Déployer vos corrections rapidement

18 décembre 2008  |  Publié dans Développement informatique, Qualité  |  1 commentaire

J’utilise le logiciel Digsby comme je vous l’avais déjà mentionné. J’ai eu un pépin avec l’application lorsque je me suis mis à l’utiliser avec deux moniteurs sur mon ordinateur. J’ai soumis un bug directement dans l’application.

Croyez-le ou non, mais le développeur, Steve Shapiro, m’a répondu dans l’heure pour m’indiquer qu’il avait déployé la correction sur internet. Il m’a tout simplement demandé de redémarrer l’application pour qu’elle se télécharge et s’installe sur mon poste. Affaire classée.

Ceci m’amène à dire, lorsque vous êtes en phase d’essais ou de tests, déployez vos corrections rapidement. J’ai souvent vu des projets où les déploiements une fois par semaine ou même une fois par mois. Toutefois, la perception chez l’utilisateur peut s’avérer très négative puisque le bug va être dans leur face pendant toute l’attente. La confiance envers le système risque de perdre des plumes.

Ceci s’applique aussi aux systèmes en production. Les bugs irritent vos usagers et le plus longtemps qu’ils ne seront pas corrigés et déployés, les usagers vont devenir de plus en plus cyniques envers l’application.

J’entends les antagonistes! Vous vous dites que déployer fréquemment risquent de déstabiliser votre application? C’est possible, mais c’est peut-être de votre faute. Avez-vous réfléchit au mode de déploiement de votre application? On est à l’époque du web et de l’instantané. Si pour déployer on doit fermer la salle de serveur pendant 4 heures, vous êtes “out”. Les gens s’attentent que vos systèmes soient disponibles. Vous ragez lorsqu’il y a des travaux routiers? C’est la même chose.

Un petit truc pour mieux programmer selon les spécifications

25 novembre 2008  |  Publié dans .NET, Qualité  |  Aucun commentaires

Lorsqu’on travaille en mode waterfall et on est dans le siège du programmeur qui doit réaliser ce qui est rédigé dans le dossier fonctionnel, on fait de notre mieux de le lire et de le comprendre. Toutefois, la programmation objet étant ce qu’elle est, on finit par sauter d’une section à l’autre dans le dossier fonctionnel au risque d’omettre un détail ou une règle d’affaire.

Un truc que j’ai adopté au fils des ans c’est de coller du texte du dossier fonctionnel comme commentaire aux endroits prévus. Je m’explique, si le dossier fait référence à une dynamique lorsqu’on quitte un champ texte, ajoutez la description de la règle d’affaire du dossier comme commentaire dans l’événement LostFocus du champ avec une petite mention TODO (à faire plus tard). Ceci vous assure plusieurs choses:

1. Vous n’allez pas l’oublier de coder la règle.
2. Vous allez programmer exactement ce qui a été demandé.
3. Vous allez avoir des commentaires dans votre code sans trop d’efforts.
4. Vous établissez un lien de traçabilité avec le dossier fonctionnel. Si il existe un code quelconque de la règle d’affaire incluez là sans hésitation!

Pour aider la tâche du programmeur, j’avais découvert un petit Add-In pour Visual Studio et que j’utilise depuis longtemps. Il s’agit de Smart Paster qui permet de coller une chaîne de caractère comme un commentaire, une String ou un StringBuilder.

Si le texte que vous tentez de coller est trop long, il va le couper à 100 caractères (valeur par défaut) et copier la suite sur autant de lignes que nécessaire. Fini les oublis!

Faire des captures d’écran facilement et proprement

9 octobre 2008  |  Publié dans Logiciels libres, Qualité  |  1 commentaire

Pour différentes raisons, on a souvent besoin de faire des screen grab, screen cap, imprime écran ou captures d’écrans dans le cadre de nos activités sur l’ordinateur. Différents outils commerciaux font un excellent travail, mais cette tâche simple requiert-elle vraiment l’acquisition de licenses logicielles?

Par défaut, dans Windows si on presse le bouton “Print Screen”, tout le bureau est sauvegardé dans le presse-papier (clipboard). On peut ensuite faire “Coller” dans Word ou Microsoft Paint. Souvent, l’image produite contient trop d’information (les résolutions d’écran sont très grandes de nos jours). Le fichier sauvegardé peut être très gros aussi et difficilement acheminable par courriel.

Jusqu’à présent, j’utilisais Snagit de TechSmith, mais il coûte 49$ US. Je ne suis pas convaincu qu’un utilitaire du genre vaut autant d’argent.

Je me suis mis à rechercher sur le web pour une alternative version libre (open source). Je suis tombé sur Greenshot disponible sur SourceForge.Net et j’en suis très satisfait. J’ai retrouvé les mêmes fonctionnalités que j’utilisais avec Snagit.

J’aime prendre une photo d’une région de l’écran. Avec Greenshot, quand on presse le bouton “Print Screen”, notre pointeur de souris se transforme en croix. Avec la souris on sélectionne le carré qu’on veut capturer. Ensuite, il nous amène dans un petit éditeur d’image où là on peut ajouter des annotations, des flèches et toutes sortes d’opérations.

Cet outil est très utile pour les bloggeurs, les équipes d’essais d’assurance qualité (QA) et les gens en support technique. Faites-en l’essai!

Un bogue fonctionnel devant les tribunaux

8 octobre 2008  |  Publié dans Développement informatique, Qualité  |  2 commentaires

Aujourd’hui je suis tombé sur l’émission de François Paradis à TVA. Il avait comme invité un dénommé Joël Ifergan qui poursuit Loto-Québec pour lui avoir refusé le gros lot de 13,5 millions. Il avait la combinaison de 7 numéros de la Super 7, mais il avait la mauvaise date de tirage.

Le monsieur avait acheté son billet à la toute dernière minute avant l’heure de tombée de 21:00 les soirs de tirage. Il avait bel et bien débuté sa transaction avant 21:00 et ce fait a été confirmé par Loto-Québec. Toutefois, la société d’état se fie sur l’heure d’impression du billet et il fut imprimé 7 secondes après 21 heures. Ce délai technique est coutume aux anciens terminaux qui se font remplacés présentement par Loto-Québec.

Toutefois, dans un système informatique lorsqu’on impose des règles fonctionnelles tels qu’une heure limite à l’utilisateur, le délai de traitement de la machine à saucisse ne devrait pas être un paramètre pour ce dernier. Le seul contrôle que le client a c’est l’heure qu’il décide de faire l’achat. L’heure du billet aurait donc dû être l’heure de début de transaction.

Si la transaction est suspendue pour des raisons techniques (ligne occupée, manque de papier dans l’imprimante, lenteur réseau, etc.) ça ne devrait pas modifier la requête initiale du client qui est de participer à un tirage de loterie à une date donnée.

Ceci est la définition pure d’une bogue fonctionnel. Un bogue n’est pas toujours accompagné d’un message d’erreur horrible rouge et clignotant à l’écran ou de fumée qui sort de la machine. Il peut prendre la forme d’un comportement très peu logique, probablement pas documentée, encore moins connu par la société d’état et encore moins par ses commerçants.

J’ignore ce que le résultat sera pour ce procès, mais j’ose croire que si cette subtilité n’a jamais été communiqué à sa clientèle, le juge favorisera le client.

Pour en savoir plus, voici un article sur le site de Cyberpresse.

Nicolas Roberge, observations et conseils sur la technologie