Spartan Hackathon - La nostra formazione è differente!

La nascita di un'idea

Ho già scritto un articolo riguardo a come i Nimbus hanno affrontato nel tempo il tema del continuous improvement e in generale della formazione/studio.
Oggi vi vorrei parlare di come 7Pixel ha pensato ad un modo alternativo per organizzare un evento formativo per tutti i suoi devs e di come io l'ho vissuto nel mio ruolo di organizzatore.
Il 7 Settembre 2017 si è svolta infatti la prima edizione dello Spartan Hackathon: una maratona di programmazione lunga 24 ore che ha visto sfidarsi 5 team di sviluppo.
In 7Pixel, grazie anche al nostro reparto "Qualità del lavoro" ci siamo fatti alcune domande:

• come invogliare tutti gli sviluppatori a fare formazione?
• come promuovere forme alternative di formazione che non siano "solo" corsi o conferenze?
• come rendere il miglioramento continuo più stimolante, divertente?
• come rompere la routine delle giornate lavorative con qualcosa di utile e spassoso?

Lo Spartan Hackathon è stata la risposta a queste domande.

Di che cosa si tratta

#spartanhackathon

Lo Spartan Hackathon altro non è che una epica sfida di programmazione: viene dato un problema e ogni team ha come obiettivo quello di realizzare il miglior software che risolva la sfida assegnata.

Tutti gli elaborati sono valutati da una giuria di esperti (gli Efori) che ne assegna i voti in base ai risultati ottenuti, alla creatività della soluzione trovata e alla presentazione del software stesso.

Le regole d'ingaggio

Ogni partecipante deve avere il proprio device su cui sviluppare. E' ammesso l'uso di librerie esterne e di un dataset che viene fornito dai saggi.

La battaglia dura 24 ore consecutive, ci si può riposare e rifocillare a piacimento.

Il software prodotto deve rispettare l'output richiesto ed ogni battaglione al termine dell'avventura deve fare una breve presentazione di quanto fatto.

I plotoni

Ogni plotone è composto da 4 soldati scelti in modo da separare gli elementi dei normali team di sviluppo aziendali e di avere seniority diverse all'interno del gruppo.

La scelta dei gruppi è stata una parte sicuramente divertente ma complessa in quanto abbiamo cercato il più possibile di fare squadre "equilibrate".

La  battaglia

Leonida e gli Efori

Il giorno dell'Hackathon è partito con note di folclore e ironia che scimmiottavano il tema spartano dell'evento.

Non sono mancate personalità in costume come l'annunciatore (io) e gli efori (i Product Owner dei vari prodotti aziendali).

Dopo la formazione dei plotoni (e la distribuzione di bellissime t-shirt e braccialetti con colori diversi per ogni team) e l'annuncio del tema della sfida, la battaglia ha avuto inizio.

Ogni team era in un'isola di scrivanie separata, dopo una prima fase d'analisi nella quale non sono mancate domande chiarificatrici del problema dato, si è passati al concept delle soluzioni e alla realizzazione vera e propria.

Lo stack tecnologico era libero per cui ogni battaglione ha, dopo aver trovato un accordo, incominciato a vomitare codice per raggiungere l'ambita meta. Si sono visti software in Java, C#, PHP e Ruby.

La notte

Il giorno è trascorso velocemente e nella notte si sono incominciati a vedere i primi segni di ironico squilibrio.

L'atmosfera era molto rilassata e giocosa anche se l'impegno nel realizzare il progetto era sempre presente. 

Fra un pisolo e l'altro non sono mancati divertenti siparietti e atti di pura follia :)

Il responso degli Efori

I plotoni presentano agli Efori

Le ultime ore della sfida si sono consumate nell'impacchettare qualcosa che fosse giudicabile dagli efori, i quali al termine della gara hanno assistito alle varie presentazioni dei team proponendo alcuni input particolari per poter giudicare gli output del software.

Con la consueta ilarità si è quindi arrivati alla proclamazione del team vincitore che ha ricevuto come premio, oltre alla gloria, anche delle bellissime medagliette a forma di elmo spartano :)

Dopo aver osannato i vincitori e deriso gli sconfitti abbiamo anche fatto una breve retrospettiva della giornata, a botte di post-it abbiamo trovato cos'è andato bene, cosa male e cosa si può migliorare.

I vincitori

Cosa ci ha lasciato

Ci vediamo alla prossima edizione

Sicuramente è stata un'esperienza nuova, diversa dagli altri Hackathon ai quali avevo partecipato.

Una vera sfida nella sfida in cui oltre a dover produrre un buon risultato, ci si deve anche scontrare con la stanchezza della notte, con un team con il quale non si è abituati a lavorare, con delle scelte che non sempre sono condivise e con un tema che non si conosce.

Personalmente credo che siano state 24 ore ben riuscite, in cui ogni partecipante e organizzatore si è portato a casa qualcosa,

Io come organizzatore ho compreso la difficoltà di trovare un tema adatto a partecipanti con competenze e skill diverse, ho capito che per organizzare un evento come questo l'ingrediente principale è l'entusiasmo, ho compreso che non è possibile accontentare tutti ma che è possibile comunque farli divertire e che per far in modo di avere un buon numero di partecipanti bisogna essere molto pazienti ed insistenti.

Il futuro

Speriamo che quella che si è consumata sia solo la prima di tante edizioni della Spartan Hackathon, ci auguriamo anche che questo evento possa essere, con i dovuti aggiustamenti, aperto anche all'esterno di 7Pixel coinvolgendo diverse community e aziende.

Vi terremo informati :)

Sistema difficile? Non smettere di cercare una via d'uscita

L'informatica è un mondo vasto e periglioso, e può capitare che gli eventi ci portino a dover gestire un sistema difficile, che nelle prossime righe sarà inteso come "un blob informe di codice che non conosce nessuno e porta avanti logiche complesse che non si devono rompere perché siamo online e abbiamo utilizzatori che non vogliamo scontentare". Whew.

In un mondo ideale la soluzione è semplice: riscriviamolo. D'altra parte i vecchi sviluppatori erano notoriamente dei fricchettoni buoni a nulla, e sicuramente il meglio che sono riusciti a fare è niente rispetto a quello che possiamo riuscire a fare noi. Certo, ci vorrà un po' di tempo, ma che problema c'è?

Di solito quando il Developer di turno discute la cosa col Business le cose vanno più o meno così:

D: Dobbiamo riscrivere X
B: Perché?
D: Perché funziona male ed è difficile da far evolvere, ci perdiamo sempre un sacco di tempo e metà delle volte che andiamo online rompiamo qualcosa
B: Scrivere X è costato un mucchio di soldi e funziona. Voi quanto ci mettereste a rifarlo?
D: Circa 6 mesi
B: Non possiamo tener fermo lo sviluppo così a lungo. Continuate a lavorare su X, se andate un po' più piano non importa.

E così va in fumo il sogno di un X 2.0 più facile e veloce da sviluppare.

Ma noi non siamo certo gente che si arrende, e visto che lavoriamo in un'azienda agile siamo anche liberi di inventarci soluzioni creative a problemi difficili. Si tratta solo di trovare una soluzione che:

• consenta di sostituire il codice vecchio con codice nuovo
• consenta di proseguire nello sviluppo senza (eccessivi) rallentamenti

La strategia che finora ci ha dato la massima soddisfazione può essere descritta come "sostituzione di un pezzo alla volta". In pratica l'idea è quella di cercare delle "linee" nel sistema legacy in modo da poterlo "tagliare" e sostituire un pezzettino alla volta. Il tempo speso in questa attività, così come il tempo speso nel refactoring, è "spalmato" sullo sviluppo delle varie funzionalità chieste dal Business.

Facile. Ma come si fa a tagliare un sistema?

Se si ha a che fare con un'applicazione web, una linea che generalmente si presta bene è quella che separa frontend e backend. L'idea è quella di sostituire tutto il frontend vecchio con uno nuovo fiammante, lasciando il backend al suo triste destino.

La sostituzione del frontend a sua volta sarà generalmente fatta un pezzo alla volta. Ad esempio, un modo che si presta bene consiste nel sostituire una rotta ("pagina") alla volta, usando un load balancer di livello 7 (tipo haproxy) per smistare le richieste. Via via che si è completata nel nuovo sistema una pagina che deve sostituirne una vecchia, si modifica il load balancer dicendogli che quella rotta ora deve essere servita dal nuovo sistema.

E' importante procedere per passi. Il primo è senza dubbio quello di preparare il balancer in modo che tutte le richieste vadano al vecchio sistema. Il passo successivo è quello di inventarsi una rotta non di produzione e configurare il balancer in modo che richieste per quella rotta vadano non più al vecchio sistema ma da qualche altra parte.

A questo punto si può dire che il meccanismo per la sostituzione progressiva del frontend è pronto, e si può procedere a scrivere la nuova implementazione.

Le prime pagine sostituite possono essere quelle più semplici e statiche (tipo le pagine "Chi siamo", "Termini e condizioni", ...) che ci consentono di impratichirci e di andare online (è fondamentale andare online con le nuove pagine più frequentemente possibile) per ricevere prezioso feedback dalla produzione. Non va trascurato questo aspetto: molti problemi importanti che potrebbero condurre il progetto al fallimento (es. con la tecnologia che abbiamo scelto le pagine sono troppo lente/pesanti) possono essere individuati presto, e prima si individuano meno lavoro si butta.

Le pagine dinamiche sono più complesse, perché è più difficile trovare le informazioni per riempirle.

La buona notizia è che generalmente i dati sono all'esterno anche dell'applicazione vecchia, e vivono sereni su un DB di qualche genere (relazionale o no poco importa). Questo significa che possiamo scrivere delle API nuove di zecca interrogando direttamente le basi di dati e ignorando la vecchia applicazione. Certo, in questo modo ci accoppiamo alla base dati e quindi diventerà difficile migliorarla, però guardiamo in faccia la realtà: se il DB è così messo male da non poterlo nemmeno sopportare durante la migrazione dal vecchio sistema al nuovo, allora non ci sono molte speranze di successo.

I casi nei quali i dati non dobbiamo solo mostrarli, ma anche cambiarli, possono presentare qualche insidia in più.
Se l'applicazione vecchia non usa cache, cambiarli direttamente su DB non pone particolari problemi. Il vero divertimento si ha quando l'applicazione vecchia usa cache, e quindi modificare i dati su DB crea disallineamenti di dati destinati a creare problemi difficili da gestire.
Un modo abbastanza semplice per gestire questa situazione consiste nell'implementare nel vecchio sistema una chiamata tipo "drop caches" che svuoti tutte le cache, così da forzarlo a ricaricare i dati da DB mantenendo così la consistenza. Secondo la linea della semplicità sarebbe bello avere una sola chiamata che svuoti tutte le cache, ma se ciò non fosse possibile per questioni di performance è anche possibile rendere l'API un po' più complessa per consentire l'eliminazione solo di una parte della cache. La granularità va decisa caso per caso, tenendo conto che per evitare errori difficili da diagnosticare è meglio sacrificare un po' di velocità e avere un'API più semplice.
Se il vecchio sistema è anche parte di un cluster, ricordarsi di fare in modo che tutti i nodi cancellino la cache, e non solo quello che ha avuto la ventura di essere destinatario della chiamata. In caso contrario si vedranno effetti strani (tipo pagine che cambiano in modo incomprensibile quando vengono ricaricate perché la richiesta è stata servita da nodi diversi). Come fare a propagare la richiesta è nuovamente dipendente dal caso, però c'è da aspettarsi che se un sistema ha cache e vive in cluster allora ci sarà già un qualche meccanismo di questo genere.

Ultimo caso interessante è quello della sessione utente, che dovendo essere condivisa tra i due sistemi pone nuovi interessanti problemi.
E' possibile che la sessione viva su DB come un qualsiasi altro dato, nel qual caso si tratta solo di scrivere una nuova implementazione e interfacciarla come descritto sopra. Il fatto è che spesso le applicazioni usano svariati framework e a volte una singola sessione utente è in realtà costituita dall'unione delle sessioni gestite dai vari layer che le compongono.
In questo caso una "pezza" consiste nello scrivere API nella vecchia applicazione che si aspettino di essere invocate dall'utente, e chiamarle server-to-server copiando nella richiesta tutti i cookie dell'utente. In questo modo l'onere di identificare l'utente resta alla vecchia applicazione per il tempo necessario alla migrazione di tutte le pagine. Una volta migrate tutte sarà possibile reimplementare la gestione della sessione e staccarsi da quella vecchia.

Tutto ciò, com'è facile intuire, non è una passeggiata. C'è un sacco di lavoro da fare, e visto che non ci si può lavorare a tempo piano ci vorrà anche molto tempo. Ne vale la pena?
Noi pensiamo di sì. Nella nostra azienda abbiamo almeno 3 sistemi già in produzione che sono nati come sostituti di omologhi vecchi, e un quarto è in fase di transizione. I benefici di poter progressivamente essere veloci sulle parti sostituite possono essere grandi, e c'è anche da tenere in considerazione che il morale tende a essere più alto se la quotidianità del lavoro non è solo spaccarsi la testa su un sistema orribile ma anche trovare soluzioni creative per allontanarsene.

Buona riscrittura incrementale a tutti!

Ci apriamo al mondo

Benvenuti,
oggi vogliamo presentarci al mondo: "Piacere, siamo il Team Nimbus".

Nasciamo come team di sviluppo nel Dicembre del 2011 in 7Pixel. Quel mese fu il big bang del reparto sviluppo in azienda, una massa informe di oltre 20 sviluppatori si sgretolava in team più piccoli, tendenzialmente di 4 persone, per cercare di dare una svolta alla produttività nella produzione di software.
Siamo quindi stati partoriti da un team più grande che chiamavamo TimOne.

Cosa facciamo? Beh cerchiamo di fare in modo che i nostri clienti abbiano il sorriso sulle labbra :) sviluppando del software di qualità e contribuendo a migliorarne il processo di produzione.
Come lo facciamo? Siamo partiti studiando e applicando eXtreme Programmig che abbiamo poi adattato per fare in modo che si sposasse al meglio con la nostra realtà di team e aziendale. Partiamo dai valori di XP e li integriamo con:

• Automatizzazione
• Pulizia
• Adattamento
• Cost-effectiveness

Ora "ci siamo montati la testa" e abbiamo deciso che il Team Nimbus può essere conosciuto anche al di fuori di 7Pixel. Ci apriamo ufficialmente al mondo!!

Crediamo che la condivisione sia importante e pertanto vogliamo portare un po' della nostra esperienza anche ad altri devs magari per far nascere discussioni o ricevere pareri.

Ma esattamente di cosa tratteremo in questo Blog? Parleremo delle soluzioni tecniche con cui ci siamo trovati meglio e sicuramente di metodologie Agili e come le abbiamo adattate alle nostre esigenze.

Pensiamo che oltre a dare uno spunto ad altri programmatori sia un ottimo modo per poter imparare noi stessi qualcosa di nuovo, per razionalizzare alcune nostre idee all'interno di un articolo e per capire se qualcuno ci può dare dei suggerimenti per migliorarci.

Quindi benvenuti nel nostro blog, speriamo possa esservi utile!!