L’Intré Camp è un momento sempre molto atteso, vuoi perché ci si incontra per passare una giornata tutti insieme, vuoi perché è l’occasione giusta per diffondere conoscenza e parlare delle gilde.
È consuetudine infatti organizzare una unconference, ovvero una conferenza con proposte di sessioni (e non solo) decise al momento dai partecipanti stessi. Dato il momento che stiamo vivendo, ci siamo organizzati già dallo scorso camp con la versione da remoto di questo tipo di conferenza, ribattezzata virtual unconference.
Già all’appuntamento del 21 aprile 2020 era stata introdotta una grossa novità: estendere la partecipazione a persone esterne di Intré con l’auspicio di aumentare la contaminazione di conoscenza grazie anche al loro apporto.
Nei prossimi paragrafi potrete leggere un resoconto delle sessioni proposte il 14 luglio 2020.
Buona lettura.
Introduzione e marketplace
Alessandro Giardina ha presentato la board Miro, migliorata sia nell’organizzazione degli spazi che nella grafica grazie al lavoro di Giacomo Nava.
La board prevede quattro sezioni.
- Intro: dedicata alla spiegazione del significato di unconference, la legge dei due piedi e i quattro principi [1].
- Marketplace: è presente un tabellone dove inserire i post-it con le proposte, pensato (inizialmente) per ospitare le sessioni tre stanze virtuali (colonne) in tre slot temporali (righe). In questa sezione è presente anche il parking lot, un parcheggio appunto, dove riportare le proposte di sessione prima di presentarle a tutti e collocarle nel marketplace.
- Nove spazi, uno per ogni sessione, dove inserire post-it di commenti, apprezzamenti, link…tutto ciò che si scaturisce durante una sessione.
- Feedback wall: un altro tabellone, suddiviso in tre colonne, per i post-it relativi ai feedback sulla conferenza. Critiche positive e negative sono ben accette, al fine di poter migliorare l’evento per le volte successive.
La virtual unconference è iniziata con la fase di marketplace durante la quale sono arrivate molte proposte, più delle nove inizialmente previste. Per ovviare al problema Alessandro ha creato una quarta stanza virtuale dove hanno trovato sistemazione le sessioni inizialmente non collocate.
Sono state proposte sessioni tecniche e non solo. Si è parlato di git, del linguaggio Rust, di stime per i progetti, interfacce dark per siti Web…di tutto e di più, per accontentare gli oltre 60 partecipanti a questa conferenza.
Vediamo quindi di che cosa si è parlato in ognuna delle sessioni nelle quattro stanze di questa virtual unconference:
- The Oval Room
- Panic Room
- The Chamber of Secrets
- Last Minute Room
The Ovall Room
Mi ascolti quando [non] parlo?
Marco Testa recentemente ha letto il libro “The culture map” [2] di Erin Meyer che parla di comunicazione e problemi legati ad alcune culture mappate nel libro.
Si parla di otto indicatori tra i quali:
- comunicazione: Due tipologie: di alto contesto dove presuppone che gli interlocutori sappiano leggere il “non detto”, ad esempio la cultura giapponese; basso contesto, quindi una comunicazione molto diretta, ad esempio la cultura anglosassone;
- dare feedback negativo: il più interessante per Marco, perché dare feedback non è mai semplice. È meglio un feedback diretto o più edulcorato? Non è detto che nelle culture dove c’è una comunicazione diretta il feedback sia diretto;
- persuasione: come si può convincere una persona?;
- leadership: esistono diversi tipi, da quella egualitaria a quelle più autoritarie;
- fiducia;
- sensibilità sul tempo: come lo si percepisce.
Meglio una comunicazione diretta o indiretta? Meglio dare feedback diretti?
La pratica dell’eXtreme Programming e le metodologie Agili pongono un forte accento sulla comunicazione e sul feedback.
Marco si trova spesso in difficoltà nel dare feedback e farsi capire (magari con comunicazione indiretta), e durante la sessione si è acceso un interessante dibattito sulla tematica.
Stime
Alberto Maggioni parla di come poter migliorare le stime di un progetto.
Nel suo team hanno analizzato tre punti:
- lavorare con storie più piccole: sono più semplici da stimare, e si ottengono spezzando le storie in elementi appunti più piccoli;
- tracciare i tempi effettivi per lavorare su una storia, variabili da sprint a sprint;
- usare la metodologia del planning poker [3].
Per il tracking dei tempi, Alberto ha mostrato la funzionalità task, attivabile da IntelliJ e integrabile con Jira. Dopo aver spiegato come configurare il progetto (settando parametri quali il feature branch, time tracking e altri), ha spiegato come creare un task e mostrato come IntelliJ tiene traccia del tempo e su quali file.
Il planning poker è una tecnica per fare stime ed evitare bias e groupthinking, ovvero l’allinearsi alla stima data dalla prima persona che prende la parola. Svolgimento:
- ogni membro del team sceglie una carta;
- tutti mostrano la propria carta nello stesso momento;
- se le carte coincidono, quella è la stima;
- in caso contrario, si discute per trovare un accordo (tipicamente spiega chi ha dato il voto più basso e più alto) o si torna al punto uno.
Dato che in quest’ultimo periodo si lavora sempre da remoto, Alberto e il team hanno adottato Scrumpy [4], tool online gratuito per fare planning poker da remoto su task (integrabile ovviamente con Jira).
L’introduzione di Alberto ai tool ha poi generato una discussione sulle esperienze in ambito stime in altri team.
I file di progetto sono organizzati male, come posso fare?
L’ultima trance di sessioni della virtual unconference ha visto tra i protagonisti Francesco Sacchi che ha colto l’occasione per ottenere dei consigli sulla gestione della struttura del file system in un progetto, tipicamente costituita da file e cartelle disorganizzati.
Esistono delle convenzioni a livello architetturale (per esempio utilizzare un framework che adotta il pattern MVC [5] aiuta a organizzare i file in tre cartelle Model, View e Controller appunto) o di progetto che possono dare una mano:
- attenzione a creare la cartella utils, spesso poi cresce a livello di file e sottocartelle perché vengono salvati file che non sappiamo bene dove collocare;
- in base al framework o linguaggio fare attenzione a seguire le convenzioni. Prendendo come esempio React, è comodo avere una cartella per ogni componente ma c’è il rischio di averne tanti. Qualora si decidesse di adottare una convenzione specifica per il progetto, che sia valida e abbia davvero senso.
- Decidere una convenzione sulle nomenclature aiuta poi a organizzare bene file e cartelle facilmente comprensibili a chi entra nel progetto in corso d’opera.
Panic Room
QA – What about?
Fabio Fortini lavora da non molto con un Quality Assurance Engineer (QA) in team.
Che impatti ha avuto nel lavoro? Che cosa fa un QA?
Prima dell’arrivo della figura del QA Fabio e il team in cui lavora erano così abituati: completata la pull request il PBI (Product Backog Item) veniva spostato in stato di done. I task non servivano a nulla se non come reminder.
Dall’arrivo del QA ogni pull request corrisponde al task, quindi il task va in stato di done quando la pull request è completata. Un PBI non ha nulla in stato di progress, tranne i task di QA. Per evitare colli di bottiglia, il team si è imposto che ci possono essere un massimo di quattro PBI in progress.
Che fa il QA?
In fase di sviluppo partecipa ad alcune discussioni sulla feature, talvolta anche tecniche, e porta la sua esperienza.
In fase di review segue alcune sessioni di review assieme agli sviluppatori, se può prova in anteprima la feature e magari trova qualche bug.
Dopo il merge del codice della funzionalità, per ogni PBI testa la funzionalità sotto ogni aspetto.
Tra i tanti vantaggi che porta, Fabio ne elenca alcuni secondo lui più impattanti:
- la quantità di bug trovati dal cliente finale è notevolmente ridotta;
- una maggiore qualità del codice;
- fare refactoring del codice è più facile;
- l’aggiunta di una funzionalità è più veloce.
La breve presentazione sul QA ha poi generato un’interessante discussione che ha visto protagonisti tutti i partecipanti alla sessione, in particolare alcuni QA engineer di RGI che lavorano assieme a nostri sviluppatori.
Un momento di condivisione di esperienze e modus operandi (ad esempio attività di QA svolte a turno da sviluppatori del team) che è stato utile per capire di più in merito alla figura del QA.
Interfacce dark – UI/UX e SASS
Andrea Sironi e Diego Chierichetti, designer dello studio Thanks Design, hanno parlato di interfacce dark per siti Web.
Sempre più clienti chiedono di realizzare la versione dark di un sito che ha diversi vantaggi tra i quali il miglioramento dell’ergonomia visiva riducendo l’affaticamento degli occhi. È però importante definire e bilanciare i colori.
A tal proposito Diego ha condotto una breve demo per realizzare live la versione dark del sito di Gumly, un’applicazione risultato di una gilda. Per la demo Diego ha utilizzato Adobe XD, un prodotto estremamente leggero e fluido, ideale anche quando il file inizia a diventare complesso. Durante la demo è stato dimostrato quanto sia veloce modificare il colore e altre caratteristiche alle pagine di un sito, dando nel frattempo qualche dritta sulla scelta dei colori scuri e chiari in base al componente che va modificato.
Degno di nota il servizio online constrastchecker.com che, dato in pasto il codice esadecimale di due colori, restituisce un’indicazione (verde o rosso) in merito alla validità del contrasto per diversi standard. Diego e i colleghi designer guardano lo standard AA dato che utilizzano Material Design.
Andrea è sceso più nel dettaglio tecnico mostrandoci come realizzare un toggle, per passare dalla modalità light a quella dark, attraverso l’uso Sass [6]. Sass, o scss, porta delle funzionalità tipiche della programmazione che permettono di scrivere file .css in maniera più rapida, leggibile e mantenibile:
- uso di variabili: se si deve cambiare il colore di una proprietà, lo si cambia in un punto solo del file;
- funzioni: attraverso un metodo theme-aware (e l’uso della direttiva @mixin) Andrea ci ha spiegato come con poche righe di codice viene gestito l’aggiornamento di colore di diverse proprietà per le due modalità.
From dust to Rust – dangerous live coding
L’ultima sessione della virtual unconference per questa room è stata presentata da Alex Mufatti il quale, come tanti sviluppatori, è attratto da nuovi linguaggi come Rust [7]. Secondo un recente sondaggio di StackOverflow risulta che questo linguaggio, sviluppato nel 2010 da Mozilla Foundation, è il più amato dagli sviluppatori, forse perché è stato implementando prendendo il meglio dai più noti linguaggi di programmazione (C++ e Javascript tra gli altri).
In questa sessione Alex ci ha mostrato le potenzialità di Rust implementando il famoso gioco “Game of life” [8] compilato in WebAssembly [9].
Per prima cosa deve essere generata la struttura del progetto utilizzando il comando generate di cargo, che è il package manager di Rust:
cargo generate <template locale o remoto>.
Dopodiché sotto con il codice, quindi Alex ha avviato l’IDE IntelliJ con plugin per Rust.
Interessante la struttura dei file del progetto creato, con attenzione al file cargo.toml, l’equivalente del package.json, dove troviamo informazioni su dipendenze e altro, e la cartella src contenente i moduli tra cui lib.rs che è il file di progetto che verrà compilato in WebAssembly.
Con Rust possiamo utilizzare funzioni JavaScript ed esporre nostri metodi, il tutto con la direttiva #[wasm_bindgen].
Tra una riga di codice e l’altra Alex ci ha fatto vedere come fare la build del progetto, passaggio fondamentale attraverso il comando wasm-pack build. Questo comando genera una cartella pkg che contiene l’applicazione.
Per generare il progetto JavaScript è sufficiente eseguire il comando npm init wasm-app www che restituisce come output la cartella www contenente i file del progetto.
Purtroppo il tempo a disposizione non è stato sufficiente per completare lo sviluppo, ma Alex ci ha mostrato una sua versione precedente e funzionante.
The Chamber of Secrets
DevOpsatore aziendale
Luca Marcato e Francesco Agozzino hanno parlano di una tematica molto calda nel nostro mondo, riassumibile in una parola: DevOps.
Luca ha curato la prima parte della sessione introducendo hub-configurator, un progetto interno realizzato da Francesco Sacchi e Daniele Percivaldi. Il progetto è composto da script e una pipeline CI/CD per realizzare deploy di container Docker su un’istanza interna di Portainer [10] in maniera semplice e rapida, e quindi avere come risultato una web app pubblica.
Nella demo Luca ha mostrato come:
- implementare una semplice app in Node.js usando il modulo Express, e renderla pubblicata su Internet;
- creare un Dockerfile per l’immagine Docker del progetto e il file gitlab-ci-yml contenente la logica della pipeline CI/CD per GitLab. Entrambi i file sono necessari a hub-configurator per effettuare il deploy.
Il container pubblico è visibile tramite Portainer, che mostra lo stato dei vari container Docker attivi e altre informazioni a essi inerenti.
Nella seconda parte della sessione Francesco ha moderato una discussione sulle pratiche DevOps e sull’utilizzo di strumenti interni come appunto Portainer.
Si fa presto a dire Undo
In chiusura delle sessioni tenute alla virtual unconference per questa “stanza dei segreti”, Marco Loregian ha parlato del concetto di Undo, quella operazione che ognuno di noi esegue per tornare indietro cercando di rimediare a un errore (per chi usa un pc Windows ad esempio, ctrl+z dovrebbe essere molto familiare).
Cosa vuol dire Undo? Sicuri di saperlo?
Partendo dalla definizione su Wikipedia [11], sorgono delle domande: posso annullare solo le mie azioni? Cos’è un’azione? E se un sistema non manipola documenti? Perché la maggior parte e non tutte le applicazioni?
Quali sono i modelli i Undo che potrebbero esserci utili?
Un modello di Undo indica in che modo gli utenti possono scegliere di “cancellare” qualcosa fatto in precedenza. Marco ha spiegato alcune proprietà per classificare questi modelli, per esempio minimale se l’annullamento di un comando causa l’annullamento dei soli comandi recenti che da esso dipendono. Tra i vari modelli, Marco ha parlato di Undo lineare (annullo il comando in cima alla pila) e non lineare (scelgo quale comando annullare). Per i sistemi multiutente il discorso si complica, pensate al fatto che chiunque possa annullare un’operazione fatta da altri utenti.
Come si può esplorare il problema in casi “nuovi”?
Bisogna capire bene il contesto, e la funzionalità. Marco ha raccontato di alcuni suoi esperimenti:
- alcuni workflow da lui realizzati per modellare realtà specifiche;
- Undo per i cellulari (2006, quindi ancora telefonate ed sms e niente Internet);
- Undo per la posta elettronica (lavoro sempre del 2006);
- Undo per l’allora Ubiquitous Computing (oggi Internet of Things).
Last minute Room!
Eccoci al resoconto di quanto presentato e discusso nella room creata al volo durante il marketplace di questa virtual unconference.
Motori di regole e home server
Andrea Iosio, ospite esterno di RGI, vorrebbe discutere riguardo l’event streaming per sistemi con architetture a microservizi. Prendendo l’esempio classico di un e-commerce, l’inserimento di un prodotto o l’acquisto di un prodotto scatenano una serie di operazioni gestite appunto da diversi microservizi.
Esistono diverse strategie per organizzare le comunicazioni tra microservizi:
- diretta, o punto-punto: “il servizio 1 chiama servizio 2” e così via. Semplice da implementare e fare debug, però ogni servizio deve conoscere tutto il sistema e va bene per un numero ridotto di servizi, perché una modifica poi va replicata su tutti i servizi;
- event streaming: il dato non lo comunico a un servizio, bensì inserisco l’evento relativo su un bus (modello publish/subscribe) e i servizi interessati (i sottoscritti) ne fanno uso.
Quale di queste strategie è migliore per il progetto in cui lavora Andrea? Utilizzare Kafka [12] può rappresentare una soluzione? Da questo interrogativo è nato un interessante dibattito tra tutti i partecipanti alla sessione.
Product Backlog Refinement: dove lo metto?
Fabio Ghislandi ha curato una sessione che vuole essere più un confronto sul tema del refinement.
Riprendendo la Scrum Guide ufficiale [13], il refinement non è inteso come un evento Scrum come sprint planning, daily scrum e altri. È un processo, che sta dietro al Product Backlog che è un artefatto di Scrum. Il refinement non ha un momento esatto in cui essere collocato, è un processo continuo in cui si lavora, PO e team, per affinare gli elementi del backlog.
Questa non presa di posizione degli ideatori di Scrum va a vantaggio dei singoli team, che hanno quindi libertà. Da qui è nata un’accesa discussione tra i vari partecipanti alla sessione, ognuno portando esperienza su questa attività.
Conclusioni
Questo pomeriggio di virtual unconference è letteralmente volato.
Nonostante le difficoltà e le limitazioni imposte dalla modalità online dell’evento, le sessioni proposte hanno generato un buon livello di interazione tra tutti i partecipanti, interni ed esterni a Intré, portando nella maggior parte dei casi degli spunti utili.
Con la speranza di poter organizzare la prossima unconference dal vivo, appuntamento alla seconda parte dell’Intré Camp dedicata alle gilde.
#openIntré