Sabato mattina, caffè, InfoQ. Uber ha costruito GitFarm, un servizio che esegue le operazioni git al posto del client. Nessun clone locale: si chiama una API gRPC, dall’altra parte c’è un repository già pronto, e torna solo il risultato dell’operazione. Il motivo sta nei numeri che pubblicano loro. Clonare il monorepo Go di Uber richiede circa quindici minuti, sei core, 32 GB di memoria e più di 40 GB di disco.

Se il clone costa 40 GB e un quarto d’ora, il problema non è il clone.

Questa storia dei monorepo mi gira in testa da anni, ed è l’ennesimo articolo che pontifica sull’argomento senza mai arrivare al punto. La posizione da cui parto è sempre la stessa: il monorepo non serve a niente. Non ho mai trovato una ragione per tenere quattrocento cose in un posto solo, e ogni volta che qualcuno me ne dà una si sfalda appena la gratti.

Solo che è una posizione che non ho mai messo alla prova sul serio, e una convinzione che non provi a rompere non è una convinzione, è un pregiudizio. Quindi stamattina ho provato a romperla per bene, leggendo le fonti primarie invece dei commenti su Hacker News.

Si è rotta in un punto solo. Ed è quello che ho trovato guardando cosa restava in piedi che vale la pena raccontare.

Oggi voglio raccontarvi una storia. Non una di quelle storie edificanti sui “pionieri visionari” che troviamo nei manuali, ma la storia vera e cruda di come Java sia passato da linguaggio che ti odiava cordialmente a linguaggio che cerca almeno di capirti. È la storia di 30 anni di errori, testardaggine, rivoluzioni silenziose e quello che alla fine si rivela essere il più grande esperimento di ingegneria sociale mai tentato su 9 milioni di programmatori.

Oggi parlo di evoluzione dei linguaggi di programmazione, tema a me caro, chi mi conosce di persona sa quanto mi diverta seguire l’evoluzione tecnica degli strumenti che uso quotidianamente. L’occasione me l’ha data la rilettura di un pezzo di Richard Gabriel del 2003, “The Art of Lisp & Writing”, che inizialmente avevo catalogato come “ennesima difesa d’ufficio di Lisp da parte di un fan sfegatato”. Poi ho scoperto un dettaglio che cambia tutto: l’articolo è stato scritto come introduzione al libro “Successful Lisp” di David Lamkins nel 2003.

Il literate programming è un approccio alla programmazione che integra codice e documentazione in un unico flusso naturale, permettendo di pensare come esseri umani invece che come macchine. In questo articolo esploro come Org-mode di Emacs rappresenti l’implementazione più elegante e potente di questa filosofia, trasformando la documentazione da faticoso obbligo a parte organica e piacevole del processo di sviluppo.

Nel vasto e caotico universo dell’informatica, fermarsi equivale a scegliere deliberatamente di diventare il prossimo fossile digitale. Immagina un consulente Java che, forte delle sue certezze, si crogiola nel comfort delle sue conoscenze consolidate. Peccato che, mentre lui si rilassa, il mondo del codice continua a girare vorticosamente, lasciandolo indietro come un floppy disk in un’era di cloud computing.

Oggi vorrei parlarvi di un algoritmo.

Di norma un algoritmo talmente semplice da essere usato durante i colloqui per la valutazione della capacità minima di scrivere e leggere codice che comprenda il minimo indispensabile di logica, matematica e pensiero critico.

L’algoritmo consiste nell’implementare una funzione che dati i numeri da 1 a 100 faccia quanto segue:

• stampi la stringa “Fizz” quando il numero è un multiplo di 3
• stampi la stringa “Buzz” quando il numero è un multiplo di 5
• stampi la stringa “FizzBuzz” quando il numero è un multiplo di 3 o 5
• stampi il numero quando non è un multiplo di 3 né di 5

Semplice semplice. Ma allora perché ne parlo?

Di norma direi che il calcolo delle stime è qualcosa che facciamo tutti i giorni e che quindi almeno sulla carta ogni programmatore dovrebbe saper farlo.

Di norma direi anche che ci dovrebbe essere una procedura, una best practice una formula che possa calcolare una stima.

Siamo programmatori, quindi siamo ingegneri (più o meno)!

Ultimamente mi trovo spesso a leggere di sviluppatori che non conoscono determinati acronimi, o che si ritrovano a chiamarsi “sviluppatori” senza sapere cosa effettivamente significhi sviluppare software.

E come al solito mi triggero sulle basi e vado dritto come un pesce all’amo tentando di sviscerare un argomento che molti altri più bravi di me hanno tentato di sviscerare in libri interi spesso riuscendoci solo in parte.

Mi ripeto sempre che è una cattiva idea usare un blog per parlare di un argomento così vasto e che i grandi come Uncle Bob e Kent Beck si rivolterebbero nella tomba se ne avessero una.

Ma siccome sono entrambi ancora vivi, non temo questa reazione e quindi sbaglio con piacere, sperando anche di fare cosa gradita a quei 3 scappati di casa che leggono questo sito.

Inizio, dopo l’inizio, dicendo che le basi dello sviluppo di software sono tante, e lo sviluppo di software è un’arte complessa che merita tempo per lo studio e dedizione per la materia, mancanti le quali il software non può essere sviluppato oppure può esserlo ma sarà brutto, poco performante, difficile da mantenere e probabilmente pieno di problemi.

E soprattutto, un software sviluppato senza conoscere le basi sarà consegnato in ritardo, sempre. Qui non ci sono deroghe.

Il TDD è una di quelle metodologie che più spesso viene bistrattata qui in Italia. Spesso si sente definire questo approccio come troppo costoso o peggio come fallimentare.
Molto spesso la “colpa” va al budget, sempre troppo risicato quantunque esso sia, ma qui si sa che la coperta viene commissionata su misura per un watusso e poi arrotolata fino a non coprirci neanche un pigmeo. E quello deve bastarti, altra non ne srotolano.

Al di là delle facili critiche e delle superficiali battute tragicomiche, il fatto è che c’è molto ancora da fare per convincere i più biechi antagonisti di questa tecnica che vale la pena iniziare a fare dei test un componente necessario di ogni progetto.