メインコンテンツへ飛ぶ

"コミュニティ" タグの記事が 1 件の投稿 件あります

Community initiatives in Electron

全てのタグを表示

Google Summer of Code 2024

· 読むのにかかる時間 1 分

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:

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.

info

If this is your first time participating in Google Summer of Code or if you’re new to open source in general, we recommend reading Google’s Contributor Guide as a first step before engaging with the community.

Drafting your proposal

Interested in collaborating with Electron? First, check out the seven project idea drafts that we have prepared. 掲載されているアイデアは、すべて企画のために現在公開中のものです。

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.

応募には以下のものがあるとよいでしょう。

  • Your proposal: a written document that describes in detail what you plan to achieve over the course of the summer.
  • 開発者としての経歴。 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.

info

Our 2022 Google Summer of Code intern, @aryanshridhar, did an amazing job! If you want to see what Aryan worked on during his summer with Electron, you can read his report in the 2022 GSoC program archives.

質問?

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!

リソース

Introducing electron/rfcs

· 読むのにかかる時間 1 分

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.

どのように動作するのですか?

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 年目の Electron 🎉

· 読むのにかかる時間 1 分

electron/electron リポジトリへの最初のコミットは 2013 年 3 月 13 日でした1

electron/electron での @aroben による最初のコミット

その後、10 年の��月と 1192 人の貢献者による 27,147 以上のコミットを経て、今日 Electron はデスクトップアプリケーションを構築する最も人気のフレームワークの 1 つとなっています。 この節目は、これまでの歩みを祝って振り返り、その過程で学んだことを共有する絶好の機会です。

今があるのは、このプロジェクトへ貢献しようと時間に労力を捧げてくださった皆さまのおかげです。 ソースコードのコミットは最も目立つ貢献ですが、バグ報告、ユーザーランドモジュールのメンテナンス、ドキュメントや翻訳の提供、サイバースペースでの Electron コミュニティへの参加など、人々のそういった努力も認めなければなりません。 すべての貢献は私たちメンテナーにとってかけがえのないものです。

記事の続きの前に一言、御礼申し上げます。 ❤️

ここまでどうやって到達できたのでしょうか?

Atom Shell は、2014 年 4 月にパブリックベータを開始した GitHub の Atom エディタ の基盤として作られました。 当時利用可能だったウェブベースのデスクトップフレームワーク (node-webkit や Chromium Embedded Framework) に代わるものとして、ゼロから構築されたものです。 驚くべき機能としては、Node.js と Chromium を組み込むことでウェブ技術向けの強力なデスクトップランタイムを提供していました。

1 年も経たないうちに、Atom Shell の性能と人気は絶大なものになりました。 大企業、スタートアップ、そして個人開発者たちがこぞって Electron でアプリを作り始め (初期の採用企業は SlackGitKrakenWebTorrent など)、このプロジェクトは Electron という適切な名前に変更されました。

それ以来、Electron は本格的に活動してきました。 週間ダウンロード数の変化は、こちらの npmtrends.com のご好意によってご覧いただけます。

Electron の週間ダウンロード数の時間変化のグラフ

Electron v1 は 2016 年にリリースされ、API の安定性の向上とドキュメントやツールの充実を約束しました。 2018 年にリリースされた Electron v2 は、セマンティックバージョニングを導入し、Electron の開発者がリリースサイクルを把握しやすくなりました。

Electron v6 では、Chromium と同じ 12 週間の定期メジャーリリースケジュールに移行しました。 この決定はプロジェクトの考え方において「Chromium のバージョンを最新にする」ということを必須事項から優先事項に変えました。 これによりアップグレード間の技術的負債が減り、Electron の更新と堅牢性の維持が容易になりました。

それ以来、Electron の新バージョンを Chromium の安定版と同じ日にリリースするという、よくできた仕組みになっています。 2021 年に Chromium がリリーススケジュールを 4 週間に早めた時には、私たちは肩をすくめて、それに合わせてリリースケーデンスを8週間に増やすことにしました。

Electron は現在 v23 であり (そしてこれからも増え続ける)、クロスプラットフォームのデスクトップアプリケーションを構築するための最高のランタイムを構築することに専念しています。 近年、JavaScript の開発ツールがブームになっていますが、Electron はデスクトップアプリケーションのフレームワークとして、安定しており実戦投入され頑丈であり続けています。 Electron アプリは今やどこにでもあります。Visual Studio Code でプログラミング、Figma でデザイン、Slack でコミュニケーション、Notion でメモ (他にも多くの使用例があります)。 私たちはこの業績を非常に誇りに思うと同時に、助力して頂いたすべての人に感謝しています。

この過程で何を学んだのでしょうか?

10 年という節目を迎えるまでの道のりは、長いものでした。 ここでは、持続可能な大規模オープンソースプロジェクトの運営に役立った主なものを紹介します。

ガバナンスモデルで分散された意思決定をスケールする

Electron が爆発的に普及した後、私たちの克服すべき課題はプロジェクトの長期的な方向性をどうするかでした。 会社や国、タイムゾーンを越えて分散している数十人のエンジニアのチームを、どのように指揮すればよいのでしょうか。

初期の頃、Electron のメンテナーグループはインフォーマルな調整に頼っていました。小規模なプロジェクトでは高速かつ軽量ですが、より広範な協働作業にはスケールしません。 2019 年には、異なるワーキンググループがフォーマルな責任領域を担うガバナンスモデルに移行しました。 これは、プロセスを効率化し、プロジェクトの所有権の一部を特定のメンテナーに割り当てるのに役立っています。 それぞれのワーキンググループ (WG) は、今日ではどのような役割を担っているのでしょうか?

  • Electron のリリースの広報 (Releases WG)
  • Chromium と Node.js のアップグレード (Upgrades WG)
  • 公開 API のデザインの管理 (API WG)
  • Electron の堅牢性の維持 (Security WG)
  • ウェブサイトの運営、ドキュメント化、ツール作成 (Ecosystem WG)
  • コミュニティと企業への働きかけ (Outreach WG)
  • コミュニティのモデレーション (Community & Safety WG)
  • ビルドインフラ、メンテナーのツール、クラウドサービスの維持管理 (Infrastructure WG)

ガバナンスモデルに移行したのと同じ頃、Electron の所有権も GitHub から OpenJS Foundation に 移行しました。 元々のコアチームは現在もMicrosoftで働いていますが、彼らはElectronの管理体制を形成する、より大きな協力者のグループの一部に過ぎません。2

このモデルは完璧ではありませんが、世界的パンデミックやマクロ経済の逆風が続く中で、私たちによく適していました。 今後は、Electron を次の 10 年に繋げるために、ガバナンス憲章を改訂していく予定です。

info

詳しく知りたい方は、electron/governance リポジトリをご確認ください!

コミュニティ

オープンソースにおけるコミュニティの分野は難しいです。アウトリーチのチームが「コミュニティマネージャー」と書かれたトレンチコートを着た十数人のエンジニアである場合は特に難しくなります。 とはいえ、大規模なオープンソースプロジェクトであるということは、多くのユーザーを抱えているということであり、彼らの Electron に対するエネルギーを活用してユーザーランドのエコシステムを構築することは、プロジェクトの健全性を維持する上で極めて重要な要素です。

コミュニティの活気を高めるために、どのようなことを行ってきたのでしょうか。

バーチャルコミュニティの構築

  • 2020 年に、コミュニティ Discord サーバーを立ち上げました。 以前は Atom のフォーラム欄がありましたが、よりインフォーマルなメッセージングプラットフォームを用意し、メンテナと Electron 開発者間の議論や一般的なデバッグのヘルプのためのスペースを用意することにしました。
  • 2021 年には、@BlackHole1 の協力で Electon China というユーザーグループを設立しました。 このグループは、Electron の英語スペースの外でアイデアを出し合ったり Electron について議論したりする場を提供し、中国の活気ある技術市場からのユーザー増加に貢献しています。 また、npm の中国語ミラーである cnpm で Electron のナイトリーのリリースをサポートして頂いたことにも感謝します。

注目度の高いオープンソースプログラムへの参加

  • 2019 年から毎年、Hacktoberfest に参加しています。 Hacktoberfest は、DigitalOcean が毎年開催しているオープンソースの祭典で、オープンソースソフトウェアに自分の足跡を残そうとする熱心な貢献者が毎年何十人も集まっています。
  • 2020 年には、Google Season of Docs の初期のイテレーションに参加し、@bandantonio の協力の下で Electron の新しいユーザーチュートリアルのフローを作り直しました。
  • 2022 年には、初めて Google Summer of Code の学生のメンターをしました。 @aryanshridhar は、Electron Fiddle のコアのバージョン読み込みロジックをリファクタリングし、そのバンドラを webpack に移行する、素晴らしい働きをしてくださいました。

あらゆるものの自動化!

現在、Electron のガバナンスには約 30 人のアクティブなメンテナがいます。 フルタイムで貢献している人は半分以下なので、あれもこれもと仕事が多いことになります。 すべてを円滑に進めるコツは何でしょうか? 私たちのモットーは、コンピュータは安い、人の時間は高い、です。 典型的なエンジニアの活動において、より活動を快適にするための自動化サポートツール群を開発しました。

Not Goma

Electron のコアとなるコードベースは巨大な C++ コードの塊であり、そのビルド時間はバグ修正や新機能をいかに早く送り出せるかの制限要因となっていました。 2020 年には、Google の分散コンパイラサービス Goma の Electron 専用カスタムバックエンドである Not Goma をデプロイしています。 Not Goma は、認可されたユーザーのマシンからのコンパイル要求を処理し、バックエンドの数百のコアに処理を分散させます。 また、コンパイル結果をキャッシュしておくことで、同じファイルをコンパイルする他の人はそのコンパイル済み結果をダウンロードするだけでよくなります。

Not Goma の立ち上げ以降、メンテナのコンパイル時間が数���間の規模から数分に短縮されました。 安定したインターネット接続さえあれば、Electron をコンパイルできるようになりました!

info

オープンソース貢献者の方は、Electron Build Tools にてデフォルトで利用できる Not Goma の読み取り専用キャッシュをお試しいただけます。

Continuous Factor Authentication

Continuous Factor Authentication (CFA) は npm の二要素認証 (2FA) システムの自動化レイヤーで、semantic-release と組み合わせて様々な @electron/ npm パッケージの安全な自動リリースを管理します。

semantic-release でも npm パッケージの公開プロセスは自動できますが、これだけでは二要素認証をオフにするか制限を回避するシークレットトークンを渡す必要があります。

私たちは npm の 2FA の時間ベースのワンタイムパスワード (TOTP) を任意の CI ジョブに配信する CFA を構築し、二要素認証の追加セキュリティを維持しながら semantic-release の自動化を活用できるようにしました。

これには Slack での統合フロントエンドを備えた CFA を使用しています。これによりメンテナは、TOTP ジェネレータが手元にあれば Slack のあるどのデバイスからでもパッケージの公開を検証できます。

info

自分のプロジェクトで CFA を試してみたい方は、その GitHub リポジトリドキュメント をご確認ください。 CI プロバイダとして CircleCI をご利用の場合、CFA を使ったプロジェクトの基盤を素早く組むための 便利なオーブ も用意されています。

Sheriff

Sheriff は、GitHub、Slack、Google Workspace 全体での権限管理を自動化するために私たちが書いたオープンソースのツールです。

Sheriff の重要な価値提案は、権限管理は透明性のあるプロセスであるべきだということです。 これは上記のすべてのサービスにまたがって権限を指定するために、単一の YAML 設定ファイルを使用します。 Sheriff を使えば、PR を承認してマージするのと同じくらい簡単に、レポジトリのコラボレーターの状況を取得したり、新しいメーリングリストを作成したりできます。

Sheriff には Slack に投稿される監査ログもあり、Electron の組織内のどこかで不審な動きがあったときに管理者へ警告できます。

…そしてすべての GitHub ボット

GitHub は豊富な API 拡張性を持つプラットフォームであり、Probot というファーストパーティのボットアプリケーションフレームワークを提供しています。 私たちがより創造的な仕事に集中できるよう、私たちの代わりに単純作業をこなしてくれる小さいボット群を構築しています。 以下にいくつかの例を示します。

  • Sudowoodo は Electron のリリースプロセスの最初から最後まで、ビルドのキックオフから GitHub と npm へのリリースアセットのアップロードまでを自動化します。
  • Trop は、GitHub の PR ラベルに基づいて以前のリリースブランチへのパッチの cherry-pick を試みることで、Electron のバックポートプロセスを自動化します。
  • Roller は、Electron の Chromium と Node.js の依存関係のローリングアップグレードを自動化します。
  • Cation は、electron/electron の PR のステータスを確認するボットです。

このような小さなボット家族のおかげで、開発者の生産性が大幅に向上しました!

今後の予定は?

プロジェクトとして次の 10 年を迎えるにあたって、疑問に思われることでしょう。Electron はこれからどうなるのでしょうか?

私たちは、Chromium のリリースケイデンスに同期して 8 週間ごとに Electron の新しいメジャーバージョンをリリースし、エンタープライズ級のアプリケーションの安定性と堅牢性を維持しながら、ウェブプラットフォームと Node.js による最新で最高のフレームワークを保ち続けます。

今後の取り組みについては基本的に、具体的になった時点でお知らせします。 今後のリリース、機能、一般的なプロジェクトの更新について知りたい方は、ブログ をご覧頂くか、ソーシャルメディアのプロフィール (TwitterMastodon) をフォローしてください!

Footnotes

  1. これは実際には、2017 年に Electron に吸収されて git 履歴がマージされたelectron-archive/brightray プロジェクト での最初のコミットです。 でも細かいことはいいでしょう? 誕生日ですから、ルールはこちらで決めちゃいました!

  2. 一般に信じられていることとは異なり、なんとElectronはGitHubやMicrosoftの所有ではなく、OpenJS Foundationの一部となっています。

Google Summer of Code 2022

· 読むのにかかる時間 1 分

Electron チームは、今年初めて Google Summer of Code に参加することをお知らせします!


Google Summer of Code とは何ですか?

Google Summer of Code (GSoC) は、オープンソースソフトウェアプロジェクトと潜在的な貢献者をつなぐ、年に一回のメンタリングプログラムです。 以前は学生だけでしたが、現在は 18 歳以上であれば誰でも GSoC に登録できます。

詳しい情報については Summer of Code のホームページ をご確認ください。

登録方法は何ですか?

Electron との共同開発に興味はありますか? オープンソースのコントリビューターを始めたばかり方や初心者であれば、ぜひご応募ください!

Google Summer of Code の Electron コントリビューターとして選ばれるためには、ご応募していただく必要があります。 応募開始は 2022 年 4 月 4 日、締め切りは 2022 年 4 月 19 日 となります。 Google Summer of Code の応募要項はこちらで更新しています

応募をご希望ですか? まずは、私たちがご用意した 5 つのプロジェクトアイデア案 をご覧ください。 掲載されているアイデアは、すべて企画のために現在公開中のものです。 また、企画プロジェクトのリストにない新規アイデアも受け付けています。

応募には以下のものがあるとよいでしょう。

  • 企画書。この夏のプログラムの間に達成する目標の計画を詳細に記した文書です。
  • 開発者としての経歴。 レジュメをお持ちの方はコピーを添付してください。または、関連する技術的な経験を中心に、これまでの経験をお聞かせください。

Electron への応募にかかる提出物の詳細は、こちらをご覧ください。

また GSoC 学生/コントリビューター公式ガイド には、企画書を作成する際の重要なヒントが記載されていますので、ぜひご覧ください。

プロジェクトの企画について議論したい方や質問がある方は、#gsoc-general Discord チャンネル にぜひいらしてください!

リファレンス

コミュニティDiscordサーバーとHacktoberfest

· 読むのにかかる時間 1 分

コミュニティの絆とオープンソースの1ヶ月間のお祝いのために私たちに参加してください。


Hacktoberfest と Discord のバナー

Electron コミュニティの Discord の立ち上げ

Electronの Outreach ワーキンググループ は、 公式コミュニティ Discord サーバーの立ち上げを発表することを楽しみにしています!

なぜ新しいDiscordサーバーなのか?

Atom テキスト エディタののバックボーンとして、Electron フレームワークに関するコミュニティでのディスカッションは、Atom の Slack ワークスペースの1チャネルで行われていました。 時間が経ち、2つのプロジェクトが分離していくにつれて、AtomワークスペースとElectronプロジェクトとの関連性は低下し、Slackチャンネルへのメンテナンの参加者も同様に低下しました。

これまで、招待を受け取るのに苦労したと多く人からの報告を受けました。コアメンテナンス担当者のほとんどがチャンネルを頻繁に行なっていたにもかかわらず、より広範なコミュニティをAtom Slackワークスペースにリダイレクトしていました。

この新しいサーバーは、Electron に関する最新情報を得ることができる、コミュニティの中心的な議論の場となるようにしています。

ぜひお越しください!

今のところ、サーバーのメンバーシップは数人のメンターが協力して立ち上げていますが、皆さんとお話しできることをとても楽しみにしています。 助けを求めたり、Electron の最新情報を得たり、他の開発者と交流したりできます。 サーバーにアクセスできる便利な 招待リンク をご用意しました!

Hacktoberfest 2020

大規模で長期間実行されているオープンソースプロジェクトとして、Electronはコミュニティからの貢献なしにはほとんど成功しませんでした。 コードの提出からバグレポート、ドキュメントの変更まで様々です。 だからこそ、Hacktoberfest に参加することで、あらゆるスキルレベルの開発者たちがより広いコミュニティでプロジェクトに参加できるようになることが重要だと考えています。

寄せ集め物

今年は、あなたにすべてを与えるより広いプロジェクトを持っていません。しかし、Electron JavaScript エコシステム全体に貢献する機会に焦点を当てたいと思います。

私達のさまざまリポジトリで hacktoberfest のタグのある課題をみてください。メインの electron/electron リポジトリ、electron/electronjs.org ウェブサイト、electron/fiddle、それに electron-userland/electron-forgeもあります。

P.S. 特に冒険したい方向けに、help wanted タグが付けられた Issue のバックログも用意しています。

つまづきましたか? 一緒にチャットしてみましょう!

さらに、私たちの Discord サーバーのグランドオープンが、今年最大のオープンソースソフトウェアの祭典と重なったのも偶然ではありません。 Hacktoberfest の PR に協力してもらうためにも、#hacktoberfest チャンネルをチェックしてみましょう。 見逃した方のために、招待リンクをこちらに再びご用意しました!

Google Season of Docs

· 読むのにかかる時間 1 分

Google Season of Docs 第 2 段に参加させていただき、Electron としては大変光栄です。このイニシアティブでは、オープンソース組織のメンターとテクニカルライターがペアを組み、プロジェクトのドキュメントを改善していきます。


Season of Docs とは何ですか?

Season of Docs ロゴ

Season of Docs は、テクニカルライターとオープンソースコミュニティのコラボレーションを促進し、両者の利益に貢献するプログラムです。 オープンソースのメンテナーは、ライターのテクニカルライティングの専門知識を活用して、ドキュメントの構造と内容を改善します。テクニカルライターは、指導者の指導のもとオープンソースのコミュニティへ派遣されます。 詳細は Google の Season of Docs ウェブサイト で解説しています。

このプログラムに初めて参加した弊社では、テクニカルライター 1 名をメンターとして迎え、Electron の エコシステム作業グループ と協力しドキュメントの大部分を再構築していきます。 プロジェクト全体のタイムラインについては、こちら をご覧ください。

登録方法は何ですか?

テクニカルライターとして弊社とのコラボレーションに興味がございますか? まずは、今年のプログラムのために Google の テクニカルライターガイド を把握し、用意した 2 つの プロジェクトのアイデア草稿 をご確認ください。

Season of Docs のテクニカルライターとして採用されるには、6 月 8 日から 7 月 9 日までの期間中に Google Season of Docs のウェブサイトから応募する必要があります。

応募書類には、3 ヶ月間 Electron ドキュメントで何を成し遂げようとしているのかを詳細に記述した提案書を添付してください。 この提案書は、プロジェクトのアイデア草稿に記載した出発点のいずれかを発展させた内容か、全く新しいものにして頂いて構いません。 どこから手を付ければいいのかわかりませんか? 昨年の 受理された提案書のリスト を閲覧して、知見を得ることもできますよ。

提案書とは別に、テクニカルライターとしての経歴も審査されます。 履歴書には、テクニカルライティングのサンプル (既存のドキュメント、チュートリアル、ブログ記事など) と、加えて関連するライティング経験を強調したコピーを添付してください。

プロジェクトの提案を議論したい場合は、season-of-docs@electronjs.org までメールでお問い合わせください。そこからお話しましょう!

リファレンス

Electron アプリフィードバックプログラム

· 読むのにかかる時間 1 分

Electron はリリースサイクルが高速かつより安定するように取り組んでいます。 実現のため、大規模 Electron アプリのためのアプリフィードバックプログラムを始めました。ベータリリースをテストしてアプリ固有の問題を報告できます。 これは、できるだけ早くアプリケーションを次の安定リリースへアップグレードする、その作業の優先順位付けに役立ちます。

編集(2020-05-21):このプログラムは引退しました。


どんなアプリが参加できますか?

このプログラムに参加するアプリの基準と要件は、以下の項目の���りです。

  • ベータ期間中に 10,000 ユーザー時間以上アプリをテストすること
  • アプリにおける Electron のバグと障害について議論する手続きを毎週行う担当者を 1 人配置すること
  • Electron の 行動規範 の遵守に同意すること
  • 以下の質問に列挙されている下記情報を共有すること

Electron アプリが共有しなければならない情報は何ですか?

  • ベータリリースで実行されたアプリの総ユーザー時間
  • アプリがテストしている Electron のバージョン (4.0.0-beta.3 など)
  • ベータテストされているリリースラインでアプリケーションのアップグレードを妨げるようなバグ

ユーザー時間

すべてが正確なユーザー数を共有できるわけではないことは理解していますが、より良いデータは特定リリースの安定性の判断に役立ちます。 現在、アプリのテストはベータサイクルを通じて 10,000 ユーザー時間まで到達するようにお願いしています。

  • 10 ユーザー時間は、10 人が 1 時間テストする、もしくは 1 人が 10 時間テストするということです。
  • 3.0.0-beta.2 で 5,000 ユーザー時間をテストしてから、3.0.0-beta.5 で 5,000 ユーザー時間をテストする、というようにベータリリース間でテストを分割できます。 多ければ多いほど良いのですが、アプリケーションによっては全ベータリリースをテストできません。
  • CI や QA 時間は合計にカウントされませんが、内部リリースはカウントされます。

私の Electron アプリも参加するべきですか?

あなたのアプリのバグは追跡され、コア Electron チームのレーダーに記録されます。 あなたのフィードバックが、新しいベータ版の動作確認、必要な作業の確認などで Electron チームの役に立ちます。

私のアプリケーションの情報は公開されますか? この情報を見られるのは誰ですか?

いいえ、アプリケーションの情報は一般公開されません。 情報は、アプリフィードバックプログラムと Electron ガバナンス のメンバーのみが閲覧できるプライベート GitHub リポジトリに保管されます。 メンバーは全員 Electron の 行動規範 の遵守に同意しています。

新規申込

現在、新規申込の 数を限定 しています。 もし興味があり、上記の要件を満しているならば、この フォーム に記入してください。

今週のプロジェクト: Jasper

· 読むのにかかる時間 1 分

今週は GitHub 通知を管理する Electron ベースのツール、Jasper の作者にインタビューを伺いました。


こんにちは! あなたは誰ですか?

私は Ryo Maruyama で日本のソフトウェア開発者です。 JasperESDoc を開発しています。

Jasper とは何ですか?

Jasper は GitHub 向けの柔軟で強力な Issue リーダーです。 github.com や GitHub Enterprise での Issue やプルリクエストに対応しています。

Jasper アプリスクリーンショット

どうしてこのアプリを制作したのですか?

仕事や OSS の活動で GitHub を使っている人は、毎日のように大量の通知が届く傾向にあります。 通知を受け取る方法として、GitHub ではメールと ウェブ通知 を提供しています。 これらは数年前から使用していましたが、以下のような問題に直面しました。

  • メンションされた、コメントした、監視している Issue を見落としがちである。
  • 後で確認しようと Issue を頭の片隅に置いても、たまに忘れてしまうことがある。
  • Issue を忘れないために、ブラウザでタブがたくさん開いたままになる。
  • 自分に関係する Issue なのかどうかを全て確認するのは難しい。
  • 自分のチームの活動を全て把握しづらい。

こういった問題の対処に時間と労力を費やしていました。そこで効率的に解決するために GitHub 用の Issue リーダーを作ってみようと思い、Jasper の開発を始めました。

どういった人が Jasper を使用していますか?

Jasper は、GitHub を利用する企業の開発者、デザイナー、マネージャーに利用されています。 もちろん、OSS 開発者の中にも使っている人がいます。 さらに GitHub の人も使っています!

Jasper はどのような仕組みですか?

Jasper の設定を終えると、以下の画面が表示されます。 左から順に、"ストリームリスト"、"Issue リスト"、"Issue 本文" が表示されます。

Jasper 起動画面

この "ストリーム" は、Jasper の核となる機能です。 例えば、"eceltron/electron リポジトリの @zeke にアサインされた Issue" を見たい場合は、以下のようなストリームを作成します。

repo:electron/electron assignee:zeke is:issue

Jasper 起動画面 2

ストリームを作成して数秒待てば、条件を満たす Issue が表示されます。

Jasper 起動画面 3

ストリームではなにができますか?

ストリームにはどのような条件が使えるのかご紹介します。

ユーザとチーム

ストリームIssues
mentions:cat mentions:dogcatdog のユーザをメンションした Issue
author:cat author:dogcatdog が作成した Issue
assignee:cat assignee:dogcatdog がアサインされた Issue
commenter:cat commenter:dogcatdog がコメントした Issue
involves:cat involves:dogcatbob が "関わりのある" Issue
team:animal/white-cat team:animal/black-doganimal/white-catanimal/black-dog をメンションした Issue

involves というのは mentionauthorassigneecommenter のいずれかであるということです。

レポジトリと Organization

ストリームIssues
repo:cat/jump repo:dog/runcat/jumpdog/run 内での Issue
org:electron user:cat user:dogelectroncatdog 内での Issue

orguser は同じです

属性

ストリームIssues
repo:cat/jump milestone:v1.0.0 milestone:v1.0.1cat/jump 内で v1.0.0v1.0.1 に割り当てられた Issue
repo:cat/jump label:bug label:blockercat/jump 内で bug blocker を割り当てた Issue
electron OR atomshellelectronatomshell を含む Issue

レビュー状況

ストリームIssues
is:pr review:requiredcat/jump 内のレビューが必要な Issue
is:pr review-requested:catcat のレビューが必要な Issue。
まだレビューされていないものになります。
is:pr reviewed-by:catcat がレビューした Issue

これらを見てお気づきかもしれませんが、ストリームには GitHub の検索クエリが使えます。 ストリームや検索クエリの使い方については、以下の URL を参照してください。

Jasper には、未読 Issue 管理、未読コメント管理、お気に入り、更新の通知、Issue のフィルタリング、キーボードショートカットなどの機能もあります。

Jasper は有料製品ですか? おいくらですか?

Jasper は $12 です。 また、30 日間の 無料体験版 もあります。

Electron で Jasper を構築することにしたのはなぜですか?

Electron のこういったところが気に入っています。

  • JavaScript/CSS/HTML でアプリを開発できる。
  • Windows、Mac、Linux プラットフォーム向けに構築できる。
  • Electron は活発に開発されており大きなコミュニティがある。

これらの特長により、迅速にシンプルなデスクトップアプリケーションが開発できます。 素晴らしいことです! あなたもプロダクトのアイデアがあれば、是非 Electron の利用を検討してみてください。

Jasper 開発の際に直面した課題はありますか?

"ストリーム" の概念を考え出すところで苦労しました。 最初は GitHub の Notifications API を使おうと考えました。 しかし、特定のユースケースに対応していないと気づきました。 その後 Notification API に加えて、Issues APIPull Requests API の利用も検討しました。 それでも、望んでいたものにはなりませんでした。 そこで、いろいろな方法を考えていくうちに、GitHub のSearch API をポーリングするのが最も柔軟だと気づきました。 ここまでに約 1 ヶ月の実験期間を要しましたが、その後 2 日でストリームの概念を取り入れた Jasper のプロトタイプを実装しました。

注: ポーリングは最大で 10 秒に 1 回までとなっています。 GitHub API の制限からすれば余裕を持たせてあります。

今後の予定は何ですか?

今後は以下のような機能を開発予定です。

  • フィルタ付きストリーム: ストリーム内の Issue をフィルタリングするような、フィルタを付けたストリームです。 SQL のビューのようなものです。
  • 複数アカウント: github.com と GHE の両方を利用できるようにします。
  • パフォーマンス改善: 今のところ WebView での Issue 読み込みは通常のブラウザよりも遅くなっています。

更新情報は @jasperappio の Twitter を確認してください。

今週のプロジェクト: WebTorrent

· 読むのにかかる時間 1 分

今週は @feross@dcposch が WebTorrent についてお話しします。WebTorrent は、ユーザーをつなぎ合わせて分配された分散型ブラウザ間ネットワークを形成する、ウェブベースのトレントクライアントです。


WebTorrent とは?

WebTorrent は、ブラウザーで動く初のトレントクライアントです。 全て JavaScript で書かれており、P2P 転送に WebRTC を使用できます。 ブラウザのプラグイン、拡張機能、インストールは不要です。

公開のウェブ標準を使用して、WebTorrent はウェブサイトのユーザーを結び付け、効率的なファイル転送のために分配された分散型ブラウザ間ネットワークを形成します。

WebTorrent の実際のデモは webtorrent.io で見ることができます。

webtorrent ホームページ

これが凄いと言われるのはなぜですか?

YouTube のようだけれども、訪問者がサイトコンテンツのホストを助けるビデオサイトを想像してください。 WebTorrent で強化されたウェブサイトは、利用者が多いほどより高速で強靭になります。

ブラウザ間通信は仲介者を排除し、人々が各々の条件で通信できます。 クライアント/サーバーは不要です。ピアのネットワークがあれば、みな平等です。 WebTorrent は、ウェブを再分散化する道程の初めの一歩です。

Electron はどこに登場するのですか?

約 1 年前、デスクトップアプリ版 WebTorrent である WebTorrent デスクトップ を作成することにしました。

WebTorrent デスクトッププレイヤーウインドウ

私たちは、以下の 3 つの理由の下に WebTorrent デスクトップを作りました。

  1. 簡潔、軽量、広告なしのオープンソーストレントアプリが欲しい
  2. 優良なストリーミングサポート付きトレントアプリが欲しい
  3. BitTorrent と WebTorrent ネットワークを繋ぐ "ハイブリッドクライアント" が欲しい

トレントは既にウェブブラウザでダウンロードできるのに、なぜデスクトップアプリなのですか?

初めに、WebTorrent 設計の背景を少しだけお話しましょう。

webtorrent デスクトップロゴ

黎明期の頃、BitTorrent は TCP を転送プロトコルとして使用していました。 その後、TCP よりも優れた性能と更なるメリットを持った uTP が登場しました。 すべての上流トレントクライアントは最終的に uTP を採用し、現在はどちらのプロトコルでも BitTorrent を使用できます。 WebRTC プロトコルは次の必然的な段階です。 すべてのデスクトップ BitTorrent クライアントと数百万のウェブブラウザで構成される 1 つの巨大な P2P ネットワーク — これはウェブブラウザとの相互運用性を保証します。

"ウェブピア" (ウェブブラウザで実行されるトレントピア) は、数百万の新しいピアを追加し、BitTorrent を多数の新しいユースケースに広めることで、BitTorrent ネットワークを強化します。 WebTorrent は、既存の BitTorrent クライアントが WebTorrent サポートを簡単に追加できるように、できるだけ BitTorrent 仕様に準拠しています。

Vuze の��うな一部のトレントアプリはウェブピアを既にサポートしていますが、他のアプリのサポート追加を待ちたくはありませんでした。 **元来、WebTorrent デスクトップは WebTorrent プロトコルの採用を促進する手段でした。**誰もが使いたくなるような素晴らしいトレントアプリを作成することで、ウェブピア (ウェブサイト上のユーザなど) とトレントを共有できるネットワーク内のピア数を増やすのです。

あまり知られていないような、興味深いトレントの用法はありますか?

WebTorrent の一番すごい用法というと、ピアアシスト配信でしょう。 Wikipediaインターネットアーカイブ などの非営利プロジェクトは、訪問者にリソースを提供してもらうことで帯域幅とホスティングコストを削減できます。 人気コンテンツは、ブラウザ間で迅速かつ安価に提供できます。 たまにしかアクセスされないコンテンツは、オリジンサーバーから HTTP 経由で確実に提供できます。

インターネットアーカイブはトレントファイルを実際に既に更新しているため、WebTorrent でうまく動作します。 なので、サイトにインターネットアーカイブのコンテンツを埋め込みたい場合でも、トレントでアーカイブのホスティングコストを削減し、アーカイブ側は実際にウェブをアーカイブすることに資金を注げます。

CDN から P2P を介したアプリ配信といった、面白いビジネスユースケースもあります。

WebTorrent を使うお気に入りのプロジェクトはありますか?

gaia アプリスクリーンショット

WebTorrent で作られた一番すごいものといえば、間違いなく、Gaia 3D Star Map でしょう。 これは、ぬるぬる動く天の川の 3D インタラクティブシミュレーションです。 データはトレントから直接ブラウザに読み込まれます。 銀河系を飛び回り、私たち人間が宇宙の広大さに比べてどれだけ小さいかを実感すると同時に畏敬の念を抱きます。

この作成方法は、著者の Charlie Hoey が WebGL と WebTorrent で天体図を作成した方法を説明しているブログ記事 Torrenting The Galaxy で読むことができます。

brave ロゴ

また、私たちは Brave の大ファンです。 Brave は、広告とトラッカーを自動的にブロックして、ウェブをより高速で安全にするブラウザです。 最近、Brave はトレントサポートを追加しました。そのため、従来のトレントを外部アプリなしで閲覧 できます。 この機能は WebTorrent で動作しています。

そのため、ほとんどのブラウザーが PDF ファイルを描画できるように、Brave はマグネットリンクとトレントファイルを描画できます。 これらは、ブラウザがネイティブでサポートするただの別種のコンテンツです。

なんと、Brave の共同創設者の 1 人は、WebTorrent の作成に使われた言語 JavaScript の作成者 Brendan Eich です。その Brave が WebTorrent 統合を選んだなんてとてもカッコよくないですか?

Electron で WebTorrent デスクトップを構築することにしたのはなぜですか?

WebTorrent デスクトップメインウインドウ

Electron アプリはすべてのアプリに Chrome コンテンツモジュール全体を含むため、"肥大化" していると言われています。 これは、場合によっては部分的に当てはまります (Electron アプリインストーラーは通常 ~40MB ですが、OS 固有のアプリインストーラーでは通常 ~20MB)。

しかし、WebTorrent デスクトップの場合、Electron のほぼすべての機能を使用しますし、通常の操作では何十もの Chrome 機能を使用します。 プラットフォームごとにこれらの機能をゼロから実装していれば、アプリを構築するのに数ヶ月から数年かかるか、単一のプラットフォームでしかリリースできなかったでしょう。

アイデアを実現するため、Electron の Dock 統合 (ダウンロード進捗を表示)、メニューバー統合 (バックグラウンド実行)、プロトコルハンドラーの登録 (マグネットリンクを開く)、powerSaveBlocker (映像再生中のスリープ防止)、自動更新 といった機能を使用しました。 Chrome の機能については、<video> タグ (多種に渡る動画形式の再生)、<track> (字幕対応用)、ドラッグアンドドロップ対応、WebRTC (ネイティブアプリでの使用は難しい) など、色々と使用しています。

言うまでもなく、トレントエンジンは多くの Node API が存在することを前提とした JavaScript で記述されています。特に、require('net')require('dgram') によって TCP と UDP ソケットをサポートしています。

まとめると、Electron は私たちが必要としていたもので、堅牢で洗練されたアプリを記録的な速さで配信するために必要で正確な機能群を備えていました。

Electron の好きなところは何ですか?

WebTorrent ライブラリは、オープンソースサイドプロジェクトとして 2 年間開発中です。 **WebTorrent デスクトップは 4 週間で作成しました。**アプリを非常に迅速に構築して配信できたのは Electron であることが主な理由です。

jQuery を使用する世代のフロントエンドプログラマーを Node.js がサーバープログラミングに導いたのと同じで、Electron はウェブや Node.js の開発に精通している人なら誰でもネイティブアプリ開発に手を出せるようにします。 Electron は非常に強力です。

ウェブサイトとデスクトップクライアントはコードを共有していますか?

はい、webtorrent npm パッケージ は、Node.js、ブラウザ、Electron で動作します。 全く同じコードがすべての環境で実行できる — これが JavaScript の美です。 これが今日の万国共通の実行環境です。 Java Applets は "一度書けば、どこでも動く" アプリを約束しましたが、その理想は多くの理由で実際には実現しませんでした。 Electron は、他のどのプラットフォームよりも、本当にその理想に接近しています。

WebTorrent デスクトップ構築の際に直面した課題はありますか?

アプリの初期版では、UI パフォーマンスの向上に苦労しました。 メインアプリウィンドウを描画するレンダラープロセスと同じ所にトレントエンジンを配置していました。このため、予想どおり、トレントエンジンからの激しい CPU 演算 (ピアから受信したトレントピースの検証など) が発生した場合は常に低速になっていました。

これを修正するため、トレントエンジンを IPC を介して通信する 2 つ目の非表示のレンダラープロセスに移動しました。 こうすれば、そのプロセスが短時間に多くの CPU を使用する場合でも、UI スレッドは影響を受けません。 滑らかなスクロールとアニメーションには非常に満足です。

注釈: WebRTC (レンダラーでのみ使用可能) にアクセスする必要があるため、"メイン" プロセスではなく、レンダラープロセスにトレントエンジンを配置する必要がありました。

Electron はどういった領域で改善されるべきでしょうか?

本番用のアプリを構築して配信する方法や、特にコード署名や自動更新などのトリッキーなテーマについて、より良いドキュメントを望んでいます。 私たちは、ソースコードを研究して Twitter で尋ねてベストプラクティスについて学ぶ必要がありました!

WebTorrent デスクトップは開発終了ですか? それとも、今後何かありますか?

現行の WebTorrent デスクトップは素晴らしいと思いますが、改善の余地は常にあります。 現在、細かい点の修正、パフォーマンス、字幕サポート、映像コーデックサポートの改善に取り組んでいます。

プロジェクトの参加に興味がある場合は、私たちの GitHub ページ を見てください!

他の開発者に役立つ Electron 開発のノウハウはありますか?

WebTorrent デスクトップのコントリビューターの 1 人である Feross は、最近 NodeConf Argentina で "Electron の世界: JavaScript でクロスプラットフォームアプリを構築" という講演を行い、洗練された Electron アプリをリリースするための便利なヒントを紹介しました。 この講演は、あなたが基本的な実用アプリを持っている段階にいて、それを次のレベルの洗練と専門的な領域に昇華させようとしているのであれば非常に役立ちます。

動画はこちら:

スライドはこちら:

もう一人の WebTorrent のコントリビューターである DC は、アプリを洗練されたネイティブにするための できることのチェックリスト を書きました。 コード例が付いており、macOS Dock 統合、ドラッグアンドドロップ、デスクトップ通知、アプリの読み込みを速くするなどをカバーしています。

今週のプロジェクト: Voltra

· 読むのにかかる時間 1 分

今週は、Aprile Elcich さんと Paolo Fragomeni さんにお会いして、Electron を搭載した音楽プレイヤー Voltra についてお話を伺いました。


Voltra とは何ですか?

Voltra は、自分の音楽を所有したい人のための音楽プレイヤーです。 すでに持っているものから新しい音楽を見つけたり、購入したりできるストアでもあります。 広告なしで、デスクトップとモバイル向けのクロスプラットフォームです。 情報収集もしません。

voltra-artistview

Voltra はどんな人が対象ですか?

音楽を聴くすべての人です。

Voltra を作ったきっかけは何ですか?

ラジオは昔からリスナーの大きなシェアを獲得しています。 今や電波からインターネットへと移行しています。 オンデマンドで音楽をレンタルできるようにもなりました - ラジオの復活です! そのために多くの新しい製品やサービスが登場しています。しかし、ストリーミングラジオはまだ、音楽とその視聴手段を掌握されています。

私たちは、自分が持っている音楽というものに全面的にこだわったプロダクトを望みました。 アーティストやレーベルから直接、新しい音楽を発見したり購入したりすることを容易にするものです。

無料版はありますか?

デスクトッププレイヤーは完全に無料です。 あなたの音楽を販売するのも無料です! 当サイトに広告はありません。

このアプリは無料なので、後にオープンソース化するかもしれません。 今のところそれを管理する余裕はありません。 機能や採り入れる方向性についても、とても具体的なアイデアを持っています。 活発なベータコミュニティもあり、そのフィードバックを大切にしています。

どうやって収益化するのですか?

プレミアム機能があります!

Voltra Audio Archive は、音楽に特化したクラウドバックアップサービスです。 データブロックを圧縮、共有はしません。 あなたの音楽コレクションは、物理的なバックアップです。

アーティストやレーベル向けの プロ会員 は、アナリティクスやプロアーティストのウェブページなど、より関連する視聴者に届けるためのツールを提供しています。

Voltra は何が特色なのですか?

デザインとユーザビリティは、私たちにとって非常に重要です。 リスナーの皆様に、煩わせない視聴体験を提供したいのです! 興味深い音楽プレーヤーやストアはすでにいくつか出ています。 しかし、その多くは作者が思っているよりも高度で使いづらいのです。 一人でも多くの人が Voltra を利用できるようにしたいです。

また、アーティストやレーベルからの引き抜きはしていません。 これが差別化しているポイントです。 アーティストが自分の音楽を市場に出すための障壁を下げるには、本当に重要なことなのです。

どのようなデザイン & 技術的な決定をしましたか?

Voltra をデザインするにあたって、ネイティブアプリやウェブの UI の慣習を考慮し、何を削るかということもたくさん考えました。 私たちには、ここ数ヶ月の間で批判的なフィードバックをくれた活発なプライベートベータグループがいます。

人々は、アルバムアートや写真を本当に大切にしているということがわかりました。 多くのプレイヤーはファイルのリストでしかありません。 アルバムアートは物理アルバムを所有するにあたって格好いい所の一つですが、Voltra デスクトップアプリではこの点を強調したいと思いました。

voltra-albumview

他人のファイルに手を出さないようにも気をつけました。 ファイルを見るだけなので、それ自体は好きな場所に置くことができます。名前を変更したり、移動したりすることはありません。 プロセスが実行されていなくても新規ファイルを追跡できるように、見ているディレクトリの状態を追跡する埋め込みデータベースがあります。

Voltra 構築の際に直面した課題はありますか?

パフォーマンスを重視して、そこに時間をかけました。 最初はフレームワークから始めましたが、バニラ JavaScript に移行しました。 経験上、フレームワークが提供する一般的な抽象化は、導入することによるパフォーマンスの対価や儀式的な記述を上回ります。

現在はとても巨大なコレクションにも対応しています。 大きなコレクションであれば数万もの画像になるでしょう! Node.js のファイルシステムモジュールをレンダラープロセスから直接利用できるようにしたことで、DOM イベントに基づいた大量の画像の超高速での遅延ロード/アンロードが非常に簡単になりました。

一般的に、setImmediaterequestIdleCallback は、UI の応答性を維持しながら多くの処理を実行するにあたってとてつもなく重要な道具です。 具体的には、CPU に依存するタスクを別のプロセスに分散させることで、ユーザーインターフェースの応答性を保つことができます。 たとえば、実際のオーディオコンテキストを別のプロセスに移動し、ビジーな UI による潜在的な中断を IPC を介した通信で回避しました。

Electron で Voltra を構築することにしたのはなぜですか?

ブラウザのサンドボックスはとても制限されていますが、私たちはウェブプレイヤーも開発しています。 しかし、私たちはウェブプレイヤーも開発しています。 そのため、2 つの実装間でほぼ 100% のコードを共有できるのは大きな利点です。

実際には、Swift でネイティブアプリを構築するところから始めました。 一番の問題点は、多くの再発明をしていることでした。 ウェブには世界最大のオープンソースエコシステムがあります。 そこで、すぐに Electron に切り替えました。

最も重要なのは、Electron で一度開発すれば、すべての主要なプラットフォームで Just Work™ するということです。 保証はありませんが、各プラットフォームのためのネイティブコーディングのコストは、Electron を導入するコストを確実に上回っています。

Electron の好きなところは何ですか?

問題解決!: Node.js のネットワークスタックと Chromium のプレゼンテーション層が一緒になっていることこそが、問題解決の秘訣です。

適性: ウェブスタックだけなので、文字通りチーム全員が製品の構築に関われます。

コミュニティ: 高度に組織化されたコミュニティがあり、コミュニケーション手段が発達しています。 このようなサポートを受けながら開発を進められることはとても素晴らしいことです。

Electron はどういったところを改善できるでしょうか?

Electron に 1 つのパッケージャを推奨してもらいたいです。 Node にとってのパッケージマネージャーと同様に、Electron にとってもパッケージマネージャーは重要です。 ユーザーランドには複数のパッケージャーがあり、それぞれが興味深い機能を備えていますが、それぞれにもバグがあります。 コミュニティのコンセンサスが得られれば、貢献者が費やすエネルギーの方向性が定められるでしょう。

今後の予定は何ですか?

私たちは現在モバイルアプリを開発中で、アーティストやレーベルと協力して彼らの音楽を Voltra ショップに追加しています。 そこのあなた! アーティストやレーベルの方であれば、ぜひご登録ください! 目標の 1000 万曲を達成しましたら、ショップをオープンする予定です。