Windows Vista è ormai uscito da più di un anno; la curiosità insita nei programmatori avrà quasi certamente preso il sopravvento e, molto probabilmente, avrete installato Windows Vista.

Se non la avete fatto, peggio per voi ... e potete pure tralasciare la lettura di questo post perchè non vi serve assolutamente a niente.

Se invece avete installato Vista vi ritrovate con IIS aggiornato alla versione 7, che devo dire è veramente un gran bel gioiellino.

Non mi dilungo molto sui cambiamenti del nuovo web server Microsoft, sarebbero fuorvianti. Mi limito invece a quelle che sono le caratteristiche che ruotano attorno a quanto sto per scrivere. gli HttpHandler.

Un HttpHandler è del codice che - in base all'estenzione del file richiesto - si preoccupa di catturare la richiesta dalla coda di gestione ed eseguire / parsare il file secondo quanto l'handler è stato programmato, quindi restituirne l'output verso il context richiedente.

E' necessaria una premessa, che già il titolo dovrebbe portare all'attenzione dei programmatori più attenti. Mi riferisco alla modalità di esecuzione del worker process - ClassicMode - sopra menzionato.

Con l'introduzione di IIS 7, infatti, il nuovo server web ha subito dei profondi cambiamenti architetturali che in sintesi oggi ci offrono due modalità di esecuzione per l'Application Pool: il ClassicMode e l'Integrated Mode.

Fintanto che Windows 2008 non sarà ufficialmente commercializzato e adottato dagli hosting provider o installato sulla nostra macchina di produzione, purtroppo per noi il server web disponibile è ancora IIS6, che prevede solo la modalità ClassicMode.

Ne consegue che, allorquando decidiamo di sviluppare un nostro HttpHandler, e ovviamente lo testiamo con IIS 7, laddove avessimo la necessità di verificare che effettivamente il componente appena creato possa correttamente funzionare anche su IIS 6, prima di passarlo in produzione, dobbiamo testarlo nella modalità sopracitata.

Come fare?

Se abbiamo testato il componente su un sito web che girava in un Integrated Application Pool, dobbiamo per prima cosa dire al nostro sito di usare un Application Pool configurato con il ClassicMode.

Ovviamente non è tutto qui, magari.

Nella stragrande maggioranza dei casi, dato che con l'handler sarete andati a gestire una particolare vostra estenzione (ma questo succede anche se avete utilizzato una estenzione nota), mentre con IIS 7 è sufficiente mappare l'estenzione verso il vostro handler, con IIS 6 dovrete prima mappare l'estenzione sulla quale state lavorando affinchè passi per l'aspnet_isapi.dll (diversamente sarà IIS a prendersi in carico la richiesta e non sapendoci che fare con la vostra etenzione non mappata probabilmente vi restituirà una 404).

Sarà poi compito di Asp.Net fare il check dei vari handler installati e dirottare internamente la richiesta verso l'handler più appropriato.

E infine apportare una modifica al nostro file web.config per dire che quella determinata estenzione dovrà essere gestita dal nostro Handler (che dovrà, per IIS6 essere necessariamente un file compilato e messo nella Bin del nostro sito).

Con IIS 7, tutto questo non è necessario, l'Handler può essere direttamente una classe messa nella nostra App_Code e compilata al volo, che con una semplice mappatura che a questo punto cambierà di posizione (non più quindi in , ma in dove si specificherà a questo punto anche il path al quale il nostro handler deve rispondere) e tanto sarà sufficiente affinchè l'evento HttpApplication.MapRequestHandler possa dirottare la richiesta verso il nostro handler.

Approfondimenti

Per futura memoria di chi legge, ma anche per lo scrivente, lascio alcuni link utili sugli handler e sul life cycle di IIS 6 e 7:

1. ASP.NET Application Life Cycle Overview for IIS 5.0 and 6.0
2. ASP.NET Application Life Cycle Overview for IIS 7.0
3. Introduction to HTTP Handlers

Se vi trovate invece in panne con la migrazione di un Handler da IIS6 a ISS7, nel blog di Rick Strahl ci sono un paio di post interessanti:

1. Migrating an ASP.NET app to IIS 7
2. HttpModule and HttpHandler sections in IIS 7 web.config files

Dopo un precedente articolo sull'errore 404 lato SEO, oggi parlo dell'errore 404 lato ASP.Net e IIS. Il perchè bisogna configurarlo l'ho spiegato nell'articolo sopra citato, come configurarlo nell'ambiente Microsoft lo faccio ora.

Esistono due modi, complementari, per configurare l'errore 404 in ASP.Net /IIS6. Complementari perchè uno non esclude l'altro.

Data l'architettura del framweork, una volta che la richiesta giunge al server, questa a seconda dell'estenzione che il file richiesto ha, può subire un dirottamente all'interno della pipeline.

I file statici, quindi i file .htm e .html (ma anche i .css e tutte le immagin) verranno smistati automaticamente verso l'handler che si preoccupa di gestire i file statici (StaticFileModule), mentre i file con estenzione .aspx verranno gestiti dall'handler aspnet_isapi.

Dati questi due percorsi differenti, ne consegue che qualora venga inoltrata una richiesta per una risorsa non esistente sul server di destinazione, la risposta 404 procederà per due vie completamente distinte.

Quella dei file statici verrà inoltrata direttamente ad IIS, il quale ritornerà al client la pagina associata al codice di errore 404 configurata all'interno della proprietà del sito.

Di default viene restituita una pagina brutta e asettica come quella che si vede qui sotto, ma agendo nelle proprietà di configurazione del sito si può impostare un qualsiasi tipo di risorsa, anche appartenente ad un altro sito web.

Nel caso di una risorsa .aspx non trovata, le cose sono leggermente diverse.

A preoccuparsi di restituire una pagina d'errore è lo stesso framwork.

Ovviamente, di default, la gestione delle pagine non trovate non è abilitata, e nel caso viene mostrata una pagina d'errore (per alcuni) più criptica e sempre antiestetica.

Per poter abilitare la gestione delle pagine non trovate, in questo caso bisogna agire all'interno del file Web.Config, andando a creare, laddove non esista già, una sezione CustomErrors.

Un esempio può essere come quello qui sotto:

In questo caso, il framework reindirizzerà la richiesta verso il file statico 404.html. Nulla vieta di mettere una pagina con estenzione .aspx che faccia del lavoro per noi, tipo mandare une e-mail all'amministratore del sito, piuttosto che registrare degli eventi in un file di log, ecc.

Medesimo discorso vale anche per la configurazione del Custom Error statico. Impostando una risorsa di tipo URL si può specificare un percorso assoluto e rimandare il tutto ad una pagina dinamica, con il vantaggio che si potrà creare una sola pagina e gestire in entrambe i casi il problema della risorsa non trovata.

Dopo circa un anno di uso di SubText ho deciso di passare a miglior vita spostando tutti miei vecchi post sulla piattaforma DotNetBlog?

Perchè? Semplice ogni tanto bisogna cambiare, ma in primis perchè ormai SubText puzza di stantio, non vengono rilasciati aggiornamenti, è piuttosto chiusa come architettura, e non per ultimo un problema in fase di commentazione che un amico mi ha portato a far vedere sabato scorso, dove con IE non c'era verso di lasciare commenti (mi beccavo sempre un errore 500 che non sono riuscito a comprendere il perchè neppure guardando il log file).

Insomma Sabato notte ci ho fatto le 2:30 per fare la migrazione, perchè sfortunatamente la procedura di export dei post da SubText su formato BlogML non riusciva ad essere importata in DotNetBlog in maniera corretta.

Sono dovuto andare di query a manina!! Un lavoraccio pazzesco.

Nonostante avessi finito, non potevo rilasciare subito la nuova versione. C'erano alcune cose da fare ancora. Cose che in parte si sono sistemate dopo un riavvio del server. Per esempio l'errore 404 non veniva trappato e rispedito alla pagina aspx che se ne occupava, non c'era continuità con i link perchè l'autore di DotNetBlog per quanto ha detto di aver fatto un Url Rewriter in grado di catturare anche i vecchi link per SubText, in realtà io nel codice non vi ho visto traccia.

Insomma, tolta Domenica e tutto la giornata di ieri, oggi con qualche ora ho messo apposto quelle due o tre cose per farlo funzionare come mi aspettavo.

Come piattaforma, se facciamo un paragone con SubText, quella di DotNetBlog è per certi versi ancora indietro; ci sono molte molte cose che non mi piacciono, una per tutte per esempio l'impossibilità di avere più blog sotto lo stesso sito web.

Manca una link section, la gestione dei referer è veramente indecente. Insomma come tutti i prodotti c'è del buono e del cattivo.

Ma la cosa che più mi piace è l'archittetura estendibile che lo sviluppatore ha ideato, attraverso la quale si può scrivere un proprio componente, deployarlo dentro la cartella Extensions e il blog può utilizzare questa nuova caratteristica appena installata.

Apprezzo molto anche il migliore supporto della MetaWebLog API (quella che si usa con LiveWriter per capirci) che sotto SubText era veramente scarsa (niente aggiornamento della data di pubblicazione, niente categorie aggiungibili, ecc. ecc.)

Concludo con una ulteriore nota positiva per questo prodotto, al quale sembrano interessati molti bloggers che contribuiscono con idee e suggerimenti su CodePlex nel quale si trovano anche i sorgenti che il suo autore sembra mantenere con una discreta frequenza.

A parte tutto questo, mi sento però nel dovere di ringraziare l'autore di SubText, per avermi dato la possibilità tramite il suo prodotto di gestirmi il mio blog.

Quando si lavora ad un sito web può capitare di dover spostare una risorsa. In questi casi non c'è niente di meglio che dire a tutti quello che stiamo facendo, implementando un forwarding verso la nuova risorsa, indicando quindi al client che ne ha fatto richiesta che è avvenuto questo cambiamento. In parole povere, il server non dovrà far altro che caricare un'altra risorsa invece che quella originariamente richiesta dal client.

Se infatti non si procedesse con un forwarding verso una nuova risorsa, una richiesta da parte del client verso un URL non esistente ritornerebbe al client un codice di errore che sta indicare che la risorsa non è stata trovata. Questo codice il famoso 404, pagina non trovata.

Come procedere in questi casi?

Esistono tre modi per fare l'URL Forwarding in ASP.Net

1. Il Response.Redirect, che probabilmente i vecchi programmatori Classic ASP ricorderanno bene
2. Il Server.Transfer
3. Il Responde.RedirectLocation

Vediamoli nel dettaglio.

Il Response.Redirect è un metodo che il framework si trascina dietro sin da classic ASP 2.0 (a mia memoria, non ricordo l'1.0 se lo aveva, ma credo di ricordare di no). Con questo metodo, semplicemente si prende la richiesta corrente dalla pipeline e la si sposta su una nuova richiesta. La nuova richiesta (risorsa) potrà essere tanto una risorsa interna che una risorsa esterna. Quest'ultimo aspetto è da tenere in considerazione perchè ad esempio il metodo Server.Transfer non supporta reindirizzamenti esterni.
Tornano al nostro Redirect, un utilizzo intensivo di questo sistema è degradante, perchè questo discorso di aprire una nuova richiesta porta ad un overhead del server che alla lunga vedrà un calo di prestazioni. Chiaramente ci vogliono scenari distribuiti piuttosto complessi per potersene rendere contro.
Per questo motivo, con il framework 1.0 questo metodo è stato corredato di un overload che comprende un parametro boolean che serve ad indicare al metodo se persistere il thread corrente e lasciare che continui la sua esecuzione sebbene la pipeline sia stata dirottata o meno verso una nuova pagina.
In entrambe i casi, per via del fatto che all'interno del codice del framework viene fatta una chiamata al metodo Response.End, viene comunque sollevata una eccezione gestita dal framework, che non scatenerà errori nella vostra pagina, ma sarà sempre una sorta di anomalia.

Morale, evitare il Response.Redirect se proprio non se ne può fare a meno (Redirect verso un'altra risorsa). Utilizzare invece il metodo Server.Transfer, assai più performante. Anche il Server.Transfer è roba vecchia, nel senso che venne introdotto già a partire da Classic ASP 3.0, anzi fu una delle novità principali che io ricordi.
Il funzionamento è quasi simile al Redirect, per lo meno visivamente sembra uguale. La differenza sta nel fatto che mentre la Redirect richiede una nuova pagina, la Server.Transfer richiede l'esecuzione della risorsa e la restituisce sulla pipeline originale.
Attenzione al fatto dell'eccezione; se questo davvero vi preoccupa, sappiate che anche il Server.Transfer solleva anch'egli l'eccezione del Response.Redirect, perchè internamente fa una chiamata al metodo Response.End.

L'utilizzo di Response.End, Response.Redirect e Server.Transfer sollevano una ThreadAbortException. E' un prolema noto documentato dalla KB312629

Se davvero non volete avere di questi problemi dovete usare il metodo Server.Execute, che è lo stesso poi richiamato dal Server.Transfer, con la differenza che il Server.Execute non chiama alcun Response.End e vi restituisce il risultato dell'esecuzione della pagina chiamata, ovvero l'esatto output che avreste chiamando direttamente quella determinata pagina dal primo fino all'ultimo (ammesso che vi siano).

Sembrerebbe il metodo migliore, tuttavia vi sono casi specifici in cui il Server.Transfer non può essere utilizzato. Non sono in grado di elencarli tutti, ma per esempio uno lo posso documentare.

Oggi stato scrivendo un HTTPHandler per gestire un sito web che deve subire un processo di transizione da statico a dinamico, e facendo alcuno prove, mi sono reso conto che il Server.Transfer in questo processo di trasferimento parte dall'assunto che l'oggetto Page, con tutto quello che ne consegue, sia stato già correttamente caricato dal context corrente. In realtà, nel mio caso, agendo ancor prima che l'oggetto Page fosse stato creato, l'oggetto Session nel mio caso non esisteva, e ne risultava che la pagina a cui trasferivo la chiamata, facendo uso della Session mi generava un errore.

Non entro del merito del perchè. Magari un errore mio che comunque esula da questo post che si limita all'URL fowarding.

Come risolvere? Semplice, con un Response.RedirectLocation che non c'entrerebbe niente di per se con un trasferimento automatico verso una nuova risorsa, e infatti il suo compito è solamente quello di impostare l'HTTP Location header della pagina su di un nuovo percorso.

Senza fare null'altro questo sistema non serve a niente (non in questo caso di URL Forwarding). Se però aggiungiamo immediatamente dopo una impostazione dello StatusCode, cioè alteriamo il codice restituito al client, che normalmente sarebbe 200 - Ok, e lo impostiamo su un 302 - Risorsa mossa temporaneamente o un 301 - Risorsa mossa definitivamente, quando questo codice torna al client, il fatto che sia specificato un nuovo path, porterà il client ad effettuare una nuova richiesta verso la risorsa indicata.

Il tutto con una grande differenza, il thread precedente sarà stato correttamente chiuso, nessuna eccezione sarà stata generata.

Un esempio per essere più concreti:

A questo punto scegliere il sistema migliore è solo questione di analisi e capire quale sia veramente il sistema più adatto alla specifica esigenza sulla quale si sta lavorando.

Nonostrante la forte crisi dei mutui, delle ingenti difficoltà per arrivare a fine mese, una cosa che vedo che non manca a nessuno (o quasi) è un navigatore satellitare.
Voglia essere un dispositivo stand alone, un palmare, il software installato sul telefonino, nel bene o nel male oggi molti hanno avuto modo di apprezzare la possibilità di evitare strade inutili e lunghi percorsi e talvolta di trovarsi negli ingorghi di traffico.

Una delle cose più interessanti del navigatore è a mio avviso il POI, Point of Interest, ovvero un punto di interesse in una specifica località. Punto di interesse non significa esclusivamente monumento o chiesa, ma può essere anche un cinema, un parco giochi, un ufficio pubblico o un ristorante.
Quello che però non tutti forse sanno è che ognuno di noi, con un minimo di sforzo, potrebbe creare la sua lista di POI e condividerla con amici e parenti.

Ma come si crea un file POI?

In questo breve percorso vi illustrerò come farne uno per la diffusissima piattaforma TomTom (non ha importanza che versione) anche perchè possedendone uno, era l'unico con il quale verificare che il file generato fosse corretto.

Per prima cosa bisogna ricavare le coordinate di latitudine e di longitudine del posto che vogliamo usare come POI. Per farlo un sito che è di immediato aiuto è http://www.earthtools.org/ basato su Google Maps. Si potrebbe usare lo stesso GMap, ma dato che le coordinate non sono così appariscenti, per una volta evitiamo gli strumenti Google.

A questo punto si può procedere in due modi. Uno più tecnico e meno invasivo, perchè non richiede l'installazione di software, l'altro con un piccolo tool freeware che genererà il file per noi.

Il tool di cui sto parlando si chiama PoiEdit. Si scarica si installa (c'è anche una versione italiana per chi non mastica l'inglese), si genera un file e si salva il corrispettivo OV2 (che è un file di categoria), con un nome appropriato.

Proprio perchè si tratta di un file di categoria, meglio essere generici. Quando si nomina il file ricordarsi che gli spazi vanno creati con gli underscore (_) e che non vi sono caratteri accentati. Una volta creato il file, volendo si può associare una immagine, che dovrà essere di tipo Bitmap 24 bit, larga massimo 22x22 pixel.

Il sistema meno pratico, invece, consiste nel creare un file di testo con estenzione .asc, contenente molto semplicemente latitudine, longitudine e descrizione.

Es. 53.5000000 , 4.00000000 , "Ristorante Pino Grigio"

A questo punto, utilizzando il tool OV2Tools, si genera il file .OV2 e il gioco è fatto.

Copiando il file dentro la cartella del vostro dispositivo dove è presente la cartografia (es. \My Documents\Italy o \Storage Card\Western Europe), al successivo riavvio del TomTom avrete a disposizione anche voi il vostro POI personale.

Buona navigazione a tutti.

Technorati Tags: GPS,Navigatore satellitare,TomTom,POI

Va sempre più di moda aggiungere la favorite icon al proprio sito web. Esistono diversi programmi per generare icone. Alcuni indipendenti, altri come plug in di celebri programmi, ma a meno che non siate iconofoli (passatemi il termine) più di una icona difficilmente vi servirà. E anche ammesso che facciate siti web in maniera professionale, le icone generalmente sono qualcosa che non rientrano nel contesto grafico.

Allora, invece di investire soldi in applicazioni stand alone, suggerisco questo sito web che contiene il tool FavIcon from Pics, uno script in grado di generare un file .ico da uno di tipo jpg o gif. L'immagine di partenza deve essere un file 16x16 o massimo 32x32.

Si invia il file al server e immediatamente si salva il file .ico pronto all'uso.

For whom program in ASP.Net, since the first version you probably start to appreciate and contemporary hate the page’s StateBag, otherwise called ViewState. Without going through the particulars, to avoid loosing the article path, in few words the ViewState take care to serialize the content of the page variables into a string that is passed back to the next page request through a mechanism called PostBack.
The drama is that not all controls need ViewState, and often this persisting process is turned off to reserve memory and avoid unuseful server roundtrip.

Things changed when ASP.Net 2.0 framework has been released: a new method called ControlState was introduced for persistance. This method basically works as the ViewState, but first of all cannot be deactivated by the web page programmer, and it memorize only what is really needed (according to the override you will do in your code). Again, you can also decide for which control activate this repository and for which not.
Immediately should jumps in mind that you can even completely deactivate the ViewState and continue to be supported by the Control’s variable persistance without any matter.

That’s all true, but only in part!

So you are probably asking why I’m writing this if this isn’t the truth. As I said, it’s not true only in part. To correctly work, both ViewState and ControlState needs to embrace the PostBack technique. For whom don’t know what PostBack is, it's a small javascript function automatically added by the framework to the rendered HTML page that take care to collect every input control’s value and to submit them to the same page through a server call. This let you restore value on the next page load for following elaboration.

Now, suppose just for a moment - as it was in my case - while I was developing a control to have a limit where you cannot use Javascript (without worrying why). What happen in this case? No javavascript = no PostBack. And then?

To avoid this kind of problem I had to use an alternative way to persist my control’s value, based always on the serialization, but persisting values in the Session object.

The serialization is the process of saving an object into a storage medium (such as a file or a memory buffer) and to transmit it across a network request.

In this way, with a couple of if inside the code, and using the same execution path used by the ControlState, I finally successfull persisted my control’s value without using PostBack.

Below an abstract of the code I used.

First of all I created a serializable class that you need both you want to persist values in a traditional way and with Session method.

You then add a condition if you want to use the ControlState mechanism or not. This can be done in the OnInit method of our control.


It's now necessary to add the alternative storage path in the PreRender override. You shouldn't do anything for the ControlState since you are obliged to override the SaveControlState method.

if (PagingMode != PagingModeEnum.Postback)
  this.SaveControlStateInSession();

Finally paste the code that will perform the persistance above used.

///

The above function use the LosFormatter class that is an hidden class of the System.Web.UI namespace, used by the framework for the serialization process of the page ViewState and of the famous hidden form field __VIESTATE.

Finalmente il primo Service Pack per Windows Vista è disponibile (almeno per gli abbonati MSDN). Il Download non è stato dei più brillanti, 130Kb al secondo, quindi quasi due ore e mezza per farmi 1,3 GB di pacchetto.

Erano le 16:00 di ieri pomeriggio, ma dovendo poi uscire ho rimandato a questa mattina l'installazione. Primo approccio necessario: la calma.

E fidatevi, ci vuole tutto quel tempo. Se infatti dopo circa 25 minuti di spacchettamento magari pensate di aver finito, non avete fatto i conti con il successivo riavvio che se ne piglia circa altri 30-35 minuti di tempo.

Fortunatamente hanno introdotto un indicatore percetile di progressione di installazione, che sebbene non sia il massimo, almeno vi dà l'idea che qualcosa stia realmente accadendo.

La prima cosa poi, che ho avuto modo di provare nell'immediato è stata quella del Desktop Remoto, che ultimamente su una installazione fresca di Vista mi stava dando non poche noie. Non colgo cambiamenti di performance o altro, non in un primo impatto, ma qualcosa sicuramente è stato toccato anche qui. Infatti ecco come si presenta ora la maschera di login per una connessione precedentemente impostata.

Al momento non ho avuto modo di provare altro, quindi mi riservo di aggiungere commenti a questo post mano a mano che avrò modo di apprezzare (o odiare) le fix di questo SP.

Techspansion aggiorna alla versione 1.31 VisualHub, il suo software per la conversione di video su Mac.

La nuova versione presenta le seguenti caratteristiche:

• Veloce conversione da quasi ogni formato video per iPod, PSP, DV, DVD, Tivo, AVI, MP4, WMV, MPEG e Flash.
• Converte qualsiasi file in tre fasi: click, trascina, click.
• Fino a 18 ore di video su un DVD. Possibilità di guardare il video su qualsiasi lettore DVD.
• Supporta Xgrid. Utilizza la potenza di ogni Mac in rete per la codifica.
• Non sono richiesti QuickTime Pro o speciali plugin.
• Sono supportati DivX / XviD AVI, tutte le varianti di video MPEG e molti altri formati.
• Elaborazione di più file. Salvataggio consentito nella stessa cartella o in una cartella diversa.
• Pannello delle impostazioni avanzate veramente completo che permette di modificare ogni aspetto della codifica.
• Anteprima dinamica - Vedi i risultati prima di iniziare una lunga codifica.
• Permette di unire più video.
• Guida utente altamente dettagliata.

Il software, in formato Universal Binary, è a pagamento, ma poco più di 23 dollari possono essere giustificati per tutto quello che questo software fa.

Misurare gli accessi ad un determinato sito web, visto sotto un profilo SEO / SEM non può che aiutare la controparte che lavora sul sito a rendersi conto di quanto egli stia o non stia lavorando bene (e ovviamente aiuta anche il cliente a rendersi conto degli accessi che riceve e di conseguenza si rende conto di come le cose migliorino tendenzialmente con il tempo).
Tendenzialmente sarebbe più corretto dire che le statistiche dovrebbero interessare in realtà solo l'aspetto SEM di un sito, ma sovente - per lo meno qua in Italia - dato che le due figure tendono a miscelarsi uniformemente, tali analisi vengono compiute dalla stessa identica persona.

Sapere chi è entrato, da che parte del mondo, quanto tempo è rimasto ... serve a capire i nostri utenti, capire se il nostro sito soddisfa le loro esigenze, capire in cosa possiamo migliorare il sito ecc. ecc.

E' quindi di vitale importanza rendersi conto - con strumenti appropriati - quali e quanti risultati il vostro sito web ottenga. Questo genere di confronti, in buona misura, si possono fare utilizzando un software di statistiche che legga i cosiddetti RAW log files, ovvero i dati di accesso che il server web registra ad ogni singola chiamata da parte di un referral cioè di un riferimento voglia esso essere un crawler/spider piuttosto che un utente singolo.
Ovviamente esistono anche dei servizi di statistiche si appoggiano su del codice javasript inserito nelle pagine web che compiono lo stesso identico lavoro:  l'aggravante in questo caso è  però quella di avere un processo di caricamento della pagina più lungo, piuttosto che una attendibilità dei dati non sempre completa laddove il visitatore non supporti o non abbia abilitato il codice javascript. Ne consegue che questo genere di strumenti lascia il tempo che trova, sebbene siano parimenti completi a quei software di statistica che analizzano i log files: un esempio di quest'ultimi software javascript based lo abbiamo con l'ormai celebre Google Analytics, basato sulla versione 5 del popolare Urchin.

Indipendentemente dal sistema di analisi utilizzato, vorrei aggiungere una nota che probabilmente qualcuno potrà contestare. Recentemente ho letto di un post che sbandierava ai quattro venti il collegamento dove le statistiche di un dato blog erano posizionate e sul quale semplicemente entrandoci sopra si poteva visualizzarne il contenuto.
Non voglio con questo colpevolizzare l'autore del post (che chiariamoci non ha fatto nulla di illecito, semmai è il gestore del blog che ha  peccato lasciando in bella evidenza l'iconcina dove poter reperire tali dati), ma per il mio modo di vedere le statistiche di un sito sono un dato personale che dovrebbe essere visionato esclusivamente dal proprietario del sito e dal suo SEO/SEM manager; non dovrebbe quindi essere un dato di pubblico dominio.
Questo perchè dalle statistiche si possono, come già detto sopra, desumere i comportamenti degli utenti verso un particolare sito e il suo contenuto e con i dati di accesso alla mano si può - volendo - anche cercare di replicare le medesime strategie adottate dal sito di cui si stanno visionando le statistiche al fine di catturare parte dell'interesse di quei visitatori, dirottando magari parte del traffico. Non sto qui a spiegare ne come si possa fare, ne perchè lo si voglia fare, ma in uno scenario attuale quale quello di Internet, dove gli illeciti e le truffe, il forging e lo spam sono all'ordine del giorno, onestamente nutro qualche serio dubbio che in situazione di estrema competitività questo non possa non avvenire.

Analizziamo le nostre statistiche

Le statistiche spessono offrono una tale vastistità di dati (o al contrario per alcuni software gratuiti potrebbero offrirne talmente tanto pochi) che spesso non è facile orientarsi su cosa sia più appropriato tenere in considerazione.

Sintentizzando, l'elenco qui sotto proposto, sono le parti che personalmente ritengo più essenziali. Per ognuna cercherò di dare un abstract su cosa il dato rappresenti.

• Numero di visite
• Pagine viste
• Numero di conversioni
• Provenienza dei visitatori
• Parole chiave utilizzate nella ricerca
• Tempo medio di permanenza

Numero di visite

Una visita inizia nel momento in cui un utente entra per la prima volta all'interno del sito e finisce nel momento in cui lo abbandona o nel momento in cui la pagina web rimane aperta per un periodo troppo lungo senza che venga movimentata (generalmente 20 minuti).
Questo mette in luce un aspetto spesso sottovalutato di alcuni siti che usano il meta tag refresh per aggiornare la pagina (coscenziosamente o meno è un'altra storia) che in questo modo falsano le statistiche.

Al di là di questo, guardando al trend delle visite si capisce immediatamente l'impatto complessivo dell'attività di SEOing condotta, a cui però non bisogna dimenticare di sottrarre l'eventuale fattore ciclico dei periodi stagionali. Ad esempio un sito web di un agriturismo potrà riscontrare picchi di visite nei periodi di festività o quando coincidono i periodi di ferie globali (luglio-settembre, dicembre-gennaio), mentre magari un sito che si preoccupa di progettazione giardini avrà dei picchi nei momenti della pre-semina (marzo-giugno o ottobre-novembre).

Isolare il numero di visite, ovvero saper distinguere da utenti attirati dal momento di picco o da utenti attirati da una particolare condizione impartita dall'attività di SEOing può a volte essere fondamentale. Ma questo non si può sempre fare, in particolar modo se non si lavora per l'indicizzazione di parole chiave che possano in qualche modo essere collegate all'attività, ma per questo fuori dal contesto del picco stagionale.
Un esempio: riferendoci all'attività turistica, se mettiamo che un hotel stia in riva al mare e indicizziamo per hotel abruzzo mare sarà chiaro che nel momento di picco il numero delle visite si andrà ad amalgamare. Se invece indicizziamo per evento per la ricorrenza di ... per un hotel in abruzzo sul mare, non molto distante dal luogo della ricorrenza e quindi utilizzabile come base d'appoggio, sarà sicuramente più semplice scernere le due tipologie e numeri di visite.

Pagine viste

Nel momento in cui viene fatta una richiesta ad un server web ed inizia il download di una pagina, questo dato viene registrato nei log files. Attenzione a non confondere però, quando si guardano le statistiche, il numero di pagine viste (Page view) con il numero di files scaricati (Hits).
Ogni file infatti è costituito da una o più risorse (immagini, file audio, codice javascript, css) e queste vengono contate separatamente e in aggiunta alla pagina stessa.
Questo dato è utile per capire in linea di massima (e a seconda della tipologia di pagine viste che si sta consultando, perchè alcuni software di statistiche offrono diverse proiezioni di questo dato) l'interesse generale verso il vostro sito.
Per essere più chiari: se il numero di visite coincide (o vi è uno scostamento minimo) con il numero di pagine viste, è chiaro che il vostro sito non interessa, perchè il visitatore che è entrato, quasi subito non è stato attratto dal contesto proposto ed è scappato. Il perchè sia scappato, può essere ricondotte a diverse ragioni (una landing page mal progettata, un sito web poco accattivante dal punto di vista grafico, ecc.).
Diversamente vuol dire che l'utente ha trovato - presumibilmente - quello che gli interessava e ha proseguito nella navigazione e qusto ci introduce al prossimo aspetto.

Numero di conversioni

In realtà non tutti i sistemi di statistiche offrono questo dato, anzi direi proprio che a parte Analytics nessun sistema che io conosca è in grado di offrirlo. Anche perchè, a dire il vero, la conversione è capire quando la visita di un utente si trasforma in qualcosa di concreto. E nella stragrande maggioranza il punto di conversione è una richiesta di contatto (nei siti di e-commerce è un'acquisto). Ma anche Analytics non è in grado di gestire scenari piuttosto complessi di punti di conversione, quindi queto è un dato che va ricavato. Come?

Prendiamo l'esempio precedente. L'agriturismo: supponiamo un periodo morto, vediamo 50 visite, 70 pagine viste. Togliamo - se non lo abbiamo fatto - il numero delle visite dei motori, supponiamo 10, quindi rapido cacolo una media di 1,75 pagine viste a visita (veramente basso come valore).
Di queste pagine viste, 15 risultano essere alla pagina con i contatti, quindi una percentuale di conversione del 4,6% che tradotto in richieste utente, significa che di quei 40 visitatori (10 erano gli spider) 8,6 sono stati attratti a tal punto da andare a finire nella pagine dei contatti.
I numeri sono inventati in questo caso, quindi non corrispondono a nessun caso reale, ma tramite questo sistema e raffrontando poi le e-mail ricevute, piuttosto che il numero di telefonate, si ha un'idea di quanto l'attività di seoing svolta porti risultati.

Provenienza dei visitatori

Altrimenti chiamato in inglese Referrals, ovvero la provenienza in termini di risorsa web, quindi non una provenienza geografica. Sapere in sostanza da che sito web il nostro visitatore è arrivato.

Maggiore sarà il numero di visitatori che arriva dai motori di ricerca, migliore è l'attività di SEOing svolta. Si ponga però l'attenzione a scernere i visitatori che arrivano da canali PPC piuttosto che dal motore per ricerca naturale.
A questo dato va comunque aggiunto e considerato il numero di visitatori che arrivano comunque dagli altri siti, laddove la risorsa l'avranno presumibilmente trovata perchè il SEO manager si sarà adoperato per stringere una serie di s cambi link con altri webmaster o attività analoghe.

Se poi vogliamo tenere in considerazione la provenienza geografica, con questo dato possiamo avere un'idea della nazione di origine della richiesta. Se vediamo che abbiamo un dato piuttosto elevato di richieste da stati esteri, ma il nostro sito non è tradotto in lingua, forse sarebbe un buon segnale avviare un processo di traduzione del sito per catturare anche l'interesse di quei visitatori (che sebbene possano usare traduttori automatici, sarebbero assai più avvantagiati dal trovare il testo tradotto direttamente nel sito. Questo a patto che sappiate parlare la lingua e in grado di dialogare con il visitatore in caso di bisogno).

Parole chiave utilizzate nella ricerca

Un altro aspetto da visionare è l'analisi delle parole chiave che il visitatore ha utilizzato durante la ricerca. Questo vale sostanzialmente per i motori di ricerca. Analizzare questo dato è fondamentale per capire se la scelta delle parole chiave è stata valutata bene o meno. Una distribuzione media degli accessi tra tutte le parole chiave vuol dire che l'analisi e gli sforzi del seoer sono sufficienti, di contro qualcosa è andato male.

Peggio se poi, tra la lista delle parole chiave non ne figura qualcuna. Vuol dire che quella data parola non è completamente e correttamente associata al sito internet indicizzato e quindi sono richiesti degli interventi immediati.

Tempo medio di permamenza

Quanto tempo - generalmente minuti - i nostri visitatori sono rimasti. Tra una richiesta di una pagina e l'altra, oltre all'indirizzo IP del client che ve ne fa richiesta viene tracciato anche il momento della richiesta stessa. Quando non vengono più tracciate richieste per quell'IP si potrà sapere quanto l'utente è rimasto sul sito. Ovviamente i sistemi di statistiche non danno un dato riferito al singolo visitatore, piuttosto in una data fascia di tempo dicono quanti visitatori ci sono.

Generalmente più il numero dei visitatori è alto rispetto ad un valore di permanenza basso e peggio è.

Tuttavia non tutti i sistemi di statistiche offrono questo tipo di dato. Alcuni danno molto più semplicisticamente un valore ATOS (Average time on site) mediano per giorno o per settimana. Cioè sommano tutto il calderone e poi dicono un valore unico.
Non mi piace questo modo di rappresentare il dato, ma se il software di statistiche in compenso offre diverse altre proiezioni e viste di dati, tutto sommato ci si può anche passare sopra.

Con questo concludo questo post e mi auguro di aver chiarito i dubbi degli utenti che mi hanno scritto per avere un parere.