MozFR

Mozilla Firefox 49

Firefox 49 : mode lecture : en cours de lecture à voix hauteUne semaine ! C’est le délai supplémentaire qui a permis à Mozilla de déboguer Firefox et de corriger des vulnérabilités de dernière minute. Depuis la sortie, une mise à jour mineure de stabilité est venue régler un problème spécifique à Windows (plus d’infos en anglais).

Dans cette version 49, la nouveauté la plus visible et qui parlera à tous les utilisateurs est la lecture à haute voix dans le mode lecture déjà très pratique. Dans Firefox 49 pour Android, vous apprécierez l’affichage de la version de la page hors connexion en cas de perte de celle-ci.

Montée en charge du multi-processus

Firefox 49 : informations de dépannage : Fenêtres multi-processus : 0/1 (désactivé par des  modules complémentaires)Mozilla met l’accent sur le déploiement continu du multi-processus et l’amélioration des performances constatée. Le mois dernier, nous avons commencé à déployer la nouveauté la plus significative de notre histoire. Nous avons ajouté des capacités de multi-processus à Firefox pour ordinateur, ce qui veut dire que Firefox répond mieux et est moins sujet à des blocages. En fait, nos tests initiaux montrent des améliorations de 400 % pour la réactivité globale. Mozilla a aussi communiqué sur des améliorations de 700 % de la réactivité dans le chargement de grosses pages web.

Dans Firefox 48, seuls les utilisateurs n’ayant pas installé de module complémentaire pouvaient faire partie de cette première phase de déploiement. Dans cette version, nous avons étendu la prise en charge à un petit ensemble initial des modules compatibles, avec pour objectif une expérience en multi-processus pour tous les utilisateurs de Firefox en 2017. Le multi-processus, qui était limité à un seul processus de contenu et un seul processus de navigateur, va progressivement comporter plusieurs processus de contenu et la mise en bac à sable (sandboxing).

Mozilla va toujours être prudent dans le déploiement et tester des groupes similaires où cette fonction de multi-processus est activée et où elle ne l’est pas encore. Dans les semaines à venir, le multi-processus sera activé pour 100 % de la cohorte initiale d’utilisateurs. Dans les six prochains mois, une majorité d’utilisateurs peuvent s’attendre à disposer de ces capacités. Firefox 52 ou 53 pourrait avoir de multiples processus de contenu séparés (plus d’infos en anglais).

Firefox 49 : Nightly : 2 processus

La parole est donnée au mode lecture

Firefox 49 : mode lecture : nouvelles icônesLe mode lecture disponible pour ordinateur comme pour Android est une super fonction, voire indispensable pour certains sites. Quand Firefox détecte un article, il en isole le texte et parfois les images d’illustration et l’affiche d’une manière uniformisée pensée pour faciliter la lecture.

Le mode lecture dans Firefox 49 pour ordinateur passe à un stade supérieur avec un relookage, des fonctions de personnalisation supplémentaires et surtout la lecture à voix haute. Même si cette dernière option peut être très utile aux personnes avec certaines déficiences, elle risque de se faire une place dans la vie en ligne de tout un chacun.

Quand vous cliquez sur la nouvelle icône, vous avez même une référence à une célèbre fable française. Vous pouvez en régler la vitesse de diction, sous les boutons de lecture arrière et avant pour changer de paragraphe. En bas, vous pouvez choisir entre les voix disponibles. Elles dépendent de votre système d’exploitation. Vous apprécierez de pouvoir changer d’onglet et que la lecture continue (voyez l’icône de son pour indiquer l’onglet bavard). Remarquez aussi le détail : quand vous reprenez une lecture après l’avoir interrompue grâce au bouton stop, elle redémarre au paragraphe où vous étiez.

Firefox 49 Windows : mode lecture : voixFirefox 49 Linux : mode lecture : voix

Notez que ce mode n’exige pas d’accès à un service distant, mais fonctionne grâce aux capacités de synthèse vocale de votre système d’exploitation, le tout relié par l’API Web Speech. La fonction ne sera donc pas homogène d’une marque à l’autre, d’une distribution à l’autre, d’une configuration à l’autre ou d’un pays à l’autre.

Si vous préférez lire vous-même, Firefox 49 permet de nouvelles personnalisations du thème du mode lecture. En plus du choix du type de police, de sa taille et de la couleur du fond (sépia c’est top !), vous pouvez désormais rétrécir ou agrandir la largeur de la colonne (vous pouvez ainsi vous faire un mode de colonne étroit comme un journal papier) et la hauteur de l’interligne.

Firefox 49 : mode lecture : polices

On se demande toutefois pourquoi Mozilla n’a pas rendu ce mode automatique, au moins sur la base des sites consultés.

Une option cachée de Firefox 49 permet d’ajouter à l’aperçu avant impression une case à cocher « Simplifier la page » qui utilise le mode lecture de Firefox pour modifier la mise en page afin de faciliter la lecture. Cette option permet aussi d’économiser de l’encre et du papier en n’imprimant que le contenu essentiel de la page.

Firefox 49 : aperçu avant impression : simplifier la page

Au revoir Hello

On vous épargnera le titre Goodbye Hello, mais il s’agit bien d’un adieu. L’expérimentation de la technologie WebRTC (qui elle continue) pour produire un système de visioconférence augmenté de partages d’onglets ou de fichiers et de discussion instantanée textuelle n’a pas trouvé son public, face, il est vrai, à un marché encombré de solutions plus performantes même si propriétaires. L’aide de Mozilla propose des solutions alternatives toujours dans le navigateur. L’extension Firefox Hello Beta aussi se désinstallera elle-même.

Malgré des avantages comme être multi-navigateur et multiplateforme, Hello, qui permettait de passer des appels audio et vidéo sans inscription, installation ni plugin, était aussi accusé d’alourdir le navigateur et de parfois provoquer des consommations mémoire gigantesques. Cette fonctionnalité expérimentale est une nouvelle victime de la politique qui passe en revue les fonctionnalités de Firefox et ne garde que celles qui peuvent être portées au niveau « super » en interne.

Moins de Flash mais des DRM aussi pour Linux

Comme vous avez pu le lire ici en juillet, Mozilla a un plan pour l’extinction des plugins et la réduction de l’usage de Flash dans Firefox.

Mozilla va bloquer les fichiers Flash de très petites tailles non visibles pour les utilisateurs et essaie de réimplémenter en HTML seul les fonctionnalités de base utilisées. La liste de Mozilla bloque des supercookies et des témoins d’empreinte numérique. La réduction des éléments Flash est aussi destinée à faire baisser fortement les plantages du navigateur.

Toujours dans la traduction évoquée ci-dessus était mentionnée l’arrivée des DRM par l’implémentation du standard EME (Encrypted Media Extensions) pour le HTML5 permettant l’affichage de contenu vidéo en provenance de Netflix et d’Amazon. La solution de Google arrive avec Firefox 49 sur Linux, alors que Windows dispose déjà de ce plugin nouvelle génération et de celui d’Adobe. Ces composants de gestion des droits numériques appelés « Content Decryption Module (CDM) » déchiffrent, décodent et affichent la vidéo protégée (plus d’infos en anglais).

Firefox 49 : plugins : modules de déchiffrement de contenu

L’aide de Mozilla a un article qui explique comment désactiver les DRM, et comment refuser et désinstaller les DRM. Mozilla met à disposition des Firefox sans DRM.

Amélioration de la sécurité

Comme toute version majeure de Firefox, cette version 49 est un mise à jour de sécurité. 18 failles sont comblées dont 4 critiques.

Mais, Mozilla a aussi amélioré le gestionnaire d’identification de Firefox qui permet désormais aux pages HTTPS de se servir des identifiants, dont les mots de passe, enregistrés en HTTP pour le même domaine, mais pas le contraire. Mozilla inscrit cette nouveauté dans son effort pour démocratiser le HTTPS avec des initiatives comme Let’s Encrypt.

Cette version comprend la prise en charge du nouveau protocole cryptographique TLS 1.3 standardisé par l’IETF. Cette version du protocole n’est pas activée par défaut.

Les pages hors connexion dans Firefox pour Android

Firefox 49 pour Android : Affichage de la version hors connexionLa version 49 de Firefox pour Android introduit l’affichage des pages hors connexion. Dorénavant quand vous n’avez pas de connexion, Firefox affichera la version de la page enregistrée avec le message : « Affichage de la version hors connexion ».

L’apparence et le comportement des onglets de Firefox pour Android ont été améliorés :

  • Les anciens onglets sont désormais masqués lorsque le paramètre de restauration des onglets vaut « Toujours restaurer ».
  • Mémorisation de la position du défilement et du niveau de zoom utilisé pour les onglets ouverts.
  • Mise à jour des commandes de médias pour éviter de jouer des sons provenant de plusieurs onglets en même temps.
  • Des améliorations visuelles dans l’affichage du favicon.

Les écrans de premier lancement ont été mis à jour pour illustrer plusieurs fonctionnalités indispensables comme le mode lecture et la synchronisation.

Firefox pour Android diffuse désormais des notifications asynchrones grâce à l’API Push.

Firefox 49 pour les développeurs

Le Mozilla Developer Network, MDN de son petit nom, dispose d’une liste des modifications apportées à Firefox à destination des développeurs.

Dans les outils pour développeurs, le moniteur de réseau dispose désormais d’une colonne « Source ».

Firefox 49 : DevTools : Réseau : colonne Source

La liste des erreurs JavaScript affiche pour chaque élément un lien « En savoir plus » qui mène à une page du MDN pour faciliter le débogage.

Et bien d’autres améliorations à découvrir dans l’article de Mozilla Hacks.

Firefox 49 : DevTools : Console JS : En savoir plus : Référence MDN

Les développeurs web liront avec profit cet autre article qui explique comment Firefox 49 arrange les sites conçus avec uniquement WebKit à l’esprit (préfixe -webkit-).

okcupid webkit

Les développeurs d’extensions en général apprécieront le billet du blog des modules complémentaires sur les WebExtensions dans Firefox 49.

Fins de prise en charge

Mac OS X 10.6, 10.7 or 10.8 – Snow Leopard, Lion et Mountain Lion – ne sont plus pris en charge (pour les autres). Ces versions sont toujours prises en charge par la version longue durée pour les entreprises et organisations, Firefox ESR, pour quelque temps encore.

Sous Windows, la prise en charge des processeurs SSSE a également pris fin avec cette version.

Améliorations de performances sans accélération matérielle

Les performances du navigateur ont été améliorées sur les systèmes Windows sans accélération matérielle.

Pour les systèmes Mac sans accélération matérielle, les performances ont aussi été améliorées.

Les vidéos profitent désormais d’une accélération via les instructions SSSE3 du processeur lorsque l’accélération par le processeur graphique n’est pas disponible.

Lecteur vidéo HTML5

Firefox 49 : lecteur vidéo HTML5 : menu contextuelLe lecteur audio et vidéo HTML5 par défaut dispose désormais de commandes pour jouer les fichiers en boucle et pour accélérer la vitesse de lecture à 1,25.

Firefox 49 propose une préférence cachée qui permet de fixer une fraction du volume du lecteur HTML5 par défaut.

Mais encore…

L’apparence des polices OS X lissées a été améliorée. Firefox 49 a aussi réactivé la valeur par défaut pour le façonnage des polices Graphite2.

Le prochain train est attendu le mardi 8 novembre avec Firefox 50.

Télécharger Firefox pour ordinateur

Installer Firefox pour Android

Firefox 49 : Mozilla : page de téléchargement

Les onglets contextuels dans Firefox Nightly

Attention : cette fonctionnalité est encore expérimentale et peut être amenée à évoluer :)

Pourquoi faire ?

« Mais dis-moi plutôt qui tu es ? », Rafiki, Le Roi Lion

Lorsque nous naviguons sur le Web, nous utilisons différents sites pour différents besoins. Notre identité numérique se compose parfois de différentes identités selon le contexte : personnel, professionnel, consommation, etc. En revanche, il était jusqu’à présent difficile d’organiser cette compartimentation via le navigateur web (utiliser différents navigateurs, la navigation privée, différents profils, etc.).

La fonctionnalité d’« onglet contextuel », implémentée dans Firefox Nightly, a été conçue pour répondre à ce besoin de séparation. Ainsi, au sein d’une même session et d’un même profil, on pourra se connecter, simultanément, sur un compte personnel et, par exemple, sur un compte professionnel (ou autre) d’un site donné (Twitter, Google, Facebook, Trello…).

Cette séparation permet également de limiter le pistage des différents sites en isolant les données créées par chacun. Nul besoin que les publicités (disons Facebook) laissent des traces à destination des autres sites (disons Amazon). En utilisant ces sites dans des contextes séparés, les cookies, entre autres, seront compartimentés. En plus de ces aspects relatifs à la vie privée, cela permet d’obtenir une meilleure sécurité : cela améliore la protection contre le vol de cookies de session d’un site bancaire par exemple.

Note : les onglets contextuels ne sont pas la réponse à toutes les questions, les profils ou Tor Browser ont toujours leurs raisons d’être.

Les différents contextes

La compartimentation ne se limite pas nécessairement au caractère personnel/professionnel. Pour cette fonctionnalité, Mozilla a prévu un premier ensemble de contextes :

  • Personnel
    • exemple d’utilisation : le compte Twitter personnel, la page Gmail sur une adresse électronique privée,
  • Professionnel
    • exemple d’utilisation : les documents Google des clients de l’entreprise (:]]), la page Facebook de la société maintenue à jour,
  • Bancaire
    • exemple d’utilisation : suivre mon compte bancaire, accéder à des documents privés sur le portail de mon assurance,
  • Achats en ligne
    • exemple d’utilisation : RedBubble, Amazon…

Par la suite, en plus de ces catégories prédéfinies, il est prévu de pouvoir ajouter des contextes personnalisés. Enfin, il y a un contexte par défaut, le contexte « normal » (ce qui vous permet d’utiliser Firefox sans nécessairement avoir recours aux contextes).

Lorsque vous cliquez sur un lien depuis un contexte « Personnel », le nouvel onglet sera automatiquement rattaché au contexte « Personnel » (idem pour les autres).

Comment les utiliser ?

Tout est expliqué dans cette vidéo :

Et si vous préférez lire, voici la suite :

Prérequis : À l’heure actuelle, cette fonctionnalité est uniquement disponible sur le canal Nightly de Firefox. Pour l’utiliser, vous pouvez télécharger cette version sur ce site de la communauté francophone ou encore sur ce nouveau site mozilla (NB : vous pouvez tout à fait utiliser une version « classique » de Firefox en parallèle d’une « Nightly » afin de tester :) ). Si vous souhaitez désactiver cette fonctionnalité, vous pouvez utiliser la préférence privacy.userContext.enabled avec la valeur false via sur la page about:config.

Pour ouvrir un nouvel onglet contextuel, vous disposez de différentes options.

1. Avec le menu hamburger

  1. Cliquer sur l’icône en haut à droite icône menu hamburger
  2. Cliquer sur « (+) Personnaliser » en bas
  3. Ensuite, vous pouvez glisser le bouton « Onglet contextuel » dans le menu (à droite) ou dans votre barre d’outils

Aperçu du bouton dans l'écran de personnalisation

L’écran de personnalisation

Aperçu du bouton d'onglet contextuel dans le menu

Accéder au bouton lorsqu’il est dans le menu

Aperçu du bouton dans la barre principale

Accéder au bouton lorsqu’il est dans la barre d’outils

2. Avec le menu « Fichier » de la barre de menus

Si vous utilisez la barre de menu, cette option est disponible dans le menu « Fichier » : Aperçu du menu via la barre de menus

2. Grâce à la liste d’onglets

Si vous naviguez avec de nombreux onglets, vous pourrez utiliser la liste d’onglets pour ajouter un nouvel onglet contextuel : Aperçu du menu via la liste d'onglets

Note : Cette option apparaît uniquement lorsque le navigateur n’a plus suffisamment d’espace pour afficher chacun des onglets.

3. Via les hyperliens

Une fois que vous avez ouvert un nouvel onglet contextuel, tout lien sur lequel vous cliquerez ouvrira un onglet rattaché (ex. je suis sur mon Twitter avec le contexte « Personnel », si je clique sur un lien vers lesjours.fr, celui-ci sera ouvert dans le contexte « Personnel »). Mais que se passe-t-il si je suis sur Twitter (perso) et que je vois un lien vers Amazon (achats) ? Lorsqu’on clique droit sur un lien, on dispose d’une nouvelle option permettant de choisir le contexte dans lequel on veut ouvrir le nouvel onglet :

Nouvelle option du menu contextuel via les liens

Quelques illustrations

Pour s’y retrouver, on dispose de deux indicateurs :

  • Une ligne colorée au-dessus de l’onglet
    • Bleue : contexte personnel
    • Orange : contexte professionnel
    • Verte : contexte bancaire
    • Rose : contexte pour les achats en ligne
    • Rien : le contexte par défaut Aperçu des indicateurs visuels
  • Pour l’onglet actif, un symbole à la fin de la barre d’adresse

Sous le capot

La technique

Les onglets contextuels ne sont pas des profils séparés. D’ailleurs, ils fonctionnent au sein d’un même profil (autrement dit, chaque profil embarque son propre ensemble de contextes).

Note : Pour en savoir plus, comme pour chaque fonctionnalité de Firefox, vous pouvez consulter Bugzilla. Les onglets contextuels sont poétiquement décrits dans le bug 1191418.

À l’origine

En fait, les contextes reposent principalement sur la notion d’origine. Une origine se définit par un schéma (ex. http/https), un hôte (le domaine) et le port. Cette origine est déjà employée par le navigateur pour décider si telle ressource provenant de telle origine est sécurisée et peut être chargée (cf. MDN). En ajoutant des informations à l’origine d’une page, on peut enrichir cette fonctionnalité (c’est ce que font déjà la navigation privée, le Tor Browser, etc.). Gecko utilise donc des informations complémentaires, appelées OriginAttributes pour déterminer si deux origines sont équivalentes.

Pour les onglets contextuels, un nouvel attribut : userContextId a été ajouté à ces informations. Chaque contexte aura son propre userContextId et les informations stockées par les sites seront compartimentées en tenant compte de cette information.

Les onglets contextuels ajoutent ainsi un nouvel élément de sécurité contre les attaques de type XSS et CSRF.

Pas touche à mes cookies

On vient de le voir, lorsque je navigue sur Twitter via un onglet contextuel « personnel », Firefox utilise l’origine combinée avec l’attribut userContextId afin de déterminer les informations auxquelles cet onglet Twitter aura accès. Il ne pourra pas, par exemple, accéder aux informations d’un autre onglet supersecurebanking.net, qui, elles, sont stockées avec un autre attribut userContextId. Ouf.

Mais qu’entend-on par donnée personnelle ? Qu’est-ce qui est compartimenté ? Qu’est-ce qui ne l’est pas ?

Ce qui est isolé :

Ce qui n’est pas isolé :

  • L’historique
  • Les marque-pages
  • Les mots de passe enregistrés
  • L’historique des recherches et des formulaires
  • Les permissions accordées aux sites web
  • Les exceptions de certificats de sécurité
  • Des trucs ésotériques comme les marqueurs HSTS et les réponses OCSP

Les limites

Les onglets contextuels augmentent la sécurité des données via cette compartimentation. Mais celle-ci n’est pas absolue, votre ordinateur aura toujours la même IP, le même agent utilisateur, le même système d’exploitation, etc. Si la séparation des cookies protège contre un pistage basique, il faut être conscient que le fingerprinting avancé est toujours possible, même avec les onglets contextuels. Selon les cas d’usage, le navigateur [Tor Browser] peut être une alternative pertinente. Ce dernier maximise l’anonymat en ligne quitte à casser certaines fonctionnalités des sites visités, les onglets contextuels visent à améliorer la vie privée tout en conservant les fonctionnalités des différents sites.

La suite

Voici quelques pistes pour l’avenir de cette fonctionnalité :

  • L’amélioration de l’ergonomie et de l’interface utilisateur : ce n’est pas parce que cette fonctionnalité concerne la sécurité et la vie privée, qu’elle ne doit pas être claire, accessible et attirante. Elle doit pouvoir bénéficier aux personnes qui ne maîtrisent pas ces enjeux.
  • Le nettoyage des données relatives à chaque contexte (qui a dit qu’il fallait passer en navigation privée pour acheter un cadeau ?)
  • Ouvrir un onglet contextuel en appuyant longtemps sur (+) lorsqu’on veut ouvrir un nouvel onglet
  • Les contextes personnalisés ou limités à un site
  • Régler quelques bugs relatifs
  • Recevoir votre avis grâce à ce sondage ou via containers@mozilla.com

Liens & sources

Se lancer dans l’open source : un témoignage engageant

Comment participer à des projets open source et s’y sentir légitime ? La réponse habituelle un peu désinvolte consiste à dire : « il suffit de commencer à proposer ne serait-ce qu’un signalement de bug ou une correction mineure dans la documentation et hop ». En commençant par une contribution minime, on peut donc trouver sa place dans une équipe. Théoriquement, c’est exact.

Mais quand on est une jeune femme à peine sortie de ses études d’informatique et qu’on éprouve un peu d’appréhension au contact des contributeurs supposés expérimentés, rien n’est tout à fait simple.

Comme on le lira dans le témoignage de Shubheksha, il faut non seulement parvenir à surmonter son manque de confiance en soi, mais aussi avoir la chance de rencontrer sur son chemin des mentors qui vous accueillent avec bienveillance, vous guident et vous invitent à contribuer davantage encore.

Le parcours cahoteux d’une débutante dans le monde de l’open source

Article original paru dans Medium : A Beginner’s Very Bumpy Journey Through The World of Open Source

Par Shubheksha

Traduction :  Lyn, audionuma, goofy, Lumibd, Manguito,et un anonyme

shubhekshaAvez-vous atterri ici en recherchant des conseils sur la meilleure manière de contribuer à l’open source ? Il y a des milliers d’histoires de ce genre sur Internet, n’est-ce pas ?
Je suis sûre que vous en avez lu beaucoup à présent, car vous essayez de contribuer depuis un bon moment. Et vous avez toujours l’impression de ne pas avoir progressé.
Je connais ce sentiment. J’étais exactement dans la même situation il y a quelques semaines. Laissez-moi vous conter mon histoire.

Voilà à peu près deux ans que j’essaie de contribuer à l’open source.

Oui. Deux ans.

Et il y a bien une chose que je peux affirmer : c’est intimidant. C’est dur de commencer. Vous devez apprendre comment travailler sur un long code source. Vous devez apprendre et adopter les règles de style de code d’un projet.

Tout paraît confus. L’ordre des instructions, comment les différents modules interagissent entre eux, comment et pourquoi le code est organisé de la manière dont il l’est : tout cela constitue un grand labyrinthe.

Je ressens cela en permanence car je ne suis, après tout, qu’une amatrice qui essaie d’en apprendre autant qu’elle le peut.

J’ai donc choisi de suivre la voie la plus facile : la correction de fautes dans la documentation ou les commentaires, et la résolution de bugs triviaux où il était évident de trouver ce qui devait être modifié. Je ne voulais pas poser trop de questions ni essayer de comprendre l’ensemble du code.

Chaque fois que je voulais contribuer, j’allais sur github — ou un autre gestionnaire de bugs – et j’essayais de rechercher des problèmes étiquetés « facile », « débutant », « premier bug facile ». Après en avoir consulté des centaines, je trouvais quelque chose de suffisamment simple à traiter sans beaucoup d’aide extérieure.

Alors, cela a bien fonctionné jusqu’au moment où j’ai pris conscience que je pourrais mieux utiliser les compétences que j’étais en train de développer. J’avais appris tant de nouvelles choses, mais je ne voyais pas à quoi j’aurais pu les utiliser. Apprendre sans mettre en application, c’est bien peu gratifiant. J’étais bloquée sur un palier et je n’avançais plus du tout.

Alors, il est arrivé quelque chose qui m’a terriblement effrayée en tant que nouvelle contributrice qui essaie de naviguer dans le monde de l’open source. J’avais trouvé un bug qui avait l’air assez facile dans un grand projet renommé.

J’ai pensé qu’il valait mieux demander quelques éclaircissements avant de procéder à la moindre modification car je craignais de tout bousiller. J’ai donc envoyé un commentaire indiquant que j’étais une nouvelle contributrice, et demandant quelle serait la meilleure manière de modifier un bout de texte pour corriger le bug.

La réponse que je reçus fut :

« Si tu n’arrives pas à déterminer comment effectuer cette modification, c’est que tu n’es pas qualifiée pour effectuer cette modification. »

Cette réponse me laissa complètement décontenancée, et m’effraya davantage encore à l’idée de poser des questions lorsque je ne comprenais pas quelque chose à propos d’un projet.

Peut-être étais-je indésirable parce que je n’en savais pas assez ? Peut-être devais-je travailler davantage pour acquérir des compétences au lieu de poser des questions stupides et maladroites à des personnes expérimentées beaucoup trop occupées pour me répondre ?

C’est aussi à cette époque que ma recherche d’un mentor a commencé. J’ai pensé que si je connaissais quelqu’un avec qui je serais plus à l’aise pour poser des questions, les choses se passeraient bien et je pourrais me rendre plus utile.

J’ai donc écrit à de nombreuses personnes en leur demandant de m’aider à débuter, vu que je me sentais particulièrement intimidée par mes précédentes expériences. J’ai reçu beaucoup de réponses positives, pleines d’encouragements, mais je n’ai jamais exactement trouvé ce que je cherchais.

J’avais l’impression de buter contre un environnement clos dans le monde ouvert de l’open source.

Tout semblait suggérer que je n’avais qu’à m’y mettre et à ne pas avoir peur. Mais je n’étais pas prête à ce moment là.

Moi, fuyant le monde du logiciel open source

Ma découverte de Mozilla

Par une belle soirée, alors que je cherchais des bugs à corriger, j’ai atterri sur le projet de Mozilla qui vous aide à tester des extensions web. J’étais contente de voir qu’il y avait quelques problèmes étiquetés comme « premier bug facile » mais aucun d’entre eux n’était aussi simple que de corriger une petite coquille.

Bon sang, j’en suis tellement heureuse maintenant.

J’ai commencé à travailler sur l’un de ces bugs, mais j’ai vite compris qu’il me faudrait poser des questions si je voulais être capable de résoudre le problème. J’ai parcouru le code source. Après avoir compris les grandes lignes du problème, j’ai demandé plus d’informations. et voila ! J’ai été capable de résoudre le problème une fois que j’ai eu tous les détails nécessaires.

Maintenant que j’ai soumis trois pull requests [NDT : demandes de modification du code source] (l’une a été acceptée, les deux autres sont en passe de l’être), je suis heureuse d’avoir franchi le pas. Je suis contente de ne pas avoir hésité à poser des questions pertinentes, même si je risquais parfois d’avoir l’air de poser des questions stupides.

Ce n’est pas un problème de ne pas tout savoir et de progresser par étapes pour apprendre quelque chose de nouveau.

Les gens de Mozilla qui encadrent ces corrections m’ont beaucoup aidée et ont toujours été très positifs. Ils m’ont guidée du début à la fin, prenant le temps de m’expliquer les choses de façon à la fois simple et très détaillée. Et cela malgré le fait qu’ils n’auraient mis que quelques heures à corriger ces problèmes eux-mêmes au lieu de prendre le temps de me guider vers une solution de mon cru, dont la conception m’a pris plusieurs jours.

J’ai appris et découvert énormément de choses juste en travaillant sur ces trois problèmes basiques. Et je suis vraiment excitée à l’idée de travailler sur des problèmes encore plus difficiles et d’augmenter ma compréhension de ce sujet et mes connaissances.

l'insatiable vieux dino de Mozilla se goinfre de bugs

l’insatiable vieux dino de Mozilla se goinfre de bugs

Je ne peux pas les remercier assez pour cette expérience tellement positive et enrichissante, qui m’amène à installer Firefox localement et à parcourir les bugs sur Bugzilla un jour sur deux (je garde mes questions sur « Pourquoi » et « Comment » pour un billet plus long).

Je prévois de contribuer à Mozilla aussi régulièrement que possible. À chaque fois que j’ai posé une question pertinente, que ce soit sur IRC, Github ou Bugzilla, j’ai reçu des réponses très aimables.
Jusqu’à aujourd’hui, j’ai résolu trois problèmes dans web-ext, et j’ai eu un correctif accepté et intégré dans Firefox.

Mes contributions ont été remarquées par la communauté, et j’ai aussi été nommée dans le « Addons Contribution Recognition document » [NdT : la liste des contributeurs aux extensions de Mozilla].

En définitive, mes expériences de ces dernières semaines ont été vraiment merveilleuses. J’ai appris tellement de choses, petites et grandes, qu’aucun manuel de programmation n’aurait pu m’apprendre.
Voici mes conseils pour les développeurs débutants qui veulent contribuer à un projet open source :

Conseil n°1 : n’ayez pas peur de poser des questions

Je ne saurais trop insister sur ce point. J’ai perdu beaucoup de temps parce que je ne cessais de me censurer, et c’était ma plus importante inhibition.

Tout le monde a peur de paraître stupide. Mais ne laissez pas cette peur paralysante devenir une entrave à votre progression.

Il est normal de demander si vous ne comprenez pas quelque chose qui est en rapport avec le projet. Les développeurs du projet sont devenus des experts au fil des années. Ils peuvent vous aider très rapidement. Sinon vous risquez de perdre des heures le nez dans le code source à essayer de deviner quelque chose que vous n’êtes même pas censés savoir au départ.

Mais quand vous demandez des informations, vérifiez si elles ne sont pas déjà disponibles dans une documentation ou une recherche Google. Ainsi, vous prendrez garde à respecter le temps libre des développeurs du projet.

Conseil n°2 : c’est normal d’avoir des lacunes

On ne s’attend pas à ce que vous sachiez tout de A à Z lorsque vous commencez à contribuer à un projet. Le processus, c’est plutôt que vous appreniez et gagniez en compétence en résolvant des problèmes de plus en plus difficiles, et en vous familiarisant avec le projet et les outils qu’il utilise. Le temps nécessaire pour cela varie d’un projet à l’autre et d’une personne à l’autre.

Conseil n°3 : lancez-vous !

Ne perdez pas un temps considérable à choisir le projet idéal. Si vous connaissez un projet ou une organisation dont la communauté accueille amicalement les débutants, faites-en votre point de départ.

Trouvez un problème avec lequel vous êtes à l’aise, de préférence dans un langage que vous pratiquez déjà depuis un moment, et essayez d’imaginer ce qui a besoin d’être fait. Demandez des informations pertinentes afin de combler vos lacunes, et après, lancez-vous ! N’attendez pas.

Merci à tous ceux qui travaillent dans l’open source

Une dédicace spéciale à tous les contributeurs aux projets open source qui sont super réactifs et qui encouragent les nouveaux. Vous aidez les nouveaux venus à se frayer un chemin au milieu d’interminables lignes de code et les faites contribuer de manière peut-être limitée mais néanmoins significative. Vos efforts sont nécessaires et sincèrement appréciés.

En tant que débutante et développeuse junior, j’essaie juste de trouver mon chemin dans le vaste et formidable monde de l’informatique. Quelques minutes de votre temps, que ce soit pour me présenter une simple technique de débogage ou pour me montrer comment écrire correctement des tests logiciels, m’aideront, au fil du temps, à devenir une meilleure développeuse.

Vous avez l’expérience et j’ai l’envie insatiable d’apprendre autant que je peux.

Un grand merci à Guido, Kumur McMillan et Luca qui ont été de fabuleux mentors tout au long de ce parcours, ils m’ont suivie à chaque instant et ont répondu à mes diverses questions. J’ai vraiment apprécié le temps et les efforts que vous m’avez consacrés :)

Si vous êtes un nouveau venu qui peine à entrer dans le monde de l’open source, j’aimerais que vous me parliez de votre histoire et de votre expérience. Si je peux vous aider de quelque façon que ce soit, surtout n’hésitez pas à me contacter.

J’envisage de rendre compte de mon parcours chez les contributeurs de l’open source, donc si vous désirez que j’aborde un sujet en particulier, merci de laisser un commentaire.
Merci à Pawan Dubey et Quincy Larson pour m’avoir aidée à peaufiner cet article.

Le Web est en danger, la réforme européenne du droit d'auteur pourrait tout casser

Il y a trois jours, Mozilla, sous la plume de sa directrice des affaires juridiques et commerciales, Denelle Dixon-Thayer, a jugé « inadaptée » la proposition de la Commission européenne pour une réforme du droit d’auteur dans l’Union. Il est encore temps d’agir.

Aujourd’hui, nous publions la traduction d’un billet de Nino Vranešič, Mozilla Rep et bénévole slovène. Il était présent, le week-end dernier, à Berlin où des Mozilliens européens ont pu discuter de cette réforme et des moyens d’action, après une présentation depuis Bruxelles de Raegan MacDonald de l’équipe Net Policy de Mozilla.


Cela fait des décennies et des décennies que des lois sur le droit d’auteur (copyright) sont en vigueur.

Petite rétrospective historique : la première Révolution industrielle était basée sur l’eau et la vapeur pour mécaniser la production. La deuxième se fondait sur l’électricité, qui permit la production de masse. La troisième se fondait elle sur l’électronique connectée et les technologies d’information pour automatiser la production. Aujourd’hui nous vivons dans la « quatrième Révolution industrielle », que l’on appelle aussi la Révolution numérique.

Navigating the next industrial revolution - timeline

La Révolution numérique se caractérise par une fusion entre technologie et société. Elle brouille les limites entre les sphères physique, numérique, et biologique.

Mais ce n’est que le commencement. Nous développons constamment de nouvelles technologies : l’Internet des objets, l’impression 3D, la réalité augmentée, la réalité virtuelle, l’informatique quantique, les nanotechnologies, les biotechnologies, les véhicules autonomes, etc.

On se confronte à des défis nouveaux et des opportunités infinies. On ne peut pas prédire dans quelle direction cette révolution nous mènera, mais l’histoire suggère que cela pourrait être la combinaison ou même la multiplication des technologies existantes. Tandis qu’on continue d’avancer, encore et toujours, dans cette « ère numérique », nos lois se font de plus en plus vieilles et obsolètes.

C’est avec l’industrie de l’édition que l’histoire du droit d’auteur a commencé, historiquement influencée par les cadres sociopolitiques et juridiques. Jurgen Habermas a inventé le terme de « sphère publique » (public sphere), façonnée par la sociologie, la politique, l’économie et les lois.

Cette théorie peut être très utile pour comprendre n’importe quelle loi moderne sur le droit d’auteur à venir.

Public sphere theory

Dans ce contexte, les auteurs en tant que groupe ont historiquement joué un rôle important dans le développement des lois sur le droit d’auteur. Avec l’avènement du Web et d’Internet en général, les médias numériques ont transformé la sphère publique en changeant les modèles de discours publics. Internet a considérablement étendu la portée de la sphère publique. Les auteurs créent dans un espace global et non plus dans des espaces publics limités.

On fait face à une révolution où chaque utilisateur n’est pas simplement un consommateur, mais aussi un créateur de contenu sur le Web. Internet est devenu une plateforme d’innovation, d’opportunités, et de créativité.

Handrawn poster - users must be actors

C’est ici que les artistes, programmeurs, développeurs, hackers, entrepreneurs, éducateurs, chercheurs et tous les utilisateurs du Web créent, partagent, lisent et collaborent.

Reform copyright law in Europe !La Commission européenne essaie de concevoir un cadre plus européen pour le droit d’auteur, qui moderniserait les règles du droit d’auteur dans l’Union européenne. Mais ils n’y parviennent pas. Certaines lois dans l’UE n’ont pas rattrapé leur retard avec la Révolution numérique. L’une d’elles est le cadre juridique du droit d’auteur qui est obsolète et empêche ou même interdit (en fonction des pays) des fondements mêmes de la plateforme ouverte qu’est le Web : collaboration et ouverture. Ce cadre légal a été écrit avant même qu’Internet ne change radicalement notre façon de vivre.

Ces lois s’opposent au style de vie du XXIᵉ siècle.

Il est illégal de partager une photo des éclairages de la tour Eiffel la nuit. Elles sont soumises au droit d’auteur. Et les touristes n’en ont pas l’autorisation, spécifique aux artistes.

Dans certaines parties de l’UE, créer un mème Internet est techniquement illégal. Il n’existe aucune exception de fair-use à l’échelle européenne.

Dans certaines parties de l’UE, éducateurs, enseignants ou professeurs ne peuvent montrer des films ou partager des ressources éducatives dans une salle de classe, à cause de restrictions de droit d’auteur.

Vous trouvez que c’est absurde ?

C’est encore pire que cela. La Commission européenne vient de proposer (14 septembre 2016) quelque chose qui pourrait enterrer nos espoirs d’un cadre légal du droit d’auteur qui puisse être moderne, flexible et technologiquement neutre. Au lieu de tout cela, ils soutiennent le blocage géographique et la censure de contenus. Cela montre au mieux qu’ils refusent l’innovation et le passage au numérique. Nous (les Européens) méritons mieux et nous devrions nous battre pour nos droits.

Cette nouvelle proposition pourrait avoir de lourdes conséquences pour n’importe quel utilisateur du Web. Les éditeurs de médias obsolètes font pression (avec succès) à travers le monde pour restreindre le fait de partager des liens sur Internet.

L’Espagne et l’Allemagne ont récemment changé leurs lois pour mettre en place des frais à payer pour un lien vers un site web d’actualités. Les médias indépendants et les blogueurs ne peuvent plus travailler. Les agrégateurs de contenu ont du mal à survivre, les petits médias voient leurs sites web dé-listés, et l’accès à la connaissance est restreint. À présent, les entreprises médiatiques vieillissantes font pression pour faire appliquer des lois qui censureront les liens dans l’Union européenne toute entière.

Les internautes et les entreprises devraient pouvoir partager des liens librement vers des contenus et des services de leur choix.

Les liens sont essentiels à la liberté d’expression en ligne et les experts nous avertissent de l’évidence : censurer des liens reviendrait à « casser le Web » tel qu’on le connaît.

Les règles de la Commission incluent des méthodes chères et invasives pour surveiller et filtrer le contenu des utilisateurs. Cela signifie censurer certains de vos contenus favoris, qui pourraient littéralement disparaître des moteurs de recherche et du Web. Non seulement les utilisateurs de l’UE seront touchés, mais tous les utilisateurs de par le monde le seront.

Vous trouvez ça encore plus absurde ?

Corrigeons le droit d’auteur ensemble. Voici trois choses qui peuvent aider :

1. Actualiser la loi européenne relative au droit d’auteur pour le 21e siècle. 2. Introduire de la souplesse et faire preuve d’ouverture pour encourager l’innovation et la créativité. 3. Ne pas casser l’Internet.

Battons-nous pour des lois qui ont du sens au XXIᵉ siècle. Des lois qui soutiennent la créativité, l’inclusion, la diversité et la collaboration dans nos vies numériques.

Dites à l’Union européenne que nous avons besoin d’une loi sur le droit d’auteur qui soit meilleure, plus moderne et qui respecte les fondamentaux du Web ouvert.

Vous êtes avec moi ?

Signez la pétition dès aujourd’hui : changecopyright.org.

–– Nino Vranešič (@ninovranesic)



Traduction Nildëala et relecture par la communauté

jEdit bugs: Getting off the Ground with Kinto and Kinto.js

jEdit bugs: Getting off the Ground with Kinto and Kinto.js

This is a guest post by Eric Le Lay on his experience using Kinto.

Introduction

Have you heard of jEdit — the programmer's text editor?
It's a multi-platform text editor, written in Java, with a myriad of plugins. I've been part of the development team for ten years. It's hosted on Sourceforge, with the code base under Subversion.

This is a labour of love for us, contributing during our free time. For me, that's when I'm on holidays. I don't always have Internet access where I'm staying. Or it's via a short Ethernet cable in a dark and overheated room. Don't lock me out of the sunny garden! Give me everything I need off-line!

  • Java sources and Javadoc: install the openjdk7-doc and openjdk7-src packages;
  • jEdit and plugins sources: with git-svn I get the code and history;
  • bugs and feature requests: oops!

We have 1100 open tickets and 7600 closed. None of them are available offline. That needs to change!

Grabbing a ticket archive

Sourceforge lets project admins download an archive of their project, containing tickets and other things. A script of mine converts them to a bunch of HTML files, with a little JavaScript for navigation. Resulting HTML files are then uploaded to jedit.org/trackers where they can be browsed online or downloaded.

To save space, only open tickets are available.

Sourceforge takes minutes to generate the project archive, so I run the export at most once per week. It's not convenient for users either, because they have to download a new archive to get an up-to-date view of tickets. Even downloading the latest archive doesn't give them the freshest state, because it can be a week old at worst: lots of room for improvements!

My Goals

  • be able to incrementally update tickets;
  • better ticket search and visualization; maybe even offline modification;
  • I'd like to try Kinto :-).

First Steps with Kinto

I've heard about Kinto from Rémy and Alexis. As with couchdb/pouchdb, it's possible to sync the database between the server (Kinto) and the browser (kinto.js). Kinto.js stores data in IndexedDB so it should be possible to work with a biggish database.

Each user can create his own collections (think SQL tables) in Kinto. There are even finer grained permissions, document by document (think SQL rows).

To Do List

I've begun with the tutorial. It nicely introduces Kinto basics: create documents, show them, modify them, sync with a remote server. It uses Mozilla's hosted test server: one less barrier to try it out.

Tickets instead of Tasks

I've moved to a local Kinto server for my next steps: it's very easy to deploy using docker. If you plan to batch-import documents, install the PostgreSQL backend straight away (easy to install using docker-compose; just follow the instructions). The In-Memory backend has issues with parallel batch import requests (which happens when you import in a node.js script with request).

Once tickets are imported, the webapp has just to fetch them via kinto.js's sync()and display them.

Local Search with kinto.js

Searching in the browser with kinto.js is not as rich as on the server: it supports only a conjunction of key: [value1, value2, ...] parameters. Querying the id, _status, last_modified is accelerated by an index (code here). All documents are then loaded and returned in an array, then filtered according to remaining query params. Arbitrary queries are done by the application on the result of the list() operation. This is fine for small collections, but searching is not lighting fast when you reach 8k documents.

An example of full-text search (from a keyword in a text field):

function filterByKeyword(keyword){
  return function(doc){
    return doc.summary.indexOf(keyword) >= 0;
  };
}

function search(){
  var keyword = document.getElementById("query");
  return tickets
    .list()
    .then(function(res){
      return res.data.filter(filterByKeyword(keyword));
    });
}

// on submit
search().then(render);

Architecture

I'm hosting my Kinto server on a C1 server at scaleway. It contains 2 collections:

  • tickets, for open or recent tickets;
  • oldTickets, for tickets closed before 2016.

I use Sourceforge's ticket id instead of an auto-generated id. This way I can update the database more easily (no need to fetch the kinto document before updating it, since I know the content and the id).

Clients are web applications.

An updater script forwards modifications from Sourceforge to the Kinto database.

The C1 machine has an ARM processor and runs Debian Jessie. So a few deviations to the standard setup were necessary (see the wiki kinto).

The kinto.js Client

My goal was to learn kinto.js, not your latest front-end framework, so I quite liked the vanilla take on the tutorial and stuck with it:

  • bootstrap CSS, fontawesome icons,
  • a few utilities: moment, lodash,
  • datatables (after devising my own row management, but not wanting to implement row details myself and having found a nice example for this).

screenshot of the application

Initial State

When you load the application for the first time a panel shows you ticket counts, lets you choose to include old tickets and download the database.

Here is how I determine if it's the first run:

tickets.db.getLastModified().then(function(res) {
    if (res) {
        hasDB();
    } else {
        noDB();
    }
});

To display the server's ticket count before sync, one has to go down to the kinto-http package (this is being worked on, see this issue).

code snippet:

function fetchTotalRecords(api, bucket, name, etag) {
    var headers = {};
    headers["Authorization"] = "Basic " + btoa("token:tr0ub4d@ur");
    return api.client.execute({
        path: "/buckets/" + bucket + "/collections/" + name + "/records" + (etag ? ("?_since=" + etag) : ""),
        method: "HEAD",
        headers
    }, {
        raw: true
    }).then(function(res) {
        console.log("RES", res);
        return parseInt(res.headers.get("total-records"));
    });
}

tickets.db.getLastModified().then(function(lastMod) {
    var api = tickets.api.bucket(tickets.bucket).collection(tickets.name);
    // you'll soon be able to replace it with api.getLastModified(lastMod)
    return fetchTotalRecords(api, tickets.bucket, tickets.name, lastMod);
}).then(renderTicketCount);

This method also works to find out if updated tickets exist on the server ( via the ETag). The kinto server doesn't respond instantly as it should. Maybe I should also put the ETag in an If-None-Match header to speed things up.

Searching for Tickets

I've used lunr to implement client-side full text search. It builds a Lucene-like index and then lets one query this index. The index is serialized and saved as a document in a local Kinto.js collection to be reused on next page load.

Searching the index returns an array of document ids, from which I load documents before filtering the resulting (usually small) array with remaining query params. This is performing better than the first version of the application, when I first loaded all documents by calling tickets.list().

To search for hello in the lunr index:

> index.search("hello")
   [{"ref":"52a4d8cb27184667e3400f42","score":0.019459983366287688},
    {"ref":"5690ff3f24b0d96f08df7d6a","score":0.013994677485991343},
    ...
   ]

To get a { data: ['array', 'of', 'tickets', 'containing', 'myText'] } Promise:

return Promise.all(index.search(myText).map(function(hit) {
    return tickets.get(hit.ref);
})).then(function(allRes) {
    return {
        data: allRes.map(function(res) {
            return res.data;
        })
    };
});

Matching documents are fetched from IndexedDB in parallel via their Id (collection.get()). It's fast because IndexedDB is optimised for key based access, but it could be more efficient to use tickets.list({filters: {id: ['array', 'of', 'ids']}}) to curb request count.

Displaying a Ticket

My application is meant to be multi-tab, browser history and bookmarks compatible. To achieve that, the UI state is stored in the URL and interactions result in calls to pushState().

var state;

function encodeState(state) {
    return "#" + encodeURIComponent(JSON.stringify(state));
}

function applyState(state) {
    document.getElementById("search").value = state.filter;
    search();
}

function saveState(state) {
    window.history.pushState(state, "jEdit Trackers", encodeState(state));
}

function hashIsTicket() {
    return window.location.hash.match(/^#[a-z0-9-]+$/);
}

window.addEventListener("popstate", function(e) {
    // called on browser history navigation
    if (e.state) {
        state = e.state;
        applyState(state);
    } else {
        if (hashIsTicket()) {
            // show this ticket
        } else {
            // show search interface
        }
    }
});

A ticket can be displayed from the result list by clicking Open. Nothing fancy: the id is put in the URL's hash and the application parses the hash at startup.

function restoreInitialState() {
    if (window.location.hash.match(/^#[a-z0-9-]+$/)) {
        showTicket(window.location.hash.substring(1));
    } else if (window.location.hash.startsWith("#%7B")) {
        try {
            state = JSON.parse(decodeURIComponent(window.location.hash.substring(1)));
        } catch (e) {
            console.log("invalid state in hash", window.location.hash);
            state = defaultState();
        }
        applyState(state);
    } else {
        state = defaultState();
        applyState(state);
    }
}

restoreInitialState(); // to restore state from bookmark or link at page load

Updates

Documents have to be updated in Kinto whenever a ticket is modified at Sourceforge's trackers. I do this via a server-side program.

updater.py

There is no way to get a real-time modification stream from Sourceforge.

A few ideas to work around that:

  1. poll each tracker's RSS feed (limited to 10 tickets so one can miss updates if the script lags at some point);
  2. poll each tracker's REST API, asking for tickets modified since last time (delay < polling period);
  3. subscribe to the jedit-devel mailing list and fetch mails with a pop3 client (delay < 1 minute).

I've chosen solution 2. The updater.py script:

  1. fetches the trackers list from Sourceforge,
  2. fetches from kinto the last update date (a document in the updater collection),
  3. queries Sourceforge for tickets modified since this date,
  4. pushes updates to the tickets and oldTickets collections.

Tickets are returned by Sourceforge in JSON format. There is only minimal mapping to do (fetch comments via a second request to Sourceforge).

Client Notifications

Kinto seems to provide websockets notifications but I've not looked into it.

Clients are instead polling the kinto server for new tickets every minute. When there are, a little would you like to sync? notification appears on the top-right of the page.

Following a synchronization, I update the lunr index with modified/added/deleted documents (index.add(document), index.remove(document)).

Counters displayed on buttons (missed, open bugs) are then recomputed and stored in a client collection. When there are no deletions I can update them incrementally, otherwise I have to go through the whole collection to recompute them.

Conclusion

Was Kinto Worth a Try?

Definitly yes. It's a sound platform and a good fit for my application. However it's not an out-of-box experience like meteor. One has to combine it with other libraries to create a full application. On the other hand, it makes deployment and debugging simpler.

Performance is fine (batch importing the 8k tickets keeps my little server busy for 5 minutes) and the system is open.

I made things a bit complicated for myself by splitting tickets into 2 collections, but not loading the old tickets is a huge performance boost.

To Do List (not the tutorial)

I've spent 3 weeks exploring Kinto and still have things to try out. I'm also far from a full-fledged application.

Some leads:

Modifying Tickets
I'd like to be able to modify tickets from the application, instead of having to use the Sourceforge UI. Modifications could be possible offline, kept in kinto.js until network connectivity is restored.

Nothing prevents it but it takes a lot of development to make a nice UI. I'll first look into FormBuilder before rolling out my own. If actual interaction with trackers is too much, maybe letting users tag, star, follow tickets for themselves could be useful (stored in kinto to sync between their devices).

User Interface The UI could be improved greatly. I also plan to refactor the code to take advantage of react, since there exists some boilerplate and kinto-admin for inspiration.

Attachments Tickets are available offline, but not attachments (attachments like the log with the stack trace I need to fix a bug). So no 100% offline experience yet! I'd like to distribute these attachments, maybe using Kinto Attachments. Attachments are a total of 10MB for fresh tickets, plus 18MB for old ones: it seems feasible.

Full Text Search I make very basic use of lunr.js: indexing the title and description fields. But the index is already quite big and slow to (de)serialize from IndexedDB. I wonder if I should enrich it, allowing more powerful queries or define my own query language and use indexes on my side.

Indexing should take place in a WebWorker, to not stall the application.

Performances Tickets could be indexed by number, to speed up this kind of query (ids are unique in a project, numbers are unique in a tracker). Also, indexing on other predefined search criteria could speed things up.

Manually managing indexes would be feasible (a document per index, mapping each value of the field to an array of document ids). Then, looking for all open bugs would look like:

indexes.get("bug").then(resInd){
    var ind = resInd.data; // ind = { open: ["id1", "id2", ...], ...}
    return Promise.all((ind.open).map(tickets.get.bind(tickets)))
                  .then(function(multiRes){
                      return multiRes.map(function(res){ return res.data;})
                  });
});

Thank You!

I'd like to thank the Kinto team for their kindness and their openness: reachable on IRC (#kinto) and Slack, they encourage issues and PRs. Many of which are even accepted ;-)

My code is available on github: elelay/jedit-trackers-kinto.
The application is available at trackers.elelay.fr.
Feedback is welcome via IRC (elelay) — why not even Issues and PR?

Mozilla vous attend aux Journées du patrimoine les 17 et 18 septembre

Bureau Mozilla Pa Les Journées européennes du patrimoine 2016 se dérouleront le 17 et 18 septembre. Le thème pour cette année en France sera : Patrimoine et Citoyenneté, avec de nombreux lieux ouverts gratuitement ou à tarifs réduits.



Les bureaux de Mozilla Paris (18 s) sur YouTube

Depuis 2013, les bureaux parisiens de Mozilla sont installés dans un monument historique classé et il ouvrira ses portes les 2 jours pour vous recevoir pendant ces Journées européennes du Patrimoine 2016.

Hotel de Mercy-Argenteau

Mozilla Paris est installé dans le 9ᵉ arrondissement de la capitale au cœur de l’hôtel de Mercy-Argenteau, au 16 bis, boulevard Montmartre. Bâti en 1778 par l’architecte Firmin Perlin dans un style Louis XVI, cet hôtel devint rapidement la propriété du comte de Mercy-Argenteau, ambassadeur d’Autriche à Paris de 1783 à 1790 et qui avait été précepteur de la future reine Marie-Antoinette.

L’association 9ᵉ Histoire proposera 2 visites guidées pour chacune des 4 demi-journées du week-end.

La cuisine de Mozilla Paris

En dehors des horaires des visites guidées, les visites seront libres les deux jours.

Des bénévoles de la fondation qui développe le célèbre navigateur web Firefox seront là tout le week-end pour vous faire découvrir les enjeux du Web d’aujourd’hui : vie privée, logiciel libres, Internet et téléphonie mobile…

Fondation Mozilla
16 bis, boulevard Montmartre – 9ᵉ arrondissement de Paris
Ouverture : samedi de 10 h à 18 h (4 visites guidées)
et dimanche de 10 h à 17 h (4 visites guidées)
Gratuit
Accès handicapé

Les horaires des visites guidées de 9ᵉ Histoire sont :

  • Samedi 17 septembre : 10h30 / 12h00 / 14h30 / 15h30 
  • Dimanche 18 septembre : 10h30 / 11h30 / 14h30 / 16h00

Restez branché sur nos réseaux sociaux (Facebook et Twitter) pour les dernières nouvelles.

Liens utiles :

Bannière JEP2016

Pour préparer votre visite :


@hellosct1

Défenseurs des droits et entreprises technologiques en justice contre les fouilles électroniques secrètes

Gagged Washington (CC By-NC 2.0) art around Après avoir soutenu Apple contre le FBI qui prétendait pouvoir lui imposer d’inclure des portes dérobées dans ses produits, les défenseurs des droits et les entreprises technologiques dont Mozilla soutiennent Microsoft dans son action en justice contre le ministère de la Justice des États-Unis et ses ordonnances judiciaires qui bâillonnent les entreprises Internet en leur ordonnant le silence sur les informations et les comptes auxquels les forces de l’ordre ont eu ainsi accès. Nos bénévoles de la communauté vous ont traduit le billet de la directrice des affaires juridiques et commerciales de Mozilla, Denelle Dixon-Thayer, et l’article d’annonce de l‘Electronic Frontier Foundation (EFF) :

Contre-attaque contre les ordonnances secrètes

Mozilla se joint aujourd’hui à une coalition d’entreprises technologiques – dont Apple, Lithium et Twilio – pour déposer un mémoire d‘amicus curiae en soutien de Microsoft dans son affaire contre l’usage sans discernement d’ordonnances de non-publication. De tels commandements empêchent les entreprises de notifier à leurs utilisateurs les demandes du gouvernement concernant leurs données.

La transparence est le pilier central pour tout ce que nous faisons chez Mozilla. C’est fondamental pour la façon dont nous développons nos produits, avec un code source que n’importe qui peut inspecter, et c’est essentiel à notre vision d’un web ouvert, sécurisé, auquel on peut faire confiance et qui donne aux utilisateurs le contrôle de leur vie en ligne. Nos efforts de réforme dans les domaines de la divulgation des vulnérabilités et de la surveillance gouvernementale reposent sur l’idéal de transparence.

Et la transparence – ou plus exactement l’absence de celle-ci – est la raison pour laquelle nous nous soucions de cette affaire. Quand sont demandées des données personnelles, ces ordonnances de non-publication sont parfois rendues sans que le gouvernement ait démontré pourquoi cette imposition du silence est nécessaire. Pire encore, le gouvernement impose des règles à durée indéfinie qui empêchent les entreprises d’avertir leurs utilisateurs même des années après et longtemps après que chacun est d’accord pour dire que l’ordonnance de non-publication n’est plus nécessaire. Ces actes sacrifient inutilement la transparence sans aucune justification. C’est insensé et inacceptable.

Nous n’avons pas encore reçu d’ordonnance de non-publication qui nous empêcherait de notifier un utilisateur d’une requête pour ses données. Néanmoins, nous estimons qu’il est mauvais pour le gouvernement de repousser indéfiniment le délai pour qu’une entreprise puisse fournir  une notification à l’utilisateur. C’est ce que nous avions déclaré quand nous avons publié notre rapport de transparence en mai, nous avions dit que nous prendrions des mesures pour mettre en œuvre cette conviction. C’est exactement ce que nous avons fait aujourd’hui.

— Denelle Dixon-Thayer, directrice des affaires juridiques et commerciales de Mozilla

Le document original comme cette traduction sont sous licence CC By-SA 3.0


L’EFF à la cour : Le gouvernement doit informer les gens qu’il a accédé à leurs courriels et données personnelles

Ignorer le devoir de donner une notification d’une intrusion dans la vie privée des utilisateurs est inconstitutionnel

Seattle, État de Washington — L‘Electronic Frontier Foundation (EFF) a déclaré aujourd’hui à une cour fédérale que le gouvernement enfreint la constitution des États-Unis quand il omet de notifier aux gens qu’il a violé ou analysé leurs communications privées stockées par leur fournisseur Internet dans le cloud.

L’EFF soutient Microsoft dans son procès contestant des parties de l‘Electronic Communications Privacy Act (ECPA) qui autorisent le ministère de la Justice (DOJ) à délivrer une injonction à une entreprise pour avoir accès aux courriels et autres informations stockées sur ses serveurs distants, tout cela sans dire aux utilisateurs que leurs données ont été fouillées ou saisies. Dans un mémoire déposé dans l’affaire Microsoft v. Department of Justice pendante devant la cour fédérale du district de Seattle, l’EFF avec Access Now, New America’s Open Technology Institute et la juriste Jennifer Granick affirment que les protections du Quatrième Amendement[1] contre les perquisitions sans motif légitime et les saisies par le gouvernement s’appliquent à toutes nos informations, qu’importe leur format et où elles se situent.

« Si le gouvernement a un mandat pour fouiller dans nos courriers, nos coffres-forts ou nos courriels stockés dans le cloud, il doit avertir les gens de ces fouilles », déclare l’avocat employé par l’EFF, Lee Tien. « Quand des fouilles électroniques sont faites en secret, nous perdons notre droit à contester la légalité des ingérences des forces de l’ordre dans notre vie privée. Le Quatrième Amendement ne permet pas cela et il est temps pour le gouvernement de se conformer à la Constitution et de la respecter. »

Microsoft a poursuivi le DOJ au cours de l’année contestant les dispositions de l’ECPA édictées il y a 30 ans, bien longtemps avant l’émergence de l’informatique en nuage (cloud computing) omniprésent qui joue désormais un rôle vital dans le stockage de nos communications privées. Le gouvernement a utilisé la transition vers l’informatique en nuage comme une occasion pour conduire des investigations secrètes en se servant de mandats secrets de perquisition des fournisseurs de services Internet en cherchant à obtenir les courriels de leurs utilisateurs, selon les poursuites. Le gouvernement qui prétend au rejet de l’action ne veut pas que les titulaires de comptes soient informés qu’on a accédé à leurs données à cause d’une disposition inconstitutionnelle de l’ECPA, alors que des fournisseurs de services comme Microsoft sont interdits de prévenir leurs clients des fouilles.

« Quand les gens conservent leurs lettres personnelles dans le tiroir du bureau de leur domicile, ils savent si ces informations sont sur le point d’être fouillées parce que la police a frappé à leur porte et leur a montré un mandat », déclare l’avocat employé par l’EFF, Sophia Cope. « Le fait qu’aujourd’hui nos courriels privés sont conservés sur un serveur maintenu par une entreprise Internet ne modifie pas les obligations du gouvernement en vertu du Quatrième Amendement. La Constitution exige des forces de l’ordre qu’elles disent aux gens qu’ils font l’objet d’une fouille, ce qui leur permet de faire valoir leurs droits et donne une société libre avec un moyen crucial de demander des comptes au gouvernement. »

L’EFF remercie l’avocat de Seattle Venkat Balasubramani de FocalLaw P.C. pour son assistance comme conseiller local.

Le mémoire : https://www.eff.org/document/microsoft-v-justice-department-amicus-brief

À propos de l’affaire : https://www.eff.org/cases/microsoft-v-department-justice


Note du traducteur

Note 1 : « Le droit des citoyens d’être garantis dans leurs personne, domicile, papiers et effets, contre les perquisitions et saisies non motivées ne sera pas violé, et aucun mandat ne sera délivré, si ce n’est sur présomption sérieuse, corroborée par serment ou affirmation, ni sans qu’il décrive particulièrement le lieu à fouiller et les personnes ou les choses à saisir. » Quatrième amendement de la Constitution des États-Unis sur Wikipédia.



Traduction @Mozinet, relecture Théo et Hellosct1

Crédit illustration : Gagged Washington, photo prise par art around le 29 mars 2012 sous licence CC By-NC 2.0 — Flickr

Survoler les bugs avec Kinto

Survoler les bugs avec Kinto

Voici un article rédigé par Eric Le Lay sur son utilisation de Kinto.

Introduction

Connaissez-vous jEditl'éditeur de texte des développeurs ?
C'est un éditeur de texte multi-plateforme, écrit en java, disposant de nombreux plugins. Je participe à son développement depuis une dizaine d'années. Nous l'hébergeons sur Sourceforge ; le code principal est sous Subversion.

Nous sommes bénévoles et le maintenons sur notre temps libre. Pour ma part, je n'ai pas toujours accès à internet pendant les vacances. Ou via un câble Ethernet dans une pièce sombre et surchauffée. Tout ça pour dire que j'aime avoir un maximum de choses sous la main hors-ligne :

  • sources et doc de la plateforme java : pas de problème avec les packages openjdk7-doc et openjdk7-src ;
  • sources de jEdit et des plugins : avec git-svn j'ai le code et son historique ;
  • bugs et feature requests : oups!

Nous avons 1100 tickets ouverts et 7600 clos. Tout ça n'est pas disponible hors-ligne. Ça doit changer !

Comment obtenir une archive des tickets ?

Sourceforge permet aux admins de télécharger une archive du projet, dont les tickets. Actuellement un script les convertit en un paquet de fichiers HTML avec un peu de javascript pour la navigation. Le résultat (fichiers HTML pour un usage en-ligne et archive téléchargeable) est déployé via rsync sur jedit.org/trackers. Pour limiter le volume, seuls les tickets ouverts sont disponibles.

La génération de l'archive du projet par Sourceforge prend plusieurs minutes, c'est pourquoi je la lance au plus une fois par semaine. Pour les utilisateurs, ce n'est pas très pratique, car il faut qu'ils téléchargent une nouvelle archive pour avoir une vue à jour des tickets. Elle peut avoir une semaine de retard : peut mieux faire.

Objectifs

  • je voudrais permettre la mise à jour incrémentale des tickets ;
  • je voudrais enrichir la visualisation des tickets : possibilité de recherche améliorée ; peut-être permettre la modification hors-ligne ;
  • je voudrais essayer Kinto :-).

Mes premiers pas avec Kinto

J'ai entendu parler de Kinto par Rémy et Alexis. Comme avec couchdb/pouchdb, il est possible de synchroniser la base de données entre le serveur (Kinto) et le navigateur web (kinto.js). Kinto.js stocke les données dans IndexedDB donc il est possible de manipuler une base relativement volumineuse.

Chaque utilisateur peut créer ses propres collections (l'équivalent des tables SQL) Kinto. Il est même possible de gérer les permissions document par document (l'équivalent des lignes SQL).

Le tutoriel : ToDo list

J'ai commencé par le tutoriel. Il présente bien les opérations: créer des documents, les afficher, les modifier, synchroniser avec le serveur. Il s'appuie sur le serveur Kinto de test de mozilla : donc un obstacle de moins pour démarrer.

Des tickets au lieu des tâches

Je suis passé à un serveur kinto local pour mes tests : il est déployable très facilement via docker. Si vous envisagez d'importer des documents, utilisez tout de suite le backend PostgreSQL (aussi facile à mettre en place, avec docker-compose ; tout est expliqué). Le backend en RAM pose des problèmes lors d'import batch en parallèle (ce qui se produit si vous importez depuis un script node.js utilisant request).

Une fois les tickets importés, l'application web n'a plus qu'à les récupérer via la synchronisation kinto.js et les afficher.

Recherche locale avec kinto.js

La recherche locale avec kinto.js n'est pas aussi développée que la recherche sur le serveur : seule la conjonction de clé: [valeur1, valeur2, ...] est supportée. La recherche sur les champs id, _status et last_modified est accélérée par un index (code ici). Ensuite, tous les documents sont chargés et retournés sous forme de tableau puis filtrés selon les critères restants. Le filtrage selon des critères plus complexes se fait par l'application sur le résultat de list(). Dans les cas de petites collections c'est simple et de bon goût mais avec 8000 documents la recherche devient un peu lente.

Exemple de recherche complexe par mot clé (champ de texte) :

function filterByKeyword(keyword){
  return function(doc){
    return doc.summary.indexOf(keyword) >= 0;
  };
}

function search(){
  var keyword = document.getElementById("query");
  return tickets
    .list()
    .then(function(res){
      return res.data.filter(filterByKeyword(keyword));
    });
}

// on submit
search().then(render);

Architecture

J'héberge mon serveur kinto sur un serveur C1 chez scaleway. Il contient deux collections :

  • tickets, pour les tickets ouverts ou récemment fermés ;
  • oldTickets, pour les tickets fermés avant 2016.

J'utilise l'id des tickets chez Sourceforge plutôt qu'une id auto-générée. Je peux ainsi mettre à jour la base facilement à partir des infos de Sourceforge (pas besoin de rechercher le document chez kinto avant de le mettre à jour puisque je connais l'id).

Les clients sont des applications web.

Un script de mise à jour reporte les modifications de Sourceforge dans la base.

La machine étant un serveur ARM sous debian Jessie, quelques aménagements ont été nécessaires (détails sur le wiki kinto).

Client kinto.js

Mon objectif était d'abord d'en apprendre le maximum sur kinto.js. J'ai bien aimé le coté vanilla du tutoriel (pas de dépendance à n frameworks) et suis resté sur cette simplicité :

  • le CSS de bootstrap, les icônes de fontawesome
  • quelques utilitaires : moment, lodash,
  • datatables (après avoir fait ma propre gestion de table, mais voulant déplier certaines lignes de la table et ayant trouvé un exemple tout prêt).

Capture d'écran de l'application

État initial

Lorsque vous accédez pour la première fois à l'application, un panneau vous est présenté proposant de récupérer les tickets, dont éventuellement les vieux tickets.

Petite astuce pour déterminer si c'est la première fois :

tickets.db.getLastModified().then(function(res) {
    if (res) {
        hasDB();
    } else {
        noDB();
    }
});

Pour afficher le nombre de tickets sur le serveur avant de les récupérer, il faut descendre dans le package kinto-http.

Le code correspondant (bientôt simplifié) :

function fetchTotalRecords(api, bucket, name, etag) {
    var headers = {};
    headers["Authorization"] = "Basic " + btoa("token:tr0ub4d@ur");
    return api.client.execute({
        path: "/buckets/" + bucket + "/collections/" + name + "/records" + (etag ? ("?_since=" + etag) : ""),
        method: "HEAD",
        headers
    }, {
        raw: true
    }).then(function(res) {
        console.log("RES", res);
        return parseInt(res.headers.get("total-records"));
    });
}

tickets.db.getLastModified().then(function(lastMod) {
    var api = tickets.api.bucket(tickets.bucket).collection(tickets.name);
    return fetchTotalRecords(api, tickets.bucket, tickets.name, lastMod);
}).then(renderTicketCount);

Cette méthode fonctionne aussi pour déterminer s'il y a eu du nouveau sur le serveur (via l'ETag). Le serveur kinto ne répond pas instantanément. Il faudrait peut-être passer l'etag en If-None-Match en plus de since pour accélérer les choses.

Recherche

Pour la recherche en texte libre coté client, j'ai utilisé lunr. Il construit un index à la Lucene, et permet ensuite de rechercher dans cet index. L'index est sérialisé et enregistré comme un document d'une collection kinto.js cliente pour être réutilisé à la prochaine visite.

La recherche dans l'index retourne un tableau d'id de documents depuis lequel j'extrais les documents, avant de filtrer ce petit tableau avec les autres critères. Cela a accéléré les choses par rapport à la première version de l'application, dans laquelle je commençais toujours la recherche par un tickets.list(), qui retournait tous les documents.

Pour rechercher hello dans l'index en mémoire :

> index.search("hello")
   [{"ref":"52a4d8cb27184667e3400f42","score":0.019459983366287688},
    {"ref":"5690ff3f24b0d96f08df7d6a","score":0.013994677485991343},
    ...
   ]

Pour obtenir une promesse d'un objet { data: ['tableau', 'de', 'tickets', 'contenant', 'texteLibre'] }:

return Promise.all(index.search(texteLibre).map(function(hit) {
    return tickets.get(hit.ref);
})).then(function(allRes) {
    return {
        data: allRes.map(function(res) {
            return res.data;
        })
    };
});

Dans ce code, tous les documents sont récupérés d'IndexedDB en parallèle via leur Id (collection.get()). C'est rapide car IndexedDB est optimisé pour l'accès par clé, mais il serait peut⁻être plus efficace d'utiliser tickets.list({filters: {id: ['tableau', 'des', 'ids']}}) pour limiter le nombre de requêtes.

Affichage d'un ticket

L'application est conçue pour être multi-onglet, permettre la navigation dans l'historique et la création de marques pages. Pour cela, l'état est stocké dans l'url et les recherches entraînent des appels à pushState().

var state;

function encodeState(state) {
    return "#" + encodeURIComponent(JSON.stringify(state));
}

function applyState(state) {
    document.getElementById("search").value = state.filter;
    search();
}

function saveState(state) {
    window.history.pushState(state, "jEdit Trackers", encodeState(state));
}

function hashIsTicket() {
    return window.location.hash.match(/^#[a-z0-9-]+$/);
}

window.addEventListener("popstate", function(e) {
    // called on browser history navigation
    if (e.state) {
        state = e.state;
        applyState(state);
    } else {
        if (hashIsTicket()) {
            // show this ticket
        } else {
            // show search interface
        }
    }
});

On peut afficher un ticket dans un autre onglet en cliquant sur Ouvrir dans un résultat de recherche. Rien de bien compliqué : l'id est mise dans le hash de l'url et l'application interprète ce hash au chargement.

function restoreInitialState() {
    if (window.location.hash.match(/^#[a-z0-9-]+$/)) {
        showTicket(window.location.hash.substring(1));
    } else if (window.location.hash.startsWith("#%7B")) {
        try {
            state = JSON.parse(decodeURIComponent(window.location.hash.substring(1)));
        } catch (e) {
            console.log("invalid state in hash", window.location.hash);
            state = defaultState();
        }
        applyState(state);
    } else {
        state = defaultState();
        applyState(state);
    }
}

restoreInitialState(); // to restore state from bookmark or link at page load

Mises à jour

Lorsqu'un ticket est modifié coté Sourceforge il faut mettre à jour le document correspondant dans Kinto. Je le fais via un programme coté serveur.

updater.py

Il n'est pas possible d'obtenir les modifications de tickets Sourceforge en temps réel via les technologies web.

Quelques idées pour les obtenir :

  1. interroger périodiquement le flux RSS de chaque tracker (limité à 10 tickets donc on peut rater des mises à jour si le script ne s'exécute pas pendant un moment) ;
  2. interroger périodiquement l'API REST de chaque tracker, en demandant les tickets modifiés depuis la dernière fois (délai < période de polling) ;
  3. s'abonner à la mailing list jedit-devel et les récupérer avec un client pop3 (délai < 1 minute).

J'ai choisi la solution 2. Le script updater.py

  1. récupère la liste des trackers chez Sourceforge,
  2. récupère de kinto la date de dernière mise à jour (document dans une collection updater),
  3. interroge Sourceforge sur les tickets modifiés depuis cette date,
  4. pousse les mises à jour dans les collections tickets et oldTickets.

Les tickets sont déjà en JSON, avec un minimum de mapping à faire (récupérer les commentaires via une seconde requête à Sourceforge).

Notifications client

Kinto semble disposer d'un mécanisme de notification via websockets mais je ne l'ai pas exploré.

Les clients interrogent le serveur kinto pour les nouveaux tickets toutes les minutes. Lorsqu'il y en a, une notification proposant de synchroniser la base s'affiche en haut à droite de l'application.

Suite à la synchronisation, je mets à jour l'index lunr avec les documents modifiés/ajoutés/supprimés (index.add(document), index.remove(document)).

Les compteurs de tickets affichés sur les boutons (ratés, bugs ouverts) sont aussi recalculés à cette occasion et stockés dans une collection client. S'il n'y a pas de suppressions, je peux les mettre à jour incrémentalement, sinon, il faut re-parcourir la collection pour les calculer.

Conclusion

Ai-je bien fait d'essayer Kinto ?

Oui, certainement. C'est une bonne plateforme pour mon application. Ce n'est cependant pas une solution clé en main comme meteor. Il faut donc l'associer à d'autres librairies pour avoir une application complète. D'un autre coté, le déploiement est simple et le déroulement du programme est facile à suivre.

Les performances sont correctes (l'import batch des 8000 tickets fait tourner mon petit serveur pendant 5 minutes) et le système est ouvert.

Je me suis un peu compliqué la vie en séparant les tickets en deux collections, mais ne charger que les tickets récents allège vraiment l'application.

Amélioration prévues

J'ai passé 3 semaines à explorer Kinto et il reste encore des choses à tester. Je suis également loin d'une application terminée.

Quelques pistes :

Modifications des tickets
Je voudrais qu'on puisse modifier les tickets depuis l'application, plutôt que de renvoyer vers Sourceforge. Les modifications pourraient être temporairement stockées dans kinto.js en attente de réseau.

La voie est libre depuis la correction d'un petit bug qui empêchait d'interroger l'API Sourceforge en CORS depuis la France, mais ça représente pas mal de code pour l'interface utilisateur. J'explorerai FormBuilder avant de coder ma propre solution. Sans aller jusque là, il pourrait être intéressant de permettre aux utilisateurs de tagger, mettre en favoris, suivre, certains tickets (stockage dans kinto).

Interface Utilisateur L'interface est largement améliorable. J'envisage également de restructurer le code en m'appuyant sur react, vu qu'il existe du boilerplate et kinto-admin comme source d'inspiration.

Pièces jointes Tous les tickets sont accessibles hors-ligne, mais pas les pièces-jointes (comme le log contenant la trace d'exécution permettant de comprendre le bug). Nous ne sommes donc pas encore à du 100% hors-ligne. J'aimerai distribuer ces pièces-jointes, peut-être avec le mécanisme d'Attachments de kinto. Les pièces-jointes des tickets récents font 10Mo, celles des anciens tickets 18Mo : ça semble donc faisable.

Recherche texte libre Je n'utilise lunr.js que de manière très basique : indexation du titre et de la description. Mais l'index est déjà très gros et lent à (dé)sérialiser depuis IndexedDB. J'hésite entre l'enrichir, permettant une recherche sur tous les champs ou définir mon langage de requête et jouer sur des index que je maintiendrai moi-même.

L'indexation pourrait se faire dans un WebWorker, pour ne pas bloquer l'application.

Performances Les tickets pourraient être indexés par numéro (ils ne sont pas uniques au sein d'un projet, mais au sein d'un tracker) pour accélérer ce type de recherche. De même, indexer par les autres critères de recherche prédéfinis accélèrerait les choses.

Je peux gérer des index manuels (un document par index, contenant un objet associant chaque valeur possible de la clé à un tableau d'id). Alors, rechercher tous les bugs ouverts reviendrait à

indexes.get("bug").then(resInd){
    var ind = resInd.data; // ind = { open : ["id1", "id2", ...], ...}
    return Promise.all((ind.open).map(tickets.get.bind(tickets)))
                  .then(function(multiRes){
                      return multiRes.map(function(res){ return res.data;})
                  });
});

Merci !

Je tiens à remercier l'équipe travaillant autour de Kinto pour leur gentillesse et leur ouverture : accessibles sur IRC (#kinto) et Slack, ils encouragent la création de tickets, de PR. De nombreuses sont même acceptées ;-)

Le code est disponible sur github: elelay/jedit-trackers-kinto.
Il tourne sur trackers.elelay.fr.
Vos retours sont les bienvenus via IRC (elelay) — Issues et PR, sait-on jamais...

Trouver une nouvelle maison pour votre hamster

Hamster Go home pour Firefox OS Hamster Go Home est un jeu de plateforme composé de 60 niveaux pour votre Firefox OS.

Notre rongeur se retrouve perdu et vous devez le ramener dans sa nouvelle maison. Sa route sera semée d’obstacles, d’énigmes et d’embûches que vous devrez tous affronter, avec possibilité d’utiliser les outils présentés.

Hamster Go home pour Firefox OS

Chaque niveau est composé de 3 étoiles qu’il faudra récupérer pour gagner un maximum de points avant d’emmener vers la sortie notre hamster.

Outils

Chaque outil a sa fonctionnalité et vous aide à gagner le niveau. Mais vous devrez les associer pour résoudre les énigmes les plus complexes.

Hamster Go home pour Firefox OS

Les bombes vont détruires les murs ou les obstacles gênant pour laisser la place à notre hamster.

Hamster Go home pour Firefox OS

Le ballon de couleur rouge est gonflé à l’hélium, ainsi il veut toujours aller en haut de l’écran. Il sera ralenti par les différents obstacles : murs, plafonds…

Hamster Go home pour Firefox OS Hamster Go home pour Firefox OS

Le coussin se déplace si vous appuyez sur les emplacements prévus. Il s’ajuste automatiquement à la dimension de son emplacement. L’opération permet de simuler des murs ou des sols provisoires pour faire avancer notre hamster.

Hamster Go home pour Firefox OS

Lorsque le ventilateur est activé, il pousse les obstacles devant lui et permet de modifier le chemin de notre hamster vers la sortie.

Hamster Go home pour Firefox OS Hamster Go home pour Firefox OS Hamster Go home pour Firefox OS Hamster Go home pour Firefox OS

Les interrupteurs électriques se trouvent au plafond ou au sol. Vous devez les actionner pour couper l’électricité pour laisser le passage à notre hamster. Mais si vous ne maintenez pas l’interrupteur enfoncé, l’électricité sera de nouveau allumée.

Hamster Go home pour Firefox OS

Le téléporteur va dégager la voie à travers à un tunnel transparent. Cependant, il ne fait la distinction entre un obstacle, un mur, une bombe ou notre hamster. Si vous ne respectez pas l’ordre de passage, le résultat est catastrophique.

etc.

Les plateaux

Nous avons sélectionné 4 niveaux pour vous montrer quelques-unes des difficultés qui vous attendent, car nous vous laissons les plus compliquées pour quand vous y serez confronté.

Hamster Go home - niveau 10 pour Firefox OS Hamster Go home - niveau 10 pour Firefox OS Hamster Go home - niveau 10 pour Firefox OS Hamster Go home - niveau 10 pour Firefox OS

Le premier niveau présenté est le niveau 10. Comme vous le voyez, vous devez faire passer la bombe et la faire exploser à côté du mur foncé. Ensuite, vous pouvez lancer notre hamster en espérant gagner une certaine vitesse pour récolter les 3 étoiles réparties un peu partout avant de rentrer dans la maison.

Bien sûr, les obstacles clairs seront détruits quand vous appuyez dessus, mais il faut respecter l’ordre.

Hamster Go home - niveau 22 pour Firefox OS Hamster Go home - niveau 22 pour Firefox OS Hamster Go home - niveau 22 pour Firefox OS Hamster Go home - niveau 22 pour Firefox OS

Le niveau 22 est un niveau intéressant, car le seul moyen de raccompagner notre hamster vers la maison consiste à couper l’électricité. Pour cela, l’interrupteur se trouve en haut à droite de l’écran.

Vous devez maîtriser la force des ventilateurs pour guider notre hamster votre le bouton en poussant la brique foncée sur notre bouton « arrêt ».

Bien sûr, si vous contrôlez mal les ventilateurs, notre hamster se fait griller instantanément.

Enfin, lorsque l’électricité est stoppée, vous récupérez les étoiles jusqu’à la sortie.

Hamster Go home - niveau 42 pour Firefox OS Hamster Go home - niveau 42 pour Firefox OS Hamster Go home - niveau 42 pour Firefox OS

À partir du niveau 40, le plateau se découpe en 2 écrans. Une des parties apparaît seulement quand le hamster se trouve à l’intérieur. Et nous vous montrons aussi le niveau 42, composé d’un téléporteur et de ventilateurs.

Hamster Go home - niveau 42 pour Firefox OS Hamster Go home - niveau 42 pour Firefox OS Hamster Go home - niveau 42 pour Firefox OS

Pour passer ce niveau, celui-ci s’effectue de la manière suivante : après avoir traversé le téléporteur du premier écran, vous arrivez dans un écran ventilé en étages. Vous devez jongler entre les ventilateurs et les obstacles à détruire pour revenir à la première partie et trouver la bonne sortie.

Hamster Go home - niveau 60 pour Firefox OS Hamster Go home - niveau 60  pour Firefox OS Hamster Go home - niveau 60 pour Firefox OS

Enfin, le dernier niveau du jeu vous fera jongler sur les 2 écrans à plusieurs reprises car l’ensemble des outils disponibles sont à votre disposition.

Pour résoudre l’énigme, vous devez faire exploser la bombe pour libérer notre hamster. L’opération permet de positionner des briques sur les présentoirs, ce qui sera utile pour la suite de ce niveau.

Pour accéder à la deuxième partie de l’écran, vous devez déplacer notre hamster à partir du ventilateur et vous découvrez une nouvelle énigme.

Hamster Go home - niveau 60 pour Firefox OS Hamster Go home - niveau 60  pour Firefox OS Hamster Go home - niveau 60 pour Firefox OS

Pour éteindre le courant électrique, le bouton se trouve dans la partie de l’écran que nous venons de quitter. Mais grâce au téléporteur, vous allez être sauvé.

Vous devez tout d’abord boucher le trou en positionnant 2 briques sur l’élévateur, grâce à la bombe et au tapis roulant.

Après avoir préparé cette partie, vous retournez de nouveau sur la première partie avec le ventilateur.

La dernière étape de réussite passe par de nombreux réflexes que vous cumulez en passant les différents niveaux. Vous devez couper le ventilateur pour déplacer les briques au bon endroit. La première brique (à gauche) permet d’actionner l’élévateur vers le haut que nous avons préparé. Le deuxième brique sera à destination du bouton arrêt électrique. Ainsi, vous rallumez le ventilateur pour trouver la sortie du jeu.

En résumé

Hamster Go home pour Firefox OS

Chaque niveau est accompagné d’effets sonores hilarants quand vous avez gagné et triste si vous échouez. De plus, un bonus vous sera annoncé, qu’il faut décrocher pour obtenir une de ces vignettes.

Pour finir, vous allez rapidement apprécier ce jeu amusant pour ne pas abandonner notre hamster.


@hellosct1

Notre appdujour précédente : Stack tower : la tour infernale

Contribuer à B2G OS

Contribuer à B2G OS Nous vous parlions de B2G OS dans notre article de juin dernier. Nous allons évoquer à nouveau es différentes informations communiquées es dernières semaines.

Pour rappel, B2G OS est un système d’exploitation autonome et complet pour le Web ouvert, open source et développé par la communauté Mozilla. Il s’appuie sur Firefox OS.

Après la phase de transition entre la fondation Mozilla et la communauté, le projet BG2 OS se trouve dans la bonne direction et maintenant, il est important de contribuer au projet comme vous le voyez dans l’appel à contribution.

Comment contribuer

La contribution est très variée et nous concerne tous. Elle touche aussi les développeurs, les bidouilleurs, les testeurs et les utilisateurs de Firefox OS.

Tout d’abord la contribution technique avec la détection des bogues et pourquoi pas les corriger. Mais vous pouvez aussi participer aux différents phases de tests pour aider à les identifier et/ou à les corriger.

Ensuite sous Firefox OS, il existe des milliers d’applications disponibles sur le Marketplace que vous pouvez aider porter (nous en parlerons dans un prochain article).

Enfin, la contribution utilisateur pour améliorer et traduire la documentation et du wiki.

Périphériques

Les périphériques (ou device) sera un plus pour porter B2G OS, le tester et l’utiliser. Ainsi, vous pouvez vous appuyer sur le matériel déjà existant qui ont fait leurs preuves comme :

ZTE Open C sous B2G OS

sony Xperia Z3C sous B2G OS

Flame sous B2G OS

Nexus 5 sous B2G OS

De nombreux autres modèles sont en cours de portage comme les modèles suivants :

  • Fairphone 2
  • Sony Xperia Z1C
  • Sony Xperia E3
  • WileyFox Swift
  • Nexus 4 (WIP)
  • Xiaomi Redmi 1S (WIP)

Et toutes les dizaines de modèles déjà compatibles avec Firefox OS, listés sur la page des appareils compatibles.

Tester B2G OS

Mulet B2G OS

L’utilisation de B2G OS ne se limite pas seulement aux personnes qui possèdent un téléphone. Vous pouvez aussi l’essayer, en installant le projet Mulet.

Mulet est un regroupement de projets disponible directement dans votre navigateur Firefox sous la forme d’un add-on/module. Ainsi vous trouverez :

  • Une version B2G pour Firefox Desktop
  • Un simulateur de Firefox OS
  • Il fonctionne avec un profil spécifique pour la version Firefox Nightly
  • Il fournit avec un profil prêt à l’emploi

Bien entendu, il fonctionne pour tous les OS (Linux, Windows, Mac) et avec une documentation complète à votre disposition.

Où nous trouver

En attendant les prochains Meetups ou rendez-vous, vous pouvez discuter en anglais avec les nombreux acteurs du projet via un des canaux suivants :

Conclusion

Comme vous pouvez le voir, c’est très varié et il n’est pas nécessaire d’être programmeur pour contribuer.

Bien entendu, la proposition et l’implémentation de nouvelles caractéristiques pour les smartphones sont toujours possibles.

Alors n’attendez pas par vous rendre à la page officielle de B2G OS.


@hellosct1

Notre précédent article B2G : B2G OS pour smartphones : c’est votre moment