RomaJS natalizio, tra Angular su vasta scala e lazy loading

Che meraviglia le festività natalizie, e che c’è di meglio delle festività di Natale se non i meetup prefestivi? Ci si fa gli auguri, tra quei pochi che riescono a presenziare sfuggendo ai parenti, alle cene aziendali, agli eventi dove è del tutto assente il coding, e tra una fetta di pandoro e l’altra¹ si parla di cose veramente interessanti. Questo mese abbiamo avuto due talk eccezionali:

• “Angular su progetti da milioni di euro” di Alessandro Avolio,
• “Image loading techniques” di Guido D’Orsi.

Il talk di Alessandro, “Angular su progetti da milioni di euro”, è stato una conferma per alcuni aspetti, illuminante per altri. Mi ha dato spunto su alcune pratiche da introdurre nei prossimi progetti e mi ha chiarito alcuni dubbi che avevo riguardo lo sviluppo agile in consulenza. È molto interessante come il team di cui fa parte Alessandro abbia in qualche modo potuto segregare il proprio dominio applicativo rispetto ai produttori delle API (ovvero gli sviluppatori backend dello stesso team); le domande alla fine hanno fioccato, e gli argomenti delle questioni poste sono stati tra i più disparati: dalla compilazione del bundle al processo agile del team². Sicuramente è stata anche un’occasione notevole per mettere alla prova un framework di questo tipo su progetti che non siano la solita todo app, ma qualcosa di molto più reale (dove, ahimé, il rischio di farsi male aumenta esponenzialmente).

Guido invece ci ha presentato varie tecniche per gestire il lazy loading delle immagini nel nostro sito. Ancora una volta abbiamo avuto un talk “no-slides”, con live coding e tutto il resto: Guido mi fa impazzire, perché ogni volta che porta un talk del genere fa delle cose assurde, come quando ha scritto un Virtual DOM senza colpo ferire. Anche questo talk è stato pieno di spunti, dato che non solo nella prima parte ci siamo concentrati molto sulle performance di caricamento, ma nella seconda abbiamo anche analizzato tecniche per la produzione di placeholder leggermente più impattanti dal punto di vista delle performance che però siano decisamente più belli a vedersi.

Phoenix Framework on fire 🔥 ad Elixir Roma

Ultimamente stanno succedendo tante cose. Di alcune posso parlare liberamente, di altre meno: tra quelle di cui posso parlare c’è il fatto che mi sono appassionato un sacco ad Elixir (e in generale alla programmazione funzionale), e ho deciso di scrivere uno dei miei progetti nuovi con Phoenix Framework.

È un’esperienza fantastica, sto rispolverando un sacco di concetti vecchi e sto assaporando un sacco di piccole novità; sinceramente devo dire che è forse il framework con cui sono più produttivo in generale. Mi sono trovato talmente bene durante questo viaggio con Phoenix che ho voluto condividere qualche settimana fa con i ragazzi di Elixir Roma il mio feedback, una volta ottenuta una buona dimestichezza sia con Elixir che con tutto quello che ci gira intorno.

Le slide le trovate qui sotto:

Di Elixir Roma ormai sono un frequentatore fisso e vi invito (ovviamente) ad unirvi a noi nelle nostre birrate mensili, dato che tra noi avventori abituali ne scopriamo sempre di bellissime.

Ringrazio in particolare Claudio e a seguire tutti coloro che mi sono stati a sentire per un sacco di tempo, perché era il mio primo talk su Elixir e non nascondo di essere stato un bel po’ agitato. Ci sono parti che potevano essere spiegate meglio e parti che potevano essere spiegate peggio, ma la cosa importante è che l’audience mi ha decisamente messo a mio agio. Mi sono divertito 😎

Qui trovate anche una foto che mi ha scattato il buon Lorenzo Ferrara durante lo speech. ❤️

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

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

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.

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.

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.

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

👋