Les articles du mois de mars 2012

Il y a quelques années, j’avais regardé une conférence de Jason Fried (le fondateur de 37signals) où il présentait sa vision et ses méthodes de travail. J’avais particulièrement aimé sa comparaison entre le travail et le sommeil (à partir de 8’40 dans la vidéo).

Vous pouvez comparez ça à du sommeil paradoxal (« en état MOR »). Quand vous dormez, votre sommeil n’est pas productif jusqu’à ce que vous soyez en sommeil paradoxal. C’est là où la magie du sommeil se passe vraiment. Et ça prends du temps pour arriver en sommeil paradoxal. Vous ne pouvez pas allez vous coucher et arriver au sommeil paradoxal immédiatement. Il vous faut au moins une demi heure ou plus pour y arriver. Et là, si quelqu’un vous réveille, ou s’il y a du bruit, ou quoi que ce soit, vous sortez du sommeil paradoxal. Et pour y revenir, vous ne pouvez pas reprendre là où vous étiez. Vous devez refaire tout le processus pour retourner en sommeil paradoxal à nouveau. Donc même si vous passez une nuit de 8 heures, vous n’avez pas vraiment dormi pendant 8 heures. Vous avez seulement eu quelques heures de sommeil paradoxal. Nous trouvons que le sommeil paradoxal est une bonne comparaison au travail.

On aime bien l’idée que le travail est comme le sommeil dans la mesure où ça prends du temps pour se mettre dans le flot de quoi que ce soit que vous soyez en train de faire. Vous ne pouvez pas vous pointer pas au travail et être productif immédiatement. Et personne ici ne travaille réellement 8 heures par jour. On va être présent au travail 8 heures par jour, on va être assis à notre bureau 8 heures par jour, mais on n’est pas réellement productif 8 heures par jour. Si vous avez quelques heures de bon travail dans une journée, alors c’est une bonne journée. Et ça prends du temps pour arriver à cet état, pour être en effet productif et faire du bon boulot. Et c’est ce qu’on appelle du  « travail paradoxal ».

A chaque fois que quelqu’un vous touche l’épaule, il vous sort du travail paradoxal et il vous faut du temps pour revenir à cet état.

Je pense que c’est l’une des raisons qui poussent de nombreux développeurs, souvent malgré eux, à préférer travailler le soir ou le week-end. Au travail, la plupart des chefs de projets ou des clients n’hésitent pas à vous appeler ou à venir vous voir dès qu’ils ont la moindre interrogation. C’est chouette de pouvoir apporter une réponse dans l’immédiat. Mais il est rare qu’une question nécessite réellement une réponse immédiate. Très souvent, un mail répondu dans la demi-journée aurait largement pu suffire. Une interruption, même de quelques minutes, coûte en réalité bien plus en productivité.

Hier j’ai lu un article formidable chez Aentan qui parle de surréflexion :

Avez vous vu le film de Bollywood « 3 Idiots » ? C’est le film le plus rentable de tous les temps en Inde qui raconte les aventures de 3 ingénieurs étudiants à la fac. Une des scènes m’a particulièrement marqué.

– Dans l’espace, les stylos à encre ne peuvent pas être utilisés. Donc après des millions de dollars de dépenses, les scientifiques ont inventé ce stylo ! Grâce à lui vous pouvez écrire sous n’importe quelle angle, sous n’importe quelles températures, sans gravité. 

– Monsieur, pourquoi les astronautes n’ont pas essayé un crayon dans l’espace ? 

Le reste de l’article est tout aussi génial avec un exemple de puzzle qu’on trouve sur Facebook, ou comment couper une pizza en 11 parts égales.

La surréflexion est une vraie plaie en intégration. Si vous passez trop de temps à réfléchir à un problème, à la façon d’intégrer une maquette, vous finirez bien souvent par apporter une solution démesurée.

Pour une page donnée, vous pourrez trouver des milliers de façons différentes de l’intégrer. Bien sûr dans le tas il y aura des milliers de mauvaises façons de l’intégrer. Mais il n’y aura jamais une seule bonne façon d’intégrer une page. Chaque choix réalisé lors d’une intégration, que ce soit dans l’utilisation de vos balises sémantiques, dans les styles choisis pour réaliser une mise en page, ou dans la façon de coder des interactions en JavaScript, aura un impact sur le résultat final dans des directions différentes. Vous pouvez créer une page dont le poids est parfaitement optimisé, mais plus difficile à maintenir. Vous pouvez créer une page en urgence dans un temps très court, mais elle ne sera peut être pas très optimisée. Ces deux versions peuvent être toute aussi bonne, selon les critères requis pour cette page en particulier.

Si vous passez trop de temps à surréflechir le moindre de ces choix, vous ferez du sur place.

Il y a 6 mois, je partageais ma vision d’Adobe et de Flash en la résumant en une phrase :

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

Depuis, Adobe a annoncé l’arrêt de Flash sur mobiles et son repositionnement de Flash pour de la vidéo et du jeu premium. Et on a vu arriver pour la première fois des démos de jeux impressionantes, comme Epic Citadel ou Tail Drift. Mais hier, Adobe a provoqué la colère de toute sa communauté en annonçant une taxe dédiée aux développeurs de jeux en Flash.

Les fonctionnalités premium sont disponibles sans redevance et sans restriction jusqu’au 31 juillet 2012. A partir du 1er août, les fonctionnalités premium nécessiteront une license d’Adobe. Les applications qui gagnent moins de 50 000$ de chiffre d’affaires resteront libre de toute redevance, tout comme l’utilisation des fonctionnalités premium livrées avec Adobe AIR, y compris pour les applications mobiles pour iOS et Android.

Il n’y a aucun frais pour utiliser les fonctionnalités premium des applications qui génère moins de 50 000$ de chiffre d’affaires. Pour chaque application qui génère plus de 50 000$, les frais pour utiliser les fonctionnalités premium seront de 9% du chiffre d’affaires net de l’application au dessus de 50 000$. Le chiffre d’affaires net est calculé après déduction des taxes, des coûts de traitement des frais, et des frais des plate-formes sociales.

Il est courant pour les développeurs de laisser une part de leurs revenus à la plate-forme qui les diffuse. Apple prends 30% des ventes sur l’App Store. Google prends 5% des ventes sur le Chrome Web Store. Mais c’est en échange d’un service d’hébergement, de diffusion et à moindre échelle de promotion des applications que vous soumettez. Avec la nouvelle taxe d’Adobe, vous n’avez rien de plus en échange. Autrement dit : bien que vous ayez payé Adobe des milliers d’euros en license pour utiliser leurs outils de développement Flash, vous devrez vous acquitter de 9% de vos revenus au delà de 37 000€ pour continuer à utiliser Flash.

Néanmoins, ce cap financier n’est clairement pas atteint par la plupart des jeux Flash. Et surtout, les fonctionnalités premium en question concernent uniquement l’utilisation conjointe de deux API (ApplicationDomain.domainMemory et Stage3D.request3DContext), dédiées à l’optimisation de la mémoire et à l’accélération graphique matérielle. Pourtant, cette annonce sonne vraiment comme un geste audacieux de la part d’Adobe, qui a construit son patrimoine dans le domaine du jeu grâce à des petits développeurs indépendants.

J’ai toujours du mal à voir où va Adobe en souhaitant se concentrer sur du jeu vidéo « premium », digne de consoles de salon. L’immense succès des jeux Flash s’est construit grâce à des milliers de développeurs indépendant qui ont créé des jeux simples, et attractifs pour le grand public. En visant du jeu haut de gamme, Adobe cible un public de joueurs avertis. Et dans ce domaine, ils ne sont pas en concurrence avec des organismes de standards du web, mais avec des sociétés spécialisées dans le jeu vidéo comme Nintendo, Sony et Microsoft. Adobe s’est par exemple associé à Epic et Unity pour porter leurs moteurs 3D respectifs sous Flash Player. Mais ces moteurs fonctionnent déjà sur les autres plates-formes (iOS, Android, PC, Mac, ou même via un plugin web pour Unity). J’ai un tout petit peu de mal à voir pourquoi un développeur choisirait de passer par Adobe pour porter un jeu sur le web aujour’hui.

Hier, Mozilla a lancé BrowserQuest, une démo technique sous forme de mini-jeu massivement multijoueurs tout en HTML5. C’est une petite aventure toute simple (comptez une vingtaine de minutes pour tout explorer), mais ça fourmille de détails et de références cachées. Mais c’est surtout très bien réalisé.

Le jeu a été développé par les français de Little Workshop, et a déjà accueilli plus de 150 000 joueurs en moins de 24 heures (vous pouvez suivre le nombre de connectés en temps réel ici). Il utilise pleins de joyeusetés (Canvas, WebWorkers, localStorage, Media Queries, HTML5 Audio). Et c’est censé tourner sur n’importe quel navigateur moderne sur n’importe quelle plate-forme. Oh, et vous pouvez récupérer tout le code source du jeu librement.

En jouant à BrowserQuest, je n’ai pas pu arrêter de m’empêcher de penser que ce que j’avais là, sous mes yeux, était important. En y réfléchissant, je pense que c’est important à deux niveaux.

C’est important pour Mozilla, parce que de mémoire, c’est leur première démo HTML5 qui s’adresse au grand public. Google a compris ça il y a déjà un an en proposant des clips interactifs comme 3 Dreams Of Black, ou plus récemment avec Angry Birds. Microsoft a compris ça également en portant Cut The Rope en HTML5. Mozilla a sorti le grand jeu avec BrowserQuest (sans mauvais jeu de mot), et c’est une très belle démonstration pour prêcher par l’exemple.

Mais c’est aussi important pour le web. BrowserQuest n’est pas une démonstration des capacités de Firefox. C’est une démonstration des capacités du web, en tant que plate-forme, avec ses langages. Peu importe votre ordinateur, votre tablette, votre téléphone, votre écran, votre système d’exploitation, votre navigateur, vous pouvez en profiter dès maintenant.

Et ça, ça change tout.

J’aime bien les histoires de bugs. TheDailyWTF est une mine d’or pour ça, mais j’aime beaucoup entendre de vive voix des développeurs raconter leurs propres expériences. Voici l’histoire d’un bug que j’ai rencontré il y a quelques mois. C’est le genre de bug qui une fois résolu, donne l’impression d’être David Caruso dans Les Experts : Miami, et donne envie d’enfiler une paire de lunettes de soleils en criant YEEAAAAHH à travers tout le bureau.

Quelques jours après le lancement d’un nouveau site e-commerce, le client me transfère le mail d’un de ses collègues qui rencontre un problème sur Internet Explorer. Sur la fiche produit, lorsqu’on ajoute un produit à son panier, la « div » qui s’affiche via une lightbox est coupée sur la droite.

Bizarre. Tout a bien été testé avant le lancement du site. Et même sur IE6, qui n’est pas censé être supporté, tout s’affiche correctement. Au risque de faire un peu cliché, je rassure le client en lui disant que « chez moi ça marche ». Je lui demande un peu plus de précisions sur la version d’Internet Explorer et le système d’exploitation utilisés, car sa capture d’écran envoyée ne laissait entrevoir que le contenu de la page qui posait problème.

D’après le client, le problème se produit bien sur IE8. Ça ne le fait pas sur son poste, mais il l’a bien vu sur le poste de son collègue. Et pire, sur le poste d’un autre collègue, sous IE7, l’overlay de la div s’affiche au-dessus de tout le contenu du site et de la div elle-même. Et le service de la relation client téléphonique confirme également avoir reçu des appels de clientes perdues devant leur ordinateur à cause de ce problème.

Mince alors ! On a pourtant bien testé le site dans tous les sens, sur les différents postes de la boîte sous différentes configurations. De mon côté, j’utilisais une machine Virtuelle sous Windows 7 avec IE9 d’installé. J’utilisais le « Mode de compatibilité » d’IE pour tester le rendu du site sous les différentes versions d’IE. Je sais que ce mode n’est pas 100% fidèle aux vraies versions du navigateur, mais pour ce genre de problème qui touche surtout à des styles, ça fonctionne d’habitude très bien.

Les jours ont passé et je ne vois pas trop comment trouver une solution. Je propose au client d’y jeter un oeil la prochaine fois que je leur rendrais visite dans leurs locaux. Mais c’est embêtant… Plusieurs personnes rencontrent ce bug, de manière systématique, et pas moi.

Tracassé, je décide le week-end qui suit de ressortir un vieux PC chez moi sur lequel je sais que j’ai un IE7 d’origine installé sous Windows XP. Je commence par tester sur le serveur de test du site. Rien. Je teste en ligne. Et là, miracle ! J’arrive à reproduire le problème ! C’est drôle comme la reproduction d’un bug peut être une grande satisfaction pour un développeur.

C’est l’heure de sortir ma loupe de détective et enfin de pouvoir commencer mon enquête. Sur le site en ligne, je remarque que j’ai des règles de styles supplémentaires qui apparaissent. Ces règles proviennent… de la page d’erreur 404 du site.

Après inspection des ressources appelées par la page sur IE, je me rends compte que le site fait appel à un fichier « ie.css ». C’est surement une petite délicatesse mise à ma disposition par le développeur du site. Sauf que, ne m’ayant rien dit, et n’ayant pas l’utilité d’un tel fichier, je n’avais pas créé le dit fichier sur le serveur. Du coup, la page du site faisait appel à une CSS qui renvoyait en fait la page 404 du site. Or, sur les anciennes versions d’IE, les styles présents dans une page 404 étaient interprétés dans la page courante. Les styles de la page 404 rentraient donc en conflit avec ceux de la fiche produit. Ce bug, présent sur IE7 sous Windows XP SP1, avait été corrigé dans les versions suivantes sous Windows XP SP2. Il n’apparaissait pas dans le mode de compatibilité d’IE7 sous IE9 car il s’agit d’un problème lié au chargement des ressources d’IE, et non à son moteur de rendu. Et le bug n’était pas présent sur le serveur de test, car sur ce serveur la page 404 appelée était celle par défaut du serveur et ne contenait aucun style.

Il ne me restais alors plus qu’à créer ce fichier, et passer le tout en ligne. L’affaire était résolue, et je pouvais désormais crier de joie à travers tout le bureau.