Electron におけるコミュニティの取り組み
すべてのタグを表示
Electron API の過去の変更点がドキュメントに詳しく記載されるようになりました。
こんにちは 👋、私はピーターです。Electron の2024年 Google Summer of Code (GSoC) のコントリビューターです。
GSoC プログラムを通して、Electron のドキュメントと関数やクラスなどに API 履歴機能を実装しました。これは Node.js ドキュメント と同様に、API ドキュメントの Markdown ファイルでシンプルかつ強力な YAML スキーマを使用し、Electron ドキュメントウェブサイトにわかりやすく表示できるようにしました。
Electron が Google Summer of Code (GSoC) 2024 の第20回エディションのメンター組織として承認されたことを発表できることを嬉しく思います！Google Summer of Code は、オープンソースソフトウェア開発に新しいコントリビューターを招くことに重点を置いたグローバルプログラムです。
プログラムの詳細については、Google の Summer of Code のホームページ をご確認ください。
Electron は、ウェブテクノロジーを使用してクロスプラットフォームデスクトップアプリケーションを構築するための JavaScript フレームワークです。コアの Electron フレームワークは、Chromium と Node.js で構築されたコンパイル済みのバイナリ実行可能ファイルで、ほとんどが C++ で記述されています。
Electron コア以外にも、Electron 組織を維持するために、以下のようなさまざまなプロジェクトに取り組んでいます。
Summer of Code のコントリビューターとして、github.com/electron の傘下にある多数のプロジェクトのいずれかで、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とpull requestを通じて議論されています。Electronへのほとんどの変更については、これは良いシステムです。多くのバグ修正、ドキュメントの変更、さらには新機能でさえ、標準的なGitHubフローを通じて非同期的にレビューしてマージするのに十分なほど簡単です。
より重要な変更、例えば、大規模なAPIサーフェスや、Electronアプリの大部分に影響を与える破壊的な変更については、コードの大部分が書かれる前のアイデア段階でレビューを行うのが理にかなっています。
このプロセスは一般に公開されるように設計されており、オープンソースコミュニティ全体が、Electronに実装される可能性のある変更について、実装される前にフィードバックを提供することも容易になります。
RFCプロセス全体は、GitHubのelectron/rfcsリポジトリに存在します。手順の詳細については、リポジトリのREADMEに記載されています。
簡単に言うと、RFCは、electron/rfcsリポジトリにPRが作成されると提案済となります。提案済みのRFCは、
mainブランチにマージされるとアクティブになります。これは、Electronメンテナーがelectron/electronでの実装に賛成していることを意味します。または、RFCがアクティブになるには、PRが少なくとも2人のAPIワーキンググループメンバーによって承認される必要があります。マージする前に、RFCは同期的に提示され、WGメンバーの3分の2以上の定足数によって全会一致で承認される必要があります。合意に達した場合、1か月の最終コメント期間が開始され、その後PRがマージされます。
アクティブなRFCは、実装がelectron/electronにマージされると完了となります。
Electronコミュニティの誰でも、RFCを提出したり、electron/rfcsリポジトリにフィードバックを残したりできます！
textフォルダを参照してください。このプロセスを双方向の対話にし、将来的にこれらのAPIを利用する可能性のあるElectronアプリから多様な意見を得るために、コミュニティの参加を奨励したいと考えました。現在提案されているRFCにフィードバックを残すことに興味がある場合は、Electronメンテナーがすでにいくつか作成しています。
ElectronのRFCプロセスは、多くの確立されたオープンソースRFCプロセスをモデルにしています。多くのアイデアとコピーライティングの大部分は、以下からインスピレーションを得ています。
electron/electronリポジトリへの最初のコミットは、2013年3月13日でした1。
10年と1192人のユニークな貢献者からの27,147件以上のコミットを経て、Electronは今日、デスクトップアプリケーションを構築するための最も人気のあるフレームワークの1つになりました。この節目は、これまでの道のりを祝い、振り返り、その過程で学んだことを共有する絶好の機会です。
プロジェクトに時間と労力を費やして貢献してくださった皆様がいなければ、私たちは今日ここにいませんでした。ソースコードのコミットは常に最も目に見える貢献ですが、バグを報告したり、ユーザーランドモジュールを保守したり、ドキュメントや翻訳を提供したり、サイバースペース全体でElectronコミュニティに参加したりする人々の努力も認めなければなりません。すべての貢献は、メンテナーである私たちにとって非常に貴重です。
ブログ記事の続きに入る前に、ありがとうございます。❤️
Atom Shellは、GitHubのAtomエディターのバックボーンとして構築され、2014年4月にパブリックベータ版がリリースされました。当時利用可能だったWebベースのデスクトップフレームワーク（node-webkitとChromium Embedded Framework）の代替としてゼロから構築されました。Node.jsとChromiumを組み込み、Webテクノロジーに強力なデスクトップランタイムを提供するというキラー機能がありました。
1年以内に、Atom Shellは機能と人気が著しく高まり始めました。大企業、スタートアップ、個人の開発者も同様に、それを使用してアプリを構築し始め（初期の採用者には、Slack、GitKraken、WebTorrentなどがあります）、プロジェクトは適切にElectronに改名されました。
それ以来、Electronはすぐに軌道に乗り、止まることはありませんでした。以下は、npmtrends.com提供の、時間の経過に伴う週ごとのダウンロード数の推移です。
Electron v1は2016年にリリースされ、APIの安定性の向上とドキュメントおよびツールの改善を約束しました。Electron v2は2018年にリリースされ、セマンティックバージョニングが導入され、Electron開発者がリリースサイクルを追跡しやすくなりました。
Electron v6までに、Chromiumに合わせて、12週間ごとの定期的なメジャーリリースサイクルに移行しました。この決定は、プロジェクトの考え方の変化であり、「最新のChromiumバージョンを持つこと」を、あって便利なものから優先事項に変えました。これにより、アップグレード間の技術的負債が減少し、Electronを最新の状態に保ち、安全性を維持することが容易になりました。
それ以来、私たちは順調に稼働し、すべてのChromium安定版と同じ日に新しいElectronバージョンをリリースしています。Chromiumが2021年にリリーススケジュールを4週間に高速化するまでに、私たちは肩をすくめて、それに応じてリリースサイクルを8週間に増やすことができました。
現在、私たちはElectron v23（そしてカウント中）であり、クロスプラットフォームのデスクトップアプリケーションを構築するための最高のランタイムを構築することに専念しています。近年、JavaScript開発者ツールが急増しているにもかかわらず、Electronはデスクトップアプリフレームワークの分野で安定した、実戦でテストされた主力であり続けています。Electronアプリは今日ではどこにでもあります。Visual Studio Codeでプログラミングしたり、Figmaでデザインしたり、Slackでコミュニケーションしたり、Notionでメモを取ることができます（他にも多くの使用例があります）。私たちはこの成果を非常に誇りに思っており、可能にしてくださったすべての人々に感謝しています。
10年の節目までの道のりは長く曲がりくねったものでした。持続可能な大規模オープンソースプロジェクトを運営するのに役立った重要な点をいくつか紹介します。
私たちが克服しなければならなかった1つの課題は、Electronが最初に人気を博した後、プロジェクトの長期的な方向性をどのように処理するかでした。企業、国、タイムゾーンに分散した数十人のエンジニアのチームとして、どのように対応すればよいのでしょうか？
初期の頃、Electronのメンテナーグループは非公式な調整に依存していました。これは小規模なプロジェクトでは迅速で軽量ですが、より広範なコラボレーションには拡張できません。2019年に、私たちはさまざまなワーキンググループが正式な責任分野を持つガバナンスモデルに移行しました。これは、プロセスを合理化し、プロジェクトの所有権の一部を特定のメンテナーに割り当てる上で非常に役立っています。現在、各ワーキンググループ（WG）は何を担当しているのでしょうか？
ガバナンスモデルに移行したのとほぼ同時期に、Electron の所有権を GitHub からOpenJS Foundation へと移管しました。当初のコアチームは現在も Microsoft で働いていますが、彼らは Electron のガバナンスを形成するより大きな協力者グループの一部に過ぎません。2
このモデルは完璧ではありませんが、世界的なパンデミックや継続的なマクロ経済の逆風の中、私たちにはうまく機能してきました。今後は、Electron の 2 番目の 10 年を導くためにガバナンス憲章を刷新する予定です。
詳細を知りたい場合は、electron/governance リポジトリをご覧ください！
オープンソースのコミュニティ部分は難しいものであり、特にアウトリーチチームが「コミュニティマネージャー」と書かれたトレンチコートを着た 12 人のエンジニアの場合、なおさらです。とは言え、大規模なオープンソースプロジェクトであるということは、多くのユーザーがいることを意味し、彼らのエネルギーを Electron に活用してユーザーランドのエコシステムを構築することは、プロジェクトの健全性を維持する上で非常に重要です。
コミュニティのプレゼンスを高めるために、私たちは何をしてきたのでしょうか？
現在、Electron のガバナンスには約 30 人のアクティブなメンテナーがいます。私たちのうち、フルタイムで貢献している人は半数未満です。つまり、やるべきことはたくさんあります。すべてをスムーズに稼働させるための私たちの秘訣は何でしょうか？私たちのモットーは、コンピューターは安く、人間の時間は高価だということです。典型的なエンジニアらしく、私たちは自分たちの生活を楽にするための自動化されたサポートツール群を開発しました。
Electron のコアコードベースは C++ コードの巨大な塊であり、ビルド時間は常にバグ修正や新機能のリリース速度を制限する要因でした。2020 年に、Google の Goma 分散コンパイラサービス向けのカスタムの Electron 固有のバックエンドである Not Goma を導入しました。Not Goma は、認証されたユーザーのコンピュータからのコンパイルリクエストを処理し、バックエンドの数百のコアに処理を分散させます。また、コンパイル結果をキャッシュするため、同じファイルをコンパイルする別の人は、事前にコンパイルされた結果をダウンロードするだけで済みます。
Not Goma の導入以来、メンテナーのコンパイル時間は数時間規模から数分規模に短縮されました。安定したインターネット接続が、貢献者が Electron をコンパイルするための最低限の要件となりました！
オープンソースの貢献者であれば、Electron Build Tools でデフォルトで利用できる Not Goma の読み取り専用キャッシュも試すことができます。
継続的二要素認証（CFA）は、npm の二要素認証（2FA）システムを自動化するレイヤーであり、これを semantic-release と組み合わせて、さまざまな @electron/ npm パッケージの安全で自動化されたリリースを管理しています。
semantic-release はすでに npm パッケージの公開プロセスを自動化していますが、二要素認証を無効にするか、この制限を回避するシークレットトークンを渡す必要があります。
CFA は、npm 2FA 用の時間ベースのワンタイムパスワード（TOTP）を任意の CI ジョブに提供するように構築されており、二要素認証による追加のセキュリティを維持しながら、semantic-release の自動化を活用できます。
Slack インテグレーションフロントエンドで CFA を使用しており、メンテナーは TOTP ジェネレーターを手元に持っていれば、Slack がインストールされているどのデバイスからでもパッケージの公開を検証できます。
自分のプロジェクトで CFA を試してみたい場合は、GitHub リポジトリまたは ドキュメントを確認してください！CircleCI を CI プロバイダーとして使用している場合は、CFA でプロジェクトを迅速に足場組みするための 便利な orb も用意されています。
Sheriff は、GitHub、Slack、Google Workspace 全体での権限管理を自動化するために作成したオープンソースツールです。
Sheriff の主な価値提案は、権限管理は透過的なプロセスであるべきだということです。上記のすべてのサービス全体の権限を指定する単一の YAML 設定ファイルを使用します。Sheriff を使用すると、リポジトリでのコラボレーターのステータスを取得したり、新しいメーリングリストを作成したりすることが、PR が承認されてマージされるのと同じくらい簡単になります。
Sheriff には Slack に投稿する監査ログもあり、Electron 組織のどこかで不審なアクティビティが発生すると管理者に警告します。
GitHub は、豊富な API 拡張性と、Probot と呼ばれるファーストパーティのボットアプリケーションフレームワークを備えたプラットフォームです。より創造的な仕事に集中できるように、私たちは私たちの代わりに地味な作業をこなしてくれる、より小さなボット群を構築しました。以下にいくつかの例を示します。
私たちの小さなボットファミリーは、開発者の生産性を大幅に向上させてくれました！
プロジェクトとして 2 番目の 10 年に入るにあたり、Electron の次は何かと疑問に思うかもしれません。
私たちは、Chromium のリリースケイデンスと同期し続け、8 週間ごとに Electron の新しいメジャーバージョンをリリースし、エンタープライズグレードのアプリケーションの安定性とセキュリティを維持しながら、Web プラットフォームと Node.js の最新かつ最高のものをフレームワークに反映させていきます。
今後の取り組みに関するニュースは、具体的なものになった時点で発表する予定です。今後のリリース、機能、一般的なプロジェクトの最新情報を知りたい場合は、私たちのブログを読んだり、ソーシャルメディアプロファイル（Twitter および Mastodon）をフォローしてください！
これは実際には、electron-archive/brightray プロジェクトからの最初のコミットであり、2017 年に Electron に吸収され、git の履歴がマージされました。しかし、誰が数えているでしょうか？今日は私たちの誕生日なので、ルールは私たちが作ります！↩
一般的な考えとは異なり、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のアウトリーチワーキンググループは、公式コミュニティDiscordサーバーの立ち上げを発表できることを嬉しく思います！
Atomテキストエディターのバックボーンとして初期の頃、Electronフレームワークに関するコミュニティの議論はAtomのSlackワークスペースの単一のチャンネルで行われていました。時間が経つにつれて、2つのプロジェクトの切り離しが進むにつれて、Electronプロジェクトに対するAtomワークスペースの関連性は低下し、同じようにSlackチャンネルでのメンテナーの参加も減少しました。
今まで、招待状の受け取りに苦労しているという報告や、コアメンテナーが頻繁にチャンネルを訪れていないという報告が多数あったにもかかわらず、私たちはより広範なコミュニティをAtom Slackワークスペースにリダイレクトしていました。
私たちは、この新しいサーバーを、Electronに関するすべての最新ニュースを入手できるコミュニティの中心的な議論の場として設定しています。
これまでのところ、サーバーのメンバーシップは、サーバーを立ち上げるために協力してきた数人のメンテナーで構成されていますが、皆さんとチャットできることを楽しみにしています！助けを求めたり、Electronのリリースに関する最新情報を入手したり、他の開発者と交流したりしてください。サーバーにアクセスできる便利な招待状を用意しました！
大規模で長期間にわたるオープンソースプロジェクトとして、Electronは、コードの提出からバグレポート、ドキュメントの変更など、コミュニティからのあらゆる貢献がなければ、これほど成功していなかったでしょう。そのため、私たちは、あらゆるスキルレベルの開発者のより広いコミュニティをプロジェクトに導入するために、Hacktoberfestに参加することの重要性を信じています。
今年は、皆さんに取り組んでいただくためのより大きなプロジェクトはありませんが、Electron JavaScriptエコシステム全体で貢献の機会に焦点を当てたいと考えています。
メインのelectron/electronリポジトリ、electron/electronjs.orgウェブサイト、electron/fiddle、electron-userland/electron-forgeなど、さまざまなリポジトリでhacktoberfestタグが付いたイシューを探してください。
追伸：特に冒険心がある場合は、help wantedタグが付いたイシューのバックログもあります。よりチャレンジングなものを探している場合は、どうぞ。
さらに、Discordサーバーのグランドオープンが、今年最大のオープンソースソフトウェアのお祝いと一致しているのも偶然ではありません。#hacktoberfestチャンネルでHacktoberfest PRに関するヘルプを求めてください。見逃した場合は、こちらに再度招待リンクがあります！
Electronは、GoogleのSeason of Docsイニシアチブの第2版に参加できることを誇りに思っています。このイニシアチブでは、プロジェクトドキュメントを改善するために、オープンソース組織のメンターとテクニカルライターがペアを組みます。
Season of Docsは、テクニカルライターとオープンソースコミュニティ間のコラボレーションを促進し、両者に利益をもたらすプログラムです。オープンソースのメンテナーは、ライターのテクニカルライティングの専門知識を利用してドキュメントの構造と内容を改善し、テクニカルライターはメンターの指導の下でオープンソースコミュニティに紹介されます。詳細については、GoogleのSeason of Docsウェブサイトをご覧ください。
このプログラムに初めて参加するにあたり、私たちはElectronのエコシステムワーキンググループと協力して、ドキュメントの大部分を再構築する1人のテクニカルライターをメンタリングします。プロジェクト全体のタイムラインについては、こちらをご覧ください。
テクニカルライターとして私たちと協力することに興味がありますか？まず、Googleの今年のプログラムのテクニカルライターガイドに目を通し、私たちが準備した2つのプロジェクトアイデア案をご覧ください。
Season of DocsでElectronのテクニカルライターとして選ばれるためには、候補者は6月8日から7月9日まで実施されるテクニカルライター応募期間中に、Google Season of Docsウェブサイトで応募する必要があります。
あなたの応募には、提案書を含める必要があります。これは、3ヶ月間Electronドキュメントで達成しようとしていることを詳細に記述した文書です。この提案書は、プロジェクトアイデア文書で言及されている出発点の1つに基づいて作成することも、完全に新しいものにすることもできます。どこから始めたらよいかわからない？インスピレーションを得るために、昨年の承認された提案書リストを確認できます。
提案書に加えて、テクニカルライターとしてのあなたの経歴も検討します。関連するライティング経験に重点を置いた履歴書のコピーと、テクニカルライティングのサンプル（これらのサンプルは、既存のドキュメント、チュートリアル、ブログ記事など）を含めてください。
プロジェクト提案について議論したい場合は、season-of-docs@electronjs.orgにメールを送ってください。そこからチャットできます！
Electronは、リリースサイクルをより迅速かつ安定させるために取り組んでいます。それを実現するために、私たちは大規模なElectronアプリを対象としたアプリフィードバックプログラムを開始し、ベータリリースをテストし、アプリ固有の問題を私たちに報告してもらっています。これにより、アプリケーションを次の安定リリースに早期にアップグレードするための作業に優先順位を付けることができます。
編集 (2020-05-21)：このプログラムは廃止されました。
このプログラムに参加するアプリの基準と期待には、次の項目が含まれます
すべての方が正確なユーザー数を共有できるわけではないことは理解していますが、より良いデータは、特定のリリースがどれほど安定しているかを判断するのに役立ちます。アプリには、ベータサイクル全体で最低限のユーザー時間数 (現在は10,000時間) のテストを実施することを求めます。
アプリのバグは追跡され、Electronコアチームのレーダーに載ります。フィードバックは、Electronチームが新しいベータ版の状況と、必要な作業を確認するのに役立ちます。
いいえ、アプリケーションの情報は一般に公開されません。情報は、アプリフィードバックプログラムのメンバーとElectronガバナンスのメンバーのみが閲覧できるプライベートGitHubリポジトリに保管されます。すべてのメンバーは、Electronの行動規範に従うことに同意しています。
現在、限定数のサインアップを受け付けています。ご興味があり、上記の要件を満たすことができる場合は、こちらのフォームにご記入ください。
今週は、GitHubの通知を管理するためのElectronベースのツールであるJasperの作成者にインタビューしました。
私は丸山 遼です。日本のソフトウェア開発者です。JasperとESDocを開発しています。
Jasperは、GitHub用の柔軟で強力なissueリーダーです。github.comおよびGitHub Enterpriseのissueとpull requestをサポートしています。
人々が仕事やOSS活動でGitHubを使用すると、毎日多くの通知を受け取る傾向があります。通知を購読する方法として、GitHubはメールとWeb通知を提供しています。私はこれらを数年間使用していましたが、次の問題に直面しました。
これらの問題を回避するために多くの時間とエネルギーを費やしていたため、これらの問題を効率的に解決するためにGitHub用のissueリーダーを作成することにし、Jasperの開発を開始しました。
Jasperは、GitHubを使用しているいくつかの企業の開発者、デザイナー、マネージャーが使用しています。もちろん、一部のOSS開発者も使用しています。そして、GitHubの一部のメンバーも使用しています！
Jasperが構成されると、次の画面が表示されます。左から右に、「ストリームリスト」、「issueリスト」、「issue本文」が表示されます。
この「ストリーム」は、Jasperのコア機能です。たとえば、「electron/electronリポジトリの@zekeに割り当てられたissue」を確認したい場合は、次のストリームを作成します。
repo:electron/electron assignee:zeke is:issue
ストリームを作成し、数秒待つと、条件を満たすissueが表示されます。
ストリームに使用できる条件の種類を紹介します。
| ストリーム | Issue |
|---|---|
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を意味します。
| ストリーム | Issue |
|---|---|
repo:cat/jump repo:dog/run | cat/jumpまたはdog/runのissue |
org:electron user:cat user:dog | electron、catまたはdogのissue |
orgはuserと同じです。
| ストリーム | Issue |
|---|---|
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 |
| ストリーム | Issue |
|---|---|
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の通知APIを使用することを検討しました。しかし、特定のユースケースをサポートしていないことに気づきました。その後、通知APIに加えて、Issues APIとPull Requests APIを使用することを検討しました。しかし、私が望んでいたものにはなりませんでした。さまざまな方法について考えていたときに、GitHubのSearch APIをポーリングすることが最も柔軟性があることに気づきました。この点に到達するまでに約1か月の実験が必要でしたが、その後、ストリームの概念を持つJasperのプロトタイプを2日間で実装しました。
注：ポーリングは、最大でも10秒に1回に制限されています。これは、GitHub APIの制限に対して十分に許容できます。
次の機能を開発する計画があります。
更新については、Twitterで@jasperappioをフォローしてください。
今週は、@ferossと@dcposchに、分散型、分散型のブラウザ間ネットワークを形成するためにユーザーをつなぐ、Webで動作するTorrentクライアントであるWebTorrentについて話を聞きました。
WebTorrentは、ブラウザで動作する最初のTorrentクライアントです。完全にJavaScriptで記述されており、ピアツーピア転送にWebRTCを使用できます。ブラウザのプラグイン、拡張機能、インストールは必要ありません。
オープンWeb標準を使用して、WebTorrentはWebサイトのユーザーをつなぎ合わせ、効率的なファイル転送のための分散型、分散型のブラウザ間ネットワークを形成します。
WebTorrent のデモは、こちらでご覧いただけます: webtorrent.io。
YouTube のような動画サイトを想像してみてください。ただし、サイトのコンテンツをホストするのは訪問者自身です。WebTorrent を利用したウェブサイトを使用する人が増えるほど、高速になり、より回復力が向上します。
ブラウザ間の通信は仲介者を排除し、人々が自分たちの条件で通信できるようにします。クライアント/サーバーの必要がなくなり、すべてが対等なピアのネットワークになります。WebTorrent は、Web を再び分散化するための第一歩です。
約1年前、私たちは WebTorrent のデスクトップアプリ版である WebTorrent Desktop を構築することにしました。
WebTorrent Desktop を作成した理由は3つあります。
まず、WebTorrent の設計に関する背景を少し説明します。
初期の BitTorrent は、トランスポートプロトコルとして TCP を使用していました。その後、uTP が登場し、TCP よりも優れたパフォーマンスと追加の利点が約束されました。すべての主流の torrent クライアントが最終的に uTP を採用し、今日ではどちらのプロトコルでも BitTorrent を使用できます。WebRTC プロトコルは、次の論理的なステップです。これにより、Web ブラウザとの相互運用性が実現します。つまり、すべてのデスクトップ BitTorrent クライアントと数百万の Web ブラウザで構成される巨大な P2P ネットワークです。
「Webピア」（Web ブラウザで実行される torrent ピア）は、何百万もの新しいピアを追加し、BitTorrent を多くの新しいユースケースに広げることで、BitTorrent ネットワークを強化します。WebTorrent は、既存の BitTorrent クライアントが WebTorrent を簡単にサポートできるように、BitTorrent 仕様に可能な限り厳密に従っています。
Vuze のような一部の torrent アプリはすでに Web ピアをサポートしていますが、他のアプリがサポートを追加するのを待つことはしたくありませんでした。つまり、WebTorrent Desktop は、WebTorrent プロトコルの採用を加速するための手段でした。人々が本当に使いたいと思うような素晴らしい torrent アプリを作成することで、Web ピア（つまり、Web サイトのユーザー）と torrent を共有できるネットワーク内のピアの数を増やすことができます。
WebTorrent の最もエキサイティングな用途の 1 つは、ピア支援配信です。Wikipedia や Internet Archive のような非営利プロジェクトは、訪問者に貢献させることで、帯域幅とホスティングコストを削減できます。人気のあるコンテンツはブラウザ間で迅速かつ安価に提供できます。アクセス頻度の低いコンテンツは、オリジンサーバーから HTTP 経由で確実に提供できます。
Internet Archive は実際にすでに torrent ファイルを更新しており、WebTorrent でうまく機能します。したがって、Internet Archive のコンテンツをサイトに埋め込みたい場合は、アーカイブのホスティングコストを削減し、Web のアーカイブに実際により多くのお金を費やすことができるようにすることができます。
また、CDN から P2P によるアプリ配信まで、エキサイティングなビジネスユースケースもあります。
WebTorrent で構築された最もクールなものは、おそらく Gaia 3D Star Map でしょう。これは、天の川の洗練された 3D インタラクティブシミュレーションです。データは、ブラウザ内で直接 torrent からロードされます。私たちの星系を飛び回り、広大な宇宙と比較して、私たち人間がどれほど小さいかを実感するのは、畏敬の念を抱きます。
これがどのように作成されたかについては、Torrenting The Galaxy で読むことができます。このブログ記事で、著者の Charlie Hoey は、WebGL と WebTorrent を使用して星図を構築した方法を説明しています。
また、私たちは Brave の大ファンです。Brave は、広告とトラッカーを自動的にブロックして、Web をより高速かつ安全にするブラウザです。Brave は最近 torrent サポートを追加したため、別のアプリを使用せずに従来の torrent を表示できます。この機能は WebTorrent を利用しています。
したがって、ほとんどのブラウザが PDF ファイルをレンダリングできるのと同じように、Brave はマグネットリンクと torrent ファイルをレンダリングできます。これらは、ブラウザがネイティブにサポートする別のタイプのコンテンツにすぎません。
Brave の共同創設者の 1 人は、実際に JavaScript の作成者である Brendan Eich であり、JavaScript は WebTorrent を作成した言語であるため、Brave が WebTorrent を統合することを選んだのは非常にクールだと思います。
すべてのアプリに Chrome コンテンツモジュール全体が含まれているため、Electron アプリは「肥大化している」というミームがあります。場合によっては、これは部分的に当てはまります（Electron アプリのインストーラーは通常約 40MB で、OS 固有のアプリのインストーラーは通常約 20MB です）。
ただし、WebTorrent Desktop の場合、ほぼすべての Electron 機能と、通常の操作中に多数の Chrome 機能を使用します。これらの機能をプラットフォームごとにゼロから実装する場合、アプリの構築に数か月または数年長くかかったり、単一のプラットフォーム向けにしかリリースできなかった可能性があります。
ほんの一例として、Electron の ドック統合（ダウンロードの進捗状況を表示するため）、メニューバー統合（バックグラウンドで実行するため）、プロトコルハンドラーの登録（マグネットリンクを開くため）、省電力ブロッカー（ビデオ再生中にスリープを防ぐため）、および 自動更新を使用しています。Chrome 機能としては、<video> タグ（さまざまなビデオ形式を再生するため）、<track> タグ（クローズドキャプションのサポートのため）、ドラッグアンドドロップのサポート、および WebRTC（ネイティブアプリで使用するのは簡単ではありません）を多数使用しています。
言うまでもなく、私たちの torrent エンジンは JavaScript で記述されており、多数の Node API、特に TCP および UDP ソケットサポート用の require('net') および require('dgram') の存在を前提としています。
基本的に、Electron はまさに私たちが求めていたものであり、堅牢で洗練されたアプリを記録的な速さで出荷するために必要な機能の正確なセットを備えていました。
WebTorrent ライブラリは、オープンソースのサイドプロジェクトとして 2 年間開発されてきました。WebTorrent Desktop は 4 週間で作成しました。Electron は、アプリを非常に迅速に構築および出荷できた主な理由です。
Node.js が jQuery を使用するフロントエンドプログラマーの世代にとってサーバープログラミングを身近にしたのと同じように、Electron は Web または Node.js 開発に精通している人なら誰でもネイティブアプリ開発を身近にします。Electron は非常に強力です。
はい、webtorrent npm パッケージ は、Node.js、ブラウザ、および Electron で動作します。まったく同じコードをすべての環境で実行できます。これが JavaScript の美しさです。今日では、ユニバーサルランタイムです。Java アプレットは「一度書けばどこでも実行できる」アプリを約束しましたが、さまざまな理由から、そのビジョンは実際には実現しませんでした。Electron は、他のどのプラットフォームよりも、実際にその理想にかなり近いものになっています。
アプリの初期バージョンでは、UI のパフォーマンスを高く保つことに苦労しました。torrent エンジンをメインアプリウィンドウを描画するのと同じレンダラープロセスに配置しましたが、案の定、torrent エンジンからの激しい CPU アクティビティ（ピアから受信した torrent ピースの検証など）があるときは常に処理が遅くなりました。
これを修正するために、torrent エンジンを 2 番目の不可視のレンダラープロセスに移動し、IPC を介して通信しました。このようにすると、そのプロセスが CPU を大量に使用した場合でも、UI スレッドは影響を受けません。スムーズなスクロールとアニメーションは非常に満足できます。
注：WebRTC（レンダラーでのみ使用可能）にアクセスする必要があるため、torrent エンジンを「メイン」プロセスではなくレンダラープロセスに配置する必要がありました。
私たちが望んでいることの 1 つは、特にコード署名や自動更新のようなトリッキーなテーマに関する、本番環境に対応したアプリを構築および出荷する方法に関するより良いドキュメントです。ソースコードを調べて Twitter で尋ねることで、ベストプラクティスについて学ぶ必要がありました！
現在のWebTorrent Desktopは素晴らしいと考えていますが、常に改善の余地はあります。現在、私たちは、洗練さ、パフォーマンス、字幕サポート、およびビデオコーデックのサポートの改善に取り組んでいます。
このプロジェクトへの参加にご興味がある場合は、GitHubページをご覧ください。
WebTorrent Desktopのコントリビューターの一人であるFerossは、最近NodeConf Argentinaで「現実世界のElectron：JavaScriptでクロスプラットフォームデスクトップアプリを構築する」という講演を行い、洗練されたElectronアプリをリリースするための役立つヒントを紹介しました。この講演は、基本的な動作アプリが完成し、それをさらに洗練させてプロフェッショナルなレベルに引き上げようとしている段階にいる場合に特に役立ちます。
もう一人のWebTorrentコントリビューターであるDCは、アプリを洗練されたネイティブのように感じさせるためにできることのチェックリストを執筆しました。これにはコード例が含まれており、macOSドックの統合、ドラッグアンドドロップ、デスクトップ通知、アプリの高速読み込みなどをカバーしています。