Alessio Biancalana Grab The Blaster di Alessio Biancalana

Go static – ovvero il vademecum di GitLab sugli static site generator

I ragazzuoli di GitLab hanno cominciato a fare una serie di tutorial veramente ben fatti sui siti web statici, essenzialmente per promuovere il loro GitLab Pages, servizio in concorrenza con il molto più celebre GitHub Pages, ma decisamente più flessibile dato che offre la possibilità di fare hosting di siti statici non solo basati su Jekyll, ma su molti più generatori scritti in (praticamente) qualsiasi linguaggio.

Nonostante questo, chiaramente a parte i rimandi al loro servizio di Pages, il loro drilldown è una lettura molto neutrale e piacevole.

Go Debian

Il mitico Paul Tagliamonte ha scritto una serie di tool in Go per interfacciarsi con l’ecosistema Debian. Dell’esperienza che ne ha ricavato, globalmente, possiamo fare tesoro, specie riguardo “cool stuff” e caveat del linguaggio stesso:

Some of the things Go is great at: Writing a server. Deaing with asynchronous communication. Backend and front-end in the same binary. Fast and memory safe. […] Things Go is bad at: Having to rebuild everything for a CVE. Having if err != nil everywhere. “Better than C” being the excuse for bad semantics. No generics, cgo (enough said)

E così discorrendo. Assolutamente da leggere per fare tesoro di tutto, soprattutto nel mio caso, ossia quello di un junior gopher affamato di conoscenza.

Bandiere, ruoli e workaholic

Oggi sono finito sull’about di Marco Arment per caso, e subito dopo su questo post (che parla della crescita di Tumblr, linkato nel titolo come sempre) che paradossalmente nonostante la mia ammirazione per lui non avevo mai letto. Fornisce degli spunti di riflessione a mio parere veramente buoni sull’operato di un CEO di un’azienda di prodotto, sul ruolo di un tecnico quando si parla di crescita dell’azienda, e su tante altre cose. Per esempio il posizionamento.

MySpace was where you went in the past, WordPress and Movable Type were where people went if they had the patience and writing output to maintain a traditional blog, Facebook was where you went to define yourself by schools and checkboxes, and Tumblr was where you went to make your own identity and express your creativity.

Mi sono anche rivisto parecchio nel ruolo di Marco come “esecutore di idee”; di base io sono una persona che ha molte idee storte, ovvero che non possono essere accoppiate a un valore di business. Viceversa mi piace molto scrivere codice elegante e costruire prodotti dando il mio contributo soprattutto in maniera tecnica, rifinendo un’idea preesistente:

David always had a vision for where he wanted to go next. I was never the “idea guy” — in addition to my coding and back-end duties, I often served as an idea editor. David would come in with a grand new feature idea, and I’d tell him which parts were infeasible or impossible, which tricky conditions and edge cases we’d need to consider, and which other little niceties and implementation details we should add. But the ideas were usually David’s, and the product roadmap was always David’s.

E in questo post ho anche trovato la più fedele riproduzione del mio pensiero riguardo il lavorare sotto un workaholic (perché me ne sono trovati diversi davanti nel tempo).

David always obsessed over his newest ideas, features, and designs until they were completely polished and ready to go. He’s a workaholic […] He expects people around him to be similarly into work and Tumblr, and often drove me hard with seemingly impossible demands. But David has a lot of Steve Jobs-like qualities, and like many people who worked for Steve, I look back on Tumblr’s crunch times with mixed feelings: I don’t want to return to that stress level, but David pushed me to do amazing work that I didn’t think was possible.

Certo, a me piace prendermi delle libertà. Non sono il tipo che si ammazza di lavoro, ma mi piace arrivare al traguardo in fretta con un buon prodotto. Per quanto sia deprecabile un atteggiamento che ti spinge a sovraccaricarti, comunque la realtà dei fatti è che a volte se il risultato sperato viene raggiunto pienamente ci si ritrova tutti più uniti come squadra. Questo non significa che ci sia sempre necessità di lavorare in questo modo, anzi; e dall’esperienza di Arment come lead developer, almeno per come la racconta lui, ho capito che per me non c’è niente di meglio che avere un goal fissato, formare una squadra, e dire “ok, quella è la bandiera: andiamo a prendercela”.

Prescindere da C nel 2016 – è possibile?

Purtroppo sono giornate veramente impegnative, per cui ho modo di scrivere poco, poco, poco. Per via di esami universitari e (sinceramente) un pizzico di diletto personale tuttavia mi sono trovato a scrivere di recente del codice C; e, riguardo questo, dato che C non lo toccavo da un po’ di tempo, oltre a leggermi The Linux Programming Interface di Michael Kerrisk, ho anche letto sia How To C (As Of 2016) che la rispettiva critica che ne è seguita. O almeno una delle più quotate :-)

Programmando programmando, mi sono chiesto: “ma è veramente possibile prescindere da C nel 2016?” – e beh, la mia risposta è che no, non possiamo. Non possiamo per una serie di ragioni, prima di tutto perché comunque conoscere il basso livello è importante per chiunque, per imparare che una macchina è un cuore pulsante di metallo e bit, quindi è bene (qualsiasi che sia il livello di astrazione) imparare a scrivere codice con criterio al fine di gestire le risorse in maniera non-cinobalanica. Probabilmente C come linguaggio e le tecnologie embedded come “target” insegnano più di tutto il resto come affrontare le problematiche con un approccio orientato al risparmio di risorse; non è la panacea ad ogni male, ma è sicuramente qualcosa che un programmatore deve conoscere e saper sfoderare alla bisogna.

E poi perché, diciamocelo, moltissimi runtime sono scritti in C (o C++), e sicuramente il C è ancora un linguaggio “fashioned”, dato che serve conoscerne quantomeno una fetta. È bello che ultimamente si stia riscoprendo “la gioia” del linguaggio compilato: negli ultimi anni c’è stato un rifiorire di tecnologie che permettono di avere molta potenza per le mani anche a basso livello. Il C, tuttavia, non è da dimenticare per nulla – anzi.

Negli ultimi giorni ho persino scritto un po’ di Makefile, dato che casualmente non l’avevo mai fatto :-D sto preparando un tutorial per niubbi, che poi pubblicherò. State tonnati.

Documentation first

Ancora un’altra frase iconica di Joey Hess, giuro che poi la smetto.

I write documentation first and code second.