Il codice che segue permette di creare una mappa con le API Google Maps visualizzando una lista di marker partendo da indirizzi. Il codice sfrutta il plugin GMap3 per instanziare la mappa.

Per gestire la lista degli indirizzi da cui ricavare latitudine e longitudine per i marker avrei potute usare la funzione nativa del plugin stesso ma ho notato che, con array superiori ai 10 item, si crea un effetto poco piacevole. Quando la lista è numerosa, infatti, il codice impiega diverso tempo per ottenere le coordinate: la mappa viene immediatamente istaziata ma può passare anche qualche secondo prima che tutti i “balloon” vengano visualizzati. Continua a leggere…

Il codice che segue permette di creare una mappa visualizzando una lista di marker partendo da indirizzi. Il problema più grande, in caso di mancanza di latitudine e longitudine, è il fatto che le API di Google Maps impongono un timeout alle chiamate. Per ovviare ho scritto una funzione che reitera la lista degli indirizzi fino a quando tutte le richieste non sono state soddisfatte. Continua a leggere…

In vista del rilascio di un sito con layout responsive ho cercato una soluzione che mi permettesse di ottimizzare il caricamento delle immagini. Alla base del ragionamento c’è una semplice considerazione: se la risoluzione del device è di 480 pixel è inutile fornire immagini 3 volte più grandi, soprattutto se l’utente non ha a disposizione una connessione a banda larga.

Ho immaginato questa soluzione basandomi su Wordpress, dove è semplice avere in automatico diversi tagli della stessa foto. Il limite più grosso della tecnica proposta, quindi, è dare per scontata l’esistenza di diverse versione dello stesso file. A differenza di Adaptive Images non è prevista la creazione di immagini “on the fly”.

Potete vedere la demo accedendo con vari dispositivi se potete.

Prima di passare all’analisi del codice alcune considerazioni importanti.

- Il proof of concept utilizza un cookie, un javascript da 1,1 KB (compresso) e 2 regole da inserire in un file htaccess (se avete accesso alla configurazione del virtualhost, ovviamente, mettete le regole lì dentro. Le elaborazioni saranno più veloci).

- Lo script è volutamente in javascript puro per questioni prestazionali. La prima versione che ho fatto usava jQuery ma, anche se l’adoro, è pur sempre un wrapper e quindi più lento nell’esecuzione. Al primo caricamento, in molti casi, non venivano fornite le immagini giuste per via di una lenta elaborazione. Dopo che la libreria veniva servita dalla cache del browser, ovviamente, la situazione cambiava.

- L’approccio che ho utilizzato inizialmente era di impostare come default le immagini più piccole, per sostituirle all’occorrenza con quelle più grandi.
Dopo tutti i test effettuati ho valutato che fosse meglio agire al contrario. In caso di errori da parte del client il massimo che può accadere è che gli vengano fornite le immagini di peso maggiore; poco male rispetto al caso in cui ad un browser con risoluzione di 1900×1200 vengano mostrate foto 70×70.

- Questa tecnica non si basa sull’analisi degli user-agent ma sulla risoluzione dello schermo dell’utente indipendentemente dal dispositivo che usa. Non era mia intenzione fornire un’immagine per ogni device ma, piuttosto, ragionare per breakpoint (anche abbastanza ampi).
Mi spiego meglio: nella maggior parte dei casi la differenza tra l’immagine desktop e quella per tablet potrebbe essere minima; quello che è importante è riuscire a distinguere le foto tra smartphone e pc. Ecco perchè i breakpoint per default sono 3: small, medium e normal.
Attenzione ad un particolare: il javascript utilizza window.screen.availWidth. Ciò significa che sul mio tablet android, sia inversione portrait che landscape, il valore restituito sarà sempre 1280, ovvero la risoluzione massima impostata. In sostanza do per scontate che se entrate nel sito con una risoluzione la manterrete per tutta la navigazione.

La scelta di comprire con un unico breakpoint tutte le versioni tablet è voluta anche per via di possibili problemi di cache del cookie. Molto dipende anche dai breakpoint che avete costruito voi nel vostro layout responsive.

Questo tutorial propone un’alternativa all’utilizzo dei captcha per prevenire lo spam dei software automatici.
La tecnica “honeypot” (barattolo di miele), rivista e corretta in diversi aspetti, è conosciuta da tempo ma spesso viene poco considerata. Non si garantisce l’eliminazione totale dei messaggi indesiderati – traguardo impossibile vista l’esistenza degli spammer umani – ma in determinati contesti e situazioni si possono raggiungere ottimi risultati.

L’esperimento vuole essere un tentativo di andare incontro agli utenti senza obbligarli, come avviene oggi, a sforzi cognitivi superflui. Di contro, come è giusto che sia, si spostano sul fornitore del servizio tutti gli òneri relativi ai controlli.
Un punto deve essere chiaro: la soluzione definitiva contro lo spam ancora non esiste e, di certo, non si sta promettendo di riuscire a trasformare il piombo in oro.

Se non desideri leggere i vari capitoli del tutorial puoi passare direttamente all’esempio finale.

Indice

• Introduzione
• Ambiti di utilizzo
• Tipi di bot
• La tecnica “honeypot”
• Esempio n° 1
• Esempio n° 2
• Esempio n° 3
• Esempio n° 4
• Download degli esempi

Continua a leggere…

Se abbiamo la necessità di inserire javascript da domini esterni al nostro sito può essere importante caricarli in modalità asincrona per evitare possibili SPOF. Continua a leggere…