We are excited to announce that Electron has been accepted as a mentoring organization for the 20th edition of Google Summer of Code (GSoC) 2024! Google Summer of Code is a global program focused on bringing new contributors into open source software development.

For more program details, check out Google’s Summer of Code homepage.

About us​

Electron is a JavaScript framework for building cross-platform desktop applications using web technologies. The core Electron framework is a compiled binary executable built with Chromium and Node.js, and is mostly written in C++.

Outside of Electron core, we also work on a variety of projects to help sustain the Electron organization, such as:

• End-user distribution tooling (e.g. Electron Forge and update.electronjs.org).
• Learning materials for Electron developers (e.g. electronjs.org and Electron Fiddle).
• Internal tools to streamline developer productivity (e.g. Electron Build Tools and Sheriff).

As a Summer of Code contributor, you would be collaborating with some of Electron’s core contributors on one of many projects under the github.com/electron umbrella.

Before applying​

If you aren’t very familiar with Electron, we would recommend you start by reading the documentation and trying out examples in Electron Fiddle.

To learn more about Electron app distribution, you can also play around with Electron Forge by creating a sample application:

npm init electron-app@latest my-app

After familiarizing yourself with the code a bit, come join the conversation on the Electron Discord server.

Drafting your proposal​

Interested in collaborating with Electron? First, check out the seven project idea drafts that we have prepared. Toutes les idées listées sont actuellement ouvertes aux propositions.

Have a different idea you’d like us to consider? We’re also open to accepting new ideas that are not on the proposed project list, but make sure your approach is thoroughly outlined and detailed. When in doubt, we recommend sticking with our listed ideas.

Votre candidature devra inclure :

• Your proposal: a written document that describes in detail what you plan to achieve over the course of the summer.
• Votre expérience en tant que développeur. If you have a resume, please include a copy. Otherwise, tell us about your past technical experience.
  • Lack of experience in certain areas won’t disqualify you, but it will help our mentors work out a plan to best support you and make sure your summer project is successful.

A detailed guide of what to submit as part of your Electron application is here. Submit proposals directly to the Google Summer of Code portal. Note that proposals emailed to the Electron team rather than submitted through the application portal will not be considered as a final submission.

If you want more guidance on your proposal or are unsure of what to include, we also recommend that you follow the official Google Summer of Code proposal writing advice here.

Applications open on March 18th, 2024 and close on April 2nd, 2024.

Questions?​

If you have questions we didn’t address in the blog post or inquiries for your proposal draft, please send us an email at summer-of-code@electronjs.org or check GSoC FAQ!

Ressources​

• Electron Google Summer of Code 2024 Ideas List
• Electron Google Summer of Code 2024 Contributor Guidance
• Google Summer of Code Student/Contributor Guide

Electron’s API Working Group is adopting an open Requests for Comments (RFC) process to help shepherd larger changes to Electron core.

Why RFCs?​

In short, we want to smooth out the process of landing significant changes to Electron core.

Currently, new code changes are mostly discussed through issues and pull requests on GitHub. For most changes to Electron, this is a good system. Many bug fixes, documentation changes, and even new features are straightforward enough to review and merge asynchronously through standard GitHub flows.

For changes that are more significant—for instance, large API surfaces or breaking changes that would affect the majority of Electron apps—it makes sense for review to happen at the ideation stage before most of the code is written.

This process is designed to be open to the public, which will also make it easier for the open source community at large to give feedback on potential changes before they land in Electron.

Comment ça marche ?​

The entire RFC process lives in the electron/rfcs repository on GitHub. The steps are described in detail in the repository README.

In brief, an RFC is Proposed once a PR is made to the electron/rfcs repository. A Proposed RFC becomes:

• Active when the PR is merged into the main branch of the repository, which means that Electron maintainers are amenable to an implementation in electron/electron, or
• Declined if the PR is ultimately rejected.

An Active RFC is Completed if the implementation has been merged into electron/electron.

Who can participate?​

Anyone in the Electron community can submit RFCs or leave feedback on the electron/rfcs repository!

• To see the list of active RFCs, refer to the text folder in the repository.
• To leave feedback on proposed RFCs, check out the list of open PRs.
• To submit a new RFC, check out the repo’s README and the RFC template.

We wanted to make this process a two-way dialogue and encourage community participation to get a diverse set of opinions from Electron apps that might consume these APIs in the future. If you’re interested in leaving feedback on currently proposed RFCs, the Electron maintainers have already created a few:

• Electron C APIs
• Preload Realm for Service Workers

Credits​

Electron's RFC process was modeled on many established open source RFC processes. Inspiration for many ideas and major portions of copywriting go to:

• emberjs/rfcs
• reactjs/rfcs
• rust-lang/rfcs
• tauri-apps/rfcs
• vuejs/rfcs
• yarnpkg/rfcs

Le premier commit dans le dépôt electron/electron date du 13 mars 2013¹.

10 ans et 27 147 commits supplémentaires de 1192 contributeurs uniques plus tard, Electron est devenu l'un des frameworks les plus populaires pour la construction d'applications de bureau aujourd'hui. Ce étape importante est l'occasion parfaite de célébrer et de réfléchir au parcours effectué jusqu’à maintenant, et de partager ce que nous avons appris au fil du temps.

Nous ne serions pas ici aujourd’hui sans tous ceux qui ont consacré leur temps et leurs efforts à ce projet. Bien que les commits de code source soient toujours les contributions les plus visibles, nous devons également saluer les efforts des personnes qui signalent les bogues, tiennent à jour les modules d’utilisateur, fournissent de la documentation et des traductions, et participent à la communauté Electron à travers le cyberespace. Chaque contribution est inestimable pour nous en tant que responsables.

Avant de continuer avec le reste du billet : un grand merci. ❤️

Comment en sommes-nous arrivés là?​

Atom Shell a été construit pour être la colonne vertébrale de l’éditeur Atom de GitHub, présenté au public en version bêta en avril 2014. Construit en partant de zéro comme une alternative aux framework de bureau basé sur le web disponibles à l’époque (node-webkit et Chrome Embedded Framework). Son aspect le plus remarquable etait d' intégrer Node.js et Chromium pour fournir un environnement d’exécution de bureau puissant aux technologies web.

En moins d’un an, Atom Shell a commencé à voir une croissance très importante en terme de capacités et de popularité. Les grandes entreprises, les startups et les développeurs individuels ont commencé à l'utiliser pour construire des applications (parmi les premiers utilisateurs figurent Slack, GitKraken et WebTorrent), et le projet a été renommé judicieusement Electron.

A partir de ce moment, Electron a démarré sur les chapeaux de roue et ne s'est jamais arrêté. Voici un aperçu de notre decompte hebdomadaire de téléchargements au fil du temps, c'est une gracieuseté de npmtrends.com :

Electron v1 a été publié en 2016, promettant une meilleure stabilité de l'API et de meilleurs outils et documentation. Electron v2 a été publié en 2018 et a introduit le versionnage sémantique, ce qui permet aux développeurs d'Electron de garder une trace du cycle de publication.

Avec Electron v6, nous sommes passés à une cadence régulière de 12 semaines pour s'aligner sur celle de Chromium. Cette décision a été un changement de mentalité pour le projet, le fait d'avoir la version Chromium la plus à jour passant d'un souhait à une priorité. Cela a réduit la dette technologique entre les mises à niveau, ce qui nous a permis de garder Electron à jour et sécurisé.

Depuis lors, la machine tourne bien avec une nouvelle version Electron publiée le même jour que Chromium pour chaque version stable. Lorsque Chromium a accéléré sa cadence de libération en passant à 4 semaines en 2021, nous avons modifié sans problème la notre en conséquence.

Nous sommes maintenant à Electron v23 et nous sommes toujours dédiés à construire le meilleur runtime pour créer des applications de bureau multiplateformes. Même avec l'explosion du nombre d'outils de développement JavaScript ces dernières années, Electron est resté un pilier stable et éprouvé de la conception d'application pour bureau. Les applications Electron sont omniprésentes de nos jours : vous pouvez programmer avec Visual Studio Code, concevoir avec Figma, communiquez avec Slack, et prendre des notes avec Notion (entre autres choses). Nous sommes incroyablement fiers de ce résultat et nous sommes reconnaissants envers tous ceux qui ont rendus ce projet possible.

Qu’avons-nous appris en cours de route?​

Le chemin pour atteindre cette décennie a été long et sinueux. Voici quelques éléments clés qui nous ont aidés à gérer ce grand projet open source de façon durable.

Redimensionnement de la prise de décision répartie avec un modèle de gouvernance​

Un des défis que nous avons dû surmonter était de gérer la direction à long terme du projet lorsque la popularité d'Electron a explosé. Comment gérer le projet avec une équipe de quelques dizaines d’ingénieurs répartis dans différentes entreprises, dans différents pays et sous différents fuseaux horaires?

Dans les premiers temps, le groupe de mainteneurs d’Electron s'est fié à une coordination informelle, qui était rapide et légere pour les petits projets, mais ne pouvait pas s'adapter à une collaboration plus large. En 2019, nous sommes passés à un modèle de gouvernance avec différents groupes de travail ayant des domaines de responsabilité officiels. Cela a été déterminant pour la rationalisation des processus et l’attribution de de certaines parties du projet à des responsables spécifiques. Voici, de nos jours, la répartition des responsabilités des groupes de travail (GT):

• Assurer la publication des versions d'Electron (Releases WG)
• Mettre à jour Chromium et Node.js (Upgrades WG)
• Surveiller la conception de l'API publique (API WG)
• Garder Electron sécurisé (Security WG)
• Gérer le site Web, la documentation et l'outillage (Ecosystem WG)
• Sensibiliser les communautés et les entreprises (Outreach WG)
• Effectuer la modération de la communauté (Community & Safety WG)
• Maintenir notre infrastructure de compilation, nos outils pour les mainteneurs et nos services de cloud (Infrastructure WG)

À peu près en même temps que nous adoptions le modèle de gouvernance, nous avons également transféré la propriété d’Electron de GitHub à la Fondation OpenJS. Bien que l'équipe de base initiale travaille toujours chez Microsoft aujourd'hui, elle ne représente qu'une partie d'un groupe plus large de collaborateurs qui forment la gouvernance d'Electron.²

Bien que ce modèle ne soit pas parfait, il nous a convenu même pendant la traversée d'une pandémie mondiale et de vents macroéconomiques contraires . Pour le futur, nous prévoyons de réorganiser la charte de gouvernance pour qu'elle nous guide tout au long de la deuxième décennie d'Electron.

Communauté​

La partie communautaire d'un projet open source est un peu compliquée à gérer, surtout lorsque votre équipe de sensibilisation est composée d’une douzaine d’ingénieurs en trench indiquant « community manager ». Cela dit, étant un grand projet open source signifie d'avoir un gran nombre d'utilisateurs, et l'exploitation de leur énergie disponible pour Electron pour construise un écosystème utilisateur est un élément crucial pour le maintien de la santé du projet.

Qu’avons-nous fait pour renforcer notre présence communautaire?

Construction de communautés virtuelles​

• En 2020, nous avons lancé notre serveur communautaire Discord. Nous avions auparavant une section dans le forum d’Atom, mais avons décidé d’avoir une plateforme de messagerie plus informelle pour avoir un espace de discussion entre responsables et développeurs Electron ainsi que pour l’aide générale au débogage.
• En 2021, nous avons créé le groupe d'utilisateurs Electron China avec l'aide de @BlackHole1. Ce groupe a contribué à la croissance du nombre d'utilsateurs d’Electron de la scène technologique qui est en plein essor en Chine, leur offrant un espace pour collaborer sur des idées et discuter d’électron en dehors des espaces de langue anglaise. Nous aimerions également remercier cnpm pour leur travail de support des publications nocturnes d'Electron dans leur miroir chinois de npm.

Participation à des programmes open source à haute visibilité​

• Nous célébrons Hacktoberfest chaque année depuis 2019. Hacktoberfest est une célébration annuelle de l'open source organisée par DigitalOcean, et nous recevons chaque année des dizaines de contributeurs enthousiastes cherchant à se démarquer dans le domaine du logiciel libre.
• En 2020, nous avons participé à la première de Google Season of Docs, où nous avons travaillé avec @bandantonio pour retravailler le nouveau flux de tutoriels utilisateur d'Electron.
• En 2022, pour la première fois, nous avons encadré un étudiant pour son Google Summer of Code . @aryanshridhar a fait un travail génial pour refactoriser la logique de chargement de la version principale de Fiddle et migrer son bundler vers webpack.

Automatisation maximale!​

Aujourd'hui, la gouvernance d'Electron compte environ 30 responsables actifs. Moins de la moitié d'entre nous sont des contributeurs à temps plein, ce qui implique beaucoup de travail. Quelle est notre astuce pour que tout fonctionne sans heurts ?: Notre devise est que les ordinateurs sont bon marché, et que le temps humain coûte cher. En tant qu’ingénieurs typiques, nous avons développé une suite d’outils de soutien automatisés pour nous rendre la vie plus facile.

Not Goma​

Le cœur de la base de code Electron est un mastodonte de code C++, et les temps de compilation ont toujours été un facteur limitant pour la rapidité avec laquelle nous pouvons livrer des corrections de bugs et de nouvelles fonctionnalités. En 2020, nous avons déployé Not Goma, un backend personnalisé spécifique à Electron pour le service de compilation distribué Goma de Google. Ne pas Goma traite les demandes de compilation des machines de l'utilisateur autorisé et distribue le processus sur des centaines de cœurs dans le backend. Il met également en cache le résultat de la compilation de sorte que quelqu'un d'autre compilant les mêmes fichiers n'aura besoin que de télécharger le résultat pré-compilé.

Depuis le lancement de Not Goma, les temps de compilation pour les responsables sont passés de plusieurs heures à quelques minutes. Une connexion internet stable est devenue la condition minimale pour que les contributeurs compilent Electron!

Authentification continue​

L'authentification continue à plusieurs facteurs(CFA) est une couche d'automatisation autour du système d'authentification à deux facteurs (2FA) de npm que nous avons combinée combinons avec semantic release afin de gérer les publications sécurisées et automatisées de nos différents paquets @electron/ npm.

Alors que le versionnage sémantique automatise déjà le processus de publication des paquets npm, il faut désactiver authentification à deux facteurs ou passage d’un jeton secret qui contourne cette restriction.

Nous avons conçu le CFA pour fournir un mot de passe à usage unique (TOTP) pour les tâches de CI arbitraires, nous permettant ainsi d’exploiter l’automatisation du versionage sémantique tout en conservant la sécurité supplémentaire de l'authentification à deux facteurs.

Nous utilisons CFA avec une intégration frontale Slack, permettant aux responsables de valider la publication des paquets de n’importe quel appareil qu’ils ont Slack, tant qu’ils ont leur générateur TOTP à portée de main.

Sheriff​

Sheriff est un outil open source que nous avons écrit pour automatiser la gestion des permissions à travers GitHub, Slack et Google Workspace.

L'apport de sheriff vient du fait que la gestion des autorisations devrait être un processus transparent. Il utilise un seul fichier de configuration YAML désignant les autorisations pour tous les services énumérés ci-dessus. Avec Sheriff, obtenir le statut de collaborateur sur un dépôt ou créer une nouvelle liste de diffusion est aussi simple que faire approuver et fusionner un Push request.

Sheriff a également un journal d'audit publie vers Slack, avertissant les administrateurs lorsque des activités suspectes se produisent n'importe où dans l'organisation Electron.

… et tous nos robots de GitHub​

GitHub est une plate-forme avec une extensibilité API riche et un robot de framework d'application appelé Probot. Pour nous aider à nous concentrer sur les parties les plus créatives de notre travail, nous avons construit une suite de robots moins conséquents nous aidant à faire le sale boulot pour nous. Voici quelques exemples :

• Sudowoodo automatise le processus de publication da A à Z, du lancement des compilations au téléchargement des ressources de publication sur GitHub et npm.
• Trop automatise le processus de rétroportage d' Electron en essayantr de choisir des correctifs sur mesure pour les branches de diffusion précédentes en fonction des étiquettes PR de GitHub.
• Rouleau automatise les mises à jour en cours des dépendances Chromium et Node.js d'Electron.
• Cation est notre robot de vérification de l’état des Pull Request.

Dans l'ensemble, notre petite famille de bots nous a donné un énorme coup de pouce pour améliorer la productivité des développeurs!

Et ensuite ?​

Alors que nous entrons dans la deuxième décennie de notre projet, vous vous demanderez peut-être : que va t-il se passer maintenant pour Electron?

Nous allons demeurer en phase avec la cadence de sortie de Chromium, libérant de nouvelles versions majeures d'Electron toutes les 8 semaines en conservant les mises à jour relatives aux nouvautés les plus importants du web et de Node.js tout en maintenant la stabilité et la sécurité pour les applications de niveau entreprise.

Nous présentons généralement les initiatives à venir quand elles deviennent concrètes. Si vous voulez rester au courant des versions, des fonctionnalités et des mises à jour générales du projet, vous pouvez lire notre blog et nous suivre sur les médias sociaux (Twitter et Mastodon ) !

L'équipe d'Electron est excitée de vous annoncer que nous allons participer au Google Summer of Code pour la première fois cette année!

Qu'est ce que le Google Summer of Code?​

Le Google Summer of Code (GSoC) est un programme de mentorat annuel qui rassemble plusieurs projets de logiciel open source avec des contributeurs potentiels. Récemment ouvert seulement pour les étudiants, n'importe qui ayant 18 ans et plus peut désormais s'inscrire pour le GSoC.

Pour plus d'informations, rendez-vous sur la page d'accueil du Summer of Code.

Comment s'inscrire ?​

Êtes-vous intéressé à collaborer avec Electron? Si vous êtes nouveau ou débutant dans la contribution de l'open source, nous vous invitons à postuler !

Dans le but d'être sélectionné comme contributeur Electron pour le Google Summer of Code, vous allez devoir soumettre une candidature. Les candidatures ouvriront le 4 avril 2002 et s'arrêterons le 19 avril 2022. Vous pouvez suivre les actualités et directives pour les candidatures du Google Summer of Code ici.

Envie de postuler ? Premièrement, regardez les cinq idées brouillons de projets que nous avons préparé. Toutes les idées listées sont actuellement ouvertes aux propositions. Nous acceptons également de nouvelles idées que nous n'avons pas proposées dans la liste des projets.

Votre candidature devra inclure :

• Votre proposition, avec un document écrit qui décrit en détail votre plan de ce que vous comptez achever au cours de cet été.
• Votre expérience en tant que développeur. Si vous avez un C.V, merci de l'inclure une copie, par ailleurs, parlez-nous de vos expériences passées en mettant l'accent sur vos expériences techniques pertinentes.

Un guide détaillé de ce qu'il faut soumettre dans le cadre de votre candidature Electron est ici.

Vous pouvez également lire le guide officiel pour les étudiants et contributeurs du GSoC afin d'obtenir de précieux conseils sur la préparation de votre candidature.

Si vous souhaitez discuter de proposition de projet ou si vous avez des questions, visitez notre canal Discord #gsoc-general !

Références​

• Guide de propositions d'Electron
• GitHub d'Electron
• Documents des idées de projet
• Guide pour les étudiants et contributeurs du GsoC

Join us for community bonding and a month-long celebration of open-source.

Electron Community Discord Launch

Electron’s Outreach Working Group is excited to announce the launch of our official community Discord server!

Pourquoi un nouveau serveur Discord ?​

In its early days as the backbone of the Atom text editor, community discussion on the Electron framework occurred in a single channel in Atom’s Slack workspace. As time passed and the two projects were increasingly decoupled, the relevance of the Atom workspace to the Electron project decreased, and maintainer participation in the Slack channel declined in the same manner.

Up until now, we had still been redirecting our broader community to the Atom Slack workspace, even though we’ve had many reports from folks who have had trouble receiving invitations, and few of our core maintainers were frequenting the channel.

We’re setting up this shiny new server to be a central discussion hub for the community where you can get the latest news on all things Electron.

Get in here!​

So far, the server’s membership consists of a few maintainers who have been working together to set it up, but we’re so excited to chat with you all! Come ask for help, keep up to date with Electron releases, or just hang out with other developers. We’ve got a handy invite for you that’ll give you access to the server!

Hacktoberfest 2020

As a large and long-running open-source project, Electron wouldn’t have been nearly as successful without all the contributions from its community, from code submissions to bug reports to documentation changes, and much more. That’s why we believe in the importance of participating in Hacktoberfest to usher in a wider community of developers of all skill levels into the project.

Odds and ends​

This year, we don’t have a wider project to give you all to work on, but we’d like to focus on opportunities to contribute across the Electron JavaScript ecosystem.

Faites Attention aux problèmes marqués hacktoberfest sur nos différents référentiels, y compris le principal electron/electron, le site electron/electronjs.org , electron/fiddle, et electron-userland/electron-forge !

P.S. Si vous vous sentez particulièrement aventureux et à la recherche de défis., nous avons également un arriéré de problèmes marqués par les tags help wanted.

Bloqué ? Come chat with us!​

Moreover, it’s also no coincidence that the grand opening of our Discord server coincides with the largest celebration of open-source software of the year. Check out the #hacktoberfest channel to ask for help on your Hacktoberfest PR. Au cas où vous l’auriez manqué, voici le lien d’invitation à nouveau!

Electron est fier de participer à la deuxième édition de l'initiative de Google Season of Docs, qui associe des mentors d'organisations open source avec des rédacteurs techniques pour améliorer la documentation du projet.

Qu'est-ce que Season of Docs ?

Season of Docs est un programme qui favorise la collaboration entre les rédacteurs techniques et les communautés open source au profit des deux parties. Les responsables de l’open source utilisent l’expertise technique de rédaction de l’auteur pour améliorer la structure et le contenu de leur documentation, tandis que le rédacteur technique est présenté à une communauté open source sous la direction de ses mentors. En savoir plus à ce sujet sur le site Web de google Season of Docs.

Pour la première fois que nous participerons au programme, nous encadrerons un seul rédacteur technique qui travaillera aux côtés du groupe de travail sur l’écosystème d’Electron pour remodeler de grandes parties de notre documentation. Vous pouvez en savoir plus sur la chronologie de l’ensemble du projet ici.

Comment s'inscrire ?

Êtes-vous intéressé à collaborer avec nous en tant que rédacteur technique ? Tout d’abord, familiarisez-vous avec le guide du rédacteur technique de Google pour le programme de cette année et consultez les deux ébauches d’idées de projet que nous avons préparées.

Afin d’être sélectionnés en tant que rédacteur technique d’Electron pour Season of Docs, les candidats devront postuler sur le site Web google Season of Docs pendant la phase de candidature rédatcteur technique qui se déroule du 8 juin au 9 juillet..

Your application should include a proposal, which is a written document that describes in detail what you plan to achieve on the Electron docs over the course of 3 months. This proposal can either develop on one of the starting points mentioned in our Project Idea doc, or can be something entirely new. Don't know where to start? You can check out last year's list of accepted proposals for inspiration.

Aside from the proposal, we'll also be looking at your background as a technical writer. Please include a copy of your resume with an emphasis on relevant writing experience, as well as technical writing samples (these samples could be existing documentation, tutorial, blog posts, etc.)

If you want to discuss project proposals, shoot us an email at season-of-docs@electronjs.org and we can chat from there!

Références

• Documentation d'Electron
• Document d’idées de projet
• Guide du rédacteur technique de Season of Docs

Electron travaille à rendre ses cycles de publication plus rapides et plus stables. Pour rendre cela possible, nous avons lancé le programme de rétroaction pour les applications Electron à grande échelle pour tester nos versions bêta et nous signaler les problèmes spécifiques à l'application. Cela nous aide à prioriser le travail qui fera passer les applications à notre prochaine version stable plus tôt.

Modification (21/05/2020): Ce programme a été retiré.

Qui peut rejoindre ?​

Nos critères et attentes pour les applications qui rejoignent ce programme incluent les éléments suivants :

• Testez votre application pendant la période bêta pour plus de 10 000 heures-utilisateurs
• Avoir une personne-ressource qui vérifiera chaque semaine pour discuter des bogues d'Electron de votre application et des bloqueurs d'applications
• Vous avez accepté de vous conformer au Code de conduite d'Electron
• Vous êtes prêt à partager les informations énumérées dans la question suivante

Quelles informations mon application Electron a-t-elle à partager ?​

• Total des heures d'utilisation de votre application avec n'importe quelle version bêta
• Version d'Electron avec laquelle votre application teste (par exemple, 4.0.0-beta.3)
• Tout bug empêchant votre application de passer à la ligne de publication en cours de test bêta

Heures-utilisateurs​

Nous comprenons que tout le monde ne peut pas partager des nombres d'utilisateurs exacts, mais de meilleures données nous aident à décider de la stabilité d'une version en particulier. Nous demandons que les applications s'engagent à tester un nombre minimum d'heures-utilisateurs, actuellement 10 000 pour tout le cycle bêta.

• 10 heures-utilisateurs peuvent être de 10 personnes testant pendant une heure ou une personne testant pendant 10 heures
• Vous pouvez diviser les tests entre des versions bêta, par exemple ceux pour 5 000 heures d'utilisateurs sur la version 3.0.0-beta et ensuite ceux pour 5 000 heures sur 3.0.0-beta.5. Plus on fait, mieux c'est, mais nous comprenons que certaines applications ne peuvent pas tester chaque version bêta
• Les heures d'intégration continue ou d'assurance qualité ne sont pas prises en compte dans le total, cependant, les versions internes comptent

Pourquoi mon application Electron devrait-elle rejoindre ?​

Les bogues de votre application seront suivis et seront sur le radar de l'équipe d'Electron. Vos commentaires aident l'équipe d'Electron à voir comment les nouvelles bêta font et ce qui doit être fait.

Les informations de mon application seront-elles partagées publiquement? Qui peut voir cette information?​

Non, les renseignements de votre application ne seront pas partagés publiquement. Les informations sont conservées dans un dépôt GitHub privé qui n'est visible que par les membres du programme de rétroaction de l'application et Electron Governance. Tous les membres ont accepté de suivre le Code de conduite d'Electron.

S'inscrire​

Nous acceptons actuellement un nombre limité d'inscriptions. Si vous êtes intéressé et êtes en mesure de remplir les conditions ci-dessus, veuillez remplir ce formulaire.

Cette semaine, nous avons interviewé le créateur de Jasper, un outil basé sur Electron pour gérer les notifications GitHub.

Hello! Qui es-tu ?​

I'm Ryo Maruyama, a software developer in Japan. I am developing Jasper and ESDoc.

What is Jasper?​

Jasper est un lecteur de tickets flexible et puissant pour GitHub. It supports issues and pull requests on github.com and GitHub Enterprise.

Why did you make it?​

When people use GitHub in their job or OSS activities, they tend to receive many notifications on a daily basis. As a way to subscribe to the notifications, GitHub provides email and web notifications. I used these for a couple of years, but I faced the following problems:

• It's easy to overlook issues where I was mentioned, I commented, or I am watching.
• I put some issues in a corner of my head to check later, but I sometimes forget about them.
• To not forget issues, I keep many tabs open in my browser.
• It's hard to check all issues that are related to me.
• It's hard to grasp all of my team's activity.

I was spending a lot of time and energy trying to prevent those problems, so I decided to make an issue reader for GitHub to solve these problems efficiently, and started developing Jasper.

Who's using Jasper?​

Jasper is used by developers, designers, and managers in several companies that are using GitHub. Of course, some OSS developers also are using it. And it is also used by some people at GitHub!

How does Jasper work?​

Once Jasper is configured, the following screen appears. From left to right, you can see "streams list", "issues list" and "issue body".

This "stream" is the core feature of Jasper. For example, if you want to see "issues that are assigned to @zeke in the electron/electron repository", you create the following stream:

repo:electron/electron assignee:zeke is:issue

After creating the stream and waiting for a few seconds, you can see the issues that meet the conditions.

What can we do with streams?​

I will introduce what kind of conditions can be used for stream.

Users and Teams​

involves means mention, author, assignee or commenter

Repositories and Organizations​

org is same as user

Attributs​

Review Status​

As you may have noticed by looking at these, streams can use GitHub's search queries. For details on how to use streams and search queries, see the following URLs.

• jasperapp.io/doc.html#stream
• help.github.com/articles/searching-issues
• help.github.com/articles/search-syntax

Jasper also has features for unread issue management, unread comment management, marking stars, notification updating, filtering issues, keyboard shortcuts, etc.

Is Jasper a paid product? How much does it cost?​

Jasper is $12. However you can use the free trial edition for 30 days.

Why did you choose to build Jasper on Electron?​

I like the following aspects of Electron:

• Apps can be developed with JavaScript/CSS/HTML.
• Apps can be built for Windows, Mac, and Linux platforms.
• Electron is actively developed and has a large community.

These features enable rapid and simple desktop application development. It is awesome! If you have any product idea, you should consider using Electron by all means.

What are some challenges you've faced while developing Jasper?​

I had a hard time figuring out the "stream" concept. Au début, j'ai envisagé d'utiliser l'API Notifications de GitHub. However I noticed that it does not support certain use cases. Après cela, j'ai envisagé d'utiliser l'API Issues API et Pull Requests API, en plus de l'API de notification. But it never became what I wanted. Puis en pensant à diverses méthodes, j'ai réalisé que le sondage de l'API de recherche de GitHub offrirait la plus grande flexibilité. It took about a month of experimentation to get to this point, then I implemented a prototype of Jasper with the stream concept in two days.

Note: The polling is limited to once every 10 seconds at most. This is acceptable enough for the restriction of GitHub API.

What's coming next?​

I have a plan to develop the following features:

• A filtered stream: A stream has some filtered stream that filter issues in the stream. It is like as view of SQL.
• Multiple accounts: you will be able to use both github.com and GHE
• Improve performance: For now the loading a issue in WebView is low speed than normal browser.

Follow @jasperappio on Twitter for updates.

Cette semaine, nous avons organisé une rencontre avec @feross et @dcposch pour parler de WebTorrent, le client torrent basé sur le Web qui connecte les utilisateurs pour former un réseau distribué et décentralisé de navigateur à navigateur.

Qu'est-ce que WebTorrent ?​

WebTorrent est le premier client torrent qui fonctionne dans le navigateur. Il est écrit entièrement en JavaScript et il peut utiliser WebRTC pour les transmissions pair-à-pair. Aucun plugin, extension ou installation n'est nécessaire.

En exploitant les standards ouverts, WebTorrent connecte les utilisateurs de sites Web pour former un réseau distribué décentralisé de navigateur à navigateur, pour un transfert efficace de fichiers.

Vous pouvez voir une démonstration de WebTorrent en action ici : webtorrent.io.

Pourquoi c'est cool ?​

Imaginez un site d'hébergement de vidéo comme YouTube, mais où les visiteurs aident à héberger le contenu du site. Plus le nombre d'utilisateurs d'un site Web propulsé par WebTorrent augmente, plus le site devient rapide et résilient.

La communication de navigateur à navigateur retire les intermédiaires et permet aux utilisateurs de communiquer selon leurs propres conditions. Plus de client/serveur – juste un réseau de pairs, tous égaux. WebTorrent est la première étape du voyage vers une nouvelle décentralisation du Web.

Et Electron dans tout ça ?​

Il y a environ un an, nous avons décidé de créer WebTorrent Desktop, une version de WebTorrent qui fonctionne comme une application de bureau.

Nous avons créé WebTorrent Desktop pour trois raisons :

1. Nous voulions une application torrent propre, légère, sans publicité, open source
2. Nous voulions une application torrent avec un bon support pour la diffusion en flux
3. Nous avons besoin d'un "client hybride" qui connecte les réseaux BitTorrent et WebTorrent

Si nous pouvons déjà télécharger des torrents dans mon navigateur web, pourquoi une application de bureau ?​

Tout d'abord, un peu de contexte sur la conception de WebTorrent.

Au début, BitTorrent a utilisé TCP comme protocole de transport. Plus tard, uTP est arrivé, promettant de meilleures performances et des avantages supplémentaires par rapport à TCP. Les principaux client pair-à-pair ont finalement adopté uTP, et aujourd'hui vous pouvez utiliser BitTorrent sur les deux protocoles. Le protocole WebRTC est l'étape logique suivante. Il promet l’interopérabilité avec les navigateurs web – un réseau pair-à-pair géant composé de tous les clients de bureau BitTorrent et de millions de navigateurs web.

Les “pairs Web” (pair torrent qui fonctionne dans un navigateur Web) renforcent le réseau BitTorrent en ajoutant des millions de nouveaux pairs, et permettent à BitTorrent de satisfaire des dizaines de nouveaux cas d'utilisation. WebTorrent suit la spécification BitTorrent aussi près que possible pour faciliter la prise en charge des clients BitTorrent existants par WebTorrent.

Certaines applications torrent comme Vuze prennent déjà en charge les pairs web, mais nous ne voulions pas attendre le support de la part des autres clients. Fondamentalement, WebTorrent Desktop a été notre façon d'accélérer l'adoption du protocole WebTorrent. En créant une application torrent géniale que les gens veulent vraiment utiliser, nous augmentons le nombre de pairs dans le réseau qui ont la capacité partager des torrents avec des pairs web (ex : utilisateurs sur les sites Web).

Quels sont des cas d'utilisation intéressants pour les torrents au-delà de ce que les gens conaissent déjà ?​

Une des utilisations les plus excitantes pour WebTorrent est la diffusion assistée par pairs. Des projets à but non lucratif comme Wikipedia et l'Internet Archive pourraient réduire la bande passante et les coûts d'hébergement en permettant aux visiteurs de contribuer. Le contenu populaire peut être servi de navigateur à navigateur, rapidement et à moindre coût. Le contenu rarement consulté peut être servi de manière fiable via HTTP à partir du serveur d'origine.

L'Internet Archive a déjà mis à jour leurs fichiers torrent pour qu'ils fonctionnent au mieux avec WebTorrent. Donc, si vous voulez intégrer du contenu de l'Internet Archive à votre site, vous pouvez le faire d'une façon qui réduire les coûts d'hébergement pour l'Archive, leur permettant de consacrer plus de ressources à l'archivage effectif du web !

Il y a aussi de multiples cas d'utilisation métier excitant, des CDN à la livraison d'applications de pair-à-pair.

Quelque projets favoris qui utilisent WebTorrent ?​

La chose la plus cool construite avec WebTorrent est, de loin, probablement Gaia 3D Star Map. Il s'agit d'une simulation interactive en 3D de la Voie Lactée. Les données se chargent à partir d'un torrent, directement dans votre navigateur. C'est impressionnant de voler au travers notre système stellaire et de réaliser à quel point nous, les humains, sommes insignifiants comparés à l'immensité de notre univers.

Vous pouvez lire sur la réalisation du projet dans Torrenting The Galaxy (en anglais), un article de blog où l'auteur, Charlie Hoey, explique comment il a construit la carte des étoiles avec WebGL et WebTorrent.

Nous sommes également des admirateurs de Brave. Brave est un navigateur qui bloque automatiquement les publicités et les pisteurs pour rendre le Web plus rapide et plus sûr. Brave à récemment ajouté le support de torrent pour que vous puissiez voir les torrents traditionnels sans utiliser une application séparée (en anglais). Cette fonctionnalité est supportée grâce à WebTorrent.

Ainsi, tout comme la façon dont la plupart des navigateurs peuvent afficher des fichiers PDF, Brave peut afficher les liens magnet et les fichiers torrents. Ce sont juste un autre type de contenu que le navigateur prend en charge nativement.

L'un des cofondateurs de Brave est Brendan Eich, le créateur de JavaScript, le langage dans lequel nous avons écrit WebTorrent, donc nous pensons qu'il est assez cool que Brave ait choisi d'intégrer WebTorrent.

Pourquoi avez-vous choisi de créer WebTorrent Desktop sur Electron?​

Il y a un meme que les applications Electron sont « gonflées » parce qu'elles incluent l'intégralité du module de contenu Chrome dans chaque application. Dans certains cas, c'est partiellement vrai (un installateur d'applis Electron est généralement ~40 Mo, où un installateur d'applis spécifique au système d'exploitation est généralement ~20 Mo).

Cependant, dans le cas de WebTorrent Desktop, nous utilisons presque toutes les fonctionnalités d'Electron, et des dizaines de fonctionnalités de Chrome dans le cadre d'un fonctionnement normal. Si nous voulions implémenter ces fonctionnalités de zéro pour chaque plate-forme, il aurait fallu des mois ou des années de plus pour développer notre application, ou nous n'aurions pu être publiés que pour une seule plate-forme.

Juste pour donner une idée, nous utilisons l'intégration du dock d'Electron (pour afficher la progression du téléchargement), l'intégration de la barre de menu (pour l'exécution en arrière-plan), l'enregistrement des protocoles (pour ouvrir des liens magnet), le bloqueur d'économie d'énergie (pour éviter la mise en veille pendant la lecture vidéo) et la mise à jour automatique. En ce qui concerne les fonctionnalités de Chrome, nous utilisons également une grande quantité : la balise <video> (pour lire plusieurs formats vidéo différents), la balise <track> (pour la prise en charge des sous-titres), le support du glisser-déposer et WebRTC (qui n'est pas trivial à utiliser dans une application native).

Sans oublier : notre moteur torrent est écrit en JavaScript et présuppose l'existence de nombreuses API Node, principalement require('net') et require('dgram') pour le support des socket TCP et UDP.

Fondamentalement, Electron est exactement ce dont nous avions besoin et possède exactement le jeu de fonctionnalités dont nous avions besoin pour publier une application solide et soignée en un temps record.

Quelles sont vos choses préférées à propos d'Electron?​

La bibliothèque WebTorrent est en développement, en tant que projet open source, depuis deux ans. Nous avons créé WebTorrent Desktop en quatre semaines. Electron est la principale raison pour laquelle nous avons pu développer et publier notre application si rapidement.

Tout comme Node.js a rendu la programmation serveur accessible à une génération de programmeurs front-end habitués à jQuery, Electron rend le développement d'applications natives accessibles à tous ceux qui sont familiers avec Web ou le développement Node.js. Electron est extrêmement puissant.

Le site Web et le client Desktop partagent-ils leur code ?​

Oui, le paquet npm webtorrent fonctionne avec Node.js, le navigateur, et dans Electron. Le même code peut s’exécuter dans tous les environnements – c’est la beauté de JavaScript. C'est la plateforme d'exécution universelle d'aujourd'hui. Les applets Java ont promis des applications « Write Once, Run Anywhere » (n.d.l.t. : écrire une seule fois, exécuter partout, ancien slogan de Sun Microsystems), mais cette vision ne s'est jamais matérialisée, pour plusieurs raisons. Electron, plus que toute autre plate-forme, se rapproche réellement de cet idéal.

Quels sont les défis que vous avez rencontrés lors de la création de WebTorrent?​

Dans les premières versions de l'application, nous avons rencontré des difficultés à rendre l'interface plus performante. Nous avons mis le moteur torrent dans le processus de rendu qui dessine également la fenêtre principale de l'application, ce qui, de manière prévisible, a mené à des ralentissements à chaque fois qu'il y avait une activité CPU intense provenant du moteur de torrent (comme la vérification des segments de torrent reçus des pairs).

Nous avons corrigé cela en déplaçant le moteur de torrent dans un second processus de rendu, invisible, avec lequel nous communiquons au travers IPC. Ainsi, si ce processus utilise brièvement beaucoup de CPU, le processus responsable de l'interface utilisateur n'est pas affecté. Les animations et défilement délicats sont si satisfaisants.

Note : nous avons dû mettre le moteur torrent dans un processus de rendu au lieu d'un processus "main", parce que nous avons besoin d'accéder à WebRTC (qui n'est disponible que dans le rendu.)

Dans quels domaines faut-il améliorer Electron ?​

Une chose que nous aimerions voir est une meilleure documentation sur la façon de créer et de déployer des applications adaptées à la production, principalement autour de sujets délicats comme la signature de code et la mise à jour automatique. Nous avons dû apprendre les meilleures pratiques en creusant dans le code source et en demandant sur Twitter !

WebTorrent Desktop est-il terminé ? If not, what's coming next?​

Nous pensons que la version actuelle de WebTorrent Desktop est excellente, mais il est toujours possible de l'améliorer. Nous travaillons actuellement au polissage et à l'amélioration des performances, du support des sous-titres et des codecs vidéo.

Si vous souhaitez participer au projet, consultez notre page GitHub!

Quelque conseils de développement pour Electron qui pourraient être utiles à d'autres développeurs ?​

Feross, l'un des contributeurs de WebTorrent Desktop a récemment donné une conférence "Real world Electron: Building Cross-platform desktop apps with JavaScript" à la NodeConf Argentina qui contient des conseils utiles pour la publication d'une application Electron soignée. La conférence est particulièrement utile si vous êtes au stade où vous avez une application de travail de base et que vous essayez de la faire passer au niveau suivant du polissage et du professionnalisme.

Regarder ici (en anglais):

Présentation ici (en anglais):

DC, un autre contributeur WebTorrent, a écrit une liste des choses que vous pouvez faire (en anglais) pour que votre application apparaisse soignée et native. Il est livré avec des exemples de code et couvre des sujets tels que l'intégration du dock macOS, le glisser-déposer, les notifications de bureau et l'assistance pour que votre application se lance rapidement.

Cette semaine, nous avons rencontré Aprile Elcich et Paolo Fragomeni pour parler de Voltra, un lecteur de musique basé sur Electron.

Qu'est-ce que Voltra ?​

Voltra est un lecteur de musique destiné aux personnes qui veulent posséder leur musique. C’est aussi un magasin où vous pouvez découvrir et acheter de nouvelles musiques en fonction de ce que vous possédez déjà. Voltra est sans publicité, multi-plateformes pour bureau et mobile. De plus, il ne vous espionne pas.

À qui destiné Voltra ?​

A quiconque écoutant de la musique.

Qu'est-ce qui vous a motivé à créer Voltra?​

La radio a toujours eu une grande part d'auditeurs. Elle quitte les ondes pour l'Internet. Maintenant vous pouvez louer de la musique à la demande — c'est le renouveau de la radio ! De nombreux nouveaux produits et services ont vu le jour grâce à cela, mais la radio en streaming laisse encore quelqu'un d'autre au contrôle de votre musique et la façon dont vous la vivez.

Nous voulions un produit entièrement axé sur la musique que vous possédez. Quelque chose qui permette de découvrir et d'acheter facilement de la nouvelle musique directement auprès des artistes ou des labels.

Existe il une version gratuite ?​

Le lecteur de bureau est complètement gratuit. Vendre votre musique est également gratuit ! Nous ne sommes pas financés par la publicité.

Puisque l'application est gratuite, nous pourrions en ouvrir les sources plus tard. Pour le moment, nous n'avons pas la bande passante pour gérer cela. Nous avons également des idées très précises concernant les fonctionnalités et la direction que nous voulons donner aux choses. Nous avons une communauté bêta active et nous prenons les commentaires à cœur.

Comment gagnez-vous de l'argent ?​

Nous avons des fonctionnalités premium !

Notre archive audio Voltra est un service de sauvegarde cloud conçu spécifiquement pour la musique. Nous ne compressons ni ne partageons les blocs de données. Votre collection musicale est sauvegardée physiquement pour vous.

Pour les artistes et labels, notre adhésion pro offre des outils qui les aident à atteindre des publics plus pertinents, tels que des analytiques et des pages web professionnelles pour les artistes.

Qu'est-ce qui rend Voltra différent?​

Le design et la facilité d'utilisation sont extrêmement importants pour nous. Nous voulons offrir aux auditeurs une expérience d'écoute sans distraction ! Il existe des lecteurs de musique et des magasins intéressants. Mais beaucoup d'entre eux sont plus avancés et plus difficiles à utiliser que leurs créateurs ne le pensent. Nous voulons rendre Voltra accessible au plus grand nombre de personnes possible.

Nous ne prenons pas non plus de commission sur l'artiste ou le label. C'est un différenciateur clé pour nous. C'est vraiment important car cela abaisse la barrière pour les artistes qui souhaitent commercialiser leur musique.

Quels sont les aspects de design & décisions techniques que vous avez prises?​

En concevant Voltra, nous avons envisagé des conventions de l'interface utilisateur à partir d'applications natives et du web, nous avons également beaucoup réfléchi à ce que nous pouvions supprimer. Nous avons un groupe bêta privé actif qui nous a donné des commentaires critiques au cours de ces derniers mois.

Nous avons découvert que les pochettes d'album et la photographie sont vraiment importantes pour les gens. De nombreux lecteurs ne sont que des listes de fichiers. L'une des choses intéressantes de la possession d'albums physiques est la pochette de l'album, et nous avons voulu mettre l'accent sur cet aspect dans l'application de bureau Voltra.

Nous nous sommes également assurés de ne pas toucher aux fichiers des gens. Nous utilisons la surveillance de fichiers pour que vous puissiez placer vos fichiers où vous voulez, nous ne les renommons pas et ne les déplaçons pas pour vous. Nous disposons d'une base de données intégrée pour suivre l'état des répertoires surveillés afin de pouvoir suivre ce qui est nouveau, même lorsque le processus n'est pas en cours d'exécution.

Quels sont les défis que vous avez rencontrés lors de la création de Voltra ?​

Nous passons beaucoup de temps à nous concentrer sur les performances. Nous avons commencé avec des frameworks, mais nous sommes passés à du Javascript classique. D'après notre expérience, les abstractions généralisées qu'ils fournissent l'emportent sur les pénalités de performance et le cérémonial qu'ils introduisent.

Nous gérons assez bien les très grandes collections à ce stade. De grandes collections signifient potentiellement des dizaines de milliers d'images ! Le fait d'avoir le module de système de fichiers de Node.js directement accessible depuis le processus de rendu a permis de facilement charger et de décharger paresseusement de nombreuses images très rapidement en fonction des événements DOM.

En général setImmediate et requestIdleCallback ont été des outils super importants pour effectuer beaucoup de traitement tout en maintenant l'interface utilisateur réactive. Plus précisément, la répartition des tâches liées au processeur dans des processus distincts aide beaucoup à garder l'interface utilisateur réactive. Par exemple, nous avons déplacé le contexte audio dans un processus distinct, communiquant avec l'interface par IPC pour éviter les interruptions potentielles d'une interface utilisateur occupée.

Pourquoi avez-vous choisi de construire Voltra avec Electron?​

Le bac à sable du navigateur est trop restreint pour notre application. Mais nous développons également un lecteur web. Le fait que nous puissions partager presque 100 % du code entre les deux implémentations est donc une grande victoire.

Nous avons en fait commencé par construire une application native avec Swift. Le principal problème que nous avons rencontré était que nous devions réinventer beaucoup de choses. Le web possède le plus grand écosystème open source au monde. Nous sommes donc assez rapidement passés à Electron.

De plus, et c'est le plus important, avec Electron, vous développez une fois et cela devrait Juste Fonctionner™ sur toutes les principales plateformes. Ce n'est pas garanti, mais le coût du codage natif pour chaque plateforme dépasse nettement sur les autres coûts qu'Electron introduit.

Quelles sont vos choses préférées à propos d'Electron?​

GTD!: Having Node.js’ networking stack and Chromium’s presentation layer packaged together is a recipe for getting things done.

Compétence : C'est juste la couche web, donc littéralement toute notre équipe est impliquée dans la construction du produit.

Communauté : Il existe une communauté très organisée qui sait très bien communiquer ! Nous sommes très heureux de pouvoir nous développer avec un tel soutien.

Dans quels domaines Electron pourrait-il être amélioré ?​

Nous aimerions voir Electron approuver un seul empaqueteur. L'empaqueteur est aussi important pour Electron que le gestionnaire de paquets est à Node. Il y a plusieurs empaqueteurs dans la zone utilisateur, chacun avec des fonctionnalités intéressantes, mais chacun avec des bogues. Un consensus de la communauté permettrait de diriger l'énergie dépensée par les contributeurs.

What's coming next?​

Nous développons actuellement une application mobile et travaillons avec des artistes et des labels pour ajouter leur musique à la boutique Voltra. Hé ! Si vous êtes un artiste ou un label, inscrivez-vous maintenant ! Nous prévoyons d'ouvrir la boutique lorsque nous aurons atteint notre objectif de 10 millions de titres.