Codemotion Rome 2017 – inseguire elefanti 🐘 fino alla luna 🌝

Come al solito volevo scrivere prima questo post, ma in questo periodo sembro avere un backlog abbastanza scombinato (e i capelli un po’ dritti). Questa scombinatezza di piani però non mi ha distolto dall’andare lo scorso weekend al Codemotion, e farmi avvolgere dall’amicizia di tante persone che non vedevo da tantissimo tempo, dal calore di chi vedo spesso a Roma, ma soprattutto dalla preparazione degli speaker di cui quest’anno mi sono goduto i talk.

Non so se è per qualche ragione particolare, ma quest’anno per me è stato il Codemotion più bello di tutti. Forse ho sentito di più la mia missione di “portatore di novità” in quanto a bagaglio culturale aziendale, forse effettivamente gli speaker di quest’anno avevano qualcosa in più (vero Luca? Vero Matteo?), o forse semplicemente sotto alcuni punti di vista ero più rilassato tanto da riuscire a godermi meglio l’evento, ma nessun Codemotion mai fatto supera per me quello di quest’anno.

Che cosa ho seguito

Molto del valore che ha avuto per me la conferenza quest’anno sicuramente lo devo agli speech che ho scelto di seguire, e con un pizzico di fortuna (può capitare il talk leggermente fiacco) ho piazzato tutte le mie scommesse sui cavalli giusti, nonché ovviamente su persone che mi hanno fatto portare a casa un bagaglio clamoroso di conoscenze e sentimenti.

Nello specifico, e in rigoroso ordine cronologico:

• Giorgio Natili - Unethical JavaScript: La voce sexy di Giorgio mista al suo accento “peggiore di Mario” (parole sue) di solito è sinonimo di qualità. Anche questa volta non mi ha deluso, parlando di best practice miste a un po’ di ultimo grido per scrivere codice leggibile facendo un po’ meno gli hipster e un po’ di più i ragazzi gentili nei confronti dei colleghi che dovranno mantenere le nostre applicazioni. Messaggio principale: “Scrivi sempre il codice come se il prossimo maintainer fosse un pazzo psicopatico che sa dove vivi”.
• Luca Lanziani - Introduzione a NodeJS: Durante il meetup preserale della meravigliosa community di RomaJS (di cui qui alcuni esempi di figaggine) Luca ha presentato le basi per scrivere Javascript sul server senza paura e con un minimo di cognizione di causa. La cosa interessante è che era stata preventivata un’introduzione un pelo più profonda (e interattiva), cosa andata improvvisamente a monte visti due fattori: l’aula pienissima di persone, e il fatto che in pochi in realtà si erano già confrontati con NodeJS anche solo in maniera embrionale. Rispolverare le basi è sempre interessante, bisognerebbe farlo periodicamente con ogni tecnologia o framework, e date queste premesse anche i più senior hanno potuto (imho) portare comunque a casa un valore aggiunto.
• Russ Olsen - To The Moon: Troppo inspirational anche per una track inspirational. Russ Olsen ha descritto il percorso dalla terra alla luna, le decisioni strategiche che hanno condotto a questo traguardo, gli ostacoli, e le storie di uomini che hanno gettato il cuore oltre quegli ostacoli. Ho pianto come un vitello, e ho anche riscoperto il motivo per cui faccio quello che faccio, ogni giorno.
• Luciano Mammino - Universal Javascript Web Applications with React: Non avevo mai visto uno speech di Luciano, è molto bravo e ha introdotto un concetto interessante, demistificando il concetto di Universal Javascript (ossia il codice che può essere eseguito in maniera indiscriminata lato server e lato browser), mostrando come attraverso una serie di best practice e facendo riferimento a determinate librerie si possa raggiungere questo risultato con poco sforzo.
• Ronnie Chen - Staying Alive: Patterns for Failure Management From the Bottom of the Ocean: Rimanendo nella stessa aula, ho avuto il piacere di seguire Ronnie Chen, Data Engineer di Slack che ha parlato di pattern per la gestione del fallimento, facendo riferimento a uno degli oggetti più pericolosi per chi fa il sub, ovvero il rebreather. Prendendo spunto dalle procedure di emergenza in caso di malfunzionamento dei rebreather, e dalle best practice (come le checklist pre-immersione) per verificare in maniera preventiva l’operatività di questi, Ronnie ha illustrato come portare questi pattern all’interno di una tech company. Il paragone tra un server sotto botta e un rebreather che ama far scherzi è stato particolarmente efficace.
• Nicola Iarocci - RESTful Services Made Easy: The Eve REST API Framework: Il talk di Nicola è stato un hands-on interessante su un framework che ha sviluppato lui per servizi web REST in Python. A parte l’apprezzatissima scelta tecnica di basarsi su Flask per gestire le richieste agli endpoint, mi è risultata veramente efficace la strategia di far gestire praticamente qualsiasi cosa a livello di configurazione, dando la possibilità al programmatore di inserirsi nel ciclo di vita della API solo quando ne ha realmente bisogno. In questo modo secondo me il time to market si abbassa di un casino di tempo.
• Matteo Manchi - React Native for multi-platform mobile applications: Non avevo mai approcciato le applicazioni Android o iOS, se non per qualche ora totale della mia vita. React Native sembra un buon approccio allo sviluppo mobile per massimizzare la condivisione del codice su più piattaforme, e riuscire comunque a non perderci in performance renderizzando in ogni caso componenti grafici nativi. Matteo poi, come speaker, è veramente bestiale, tiene l’attenzione del pubblico e qualsiasi concetto lo esprime in maniera molto chiara, senza fronzoli, e sempre con qualche battutina che alleggerisce il clima. Come ultimo speech è stato veramente una boccata d’aria fresca, e non ho avvertito minimamente la pesantezza di tutta la conferenza sulle spalle. Plus: appena uscito volevo andare a scrivere JS per mobile. 😂
• Alberto Brandolini - Chasing Elephants: Alberto è stato un keynoter veramente tosto. Il suo talk è stato controverso, perché da un lato ha celebrato ancora una volta il “perché lo facciamo”, dall’altro mi ha fatto venire un po’ di depressione specialmente con le sue frasi riguardo il fatto che nessuna azienda italiana ha mai visto un senior developer in faccia. Sono tendenzialmente d’accordo, e questo mi intristisce molto. Anche qui un bagaglio molto interessante da portare a casa: “good developers go where good developers are; good developers are compulsive learners”.

Il pelo nell’uovo

“Ma ha anche dei difetti” è un meme che mi fa sempre ridere. E anche questo Codemotion, come quelli passati, e come la Panda 4x4, ha anche i suoi difetti. Difetti minimi, per carità, ma vale la pena andare a trovare il pelo nell’uovo per evitare lo status quo, no? 😇

In realtà come miglioramento marginale quello che ho potuto vedere è che molto della conferenza era spostato sul lato architetturale dello sviluppo di un’applicazione, o sul frontend. Una cosa a cui mi piacerebbe assistere sarebbe una maggior diversificazione tra le piattaforme utilizzate, mentre il feeling di quello che propone la comunità (che mi rendo conto che non sia esattamente controllabile da Codemotion) è sempre un po’ “Javascript, Java - e poi ci sono i soliti ignoti tipo Golang e Elixir”.

Mi rendo conto che sia meno appetibile, e che vada contro i miei stessi interessi, ma a me piacerebbe vedere anche altri tipi di informatici come gli esperti di networking confrontarsi a Codemotion, eventualmente a scapito di Javascript che quest’anno ha avuto una track dedicata.

D’altra parte mi fa piacere che una tecnologia che mi piace tanto come questa abbia una track tutta sua e un percorso privilegiato… forse un po’ troppo? Dopo questa critica, in ogni caso, sono sicuro che Guido mi verrà a prendere per un orecchio in ufficio 😂

Ending theme

Siamo arrivati in fondo. Spero che Codemotion continui così, è una grande conferenza con i suoi punti di forza e le sue contraddizioni. Mi fa piacere che in molti continuino a frequentarla, e che ormai sia il punto di riferimento in Italia. Al di là dell’aspetto tecnico, è anche un modo per incontrare tantissimi amici che altrimenti non vedrei mai, e un momento per dire “ok, stacco gli occhi dal monitor”.

Al prossimo Codemotion 😎

Images courtesy of Codemotion. Thanks guys!

ChatOps, Botstation, e un momento di relax con RomaJS

Nell’ultimo mese ho avuto a che fare con un po’ di grattacapi interessanti; in particolare, con il mio nuovo team ci siamo trovati nella condizione antipatica di dover svolgere alcuni task ripetitivi senza che tutti conoscessero esattamente le operazioni da svolgere e i comandi da dare in pasto alle macchine.

Per questo motivo ho deciso di introdurre un po’ di pratiche ChatOps (qui qualche informazione in più), in modo da avere un bot a disposizione che mi consentisse di dedicarmi alle cose importanti, senza essere infastidito dal “come si fa”, da una miriade di cose ripetitive, e così via. Il primo passo è stato studiare un po’ la piattaforma di Slack (che usiamo in UniquID) e capire cosa potevo fare grazie alla libreria slackbots per NodeJS; il passo induttivo, invece, è stato dare forma a un piccolo minion che prendesse i comandi dal team e li trasformasse in azioni reali.

ChatOps è divertimento

Immediatamente mi sono accorto che a meno di qualche ritocco era tutto pronto: una forma simpatica del bot ne ha facilitato l’adozione da parte del team, che in meno di poche ore aveva già accolto il nuovo arrivato e il suo cervello artificiale con tanti sorrisi. Lui è ancora lì che fa cose per noi, quando gliele chiediamo, e ogni tanto aggiungiamo qualche funzione che potrebbe essere utile – insieme ad altre sicuramente più facete.

Una cosa che ho notato è che adesso pur mantenendo un debito tecnico abbastanza elevato sulle attività sistemistiche, comunque il team è in grado di gestirle senza degli specialisti, senza frustrarsi, e avendo comunque nei casi peggiori una linea guida su come diavolo fare una determinata cosa, data proprio dal sorgente del bot.

Codice sorgente che allo stato attuale, dopo un po’ di macchinazioni, è diventato all’incirca quello che segue:

var Botstation = require('botstation');
var bot = new Botstation.Bot();
 
bot.config({
    key: 'xoxb-157105193143-eJdSjJRttSCU2DAd3IdAtBoi',
    name: 'Dat Bot'
});
 
bot.task({
    name: "Help",
    matcher: "isMessage",
    content: "!help",
    exec: (bot, data, params) => {
        bot.postMessage(data.channel, 'Do you need help?', params);
    }
});
 
bot.start(() => {
    console.log('Bot started!');
});

Botstation

Il codice qui sopra non è campato in aria, bensì deriva da un lavoro di semplificazione che ho fatto su ciò che avevo in un momento precedente; ho realizzato infatti che non ci sono moltissimi framework per scrivere bot, così ho provato a buttarne giù uno mio, con una API architettata in modo da poter aggiungere quanti task mi servivano nascondendo tutta la (poca per il momento, a dir la verità) complessità di gestione del websocket, degli eventi del bot, e così via. Ho chiamato questa nuova creatura Botstation.

Il prossimo passo che vorrei intraprendere è quello di rendere Botstation multipiattaforma, scrivendo un meccanismo per cui avendo a disposizione vari adapter (Slack, Telegram, Facebook) si riesca a mettere in piedi un chatbot senza sforzo nascondendo la complessità della diversità dei servizi e delle loro API. Solo che non ho tempo di farlo adesso 😁

Fortunatamente, però, ho visto che i vari wrapper per le API di Telegram e compari sono orientati agli eventi nella stessa maniera.

RomaJS: ChatOps in compagnia con birra e taralli

Ho presentato questo piccolo lavoretto allo scorso RomaJS (veniteci a trovare!), credendo di fare solo da riempitivo perché non c’era nessun altro che portasse uno speech di livello. A sorpresa, invece, le persone sono rimaste abbastanza colpite sia dall’approccio ChatOps, fortemente orientato al cazzeggio inter-team, sia dalla facilità con cui è possibile scrivere un chatbot – con o senza Botstation, che ora come ora funge solo da wrapper di Slackbots.

Avrei dovuto scrivere questo post parecchi giorni fa, ma purtroppo sono state settimane complicate ed è stato veramente difficile mettere insieme i pezzi per via degli impegni di questi giorni. Un aspetto veramente stimolante è stato incontrare anche a Codemotion, in questi giorni appena passati, svariate persone che mi hanno chiesto come stesse andando lo sviluppo di Botstation e mi hanno esposto alcune domande e alcuni dubbi.

Io ovviamente sono stato felicissimo dell’impatto (seppur piccolo) che sta avendo un framework del genere, che onestamente avevo iniziato a scrivere solamente come esercizio personale. 😎

Quindi?

Riassumendo:

• ChatOps vi aiuta a liberarvi del peso di task orientati alla sistemistica, ripetitivi, noiosi;
• Un bot utile è sempre ben accolto; un bot con funzioni aggiuntive stupide, insensate e ironiche ancora di più perché migliora il morale
• Botstation vi può aiutare, se usate Slack. Presto vi potrà aiutare anche se usate altre piattaforme di messaggistica 👌

Hangouts è appena diventato un competitor di Slack

Using Google Hangouts is often about videoconferencing, but it’s also about collaboration in many different forms. Over the past few years, the company has evolved its strategy to one centered around team productivity and chat.

E così comincia la transizione verso un nuovo tipo di terreno, assolutamente fertile, sul quale Hangouts si innesta e va a diventare un competitor diretto di Slack.

Il guaio è che mentre l’applicazione di Google per quanto riguarda la conversazione scritta è in mezzo al guado da un bel po’ mancando occasioni e fallendo l’affermazione come tool di collaborazione di massa, altri hanno saputo mettersi in risalto in maniera più significante.

Per esempio Slack, che ormai è il centro della comunicazione di parecchie community, di un sacco di aziende, e in generale di tutte quelle organizzazioni che preferiscono centralizzare il lavoro nello stesso posto in cui avviene tutta la comunicazione interna.

Microsoft con Teams ha provato ad imporsi su questo terreno, avendo già un bel bacino di clienti Office, ma pare che non stia funzionando. La traction di Slack aumenta, e vedremo cosa sarà capace di tirare fuori Google oltre qualche bot e qualche caratteristica aggiuntiva.

Rendere un'app React completamente funzionale (e reattiva)

In this article I’ll talk about redux-cycles, a Redux middleware that helps you to handle side effects and async code in your React apps in a functional-reactive way — a trait which is not yet shared by other Redux side effect models — by leveraging the Cycle.js framework.

Con il nuovo anno mi sono detto che avrei cominciato a condividere i miei rompimenti di capo sulla programmazione funzionale. Ancora non sono arrivato a una quadra tale per cominciare a mettermi per iscritto, però ormai siamo a marzo e tanto vale cominciare a scriverne, cominciando con il post di un amico.

Luca Matteis è uno dei miei compagnucci di banco di RomaJS, e ha scritto questo meraviglioso compendio su come rendere una React application “fully functional”, che va esattamente nella direzione in cui sto andando io, ovvero quella del “functional programming for dummies”.

Mozilla + Pocket = <3

Ora che ho trovato un briciolo di tempo in mezzo (sul finale, anzi) di una settimana incredibile, parliamo un attimo di questo fatto: Mozilla ha acquisito Pocket. Mi sembra tutto molto in linea con la strategia di Mozilla che prevede di estendere la sua visione sui contenuti e sul web ad ogni ambito, cosa che aveva già provato a fare svariate volte tramite Firefox con varie soluzioni per la leggibilità degli articoli su Internet.

Pocket brings to Mozilla a successful human-powered content recommendation system with 10 million unique monthly active users on iOS, Android and the Web, and with more than 3 billion pieces of content saved to date.

Pocket è esattamente il tassello mancante, poiché una piattaforma che ha mercato e funziona sia su Android, sia su iOS, fa esattamente quello che Mozilla ha cercato di integrare in Firefox per anni, ovvero i contenuti “without all the bullshit”. Chi si ricorda della Reader View? L’avete mai usata?

In working closely with Pocket over the last year around the integration within Firefox, we developed a shared vision and belief in the opportunity to do more together that has led to Pocket joining Mozilla today.

Quello che mi sembra un buon colpo per Mozilla, mi sembra anche un’elegante “uscita di scena” per Pocket, in un senso molto particolare: nonostante io sia un utilizzatore di Pocket in maniera molto massiccia, non mi sono mai, mai, mai trovato nella condizione di (anche solo) desiderare un upgrade del mio account. Cosa che svariate altre volte è successa invece ad esempio con Feedly. Alla luce di questo, ho sempre avuto qualche problema ad accettare l’idea di sostenibilità di un’azienda come Pocket.

Data questa premessa, sicuramente Mozilla è un buon approdo, dato che la sostenibilità del modello di Mozilla non è assolutamente data da una visione capitalistica quanto più dall’aderenza al modello di una charity.