TDD workshop

sherlockFew months ago in the office we started a discussion about testing.
The original topic was “how to implement a continuous integration/continuous delivery workflow”, so “how to test” became immediately a requirement and a parallel important topic.

My suggestion was to start coding in TDD of course, but like every office we had a lot of legacy code to deal with.
In order not to be stuck by that, we decided temporarily to focus on new (or almost new) projects and apply it to them.

So the point became to find a way to have all the developers, regardless on the seniority and the project, on the same page about the topic.

Continue reading

Advertisements

The hangman in angularjs

Source Wikipedia:

The Hangman is a paper and pencil guessing game for two or more players. One player thinks of a word, phrase or sentence and the other tries to guess it by suggesting letters or numbers.

The word to guess is represented by a row of dashes, giving the number of letters, numbers and category. If the guessing player suggests a letter or number which occurs in the word, the other player writes it in all its correct positions. If the suggested letter or number does not occur in the word, the other player draws one element of a hanged man stick figure as a tally mark. The game is over when:

  • The guessing player completes the word, or guesses the whole word correctly
  • The other player completes the diagram:

This diagram is, in fact, designed to look like a hanging man. Although debates have arisen about the questionable taste of this picture,[1] it is still in use today. A common alternative for teachers is to draw an apple tree with ten apples, erasing or crossing out the apples as the guesses are used up.

Continue reading

Blackjack in AngularJs (reprise)

After the first implementation of the game, my friend and I compared our versions.
He focused on the deck model instead of the dealer like I did.

This simple choice drove his design to a complete different path.
He put a lot of effort trying to replicate a realistic deck, implementing the shuffle logic and making impossible to draw the same card twice.

This hypotheses never came up to my mind because I knew that in the real game there are multiple decks in order to make almost impossible for the players the calculation of the drawn cards.
Continue reading

Pivotaltracker plugin: Importance of Integration test

When I developed the pivotaltracker plugin to extract our backlogs (here the post), instead of create a mock application to use it, I gave the library to my colleague so he could integrate it in the real application that my frontend application would have used to retrieve all the backlogs.

Everything went well until the application tried to parse the stories in the final contract, then the application crashed miserably.
I and my colleague worked side by side:
The first thing I did was to run my test: all passed.
So I checked the response of the pivotaltracker API, maybe they had changed something: nope, the response of the API was exactly what I expected to receive.
So what happened?
Why my test didn’t represent correctly the real situation?

Continue reading

Backlog Aggregator: Roadmap Feedback (part one)

In our weekly meeting with the boss, I showed my roadmap-preview to have feedback and improve it (here the first part and here the second part of the creation of the roadmap-preview).
The roadmap-preview had to be used in two different places: in a dashboard as part of a summary of a project and in a Roadmap page where was needed to show more detailes.

My roadmap-preview had been considered good-looking, but lacking of information.
It wasn’t clear the content and the month of a release: in the dashboard had to be possible to read the key features of a release clicking on the flag, but in the Roadmap page was considered more useful to view them immediatly.

I decided not to create two different roadmap-preview directives; I prefered to have something like:

<roadmap-preview
  roadmap="roadmap"
  show-detail="true"></roadmap-preview>

Continue reading

Backlog Aggregator: Pivotaltracker Plugin (part one)

There we are.
The goal with this plugin was to give an easy way to get from a project the stories of the current iteration.
I usually prefer to work time boxed when I play on an exploration task, so I decided to give five hours to this task and then evaluate the results and possible efforts/costs to obtain an usable version of the plugin.

My team uses Pivotatracker so I already had  the credentials to use the API, but before to write any code, I started reading a few of documentation and making some test using my REST Client.
After one hour I was sure to have enough information to start.

Continue reading

Backlog Aggregator: how

Well, the idea was to have a website where to show, for every project, backlog and other informations more related at the Company and its workflow.

We decided to split the work, so I was in charge to develop the website and to give a help to develop the plugins able to get stories from pivotaltracker and easybacklog and able to map them in a common DTO.

The others two team members started to analize a repository and a backoffice to put other relevant information apart the backlogs.

Continue reading

Backlog Aggregator: why

Long story short : it is three years I am working in an agile team (two years as Scrum Master) . Initially, the team was supposed to be a pilot for the company and because of some results we brought, it was decided to migrate other teams in an agile approach .

In the spirit of the methodology, each team have had the possibility to self-organizing; after that, they chose which tools ( electronic or not) they could use to optimize their work.

Continue reading