Acquisition de christianrondeau.net

Après de bons et loyaux services avec wordpress.com, je lève mon chapeau et déménage, un peu comme d'un appartement à une maison! La nouvelle addresse de mon blogue, la seule à être tenue à jour, sera la suivante: http://blog.christianrondeau.net. Cette acquisition me permettra de rendre disponible des exemples de code, des outils gratuits et toute un éventail d'opportunités! S'il vous plaît, mettez à jour vos favoris, et continuez à me rendre visite dans mon nouveau "chez moi"!

Opinion sans originalité sur les exceptions

Cet article est en réalité un courriel répondant à une question sur les bonnes pratiques avec les exceptions. S'il peut être utile à quelqu'un, tant mieux!

Premièrement, l'Exception Management Application Block est surtout fait pour "réagir" et publier les exceptions à l'extérieur du contexte d'exécution du code. Il n'aide donc, selon moi, aucunement à la bonne gestion des erreur à l'intérieur du code.

Généralement on arrive devant un des cas suivants:

• L'exception est lancée dans un contexte transactionnel, dans quel cas le catch et le finally doivent s'assurer de faire le rollback, et laisser la classe appellante faire son rollback aussi. Dans ces cas là on ne veut pas gérer l'exception elle même, seulement s'assurer du bon fonctionnement du code.
• L'exception est lancée à un niveau du stack directement causée par une action de l'utilisateur (par exemple, un paramètre invalide non vérifiable par des validateurs, ou une valeur invalide dans le querystring). Dans ces cas là, on peut simplement gérer l'erreur sur place (afficher une page disant que la page a reçu un paramètre invalide) ou, ma préférence personnelle, laisser l'erreur remonter jusqu'au handler principal (généralement le Main dans une application windows, ou le Global_asax.Application_Error dans les application web).
• L'exception est récupérable (par exemple, le caching plante). Dans ces cas là (plutôt rares), simplement récupérer (et s'assurer qu'il n'est pas possible d'éviter qu'il y aie une exception en remplaçant le code fautif par une vérification des paramètres! Les exceptions ne devraient jamais faire partie intégrante d'un flow "valide" du code) et publier l'erreur.
  

Lire la suite sur christianrondeau.net

Je speak C#

Une grande question, difficile à répondre; dans quelle langue doit-on déclarer ses variables, méthodes et classes? Dans quelle langue devrait-on écrire ses commentaires?

La syntaxe

Premièrement, il faut noter que je suis un francophone aguerri, prêt à bondir pour défendre sa langue. Mais, car il y a un mais, un problème survient; lorsqu'on développe une application, on utilise un langage de programmation. Ce langage est en quelque sorte une langue à part, un sous-ensemble de l'anglais. Sa structure et ses mots correspondent à l'anglais. Quels sont les impacts? Une lecture naturelle.

Lire la suite sur christianrondeau.net

Deux, c'est bien, mais un, c'est mieux!

Un petit article sur un détail important mais qui, je crois, n'a pas été beaucoup discuté; le nombre d'appels sur des objets dans une ligne de code.

Prenons par exemple la ligne de code suivante, ou employe est un paramètre de méthode:

int assignements = employe.GetHoraire().GetAssigments(this.jourEnCours).Length;

Elle peut paraître exagérée pour certains, mais elle représente plusieurs cas que j'ai vu et que j'ai fait. Beaucoup auront prévu le coup; en production l'erreur suivante est lancée:

Object reference not set to an instance of an object.

*musique dramatique* béât devant son courriel d'erreur (car bien sûr le programmeur fautif s'est sagement envoyé le stack trace ainsi que le nom de l'utilisateur connecté, la page visualisée et la date).

Lire la suite sur christianrondeau.net

Un éditeur de code semi-graphique

Dans la veine de Le code; un simple format de spécifications?, voici une idée qui pourrait peut-être devenir une jointure possible entre les avantages des modèles graphiques et les éditeurs déjà très avancés disponibles aujourd'hui. Elle éveillera peut-être quelques gens ayant travaillé avec Macromedia Flash.

Vérifions certains requis pour une solution applicable:

• Le code doit rester flexible
• On doit pouvoir coder aussi rapidement qu'en mode textuel pur
• On doit pouvoir accéder à des vues différentes en navigant et en contexte
• Une application de collaboration et de développement devrait permettre de "voir" autant la documentation que le code d'une manière flexible et fortement typée

Lire la suite sur christianrondeau.net

L'enfer de l'affichage des composites en ASP.NET

Beaucoup de gens ont travaillé avec des composites. Ils s'avèrent en effet utiles pour déterminer des règles imbriquées, des catégories à plusieurs niveaux, des menus récursifs etc. Il est par contre difficile de les afficher en ASP.NET sans transformer le code en monstre. Voici donc l'approche qui, jusqu'à ce jour, s'est avérée la plus simple et maintenable. De plus, celle-ci pourrait être automatisable assez facilement.

Lire la suite sur christianrondeau.net

L'importance d'une bonne vision

Il est impressionnant de voir à quel point la vision logistique d'un projet peut influencer l'efficacité du développement et la motivation d'une équipe. Malgré qu'on tente souvent de minimiser l'information concernant les besoins d'affaire concrets dans une analyse pré-digérée ( surtout dans une grande entreprise ), l'équipe, ayant les deux mains dans La réalisation d'une solution se trouve souvent devant des dilemmes non pas d'implémentation, mais de logique. Certaines demandes peuvent sembler ne faire aucun sens, ou même être issues de mauvaises décisions. Dans d'autre cas, certaines demandes sont contradictoires, et le développeur a le choix entre affronter les preneurs de décision, ou concocter une solution satisfaisant tout le monde, selon son propre avis. Le développeur faisant face à ces problèmes construit une certaine frustration, mêlée à un sentiment d'impuissance. Deux comportements font surface; une colère minant le moral général de l'équipe, ou un abandon: "Bof, tant que j'ai mon chèque de paye...".

Lire la suite sur christianrondeau.net

Les Navigation Nodes; une approche de navigation web

Dans tous les projets web que j'ai eu l'occasion de développer jusqu'ici, un chose est indiscutablement présente: un plan de navigation, spécifiant quelles pages mènent à quel endroit, dans quels contextes et conditions. Ces problèmes m'ont amené à développer (avec l'aide de Stéphane) et implémenter avec succès dans deux projets une méthode que je nommerai ici "Navigation Node".

Problème:

• La navigation est étroitement liée au design, donc difficile à maintenir
• Les changements de flux de navigation demandent beaucoup de tests et de vérifications
• Les URLs dynamiques sont souvent difficiles à gérer
• Il n'y a pas d'endroit centralisé ou gérer la logique de navigation

Solution:

Développer un système de nodes de navigation qui puisse "mapper" le schème fourni par les analystes en utilisabilité au système de manière simple, flexible et possiblement automatisable.

Ceci peut être fait en permettant la création de "nodes" de navigation indépendantes de l'interface utilisateur, gérées de manière centralisée.

Lire la suite sur christianrondeau.net

Le code; un simple format de spécifications?

Lors de nos nombreuses discussions errant entre la philosophie et l'interrogation technique, Stéphane et moi parlions souvent de notre conception du code et du développement logiciel en général. Certaines différences de point de vue mineures, telles que: "devrions-nous mettre des espaces entre la première parenthèse d'une méthode et son premier paramètre?", nous ont vite fait remettre en question notre vision du code. Jusqu'ici, le code était le résultat, là ou tous les processus et l'analyse mènent. Désormais, il n'est à nos yeux qu'une vue pour l'interpréteur ou le compilateur, tout comme les fonctionnalités sont des explications au développeur ou les spécifications pour le client.

La première idée issue de ce principe était de lier de manière forte les éléments des documents d'analyse à travers le code, ainsi qu'aux différents diagrammes. De cette manière, on pourrait facilement juxtaposer les différents éléments dans une vue propre aux besoin d'un rôle. On pourrait aussi aisément suivre les changements autant en amont qu'en aval. On rend donc la documentation manuelle inutile, en plus d'en fournir une exacte et à jour en tout temps, puisqu'elle implémente un ou plusieurs éléments des documents d'analyse. Cette idée serait principalement traduite par une application de collaboration impliquant une structure de contenu extrèmement rigide.

Lire la suite sur christianrondeau.net

Les équipes pop-corn

Suite à un dîner avec deux de mes collègues (soit un analyste et un architecte) touchant l'implantation de processus et méthodologies concrètes dans notre milieu de travail, un sujet intéressant s'est infiltré: dans une entreprise de taille moyenne, les équipes devraient-elles rester groupées, au point d'être considérée comme des ressources indiscociables?

Tom Demarco, dans l'excellent livre "Peopleware" ( il est illégal de ne pas avoir lu ce livre je crois ) parle beaucoup du "Team Jell", c'est à dire le gain immense de productivité du à une cohésion forte entre les membres d'une même équipe. En pratique, ces gains sont assez difficile à évaluer et à défendre. Les équipes pop-corn n'ont aucun ouvrage dédié, à ma connaissance, vantant les mérites incontestables sur le ROI d'une synergie d'équipe statique comme le font tant de livres sur les processus agiles, l'utilisation d'UML ou des procédures strictes de QA.

Pourtant, les effets néfastes de telles méthodes d'attribution des tâches - traits d'entreprises ayant vécu avec des ressources très limitées pour un grand nombre de petits projets? - sont concrets. On pourrait à priori comparer les coûts reliés aux équipes pop-corn à une version miniature des coûts de perte/embauche d'employés. Les équipes sont après tout des mini-structures très semblables à leur conteneur.

Lire la suite sur christianrondeau.net