Country / Dev

Il n’y a pas que Mootools dans la vie, il y a aussi JQuery. Et lui aussi a des trucs sympa qui sont malheureusement absents (pour l’instant) de Mootools. Par exemple sa version 1.3 a introduit les Live Events qui peuvent grandement faciliter la gestion des événements dans vos pages. Je l’ai donc adapté pour Mootools 1.2

Plus je fais de javascript « lourd»  plus j’ai besoin de générer du code HTML via mes scripts. Au début j’utilisais les méthodes du DOM (createElement, appendChild, etc.) mais dès qu’on a une structure HTML un peu compliquée ça devient vraiment le bordel (et ce même avec un framework). Et je ne vous raconte même pas l’horreur pour la maintenance après…

Il restait la solution du bon vieux innerHTML, non standard mais qui marche très bien et est très rapide. Mais ça ne convenait pas vraiment si je voulait insérer mon bout de code après un élément précis, ajouter des événements sur une portion précise de ce code etc.

Donc je me suis fait une petite méthode String.toDOM() qui permet de convertir une chaine de caractère en noeuds DOM.

Il y a quelque temps j’avais fais un post Organiser ses CSS. Depuis, j’ai mis au propre la documentation des conventions que j’utilise pour mon boulot.

Ce n’est encore que des documents de travail alors il manque sûrement plein de choses et il y en a sans doutes d’autres qui ne sont pas très claires, n’hésitez pas à me le signaler.

• Conventions de codage (x)HTML
• Conventions de codage CSS

Tout intégrateur aura tôt ou tard à faire à un script de pub, ces bouts de javascript qui viennent faire un gros document.write() au milieu de votre belle page codée avec amour. Oui, c’est dur, mais vous êtes bien souvent obligé de le mettre…

Me voila de retour de Paris Web 2008 et je dois dire que c’est encore une édition réussie pour ce rendez-vous incontournable pour tous les professionnels du web français.

C’est déjà la 3ème édition et c’est toujours du bonheur : des conférences toutes plus intéressantes les unes que les autres, des rencontres avec des gens super intéressants et bien sûr une superbe ambiance.

Petit aperçu (ironique) des différents types de développeurs.

Évidement je ne rentre dans aucun groupe (ça serait trop facile), je pense que je me situe à peu prêt entre le pragmatique et le ninja⁽¹⁾, avec un petit côté libriste aussi.

• Os : Windows XP⁽²⁾ / Ubuntu
• Éditeur : Aptana
• Langages favoris : PHP, xHTML, CSS, Javascript⁽³⁾
• VCS : Subversion⁽⁴⁾
• Navigateur : Firefox

Et vous ?

1. Vive les claviers ergonomiques ! Et faudrai que je trouve le temps de me mettre à Dvorak
2. Et oui, je reste un joueur malgré tout.
3. Je suis dev font-end, ça se voit tant que ça ?
4. Intéressé par Git, mais ça manque encore de client desktop potable.

Il vous arrive peut être comme moi de développer des petits utilitaires afin de vous faciliter la vie. Histoire de pouvoir expédier quelques tâches répétitives en 1 clic je me suis fait 3 utilitaires en ligne de commande avec le language AutoIt.

J’ai l’impression de me répéter, mais apparemment tout le monde n’est pas encore au courant qu’il faut utiliser des noms de class sémantiquement correcte lorsque l’on fait ses CSS.

Par là je veux dire assigner à vos éléments une class qui désigne leur rôle et non pas leur apparence. Le rôle du CSS est de séparer le contenu de la présentation, si vous insérez dans votre contenu des class décrivant la présentation des éléments alors vous perdez le principal avantage des CSS !

Exemple, j’ai un message d’erreur (un texte en rouge) à afficher dans ma page, je lui met donc une classe .red :

.red { color:red; }

Ça marche, c'est génial. Tout se passe bien, jusqu'au jour où le client veut que le message s'affiche plutôt en orange ! Vous vous retrouvez alors avec :

.red { color:orange; }

La logique de votre code vient d'en prendre un coup. Vous pouvez aussi renommer en .orange toutes les class .rouge dans vos templates, quel temps perdu tout ça pour une couleur qui change... Alors qu'avec une simple class .error mon code serait resté logique et flexible malgré les éventuelles modifications futur.

Donc non, n'utilisez jamais de class qui décrivent l'apparence de vos éléments, même si vous vous dîtes que le style de votre élément ne changera jamais, vous pourriez être surpris !

Jamais ?

Ok, il peux y avoir des exceptions dans des cas précis.

En particulier si la personne qui doit manipuler ces class n'a pas un profil technique. Le cas que je rencontre régulièrement c'est le client qui veut aligner une image à droite dans une page, mettre un texte en bleu, etc. (et qui n'a pas accès à un outils WYSIWYG). Dans ce cas là vous pouvez lui définir quelques class utilitaires avec des noms assez explicite (parce que lui pensera apparence et pas rôle) pour qu'il puisse utiliser dans ses créations. Il y a sans doute d'autres cas particuliers où on pourrait être amené à utiliser ce genre de noms de class, si vous avez des exemples...

Ouf, la semaine dernière était bien chargée entre le Google Developer Day le jeudi et le Mozilla Add-Ons Workshop le samedi suivant.

Google Developer Day

Comme à son habitude Google avait mis mes petits plats dans les grands avec un superbe cadre à l’ENSA (salle de jeu, coin repos, buffets, …) et bien sûr les conférences et ateliers.

Mais j’ai plutôt été déçu des ateliers, en particulier celui sur Open Social (1h présentation, 1h « démerdez-vous» ). Tandis que celui sur Android nous a gavé de code avant de nous montrer le résultat final (amha un décorticage pas-à-pas de l’application aurait été plus efficace).

Bref, je suis un peu resté sur ma faim. Dans mes souvenirs, l’édition de l’année dernière avait été beaucoup plus intéressante.

Mozilla Add-Ons Workshop

Le samedi, le MAOW avait lieu dans un lieu moins tape à l’oeil, à savoir La Cantine, mais que j’ai néanmoins trouvé beaucoup plus chaleureux. De plus, les présentations étaient vraiment intéressantes !

Pour commencé j’ai assisté à l’atelier « Votre première extension»  présenté par Paul Rouget (c’est toujours aussi impressionnant à quel point il maitrise son sujet).

Puis on a eu le droit à « Javascript pour adultes»  avec pas mal d’infos sur les nouvelles capacités présentes dans les dernières versions de javascript et une présentation de ce que sont les closures. Vraiment très intéressant, mais oubliez les nouveautés de javascript 1.7 / 1.8 si vous voulez faire autre chose que des add-ons, ça n’est pas présent dans IE (étonnant non ?)

Ensuite nous avons eu le retour d’expérience du développeur d’Adblock plus : qu’es ce qui fait qu’une extension devient populaire, comment gérer son évolution et sa communauté, etc. Là, j’avoue que j’ai faillit m’endormir (désolé).

Enfin on nous a présenté FUEL, la bibliothèque javascript intégrée à Firefox 3 qui permet de simplifier le développement d’extension aux développeurs.

Bref, en conclusion, j’ai trouvé la journée de Mozilla beaucoup plus intéressante que celle de Google (en plus le t-shirt du MAOW est plus joli ) et ça m’a plus donné envi de me (re)plonger dans les techo de Mozilla que dans celles de Google (maintenant il faut que je trouve la motivation et le temps).

En attendant, comme d’habitude, vous pouvez retrouver mes quelques photos des 2 événements sur mon compte flickr.

Ça y est, comme promis google chrome est sortit en beta. Après l’avoir testé quelques instants je dois dire qu’il me laisse une impression plutôt positive, rien de totalement révolutionnaire mais des petits détails qui rendent la navigation plus agréable.

Je ne vais pas vous décrire en détails les fonctionnalités (des milliers d’autres blogs vont s’en charger, ne vous inquiétez pas), mais plutôt me concentrer sur ce qui nous intéresse nous les développeurs, à savoir les performances javascript, les spécificités du navigateur et les outils de développement fournis.