Over the course of the GSoC program, I implemented an API history feature for the
Electron documentation and its functions, classes, etc. in a similar fashion to the
Node.js documentation: by allowing the
use of a simple but powerful YAML schema in the API documentation Markdown files
and displaying it nicely on the Electron documentation website.
¡Estamos encantados de anunciar que Electron ha sido aceptado como una organización mentora para
la vigésima edición de Google Summer of Code (GSoC) 2024! Google Summer of Code es un programa
global centrado en traer nuevos colaboradores al desarrollo de software de código abierto.
Electron es un framework JavaScript para construir aplicaciones multiplataforma de escritorio usando
tecnologías web. El framework central de Electron es un ejecutable binario compilado construido con
Chromium y Node.js, y está escrito principalmente en C++.
Fuera del núcleo de Electron, también trabajamos en una variedad de proyectos para ayudar a sostener la organización de
Electron como:
Herramientas internas para optimizar la productividad del desarrollador (por ejemplo, Electron Build Tools
y Sheriff).
Como colaborador de Summer of Code, estarías colaborando con algunos de los principales colaboradores de Electron
en uno de los muchos proyectos bajo el paraguas github.com/electron.
Si esta es tu primera participación en Google Summer of Code o si eres nuevo en código abierto en general
recomendamos leer la [Guía de colaboradores](https://google. ithub.io/gsocguides/student/) como un primer paso
antes de comprometerse con la comunidad.
¿Estás interesado en colaborar con Electron? Primero, revisa los siete borradores de ideas del proyecto
que hemos preparado. Todas las ideas de la lista están actualmente abiertas a propuestas.
¿Tienes una idea diferente que te gustaría tener en cuenta? También estamos abiertos a aceptar nuevas ideas que
no están en la lista de proyectos propuestos. pero asegúrese de que su enfoque está completamente esbozado y detallado.
En caso de duda, le recomendamos que se aferre a nuestras ideas listadas.
Su solicitud debe incluir:
Tu propuesta: un documento escrito que describe en detalle lo que planeas lograr durante
el curso del verano.
Su experiencia como desarrollador. Si tiene un currículum, por favor incluya una copia. De lo contrario,
cuéntanos tu experiencia técnica pasada.
La falta de experiencia en ciertas áreas no te descalificará, pero ayudará a nuestros mentores
a elaborar un plan para ayudarte mejor y asegurarte de que tu proyecto de verano sea un éxito.
[Aquí está una guía detallada de qué enviar como parte de tu aplicación Electron.](https://electronhq.notion. ite/Electron-GSoC-2024-Contributor-Guidance-f1f4de7a0d9a4664a96c8d4dd70cb208?pvs=4)
Enviar propuestas directamente al portal de Google Summer of Code. Tenga en cuenta que las propuestas enviadas por correo electrónico al equipo
Electron en lugar de enviarlas a través del portal de la aplicación no serán consideradas como un envío final.
Si desea más orientación sobre su propuesta o no está seguro de qué incluir, también recomendamos que
sigas [la propuesta oficial de Google Summer of Code escribiendo consejos aquí](https://google. ithub.io/gsocguides/student/writing-a-proposal).
Aplicaciones abiertas el 18 de marzo de 2024 y cierran el 2 de abril de 2024.
info
Nuestro interlocutor de Google Summer of Code 2022, @aryanshridhar,
hizo un trabajo increíble! Si quieres ver en qué trabajó Aryan durante su verano con Electron,
puedes leer su informe en [2022 GSoC program archives](https://summerofcode. ithgoogle.com/archive/2022/organizations/electron).
Si tienes preguntas que no enviamos en las publicaciones del blog o consultas para tu borrador de propuestas,
por favor envíanos un correo electrónico a Summer-of-code@electronjs. rg o revisa GSoC FAQ!
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.
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.
info
For the RFC to become Active, the PR must be approved by at least 2 API Working Group members.
Before merging, the RFC should be presented synchronously and accepted unanimously by a quorum of at
least two-thirds of the WG members. If consensus is reached, a one-month final comment period will
be triggered, after which the PR will be merged.
An Active RFC is Completed if the implementation has been merged into electron/electron.
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:
El primer commit en el repositorio electron/electron fue el 13 de marzo de 20131.
10 años y 27.147 commits más de 1192 colaboradores únicos después, Electron se ha convertido en uno de los frameworks más populares para crear aplicaciones de escritorio hoy en día. Este hito es la oportunidad perfecta para celebrar y reflexionar sobre nuestro viaje hasta ahora, y para compartir lo que hemos aprendido en el camino.
No estaríamos aquí hoy sin todos los que han dedicado su tiempo y esfuerzo a contribuir al proyecto. Aunque los commits del código fuente son siempre las contribuciones más visibles, también tenemos que reconocer el esfuerzo de la gente que informa de errores, mantiene módulos de usuario, proporciona documentación y traducciones, y participa en la comunidad Electron a través del ciberespacio. Cada contribución tiene un valor incalculable para nosotros como mantenedores.
Antes de continuar con el resto de la entrada del blog: gracias. ❤️
Atom Shell se construyó como la columna vertebral para el editor Atomde GitHub, que se lanzó en beta pública en abril de 2014. Se construyó desde cero como alternativa a los frameworks de escritorio basados en web disponibles en ese momento (node-webkit y Chromium Embedded Framework). Tenía una característica estrella: contiene Node.js y Chromium para proporcionar un potente tiempo de ejecución de escritorio para tecnologías web.
Al cabo de un año, Atom Shell empezó a crecer enormemente en capacidades y popularidad. Grandes compañías, startups y desarrolladores individuales habían empezado a construir aplicaciones con él (algunos de los primeros adoptores incluyen Slack, GitKraken, y WebTorrent), y el proyecto fue renombrado correctamente a Electron.
Desde entonces, Electron no ha parado de crecer. Aquí tienes un vistazo a nuestro recuento semanal de descargas con el tiempo, cortesía de npmtrends.com:
Electron v1 se lanzó en 2016, prometiendo una mayor estabilidad de la API y mejores documentos y herramientas. Electron v2 se lanzó en 2018 e introdujo el versionado semántico, lo que facilita a los desarrolladores de Electron a los desarrolladores hacer un seguimiento del ciclo de lanzamiento.
En Electron v6, cambiamos a una cadencia regular de lanzamientos principales de 12 semanas para ajustarnos a la de Chromium. Esta decisión supuso un cambio de mentalidad para el proyecto, haciendo que "tener la versión más actualizada de Chromium" pasara de ser un "nice-to-have" a una prioridad. Esto ha reducido la cantidad de deuda técnica entre actualizaciones, lo que nos facilita mantener Electron actualizado y seguro.
Desde entonces, hemos sido una máquina bien engrasada, lanzando una nueva versión de Electron el mismo día que cada versión estable de Chromium. Cuando Chromium aceleró su calendario de lanzamientos a 4 semanas en 2021, pudimos encogernos de hombros y aumentar nuestra cadencia de lanzamiento a 8 semanas.
Ahora estamos en Electron v23 (y contando), y seguimos dedicados a construir el mejor tiempo de ejecución para aplicaciones de escritorio multiplataforma. Incluso con el auge de las herramientas para desarrolladores de JavaScript en desarrolladores de JavaScript en los últimos años, Electron se ha mantenido estable y ha de escritorio. Las aplicaciones de Electron son omnipresentes hoy en día: puedes programar con Visual Studio Code, diseñar con Figma, comunicarte con Slack y tomar notas con Notion (entre muchos otros casos de uso). Estamos increíblemente orgullosos de este logro y agradecidos con todos aquellos que lo hicieron posible.
El camino hacia la marca de la década ha sido largo y sinuoso. Aquí hay algunas claves que nos han ayudado a mantener un proyecto de código abierto grande y sostenible.
Escalando la toma de decisiones distribuida con un modelo de gobernanza
Uno de los desafíos que tuvimos que superar fue manejar la dirección a largo plazo del proyecto una vez que Electron explotó en popularidad. ¿Cómo manejamos ser un equipo de varias docenas de ingenieros distribuidos en diferentes empresas, países y zonas horarias?
En los primeros días, el grupo de mantenimiento de Electron dependía de la coordinación informal, lo que es rápido y ligero para proyectos más pequeños, pero no es escalable para una colaboración más amplia. En 2019, cambiamos a un modelo de gobernanza donde diferentes grupos de trabajo tienen áreas formales de responsabilidad. Esto ha sido fundamental para optimizar los procesos y asignar porciones de propiedad del proyecto a mantenedores específicos. ¿De qué es responsable cada Grupo de Trabajo (WG) en la actualidad?
Sacar las versiones de Electron (Releases WG)
Actualizar Chromium y Node.js (Upgrades WG)
Supervisar el diseño de la API pública (API WG)
Mantener Electron seguro (Security WG)
Administrar el sitio web, documentación y herramientas (Ecosystem WG)
Alcanzar a la comunidad y a las empresas (Outreach WG)
Moderación de la comunidad (Community & Safety WG)
Mantener nuestra infraestructura de compilación, herramientas de mantenedor y servicios en la nube (Infrastructure WG)
Alrededor de la misma época en que cambiamos al modelo de gobernanza, también trasladamos la propiedad de Electron de GitHub a la OpenJS Foundation. Aunque el equipo central original todavía funciona en Microsoft hoy, son sólo parte de un grupo de colaboradores más grande que forman la gobernanza de Electron.2
Si bien este modelo no es perfecto, nos ha funcionado bien a través de una pandemia global y vientos macroeconómicos en curso. En el futuro, planeamos renovar la carta de gobernanza para guiarnos a través de la segunda década de Electron.
La parte de la comunidad de código abierto es difícil, especialmente cuando tu equipo de divulgación está compuesto por una docena de ingenieros disfrazados con una gabardina que dice "gerente de comunidad". Dicho esto, ser un proyecto de código abierto grande significa que tenemos muchos usuarios, y aprovechar su energía para construir un ecosistema de usuarios para Electron es una parte crucial para mantener la salud del proyecto.
¿Qué hemos estado haciendo para desarrollar nuestra presencia en la comunidad?
En 2020, lanzamos nuestro servidor de Discord. Anteriormente teníamos una sección en el foro de Atom, pero decidimos tener una plataforma de mensajería más informal para tener un espacio para discusiones entre mantenedores y desarrolladores de Electron, así como para obtener ayuda general de depuración.
En 2021, establecimos el grupo de usuarios de Electron China con la ayuda de @BlackHole1. Este grupo ha sido fundamental para el crecimiento de Electron en usuarios de la floreciente escena tecnológica de China, proporcionando un espacio para que colaboren en ideas y discutan sobre Electron fuera de nuestros espacios en inglés. También nos gustaría agradecer a cnpm por su trabajo en apoyar las versiones nocturnas de Electron en su espejo chino para npm.
Participar en programas de código abierto de alta visibilidad
Desde 2019 hemos estado celebrando el Hacktoberfest cada año. Hacktoberfest es una celebración anual de código abierto organizada por DigitalOcean, y desde 2019 hemos estado participando en ella. Cada año recibimos docenas de entusiastas contribuyentes que buscan dejar su huella en el software de código abierto.
En 2020, participamos en la primera iteración de Google Season of Docs, donde trabajamos con @bandantonio para reorganizar el flujo del tutorial de usuario nuevo de Electron.
En 2022, mentorizamos a un estudiante en el programa Google Summer of Code por primera vez. @aryanshridhar did some awesome work to refactor Electron Fiddle's core version loading logic and migrate its bundler to webpack.
Hoy en día, la gobernanza de Electron cuenta con alrededor de 30 mantenedores activos. Menos de la mitad de nosotros somos contribuidores a tiempo completo, lo que significa que hay mucho trabajo para compartir. ¿Cuál es nuestro truco para mantener todo funcionando sin problemas? Nuestro lema es que las computadoras son baratas y el tiempo humano es caro. Al estilo típico de los ingenieros, hemos desarrollado una serie de herramientas de soporte automatizadas para facilitar nuestras vidas.
La base de código principal de Electron es un gigante de código en C++, y los tiempos de compilación siempre han sido un factor limitante en la velocidad con la que podemos implementar correcciones de errores y nuevas funcionalidades. En 2020, implementamos Not Goma, una plataforma personalizada específica para Electron para el servicio de compilador distribuido de Google llamado Goma. Not Goma procesa las solicitudes de compilación de las máquinas autorizadas de los usuarios y distribuye el proceso en cientos de núcleos en el backend. Además, Not Goma también almacena en caché el resultado de la compilación para que alguien más que compile los mismos archivos solo necesite descargar el resultado precompilado.
Desde que lanzamos Not Goma, los tiempos de compilación para los mantenedores han disminuido de varias horas a unos pocos minutos. ¡Una conexión estable a internet se convirtió en el requisito mínimo para que los contribuyentes pudieran compilar Electron!
info
Si eres un contribuidor de código libre, puedes probar Not Goma's cache de lectura, el cual está disponible de forma predeterminada con h Electrón Build Tools.
Autenticación de Factor Continuo (CFA) es una capa de automatización en torno al sistema de autenticación de dos factores (2FA) de npm que combinamos con semantic-release para gestionar lanzamientos seguros y automatizados de nuestros diversos paquetes npm de @electron/.
Mientras que semantic-release ya automatiza el proceso de publicación de paquetes de npm, requiere desactivar la autenticación de dos factores o pasar un token secreto que evita esta restricción.
Construimos CFA para entregar una contraseña de un solo uso basada en el tiempo (TOTP) para el 2FA de npm a trabajos de integración continua (CI) arbitrarios, lo que nos permite aprovechar la automatización de semantic-release manteniendo la seguridad adicional de la autenticación de dos factores.
Usamos CFA con una interfaz integrada en Slack, lo que permite a los mantenedores validar la publicación de paquetes desde cualquier dispositivo en el que tengan Slack, siempre y cuando tengan su generador de TOTP a mano.
info
¡Si quieres probar CFA en sus propios proyectos, consulte el repositorio de GitHub o la documentación! Si utilizas CircleCI como proveedor de CI, también tenemos un práctico orb para configurar rápidamente un proyecto con CFA.
Sheriff es una herramienta de código abierto que escribimos para automatizar la gestión de permisos en GitHub, Slack y Google Workspace.
La propuesta de valor clave de Sheriff es que la gestión de permisos debe ser un proceso transparente. Utiliza un único archivo de configuración YAML que designa los permisos en todos los servicios mencionados anteriormente. Con Sheriff, obtener el estado de colaborador en un repositorio o crear una nueva lista de correo es tan fácil como obtener la aprobación y la fusión de una PR.
Sheriff también cuenta con un registro de auditoría que se publica en Slack, alertando a los administradores cuando ocurre actividad sospechosa en cualquier lugar de la organización Electron.
GitHub es una plataforma con una amplia extensibilidad de API y un marco de aplicación de bot de "first-party" llamado Probot. Para ayudarnos a enfocarnos en las partes más creativas de nuestro trabajo, creamos una suite de bots más pequeños que nos ayudan a realizar el trabajo sucio. Aquí hay algunos ejemplos:
Sudowoodo automatiza el proceso de lanzamiento de Electron de principio a fin, desde el inicio de compilaciones hasta la carga de activos de lanzamiento en GitHub y npm.
Trop automatiza el proceso de retroportar para Electron al intentar seleccionar parches a ramas de lanzamiento anteriores basadas en las etiquetas de PR de GitHub.
Roller automatiza las actualizaciones rodantes de las dependencias de Chromium y Node.js de Electron.
Cation es nuestro bot de verificación de estado para las PR de electron/electron.
¡En conjunto, nuestra pequeña familia de bots nos ha dado un gran impulso en la productividad de los desarrolladores!
Al entrar en nuestra segunda década como proyecto, es posible que te preguntes: ¿qué sigue para Electron?
Vamos a mantenernos en sincronía con el ritmo de lanzamiento de Chromium, publicando nuevas versiones principales de Electron cada 8 semanas, manteniendo el framework actualizado con lo último y lo mejor de la plataforma web y Node.js mientras mantenemos la estabilidad y seguridad para aplicaciones de calidad empresarial.
Generalmente anunciamos noticias sobre próximas iniciativas cuando se vuelven concretas. ¡Si quieres estar al tanto de futuros lanzamientos, funciones y actualizaciones generales del proyecto, puedes leer nuestro blog y seguir nuestros perfiles en redes sociales (Twitter y Mastodon)!
Este es en realidad el primer commit del proyecto electron-archive/brightray project, que se incorporó a Electron en 2017 y tuvo su historial de git fusionado. Pero, ¿quién está contando? ¡Es nuestro cumpleaños, así que nosotros hacemos las reglas! ↩
Contrario a las creencias populares, Electron ya no es propiedad de GitHub o Microsoft, y es parte de la Fundación OpenJS hoy en día. ↩
Google Summer of Code (GSoC) celebrado cada año, es un programa de mentorías que busca conectar proyectos de código abierto con futuros posibles colaborares. Anteriormente solo era abierto para estudiantes, ahora cualquier persona mayor de 18 años puede registrarse en Google Summer of Code.
¿Estás interesado en colaborar con Electrón? ¡Si eres un colaborador novato o principiante en el código abierto, le damos la bienvenida a su solicitud!
¿Quieres presentar tu candidatura? Primero, revisa los cinco borradores de ideas de proyecto que hemos preparado. Todas las ideas de la lista están actualmente abiertas a propuestas. También estamos abiertos a aceptar nuevas ideas que no estén en la lista de proyectos propuestos.
Su solicitud debe incluir:
Tu propuesta, que es un documento escrito que describe en detalle lo que planeas conseguir en el transcurso del verano.
Su experiencia como desarrollador. Si tiene un currículum vitae, incluya una copia; de lo contrario, háblenos de su experiencia anterior haciendo hincapié en la experiencia técnica relevante.
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.
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.
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.
P.S. If you're feeling particularly adventurous, we also have a backlog of issues marked with help wanted tags if you're looking for more of a challenge.
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. In case you missed it, here's the invite link again!
Electron se enorgullece de estar participando en la segunda edición de la iniciativa de la Temporada de Documentación de Google (Google Season of Docs Initiative) que combina mentores de organizaciones de código abierto con escritores técnicos para mejorar la documentación del proyecto.
¿Qué es la Season of Docs?
Season of Docs es un programa que promueve la colaboración entre escritores técnicos y comunidades de código abierto en beneficio de ambas partes. Los mantenedores de código abierto utilizan la experiencia de escritura técnica del escritor para mejorar la estructura y el contenido de su documentación, mientras que el escritor técnico es presentado a una comunidad de código abierto bajo la guía de sus mentores. Obtenga más información sobre ello en el sitio web Season of Docs de Google.
Por primera vez participando en este programa, estaremos orientando a un solo escritor técnico que estará trabajando junto al Grupo de trabajo del ecosistema de Electron para remodelar partes de nuestra documentación. Puedes aprender más sobre la línea temporal de todo el proyecto aquí.
¿Cómo me registro?
¿Está interesado en colaborar con nosotros como escritor técnico? En primer lugar, familiarízate con la guía de escritura técnica de Google para el programa de este año y revisa los dos borradores de ideas del proyecto que hemos preparado.
Para ser seleccionado como escritor técnico de Electron para Season of Docs, los candidatos tendrán que solicitar en el sitio web de Google Season of Docs durante la fase de Solicitud de Escritor Técnico que se está ejecutando del 8 de junio al 9 de julio..
Tu solicitud debe incluir una propuesta, que es un documento escrito que describe en detalle lo que planeas lograr en los documentos de electrones durante el transcurso de 3 meses. Esta propuesta puede desarrollarse en uno de los puntos de partida mencionados en nuestro proyecto de idea doc, o puede ser algo completamente nuevo. ¿No sabes por dónde empezar? Puedes revisar la lista de propuestas aceptadas del año pasado para inspirarte.
Aparte de la propuesta, también estudiaremos sus antecedentes como escritor técnico. Por favor incluya una copia de su currículum con énfasis en la experiencia de escritura relevante, así como muestras técnicas de escritura (estas muestras podrían ser documentación existente, tutorial, artículos de blog, etc.)
Si quieres discutir las propuestas de proyecto, ¡envíanos un correo electrónico a season-of-docs@electronjs.org y podemos chatear desde ahí!
Estamos trabajando en hacer el ciclo de desarrollo de Electrón más rápido y estable. Para hacerlo posible, hemos iniciado el Programa de Comentarios de Aplicaciones para aplicaciones Electron a gran escala para probar nuestras versiones beta y reportarnos problemas específicos de la aplicación. Esto nos ayuda a priorizar el trabajo que hará que las aplicaciones se actualicen antes a nuestra próxima versión estable.
Edición (2020-05-21): Este programa ha sido retirado.
Entendemos que no todos pueden compartir números de usuario exactos, sin embargo mejores datos nos ayudan a decidir cuán estable es una versión en particular. Pedimos que las aplicaciones se comprometan a probar un número mínimo de horas de usuario, actualmente 10.000 en todo el ciclo beta.
10 horas de usuario podrían ser 10 personas probando por una hora, o una persona probando por 10 horas
Puede dividir la prueba entre versiones beta, por ejemplo prueba de 5.000 horas de usuario en 3.0.0-beta. y luego pruebe por 5.000 horas de usuario en 3.0.0-beta.5. Más es mejor, pero entendemos que algunas aplicaciones no pueden probar cada versión beta
Las horas CI o QA no cuentan para el total; sin embargo, las versiones internas cuentan
Los errores de tu aplicación serán rastreados y estarán en el radar del núcleo del equipo de Electron. Sus comentarios ayudan al equipo de Electron a ver cómo están haciendo las nuevas betas y qué trabajo hay que hacer.
¿Se compartirá la información de mi aplicación públicamente? ¿Quién puede ver esta información?
No, la información de su aplicación no se compartirá con el público en general. La información se mantiene en un repositorio privado de GitHub que sólo es visible para los miembros del Programa de Comentarios de la aplicación y Gobernanza Electron. Todos los miembros han aceptado seguir el Código de Conducta de Electron.
Actualmente estamos aceptando un número limitado de registros. Si está interesado y puede cumplir con los requisitos anteriores, por favor rellene este formulario.
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.
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!
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.
Issues that are requested review by cat. But these are not reviewed yet.
is:pr reviewed-by:cat
Issues that are reviewed by cat
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.
Jasper also has features for unread issue management, unread comment management, marking stars, notification updating, filtering issues, keyboard shortcuts, etc.
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. Al principio consideré usar la API de Notificaciones de GitHub. However I noticed that it does not support certain use cases. Después de eso consideré usar la API de problemas y API de Pull Requests, además de la API de Notificación. But it never became what I wanted. Entonces mientras pensaba en varios métodos, me di cuenta de que el sondeo de la API de búsqueda de GitHub ofrecería la mayor flexibilidad. 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.
This week we caught up with @feross and @dcposch to talk about WebTorrent, the web-powered torrent client that connects users together to form a distributed, decentralized browser-to-browser network.
WebTorrent is the first torrent client that works in the browser. It's written completely in JavaScript and it can use WebRTC for peer-to-peer transport. No browser plugin, extension, or installation is required.
Using open web standards, WebTorrent connects website users together to form a distributed, decentralized browser-to-browser network for efficient file transfer.
You can see a demo of WebTorrent in action here: webtorrent.io.
Imagine a video site like YouTube, but where visitors help to host the site's content. The more people that use a WebTorrent-powered website, the faster and more resilient it becomes.
Browser-to-browser communication cuts out the middle-man and lets people communicate on their own terms. No more client/server – just a network of peers, all equal. WebTorrent is the first step in the journey to re-decentralize the Web.
About one year ago, we decided to build WebTorrent Desktop, a version of WebTorrent that runs as a desktop app.
We created WebTorrent Desktop for three reasons:
We wanted a clean, lightweight, ad-free, open source torrent app
We wanted a torrent app with good streaming support
We need a "hybrid client" that connects the BitTorrent and WebTorrent networks
If we can already download torrents in my web browser, why a desktop app?
First, a bit of background on the design of WebTorrent.
In the early days, BitTorrent used TCP as its transport protocol. Later, uTP came along promising better performance and additional advantages over TCP. Every mainstream torrent client eventually adopted uTP, and today you can use BitTorrent over either protocol. The WebRTC protocol is the next logical step. It brings the promise of interoperability with web browsers – one giant P2P network made up of all desktop BitTorrent clients and millions of web browsers.
“Web peers” (torrent peers that run in a web browser) make the BitTorrent network stronger by adding millions of new peers, and spreading BitTorrent to dozens of new use cases. WebTorrent follows the BitTorrent spec as closely as possible, to make it easy for existing BitTorrent clients to add support for WebTorrent.
Some torrent apps like Vuze already support web peers, but we didn't want to wait around for the rest to add support. So basically, WebTorrent Desktop was our way to speed up the adoption of the WebTorrent protocol. By making an awesome torrent app that people really want to use, we increase the number of peers in the network that can share torrents with web peers (i.e. users on websites).
What are some interesting use cases for torrents beyond what people already know they can do?
One of the most exciting uses for WebTorrent is peer-assisted delivery. Non-profit projects like Wikipedia and the Internet Archive could reduce bandwidth and hosting costs by letting visitors chip in. Popular content can be served browser-to-browser, quickly and cheaply. Rarely-accessed content can be served reliably over HTTP from the origin server.
The Internet Archive actually already updated their torrent files so they work great with WebTorrent. So if you want to embed Internet Archive content on your site, you can do it in a way that reduces hosting costs for the Archive, allowing them to devote more money to actually archiving the web!
There are also exciting business use cases, from CDNs to app delivery over P2P.
What are some of your favorite projects that use WebTorrent?
The coolest thing built with WebTorrent, hands down, is probably Gaia 3D Star Map. It's a slick 3D interactive simulation of the Milky Way. The data loads from a torrent, right in your browser. It's awe-inspiring to fly through our star system and realize just how little we humans are compared to the vastness of our universe.
You can read about how this was made in Torrenting The Galaxy, a blog post where the author, Charlie Hoey, explains how he built the star map with WebGL and WebTorrent.
We're also huge fans of Brave. Brave is a browser that automatically blocks ads and trackers to make the web faster and safer. Brave recently added torrent support, so you can view traditional torrents without using a separate app. That feature is powered by WebTorrent.
So, just like how most browsers can render PDF files, Brave can render magnet links and torrent files. They're just another type of content that the browser natively supports.
One of the co-founders of Brave is actually Brendan Eich, the creator of JavaScript, the language we wrote WebTorrent in, so we think it's pretty cool that Brave chose to integrate WebTorrent.
Why did you choose to build WebTorrent Desktop on Electron?
Hay un meme que las aplicaciones Electron están "infladas" porque incluyen todo el módulo de contenido de Chrome en todas las aplicaciones. En algunos casos, esto es parcialmente cierto (un instalador de aplicaciones Electron suele ser ~40MB, donde un instalador de aplicaciones específicas del sistema operativo suele ser ~20MB).
However, in the case of WebTorrent Desktop, we use nearly every Electron feature, and many dozens of Chrome features in the course of normal operation. If we wanted to implement these features from scratch for each platform, it would have taken months or years longer to build our app, or we would have only been able to release for a single platform.
Just to get an idea, we use Electron's dock integration (to show download progress), menu bar integration (to run in the background), protocol handler registration (to open magnet links), power save blocker (to prevent sleep during video playback), and automatic updater. As for Chrome features, we use plenty: the <video> tag (to play many different video formats), the <track> tag (for closed captions support), drag-and-drop support, and WebRTC (which is non-trivial to use in a native app).
Not to mention: our torrent engine is written in JavaScript and assumes the existence of lots of Node APIs, but especially require('net') and require('dgram') for TCP and UDP socket support.
Basically, Electron is just what we needed and had the exact set of features we needed to ship a solid, polished app in record time.
The WebTorrent library has been in development as an open source side project for two years. We made WebTorrent Desktop in four weeks. Electron is the primary reason that we were able to build and ship our app so quickly.
Just as Node.js made server programming accessible to a generation of jQuery-using front-end programmers, Electron makes native app development accessible to anyone familiar with Web or Node.js development. Electron is extremely empowering.
Do the website and the Desktop client share code?
Yes, the webtorrent npm package works in Node.js, in the browser, and in Electron. The exact same code can run in all environments – this is the beauty of JavaScript. It's today's universal runtime. Java Applets promised "Write Once, Run Anywhere" apps, but that vision never really materialized for a number of reasons. Electron, more than any other platform, actually gets pretty darn close to that ideal.
What are some challenges you've faced while building WebTorrent?
In early versions of the app, we struggled to make the UI performant. We put the torrent engine in the same renderer process that draws the main app window which, predictably, led to slowness anytime there was intense CPU activity from the torrent engine (like verifying the torrent pieces received from peers).
We fixed this by moving the torrent engine to a second, invisible renderer process that we communicate with over IPC. This way, if that process briefly uses a lot of CPU, the UI thread will be unaffected. Buttery-smooth scrolling and animations are so satisfying.
Note: we had to put the torrent engine in a renderer process, instead of a "main" process, because we need access to WebRTC (which is only available in the renderer.)
One thing we'd love to see is better documentation about how to build and ship production-ready apps, especially around tricky subjects like code signing and auto-updating. We had to learn about best practices by digging into source code and asking around on Twitter!
Is WebTorrent Desktop done? If not, what's coming next?
We think the current version of WebTorrent Desktop is excellent, but there's always room for improvement. We're currently working on improving polish, performance, subtitle support, and video codec support.
If you're interested in getting involved in the project, check out our GitHub page!
Any Electron development tips that might be useful to other developers?
Feross, one of the WebTorrent Desktop contributors, recently gave a talk "Real world Electron: Building Cross-platform desktop apps with JavaScript" at NodeConf Argentina that contains useful tips for releasing a polished Electron app. La charla es especialmente útil si estás en el escenario donde tienes una aplicación básica de trabajo y estás intentando llevarla al siguiente nivel de pulido y profesionalismo.
DC, another WebTorrent contributor, wrote a checklist of things you can do to make your app feel polished and native. It comes with code examples and covers things like macOS dock integration, drag-and-drop, desktop notifications, and making sure your app loads quickly.
