HTeuMeuLeu

Lu chez James Hague, « Une compréhension complète n’est plus possible » :

Supposons que vous venez juste d’acheter un MacBook Air, et que votre objectif est de devenir maître de la machine, de comprendre comment elle fonctionne à tous les niveaux.

Le livre « Mac OS X Internals: A Systems Approach » d’Amit Singh est un bon début. Ça ne parle pas tant de programmation que de discours approfondis sur la façon dont toutes les parties du système d’exploitation fonctionnent entre elles : ce que fait le firmware, les séquences d’événements durant le démarrage, ce que les drivers font, et ainsi de suite. A 1680 pages, ce n’est pas une petite lecture.

Pour vraiment comprendre le matériel, Intel a gentiment mis à disposition une documentation gratuite en 7 volumes. Je vais rester simple en recommandant la lecture de Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture (550 pages) et les deux volumes décrivant les jeux d’instructions (respectivement 684 pages et 704 pages).

[…]

Le total de tout ça, c’est plus de 11 000 pages de lecture. J’ai omis d’inclure les pages man pour des centaines d’utilitaires système et la documentation d’Xcode. Et je n’ai même pas encore abordé les connaissances graphiques nécessaires pour faire quoi que ce soit d’intéressant avec OpenGL, ou comment écrire du bon C ou Objective-C ou quoi que ce soit concernant la conception orientée objet, et…

Son article touche un très bon point, et ça m’a rappelé cette vidéo de l’excellent Richard Feynman  (prix nobel de physique et joueur de bongo) qui remets un journaliste à sa place quand il lui demande comment fonctionnent des aimants. Si vous ne connaissez pas Richard Feynman, rendez-vous service et regardez cette vidéo.

Le journaliste : Quand vous tenez deux aimants, et que vous les poussez l’un contre l’autre, vous sentez cette pression entre les deux. Et quand vous les retournez, et ils se collent l’un avec l’autre. Qu’est-ce que c’est cette sensation entre deux aimants ?

Richard Feynman : Qu’entendez-vous par « qu’est-ce que c’est cette sensation ? »

Le journaliste : Et bien, il se passe quelque chose. Cette sensation, il y a quelque chose…  quand vous collez deux aimants l’un contre l’autre.

Richard Feynman : Ecoutez ma question : qu’entendez-vous par « quelle est cette sensation » ? Bien sûr qu’il y a quelque chose. Mais que voulez-vous savoir ?

Le journaliste : Ce que je veux savoir, c’est ce qui se passe, entre ces deux morceaux de métal.

Richard Feynman : Les aimants se repoussent l’un l’autre.

Le journaliste : Oui mais qu’est-ce que ça signifie ? Ou pourquoi est-ce qu’ils font ça ? Ou comment est-ce qu’ils font ça ? … J’estime que c’est une question parfaitement raisonnable.

Richard Feynman : Bien sûr ! C’est même une excellente question ! Mais le problème, c’est quand vous demandez « Pourquoi quelque chose se passe ». Comment quelqu’un réponds à une question comme ça ?

Par exemple, Tante Minny est à l’hôpital. Pourquoi ? Parce qu’elle a glissé sur la glace et qu’elle s’est cassée la hanche. Cette réponse satisfait les gens. Mais ça ne satisferait pas quelqu’un qui vient d’une autre planète et qui ne connaît rien de nous. Par exemple pourquoi quand on se casse la hanche on va à l’hôpital ? Comment vous rendez-vous à l’hôpital quand votre hanche est cassé ? Et bien son mari a vu qu’elle s’était cassé la hanche, il a appelé l’hôpital pour que quelqu’un vienne la chercher. Tout ceci est compris implicitement par les gens.

Quand vous expliquez « Pourquoi », vous devez être dans un cadre de travail qui permets à quelque chose d’être vrai. Sinon vous continuerez éternellement de demander pourquoi.

Pourquoi est-ce que le mari a appelé l’hôpital ? Parce que le mari est intéressé par le bien être de sa femme. Mais tous les maris ne sont pas toujours intéressés dans le bien être de leur femme, quand ils sont soûls et en colère. Et donc vous commencez à avoir une compréhension très intéressante du monde et toutes ses complications. Si vous essayez de poursuivre la moindre branche, vous irez de plus en plus loin dans différentes directions.

Je pense que c’est vrai également pour le métier d’intégrateur. Avec toutes les nouveautés techniques apparues rapidement ces dernières années (HTML5, CSS3, Canvas, WebGL, …), et la mise en avant massive des technologies côté client en dehors du web (applications mobile, Windows 8, …), il n’est plus possible pour un intégrateur de maîtriser l’ensemble des technologies mises à sa disposition. Le métier d’intégrateur et plus largement de développeur front-end va alors se diviser en de nouvelles branches, tout comme il y a 10 ans le métier d’intégrateur s’était détaché du métier de webdesigner.

On en arrive alors à ce que vous aimez faire. Qu’est-ce que vous préférez ? Est-ce l’organisation de contenus basés sur la sémantique HTML ? Ou la mise en page en CSS ? Ou le développement d’interactions en JavaScript ? Est-ce que vous souhaitez continuer à faire des sites web ? Ou est-ce que vous voulez vous spécialiser dans le développement d’applications web (pour mobiles ou pour les OS dédiés) ?

Peu importe la réponse, trouvez ce que vous aimez, et creusez le sujet à fond. Car peu importe votre spécialité, ça deviendra votre plus grand atout.

J’ai souvent eu à intégrer des pages statiques avec des longues listes de liens. La plupart du temps, les chefs de projets utilisent Excel (ou OpenOffice, LibreOffice ou Google Docs) pour rassembler et partager tous ces liens. Typiquement, on va y trouver une colonne avec l’intitulé du lien, et un autre avec l’URL du lien.

A partir de ces liens, je vais devoir générer le code HTML suivant :

<ul>
<li><a href="http://www.hteumeuleu.fr/chrome-sous-android-ne-supporte-pas-flash/">Chrome sous Android ne supporte pas Flash</a></li>
<li><a href="http://www.hteumeuleu.fr/cout-grandissant-developpement-interactif/">Le coût grandissant du développement interactif</a></li>
<li><a href="http://www.hteumeuleu.fr/produire-c-est-decourager-la-creativite/">« Produire, c’est décourager la créativité. »</a></li>
<li><a href="http://www.hteumeuleu.fr/statistiques-google-janvier-2012/">Les statistiques de Google+ en janvier 2012</a></li>
</ul>


Une façon basique d’arriver à ce résultat serait d’intégrer chaque lien un par un, en copiant l’intitulé du lien, en le collant dans son éditeur de code, puis en copiant l’URL du lien, et en la collant dans son éditeur de code. Mais clairement, c’est long, fastidieux et très pénible. Et ce n’est clairement pas adapté pour des documents de plusieurs centaines de liens.

Voici une façon beaucoup plus simple d’arriver au même résultat en utilisant de simples formules dans un tableur. Ces formules fonctionnent en principe dans n’importe quel tableur (Excel, OpenOffice, LibreOffice, Google Docs), mais selon la langue du logiciel il est possible que vous deviez traduire le nom des fonctions utilisées.

Dans un tableur, pour concaténer deux valeurs de cellules ou deux chaînes de caractères, on va utiliser l’opérateur & (ex : A1 & A2). Une chaîne de caractère doit être délimitée par deux double guillemets anglais (ex : A1 & « toto »). Pour échapper des double guillemets dans une chaîne de caractère, il faut écrire deux double guillemets. Voici alors la formule qu’on utiliserait dans une colonne C pour générer la balise d’un lien dont le contenu se trouve dans la colonne A, et l’URL dans la colonne B.

="<li><a href=""" & B1 & """>" & A1 &"</a></li>"

Si vous avez un document bien formaté, vous pouvez dores et déjà étendre cette formule à tout votre colonne, et vous n’aurez plus qu’à copier/coller le tout dans votre page HTML ! Mais souvent, les documents de ce genre sont remplis d’annotations, avec des lignes vides ou commentées pour structurer un peu le document. On va alors peaufiner un peu notre formule en ajoutant un traitement conditionnel avec la fonction IF (ou SI en français). Cette fonction prends 3 paramètres : IF(test; valeur si vrai; valeur si faux). Afin de s’assurer qu’on doit bien générer du HTML pour la ligne en cours, on va vérifier si la cellule de la colonne URL n’est pas vide. Si c’est le cas, on génère bien le HTML, sinon on n’affiche rien. On obtient alors la formule suivante :

=IF(B1<>""; "<li><a href=""" & B1 & """>" & A1 & "</a></li>" ;"")

Pour finaliser tout ça, je peux également insérer une nouvelle formule dans une cellule vide qui va concaténer toutes mes balises <li>, et les englober dans une balise <ul>. Pour concaténer rapidement toute une plage de cellule, on va utiliser la fonction CONCATENATE(). Ça donne quelque chose comme ça :

=CONCATENATE("<ul>"; C3:C56; "</ul>")

Et voilà ! Vous n’avez plus qu’à copier le contenu de cette cellule dans votre page HTML. J’ai créé sur Google Docs un document d’exemple pour que vous puissiez voir le résultat directement.

Il y a 2 ans, le 24 février 2010 à 15h52, je publiais mon premier tweet. A la base, j’ai créé un compte Twitter surtout pour moi. Chaque jour, je lis beaucoup d’articles, de tutoriels et d’actualités sur le développement web. Je conservais les articles qui m’intéressaient vraiment dans mes favoris, mais c’est très vite devenu ingérable. Je me suis dit qu’en les publiant sur Twitter, je pourrais facilement en garder une trace, et qu’au passage, ça intéresserait peut-être d’autres gens.

Il s’avère que ça ne s’est pas trop mal passé.

Il se trouve que j’aime beaucoup Twitter. J’essaie de garder le nombre de comptes que je suis à un nombre raisonnable, en suivant principalement des comptes orientés web. Mais en réalité, je me rends compte que ces 2 dernières années, Twitter a été ma première source d’informations, même bien au-delà de l’actualité du web.

Quelques mois plus tard, j’ai lancé ce blog. L’objectif de ce blog est d’être la continuité du compte Twitter, en partageant mon point de vue sur des sujets qui me tiennent à coeur. Certains appellent ça du troll, mais sincèrement, ce n’est que mon point de vue. Et ceci n’est qu’un blog personnel.

Je lis beaucoup d’articles sur beaucoup de blogs, et je suis toujours aussi surpris de la neutralité et de la consensualité que certains rédacteurs adoptent sur leurs blogs personnels. Je préfère largement lire un article passionné, avec un point de vue (quitte à ne pas être d’accord), plutôt qu’un article sans saveur digne d’un communiqué de presse.

Il y a une citation que j’aime bien (bizarrement attribuée à Mark Twain) qui dit « Danse comme si personne ne te regardait ». J’essaie d’adopter cette philosophie sur mon blog, en écrivant comme si personne ne me lisait. Et si ça peut rassurer mes détracteurs, c’est souvent le cas.

Voici quelques statistiques sur mon blog depuis son lancement en juillet 2010. J’ai eu 98 509 visites, 67 496 visiteurs uniques, et 213 808 pages vues. 58% de mes lecteurs sont sur Windows, 22% sur Mac OS, 9% sur Linux et 6,5% sur iOS (oh, et Android : 2,55%). 43% sont sur Firefox, 33% sur Chrome, 9% sur Safari et 4% sur Internet Explorer (et parmi ces 4%, 54% sont sur IE8, 25% sur IE9, 14% sur IE7, 5% sur IE6). La nuit je rêve d’avoir des statistiques de navigateurs similaires sur les sites de mes clients. 38% de mon trafic est direct, 20% vient de Twitter, 18% vient de Google, 8% vient de Facebook (et 0,5% vient de Google+).

Voici une petite liste des articles les plus vus sur mon blog :

5. Des maquettes difficilement intégrables… wait, what ? (octobre 2011)
4. Estimer un temps de développement, c’est difficile (février 2012)
3. Le Pixel Perfect (mai 2011)
2. Des démos WebGL (février 2011)
1. Les développeurs, graphistes et chefs de projets (juin 2011)

Laissez moi revenir en détails sur ce numéro 1. La réception de cet « article » a été phénoménale. Pourtant, j’ai vraiment fait cette image à l’arrache, un mardi soir devant la télé, quelques semaines après avoir vu une image du même genre sur Reddit. Le mercredi matin, je l’ai publiée, et puis je l’ai twittée. Et là, ça a été l’avalanche. Depuis sa publication, l’article a été vu plus de 33 000 fois sur mon blog, et le fichier JPG seul a été vu plus de 76 000 fois depuis mon serveur, générant plus de 7 Go de trafic. Mais l’image a aussi été reprise un nombre impressionnant de fois sur d’autres blogs. Elle a même été traduite en anglais quelques semaines plus tard, et retweetée par George Broussard himself. Grâce ou à cause de cet article, voilà à quoi ressemblent les statistiques du blog ces 2 dernières années.

Je pense que cet anniversaire est la bonne occasion pour remercier tous mes lecteurs et tous mes followers. Alors : merci.

 

Adobe a publié cette semaine sa feuille de route pour Flash ces prochaines années, et je ne pouvais pas être plus satisfait :

Avec la croissance de la compétition sur le marché des navigateurs, les fabricants de navigateurs ont de plus en plus innové et ont fourni des fonctionnalités qui ont permis de déployer des animations riches directement grâce aux technologies du navigateur, une rôle autrefois joué principalement par Flash Player. De plus en plus, les animations riches seront déployées directement dans le navigateur en utilisant HTML5, CSS3, JavaScript et les autres technologies modernes du web. Alors que le rôle premier de Flash en tant que moteur d’innovation sur le web reste le même, ce pour quoi il sera utiliser va changer.

Adobe croit que les moteurs d’exécution de Flash se prêtent particulièrement bien à deux utilisations principales : créer et déployer des jeux riches, expressifs avec des graphismes de la qualité d’une console, et déployer des vidéos premium.

Ce changement de cible pour Flash ne signifie pas que les contenus existants ne fonctionneront plus, ou que Flash ne pourra pas être utilisé pour des contenus autres que du jeu et de la vidéo. Par contre, ça signifie que lorsque nous devrons prioriser les développements futurs et les corrections de bugs, le jeu et la vidéo seront nos priorités.

Soyons clairs : aujourd’hui, si vous souhaitez diffuser de la vidéo et que vous êtes un minimum sérieux, vous êtes obligés de proposer une alternative à Flash. D’après NetMarketShare, les utilisateurs mobiles représentent 9% des internautes, et ce chiffre ne va faire qu’augmenter ces prochaines années. Aujourd’hui, plus de 60% du marché des navigateurs supporte nativement les vidéos en HTML5, et ce chiffre ne va faire qu’augmenter ces prochaines années. Les vidéos en HTML5 ont des lacunes, comme l’absence de gestion de contenus protégés (DRM). Mais Adobe le dit clairement : à part pour de la vidéo premium, utiliser Flash est une hérésie.

Et quand au jeu, j’ai un tout petit peu de mal à voir comment Adobe va s’en sortir. Depuis 3 ans, Adobe nous rabâche chaque année des nouvelles démos de jeux en 3D époustouflantes avec des gros éditeurs : Square Enix, Epic Games et l’Unreal Engine, … Mais ces 3 dernières années, tout ceci en est resté au stade de vidéo de présentation.
En comparaison, ces 3 derniers mois, on a vu arriver les portages en HTML5 de deux des jeux les plus vendus l’année dernière : Angry Birds et Cut the Rope. Il ne s’agit pas de vidéos de promesses de ce que pourraient potentiellement être des jeux en HTML5. Non, il s’agit du vrai truc.

Adobe en profite pour détailler sa feuille de route pour 2012 avec de nouvelles versions de Flash Player (noms de code « Cyril » et « Dolores »), et présente vaguement les prochaines fonctionnalités de Flash pour les années à venir (« Flash Player Next »).

Adobe présente également le support fourni pour Flash pour les différents systèmes et plate-formes, en rappelant la toute fraîche annonce de l’abandon de Flash Player pour Linux aux mains de Google. Voici un petit récapitulatif du support de Flash pour le web :

• Apple OS X : Flash Player est toujours supporté, mais n’est plus installé par défaut sur aucun Mac.
• Microsoft Windows : Flash Player est supporté (pour le moment).
• Windows 8 : Flash Player (comme tout autre plugin) ne fonctionnera pas dans la version Metro de Windows 8 (destinée aux écrans tactiles).
• Linux : Flash Player est supporté, désormais par Google, uniquement sous Chrome.
• Mobile : Flash Player n’est plus supporté.
• Télévision : Flash Player n’est plus supporté.

Je ne voudrais pas vendre la peau de l’ours avant de l’avoir tué, mais ça me fends le coeur de voir un ours agoniser ainsi.

Depuis le début de l’année, j’ai l’impression que chaque semaine voit son lot de nouveaux scandales autour de Google. En voici une petite liste non exhaustive :

• Google a monté une vaste escroquerie au Kenya pour se faire passer pour un annuaire local et inciter les entreprises à créer un site sur l’équivalent du très mauvais « Mon entreprise en ligne ». (source)
• Des employés de Google ont été surpris en train de vandaliser les données d’OpenStreetMap. (source)
• Google a pénalisé Chrome dans ses résultats de recherche, lui faisant perdre 0,17% de parts de marché en janvier, après avoir violé ses propres règles de SEO pour promouvoir Chrome. (source)
• Google a changé sa politique de respect de la vie privée, les autorisant à faire du croisement de données entre tous leurs services pour mieux vous profiler. Si vous n’êtes pas d’accord, vous n’avez aucune possibilité de refuser ce changement de politique. (source)
• Google favorise désormais les résultats de son propre réseau social, Google+, au détriment de la pertinence et de la neutralité de son moteur de recherche (source)
• Larry Page aurait dit à ses employés : « Comprenez Google+ ou partez »
• Google contourne les préférences de vie privée de Safari et d’IE pour continuer de vous traquer. (source)
• Google a supprimé les liens de ses logos pour revenir à l’accueil, le b.a.-ba de l’ergonomie depuis la nuit des temps. (source)

Et on est que le 53ème jour de 2012. Google devrait relire son propre code de conduite.

Il y a deux semaines j’avais parlé sur Twitter de PSD.js, un fichier JavaScript pour lire des fichiers PSD. Après quelques tests avec les PSD que j’avais sous la main, j’ai vite compris que ça ne fonctionnait pas très bien. J’aurais pu blâmer les développeurs de la librairie, ou les faiblesses de mon navigateur. Et puis je me suis souvenu d’un commentaire laissé par un développeur de Xee, une visionneuse d’images sous Mac, en plein milieu de son code.

A ce stade, je voudrais prendre un moment pour vous parler du format PSD d’Adobe. PSD n’est pas un bon format. PSD n’est même pas un mauvais format. L’appeler ainsi serait une insulte pour les autres mauvais formats, comme PCX ou JPEG. Non, PSD est un format exécrable. Pour avoir travaillé sur ce code pendant plusieurs semaines maintenant, ma haine envers le format PSD a grandi en un feu ardent qui brûle avec la violente passion d’un million de soleils.

S’il existe deux façons différentes de faire quelque chose, le format PSD fera les deux, à des endroits différents. Ensuite il inventera trois autres façons qu’aucun humain sain d’esprit n’aurait pu imaginer, et il les fera également. Le format PSD fait de l’incohérence une forme d’art. Pourquoi, par exemple, est-ce qu’il a soudainement décidé que ces morceaux en particulier devraient s’aligner sur 4 octets, et que cet alignement ne devrait pas être inclus dans la taille ? D’autres morceaux à d’autres endroits ne sont pas alignés, ou alors alignés avec l’alignement compris dans la taille. Ici, pourtant, ce n’est pas compris. N’importe lequel de ces trois comportements serait bien. Un format sensé en choisirait un. Le format PSD, bien sur, utilise les trois, et plus.

Essayer d’extraire des données d’un fichier PSD c’est comme essayer de trouver quelque chose dans le grenier de votre vieil oncle excentrique qui est mort dans une attaque de requin en se baignant en eau douce le jour de son 58ème anniversaire. Ce dernier détail n’est peut-être pas important dans cette comparaison, mais à ce stade je passe beaucoup de temps à imaginer des destins amusants pour les gens responsables de ce format digne de Rube Goldberg.

Plus tôt, j’ai essayé d’obtenir les dernières spécifications du format PSD. Pour ça, j’ai du m’inscrire auprès d’Adobe pour obtenir la permission de faire une demande pour qu’ils puissent envisager de m’envoyer ce tome sacré. Ça impliquait de devoir leur faxer une copie de tel ou tel document, probablement signé de mon sang. J’imagine seulement qu’ils rendent ce processus si difficile parce qu’ils sont intensément honteux d’avoir créé cette abomination. Je n’étais naturellement pas suffisamment crédule pour aller au bout de la procédure, mais si je l’avais fait, j’aurais imprimé chacune des pages des specs, et je les aurais brûlées. Si j’en avais le pouvoir, je rassemblerais toutes les copies de ces specs, et je les lancerais dans une fusée directement vers le soleil.

Le format PSD n’est pas mon format préféré.

J’ai toujours ce coup de gueule bien en tête à chaque fois que j’utilise des formats de fichiers créés par Adobe.

Vu sur Quora il y a quelques semaines, une honnête question : « Pourquoi les tâches de développement logiciel sont en général fausses d’un facteur de 2 ou 3 ? ». Michael Wolfe, CEO de Pipewise, a posté une excellente réponse.

Partons en randonnée sur la côte de San Francisco à Los Angeles pour rendre visite à nos amis à Newport Beach. Je sors ma carte et je dessine notre route le long de la côte.

La ligne doit faire environ 600 kilomètres de long. On peut marcher 6 kilomètres par heure pendant 10 heures par jour, donc on sera là bas dans 10 jours. J’appelle nos amis et on réserve le dîner pour samedi soir prochain, quand on arrivera sur place triomphalement à 18h. Ils ont hâte !

On se lève tôt le lendemain, excité de partir à l’aventure. On enfile nos sacs à dos, on emporte notre carte, et on planifie notre premier jour. On regarde notre carte. Oh oh :

Waow, il doit y avoir un million de tours et détours sur la côte. Une journée de 60 kilomètres va à peine nous emmener à Half Moon Bay. Ce voyage doit faire au moins 800 kilomètres, pas 600. On appelle nos amis pour reculer le dîner au mardi. Mieux vaut être réaliste. Ils sont déçus, mais ils sont impatients de nous revoir. Et 12 jours pour aller de San Francisco à Los Angeles n’est toujours pas si mal.

Passé cette mauvaise surprise, on décolle. Deux heures plus tard, on a à peine dépassé le zoo. Comment ça se fait ? On regarde derrière nous :

Qu’est-ce que c’est long ! Du sable, de l’eau, des marches, des criques, et des lions de mer en colère ! On avance au mieux à 3 kilomètres par heure, la moitié de ce qu’on voulait faire. On peut soit commencer à marcher 20 heures par jour, ou on peut repousser notre dîner avec nos amis encore d’une semaine. OK, partageons la différence : on va marcher 12 heures par jour et repousser notre dîner avec nos amis au week-end suivant. On les appelle pour décaler le dîner au samedi suivant. Ils sont un peu agacés mais disent « OK, on vous verra là alors ».

On campe à Moss Beach après une dure journée de 12 heures. Merde, ça prends des plombes pour monter ces tentes avec le vent. On ne se couche pas avant minuit. Pas grave : on va s’endurcir un peu et on accélérera un peu demain.

On dort trop longtemps et on se réveille mal en point et fatigué à 10 heures. Putain ! Pas moyen qu’on arrive à faire nos 12 heures. On va viser 10, et on en fera 14 demain. On prends nos affaires et on y va.

Après une lente marche de quelques heures, je remarque que mon ami boîte. Oh merde, des cloques. Il faut qu’on s’occupe de ça maintenant… On est le genre d’équipe qui tue les problèmes dans l’oeuf avant qu’ils ne viennent nous ralentir. Je cours pendant 45 minutes, 5 kilomètres vers Pescadero, pour acheter des pansements, et file retrouver mon ami pour le soigner. Je suis épuisé, et le soleil est en train de se coucher, alors on abandonne pour la journée. On va se coucher après avoir parcouru seulement 10 kilomètres cette journée. Mais on a quelques ravitaillements. Ça va aller. On rattrapera la différence demain.

On se lève le lendemain matin, des pansements pleins les pieds et on se mets en route. On sort d’un virage. Et merde ! Qu’est-ce que c’est que ça ?

Notre satané carte ne montrait pas tout ça ! Il faut qu’on marche 5 kilomètres dans les terres, autour de terrains grillagés protégés par le gouvernement, qu’on se perde deux fois, puis qu’on retourne vers la côte autour de midi. Une partie de la journée est partie pour seulement 1,5 kilomètres de progrès. OK, on ne va pas appeler nos amis pour reculer encore une fois. On va marcher jusqu’à minuit pour essayer de rattraper notre retard et reprendre notre planning.

Après une nuit troublée de court sommeil dans le brouillard, mon ami se réveille le lendemain avec une violente fièvre et des maux de tête. Je lui demande s’il pense pouvoir reprendre. « Qu’est-ce que tu crois, trou du cul, ça fait 3 jours que je marche dans un brouillard glacial sans prendre une pause ! ». OK, c’est tout pour aujourd’hui. On va s’accrocher et se remettre sur pieds. Demain on marchera 14 heures vu qu’on sera reposé et entraîné… On n’est plus qu’à quelques jours, alors on va y arriver !

On se lève le lendemain un peu groggy. Je regarde notre carte :

Oh merde ! On commence le 5ème jour de notre voyage de 10 jours, et on n’a même pas quitté la baie. C’est ridicule ! Faisons l’effort de faire une estimation précise, appelons nos amis, quitte à se faire crier dessus, mais avec une date réaliste une bonne fois pour toutes.

Mon ami dit que nous avons fait 60 kilomètres en 4 jours, c’est un voyage d’au moins 1000 kilomètres, donc environ 60 jours, peut être 70 pour être sûrs. Je dis « Pas moyen… oui, je n’ai jamais fait cette marche avant, mais je sais qu’il ne faut pas 70 jours pour marcher de San Francisco à Los Angeles. Nos amis vont se moquer de nous si on les appelle et qu’on leur dit qu’on ne les verra pas avant Pâques! »

Je continue, « si tu peux t’engager à marcher 16 heures par jour, on peut rattraper la différence ! Ce sera dur, mais c’est un moment crucial. » « Va te faire foutre », me rétorque mon ami, « Ce n’est pas moi qui ait dit à nos amis qu’on serait là dimanche à la base ! T’es en train de me tuer parce que toi tu as fait une erreur ! »

Un silence tendu tombe entre nous. Aucun coup de fil ne sera passé. J’appellerais demain quand mon camarade aura repris ses esprits et sera prêt à s’engager sur quelque chose de raisonnable.

Le lendemain matin, on reste dans nos tentes jusqu’à que la pluie diluvienne s’arrête. On remballe nos affaires et on décolle à 10h après s’être occupé de nos cloques et nos muscles. La dispute de la veille n’est pas mentionnée, mais je parle un peu durement à mon idiot d’ami quand il oublie sa bouteille d’eau derrière, et qu’on doit perdre 30 minutes pour retourner la chercher.

Je me fais une note mentale qu’on va arriver à bout de papier toilette et qu’il faudra qu’on se restocke quand on arrivera dans la prochaine ville. On arrive au coin d’un détour : une imposante rivière nous barre le passage. Je sens une énorme diarrhée arriver…

Bret Victor est un concepteur logiciel/développeur/visionnaire. Il a travaillé 4 ans chez Apple et a plus récemment travaille sur l’excellent livre interactif Our Choice sur iPad. Hier matin, la toile était en ébullition devant une vidéo d’une conférence de Bret Victor au CUSEC2012 : « Inventing on Principle« . Au cours de cette conférence, il explique l’importance dans le monde informatique d’avoir des principes qui guident vos choix, vos décisions techniques et vos créations. Et il détaille son propre principe :

Si nous écrivons du code sur un ordinateur, pourquoi est-ce que nous simulons ce que l’ordinateur devrait faire dans notre tête ? Pourquoi l’ordinateur ne peux pas juste le faire et nous le montrer ?

Au cours des 35 premières minutes de sa conférence, Bret présente différents outils et interfaces qu’il a développé pour faciliter sa créativité, et obtenir un rendu immédiat de tout son code. Si vous faites du développement JavaScript, du développement Flash, de l’animation pour le web ou du web en général, vous devez impérativement regarder cette conférence.

Au cas où vous n’auriez pas le temps de regarder cette vidéo ou ne seriez pas encore totalement convaincu, voici quelques détails sur sa présentation.

En premier lieu, Bret présente un éditeur Canvas HTML5. La particularité de cet éditeur, fidèle à son principe de création, est d’afficher en temps réel la moindre modification. Il présente d’abord l’exemple d’une illustration d’un paysage en Canvas (de 2’30 à 9’30), puis d’un mini jeu de plates-formes inspiré de Braid (de 10’30 à 16’30). Si vous n’avez que quelques minutes, prenez le temps de regarder ce deuxième exemple (et si Vimeo vous insupporte, j’ai uploadé cet extrait sur Youtube).

Outre les petits détails bien pensés de son interface (comme la possibilité de moduler rapidement la valeur d’une variable, numérique ou d’une couleur par exemple), la nature même de JavaScript et son exécution à la volée est ici mise en avant de façon extraordinaire. Si vous faites du Flash, ça risque d’être difficile de revenir à la réalité et à votre routine habituelle : je code pendant 5 minutes, je compile pendant 1 minute, je teste 30 secondes, et je recommence.

Un des gros avantages de JavaScript et son exécution à la volée est également mis en avant à travers un 3ème exemple (de 17′ à 23′): la création d’un algorithme de tri binaire. Si vous développez, vous connaissez la routine : vous réfléchissez à un algorithme, vous codez une première version, vous testez un premier cas, vous ajustez si nécessaire, vous testez un deuxième cas, vous réajustez si nécessaire, etc… Ici, une partie de l’interface retranscrit en direct les valeurs des différentes variables de votre code, tout en précisant vous même les valeurs de tests des paramètres passés à votre fonction.

S’en suit une présentation d’un 4ème exemple (de 23′ à 28′) démontrant cette fois-ci l’intérêt d’une interface en temps réel hors programmation informatique avec des circuits électroniques. Et enfin, le clou du spectacle (de 29′ à 34′), la réalisation en 2 minutes d’une animation sur iPad, littéralement faite à la main, qui aurait pris une journée à faire sur l’IDE de Flash pour un néophyte.

Cette conférence véhicule pleins de valeurs que j’essaie de défendre à travers mes articles : l’importance d’un mantra, la pertinence de JavaScript comme étant un langage digne de ce nom, ou encore le fait que HTML5 pousse à la créativité au delà des limites de tout IDE. Comprenez, donc, mon emballement.

 

Vu la semaine dernière sur Twitter via Asa Dotzler, un article de Mark Shead intitulé « Pourquoi vous devez avoir des connaissances de votre domaine » :

Voici le pistolet à air comprimé Feinwerkbau P11 Piccolo. Il coûte aux alentours de 1500$, et on dirait qu’il a été conçu principalement pour des gens qui font de la compétition. Le canon noir est ce qui propulse la bille, et le canon argenté contient l’air comprimé.

Si vous avez un pistolet qui fonctionne à l’air comprimé, ce serait bien de savoir combien d’air il vous reste n’est-ce pas ? Je ne suis pas sûr que le design ait été bien réfléchi cependant.

Je ne connais pas l’histoire de ce pistolet, mais je sais que vous ne devriez pas avoir à pointer un canon vers votre visage pour lire une jauge.

Quand je vois quelque chose comme ça, j’aime bien m’arrêter et me demander si je fais des erreurs similaires dans mon domaine de développement logiciel. Des erreurs de pauvre conception ne sont pas limitées aux pistolets.

Ce qui me fascine avec ce genre d’exemple, c’est qu’il s’agit d’un produit récent réalisé par une grande société spécialisée dans la fabrication d’armes. La conception de ce produit a très certainement fait intervenir des dizaines de personnes avant de passer en production. A aucun moment, personne n’a eu la présence d’esprit de se dire que ce n’était peut être pas une très bonne idée.

Les États-Unis et l’Union Européenne viennent de donner leur approbation pour le rachat de Motorola Mobility par Google annoncé en août dernier, pour la modique somme de 12,5 milliards de dollars. MG Siegler avait publié il y a quelques semaines un très bon article résumant ce que Google achetait pour cette somme :

Motorola Mobility ont livré — livré, pas vendu — 5,3 millions de smartphones au cours du trimestre. Pour rappel, Apple en a vendu 37 millions.

Sur toute l’année, Motorola a livré — livré, pas vendu — 18,7 millions de smartphones. Pour rappel, Apple a vendu 37 millions de smartphones ce dernier trimestre.

Ils ont livré — livré, pas vendu — 200 000 tablettes ce dernier trimestre. DEUX CENT MILLE. Pour rappel, Apple a vendu 15 millions de tablettes.

Sur toute l’année, Motorola a livré — livré, pas vendu — 1 million de tablettes. Pour rappel, Apple a vendu 15 millions de tablettes ce dernier trimestre.

La société a perdu 80 millions de dollars au cours du trimestre — dont 70 millions étaient de la division mobile. L’unité a perdu 285 millions de dollars au cours de l’année.

Et tout ça pour DOUZE VIRGULE CINQ MILLIARDS DE DOLLARS. En août dernier, John Gruber rappelait ce que cette somme représentait pour Google :

Regardez les résultats financiers de Google. Ils ont rapporté 8,5 milliards de revenus nets cette année, et 6,5 milliards l’année dernière. C’est pour la totalité de Google. Ils offrent 12,5 milliards de dollars pour Motorola. Donc Google vient de dépenser quasiment deux années de ses bénéfices pour acheter un fabricant de téléphone de seconde classe qui est lui même peu rentable, a quasiment fait faillite, et est sans doute seulement le troisième meilleur fabricant d’appareils sous Android, derrière HTC et Samsung.

J’ai un tout petit peu de mal à croire que Google ait dépensé autant pour laisser Motorola « opérer comme une unité commerciale distincte ».

Après le débat lancé par le W3C face aux préfixes des navigateurs, Raphaël Goetter d’Alsacréations a partagé sa solution pour facilement adapter ses sites en utilisant le script -prefix-free.

Comme beaucoup d’outils de ce genre, -prefix-free nécessite une requête HTTP et un traitement du JavaScript, au détriment des performances du navigateur.

En ce qui me concerne, je considère que les avantages fournis contrebalancent ce handicap. Mais sur mobiles, où les temps de chargement sont prépondérants, la question mérite le détour.

J’ai d’abord cru à une blague, mais il est apparemment très sérieux. Jérémie Patonnier a ce matin très bien détaillé la problématique, en titrant son article « Lier CSS à JavaScript : une mauvaise idée ».

De manière générale, ce genre d’interrogations arrive rarement quand on applique un mantra, une philosophie globale, un fil conducteur qu’on applique dans n’importe quelle situation. Personnellement, ma philosophie se résume en une question.

Qu’est-ce qui est le mieux pour l’utilisateur ? 

Le graphiste a maquetté des listes déroulantes personnalisées. Je peux utiliser un script pour simuler une liste déroulante avec la charte maquettée, au détriment des performances de la page, ou laisser les listes déroulantes par défaut du navigateur, au détriment de la charte graphique. Qu’est-ce qui est le mieux pour l’utilisateur ?

Je dois intégrer une page simple avec quelques éléments à rendre dynamique (apparition au clic ou au survol). Je peux utiliser une librairie type jQuery pour coder ça rapidement, ou prendre un peu plus de temps pour coder la même chose en JavaScript seul. Qu’est-ce qui est le mieux pour l’utilisateur ?

J’ai du texte dans une police personnalisée. Je peux importer une police en CSS3 de plusieurs dizaines de Ko, ou découper une image de quelques Ko. Qu’est-ce qui est le mieux pour l’utilisateur ?

En octobre dernier, je partageais déjà mon point de vue sur la finalité d’une page web :

On ne fait pas un site web pour le client. On fait un site web pour un utilisateur. Un utilisateur est une vraie personne. Un utilisateur a son terminal (ordinateur, smartphone, télévision, …), son entrée (clavier/souris, tactile, …), sa sortie (écran 16/9, 4/3, 72 dpi, 326 ppi, …), sa connexion internet (56k, ADSL, Fibre, Edge, 3G, …). Un terminal à son système d’exploitation (Windows, Mac OS, iOS, Android, …), son processeur, sa carte graphique, … En pratique, vous aurez quasiment autant de configurations possibles que de visiteurs. Quand vous travaillez pour le client, vous rendez 1 personne heureuse. Quand vous travaillez pour l’utilisateur, vous rendez des milliers voire des millions de personnes heureuses.

D’autres intégrateurs auront surement un mantra différent, privilégiant par exemple la charte graphique, le temps de réalisation ou le coût d’un projet. On peut y trouver un intérêt sur le court terme. Mais je pense que seule une conception pensée pour l’utilisateur reste valable sur le long terme.

Daniel Glazman, co-président du groupe de travail CSS du W3C, a lancé aujourd’hui un appel à tous les acteurs du web pour éviter que les fabricants de navigateurs n’implémentent les préfixes -webkit- sur le long terme.

Je demande à toute la communauté des acteurs du web d’arrêter de concevoir des sites pour WebKit seulement, en particulier quand le support d’autres navigateurs n’est qu’une question d’ajouter quelques lignes de propriétés CSS avec des préfixes.

Je demande à toute la communauté des acteurs du web de supprimer immédiatement et d’arrêter d’implémenter la détection (sniffing) de navigateurs basés sur WebKit. Vous possédez un tel site ? Montrez votre soutien pour le Web Ouvert et supprimer cette détection immédiatement après avoir lu cet appel.

Je demande à la communauté des utilisateurs du web et des designers du web d’arrêter de recommander des sites qui nécessitent un navigateur en particulier alors qu’ils pourraient être ouverts à plusieurs navigateurs. Ne faites pas de lien vers ces sites, et mentionnez les uniquement pour faire savoir à la communauté qu’ils échouent dans leur service du Web Ouvert. Ne nourrissez pas les trolls, blacklistez les, peu importe à quel point le service qu’ils fournissent est cool.

Je suis totalement d’accord avec Daniel Glazman sur les deux premiers paragraphes. Je plaide coupable d’avoir moi même déjà utilisé des propriétés CSS avec uniquement leur préfixe WebKit (en particulier il y a 1 ou 2 ans, avant que Firefox ne revienne dans la course et commence à implémenter pleins de nouvelles propriétés).

Par contre, je suis convaincu qu’il se trompe de combat en cherchant à lancer une chasse aux sorcières. Mais puisqu’il insiste…

http://www.w3.org/2008/site/css/minimum
Ligne 134: .w3c_leftCol a:hover,.w3c_leftCol li a:focus{ -moz-transition-property:background-color;-webkit-transition-property:background-color;-o-transition-property:background-color;-moz-transition-duration:.3s;-webkit-transition-duration:.3s;-o-transition-duration:.3s;}
Ligne 181: .button{border:0;-moz-border-radius:3px;-moz-box-shadow:0 1px 3px rgba(0,0,0,0.5);-webkit-border-radius:3px;-webkit-box-shadow:0 1px 3px rgba(0,0,0,0.5);border-bottom:1px solid rgba(0,0,0,0.25);background-color:#555;color:#FFF;cursor:pointer;font-size:81%;font-weight:bold;left:5px;padding:2px 5px;position:relative;text-shadow:0 -1px 1px rgba(0,0,0,0.25);} http://www.w3.org/2008/site/css/advanced
Ligne 31: .secondary_nav{ -webkit-box-shadow:0 1px 2px #fff;-moz-box-shadow:0 1px 2px #fff;-webkit-border-radius:5px;-moz-border-radius:5px; }
Ligne 35: #search-form{ -webkit-border-radius:5px;-moz-border-radius:5px;}
Ligne 233: #request_form fieldset input:focus,#request_form fieldset textarea:focus{ -webkit-transition:border .2s linear,-webkit-box-shadow .2s linear;-moz-transition:border .2s linear,-moz-box-shadow .2s linear; }


Le site du W3C lui-même n’utilise pas systématiquement les noms de propriétés non-préfixées, et jamais les préfixes pour l’ensemble des navigateurs (pourquoi tant de haine envers -ms- ?). Je suppose que je devrais faire comme Daniel Glazman, et lui envoyer un e-mail.

C’est facile de dénoncer et de pénaliser. Les acteurs du web ont fait quelque chose de stupide en utilisant uniquement des préfixes -webkit-. Les fabricants de navigateurs vont faire quelque chose de stupide en implémentant les propriétés avec le préfixe -webkit-. Le W3C propose une réponse stupide visant à pénaliser les auteurs du web ignorants ou peu consciencieux.

Avant de vouloir pointer du doigt et pénaliser les sites qui favorisent WebKit, il serait peut être bon d’éduquer les acteurs du web. Nous sommes en 2012 et le W3C ne propose aucune documentation simple et claire, compréhensible par le commun des mortels, indiquant le bon usage et le bon fonctionnement des propriétés CSS. C’est regrettable, mais pas étonnant qu’on se retrouve dans une telle situation.

Hier, lors d’un comité du groupe www-style du W3C, réunissant Daniel Glazman (co-président du groupe de travail CSS du W3C), Tantek Çelik (Mozilla), Florian Rivoal (Opera) et Sylvain Galineau (Microsoft), la discussion la plus hallucinante que j’ai pu lire à ce jour.

glazou: Title is: Why and How to Implement Other Vendors’ Prefixes
tantek: This is a specific subtopic of vendor prefixes
tantek: The problem statement right now, and this is a problem for
Mozilla and any other non-WebKit browser
tantek: Sites have webkit-specific content, and serve backup content to
everyone else. Specifically for mobile content.
tantek: Non-WebKit browsers face prisoners dilemma
tantek: similar to quirks in 2003 or so
tantek: At this point we’re trying to figure out which and how many webkit
prefix properties to actually implement support for in Mozilla
plinss: Zero.
tantek: Currently we have zero. Zero is no longer an option for us.
Florian, Sylvain: Zero is not an option for us anymore either.

Vous avez bien lu : pour Mozilla, Opera et Microsoft, il n’est plus envisageable de ne pas implémenter les propriétés en utilisant les préfixes -webkit-. Et ça ne va pas s’arrêter là :

tantek: We will also need to send a webkit-tricking UA string.
tantek: Just like WebKit sent « like Gecko » in its UA string, we have to do
the same thing again

Je ne sais pas trop comment on peut s’y prendre, mais il va falloir gentiment dire à Mozilla, Opera et Microsoft d’arrêter leurs âneries.

Hier, une toute première beta de Chrome sous Android est sortie. L’application est disponible uniquement sur Ice Cream Sandwich (qui 3 mois après sa sortie représente 1% des appareils sous Android).

Signe des temps, Adobe et Google ont confirmé que Chrome sous Android ne supportera jamais Flash Player. A terme, Chrome va remplacer le navigateur par défaut sous Android. Si vous pensiez encore pouvoir faire des sites en Flash pour mobiles, repensez-y.

R Blank, entrepreneur, formateur ActionScript et fondateur de la communauté Flash à Los Angeles, a écrit un article qui m’a fait sortir de mes gonds : « La mode majeure du développement interactif » (ou « Le coût grandissant du développement interactif » dans sa première publication).

D’un point de vue d’entreprise, la clé à retenir de cette période est que, dollar pour dollar, les expériences fourniront moins de fonctionnalités, pour un plus petit pourcentage de visiteurs. Dit autrement, produire la même fonctionnalité, livrée au même pourcentage du marché, coûtera plus cher.

Cette conclusion n’est pas un commentaire sur les valeurs particulières ni de HTML ou de Flash. C’est plutôt le reflet d’un fait sous-jacent : Adobe absorbe une portion non-insignifiante des coûts de production pour nous autres qui utilisons Flash pour livrer des expériences riches dans un navigateur. Adobe s’assure que Flash tourne de la même manière, dans n’importe quel navigateur, sur n’importe quelle plate-forme, et que vous n’avez pas à vous en préoccuper. Ainsi, Flash représente une subvention significative de la part d’Adobe au reste d’Internet.

Il n’y a aucune société investissant de manière similaire et aussi consistante pour HTML5.  Au lieu de ça, HTML5 fonctionne juste comme les précédentes versions de HTML. C’est un standard international, et les différents fabricants de navigateurs l’implémente différemment. Chaque navigateur que  vous souhaitez supporter accroît les coûts et le temps de production, d’abord en augmentant le temps passé en tests d’assurance qualité, puis au temps de développement passé à résoudre des problèmes spécifiques à des navigateurs qui sont inévitablement découverts.

Son point de vue est évidemment biaisé, et il y tellement de choses fausses ou erronées dans cet extrait que je ne sais pas par où commencer. Mais je partage son interrogation : un développement interactif va-t-il coûter plus cher en HTML5 qu’en Flash ?

Il n’y a aucun débat sur le fait qu’aujourd’hui, faire du développement interactif en HTML5 coûte sensiblement plus cher que du développement en Flash. Dit autrement : développer sur une plate-forme jeune de quelques années coûte plus cher que développer sur une plate-forme lancée en 1996. Ce n’est surement pas pour rien que la plupart des démos interactives qui me viennent à l’esprit (20 Things I Learned, RO.ME, Cut The Rope) sont sponsorisées par les navigateurs eux-mêmes.

Mais je suis convaincu que sur le long terme, le coût du développement interactif tendra vers zéro. Le seul coût imputé au client sera à la hauteur de ses demandes spécifiques. Je suis convaincu que de la même manière que ces 10 dernières années ont vu émerger des tonnes de CMS de grande qualité permettant de créer des sites gratuitement, ces 10 prochaines années vont voir fleurir le même genre de solutions pour l’interactivité côté client. J’en reviens exactement à ce que j’expliquais en novembre dernier, dans mon article « Flash vs. HTML5« .

Avec HTML5, un tout nouveau public découvre les joies et les possibilités de l’animation pour le web. HTML5 est un standard ouvert et gratuit. Avec HTML5, vous facturez à vos clients votre création plutôt que la technologie. Avec HTML5, votre code est constamment visible et accessible aux yeux de tous.

La philosophie de Flash est exclusive; elle pousse à la créativité aux dépends de la technique, à la fermeture et à la lucrativité.

La philosophie de HTML5 est inclusive; elle pousse à la créativité en équilibre avec la technique, à l’ouverture et au libre échange.

Mais évidemment, il s’agit ici de mon point de vue biaisé d’intégrateur. Alors voici maintenant quelques considérations factuelles pour l’avenir.

• 2007 : Apple ne supporte pas Flash sur iOS.
• 2010 : Apple n’installe plus Flash par défaut sur aucun de ses ordinateurs.
• 2011 : Adobe arrête le support de Flash sur mobiles et sur télévision.
• 2011 : Les applications HTML5 de Spotify ne supportent pas Flash.
• 2012 : Internet Explorer 10 ne supportera pas Flash dans sa version Metro.

Plus le temps passe, et moins de plate-formes supporteront Flash. En 2011, la vente d’ordinateurs a continué de chuter, au profit quasiment unique de l’iPad.

Kaelig a publié cette semaine une très bonne conclusion pour « sortir du débat Standards vs. pragmatisme » :

Ne cédez pas au buzz du moment, ne sautez pas sur les nouveautés pour l’amour du risque. Ce n’est pas seulement une affaire de professionnels du web, vous pourriez carrément mettre votre client dans le pétrin si vous manquez de vigilance sur la pérénité des choix techniques que vous effectuez.

En choisissant Flash aujourd’hui, vous assurez à vos clients que votre travail ne fonctionnera plus sur une majorité de plate-formes utilisées dans les 2 ans à venir. Qu’on le veuille ou non, Flash Player va disparaître. Ce n’est plus qu’une question de temps. Vous n’avez pas le choix. A mon avis, la vraie question à se poser pour un professionnel n’est pas « combien ça coûte ? », mais « quand dois-je m’y mettre pour rester compétitif ? ».

J’ai récemment lu Bossypants, l’autobiographie de l’excellente Tina Fey, auteur et comédienne découverte dans le Saturday Night Live, désormais à la tête de la série 30 Rock. A travers le livre, elle raconte son expérience et ce qu’elle a appris en travaillant à la télévision. Elle détaille notamment ce qu’elle retient de son producteur, Lorne Michaels. En voici le premier point qui m’a rappelé pas mal de choses.

Produire, c’est décourager la créativité

Une émission de TV comprends de nombreux départements : costumes, accessoires, talent, graphiques, décors, transports. Chaque personne dans chaque département veut montrer ses compétences et contribuer de manière créative à l’émission, ce qui est une bénédiction. C’est gratifiant de travailler avec des gens qui sont talentueux et enthousiastes pour leur travail. Vous pourriez penser qu’en tant que producteur, votre travail consiste à pousser la créativité, mais la plupart du temps votre travail consiste à contrôler l’enthousiasme. Il peut arriver que le script demande un muffin aux céréales sur une assiette blanche et le Département Accessoires débarque avec un cake aux céréales en forme de père noël servi sur un plateau en argent où il est écrit « Bienvenue au Danemark. » « On pensait que ce serait drôle. » Et vous devez trouver une façon polie d’expliquer que le personnage est juif, donc le fait qu’il mange la tête du père noël peut avoir des connotations négatives, et le plateau en argent, bien que magnifique, donne un reflet bizarre à la caméra et partons plutôt sur un muffin aux céréales sur une assiette blanche.

D’après les statistiques de NetMarketShare relevant le pourcentage de liens référants des plus gros sites, Google+ vient d’atteindre le mois dernier 0,00000%.

Voilà, mon travail ici est terminé.

Cette semaine, Bertrand Keller a traduit un article de Kevin Dees publié chez ThinkVitamin sobrement intitulé « La séparation de la structure, de la présentation et du comportement est morte« .

Prenons l’exemple d’un lien avec un effet visuel lors du survol de la souris. Vous avez le choix entre passer par la CSS pour un effet :hover et/ou utiliser une petite pincée de JavaScript pour la gestion d’un comportement plus complexe.

Avec un changement de couleur géré en CSS et un effet (une opacité par exemple) en JavaScript, le comportement du lien est spécifié dans deux couches différentes : c’est ce qu’on appelle la « divergence ». Ce lieu de gestion subtile de l’effet de survol par deux couches différentes.

L’intégration n’est pas la collage grossier de différentes couches mais plutôt l’emboîtement subtile de plusieurs technologies (ce qui définit, à mon avis, le principe de l’artisanat).

Je suis totalement d’accord sur les subtilités de l’intégration et de ces différents langages. Cependant, je pense sincèrement que la séparation de la structure, de la présentation et du comportement sur le web est tout sauf morte. Au contraire, je dirais qu’avec HTML5 et CSS3, elle vient juste de naître.

Prenez par exemple un tutoriel pour faire un joli menu publié chez WebDesignerWall en 2007. Le code HTML est pour l’époque particulièrement propre, mais il mélange cependant la structure et la présentation.
<ul id="menu">
<li><a href="#" class="home">Home <span></span></a></li>
<li><a href="#" class="about">About <span></span></a></li>
<li><a href="#" class="rss">RSS <span></span></a></li>
</ul>

Vous voyez ces <span> vides ? Dégoûtants, hein ? Mais avant CSS3, on était obligé d’ajouter du contenu supplémentaire (souvent vide de contenu et vide de sens) pour parvenir à reproduire une charte graphique avec un code un minimum propre. Si vous vouliez réutiliser du code de présentation, vous étiez obligé d’en reproduire la structure.

Maintenant, faisons un saut juste 2 ans plus tard, avec ce tutoriel pour faire des boutons super géniaux en CSS3 publié chez Zurb en 2009. Ce tutoriel ne contient plus que du code CSS. Plus besoin d’une structure imposée. Reprenez les styles de boutons créés, et appliquez les sur n’importe quel contenu, n’importe quelle balise, n’importe quelle structure.

Les nouveaux langages du web nous donnent donc plus de pouvoir pour plus facilement distinguer HTML, CSS et Javascript. Mais comme le disait Spider-Man (ou Voltaire, au choix) : « De grands pouvoirs impliquent de grandes responsabilités ».

On peut utiliser CSS et la pseudo classe :hover pour gérer l’affichage d’un sous-menu. Mais est-ce vraiment la bonne méthode ? Ne s’agit-il pas plutôt là d’un comportement ? Comme je le disais il y a 2 semaines : « Juste parce que vous pouvez le faire ne signifie par que vous devez le faire« . C’est notre responsabilité d’auteur du web de faire bon usage des nouvelles fonctionnalités du web. A moins que ce ne soit Halloween, la séparation de la structure, présentation et du comportement devrait être de plus en plus nette.

Hier, j’ai appris via Nofrag que Michel Hazanavicius, le réalisateur de The Artist était aussi le réalisateur de La Classe Américaine, un de mes films préférés. J’ai aussi appris qu’il est un fervent défenseur de la HADOPI. Monde de merde.

En parlant d’Apple, le week-end dernier, le New York Times a publié un excellent article sur Apple, et comment les Etats-Unis sont passé à côté de la production de l’iPhone.

Les cadres d’Apple disent qu’à ce stade, aller outre-pacifique est leur seule option. Un ancien cadre décrit comment la société comptait sur une usine chinoise pour réorganiser la fabrication de l’iPhone seulement quelques semaines avant que l’appareil ne sorte. Apple avait reconçu l’écran de l’iPhone à la dernière minute, obligeant un remaniement de la chaîne de production. Les nouveaux écrans ont commencé à arriver à l’usine aux alentours de minuit.

Un chef d’équipe a immédiatement réveillé 8000 ouvriers à l’intérieur des dortoirs de la société, d’après le cadre. Chaque employé s’est vu offrir un biscuit et une tasse de thé, puis a été guidé vers une station de travail, et en moins d’une demi heure commença une garde de douze heures passée à installer des écrans en verre dans des cadres biseautés. En 96 heures, l’usine produisait plus de 10 000 iPhones par jour.

« La vitesse et la flexibilité sont à couper le souffle », déclara le cadre. « Aucune usine Américaine ne peut rivaliser avec ça. »

La semaine dernière, je découvrais également avec stupéfaction à quel point Apple prenait sérieusement son rôle dans son partenariat avec des usines chinoises :

Nous exigeons de nos fournisseurs qu’ils renvoient les travailleurs mineurs à l’école et qu’ils paient pour leurs dépenses scolaires, leurs allocations de vie, et les salaires perdus pendant 6 mois ou jusqu’à ce que le travailleur atteigne l’âge de 16 ans, en prenant la période la plus longue. Nous nous assurons également que les étudiants ont le soutien dont ils ont besoin pour réussir à l’école. Nous aidons les étudiants à contacter leurs familles, à identifier leurs possibilités d’études, et à s’inscrire à l’école – et nous suivons leurs progrès. Si des travailleurs mineurs ont déjà quitté l’usine, nous essayons de les localiser et de leur offrir le même soutien dans leur éducation.

« Apple c’est le mal ».