Saltar al contenido principal

23 publicaciones etiquetados con "Comunidad"

Community initiatives in Electron

Ver todas las categorías

Introducing API History (GSoC 2024)

· 7 lectura mínima

Historical changes to Electron APIs will now be detailed in the docs.


Hi 👋, I'm Peter, the 2024 Google Summer of Code (GSoC) contributor to Electron.

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.

Verano del Código de Google 2024

· 4 lectura mínima

¡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.

Para obtener más detalles del programa, consulta la página de inicio de Summer of Code.

Sobre nosotros

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:

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.

Antes de aplicar

Si no estás muy familiarizado con Electron, te recomendamos que comiences leyendo la documentación y probando ejemplos en Electron Fiddle.

Para obtener más información sobre la distribución de aplicaciones Electron también puede jugar con Electron Forge creando una aplicación de muestra:

npm init electron-app@latest my-app

Después de familiarizarte un poco con el código, ven a unirte a la conversación en el Servidor de Discord de Electron.

info

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.

Elaborando su propuesta

¿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).

¿Preguntas?

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!

Recursos

Introducing electron/rfcs

· 3 lectura mínima

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.

¿Cómo funciona?

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.

Who can participate?

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

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:

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:

10 años de Electron 🎉

· 11 lectura mínima

El primer commit en el repositorio electron/electron fue el 13 de marzo de 20131.

Primer commit en electron/electron por @aroben

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. ❤️

¿Cómo hemos llegado hasta aquí?

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:

Gráfico de descargas semanales de Electron a lo largo del tiempo

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.

¿Qué aprendimos en el camino?

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.

info

Si quieres saber más, ¡echa un vistazo al repositorio electron/governance!

Comunidad

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?

Construyendo comunidades

  • 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.

¡Automatiza todas las cosas!

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.

Not Goma

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

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

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.

... y todos nuestros bots de GitHub

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!

¿Qué sigue?

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)!

Footnotes

  1. 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!

  2. 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.

Verano del Código de Google 2022

· 2 lectura mínima

¡El equipo de Electrón está encantado de anunciarles que por primera vez en este año estaremos en el Google Summer of Code!


¿Qué es Google Summer of Code?

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.

Para obtener más información, consulte Summer of Code.

¿Cómo me registro?

¿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!

Para ser seleccionado como colaborador de Electron para Google Summer of Code, deberá enviar una solicitud. Las solicitudes se abrirán el 4 de abril de 2022 y se cerrarán el 19 de abril de 2022. Puedes seguir las actualizaciones de Google: las directrices de aplicación de verano de código aquí.

¿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.

Aquí encontrará una guía detallada de lo que debe presentar como parte de su solicitud Electron.

También puedes leer la guía oficial de estudiantes/colaboradores de GSoC para obtener consejos importantes sobre cómo preparar tu propuesta.

Si quieres hablar sobre propuestas de proyectos o tienes alguna pregunta, ¡ven a nuestro canal de Discord #gsoc-general!

Referencias

Servidor Comunitario de Discord y Hacktoberfest

· 3 lectura mínima

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


Hacktoberfest and Discord banner

Lanzamiento de la comunidad de Electron en Discord

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

¿Por qué un nuevo servidor de 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.

Look out for issues tagged hacktoberfest across our various repositories, including the main electron/electron repository, the electron/electronjs.org website, electron/fiddle, and electron-userland/electron-forge!

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.

Stuck? 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. In case you missed it, here's the invite link again!

Google Season of Docs

· 3 lectura mínima

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?

Logo de Temporada de Documentos

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í!

Referencias

Programa de Retroalimentación de la Aplicación Electron

· 3 lectura mínima

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.


¿Quién puede unirse?

Nuestros criterios y expectativas para que las aplicaciones se unan a este programa incluyen los siguientes elementos:

  • Prueba tu aplicación durante el periodo beta durante más de 10.000 horas
  • Tener una persona de un solo punto que chequee semanalmente para discutir los errores de su aplicación Electron y bloqueadores de aplicaciones
  • Aceptas acatar el Código de Conducta de Electron
  • Está dispuesto a compartir la siguiente información listada en la siguiente pregunta

¿Qué información debe compartir mi aplicación Electron?

  • Total de horas de funcionamiento de su aplicación con cualquier versión beta
  • Versión de Electron con la que está probando su aplicación (por ejemplo, 4.0.0-beta.3)
  • Cualquier error que impida que su aplicación de actualizar a la línea de publicación sea probado

Usuario / Horas

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

¿Por qué debería unirse mi aplicación Electron?

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.

Registrarse

Actualmente estamos aceptando un número limitado de registros. Si está interesado y puede cumplir con los requisitos anteriores, por favor rellene este formulario.

Proyecto de la semana: Jasper

· 5 lectura mínima

Esta semana hemos entrevistado al creador de Jasper, una herramienta basada en Electron para administrar las notificaciones de GitHub.


¡Hola! ¿Quién eres?

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

¿Qué es Jasper?

Jasper es un lector de problemas flexible y potente para GitHub. It supports issues and pull requests on github.com and GitHub Enterprise.

Jasper App Screenshot

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".

Jasper Start Screen

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

Jasper Start Screen 2

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

Jasper Start Screen 3

What can we do with streams?

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

Users and Teams

StreamProblemas
mentions:cat mentions:dogIssues that mention user cat or dog
author:cat author:dogIssues created by user cat or dog
assignee:cat assignee:dogIssues assigned to cat or dog
commenter:cat commenter:dogIssues that cat or dog commented on
involves:cat involves:dogIssues that "involve" cat or bob
team:animal/white-cat team:animal/black-dogIssues that animal/white-cat or animal/black-dog are mentioned in

involves means mention, author, assignee or commenter

Repositories and Organizations

StreamProblemas
repo:cat/jump repo:dog/runIssues in cat/jump or dog/run
org:electron user:cat user:dogIssues in electron, cat or dog

org is same as user

Atributos

StreamProblemas
repo:cat/jump milestone:v1.0.0 milestone:v1.0.1Issues that are attached to v1.0.0 or v1.0.1 in cat/jump
repo:cat/jump label:bug label:blockerIssues that are attached bug and blocker in cat/jump
electron OR atomshellIssues that include electron or atomshell

Review Status

StreamProblemas
is:pr review:requiredIssues that are required review in cat/jump
is:pr review-requested:catIssues that are requested review by cat.
But these are not reviewed yet.
is:pr reviewed-by:catIssues 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.

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. 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.

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.

Project of the Week: WebTorrent

· 9 lectura mínima

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.


What is WebTorrent?

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.

webtorrent homepage

Why is this cool?

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.

Where does Electron come into the picture?

About one year ago, we decided to build WebTorrent Desktop, a version of WebTorrent that runs as a desktop app.

WebTorrent Desktop player window

We created WebTorrent Desktop for three reasons:

  1. We wanted a clean, lightweight, ad-free, open source torrent app
  2. We wanted a torrent app with good streaming support
  3. 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.

webtorrent desktop logo

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?

gaia app screenshot

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.

brave logo

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?

WebTorrent Desktop main window

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.

¿Qué es lo que más le gusta de Electron?

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.)

¿En qué áreas debe mejorarse Electron?

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.

Watch here:

Slides here:

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.