Applicazioni web e encoding

Applicazioni web e encoding

Chi, sviluppando applicazioni web, affronta per la prima volta il problema di rendere la propria applicazione utilizzabile da persone che utilizzano lingue non basate sull’alfabeto latino, si scontra inevitabilmente con problemi legati all’errata interpretazione degli encoding dei caratteri.

Un’applicazione web coinvolge differenti ambienti, ognuno dei quali dotato di un proprio encoding/charset. In particolare bisogna dialogare con:

• l’encoding utilizzato dal filesystem del server
• l’encoding con cui lavora il server web
• l’encoding dichiarato nelle pagine
• l’encoding che utilizza il browser
• l’encoding con cui si accede al server di database (o alla base di dati memorizzata)
• l’encoding con cui il server di database memorizza le informazioni

In questa pagina è riassunto il comportamento per le applicazioni PHP che utilizzano Apache su di un server Linux e PostgreSQL come server di database. A tal fine si precisano i seguenti aspetti:

• PostgreSQL memorizza su filesystem i dati nell’encoding specificato alla creazione del database.
• Ogni client di postgres (es. pgsql) può definire l’encoding in cui le query vengono scritte o i dati restituiti. La stessa cosa vale per la libreria PHP di accesso a PostgreSQL utilizzando pg_set_client_encoding
• Le stringhe PHP hard coded sono nel charset del documento, ovvero quello definito dall’editor durante la redazione della pagina PHP
• I dati che arrivano dal browser sono convertiti dal browser stesso nell’encoding della pagina.

Sulle ultime installazioni di Linux PostgreSQL crea di default i DB in UTF-8, pertanto è fondamentale specificare l’encoding da usare nella connessione al db se le pagine (come redatte e come dichiarate) non sono in UTF-8.

Impostazione dell’encoding nelle pagine

Salvare le pagine sul filesystem

Per questo primo problema la soluzione è semplice: le pagine vanno scritte utilizzando lo stesso encoding che viene dichiarato in HTML. Questo è fondamentale per far sì che i caratteri digitati nella pagina vengano visualizzati correttamente e, soprattutto, senza essere obbligati a utilizzare funzioni di conversione.

Comunicazioni tra browser e server web

Per ogni pagina vi sono 2 encoding che vengono presi in considerazione dai browser al fine di decidere il corretto set di caratteri da utilizzare:

• L’encoding precisato negli header
• L’encoding dichiarato tramite il tag meta

In mancaza di header specifico Apache imposta in automatico l’header in base al tag meta della pagina. In ogni caso Apache può essere forzato a indicare un encoding predefinito indipendentemente dal tag meta specificato utilizzando la direttiva AddDefaultCharset. E’ pertanto consigliato specificare sempre l’header nella pagina tramite la direttiva PHP:

header("Content-type: text/html; charset=");

Dati inseriti dall’utente

Il browser converte automaticamente i dati inseriti dall’utente nell’encoding della pagina. E’ tuttavia consigliabile specificare l’attributo ACCEPTCHARSET sui form in quanto, come specificato dalla stessa Microsoft, il comportamento del browser potrebbe essere imprevedibile:

If the this attribute is not specified, the form will be submitted in the character encoding specified for the document. If the form includes characters outside the character set specified for the document, Microsoft Internet Explorer will attempt to determine an appropriate character set. If an appropriate character set cannot be determined, then the characters outside of the character set will be encoded as an HTML numeric character reference. (…) If the user enters characters that are not in the character set of the document containing the form, the UTF-8 character set will be used. UTF-8 is the preferred format for multilingual text.

Impostazioni in PHP

Le connessioni al database vanno impostate con l’encoding corretto in modo che i dati forniti vengano convertiti nel formato previsto dal server di database per la memorizzazione su filesystem.

In ogni pagina bisogna, pertanto, precisare la direttiva pg_set_client_encoding per la connessione al database.

Bisogna fare attenzione al fatto che, in sua mancanza, l’applicazione funzionerà correttamente in quanto i dati memorizzati vengono ripresi nello stesso formato. Accedendo, però, direttamente al database con una console, le informazioni inserite saranno completamente errate e non modificabili.

Note su alcune funzioni PHP

Fino a PHP5 molte funzioni PHP lavorano esclusivamente in ISO-8859-1. Se si utilizza UTF-8 è meglio verificare il comportamento di ogni funzione che lavora con le stringhe.

In particolare:

• non funziona strlen. Usare come workaround strlen(utf8_decode($str)).
• htmlspecialchars presuppone che la stringa sia in ISO-8859-1. La cosa non dovrebbe causare problemi con encoding differenti, ma nel caso è meglio precisarlo con i parametri aggiuntivi della funzione (htmlspcialchars($str, ENT_COMPAT, “UTF-8″))
• Alcune funzioni di ricerca potrebbero non trovare le corrispondenze. Per le ricerche, in particolare con espressioni regolari, si consiglia di utilizzare preg_match con l’opzione /u (altrimenti anche questa lavora in ISO-8859-1). La seguente, ad esempio, verifica che una stringa sia lunga al massimo 10 caratteri utilizzanto UTF-8.
  preg_match("/^\w{,10}$/u", $string)

Conclusioni

Spero che le informazioni fornite siano utili per risolvere problemi di conversione che, spesso, fanno perdere una grande quantità di tempo.

AddDefaultCharset

La fine delle applicazioni web?

In questo post cercherò di ripercorrere la storia delle applicazioni web attraverso le mie esperienze personali fino a fare un ragionamento su quello che potrebbe essere il loro futuro.

I primi passi

Nel 1998 lavoravo alla mia tesi di laurea realizzando il prototipo di un’applicazione web per la gestione documentale.

All’epoca ci si poteva connettere ad Internet con dei modem a 29K (o a 56K se si era già disposti a spendere) e potete immaginare quanto fosse difficile spiegare i vantaggi delle applicazioni web agli amministratori delle aziende.

La tecnologia utilizzata si basava su Netscape Fasttrack Server e sul linguaggio Javascript Server Side.

Nello stesso anno Microsoft annunciava l’Option Pack di Windows NT 4.0: una serie di strumenti aggiuntivi per il sistema operativo server che introduceva il supporto delle Active Server Pages: il primo passo di quella che, anni più tardi, si sarebbe concretizzata nella “guerra dei browser”.

Dall’intranet a Internet

Pochi mesi dopo realizzavo un progetto di gestione distribuita di anagrafiche.

La conoscenza di Internet da parte del pubblico non era molto cresciuta, ma la posta elettronica stava lentamente diventando un fenomeno di massa. Parlare di applicazioni web era meno difficile e gli sguardi erano simili a quelli che si ottengono adesso cercando di introdurre i concetti di Enterprise 2.0: “bello, ma per il momento non mi serve”. All’epoca un forte aiuto iniziava ad essere dato dai servizi di internet banking, rigorosamente accessibili solo con connessione telefonica dedicata verso la banca.

Le tecnologie utilizzate questa volta sfruttavano Linux e il mondo open source attraverso Apache, Mini SQL (mSQL) e w3-msql, un’estensione cgi che permetteva di realizzare una ben poco potente programmazione server side.

Anni luce indietro rispetto al Javascript della Netscape, ma con vari vantaggi tra cui:

• supporto per un database relazionale
• nessuna necessità di compilazione del codice per la sua esecuzione
• strumenti liberi e gratuiti

L’era moderna

Nello stesso periodo PHP veniva rilasciato nella sua versione 3: ancora uno strumento grezzo, ma già più avanzato di w3-msql.

Con la versione 4 di questo prodotto inizio, verso la fine del 2000, quello che è il primo progetto di livello “enterprise” in questa tecnologia.

Si tratta di nuovo di un sistema di gestione anagrafica completato da un sistema per la gestione dei dati aziendali che consente di tenere traccia dei compiti da svolgere.

In questi anni Internet è ormai diventato un fenomeno di massa e le applicazioni web, oltre grazie ai già citati siti di internet banking, sono portate al pubblico attraverso i siti di e-commerce.

Un nuovo look

Il primo sistema di Webmail è stato fatto da un italiano (l’ho scoperto su wikipedia scrivendo questo articolo!) nel 1995. Solamente con la diffusione su larga scala delle e-mail gratuite, tuttavia, questo strumento raggiunge il grande pubblico.

Esso è visto come un accessorio utile per le emergenze, ma nel 2004, con GMail, Google compie il grande passo e lancia quella che è la prima web application che riesce ad imitare l’interattività con l’utente propria delle applicazioni per desktop.

Questo passo dà la spinta finale a questa tecnologia e nei mesi seguenti diventa il modo principale in cui le nuove applicazioni devono essere sviluppate:

• accessibili da ogni parte del mondo
• senza bisogno di installazioni sui computer
• con una completa gestione dei dati sul server
• utilizzabili con un semplice browser

Il presente

Mentre il mondo si trova sommerso dallo tsunami delle web application, il fronte dell’onda si è già spostato e inizia ad interrogarsi sul futuro di questa tecnologia.

Il vantaggio dell’utilizzo da qualsiasi pc non è più sufficiente. Il mondo adesso vuole poter utilizzare le informazioni dal proprio programma preferito o dal proprio dispositivo preferito.

Se sto ascoltando la musica con un media player voglio poter accedere alle informazioni sulla canzone che sto ascoltando direttamente cliccando sul titolo e non passando da un browser.

Se sono in auto il mio navigatore deve essere in grado di prelevare le informazioni sul traffico, magari calcolate automaticamente in base a informazioni fornite dai navigatori di altri utenti, direttamente e ripresentarmele nel formato grafico più utile o utilizzarle per ricalcolare la strada in base ai suoi algoritmi interni.

Se utilizzo il mio frigorifero, voglio che sia in grado di ordinare i prodotti mancanti senza obbligarmi a connettermi ad un sito internet, ma semplicemente scegliendoli da una lista (questo è forse un po’ futuristico, ma neanche troppo: in fondo con i film si può già fare…).

In quest’ottica i siti web sono già uno strumento antiquato e il futuro pensa ad un web basato sui web services e sulle informazioni semantiche. Uno scenario che non lascia molto spazio alle interfacce utente avanzate realizzate con Javascript e AJAX.

I primi passi in questa direzione sono stati già compiuti e possono essere visti in vari esempi:

• un sistema di social bookmarking come del.icio.us avrebbe ben poco successo senza un plugin che permette l’utilizzo direttamente da un browser
• database musicali come CDDB sono già utilizzati da anni dai media player o da cd ripper per recuperare informazioni su cd e canzoni
• le api di programmazione che consentono di integrare funzionalità dei site web 2.0 nei propri programmi si sprecano (per un elenco basta consultare Programmable Web)
• i sistemi di webmail, malgrado la loro diffusione, non soppiantano i client di posta tradizionali e gli applicativi come Google Office sono ben lontani, come percentuale di mercato, anche da comprimari come OpenOffice
• questo stesso sito ha vari plugin per Firefox che mi consento di effettuare le operazioni più comuni senza accedere direttamente al sito

Una struttura per il futuro

La struttura applicativa 3-tier che ha dominato il web in questi anni, si evolve in una nuova struttura in cui il data e l’application tier rimangono sul web server, mentre il presentation tier migra sul client, sempre più spesso realizzato con strumenti di programmazione tradizionali o come plugin per programmi già esistenti. L’interfaccia web diventa uno dei possibili canali, ma sempre più quello di riserva o da utilizzare per operazioni straordinarie non altrimenti previste.

In quest’ottica, mi piacciono molto le tecnologie che consentono di realizzare plugin per i browser. Questi programmi sono multipiattaforma, facili da installare e aggiornare (i browser offrono meccanismi automatici per tenerli aggiornati) e, per loro stessa natura, fortemente orientati al web.

Neanche da dire che il prodotto più maturo, al momento, è XUL, il linguaggio su cui si basa la famiglia di prodotti di Mozilla (Firefox, Thunderbird, Sunbird, …).

Chissà che la miriade di toolkit Javascript che si stanno diffondendo in questi mesi non siano destinati ad una fine ben più rapida del tempo che stanno impiegando per raggiungere la maturità.

XWCM – XML Web Content Management

Un sito web2.0 è, prima di tutto, un sito e, come tale, ha bisogno di un sistema di gestione dei contenuti che faciliti la redazione delle pagine agli autori e permetta agevolmente di apportare variazioni grafiche globali.

Questo, però, non è il solo motivo per cui oggi parlerò di un CMS. Il motivo reale è legato al fatto che tale sistema rappresenta il mio primo progetto open source rilasciato sotto una licenza libera.

Descrizione

XWCM nasce nel 2006 come progetto interno della mia azienda, Logic, per realizzare un motore di CMS che consentisse la massima libertà di personalizzazione delle pagine.

Questo sistema doveva rispettare le seguenti caratteristiche:

• permettere una separazione netta tra grafica e contenuti
• gestire la struttura del sito in modo da mantenere un sistema di menu coerente e uniforme
• permettere la gestione di siti in più lingue senza richiedere necessariamente una struttura identica tra le varie lingue
• richiedere la quantità minima di pre-requisiti tecnici e, in particolare, evitare di appoggiarsi ad un database relazionale
• i contenuti sono redatti da sviluppatori web dotati di accesso diretto ai file del sito (tramite FTP o altro) e, pertanto, un’interfaccia grafica di gestione non è tra le priorità

Al fine di semplificare la parte di gestione dei template, che si sarebbe potuta rivelare ardua partendo da zero, si è scelto di utilizzare XSLT e basare tutti i contenuti su XML.

Per ulteriore semplicità di gestione dei contenuti e per poter facilmente utilizzare editor esistenti per la redazione degli stessi, si è scelto di basare i contenuti stessi su file XML redatti rispettando la sintassi del XHTML.

Il sistema ha rapidamente raggiunto una versione stabile e completa di tutte le caratteristiche necessarie e in questi giorni Logic ha deciso di concedermi il permesso di rilasciarne il codice sotto una licenza libera.

Questa scelta è stata dettata dal desiderio di migliorare il sistema e completarlo con un’interfaccia grafica per la gestione del sito in modo da trasformarlo da un sistema pensato per sviluppatori ad un sistema utilizzabile da tutti.

Realizzazione di un sito

Realizzare un sito con XWCM risulta estremamente semplice, a condizione di avere alcune conoscenze di XSLT per personalizzare il template e di XML per redarre i contenuti.

Il prerequisito fondamentale è quello di avere a disposizione un server web con supporto per PHP (almeno nella versione 4.3) e supporto per domxml e xslt attivati.

Una volta configurato il tutto è sufficiente copiare sul server la libreria XWCM presente nel pacchetto di distribuzione e la cartella con il sito demo. Se tutto funziona correttamente il sito dimostrativo è visualizzato all’indirizzo http://<servername>/demo_site.

Personalizzazione del sito

La libreria utilizza 2 file principali per la personalizzazione del sito: un file che descrive la struttura del sito stesso e un template.

Il file della struttura (menu.en.xml) è, in linea di principio, un insieme di tag “file” con struttura ad albero che descrivono esattamente le pagine del sito e le loro relazioni gerarchiche. All’interno di questo file è presente l’indicazione del path del template da utilizzare.

Il template è un file XSLT che trasforma l’XML generato dalla libreria nella pagina vera e propria. Per la personalizzazione di questo file è necessario consultare la documentazione per capire come viene generato l’XML da elaborare.

Una volta sistemati questi file è sufficiente creare i file di contenuto con i corrispondenti file php in modo che la loro posizione rifletta la struttura del sito definita nel file del menu.

Caratteristiche avanzate

Tra le principali caratteristiche supportate da XWCM, oltre a quelle già sopra indicate, si possono evidenziare:

• Supporto per la generazione dinamica delle pagine (esempio elencare dati presi da un db)
• Supporto per template dinamici
• Supporto per template multipli. Sezioni del sito o anche singole pagine possono essere dotate di template differenti
• Generazione automatica del filo d’arianna

Esempi

Oltre al sito demo presente nel pacchetto lo stesso sito di XWCM è realizzato con XWCM stesso. Puntando al file del menu dovrebbe essere possibile ricavare tutte le informazioni necessarie per accedere ai sorgenti del template e degli altri file che compongono il sito.

Conclusioni

Spero che il progetto possa entusiasmare altre persone e la comunità di utenti e sviluppatori si ampli fino a dare la possibilità di creare un sistema di CMS completo e affidabile.

Se avete provato la libreria vi prego di darmi un riscontro.

The World Wide Mash

Uno dei fenomeni che stanno alla base del web2.0 e che lo caratterizzano è legato all’utilizzo di parti di altri siti per costruire il proprio. Questo modo di operare viene identificato con il termine “mashup” il cui significato letterale è quello di poltiglia.

Questo nomignolo poco gratificante deriva dal fatto che spesso i servizi utilizzati non sono esattamente pensati per essere utilizzati all’interno di altri siti e il risultato è quello di un’accozzaglia di oggetti debolmente interconnessi tra loro e, a volte, anche poco integrati graficamente.

Ultimamente, tuttavia, questo modo di utilizzare pezzi di siti, si sta strutturando per consentire un utilizzo più organico e, anche se siamo lontani dal web semantico desiderato da Tim Berners Lee, ci stiamo avviando verso il “mesh-up”, in cui la poltiglia assume il significato di interconnessione strutturata.

Vediamo alcuni esempi di mashups e come si sta muovendo il mondo dell’informatica.

Una breve storia dei mashups

Anche se ci si deve spingere poco indietro nel tempo, il primo esempio di mashup si fa risalire al sito housingmaps.com. Questo sito non fa altro che prelevare le informazioni da Craiglist, un sito di annunci commerciali molto legato alla compravendita di abilitazioni, e combinarle con Google maps in modo da localizzare geograficamente le case in vendita.

L’innovazione fondamentale che l’ideatore del sito ha apportato è stata quella di non limitarsi ad utilizzare informazioni provenienti da altre sorgenti e ripubblicarle, come nel caso di news tramite RSS, banner pubblicitari o video presi da siti specializzati. In questo sito i dati vengono elaborati proprio come dati a se stanti e ricombinati (eventualmente con altri) per creare qualcosa di nuovo e non esistente prima.

Da questo primo esempio si sono sviluppate moltissime idee, e oggi nascono all’incirca 3 esempi di mashup al giorno, con funzioni che spaziano dai servizi di localizzazione fino ai giochi.

Il punto di partenza per chi voglia cimentarsi è sicuramente Programmable web che, oltre ad un nutrito database di esempi, fornisce l’elenco completo di tutte le API disponibili e i link a vari howto che spiegano come utilizzare una determinata API.

Il numero, sicuramente ragguardevole di 3600 mashups censiti e 1250 API disponibili (che corrispondono ad altrettanti servizi accessibili via web) dà un’idea dell’importanza e della diffusione del fenomeno.

Dalla parte opposta chi fornisce i servizi vede in questo strumento un metodo eccezionale per farsi conoscere ed imporsi come standard de facto. Google maps, in tal senso, è l’esempio principe con quasi 1600 mashups conosciuti e, forse grazie anche a questo, surclassa i propri concorrenti come notorietà nel settore delle mappe geografiche.

Le tecnologie

Indipendentemente dall’idea che vi sta dietro, le tecnologie che vengono utilizzate si basano quasi sempre su XML anche se spesso l’accesso ai servizi è nascosto dietro vere e proprie librerie che, oltre al puro trasferimento di dati, celano pezzi di codice che registrano gli accessi o ne limitano le possibilità.

Il formato XML dei dati può essere rappresentato da uno standard, come nel caso dei RSS, o da formati proprietari specificatamente pensati per il servizio desiderato.

L’accesso ai dati avviene utilizzando direttamente i dati in formato XML, utilizzando web services basati sui più disparati protocolli di comunicazione (SOAP, REST o XML-RPC) o, nel caso non esistano altri metodi, tramite l’analisi della pagina web in cui tali dati sono visualizzati.

Oltre agli aspetti indicati è importante anche capire dove il mashup può avvenire: sul server che ospita il sito o direttamente sul browser dell’utente che lo sta visualizzando.

Mentre i mashups realizzati sul server possono usufruire di una serie più completa di API, quelli su client si devo limitare alle possibilità offerte da Javascript, tuttavia ne permettono la realizzazione, come caso limite, anche senza disporre di un server web.

Editor di mashups

Creare un mashup richiede alcune competenze di programmazione e non è sicuramente alla portata di tutti. Per facilitare la creazione di questi oggetti sono disponibili software specifici o servizi accessibili via web.

Purtroppo la maggior parte di questi strumenti è pensata come strumento per le aziende e non è disponibile gratuitamente. Tra le versioni utilizzabili senza costi di licenza ve ne sono 2 particolarmenti promettenti.

Yahoo! Pipes fornisce un servizio accessibile via web che permette, attraverso una comoda interfaccia grafica, di combinare tra loro differenti flussi di dati, rielaborarli e  ottenere un risultato in vari formati che vanno dagli standard RSS e JSON fino ad alcuni formati proprietari.

Di questo servizio è senza dubbio pregevole l’interfaccia utente per la creazione dei “pipes”, che consiste in un editor di diagrammi scritto in Javascript di ottima qualità. Il formato di output, viceversa, non sembra, ad un’analisi superficiale, facilmente configurabile, se non passando dai risultati esportati e rielaborandoli quantomento attraverso un XSLT.

Gnip utilizza un approccio più orientato alla programmazione e l’interfaccia per la creazione dei filtri è sicuramente meno semplice. Esso, tuttavia, ha il vantaggio di permettere la creazione e pubblicazione sul sito di “produttori” di informazioni, dove un produttore può essere già uno strumento che combina fonti differenti. sotto questo aspetto lo strumento di Yahoo! fornisce una lista chiusa di strumenti utilizzabili, anche se decisamente soddisfacente.

In entrambi i casi è sicuro che limitandosi agli strumenti base messi a disposizione senza scrivere una linea di codice si ottiene un risultato molto distante da un vero e proprio mashup.

Conclusioni

Per chi volesse approfondire l’argomento, oltre al già citato sito di Programmable web, si può far riferimento alla pagina di Wikipedia in cui vi sono vari riferimenti a tecnologie, strumenti e esempi significativi.

La gratificazione dell’utente

Dall’analisi degli strumenti di enterprise2.0 fatta nel precedente post si intuisce come, tra tutte le necessità aziendali che le tecnologie proposte sono in grado di soddisfare, quella preponderante sia relativa alla comunicazione e all’informazione.

Rod Boothby analizza questa necessità, comparando gli strumenti attualmente in uso, quali telefono e e-mail, con i nuovi strumenti che si basano sui principi del web2.0 come blog e wiki.

Il primo confronto paragona 2 aspetti dell’informazione quali la sincronicità e la possibilità di riutilizzo. Sotto questo aspetto il web2.0 ne esce vincitore esaltando le capacità di asincronicità, catalogazione, ricercabilità e referenziabilità che abbiamo iniziato ad apprezzare grazie all’e-mail.

Il punto fondamentale, tuttavia, è dato dalla capacità di queste nuove tecnologie di esaltare la gratificazione e, come conseguenza, la partecipazione delle persone allo scambio ideologico.

La teoria dell’altruismo reciproco

Robert Trivers, nel suo trattato “L’evoluzione dell’altruismo reciproco” (maggiori approfondimenti sul tema), analizza dal punto di vista biologico ed evolutivo un comportamento estremamente diffuso in varie comunità animali, che si concretizza a partire dalla capacità di non infierire o aiutare il più debole, fino a comportamenti di vera e propria condivisione delle eccedenze.

Sicuramente non mancano gli esempi per dimostrare che anche il genere umano ne è affetto, tuttavia, parlando di Internet e informatica, possiamo citare 2 esempi fortemente attuali:

• il file sharing
• il mondo del software open source

In entrambi i casi gli utenti mettono a disposizione della collettività beni o servizi in modo altruistico e questo comportamento ha tutta una serie di ricadute. Prima tra tutte la forte tendenza che hanno queste persone a costituirsi in comunità. Questa tendenza, parte integrante della teoria citata, serve a incrementare i benefici del comportamento altruistico e gli svantaggi per chi adotta comportamenti non consoni ed egoistici.

Il motivo principale per cui questi comportamenti vengono adottati è legato al rapporto tra ciò che si dà e ciò che gli altri ricevono. Il meccanismo funziona quando la percezione del valore ricevuto (dagli altri) è superiore al valore del sacrificio sopportato (da se stessi). Questo in quanto dietro il comportamento altruistico si cela la speranza di potere, in futuro, usufruire di questa differenza.

Il valore aggiunto per i dipendenti

Questo valore aggiunto, calandosi in ambito aziendale, si può concretizzare in vari modi, di cui i principali sono la gratificazione e la speranza di futuro riconoscimento.

Mentre la seconda rappresenta una speranza a lungo termine, la prima è immediata e può derivare da vari aspetti:

• Sensazione di avere il controllo su parte del processo aziendale
• Conoscenza in tempo reale delle decisioni che l’azienda assume
• Possibilità di ribattere a tale decisioni e di ricevere commenti in risposta
• Possibilità di condividere le proprie idee, vedendosene attibuita la paternità e ricevendo feedback immediati e riconoscimenti pubblici

Tra gli esempi citati nel paragrafo precedente, il mondo dell’open source si avvicina molto ad un processo aziendale e può essere paragonato ad un’azienda di software di dimensioni immense.

In questo contesto i 4 aspetti sopra indicati si concretizzano nel seguente modo:

• Il mio contributo si inserisce nel contesto del software che il mondo utilizza: contribuisco a qualche cosa di mondiale
• Ogni decisione è resa pubblica e non mi viene nascosta. Principio che consente il funzionamento di team di sviluppo geograficamente distribuiti
• Possibilità, tramite forum, wiki e commenti ai post, di ribattere a qualsiasi decisione
• Possibilità di dire la mia opinione o proporre la mia idea sapendo di poter contare su un confronto sincero e su una corretta attribuzione delle idee

Unitamente alla speranza di futuro riconoscimento che si potrebbetrasformare in sostanziose offerte di lavoro, questi aspetti hanno contribuito a far diventare l’open source un fenomeno di successo.

Massimizzare gli effetti dei nuovi strumenti

Per ottenere la maggiore gratificazione, come suggerisce Dion Hinchcliffe in questo post bisogna imporre il minor numero di regole possibile, proprio per esaltare la sensazione di controllo che viene fornita all’utente.

In secondo luogo l’aspetto più importante è il feedback: dai vertici verso il basso, ma anche dai dipendenti verso l’alto e tra dipendenti stessi. In questo articolo sono riportati degli esempi di successo che la mancanza di confronto e riconoscimento avrebbe stroncato, dando un forte colpo allo sviluppo scientifico.

I blog sono sicuramente lo strumento ideale, a condizione che siano sottoposti a linee guida di utilizzo estremamente sintetiche e liberi per tutti. Solo in questo modo si riuscirà a trasformare un lavoratore in un innovatore.

Per concludere voglio ricordare una massima che nel mondo del software libero è molto diffusa e che può far capire l’importanza del processo sopra descritto:

“Se io do un Euro a te e tu un Euro a me, abbiamo 1 Euro a testa.
Se io do un’idea a te e tu un’idea a me, abbiamo 2 idee a testa.”

Enterprise2.0 – una breve analisi

Sulla scia del successo mediatico del web2.0 si è diffusa l’abitudine di applicare il suffisso “2.0” ad una serie di parole per indicare l’introduzione delle tecniche del web2.0 in determinati settori.

Su questa scia si è iniziato a parlare di science2.0, office2.0, health2.0, government2.0, … ma un posto di rilievo, almeno per la sua rilevanza, spetta all’enterprise2.0.

In questo post ho raccolto alcuni appunti che cercano di chiarire cosa vuol dire applicare le tecniche del web2.0 all’interno delle imprese.

Definizioni

Il termine web2.0, al contrario del suo capostipite, non indica un insieme di tecnologie o di standard, ma un approccio sociale al modo in cui il web viene costruito. Le informazioni presenti nei siti non nascono più, come nel passato, in modo gerarchico, ad opera di un gruppo limitato di persone che costituisce il comitato di redazione. Esse nascono ad opera degli utenti che fruiscono del servizio, sfruttando una forza lavoro enorme e, normalmente, gratuita.

Questo nuovo modo di operare ha portato alla creazione di strumenti ben definiti che delineano il tipo stesso del servizio offerto dal sito, creando nuovi nomi che dal prodotto sono passati ad identificare la tecnologia che tale prodotto consente di realizzare. Si parla così di blog, di wiki, di social bookmarking o di social networking identificando sia un sito che offre tale servizio che il software che consente di realizzarlo.

Parlando di enterprise2.0 l’approccio metodologico passa in secondo piano e si inizia ad instaurare una vera e propria definizione basata sulle esigenze specifiche che un prodotto in grado di traghettare l’impresa verso tale “tecnologia” deve avere.

Di seguito provo a riassumere quelle che costituiscono, al momento attuale, il sottoinsieme di prodotti del web2.0 che, nel suo complesso, può essere definito come enterprise2.0. Questo elenco, ovviamente, si basa sull’attuale stato dell’arte e sicuramente in futuro varierà in base alle nuove idee che scaturiranno e che risulteranno applicabili in ambito aziendale.

La condivisione delle informazioni

Come suggerito in questo articolo, l’obiettivo dell’impresa, parlando di web2.0, è quello di condividere le informazioni. Tra i vari strumenti disponibili, l’autore suggerisce 5 pilastri fondamentali, mescolando strumenti che consentono di fornire informazioni a strumenti che permettono di consultarle.

Li elenco di seguito strutturandoli meglio e aggiungendone uno, a mio avviso dimenticato.

• Il social networking
• I blog
• I wiki
• Il social bookmarking

Questi 4 strumenti utilizzati per fornire informazioni devono essere tutti completati dai tag per la classificazione e dagli RSS per la fruizione delle informazioni inserite.

Il social networking

Il database dei dipendenti e dei collaboratori. Chi sono, cosa fanno, con chi lavorano, su che progetti, quale è il loro curriculum, …

Consultando un sito come LinkedIn non credo che vi siano informazioni che un’azienda reputerebbe poco importanti relativamente ai propri dipendenti. Al massimo le informazioni vanno riviste legandole maggiormente alla propria realtà, ad esempio prelevando i progetti dall’elenco dei progetti aziendali, i gruppi da quelle dei vari uffici, le autorizzazioni dalle policy aziendali e così via.

I blog

Il blog è ciò che si pensa e il diario in cui vengono memorizzati gli appunti sul proprio lavoro. Esso rappresenta, per l’azienda, un doppio canale: comunicazione e documentazione.

Il primo serve per fornire direttive e informazioni evitando e-mail di massa in cui si rischia di dimenticare qualcuno e che non sono viste da chi arriva dopo. E’ un canale estremamente efficiente par parlare con i sottoposti e per comunicare la propria visione o la visione aziendale.

Il secondo rappresenta un efficace sistema di documentazione del lavoro svolto: ogni giorno ogni dipendente scrive ciò che ha fatto, che problemi ha riscontrato e come li ha risolti. Un valore inestimabile, ad esempio, nel caso di passaggio di consegne.

I wiki

Il wiki è l’imitazione, tramite un software, della classica lavagna in cui, durante le riunioni, si tiene traccia delle idee e dei concetti permettendo a chiunque di modificare ciò che vi è scritto. Questo video chiarisce in modo encomiabile il concetto.

A questo strumento base un wiki aggiunge una caratteristica fondamentale: l’asincronicità. Grazie ad un wiki non posso solo fornire il mio contributo, ma il documento si può completare in tempi differenti, senza bisogno di trovare un momento di disponibilità collettiva.

I wiki, inoltre, dispongono di strumenti per la tracciabilità delle modifiche che semplificano enormemente la ricerca delle novità o delle modifiche apportate da una determinata persona o l’esplorazione di ipotesi, senza contare il fatto che un wiki dispone di molte “lavagne” che possono essere collegate tra loro tramite link.

Social bookmarking

Non credo che esista un’organizzazione che prima o poi non senta il desiderio di avere una pagina con un elenco di link ritenuti importanti.

Il social bookmarking aggiunge a questa pagina le caratteristiche del web 2.0 relativamente al fatto che viene “manutenuta” da tutti e tutti la possono correggere nel momento in cui un link non è più valido o importante.

Il fatto che un link sia legato ad una persona specifica, inoltre, permette anche di sapere cosa tale persona reputa importante (ad esempio cosa è importante per il mio capo) e aggiunge a chi lo consulta un criterio di valutazione: se una persona che stimo mi consiglia qualche cosa sono più propenso a consultarla rispetto al consiglio di uno sconosciuto.

I tag

Il sistema dei tag è un ottimo sistema di classificazione che supera i limiti delle gerarchie statiche creando gerarchie dinamiche. Solo utilizzandolo se ne riesce ad apprezzare i vantaggi rispetto alle classificazioni ad albero, anche perché richiede un nuovo modo di organizzare il proprio pensiero.

I tag, inoltre, hanno anche una forte valenza psicologica e organizzativa, permettendo di sfruttare quella che viene definita “wisdom of crowds” e incrementare lo scambio di informazioni, come ottimamente spiegato in questo articolo.

Gli RSS

Se provate a consultare un RSS utilizzando un client di posta capite subito le analogie e le differenze con le e-mail.

Le analogie sono nel formato e nell’immediatezza dell’informazione. Ogni messaggio arriva più o meno nell’istante in cui viene inviato o alla prima occasione di consultazione da parte del destinatario.

Le differenze, invece, sono tutte dei vantaggi:

• Arrivano i messaggi solamente dalle persone desiderate (dagli elenchi che ho sottoscritto): niente spam
• I messaggi vecchi restano anche per chi arriva dopo, ad esempio il neo assunto
• Il messaggio non arriva realmente, ma ne arriva solo titolo e riassunto (se così voglio). I contenuti pesanti che potrebbe contenere finiscono sul mio pc solo se lo desidero.

Conclusione

Individuate le necessità occorre trovare gli strumenti. Internet ne è piena e il mondo del software libero anche. Quello che rimane da capire è quali siano i più adatti e, soprattutto, in che modo si integrano tra di loro e in che modo possono essere integrati con le realtà aziendali che si basano su prodotti gestionali preesistenti e con severe regole di accesso per la protezione delle informazioni.

Agli strumenti classici, infatti, è fondamentale aggiungere una parte di strumenti del mondo esistente che ne completano l’utilità calandoli nella specifica realtà aziendale. Quanto elencato, pertanto, farà da supporto a ERP, CRM e altri strumenti già ampiamente diffusi.

Capire quali sono gli strumenti corretti e come integrarli è un lavoro per i prossimi post.

Registrazioni e identità, dall’e-mail a OpenID

Nel precedente post ho sconsigliato, per problemi di privacy e sicurezza, l’utilizzo di OpenID come sistema centralizzato di autenticazione per tutti i servizi web.

Vorrei ritornare sull’argomento per approfondire il funzionamento di OpenID (dal punto di vista di un utente) per motivare meglio questa scelta e spiegare nel dettaglio la soluzione che reputo più idonea.

Analizziamo i vari metodi di registrazione che si possono trovare sui siti web esponendo pregi e difetti.

Registrazione con username e password

Il metodo più facile per gestire la registrazione è quello di chiedere all’utente che si vuole iscrivere di scegliere esclusivamente uno username e una password.

Questo metodo non fornisce al sito alcuna informazione sull’identità dell’utente, ma consente esclusivamente di accertarsi che, nei successivi accessi, chi entra è la stessa persona che è entrata la prima volta.

In questo modo il sito è in grado di collegare le azioni compiute, siano esse informazioni memorizzate o altro, allo username. Questo può consentire di attivare meccanismi di restrizione dei permessi quali, ad esempio, consentire l’accesso alle informazioni esclusivamente all’utente che le ha inserite.

Questa soluzione, tuttavia, ha 2 grossi limiti.

Il primo è un limite “organizzativo”: cosa succede, ad esempio, se non mi ricordo più la password?

Il secondo è un problema di funzionalità. Supponiamo di voler creare una “rete” di fiducia in cui l’accesso alle informazioni è consentito non solo all’utente che le inserisce, ma anche a ad altri. Questi altri possono essere identificati esclusivamente tramite username. Questo comporta che la corrispondenza username – persona reale deve essere effettuata al di fuori del meccanismo proposto, ad esempio con una mail tra le 2 persone in cui si dice “il mio username è xyz”.

Registrazione standard Web 1.0

Per ovviare ai problemi sopra elencati, in tutti i siti che attualmente conosciamo, la registrazione è accompagnata dalla richiesta di un indirizzo e-mail. La procedura di registrazione si svolge nel seguente modo:

• Scelta di username e password e indicazione del proprio indirizzo di e-mail
• Invio di una e-mail di conferma con un link
• Cliccando sul link l’account viene attivato

Ovviamente vi sono variazioni sul metodo che si basano sul fornire una password automatica che l’utente può poi cambiare, utilizzano direttamente l’indirizzo e-mail come username o sfruttano altri metodi per ottenere conferma, quali un SMS come nel caso dei provider telefonici.

Qualunque sia la variante, tuttavia, l’utente viene identificato non solo come colui che si è registrato, ma anche come colui che risponde ad un indirizzo e-mail o altro strumento di comunicazione.

L’indirizzo e-mail costituisce un’identificazione univoca e, se viene pubblicato, consente anche a chi mi conosce di associarmi a tale account.

Il meccanismo funziona e i problemi precedentemente esposti sono stati risolti. I promotori di altri sistemi, tuttavia, segnalano che questo meccanismo porta ad una proliferazione di username, password e dati per ogni utente (uno per ogni sito) con disagi per chi va tutti i giorni su svariati account e li vuole tenere allineati.

OpenID

OpenID permette, tra le altre cose, di avere un account unico. Ecco come funziona l’iter di registrazione.

• Mi registro su un sito che fornisca il servizio di provider OpenID utilizzando il metodo standard basato su e-mail
• A questo punto, per registrarmi ad un altro sito che si comporti da client OpenID fornisco esclusivamente la mia URI OpenID, ovvero l’URI che mi identifica su internet
• Il nuovo sito fa una richiesta al mio provider OpenID chiedendogli i miei dati e il provider, prima di inviarli, mi chiede conferma tramite redirezione su una sua pagina e, se non l’ho già fatto, richiesta di username e password originali
• Il client a questo punto mi autentica registrando le informazioni che è riuscito a ricavare dal mio account OpenID
• Nei successivi accessi fornirò sempre la mia URI e la richiesta di password avverrà sempre e solo da parte del provider OpenID e solamente alla prima connessione

Tramite questo metodo ho avuto i seguenti vantaggi:

• Sono stato identificato in modo univoco su internet (identità)
• Non ho dovuto ripetere i miei dati per la nuova registrazione
• In teoria il nuovo sito potrà aggiornare le informazioni ogni volta che cambieranno sul mio account
• Utilizzo uno username/password unici per tutti i servizi
• Inserisco username e password una sola volta e vale per tutti i siti attivati

E’ un meccanismo fantastico, ma il rovescio della medaglia è che il mio provider non solo può accedere a tutti i miei siti spacciandosi per me (basta una modifica al programma o la memorizzazione in chiaro della password), ma ne ha anche l’elenco in quanto deve memorizzare i siti autorizzati.

Dormireste sonni tranquilli?

Come utilizzare OpenID

OpenID ha grossi vantaggi, soprattutto nella capacità che ha di mantenere sincronizzati i propri dati tra siti differenti e, se completato con le informazioni che possono essere memorizzate tramite un file FOAF, potrebbe costituire veramente la nostra identità in rete.

Il meccanismo che propongo è quello di rinunciare allo username/password unici per ogni sito. Questa rinuncia è, a mio avviso, minima e se non se ne può fare a meno, piuttosto utilizziamo i meccanismi di memorizzazione automatica dei browser.

La procedura di registrazione, pertanto, potrebbe essere la seguente:

• Registrazione utilizzando il primo metodo (solamente username e password, senza e-mail) completato con la mia URI OpenID)
• Il sito scarica dal provider OpenID i miei dati e memorizza la mia URI per successivi aggiornamenti
• La URI OpenID non potrà mai essere usata per l’accesso al mio sito, ma dovrò sempre usare username e password forniti al sito stesso

In questo modo ho mantenuto il vantaggio di collegare tutti i miei siti alla mia identità e permettere alle persone di sapere che quel sito è della persona descritta a quell’URI e citata come amico da quell’altro utente.

Alla semplice URI (che potrebbe essere direttamente il mio file FOAF), OpenID ha aggiunto la dimostrazione della proprietà dell’URI, meccanismo fondamentale per costruire una rete di fiducia basata su tale identità.

“Chi sono” – la nostra identità sul web

Come primo post su questo blog sarebbe forse giusto parlare dell’autore, dei suoi interessi e della sua vita. Tuttavia io preferisco mirare direttamente all’obiettivo entrando subito negli argomenti a cui questo blog è dedicato. Il “chi sono” del titolo, pertanto, non si riferisce a me, ma alla nostra identità in Internet.

Così come succede nella vita reale, anche nel mondo virtuale abbiamo bisogno di “definirci”, di trovare un modo univoco per rappresentare la nostra identità. Se nella vita reale posso dire io sono Tizio, residente in questa città e abitante a questo indirizzo, non è altrettanto facile classificarci nel momento in cui siamo in rete.

Chi sono io? Sono la persona descritta su Facebook o su LinkedIn, quella presente su Flickr o su TripAdvisor o, ancora, sono l’autore di questo blog? Le nostre identità in rete sono multiple e spesso discordanti, in quanto non è presente un meccanismo che consenta di trasferire e mantenere sincronizzate le informazioni.

Un secondo aspetto è quello della veridicità della frase: “la persona descritta a quell’indirizzo internet sono io”. Posso dirvi che mi chiamo Tim Berners-Lee e che questa è la pagina che mi descrive, ma difficilmente, basandovi esclusivamente su Internet, potete essere in grado di accertarlo.

Questo problema è ancora più grande nel momento in cui quella pagina contiene, come nell’esempio proposto, informazioni significative su opere o conoscenze che possono influenzare pesantemente il mio interlocutore e indurlo ad assegnare un peso differente alle mie affermazioni.

Per nostra fortuna la tecnologia ci sta già venendo incontro e ci fornisce 2 strumenti che, combinati, riescono a risolvere completamente i problemi esposti. Tali strumenti sono FOAF e OpenID.

FOAF

Friend Of A Friend è uno strumento estremamente semplice. Si tratta, essenzialmente, di uno standard basato su RDF che permette di descrivere una persona e tutti i collegamenti che essa ha con altre persone o cose, siano esse definite o meno sul web.

In pratica si tratta di creare un file RDF all’interno del quale vi siano tutte le informazioni che normalmente ci vengono richieste iscrivendoci ad un sito, dai dati anagrafici ai nostri recapiti. Tali informazioni saranno poi completate dai collegamenti del tipo “lavoro in questa azienda”, “ho scritto questi libri”, “questo è il mio blog” e, forse più importante di tutti dal punto di vista del social networking, “conosco questa persona” dove la persona presa in causa è l’URL di un altro file FOAF.

Se creiamo il nostro file e lo pubblichiamo in qualche modo in internet, possiamo iniziare a dire in giro “questo sono io” e fornire a chiunque sempre le stesse informazioni. I miei amici potranno iniziare a collegarmi tramite i file FOAF e la rete di interconnessioni comincerà ad ingrandirsi.

Se tutti i siti che ci chiedono nome e recapiti si accontentassero di un URL, potrebbero non solo evitarci la fatica di ripetere le stesse informazioni ad ogni registrazione, ma anche tenerle costantemente aggiornate riscaricando la nuova versione del file ogni volta che viene modificato.

I file FOAF sono il primo tassello del “Giant Global Graph” del precedentemente citato Tim Berners-Lee, in cui il web si trasforma da un insieme di pagine interconnesse ad un insieme di informazioni interconnesse, intendendo con informazione il dato puro e semplice.

Crearsi un’identità

Creare il proprio file FOAF è relativamente semplice e può essere fatto seguendo 2 strade, ognuna con vantaggi e svantaggi.

La prima consiste nell’iscriversi ad un sito di social networking che fornisca tale servizio. E’ facile trovare in rete degli elenchi, tuttavia così facendo ci si lega a tale sito e la vostra identità in rete ne seguirà le sorti. I problemi che nascono sono gli stessi di un indirizzo mail. Nel momento in cui voglio (o sono obbligato) a cambiarlo devo contattare tutti coloro che lo usano affinché lo sostituiscano con quello nuovo.

Nel caso dell’identità questo potrebbe essere particolarmente oneroso, in quanto i suoi riferimenti si potrebbero essere diffusi in modo considerevole e cambiarli non è così facile come mandare una singola mail.

Il secondo metodo è quello di crearsi il proprio file FOAF tramite un servizio on-line come Foaf-a-matic e pubblicarlo sul proprio sito.

In questo caso il rischio di dover cambiare è più limitato, a condizione di essere il titolare del dominio o di avere un rapporto di estrema fiducia con chi ce lo fornisce, tuttavia diventa più oneroso l’aggiornamento che comporta una variazione manuale del file.

In entrambi i casi permane poi un problema: come garantire agli altri che il file a quell’URL è veramente il mio?

Aggiungiamo OpenID

Sul sito ufficiale viene detto che OpenID elimina la necessità di avere molteplici username per accedere ai vari siti presenti in internet. In base a questa definizione OpenID sembra essere un protocollo per implementare un sistema di autenticazione centralizzato e, in effetti, come tale funziona.

Dal punto di vista dell’utente il meccanismo è semplice:

• Mi registro su un sito che fornisca il servizio di provider OpenID

• Mi collego ad un sito che supporti gli account OpenID (il client)

• Invece di registrarmi fornisco la mia URL OpenID

• Vengo rimbalzato sul sito del provider dove possono inserire username e password

• Le mie informazioni sono inviate al client il quale mi autentica

Bello, ma nasce immediatamente un problema: mi fido così tanto di questo provider da consegnarli l’account per accedere a tutti i miei siti? Io no di sicuro.

Sotto quest’ottica OpenID avrà uno scarso successo come meccanismo globale, ma potrebbe rivelarsi molto utile in ambito aziendale configurandosi come un sistema unificato di autenticazione: mi registro sul server OpenID aziendale e posso accedere a tutti i servizi internet senza fornire nuovamente username e password. In questo caso l’azienda garantisce la mia identità solamente per i servizi dell’azienda stessa e io fornisco username e password solamente a chi quei servizi già li gestisce.

Se OpenID non costituisce un sistema integrato di autenticazione, in che modo può completare il meccanismo di gestione globale della propria identità? Prendendolo per il solo protocollo che gli sta alle spalle e non per l’uso che ne viene proposto.OpenID dovrebbe essere utilizzato semplicemente come metodo di comunicazione tra computer per autenticare l’accesso ad una determinata pagina.

In sintesi il processo è questo:

• Dico ad un servizio “io sono la persona descritta a questa URL”

• Tramite OpenID viene richiesto l’accesso a tale URL e io, inserendo username e password, acconsento al trasferimento dei miei dati

• In quella pagina è presente un link al file FOAF che mi descrive

• Il sito mi identifica come la persona descritta da tale file in modo univoco e può sempre scaricare gli aggiornamenti che mi riguardano

Un descrizione alternativa di questo meccanismo è fornita in questo post, anche se si lascia sempre passare il concetto che l’URL OpenID può sostituire username e password. A mio avviso deve limitarsi ad accompagnarli così come un indirizzo e-mail completa la registrazione tramite l’invio di un link di conferma.

Conclusioni

Tramite FOAF e OpenID viene definita la nostra identità in rete nel senso di URI univoca per ognuno di noi. Ovviamente posso continuare a dire di essere l’inventore del web, ma il W3C, quando parlerà di me, parlerà della persona con una certa URI e tale persona non potrò essere io, in quanto non sarò in grado di “dimostrarlo” a chi me lo chiedesse.

Tramite questi 2 protocolli abbiamo un metodo per costruire la nostra rete di conoscenze in internet.