Alessio Biancalana Grab The Blaster di Alessio Biancalana

Codemotion Milan 2017: siamo tutti una unica grande famiglia (serverless) 💻 🚀 🏎

e il cui albero genealogico è memorizzato su una blockchain. Ma scherzi a parte 😎

Codemotion Milan 2017

Sono passate a malapena ventiquattro ore dal mio ritorno a casa dopo questo Codemotion Milan 2017; ho fatto fatica a cominciare la scrittura di questa retrospettiva per il semplice fatto che in due giorni sono successe tante, troppe cose – e insieme ai “fatti” ci metto anche tutte le informazioni da metabolizzare e rielaborare. In ogni caso, sono veramente grato a tutto l’ecosistema italiano del software development per avermi regalato due giorni da sogno.

Giorno 1

Il primo impatto che ho avuto con Codemotion Milano è stato a causa della nuova location di quest’anno: passata la fila per il badge mi sono trovato catapultato in qualcosa di nuovo, ossia il BASE Milano. Un posto decisamente diverso dal Politecnico che ha ospitato la conferenza sino ad ora. Essendo un gigantesco open space, non pensavo che avrebbe funzionato bene suddividere lo spazio tramite “enclosures” per poi dare ai partecipanti un paio di cuffie a testa per ascoltare gli speaker in mezzo alla confusione generale; e invece dopo la keynote session in cui guardavo la location abbastanza sfiduciato, devo dire che con quelle cuffie abbiamo ingranato alla grande.

A proposito di keynote session, la keynote è stata spettacolare: innanzi tutto un applauso ai ragazzi di Codemotion per averci portato Salvatore “antirez” Sanfilippo, e un applauso ad antirez stesso, che con i suoi feedback su 8 anni di sviluppo di Redis mi ha fatto veramente emozionare parecchio. Ho avuto occasione di parlarci anche in separata sede, sia in caffetteria che durante la cena speaker (grazie a Francesco per avermi portato con sé!), ed è una persona di una saggezza infinita, di un’intelligenza rara, e di una purezza che in altri rockstar developer di oggi fatico a trovare. Mi ha colpito, e devo dire che le chiacchierate con lui mi hanno aperto la mente su svariati temi.

Io, antirez e il buon Luca Ronca

Proseguendo, ho seguito Luciano Mammino con il suo “Cracking JWT tokens: a tale of magic, Node.JS and parallel computing”: un talk veramente ben confezionato, non proprio entry level ma nemmeno così esoterico che ha mostrato alcune vulnerabilità relative a JSON Web Token, specialmente per quanto concerne i secret. Usate sempre secret robusti e memorizzati nei vault giusti!

Nei due giorni, a partire da dopo il talk di Luciano, ho persino avuto degli incontri più e meno ravvicinati con i ragazzi del Team per la Trasformazione Digitale del governo italiano. Nello specifico ho incontrato più da vicino Riccardo Iaconelli, mentre il buon Alessandro Ranellucci l’ho solo visto da lontano, e mi è piaciuto molto che durante un evento del genere i nostri eroi abbiano trovato il modo di ritagliarsi un momento per raccogliere proposte dai community leader che erano presenti.

Dopo il pranzo del primo giorno ho seguito Lorenzo Barbieri di Microsoft che parlava di Functions As A Service su Azure, e malgrado il suo talk mi sia piaciuto molto l’ho trovato un po’ troppo orientato ai CTO e poco ai developer smaliziati. Mi rendo conto che c’era poco tempo per spiegare tutto, ma un po’ più di codice e qualche esempio visto più profondamente mi avrebbe fatto piacere. A parte il contenuto su cui per forza di cose immagino abbia dovuto tagliare, per me Lorenzo rimane uno dei punti di riferimento per quanto riguarda le tecniche di public speaking 😸

Poi è stato il turno di James Ferguson, direttamente da SkyScanner: il suo “A design system. A year in review.” è stato una bella sorpresa, perché ha affrontato alcuni temi che sto tentando di sviscerare anche in azienda, e mi ha dato dei consigli utilissimi, come il fatto di gestire il proprio design system tramite un’architettura monorepo basata su Lerna e Storybook. In ogni caso, è stato interessante vedere che per adottare un design system in maniera sensata, il primo ostacolo da superare sia proprio la mente delle persone, e in quello può sicuramente servire un bravo facilitatore che riesca a mettere tutti sul binario giusto per cooperare.

Matteo Manchi: React Native in practice

Subito dopo è stata la volta del mio amichetto Matteo “takeno” Manchi, con “React Native for multi-platform mobile applications”. Che dire? Un talk essenziale, fatto bene, che fa capire le potenzialità di React Native a chi non lo conosce, e soprattutto a chi è interessato ad adottarlo per un uso aziendale. Di più non posso dire, o mi perderei in lodi dato che Matteo ha una dialettica veramente affine alla mia, con cui riesce sempre a catturarmi (e spero a catturare anche gli altri!).

Dopodiché, il meetup dei meetup con Andrea Ferlito a fare da boss della situa. 🚀

E dopo ancora, la cena speaker durante la quale abbiamo formato un meraviglioso manipolo con Matteo Manchi (again! Ma ve l’ho detto che gli voglio bene), Marco Liberati, Francesco “de-vasto” Malatesta e Mattia “raibaz” Tommasone, ascoltando antirez che parlava di università, di Golang, e di un sacco di altre cose. ❤️

Giorno 2

Il secondo giorno ancora un po’ insonnolito ho seguito Justin Cormack di Docker con “The 10 Container Security Tricks That Will Help You Sleep At Night”: alcuni consigli erano un po’ triti, altri veramente non banali. Oltretutto Justin è stato disponibile per le domande anche dopo durante il networking. In particolare, tra i consigli ho apprezzato molto quello sul distruggere spesso i container in modo che attaccanti malevoli non abbiano la possibilità di aprire una backdoor di lunga durata bensì debbano sempre riprovare a sfruttare le falle (falle che con container circa “rolling release” vengono sempre patchate, oltretutto).

Rafal Gancarz, con “Serverless for the Enterprise”, era partito benissimo, poi nonostante abbia mantenuto il suo talk su un livello più che decente, ha deciso di infilare dopo un hello world con Amazon Lambda il suo personale punto di vista sul catalogo serverless di Amazon, prodotto per prodotto. Diciamo che per quanto abbia provato a seguirlo e per quanto la qualità fosse comunque presente, la parte centrale del talk è stata un po’ sterile.

Uno slot l’ho saltato per andare a pranzo con la mia amica Alice ❤️

E sono tornato a bomba con il talk di Francescone Malatesta: “Costruire una Community: ‘What You Give is What You Get’”, dove il mio stimatissimo esimio collega ha messo in luce i vantaggi di partecipare alla vita delle community che troviamo sulla nostra strada durante la nostra vita professionale e non. Sinceramente mi è anche scesa la lacrimuccia quando ha annunciato di voler lasciare Laravel-Italia. Dopodiché tra una chiacchiera e l’altra ho dato il mio arrivederci allo zio Chicco, e avendo fatto un ultimo giro per salutare tutti gli amici sono corso in stazione per il treno, per andare a casa.

Alla fine di tutto questo, ho solo un consiglio, rivolto specialmente agli speaker che hanno affrontato le tematiche blockchain e serverless computing: fateci vedere casi reali. Ci siamo rotti il 🍆 di assistere a talk che sembrano la versione un po’ più lunga e discorsiva di “Serverless 101”, e come funziona una blockchain lo sappiamo da un bel po’, tra proof of work e distributed consensus. Fateci vedere applicazioni reali, ve ne prego. Casi di studio, codice, e così via: vogliamo vedervi mettere le mani tra lo sporco, si chiama Codemotion, non Slidemotion, quindi vedete di darvi una smossa e per la “big thing” dell’anno prossimo (tanto ‘sta roba sarà già passata di moda) portate qualcosa di ciccione e di impegnativo da farci digerire.

Gli amici che mi hanno fatto passare due giorni memorabili si meritano una menzione speciale qui sotto (e per chi non ci fosse, sappiate che la cosa è puramente intenzionale (scherzo)):

  • Luciano Mammino (ti devo ancora un caffè mortacci mia! Giuro che la prossima volta mando a cagare tutti quelli che ci interrompono)
  • Marco Vito “mavimo” Moscaritolo
  • Francesco Malatesta (again)
  • Matteo “takeno” Manchi (again)
  • Marco Liberati (again)
  • Alessandro “lifeisfoo” Miliucci
  • Giuseppe “sanfra” Sanfrancesco
  • Daniele “wifau” Faugiana
  • Enrico “wolf4ood” Risa
  • Niko “mogui” Usai
  • Angelo Quercioli
  • Roberto “rebtoor” Alfieri
  • Luca “zeta3” Annunziata
  • Luca Ronca, Davide Barbesino, Gabriele Genta e tutta la stupenda ciurma di AdEspresso

Ad maiora! 🚀

Container su Linux in 500 righe di codice

Per un’introduzione formale ai cgroups, che sono il meccanismo sottostante alla “magia dei container” su Linux, un buon punto di riferimento secondo me sono le slide della LinuxCon 2016 di Michael Kerrisk. Viceversa, per chi volesse un esempio pratico di uso dei cgroups, “Linux containers in 500 lines of code” è meraviglioso.

È meraviglioso per due motivi, il primo è che sicuramente da qui capiamo un po’ di programmazione di sistema con tutti i crismi, il secondo invece è che viene mostrato quanto sia semplice, persino in C, iniziare a pastrugnare con questa meravigliosa feature che è il cuore pulsante di tutto quello che fa Docker, per esempio 😎

Kubernetes: primi passi 🐳

Onestamente? Sono anni che voglio imparare Kubernetes. Peccato che per qualche motivo finisca sempre per capitolare; il più fallimentare dei miei tentativi è stato quando per far partire un numero spropositato di “minion” in UniquID che simulassero un dato comportamento ho infilato tutto in dei container: pur volendo imparare a installare un cluster Kubernetes, alla fine sono tornato per mancanza di tempo ad una gestione manuale tramite un programma in Python scritto da me.

Stufo della mia ignoranza, da qualche settimana ho deciso di partire con un crash course di Kubernetes. La prima cosa che ho fatto, avendo fallito completamente in passato con il setup di un cluster non capendo nemmeno dove mettere mano, è stata darmi una calmata installando Minikube sul mio computer.

Minikube

Da quando ho fatto tableflip l’ultima volta cercando di capire come funziona il setup di un cluster Kubernetes, è uscito Minikube. Grazie a Minikube possiamo installare un cluster di un singolo nodo master di test all’interno della nostra macchina; la pagina di manuale dedicata è abbastanza estesa.

Una volta installato e configurato kubectl (sulla mia workstation ho usato Homebrew, per Arch Linux come al solito è tutto su AUR, per Debian e CentOS/Red Hat se non lo trovate nei repository ci sono modi alternativi) è toccato all’eseguibile minikube essere installato in /usr/local/bin. La guida spiega come fare con un curl, e io ho semplicemente (una volta controllato che lo script che stavo scaricando non facesse cose strane) installato il binario in questo modo.

Con minikube start poi l’ho lanciato, ed è partita la fase di setup che richiede qualche minuto. Una volta completata la guida del kickstart deployando il container che ha dentro una sorta di applicazione “hello world”, ho fatto qualche altro esperimento deployando Grocery, ovvero il mio webserver scritto in C che ho svolto come progetto universitario qualche settimana fa.

Kubernetes dashboard

Per deployare il container è necessario un comando simile a questo:

$ kubectl run hello-grocery --image=registry.hub.docker.com/dottorblaster/grocery --port=8080

È importante notare l’URL che abbiamo dato in pasto a kubectl, perché l’unica via per me di reperire come sono fatti i resource locator di immagini presenti su Docker Hub è stato scavare dentro StackOverflow. Quindi, tanto per chiarire, per deployare un container costruito a partire da un’immagine che si trova sul Docker Hub, dobbiamo prependere al nostro solito nome di immagine il dominio registry.hub.docker.com.

Dopodiché per rendere il container accessibile al mondo esterno dobbiamo esporre il deployment tramite la rete interna. Questa cosa mi disturba leggermente, nel senso che già Docker fa da discreto layer di astrazione con il suo mapping di porte esterne al container a porte interne, in più con Kubernetes andiamo ad aggiungere strati su strati di complessità, che ovviamente però per grandi ambienti e infrastrutture ingombranti diventa necessaria.

$ kubectl expose deployment grocery --type=NodePort

Fatto! Abbiamo deployato il nostro container.

Non è che l’inizio

Per una prova al volo, questo era quello che mi interessava, che però non mette in risalto nemmeno un millesimo delle potenzialità di Kubernetes. Volevo iniziare a fare altre cose ma la mia versione locale di kubectl era troppo aggiornata rispetto a quella di Minikube, così invece di risolvere questo problema ho preferito aspettare direttamente un aggiornamento di Minikube studiando altro.

Setup di un cluster Kubernetes

Invece di continuare a pasticciare con Minikube il quale forse è il tool migliore per studiare Kubernetes che io abbia mai visto, sono andato a cercare sul manuale come fare setup di un cluster on premise. Abbastanza sepolto sotto ogni offerta cloud di ‘sto mondo ho trovato effettivamente il modo, con varie alternative.

Nello specifico quelle che ho apprezzato di più sono kubeadm, che è il tool principe per l’amministrazione di un cluster, e Kubespray, che consiste in un insieme di playbook Ansible che non fanno altro che orchestrare l’uso di kubeadm per rendere più semplice il mantenimento del cluster.

Prossimi step

Per ora termino qui, tuttavia il mio “learning path” relativo a Kubernetes credo sia ben lontano dall’essere anche solo cominciato. Tutto quello che ho appena appuntato mi serve, perché trovo che la documentazione di Kubernetes oltre ad essere dispersiva sia molto incentrata sul “compra hosting Kubernetes dai migliori provider” – che è sicuramente quello che ogni azienda con un po’ di sale in zucca dovrebbe fare, ma non è decisamente il miglior modo per un “junior” di imparare come funziona il giocattolone.

I prossimi passi:

  • Setup vero di un cluster usando kubeadm
  • Deploy di un’applicazione stateful con uno stack classico webapp + database, per imparare a gestire anche questa grana

👋

Homebrew, macOS e lo strano caso dell'XCode fantasma 👻

Altro giro di Homebrew su macOS, altra storia dell’orrore (sort of: ne ho sentite di molto peggiori) su “cose a caso”: scrivo “cose a caso” perché effettivamente non ho capito che cosa cacchio stesse cercando di fare il mio computer, e cosa diamine sia successo nel frattempo.

Andando con ordine, questa settimana ho trovato un bug su un bot Telegram che ho scritto in Elixir. Provando a compilare il fix in locale, ho trovato un’incompatibilità tra la vecchia versione di Erlang che avevo installata, e macOS High Sierra a cui ho aggiornato da poco. Ho deciso quindi di aggiornare i miei package locali, ma:

Error: Your Xcode (8.3.spicci) is outdated. Please update to Xcode 9.0 (or delete it). Xcode can be updated from the App Store.

Ok. Vado sull’App Store, e vedo che XCode non mi viene segnalato come installato. Strano: ricordo di averlo, ma effettivamente non riesco a vederlo nemmeno dal drawer delle applicazioni. Dopodiché metto ad installare gli svariati giga della versione 9.0, mentre penso “ma vuoi vedere che basta aggiornare solo i command line tools?”; nell’ordine sono successe le seguenti cose:

  • Ho usato xcode-select --install per cercare aggiornamenti nei CLI tools, e ne ho installato uno (che non specificava la versione);
  • Nell’App Store mi è comparsa la voce di aggiornamento ai CLI tools 8.3.spicci (che avevo appena portato a termine), e ho aggiornato;
  • L’App Store mi ha successivamente proposto l’aggiornamento ai CLI tools 9.0, che ho installato;
  • Lanciando brew upgrade ottengo lo stesso errore.

Ho lanciato il computer nello zaino e me ne sono andato al meetup di Rust che mi attendeva. La mattina dopo mi viene lo sghiribizzo di controllare meglio: il laptop mi accoglie con un popup che mi informa del download di XCode 9.0 fallito (cominciamo bene), e a me viene in mente di lanciare una find su /Applications giusto per capire; infatti scopro che ho una versione di XCode installata, a ‘sto punto non tanto a mia insaputa quanto a insaputa del sistema operativo. Provo a cancellarla, e a rilanciare brew upgrade.

Funziona.

Poi dicono che Linux è difficile.

Vim su macOS installato tramite Homebrew: come riabilitare il backspace ⌨️

È già da un sacco di tempo che volevo risolvere questo piccolo problemino ma non trovavo la voglia dato che per lavoro uso sempre qualche altro editor: installando Vim da Homebrew su macOS, il backspace non funziona più come dovrebbe in insert mode.

Per riavere indietro il vecchio comportamento, basta inserire questa riga alla fine del proprio vimrc:

set backspace=2

Vim da Homebrew

Giusto come annotazione, installare Vim da Homebrew serve, dato che la versione installata di default con macOS è un po’ vecchiotta, e quello che accade è semplicemente che alcuni plugin, magari facenti uso di feature più recenti, non si comportano come previsto.