あるいは Kanazawa.rb meetup #47 に参加してきたよの巻。
Swaggerに対するモヤモヤ
最近 Swagger を動かしたり していたんですが、まぁ確かに Swagger UI は Google API Explorer みたいで感動はするんですが、「いや、『仕様』を書きたいんじゃないんだ」という気持ちがどうもモヤモヤしてましてですね。というのも、API というのはあくまで外部とのインターフェイスで、実際にはそのインターフェイスを実現するためには中で涙ぐましい努力をしたりするわけじゃないですか。そう、シンクロナイズドスイミングみたいなアレです。
そんな気持ちもあって、Swagger ではなく Grape から入るということを前回はやっていたわけです。Swagger UI は「公開されている API のクライアントを書く際にチェック用のツールとしては優れている」けど、ここからコード生成してもなー、っていう。どうせ中の泥臭い部分はサーバを書く言語で書かなきゃいけないのなら、インターフェイス部分を書く手間を減らしてくれる Grape などの DSL からドキュメント起こす方がいいよな、と思うわけです。少なくともサーバを書くという部分においては。
※ いい具合に Facade なコードを作っておけばできなくはないかもしれないし、Grape の中に生々しくロジックが入りすぎていていいわけでもないですが。
同時に自分の中では「仕様を外部に公開するよりはオレはテストをしたいのだ」という気持ちがくすぶってくるわけです。ビビりなので。spec の validation ではなく API のテストをしたいわけです。そんなものは今まで通りやればいいじゃん？ うん、まぁそうなんだけど。
Consumer Driven Contract TestingとPact
Consumer Driven Contract Testing という考え方があるらしい。
API サーバの詳細な動作ではなく、「クライアントが壊れないように API が動作してほしい」という意味での Concumer Driven Contract. 自分の理解としては The RSpec Book の中にあった BDD の二重構造の外側の部分のテストみたいな印象です。
これを実現する
というツールが『マイクロサービスアーキテクチャ』の中で紹介されていたので、これを試す、というのを今回の meetup のお題にしました。
Pactにできること
- クライアント（Consumer）側が守ってほしい挙動を記述する（標準では RSpec を利用）
- mock サーバを立ち上げ、サーバ側の挙動は mock として記述する
- それをサーバ（Provider）側と共有するためのJSONフォーマットがある（Pactfile）
- これを Provider 側で実行する
- 集約サーバがある（Broker）
- Broker から Provider は自分が守るべき Contract を取得し、守れているか自分に対してテストする
- mock を使ったテストは標準では rack-test を使うので Grape で書いた API はまさにそのままテストできる
mock を stub ではなく正しく mock として使っているので test double が分かっていないと、混乱するかもしれないです。しかも中間形式を用いながら使いまわしているので、クライアント側の期待する動作をサーバ側で検証できるのは非常に面白いです。
Broker はなくても Provider 側でテストの実行方法が分かれば最低限なんとかなるので、以下を目標としました。
本日の目標
- Consumer のテストの記述と Mock の動作が分かる
- Pactfile を生成する
Grape ですでに途中まで書いてある API があるので、それに対してPactfileからテストを実行する
までできれば練習完了。 3 は完了しなかったけど、これは想定の範囲内ということで。
bethesque/pact-consumer-minitest: Minitest support for the Pact Consumer gem
感想としてはクライアント側のコードを example に合わせて HTTParty を使ってみて、この部分に慣れていなかったのでなかなか手間取ってしまいましたが、サーバの mock は書きやすくてよかったと思います。まずは API のテストの第一歩を歩き始めた気分。
（このあと provider state など不慣れな用語がたくさん出てきて戸惑うことになるのですが、それはまた後日）
参考
思うところがあって github pages と jekyll を試してみた。
github pages
2種類ある。
- username.github.com
- username.github.com/repos
username.github.com
github.com/username/username.github.com
という repository を作る。例えば wtnabe なら
github.com/wtnabe/wtnabe.github.com
になる。ここに index.html を push してやればほどなく
http://wtnabe.github.com
にアクセスできるようになる。（これ書いてる時点ではテストが置いてあるけど、いつまでもあると思っちゃダメよ）
username.github.com/repos
各 repository に gh-pages という branch を作る
ことで、この中の HTML や素材が
username.github.com/repos
という名前でアクセスできるようになる。
両方作ったらどうなるの？
2種類あると気づいた段階でピンときてたんだけど、どうもこの2種類の github pages は最終的に一つのディレクトリツリー上に展開されているようだ。
試しにやってみたところ
- github.com/wtnabe/wtnabe.github.com 内に /ical2gcal/index.html を作成
- 作った /ical2gcal/index.html が wtnabe.github.com/ical2gcal/ に表示される
- github.com/wtnabe/ical2gcal に gh-pages branch を作る
- 作った gh-pages が wtnabe.github.com/ical2gcal/ に表示される
- github.com/wtnabe/wtnabe.github.com/ical2gcal/index.html を編集
- 今編集したファイルが表示される。つまり 1 に戻る。
という動きをした。
つまり username.github.com の github pages を作る際には各 repos の名前空間が conflict することになるので注意が必要。
作り方
Web UI から自動生成するのが楽だし template も選べてよいと思う。
特に repository の github pages を作る際はすでにある README を index の内容として読み込んでくれる機能もあるのでだいぶ楽。README を github 標準のスタイル以外でも表示できるというだけでもそれなりに意味があるし、ちょっとドキュメント書くかって気になりそう。
jekyll
github pages と言えば jekyll というか、もう生の HTML の編集なんてできませんて。
ということでこっちも試してみる。jekyll コマンドで
- (デフォルトで) _site/ 以下に render 結果を生成
- –server で localhost に確認用のサーバを起こす
- –auto でファイルを監視して自動生成
- ただし livereload のような仕組みはないのでそこは各自で reload するか工夫が必要
という感じで使える。
以前紹介した Middleman は Sinatra を使って Rails 風の layout で、tilt を使って各種のマークアップ形式や CoffeeScript などに対応していたが、こいつはそれに比べるとだいぶシンプル。
とは言えちょっとクセがあって、
- — で囲んでコンテンツのファイルを二層にしないと変換が機能しない。最低限 layout と title を YAML で定義する感じになると思う。
- git や gem 関係で必要なものも放っておくと出力（コピー）される1ので、_config.yml の exclude: に定義しておくとよい
- Textile は使わなくても RedCloth のインストールは必須で、かつ正しく依存性解決してくれない
- ここはだいぶ変だと思う2
excludeの定義は例えばこんな感じ
exclude:
- .git
- .bundle
- Gemfile
- Gemfile.lock
- _config.yml
- _layouts
- params.json
- vendor
実はこの params.json が何してるのか、まだよく分かってない。github pages を auto generate させたら勝手にできてた。
jekyll on github pages
jekyll での生成をアテにして Markdown ファイルや _layout/ などのファイルを直接 push してやると、ほどなく render 後の正しい HTML を閲覧できるようになる。
この機能を正しく使うには localhost に jekyll の環境がないとすぐに確認できないので黒い画面が苦手な人には厳しいと思う。
逆に使わないなら jekyll は無関係に github pages は作れる。
まとめ
github pages と jekyll を同時に扱おうとして無駄にややこしくなってしまった。
github pages は単に HTML を置いておくことができる repository でその名前や branch にルールがあるだけ。
たまたま jekyll での生成をアテにしたファイルも置いておくことができるというだけ。
jekyll はー…個人的には Liquid の良さがよく分からないのと、Liquid を使いつつ Textile や Markdown だけ特別扱いしている jekyll の方針がなんかモニョモニョする。まぁ何かしら global な値を渡したりはしたいんだけど、テンプレートや値の渡し方は Middleman + Tilt の方がよさげに見える。たぶん対応を広げすぎない方がいいという判断であえて現状のような構成になってるんだろうけど。
あと github pages のドキュメント、リンクがループしてたりして全然さっくり分かる感じがしないのは割と残念。仕組みはいいのに。
リンク
ある時から突然 Thunderbird で受信時の認証が通らなくなったということでヘルプ。現象としては
- Thunderbird 側の設定を何か変えたわけではない
- サーバ側の設定も変更なし
- 突然認証が通らなくなった
というもの。何度か試してみたけど確かにダメだ。正しいアカウント情報を入れ直したりしてみたけどダメ。
こういうときはログを読む。これ開発でもサポートでも鉄則ね。
……。
Thunderbird の protocol log なんて見た記憶がない。どうやって設定すんだろ？ 自分の機械だったら ngrep で強引に読んじゃうんだけど、他人の機械ではそういうわけにもいかない。困ったなぁとつぶやいていたら例によって twitter で正解を知った。
16:19:54 <liar_l> @wtnabe もう遅いっぽいですが、この辺とか。
https://wiki.mozilla.org/MailNews:Logging
16:21:01 >wtnabe< @liar_l うぉ。環境変数で採れるんですか！知らなかった。
あざっす！
MailNews:Logging - MozillaWiki
ここに代表的なプラットフォームごとにログを採るための環境変数の設定方法が書いてあるのでそれに従うだけ。
17:46:36 >wtnabe< @liar_l ありがとうございます。問題の機械で現象を特定
できました。通常の設定画面からは変更できない値が誤っ
て使われていたのでabout:configで直しました。
18:02:02 >wtnabe< 探しても出てこない現象だったんでメモ。アカウント設定
では一つしかアカウントが見えないのに
mail.servers.serverが複数あり、GUI で設定できない
usernameが送信されて認証失敗。
18:02:48 >wtnabe< どれか分からないのでusernameを正しいものに全部書き換
えて対処。もしかすると使ってないはずのものを消しても
よかったのかも。
18:07:29 >wtnabe< OSX だったので log を tail しながらトラブルシュートし
たわけど、Windows だったらもっと作業的に面倒だったん
だろうな。よかったよ OSX で。
アカウントの作成を失敗してやり直したか、あるいは複数のアカウントを使っていたんだけど消してしまったか、まぁたぶんそんな操作が以前あったのかも。GUI の通常のダイアログでは見えない複数のサーバ情報があり、GUI の通常のダイアログ上には正しい情報が表示されるが、実際には違う情報がサーバに送られてたという、ちょっとやっかいな症状。このトラブルはちょっと経験値要るわ。
上にも書いてあるけど、通常のダイアログで確認できなくても Thunderbird なら about:config の画面で操作できるので今回はそっちで対処。
周りから見ると
- Mac なのに Terminal でデカデカと log を tail -f
- いつもの Thunderbird なのに見たことのないウィンドウで文字いっぱい
という状態でとてもいぶかしい感じだった。ま、出張サポセンなんてそんなもの。
最近読んだのは『20世紀少年』『21世紀少年』、あと『医龍』。
『20世紀少年』は連載時途中で挫折して間が空いていた。どうも血の大みそかからともだち復活のくだりまでスッポリ抜けていたようだ。あと『21世紀少年』も読んでなかった。
読み直して思ったんだけど、これ、今の子どもはどういう感想を抱くんだろう。小学生が読んでも面白くはないだろうな。中高生くらいになると昔はこういう生活、遊びがあった、今はどうだ、と置き換えて考えることも十分できる。大学生の意見はどうだろう。何か面白いものが聞けるかな。作品のテーマとか無視でいい。自分たちの感じる懐かしさのポイントと、彼らが先入観なく感じるもののズレを確認してみたい。
『医龍』はドラマを見てた。漫画は雑誌に載っていたのをチラッと見たことはあって、一部登場人物のキャラ付けが違うのは知ってた。
全部読んだわけじゃないけど、個人的にはスキルの差のある人およびチーム間のギャップの話がとても興味深かった。普通の人が普通の方法でできることをやるという霧島の考え、朝田と霧島の間で揺れる伊集院、伊集院の成長を考えて伊集院に普通の人たることを強制するか否か悩む霧島、のくだりはちょっとグッときた。
本当は自分もそろそろ、自分の力が足りるか足りないか、すごい人はいるのに自分は、といった話ばかりではなく、こういう後輩の指導みたいな話に興味を持たないとダメなんだろうなぁ。もう少し大きな組織にいればその辺に悩むこともあるのかな。考えたらそうした悩みを抱える機会が少ないのも田舎の不利な点なのかもしれない。いざ人を育てなければいけなくなったときの対応力を鍛えることができない。勢い、乱暴な徒弟制のようなものになりがち。
まぁ、体系だった教育システムがあったとしても新人のできることは実際たかが知れていて、チームの中でイーブンな関係で働きながら成長できます的な建前であってもそれが本当に可能なのは実はかなりマニュアル化が進んでいないと無理っぽくね？という気はしている。それって成長産業など変化の激しい環境では結構難しいんじゃないかと。もう一つは、実はそういう環境での教育をぬるく感じる、あるいは逆に押し付けがましくてうっとぉしいと感じる可能性もあるわけで、実際、近代学校がまさにそれだよねという印象を抱いている。
そこでもう一度出てくるのは霧島の「研修医は失敗してもいい」という言葉で、「失敗できる環境をどう作れるか」が上に立つ者の腕なのかなという風に思ったりもしている。こうして言葉にするのはもしかすると初めてかもしれないが、「やり直しが効く」とか「選択肢がある」とか、そういう言い回しはずっと前から好きなので、実はこの10数年、同じこと言ってるだけだな。
やっぱオレがいちばん進歩してねぇよ。
読み始めてすぐに興味を失ったりしていた アンビエント・ファインダビリティ ―ウェブ、検索、そしてコミュニケーションをめぐる旅をようやく読み終えた。本当は出始めの頃から興味はあったんだけど、なぜかなんとなく敬遠していた本。
副題に「ウェブ、検索、そして…」って書いてあるから意を決して買ったんだけど、内容的にはウェブはあんまり関係ないというか、まぁ現実社会で人間はウェブという情報ファーストフードを大量摂取してぶくぶくに太って身動き取れなくなっているケースも多いんじゃねーの？という警鐘的な内容1の方に大きく興味を引かれたというかいやな気分にさせられて、その印象が強くなっているところ。
逆に面白かったのは序盤の wayfinding（経路探索）のところで、人間を含めて生き物がどのように自分の周辺の環境を認知、識別、記憶し、経路を正しく導出するかというくだりは非常に興味深かった。ただし、テキストベースのドキュメントやメタデータをもとに情報のフィルタリングを半自動、あるいは全自動で行ってそれを判断材料にしている人間は、次の世代ではもう生の現実世界における経路探索能力を失ってしまうのではないかという、超悲観的な予想を勝手に立ててまたいやな気分を味わわされることになるのだけれど。
まぁいやな気分になってしまうのは、自分がコンピュータだの IT だの大好きなクセして、それが明るい未来を生み出すとは思えないというか、だからこそ逆に人間が生き物としてこの世に生きていることをどう捉え、どのように人間は生き、また次代の人間を育てなければいけないのか、ということをちまちま思い悩むのが好きな人間だからだろうと思います。きっとこの本のせいではないです。
内容は多岐に渡り、どうも発散してしまって結局なんだったのだろうという印象も残るが、いろんな学問分野への入り口が開かれている点は、理解しやすさや説明の丁寧さを除いて、とりあえず初学者にオススメなのではないかと思った。情報科学とか認知科学とかその辺の分野が割と近しい人向けというか。あと情報リテラシーを真剣に考えなければいけない教育方面の人も。
読み方としては、割とこの本の根底に流れている精神だと思うけど、各自が自由に自分の好きなフィールドに勝手に引き寄せてタグ付けすればよいのだなと感じた。正確な理解や内容の整理を意識過ぎてはいけない本なのだ、きっと。
もちろんそれだけじゃないよ ↩
自分は統計は結局スルーしちゃったので R だけあってもだめなんですが(^^;