東京Node学園8に参加してきました

Node.js

「パフォーマンスチューニングを行うことができるparamtuner」@muddydixon

  1. 自動的にパフォーマンスチューニングしてくれるツール
  2. Node.js製で。モジュールとしても利用可能
  3. Strategyでパラメーター空間の探索アルゴリズムを変更可能
  4. データをストリームで受けてリアルタイムで統計処理できるモジュール
  5. 時系列データの欠損を補完してくれるツールも作っています

「NodeとPromiseと時々関数型」 @okapis

  1. Javascriptコミュニティに道場破りに来ました
  2. Scalaの非同期RPCライブラリ「Finagle」の基本はfuture/promise
  3. 「Node.jsはコールバックではなくpromissを採用すべきだった」というブログが公開される
    1. コールバックは処理をモジュール化するのが難しい
    2. 逐次処理か非同期処理の区別が必要
    3. ネスト地獄は本質ではない
  4. 正しく動くコードを書くのが大変
  5. メンテナンス性が低い
  6. プロミス
    1. 完了していないかもしれない計算の入った箱
    2. 計算が完了すると特定の処理をしてくれる場合が多い
  7. 言語やライブラリによって機能や実装、名前も異なる
  8. 「とりあえず関数型プログラミングと融合したケースを扱います」
    1. 手続き型はhow、関数型はwhat
    2. 値同士の関係を表現するのに関数を使う
  9. プロミスで記述することで、処理の順番はコンピュータに考えてもらうことができ、非常にシンプルになる
  10. プロミスは難しい?
    1. 動作を調べる必要があるのでは？
      1. シンプルである方が大事
  11. まとめ
    1. コールバックは簡単
    2. だけど拡張性に乏しい
  12. 関数型はプログラマの芸風を広げてくれる
  13. 会場から
    1. 元々Node.jsはプロミスを採用していた
    2. javascriptの書き方として嫌悪されていた
      1. エラー処理のために、結局コールバックが必要
      2. エラーコールバックの数が現実のアプリケーションでは増えて汚くなる
      3. 結局、コールバックの第一引数にエラーを使うことに
    3. 現在はベースはシンプルにして、その上で好きなものを実装する形に

Let It CRASH @koichkさん

  1. Earlangの耐障害性のポリシー
    1. あえて失敗を備えない
    2. 特別なプロセスが再起動させる
    3. エラー処理とアプリが分離する
  2. NodeではuncaghtException
    1. そのまま続けちゃダメ
    2. 最近ではdomain.on(err)
  3. ここで時間切れ(^^;)

Object.defineProperty

  1. オフジェクトのプロパティの性質を制御する関数
  2. 変更できなくしたり、プロトタイプ汚染を防いだり
  3. ゲッター、セッターを定義できる