Mois : mai 2013

Trucs et astuces avec Google Chrome

En tant que travailleur du web, vous utilisez inévitablement un navigateur web pour accomplir la majorité de vos tâches. Cela va de soi.

Lorsque je pense à l’inévitable utilisation d’un navigateur web dans mon métier, il me vient en tête la variation sur le paradoxe de l’œuf et de la poule suivante :

Qu’est-ce qui est apparu en premier : le navigateur web ou le développeur web?

Le choix du navigateur est même un sujet sensible à semer la zizanie dans un groupe d’artisan du site web. Sommairement, il y a deux clans. Il y a ceux qui utilisent Google Chrome et les autres. Les autres sont ceux qui utilisent des navigateurs de second plan comme Firefox, Opera et Internet Explorer.

chrome-logoVous l’aurez deviné. Je suis un adepte invétéré de Google Chrome. Désolé pour les utilisateurs de Firefox, je vous aime quand même, un peu.

Cette introduction était un prétexte pour vous présenter ma liste de mes fonctionnalités préférées de Google Chrome.

Édition de propriétés CSS à même l’inspecteur – version magique

Lorsque j’ai su qu’il était possible de mettre à jour les valeurs de propriétés de style CSS, dans l’inspecteur HTML de Chrome, à l’aide du défilement de la roulette de ma souris, j’étais abasourdi.

Vraiment, j’étais impressionné!

Pour reproduire cette façon de faire, j’ai produit ce mini vidéo, en prenant exemple, la page d’accueil de ce blogue.

Édition de JavaScript à même l’onglet Sources

L’onglet « Sources » de l’inspecteur permet de consulter la source des scripts JavaScript qui sont exécutés à même votre page web. À même cet onglet, vous y trouverez différentes fonctions vous permettant de faire l’analyse et le débogage de votre code source.

Saviez-vous que c’était aussi un éditeur de JavaScript? Vous pouvez, avec ce même onglet, ajouter et/ou retirer du code à votre guise sans avoir même à recharger la page.

Pour avoir une idée de ce que vous pouvez faire avec cela, allez consulter la source du fichier functions.js du site http://geekroulette.ca/.  Ensuite, allez ajouter un console.log(« FrenchCoding »); après la ligne 63.

Une fois cela complété, allez cliquer sur le bouton « Démarrer » et  constatez que « FrenchCoding » sera écrit dans l’onglet « Console ».

Propriétés de l’inspecteur

Voyez-vous la petite roue dans le coin droit de l’inspecteur? Cliquez dessus. Ceci est les propriétés de l’inspecteur lui-même.

Dans le menu « General » vous pouvez personnaliser certains comportements de l’inspecteur. J’utilise fréquemment le paramètre « Disable cache » qui permet, vous l’aurez compris, de forcer Chrome à toujours ignorer les en-têtes d’expiration sur les fichiers et les télécharge toujours.

Vous pouvez aussi modifier certains comportements du navigateur dans l’onglet « Overrides ». C’est à cet endroit que vous pouvez réécrire le « User Agent » de votre navigateur ou, même, simuler une résolution d’écran en particulier.

Il est inutile de vous parler de l’onglet « Shortcuts ». N’est-ce pas?

Gestionnaire de tâches

Pour Chrome, une page est l’équivalent d’un processus bien distinct. Ce paradigme vous permet d’accéder à un gestionnaire de tâche pour votre navigateur.

À l’aide des touches « Shift-Escape », vous pouvez faire apparaître ce gestionnaire de tâches. Cela va vous permettre de consulter certaines statistiques d’utilisation, en temps réel, du navigateur et de ses différents processus. Vous pouvez même arrêter un processus en particulier si cela vous dit.

Publicité

Les liens de la semaine – Édition #32

Développement

.NET

Web

Technologie

Science et autres

Comment créer un fichier CSV UTF-8 incluant le BOM avec C#

Introduction

Ce billet est dédié à une situation que j’ai eu à personnellement prendre d’assaut dernièrement. Cette situation est très spécifique au domaine d’affaires d’un client que je supporte.

L’idée est que le site accepte des inscriptions par un formulaire. Ces inscriptions sont ensuite enregistrées dans une base de données pour être ensuite exportées dans un fichier CSV. Une fois dans ce fichier, ces inscriptions seront importées dans une liste de contact pour un envoi d’infolettre.

Vous me suivez jusque là? Super.

Votre fichier UTF-8 moyen, en mal de vivre.
Votre fichier UTF-8 moyen, en mal de vivre.

Parfois, ce client aime bien manipuler la liste d’inscription, dans le format CSV, avant de faire l’importation dans son courrielleur. La méthode commune est d’ouvrir le fichier directement avec Microsoft Excel. Ce dernier va reconnaître le fichier comme une feuille de données et vous pourrez la manipuler de façon transparente, comme un fichier Excel.

Or, il s’avère que Microsoft Excel a de la difficulté à détecter l’encodage d’un fichier UTF-8 l’élément nommé le Byte Order Mark (BOM). Cela veut dire que vos fichiers CSV auront toujours l’air du fichier texte de la prise d’écran ci-haut, à moins que vous interveniez.

Traditionnellement, avec les fichiers UTF-8, le BOM est utilisé pour détecter la validité de l’encodage de ces fichiers.  Pour déterminer si un fichier est réellement UTF-8, un éditeur texte tentera de valider la présence de ces octets au tout début du fichier.

Bref, si vous le faites, vous mettez les chances de votre côté.

Comment faire?

AVERTISSEMENT

La solution à appliquer peut varier énormément selon le contexte où vous vous trouvez. Dans mon cas, j’ai eu à utiliser une technique assez bas niveau. Le côté positif de cette technique est qu’elle peut être utilisée dans presque tous les contextes.

Le code que vous allez voir est l’idée générale derrière la  véritable solution que j’ai employée pour générer le fichier CSV de mon client. Vous allez comprendre lorsque vous allez le lire.


using (var fs = new FileStream(@"c:\frenchcoding\frenchencoding.csv", FileMode.OpenOrCreate, FileAccess.ReadWrite))
{
var preamble = new UTF8Encoding(true).GetPreamble();
fs.Write(preamble,0,preamble.Count());
var byteArrayLine1 = System.Text.Encoding.UTF8.GetBytes("courriel, nom, prénom"+Environment.NewLine);
fs.Write(byteArrayLine1, 0, byteArrayLine1.Count());
var byteArrayLine2 = System.Text.Encoding.UTF8.GetBytes("pascal.paradis@gmail.com, Paradis, Pascal");
fs.Write(byteArrayLine2, 0, byteArrayLine2.Count());
}

view raw

encoding.cs

hosted with ❤ by GitHub

La technique utilisée fait en sorte que le BOM est ajouté immédiatement dans les premiers octets du fichier texte généré. Le BOM est la valeur retournée par la méthode GetPreamble() de la classe UTF8Encoding lorsque la valeur true est envoyée au constructeur.

D’ailleurs,  à titre informatif, le nom du paramètre du constructeur est encoderShouldEmitUTF8Identifier. Le nom est assez évocateur. Dans ce cas-ci, vous désirez un fichier UTF-8 alors vous laissez cette valeur à true.

nodepad-utf-8-encodingDe plus, la preuve ultime que cette solution fonctionne se prouve avec notepad++. L’éditeur texte détecte le fichier comme ayant un encodage UTF-8 pur!

Les liens de la semaine – Édition #31

Développement

Web

Technologie

Science et autres

Versionnage sémantique

Il y a un comportement que je considère comme pratiquement universel chez les développeurs. Lorsqu’on se donne la peine d’y porter attention, il devient clair et limpide que nous le faisons à peu près tous. Cela fait comme partie du processus de développement logiciel. Un peu comme si cela était implicite. Un peu comme la règle non écrite que tous se doivent de suivre.

Vous vous doutez bien de ce que je veux introduire. Nous donnons des numéros de version à tout ce que nous produisons.

Parfois ce sera une version Alpha ou Beta. Une autre fois ce sera une version 0.1. Toutefois, le moment tant attendu sera celui de la version 1.0. Celui de la sortie officielle, loin d’être finale.

Il peut être amusant de donner à brûle-pourpoint des numéros de version. Dans la très grande majorité des cas, ce numéro de version sera sans incidence. On s’en branle un peu non? Le code compile. C’est tout ce qui nous préoccupe.

La nécessité d’avoir une logistique de versionnage plus rigoureuse s’impose lorsqu’il vient le temps de maintenir un bout de code qui sera utilisé en dépendance pour d’autres logiciels. La question devient soudainement différente. Comment je vais communiquer l’importance de mes changements et ainsi que le risque associé à la mise à jour à une version en particulier?

La sémantique

Le versionnage sémantique vise à imposer une structure aux numéros de version qui seront donnés à votre logiciel. Chacun des éléments qui composeront un numéro de version a un but particulier ayant pour but de communiquer l’intention de cette version.

Le document initial a douze règles régissant la mise en oeuvre des numéros de versions. Je vous fais part d’une traduction libre, tirée d’un fork GitHub de la part de DudePascalou.

Les mots clés « DOIT », « NE DOIT PAS », « OBLIGATOIRE », « DEVRAIT », « NE DEVRAIT PAS », « RECOMMANDÉ », « PEUT », et « OPTIONNEL » dans ce document doivent être interprétés comme décrit dans la RFC 2119.

  1. Tout logiciel utilisant le Versionnement Sémantique DOIT déclarer une API publique. Cette API peut être déclarée dans le code lui-même ou dans un document. Dans tous les cas, elle doit être précise et claire.
  2. Un numéro de version standard DOIT prendre la forme X.Y.Z où X, Y et Z sont des entiers non négatifs. X est la version majeure, Y est la version mineure, et Z est la version de patch. Chaque élément DOIT augmenter numériquement par incréments d’une unité. Par exemple : 1.9.0 -> 1.10.0 -> 1.11.0.
  3. Quand un numéro de version majeur est incrémenté, la version mineure et la version patch DOIVENT être remises à zéro. Quand un numéro de version mineur est incrémenté, la version patch DOIT être remise à zéro. Par exemple: 1.1.3 -> 2.0.0 et 2.1.7 -> 2.2.0.
  4. Une fois qu’une version d’un composant est publiée, le contenu de cette version NE DOIT PAS être modifié. Toute modification doit être publiée comme une nouvelle version.
  5. La version majeure zéro (0.y.z) sert au développement initial. Tout peut changer à tout moment. L’API publique ne devrait pas être considérée comme stable.
  6. La version 1.0.0 définit l’API publique. La façon dont le numéro de version est incrémenté après la publication est dépendante de cette API publique.
  7. La version de patch Z (x.y.Z | x > 0) DOIT être incrémentée si des corrections d’anomalies rétro-compatibles sont effectuées. Une correction d’anomalie est définie comme un changement interne qui corrige un comportement incorrect.
  8. La version mineure Y (x.Y.z | x > 0) DOIT être incrémentée si une nouvelle fonctionnalité rétro-compatible est introduite dans l’API publique. Elle DOIT être incrémentée si une fonctionnalité de l’API publique est marquée comme obsolète. Elle PEUT être incrémentée si une nouvelle fonctionnalité ou amélioration est introduite dans le code privé. Elle PEUT inclure des changements de niveau de patch. La version de patch DOIT être remise à 0 lorsque la version mineure est incrémentée.
  9. La version majeure X (X.y.z | X > 0) DOIT être incrémentée si des changements rétro-incompatibles sont introduits à l’API publique. Elle PEUT inclure des changements mineurs et de patch. Les numéros de version de patch et mineurs DOIVENT être remis à 0 lorsque la version majeure est incrémentée.
  10. Une version admissible (de l’anglais pre-release) PEUT être notée par l’ajout d’un tiret et une série d’identifiants séparés par des points suivant immédiatement la version de patch. Les identifiants DOIVENT être composés uniquement de caractères alphanumériques ASCII et de tirets [0-9A-Za-z-]. Des versions admissibles sont utilisables et précèdent la version normale associée (version admissible < version normale). Exemples : 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
  11. Une version de construction PEUT être représentée par l’ajout d’un signe « plus » et d’une série d’identifiants séparés par des points suivant immédiatement la version de patch ou admissible. Les identifiants DOIVENT être composés uniquement de caractères alphanumériques ASCII et de tirets [0-9A-Za-z-]. Les versions de construction sont utilisables et suivent la version normale associée (version de construction > version normale). Exemples: 1.0.0+build.1, 1.3.7+build.11.e0f985a.
  12. La priorité DOIT être calculée en séparant les numéros de version, dans l’ordre, en identifiants majeur, mineur, patch, de admissible et de construction. Les numéros de version majeur, mineur, et de patch sont toujours comparés numériquement. Pour les versions admissible et de construction, la priorité DOIT être déterminée en comparant chaque identifiant séparé par un point comme suit : les identifiants composés de chiffres seulement sont comparés numériquement et les identifiants composés de lettres ou de tirets sont comparés dans l’ordre de tri ASCII. Les identifiants numériques précèdent les identifiants non numériques (identifiants numériques < identifiants non-numériques). Exemple : 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-RC.1 < 1.0.0-RC.1+build.1 < 1.0.0 < 1.0.0+0.3.7 < 1.3.7+build < 1.3.7+build.2.b8f12d7 < 1.3.7+build.11.e0f985a.

Dans le vrai monde

Le versionnage sémantique n’est pas la seule façon de donner une identité à une version de votre logiciel. La page dédiée au versionnage logiciel répertorie une multitude de façons d’arriver à cette fin sans utiliser cette façon de faire.

La façon de versionner son logiciel doit être une question débattue au sein de l’équipe de développement. Un bel exemple de ce débat est celui tenu par l’équipe de développement Drupal. La question a été lancée en juin 2012 et il y a eu des échanges jusqu’en février sur ce sujet.

Il est difficile de répertorier les projets utilisant le versionnage sémantique. Toutefois, la façon de nommer les versions n’est pas à prendre à la légère et a beaucoup d’implication pour les contributeurs et utilisateurs.

Après tout, est-ce que de donner un numéro de version qui s’incrémente d’une façon prévisible et logique à travers le temps serait une façon de démontrer qu’un développeur se soucie réellement de ses utilisateurs? Moi, je crois que oui.