Les liens de la semaine – Édition #207

Développement

.NET

Web

Technologie

Science et autres

Publicité

Ma participation au demi-marathon de Montréal

Officiellement, le marathon de Montréal ne se nomme pas le « marathon de Montréal ». Contrairement à son appellation populaire, son vrai nom est le « Rock ‘n’ Roll Montréal ». Pour moi c’est la seule chose qui est réellement ambiguë avec cette course.

Lorsqu’il vient le temps d’expliquer que l’on va participer à l’épreuve du demi-marathon à cet événement, je n’ai jamais réussi à trouver une façon claire, nette et précise de l’expliquer sans trop causer de confusion. Les variantes sont les suivantes :

  • Je participe au demi-marathon dans le cadre du marathon de Montréal. Non, pas le marathon. Oui, c’est ça le demi. Le 21.1 kilomètres. Hé hé, oui, un marathon un jour, mais pas tout de suite. Juste le demi-marathon c’est suffisant. C’est ça.
  • Je fais le demi-marathon de Montréal
  • Je cours un demi-marathon à Montréal. Oui, t’sais, la grosse course qui pars sur le pont Jacques-Cartier? Oui, oui, c’est ça. Le demi. Pas le gros Marathon.

Dans tous les cas, c’est étrange à expliquer. L’autre chose est que je n’ai jamais entendu c’est quelqu’un qui dit qu’il participe du demi-marathon Rock ‘n’ Roll Montréal. Jamais.

Ceci étant dit, parlons de mon dernier demi-marathon de Montréal.

La course, en chiffres

Le marathon de Montréal est toujours un événement spécial pour moi. C’est beaucoup de choses en même temps. Je pourrais mentionner que le trajet est intéressant (et difficile!) et que l’ambiance rend la chose intéressante. De courir et de voir tous ces gens amassés sur le trottoir rend l’expérience mémorable.

Avant tout, pour moi, il s’agit de la célébration d’une saison d’entrainement à la course à pied. Célébration, vraiment. Elle n’aura pas été facile celle-là. De mars à septembre, je me suis entraîné afin de réaliser mon meilleur temps à cette course. Il y a eu des hauts, des bas et surtout beaucoup d’apprentissages qui ont contribué à me rendre meilleur même si ça ne parait pas au chronomètre.

Temps officiel01:43:30

mtl-temps

Ce qui rend la course de Montréal intéressante est la gestion de celle-ci. Comment devez-vous gérer vos ressources afin de rallier l’arrivée? Les premiers 15 kilomètres se font sur un terrain assez plat. Par la suite, il s’agit d’une ascension par paliers ce faisant de façon assez drastique par moments, d’une descente assez prononcée à la rue Montcalm jusqu’à la fameuse côte Berri qui se prolonge sur une assez longue distance.

Si vous dépensez toute votre énergie au début, il vous manquera du carburant à la toute fin. Je vous le garantis.

Globalement, la course s’est bien déroulée. Au final, il s’agit du même temps que celui que j’ai réalisé à Châteauguay au début de la saison par une différence de vingt secondes. J’aurais bien aimé battre ce temps et me rapprocher de la marque de 01:40:00. Toutes considérations gardées, ce n’est pas un mauvais résultat. Surtout considérant que le trajet de Montréal est significativement plus difficile.

Pour la suite?

J’ai déjà écrit à propos des embûches que j’ai eu à traverser cette saison-ci au niveau course à pied. En particulier vers la fin de l’été où mon objectif de rehausser le rythme de course à l’entrainement n’a pas vraiment pu se réaliser.

Toutes perspectives gardées, je ne dois pas m’apitoyer sur mon sort. Au contraire, je dois prendre ceci comme une occasion de revoir le chemin que j’ai parcouru depuis que je me suis mis à la course à pied. Au niveau de ma forme globale, je suis en forme comme je ne l’ai jamais été.

J’ai déjà confirmé ma présence pour le demi-marathon de l’an prochain à Montréal. Cette prochaine saison sera l’occasion pour moi de déployer une nouvelle stratégie pour atteindre ma cible d’un temps sous 01:30:00. Chose certaine, cette fois-ci, je vais mettre les bouchées doubles côté entrainement pour atteindre mon but.

Chose certaine, si j’ai appris quelque chose cette saison-ci, c’est que j’aime la course à pied. À quelques reprises, j’ai eu envie d’arrêter. De mettre de côté cette activité qui m’occasionne tant de problèmes. À chaque fois, j’ai persévéré et trouvé une solution pour m’améliorer.

Être un meilleur humain. C’est surtout ça le but de l’opération, en bout de compte.

Les liens de la semaine – Édition #206

Développement

.NET

Web

Technologie

Science et autres

Les liens de la semaine – Édition #205

Développement

.NET

Web

Technologie

Science et autres

Humour

Vous ne déployez pas votre application en mode Release? Vous faites erreur!

Vous avez peut-être (ou pas du tout) remarqué cet article dans les liens de la semaine #201. Il y est question du déploiement d’une application en mode « Debug » en production. L’argument est bien simple. Le mode « Release » est synonyme d’application d’optimisations par le compilateur C# sur votre code. Ces optimisations sont, bien sûr, une façon très simple de donner un petit coup de turbo à votre application sans trop d’efforts.

À condition, bien évidemment, que vous pensiez à compiler votre application en mode « Release ». C’est aussi le point de l’article. Ce n’est pas tout. Il y a aussi le mode « debug » à désactiver. Cela se fait par l’entremise de l’attribut debug sur l’élément compilation qui doit être paramétré à « false ».

C’est à cet instant que ça m’a frappé. Si vous déployez votre application autrement qu’en mode debug et compilée en « Release », vous commettez un sérieux faux pas. C’est vraiment l’équivalent de passer « Go » sans réclamer son 200$ côté performance.

J’irais même plus loin. Il n’y a plus vraiment de bonnes excuses pour déployer manuellement une application de nos jours. Le déploiement devrait être une opération automatisée pouvant s’exécuter aussi fréquemment que possible. Les gens qui font des projets cloud n’ont, d’ailleurs, pas vraiment le choix de fonctionner ainsi. Bien souvent, l’accès aux environnements est assez limité.

Sommairement, les options qui s’offrent à nous sont :

  • Un script (Powershell ou équivalent) qui invoque MSBuild pour compiler votre application et préparer le déploiement. Avec .NET Core et le nouveau CLI, c’est vraiment un jeu d’enfant.
  • Utiliser un outillage comme Cake pour automatiser certaines tâches
  • Mettre en place un build server comme CCNet pour connecter votre gestionnaire de source à vos environnements de tests et production

Pour être sincère, bien souvent, la solution est à mi-chemin entre les deux. J’en conviens.

Pour les petites équipes/projets, investir du temps à configurer un serveur CCNet peut être difficile à trouver et à justifier. Je suis le premier à comprendre cela. Cependant, pour travailler dans un environnement où cet effort a été réalisé, le jeu en vaut réellement la chandelle.

Devoir repartir l’automatisation d’un projet demain matin, il est certain que je donnerais un sérieux coup d’oeil à Cake. Toutes les conditions de base de succès sont réunies dans cet outil pour permettre d’atteindre ce but. C’est-à-dire l’automatisation de la compilation et du déploiement d’une application en production.

Par le fait même, un processus de déploiement est simple et automatisé et aussi un synonyme de qualité d’environnement de développement. Dans mon équipe, il y a l’expression que « le build server a rarement tort ». Un déploiement réalisé par une machine tierce permet évidemment de mettre en évidence des pépins qui ne surviendraient pas sur un environnement de développement.

Un processus de déploiement bien rodé est celui où tous les développeurs d’une équipe peuvent déployer à leur guise et au moment qu’ils désirent. Pensez-y! Ne laissez rien au hasard côté déploiements. Automatisez le plus possible. Vous verrez, c’est payant à long terme.