Archives de catégorie : Phase Apprentissage

image

The Siren of Shame

J’aime utiliser des gadgets en entreprise. L’objectif de ceux-ci est d’apporter un côté ludique qui permet de faciliter le travail de l’équipe tout en dédramatisant les choses.

C’est donc avec grand plaisir que j’ai découvert la “Siren Of Shame”.

Ce gadget est en réalité constitué de deux parties :

  • L’élément visible qui est le gyrophare USB qui s’installe en 1 clic de souris
  • Un outil de monitoring qui est capable de se connecter aux principaux serveur d’intégration continue du marché (TFS, Team City, Cruise Control.net, etc.)

L’objectif est simple : alerter de manière visuelle et sonore dès qu’une build est cassé pour la réparer au plus vite.

image

L’installation du logiciel se fait de manière très simple et la configuration est également aisée. En 5 minutes, le système est fonctionnel et nous sommes capables de tester les différents styles de lumière (gyrophare tournant, fondu de lumière, etc.) et de définir jusqu’à quand nous souhaitons avoir les signaux sonores et lumineux (signal pendant un laps de temps défini ou jusqu’à ce que la build soit réparé, etc.).

L’outil propose de plus 3 fonctionnalités intéressantes :

  • Un tableau de bord permettant de voir l’état de toutes les builds
  • Un outil de réputation qui permet d’avoir une liste triée des développeurs selon un ratio nb de buils/nb de builds échouées
  • Un graphique simple d’analyse de l’état d’une build

image

Un outil donc fort simple, qui fait uniquement ce qu’on lui demande sans trop de fioritures.

Avant de vous décrire mon retour d’expérience du système (cela fait un mois que nous l’avons à présent adopté), je vais vous retracer l’historique de la mise en place du serveur de build dans le service afin de bien décrire l’intérêt d’utiliser ce type de gadget et l’effet obtenu.

Pourquoi un serveur de build ?

Une de mes premières actions lors de mon arrivée à Log’in Space il y a maintenant 1 an a été d’analyser l’environnement de développement pour voir comment il était possible de rendre l’équipe plus efficace.

Le service développement fait très fréquemment des releases des différents produits, la création d’une version prenait alors environ 1h lorsqu’il n’y avait de problèmes, et durait beaucoup plus lorsque un problème de compilation non détecté avait lieu.

Les développeurs avaient l’habitude d’effectuer leur checkin après avoir terminé sans forcément faire de getlatest réguliers. Le code présent sur le source control était différent de celui présent sur les postes de développement et de temps en temps il arrivait que le responsable de la release ait une surprise en essayant de compiler le résultat final…

Afin de résoudre ce problème et être beaucoup plus réactif en cas de problème (ie. ne plus être devant le fait accompli mais réagir dès qu’il y a un problème) un serveur de build sous Team Build a été mis en place.

La première étape a été de simplement automatiser la création d’une version, puis de mettre en place de l’intégration continue (plus proche actuellement de la compilation continue). Ainsi chaque développeur est abonné aux alertes proposées par TFS, et est ainsi notifié de la réussite ou de l’échec de la build déclenché par son check-in. De plus l’automatisation a permis de réduire le temps de création d’une version à 15min.

Il s’agit d’un progrès dans le sens où l’on est beaucoup plus réactif mais il me restait à arriver à sensibiliser l’équipe sur le fait de vraiment prêter attention à avoir un code correct et fonctionnel dans le source control, afin d’avoir le plus rarement possible un code invalide.

Et cet objectif a été atteint grâce à la sirène. Les membres de l’équipe souhaitant éviter que la sirène ne s’allume, ils pensent à présent bien aux risques apportés par leur check-in avant de faire leur commit ! La sirène est en effet mise en avant et bien visible de tous, il n’est donc pas nécessaire qu’elle s’allume pour que tout le monde ait conscience de sa présence.

Encore un (tout petit pas) de franchi vers une meilleure qualité logicielle et vers moins de stress pour l’équipe !

Il reste bien évidemment de gros progrès à accomplir  comme l’intégration de l’exécution de tests automatisés par exemple, mais il s’agit d’une évolution qui va dans le bon sens.

Les + et les –

Les +

  • Outil simple à mettre en œuvre, qui fait uniquement ce qu’on lui demande
  • Une API est disponible pour piloter la sirène dans d’autres contextes que l’intégration continue

Les –

  • Lorsque deux builds échouent “en même temps”, les signaux s’arrêtent lorsqu’une des builds a été réparé et non lorsque l’ensemble des builds ont été réparés
  • Très légers bugs dans l’affichage des changesets liés aux builds lors de check-in très rapprochés

Les risques Sourire

J’ai pu identifier deux risques durant ce premier mois d’utilisation.

Le premier concerne les prestataires intervenants sur un de nos projets. L’un deux a eu la bonne idée de casser et de réparer la build entre midi et deux. L’équipe étant en train de déjeuner la sirène a été d’une totale inefficacité ! Il peut être intéressant de garder le système d’alertes afin d’avoir un réel suivi des builds.

Second risque : Si vous mettez Kool & The Gang au bureau afin de mettre un petit d’ambiance, il se peut qu’un membre de votre équipe vous propose d’allumer le gyrophare en cassant une build histoire d’avoir une ambiance son et lumière Smile (oui, oui c’est du vécu…)

image

Les évènements Microsoft sont-ils uniquement des évènements marketing ?

Des évènements purement marketing ?

Je suis toujours surpris de constater qu’il existe toujours un certain nombre de personnes qui pensent que les évènements à destination des développeurs organisés par Microsoft sont crées uniquement à des fins marketing et qu’elles sont donc par définition inintéressantes pour des développeurs.

J’ai de nouveau rencontré ce type de remarque récemment en commentaire d’un de mes posts où j’évoque l’évènement Build qui débutera la semaine prochaine.

image

Je vais donc profiter de l’occasion pour préciser ce que je pense de ce type d’évènements. Ayant eu l’opportunité de participer aux Tech’Ed Europe 2003/2004/2005/2006 et à la PDC 09 je commence à avoir un certain recul sur ces évènements internationaux.

Commençons par enfoncer des portes ouvertes, OUI ce sont des évènements organisés par Microsoft, donc OUI seules les technologies et produits Microsoft sont présentés. Cela est dommage car ces évènements ne permettent donc pas de manière simple d’avoir un positionnement de ceux-ci par rapport à la concurrence.

Autre inconvénient de ce type de conférence et de présentation, l’objectif pour Microsoft est de présenter ces technos et produits et de donner les bonnes pratiques liées à l’utilisation de ceux-ci et en aucun cas d’aider les développeurs à devenir de meilleurs développeurs contrairement à d’autres conférences comme la NDC par exemple. Seules les sessions dédiées à l’ALM peuvent parfois rentrer dans cette catégorie.

Mais ce ne sont pas pour autant des conférences marketing inintéressantes techniquement bien au contraire ! Il y a toujours des sessions intéressantes et qui ne sont pas forcément lié directement à un argument de vente.

Je me souviens par exemple d’une session au Tech’Ed 2003 où le speaker à redéveloppé le contrôle DataGrid d’ASP.net quasi feature complete en une heure from scratch sans aucun “tust” (très éprouvante pour arriver à assimiler l’immense volume de notions présentées), d’une session de Juval Lowy sur l’API System.Transactions introduite avec le framework 2.0 où il présentait son framework qui permet de manipuler n’importe quel objet serializable de manière transactionnelle, d’une session sur le cryptage level 800 par Rafal Luckawiecki, etc.

Idem pour la PDC 09, même si comme je l’indiquais dans mon bilan de l’évènement, je n’avais pas retrouvé de sessions techniques d’un niveau aussi élevé que certaines  sessions de level 400 proposées aux Tech’Ed, il n’en reste pas moins qu’assister à un panel de discussion dédié aux langages avec comme intervenants Herb Sutter, Anders Heiljsberg, Eric Meijer, Don Box, et d’autres, à une session sur le garbage collector présentée par Patrick Dussud ou encore une session sur Rx par Eric Meijer et Bart de Smet reste une occasion intéressante et épanouissante techniquement.

Eric Meijer

Pourquoi s’y rendre quand on peut télécharger les vidéos des sessions ?

La raison est simple : le networking !

Microsoft mets à disposition depuis quelques années les vidéos de ces évènements en ligne temporairement ou “définitivement”. Participer sur place en IRL à ce type d’évènements permet :

  • de confronter ses idées et opinions par rapports à ce qui est présenté avec les autres attendees.
  • de bénéficier du retour d’expérience des autres attendees sur l’utilisation d’une techno sur de vrais projets
  • de créer ou maintenir son networking avec les microsoftees de sa section locale et ainsi parfois avoir des informations complémentaires ou “des bruits de couloir” lorsque l’on est sous NDA (contrat de confidentialité) avec l’éditeur.
  • de maintenir son networking de manière générale avec “l’écosystème” .net (partenaires, communautés, SSII, éditeurs, etc.)

Autre raison de s’y rendre toute bête mais qui a en son importance, vous avez votre planning définitivement bloqué et vous êtes ainsi sûr de faire votre veille technique pendant la semaine que dure la conférence. Au lieu de s’éparpiller et de visionner quelques vidéos par-ci par-là durant son temps libre, vous avez la possibilité d’effectuer votre veille technique à la carte durant une semaine non-stop.

En conclusion

Assister à un des évènements internationaux du type Tech’Ed, PDC ou Build est, à mon avis, un très bon moyen d’effectuer sa veille technique avec généralement des sessions de qualité.

Si votre objectif est d’assister à une conférence orientée sur la technique en étant indépendant de tels ou tel éditeur et d’avoir une vision plus générale des choses afin de devenir un meilleur développeur alors il vaut mieux vous orienter vers une conférence de type NDC par exemple.

Sur ce, rendez-vous dans quelques jours pour voir ce que donne la Build !

image

Les 3 stades de maturité d’une équipe de développement

Avec mon changement de métier en début d’année, j’ai naturellement enrichi ma liste de lectures avec des sites/blogs non techniques traitant du leadership d’équipes de développement.

Un des mes sites préférés dans ce domaine est le blog Five Whys de Roy Osherove et celui-ci identifie 3 stades de maturité d’une équipe de développement :

  • Le chaos : l’équipe ne possède pas les connaissances techniques fondamentales/de base/minimales nécessaires pour débuter à faire correctement les choses.
  • L’apprentissage : l’équipe possède certaines connaissances techniques ET non-techniques qui lui permettent de voir son niveau régulièrement s’améliorer
  • L’autonomie : l’équipe est quasiment autonome, et possède les connaissances nécessaires au bon déroulement d’un projet.

Vous pouvez vous référer à ce post ou encore à ces slides pour plus de détails sur ces stades de maturité.

image

Je n’avais jamais formalisé mon point de vue sur le niveau des équipes de dév. de cette manière avant d’avoir lu le blog de Roy Osherove, mais je suis entièrement d’accord avec ce découpage.

Et je trouve de plus qu’il permet d’expliquer énormément de choses concernant le monde du développement, et je vais m’attacher cette semaine à rédiger différents posts à ce sujet.

Stay tuned !

The Information SuperHighway (cc) Vermin Inc.

Mettre en place une veille technologique via RSS

“Mais tu passes combien d’heures par jour sur le net pour connaitre autant de
sites/blogs ?”

Voilà une question que l’on me pose de temps en temps suite à une de mes réponses
du style : “Il  y a Eric Lippert qui a bloggué sur ce sujet il y a 1 mois et
demi, vas sur son blog sur msdn tu trouveras ton bonheur”. Malheureusement à chaque
fois que l’on m’interroge à ce sujet je me rends compte que la personne en face de
moi ne fait pas du tout de veille technologique et ne maitrise pas l’utilisation des
flux RSS. Car au lieu de passer plusieurs heures par jour à me balader sur Internet,
je passe maximum 1/2h par jour à consulter l’ensemble du contenu que je récupère via
mes 200 flux auxquels je suis abonné. Consulter 200 sites/blogs par jour ? oui c’est
possible via RSS. Et voici ma méthode pour réaliser ma veille technologique efficacement
sans y consacrer 307 ans.

1ère étape : Trouvez votre lecteur RSS

Première étape qui évoluera en fonction de vos habitudes de consommation,
il faut choisir votre client RSS. Deux principales options s’offrent à vous : un client
web ou un client riche. Pour savoir quels sont les points forts et points faibles
des principaux clients sur le marché, je vous recommande ce
post de l’excellent blog d’Olivier Ezratty
.

image Les
critères de choix qui me semble les plus importants en tant que gros consommateur
de flux sont : la performance (en terme de consommation CPU et de mémoire et d’affichage
des posts), et la possibilité de flagguer les posts les plus intéressants.
2ème étape : Créez votre catalogue de flux RSS

Il s’agit généralement de l’étape la plus simple. Vous avez très probablement en tête
certains blogs ou têtes pensantes qui publient régulièrement des informations dans
le domaine qui vous intéresse. Rendez-vous (pour la dernière fois) sur ces sites web
que vous connaissez déjà et abonnez vous aux flux RSS qu’ils exposent.

Classez correctement vos flux en différentes catégories/sous-catégories afin de pouvoir
retrouver facilement les informations lorsque vous en aurez besoin.

Je vous déconseille fortement de vous abonner aux flux qui ne proposent qu’un résumé
du contenu et non l’intégralité du contenu (le RSS sert à syndiquer du contenu et
non des résumés). Ces flux sont une perte de temps puisqu’ils vous obligent à consulter
le site pour avoir accès à l’information souhaitée. Sur mes 200 flux, je n’en possède
que deux qui proposent uniquement le résumé (celui de Mary
Jo Foley
, et celui d’une toulousaine
pleine d’humour
–rien à avoir avec la techno :p)

3ème étape : Maintenez régulièrement sa liste d’abonnements

Il est très important d’enrichir votre liste de flux, votre client RSS
n’est pas une boite qui s’alimente toute seule en effectuant sans cesse des requêtes
HTTP, il faut l’entretenir en lui donnant de quoi se mettre sous la dent. En plus
du simple ajout ponctuel effectué suite à des recherches précises, j’enrichis mon
catalogue de deux manières :

  • En suivant les blogrolls des blogs qui me plaisent le plus. Les personnes qui vous
    intéressent le plus ont une probabilité assez importante de recommander à leur tour
    des personnes intéressantes. Cette technique fonctionnait bien jusqu’à il y a quelques
    mois mais je l’utilise de moins en moins car : les bloggeurs utilisent de moins en
    moins les blogroll et quand ils le font c’est généralement pour des blogroll “corporate”
    destinés à promouvoir leurs collègues.
  • La deuxième technique, celle que je privilégie, est d’utiliser Twitter.

La maintenance passe également par la suppression des flux inactifs ou qui ne vous
intéressent plus. Cette étape est importante afin de ne pas pénaliser les performances
de votre client et surtout afin de toujours avoir des informations pertinentes et
non un simple tas d’informations accumulées avec le temps. La plupart des clients
RSS vous permettent d’avoir facilement accès à vos flux morts pour que vous puissiez
faire facilement le ménage.

4ème étape : Abonnez vous à des blogs/sites/rubriques de news

Vous n’êtes pas les seuls à faire de la veille technologique, n’hésitez
donc pas à profiter du travail des autres quand ceux-ci ont la gentillesse de le partager
via des blogs, des sites ou alors des rubriques dédiées.

En règle générale, vous ne trouverez pas de listes qui ciblent exactement vos centres
d’intérêts, c’est pour cette raison que ces sites doivent être des compléments à votre
propre veille, et non en être la base.

Dans le monde .net vous pouvez vous abonner aux sites suivants :

En anglais : The Morning Brew

En français : C2i.fr ou encore ma
propre rubrique de news
😉

Voilou ! vous êtes à présent parés pour affronter la masse d’informations disponibles
sur le net !

Le principe de précaution

“Quelqu’un peut il m’expliquer pourquoi il arrive fréquemment, dans une équipe
projet, d’avoir une ou deux personnes qui ne peuvent écrire une classe sans écrire,
systématiquement, une ou plusieurs interfaces ou classes abstraites qui, en fin de
projet, ne sont finalement implémentées que par une classe voir pas du tout ?”

Voilà en substance un mail qui a lancé un débat intéressant entre collègues. Et je
dois dire que je suis d’accord avec ce constat et qu’il est vrai que j’ai parfois
l’impression que certains développeurs pensent que savoir développer proprement et
professionnellement signifie devoir implémenter 9879798 interfaces et classes abstraites
et ajouter 98770754 niveaux d’abstractions. Après tout, rajouter de l’abstraction
est le premier réflexe que l’on peut avoir lorsque l’on essaie d’atteindre l’objectif
premier de tout développeur qui se respecte :

Ecrire du code maintenable

Cet objectif est en effet primordial afin de réduire le coût de développement (et
de maintenance) d’un projet. Mais il mène parfois vers le travers évoqué ci-dessus.

Cette
mauvaise habitude appelée “le syndrome du “ocazou”” par David,
se rapproche beaucoup du principe de précaution dont on parle beaucoup en ce moment.
Adapté au développement logiciel celui-ci pourrait se traduire par :

“ l’absence de certitudes, compte tenu des connaissances techniques du moment,
ne doit pas retarder l’adoption de mesures effectives et proportionnées visant à prévenir
un risque de dommages graves et irréversibles au projet de développement à un coût
économiquement acceptable ”

Seul problème avec ce genre de principe de précaution, il est très souvent difficile
d’arriver à proportionner correctement son action afin d’éviter les problèmes par
la suite. L’actualité récente l’a montré, le principe de précaution incite souvent
à exagérer la menace, et a dans quasi tous les cas une certaine faculté à faire exploser
les coûts pour un résultat… souvent peu mesurable.

En réalité, la maintenabilité doit certes être basé sur du code propre et bien structuré,
mais il repose également sur deux principes fondamentaux :

  • Le principe KISS (Keep
    It Simple and Stupid)
    : Plus un code est simple et plus il sera facilement
    compréhensible et maintenable. Ajouter de la complexité en ajoutant des niveaux d’abstractions
    inutiles ne fait… qu’ajouter de la complexité.
  • Le principe
    YAGNI
    (You aren’t going to need it)
    : Ce principe indique qu’il
    ne faut pas ajouter des fonctionnalités ou du code tant que l’on n’en a pas réellement
    besoin.

Ces deux principes sont d’autant plus valables que nous avons à présent des outils
efficaces (comme ReSharper) permettant
de refactoriser intelligemment son code afin de faire évoluer son architecture quand
on a en besoin
. Inutile donc de rajouter de la complexité en prévision
du futur, il ne sera pas trop tard pour le faire par la suite…

Critique : The Pragmatic Programmer

L’ouvrage “The Pragmatic Programmer” sous-titré “from journeyman to master” est certainement
un des livres que je lis le plus régulièrement. J’essaie en effet de le relire au
moins une fois tous les ans afin de revoir comment je peux améliorer mes habitudes
de développeurs. Il est en effet très important d’analyser ses méthodes de travail
et de les confronter avec les meilleures pratiques dans le domaine afin d’améliorer
la qualité du travail fini, améliorer sa productivité, et tout simplement travailler
dans de meilleures conditions. The Pragmatic Programmer est LE livre qu’il vous faut
si vous aussi vous avez cet objectif.

De l’utilisation d’outils de contrôle de code source, de la pertinence d’utiliser
des techniques de refactoring, de la nécessité de tester son code, d’améliorer ses
techniques de debugging, ce livre évoque un grand nombre de vérités que l’on peut
parfois considérer comme des banalités, mais qui ne sont parfois pas si simple à mettre
en œuvre dans la vraie vie.

Un sujet qui pourrait vite être rébarbatif et ennuyeux si la pédagogie de l’ouvrage
n’était pas aussi réussie. Les analogies employées sont par exemple très intéressantes
et sont une vraie valeur ajoutée. Ce point est d’ailleurs crucial puisque travaillant
en équipe, il est important de savoir partager les idées proposées afin de convaincre
les personnes avec lesquelles vous travaillez d’améliorer les méthodes de travail
habituellement utilisées.

Vous l’avez compris, contrairement au
précédent ouvrage dont je vous avais parlé
, je vous recommande la lecture de ce
livre. Même s’il n’est plus tout jeune, les principes et conseils proposés sont toujours
d’actualité.

En savoir plus :

The
Pragmatic Programmer: From Journeyman to Master