Dopo aver sistemato zaini e quant’altro nella sala principale

La parola è passata a Ferdinando che ha pensato ad un simpatico icebreaker per iniziare con il sorriso la giornata.

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:

• tutti devono ricevere il peluche
• ognuno deve pronunciare un nome diverso dell’animale.

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!

Introduzione

Come oramai tradizione vuole, Francesco ha aperto ufficialmente la giornata introducendone l’agenda

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:

• chiudere i lavori per lo sdoppiamento della sede lavorativa di Seriate
• continuare i colloqui con tutti i collaboratori
• migliorare, evolvere le gilde: capire come rendere più efficace il momento delle gilde definire e condividere:
  • output atteso
  • strumenti con il quale perseguire l’obiettivo
  • cosa si vuole imparare

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 🙂

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.

Bene così, mi vien da scrivere. Sotto con le proposte!

Test book: consigli utili

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:

• Verify that the user is logged in (Verifica che l’utente sia loggato)
• Verify that the user area is accessible (Verifica che l’area utenti sia accessibile)
• Verify that the logout button is present (Verifica che il pulsante logout sia presente).

Ancora meglio sarebbe, per ogni acceptance criteria, definire:

• precondizioni
• dati di input
• step da eseguire
• output atteso

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 🙂

RegExr

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à.

Scratch: creare videogiochi per bambini

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

Architetture invisibili

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?

• Performance da raggiungere: si vuole una risposta nel più breve tempo possibile
• Estrarre informazioni utili dai dati, magari in base alla tipologia dell’utente e agli scopi

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 quanti 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:

• la linea telefonica
• l’antenna
• la cella telefonica.

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:

• cpu
• ram
• networking

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 😉

NPM dependencies 🤯

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)

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!

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 🙂

Gilde

Ripreso posto nell’aula principale, Francesco Sacchi e Luca Marcato hanno dato il via al momento di presentazione dei lavori delle gilde in corso:

• FreeGilda
• Games
• PWA (Progressive Web App)
• Design for emotions

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è.

FreeGilda

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:

• Corso su CSS, tenuto dal collega Andrea Sironi e organizzato con incontri settimanali
• realizzazione di un backend in linguaggio Golang, applicando TDD

Gilda Games

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:

• lo scenario di gioco
• caratteristiche relative alla meccanica di gioco quali punti vita, attacco, difesa, livello
• caratteristiche relative all’aspetto del personaggio
• tecnologia da utilizzare sia per il backend (blockchain Ethereum per garantire il salvataggio dei personaggi collezionabili) che per il frontend (ReactJS)

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?

• tutorial CryptoZombies: interessante, divertente
• studio delle basi del linguaggio Solidity
• Proof Of Concept grafico carino per la realizzazione del personaggio
• comprensione delle potenzialità e dei limiti della blockchain

Cosa non è andato bene?

• un componente del team se n’è andato. Ciao Johan! In bocca al lupo per tutto 🙂
• ambizione poco realistica rispetto poi a ciò che si poteva implementare
• non sempre si è avuta piena partecipazione agli incontri

Alcune note tecniche:

• Solidity + Web3.js è macchinoso e ripetitivo, forse esiste una diversa soluzione tecnologica
• le versioni del linguaggio e dei tool sembrano immaturi e poco stabili
• assenza di test automatici
• il progetto è incompleto, front-end e back-end ad ora non comunicano tra di loro

GILDA PWA (Progressive Web App)

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:

• affidabilità
• velocità
• coinvolgimento: installabile sul dispositivo, esecuzione in modalità fullscreen, icona sulla home dello smartphone, notifiche push
• sicurezza: viene esposta su protocollo https per evitare che la connessione esponga informazioni o che i contenuti vengano alterati.

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:

• concetto di pwa immediatamente applicabile a progetti esistenti
• facilmente implementabile
• documentazione adeguata

Contro riscontrati:

• durante lo sviluppo bisgona fare attenzione al service worker, script che il browser esegue in background e separato da una pagina web.
• Utilizza funzioni che non richiedono una pagina web o un’interazione da parte dell’utente. Oggi include funzioni quali le notifiche push e la sincronizzazione in background
• assenza di support per iOs (per ora)
• alcuni aspetti non trattati per mancanza di tempo

DESIGN FOR EMOTION

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:

• aspettativa
• esperienza d’uso o interazione
• ricordo

Il prodotto quindi deve/dovrebbe essere:

• utile
• usabile
• piacevole: focus della gilda

A sua volta, la piacevolezza può essere di 2 tipi (citazione aaron walter, libro design for emotion):

• superficiale: emerge con l’interazione con un prodotto (look&feel dell’interfaccia, naturalezza delle interazioni, copywriting testi chiaro e naturale,
  animazione fluida, multisensorialità)
• profonda: porta alla soddisfazione. Tiene conto dell’utilità ed usabilità. Durante questa esperienza si tende ad eliminare i cosiddetti pain point, cioè momenti spiacevoli
  durante l’utilizzo di un prodotto.

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.

Piacevolezza superficiale e emotional design

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

• della persona
• del designer

Temi affrontati:

• gli oggetti piacevoli svolgono meglio la loro funzione
• oggetti intesi come qualcosa che provoca emozioni e ricordi
• progettare oggetti per il piacere
• 3 livelli di elaborazione delle emozioni

Design del coinvolgimento

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.

Bias cognitivi

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:

• FreeGilda: sessione tecnica sul linguaggio Golang, e discussione sul format di partecipazione alle gilde
• Gilda Games: 2 diverse sessioni tecniche per mostrare logica e codice lato backend (blockchain) che frontend
• Gilda PWA: sessione tecnica dove verrà mostrato il codice e la logica della web-app, e Lighthouse
• Gilda Design for emotion: Emotion for design, con approfondimenti sulle tematiche affrontate.

Chissà, magari leggerete qualcosa in merito 😉

Definizione delle nuove gilde

“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:

• studio e la pratica su bash, un linguaggio di scripting che immagino abbiate sentito nominare tante volte
• programmazione funzionale
• reingegnerizzazione di codice legacy
• reactive programming

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:

• Alexaskill
• Lambda: functionaml programming
• Reactive programming
• User research tools
• Corso di formazione sull’argomento saghe

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).

Conclusione giornata

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!