Pour bien commencer, rien de tel que CodeKit. Il s'agit juste une outil (éditeur ? IDE ?) orienté web, pas libre, sous mac. Parfait, pour mon bon public, non ?

Si vous avez étés déçus par le premier lien (mais je suis sur que ce n'est pas possible...) voici la sortie d'AngularJS 1.0. J'étais probablement à l'ouest ces derniers temps, mais je ne me souvenais pas que c'était passé chez Google. D'ailleurs j'ai pas tout compris, mon navigateur avait encore une partie du site en cache, de l'ancien site je veux dire. Ca faisait un mélange assez particulier.

Quoi qu'il en soit, j'ai commencé à m'y mettre ces derniers jours. Au début plus par curiosité qu'autre chose, et finalement j'ai trouvé ça plutôt bien. Assez simple d'utilisation, une documentation correcte, des possibilités intéressantes. Evidemment je suis tout de suite tombé dans des cas tordus : genre je veux exécuter une fonction JS lors de la compilation de la donnée, j'ai pas encore bien réussi à le faire malheureusement.

Pour l'histoire, le but est de recevoir une donnée en Markdown et de laisser le javascript l'afficher correctement. Pour ce faire j'utilise PageDown qui n'est ni plus ni moins que le js utilisé sur l'ensemble des sites Stack Exchange. Et ça fonctionne plutôt bien. Mais bon, c'est pas tout, faut que je me plonge dans AngularJS pour savoir comment appeler le formatteur au bon moment. Ca doit pas être si compliqué que ça, mais j'ai pas encore vraiment mis la main dessus.

Et une fois que mon applis ressemblera à quelque chose, je viendrai probablement en parler icitte, je sais que certains seraient intéressés (mais j'en dit pas plus sinon c'est pas drôle).

Ha oui, et Google utilise déjà AngularJS en production dans Places par exemple. Google ressemble malheureusement sur ce point à une entité sans direction réelle, entre closure, jquery, angular, gwt... c'est un beau bordel.

Allez, pour continuer dans le oueb, voici un article réellement intéressant concernant les performances CSS. C'est un point qu'on oublie souvent lorsqu'on parle de performances web, pourtant l'impact peut être important. Il est en effet intéressant de comprendre comment les navigateurs interprètent le CSS. L'impact n'est pas tout le temps en terme de performance pure, mais il l'est beaucoup en terme de ressenti. Ce qui est important si on veut que l'utilisateur ait une bonne impression c'est que ça ne flash par exemple pas partout, mais pour ça il faut comprendre l'ordre de chargement et d'exécution de l'html et du css. Certains navigateurs fonctionnent à l'envers les uns des autres par exemple (application du CSS pendant le rendu du DOM ou uniquement après par exemple). Bon, je vais pas beaucoup plus loin, le but étant surtout de vous intéresser au sujet, il faut parfois fouiller un peu mais il y a pas mal de ressources sur le sujet mine de rien.

Tant qu'on est à parler de navigateurs, parlons un peu de bouses. Certains sites se sont mis à appliquer des taxes pour les utilisateurs d'IE7. Justification : "faire un rendu propre pour IE7 ça prend du temps et coûte de l'argent". J'adore !

Un peu de sérieux quand même ! Revenons au CSS. Vous n'êtes pas sans savoir que, depuis quelques temps, des générateurs de CSS existent. Les plus connus étant {less} et Sass. Je suis plutôt fan il est vrai. J'aime particulièrement Closure Stylesheets mais c'est aussi parce que j'utilise toute la stack closure.

Quoi qu'il en soit, voici un article du train de 13h37 vous permettant de bien démarrer avec LESS au cas où ce ne serait déjà pas le cas. Entre autre découverte pour ma part, SimpleLESS qui est une petite application compilant vos fichiers .less à la volée. D'ailleurs cette application est disponible sous windows, linux et mac, et les sources sont sur Github sous licence CC by. Alors, pourquoi s'en priver ?

J'en profite égalemment, ceux qui ne le connaissent pas et qui pourtant s'intéressent au web pouront aller faire un tour du côté du train de 13h37. Assez sympa pour le moment.

Une petite apparté pour signaler à ceux qui l'auraient loupé que Github a désormais un client sous windows. Ça reste intéressant bien que je préfère l'ergonomie et le style du client mac (et que j'apprécie encore un peu plus SourceTree entre autre par la gestion de mercurial, j'aimerais vraiment que ce type d'application arrive sous linux, en open source si possible...).

Afin de rester sous windows (vous remarquez comment j'essai de lier mes news ? ;-) ) mais entre gens sérieux, voici de quoi avoir un petit shell sympathique : gow. Je ne l'ai pas encore testé parce que ma machine windows tourne avec un cygwin déjà configuré et que ça me gave de devoir tout changer, mais si je devais en réinstaller un aujourd'hui ce serait probablement celui-ci. Si vous avez de retours (bon ou mauvais) je suis preneur.

Hop, on revient un peu sur le dev web quand même. J'ai appris récemment l'existence de JSX : une alternative plus rapide, plus sûr, plus simple à JavaScript. En gros, un langage dont le but est d'être compilé en javascript, tout en étant fortement accès performances. L'objectif est donc de produire du code plus sûr, plus rapide, tout en étant plus lisible et plus maintenable. Une fonctionnalité intéressante (pour moi sans ça le projet perd réellement de son intérêt) qui est le support des sourcesmap permettant de debugger correctement son code.

Ce projet s'inscrit donc en partie en concurrence avec Dart. Enfin en partie seulement, car l'un des objectifs de Dart est d'être exécuté de manière native (ils pensent que c'est l'un des meilleurs moyens pour améliorer réellement les performances). La capacité de Dart à être traduite en JS est en quelque sorte un paliatif en attendant les VMs, alors que pour JSX ça semble être le but. Dans tous les cas quelque chose d'assez sympa.

Pour ceux qui en font (je sais qu'il y en a ici) écrire du coffeescript permet-il d'améliorer les perfs, ou est-ce plus lent, ou on en sait rien ?

Dans un précédent je parlais de l'attaque de CloudFlare. Un travail assez intéressant a été réalisé afin d'analyser les différents problèmes et de refaire la chronologie des évènements. C'est plutôt instructif.

Sinon, pour rester côté sécurité, une analyse du système de collision MD5 dans Flame a été réalisée. Le problème, ou au moins la surprise, est que l'attaque MD5 employée ne fait pas partie des versions qui étaient connues jusqu'à présent. Et il faut aussi avoir en tête que Flame date de 2010. C'est donc assez intriguant, et c'est quand même à se demander qui a écrit Flame. A priori seules des très très bons en crypto ont pu le réaliser. D'ailleurs, en 2008 casser du MD5 ça revenait à utiliser un cluster de 200 PS3 ou l'équivalent de $20 000 d'Amazon EC2... Assez impressionnant mine de rien.

Et si on s'éloignait un peu du développement et de la sécurité ?

Alors parlons, rapidement, un peu d'agilité. Pour ceux qui connaissent les méthodes agiles cet article ne va pas vraiment leur apprendre quelque chose. Par contre il tente, de manière certes un peu rapide et pas hyper approfondie, de répondre à la question de savoir si les méthodes agiles sont un effet de mode ou une révolution durable ? L'article est assez succinct et la conclusion est plutôt intéressante car résume bien le problème des méthodes traditionnelles en comparaison des méthodes agiles :

En définitive, ce qui différencie les deux approches (Cycle en V versus AGILE) est la réponse apportée à la question de la connaissance. D’un côté l’hypothèse qu’il est possible de connaître et de formaliser a priori (antérieurement à toute expérience) un système complexe. De l’autre, les méthodes AGILE qui réfutent implicitement cette hypothèse et proposent des pratiques intégrant une connaissance a posteriori des systèmes complexes.

Une assez bonne définition je trouve.

Et pour rester dans les méthodes, et vous, demandez-vous des M&M's dans votre cahier des charges ? Je ne me souvenais plus de cette histoire, mais sous ses allures de caprice se cache en réalité une vrai réflexion sur les cahiers des charges, leur lecture. Et mine de rien c'est une assez bonne option pour augmenter la sécurité.

Pour finir, et histoire de se détendre, voici quelques photos sympathiques. Il s'agit de scènes cultes de filmes réalisées à partir de lego. Bon je sais, c'est pas la première fois que certains réalisent des trucs en Lego mais c'est marrant.