Brain Cracking

Rappel : migration vers braincracking.org

Pour ceux qui n'auraient pas mis à jour leur bookmark ou leur fil RSS, je rappelle que http://jpv.typepad.com a migré vers http://braincracking.org ! Vous avez déjà loupé un article et plusieurs news :)

Le fil RSS définitif est http://feeds.feedburner.com/braincracking

A tout de suite :)

Migration vers braincracking.org

Après 9 mois d'existence, ce blog migre vers un nouveau domaine : http://braincracking.org. Au tout début je n'étais pas sur de tenir le rythme ou de trouver un vrai intérêt à faire ce blog, mais en faisant le bilan j'ai décidé de continuer :

• 145 revues de presse couvrant l'actualité du développement d'applications Web, ça commence à faire du contenu intéressant : au bout de quelques mois, je me suis rendu compte que j'utilisais beaucoup le moteur de recherche (de mon lecteur de RSS : thunderbird) pour retrouver d'anciens articles et tutoriaux, et que mes commentaires de l'époque m'aidaient en plus à retrouver rapidement la conclusion, en plus de mettre pas mal de sémantique. Si ça me sert dans mon travail quotidien, ça vous sera forcément utile aussi, et la version gratuite de typepad que j'utilisais ne permet pas de mettre un moteur de recherche
• une centaine de commentaires ont également été migrés mais je trouvais que le système typepad de commentaires était très contraignant : j'en apprend beaucoup grâce à vos commentaires et vos points de vue, en plus de l'impression rassurante de ne pas être seul au monde :) Le système de commentaires plus engageant de Wordpress devrait donc faciliter la communication.
• d'autres auteurs ? le nom de domaine jpv.typepad.com n'encourageait pas vraiment à contribuer, car ça donne l'impression de travailler pour moi. Hors ce blog n'est pas pour me promouvoir moi (je ne suis ni freelance ni en recherche de poste) mais pour remplir un vide : je ne connais pas d'autre revue de presse en français sur les thèmes que vous trouvez généralement ici : les features d'HTML5, un peu de CSS3, les performances Web et l'utilisation avancée de JavaScript. Je recherche donc d'autres commentateurs de l'actualité, ainsi que des articles originaux sur des points précis. Je recherche également quelqu'un qui pourrait traduire les articles en anglais.
• customisons : le passage sur un hébergement normal, avec un wordpress qui est une plateforme impressionante de customisation va me permettre un peu plus de liberté dans le code des démos des articles, jusqu'ici hébergées sur jsfiddle.net. Et accessoirement je vais pouvoir un peu jouer avec CSS3, chose que je ne me permet pas au travail, tout en mettant de la sémantique HTML5 et de la performance sur ce blog

L'url du fil RSS officiel restera http://feeds.feedburner.com/braincracking, si vous aviez souscrit à http://jpv.typepad.com/blog/rss.xml, mettez à jour vos lecteurs RSS :)

RPW 11/08/10: faire un fallback pour HTML5 Forms, teste l'existence d'une valeur en Javascript, serveur WebSocket en PHP, IE9 beta1 en automne

2 grosses semaines de vacances, cela fait du bien. Je n'ai pas tenu le blog à jour, mais j'ai continué à partager des liens sur Twitter et à faire ma revue de presse quotidienne. A priori je n'ai pas raté grand chose de l'actualité des applications Web pendant ces 2 dernières semaines. Il est maintenant temps de rattraper le retard sur ce blog en commentant les liens les plus importants, ce qui vu le volume se fera en plusieurs posts. Commençons :

• Forms : un bon tuto plus du code pour faire migrer ses formulaires vers HTML5 en construisant un fallback JS. Web Forms 2 renommé en HTML5 Forms sera sans doute la plus utilisée des fonctionnalités HTML5 et permet d'écrire dans le markup du comportemental habituellement écrit en JavaScript comme la validation, les champs obligatoires ou du texte par défaut, réduisant ainsi les temps de développement grâce aux standards. L'auteur part ici de webforms2, la seule librairie JS que je connaisse qui émule la spec Forms, mais qui n'est pas complète. Il rajoute par dessus le support des widgets, comme l'apparition d'un calendrier pour les champs de type date ou datetime, d'un color-picker pour color ou même le support de placeholder (texte par défaut qui disparait au clic) qui est bizarrement absent de webforms2. Ces widgets proviennent d'autres scripts, et dans votre implémentation vous pouvez tout à fait y préférer ceux de YUI ou jQuery. L'auteur promet de faire encore évoluer cette librairie, mais c'est en lisant cet article que je me rend compte de la somme faramineuse de travail à faire pour supporter complètement les specs HTML5 Forms, autant pour les faiseurs de navigateurs que pour des librairies JS. Malgré cela, il me semble judicieux en tant que webdev de passer d'hors et déjà à la syntaxe HTML5 pour les forms (<input type="email" required pattern="[a-z]@[a-z].com" /> par exemple). Si vous avez déjà du code comportemental écrit en JS, reprenez le pour qu'il analyse le markup au lieu de tout déclarer en JS, si vous n'en avez pas, faites votre propre classe et encapsulez webforms2 dedans pour avoir une bonne base.
• JavaScript : comment détecter qu'une propriété existe en javascript ? Facile, en général on fait un if( instance.property), sauf que cela retourne false si la property en question est une chaîne vide ou 0 en plus de null et undefined, ce qui peut surprendre si l'on vient de PHP car on croit avoir l'équivalent de isset() alors que ce test se rapproche plus de empty(). Si vous voulez éviter les surprises et vous faciliter la maintenance, vous pouvez utiliser une fonction de test (isValue() de YUI par exemple) ou plus simplement if(property in instance). Cette dernière solution pose d'autres problèmes de compréhension si vous avez une chaîne d'héritage objet
• Web Socket : tutoriel pour démarrer un projet utilisant WebSocket (communication permanente entre le client et le serveur) en PHP et Javascript. Plutôt que d'utiliser Node.js (et donc avoir à l'installer), l'auteur utilise une librairie PHP qui fait office de serveur WebSocket (attention, elle demande à pouvoir lancer un PHP en ligne de commande). Côté JS, l'auteur fait l'impasse sur un quelconque fallback Flash (il  existe pourtant au moins 3 jeunes librairies : Socket.IO, web-socket-js et jWebSocket). Côté serveur, il faut signaler que PHP est fortement critiqué pour faire serveur de socket car demander à Apache+PHP de tenir ouvertes des connections pendant longtemps n'est pas vraiment ce pour quoi ils ont été développés. Mais cette librairie vous permettra au moins de commencer à tester WebSocket sans installation supplémentaire.
• Browser War : IE9 devrait sortir cet automne en beta. De mémoire MS fait en général 2 ou 3 betas de plusieurs mois avant de finalement sortir. On ne parle plus de "developer preview" comme jusqu'ici mais bien d'un vrai navigateur, avec tout son interface graphique et ses fonctionalités. Je me demande si ils vont rattraper l'avance que prendra Firefox 4 avec la gestion des identités. En attendant, continuons à tester nos sites avec la preview pour remonter des bugs à MS : lorsqu'ils seront en phase de beta, ils auront moins de temps à consacrer aux bugs du moteur, pour corriger en priorité ceux de l'interface.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .

RPW 27/07/10: youtube et HTML5, faire son player video html5, chiffres Web Mobile français, historique de GMail

Revue de Presse Web de hier :

• Vidéo : Youtube propose son player "embedable" en version HTML5. Il s'agit d'une iFrame incluant une page comme celle-ci contenant le player et ses dépendances, le fallback Flash étant inclus au besoin. Même si le journaliste s'en étonne, car Youtube avait fait un rapport critique (résumé dans cette news) sur son expérience HTML5, il faut tout de même rappeler que cette critique est valable aujourd'hui, et ne le sera plus dans le futur (1 an ?), et que bien peu de sites ont la grille de critères de Youtube. D'autant que ce nouveau player est en phase d'expérimentations et est fait de manière à recevoir des feedbacks de la part des développeurs, une bonne manière donc de prévoir le futur. Ravi de voir cette confirmation que Google n'abandonne pas la partie.
• Vidéo : tutoriel pour construire soi même un player video HTML5, avec fallback Flash. Il manque la partie la plus compliquée qui est une API unifiée à l'un ou l'autre player et avec des skins similaires, mais le but avoué du tuto est de faire découvrir <video> et son API JS, à vous donc d'implémenter le reste. Ou de choisir parmi la pléthore de librairies "video HTML5" (si quelqu'un a un tableau comparatif des fonctionalités de ces librairies, je prends, j'en aurais besoin pour mon intervention Paris Web)
• Mobile : des chiffres français sur le Web Mobile. 30% des français ont un forfait Web Mobile. Il y a même 2 millions de comptes ouverts data uniquement (les "clés 3G" pour Netbook ou les Sim pour iPad, probablement une majorité de pros ?), et d'après les projections (qui valent ce qu'elles valent) cela donnerait une majorité de français utilisant le Web mobile d'ici à 2 ans. La bonne nouvelle pour les développeurs, c'est qu'ils peuvent compter sur la présence très forte de navigateurs modernes (utilisation de HTML5 et CSS3), la mauvaise est qu'il n'est pas aisé d'avoir un site à la fois desktop et mobile et que les conntraintes (taille d'écran, touchscreen ou pas, réseau rapide ou pas, utilisation nomade ou pas ...) se multiplient.
• Applications : l'histoire impressionnante du code de GMail. De 10 000 lignes de JS à son lancement en 2004, ils en sont aujourd'hui à 443 000 lignes (hors commentaires), mais cela inclue Buzz, les chats video et audio et la partie SMS et des fonctionalités disponibles dans le labs. Dès le début ils ont innové en créant des outils côté serveur pour vérifier et valider le code JS, ce qu'ils ont fait évolué ensuite en un compilateur qui ré-écrit le code, dont les outils Closure sont issus. Issu de cette conférence, il se dit un peu partout que JS a même remplacé Java côté serveur, mais ce n'est pas écrit dans les slides et je ne peux pas accéder à la vidéo pour confirmer ces rapports. Depuis le début ils maîtrisent la génération de JS en fonction des besoins client : spécialisation par langue, par vue, par type d'utilisation, ne délivrant ainsi que le code qui sera le plus probablement utilisé pour chaque type d'utilisateur, ce qui correspond à énormément de combinaisons possibles, en plus d'avoir un mécanisme de lazy-loading. Ils se sont mis un peu tardivement à l'orienté objet, ont inventé un langage de templating commun et performant entre java et JS et passent à HTML5 très rapidement avec l'offline et le drop de fichiers, ainsi qu'à CSS3. Bref, vu les contraintes, la manière de coder et la capacité de développement de l'équipe Gmail, je crois qu'il faut arretter de se comparer et de dire "comme gmail" :)

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .

RPW 26/07/10: tests unitaire AJAX, librairie WebSocket, imprimer des éléments HTML5 sous IE

Revue de Presse Web du WE :

• Perfs : 2 résumés de la soirée performances : l'un par Zeroload, l'autre par Johan Bleuzen qui a noté quelques points particuliers sur la technique du flush() telle qu'utilisée par Google, ainsi que d'autres détails de la présentation très dense de Stoyan (je suis à peu près sur qu'elle était inédite et qu'il a profité du niveau de la soirée pour se lacher un peu).
• Tests : outil jQuery permettant de compléter vos tests unitaires et d'intégration en simulant des retours de XHR (dites requête Ajax). Les tests unitaires coûtent très cher pendant la phase de développement (il faut ajouter 50% du temps de dev), mais ce temps est compensé par une baisse du coût de debug et une hausse de la qualité du service (et de la satisfaction des développeurs, ce qui n'a littéralement pas de prix). Si vous avez franchi le cap, vous avez probablement déjà un framework de tests unitaires, mais il ne comporte pas forcément de quoi simuler (mocker) les XHR. Si ce n'est pas le cas, il est intéressant de commencer par tester les couches les plus basses comme l'accès aux données, car c'est généralement la plus stable. Le retour sur investissement est donc bien meilleur et cet outil peut vous aider à démarrer.
• HTML5 : un fix pour IE, qui ne sait pas styler les éléments inconnus comme ceux de la nouvelle sémantique HTML5. Le fix est on ne peut plus bourrin puisqu'il consiste à remplacer les <article> et autre <nav> par des <div> au moment de l'impression ... Pas sur que cela marche donc avec toutes les feuilles de style, si il y a des règles qui ciblent ces éléments (ce qui d'après certains était une mauvaise idée du point de vue des performances ou de l'organisation du code).
• Websockets : Socket.IO est le genre de petite librairie que l'on aime car elle permet de s'affranchir des questions d'implémentation dans les browsers pour se concentrer le code de votre appli. Elle émule donc WebSocket sur les navigateurs ne le supportant pas (IE6-8, anciens FF) avec un fallback Flash et d'autres méthodes que je ne connaissais pas (ActiveX HTMLFile qui est l'équivalent d'une iframe scriptée mais qui évite l'indicateur de chargement d'IE). Le projet a l'air jeune mais très actif, par contre je ne l'ai pas testé et le manque de documentation est inquiétant (hormis les fonctions de base) : il est évident qu'utiliser le(s) fallback(s) long polling ou websocket ne se gère pas du tout de la même manière côté serveur, et rien n'est dit là dessus.
• Nawak : insultes de développeurs, style "Ta mère a oublié de faire un checksum à ta naissance" ou "Ta mère en Open source". Drole. Ou pas

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .

RPW 23/07/10: HTML5 et DIV, Node.js sur un multi-thread, introduction performances Web

Revue de Presse Web de vendredi dernier :

• HTML5 : article sur l'utilisation du tag <div> dans la sémantique HTML5. Dans mon implémentation de l'époque je n'avais pas très bien compris la différence entre <div> et <section>, la raison principale étant que je croyais que <section> ne voulait rien dire. Cet article rappelle donc que ce n'est pas le cas, que non seulement <div> fait toujours partie de la spec HTML5 mais qu'en plus il est recommandé de l'utiliser, notamment pour s'aider à styler la page ou à séparer des parties du markup de manière arbitraire. <section> s'utilise quant à lui autour d'un contenu de texte isolable suffisamment important ou signifiant pour contenir un titre (<hx>), et qui n'est pas un <article>, <nav> ou tout autre nouvel élément plus signifiant. Voir ce très pratique (et imprimable affichable dans le bureau) schéma de décision.
• Node.js : Yahoo! fait ses essais et les partage : la problématique de Yahoo! et des sites en général qui développent avec des langages server-side traditionnels comme PHP, c'est que pour tenir la charge, ils ont eu tendance à s'acheter des serveur multi-core. Dans ma boîte par exemple, on a très peu de puissance brute par process, mais on peut tenir énormément de threads en simultané. Hors un serveur Node.js ne tient que dans un seul thread, gérant en interne les concurrences, et du coup ne bénéficiant pas des serveurs multi-thread. Les solutions explorées par Yahoo! ici passent soit par un load-balancer, par un patch du kernel ou (probablement plus facile à déployer) d'un seul serveur Node.js pour router sur les autres instances Node, avec l'utilisation inattendue de Web Workers côté serveur.
• Perfs : bonne présentation générale autour des performances Web, ou la problématique (temps = argent, 90% de l'optimisation est côté client) et les premières solutions (gzip, réduire les requêtes HTTP ...) sont présentées à des non-experts performances Web, en 20 minutes seulement. Bien pour débuter ou faire ce genre de présentation en interne.
• HTML5 history : cette spécification permet de gérer l'url affichée et l'utilisation des boutons précédent/suivant des navigateurs, sans recharger la page, et est déjà supportée par les Webkit et FF4. Elle viendra en remplacement des hacks actuels, certes encapsulés, qui consistent à utiliser une iframe ou à gérer les états de l'application derrière le # de l'url (et donc à faire tourner un timer infini pour surveiller cette url). Il ne reste plus qu'à espérer que les librairies vont se mettre à jour pour l'utiliser, afin de continuer à l'utiliser uniformément sur tous les navigateurs.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .

inclusion performante de javascript, la mini-conférence

ce site a migré : retrouvez cet article à jour sur braincracking.org

Pas de revue de presse ces 2 derniers jours car j'ai du préparer une mini conférence de 20 minutes et les sujets performances demandent énormément de recherches et de validation :)

Voici donc mes slides en ligne (PDF ici) de la soirée performance de hier, organisé par Eric Daspet et hébergé (et alcoolisé) par Octo. L'idée était d'explorer un point particulier des performances Web, le sujet traité ici étant l'inclusion non-obstrusive de JS. Il y a beaucoup de techniques plus ou moins exotiques, au final je vous ai épargné un listing savant que j'ai troqué contre un début de guide pratique d'implémentation. Je n'ai pas pu estimer de coûts de développement car les sites sont beaucoup trop différents.

Après un rappel des contre-performances des <script> dans le <head> (Voyages-sncf a des serveurs ultra performants qui délivrent du HTML en 200ms, mais la page reste blanche 2s), rappel des 3 techniques non bloquantes officielles :

• Inline : on n'y pense plus, et pourtant c'est celle qui demande le moins de modification de code. A utiliser pour les pages avec beaucoup de nouveaux visiteurs, sans trop de JS (jeux concours, les HP Google, facebook, Yahoo!, Netvibes ...)
• Bottom : déplacer le <script> du <head> à la fin de <body>. A partir de là les difficultés d'implémentation commencent car vous avez probablement du JS inline qui avait des dépendances dans le fichier que vous venez de déplacer. 2 hacks possibles alors, l'un mute+eval() que j'applique déjà, l'autre que je n'ai pas exploré qui consisterait à hijacker les fonctions qui seront appellées pour les exécuter plus tard. Si cela n'est pas possible, vous êtes bons pour modifier votre code inline, ce qui est en général le moment où le "projet performances" tombe à l'eau ...
• DOM : la meilleure mais la plus lourde à implémenter, qui consiste à créer dynamiquement des <script> et à y attacher un callback JS contenant le code dont il dépend. C'est la plus pérenne à mon sens car une fois passé le gros boulot consistant à fixer son JS inline (en général encapsuler le code dans une fonction de callback suffit), alors le code est extrêmement souple et résistera aux changements à venir : code JS qui grossit et se complexifie, découverte de nouvelles techniques ...

Les liens en raccourci dans les slides sont des références que je vous ai déjà partagé, mais vous trouverez aussi quelques références sur le comportement IE6-7 intéressantes si vous êtes plutôt côté R&D

On le voit, sur un site existant gagner plusieurs secondes (donc de l'argent) sur l'inclusion des JS est réalisable mais a un certain prix. Ceux qui sont avantagés sont ceux qui développaient déjà de manière non-obstrusive (HTML d'abord, puis CSS, puis JS) et qui organisent déjà bien leur code JS (une classe ou un ensemble de méthodes par fichiers par exemple).

Si vous n'arrivez pas à faire passer un projet d'un bloc malgré vos arguments financiers, passez au moins doucement votre code à la méthode DOM au fur et à mesure de la maintenance de votre site, tout évolution future sera moins pénible :)

Et avant cela, il vous faut implémenter des techniques tout aussi efficaces et moins chères, comme la compression gzip, la concaténation des CSS/JS et surtout la gestion du cache navigateur.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail.

RPW 19/07/10: savoir lire un graphique réseau, les fichiers complémentaires des sites, référence Canvas, astuce police

Revue de Presse Web de hier :

• Perfs : bonne vidéo sur comment lire un graphique réseau généré par webpagetest.org et httpwatch.
• Gestion : petit listing des fichiers invisibles mais utiles qui accompagnent les sites, et qu'on oublie souvent de maintenir, voir de faire au début d'un site. Il y a bien sur les favicon.ico et robots.txt qu'on ne présente plus, et qui vous éviteront d'avoir des logs plein de 404, mais aussi sitemap.xml qui pointe les moteurs de recherche sur certaines urls (généralement généré dynamiquement), Dublin.rdf qui permet de stocker des metadatas de votre site (ce qui évite de les mettre systématiquement dans le <head> de votre site) et enfin Opensearch.xml qui permet à un utilisateur d'ajouter votre moteur de recherche dans son browser (tutoriel ici par Alsacreations)
• Canvas : feuille de références qui liste sur une image les méthodes et propriétés Canvas. Toujours pratique pour imprimer et afficher dans son bureau, si vous en venez à commencer à utiliser Canvas en complément voire en remplacement de Flash.
• Fonts : astuce pour ceux qui hébergent leurs polices : Firefox inclut des restrictions de nom de domaine pour respecter les droits inhérents à certains formats de police. L'hébergement des fichiers statiques sur un autre nom de domaine (sans cookie) étant une amélioration de performance Web qui devrait se populariser, cela peut poser problème. La solution décrite ici est de modifier la configuration du serveur Apache pour que FF accepte de télécharger la police.
• Outils : excellent tutorial complet sur l'utilisation de Git, en remplacement de CVS ou SVN.
• Canvas : n'est pas toujours le meilleur choix même pour des applications très graphiques comme un jeu vidéo en 3D isométrique. J'avais déjà partagé avec vous cette conférence sur l'impressionante implémentation d'un moteur de jeu en JS. Le point le plus surprenant était que ces développeurs ont préfèré utiliser un DOM classique plutôt que Canvas. Ils s'en expliquent donc dans ce post : problèmes de performances avec les images, beaucoup de code pour recalculer certaines choses que le navigateur gère déjà très bien et impossibilité de copier des parties de HTML pour les injecter dans un Canvas. 

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .

RPW 17/07/10: tester le type en javascript, HTML5 version courte, tester le comportement navigateurs face au cache

Revue de Presse Web de ce WE :

• HTML5 : présentation vidéo ultra courte des nouveautés d'HTML5 (la vraie spec), pas inutile pour montrer rapidement les promesses d'HTML5. On y voit notamment de la sémantique avec des <section> dans des <article> (j'ai mis du temps à quoi servait <section>...) et comment s'utilise <figure> et <legend> pour ajouter une légende à une image. Après sont rapidement passés en revue localStorage, Canvas, audio / video et la communication entre frames.
• JavaScript : comment tester le type en JS. On se dit typeof est là pour ça, mais comme souvent en JS, ça n'est finalement pas très intuitif. Par exemple "(typeof 'chaine')' renvoie bien 'string', mais "(typeof new String('chaine')" renvoie 'object'. Vous me direz : pourquoi utiliser l'objet String ? D'abord vous ne maîtrisez pas forcément tout le code JS (des librairies peuvent l'utiliser), et ensuite il y a un micro gain de performance JS : les opérations sur un objet String() sont un poil plus rapides que les mêmes opérations sur une 'string', ce qui devient important dans certains cas extrêmes (un moteur de template pour moi). Pour être certain d'avoir un code bullet proof, il vaut donc mieux utiliser une méthode qui sait tester les types. L'auteur présente ici sa version, perso j'utilise YUI et je n'ai pas trouvé d'équivalent jQuery à part un isArray, mais vous connaissez surement jQuery mieux que moi ?
• Perfs : Petit script pour tester le comportement du cache des navigateurs en fonction des headers. Il vous permet de construire une page de test incluant JS, CSS ou images avec des temps d'attente et surtout des directives de cache. C'est moins pratique que Cuzillion, mais dans ce dernier les headers ne sont pas configurables, vous ne pouvez donc tester que les visites sans cache.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .

RPW 16/07/10: poids des pages, moteur de jeux en JS, convention de codage JavaScript, intersection de tableau javascript

Revue de Presse Web de hier :

• Perfs : les pages web sont de plus en plus lourdes, c'est un constat que l'on se fait depuis l'avènement de l'ADSL pour tous en France mais à quel point cela est il grave ? Le markup d'un site populaire comme CDiscount fait 172Ko (normal, tout est à base de <table> ...), mais il ne fait plus que 31Ko une fois gzippé : il est généré et reçu en moins d'une demie seconde, ils ne voient sans doute pas l'intérêt de changer. Et pourtant si l'on ajoute les 15% d'utilisateur à qui l'on ne sert pas Gzip (voir ce PDF) aux utilisateurs sans ADSL (5%) ou sur réseau mobile, on peut se dire que le poids de la page est toujours important, même en France pays du haut débit.
• JavaScript : un code très optimisé pour obtenir l'intersection de 2 tableaux. Des solutions JS génériques comme Taffy DB ou JSLINQ permettent de manipuler sans difficulté des tableaux, mais lorsqu'arrivent des problèmes de performances, ces librairies ont rarement été optimisées. L'auteur présente donc ici un algorithme qui est beaucoup plus efficace sur les grands ensembles. Etant donné les licences et la vitesse à laquelle ces librairies évoluent, cela vaut peut être mieux d'utiliser un wrapper pour pouvoir changer facilement de code et avoir le mieux optimisé pour vos besoins.
• JavaScript : convention de codage en JavaScript, par Google. Sans le savoir et à force d'erreurs je respecte déjà les ³/₄ de ces conventions, qui deviennent logiques dès que ce que l'on code dépasse le stade du scripting ou que la taille de l'équipe dépasse 1. Les règles sont très diverses et vont de la documentation au format JavaDoc (la même que pour PHP, facile) à l'utilisation d'eval() en passant par les conventions de nommage (majuscules pour les constante, camelCase pour les fonctions ...). Et cela évite également les débats sans fin sur l'utilisation de ' ou " pour les chaînes de caractères ou la position des {} : il n'y a parfois pas de gagnant, il faut juste trancher. Même si certaines de ces règles sont orientées pour faire passer son JS au Google Closure Compiler, la formalisation de ces règles dans votre équipe vous assurera quoi qu'il en soit une maintenance plus aisée.
• JS : conférence sur un moteur de jeu en JS. Il s'agit du moteur Aves, dont voici une bonne démo. Ca prend 45mn en anglais, voici donc quelques notes :
  • Canvas n'est pas assez efficace => utilisation directe de .innerHTML
  • jquery est utilisable pour sa gestion de la souris et son modèle évènementiel
  • 2D et 3D isométrique seulement, WebGL est très loin
  • Flash éliminé pour manque d'interopérabilité
  • utilisation de la génération de classes plutôt que de générer des styles inlines sur chaque élément
  • l'industrie du jeux peut se permettre d'attendre HTML5, CSS3 et l'accélération matérielle, car ils savent qu'ils vont passer 1-2 ans sur un jeu
  • 3 listeners pour tout le document ! pour gérer les zones non carrées, ils voulaient gérer une carte de pixels en JS, et finalement ils ont utilisé Canvas pour analyser les images et savoir si la zone cliquée était transparente ou pas !
  • l'avantage de réutiliser JS au frontend comme au backend est que des portions de code sont réutilisables, pour calculer les positionnements par exemple
  • JS au backend est presque aussi rapide que C, utilisation de EcmaScript 5
  • mais Node est tout neuf
  • le code backend event-driven, jamais bloqué est idéal pour des MMO
  L'intérêt d'étudier cette utilisation extrême de JS est que c'est une vraie implémentation professionelle de toutes les techniques HTML5, CSS3 et Node.js. Même si leur vision se situe à 2 ans d'ici, cela préfigure ce qu'il sera possible d'ici là.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious, Mail .