なかなかギョーム以外でPCを触り続ける時間が確保できない状態が続いているので、こういうの書く時間も必然的になくなっちゃって久しいんだけど、たまたま大晦日で早く酔っぱらって早く目が覚めたので、書き留めておこう。

※ いきなり脱線だけど、スマホで書くとか個人的には苦行以外のなにものでもないなーと思ってる。メモは書けるけど文章は書けないよー。メモは書けるのでスライドの下書きは書けちゃうんだけど、やっぱ文章は書きながら編集できないとつらいっす。

新しくできたこと・試してみたこと

Vagrant + Chef

• Vagrant
• opscode/chef
• chef (Chef) (書いてる時点ではまだ中身ないけど、こっちに移行する気みたい)

• vagrant + chef-solo provisioningが初めて動くまで - あーありがち(2013-05-25)
• WindowsでVagrantパッケージを入れたときにできることとVagrantfileをrakeで生成するアイディア - あーありがち(2013-05-26)

正直言うともう忘れ始めているけど、これは2013年でいちばん大きな収穫だった。以前は Mac を使っている自分だけ Rails の環境を不自由なく使えるとか、Linux と Mac で環境を合わせるのが面倒とか、独自に作った VM の Linux が微妙に設定足りなくてたまたまエラーの起きない環境で作業してる人がいたりとか、お仕事的には困った感じになっていたんだけど、今は Vagrant

• Chef Solo を使った VM を配布して Win/Mac 問わず Linux 上で作業するようにしている。

実際にはこれだけでは済んでなくて、Samba 越しにコード書けるようにしとけばみんな幸せかなと思ったら Windows + Samba のクセ¹にちょっとハマったり、みんな同じ環境を使えるようにするために hostonly ( private ) な network にしたのでスマホの実機確認しにくくなって proxy を足すとか、使う道具が増えて面倒になった部分もあるけど、それでもよかったなと思う。

今は vagrant up するタイミングで repos の最新版と比較して警告を出すようにしてるので、プロダクトのコードだけでなく環境も更新しやすくなってきている。こういう細かいノウハウ、もっと表に出していきたい。自分のために。

Padrino

The Elegant Ruby Web Framework - Padrino Ruby Web Framework

ごく簡単なものを実際に作って動かしてみた。どこにもそのメモをアウトプットできないまま時間が過ぎてしまったんだけど、個人的な感想としてはすでに Rails 使ってる人は Rails でいいし、初学者も Rails の方がいいんじゃないかなぁという気がした。ただし、

1. 要件があまり変化しない（基本的な API 中心とか？）
2. Rails のように情報が大量に手に入る必要がない
3. Rails のように便利 gem のカタマリになりすぎると gem のお守りの比率が増えてよくないと判断できる

場合にはいいのかなぁという、消極的な採用理由は残りました。

まずそもそも Rails と併用すると似てるけど微妙に違うコマンド、タスク、作法に戸惑うので割とイライラする。裏を返すとRails の経験があるとだいたい勘が働いて、落ち着いて考えるとだいたい「あーそうだよね」という動きをするということでもある。

ただ実際に利用した 0.11.x で iOS のやや古い Safari で redirect が正しく動かないとか、Rails では経験したことのない「うーん？」という動きをしたり、どーにも Controller の DSL が気持ちよくないなぁという感想が残って、結論としては上のような感じで自分がメインで使うのは Rails かなぁという感じ。

Controller の DSL は Sinatra 由来なんすかね。Sinatra は発想はいいなと思ってるし、Kanazawa.rb の企画に取り入れたりはしてたけど、実はまともに使ったことがなくて、今回初めて書いたけど、あんまり気持ちよくないなーというのが正直な感想だった。すごく初歩的なことなんだけど、ApplicationController を継承しないので、じゃあ全部の Controller で共通する処理はどこに書けばいいの？とか、 module を使えばいいかなと思っても block は module でも class でもないからどうすんだべ、とか調べないと分からないところなんかが個人的な引っかかりポイントでした。²

つまんないこと言ってすいません。

でもなんか「フツーこうすればこうなる」って容易に想像がつく、少なくとも ApplicationController 方式はフツーの OO を知っていれば想像がつくのはよいことなんだなぁと再認識することができたのはよかった。この経験があって、改めて Rails を触ってみたときに、うまいこと Ruby そのものをパワーアップさせてる感じが本当にうまいなぁと小並感を抱いたもんです。callback とか module の使い方が Ruby そのものの理解に繋がっていく感じがすげー³。

だいぶ脱線したけど、Sinatra だけでゴリゴリ書けるものをもう少しうまく扱うのにはよいのかなと思いました。まる。

PhantomJS

• PhantomJS | PhantomJS
• Kanazawa.rb meetup #14 に参加してきた - あーありがち(2013-10-19)

タイトルが意味分かんなくなっちゃってるけど、この中に Jasmine と組み合わせる話を軽くまとめた。結論から言うと PhantomJS 1.8 以降はすごく便利だし、使うべし。

ただし、本物のブラウザなのでそれなりにメモリを食うので CI サーバが貧弱だとまずい。

Cucumber

Cucumber - Making BDD fun

やっとまともに回せた気がする。きっかけは Turnip の登場で、Turnip が流行り始めたからこそ逆に Cucumber かなという気がしてきているところ。

ポイントは

• end-to-end のテストは必ずしも受け入れテストではない
• Turnip は The RSpec Book はじめ、近年あちこちで言われている二重構造の BDD に逆行しているような気がする

あるいはごく単純な話にすると、開発者は

rake spec

を叩いた時に常に受け入れテストが走ってほしいかということ。で、自分は違うなぁと思った。

自分がなかなか Cucumber を使わなかった理由は単に面倒くさいに尽きる⁴んだけど、実際に feature を書いたり Turnip に関する記事を読んでるうちに以下のようなことを思い始めてきた。

• 開発者視点だと Gherkin を使って書くシナリオは必須ではないし、逆にユーザーストーリーとしては記述されない部分の中にも end-to-end でテストしたいものはある
• だから end-to-end テストすなわち Gherkin というのは変だし、シナリオベースのテストは開発者の安心にとって必要十分じゃないのではないか

で、

受け入れテストは開発者が日常的に動かすテストと別な場所に置いてあって別なツールで動かした方が扱いやすいのではないか

というのが今のところの結論。だから受け入れテストは Cucumber にしようとしてる。実際には自分のお仕事的には受け入れテストが揃っていることは要件ではないので姿勢の問題でしかないんだけど。

Limonade-php ( 未投入 )

Limonade - PHP micro-framework

Sinatra の DSL が気持ちよくないと言っておきながら PHP の Sinatra-inspired なフレームワークを試してた。

小さいビジネスにはこういうので十分かなと思った。ほどよく枯れていて、かつ止まっていない。View がちょっとだけ制限された生 PHP になるのがモダンな感じ。基本は OO ではないので $this-> がコード中に出てこないのがまた気持ちよい。書こうと思えば Class-based な Controller も書ける。

mod_rewrite 頼みなのはそれはそれでハマりポイントがあってイヤだし、Model はスルーだけど、今のお仕事であれば Model は昔自作したやつがあるので、まぁそんなもんかなという感じ。ブツが育ちそうなのが分かってれば Rails にする。

ほか

• Terminus ( 未投入 )
  • 試した限りではちょっと古い iOS 端末やシミュレータではテストが完走しなかったのもあってまだ実戦投入はしてない。すごくよいとは思っている。
• Jekyll plugin ( Github Pages でトラブって頓挫中 )
• AWS S3
• Fabrication ( 以前から使ってたけど、拙作 easy fabricator と同居させた )
• Veewee
  • 当初思っていたよりずっと簡単だし、適当に拾ってきた Vagrant Box 使わなくてよいのでオススメ
• Zapier
  • 無料で使うにはいろいろ制限があるけど、任意の URI に post できるのは助かる。IFTTT ではできないことができるのでよい。

継続できたこと

• Jenkins
  • Capistranoと組み合わせたり
  • visualize plugin 増やしてやる気維持
• Capistrano
  • deploy時に必要な権限を制限して実行できるユーザーを増やしたり

Kanazawa.rb

Meetup - Kanazawarb

• 大物ゲストを招いての開催の成功とその反動の沈み込みを一応抜けた
• 2013年現在、wtnabe がいなくても meetup の開催は継続できる状態になった
• 2013年にコミュニティスピーカーデビューを Kanazawa.rb で果たした人が 7人

これは自慢していいと思う。ちなみに 2012年にスピーカーデビューした人が6人で、これを越えたのも自慢。

ただ本当はやっぱり Kanazawa.rb という名前で何かプロダクトやみんなが参照してくれるような資料的なコンテンツが生まれるといいな、その結果みんなにもっと Kanazawa.rb が知れ渡って、憧れの地というか「あの Kanazawa.rb に参加するんです、ドキドキ」みたいなことになれたらいいなという思いはあるけど、なんかどうもこのコミュニティはあんまりそっちを志向していないような気がするなという感想を最近は持ってて、次の目標をどこに置いたらいいのかなぁという迷いはある。

2012年は人材流出コミュニティというのが自虐的な内輪のブランディングではあったけど、マジな話、Kanazawa.rb から次々と有望な人が抜けていく状態だったことはやっぱダメージはあって、少なくとも技術的にリードできてノウハウやスキルのシェアに積極的な人は不足している。やっぱり Asakusa にはなれないよねーという当たり前のことを再確認しつつ、じゃあどうするかはまだ見えていない。

ほんとはこんなこと心配しないでおれはおれのコードを書いてブログを書くだけにした方が自分のためにはなるんじゃないのと思ったりもする。一方で「それじゃあ2000年代と何も変わらないじゃないの、東京以外にはおまえらはいないのですか」ともう一人のおれが問い詰めてくるわけだ。ぶっちゃけつらい(笑)

読んだ本とか

なぜかアサマシが貼れないのでとりあえずそのまま。

• The RSpec Book
• アプレンティスシップ・パターン
• アジャイルレトロスペクティブズ
• 入門Chef Solo
• Railsデプロイ
• コーディングを支える技術
• SQLアンチパターン
• TeamGeek
• これだけ！KPT
• Twelve-Factor App
• パターン・ランゲージ

• 明日の広告
• Running Lean
• BMGワークブック
• ランチェスターNo.1理論
• 採用基準

ここ数年は帰省のタイミングでまとめて乱暴に読む + 日常的にちょこちょこ、のリズムができてきて、いっときよりは読めるようになってきたけど、まだまだ勉強不足だなと痛感することしきり。

ただまぁスマホしか持てずに本も読めない、何か書いたり作ったりできないという時間が増えているので、これ以上インプットを増やすのはなかなか難しいなぁとは思っていて、歯痒い。

作ったもの

小物ばかりだけど、一応成果は出せていてそこそこ満足。

• activerecord_simple-explain
  • ActiveRecord 3.0/3.1 で explain するためのちっちゃいやつ
• gcalapi の redirect 対応
• rqrcode_png_bin
  • rqrcode_png をコマンドラインから叩くもの

まとめ

ブログ力の衰えは著しいけど、こうして見るとまだ停滞はしてないのかなという気もするので、そう考えるとそこそこよい年だったのかも。個人的な印象では悩んでばかりであまりいい年だった気がしないんだけど、いい年だったっぽい外面を作るのも大事かなという気もするので、よい年でしたと言っておきましょう。

よい年でした！