HTeuMeuLeu

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.

Lu chez plasmasturm, repris lui même d’ailleurs : Les 6 étapes du débogage.

1. Ça ne peut pas arriver.
2. Chez moi ça marche.
3. Ça ne devrait pas arriver.
4. Pourquoi est-ce que ça arrive ?
5. Oh, je vois.
6. Comment est-ce que ça a pu marcher ?

S’il y a un livre qui a profondément changé ma compréhension du monde et la façon dont je conçois des sites Internet, c’est très certainement « The Design of Everyday Things » de Donald Norman. Le livre traite de la conception des objets de la vie de tous les jours, d’ergonomie et de facilité d’utilisation, avec pleins d’anecdotes et d’exemples comme je les aime. Dans les premiers chapitres du livre, l’auteur prends l’exemple des portes. Cet exemple est devenu tellement célèbre qu’il est désormais courant de désigner une porte mal conçue comme une « porte de Norman ».

Quand nous approchons une porte, nous devons trouver le côté qui s’ouvre et l’endroit à manipuler. En d’autres termes, nous devons arriver à comprendre ce que l’on doit faire et où le faire. Nous nous attendons à trouver un signal visible pour réaliser la bonne manipulation : une plaque, une prolongation, un creux, un renfoncement – quelque chose qui permette à la main de toucher, saisir, tourner ou s’insérer. Ceci nous dit où agir. L’étape suivante est de comprendre comment : nous devons déterminer quelles opérations sont permises, en partie en se basant sur l’affordance, en partie guidés par les contraintes.

Il y a une variété incroyable de portes. Certaines ne s’ouvrent que si un bouton est appuyé, et certaines ne semblent pas s’ouvrir du tout, n’ayant aucun bouton, aucun matériel, ni aucun autre signe de leur fonctionnement. La porte s’ouvre peut être à l’aide d’une pédale. Ou peut être qu’elle est activée par une commande vocale, et que nous devons prononcer la phrase magique (« Sésame ouvre toi !« ). En outre, certaines portes ont des étiquettes sur elles : tirez, poussez, glissez, portez, sonnez, insérez votre carte, entrez votre mot de passe, souriez, tournez, saluez, dansez, ou peut-être juste, demandez. D’une manière ou d’une autre, quand un appareil aussi simple qu’une porte doit être utilisé avec un manuel d’utilisation – même s’il s’agit d’un manuel d’un seul mot – alors c’est un échec, mal conçu.

Je pense que c’est tout aussi valable pour le web. Si vous devez expliquer à l’internaute comment se servir de votre page, même avec une simple phrase, vous avez raté votre travail.

Que vous soyez graphiste, développeur ou chef de projets, je vous recommande vraiment très chaudement la lecture de « The Design of Everyday Things« . Le livre, bien que datant de 1988, n’a jamais été traduit en français. Mais même en étant très précis et très détaillé, il se lit relativement facilement et se divise en pleins de sections assez courtes et souvent illustrées. Et il ne coûte que 10€ chez Amazon (et si vous utilisez ce lien, vous contribuerez à mon bien être personnel).

Dans la même veine, cette galerie de photos de panneaux sur des panneaux créée par Jason Fried me fait toujours autant sourire.

Le piratage n’existe pas parce qu’il y a des mauvaises personnes ici et là qui sont des voleurs et/ou qui détestent le capitalisme et/ou se sentent dans leur droit. Bien sur, il y a des mauvaises pousses, mais ce sont les exceptions, pas la règle. Le piratage existe parce que c’est souvent un moyen plus facile d’obtenir du contenu que les moyens légaux. Et parfois, c’est le seul moyen.

MG Siegler, dans son très bon article « Winter And The Wall » (repartant du même exemple de l’offre légale inexistante pour la série Game Of Thrones, déjà brillamment illustré il y a quelques semaines chez l’excellent The Oatmeal).

Depuis un petit moment, je n’arrête pas d’entendre parler de pré-processeurs CSS, comme Sass, LESS, ou Stylus. Ces outils ajoutent de nouvelles fonctionnalités à vos CSS (comme des variables, des fonctions ou des snippets) en générant votre code côté serveur. Parfois ça donne un peu envie, mais la plupart du temps vraiment pas (voire pire encore).

Lea Verou résume parfaitement mes appréhensions sur ce genre d’outils :

• Les pré-processeurs faussent notre perception de la taille finale d’une feuille de style, et ça peut être difficile d’optimiser correctement le tout
• Les pré-processeurs rendent plus difficile la routine classique de débuggage, où les numéros de lignes visibles dans Firebug (ou équivalent) ne correspondent pas à votre CSS
• L’utilisation de pré-processeurs en équipe nécessite que toute l’équipe maîtrise l’outil
• Les fonctionnalités apportées par les pré-processeurs finiront par arriver dans les spécifications officielles de CSS (c’est déjà le cas pour les variables). Comme le dit Lea, « coder pour un pré-processeur CSS aujourd’hui c’est un peu comme construire un chateau de sable ».

Ceci dit, je n’ai jamais utilisé de pré-processeur CSS. Il est donc possible qu’avec certains d’entre eux, mes craintes ne soient pas justifiées. Pour autant, j’ai énormément de mal à me pencher sur ce sujet et m’y intéresser réellement. Peut-être parce que je suis un vieil intégrateur. Mais peut être aussi parce que j’ai tendance à préférer les choses simples.

Il y a quelques mois, j’étais tombé sur « The MicroPHP Manifesto« , un excellent article dans lequel un développeur PHP revendique son amour pour coder en PHP, sans frameworks. La comparaison donnée dans son introduction est pile poil comme je les aime :

La ligne standard de l’histoire du Punk est qu’il s’agissait d’une réaction aux excès du rock moderne, en particulier le rock progressif de l’époque. La réalité est indéniablement plus compliquée, mais je suspecte qu’il y a en ça une part de vérité. Le rock’n’roll semblait être dans son âge d’or à la fin des années 60s et 70s, inaccessible pour le grand public. Le contraste entre des groupes comme Rush et Black Flag, tous les deux supposés jouer du « rock », était extrême.

Pour rigoler, regardons la batterie du batteur de Rush Neil Peart :

Et maintenant, voici les Black Flag en train de jouer à Los Angeles en 1979 :

Vous pouvez faire tenir la totalité de Black Flag dans l’espace de la batterie de Neil Peart. Et ils joueraient quand même de manière impressionante et déchireraient tout.

Cet exemple colle parfaitement à l’utilisation de pré-processeurs en CSS. Dans l’absolu, CSS est un langage simple à utiliser. Vous n’avez pas besoin d’un compilateur. Vous n’avez pas besoin d’un éditeur particulier. Vous pouvez aller sur n’importe quel ordinateur, coder dans le bloc-notes, et faire des sites « qui déchirent ». Pour moi, une CSS doit être agnostique de tout éditeur et de tout autre langage.

Le manifeste du micro PHP cité ci-dessus s’applique alors parfaitement ici. Et si je devais résumer ma pensée en une phrase, je détournerais le fameux dicton pour donner le manifeste du CSS pur et dur suivant :

Ce qui se passe en CSS, reste en CSS.

Je déteste l’expression « surfer sur Internet ». Je ne surfe pas. Je suis assis comme un gros porc au fond de ma chaise en train de fixer un écran d’ordinateur. Je n’ai jamais fait de surf, mais je pense que ça n’a pas grand chose à voir. J’ai toujours imaginé que le terme venait d’un fournisseur d’accès ou d’une grosse boîte de com’ des années 90 qui a voulu rendre le web super cool. Mais sur le web français, les réponses sont plutôt évasives quand on cherche d’où vient l’expression. Voici par exemple l’explication de Wikipedia :

L’expression surfer sur le Web signifie « consulter le Web ». Elle a été inventée pour mettre l’accent sur le fait que consulter le Web consiste à suivre de nombreux hyperliens de page en page.

Okay. Il va falloir m’expliquer le rapport entre suivre des liens de pages en pages et des grands blonds musclés qui glissent sur des grandes vagues en Californie.

Heureusement, une petite recherche en anglais nous amène droit à la réponse. La première personne associée à l’utilisation de cette expression est Jean Armour Polly, une bibliothécaire et auteur américaine. En juin 1992, elle publie dans le bulletin de la bibliothèque de l’Université du Minnesota un article intitulé « Surfing the internet« . Sur son site personnel, elle raconte comment lui est venue l’idée de cette expression.

J’étais sous contrat avec le Wilson Library Bulletin pour écrire un article adressé aux débutants à propos d’Internet, à soumettre au journal en mars 1992. L’article a été imprimé dans l’édition de juin 1992.

En écrivant cet article, je savais que ce serait un des premiers du genre. « Zen and the Art of the Internet » était publié sur le net par Brendan Kehoe en janvier 1992, et c’était devenu un phénomène du net à petite échelle. Jusque-là il n’y avait que des RFCs (Requests for Comments) et d’autres écrits techniques à propos d’Internet. L’article de Kehoe innova pour les nouveaux utilisateurs universitaires, et j’étais décidée à faire la même chose pour les bibliothécaires.

En cherchant un titre pour l’article, j’évaluais plein de métaphores possibles. Je voulais quelque chose qui exprimait le plaisir que j’avais à aller sur Internet, tout en évoquant la compétence et l’endurance nécessaire pour bien l’utiliser. J’avais aussi besoin de quelque chose qui évoque un sens de l’aléatoire, du chaos et même du danger. Je voulais quelque chose qui fasse mouche, qui fasse mordre à l’hameçon, quelque chose de nautique.

A cette époque j’utilisais un tapis de souris de la bibliothèque d’Apple à Cupertino, en Californie, célèbre pour inventer et s’approprier des expressions savoureuses et les faire imprimer sur des survêtements et des tapis de souris (par exemple, « Un mois au laboratoire peut vous éviter une heure à la bibliothèque »). Celui que j’avais présentais un surfeur sur une grande vague. « Surfeur de l’information », ça disait. « Eureka », me suis-je dis. Et j’avais ma métaphore.

Quand je pense à l’état actuel du web, j’ai le sentiment qu’on est entré dans la 3ème génération d’intégrateurs. Chaque génération a été marquée par sa guerre entre navigateurs, ses outils de développement, et ses bonnes et mauvaises pratiques.

La première génération était la génération Netscape/Internet Explorer, du milieu des années 1990 jusque l’an 2000. Netscape était le navigateur dominant, mais s’est rapidement fait rattraper par Internet Explorer. La connexion à Internet se faisait en général en 56k. Les sites étaient principalement codés à l’aide d’éditeurs WYSIWYG, comme Microsoft Frontpage ou Macromedia Dreamweaver. Les mises en page de sites se faisaient à l’aide de tableaux, de frames, et les pages étaient remplies d’images « spacer.gif » ou de gifs animés. C’étaient les débuts d’Internet, et la première préoccupation d’un intégrateur était de mettre une page web en ligne.

La seconde génération était la génération Firefox, de 2001 jusque la fin de la décennie. Internet Explorer était le navigateur dominant, mais s’est rapidement fait grignoter par Firefox. La connexion à Internet se faisait en général par ADSL. Les sites étaient principalement codés à l’aide de gros IDE spécifiques à un langage de développement, comme Visual Studio. Les mises en page de sites se faisaient à l’aide de CSS, de float, et les pages étaient remplies de div et de Flash. La première préoccupation d’un intégrateur était de respecter le design réalisé par un graphiste.

La troisième génération est la génération WebKit, qui a débuté un peu avant 2010. Il n’y a plus vraiment de navigateur dominant, mais le moteur de rendu WebKit (utilisé dans Chrome, Safari) est largement majoritaire. La connexion à Internet se fait désormais principalement sur mobile, en Edge ou 3G. Les sites sont codés à l’aide d’éditeurs de code aux interfaces plus minimalistes, comme Textmate, SublimeText ou Notepad++. Les mises en page de sites se font à l’aide de CSS3, de media queries, et les feuilles de styles sont remplies de préfixes navigateurs. La première préoccupation d’un intégrateur est de rendre son site visible partout, peu importe le navigateur, la taille de l’écran et le type d’appareil utilisé.

Cela m’amène à faire le constat suivant. Chaque génération dure entre 5 et 10 ans. Et chaque génération a vu apparaître des méthodes de travail radicalement différentes avec des problématiques totalement différentes. J’ai toujours un léger rictus quand je vois des agences web ou des intégrateurs se vanter d’avoir « 15 ou 20 ans d’expérience », car en réalité, vous avez seulement l’expérience depuis le début de la génération en cours. Et pire, si vous avez de l’expérience mais que vous ne vous remettez pas en question, vous risquez de traîner d’anciennes pratiques désormais devenues obsolètes voire néfastes.

Si je pense qu’il n’est plus possible aujourd’hui de maîtriser toutes les facettes de l’intégration, je pense aussi qu’il est très important pour un intégrateur de continuellement se remettre en question. Les bonnes pratiques d’aujourd’hui seront les mauvaises pratiques de demain.

Et quand des clients me demandent si je crains la concurrence d’autres agences ou d’agences low-cost, je réponds par la négative. Ma plus grosse crainte, c’est moi même. La peur que je n’arrive pas à me renouveler. Et pire : la peur que je ne me rende même pas compte qu’il faille que je me renouvelle.

La semaine dernière s’est déroulée à Austin au Texas la SXSW (South by Southwest), un des plus grands festivals de musique, films et médias interactifs. C’est un des rendez-vous les plus importants pour le web, où les plus grands acteurs donnent des conférences sur tous les sujets du moment. Google était donc présent, et a donné pendant près de 3 heures une série de mini-conférences sur Android, Google+ et le web. Paul Irish, développeur dans l’équipe de Chrome, a présenté pendant 20 minutes les « trucs vraiment nouveaux nouveaux tout chaud » en HTML5. Si vous avez un peu de temps et que vous voulez rester à la page, cette vidéo est faite pour vous ! (la présentation de Paul Irish débute à 1h51)

Voici l’ensemble des sujets abordés, avec les liens vers les démos présentées :

• Les régions et exclusions CSS (article, démo), pour créer des mises en pages avancées comme dans des magazines
• Les filtres CSS (démo), pour appliquer des effets (flou, luminosité, contraste, …) sur n’importe quel élément d’une page
• La propriété navigator.connection, pour connaître le type de connexion de l’internaute
• L’API FullScreen (démo), pour afficher n’importe quel contenu d’une page en plein écran
• L’API Pointer Lock (démo), pour contraindre le curseur de la souris à rester dans une zone précise (idéal pour les jeux)
• L’API GamePad (démo), pour utiliser une manette de jeu
• L’API Page Visibility (démo), pour savoir si une page web est affichée ou en arrière-plan
• La fonction requestAnimationFrame (article, démo), pour créer des animations en utilisant efficacement le processeur de la machine
• La fonction getUserMedia (démo Photobooth, démo Webcam Toy, démo explosion), pour utiliser la webcam et le micro de l’internaute
• WebRTC, pour créer du chat audio/vidéo en temps réel

 

Le nouvel iPad est sorti, et les premiers tests de journalistes professionnels apparaissent.

Toujours pas de support d’Adobe Flash.
— Edward C. Baig, USA Today

Dommage… […] l’iPad nouvelle formule ne sait toujours pas lire les vidéos en Flash.
— Didier Sanz, Le Figaro

Au-delà des défauts habituels des produits mobiles Apple comme le manque d’ouverture ou l’absence de compatibilité avec flash, les défauts du nouvel iPad reste pour la plupart déjà connu.
— Florent Deligia, Lyon Capitale

Dans la liste des autres technologies mortes que le nouvel iPad ne supporte toujours pas : les disquettes 3,5″, les cassettes audio, les CD audio, les DVD, …

Quelle déception.

Après le lancement l’année dernière du site IE6Countdown, Microsoft lance une nouvelle campagne pour rappeler qu’IE9 n’est pas si mal comparé à ses prédécesseurs avec le blog Tumblr « The Browser You Loved To Hate » et la vidéo ci-dessous.

La seule et unique chose pour laquelle IE est bon, c’est pour télécharger d’autres navigateurs.

Je suis peut être inculte et naïf, mais est-ce qu’il y a déjà eu une société, peu importe le domaine, qui a investi autant d’argent pour autant discréditer et dévaloriser ses anciens produits ?

Pour autant, ça reste une meilleure campagne que la pizza IE8, toujours en vente 3 ans après la sortie du navigateur.

Il y a un an, Google annonçait de manière fracassante l’abandon du codec vidéo H.264 (format propriétaire et soumis à des droits de license d’utilisation) au profit d’un nouveau codec, WebM. C’était une grande nouvelle pour Mozilla, ayant toujours refusé de supporter le codec H.264. Mike Shaver (anciennement grand défenseur de l’open web chez Mozilla, qu’il a quitté l’année dernière pour rejoindre Facebook (sic !)) écrivait l’année dernière :

Des organisations comme Google, Mozilla, Opera et les autres qui croient réellement en l’importance de la vidéo ouverte sur le web investissent dans notre philosophie pour leurs produits, et le web va être encore plus fort et encore plus génial grâce à ça.

Félicitations et merci, Google.

L’annonce de Google est vite tombée en désuétude, et la société n’a pas fait grand chose pour pousser le support du format WebM. Mozilla se retrouve alors seul dans son combat pour l’open web. Et les discussions pour supporter le format H.264 dans Firefox sont réapparues cette semaine. Andreas Gal de chez Mozilla écrit alors :

Google a promis beaucoup de choses et n’ont pas suivi, et nos utilisateurs et nos projets en payent le prix. H.264 ne va pas disparaître. Tenir le coup un peu plus longtemps ne va strictement rien nous apporter.

La première motivation de Mozilla, c’est de supporter H.264 pour leur OS mobile, Boot to Gecko. Comme l’écrit MG Siegler, sans support de H.264, « Boot to Gecko serait un véritable faux départ ». Le support de H.264 serait alors étendu aux versions mobiles de Firefox, puis aux versions bureau pour les OS supportant nativement H.264. L’article d’Arstechnica détaille très bien tout le schmilblick.

Cette actualité me rappelle à quel point les avancées du web doivent être supportées par de grandes sociétés. Ces dernières années, Apple a pesé lourd dans la balance contre Flash. Google aurait pu peser lourd dans la balance contre H.264, mais ils en ont décidé autrement.

 

Christian Heilmann, développeur évangéliste chez Mozilla, explique pourquoi « HTML5 n’est pas prêt, ne le sera jamais, et c’est une bonne chose » :

HTML est désormais un standard vivant. Ça dérange l’esprit de beaucoup de personnes : comment un standard peut-il être vivant ? Et bien, pour moi, ça a beaucoup de sens. Les besoins du web sont constamment en train de changer. Il y a quelques années personne n’aurait prédit – et encore moins les groupes de standards – que nous utiliserions internet sur des appareils mobiles avec des interfaces tactiles. Que va-t-il se passer dans le futur proche ? Qui sait ? De la reconnaissance faciale et de la détection de mouvements ?

HTML5 est définit par les fabricants de navigateurs qui bricolent et innovent et enrichissent les standards. Puis les autres fabricants de navigateurs viennent en discuter et nous nous accordons pour en faire un standard. Cela évite le problème pour des développeurs d’avoir à construire des choses pour des navigateurs et ça signifie que le standard ne sera pas à la traîne. Le principal pouvoir d’internet est que vous n’avez pas à écrire la même application plusieurs fois pour différents environnements, et en s’accordant entre fabricants de navigateurs nous nous assurons qu’il n’y aura pas de nouvelle situation à la IE6.

Donc non, HTML5 n’est pas prêt et ne le sera jamais – et c’est une bonne chose. Nous avons un standard pour le web avec tout ses changements et adaptations, et pas un standard logiciel qui s’attends à un renouvellement tous les 5 ans.

Je suis d’accord avec le fond de l’article. Par contre, j’ai l’impression qu’il présente les fabricants de navigateurs et les groupes de standards de manière un peu trop idéaliste. Il y a tout juste un mois, tous les fabricants de navigateurs étaient d’accords pour commencer à faire du grand n’importe quoi, quitte à ce qu’on se retrouve justement dans « une nouvelle situation à la IE6 ».

Faire de HTML un standard vivant est une très bonne chose. Mais j’ai comme des doutes sur la capacité des groupes de standards actuels à en faire une bonne chose sur le long terme.

Quand on parle de navigateurs, on parle surtout des cinq suspects habituels : Internet Explorer, Firefox, Chrome, Safari et Opera. A eux seuls, ces cinq navigateurs représentent près de 99% de parts de marché. Mais j’ai toujours été fasciné par la quantité, la diversité et la spécificité des navigateurs restants.

Mais surtout, j’ai toujours adoré les logos des navigateurs. Mis côte à côte dans le dock de Mac OS ou sur le bureau de Windows, ça me rappelle mon enfance, ma collection de pin’s, mon classeur de Pogs ou encore ma collection de Pokémons. En voici une petite sélection d’après la liste des navigateurs sur Wikipédia.

 

Il n’y a pas très longtemps j’ai découvert Neil DeGrasse Tyson, astrophysicien et directeur du planétarium du Musée d’Histoire Naturelles de New York (et également devenu le meme « Watch out guys, we’re dealing with a badass over here » malgré lui).

J’ai découvert cette vidéo la semaine dernière, magnifiquement mise en scène sur une chanson de The Cinematic Orchestra, et je suis resté bouche bée. Interrogé par un lecteur du Time Magazine, il réponds à la question suivante : « Quel est le fait le plus ahurissant que vous puissiez partager avec nous à propos de l’Univers ? »

Le fait le plus ahurissant… c’est de savoir que les atomes qui composent la vie sur Terre, les atomes qui forment le corps humain sont traçables jusqu’aux creusets qui ont cuisiné des éléments de lumière en éléments denses dans leurs noyaux, sous des températures et des pressions extrêmes.

Ces étoiles, les plus lourdes d’entre elles, sont devenues instables dans leurs vieilles années. Elles se sont écroulées puis ont explosé, dispersant leurs intestins enrichis à travers la galaxie. Des intestins faits de carbone, de nitrogène, d’oxygène, et tous les ingrédients fondamentaux de la vie en elle-même. Ces ingrédients sont devenus une partie de nuages de gaz, qui se sont condensés, écroulés, et ont formé la génération suivante de système solaires : des étoiles avec des planètes en orbites. Et ces planètes ont maintenant les ingrédients de la vie elle-même.

Donc je lève les yeux au ciel la nuit… et je sais que oui, nous faisons partis de cet univers, nous sommes dans cet univers… Mais peut être que plus important que ces deux points, c’est que l’Univers est en nous. Quand je pense à ça, je regarde en haut… Beaucoup de gens se sentent petits parce qu’ils sont petits et que l’Univers est grand… mais je me sens grand, parce que mes atomes viennent de ces étoiles.

Il y a un niveau de connectivité. C’est vraiment ce que vous recherchez dans la vie, vous voulez vous sentir connectés, vous voulez vous sentir appropriés. Vous voulez vous sentir comme un participant dans le déroulement des activités et événements autour de vous.

C’est exactement ce que nous sommes, juste en étant en vie.

Ça n’a strictement rien à voir avec le web. Ça n’a strictement rien à voir avec l’intégration. Mais j’ai trouvé cette vidéo profondément inspirante.

Lu hier via Hacker News, la conclusion du livre « Learn Python the hard way » de Zed A. Shaw, intitulée « Conseil d’un vieux programmeur » :

Finalement, je dirais qu’apprendre à créer des logiciels vous change et vous rend différent. Pas mieux ni pire, juste différent. Vous trouverez peut-être que les gens vous traitent durement parce que vous savez créer des logiciels, peut-être en utilisant des mots comme « nerd« . Peut-être que vous réaliserez que parce que vous pouvez disséquer leur logique ils détestent débattre avec vous. Vous trouverez peut être que le simple fait de savoir comment fonctionne un ordinateur vous rends ennuyeux et bizarre à leurs yeux.

Face à ça je n’ai qu’un seul conseil : qu’ils aillent se faire foutre. Le monde a besoin de plus de gens bizarres qui savent comment les choses fonctionnent et qui aiment tout comprendre. Quand ils vous traitent comme ça, souvenez vous juste que c’est votre voyage, pas le leur. Être différent n’est pas un crime, et les gens qui vous disent ça sont juste jaloux que vous ayez choisi une compétence qu’ils n’auraient jamais pu acquérir même dans leurs rêves les plus fous.

Vous savez coder. Pas eux. Et ça, c’est plutôt cool.

 

La semaine dernière je vous ai parlé de Richard Feynman (prix nobel de physique et joueur de bongo), en vous incitant vivement à en apprendre plus sur le personnage. Tel que je vous connais, nous n’en avez rien fait. Alors voici une petite anecdote que j’ai découverte il y a pas très longtemps sur Wikipédia.

A Princeton, le physicien Robert R. Wilson encouragea Feynman a participer au Projet Manhattan — le projet de l’U.S. Army en pleine guerre développant la bombe atomique à Los Alamos. Feynman dit qu’il avait été persuadé de rejoindre cet effort pour la construire avant que l’Allemagne Nazi ne développe sa propre bombe. […]

Dû à la nature top secrète du projet, Los Alamos était isolé. De la bouche de Feynman, « Il n’y avait rien à faire du tout là bas ». Ennuyé, il laissa libre cours à sa curiosité en apprenant à deviner les combinaisons de cadenas des armoires et des bureaux utilisés pour des documents sécurisés. Feynman joua pleins de tours à ses collègues. Dans un cas il trouva la combinaison d’une armoire de classement en essayant les numéros qu’un physicien utiliserait (ils se sont avérés être 27-18-28, d’après la base d’un logarithme naturel, e=2,71828…), et il découvrit que que les 3 armoires à classeurs où un collègue rangeait ses notes de recherche sur la bombe atomique utilisaient toutes la même combinaison. Il laissa une série de notes pour plaisanter, ce qui au départ effraya son collègue, Frederic de Hoffmann, et lui fit croire qu’un espion ou un saboteur avait réussi à gagner aux secrets de la bombe atomique.

Je pourrais utiliser ça comme un bon exemple pour parler de mot de passe et de sécurité. Mais ce qui m’a plu ici, c’est l’opposition du sérieux du projet, à l’amusement de Richard Feynman.

Les meilleurs projets sur lesquels j’ai travaillé sont ceux où je me suis le plus amusé. Que ce soit en essayant des nouvelles techniques d’intégration, ou alors en glissant des petites blagues à destination du client. Cela ne signifie pas que ces projets n’étaient pas sérieux.

Il y a quelques temps, j’avais vu une conférence chez TED dont le titre résume bien ma philosophie : Les grands designs sont sérieux (pas solennels).

La semaine dernière, j’ai vu sur Reddit cette image qui m’a fait sourire.

Je me suis toujours demandé comment fonctionnait cette animation dans iOS, se bloquant quasiment systématiquement à 90% avant de finaliser l’envoi. Magie de Reddit, le créateur de Cydia et un développeur iPhone de chez Apple sont venus apporter quelques précisions.

C’est un indicateur de progression indéterminé pour quelque chose dont ils peuvent deviner la durée mais sans avoir de suivi de sa progression. Ça fonctionne comme ça :

• Affichez la barre de chargement pendant 4 secondes (ou 6 secondes s’il y a une photo jointe).
• Si ça prends moins de 4 secondes,  remplissez rapidement le reste de la barre.
• Si ça prends plus de 4 secondes, faites une pause à 90%.

C’est le même principe utilisé par un Mac avant au moment de booter. Déterminer le temps de chargement d’un système UNIX est très lent, alors ils ont juste mesuré le temps lors du dernier démarrage et vous donnent une barre de progression sur cette durée.

Maintenant je le saurais.

 

Je pensais avoir entendu tous les arguments possibles en faveur de Flash. Mais Adobe vient de se surpasser sur son site Adobe Gaming promouvant Flash pour le jeu vidéo.

Des milliards et des milliards…

C’est ce que se font les éditeurs de jeu chaque année en choisissant la technologie Flash pour construire leurs jeux.

Mais oui ! Avec Flash vous n’allez pas gagner votre vie. Vous n’allez pas devenir millionaire. Vous allez devenir milliardaire.