Archives mensuelles : juin 2013

Les Pascaleries : Édition #3 – directement de mon univers!

Après le développement, s’il y a une chose que j’aime faire c’est de parler. Il ne s’agit pas juste de parler pour parler dans le vide. Expliquer des concepts. Les vulgariser pour que les autres puissent comprendre.

Ma façon préférée d’y arriver est d’imager les concepts afin que vos interlocuteurs puissent imaginer ce que vous tentez d’expliquer. Des fois, il arrive que mes comparaisons soient totalement accidentelles. Dans d’autres cas, je semble être possédé d’un élan créatif. Un éclair de génie, genre.

Alors, c’est avec grand plaisir que je présente la troisième édition des Pascaleries. C’est-à-dire la collection des comparaisons et métaphores que j’ai pu utiliser dans mes conversations.

Turbulence – Indisponibilité du site web

Par un certain mardi matin d’été, le soleil brillait et l’air était chaud. Les oiseaux gazouillaient et tout le monde travaillait en harmonie. Une belle journée à l’horizon.

Tout à coup, les courriels entraient par dizaines et le téléphone sonnait autant. On nous disait que son site était indisponible à partir du web. Oups! Une panne momentanée et généralisée.

C’est donc à ce moment que j’ai introduit le concept de période de turbulence sur nos hébergements. Exactement la même comparaison que pour les vols d’avions : la turbulence atmosphérique.

En avion, la turbulence atmosphérique fait en sorte que l’avion va se faire brasser au point de ressentir jusqu’au point que vous pouvez ressentir des secousses relativement désagréables pendant une courte période durant votre vol.

Vouvoiement

Ce qui est assez drôle, c’est que j’ai vraiment appris à vouvoyer de façon naturelle en étant quotidiennement en relation avec la clientèle.
Au début, c’était comme forçant, pas naturel du tout.
Ça m’aura servi.
Un client, administrateur réseau, que j’avais l’habitude de vouvoyer me vouvoyait aussi en retour. La relation était cordiale.
Assez froide, cependant.
Un jour, en révisant les formalités d’un développement à venir, il fallait parler de certaines procédures stockées. En particulier, de certains ajustements qui affectaient le site en entier.
Il m’a sorti : « Écoute, nous allons parler de programmation SQL. Est-ce qu’on peut se tutoyer?« .
Je vais garder ce moment dans ma mémoire à jamais.
J’étais flabbergasté!

« Planter une graine » de façon imagée

vigne-mario

Extrait d’une discussion arrivée véritablement lors d’une discussion avec mon gestionnaire de projets.

– Et puis, Pascal, est-ce qu’il y a du nouveau sur ce dossier?

– Eh bien, j’ai eu une conversation avec le client hier. Nous avons statué sur ce qui a été complété. En ce qui concerne le plan de match pour la mise en ligne qui va suivre, j’ai planté une graine dans le pot de terre et je l’ai arrosé abondamment.

– (regard perplexe)

– J’espère bien que d’ici la semaine prochaine la graine va germer.

Regarder sous un Kilt pour voir de quoi ça a l’air

Un collègue, en introduction de présentation, a une fenêtre du logiciel .NET Reflector d’ouverte à l’écran. J’ai lancé une comparaison qui a causé quelques rigolades dans la salle.

Vous ne trouvez pas que .NET Reflector est un peu comme lever un Kilt pour regarder ce qu’il y a en dessous?

sous-le-kilt

Pour ceux qui ne le savent pas, Reflector est un outil permettant d’analyser le code source contenu dans une DLL de .NET en décompilant le code qu’elle contient. Il s’agit, habituellement, d’une opération de dernier recours quand la documentation ne suffit pas.

Toutefois, je vous recommande très fortement de garder l’utilitaire à portée de main. Il est très utile! Je vous promets que vous ne pourrez pas voir ce qui se trouve sous un kilt!

Advertisements

Les liens de la semaine – Édition #36

quebecAujourd’hui, le 24 juin, c’est la St-Jean-Baptiste, la fête nationale du Québec. Bonne fête à tous les Québécois!

Développement

Web

Technologie

Science et société

Comparer les valeurs « 7.0 » et « 10.0 » avec JavaScript

Dernièrement, j’ai eu à produire un correctif sur un script de détection de version de navigateur assez âgé. Ce script en particulier détectait quelques navigateurs en particulier afin de leur afficher un message comme quoi leur expérience de navigation serait optimale s’ils utilisaient une version récente de Firefox, Google Chrome ou Internet Explorer.

La principale faiblesse de ce script était qu’il faisait une détection de navigateur basée sur le numéro de version.

Une mise en contexte historique s’impose

Le quatre septembre 2012 fut la date où le navigateur Internet Explorer 10 a été mis à la disposition des internautes. Cette version d’Internet Explorer est celle qui respecte mieux les standards du web (HTML5 et CSS3). Sur papier, tout est parfait dans le meilleur des mondes. N’est-ce pas?

Là où j’ai eu à intervenir, est que cette fameuse détection de navigateur se faisait, disons-le, dans le mauvais sens du poil. Il a été mentionné que les visiteurs utilisant Internet Explorer 10 se faisaient présenter l’avertissement de navigateur que j’ai mentionné en introduction.

Tant pis pour eux que je me suis initialement dit. Toutefois, il fallait investiguer et trouver une solution permanente.

Une détection simpliste

À vrai dire, il s’agissait, à mon avis, de la pire méthode possible pour détecter la version du navigateur. C’est à dire, l’utilisation de la fonctionnalité jQuery.browser.

Truc de projQuery.browser est déprécié depuis déjà un bon moment. Ne l’utilisez plus. OK?

L’appel en question avait l’air de la chose suivante : jQuery.browser.msie && jQuery.browser.version <= ‘7’. D’ailleurs, cette ligne en question est présente dans beaucoup de résultats Google.

Or, dans le cas du navigateur Internet Explorer 10, comparer la valeur de jQuery.browser.version à la chaîne ‘7‘ revient à la comparaison suivante : ‘10‘ <= ‘7‘. Exécutez cette comparaison dans la console JavaScript de votre navigateur. Le résultat retourné sera « True« .

10-7

À première vue, le résultat semble incohérent. N’est-il pas un peu étrange que 10 soit plus petit que 7? Si vous regardez comme il faut,vous remarquerez qu’il s’avère que ce sont deux chaînes qui sont comparées. Comment voulez-vous que le compilateur sache quoi faire avec?

À ce point-ci, je présume que l’auteur initial du script n’avait pas pensé qu’il avait affaire à des chaînes plutôt qu’à des nombres. Dans un cas comme celui-ci, JavaScript compare le premier caractère de chacune des chaînes pour déterminer le résultat de la comparaison. Au minimum, pour avoir été cohérent dans l’approche, il aurait fallu utiliser la fonction parseInt afin d’extraire la valeur numérique de la chaîne.

Au final, la comparaison en question revient à comparer les valeurs de 1 <= 7. Ce qui donne le résultat cité plus haut.

La bonne façon

J’ai précédemment mentionné que la détection du navigateur basé sur le numéro de la version était la pire des façons de déterminer à quel navigateur vous avez affaire.

Dans le meilleur des mondes, il est préférable d’opter pour une stratégie détection de fonctionnalité dans le cas où vous désirez viser certains navigateurs anciens. La principale raison de cela est que jQuery.Browser est déprécié depuis la version 1.3 de jQuery et n’existe plus depuis la version 1.9 (la version courante).

Par exemple, dans le cas qui nous intéresse, la détection d’Internet Explorer 7 aurait pu se faire par la détection du  support de certaines propriétés CSS ou fonction reliée au DOM HTML tel que suggéré par Mozilla. Il y a même certaines stratégies plus avancées qui sont suggérées par ce billet.

Parlant de détection de navigateurs, Microsoft a même une page dédiée à la détection d’Internet Explorer. Vous pourriez vous laisser tenter et suivre leurs conseils afin de vous assurer que vos visiteurs utilisent bien Internet Explorer.

Les liens de la semaine – Édition #35

Développement

.NET

Technologie

Web

Science et autres

Intégration de la révision Git à son projet Visual Studio 2012

Vous vous souvenez de mon billet qui traitait de l’intégration du numéro de révision SVN à son projet Visual Studio? Ce billet documentait une avenue que j’ai préconisée afin de m’assurer que le numéro de révision SVN soit toujours présent au moment du déploiement de mon site web.

La technique utilisée, dans ce billet, consistait à utiliser l’événement de précompilation du projet web et extraire la révision courante pour le rendre disponible dans un fichier texte accessible à la racine du site web.

Évidemment, le principal désavantage de cette solution est qu’elle est spécifique au gestionnaire de code source SVN.

Et Git, lui?

Comme le camarade Olivier l’a mentionné. Qu’est-ce qu’il advient de Git, lui? C’est exactement là où je voulais en venir! Après tout, à part pour le travail, j’utilise uniquement Github pour entreposer mon code.

Un gestionnaire différent, autres mœurs?

Lorsque j’ai entrepris d’élaborer, la solution Git, je savais que je ne pourrais pas emprunter le même chemin que celui emprunté pour SVN. Après tout, je n’ai pas accès à TortoiseSVN pour extraire la version courante.

Ceci étant dit, la façon de procéder doit être la même, car c’est au moment de la compilation que doit se faire l’opération de récupérer le numéro de version. C’est aussi à cette étape que vous pourriez, par exemple, décider d’inclure le numéro de révision à même votre fichier AssemblyInfo.cs.

La recette

Au bout du compte, j’ai besoin d’identifier au minimum trois informations dans mon fichier version.txt.

  • La date de la compilation
  • La branche utilisée pour cette version
  • La révision utilisée.

La façon la plus simple d’y arriver est d’avoir un script Powershell qui va aller extraire cette information du dossier courant. Ce script est composé des trois éléments permettant de retrouver les trois informations mentionnés ci-haut.

Ces trois informations sont séparées par le caractère « -« . Les données extraites sont représentées de la façon suivante : « 2013-06-06 20:44:02 – master – 450fad1« .

En supplément, vous devez avoir la commande suivante dans vos événements de précompilation : powershell.exe $(ProjectDir)\Build\git-version-extract.ps1 -FilePath $(ProjectDir)\version.txt.

Note : vous devez absolument exécuter votre instance de Visual Studio en mode administrateur pour que cette configuration fonctionne.

Un petit pas pour l’avenir

L’exemple que j’ai mis en place est une façon de faire parmi tant d’autres. D’ailleurs, elle pourrait être utilisée à d’autres sauces.

Je donne l’exemple du fichier AssemblyInfo qui pourrait être généré de cette façon pour votre application. Dans mon cas, je préfère avoir accès à un fichier qui est accessible même lorsque mon site est mort. Toutefois, vous pourriez avoir besoin de cette information dans votre historique d’erreurs, par exemple.