Coding Archivi -

Blog Archives

Latest Posts

Monthly

All Posts in Coding

Aprile 21, 2020 - Commenti disabilitati su Perché è importante uno sviluppo iterativo e incrementale anche in una libreria OpenSource?

Perché è importante uno sviluppo iterativo e incrementale anche in una libreria OpenSource?

Questa è la nostra esperienza sulla realizzazione di una libreria OpenSource, di come lo sviluppo iterativo, incrementale si applichi non solo a progetti "commerciali" ma anche allo sviluppo open source, in particolare a quello guidato dalle esigenze e dal feedback.

Questa è la storia di Daikon

a dead simple and minimal framework for creating web applications in Kotlin with minimal effort

Una libreria utiizzata in molti progetti del nostro team.

La Nascita

Tutto è nato dal team in cui lavoriamo: il Team Vega e dal nostro coinvolgimento su progetti riguardanti lo sviluppo di applicazioni web in Kotlin.

Siamo stati per molto tempo dei fan di SparkJava per la sua semplicità e il suo DSL molto intuitivo.

Un'applicazione scritta in Spark è anche abbastanza semplice da testare e da manutenere, ma ci trovavamo spesso nelle condizioni di non poter usare SparkJava anche per i test.

In particolare, come spesso accade, abbiamo a che fare con servizi esterni (autenticazione, API varie, etc...), quindi nei test E2E ci piace (ove non sono disponibili i servizi veri) usare delle implementazioni che simulano il comportamento reale. Per fare questo solitamente creiamo dei test che lanciano delle API HTTP programmabili con validazioni e risposte realistiche.

Con SparkJava non possiamo lanciare più di un server HTTP nella stessa applicazione, questo perché dietro le quinte lavora con oggetti statici.

Sappiamo però che esistono librerie per soddisfare questa necessità ad esempio WireMock, ma non ci siamo mai trovati troppo bene ed in più ci forzano a configurare API HTTP in due modi diversi:
1. la libreria per il codice di produzione
2. la libreria per il codice di test.

Questo è stato uno dei motivi che hanno dato il via allo sviluppo di Daikon: avere un unico modo per lanciare più applicazioni che usano HTTP nella stessa suite di test.

In più volevamo anche qualcosa che fosse:
- rapido a partire e a servire richieste, dato che ultimamente stiamo lavorando parecchio su container docker che per loro natura sono volatili e necessitano di startup veloci.
- senza magia, ovvero la possibilità di capire facilmente come utilizzare la libreria senza magie/convenzioni che obblighino gli utilizzatori a fare mille ricerche su StackOverflow. (es: SpringBoot)

L'Evoluzione

Cosa sta dietro al concetto di iterativo-incrementale in pratica?

L'idea parte dalla necessità di trovare un modo per validare il prima possibile quello che stiamo sviluppando e capire se questo porta valore.

Per andare in questa direzione dobbiamo avere sempre qualcosa di funzionante e pronto per essere utilizzato anche se con funzionalità ridotte, grezze e migliorabili.

Non solo, gli incrementi e le raffinazioni devono essere guidate dal feedback e motivate da reali esigenze, senza speculare su quello che potrà essere o potrà avvenire nel futuro.

Oramai è qualcosa che noi in Claranet Italia diamo per scontato nella realizzazione dei progetti, ma non sempre è un concetto che viene applicato da chi sviluppa, in modo particolare nel mondo OpenSource.

A volte perché si sviluppa pensando a utilizzatori immaginari (non reali), a volte perché ci si fa prendere da manie di grandezza con il risultato di complicare il codice provando a renderlo più estensibile/configurabile/astratto, salvo poi ritrovarsi tra le mani un codice più complesso e difficile da manutenere senza una reale necessità.

In Daikon tutto (o quasi) è stato guidato dal feedback e dalla necessità.

Le prime versioni erano molto scarne: si faceva partire un' applicazione web con pochi metodi HTTP supportati, solo GET, POST e poco altro.

Man mano che usavamo Daikon nei nostri progetti, ci rendevamo conto che mancavano delle funzionalità. Quindi cercavamo di utilizzare queste reali necessità come spinta alla crescita di Daikon invece che svilupparle all'interno dei singoli progetti.

Siccome non siamo soli nell'universo, anche i feedback di colleghi, clienti e collaboratori sono stati importantissimi per capire quali funzionalità aggiungere o affinare.

Nonostante avessimo testato l'applicazione con scrupolo e il suo design sia stato fatto in TDD, niente è esente da bug. Questi feedback, quindi, ci hanno aiutato molto a trovarne alcuni (pochi per fortuna), verificarli con dei test e correggerli.

Man mano che Daikon veniva usato ci sono stati segnalati alcuni miglioramenti che avrebbero potuto semplificare il suo utilizzo e così, basandoci su necessità, feedback e uso quotidiano, abbiamo fatto la sua roadmap, fino a renderlo una libreria stabile e usata in diversi progetti in produzione.

I Traguardi Raggiunti

Uno degli obiettivi che ci eravamo prefissati era di tenere la libreria il più snella possibile. Per questo motivo abbiamo sempre cercato di evitare l'aggiunta di dipendenze. Quando qualcosa si rendeva necessario (es: parsing delle richieste e risposte in JSON) creavamo delle estensioni per Daikon che a tutti gli effetti erano progetti separati.

In questo modo l'utilizzatore ha a disposizione il set minimo di funzionalità che gli servono ed eventualmente aggiunge le estensioni alla sue dipendenze per le altre funzionalità.

Per quanto riguarda le estensioni, ci è venuto in soccorso Kotlin che, grazie alle Extension Functions, ci ha permesso di trovare un modo elegante, leggero ed espressivo per estendere il core di Daikon.

Sono nate così diverse estensioni:
* Daikon Freemarker
* Daikon Gson
* Daikon Jackson XML
* Daikon Eureka
* Daikon Prometheus

Dopo qualche tempo abbiamo iniziato a gestire anche alcuni servizi Serverless, quindi abbiamo deciso di estrarre l'intero routing nel CORE di Daikon in modo che fosse flessibile ed utilizzabile sia come server HTTP (usando Jetty) sia in Lambda che semplifica la gestione di applicazioni serverless.

Quindi è nato un altro interessante progettino: Daikon Lambda che ha la stessa interfaccia e le stesse funzionalità di base di Daikon.

Abbiamo poi deciso di estendere il concetto di semplicità e minimalismo anche al client HTTP. Così è nato anche Topinambur.

Collaborazione ed entusiasmo

Una cosa che ci è piaciuta moltissimo è stato il fatto che il Team Vega non fosse solo in questa avventura. Ai nostri colleghi è piaciuto il progetto e si sono adoperati per darci una mano a realizzare qualcosa che mancava o a migliorare quanto avevamo fatto. Ad esempio Daikon Prometheus è nato dall'esperienza in quell'ambito di un nostro collega che ha visto l'opportunità di estendere la nostra libreria con quanto conosceva.

I clienti, inoltre, si sono dimostrati da subito entusiasti del progetto, sia perché avevano a disposizione qualcosa di funzionante e semplice integrato nei loro progetti, sia perché lo hanno potuto integrare in altri loro sistemi senza difficoltà e molto velocemente. Senza contare il fatto che lo sviluppo di Daikon non aveva intaccato (se non positivamente ) la delivery del progetto.

Feedback

Daikon è un progetto in continua crescita che si evolverà ulteriormente grazie ai feedback che riceveremo. Potete contribuire in vari modi:
* usatelo e diteci come vi trovate, cosa vorreste avere in più o cosa vorreste migliorare;
* diventate contributor del progetto;
* mettete un like a questo post e una stellina al progetto su GitHub.

PS: vi siete chiesti come mai le librerie hanno nomi di vegetali? Basta nomi di animali, finalmente una libreria vegetariana!

Settembre 21, 2017 - Commenti disabilitati su Refactoring e architettura emergente di un’applicazione Zeppelin

Refactoring e architettura emergente di un’applicazione Zeppelin

Condividiamo alcune esperienze sulla gestione di un progetto complesso in ambiente Apache Spark/Apache Zeppelin.

Uno dei progetti su cui il team di XPeppers ha lavorato negli ultimi mesi è stato lo sviluppo di un'applicazione di software quality dashboard per un grande gruppo bancario. Il compito dell'applicazione è fornire un pannello di controllo centralizzato attraverso cui monitorare la qualità del software rilasciato dai numerosi fornitori del gruppo. I dati da gestire sono generati da SonarQube, aggregati e rappresentati secondo logiche custom definite dal Cliente. I progetti da tenere sotto monitoring sono molti, e per ciascuno di essi si devono processare sia dati attuali che trend storici; serviva quindi una piattaforma di big data management. La scelta è stata di usare la coppia Apache Zeppelin / Apache Spark, sviluppando il codice necessario per le elaborazioni e visualizzazioni custom in Scala (per l'elaborazione dati) e AngularJS (per la UI), e usando SBT come strumento di build.

Il primo spike

La prima versione dell'applicazione è stata sviluppata in modo un po' quick & dirty: volevamo arrivare velocemente a mostrare un prototipo funzionante agli stakeholder e capire se la scelta dello stack tecnologico (e soprattutto di Zeppelin come front-end) fosse accettabile. La demo è piaciuta e ci siamo trovati con la "release 0" (ci siamo concessi un approccio "S pike and Stabilize").

Questa prima versione era costituita da una singola nota Zeppelin, suddivisa in una ventina di paragrafi, molti dei quali contenenti diverse decine di righe di codice Scala e SQL più o meno complicato. Soltanto due servizi erano forniti da classi Scala compilate separatamente: il dialogo HTTP con i Web Service di SonarQube, e la gestione di una base dati locale in formato Parquet.

noterel0

Primo refactoring

Era il momento di fare un po' di stabilize, e il problema principale della release 0 era evidente: troppo codice troppo complicato inserito nel corpo della nota Zeppelin, e quindi di gestione incredibilmente difficile (versioning quasi inutile, impossibilità di usare IDE o editor evoluti per modificarlo, ...)

Abbiamo quindi cominciato a migrare il codice dalla nota Zeppelin verso classi Scala, cogliendo l'occasione per aggiungere dove possibile test unitari (in Scalatest). Il codice ha cominciato ad assumere una forma vagamente object-oriented, anche se ancora un po' rudimentale.

La relazione fra la nota e le classi Scala importate da JARera un po' migliorata:

Nel frattempo il PO ha cominciato a chiedere modifiche alla nota originale, e un bel giorno le dashboard richieste sono diventate due, molto simili fra loro come layout, ma con diversi set di dati visualizzati (dati di leak period vs. dati storici per una data scelta in input). Questo è stato anche il momento in cui abbiamo agganciato per la prima volta una callback (scritta in Scala) alla GUI AngularJS della dashboard (usando il metodo angularWatch dello ZeppelinContext).

Il secondo punto di partenza

Il fatto di aver migrato una parte del codice dalla nota ai sorgenti Scala, ovviamente, si è rivelato provvidenziale nel passaggio da una a due note. Tuttavia, le due note attingevano a fonti di dati diverse (il database Parquet per la nota principale, i WS Sonar per la nuova dashboard "di leak period") e per farlo usavano metodi nati indipendentemente e collocati in classi diverse. Inoltre, entrambe le note contenevano ancora parecchio codice; andavano lente, ed erano instabili. La manutenzione e il refactoring erano sempre molto difficili. Sapevamo che le classi Scala avevano parecchi problemi (a partire da un forte difetto di SRP: avevamo 2 o 3 classi “demi-god” con decine di metodi di accesso ai dati), ma le possibilità di refactoring erano limitate dal fatto che mancavano ancora molti test unitari e prevedere/verificare le conseguenze delle modifiche sulle note era molto complesso.

Nel frattempo, erano entrate nuove richieste dal PO, tra cui una per una terza dashboard (sempre simile come layout ma diverse come logica di caricamento dati), e ogni tanto ci veniva chiesto di clonare una nota per una demo. Queste note “demo” diventavano tipicamente inutilizzabili dopo qualche settimana, perché legate a codice modificato in continuazione, e non soggette a manutenzione.

Con la terza nota avevamo una valida giustificazione per un nuovo refactoring. A questo punto era evidente che l'applicazione sarebbe stata soggetta a ulteriori evoluzioni per i mesi a venire, e che avevamo raggiunto la soglia di design payoff: per non rallentare dovevamo fermarci, e rivedere più profondamente il design.

Secondo refactoring

Nelle settimane successive non abbiamo rilasciato quasi nessuna major feature, e abbiamo lavorato sul debito tecnico, in modo mirato, fino a portare a casa due breakthrough principali:

abbiamo trovato un’implementazione molto più efficiente per le note, che ha reso possibile provare il funzionamento in poche decine di secondi (vs. tempi sopra la decina di minuti) e cominciare a parlare di una ten-minute build comprensiva di integration test;
abbiamo definito un’interfaccia comune (in effetti una classe astratta) da cui far dipendere, in modo uniforme, tutte le note, migrando faticosamente la vecchia pletora di metodi simili-ma-diversi sotto il cappello della nuova interfaccia. L’abbiamo chiamata Report (nel senso di un report Sonar).

A questo punto la differenza principale fra le diverse note consisteva nella classe concreta che veniva istanziata per popolare la nota. La “Leak Period Dashboard” istanziava un LeakPeriodReport, la “Dashboard” principale (che mostra un report riferito a una data fornita in input) istanziava un TimeReport, la “Comparative Dashboard” (che mostra un report che è il delta fra due date, una generalizzazione del concetto di leak period) istanziava un DeltaReport (dandogli in pasto in costruzione altri due Report fra cui calcolare il delta). Una cosa così:

uml1

Le differenze fra le varie dashboard non erano proprio tutte solo nell’istanziazione del Report concreto: alcune note avevano bisogno di agganciare callback e altre no, c’erano delle variazioni nelle visualizzazioni di alcuni valori, e così via. Ma eravamo arrivati a note con 3-4 paragrafi ciascuna:

inizializzazione delle dipendenze (con l'interpretespark.dep)
setup di eventuali dati specifici (per esempio, le date fra cui scegliere nelle note "temporali")
istanziazione di un (certo tipo) diReport
popolamento della dashboard a partire dal report (una serie di binding delle variabili Angular a partire dai dati forniti dalReport)
eventuale aggancio di callback

Terzo refactoring

A questo punto è arrivata una richiesta del PO di tipo nuovo:

"Belle. Ora fatemele uguali anche per questi altri 4 gruppi di progetti."

Si trattava di passare da 3 dashboard (simili fra loro)... a 15!

Se non avessimo già estratto il codice dalle note nelle classi compilate, sarebbe stato un bagno di sangue (sia creare le nuove note che, soprattutto, manutenerle). In realtà le note erano già molto piccole e facilmente clonabili senza incorrere in un effort di manutenzione enorme. C’era comunque ancora un po’ di codice, e come detto sopra, alcune piccole differenze di logica (aggancio di callback, setup specifici, ecc.).

A questo punto abbiamo fatto un ultimo passo di refactoring/DRY: abbiamo spostato TUTTO il codice dalle note nelle classi Scala compilate separatamente, inclusi i binding di variabili Angular e gli altri statement che facevano uso delloZeppelinContext(per inciso, questo ha richiesto l'aggiunta di una nuova dipendenza nel nostrobuild.sbt: "org.apache.zeppelin" %% "zeppelin-spark" % "0.6.1").

Finalmente tutto il codice era gestibile via IDE e alla portata dei test unitari, e non abbiamo avuto difficoltà a fare al volo un ulteriore passo di riorganizzazione, portando a fattor comune in una classe astratta tutto il codice invariante fra le diverse note (p.es. il popolamento delle variabili Angular a partire dai valori tornati dal Report), e isolando le differenze in tre sottoclassi concrete: BasicDashboardNote, LeakPeriodDashboardNote, e ComparativeDashboardNote:

uml2

Su Zeppelin abbiamo lasciato solo il minimo indispensabile, ovvero due righe essenzialmente uguali in ogni nota:

val projects = z.input("Elenco dei progetti sotto analisi") new BasicDashboardNote(z, projects)

Nota: i diagrammi sono fatti con i tool di yUML.

Maggio 16, 2017 - Commenti disabilitati su Il continuous improvement inizia dalle persone

Il continuous improvement inizia dalle persone

In questo blog post vogliamo mettere in evidenza uno dei valori più importanti all’interno di XPeppers: il miglioramento continuo. Un valore che si può percepire già dai primi giorni di esperienza lavorativa, momento in cui i nuovi arrivati iniziano a seguire un percorso di studio mirato all’approfondimento dei principi e dei valori condivisi dal team, tra cui tematiche legate ai metodi agili e ad extreme programming.

Kata in progress!

In questo percorso c’è la figura di un tutor aziendale, una persona del team che affianca e segue il nuovo arrivato durante un primo periodo, fornendo feedback e consigli su come affrontare nel modo migliore i temi trattati. Oltre a questa figura di riferimento, si può sempre contare su un ulteriore supporto dal resto del team.

Il nostro percorso di studio è organizzato in aree tematiche che coprono i concetti più importanti delle metodologie agili e tutte quelle buone pratiche per scrivere codice migliore. Studiamo dai libri, dai blog e da altre risorse che riteniamo valide, alternando la teoria alla pratica. Affiancandoci a qualche altra persona del team svolgiamo e ripetiamo esercizi di programmazione, detti Kata, per rendere il più naturale possibile l’apprendimento dei temi studiati e la loro applicazione su progetti reali.

Una volta completato questo percorso, in XPeppers continua ad essere presente come pratica quotidiana il cosiddetto “pomodoro di studio”, momento in cui ogni giorno ciascuno di noi dedica del tempo all’approfondimento di argomenti che crediamo importanti per la nostra crescita professionale. Quando lo riteniamo opportuno organizziamo anche presentazioni interne per cercare feedback e condividere tematiche rilevanti col resto del team.

Per nostra natura ci piace raccogliere feedback e cercare di migliorarci continuamente, e questo si riflette anche sul nostro percorso di studio che continua a cambiare nel tempo per rimanere al passo con le tematiche emergenti.

Se anche tu come noi credi al miglioramento continuo, sei curioso e pensi che il nostro metodo e percorso di studio possano farti crescere allora continua a seguirci o mandaci la tua candidatura!

Gennaio 5, 2017 - Commenti disabilitati su Serverless Test Driven Development

Serverless Test Driven Development

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 - Commenti disabilitati su Ruby Day 2016 – La nostra esperienza a Firenze

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

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.

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

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 - Commenti disabilitati su Reasons to adopt a microservices architecture

Reasons to adopt a microservices architecture

by Paolo D'incau

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:

Microservices are not something you should aim for. They are a means to an end. Focus on what's important - building useful software.

— Sam Newman (@samnewman) 10 giugno 2015

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 - Commenti disabilitati su ReactJS Day 2016 Verona

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 - Commenti disabilitati su AngularJS per lo sviluppo di applicazioni web

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.

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 - Commenti disabilitati su AWS lambda zombie workshop

AWS lambda zombie workshop

Stiamo reclutando nuovi sviluppatori per la AWS Lambda Signal Corps

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.

Pagina successiva »