@kyanny's blog

My thoughts, my life. Views/opinions are my own.

Node.js debug 使い方

Debugger Node.js v4.1.1 Manual & Documentation

はじめてのNode.js:Node.jsアプリケーションのデバッグ 2ページ | OSDN Magazine

  • n(ext), s(tep), c(ontinue) などはいつもどおり
  • watch('expr') で変数の値をウォッチすると next で進むたびに常時その時点での値を表示してくれる
$ cat a.js
var a = 0;
a = 1;
a = 2;

$ node debug a.js
< Debugger listening on port 5858
debug> . ok
break in a.js:1
> 1 var a = 0;
  2 a = 1;
  3 a = 2;
debug> watch('a')
debug> n
break in a.js:2
Watchers:
  0: a = 0

  1 var a = 0;
> 2 a = 1;
  3 a = 2;
  4 
debug> n
break in a.js:3
Watchers:
  0: a = 1

  1 var a = 0;
  2 a = 1;
> 3 a = 2;
  4 
  5 });
  • 任意の expr を評価したいときは repl コマンドで改めて repl に入らないといけない
debug> repl
Press Ctrl + C to leave debug repl
> a
1
  • いまいる行の周辺のコードを見るには list(5) のようにする。 list は関数なのでカッコが必要
debug> list(5)
  1 var a = 0;
  2 a = 1;
> 3 a = 2;
  4 
  5 });
debug> list
[Function]
debug> 

Dragonfly を学ぶ

仕事で markevans/dragonfly · GitHub を使っているが、すでに導入・運用済みのものをなんとなく利用しているだけで、どのように使うのか・どのように動作するのかが自分の中で腑に落ちていないことに気づいたので、 http://markevans.github.io/dragonfly/ を読みながら動作する最小のコードを書いて学んだ。

https://github.com/kyanny/playground/tree/gh-pages/ruby-dragonfly

  • Dragonfly はコンテンツの保存と配信を司るライブラリで、 Rails エコシステムにおける carrierwave や paperclip と似た存在だが、独立して利用することもできる
  • Dragonfly.app で Dragonfly のインスタンスを得る。このインスタンスを通じてコンテンツに対し各種操作を行う
  • Dragonfly.app.store でコンテンツをバックエンドのストレージに保存する。 store は uid を返し、これがストレージ内でコンテンツを一意に特定するキーとなる。通常この uid をデータベースに保存しておく。ストレージは設定により複数から選べる(メモリ、ファイルシステム、 Amazon S3 など)
  • Dragonfly.app.fetch に uid を渡すと Job オブジェクトというものが得られる。これは Dragonfly がコンテンツをラップしたオブジェクトで、コンテンツの属性(mime type など)を得たり、コンテンツの種類によっては動的な変換処理を施すこともできる
  • Job オブジェクトに対して #url というメソッドを呼び出すと、そのコンテンツを配信するための長くて一意な URL が得られる。こんなの http://localhost:9292/W1siZiIsIjIwMTUvMDkvMTgvMzhnd2phY3pzMl9sZW5hX3N0ZC5wbmciXV0
  • コンテンツを配信するウェブアプリケーションは、 uid をパラメータで受け取るように実装してもよい(その場合は内部で #fetch したあと適切な HTTP ヘッダを付与してコンテンツを返すような実装も書かなければならない)
  • そういう処理を毎度自分で書かなくて済むように、 Dragonfly.app は Rack アプリケーションとして動作し、 Job オブジェクトが #url で返した URL へアクセスしたとき対応するコンテンツを配信してくれるようになっている
  • Dragonfly.app.fetch_url メソッドを使うと指定した URL からコンテンツを取得して再配信できるので、バックエンドストレージ無しのコンテンツ配信プロキシサーバとしても動作する
  • Dragonfly はプラグイン機構や設定が充実していて、標準で ImageMagick プラグインが利用できるので、画像ファイルを配信時に動的に変換することができる(任意のサイズのサムネイル画像を配信する、など)

最近読んだもの

13 Tricks to Appear Smart on Twitter — The Cooper Review — Medium

俗っぽくて笑った。思い当たるフシがいくつもある。こういうことはできるだけ避けていこう。

デザイナーの道具箱 - デザイン指定のポイント 2 | CodeGrid

一緒に仕事するデザイナーに読んでほしい。

ちょっとお先にHTML 5.1 - picture要素 1 | CodeGrid

なるほどむずかしい。でも勉強になる。

フロントエンドのサウンド実装 - 「音」に関する要素・API | CodeGrid

このシリーズも楽しみ。

GRを1ヶ月間使用した感想(GRとGR DIGITAL4の比較) | ダーフク.com

シルエットの写真がとても良い。あんな写真を撮ってみたい。

autodoc その後

二年前に autodoc導入したが、現在はもはや誰も見てないし使ってないね、という話を社内でしたら、「使い始めた話だけじゃなくて、やめちゃった話もブログに書くべき」と指摘され、確かに誠実な姿勢とはいえないなと反省したのでこの記事を書いています。

恥を忍んで現状を明かすと、 master ブランチに push されたタイミングで実行される Jenkins のジョブが半年ずっと fail していた、ということに昨日気づいた体たらく。そもそも生成された markdown ドキュメントを push していたリポジトリがとっくの昔に削除されていたと思っていた。

うまくいかなかった原因の分析:

Quipper の Internal API は非常に込み入ったデータ構造を返すものがほとんどで、お世辞にも「きれいな RESTful API」とは言えない。なので request spec を書く際に、完璧なテストデータを用意しきれておらず、アサーションもちょっと粗い(JSON が所定のフィールドを持っているか、フィールドの値の型は何か、という詳細なレベルのテストはモデル層のユニットテストとして書いているので request spec で重複するテストを網羅的に書かない)なので、 autodoc が生成するドキュメントに記載されるレスポンスデータは、「あるべきデータ構造・データ型」でもなければ「本番環境の API が実際に返しうるデータ構造・データ型」でもない、ということがありえる。つまり、ドキュメントの信頼性が低い。

autodoc で生成されるドキュメントの精度を上げるために request spec で込み入ったデータ構造を再現したテストを書く、というのは労力に見合わない。大量のテストデータを生成しなければいけないのでテストコードは太り、テスト時間は長くなる。しかもあくまでテストデータにすぎないので、実際にありえるパターンすべてを網羅するのが難しい。ツールを活かすために別の負担が増すくらいならふつうにドキュメントを書いたほうがよい。がそんな余裕はなく、またぶっちゃけそこまで API ドキュメントが必要とされてもこなかった(ほぼ全員 Ruby と Rails の読み書きができるので実装を読んだほうがはやいし確実)

ということで、銀の弾丸はなかったという話でした。