mozFR

Mozilla Francophone

Firefox OS arrive
en France !
En savoir plus »

Mozilla : “Firefox + Vous” de juillet 2015 – Newsletter francophone

Mozilla Francophone

Miaou ! Rrrrrrrrr…

catpower.jpgÇa devait arriver : nous, les chats, avons pris le contrôle de la lettre mensuelle du mois dernier (recevez vous aussi le numéro d’août dans votre boîte aux lettres électronique).

Si vous êtes déjà adeptes de Firefox, faites connaître cette petite lettre à vos amis et à vos proches… Vous serez également les bienvenus si vous souhaitez aider à traduire les prochains numéros aux côtés de notre super équipe de traducteurs bénévoles.

Au menu : des chats qui vont vous en faire voir de toutes les couleurs, Firefox Hello, Firefox Friends et les rubriques habituelles !

 

Lire la suite »

Journée internationale de la bière : retour sur OpenBeerMap

Firefox OS

La Journée mondiale de la bière 2015  se déroule ce samedi 1er août.

À l’origine, ce fut un événement lancé en 2007 par un groupe d’amis de Santa Cruz en Californie et le phénomène a pris de l’importance pour gagner de nombreux pays.

Carte OpenBeerMapCette célébration de la cervoise, nous a paru le bon moment pour prendre des nouvelles du projet OpenBeerMap – notre première appdujour : Trouvez où boire une bière autour de vous avec Open Beer Map ! – et voir de quelle manière il avait évolué.

Qu’est-ce que…, un petit rappel ?

Depuis maintenant plus d’un an et demi, vous pouvez installer OpenBeerMap à partir du Marketplace de Firefox OS. Le but de cette appli est de vous aider à trouver le lieu proche de vous qui propose votre bière préférée.

Depuis son lancement, l’application a subi quelques améliorations :

Tout d’abord, la partie la moins visible au cœur de l’appli qui gère la géolocalisation des bières reste toujours la même. Le code a tout de même été nettoyé et simplifié afin de faciliter la contribution et la réutilisation.

Ensuite, la partie qui a subi le plus d’évolutions concerne l’interface utilisateur, principalement au niveau graphique.

Carte OpenBeerMap

Dans l’interface, vous pouvez personnaliser votre OpenBeerMap en changeant le fond de la carte et en affichant ou pas les restaurants.

Configuration de l'affichage dans OpenBeerMapÉdition du bar dans OpenBeerMap

Par ailleurs, vous pouvez affiner la personnalisation avec des fonctionnalités de recherche plus précises. Ainsi, vous pouvez trouver :

  • les bières de votre choix ;
  • les bières artisanales (même peu connues) ;
  • en bouteille ;
  • à la pression.

Enfin, l’ensemble de ces recherches peuvent être associées aux restaurants.

Bières préférées dans OpenBeerMap

Les contributions

Depuis son lancement, l’application a pu s’améliorer grâce aux 37 pays contributeurs, dont la France qui est en première position :

Pays contributeurs à OpenBeerMap

Concernant les systèmes d’exploitation, nous pouvons noter que les utilisateurs de smartphones Firefox OS sont les contributeurs les plus actifs et nous vous en remercions (amis lecteurs).

OS OpenBeerMap

Enfin, de nombreuses autres informations de statistiques, ont été publiées sur le journal OpenBeerMap.

Enfin

Actuellement l’application gère 986 bières différentes et elle est encore loin du compte car il faut savoir qu’il existe plus de 4 000 bières dans le monde ! Les auteurs de l’application comptent sur vous.

Même si l’application évolue régulièrement avec des nouvelles fonctionnalités, des lieux supplémentaires : les contributeurs d’origine lancent un appel pour aider à la progression de ce projet, soit au niveau du développement, soit en participant aux tests et aux traductions, et bien sûr en contribuant à l’application : vous pouvez compléter la liste des lieux, les informations à leur propos et les bières qui y sont servies.

Les informations de contributions sont disponibles sur le lien contribuer du site officiel.

Mais en attendant, vous pouvez consulter la carte sur le Web. Vous pouvez aussi installer l’application depuis le Marketplace sur votre ordinateur ou votre mobile Android équipé de Firefox.


@hellosct1
Lire la suite »

Ganesh et Pamela font découvrir Firefox OS à des milliers de Mauriciens II

Firefox OS

En plein action de présentation de l'Orange Klif à MauriceComme promis, nous retrouvons Ganesh de Mozilla Maurice, pilier de la campagne des lancements de Firefox OS en Afrique et au-delà. Dans la première partie de cette interview, nous avons vu son parcours avant Firefox OS, sa préparation de la campagne et des manifestations publiques pour présenter le Klif avec Orange. Voyons ce qu’attendent les habitants de Maurice d’un smartphone et ce qu’ils peuvent trouver sur ce marché insulaire, ainsi que les ambitions de Ganesh pour Mozilla dans sa région du globe.

Vous avez rencontré beaucoup de public. Quelles sont les questions qui reviennent le plus et celles qui vous ont le plus surpris ?

Les commentaires que nous avons recueillis pendant les événements de lancement de l’Orange Klif, parmi les gens sont toujours les mêmes dans les différentes régions. Ils étaient étonnés d’avoir un smartphone à ce prix et que ceci vaut le coup d’en posséder un ; ils ont pris connaissance pour la première fois l’existence du Firefox OS, la nouvelle plateforme de smartphones. Mais parmi les gens avec qui nous avons eu des échanges, ils cherchent à savoir les spécifications de l’Orange Klif : le nombre de pixels de la caméra, la disponibilité de caméra de l’avant pour faire des selfies, à propos la mémoire interne, la vitesse et le type du processeur, les outils de communication tels que WhatsApp, Viber et ainsi de suite.

Les Mauriciens en général cherchent des smartphones haut de gamme et des spécifications au-dessus de ce qui est disponible sur l’Orange Klif. Mais nous voyons qu’il y a une clientèle pour l’Orange Klif.

En plein action de présentation du Klif à l'Orange Klif lor baz à Maurice

Quelles sont les particularités de la pénétration et de l’usage du mobile à Maurice ? Quelles sont selon toi les principales différences du « marché » du mobile à Maurice par rapport au marché du mobile en Europe ?

En France par exemple, je vois qu’on peut acheter le service avec le mobile. Par contre à Maurice, on doit payer la facture complète du mobile et acheter aussi la puce. Avec Orange Maurice, on peut acheter un smartphone, un iPhone par exemple, et celui-ci est facturé sur son téléphone fixe.

Voici quelques statistiques concernant les smartphones :

Mozilla MauriceLa population de Maurice est estimée en 2014 à 1,3 millions d’habitants et le nombre des lignes de téléphone mobile était estimé à 1 450 000 en 2011 et en 2014 on est passé à 1 650 000 abonnés. Il faut aussi noter qu’en 2012 pour chaque centaine d’habitants il y avait 114 lignes mobiles. Nous avons trois compagnies comme fournisseur de service de téléphonie mobile : Orange, Emtel et MTML. La majorité des utilisateurs sont connectés à des services prépayés.

Ganesh, tu m’avais dit participer à des rencontres intercommunautaires africaines et avoir aidé à monter une communauté Mozilla à Madagascar. Peux-tu nous parler de cette collaboration entre les communautés en Afrique dont plusieurs francophones et du résultat de vos discussions et rencontres ?

C’est une très bonne question, car ça fait un bon bout de temps que je souhaiterais voir une communauté de l’Océan indien en regroupant toutes les îles mascareignes (Maurice, Rodrigues, Madagascar, Réunion, Mayotte, Comores et Seychelles). J’ai même abordé la question avec William Quiviger et aussi lors des meetups francophones en 2013 à Paris et récemment lors du meetup Africa à Nairobi (au Kenya). Je pense qu’on peut développer cette collaboration intercommunautaire avec l’idée de « Grow Mozilla » qui a d’ailleurs germé avec le lancement de Firefox OS en Afrique. Il faut aussi souligner que pendant le meetup Africa, il y avait des représentants de la Côte d’Ivoire et du Burkina Faso qui souhaiteraient aussi voir beaucoup plus d’interactions entre les communautés francophones de l’Afrique et de l’Occident.

Avec le lancement de Firefox OS en Afrique, dont je fais partie de l’équipe noyau, je me suis tourné vers le frère d’un un ami malgache, Mariot Tsitora, avec qui j’avais déjà eu des contacts dans le passé pour le faire adhérer à Mozilla. Mais depuis, je n’avais pas eu de nouvelle de lui. Comme il n’y avait pas de Rep à Madagascar, j’ai saisi cette opportunité pour rétablir le contact avec Mariot pour le mettre en contact avec l’équipe d’Orange Madagascar. Et à la surprise générale, Mariot était déjà un FSA (Firefox Student Ambassador) – bonne nouvelle ! Nous avions un contact à Madagascar ! J’en suis ravi. Il a fait preuve de sa volonté en collaborant avec l’équipe d’Orange et a aussi organisé des activités dans son université et ailleurs. Je pense qu’il fera un bon Rep. Mes prochains objectifs dans la région sont de créer des contacts et voir comment organiser des activités Mozilla sur ces îles.

Mozilla Maurice Reps

Ces projets sont super intéressants et j’espère que tu nous tiendras au courant. Nous espérons aussi pouvoir amplifier les interactions entre les communautés ayant un Firefox OS et, en particulier, dans les communautés qui ont le français en partage aussi bien au nord qu’en Afrique, au Moyen-Orient, dans l’Océan indien, en Océanie… et pourquoi pas en Asie.

En cette fin de semaine, les membres de la communauté noyau pour les lancements en Afrique se concertent à Paris avec Mozilla pour préparer la seconde phase de l’opération, et Ganesh est du nombre.


Vous pouvez retrouver l’actualité de Mozilla Maurice sur leur site et leur page Facebook. Retrouvez aussi Ganesh sur Twitter et l’actualité de Firefox OS en Afrique sur le blog multilingue Firefox OS Africa.


@Mozinet


Retrouvez la première partie de l’interview de Ganesh.

Retrouvez l’interview de Natalia (Mozilla) : Firefox OS en Afrique, c’est parti !


Crédit photos : Ganesh. Tous droits réservés.

Lire la suite »

ES6 en détails : les classes

Blog technique de MozFR

Suite de la traduction, qui continue la série d’articles de Jason Orendorff. L’article original se trouve ici. Vous pouvez retrouver les différents articles de la série grâce aux mots-clefs.

Merci à Jérémie et Banban pour la traduction et à goofy pour la relecture :) !


ES6 en détails est une série d’articles décrivant les nouvelles fonctionnalités ajoutées au langage de programmation JavaScript avec la sixième édition du standard ECMAScript (ES6 en abrégé).

Aujourd’hui, retour aux choses simples après quelques billets précédents assez complexes. Pas de façon complètement nouvelle d’écrire du code avec des générateurs, pas d’objets Proxy superpuissants qui viendraient s’accrocher à l’algorithmique interne du langage JavaScript, pas de nouvelles structures de données qui vous éviteraient de réaliser vos propres solutions. À la place, nous allons parler d’une solution syntaxique et idiomatique pour résoudre un vieux problème : la création de constructeurs d’objets en JavaScript.

Le problème

Supposons que l’on veuille créer l’exemple le plus emblématique de la conception orientée objet : la classe Cercle. Imaginons que nous sommes en train de créer un Cercle pour une petite bibliothèque Canvas. Entre autres choses, on pourrait avoir envie de savoir comment réaliser les opérations suivantes :

  • Dessiner un Cercle donné dans un Canvas donné.
  • Se souvenir du nombre de Cercles que l’on a créés jusque-là.
  • Se souvenir du rayon d’un Cercle en particulier et garantir qu’il ne puisse être modifié.
  • Calculer la surface d’un Cercle donné.

JavaScript tel qu’on le connait actuellement nous indique que l’on doit tout d’abord créer le constructeur de cet objet sous forme d’une fonction. Ensuite, il est nécessaire d’ajouter toutes les propriétés que l’on pourrait vouloir appliquer à notre objet directement sur cette fonction. Enfin, il va falloir remplacer la propriété prototype de ce constructeur par un objet ad hoc. Cet objet prototype contiendra toutes les méthodes nécessaires aux instances de notre classe. Même pour un exemple très simple, une fois que vous en aurez fini, vous allez vous retrouver avec ce genre de code un peu écœurant.

function Cercle(rayon) {
    this.rayon = rayon;
    Cercle.nbrDeCercles++;
}

Cercle.dessiner = function dessiner(cercles, canvas) { /* Code pour dessiner dans le Canvas */ }
Object.defineProperty(Cercle, "nbrDeCercles", {
    get: function() {
        return !this._count ? 0 : this._count;
    },

    set: function(val) {
        this._count = val;
    }
});

Cercle.prototype = {
    surface: function surface() {
        return Math.pow(this.rayon, 2) * Math.PI;
    }
};
Object.defineProperty(Cercle.prototype, "rayon", {
    get: function() {
        return this._radius;
    },

    set: function(rayon) {
        if (!Number.isInteger(rayon))
            throw new Error("Le rayon du cercle doit être un entier.");
        this._radius = rayon;
    }
});

Non seulement le code est lourdingue mais il est égalment assez peu intuitif. Il nécessite d’avoir une excellente compréhension du fonctionnement des fonctions et de la façon dont les propriétés et méthodes sont utilisables par les instances d’objets. Cela vous semble compliqué ? Pas d’inquiétude. Tout l’enjeu de cet article est de vous montrer une methode bien plus simple pour écrire un code équivalent.

Syntaxe de définition des méthodes

Pour commencer à nettoyer tout ça, ES6 propose une nouvelle syntaxe afin d’ajouter des propriétés exotiques à un objet. S’il a été assez facile d’ajouter la méthode surface à l’objet Cercle.prototype ci-avant, ça n’a pas été une mince affaire de gérer les getters/setters de la propriété rayon. Dans la mesure où JavaScript est de plus en plus utilisé avec une approche orientée objet, de nombreuses personnes ont eu envie de définir des méthodes plus simples pour ajouter de tels accesseurs et mutateurs. Ce dont nous avions besoin, c’était une façon d’ajouter des « méthodes » à un objet aussi simple que obj.prop = methode, sans la lourdeur de Object.defineProperty. On veut pouvoir simplement:

  • Ajouter une fonction ordinaire comme propriété d’un objet
  • Ajouter une fonction générateur comme propriété d’un objet
  • Ajouter une fonction accesseur ou mutateur comme propriété d’un objet
  • Ajouter n’importe laquelle des fonctions ci-avant comme si l’on avait utilisé la syntaxe à crochets [] sur l’objet fini, ce que l’on appelle les « noms de propriétés générés ».

Certaines de ces actions étaient impossibles jusqu’à présent. Par exemple, il n’y avait aucun moyen de définir un accesseur ou un mutateur via une affectation directe à obj.prop. Il a donc fallu rajouter une nouvelle syntaxe. Désormais, vous pouvez écrire le code suivant :

var obj = {
    // Les méthodes sont désormais ajoutées sans le mot clé "function",
    // le nom de la propriété devenant le nom de la fonction.
    methode(args) { ... },

    // Pour créer une méthode qui soit un générateur, ajoutez juste un '*', comme d'habitude.
    *genMethode(args) { ... },

    // Les accesseurs et mutateurs peuvent désormais être créés directement sur place
    // avec l'aide de |get| et |set|. Cependant ils  ne peuvent pas être des générateurs.

    // Notez qu'un accesseur défini de cette façon ne doit avoir aucun argument.
    get propName() { ... },

    // Notez qu'un mutateur défini de cette façon doit avoir exactement un argument.
    set propName(arg) { ... },

    // Pour pouvoir gérer le quatrième cas ci-avant, la syntaxe à crochets [] est autorisée
    // partout où un nom de fonction est attendu. Cela permet d'utiliser des symboles,
    // des appels de fonction, des concaténations de chaînes et toute autre méthode pouvant
    // être évaluée comme un identifiant de propriété valide. L'exemple ci-après crée une 
    // méthode mais cela fonctionne également pour les accesseurs, mutateurs et générateurs.
    [functionQuiRenvoieUnNomDePropriété()] (args) { ... }
};

En utilisant cette nouvelle syntaxe, on peut reécrire notre exemple de la manière suivante :

function Cercle(rayon) {
    this.rayon = rayon;
    Cercle.nbrDeCercles++;
}

Cercle.dessiner = function dessiner(cercles, canvas) {
 /* Code pour dessiner dans le Canvas */
}

Object.defineProperty(Cercle, "nbrDeCercles", {
    get: function() {
        return !this._count ? 0 : this._count;
    },

    set: function(val) {
        this._count = val;
    }
});

Cercle.prototype = {
    area() {
        return Math.pow(this.rayon, 2) * Math.PI;
    },

    get rayon() {
        return this._radius;
    },

    set rayon(radius) {
        if (!Number.isInteger(radius))
            throw new Error("Le rayon du cercle doit être un entier.");
        this._radius = radius;
    }
};

Si vous voulez pinailler, ce code n’est pas tout à fait identique au précédent. Les méthodes définies via la notation littérale sont configurables et énumérables, alors que les accesseurs et mutateurs définis précédemment ne sont ni configurables ni énumérables. Dans les faits, c’est quelque chose que l’on remarque rarement et j’ai décidé d’éluder cette question pour rester simple.

Quoi qu’il en soit, c’est déjà beaucoup mieux, n’est-ce pas ? Malheureusement, même armé de cette nouvelle syntaxe, on ne peut pas faire grand-chose pour la définition de Cercle puisque l’on doit toujours définir une fonction. Or, il n’est pas possible de définir les propriétés de cette fonction pendant qu’on définit la fonction elle-même.

Syntaxe de définition des classes

Bien que se soit mieux, ça ne satisfait toujours pas les personnes qui veulent un solution plus simple pour la conception orientée objet en JavaScript. Leur argument est le suivant : les autres langages possèdent une structure faite pour gérer la conception orientée objet : les classes

Ok. Ajoutons-donc les classes.

Ce que l’on veut, c’est un mécanisme qui nous permettra d’ajouter des méthodes à un constructeur identifié et d’ajouter des méthodes à son prototype, méthodes qui seront donc accessibles aux instances de la classe. Vu qu’on a déjà notre nouvelle syntaxe de définition des méthodes, autant l’utiliser. On a juste besoin d’un moyen de différencier les méthodes génériques, utilisables pour toutes les instances de classe, et les méthodes spécifiques à chaque instance. En C++ ou en Java, le mot-clé pour faire cette différence c’est static. Il en vaut bien un autre, utilisons celui-ci.

À présent, il serait bien utile d’avoir un moyen pour identifier la méthode qui, parmi toutes les autres, sera le constructeur de la classe. En C++ ou en Java, cette fonction a le même nom que la classe sans type de retour. Puisque JavaScript n’a, de toute façon, pas de type de retour et que l’on a besoin d’une propriété constructor pour des questions de rétro-compatibilité, on va appeler cette méthode constructor.

En faisant tout ça, on peut réécrire notre classe Cercle comme elle aurait toujours dû l’être :

class Cercle {
    constructor(rayon) {
        this.rayon = rayon;
        Cercle.nbrDeCercles++;
    };

    static dessiner(cercle, canvas) {
        // Code pour dessiner dans le Canvas
    };

    static get nbrDeCercles() {
        return !this._count ? 0 : this._count;
    };
    static set nbrDeCercles(val) {
        this._count = val;
    };

    surface() {
        return Math.pow(this.rayon, 2) * Math.PI;
    };

    get rayon() {
        return this._radius;
    };
    set rayon(radius) {
        if (!Number.isInteger(radius))
            throw new Error("Le rayon du cercle doit être un entier.");
        this._radius = radius;
    };
}

Wow ! Non seulement, nous avons pu regrouper tout ce qui est propre à notre Cercle mais en plus c’est si… simple. C’est clairement mieux que ce que nous avions au départ. Malgré tout, vous allez sans doute avoir des questions ou bien vous allez trouver certains cas particuliers. J’ai fait de mon mieux pour anticiper et répondre à certains d’entre eux :

  • Pourquoi des point-virgules ? — Dans une tentative de faire en sorte que ça ressemble à des classes « traditionnelles », nous avons choisi d’utiliser un séparateur classique. Vous n’aimez pas ça ? C’est optionnel, les delimiteurs ne sont pas obligatoires.
  • Comment faire si je ne veux pas de constructeur mais que je veux quand même ajouter des méthodes à une classe ? — Pas de problème. La méthode constructor est complètement facultative. Si vous n’en définissez aucune, ça va se comporter comme si vous aviez écrit constructor() {}.
  • Un constructeur peut-il être un générateur ? — Nope ! Ajouter un constructeur qui n’est pas une fonction normale engendrera une erreur TypeError. Ça vaut pour les générateurs mais également pour les accesseurs et mutateurs.
  • Puis-je définir un constructeur via un nom de propriété généré ? — Hélas non. C’est vraiment difficile a gérer, on n’a donc même pas essayé. Si vous définissez une méthode avec un nom de propriété généré qui se trouve être constructor, vous obtiendrez bien une methode appelé constructor mais ce ne sera pas le constructeur de la classe.
  • Que se passe-t-il si je change la valeur de Cercle ? Cela posera-t-il des problèmes si j’utilise new Cercle ? Non ! Comme pour les expressions de fonctions, les classes reçoivent une structure interne pour un nom donné. Cette structure ne peut pas être modifiée depuis l’extérieur, quelle que soit la valeur utilisée pour modifier la variable Cercle dans la portée courante. Cercle.nbrDeCercles++ du constructeur continuera de fonctionner normalement.
  • Certes, mais je pourrais passer un littéral objet directement comme argument d’une fonction. Ces nouvelles « classes » ne fonctionneraient plus, non ? – Heureusement, ES6 apporte également les expressions de classe. Celles-ci peuvent être nommées ou anonymes et elles se comporteront exactement comme ce qu’on a vu avant sauf qu’elles ne créeront pas de variable dans la portée de la déclaration.
  • Et au fait, qu’en est-il de l’énumérabilité et du reste ? – Les gens souhaitaient pouvoir installer des méthodes sur des objets mais n’obtenir que les propriétés de données lors d’une énumération, ce qui est logique. Pour cette raison, les méthodes ajoutées aux classes sont configurables mais pas énumérables.
  • Euh, attendez ? Où sont mes variables d’instances et mes constantes statiques ? – Bien vu. À l’heure actuelle, elles n’existent pas avec les classes ES6. Mais c’est bien parti pour les avoir par la suite : le sujet a déjà été abordé lors des réunions de spécifications par moi et plusieurs personnes favorables à l’idée d’avoir à la fois des valeurs statiques et des constantes utilisables avec cette syntaxe de classe. D’autres discussions sont à venir sur ce sujet.
  • OK, ça a l’air super ! Puis-je utiliser cette fonctionnalité ? – Pas exactement. Certaines prothèses existent (notamment grâce à Babel) et vous pouvez actuellement vous amuser avec les classes. Malheureusement, cela va prendre encore un peu de temps avant qu’elles ne soient implémentées au sein des principaux navigateurs. Tout ce dont nous avons parlé aujourd’hui a été implémenté par votre serviteur et est disponible dans la version Nightly de Firefox. Les classes sont implémentées dans Edge et Chrome mais ne sont pas activées par défaut. Il semblerait qu’à l’heure actuelle, il n’y ait pas d’implémentation pour Safari.
  • Java et C++ permettent de créer des sous-classes et utilisent le mot-clé super. Cet article n’en parle pas, est-ce que JavaScript permet de faire pareil ? Oui, toutefois c’est un sujet suffisamment vaste pour un autre billet. Nous reviendrons prochainement pour parler des sous-classes et explorer le pouvoir des classes JavaScript.

Je n’aurais pas été capable d’implémenter les classes sans l’aide apportée par Jason Orendorff et Jeff Walden et la relecture de code qu’ils ont effectuée.

La semaine prochaine, Jason Orendorff reviendra pour expliquer en détails les nouvelles instructions ES6 let et const.

Lire la suite »

La lettre ouverte de Chris Beard au directeur exécutif de Microsoft : un grand pas en arrière pour le choix et le contrôle de l'utilisateur

Mozilla Francophone

C’est déjà un énorme succès en termes de volume : de très nombreux utilisateurs de Windows passent et passeront bientôt à la version de Windows 10, dont Microsoft a proclamé largement que la mise à niveau serait gratuite. Mais malgré l’important investissement médiatique du marketing de Microsoft pour vanter les mérites de Windows 10 nombreuses sont les critiques qui se déchaînent :

…mais c’est sur un autre point crucial, celui de la maîtrise par l’utilisateur de ses choix de navigation, que Chris Beard, le directeur exécutif de Mozilla, interpelle publiquement sur le blog de Mozilla son homologue de Microsoft, dans le billet ci-dessous, traduit par MozFr.




chrisBeard.jpeg

Satya,

Je vous écris pour vous faire part d’un aspect très dérangeant de Windows 10. Pour être plus précis, le processus de mise à niveau semble avoir été conçu pour jeter à la poubelle le choix de navigation sur Internet effectué par vos clients, pour le remplacer par l’usage d’Internet que Microsoft veut leur imposer.

Dès que nous avons découvert que le processus de mise à niveau de Windows 10 dépouille les utilisateurs de leur choix en remplaçant efficacement les préférences des utilisateurs existantes pour le navigateur Web et d’autres applications, nous avons contacté votre équipe pour discuter de ce problème. Malheureusement, aucun progrès notable n’en est ressorti, d’où la présente lettre ouverte.

Nous apprécions qu’il soit encore techniquement possible de conserver les paramètres par défaut précédents des utilisateurs, mais la conception de l’ensemble de l’expérience de mise à niveau et les nouveaux paramètres par défaut des API ont été modifiés pour rendre l’opération moins évidente et plus difficile. À présent, les utilisateurs qui souhaitent réaffirmer les choix qu’ils ont fait dans les versions précédentes de Windows doivent effectuer deux fois plus de clics de souris et faire défiler des pages contenant des détails techniques. C’est déroutant, d’une navigation difficile et il est facile d’être perdu dans la manœuvre.

Mozilla existe pour apporter le choix, le contrôle et les possibilités qu’offre Internet à tout le monde. Nous élaborons Firefox et nos autres produits dans cet objectif. Nous avons créé Mozilla comme une organisation à but non lucratif pour cette raison. Et nous travaillons de toutes nos forces à faire que l’expérience de l’Internet, au-delà de nos produits, respecte ces valeurs. Parfois, nous voyons de grands progrès, où les produits à destination des consommateurs respectent les individus et leurs choix. Cependant, avec le lancement de Windows 10, nous sommes profondément déçus de voir Microsoft a fait un énorme pas en arrière.

Ces changements ne nous préoccupent pas en tant qu’organisation à l’origine de Firefox. Ils nous préoccupent parce qu’il y a des millions d’utilisateurs qui aiment Windows et dont les choix sont ignorés, et en raison de la complexité accrue qui fait obstacle à tous ceux qui décident de faire un choix différent de ce que préfère Microsoft.

Nous vous prions instamment de reconsidérer votre tactique commerciale sur ce point et à nouveau, de respecter le droit des utilisateurs à choisir et contrôler de leur expérience en ligne en rendant plus facile, plus évident et intuitif pour eux de confirmer les choix qu’ils ont déjà faits à travers l’expérience de mise à niveau. Il devrait être plus facile pour les gens de faire valoir de nouveaux choix et préférences, et pas seulement pour les autres produits Microsoft, à travers les paramètres par défaut des API et des interfaces utilisateur.

S’il vous plaît, donnez à vos utilisateurs le choix et le contrôle qu’ils méritent dans Windows 10.

Cordialement,

Chris Beard

Directeur exécutif de Mozilla

Lire la suite »

Ganesh et Pamela font découvrir Firefox OS à des milliers de Mauriciens

Firefox OS

En plein action de présentation de l'Orange Klif à MauriceDans notre série d’interviews de Mozilliens participant à la campagne de lancements de Firefox OS en Afrique et au-delà, nous vous proposons de découvrir Ganesh un des piliers de cet effort communautaire. Avec son épouse Pamela, Ganesh représente Mozilla à Maurice, cet État insulaire de l’Océan indien, et fait partie de la communauté noyau mise en place pour les lancements africains dont nous parlait Natalia le mois dernier. Ganesh sera d’ailleurs bientôt à Paris pour rencontrer et travailler avec ses homologues et les employés de Mozilla en charge des lancements.

Ganesh est tellement disert et passionné par Mozilla que nous vous proposons cette interview riche en deux parties dont voici la première :

Peux-tu nous décrire ton parcours avant Firefox OS ? Comment en es-tu venu à participer au projet Mozilla et quels étaient tes centres d’intérêt ?

Mon aventure avec Mozilla commence surtout avec le lancement du Firefox 1.0 en 1999. Auparavant, j’ai utilisé Mosaic qui était le premier navigateur web qui a été remplacé par la suite par Netscape. Comme j’étais toujours assoiffé de connaissances en informatique, je me suis inscrit pour recevoir les lettres de Mozilla. C’est ainsi que je suis de très près les activités de Mozilla et aussi les développements en cours. J’ai connu et utilisé toutes les versions de Firefox et j’ai même fait de la propagande pour Firefox et Thunderbird parmi les participants qui suivaient des formations dans mon institution – Institut de Santé de Maurice – où je travaille actuellement. Nous avons installé Firefox sur tous les ordinateurs de l’Institut et aussi ceux des professionnels de santé qui viennent de l’Afrique subsaharienne (anglophone et francophone) et qui suivent des formations à l’Institut. J’utilise Firefox et Thunderbird depuis déjà 15 ans. Il faut aussi mentionner que nous travaillons en étroite collaboration avec l’Agence universitaire de la francophonie dont notre institut est un établissement membre pour l’utilisation des logiciels libres.

Présentation de l'autocollant Firefox OS à MauriceCe n’est qu’en 2008 que je suis devenu un « Student Campus Rep » et c’est là que j’ai commencé à faire des activités comme « Spread Firefox » et des échanges avec Mozilla – Williams Reynolds était un des mes interlocuteurs. J’étais tellement impressionné et émerveillé par les activités de Mozilla que je suis devenu Mozilla Rep en 2012 et c’est ainsi que mon amour pour Mozilla dure toujours. Étant donné que Pamela, mon épouse, est aussi informaticienne, elle a créé son profil mozillien. En tant que Rep, avec la collaboration de Pamela, j’ai organisé des centaines d’événements à travers Maurice. Aujourd’hui, je suis ravi que la communauté Mozilla Maurice soit reconnue par Mozilla, ce qui pour moi est l’une des mes réalisations.

Peux-tu nous décrire le parcours qui t’a amené à participer au lancement de Firefox OS à Maurice et en Afrique ?

Suite à la création de la communauté noyau pour le lancement du Firefox OS en Afrique, j’avais reçu un mail envoyé par William Quiviger – un appel à intérêt pour faire partie de cette équipe. Étant donné que l’Île Maurice était parmi les 13 pays africains où Firefox OS serait lancé par le biais du smartphone Orange Klif, j’ai accepté de contribuer à cet événement de grande envergure. Voici les étapes avant le lancement :

Après ma première participation à la première visioconférence organisée par Ibrahima Saar (Mozilla) avec l’équipe de l’agence marketing RE-UP engagée par Mozilla, il fallait qu’on choisisse parmi les quatre équipes (rédaction, création, localisation et événements) constituées pour les besoins des activités pour ce lancement. Au début, je me suis joint aux équipes créative et localisation, mais finalement, comme je suis bilingue (anglais/français), on m’a demandé d’être le chef de fil de l’équipe de localisation coordonnée par l’agence. Au total, j’ai traduit plusieurs articles, le wiki et le blog du Firefox OS Africa.

Un plan de travail a été élaboré dans ce sens, suivi de visioconférences hebdomadaires chaque vendredi à la même heure. Entretemps, il y a eu des échanges de courriels avec les représentants de l’agence pour mettre en place le blog, le wiki, le site Firefox OS Africa, etc.

Événement Orange pour présenter le Klif à Maurice

Au même moment, j’ai eu une première rencontre de travail avec l’équipe marketing d’Orange Maurice pour arrêter la marche à suivre pour le lancement du Klif à Maurice. Mais auparavant en août 2014, à la suite d’un courriel d’Amira Dhalla (de Mozilla), j’avais rencontré le directeur exécutif du département du développement et business d’Orange Maurice. Il était étonné et émerveillé de voir un smartphone (Keon) qui tournait sous Firefox OS. Notre deuxième rencontre a eu lieu en octobre 2014 pour une présentation de Firefox OS. Ce n’est qu’après sa participation au Mobile World Congress de Barcelone en février, qu’on a repris contact pour préparer le lancement de l’Orange Klif à Maurice.

Justement qu’est-ce que Mozilla Maurice a fait avec Orange Maurice pour le lancement de Firefox OS ?

Mozilla Maurice à l'Orange Klif lor bazOrange Maurice organise en ce moment un événement (« Orange lor baz » qui veut dire « Orange sur place ») de proximité dans des régions rurales qui sont des endroits très importants du pays par rapport aux activités journalières, surtout les samedis. C’est un événement musical avec d’autres activités sous un chapiteau géant avec plusieurs stands où les gens pourraient voir de près les services offerts par Orange Maurice. À la demande d’Orange, Mozilla Maurice a fait son entrée à la deuxième promotion qui s’est tenue à Bambous qui se trouve à l’ouest du pays. Cet événement de grande envergure qui attire des milliers des gens (le 9 mai à St Pierre – 4 000, le 23 mai à Bambous – 7 000 aussi première promotion du Orange Klif, 6 juin Rivière des Anguilles – environ 4 000). Il nous reste encore trois événements de ce genre et on nous a aussi invité dans les Orange Shops qui se trouvent dans les centres-villes et centres commerciaux. Alors, nos Mozilliens qui participent et font le déplacement pour participer à ces événements, surtout pour la promotion de Firefox OS sur l’Orange Klif sont ma femme Pamela et bien sûr moi, Ganesh. Parmi les milliers des personnes qui visitent ces stands, il y en a beaucoup qui sont intéressés à nous écouter.

Quelques retours : il faut aussi mentionner qu’après la première promotion, il y avait une vente de 300 Klif ; les gens était si intéressés qu’ils voulaient acheter l’Orange Klif sur place, mais celui-ci n’était disponible que dans les boutiques. Par contre, il faut aussi souligner qu’à Maurice il y a plusieurs types des personnes avec des profils différents qui cherchent des produits haut de gamme avec des fonctionnalités précises. Nos dernières sorties ont été : samedi 26 juin à Flacq qui se trouve dans l’Est, samedi 11 juillet dans le Nord à Rivière du Rempart et jeudi 25 juillet dans le Sud à Mahebourg (dont vous voyez les photos ici).

Nous laissons Ganesh pour aujourd’hui, mais dès demain nous le retrouverons pour la seconde partie de cette interview avec les questions des Mauriciens, ce qu’ils peuvent trouver sur leur marché de téléphonie local, mais aussi les ambitions de notre Rep pour Maurice pour les communautés Mozilla de son environnement régional.


Vous pouvez retrouver l’actualité de Mozilla Maurice sur leur site et leur page Facebook. Retrouvez aussi Ganesh sur Twitter et l’actualité de Firefox OS en Afrique sur le blog multilingue Firefox OS Africa.


@Mozinet


Retrouvez la seconde partie de l’interview de Ganesh.

Retrouvez l’interview de Natalia (Mozilla) : Firefox OS en Afrique, c’est parti !

Crédit photos : Ganesh. Tous droits réservés.

Lire la suite »

Flipper avec Vanilla Pinball sur Firefox OS

Firefox OS

Flipper Vanilla Pinball dans Firefox OSVanilla Pinball est un flippeur des plus classiques, et vous allez pouvoir flipper sur votre Firefox OS.

L’intérêt du jeu réside en 2 points. Tout d’abord, vous devez réaliser le score le plus élevé et ensuite garder le plus longtemps la bille sur le plateau. Associer les deux vous permet de passer de longues heures de jeu que nous allons découvrir aujourd’hui.

Début

Écran de démarrage du flipper Vanilla Pinball dans Firefox OS

Lors du lancement du jeu, une petite publicité apparait sur tout l’écran. Elle vous oblige à être connecté sur Internet, mais disparait au bout de quelques secondes ou en fermant le placard.

Ensuite, un tour d’initiation vous montre comment jouer :

Flipper Vanilla Pinball dans Firefox OS – tour 1Flipper Vanilla Pinball dans Firefox OS – tour 2Flipper Vanilla Pinball dans Firefox OS – tour 3

Ce tutoriel se décompose de 3 parties : Tout d’abord en maintenant votre doigt sur le lance-billes vous donnez plus ou moins de force à la bille. Ensuite, vous tapez sur la gauche pour actionner la manette de gauche et sur la droite pour la manette de droite.

Jouer

Maintenant, vous êtes prêt à jouer. Vous disposez de trois billes pour obtenir le meilleur score.

Flipper Vanilla Pinball dans Firefox OSFlipper Vanilla Pinball dans Firefox OS

Après avoir armer votre lance-billes, la bille part et c’est à votre tour d’envoyer la bille au bon endroit pour obtenir un maximum de points.

Le plateau se découpe de la façon suivante :

Bumper du flipper Vanilla Pinball dans Firefox OS

Les bumpers sont des champignons ronds qui, lorsqu’ils sont touchés, vont repousser la bille. Ils sont au nombre de 2 à droite du plateau. Lorsque vous les touchez, le compteur augmente de 600 points.

Escargot du flipper Vanilla Pinball dans Firefox OS

L’escargot est un autre bumper et, suivant la puissance de la bille, celui-ci tournera sur lui même et votre bille pourra aussi bien se diriger vers la rampe ou l’attrape bille (à droite).

Rampe du flipper Vanilla Pinball dans Firefox OS

Pour accéder à la rampe, la bille doit obligatoirement passer par l’escargot. Ainsi, des points peuvent être récupérés si les cibles fixes sont allumées (voir un peu plus bas).

Cible du flipper Vanilla Pinball dans Firefox OS

Les cibles fixes sont des cibles statiques qui se contentent d’enregistrer le contact avec la bille. À chaque passage de la bille, vous gagnez 5 points.

Cible fixe gauche du flipper Vanilla Pinball dans Firefox OSCible fixe droite du flipper Vanilla Pinball dans Firefox OS

Deux autres cibles fixes sont disponibles, se trouvant proche des bascules. À chaque contact avec la bille, vous gagnez 20 points.

Cibles tombantes du flipper Vanilla Pinball dans Firefox OS

Les cibles tombantes sont des cibles qui disparaissent sous le plateau de jeu lorsqu’elles sont touchées. En toucher une série complète permet souvent de progresser dans le jeu. Lorsque toute une rangée de cibles tombantes a été touchée, celle-ci revient le plus souvent à sa position initiale.

Cibles fixes du flipper Vanilla Pinball dans Firefox OS

Les cibles fixes sont des cibles statiques qui se contentent d’enregistrer le contact avec la bille. Elles s’allument seulement si les 3 cibles tombantes ont été activés. Pour cela, vous n’aurez plus qu’à passer la bille dessus pour les éteindre et récupérer les 100 points.

Roue du flipper Vanilla Pinball dans Firefox OS

La roue est encore un autre bumper qui tourne sur lui même. À chaque contact avec la bille, elle tournera sur elle-même pour renvoyer votre bille dans une direction. Mais elle ne vous fera pas gagner de points.

Trou du flipper Vanilla Pinball dans Firefox OSTrou du flipper Vanilla Pinball dans Firefox OS

Sur le plateau, deux blocages sont disponibles. Vous devez envoyer votre bille dans un de ces deux trous. Si vous réussissez l’opération, celle-ci sera bloquée quelques secondes et vous fera gagner 50 points supplémentaires. Elle sera libérée dans l’autre trou, sur le principe d’un tunnel invisible

Fin de partie

La fin de la partie est une fin classique car vous le savez déjà, avec les flippers, vous ne gagnez jamais puisque ce n’est pas le but réel du jeu.

Fin de partie du flipper Vanilla Pinball dans Firefox OS

Par conséquent, la partie s’arrête quand votre bille quitte le plateau.

Ici, il y a deux façons de perdre la partie :

  • si elle tombe entre les deux bascules ;
  • si elle tombe dans le couloir de la mort, c’est à dire dans le vide.
Écran de « Game Over » du flipper Vanilla Pinball dans Firefox OS

Enfin, vous aurez droit à l’écran final appelé « Game Over » , qui vous communiquera le score de votre partie et le meilleur score.

Bien sûr, vous pourrez rejouer sans problème autant de fois que vous le voulez.

Au final

Vanilla Pinball est un flipper classique, mais les sensations sont bien présentes pour garder le plus longtemps possible la bille dans le plateau.

Au niveau des inconvénients, nous pouvons regretter les effets sonores et la fonction Tilt. Cependant, nous vous le proposons bien volontiers.


@hellosct1


Retrouvez l’appdujour de la semaine dernière : Game of Life, un simulateur de vie dans votre Firefox OS

Lire la suite »

MDN : dix ans d'évolution

Blog technique de MozFR

MDN fête ses 10 ans cette semaine. Ce billet, traduction du billet de Janet Swisher, est l’occasion de retracer l’historique de MDN et d’expliquer l’orientation du projet aujourd’hui.


MDN-10years_twitter-avatar_400x400px.pngCette semaine marque le dixième anniversaire du wiki MDN (Mozilla Developer Network). Ce billet explore les origines de MDN, ses évolutions diverses et la direction qu’il pourrait prendre.

(Ce billet est principalement basé sur une table ronde qui a eu lieu lors du week-end Hack On MDN d’avril 2015 à Berlin et sur le billet de Florian Scholz à propos de l’histoire de la documentation JavaScript sur MDN.)

Qu’est-ce que MDN aujourd’hui ?

Pour de nombreux développeurs web, MDN sert de référence pour le Web. C’est pour eux l’endroit où chercher des documents et où apprendre à propos des technologies du Web. MDN offre bien plus. C’est une ressource pour apprendre sur le Web, un endroit pour partager ses connaissances et son savoir. La force de MDN réside dans son ouverture : n’importe qui peut aider à améliorer les ressources, que ce soit petit à petit ou de façon conséquente. MDN encourage également la croissance des technologies web, là où elles n’étaient pas présentes auparavant.

MDN est une communauté de développeurs, d’écrivains techniques et de traducteurs. Quelques membres sont des employés de Mozilla mais cela ne représente qu’un sous-ensemble d’une plus grande communauté, formée de personnes qui apportent de petites ou de grandes contributions.

Le meilleur retour pour les contributeurs à MDN : ce que nous entendons quand nous discutons avec les développeurs qui nous disent à quel point ils apprécient MDN. Ce n’est pas « MDN, ouais, c’est pas mal » ou « c’est super.». La réponse que nous entendons le plus est « j‘adore MDN, c’est la meilleure ressource que je connaisse ». C’est extrêmement gratifiant de savoir que vous contribuez à quelque chose que les gens aiment vraiment.

MDN, pour qui ?

MDN s’adresse à différents publics :

  • tout d’abord aux développeurs web
  • aux personnes qui veulent apprendre le développement web
  • aux enseignants qui forment aux compétences et aux concepts du Web
  • aux développeurs des produits qui s’inscrivent dans l’écosystème Mozilla : les modules Firefox, les applications Firefox OS
  • aux développeurs qui contribuent au code de Mozilla

Les débuts de MDN

Le site qui est devenu MDN, developer.mozilla.org, ou « Devmo » fut d’abord une redirection vers une page pour les développeurs à partir du site mozilla.org. Plus tard, ce contenu fut déplacé sur Devmo. Il contenait principalement des informations à destination des développeurs qui contribuaient au code de Mozilla.

De la même façon que le projet Mozilla émergea des restes de Netscape, MDN tel que nous le connaissons démarra à partir de la documentation écrite initialement à Netscape. Le site connu sous le nom « Netscape DevEdge » documentait les technologies du Web comme JavaScript ou d’autres, implémentées comme produits Netscape. Après que Netscape ait été acquis par AOL, le site DevEdge fut fermé et les informations qu’il contenait disparurent du Web.

Mitchell Baker (à la présidence de Mozilla) et d’autres personnes de Mozilla travaillèrent avec AOL afin de trouver un arrangement pour publier le contenu de DevEdge. Mitchell Baker annonça cela en février 2005. Au même moment, Deb Richardson était recrutée pour migrer le contenu de DevEdge vers Devmo et s’occuper de ce contenu.

Mitchell et Deb décidèrent de placer ce contenu dans un wiki afin que quiconque puisse contribuer ouvertement pour mettre à jour et maintenir le contenu. Auparavant, le contenu de DevEdge était géré via un système de gestion de version CVS et publié sous forme d’un site statique. Utiliser un wiki pour publier de la documentation était un concept nouveau pour l’époque. Ça a pris un peu de temps pour que certains développeurs du projet Mozilla s’habituent à cette méthode. D’autres, en revanche, adoptèrent immédiatement cette aproche. Parmi les premiers contributeurs, nombreux furent les développeurs qui contribuaient au projet Mozilla par ailleurs.

Deb et quelques contributeurs, passèrent plusieurs mois à dénicher et à migrer le contenu utile de DevEdge, en travaillant sur un serveur de test. Cette tâche était toujours en cours lorsque le contenu fut migré sur le site Devmo qui prit alors le nom de « Mozilla Developer Center » (« MDC ») en juillet 2005. C’est cette date qui constitue le point de départ de ce qui s’appelle désormais Mozilla Developer Network.

L’évolution de la plateforme

Au cours de son histoire, MDN a vécu sur trois plateformes wiki différentes : tout d’abord MediaWiki puis MindTouch DekiWiki et maintenant Kuma, une plateforme développée par Mozilla. L’infrastructure technique du projet est intéressante, non seulement pour l’aspect technique mais aussi pour l’influence qu’elle a sur des structures sociales comme la communauté.

MediaWiki

Pour la première itération de MDC, la plateforme utilisée fut MediaWiki. Le logiciel open-source qui soutient Wikipédia. À l’époque, c’était la technologie wiki la plus robuste et la plus utilisée. Le projet Devmo découvrit petit à petit q’un logiciel conçu pour écrire une encyclopédie généraliste n’était pas nécessairement idéal pour écrire de la documentation technique à destination des développeurs. Les exemples de code, par exemple, n’étaient pas bien gérés et devenaient illisibles. Mozilla tenta de résoudre ces problèmes en créant son propre fork de MediaWiki, ce qui s’avéra en fin de compte assez difficile à maintenir.

Sur le plan des contributions, utiliser MediaWiki était un avantage car de nombreux techniciens étaient déjà familiers avec son fonctionnement. Cependant, le projet atteignit rapidement un seuil où il devint difficile de faire revenir les contributeurs. Ceci, associé aux problèmes techniques, entraîna la recherche d’une nouvelle plateforme plus facile d’utilisation.

DekiWiki

Après un processus d’évaluation pour voir l’ensemble des solutions « wiki » du marché (et pas seulement celles qui étaient open-source), le choix se porta sur DekiWiki, construit par MindTouch. Un avantage de DekiWiki était que le format source des articles était du HTML plutôt qu’un balisage de wiki. Ce choix était donc logique pour cibler les développeurs web : utiliser le même format pour la documentation que pour le Web. Cela nécessitait de migrer tout le contenu de MediaWiki, écrit dans un langage particulier, vers du HTML : cela constituait un projet de migration majeur. Le choix de DekiWiki fut annoncé en novembre 2007 et le site bascula vers cette solution en août 2008.

Bien que DekiWiki fut un produit de qualité, il y avait un biais important dans le processus de sélection et un grand groupe de participants manquait à l’appel : les contributeurs volontaires qui participaient au site. Le taux de contribution plongea car la communauté de contributeurs n’avait pas adopté la plateforme. Les communautés de localisation notamment, qui traduisent le contenu dans d’autres langues que l’anglais, furent sévèrement touchées. Elles avaient construit des outils et des processus qui fonctionnaient avec MediaWiki, outils et processus qui ne fonctionnaient plus avec DekiWiki. Après quelques mois, la plupart de ces groupes se dissolurent et décidèrent d’arrêter leurs contributions. Le résultat qui s’ensuivit fut que la documentation traduite devint immobile et de moins en moins à jour au fur et à mesure.

DekiWiki était aussi écrit en C# et donc conçu pour s’exécuter dans un environnement Microsoft .NET. Il y avait donc un écart avec l’infrastructure technique de Mozilla, basée sur Linux. Les tentatives pour faire fonctionner DekiWiki sur Mono aboutirent à de nombreuses instabilités, le site étant alors hors service pendant des jours voire des semaines à ce moment.

Suite à ces problèmes, l’équipe rechercha une autre solution. Les meilleurs candidats sur le marché restaient MediaWiki et DekiWiki. Alors que le contenu était désormais intégralement écrit en HTML, le remigrer vers la syntaxe MediaWiki n’était plus faisable. Aucun produit ne semblait répondre aux besoins spécifiques d’un site de documentation pour développeurs ouverts aux contributions, Mozilla décida donc de créer sa propre plateforme.

Kuma

La plateforme actuellement utilisée pour MDN s’appelle Kuma et est écrite en Python avec Django. Initialement, Kuma était un fork de Kitsune, la plateforme utilisée pour le site de support de Mozilla. Ce fork fut adapté pour les besoins d’un wiki destiné aux développeurs plutôt qu’aux utilisateurs des produits Mozilla. Note : « kitsune » signifie renard en japonais et « kuma » signifie ours (en effet tout le monde sait bien que les utilisateurs sont des renards et les développeurs des ours…).

Comme DekiWiki, Kuma utilise le format HTML pour stocker le contenu des articles. Pour passer de DekiWiki à Kuma, la migration consistait à migrer les scripts et macros utilisés sur le site. DekiWiki utilisait « DekiScript », un langage basé sur Lua alors que Kuma a vu naître KumaScript, basé sur JavaScript et Node.js. KumaScript a été créé et conçu par Les Orchard. Cela signifie qu’en plus de stocker ses documents en HTML, KumaScript est implémenté en utilisant les technologies documentées sur MDN, lesquelles sont connues des contributeurs. Il fut possible de migrer automatiquement 70% des macros, le reste a du être migré manuellement.

Lors du lancement de la plateforme Kuma, le but était d’obtenir les mêmes fonctionnalités qu’avec DekiWiki. Le contenu fut migré vers le nouveau système et les changements qui étaient apportés progressivement sur le serveur de production était également appliqués sur le serveur de test utilisant Kuma. De cette façon, l’instance de Kuma était synchronisée avec le serveur DekiWiki. Ainsi, bien que la migration effective prit des mois de travail pour lancer Kuma, le lancement réel passa presque inaperçu. Il suffit d’activer un interrupter et le traffic fut redirigé vers le nouveau site, sans aucun problème et sans même perturber les sessions des personnes connectées.

L’évolution de la communauté

Depuis le début, la communauté du site DevMo a grandi de façon organique en commençant avec des contributeurs déjà actifs sur d’autres parties du projet Mozilla. Comme pour d’autres domaines de Mozilla, la communication est basée sur une liste de diffusion (mailing list) et sur un canal de discussion IRC. Au milieu de l’année 2007, il y avait environ 250 contributions par mois. Comme évoqué auparavant, la migration vers DekiWiki a entraîné une chute phénoménale des contributions en localisation. Le nombre total de contributions déclina également.

mdn_doc_sprint.jpg Doc Sprint MDN à Paris en 2010

Afin que la communauté soit mieux engagée dans le projet, je (Janet Swisher) fus recrutée comme écrivain technique vers juin 2010. Cela me permit d’apporter l’expérience que j’avais de la documentation open source pour les développeurs. La méthodologie des « books sprints » utilisée par le projet FLOSS Manuals pour produire des manuels sur les logiciels libres en cinq jours ou moins fut particulièrement utile. Le premier « doc sprint » a eu lieu en octobre 2010 dans les bureaux de Mozilla Paris. Les docs sprint permettent de réunir les contributeurs à MDN, physiquement ou virtuellement, afin de travailler ensemble, de façon collaborative et concentrée pendant un week-end. Ces sprints eurent lieu tous les trimestres pendant environ trois ans. Récemment, ceux-ci ont évolué et ont lieu moins souvent mais durent plus longtemps, ils s’appellent désormais « Hack on MDN ». Afin que ces événements soit plus attractifs pour les développeurs, c’est l’occasion de travailler sur le contenu de la documentation mais aussi sur la plateforme et les outils.

11073502_781006205281080_8135317797319228200_o.jpg Présentation des sujets lors du week-end Hack On MDN à Berlin en 2015

De plus, la communauté se réunit régulièrement en ligne pour échanger des informations générales autour de MDN mais aussi pour suivre les différents projets. Ces activités communautaires, associées à la migration vers Kuma en 2012 ont entraîné une augmentation significative des contributions : il y en a, à l’heure actuelle, environ 1000 par mois.

L’évolution de la marque

MDC_wordmark.pngAu début, le site DevMo était connu sous le nom « Mozilla Developer Center ». Le site portait simplement ce nom et un style MediaWiki avait été choisi pour la mise en forme. Lors de la migration vers DekiWiki, le mot « Mozilla » fut placé en avant et suivi d’un « <developer center/> » qui indiquait un lien avec les langages du Web.

MDN_robodino_logo.pngEn septembre 2010, le nom du site changea « Mozilla Developer Center » devint « Mozilla Developer Network » ou MDN. Ce changement fut reçu avec un certain scepticisme de la part des développeurs qui utilisaient le site. Aujourd’hui, le terme MDN semble désormais globalement accepté. Le design visuel du site changea également pour adopter un thème plus sombre. MDN eut alors son propre logo « robot dino », une image qu’il n’avait jamais porté auparavant.

Ces changements visuels furent accompagnés de nouvelles fonctionnalités pour que le site soit plus que de la documentation. Une fonctionnalité réussie fut le « Demo Studio », une zone où les développeurs peuvent envoyer le code de leurs démos pour les partager et les montrer.

Lorsque MDN passa de DekiWiki à Kuma, l’apparence du site fut conservée et il y eut donc très peu de différences entre le site avant et après la migration. Après six à huit mois passés à résoudre des bugs liés à Kuma, un projet fut mis en place pour changer le design graphique mais aussi la structure du contenu. Ces modifications furent diffusées grâce à des flags destinés aux utilisateurs beta-testeurs. Ainsi, la plupart des utilisateurs voyait le site sans changement et les beta-testeurs pouvaient voir et tester le nouveau design et la nouvelle structure. Le « lancement » de ce nouveau design consista simplement à activer la fonctionnalité dans la base de données pour que celle-ci soit visibile de tout le monde.

Cette refonte apporta un nouveau logo, la tête de dinosaure sur fond de carte, mais aussi de nouvelles fonctionnalités structurelles comme la barre de navigation qui s’adapte en fonction du sujet de l’article. Pour les articles localisés, cette barre permet aussi d’indiquer quels articles sont traduits ou non. S’ils ne sont pas traduits, elle affiche un message invitant le lecteur à participer à cette traduction.

L’évolution du contenu

La date de naissance de MDN tel que nous le connaissons aujourd’hui correspond à l’acquisition et à la re-publication du contenu de Netscape DevEdge en 2005. Mais dans les premiers temps, le contenu était très orienté vers les produits et technologies Mozilla. Cette orientation ne concernait pas uniquement la documentation autour de XUL et des API internes à Mozilla mais aussi celle des technologies web qui étaient plus centrée autour de Mozilla et Firefox. On pouvait par exemple trouver de grandes bannières « fonctionne avec Firefox 2.0 » ou des explications sur le support d’une fonctionnalité dans Gecko en plein milieu d’un article relativement neutre.

Lorsque Mozilla s’engagea plus activement pour la communauté de MDN en 2010, les membres de la communauté exprimèrent l’idée que MDN devait être neutre (entre les différents navigateurs) afin de mieux servir les développeurs web. MDN pouvait ainsi devenir une ressource utile quel que soit le navigateur visé. Adopter cette stratégie demanda un effort conséquent pour retirer le contenu spécifique à Firefox au sein des articles portants sur les technologies standard du Web. Cela permit notamment de créer les tableaux de compatibilité qui existent aujourd’hui, chacun comportant des informations sur les principaux navigateurs. Le contenu de MDN devenant plus « agnostique », les autres organisations commencèrent à contribuer à MDN.

MDN : aujourd’hui et demain

En ce moment, deux projets ont un impact majeur sur MDN, à court ou à moyen terme. Ces projets sont la « Learning Area » d’une part et le projet des données de compatibilité d’autre part.

Les informations présentes sur MDN sont, depuis longtemps, utilisées par les développeurs web expérimentés. En ce qui concerne les débutants en revanche, MDN a manqué de contenu pour les accompagner. Le but de la Learning Area (Apprendre le Web) est de changer ça en apportant des tutoriels et d’autres ressources pour que les lecteurs de MDN puissent apprendre le développement web par eux-mêmes. Ce projet est une réponse aux sondages que nous avons proposés au public de MDN. Les résultats ont mis en avant le manque de contenu pour l’apprentissage et la découverte. Ce projet a démarré depuis un an et a vu la création d’un vaste glossaire sur les concepts liés au Web, de tutoriels s’inscrivant dans la littératie du Web développée par la Fondation Mozilla. La Learning Area est une excellente opportunité pour commencer à contribuer à MDN car nous avons à la fois besoin de débutants et d’experts pour enrichir ce projet.

Actuellement, les données de compatibilités des différents navigateurs sont gérées dans des tableaux présents sur les différentes pages. Les données qu’ils contiennent sont plutôt bonnes grâce aux nombreuses contributions. Toutefois, cette approche n’est pas durable ou maintenable. Par exemple, chaque tableau doit être répliqué puis maintenu sur les différentes versions localisées. Le projet des données de compatibilité vise à améliorer la qualité de ces données, de faciliter la contribution à ces données, de simplifier l’accès à ces données et de pouvoir réutiliser ces données grâce à un dépôt centralisé. Ce projet est géré en termes d’actions plutôt qu’avec un planning donné. Les contributions de tout bord sont bienvenues !

MDN dans 10 ans ?

MDN tel que nous le connaissons aujourd’hui est très différent de ce qu’il était 10 ans auparavant. Le Web a évolué, Mozilla a évolué et MDN a évolué. Les 10 ans à venir verront sans doute des changements encore plus forts. La vision d’un « cyber-espace » directement connecté va peut-être se concrétiser. Une chose est sûre, il y aura de plus en plus de développeurs web, de plus en plus de types d’appareils et de nouveaux standards à venir.

Certains éléments ne changeront pas : la mission de Mozilla sera toujours de travailler afin qu’Internet soit une ressource publique mondiale, ouverte et accessible à tous. MDN continuera d’être un moyen au service de cette mission en fournissant les ressources nécessaires pour que chacun puisse créer et développer sur cette plateforme qu’est le Web. Peu importe la façon dont son contenu est distribué, MDN continuera d’être le fruit des contributions d’une communauté mondiale de personnes passionnées par l’enseignement et le partage des connaissances autour du Web.

Lire la suite »

Mamie Fox a été aux RMLL 2015 à Beauvais

Firefox OS

RMLL 2015 : stand MozillaBonjour mes petits,

En ce mois de juillet, mon petit-fils le Fox m’a emmené aux Journées mondiales du logiciel libre, plus connu sous le nom de RMLL pendant une semaine. L’édition 2015 s’est déroulée dans la ville de Beauvais, dans l’Oise.

C’est la première fois que je laisse la maison une semaine complète pour un événement de cette ampleur. Les autres événements auxquels j’ai participé ne duraient que 2 ou 3 jours.

Ce fut donc pour ma part une première et je vais vous faire un petit résumé de l’ambiance chaleureuse que m’ont réservée tous les amis de mon petits-fils.

Je m’étais préparée la veille avec toujours des surprises pour mon petit-fils le Fox et tous ses amis. Je suis décidément une mamie gâteau.

Après un petit trajet en train en direction de Beauvais, je suis arrivée à l’entrée de ce rendez-vous comme vous pouvez la voir :

RMLL 2015 : bannière

En journée

Le déroulement des journées était très différent des uns des autres. Un programme était heureusement disponible pour tous à l’entrée.

Le week-end

Le week-end était ouvert principalement aux familles et à toutes les personnes curieuses. Ce fut donc super de voir tous ces gens.

RMLL 2015 : stand Mozilla

Heureusement que de nombreux Mozilliens étaient là pour répondre à tous les visiteurs.

Aussi, j’en ai profité pour visiter la ville et sa cathédrale puisque c’était juste à côté.

RMLL 2015 : village devant la cathédrale

J’ai même découvert un personnage étonnant : Richard Stallman, le « pape » du logiciel libre, qui a tenu un discours passionné et parfois amusant.

RMLL 2015 : Richard Stallman

La semaine

Dès le lundi, le décor était complément différent. Tous les stands ont été rassemblés à côté des salles des conférences programmées autour du Libre. C’était une bonne idée car comme ceci j’étais proche des dizaines de conférenciers.

De plus, de nombreux amis de mon petit-fils le Fox étaient présents pour se relayer à tenir le stand de Mozilla ; preuves à l’appui :

RMLL 2015 : stand Mozilla durant la semaine RMLL 2015 : stand Mozilla durant la semaine

… et répondre aux questions qui se sont enchainées : Comment, Firefox OS ça existe ? Nous pouvons le trouver dans les magasins ? Est-ce que cela fonctionne ? … Mais le Fox et ses amis ne se lassent pas de répondre aux mêmes questions.

En parallèle, des amis de mon petits-fils le Fox ont assuré les différentes conférences au programme :

Security and Privacy on the Web in 2015

François Marier de Mozilla a donnée une conférence en anglais sur le sujet très en vogue de la sécurité et de la vie privée sur le Web en 2015. En voici les diapos :

Security and Privacy on the Web in 2015 par Francois Marier

… et la video :

Embarquer le web dans un smartphone Firefox OS

Christophe Villeneuve, un ami du Fox, a donné une conférence sur le Web et Firefox OS, deux sujets qui lui tiennent à cœur. En voici les diapos :

Embarquer le web dans un smartphone Firefox OS par Christophe Villeneuve

… et la video :

Firefox OS et vie privée

Par ailleurs, nos amis mozilliens ont pu éviter une déconvenue aux visiteurs des RMLL. En effet, une des conférences programmée puis annulée en temps et en heure par un de nos amis mozilliens n’avait pas été retirée du programme. Au pied levé, nos amis mozilliens Christophe et Antoine l’ont reprise. Ils ont eu la lourde tâche de la préparer et de la jouer en direct. Mais, comme c’est un sujet qui tient à coeur nos Mozilliens, il leur fut très facile d’en parler, même si cela n’est jamais évident au premier abord. En voici les diapos :

Firefox os et vie privee par Christophe Villeneuve et Antoine Turmel

et la video :

Vous trouverez toutes les vidéos des conférences données à ces RMLL classées par thème sur le site officiel.

Enfin, je me suis promener dans les différents stands et j’ai pu récupérer quelques goodies :

RMLL 2015 : goodies

… et voici ce que l’on pouvait trouver sur le stand de Mozilla :

  • des téléphones et des tablettes pour voir et essayer Firefox OS,
  • des badges,
  • des stickers, des autocollants,
  • des cartes de visite avec le lien du blog de FirefoxOS,
  • des bracelets,
  • etc.

rmll2015_goodies_mozilla.jpg

Et même les fameux gâteaux Firefox en 3D que j’aime faire pour mon petit-fils et ses amis. Et ils ont été très appréciés.

Les soirées

Comme l’événement se déroulait sur une semaine, il a bien fallu occuper tout ce petit monde et surtout les amis de mon petit-fils le Fox pour éviter de les voir s’ennuyer ou de se lancer dans de longs débats interminables. Ils n’étaitent pas là non plus pour rester tout le temps enfermés dans leurs chambres.

Heureusement que mon petit-fils avait repéré que les organisateurs avaient prévus des activités nocturnes pour tous ceux le souhaitaient. Et ils avaient fait cela en grand.

De nombreux lieux étaient listés pour se retrouver autour d’une table pour boire un verre ou manger. Je partage avec vous quelques œuvres d’arts dont ils ont le secret :

RMLL 2015 : soirée RMLL 2015 : soirée RMLL 2015 : soirée

Mon petit-fils m’a emmenée voir des concerts de musique électro pendant cette semaine avec des groupes comme Hallogenerator et Superdirt2, qui était différents des concerts dont j’ai déjà pu vous parler. Je n’y serais pas allée de moi-même et j’aurais eu tort.

RMLL 2015 : concert RMLL 2015 : concert

J’ai même pu assister à des projections vidéo.

La dernière soirée nous fut proposé un repas, organisé à la mairie, pour nous montrer que ce n’était pas un vrai adieu, mais juste un au revoir.

Par ailleurs, comme les RMLL se déroulaient dans la ville de Beauvais, il était possible de se promener facilement dans le centre et même dans sa vieille ville ou encore dans sa cathédrale. À Beauvais, amis parisiens, il n’y a pas que l’aéroport…

Pour finir

La semaine a passé très vite car aux RMLL on n’a pas le temps de s’ennuyer. Le dernier jour, les discussions étaient orientées le plus souvent vers la prochaine ville qui recevrait ce rendez-vous autour du Libre en 2016, et la ville qui ressortait le plus souvent était la ville de… Nantes.

À très vite !


Mamie Fox


@hellosct1

Crédits illustrations : vidéos RMLL 2015 Beauvais sous licence Creative Commons By SA 4.0

Photos nos 1, 3, 6, 7, 9, 13 et 14 RMLL 2015 par Christophe Villeneuve. Tous droits réservés.

Photos nos 4 et 8 Retour des #RMLL2015 par Aldolinux. Tous droits réservés.

Photos April RMLL 2015 à Beauvais, n° 12 Fabien Rendu, et nos 2, 5, 10 et 11 Christian P. Momon, toutes sous triple licence : GFDL version 1.3 ou ultérieure, Creative Commons By SA version 2.0 ou ultérieure, Licence Art Libre version 1.3 ou ultérieure.

Lire la suite »

ES6 en détails : les proxies

Blog technique de MozFR

Suite de la traduction, qui continue la série d’articles de Jason Orendorff. L’article original se trouve ici. Vous pouvez retrouver les différents articles de la série grâce aux mots-clefs.

Merci à Ilphrin et Banban pour la traduction et la relecture !


ES6 en détails est une série d’articles décrivant les nouvelles fonctionnalités ajoutées au langage de programmation JavaScript avec la sixième édition du standard ECMAScript (ES6 en abrégé).

Voilà ce qu’on va s’amuser à construire aujourd’hui :

var obj = new Proxy({}, {
  get: function (target, key, receiver) {
    console.log(`accès à ${key} !`);
    return Reflect.get(target, key, receiver);
  },
  set: function (target, key, value, receiver) {
    console.log(`modification de ${key} !`);
    return Reflect.set(target, key, value, receiver);
  }
});

Pour un premier exemple, c’est un peu ardu. Je vais expliquer les différentes parties au fur et à mesure. Pour le moment, regardons l’objet que nous venons de créer :

> obj.count = 1;
    accès à count !
> ++obj.count;
    accès à count !
    modification de count !
    2

Qu’est-ce qui se passe ? Nous sommes en train d’intercepter l’accès aux propriétés pour cet objet. Nous surchargeons l’opérateur ..

Comment ça marche

La virtualisation est un des meilleurs tours de passe-passe en informatique. C’est une technique générique qui permet de faire des choses extraordinaires. Voici comment elle fonctionne :

  1. Prenez une photopower-plant.jpgCrédit photo : Martin Nikolaj Bech
  2. Dessinez une forme quelque part sur cette imagepower-plant-with-outline.png
  3. Maintenant, remplacez tout ce qu’il y a à l’intérieur (ou à l’extérieur) de cette forme avec quelque chose d’inattendu. Une seule règle à respecter : la règle de la compatibilité ascendante. Le remplacement effectué doit ressembler suffisamment à ce qu’il y avait avant pour qu’un observateur de l’autre coté de la ligne ne puisse pas remarquer que quelque chose a changé.wind-farm.pngCrédit photo: Beverley Goodwin.

Ce tour de passe-passe est également présenté dans des films comme The Truman Show et Matrix où une personne est à l’intérieur de cette forme et où le reste du monde a été remplacé par une illusion de normalité.

Pour respecter cette règle de la compatibilité ascendante, il faut que le contenu utilisé pour le remplacement soit soigneusement conçu. Cependant, le plus important dans ce tour de force est de dessiner la bonne forme.

Par « forme », j’entends ici la frontière d’une API. Une interface. Les interfaces définissent comment deux morceaux de code peuvent interagir entre eux et ce que chacun attend de l’autre. Si une interface est déjà conçue dans le système, la forme est déjà dessinée. Vous savez que vous pouvez remplacer un des deux côtés sans que l’autre soit impacté.

C’est quand il n’y a pas d’interface existante que vous devrez faire preuve de créativité. Certains des projets logiciels les plus géniaux ont vu le jour grâce à la création d’une frontière d’API qui n’existait pas auparavant. Créer cette interface de toute pièce constitue une prouesse d’ingénierie.

La mémoire virtuelle, la virtualisation des composants matériels, Docker, Valgrind, rr sont tous, sous certains aspects, des projets qui ont impliqué la création de nouvelles interfaces, parfois inattendues, au sein de systèmes existants. Dans certains cas, cela a pris des années, a nécessité de nouvelles fonctionnalités des systèmes d’exploitation voire de nouveaux composants matériels pour que la nouvelle frontière fonctionne correctement.

Les meilleures techniques de virtualisation apportent également une nouvelle compréhension de ce qui est virtualisé. Avant d’écrire une API pour interfacer quelque chose, il faut le comprendre. Une fois que vous l’avez compris, vous pouvez réaliser des prouesses.

ES6 introduit le support de la virtualisation pour le concept primordial de JavaScript : l’objet.

Qu’est-ce qu’un objet ?

Sérieusement, réfléchissez-y pendant quelques minutes avant de poursuivre. Continuez cet article lorsque vous avez construit votre définition de ce qu’est un objet. thinker.jpgCrédit photo : Joe deSousa.

Cette question est trop difficile ! Je n’ai jamais entendu de définition complètement satisfaisante.

Est-ce bien surprenant ? La définition de concepts fondamentaux est toujours un exercice périlleux — prenez certaines des premières définitions des Éléments d’Euclide par exemple. La spécification du langage ECMAScript n’a donc pas à rougir quand elle définit un objet comme « un membre du type Object » (ce qui nous aide beaucoup).

Plus loin, la spécification ajoute « Un objet est une collection de propriétés ». Pas mal. Si vous voulez une définition, celle-ci pourra faire l’affaire pour le moment. Nous y reviendrons plus tard.

Plus haut, j’ai dit que pour écrire une API afin d’interfacer quelque chose, il faut le comprendre. D’une certaine façon, je vous ai promis que nous suivrons ce chemin, que nous comprendrons mieux ce que sont les objets et que nous ferons des choses formidables.

Prenons donc le chemin emprunté par le comité de standardisation ECMAScript et voyons ce qu’il faudrait pour définir une API, une interface, pour les objets JavaScript. De quels types de méthodes avons-nous besoin ? Que peuvent faire les objets ?

D’une certaine façon, cela dépend de l’objet. Les objets Element du DOM peuvent réaliser certaines choses, les objets AudioNode peuvent faire d’autres choses… Toutefois, il y a quelques capacités partagées par tous les objets :

  • Les objets ont des propriétés. Vous pouvez accéder à ces propriétés, les initialiser et les modifier, les supprimer et ainsi de suite.
  • Les objets ont des prototypes. C’est grâce à eux que l’héritage fonctionne en JavaScript.
  • Certains objets sont des fonctions ou des constructeurs. Vous pouvez les appeler.

Tout ce que les programmes JavaScript font avec les objets (ou presque) est fait en utilisant les propriétés, les prototypes et les fonctions. Même le comportement spécial des objets Element ou AudioNode provient des méthodes appelées qui sont des propriétés fonctionnelles héritées.

C’est pour cette raison que lorsque le comité de standardisation a défini un ensemble de 14 méthodes internes, l’interface commune à tous les objets, celles-ci se concentraient sur ces trois aspects fondamentaux.

La liste complète est décrite dans les tableaux 5 et 6 du standard ES6. Ici, je n’en décrirai que quelques-unes. Les doubles crochets, [[ ]], un peu étranges indiquent qu’il s’agit de méthodes internes, inaccessibles via du code JavaScript ordinaire. Ces méthodes ne peuvent pas être appelées, supprimées ou surchargées.

  • obj.[[Get]](key, receiver) – Obtenir la valeur d’une propriété.

    Appelée lorsque le code JS exécute : obj.prop ou obj[key].

    obj est l’objet dans lequel nous cherchons à accéder à une propriété, receiver est l’objet sur lequel nous commençons à chercher cette propriété. Parfois, nous voulons rechercher dans plusieurs objets. obj peut être un objet sur la chaîne de prototypes de receiver.

  • obj.[[Set]](key, value, receiver) – Affecter une propriété à un objet.

    Appelée lorsque le code JS exécute : obj.prop = valeur ou obj[key] = valeur.

    Lors d’une affectation comme obj.prop += 2, la méthode [[Get]] est appelée en premier et ensuite la méthode [[Set]]. De même pour ++ et --.

  • obj.[[HasProperty]](key) – Teste l’existence d’une propriété.

    Appelée lorsque le code JS exécute : key in obj.

  • obj.[[Enumerate]]() – Liste les propriétés énumérables de l’objet.

    Appelée lorsque le code JS exécute : for (key in obj) …

    Ceci retourne un objet itérateur, et c’est ainsi qu’une boucle for-in obtient les noms des propriétés d’un objet.

  • obj.[[GetPrototypeOf]]() – Retourne le prototype de l’objet.

    Appelée lorsque le code JS exécute : obj.__proto__ ou Object.getPrototypeOf(obj).

  • functionObj.[[Call]](thisValue, arguments) – Appelle une fonction.

    Optionnelle : tous les objets ne sont pas des fonctions.

    Appelé lorsque le code JS exécute : fonctionObj() ou x.methode().

  • constructorObj.[[Construct]](arguments, newTarget) – Invoque un constructeur.

    Appelée lorsque le code JS exécute : new Date(2890, 6 2), par exemple.

    Optionelle : tous les objets n’ont pas de constructeur.

    L’argument newTarget joue un rôle pour les sous-classes. Nous l’aborderons dans un prochain billet.

Vous pouvez peut-être deviner certaines des sept autres méthodes.

Avec le standard ES6, à chaque fois que c’est possible, le moindre petit morceau de syntaxe ou de fonction intégrée qui manipule des objets est spécifié selon l’une des 14 méthodes internes. ES6 marque une limite claire autour des mécanismes d’un objet.. Les proxies vous permettent de remplacer ces mécanismqes standard avec du code JavaScript arbitraire.

Dans un moment, lorsque nous commencerons à parler de surcharger ces méthodes internes, souvenez-vous, nous parlerons de surcharger le comportement de la syntaxe comme obj.prop, des fonctions natives comme Object.keys(), etc.

Proxy

ES6 définit un nouveau constructeur global : Proxy. Il prend deux arguments, un objet cible (target) et un objet gestionnaire (handler). Un exemple très simple pourrait être :

var target = {}, handler = {};
var proxy = new Proxy(target, handler);

Pour le moment, laissons l’objet gestionnaire de côté et concentrons-nous sur les liens entre le proxy et la cible.

Le comportement du proxy peut être expliqué en une phrase : toutes les méthodes internes du proxy sont retransmises à la cible. Par exemple, si quelque chose appelle proxy.[[Enumerate]](), cela renverra juste target.[[Enumerate]]().

Essayons. Utilisons une instruction qui entraîne l’appel de proxy.[[Set]]()

proxy.couleur = "rose";

OK, que s’est-il passé ? proxy.[[Set]]() devrait avoir appelé target.[[Set]]() et cela devrait avoir créé un nouvelle propriété sur target. Est-ce bien le cas ?

> target.couleur
    "rose"

Ça a bien fonctionné. Il en va de même pour les autres méthodes internes. Le proxy, dans la plupart des cas, se comportera exactement comme la cible.

Il y a certaines limites à cette illusion. Vous aurez notamment proxy!==target. Un proxy pourra également recaler certaines opérations à la suite des vérifications de types alors que celles-ci auraient fonctionné pour la cible. Par exemple, si la cible d’un proxy est un Element du DOM, le proxy ne sera pas vraiment un Element. Une opération comme document.body.appendChild(proxy) échouera avec une exception TypeError.

Les gestionnaires de proxies

Revenons vers l’objet gestionnaire (handler). C’est cet objet qui rend les proxies utiles.

Les méthodes de l’objet gestionnaire peuvent surcharger n’importe quelle méthode interne du proxy.

Par exemple, si vous voulez intercepter toutes les tentatives de modification/affectation de propriétés pour un objet, il vous suffit de définir une méthode handler.set() :

 
var target = {};
var handler = {
  set: function (target, key, value, receiver) {
    throw new Error("Merci de ne pas modifier de propriétés sur cet objet.");
  }
};
var proxy = new Proxy(target, handler);
 
> proxy.nom = "angelina";
    Error: Merci de ne pas modifier de propriétés sur cet objet.

La liste complète des méthodes pour les gestionnaires est documentée sur la page MDN de Proxy. Il y a 14 méthodes, chacune de ces méthodes faisant écho aux 14 méthodes internes définies dans ES6.

Toutes les méthodes pour les gestionnaires sont optionnelles. Si une méthode interne n’est pas interceptée par le gestionnaire, elle est simplement transmise à la cible comme nous l’avons vu auparavant.

Exemple : objets auto-généres

Nous en savons désormais assez sur les proxies pour les utiliser à des fins étranges et réaliser quelque chose qui est impossible sans les proxies.

Voici notre premier exercice : créer une fonction Arbre() qui peut faire ceci :

> var arbre = Arbre();
> arbre
    { }
> arbre.branche1.branche2.brindille = "vert";
> arbre
    { branche1: { branche2: { brindille: "vert" } } }
> arbre.branche1.branche3.brindille = "jaune";
    { branche1: { branche2: { brindille: "vert" },
                 branche3: { brindille: "jaune" }}}

Observez ici comment tous les objets intermédiaires branche1, branche2 et branche3 sont créés automatiquement, presque de façon magique, quand ils sont nécessaires. Plutôt pratique n’est-ce pas ? Comment cela pourrait-il fonctionner ?

Jusqu’à maintenant, il n’existait aucun moyen pour que cela puisse fonctionner. Cependant, avec les proxies, il suffit de quelques lignes de code. Il suffit de raccorder arbre.[[Get]](). Si vous voulez un défi, vous pouvez essayer d’implémenter ceci avant de continuer votre lecture. maple-tap.jpgPas la meilleure façon de se raccorder sur un arbre en JS. Crédit photo : Chiot’s Run.

Voici ma solution :

function Arbre() {
  return new Proxy({}, handler);
}
 
var handler = {
  get: function (target, key, receiver) {
    if (!(key in target)) {
      target[key] = Arbre();  // créer un sous arbre automatiquement
    }
    return Reflect.get(target, key, receiver);
  }
};

Notez l’appel à Reflect.get() à la fin de l’exemple. Il s’agit d’un besoin extrêmement commun, lorsqu’on utilise les méthodes d’un gestionnaire de proxy, que de vouloir dire « maintenant, je souhaite simplement appliquer le comportement par défaut à l’objet cible ». Pour cela, ES6 définit un nouvel objet Reflect qui possède 14 méthodes que l’on peut utiliser à cet effet.

Exemple : une vue en lecture seule

Je pense que j’ai pu donner une fausse impression en indiquant que les proxies seraient simples à utiliser. Prenons un exemple supplémentaire pour voir si c’est bien le cas.

Cette fois, le devoir est plus complexe : nous devons implémenter une fonction readOnlyView(object), qui prend n’importe quel objet et qui renvoie un proxy qui se comporte exactement comme cet objet sauf qu’il est impossible de le modifier. Elle se comporterait de la façon suivante :

> var newMath = readOnlyView(Math);
> newMath.min(54, 40);
    40
> newMath.max = Math.min;
    Error: impossible de modifier, vue en lecture seule
> delete newMath.sin;
    Error: impossible de modifier, vue en lecture seule

Comment implémenter cette fonction ? La première étape est d’intercepter toutes les méthodes internes qui pourraient modifier l’objet cible si nous les laissions passer. Il y en a cinq.

function NOPE() {
  throw new Error("impossible de modifier, vue en lecture seule");
}
 
var handler = {
  // On surcharge les cinq méthodes qui peuvent modifier.
  set: NOPE,
  defineProperty: NOPE,
  deleteProperty: NOPE,
  preventExtensions: NOPE,
  setPrototypeOf: NOPE
};
 
function readOnlyView(target) {
  return new Proxy(target, handler);
}

Y a-t-il des failles à ce système ?

Le plus problème est que la méthode [[Get]], ainsi que d’autres, peuvent toujours renvoyer des objets modifiables. Par exemple si un objet x est une vue en lecture seule, x.prop pourrait être modifié. C’est une faille digne de ce nom.

Pour corriger cela, nous devons ajouter une méthode handler.get() :

var handler = {
  ...
 
  // On enveloppe les autres résultats dans des vues en lecture seule.
  get: function (target, key, receiver) {
    // On applique le comportement par défaut.
    var result = Reflect.get(target, key, receiver);
 
    // On s'assure de ne pas renvoyer d'objet modifiable !
    if (Object(result) === result) {
      // result est un object.
      return readOnlyView(result);
    }
    // result est une valeur primitive, déjà non modifiable.
    return result;
  },
 
  ...
};

Ce n’est pas suffisant non plus. Il faudra un code similaire pour les autres méthodes, dont getPrototypeOf et getOwnPropertyDescriptor.

D’autres problèmes se posent ensuite. Lorsqu’un accesseur (getter) ou une méthode est appelé via ce type de proxy, la valeur passée à l’accesseur ou à la méthode sera généralement le proxy lui-même. Or, comme nous l’avons vu auparavant, de nombreux accesseurs et méthodes vérifient le type, ce qui empêchera le proxy de passer. Dans ces cas-là, il serait plus pratique de substituer le proxy par l’objet cible. Pouvez-vous trouver comment faire ?

La leçon à tirer de ces exemples : c’est simple de créer un proxy mais difficile de créer un proxy dont le comportement est intuitif.

Informations diverses et variées

  • À quoi les proxies sont-ils vraiment utiles ?

    Il sont certainement utiles lorsqu’on souhaite observer ou enregistrer les accès à un objet. Ils seront pratiques pour le débogage. Les frameworks de test pourraient les utiliser pour simuler les vrais objets.

    Les proxies sont utiles si vous avez besoin d’un comportement qui n’est pas à la portée d’un objet ordinaire : peupler des propriétés de façon automatique est un exemple.

    J’ai horreur de dire ça mais l’une des meilleure façon de voir ce qui se passe dans du code qui utilise des proxies… c’est d’envelopper le gestionnaire de proxy dans un autre proxy qui affiche des informations dans la console à chaque fois qu’une méthode du gestionnaire est appelée.

    Les proxies peuvent être utilisés pour restreindre l’accès à un objet comme on l’a vu avec readOnlyView. C’est un cas d’utilisation assez rare pour des applications mais Firefox utilise les proxies en interne afin d’implémenter la sécurité des frontières entre les différents domaines. Les proxies sont un élément clé de notre modèle de sécurité.

  • Proxies ♥ WeakMaps. Dans notre exemple sur readOnlyView, nous avons créé un nouveau proxy à chaque fois que nous accédions à un objet. Il serait possible d’économiser beaucoup de mémoire en mettant les différents proxies créés en cache dans une WeakMap. De cette façon, peu importe le nombre de fois qu’un objet est passé à readOnlyView, seul un proxy sera créé pour celui-ci.

    Vu sous cet angle, les proxies sont l’une des raisons d’utiliser WeakMap.

  • Les proxies révocables. ES6 définit également une autre fonction : Proxy.revocable(target.handler) qui crée un proxy de la même façon que new Proxy(target, handler), sauf que ce proxy peut être révoqué plus tard (Proxy.revocable renvoie un objet avec une propriété .proxy et une méthode .revoke). Une fois qu’un proxy est révoqué, il ne fonctionne plus, toutes ses méthodes internes lèveront des exceptions.
  • Les invariants d’objets. Dans certaines situations, ES6 requiert des résultats renvoyés par les méthodes du gestionnaire de proxy qui soient cohérents avec l’état de l’objet cible. Cette condition existe afin d’appliquer les règles qui concernent l’immuabilité parmi les différents objets, y compris les proxies. Par exemple, un proxy ne peut pas prétendre être inextensible si l’objet cible n’est pas réellement inextensible.

    Les règles exactes sont trop complexes pour être vues ici, mais si vous obtenez un message d’erreur qui ressemble à “proxy can’t report a non-existent property as non-configurable” (“le proxy ne peut pas signaler qu’une propriété inexistante n’est pas configurable”), ce sera pour cette raison. Le remède le plus probable est de modifier ce que le proxy prétend sur lui-même. Une autre possibilité est de modifier l’objet cible au vol afin que celui-ci reflète l’état du proxy.

Alors finalement, qu’est-ce qu’un objet ?

Je pense que nous en étions resté à « Un objet est une collection de propriétés ».

Je ne suis pas entièrement satisfait de cette définition, même en considérant comme acquis qu’on les intègre aux prototypes et aux appels. Je pense que le mot « collection » est exagéré vu comment un proxy ressemble à une collection. Ses méthodes de manipulation pourraient faire n’importe quoi. Elles pourraient retourner un résultat aléatoire.

En déterminant ce qu’un objet peut faire, en standardisant ces méthodes et en ajoutant la virtualisation en fonction prioritaire que tout le monde peut utiliser, le standard ECMAScript a ouvert le champ des possibles.

Les objets peuvent désormais être presque n’importe quoi.

Peut-être que la réponse la plus honnête à la question « Qu’est-ce qu’un objet ? » est maintenant de reprendre les 12 méthodes internes comme définition. Un objet est quelque chose dans un programme JS qui a une opération [[Get]], un opération [[Set]] et ainsi de suite.

Est-ce que nous comprenons mieux les objets avec tout ça ? Je n’en suis pas si sûr ! Avons-nous fait des choses étonnantes ? Certainement. Nous avons fait des choses qui auraient été auparavant impossibles en JS.

Puis-je utiliser les proxies dès maintenant ?

Non ! Seul Firefox supporte les proxies et il n’existe pas de prothèse (polyfill) correspondante. Vous êtes donc libre d’expérimenter avec eux. Vous pouvez créer un projet qui crée une galerie des glaces avec des milliers d’exemplaires pour chaque objet pour rendre le tout inextricable et indébogable, il n’y a aucun risque que ce code puisse passer en production… pour le moment.

Les proxies furent d’abord implémentés en 2010 par Andreas Gal dont le code a été revu par Blake Kaplan. Le comité de standardisation a ensuite totalement revu la conception de cette fonctionnalité. C’est Eddy Bruel qui a implémenté cette nouvelle spécification en 2012.

J’ai implémenté Reflect et ce code a été revu par Jeff Walden. Il sera dans Firefox Nightly à partir de ce week-end (NdT : le week-end du 18-19 juillet 2015). Il ne manque que Reflect.enumerate() qui n’est pas encore implémenté.

La prochaine fois, nous aborderons la fonctionnalité la plus controversée d’ES6, et qui mieux que la personne qui les a implémentées dans Firefox pour vous en parler ? (Re)joignez-nous la semaine prochaine avec Eric Faust, ingénieur Mozilla pour présenter les classes ES6 en détails.

Lire la suite »