Archives mensuelles : février 2016

Les liens de la semaine – Édition #173 (bissextile, en plus!)

Développement

.NET

Technologie

Web

Science et autres

Conférence ConFoo 2016 – J’y serai!

confooCette année, je vais avoir l’opportunité d’aller assister à la conférence ConFoo. Il s’agit d’une des plus imposantes conférences liées au développement logiciel qui se donne dans la ville de Montréal. Au total, il s’agit de 155 présentations qui se donnent sur trois jours au total.

En plus du volume de présentations, c’est aussi les sujets qui sont variés. Elles passent de l’architecture logicielle, par le JavaScript et jusqu’à la gestion d’une équipe de développement.

Ce genre de conférences proposent beaucoup de petites présentations en condensé. Le but n’est pas d’aller chercher des connaissances approfondies, mais d’aller chercher certaines bases qui alimenteront des solutions pour des projets à venir.

Pour moi, il s’agit d’une occasion d’aller explorer de nouvelles façons de concevoir la technologie et ainsi pouvoir en faire bénéficier les solutions que je développe pour mes clients. Je compte bien profiter de chacun des moments que je vais passer là-bas pour apprendre quelque chose de nouveau.

Alors, comment vais-je occuper mon temps à ConFoo? Voici mon plan de match.

Mercredi

  1. XSS moderne : Protections et contournements
  2. Composing amazingly reusable UI with React and Flux
  3. Node.js Authentication and Data Security
  4. Making the Web Easy
  5. You don’t need JavaScript for that!

Jeudi

  1. Level Up Your Team
  2. Beyond REST maturity levels: Real life, high-load REST APIs
  3. Deliver More, Stress Less with Kanban (ex aequo avec How Roslyn has revitalized .NET Open Source)
  4. Horizontal vs Vertical Scaling
  5. Making .NET Applications Faster (je me garde une petite marge pour Hack Better, With SCIENCE!)
  6. UML Diagrams for Web Developers

Vendredi

  1. The hidden cost of bad code (and how to avoid it) ou Security Theatre
  2. Database Architecture for SaaS
  3. How I Learned to Stop Caring and Made Better Software
  4. Building Reactive Services using Functional Programming ou GPUs – Not Just for Graphics Anymore
  5. Surviving the Developer/Lead/Manager Transitions
  6. Devenez le plus heureux des Front-end avec Gulp.js ou Now What? Relearning What you Know in ASP.NET 5

Il y a des plages horaires où les choix sont plus difficiles que d’autres. Dans ces choix j’ai tenté de conserver un équilibre entre aller chercher de nouvelles connaissances, mon avancement personnel et aller chercher un petit plus pour faire avancer certains projets au bureau. Après tout, pour le dernier point, c’est l’boss qui paie après tout!

J’ai bien hâte que ça commence! En fait, je me sens comme un enfant la veille de Noël. Après avoir révisé mes choix pour les sessions, je crois bien devoir me coucher tôt, car les journées vont être pas mal occupées!

Par pure curiosité: est-ce qu’il y a d’autres lecteurs qui y seront?

Les liens de la semaine – Édition #172

Développement

.NET

Web

Technologie

Science et autres

Les liens de la semaine – Édition #171

Développement

.NET

Web

  • Dragula, une librairie qui simplifie au maximum le concept de drag & drop dans une page web.
  • mjml, un framework permettant de développer des courriels responsive.

Technologie

Science et autres

Tweet de la semaine

Un refactoring ne se limite pas à supprimer un commentaire

Un des principes que j’applique le plus lorsque je développe est celui de la règle du boy scout. La règle du boy scout est basée sur le fondement suivant : toujours laisser un endroit dans un état meilleur que celui où vous l’avez trouvé.

En programmation, cette règle signifie exactement la même chose lorsque vous effectuez un changement dans une classe. Le synonyme de ceci se résume (presque) ainsi.

refactor-all-the-things

Le contexte à l’origine de ce billet est lié au développement sur la plus grosse application web que moi et mon équipe faisons évoluer. Il s’agit d’une application qui a du vécu. Elle existe depuis 2007, pour vous dire.

Sans révéler de détails confidentiels sur cette application, je m’amuse à dire que, si cette application n’existait pas, mon équipe n’y serait pas non plus. Il s’agit de notre pain et de notre beurre. Près de la moitié de nos itérations à trois développeurs y sont dédiées. C’est quand même beaucoup d’heures de développement.

Or, puisqu’il est question d’une application âgée, dit code base qui a du vécu. Sur une ligne du temps, il s’agit d’une application qui a connu la transition de la fin de .NET 2.0 à .NET 4.5. À la lecture du code, il est intéressant de constater cette évolution dans les façons de coder et par le style de programmation de chacun des individus qui ont contribué au projet avec le temps.

Cependant, au-delà de la curiosité anthropologique, du code âgé signifie aussi qu’il y a du ménage à faire. En particulier aux endroits qui n’ont pas vu beaucoup d’évolution ces derniers temps. Une des pratiques que je tente d’endiguer dès que j’en ai l’occasion est ce que je nomme la surcommentarisation du code.

Je nomme cela aussi l’effet //this is bridge

Vous avez tous déjà vu un extrait de code qui ressemble à celui-ci.

Je suis assez contre l’utilisation des commentaires dans du code. Je me dis qu’il s’agit de la pire documentation qui peut exister. Bien souvent, les commentaires ne font qu’ajouter du bruit inutile à du code qui aurait besoin d’être simplifié.

Parfois, un commentaire peut aider à expliquer un contexte derrière la mise en place d’une solution. À cela, je réponds que je préfère avoir un code plus explicite, mais qui décrit exactement qu’il fait. Par exemple, un commentaire peut être remplacé par une méthode avec un nom significatif qui englobe une ou deux lignes de code. C’est plus long, mais plus clair.

L’avantage est qu’une méthode avec une si petite portée est significativement plus facile à nommer. De plus, ces méthodes ont tendance à faire une seule chose et la comme il faut.

Même si je suis contre l’utilisation des commentaires, même s’il est rare, je concède qu’il peut toujours y avoir un bon contexte pour un commentaire. Tout est une question de modération. Cela est sans rappeler l’histoire du garçon qui criait au loup. À force d’inclure trop souvent des commentaires, on finit par perdre de vue l’essentiel avec le concept d’origine. C’est à dire mieux communiquer ses intentions et faire en sorte que les bogues se tiennent loin du troupeau.