本記事はElectron Advent Calendar 2016 5日目の記事です。

InkdropというElectron製ノートアプリを作っています。
このアプリにはプラグイン機構による拡張性を備えているのですが、これはatomからコードを拝借して実装しました。
atomはMITライセンスによるオープンソースのテキストエディタです。
その際に得た知見を共有したいと思います。
これをきっかけにあなたのElectronアプリ改善のお役に立てれば幸いです。
atomのパッケージを作ったことのある方ならすんなり理解できると思います。

event-kit

全体を通してイベント駆動の処理はevent-kitと呼ばれるモジュールが使われています。
一見車輪の再発明っぽいですが、良いところがあります。

イベント購読APIの基本的な実装方法は以下の通りです：

import { Emitter } from 'event-kit'

class User {
  constructor () {
    this.emitter = new Emitter()
  }
  onDidChangeName (callback) {
    this.emitter.on('did-change-name', callback)
  }
  setName (name) {
    if (name !== this.name) {
      this.name = name
      this.emitter.emit('did-change-name', name)
    }
    return this.name
  }
  destroy () {
    this.emitter.dispose()
  }
}

イベント購読の利用側は以下のように実装します：

const subscription = user.onDidChangeName(name => console.log(`My name is ${name}`))
// 購読解除
subscription.dispose()

event-kitでは、複数の購読をまとめてキャンセルできます。これが結構便利。

import { CompositeDisposable } from 'event-kit'

const subscriptions = new CompositeDisposable()
subscriptions.add(user1.onDidChangeName(name => console.log(`User 1: ${name}`)))
subscriptions.add(user2.onDidChangeName(name => console.log(`User 2: ${name}`)))

// 購読解除
subscriptions.dispose()

node標準のEventEmitterだとremoveListenerにコールバック関数を渡さないといけなくて面倒ですが、これならいちいち関数を保存しておく必要がありません。

CommandRegistry

ソースコード: https://github.com/atom/atom/blob/master/src/command-registry.coffee

atomはそれ自体が多くのパッケージで出来ています。
そのため、モジュール同士の疎結合化がかなり考えぬかれて設計されています。
その中核をなすのがCommandRegistryです。
これはコマンド名と対応する処理のペアを管理するモジュールです。
たとえば、application:quitやcore:copyといったものがあります。
モジュール間でやりとりされるメッセージみたいなものと考えてもいいかもしれません。
具体的には、主にショートカットの入力やメニューの実行に使われています。
エディタ内での方向キーすらcore:move-upといったコマンドになっています。
この仕組みによって高いカスタマイズ性をも実現しています。

もちろん、コマンドのイベント検知には前述のevent-kitが使われています。

MenuManager

ソースコード: https://github.com/atom/atom/blob/master/src/menu-manager.coffee

Electronアプリはマルチプラットフォームで動作しますが、プラットフォームに合わせた挙動は自分で実装しなければなりません。
その一つにメニューが挙げられます。

atomでは以下のようにCSON形式でメニューの項目とそれに対応するコマンドが列挙されています：

'menu': [
  {
    label: 'File'
    submenu: [
      { label: 'New Window', command: 'application:new-window' }
      { label: 'New File', command: 'application:new-file' }
      { label: 'Open…', command: 'application:open' }
      { label: 'Add Project Folder…', command: 'application:add-project-folder' }
      { label: 'Reopen Last Item', command: 'pane:reopen-closed-item' }
      { type: 'separator' }
      { label: 'Save', command: 'core:save' }
      { label: 'Save As…', command: 'core:save-as' }
      { label: 'Save All', command: 'window:save-all' }
      { type: 'separator' }
      { label: 'Close Tab', command: 'core:close' }
      { label: 'Close Pane', command: 'pane:close' }
      { label: 'Close Window', command: 'window:close' }
    ]
  }
...

https://github.com/atom/atom/tree/master/menus
上記にmacOS、linux、windowsの3種類のメニュー定義データがあります。

Electronにもテンプレートからメニューを定義するAPIがあります。
MenuManagerは単なるテンプレートにとどまらず、コマンドのハンドラの有無で自動で項目を無効/有効を切り替えたりしてくれます。
また、パッケージによって新たにメニューを部分的に追加したり削除しやすいように作られています。

atom-keymap

ここで、キーボードショートカットの定義が無いことに気づいたかもしれません。
atomではメニューとショートカットさえも疎結合にできています。
各キー入力とコマンドのペアをkeymapと呼び、別途定義されています。
この仕組みはatom-keymapというモジュールによって実現しています。

atomのkeymapはプラットフォームごとにこちらに定義されています: https://github.com/atom/atom/tree/master/keymaps

下記のように、キーの組み合わせとコマンドの対で定義されています：

'atom-text-editor':
  # Platform Bindings
  'home': 'editor:move-to-first-character-of-line'
  'end': 'editor:move-to-end-of-screen-line'
  'shift-home': 'editor:select-to-first-character-of-line'
  'shift-end': 'editor:select-to-end-of-line'

atom内部では、window.documentのkeyupとkeydownイベントを受け取って対応するコマンドをdispatchしています。
このkeymap機構によって、プラットフォームに合わせたキー操作、新しいコマンドの定義、ショートカットの変更などがとても容易になります。

再利用しやすかった

紹介したモジュールはatomの中核でありそれぞれ依存関係にあるので、一部だけ導入するというのは難しいでしょう。
しかし中核とそれ以外で完全に疎結合なので、比較的アプリのコードと馴染ませやすいと思います。
実際に再利用するにあたって、あまりモジュール自身のコードをいじる必要はありませんでした。
もしこれからElectronのアプリを作るという方は、一度見てみて損はないと思います。

パッケージ機構そのものはさすがに複雑で説明が大変なので、また機会があれば説明したいと思います。

md.renderer.rulesを書き換える

以下のようにlink_openという名前のルールを書き換えることで、target="_blank"をデフォルトに出来る。

const md = new MarkdownIt()

// Remember old renderer, if overriden, or proxy to default renderer
var defaultRender = md.renderer.rules.link_open || function(tokens, idx, options, env, self) {
  return self.renderToken(tokens, idx, options)
}

md.renderer.rules.link_open = function (tokens, idx, options, env, self) {
  // If you are sure other plugins can't add `target` - drop check below
  var aIndex = tokens[idx].attrIndex('target')

  if (aIndex < 0) {
    tokens[idx].attrPush(['target', '_blank']) // add new attribute
  } else {
    tokens[idx].attrs[aIndex][1] = '_blank'    // replace value of existing attr
  }

  // pass token to default renderer.
  return defaultRender(tokens, idx, options, env, self)
}

参考

• Best way to override renderer rules? ? Issue #46 ? markdown-it/markdown-it
• markdown-it design principles

まず以下のようにデフォルトの挙動をキャンセルする。

document.ondragover = document.ondrop = function (e) {
  e.preventDefault()
}

次に任意のDOMにdropイベントリスナを登録する。

document.body.addEventListener('drop', function (e) {
  console.log('file dropped:', e.dataTransfer.files[0]);
});

以下のようなFileオブジェクトが取得できる。

{
  lastModified: 1472114272000
  lastModifiedDate: Thu Aug 25 2016 17:37:52 GMT+0900 (JST),
  name: "07-recovering-your-password_linux01.png",
  path: "/Users/.../07-recovering-your-password_linux01.png",
  size: 103790,
  type: "image/png",
  webkitRelativePath: ""
}

ld: library not found for -lgcc_s.10.5
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Release/.node] Error 1

gccなのでXCodeが関連している模様。
関連情報:

• XCode 7: library not found for -lgcc_s.10.5 ? Issue #2933 ? nodejs/node

I got the same error here, a possible error after upgrading xcode version.
I fix it with a temp solution:
cd /usr/local/lib sudo ln -s ../../lib/libSystem.B.dylib libgcc_s.10.5.dylib

とりあえず以下で対処できるらしい：

cd /usr/local/lib;
sudo ln -s ../../lib/libSystem.B.dylib libgcc_s.10.5.dylib 

んーむ・・

時代はSPA

スマホの普及で、モバイルネットワークなのに画面遷移ごとにページのリロードなんてユーザはじれったくて待ってくれない。
だから、SPA(Single Page Application)という手法が出るのは必然だ。
これは、画面遷移に応じて必要なデータを読み込み、必要な部分だけを再描画する手法だ。

言語のスイッチングコストは予想以上に高い

昔と比べて、ウェブサービスの開発コストはほんとうに下がった。
だから、一人でサービスを作る人もこれから格段に増えるに違いない。

一人でSPAを組む時にしんどいのが、言語のスイッチングコストだ。
Railsで組んでいるなら、RubyとJavaScriptの２つを並行して書かなければならない。

言語はそれぞれ独特の作法があり、いいコードを書くにはそれなりの鍛錬が必要だ。
しかしいかに熟練していたとしても、常に複数言語のテクニックやライブラリにキャッチアップするのは大変だ。

node.jsは”お一人様向け”

node.jsは、サーバサイドで動くJavaScript環境だ。
つまり、スイッチングコストが圧倒的に低い。

もちろん、DOM操作やファイル操作など、クライアントとサーバサイドでは相互で通用しないテクニックもある。
でもそれは言語の問題ではなく、アーキテクチャの問題だ。

一人で効率よく開発したいなら、node.jsをお薦めする。
フレームワークはどれがいい？
そんなのは今どきどれもよく出来ているから、「住めば都」だ。

tl;dr

• MongoDBではv2.6から cursor.maxTimeMS()によって処理をタイムアウトさせられる
• 各ドライバから使用可能
• mongooseでは mongoose.Query#maxTime メソッドで指定可能

サーバ側で処理をタイムアウトさせるには

MongoDBでは、v2.6からサーバ側で処理の実行タイムリミットを設定できます。
処理のタイムリミットは、cursor.maxTimeMS() メソッドを呼ぶことで設定できます。
この maxTimeMS を設定すると、指定したタイムリミットを超えて検索やアップデートが実行された場合、その処理を中止します。

以下のようにコンソールで試せます：

db.collection.find({description: /August [0-9]+, 1969/}).maxTimeMS(50)

各ドライバでのmaxTimeMSの使用方法

各ドライバといっても調べたものだけを列挙しておきます。

PHP

• MongoCursor::maxTimeMS

例：

$cursor = $collection->find();
$cursor->maxTimeMS(2000);

try {
    $results = iterator_to_array($cursor);
} catch (MongoExecutionTimeoutException $e) {
    echo "query took too long!";
}

ちなみに、PHPにはMongoCursor::timeout もあります。
このメソッドはクライアント側でタイムアウト処理を行うものです。
サーバ側では処理をキャンセルしないので、注意です。

node.js

こちらに詳しく書いてあります。
例:

var MongoClient = require('mongodb').MongoClient;

MongoClient.connect("mongodb://localhost:27017/test", function(err, db) {
    // Get an aggregation cursor
    var cursor = db.collection('data')
        .find({"$where": "sleep(1000) || true"})
        .maxTimeMS(50);

    // Get alll the items
    cursor.toArray(function(err, items) {
        console.dir(err);
        console.dir(items);
        db.close();
    });
});

mongooseでタイムアウトさせるには

MongoDBのnode.jsにおけるODM(Object Data Mapping)のmongooseでもmaxTimeMSに対応しています。
v3.8.13 から利用できるようになりました。
該当の変更は こちら。
実際には子分モジュールの mquery で実装されています。

使い方はシンプル：

var mongoose = require('mongoose');
mongoose.connect('mongodb://localhost/test');

var Cat = mongoose.model('Cat', { name: String });
Cat.find({name: 'Zildjian' }).maxTime(1000).exec(function(err, docs) {
    console.log(err); // --> { [MongoError: operation exceeded time limit] name: 'MongoError' }
});

operation exceeded time limit というメッセージのエラーが得られます。

このように、mongoose.Query オブジェクトを返すメソッドでmaxTimeメソッドが使えます。
Model#saveメソッド、Model#remove では残念ながら使えないようです。

エラーを判別しにくい問題

Errorオブジェクトにはエラー種別を明示的に判別するコードがありません。
そのため、とても不安な方法ですがエラーメッセージで判別する方法しか見当たりません(他に良い方法をご存知の方がおられましたらぜひご教授ください)。
メッセージによるタイムアウト判別は以下のようになります：

if(err.message === 'operation exceeded time limit') {
   // retry
}

なぜPHPにはMongoExecutionTimeoutExceptionがあるのにnode.jsでは無いんだ？

参考

• cursor.maxTimeMS() ? MongoDB Manual 2.6.4
• Mongo Driver and Mongo DB 2.6 Features ? MongoDB Node.JS Driver 1.4.9 documentation
• mongoose/History.md at master ? LearnBoost/mongoose
• bump mqurey to 0.9.0 to use maxTimeMS by yuukinajima ? Pull Request #2102 ? LearnBoost/mongoose
• aheckmann/mquery
• PHP: MongoCursor::maxTimeMS – Manual

DynamoDBがJSONデータをサポートした

今月(2014年10月10日)のことですが、Amazon DynamoDBがいろいろアップデートしました：

• Amazon DynamoDBのアップデート ? JSON、 拡張された無料試用枠, フレキシブルスケーリング、 より大きなアイテム

その中でもJSONデータサポートは注目のアップデートです。
これは具体的にどういうことか説明します。
DynamoDBはスキーマレスのNoSQLです。
これまで、カラム（属性）には単一データまたはセット（重複を許さない配列）が格納できました。
しかしながら、入れ子構造は格納できませんでした。
JSONデータのサポートとは、この入れ子構造が取り扱えるようになったということです。
つまり、MongoDBのように、JSON形式のデータをそのままデータベースに格納できるようになったのです。

既存ODMライブラリに手を加えて対応させた

node.js向けのODMライブラリにはいくつかあります。
vogels はその中でもいい感じのライブラリです。
しかし残念ながら、あまり精力的にメンテナンスされてるとは言いがたく、今回のアップデートに対してもまだ対応していない様子です。
そこで、自分で対応させてみることにしました。
フォークしたものがこちらにあります：

• noradaiko/vogels

いちおうプルリクしてありますが、マージされるのを待てません笑

vogelsの使い方

まずは基本的な使い方をドキュメントから引用してざっくり説明します。
次に、入れ子構造のデータを扱うための方法を説明します。

設定

AWS SDKのキーをファイルから設定します。

var vogels = require('vogels');
vogels.AWS.config.loadFromPath('credentials.json');

もちろん直接値を渡して設定もできます。

var vogels = require('vogels');
vogels.AWS.config.update({accessKeyId: 'AKID', secretAccessKey: 'SECRET'});

基本

データモデルの定義方法は以下のとおりです：

var Account = vogels.define('Account', function (schema) {
  schema.String('email', {hashKey: true});
  schema.String('name').required(); // name attribute is required
  schema.Number('age'); // age is optional
  schema.Date('created', {default: Date.now});
});

ハッシュとレンジキーを指定しての定義：

var BlogPost = vogels.define('Account', function (schema) {
  schema.String('email', {hashKey: true});
  schema.String('title', {rangeKey: true});
  schema.String('content');
  schema.StringSet('tags');
});

書き込み：

Account.create({email: 'foo@example.com', name: 'Foo Bar', age: 21}, function (err, acc) {
  console.log('created account in DynamoDB', acc.get('email'));
});

読み込み：

Account.get('test@example.com', function (err, acc) {
  console.log('got account', acc.get('email'));
});

簡単ですね！
クエリやセカンダリインデックスなどの使い方はドキュメントを参照してください。

入れ子構造の取り扱い方

ここからが本題です。
DynamoDBでは、MapとListという新しいデータ型を追加することで入れ子構造の格納を実現しています。
先述の通り、vogelsではスキーマを定義して、それに合わせたデータを出し入れします。
vogelsで入れ子構造を取り扱うには、このスキーマをMapとListを使用して定義します。

Map

MapはJavaScriptでいうオブジェクトです。まずは以下の例をみてください。

var Photo = vogels.define('Photo', function (schema) {
  schema.String('userid', {hashKey: true});
  schema.Map('location');
});

Photo.create({userid:'john', location: {name: "東京タワー", latitude:35.65858, longitude: 139.745433}}, console.log);

この例では、Photoモデルのlocation属性がMap型として定義されています。
中身には、場所に関するデータが格納されています。
単純ですね！
もちろん、このlocationの中身もスキーマで定義できます。

var Photo = vogels.define('Photo', function (schema) {
  schema.String('userid', {hashKey: true});
  schema.Map('location', function(schema) {
    schema.String('name');
    schema.String('latitude');
    schema.String('longitude');
  });
});

Mapの中に更にMapを格納することもできます。
Mapの中身のスキーマを定義しなかった場合、未定義となり制約は与えられず、自由なフォーマットのデータが格納できます。

List

ListはJavaScriptでいう配列です。使い方は以下のとおり。

var Photo = vogels.define('Photo', function (schema) {
  schema.String('userid', {hashKey: true});
  schema.List('likes');
});

Photo.create({userid:'john', likes: ['emily']}, console.log);

こちらも直感的ですね。
Listの各要素の形式が同じで尚且つMap型の場合は、以下のように要素のスキーマを定義できます。

var Photo = vogels.define('Photo', function (schema) {
  schema.String('userid', {hashKey: true});
  schema.List('likes', function(schema) {
    schema.String('userid');
    schema.Date('likedAt');
  });
});

MongoDBとの併用はかなりイケてる？

JSON形式のドキュメントがそのまま格納できるDBMSとして、有名なのはMongoDBです。
今回のJSONサポートによって、DynamoDBはMongoDBと同じフォーマットでデータを取り扱えるようになりました。
これは、「併用しやすい」という事です。
併用すると何が嬉しいか、考えてみます。

DynamoDBは運用コストが低くスケーラビリティが高いのがウリのデータベースです。
その代わり、検索の柔軟性を犠牲にしています。
それに対してMongoDBは検索の柔軟性が高いのが強みです。
しかしながら、DaaSは価格が高いし自分で運用するのは大変です。
DynamoDBとMongoDBを併用することによって、互いの弱みを補い合えるかもしれません。

MongoDBを既に使っていた人にとっては、すごい良いニュースではないでしょうか。

メモ。
検索しても古いやりかたしか出てこなかったので。

mochaはnode.js製のテストフレームワークです。
CoffeeScriptはJavaScriptのトランスパイラです。

CoffeeScriptで書いたテストをmochaで実行できるのですが ドキュメント によると、 CoffeeScript 1.7からそのコマンドが変わっています。

coffee-script is no longer supported out of the box. CS and similar transpilers may be used by mapping the file extensions (for use with –watch) and the module name. For example –compilers coffee:coffee-script with CoffeeScript 1.6- or –compilers coffee:coffee-script/register with CoffeeScript 1.7+.

というわけで、以下のように実行します：

$ mocha --compilers coffee:coffee-script/register

古いやり方で出るエラー

$ mocha --compilers coffee:coffee-script
/.../node_modules/coffee-script/lib/coffee-script/coffee-script.js:195
          throw new Error("Use CoffeeScript.register() or require the coffee-s
                ^
Error: Use CoffeeScript.register() or require the coffee-script/register module to require .coffee.md files.
  at Object._base.(anonymous function) [as .coffee] (/.../node_modules/coffee-script/lib/coffee-script/coffee-script.js:195:17)
  at Module.load (module.js:355:32)
  at Function.Module._load (module.js:310:12)
  at Module.require (module.js:365:17)
  at require (module.js:384:17)
  at /.../node_modules/mocha/lib/mocha.js:184:27
  at Array.forEach (native)
  at Mocha.loadFiles (/.../node_modules/mocha/lib/mocha.js:181:14)
  at Mocha.run (/.../node_modules/mocha/lib/mocha.js:393:31)
  at Object.<anonymous> (/.../node_modules/mocha/bin/_mocha:380:16)
  at Module._compile (module.js:460:26)
  at Object.Module._extensions..js (module.js:478:10)
  at Module.load (module.js:355:32)
  at Function.Module._load (module.js:310:12)
  at Function.Module.runMain (module.js:501:10)
  at startup (node.js:124:16)
  at node.js:842:3

Mongoose(MongoDBのODM)を使って、コレクションからほんの10万ほどのドキュメントを処理するスクリプトを実行した時でした。処理が固まってしまうのです。なぜでしょう？

各ドキュメント処理では、コールバックを伴う非同期的な処理を含みます。
問題のCoffeeScriptのコードは以下のようなイメージです：

Foo.find()
    .sort value:-1
    .stream()
    .on 'data', (d)->
        someTask d

someTask = (d)->
    doAwesomeJob (result)->
        console.log "Great!"

モデルFooのドキュメントを全て読み込み、各ドキュメントをストリームに流し込んでいます。
メモリを節約するためにストリームの手法を採用しています。
doAwesomeJobは、例えばAPIを叩くとか、そういう非同期な処理です。
しかし、doAwesomeJobのコールバック関数がなかなか呼ばれない。遅い。ついには全く呼ばれなくなる。

イベントループのキューが溢れている

Node.jsアプリケーションはシングルスレッドです。
下図のように、イベントループ機構が備わっていて、Event Queueに溜まった処理キューを順次消化していく仕組みになっています。

(via http://misclassblog.com/interactive-web-development/node-js/)

つまり、Node.jsはひとつずつしかキューを処理できないのです。
上記スクリプトで、ストリームのイベントのInvocationが、大量にこのイベントキューに押し寄せている事を想像してください。
doAwesomeJobのコールバックは、その非同期処理の完了時点で最後列にエンキューされます。
しかし、非同期処理の間にドキュメント読み出しイベントの処理キューが大量に溜まります。
その結果、doAwesomeJobのコールバックが呼ばれるまでに時間がかかってしまっているのでした。

似た問題に直面している人がいました。

• rabbitmq flooding nodejs app

RabbitMQのメッセージキューがいちどに大量に来た時に、イベントループのキューが溢れるようです。
問題は僕のケースより少し深刻なようです。見なかったことにしましょう。

ストリームを分割しよう

溢れるのなら、分割すればいいですね。
以下のように変更を加えました：

processNext = (offset, num, on_completion)->
    i = 0, j = 0, closed = false
    Foo.find()
        .sort value:-1
        .skip offset
        .limit num
        .stream()
        .on 'data', (d)->
            ++j
            someTask d, ->
                ++i
                if i==j && closed
                    processNext offset+i, num, on_completion
        .on 'close', ->
            closed = true
            on_completion() if j==0

someTask = (d, callback)->
    doAwesomeJob (result)->
        console.log "Great!"
        callback()

processNext 0, 100, ->
    console.log "done!"

ドキュメントを100個ずつ読み出して、処理して、終わったら次の100個・・というフローに変更しました。
今のところ、これで上手く動いています。

でもこのコードは少し汚いので、よりエレガントに書くためにasyncを使うことをお薦めします。
drainで完了をフックするといいと思います。

このストリームの分割では、ストリームを処理している間にドキュメントが追加・削除される事を想定していません。
コレクションの変更まで考慮する場合は、想定される変更内容によって変わると思います。

ご参考まで！