Aurélien Pelletier

Des tweets et des plus n°14 – Agile subway map

2012-02-20T22:32:03Z

A Web Developers’ View of Play Framework 2.0: With Play, the Back button just works [...] Play doesn’t fight HTTP or the browser [...] As a Java EE developer, PHP and Rails developers have been laughing at us for years

La pratique “Définition de prêt pour une story”: Une story non prête n’est pas acceptée dans un sprint qui commence

On Naming: The challenge is that the coder is holding two conversations at once, one with the compiler/interpreter and one with the future maintainer

It’s About The Hashbangs: Directly addressable content is what makes web apps better than desktop apps. It’s certainly not the UIs.

Des tweets et des plus n°9 – Developeronomics

Des tweets et des plus n°13 – Polyglot Persistence

2012-02-10T12:22:34Z

Polyglot Persistence: using multiple data storage technologies, chosen based upon the way data is being used by individual applications. Why store binary images in relational database, when there are better storage systems

Less Process, More Discipline :The key to agile methods is this: You may have less process, but you must have more discipline.

Service Oriented Agony: Unfortunately this is a huge violation of the Single Responsibility Principle — or its big brother the Common Closure Principle. These principles tell us to group together things that change together, and keep apart things that change for different reasons.

How to Create Maintainable Acceptance Tests: Prefer to test your application via the service layer or at worst the servlet layer; only test on the UI level if you really have to and only as little as possible for UI is much more brittle (and also difficult to test)
The more you want to test the more you have to pay for it in the terms of maintenance effort. Usually you decide so that you cover the part(s) of the application where the most risk is – the best thing is to do cost-benefit evaluation.

No related posts.

Des tweets et des plus n°12 – Mega Busted

2012-01-25T20:26:03Z

The GitHub Job Interview: You come up with a cool idea of an open-source project. This becomes your company’s development sandbox. Candidates are asked to then contribute to the project in some way

Languages, Verbosity, and Java: “A little redundancy in a language is a good thing. It’s important for readability.” Joshua Bloch

Amazon DynamoDB: A number of outages at the height of the 2004 holiday shopping season can be traced back to scaling commercial technologies beyond their boundaries

Average Is Over: the reason we have such stubbornly high unemployment and sagging middle-class incomes today is largely because of the big drop in demand because of the Great Recession, but it is also because of the quantum advances in both globalization and the information technology revolution

Code Search tools

Des tweets et des plus n°11 – Geeks win

2012-01-08T17:34:43Z

Shame driven development: it was throwaway, one-use code so didn’t have any unit tests. I was embarrassed. [...] the only way to go fast, is to go well

Cleaning a kitchen is a good metaphor for Refactoring: Neither would a cook accept that I go into his kitchen and say: I want my steak half the price, can’t you not clean the kitchen today? In the software world we let people tell us, do it quick and dirty, you can clean up after, when we have the time.

How netflix get out of the way: Who has junior engineers, graduate hires and interns writing code? We don’t. We find that engineers who cost twice as much are far more than twice as productive, and need much less management overhead

CQRS: est un modèle d’architecture système qui sépare la partie lecture de données (query) de celle qui les modifie (command) de manière à produire un système extensible, distribuable, et fournir quelques avancées utiles qui rendent la maintenance du système moins pesante.

No related posts.

Another Git branching model

2012-01-02T21:39:32Z

We’ve switched to git at work a few month ago. Not an easy task but the rewards are worth the trouble. Our branching model was based on Git Flow because it’s well documented and gives you a structure to start with DVCS. Well, after a few iterations it wasn’t working as expected in our context. So we had to come up with our own workflow.

I guess Git Flow works well on a clean code base with good test coverage. But on legacy code, where one feature means two regressions, a release branch is like the vietnam war, you never know when you will get out of it. That was one of our main problem on subversion, we were creating release branch to go to production. And it would take forever to actually ship the code. Meanwhile all other development efforts remain stuck.

I though that cheap branching and merging in git would solve our issue. But cheap merging is not enough, you also need to be able to easily pick what to merge. And with Git Flow it’s not easy to remove a feature from a release branch once it’s there. Because a feature branch is started from develop it is bound by its parents commits to other features not yet in production. As a result, if you merge a feature without rebasing you always get more commits than wanted.

So here is the workflow we use to solve those issues:

The main branches

We have three branches with an infinite lifetime based on the classical trio (dev/test/prod):

master
staging
develop

Master is the same as in git flow:

We consider origin/master to be the main branch where the source code of HEAD always reflects aproduction-ready state.

Staging is a bit like develop in Git Flow :

We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”.

Develop is there for continuous integration, this is where we constanly merge all the changes to detect bugs and conflicts as soon as possible. The source code in the develop branch never reach a stable point where it is ready to be released. Instead only some feature branches reach a stable point. Those stable feature branches are merge into the staging branch. Since feature branches were created from master and not from develop we can pick individualy which one will be merge to staging. In fact this is the main point of this workflow: We can easily choose which features will go into production next.

To release the code to production we just merge staging into master.

Feature Branches

All work is done in feature branches which can be merge into

master for a quick fix in production
staging for bug fixes
develop constanly for continuous integration

Since we use github we usualy do a pull request to merge feature branches. We don’t always follow the rules and commit on master and staging happens, they are merge back to staging and develop. The only place where we don’t commit is develop (only merge commit)

Summary

Git Flow was not working for us, but by creating feature branches from master instead of develop we gained the ability to easily choose which features we release next. This gave us much more flexibility and got us out of “vietnam release branch”.

Now I should tell about all the best practices to make this workflow really work, but I’m lucky, someone already wrote them down.

And you, what is your branching model ?

Des tweets et des plus n°2 – Post It war

Des tweets et des plus n°10 – Tous bureaucrates

2011-12-30T22:15:43Z

Tous bureaucrates: Ainsi – et c’est la caractéristique principale d’une bureaucratie – la défense des territoires y devient un objectif plus important que l’intérêt général de l’entreprise, sa survie. Car ce rapport de force moyenâgeux entre services se superpose à la traditionnelle séparation entre penseurs et faiseurs, autre caractéristique des bureaucraties

Strangest language feature:

JavaScript truth table:
 
''        ==   '0'           // false
0         ==   ''            // true
0         ==   '0'           // true
false     ==   'false'       // false
false     ==   '0'           // true
false     ==   undefined     // false
false     ==   null          // false
null      ==   undefined     // true
" \t\r\n" ==   0             // true

Les métiers de l’informatique: En France, 77% des jeunes diplômés en informatique débuteraient ainsi leur entrée dans la vie professionnelle à partir d’une SSII, alors que seul 1 % de l’effectif des SSII quitterait l’entreprise pour cause de départ à la retraite (contre 10,4 % en moyenne)

LA PÉNURIE DE DÉVELOPPEURS: Altaïde rencontre aussi depuis deux ans les pires difficultés à trouver des développeurs sur les technos du web et mobile. Trouver des développeurs PHP, Java, .Net, IOS, Androïd ou RoR, pour ne citer que ces technos les plus demandées, c’est une débauche de moyens et d’énergies énorme.

No related posts.

Des tweets et des plus n°9 – Developeronomics

2011-12-12T20:44:05Z

The Rise of Developeronomics: We are only just beginning to understand how software is now the core function of every company, no matter what it makes or what service it actually provides.

Why Play isn’t a Java web framework : The country that Play comes from is called the World-Wide Web

4 Types of programmer: action heroes are mostly extreme agile developers, technical gurus, and junior developers.

Testing Will Challenge Your Conventions: “Clever” is dead. Clever is hard to refactor. Clever is hard to isolate, hard to internalize, hard to phrase in tests. One point of “obvious” is worth two hundred points of “clever”.

No related posts.

L’architecte

2011-12-08T22:08:23Z

La tête dans les nuages
Les mains dans le cambouis
Les pieds sur la prod

La tête dans les nuages

Pas parce qu’il s’intéresse au cloud, mais parce qu’il doit prendre de la hauteur et du recul pour analyser, synthétiser et savoir restituer des vues adaptés à chacun des acteurs d’un projet. Il est le garant d’une vision partagée et cohérente des objectifs métiers stratégiques jusqu’aux déploiement des composants logiques sur des serveurs physiques ou virtuels.

Les mains dans le cambouis

L’architecte qui ne code plus (pire n’a jamais codé) a vite fait de s’envoler dans les nuages et de perdre le contact avec la réalité. De la vue aérienne d’un projet il doit pouvoir zoomer sur un composant logique, sa conception et la ligne de code. Seul un astro-architecte qui ne quitte jamais les stratosphères de sa cellule architecture et méthode peut retenir des technologies comme EJB1/2 ou JSF, qui en pratique sont inutilisables. Une technologie ou une architecture peut avoir toutes les qualités que l’on voudra, si elle n’est pas comprise et adopté par les développeurs ça n’ira pas loin.

Les pieds sur la prod

Tan qu’il n’est pas entre les mains des utilisateurs un projet informatique ne produit aucune valeur. Et le passage obligé pour atteindre les utilisateurs c’est la prod. Vous suivez à la lettre les recommandations du site 12factors ? Super votre application est prête à être déployé dans le cloud. Dommage, ce qu’attend votre prod c’est un ear pour déployer sur webFear ! Pour que le succès d’une application soit complet travailler en étroite collaboration avec les gens de la prod (Devops) et aussi important que de leur faire avec le métier (les méthodes agiles)

Et chez vous il fait quoi l’architecte (logiciel bien sûr) ?

No related posts.

Le meilleur code

2011-12-05T18:30:13Z

est celui dont on peut se passer

J’aime bien cette citation

“Le meilleur code est celui dont on peut se passer.”
Le type qui va maintenir votre code

C’est la clé d’une réalité difficile à accepter et encore plus à prouver : un bon développeur peut être 100 fois plus productif qu’un mauvais.

Dans l’évolution d’un programmer python:

Le débutant écrit une implémentation naïve,
Celui qui connait le langage résout le problème en une ligne simple,
L’expert utilise tout simplement une librairie déjà existante.

Mais il manque un type de développeur: celui qui trouve la solution pour ne pas avoir à écrire ce code.

Illustration avec le Kata du game of life

Lors du code retreat de ce week-end la 3eme itération avec piwai m’a permis de trouver une illustration simple et concrète de ce précepte. (PRO tip: le pair programming est un moyen pour fabriquer des développeurs 10 fois plus productif à partir de deux développeurs normaux)
Le kata classique d’une code retreat est le game of life, la spec tien en 4 règles:

Any live cell with fewer than two live neighbours dies, as if caused by under-population.
Any live cell with two or three live neighbours lives on to the next generation.
Any live cell with more than three live neighbours dies, as if by overcrowding.
Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

Chaque itération dure 45min, en pratique il est difficile de finir dans ce temps, ce qui tombe bien car le but d’un kata n’est pas de finir mais d’expérimenter librement. Dans une approche TDD naïve on va commencer par implémenter un test permettant de valider la première règle, puis implémenter le code permettant qui permet de faire passer le test.

Mais TDD ne veut pas pire pas de conception, bien au contraire, la première question à se poser est qu’est qu’on doit tester?

Dans le cas du game of life on réalise très vite qu’on à besoin de stocker l’état des cellules dans 2 structures, une pour la génération actuelle, une autre pour la suivante. Si l’on démarre toujours la génération suivante par une structure vide que l’on va remplir en parcourant la structure actuelle il n’est pas nécessaire d’identifier les cellules à tuer: elles sont déjà toutes mortes dans la prochaine génération. Ce qui permet de ne pas se soucier de 2 règles sur 4.

Ainsi

Any live cell with fewer than two live neighbours dies, as if caused by under-population.
Any live cell with two or three live neighbours lives on to the next generation.
Any live cell with more than three live neighbours dies, as if by overcrowding.
Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

Devient

All cell are dead in the next generation
Any live cell with two or three live neighbours lives on to the next generation.
Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

La complexité du problème a été divisée par deux…

En partant sur ces bases on a pu finir de manière relativement élégante en 30 min.

package gol;

import java.util.ArrayList;
import java.util.HashSet;
import java.util.List;
import java.util.Set;

public class World {

	Set<String> world = new HashSet<String>();

	public void addLiveCell(int x, int y) {
		world.add(getkey(x, y));
	}

	private String getkey(int x, int y) {
		return x + ":" + y;
	}

	private int getX(String key) {
		return Integer.valueOf(key.split(":")[0]);
	}

	private int getY(String key) {
		return Integer.valueOf(key.split(":")[1]);
	}

	public int getNumberOfNeighbour(int x, int y) {
		int numberOfNb = 0;
		List<String> neighbour = getNeighbour(x,y);
		for (String key : neighbour) {
			if (world.contains(key)) {
				numberOfNb++;
			}
		}

		return numberOfNb;
	}

	public int getNumberOfNeighbour(String key) {
		return getNumberOfNeighbour(getX(key), getY(key));
	}


	private List<String> getNeighbour(String key) {
		return getNeighbour(getX(key), getY(key));
	}

	private java.util.List<String> getNeighbour(int x, int y) {
		List<String> nb = new ArrayList<String>();
		nb.add(getkey(x-1, y-1));
		nb.add(getkey(x-1, y));
		nb.add(getkey(x-1, y+1));
		nb.add(getkey(x, y-1));
		nb.add(getkey(x, y+1));
		nb.add(getkey(x+1, y-1));
		nb.add(getkey(x+1, y));
		nb.add(getkey(x+1, y+1));
		return nb;
	}

	public void tick() {
		Set<String> newWorld = new HashSet<String>();
		Set<String> neighbourCells = new HashSet<String>();
		for(String key : world) {
			if (ifThreeOrTwoNeighbour(key)) {
				newWorld.add(key);
			}
			neighbourCells.addAll(getNeighbour(key));
		}

		for(String key : neighbourCells) {
			if (ifThreeNeighbour(key)) {
				newWorld.add(key);
			}
		}

		world = newWorld;

	}

	private boolean ifThreeOrTwoNeighbour(String key) {
		int numberOfNeighbour = getNumberOfNeighbour(key);
		return numberOfNeighbour == 3 || numberOfNeighbour == 2;
	}

	private boolean ifThreeNeighbour(String key) {
		int numberOfNeighbour = getNumberOfNeighbour(key);
		return numberOfNeighbour == 3;
	}

	public boolean isAlive(int x, int y) {
		return world.contains(getkey(x, y));
	}

}

            view raw
            World.java
            This Gist brought to you by GitHub.
          

Des tweets et des plus n°8 – Yoda Conditions

2011-12-02T10:10:47Z

Politics-Oriented Software Development: The code itself is the only document which may be relied upon in any way in order to find out how the software might actually behave under this or that set of circumstances. However, anyone actually saying so only reveals themselves as a troublemaker.

Entreprise 2.0: Within the companies, workers have little incentive to
share, as it is additional work with no clear benefits. Therefore, only the
minority of do-gooders, open source advocates who have an ideological bias
towards sharing knowledge, uses it

The death of Flash : Apple decided not to adopt the Flash Platform because Flash would limit its ability to differentiate its devices

Yoda Conditions : Un véritable guide des bonnes pratiques du code legacy. A lire absolument!

No related posts.