mozFR

Mozilla Francophone

Firefox OS arrive
en France !
En savoir plus »

Mamie Fox sera à la Braderie de Lille le week-end prochain

Firefox OS

Braderie de Lille 2014 : stand MozillaChers amis,

Le week-end prochain, je serai avec mon petit-fils le Fox chez les Ch’ti. En effet, nous allons aider les Mozilliens à tenir le stand de Mozilla à la Braderie de Lille. Mozilla est traditionnellement présent lors de cette manifestation populaire, commerciale et festive majeure de la métropole nordiste.

Un tas de moules devant Aux MoulesMon petit-fils n’a de cesse de me parler des tas de moules, de la foule et du public bien différent de celui que nous avons pu rencontrer lors des salons pour libristes. Tout le week-end, vous pourrez nous trouver dans le « village solidaire », place du Vieux Marché aux Chevaux (pas loin de la Grand’ Place), à l’invitation de Chtinux. Ce village rassemble de nombreuses associations avec plusieurs stands dédiés à l’informatique. Nous serons en compagnie de représentants d’Ubuntu-fr, de la FFDN/Neutrinet ou encore de La Quadrature du Net.

Braderie Lille 2014 : Mozilla sur le stand Chtinux

Le Fox m’a bien précisé que ce n’était pas le village associatif que vous pouvez voir sur les plans de la Braderie, mais le village de « La braderie solidaire » qui fête cette année ses 10 ans et s’étend désormais au-delà de la place du Vieux Marché aux Chevaux à la rue du Court Debout et à la rue du Bleu Mouton. Nous serons en bonne compagnie avec des associations régionales de l’économie sociale et solidaire, de la citoyenneté et de l’écologie, de restaurateurs bio de la région et de micro entreprises ou petites structures commerciales agissant dans le domaine de l’agriculture biologique et/ou du commerce équitable.

Braderie de Lille 2014 : bénévole Mozilla

La braderie a lieu sur des centaines de kilomètres de trottoirs dans le centre-ville très beau de Lille dédié à des millions de bradeux (2 à 3 millions selon les années). En plus de la bière et des moules-frites, des commerces bradant leur stocks, une foule compacte fouine dans le plus grand « marché aux puces » d’Europe où 10 000 exposants vendent tout et rien.

Foule rue Faidherbe lors de la Braderie de Lille 2005

Avec nos amis bénévoles de Mozilla fr et Mozilla Belgium, nous présenterons le système d’exploitation mobile de Mozilla en français, en néerlandais et en anglais. Le samedi 5 septembre, il y aura des bénévoles de 12 h à 19 h et le dimanche 6 de 10 h à 19 h.

Le Mozilliens locaux ont des comptes Twitter sur lesquels ils pourront publier des nouvelles au cours du week-end avec le hashtag #mozbdl2015 que vous pouvez reprendre :

Foule entre les stands de la Braderie de Lille 2012

Voici quelques liens pour préparer votre visite :

Fin de braderie, avenue du peuple belge, 2010

Fin de braderie avenue du Peuple Belge

Alors, on vous y verra ?

Mamie Fox


L’année dernière : Braderie 2014

Le précédent article de Mamie Fox : Mamie Fox a été aux RMLL 2015 à Beauvais


Crédit illustrations : Photos nos 1, 3 et 4 de Mozilla à la Braderie 2014, Quentin Lamamy. Tous droits réservés.

Photos nos 2 et 6, Braderie de Lille 2010 de Frédérique Voisin-Demery, sous licence CC By 2.0

Photo n° 5, Rue Faidhebre, Braderie de Lille 2005 de Steff, sous licences CC By-SA 1.0, CC By-SA 3.0 et GNU Free Documentation License, version 1.2

Photo n° 6, Braderie de Lille de 2012, Jérémy-Günther-Heinz Jähnick, sous licence CC-By-SA 3.0.

Lire la suite »

Mozilla : “Firefox + Vous” d'août 2015 – Newsletter francophone

Mozilla Francophone

Un peu de magie ?

baguetteMagique.jpg

Nous vous présentons Emma (c’est la petite-fille de Mamie Fox paraît-il). Elle a un fluide magique qui lui permet de retrouver partout ses données personnelles. Elle vous donne l’astuce dans le numéro du mois d’août.

Recevez le numéro de septembre 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 : le nouveau Firefox, Sync, des thèmes carrément cosmiques, Firefox Friends et les rubriques habituelles !

Crédit image : Carol Alejandra Hernández Sánchez CC BY-2.0

Lire la suite »

ES6 en détails : l'avenir

Blog technique de MozFR

Suite et fin de la la traduction, qui clôture 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 à 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é).

L’article de la semaine dernière apportait la dernière touche à ce passage en revue des nouvelles fonctionnalités apportées par ES6, débuté il y a quatre mois.

Dans ce billet, nous aborderons une douzaine d’autres fonctionnalités dont nous n’avons pas pu discuter avant. Considérez cela comme la fin du tour de la maison et la visite de certaines petites pièces situées à l’étage. Ou seraient-ce des cavernes entières cachées dessous… Si vous n’avez pas lu les autres articles, allez-y. Commencer la visite par ici n’est peut-être pas la meilleure façon de procéder. typedarrays.png « Sur votre gauche, vous pouvez observer les tableaux typés dans leur milieu »

Un dernier avertissement : parmi les fonctionnalités dont nous allons discuter, beaucoup ne sont pas encore implémentées.

OK. Commençons.

Les fonctionnalités que vous utilisez peut-être déjà

ES6 standardise certaines fonctionnalités qui étaient présentes dans d’autres standards ou qui étaient largement implémentées mais non standards.

  • Les tableaux typés, ArrayBuffer et DataView. Tout ceux-ci étaient standardisés dans le cadre de WebGL et ont depuis été utilisés dans de nombreuses autres API : Canvas, l’API Web Audio, WebRTC. Ces objets sont pratiques si vous devez manipuler de grands volumes de données binaires ou numériques.

    Par exemple, si vous souhaitez disposer d’un contexte de rendu pour Canvas et que vous êtes en forme, vous pouvez l’implémenter vous-même !

    var context = canvas.getContext("2d");
    var image = context.getImageData(0, 0, canvas.width, canvas.height);
    
    var pixels = image.data;  
    // un objet Uint8ClampedArray
    // ... Votre code !
    // ... On bidouille les bits bruts dans `pixels`
    // ... puis on les écrit sur le canevas :
    context.putImageData(image, 0, 0);
    

    Lors de la standardisation, les tableaux typés se sont vus agrémentés de méthodes comme .slice(), .map() et .filter().

  • Les promesses (objets Promise). Écrire un seul paragraphe sur les promesses, c’est un peu comme manger une seule chips. D’une part c’est très difficile et d’autre part ça n’a aucun intérêt. Que dire… Les promesses forment une brique pour programmer de façon asynchrone en JavaScript. Elles représentent des valeurs qui seront disponibles plus tard. Par exemple, lorsque vous appelez fetch(), plutôt que de bloquer le reste, la fonction renvoie immédiatement un objet Promise. L’action de fetch se passe en arrière-plan et vous pourrez vous en servir quand la réponse arrivera. Les promesses sont plus riches que les fonctions de rappel (callback) car elles peuvent être enchaînées les unes après les autres. Ce sont aussi des valeurs de premier rang avec des opérations intéressantes disponibles et la gestion des erreurs est beaucoup plus simple à mettre en œuvre. Les promesses peuvent être émulées avec des prothèses dans le navigateur. Si vous ne connaissez pas déjà les promesses, vous pouvez lire l’article, très complet, de Jake Archibald, traduit par Christophe Porteneuve sur le sujet.

  • Les fonctions dans les portées de bloc. Voici une fonctionnalité que vous ne devriez pas utiliser même si vous l’avez déjà fait… peut-être sans le vouloir.

    Depuis ES1 et jusqu’à ES5, ce code était, techniquement, illégal :

    if (temperature > 30) {
      function rafraichir() {
        return ventilo.allumer().then(boireLimonade);
      }
      rafraichir();
    }
    

    La déclaration de fonction, à l’intérieur d’un bloc if, était normalement interdite. Elle n’était autorisée qu’au plus haut niveau ou dans le bloc le plus externe de la fonction.

    Mais ça fonctionnait avec les principaux navigateurs. À peu près.

    Et pas de façon compatible. Quelques détails différaient ici et là. Toutefois ça fonctionnait dans l’ensemble et de nombreuses pages web utilisent encore un tel code.

    Dieu merci, ES6 a standardisé cet aspect. La fonction est désormais remontée en haut du bloc englobant.

    Malheureusement, Firefox et Safari n’implémentent pas encore ce nouveau standard. Pour le moment, il est donc conseillé d’utiliser une expression de fonction :

    if (temperature > 30) {
      var rafraichir = function () {
        return ventilo.allumer().then(boireLimonade);
      }
      rafraichir();
    }
    

    La seule raison pour laquelle ces fonctions n’ont pas été standardisées auparavant c’est que les contraintes de rétro-compabilité étaient incroyablement compliquées. Personne ne pensait qu’elles pourraient être résolues. ES6 a réussi ce tour de force en ajoutant une règle très étrange qui ne s’applique qu’à du code non-strict. Je ne peux pas l’expliquer ici. Croyez-moi, utilisez le mode strict.

  • Les noms de fonctions. Les principaux moteurs JS qui existent supportent depuis longtemps une propriété non-standard .name pour les fonctions qui ne sont pas anonymes. ES6 standardise cet aspect et y ajoute une amélioration pour des fonctions qui pouvaient auparavant être vues comme anonymes :

    > var inférieurÀ = function (a, b) { return a < b; };
    > inférieurÀ.name
        "inférieurÀ"
    

    Pour les autres fonctions telles que les fonctions de rappel (callbacks) qui sont passées en arguments aux méthodes .then, la spécification n’a rien pu proposer de mieux que la chaîne vide comme valeur pour fn.name.

Les trucs sympas

  • Object.assign(target, ...sources). Une nouvelle fonction de la bibliothèque standard, semblable à la méthode _.extend() d’Underscore.

  • L’opérateur de décomposition pour les appels de fonction. Rien à voir avec les cadavres dans le placard. C’est au contraire une fonctionnalité plutôt vivifiante.

    En mai, nous avons évoqué les paramètres du reste. Ils permettent à une fonction de recevoir autant d’arguments qu’on veut et remplacent agréablement l’objet arguments, un peu maladroit.

    function log(...trucs) {  
    // trucs est le paramètre du reste
    
      var rendered = trucs.map(renderStuff); 
      // C'est un vrai tableau
    
      $("#log").add($(rendered));
    }
    

    Ce que nous n’avons pas vu, c’est qu’il existe une syntaxe correspondante pour passer autant d’arguments qu’on veut à une fonction, autrement dit, une méthode plus civilisée que fn.apply() :

     // logger toutes les valeurs d'un tableau
     log(...monTableau);
    

    Bien entendu, ça fonctionne avec n’importe quel objet itérable vous pouvez donc faire de même avec un ensemble (Set) en écrivant log(...monSet).

    À la différence des paramètres du reste, il peut être judicieux que de décomposer plusieurs arguments dans un même appel :

    // l'été vient avant l'hiver
    log("Été :",...températuresÉté, "Hiver :", températuresHiver);
    

    L’opérateur de décomposition peut s’avérer utile pour aplatir un tableau de tableaux :

    > var petitsTableaux = [[], ["un"], ["deux", "trois"]];
    > var grandTableau = [].concat(...petitsTableaux);
    > grandTableau
        ["un", "deux", "trois"]
    

    mais peut-être que ce cas de figure n’intéresse que moi. Dans ce cas, la faute incombe à Haskell.

  • L’opérateur de décomposition pour construire les tableaux. En mai également, nous avions évoqué les motifs de décomposition permettant d’obtenir un nombre variable d’éléménts d’un tableau :

    > var [tête, ...queue] = [1, 2, 3, 4];
    
    > tête
           1
    > queue
           [2, 3, 4]
    

    Devinez quoi ? Il existe une syntaxe correspondante pour construire un tableau :

    > var réunion = [tête, ...queue];
    
    > réunion
          [1, 2, 3, 4]
    

    Cette syntaxe suit les mêmes règles que pour l’opérateur de décomposition appliqué aux appels de fonction : vous pouvez utiliser l’opérateur de décomposition plusieurs fois dans un même tableau et ainsi de suite.

  • Gestion de la récursion terminale. Cette fonctionnalité est trop géniale pour que je puisse l’expliquer ici.

    Pour comprendre de quoi il s’agit, je vous invite à lire Structure and Interpretation of Computer Programs. Si ça vous intéresse, continuez à lire, la récursion terminale est expliquée à la section 1.2.1 « Récursion linéaire et itération ».

    Pour respecter le standard ES6, les implémentations doivent être à récursivité terminale (au sens utilisé dans ce livre).

    Aucun des principaux moteurs JavaScript n’a encore implémenté cet aspect, d’ailleurs difficile à mettre en œuvre. Chaque chose en son temps.

Les nouveautés liées au texte

  • Mise à jour d’Unicode. Pour respecter ES5, les implémentations devaient a minima supporter tous les caractères de la version 3.0 d’Unicode. Avec ES6, les implémentations doivent au moins supporter Unicode 5.1.0. Vous pouvez désormais utiliser des caractères du syllabaires linéaire B pour nommer vos fonctions !

    Utiliser le syllabaire linéaire A est un peu risqué en revanche, en effet il n’a été ajouté à Unicode qu’à partir de la version 7.0. Aussi, ça peut être un peu compliqué de maintenir du code écrit dans un langage qui n’a jamais été déchiffré.

    (Même avec les moteurs JavaScript qui supportent l’emoji ajouté avec Unicode 6.1, vous ne pouvez pas utiliser U+1F638 comme nom de variable. Pour quelque obscure raison, le Consortium Unicode a décidé de ne pas classer ce caractère comme un identifiant. U+1F63F)

  • Séquences d’échappement Unicode étendues. ES6, comme les versions précédentes, supporte les séquences d’échappement Unicode sur quatre chiffres. Elles ressemblent à ça : \u212A. Elles sont géniales et vous pouvez les utiliser dans des chaînes de caractères. Si vous vous sentez d’humeur joueuse et que vous n’avez pas les moyens d’investir dans un outil de revue de code, vous pouvez même les utiliser dans des noms de variables. Mais lorsqu’il s’agit d’un caractère comme U+13021, le hiéroglyphe égyptien qui représente un homme debout sur sa tête, il y a un léger problème. Le nombre 13021 comporte cinq chiffres.

    Et cinq est plus grand que quatre.

    Avec ES5, il fallait écrire deux séquences d’échappement pour former une paire de demi-codets. On se serait cru aux Âges sombres : froids, tristes, barbares. ES6, tel la Renaissance italienne, apporte de lumineux changements : vous pouvez maintenant écrire \u{13021}.

  • Un meilleur support pour les caractères en dehors du BMP (plan multilingue de base). Les méthodes .toUpperCase() et .toLowerCase() fonctionnent désormais sur les chaînes écrites avec l’alphabet Deseret !

    Dans le même esprit, String.fromCodePoint(...codePoints) est une fonction, très semblable à l’ancienne String.fromCharCode(...codeUnits), qui permet de travailler avec des codets en dehors du BMP.

  • Les expressions rationnelles Unicode. Les expressions rationnelles Unicode supportent un nouveau marqueur : le marqueur u. Celui-ci permet aux expressions rationnelles de traiter les caractères en dehors du BMP comme des caractères « entiers » et non comme deux codets séparés. Par exemple, sans le marqueur u, /./ ne correspond qu’à la moitié du caractère “”. En revanche, /./u correspond à la chaîne entière.

    Utiliser le marqueur u sur une expression rationnelle permet également d’obtenir des correspondances utilisant mieux Unicode et qui gère mieux la casse et les séquences d’échappement étendues. Pour plus d’explications, rien de mieux que le billet, très détaillé, de Mathias Bynens.

  • Expressions rationnelles « adhérentes ». Une fonctionnalité, sans rapport avec Unicode, est le marqueur y, également appelé marqueur d’adhérence. Une expression rationnelle adhérente ne cherche une correspondance qu’à l’endroit indiqué par sa propriété .lastindex. S’il n’y a pas de correspondance à cet emplacement, l’expression rationnelle renvoie null directement plutôt que de chercher une correspondance plus loin sur la chaîne.

  • Une spécification officielle pour l’internationalisation. Les implémentations ES6 qui offrent des fonctionnalités d’internationalisation doivent supporter ECMA-402 : la spécification de l’API d’internationalisation d’ECMAScript 2015. Ce standard séparé spécifie l’objet Intl. Firefox, Chrome et IE11 (ainsi que les versions supérieures) le supportent déjà. Il en va de même pour Node 0.12.

Les nouveautés liées aux nombres

  • Les littéraux pour les nombres binaires et octaux. Si vous avez besoin d’écrire le nombre 8 675 309 tel un-e excentrique et que 0x845fed est trop surfait à votre goût, vous pouvez désormais l’écrire en octal (0o41057755) ou en binaire (0b100001000101111111101101).

    La fonction Number(str) reconnaît également les chaînes de caractères utilisant ce format. Par exemple, Number("0b101010") renverra 42.

    (Léger rappel : number.toString(base) et parseInt(string, base) sont les méthodes « originales » pour convertir des chaînes et des nombres en utilisant des bases arbitraires.)

  • De nouvelles fonctions et constantes pour Number. Ces changements portent sur un sujet restreint. Si cela vous intéresse, vous pouvez parcourir la spécification et voir ce que ça donne à partir de Number.EPSILON.

    La nouvelle idée peut-être la plus intéressante est l’intervalle pour représenter les entiers correctement, il va de −(253 - 1) à +(253 - 1) (au sens large). Cet intervalle numérique existe depuis le début de JS. Chaque entier compris dans cet intervalle (ainsi que ses voisins) peut être exactement représenté par un nombre JavaScript. En résumé, sur cet intervalle, ++ et -- fonctionnent sans surprise. En dehors de cet intervalle, les entiers impairs sont représentables par des nombres flottants sur 64 bits. Incrémenter ou décrémenter des nombres représentables (ceux qui sont pairs) ne peut donc pas fournir de résultat entièrement correct. Au cas où cela ait de l’importance pour votre code, vous pouvez maintenant utiliser les constantes Number.MIN_SAFE_INTEGER et Number.MAX_SAFE_INTEGER ainsi qu’une fonction de prédicat : Number.isSafeInteger(n).

  • De nouvelles fonctions pour Math. ES6 ajoute les fonctions trigonométriques hyperboliques ainsi que leurs inverses, Math.cbrt(x) pour calculer des racines cubiques, Math.hypot(x, y) pour calculer l’hypothénuse d’un triangle rectangle, Math.log2(x) et Math.log10(x) pour calculer des logarithmes sur des bases fréquemment utilisées, Math.clz32(x) pour aider à calculer des logarithmes entiers, ainsi que quelques autres fontions.

    Math.sign(x) permet d’obtenir le signe d’un nombre.

    ES6 ajoute aussi Math.imul(x, y) qui calcule la multiplication signée de deux nombres modulo 232. Plutôt étrange comme fonctionnalité, sauf si vous voulez contourner le fait que JS ne possède pas d’entiers sur 64 bits ou de système pour représenter de grands entiers. Dans ces cas, c’est plutôt pratique et ça permet d’aider les compilateurs. Emscripten utilise cette fonction pour implémenter, en JS, la multiplication des entiers représentés sur 64 bits.

    De la même façon, Math.fround(x) est utile aux compilateurs qui doivent supporter les nombres flottants sur 32 bits.

Fin

Est-ce vraiment tout ?

Pas vraiment. Je n’ai pas abordé l’objet qui est le prototype commun à tous les itérateurs natifs, ni le constructeur top-secret GeneratorFunction, ni Object.is(v1, v2), ni l’utilité de Symbol.species quand on veut créer des sous-classes d’Array et de Promise, ni la façon dont ES6 spécifie l’interaction entre plusieurs variables globales (ce qui n’avait pas été standardisé jusqu’à présent).

Je suis également certain d’avoir oublié d’autres choses.

Mais si vous avez suivi cette série depuis le début, vous devriez avoir un bon aperçu de la direction qui a été prise. Vous savez que vous pouvez utiliser les fonctionnalités ES6 dès aujourd’hui et qu’en faisant ça, vous utiliserez un meilleur langage.

Il y a quelques jours, Josh Mock m’a fait remarquer qu’il avait utilisé huit fonctionnalités ES6 différentes sur environ 50 lignes de code, sans même y penser : les modules, les classes, les arguments par défaut, Set, Map, les gabarits de chaînes de caractères, les fonctions fléchées et let (il avait oublier de mentionner la boucle for-of).

C’est également ce que j’ai ressenti. Ces nouvelles fonctionnalités s’imbriquent très bien. Elles finissent par affecter chaque ligne de JS que vous écrivez.

Pendant ce temps, tous les moteurs JS se dépêchent d’implémenter et d’optimiser les fonctionnalités que nous avons vues au cours de ces derniers mois.

Une fois que ce sera fini, le langage sera terminé. Rien n’aura besoin d’être changé et je devrai trouver quelque chose d’autre sur quoi travailler.

Je rigole, les propositions pour ES7 sont déjà sur la rampe de lancement. En voici quelques-unes :

  • L’opérateur d’exponentiation. 2 ** 8 renverra 256. Celui-ci est implémenté dans Firefox Nightly.

  • Array.prototype.includes(valeur). Renvoie true si le tableau contient la valeur donnée. Cette méthode est implémentée dans Firefox Nightly et peut être remplacée par une prothèse (polyfill).

  • SIMD. Cette API expose les instructions SIMD 128 bits fournies par les processeurs récents. Ces instructions permettent d’effectuer, en une fois, des opérations arithmétiques sur des tableaux de 2, 4 ou 8 éléments adjacents. Elles peuvent améliorer les performances de certains algorithmes de façon drastique : traitement audio et vidéo, cryptographie, jeux, etc. Ces fonctions se situent à un très bas niveau et sont très puissantes. Elles sont implémentées dans Firefox Nightly et peuvent être remplacées par une prothèse.

  • Les fonctions asynchrones. Nous avons entraperçu cette fonctionnalité dans le billet sur les générateurs. Les fonctions asynchrones ressemblent aux générateurs mais sont spécialisées pour la programmation asynchrone. Quand vous appelez un générateur, il renvoie un itérateur. Quand vous appelez une fonction asynchrone, elle renvoie une promesse. Les générateurs utilisent le mot-clé yield pour faire une pause et produire une valeur, les fonctions asynchrones, quant à elles, utilisent le mot-clé await pour faire une pause et attendre une promesse.

    C’est plutôt difficile de les décrire en quelques lignes mais il y a fort à parier que les fonctions asynchrones seront la fonctionnalité phare de ES7.

  • Les objets typés. La suite logique des tableaux typés. Les tableaux typés ont des éléments qui peuvent être typés. Un objet typé est simplement un objet dont les propriétés sont typées.

    // On crée une nouvelle structure typée. Chaque a deux propriétés
    // appelées x et y.
    var Point = new TypedObject.StructType({
      x: TypedObject.int32,
      y: TypedObject.int32
    });
    
    // On crée une instance de ce type.
    var p = new Point({x: 800, y: 600});
    console.log(p.x); // 800
    

    Les performances sont la principale (voire la seule) raison d’utiliser cela. Comme les tableaux typés, les objets typés apportent les bénéfices d’un typage fort (utilisation de mémoire, vitesse) mais au choix et à la granularité des objets, contrairement aux langages où tout est typé de façon statique.

    Il sont également pertinents si on utilise JS comme langage cible pour compiler.

    Les objets typés sont implémentés dans Firefox Nightly.

  • Décorateurs de classes et de propriétés. Les décorateurs sont des étiquettes que vous pouvez ajouter à une propriété, une classe ou une méthode. Voici un exemple pour les illustrer :

    import debug from "jsdebug";
    class Personne {
        @debug.logSiAppelé
        teteRonde(assert) {
        return this.tete instanceof Spheroide;
        }
        ...
    }
    

    c’est @debug.logSiAppelé qui est le décorateur ici. Je vous laisse imaginer ce qu’il fait à la méthode.

    La proposition pour le standard explique comment cela fonctionne, en détails et avec de nombreux exemples.

Encore une nouveauté intéressante que je dois mentionner. Il ne s’agit pas d’une fonctionnalité du langage.

TC39, le comité pour le standard ECMAScript va augmenter le rythme des versions et adopter un processus plus transparent. Six ans se sont écoulés entre ES5 et ES6. Le comité a l’intention de publier ES7 12 mois après ES6. Les éditions suivantes du standard seront publiées à ce rythme annuel. Certaines des fonctionnalités listées ci-dessus seront prêtes à temps. Elles « monteront dans le train » et feront partie d’ES7. Celles qui ne sont pas finalisées durant cette période prendront le prochain.

J’ai adoré partager cette quantité stupéfiante de nouveautés apportées par ES6. Bonne nouvelle, une telle vague ne devrait probablement pas se reproduire. Merci d’avoir suivi ES6 en détails. J’espère que ces articles vous ont plu. À la prochaine !


Fin de cette série sur ECMAScript 6. Ce fut un plaisir que de travailler sur ces traductions au fur et à mesure que Jason Orendorff avançait. De sincères et chaleureux remerciements s’imposent pour ces 17 articles, ces milliers de mots et ces dizaines d’exemples :

  • Merci à Marine, Banban, Ilphrin, Jérémie, Mentalo, Thegennok, Lucas, Benjamin, Benoît et Amarok qui ont participé aux traductions de ces articles, que ce soit pour quelques lignes, de nombreux paragraphes, voire des articles. Sans ce magnifique travail d’équipe, cette série n’aurait pas pu avancer à ce rythme ! Bravo tout le monde !
  • Merci à goofy qui a été très patient tout au long de ces quatre mois pour relire chacun des articles tout en gardant un œil sur SUMO. Puisse la force du Bescherelle et les règles typographiques t’apporter joie et bonheur :)
  • Merci à Pascal Chevrel pour avoir répondu à mes questions sur Dotclear et pour faire ce travail de l’ombre qu’on sous-estime trop souvent : la maintenance, en l’occurrence celle de ce blog.
  • Merci à celles et ceux qui ont partagé ces articles.
  • Merci à Framasoft pour ses supers framapads !
  • Merci aux auteurs de la série : Eric Faust, Gastón I. Silva, Nick Fitzgerald, Benjamin Peterson…

Enfin et surtout, merci à Jason Orendorff, de m’avoir appris beaucoup de choses sur JavaScript, d’avoir trouvé des jeux de mots assez tordus à traduire, d’utiliser MDN et d’avoir accepté que ce projet puisse continuer à vivre sous une autre forme qui devrait arriver prochainement…

Qui sait, peut-être à bientôt sur ce blog !

Lire la suite »

News Xulfr

Avec les dernières annonces de Mozilla, nous pouvons considérer la technologie XUL comme étant une technologie du passé.

Coté XulRunner, il n'y a déjà plus de builds pour les nightlies et beta de XulRunner. Dans les répertoires de téléchargement dédiés, il n'y a ainsi plus qu'un message indiquant la fin de vie de XulRunner. La version 40.0.2 restera donc la dernière version stable de XulRunner. Les applications réalisées pour XulRunner pourront toutefois continuer à fonctionner en utilisant Firefox avec son option --app (sous réserve de compatibilité des API internes...).

Il est même envisagé de supprimer les sources de XulRunner de la branche master des sources de Mozilla, si personne ne veut s'en occuper. Benjamin Smedberg, ingénieur chez Mozilla et créateur de XulRunner, ne peut et ne veut plus s'en occuper. Cependant il semble que quelqu'un se soit déclaré volontaire puisque les sources sont encore là, après la date fatidique qui était prévue pour la suppression. Mais jusqu'à quand ce volontaire s'en occupera ?

Ensuite une discussion a démarré pour trouver des solutions pour arriver à un navigateur sans XUL, donc pour arriver à supprimer la technologie XUL de Gecko (qui commence un peu à faire doublon avec HTML). Cela n'est pas chose facile, et prendra quelques années probablement. Faut-il une suppression progressive ? ou refaire tout à zéro ? (à partir de Servo ?). Il y a des pistes comme browser.html mais cela reste très expérimental et très incomplet pour le moment.

Cependant, une première décision est prise : les extensions en XUL/XPCOM ne seront plus installables l'année prochaine dans Firefox. Il faut donc les considérer comme obsolète, et les développeurs devront utiliser une nouvelle API, WebExtensions. Elle sera compatible avec celle utilisée dans le navigateur Chrome. Et sera étendue pour permettre à certaines extensions avancées d'avoir accès à des fonctionnalités similaires à ce que l'on pouvait faire directement avec l'API interne XPCOM. Mais il y a tout de même des doutes quant aux futures possibilités, et probablement que certaines extensions ne pourront plus être réécrites avec les mêmes fonctionnalités.

Lire la suite »

ES6 en détails : les modules

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 à Banban et Ilphrin pour la traduction et merci à 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é).

En 2007, lorsque j’ai intégré l’équipe Mozilla pour le moteur JavaScript, nous avions une blague récurrente : un programme JavaScript tient généralement sur une ligne et c’est tout.

C’était deux ans après le lancement de Google Maps. Peu avant, JavaScript était en grande partie utilisé pour valider des formulaires et il était à peu près certain qu’un gestionnaire <input onchange=…> tiendrait sur une ligne.

Les choses ont changé. Les tailles des projets JavaScript sont désormais démentielles et la communauté a développé des outils pour travailler à ce niveau. Un des éléments de base nécessaire est un système de modules : une façon de partager le code pour l’utiliser entre plusieurs fichiers et plusieurs dossiers – tout en garantissant que chaque partie de votre code puisse accéder à une autre lorsque c’est nécessaire – et en étant capable de charger tout ce code efficacement. Il était donc naturel que JavaScript se dote d’un système de modules. Plusieurs, en fait. Il y a également plusieurs gestionnaires de paquets : des outils qui permettent d’installer tous les logiciels et de gérer les dépendances de haut niveau. Vous pourriez penser qu’ES6, avec sa nouvelle syntaxe pour les modules, arrive un peu après la cavalerie.

Soit, aujourd’hui nous allons voir si ES6 ajoute quelque chose à ces systèmes existants et si oui ou non les futurs outils et standard pourront s’appuyer sur lui. Mais pour le moment, voyons à quoi ressemblent les modules ES6.

Les bases

Un module ES6 est un fichier contenant du code JavaScript. Il n’y a pas de mot-clé spécifique module, un module est lu comme un script. Il y a deux différences :

  • Les modules ES6 sont considérés comme écrits en mode strict, même si vous n’écrivez pas "use strict";
  • Vous pouvez utiliser import et export dans les modules.

Parlons d’abord d’export. Par défaut, tout ce qui est déclaré dans un module lui est local. Si vous voulez que quelque chose de déclaré dans un module soit public, afin que les autres modules puissent l’utiliser, vous devez l’exporter. Il existe plusieurs façons de faire. La plus simple est d’utiliser le mot-clé export.

// kittydar.js - Trouve tous les chats d'une image.
// (Cette librairie existe vraiment et a été écrite
// par Heather Arthur, mais elle n'utilisait pas les
// modules, car nous étions en 2013)

export function detectCats(canvas, options) {
  var kittydar = new Kittydar(options);
  return kittydar.detectCats(canvas);
}

export class Kittydar {
  //... plusieurs méthodes de traitement d'image ...
}

// Cette fonction auxiliaire n'est pas exportée. 
function resizeCanvas() {
  ...
}
...

Et c’est vraiment tout ce dont vous avez besoin pour écrire un module ! Vous n’avez rien à mettre dans un IIFE ou une fonction de rappel (callback). Allez-y et déclarez simplement ce qui est nécessaire. Puisque le code est un module et non un script, toutes les déclarations seront encapsulées dans ce module et ne seront pas visibles de façon globale pour les autres scripts et modules. Il suffit d’exporter les déclarations qui forment l’API publique de votre module.

En dehors des exportations, le code d’un module est tout à fait normal. On peut utiliser des objets globaux comme Object et Array. Si votre module est lancé dans un navigateur, celui-ci pourra utiliser document et XMLHttpRequest.

Dans un autre fichier, on peut importer et utiliser la fonction detectCats() :

// demo.js - Démo de Kittydar
import {detectCats} from "kittydar.js";
function go() {
    var canvas = document.getElementById("catpix");
    var cats = detectCats(canvas);
    drawRectangles(canvas, cats);
}

Pour importer plusieurs noms à partir d’un module, on écrira :

import {detectCats, Kittydar} from "kittydar.js";

Quand vous exécutez un module contenant une déclaration import, les modules qu’il importe sont chargés en premier, puis le corps de chaque module est exécuté selon un parcours en profondeur du graphe de dépendance, cela évite les cycles et permet de passer tout ce qui a déjà été exécuté.

Voilà les bases des modules. C’est aussi simple que ça. ;-)

Listes d’export

Plutôt que de marquer chaque fonctionnalité exportée, vous pouvez écrire une liste de tous les noms à exporter, entre accolades :

export {detectCats, Kittydar};
// pas besoin d'utiliser le mot-clé `export` ensuite
function detectCats(canvas, options) { ... }
class Kittydar { ... }

Une liste export ne doit pas nécessairement être placée en début de fichier, elle peut apparaître n’importe où tant qu’elle est dans la portée de plus haut niveau du module. Il est possible d’avoir plusieurs listes export ou bien de mélanger les listes export avec d’autres déclarations export. Une condition à respecter : un nom ne doit pas être exporté plus d’une fois.

Renommage des imports et exports

Il arrive parfois qu’un nom importé entre en collision avec un nom déjà utilisé par ailleurs. ES6 vous permet donc de renommer les valeurs importées :

// suburbia.js
// Ces deux modules exportent quelque chose appelé « flip ».
// Pour les importer tous les deux, nous devons en renommer au moins un.
import {pain as painGlace} from "igloo.js";
import {pain as painBlé} from "boulangerie.js";
...

De la même manière, vous pouvez renommer les éléments lorsque vous les exportez. Plutôt pratique si vous voulez exporter la même valeur avec deux noms différents, ce qui peut arriver :

// unlicensed_nuclear_accelerator.js
// – lecture continue de media sans DRM
// (bibliothèque qui n'existe pas mais 
// devrait peut-être...)
function v1() { ... }function v2() { ... }
export {
  v1 as streamV1,
  v2 as streamV2,
  v2 as streamLatestVersion
};

Exports par défaut

Le nouveau standard est conçu pour pouvoir opérer avec les modules CommonJS et AMD existants. Si, par exemple, vous avez un projet Node et qu’à un moment vous avez tapé npm install lodash, vous pouvez importer les fonctions individuelles de Lodash dans votre code ES6 :

import {each, map} from "lodash";

each([3, 2, 1], x => console.log(x));

Mais peut-être avez-vous l’habitide de voir _.each plutôt que each et souhaitez-vous continuer à l’écrire de cette façon ? Ou peut-être avez-vous envie d’utiliser _ comme une fonction puisque c’est utile avec Lodash ?

Pour cela, vous pouvez utiliser une syntaxe légèrement différente, en important le module sans les accolades.

import _ from "lodash";

Ce raccourci est équivalent à import{default as _} from lodash";. Tous les modules CommonJS et AMD sont présentés à ES6 avec des exports par défaut qui correspondent à ce que vous auriez obtenu en utilisant require() pour le module souhaité (autrement dit, l’objet exports).

Les modules ES6 sont conçus pour vous permettre d’exporter plusieurs choses. Toutefois, pour les modules CommonJS existants, l’export par défaut sera tout ce que pourrez obtenir. Par exemple, à l’heure où est écrit cet article, le célèbre paquet colors n’est pas particulièrement supporté par ES6. C’est un ensemble de modules CommonJS, comme la plupart des paquets npm et vous pouvez l’utilisez directement dans votre code ES6.

// Équivalent ES6 de `var colors = require("colors/safe");
`import colors from "colors/safe";

Si vous voulez que votre module ES6 ait un export par défaut, c’est simple à faire. Il n’y a rien de spécial au sujet de l’export par défaut, c’est un export comme un autre, excepté qu’il est appelé default. Vous pouvez donc utiliser la syntaxe de renommage dont nous avons déjà parlé :

let monObjet = {
  champ1: valeur1,
  champ2: valeur2
};
export {monObjet as default};

Encore mieux, vous pouvez utiliser la notation raccourcie :

export default {
  champ1: valeur1,
  champ2: valeur2
};

Les mots-clés export default peuvent être suivis par n’importe quelle valeur : une fonction, une classe, un littéral objet, à vous de choisir

Les objets module

Désolé, ça commence à faire un peu long. Cela dit, JavaScript n’est pas un cas isolé. Pour certaines raisons, les systèmes de modules des différents langages ont tendance à avoir plein de petites fonctionnalités utilitaires un peu ennuyantes. Heureusement, il ne reste qu’un seul point à voir… enfin deux.

import * as vaches from "vaches";

Quand vous écrivez import *, vous importez un objet d’espace de noms pour le module. Les propriétés de cet objet sont les valeurs exportées par le module. Ainsi, si le module vache exporte une fonction appelée meugle(), après avoir importé vache de cette façon, vous pourrez écrire vache.meugle().

Agréger des modules

Parfois, le module principal d’un paquet importera des paquets d’autres modules pour les exporter ensuite de façon unifiée. Pour simplifier ce genre de code, il existe un raccourci d’importation-exportation.

// monde.js - des saveurs de toute la planète

// importer "sri-lanka" et réexporter 
// certains de ses exports
export {Thé, Cannelle} from "sri-lanka";

// importer "guinée-équatoriale" et réexporter
// certains de ses exports
export {Café, Cacao} from "guinée-équatoriale";

// importer "singapour" et exporter tous ses exports
export * from "singapour";

Chacune de ces instructions export from est similaire à une instruction import from suivie d’un export. À la différence d’un import « réel », cela n’ajoute pas les éléments réexportés à la portée du module. Il ne faut donc pas utiliser cette notation raccourcie si vous souhaitez utiliser Thé dans votre monde.js. Il ne sera pas accessible de cette façon.

Si un des noms exporté par singapour entrait en collision avec un autre élément exporté par ailleurs, cela entraînerait une erreur. Attention donc quand vous utilisez export *.

Pfiou, on en a enfin fini avec la syntaxe. Passons aux choses sérieuses.

Qu’est-ce que fait import ?

Et si je vous disais qu’import ne fait… rien ?

Vous ne seriez pas si crédule… Eh bien, me croiriez-vous si je vous disais que le standard, pour une grande partie, ne dit pas ce que fait import ? Et que c’est une bonne chose ?

En ce qui concerne le chargement des modules, ES6 laisse carte blanche aux implémentations. Le reste sur l’exécution des modules est quant à lui spécifié en détails.

Grossièrement, lorsque vous demandez au moteur JS de lancer un module, il doit se comporter de la façon suivante, avec ces quatre étapes :

  1. Analyse (parsing) : l’implémentation lit le code source du module et vérifie la présence d’erreurs de syntaxe
  2. Chargement : l’implémentation charge tous les modules importés (récursivement). C’est cette partie qui n’est pas encore standardisée.
  3. Édition des liens (linking) : pour chaque module chargé, l’implémentation crée une portée pour ce module et la remplit avec les liaisons déclarées dans ce module, y compris celles qui utilisent des données importées d’autres modules. C’est cette partie qui fait que vous aurez une erreur si vous utilisez import {gâteau} from "mensonge", mais que le module "mensonge" n’exporte rien qui s’appelle gâteau. Dommage, vous n’étiez vraiment pas loin d’avoir du code JavaScript fonctionnel… et un peu de gâteau.
  4. Exécution (runtime) : pour finir, l’implémentation exécute les instructions présentes dans les corps de chacun des modules qui viennent d’être chargés. À ce moment, le processus d’import est déjà fini. Quand l’exécution atteint une ligne de code utilisant une valeur importée, il n’y a donc rien qui se produit.

Vous voyez, je vous avais bien dit que rien ne se passait !

Et c’est là qu’on arrive à la partie intéressante. Il y a une astuce : puisque le système ne spécifie pas le fonctionnement du chargement et parce que vous pouvez deviner en avance en regardant les déclarations import dans le code source, une implémentation ES6 peut donc faire tout le travail lors d’une compilation pour empaqueter tous les modules dans un seul fichier et l’envoyer sur le réseau ! Certains outils comme webpack utilisent cette technique.

Ça n’a l’air de rien comme ça mais c’est très important : charger des scripts via le réseau prend du temps, à chaque fois que vous allez chercher un script, il se peut qu’il ait besoin d’en importer une douzaine en plus. Un outil de chargement simpliste utiliserait beaucoup d’allers-retours réseau. Avec webpack, non seulement vous pouvez utiliser les modules ES6 dès aujourd’hui mais vous n’avez aussi aucune pénalité sur la performance lors de l’exécution.

En ce qui concerne le chargement des modules, une spécification détaillée était prévue et elle fut construite. Une des raisons pour lesquelles elle ne fait pas partie du standard final est qu’il n’y avait pas de consensus sur la façon de gérer l’empaquetage (bundling). J’espère que quelqu’un trouvera une solution parce que, comme nous allons le voir, le chargement des modules devrait vraiment être standardisé. L’empaquetage est trop délicieux pour qu’on puisse s’en passer.

« Statique contre dynamique » ou encore « les règles et comment les casser »

Alors que JavaScript est un langage dynamique, le système de modules que nous avons décrit jusqu’à présent est étonnament statique.

  • Toutes les variantes d’import et d’export sont permises uniquement au plus haut niveau dans un module. Il n’existe pas d’import ou d’export conditionnel et on ne peut pas importer dans la portée d’une fonction.
  • Tous les identifiants exportés doivent être explicitement exportés par leurs noms dans le code source. Il n’est pas possible de programmer une boucle parcourant un tableau pour exporter un ensemble de noms en fonction de données.
  • Les objets module sont gelés. Il n’y a aucune façon d’ajouter une nouvelle fonctionnalité à un module comme avec les prothèses.
  • Toutes les dépendances d’un module doivent être chargées, analysées et liées avant que le code du module ne puisse être exécuté. Il n’y a pas d’élément de syntaxe pour qu’un import puisse être chargé à la demande.
  • Il n’y a aucun moyen de récupérer suite à une erreur d’import. Une application pourrait avoir des centaines de modules qui la composent, si un seul échoue à charger, rien ne fonctionnera. Il est impossible d’importer dans un bloc try/catch (un avantage ici : le système est tellement statique que webpack peut détecter ces erreurs pour vous lors de la compilation).
  • Il n’y a pas de mécanisme pour permettre à un module d’exécuter du code avant que ses dépendances soient chargées. Cela signifie qu’un module n’a aucun contrôle sur la façon dont ses dépendances sont chargées.

Ce système fonctionne plutôt bien si vous avez des besoins statiques. Mais ce n’est pas inimaginable que d’avoir quelques besoins particuliers de temps en temps, pas vrai ?

C’est pour ça que n’importe quel système de chargement de module possède une API avec laquelle vous pouvez programmer pour aller de pair avec la syntaxe ES6 statique import/export. Par exemple, webpack inclut une API qui vous permet de « découper » du code, de charger certains paquets de modules à la demande. Cette même API vous permet de passer outre la plupart des règles évoquées dans la liste ci-avant.

La syntaxe des modules ES6 est très statique et c’est bien car cela permet d’utiliser des outils puissants pour la compilation. Mais cette syntaxe statique a été conçue pour être combinée avec une API de chargement riche, dynamique et à venir.

Quand puis-je utiliser les modules ES6 ?

À l’heure actuelle, pour utiliser les modules, vous aurez besoin d’un transpileur tel que Traceur ou Babel. Dans un article précédent de la série, Gastón I. Silva a montré comment utiliser Babel et Broccoli pour compiler du code ES6. Suite à cet article, Gastón a construit un exemple utilisant les modules ES6. Ce billet d’Axel Rauschmayer contient un exemple utilisant Babel et webpack.

Le système de modules ES6 a principalement été conçu par Dave Herman et Sam Tobin-Hochstadt qui, pendant plusieurs années, ont défendu les composants statiques du système contre tout ceux qui arrivaient pour se joindre à cette controverse (dont moi). Jon Coppeard est en train d’implémenter les modules dans Firefox. Des travaux supplémentaires sont en cours pour standardiser le chargement des modules. La suite devrait se traduire par un ajout à HTML devant vraisemblablement ressembler à <script type="module">.

Et voilà ES6.

Cette série fut tellement intéressante que je n’ai pas envie qu’elle s’arrête. Encore un épisode ? Comme ça, nous pourrons parler des points divers et variés de la spécification ES6 qui n’étaient pas suffisamment conséquents pour mériter leur propre article. Nous en profiterons pour évoquer le futur d’ECMAScript. À la semaine prochaine donc, pour la formidable conclusion d’ES6 en détails.

Lire la suite »

Votre ZTE Open C ! Votre fond d’écran !

Firefox OS

Accueil de Firefox OS 2.2 : fond d'écran FirefoxFirefox OS vous donne la possibilité de personnaliser votre téléphone. Et la première des initiatives pour avoir un téléphone qui vous ressemble est de changer le fond d’écran. Pour cela rien de plus facile : après avoir déverrouillé, il faut appuyer quelques secondes sur une partie vide de votre écran. Là, trois options se proposent à vous :

  • prendre une image parmi les fonds d’écran de votre téléphone,
  • prendre une image de votre galerie,
  • prendre une photo pour ensuite l’appliquer en fond d’écran.

Vous trouverez quelques lignes plus bas, une démonstration pour changer son fond d’écran.

Si vous être le possesseur d’un ZTE Open C, votre smartphone dispose déjà un bon nombre de fonds d’écran et ZTE a par ailleurs rajouté des fonds d’écran adaptés à la résolution du téléphone. Cependant, comment importer et surtout où trouver des fonds d’écran à la résolution de l’Open C ?

Où trouver son fond d’écran

La résolution d’écran du ZTE Open C est de 480x800 pixels. Un éléments très important à prendre en compte car cette dimension vous assurera un affichage optimal du fond d’écran sur votre téléphone.

Plusieurs sites internet proposent des fonds d’écran pour mobile, il suffit d’aller sur ces sites spécialisés (wallpaper.mob.org, mobile9.com, Flickr) et de choisir les images au format 480x800 ou de taper « fond d’écran 480x800 » dans votre moteur de recherche favori.

Comment changer son fond d’écran ?

Voici une démonstration en images avec un fond d’écran trouvé sur Flickr et importé sur le ZTE Open C depuis l’ordinateur (pour un mode d’emploi adapté à votre version de Firefox OS, consultez cet article de l’assistance de Mozilla).

ZTE Open C de Grégoire

Fond d’écran de mon ZTE Open C.

Tour Tokyo de Masatsu

Image de résolution 480x800 téléchargée sur Flickr et transférée sur mon ZTE Open C. Pour information, elle représente la tour de Kyoto au Japon photographiée par l’artiste Masatsu. NB : Vous pouvez également sélectionner une image prise avec l’appareil photo depuis la galerie et la mettre en fond d’écran en suivant cette étape.

Menu Changer le fond d'écran.png

Processus classique de changement de fond d’écran : appuyer sur un espace vide de votre écran quelques secondes puis sélectionner « changer le fond d’écran ».

Menu sélectionner depuis

Votre image est enregistrée dans la galerie, il faut donc sélectionner « Galerie ».

Sélectionner l'image depuis la galerie

On sélectionne l’image transférée.

Rogner

L’image étant déjà dans la résolution 480x800, on clique directement sur « Terminé ».

ZTE Open C de Grégoire

Voici le résultat final.

Pour vous inspirer, voici une petite sélection d’images au format 480x800 crée par l’artiste John Baer. Toutes ces images sont sous licence Creative Commons et peuvent donc être utilisés sur votre smartphone et partagés sans demander l’accord de l’auteur.

Brick Yard

Brick Yard, des briques sylisées

Uni unbranded

Uni unbranded, mieux qu’un aplat de couleur

Splash

Splash qui rappelle les vagues et la mer

Mozilla a mis à disposition ces fonds pour tous vos écrans à l’occasion des dix ans de Firefox :

Firefox Decade Mozilla

Maintenant que le changement de fond d’écran n’a plus de secret pour vous, à vous de jouer et personnaliser votre Open C comme vous l’entendez.


N’hésitez pas à partager vos créations et vos trouvailles avec la communauté.


Grégoire


Vous pouvez améliorer et personnaliser vos images avec l’application Aviary que nous vous présentions en novembre.


Crédit illustrations :

Images sur Flickr sous licence CC By-SA 2.0 :

Image 3 Makoto Satsukawa

John Baer : Image 9, Image 10 et Image 11

Lire la suite »

Comment travaillons-nous ? Au grand jour…

BlogZiNet

Voici un mois, je suis tombé sur ce manifeste de l’équipe de collecte de fonds de la fondation Mozilla. L’extrait suivant entre particulièrement en résonnance avec le travail que nous faisons au sein du groupe de communication francophone communautaire pour Firefox OS (de son petit nom « groupe comm »).

En VO :

How do we work?

In the open.
With pride.
With meticulous processes.
With humility.
With empathy.
We collaborate.
We listen, a lot.
We ask ourselves for our best work, we support each other and other Mozillians.
We seek the truth, and tell it well.
We build and model healthy culture.
We solicit responsibly, with the best intentions for our donors and Mozilla.

En VF :

Comment travaillons-nous ?

Au grand jour.
Avec fierté.
Avec des processus méticuleux.
Avec humilité.
Avec empathie.
Nous collaborons.
Nous écoutons, beaucoup.
Nous exigeons de nous-même le meilleur travail, et nous nous soutenons les uns les autres, ainsi que les autres Mozilliens.
Nous cherchons la vérité et et la disons aussi.
Nous construisons et modelons une culture saine.
Nous sollicitons de façon responsable, avec les meilleures intentions pour nos donateurs et Mozilla.

À part la fin, nous pourrions la reprendre comme profession de foi.

Sources et références

Mozilla: View Source Fundraising, Fundraising Team Charter, 17 juil. 2015, Rebecca Davies

© 2010-2014 Mozinet - Ce billet a été publié sur BlogZiNet.

Lire la suite »

Sculpter votre corps avec Push Ups pour Firefox OS

Firefox OS

Je ne sais pas vous, mais personnellement, j’avais beaucoup de mal à faire des pompes : d’une part parce que je n’arrivais à en faire que peu et d’autre part par manque de motivation… et puis j’ai découvert « Push Ups » !

Cette application propose de vous prendre en main et de vous aider à faire de plus en plus de pompes. Sa méthode ? Vous soumettre à des séries de pompes progressives et adaptées à votre forme physique. Vous aimerez alors faire vos entraînements et développer petit à petit les muscles de votre cage thoracique, de vos épaules, de vos bras et de votre sangle abdominales.

On se lance ?

Push Up Week 1 - Day 1

Lors du premier démarrage, « Push Ups » va vous demander beaucoup d’honnêteté et d’humilité ! En effet, pour adapter les séances l’application a besoin de connaître le nombre de pompes que vous êtes capable de faire d’affilée. Un bon conseil ne trichez pas, car alors les séances seraient trop difficiles et vous seriez vite découragé.

Vous avez le choix entre trois réponses : entre 0 et 5 pompes, entre 6 et 14 et plus de 15 pompes.

nombre de pompes

À partir de là, l’application va vous demander de réaliser une séance de pompe quotidienne en vous indiquant le nombre de pompes et le nombre de séries à réaliser. Le temps de repos entre chaque série est également indiqué et représenté par une série de bloc qui disparaîtront seconde après seconde. S’il est tout à fait possible de ne pas en tenir compte au début, un conseil : respectez-les.

Calendrier Push Ups

Sans vous en rendre compte, au fil du temps, vous ferez des séries de plus en plus longues et sans trop de difficulté. Jetez un œil aux statistiques pour vous en rendre compte.

L’application n’est malheureusement pas disponible en français, mais les instructions et les messages sont dans un anglais tout à fait accessible.

Si l’application vous plaît, sachez que le développeur Dinh a créé d’autres applications du même genre, pour les abdos (ou redressements assis) : « Sit Ups », pour les tractions : « Pull Ups », pour les cuisses : « Squats »…


Et vous, combien de pompes pourrez-vous faire d’affilée à la fin de l’été ?


Aldéric


Retrouvez l’appli de la semaine dernière : Soyez en forme cet été avec « Run, Hike, Bike » pour Firefox OS

Lire la suite »

ES6 en détails : les sous-classes et l'héritage

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 à Banban et Marine pour la traduction et merci à 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é).

Deux semaines auparavant, nous avons vu le nouveau système de classes ajouté avec ES6 et qui permet de gérer les cas simples pour créer des constructeurs d’objets. Nous avons vu comment écrire du code qui ressemble à :

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;
    };
}

Cependant, comme certains l’ont relevé, nous n’avons pas eu le temps de parler de l’étendue des pouvoirs des classes ES6. Comme pour les langages basés sur les classes (C++ ou Java par exemple), ES6 gère également l'héritage : une classe peut en utiliser une autre comme « base » et ajouter des fonctionnalités supplémentaires qui lui sont propres. Allons voir ce que nous réserve cette nouvelle fonctionnalité.

Mais avant de parler des sous-classes et de l’héritage entre classes, ça peut faire du bien de réviser l’héritage des propriétés et la chaîne, dynamique, des prototypes.

L’héritage en JavaScript

Lorsqu’on crée un objet, on peut lui adjoindre des propriétés mais il hérite également des propriétés de ses prototypes. Certains développeurs JavaScript connaissent bien la méthode Object.create qui permet de faire tout ça facilement :

var proto = {
    valeur: 4,
    méthode() { return 14; }
}
var obj = Object.create(proto);

obj.valeur; // 4
obj.méthode(); // 14

De plus, si on ajoute des propriétés à obj qui ont les mêmes noms que celles de proto, les propriétés de obj masqueront celles de proto (NdT : en anglais, on parle de « shadowing »).

obj.valeur = 5;
obj.valeur // 5
proto.valeur; // 4

Un héritage de classes simple

Après ces légères révisions, voyons comment raccrocher la chaîne de prototypes à un objet créé via une classe. Encore un rappel : quand on crée une classe, on construit une nouvelle fonction qui correspond à la méthode du constructeur dans la définition de la classe et qui contient toutes les méthodes statiques. On crée aussi un objet qui sera le prototype de cette fonction créée et qui contiendra toutes les méthodes des instances. Pour créer une nouvelle classe qui hérite de l’ensemble des propriétés statiques, il faudra que l’objet fonction correspondant à cette nouvelle classe hérite de l’objet fonction de la classe parente. De la même façon, il faudra que l’objet prototype de la nouvelle fonction hérite de l’objet prototype de la classe parente afin que la nouvelle classe bénéficie des méthodes d’instances.

Cette description est un peu difficile à digérer, voyons ce que ça donne dans un exemple utilisant des éléments de syntaxe connus. Ensuite, nous ajouterons un élément syntaxique simple mais qui permettra de rendre le code plus agréable à lire.

Si on poursuit avec notre exemple précédent et qu’on considère une classe Forme qu’on veut décliner :

class Forme {
    get couleur() {
        return this._couleur;
    }
    set couleur(c) {
        this._couleur = parseColorAsRGB(c);
        this.modifApportée();  // on repeindra le canvas après
    }
}

Lorsqu’on essaie d’écrire le code pour faire ça, on se confronte au même problème qu’on a eu dans le billet précédent sur les classes avec les propriétés statiques : il n’y a aucun élément syntaxique qui permette de changer le prototype d’une fonction lors de sa définition. Bien qu’on puisse résoudre ça à coup de Object.setPrototypeOf, cette approche est limitée en termes d’optimisation et de performances et on préfèrerait avoir un moyen de créer une fonction avec le prototype voulu.

class Cercle {
    // Comme vu avant
}
// Rattacher les propriétés des instances 
Object.setPrototypeOf(Cercle.prototype, Forme.prototype);
// Rattacher les propriétés statiques
Object.setPrototypeOf(Cercle, Forme);

C’est assez moche. La syntaxe des classes a été ajoutée afin qu’on puisse encapsuler toute la logique d’un objet à un seul endroit plutôt que d’avoir à « rattacher » des choses a posteriori. Java, Ruby et d’autres langages ont une façon de déclarer qu’une déclaration de classe est une sous-classe d’une autre, ça devrait également être le cas pour JavaScript. Pour cela, on peut utiliser le mot-clé extends et écrire :

class Cercle extends Forme {
    // Comme vu avant
}

On peut mettre n’importe quelle expression après extends tant que celle-ci correspond à un constructeur valide avec une propriété prototype. On pourra donc mettre :

  • une autre classe
  • des fonctions semblables à des classes provenant de frameworks gérant l’héritage
  • une fonction normale
  • une variable qui contient une fonction ou une classe
  • un accès à une propriété d’un objet
  • un appel de fonction

On peut même utiliser null si on souhaite que les instances n’héritent pas d’Object.prototype.

Des oiseaux ? Des avions ? Non… Ce sont les super propriétés !

On peut donc faire des sous-classes, on peut hériter des propriétés et dans certains cas, nos méthodes masqueront (ou surchargeront) les méthodes qui auraient du être héritées. Comment faire quand on voudra contourner ce masque ?

Imaginons qu’on veuille écrire un sous-classe de la classe Cercle qui gère un homothétie avec un facteur donné. Pour cela, on pourrait écrire :

class CercleHomothétique extends Cercle {
    get rayon() {
        return this.facteur * super.rayon;
    }
    set rayon() {
        throw new Error("Le rayon d'un CercleHomothétique est constant." +
                        "Modifier plutôt le facteur d'échelle.");
    }

    // Code pour gérer le facteur d'échelle
}

On remarque ici que l’accesseur pour le rayon utilise super.rayon. Ce nouveau mot-clé, super, permet d’utiliser les propriétés du prototype, y compris quand celles-ci sont surchargées. super[expr] fonctionne également. L’accès aux propriétés avec super peut être utilisé dans n’importe quelle fonction définie avec la syntaxe de définition d’une méthode. Même si ces méthodes sont utilisées en dehors de l’objet original, l’accès aux propriétés est toujours lié à l’objet sur lequel la méthode a été définie initialement. Autrement dit, si on stocke la méthode dans une nouvelle variable, cela ne changera pas le comportement de super.

var obj = {
    toString() {
        return "MonObjet : " + super.toString();
    }
}

obj.toString(); // MonObjet : [object Object]
var a = obj.toString;
a(); // MonObjet : [object Object]

Créer des sous-classes pour les objets natifs

Avec tout ça, il est possible d’étendre les objets natifs offerts par le langage. Les structures de données natives ajoutent une richesse énorme à JavaScript, ce sera très utile de pouvoir créer de nouveaux types qui tirent parti de cette richesse. Cet aspect était une notion clé lors de la conception du système de sous-classes. Imaginons qu’on ait l’idée folle de créer un tableau versionné… On veut pouvoir effectuer des changements, les sauvegarder (« commit »), revenir à une version précédente (« rollback »). On peut utiliser l’objet Array et en créer une sous-classe :

class VersionedArray extends Array {
    constructor() {
        super();
        this.history = [[]];
    }
    commit() {
        // On sauvegarde les changements en historique
        this.history.push(this.slice());
    }
    revert() {
        this.splice(0, this.length, this.history[this.history.length - 1]);
    }
}

Les instances de VersionedArray contiennent quelques propriétés importantes. Ce sont des instances d’Array avec l’ensemble des attributs utiles que sont map, filter et sort. Array.isArray() les considèrera comme des tableaux, même la propriété length sera automatiquement mise à jour pour ces instances. Encore mieux : les fonctions qui renvoient un nouveau tableau (par exemple Array.prototype.slice()) renverront bien un VersionedArray !

Les constructeurs de sous-classes

Dans la méthode constructor de l’exemple précédent, vous avez pu voir le super() utilisé. Quel est son rôle ?

Dans les modèles de classes traditionnels, les constructeurs sont utilisés pour initialiser l’état des instances de la classe. Chaque sous-classe qui suit est ensuite responsable de l’initialisation de l’état associé aux spécificités de la sous-classe. On veut pouvoir enchaîner ces appels afin que les sous-classes puissent partager ce code d’initialisation pour la classe qu’elles étendent.

Pour appeler un constructeur d’une classe parente, on utilise là encore le mot-clé super mais cette fois comme s’il s’agissait d’une fonction. Cette syntaxe n’est valide qu’au sein de méthodes constructor pour des déclarations de classes qui utilisent extends. Avec super, on peut donc réécrire notre classe Forme :

class Forme {
    constructor(couleur) {
        this._couleur = couleur;
    }
}
class Cercle extends Forme {
    constructor(couleur, rayon) {
        super(couleur);

        this.rayon = rayon;
    }

    // Comme précédemment
}

En JavaScript, on a l’habitude d’écrire des constructeurs qui agissent sur l’objet this pour installer des propriétés et initialiser l’état interne. Normalement, l’objet this est créé lorsqu’on appelle le constructeur avec new, comme si on appelait Object.create() sur la propriété prototype du constructeur. Cependant, certains objets natifs sont organisés différemment en interne. Les tableaux (Array) par exemple, sont organisés différemment en mémoire. Étant donné qu’on souhaite vouloir créer des sous-classes pour les types natifs, on laisse le constructeur le plus « haut » allouer l’objet this. Ainsi, si c’est un objet natif, on aura l’organisation voulue et si c’est un constructeur normal, on aura l’objet this par défaut qu’on attend.

Cela entraîne une bizarrerie dans la façon dont this est lié aux constructeurs des sous-classes. Avant d’avoir exécuté le constructeur de base et donc d’avoir pu allouer l’objet this : on n’a pas de valeur pour this. Pour cette raison, tous les accès aux constructeurs de sous-classes lèveront une exception ReferenceError s’ils ont lieu avant l’appel au constructeur parent avec super().

Comme on l’a vu dans le billet précédent sur les classes, il est possible de ne pas écrire de méthode constructeur pour une classe. C’est également valable pour les sous-classes et leurs constructeurs. Si on ne déclare pas de méthode constructor, cela sera équivalent à :

constructor(...args) {
    super(...args);
}

Parfois, les constructeurs n’interagissent pas avec l’objet this. À la place, ils créent un objet d’une autre façon, l’initialisent et le renvoient directement. Si c’est le cas, il n’est pas nécessaire d’utiliser super. N’importe quel constructeur peut renvoyer un objet directement, qu’un constructeur parent ait été appelé ou non.

new.target

L’allocation effectuée par la classe la plus « haute » a une autre conséquence un peu étrange : parfois la classe la plus haute ne sait pas quel type d’objet allouer. Imaginons qu’on ait écrit un framework de gestion d’objets et qu’on ait une classe de base Collection dont certaines des sous-classes sont des tableaux (Array) et d’autres des tableaux associatifs (Maps). Au moment où on utilise le constructeur Collection, on est incapable de dire quelle sorte de sous-classe nous intéresse.

Puisqu’on peut avoir des sous-classes pour les types natifs, lorsqu’on exécute le constructeur natif, en interne, on doit connaître le prototype de la classe originale. Sans ça, on serait incapable de créer un objet avec les bonnes méthodes d’instances. Pour résoudre ce cas avec les « Collections », un nouvel élément de syntaxe a été ajouté à JavaScript pour exposer ces informations : la méta-propriété new.target. Elle correspond au constructeur qui a été appelé avec new. Lorsqu’on appelle une fonction avec new, new.target prendra la valeur de la fonction appelée. La valeur de new.target est transmise lorsqu’on utilise super au sein du constructeur.

Un exemple vaut mieux qu’un long discours pour expliquer :

class Toto {
    constructor() {
        return new.target;
    }
}
class Truc extends Toto {
    // This is included explicitly for clarity. It is not necessary
    // to get these results.
    constructor() {
        super();
    }
}
// Toto directement appelé, new.target correspond à Toto
new Toto(); // Toto

// 1) Truc directement appelé, new.target correspond à  Truc
// 2) Truc appelle Toto via super(), new.target est toujours Truc
new Truc(); // Truc

Nous avons résolu le problème avec la Collection décrite ci-dessus, parce que le constructeur de la collection peut juste vérifier new.target et l’utiliser pour les sous-classes, puis déterminer quel type natif utiliser.

new.target est valide dans n’importe quelle fonction. Si la fonction n’est pas appelée avec new, il vaudra undefined.

Un mélange détonant

En espérant que vous ayez survécu à ces nouvelles fonctionnalités. Merci de vous être accroché-e. Prenons un peu de temps pour se demander s’ils permettent de résoudre les problèmes correctement. De nombreux développeurs se sont demandé si c’était une bonne chose d’utiliser l’héritage pour coder une fonctionnalité. Vous pourriez croire que l’héritage n’est pas aussi efficace que la composition pour construire des objets, ou que la propreté de cette nouvelle syntaxe ne vaut pas l’absence de flexibilité du design qui en résulte, en comparaison avec l’ancien modèle basé sur les prototypes. Il est indéniable que les mixins sont devenus le mode d’expression dominants pour créer des objets qui partagent du code de façon extensible. C’est le cas pour une bonne raison : ils fournissent une méthode facile permettant de partager du code sans relation avec le même objet, sans avoir à comprendre comment ces deux éléments sans relation peuvent s’intégrer dans la même structure d’héritage.

Il existe de nombreuses croyances sur ce sujet, mais je crois qu’il y a quelques aspects notables. Premièrement, l’ajout des classes comme une fonctionnalité du langage ne rend pas leur utilisation obligatoire. Deuxièmement, tout en étant aussi important, l’ajout des classes comme une fonctionnalité du langage ne signifie pas qu’elles sont toujours le meilleur moyen de résoudre les problèmes d’héritage ! En réalité, certains problèmes seront plus facilement résolus en utilisant l’héritage et les prototypes. En fin de compte, les classes sont juste un nouvel outil à votre disposition, ce n’est pas le seul outil que vous avez et ce n’est pes nécessairement le meilleur.

Si vous souhaitez continuer à utiliser les mixins, vous aurez besoin de classes qui puissent hériter de plusieurs sources. Malheureusement, ce serait assez bouleversant de modifier le modèle d’héritage maintenant. Pour cette raison, JavaScript n’implémente pas l’héritage multiple de classes. Ceci étant dit, il existe une solution hybride qui permet d’utiliser les mixins dans un framework basé sur les classes.

Les fonctions suivantes, par exemple, sont basées sur l’idiome mixin extend :

function mix(...mixins) {
    class Mix {}

    // On ajoute toutes les méthodes et accesseurs
    // des mixins à la classe Mix.
    for (let mixin of mixins) {
        copyProperties(Mix, mixin);
        copyProperties(Mix.prototype, mixin.prototype);
    }
    
    return Mix;
}
function copyProperties(target, source) {
    for (let key of Reflect.ownKeys(source)) {
        if (key !== "constructor" && key !== "prototype" && key !== "name") {
            let desc = Object.getOwnPropertyDescriptor(source, key);
            Object.defineProperty(target, key, desc);
        }
    }
}

Cette fonction mix peut désormais être utilisée pour créer une classe parente composée. Il n’y a pas besoin de créer une relation d’héritage explicite entre les différents mixins. Si par exemple, on travaille sur un outil d’édition collaboratif et que les actions d’édition sont enregistrées et que le contenu de ces actions doit être sérialisé, on pourra utiliser la fonction mix pour définir la classe DistributedEdit :

class DistributedEdit extends mix(Loggable, Serializable) {
    // Méthodes d'événements
}

C’est ainsi qu’on mélange les deux approches efficacement. C’est aussi facile de voir comment étendre ce modèle pour gérer des classes mixin qui possèdent des classes parentes : il suffit de passer la classe parente dans le mélange et que la classe renvoyée étende cette classe parente.

Quand puis-je commencer à utiliser ces fonctionnalités ?

OK, on a beaucoup parlé des sous-classes et de décliner les objets natifs, mais peut-on les utiliser dès maintenant ?

À peu près. Parmi les principaux navigateurs, Chrome possède la plupart des fonctionnalités évoquées aujourd’hui. En mode strict, vous devriez pouvoir faire tout ce que nous avons vu à part décliner Array. Les autres types natifs sont fonctionnels mais Array est un peu particulier et ce n’est donc pas une surprise que ça prenne du temps. En ce qui concerne Firefox, je suis en train d’implémenter ces fonctionnalités et espère atteindre le même objectif (tout sauf les déclinaisons d’Array) très bientôt. Le bug 1141863 contient plus d’informations à ce sujet, il devrait arriver dans la version Nightly de Firefox d’ici quelques semaines.

Edge supporte super mais pas les sous-classes pour les types natifs. Safari ne supporte aucune de ces fonctionnalités.

Sur ce sujet, les transpileurs ne sont pas d’un grand secours. Ils permettent de créer des classes et d’utiliser super mais ils n’ont aucun moyen pour assister à la création de sous-classes des types natifs. En effet, il faut que le moteur JavaScript permette d’obtenir les instances de la classe de base pour les méthodes natives (par exemple quand on utilise Array.prototype.splice sur une classe).

Bon, ce fut un long billet ! La semaine prochaine, Jason Orendorff revient pour discuter du système des modules ES6 en détails.

Lire la suite »

Firefox OS : bientôt des feature phones intelligents

Firefox OS

Powered by Firefox OSLe 1er mars, à l’occasion du Mobile World Congress 2015, Mozilla, KDDI, LG U+, Telefónica et Verizon Wireless avaient annoncé qu’ils collaboraient « pour créer une nouvelle catégorie de smartphones Firefox OS, à la fois intuitifs et simples à utiliser ». Ainsi, il s’agissait de « créer une nouvelle gamme de téléphones Firefox OS pour un lancement en 2016 sous différentes formes – rabats, claviers coulissants, plats – combinant la simplicité d’un téléphone basique (appels, SMS) avec les fonctions plus avancées d’un smartphone comme les applications ludiques, du contenu, une navigation, un lecteur de musique, un appareil photo, la vidéo, le LTE, le VoLTE, les emails et la navigation Web. »

Aujourd’hui, les choses se précisent avec une vidéo d’animation de Mozilla présentant un feature phone (téléphones d’entrée de gamme avec les fonctions classiques d’un téléphone mobile d’avant les smartphones) à clavier physique combiné avec l’intelligence d’un smartphone propulsé par Firefox OS.

Le site Firefox OS Guide a repéré une vidéo sur la page Facebook de Mozilla Egypt mettant en ligne une vidéo Mozilla intitulée Firefox OS Smart Feature Phone.


Il y est présenté un téléphone « simple et familier » avec un petit écran qui donne l’heure au-dessus d’un clavier en dur. On nous annonce d’emblée que la « navigation [est] simple » avec des icônes rondes empilées sur l’écran que l’on peut faire défiler vers le haut ou vers le vas dans un carrousel infini pour faire apparaître au centre l’icône plus grosse de la fonction que l’on veut enclencher : téléphone, alarme, notifications, outils, appareil photo, message.

Simple navigation
Ensuite, il nous est indiqué qu’il « suffit de numéroter et de se connecter ». Ainsi, quand on numérote sur le clavier physique, on fait apparaître la liste des contacts correspondant au début de numéro tapé. En appuyant sur le nom du contact dans la liste, on lance l’appel. Just dial and connect : contacts
Le contact apparaît alors sur l’écran avec sa photo et les commandes habituelles de Firefox OS disponibles lorsque l’on passe un appel téléphonique. Just dial and connect : appel à Mitchell Baker
C’est « une expérience personnelle » que l’on nous promet ensuite. On nous dit que l’on pourra « accéder rapidement aux appels récents ». On le fera par une icône à la droite de l’icône verte du téléphone. Quickly access recent calls
De la liste des appels, on pourra « épingler ses favoris ». Si on appuie sur l’entrée du menu qui apparaît alors « Épingler sur l’écran d’accueil », le contact apparaît à gauche de l’icône de téléphone avec sa photo dans un rond et ses nom et numéro de téléphone en dessous. Pin your favorites
Vous pouvez ainsi épingler plusieurs contacts. Pin your contacts
Mais aussi vous pouvez aussi « épingler vos playlists » musicales… Pin your playlists
… et « épingler vos alarmes ». Pin your alarms
Mais à la différence des feature phones qui se vendant encore bien vous pourrez « embrasser le Web ». Il vous est promis de « faire mieux avec l’internet ». Vous avez ainsi accès à la météo avec la température d’une ville dans une icône à gauche de l’icône météo, à Facebook avec vos contacts en photo à gauche de l’icône de l’application et des notifications à droite… Made better with the internet : weather
… et à Firefox avec des aperçus de site à gauche (sûrement l’équivalent des marque-pages) et l’icône de l’historique à droite. Powered by Firefox
C’est alors que l’on nous signale bien que le téléphone est « propulsé par Firefox OS » pour ensuite nous montrer une photo piochée dans la galerie du téléphone qui est poussée vers un écran large équipé de Firefox et un portable, semble-t-il, avec tous deux dessus « Firefox OS Remote Access » (accès à distance). Le dernier slogan est « simple, personnel, Web ». Feature phone, TV, portable

Feature phone, TV et portable : ballon

L’on ne sait pas ce que donnera la navigation web sur un si petit écran et s’il sera possible d’ajouter des applications. Le prix sera un élément fondamental du succès de ce genre de téléphones.

Ces téléphones étaient prévus pour sortir en premier aux États-Unis.

La vidéo (1 min 51) :


Et vous ? Achéteriez-vous un feature phone intelligent pour vous ou pour votre famille en remplacement d’un vieux feature phone sans Internet ?

On en a parlé

Le 1er mars 2015 :

Firefox OS démontre la flexibilité du web: l’écosystème s’enrichit avec plus de partenaires, de types d’appareils et de régions en 2015 (en français)

Mozilla, KDDI, LG U+, Telefónica and Verizon Wireless Collaborate to Create New Category of Firefox OS Phones (en anglais)

… et maintenant :

Smart Feature phones are coming powered by Firefox OS! Are You Ready? (en anglais)


@Mozinet
Lire la suite »