Catégorie : Vie de programmeur

Vous êtes tentés de démarrer un projet open source dans votre organisation?

L’open source est une façon de faire du développement logiciel qui est présente depuis déjà un bon moment. Cependant, il y a une tendance forte chez les entreprises à ouvrir le code de ses applications ou librairies afin d’y accepter les contributions.

EnfantsPar exemple, dans le cas que je connais le mieux, il semble une bonne idée de penser à rendre accessible à tous le code d’une librairie développée pour les développements clients. Cette accessibilité du code permettrait à la communauté de participer à l’effort de développement ou de simplement réutiliser le module librement.

L’idée à la base est assez simple. Si le module en question connaît un bon succès à l’interne, pourquoi ne pas en faire profiter les autres? Vous avez probablement déjà eu une discussion au sujet dans votre organisation.

Souvent, une idée peut sembler intéressante jusqu’à ce que l’on s’intéresse aux petits détails ou que l’on soit à pieds joints dans l’expérience. C’est exactement ce qui arrive avec l’idée d’ouvrir le code d’un développement interne.

La vie d’un projet open source

D’ailleurs, je tiens à être clair. Je suis un très grand fan de l’open source. Mon propos est plus de mettre en éclairage que l’idée n’est pas systématiquement bonne. L’open source sans plan de match ne vaut pas grand-chose en soi.

Habituellement, le démarrage d’un projet open source va comme ceci:

  1. Un développement initial d’une librairie a lieu
  2. Le projet en tant que tel prend de la traction à l’interne
  3. Une pression à rendre à ouvrir le code a lieu
  4. Un compte Github ou Bitbucket est créé et le code y est téléchargé
  5. Les développements y ont lieu ou, du moins, une version y est téléchargée périodiquement
  6. Le projet gagne en visibilité
  7. Des demandes de support commencent à survenir

À partir de cet instant, l’organisation a quelques décisions à prendre.

  • Investir du temps et de l’argent pour supporter les contributeurs et faire de la correction de bogues les utilisateurs. Principalement pour maintenir la réputation de la librairie et de l’entreprise.
  • Distancer l’organisation du développement du projet open source.
  • Ajouter une mention « à vos risques et périls » pour l’utilisation de la librairie.

La dernière option est vraiment contre-productive considérant que l’open source est avant tout à propos de la création d’une communauté autour du bout le logiciel en question. Si on se déresponsabilise du développement de la librairie et de son utilisation, pourquoi y ouvrir le code?

Ce qui doit être fait

Pour qu’un projet open source puisse avoir une viabilité, je crois que certaines conditions gagnantes doivent être combinées.

  • Une feuille de route indiquant la direction que va prendre le projet.
  • Des indications claires sur les contributions acceptées par les mainteneurs
  • Accepter les contributions externes

Un bon exemple de ce genre de fonctionnements est le projet Rails. Très rapidement, à partir de la page d’accueil du projet sur Github, vous avez une description du projet et une documentation pour se lancer tête baissée dans le projet.

La qualité la plus importante pour un développeur web

Si vous deviez nommer la principale qualité qu’un médecin doit avoir, à part les réponses faciles comme la compétence, qu’est-ce que serait celle-ci?

Vous seriez tenté de répondre des réponses comme:

  • Bonne humeur
  • Ponctualité
  • Précision des diagnostics

Et vous pourriez en énumérer encore quelques-unes, j’en suis certain. Il serait, toutefois, relativement improbable que vous répondiez quelque chose concernant la qualité du maniement de son stéthoscope.

Après tout, on s’en balance un peu de son maniement du stéthoscope. Ce qui est important, avant tout, pour un médecin est la qualité du service qu’il rend à la population. Si les gens sont plus heureux en sortant du bureau du médecin, c’est tout ce qui compte.

Le développeur web

En dix ans de vie active sur le marché du travail, je dois avouer que nous sommes à une drôle d’époque. Les choses évoluent très rapidement. À mon avis, la nature même du développeur web est en pleine transformation.

À une certaine époque, disons vers 2008, les rôles et responsabilités des artisans du web étaient tranchés au couteau. Soit que tu étais un développeur ou tu étais intégrateur web.

Dans le cas d’un site ASP.NET, le rôle de l’intégrateur web était surtout de faire la mise en page du site, car la majorité des fonctionnalités d’interactivité étaient assurées par ASP.NET. Le développeur .NET avait donc la majorité des responsabilités.

Jusqu’à récemment, il pouvait y avoir un ratio programmeur/intégrateur assez élevé sans problèmes. Il ne faut pas être dupe, la tendance est à la renverse. Ceci s’explique principalement par le niveau grandissant de responsabilités dans le développement côté client.

Un exemple criant de vérité est le cas des librairies comme AngularJS qui permettent la mise en place d’interfaces interactives côté client avec très peu d’interactions avec le serveur. Le développement côté client se démocratise de plus en plus.

La polyvalence

swiss_army_knife1[1]

L’atout principal d’un développeur web est sa capacité à réduire la taille de la zone grise qui le sépare encore les autres corps de métier qui sont mis à contribution pour le développement d’un site web.

Par exemple, un intégrateur web pourrait se porter volontaire pour faire une portion d’un design pour une nouvelle section du site. Le développeur pourrait contribuer à la mise en place de certaines portions de JavaScript pour l’animation d’un carrousel, par exemple.

Tout revient à la polyvalence des individus pour  la réalisation d’un projet. La règle est assez simple. Plus les individus sont en mesure de s’impliquer dans des sphères à l’extérieur de leur zone habituelle, meilleure sera la capacité de livraison de l’équipe. La vélocité de l’équipe sera améliorée.

Dans le contexte de l’agilité, lorsqu’il est question d’améliorer la vélocité de votre équipe, c’est votre propriétaire de produit qui en sera heureux. De la mélodie à ses oreilles.

Ma vie de programmeur, en images – partie III

Lorsque j’écris de la documentation

tiger-sleep

Lorsque je vais dîner avec mes collègues

turkey-gang

Une journée typique de programmeur

ibaDjk7AeIcvxv[1]

Lorsque je viens en aide à un collègue qui a un problème avec son code

3ThYXrj[1]

Lorsque je suis dans le mood pour développer

D6x5ie2[1]

Ma solution se fait dérouter au moment du contrôle qualité

CaiObKz[1]

Le site est en panne?

DT0UoMO[1]

Un message au à la personne qui apporte des beignes au bureau

clam

Comment je m’imagine lorsque je fais du refactoring sans tester

eIAZUaS[1]

La sensation que donne de démarrer un nouveau projet

izx3PMafci5V3[1]

Lorsque c’est moi qui se pousse avec le dernier beigne du bureau

MQ6GhR1[1]

Lorsqu’un git pull rend le projet non fonctionnel sur mon poste

rv-hit

Histoire vécue #2 – Comment ne pas configurer un site ASP.NET MVC 5 sur son serveur IIS 7.5

Mercredi 5 février a été la journée où je me suis cassé les dents sur un problème qui, à première vue, était inexplicable et totalement à l’encontre de l’ordre des choses.

S’il y a un signe universel qui signifie quelque chose en informatique, c’est bien celui-ci. Lorsque quelque chose doit fonctionner d’une façon et que, pour une raison inconnue, ce n’est pas le cas, il y a anguille sous roche.

Mise en contexte

Mon poste de développement utilise une configuration assez à jour (Windows 8 et IIS 8) et le projet sur lequel je travaille est aussi à la fine pointe (.NET 4 et ASP.NET MVC 5).

À ce moment de l’histoire, aucun signe ne pouvait laisser présager qu’un problème se pointe le bout du nez. Les fonctionnalités développées ont été accomplies dans le temps et le budget requis.

À partir de là, on pense vivre un rêve. On passe l’étape de la revue de sprint avec le client et tout le monde est heureux. Du beau travail, vraiment.

Juste pour tester…

Ce qui a été développé est un composant faisant oeuvre de service web reliant une application web et une application de gestion utilisée par le client. Étant donné que le composant développé se met les pieds dans une partie critique, il a été entendu qu’une bonne période de tests serait mise de l’avant avant de donner le feu vert pour la production.

Le principal but de cette période de tests sera d’exécuter parallèlement l’application afin d’être en mesure de comparer l’état des données avec la production pour en assurer la précision.

En bout de compte, pour valider ces données, le composant a été hébergé sur un serveur temporaire où il sera observé sous toutes ses coutures pendant quelques jours.

La mise en ligne

Une fois le serveur web accessible, je me lance dans la mise en ligne. Une fois le nécessaire déployé, j’ouvre un nouvel onglet à partir de mon navigateur web et j’ai la page suivante :

Votre page d'erreur HTTP 404 sous IIS 7.
Votre typique page d’erreur HTTP 404 sous IIS 7.

Après les vérifications nécessaires permettant de m’assurer que je ne suis pas fou ou que j’ai commis une erreur humaine, je demande une double vérification par un collègue. Malheureusement, tout est en ordre du côté de mon application. Le site web servait le contenu sauf celui provenant d’ASP.NET MVC.

L’ordre normal des choses n’est soudainement pas respecté. Je confirme que je n’étais pas très heureux à cet instant. La mise en ligne allait prendre officiellement plus de temps que prévu.

Une mise à jour

Dans mon cas, le serveur en question avait pris un peu la poussière dernièrement. Certaines mises à jour Windows étaient à appliquer sur celui-ci.

Une mise à jour en particulier est importante à appliquer, car elle vise précisément à adresser cette situation. Il s’avère qu’IIS 7 n’avait pas été initialement conçu pour servir des contenus web n’ayant pas d’extension (ex. : mapage.aspx au lieu de /monaction/1).

Donc, la mise à jour corrige le tir à ce sujet. Une fois qu’elle a été installée sur le serveur, mon application s’est mise à fonctionner comme prévu.

Alternativement, j’aurais pu activer l’option runAllManagedModulesForAllRequests= »true ». Toutefois, comme son nom l’indique, la totalité des requêtes faites à mon site web aurait passé à travers des modules ASP.NET. Selon l’achalandage à votre site, cela peut avoir un impact de performance majeur.

Sources :

Histoire vécue – comment ne pas gérer son historique de développement Git

Depuis l’automne passé, les équipes de développement chez Absolunet utilisent Git à temps plein. Sans réserve, je peux dire que l’on vit le rêve Git à temps plein. Branches à volonté et modèle de travail asynchrone et déconnecté sont au rendez-vous. 

Ce que je suis sur le point de documenter est un truc que j’ai dernièrement sorti du derrière de ma manche afin de me sortir du pétrin. Lorsque je dis que je me suis sorti du pétrin, il s’agit de se mettre dans le même état d’esprit que l’image ci-dessous.

shoot
Résolution de problèmes informatiques

Rien n’arrive pour rien dans ce beau monde. La réalité vient parfois vous frapper en plein visage. Dans mon cas, il s’agit de la réintégration d’une branche restée en développement pendant trop longtemps sans être réintégrée graduellement.

Je peux vous dire que ça a été pénible jusqu’à la mise en ligne.

Un seul commit

En théorie, il ne devrait pas y avoir d’obstacles à réintégrer une branche, peu importe la période de temps où le développement s’est fait en parallèle. Point à la ligne. Les révisions branchées sont appliquées par-dessus celles où vous désirez réintégrer. Validez les conflits, testez votre code et c’est la fin de l’histoire.

Là où la réalité est venue me rattraper, est que lors de la réintégration de cette branche, une très grande majorité des fichiers nouvellement ajoutés lors du développement en question était considérée en conflit. Cela ne devrait pas se passer ainsi, n’est-ce pas?

Or, il s’avère que la source de cet incident est relativement anodine, mais a une importance capitale. Par erreur, une réintégration de la branche de développement avait été effectuée et soumise à l’historique de développement commun. Lorsque nous avions réalisé notre bourde, le commit en question avait été annulé (revert).

Vous me voyez venir? Tous les changements, même s’ils sont des fichiers nouveaux vis-à-vis la branche dans laquelle je tentais de réintégrer, puisqu’ils avaient été précédemment annulés Git ne pouvait déterminer ce qu’ils devaient conserver comme modification.

Ce qui fait mal dans toute l’opération est le volume de fichiers à résoudre. Il y en avait des centaines. En plus de cela, les changements étaient dispersés à travers quelques centaines de commits et une bonne proportion d’entre eux contenaient des changements mixtes. C’est à dire des fichiers qui avaient évolué à la fois sur la branche stable et celle de développement.

Aux grands maux, les grands moyens

Je ne vais pas raconter d’histoire. La solution que j’ai retenue est loin d’être élégante et très loin d’un modèle reposant sur les bonnes pratiques du versionnage de code source.

Ce que j’ai fait ressemble à ça :

  • prendre une copie de la branche master
  • coller son contenu dans ma branche de développement.

Je dois avouer que ce n’est pas très élégant.

Toutefois, avec tout cela, mon problème de réintégration de branche n’est pas résolu. Considérant que j’ai réintégré manuellement le contenu de ma branche, il faut soumettre ces changements à l’historique public.

Pour y arriver, il faut forcer un push de l’historique de développement de la branche master afin qu’elle pointe sur le plus récent commit de l’historique. Ceci se fait en deux étapes : 

Vous devinerez que l’image choisie en préambule est drôlement appropriée pour cette opération en particulier. Une fois cela réalisé, le tour est joué et vous pouvez aller prendre un café!