靴が左右バラバラだった

初めての経験だったので記録しておこう。

片方白で、もう片方は黒だったのでかなり目立ってたと思う。

呑んでたわけでもないのになんでこんなことに…

TDDBC長岡 1.0 でTAをしてきた

ついに開催された TDDBC長岡 1.0 で、ペアプロデモとTAという形でお手伝いしてきました。

せとあずささんとのデモは、Eclipseの設定忘れがあってもたもたしてしまうことに。

デモ自体は無難にできたような気もするんですか、ちょっとわざとらしすぎましたかね…

午後はRubyの2ペアのTAという形で見てたんですが、プライベートでRuby書いている人たちばかりだったので、それほど口を出すこともなく…

  • Rubyでクラスを判定するのはあまり筋がよくないよ
  • RSpecについて調べたかったら RSpec - Relish を見るのがいいよ

というくらいしか役にたった記憶がないような。

あまりにみなさんが優秀だったので、こっそりお題をやってみたり。 成果はこちら。途中までだけど。

kenchan / tddbc_nagaoka_java_version_parser

終わったあとの懇親会、二次会共に、お酒も料理もとても美味しくて、完全に呑みすぎていました。(変な風に絡んでしまった皆様、ごめんなさい)

故郷の方の皆さんと、こういう形で触れ合えてとても嬉しかったので、また機会があればお手伝いしたいと思います!

散髪ログ

近くの美容院が結局深夜営業を再開したみたいだったので夜に予約して散髪。

前回は3月3日だったので2ヶ月半くらい。すごく伸びた気がしてたんだけど、そんなでもなかったのかな。

Ruby 2.0.0-p195

Ruby 2.0.0-p195がリリースされて、さらにruby-buildもすぐにタグが打たれたので、esm-overlayのruby-buildを更新して入れたのでした。

MacにTDDBCの環境を作った(Java, Eclipse)

TDDBCに向けて、デモの環境をMacに作ったのだった。

自前のMacはSnow Leopardのまま凍結されてしまっているので、JDK 7が入れられなかったり、Quick JUnitとGrowlの連携がうまく動かなかったりと思ったような環境にできなかったけど、とりあえずデモができるくらいの環境にはなった気がする。

ところで、KeyCastrの代替ソフトって今あるんですかね?(旧いdmgみつけて入れてみたけどまともには動かなかった)

Funtoo Linux インストール講習会本番

まずは、当日の参加者の皆さん、会場を提供してくださったEngineYard様、ありがとうございました。

全員がブートまでは行けた前回に油断した結果、今回は何名かkernelのビルドが終わらないまま終了してしまいました。

前日の素振りでdebian-sourcesのbinaryフラグを付けた場合のビルド時間がやばいことには気付いていて、当日はCPUの割り当て数をなるべく多くしてもらったんですが、それでもマシンスペックによっては数時間コースになってしまい時間内に終わらず…

前回はgentoo-sourcesでカーネルのオプションもある程度整理したものをビルドしてもらっていたんですが、そうするとどうしてもブートしないマシンが出てきたりしてしまうので、今回はFuntoo Linux Installation ドキュメントをなぞることにしようとしたのが失敗といえば失敗ですね。

ただ、その長いビルド時間を利用して補足説明や、普段私達がどんな感じで使っているのかを紹介できたので(今までも軽くはやっていましたが)、今後のFuntooライフに役立ていただければと思います。

VirtualBoxコースを見ていてのメモ

  • BIOSでCPUの仮想化オプションが無効になっている場合があるので最初に確認してもらう
  • インストールのときはなるべく多くのCPUを割り当ててもらう(コア数の半分くらい)
  • debian-sourcesのbinaryフラグ付きビルドはディスクを大量に食うので20Gくらいは開けておく
  • どうせみんな同じ環境なんだから、kernelのオプションを決めて自前でビルドしたほうがいい(準備の時間…)

もしかしたら次回があるかもしれないし、参加者の皆さんからは「普段の使い続け方についてもっと知りたい」という声もいただいたので、今後ともよろしくお願いします。

TDDBC長岡に向けたミーティング

TDDBC 長岡でのデモの打ち合わせをしていた。

題材からデモの流れ、どこでどういう説明をするのか、みたいなのを整理しながら、最後に軽く通してみて終わり。

@t_wada さんや @setoazusa さんがどういう問題意識を持っているのかもわかって大変勉強になった。

これがちゃんとできればいいデモになりそうなので、あとは私のEclipseリハビリだけですね…

プロジェクトの歓迎会

プロジェクトの歓迎会で一回休み。

数カ月前からぜんぜん咳が止まらないのでいいかげん病院に行ってきたのだった。

連休明けだから午前中を完全に潰す覚悟でいったけどそんなに混んでなくてよかった。

喉もはれてるから、まずは咳を止めましょうということでちょっと強めの咳止めをもらって終わり。

GW後半終了のお知らせ

5/3にはプラレール博へ海浜幕張まで。3時くらいに着いた段階でも入場には10分くらいかかったかな。 中はそれはそれは大変な感じになっていて、とりあえず一周見てから、奥さんはお土産を買いに、私と息子は比較的空いてる広いスペースでひたすらプラレールを眺めていた。

(下の写真は閑散としているエボルタエリアの様子です)

丁度入場口が閉まるくらいの時間になったので、ためしに入口まで戻ったらだいぶ過疎っていたので、それからスタンプラリーを開始して、最後に一番空いているアトラクション(3つの箱の中から車両を一つずつ取って、おなじ車両だったら金メッキの車両がもらえるというビンゴゲーム)を1回やったが、息子に事前情報を与えすぎたため、中を覗きまくるという恥しい感じになってしまった…

「中を見ないで取って」としつこく言っていたら、ピカピカのプラレールが欲しかった奥さんにうるさいと言われたが、子供だからってルールを無視するのはよくないと思うんです!!1

あとは、幕張限定の連結バスにも乗れたので息子はだいぶ満足だったみたい。帰ったらみんな疲れ果ててすぐに寝てしまったのと、翌日(5/4)はだいたい死んでいた。

5/5は子供の日なので息子と外に出て、ヨーカドーの海老の大きさに比例して価格が決まる寿司(もちろんそれだけじゃないが、安い方だと海老が小さい)とオランダ家のケーキを買って帰宅。

そして今日は、たまには外でゆっくりしてこいと言われたので、お言葉に甘えて淡路町のスタバでもくもくしながらこれを買いているのであった。

Sidekiqを使った非同期処理のテストについて

まとめ

sidekiqを2つのRailsアプリケーションで使ってみて、テストの書き方と残し方について思うところがあったので書いてみます。

  • 特別な事情がなければsidekiq/testingを使うべき(sidekiq/testing/inlineは使わない)
  • 非同期処理そのもののユニットテストはMyWorker.new.performで書けばよい
  • 非同期処理をキックする側のユニットテストはMyWorker.jobs.sizeを検証するだけにする
  • エンドツーエンドテストでは「全ての非同期ジョブを実行する」というようなstepやメソッドを作ってそれを呼ぶ

sidekiq/testingsidekiq/testing/inlineについて

sidekiqのwikiには、テストのための仕組みとしてsidekiq/testingsidekiq/testing/inlineの2つがあり、**「どちらか選んで使え」**と書いてあります。

それぞれの実装を読んでもらえばわかりますが、

  • sidekiq/testingはジョブキューをArrayで潰して非同期処理が実行されなくする
  • sidekiq/testing/inlineはワーカーの処理を同期実行する

という動きをします。

ぱっとみsidekiq/testingはユニットテスト、sidekiq/testing/inlineがエンドツーエンドテスト向き、のように見えますが、両方ともsidekiq/testingを使うべきだと私は感じました。

  • requireしただけで有効になってしまうのでspec_helperで切り分けるのが困難である
  • 同期処理を前提としたテストを書けてしまう(実際に書くかどうかは別として)
  • エンドツーエンドテストでは後述の仕組みを使って、明示的に非同期処理を走らせたほうがテストの意図を表現しやすい
  • テストを書く上では非同期処理の先を気にしなくていい場合の方が圧倒的に多いのに、その全てでperformをstubするのが面倒だし意図が捕みにくい

というところで、sidekiq/testingを使ってどうやってテストを書いていけばよいか紹介します。

非同期処理の処理内容のテスト

非同期処理の処理内容は簡単で、testing-workers-directlyの項にあるように直接performを呼べばよいです。

describe S3UploadWorker do
  let(:worker) { S3UploadWorker.new }

  describe '#perfome' do
    it { expect { worker.perform() }.to change(...) }
  end
end

非同期処理の実行をキックする方のテスト

非同期処理の実行をキックする側は、sidekiq/testingの流儀に従ってジョブキューに処理が入ったことだけを検証するようにしましょう。

例えばImage#uploadS3UploadWorkerを使ってS3へのアップロードを非同期化していることを検証したい場合は以下のように書けばよいでしょう。

describe Image do
  let(:image) { Image.new(...) }

  describe '#upload' do
    it { expect { image.upload }.to change(S3UploadWorker.jobs, :size).by(1) }
  end
end

これだけだとジョブがいつまでも残ってしまうのでspec_helper等にclean_allを呼ぶコードを入れておきましょう。

config.before(:each) do
  Sidekiq::Worker.clear_all
end

エンドツーエンドテスト

では、非同期処理も含めたエンドツーエンドテストはどうすればいいでしょうか。

sidekiqのwikiを読むとdrainというクラスメソッドがあります。これを使います。

  • Sidekiq::Worker.drainは特定のワーカーのジョブキューに溜っているジョブを全て実行します
  • Sidekiq::Worker.drain_allは全てのワーカーのジョブキューに溜っているジョブを全て実行します

request specsならばこれらを直接、cucumberやturnipであれば以下のようなステップを作って明示的に呼び出すようにします。

step 'バックグランド処理を全て実行する' do
  Sidekiq::Worker.drain_all
end

この方法は、非同期処理の完了を待ち合わせをしたり、適当にsleepを入れたりしなくてもいい上に、テストの意図も表現しやすいのでお勧めです。

おわりに

今回のエントリは、実際にお仕事で別々のテスト戦略を選択したRailsアプリケーションに機能追加や修正をしてみたところ、sidekiq/testing/inlineは安易に選択しないほうがよさそうと思ったのがきっかけです。

sidekiq/testing/inlineを選択した場合は、以下のような問題が起きる可能性を考慮しなければなりません。

  • 非同期処理がいらないところにすべてstubを仕込まないといけない
  • 実行されてもされなくてもいいところでは全て実行されるので、スローテスト問題になりやすい
  • 同期実行される前提でテストが書かれる可能性がある
  • 非同期処理の先も含めてのユニットテストが書かれてしまったりする

「そんなの書かねーよ」と言われればそれまでですが、こういう書き方ができてしまう方法を選択しないほうがよいにこしたことはないと思います。

というわけでみなさん非同期処理のライブラリとしてsidekiqを選択する場合は以下のような方針でテストを書いみるのがよいのではないでしょうか。

  • 特別な事情がなければsidekiq/testingを使うべき(sidekiq/testing/inlineは使わない)
  • 非同期処理そのもののユニットテストはMyWorker.new.performで書けばよい
  • 非同期処理をキックする側のユニットテストはMyWorker.jobs.sizeを検証するだけにする
  • エンドツーエンドテストでは「全てのジョブを実行する」というstepやメソッドを作ってそれを呼ぶ

おわり。

WEB+DB PRESS vol.74

一番よかったのは特集2のMySQL特集で、とくに3章の運用ノウハウと5章のInnoDB-memcachedの話がよかったですね。 早速手元のMySQLを5.6にして、試す準備をしたのでした。

あとは、 @yuki24 さんの英語の話は今まで見た事がない切り口ですごく面白かったし、JavaScriptのメモリリークの話はあとで写経していざというときに供えようと思いました。

4774156078.01.MZZZZZZZ.jpg

GW前半終了のお知らせ

今年は余分な休みなど取らずに暦通りにしたので、すでに前半が終わってしまっていた。

だいたい普通の休日と同じように息子と外にでたのと、日曜は久し振りにヒルトン東京ベイのデザートビュッフェへ。

奥さんがそこのクロックムッシュが好きだったのでたまーに行っていたが、数年前に無くなってしまったのであった…

息子はメロンのゼリーを3個にサンドイッチやケーキなど、お腹がパンパンになるまで食べていた

TDDBC長岡にお手伝いに行きますのお知らせ

5/18(土)にTDDBC長岡1.0が開催されます。

以前、開催したいと日記に書いたけどまったく動けてなかったので、せめてお手伝いだけは!という感じで当日お邪魔します。

KeynoteのあとのTDDデモを@setoazusaさんとペアで、また午後のハンズオンではRubyのTA的なところで協力させていただきます。

まだ定員に余裕もあるようですので、近隣にお住いの方は是非ご参加ください!

歓送迎会

部署の歓送迎会(山ちゃんからのBYK)で一回休み。

新しい人が増えるというのは、どんな形であれ刺激になるからいいなぁ。

OctopressからMiddlemanに

Octopressからmiddleman(middleman-blog)に移行してみました。

source/_postをそのままもってきて起動してみるといろいろエラーが出たので、それを適宜直してmiddleman-deployでデプロイ。

  • ファイル名の日付とFrontmatterのdateの値が違っているとエラーが…
  • Frontmatterからlayoutを削除
  • デフォルトのmarkdownインタプリタのmarukuだとin-line HTML(amazonのアサマシとか)をうまく解釈できなかったのでredcarpetに
  • Octopressのgistプラグインを使っていたところを修正
  • シンタックスハイライトはmiddleman-syntaxとrichleland / pygments-cssのgithub.cssで色付け
  • slimを使ったことなかったのでレイアウトとかはslimで
  • マークアップとCSSはlab.ursm.jpを参考に(HTML5勉強になります!)

思ってたより沢山やらないといけないことがあったけど(静的サイトを作るための物なんだから当然…)、一度やってしまえばいいことが多いし、見た目を弄るのはOctopressよりずっと簡単なのでしばらくここに住んでみようと思います。

一杯だけ

のつもりが計3杯。HUB会議室はいろいろ捗ってしまう。

明日から新人sが来るということでフォーメーション的なものの相談をしながら、一方で自分は7年目になり、人生で一番長く同じ組織に所属しているという事実を突きつけられたのであった。

「第1回 Funtoo Linux インストール講習会」開催のお知らせ

Engine Yardが永和システムマネジメントと日本初となる開発パートナーシップを締結を記念して、Engine Yard CloudのベースとなっているGentoo Linuxの派生ディストリビューションであるFuntoo Linuxのインストール講習会を開催することになりました。

計画当初は「第3回 Gentoo Linux インストール講習会」だったのですが、社内でGentoo使っている人もいないし、グーグル先生によればGentooインストール講習会は各地で行われていてキャズムを越えた感があるので、思いきって名前をかえようということになったのでした。

しかも、なんと、今年は新卒の 公式な 受け入れカリキュラムの一つになり(!!!)、新卒氏も何名か参加する予定です。(補足しておくと、新卒氏の参加は業務扱いで代休が与えられます)

Funtoo試してみたいけど、一人だとしんどいという方や、Gentoo使ってるけどFuntooも使ってみたいという方、ぜひぜひ奮ってご参加ください。

第1回 Funtoo Linux インストール講習会

タケシの部屋

事業部長とチーフプログラマ(ursm)とのお食事会(通称タケシの部屋)に御呼ばれしてきた。

開発環境整備班の活動、将来の話とかいろいろできて大変有意義なランチであった。

中間面談

中間面談であった。

今年から目標管理が全面的にgithubのリポジトリにmarkdownを置く形になったので、年間許容Excel量を圧迫されなくなったのだった。

角谷さんと最近どーよみたいな話から、新人についての話とかざっくばらんにした記憶。

Asakusa.rbの花見にお邪魔した

前日がプロジェクトの打ち上げで、お昼までダメージが抜けなかったのでそれからがんばって準備して出発。

まだ体がアルコールを受け入れるのに万全ではないように感じたので、端っこで子供sと遊んでた。

花見どうしようかなぁと思っていたところで丁度よく参加できたので助かりました。

場所取りの方々お疲れさまでした!

プロジェクトの打ち上げ

去年の8月くらいからのプロジェクトが一段落したので打ち上げであった。

個人的には久々の大規模プロジェクトだったので楽しくもあり、苦しくもあった…

Vagrant 1.1.4 のebuildを作成(バイナリパッケージ)

1.x はgemでリリースされないそうなので、ダウンロードページにあるバイナリパッケージ的なもののebuildを esminc/esm-overlay で公開しました。

emerge vagrant-binでインストールできます。

https://github.com/esminc/esm-overlay/pull/3 にもあるようにちょっとよくわからない警告がでるのですが、とりあえずvagrant upは問題なくできているので大丈夫ですかね…

公式の方でも、1.1系がマスクされた状態であるので、それまでの繋ぎとしてお使いください。

VagrantのFuntoo Base Boxを公開しています

最近流行ってますねVagrant。

とにかく簡単にVMが作れちゃうので「これを機にGentooデビューしちゃおっかなー」という人が沢山いるということは想像に難くないところですし、「Funtooにしちゃおっかなー☆」という人も一定数いるに違いありませんよね。

ただ、VagrantUp - www.funtoo.orgでリンクされているBase Boxはportage treeが1年前くらい前の物な上に、emerge --sync; emerge -uDN worldするともれなく数時間コース、そして2、3回つまずくところがって、さらにgrubのメジャーバージョンが挙がってしまうという3重苦のような感じで、ここでも初めて使う人を寄せつけない感じになっております。

そこで数日前(20130307)に更新したBase BoxをDropboxで公開してみました。

https://dl.dropbox.com/u/268888/funtoo-current-20130307.box

変更点は、以下の通りです。

  • 20130307時点のportage treeにsyncしてemerge -uDN world
  • なぜかMAKE_OPTS = -j9となっていたのでMAKE_OPTS = -j3
  • eixが入っている

さくっとfuntooを試してみたい方はvagrant box add funtoo https://dl.dropbox.com/u/268888/funtoo-current-20130307.boxという感じでご利用ください。

今はknife-soloでごにょごにょやろうとしているんですが、knife-soloは/etc/issueを見てディストリビューションを判断する仕組みになっていて、funtooは/etc/issueが無いのでそのままで使えずに、面倒だからveeweeで作りなおすかーということころまでヤクの毛刈りが進んでいるところです。

大江戸Ruby会議03に参加してきた

角谷さんが「ぼくは、地域Ruby会議ってこういうのをやりたかったのでだいぶ満足! #odrk03」と言っていたけれど、その言葉の通り、すばらしい会場と講演者、講演内容でした。

@makoto_inoueさんの話では、同じ受託開発を生業としている会社として興味深いところだらけで、沢山ヒントを貰えた気がします。(特に、数十名の規模で研究開発というか基盤整備みたいな人を配置できるってすごいことですよね)

あとすごく心を動かされたのは、@yotii23さんのRailsGirlsについての話でした。というのも、大学時代の後悔というか、どうしたらよかったのかと今でも悩んでいることが一つあって、その解がRailsGirlsなのかもしれないと思ったのです。

(ここから昔話)

いろいろ縁があって、学部3年から大学院を出るまでの計4年くらいSA、TAをやらせてもらっていたんですが、その中で(それほどプログラミングができるわけではなかった)ある女性に「プログラミングって、Suicaのシステムとか作れるの?すごいじゃん!それならもっと真剣に勉強してたかも…」と言われたことがあって…

言葉尻だけを捉えると「何言ってんのwww」みたいなかんじなんですが、どうやったらその人にプログラミングの可能性というか、楽しみを伝えることができたのかなぁと今でも考えちゃうんですよね。

頭のいい子だったので、プログラミングの楽しさをちゃんと伝えることができたら別の道があったんじゃないかなぁと今でも考えています。

(ここまで)

最後の@nari3の講演はネタのそうじゃないところのバランスが絶妙で、あっという間に終わってしまった、という感じでした。もっと楽しんで、それを仕事にしていきたいですね!

いやーすばらしい会場と講演者、講演内容でした!大切なことなので2回書いておきます。

あと、RubyKaigi2013のLTはEnglish ONLYであるという発表があり、社内SNSに「LTやりたい」と書いてしまった私には、心とトークの準備をする時間が余分に確保できてよかったです…

追記

@makoto_inoueさんからコメントを頂いたのに、諸事情で消えてしまたのでここに転記させていただきます。

@makoto_inoueです。私の講演で何か得るものがあったようで、大変うれしいです。一点訂正ですが、「数十名の規模で研究開発というか基盤整備みたいな人を配置」とありますが、うちは全社員20人の会社で、そのうち2人がBatmanになるよう定期的にまわすようにしています(といってもこのこころみが始まってからまだ3ヶ月しかたっていないのでまわしていませんが)。誤解を招くような表現をしてしまったようで申し訳ないです。

規模に関してはすみません。完全に誤解していました。(すみません)

それでも、そういう試みを始めることができて、3ヶ月は続いているというのはすごいことだなぁと思いました。

カプセルホテルデビュー

人生初めてのカプセルホテル。

社会勉強になりました。