Les articles du mois de février 2012

Le format PSD

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.

Estimer un temps de développement, c’est difficile

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 et le futur des interfaces de développement

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).

Un éditeur de jeux

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.

Un éditeur d'algorithme

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.

 

Un exemple de mauvais design

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 » :

Le pistolet à air comprimé Feinwerkbau P11 Piccolo

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.

"Boom headshot !"

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.

Google rachète Motorola Mobility

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 ».