Ricostruzione della blogoclasse

Questa estate ho iniziato a sviluppare una serie di strumenti che vorrei sostituire ad alcuni servizi web, quali GoogleDocs o GoogleReader, nella gestione delle blogoclassi. È un lavoro che assorbe molto tempo ma mi piace molto e soprattutto risponde ad alcune necessità che sento sempre più impellenti. In questo post ricapitolo brevemente le motivazioni fondamentali del metodo della blogoclasse e illustro semplicemente il tipo di lavoro che mi sono accollato. Dal discorso emergono anche alcuni spunti di più ampio respiro che riprenderò in qualche post successivo.

Il modello di insegnamento universitario, indotto dalla massificazione imponente – un modello trasmissivo, spersonalizzato e unidirezionale – è subottimale e comporta costi crescenti a fronte di risultati sempre più poveri. La blogoclasse rappresenta un tentativo di ridurre gli effetti dell’industrializzazione dell’insegnamento. Un tentativo di recuperare, almeno in parte, il dialogo fra gli individui. Un tentativo ispirato dall’ideale della prima accademia, dove i discepoli potevano cimentarsi con il loro maestro in un’esperienza che si estendeva nel tempo, mentre oggi il maestro è sempre più ridotto ad una sorta di operatore multimediale informato, il contatto con il quale si riduce ad una verifica finale, spesso banalizzata e dominata da fattori casuali. Non accade così nella totalità dei casi ma certamente accade troppo spesso.

La blogoclasse non si riduce solo a far aprire un blog a ciascun studente, perché in assenza di alcuni requisiti particolari, questa diventa una mera accozzaglia di siti. A parte i requisiti primari, vale a dire il proposito genuino del docente di insegnare e apprendere e il proposito dello studente di costruire effettivamente il proprio futuro – propositi apparentemente ovvi ma per nulla scontati nei fatti – occorre anche predisporre una minima infrastruttura organizzativa che consenta di seguire le attività degli studenti nel miglior modo possibile e di dar vita a un dialogo quando necessario.

Gli anni scorsi, pur di mettere in piedi qualcosa di fattibile mi sono avvalso pesantemente dei vari servizi web 2.0 che sono andati proliferando in questi anni. Del resto, dovendo occupandomi di Information Technology, era anche naturale sperimentare tutte queste nuove tecno-creature. Limitarsi a leggere quello che se ne dice non è certamente sufficiente.

Mediante i moduli (form) associati ai fogli di lavoro di GoogleDocs è stato possibile gestire in modo estremamente semplice l’iscrizione alla blogoclasse degli studenti. La griglia che va formandosi nel foglio può essere letta da un software locale che raccoglie la traccia del lavoro di ogni studente e gestisce i collegamenti con l’aggregatore dei feed di tutti i blog.

Il sistema così congegnato ha funzionato in modo egregio, ed ha consentito di scoprire possibilità che sarebbero state inimmaginabili anche solo pochi anni fa. Tuttavia, con il tempo sono emersi alcuni problemi che ora occorre affrontare.

• Non c’è dubbio che le capacità e le funzionalità che i servizi web offrono stiano raggiungendo livelli che anche i più ottimisti avrebbero avuto difficoltà a prevedere. Tuttavia occorre adattarsi alle opzioni offerte, e con il tempo può accadere di desiderare qualcosa che non si trova o che viene offerto in modi diversi da quello che si desidererebbe – questo è comunque un problema che si presenta con qualsiasi software prodotto da terze parti.
• I servizi sono molto dinamici. È certo un fatto positivo che mutino velocemente perché questo significa che aumentano le potenzialità ma è anche vero che spesso lo strumento che stai utilizzando ti cambia sotto il naso: quando riprendi in mano un procedura che avevi usato un paio di mesi fa hai sempre il dubbio che siano stati introdotti dei cambiamenti che ti potrebbero costringere ad un lavoro di riadattamento aggiuntivo.
• Non è terribilmente difficile collegarsi ai servizi web 2.0 con il proprio software. Si tratta di utilizzare le famose “API” (Application Programming Interface) dei servizi web: una serie di funzioni che possono essere integrate nel proprio software per scambiare informazioni con il servizio ed eventualmente impartire comandi automaticamente. Tuttavia, oltre alla mutevolezza che ho appena citato, talvolta le API, benché circolino in rete, non sono state rilasciate ufficialmente dal gestore del servizio e così si acuisce ulteriormente la sensazione di incertezza. Per esempio questo è il caso delle API per accedere alle informazioni memorizzate dal servizio di aggregazione di feed GoogleReader, proprio quelle che ho usato ampiamente nelle blogoclassi degli anni scorsi per recuperare i testi scritti dagli studenti nei loro blog. Un anello debole analogo del mio sistema erano i collegamenti che servivano a recuperare i dati dai fogli di lavoro di GoogleDocs.
• Quando si usano sistemi informatici per la gestione di dati, è fondamentale avere la possibilità di uscire dalle situazioni di emergenza, che possono essere dovute a interruzioni o disfunzioni dei servizi, limitando al minimo i tempi di fermo ed evitando la perdite o la corruzione dei dati. Certamente i servizi di Google sono fra i più affidabili che ci siano, per via della dimensione del business che sviluppano, ma la certezza non è di questo mondo e poi vi sono anche altri fattori inerenti alla qualità dei collegamenti, che non dipendono certo da Google.
• E in ultimo, ma non per importanza, vi è l’aspetto della conservazione e del corretto uso delle informazioni private che, nel caso dei servizi web, vengono affidati a terzi parti in circostanze che, di fatto, raramente sono perfettamente definite e sfuggono dal controllo degli utenti. Quest’ultimo è un grandissimo problema che investe tutta la nuvola, (the cloud) per usare l’ultima delle metafore in voga nelle mondo delle nuove tecnologie. La nuvola, ubiquitaria e non precisamente localizzata nello spazio, è un’entità nella quale galleggiano dati e servizi accessibili da tutte le parti del mondo. Una realtà che sta compenetrando la sfera sociale, imprenditoriale e manifatturiera a livello internazionale, con innegabili e spesso cospicui vantaggi in termini di efficienza e abbattimento di costi. Una realtà tuttavia che pone formidabili problemi di normativa e di risoluzione delle controversie, per via della fumosa delocalizzazione e della differenziazione legislativa fra paesi diversi e lontani.

Da queste brevi considerazioni, si capisce come l’organizzazione che ho sviluppato in questi anni abbia comportato l’assunzione di alcuni rischi. Rischi che ho cercato di ridurre, per così dire a mani nude, ma che non potevano essere elusi completamente. Rischi che non mi pento assolutamente di essermi assunto e che ritengo essere connaturati a qualsiasi iniziativa che abbia il carattere dell’innovazione e della sperimentazione. Non si può esplorare il nuovo con una rete di salvataggio perfetta. Rischi che rientrano in quella che potrei chiamare “fase prototipale”, cioè di sviluppo e impiego di processi in fase di prototipo, vale a dire abbozzati nelle caratteristiche essenziali, ma non perfettamente definiti e stabilizzati. Per intendersi nel concreto: se io ignoro gli esiti di una nuova metodologia, come quella della blogoclasse, non ha senso investire tempo nella costruzione accurata dei suoi componenti finali. La causa fondamentale del fallimento di tanti progetti di innovazione tecnologica, che ho potuto vedere dall’interno, sta proprio nell’illusione di poterne definire con precisione tutte le parti sin dall’inizio. La definizione delle forme e dei colori precisi di un affresco avviene grazie all’esecuzione di una lunga serie di schizzi.

Ora che principio ad avere le idee chiare sulle possibilità del metodo della blogoclasse, dei contesti nei quali esso funziona più o meno bene, inizia ad avere senso l’investimento di maggior tempo nella definizione accurata dei suoi componenti, e ciò comporta, a sua volta, la necessità di costruirseli da se. Fortunatamente, con il software questo si può fare e non solo, si può anche andare oltre il mero aspetto della performance tecnologica, si può anche fare una scelta di campo di natura ideologica, se non filosofica, grazie all’esistenza del software libero, o più generalmente e più correttamente, di una cultura del libero scambio dei prodotti dell’ingegno, una messe ricchissima che abbonda nell’umanità e che tante forze economiche vorrebbero ridurre in regime di scarsità. Come altrettanto ricco è l’altro ingrediente fondamentale delle attività umane, l’energia fisica, della quale il sole regala grande e sovrabbondante copia.

È così che, al quarto anno di esistenza della blogoclasse, ho deciso di dedicare questa estate all’esplorazione dell’indipendenza, rifacendomi artigiano, attingendo semplicemente alle libere fonti del pensiero da un lato, e di energia solare dall’altro: scrivendo il software che mi serve, impiegando strumenti liberi e standard non proprietari, che oggigiorno sono ubiquitari, e costruendo il sistema di alimentazione dei miei apparecchi attingendo energia dalla fonte solare.

Così ho finito il primo componente che consente agli studenti di iscriversi e al docente di tenere traccia del loro lavoro. È concepito come un servizio web ed è interamente costruito con componenti software liberi e standard aperti. Ho usato una suite di strumenti che si chiama LAMP, e che alimenta milioni di servizi web nel mondo. LAMP: Linux, Apache, Mysql, Php, tutti prodotti software open source che sono accesibili a chiunque senza alcun onere.

Linux è il celebre sistema operativo che tutti conoscono, almeno per sentito dire. Nel mio lavoro uso la distribuzione Debian sul server presso il Dipartimento di Fisiopatologia Clinica di Firenze e Ubuntu su questo portatile, che impiego per lavorare e sviluppare il software. Apache è il software che consente di rendere disponili le pagine web in un server. Un sistema open source che domina il mercato dei web server: il 66% del milione di siti più attivi del mondo è gestito da Apache. MySQL è il sistema di gestione di database relazionali, gli oggetti che memorizzano e gestiscono dati. PHP è il linguaggio che consente di programmare le attività sul server, quando gli utenti “cliccatori” richiedono qualcosa sulle pagine web disponibili su quel server.

Poi si aggiungono un altro linguaggio, Javascript, che consente di svolgere parte delle operazioni richieste non sul server, che tende ad essere sovraccarico perché deve rispondere a tutti i “click” che provengono dal mondo, bensì sul client, cioè sul computer dell’utente “cliccatore”. Ed infine c’è anche AJAX, un metodo che amplia le possibilità di comunicazione fra i computer client degli utenti “cliccatori” e i computer server che rispondono ai click. Ai programmatori, AJAX consente di distribuire in modo migliore il carico di lavoro fra computer client e server. La proliferazione dei servizi web 2.0 si avvale ampiamente di questi ultimi strumenti.

Questo primo componente di gestione delle blogoclassi è fatto da due parti, ovvero da due pagine web: una accessibile al pubblico per l’iscrizione ai corsi e una privata, che è accessibile solo a docenti e tutor per la gestione della blogoclasse.

Offro qui la prima versione della pagina di iscrizione, con la preghiera a chiunque voglia darmi una piccola mano, di iscriversi. Naturalmente si tratta di una iscrizione ad un corso fantomatico che svanirà prima di nascere, portandosi nel nulla tutte le iscrizioni ed i relativi dati. Questo vostro atto rappresenta per me un aiuto importante perché è molto difficile, se non impossibile, testare un sistema web per tutte le combinazioni possibili di computer, sistemi operativi, browser e relative versioni. Io lo testo su tre macchine: questo laptop con Ubuntu e Firefox, un Mac con Safari, un laptop con Windows XP e Internet Explorer, ma so bene che non è sufficiente. Sono doppiamente grato a coloro i quali, incontrando un problema, me lo segnaleranno. Questo è l’indirizzo: http://lai.dfc.unifi.it/blogoclasse/iscrizione.html

Per illustrare invece come funziona la pagina di gestione della blogoclasse, che non è pubblicamente disponibile, ho fatto un video.

La pagina di gestione mi consente di seguire la blogoclasse in qualsiasi parte del mondo mi trovi. Inoltre, grazie ad una brillante caratteristica di MySQL, tutte le volte che mi collego, il database che si trova fisicamente nel server a Firenze viene replicato automaticamente e identicamente sul mio laptop, con due importanti vantaggi: la possibilità di lavorare localmente sul database, ovvero sulla blogoclasse, quando non posso essere online, e la duplicazione del database, che costituisce garanzia di continuità nel caso di fermi tecnici del server.

Anche il video, confezionato molto alla svelta, alla prima, è realizzato con un software libero, Kdenlive.