Archives mensuelles : décembre 2015

La revue de l’année 2015

La nouvelle année est à notre porte. C’est l’heure de faire un bilan de la dernière année de ce blogue. J’aime beaucoup faire ce genre de rétrospective, car cela me permet de revoir l’évolution de mon travail de l’année. Cela rend la chose particulièrement intéressante, car les sujets que j’aborde dans mes billets sont régulièrement influencés par mon quotidien.

Ceci étant dit, l’année 2015 a été une année assez occupée et parsemée de changements pour ma part. Elle l’a été pour ce blogue, d’un point de vue personnel et professionnel.

Les grandes lignes étant celles-ci:

  • Nouvel emploi
  • Dépassement des objectifs à la course à pied
  • Naissance du deuxième enfant

Je l’ai mis à la fin de la liste, mais, honnêtement, mes enfants sont la plus grande source de fierté et de bonheur dans ma vie. Les parents que je connais sont unanimes. Je ne pensais pas éprouver de l’amour aussi fort que depuis que ces petites créatures sont dans ma vie.

Ceci étant dit, pour ce qui est de French Coding, le défi a été plus grand cette année. En particulier dans la période de l’automne. L’inspiration a été un peu plus difficile à aller chercher et le temps a commencé à me manquer un peu plus avec la venue du deuxième marmot.

Chose certaine, les vacances des fêtes ont porté ses fruits. J’ai fait le plein d’idées de billet pour les semaines à venir. De quoi m’occuper pour un bon moment.

Côté objectifs, l’an passé, je m’étais dit que je voulais faire autre chose que du web avec .NET. J’avais même reçu une suggestion de jeter un coup d’oeil à Elm. L’idée était bonne (et l’est encore, d’ailleurs. Merci, Fred!).

Cependant, les choses ne se sont pas passées ainsi. Avec mon changement professionnel, j’ai fait la transition du développement de sites web au développement d’applications d’affaires web.

C’est toujours du web, j’en conviens. Toutefois, il y a une grande importance à donner à la qualité du code. C’est ainsi que je me suis prononcé à ce sujet à plusieurs reprises ces derniers mois.

Les chiffres

Billets

Visites de l’année

visites-2015

Au moment d’écrire ceci (29 décembre – 14:35), il y a eu 39 414 visites pour l’année 2015. Au rythme où les visites se produisent, il y a de très bonnes chances que je puisse franchir le cap des 40 000 visites. Merci beaucoup!

Le billet du mois

Pour cette année

L’année 2016 sera la quatrième année de French Coding. C’est quelque chose que je dis souvent: le temps passe vite quand on s’amuse!

Cette fois-ci ce sera la bonne. La quatrième année de French Coding sera celle où l’identité visuelle du blogue sera rafraîchie. Cela fait assez longtemps que je désire avoir une colonne de droite pour y afficher du contenu. C’est cette année que ça va se produire. Tenez-vous-le pour dit!

C’est tout pour les objectifs. Le restant ce sera que de la continuité dans ce projet qui est d’écrire sur ce qui me plait une fois par semaine (en moyenne!).

Pour le reste, je vous souhaite une bonne et heureuse année. Réalisez vos projets. Codez et geekez autant que possible. Année 2016, à nous!

giphy

Advertisements

Les liens de la semaine – Édition #164

Développement

.NET

Technologie

Web

Science et autres

Puisque Star Wars est à la mode ces temps-ci, je vous laisse une blague de très mauvais goût à ce sujet…

Comment lister les couleurs de System.Drawing.KnownColor avec C# (et joyeux Noël!)

Je travaillais à développer une fonctionnalité de calendrier pour un projet. Il s’agissait de mettre en place une grille d’activité sur une plage horaire d’une semaine de travail en utilisant le composant Scheduler de KendoUI. Cette partie s’est super bien déroulée. Comme planifié. Rien à signaler de ce côté.

Or, au moment où je développais mon petit bout de fonctionnalité, la palette de couleur qui permet d’identifier les différents éléments composant le calendrier n’était pas encore établie.

Alors, quoi faire dans ce cas-là? Je suis particulièrement pathétique lorsqu’il est temps de faire usage d’une créativité artistique. Ma solution devait être aussi jetable et de courte durée, car j’allais recevoir la palette de couleur à utiliser en cours d’itération.

Dans ce cas, je me suis dit qu’il fallait avoir recours à System.Drawing.KnownColor afin d’utiliser leur code hexadécimal pour les utiliser en CSS. Qu’est-ce que System.Drawing.KnownColor? Il s’agit d’une énumération qui identifie les couleurs système de Windows. Elles sont laides et peu originales, mais ce sont des couleurs qu’il est possible de référencer avec du code.

C’est un peu simplet, mais ça fait le travail, comme on dit. Il est à noter que je procède à un tri en utilisant un GUID unique afin d’obtenir un jeu de couleur différent à chaque utilisation.

Le petit bonus est que la couleur est convertie en son équivalent hexadécimal pouvant être utilisé dans un style CSS (ex.: « #4D5B32 ») grâce à la dernière ligne du code. Il s’agit d’extraire la composante rouge, verte et bleue de la couleur et transformer sa valeur hexadécimale (l’utilisation du motif « X2 » de ToString()).

~~

En cette veille de Noël, je profite de cette occasion pour vous dire merci et vous souhaite tous de passer de joyeuses fêtes! Profitez en bien!

Les liens de la semaine – Édition #163

Développement

.NET

Technologie

  • J’ai trouvé ce site bien intéressant. useronboard.com fait l’analyse de l’expérience d’accueil sur un site ou une application

Web

C’est l’histoire d’un refactoring, vois-tu?

J’ai souvent abordé le sujet de la qualité du code sur ce blogue. C’est un sujet qui me passionne énormément. Je crois sincèrement que la qualité du code est intimement liée à l’importance accordée à la pratique de la programmation.

À mon avis, le souci de la qualité du code n’est pas nécessairement de connaître en détail les implémentations des design patterns du Gang of Four. Il s’agit d’avoir le souci du détail et, c’est étrange de dire ceci, de faire preuve d’amour envers ce que l’on code.

Cette semaine dans les liens de la semaine, j’ai lié le billet Relax. Everyone’s Code Rots. Lorsque l’on produit quelque chose, il faut s’attendre qu’après quelque temps, la solution ne soit plus au goût du jour. C’est normal, en fait.

Cependant, une solution développée avec le souci de la qualité a souvent une qualité qu’il n’y a pas ailleurs. Il s’avère que la maintenabilité de celle-ci est significativement plus simple. C’est souvent très facile d’identifier les composants et ce qu’il doit être fait pour modifier des fonctionnalités.

no-overload

Il y a un pattern que j’ai vu régulièrement revenir dans des applications que j’ai eu à maintenir dans les dernières années. Il s’agit de celui où une méthode va détenir une quantité phénoménale de paramètres à recevoir, car elle est responsable d’aboutir le résultat d’un grand nombre de traitements qui ont été préalablement exécutés.

Le problème avec cette façon de faire est à plusieurs facettes:

  • Cette méthode est invoquée dans le cadre d’exécution Top-Down (ascendante). Habituellement, la méthode dans le bas est impossible d’être dissociée de la pile d’exécution
  • Il est strictement impossible de mémoriser l’entièreté des paramètres qui sont gérés par cette méthode
  • Lorsqu’on modifie la signature de la méthode, un problème comme celui affiché à droite est créé. 26 erreurs pour une méthode qui accepte 20 paramètres.
  • Par le nombre de paramètres qu’elle accepte, cette fonction fait, conséquemment, un très grand nombre de choses en même temps.

Habituellement, la maintenance de ce genre de contexte est très difficile, car, à tous les endroits où cette méthode est appelée, le contexte n’est généralement pas le même. Vous avez donc affaire à « ce code » auquel personne ne veut réellement toucher.

Il est difficile de régler un cas comme celui-là rapidement. Il n’y a pas de remède facile. La stratégie à adopter dans un cas comme celui-là est en deux volets.

  • Diviser la fonction principale (CreateRow) en plus petites méthodes. Cela aura pour effet de donner un peu plus de visibilité sur l’interaction de la méthode avec ses paramètres. Peut-être qu’il sera plus facile d’identifier certains paramètres à extraire ou à retirer pour les déplacer dans l’appel d’une autre méthode.
  • Procéder à la création d’une classe qui sera utilisée pour regrouper les paramètres de la méthode. Au lieu d’envoyer 20 paramètres, un seul en sera utilisé. De plus, cela aidera à la classification de ceux-ci.

Cela serait une première étape dans le chemin pour faire de ce bout de code quelque chose d’un peu plus agréable à maintenir. L’autre facteur important à tenir compte dans cette opération est le facteur coût/bénéfice de ce refactoring important.

En fait, c’est toujours se demander quelle est la valeur du code en question. Un bout de code qui ne sera pas appelé à être changé ne vaut généralement pas la chandelle en terme d’efforts de développement.