Dopo aver sistemato zaini e quant’altro nella sala principale
Bentrovati cari lettori,
eccoci a Marzo, eccoci nel 2019, pronti per una nuovo camp Intré 🙂
Una bellissima giornata di sole ha fatto da sfondo alla giornata, svoltasi nella bellissima e verde atmosfera dell’agriturismo La Bergamina, ad Arcore, a due passi da Monza.
Sarà per il successo delle edizioni precedenti, sarà perchè siamo sempre di più…che folla all’ingresso dell’agriturismo 🙂
ingresso
Dopo aver sistemato zaini e quant’altro nella sala principale
sala principale
La parola è passata a Ferdinando che ha pensato ad un simpatico icebreaker per iniziare con il sorriso la giornata.
icebreaker Nando
Con la gentile concessione del figlioletto, Ferdinando ha dato il via all’icebreaker lanciando un peluche ad una persona in sala, pronunciando il nome di un animale. A sua volta questa persona ha lanciato il peluche ad un’altra pronunciando il nome di un differente animale. Le regole quindi:
Inizio divertente, non c’è che dire.
Per l’icebreaker successivo, Ferdinando ha pensato di “alzare” il livello di difficoltà, inserendo la regola per la quale il peluche va lanciato alla stessa persona del turno precedente, pronunciando lo stesso nome dell’animale.
Va detto, qualcuno ha barato, ma come si dice…SI DICE IL PECCATO MA NON IL PECCATORE 🙂
Grazie Ferdinando, ci siamo scaldati e ora siamo davvero pronti per iniziare la giornata. Parola a Francesco!
Come oramai tradizione vuole, Francesco ha aperto ufficialmente la giornata introducendone l’agenda
dig
Il 2018 è stato un anno ricco di soddisfazioni, Intré è ulteriormente cresciuta sia in termini di collaboratori che in termini di ricavi.
E per il 2019?
Chi si ferma è perduto, si dice. E Intré non vuole essere da meno. L’intenzione infatti è quella di continuare ad assumere nuovi collaboratori (caro lettore, ti stuzzica l’idea di fare parte di un’organizzazione che apprende?) e crescere ulteriormente.
Un altro obiettivo è il consolidamento della struttura organizzativa, inserendo figure lavorative che aiutino il team nel lavoro di tutti i giorni.
Executive agile coach, cto (chief technology officer o chief technical officer) e team support sono quindi benvenuti.
Colgo l’occasione per dare il benvenuto a nome di Intré tutta a Marco Loregian, nuovo collaboratore salito a bordo per appunto dare supporto ai team lavorandoci assieme 🙂
Per quest’anno l’azienda si prefigge inoltre di:
da definire tra i componenti della gilda entro il primo incontro operativo della gilda.
Un 2019 sfidante!
2019…a voi cari lettori questa data può non dire nulla, ma per Intrè vuol dire…20 anni!
Per l’occasione, Francesco ha annunciato che nel prossimo Giugno sarà organizzato un evento celebrativo di 2 giorni, da passare assieme lavorando per ciò che Intré potrà essere (mi piace ricordare e sottolineare la sigla usata da Francesco Intré Next20) ma anche divertendoci con un’attività ludico-sportiva…di più non ci è stato concesso sapere 🙂
Un altri evento da ricordare sarà l’inaugurazione dell’estensione della sede di Seriate, il prossimo Maggio!
Ora spazio al momento di open conference 🙂
Che cos’è un open conference (o 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 3 aule). Non solo proposte, ma anche richieste di aiuto su qualunque argomento o tematica. L’intento è ottenere 3 sessioni di talk di durata di 45 minuti l’uno.
Ferdinando, consolidato e apprezzato universalmente come moderatore :), ha ricordato come comportarsi durante un open conference.
C’è una sola legge, la LEGGE DEI 2 PIEDI: andiamo dove possiamo trarre / apportare valore, e 4 principi:
E come i calabroni e le farfalle, spostiamoci di stanza in stanza, trasportando in questo caso informazione e conoscenza.
Bene così, mi vien da scrivere. Sotto con le proposte!
dav
Per chi come me è sviluppatore software, può già aver capito di cosa si stia parlando.
Un libro sui test? No no, bensì un documento che raccoglie un insieme di casi di test, scritti ed eseguiti.
Ma come scrivere al meglio i casi di test? Quale scopo deve avere un documento di questo tipo? Esiste un template dal quale partire?Queste e altre domande mi frullavano per la testa, quindi quale miglior occasione di un open conference dove poter alzare la bandierina e chiedere consiglio a chiunque avesse voglia di dire la sua?
Nell’accogliente giardino antistante la sala principale, io con la gentile partecipazione di Ferdinando, Gianni, Alessandro e Marco abbiamo intavolato un’interessante discussione durante la quale sono emersi interessanti spunti e consigli.
Un test book dovrebbe contenere gli acceptance criteria, o criteri accettazione, scritti non dallo sviluppatore bensì utilizzabili dallo sviluppatore in fase di test dell’applicativo.
La forma più semplice per un acceptance criteria è
Verify that ________________
Per esempio:
Ancora meglio sarebbe, per ogni acceptance criteria, definire:
dal momento che tale documento potrebbe essere utilizzato da un utente finale, magari che ha scarsa conoscenza dell’applicativo.
E’ bene coinvolgere utenti esperti o comunque figure con conoscenza del dominio applicativo nella stesura di questi acceptance criteria qualora fosse lo sviluppatore a dover redarre tale documento. Meglio ancora se ci fosse un qualche template da seguire, e in caso realizzarlo.
Ringrazio davvero i partecipanti di questo incontro, è stata dipanata un pò di nebbia in merito all’argomento.
Nel frattempo, comodamente seduti nell’aula principale, altri colleghi hanno assistito ad una vera e propria lezione sull’argomento regular expression, o espressioni regolari.
In cattedra, il professor Damiano 🙂 il quale ha spiegato come scrivere espressioni regolari in maniera efficiente, facendo emergere le enormi potenzialità.
Il collega ux designer Andrea Sironi ha organizzato un talk relativo a Scratch.
Dopo un dolce coffee break tra caffè, brioche calde e quant’altro, tutti pronti per la seconda parte di open space
Munito di pennarello e flip chart Giulio ha proposto alla platea (eh sì, la curiosità è stata di molti), un suo ragionamento sulla tematica delle infrastrutture invisibili.
Facciamo qualche passettino indietro però.
Inizialmente c’erano monoliti. Assenza di ui, mouse, bassa potenza computazionale. L’utente interagiva con comandi digitati da tastiera.
Negli anni, con l’evoluzione della tecnologia, la complessità è esplosa. Complessità sia in termini di moli di dati sempre crescente e soprattutto in termini di complessità architetturale.
E’ stata, e sempre sarà, una rincorsa nello scegliere la miglior architettura per raggiungere determinati obiettivi e performance.
Che cosa vogliamo oggi?
Quindi: partendo da una gran mole di dati, fornire l’informazione giusta all’utente giusto nel più breve tempo possibile.
Dove siamo oggi?
Cloud, virtualizzazione, container, serverless, blockchain…l’utente finale quanto ne sa dell’architettura che sta dietro?
Facendo qualche passettino indietro negli anni 2000-2010, ricordando una classica architettura Java, composta da diversi componenti. Qual’era il costo nell’adottarla? E quanto costava farla evolvere?
Era necessario mettere mano a più livelli dell’architettura.
Ieri, come oggi, esistono dei pattern architetturali che aiutano a scegliere l’architettura migliore, per poi avere un costo di mantenimento più basso.
Il vero quesito è: come comportarci oggi nella scelta architetturale, con un dominio più complesso?
Pensiamo alla virtualizzazione: dapprima crearne una nuova voleva dire utilizzare diversi strumenti, oggi è possibile crearla scrivendo poche righe di codice -> infrastrucure as a code, o iaac. Quindi senza dover preoccuparci di conoscere quanti e quali strumenti utilizzare.
Per aiutarci a capire il suo pensiero, Giulio ha usato una metafora, personalmente azzeccata, del treno in corsa: noi siamo sul treno, non preoccupiamoci, non dobbiamo guidare, il treno va su di un binario.
Il binario è la nostra infrastruttura invisibile.
Se ci riflettiamo un attimo, è possibile individuare diversi esempi di infrastrutture invisibili:
Come funzionano non lo sappiamo, ma sono indispensabili per lo smartphone, il tablet, i dispositivi che ne sfruttano il servizio.
Negli anni, si è sempre spostato il limite oltre il quale non si poteva andare con le architetture.
Nel 2000, questo limite era il sistema operativo, la jvm (java virtual machine).
Nel 2010 questo limite era rappresentato dalle macchine virtuali, servizi (iaas, paas, saas)
Nel 2020: cloud, multi-cloud, caas (container as a service), machine learning, api fornite da Google o Amazon.
E per il futuro?: sistemi operativi totalmente distribuiti, ecosistemi di servizi di diversa complessità che permettono di raggiungere i nostri scopi (elaborazione veloce, ottenere il dato che sia di valore per i nostri scopi)
Ancora una volta, SIAMO IN GRADO DI DOMINARE QUESTE ARCHITETTURE DI COMPLESSITA’ SEMPRE CRESCENTE?
Secondo Giulio, arriveremo ad un punto dove bisognerà come dire, tirare un riga.
Si tenderà a dover\poter comunicare utilizzando la riga di comando (CLI), e magari non lo faremo solo noi esseri umani, ma anche robot o software istruiti a dovere.
Pensiamo a Kubernetes, ai servizi di Text to Speech. Pensiamo soprattutto a qualcosa che sia standard, sicuro e affidabile, libero, e regolamentato.
L’interazione uomo-macchina sarà ulteriormente semplificata.
E noi sviluppatori, tecnici IT… dove ci posizioneremo rispetto a quella famosa riga che verrà tirata?
Saremo SOPRA quella riga, e cioè coloro che realizzeranno servizi, app che sfruttano queste architetture invisibili oppure SOTTO, visti quindi come esperti di dominio, che aiutano alla realizzazione di sistemi?
DevOps può essere una risposta.
DevOps non è semplicemente una delle tante posizioni lavorative nate in questi ultimi anni bensì un insieme di pratiche che permettono di poter realizzare il tutto.
Giulio ha poi chiuso il suo intervento dando la sua opinione su come come potrà cambiare il business in quest’ottica di infrastrutture invisibili.
Pensiamo a quali parametri guardiamo quando si deve scegliere un cloud vendor:
Valutiamo quindi il costo delle risorse. A tendere, si valuteranno i servizi (api), il guadagno quindi si sposterà dalle risorse ai servizi. Ancora una volta, pensiamo a Kubernetes, una soluzione rientrante nella categoria caas: Container as a service.
Kubernetes è sostanzialmente un orchestratore di oggetti chiamati pod, che contengono container. E’ possibile aggiungere\rimuovere pod, cioè servizi, senza preoccuparmi di come gestirli.
Sarà poi il cloud vendor scelto che gestisce le risorse.
Posso scegliere il cloud vendor che più mi aggrada, tanto non devo guidare io. E’ tutto sulle “rotaie” che in questo caso sono rappresentate da Kubernetes, che può essere visto come sistema operativo distribuito. Ma niente paura, il tutto non si configura da solo e non può funzionare senza l’intervento umano. Si avrà ancora bisogno di figure IT e altre figure lavorative figlie di un mondo in continuo cambiamento.
Grazie Giulio per averci fatto riflettere sul mondo che è stato, e soprattutto sarà. Spesso non ci rendiamo conto, ma una rivoluzione è in atto. E’ solo che non la vediamo 😉
Durante questo talk Francesco Sacchi ha raccontato le differenze tra i vari tipi di dipendenze che i pacchetti npm possono avere (dependency, dev dependency e peer dependency).
Al termine della spiegazione è stato proposto un piccolo quiz/esempio con semplici pacchetti creati ad-hoc per validare ciò che si era appreso, per mettere in luce le principali problematiche e per cercare di dare risposta alle domande che uno sviluppatore di solito si pone affrontando il tema delle dipendenza.
Il risultato di questa discussione?
Tutto il sistema di dipendenze di npm si basa sul Semantic versioning e sul fatto che questo venga correttamente utilizzato da tutti i creatori di pacchetti. 🤯
Qui trovate le slides del talk.
Rifocillati da un’ottima pausa pranzo, Ferdinando ci ha richiamati all’ordine nel giardino antistante l’agriturismo.
Diverse decine di palloncini verdi, rosa, gialli rossi e blu ci attendevano.
“Che cos’avrà mai in mente Nando per noi per il momento serious game?”
Prima ancora di introdurci al gioco, un ulteriore momento di gioia. Auguri Matteo per la nascita della seconda figlia! (Il regalo non è la scatoletta rosa heheheh)
dav
Siamo colleghi sì, ma perchè no, anche un bel gruppo di amici 🙂
Torniamo ai palloncini.
Ferdinando ci ha consegnato un palloncino a testa chiedendoci di legarlo alla caviglia.
Va da sè che si sono create delle squadre. Obiettivo? Scoppiare i palloncini di colore diverso 🙂
Pronti via quindi, persone inseguite da altre persone per tutto il giardino. Momento tanto intenso quanto breve, e quanta energia!
sdr
Per il secondo gioco siamo rimasti sempre in giardino, riuniti attorno ad un disco di legno, con un gancio attaccato alla base, dal quale si diramano 30 (più o meno) diversi fili colorati.
Attorno al disco sono stati posizionati dei blocchetti di legno con una fessura in cima.
Secondo voi, che dovranno mai fare 30 (più o meno) persone con altrettanti fili e un gancio attaccato ad un disco di legno?
Tutti uniti, concentrati e soprattutto coordinati, l’obiettivo è agganciare ogni pezzo di legno e impilarli a formare una bella torre.
Potete facilmente immaginare l’effetto Jenga di questa esperienza 🙂
Ripreso posto nell’aula principale, Francesco Sacchi e Luca Marcato hanno dato il via al momento di presentazione dei lavori delle gilde in corso:
Ricordando che ogni gruppo ha a disposizione circa 20 minuti durante i quali si espone ciò che è stato fatto, eventuali mancanze\problemi durante nello svolgimento della gilda, e cosa poter approfondire durante gli appuntamenti di gildonferenza.
Per i lettori meno attenti 🙂 non è la prima volta che racconto di una gildonferenza.
Nel lontano 2018, durante il camp di Ottobre, Francesco e Luca hanno proposto questo momento di approfondimento di temi studiati nelle gilde appena concluse, con incontri organizzati negli spazi interni di Intrè.
Gilda del quale facevo parte.
Il nome free sta ad indicare appunto la libertà di poter approfondire più argomenti per i quali i 4 mesi canonici di una gilda risulterebbero un tempo eccessivo.
Argomenti da approfondire non in solitaria, ma in mini gruppi di almeno 2 o persone.
Nonostante avessimo definito una board su Trello con una lista di argomenti da affrontare, purtroppo la gilda non è andata bene.
Per la maggior parte dei componenti la partecipazione alla gilda è stata scarsa, prevalentemente a causa di impegni lavorativi.
Pochi obiettivi portati a termine:
Obiettivo della gilda è la realizzazione di un semplice (o perlomeno così pensavano inizialmente 🙂 ) videogame, precisamente un gioco a turni, dove ogni giocatore governa un solo personaggio per combattere contro altri giocatori.
I primi incontri della gilda sono stati spesi per definire:
In merito alla blockchain il gruppo ha deciso di seguire il tanto simpatico quanto esaustivo tutorial CryptoZombies, per imparare a programmare in
Solidity, linguaggio di programmazione per appunto implementare Smart Contract.
Per la parte di backend, è stato implementata logica per:
– creare e salvare un personaggio,
– lettura personaggi dell’utente,
– compilazione e deploy della app su un blockchain locale di sviluppo
Per la parte di frontend invece, è stato realizzato un avatar creator (un grazie al collega Andrea Sironi :)) con il quale poter scegliere ad esempio i vestiti, capelli e colori.
La comunicazione tra frontend e app è stata gestita con chiamate tramite la libreria Web3.js
Cos’è andato bene durante la gilda?
Cosa non è andato bene?
Alcune note tecniche:
Obiettivo di questa gilda è la realizzazione di una pwa, cercando di cogliere pro e contro.
Ma che vuol dire pwa?
Per pwa si intende una applicazione web con caratteristiche quali:
che la rendono simili ad un’applicazione nativa.
Da un punto di vista tecnologico, si è deciso di realizzare il backend in Node.Js e il frontend con React.js. Per il database è stato utilizzato MongoDb.
Degno di nota l’utilizzo di Lighthouse, un tool open-source disponibile anche nel developer tool di Google.
Fornisce statistiche tra le quali livello di performance, affidabilità, best practices, progressive web app. Statistiche utili per capire appunto il livello della web-app anche durante la fase di sviluppo.
Come esercizio, il gruppo ha deciso di realizzare una pwa per tenere traccia degli elementi di una collezione. Pwa che hanno dimostrato con una demo 🙂 durante la quale si poteva accedere o da istanza del browser da pc o da smartphone.
Una volta inserito il nome di una room, si poteva inserire un item specificandone il nome.
Siccome siamo un pochettino nerd è stata creata la room Avengers, e tra un item Thor, un item Hulk…ogni volta che si aggiornava la pagina si poteva vedere la lista di item aggiornata.
Durante la demo è stato dimostrato anche la funzionalità della web-app offline!
Pro della tematica pwa:
Contro riscontrati:
Eccoci alla gilda dei nostri colleghi ux designer.
Emanuele ha fatto una breve introduzione su come Thanks design cura l’esperienza utente nella ideazione di un prodotto, per aiutare a capire lo scopo di questa gilda.
L’esperienza ha differenti fasi:
Il prodotto quindi deve/dovrebbe essere:
A sua volta, la piacevolezza può essere di 2 tipi (citazione aaron walter, libro design for emotion):
Quindi individuare e superare le aspettative dell’utente è importante.
Cosa è stato fatto durante questa gilda?
Una prima fase è stata dedicata alla ricerca degli argomenti, per capire i punti da affrontare e la lettura di alcuni libri sull’argomento in un secondo momento.
Di seguito i punti approfonditi.
Valentina ci ha parlato di emotional design, e di quanto appreso tramite la lettura del libro Emotional design.
Quando interagiamo con un prodotto mediante la sua grafica, cerchiamo di focalizzarci sulle micro interazioni, o meglio con una certa funzionalità del prodotto all’interno di una interazione globale.
Il tutto ruota attorno ad un singolo task da raggiungere, quindi un unico obiettivo.
Progettare i dettagli quindi, ad esempio il cambio dell’interfaccia grafica di un pulsante durante diverse fasi (magari un’icona che indica l’attivazione, una per l’attesa, un’altra per la disattivazione).
Si parla di emotional design visto dal punto di vista
Temi affrontati:
Matteo si è occupato del tema del design del coinvolgimento, raccontandoci quanto appreso dalla lettura del libro L’arte del coinvolgimento.
Tema: il design del coinvolgimento mira a fornire istruzioni per progettare prodotti ed esperienze da cui l’utente si sente attratto e portato a ripeterne la fruizione.
Possiamo intendere un bias cognitivo come un pattern di deviazioni del giudizio razionale.
Roberto ci ha raccontato quanto appreso dalla lettura di un libro che tratta il tema dei bias e come questi influenzano l’utente nella sua esperienza con un qualsiasi prodotto.
Dalla presentazione delle gilde, sono emersi gli argomenti per gli appuntamenti di gildonferenza:
Chissà, magari leggerete qualcosa in merito 😉
“Morta una gilda, se ne fa un’altra”. Recita così il detto, giusto? 🙂
Scherzi a parte, concluse le presentazioni è arrivato il momento di proporre nuove gilde, che può voler dire riproporre una precedente gilda per continuare lo studio e magari il progetto che ne è nato.
Sotto con le proposte quindi!
Gianni ha proposto diversi argomenti:
Marco Ranica ha proposto una gilda sul mondo Amazon Web Services e in particolare come realizzare una skill con Alexa, l’assistente vocale di Amazon.
Lorenzo ha proposto una gilda che come obiettivo si pone la realizzazione di una app in linguaggio Kotlin. Il backend è già esistente, dal momento che è stato realizzato nell’ambito della FreeGilda appena conclusa 🙂
Carlo Ballabio ha proposto lo studio del pattern saga per implementare transazioni distribuite in un contesto di architettura a microservizi.
Carlo Mandelli ci ha riprovato con la sua agiLego 🙂 Come al camp precedente, ha infatti riproposto una gilda per la riproduzione di cerimonie agili con il Lego, magari creando animazioni.
Ma non solo.
Fresco delle nozioni apprese durante la gilda sulle progressive web app, ha proposto la realizzazione di una pwa appunto per gestire la nota spese aziendale.
Emanuele, per i colleghi designer, ha proposto una gilda dal titolo User research tools: studio finalizzato per aggiornare i tool che attualmente vengono utilizzati nella fase di user research.
Il buon Marco Rotondi ha proposto uno studio sull’architettura serverless, che consente di creare applicazioni concentrando la propria attenzione sul prodotto, piuttosto che sulla gestione e il funzionamento di server e di runtime, siano essi sul cloud o in locale.
Gabor ha proposto una gilda che come argomento ha lo studio della programmazione funzionale per realizzare immagini canvas tramite l’utilizzo di librerie. Un canvas è un elemento che offre la possibilità di creare uno spazio all’interno di una pagina web sul quale insistere con delle API di disegno bitmap.
Ultimo ma non per importanza, Francesco Sacchi, come Gianni, ha proposto una gilda sull’approfondimento del tema della programmazione funzionale.
Come sempre, tantissima carne al fuoco. Ed è un bene che sia così 🙂
Di seguito le future gilde:
I componenti di ciascuna gilda si sono riuniti per decidere assieme l’obiettivo da raggiungere, e come raggiungerlo (realizzazione di un progetto, approfondimento di un particolare argomento ad esempio).
Un’altra bellissima giornata di camp si è conclusa.
Prima di salutarvi, vorrei ringraziare i colleghi che hanno contribuito alla realizzazione di questo articolo ed Intré che oramai da 3 anni mi dà la possibilità di scrivere articoli su giornate di camp e conferenze.
Vi saluto davvero ora, e a nome di tutti…arrivederci al prossimo camp!
Cosa sono gli algoritmi genetici? Quando e come applicarli? Ne parla Marco Loregian in una sessione dell'open conference organizzata durante l'Intré Camp di Ottobre 2019.
Agli Italian Agile Days di Modena Giulio Roggero racconta la sua esperienza nei progetti software con un'architettura a microservizi, e Feature Team.
Portando esempi di progetti al quale ha partecipato, cercherà di spiegare i vantaggi nel rendere evolutiva un'applicazione frontend senza che invecchi troppo nel tempo.
Via Gaslini, 2 20900 Monza (MB)
Telefono:+39 039.28.45.774
Codice Fiscale: 02885420964
Partita IVA:IT02885420964