とちぎRuby会議01 LTスライド

LTスライドを下記に置きました。
分散test/unit(LT_d_test.pdf)

この話のメインは30分ほどの間に起きた物語を抽出したものなんですが、もうちょっと考えるとRindaを使うとかあったかもしれません。その時は、どのようにJobを他のprocessに実行させるかが興味深い課題になりそうです。(今ってそんな実装ってないですよね?)
RubyはCodeとDataの区別がはっきりとしないのでDataだけ受け渡すのではない方法を考える必要がありそうですが、果たして簡単に出来る事と出来ない事の境界線は何処に引かれそうでしょうか。

とちぎRuby会議01

行ってきました。
人は多すぎず少なすぎず主催者との距離が近くてこんなRuby会議もいいなぁと思いました。
招待講演も、面白かったり、ためになったり、昔懐かしくなったり。
LTは時間配分を間違えたのが心残り。でもああやって喋るのは楽しいですね。
そして、後の懇親会が豪華すぎる。今日はtest/unitを題材に喋ったのでその流れから角谷さんからRSpecのtest/unitとの違いを熱く語っていただいたり、また皆さんお相手して頂きありがとうございました。LTの発表資料は近い内に上げたいと思いますが、今日はもう疲れたのでそろそろこの辺で。

RubyForgeにプロジェクトを作ってみる。

プロジェクトってどうするのかよく分からないけれども、とりあえずモノは試しとRubyForgeにプロジェクトを登録してみた。これは0から人様に提供できるライブラリを作成するまでの、その記録になるはずである。

さて、そもそも登録するものが無くては始まらないので、今回はたまにしか使わないので放置気味だったrubyソースへのパッチ当てライブラリを持ってきました。
パッチにファイルに当てるのではなく、requireされる時にメモリ上でパッチを当ててから評価する事によってパッチを実現するもので、主に標準添付ライブラリなどを少しだけカスタマイズしたい場合などにメンテナンス性の面からオリジナルには手を入れたくないので使ってた、本体100行にも満たないシンプルなライブラリです。
しかしpatchの解析がかなり適当だったり、当てるファイルの情報を別に与えないといけなかったりするので、さしあたりそのあたりを改善するのが目標。

以下することリスト

  1. http://rubyforge.org/rubyforgeのアカウントを作る。
    まずはアカウントが無いと始まらない。でもアカウントだけは結構前に作ってたので今回はパス。
  2. ログインしたらマイページから新規プロジェクト登録を選択。
  3. プロジェクトFullName、アピール、ライセンス、サマリーに表示させる内容、プロジェクトUnixName、CVS/SVNの選択 を入力する。
    FullNameとUnixNameは、正式名称とURL等で現れる名前との違い。今回は同じrbpatchという名前に。またアピールは書くエリアがかなりでかいのでちょっと躊躇したけれど、分量はあまり関係ないようで、"you can see what happens when apply a patch w/o change original code." なんていう英語として正しいのかどうかよく分からない一文だけで受け付けてくれました。
  4. Submitを押す。

これで承認待ちの状態に入りました。後はrejectされたら悲しいなとSF(Sukosi Fuan)になりながら承認されるのを待ちます。承認者の活動時間帯にもよるとは思いますが、今回は3時間弱で承認を貰いました。

というわけで晴れてプロジェクト発足です。
http://rubyforge.org/projects/rbpatch/
まだドキュメントもsetupスクリプトも入って無い状態だけど、とりあえず第一歩ということで。
やりたいこととやらないといけない事はいっぱいあるので、この話はまだまだ続きます。(たぶん)

テスト駆動開発とビヘイビア駆動開発

Rubyでのテスト用フレームワークを調べてた時にRSpec(http://rspec.rubyforge.org/)でBDDって言葉が出てきてなんじゃらほいと思ったのでそれについてのメモ。

xUnitのようなテスティングフレームワークを使うと、テストの用語から離れるのは難しい。テスト中心の言語で構成されているのだから当然だ。ビヘイビアを仕様化するための新しいフレームワークで始める必要がある。ThoughtWorks社のDan Northは、このためにjBehaveプロジェクトを開始した。 [6] 筆者と数名はRuby上のビヘイビア仕様フレームワークであるrSpec [7] を立ち上げた。rSpecについては、以降で詳細に見ていくことにする。
7 ビヘイビア仕様フレームワーク

では、ビヘイビアの仕様とはどのようなものだろう? パッと見はこれまでのxUnitと変わらないようにみえるだろうし、実際のところ、語彙の違いを除けば今までと同じように使える。TestCaseをサブクラス化する代わりに、Contextをサブクラス化する。メソッドの先頭を「test」で始める代わりに「should」とする。命名規約に煩わされすに適切な名前を選ぶことができる、こちらのほうが好ましいだろう。

http://giantech.jp/wiki/BDDIntro

どうやらやってる事はテスト駆動開発と同じだけど、テストという語彙に引きずられて開発手法であるというのがぼやけるから、名前を変えようという運動のようだ。
地球の引力に引きずられるオールド・タイプの為に楔から解き放ってやろうという事だろうか。
認識をテストからスペックに置き換えた時に明白な実装はともかく、レッド/グリーン/リファクタリングというサイクル、仮実装や三角測量といった概念とうまくすり合わせられるのかがちょっとだけ疑問。もちろん、すんなり合う考え方があるのかもしれないし、また別のいい開発サイクルがあるのかもしれない。その辺はこれからもうちょっと勉強してみよう。

schemeクイッククッキング

ひっそりとschemeやらhaskellやら微妙に勉強中なのですが、そのあたりの師匠のid:sshi先生が最近http://d.hatena.ne.jp/sshi/20070222/p1でqsortの末尾再帰化ってのを書いてた。

が、なんだか理解できなかったので参考にしながら自分でも書いてみることに。

(define (qsort lst)
  (let qs ((acc '())
	   (current lst)
	   (stack '()))
    (if (null? current)
	(if (null? stack)
	    acc
	    (let ((next (car stack)))
	      (qs (cons (cdr next) acc) (car next) (cdr stack))))
	(let ((x (car current))
	      (xs (cdr current)))
	  (receive (gt le) (partition (lambda (y) (> y x)) xs)
	    (qs acc gt (cons (cons le x) stack)))))))

こういうなじみのあるネタで且つ配列物だとlisp素人でも書きやすくていいですね。
これでnamed-let,多値代入,null?,list?,pair?,partition,trace(slib)を覚えたぞ。

しかし、書いている最中に元コードの意味は理解できたけど、pair?とlist?の使い方はなんかアレゲじゃないでしょうか先生。後 traceだと関数の中で定義した関数やnamed-letを使った時に途中経過を追えないのですが、デバックはどういう風にすればいいのでしょうか先生。

おしえてせんせいさん。