Mathieu

Shared by Mathieu
GB c'est pour toi

Dans notre série des accessoires iPhone et iPod Touch, on en a vu des supports de toutes tailles et de toutes les matières, mais un comme le iPlunge, jamais encore !

Plutôt qu'un long discours, le voici en image, vous allez comprendre !

Il ne coûte que 6 $ ici (il faut voir les frais de port après par contre).

Vous aimez ?

Parcourir les nombreux accessoires iPhone et iPod Touch référencés par iPhon.fr.

Suivez iPhon.fr sur Twitter, sur Facebook, via RSS, sur le site mobile de iPhon.fr ou avec l'application dédiée iFon.fr

Source

High off Baltimore Pandemic and Yellow Tops, I believe we promised a release candidate shortly after RailsConf. As things usually go in open source, we gorged ourselves on fixes and improvements instead. But all to your benefit. We’ve had 842 commits by 125 authors since the release of the last beta!

Now it’s time to just say good is good enough, otherwise we could keep on with this forever. So please welcome the Rails 3 release candidate! You install, as always, with gem install rails --pre.

Most of the fixes have been of minor significance, but we did manage to dramatically speed up Rails 3 development and startup speed for larger applications (Basecamp went from insufferable to about 2.3 levels of enjoyment).

Speed is now pretty good across the board except for part of Arel that Active Record now depends on. We’ll be making sure we get performance of Active Record back to at least 2.3 levels before release.

A few more highlights:

• Support for the MySQL2 gem, which will take care of MySQL encoding issues on Ruby 1.9.2.
• Shallow routes are back.
• Fixed the autoload issues
• Made the rails command work even when you’re in a subdirectory
• Dealt with a variety of web encoding issues

Indulge yourself in the delights of all the glorious details from the commit logs or checkout the slightly less pedantic summaries in the CHANGELOGs.

This release candidate of Rails 3 also concides with the release candidate of Bundler 1.0. Huge strides were made with Bundler and it should both be much faster and have most of the edge cases sawed off.

I’ve said “we’re almost there” so many times that I’m almost exhausted. But really, guys, WE’RE ALMOST THERE!!!¹

¹ Just a few weeks before final is out?

Shared by Mathieu
nice !

L’échange de données vectorielles entre SIG hétérogènes est actuellement à peu près correctement maitrisé (via des formats de fichiers communs – shapefile, KML, GML par exemple – ou des protocoles spécifiques – WFS notamment). On ne peut pas en dire autant de l’échange des styles graphiques à appliquer aux données. Il manque encore dans ce domaine un standard reconnu et implémenté par la majorité des solutions logicielles. Il existe bien Symbology Encoding de l’OGC (dérivé de Style Layer Descriptor) mais on ne peut pas dire que son adoption soit généralisée ou tende à l’être. Les principaux reproches que l’on peut faire à Symbology Encoding :

• sa verbosité (héritée de celle de XML) ;
• sa relative complexité (reproche que l’on entend régulièrement à l’endroit des travaux de l’OGC) ;
• ses écarts par rapport à la modélisation des représentations cartographiques élaborée par l’ISO TC211 (cf. ISO 191171 – Geographic information — Portrayal)

Selon moi, le principal défaut de Symbology Encoding réside dans ses capacités restreintes à gérer des représentations graphiques complexes. Les représentations spécifiques de certains métiers (informations tactiques des militaires, cartes météorologiques et océanographiques, cartes géologiques par exemple) atteignent facilement ces limites. Symbology Encoding n’est pas non plus adapté pour produire des cartes incluant des graphiques (camemberts et histogrammes notamment). C’est la raison pour laquelle des travaux sont régulièrement entrepris pour essayer d’améliorer les capacités de ce standard. Par exemple : le projet européen Orchestra et, du côté de l’OGC, le groupe de travail MetOcean, le test-bed OWS-6 et le groupe de travail SLD.

Globalement, on ne peut pas dire que Symbology Encoding progresse très vite. Certains n’attendent pas que les organismes de standardisation avancent et étendent les standards pour les adaptés à leurs besoins. C’est le cas de GeoServer qui a intégré quelques extensions maison (cf. SLD Extensions in GeoServer).

Une autre initiative de la communauté géospatiale libre est également en cours : MapCSS. Il s’agit d’un langage déclaratif de styles cartographiques inspiré du format CSS (format utilisé pour définir les styles de pages web). MapCSS fait suite à différents travaux menés de droite et de gauche pour utiliser des styles CSS pour produire des cartes : Styling GeoServer Layers with CSS, Cartagen – GSS et Cascadenik.

Il ne faut pas forcément s’attendre à ce que MapCSS soit une alternative plus prometteuse que Symbology Encoding en termes de capacités graphiques. Non, MapCSS est plutôt une alternative basée sur un standard très largement répandu (CSS) qui a l’avantage d’être plus compact, d’être plus lisible que Symbology Encoding et d’être plus familier pour les développeurs de sites web.

MapCSS en est à ses débuts et il n’est pas sûr qu’il bénéficie d’un engouement suffisant pour qu’il sorte réellement de l’anonymat et devienne quelque chose de moins confidentiel. On peut néanmoins constater que les choses avancent vite :

• un groupe de discussion s’est mis en place au sein de l’OSGeo pour faire progresser la définition de MapCSS (cf. ici). Il semble plus actif que le groupe SLD de l’OGC ;
• des implémentations de MapCSS existent déjà (cf. là). Parmi ces implémentations on peut noter Potlatch2 (la future version de l’outil de saisie en ligne d’OpenStreetMap – cf. ici et là). Si vous souhaitez tester en ligne MapCSS, je vous invite à essayer Halcyon (qui utilise le même moteur de rendu que Potlatch2).

Une initiative à surveiller donc.

Since this post got quite popular I decided to incorporate some of the excellent suggestions posted in the comments, so this list now has more than 30 books in it.

Learning a new programming language always is fun and there are many great books legally available for free online. Here’s a selection of 30 of them:

Lisp/Scheme:
How to Desing Programs
Let Over Lambda
On Lisp
Practical Common Lisp
Programming in Emacs Lisp
Programming Languages. Application and Interpretation (suggested by Alex Ott)
Structure and Interpretation of Computer Programs
Teach Yourself Scheme in Fixnum Days
Visual LISP Developer’s Bible (suggested by skatterbrainz)

Ruby:
Data Structures and Algorithms with Object-Oriented Design Patterns in Ruby
Learn to Program
MacRuby: The Definitive Guide
Mr. Neighborly’s Humble Little Ruby Book (suggested by @tundal45)
Programming Ruby
Ruby Best Practices
Ruby on Rails Tutorial Book (suggested by @tundal45)

Javascript:
Building iPhone Apps with HTML, CSS, and JavaScript
Eloquent Javascript
jQuery Fundamentals

Haskell:
Learn You a Haskell for Great Good
Real World Haskell

Erlang:
Concurrent Programming in Erlang
Learn You Some Erlang for Great Good

Python:
Dive into Python
How to Think Like a Computer Scientist – Learning with Python

Smalltalk:
Dynamic Web Development with Seaside
Pharo by Example (based on the next book in this list, suggested by Anonymous)
Squeak by Example

Misc:
Algorithms
The Art of Assembly Language
Beginning Perl
Building Accessible Websites (suggested by Joe Clark)
The C Book
Compiler Construction
Dive Into HTML 5 (suggested by @til)
Learn Prolog Now!
Objective-C 2.0 Essentials
Programming Scala

Of course there are many more free programming eBooks, but this list consists of the ones I read or want(ed) to read. This is far from comprehensive and languages that are completely missing are mostly left out on purpose (e.g. PHP, C++, Java). I’m sure somebody else made a list for them somewhere.

Shared by Mathieu
Pourquoi, pas comment : la vidéo
Martin Fowler, Thoughtworks
Neal Ford, ThoughtWorks

2ème partie consacrée à la Keynote de Martin Fowler et de Neal Ford après l’introduction consacrée à la plannification.

Neal Ford, Crédit photo : USI 2010 album sur Flickr.com

De l’importance de la communication
Après cette première partie, Neal Ford nous parle maintenant de la communication. Plus importante que la technologie, nous allons voir que la communication est l’un des points clés pour réussir des projets.

Neal demande à la salle si nous avons déjà fait partie de projets qui se sont plantés. Rires, quelques mains se lèvent. Il demande ensuite si la raison de l’échec était le mauvais choix d’une technologie, ou une mauvaise communication ? L’ensemble répond : la communication.

Il est donc plus facile de planter un projet car vous communiquez mal, que parce que vous avez pris un framework exotique au lieu de prendre un framework standard.

Les projets se plantent souvent à cause des gens. La communication entre les gens devient très importante. Nous sommes des créatures massivement communicantes. Notez qu’en prison, la plus grosse punition est d’aller au mitard. De ne plus pouvoir communiquer avec d’autres humains… Dingue non ? Pensez aussi aux gens que l’on met « au placard »… Nous avons besoin de communiquer. C’est vital.

Alistair Cockburn explique dans un graphe que la qualité de la communication avec les outils modernes est très inégale.

Pour travailler, nous sommes bien plus efficace devant un tableau blanc qu’au téléphone, ou même pire, via un document Word. Le pire des processus de communication est le papier écrit. Et le drame, c’est que c’est l’un des plus utilisés dans les Entreprises. C’est marrant, mais la semaine dernière je suis allé chercher un grand tableau blanc pour notre équipe, et je l’ai installé dans notre bureau… Croyez-moi cela marche.

Neal Ford explique que c’est pour cette raison, qu’il est illusoire de croire qu’une spécification technique envoyé à des développeurs en Inde donnera le logiciel escompté. C’est une perte de temps et d’argent. Cela ne fonctionne pas.

Cela va plus loin. Nous avons même une capacité limitée à communiquer et faire autre chose en même temps. Vous ne vous êtes pas demandé pourquoi il est dangereux de téléphoner et conduire en même temps ? Pourtant vous avez le droit de parler avec votre voisin, vous pouvez écouter la radio, mais on vous interdit de téléphoner en même temps. Or pour ceux qui ont essayé (moi le premier) vous vous rendrez compte que la communication au téléphone est moins bonne que lorsque vous avez la personne à côté de vous. Cela vous demande même un effort plus important pour comprendre. Et cet effort vous déconcentre de la route. C’est bien là la preuve que les canaux de communications demandent plus ou moins d’efforts.

Un document écrit est aussi très destructif, car la possibilité de donner son retour n’existe pas ou peu, par rapport à une communication face à face. Bien entendu, ces documents sont souvent écrits à la suite de réunions, où nous nous sommes vus… Mais souvent le développeur n’aura pas eu l’opportunité de discuter avec le client, et de poser quelques questions simples. Il est donc primordial pour réussir un projet de prendre en compte ce facteur de communication.

Le manifeste Agile propose 4 valeurs clés, dont l’une est exactement ce que Neal Ford vient d’expliquer.
Les quatre valeurs fondamentales Agiles sont :
– Davantage l’interaction avec les personnes que les processus et les outils.
– Davantage un produit opérationnel qu’une documentation pléthorique.
– Davantage la collaboration avec le client que la négociation de contrat.
– Davantage la réactivité face au changement que le suivi d’un plan.

Voir l’article original en Anglais : http://agilemanifesto.org/

Neal Ford présente ensuite un projet supporté par ThoughWorks au Malawi. Ce projet permet à des infirmières de transmettre via SMS des bilans de santé, alors que les moyens de communications sont très mauvais, et que la vie est très dure. Ce projet RapidSMS, est un projet open-source réalisé pour l’UNICEF en Python.

La communication dans ce projet est vitale, et elle permet de sauver des vies.

Le Feedback
Martin Fowler attaque maintenant la deuxième partie de sa présentation. Pourquoi certains projets réussissent bien ? Il souhaite nous parler de l’importance du retour d’information, le feedback en Anglais.

Martin nous montre une photo d’un gâteau. Réalisé avec une approche prédictive, tout le monde sait qu’il faut respecter la recette en cuisine pour réussir. Ma grand-mère me disait de mettre 75g de farine, et de ne pas poser de questions. La cuisine est une alchimie intéressante. Si vous avez une recette pour 4 et que vous voulez faire un gâteau pour 8, il ne faut pas doubler les quantités. En effet, lorsque vous doublez les quantités, vous avez toutes les chances de planter votre gâteau. Curieusement, la cuisine est bien plus compliquée que ce que nous pensons. Et bien le développement logiciel, c’est pareil. Il ne sert à rien d’ajouter 2 développeurs en pensant que vous irez 2 fois plus vite. Parfois même, vous irez 2 fois moins vite, car il faudra former ces nouveaux arrivants…

Martin nous montre une photo de gâteau donc, et une photo de pomme de douche. Quelles différences y-a-t-il entre une pomme de douche « chaud-froid » et un gâteau ? Et bien une histoire de retour, de feedback.

La cuisine est un processus défini alors que régler une douche est un processus adaptatif/empirique.

La cuisine suit un plan précis, une recette. Et le feedback ne sera fait qu’à la fin. Peut-être que votre gâteau sera raté, peut-être qu’il sera excellent, vous ne le saurez qu’à la fin. Au contraire, si vous prenez une douche dans un Hôtel, et que vous devez régler la température, vous allez utiliser un feedback permanent pour adapter la température. C’est l’approche Agile.

Cette illustration nous permet de comprendre qu’il existe 2 types de processus, et que cela fait partie de notre vie quotidienne. Dans le cas d’un processus empirique (la douche) nous examinons le résultat final pour adapter le signal d’entrée. Dans le cas d’un processus défini, si je suis la recette à la lettre j’aurai toujours le même gâteau, je serai capable de reproduire à l’identique la même chose.

Or chaque développement de chaque projet est différent et donc l’approche prédictive ne semble pas une bonne chose. Par contre pour mélanger des ingrédients chimiques dans une usine, vous serez d’accord qu’un processus défini est primordial, pour des raisons de sécurité. Pour le développement d’un logiciel, Martin Fowler nous demande de bien réfléchir avant de choisir une méthode de développement.

Si vous prenez l’approche empirique (la douche) pour construire votre logiciel, il est donc très important de mettre en place un système de feedback. C’est pour cette raison que les équipes Agiles s’installent des murs de post-it, des Kanban, des indicateurs visuels et toutes sortes de trucs sympas : pour avoir du feedback disponible à tout moment.

Martin Fowler montre la photo d’un immeuble de 20 étages en Chine. On voit qu’au 15ème, les fenêtres sont couvertes de post-it. C’est l’étage de ThoughWorks, facilement identifiable de la rue… Rires dans la salle.

L’intérêt d’un Kanban est que ce tableau est lisible par tout le monde. Ecrit clairement, il donne une vision de l’avancement du projet. Tout le monde peut y participer, et donc doit pouvoir y accéder facilement.

Feedback sur la construction du logiciel
Martin Fowler insiste ensuite sur l’importance de donner un indicateur sur l’avancement de la construction du logiciel. Nous devons savoir où nous en sommes en terme de développement du logiciel.

L’intérêt d’afficher sur le mur le planning de son projet est primordial. Martin Fowler explique qu’il lui arrivait auparavant d’aller dans des équipes de développement, et de constater que les développeurs n’avaient pas accès au planning global du projet. Mettez en place un tableau avec les prochaines semaines de développement, cela permettra de donner plus de visibilité et donc de sens, au travail de chacun.

A propos des outils électroniques, les équipes de développement préfèrent utiliser un vrai tableau plutôt qu’un logiciel. Je confirme : ne vous jetez pas sur un outil, privilégiez une solution simple à base de post-it et de fiches bristols. Cela fonctionne très bien.

Dans ce qui est de donner du feedback, Martin rappelle que le seul moyen de voir un progrès dans le développement d’un logiciel, c’est d’avoir un logiciel qui marche. Cela veut aussi dire, un logiciel déployé et testé.

Le processus de construction de votre logiciel est très important. Certains projets aiment bien utiliser des Lava Lampes rouges ou vertes pour signaler que la construction du logiciel fonctionne, ou non. A titre personnel, j’ai mis en place cette pratique à la BNP il y a un an et nous avions une Lava Lampe rouge que nous allumions pour signaler un « Build failed ». C’était sympa.

Neal Ford parle ensuite de CCBoard, un tableau de bord de construction de projets. Ce logiciel open-source permet d’afficher le status de toutes vos builds.

Faire de l’intégration continue c’est compiler, tester, packager, déployer, retester et valider un logiciel. Cela demande un effort, qui permet cependant de réduire à zéro l’effort de « release » d’un logiciel. Si vous êtes capable de construire à tout moment votre logiciel, et de le packager, vous comprendrez que faire « une release » devient facile.

A propos des pratiques de développement logiciel, Martin Fowler parle du Pair Programming. Il a été observé que lorsque 2 développeurs travaillent en même sur un écran, les deux n’utilisent pas la même partie de leur cerveau. Celui qui tape le code sur le clavier est dans la réalisation, alors que celui qui est assis à côté est dans la réflexion, la beauté du code et la vision globale. Celui qui code est le pilote, et celui qui est à côté est le navigateur. Cela permet de réaliser du code de meilleur qualité.

Martin utilise l’image d’un jardin de la Renaissance, tiré d’un château de la Loire. Puis ensuite l’image d’un jardin tropical, tiré d’un parc en Angleterre. D’un côté l’ordre, la clarté. De l’autre le chaos, le foutoir apparent. Et pourtant ces 2 jardins sont beaux. Ils correspondent à deux approches : l’une procédurale, l’autre artistique. Tout ceci pour illustrer qu’il faut des deux pour faire un monde. Et il nous encourage à mélanger ces 2 approches lorsque nous codons, en faisant du Pair Programming par exemple.

Dernière partie
« La perfection n’est pas ce que nous visons, mais ce que nous faisons à tout moment ». Cette phrase de Kent Beck résume l’approche eXtrem-Programming, où l’on fait de tout, mais très bien et en permanence.

L’introspection est alors important. Chaque semaine, l’équipe doit réfléchir et s’assurer de s’améliorer en permanence. Si une équipe ne change pas ses pratiques régulièrement, et qu’au bout de 12 mois vous la retrouvez dans le même état, c’est qu’elle a cessé de progresser. Et c’est un indicateur qu’il manque peut-être des pratiques de rétrospectives.

Neal Ford ensuite à propos de la communication et du retour, nous raconte un peu ses expériences passées. Dans les équipes de développement qu’il a croisé, il a remarqué que les équipes aiment bien laisser trainer des petits jeux, des casse-têtes ou des Rubbik’s Cub. Cela permet en fait de décompresser et de mobiliser d’autres parties du cerveau. Il y a 5 ans, je me souviens que nous avions un petit panier de basket, et que nous faisions des tournois, histoire de lever le nez du code de temps en temps…

Neal Ford dit clairement que mettre des développeurs face à un mur pour coder, n’est pas une bonne idée. Il faut stimuler leur créativité. Il y a des entreprises qui mettent en place des règles et qui vous interdisent d’afficher des photos personnelles, des posters de cinéma, ou de vous balader en tee-shirt « My bozz rebooted » dans les couloirs… Pensez à ces photos des locaux de Google, où à l’excès inverse, les gens peuvent avoir un peu tout et n’importe quoi dans leur espace de travail… La notion de « Cubicle » est cependant très américaine, et c’est un aménagement de bureaux peu utilisé en France.

Ce qu’il faut retenir, c’est qu’il important de traiter les développeurs comme des créatifs. Ils doivent pouvoir aménager leur espace de travail librement. Mettez des tableaux blancs, laissez-les s’installer et s’approprier leur bureau. Si vous n’avez que des prestataires qui viennent de SSII, croyez-moi c’est possible. Nous avions une lava-lampe, j’avais acheté une petite plante verte, nous avions nos posters Scrum, le tout en évidence à côté de la cafétéria, et personne ne nous a jamais dit d’arrêter.

A propos de la construction des logiciels, Neal Ford raconte une histoire sympa. Dans une des équipes où il a travaillé, le logiciel d’intégration continue joue une petite musique de 3 secondes lorsque la compilation fonctionne. C’est très pratique, car cela permet de vous signaler que vos derniers commits fonctionnent, sans vous déranger. Vous entendez vos 3 secondes de musique, et vous pouvez continuer. Chaque développeur avait sélectionné une chanson ou un bruit, et donc pouvait savoir que son commit était passé. Sympa non ?

Ensuite, lorsque le build cassait, une autre chanson se mettait en marche. Dans son équipe c’était « Oups I did it again ! » de Brittney Spears. Et d’entendre cette chanson mettait une bonne ambiance. Toute l’équipe se mobilisait pour aller réparer le logiciel immédiatement.

Neal Ford montre ensuite une photo d’une équipe de développement. On voit une énorme peluche de Kangourou assise sur le fauteuil à côté du développeur. Celui qui a le « Stuff Kangoroo » est responsable du build pour la journée. Lorsque la chanson de Brittney se met en marche, son travail est alors de chercher le développeur et de s’assurer que le logiciel est réparé rapidement. C’est un peu un rôle barbant, donc ce rôle tourne. Et celui qui a cassé le build récupère alors le « Stuff Kangoroo ». Et ainsi de suite…

Notre travail peut être amusant, et sérieux. Derrière cette peluche « pas sérieuse » il y a une pratique très précise de génie logicielle, celle de fixer tout de suite la construction du logiciel. Et ça marche ! Alors n’hésitez pas à aller chez Toyr’us et d’acheter un énorme Ours en peluche, et de le donner à l’équipe de développement. J’ai repéré une peluche de « Sully » du dessin animé « Monstres et compagnie » et je compte bien l’embarquer pour notre projet actuel.

Neal Ford montre enfin une page de Wiki généré automatiquement par l’outil de construction, sur laquelle les développeurs peuvent aussi écrire. Ce carnet de bord quotidien raconte la journée passée. A quelle heure Nicolas a commité son code… a quelle heure la compilation s’est terminée, puis les tests. Ensuite on voit que Pierre a annoté la page et qu’il a marqué un détail sur l’installation… Bref un carnet de bord, comme en marine, mais généré en partie automatiquement.

Conclusion
En conclusion, Neal Ford reprend la question du départ : « Pourquoi le développement Agile fonctionne-t-il si bien ?« . Et bien grâce au Feedback, grâce à la communication, et aussi parce que nous percevons le métier de développeur différemment. Nous pensons que la réflexion est aussi importante que la réalisation. Et nous pensons aussi que le développement est fun !

Crédit photo : USI 2010 flickr.com – Tous droits réservés
Martin Fowler et Neal Ford ouvrent cette deuxième journée de la conférence USI 2010. Deux des plus célèbres des Geeks pour commencer la journée… Avouez que cela vaut le coup non ? Leur présentation nous propose de comprendre non pas comment, mais pourquoi des logiciels fonctionnent… Suivez le guide.

Avant tout, je présente rapidement les deux speakers. Martin Fowler est d’origine anglaise, c’est un geek de 47 ans qui a participé au Manifeste Agile, a co-écrit des livres d’excellentes qualités sur le refactoring avec Kent Beck, et c’est surtout un conférencier de renom. Neal Ford est américain, Geek de 48 ans, passionné par la technologie, auteur de plusieurs livres comme l’excellent « The Productive Programmer« , il travaille aussi chez ThoughtWorks avec Martin Fowler.

Neal Ford débute la présentation en nous apostrophant, afin de nous demander si nous savons pourquoi certains logiciels marchent, pas comment ils marchent. Martin Fowler explique qu’une phrase anglaise célèbre dit : « Plan your work, work your plan« . Cette approche prédictive est intéressante. Un plan est une prédiction de ce que l’on souhaite, plutôt une prévision. Et pour aller plus loin, le succès d’un projet dans ce cas, serait de dire que vous avez respecté votre plan à la lettre. Le succès des projets est défini sur la base d’une prévision. Cette approche prédictive est intéressante dans certains domaines, mais elle doit être discutée lorsque l’on parle de développement logiciel. Elle ne fonctionne que si vous êtes en mesure de préparer un ensemble clair et indiscutable de demandes, et que cet ensemble n’évolue pas dans le temps.
Reconnaissez tout d’abord que c’est difficile. Il est assez difficile de tout prévoir, et de tout planifier. Et ce, d’autant plus que le projet est long.

Martin demande aux chefs de projets qu’il rencontre, si les exigences sont stables. Et c’est plutôt rare. Un sondage dans la salle remplie de près de 500 personnes montre aussi qu’en général, les demandes évoluent ou sont précisées alors que le développement a débuté. Presque personne n’a de demande stables. La communauté de l’approche traditionnelle le sait très bien. Alors ils cherchent à stabiliser et à figer les requierements. Ils mettent un point d’honneur à vous rendre la vie difficile si vous souhaitez changer quelque chose.

Dans le monde Agile, nous savons que le changement est une composante du développement logiciel. Cela nous permet de nous en servir comme d’un avantage, plutôt que de le subir. Nous avons développé des techniques pour absorber le changement, tout en délivrant le logiciel. La première de ces techniques, est de séparer la phase de recueil des exigences, de la phase d’implémentation. Pour parler de Scrum, nous avons une étape de capture des requierements, c’est l’alimentation du Product Backlog. Et nous avons par ailleurs un cycle de développement, qui travaille sur un périmètre stable. Vous voyez que nous avons bien besoin de figer à un moment donné les demandes, mais nous le faisons sur une petite période de 2 à 3 semaines.

How do we do this ?
Nous passons d’une approche prédictive à une approche adaptative. Le secret de l’Agilité c’est que l’on ne peut prévoir tout, mais que par contre on sait s’adapter. D’où ce mot « Agile » finalement. Faire de l’Agile ce n’est pas jeter des plannings. Au contraire, nous serons en mesure de donner un planning chaque semaine. Nous serons en mesure de prédire avec précision les 2 semaines qui arrivent.

Ensuite, pour réussir il ne faut pas uniquement appliquer des méthodes Agiles et penser que cela va réussir. Il faut absolument prendre de bonnes pratiques de programmation. Tests unitaires, intégration continue, refactoring, vous les connaissez tous je pense. Martin propose de relire un papier publié il y a 10 ans, remis au goût du jour en 2004, que chaque Architecte Agile devrait connaître : « Is Design Dead ?« . Faire de l’Agilité ce n’est pas jeter le Design à la poubelle. Au contraire.

Martin Fowler raconte qu’il va parfois dans certaines entreprises qui sont passées d’une approche classique à une approche Agile. Et les projets ne réussissent pas mieux. L’Agilité permet même de se planter plus vite en fait. Il rappelle l’importance des techniques de programmation et de développement telles que celles de l’eXtreme Programming. Faire de l’Agile sans changer sa méthode de travail ne permet pas de réussir mieux. A méditer lorsqu’un consultant de 19 ans de McKissé vous vend de l’Agilité… alors qu’il n’a jamais programmé.

Donc pour résumer cette première partie : passez de l’approche prédictive à l’approche adaptative.

La seconde distinction
Une photo de Taylor nous rappelle qu’au XXe siècle la vision du Taylorisme visait à séparer l’exécution d’une tâche de sa définition. Ecoutez bien ce qui va suivre, moi j’ai adoré. Il y a 100 ans, nous pensions que pour être plus effectif, il fallait que des gens pensent à ce qu’il faut faire, et que d’autres réalisent cette tâche. C’est le métier d’Ingénieur ou d’Architecte, ce métier où tu penses à ce qu’il faut faire. Mais dans le développement informatique, nous avons juste oublié la partie « réalisation », la partie « artisanale ». Et c’est pour cette raison que de très bons scientifiques, en mesure de penser, sont de très mauvais exécutants. Personne ne leur a appris à programmer.

Vous savez pourquoi il faut le faire, mais vous ne savez pas comment faire…
N.Martignole

L’approche traditionnelle du développement logicielle essaye de séparer ceux qui conçoivent de ceux qui réalisent. Cette vision fonctionne si les gens qui réalisent sont prévisibles. S’ils suivent à la lettre le processus standardisé, comme un ouvrier finalement, oui cette approche devrait marcher. Alistair Cockburne explique que les gens ne sont pas prédictibles :

In the title, [of his article] I refer to people as « components ». That is how people are treated in the process / methodology design literature. The mistake in this approach is that « people » are highly variable and non-linear, with unique success and failure modes. Those factors are first-order, not negligible factors. Failure of process and methodology designers to account for them contributes to the sorts of unplanned project trajectories we so often see.
[Alistair Cockburn non-linear]

Dans l’approche traditionnelle, nous pensons que les processus vont nous aider. Cela va plus loin, car certaines approches (Model Driven Architecture) proposent de retirer la possibilité de développer, pour plutôt générer du code. La génération automatique de code permettrait d’économiser du temps. Cette approche essaye de combattre le caractère imprévisible de l’être humain. Générer un logiciel par modélisation c’est mettre un terme au chaos de la programmation classique.

Je pense à titre personnel que l’approche MDA permet de déplacer la complexité, mais qu’elle ne peut pas être une solution pérenne pour développer des projets de bout en bout. Lorsque nous aurons compris que la programmation d’un logiciel complet ne peut pas être automatique, nous aurons fait un grand pas.

Les développeurs sont donc les personnages les plus importants dans le développement logiciel. Or ils ne sont pas prévisibles, il est donc stupide de voir les gens comme des ressources. L’utilisation du jour/homme fait beaucoup de tord à notre industrie. Je connais personnellement des personnes qui font en 1 journée ce que d’autres font en 20 jours. Et je me mets dans les 20 jours. Et inversement, je peux faire des choses en 1 journée qui demanderaient 20 jours à un autre développeur. Nous ne sommes pas égaux devant les problèmes de programmation. Nous ne pouvons donc pas prévoir la fin d’un projet en divisant le nombre de jours par la « quantité de ressources disponibles« . Mettez-vous cela dans le crâne une fois pour toute.

Alors comment cela fonctionne-t-il ? Martin Fowler explique que nous devons prendre un groupe de développeurs, mettre en place quelques règles, puis ensuite s’adapter et faire des rétrospectives afin de progresser. Il est contre-productif d’utiliser des processus et de la standardisation, cela tend à niveler par le bas les niveaux des équipes.

People comes first, and they chosse their own process they follow, not the opposite.

En résumé, Martin Fowler a parlé de l’attitude par rapport au planning, et de l’attitude par rapport aux gens.

Fin de la première partie
Retrouvez la suite de cette KeyNote dans un deuxième article demain

This astronaut photograph shows the southern end of Paramushir Island after a snowfall. Four volcanic centers are brightly lit on their western slopes and deeply shadowed to the east.

Shared by Mathieu
iPhone4 made video :-)

Tous ceux qui ont eu des iMac G5 de première génération se souviennent de l'affaire des condensateurs défectueux. A l'époque de leur fabrication, un fabricant majeur de condensateurs avait vendu des centaines de millions de produits défectueux qui s'étaient retrouvé un peu partout dans des produits électronique. Dans les ordinateurs où ils étaient particulièrement sollicités (chaleur et courant important), ils ont commencé à claquer en série. C'est arrivé aux iMac G5. Apple avait à l'époque fait un rappel pour échanger sous garantie étendue les cartes mères en panne.
Dell aussi a été touché par ce problème sur 12 millions de machines. C'est sa gestion de la crise qui provoque aujourd'hui un scandale. La société aurait continué à vendre les machines en question tout en sachant que le taux de panne à 3 ans était de 97%. Lors des réparations, ils remettaient les mêmes pièces défectueuses (remarquez, Apple aussi) ne faisant donc que donner un sursis à une mort planifiée. 
Sachant comment la justice fonctionne aux Etats-Unis, Dell risque de devoir payer une forte amende, mais aussi dédommager 12 millions de clients. La société n'étant plus ce qu'elle était il y a 5 ans, elle va le sentir passer.
Pour ceux qui ont de la mémoire, Dell devrait peut-être vendre ses actifs et rembourser avec l'argent ses actionnaires. 

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover & Adewale Oshineye

There are some books that I wish were available 4 years ago when I first started working in the software development world, maybe even before I went to college. This book is definitely one of them. It’s not an easy task to concretely outline the practices that are helpful towards improving one’s skill as a software developer but this book does it well as Dave and Ade speak about their experiences as apprentices and how they grew to be journeymen.

I will point out the patterns that resonate the most with me and my quest to be a better developer.

1. Expose Your Ignorance
Context of the problem: Your team/clients/managers are expecting you to know what you’re doing and deliver value to the team but you’re unfamiliar with some of the required technologies or the domain of the project.

This situation happens to me on quite a regular basis every time I switch to a new project. It’s one thing to not know the domain of the application, it’s another to not be comfortable or familiar with the language or tools that are used on the project. When I started my first project at ThoughtWorks, I remember taking about 3-4 months to get up to speed and learn all the right questions to ask when working on a story. I have reduced that learning curve period since then, but it has always been a challenge to have to deliver on my first day on a new project.

Suggestions from the book:

• Show your team and managers that the learning process is part of delivering software.
• Get used to learning. Craftsmen will have to work with different technologies and domains over the course of their career. Those who stick to just one domain/technology are called experts. Expertise is not the goal of the apprentice.
• The most important trait of a craftsman is the ability to learn, identify an area of ignorance and working to reduce it.

2. Confront Your Ignorance
Exposing your ignorance will be of no value if you don’t do anything about it. There will always be tools and techniques that you need to learn and master and you have to start somewhere.

I usually do the following:
- read documentation, APIs and FAQs
- if it’s open source, attach the code so it’s easier to look at what’s going on

Things I should really do more of:
- write a scratch application to use the new tool/library
- actually dive in to the code, if there is any

Things I am currently trying to do:
- start from scratch and learn about a language from the ground up. I recently picked up the book C# In Depth by Jon Skeet to learn about the innards of C# starting with C#1 onwards to C#3. I also was reading Programming Clojure by Stuart Halloway (but sadly that has been pushed to the wayside).

3. Be The Worst
Some people find it discouraging when they realize that they are the least experienced person on their team. I, however, find that exhilarating because I know the opportunities for me to learn will be endless. Being the worst on your team shouldn’t disheartened you, but it should push you to work harder than anyone else because the goal is not to stay the weakest, it is to work your way up.

Enthusiasm and passion can be contagious and I have my coworkers at ThoughtWorks to thank for always pushing me to learn more and be better, either explicitly or implicitly.

4. Kindred Spirits
The journey to becoming a master craftsman can sometimes be a lonely one depending on the people who work with you and the work culture that you’re in. It is very disheartening if your efforts to learn new tools, or languages or platforms isn’t supported by your manager just because “it’s the company mandate that we only use X, Y, Z products and open source tools aren’t allowed“. You need to surround yourself with people who are like-minded about learning and that can be achieved via user groups, mailing lists, etc.

My kindred spirit is in the form of Mark Needham, who is a friend and a coworker at ThoughtWorks. We discuss about everything from what’s the best build tool to use in the .Net world, to why is it so hard to change the way people work. He is constantly challenging me to explore things further like diving into the code for Rhino Mocks to understand how things are done behind the scenes.

5. Expand Your Bandwidth
You have built up a set of skills. You are comfortable doing what you’re doing now and hope things doesn’t change so you don’t have to set foot in unknown territory again.

It’s easy to get comfortable with what you know and ignore what you don’t. But unless you want to do the same thing over and over again for a long time (which is quite impossible in software development these days), there will always be new languages to learn, new tools to use, new methodologies to get used to. I don’t think we can afford to rest on our laurels in the software development world. Things change so frequently and there is always so much to learn.

Tip: Read books, read blogs. Read, read, read.

Other patterns that I think are useful:
6. Breakable Toys – use your favorite tools to build a simple application of your choice. Most work environments don’t allow for failure and experiments so you need to create a safe environment where you can do just that.
7. Use The Source – Seek out code and read it. A lot of the tools we use nowadays are open source so the code is readily available.
8. Record (and Share) What You Learn – I use this blog as a tool to record my learnings and as a platform to share them with others and to solicit feedback from them.

I highly recommend this book to anyone who is seeking to learn how to improve their skills as a software developer.