Icebreaker

Dopo un accogliente benvenuto a base di caffè torte e pasticcini, Fabio ci ha richiamati all’ordine per dare inizio alla giornata con uno degli icebreaker già provati nei camp precedenti. Morra cinese, o forbice-carta-sasso. Di volta in volta, il vincitore della partita sfida il vincitore della partita della coppia a fianco, e lo sconfitto deve tifare per la persona che lo ha battuto. A ogni iterazione quindi, ogni vincitore ha un seguito di persone sempre crescente, pronte a tifare per lui, sino allo scontro finale 🙂

Cosa emerge da questo icebreaker?
Il team, in ogni suo membro, deve essere sempre pronto a cooperare per raggiungere l’obiettivo, lavorando con determinazione e volontà.

Ognuno al suo posto, l’Intré Camp sta per cominciare!

Introduzione

Francesco ha aperto ufficialmente la giornata con una sua presentazione.

Come è andato il 2018?
Intré è ulteriormente cresciuta sia in termini di fatturato,  nuovi collaboratori e branding (il nuovo sito è online 🙂 ).

Che cosa ci aspettiamo dal 2019?
L’intenzione è di non fermarsi, con ulteriori assunzioni (te che stai leggendo, vorresti far parte di un’organizzazione che apprende?) e l’avviamento di nuovi progetti.

Momento religioso
Il cristianesimo, come l’ebraismo, si poggiano sui 10 comandamenti, che ogni credente dovrebbe rispettare.
Ma la storia ci ha insegnato che l’uomo è ricorso all’adorazione di falsi idoli in momenti di sconforto (si pensi al vitello d’oro).
Secondo Francesco, anche uno sviluppatore ha un primo comandamento, e degli idoli da adorare.
Quali sarebbero questi idoli?

• Le persone non hanno le idee chiare.
• Non c’è abbastanza tempo per fare ciò che loro chiedono.
• Non hanno fatto test.
• Il pc non è abbastanza performante.
• Colpa della lentezza della connessione di rete.
• …

Quindi? Piuttosto che adorare questi idoli, o meglio incolpare sempre e comunque qualcuno o qualcosa, pensare diversamente. Anzi, inversamente (passatemi la parola).

SE C’E’ UN PROBLEMA, QUELLO L’HO PROVOCATO IO!

Ecco svelato il primo comandamento che uno sviluppatore dovrebbe seguire.

Ma non è semplice, secondo Francesco si dovrebbero abbandonare determinati atteggiamenti che vanno contro il comandamento, come ad esempio:

• Altezzosità.
• Prepotenza.
• Presunzione.
• Senso di superiorità.
• Superbia.

In favore di altrettanti, quali:

• Modestia.
• Semplicità.
• Gentilezza.
• Pazienza.
• Attenzione.
• Risolutezza.
• Puntare all’obiettivo.

E se ci pensiamo bene, non si tratta di compiere chissà quale sforzo. Dopotutto:

Open space

Fatta eccezione dello scorso camp di Giugno dove la mattinata fu dedicata ad interessantissimi workshop, solitamente la prima parte viene dedicata all’Open space.

Un Open space può essere visto come una conferenza organizzata al momento. In una prima fase infatti, vengono proposti degli argomenti. Chiunque ne può proporre uno, collocando un post-it sul foglio di una flipchart dove è stata disegnata una griglia orari\spazi (solitamente tre aule). Ma non solo proposte, anche richieste di aiuto su qualunque argomento o tematica. L’intento è ottenere tre sessioni di talk di durata di 45 minuti l’uno.

Al termine della fase di proposte, ha avuto luogo il marketplace per organizzare al meglio le proposte in accordo con gli spazi a disposizione e preferenze.
A scapito del talk Appunti sparsi proposto da Giulio, è stato deciso di dedicare spazio al dry-run del talk Code is Law che Johan Duque presenterà ai prossimi Italian Agile Days di Brescia.

Mind maps drawing

Ecco un esempio di talk nato dall’esigenza di qualcuno di colmare lacune 🙂
Giulio infatti, su richiesta di Johan, ha organizzato una sorta di mini workshop sulle mappe mentali.

Che cos’è una mappa mentale?
É un modo per prendere appunti che siano comprensibili. Quante volte ci è capitato di scrivere un elenco puntato, piuttosto che scrivere informazioni in riquadri, collegandoli ognuno con frecce cercando di dare loro un senso? Una mappa mentale può essere vista come un pattern da applicare per prendere appunti in forma grafica comprensibile in qualunque momento si voglia rileggere quell’appunto.

L’idea è partire scrivendo il topic principale al centro, e man mano scrivere i concetto chiave che estrapoliamo disponendoli in forma circolare, partendo dall’alto in senso orario. Da ogni concetto è possibile poi creare diramazioni.

Per farci meglio comprendere, Giulio ha chiesto ai partecipanti di dividersi in tre sottogruppi, e provare a creare una mappa mentale che descrivesse Intré. Muniti di carta e penna quindi, ci siamo cimentati dapprima scrivendo ognuno la propria mappa mentale, poi un breve momento con il resto del gruppo per concordare una mappa comune, e infine un confronto con Giulio e gli altri gruppi.

Oggi Giulio riesce a costruire sue mappe mentali su di un foglietto di una piccola agenda, ma è il risultato di tanti anni di pratica. Il suo consiglio è quello di partire da normali fogli A4, e di sforzarsi a utilizzarle non solo per prendere appunti durante presentazioni o meeting, ma anche per altri momenti della nostra vita di tutti i giorni.

Che cosa ci è piaciuto?

• Rappresentazione grafica delle informazioni aiuta. É immediato.
• Semplicità legata all’utilizzo di singole parole.
• Sinteticità.

Cosa non ci è piaciuto? Quali difficoltà abbiamo incontrato?

• La difficoltà nell’avere sin da subito il quadro completo, ti porta a creare troppi rami. Aiutiamoci con una “pre-mappa”, con delle macro aree.
• Se siamo a una conferenza, diamo un occhio all’agenda per scrivere in anticipo gli argomenti principali nella mappa.
• Dare il nome giusto al ramo: è difficile, ma è una parte fondamentale di tutto il lavoro.

Ammetto la difficoltà nel creare una mappa mentale concentrica, ma altrettanto ammetto l’utilità di avere uno schema logico che in un secondo momento, anche a distanza di anni, ti aiuta a recuperare velocemente informazioni su di un certo argomento.
Ora sta a me, fare pratica e lasciare che il mind mapping diventi la prima opzione.

Grazie Giulio!

Consigli utili per dominare il caos

Gianni, come la maggior parte di noi (e suppongo anche te, caro lettore), vive una quotidianità lavorativa dove il caos la fa da padrone.
Non importa che tu sia sviluppatore, manager, designer…diversi fattori portano il  caos nel nostro lavoro:

• requisiti che cambiano frequentemente;
• idee poco chiare sulle attività di progetto;
• mancanza di test (sia unit test che integration test), tester e tempo;
• Codice applicativo scritto male;
• User Story scritte male: poche righe, che inizialmente danno l’idea che sia facile, poi quando ci inizi a lavorare scopri che la mole e la difficoltà sono tutto fuorché facili;
• a volte si ha uno scontro di opinioni;
• competenze tecniche, magari carenti sul dominio applicativo o sul framework/tecnologia del progetto.

Mi rendo conto, stiamo ricadendo proprio nella situazione dei falsi idoli dello sviluppatore descritta da Francesco nella sua presentazione…che azioni potremmo quindi intraprendere per mitigare alcuni di questi fattori?

Cosa possiamo fare noi sviluppatori a livello di team?

• Potremmo condividere competenze, ciò potrebbe ridurre la probabilità di avere del codice scritto male.
• Potrebbero essere utili delle linee guida da seguire per scrivere codice, di modo tale da non mettere in difficoltà noi stessi qualora dovessimo riprendere in mano quel codice a distanza di tempo, o nuove persone che entrerebbero a fare parte del team.
• Code review: trovare quell’oretta di tempo per ragionare assieme su una certa porzione di  codice. Rivederlo, e magari cambiarlo.
• In caso di refactoring/riscrittura di una porzione di codice, non scrivere anche solo un test minimale è impensabile.
  Almeno un test ci deve essere. Anche semplice, pensandolo in modo furbo (ad esempio, un test che accerta che la chiamata X ritorni qualcosa). Magari anche relativo alla porzione di software che abbiamo modificato.

Ma questo cambiamenti, ad esempio sull’iniziare a scrivere test, devono partire da noi.

Ancora una volta, smettiamo di pensare che il problema sia sempre là fuori.

Il caos è una brutta bestia per tutti noi, ma smettiamo di temerlo e iniziamo a fronteggiarlo.
Stop scaring of, start fighting!

Kafka

Alberto e Alessandro hanno organizzato una presentazione su Apache Kafka, dapprima spiegandone l’architettura e fornendo i concetti principali (a cura di Alberto) e poi mostrandoci esempi pratici (a cura di Alessandro).

Che cos’è Kafka?
Apache Kafka è una piattaforma open source di stream processing scritta in Java e Scala e sviluppata dall’Apache Software Foundation. Il progetto mira a creare una piattaforma a bassa latenza e alta velocità per la gestione di feed dati in tempo reale. Questo progetto viene usato principalmente per tutte le applicazioni di elaborazioni di stream di dati in tempo reale. – Wikipedia

Concetti principali dell’architettura Kafka:

• topic: una sorta di categoria per raggruppare messaggi, composto da una o più partizioni;
• partizione: contenitore di un certo numero di messaggi. Possono avere dimensioni differenti; permette di rendere scalabile il sistema;
• record: l’insieme messaggio + key + timestamp; un record è inviato alla partizione, identificata da un offset;
• producer: processo responsabile dell’invio dei messaggi; diverse logiche di invio messaggi:
  • invio a una precisa partizione tramite una precisa key; i messaggi con questa key saranno processati da uno più consumer;
  • randomico, i messaggi vengono assegnati con una logica round-robin decisa dal broker;
• consumer: processo che legge il messaggio;
• gruppo: insieme di consumer;
• broker: processo che gestisce ricezione e salvataggio dei messaggi;
• cluster: insieme di broker;
• zookeeper: processo che monitora lo stato del sistema;
• bilanciamento: sistema che garantisce l’equilibrio tra numero di partizioni e numero di consumer.
  Ad esempio: sistema con 4 consumer e 3 partizioni. Quando un consumer si disconnette, Kafka riassegna le sue partizioni a un consumer scarico. É importante gestire le partizioni. Ogni consumatore può avere minimo una partizione. Non ci possono essere un numero di partizioni superiore al numero di consumatori. Questo perché ci sarebbero consumatori che non ricevono messaggi.

Quanti concetti!

Dopo aver avviato un container Docker con Kafka, Alessandro ci ha mostrato come creare:

• topic, specificando zookeeper, quante repliche, quante partizioni, e il nome del topic;
• producer: specificando l’url di Kafka e il topic sul quale mandare messaggi;
• consumer: specificare il groupId, cioè il nome del gruppo, e nome consumatore.

Il tutto eseguendo degli script di test forniti da Kafka. Ammetto pensavo fosse più complicato, in realtà basta parametrizzare opportunamente questi script, e il gioco è fatto 🙂

Alessandro ci ha mostrato alcuni comandi quali:

• list <nome zookeeper>: comando per verificare la presenza di un topic;
• describe <nome zookeeper>: comando che dà ulteriori informazioni su di un topic;
• ottene la lista dei gruppi di consumer.

Giusto per non farsi mancare nulla, Alessandro ha speso due parole su Kafka tool e Kafka Offset monitor, software utili per mostrare informazioni utili sul cluster.

• Kafka offset monitor: avviato da browser web,  fornisce dettagli sui gruppi di consumer (esempio: broker, offset).
  Permette di vedere anche la lista di topic e una rappresentazione grafica (grafo) del sistema configurato.
• Kafka tool: simile a Kafka offset monitor, fornisce ulteriori informazioni come la lista di messaggi, le partizioni che li contengono.

Nei minuti (ahimè e ahi noi) finali di questa sessione, Alessandro e Alberto hanno realizzato piccole demo su:

• Sistema publishsubscribe con un producer e due consumer che ricevono contemporaneamente il messaggio. Hanno definito un topic di nome pubSub, i due consumer sottoscritti allo stesso topic, con attenzione sul groupId. Deve essere diverso per i due consumer.
• Coda: un topic, due consumer ma solo un solo consumer scoda i messaggi inviati, nonostante i due consumer abbiano uno stesso gruppo.

Dulcis (e che dolce!) in fundo, Alberto e Alessandro ci hanno mostrato una loro piattaforma di trading basata su Kafka e microservizi 🙂

Gran bella sessione, grandi ragazzi!

Pranzo

Al camp rifocilliamo non solo lo spirito e la mente…anche il corpo.

Serious game

Nel salone principale sono comparsi dei segni sul pavimento…delle griglie 5 x 7.
Che sta succedendo?!

Fabio ci ha riuniti tutti e suddivisi in tre squadre.

L’obiettivo è che ogni membro del team deve completare un certo percorso sulla griglia, un passo alla volta, scoprendo di volta in volta il percorso corretto.

Le regole sono poche ma chiare:

• Chi è fuori dalla griglia non può suggerire.
• Il giudice deve notificare la correttezza o meno degli step sulla griglia.
• Ogni volta che si effettua un passo errato, bisogna tornare indietro e ripetere correttamente i passi all’indietro.
• Vince il team che per primo completa il percorso. Tutti i membri devono completarlo.

Che cosa emerge?

• Il team deve collaborare per raggiungere l’obiettivo, anche pur rimanendo esterno al sistema.
• É più facile agire all’interno del sistema, strategie fatte inizialmente, per quanto utili, possono essere cambiate in corso d’opera. Bisogna reagire al cambiamento.
• Bisogna stare attenti alle specifiche che vengono fornite: una delle regole era NON SI PUO’ PARLARE, il che non vuol dire che NON SI PUO’ INDICARE IL PERCORSO CORRETTO. Attenzione!

Un gran bel momento, non solo di divertimento ma anche di apprendimento.

Presentazione gilde

Come ogni camp, è arrivato il momento dedicato alla presentazione dei lavori delle ultime gilde:

• Kubernetes
• Blockchain
• Studio di nuovi tool per la progettazione
• Architetture
• Free gilda

Prima di iniziare con le presentazioni, Francesco e Luca hanno introdotto una novità, nata da un’esigenza comune.
É difficile condensare in 15 minuti di presentazione un lavoro di studio di quattro ore settimanali svolto in quattro mesi.
Tanto si vorrebbe dire, mostrare e dimostrare. Come si può fare?

Gildonferenza

Nome scelto non a caso 🙂

Francesco e Luca hanno proposto un format di conferenza interno a Intré, dedicata appunto alle gilde.
Tramite prenotazione del biglietto via Eventbrite, ognuno può prenotarsi per una delle gilde in essere.

L’idea è dedicare spazio a tutte le gilde, tramite presentazioni\mini workshop di  un’ora di tempo.

Bellissima idea, grandi ragazzi!

Gilda Kubernetes

Obiettivo di questa gilda è stato lo studio del tool Kubernetes:

Kubernetes (abbreviato K8s), è un sistema open-source di orchestrazione e gestione di container. Inizialmente sviluppato da Google adesso mantenuto da Cloud Native Computing Foundation. Funziona con molti sistemi di containerizzazione, compreso Docker. – Wikipedia

Due i motivi hanno portato la nascita di questa gilda:

• la curiosità sulle potenzialità che il prodotto offre, e dall’esigenza di utilizzarlo in un progetto reale;
• trovare soluzioni alternative per semplificare i rilasci e la loro successiva manutenzione.

Nonostante le difficoltà legate ad esigenze di progetto, del lavoro è stato svolto:

• studio del tool seguendo il tutorial;
• prove su cluster del progetto client;
• creazione cluster su Amazon Web Services;
• deploy di una app di chat in autoscale: in base al carico, la app scala le risorse.

Che cosa è piaciuto di Kubernetes:

• comodità nella fase di rilascio dei microservizi;
• è svincolato dall’hardware;
• facilità di accesso/modifica alle informazioni del cluster.

Che cosa non è piaciuto:

• Qualche bug presente 🙂
• Alcuni tool che vengono messi a disposizione, come la dashboard, sono ancora acerbi.
• Instabilità ereditate dal cloud su cui si appoggia (Microsoft Azure).

Gilda Blockchain

Obiettivo di questa gilda, della quale ho fatto parte, è applicare la blockchain di Ethereum, a un progetto reale.

Il progetto in questione è I3-WAY, una applicazione, realizzata in AngularJs dal collega Fabio, che permette a qualunque collaboratore di Intré di segnare un appuntamento in un calendario visibile da tutti gli altri, di modo tale appunto da sapere chi è dove (Where Are You :)).

Un po’ come per i colleghi della gilda Kubernetes, anche noi abbiamo trovato delle difficoltà legate al tempo da trovare per lo studio, ma siamo comunque riusciti nell’intento.

In che modo?

Sfruttando la nostra blockchain Ethereum oggetto di studio della scorsa gilda blockchain, abbiamo realizzato l’integrazione con I3-WAY creando un database contenente i riferimenti alle transazioni.
Una transazione è la memorizzazione sulla blockchain delle informazioni relative all’appuntamento tramite uno Smart Contract, con il conseguente vantaggio dato dal fatto che tali informazioni possano essere recuperate in qualsiasi momento (ogni membro della blockchain ha una copia aggiornata della blockchain).

Il lavoro quindi svolto è stato:

• modifica del database;
• sviluppo di un semplice Smart Contract;
• implementazione di un server in Node.js per la gestione degli Smart Contract;
• modifiche lato frontend per mostrare le informazioni relative allo stato della transazione nella blockchain e per l’aggiunta della funzionalità di verifica dei dati in I3-WAY con quelli memorizzati sulla blockchain.

Ciò che ci è piaciuto è apprendere ulteriore conoscenza su questo mondo sempre più parte della nostra quotidianità, e la consapevolezza di aver realizzato un modulo completamente slegato dal contesto applicativo. Oggi lo abbiamo applicato a I3-WAY, domani…chissà 🙂

Gilda sullo studio di nuovi tool per la progettazione

I nostri colleghi designer si sono dedicati a una gilda di ricerca e studio di tool in grado di migliorare le performance legate ai flussi di lavoro interni e gestione dei sorgenti.

Rifacendosi al modello Design Eye, vediamo quindi le aree di interesse toccate e quali tool sono stati considerati:

• Ricerca:
  • tool: Google Forms come strumento per questionari\interviste.
    Pro: template facilmente declinabile alle esigenze.
    Problemi risolti: Ricevere risposte da remoto (paesi differenti).
• Sviluppo
  • Wireframe
    tool: Adobe XD: gestione simboli e font icon; anteprima diretta su device.
    Problemi risolti:
    • lentezza tool usati;
    • molti elementi da riutilizzare;
    • conversione macchinosa da wireframe a interfaccia;
    • rischio di incoerenze dello stesso elemento in schermate diverse;
    • difficile individuazione di asset da riutilizzare (ad esempio icone);
    • assenza di un’anteprima Web;
    • conversione macchinosa da interfaccia a prototipo;
    • impossibilità di riprodurre nel prototipo alcune interazioni.
  • Condivisione di specifiche e asset
    tool: Zeplin
    Utile per la generazione automatica specifiche e asset; generazione automatica snippet e CSS.
    Problemi risolti:
    • difficoltà e lentezza nel trasmettere misure e altre specifiche al team di sviluppo;
    • condivisione asset non immediata.
  • HTML\CSS
    tool: Sass
    Linguaggio che fornisce un modo efficiente di organizzare il codice CSS con uso di variabili e componenti.
    L’idea è utilizzare uno starter kit creato, per evitare ogni volta di partire da zero.
    Problemi risolti:
    • assenza di organizzazione in file e cartelle e convenzioni sul naming;
    • nessun codice base di partenza all’inizio dello sviluppo;
    • organizzazione di file e cartelle diversa da persona a persona;
    • rischio di incoerenze dello stesso elemento in porzioni di codice diverse.

Gilda architetture software

Obiettivo di questa gilda, lo studio e l’applicazione di alcuni pattern architetturali per lo sviluppo software.

Come ci si è organizzati?

• Scelta di quali architetture studiare.
• Ricerca di documentazione su ognuna delle architetture scelte.
• Creazione delle  sezioni su Draw.io.
• Esercitazione con schemi basati su kata architetturali.
• Realizzazione del tic-tac-toe, nome anglosassone del gioco del tris.

Architetture scelte:

• Domain Driven
• Hexagonal
• Layered
• Event-driven
• Microservices
• Onion

Per ogni tipologia di architettura, il modus operandi è stato il seguente:

1. Raccolta documentazione.
2. Kata architetturali: esercizio su come disegnare l’architettura per un certo progetto.
3. Sviluppo del gioco tic-tac-toe applicando l’architettura presa in esame.

Ogni membro della gilda ha appreso molti concetti relativi alle architetture, sono stati considerati positivi i diversi momenti di confronto avvenuti durante le esposizioni delle idee, e l’aver imparato a giocare a tic-tac-toe, alle volte perdendo contro il software da loro sviluppato 🙂

Freegilda

Una gilda incentrata su tanti piccoli argomenti.
Una gilda diversa dalle altre, nata con lo scopo di colmare lacune su argomenti troppo piccoli per essere oggetto di uno studio di quattro mesi.
Come si sono organizzati i componenti del team per tenere traccia delle attività?
Usando una semplice board su Trello.

Quale è stato il modus operandi?

• Backlog iniziale.
• Punto della situazione, quando serve.
• Nella wiki interna, aggiornamento di un journal.
• Studio e produzione di un output.

Ma quale può essere l’output di una gilda che studia diversi argomenti?

• Pubblicazione di un articolo.
• Presentazione di un talk a una conferenza.
• Workshop
• Presentazione interna.
• Tutorial online (video).
• Progetto con codice funzionante pubblicato su Gitlab.

Che argomenti\progetti hanno trattato?

• Progetto Gitoscope su Github.
• Comandi shell.
• Workshop su Docker TURNKEY CONTINUOUS DELIVERY, tenuto da Gianni sia alla conferenza DevOps Heroes di Parma e ai prossimi Italian Agile Days a Brescia.
• Reactive programming.
• Progetto Golang.
• Java design pattern.
• Workshop Object Calisthenics tenuto da Ferdinando Santacroce all’Agile Venture di Prato.
• Procedure Oracle.
• Articolo CQRS with Spring e Axon.
• Talk tenuto da Damiano al prossimo IAD a Brescia.
• Corso Webpack 4.
• Talk e corso su Git, “Git Pizza”

Possiamo dire che la freegilda è piaciuta e molto probabilmente continuerà a piacere?

Nascita delle nuove gilde

Terminato la presentazione delle nuove gilde, si è passati alla fase di definizione delle nuove gilde.
Francesco, supportato da Luca, ha munito di carta e penna ognuno di noi e lasciato del tempo per pensare a idee e proporle.

Dalle svariate proposte iniziali, si è necessariamente dovuto fare una scrematura.

Spiace per coloro che si sono visti bocciare la proposta (ritentate, sarete più fortunati), ma per il futuro prossimo le gilde saranno:

• freegilda 2.0
• Let’s make a videogame
• Design for emotions
• Progressive web-apps

Conclusione

Come abbiamo iniziato, è stato giusto concludere.

Fabio ha riproposto l’ice breaker che riscosse successo e divertimento al camp di ottobre del 2017.

Tutti riuniti in cerchio, scopo del gioco è contare ad alta voce un numero a testa, partendo da zero, applaudendo anziché parlare ogni volta che si arriva a un numero suddivisibile per tre o contenente il numero tre. Chi sbaglia, esce dal cerchio. E si riparte.

Il gioco termina quando rimangono tre persone in gioco.
É davvero tempo di saluti ora, arrivederci al prossimo racconto di questa fantastica giornata assieme.