Pensée : Échographie = Inspection de variable à l’échelle humaine

L’un des défis que je me suis donné pour l’année 2012 est de démarrer un blogue afin d’y documenter tout ce qui ne peut pas entrer en 140 caractères.

Dans cette liste de défis, il y en a un de taille m’attend : La paternité.

L’une des premières étapes de la paternité est l’échographie. L’échographie est utilisée à différentes étapes de la grossesse de votre conjointe. Son but premier est de valider l’état de santé de votre enfant en utilisant un moniteur à ultrasons. Ces ultrasons permettent de voir à travers le ventre de la maman l’état du foetus.

À certaines étapes, les médecins peuvent écouter le coeur et, vers la fin, mesurer certaines parties du corps de l’enfant pour valider le stade de son développement.

De nature, je suis quelqu’un de visuel. Je suis du genre à utiliser des images pour m’aider à représenter certains concepts. Par exemple, la conception de l’enfant peut être représenté par le fait d’exécuter un nouveau processus parallèle à exécution différée.

Pour ma part, j’ai représenté l’idée de l’échographie utilisée pour identifier le sexe de notre futur enfant par la citation suivante.Une échographie c'est vraiment l'équivalent humain de mettre un breakpoint et d'inspecter une variable. (J'ai su que c'était un garçon!)

Vous pouvez aussi constater que la citation a eu un effet fou sur les médias sociaux.

Maintenant que vous avez lu cet article, vous pouvez maintenant comprendre pourquoi qu’à chaque vois que je vois une image d’échographie comme celle-ci :

Je vois, en fait, ceci :

Advertisements

Touver le bon MimeType pour son fichier

Lors d’un développement que j’ai eu à faire récemment, je me suis posé la question suivante : Quel est le MIME type du fichier que je suis sur le point d’envoyer en réponse?

Un MIME type (Ou Content-Type, c’est selon) est l’un des mécanismes important lorsqu’il est temps de distribuer le contenu au client. C’est ce qui permet d’identifier le type de contenu que le serveur vous envoie. Pourtant, de mémoire, je ne pourrais qu’en nommer deux ou trois tout au plus.

Si vous n’êtes pas plus capable de moi d’en nommer par cœur, rassurez-vous car il s’agit de quelque chose qui est normalement géré par votre serveur web.

Pour ceux qui sont du genre à lire des RFC, le RFC 2046 est celui qui définit le standard appelé : Multipurpose Internet Mail Extensions (MIME). Il met sur la table tout ce qui est nécessaire afin d’être en mesure de transférer un fichier binaire à travers un courriel qui est transféré uniquement en texte.

Le concept a été initialement prévu pour le courriel. Son utilisation a été étendue à d’autre protocoles incluant HTTP, comme dans le cas qui nous intéresse.

Prenons en exemple une réponse typique d’une requête à http://en.wikipedia.org/wiki/Internet_media_type.

À la ligne trois, l’identifiant Content-Type nous indique à quel type de contenu auquel nous avons face. Dans ce cas-ci, il s’agit d’une simple page HTML utilisant l’encodage UTF-8.

Le Content-Type est composé de trois éléments sous le format suivant : Type / Sous-Type; charset=Encodage. Sachez que l’encodage est optionnel.

La problématique à résoudre

Il est essentiel d’identifier son fichier lorsqu’on l’envoie au client au risque que ce qui est envoyé va être soit ouvert par la mauvaise application ou même simplement affiché comme un flux binaire à l’écran. Ce qui n’est pas vraiment très très utile.

Il existe plusieurs façon d’arriver à sa fin pour l’identification de son Content-Type. Les façons se résument à :

Ce que j’ai préféré faire

Étant un paresseux de nature, j’ai préféré y aller vers une solution sollicitant le moins d’effort possible. Mes recherches m’ont dirigé vers le repository Github nommé csharp-MimeType-Dictionnary.

Mon premier réflexe a été de me demander pourquoi je n’y avait pas pensé avant? L’idée aussi d’extraire le catalogue des MimeTypes d’un site pour les mettre dans un Dictionnaire par la suite!

L’utilisation de cette librairie est comme vous le comprendrez est très simple :

var mime = MimeTypeDictionary["pdf"]

Sans révolutionner le monde du développement web, ce dictionnaire permet rapidement d’avoir accès au MimeType d’un fichier donné sans avoir à le rechercher sur internet. Pour moi, il s’agit d’une économie de temps. Moins que je passe de temps à chercher de l’information plus je suis productif.

Une fois de plus, il faut remercier internet. :)

Pushstate ou bien comment gérer son historique de navigation en 2012

Dans la foulée des avancées que le nouveau standard HTML5 a apportées, un ajout intéressant a été incorporé à l‘API javascript permettant d’accéder à l’historique du navigateur.

Cet ajout est nommé pushstate. Pushstate permet de dynamiser la navigation de l’historique d’un navigateur sans avoir à rafraichir de la page.

Pushstate, c’est quoi?

Pushstate permet de modifier l’URL d’une page dans le navigateur sans générer un rafraichissementde page web. Le principal avantage de ce mécanisme est qu’il est maintenant possible d’utiliser des URL « Belles » pour modifier l’état de navigation d’une application web en AJAX, par exemple. Par le fait même, l’utilisation de l’appel à pushstate va génère un ajout à l’historique de navigation de votre navigateur.

L’ennemi : Le Hashbang

Depuis la venue des applications avec une navigation 100 % côté client en AJAX, l’état de la navigation est défini avec le hash dans l’URL. Dans le jargon du web, cet élément est aussi appelé le Fragment Identifier.

Le hash est la partie suivant le # dans l’URL. Par exemple, dans l’URL https://mail.google.com/mail/u/0/?shva=1#inbox, #inbox est le Fragment Identifier.

Cette technique exploite le concept que lorsqu’on modifie le hash de l’URL, il est possible de modifier l’historique de navigation de l’application web que l’on utilise. Le meilleur exemple de cette navigation est probablement GMail où il est possible de passer d’une section à l’autre sans rafraichissent de page et avec un historique de navigation modifiée.

Historique gmail

Le principal désavantage de cette technique est que le hash n’est pas communiqué au serveur. Tout se passe au niveau du client, c’est-à-dire le navigateur.

Puisque le hash  est utilisé côté client, il s’avère que cela n’est pas vraiment compatible avec les moteurs de recherche. Ceux-ci, dans la majorité des cas, indexent que du texte brut sans transformations par le client en Javascript.

Toutefois, un mécanisme a été mis en place par Google afin de faire en sorte que les applications web AJAX soient indexables. Toutefois, l’implémentation de celui-ci n’est pas garantie par tous les services en ligne où vous pouvez partager un lien.

Ce mécanisme fait en sorte qu’une URL comme www.example.com/ajax.html#!key=value soit transformé par www.example.com/ajax.html?_escaped_fragment_=key=value. Ce n’est pas très beau et pas très naturel.

La solution

La documentation du standard HTML5 est assez clair. Les applications AJAX ne doivent pas dépendre d’un mécanisme utilisé initialement pour positionner le client dans un document donné.

Une application web AJAX doit garder les deux propriétés suivantes :

  • Utiliser des URLs lisibles et simple permettant de naviguer dans l’application.
  • Être indexée par google.

Un bon exemple qui pourrait tirer profit de cette technique est le site Twitter qui est connu pour son utilisation abusive du hashbang pour sa navigation.

Lorsqu’on visite la page de mon profil sur Twitter, l’URL https://twitter.com/pparadis est automatiquement traduite à https://twitter.com/#!/pparadis.

Le concept proposé ici par HTML5 est d’éliminer complètement la redirection vers https://twitter.com/#!/pparadis et d’utiliser des URL normalement constituées pour naviguer dans l’application.

Dans le concret?

L’implémentation du pushstate dans votre page web nécessite deux éléments, au minimum.

  • Implémenter l’évènement window.onpopstate = function(event) { return; };
  • Générer un l’évènement comme : history.pushState(null, null, link.href);

En termes clairs, l’évènement onpopstate va être généré à chaque fois que vous appuierez sur le bouton précédent et/ou suivant de votre navigateur. La même chose s’applique si vous faites un history.back(); en javascript.

Le facteur clé permettant une plus grande acceptation du pushstate dans les solutions AJAX est le support dans les navigateurs web. Les navigateurs Chrome et Firefox sont déjà bien en avant avec le support pour pushstate. Toutefois, le support de celui-ci avec Internet Explorer est prévu seulement pour la version 10.

Pour arriver à implémenter la réécriture de l’historique de navigation à travers une majorité de navigateurs, l’utilisation de la librairie history.js. Cette librairie expose un API unifié et testé à travers une multitude de navigateurs de différentes époques. history.js suggère même que la librairie fonctionne aussi sur Internet Explorer 6. C’est pour dire!

En fin de compte

L’utilisation du pushstate va devenir un incontournable avec les applications AJAX sur le web dans les prochains mois et les années qui vont suivre.

L’implémentation la plus utilisée de pushstate est probablement celle réalisée par le très populaire site d’hébergement de code en ligne Github. Depuis décembre 2010, le site utilise pushstate dans la navigation des repository. Le tout se fait en javascript et CSS3 dans une fluidité déconcertante.

Alors, pourquoi pas votre site? Et pourquoi pas maintenant?

Source(s)

À quelle vitesse Google indexe le web?

L’indexation a toujours été au coeur des préoccupations de Google. L’idée est facile à comprendre : plus le contenu est à jour, plus il sera pertinent et recherché.

Or, le dernier article de Code18 au sujet de la mystérieuse épinglette avait piqué ma curiosité. Sans être en mesure d’identifier le dit objet en question, j’ai décidé d’en faire une recherche sur Google.

Instinctivement, j’ai décidé d’inscrire les mots clés « épinglette homme étoile » dans Google. À ma grande surprise, j’ai constaté que l’article fraichement mis en ligne avait déjà été indexé par Google… quatre minutes de sa publication.

Il n’y a pas de mesure exacte fournie par Google afin de déterminer à quelle fréquence son site sera indexé. Google préfère se garder ce droit de réserve.

La fréquence d’indexation d’un site est déterminé par une multitude de critères. Dans ces critères, il y a notamment le PageRank, l’algorithme développé par Google afin de déterminer la popularité d’une page web.

À ses débuts, au début des années 2000, l’indexation du web par Google pouvait prendre jusqu’à quatre mois. La vitesse à laquelle le contenu est indexé a été significativement améliorée vers 2003. Une mise à jour majeure de l’engin d’indexation a été mise en place afin d’indexer le contenu de façon incrémentale. Réduisant ainsi de façon marquée le temps et l’énergie nécessaire pour indexer le web.

De puis ce temps, il est possible de remarquer que Google donne une indication en temps depuis l’indexation du résultat de recherche et la tendance est toujours vers une indexation de plus en plus rapide du contenu.

Je dois l’avouer. Je suis assez impressionné par cette découverte! Et je ne suis pas le seul. T’es rapide Google!

Design Pattern : Programmation chainée

Un objectif que je me donne en développant du code c’est de limiter le nombre de caractères que je dois taper pour réaliser ce que j’ai à livrer.

Bref, il faut tapper le moins de code possible. Ce qui rejoint parfaitement l’objectif du Spartan Programming et facilite par le fait même la maintenance et facilite la compréhension du code.

Voyons la situation classique d’instanciation d’objet :

Ce que je n’aime pas dans ce code c’est la répétition de la variable smtpServerConfiguration. Tout ce que cela fait, c’est d’ajouter du bruit autour du but actuel du code.

Voilà qu’entre en jeu la désignation chaînée (Fluent Interfaces). Le but de la désignation chaînée est de pouvoir faciliter l’écriture de code en chaînant l’appel des fonctions.

De cette façon :

La conception d’une classe permettant ce genre d’appels est très simple et sa mise en place est liée étroitement à la programmation orientée objet.

Pour ceux d’entre-vous qui font du C#, ce genre d’appels doit vous sembler familier. Il s’agit en effet d’un des deux modes de requête possible avec LINQ. La désignation chaînée a été popularisée avec la venue de LINQ dans le monde .NET où il est possible du code comme celui-ci :