Je reviens aux sources et à mon grand dada avec l’intégration HTML au sens large du terme. J’ai choisi d’intituler cet atelier : industrialiser l’artisanat de l’intégration HTML. Rendez-vous le samedi 16 octobre 2010 à 10h50 dans les locaux de Télécom Paris pour en discuter … et maintenant, pour le préparer et en dessiner les contours.

Origine de l’atelier

Juste après l’édition 2009 de Paris-Web, je me demandais sur quoi je pourrais parler en conférence ou en atelier. Cette manifestation a le mérite d’attirer des orateurs de qualité … et ce n’est pas évident de monter sur scène en se disant : que pourrais-je apporter au public, qui ne soit pas de la redite et suscite autant d’intérêt qu’une Stéphanie Troeth, Karl Dubost ou Christian Heilmann.

Et là j’ai lu la lettre au papa Paris-Web d’Elie Sloïm. J’ai de suite pensé à un sujet lié à l’intégration HTML. Cette spécialité connaît une effervescence d’outils depuis 2008 (frameworks CSS, pré-processeurs CSS et performances Web) … pourtant les méthodes de travail restent toujours très liées au développeur, à son tempérament et à ses connaissances d’outils capables d’améliorer la productivité. Quelque chose de tout sauf normalisé, industrialisé.

Comme il s’agit également d’une pratique ayant du mal à accepter les changements – je me souviens encore des réticences liées aux frameworks, alors que dans tout langage de programmation ces outils sont perçus comme du pain béni – je me suis dis qu’il y avait quelque chose à faire.

Les axes initiaux de l’atelier

En préparant l’appel à propositions de Paris-Web, j’avais convenu que cet atelier devrait tenter de répondre aux objectifs suivants :

• dresser un état de l’art de l’intégration HTML
• offrir une large tribune à l’audience, notamment en partageant ses propres retours d’expérience
• déterminer ce dont on dispose et ce dont on manque en terme d’outillage

Par extension, je souhaitais répondre (au moins) à ces questions :

• comment bâtir des CSS indépendantes et réutilisables ?
• quand et comment utiliser un préprocesseur CSS ?
• comment dialoguer avec le graphiste ?
• comment dialoguer avec le développeur ?
• comment détecter les régressions et assurer une qualité de code en CSS ?

J’ai également repris l’historique des précédents Paris-Web pour voir que de précédents ateliers s’étaient déjà penchés sur la question de la chaine d’intégration. D’où mon souhait de ne pas forcément réinventer la roue.

Pour autant, les objectifs tout comme les questions ne sont pas figées dans le marbre. Cet article est également là pour capter vos avis et vos remarques, pour ajuster cela avant le jour de l’atelier.

Discuter, échanger, et créer

Enfin, mon évolution personnelle au long de cette année 2010 et certaines paroles de David Larlet résonnaient dans ma tête.
Un sujet de cette importance ne peut pas être magistral. Pourquoi ? Parce que tous les intégrateurs rencontrent une variété de conditions de travail différentes, et qu’il serait d’autant plus difficile d’obtenir un consensus en prodiguant cet atelier de manière magistrale.

D’où l’idée d’introduire l’atelier par un bref résumé de mes retours d’expérience sur les frameworks (existants, ou créés pour le besoin), les pré-processeurs CSS, leur combinaison ainsi que l’application de la philosophie Object Oriented CSS. Quelque chose comme 10/15 minutes maximum.

Le reste du temps serait réparti de manière équitable sur chacune des questions, et animé sous forme de discussion. Chaque participant répondrait (via des post-it, je les fournirai ) par 1 ou plusieurs réponses, positives et négatives. En gros, ce qu’il faut faire, et ce qu’il ne faut pas faire.

Cette collecte en live des post-it, affichés au tableau, permettrait de dresser une cartographie des bonnes et mauvaises pratiques, des actions à mener et dont il faut se méfier.

A défaut de parler d’une industrialisation vidant l’intégration HTML de son côté artisanal, on aurait une excellente occasion pour tous se poser ensemble les bonnes questions, et repartir avec des réponses et des idées pleins la tête.

Conclusion

Bref, si le sujet de l’intégration HTML vous préoccupe, est au centre de vos intérêts et que vous souhaitez en améliorer sa pratique professionnelle (pour une meilleure reconnaissance de celle-ci ?), je vous invite à la fois à venir à l’atelier technique du samedi (il reste quelques places ; ça ne coûte que 22€) et à réagir en commentaires. Je ferai mon possible pour adapter l’animation de l’atelier à vos problématiques et questionnements.

Cet atelier serait ainsi à l’image de Paris-Web : une grande discussion conviviale, constructive et enrichissante.
L’idée sera ensuite de concrétiser ces échanges soit par un ensemble de billets de blogs soit, si la matière le permet, en livre blanc.

Ne me demandez pas ce que je prévois pour 2011, je n’en ai aucune idée … pour l’instant

Il existe cependant une méthode alternative reposant sur Subversion (SVN). C’est la méthode idéale pour tout développeur WordPress ou gestionnaire de blogs. C’est celle que j’emploie depuis la version 2.6 grâce notamment à la constante WP_CONTENT.

Explications et application concrète.

Avant toute chose, sachez que ce tutorial est optimisé pour les personnes qui versionnent entièrement leur projet. Il n’est pas question ici d’avoir une arborescence libre et de procéder à des checkout un peu partout. C’est possible mais pas du plus grand intérêt.

L’avantage évident ici est de pouvoir déployer son blog n’importe où en un rien de temps.

Structure des fichiers

Installer WordPress en tant que dépendance SVN revient à mélanger 2 techniques :

• Installer WordPress dans son propre répertoire
  
• Installer WordPress proprement depuis SVN

Je suis pénible donc je n’ai pas spécialement envie de modifier un fichier core ou autre chose que wp-config.php. Tout le contraire de ce qu’indique la première méthode.

La seconde explication m’a toutefois posé légèrement problème puisqu’un peu brutale et posant soucis chez OVH.

Celles et ceux qui voient la capture d’écran ci-dessus peuvent constater que tout WordPress a été déplacé dans un sous-répertoire wordpress au même niveau que wp-content.
On ne garde à la racine que le fichier .htaccess et wp-config.php.

Sur le répertoire racine, j’ai appliqué ces propriétés pour WordPress 2.7 :

• svn:ignore :
  

  wp-config.php

• svn:externals :
  

  wordpress http://svn.automattic.com/wordpress/branches/2.7

Je ne versionne volontairement pas le fichier wp-config.php car c’est le seul fichier susceptible de changer d’une instance à une autre. Je le récupère depuis wordpress/wp-config-sample.php et je le personnalise selon mes besoins.
Et puis versionner des mots de passe … qui y tient ?

Configuration

Après cette restructuration, on aura toutefois besoin de configurer 2-3 bricoles. Vraiment rien de méchant promis.

Le .htaccess

Voici ma configuration. Elle peut être aisément déportée dans votre déclaration de Virtual Host pour des raisons de performance. Sur un serveur mutualisé vous n’avez en général pas accès à ce dernier type de configuration.

<IfModule mod_rewrite.c>
Options -Multiviews -Indexes +FollowSymlinks
RewriteEngine On
RewriteBase /
# Moving to dependency
RewriteRule ^(index.php|wp-[a-z0-9-]+\.php|xmlrpc.php)?$ wordpress/$1 [L]
RewriteRule ^(wp-admin|wp-includes)/(.*)$ wordpress/$1/$2 [QSA,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . wordpress/index.php [L]
</IfModule>
# BEGIN WordPress
# END WordPress

Ce fichier est très inspiré de la configuration SVN proposée sur le Codex WordPress. Seulement voilà, cette renvoie tout sur index.php … et omet ainsi tous les accès aux fichiers situés à la racine, avec entre autre :

• wp-cron.php
• wp-link-opml.php
• wp-trackback.php
• xmlrpc.php

Je vous fais grâce des contrôleurs de flux (Atom, RSS & cie) et des appels en directs à index.php effectués par certains plugins.

Donc non on ne peut pas vraiment se passer de ces fichiers. D’où ces 2 règles :

• RewriteRule ^(index.php|wp-[a-z0-9-]+\.php|xmlrpc.php)?$ wordpress/$1 [L]
  

  On capte tous les fichiers PHP (les contrôleurs) originellement situés à la racine de WordPress.

• RewriteRule ^(wp-admin|wp-includes)/(.*)$ wordpress/$1/$2 [QSA,L]

  Et là c’est pour le confort de conserver les adresses initiales … mais aussi pour éviter de modifier un bout de paramétrage dans l’admin. Le jour où vous décidez de rebasculer à l’ancien système, ça se fera sans douleur

Enfin, pourquoi avoir poussé les commentaires WordPress vers le bas ? Tout simplement pour éviter que nos règles personnalisées soient écrasées par WordPress lors d’une mise à jour des permaliens. Nos règles primeront toujours ainsi.

Le fichier wp-config.php

Dans le fichier wp-config.php, nous n’allons rien modifier. Nous allons juste ajouter forcer 2 paramètres. Ils indiqueront à WordPress où se trouve le véritable répertoire wp-content (renommable mais je ne jouerai pas avec).

Le blog

Bon j’ai menti un peu toute à l’heure en indiquant qu’on ne toucherait qu’à wp-config.php. Cependant la modification est on ne peut plus mineure et ne concerne que l’upload de medias.

En effet si on ne touche pas à l’emplacement des fichiers envoyés, WordPress considère qu’ils sont uploadés dans wordpress/wp-content/uploads. C’est fort gênant mais heureusement, en préfixant le chemin par ../ ou en tapant un chemin absolu tout rentrera dans l’ordre.

À noter qu’il s’agit du seul paramétrage hors d’un fichier. Si j’avais pu m’en passer je l’aurais fait.

Dépendance SVN pour la traduction

C’est en tombant sur un autre article traitant de svn:externals pour WordPress que j’ai été interpelé sur la prise en charge des langues via SVN également.
Le système n’est pas parfait puisqu’on ne peut gérer qu’une seule langue par ce biais là. Ça ne conviendra donc pas aux blogs multilingues.

La technique consiste à transformer wp-content/languages en svn:externals.
Ça donnerait ceci pour la version française de WordPress 2.7, au niveau du svn:externals du répertoire wp-content :

languages http://svn.automattic.com/wordpress-i18n/fr_FR/branches/2.7/messages/

Simple et efficace mais ça reste encore de la bricole.

Cas particulier : plugins et i18n

Je vous expose le problème mais malheureusement vous ne pourrez pas y faire grand chose. Par contre ami développeurs, pour rendre votre code de plugin 100% portable, merci de prendre note

Le chargement des traductions s’effectue à l’aide de la fonction load_plugin_textdomain(). Elle prenait seulement 2 paramètres jusqu’à l’arrivée de WordPress 2.6. Ça n’a pas été crié sur les toits mais elle prend désormais 3 … et c’est du 3ème argument qu’il faut utiliser désormais :

1. $domain : l’espace de nom des traduction (inchangé)
2. $abs_rel_path : chemin relatif par rapport à l’emplacement de WordPress (déprécié, on y mettait PLUGINDIR.'/'.dirname(plugin_basename(__FILE__)) en général)
3. $plugin_rel_path :  chemin relatif par rapport à l’emplacement des plugins (c’est qui nous intéresse ; dirname(plugin_basename(__FILE__)) nous suffira désormais)

Vous trouverez un exemple sur le Codex, du côté de l’internationalisation des plugins.
Un exemple de code pérenne :

load_plugin_textdomain('votreplugin', dirname(plugin_basename(__FILE__)), dirname(plugin_basename(__FILE__)));

Et si jamais vous utilisez votre plugin en lien symbolique ça ne fonctionnera pas … mais on s’éloigne du sujet

Et pour WordPress Mu ?

Je ne m’attarderai pas dessus mais les manipulations sont sensiblement les mêmes. Je n’ai pas encore eu l’occasion d’essayer mais j’ose imaginer qu’il n’y a pas tant de différences que ça

Conclusion

Le jour où vous souhaitez migrer vers une autre version majeure de WordPress, c’est simple : il suffit de changer les externals vers le tag adéquat.

Pourquoi ne pas utiliser le trunk directement me demanderez-vous ? Le trunk de WordPress est plutôt instable puisque c’est là que se construit la prochaine version de manière systématique. L’utilisation des branches permet de bénéficier des correctifs sans avoir à modifier le moindre external.
Si vous avez un grand besoin de stabilité, alors utilisez les tags qui sont en principe figés.

On remarquera aussi que malgré son âge, WordPress commence à peine à proposer des solutions d’industrialisation.
Les liens symboliques sont en effet très mal gérés. Tentez d’utiliser un seul répertoire source pour plusieurs blogs avec des liens symboliques et tout s’effondre.

La preuve en est aussi avec le manque de ressources disponibles sur le Web et traitant ce sujet. Ça m’étonnerait d’être le premier à vouloir déployer du WordPress via SVN.
Les choses s’améliorent mais pour le côté code is poetry, on en est encore loin.

High Performance Web Site, sous-titré Essential Knowledge for Frontend Engineers, est ce genre de livre à lire au moins une fois à défaut de le posséder. Il résume en à peu près 120 pages 14 points d’optimisation d’un site Web.

C’est d’autant plus intéressant que l’approche se base sur les mécanismes et non sur de l’optimisation de code. Ainsi dans la plupart des cas, vous n’aurez « que » du paramétrage serveur à faire.

Ce livre fait étrangement penser aux conseils de haute performance prodigués par le Yahoo! Developer Network et repris par l’extension Firefox pour Firebug, j’ai nommé YSlow.
C’est normal : ce livre est écrit par un ingénieur de Yahoo!, probablement un de ceux qui ont participé à la rédaction du guide de performances.

Pourquoi acheter High Performance Web Sites ?

On serait tenté de ne pas acheter le livre puisqu’une bonne partie de ses conseils sont repris sur le guide de haute performance cité plus haut.

Sachez toutefois que cet ouvrage va plus loin dans le détail, prend bien le temps de présenter ses tests de performance pour illustrer et de justifier l’application de leurs méthodes. La plupart des relevés de mesure sont effectués sur une dizaine de sites allant de Google à Amazon.

J’achèterais ce livre si j’étais :

• un administrateur système chargé d’héberger 1 ou plusieurs sites Web
• un technicien/webmaster en charge d’un site à plus ou moins fort trafic
• un développeur Web soucieux des performances de ses productions
• toute personne avare en kilo-octets superflus
• toute personne voulant accélérer les temps de réponse de son ou ses sites Web

Les 14 points d’optimisation

High Performance Web Sites axe son discours sur 14 points :

1. Limiter le nombre de requêtes HTTP
2. Utiliser un Content Delivery Network (CDN)
3. Utiliser une entête Expires
4. Compresser les composants avec Gzip ou Deflate
5. Placer les feuilles de style en début de page
6. Placer les scripts JavaScript en bas de page
7. Éviter les expressions CSS (Internet Explorer)
8. Placer les scripts JavaScript et les feuilles de style dans des fichiers externes
9. Réduire le nombre d’appels à des DNS différents
10. Minifier le JavaScript et les CSS
11. Éviter les redirections
12. Supprimer les doublons de scripts
13. Configurer ETags
14. Permettre la mise en cache des appels Ajax

Il prend cependant le soin de bien expliquer les mécanismes d’HTTP et les intérêts à améliorer les performances frontend.

Le livre termine sur un comparatif des 14 points sur 10 sites, notation YSLow comprise, dont Amazon, Google, CNN, eBay, Wikipédia et Yahoo!.

La mise en pratique

J’étais déjà sensibilité à presque tous les points pour avoir lu ces fameuses 14 règles en utilisant l’extension YSlow et Firebug. Cependant après la lecture du livre j’ai eu davantage de clés et des exemples probants pour me convaincre de les mettre en œuvre.

On peut appliquer la majorité des points et les points pertinents en 1 heure. En effet, tout site ne peut se permettre d’utiliser un CDN pour accélérer les temps de réponse autour du globe.

Personnellement j’ai mis en place une compression Gzip directement au niveau d’Apache au lieu d’utiliser une compression effectuée en PHP (avec Gzip aussi). J’ai couplé cet effort avec la minification JavaScript et la désactivation des ETags.

J’avais déjà au préalable externalisés mes CSS et JavaScript, placé au bon endroit (mais seulement les appels externes au DNS principal en bas de page) et sans doublon.

C’est bête à dire mais le résultat s’est vraiment senti avec des chargements de page incroyablement plus rapides. YSlow est effectivement un compagnon idéal pour la mise en application de ces éléments avec son analyse des performances et des composants.

Conclusion

J’ai dévoré High Performance Web Sites grâce à sa simplicité de rédaction, les nombreux exemples et surtout, les explications enrichissantes. Elles sont mises en application sur Yahoo! et certes, même si on peut se dire qu’on n’a pas de site de leur envergure, leurs conseils sont toujours bons à prendre.

High Performance Web Sites est un concentré de bonnes pratiques, simples à mettre en œuvre. Pourquoi s’en priver ?

Ces optimisations ne sont évidemment pas les seules à mettre en place pour que tout fonctionne bien : il faut aussi produire du code HTML propre, du JavaScript optimisé, du code application qui ne soit pas redondant.

C’est un bon début et des pratiques à généraliser.

L’installation par défaut d’un serveur MySQL est suffisante pour être opérationnel dans la minute qui suit. Elle ne facilite en revanche pas la maintenance en laissant le répertoire contenant vos bases de données et tables hors de portée.

L’intérêt de choisir soi-même l’emplacement de ce répertoire, le datadir, est double :

• regrouper les données en un endroit connu (facilite les sauvegardes)
• utiliser le partitionnement du disque pour ne pas avoir à craindre une perte de données en cas de réinstallation du système (facilite la maintenance)

Nous allons voir comment procéder à ce changement tout en adaptant les sécurités des systèmes tels que SELinux et AppArmor. Ces derniers empêcheront en effet le serveur de démarrer.

Remarque importante : j’ai publié une version améliorée du déplacement des données d’un serveur MySQL. Je la recommande par rapport à cet article : elle implique moins de manipulations et est plus propre.

Quelques généralités avant de commencer

Quitte à changer l’emplacement du datadir, autant le déplacer sur une partition qui ne sera pas effacé lors de la réinstallation de votre système d’exploitation, que ça soit du Linux, MacOS ou Windows.

Personnellement, sous Ubuntu/Debian, je crée un répertoire dans /home qui s’appelle mysql. Mon répertoire /home est bien entendu monté sur une partition différente. Si ce n’est pas le cas chez vous, pensez à déplacer votre /home.

sudo mkdir /home/mysql
sudo chown mysql:mysql /home/mysql

Enfin, dernier détail à connaître : l’emplacement de vos données MySQL :

• sous Linux, généralement : /var/lib/mysql
• sous Windows, avec WAMP : C:Program FilesWampmysqldata

Méthode 1 : modifier la configuration MySQL

C’est probablement la méthode la plus simple mais elle a l’inconvénient d’avoir à modifier un fichier de configuration. Il faut donc modifier la propriété datadir de votre fichier de configuration MySQL :

• sous Linux, généralement : /etc/mysql/my.cnf
• sous Windows, avec WAMP : C:Program FilesWampmysqlconfmy.ini

Dans ce fichier se trouve une section consacrée à la configuration générale du serveur mysql (mysqld pour mysql daemon) :

[mysqld]
user            = mysql
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp

J’ai mis en gras la ligne qui nous intéresse, à savoir le datadir.
Quelle valeur mettre ? Celle de l’emplacement souhaité pour vos données. Dans mon cas ça aurait été /home/mysql :

datadir         = /home/mysql

Vous vous assurerez d’avoir bien stoppé le service MySQL, d’avoir copié/collé vos données de l’ancien emplacement vers le nouveau et enfin de redémarrer MySQL. C’est seulement en cas de réussite que vous pourrez supprimer l’ancien répertoire

sudo -s
/etc/init.d/mysql stop
cp -pr /var/lib/mysql/* /home/mysql
/etc/init.d/mysql start

Méthode 2 : utilisation d’un lien symbolique

La documentation de MySQL explique l’utilisation des liens symboliques pour tout, une base de données précises voire même les tables. Ceci dit nous allons voir l’exemple global : on déplace tout.

Concrètement cette méthode consiste à :

1. stopper le service MySQL
2. déplacer le répertoire de données (au cas où)
3. créer le lien symbolique
4. copier les données dans le nouvel emplacement
5. relancer le service MySQL

Concrètement, ça se traduit comme ceci :

sudo -s
mv /var/lib/mysql /var/lib/mysql-old
ln -s /home/mysql /var/lib/mysql
cp -pr /var/lib/mysql-old/* /home/mysql
/etc/init.d/mysqld start

Là encore, supprimez la copie de vos données (répertoire mysql-old) seulement en cas de succès. Ça facilite les retours en arrière en cas de pépin.

Cas particulier : systèmes employant AppArmor ou SELinux

Il y a cependant un hic possible si vous utilisez une distribution Fedora ou Ubuntu, surtout depuis sa version Hardy Heron (8.04). Celle-ci intègre une sécurité pour éviter à certains services critiques d’être altérés par une manipulation extérieure … comme la notre.

Il faut savoir que les 2 méthodes du haut échoueront si vous rentrez dans ce cas de figure : le service MySQL ne démarre pas.
Pas de panique, il y a juste un fichier à modifier : /etc/apparmor.d/usr.sbin.mysqld. Il y a un passage ressemblant à ceci, dans le cas d’AppArmor et Ubuntu :

/etc/mysql/*.pem r,
/etc/mysql/conf.d/ r,
/etc/mysql/conf.d/* r,
/etc/mysql/my.cnf r,
/usr/sbin/mysqld mr,
/usr/share/mysql/** r,
/var/lib/mysql/ r,
/var/lib/mysql/** rwk,
/var/log/mysql/ r,
/var/log/mysql/* rw,
/var/run/mysqld/mysqld.pid w,
/var/run/mysqld/mysqld.sock w,

Vous voyez le loup venir. Il suffit de remplacer les occurences de /var/lib/mysql par le chemin de votre nouvel emplacement, /home/mysql dans notre cas :

/home/mysql/ r,
/home/mysql/** rwk,

La raison de cette modification est presque simple : AppArmor ne suit pas les liens symboliques. Il considère que /var/lib/mysql est différent de /home/mysql et que ce dernier ne concerne pas le service mysqld.
Notre modification évite ce blocage et permet du même coup au serveur MySQL de démarrer ; les échecs étant dus au fait que le serveur ne trouvait pas de base à charger (dont la sienne, mysql).

Pour terminer, on peut relancer les 2 services, apparmor et mysqld :

sudo /etc/init.d/apparmor restart
sudo /etc/init.d/mysqld restart

Conclusion

Nous avons vu 2 méthodes pour rendre sa gestion des bases de données plus souple et plus sure. En cas de défaillance système – ça arrive même aux meilleurs – il faut pouvoir le réinstaller sans craindre de perdre des données vitales. Et les bases de données le sont.

On peut aussi constater que les nouveaux services de protection peuvent compliquer la vie si on ne les sait pas actifs et si on ne comprend pas leur fonctionnement. J’ai passé plusieurs heures à comprendre pourquoi le serveur MySQL ne se relançait pas alors qu’il me semblait avoir effectué la même manipulation sur les précédentes versions d’Ubuntu.

N’hésitez pas à partager votre méthode ou apporter vos suggestions sur votre gestion des datadir.

J’y songeais mais l’article «De l’ordre, que diable !» m’a incité à m’y atteler plus tôt que prévu.
Il n’y a en effet pas de méthode universelle pour programmer les CSS mais après plusieurs années d’expérience, j’ai affiné ma réflexion que je vous livre aujourd’hui.

Où l’on parlera de présentation en 1 ligne, de CSSDoc mais aussi de folding et d’indentation. En clair, tout plein de bonnes pratiques de développement en CSS qui vous feront gagner du temps, vous éviterons de la sueur et sentent bon le travail de qualité.

Halte là et retour à la ligne !

J’ai utilisé pendant un moment la technique dite du single line CSS ; à savoir 1 ligne par déclaration.
Je n’hésiterai pas une seconde à dire que je déconseille fortement cette écriture pour les raisons suivantes :

• si on souhaite gagner de la place, il y a des compresseurs (je recommande YUI Compressor): pas la peine de réaliser ce travail nous-même ;
• l’ajout de commentaires n’en est que plus compliqué : on a tous besoin de commenter certains passages cruciaux, notamment les hacks et autres fix ;
• c’est tout bonnement illisible dès qu’on s’y replonge quelques semaines plus tard : imaginez pour quelqu’un qui n’a pas écrit le code !

Les arguments avancés pour cette technique ne tiennent pas la route : on recherche avant tout la qualité et la facilité de relecture. Les quelques kilo-octets à perdre se feront par le biais de programmes. Ça ne doit certainement pas entraver le développement.

L’auto-documentation avec la syntaxe CSSDoc

Les habitués de Java connaissent JavaDoc.
Les habitués de PHP connaissent PHPDoc.
Les habitués de JavaScript connaissent JsDoc Toolkit (dérivé de JsDoc).

Il était donc tout naturel que cette syntaxe de commentaires et d’auto-documentation soit utilisable en CSS avec CSSDoc. Il n’y a pas d’inconvénient à l’utiliser, au contraire, que des avantages :

• la syntaxe permet d’harmoniser les commentaires sur les projets impliquant plusieurs développeurs ;
• sa syntaxe facilite la relecture puisqu’elle est connue et employée dans de nombreux langages, autres que les CSS ;
• l’auto-documentation du code c’est faciliter la génération d’une documentation externe en automatisant le processus ;
• documenter en même temps que l’on écrit c’est comprendre ce que l’on fait et gagner du temps en évitant une écriture a posteriori ;

La syntaxe CSSDoc est documentée, aisément reconnaissable et est supportée par les meilleurs éditeurs CSS, dont Aptana IDE :

/**
 * @author Oncle Tom
 * @lastmodified Fev, 26 2008
 * @media print, screen
 * @site http://www.oncle-tom.net/
 */
/**
 * Redéfinition des balises HTML
 *
 * @section html
 * @todo utiliser un reset.css conforme
 */
html,
*{
  margin: 0;
  padding: 0;
}

L’organisation hiérarchique

J’ai pour habitude de travailler avec une seule feuille de style par media. Comme je travaille sur des hiérarchies thématiques, leur découpage en plusieurs fichiers ne consiste qu’à du copier/coller. On peut ainsi facilement passer d’une mono-feuille à du multi-feuilles. Je ne suis pas un fervent utilisateur de ces dernières car un code bien lisible sur une seule page n’est pas problématique.
Je ne l’emploie que pour faciliter la réutilisation des CSS sur plusieurs projets partageant la même base graphique.

Concrètement, je vais d’abord organiser ma feuille pour redéfinir les éléments HTML génériques puis créer autant de sections qu’il n’y en a sur ma page (navigation, contenu, navigation de contenu, contenus annexes etc.).
Plus je m’avancerai dans la profondeur du balisage HTML et plus j’indenterai mon code. Cette indentation fait penser à celle utilisée par le langage Python.

On pourrait résumer cette convention à ceci :

• pas de tabulation, que des espaces pour avoir le même affichage peu importe les éditeurs
• 2 espaces par tabulation
• attributs classés par ordre alphabétique (même logique pour tout le monde)
• une ligne d’espace entre les définitions ; pas de ligne entre les définitions proches/liées

C’est simple et voici un exemple de résultat :

/**
 * Redéfinition du HTML
 */
a{
  text-decoration: underline;
}
  a img{
    border: none;
  }
p{
  line-height: 1.5em;
}
  p img{
    margin: 1.5em
  }
  p img.top{
    margin-top: 0;
  }
/**
 * Contenu
 */
#main-content{
  clear: both;
  width: 100%;
}
  /**
   * Articles
   */
  #articles{
    margin-bottom: 2em;
  }
    #articles h2{
      font-size: 1.5em;
      font-weight: bold;
    }

Les mieux organisés d’entre vous ajouteront un tri par fréquence d’utilisation afin d’optimiser les va-et-vient : on met en haut ce qu’on est susceptible de modifier le plus souvent, en bas ce à quoi on touchera rarement. Je ne vais pas jusque là mais ça reste envisageable, pertinent et surtout adapté aux plus chevronnés de l’optimisation.

Autres conseils et astuces

Utilisation de raccourcis

Les aficionados de l’optimisation et du gain de temps apprécieront cette méthode, s’ils ne l’utilisent pas déjà. J’ai pour habitude de placer des raccourcis dans mes sections pour faciliter l’utilisation d’une recherche via le raccourci clavier Control+F.
Je préfixe chaque raccourci d’un symbole = :

/**
 * Liens d'évitement
 * =evitement
 */

Je trouve cette méthode très pratique pour atteindre des portions de code. On évite ainsi un appel à la touche Alt Gr pour appuyer sur le # d’un ID (pour peu que l’on n’ait que des ID en tant que sections). On évite aussi les collisions de nom ou les recherches infructueuses pour cause de changement de nom de classes ou d’ID.

De la sémantique, que diable !

Je suis particulièrement attaché à cette bonne pratique d’autant plus qu’elle ne tombe pas forcément sous le sens de tout le monde : nommez vos ID et classes en fonction de leur signification, pas de leur représentation. C’est la suite logique de la séparation fond et forme du HTML et des CSS.

Mauvaise sémantique :

.rouge{
  color: red;
}
#sidebar{
  /* ... */
}
#top-links{
  /* ... */
}

Bonne/meilleure sémantique :

.important{
  color: red;
}
#alternate-navigation{
  /* ... */
}
#main-links{
  /* ... */
}

#sidebar pourra être renommé différemment selon son contenu, selon que l’encart contienne des éléments de navigation supplémentaires, des informations utilisateur (#user-content) ou encore des widgets (#widgets).
En conservant votre HTML intact et en jouant sur les CSS, la #sidebar peut en effet se retrouver tout en bas, à l’horizontale. Aurez-vous toujours envie de l’appeler pareil ? Pas forcément. Un bon nommage est un nommage qui se conserve peu importe l’aspect de la présentation.

Du choix de la langue

Cette bonne pratique s’applique aussi bien aux CSS qu’à d’autres langages. Il faut partir du principe qu’il ne faut pas mélanger les langues dans le code, tant dans les commentaires que dans le nommage des classes et ID. Choisissez-une langue et restez avec.
Certaines contraintes peuvent faciliter le choix de la langue : le travail avec une équipe internationale ou la redistribution du code. Dans ce cas l’anglais sera à 99% votre langue de prédilection.

Il n’y a pas de choix idéal : certains préféreront le tout français, d’autres le tout anglais. L’essentiel est que ce choix soit motivé par des arguments objectifs, pas une préférence personnelle.

Recours au folding

J’en parle succintement mais le folding consiste à utiliser votre éditeur CSS pour masquer une partie de code. Eclipse propose par exemple de masquer toutes les définitions et tous les commentaires : leur contenu n’est révélé qu’en le dépliant.

Je ne suis pas un fervent utilisateur de cette pratique bien que je respecte son utilisation. Je trouve qu’en utilisation les précédentes astuces (hiérarchie + recherche) on s’y retrouve très bien.

Conclusion

Ma méthodologie n’est pas parfaite, peut être perfectible et ne conviendra pas à tout le monde, par goûts ou par habitudes. Ces dernières sont cependant à combattre pour améliorer son travail. Quoi de mieux qu’un code propre, bien documenté et où l’on trouvera facilement ce que l’on cherche ?

C’est ce qui importe. Il y a autant de façons de coder qu’il n’y a de développeurs. Le tout est d’être ouvert aux améliorations possibles, aux méthodes existantes et à l’intérêt de leurs utilisations. Je trouverai peut-être cet article obsolète dans 1 an mais il aura été un point de passage.

J’espère qu’il le sera au moins en partie pour vous, développeur en herbe ou féru des pseudo-classes

Je rédige sur ce blog depuis bientôt 3 ans, depuis plus de 5 ans sur Emu Nova et depuis quasiment 10 ans si on remonte à mon ancien site perso et mon site consacré à Star Wars. Ah l’époque des .fr.st .
Ce bagage m’a permis d’affiner mon écriture sur le Web mais je cherchais à l’améliorer. C’est précisément à ce moment qu’Olivier Ertzscheid offre la dernière préface issue de sa plume et qu’Élie Sloïm recommande un obscur livre : l’écrit Web.

J’apprécie ces hommes, entre autre, pour leur bonne parole donc il n’en fallait pas davantage pour me procurer cet ouvrage.

Pourquoi le lire ?

L’écrit Web se destine à toute personne désireuse de perfectionner son écriture. Et plus particulièrement l’écriture sur le Web.
Combien d’entre vous ou parmi vos connaissances n’ont jamais dis que lire sur un écran c’est fatiguant, les livre c’est mieux ? Une bonne majorité. Et c’est bien parce qu’on ne lit pas de la même manière un livre qu’un écran d’ordinateur qu’on doit impérativement adapter son écriture à un lectorat volatile, contraint par la technologie et difficile à capter.

L’écrit Web dispense ses bonnes pratiques pour mieux écrire sur le Web en suivant 6 grands axes :

1. organiser l’information
2. structurer son texte
3. adapter son style
4. soigner les microcontenus
5. penser indexation et référencement
6. bloguer

J’ai volontairement grassé les 4 axes les plus intéressants. Ils m’ont permis de conceptualiser beaucoup de pratiques que j’appliquais inconsciemment … et d’en découvrir d’autres.
L’idée générale n’est pas d’apprendre à écrire mais de réapprendre. Les raisons sont simples :

• on lit moins vite sur un écran d’ordinateur ;
• on lit en profondeur et non à plat, grâce aux liens hypertextes (qui ralentissent aussi la lecture).

Organiser et structurer

En partant de ces principes là, il faut donc songer à réorganiser ses textes voire ses sites Web d’une part pour faciliter la vie de ses lecteurs (occasionnels ou pas) mais aussi pour capter plus facilement leur attention. Que faites-vous devant un gros pavé de texte ou un site mal organisé ? Vous zappez. Alors pensez qu’on fait de même avec ce que vous écrivez .

En fin de compte tout contenu, que ce soit une page ou du texte, s’organise en suivant le principe de la pyramide inversée à l’image du triangle d’or d’une page Web si cher aux référenceurs. On commence par l’essentiel pour terminer sur du détail. Ça vaut également pour l’ordre des listes à afficher (chronologiques, géographiques, thématiques etc.).

Contrairement au papier où la lecture se fait à plat, on peut et on doit se servir de la navigation hypertexte pour désengorger les pavés de textes susceptibles de décourager la lecture. C’est ce qu’entend l’auteur par navigation en profondeur.
Plutôt que d’accueillir un visiteur avec beaucoup de texte, mieux vaut donc plusieurs boites aux titres informatifs présentant le contenu en une poignée de lignes.

Autre conseil judicieux, respecter les 5W (ou QQOQP en français) :

1. Qui ? (Who)
2. Quand ? (When)
3. Où ? (Where)
4. Quoi ? (What)
5. Pourquoi ? (Why)

En y songeant lors de la rédaction et en respectant l’ordre, on se retrouve à construire des phrases informatives, bien structurées et plaisantes à lire. Cumulez avec la pyramide inversée et c’est le gros lot : votre lecteur sait tout et tout de suite.

Comment mieux écrire pour le Web

Maintenant que l’on connaît l’ordre de rédaction, écrivons mieux. Écrivons court en suivant les principes 1 idée par phrase et sujet, verbe, complément. La lecture n’en est que fluidifiée. Si en plus il n’y a pas de fautes d’orthographe et que le style reste naturel, alors on touche presque au but.

Une des particularités du Web c’est la republication du contenu. On peut écrire un article pour un site mais le retrouver affiché sur d’autres sites, sur son téléphone portable, un agrégateur voire sur le même site mais sans son contenu (dans une liste par exemple).
Cette particularité est une bonne raison pour donner des titres explicites. Ils pourront ainsi être compris déconnecté de leur contexte. L’écrit Web propose des exemples clairs et compréhensibles vous aideront à mieux en comprendre les subtilités.

La construction des liens hypertexte était indispensable et mérite vraiment d’être lue par toute personne peu familière du référencement. Au-delà de cette pratique, ce sont tout simplement la compréhension et l’accessibilité qui sont en jeu. Pas de liens sur des cliquez ici, ici ou là. Je rajouterai même qu’il ne faut pas de liens ayant le même libellé pointant vers des URL différentes.
Tout comme le libellé du lien décrit le contenu vers lequel il pointe, il vaut mieux englober plusieurs mots (plus facile à cliquer) et qu’ils soient soulignés surtout ! Combien de chartes graphiques je reçois sans aucun lien soulignés ; j’outrepasse systématiquement cette mauvaise pratique du graphiste, dans le contenu en tous cas.

Conclusion

J’ai énormément apprécié et appris de ce livre, surtout les parties structurelles et organisationnelles. La pyramide inversée et les bonnes pratiques de rédaction sont des gros « plus » que j’ai rarement retrouvé ailleurs … ou tout du moins, pas concentré en si peu de pages.
Il se lit très bien et rapidement. J’ai prévu de l’offrir à quelques collaborateurs rédacteurs qui seront susceptibles d’en tirer des leçons et ainsi améliorer leur qualité rédactionnelle. Un bon investissement.

J’ai en revanche moins appris (voire rien du tout) sur les 2 derniers chapitres concernant le référencement et les blogs. Étant donné la quantité d’informations à traiter sur ces sujets, le contenu du livre était forcément un peu léger mais pas dénué d’intérêt pour les néophytes.
Ces parties étaient néanmoins plus techniques et à mon avis plus difficiles à comprendre pour des personnes survolant l’informatique.

Si vous ne saviez pas quoi faire de vos étrennes, que vous rédiger pour le Web et que le marketing vous intéresse, il y aura sûrement de bonnes idées à prendre

Firebug fait partie de mes extensions préférées depuis un bon moment. Je l’estime aujourd’hui même plus importante que l’extension Web Developer, c’est dire.

J’ai pourtant constaté que la plupart de ses utilisateurs la sous-exploitait en se limitant à la console pour consulter les erreurs et éventuellement à l’inspecteur HTML pour remonter rapidement dans l’arborescence des balises en 1 clic. C’est bien mais pas assez.
Firebug est tout simplement énorme ! Suffisamment énorme pour gagner un temps incroyable dans le développement d’applications JavaScript et pour mieux comprendre les incohérences des CSS dans une page, entre autre.

Je vous offre aujourd’hui mon cadeau de Noël pour gagner en productivité et maîtriser cet outil ô combien indispensable.

Le plus amusant dans l’histoire c’est que le site officiel de Firebug dévoile (succinctement certes) tous les petits plus qui simplifient la vie. Je vais m’atteler à les éplucher en fonction des domaines d’utilisation :

1. pour le HTML et les CSS
2. pour le JavaScript
3. pour gagner en performances

Firebug pour le HTML

L’inspection HTML

J’apprécie l’inspection HTML car elle me permet de retrouver simplement le code lié au visuel. Après avoir activé l’inspecteur, je survole l’élément sur lequel je veux travailler, je clique dessus et le volet Firebug se fige dessus en m’indiquant toutes ses propriétés CSS, le modèle de boîte et ses propriétés DOM. On en reparle tout de suite après.
L’inverse est également possible. C’est à dire qu’en survolant le code, la correspondance visuelle dans la page est établie. C’est rudement pratique pour repérer des éléments qui sortent du flux. Ça l’est d’autant plus que les différentes marges (internes, externes, bordures) sont elles aussi mises en surbrillance.

Le gros atout de cet inspecteur c’est également l’édition à la volée de toutes les balises ! Idéal pour tester diverses classes d’un objet ayant un impact visuel fort sur son affichage. Cet outil présente un gain de temps énorme par rapport à la modification du code dans son éditeur et un petit coup de touche F5 dans la foulée.

Il faut également retenir que toute balise est sélectionnable en cliquant sur son nom (div, h3 etc.). Cela a a pour effet de mettre à jour le panneau latéral de Firebug. Panneau latéral qui est également fort utile.

L’inspection CSS, Layout et DOM

Le panneau latéral de l’inspecteur HTML se compose de 3 onglets, tous très utiles.

Inspecteur CSS

Les propriétés CSS affichées concernent uniquement l’objet actif et c’est ce qui en fait sa force. Ce panneau indique en effet la cascade CSS en cours ce qui permet de comprendre rapidement pourquoi sa feuille de style n’est pas appliquée comme il faudrait. Elle a la bonne idée de mentionner quelle feuille de style est utilisée et quelle ligne. De quoi corriger ça dans son éditeur favori rapidement.

Ou pas. En effet l’inspecteur CSS permet, tout comme l’inspecteur HTML, de modifier les propriétés à la volée et sans fioriture. Si je précise sans fioriture c’est parce que l’éditeur à la volée de Web Developer rend parfois l’affichage de la page bancale en décalant des éléments. Là vous pouvez totalement compter sur l’éditeur intégré et ce n’est pas un luxe !
Désactiver, supprimer, modifier ou ajouter des propriétés sont quelques-unes des actions que vous pourrez effectuer à même la page.

Là encore c’est une des parties où les gains de temps sont énormes. On peut en effet modifier ses CSS et les tester tout en observant l’impact immédiat de ses modifications.

Inspecteur du modèle de boîte (Layout)

Le modèle de boîte CSS peut vite devenir pénible à gérer et plus particulièrement quand on visualise mal le cumul des différentes marges.
Dans tous les cas c’est appréciable de pouvoir constater les marges en présence et encore, de pouvoir modifier leurs dimensions à la volée. Firebug a la bonne idée de colorer les marges intérieures (padding), extérieures (margin) et les bordures (border) d’une couleur différente.

Il a également la bonne idée d’afficher une double règle millimétrée au survol du panneau layout. Très pratique dans le cas de design en grilles ou nécessitant un certain rythme de visualisation.

Inspecteur DOM

Ah l’inspecteur DOM ! S’il n’existait pas il faudrait l’inventer. Firefox proposait déjà un tel outil à la différence près qu’il était moins pratique d’utilisation.
L’inspecteur DOM m’est moyennement utile dans le cas d’une simple inspection du code HTML bien que ce soit toujours pratique de visualiser la présence ou pas d’objets JavaScript dans tel ou tel élément. C’est fortement appréciable pour la librairie Prototype étant donné les dégâts causés par son extension du DOM à gogo.

Firebug pour le JavaScript

L’inspecteur JavaScript

C’est l’autre outil indispensable de Firebug. Avec lui, c’en est fini des alert(mavariable);. L’inspecteur DOM prend avec lui toute son utilité.

J’illustre sur l’image ci-dessus l’utilisation des points d’arrêt (breakpoints). Il suffit d’un clic à gauche d’un numéro de ligne pour en placer/retirer un. Concrètement quand l’exécution du JavaScript arrivera au premier point d’arrêt, elle va se stopper.
Quel intérêt ? Observer. En agissant ainsi, vous avez la main sur toutes les variables connues au sein de votre code/fonction. Très utile pour connaître les paramètres passées à la fonction et détecter les erreurs. C’est pour cette raison que les alert() deviennent inutiles : tout est à portée de main. Vous ne pesterez plus contre un undefined mal placé

En parallèle de ça, l’inspecteur DOM est à utiliser pour visualiser d’un coup d’œil les différentes variables actives ainsi que leur arborescence. Comme tout est cliquable, l’inspecteur vous transporte sur n’importe quel objet pour en étudier le contenu.

La console Firebug alias console.*

La console Firebug est l’autre tueuse d’alert() et s’utilise de deux manières.

La plus accessible est d’interagir avec. Vous saisissez votre code, la console l’exécute et retourne le ou les résultats. Encore une fois les objets sont cliquables et navigable au travers de l’inspecteur DOM.
La console est utile pour utiliser des fonctions sorties du contexte de l’initialisation : il devient tout à fait possible de piloter des éléments après le chargement de la page. Ça évite encore une fois des F5 inutiles et consommateurs de temps.

L’autre manière d’utiliser la console c’est de ne pas l’utiliser. Ou pas de manière active tout du moins puisqu’elle est également un objet JavaScript (console) utilisable dans votre code auquel sont rattachées plusieurs fonctions au nom explicite :

• console.log() : affiche une information standard
• console.info() : affiche une information de type « information »
• console.warn() : affiche une information de type « avertissement »
• console.error() : affiche une information de type « erreur »
• console.debug() : débogue le contenu d’un objet directement dans la console

Autrement dit, si l’inspecteur ne suffisait pas, au lieu de lancer un alert(mavariable) (potentiellement dangereux dans une grande boucle qui n’a jamais cliqué 50 fois sur « OK » à cause de ça ?), il vaudra mieux utiliser console.log(mavariable). Il y a de quoi faire, surtout avec la possibilité de créer des groupes de messages et l’utilisation de la syntaxe printf.

Et top du top, en cas d’erreur JavaScript, la console affiche un petit cercle rouge qui rappelle fortement le point d’arrêt. Normal puisque c’en est un. Un clic et on évite de rechercher la ligne problématique dans le code. Encore une fois, du temps de gagné.

Firebug pour les performances

Après avoir bien développé, Firebug propose de mieux développer. L’extension magique propose quelques outils sympathiques pour rapidement déceler les problèmes, notamment de scripts trop gourmands ou à optimiser.

Le traceur réseau

Avec le traceur réseau c’est simple, tout ce qui est chargé sur la page est chronométré. Si un élément est systématiquement long à charger en tête de liste, pourquoi ne pas essayer de le déplacer dans le bas de la pile ? Je pense notamment aux appels vers des fichiers JavaScripts externes. Les appeler en bas de page permet d’éviter des gels de page. C’est ce que YSlow nous recommandera

Outre une petite prévisualisation des contenus, le traceur affiche aussi les statuts des contenus s’ils sont différent du statut 200 (found). Et de surligner ça en rouge en cas de fichier introuvable.

J’aime beaucoup le traceur pour le suivi des requêtes XHR (appels AJAX). Un clic sur un appel affiche à la fois les entêtes, les données transmises au serveur et sa réponse. Fini les requêtes AJAX qui ne produisent rien sans qu’on puisse savoir pourquoi. Le clic droit sera également un fidèle allié, notamment pour ouvrir l’appel AJAX dans un nouvel onglet. C’est plus lisible pour déboguer quand même

Le profileur JavaScript

Le profileur (profiler) JavaScript s’utilise un peu à la manière de la console : de manière active ou au travers de l’objet console.

Le profileur enregistre tout ce qui se passe entre le moment où il est enclenché et le moment où il est stoppé. Il va ainsi dénombrer toutes les appels (calls), leur durée d’exécution et leur fichier d’origine, entre autre. L’idée est bien entendu de voir ce qui consomme le plus d’appels et de temps pour savoir si ce comportement est normal ou pas. À ce stade là, difficile de pousser la granularité du profileur plus loins.

Sauf en utilisant le profileur directement dans le code comme on a déjà pu le faire pour les logs. console.profile() et console.profileEnd() seront vos amis. C’est vraiment l’idéal pour profiler l’exécution d’une fonction, voire même les portions de code exécutée en son sein.

L’extension YSlow

L’extension YSlow est une extension pour Firefox mais elle nécessite toutefois la présence de Firebug. Elle s’articule autour de trois critères.

Il y’ a d’une part la surveillance des performances. YSlow se base sur la liste des bonnes pratiques établies par Yahoo! (14 à l’heure actuelle). YSlow passe ces critères en revue et accorde une note en conséquence. Si certaines sont difficiles à tenir, c’est un bon moyen de s’intéresser à de nouvelles pratiques d’optimisation et de performances.

Le second critère est affiché dans le panneau stats. Il s’agit de la capture d’écran ci-dessus. Certes il s’agit d’un simple tableau mais dont les chiffres sont intéressants à étudier. YSlow analyse la page pour un premier et un second chargement. La différence entre les deux ? C’est que le cache est passé par là et normalement, je dis bien normalement, le second chargement se doit d’être beaucoup plus rapide.
Si ce n’est pas le cas, il y a de l’optimisation à faire et cela peut aussi signifier du côté serveur Web. Pas forcément du développement donc.

Enfin on termine sur une partie complémentaire aux stats : les composants (components). Elle distille des informations plus verbeuses que le traceur réseau de Firebug en se focalisant sur les E-Tag, la présence ou pas de compression, la date de validité du cache ainsi que la taille des objets.

Conclusion

J’espère avoir éclairé quelques lanternes sur l’utilisation de Firebug. Cette extension est suffisamment puissante pour gagner en confort de développement ; il serait dommage de s’en priver. On gagne du temps, du confort et surtout, de la qualité de développement.
À noter qu’il existe aussi Firebug Lite. Il s’agit d’un script JavaScript compatible avec les principaux navigateurs du marché mais comme le Lite l’indique, les fonctionnalités sont plutôt limitées. Seule la console JavaScript persiste.

JQuery est une formidable librairie JavaScript car elle offre une grande souplesse et une utilisation simple. Il est cependant important de bien comprendre son fonctionnement pour éviter les débordements liés à une joie mal maîtrisée.
S’il est très facile d’utiliser les sélecteurs CSS de jQuery, je constate de ci de là que leur utilisation n’est pas toujours optimale … quand elle l’est déjà un tant soit peu.

Alors on se retrousse les manches et c’est parti pour un petit cas pratique sur les sélecteurs CSS jQuery, plus une petite récap’ pour grapiller du temps et des lignes de code

Le cas pratique

J’ai pensé à une chose : plutôt que vous papillonniez en lisant cet article, j’ai fait en sorte que vous puissiez y prendre part. JQuery est très divertissant – certainement plus que votre voisine d’en face – alors tant qu’à me lire, autant optimiser la compréhension
Pour cela il vous faut 2 choses :

1. un bac à sable HTML / jQuery concocté par mes soins
2. l’inévitable extension Firebug pour bénéficier d’une console digne de ce nom (entre autre)

Principe de la sélection CSS de jQuery

Que celui qui s’est lancé corps et âme dans jQuery sans lire la documentation lâche un com’ ! Elle est suffisamment complète pour éviter la plupart des questions du genre comment je fais pour ….

Maintenant que vous avez le document en main, nous allons jouer avec jQuery pour récupérer ce que nous voulons. Les personnes n’ayant pas Firebug comprendront la logique du code sans même avoir à le regarder :

// Récupération du premier paragraphe
$('body p:first-child');
// Récupération du nœud des continents
$('ul.continents');
// Récupération de la liste des capitales
$('.capitale');
// Récupération du dernier élément du body
$('body :last');
// Compter le nombre de pays
$('.pays > li').length;

Magique non ?

Comprendre la sélection CSS de jQuery

Les résultats sont propres mais n’est pas parce que ça marche que c’est bien. La preuve, tous les exemples ci-dessus ne sont pas du tout optimisés.
Alors comment savoir si un sélecteur est optimisé ou pas ? La réponse n’est pas systématique car elle dépend exclusivement de votre rigueur et du DOM à interroger. Plus il sera touffu et plus votre sens aigü de la performance sera sollicité.

Reprenons les exemples ci-dessus pour le transposer en JavaScript old-school. C’est le meilleur moyen de sentir le piège … ou pas.

// Récupération du premier paragraphe
$('body p:first-child');
// équivaut à
document.getElementsByTagName('body')[0].getElementsByTagName('p')[0];

Il y a 2 erreurs dans cette sélection :

1. sélectionner body. getElementsByTagName() oblige à parcourir tous les nœuds du document (1000 s’il y en a 1000) alors qu’on n’en veut qu’un … et qu’il ne peut y en avoir d’un ;
2. on sélectionne ensuite tous les p du body. Autant le faire dès la première fois car là encore c’est tous les nœuds contenus dans body qui sont parcourus … y compris l’énorme liste à puces !

// Récupération du nœud des continents
$('ul.continents');
// équivaut à
var continents = [];
var el = document.getElementsByTagName('ul');
for (i in el)
{
  if (el[i].className.match(/(^| )continents( |$)/);
  {
     continents.push(el[i]);
  }
}

La sélection est ici trop générique. On voit bien que l’on est obligé de charger tous les éléments ul du DOM pour les filtrer.

// Récupération de la liste des capitales
$('.capitale');
// équivaut à
var capitales = [];
var el = document.getElementsByTagName('*');
for (i in el)
{
  if (el[i].className.match(/(^| )capitale( |$)/);
  {
     capitales.push(el[i]);
  }
}

C’est probablement la dernière chose à faire. Cassez les genoux de toute personne écrivant un tel sélecteur : il mérite d’animer le BigDill rien de plus !
Dans ce cas de figure, c’est TOUT le DOM qui est chargé (75 éléments) pour ensuite boucler sur un filtre. Cette boucle n’est pas optimisée mais ce n’est pas ce que l’on souhaite travailler aujourd’hui

// Récupération du dernier élément du body
$('body :last');
// équivaut à
var el = document.getElementsByTagName('body')[0].lastChild;

Comme dans le premier cas, le document.getElementsByTagName() charge tout le DOM pour le filtrer, ne récupérer que le premier élément et, seule opération non coûteuse, utiliser son dernier enfant.
Ce n’est pas la pire des exemples mais là encore on peut optimiser les choses.

// Compter le nombre de pays
$('.pays > li').length;
// équivaut à
var pays = 0;
var el = document.getElementsByTagName('*');
for (i in el)
{
  if (el[i].className.match(/(^| )pays( |$)/);
    {
      var continent = el[i];
      for (j in continent.childNodes)
      {
        pays += continent.childNodes[j].nodeName == 'li' ? 1 : 0;
      }
    }
  }
}

Un sélecteur par classe ne devrait être qu’un cas extrême, quand on ne peut se fier à une balise donnée. Car de manière générale, le getElementsByTagName('*') est à bannir. Charger tout le DOM est une folie furieuse.
La bonne idée ici est l’utilisation du symbole >. Cela se traduit par .childNodes et nous verrons plus bas pourquoi c’est mieux.

Et maintenant, optimisons

S’il fallait résumer l’optimisation en 3 points, voici ce que je donnerai :

1. jamais de sélecteur vague
2. toujours un ID (#<ID>) en tête de sélecteur
3. utiliser au maximum les objets natifs (firstChild, childNodes etc.) : ils évitent d’interroger tout le DOM

L’ennemi des sélecteurs CSS ce sont les boucles. Plus elles ont à brasser d’éléments, plus elles sont longues. getElementsByTagName() cache une boucle : JavaScript scanne tout le DOM pour trouver un nœud ayant un tagName correspondant.
S’il faut l’utiliser, c’est en aval d’un sélecteur ayant déjà trié une bonne partie du document.

Votre meilleur ami est getElementById(). Comme son nom l’indique il ne retourne qu’un seul élément et surtout, il est incroyablement rapide. Utilisez-le dans un maximum de cas mais attention tout de même : trop d’ID nuit à la structure du document le rendant ainsi trop rigide.
Il en est de même du parcours des objets natifs des nœuds du DOM. Cela signifie que dès que vous changer la tête de votre HTML, le JavaScript peut en pâtir.

Des fois il faudra faire quelques concessions de performances pour éviter de réécrire votre code au moindre changement … ou parce que la génération est dynamique et difficilement maîtrisable.

Grâce à ces informations, nous pouvons reprendre nos exemples mais de manière optimisée :

// Récupération du premier paragraphe
$('body p:first-child');
// version optimisée
$('#sandbox > p:first');
// Récupération du nœud des continents
$('ul.continents');
// version optimisée
$('#geoliste');
// Récupération de la liste des capitales
$('.capitale');
// version optimisée (mais fortement liée à la structure du document)
$('#geoliste > li > ul ul > li.capitale');
// Récupération du dernier élément du body
$('body :last');
// version optimisée
$('#sandbox :last');
// Compter le nombre de pays
$('.pays > li').length;
// version optimisée (mais liée à la structure du document)
$('#geoliste > li > ul > li').length;

Évitons les doublons : chaînons !

Les CSS c’est un peu fatiguant alors terminons sur une autre utilisation de jQuery parfois sous-employée à cause d’un manque de compréhension : les chaînes. jQuery renvoie des objets et permet de réutiliser/filtrer les résultats avec un seul sélecteur.

Voici un extrait de code largement optimisable :

$('#intro').addClass('jevaisdisparaitre');
$('#intro').append(' <strong>Je vais disparaître</strong>.');
$('#intro code').html('Goodbye World');
$('#intro').css('cursor', 'pointer');
$('#intro').one('click', function(){ alert("Bye bye"); $(this).remove(); });

Tout est correct sauf qu’on répète plusieurs fois le même sélecteur au lieu d’utiliser la chaîne disponible. jQuery optimise la sélection d’un élément déjà sélectionné au préalable mais n’empêche, au lieu d’interroger 5 fois #intro, nous n’allons plus le faire qu’une seule fois :

$('#intro')
  .addClass('jevaisdisparaitre')
  .append(' <strong>Je vais disparaître</strong>.')
  .one('click', function(){
    alert("Bye bye");
    $(this).remove();
  })
  .children('code')
  .html('Goodbye World');

Tout se suit jusqu’à la fonction children() qui modifie le sélecteur de départ et applique la suite de la chaîne à cette nouvelle sélection.
Une autre optimisation consiste à déplacer la déclaration CSS cursor dans la classe .jevaisdisparaitre de l’hypothétique feuille de style. Essayez de dissocier au mieux fond et forme : ça évite BEAUCOUP de modifications de code pour des ajustements esthétiques.

Conclusion

Optimiser ses sélecteurs n’est finalement pas si difficile que ça quand on comprend comment fonctionnent les rouages internes. Il est évident que les gains peuvent être minimes sur de petites pages. Il s’agit cependant d’une gymnastique à maîtriser : ce n’est pas en arrivant sur de gros volumes qu’il faudra apprendre à sélectionner proprement.

Et comme les petites rivières font les grands fleuves, ces petites économies pourraient vous sauver la vie sur des applications full-AJAX ou qui sait, quand vous travaillerez chez Netvibes

La majorité des systèmes de bases de données permettent de trier une sélection de données en fonction de nos besoins, souvent de manière simple. La majorité des besoins courants impliquent des tris ascendants ou descendants (comprendre « par ordre alphabétique croissant ou descendant ») sur une plusieurs colonnes (des dates, des titres ou des codes particuliers) mais de temps à autre, il arrive que les besoins soient plus complexes puisque l’on voudra soit :

• un ordre aléatoire
• un ordre bien précis, ni ascendant ni descendant

Le mécanisme de tri (ORDER BY)

Pour bien comprendre comment fonctionne en détail la commande ORDER BY, je vous invite à lire la documentation concernant les optimisations relatives à ORDER BY. Ce que l’on doit en retenir :

1. le tri est effectué sur les données filtrées par un éventuel WHERE ;
2. il y a 2 algorithmes de tri : l’un utilisant deux passes, l’autre n’utilisant qu’une passe mais davantage de mémoire ;
3. l’algorithme en une passe n’est pas valable pour des tris sur des données de type TEXT ou BLOB ;
4. un tri sur un index est largement plus rapide et plus performant que sur des valeurs non-indexées

Lorsqu’on veut trier des données, il vaut donc mieux écrémer au mieux la plage de données grâce à de judicieux filtres WHERE et de préférence, sur des colonnes indexées.

Mais revenons à nos moutons.

Tri aléatoire (ORDER BY RAND())

Deux solutions s’offrent au développeur pour effectuer un tri aléatoire : recueillir les données voulues et les trier via langage de programmation (sort(), ksort() etc.) ou alors trier directement à la source via la base de données.
Si les bases de données portent leur nom, c’est bien parce qu’elles sont performantes dans leur travail donc autant leur laisser celui-là, celui du tri aléatoire, qui sera bien plus rapide et performant, surtout sur des volumes importants de données.

Cette solution est relativement connue, ORDER BY RAND() mélange les données recueillies de manière totalement aléatoire, sans tenir compte des index ni de quoi que ce soit d’autre. Pensez à utiliser une clause LIMIT si vous ne voulez récupérer qu’un nombre défini de lignes.

SELECT * FROM `ma_table` ORDER BY RAND() LIMIT 1 ;

Cette instruction prendra une ligne et une seule, au hasard. Rapide, concis et efficace.

Tri personnalisé (ORDER BY FIELD())

Pire que le tri aléatoire, il y a celui du tri personnalisé, celui qui n’est ni ascendant, ni descendant, ni aléatoire : on veut un ordre précis. Imaginons que nous nous trouvions avec la table suivante :

Comment faire pour récupérer la liste des jours de semaine dans l’ordre de notre choix ? Tout simplement en utilisant la fonction FIELD() (depuis MySQL 4) :

SELECT jour_nom
FROM `dates_semaine`
ORDER BY FIELD( jour_id, 'lun', 'mar', 'mer', 'jeu', 'ven', 'sam', 'dim' ) ;

J’aurais tendance à dire que la requête parle d’elle-même : on spécifie un tri sur le champ jour_id dans l’ordre passé dans les paramètres suivants.
Ce qui est intéressant dans notre cas c’est qu’on peut donc gérer des semaines débutant le jeudi, le samedi, le dimanche ou le lundi (histoire de coller avec tous les calendriers existants). Seuls les paramètres à donner à la requête changeraient.
C’est également intéressant pour trier le résultat d’une requête en fonction de l’ordre des lignes d’un fichier qui aurait été uploadé sur un serveur.

Conclusion

La clause ORDER BY est plus puissante qu’il n’y paraît. Elle est garante de l’ordre des résultats retournés. Si dans certains cas l’ordre n’a pas d’importance, le contraire peut également être valable. Et c’est précisément dans ce cas que l’on aime à pouvoir manipuler les données comme on l’entend.
Il existe d’autres possibilités intéressantes en combinant par exemple le tri et les recherches FULLTEXT pour récupérer les lignes par ordre de pertinence ou pourquoi pas sur des résultats de calcul.

Read/WriteWeb fait partie de mes sources d’informations quotidiennes. Je suis tombé aujourd’hui sur un article concernant le lancement d’une nouvelle application Facebook permettant de recommander ses extensions favorites : Rock your Firefox.

Ca tombe bien puisque je songeais depuis quelques jours à parler des extensions que j’utilise quotidiennement dans Firefox. Certaines n’intéresseront que les développeurs, d’autres les amateurs de praticité.

Extensions Firefox

Avant toute chose, si jamais vous vous posiez la question où trouver de nouvelles extensions pour Firefox (ou Thunderbird ou d’autres produits Mozilla), rendez-vous sur Mozilla Add-ons.
L’application Facebook Rock your Firefox reprend la liste des extensions et des thèmes en vous proposant de choisir vos préférées et de les partager sur votre profil. C’est un bon moyen pour afficher votre qualité d’utilisation de ce navigateur libre et gratuit.

Extensions « Pratiques »

Adblock

Certains sites sont envahis de publicités qui gênent affreusement la navigation. Plutôt que de se passer d’un contenu intéressant, autant supprimer les nuisances. Adblock est là pour ça. Que ça soit des images,des animations Flash ou bien encore des scripts JavaScript, Adblock liste le contenu des ressources bloquables et permet même de créer des filtres génériques à l’aide du caractère * (wildcard, remplace un à plusieurs caractères, peu importe lesquels).
Attention toutefois, la publicité est vitale pour de nombreux sites donc bloquez avec intelligence.

Google Browser Sync

C’est certainement l’extension que j’installe en premier et pour cause : Google Browser Sync sauvegarde tous mos favoris, cookies et historique de navigation de manière sécurisée.
Je l’utilise sur plusieurs ordinateurs et plusieurs installations de Firefox ce qui me permet de retrouver tous mes favoris peu importe où je me trouve, à partir du moment où il y a une connexion Internet. A utiliser pour vos sauvegardes ou vos besoins de mobilité.

PDF Download

Je n’aime pas que les documents PDF s’ouvrent directement dans un onglet ou une fenêtre de mon navigateur Web. Surtout quand les plus lourds le font planter. PDF Download affiche systématiquement plusieurs choix tels que Afficher dans la page, Ouvrir en tant que PDF ou encore Télécharger directement.

Screengrab!

Screengrab est une solution propre pour effectuer une capture d’écran de sa portion visible, d’une page Web complète ou bien d’une portion d’écran bien définie. Vous l’aurez compris, pas besoin de faire 10 000 captures pour une page étalée en hauteur et pas besoin d’avoir Photoshop ou The Gimp d’installé pour s’en sortir.

Tab Mix Plus

Tab Mix Plus apporte un lot considérable d’options pour mieux régler le comportement de vos onglets. Personnellement je l’utilise pour que toute nouvelle fenêtre se charge obligatoirement dans un nouvel onglet sans me déranger (chargement en arrière-plan). Je profite aussi de son indicateur de chargement allant de 0 à 100%.
En revanche j’évite son système de récupération en cas de plantage, il fonctionne moins bien que celui intégré à Firefox (pour les rares cas où cela s’est produit chez moi).

Extensions « Développeur Web »

ColorZilla

ColorZilla est une simple pipette colorimétrique mais ô combien efficace. Un clic sur un endroit de la page mémorise automatiquement le code couleur associé et permet de l’utiliser sous plusieurs formats dans n’importe quel autre programme dont Photoshop ou votre éditeur CSS favori.

DOM Inspector

C’est la seule extension qui ne se télécharge pas/plus (jusqu’à la version 1.5 c’était encore possible). L’inspecteur DOM s’installe en même temps que Firefox (si vous cochez la case adéquate) et permet comme son nom l’indique, d’inspecter les noeuds de votre document (HTML ou XML), d’en voir leurs attributs, fonctions et ce de manière récursive.
L’analyse en temps réel permet même de voir les modifications apportées à l’arbre DOM par le biais du JavaScript.

Firebug

Firebug est obligatoire lorsqu’on souhaite explorer avec aisance la structure HTML d’un document, exécuter du JavaScript à même la page ou déboguer efficacement son code, ne serait-ce qu’en se rendant compte des temps de chargement des différents fichiers (CSS, JavaScript, Flash etc.).
Ca incite notamment à taper son code directement dans sa console plutôt qu’à le modifier et recharger la page pour déceler des erreurs ou étudier le comportement de la page. On gagne du temps et votre employeur de l’argent.

Firebug : YSlow

YSlow est une extension Firefox mais dédiée à Firebug. Une petite première made in Yahoo! très utile. Cette extension permet de calculer les performances de la page, suggère des optimisations et analyse les différents composants ainsi que leurs caractéristiques (URL, poids, temps de réponse et ETag).
Indispensable pour les phases d’optimisation et de fine tuning comme dirait l’autre.

Operator

Je vous ai déjà parlé de l’intérêt des microformats ? Operator est un outil notifiant des microformats actifs sur les pages que vous visitez. Outre la navigation interactive procurée, Operator signale dans la console de débogage d’éventuelles erreurs (élément absent, malformé ou invalidant un microformat).

TimeStamp Converter

Le nombre 1198533599 vous dit quelque chose ? Avec TimeStamp Converter ça sera le cas. Cette extension convertit les temps Unix en heure humainement compréhensible et vice-versa. Elle le fait également à partir de sélections de texte, évitant ainsi toute saisie pénible.

Web Developer

Le Saint-Graal du développeur Web. Triturer la page, modifier ses mécanismes, débloquer des champs en lecture seule, afficher les champs masqués, topographie de la page, modifier la résolution et afficher l’arborescence en cascade de la page jusqu’à un élément pointé de la souris sont le genre d’outils fournis par Web Developer. Couplée avec Firebug, vous transformez un « simple » navigateur Web en machine de guerre du développement Web propre et efficace.

Ca peut sembler inutile à première vue lorsqu’on utilise MySQL au travers d’API d’autres langages (PHP, Perl, C# etc.). Et pourtant ça peut vous être très utile pour économiser des requêtes, du temps à programmer ces boucles et puis surtout, par flemme.

Oui, la flemme est pour moi la qualité numéro un du développeur car le flemmard a pour but d’arriver à ses fins en un minimum d’efforts.

Déclaration de variables

On peut déclarer une variable de deux façons dans MySQL.
La première méthode consiste à utiliser l’opérateur SET.

SET @pierre = 3, @feuille = 3 + 2, @ciseau = @pierre % @feuille ;

On peut également consister une variable à partir d’une requête.

SELECT @nb_total := COUNT(*) FROM `ma_table` ;

Note : dans ce cas là, on préfixe l’opérateur = de : (deux points).

Utilisation simple des variables

L’utilisation première qui peut en être faite c’est d’assainir vos requêtes SQL en évitant au maximum l’apparition de variables issues d’autres langages.
Avant :

SELECT * FROM `ma_table` WHERE colonne1 = {$variable1}, colonne2 = '{$variable2}' LIMIT 1;

Après :

SET @variable1 = {$variable1}, @variable2 = '{$variable2}';
SELECT * FROM `ma_table` WHERE colonne1 = @variable1, colonne2 = @variable2 LIMIT 1;

Comme les variables sont effectives pour la connexion courante, une variable MySQL peut être réutilisée à tout moment. De quoi décomplexifier certains scripts pas forcément bien structurés.

Utilisation complexe des variables

Les variables peuvent également être modifiées à même la requête. C’est à dire qu’à chaque itération effectuée par MySQL, le moteur va réévaluer le contenu de la variable. J’ai notamment eu besoin de ça pour ajouter de nouveaux éléments à la suite d’autres tout en renumérotant leur ordre. Je souhaitais éviter une boucle récursive en PHP qui aurait occasionné de multiples requêtes.

Je dispose d’une table (item_liste) avec plusieurs éléments, une clé primaire sur deux champs (item_id et item_cat) ainsi qu’un autre champ indexé permettant de les trier dans un ordre donné (item_ordre). Le but : prendre des éléments de la catégorie 1 pour les mettre à la suite de la catégorie 2.

Voici en gros ce que ça donne au final :

SELECT @ordre := IFNULL(MAX(item_ordre), 0) FROM `item_liste` WHERE item_cat = 2 ;
UPDATE `item_liste` SET item_ordre = @ordre := @ordre+1, item_cat = 2 WHERE item_cat = 1 ;

1. On compte la borne supérieure de la catégorie 2. Pourquoi un IFNULL ? Parce MAX() retournera NULL si un des item_ordre en contient un. C’est une sécurité ;
2. On met à jour les éléments de la catégorie 1 avec leur nouvel ordonnancement et leur nouvelle catégorie.

Alors pourquoi ça fonctionne ? La commande UPDATE balaie les lignes une par une et du coup, met à jour la variable @ordre à chaque ligne. Nous retrouvons ainsi l’effet désiré : incrémenter chaque ligne déplacée dans la nouvelle catégorie.

Il existe des utilisations plus compliquées que celles-là mais je pense que c’est un bon départ pour se faire une idée de ce qui est faisable par ce biais là. L’imagination et les besoins feront le reste

Sélection optimisée avec IN()

IN() devrait être utilisé dès lors que l’on a plusieurs critères sur un même colonne. L’écriture suivante ne devrait pas apparaitre dans votre code :

SELECT * FROM `ma_table` WHERE id = 3 OR id = 5;

A la place, il devrait y avoir ceci :

SELECT * FROM `ma_table` WHERE id IN (3, 5);

C’est une habitude à prendre car elle permettra d’automatiser bien des choses. Imaginez qu’on ne fasse plus cette sélection « en dur » mais à partir d’un tableau PHP. Trois façons d’écrire la requête, vous verrez vite laquelle sera la plus pratique à réutiliser :

$tableau = array(3, 5);
/* Méthode 1 : vite-fait mal fait */
$separateur = '';
$sql = "SELECT * FROM `ma_table` WHERE ";
foreach( $tableau as $id )
{
	$sql .= $separateur." id = ".$id;
	$separateur = ' OR ';
}
/* Méthode 2 : utilisation "optimisée" avec des OR dans la requête */
$sql = "SELECT * FROM `ma_table` WHERE id = ".implode(' OR id = ', $tableau);
/* Méthode 3 : passe-partout */
$sql = "SELECT * FROM `ma_table` WHERE id IN (".implode(',', $tableau).")";

Le gros avantage de la dernière méthode c’est le retraitement des données. Il est facile et plus logique d’imploser et d’exploser une chaine composée de séparateurs virgule (ou autre caractère employé aux mêmes fins).

$tableau = array(3, 5);
$tableau = implode(',', $tableau);
/* du code nécessitant $tableau en tant que chaîne */
$tableau = explode(',', $tableau);
/* du code nécessitant $tableau en tant que tableau */

Aggrégats avec GROUP_CONCAT()

Dans les exemples précédents, $tableau était rempli « en dur ». Dans la vraie vie, ça ne se passe pas comme ça : on récupère des identifiants (clés et/ou index) pour valider les sélections. L’exemple basique : on veut mettre à jour une table de configuration avec les ID d’articles présents dans une ou plusieurs catégories.

$tableau = array();
/* Sélection des ID */
$query = mysql_query("SELECT id FROM `ma_table` WHERE cat_id IN ('fromage', 'tortues');");
while( $ligne = mysql_fetch_assoc($query) )
{
	$tableau[] = $ligne['id'];
}
/* On met à jour notre table de configuration */
$tableau = implode(',', $tableau);
mysql_query("REPLACE INTO `table_config` (config_id, config_valeur) ".
	"('cache_articles', '{$tableau}')");

C’est simple, propre et on se dit qu’on a bien bossé. Et pourtant, l’utilisation de la fonction d’agrégation GROUP_CONCAT() de MySQL nous épargnera quelques lignes. On appréciera :

$tableau = array();
/* Sélection des ID */
$query = mysql_query("SELECT GROUP_CONCAT(id) AS cache_articles FROM `ma_table` WHERE cat_id IN ('fromage', 'tortues');");
$tableau = mysql_fetch_assoc($query);
/* On met à jour notre table de configuration */
mysql_query("REPLACE INTO `table_config` (config_id, config_valeur) ".
	"('cache_articles', '{$tableau['cache_articles']}'");

Bref, on a gagné une boucle (le while), des lignes de résultats MySQL (autant de ressources d’économisées) et un traitement PHP en moins (implode). Et devinez quoi ? Le résultat retourné par le GROUP_CONCAT s’intègre très bien dans le … IN().

Voyons ensemble 10 combinaisons de touches avec Control, facilement mémorisables. Ces combinaisons se retrouvent sur la plupart des logiciels Windows, Linux et Mac OS X à la différence près que pour ce dernier, c’est la touche Pomme qui interagit.

Sur la première rangée de votre clavier :

• Control + A (All, tous) : sélectionner tout le contenu d’une zone active (document, zone de texte etc.) ;
• Control + Z : annule un changement et revient à l’état précédent. Très pratique dans les éditeurs de texte pour corriger rapidement une phrase ;
• Control + T (Tab, onglet) : crée un nouvel onglet dans les applications gérant ce mécanisme (Firefox, Internet Explorer 7, GAIM etc.) ;

Sur la deuxième rangée de votre clavier :

• Control + Q (Quit, quitter) : ferme entièrement une application ;
• Control + S (Save, sauvegarder) : enregistre le document actif. Indispensable avec les éditeurs de texte ;

Sur la troisième rangée de votre clavier :

• Control + W (Window, fenêtre) : ferme l’onglet actif dans les applications gérant ce mécanisme ;
• Control + X (Cross, Cut, couper) : coupe la sélection (texte, documents) en attendant d’être collée ;
• Control + C (Copy, copier) : copie la sélection (texte, documents) en attendant d’être collée ;
• Control + V : colle la sélection (texte, documents) ;
• Control + N (New, nouveau): crée un nouveau document au sein de l’application (fenêtre, fichier etc.).

Ca peut paraître barbare à première vue et pourtant. Regardez votre clavier : ce sont systématiquement des touches placées en début de rangée et allant vers la droite. Toutes ces combinaisons s’effectuent facilement avec une seule mains et 2 doigts.
Pour faire simple et efficace : appuyez sur la touche Control avec votre auriculaire puis sur son complément avec votre index OU votre majeur pour les touches les plus proches de Control. Ca évite les contorsions inconfortables.

Personnellement je préfère largement abuser du Control + S que faire confiance aux sauvegardes automatiques (surtout quand on connaît la capacité de Microsoft Office à détruire vos fichiers). Vous économisez des clics, votre poignet et du temps tout en gagnant en confort d’utilisation.