Dwight explique qu’un des principes de base qu’il a appris au fil des années, c’est l’importance de répliquer les données. Pour réussir, il faut être capable de construire un site web capable de ne pas rendre captif toutes les données qu’il va générer. J’aime beaucoup cette idée. Voyez votre projet comme une source de données. Essayez de ne pas prendre une solution trop captive et trop contraignante, car la clé de votre succès sera les services que vous pourrez construire sur vos données.

Pour s’assurer que les données sont bien sauvegardéss, vous pouvez les répliquer sur différents serveurs. Vous pouvez mettre en place une solution curative avec des backups de votre base. Ou sinon, vous pouvez aussi prévoir une solution préventive au niveau de votre architecture.

MongoDB c’est cela : une base de données type No-SQL orientée document, sans schéma, capable de fonctionner sur un énorme volume de donnée. C’est un serveur qui se configure en cluster en quelques minutes. Bref c’est un système qui coûte moins cher qu’une solution Oracle, et qui permet de répondre à pas mal de besoins. Mais pas à tous.

Aujourd’hui le premier souci est la capacité à monter en charge et à faire tourner sur un même CPU, sur un même espace mémoire, une quantité d’informations plus importante. Traiter en parallèle les données. Sur les bases de données relationnelles, il est acquis aujourd’hui que certaines opérations ne sont pas possibles lorsque le volume et le nombre de transaction à traiter sont importants. Les jointures, la consolidation des données, il s’avère que le prix de tout cela explose au fur et à mesure. Dwight dit que plutôt de parler de « noSQL » il préfère dire « noRelationnal ».

MongoDB est dans la famille des bases de données NoSQL. Jean-Laurent de Morlhon demande pourquoi, alors que l’approche non-relationnelle existe depuis les années 80, pourquoi cette approche est populaire aujourd’hui ? Tout d’abord Dwight explique qu’aujourd’hui, les volumes sont bien plus importants qu’il y a quelques années. L’approche non-relationnel est une solution logicielle, alors qu’il y a 10 ans nous étions dans la solution matérielle. Il y a 10 ans on achetait une machine plus grande. Aujourd’hui on travaille sur le logiciel et on arrête d’empiler la puissance mémoire/CPU.

Dwight explique aussi qu’il y a quelques années, on créait son modèle relationnel pour le minimum de système, en ne pensant qu’à l’application que l’on réalisait à ce moment là. Le souci de cette approche c’est lorsque le métier évolue. Comment garder à peu de frais un schéma ? Comment éviter des développements longs et couteux ? Aujourd’hui, une application et son modèle de donnée doit être pensé pour plusieurs années. Or le stockage devient un problème. Comment stocker et retrouver rapidement ces énormes volumes ?

Je trouve cette idée intéressante. Imaginez vos données comme un immeuble, qui aura besoin d’un ravalement de facade. Plus sérieusement, imaginez l’état de vos données dans 5 ans… Imaginez la quantité et le coût d’exploitation…

Les concurrents de MongoDB ne bénéficient pas de la même couverture médiatique. Apache Cassandra est un excellent produit, arrivé finaliste lors du concours de l’USI 2011. Il existe d’autres solutions comme Redis ou CouchDB, des solutions dites « No-SQL ». Si vous voulez briller en ville : parlez d’Agilité, de Scrum et terminez par une petite saucée de CloudComputing, le tout avec du NoSQL. Les hommes vous trouveront intelligents et les femmes se jetteront sur vous. Ou inversement. Bref.

Dwight parle ensuite d’Oracle, qui se positionne aussi sur ce secteur. Oracle a lancé un système clé/valeur, construit sur le moteur open-source de Berkley. IBM aussi s’intéresse forcément à ce type de solution. Pourquoi ? Car ce sera le nouvel eldorado.

Dans une entreprise traditionnelle, on a souvent une base relationnelle (SGBDR) et une base décisionnelle (data warehouse). Chaque système a ses avantages et ses inconvénients. Une base relationnelle permet de garantir l’intégrité, de gérer les transactions, et de représenter les relations entre les entités du Domaine. Un système de Datawarehouse est pensé pour l’analyse et le reporting sur les données. Enfin Dwight expose que MongoDB se place comme étant un troisième type de base de données. MongoDB offre de l’agilité, une installation et une capacité à s’installer en cluster bien plus simple (et surtout vraiment moins cher) que les solutions classiques des éditeurs comme Oracle ou IBM. Donc on voit ici qu’une entreprise pourra avoir ces 3 logiciels, avec un usage différent à chaque fois.

Si par contre vous regardez le monde des Startups en ce moment, là c’est une toute autre histoire. Traditionnellement, le couple PHP+MySQL+Apache était utilisé pour construire un site Internet. Ruby on Rails est largement utilisé par les startups. Mais comme l’expliquerons les équipes de Fotopedia quelques heures plus tard : Rails n’est pas aussi performant en production que Java/Scala/.NET. Bref, peu importe, si on parlait plutôt de bases de données ?
Et bien MongoDB est une compétence très demandée sur le marché, information que j’ai vérifié :

Source : http://data.story.lu/2011/09/29/facts-and-stats-mongodb-trend

Quelques questions de la salle ensuite parlent des relations entre les développeurs et les DBA. Quelqu’un demande à Dwight son opinion sur le métier de DBA par rapport à MongoDB. Il explique en forçant un peu le trait que tout d’abord, une base de donnée classique, c’est le royaume du DBA. Une base MongoDB, c’est plutôt le royaume des développeurs. En quelques sortes, le développeur prend le pouvoir sur le modèle. Dwight explique qu’il y a des DBAs pour les bases NoSQL, des personnes qui sont souvent aussi des développeurs. L’absence de schéma, sa flexibilité, le fait que ce modèle mappe directement le code, fait que forcément le développeur est le premier évangéliste de MongoDB.

Une autre question porte sur le nombre de clients qui utilisent MongoDB aujourd’hui en production. Personnellement lorsque j’entends ce type de question… ça me fatigue. Il n’y a que les Français pour se dire :
- »Ah moi je prends une techno QUE si c’est utilisé sur de VRAIS SITES ou sur des VRAIS PROJETS.

Pour la société 10gen, aujourd’hui Dwight explique qu’ils ont 400 clients. Il y a bien entendu bien plus de sociétés qui utilisent MongoDB. Dans le monde des startups, 90% des projets qu’il a vu font le choix de l’approche NoSQL, donc souvent MongoDB. Pourquoi ? Car il existe de nombreux drivers pour tous les langages.

Il résume cela avec une phrase en souriant :

It’s happening.

Une question ensuite porte sur Oracle, afin de connaître son opinion. Il voit des entreprises qui ajoutent MongoDB, tout en gardant leur base Oracle. Par ailleurs, Oracle travaille sur des solutions de type MySQL. Et ce sera un compétiteur pour 10gen très important. Il pense que si Oracle venait à ignorer l’approche NoSQL, alors ils perdront des parts de marché.

Pour terminer, nous avons eu aussi une présentation très détaillé de l’importance du schéma sur les performances. Le CEO de MongoDB passe 10 bonnes minutes à nous expliquer le problème de chargement de blocs non-contigus, spécialement lorsque les données recherchées ne sont pas dans un index. C’est impossible pour moi à retranscrire ici.

Mais au final, retenez que le CEO de MongoDB est un Geek, un gars qui assure, et qui peut vous parler de swap et de disques SSD dans une présentation.

Et moi, ça m’a donné envie d’essayer MongoDB.

Le planning est décidé et voté à l’avance, afin de séquencer la journée. Au programme : NoSQL, Vendre les Tests au Management, une présentation sur Hadoop et une séance de TDD pour ceux qui veulent participer. J’ai fait aussi une présentation de Play! Framework en 1h30, avec une séance de live-coding.

Michael Figuiere qui rentre juste de la conférence NoSQL Europe à Londres, nous a présenté NoSQL en 2h00. Ce fut une très bonne présentation, tant sur le fond que sur la forme. Je me dis aussi que ces exercices sont un bon moyen pour les personnes de Xebia pour se préparer à faire des présentations ensuite à l’extérieur. L’ambiance est assez studieuse. Les questions fusent, et chacun peut intervenir pour participer. Les débats sont intéressants, avec un Cyrille qui ajuste les débats.

L’organisation de l’événement est assurée par Erwan Alliaume et Nicolas Jozwiak. Les sujets sont en fait proposés quelques semaines en avance, afin de s’assurer que le programme puisse être préparé. Ils joueront tous les deux les maîtres de cérémonie. L’encadrement de Xebia est très spectateur. Mais j’ai vu que le directeur général, le directeur technique et même le PDG, passent au moins une heure en tant que spectateur, sans intervenir. Je pense qu’ils apprécient de regarder de l’extérieur et qu’ils en profitent pour suivre les présentations.

Le repas est un moment important pour discuter autour d’un bout de pizza. Les nouveaux posent des questions aux anciens, le planning de l’après-midi se prépare, tout est bien rodé.

J’ai ensuite décidé de faire un atelier DDD avec à ma droite « l’invité mystère ». Et bien nous nous sommes bien amusés et nous avons appris des choses. Après avoir refactorisé plusieurs fois notre code, sous la conduite de Guillaume Bodet, nous avons échangé et passé un bon moment avec les équipes de Xebia.

J’ai ensuite fait une présentation de Play! qui a un peu duré, où j’ai codé une application simple pour montrer un peu les capacités de l’outil. Pas le temps de rester malheureusement pour la suite, je file à la présentation des speakers de l’USI 2010.

Conclusion
J’étais aussi en observateur, afin de travailler sur le sujet que je présente en juillet à la conférence l’USI 2010. J’ai regardé le fonctionnement, la dynamique de la communauté des consultants de Xebia. On se rend compte que cet investissement est payant. Les présentations sont de qualités, les personnes sont là aussi pour se former et pour échanger avec d’autres personnes. L’organisation n’est pas pilotée par le management, ce qui est intéressant. C’est 2 collaborateurs qui se chargent de la préparation puis de l’animation. L’idée de proposer aux candidats de vivre une journée avec les équipes est très futée. Cela permet vraiment de séduire ceux qui hésitent, s’il y en a.

L’organisation de la journée gagnerait peut-être à avoir des petites présentations plus courtes, plus rapides, sur des sujets plus improbables comme j’ai vu chez SFEIR. Je vous raconterai cela dans un autre billet.

Merci à Xebia, à Erwan, à Nicolas et à Luc pour cette journée.

L’heureux gagnant d’un voyage à JavaOne est Sébastien Guerlet avec qui j’ai eu le hasard de discuter au début de la soirée, sans savoir qu’il deviendrait le gagnant. Il travaille dans une société de consultant qui intègre pour des grands comptes le logiciel SalesForce.com, un moteur de CRM SAAS (Service As A Service). Arrivé 47 ème au Quizz, il a remporté le tournoi après 3 heures de jeu. La fin était vraiment sympa, je pense que vous trouverez des photos sur le blog de Xebia demain matin.

J’ai croisé des lecteurs du Touilleur et c’est toujours sympa de discuter avec les personnes qui lisent mon charabia. Je suis tombé aussi sur Dimitri Baeli, avec qui j’ai travaillé il y a 6 ans dans l’une des start-ups de l’époque (Dotvision) qui avait fait la plus grosse levée de fond de la place de Paris en 99… Souvenir… JavaOne 2000… Ah c’était cool.

Quant à moi j’ai terminé 24ème… 56 minutes de jeu… Mais du coup j’ai ensuite eu le temps de discuter avec pas mal de monde.
Et donc voici ce à quoi je voulais venir : je voulais partager les idées et les suggestions des joueurs, qui ont tous été bluffé par l’organisation. Diner et buffet très sympa.
- Guillaume : « Ca aurait été bien d’avoir un goodies comme un tee-shirt »
- Dimitri : « L’an prochain, si vous pouviez faire jouer 30mn les gens sans commencer le tournoi, ça sera plus facile »
- Nicolas : « Je propose que Sébastien, le vainqueur, soit requalifié l’an prochain automatiquement »
- Christophe « On a tous des badges avec nos noms et marqué Xebia… du coup je ne vois pas qui sont les gens de Xebia. » Et moi de répondre : « ce sont ceux qui n’ont pas de badge  »
- Le croupier : « Pour des amateurs, ça joue bien. Y’en a qui se débrouillent vraiment bien. »
- Un gars : « On pourrait avoir des cartes de poker avec le logo Xebia ? »

Allez je vais dormir car demain Scrum Stand-up meeting à 09h30, suivi d’une réunion et ensuite vendredi soir, encore soirée Java (j’ai pas arrêté cette semaine)

Mission remplie, billet posté à 1h36, encore un point de santé mentale en moins, à vous les studios,

Bye

Comme plusieurs personnes me l’ont fait remarqué, le dernier article publié sur la page d’accueil du Touilleur datait du 11 mars, alors que j’ai blogué pas mal depuis. Désolé pour ce couac. C’est maintenant réparé, vous devriez retrouver une page d’accueil à jour. Vous pouvez me signaler les soucis en utilisant mon email qui est en haut à droite sur le logo du Touilleur. Et vous pouvez aussi me contacter pour me parler de la pluie et du beau temps, il n’y a pas de soucis. Je sponsorise aussi les candidatures motivées, comme pour une personne qui m’a contacté et qui cherchait du boulot dans la finance avec du Java. Avis aux amateurs donc. Qui ne tente rien n’a rien

Pour revenir au look du blog, j’ai préparé un nouveau thème pour le Touilleur. La section Archives prenant un peu trop de place, je vais la remplacer par un nuage de tags, ce qui me semble plus pertinent. Migration prévue ce week-end.

Côté Scrum, c’est sur les rails pour mon équipe depuis la certification Scrum. Après quelques aventures, je trouve que la semaine dernière a été assez sympa. J’ai conscience que pour l’équipe c’est une révolution, et qu’il y a beaucoup de travail de communication de ma part à effectuer. Mais je pense qu’ils y croient.

Ici au travail, depuis la formation, j’ai pris conscience que trop d’email tue l’email. Je serai tenté de proposer un « No Mail Friday« , « Pas de mail le vendredi ». L’outil électronique a tendance à dégrader la communication et les relations entres les gens. Je n’ai jamais autant pris l’ascenseur et discuté avec les gens qu’avant. Il est vital de discuter, je pense que nous souffrons d’un problème de communication où le mail devient le rempart pour ne pas s’engager, pour ne pas s’exposer.
J’ai décidé de me déplacer, discuter avec les gens, ou téléphoner. Terminé la perte de temps à jouer au « Reply-All » avec une pile de manager…

Hier je suis entré dans le bureau du nouveau big boss. Madame Boss est partie, remplacée par Monsieur Boss. Et au dessus, GrandBoss qui est reparti au Luxembourg a été remplacé par MisterHeadBoss. Bref vu que MisterHeadBoss est un ancien de Netscape, je suis passé discuter avec lui à propos d’archéologie de l’informatique : Netscape Applicaton Server, la suite iPlanet, Netscape Directory Server qui était l’un des premiers annuaires LDAP… A l’époque cette suite iPlanet était la meilleur offre pour avoir un serveur web, un annuaire LDAP, un agenda d’entrerpise ou un serveur de certificats.

La phase 2 sera de lui parler de Scrum. S’il veut soigner la bête, il faut changer de médecin et de médicaments. Basculer toutes les équipes n’est pas une bonne idée. Par contre, en parler et mettre en place des actions pour certains projets, à mon avis cela pourrait apporter une bouffée d’air frais à nos développeurs qui tournent en rond comme dans un bocal.

Et vous ? Est-ce que ça scrum ? Comment va la vie ?

Pendant ces 2 jours de formation avec Jeff Sutherland, nous avons couvert les différents aspects de Scrum avec une partie pratique et une partie partagée par Jeff avec son expérience. Scrum est avant tout un framework de développement Agile orienté produit et pas projet. Basé sur la simplicité, sur la transparence et l’efficacité. L’organisation parfaite nous a aussi permis de discuter et rencontrer pas mal de monde puisque nous étions 30 personnes. Suisses, Belges, Luxembourgois et Français.

Déroulement de la formation

Durant ces 2 jours nous avons mis en oeuvre, non sans mal et avec pas mal de rires, les différents ateliers de Scrum. 30 personnes étaient présentes, avec quelques personnes de Xebia. Divisé par table de 6, nous avons effectué différents exercices, l’alternance entre présentation formelle, séance de questions, exercices et pauses cafés étant gérée par Jeff avec un grand sens de l’organisation. En fait son secret était affiché dans un coin de la salle. Il a déroulé les différents points de la formation sous la forme de post-it accrochés au mur. Durant les 2 jours, selon l’avancement, il mettait à jour son tableau en déplaçant ses post-its… Et nous avons tenu le programme sans problèmes, le dernier jour se terminant à l’heure.

Qui était présent à cette formation ? Finalement des personnes de différents horizons. Des français mais aussi des personnes du Luxembourg et de Suisse. Des développeurs, des chefs de projets, des managers opérationnels… les profils étaient variés. Et les échanges ont été très constructifs.

Sur le déroulement de la formation, sans en révéler tous les détails, je dirai que vous repartez avec un bon bagage. Suffisant pour commencer dès le lundi suivant à travailler en tant que Scrum Master. L’objectif est rempli. Finalement Scrum est simple. Il n’y a pas de choses compliquées à essayer de comprendre. Simplement 3 outils de reporting, 3 artefacts, quelques définitions simples… et vous pouvez vous lancer.

Qu’en est-il de la part de « buzz commercial » par rapport à la réalité ? Finalement pour justifier la réussite de Scrum, le plus simple est de regarder les exemples de societés comme Yahoo, Google, GE HealthCare, qui sont passés d’un mode de développement à l’ancienne (Waterfall, RUP) à une méthode Agile comme Scrum. Les chiffres sont là pour répondre aux sceptiques. Et c’est assez impressionant…

Le plus gros du travail maintenant va être d’évangéliser, de proposer et de faire adopter Scrum. Car pour moi il est clair qu’un produit développé dans un mode Waterfall est un produit qui a de fortes chances de se planter. Alors certes, les sceptiques ou les maîtres de RUP risquent de bondir et de me tirer dessus à vue. RUP par exemple définit 27 rôles. Scrum fonctionne avec 3 rôles : Product Owner, Scrum Master et The Team.

CMMI 5 et Scrum, comment économiser de l’argent ?

Un graphe qui m’a marqué : un projet CMMI développé par une entreprise de niveau 1 qui a une productivité de 100, en mode Waterfall, coûte 50% de ce temps en correction de problèmes et 50% en développements innovants.

Une entreprise évaluée CMMI niveau 5 améliore sa productivité et peut réaliser la production d’un logiciel pour 69% d’effort au lieu de 100% auparavant.La correction d’incidents, la réécriture passe de 50% à 10% sur la même échelle grâce au processus d’Optimisation mis en place. La productivité est inchangée, à 50%. Et par contre, 9% de coûts de structures, de gestion des processus s’ajoutent. 9% de l’activité est consacrée à se regarder le nombril pour s’améliorer sans cesse (principe CMMI 5).

Appliquons Scrum dans cette structure et regardons ce qu’il se passe. Au total, l’effort passe de 69% à 35%. Cela veut dire, que pour 2 fois moins d’effort, vous produisez la même quantité de lignes de codes. Les coûts de gestion de processus sont divisés par 2 (4% au lieu de 9%). Les coûts de refactoring passent de 10% à 6%, vous réduisez de 40% le temps passé en correction de bugs, refactoring et bidouillages divers… Enfin la partie production pure passe de 50 à 25. Votre societé a donc doublé sa productivité…

Ces chiffres ainsi que de biens meilleurs explications en anglais se trouvent ici si vous souhaitez en savoir plus.

Et la suite ?

Je compléterai à partir de maintenant en vous faisant partager mon expérience de mise en place de Scrum chez nous… C’est le début d’une longue série de Post je pense.

Photos souvenirs

Sans vous dévoiler pourquoi nous sommes entrain de faire ce château de carte, voici quelques photos prises par Alexander Papanastassiou de Business Quests et par moi-même. Le monsieur avec la chemise noir, c’est Jeff Sutherland.

Jeff présente les consignes du dernier atelier

Avec une velocity assez rapide nous complétons les 3 itérations et terminons même un peu vite. Alexander propose d’essayer finalement de faire l’exercice le plus difficile avec les cartes à jouer… Quasiment impossible.

Jeff Sutherland debout à côté de Guillaume Bodet de Xebia.

Damien trie les tâches du Product BackLog

Changement de tactique: sur une idée de Denis nous utilisons des Post-it pour coller les cartes… et là ça avance vite.

Un des exercices (sorti du contexte les gens vont se demander ce que l’on a fait…). Le monsieur avec le chemise blanche, c’est Cyrille de Xebia.

4 étages !!!

Une photo de Jeff Sutherland

et enfin une petite photo de moi en plein Sprint final, avec la casquette de Scrum Master.

Autres liens

Voir le post sur le blog d’Alex http://blog.businessquests.com/2008/03/done.html

L’article de David Andriana est très clair et vous expliquera ce que nous avons fait pendant ces 2 jours.

Si vous êtes intéressés, les places à la formation partent très vite, donc n’attendez pas, inscrivez-vous sur le site de Xebia. Pour ma part j’ai même utilisé mon DIF (droit individuel à la formation).

J’ai la confirmation que j’assisterai fin mars à la certification Scrum Master avec Jeff Sutherland, organisée par Xebia. Passer d’un mode de développement à l’ancienne (spécifications,codage,livraison,recette) à une méthode Agile comme Scrum, c’est une petite révolution qui se prépare. Pour moi c’est vital. Il nous faut de l’Agilité pour répondre efficacement à la complexité de notre secteur. C’est un peu bateau je l’avoue. Il me faut aussi de quoi évangéliser (car je ne vois pas d’autre mot) les 3 équipes autour de moi, puis ensuite les 4 clients actuels internes qui utilisent notre framework. Par ailleurs nous avons un projet qui sera le candidat idéal pour mettre en application tout cela. J’ai cependant le sentiment que finalement, le plus gros effort sera la partie humaine et la communication. Il va être difficile de faire passer un message et de demander à notre environnement de s’adapter à notre nouvelle méthode. Mais comme disait un grand savant chinois : « Qui n’avance pas… recule ».

Le développement d’un logiciel est finalement assez proche de la croissance d’un arbre. Une branche pousse, des fleurs puis des fruits sortent sur les branches. Parfois la branche est malade, et on tente de la réparer avec un bout de ficelle… alors que finalement il vaut mieux parfois couper net et proprement afin que la maladie contractée par cette branche ne se propage pas à l’arbre tout entier… (je suis le roi de la métaphore de supermarché).

J’ai appris il y a quelques jours que Gustave Eiffel avait construit sa Tour en 26 mois avec à peine 200 personnes. Vous imaginez un Gustave Eiffel ingénieur ? qui dessine ? Pas du tout. Mr Eiffel était à la fin de sa carrière. Plus rien à prouver, 25 ans d’expérience. Par contre un sens de la communication et de la politique ultra-développé. Bref lorsqu’il entend parler d’un projet pour l’exposition universelle de 1889, il se débrouille pour faire gagner son projet au concours organisé par la ville de Paris.

En 1887 il demande à 2 de ses meilleurs ingénieurs de travailler sur les plans (il fait de la délégation) en prenant pas mal de temps pour regarder ce que font les concurrents (veille technologique). Les premiers plans sont prometteurs mais… moches ! Il contacte un architecte afin de demander un dessin qui donne une touche esthétique à son idée de Tour (appel à un prestataire qualifié externe).

Par la suite il subit 2 grèves pendant la construction. A la première grève les ouvriers veulent 40 centimes d’augmentation. Il fait une promesse plus généreuse à 50 centimes s’ils reprennent le boulot… et les ouvriers n’ont rien finalement (exploitation acharnée de prestataires). Deuxième grève, avec cette fois-ci des ouvriers bien décidé à obtenir un peu plus par mois. Il refuse encore mais promet une prime énorme de 100 Fr si le chantier est terminé à temps pour l’exposition universelle de 1889. Les ouvriers, pour le coup vraiment motivés par cette prime, termineront le chantier avec 2 mois d’avance en mai 1889!
Gustave Eiffel payera la prime de 100 Fr (tenir ses promesses et motiver par une prime).

Pour revenir aux méthodes Agile, une chose m’a marqué. Lors de la construction de la Tour Eiffel, Gustave Eiffel avait demandé aux personnes manuelles qui montent la Tour de refuser toute pièce comportant le moindre défaut. Le zéro défaut à la Toyota avant l’heure.

Un journaliste demande à Eiffel :
- « Attendez… vous payez cher ce fer qui vient de Lorraine, vous faites fondre les pièces à Levallois, et si la pièce a un défaut, vous la jetez ? »
- « Oui tout à fait… »
- « Mais pourquoi par exemple ne pas la raccourcir lorsqu’elle est trop longue ? »
- « Vous avez raison… et vous avez tort. Si nous demandons à un monteur manuel de recouper la pièce dans l’urgence, sur les calculs d’un ingénieur sur le site qui sera stressé, qui aura le vertige et froid, pensez-vous que la correction de la pièce sera parfaite ?  »
- « …euh non… et vous ne pouvez pas rallonger la pièce ? »
- « Les monteurs sont des personnes qui sont dédiés à une tâche: assembler les éléments. Les ingénieurs font les calculs et s’assurent que la Tour ne va pas s’écrouler. Donc ce n’est pas au monteur de décider ce qu’il faut faire »
- « Quelqu’un surveille le travail des monteurs ? Qu’ils ne font pas exprès de rejeter trop de pièces ? »
- « Nul besoin. Les monteurs sont fiers d’avoir la possibilité de s’opposer aux Ingénieurs. Et croyez-moi, pour rester crédible ils ne refusent les pièces que lorsque c’est vraiment nécessaire… »
- « … »

Gustave Eiffel venait d’inventer une méthode utilisée ensuite 100 ans plus tard par Toyota pour construire leurs véhicules: le Zéro Défaut.

Et si nous revenons à nos logiciels ? Imaginez parfois un bout de code que vous avez écrit tard comme ce soir pour moi… Vous êtes à 95 mètres du sol, entrain de tailler votre bout de code Java pour le faire tenir tant bien que mal… vous savez que si vous ne mettez pas cette correction, il ne sera pas possible de continuer à monter la suite de votre logiciel…
Le client est en bas qui attend une solution miracle pour traiter de gros volumes…
Alors vous codez, vous sciez, et vous pensez qu’en 1888 s’ils avaient fait comme vous, la Tour serait certainement aujourd’hui une horreur bien couteuse à maintenir. Et pour le coup, ce n’est plus la branche mais l’arbre qu’il faut abattre…

Allez je retourne à la mine.

Faire du code rend humble.

Le principe est simple: tout d’abord vous devez vous inscrire sur le site XebiaPoker.com. Une fois inscrit, vous pouvez commencer à répondre à plusieurs Quizz en Flash sur le thème de Java, J2EE, Scrum ou Hibernate par exemple. Le quizz se déroule dans un temps limité. Croyez-moi c’est bien stressant. Et vous ne pouvez pas recommencer un quizz une fois lancé. Tout ceci pour ne pas tricher et que le système soit equitable. Les bonnes réponses aux différents quizzs permettent d’établir un classement des joueurs. Les 50 premiers se verront inviter pour participer à un vrai tournoi. Etant aussi joueur de poker débutant, je me dis que c’est vraiment une excellente idée.

Je me suis inscrit et j’ai commencé à concourir… je suis 21ème pour l’instant. Il me reste encore 2 quizzs sur Spring et Hibernate pour espérer grimper un peu plus, mais ça va être difficile. Je vais potasser car je ne connais pas Spring par la pratique. J’ai lu un bon nombre d’articles mais j’avoue ne pas avoir eu l’occasion de m’en servir.

Sur le quizz Java niveau 2 j’ai eu un plantage lors de l’envoi d’une réponse, avec affichage d’un message d’erreur… tant pis pour moi.Les quizzs sont limités dans le temps, vous n’avez que 20 secondes pour répondre à chaque question. Et il n’est pas possible de repasser un quizz. Bref c’est bien stressant et très sympathique comme idée.

Si vous êtes intéressés, rendez-vous sur http://www.xebiapoker.com

JavaOne… me (re)voilà !!!