Monthly Archives: December 2011

Des tweets et des plus n°10 – Tous bureaucrates

[youtube=http://www.youtube.com/watch?v=C46AbY7uAZs]

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.

Des tweets et des plus n°9 – Developeronomics

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”.

L’architecte

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) ?

Le meilleur code

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:

  1. Any live cell with fewer than two live neighbours dies, as if caused by under-population.
  2. Any live cell with two or three live neighbours lives on to the next generation.
  3. Any live cell with more than three live neighbours dies, as if by overcrowding.
  4. 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

  1. Any live cell with fewer than two live neighbours dies, as if caused by under-population.
  2. Any live cell with two or three live neighbours lives on to the next generation.
  3. Any live cell with more than three live neighbours dies, as if by overcrowding.
  4. Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.
Devient
  1. All cell are dead in the next generation
  2. Any live cell with two or three live neighbours lives on to the next generation.
  3. 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.

Des tweets et des plus n°8 – Yoda Conditions

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!