Si vous passez par là, bonne année.

La Fabrique comprend les nouveaux locaux de trempolino (avec les salle de répétitions), ainsi que le nouveau complexe de salles de concert Stereolux.

En deux mots :
C’est moche.

Ce n'est pas très conviviale.

Pour être un peu plus explicite, c’est comme si on avait attrapé le chaton de la convivialité, qu’on avait mis son poing tout à l’intérieur de sa bouche et qu’on l’avais retourné comme une vulgaire chaussette.

Oui, ça reste à l’image de l’architecture de ce coin de l’Ile de Nantes, mais il faut avouer que pour un lieu censé être chaleureux, ce genre de bâtiment n’est pas idéal. Certains trouverons ça «moderne», voir «classe», et se réjouirons d’avance des soirées branchés qu’ils passerons là bas.

Du reste, la programmation est à l’image des locaux : ce soir ce sont les Horrors qui jouent.

Ho, et je donnerais mon point de vue sur les salles de concerts elles-mêmes quand j’aurais l’occasion d’y faire un tour…

Article rapide pour parler de Fruitopia.

Journalisme d'investigation, je me suis déplacé pour enquêter. Sérieux.

C’est Coca-Cola qui fait ça. C’est tout simple, un jus d’eau avec deux trois saveurs fruitées, mais c’est cool. Ils vendent ça dans la plupart des fast-food, et ils ont le culot de mettre ça dans le rayon des jus de fruits

Je crois que c’est vendu au Canada et en Australie. Donc, si vous y passez…

Comment ne pas commencer cette série par Tim Hortons, la chaîne de restaurant la plus répandue au Canada (devant Subway, devant McDonald’s).

Le flou, tout l'art de savoir prendre des photos.

À l’image de Dunkin’ Donuts, Tim Hortons est un restaurant de beignes (les beignes étant connus en France sous le sobriquet de « hum-des-Donuts »).  On y trouve donc des beignes de tout types, des muffins, et diverses pâtisseries. Ils vendent aussi des sandwichs et des soupes mais tout ça ne représente finalement que peu d’intérêts. Les cafés en revanche sont intéressants, en particulier le cappucino à la vanille française.

Toutes ces choses là ont un nom à eux. Roussette au miel, Boston à l'érable, au chocolat...

À noter qu’ils ont produit, les Timbits, qui est devenu extrêmement populaire.

Timbits, d'après Wikipedia

Le nom non commercial du produit est « trou-de-beigne », et c’est parfait avec le café.

Bref, Tim Hortons est une vrai institution au Canada. Si vous débarquez à l’aéroport Trudeau de Montreal, vous aurez la chance d’en trouver un à l’étage des arrivées.

De plus, ça sera l’occasion de parler d’autres choses que ces sales trucs de geeks

J’ai depuis quelque temps créé un nouveau portail ou je publie des plugins javaScript pour le populaire framework jQuery. Pour le moment, ils sont assez peu nombreux, et très spécifiques (beaucoup liés aux projets que j’ai rencontré), mais je prévois d’ici peu de temps d’en publier deux plus importants. Le code source est hébergé par gitHub.

Pour visiter ce site, c’est ici : plugins jQuery.

Le W3C, trop souvent montré du doigt par le passé comme une communauté de développeurs fermés aux besoins d’intégrateurs pas forcement issus du monde du développement (infographistes, amateurs, etc.), a décidé de faire un consensus reléguant à l’état de conventions de code certaines choses qui étaient devenus obligatoires, à juste titre, avec XHTML.

Aujourd’hui, ou en sommes nous ? HTML5 est il une application de SGML ou de XML ? En fait, ça dépend de vous. Vous pouvez très bien décider de servir votre page comme document XML, ou de ne pas le faire tout en respectant la syntaxe XML-like. Tout est convention.

Voici 5 mauvais patterns  que je vous déconseille fortement d’appliquer dans vos codes.

1.Ne pas fermer les tags

<p>Ceci est un paragraphe non fermé

Sans doute le pire retour en arrière avec HTML5 : vous avez le choix de fermer ou non les tags.

Pour rappel, certains tags en HTML4 ne devaient strictement pas être fermés (br, img). D’autres étaient juste permissifs (li, option).

Aujourd’hui, c’est juste à vous de choisir. Et si vous décidiez d’alterner une fois sur deux, ça ne serait pas une erreur non plus. C’est très laid bien évidemment, et je vous conseille de continuer à fermer les tags en permanence. Votre code respectera un standard qui vous permettra, par exemple, de l’ouvrir à des communautés, ou de mieux travailler en équipe. Ça vous semble long ? Prenez le temps de configurer correctement votre IDE.

2.Ne pas encadrer les valeurs de vos attributs

<div id=monId></div>

HTML5 vous permet de ne pas avoir à encadrer les valeurs de vos attributs avec des quotes ou double-quotes. Encore une fois, ce n’est pas parce qu’il permet ça qu’il faut forcement tomber dans le piège. Continuez d’utiliser les double-quotes, pour les mêmes raisons que vous fermerez vos balises. Ne pas le faire ne représente de plus aucun intérêt.

3.Créer des attributs sans valeurs

<input type="text" required />

Encore une nouvelle liberté que l’on peut prendre dans HTML5 : ne pas donner de valeur à un attribut. Un attribut est un ensemble clé/valeur. Oui, vos navigateurs, s’ils trouvent l’attribut readonly, sauront le traiter. Imaginons que vous ayez à parser votre document avec une application qui ignore HTML ? Il n’aura aucune idée de ce ça signifiera. Ça n’arrivera pas ? Soyez propre, mettez une valeur. Votre collègue le fera, lui, peut-être.

4.Valider son document n’a plus aucune valeur

C’est un peu une synthèse des 3 premiers points. HTML5 est très mal nommé. Il peut donner l’impression que XHTML a été dans l’impasse, qu’il a été oublié, qu’on est reparti de HTML4 et qu’on a fait HTML5.

C’est bien entendu faux, et si vous n’avez jamais eu l’occasion de faire du XHTML, je vous conseille de le pratiquer un peu avant de vous lancer dans HTML5.

En effet, le validateur du w3c se contentera désormais de vérifier que votre document est bien formé selon ses normes désormais permissives. Ce n’est pas une bonne manière d’apprendre à respecter les conventions généralement acquises.

XHTML a permis de créer une expertise dans le domaine du HTML que HTML4 n’aurait jamais été capable d’atteindre. C’est grâce à XHTML que nous avons pu comprendre et mettre en place des documents sémantiquement correcte (souvenez vous des balises de style de HTML4 comme b). Il a apporté une rigueur, et nous a donné un autre regard sur la structure d’une page web. Il nous a aidé à utiliser javascript au mieux, grâce à ses DOM fatalement correctement formés.

Ce savoir faire a pris place dans le métier, et c’est aujourd’hui le standard qualité attendu. Ne faites pas l’impasse sur ces standards, quand bien même ils sont relégués au rôle de conventions de code. C’est ce qui fera la différence entre un bon développeur frontend et les autres.

5.Faire passer HTML5 pour ce qu’il n’est pas

En vérité ce n’est pas vraiment HTML5 le soucis, mais plutôt le bruit qu’on fait autours.

Il est régulier qu’on attribut à HTML5 des comportements qui ne viennent pas de lui, ou pas totalement. Le soucis, c’est que ces comportements concernent soit le style, soit le traitement.

Non, HTML5 n’est pas CSS3.

Et non, HTML5 ne permet pas de se passer de JavaScript pour «dragger» un élément.

En fait le langage est toujours bien conçu pour maximiser la séparation des données, du style et de l’interaction. L’attribut draggable peut rendre sceptique au premier abord. Il autorise en effet un élément à être bougé dans une page. Seul, on ne peut rien en faire. En revanche, avec les nouveaux évènements associés (dragstart, dragend, etc.), on peut facilement utiliser du JavaScript pour traiter tout ça. Vous pouvez donc continuer de faire confiance à votre framework JavaScript préféré. S’il est sérieux, il intégrera rapidement ces solutions dans son code.

Pourquoi ces mauvais patterns

Après l’échec de XHTML2.0, HTML5 a répondu en particulier à deux catégories d’acteurs de la vie du web :
D’abord, ceux qui souhaitaient aller plus loin dans la sémantique du code. À ce niveau on s’y retrouve tous : experts en SEO, puristes du web correctement compartimenté, etc.
Ensuite, beaucoup ne voyaient pas l’intérêt d’appliquer les règles « restrictives » de XHTML. Souvent par mauvaise habitude, il faut bien le dire. Le fait d’avoir un langage « compliqué », réservé aux développeurs, peut-être vu comme un frein pour le développement du business (les employeurs savent comme il est difficile de trouver de bons intégrateurs aujourd’hui). C’est un peu le même combat que pour les noms de domaines de premier niveau, qui s’ouvrent aujourd’hui à des entreprises, au grand dam de la neutralité du web. La technique cède la place au marketing et au business.

Cependant, il est probable que le «mauvais» HTML5 finisse par rencontrer les mêmes limites et les mêmes problèmes qu’avec HTML4, et que le code «utile» soit celui qui respecte les conventions habituelles. Ne changez donc pas vos bonnes vieilles habitudes avec HTML5, profitez des nouveaux tags pour créer des applications dont la lisibilité, la durée de vie et la maintenabilité sera plus grande. Après tout, quelques mauvais points, dans un océan de belles nouveautés, c’est très peu

En exposant mon soucis, j’ai eu une conversation fascinante, donc j’aimerais parler ici.

Mon problème concernait le framework jQuery. J’imaginais trouver, sur les serveurs de jabberfr.org, fréquentés par des technophiles (libristes, linuxiens, développeurs d’applications), quelques âmes particulièrement bien au courant du fonctionnement de ce framework.

Et bien je me suis fait plus ou moins incendier. En fait, pas moi, mais JavaScript en général, jQuery en particulier. En effet, je suis tombé sur une gentille bande de geeks dont le point de vue est que «Javascript est mauvais dans le web, il n’est jamais utile», ou, pour d’autre, «jQuery est lourd et inutile». Plusieurs d’entre eux disant désactiver le javascript sur leur navigateur.

JavaScript était un peu un mouton noir au début des années 2000. Il est vrai que le langage possède bon nombre d’inconvénients, de mauvais patterns, et les implémentations étaient très inégales. De plus, beaucoup de gens récupéraient des bouts de code sur leurs sites sans même savoir ce qu’ils faisaient : un copier/coller et c’était bon.

Mais JavaScript possède aussi de bons morceaux, et utilisé proprement, il apporte un réel plus aux applications web. XHR est passé par là et a poussé les développeurs à rentrer plus profondément dans le langage.

Voici donc quelques raisons pour lesquelles javaScript et jQuery (ou n’importe quel framework maintenu en réalité) peuvent être bons pour le web.

JavaScript est facultatif

Avant tout, il est bon de rappeler que l’utilisation de javaScript, de Ajax, n’est pas obligatoire sur une page. Dans bien des cas, l’utilisation de javaScript sera superflue. C’est d’autant plus vrai que transition arrive avec CSS3. JavaScript est une surcouche pour permettre l’interaction entre le visiteur et le site. Il arrive des cas ou cette interaction est inutile.

JavaScript ne nuit pas à l’accessibilité

Contrairement à une idée reçue, JS ne nuit pas à l’accessibilité. À condition de bien travailler

En effet, un site bien développé sera utilisable avec ou sans JavaScript. Si on est rigoureux dans son développement, alors ce n’est pas beaucoup plus compliqué. Il n’y a pas vraiment besoin, par exemple, de faire 2 versions de son site, une avec JS et l’autre sans.

Pour l’ajax, une bonne stratégie backend permettra de régler simplement les problèmes qui peuvent se poser à vous. Du côté frontend, il est important de toujours utiliser des href et des action (pour les formulaires) valides !

En ce qui me concerne, ma stratégie est d’utiliser une URL commune pour une action, qu’elle soit réalisée en Ajax ou en statique. Pour un form par exemple, je vais mettre un action vers le traitement standard du formulaire. Le serveur renverra par défaut la page complète de résultat du formulaire. Si je décide d’intercepter le submit en javascript pour faire un traitement Ajax, ma requête pointera sur le lien du action (le même qu’en statique donc), j’injecterais juste le format de retour désiré, json par exemple. Mon backend effectuera le même traitement, il aura reçu les mêmes données, il se contentera de me servir du json au lieu du html. C’est très facile à mettre en place, et très facilement généralisable.

JavaScript est standardisé

ECMAScript est le nom du standard mis en oeuvre dans JavaScript ou JScript (Microsoft) par exemple. De plus, on peut se baser sur le DOM pour manipuler sa page. Il faut reconnaître et être conscient que les implémentations ne sont pas toutes égales. Mais ce n’est pas forcement la jungle qu’on décrit régulièrement.

jQuery est DRY

Don’t Repeat Yourself. J’ai parlé des différences d’implémentation de ECMAScript selon les navigateurs. C’est là qu’interviennent les framework. Qu’est ce qu’un framework ? Un framework est une base de travail donnant accès à des méthodes utilisées très couramment par les développeurs. L’objectif est de ne pas avoir à réinventer la roue à chaque fois.

Par exemple, lorsque l’on souhaite passer une requête « ajax », on effectue beaucoup de routines très répétitives : on doit vérifier quelles sont les méthodes disponibles (selon les navigateurs), construire son objet XHR, surveiller les étapes, etc. Un framework offre une méthode, et parfois plusieurs helper, pour effectuer ces routines le plus simplement possible, en faisant abstraction entre autre du navigateur. Pour jQuery par exemple, on a accès à $.ajax(), ou encore, pour un cas plus particulier, à $.getJSON(), dont le nom est transparent.

Il existe plusieurs frameworks, et jQuery n’est pas forcement le meilleur d’entre eux. Il est le plus populaire, bien qu’il ne soit pas le plus léger ou le plus performant. On y trouve donc beaucoup de sources (malgré une documentation assez moyenne, qui ne rentre pas assez dans le détail à mon gout), beaucoup de plugins. Quand à la question de la simplicité ou non, c’est une question de confort et de philosophie. jQuery adopte un point de vue « élément », ce sont les éléments qui sont au centre. En ce qui me concerne, j’ai su adopter ce point de vue et je trouve le framework très agréable à utiliser. Je trouve que le code produit est beau, et qu’il se rapproche beaucoup de la bonne manière de coder en JavaScript. Tout développeur n’aura pas ce sentiment là, c’est une question subjective.

Un des effets d’utiliser un framework communautaire est aussi la réactivité dans l’ajout des nouveautés. Je vais parler plus loin de HTML5 draggable par exemple. On peut être certain que cela sera implémenté dans les framework très bientôt. Et on n’aura pas à changer notre code, c’est l’implémentation de la méthode .draggable() qui aura changé. Le tout sera fait de manière transparente pour nous.

Les CDN grand public rendent jQuery disponible pour tous les utilisateurs

jQuery, comme d’autre frameworks, est disponible sur des cdn publics, comme Google. Un cdn est, grosso-modo, un serveur de fichier optimisé. Les avantages sont multiples, mais dans le cas qui nous concerne ici, si on utilise un cdn comme google par exemple, on peut supposer que les visiteurs on déjà chargé la librairie dans le cache de leur navigateur avant d’arriver sur votre site. C’est donc du temps de gagné pour eux.

Les navigateurs sont de plus en plus performants pour le JavaScript

Ce qu’on reproche à jQuery, c’est sa lourdeur. Il est vrai que la bibliothèque est composée de beaucoup d’éléments dont on a pas besoin sur sa page, et qu’il n’est pas possible, à l’instar de jQueryUI, de créer son fichier custom n’embarquant que le nécessaire. Il est vrai aussi que le fichier est parsé à chaque reload de la page. D’où l’importance d’optimiser sa page, en chargeant les javascript autant que possible en bas de page. Mais il faut aussi savoir reconnaitre que les moteurs javascript des navigateurs ont étés énormément optimisés des dernières années pour supporter au mieux le JavaScript. Les résultats sont devenus très acceptables.

HTML5 encourage le JavaScript

Et oui. Autant HTML5 et CSS3 veulent reprendre le contrôle sur leurs domaines respectifs (données et présentation), ce qui est une très bonne chose (les nouveautés dans les formulaires sont les bienvenues), autant certaines nouveautés encouragent à utiliser JavaScript, dans les meilleures conditions. Je penses en particulier à l’attribut draggable (un booléen), qui ne sert juste à rien si on intercepte pas les évènements avec du javascript.

JavaScript est une surcouche qui apporte un réel plus à l’expérience utilisateur

Écoutez ce que vous conseille votre spécialiste UX. Vous pourrez rarement répondre à ses recommandations sans utiliser une surcouche JavaScript.

L’expert sait ce qui est bon pour l’utilisateur, c’est son métier. Il saura vous guider pour savoir ce qui est bon pour l’utilisateur, ce qui représente un plus dans son expérience de navigation, ce qui va convertir. C’est une bonne occasion de séparer ce qui est utile ou non, et donc d’éviter le javascript inutile.

Une bonne communication entre lui et vous permettra de mettre en place la meilleure stratégie possible pour garder votre page «user-friendly» malgré la non disponibilité de certains composants chez l’utilisateur (c’est vrai pour javascript comme pour css).

De plus, difficile de dire « non » à un spécialiste de l’ergonomie, sous pretexte qu’un composant n’est pas proposé dans HTML ou CSS, quand ce composant est utilisé partout sur le web.

JavaScript est prototypé

Ce n’est pas forcement un point qui fait la force de JavaScript, c’est juste quelque chose dont il faut avoir conscience.

Un des aspect les plus déroutant pour les développeurs débutant en javascript est l’absence de classes. En effet, le langage est prototypé. C’est un concept qui peut sembler bizarre au début, qui peut être source de commentaires négatifs (surtout quand on associe programmation orientée objet aux classes), mais qui mérite d’être assimilé. Cela permettant de mieux cerner le sérieux du langage.

En conclusion

Bien sûr qu’il faut assurer l’accessibilité. Bien sûr qu’il ne faut pas surcharger ses pages de JavaScript. Mais en 2011, il est devenu un indispensable du web, et il est dommage de le renier totalement.

L’une des raisons qui conduit certains à faire ce choix est que bon nombre de développeurs web font des erreurs agaçantes.

Une autre raison ouvrirait la porte à un débat plus important : pour certain, le web applicatif est une erreur. Il ne devrait être que l’objet de partage de données (des pages HTML plus ou moins statiques). Ces gens là sont en contradiction avec leurs propos quand ils proposent un formulaire de commentaires sur leurs blogs (n’est-on pas là au commencement d’une web-app, même sans JavaScript ?). Mais, si j’ai le temps, ça fera l’objet d’un autre article.

Vous trouverez à cette adresse des tutos et des astuces en HTML et CSS3. Profitez en, c’est gratuit.

Ubuntu 11.04 est sorti, et il propose désormais par défaut Unity.

Pour rappel, Unity est une surcouche graphique, plutôt populaire sur les netbook, qui change considérablement l’expérience utilisateur.

Pour le moment j’ai été plutôt dérouté. La mise à niveau a en effet supprimé bon nombre de mes réglages Compiz, qui ne sont pas directement compatibles avec Unity, et après les premiers problèmes graphiques, je suis revenu à l’interface Gnome d’origine.

J’imagine que je prendrais le temps de l’utiliser au fur et à mesure.