Mozilla Francophone https://mozfr.org/ 2015-07-30T18:05:26Z Author Mozilla Francophone : Ganesh et Pamela font découvrir Firefox OS à des milliers de Mauriciens https://blog.mozfr.org/post/2015/07/Ganesh-et-Pamela-font-decouvrir-Firefox-OS-a-des-milliers-de-Mauriciens 2015-07-30T17:11:00+00:00 Mozinet 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és 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 l’interview de Natalia (Mozilla).

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

]]>
Firefox OS : Flipper avec Vanilla Pinball sur Firefox OS https://firefoxos.mozfr.org/post/2015/07/Flipper-Vanilla-Pinball-Firefox-OS 2015-07-29T16:16:00+00:00 Mozinet 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

]]>
Blog technique de MozFR : MDN : dix ans d'évolution https://tech.mozfr.org/post/2015/07/26/MDN-%3A-dix-ans-d-evolution 2015-07-26T15:00:00+00:00 sphinx 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.

]]>
Firefox OS : Mamie Fox a été aux RMLL 2015 à Beauvais https://firefoxos.mozfr.org/post/2015/07/Mamie-Fox-a-ete-aux-RMLL-2015-Beauvais 2015-07-25T14:15:00+00:00 Mozinet 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.

]]>
Blog technique de MozFR : ES6 en détails : les proxies https://tech.mozfr.org/post/2015/07/23/ES6-en-details-%3A-les-proxies 2015-07-24T17:34:00+00:00 sphinx 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.

]]>
Firefox OS : Ne confondez plus navigateur web et moteur de recherche ! https://firefoxos.mozfr.org/post/2015/07/Ne-confondez-plus-navigateur-web-et-moteur-de-recherche 2015-07-22T23:00:00+00:00 Mozinet navigateurs et moteurs de recherche.pngChers amis,

Lors des RMLL2015, qui se sont finis à Beauvais (60) la semaine dernière, le Fox et moi avons été surpris par le nombre de visiteurs ne faisant pas la distinction entre « navigateur web » et « moteur de recherche ». Avant de présenter Firefox, nous demandions systématiquement à nos interlocuteurs avec quel navigateur ils consultaient le Net et bien souvent on nous répondait par « Google » ou « Yahoo ». Voici quelques explications que m’a transmises le Fox :

Qu’est-ce qu’un moteur de recherche ? Sur Internet, quand on parle de moteur de recherche, on désigne une « application web » permettant de trouver des ressources en ligne (page internet, photo, vidéo…) à partir d’une requête composée de mots-clés. Là encore, il existe beaucoup de moteurs de recherche tels que Google, Bing, Yahoo ou encore DuckDuckGo. Ces moteurs de recherche indexent – analyses et classements spécifiques permettant de retrouver (principalement) les éléments textuels rapidement – le contenu d’Internet et à l’aide d’algorithmes affichent les résultats qui leur paraissent les plus pertinents.

Qu’est-ce qu’un navigateur web ? Parfois appelé browser, butineur ou explorateur, le navigateur web est un programme qui permet d’afficher du contenu web, comme les pages de ce blog par exemple. En général, ce programme se compose d’au moins deux zones : l’une pour l’affichage des contenus souhaités et l’autre étant une barre d’adresse dans laquelle l’utilisateur vient inscrire l’URL (l’adresse) du site ou de la page qu’il souhaite consulter. Cette barre d’adresse est parfois « fusionnée » avec un moteur de recherche, dans ce cas il est possible d’y entrer une URL ou directement une requête. Cette fusion entretient sans aucun doute cette confusion. Ce n’est pas le cas dans Firefox, où la barre d’adresse est suivie d’une barre de recherche indépendante : pas de confusion possible. Même si dans les faits, la barre d’adresse remplit les deux rôles ! Il existe différents navigateurs, les principaux étant Firefox, Internet Explorer, Chrome et Safari.

Ainsi vous l’aurez compris : il est tout à fait possible d’utiliser n’importe quel moteur de recherche, sur n’importe quel navigateur !

Et Firefox OS dans tout ça me direz-vous ? Firefox OS intègre un moteur de recherche qui interroge à la fois le contenu du téléphone, pour trouver une application installée par exemple, mais également le contenu disponible sur Internet, en transmettant votre demande à un moteur de recherche en ligne.

messages et moteurs de recherche.png

Quand vous cliquez sur le résultat de votre choix, Firefox OS ouvre ensuite le navigateur web pour vous afficher la page demandée.

Messages dans Google

Le Fox et moi espérons que c’est clair pour vous maintenant. Si toutefois vous souhaitez aller plus loin, nous vous conseillons de consulter les pages Wikipédia consacrées aux navigateurs web et aux moteurs de recherche.

Vous pouvez également jeter un œil à cette courte vidéo que nous vous avons concoctée pour vous expliquer comment faire une recherche dans le téléphone et sur Internet avec Firefox OS 1.3.


Un mot, un concept ou même un sigle obscur ? demandez l’explication au Fox !


Mamie Fox


Aldéric


Le Mot du Fox précédent : OS

]]>
Firefox OS : Game of Life, un simulateur de vie dans votre Firefox OS https://firefoxos.mozfr.org/post/2015/07/Game-of-Life-simulateur-de-vie-dans-Firefox-OS 2015-07-21T10:30:00+00:00 Mozinet Game of LifeÀ vrai dire, « Game of Life » ou « Jeu de la vie » n’est pas à proprement parler un jeu, mais plutôt un simulateur de vie. Il a connu une grande notoriété auprès du grand public dans les année 70-80. Et c’est avec un grand plaisir que nous vous le présentons aujourd’hui.

Inventé en 1970 par John Horton Corway, ce simulateur propose de faire évoluer des cellules sur une grille que l’on pourrait comparer à une boîte de Petri carrée. Chaque case de cette grille représente une cellule. Quand elle est de couleur blanche, la cellule est « morte ». Au contraire, quand elle est noire, la cellule est vivante. Les règles de survie à chaque itération sont simples :

  • si une cellule morte (blanche) a exactement trois voisines, elle revit et devient noire.
  • si une cellule vivante (noire) a deux ou trois voisines, elle reste en vie, sinon elle meurt.

Game of Life

Ainsi, le but du jeu est de placer des cellules vivantes sur la grille et de les observer évoluer en appuyant sur le bouton lecture.

Ce simulateur fait ressortir des configurations de cellules particulières et intéressantes, telles que les « vaisseaux », les « oscillateurs », les « mathusalems », les « canons »… chacune de ses configurations évolue de manière remarquable. Les vaisseaux avancent, les canons tirent, les mathusalems évoluent en de multiples formes avant de se figer en structures stables, quant aux oscillateurs… je vous laisse deviner.

Les plus geek d’entre nous connaissent sûrement ce simulateur, car le symbole des hackers le « planeur » est issu de ce jeu ! C’est en effet la plus petite structure auto-reproductible connue.

Ce simulateur dispose d’un panneau de configuration que l’on peut activer en haut à gauche de l’écran et dans lequel on peut ajuster :

  • Speed : pour ajuster la rapidité des itérations et donc rendre le jeu plus ou moins rapide.
  • Cell Size : pour ajuster la taille des cases et donc disposer d’un plateau de jeu plus ou moins grand.
  • Pattern permet de sélectionner et d’utiliser ces fameuses configurations dont nous avons parlé plus haut.

Game of Life : paramètres

Sur l’écran principale, la barre du bas permet les actions suivantes (de gauche à droite) :

  • le « retour arrière » affiche le « pattern » sélectionné.
  • le « bouton avance » affiche l’itération suivante.
  • le bouton « lecture » lance les itérations de façon continue.
  • le bouton « éjecte » annule l’écran en cours.
  • le bouton « gomme » permet d’effacer les cellules une à une en cliquant dessus.

Jetez un œil à cette vidéo pour avoir une idée plus précise du jeu !


Vidéo Game of life sur YouTube (59 s)

Nous espérons que vous prendrez, comme nous, beaucoup de plaisir à bidouiller avec cet ancêtre du jeu vidéo.

La version de Game of Life présentée ici est aussi jouable sur un ordinateur et un appareil Android avec Firefox installé. Attention, une autre version en couleur de Game Of Life est disponible pour Firefox OS sur le Marketplace.


Et vous, quel ancien jeu aimeriez vous retrouver le Marketplace de Firefox OS ?


Aldéric

Retrouvez l’appli de la semaine dernière : Les devises de vos vacances avec Firefox OS.

]]>
Mozilla Francophone : Bloquer le chiffrement RC4 non sécurisé avec Firefox https://blog.mozfr.org/post/2015/07/Bloquez-le-chiffrement-RC4-non-securise-avec-Firefox 2015-07-20T16:28:00+00:00 Goofy par Martin Brinkmann, source : cet article de ghacks

Pourquoi désactiver RC4

Chaque fois que vous vous connectez à un site web sécurisé en utilisant Firefox ou tout autre navigateur moderne, des négociations se produisent en arrière-plan pour déterminer ce qui est utilisé pour chiffrer la connexion.

RC4 est un chiffrement de flux qui est actuellement pris en charge par la plupart des navigateurs, même s’il ne peut être utilisé que comme une solution de repli (si d’autres négociations échouent) ou pour des sites en liste blanche.

On a récemment révélé des exploits qui profitent des failles dans RC4 et permettent aux pirates d’exécuter des attaques dans un délai acceptable, par exemple pour déchiffrer les cookies web qui contiennent souvent des informations d’authentification.

Mozilla a envisagé de supprimer complètement RC4 de Firefox avec les versions 38 ou 39 du navigateur, mais a décidé d’y renoncer sur la base de données de télémétrie. Dans l’état actuel des choses, RC4 ne sera pas désactivé dans Firefox 39 ou 40.

Astuce : vous pouvez vérifier si votre navigateur est vulnérable en visitant ce site de test pour RC4. Si vous voyez des notifications rouges sur la page après l’affichage du texte, cela signifie qu’il est vulnérable aux attaques.

Il faut noter que d’autres navigateurs, Google Chrome, par exemple, sont également vulnérables. Apparemment Google travaille aussi à l’abandon complet du support RC4 dans Chrome

Comment désactiver RC4 dans Firefox

Les utilisateurs de Firefox peuvent désactiver complètement RC4 dans leur navigateur web. Il convient de noter que certains sites sécurisés peuvent ne pas fonctionner après cette opération.

Saisissez about:config dans la barre d’adresse du navigateur et appuyez sur la touche Entrée. Confirmez que vous serez prudent lorsque apparaît l’avertissement de sécurité.

Dans le champ de recherche, saisissez : RC4 et double-cliquez sur les préférences suivantes pour qu’elles passent à false

  • security.ssl3.ecdhe_ecdsa_rc4_128_sha
  • security.ssl3.ecdhe_rsa_rc4_128_sha
  • security.ssl3.rsa_rc4_128_md5
  • security.ssl3.rsa_rc4_128_sha

firefox-disable-rc4.jpg

Une fois que vous aurez opéré ces modifications, redémarrez Firefox et rechargez la page de test. Vous devriez voir des messages d’échec de connexion au lieu des avertissements.

Si vous rencontrez des problèmes de connexion à des sites sécurisés après avoir fait les changements, vous pourriez avoir besoin de rétablir la prise en charge du RC4. Pour ce faire, répétez les étapes ci-dessus et assurez-vous que les valeurs des préférences sont ramenées à true

]]>
Firefox OS : Un nouvel horizon pour Firefox OS https://firefoxos.mozfr.org/post/2015/07/Un-nouvel-horizon-pour-Firefox-OS 2015-07-19T15:00:00+00:00 Mozinet Firefox OS 2.5 à WhistlerFirefox OS 2.5 a été une surprise annoncée à Whistler au Canada où des Mozilliens (employés de Mozilla et bénévoles) étaient réunis pour un ensemble de semaines de travail fin juin. Aujourd’hui, Mozilla publie la feuille de route pour Firefox OS 2.5 et au-delà. Nous avons traduit le billet du blog de Mozilla pour vous :

Le futur de Firefox OS

Firefox OS est une importante partie de notre stratégie mobile, en plus de Firefox pour Android et d’autres initiatives. Nous croyons que le développement d’une alternative ouverte et indépendante aux plateformes propriétaires et contrôlées par un unique éditeur est essentiel pour l’avenir d’un écosystème mobile sain. Et c’est au cœur de notre mission de promouvoir l’ouverture, l’innovation et la saisie des chances offertes dans la vie en ligne.

En tant que projet open source, nous sommes différents des autres entreprises de haute technologie et faisons la plupart de notre travail et de la planification au grand jour, c’est pourquoi nous voulons partager brièvement les nouvelles de ce que nous prévoyons et ce que nous allons expérimenter lors de la prochaine étape de Firefox OS.

Initiative Ignite

Plus tôt cette année, nous avons partagé que nous passions à la prochaine étape de Firefox OS, où nous nous concentrerons sur l’expérience au cœur du produit pour nous assurer qu’il est épuré, moderne et facile à utiliser, et pourtant puissant grâce à son extensibilité, son design bien pensé et des fonctionnalités qui donnent aux utilisateurs le contrôle de leur expérience.

Notre objectif est de construire la prochaine génération de Firefox OS avec une expérience produit plus forte et plus unifiée, et une plateforme pour développeurs qui incarne nos valeurs en mettant en exergue le meilleur du Web.

Ignite au centre de la plateforme web, la communauté et le centrage sur l'utilisateurPour ce faire, nous réunissons trois idées clés :

  1. Centré sur l’utilisateur : Veiller à ce que nous offrions une expérience que les gens aiment grâce à un design, une recherche et une itération produit centrés sur l’utilisateur.
  2. La plateforme web : Apporter plus de Mozilla et de Web ouvert aux gens et pas seulement les technologies web sur lesquelles nos produits sont développés.
  3. Communauté : Mobiliser et donner pleinement les moyens à notre communauté mondiale de développeurs, designers et plus encore pour aider à construire l’avenir ensemble.

Pour répondre à cette vision, nous passons immédiatement à un modèle de développement où nous allons piloter un seul noyau open source de Firefox OS, avec des versions majeures tous les six mois, sur la base de sprints hebdomadaires.

Chaque version majeure tentera d’offrir une valeur significative à l’utilisateur et à la plateforme, et sera disponible directement pour tous ceux qui veulent flasher un téléphone Android déverrouillé ou exécuter à travers B2GDroid (une application qui vous permet de découvrir Firefox OS sur Android) pour obtenir la dernière expérience, aider à tester de nouvelles fonctionnalités et de contribuer en retour au projet global. Nous allons également soutenir nos partenaires (c-à-d les équipementiers et les opérateurs) qui construiront et distribueront des appareils propulsés par Firefox OS basés sur ces versions majeures.

2.5 RA timeline

Firefox OS 2.5

La prochaine version majeure de Firefox OS est maintenant planifiée pour ce mois de novembre. Vous pouvez voir une ébauche de la feuille de route et du plan ici.

Firefox OS 2.5 sera l’expérience Firefox OS la plus personnalisable, sécurisée, pertinente au niveau local et donnant les moyens de faire ce qu’on veut jamais vue. En plus du contenu local, de la personnalisation et des fonctions protégeant la vie privée, nous prévoyons de permettre l’équivalent mobile d’« Afficher le code source de la page » (View source) (note : nous sommes toujours en cours d’évaluation et de conception de l’ensemble des fonctionnalités final), de repenser notre modèle de sécurité pour exposer plus de la nouvelles API web mobiles aux développeurs et rendre possible un mécanisme d’extensions à la Firefox pour ajouter à l’interface utilisateur et aux capacités du téléphone.

Développement de nouveaux produits

Nous intensifions également nos efforts de développement de nouveaux produits avec des partenaires clés, s’appuyant sur les récentes annonces au sujet des téléviseurs connectés Firefox OS et feature phones (téléphones aux fonctions de base) intelligents, et des explorations actives dans l’internet des objets et les autres possibilités d’appareil connecté.

Restez à l’écoute pour les nouvelles.


Vidéo Experimental New Version of Firefox OS sur YouTube (2 min)


@Mozinet


À lire aussi : La nouvelle stratégie de Mozilla pour Firefox


Crédit illustrations : Photo n° 1 Firefox OS Central. Tous droits réservés.

Images n° 2 et 3 Mozilla.

La chronologie et la vidéo issues de Mozilla ont été ajoutées par nous à l’article initial.

]]>
BlogZiNet : La nouvelle stratégie de Mozilla pour Firefox http://blogzinet.free.fr/blog/index.php?post/2015/07/18/nouvelle-strategie-Mozilla-pour-Firefox 2015-07-18T18:59:00+00:00 Mozinet Mozilla a esquissé dans un billet du blog des versions futures de Firefox (traduit ci-dessous) début juillet une nouvelle stratégie pour sauver et relancer Firefox. Quelques jours plus tard, Dave Camp, directeur de l’ingénierie de Firefox, a posté deux messages sur la liste de diffusion firefox-dev où se déroulent les discussions relatives au développement de la version pour ordinateur du navigateur web Firefox.

Dans le premier intitulé les trois piliers, Dave articule la nouvelle stratégie de Mozilla pour Firefox autour de 3 axes principaux. Une qualité sans compromis passera par un programme baptisé « Great or Dead » (formidable ou mort) qui auditera tous les fonctionnalités du navigateur pour s’assurer que chacune d’elles soient parfaitement fignolée, fonctionnelle et une joie à utiliser. Si la fonction n’atteint pas ces standards de qualité, elle ne devra pas exister. Dans ce cas, la fonctionnalité sera retravaillée ou sinon son code devra être retiré. Alors, il faudra trouver un service tiers ou une extension qui fait bien mieux le job. La liste des fonctionnalités qui devront passer ce test sera établie et maintenue avec l’aide de la communauté.

Dave Camp prévient : attendez-vous à voir certains des efforts investis dans de nouvelles fonctionnalités être recentrés pour que des fonctionnalités existantes atteignent nos standards. E10s pour Electrolysis, le gros projet de séparation de l’exécution du programme entre un processus pour le contenu et un pour l’interface est crucial pour rendre Firefox rapide et réactif. Mais ça demande un gros travail pour adapter Firefox mais aussi Gecko, le moteur d’affichage de Mozilla. Les efforts devront être dédoublés surtout si on considère qu’un gros travail doit être fait pour adapter les extensions à ce nouveau fonctionnement de Firefox.

Le meilleur du Web sera atteint en nouant des partenariats avec la communauté qui développe des extensions et des partenaires pour développer les fonctions que Mozilla ne sait pas développer seul en interne. C’est déjà le cas avec Telefónica pour Hello (visioconférence) et l’intégration de Pocket tant décriée par la communauté. Bien que Mozilla ait fait modifier sa politique de vie privée et se soit assurer d’avoir du code open source dans Firefox, de nombreuses voix se sont élevées contre cette intégration. Mozilla en tiendra compte et y répondra. Mozilla tend à être d’accord avec tous ceux qui demandent à ce que la fonction puisse être entièrement retirée de Firefox en la livrant sous la forme d’une extension livrée avec le navigateur. La façon dont ces services intégrés apparaitront dans l’interface et seront présentés aux utilisateurs pour la première fois devra être repensée, surtout si ces intégrations de services tiers augmentent.

Ce qui rend Firefox unique ; ce troisième pilier conduira à recentrer les nouvelles fonctionnalités sur ce pourquoi les internautes ont choisi Firefox. Le navigateur leur donnera des fonctions pour les aider à mieux contrôler leur propre utilisation du Web. Le navigateur devra être actif et devra filtrer le Web en notre nom et sous notre direction. Mozilla commencera par un domaine où les internautes veulent vraiment plus de contrôle : leur vie privée en ligne. La première étape passera par l’arrivée dans Firefox prochainement d’un mode de navigation privée amélioré.

Dans le second message, Dave présente le plan pour revisiter la façon dans Firefox est développé et délivré. Le temps pour que les nouvelles fonctionnalités atteignent les nouvelles fonctionnalités sera raccourci. Le délai de délivrance des correctifs critiques doit se compter en minutes plus en jours. Les fonctionnalités individuelles seront déployées vers des publics réduits pour des tests focalisés et multivariables.

Les technologies web seraient devenues matures pour développer de grosses applications web et doivent être utilisées directement pour développer Firefox. Les technologies spécifiques à Mozilla comme XUL et XBL seront abandonnées. Les problèmes de performance reste sans solutions et cela crée de la complexité inutile dans Gecko. C’est plus difficile même pour des développeurs web expérimentés de se mettre à la page. La décision est prise mais les modalités restent à discuter. Et les questions sont nombreuses. Certaines n’ont même sûrement pas été encore posées.

Voici donc la traduction du premier billet sur le blog des versions futures de Firefox :


Nous avons créé Firefox il y a plus d’une décennie avec la mission de donner aux gens transparence, choix et contrôle en ligne. Depuis lors, le navigateur a continué à faire évoluer son rôle essentiel dans la façon dont les internautes utilisent le Web et contrôlent leur vie en ligne.

Voilà pourquoi chez Mozilla nous sommes toujours concentrés sur une seule question : comment pouvons-nous rendre Firefox encore meilleur et continuer à réjouir les utilisateurs ? Parce que nous sommes différents de la plupart des entreprises de haute technologie et que nous travaillons au grand jour, nous partageons quelques expériences centrées autour des trois axes prioritaires de notre stratégie.

Firefox Pillars : Quality, Uniquely Firefox, Best of the Web

Une qualité sans compromis

Le premier axe prioritaire est de procurer une expérience utilisateur sans compromis qui assure que Firefox atteigne les standards de qualité et de performances les plus rigoureux. Cet engagement est évident dans les progrès que nous faisons pour améliorer les expériences les plus riches du Web comme la lecture vidéo HTML5 et les performances des jeux. Nous allons également bientôt proposer Firefox sur de nouvelles plateformes, telles que Firefox pour iOS et Windows 10, où nous allons fournir une alternative indépendante et très performante au navigateur intégré d’origine.

Le meilleur du Web

Firefox est réputé pour donner aux utilisateurs un contrôle complet sur leur expérience du Web tout en repoussant les limites du « navigateur moderne ». Aujourd’hui, nous travaillons avec plusieurs partenaires et développeurs du monde entier pour mettre en évidence l’innovation et offrir le meilleur du Web dans Firefox. Nous avons montré cela avec notre nouvelle stratégie de recherche pour Firefox pour promouvoir le choix et l’innovation et avec les nouvelles technologies ouvertes que nous développons sur la base de standards, dont Firefox Hello, le premier outil de chat vidéo WebRTC intégré au navigateur conçu en partenariat avec Telefónica. Nous continuons d’être pionnier des standards ouverts dont WebVR, WebGL et WebRTC pour faire progresser le Web comme plateforme de développement.

Ce qui rend Firefox unique

Plus tôt cette année, nous avons demandé aux utilisateurs d’identifier ce qui fait que Firefox est différent et les résultats ont réaffirmé notre opinion selon laquelle il est important pour Firefox d’être de plus en plus reconnu pour des caractéristiques telles que la performance, la confiance et la qualité qui cadrent avec notre mission.

Nous désirons que nos utilisateurs nous fassent confiance parce que nous protégeons leurs choix et leur vie privée. Voilà pourquoi nous expérimentons des améliorations de la navigation privée et d’autres fonctionnalités uniques pour une version majeure axée sur ces trois principes que nous partagerons avec les utilisateurs de Firefox plus tard cette année.

Restez à l’écoute pour les nouvelles.


Le document original et cette traduction sont soumis aux conditions de la licence
Creative Commons : « Paternité – Partage des conditions initiales à l’identique 3.0 »
ou toute version postérieure.

License Creative Commons

Sources et références

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

]]>