RubyKaigi2008 一日目
案の定、起きたら朝ではなかった。YARVやJRubyやRubiniusの話、さらにMatzの基調講演もまるごと聞きのがした。16:00からのセッションとLTだけ見て、懇親会のチケットも買ってなかったのでそこで終了。例によって偏見と思い違いも込みでメモ代わりになぐりがき。
Ruby《を》教えてるんじゃない、Ruby《で》教えてるんだってば(増原英彦)
東大でのRubyを使ったプログラム教育のおはなし。irb上で、eachじゃなくてforを使わせて、クラスを使わないで短いプログラムを記述させるそうな。一発目としてはありかもなあ。
ところで、Rubyを教育の言語として選択したのは増原さん個人の判断ではなくて、何人かの先生の合議だった、とのことだけど、そのメンツがすごかった。直接名前を紹介しないで、各先生のかかわった書籍(論文もあった？)の表紙がざっと表示されただけだったので全員はわからなかったけど、竹内郁雄先生や武市先生は確認できた。多分湯浅先生もはいってた。関数型プログラミング界の御大達がrubyを押すっていうのはちょっとおもしろい。RubyはやっぱりMatzLispなんだな。あー、てことは成功したDylanでもあるのか？
成功するRuby教育のプラクティス(吉田裕美)
請け負ったRuby教育の事例紹介、ということでいいのかなこれは。実習の時に、普通にサンプルを書かせるんじゃなくて、テストケースをこちらで与えてそれに通るコードを書かせるのはよさげ。次のステップとして「じゃあ次は仕様からテストケースを自分で作れるようになりましょう」というのに自然に移行できそうだし。
妄想ひとつめ。そういえば「プログラミングの基礎 ((Computer Science Library))」でも、コードを書く時には、外部仕様を決めて、入出力の型を決めて、それに合うように本体の実装を書かせる、という方向に誘導していた。このへんの思考の流れを強制するように仕様に取りこんだ言語はできんもんかな。
さらに妄想。topcoderでは、与えられたお題を満たすコードを書いて得点を得るフェイズの後に、他人のコードを見て、バグを指摘(仕様と異なる動作をするような入力を送りこんでバグを表面化させる)して成功したら加点、っていうフェイズがある。これも教育に取りこめないかな？
例えば、実習でコードを書かせた後、いきなり講師が採点とかアドバイスするんじゃなくて、このシステム上に全部コードをのっけて受講者みんなに他人のコードの穴をつつきまくらせる。バグの指摘が成功すると結構気持ちいいからそれなりにインセンティブもありそうだし、どれくらいのバグを指摘できたかはその受講者の評価材料にもなりそう。さらにその後に、バグを指摘された人と指摘した人を組ませてペアプロでコードを改良させれば講師の手をわずらわせずに教育効果があがるやもしれない。
RSpecによるRailsアプリケーションBDD事例(Yugui)
今日僕が見たなかでは一番おもしろかった話。危機的なプロジェクトに、subversionやtracを導入し、さらにBDDを基本にすることで、結構スムーズにRailsへのリプレースが進んだ、という事例の紹介。結果的には、本体コード3割、テストコード7割くらいの比率になったらしい。参考になったのは、不慣れな人が多い環境でBDDを推進する時に、まず慣れてる人がお手本となるテストケースを量産しておいて、後から不慣れな人にもそれをお手本にして書いてもらう、という手順。なるほど。
内容とは関係ないけど、このプレゼン、Wiiリモコンでスライドを操作しつつ、ステージの中央あたりで大きめの身振り手振りをまじえてしゃべってたので、たまに踊っているように見えた。生「踊るプログラマ*1」が見れて満足。
一番格好よかったのは、「そんなにテストが多くなると、上のほうからテストじゃなくて新規機能を実装しろよ、という話はでてこないのか？」という質問に対して「『わかってない人は余計なこといわないで黙っててください』で押しとおします(ました？)」と言い切る姿。しびれる。明日本買うのでサインください。
(仮)Ruby技術者認定試験 模擬問題解説(松田慎弥)
Ruby技術者認定試験の傾向と対策、のようなお話。ざっくりまとめると、組込みや標準ライブラリの仕様を暗記するのが重要、らしい。個人的にはrubyを書く時にはirbとリファレンスマニュアルは必須なので、この試験には絶対受からない気がした。ちゅうか、irbやマニュアルくらい使わせてくれてもいい気がするんだけど。ころころ仕様変わるんだしさー。
現に(半分はネタだけど)この発表中に紹介されていた問題の答えを変えちゃうような仕様変更の企みがIRCチャットのほうで高速で進行していた。問題作るほうも受けるほうも大変だな。
以下、Lightning Talksの気になったやつだけ。やっぱこれ書くの疲れるなあ。
RubyとODEでピタゴラ装置 (佐々木竹充)
これはおもしろかった。物理シミュレーションエンジンであるODEをRubyからあやつって、仮想空間上でのプレゼン。キューブに文章がはりつけてあるので、スライドを送る代わりに空間内をWiiリモコンで移動してキューブに注目することでプレゼンがすすむ。さらに空間自体がひとつのピタゴラ装置になっていて、最後に「どーん」と崩壊するキューブ群の中に最後のまとめ文章がしこんである、という趣向。実際には最後にまとめのキューブを探せなくてちゃんと終われなかったのもいい感じ。
欲をいえばこれは、去年のLL Spiritでの「君ならどうかく」(プレゼンテーションソフト編)のセッション*2で見たかった！もうちょっとプレゼン向きの操作*3がそろってれば十分新たなプレゼン手法として確立すると思う。…あーでも物理シミュレーションにする意味はあんまりないかな…。
Rubyで楽しむフォークプログラミング (Webアプリじゃないよ蝙) (高山征大 (mootoh))
個人的に楽しみにしていたLTふたつのうちのひとつ。
デスクトップ上でRubyを使うと結構簡単にリッチなUIをいじれるのでかなり楽しい、最近はWebアプリを書いて楽しむ人が多いみたいだけど、もうWebアプリいっぱいあるし、こういう楽しみ方はどうですか的なお話。
MacOS上でRubyでいろんなスクリプトを書いていろんなサービスのUIを拡張してる事例が紹介されてなかなか楽しめた。でも画像が動くのを想像するのは無理！残念。あと、WindowsユーザーとしてはMac固有の話がどれくらいだったのかが気になるところ。Mac買えってことかなあ。
toRubyでみつけた Rubyist人生再出発 (池澤一廣)
どうにも越えられないRubyの壁に悩んでいたところ、近場に住んでると判明した咳さんにおもいきって出してみたメールがきっかけでtoRuby(勉強会)の企画が持ちあがり、irbを通したオブジェクトの視覚化等々を教えてもらうことによってRubyの見方が変わって壁を越えられたというお話。
わかんない話をわかんないまま諦めないで、駄目元でやってみた行動が次の理解へ繋がった、といういい話だった。
にしても、こういう人に敷居が高いとおもわれてしまうMLというシステムはすこし哀しい。もうちょい緩い場の提供はできないものか。
Ruby 1.9 on Rails 2.1による新時代DBプログラミング (松田明)
えーと、結局DBからデータをひっぱってくるのは集合演算にすぎなくて、SQLはそれを表現するにはちょっとつらい。Rails2.1では集合演算を抽象化して自由に組みあわせられるなんとかいうメソッド(name_scopeでしたっけ？)があるのでそれを使いましょう、という話。
RDBへのクエリはもともと(思想的には)集合演算だろう、とか思ってしまったけど、今頃こんな話がけっこう評判よく紹介されるのは、今迄はSQLの制約がそれを許さなかった、ということなんだろうか。SQLあんまり詳しくないのでよくわからない。
テストベースコードリーディングのすすめ (遠藤侑介)
楽しみにしていたLTふたつのうちのふたつ目。テストのカバレッジを上げる、というのを目的にソースコードを読みすすめる手法の紹介。カバレッジをあげるにはどうしてもコードをちゃんと読まざるをえず、しかも読んだ結果としてテストコードが書ければカバレッジのパーセンテージが上昇するのでやってて達成感がある、とのこと。
たしかに。正直なところ真面目なのかネタなのかわからなかったが、がしがしバグを発見してテストを量産して結果的にRubyのコミッタになった遠藤さんが言うと説得力があるなあ。でもそんな簡単にテストコード書けるもん？「テストのカバレッジを上げる」ってさらっと言ってたけど、それ自体の敷居が結構高いような気がしてならない…。PHPで試してみるべきなのか…。
Industrial-Designed Language: Ruby (斎藤ただし)
最初からの予定だったのか、突然のトラブルだったのか、スライドなしのLT。つまりしゃべくるだけ。しゃべくるだけなのに時間にきっちりおさめたのはすごい。
ふー。疲れた。あさいちがartonさんの話なので明日は遅刻するわけにはいかないのだが、何時に起きればいいのかな…。つくば遠いよー。
*1:http://idm.s9.xrea.com/ratio/2007/05/13/000621.html
*2:http://d.hatena.ne.jp/sshi/20070805/p1を参照のこと
*3:選択したキューブに自動的にずずっとよっていって文章が読みやすい位置に勝手にあわせるとか、あるいはプレゼンのための移動コースをあらかじめしこんでおけるとか、何階層かのレイヤーのスムーズなズーミングとか
