Préface

Comme indiqué dans un précédent billet, je tente l'ouverture du blog à des auteurs externes, de jeunes développeurs brillants et sélectionnés avec soin.
Ils apporteront leur expertise et un point de vue décalé sur des sujets que je ne traite pas habituellement.

Je vous présente aujourd'hui Hadrien Pierart, freelance au parcours atypique, spécialisé dans le développement front (web et Android).
Hadrien tiendra notamment une rubrique récurrente intitulée "Dernières nouvelles du Front", inspirée des célèbres Javascript Weekly et HTML5 Weekly, dont voici le premier numéro.

Bonne lecture !
Olivier

Dernières nouvelles du Front #1

Quelques mots sur moi pour cette première édition : historiquement développeur Java Android, je me suis rapidement mis au développement web et plus particulièrement JavaScript. Comme on ne peut rarement tout faire, j'ai choisi de me concentrer principalement sur le web, les webperfs et le développement fullstack avec une nette préférence pour le front et une passion pour ce langage atypique qu'est le JS.

Je suis freelance comme Olivier et je travaille actuellement pour une startup nommée Once.
Enfin je suis aussi Editor pour infoQ FR.

Pour résumer cette édition, je vais vous parler de plugins grunt, de nouveautés ou fonctionnalités cachées des DevTools de Chrome, de convention de code en CSS et un peu de JS bashing pour finir. (Ca fait toujours sourire, même pour un grand adepte comme moi)

Aujourd'hui plus que jamais, le Javascript a le vent en poupe. On le trouve même côté serveur - ce que je trouve personnellement d'une absurdité étourdissante, mais passons.

En ce moment, la mode est aux frameworks MVC côté client ; là, j'y crois déjà un peu plus. Mais il en sort environ un par semaine, et il est difficile de faire son choix, malgré la pléthore de comparatifs qui fleurissent sur le net (ici, là, ou encore là-bas).

Thoughtworks, de son côté, estime que la peinture n'est pas encore sèche et qu'il vaut mieux attendre un peu avant de se lancer dans ce genre d'aventure en production. En effet, on a encore très peu de retours d'expérience, et la pérennité des frameworks n'est pas encore démontrée.

Pourtant, dans le tas, il y en a un qui m'a fait de l'oeil : Angular.js. Je vous propose donc une petite démonstration de son intégration avec Spring MVC côté serveur, pour réaliser une application, totalement originale n'est-ce pas, de "todo-list".

Google a récemment (et sans prévenir) changé son API permettant d'intégrer des Waves sur des sites.
Rien de méchant, car cela concerne surtout les options graphiques, mais cela a suffi pour empêcher mes compte-rendus de conférence de s'afficher correctement : à la place, il n'y avait plus que du blanc... J'ai donc fouillé un peu pour trouver d'où cela pouvait venir.
Vous trouverez ci-dessous les nouvelles instructions détaillées.

Et puis, j'en profite pour vous annoncer la bonne nouvelle : il est maintenant possible de consulter les Waves intégrées sans posséder de compte Wave !
C'était la principale critique remontée à Google, et elle a visiblement été écoutée. Par contre, la modification de la Wave est toujours réservée aux utilisateurs authentifiés.

Google Wave provides an "Embedded API" that can be leveraged to insert a single Wave into any HTML page.
Unfortunately, the official documentation is somewhat old and gives the procedure only for the sandbox waves, not the regular ones. As a result, I had to struggle more than an hour long and browse the API's source code to get all the parameters right, and eventually successfully display a wave in a blog post (see my summary of the last Paris JUG's meeting, in French).

Here is a very short tutorial to help you integrate waves in your own websites/blogs in minutes !

Je me suis un peu amusé avec la nouvelle balise HTML5 Canvas et l'API Javascript associée...
Si vous avez un navigateur récent, vous devriez pouvoir voir et contrôler les flammes :

Je vous invite à regarder le code source de la page pour plus de détails !

Voici le compte-rendu de la conférence "Dans la tête de Peter Lubbers" organisée par Zenika mercredi dernier.

Peter Lubbers est directeur de la formation chez Kaazing, une société spécialisée dans le streaming de données en temps réel pour le web ; leur produit phare, le WebSocket Gateway, exploite au maximum les dernières API de communication proposées par HTML5. Peter était donc l'homme de la situation pour nous donner les dernières nouvelles du front, en attendant la sortie de son livre "Pro HTML5 Programming", prévue pour avril.

La conférence s'organisait autour de 5 points : le bilan des technologies actuelles, les WebSockets, les Server-sent Events, l'objet XmlHttpRequest version 2, et le Cross-document messaging.

Lorsque, dans une page Web, l'utilisateur déclenche une action qui modifie toute la page, il est de bon ton de s'assurer qu'il ne déclenche pas une autre action avant que la page suivante ne soit chargée.

Tous les éléments qui permettent à l'utilisateur d'agir sur la page doivent donc être désactivés. Parmi ceux-ci, il y a les champs de formulaires (champs texte, boutons-poussoir, boutons radio, cases à cocher, ...), et les liens hypertextes.

Si désactiver les champs de formulaires est assez facile en JavaScript (tous possèdent un attribut disabled, qu'il suffit de mettre à true), désactiver les liens est une autre paire de manches ! Il y a bien un attribut disabled sur les ancres, mais c'est une spécificité, non standard, d'Internet Explorer. Et en plus cet attribut ne modifie que l'affichage : avec IE, un hyperlien dans l'état "disabled" est toujours actif !

Ce constat mène assez rapidement à la question suivante : comment faire ? Et d'ailleurs, est-ce faisable ?

Qu'insère le bloc JavaScript suivant dans la page HTML ?

var flagBidon = true;
 
function test() {
    var x = 5;
 
    document.write(x);
    document.write("<br/>");
 
    if (flagBidon) {
        var x = 10;
        document.write(x);
        document.write("<br/>");
    }
 
    document.write(x);
    document.write("<br/>");
}
 
test();

Qu'insère le bloc JavaScript suivant dans la page HTML ?

var x = 9;
function test() {
    document.write(x);
    document.write("<br/>");
 
    var x = 10;
 
    document.write(x);
    document.write("<br/>");
}
test();
document.write(x);

Un petit quiz JavaScript, pour changer. Voici une fonction de validation de dates, écrite en JavaScript :

/**
* Vérifie que la date passée sous la forme d'une chaîne de caractères
* (exemple : "15/11/2008") est valide
*/
function validateDate(dateAsString) {
    // Vérifie que la date est du format "JJ/MM/AAAA"
    var regex = new RegExp("^[0-9]{2}[/][0-9]{2}[/][0-9]{4}$", "g");
 
    if (regex.test(dateAsString)) {
        // Vérifie en plus que les champs jour, mois et année sont
        // cohérents et correspondent à une date pas totalement farfelue.
        var fields = dateAsString.split("/");
        var day    = parseInt(fields[0]);
        var month  = parseInt(fields[1]);
        var year   = parseInt(fields[2]);
 
        if (day   > 0 && day   < 32 &&
            month > 0 && month < 13 &&
            year  > 1970 && year < 2200) {
            return true;
        }
    }
    return false;
}

Question : Certains jours de l'année 2009 ne passent pas la validation alors qu'ils le devraient. Lesquels, et pourquoi ?