DOT GAME @COWO42

dotgame

Ideato in collaborazione con Cowo42 è lieta di invitarvi a Dot Game, il workshop  in cui vi mostreremo come rendere più fluido il vostro lavoro e quello del vostro team.

Qual è il modo migliore per organizzare un lavoro in gruppo?
E’ sufficiente dare il massimo individualmente per ottenere i migliori risultati collettivi?

Il “dot game” è una simulazione in tempo reale di una catena di montaggio nella quale i partecipanti, divisi in operai, tester e clienti verranno coinvolti in un gioco di società che lascerà emergere tipici schemi comportamentali del lavoro di gruppo, fornendo spunti di riflessione e interessanti discussioni.

Il workshop è un’occasione per affrontare in modo informale e piacevole alcuni degli aspetti propri del Lean Management: l’ottimizzazione e la visione sistemica dei processi, le dinamiche relazionali e comunicative dei team interfunzionali, la valutazione delle prestazioni in un’ottica di miglioramento continuo.

L’evento è gratuito.

Per informazioni e curiosità sul workshop scrivi a info@ideato.it.
Clicca qui per registrarti.

 

DATA E ORA

mercoledì, 7 dicembre 2016
18:30 – 20:00 CET

Aggiungi al calendario

LOCALITÀ

Cowo42 Coworking Osimo
Via Giovanni Agnelli, 6
60027 Osimo

Visualizza Mappa

 

 

 

 

 

 

Come trovare i talenti ? Bisogna sviluppare le opportunità (per tutti)

tag-innovation-school3-copy

“La fortuna non esiste: esiste il momento in cui il talento incontra l’occasione”.
Ho scomodato l’illustre Seneca per aprire il tema, sempre più attuale, del rapporto tra formazione, opportunità e ricerca del lavoro nel mondo delle nuove professioni digitali.

Oggi la richiesta del mercato di figure professionali quali sviluppatori web e mobile, user experience designer, esperti di interazione uomo-macchina, web analyst e data scientist, cloud architect, è in costante crescita e la domanda da parte delle aziende non trova una risposta adeguata a coprire tutte le esigenze.
In un contesto così fluido, caratterizzato dall’assenza di limiti spazio-temporali e dalla crescita esponenziale di informazioni cui siamo sottoposti, trovare un luogo in cui orientarsi, formarsi e cominciare a costruire una storia professionale e personale  è la prima vera sfida da affrontare per le persone che si candidano ad una posizione lavorativa.
Ed anche è la prima vera sfida per quelle aziende che, come noi, sono alla ricerca di nuovi talenti da inserire nel team.

In ideato abbiamo costruito un processo di ricerca e selezione dei candidati che nasce in parte dalla metodologia agile applicata ai processi HR, in parte dalla rete e dagli strumenti innovativi che il web mette a disposizione ed infine dalla collaborazione con Università e Partner che sviluppano percorsi di formazione basati su metodologie all’avanguardia e di alto contenuto tecnico.
Voglio condividere con voi una nostra recente nostra esperienza che testimonia come cambiano le dinamiche attraverso cui i giovani, nativi digitali e non solo, entrano in azienda.

Dalla collaborazione con TAG Innovation School , uno dei nostri partner principali, è nata l’ ultima edizione di CodeMaster Frontend Edition  che si chiuderà il 14 dicembre con la presentazione dei progetti individuali degli studenti che vi hanno preso parte.
La collaborazione quasi quotidiana con il team di Education Specialist di TAG Innovation School, Carlos ed Enrico, lo scambio di competenze ed esperienze, ci ha permesso di vivere direttamente e passo dopo passo l’esperienza formativa insieme agli studenti.
In questi mesi, dalla metà di settembre, abbiamo avuto l’occasione di conoscerli nello studio e lavoro di gruppo quotidiani e di vedere crescere le loro competenze tecniche e soft skill.
E’ stata per noi un’occasione importante per diverse ragioni:

  • Lavorare con un Partner come  TAG Innovation School ha permesso al nostro team di misurarsi con i temi più attuali della formazione e confrontarsi con contenuti nuovi ed innovativi sul piano delle metodologie educative.
  • E’ stata un’esperienza umana molto intensa e arricchente per lo scambio di punti di vista e culture differenti portate in primis dagli studenti oltre che dai colleghi di TAG.
  • E’ stato un momento molto utile di valutazione di nuovi profili professionali. In particolare abbiamo raccolto molto volentieri l’invito di Carlos ed Enrico di TAG Innovation School di sottoporre agli studenti di CodeMaster Frontend Edition  e di UX Design Master un compito da svolgere in giornata per sondarne qualità, determinazione e creatività.

Venerdì scorso, 18 novembre abbiamo lanciato due Brief sui quali gli studenti, organizzati in team, hanno lavorato per produrre nel pomeriggio il risultato della loro attività e presentarcelo.
In entrambi i progetti si trattava dello sviluppo di un’applicazione web : una landing page dedicata agli eventi di ideato (le “Pillole”) ed un cruscotto di visualizzazione e monitoraggio remoto di macchine utensili, sulla scia di quella che è diventata una delle principali aree di intervento di ideato, la Smart Factory.
Siamo rimasti sorpresi positivamente dalla qualità dei lavori, dall’entusiasmo, dall’affiatamento dei team e dalla capacità di presentazione dei progetti che gli studenti hanno dimostrato.
Abbiamo fatto recruiting in un modo nuovo, abbiamo toccato con mano la qualità del percorso di formazione che noi stessi abbiamo contribuito a sviluppare e ci siamo divertiti ad imparare da giovani menti desiderose di apprendere e fare.

L’epoca dei colloqui in alta uniforme è finita. Aziende e persone devono incontrarsi, sui social, su skype, su slack, alle conferenze, nei luoghi come TAG Innovation School  e confrontarsi. Soprattutto, devono avere tempo ed un progetto su cui discutere e misurarsi.

L’ assessment con gli studenti di TAG Innovation School di venerdì scorso ci ha dato il tempo, il luogo ed il tema su cui lavorare insieme per poter individuare tra trenta studenti i futuri membri del nostro team.
In ideato cerchiamo persone felici del proprio lavoro, entusiasmo e motivazione prima di tutto. Il nostro candidato ideale risolve problemi in modo creativo ed è curioso, è  collaborativo e comunica efficacemente con i diversi interlocutori. E’ dotato di un lean mindset ed è portato a migliorare continuamente.
Le realizzazioni dei due brief, ciascuna con le sue peculiarità, hanno messo in evidenza alcuni studenti particolarmente brillanti.
Riconosciamo un valore autentico ed anche etico a questa nuova modalità di ricercare i talenti, i cui tratti salienti sono la relazione, la cura e la nascita di una vera e propria partnership tra azienda e candidato.

Per tornare a Seneca, la fortuna non esiste, esistono le opportunità.

 

 

 

Community give back

community-give

Uso questo termine altisonante per raccontare quello che stiamo facendo, sempre di più in ideato, forse per la mia partecipazione attiva al GrUSP, forse perché, in realtà, ci piace davvero lavorare in un ecosistema più sano e ci vogliamo impegnare seriamente a crearlo.

Negli anni abbiamo sempre partecipato a conferenze ed eventi che ci vedevano protagonisti con interventi, workshop e talk. Solo nell’ultimo mese abbiamo partecipato allo SMAU, con 2 talk al SymfonyDay e durante novembre saremo presenti al Codemotion di Milano ed all’AgileDay con un talk ed un posto ad una tavola rotonda e la scaletta per il 2017 è già piena.

Abbiamo però deciso di lasciare la nostra zona di conforto e ci siamo spinti ad operare anche sul fronte della formazione strutturata, grazie anche al supporto della Tag Innovation School, diventando, grazie al lavoro di Carla e Vittorio, il partner tecnologico del CodeMaster di Milano (e prossimamente Roma) ed aiutando nuove leve a comprendere le basi di questa professione.

Ma non ci siamo fermati qui.

Ognuno di noi nel suo piccolo sta portando in giro e raccontando quella che è la nostra visione di azienda, lavoro e collaborazione sana. Da Pietro e la sua lecture a degli studenti delle medie a Milano, a Simone (e me) con due interventi presso la Facoltà di Scienza e Tecnologie Informatiche di Cesena.

Diamo qualcosa indietro alla community facendo si che anche le prossime generazioni conoscano i corretti valori e le buone pratiche per poter diventare grandi professionisti.

 

CQRS ed Event Sourcing: Il nostro primo progetto andato in produzione – Parte 5 Conclusioni

cqrs

Dopo un anno, ho notato sia aspetti positivi che negativi legati all’utilizzo di questo pattern. Alla domanda “lo rifaresti ?” ad oggi risponderei di si, ma solo per progetti che hanno domini complessi, ovvero con logiche complesse, flussi di business complessi e quindi domini che richiedono una buona flessibilità al cambiamento.

In Soisy ci siamo trovati a dover modellare flussi molto complessi, che abbiamo dovuto modificare molte volte per esigenze di business. Se siamo quindi in situazioni dove è necessario esplorare un dominio dato che a priori le informazioni che abbiamo non sono sufficienti o non sono corrette, Cqrs ed Event Sourcing ci permettono rendere il software flessibile e quindi di poter fare refactoring  in maniera relativamente semplice.

Ricordiamoci che non siamo obbligati a dover modellare tutto il nostro software in questa maniera, ma volendo solo le parti di dominio che riteniamo necessarie. In Soisy ad esempio abbiamo tutta la parte di firma digitale del contratto che non è stata realizzata in questo modo, dato che non ne sentivamo la necessità.

Andiamo adesso ad elencare un po’ di vantaggi e svantaggi.

Vantaggi:

  • è un pattern che pur se complesso permette di mantenere una complessità lineare all’interno del software. Dopo un anno di lavoro iterativo, basato sostanzialmente sull’implementazione e il refactoring continuo data la grande complessità del dominio, il software ha sempre risposto più che bene. Non ci siamo mai trovati in situazioni in cui “non potevamo fare delle cose”.
  • l’approccio ad eventi permette di modellare molto bene i flussi che avvengono all’interno del dominio. L’esempio visto rappresenta la prima implementazione dell’approvazione di un prestito quando ancora a livello di dominio non sapevamo bene di cosa stavamo parlando. Oggi l’approvazione è un flusso composto da diversi step tra cui l’interrogazione ai servizi CRIF ed altre fasi. Con un approccio ad eventi risulta relativamente facile poter mettersi prima o dopo un determinato evento per aggiungere nuova logica. Questa cosa ci ha permesso di poter cambiare strada molto velocemente durante le fasi di implementazione della funzionalità e quindi di esplorazione del dominio
  • come avete visto in fase di scrittura siamo sempre in modalità append only. Per ogni azione richiesta al sistema, ci saranno nuovi eventi salvati. Questo riduce la complessità in fase di scrittura in quanto concetti come “modifica” o “cancellazione” vanno sempre gestiti nella stessa maniera ovvero salvando eventi che rappresentano una modifica o una cancellazione
  • poter ricostruire ogni volta che vogliamo tutti i read model, ri-proiettando tutto l’event stream. L’event store è l’unica fonte di verità e proprio da questa fonte possiamo attingere per ricostruire read model specifici per le nostre esigenze. Pensate all’esempio in cui dovete implementare dei report statistici. Invece che impazzire costruendo query con molte join, nel nostro caso potreste implementare un nuovo projector che crea un nuovo read model adhoc per le nostre esigenze.
  • l’event store è a sua volta un log. Questo rende più semplice ricostruire cosa è accaduto nel sistema,  ad esempio per avere delle statistiche su un utente o per il debug. Abbiamo a disposizione tutto quello che è successo nel dominio del software e possiamo andare avanti e indietro nel tempo (requisito che in un dominio bancario è richiesto) in base alle nostre esigenze.
  • Il prossimo è un vantaggio legato a broadway. Con il componente per il testing che mette a disposizione, possiamo testare unitariamente e molto facilmente tutta la logica di dominio.
  • l’evento diventa il contratto da rispettare tra scrittura e lettura. Questo potrebbe permettere a persone differenti di poter implementare esclusivamente la parte di lettura o quella di scrittura. Essendo un pattern complesso, ogni volta che abbiamo dovuto introdurre un nuovo sviluppatore dentro Soisy, spesso l’abbiamo inizialmente messo a lavorare sulla parte di lettura che è sensibilmente più semplice.
  • può essere applicato solo per parti complesse. Nessuno ci obbliga ad applicare il pattern in tutte le parti del software.

 

Svantaggi:

  • Curva apprendimento lunga. Non è un pattern semplice e spesso viene applicato per domini complessi. Questo binomio fa si che nuovi sviluppatori che non conoscono il pattern, anche se esperti, non saranno da subito produttivi. Oltre a quello che avete visto in questa serie di post, in Soisy abbiamo anche implementato altri concetti come i processi e le saga, utili per flussi (anche asincroni) dove più aggregati devo parlare tra di loro.
  • E’ un pattern non molto comune ed ancora non molto utilizzato dalla comunità PHP. Durante i primi mesi di sviluppo ci siamo trovati in situazioni dove l’unica documentazione utile a risolvere alcuni dubbi è stata trovata in altre piattaforme, come .net e java.  Con un po’ più di confronto magari avremmo commesso meno errori nelle prime fasi di implementazione.
  • Diventa tremendamente svantaggioso per domini semplici come ad esempio applicazioni principalmente basati su CRUD o flussi semplici.
  • E’ un pattern abbastanza verboso. Personalmente non mi ha dato particolarmente fastidio, dato che con qualche “live templates” dell’IDE ho velocizzato operazioni ripetitive come la scrittura di comandi, eventi, handler e projector. Ho sentito delle obiezioni del tipo: “per fare questa roba devi creare tanti oggetti”. Vero!! Tanti piccoli oggetti molto facili da mantenere e che aumentano la leggibilità del codice. Del resto nella programmazione ad oggetti … ci sono gli oggetti.
  • Per certe applicazioni si potrebbe arrivare ad avere aggregati che con moltissimi eventi che potrebbero deteriorare le prestazioni (in fase di scrittura). I ragazzi di broadway rispondono: “se il tuo aggregato ha tanti eventi, probabilmente hai un problema di design”. Ci sono molti domini applicativi e casi differenti nello sviluppo software, quindi accetto e condivido questa risposta come provocazione, ma mi sembra anche che dia per scontate un po’ troppe cose. In Soisy siamo in produzione da diversi mesi e non abbiamo ancora avuto problemi del genere ma in un altro progetto che abbiamo in ideato si. La soluzione è stata quella di implementare gli snapshot ovvero delle fotografie dell’event store in determinati istanti di tempo. Lo snapshot diventa il nuovo punto di partenza da cui l’aggregato si ricostruirà molto più velocemente, ma aggiunge complessità al software.
  • Siccome PHP è un linguaggio sincrono, per implementare flussi asincroni necessita di un sistema di code e/o librerie aggiuntive, aggiungendo, di fatto, ulteriore complessità al nostro sistema.

 

Spero che questa serie di post vi abbia chiarito un po’ le idee su questo pattern di cui si sente tanto parlare.
In ideato continueremo ad utilizzarlo e a condividere le nostre esperienze sia positive che negative. In futuro cercheremo di pubblicare altri post che trattino altri aspetti che abbiamo dovuto affrontare come: eventi di compensazione dovuti a bug in produzione, deploy e  implementazione di saga per la realizzazione di flussi asincroni che hanno bisogno di salvare uno stato intermedio.

CQRS ed Event Sourcing: Il nostro primo progetto andato in produzione – Parte 4 Implementiamo un api per l’approvazione di un prestito

cqrs

Per sviluppare Soisy abbiamo utilizzato symfony2broadway: prendendo come esempio uno dei casi d’uso dell’applicazione (opportunamente semplificato), in questo post vi mostreremo come l’abbiamo implementato.

Questo lo scenario: il cliente che ha richiesto un prestito dovrà fornire diverse informazioni (codice fiscale, nome, cognome ecc) . Alla fine di questo flusso verrà generata la richiesta di approvazione del prestito. L’approvazione avviene in tempo reale senza tempi di attesa.

Vediamo cosa succede lato backend quando viene invocata l’api per richiedere l’approvazione:

Command bus e repository per il read model Loan sono stati registrati come servizi nel container. In questo ci viene in aiuto il BroadwayBundle che registra dei servizi e mette a disposizione comandi da console per creare o cancellare l’event store.

Il comando viaggia sul command bus e viene gestito dal relativo Command Handler. Broadway utilizza la convezione handleNOME_COMANDO

Dopo che l’aggregato è stato ricostruito, viene chiamato il metodo approve.

Alla fine di ogni metodo di un aggregato viene chiamato il metodo apply che permette di collezionare una serie di eventi, che successivamente verranno salvati nell’event store grazie al repository utilizzato nel Command Handler.

In un approccio CQRS puro, avremo salvato l’aggragato vero e proprio. In event sourcing salviamo gli eventi, che rappresentano lo stato del nostro aggregato.

Come detto negli articoli precenti, una volta salvati gli eventi vengono pubblicati dall’event bus e mandati a tutti i projector che sono in ascolto. Broadway utilizza la convenzione handleNOME_EVENTO.

Questo metodo del projector aggiorna il read model e lo salva.

Il controllo torna al controller symfony che esegue una query ottenendo il read model aggiornato e lo restituisce al chiamante.

E’ importante notare che tutto il flusso avviene all’interno di una singola richiesta PHP, quindi in maniera sincrona. Nel caso in cui ci sia l’esigenza di renderlo asincrono c’è un interessante approccio che prevede l’utilizzo di code per la proiezione dei dati e quindi la costruzione dei read model.

Nel prossimo (e ultimo post) trarremo le conclusioni su questa esperienza che tuttora stiamo portando avanti anche su un altro progetto.