All Posts in Agile

settembre 21, 2017 - 1 comment.

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 "Spike 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:

notes2.png

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.

settembre 15, 2017 - No Comments!

WeDoTDD: That’s How

We recently did an interview on wedotdd.com on how we practice TDD. We decided to share our answers also in our blog, keep on reading if you want to know more!

 

Pairing in Peppers

 

History, what you do now, anything that summarises you or makes you interesting

An agile software developer at XPeppers has on average four years worth of experience in agile methodologies and has therefore grown a skillset that ranges from Clean Code and Refactoring to Test-Driven Development. Our software developers spend most of their work hours crafting customer ideas into great software.

All team members at XPeppers focus on their continuous improvement by investing time in studying new technologies and paradigms, doing katas and setting up coding dojos and presentations.

How did you learn TDD?

Each developer who joins our team has a study path to follow and has a mentor that helps them learn all the things we value most at XPeppers, among which you can obviously find TDD.

We know that TDD can be learnt only with practice and therefore we suggest katas and organise internal coding dojo during our study time to both improve our skills and share ideas. We try to teach our developers TDD "on the field" by pairing up developers who are less experienced on TDD with our XP coaches.

Our developers quickly get that TDD has a huge impact on the quality of the code they craft and easily become engaged with it. With time they understand that tests are not only a good way to avoid regressions but also a great tool to improve code design.

Tell us more about how your team pairs

At XPeppers we try to work on uniformed pairing stations that run similar software. In addition to this, we’ve noticed that large desks with big monitors encourage a more natural role and keyboard switch.

During our pair sessions we do talk a lot (hence we’re italian :P) and collaborate in order to make better design decisions and write better code in general.

Another practice we sometimes do is to pair (on site and remote) with a member of customer's team to enhance domain knowledge and share development best practices.

More Details About the Team Itself

At XPeppers every team is shaped according to customer needs and follows a project from the beginning until its delivery. Its members however, might be adjusted based on iterations and workload whereas the team ideally is cross-functional by nature. In this way we are able to enhance our focus on a specific product and share experiences throughout the team on a project based manner.

Every month we update our projects portfolio board to both assure everyone is allocated and to have a more long term view of ongoing projects.

What role does QA play on the team? How do they interact and work with the developers, Project Managers, etc.?

In some of our projects we have a QA person that tests the user stories when they are available on a production-like environment. Usually they try to replicate the requirements written in the back of the user story.

In some other projects we write an automated user acceptance test and we have a set of UAT that proves that our software works as intended (or expected) by the customer.

What kinds of products does the team support / develop?

We have huge experience on financial applications: we built both Mobile Payment Apps for iOS and Android and backend payment gateways for some of the biggest players in Italy.

We are confident with API development (lately we are working extensively with Serverless Architectures).

The XPeppers team has many other successful case studies with different customers among with you can find famous newspapers, networking companies and public institutions.

Can you describe in detail the team methodologies & workflow when developing software

Every XPeppers team has its Product Owner which talks directly with the customer to collect the requirements and other information such as some priorities including scope, time and quality. In this way the PO can better understand the real customer needs.

Then the team takes part to a KickOff meeting in order to update all the team members on projects goals, the expected results, the timing and the process.

The whole team defines the priority for each story to minimize the time spent to have a working software that can be tried and approved by the customer.

A story complexity is estimated in points based on the team experience or on a spike made before. The points are assigned following the Fibonacci scale starting from the simplest story.

We use a physical Kanban-board every time is possible. If a team is distributed we have a virtual board, even if we often reply it in a physical format for visualisation convenience.

We schedule meetings with the customer every 1 or 2 weeks to do a demo of the software and plan which stories to include in the following iteration.

In XPeppers we adopt many XP practices like Pair Programming, TDD, Code Review. We rely on the type of customer/project to choose the practices that help us to enhance the quality of the project, the development process and the relation with the customer.

Can you describe a typical / common setup of a developer machine?

A typical developer machine at XPeppers is a MacBook Pro 13' or a Dell XPS 13'. We have an IDE to work with languages like Java or C# and an editor like vim, emacs or atom.

We follow the Agile Manifesto, so we value people more than tools: this is why we try to decide as a team which configuration is best suited for a given project.

Can you explain in detail the different types of tests the team writes and in what contexts or at which levels (boundaries) of code?

We use to write different kind of tests based on the project context. Basically, using TDD, we happen to leave a trail of tests behind us, which are going to be the core of our test suite. We tend to cover the code strategically: the most important or risky is the feature, the more tests we write for that part of code. We also write integration tests, to verify the behaviour of the system (or one of its part) as a whole. Those tests are all written by developers as part of their day-to-day work. We then also write Acceptance Tests, which we use to discuss and clarify features with customers. Those are the main type of tests we write.

Just to give a concrete example, those are some numbers taken for two big-sized projects:

  • 2,500 Unit tests, running in about 30-40 seconds
  • 200 Integration tests, running in about 19-20 minutes
  • 250 Acceptance tests, written as Cucumber scenario tests, running in about 12-18 minutes against a production-like deployed application
  • 2,308 Unit tests, running in about 10-15 seconds
  • 556 Integration tests, running in about 6 minutes
  • 502 Acceptance tests, running in about 17 minutes against a production-like deployed application

Depending on the project context, we may decide to write also other type of tests, mainly smoke tests and stress tests.

What is the team's style / approach to TDD?

As a consulting company, we don't have a team style or specific approach to TDD. We'd like to see TDD as an effective practice to build working software. We try to choose the approach that best fit particular situation, team or product.

When we are working with an external team, like customers who are approaching TDD for the first time, we like to keep a smooth and very strict rhythm so that people can appreciate, learn and better understand the practice. From the other hand, we tend to shift to a faster and less strict approach when we are working with more experienced people or when the confidence about the domain is high we tend to go faster.

Explain how you refactor your tests (blue step in TDD)

We try to make a refactor step after each test pass and try to enhance code in order to embrace business changes needs or reduce technical debt.

When our application is hard to change, we know we should refactor our code.

If we cannot do it immediately (e.g. due to a short deadline) we create a card with TD (Technical Debt) label and we do it as soon as possible.

Are there any refactoring patterns or techniques that you apply to the production code?

There are different patterns that we employ everyday in order to improve the design of our production code, avoid duplication and express in a better way the intent of each component. Each person in our team has a different set of patterns in their toolbox but we try to use those that answer the four rules of simple design; anyhow most of the patterns we employ are taken from two books we warmly recommend: Refactoring by Martin Fowler and Refactoring to Patterns by Joshua Kerievsky.

How has TDD helped the team design better code?

TDD helps our teams in many ways. It allows us to see a new feature from the customer point of view.

In addition we can write more meaningful code for the business needs, which leads to have the code cleaner and more understandable for the entire team.

It permits to have a quick feedback and to not over-engineer the application, because we write only the code that is really needed.

How has TDD benefited your customers and client's projects?

Our customers feel a better quality in the software we deliver, because there are few bugs and we can fix them quickly.

The customer asks for new features with more confidence and trusts us. The software turns out to be more flexible and easier to extend.

What are some challenges the team has faced with TDD?

There are many challenges that we try to face when we practice TDD in our team, and these challenges are not only related to technical aspects but also to different approaches that come from our different experiences.

In some situations we discuss a lot about the first test we should write when developing a new feature: shall we start with this case or another? In other cases we have to think carefully on our TDD approach; of course we love outside-in TDD but sometimes when we are confident we embrace inside-out as well.

Another challenge for an experienced member of the team is to pass down some values to younger people: first of all we teach that tests are code and therefore is important to give them all the respect they deserve and polish them using refactoring techniques, DSL etc etc. Moreover tests are made to be read by other people (not always technician) and we must try to make them as much expressive as we can.

Please provide more details on your CI environment or CI environments of the clients you support

The continuous integration environment heavily reflects the project itself. Its complexity and automation degree tell us what kind of environment to spin-up in order to be more effective and productive on a daily basis. We’ve used different tools in the past including Jenkins, GitlabCI, Travis, CodeShip, CircleCI, DroneCI for backend and frontend development. Bitrise and Buddybuild for mobile applications. At XPeppers, we prefer a streamlined continuous deployment or delivery approach to push artefacts towards production.

Please provide more details on your apprenticeship program, internships or on-boarding process

At XPeppers we provide either apprenticeship and internships programs. Both have a strong focus on learning the core principles, values and practices of our way of working.  Apprentices are given the chance to deepen their understanding of eXtreme Programming, Clean Code and TDD by following an ad hoc tailored version of our study path with the support from the entire team.

On-boarding is another very important aspect that helps newcomers to become first-class XPeppers citizens. The on-boarding process is made up of activities other than simply studying, ranging from learning our culture, presenting their progress to others and joining all daily team activities.

How does the team continually learn and improve their TDD and general code design skills?

Each team member at XPeppers has an ad hoc study path to improve both soft and technical skills continuously. We spend a certain amount of time each day to follow this path and to share know how with other team members by making presentations, pair programming sessions and other team activities that help us grow.

Do you talk about TDD with candidates during interviews?

During our interviews at XPeppers we usually ask the candidate whether or not he/she has familiarity with practices such as TDD. If so, we ask further technical information about the subject and adopt TDD during subsequent exercises and pair programming sessions. If it turns out that the candidate has never done nor seen test driven development before, we try to understand how willing the candidate is to learn and improve his/her knowledge of our practices.

maggio 16, 2017 - No Comments!

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!

marzo 6, 2017 - No Comments!

“How Agile Dev Teams work” – Our seminar @ICTDays 2017

seminar picture

Last Thursday, in a joint effort with Paros s.r.l., we held a seminar at the department of Information Engineering and Computer Science at the University of Trento.

It was the final event of the day for the 2nd of March and a part of the ICTDays program, which is a set of activities spanning across a couple of weeks, organized to facilitate the meeting between Tech companies and Information Technology students that are looking for career opportunities.

We have worked with the Paros team for a cumulative period of almost three years now, and we were looking to share our experience and introduce the attending students to what an Agile transformation may look like - maybe in a company they could be working for in a few years (or months) from now.
(You will be able to read more about our successful collaboration with Paros in an upcoming and more comprehensive case study, so be sure to keep up to date with our latest news!)

The Seminar:

After a brief intro about the Agile principles and manifesto, we talked about the "old way" of doing things.
No shared knowledge about the product, long requirement gathering cycles, impossibly complicated deployment procedures, very few opportunities for growth... You name it.
We then proceeded to illustrate how XPeppers and Paros started their collaboration. One step at a time, it managed to change the company culture, leveraging on the work of both teams.
This introduced a long series of benefits, starting from a collective code ownership of the development team to a deeper commitment to the product across all departments - simply a more efficient process all around.
In particular, we focused on the introduction of Scrum, which allowed us to focus on creating business value: rather than planning in terms of technical considerations, such as software layers, this framework helped the team to plan in terms of benefits for the customers and their final users.
The following step was introducing technical practices taken from Extreme Programming, like TDD, Continuous Integration, Refactoring, which allowed the team to develop the kind of technical excellence needed to be able to release early, often and continuously.

You can look at our slides here!

https://docs.google.com/presentation/d/1pyRu8DJr05iFzIazOUs4HJuZ7_osMs_p-Ua_8VsFoKw/edit?usp=sharing

What we have learned:

At the end of the talk, we had the chance to answer interesting questions from the students spanning across a wide range of subjects: from the technical, down to earth stuff to the most abstract concepts addressed by our process.

It was a very stimulating experience and a chance to take a fresh look at our company environment from the perspective of young, newly trained people.
We are definitely looking forward to more opportunities like this one, where we get to keep in touch with the emerging professionals in our field.

If you were attending our seminar, please let us know your feedback and any questions you may have left by contacting us through our website.
We'd love to hear from you!

febbraio 20, 2017 - 1 comment.

Hiring Great People – come abbiamo migliorato il nostro processo di recruitment

hiring

Attirare e selezionare le persone giuste consente di costruire un grande team, di farlo crescere in salute, mantenendo e consolidando la propria cultura aziendale.
Eppure troppo spesso il processo di recruitment è sottovalutato o demandato quasi interamente al reparto HR o a società esterne.

Nella sessione dell'agile day del 2015 Pietro Di Bello ha raccontato il processo di recruitment che nel corso degli anni abbiamo messo a punto, di quali siano gli aspetti che valutiamo più importanti, dell’importanza di coinvolgere pienamente il team in questo percorso, facendo anche un confronto con i metodi di selezione “tradizionali”.

Si tratta ovviamente di un percorso mai fisso: il processo di recruitment può e deve cambiare ed adattarsi al crescere dell’azienda. E come tale pone sempre nuove sfide, che vorrei raccontarvi, sia di quelle vinte che di quelle perse.

Le slides della presentazione

 

Se vuoi provare dal vivo il nostro processo di recruitment, invia la tua candidatura dalla pagina di carriere.

febbraio 13, 2017 - No Comments!

Case Study PhotoVogue

Photovogue

Nata come società di stampa, al giorno d'oggi la maggior parte dei contenuti di Condé Nast è distribuita attraverso canali digitali, per cui sono necessari la stabilità delle piattaforme di distribuzione e la flessibilità della tecnologia.

PhotoVogue, parte del marchio Vogue, è una piattaforma per i fotografi che vogliono mostrare il loro talento con la possibilità di partecipare a mostre internazionali e iniziative e la possibilità di essere rappresentato da un'agenzia di New York Art + Commerce, una delle più prestigiose al mondo.
La piattaforma, lanciata nel 2011, aveva bisogno di un importante aggiornamento della tecnologia per supportare la crescita costante. Nel corso del kickoff del progetto il team ha deciso di sfruttare tutte le tecnologie all'avanguardia fornite da Amazon.

Abbiamo partecipato all’implementazione nel corso di un periodo di tempo di tre mesi, portando l'adozione di metodologie agili e le operazioni automation di infrastruttura. Amazon ha realizzato un case study sul progetto.

La soluzione

serverless architecture

  • AWS Lambda abilita la scalabilità automatica in base al traffico di PhotoVogue to scale.
  • Il Web Client di PhotoVogue utilizza le API REST costruite con AWS Lambda e AWS API Gateway.
  • Gli utenti possono caricare le loro foto utilizzando la funzionalità delle S3 Pre-Signed URLs.
  • AWS S3 scatena una AWS Lambda function che converte la foto caricata dall'utente in vari formati.
  • AWS RDS con MySQL sono usati come servizio di database.
  • AWS CloudFront è usata come content delivery network per i contenuti.
  • AWS API Gateway è usato come layer di caching per le API rest.

Leggi il case study: https://aws.amazon.com/solutions/case-studies/photovogue/

gennaio 13, 2017 - No Comments!

Mobile Development the XP way

XP mobile

Lo sviluppo di applicazioni mobile comporta nuove sfide rispetto allo sviluppo web tradizionale, come, ad esempio, testare l’applicazione su dispositivi in continua evoluzione o automatizzare i processi manuali ripetitivi e soggetti ad errori per il rilascio sui vari store e piattaforme di distribuzione.
All’ultimo Agile Days, Tiago ha raccontato la nostra esperienza e le soluzioni implementate per arrivare ad un processo di mobile continuous integration con compilazione automatica e rilasci per i tester. In una comunità non molto test infected non è stato facile applicare TDD, ma i risultati ottenuti in termini di stabilità e pulizia del codice giustificano l’investimento.

Slides della presentazione

Link utili

Tiago è anche il trainer del corso “Continuous Delivery su progetti iOS”  in cui vengono spiegate a livello teorico e pratico i principi e le tecniche che permettono di automatizzare il processo di rilascio su App Store. Contattaci per organizzare una sessione on-site per il tuo team.

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 20, 2016 - No Comments!

La pratica del daily journal

daily journal

All'ultimo Agile Day, Pietro di Bello ci ha raccontato la pratica del daily journal: un diario di bordo, da scrivere a fine giornata, per raccontare come è andata, le cose apprese, cosa manca per chiudere il task in lavorazione e quali ostacoli si sono incontrati.

Le slides della presentazione:

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.