Revue de Presse Web du Week-End :

• Perfs : un mini-framework PHP (CSS-JS Booster) qui regroupe toutes les solutions actuelles pour servir efficacement CSS et JS : date d’expiration loin dans le futur et gestion automatique des versions (votre utilisateur aura toujours soit une version cachée, soit une version à jour), concaténation, minification (même si vous n’avez pas les droits d’exécution ou java d’installé, en utilisant Closure Service) et gzip des pages. Cerise sur le gateau : a été implémenté l’encodage des images dans le CSS en base64 et MHTML (IE) et le CSS final est divisé en 2 parties pour paralléliser le téléchargement (je n’y avais jamais pensé). Je ne l’ai pas testé mais à la lecture du code, cela a l’air plutôt solide même si l’auteur prévient que le code est encore jeune, et d’après Vincent Voyer (Zeroload) c’est production-ready puisqu’il va le déployer sous peu chez un gros client (après avoir contribué au code).
• CSS3 : comparatif des syntaxes mozilla et webkit pour faire des dégradés en CSS3. Les 2 syntaxes sont radicalement différentes et à priori c’est celle de Mozilla qui ressemble le plus à la spec actuelle (toujours en cours d’écriture), ce qui ne veut pas dire que cela sera la définitive. Sinon je vous conseille cet excellent outil pour générer des dégradés qui permet en outre d’avoir le filtre IE correspondant lorsque c’est possible (IE ne gèrant que des dégradés linéaires avec 2 couleurs), et en fallback … il vous génère un PNG :)
• Accessibilité : explication et démo en vidéo de l’attribut ARIA-live, qui permet de marquer les zones dynamiques de votre markup (qui seront mis à jour après une XHR par exemple) afin que les lecteurs d’écran re-lise la partie mise à jour. ARIA-atomic permet lui de donner le contexte, par exemple mettre les attributs <div aria-live=« polite » aria-atomic=« true« >, permet de relire la DIV, et non pas seulement le sous-élément mis à jour. On voit également la différence entre les valeurs « polite » et « rude«  (depuis remplacé par « assertive« ) qui avertisse l’utilisateur du changement de manière plus ou moins dérangeante.
• Tests unitaires : post engagé rappelant l’évidence : du code écrit avec des tests unitaires (par la même personne) tiendra mieux la route sur le long terme. Outre le fait que vous évitez nombre de bugs, il est en plus plus facilement maintenable car écrire le test en même temps force à penser son code un peu plus et au final à l’écrire de manière beaucoup plus modulaire, ce qui est plus facile à tester et à modifier par la suite. Il cite également d’autres articles qui mettent tous le doigt sur un point : les développeurs n’aiment pas tester leur code, alors qu’au fond cela fait partie intégrante de leur métier que de garantir un certain niveau de qualité. D’après mes expériences, que je n’ai jamais généralisé à l’ensemble d’un projet par peur de perdre du temps, écrire ses tests en codant rallonge le temps de développement initial de 50%, temps que vous rattrapez en théorie sur le long terme, en plus d’une meilleure stabilité du site. Mais pour le moment je réserve ce traitement de luxe aux classes de bas niveau, absolument essentielles au site et qui résisteront aux changements d’interface ou de business. Cela concerne une minorité du code, mais c’est déjà un bon début et cela évite d’énormes bugs, pas toujours décelables immédiatement.
• Emploi : être bon en JS, il paraît que ça paye. Dans ce post, l’auteur (contributeur Mootols, 15 ans de web) nous explique qu’il recherchait des profils de bon développeur frontend et que cela lui paraît juste impossible à trouver, et qu’il est donc prêt à payer très cher. Et donc de conclure qu’il est bon d’être développeur JS ces temps ci. Vive les US donc, car il ne me semble pas qu’en France quelqu’un avec le pédrigee qu’il décrit trouvera jamais un salaire très supérieur à la moyenne, la preuve avec ce site français dédié aux emplois JS qui ne propose que très peu d’offres, et dont la moitié des offres est à côté de la plaque.