Electron API の履歴がドキュメント内で詳解されるようになります。
こんにちは 👋、2024 年 Google Summer of Code (GSoC) の Electron のコントリビューターの、Peter です。
GSoC プログラムの過程で、Electron ドキュメントとその関数、クラスなどに API の履歴の機能を実装しました。これは、Node.js ドキュメント と同様の方法で、API ドキュメントの Markdown ファイルにシンプルかつ強力な YAML スキーマを使用できるようにし、Electron ドキュメントのウェブサイトでわかりやすく表示することで実現しました。
Electron が第 20 回 Google Summer of Code (GSoC) 2024 のメンター組織として承認されたことをお知らせします! Google Summer of Code は、オープンソースソフトウェア開発に新たな貢献者を呼び込むことに重点を置いた国際プログラムです。
プログラムの詳細については、Google の Summer of Code のホームページ をご覧ください。
Electron は、ウェブ技術を用いたクロスプラットフォームのデスクトップアプリケーションを構築する JavaScript フレームワークです。 Electron フレームワークのコアは Chromium と Node.js で構築されたコンパイル済みバイナリ実行形式であり、主に C++ で書かれています。
Electron のコア以外にも以下のように、Electron 組織の維持に役立つ様々なプロジェクトに取り組んでいます。
Summer of Code の貢献者の方は、github.com/electron 傘下の多くのプロジェクトのうちの 1 つで、Electron のコアの貢献者の一部と協力して頂きます。
Electron にあまり詳しくない方は、ドキュメント を読んだり、Electron Fiddle のサンプルを試してみることをお勧めします。
Electron アプリの頒布形式の詳細について学ぶには、サンプルアプリケーションを作成して Electron Forge を試すのもよいでしょう。
npm init electron-app@latest my-app
コードに少し慣れたら、Electron の Discord サーバー での会話にご参加ください。
Google Summer of Code に初めて参加する方やオープンソース全般に馴染みがない方は、コミュニティに参加する前に、まず Google の 貢献者ガイド を読むことをお勧めします。
Electron との共同開発に興味を持てましたか? まずは、私たちが用意した 7 つのプロジェクトアイデア案 をご覧ください。 掲載されているアイデアは、すべて企画のために現在公開中のものです。
この他に検討して欲しいアイデアをお持ちですか? 提案プロジェクトのリストにない新しいアイデアも歓迎しますが、アプローチを十分に概説し、かつ詳細に説明するようにしてください。 あまり自信がないのであれば、リストのアイデアに従うことをお勧めします。
応募には以下のものがあるとよいでしょう。
Electron の応募で提出する一式の詳細なガイドはこちらです。 計画書は Google Summer of Code ポータルに直接提出してください。 注意として、申請ポータルから送信せずに Electron チームへ電子メールで送信した計画書は、最終提出物とみなされません。
計画書についてさらに詳しいガイダンスが必要な場合や、何を書き込めばよいかわからない場合は、Google Summer of Code 公式の計画書作成アドバイス に従うこともお勧めします。
応募開始は 2024 年 3 月 18 日、締め切りは 2024 年 4 月 2 日 です。
2022 年の Google Summer of Code では、インターンの @aryanshridhar さんには素晴らしい働きをして頂きました。 Aryan さんが夏に Electron で取り組んだことを確認したい方は、2022 GSoC プログラムのアーカイブ から彼のレポートを閲覧できます。
ブログ記事で取り上げられていない質問や計画書の執筆に関するお問い合わせは、summer-of-code@electronjs.org までメールしていただくか、GSoC FAQ をご確認ください。
Electron の API ワーキング グループ は、Electron のコアへのより大き な変更を支援するために、オープンな Requests for Comments (RFC) プロセスを採用しようとしています。
要するに、Electron のコアへの重要な変更を実装するプロセスをスムーズにしたいのです。
現在、新しいコードの変更は主に GitHub の Issue とプルリクエストを通じて議論されています。 Electron のほとんどの変更においては、これは良いシステムです。 多くのバグ修正、ドキュメントの変更、さらには新機能も、標準の GitHub フローを介せば非同期的にレビューおよびマージできるほど簡単です。
より重大な変更—たとえば大規模な API サーフェスや、Electron アプリの大部分に影響する重大な変更などの場合、コードの大部分が記述される前のアイデア段階でレビューを行うほうが合理的です。
このプロセスは一般公開されるように設計すべきです。そうすることで、Electron に導入される前に、オープンソースコミュニティ全体が潜在的な変更についてフィードバックを提供しやすくなります。
RFC 全体のプロセスは、GitHub 上の electron/rfcs リポジトリに保管されます。 プロセスの手順は、リポジトリの README で詳しく説明しています。
簡単に言うと、electron/rfcs リポジトリに PR が作成されると、RFC は 提唱 になります。
提唱の RFC は次のように遷移します。
main ブランチにマージされた場合になります。つまり、Electron のメンテナが electron/electron での実装に同意できることを意味します。RFC が アクティブ になるには、PR が少なくとも 2 人の API ワーキンググループのメンバーによって承認されなければなりません。 マージ前に、RFC は WG メンバーの 3 分の 2 以上の定足数によって開かれた会議で同期的に提示され、全会一致で承認される必要があります。 合意に達した場合、1 か月の最終コメント期間が開始され、その後 PR がマージされます。
実装が electron/electron にマージされたとき、アクティブな RFC は 完了 になります。
Electron コミュニティの誰もが、RFC を提出したり、electron/rfcs リポジトリにフィードバックを残したりできます!
text フォルダ を参照してください。私たちは、このプロセスを双方向の対話にして、コミュニティの参加を奨励し、将来これらの API を使用する可能性のある Electron アプリからの多様な意見を得たいと考えていました。 現在提唱状態の RFC にフィードバックを残したい方向けに、Electron のメンテナが既に作成したいくつかの RFC を下記します。
Electron の RFC プロセスは、多くの確立されたオープンソースの RFC プロセスに基づいてモデル化されました。 多くのアイデアやコピーライティングの主要部分のインスピレーションは、以下から得ました。
electron/electron リポジトリへの最初のコミットは 2013 年 3 月 13 日でした1。
その後、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 でアプリを作り始め (初期の採用企業は Slack、GitKraken、WebTorrent など)、このプロジェクトは Electron という適切な名前に変更されました。
それ以来、Electron は本格的に活動してきました。 週間ダウンロード数の変化は、こちらの npmtrends.com のご好意によってご覧いただけます。
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 の所有権も GitHub から OpenJS Foundation に 移行しました。 元々のコアチームは現在もMicrosoftで働いていますが、彼らはElectronの管理体制を形成する、より大きな協力者のグループの一部に過ぎません。2
このモデルは完璧ではありませんが、世界的パンデミックやマクロ経済の逆風が続く中で、私たちによく適していました。 今後は、Electron を次の 10 年に繋げるために、ガバナンス憲章を改訂していく予定です。
詳しく知りたい方は、electron/governance リポジトリをご確認ください！
オープンソースにおけるコミュニティの分野は難しいです。アウトリーチのチームが「コミュニティマネージャー」と書かれたトレンチコートを着た十数人のエンジニアである場合は特に難しくなります。 とはいえ、大規模なオープンソースプロジェクトであるということは、多くのユーザーを抱えているということであり、彼らの Electron に対するエネルギーを活用してユーザーランドのエコシステムを構築することは、プロジェクトの健全性を維持する上で極めて重要な要素です。
コミュニティの活気を高めるために、どのようなことを行ってきたのでしょうか。
現在、Electron のガバナンスには約 30 人のアクティブなメンテナがいます。 フルタイムで貢献している人は半分以下なので、あれもこれもと仕事が多いことになります。 すべてを円滑に進めるコツは何でしょうか？ 私たちのモットーは、コンピュータは安い、人の時間は高い、です。 典型的なエンジニアの活動において、より活動を快適にするための自動化サポートツール群を開発しました。
Electron のコアとなるコードベースは巨大な C++ コードの塊であり、そのビルド時間はバグ修正や新機能をいかに早く送り出せるかの制限要因となっていました。 2020 年には、Google の分散コンパイラサービス Goma の Electron 専用カスタムバックエンドである Not Goma をデプロイしています。 Not Goma は、認可されたユーザーのマシンからのコンパイル要求を処理し、バックエンドの数百のコアに処理を分散させます。 また、コンパイル結果をキャッシュしておくことで、同じファイルをコンパイルする他の人はそのコンパイル済み結果をダウンロードするだけでよくなります。
Not Goma の立ち上げ以降、メンテナのコンパイル時間が数時間の規模から数分に短縮されました。 安定したインターネット接続さえあれば、Electron をコンパイルできるようになりました！
オープンソース貢献者の方は、Electron Build Tools にてデフォルトで利用できる Not Goma の読み取り専用キャッシュをお試しいただけます。
Continuous Factor Authentication (CFA) は npm の二要素認証 (2FA) システムの自動化レイヤーで、semantic-release と組み合わせて様々な @electron/ npm パッケージの安全な自動リリースを管理します。
semantic-release でも npm パッケージの公開プロセスは自動できますが、これだけでは二要素認証をオフにするか制限を回避するシークレットトークンを渡す必要があります。
私たちは npm の 2FA の時間ベースのワンタイムパスワード (TOTP) を任意の CI ジョブに配信する CFA を構築し、二要素認証の追加セキュリティを維持しながら semantic-release の自動化を活用できるようにしました。
これには Slack での統合フロントエンドを備えた CFA を使用しています。これによりメンテナは、TOTP ジェネレータが手元にあれば Slack のあるどのデバイスからでもパッケージの公開を検証できます。
自分のプロジェクトで CFA を試してみたい方は、その GitHub リポジトリ や ドキュメント をご確認ください。 CI プロバイダとして CircleCI をご利用の場合、CFA を使った プロジェクトの基盤を素早く組むための 便利なオーブ も用意されています。
Sheriff は、GitHub、Slack、Google Workspace 全体での権限管理を自動化するために私たちが書いたオープンソースのツールです。
Sheriff の重要な価値提案は、権限管理は透明性のあるプロセスであるべきだということです。 これは上記のすべてのサービスにまたがって権限を指定するために、単一の YAML 設定ファイルを使用します。 Sheriff を使えば、PR を承認してマージするのと同じくらい簡単に、レポジトリのコラボレーターの状況を取得したり、新しいメーリングリストを作成したりできます。
Sheriff には Slack に投稿される監査ログもあり、Electron の組織内のどこかで不審な動きがあったときに管理者へ警告できます。
GitHub は豊富な API 拡張性を持つプラットフォームであり、Probot というファーストパーティのボットアプリケーションフレームワークを提供しています。 私たちがより創造的な仕 事に集中できるよう、私たちの代わりに単純作業をこなしてくれる小さいボット群を構築しています。 以下にいくつかの例を示します。
このような小さなボット家族のおかげで、開発者の生産性が大幅に向上しました！
プロジェクトとして次の 10 年を迎えるにあたって、疑問に思われることでしょう。Electron はこれからどうなるのでしょうか？
私たちは、Chromium のリリースケイデンスに同期して 8 週間ごとに Electron の新しいメジャーバージョンをリリースし、エンタープライズ級のアプリケーションの安定性と堅牢性を維持しながら、ウェブプラットフォームと Node.js による最新で最高のフレームワークを保ち続けます。
今後の取り組みについては基本的に、具体的になった時点でお知らせします。 今後のリリース、機能、一般的なプロジェクトの更新について知りたい方は、ブログ をご覧頂くか、ソーシャルメディアのプロフィール (Twitter や Mastodon) をフォローしてください!
これは実際には、2017 年に Electron に吸収されて git 履歴がマージされたelectron-archive/brightray プロジェクト での最初のコミットです。 でも細かいことはいいでしょう？ 誕生日ですから、ルールはこちらで決めちゃいました！ ↩
一般に信じられていることとは異なり、なんとElectronはGitHubやMicrosoftの所有ではなく、OpenJS Foundationの一部となっています。 ↩
Electron チームは、今年初めて 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 チャンネル にぜひいらしてください!
コミュニティの絆とオープンソースの1ヶ月間のお祝いのために私たちに参加してください。
Electronの Outreach ワーキンググループ は、 公式コミュニティ Discord サーバーの立ち上げを発表することを楽しみにしています！
Atom テキスト エディタののバックボーンとして、Electron フレームワークに関するコミュニティでのディスカッションは、Atom の Slack ワークスペースの1チャネルで行われていました。 時間が経ち、2つのプロジェクトが分離していくにつれて、AtomワークスペースとElectronプロジェクトとの関連性は低下し、Slackチャンネルへのメンテナンの参加者も同様に低下しました。
これまで、招待を受け取るのに苦労したと多く人からの報告を受けました。コアメンテナンス担当者のほとんどがチャンネルを頻繁に行なっていたにもかかわらず、より広範なコミュニティをAtom Slackワークスペースにリダイレクトしていました。
この新しいサーバーは、Electron に関する最新情報を得ることができる、コミュニティの中心的な議論の場となるようにしています。
今のところ、サーバーのメンバーシップは数人のメンターが協力して立ち上げていますが、皆さんとお話しできることをとても楽しみにしています。 助けを求めたり、Electron の最新情報を得たり、他の開発者と交流したりできます。 サーバーにアクセスできる便利な 招待リンク をご用意しました!
大規模で長期間実行されているオープンソースプロジェクトとして、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 第 2 段に参加させていただき、Electron としては大変光栄です。このイニシアティブでは、オープンソース組織のメンターとテクニカルライターがペアを組み、プロジェクトのドキュメントを改善していきます。
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 はリリースサイクルが高速かつより安定するように取り組んでいます。 実現のため、大規模 Electron ア プリのためのアプリフィードバックプログラムを始めました。ベータリリースをテストしてアプリ固有の問題を報告できます。 これは、できるだけ早くアプリケーションを次の安定リリースへアップグレードする、その作業の優先順位付けに役立ちます。
編集(2020-05-21):このプログラムは引退しました。
このプログラムに参加するアプリの基準と要件は、以下の項目の通りです。
すべてが正確なユーザー数を共有できるわけではないことは理解していますが、より良いデータは特定リリースの安定性の判断に役立ちます。 現在、アプリのテストはベータサイクルを通じて 10,000 ユーザー時間まで到達するようにお願いしています。
あなたのアプリのバグは追跡され、コア Electron チームのレーダーに記録されます。 あ なたのフィードバックが、新しいベータ版の動作確認、必要な作業の確認などで Electron チームの役に立ちます。
いいえ、アプリケーションの情報は一般公開されません。 情報は、アプリフィードバックプログラムと Electron ガバナンス のメンバーのみが閲覧できるプライベート GitHub リポジトリに保管されます。 メンバーは全員 Electron の 行動規範 の遵守に同意しています。
現在、新規申込の 数を限定 しています。 もし興味があり、上記の要件を満しているならば、この フォーム に記入してください。
今週は GitHub 通知を管理する Electron ベースのツール、Jasper の作者にインタビューを伺いました。
私は Ryo Maruyama で日本のソフトウェア開発者です。 Jasper と ESDoc を開発しています。
Jasper は GitHub 向けの柔軟で強力な Issue リーダーです。 github.com や GitHub Enterprise での Issue やプルリクエストに対応しています。
仕事や OSS の活動で GitHub を使っている人は、毎日のように大量の通知が届く傾向にあります。 通知を受け取る方法として、GitHub ではメールと ウェブ通知 を提供しています。 これらは数年前から使用していましたが、以下のような問題に直面しました。
こういった問題の対処に時間と労力を費やしていました。そこで効率的に解決するために GitHub 用の Issue リーダーを作ってみようと思い、Jasper の開発を始めました。
Jasper は、GitHub を利用する企業の 開発者、デザイナー、マネージャーに利用されています。 もちろん、OSS 開発者の中にも使っている人がいます。 さらに GitHub の人も使っています!
Jasper の設定を終えると、以下の画面が表示されます。 左から順に、"ストリームリスト"、"Issue リスト"、"Issue 本文" が表示されます。
この "ストリーム" は、Jasper の核となる機能です。 例えば、"eceltron/electron リポジトリの @zeke にアサインされた Issue" を見たい場合は、以下のようなストリームを作成します。
repo:electron/electron assignee:zeke is:issue
ストリームを作成して数秒待てば、条件を満たす Issue が表示されます。
ストリームにはどのような条件が使えるのかご紹介します。
| ストリーム | Issues |
|---|---|
mentions:cat mentions:dog | cat か dog のユーザをメンションした Issue |
author:cat author:dog | cat か dog が作成した Issue |
assignee:cat assignee:dog | cat か dog がアサインされた Issue |
commenter:cat commenter:dog | cat か dog がコメントした Issue |
involves:cat involves:dog | cat か bob が "関わりのある" Issue |
team:animal/white-cat team:animal/black-dog | animal/white-cat か animal/black-dog をメンションした Issue |
involves というのは mention、author、assignee、commenter のいずれかであるということです。
| ストリーム | Issues |
|---|---|
repo:cat/jump repo:dog/run | cat/jump か dog/run 内での Issue |
org:electron user:cat user:dog | electron か cat か dog 内での Issue |
org と user は同じです
| ストリーム | Issues |
|---|---|
repo:cat/jump milestone:v1.0.0 milestone:v1.0.1 | cat/jump 内で v1.0.0 か v1.0.1 に割り当てられた Issue |
repo:cat/jump label:bug label:blocker | cat/jump 内で bug と blocker を割り当てた Issue |
electron OR atomshell | electron か atomshell を含む Issue |
| ストリーム | Issues |
|---|---|
is:pr review:required | cat/jump 内のレビューが必要な Issue |
is:pr review-requested:cat | cat のレビューが必要な Issue。 まだレビューされていないものになります。 |
is:pr reviewed-by:cat | cat がレビューした Issue |
これらを見てお気づきかもしれませんが、ストリームには GitHub の検索クエリが使えます。 ストリームや検索クエリの使い方については、以下の URL を参照してください。
Jasper には、未読 Issue 管理、未読コメント管理、お気に入り、更新の通知、Issue のフィルタリング、キーボードショートカットなどの機能もあります。
Jasper は $12 です。 また、30 日間の 無料体験版 もあります。
Electron のこういったところが気に入っています。
これらの特長により、迅速にシンプルなデスクトップアプリケーションが開発できます。 素晴らしいことです! あなたもプロダクトのアイデアがあれば、是非 Electron の利用を検討し てみてください。
"ストリーム" の概念を考え出すところで苦労しました。 最初は GitHub の Notifications API を使おうと考えました。 しかし、特定のユースケースに対応していないと気づきました。 その後 Notification API に加えて、Issues API と Pull Requests API の利用も検討しました。 それでも、望んでいたものにはなりませんでした。 そこで、いろいろな方法を考えていくうちに、GitHub のSearch API をポーリングするのが最も柔軟だと気づきました。 ここまでに約 1 ヶ月の実験期間を要しましたが、その後 2 日でストリームの概念を取り入れた Jasper のプロトタイプを実装しました。
注: ポーリングは最大で 10 秒に 1 回までとなっています。 GitHub API の制限からすれば余裕を持たせてあります。
今後は以下のような機能を開発予定です。
更新情報は @jasperappio の Twitter を確認してください。
今週は @feross と @dcposch が WebTorrent についてお話しします。WebTorrent は、ユーザーをつなぎ合わせて分配された分散型ブラウザ間ネットワークを形成する、ウェブベースのトレントクライアントです。
WebTorrent は、ブラウザーで動く初のトレントクライアントです。 全て JavaScript で書かれており、P2P 転送に WebRTC を使用できます。 ブラウザのプラグイン、拡張機能、インストールは不要です。
公開のウェブ標準を使用して、WebTorrent はウェブサイトのユーザーを結び付け、効率的なファイル転送のために分配された分散型ブラウザ間ネットワークを形成します。
WebTorrent の実際のデモは webtorrent.io で見ることができます。
YouTube のようだけれども、訪問者がサイトコンテンツのホストを助けるビデオサイトを想像してください。 WebTorrent で強化されたウェブサイトは、利用者が多いほどより高速で強靭になります。
ブラウザ間通信は仲介者を排除し、人々が各々の条件で通信できます。 クライアント/サーバーは不要です。ピアのネットワークがあれば、みな平等です。 WebTorrent は、ウェブを再分散化する道程の初めの一歩です。
約 1 年前、デスクトップアプリ版 WebTorrent である WebTorrent デスクトップ を作成することにしました。
私たちは、以下の 3 つの理由の下に 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 3D Star Map でしょう。 これは、ぬるぬる動く天の川の 3D インタラクティブシミュレーションです。 データはトレントから直接ブラウザに読み込まれます。 銀河系を飛び回り、私たち人間が宇宙の広大さに比べてどれだけ小さいかを実感すると同時に畏敬の念を抱きます。
この作成方法は、著者の Charlie Hoey が WebGL と WebTorrent で天体図を作成した方法を説明しているブログ記事 Torrenting The Galaxy で読むことができます。
また、私たちは Brave の大ファンです。 Brave は、広告とトラッカーを自動的にブロックして、ウェブをより高速で安全にするブラウザです。 最近、Brave はトレントサポートを追加しました。そのため、従来のトレントを外部アプリなしで閲覧 できます。 この機能は WebTorrent で動作しています。
そのため、ほとんどのブラウザーが PDF ファイルを描画できるように、Brave はマグネットリンクとトレントファイルを描画できます。 これらは、ブラウザがネイティブでサポートするただの別種のコンテンツです。
なんと、Brave の共同創設者の 1 人は、WebTorrent の作成に使われた言語 JavaScript の作成者 Brendan Eich です。その Brave が 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 は私たちが必要としていたもので、堅牢で洗練されたアプリを記録的な速さで配信するために必要で正確な機能群を備えていました。
WebTorrent ライブラリは、オープンソースサイドプロジェクトとして 2 年間開発中で す。 **WebTorrent デスクトップは 4 週間で作成しました。**アプリを非常に迅速に構築して配信できたのは Electron であることが主な理由です。
jQuery を使用する世代のフロントエンドプログラマーを Node.js がサーバープログラミングに導いたのと同じで、Electron はウェブや Node.js の開発に精通している人なら誰でもネイティブアプリ開発に手を出せるようにします。 Electron は非常に強力です。
はい、webtorrent npm パッケージ は、Node.js、ブラウザ、Electron で動作します。 全く同じコードがすべての環境で実行できる — これが JavaScript の美です。 これが今日の万国共通の実行環境です。 Java Applets は "一度書けば、どこでも動く" アプリを約束しましたが、その理想は多くの理由で実際には実現しませんでした。 Electron は、他のどのプラットフォームよりも、本当にその理想に接近しています。
アプリの初期版では、UI パフォーマンスの向上に苦労しました。 メインアプリウィンドウを描画するレンダラープロセスと同じ所にトレントエンジンを配置していました。このため、予想どおり、トレントエンジンからの激しい CPU 演算 (ピアから受信したトレントピースの検証など) が発生した場合は常に低速になっていました。
これを修正するため、トレントエンジンを IPC を介して通信する 2 つ目の非表示のレンダラープロセスに移動しました。 こうすれば、そのプロセスが短時間に多くの CPU を使用する場合でも、UI スレッドは影響を受けません。 滑らかなスクロールとアニメーションには非常に満足です。
注釈: WebRTC (レンダラーでのみ使用可能) にアクセスする必要があるため、"メイン" プロセスではなく、レンダラープロセスにトレントエンジンを配置する必要がありました。
本番用のアプリを構築して配信する方法や、特にコード署名や自動更新などのトリッキーなテーマについて、より良いドキュメントを望んでいます。 私たちは、ソースコードを研究して Twitter で尋ねてベストプラクティスについて学ぶ必要がありました!
現行の WebTorrent デスクトップは素晴らしいと思いますが、改善の余地は常にあります。 現在、細かい点の修正、パフォーマンス、字幕サポート、映像コーデックサポートの改善に取り組んでいます。
プロジェクトの参加に興味がある場合は、私たちの GitHub ページ を見てください!
WebTorrent デスクトップのコントリビューターの 1 人である Feross は、最近 NodeConf Argentina で "Electron の世界: JavaScript でクロスプラットフォームアプリを構築" という講演を行い、洗練された Electron アプリをリリースするための便利なヒントを紹介しました。 この講演は、あなたが基本的な実用アプリを持っている段階にいて、それを次のレベルの洗練と専門的な領域に昇華させようとしているのであれば非常に役立ちます。
もう一人の WebTorrent のコントリビューターである DC は、アプリを洗練されたネイティブにするための できることのチェックリスト を書きました。 コード例が付いており、macOS Dock 統合、ドラッグアンドドロップ、デスクトップ通知、アプリの読み込みを速くするなどをカバーしています。