Bonne fête French Coding: deuxième anniversaire!

Le 12 avril prochain est la date de naissance de ce blogue. Bonne fête à moi-même!

crazy-kid-birthday-gif[1]

J’ai envie de réécrire la même chose que j’ai écrite l’an passé. Écrire sur ce blogue me permet d’expérimenter et de réfléchir sur un paquet d’idées.

Sans blague, j’ai énormément de plaisir à le faire. Ce qui me fait encore plus planer, c’est ce graphique:

visites-fc

Ça, c’est l’importance qu’accordent les visiteurs à mon travail. Le nombre croissant de visites est le meilleur cadeau que je puisse recevoir. Ça fait chaud au cœur. Merci.

À quelques reprises, j’ai eu envie de prendre une pause ou de simplement arrêter. Que mon temps était mieux investi ailleurs. À tous les coups, après une journée ou deux, je retourne à l’écriture. L’écriture finit par être quelque chose qui me chatouille les doigts. Il y a toujours quelque chose à découvrir, à documenter.

Découvrir, documenter. C’est ça la raison d’être de French Coding. Après deux ans, j’aime encore plus qu’au départ écrire!

En plus, je trouve que mon français écrit s’est amélioré.

Il y a une chose que je répète souvent à mes amis au sujet de ce blogue. Trop souvent on voit des gens partir un blogue sur un coup de tête et le laisser à l’abandon après un ou deux billets. C’est la dernière chose que je souhaitais avec cette aventure.

Principalement parce qu’il s’agit d’une trace à l’encre indélébile sur le web et surtout parce que je ne suis pas du genre à commencer quelque chose sans le finir.

Statistiques en vrac

Les liens de la semaine – Édition #75

Développement

.NET

Web

Technologie

Parlant de Heatbleed, voici certains liens en relation avec cette nouvelle:

Science et autres

Ma vie de programmeur, en images – partie III

Lorsque j’écris de la documentation

tiger-sleep

Lorsque je vais dîner avec mes collègues

turkey-gang

Une journée typique de programmeur

ibaDjk7AeIcvxv[1]

Lorsque je viens en aide à un collègue qui a un problème avec son code

3ThYXrj[1]

Lorsque je suis dans le mood pour développer

D6x5ie2[1]

Ma solution se fait dérouter au moment du contrôle qualité

CaiObKz[1]

Le site est en panne?

DT0UoMO[1]

Un message au à la personne qui apporte des beignes au bureau

clam

Comment je m’imagine lorsque je fais du refactoring sans tester

eIAZUaS[1]

La sensation que donne de démarrer un nouveau projet

izx3PMafci5V3[1]

Lorsque c’est moi qui se pousse avec le dernier beigne du bureau

MQ6GhR1[1]

Lorsqu’un git pull rend le projet non fonctionnel sur mon poste

rv-hit

Les liens de la semaine – Édition #74

Développement

.NET

Web

Technologie

La barre oblique dans l’URL, oui ou non?

Votre grand-maman vous l’a peut-être déjà dit dans le passé: « le diable est dans les détails! » Les choses ont tendance à se compliquer lorsqu’on creuse un peu plus profondément dans les détails d’implémentation.

Dernièrement, dans mon équipe, il s’agit de la question de la barre oblique en fin d’URL qui s’est invitée dans le débat. Il était de savoir quel format adopter pour les URL du projet web du client que nous débutions.

En fait, le débat a démarré sur la préférence du client pour que les URL comprennent en tout temps la barre oblique à la fin. Concrètement, le souhait est que les URL aient la forme suivante : http://frenchcoding.com/2014/03/17/les-liens-de-la-semaine-edition-71/.

Ma première réaction a été d’émettre des critiques et des réserves à cette décision. À mes yeux, la barre oblique en fin d’URL ajoute inutilement un caractère à une URL. Une URL est avant tout conçue pour les humains et doit être sans source d’erreurs possibles.

C’est à ce moment que mes recherches à ce sujet ont débuté. Rapidement, j’ai su que j’avais tort de croire que j’avais absolument raison sur ce point. La problématique est plus philosophique que concrète.

Historique

Le format d’une URL est intimement lié aux chemins de répertoires de type Unix. Un fichier se situe dans un répertoire comme /var/www/type/ficher.tar.gz. Cette convention a aussi été conservée pour le protocole HTTP et ses cousins.

Cette décision a beaucoup de sens lorsqu’on y pense. Toutefois, lorsqu’on creuse dans le détail, il faut se rendre compte de l’évidence suivante. Selon la philosophie UNIX, un chemin d’accès comme /chemin/accès/ représente un répertoire tandis que /un/chemin représente un fichier qui peut être téléchargé.

L’argument de laisser tomber la barre oblique en fin d’URL tiens uniquement de l’idéologie, car il a été clairement affirmé par Google que cela a aucune importance pour son algorithme d’indexation.

La seule règle à suivre

Vous trouvez qu’une URL ayant une barre oblique en fin d’URL est jolie? Tant mieux. Cela importe très peu dans l’équation, en réalité. Ce qui doit, cependant, être fait est de s’assurer que l’un ou l’autre des formats soit accessible sur votre site.

Ce qui est souhaité dans cette situation c’est qu’une requête à une page dans le mauvais format redirige vers le bon format. C’est tout. La redirection à opter dans ce cas est une redirection 301.

Alternativement, si vous n’êtes pas en mesure de faire une redirection automatiquement, vous pouvez faire en sorte que les contenus dans le format d’URL incorrect contiennent un lien ayant l’attribut rel="canonical".

Sources

http://stackoverflow.com/questions/3888997/dynamic-urls-with-or-without-a-trailing-slash/3889636#3889636

http://stackoverflow.com/questions/5948659/trailing-slash-in-urls-which-style-is-preferred

http://googlewebmastercentral.blogspot.ca/2010/04/to-slash-or-not-to-slash.html

http://moz.com/learn/seo/canonicalization

http://stackoverflow.com/questions/696673/lower-case-urls-in-asp-net-mvc

Suivre

Recevez les nouvelles publications par courriel.

Joignez-vous à 318 autres abonnés