KDE: nuova API per la decorazione delle finestre

- Open Source

KDecoration 2

Our decoration API is also showing it’s age. It’s cumbersome to use, too difficult to use. In fact there is a KDecoration and a KCommonDecoration – the latter trying to make KDecoration easier to use by for example providing buttons. The API got extended several times to support more features which are all optional. […] So what makes KDecoration2 better? Obviously it’s no longer QWidget or QWindow based. Instead it’s a pure QObject based API.

La citazione di cui sopra è di Martin Gräßlin, che mi fa sempre impazzire per la qualità eccellente della comunicazione di ciò che accade all’interno del ciclo di sviluppo della decorazione finestre di KDE. In sostanza, adesso KDecoration2 (ovvero il nuovo decoratore delle finestre in KDE Frameworks 5) espone una API basata su QObject, la quale immagino che renderà più flessibile la manipolazione della titlebar in modo da non introdurre solamente oggetti come i bottoni più classici dei classici, ma anche altro.

Un po’ come OS X, per esempio, o le header bar di GNOME Shell. Però fatte un po’ meglio.

Vi(m): impararlo con un solo video

- Open Source

Vim on a Linux shell with dwm

Ormai vi è diventato per me uno strumento di costante lavoro. Quando non mi viene richiesto un IDE lo utilizzo per scrivere codice e parecchio altro; soprattutto mi torna utile in tutti quegli ambiti dove un editor grafico seppur buono come Sublime Text non mi serve allo stesso modo. Proprio oggi sfogliando Reddit sono inciampato in un utilissimo video che insegna come usare vi (e conseguentemente anche vim).

Imparàtevelo. Vi servirà, ne potete star certi.

Come mi ricorda il mio amico Claudio che sta seduto qui affianco a me in treno a farmi da umarell mentre scrivo (:-D) su Linux potete servirvi di vitutor, che fa la stessa cosa in maniera leggermente più pratica e meno “videata”.

Docker 1.0: impressioni, analisi e previsioni

- Open Source

In questo periodo sono successe parecchie cose, per questo ho preferito tralasciare un pochino il blog, ossia adattarlo ai nuovi ritagli di tempo di cui dispongo (che sono ancora inferiori a quelli che avevo prima) – un po’ tipo Calcare con il suo, non so se avete presente. Dico questo solo per giustificarmi di un’assenza prolungata: c’entra ben poco con quello che sto per introdurre.

Dock

Sul finale di questo mio periodo di assenza infatti è stato annunciato Docker 1.0, ossia una milestone release del progetto che maggiormente, probabilmente, da un anno a questa parte ha attirato la mia attenzione. Docker è, in buona sostanza, un modo intelligente di sfruttare LXC per innestare le applicazioni che configuriamo in dei veri e propri “container” virtuali, i quali poi possono essere esportati su qualsiasi altra macchina. È richiesto solo Docker; fornita un’infrastruttura di base, tutto il resto continuerà a funzionare. Docker è versatile, perché è eseguibile in istanze virtuali, ma anche su macchine fisiche, e così via. La praticità di Docker è innestabile a qualsiasi livello, e questo lo rende una tecnologia perfetta anche a livello enterprise.

Cosa significa Docker 1.0

Docker 1.0 significa un sacco di cose. Principalmente, significa che ora come ora Docker è una piattaforma in rapida crescita, che si appresta ad avere come target il mondo enterprise ad un livello visto sinora solo con tecnologie come OpenStack (e, ehm, Linux? Ma voglio andarci piano coi paragoni). Per questo motivo, mi aspetto che in questi mesi e principalmente nel prossimo anno Docker raggiunga un livello di diffusione planetario, anche perché il suo primo periodo di vita depone molto bene a suo favore: con i numeri che ha alle spalle, sicuramente è diventato una tecnologia su cui investire del tempo, che magari in Italia viene snobbata per alternative vecchie come il cucco e sostanzialmente best-effort, ma che magari può fornire buone opportunità per consulenze in aziende estere, anche di grandi dimensioni.

Docker 1.0 significa feature: la codebase si ingrandirà, tanto che con questo traguardo già abbiamo alcuni importantissimi segnali di un progetto sano e di successo, come un registry pubblico dei container (simile ad npm per Node.js, ma per i propri dock), chiamato Docker Hub, e tantissime caratteristiche come ottimizzazioni sullo scheduling e sulla rimozione dei container che, beh, non fanno che rendere Docker più production-ready di quanto già non fosse. Di quanto già non fosse per un motivo ben preciso: Docker è un software che, a prescindere dalla bontà de facto del codice sorgente, è stato capace di tirare su dei numeri notevolissimi mentre lo stesso team di sviluppo si spolmonava (beh, più o meno) a scrivere ovunque “do not run in production”. E di irresponsabili, per così dire, in giro ce ne sono stati parecchi. Alcune cifre e alcuni nomi ce lo possono testimoniare.

Momentum: numeri e fatti su Docker 1.0

Ce lo dice l’annuncio di rilascio: Docker per tutto l’ultimo anno, dal 20 marzo 2013, è stato praticamente il protagonista dell’innovazione emergente dal punto di vista dei sistemi e della virtualizzazione in container. Quello che abbiamo davanti, da qualche settimana, è un tarball che dietro nasconde questo:

  • 460 contributor;
  • 8.741 commit;
  • 2.75 milioni di download;
  • 14.000 “Dockerized apps”, che suppongo siano container uploadati su quello che ora è il Docker Hub.

Ma non solo: Docker ha subito un pesante endorsement da aziende che fregandosene del suo status hanno cominciato ad integrarlo nella propria infrastruttura e a sperimentarci su. Per esempio, una serie di nomi molto interessanti, anche di aziende che producono software che usiamo sul nostro PC ogni giorno:

Per non parlare dei casi di studio forniti da Atlassian, PuppetLabs, IBM, Netflix, Google.

Docker: risorse interessanti e tutorial

Contestualmente a tutto questo fiorire di Docker nella produzione e nella pre-produzione di aziende il cui fatturato arriva ad essere una parte rilevante dell’economia globale, hanno cominciato a spuntare come funghi risorse su Docker, insieme a degli articoli che spiegano come sfruttare al meglio questo software all’interno di determinati processi. Ne ho da poco cominciato a stilare una piccola collezione, che riporto qui di seguito allo stato attuale, anche per tenere traccia di come ad oggi sia messo il panorama. Periodicamente condividerò anche altro, ma già ora – che Docker non è nemmeno diventato per così dire pronto per il panorama enterprise – ci sono diversi post che hanno suscitato il mio interesse.

  • Persistent volumes with Docker – Data-only container pattern – Un interessantissimo post che segnala come sia possibile creare dei container di soli dati per il management dei contenuti grezzi via Docker, in maniera da non perdere nulla, avere tutto ciò che facciamo tracciato tramite i sistemi di logging dell’infrastruttura e molto altro ancora. Utile, utile, utile. L’ho già detto utile?
  • Red Hat mashes Docker containers into its Enterprise Linux distribution – Yes! Docker è attivamente supportato da Red Hat, il che significa che nella prossima Red Hat Enterprise Linux questa tecnologia sarà installabile con un colpo di yum e un po’ di olio di gomito per quanto riguarda la configurazione. Certo, è un endorsement di piccola entità, ma venendo da un colosso come Red Hat che non dà mai niente per niente, sicuramente conta più che il Docker incluso in qualsiasi repository third-party di una distro a caso scalcagnata.
  • Analyzing Docker’s New OSS: libchan and libswarm – L’annuncio di Docker 1.0 non ha significato solo stabilità, ma anche una di nuove librerie completamente open source per la composizione di servizi di rete complessi che fanno uso (tra le altro cose) anche di Docker. Libchan, libswarm e libcontainer sono dei fulgidi esempi di come un’azienda possa innovare non solo con il proprio prodotto di punta, ma con un ecosistema di librerie a corredo che rendono possibili delle caratteristiche piuttosto utili. Nell’articolo trovate tutti i dettagli, ad esempio, di come con un banale docker ps sia possibile grazie a libswarm avere una panoramica dei processi in esecuzione in più container. È una lucidissima analisi di come queste librerie appena rilasciate possano letteralmente cambiare il modo in cui è concepita e implementata la cloud che utilizziamo attualmente.
  • Integrating Docker with Jenkins for continuous deployment of a Ruby on Rails application – Un caso di studio piccolo, se vogliamo elementare, ma esemplare. I grandi software possono essere messi alla prova anche e soprattutto con piccoli compiti, e Docker con Jenkins non sfugge a questa logica: con questo tutorial possiamo implementare un piccolo caso di continuous integration dove Jenkins costruisce dei Docker container, e se i test unitari vanno a buon fine, li esegue. Personalmente, apprezzo molto questo tipo di contenuti, anche perché mostrano applicazioni reali di software che altrimenti non avremmo (quasi) idea di come usare. L’idea di utilizzare Docker come layer mediano in una struttura del genere è interessante (e onestamente non so come ho fatto a non pensarci prima. Genio! [cit. René Ferretti])
  • Announcing Docker Automated Builds on Bitbucket – Atlassian non solo si impegna nello sperimentare con Docker, ma offre a tutti noi utenti di Bitbucket (e, ehm, spero presto anche di Stash) un modo per fruire delle Automated Build senza dover per forza ricorrere a GitHub. Un modo come un altro, questa partnership, per avvicinare delle community e generare un impareggiabile valore aggiunto.

Photo courtesy of Tristan Taussac

Telegram per Linux: arriva Sigram (finalmente)

- Linux

Sigram, Telegram per Linux

Già ho avuto modo di esprimermi molto favorevolmente nei confronti di Telegram, che al tempo dell’ormai “storico” down di Whatsapp aveva preso il volo come l’alternativa per la messaggistica più gettonata. Nonostante i dubbi sulla sua politica per quanto riguarda l’open source e la privacy degli utenti, comunque l’avevo reputato decisamente più sicuro del concorrente Whatsapp e personalmente ho avuto modo di apprezzare la possibilità di avere delle API pubbliche che permettessero lo sviluppo di client di terze parti.

Telegram per Mac è un gran software, con il quale mi sono trovato piuttosto bene negli scorsi mesi, ma sinceramente lavorando la stragrande maggioranza del tempo sul mio desktop Linux (si applari, avete sentito bene) ho sentito la mancanza di un client nativo per questa piattaforma, potendo solo fare affidamento su Webogram, un client web-based di cui è disponibile anche l’app per Chrome.

Per fortuna, come ho letto su WebUpd8, è stato sviluppato Sigram, un client per Telegram che gira su Linux e utilizza tutte le mie tecnologie preferite:

  • C;
  • C++;
  • Qt;
  • QML.

Praticamente un sogno a occhi aperti per chi ama le librerie Qt – e perché no, anche la loro portabilità. L’interfaccia non è nemmeno malaccio, giocoforza QML rende tutto il software un po’ webbarolo e il gusto degli sviluppatori, evidentemente deformato da eventuali esperienze in Silicon Valley (se non sono dei residenti), ha fatto si che implementassero questa UI flattona (neologismi come se piovesse oggi eh) che però non si accorda molto bene con Unity o con qualsiasi ambiente desktop presente su Linux. Forse con KDE va un po’ meglio, ma siamo lì.

Per quanto riguarda l’installazione, in maniera molto spartana, dagli sviluppatori vengono forniti dei pacchetti .deb che dovrebbero andar bene sia su Ubuntu che su Debian. Viceversa, per le altre distribuzioni, mentre alcune non sono supportate, per le più popolari Fedora (e OpenSUSE?) e Arch Linux abbiamo una assortimento non ufficiale di RPM e PKGBUILD.

Nel complesso, sono molto soddisfatto. Un grande grazie agli sviluppatori, e un buon Telegram come sempre a tutti.

A night at the Camera

- Open Source

Sono le tre e mezza di notte, e io mi trovo in un posto molto pittoresco. Probabilmente il posto più pittoresco in cui un hacker (un hacker civico, per giunta, cribbio) possa essere: il Parlamento. O meglio, non esattamente: sto dando una mano a coordinare Code4Italy @ Montecitorio, l’hackathon della Camera dei Deputati che mette a disposizione l’expertise dello Stato agli hacker che vogliono utilizzare i dati della Camera, e al contempo permette al gestore dell’infrastruttura di portare a termine un’operazione di controllo qualità notevole.

Sinceramente, non mi aspettavo una partecipazione come quella che invece c’è stata, data l’istituzione presente che fa sempre un po’ paura: è notevole invece l’impegno di alcune persone, che sono rimaste persino a programmare sino a quest’ora pur di portare a termine il loro progetto.

Andrea Ferlito e Simone Cicinelli pensano a cosa fare. na specie.

Tra i risultati di questa prima giornata di hackathon possiamo annoverare parecchia polpa:

  • Bug squashing dei dati: da alcune persone sono state scoperte alcune piccole incongruenze all’interno del dataset. Chiaramente le riporteremo e queste verranno corrette. Bug reporting dal vivo!;
  • Sono già disponibili degli esempi di query SPARQL relativi all’endpoint della Camera: prima dell’hackathon non c’erano, e sicuramente è una buona occasione per cominciare a raccogliere le richieste e a rendere molto più fruibile quello che c’è;
  • Idee interessanti in ambito applicativo. Ma non le scriverò adesso, sarebbe un bello spoiler, anche se guardando nel posto giusto potete scoprire tante cose interessanti;
  • Hai voglia a controllare, siamo finalmente riusciti a sdoganare il mito e ci siamo tolti la giacca senza che gli assistenti parlamentari piombassero su di noi come falchi. Forma over sostanza.

È emozionante come ci stiamo devastando in una sede simile. Nonostante l’austerità di un luogo come la Camera, non esitiamo a farci venire delle borse sotto gli occhi da paura, e poi mescolare un’istituzione così rigida e con meccaniche così stringenti con un ambito quasi “facilone” come quello degli hackathon è decisamente divertente. Domani ci saranno le presentazioni dei risultati finali (grossomodo…), e sono orgoglioso dei developer che sono rimasti svegli con me: possiamo dire di esserci presi il Parlamento, anche se solo per una notte.

Saluti.

Un assonnato Ale

Firefox: niente pubblicità nelle nuove schede

- Open Source

Firefox

That’s not going to happen. That’s not who we are at Mozilla.

Stimo molto Mozilla, e una delle cose che durante gli scorsi mesi mi ha lasciato stupefatto è stata proprio la decisione di mandare in pensione la politica di non sponsorizzazione (per così dire) di alcunché al fine di favorire l’afflusso di denaro alla fondazione tramite il – secondo me – becero meccanismo del piazzare delle pubblicità nella schermata relativa alle nuove schede di Firefox.

Quello che mi ha stupito molto poco invece, chiaramente, è stato il feedback parecchio negativo degli utenti nei confronti di questo tentativo di bravata da parte del team di sviluppo. Nel giro di poco, Mozilla ha ridiscusso la cosa (passo che credo faccia parte dell’iter attraverso cui deve passare ogni feature) e proprio oggi Johnathan Nightingale, VP di Firefox, ha rilasciato un comunicato dove non solo viene ufficializzato il dietro-front, ma vengono anche avanzate quelle che potrebbero essere considerate scuse.

We’ll experiment on Firefox across platforms, and we’ll talk about what we learn before anything ships to our release users. And we’ll keep listening for feedback and suggestions to make this work better for you. Because that’s who we are at Mozilla.

Questo non significa solo che noi utenti banalmente non saremo costretti a doverci sorbire della pubblicità anche “dentro casa” per così dire, ma anche che ancora una volta uno dei baluardi del software Open Source si è tirato fuori con eleganza da una morsa capitalista che ora più che mai è inutile, mostrando ancora una volta quanto sia importante la sostenibilità di un progetto, piuttosto che il profitto che ne viene ricavato.

Ben fatto Mozilla. Adesso ho di nuovo fiducia in te.

Photo courtesy of conwest_john

Cloud server – su CloudAtCost ci sono i saldi

- Web

Cloud computing

Nonostante DigitalOcean mi offra un servizio più che soddisfacente, non mi piacciono più di tanto i canoni annui: è per questo che già da un po’ di tempo cercavo un momento per mettermi a tavolino e dare una chance a CloudAtCost, che con i suoi piani “lifetime” è davvero allettante. In pratica, il servizio che viene offerto è simile a quello di DigitalOcean, con un pannello di controllo meno bello ma con la possibilità di scegliere tra il pagamento mensile o un pagamento una tantum per la propria istanza.

I prezzi per il pagamento a vita non sono nemmeno malvagi: se avete necessità di una VPS, tutti i piani su CloudAtCost sono scontati del 25%, e il piano Big Dog 3 (quello più ciccione) è in saldo al 50%. Secondo me sono prezzi pazzi: con qualche spiccio in più di un centinaio d’euro ho preso per la vita un serverino con 2GB di RAM e 40GB di storage SSD. A vita.

Mica male no? Mi riservo di provarlo per un bel po’ di tempo, per poi sfornare (almeno, spero di ricordarmi) una comparativa approfondita. Chiaramente al momento del mio acquisto DigitalOcean, verde di invidia, ha lanciato il primo batch di IPv6; ma è così che funziona il libero mercato no? :D

Photo courtesy of incredibleguy

Fedora 21 – GNOME girerà su Wayland (aka: mi preoccupo)

- Linux

Fedora on a MacBook Pro

Sembra incredibile ma non lo è: a quanto pare nella prossima release di Fedora vedremo GNOME girare su Wayland, almeno in via sperimentale. Sinceramente, ho molte perplessità su questa decisione, tant’è che non solo penso che Wayland non sia ancora realmente pronto per un utilizzo del genere, ma ritengo che a maggior ragione Fedora 21 subirà un cambiamento di rotta relativamente a questo punto.

Nonostante quella che è solo una mia mera opinione, comunque, il FESCo ha “appena” approvato il ticket, che è stato riportato nella minuta dell’ultimo meeting. Fedora 21 quindi accresce il suo grado di complessità, e proprio per la grande sfida che tutto il team di sviluppo sta affrontando, ogni giorno cresce anche il mio interesse verso il loro prodotto finale.

Mi lascia perplesso un punto: potrò giocare con la mia macchina (hint: probabilmente no)? O dovrò ridurmi a utilizzare i driver liberi? Nel secondo caso probabilmente cambierei (ancora) distribuzione, ma non posso che ammirare chi si impegna così fortemente per il futuro di Linux. Davvero.

Photo courtesy of pjen

LibreSSL e il porting su altre piattaforme

- Open Source

Finalmente sto iniziando a guardare i primi vagiti di LibreSSL su altre piattaforme, e pur non avendone scritto qui la questione Heartbleed è stata un bel bailamme da seguire, dato che ha tirato in ballo una serie di questioni notevoli sul futuro del software open source e sulla presunzione di sicurezza di alcuni sistemi.

Lock

Sempre per parlare di presunzione di sicurezza, Insane Coder durante un piccolo processo di review di alcuni port di LibreSSL ha effettivamente dimostrato come il grado di sicurezza di LibreSSL diminuisca a seconda della piattaforma utilizzata (il che è anche colpa delle prassi di porting di alcune funzioni); questo non è solo un problema di SSL, ma è anche un campanello di allarme che dovrebbe farci riflettere sulla sicurezza delle piattaforme che usiamo di solito e su cui siamo abituati a sviluppare.

There’s a couple of other significant mistakes I’m expecting to see appear in LibreSSL ports, but have not seen yet. These probably already exists in ports I haven’t reviewed, or will exist in the wild soon enough. Chief among them is implementing timingsafe_bcmp(). I’m expecting to see implementations which directly wrap to regular bcmp(), which unlike the former, is not performed in constant-time, and can expose the application to timing attacks.

Insomma: non è che adesso c’è LibreSSL ed è tutto a posto. Dobbiamo continuare a tenere gli occhi aperti, perché anche se aggiustiamo un anello della catena ci sono due tipi di criticità che si presentano a questo punto.

  • Aggiustare un anello non significa aggiustare tutta la catena: la sicurezza di un particolare strato non assicura che il resto della piattaforma sia a prova di bomba;
  • Inserire un anello nuovo in una catena di tipo diverso è difficile e dev’essere fatto nel modo giusto, garantendo che il risultato non sia troppo debole.

Photo courtesy of Patrick H.

Fotografie da #SOD14, tra dati e tagliatelle

- Open Source

Il weekend che è “appena” (sono ancora in tempo, è venerdì!) passato l’ho trascorso con i miei amichetti di Spaghetti Open Data, a discorrere di dati aperti, apertura di nuovi dataset, e finalmente nuovi bisogni all’interno della community e all’interno della pubblica amministrazione. A #SOD14 abbiamo parlato di OpenStreetMap, di CKAN, e di come un progetto che tira avanti grazie alle contribuzioni (di dati) esterne possa essere facilitato da enti più o meno strutturati ed aderenti a una serie di regole scritte. La burocrazia che non ci piacerà mai troppo poco.

E poi abbiamo sussurrato (non troppo sotto voce) del mitico ed evanescente hackathon alla Camera dei Deputati, che ormai è di dominio pubblico, quindi lo ripeto: si ragazzi, si farà, e sarà una figata. Un po’ meno per noi giudicare che diavolo avrà prodotto la community in meno di 48 ore di sviluppo martellante, ma posso garantire che da lontano si prospetta uno sforzo sicuramente interessante.

Nonostante sia stato meraviglioso ogni momento passato dal sottoscritto al fianco dei compagni opliti lungo la conferenza del venerdì, l’hackathon del sabato (in cui ho contribuito ad Open Data Census – e daje!) ed il momento formativo della domenica in cui ho imparato da Marco Brandizi e Diego Valerio Camarda (più tutta una serie di altre persone, ma Marco era l’eminenza grigia e con Diego ormai siamo amichetti, tollerateci) come diavolo funzionano i linked data, mi sono permesso di prendere qualche appunto sullo stato dell’arte della nostra missione in Italia, di dove siamo e di dove stiamo andando a finire.

Matteo Brunati a #SOD14

2014: la maturità del panorama open data italiano

Al Green Open Data, ormai diverso tempo fa (anni? Non ricordo), mi sono alzato in piedi e ho avuto il coraggio di dire che non bastava liberare dati a caso, ma questi dati dovevano seguire grossomodo delle descrizioni comuni, una notazione omogenea (e qui ci viene incontro l’ambito Linked, me ne rendo conto, ma la facevo più semplice), una serie di regole anche relative alla qualità per cui un diamine di sviluppatore che si trovasse a scremare quella pletora di numeri non dovesse per forza impazzire tra errori umani e insiemi di dati disomogenei.

Beh, improvvisamente non solo la società civile se n’è resa conto insieme a me pian piano, ma addirittura i pubblici amministratori hanno cominciato a capire che favorire il riuso dei dati da parte di una comunità di persone attive non è qualcosa che viene innescato al momento del rilascio, ma segue una dinamica completamente diversa. Allo stesso modo chi prima chinava il capo e ringraziava in maniera quasi fantozziana i liberatori di rumenta selvatica, adesso sta iniziando a farsi sentire, perché effettivamente lavorare su un dato “brutto” significa raffinarlo, portare avanti la ricerca e non poter nemmeno contribuire indietro le modifiche – dato che comunque le istituzioni non sono preparate a gestire un “ritorno” di informazioni di questo tipo – beh, tutto questo significa doppio lavoro per tutti. Ed è interessante (ne sono più che lieto) che anche al secondo raduno storico di Spaghetti Open Data, finalmente, si sia creato il clima per parlare di rilascio in maniera seria, strutturata e tra persone adulte che più che alla visibilità, sono interessate all’effettivo risultato.

Ogni dataset è bello a mamma sua

“Noi abbiamo più dataset” – “Si ma io ho più triple di te” – “Noi abbiamo l’API, l’endpoint SPARQL e pure un kiletto de guanciale”

Ho notato che improvvisamente (o progressivamente durante l’ultimo anno, dipende da quanto granularmente analizziamo il fenomeno) il tema della produzione dei deliverable che affligge chi fa open data si è spostato dall’autoreferenzialità più assoluta, come l’analisi della cardinalità di un linked dataset (quando è linked), all’analisi di cosa produce la liberazione dell’informazione. Questo è interessante, perché ho sentito finalmente pubblici decisori che in veste di civil servant hanno detto chiaramente che è ora di smettere di misurare chi ce l’ha più lungo, e cominciare a fare un lavoro di disseminazione serio.

C’è stato quindi uno spostamento del baricentro, da quanto effettivamente siamo fighi se liberiamo tanti dati, a quanto effettivamente siamo fighi se liberiamo una caterva di cose ma di queste ne vengono usate ben poche – se non nessuna. Finalmente le amministrazioni e anche alcuni evangelist del tema hanno capito che far prender polvere a dei dataset non è bello per nessuno, e hanno cominciato a cercare una soluzione al problema. In sostanza, ogni dataset è bello alla PA sua, ma effettivamente i primi ditini sentenziosi cominciano ad alzarsi, a ragione: come possiamo toglierci da questo impiccio?

Toc toc, sono l’engagement e non cresco sugli alberi

La soluzione principesca venuta progressivamente a galla durante le tappe in giro per Bologna del raduno – tipo alla Pizzeria Il Sellaio, dove fanno una pizza condìta che levati proprio, da leccarsi i baffi – è quella di stimolare gli sviluppatori a produrre prodotti buoni utilizzando i dataset, tramite operazioni di scouting mirato alle community e, perché no, tramite la produzione di esempi facenti uso dei dataset, in modo da produrre un circolo virtuoso in cui lo Stato dà il là, e la società civile in qualche modo risponde con il seguito di un circolo virtuoso che può solo fare benissimo.

Si è capito, quindi, non solo che l’engagement non cresce sugli alberi, ma che fare engagement sul territorio (e non solo) per quanto riguarda i dati è qualcosa di terribilmente complesso, che richiede delle risorse notevoli e che magari non è nemmeno tanto alla portata di un ente come una PA. Code For Italy (tanto per citare un progetto a caso) funge da collante proprio per operazioni come queste, dove un amministratore vuole cercare di coinvolgere quanto più possibile la popolazione in attività sostanzialmente di welfare proveniente dal basso, se vogliamo.

Luca Corsato e Peppa Pig

Master Chef

Durante il raduno, chiaramente mentre ero assente perché mica posso fare sempre il bravo ragazzo, sono stati assegnati dei diplomi di Open Data Master Chef ad un sacco di membri della community che secondo il parere delle teste più anziane hanno dato un contributo rilevante a loro modo (almeno credo) al progredire del gruppo. Sono stato insignito del titolo di Master Chef appena arrivato all’hackathon del sabato, e nonostante poi mi abbiano detto “seh vabbeh tanto l’abbiamo dato a un sacco di gente”, è un onore comunque far parte di Spaghetti Open Data. A #SOD14 abbiamo dimostrato ancora una volta cosa può fare, di cosa è capace una community completamente grassroot come la nostra, capace con la sola forza del numero e della creatività, di tirare fuori costantemente nuovi spunti tecnologici, filosofici, amministrativi.

Allo stesso tempo, in un raduno come #SOD14 è possibile scoprire che le persone hanno anche una faccia. E Luca Corsato ha pure gli adesivi di Peppa Pig attaccati sul computer. Trovarsi di persona è sempre bellissimo, e chiaramente permette anche di accelerare ove possibile il ritmo di produzione di idee e prodotti da parte di una community che, ormai arrivata all’asintoto per quanto riguarda gli utenti a loro modo attivi, ha la necessità di bypassare le fasi in cui si genera più overhead durante le comunicazioni.

Una speranza personale? Ovviamente, che il repository GitHub di Spaghetti Open Data si popoli ancora maggiormente, alla luce anche delle idee emerse durante #SOD14.

Matteo Brunati ha una barba meravigliosa

Nulla mi ha stupito, di #SOD14, più del trovare Matteo ‘dagoneye’ Brunati con una barba che poteva solo raccogliere complimenti. A parte gli scherzi, non solo Matteo mi ha fornito un’interessante ispirazione per il mio look, ma anche un’overview di come funzionano alcuni grossi progetti, come ne è strutturato il workflow, e come vengono ammesse le persone. Tutto materiale per farmi un’idea e decidere insieme alla community nascente cosa diavolo deve diventare Code For Italy (anche se probabilmente lo scopriremo solo vivendo).

Un’ultima parola? Daje.