Dal 2004 il blog di Antonio Troise

Oggi ho deciso di inserire sul mio blog il widget per Google Friend Connect per provare il servizio di Google pensato per rendere i siti più sociali. Il vantaggio di usare Google Friend Connect è quello di creare una piccola community su cui far convergere i propri utenti (basta che abbiano un semplice account gmail) e proporre, magari, domande agli utenti che decidono di entrare a far parte di Friend Connect, in modo da conoscere meglio i loro interessi, oppure scambiarsi messaggi privati tra i membri della stessa community.
Interessante è anche la possibilità del proprietario del sito di inviare newsletter agli utenti che partecipano alla community, dividendole anche in base ai loro interessi. Tutte le informazioni raccolte possono anche essere esportate in formato JSON o XML. E’ probabile che presto si integrerà con i flussi di informazioni di Google Wave in modo da alimentare automaticamente la community con nuove discussioni, ma quel che è certo è che uno degli aspetti non proprio secondari è quello di potersi integrare con Google AdSense in modo da poter visualizzare annunci pubblicitari che tengono conto sia dei contenuti del sito, che degli interessi personali espressi in precedenza dai singoli utenti.

Come attivare Google Friend Connect

Rispetto ai primi tempi in cui il servizio era attivo, ora non è più necessario scaricare e inserire nella root del proprio sito web i file rpc_relay.html e canvas.html e l’attivazione è molto semplice. Infatti, dopo essersi loggati con il proprio account Google (che equivale al proprio account Gmail), sarà sufficiente accettare i “Termini di servizio per gli sviluppatori di Friend Connect”

e verrete subito mandati ad una pagina in cui potrete inserire il nome e la url del vostro sito

per poter attivare la vostra nuova community!

Bene, ora non resta altro che creare un gadget che permetta agli utenti del proprio sito di unirsi alla vostra nuova community.

La procedura è molto semplice e guidata

e vi permetterà di creare del codice HTML del tipo:

<br /> <!-- Include the Google Friend Connect javascript library. --><br /> <script type="text/javascript" src="http://www.google.com/friendconnect/script/friendconnect.js"></script><br /> <!-- Define the div tag where the gadget will be inserted. --></p> <div id="div-234567890123456789" style="width:276px;border:1px solid #cccccc;"></div> <p><!-- Render the gadget into a div. --><br /> <script type="text/javascript"> var skin = {}; skin['BORDER_COLOR'] = '#cccccc'; skin['ENDCAP_BG_COLOR'] = '#e0ecff'; skin['ENDCAP_TEXT_COLOR'] = '#333333'; skin['ENDCAP_LINK_COLOR'] = '#0000cc'; skin['ALTERNATE_BG_COLOR'] = '#ffffff'; skin['CONTENT_BG_COLOR'] = '#ffffff'; skin['CONTENT_LINK_COLOR'] = '#0000cc'; skin['CONTENT_TEXT_COLOR'] = '#333333'; skin['CONTENT_SECONDARY_LINK_COLOR'] = '#7777cc'; skin['CONTENT_SECONDARY_TEXT_COLOR'] = '#666666'; skin['CONTENT_HEADLINE_COLOR'] = '#333333'; skin['NUMBER_ROWS'] = '4'; google.friendconnect.container.setParentUrl('/' /* location of rpc_relay.html and canvas.html */); google.friendconnect.container.renderMembersGadget( { id: 'div-234567890123456789', site: '12345678901234567890' }, skin); </script><br />

da inserire nella vostra sidebar (di solito corrisponde al file sidebar.php del vostro tema WordPress). Se volete evitare di mettere mano al codice html, potete installare il seguente widget per WordPress: Google Friends Connect Widget. Dopo averlo attivato dalla pagina dei plugin, nella pagina della Gestione Temi di WordPress trovate la sezione Widget. Qui basterà spostare, con un semplice drag e drop, il widget interessato nella posizione desiderata

e configurare correttamente il proprio “site id“ (quello che nel codice html compare in fondo dopo “site:“)

Problema di visualizzazione del gadget di Google Friend Connect

In realtà tutto questo è in linea teorica, perché sia usando il widget per WordPress, sia inserendo il codice html fornito dalla pagina di Google Friend Connect, questo è stato il risultato visualizzabile sui browser che uso solitamente sul mio Macbook Pro: Safari 4.0.4 e Firefox 3.5.6.

Sembra, infatti che su alcuni browser il gadget di Google non venga visualizzato correttamente (da quanto leggo sembra che Firefox avrebbe dovuto visualizzare correttamente il gadget ma probabilmente il browser testato era per Windows).
Per rendere visibile il gadget su qualsiasi browser di qualsiasi sistema operativo è sufficiente inserire il seguente codice html subito prima del tag di chiusura </body> (e quindi, nel caso di un tema standard per WordPress, troverete il tag richiesto nel file footer.php della cartella del vostro template) in moda da istruire il browser ad usare il parser Prototype JSON invece che quello Native JSON.

<br /> <script> window.JSON = { parse: function(st){ return st.evalJSON(); }, stringify: function(obj){ return Object.toJSON(obj); } }; </script><br />

e questo sarà il risultato!

Ora che finalmente è attiva la funzione di Friend Connect, cosa aspettate: cliccate sul pulsante “Login” che trovate nella colonna qui a lato ed entrerete anche a voi far parte della community di Levysoft!

Alle volte può sembrare che, quando vengono proposte soluzioni a riga di comando, ci si voglia complicare le cose nonostante esistano decine di altri modi, molto più user friendly, semplici, efficaci e veloci. Vi starete chiedendo per quale motivo una persona vorrebbe scaricare un file da riga di comando piuttosto che usare una delle tanti utility grafiche e gratuite disponibili o, più semplicemente, usare il download manager del proprio browser, che qualunque esso sia, svolge già efficacemente il proprio lavoro?
Ebbene, la ricerca di queste soluzioni alternative avvengono semplicemente per necessità e non solo per il gusto di complicarsi la vita lanciandosi ogni volta in nuove sfide, o almeno è questo quello che accade a me!

Vi siete mai chiesti o vi siete mai trovati nella situazione di dover scaricare qualche file in parallelo? Ebbene, sicuramente avrete constatato un inevitabile rallentamento del sistema direttamente proporzionale al numero di download simultanei che vengono lanciati, sia perché, almeno in minima parte il processore deve gestire il trasferimento, sia perché la scrittura di più file contemporaneamente sull’hard disk (anche se in questo caso il concetto di simultaneità non è verosimile) impegnano il drive tanto da lasciare indietro le operazioni del sistema operativo.

Ebbene, la situazione potrebbe essere spiacevole se su quello stesso PC ci dovete lavorare. Ed è allora che vi viene in mente che forse potreste riutilizzare quel vecchio PC che non usate più, formattarlo, installarci sopra una qualsiasi distribuzione linux, e usarlo esclusivamente come Download Manager. Quindi, ogni qualvolta, vorrete scaricare un o più file da Rapidshare, basterà che vi colleghiate in telnet sul PC Muletto, aprite un file di testo, incollate le url dei file Rapidshare da scaricare, salvate il file e lanciate un piccolo script che eseguirà per voi tutto il lavoro, senza appesantire il sistema su cui state lavorando. Ovviamente, il sistema che adotterò, per essere il più leggero e flessibile possibile, non disporrà di una interfaccia grafica, bensì sarà esclusivamente a riga di comando, insomma da veri geek. Ma vi assicuro che questa è la soluzione inaspettatamente più semplice per risolvere il vostro problema di performance.

In questa sede, comunque, affronterò esclusivamente la soluzione che risolverà il problema di come scaricare un file da Rapidshare se si possiede un abbonamento Premium e quindi si potrà disporre di un utente e password che vi garantirà un servizio che può accettare più richieste di download contemporanee (anche se come vedremo più tardi ho deciso di non usarlo per non appesantire il vecchio PC Muletto) e che non richiede alcun tempo di attesa tra un download e il successivo.

Installare WGET

Per la mia soluzione userò wget, un potente comando per scaricare una pagina web o inviare richieste GET o POST, con o senza autenticazione. Se disponete di un sistema Unix/Linux, è molto probabile che lo troverete compilato e già pronto per essere eseguito. Se invece vi trovate su un sistema Mac OS X (Tiger o Leopard che sia), nonostante si abbia a disposizione nel sistema operativo una shell unix completa di tutti i maggiori comandi, l’unico a mancare sarà proprio wget. Ci sono alternative altrettanto valide, come curl o ftp (e, per chi se lo ricorda, anche lynx che col comando “lynx URL >dump.txt” è una variante alternativa), ma per i nostri scopi, wget è abbastanza flessibile e semplice tanto da essere necessario per creare il nostro script. Quindi, per chi non volesse passare per la fase di compilazione, qui potete scaricare la versione compilata per i sistemi Mac OS X 10.5.3 e superiori (quindi anche Tiger e Leopard): wget.zip. Una volta scaricato sarà già funzionante sul vostro sistema, ma per una installazione completa, lanciate questi comandi:

<br /> cd wget<br /> sudo su root (enter password)<br /> mv wget.1 /usr/share/man/man1<br /> mv wgetrc /usr/local/etc<br /> mv wget /opt/local/bin/wget<br />

e se fosse necessario, eseguirte un

<br /> export PATH=$PATH:/usr/local/bin<br />

anche se nel file .profile della propria home directory dovrebbe già contenere il percorso settato, come qui mostrato:

<br /> echo $PATH | grep -q -s “/usr/local/bin”<br /> if [ $? -eq 1 ] ; then<br /> PATH=$PATH:/usr/local/bin<br /> export PATH<br /> fi<br />

Ora che abbiamo installato wget sul nostro sistema Mac, questo si comporterà a tutti gli effetti come un sistema Linux, quindi d’ora in poi non farò alcuna distinzione tra i due sistemi operativi.

Creare lo script – STEP 1

Per la creazione dello script ho preso spunto da my-guides.net e in questa sede mi dedicherò a spiegarne il funzionamento del codice adattato alle mie esigenze.

Rapidshare, per l’autenticazione, usa i cookie HTTP, dei file di testo inviati da un server ad un Web client (di solito un browser) e poi rimandati indietro dal client al server, senza subire modifiche, ogni volta che il client accede allo stesso server, e sono usati per eseguire autenticazioni e tracking di sessioni e per memorizzare informazioni specifiche riguardanti gli utenti che accedono al server.
Quindi, la nostra prima operazione, sarà quella di autenticarsi sul server Rapidshare e di salvare i cookie che mi permetteranno, in seguito, di scaricare qualsiasi file dal sito di hosting file.
Attensione, lo STEP 1, andrà eseguito solo una volta, perché i cookie, a meno che non si proceda alla loro eliminazione manuale, verranno salvati in una cartella della vostra home directory.

Il comando da lanciare è il seguente:

<br /> wget \<br /> –save-cookies ~/.cookies_rapidshare \<br /> –post-data “login=USERNAME&password=PASSWORD” \<br /> –no-check-certificate \<br /> -O – \<br /> https://ssl.rapidshare.com/cgi-bin/premiumzone.cgi \<br /> > /dev/null<br />

dove i parametri indicano:

• –save-cookies: definisce dove salvare i cookies. Essendo dati più sensibili ho preferito creare un file nascosto (anche se ciò non garantisce la sicurezza del file)

–post-data: assegna il metodo POST (piuttosto che GET) per inviare al form di login i dati di username e password.
–no-check-certificate: non richiede la validazione del certificato che restituisce il server (Se state usando una versione di wget precedente alla 1.10.2 l’opzione –no-check-certificate non è necessaria)
-O: esegue il download della pagina html solo per ottenere i cookie e redirige l’output su /dev/null per non far comparire a video le righe del codice html.

Ovviamente, ricordatevi di sostuire USERNAME e PASSWORD con quelli del vostro account Rapidshare.

Creare lo script – STEP 2

Ora, ogni qualvolta dobbiamo scaricare un file da Rapidshare, dobbiamo digitare quanto segue:

<br /> wget -c –load-cookies ~/.cookies_rapidshare URL<br />

dove il parametro -c si occupa di recuperare un eventuale download precedentemente interrotto che, quindi, ripartirò dal punto di arresto, mentre il parametro –load-cookies esegue un caricamento preventivo dei cookie precedentemente salvati per ottenere l’autorizzazione a scaricare, per poi, infine, dare in pasto la URL desiderata del file da scaricare. Però, nel momento in cui dovete scaricare più di un file, è evidente che dover scrivere ogni volta questa riga può essere noioso. Ecco perché ci troveremo a dover scrivere un piccolo script bash che automatizzerà il processo, dandogli in input le righe di un file urls.txt (che conterrà un file per ogni riga):

<br /> #!/bin/bash<br /> for url in `cat $1`<br /> do<br /> wget -c –load-cookies ~/.cookies_rapidshare $url<br /> done<br />

Salvate il codice sopra come file downloader.sh e rendetelo eseguibile con il seguente comando:

<br /> chmod +x downloader.sh<br />

Ora copiate tutti i link dei file Rapidshare (uno per riga) che volete scaricare e incollateli nel file urls.txt. Quindi, per scaricare tutti i file, basterà digitare questo semplice comando:

<br /> ./downloader.sh urls.txt<br />

Et Voilà! Il gioco è fatto e potete disporre di un sistema leggero, indipendente e autonomo per scaricare decine di file senza appesantire il vostro PC.

Scompattare un file RAR da riga di comando

Di solito i file su Rapidshare vengono compressi nel formato RAR e qualche volta sono anche protetti da password. Se volete completare l’opera, potete scaricare l’utility per riga di comando per Linux (o Mac) unRar 2.71 (ma esiste anche unrar della rarlab) e una volta decompresso

<br /> tar xfvz unrar-2.71.tar.gz<br />

è possibile compilarlo entrando nella cartella unrar-2.71 appena creata e lanciando i comandi

<br /> make<br /> make install<br />

Ora vi ritroverete il file eseguibile unrar nella directory /usr/local/bin/ e quindi accessibile da qualsiasi directory.

Se non potete fare a meno di seguire il Keynote Apple di oggi martedi 14 Ottobre 2008 presso il Town Hall di San Francisco, bombardati dalle decine di rumors e segnalazioni fotografiche di presunti nuovi modelli di Macbook, Macbook Pro e Apple Cinema, allora sicuramente, alle 19:00 di questa sera, sarete tra quelli che resteranno davanti al PC, pronti a cliccare sul tasto refresh del vostro browser. Se volete evitare questa noiosa procedura, laddove i vostri siti preferiti non supportino l’auto-refresh delle pagine che seguono il live dell’Apple Event, allora non potrete di certo fare a meno di Site Reloader (sito simile ma più evoluto di Page Reboot, comunque valido se non si hanno particolari esigenze), una utility web che ci permette di aggiornare una o più pagine web caricate attraverso delle finestre popup, con un intervallo di tempo del reload che va da 5 secondi a 30 minuti (di default è impostato un tempo ragionevole, anche per il live blogging di questa sera, di 30 secondi).

Come funziona Site Reloader

La procedura è molto semplice: andiamo sul sito, inseriamo l’indirizzo del sito a cui siamo interessati e clicchiamo su Add. Quindi, verrà aggiornata in ajax una lista presente sotto il textbox, con l’elenco di tutte le url inserite e il relativo tempo di reload modificabile a piacere. E’ possibile anche eliminare un sito, cliccando sull’icona rossa con la X, e automaticamente verrà chiusa anche la finestra popup relativa. Oppure, molto più semplicemente, chiudere la finestra popup di un sito e, automaticamente, verrà eliminata anche la riga nella lista dei siti di Site Reloader.

A differenza di altre applicazioni web simili, questo sito sfrutta le Google App Engine e, per poter salvare la lista dei siti da monitorare, occorre loggarsi con un account Google (lo stesso che usate per la vostra Gmail o per uno delle decine di servizi messi a disposizione dal motore di ricerca).

Inoltre, sempre solamente per gli utenti che effettuano il login e che hanno, quindi, potuto salvare la lista dei siti da monitorare, è presente anche la funzione di autocaricamento dei siti salvati sulla nostra lista, appena si aprirà la pagina di Site Reloader. Unica nota: per funzionare correttamente, Site Reloader necessita della disabilitazione (o dell’abilitazioni delle eccezioni) dell’eventuale Popup Blocker presente oramai di default su qualsiasi browser.
In definitiva, Site Reloader è indubbiamente un servizio molto utile per seguire cronache di eventi in diretta.

La lista dei siti che seguono il Keynote Apple

Per finire, ecco una lista di siti, che potrete inserire su Site Reloader, che questa sera, verso le ore 19:00 ora italiana (ore 10 am ora locale) effettueranno il live blogging dell’evento Apple:

• Engadget (live)
• Crunchgear (qui il live con le pagine che effettuano il refresh automatico)
• MacRumorsLive
• MacWorld (live)
• Gizmodo
• The Apple Lounge Live Twitter
• Melablog

Vantaggi e svantaggi

Il vantaggio di usare servizi web online (piuttosto che applicazioni standalone come plugin per Firefox come ReloadEvery) è, indubbiamente, oltre ad essere indipendenti dalla piattaforma e dai browser usati, anche quello di avere la lista dei siti da monitorare ovunque si sia. Lo svantaggio è che, come spesso accade in eventi mondiali che riscuotono un notevole successo mediatico che, in termini pratici, corrisponde ad un numero elevato di visitatori, è possibile che siti come Site Reloader possano andare offline, come accaduto durante il Keynote Apple del 15 Gennaio 2008 in cui servizi online come Twitter e CoverITLive non hano retto l’intenso traffico che da tutto il mondo transitava sui loro servers, venendo meno l’interessante diretta che stavano realizzando.

Non credo questo possa essere il caso di Site Reloader, nel qual caso dovremmo ricorrere al vecchio metodo del refresh manuale delle pagine internet, oppure, molto più semplicemente, collegandosi ad evento finito bypassando le spasmodiche cronache del Keynote Apple!

Tumblr è la più famosa piattaforma di microblogging, una forma di pubblicazione costante di piccoli contenuti in Rete, o, più precisamente di tumblelog (o tlog), una variante del blog, che favorisce una forma abbreviata arricchita da multimedialità, rispetto a quelli che sono i lunghi editoriali frequentemente associati ai blog. La forma di comunicazione comunemente usata include collegamenti, fotografie, citazioni, dialoghi di chat e video. A differenza dei blog questo formato è frequentemente usato dall’autore per condividere creazioni, scoperte, esperienze senza la necessità di commentarle.

L’usabilità di un blog su Tumblr

Anche io ho un piccolo tumblr (Levysoft’s tumblelog) che aggiorno salturiamente e lo uso, come una sorta di contenitore di cose che trovo in giro per la rete, curiosità, news, foto o video, che non approfondisco o pubblico sul mio blog, ma che mi hanno comunque interessato. In tal modo, in qualche modo, riesco, almeno virtualmente, a preservare memoria di quello che trovo interessante.
Ma quando i micropost aumentano, a volte risulta davvero difficile la consultazione, perché bisogna andare alla ricerca di una determinata notizia tra le varie pagine del proprio tumblr. Certo, esiste la possibilità di ricercare una determinata parola dal relativo modulo di ricerca (oppure accodando alla url “http://yourname.tumblr.com/search/” la chiave di ricerca desiderata), ma è anche vero che non è possibile consultare il proprio tumblr in modalità offline. Inoltre, ammettiamolo, c’è sempre la remota possibilità che i propri dati vengano persi e, siccome, a differenza di WordPress o Blogger, non è ancora stato previsto ufficialmente alcuna funzione di esportazione e/o importazione del proprio tumblelog (anche semplicemente per spostarlo su una diversa piattaforma di blog), dedicare il proprio tempo per mesi a popolare un sito per poi vederselo sparire all’improvviso, è una eventualità che nessuno vorrebbe vivere, perché in quelle pagine, ognuno di noi ritrova una piccola parte di se stessi.

Backup dei feed rss di un blog Tumblr

Per sopperire a questo problema tempo fa risolsi questo problema, iscrivendo il mio lettore di feed reader al RSS del mio blog tumblr (del tipo feed://yourname.tumblr.com/rss). In tal modo, siccome gli articoli vengono pubblicati integralmente sul feed rss, in qualche modo riuscivo a fare una sorta di backup e di database degli articoli pubblicati.

Tumble-log Backup

Ma esiste anche una modo più semplice: usare Tumble-log Backup, un tool online gratuito, che consente di creare un backup dei post pubblicati su Tumblr in un unico file html. Sarà sufficiente inserire il nome del proprio blog (funziona anche se è ospitato su domini personalizzati), decidere il numero dei post da copiare (vengono suggeriti un numero non superiore a 500 ma credo non esista un limite di articoli), e Tumble-log Backup si occuperà di creare una singola pagina web che verrà caricata con tutti i testi, foto, audio e video del proprio blog, in ordine cronologico, dal più recente al più vecchio, con la possibilità di selezionare solo uno o più tipi di elementi.

Una volta terminato il caricamento della pagina (che impiegherà un tempo variabile a seconda delle dimensioni del tumblr da backuppare) sarà possibile salvare la pagina html appena creata con il proprio browser.

Certo, non stiamo parlando di uno strumento in grado di effettuare un vero e proprio backup tale da poter essere ripristinato su qualsiasi altra piattaforma, ma la cosa interessante è che possibile utilizzare questo tool online per salvare una copia virtuale offline, da leggere con calma, di qualsiasi tumblr pubblico.

Gelato CMS il clone installabile di Tumblr

Se, però, volete avere il completo controllo del vostro microblog, senza però dovervi affidare a servizi di terzi parti (che, diciamoci la verità, possono chiudere da un giorno all’altro senza l’obbligo di fornirvi un backup) ma non volete rinunciare alla semplicità di Tumblr, allora potete installare sul vostro sito, Gelato CMS, un perfetto clone di Tumblr, sia nelle sue funzionalità che nei temi usati.
Gelato è un CMS Open Source, sviluppato in Messico, costruito attraverso l’utilizzo di codice Ajax, Php e MySQL, che sembra avere tutte le carte in regola per essere il corrispettivo di WordPress.org per quel che riguarda i tumblelog. Il vantaggio rispetto a Tumblr è quello di avere una community di sviluppo attiva in grado di apportare numerose novità e miglioramenti, grazie anche all’introduzione dei plugin.

Sinora ho parlato spesso dei DNS e in particolare degli OpenDNS (un servizio che offre liberamente i propri DNS per uso pubblico), sia quando i server DNS di Telecom Italia furono messi in ginocchio, sia per l’annuncio di una vulnerabilità insita nel protocollo DNS stesso che potrebbe permettere ad un malintenzionato, tramite il DNS Cache Poising, di controllare il traffico internet e fare del Pishing (per controllare se i vostri DNS sono sicuri, potete verificare sul completo e chiaro dns-oarc.net o sul più sintetico doxpara.com), sia, per finire, per i test di velocità che feci tra i server DNS di Alice Telecom Italia e quelli OpenDNS in cui i primi risultarono, al ping, molto più veloci dei secondi.
Ed è proprio a proposito di quest’ultimo articolo che vorrei riprendere e, al contempo, ampliare, l’argomento della velocità dei server DNS, stimolato anche da un commento di un mio lettore nel suddetto articolo, che asserisce:

ICMP non è UDP (o TCP). Può darsi comunque che i server OpenDNS siano più veloci alle query DNS anche se sono più lenti al ping.

In effetti le sue affermazioni sono teoricamente ineccepibili, anche se, a parer mio, poco probabili. Infatti le mie analisi partivano dal presupposto che non vi esistessero filtri tra i vari protocolli usati. Per fugare ogni dubbio, ho deciso quindi di rendere più precise le mie valutazioni, misurando anche quanto impiegano i server DNS a rispondere alle query.

Ma prima di partire con queste analisi, è necessario rispolverare un po’ di teoria sul DNS.

Un po’ di teoria sul DNS

Il DNS (Domain Name Service) è un servizio che permette di tradurre nomi di dominio come www.levysoft.it in indirizzi IP come 64.57.102.34 (grazie ad un database distribuito di servers DNS). Infatti, i computer non sono in grado di instradare i pacchetti verso un nome di dominio ma solo verso il corrispondente indirizzo IP. L’adozione del DNS, quindi, ha il solo scopo di semplificare la vita a noi esseri umani, in quanto risulta molto più facile ricordare una stringa testuale mnemonica piuttosto che un anonimo indirizzo IP.
Se, quindi, assegnare nomi ai computer rende la memorizzazione molto più semplice, è evidente che a questo punto è necessario uno strumento, come quello del DNS, in grado di associare automaticamente i nomi agli indirizzi IP.

Per risolvere l’indirizzo IP esistono diversi comandi:

1. host: viene usato per associare nomi ad indirizzi IP. È una utility, per Linux e Mac OS X, molto rapida e semplice, con poche funzioni:
   host levysoft.it

   levysoft.it has address 69.71.248.10
levysoft.it mail is handled by 0 levysoft.it.


   host è considerato insieme a dig il sostituto ufficiale di nslookup.

2. nslookup: (Name Server Lookup) è uno strumento consolidato presente in tutti i sistemi operativi che utilizzano il protocollo TCP/IP (Gnu/Linux, Unix, MAC OS X, Windows) ma che, essendo superato, potrebbe anche essere rimosso in molte future versioni delle distribuzioni Linux.
   Nslookup consente di effettuare delle query (richieste) ad un server DNS per la risoluzione di indirizzi IP o Hostname, per poter ottenere da un dominio il relativo indirizzo IP o nome host e viceversa.

   
nslookup levysoft.it

   Non-authoritative answer:
Name: levysoft.it
Address: 69.71.248.10


   Nonostante sia considerato obsoleto, in quanto è stato uno dei primi tool in grado di lavorare con il DNS, nslookup è un comando ancora molto potente. Per esempio, con due soli comandi, whois e nslookup, è possibile scovare i DNS Pubblici di un provider. Il primo serve a determinare chi ha registrato il nome di dominio, mentre il secondo interroga i DNS per risolvere l’indirizzo IP del server.

3. dig: (Domain Information Groper) è il comando più potente per recuperare informazioni relative al Domain Name Server indicato, inclusi reverse lookup, A, CNAME, MX, SP e record TXT. Dig è molto usato sia per la sua grande flessibilità che per i suoi output molto chiari. Contrariamente a nslookup, dig non contempla una modalità interattiva, ma è disponibile solamente in modalità non interattiva o batch che permette di fargli leggere le richieste da un file.
   Dig ha una tale infinità di opzioni (tanto che da molti viene considerato l’alternativa più verbosa e completa a nslookup), che nella sua pagina di manuale gli sviluppatori fanno dell’ironia su questo fatto tanto che, sotto la voce BUGS, si trova “There are probably too many query options“.

   La sua sintassi è la seguente:

   dig [@nameserver] [opzioni] [nome_risorsa] [tipo_di_richiesta] [ulteriori_opzioni])

   ma, di norma, si utilizza nel modo seguente:

   dig @server name type

   Se non specificato, dig utilizza come server per le richieste quello presente in /etc/resolv.conf.

   Dig, il cui nome deriva dal verbo inglese to dig (scavare, scoprire o investigare), è una utility presente in qualsiasi sistema operativo all’interno del quale è installato l’ambiente DNS BIND; pertanto essa è disponibile nativamente in ambiente Linux/Unix e Mac OS X, mentre è assente su Windows.
   Se volete usarlo anche sui sistemi Windows, allora dovrete scaricarvi la versione compilata per Windows, DIG, che permette la restituzione dei record DNS per un dominio specifico anche sulla piattaforma di casa Microsoft.

Calcolare il time response delle query DNS

Ora che abbiamo superato la parte più noiosa della teoria, passiamo alla pratica, basandosi sempre sui primi test di velocità effettuati con il classico ping che misurava il tempo, espresso in millisecondi, impiegato da uno o più pacchetti ICMP di echo request a raggiungere un server DNS.

Questa volta, però, sfruttando il potente comando DIG, ho inviato delle query dirette ai server DNS e calcolato il DNS Response Time, ovvero il tempo che il server impiegava a risolvere un nome di dominio che gli veniva passato. Questo valore ovviamente è direttamente proporzionale alla distanza geografica del server (come per il ping) e alla velocità di elaborazione del server, teoricamente molto bassa e che a sua volta dipende dal carico di sistema. In poche parole, con queste due componenti avremo la possibilità di effettuare test i più veritieri possibili, ponendosi proprio come se fosse il PC ad interrogare il server DNS.

In pratica, i comandi da lanciare dal proprio PC, per i vari server presi in esame saranno:

OpenDNS
dig http://www.levysoft.it @resolver1.opendns.com
;; Query time: 37 msec

DNS TIN
dig http://www.levysoft.it @212.216.112.112
;; Query time: 3 msec

Esistono, poi diversi tool online per calcolare il tempo di risposta di una query DNS. Tra questi, ne ho presi in esame 2 colocati all’estero: DIG: look up DNS domain IP address information e Dig DNS Check.

Ed ecco i risultati:

Ed ecco i risultati per i server OpenDNS:

Come vedete, i risultati sono molto simili a quelli ricavati con il PING ICMP. Qui in Italia, i tempi di risposta sono nettamente superiori per i server OpenDNS, a causa, appunto, della localizzazione geografica.
Discorso inverso, invece, si applica se la query viene lanciata da un server estero: gli OpenDns sono più veloci di quelli Alice.

Con questo articolo quindi ho dimostrato che le analisi effettuate con un PING ICMP assumono la stessa valenza statistica di quelle effettuate con i DNS Response Time delle query inviate direttamente al server DNS.

Ovviamente con questi test non voglio assolutamente affermare quale server DNS prediligere: i motivi per cui è vantaggioso scegliere gli OpenDNS sono innumerevoli, per cui sta a voi decidere cosa è meglio per il vostro sistema in base alle vostre esigenze ed aspettative.

Il vantaggio di possedere un computer con Mac OS X è quello di avere sempre a disposizione, perché inclusa nativamente nel sistema operativo, una shell unix completa, per i più esperti, o Automator, per i meno esperti. Quest’ultimo strumento è una applicazione davvero potente perché consente di creare in maniera visuale, grazie ad un diagramma di flusso (workflow) e trascinando le azioni una dopo l’altra (drag & drop), programmi di automazione davvero complessi e articolati.

Ma dopo aver lavorato anni sui sistemi unix, avere sottomano una potente shell unix, è una tentazione di cui davvero non posso fare a meno. Infatti, con la semplice concatenazione di comandi (pipeline) come grep, sed e awk (altri comandi utili possono anche essere sort, uniq tail, head, cut e wc) in una sola riga, è possibile estrarre (scraping) informazioni da pagine web. Infatti, struttando il fatto che le pagine html sono, anche se in misura minora ad un più ordinato e formattato file xml, strutturate con i TAG, con pochi comandi è possibile fare del sano Web_scraping.

WGET

Il comando più potente da riga di comando per scaricare una pagina web o inviare richieste GET o POST, con o senza autenticazione è, come noto, WGET.
Per scaricare un file è possibile usare una sintassi tipo:

<br /> wget http://www.miosito.it/directory/file.zip<br />

Ma la vera potenza di wget risiede nella possibilità di realizzare, con una sola riga di comando, un mirror ad un sito web.
Quindi per scaricare un intero sito in locale basta scrivere:

<br /> wget –mirror http://www.miosito.it/<br />

mentre, per scaricare solo una pagina con tutti i link interni:

<br /> wget -r -np http://www.miosito.it/index.htm<br />

Il problema è che sui sistemi MAC OS X, wget non è installato di default e, quindi, per chi non volesse passare per la fase di compilazione (anche se in giro esistono versioni già compilate per Tiger e Leopard) o, comunque, ha semplicemente la necessità di scaricare solo una file o una pagina web, allora è possibile usare una delle due alternative preinstallate su Mac OS X: ftp e curl.

FTP

Il comando FTP può essere usato anche per scaricare file HTTP.
La sintassi è molto semplice:

<br /> ftp http://www.miosito.it/directory/nomefile.html<br />

Come vedremo, in seguito, per i nostri scopi molto spesso il comando FTP è più che sufficiente per la maggior parte delle operazioni comuni.

CURL

CURL è un tool da riga di comando estremamente potente perché permette di scaricare in maniera molto flessibile ed automatizzata un qualsiasi numero di files da internet, secondo i protocolli HTTP o FTP, e di visualizzarli a schermo o di scriverli su disco.
La sintassi semplice, simile a quella dell’FTP, è:

<br /> curl -O http://www.miosito.it/directory/nomefile.html<br />

In realtà la sintassi completa è:

<br /> curl “URL del file da scaricare” -o “nome da assegnare al documento scaricato su disco”<br />

Ma la vera flessibilità del comando nasce dalla possibilità di usare nella sintassi dell’URL le parentesi quadre per indicare una serie di URLs incrementali.
Per esempio una sintassi tipo:

<br /> curl “http://www.miosito.it/image/129-[2947-2996]_img.jpg” -o “immagine#1.jpg”<br />

creerà in modo automatico tutti gli URLs compresi nell’intervallo numerico specificato, e scaricherà in successione i file corrispondenti. Ai files sull’HD verrà assegnato il nome specificato dopo la flag -o, usando l’indice #1 per creare nomi univoci, incrementati allo stesso modo della sorgente.
In poche parole la singola riga di cui sopra equivarrà ad aver digitato in successione tutti i comandi:

<br /> curl “http://www.miosito.it/image/129-2947_img.jpg” -o “immagine2947.jpg”<br /> curl “http://www.miosito.it/image/image/129-2948_img.jpg” -o “immagine2948.jpg”<br /> …<br /> curl “http://www.miosito.it/image/image/129-2996_img.jpg” -o “immagine2996.jpg”<br />

Attenzione: il flag -O dell’ultimo esempio differisce dal flag con la o minuscola usato in precedenza, in quanto per nominare il file sul disco rigido usa lo stesso nome del file remoto.

La successione di URLs incrementali non deve essere necessariamente numerica, ma anche alfabetica, ad esempio [a-z]. Inoltre in uno stesso comando si possono combinare più indici incrementali (notate come nel nominare il file è possibile usare anche i due indici #1 e #2)

<br /> curl “http://www.any.org/archive[1996-1999]/volume[1-4].html” -o “archive#1-vol#2.html”<br />

Monitorare la banda del proprio sito da riga di comando

Dati gli ultimi problemi di esaurimento della banda che hanno afflitto il mio sito, era evidente che una delle prime necessità che avevo era quello di monitorare costantemente la banda usata. Il problema è che, per farlo, dovevo ogni volta accedere al cPanel, il Pannello di Amministrazione del mio sito, dove, in un menu laterale, era possibile visualizzare la banda usata.

Allora ho deciso di crearmi un semplice script che, scaricasse la pagina html del mio cPanel, andasse a selezionare, con il comando grep, la riga che conteneva la frase “Monthly Bandwidth Transfer” e attraverso due comandi awk (i file separator usati in Awk sono relativi alla mia pagina cPanel e potrebbero variare a seconda delle diverse versioni e configurazioni del pannello di controllo), estrarre la banda usata:

<br /> ftp http://username:password@www.miosito.it:3456/frontend/x3/index.html</p> <p>grep “Monthly Bandwidth Transfer” index.html | awk ‘BEGIN {FS = “</td> <p>“} {print<br /> $4}’ | awk ‘BEGIN {FS = “>”} {print $2}’</p> <p>rm index.html<br />

Come potete notare, per semplicità ho incluso, direttamente nella URL, lo username e la password per accedere al Pannello di Amministrazione. Questo è possibile solo perché il metodo di autenticazione del cPanel si basa su htpasswd ma ricordiamo che non è un metodo sicuro perché, oltre a lasciare memorizzati informazioni personali, nella barra degli indirizzi del proprio browser o nella history del terminale usato, si lasciano tracce anche nei vari proxy in cui si passa e nei log del webserver, oltre, come comunque avviene l’autenticazione classica se non passa per SSL, con un semplice sniffer.

Ci tengo a precisare che quello sopra illustrato è solo uno dei tanti modi per risolvere il problema: questo, in particolare, è il primo che mi è venuto a mente, forte delle decine di script shell realizzati negli anni. Ovviamente è possibile anche renderlo più complesso ed efficiente, parametrizzando username, password e url e, magari, notificando con una mail o con un messaggio a video (magari anche con Growl), quando la banda è prossima all’esaurimento. Il tutto ovviamente potrebbe anche essere inserito nel crontab di sistema in modo da girare ogni ora.

Per esempio, un metodo non ortodosso, sarebbe quello di visualizzare l’output non a video ma direttamente in TextEdit usando il comando open con le pipeline. Per farlo, ho riunito i tre comandi sopra elencati in un file bash di nome: monitora_banda.bash.
Quindi lanciando:

<br /> ./monitora_banda.bash | open -e -f<br />

avremo questo risultato:

Più in generale questo è il risultato del comando ‘open’ presente su Mac OS X.
Altri esempi, potrebbero essere:

<br /> curl ‘http://example.com/encodingerror.html’ | open -a ‘Hex Fiend’ -f<br /> curl ‘http://example.com/example.html’ | open -a ‘TextMate’ -f<br /> curl ‘http://example.com/example.png’ | open -a ‘Preview’ -f<br /> curl ‘http://example.com/example.m4v’ | open -a ‘QuickTime Player’ -f<br />

Ma le possibilità, come vedete, sono infinite. Ma lo scopo di questo articolo era solo di illustrare alcuni metodi per automatizzare da riga di comando delle procedure. Il resto è lasciato all’inventiva di ciascuno di voi.

Download automatico del backup del DB Mysql

Il mio hosting non supporta il backup automatico del DB di Mysql perché non gestisce correttamente le schedulazioni di comandi da riga di comando. E’ per questo che ho realizzato un semplice script da inserire nel crontab, per scaricare quotidianamente il backup del proprio database.
Infatti, sempre nel cPanel, è presente una sezione “Backups” che permette di scaricare, manualmente e con un link statico, un full backup del sito, oppure un backup parziale del solo database Mysql o della sola home directory (il concetto esposto rimarrà comunque analogo per qualsiasi soluzione adottiate).
E’ evidente che, a questo punto, con un semplice comando, è possibile scaricare da terminale i backup:

<br /> ftp http://username:password@www.miosito.it:3456/getsqlbackup/db.sql.gz</p> <p>Requesting http://username:password@www.miosito.it:3456/getsqlbackup/db.sql.gz<br /> 401 Access Denied Still Working<br /> Username for `cPanel’: username<br /> Requesting http://username:password@www.miosito.it:3456/getsqlbackup/db.sql.gz<br /> (with authorization)<br /> 2106 KB 849.95 KB/s<br /> 2156900 bytes retrieved in 00:02 (849.92 KB/s)<br />

Basterà quindi inserirlo (con il comando crontab -e) nel crontab (se non siete esperti potrete usare il Easy Crontab Creation Tool) in modo da fargli scaricare il backup del DB, per esempio, ogni giorno alle ore 11:30 del mattino:

<br /> 30 11 * * * * ftp http://username:password@www.miosito.it:3456/getsqlbackup/db.sql.gz<br />

Attenzione: come ogni comando da terminale, FTP (ma lo stesso vale se usate WGET o CURL) andrà ad operare nella directory corrente di lavoro, quindi se volete archiviare i file scaricati in una directory apposita, spostatevici preventivamente con il comando cd nome_directory.
Inoltre, dovete tenere presente che tutti i downloads andranno a scrivere lo stesso file e, quindi, ogni giorno ci si ritroverà con solo l’ultimo file scaricato. Se avete intenzione di tenere traccia di tutti i backup scaricati, dovrete rinominare il file, per esempio, aggiungendoci un suffisso come la data di download (realizzabile o con il comando curl o con uno script bash).

Più volte mi sono dovuto imbattere in ottimizzazioni certosine per ridurre i consumi di banda mensile sul mio sito: riducendo le dimensioni dei file javascript, attivando la compressione HTTP e, a volte, anche spostando le immagini su un altro server. Ma non ho mai dovuto affrontare incrementi di banda di oltre 10/20 GB in un solo mese.
Infatti, lo scorso Giugno, con mia grande sorpresa a soli 20 giorni dall’inizio del mese, il mio sito aveva già esaurito la banda di 40 GB messa a disposizione dal Blooweb, arrivando, a fine mese, ad oltre 50 GB di banda totale. Grazie alla gentilezza dello staff del mio hosting, mi hanno ripristinato temporaneamente il servizio in attesa che capissi da cosa fosse dipeso questo improvviso aumento di banda.

Sicuramente nell’ultimo mese avevo ricevuto un incredibile aumento di visitatori e questo aveva sicuramente influenzato le statistiche: oltre 30.000 visitatori unici in più (103.000 solo a Giugno) rispetto alla media dei mesi scorsi con un incremento di banda sproporzionato di oltre 16 GB in più (giungendo a 39.52 GB a fine mese di solo traffico HTTP).

La banda è la somma del traffico HTTP, FTP, SMTP e POP

Quello che mi aveva colto impreparato, però, era che il traffico HTTP (evidenziato da tool statistici com Awstats) non era l’unico elemento che veniva conteggiato nella soglia di banda messa a disposizione da un hosting (ed evidenziato nella homepage del mio cPanel): infatti, oltre al traffico HTTP, veniva conteggiato anche quello FTP, SMTP e POP. Normalmente, però, questi valori sono sempre trascurabili rispetto alla banda generata dal traffico delle pagine web. Questo, però, fino a questo mese, visto che il 20 Giugno, a fronte di un traffico HTTP di soli 28.76 GB, il sistema misurava una banda totale che superava i 40 GB! Ovvero, stavo consumando oltre 10 GB tra traffico FTP, SMTP e POP! Una cosa davvero incredibile rispetto alla media dei mesi precedenti.

Troppi commenti con false email generano traffico SMTP

Analizzando con calma la situazione ho scoperto che la funzione di segnalazione dei commenti (del plugin per WordPress Subscribe To Comments) inviava quotidianamente molti messaggi che non venivano mai recapitati correttamente (nell’ordine di alcune centinaia al giorno), probabilmente perché molti utenti che lasciavano commenti sul mio blog non inserivano email reali. Ciò creava un indubbio traffico SMTP anche se credo non della portata di 10 GB mensili, visto che i messaggi recapitati erano solo ASCII.
Comunque, onde evitare problemi, ho provveduto ad eliminare tutte le email che si erano registrati su un solo articolo del mio sito (oltre il 95% delle mail memorizzate), supponendo che chi scrive un commento con una email fittizia sia un visitatore di passaggio e quindi non un commentatore abituale. In tal modo non ho dovuto disattivare completamente questa funzione.

Fare spesso via FTP i backup di siti molto grandi riduce la banda mensile

Un altro problema che ho messo in luce è che, se è vero che nel conteggio del traffico totale mensile, era prevista anche la banda FTP usata, allora ogniqualvolta eseguivo un backup del mio sito, questo erodeva la quota mensile. Ora siccome dal cPanel è possibile eseguire un backup di tutta la mia home directory e non solo della directory in cui risiedono le mie pagine web, ogni volta che faccio il backup del sito, scarico ben 639 MB (a fronte di un peso effettivo del mio blog di poco più di 200 MB). Se in un mese, come è accaduto a Giugno, eseguo 4-5 backup, consumo oltre 3 GB di banda mensile.
Per risolvere questo problema ho deciso di scaricare solo il contenuto effettivo del mio sito e, laddove possibile, sempre verso fine mese, in modo da tenere sotto controllo il consumo di banda.

Il problema ricorrente delle dimensioni dei file Javascript e le AJAX Library API di Google

Se questi ultimi 2 punti sono stati volti a risparmiare quel fattore di banda invisibile e difficilmente monitorabile, ho deciso anche di intervenire, ancora una volta, su quella HTTP. Devo dire che, mano a mano che avanza lo stato di ottimizzazione del sito, affrontare il problema della banda, è un lavoro davvero certosino e occorre considerare diverse variabili prima trascurate e, non da ultimo, alcuni elementi nuovi (come l’installazione di nuovi plugin) che sono intercorsi dall’ultima analisi.

Tra questi troviamo anche un vecchio problema: i file javascript. Infatti, nonostante la precedente volta li abbia compressi più che mai, nel solo mese di Giugno, i soli file JS occupavano ben 8.96 GB di banda mensile!

Per risolvere parzialmente questo problema, ho pensato, quindi, di poter sfruttare le AJAX Library API di Google. In pratica, Google, recentemente ha messo a disposizione di tutti le maggiori librerie javascript e ajax compresse, linkabili direttamente dai loro server: jQuery, Prototype, script.aculo.us, Mootools e Dojo!

Centralizzando la distribuzione dei framework javascript e sfruttando le infrastrutture della rete di Google è possibile ottenere innumerevoli vantaggi: caching (utilizzando il medesimo URL per i file, c’è la probabilità che il browser dell’utente abbia già scaricato la libreria precedentemente), compressione Gzip/Minify, e file ospitati sui server veloci di Google e quindi riduzione del traffico generato dal proprio sito.

E’ possibile richiamare gli script all’interno delle proprie pagine utilizzando la classica sintassi:

<br /> <script src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js"> </script><br />

oppure con il metodo google.load(), che di fatto è molto più potente e performante, perché permette di indicare anche la versione desiderata della libreria:

<br /> <script src="http://www.google.com/jsapi"></script><br /> <script> google.load("prototype", "1.6"); </script><br />

Nel caso di script.aculo.us dovremo caricare anche prototype:

<br /> <script src="http://www.google.com/jsapi"></script><br /> <script> google.load("prototype", "1.6"); google.load("scriptaculous", "1.8.1"); </script><br />

Infatti, per garantire la compatibilità delle applicazioni, Google offre anche una serie di versioni diverse per ogni libreria Javascript e permette di specificare quella desiderata. Il versioning è, però, anche intelligente. Infatti, se si specifica una versione parziale della libreria (p.es 1.8), Google ci farà scaricare l’ultima release stabile di quella revision (p.es. 1.8.4), mentre se si specifica solo la versione “1″ allora lui scaricherà l’ultima disponibile, ovvero, la “1.9.1″.

Plugin per WordPress per le Google AJAX Libraries API

Se non volete mettere mano al codice della funzione wp_head() di WordPress per eliminare il riferimento al file prototype residente sul server ed inserire il link a quello residente sul server di Google, esiste un comodissimo plugin: Google AJAX Libraries API Plugin. Una volta attivato non farà altro che sostituire (con un add_filter()) il riferimento a tutti i framework gestiti con la versione ospitata sui server di Google.

L’unico svantaggio è che non usa la versatile funzione google.load() (che permette di puntare dinamicamente alla ultima release stabile) bensì il classico link diretto al file javascript. Ciò vi costringerà a tenere sotto controllo la versione di Prototype usata da WordPress e aggiornare di conseguenza il plugin (che ancora non è inserito nella Repository Ufficiale dei Plugin per WordPress) oppure modificarlo a mano.
Inoltre, non punta neanche alla versione compressa del file javascript, il che comunque non rallenta minimamente il caricamento della pagina.

Infatti, come è possibile vedere, eseguendo i test con i Pingdom Tools, usando la versione non compressa di Google abbiamo un peso di 123,2 KB (che comunque non influenza la banda del proprio sito) e un tempo di caricamento di 0.5 secondi

mentre usando la versione ospitata sul mio server, a fronte di un peso complessivo di 46,6 KB abbiamo un tempo di caricamento di oltre 1,2 secondi!

Disabilitazione di alcuni plugin

Inoltre, tra i file più letti ho trovato tutta una serie di plugin per i commenti:

• quoter.php (plugin: Quoter)
• ajax-comment-preview-js.php (plugin: AJAX Comment Preview)
• lmbbox-comment-quicktags.php (plugin: LMB^Box Comment Quicktags)

Ho deciso, quindi, in via del tutto sperimentale, di disattivarli (visto che comunque non sono essenziali per l’inserimento di un commento), per capire che influenza avevano sulla banda totale e sulla velocità del sito (monitorabile facilmente con i Pingdom Tools).

Disattivare Google Translator che non porta traffico utile ad Adsense

Al termine di queste mie analisi ho scoperto che un plugin che avevo installato stava producendo un aumento di banda non indifferente in maniera totalmente indiretta e difficilmente monitorabile: sto parlando del plugin per WordPress Global Translator, un tool per la traduzione automatica delle pagine nelle principali lingue sfruttando le API di Google Translator.

Infatti, da quando a fine Maggio lo avevo installato, il traffico proveniente dagli Stati Uniti è quasi raddoppiato, passando da 15.08 GB a ben 28.06 GB! Considerando che il mio sito è scritto in italiano, è facilmente intuibile che quel plugin aveva avuto il pregio di allargare la mia fetta di visitatori ad un pubblico che solitamente non mi leggeva.

Ma allora mi sono chiesto: il traffico in più proveniente dagli Stati Uniti era traffico utile e valido e poteva essere vantaggioso per il mio sito oppure era solo uno spreco inutile di banda? Il fatto che la traduzione automatica di Google non potrà mai rispecchiare fedelmente il testo scritto nella propria madre lingua, può portare gente realmente interessata a quello che dico o solo a visitatori passivi che incappano per errore nelle mie pagine? Devo dire che, per certe keyword specifiche, il mio sito risultava primo anche in lingua inglese, e ciò conferma il fatto che Google ha svolto un ottimo lavoro di indicizzazione delle mie pagine. Ma la mia esperienza con le pagine tradotte in automatico non è delle migliori, perché spesso non si riesce a cogliere il senso più profondo delle frasi ma solo una descrizione sommaria. E purtroppo non è questo quello che desidero dare ad un lettore!

Inoltre, per i più veniali, un altro indubbio svantaggio è che, a fronte di un raddoppio di banda usata e di pagine viste, ciò non portava ad alcun incremento degli introiti di Google Adsense che si attestavano sempre sugli stessi valori dei mesi precedenti. Questo capita perché, come ho potuto constatare, anche se la pagina risulta tradotta in inglese (o in qualsiasi altra lingua), i banner Adsense risultano sempre visibili in italiano, vanificando quindi il loro scopo perché nessun inglese cliccherà mai su una pubblicità scritta in un’altra lingua.

Quindi, a ragione, ho provvedduto a disabilitare la traduzione automatica del sito, sperando che, quando Google avrà tolto dal suo indice le pagine scritte in un altra lingua al di fuori dell’italiano, la quota mensili di banda consumata si possa attestare su valori ragionevoli.

Il problema della banda dei server italiani

Il problema dei server che risiedono in Italia è che la banda viene ceduta quasi a peso d’oro: un upgrade di soli 5 GB di traffico mensile mi viene a costare bene 42.00 € in più; considerando che, in teoria, avrei bisogno di almeno altri 20 GB di banda, il costo di gestione del mio sito lieviterebbe di oltre 120.00 €!
Capite bene perché, ogni 2-3 mesi, sono costretto ad ottimizzare al massimo le prestazioni del mio sito riducendo inutili sprechi! Spero che questa mia testimonianza possa essere utile a qualcuno che, come me, combatte quotidianamente con il traffico mensile.
Se poi avete qualche altra idea o suggerimento sono sempre disponibile ad ascoltarvi.

La rivoluzione della tecnologia touch di un iPhone o un iPod Touch è tale che, per forza di cosa, è stato necessario coniare un nuovo termine per i siti o gli applicativi dedicati a questa serie di dispostivi mobili: touch friendly, ovvero che sia compatibile col tocco delle dita, tipico della navigazione con i nuovi dispositivi di casa Apple.

Pochi pensano alla versione Touch Friendly del proprio sito

Purtroppo, nonostante esistano versioni mobili di molti siti, in pochi hanno realizzato versioni per iPhone, forse perché ancora considerato, ingiustamente, di nicchia. In realtà, visto che oramai è certo che già entro Giugno 2008 anche nel nostro bel paese approderanno ufficialmente gli iPhone, allora è bene familiarizzare con questi neologismi e iniziare a pensare a come realizzare diversamente i propri siti.
Infatti, se si analizza il traffico Web dei dispositivi mobili, si vede che una fetta consistente è costituito, appunto, da iPhone. E la ragione è una sola: navigare con Safari Mobile è una vera delizia poiché non è necessario alcun adattamento ed è possibile visualizzare la pagina perfettamente come la si vedrebbe con un pc (ad eccezione dei file flash che ancora non sono supportati).

Il problema del dito come dispositivo di puntamento

Ma dopo questa affermazione allora ci si potrebbe chiedere perché è necessario creare dei siti touch friendly? La ragione è semplice: è facile navigare su qualsiasi sito con un iPhone ma, spesso, visto che la risoluzione nativa dell’iPhone è di 320 x 480 pixel, per visualizzarne correttamente uno o per cliccare su qualche elemento, è necessario zoomare più volte con le dita. Cosa che di per sè è molto semplice ma, a lungo andare può risultare noiosa. Ecco perché il lavoro del webmaster dovrebbe essere rivolto ad adattare il proprio sito anche a questi evoluti dispositivi che, secondo me, presto invaderanno il mercato del mobile.

Lo screen dell’ iPhone visualizza infatti 160 pixels ogni pollice, e per utilizzarlo si usano le dita. Il problema è che, il dispositivo di puntamento di un iPhone/iPod non è un cursore o la freccetta del mouse, bensì esclusivamente le nostre dita! Se, quindi, si preme in un punto del display, lo spazio premuto sarà compreso tra i 40 e gli 80 pixels. Quindi, la prima regola base nella costruzione di un sito Touch Friendly è quello di distanziare due elementi selezionabili di almeno di 40 pixel, altrimenti l’utente che visiterà il portale tramite iPhone difficilmente riuscirà ad effettuare una selezione senza zoomare più volte. Per questo è sempre bene ingrandire i font e gli elementi della pagina, magari raddoppiandone le dimensioni; ad esempio, se si ha impostata la dimensione di un font a 18px, buona idea sarebbe portarlo a 32px.

Una delle caratteristiche più particolari dell’ iPhone è il supporto nativo alla “viewport“, ovvero quella funzione che permette di visualizzare solo uno spezzone alla volta di sito. Questo perchè le pagine web sono adattate alle dimensioni degli schermi da PC, mentre lo schermo dell’ iPhone è di dimensioni ben minori.
Per evitare, quindi, caratteri microscopici e selezioni impossibili, si è ricorso a questo stratagemma. Di default, aprendo una pagina web, la viewport è impostata per mostrare un riquadro del sito delle dimensioni di 980-pixel.

I kit IUI e WebApp.net per realizzare siti Touch Friendly

Se non volete impazzire col codice, allora vi consiglio di usare alcuni framework javascript per realizzare in pochi minuti un sito iPhone Style. Il primo a nascere fu IUI: User Interface (UI) Library for Safari development on iPhone, un progetto davvero interessante giunto alla release 0.13 ma che, dalle prove che ho fatto, è mancante di molti elementi di una pagina web.
Ho trovato, invece, molto interessante il fork di quest’ultimo progetto: WebApp.net. L’ho trovato molto più completo del primo e ho già realizzato un paio di siti in questo modo e devo dire che, nonostante qualche differenza sintattica rispetto ad IUI, e una volta presa la mano, è davvero semplice realizzare un sito Touch Friendly con WebApp.net, anche grazie al set grafico fornito di serie. Giunto alla versione 0.2.0 qui trovate una demo della sue potenzialità e qua sotto un video che illustra cosa è possibile fare con questo kit:

Qui, invece, trovate tutta la documentazione per iniziare (è ancora in fase di scrittura)

ATTENZIONE: Ovviamente su Explorer non è possibile visualizzare correttamente questo genere di siti, ma potete visualizzarli correttamente con Safari, Firefox e Camino.

I siti Touch Friendly e la mancanza di Wikipedia

Già esistono numerosi plugin per WordPress allo scopo, Meebo e Mundu, due servizi di messaggistica istantanea via web, hanno già pensato di creare una versione adatta allo scopo, ed è già è stata creato un client web per Twitter, Hahlo, Google Reader, ma Wikipedia, nonostante le dimensioni di questa comunità non ha ancora pensato a sviluppare una versione per iPhone.

Fin’ora si era solo pensato ad installare wikipedia sull’iPhone/iPod Touch per dare la possibilità a tutti di consultare l’opera offline senza necessariamente esser connessi ad internet. Il trucco stava nell’usare il programma Wiki2Touch e Scaricare il database di wikipedia in italiano da questa pagina (il dump è grande circa 2 Gb). Seguendo questa procedura è molto semplice, in pochi minuti, installare l’intera enciclopedia sui nostri dispositivi mobili.

Ma se noi volessimo semplicemente navigare su Wikipedia online con una interfaccia touch friendly? Allora dovremmo rivolgerci ad un prodotto di terze parti: iPodia. iPodia, infatti, grazie alla tecnologia Picklr Engine, rende l’enciclopedia Wikipedia ottimizzata per i dispositivi avanzati della Mela. In pochi tap di dito potrete selezionare la lingua e scrivere la parola da ricercare. Le pagine si adattano perfettamente al formato dello schermo e basta spostare il dito dall’alto verso il basso per leggerne il contenuto.

Spesso mi capita di sentirmi chiedere quali DNS inserire per la propria connessione Alice. Io di solito snocciolo quelli classici di Telecom Italia anche se l’ultima esperienza che ho avuto mi ha fatto propendere verso quelli OpenDNS. I vantaggi degli OpenDNS sono indubbi:

• Proteggono dal phishing: riconoscono automaticamente i siti “finti” che cercano di rubarvi soldi e/o informazioni.
• Sono veloci: grandi quantità di cache riducono la consultazione di molti server diversi.
• Correggono gli errori di digitazione: tutte le volte che sbaglio a digitare un indirizzo, OpenDNS cerca di capire dove avrei voluto veramente andare.
• Infine, un innegabile vantaggio per la privacy, è senza dubbio quello di riuscire a svincolare la propria connessione utente dal controllo, spesso invadente, dei providers.

Il sistema mantiene i propri costi di gestione in maniera molto semplice; quando ci si collega ad un sito inesistente visualizzerà una pagina pubblicitaria.

Indirizzi DNS Alice e Tin

Ecco i più comuni indirizzi DNS di Alice: se avete problemi di lentezza, latenza o di risoluzione domini (con il comando nslookup dominio.it potete accertarvi del problema), provate questi:

1. 212.216.112.112
   212.216.172.62
2. 194.243.154.62
   195.31.190.31

Indirizzi DNS OpenDNS

Questi, invece, sono gli indirizzi DNS di OpenDNS:

1. 208.67.222.222
   208.67.220.220

Confronto dei tempi di risposta tra DNS Alice e Open DNS

Premetto che queste non sono prove assolute e non hanno l’ardire di dare un responso univoco, ma sono relative solo alla mia connessione Alice. Ho notato, però, una certa lentezza di risposta al ping dei server OpenDNS rispetto a quelli Telecom Italia. Ora non so se ciò sia da imputarsi al fatto che la mia connessione è Alice o ad altro, ma sta di fatto che lanciando un semplice Ping (ping -n 10 -l 32 IP) dal mio computer, ottengo tempi di risposta nettamente inferiori a quelli OpenDNS.

Per essere più obiettivo possibile ho eseguito i test anche da un server che eseguiva i Ping ICMP via web (ma posizionato in Italia), come Visual Route, con 10 pacchetti da 32 byte l’uno (valore di default), e un’altra serie di test con il sito Network-Tools (posizionato in America).

Ecco i dati:

Ed ecco i risultati per i server OpenDNS:

Come vedete, qui in Italia, i tempi di risposta sono nettamente superiori per i server OpenDNS. Anche aumentando le dimensioni del pacchetto a 512 byte, i risultati non cambiano: 2 ms per Alice e 102 ms per OpenDNS.
Discorso inverso, invece, si applica se il ping si effettua da un server estero: gli OpenDns sono più veloci di quelli Alice.

Interpretare i risultati e conclusioni

Quel che è certo è che, di solito, in provider grandi come è quello di Telecom Italia, si può contare su apparati proprietari fin dalla centrale con la possibilità di dirottare il segnale dell’utente subito nelle loro reti con ovvi benefici sulle prestazioni.

Inoltre, come si vede dalla differenza di tempi di risposta tra un server posizionato in Italia (visualroute.it) e uno posizionato in America (network-tools.com) occorre tenere ben presente che questi test sono sempre influenzati dalla posizione geografica dei server DNS: quelli Alice sono in Italia, mentre quelli OpenDNS all’estero, in particolare sono presenti 5 in America e 1 in Inghilterra:

Palo Alto, California, USA
Seattle, Washington, USA
Washington, DC, USA
New York, New York, USA
London, England, UK

E’ noto che in Italia un ping medio gira al massimo intorno ai 50ms mentre per i server all’estero il ping aumenta (per esempio 90-120ms in Inghilterra e da 150ms in poi per l’America). Certamente un instradamento opportuno potrebbe portare a ridurre i salti (hop) migliorando di una certa percentuale anche i tempi di risposta, ma certamente un utente normale non ha molte possibilità in merito e le latenze geografiche sono un problema da affrontare.

Quindi, a quanto sembra, se cercate prestazioni, vi consiglio l’uso dei server DNS Alice, mentre se tenete alla vostra privacy, cercate la correzione automatica degli errori nei domini e un valido sistema di antipishing, allora i server OpenDNS saranno per voi.
Se poi, un giorno, metteranno qualche altro server OpenDNS anche in Italia, allora sarà indubbio che la scelta dovrebbe inevitabilmente ricadere su questi ultimi!

Al momento, per esempio, io uso i DNS Alice e all’occorrenza, in caso di problemi o latenze molto alte (per fortuna per ora molto rare), mi sposto su quelli OpenDNS (che sembrano fatti più per gli americani e gli inglesi che per noi italiani).

Nonostante il completamento automatico dei dati immessi nella aree di testo dei form su Internet Explorer o Firefox, sia molto utile per l’utente medio, c’è anche chi non lo vede di buon grado, perché lo vede come un rischio per la propria privacy. Infatti, la caratteristica di questa funzione è quella di memorizzare i dati immessi in precedenza sullo stesso form (o più specificatamente sui campi che hanno lo stesso nome) per poi suggerirne le corrispondenze, in base al testo digitato nel campo, in un elenco di voci in ordine alfabetico. E’ evidente che chiunque possa accedere fisicamente ad un pc, con un solo doppio click sul campo interessato, potrebbe in pochissimo tempo ottenere alcuni dati sensibili del precedente utilizzatore. Addirittura, dato che il completamento automatico memorizza i dati in base al nome che assume il campo nel form, siccome nel 90% dei casi un form di accesso ad una area protetta da password, avrà i campi con il nome, “username” e “password“, se si prova ad accedere ad un sito è molto probabile che è possibile imbattersi negli username di tutti gli altri siti che necessitano di autenticazione e che avranno lo stesso nome nel campo di immissione utente.

Disattivare il completamento automatico da Browser

Il problema, poi, si complica, se si memorizzano anche le password sul proprio browser, poiché chiunque potrebbe accedere (ovviamente solo se fisicamente presente) a tutti i siti.

Fortunatamente su qualsiasi browser esiste la possibilità di cancellare tutte le voci salvate in tutti i moduli o di disabilitarne definitivamente la funzionalità: se, però, questa soluzione vi risulta un po’ drastica è possibile anche rimuovere selettivamente una o più voci.

Disattivare il completamento automatico dei moduli da codice HTML

Ci sono però dei casi in cui si vorrebbe disabilitare la funzione nativamente e indipendentemente dalle scelte dell’utente che, spesso e volentieri, si dimentica di questi problemi di Privacy: è il caso per esempio dell’accesso ai servizi online bancari o ad altri siti con dati molto riservati per cui, sapere anche solo lo username, può costituire un grave pericolo.
Ma, più semplicemente, potrebbe essere anche l’esigenza di coloro che vogliano realizzare un completamento automatico via ajax dei moduli in grado di interrogare il server e di visualizzare sul client un elenco di informazioni filtrate in base al contenuto immesso nel campo della form.
Oppure, più banalmente, per un puro fattore estetico del webmaster che vorrebbe che la digitazione del testo nei campi sia pulita e ordinata.

Insomma, qualunque siano le vostre necessità, se volete disattivare l’autocompletamento nei vostri moduli direttamente da codice html, è sufficiente applicare agli elementi input di un form l’attributo autocomplete e impostarlo a OFF (visto che di default è settato l’attributo ad ON).

<br /> <INPUT TYPE="Text" NAME="Username" AUTOCOMPLETE="Off" /><br />

Se, invece, volete disattivare l’autocompletamento su tutti i campi del FORM (e non ad un solo campo del modulo) allora sarà sufficiente inserire l’attributo nell’elemento all’interno della dichiarazione del FORM:

<br /> <FORM AUTOCOMPLETE="Off"><br />

Non conforme alle specifiche W3C

Dovete però sapere che attualmente il metodo AUTOCOMPLETE non è uno standard del W3C, perché è ancora solamente presente nella bozza per l’HTML 5, in particolare nella sezione dei Web Forms 2.0.
In realtà, però, sebbene non sia ancora stato incluso ufficialmente negli standard W3C, tutti i principali browsers (Internet Explorer, Firefox, Opera, Safari e Camino) già lo supportano da molti anni, per cui, se si intende utilizzarlo, si ha la ragionevole certezza che funzioni ovunque, ma le pagine che conterranno questo attributo non saranno validate come conformi alle specifiche del W3C.