La rétrospective de ma dernière performance de course au 10km de LaSalle

Le 29 mars dernier, j’ai participé au 10 kilomètres de la Course et Marche Populaires de LaSalle. Il s’agit de la quatrième fois que je participais à une compétition sur cette distance depuis que je me suis initié à la course à pied en 2013.

Plus tôt cette année, j’ai écrit à propos de mes objectifs de course pour cette année. Cette course-ci entre dans la phase de « test » dans le plan d’entraînement de dix semaines qui atteindra sa fin le 10 mai prochain pour le demi-marathon de Châteauguay.

Ce dix kilomètres comptait pour beaucoup pour moi, car il me permettait de confirmer trois choses:

  • savoir que mon entraînement hivernal aura servi à quelque chose.
  • que mon idée de perdre du poids (~12 kilos) aura été bénéfique sur ma performance finale à la course
  • que je suis sur la bonne voie sur mon objectif de compléter mon demi-marathon en moins de 02h10m

La course en chiffres et en une image

course-lasalle-resultat

Ce que vous voyez ici c’est les données extraites de mon compte RunKeeper. Mon temps officiel est de 00:54:58.6. J’ai dépassé mon objectif de moins de deux secondes. Faut-il mentionner que j’étais très très fier de mon résultat?

L’analyse des données graphiques de ma performance m’a révélé une chose très importante. La constance dans le rythme est ce qui fait la différence entre une bonne et une mauvaise course. En quelques lignes, voici comment on peut analyser le graphique du rythme (le bleu).

  • J’ai démarré la course à un rythme prudent. L’équivalent de mon R3 (~5:40 minutes/km).
  • Par la suite, j’ai graduellement augmenté la cadence pour atteindre R2 jusqu’au huitième kilomètre.
  • Vers le 8e kilomètre, sachant que j’étais un peu en retard dans l’atteinte de mon objectif de 55 minutes, j’ai tout donné pour atteindre une pointe de ~4:30 minutes/km. Soit un peu plus rapide que mon R5 d’entraînement.

En ce qui concerne le graphique du rythme cardiaque, il est proportionnellement inversé à celui de mon rythme de course. Je considère que c’est une bonne nouvelle. J’ai couru plus vite. Il a pompé plus fort.

D’ailleurs, je dois une fière chandelle à ma nouvelle montre GPS TomTom Runner Multi-Sport Cardio. C’est principalement grâce à elle que j’ai pu garder un aussi bon rythme durant cette course. Je vais lui dédier un billet très prochainement. Un très bon achat!

La suite…

Mon prochain rendez-vous avec la compétition sera le vrai test. La distance pour laquelle je me suis entraîné depuis la mi-février. Le demi-marathon.

Au moment d’écrire ceci, je suis en pleine forme et surtout, débordant de confiance à l’idée de faire cette course. À la vitesse où je progresse dans mon entraînement, je suis même tenté par l’idée de considérer d’augmenter la cadence d’entraînement pour ma deuxième série de dix semaines d’entraînement en vue du demi-marathon au Marathon de Montréal. Je le ferais pour tenter de faire un temps sous la barre des deux heures.

Pour l’avoir vécu à deux reprises, courir un demi-marathon est une expérience particulière. Malgré toute la préparation du monde, vos limites seront assurément testées.

Je m’emballe un peu. Je sais… je sais. Toutefois, je crois qu’il n’y a pas de petit défi dans ce domaine! Il suffit d’y mettre un peu d’efforts.

Les liens de la semaine – Édition #126

Développement

.NET

Web

Technologie

Science et autres

Comment arriver à sécuriser une application ASP.NET MVC?

padlockL’autre jour, j’étais à la recherche de bonnes pratiques pour l’implémentation d’une page de connexion utilisant ASP.NET MVC. Cela faisait un petit moment que je n’avais pas eu l’occasion d’en faire. J’avais besoin de me rafraîchir la mémoire.

Après avoir consulté quelques pages sur le sujet, un exemple provenant de Microsoft utilisait l’attribut AllowAnonymous sur l’action de contrôleur de connexion. Ça a piqué ma curiosité, car la majorité des autres exemples n’en faisait pas l’usage.

La première conclusion à tirer de ceci est que la majorité de développeurs ayant publié leur code sur le web ne connaît rien à la sécurité web. Je ne suis moi même pas un expert. Toutefois, il s’agit d’un fait à assumer lorsqu’il est question de sécurité informatique.

En deuxième lieu, il ne faut jamais prendre du code du web sans s’assurer de comprendre ce qu’il essaie d’accomplir. C’est encore plus important lorsqu’il est question de sécurité et d’authentification web.

Pour faire simple et pour revenir à mes moutons, l’attribut AllowAnonymous est un mécanisme permettant au développeur d’autoriser l’accès, à une requête anonyme (lire non authentifiée), à une action de contrôleur ou à toutes les actions d’un contrôleur.

Un exemple classique de cela peut être tiré directement de MSDN.

[Authorize]
public class AccountController : Controller
{
public AccountController () { . . . }
[AllowAnonymous]
public ActionResult Register() { . . . }
public ActionResult Manage() { . . . }
public ActionResult LogOff() { . . . }
}
//exemple tiré de https://msdn.microsoft.com/en-us/library/system.web.mvc.authorizeattribute%28v=vs.118%29.aspx#exampleToggle

view raw
authorize.cs
hosted with ❤ by GitHub

Dans cet exemple, un appel aux actions Manage et Logoff vont retourner un code HTTP 401. Au contraire, l’action Register sera publiquement accessible. Cela tombe sous le gros bon sens, n’est-ce pas?

Il faut savoir que cette façon de faire est l’un des mécanismes à votre disposition pour sécuriser votre application web. Par exemple, un scénario plus avancé, uniquement accessible aux développeurs ASP.NET 5, serait d’avoir recours à OWIN pour implémenter la sécurité de votre application.

C’est une question de besoin, réellement.

Ceci étant dit, la seule chose à savoir c’est qu’il ne faut pas recourir à la sécurisation en utilisant le web.config. Il s’agit de la pire option, car elle assume que vous sécurisez l’accès à des chemins physiques. Une action de contrôleur peut être accessible par plusieurs chemins. Les choses peuvent déraper rapidement dans ce scénario.