La mia esperienza nell’open source

Nel 2011,  per studiare node js creai un progetto chiamato OrgModeParser.

Org Mode è un package per l’editor Emacs, ed è pensato per tenere note strutturate, pianificare progetti con una schedulazione, mantenere una lista di cose da fare e generare poi documenti word o html da tali file in modo piuttosto efficace.

Il package è di nicchia, nel senso che devi saper usare emacs per apprezzarlo, ed è molto più comodo di MS-OneNote una volta che ci avete preso mano. Ha inoltre il grosso vantaggio che i file che manipolate sono semplici file di testo strutturati, per cui possono essere aperti senza problemi anche con semplici file di testo.

Nel 2011 NodeJS era alla versione 0.4 ed era una “novità”.  Si trattava di un software pensato per far girare applicazioni javascript lato server, basato sulla versione Crankshaft (2010) di V8, il compilatore Javascript di Google, a cui Google lavorava almeno dal 2008. In particolare NodeJS integrava anche delle librerie asincrone, che lo rendevano un linguaggio ideal per sviluppare server “mono-processo multi-richiesta ad eventi asincroni”, il sistema più veloce che c’è per gestire molte connessioni consumando poche risorse.
L’importaza di V8 era dovuta al fatto che ai tempi JavaScript non era ancora dotato di una tecnologia così raffinata come quella messa in campo da Crankshaft, che in sintesi era in grado di compilare il codice dinamico di JavaScript in linguaggio macchina in modo piuttosto efficiente. Crankshaft prendeva spunto da StrongTalk, una variante di SmallTalk in grado di “tipizzare in modo forte” un linguaggio come Smalltalk, e quindi rendere più efficiente la sua compilazione in linguaggio macchina.

Per cui nel 2010 V8 era la tecnologia più avanzata, JavaScript stava diventando sempre più importante e NodeJS era una novità che aveva parecchia trazione.

Creai il progetto per OrgModeParser su GitHub. Il mio obiettivo era approfondire lo studio del modello asincrono di NodeJs, e difatti la prima versione del parser derivava da un parser scritto in python da tal Harles Cave.

Ai tempi JavaScript era un linguaggio piuttosto…bizzarro, in rapida evoluzione e non proprio lineare (per usare un eufemismo) per cui decisi di tapezzare il parser di test di unità, anche per ripassare gli idiomi più in voga.

Continuai ad aggiornare OrgModeParser ad intervalli irregolari, con una grossa pausa tra il settembre 2013 e l’aprile 2014.

Su Github iniziarono a fiorire subito un paio di fork al mio codice, e l’interesse per il progetto era piuttosto buono, considerato che altri miei progetti che ritenevo più utili erano quasi ignorati. In parte penso che questo fosse dovuto all’interesse intorno a nodejs, al fatto che JavaScript è molto immediato, e che il codice fosse organizzato in modo molto “standard” e pubblicato sul repository di nodejs chiamato NPM.

Ho ridotto le dipendenze al minimo e ho sempre fatto in modo che l’API fosse retro compatibile, per incoraggiare le persone ad aggiornare il software.

 

Senza particolare sforzo il mio parser è finito nella pagina del sito di OrgMode dedicata ai tools scritti in altri linguaggi.

Nel dicembre 2015 ho sviluppato un piccolo motore di rendering in html, e poi non ho avuto più tempo di occuparmi del progetto per un anno.

A fine 2016 mi sono accorto che erano fioriti parecchi fork ed estensioni del motore di rendeting html, per un totale di sei contribuzioni separate. Così ho inziato a fondere i vari contributi, sia quelli suggeriti (le “pull request”) che quelli più “timidi”.
Il 17 dicembre 2016 ho quindi rilasciato la versione 0.1.2

Nel frattempo ho ricevuto un paio di bug report, e avendo un po’ di tempo extra, ho continuato a lavorarci, per fare un nuovo rilascio prima di primavera…

Lesson Learned

Per alimentare facilmente un progetto open source è fondamentale generare interesse attorno ad esso. OrgModeParser non è stato molto pubblicizzato, ma la community intorno a NodeJS è così attiva che ha ricevuto più attenzioni di altri miei progetti scritti in Erlang, Java o Ruby.

GitHub (ma anche GitLab) è uno strumento fantastico per attirare contributi.

E’ vera la regola del “10 volte” sulle community: per ottenere un contributo bisogna avere almeno 10 persone interessate. A fronte di 100 “stelle” di interesse su github, org mode paser ha ricevuto un totale di circa 11 contributi sotto forma di bug report (3) e pull requests (8) e ha un totale di circa 28 fork separati.

Considerato che è un progetto che fa appena 1-2 rilasci all’anno, è un ottimo risultato.

 

Netflix italia: slow start

Ho provato per un mese Netflix. In Italia Netflix è stato lanciato a ottobre, concentrandosi su un set di serie e film. Il catalogo di netflix appare abbastanza risicato sul discorso film. Sulle serie se la cava benino, ma è omunque scarno. Sky Italia ha risposto con “SkyBox”, riuscendo a parare abbastanza bene il colpo.

Il sistema di sottotiti di Netflix è ben fatto, e anche la trascrizione italiana è migiore rispetto a quella di Sky. Anche il servizio di streaming (provato su Fastweb) funziona bene, e adatta la risoluzione alla banda disponibile. L’applicazione per iPad è ben congegnata, sicuramente superiore a quella di Sky.

 

“Do Over”
Si tratta di un film trasmesso “in esclusiva” su netflix con Adam Sandler. La trama è debole, e fa ridere pochino.
Se questo è un film in esclusiva, meglio perderli.
Voto finale: 4/10

“House of Cards”
Su Sky non è possibile vedere House of Cards in questo periodo, neppure con l’abbonamento alle serie chiamato “Sky Box”. Di norma tornerà in catalogo a settembre. Orbene, neppure su Netflix è visibile, probabilmente per un accordo di esclusiva con Sky.

“Better Call Saul”
Due stagioni da dieci episodi di una serie particolare, spinoff dell’avvocato di Breaking Bad.
Stile di regia originale, ma un po’ troppo lento.
Voto finale: 7/10

“Sens8”
Una serie che inizia con una persona che si suicida (sparandosi in bocca) per “collegare” tra loro gli 8 sensitivi. I primi tre episodi sono confusi, e la serie fatica a decollare. Se anche questa è una esclusiva… vabbé
Voto finale: 4/10

“Unbreakable Kimmy Schmidt”: altra serie “commedy” in esclusiva: non è il massimo, ma apprezziamo il tentativo.
Voto finale: 6/10

“Doctor Who”
Buona selezione delle serie del doctor who, inclusa l’ultima che viene anche trasmessa da Rai4
Voto: 8/10

 

Conclusioni

Se avete già SkyOnDemand / NowTV,  Netflix italia al momento non è allettante. Se invece non aveta ancora un abbonamento on demand, avrete una buona selezione di serie e film, tra cui spicca però la mancanza di cinema d’autore di un certo spessore e di serie come House of Cards. Alcune serie non valgono il prezzo dell’abbonamento, e anche Sky in estate ha rifilato croste come “The Signal”, un film bruttissimo del 2014.

Al momento Netflix italia non ha scompaginato le carte in tavola, anche se ha costretto Sky a creare lo “SkyBox” che migliora la disponibilità delle serie disponibili su Sky. Inoltre la app di Sky è progettata molto male e il suo uso è frustrante rispetto a quella di Netflix. Possibile che nessuno abbia mai visto la app di “Rdo”, uno dei servizi di streaming musicale più famosi?…

Il saggio progetto svedese, rinato: Elixir e Phoenix

This entry is part 1 of 19 in the series Programming Languages

Negli ultimi 20 anni sono successe tante cose imprevedibili. Nel 1995 nasce Java. Nello stesso periodo nasce Erlang. Java inizialmente segue la strada culturale tracciata da Sun, e si configura come un linguaggio estremamente verboso, con API specifiche per la gestione della concorrenza (es keyword synchronized per gestire nativamente le zone critiche che necessitano di mutex). Inzialmente Java è per far girare applet, poi Sun presenta un chip ad hoc (picoJava) poi IBM ci mette del suo e il linguaggio si trasforma in una ottima piattaforma per lo sviluppo server side.

Nel corso di questi 20 anni Java ha cambiato pelle almeno tre volte (applet, enterprise e ora macchina virtuale come base per linguaggi come Scala e Clojure). Le sue ultime evoluzioni hanno tradito un po’ le sue origini: sono stati introdotti i template (considerati “troppo complessi” nei tutorial del 1995!) e le “default implementation” nelle interfacce (una idea orripilante, ma tant’é….).

Mantenere tutta la retro compatibilità sta portando Java a diventare un linguaggio bizzarro: il codice scritto 6/10 anni fa ora si può riscrivere in modo completamente diverso.

Erlang ha scelto una strada diversa, è pensato per essere completamente asicrono e funzionale. Forse è stata solo fortuna, ma il piccolo linguaggio svedese ha retto bene alla prova del tempo, viene aggiornato circa una volta l’anno e anche se ha beneficiato di una frazione degli investimenti miliardari di Java, si dimostra efficace.

Al giorno d’oggi, dove anche un cellulare ha almeno un paio di processori, sviluppare sistemi che possano performare il meglio possibile su più processori è un must. E’ notizia di questi mesi che la Intel ha smesso di spingere la legge di moore (che consentiva un raddoppio della potenza dei processori ogni 18 mesi) a causa dei costi eccessivi che il processo di mignaturizzazione porta con sé. Si badi bene che ancora non abbiamo toccato il limite fisco teorico, è un problema di strategia e di costi.

In tutto questo scenario c’è Elixir, una evoluzione sintattica di Erlang con qualche buona freccia al suo arco, e un buon numero di librerie disponibili

Elixir svecchia la sintassi di Erlang lo rende più amichevole, è retro compatibile con le liberie Erlang e ha consentito la creazione di framework alla ruby on ralis chiamato Phoenix che sostiene di essere molto efficente.

C’è un aspetto critico che mi porta a insistere ogni anno su Erlang.

Quando facevamo l’università c’era un problema noto a tutti nello sviluppo di applicazioni client server (non necessariamente web).

C’erano due tipi sostanziali di tecniche:

  1. server multi richiesta multi processo
    Più semplici da programmare prevedevano la creazione di un nuovo thread per ogni richiesta in arrivo.
    Vantaggi: scala se hai tante richieste contemporanee, ma il costo associato alla creazione di un thread è molto alto.
    Ideale per task CPU Bound.
  2. server multi richiesta mono processo
    Più complessi e intricati da sviluppare, prevedevano un server che non si bloccava in attesa dei dati ma processava la prima socket client con dati pronti
    Vantaggi: scala bene se hai moltissime connessioni con parecchie latenze
    Ideal per sistemi I/O bound che non riescano a saturare il mono-processo.

Ora nessuna di queste due tecniche in realtà è migliore dell’altra, e in OOP non è banale bilanciare tra questi due approcci.
Per come è pensato Erlang però, è possibile avere i vantaggi di entrambe le teniche in un colpo solo!

Difatti l’architettura a processi stateless (anziché a istanze di classi su cui si “montano” thread) consente di sviluppare una macchina virtuale supervisore (un application server, per gli amanti di Java) che possa di volta in volta bilanciare tra l’esigenza (1) e (2).

Non è possibile ottenere questi vantaggi con un framework, come ha evidenziato il creatore di Erlang in un’email che ho ripreso tempo fa: si devono avere primitive di invio e ricezione di messaggi asincroni, innervate nella semantica del linguaggio.

Il fatto poi che Erlang sia funzionale e senza stato è stata la sinergia vincente. In caso di errore è banale far ripertire la parte di processi Erlang in errore; poiché sono privi di stato, l’anomalia viene limitata al caso critico.

Processi separati e senza stato consentono un Garbge Collector più semplice; in Java siamo dovuti arrivare al G1, la nuova implementazione a bassa latenza per risolvere alcuni problemi che i gestori di memoria automatici si portano dietro.