Catégorie : Anecdote

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.

Publicité

Bonne fête French Coding: deuxième anniversaire!

Le 12 avril prochain est la date de naissance de ce blogue. Bonne fête à moi-même!

crazy-kid-birthday-gif[1]

J’ai envie de réécrire la même chose que j’ai écrite l’an passé. Écrire sur ce blogue me permet d’expérimenter et de réfléchir sur un paquet d’idées.

Sans blague, j’ai énormément de plaisir à le faire. Ce qui me fait encore plus planer, c’est ce graphique:

visites-fc

Ça, c’est l’importance qu’accordent les visiteurs à mon travail. Le nombre croissant de visites est le meilleur cadeau que je puisse recevoir. Ça fait chaud au cœur. Merci.

À quelques reprises, j’ai eu envie de prendre une pause ou de simplement arrêter. Que mon temps était mieux investi ailleurs. À tous les coups, après une journée ou deux, je retourne à l’écriture. L’écriture finit par être quelque chose qui me chatouille les doigts. Il y a toujours quelque chose à découvrir, à documenter.

Découvrir, documenter. C’est ça la raison d’être de French Coding. Après deux ans, j’aime encore plus qu’au départ écrire!

En plus, je trouve que mon français écrit s’est amélioré.

Il y a une chose que je répète souvent à mes amis au sujet de ce blogue. Trop souvent on voit des gens partir un blogue sur un coup de tête et le laisser à l’abandon après un ou deux billets. C’est la dernière chose que je souhaitais avec cette aventure.

Principalement parce qu’il s’agit d’une trace à l’encre indélébile sur le web et surtout parce que je ne suis pas du genre à commencer quelque chose sans le finir.

Statistiques en vrac

Vous connaissez surment « Ce Projet »

J’écris souvent au sujet des réalités reliées au développement web. Par fois, j’exprime des opinions sur des sujets que je trouve importants ou des fois sur des concepts qui s’apparentent plus au gros bon sens.

smellEn arrondissant sommairement, cela fait presque dix ans que je travaille comme développeur. J’ai passé plus de la moitié de ce temps à faire du développement web. Cette expérience me permet d’affirmer la chose suivante : tout développeur a eu ou aura à travailler sur Ce Projet™.

Oui oui, Ce Projet.

Vous le savez. Il s’agit du projet que, dès l’instant où vous apprenez que vous aurez à y travailler, le regard des autres ne ment pas. Lentement mais sûrement, vous sentez ce sentiment de désespoir vous animer pour les semaines à venir.

Ce Projet où, lorsque vous commencez à travailler dessus, le collègue vous donne la directive suivante : « si tu touches à cette classe-là, viens me voir avant ».

Avec Ce Projet, il semble plus simple de dupliquer du code un peu partout que de s’attaquer au réusinage de code (aussi appelé refactoring. ha!) de la logique en question.

Lorsque vous êtes désespéré, vous tentez de retrouver le numéro de téléphone ainsi que l’adresse de résidence du développeur de l’application afin de lui livrer une correction qui saura se souvenir longtemps.

S’il est question code smell, vous vous dites que, dans ce cas, Ce Projet doit être en décomposition avancée.

Une chose est certaine. Par manque de temps et de budget, l’état de délabrement de Ce Projet ne s’améliorera pas.

Il y a plusieurs facteurs qui font en sorte qu’un projet est difficile à maintenir. Il se peut que le code en place, par la nature du problème à résoudre, soit complexe. Cela peut être aussi expliqué par des délais de livraison qui ont été écourtés. Que, par extension, la qualité en a aussi été affectée !

Peu importe la nature du problème qui affecte votre application, il faut savoir que la dette technique est le phénomène sous-jacent. Une dette technique est comme son équivalent financier. Elle aura tendance à prendre plus d’ampleur si elle n’est pas régulièrement remboursée.

Dans tous les cas, je lève mon clavier bien haut à tous ceux qui ont entre leurs mains Ce Projet. Votre patience et votre santé sont mises régulièrement à dure épreuve. Vous vous dites que vous y avez goûté plus d’une tasse ces derniers temps. Dites-vous que vous n’êtes pas seuls ;)

Un billet à mettre sur une tablette

Lorsque j’écris mes billets pour ce blogue, j’ai toujours utilisé mon ordinateur pour faire le travail. Un thé décaféiné à portée de main et de la musique dans les oreilles. C’est de cette façon que me vient l’inspiration.

Au début de l’aventure French Coding, je me suis souvent demandé que seraient les outils que j’utiliserais pour arriver à bloguer au rythme que je désirais. Depuis avril 2012, je suis sur une cadence d’un billet complet par semaine et, depuis octobre 2012, j’ai ajouté les liens de la semaine les lundis matin.

Tout ça pour dire que je me demandais comment j’allais faire pour produire le contenu à cette fréquence.

En bout de compte, il s’avère que c’est moins mystérieux que ça en avait l’air. Bien souvent, j’ai des billets prévus en publication deux à trois semaines en avance. Cela aide un peu pour réduire la pression de sortir un billet le mardi soir!

Au moment d’écrire ceci, j’ai du contenu en publication planifiée jusqu’au jour de Noël. Alors, bien souvent, j’y vais selon l’inspiration du moment.

Pour ce qui est des liens de la semaine, j’utilise principalement Instapaper pour faire la collection des liens qui m’ont intéressé à travers la semaine. Le dimanche, je prends une heure pour faire la sélection des liens et mettre en page les résumés.

Donc, je disais que j’utilisais mon PC pour faire ce travail. En utilisant Google Chrome et l’éditeur de contenu inclus dans WordPress.com. C’est tout ce dont j’ai besoin pour opérer. L’autre détail à mentionner est que je vais créer des brouillons avec des idées pour des billets futurs.

L’article tire à sa fin et je vais devoir faire le lien avec la mise en tablette mentionnée dans le titre de ce billet. Depuis cette semaine, je suis nouvellement propriétaire d’une tablette iPad d’Apple.

Vous voyez venir le lien avec la tablette n’est-ce pas? Ce billet a été entièrement conçu en utilisant le iPad et l’application WordPress. Tout en étant confortablement assis sur le divan de mon salon.

iPad WordPress

La grosse vie!

Les Pascaleries : Édition #3 – directement de mon univers!

Après le développement, s’il y a une chose que j’aime faire c’est de parler. Il ne s’agit pas juste de parler pour parler dans le vide. Expliquer des concepts. Les vulgariser pour que les autres puissent comprendre.

Ma façon préférée d’y arriver est d’imager les concepts afin que vos interlocuteurs puissent imaginer ce que vous tentez d’expliquer. Des fois, il arrive que mes comparaisons soient totalement accidentelles. Dans d’autres cas, je semble être possédé d’un élan créatif. Un éclair de génie, genre.

Alors, c’est avec grand plaisir que je présente la troisième édition des Pascaleries. C’est-à-dire la collection des comparaisons et métaphores que j’ai pu utiliser dans mes conversations.

Turbulence – Indisponibilité du site web

Par un certain mardi matin d’été, le soleil brillait et l’air était chaud. Les oiseaux gazouillaient et tout le monde travaillait en harmonie. Une belle journée à l’horizon.

Tout à coup, les courriels entraient par dizaines et le téléphone sonnait autant. On nous disait que son site était indisponible à partir du web. Oups! Une panne momentanée et généralisée.

C’est donc à ce moment que j’ai introduit le concept de période de turbulence sur nos hébergements. Exactement la même comparaison que pour les vols d’avions : la turbulence atmosphérique.

En avion, la turbulence atmosphérique fait en sorte que l’avion va se faire brasser au point de ressentir jusqu’au point que vous pouvez ressentir des secousses relativement désagréables pendant une courte période durant votre vol.

Vouvoiement

Ce qui est assez drôle, c’est que j’ai vraiment appris à vouvoyer de façon naturelle en étant quotidiennement en relation avec la clientèle.
Au début, c’était comme forçant, pas naturel du tout.
Ça m’aura servi.
Un client, administrateur réseau, que j’avais l’habitude de vouvoyer me vouvoyait aussi en retour. La relation était cordiale.
Assez froide, cependant.
Un jour, en révisant les formalités d’un développement à venir, il fallait parler de certaines procédures stockées. En particulier, de certains ajustements qui affectaient le site en entier.
Il m’a sorti : « Écoute, nous allons parler de programmation SQL. Est-ce qu’on peut se tutoyer?« .
Je vais garder ce moment dans ma mémoire à jamais.
J’étais flabbergasté!

« Planter une graine » de façon imagée

vigne-mario

Extrait d’une discussion arrivée véritablement lors d’une discussion avec mon gestionnaire de projets.

– Et puis, Pascal, est-ce qu’il y a du nouveau sur ce dossier?

– Eh bien, j’ai eu une conversation avec le client hier. Nous avons statué sur ce qui a été complété. En ce qui concerne le plan de match pour la mise en ligne qui va suivre, j’ai planté une graine dans le pot de terre et je l’ai arrosé abondamment.

– (regard perplexe)

– J’espère bien que d’ici la semaine prochaine la graine va germer.

Regarder sous un Kilt pour voir de quoi ça a l’air

Un collègue, en introduction de présentation, a une fenêtre du logiciel .NET Reflector d’ouverte à l’écran. J’ai lancé une comparaison qui a causé quelques rigolades dans la salle.

Vous ne trouvez pas que .NET Reflector est un peu comme lever un Kilt pour regarder ce qu’il y a en dessous?

sous-le-kilt

Pour ceux qui ne le savent pas, Reflector est un outil permettant d’analyser le code source contenu dans une DLL de .NET en décompilant le code qu’elle contient. Il s’agit, habituellement, d’une opération de dernier recours quand la documentation ne suffit pas.

Toutefois, je vous recommande très fortement de garder l’utilitaire à portée de main. Il est très utile! Je vous promets que vous ne pourrez pas voir ce qui se trouve sous un kilt!