steve's

Oltre il giardino. Del codice.

Ott
29

Presidente: Lei è d’accordo con Ben? Pensa che possiamo stimolare la crescita con incentivi temporanei?
Chance: Fintanto che le radici non sono recise, va tutto bene, e andrà tutto bene, nel giardino.

Il surreale film del 1979 “Being there” (in Italiano “Oltre il giardino”) interpretato, come si dice, magistralmente da Peter Sellers è troppo noto per doverne fare un riassunto. Il film parla della volontà di trovare modelli a tutti i costi, del ruolo della televisione, del vuoto di valori e di altro.
Ma a me piace soprattutto la metafora del giardino. O meglio, quella che tutti – tranne Chance Gardiner – interpretano come una metafora dello Stato e della sua cura.

Qui da me tutti hanno un casa col giardino. Però il rapporto col giardino (e anzi con la natura in generale) è molto diversificato. Almeno tre categorie sono facilmente riconoscibili:
1. estetica: prato inglese, statue, alberi di rappresentanza (magnolia)
2. funzionale: orto + frutteto, niente verde inutile
3. negazionista: cemento e muri; poi eventualmente vasi
Solo che io non mi ritrovo in nessuna di queste categorie. E si vede dal fatto che tutti quelli che passano guardano, scuotono la testa e mi dicono gentilmente: “Ma ti serve aiuto per tagliare tutta questa boscaglia?” La boscaglia in questione sarebbe il mio giardino. Che è fatto di tante piante diverse, ognuna con una storia, una curiosità, un modo di crescere e di lottare con le altre, una personalità, uno stile. Ci sono tracce di piante precedenti, promesse di piante future. Alcune le ho portate io da lontano, altre me le hanno regalate, altre sono nate da sole. Piante che mi ricordano persone, luoghi, momenti.

Qualche tempo fa mi sono accorto che anche per il rapporto con il digitale valgono più o meno le stesse categorie di sopra: chi lo vede come un accessorio di moda, chi come un utile strumento, chi fa finta che non esista. Non c’è possibilità di dialogo tra queste visioni così diverse, e ognuno guarda il giardino dell’altro con disprezzo nemmeno troppo celato.
Poi c’è chi il giardino non lo vuole per niente, ma è felice di visitare quello degli altri. Più in generale, si potrebbe dire che ci sono i nomadi-cacciatori-raccoglitori, che navigano e prendono quello che gli serve, e gli stanziali-allevatori-coltivatori, che circoscrivono uno spazio e ne controllano lo sviluppo. I primi hanno uno sguardo, come dire?, grandangolare; i secondi montano un macro. Oppure: lo sguardo dei nomadi percepisce le differenze, quello dei coltivatori le crea (un po’ come lo sguardo di Ciclope, avete presente?).
All’interno di questa metafora, programmare è coltivare alberi digitali. I programmi, come gli alberi, sono organismi che se va tutto bene crescono, si sviluppano. Hanno una vita propria (ebbene si) e a volte non fanno quello che uno si immaginava che facessero. Restano piccoli, o esplodono all’improvviso; intrecciano le radici con altri alberi, sfruttano lo stesso terreno, si fanno ombra tra loro. Gli alberi, come i programmi, anche quando muoiono vengono riusati per fare altro, da noi o da altri organismi. Si riproducono con i semi, o, al limite, diventano humus per altri alberi.
Nella coltivazione dei programmi non si parte dal nulla: infatti gli alberi non si seminano, si piantano alberelli giovani (e si, c’è la questione dell’opensource…). O meglio, veramente qualcuno molto bravo e un po’ presuntuoso lo fa, ma è difficile e lungo scriversi tutto da zero; più facile utilizzare librerie, interpreti e compilatori.
I programmi si potano: si tolgono rami secchi, o si indirizza lo sviluppo in una certa direzione, per avere una certa forma finale o per avere un certo quantitativo di frutti. Si innestano con rami di altre specie perché la struttura deve essere robusta e resistente. Si curano le malattie, si eliminano i parassiti (i bug…).

Non è facile coltivare un albero. La difficoltà più grande non è la tecnica spicciola (tagliare, zappare intorno alle radici) ma la visione d’insieme. Per esempio io ho piantato un acero troppo vicino alla casa e troppo vicino ad un giovane castagno. Per i primi quattro cinque anni, l’acero è restato più o meno uguale. Poi improvvisamente ha cominciato a crescere. Il risultato è che il castagno, che è più lento, è cresciuto storto cercando sole e aria, e l’acero fa ombra ai pannelli solari sul tetto. Ma quando ho piantato il giovane acero era alto quaranta centimetri, me l’ero riportato da una passeggiata nello zaino. Ora sarà alto quindici metri e non accenna a fermarsi. Non ho saputo “vederlo” da grande, nel contesto dello sviluppo del resto del giardino. Gli esperti me l’avrebbero detto subito: non lì. Oppure dovevo tagliargli la cima dopo due-tre anni per farlo allargare più in basso.
La progettazione e lo sviluppo di un software ha le stesse difficoltà. Bisogna impostare la struttura in modo che sia solida e resistente, scegliendo il linguaggio o il framework adeguato, andando a vedere cosa hanno fatto gli altri nei loro giardini. Poi bisogna sapere vedere in avanti, immaginarlo crescere, decidere da che parte piegarlo, tagliare delle aree morte o che daranno fastidio ad altri software. E durante tutta la sua vita bisogna tenerlo pulito dai bug, controllare che non ci siano vermi che ne rodono il tronco, parassiti che inseriscono uova che esploderanno più avanti.

A che serve coltivare alberi? Beh, dipende. Alcuni sono belli, altri fanno ombra, altri portano frutti o legna.
A chi va insegnato a coltivare alberi? In linea di principio, a tutti; come tutti, secondo me, dovrebbero saper scrivere un racconto, disegnare o suonare uno strumento. Perché è fonte di un piacere immenso – quello di vedere un organismo crescere – e perché permette di condividerlo con gli altri.
Bisogna essere professionisti, avere un giardino perfetto? No, non tutti. Basta anche un limone sul terrazzino. Ma essere in grado di apprezzare un albero quando lo si vede, quello si; e non solo “uh quant’è bello”, ma saper vedere attraverso e indietro, cos’è, da dove viene, come è cresciuto, come crescerà.

E la programmazione? Anche quella va insegnata a tutti i bambini? Qui bisogna stare attenti a quello che si scrive, e siccome ne ho scritto pure troppo altrove, passo. Qui mi accontento della metafora, che è utile quando fa riflettere da un punto di vista nuovo e suggerisce idee.

Però anche in questo caso mi ritrovo (spesso) ad essere l’unico appassionato dalla boscaglia digitale e a partecipare amorevolmente a tutta la complessità dei suoi organismi, piantando qui, potando là, e poi godendomi il risultato. Non lo faccio (più) in maniera quotidiana, nel senso che intervengo solo marginalmente nelle scrittura di codice sorgente, che scrive chi è molto più bravo di me. Mi appunto ancora delle idee, o ripesco degli schemi di anni fa in attesa del momento in cui ci sarà tempo e risorse per applicarli. Vado in giro a curiosare per i vivai e riporto qualcosa a casa; oppure immagino giardini che poi altri dovranno coltivare.

Chi passa mi dice ancora: ma vuoi una mano per cancellare tutto questo pasticcio? Ma non era meglio fare il rivenditore di Moodle?

Curriculi digitali opensource

Ott
25

Il bando http://www.istruzione.it/scuola_digitale/curricoli_digitali.shtml per i curricoli digitali attualmente in corso (scade il 10 Novembre 2016) prevede 4,3 M€, riservati alle reti di scuole pubbliche e paritarie, destinati alla produzione di 25 curricoli digitali su 10 tematiche, divise in Fondamentali e Caratterizzanti, secondo il seguente schema:

Fondamentali:

  • diritti in internet
  • educazione ai media (e ai social)
  • educazione all’informazione

Caratterizzanti:

  • STEM (competenze digitali per robotica educativa, making e stampa 3D, internet delle cose)
  • big e open data
  • coding
  • arte e cultura digitale
  • educazione alla lettura e alla scrittura in ambienti digitali
  • economia digitale
  • imprenditorialità digitale

Dal mio punto di vista, non è troppo condivisibile questa biforcazione: da un lato le “educazioni a…”, dall’altro il coding, la robotica, i dati aperti. Così si introducono già nei temi e nei curricoli le separazioni che poi è difficile recuperare: tra riflessione teorica e attività tecnica, tra aspetti etici (diritti, doveri) e pratici, tra apprendimento cognitivo e affettività. Ma pazienza, in qualche modo si doveva distinguere.

Il dettaglio dei possibili contenuti dei curriculi è descritto nell’Allegato 2 (http://www.istruzione.it/scuola_digitale/allegati/2016/Allegato_2_Avviso_Curricoli_Digitali.pdf). A mio avviso, si tratta di testi non particolarmente omogenei, perché scritti da persone diverse, come si capisce dal linguaggio utilizzato e dalla formattazione libera. Si può supporre quindi che sia stato dato l’incarico di definire i contenuti a esperti di dominio che non si sono parlati tra loro. Noto che di opensource non si parla mai, e pazienza (ma anche no).

Non mi è chiarissimo il processo di valutazione delle proposte di curriculo. Da quanto ho capito io, ci saranno tre fasi: in una prima vengono richieste solo poche slide di presentazione e un formulario in cui vengano definite le scuole partecipanti, di cui almeno una deve avere esperienze dimostrabili nel settore (solo una?). In una seconda fase, viene stilata una graduatoria e vengono selezionate 125 proposte. Ai soggetti selezionati viene chiesto di inviare il progetto con un esempio, e solo 25 proposte vengono alle fine finanziate, con un massimo di 170.000 € per proposta. Ci sono poi altri 50.000 € per la migliore proposta di comunicazione del progetto (mi è sfuggito come si partecipa a questa speciale categoria).

La commissione di valutazione verrà scelta solo dopo la chiusura della prima fase. I dettagli delle altre due, come pure i processi di monitoraggio, verranno, si spera, chiariti in seguito. Potrebbe succedere, ad esempio, che i curricoli prodotti si sovrappongano oppure che lascino scoperte delle aree? Che seguano modelli completamente diversi? Che lo sviluppo non rispetti le premesse? Speriamo di no, speriamo che sia prevista anche una fase di aggiustamento in corsa.

Ma a prescindere da questi dettagli, ci sono molti aspetti che giudicherei positivi: la sottolineatura dell’importanza degli aspetti di cittadinanza digitale, la richiesta esplicita che i curricoli siano rilasciati come OER (peccato non si diano indicazioni di licenze specifiche: i contenuti prodotti si potranno usare gratis, ma si potranno anche modificare?), la citazione almeno della possibilità di analytics ovvero di raccolta dei dati di utilizzo.

Nel passato, il Ministero dell’Istruzione aveva scritto e pubblicato Programmi e Indicazioni per i vari ordini di scuola. Con la “scuola dell’autonomia”, con il passaggio dalla scuola dei programmi alla scuola dei curricoli, questo compito spetta alla scuola. Le indicazioni ministeriali però esistono ancora, e quattro anni fa per esempio sono state sottoposte ad un processo di verifica pubblica quelle per la scuola dell’infanzia e del primo ciclo, cioè fino alla scuola secondaria di primo grado inclusa. Per altro, nel documento finale (http://hubmiur.pubblica.istruzione.it/alfresco/d/d/workspace/SpacesStore/162992ea-6860-4ac3-a9c5-691625c00aaf/prot5559_12_all1_indicazioni_nazionali.pdf , mi spiace ma non c’era un link più corto) la parola digitale compare solo quattro volte: due nel conteste delle competenze chiave raccomandate dall’Europa, e due nell’area Tecnologia. Leggendo i risultati della consultazione, si capisce che secondo il 24% degli intervistati il digitale avrebbe dovuto essere più presente.

Comunque: in questo caso, forse per la prima volta, si chiede ai diretti interessati, cioè alle scuole – o meglio, a reti di scuole coadiuvate da esperti universitari o altri scelti dalle scuole stesse – di realizzare dei curricoli di livello nazionale, da condividere con le altre scuole.

E’ una buona maniera di affrontare la questione? Non lo so, ma non mi convince in generale la logica dei bandi, che permette di distribuire soldi alla Scuola – anzi, ad alcune scuole – che poi magari le usano come possono, sulla base della loro abilità a scrivere progetti. Bandi che si limitano a finanziare la creazione di un oggetto digitale (che so, un sito, una piattaforma di collaborazione o di e-learning), ma non il suo mantenimento e sviluppo futuro, col risultato che il suddetto sito muore dopo poco. Bandi che stimolano migliaia di proposte, ma ne finanziano solo una piccola percentuale, per cui il lavoro della maggioranza è sprecato. Bandi i cui risultati non sono soggetti a verifica se non contabile. Bandi in cui la coerenza dei prodotti viene cercata a posteriori, magari con un bando ulteriore.

E’ una maniera democratica? Non so nemmeno questo. Va avanti la scuola che ha al suo interno docenti capaci di progettare, nel senso specifico di “scrivere progetti finanziabili”. E si procede in maniera discontinua, per gettiti intermittenti. Per esempio, mi domando: ma una volta creati i curriculi, quali risorse verranno impiegate per aggiornarli? E chi lo farà? O si pensa che in campo come questo si possa creare IL curriculo definitivo?

Si poteva fare diversamente? Io penso di si. Faccio un piccolo esercizio di immaginazione.

1. Si poteva creare un piccolo gruppo di lavoro (di cui venissero pubblicati i nomi dei partecipanti) con almeno quattro compiti diversi:

  • raccogliere buone pratiche da paesi dove questi curricoli esistono e sono già stati sperimentati con successo
  • valutare i risultati dei Piani Ministeriali passati sul tema dell’IT, luci e ombre
  • esaminare le esperienze già realizzate nelle scuole o dalle associazioni
  • raccogliere idee tramite una ricerca non solo sul materiale cartaceo, ma anche su quello digitale, compresi i social network system.

Alla fine di questo lavoro preliminare, il gruppo di superesperti avrebbe potuto produrre un documento che indicasse obiettivi, limiti, metodi, errori da evitare, buone pratiche. Il documento avrebbe dovuto evidenziare, tra l’altro, gli incroci tra le aree tematiche. Non solo un elenco di argomenti, quindi.

2. Poi il MIUR avrebbe potuto convocare un piccolo numero di esperti, tre per ogni area tematica (per esempio uno di estrazione universitaria, un docente e un esperto di dominio), scelti mediante una procedura concorsuale pubblica, fornirgli il quadro generale e dargli modo di produrre una versione alfa del curriculo.

3. Le versioni alfa avrebbero potuto essere condivise preliminarmente tra tutti i gruppi, per verificarne la coerenza e l’omogeneità e la rispondenza al quadro generale.

4. La versione beta, risultante dal lavoro di omogeneizzazione, sarebbe potuta essere diffusa presso un numero più grande di docenti, dei quali si sarebbero raccolti i commenti. Si sarebbe potuta immaginare una piccola sperimentazione per tutti i curricoli, per permettere ulteriori aggiustamenti.

5. La versione RC (release candidate), risultato della sperimentazione, sarebbe stata pubblicata in una piattaforma aperta dove tutti gli utenti potessero suggerire miglioramenti. Non essendo necessaria una “versione finale” congelata, i curriculi avrebbero potuto essere aggiornati in maniera continua, o “forkati” come si fa nei repository di software opensource.

Costo totale: quasi sicuramente inferiore ai 4,3 milioni investiti nel bando. Immaginando trenta persone che lavorino per un anno a tempo pieno, fanno più o meno un milione di €, più il costo del gruppo iniziale dei superesperti (che voglio sperare non costerebbe altri tre milioni di €…). Con i soldi avanzati si regalava carta igienica a tutti…

Coinvolgimento degli utenti finali: sicuramente maggiore, direi. Nella modalità scelta dal MIUR, supponendo che ogni team di progetto sia composto da 20 tra docenti ed esperti, il numero totale delle persone coinvolte è di 500. Che è meno dei docenti intervistati per le Indicazioni del 2012.

Qualità dei prodotto finale: non so dirlo, ma il processo descritto sarebbe servito a controllarla a più riprese. E la prassi dell’opensource insegna che questo modo funziona abbastanza bene.

Ma perché non sono nato là?

Ott
09

La citazione (che dovrebbe essere chiara per chi ha almeno cinquant’anni) è da Claudio Baglioni, ebbene si, “Viva l’Inghilterra”, anno 1973.

Si riferisce al fatto che mi danno (voce del verbo dannare) almeno dal 1999 intorno alla necessità di un’analisi (socio)linguistica del codice sorgente e non trovo un cane disposto ad ascoltarmi. O quasi, come si vede da http://steve.lynxlab.com/?p=73

Invece in USA e in Canada ci lavorano sul serio, dentro l’università, mettendo insieme ricercatori di linguistica e di informatica. E quest’articolo, pubblicato  nei Proceedings di una conferenza annuale del Psychology of Programming Interest Group che si tiene nel’UK, è finalmente (finalmente?) un esempio pratico di un tentativo reale di applicazione di modelli e strumenti sociolinguistici al codice sorgente da parte di un gruppo di ricercatori dell’Università di Lethbridge. Molto minimale ed embrionale, ma insomma esiste.

Schermata da 2016-10-10 21-59-45

Il tema è quello del genere. Si può riconoscere solo leggendo il codice se l’autore è uomo o donna? Pare di si. E che ce ne importa, diranno i miei piccoli lettori. Ci importa, perché come premettono le autrici, è il primo passo per vedere se nel codice ci sono tracce anche della lingua materna, delle conoscenze pregresse di altri linguaggi, del livello sociale o della cultura generale. E allora? Allora è il primo passo per riconoscere che il codice sorgente è un testo, risultato di un’attività di scrittura, e quindi può contenere  tutte le varianti possibili che una scrittura permette: stili, personalità, mode, esperienze trascorse. Non importa che il lessico sia limitato (ma estensibile a piacere) e che la grammatica sia molto restrittiva (ma permette forme alternative). Un programma, definitely, is not just an implementation of an algorithm which solves a problem. Si scrivono programmi per scopi diversi: per gioco, per sfida, per sperimentazione, per produrre un effetto artistico, per imparare. A monte si sceglie il linguaggio in cui scriverli, il che ha un effetto sull’orientamento generale del programma, su come viene letto, come verrà modificato e come sarà punto di partenza per nuovi programmi.

Ne deriva che quando si insegna a scrivere codice, come quando si insegna a scrivere – ma a scrivere bene – non basta insegnare la grammatica e il lessico. Ci vuole molto, moto di più. Ci vogliono buoni esempi (lettura), modelli, obiettivi, strumenti di valutazione. Ne deriva, probabilmente (ma questa è solo una mia ipotesi) che chi legge e scrive molto, programma meglio; che introdurre lo studio di come si crea e sviluppa una storia permetterebbe di ottenere dei codici sorgenti migliori, che come le buone storie “si reggono”. Le buone storie si tramandano nei secoli, come le fiabe; forse è così anche per i buoni programmi.

Rice, J. E., I. Genee, and F. Naz. “Linking linguistics and programming: How to start?(work in progress).” Proc. 25th Annual Psychology of Programming Interest Group Conference-PPIG. 2014.

Monitoraggio, brutta parola

Ott
09
Sul sito Programma il Futuro sono scaricabili dei report sui dati sulle attività svolte nel primo (http://programmailfuturo.it/media/docs/Rapporto-monitoraggio-settembre-2014-gennaio-2015.pdf) e nel secondo anno di progetto (http://programmailfuturo.it/media/docs/evento-celebrativo/programma_futuro-MIUR-26mag2015.pdf). Numero di ore, numero di insegnanti per regione e per disciplina, numero di classi e studenti coinvolti, e poi gradimento, valutazioni, osservazioni, tutti corredati di grafici. Dati raccolti in parte grazie a Google Analytics (altrimenti perché si attiva ogni volta che apro una pagina in Code.org?) e in parte grazie a questionari.
Questa cosa mi solletica.
Dieci anni fa, quando lavoravo a Scienze della Comunicazione, ho fatto una ricerca sui forum del corso concorso per dirigenti scolastici di INDIRE (2006). Siccome la piattaforma usata non prevedeva nessun tipo di monitoraggio fine (e peraltro non esisteva più…), siamo partiti da una copia del DB Oracle e siamo riusciti a ricostruire i profili, le conversazioni, i temi, le modalità comunicative. Il risultato principale è stato forse però l’insieme di query SQL che avrebbero permesso di analizzare allo stesso modo i dati di altri forum che usavano la stessa struttura dati, ad esempio per vedere se c’erano invarianti legate alla dimensione geografica, all’età, alle esperienze pregresse. Non mi risulta che siano stati mai usati, ma pazienza.
Cinque anni dopo, il MIUR ci affidò una ricerca per valutare il risultato di tre piani di formazione nazionali. La cosa anche qui fu piuttosto difficile, perché non c’erano dati originali, ovvero il progetto delle attività non contemplava la raccolta di dati prima, durante e dopo. Sono stati analizzati fondamentalmente i risultati di questionari somministrati ai docenti. Il che come si può immaginare non è la stessa cosa di avere accesso alle informazioni primarie.
Nella recente formazione per gli Animatori Digitali del Lazio, che mi ha coinvolto solo come tecnico fornitore di piattaforme, ho proposto di impostare un piano di monitoraggio all’inizio delle attività. Non per valutare nessuno, ma perché quando domani qualcuno arriverà a chiedersi se e come ha funzionato avrà bisogno di qualche informazione in più rispetto ad un sondaggio finale.
 
Insomma la fatica per ottenere dei risultati di qualche qualità mi pare inversamente proporzionale alla lungimiranza di chi gestisce un progetto. Se poi i dati raccolti (naturalmente anonimizzati) venissero resi disponibili come opendata (oltre alle elaborazioni in PDF), si potrebbe lasciare a chi ne ha voglia e competenze il compito di far emergere qualche idea buona (qui ho esagerato, vabbè).
 
Se ogni attività di coding fosse preceduta da una raccolta di informazioni (chi è il docente, che competenze ha, che lavori sono stati fatti con quella classe in precedenza) e magari da un test di ingresso, se durante le ore di coding si potesse registrare lo scambio tra gli studenti e con il docente o il processo di acquisizione di nuove forme sintattiche, se le attività fossero seguite da un test finale, se se se… ci sarebbero alla fine dati su cui riflettere. Anche senza avere per forza la pretesa di dimostrare che il coding serve (o non serve) ad un obiettivo specifico.
Magari verrebbero fuori delle connessioni a cui non si era pensato. Per esempio, l’influenza della famiglia o dell”ambiente sociale, o della lingua materna; il peso delle competenze informatiche del docente (o delle dimensioni dello schermo, o del tempo atmosferico, o del segno zodiacale del docente, o che so io). O magari non viene fuori niente. Ma senza quei dati non si saprà mai. Non mi sto inventando i Learning Analytics: se ne occupa tanta gente, la Microsoft nell’accordo con il Ministero dell’Educazione Nazionale Francese ha specificato che il suo intervento sul coding prevede anche questo tipo di attività di monitoraggio e analisi dei dati (http://cache.media.education.gouv.fr/file/Partenaires/17/7/convention_signee_506177.pdf, pag 4). Se lo fa Microsoft, a qualcosa servirà, no?
 
Quello che voglio dire non è tanto che ci deve essere un quiz alla fine che ci permetterà di dire se Mario ha imparato il pensiero computazionale (o uno strumento di analisi degli elaborati come DrScratch, http://drscratch.org/, – grazie Massimo per la segnalazione – che pure potrebbe essere utile); ma che una Piano Nazionale dovrebbe dotarsi dall’inizio di un protocollo e di strumenti per valutare la qualità di quello che fa, e non solo la quantità e le opinioni. Se Google ha costruito la sua fortuna sull’analisi dei testi e dei comportamenti della popolazione mondiale, ci sarà pure una ragione. Che, nel nostro caso, non è poter vendere pubblicità e servizi mirati, ma valutare globalmente un piano nazionale (non il coding), e per una volta non a posteriori.
E’ un suggerimento per il terzo anno…