と言うことで、メモを投下。
Param Tuner
資料 → ParamTuner 東京Node学園#8
しばらく中に入れなくて、聞けてませんでした。
統計解析の話だったようです。資料見て自習します。
- QA
- JavaScriptで統計解析やるにあたってデータの量とかはどうなんですか?
- 実際にはHadoopで裏でやっていますが、その前段階の傾向を見るのに使っています
- なので、そんなにデータは多くはないです。
- JavaScriptで統計解析やるにあたってデータの量とかはどうなんですか?
Nodeとプロミスと時々、関数型
資料 → Node, Promises and Functional Programming // Speaker Deck
- ことの経緯
- Scala
- JavaVMで動く関数型言語。
- Finagle
- とあるブログエントリが話題に
- Callbacks are imperative, promises are functional: Node's biggest missed opportunity – The If Works
- node.jsはコールバックではなくて、Promiseにするべきだった
- 翻訳しました
- Scala
- 非同期処理を書く時に何を考えるのか?
- タスク同士の依存関係を考える
- 必要な操作の順序を考える
- 最後に、その制御フローを考える
- コールバック VS プロミス
- コールバックの良くないところ
- 処理をモジュール化したり組み立てたりするのが難しい
- 逐次処理か並列処理かを明示的に制御する必要がある。
- あと、ネストが深くなってしまう問題があるけど、重要な論点ではない。
- コールバックの良くないところ
- 例
- プロミスとは
- 完了していないかもしれない計算の結果が入っている箱
- プロミス自体も値なので、関数の間で受け渡しが出来る
- 計算が完了すると特定の処理を呼び出したりする(ものが多い)
- しかしながら
- 必ずしも全てのプロミスが関数型ではない
- 言語やライブラリによって異なる
- 関数型とは?
- 関数型プログラミング
- あらゆるものを値として扱い、
- 値同士の依存関係を関数で表現し、
- 複数の関数を合成してより大きな関数を作る
- 先の例で言うと
- 複数の非同期計算を合成して大きな計算をする
- 後で処理を追加したいときには
- thenを使う
- thenは、プロミスに依存する別の非同期処理を記述する
- thenで記述された処理は、値がいつ利用可能になり、どんな順番で処理するかを気にする必要がない
- プロミスとthenを使うと
- 記述された依存関係を元に実行順序を自動的に解決するので、
- 依存関係でプログラミング出来る
- 結果を待ちたい場合
- プロミスの配列をリストに対するプロミスにする
- これによって待合せが表現できる
- 課題に戻って
- プロミスを使うと、必要な操作の順序を考えなくても良い
- なので、非常にシンプルにプログラミングが出来る
- プロミスは難しい
- 先のブログに対する反論記事
- プロミスを使うと
- thenやlistで意味的に隠蔽してしまうので、認知的コストが大きい
- プロミスを使ったものは、学習コストがかかる
- 反論に対する反論
- 簡単であるかよりも、シンプルであるかを問うべき
- やりたいことが変わった時に、コードの変更が少なくて済む
- 結局
- どちらもただしいと思う
- コストとメリットを天秤にかける
- ただ、非同期プログラミングのコストの支払期限は意外と早いのでは?
- まとめ
- コールバックはとっつきやすい
- 変更に強くするならプロミス
- メッセージ
- 関数型を勉強してみませんか?
- 仕事で使わなくても、プログラマとして芸風を広げるのに役立ちます
- 気軽に学んで見たい人向け
@koichik さんから
- 3年ほど前はnode.jsでもプロミスを使っていました
- しかしながら、あんまり評判が良くなかったようです。
- プロミスが嫌われていたのは、プロミス自身ではなくて、JavaScriptでのプロミス自身がいけていなかったから。
- 先の例で言うと、実際にはエラー処理をしなければならないが記述されていない
- エラー処理を実装すると、結局冗長にせざるを得ない
- 現在、node.jsではメカニズムとして一番シンプルなコールバックのみ提供している
- プロミスの実装は、別のモジュールで色々な人が作っている
- node.jsのスタンスとしては、モジュールとして好きなものを作っていいよということが現在のスタンス
LT
LET IT CRASH!?
資料 → 東京Node学園#8 Let It Crash!?
- Let It Crash?
- Erllangの哲学
- Akka開発チームのブログのドメインがそれ。
- 堅牢なコードを書くには?
- ディフェンシブプログラミング
- 失敗する可能性があるものは失敗するので、失敗に備えておこう
- 引数などはチェック、例外を捕まえる
- アプリがエラーから回復する
- 通常処理とエラー処理が混在する
- Let it crash
- 失敗に備えない
- 例外を捕まえないで、スーパーバイザがエラーから回復する
- 通常の処理と分離出来る
- ディフェンシブプログラミング
- スーパーバイザ
- 1つクラッシュすれば、それだけリトライ。One4One
- 1つクラッシュすれば、関連を全てリトライ。All4One
- You! さっさとクラッシュしちゃいなよ!
- process.on('uncaughtException')
- OnErrorResumeNextとは違うのですよ。
- domain.on('error')
- エラーを無視するな
- エラーが起きたら、プロセスをシャットダウンしなさい
- process.on('uncaughtException')
といった所でLTタイム終了しちゃいましたが、まだ半分までです。
domainのAPIドキュメントを見てね!
LT2 Object.defineProperty
資料 → 不明
- Object.defineProperty
var obj = {}; Object.defineProperty(obj, 'prop', { // ここにプロパティのオプションを書く });
- オプション
- configure
- falseを設定すると、上書きとか削除とかできなくする
- enumerable
- for inのループで出てこなくなる
- wraitable
- 上書きできなくなる。
- 定数とか。厳密には定数とは違う。現状のJavaScriptで実現出来る方法。
- get, set
- getter / setter が定義が出来る
- configure
- 複数のプロパティをまとめて定義することも可能
Object.defineProperty(obj, { 'prop1': { // オプション }, 'prop2': { // オプション } })
- 作者: 清水俊博,大津繁樹,Jxck,小林秀和,佐々木庸平,篠崎祐輔,高木敦也,西山雄也
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2012/10/26
- メディア: 大型本
- 購入: 31人 クリック: 803回
- この商品を含むブログ (7件) を見る