All Posts in Coding

marzo 8, 2017 - No Comments!

Training e Affiancamento su Microservizi

formazione microservicesIn occasione di Incontro DevOps lanciamo una nuova offerta di per l'adozione di microservizi.
I corsi, erogati a Milano, Roma e presso le aziende, sono pensati per far intraprendere il percorso di adozione sia dal punto di vista metodologico sia per realizzare la propria architettura utilizzando i servizi cloud di AWS e i meccanismi di containerizzazione di Docker.
Il valore aggiunto consiste in un pacchetto kickstart per calare i concetti appresi nel contesto del dominio aziendale. Una serie di attività di affiancamento per raggiungere i risultati in minor tempo.

Pagina di dettaglio >

 

gennaio 5, 2017 - No Comments!

Serverless Test Driven Development

serverless tdd

Il paradigma serverless permette di dimenticarci della gestione dei server per poterci concentrare sulla realizzazione di funzionalità. Insieme a Filippo Liverani all'Italian Agile Day abbiamo visto come creare funzioni Lambda mantenendo alta la qualità del codice, con l'utilizzo del test driven development e ambienti locali di sviluppo e di produzione quanto più simili possibili con Docker.

Durante il talk, Filippo ha mostrato in un'applicazione di test come scrivere il primo test di accettazione in locale, un microciclo red, green, refactor e il deploy su Amazon Web Services con il framework Serverless, per poi eseguire con successo il test di accettazione direttamente sull'endpoint creato su AWS.

Repository del progetto: https://github.com/xpeppers/serverless-tdd

Slides della presentazione

Contattaci per maggiori informazioni su come adottare Serverless in azienda e se l'argomento test driven development ti interessa non perdere la prossima edizione del corso TDD explained.

dicembre 5, 2016 - No Comments!

Ruby Day 2016 – La nostra esperienza a Firenze

by Alessio Coser, Christian Fei, Matteo Pierro

Sabato, 26 Novembre 2016, abbiamo partecipato al Ruby Day 2016 a Firenze (programma).

Presentazione del Ruby Day 2016

Presentazione del Ruby Day 2016

La conferenza è iniziata con l'intervento di Xavier Noria che ha proposto alcuni concetti di codice leggibile, corretto e conciso.

Abbiamo visto alcune porzioni di codice scritte in modi diversi: alcuni più concisi, altri più leggibili e ci ha fatto notare che la scelta di come scrivere il codice è molto soggettiva, ma che dovrebbe comunque essere condivisa interamente dal team in cui ci si trova.

Successivamente abbiamo deciso di seguire una presentazione improntata su Integration testing, di Piotr Szotkowski. Il ragionamento di Piotr è partito dalle problematiche emerse in questi anni su integration testing ed ha preso come esempio l'articolo di J.B. Rainsberger intitolato "Integrated Tests Are A Scam!".
E' partito con un'introduzione sui test doubles, come e quando vengono usati, ma soprattutto quali sono le loro limitazioni. Ci ha spiegato come Bogus (un tool per il testing) affronta questi problemi in modo diverso e ci aiuta nel tdd-outside-in.

Prima di pranzo Devon Estes ci spiega come applicare concetti funzionali ad applicazioni Ruby. Ci ha invitato a ripensare il modo in cui scriviamo il codice sfruttando concetti del paradigma funzionale mostrandoci alcuni esempi di come sia possibile scrivere codice testabile e mantenibile.

Ruby Refinements - Paolo Perrotta

Refinements the worst feature you ever loved - Paolo Perrotta - Ruby Day 2016

Nel pomeriggio Paolo Perrotta ci ha raccontato di una fantastica feature poco conosciuta utilizzata di Ruby chiamata "Refinements". Ci ha parlato di come questa feature sia un'arma a doppio taglio e del motivo per il quale è stata introdotta: cercare un'alternativa sostenibile al monkey patching.

In seguito Simone Carletti ci racconta come la sua curiosità verso altri linguaggi di programmazione (Elixir, GO, Crystal e Java in particolare) lo abbiano portato ad evolvere il modo con cui scrive codice in Ruby.

Il talk successivo, proposto da Benjamin Roth, era incentrato sul tema dei ServiceObject e su come comporli per creare quello che lui chiama realistic context. Ha sottolineato come un approccio del genere porti ad avere dei Controller più light e con meno codice ripetuto. A supporto della presentazione ha introdotto una serie di gemme che "facilitano" -l'applicazione di questa pratica. Tra queste quella che ci ha colpito di più è stata Waterfall.

Nel tardo pomeriggio abbiamo partecipato al talk Lessons learned while building Hanami di Luca Guidi.
Ha parlato di tutti gli aspetti che si celano dietro lo sviluppo e il mantenimento di un progetto Open Source, di come la comunicazione e la collaborazione siano aspetti molto importanti nella buona riuscita di progetti di questo tipo.

Secondo la sua esperienza la scrittura di codice arriva alla fine di tutte quelle azioni che permettono la crescita della comunità intorno al progetto come la comunicazione che deve essere “inclusiva“ e propositiva in modo da aiutare, chi lo desidera, a collaborare al progetto.

Inoltre ha toccato un aspetto molto importante: la gestione del tempo. Consiglia di dedicasi al progetto ogni giorno anche per poche ore. Però non proprio ogni giorno, infatti si dovrebbe riuscire a ritagliarsi del tempo (come il week-end) per la propria vita privata e non permettere che questa attività, anche se è appassionante, assorba tutto il tempo libero.

Can we still innovate? - Piotr Solnica - Ruby Day 2016

Can we still innovate? - Piotr Solnica - Ruby Day 2016

Piotr Solnica ha concluso la giornata parlando della sua esperienza nello sviluppo di progetti OpenSource e di come la comunità cerca di migliorare l'ecosistema Ruby.

E' stata veramente una bella esperienza che ci ha permesso di confrontarci con la comunità Ruby e di passare una giornata divertente e stimolante.

ottobre 25, 2016 - No Comments!

Reasons to adopt a microservices architecture

by Paolo D'incau

microservices

Microservices based architecture is a trending topic in these days: more and more companies try to take a big step and shape their software and internal organisation following the examples of well-established realities such as Spotify, Netflix and Zalando. Even though it's always positive to keep an eye on new technologies, languages and frameworks available in the market, it wouldn't be wise to blindly embrace them. In this article we will discuss with concrete examples three different reasons that should trigger your interest in knowing more about microservices.

1) Faster Deployment

One of the things that I have noticed in the past years of work on monolithic architectures is that most of the times the process of deploying working features in productions becomes difficult and time consuming. Let me try to expand this point and explain why I believe that a microservices approach can ease these kinds of organizational issues.

When the products you are working on becomes somehow stable and is actively used by customers, the daily work of your team splits in three different activities, that are:

  • new features implementation
  • bug fixing
  • changes of the existing features (small ones, most of the time)

If your code is organized in a monolithic structure chances are very high that your Continuous Integration/Delivery/Deployment pipeline will reflect the same structure which means that it has a unique flow and therefore each and every change to the codebase will need to pass through tests or build steps that are totally unrelated to the change itself; this obviously means that you need more time to deploy your new code in production with all the costs that this implies.

When you need to push to production an urgent fix, but your continuous delivery pipeline remains blocked by non related broken user acceptance tests for hours (they can even be tests on features that are seldom used) your team can undergo frustration and and irritability. I have noticed the same frustation to arise when someone (probably the PO) asks to deploy a given feature to production without deploying other features that are still not ready and the team just can't satisfy the request because the deploy follows the motto "get everything or nothing".

Microservices obviously can help in tackling these kind of issues. If you separate your big project in smaller services built around features you can obviously decouple the related code, with the great benefit that your deployment strategy will follow. This means that you can decide to create a different pipeline for each microservice and therefore you will be able to deploy each component indipendently decreasing drastically the time your bug/feature/change takes to be released and used in production.

2) Easier onboarding

So you develop and improve your software for quite a lot of time (can be years), but things change and some of your developers (I hope not all of them) decide to leave and seek their fortune away from your company. Your product is widely used in production and obviously it needs support and new features, so you decide to hire new developers.

For newcomers it can be really difficult to approach a monolithic codebase and to become productive in a few weeks. It is very reasonable if you reflect on it: your new developers have to understand not only the new business features that need to be added, but also the overall business domain and the way it was coded down by other people who left the project! A monolithic architecture is the main reason that made me hear during the last years things like: "To be productive on this codebase you need N months" or "A couple of years ago we decided that...", I bet you heard something like this during your career too!

If you hired new developers and you want them to be productive as soon as possible, you may consider switching to a microservices architecture. I strongly believe that with such approach new team members can develop all the new features you need in a faster way without the burden of a limited knowledge of what lies in the monolith. Also, I recommend that newcomers should practice work on these new features while pair programming with somebody with more experience on the project so that they can be thought about the business domain, monolith architecture and, why not, team/project history.

3) Smarter scaling

Scalability seems to be a big concern nowadays and it's very common to hear business people ask the dev team whether the system under development "will scale". With the advent of cloud and virtualization everything seems very easy: you just need to deploy your application to several machines and put some sort of load balancer in front of them (e.g. country based) and voilà: you get the scalability you desired almost for free.

While it's pretty obvious that today we have a lot of platforms and tool that comes to our help, it is worth to remember that the way we design and organize our architecture still plays a big role.

Suppose your application just became mainstream and day by day is used by more users: with a monolith, if you want to scale, you are forced to deploy everything to several "replica machines", without taking into consideration whether you need to scale all the features the application provides or just a small subset of them. This kind of approach introduces different business related issues in your organisation, not only technical ones: for example you will have to use several new machines that must provide the computational power needed by the entire application and obviously this will cost you more.

When talking about scalability, microservices seems to outperform many other architectural choices out there. Whenever you feel the urge to scale some part of the system (and I hope you are forced by real metrics and not by your gut) you can decide to spin new small machines that will host only the service that provides the needed feature and nothing more; so if you are running an online shop you will be able to scale only the part connected to searches, while keeping the parts that implement shipment tracking or products recommendation as they are.

With a microservices approach you will get another great benefit: you will be able to kill some of the instances with no mercy because you are confident that just by stopping one or more microservices you are not shutting down the entire system but only a part of it.

Conclusions

In this article we have looked at three good reasons that should address you towards a microservices based architecture when redesigning your legacy monolithic application or starting it from scratch. With microservices you can boost your team productivity, reduce your time to market and scale those parts of the systems that really need it.

It is worth noting that microservices are not the only way to achieve those results, so before embracing them you should evaluate different solutions and also consider the issues that this kind of architecture can bring into your organisation. Finally you should alway keep these words by Sam Newman in mind:

About me

I have a double identity: I code OOP by day and spread FP by night (and during the weekends). I love talking about Erlang, Continuous Delivery, refactoring and microservices. I fight for to the coding “made in Italy".
I've started collecting useful resources about microservices here.

ottobre 12, 2016 - No Comments!

ReactJS Day 2016 Verona

by Christian Fei

Venerdì, 7 ottobre 2016, ho partecipato alla seconda edizione dell'evento "ReactJS Day 2016" a Verona.

La conferenza è iniziata con la presentazione dell'associazione GrUSP e di Frontenders Verona (FEVR).
Dopodiché in lineup c'erano due presentazioni sui temi "Individual paint for your React components" e "CSS is dead, long live CSS (but in modules, please)!", quindi entrambi riguardanti lo stilyng di componenti React.
Johannes Stein (@frostney) ci ha condiviso la sua esperienza con le varie tecniche per stilizzare componenti con React, dai famigerati inline-styles, da Aphrodite, da react-with-styles a una marea di webpack-modules. Adesso bisogna solo scegliere..

Dopo una breve pausa, Emanuele Rampichini (@emanuele_r) ha parlato dei vari tipi di testing di applicazioni di React. Partendo da una filosofia "PnP (Push-and-Pray)", come si crea un' applicazione che è in linea con il titolo della sua presentazione "How to push a ReactJS application in production and sleep better"? Non nuoce avere conoscenza della libreria react-test-utils e react-shallow-testutils per testare componenti React unitariamente o integrazione. Per una soluzione all-in-one di Airbnb, consiglia(mo) enzyme.

Con Massimiliano Mantione sul palco non c'era altro che aspettarsi una sbalorditiva demo con live-coding.
Ci ha lasciato tutti a bocca aperta con la dimostrazione di un suo esperimento dell'uso di React per lo shallow rendering della view, Redux per la gestione dello stato dell'applicazioni e tre varianti di "view" a la "TodoMVC":

  • una parte renderizzata con componenti HTML
  • un canvas 2D
  • un canvas 3D renderizzato con WebGL


*Modificando la todolist in una view, cambiava in tutte e tre 😎*

Francesco Strazzullo ci ha raccontato dello sua esperienza con la libreria MobX per lo state management in applicazione web JavaScript.

Nella presentazione "Building Modular Redux Applications" Gian Marco Toso presenta l'attuale stato dell'arte per l'organizzazione di progetti e del codice di applicazione modulari scritte con Redux.js.

Scrivere applicazione con una codebase "ridotta" (in termini di logica di business, linee di codice, complessità etc.) è veramente un gioco da ragazzi, ammettiamolo. Ma cosa succede in una codebase di grande scala? Il codice si riduce a codice illegibile e inutilmente complesso (aka "Spaghetti Code"), o è comprensibile e mantenibile?
Erik Wendel parla della sua esperienza ormai di quasi 5 anni in Bekk Consulting, insomma in una organizzazione a larga scala, in cui sono state adottate le librerie React e Redux. Wow!

Hoti Fatos ci introduce nel mondo GraphQL, e con una dimostrazione live ci spiega concetti del nuovo Query Language "GraphQL" (di Facebook).

La fantastica giornata al ReactJS Day 2016 finisce con la presentazione del carismatico Michele Bertoli su "Proper Error Handling with React/Redux".

seguita dall'invito al Node.JS Conf, il 22 Ottobre a Desenzano. Ci vediamo lì!

agosto 17, 2016 - No Comments!

AngularJS per lo sviluppo di applicazioni web

Un nuovo corso si aggiunge al catalogo. AngularJS per lo sviluppo di applicazioni web ti permetterà di approfondire la conoscenza del framework di Google e alla fine del corso sarai in grado di realizzare un’applicazione AngularJS in maniera autonoma.

corso per sviluppare con AngularJS

Il corso base ha una durata di 2 giornate, gli argomenti potranno essere modificati per rispondere meglio alle tue esigenze:

  • Javascript, jQuery vs AngularJS, qual’è il cambio di paradigma?
  • MVC (Model View Controller;
  • Iniezione delle dipendenze (Dependency Injection);
  • Le promesse (Promises);
  • L’architettura di AngularJS;
  • Come strutturare l’ambiente di sviluppo: npm, bower, grunt, gulp;
  • Moduli e controller;
  • Espressioni e filtri;
  • Scope e rootScope;
  • Cos’è e come funziona il binding bidirezionale (two way)?
  • Form e modelli;
  • Il routing di una applicazione con e senza uiRouter;
  • Direttive e servizi
  • Quali sono e come utilizzare direttive e servizi messi a disposizione dal framework;
  • Come sviluppare direttive e servizi personalizzati;
  • Intercettori di richiesta, cosa sono e come usarli;
  • Esercizio finale

Il corso può essere erogato presso la vostra azienda o possiamo ospitarvi presso le nostre sedi di Milano, Roma e Trento. Al momento non ci sono edizioni pubbliche in programma, puoi proporre una data o contattarci per un preventivo.

luglio 22, 2016 - No Comments!

AWS lambda zombie workshop

Stiamo reclutando nuovi sviluppatori per la AWS Lambda Signal Corps

zombie workshop

In uno scenario in cui gli zombie hanno preso il sopravvento nelle aree metropolitane, la AWS Lambda Signal Corps ha costruito un sistema di comunicazione per tenere in contatto i sopravvissuti.

Partecipa al AWS Lambda Signal Corps!

Un workshop, già collaudato in altre città degli Stati Uniti, in cui i partecipanti hanno lavorato in gruppi per costruire un'applicazione di messaggistica serverless per i sopravvissuti ad una apocalissi zombie, utilizzando Amazon S3, Amazon DynamoDB, Amazon gateway API, e AWS Lambda. I partecipanti hanno imparato a conoscere modelli di microservizi e le best practice per le architetture serverless. Hanno poi esteso la funzionalità dell'applicazione chat serverless con varie funzionalità e add-on - come l'integrazione per l’invio di SMS, e il rilevamento del movimento di zombie - utilizzando i servizi aggiuntivi come Amazon SNS e Amazon elasticsearch.

Dal diffuso interesse dei nostri clienti per le architetture serverless e AWS Lambda, e il nostro entusiasmo per questo argomento, siamo felici di annunciare che ospiteremo questo workshop gratuito il 22 Settembre a Milano.

Aiutaci a salvare l'umanità! Registrati qui

Cosa sono le architetture serverless?
Le architetture serverless consentono di creare ed eseguire applicazioni e servizi senza dover gestire infrastrutture. L'applicazione viene eseguita ancora sul server, ma tutta la gestione del server è fatto per voi dal provider cloud. Le architetture serverless possono rendere più facile costruire, gestire e scalare le applicazioni sul cloud, eliminando gran parte delle problematiche derivanti dalla gestione dei server.

Cosa è AWS Lambda?
AWS Lambda permette di far girare il tuo codice senza il provisioning o la gestione di server. Paghi solo per il tempo di elaborazione che consumi, non ci sono quindi costi quando il codice non sta girando. Questo rende più facile che mai costruire applicazioni scalabili con managed services potenti, in modo da poter concentrarsi sul proprio core business - come sopravvivere - mentre AWS si occupa della gestione delle infrastrutture.

giugno 30, 2016 - No Comments!

Quando usare React Native? Una nostra analisi

react native

React Native è un framework per lo sviluppo di applicazioni su piattaforme native che permette di unificare l'esperienza di sviluppo su diversi sistemi operativi.

React Native è un progetto basato su ReactJS, che adotta un nuovo approccio allo sviluppo Web.

Attualmente è disponibile per lo sviluppo di applicazioni iOS e Android, ma a breve dovrebbe essere rilasciata la compatibilità con la piattaforma Windows.

Le peculiarità

I Componenti

ReactJS si basa sul concetto di componente. Il Componente è qualcosa che ha uno stato, che può accettare delle proprietà e che ha un suo ciclo di vita.

Questo approccio di sviluppo "atomico" risulta perfetto per effettuare Unit Test o per creare componenti più complessi includendone altri più semplici.

Approccio funzionale e Virtual-DOM di React

I React Components possono essere visti come funzioni pure e idempotenti, infatti l'interfaccia di un componente viene espressa chiamando il suo metodo render() che può accedere allo stato corrente ed alle proprietà.

Il flusso di aggiornamento di ogni componente avviene in questo modo:

  1. La gestione del Virtual DomSi esegue il metodo render() che riceve dei dati in input e restituisce un albero di contenuti da visualizzare (Virtual-DOM).
  2. Il metodo render() viene eseguito ad ogni modifica dei dati e genera un nuovo Virtual-DOM.
  3. React calcola le differenze tra il Virtual-DOM corrente e quello relativo allo stato precedente del componente ed applica le minime operazioni necessarie per avere il DOM reale aggiornato.

Questo approccio ha le caratteristiche della programmazione funzionale, infatti può essere visto come una funzione che prende in input 2 DOM e restituisce una lista di operazioni da eseguire sul DOM Reale per applicare in modo corretto i cambiamenti necessari.

Nessuna WebView

La WebView è uno strumento basato sul motore Webkit che permette di renderizzare correttamente pagine web formate da Javascript, Html e Css.

Molti framework ne fanno uso perchè permette di unificare lo sviluppo di una app che può quindi essere pubblicata sia su Apple Store che su Play Store, senza grandi modifiche.

L'aspetto negativo di questo strumento è che ha bisogno di molte risorse, quindi le applicazioni risultano meno performanti rispetto a quelle sviluppate con una UI nativa.

A differenza delle classiche WebApp, React Native mappa ogni suo componente attraverso l'interfaccia utente nativa della piattaforma iOS o Android.

L'approccio iniziale

Per un primo approccio a React Native può essere di aiuto avvalersi di un progetto ben configurato con un'impostazione modulare e Test Friendly per lo sviluppo.

PepporoniUn progetto interessante è Pepperoni: un modello open source che include una serie ditool già pronti all'uso.
Fornisce uno scaffolding sempre aggiornato di React Native, una struttura modulare ed è predisposto per effettuare Unit Testing con Mocha e Enzyme.

Mocha è uno strumento per il testing unitario di Javascript solitamente associato ad una potente libreria Chai.js, Enzyme invece è un tool che semplifica il testing dei componenti ReactJS.

Pepperoni, inoltre, integra delle librerie come Redux e ImmutableJS per la gestione dello stato dell'applicazione.

Supporta anche il caching dello stato applicativo che permette il funzionamento offline e l'apertura più rapida dell'applicazione.

Oltre ad un sistema di autenticazione (OAuth), ha molti altri strumenti che semplificano notevolmente la configurazione iniziale del progetto.

Pro

  • Di facile utilizzo
    Una volta capito l'approccio di React Native diventa molto semplice sviluppare nuovi componenti.
  • Più performante grazie all'interfaccia nativa
    React Native guadagna molto in termini di performance rispetto alle comuni WebApp, perché fa uso di un'interfaccia nativa e non delega alla WebView il rendering della UI.
  • Un ciclo di sviluppo molto rapido
    React native è a tutti gli effetti una applicazione nativa che interpreta la business logic scritta in javascript, questo permette di velocizzare notevolmente il ciclo di sviluppo: ad ogni modifica del codice non è necessario ricompilare l'intera applicazione.
  • Virtual Dom
    Questo approccio permette di calcolare il minor numero di operazioni da effettuare per apportare le modifiche al DOM guadagnando velocità nel rendering della UI.
  • Semplifica lo sviluppo di test unitari
    Grazie alla sua struttura a componenti atomici risulta più semplice e più rapido lo sviluppo di test unitari.

Contro

  •  E' comunque un'astrazione
    Nonostante la UI sia nativa, la business logic viene comunque interpretata, quindi risulta meno performante delle applicazioni native.
  • Permette minor controllo rispetto alle applicazioni native
    Nelle applicazioni native si ha un maggior controllo soprattutto sulla gestione delle performance.
  • Attualmente non supporta la piattaforma Windows
    A breve dovrebbe essere disponibile il supporto per Universal Windows Platform.

Alternative

  • Ionic
    ionicUn framework javascript molto comune che si basa su Cordova e AngularJS per la creazione di applicazioni mobile. A differenza di React Native, si avvale di una WebView che rende l'applicazione meno performante. Con Ionic, però, è possibile sviluppare una sola applicazione ed effettuare il deploy sia su Android che iOS (Develop once, deploy anywhere).
  • Xamarin
    xamarinUn framework C# per lo sviluppo di applicazioni native. Xamarin permette di scrivere una sola volta la logica di business modificando solo la UI in base al sistema operativo. E' già presente il supporto per Windows e, utilizzando XamarinForms, è possibile scrivere una singola UI per Android, iOS e Windows. Rispetto a React Native è uno strumento certamente più complesso ed è pensato per un team di sviluppatori già orientato allo sviluppo mobile.
  • nativescriptNative Script 2.0
    E' un framework TypeScript e AngularJS. Native Script permette di sviluppare applicazioni native senza utilizzare la WebView.

Conclusioni

React Native è sicuramente un ottimo framework che permette di sviluppare applicazioni con buone prestazioni ed una interfaccia paragonabile a quella delle app native. Questo strumento, però, ha indubbiamente alcuni svantaggi che si rispecchiano sia nelle prestazioni (anche se migliori di altri framework JS) sia nella possibilità di controllare tutte le funzionalità che una applicazione nativa può offrire.

React Native può essere una soluzione ideale per un team più orientato allo sviluppo in javascript. Questo perché offre degli strumenti che facilitano e, in qualche modo, unificano la logica di business e il deploy sulle varie piattaforme mobile.

Per uno sviluppatore di applicazioni native, invece, React Native può non essere il framework più adatto perché ha un approccio differente e potrebbe non rispondere a tutte le esigenze di uno sviluppatore mobile esperto.

Per sviluppare un MVP in poco tempo e con buone prestazioni rimane un'ottima soluzione, soprattutto se a sceglierlo è un team di sviluppatori Javascript.

febbraio 25, 2016 - No Comments!

Coding Dojo a Trento: Refactoring codice Java

Il 27 gennaio abbiamo organizzato presso la sede trentina di XPeppers un coding dojo che ha riscosso un'ottima partecipazione di sviluppatori e sviluppatrici provenienti da tutta la regione Trentino-Alto Adige/Südtirol.

L'argomento della serata è stato il refactoring di codice legacy in Java, e i partecipanti si sono confrontati sulla risoluzione del Gilded Rose kata. Lo scopo del kata in questione è quello di andare ad aggiungere delle funzionalità ad una codebase esistente, scritta in modo ben lontano dall'ottimale e priva di test che ne provino il funzionamento corretto.

Come si è svolto il nostro Coding Dojo

Dopo una piccola introduzione al problema le persone presenti all'evento hanno avuto occasione di alternarsi in pair programming alla tastiera (prima come navigatore e poi come driver) e di mettere mano alla codebase con il supporto di tutte le persone partecipanti. Inizialmente si è cercato di comprendere meglio la codebase andando ad aggiungere un minimo set di test che dimostrassero la validità delle funzionalità già presenti.

Coding Dojo: Tutti assieme attorno alla tastiera

Tutti assieme attorno alla tastiera

Dopo questa prima fase abbiamo deciso di introdurre le nuove funzionalità richieste e qui ci sono venuti in soccorso i test scritti precedentemente perchè eseguendoli spesso ci hanno dato la sicurezza di non introdurre regressioni.

Tra un test in barra verde e una mossa di refactoring su Eclipse, i partepanti hanno potuto consumare degli stuzzichini delle bibite gentilmente messe a disposizione da XPeppers.

Pur non essendo riusciti a concludere l'esercizio, nelle 3 ore di coding dojo abbiamo avuto occasione di metterci a confronto con persone aventi background, skills ed esperienze diverse. E' stata sicuramente un'esperienza positiva e ne è riprova l'ottimo feedback emerso nel corso della retrospettiva tenutasi a fine incontro dove abbiamo analizzato con il classico "glad/sad/mad" la serata e i risultati ottenuti.

Coding Dojo: Retrospective time

Retrospective time

A fine sessione ci siamo lasciati con l'auspicio di organizzare questo tipo di eventi in modo più ripetitivo in modo da esplorare assieme argomenti di diverso tipo e creare un gruppo di appassionati di sviluppo software.

 

febbraio 15, 2016 - No Comments!

FOSDEM 2016 a Bruxelles

by Christian FeiTiago Martinho

Anche quest'anno XPeppers ha partecipato alla conferenza FOSDEM il 30 e 31 gennaio a Bruxelles!

FOSDEM è una conferenza gratuita dedicata a sviluppatori ed ormai è diventata il punto d'incontro in Europa che ogni anno ospita più di 7000 persone, presso l’università ULB di Bruxelles.

Da tutto il mondo sviluppatori appassionati di open-source vengono per discutere e condividere le loro esperienze.

Ci sono innumerevoli stanze dedicate a linguaggi di programmazione, tecnologie e pratiche come virtualizzazione, testing e automazione, fino al mondo open-source in generale.

Abbiamo seguito talk soprattutto legati ai temi Testing and Automation, Virtualisation, Configuration Management, Containers and Process Isolation e IoT.

Nel talk Jenkins as Code abbiamo conosciuto il plugin per Jenkins Job DSL, che rende programmabile la creazione di job Jenkins. Il presentatore ha mostrato come l'infrastruttura di Uber ha sfruttato questo strumento per scalare e automatizzare molti processi che prima richiedevano un intervento manuale.

Per rimanere nel contesto testing e automazione, abbiamo seguito la presentazione "Beyond config management", in cui l'autore ci ha esposto le sue considerazioni su DSL (scritti in Groovy) per modellare e definire l'infrastruttura in modo programmatico. Potendo compilare questo codice, abbiamo la possibilità di avere un'analisi statica sul codice dell'infrastruttura, oltre alla sua testabilità.

Secondo l'autore, e anche secondo noi, l'approccio di modellare l'infrastruttura tramite codice, cioè "Infrastructure as code", è una pratica essenziale per creare architetture affidabili e resilienti.

Nel talk PostgreSQL features for IoT da Simon Riggs abbiamo visto le nuove funzionalità di PostgreSQL dove la vision è avere un database che permette la creazione di applicazione dove l'ambulanza arriva prima del incidente perché la misurazione del battito cardiaco ha rilevato che la persone sta per avere un infarto. Questo database può registrare una grande quantità di dati in poco tempo in continuo, l'esempio fatto è quello di registrare le misurazione di glucose ogni minuto di ogni cittadino del europa.

Nel talk Build an IoT platform on Matrix da Matthew Hodgson è stata presentata una introduzione al framework Matrix. Questo framework permette di create una piattaforme aperta e decentralizzata dove vari dispositivi IoT riescono a comunicare tra di loro in una forma semplice e affidabile.

Puoi trovare i video di tutti talk qui FOSDEM 2016


 

Ogni anno viene organizzata una serata dedicata al FOSDEM, al Delirium Café vicino al Grand Place, la piazza centrale di Bruxelles. Non potevamo perderci questo evento per conoscere nuove persone, per fare networking e per goderci delle ottime birre belghe (la scelta è molto vasta; parliamo di oltre 25 birre)!

Come potete vedere non abbiamo resistito agli sticker che venivano distribuiti ai vari stand:

FOSDEM stickers!