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.

 

Criptare con emacs

Al giorno d’oggi si hanno tanti account, con tante password. Più una password è diversa dalle altre meglio è. Ma come proteggerle, evitando di segnarne sempre il meno possibile? Sotto MacOSX c’è il Keychain, ovviamente incompatibile con windows e linux.

Grazie a questo articolo, ho scoperto che emacs ha una serie di integrazioni con i meccanismi di criptazione a chiave pubblica e privata. As usual, emacs wins :)

 

Unison File Synchronizer

Several years ago I had the need of keep in sync three computers.  After some questions on a java mailing list, a very smart guy suggested me Unison.


Unison is a file-synchronization tool for Unix and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other.

Unison shares a number of features with tools such as configuration management packages (CVS, PRCS, Subversion, BitKeeper, etc.), distributed filesystems (Coda, etc.), uni-directional mirroring utilities (rsync, etc.), and other synchronizers (Intellisync, Reconcile, etc). However, there are several points where it differs:[…]

read the rest on  Unison File Synchronizer.

Unison seems a bit lost in cyberspace (no new features) but the users mailing list spot some activity, so I will suggest to give it a try, because its sync alghoritm is very well written, and the MS-Window interface is good.

The destiny of MySQL?

Slashdot underlines there are too much forks of MySQL on the way.

After leaving MySQL, Michael “Monty” Widenius started its own code fork, backed up with a company.

The nerds think the destiny of MySQL is unclear, but it is still too early to get a clear vision.

After acquisition of Sun by Oracle, it is difficult to see a future for MySQL.
Oracle has already a “non-commercial” developer-based license of Oracle, and there will be little interest in maintaining a competitor. The two forks above was an early signs of “brains escape” from MySQL.

Anyway, we will go forward to see what will happen.