Google Chromium で、すべての最新バージョンの Electron に影響するリモートコード実行の脆弱性が発見されました。 リモートコンテンツにアクセスする Electron アプリは、sandbox オプション の有効に関係なく、このエクスプロイトに対する脆弱性があります。
1.7.8 と 1.6.14 の 2 つの新しいバージョンの Electron を公開しました。どちらもこの脆弱性の修正が含まれています。 Electron 開発者全員は、アプリをすぐに最新の安定バージョンに更新することを推奨します。
npm i electron@latest --save-dev
Electron アプリを堅牢に保つベストプラクティスの詳細は、セキュリティチュートリアル を参照してください。
Please file a GitHub Security Advisory if you wish to report a vulnerability in Electron.
Electron npm パッケージに、Electron API 全体の詳細なアノテーションを提供する TypeScript 定義ファイルが含まれるようになりました。 これらのアノテーションは、たとえ純粋なJavaScriptを書いていていても、Electron の開発エクスペリエンスを向上させることができます。 ただnpm install electron を実行して、あなたのプロジェクトに最新の Electron の入力を取得できます。
TypeScript は、Microsoft が作成したオープンソースのプログラミング言語です。 これは、静的型をサポート追加することで言語を拡張する JavaScript のスーパーセットです。 TypeScript のコミュニティは近年急速に成長しています。そしてTypeScriptは、最近のStack Overflow開発者調査で 最も愛されているプログラミング言語にランクインしました。 TypeScript は「スケールする JavaScript」と説明されています。GitHub、SlackとMicrosoftのチームはこれを使って数百万人が使用する、スケーラブルな Electron アプリを作成しています。
TypeScript は、JavaScript により新しい多くの言語機能を提供しています。クラス、オブジェクトの破棄、非同期/待機などです。しかしその本当の差別化機能は**型アノテーション **です。 プログラムに期待される入出力データ型を宣言すると、コンパイル時にエラーを見つけることができ、バグを減らすことができます。そしてアノテーションはプログラムがどのように動作するかを形式的に説明することになります。
純粋な Javascript でライブラリが書かれている場合、ドキュメントを書くときには、その型はしばしば漠然と定義されます。 関数は、多くの場合、ドキュメントで指定された型よりも多くの型を受け入れることもありますし、関数にドキュメント化されていない、暗黙の型の制約を持つ場合があります。そのためにランタイムエラーが発生する可能性もあります。
TypeScript は 定義ファイル でこの問題を解決します。 TypeScript の定義ファイルには、ライブラリのすべての関数と、それらの関数で期待される入出力の型が記述されています。 ライブラリの作成者が公開ライブラリに TypeScript 定義ファイルをバンドルする場合、そのライブラリを使って開発するユーザーは、そのライブラリのAPIをエディタ内ですぐに調べられるようになります。そして、ライブラリのドキュメントを参照することなく、すぐに開発を開始できます。
AngularやVue.jsやnode-github(そして Electron も!)のように多くの人気の高いプロジェクトは自身の定義ファイルをコンパイルし、それをnpm の公開パッケージにバンドルしています。 独自の定義ファイルをバンドルしていないプロジェクトのために、DefinitelyTyped というコミュニティがメンテナンスする定義ファイルを扱う、サードパーティのエコシステムがあります。
バージョン 1.6.10 以降の、Electron のすべてのリリースには独自の TypeScript 定義ファイルが含まれています。 Npm から electron パッケージをインストールすると、 electron.d.ts ファイルがインストールパッケージに自動的にバンドルされます。
Electron をインストールする 最も安全な方法は であり、正確なバージョン番号を使用することです:
npm install electron --save-dev --save-exact
または、 yarn を使っているなら：
yarn add electron --dev --exact
@types/electron や @types/nodeなどのサードパーティの定義を既に使用している場合は、衝突しないように、Electronプロジェクトからそれらの定義ファイルを削除する必要があります。
定義ファイルは、構造化 API ドキュメントから導出します。そのため、Electron の API ドキュメントと常に 一致します。 Electron をインストールするだけで、使用している Electron のバージョンの最新の TypeScript 定義が得られます。
Electron の新しい TypeScript アノテーションをインストールして使用する方法の概要は、以下の短いデモスクリーンキャストをご覧ください。
Visual Studio Codeを使用している場合、これはすでにTypeScript をサポートしています。 Atom、Sublime、vimやその他のエディタにはコミュニティがメンテナンスしているプラグインがあります。
エディターを TypeScript にあわせて設定すると、オートコンプリートサジェスト、インラインメソッド参照、引数チェックなど、コンテキストに対応して動作します。
もしあなたが、TypeScript に詳しくなくかつ学びたいと考えているならこのMicrosoftの導入ビデオ をご覧ください。なぜTypeScriptが作られたか、TypeScriptの動作、使用方法などが説明されます。
また、TypeScript の公式サイトには ハンドブック と プレイグラウンド があります。
TypeScript は JavaScript のスーパーセットなので、既存の JavaScript コードはすでに有効な TypeScript です。 つまり、既存の JavaScript プロジェクトを徐々に TypeScript に移行し、必要に応じて新しい言語機能を追加していくことができるのです。
このプロジェクトは、Electron のオープンソースメンテナのコミュニティの協力なしには実現できませんでした。 Samuel Attard, Felix Rieseberg, Birunthan Mohanathas, Milan Burda, Brendan Forster, また、その他のバグの修正、文書の改善、技術ガイダンスの作成にたずさわっっていただいた多くのメンバーに感謝します。
Electronの新しいTypeScript定義ファイルを使用して問題が発生した場合、 electron-typescript-definitions リポジトリにイシューを提出してください。
ハッピーTypeScripting!
今週は 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 統合、ドラッグアンドドロップ、デスクトップ通知、アプリの読み込みを速くするなどをカバーしています。
Electron の 1.6.3 ベータリリースは macOS の Touch Bar に対する初期サポートを含みます。
新しい Touch Bar API により、ボタン、ラベル、ポップオーバー、カラーピッカー、スペーサを追加することができます。 これらの要素は動的に更新され、対話が起こった際にはイベントが発生します。
この API の最初のリリースに過ぎないため、いくつかの Electron のリリースの間に進化していくでしょう。 詳しい更新内容についてはリリースノートを参照してください。なんらかの問題が生じているか、機能が欠けている場合は、 Issue を開いてください。
このバージョンは npm install electron@beta でインストールできます。詳細は Electron ドキュメントの TouchBar 及び BrowserWindow を参照してください。
@MarshallOfSound による Electron への貢献に大いなる感謝を表します。 🎉
以下は Touch Bar を用いたシンプルなスロットゲームの例です。 Touch Bar の作成方法、アイテムにスタイルを適用する方法、ウィンドウと関連付ける方法、ボタンクリックイベントを扱う方法、ラベルを動的に更新する方法を示しています。
const { app, BrowserWindow, TouchBar } = require('electron');
const { TouchBarButton, TouchBarLabel, TouchBarSpacer } = TouchBar;
let spinning = false;
// リールのラベル
const reel1 = new TouchBarLabel();
const reel2 = new TouchBarLabel();
const reel3 = new TouchBarLabel();
// スピン結果のラベル
const result = new TouchBarLabel();
// スピンのボタン
const spin = new TouchBarButton({
label: '🎰 Spin',
backgroundColor: '#7851A9',
click: () => {
// 既にスピン中であれば無視する
if (spinning) {
return;
}
spinning = true;
result.label = '';
let timeout = 10;
const spinLength = 4 * 1000; // 4 秒
const startTime = Date.now();
const spinReels = () => {
updateReels();
if (Date.now() - startTime >= spinLength) {
finishSpin();
} else {
// スピンするごとに少しづつ遅くする
timeout *= 1.1;
setTimeout(spinReels, timeout);
}
};
spinReels();
},
});
const getRandomValue = () => {
const values = ['🍒', '💎', '7️⃣', '🍊', '🔔', '⭐', '🍇', '🍀'];
return values[Math.floor(Math.random() * values.length)];
};
const updateReels = () => {
reel1.label = getRandomValue();
reel2.label = getRandomValue();
reel3.label = getRandomValue();
};
const finishSpin = () => {
const uniqueValues = new Set([reel1.label, reel2.label, reel3.label]).size;
if (uniqueValues === 1) {
// 3 つの値すべてが同じ
result.label = '💰 Jackpot!';
result.textColor = '#FDFF00';
} else if (uniqueValues === 2) {
// 2 つの値が同じ
result.label = '😍 Winner!';
result.textColor = '#FDFF00';
} else {
// どの値も異なる
result.label = '🙁 Spin Again';
result.textColor = null;
}
spinning = false;
};
const touchBar = new TouchBar([
spin,
new TouchBarSpacer({ size: 'large' }),
reel1,
new TouchBarSpacer({ size: 'small' }),
reel2,
new TouchBarSpacer({ size: 'small' }),
reel3,
new TouchBarSpacer({ size: 'large' }),
result,
]);
let window;
app.once('ready', () => {
window = new BrowserWindow({
frame: false,
titleBarStyle: 'hidden-inset',
width: 200,
height: 200,
backgroundColor: '#000',
});
window.loadURL('about:blank');
window.setTouchBar(touchBar);
});
今週は、Aprile Elcich さんと Paolo Fragomeni さんにお会いして、Electron を搭載した音楽プレイヤー Voltra についてお話を伺いました。
Voltra は、自分の音楽を所有したい人のための音楽プレイヤーです。 すでに持っているものから新しい音楽を見つけたり、購入したりできるストアでもあります。 広告なしで、デスクトップとモバイル向けのクロスプラットフォームです。 情報収集もしません。
音楽を聴くすべての人です。
ラジオは昔からリスナーの大きなシェアを獲得しています。 今や電波からインターネットへと移行しています。 オンデマンドで音楽をレンタルできるようにもなりました - ラジオの復活です! そのために多くの新しい製品やサービスが登場しています。しかし、ストリーミングラジオはまだ、音楽とその視聴手段を掌握されています。
私たちは、自分が持っている音楽というものに全面的にこだわったプロダクトを望みました。 アーティストやレーベルから直接、新しい音楽を発見したり購入したりすることを容易にするものです。
デスクトッププレイヤーは完全に無料です。 あなたの音楽を販売するのも無料です! 当サイトに広告はありません。
このアプリは無料なので、後にオープンソース化するかもしれません。 今のところそれを管理する余裕はありません。 機能や採り入れる方向性についても、とても具体的なアイデアを持っています。 活発なベータコミュニティもあり、そのフィードバックを大切にしています。
プレミアム機能があります!
Voltra Audio Archive は、音楽に特化したクラウドバックアップサービスです。 データブロックを圧縮、共有はしません。 あなたの音楽コレクションは、物理的なバックアップです。
アーティストやレーベル向けの プロ会員 は、アナリティクスやプロアーティストのウェブページなど、より関連する視聴者に届けるためのツールを提供しています。
デザインとユーザビリティは、私たちにとって非常に重要です。 リスナーの皆様に、煩わせない視聴体験を提供したいのです! 興味深い音楽プレーヤーやストアはすでにいくつか出ています。 しかし、その多くは作者が思っているよりも高度で使いづらいのです。 一人でも多くの人が Voltra を利用できるようにしたいです。
また、アーティストやレーベルからの引き抜きはしていません。 これが差別化しているポイントです。 アーティストが自分の音楽を市場に出すための障壁を下げるには、本当に重要なことなのです。
Voltra をデザインするにあたって、ネイティブアプリやウェブの UI の慣習を考慮し、何を削るかということもたくさん考えました。 私たちには、ここ数ヶ月の間で批判的なフィードバックをくれた活発なプライベートベータグループがいます。
人々は、アルバムアートや写真を本当に大切にしているということがわかりました。 多くのプレイヤーはファイルのリストでしかありません。 アルバムアートは物理アルバムを所有するにあたって格好いい所の一つですが、Voltra デスクトップアプリではこの点を強調したいと思いました。
他人のファイルに手を出さないようにも気をつけました。 ファイルを見るだけなので、それ自体は好きな場所に置くことができます。名前を変更したり、移動したりすることはありません。 プロセスが実行されていなくても新規ファイルを追跡できるように、見ているディレクトリの状態を追跡する埋め込みデータベースがあります。
パフォーマンスを重視して、そこに時間をかけました。 最初はフレームワークから始めましたが、バニラ JavaScript に移行しました。 経験上、フレームワークが提供する一般的な抽象化は、導入することによるパフォーマンスの対価や儀式的な記述を上回ります。
現在はとても巨大なコレクションにも対応しています。 大きなコレクションであれば数万もの画像になるでしょう! Node.js のファイルシステムモジュールをレンダラープロセスから直接利用できるようにしたことで、DOM イベントに基づいた大量の画像の超高速での遅延ロード/アンロードが非常に簡単になりました。
一般的に、setImmediate と requestIdleCallback は、UI の応答性を維持しながら多くの処理を実行するにあたってとてつもなく重要な道具です。 具体的には、CPU に依存するタスクを別のプロセスに分散させることで、ユーザーインターフェースの応答性を保つことができます。 たとえば、実際のオーディオコンテキストを別のプロセスに移動し、ビジーな UI による潜在的な中断を IPC を介した通信で回避しました。
ブラウザのサンドボックスはとても制限されていますが、私たちはウェブプレイヤーも開発しています。 しかし、私たちはウェブプレイヤーも開発しています。 そのため、2 つの実装間でほぼ 100% のコードを共有できるのは大きな利点です。
実際には、Swift でネイティブアプリを構築するところから始めました。 一番の問題点は、多くの再発明をしていることでした。 ウェブには世界最大のオープンソースエコシステムがあります。 そこで、すぐに Electron に切り替えました。
最も重要なのは、Electron で一度開発すれば、すべての主要なプラットフォームで Just Work™ するということです。 保証はありませんが、各プラットフォームのためのネイティブコーディングのコストは、Electron を導入するコストを確実に上回っています。
問題解決!: Node.js のネットワークスタックと Chromium のプレゼンテーション層が一緒になっていることこそが、問題解決の秘訣です。
適性: ウェブスタックだけなので、文字通りチーム全員が製品の構築に関われます。
コミュニティ: 高度に組織化されたコミュニティがあり、コミュニケーション手段が発達しています。 このようなサポートを受けながら開発を進められることはとても素晴らしいことです。
Electron に 1 つのパッケージャを推奨してもらいたいです。 Node にとってのパッケージマネージャーと同様に、Electron にとってもパッケージマネージャーは重要です。 ユーザーランドには複数のパッケージャーがあり、それぞれが興味深い機能を備えていますが、それぞれにもバグがあります。 コミュニティのコンセンサスが得られれば、貢献者が費やすエネルギーの方向性が定められるでしょう。
私たちは現在モバイルアプリを開発中で、アーティストやレーベルと協力して彼らの音楽を Voltra ショップに追加しています。 そこのあなた! アーティストやレーベルの方であれば、ぜひご登録ください! 目標の 1000 万曲を達成しましたら、ショップをオープンする予定です。
Electron は、Google のオープンソースプロジェクト Chromium をベースにしています。このプロジェクトは、他のプロジェクトで使用することを想定していません。 この記事では、Electron のライブラリとしての Chromium がどのように構築されているのか、またビルドシステムがどのように進化してきたのかを紹介します。
Chromium Embedded Framework (CEF) は、Chromium をライブラリ化し、Chromium のコードベースに基づいて安定した API を提供するプロジェクトです。 黎明期の Atom エディタや NW.js では CEF を使用していました。
安定した API を維持するために、CEF は Chromium の詳細をすべて隠蔽し、独自のインターフェースで Chromium の API をラップします。 そのため、Node.js をウェブページに統合するような、内部の Chromium API にアクセスする必要があったとき、CEF の利点が障害になりました。
そのため、結局 Electron も NW.js も Chromium の API を直接使うように切り替えました。
Chromium は公式には外部プロジェクトをサポートしていませんが、コードベースはモジュール化されており、Chromium をベースに小さなブラウザを簡単に構築できます。 ブラウザインターフェイスを提供するコアモジュールは、コンテンツモジュールと呼ばれています。
コンテンツモジュールでプロジェクトを開発する際は、Chromium をプロジェクトの部品としてビルドするのが一番簡単です。 このためには、まず Chromium のソースコードをチェックアウトしてから、プロジェクトを Chromium の DEPS ファイルに追加します。
NW.js や Electron の非常に初期のバージョンでは、このようなビルド方法を使用しています。
この欠点は、Chromium がとても大きいコードベースであるため、相応に強力な マシンでビルドする必要があるということです。 一般的なラップトップであれば、5 時間以上かかります。 そのため、貢献できる開発者の数に多大な影響を与え、開発も遅くなりかねません。
コンテンツモジュールのユーザからすれば、ほとんどの場合で Electron が Chromium のコードを修正する必要はないので、Electron のビルドを改善する明白な方法は Chromium を共有ライブラリとしてビルドして Electron 内でそれをリンクすることです。 これにより、開発者は Electron に貢献する際に Chromium すべてをビルドする必要がなくなります。
libchromiumcontent プロジェクトは @aroben によってこのために作成されました。 これは、Chromium のコンテンツモジュールを共有ライブラリとしてビルドし、Chromium のヘッダとビルド済みバイナリをダウンロードできるようにします。 libchromiumcontent の初期バージョンのコードは こちらのリンクに あります。
libchromiumcontent の一部として brightray プロジェクトも生まれました。これはコンテンツモジュールの周りに薄い層を提供します。
libchromiumcontent と brightray を併用することで、開発者は Chromium のビルドの詳細に踏み込まずに素早くブラウザをビルドできます。 そして、プロジェクトをビルドするための高速なネットワークと強力なマシンが必要なくなります。
Electron 以外に、Breach ブラウザ のように、この方法でビルドされた Chromium をベースにしたプロジェクトもあります。
Windows では、単一の共有ライブラリでエクスポートできるシンボル数に制限があります。 Chromium のコードベースが大きくなるにつれ、libchromiumcontent がエクスポートするシンボル数はすぐに制限を超えてしまいました。
これは、DLL ファイル生成時に不要なシンボルをフィルタリングすることで解決しました。 リンカに .def ファイルを供給し、スクリプトで 名前空間の配下のシンボルをエクスポートすべきかどうか判断 することで動作させました。
このアプローチを取ることで、Chromium がエクスポートされたシンボルを新しく追加し続けても、libchromiumcontent はより多くシンボルを削除することで共有ライブラリファイルを生成できるようになりました。
libchromiumcontent の次の段階の話をする前に、まずは Chromium におけるコンポーネントビルドの概念を紹介しておきます。
巨大プロジェクトであるため、Chromium ではビルド時のリンクの段階で非常に長い時間がかかってしまいます。 大抵、開発者がちょっとした変更を加えると、最終的な出力が得られるまで 10 分ほどかかります。 これを解決するため、Chromium ではコンポーネントビルドを導入しました。Chromium 内の各モジュールを分離された共有ライブラリとしてビルドすることで、最終的なリンク作業に費やす時間が気にならないようにしました。
Chromium が成長を続ける中で、Chromium のエクスポートされたシンボルがあまりにも多くなり、コンテンツモジュールや Webkit のシンボルですらも制限を超えるようになりました。 シンボルを削減するだけでは、使用可能な共有ライブラリを生成できなくなったのです。
最終的に、単一の共有ライブラリを生成する代わりに Chromium の生バイナリを頒布 しなければなりませんでした。
先ほど紹介したように、Chromium には 2 つのビルドモードがあります。 生のバイナリを頒布した結果、libchromiumcontent ではバイナリに対して 2 種類のディストリビューションを頒布しなければならなくなりました。 1 つは static_library ビルドと呼ばれるもので、Chromium の通常ビルドで生成された各モジュールすべての静的ライブラリをインクルードします。 もう 1 つは shared_library で、コンポーネントビルドで生成された各モジュールの共有ライブラリすべてをインクルードします。
Electron では、デバッグ版を libchromiumcontent の shared_library 版とリンクしています。これは、ダウンロードが少なく、最終的な実行ファイルをリンクする際に時間がかからないためです。 また、リリース版の Electron は libchromiumcontent の static_library 版とリンクしています。コンパイラはデバッグに重要なシンボルを完全に生成でき、リンカはどのオブジェクトファイルが必要かそうでないかを知っているため、より良い最適化を行えます。
そのため、通常の開発において開発者はデバッグ版をビルドするだけでよく、良好なネットワークや強力なマシンは不要です。 リリース版では、ビルドにより良いハードウェアを必要としますが、より最適化されたバイナリを生成できます。
gn の更新世界的に見ても最大級のプロジェクトであるため、通常のビルドシステムはほとんど Chromium のビルドには適していません。Chromium チームは独自のビルドツールを開発しています。
初期バージョンの Chromium はビルドシステムとして gyp を使用していましたが、動作が遅く、複雑なプロジェクトでは設定ファイルがわかりづらくなるという問題がありました。 何年もの開発の後に、Chromium はビルドシステムを gn に切り替えました。こちらの方がはるかに高速で明確なアーキテクチャとなっています。
gn の改良点の一つは、オブジェクトファイルのグループを表す source_set を導入したことです。 gyp では、各モジュールは static_library か shared_library のいずれかで表現されます。Chromium の通常のビルドでは、各モジュールの静的ライブラリを生成し、最終的な実行ファイルへリンクしていました。 gn を使うと、各モジュールはオブジェクトファイルの集まりだけを生成し、最終的な実行ファイルには全オブジェクトファイルをリンクするだけなので、中間の静的ライブラリファイルは生成されなくなります。
しかし、この改善は libchromiumcontent に大きなお世話でした。なぜなら、中間の静的ライブラリファイルは libchromiumcontent が実際に必要としていたのです。
これを解決する最初の試みは、静的ライブラリファイルを生成するように gn にパッチを当てる ことでした、これで問題は解決しましたが、まともな解決策には程遠いものでした。
2 つ目の試みは、@alespergl による、オブジェクトファイルのリストからカスタムの静的ライブラリを生成する ものでした。 これは、最初にダミービルドを実行して生成されたオブジェクトファイルのリストを収集してから、gn にそのリストを与えて静的ライブラリを実際にビルドするという仕掛けでした。 これは Chromium のソースコードを最小限変更しただけで、Electron のビルドアーキテクチャはそのままです。
このように、Electron を Chromium の一部として構築するのに比べて、ライブラリとして Chromium を構築するにはより多くの労力と継続的なメンテナンスが必要になります。 しかし、後者は Electron のビルドに強力なハードウェアが不要となるため、より多くの開発者が Electron をビルドして貢献できるようになります。 この努力はそれだけの価値があります。
今週の Automattic では WordPress デスクトップ について話をしました。これは、WordPress コンテンツを管理するためのオープンソースのデスクトップクライアントです。
WordPress.com デスクトップアプリ は、コンテンツとデザインに集中できる、シームレスなクロスプラットフォーム体験を提供します。ブラウザタブが無いので、あなたの集中を削いだり、サイト作りを放って違うサイトを見てしまったりすることはありません。 ブラウザーサポートとモバイルアプリを組み合わせることで、どこでもサイトを作れます。
実際、ブラウザで WordPress.com にアクセスしたときと全く同じ技術を使用しています。 しかし、これはすべてローカルでホストされるため、読み込み時間が最小限になります。 Dock や通知などのネイティブ機能の恩恵を活用し、WordPress のサイトとブログにより集中できます。
2015 年末に、WordPress.com の多くを Calypso 形式で再構築しました。これは、React を使用したオープンソースのモダン JavaScript アプリです。 私たちは Electron の検討を開始し、Calypso にいくつかの変更を加えて、ローカルで実行できるようにしました。 これは魅力的な体験で、さらに発展させれば大きな価値があると考えたのです。
我々には Calypso に取り組むチームがいくつかありました。 従来のデスクトップ技術を使用して、これに一致する完全なマルチプラットフォーム GUI クライアントを作成するには、さらに多くの作業が必要でした。 Electron を使用することで、2 ~ 4 人の小さなチームが他のチームの成果を活用する形で数ヶ月でデスクトップアプリを構築できました。
アプリの初期バージョンは非常に速く動作しましたが、デスクトップアプリとして最適な動作をするよう調整するには、より多くの時間がかかりました。 このアプリの大きな課題の 1 つは、実際に自身のマシン上で Calypso のコピーを実行していることです。これは純粋に API が駆動する UI です。 ブリッジ作業が多く、変更は Calypso 自体にフィードバックされました。
さらに、Windows、macOS、Linux バージョンを提供するために、各プラットフォーム向けにアプリをパッケージ化する多大な労力が費やされました。
当時、Electron は比較的新しいものであり、すぐに (時には同日中に!) 修正される問題に直面し続けました。
Electron はすでにデスクトップアプリに必要なもののほとんどを提供しており、私たちが使い始めてから急速に進歩しています。 とはいえ Electron は、スペルチェックや検索/置換など、デスクトップアプリではそのまま複製するのが難しい領域が改善されるべきだと考えます。
また、新しい Chrome 技術の一部を Electron でも使いたいです。 私たちは特に WebVR の実験に熱心です。
Electron を選んだ主な理由は、非常に活発でオープンなコミュニティだからです。それが何よりの強みです。 Automattic は常にオープンソースを信奉しています。 それは私たちの中核理念の一つで、Electron プロジェクトとコミュニティは、非常にオープンかつ前向きであるという中核理念の多くに沿っています。
私たちのモデルの素晴らしいところは、デスクトップアプリが新しい Calypso 機能の恩恵を受けていることです。この機能は絶えず改善されています。 オフラインサポートなどの追加機能をアプリに追加できるようにしたいと思います。オフラインサポートは、アプリを実際にネイティブの領域に持ち込み、システム通知を改善します。
はい、このデスクトップアプリに取り組んだ後、Simplenote チームは Electron を使用して Windows と Linux 向け (ネイティブ Mac クライアントは既存) のデスクトップアプリを構築することにしました。 Simplenote Electron アプリ もオープンソースとなっており、Github で入手できます。
また、Electron を使用する Raspberry Pi との統合も予定しています。
面白そうだと思ったものがあれば、ご連絡お待ちしてます!
署名されたデスクトップソフトウェアを公開するプロセスは、特に Windows において比較的新しいものです。 Windows アプリのコード署名 の記事を作成しました。この記事には、そのプロセスとそれを正しく行うために経験したいくつかの壁について書いています。
今週の特集プロジェクトは、助成金、オープンソース、データセットを配布するための分散ツール Dat です。 Dat は 地理分散されたチーム によって構築と保守がされており、その多くがこの記事の執筆を支援しました。
私たちは P2P と分散システムの良い部分をデータ共有に昇華したいと考えました。 科学データの共有から始め、研究機関、政府、公共サービス、オープンソースチームにも分かれ始めました。
別の見方で考えると、Dat が オープンソース であることを除けば、これは Dropbox や BitTorrent Sync などのような同期アップロードアプリです。 大規模、小規模、中規模、小規模バッチ、大規模バッチデータ向けの強力でオープンソースな非営利データ共有ソフトウェアになることが目標です。
dat CLI ツールを使用方法は、以下のように入力するだけです。
dat share フォルダ/へ/の/パス
すると、dat はそのフォルダのリンクを作成します。これはそのフォルダを他人へ送信する際に使用できますが、中央サーバーやサードパーティがあなたのデータにアクセスすることはありません。 BitTorrent と異なり、誰が何を共有しているかを盗聴することも不可能です (詳細は Dat Paper のドラフトを参照してください)。
Dat デスクトップ は、コマンドラインを使用できない、または使用したくない人が Dat に触れられる手段です。 マシン上で複数の Dat をホストし、ネットワーク経由でデータを提供できます。
私たちは Project Svalbard というコードネームの物に取り組んでおり、これは紛失のリスクに晒される政府の気候データをバックアップするために活動している DataRefuge というグループに関連しています。 Svalbard は、植物 DNA の巨大な地下バックアップ保管庫を持つ北極圏のスヴァールバル世界種子貯蔵庫にちなんで名付けられました。 私たちの場合は、公開科学データセットの巨大なバージョン管理コレクションといったところです。 メタデータを熟知して信頼できれば、分散ボランティアデータストレージネットワーク のような素晴らしいプロジェクトをも構築できます。
CACivicData は、政治資金を追跡するカリフォルニア州のデータベース CAL-ACCESS からのダウンロードを毎日提供するオープンソースアーカイブです。 毎日リリース していますが、これは各 zip ファイルのいたる所で大量の重複データをホストしているということです。 Dat リポジトリが、特定のバージョンを参照したり新しいバージョンへ更新したりするときに必要な手間と帯域幅の量を減らした形でデータホストできるように取り組んでいます。
これはまだ具体案ではありませんが、コンパイル済み Electron アプリを Dat リポジトリに配置し、Electron の Dat クライアントを使用してビルドされたアプリバイナリの最新の差分を落としすことでダウンロード時間を節約するという面白そうなユースケースがあります。これにより、サーバーの帯域幅コストも削減できます。
P2P ネットワークを介してデータを共有、更新したい人。 データサイエンティスト、オープンデータのハッカー、研究者、開発者。 私たちの思いも寄らない素晴らしいユースケースをお持ちであれば、私たちはそのフィードバックを真摯に受け入れます。 Gitter Chat まで、何でもお問い合わせください!
ユーザーアカウントとメタデータの公開です。 私たちは datproject.org にデプロイする Dat レジストリのウェブアプリ開発に取り組んでいます。これはメタデータディレクトリになり、データをオンライン上のどこにでも置くことができます (全データが集中ホストされる NPM や GitHubとは対照的に、ソースコードが十分小さいため 1 つのシステムにすべてを収めることができます)。 多くのデータセットは巨大なので、(BitTorrent トラッカーの仕組みと同様に) フェデレーションレジストリが必要です 。 データ共有プロセスを円滑にするため、Dat デスクトップのレジストリを使用してデータセットを簡単に検索または公開できるようにしたいと考えています。
もう 1 つの機能はマルチライター/共同フォルダーです。 ブランチを用いて共同作業を行うという大きな計画があります。これは、データセットの共用を中心に設計されている場合を除けば git と同じです。 しかし、現在の私たちは全体的な安定性とプロトコルの標準化に取り組んでいます!
Dat は Node.js を使用して構築されているため、自然な統合に適していました。 これ以外にも、科学者、研究者、政府関係者は施設特有の構成を使用することを余儀なくされ、ユーザーはさまざまなマシンを使用する可能性があります。 つまり、Mac と同様に Windows と Linux をターゲットにできる必要があります。 Dat デスクトップは、それを簡単に実現してくれます。
人々が何を求めているのかを把握することです。 最初は表形式のデータセットから始めたのですが、解決するには少し複雑な問題だったため、ほとんどの人がデータベースを使っていないことに気づきました。 プロジェクトの途中で、ファイルシステムを使用するためにすべてスクラッチから設計し直して以来、後退していません。
以下のような一般的な Electron のインフラ問題にも遭遇しました。
Dat デスクトップの 'フロントエンド' コードでは Browserify と素晴らしい Browserify Transform をいくつか使用しています (ネイティブの require があるのにバンドルしているので、ちょっと変な感じですが、Transform が欲しいのです)。 CSS をより管理しやすくするために、Sass から sheetify へ切り替えました。 このおかげで、CSS をモジュール化でき、依存関係を共有したコンポーネント指向アーキテクチャの UI に移行するのが容易になりました。 例えば、dat-colors にはすべての色が収まっており、すべてのプロジェクトで共有されています。
私たちはいつも標準と最小限の抽象化の大ファンです。 インターフェイス全体は、いくつかのヘルパーライブラリを使用した上で、通常の DOM ノードで構築されています。 これらのコンポーネントの一部を、ローレベルで再利用可能なコンポーネントのライブラリ base-elements に移行し始めました。 私たちの技術のほとんどもそうなのですが、正常になるまで移行を反復し続けています。チームとしては正しい方向に向かっていると思います。
最大の痛手はネイティブモジュールだと考えています。 Electron 向けにモジュールを npm でリビルドする必要があるため、ワークフローが複雑になります。 私たちのチームは prebuild というモジュールを開発しました。これはビルド済みのバイナリを扱うもので、Node ではうまく機能していましたが、Electron のワークフローではインストール後にカスタムステップとして大抵 npm run rebuild が必要でした。 これは煩わしかったです。 これに対処するため、すべてのプラットフォームのコンパイル済みバイナリ版を npm tarball の中にバンドルするという戦略に最近切り替えました。 これは tarball が大きくなるということです (ただこれは .so ファイル - 共有ライブラリで最適化できます)。このアプローチなら install の後にスクリプトを実行する必要がなくなり、npm run rebuild のパターンを完全に回避できます。 npm install だけで Electron 向けに正しく動作するということです。
API はかなりよく考えられていて、比較的安定しているようです。上流の Node リリースの最新状態の維持にこれ以上ない良い仕事をしてくれています!
ネイティブモジュールを使うなら、prebuild を試してみてくれ!
ツイッターで @dat_project をフォローするか、メールマガジン に登録してください。
今週、Slack のデスクトップエンジニアであり、Ghost 出版プラットフォームの Electron クライアントである Ghost Desktop のメンテナー Felix Rieseberg と談話しました。
Ghost は、モダンなオンライン出版物を作成し稼働するための、完全にオープンソースの改造可能なプラットフォームです。 Zappos から Sky News まで、ブログ、雑誌、ジャーナリストを支えています。
Ghost は、プロ向け出版物作成だけに特化した新しいプラットフォームを作成する Kickstarter キャンペーンが非常に成功した後の、2013 年 4 月に設立されました。 私たちの使命は、世界中の独立したジャーナリストや作家のために最高のオープンソースツールを作成し、オンラインメディアの未来に真の衝撃を与えることです。 シンプルで、より焦点を絞ったエクスペリエンスを提供します。このエディタは、可能な限り最高の執筆体験を提供することだけを目的に設計しました。
従来の WordPress と比較すると、シンプルで合理化されたエクスペリエンスを提供しています。セットアップとメンテナンスが簡単で、すべての大事な機能が付属しており、劇的に高速です。 他のオンラインプラットフォームと比べても、Ghost はライターがコンテンツの完全な所有権と制御を得ることで完全なカスタマイズができ、執筆者は出版物を中心としたビジネス構築ができます。
これは私たちにおいて大事なところです。Ghost は独立した非営利組織です。 言論の自由は重要であるという信念の下、モダンなジャーナリズムとブログのための出版ツールを構築します。 当ソフトウェアは 自由なオープンソースライセンス でリリースされており、当社のビジネスモデルは 完全に透明です。当社の法的構造では、収益の 100% が Ghost の改善に再投資されます。
Ghost デスクトップなら、ライターは複数のブログを一度に管理でき、執筆に集中できます。 一般的な執筆ショートカットのような単純なものでも、ブラウザでは実現できませんがデスクトップアプリならできます。 他のアプリケーションが ディープリンク経由のブログ と直接通信できるようにします。
今年、10 人のフルタイムのゴーストチーム全体が 3 つまでの独立した出版物の成長を支援し、その活動に 45,000 ドルのリソースを費やすという心躍る計画をしています。 これを Ghost ジャーナリズム版 と呼びます。
約 3 年半にわたって、独立系出版社向けにウェブの次世代優良プラットフォームとして Ghost を構築してきましたが、今になって非常に興味深い変曲点に到達しました。 この旅は、誰でも使えるようなシンプルで上手く設計されたブログプラットフォームを作成するところから始まりました。 旅はいつも一歩ずつ進みました。
長期的には、Ghost を世界最高のジャーナリズム向けのとてつもないプラットフォームにしたいと考えています。人々を引き付ける機能を構築する必要があるのです。 今年はそれだけに集中する、と非常に意識的に決定しています。
Ghost はバックエンドとフロントエンドの両方で JavaScript とNode.js を使用するため、同じ技術と経験が利用できます。これにより、チームはより迅速な行動とより多くの構築ができ、やがてより良いエクスペリエンスを提供できます。 さらに、macOS、Windows、Linux バージョン間でアプリのコードの 95% 以上を共有できるため、プラットフォームごとに 1 つずつコードベースを維持する必要がなく、優れたコアユーザーエクスペリエンスの構築に集中できます。
最も難しいサービスを一つ挙げるとすれば、スペルチェックです。数あるオンラインサービスは簡単に利用できますが、ユーザーのプライバシーと自主性を守りながら複数言語のテキストを正しくスペルチェックするのは、簡単な課題ではありません。
Electron がオペレーティングシステムのネイティブのスペルチェック機能をアプリから使えるようにすることを望みます。 <input> フィールドが NSTextView と同じサービスを受けられる世界を夢見ていますが、それがいかに難しいかはよく知っています。
JavaScript は、数え切れないほどのツールとフレームワークを含む広大なエコシステムだと有名で、その利便性は誇張しかねます。 Electron でのアプリ構築は、ウェブアプリ構築より ほんの少し 難しいだけです。これは驚くべき偉業でしょう。
Ghost デスクトップも進行中のプロジェクトであり、まだまだ完成には程遠い状態です。 ここのところ、完全なオフラインモードをユーザーに提供することについて議論しており、かなり実現に近づいています。 他に手を加える注目すべき箇所は、他のテキスト編集アプリ (Word や Atom など) 向けの拡張と統合です。最終的には、ユーザーが好みのツールで記事を書けるようにします。 一般に、オフラインモード機能を搭載するにあたって、オペレーティングシステムとのより密接な統合方法を探します。 面白そうだと思っていただけたのであれば、ぜひご参加ください!
私は Kap、Felony、Visual Studio Code の大ファンです。
👻