Avertissement: Cette chronique se veut légère, joyeuse et instructive sur des sujets divers et variés. Elle n’a pas la rigueur éditoriale habituelle de ce blogue.

Everyone is a genius. But if you judge a fish on its ability to climb a tree, it will live its whole life believing that it is stupid – Albert Einstein

Le truc bien avec Einstein c’est que peu importe de quoi on parle, il y a nécessairement une citation sur le sujet. Celle-ci s’applique par exemple très bien aux pauvres développeurs à qui on demande de faire des applications ergonomiques… Arrêtez le massacre, il y a des gens qui font ça très bien. Et comme vous vous en doutez peut-être, aujourd’hui on va parler de savoir.

Selon un anthropologiste de chez Google (et oui, il y a tous les métiers chez Google), 90% des gens ne connaissent pas Ctrl+F… Je laisse mes lecteurs éclairés digérer cette information… 1… 2… Ok… Maintenant je vous laisse répandre la bonne parole en attendant que l’éducation nationale s’en charge. Nous, on retourne pendant ce temps à notre Alt+Shift+X, T (Lancer un test unitaire dans Eclipse).
http://www.theatlantic.com/technology/archive/2011/08/crazy-90-percent-of-people-dont-know-how-to-use-ctrl-f/243840/

Mais la nouvelle d’intérêt n’est pas là. (Lire la suite…)

La tendance des bus de messagerie est aujourd’hui de proposer des modes de déploiement distribués au delà de l’architecture master/slave qui se veulent simple à mettre en oeuvre et dynamique.
ActiveMQ n’est pas en reste et offre la possibilité de créer un cluster de brokers qui savent intégrer un nouveau broker et détecter la perte d’un broker. Ces informations peuvent ensuite être transmises aux clients connectés pour se reconnecter sur un autre broker du cluster pour mieux répartir la charge ou tout simplement car ils étaient connectés à un broker qui vient de tomber.

Nous verrons comment ces fonctionnalités permettent d’obtenir un système tolérant à la panne et quels sont les limites à prendre en considération.

Voyons tout d’abord la gestion du cluster entre brokers.
(Lire la suite…)

Objectif

Une des valeurs portées par le mouvement DevOps réside dans l’ouverture et l’échange des outils, bonnes pratiques, us et coutumes entre Devs et Ops. Essayons donc dans ce billet de tirer profit des bonnes habitudes du TDD et voir dans quelle mesure il y aurait matière à les piquer / adapter dans le monde du run et des infrastructures. Une idée serait de considérer l’infrastructure comme un système testable et donc mettre en place une stratégie systématique de TDI pour Test-Driven Infrastructure. Un changement, un test.

(Lire la suite…)

NullPointerException : l’erreur la plus courante dans un programme Java. On est tous à un moment ou à un autre tombé sur cette exception. Malheureusement, ce n’est qu’en production à 4h du matin qu’elle arrive. On corrige donc le bug suivant :

MonObjet monObjet = null;
…
monObjet.maMethode(); // => NullPointerException

Par un rapide :

if(monObjet != null) {
  monObjet.maMethode();
}

Ce correctif est tout à fait honorable, mais pourquoi ne pas essayer de ne plus avoir aucune exception de ce type ?

Il existe plusieurs méthodes validées par le compilateur pour l’éviter, et donc avant la mise en production. Aucune n’est nouvelle, certaines controversés, mais elles sont toutes étudiées dans la suite de cet article.

(Lire la suite…)

Vous êtes déjà un expert TDD, votre application a une couverture de tests de plus 80%. Mais vous avez le sentiment que tout n’est pas testé, qu’il reste d’obscurs cas que vous n’arrivez pas exprimer.

Pourquoi ne pas demander à un programme de vous aider à tester ?

Vous pouvez déjà passer par le mutation testing. Cette méthode donne une première approche, mais il en existe une autre : les tests par propriétés.

Cette méthode se résume à exprimer des propriétés et de laisser un programme la vérification de celles-ci.

C’est une façon de tester qui provient des langages fonctionnels et donc qui peut paraître étrange si on vient du monde objet « classique ».

Donc regardons plus en détail son fonctionnement et à quoi elle pourrait servir.
(Lire la suite…)

Situation n°1 : Vous regardez votre agenda, combien de réunions ont déjà été posées pour résoudre les problèmes en cours. Vous vous dites que « Ca fait beaucoup pour la journée »  en terminant votre tasse de café. Et d’ailleurs combien de fois avez-vous posé une réunion pour comprendre ce problème sur la vélocité de cette équipe ? Une vélocité qui ne décolle toujours pas, mais ces réunions vous auront permis, au choix, de rajouter des développeurs, de changer des développeurs, de changer d’architecture. Beaucoup de décisions pour, au final se rendre compte que la vélocité n’augmente toujours pas … Bref, le problème est toujours là.

Situation n°2 : C’est la fin de l’année, combien de produits avez vous lancé ? Combien de ses produits ont apportés de la satisfaction pour un client ? Et combien de réunions avez vous fait pour définir ces produits ? Combien de brainstorms et d’ateliers ? Beaucoup et à chaque fois énormément d’idées et de concepts sur comment tout ça va s’articuler, pour au final se rendre compte que peu de personnes utilisent vos produits …

Si vous avez rencontré l’une des situations présentées, et qu’après toutes ces réunions vous vous demandez encore ce qui se passe réellement, alors il est temps de sortir votre chapeau de détective privé pour aller enquêter sur le terrain !

(Lire la suite…)