Christmas Unconference – Intré Camp dicembre 2020
Bentrovati cari lettori all’ultimo appuntamento, e articolo, di questo particolare 2020, un anno che ha profondamente cambiato le nostre abitudini, chissà forse per sempre.
Intré ha saputo reagire, in puro spirito Agile, e ci siamo dovuti riorganizzare in tutte le nostre attività, lavorative in primis ma non solo.
Dopotutto qual è il nostro payoff? LEARN / CODE / DEPLOY VALUE.
Abbiamo infatti organizzato i camp aziendali, le gilde, le gildonferenze tutte da remoto, avvalendoci di tutti gli strumenti possibili ma soprattutto della nostra insaziabile voglia di imparare e condividere conoscenza.
Eccomi dunque a raccontarvi come è andato l’appuntamento di unconference del 22 dicembre che ha animato la seconda parte dell’Intré Camp andato in scena il 24 Novembre.
Buona lettura.
Che cosa si intende per unconference?
Basata sulla metodologia Open Space Technology [1], una unconference (o open conference) è una conferenza la cui agenda è organizzata al momento. Liidea è che le proposte arrivino dal basso, dai partecipanti stessi, affinché si abbiano argomenti tutti di reale interesse.
Non solo argomenti da proporre, ma anche richieste di aiuto, dubbi, spunti che possano generare una discussione costruttiva.
Come per le scorse volte Alessandro Giardina ha curato l’evento avvalendosi di Miro e Microsoft Teams per le stanze virtuali. Per ulteriori informazioni sul format invito a leggere il resoconto della nostra prima virtual unconference il 21 Aprile 2020.
E ora spazio alle persone e gli interventi che hanno animato il pomeriggio, suddivisi nelle tre stanze virtuali The Oval Room, Panic Room e The Chamber of Secrets.
The Oval Room
Spring Cloud Config
• tramite un server centralizzato per la gestione delle configurazioni;
• ogni client, in aggiunta alle proprie informazioni di configurazione locali, può recuperare le proprie configurazioni accedendo al server delle configurazioni tramite REST.
Per ulteriori approfondimenti sul codice trovate il repository a questo link.
A Django project template with CI/CD pipelines and k8s orchestration
Raffaele Colace, sviluppatore e divulgatore Python (i componenti della gilda “Adoratori del Pythone – il ritorno” lo hanno avuto come coach) e co-founder di 20tab s.r.l., ha raccontato una storia, fatta di tentativi, che lo ha portato ad avere l’attuale template di CI/CD.
Qual è il modo per sviluppare e rilasciare del software? E qual è il modo più rapido e corretto per avviare dei progetti? Queste le domande che hanno poi portato Raffaele e la sua azienda a trovare la soluzione migliore per i loro scopi.
Da un iniziale monolite, difficile da mantenere e privo di test automatici e deploy, Raffaele e i suoi colleghi passarono a una soluzione più leggera e configurabile usando template Django. Il setup era rapido, avevano la configurazione per Continuous Integration ma non era ancora la soluzione migliore. Bisognava automatizzare i test e rilasciare in produzione. Introdussero quindi Jenkins per la C.I. e Ansible per la gestione via script di deploy semi automatici. C’erano quasi, bisognava aggiungere un pezzettino per il Continuous Delivery.
Eccoci quindi al 20tab-standard-project, scaricabile dalla pagina GitHub di 20tab. Il progetto è l’orchestratore Kubernetes, dalla stessa pagina sono disponibili i pacchetti django-continuous-delivery (back-end) e react-continuous-delivery per la parte di front-end.
Per chi volesse approfondire, è anche disponibile il video su YouTube dove Raffaele spiega la configurazione e l’utilizzo del pacchetto.
Nimbella
Marco Rotondi ha presentato Nimbella, un’implementazione a pagamento di un’alternativa ad Amazon Lambda per le funzioni serverless.
Marco ha fatto vedere come realizzare una funzione attraverso la CLI di Nimbella, utilizzando come linguaggio Java.
Oggetti a teatro – Una drammatizzazione di un design pattern
In questa unconference natalizia non ci siamo fatti mancare nulla, nemmeno un’opera teatrale.
Marco Testa ha portato tutti virtualmente a teatro per assistere alla prima de “Nel segno del Comando”, liberamente tratto dal libro “Design Patterns: Elements of Reusable Object-Oriented Software” [4].
Marco ha letto (e interpretato) la sua storia, a sfondo medioevale, con l’intento di spiegare alcuni design pattern quali Command e tutti i suoi componenti: il Client, l’Invoker, il Receiver e appunto Command. Lo scopo del pattern è rendere come oggetto l’invocazione a un metodo incapsulandone quindi la chiamata.
Dopo la prima parte dedicata alla recita della originalissima storia, Marco ha spiegato il canovaccio entrando nel dettaglio degli attori, o meglio di tutti i design pattern coinvolti e i loro ruoli.
Teatralizzare i design pattern è davvero un buon modo per imparare a conoscerli, ma quando si tratta di applicarli ai progetti reali, la situazione inevitabilmente si complica. Ecco quindi che Marco complica la trama della sua storia introducendo altri pattern quali l’Adapter e l’Observer. In una storia di battaglie medioevali non può mancare uno stratega, ed ecco quindi che il pattern Strategy fa il suo ingresso.
Invoker, Command, Receiver, lo Stratega…l’informazione deve passare attraverso tutti questi attori, magari si potrebbe utilizzare il pattern Chain-of-responsibility che permette di separare gli oggetti che invocano richieste, dagli oggetti che le gestiscono, dando a ognuno la possibilità di gestire queste informazioni.
L’idea di Marco è non solo originale, ma anche utile. Chissà che non si riesca a dare vita con attori in carne e ossa, in un futuro spero prossimo.
Coding Dojo
Panic room
Zuppa o insalata? Discutiamo di diversità e omogeneità
Durante una nostra unconference non parliamo solo di software e programmazione.
Prendendo spunto dalla tesi di laurea di sua sorella Francesco Agozzino ha trattato di due tematiche delicate in ogni ambito della nostra vita: la diversità e l’omogeneità: meglio essere omogenei, come le verdure bollite in una zuppa oppure diversi, ognuno con le proprie caratteristiche intatte ma con il rischio di incappare in cattivi abbinamenti, come appunto tante verdure crude e condimenti in un’insalata [6]?
Si è discusso sulla varietà di ambiti della diversità: sesso, seniority, ruolo lavorativo, orientamento politico, etnia, attitudine. La diversità la ritroviamo non solo al lavoro ma anche in tutti i gruppi del quale facciamo parte: ad esempio nella nostra squadra di basket o calcio, in famiglia, tra amici.
Ragionando poi su che direzione prendere, se sarebbe meglio per un team avere tutte persone simili o diverse, potrebbe aver senso indagare per capire quali siano i punti di contatto, e da questi partire. Tendenzialmente ci troviamo a proprio agio nell’omogeneità e a disagio nella diversità che potrebbe però favorisce la crescita (ho questa lacuna, mi impegno per colmarla).
Concludendo, per crescere un team potrebbe dotarsi di cicli di omogeneità (all’inizio un team è nuovo, è necessario omogeneizzarsi per trovare delle basi, delle fondamenta, darsi delle regole generali) e conseguenti cicli di diversità. Per crescere, la creazione di diversità la si deve trovare all’interno del team, magari con condivisione di studi o esperienze utili oppure cercarla all’esterno avvalendosi di una consulenza esterna per colmare appunto carenze nel team.
Blazing fast websites
Oggigiorno abbiamo l’esigenza di accedere in qualunque momento al Web e pretendiamo di avere subito disponibile il servizio, qualunque dispositivo usiamo (tablet, pc, smartphone ecc.). Christian De Simone per questa unconference ha preparato alcune slide con alcuni consigli per monitorare e migliorare le performance delle pagine web, dopotutto un certo Galileo Galilei disse
Misurate ciò che è misurabile e rendete misurabile ciò che non lo è.
Esistono diverse soluzioni per il monitoraggio di siti web tutte valide, quali ad esempio PageSpeed Insight di Google, l’estensione di Chrome Lighthouse, web.dev e GTmetrix.
Ma lo strumento non basta, ecco quindi alcune buone pratiche consigliate da Christian:
- monitorare la lista di chiamate HTTP e le tempistiche, per individuare colli di bottiglia. Dove possibile sarebbe meglio ridurre il numero di chiamate HTTP;
- utilizzare immagini “web friendly”, ovvero immagini di dimensioni ridotte; magari ridurne la risoluzione, oppure comprimerle o tagliarle;
- utilizzare formati “next generation”, come WebP, per le immagini;
- ridurre il numero di script esterni usati;
- ottimizzare file JavaScript e CSS, minificando i file rimuovendo spazi, virgole, nomi verbosi…utili a chi sviluppa ma non al browser;
- utilizzare servizi di C.D.N. [7] ovvero una piattaforma di server altamente distribuita geograficamente che riduce la distanza fisica tra utente e server.
Migliorare la Code Review
Fabio Fortini ha proposto una discussione su un’attività che tutti i team di sviluppo software dovrebbero frequentemente praticare, la Code Review [8].
La Code Review, o Peer Code Review, è l’atto di riunirsi consapevolmente e sistematicamente con i propri colleghi per controllare il codice dell’altro per errori, ed è stato ripetutamente dimostrato che accelera e semplifica il processo di sviluppo del software come poche altre pratiche possono fare.
Esistono strumenti e software per fare Code Review, ma il concetto stesso è importante da capire: il software è scritto da esseri umani quindi non può per natura essere esente da errori. Ciò che non è così ovvio è il motivo per cui gli sviluppatori spesso si affidano a test manuali o automatizzati per esaminare il codice trascurando quell’altro grande dono della natura umana: la capacità di vedere e correggere gli errori da soli.
Si è discusso anche dell’atteggiamento da tenere durante una Code Review: evitare di scrivere un commento “cattivo” o comunque dal tono accusatorio verso l’altra persona, non serve a nessuno. Piuttosto scrivere dando un suggerimento, essere propositivi. A tal proposito, Fabio ha trovato molto utile la lettura di questo post [9], che vi ripropongo.
In sintesi, una chiacchierata che ha portato spunti utili a tutti i partecipanti.
Lingua onnipresente nelle lingue straniere
Gabor Heves, come Fabio, ha approfittato di questa unconference per discutere di una tematica a lui (e non solo) cara, quella dell’Ubiquitous Language [10].
L’Ubiquitous Language è un approccio progettuale utilizzato nel campo del Domain Driven Design e descritto nel libro “Domain Driven Design” di Eric Evans [11]. Consiste nell’impegnarsi a utilizzare il vocabolario di un determinato dominio aziendale, non solo nelle discussioni sui requisiti di un prodotto software, ma nelle discussioni sul design come bene e fino al “codice sorgente del prodotto stesso”. (Il libro di Evans descrive altre tecniche complementari, ma il nome Ubiquitous Language” trasmette l’intenzione principale).
Si è discusso sulle strategie da mettere in pratica, in primis quale lingua usare nel codice del progetto. Ad esempio per un progetto nuovo si potrebbe usare fin da subito la lingua inglese, che nel mondo dello sviluppo software è la più utilizzata e universalmente riconosciuta. Un altro consiglio è creare e mantenere un dizionario dei termini di dominio, che metta d’accordo tutti i livelli dell’organizzazione e non solo il team di sviluppo.
Come per la discussione di Fabio Fortini, anche questo momento ha generato molti spunti interessanti grazie al contributo di tutti i presenti.
The Chamber of Secrets
Telegram e NodeJs
Carlo Mandelli ha parlato di Telegram e Node.Js, mostrandoci un semplice progetto di integrazione di questi due mondi che soddisfa un bisogno tanto caro a Carlo (e non solo): rendere disponibili dati alle persone, senza magari dover perdere tempo nel creare la solita pagina Web.
Per creare un nuovo bot con Telegram si utilizza il bot BotFather, e in particolare con il comando /newbot si procede con la creazione di uno nuovo. Per ulteriori informazioni potete consultare questa guida [12].
Non appena creato il bot, viene comunicato il token API per interfacciarsi a esso.
Nel progetto Node bisogna innanzitutto importare il modulo node-telegram-bot-api dopodiché istanziare un oggetto con il token API e quindi poter comunicare con il bot rispondendo ai messaggi che arrivano, con la possibilità di inviare foto/video/audio. Il tutto scrivendo pochissime righe di codice.
Carlo ha poi mostrato come modificare la configurazione del bot sempre da BotFather, e anche come mostrare una tastiera personalizzata, il tutto sempre modificando qualche riga di codice dal progetto Node.
Retrospettive e metodologie Agili
Prima l’uovo o la gallina? Prima le persone o la tecnologia?
Art Of Fugue
Marina Poggio ci ha introdotto al progetto Art of Fugue, il cui titolo riprende l’ultima opera di Bach, L’arte della fuga. Il progetto è del pianista Filippo Gorini e ha un intento nobile: raccontare, attraverso 14 interviste a personaggi di spicco della cultura moderna, l’influenza dell’opera di Bach nella nostra cultura. Ogni intervista rivolge la sua attenzione a un particolare contrappunto che compone l’opera, con una scelta molto significativa tra il personaggio intervistato e contrappunto. Per esempio il 13° contrappunto è esattamente speculare al 12°, uno è l’inverso dell’altro, e Gorini ci spiega la difficoltà di fare un’opera musicale così complessa e meravigliosa con questo vincolo e a questo proposito intervista Frank Gehry, architetto di fama mondiale appartenente alla corrente decostruttivista, e discorrono di come progettare un edificio e poi ribaltarlo e farlo stare in piede e fare in modo che sia meraviglioso.
Oltre alle interviste, il progetto comprende concerti e un film.
Come portare tutto ciò al pubblico in maniera fruibile?
Attraverso una app! Ed ecco come nasce la collaborazione di Intré con Filippo.
Emanuele Mantovani e Diego Chierichetti hanno raccontato gli step del progetto, dalle stime di sviluppo alle ipotesi realizzate, alla UX e UI mostrandoci le aree della app (le interviste, i concerti), il logo, e il menù.
CSS per chi non ama scrivere CSS
Conclusioni
Sarà l’abitudine impostaci dagli eventi di questo 2020, sarà che la voglia di passare del tempo insieme non passerà mai, questo evento di unconference ci ha regalato davvero tanti bei momenti.
La lontananza non è stata un problema, ogni minuto è stato percepito e vissuto intensamente. Ognuno dei talk che ho seguito è stato interessante e da ognuno porterò a casa qualcosa. Non sono poi mancati momenti di festa e di auguri, dopotutto tra pochi giorni sarà Natale e nonostante tutto vogliamo regalarci dei sorrisi.
Un mio personale in bocca al lupo a Fabio Manzi e Francesco Agozzino, ai quali auguro il meglio per il proseguo della loro carriera professionale.
Come sempre, grazie come sempre a Intré che permette la realizzazione di questi bellissimi eventi, un grazie a tutti gli ospiti che hanno partecipato.
Arrivederci al prossimo appuntamento.
Riferimenti
- Open Space Technology | Wikipedia
- Spring Cloud Config | Spring
- Spring Cloud Config Server | Spring
- Libro “Design Patterns: Elements of Reusable Object-Oriented Software” | Amazon
- WhatIsCodingDojo | Coding Dojo
- “Soup or salad” – Models of diversity | Agile Alliance
- Content Delivery Network | Wikipedia
- What is Code Review? | SMARTBEAR
- Effective COMMENTS on pull requests | dev.to
- UbiquitousLanguage | Martin Fowler
- Libro “Domain-Driven Design: Tackling Complexity in the Heart of Software” | Amazon
- Creare un bot su Telegram: come fare e quali sono gli esempi da seguire | Computer World