As Sloth As Possible

可能な限りナマケモノでありたい

タグ:レポート

今日は東工大で行なわれたSBM研究会に参加してきた。是非感想をmixiかブログに書いてくださいとのことだったので、感想と考えたことをまとめる。

とても新鮮だった

一番印象的だったのは、集まった人に結構いろんな立場の人がいたこと。SBM研究会には、大手SI企業の人、データマイニングやレコメンデーションの研究をしている研究者、Webサービスの開発者や運営者、技術好きな学生などなど。

これはとても新鮮だった。仕事柄というか趣味でというか、ここ最近技術系のカンファレンスや勉強会に何度か足を運んでいるのだけど、その雰囲気とはまるで違う。俺は興味の方向が基本的に「コンシューマ向けのWebサービス」に向いているので、普段はBtoBな業界の方や研究者の方と交流する機会は少ない。こうして同じ場に集まることで、視点の違い、空気の違いを感じられて刺激を受けることができて良かった。

印象に残った発表

どれも興味深い内容だったのだけど、専門的になるし内容も濃いので、具体的な話は発表者の方や他の参加者の方にお任せするとして、いくつか印象に残った発表についての雑感を。

ソーシャルメディアとマーケティング

発表者は学びing株式会社の横田さん。SBMの歴史をざっとなぞり、現状のソーシャルメディアはどういう状況に置かれていて、今後どう展開していくのが良いだろうかという提案だった。

まずSBM、というよりはオンラインブックマークというサービスを、del.icio.us以前の「ブレイク前」と以降の「ブレイク後」に分けて、その違いを考察。最大の違いは「ローカルのブックマークのバックアップ、ストレージであったものが、del.icio.us以降は日用のツールになった」ことだと指摘。また、評価の可視化、ブログの興隆による「パーマリンク」の増加、ソーシャルタギングなどの分類手法が「ブレイク前」とは異なる成功要因である、とも。

次いで現状のSBMの置かれている状況について。「ブレイク後」とは言え、アンケート結果によると日本では7%強程度の「ユーザ」しかいないとの事実を指摘。まだまだSBMはいわゆる「キャズムを越えていない」ものだってのは共通認識ではあるんだけど、実際に数字を見せられると流石に愕然とする。7%って。いかに自分たちがいる界隈が「濃ゆい」集団かってことを再認識せざるを得ない。もちろんこれはSBMを「ツールとして」「意識的に、能動的に」使ってるユーザの話であって、それと気付かず検索結果などからSBMに辿りついたり、実態は領域特化型のSBMだけれどもSBMと呼ばれていないサービスを使っている人は含まれていない。とはいえ、はっきり言ってまだ「あまりにもパイが小さい」のは確か。

それを踏まえた上で、現状で無理に一般層へアプローチするのではなく、「閉鎖空間」をキーワードに、一度ターゲットを狭めて存在感を高めてからより汎用的なものを目指すべきではないか、との提案があった。例えば領域特化型のSBM、イントラSBM、モバイルSBM、など。実際にニッチなSBMやイントラSBMはちらほら存在感を増してきてはいるんだけど、モバイルSBMに関しては今のところまだ目立った成功例がないみたいだし、俺も個人的には懐疑的。理由として横田さんは「mixiやモバゲーなどのコミュニティがサイト内で出しているニュースや更新情報が、PCの文化に置けるSBMの情報配信の役割を果しているのではないか」と言っていたけど、多分、単純に「SBMにポストしづらい」のが最大の原因だと思う。ブックマークレットやアプリケーションを使えないし、URLをコピペしづらいし、それ以前にそもそも携帯端末でのブラウジング中に「URL」を意識する場面が非常に少ない。そういう障害が一気に打破されるような何かが出てこない限り、モバイル文化にSBMは定着しないのかなーと思う。

ちなみに、横田さんのプレゼンはとても面白かった。内容もさることながら飽きさせない話し方が良かった。影響力がもっとも強いのはやるおなのではないか。

Webの世界に「気付き」を集積するコモンズ・マーカー

発表者はコモンズ・メディアの星さん。先日リリースされたばかりのコモンズ・マーカーの紹介。何がどう凄いのかは実際に使ってみたりyuguiさんの記事を見たりしてもらう方が早いと思うので、敢えて解説はしない。

関心したのはそのUIへのこだわり。敢えて付箋のメタファーを捨て、いかにマークとコメントを効率良く閲覧できるかを追求した話は参考になった。そうだよなぁ、他にベターな解があるなら、別に「現実にある何か」に似せる必要はない。この辺はUIの設計の話になるのでまた別の機会につきつめて考えることにする。

あと、印象的だったのは、「引用部とコメントをセットにして一つのマーカー」にする、という見せ方。引用部とコメントが対になっていることで、単体でコンテンツたり得るということ。星さんはコモンズ・マーカーを「注釈を付けるサービスであると同時に、簡単にWeblogを記録できるサービス」だと言っていたけど、これはあれだ…Tumblrに似てるんだ。ページを軸にしてマーカーを並べると、「あるコンテンツに対しての注釈・解釈」に見えるのに、人を軸にして並べると、「その人が何を見てどう思ったのかが綴られた記録」に見える。それだけでその人の個性が出てくるし、それ自体が立派なコンテンツになる。これは面白い。

ただ、見ていて思ったのは、SBMに似てはいるけど、SBMとはまた少しベクトルの違うサービスかな、ということ。今SBMが担っている役割のうち、アノテーションに大きく重心を傾けたサービスのように思える。一応、タギングなども供えてはいるのだけど、評価や分類と言った要素はメインではないし、逆にそっちに重心を戻すとせっかく新しく生まれた魅力が減ってしまう気もする。今後コモンズ・マーカーがどう発展するのか、非常に気になるところ。

パネルディスカッション

パネラーのみずほ情報総研の吉川さんが紹介した、社内SBMの導入事例が面白かった。社内SBMを導入したことで、少なくともユーザ同士は同じ情報を見たという前提を共有できていることで、議論の前段の前提の確認のための時間が減って、よりコミュニケーションに集中できるようになった、とのこと。また、導入当初は一部署で始めて、その後ユーザ数を拡大した際に「ノイズが増えて情報共有のコストが上がる」ことが懸念されたが、「むしろ他部署の動向が知れて有益」と概ね好評でノイズの増加は起きなかった、とのこと。あと、社内文書もクリップできるようにしていたが、実際には社内文書のクリップは殆どされなかった、とも。面白い。うちだったら社内にもクリップしたいリソースは山程あるんだけどなー。

それから、社内SBMを導入したみずほ情報総研、コンシューマ向けにグループ単位のSBM「BuzzurlPlus」をリリースしたECナビが共に「コミュニティを志向し、コメントを付ける文化を求めた」ことも興味深い。ここは実はlivedoorクリップチームも同意見で、今後のSBMの展開にはキーになると思っている。

その他、全体的な印象

レコメンデーションという切り口でSBMに着目している人が多かった印象。確かに、社会学や情報工学の分野の研究材料としては大変面白いデータが集積されているし、マーケティングのツールとしてもレコメンデーションは重要な要素だ。だけど、「コンテンツの評価軸としてのSBM」や「コミュニティとしてのSBM」への言及が少なかったことが気になる。これについては後述する。

あと、まぁ分かり切ってたことだけど、はてブ人気すぎ。ほぼ全プレゼン中で言及されてnaoyaさんがニヤニヤしたり苦笑したりしてるのが面白かった。ただ、まぁ、一応SBMサービスの提供者として言っておくと、「はてブの長所・欠点」をそのまま「SBMの長所・欠点」みたいに語るのはもう少し慎重になって欲しいなと思った。そこ、クリップなら違うことやってんだけど、やっぱ見てないかー、とか何度か言いたくなった。ちょっと残念。まだ努力が必要だなー。

研究会に対して不満に思ったこと

とりあえずこれだけは書かないわけには行かないと思ってたので書く。

なんでmixi?

今回のSBM研究会は、mixiイベントを使って告知され、mixiイベント上で参加者の管理が為された。また、感想もmixiで書くよう勧められ、(参加者は全員mixiのユーザーであるのが前提なので)是非mixi上で交流を持ちましょう、とも言われた。mixiがサービスとして良いか悪いかは話がそれるのでここでは語る気はないが、言いたいのは、SBM研究会という会を運営するにあたってその方法は適切だったのか、ということ。

(追記: 6月末にブログ告知とメール応募もしてたのは知ってたけど、4月時点での告知、5月末のTechTalk.jpでの告知には気付いてなかった。うわー、これは恥かしい。俺の勘違いですね、すいません。まぁでもそれでもmixiイベントでの運用と、感想をmixiに書くように勧めるたことは微妙だなーと思うので、ここの記述は残しておきます。あとTechTalk.jpは素敵すぎる。ちゃんとチェックしとこう。)

mixiは規模こそ巨大ではあるものの、「閲覧にも書き込みにもアカウントが必要なクローズドなコミュニティ」であることに変わりはない。である以上、その中の情報に検索で到達することができないし、SBMを使って周知することもできない。本来ならリーチし得たはずのSBMに関心があり有益な情報を持っている人が、この研究会の存在を知ることができなかったり、知っていても参加できなかったりした可能性がある。

はっきり言う。「SBMの」研究会なのに「SBMがカバーしていない」場所で行なわれる意味が、全くわからない。最初からブログで告知して、メールで参加者を募るなりして、感想はブログに書いてSBMでブックマークすること、という方法の方が適切ではなかったのだろうか。俺だって、Twitterでたまたまこの話を聞かなければそもそも存在すら知らなかった、いや、「知れなかった」。それから、今回の参加者のブログ記事は情報の共有がしやすいように「SBM研究会」タグを付けてください、とまで指示が出ているにも関わらず、一方でmixiアカウントが無ければ閲覧すらできない場所に感想を書くことを推奨するとはどういうことなんだろう。何か理由があるのなら是非教えて欲しいし、そうでないのなら次回以降は違う方法を検討して欲しい。

サービス提供者の視点で語ってくれる人が欲しかった

それから、若干気になったのは、発表内容がビジネスと学術に偏り気味だったこと。例えば、レコメンデーションやフォークソノミーの研究対象として見た場合に、SBMはデータの集合として捉えられる場合が多い。だけどそれだと、ユーザ同士のコミュニティが作る文化や、元のコンテンツに付加されたコメントが生み出す価値や、UIによるユーザ動向の変化など、SBMという「サービス」に重要な要素が出てこない。

もちろん、学術的な研究対象としては非常に扱い辛いものであることも、ビジネスの観点では優先順位として低いことも、十分にわかる。それから、吉川さんや宇佐美さんの話はその辺にも触れたし、コモンズ・マーカーの紹介もあったわけで、それはそれで大変参考になった。だけど、1セッション使ってその辺を掘り下げてたり一般化したりした話があってもいいくらいのテーマなのに、それが無かったのが残念だ。

最後に

いくつか不満は挙げたけども、各発表は興味深いものばかりだったし、この研究会を通じて知り合えた方々からもすごく刺激を受けた。全体としては本当に有益な時間でした。運営の方、発表者の方、休憩時間や解散した後の飲み会でお話させてもらった方、本当にみなさんありがとうございました。

ブログネタ
Objective-C に参加中!

詳解Objective-C 2.0読書会に参加してきた。読書会というのに参加したのは初めてだけど、皆で同じ本を読んで、読んだ部分に対して「ここがわからない」「いやそれは実はこういうことで…」というやりとりは中々面白かった。一人で読んでるとスルーしがちなところも拾ってみると勉強になるなぁ。

それより何より、Objective-Cなんていうマニアックな言語の、読書会なんていうストイックな催しに、24人も集まったのが凄い。これもiPhone効果かーなんて思ったけど、現時点ではiPhoneを買うと表明した人が少なかったのも印象深かった。いや俺も買わないけど。とは言えなんだかんだで衝動買いしかねないけど。どっちだよ。

今日はCHAPTER2とCHAPTER3の途中までを読んだ。CHAPTER2はObjective-Cの基本的な特徴や構文、CHAPTER3がクラス定義と継承だった。内容に関しては詳解Objective-C 2.0を読んでもらうとして、以下は読書会中に挙がった話の補足。

[[Hoge alloc] init]について

ObjCでクラスからオブジェクトを作る場合のイディオムについての話。「allocの後に続けて初期化処理を書かないといけないと言われたことがあるが、それは何故か、どう危険なのか、またそれが必須ならなぜ一纏めにしないのか」との質問が挙がった。

allocの後にinitもしくはinit...で始まるメッセージを続ける理由は、呼び出し側でそれを分けて使うことがまず無いから。別に、

id obj = [Hoge alloc];
/* なんか別な処理 */
[obj init];

としたところで文法上は問題無いんだけど、NSObjectのクラスメソッドであるところのallocは単にメモリを割り当ててオブジェクトを生成しただけで、それがオブジェクトとして振る舞うためには最初にNSObjectのインスタンスメソッドのinitが呼び出されていなければならず、上のコードの変数objは「なんか別な処理」をしている最中には、「何もできないか、何かさせようとすると異常な挙動をする」。詳しくは見てないけど、NSObjectのinitは結構色々やってるはず。そんな不安定な状態のものを放っておくメリットはよっぽど特殊なケースでないと皆無なので、allocと初期化処理は同時にやってしまうようにしましょうと言う話。

じゃあ何でメモリ割り当てと初期化が別なんだ、一緒でいいだろ、と言われるとちょっと勉強不足で即答できないんだけど、内部的には未初期化のオブジェクトが効果的に使われてるところがあるのかもしれない。そういう設計思想だからじゃないか、としかわかんないなー。

ちなみに、「allocしてinitしたオブジェクトを返すクラスメソッド」はある。NSObjectにnewってメソッドが定義されてるので、上記のイディオムの代わりに、

id obj = [Hoge new];

って書いても同じ意味になる。ただこれだと引数なしのinitを呼び出すだけなので、引数付きで同等のことをやりたかったらそういうことをするクラスメソッドを定義してやる必要がある。あと、Cocoaのクラスでも初期化で色々ややこしいことしてるやつは、そういうクラスメソッドが用意されている。例えばNSArrayのarrayWithObjects:とか。ちなみに、Fooクラスのクラスメソッドの「fooWithHoge:」と、Fooクラスのインスタンスメソッドの「initWithHoge:」は対応させるのが慣習になっているようだ。

初期化処理のイディオム

詳解Objective-C 2.0には、初期化処理は通常次のようにする、と書かれている。

- (id)init
{
    self = [super init];
    if (self != nil)
    {
        /* 何らかの初期化処理 */
    }
    return self;
}

これは実は、次のように書いても大抵の場合問題ない。

- (id)init
{
    [super init];
    /* 何らかの初期化処理 */
    return self;
}

スーパークラスの初期化処理を明示的に呼び出すことと、returnを省略できないのは変わらないんだけど、明示的なselfへの代入とnilチェックはしなくても処理できる。スーパークラスの初期化処理を辿ってNSObjectのinitが呼び出されると自動的にselfへオブジェクトが代入されるし、仮にselfがnilでも「nilに対するメッセージ送信は単に無視される」。まぁインスタンス変数の扱いとかは危ういけど。

じゃあ何でわざわざselfへの代入を明示的にするのかと言えば、「selfに自分自身じゃないオブジェクトを代入してもいい」上に「スーパークラスのinitの返り値が自分自身とは限らない」から。そういうトリッキーな実装も可能なので(例えばNSStringとかは実は結構トリッキーなことをやってる。その話が出てくるのは大分先だけど)、何か特殊なことをするのでない時は上のイディオムで書いた方がいい。てかselfが自分自身じゃなくてもいいって凄いな。お前は誰だ。

superの意味

selfが単にオブジェクトだったのに対し、superは変数に代入したり付け替えたりはできない。多分予約語なんだよな。superは何かと言うと、「自分より上位の継承関係を辿って行って最初に見つけたクラスの実装を使って、自分のコンテキストでその処理を実行する」という構文。難しいね。

基本的には一つ上のスーパークラスを見て、なければさらに上へ…を繰り返して最終的にはNSObjectまで行く。ここで「一つ上からじゃなくて、スキップしていくつか上のクラスのメソッドを呼び出せるか」という話で盛り上がった。聞いて驚いたんだけど、実はすごくごちゃくごちゃしたコードを書けばできるらしい。けど、実行時に既存のクラスの書き換えまでやってのけるObjective-Cにおいて、コード上の継承関係を元にややこしい処理を行なうのは危険すぎる。最終的には「できるかできないかより、そんなことをしなきゃならないような設計の方が問題だよね」というオチがついた。そりゃそうだ。

メッセージセレクタ

「メソッドを呼び出す際に引数をつけるときには最後に:を付ける、複数の引数があるときは"keyword:"を並べる」というのを読んで、「第二引数以降にキーワードを付けるのは分かったけど、第一引数の前にはメソッド名があるだけでキーワードが無いけど、付ける方法はないのか」というの質問が上がった。ここはちょっと誤解しやすいポイントかも。多分、メソッド名とかメッセージキーワードとかいう語彙が悪い。

例えば、

[obj setValue:@"hoge" forKey:@"name"];

こういうときの「メッセージセレクタ」は「setValue:forKey:」のひとまとまりであって、その際に:や後ろのキーワードも含む。ちょっと無理矢理にRuby風に書くと、以下のようなイメージ。

# Rubyではメソッド名に:は使えないけど、仮に使えるとしたら
obj.setValue:forKey:("hoge", "name")
# もっと言うと、こういうイメージかも
# この方が「メッセージパッシング」っぽいし、
# 実際こういうメソッド呼び出しの方法はObjCにもある、
# というか内部的にはCの関数でこういうことをしている
obj.__send__(:setValue:forKey:, "hoge", "name")

なので、「最初の一個目がメソッド名で、二個目以降がキーワード」というのは誤り。一見分かれてるようだけど「全部くっつけたもの = メソッド名」だと思った方がいいし、セレクタ(SEL)を使って上のRubyの__send__みたいなことをやるときは正に、

SEL sel = @selector(setValue:forKey:);

などとして「メソッド名を生成」する。

ちなみに、最初の「一個目の引数の説明はどこに書くのか」に対しては、「何の引数を取るのかわかるメソッド名にする」が一応答えかな。Cocoaだと一個の引数を取るメソッドは例えば、

id url = [NSURL URLWithString:@"http://www.apple.com"];

のように、何の引数を取るか分かるように命名するのが慣習になっている。さっきのsetValue:forKey:も、「最初が値になるオブジェクトで、次がキーになるオブジェクト」ってのが分かるようになってるね。

ところで、ちょっと違う話になるけど、

# これはさっきの偽Ruby
obj.setValue:forKey:("hoge", "name")

これ何か見覚えあるなぁと思ったら、

# これはRubyCocoa
obj.setValue_forKey("hoge", "name")

RubyCocoaでOSX::NSObjectを継承したクラスのメソッドを呼び出すときとほぼ一緒(まぁ、そういう風に作ってあるのだけども)。RubyCocoaからMacアプリの世界に入った人は案外、ObjCのメソッド送信がすんなり分かるかもしれない。でもそれ以前にCocoaを知らないとRubyCocoaは分かりづらいって話はあるけど。ジレンマ。

詳解Objective-C 2.0読書会の今後

今日はとりあえず「音読して、途中途中で質疑応答タイムを設ける」っていう形式だったけど、今後は色々試行錯誤していくとのこと。あと、今回は休日だったけど、2時間程度であれば別に平日でも良いのでは?との意見から次回は試しに平日にしてみることになった。多分今月中にもう一回ぐらい開催されることになりそうなので、興味ある人はメーリングリストに参加してみるといいよ!

今週いろいろと忙しかったせいで「あとで書くと言ったまま書かないメソッド」が発動してしまって大分出遅れた感があるんだけど、RubyKaigi 2008に行ってきたの続き。

拡張ライブラリの書き方講座(artonさん)

RubyをCで拡張する方法の解説。朝からマニアックなセッションやるなぁ、と思ったら「朝のうちにマニアックなものをやっておく」という運営側の戦略だったらしい。朝一でつくばまでやって来てる人程マニアックな層なので、この戦略は当たりかもしれない。

Rubyの拡張ライブラリは結構簡単に書けるらしい。面白そうなので今度Cの勉強も兼ねて書いてみようかな。ruby拡張を書いてみるテスツ - 大学6年生のhogelogでサンプルがあがってるけど、これはちょっと面白そうだ。

あと個人的に興味深かったのは、artonさんがサンプルプログラムが上手く動かなくてその場でデバッグしはじめたとき。artonさんがあれこれ書き換えてる後ろで流されてるIRCのログに、みんなで「ここをこうすればいいんじゃないか」「arton、うしろうしろー!」などと協力してて面白かった。ペアプロならぬテラプロって誰が言ったんだっけ。

さらに仕事で使うRuby(ごとけんさん)

仕事で使うツールやその運用方法などの紹介。HikiとかRedMineとか。RedMine今回色んなセッションで紹介されてたし、Ruby本体のissue trackingにも使われてるらしい。今度使ってみようかな。

あとなんとオープンソース版Fastladderを紹介していただいた。日曜、月曜とFastladderのダウンロード数が増えてたのは間違いなくごとけんさんのお陰だろうと思う。

でもその後twitterで「Fastladderってでも最近全然開発してないよね。飽きちゃったのかな」とか言われてるのを見て焦った。いやいやいやいや、本当すいません、飽きてないですちゃんとやります。中の人二名(二人ともRubyKaigiに行ってました)が中々手が空かず放置気味になってしまってたのだけど、俺の今季の個人目標にはちゃんと「Fastladderの開発」が入ってますので!Googleグループの方にも反応できてなくて本当に申し訳ないんですが、バグレポートや要望など挙げてもらえたら頑張って対応します。

The future of Ruby in Mac OS X(Laurentさん)

RubyCocoaとMacRubyの紹介をApple社員のLaurent Sansonettiさんから。大変wktkする内容だったんだけど、それにしてもあの盛り上がりようはRubyistのマカー率の高さを示してるのかな。

前半はRubyCocoaの紹介で、後半はRubyCocoaが抱える問題点をMacRubyというアプローチで解決していこうとしている、という話。具体的なところは以前書いた記事をご覧下さい。要は「ブリッジではなくObjective-CでRuby処理系を実装することで、ラッパーを介する際のオーバーヘッドや複雑さを避ける」というのが要旨。当然ながら処理速度が飛躍的に早くなるよってところで歓声が上がってた。

RubyCocoa使いとしては「NSObjectが基底クラス」ってところが一番の目玉に感じたんだけど、Rubyist視点として興味深いのは、なるべく綺麗にObjective-Cのメッセージパッシングを実現するためにキーワード付き引き数を導入してること。MacRubyは今1.9ベースだけど、この機能は1.9にも無い。これが洗練されてくればMRIにも取り入れられるかもしれないってことで今後に期待。

あと、ちなみにMacRubyはiPhoneで動かすことは当分できないそうだ。メモリ管理にRubyのGCではなくObjC 2.0のGCを使っているので、GCサポートが無いiPhoneのランタイム向けにコンパイルできないらしい。これはちょっと残念。

それから質疑応答の光景が中々面白かった。Laurentさんはフランス語が母語?だったようで、込み入った質問になると「日本語で質問→フランス語で通訳→英語で回答→日本語で通訳」とかになってた。マルチリンガル!

Real-World Enterprise Ruby(大場さん、高井さん)

企業向けの開発でRubyを導入するにあたってのノウハウを伊藤忠テクノソリューションズの二人から。内容的には非常に真面目な話な上、二人ともスーツでステージに立ってたにもかかわらず、IRCでは「スーツがコスプレにしか見えなくなってきた」「漫才が始まった」などと盛り上がっていたのでなんだろうと思って行ってみたら、確かに面白いことやってた。なんでそんなことになったのかは高井さん大場さんのキャラクターから推してしるべし。

ちなみに内容はSI業界の人にはかなり参考になったんじゃないかと思う。yuguiさんの「わかっとらんやつは黙ってろ」とは対照的な、上司や顧客にRuby導入を承認させる方法とその効用についてがよくわかるセッションだった。

最後に

仕事柄大変Perl充な日々を送っているのだけど、久々に2日間丸々Rubyまみれな時間を過させてもらって本当に楽しかった。RubyKaigiスタッフの方々、スピーカーの方々、会場でご一緒させてもらった方々に心からの感謝を。

それから車を出してくれたsotarok、家に泊めてくれたdaftbeats、俺が頼まれてたyuguiさんのサイン入り初めてのRubyを代わりに確保してくれたfrom_kyushu、本当に助かりました。ありがとう!ハチロク世代++。

追記

あと俺何気にRubyConfのTシャツやらJRubyのTシャツやらを着てた。初めてのRuby片手にPHPTシャツを着たsotarokと、Sunと何の繋りもないのにJRubyTシャツを着てた俺が連れだって歩いてる光景は中々妙な感じだったんだけど誰にもつっこまれなかったのは、ツッコミ待ちなのがバレてたんだろうか。

表題通り、RubyKaigiに行ってきました。大変に楽しかったし会場中にRuby愛が満ちていて充実した二日間だった。全体のレポートは既にそこかしこであがってると思うし、動画もUPされてるようなのでそちらを観てもらうとして、興味深かったセッションや出来事をいくつか。

基調講演(まつもとさん)

Rubyは梁山泊になりつつあるんじゃないか、という趣旨の話。が、それよりも印象に残ったのは「Rubyをキメるとキモチいい」。ええ。キモチいいですね。うふふ。

Ruby M17N(成瀬ゆいさん、Martin J. Dürstさん)

Ruby1.9からは多言語対応のため文字列の扱いが大きく変わっている。唯一の内部エンコーディングを持たず、内部で変換をかけたりもしない、Stringオブジェクト自体がエンコーディングを持つ、とか。話には聞いてたけど1.9はまだあんまり弄れてないので興味深かった。

個人的には「内部エンコーディングを持たずソースコードやStringオブジェクトの単位でエンコーディングが決まってしまうとなると、例えば日本語を処理するライブラリなどを書くときに上手く実装するのが大変になるのではないか」っていう話が気になった。多分、受けとった文字列のエンコーディングを記憶しておいて一旦変換し、処理が終わったら最初のエンコーディングに戻して返す、とか、マルチバイトの文字列を返すメソッドはオプションでエンコーディングを取る、みたいなのが基本になると思うけど、若干前より泥臭くなってる印象もなきにしもあらず。

RSpecによるRailsアプリケーションBDD事例報告(yuguiさん)

最初サブセッションの方にいたんだけど、なんかメインの方で俺のID(faultier)が連呼されててびっくりして行ったら、案の定以前一緒に仕事してた会社での事例だった。うひー。妙な汗かいた。

で、肝心のBDDですが、これは確かに実績を上げてました。RSpecとSeleniumを使うようになって格段にバグも減ったし、「何をやってるか知りたければまずSpecを見ろ」っていう習慣も自然に浸透したし、LLに不慣れなベテランプログラマや新人プログラマを含む混成部隊でもペアプロのお陰で開発速度を維持できたし全体の技術水準も上がりました。

あと余談だけど、「Specのないコードを書くときは上長に申請書を提出させる」とか「ペアプロ時にはナビゲータはピコピコハンマー装備」とか、今回の名言「わかんないやつは黙ってろ」とか、本当にやっちゃう人ですからねyuguiさんは。実際に。そこに痺れる憧れる。

Rubyで快適に連投する11の方法(ujihisa)

ujihisaの集客力は異常。

1日目終了後

ハチロク世代+α、つくばクラスタ、懇親会難民だったTAKESAKOさん、が合流して会場付近の魚民でYet Another 懇親会。幹事を努めてくれたdaftbeats、はるばる九州からきてくれたfrom_kyushu、お疲れ様!

楽しく飲んだ後はdaftbeats家におじゃまさせてもらった。hacktour組に対抗して夜通しRubyプログラミング、の予定だったけどIRCボットと戯れてるうちに夜が更けてた。何してんだ俺。

続きはあとで

長くなりそうなので2日目のことは後でまた書きます。

↑このページのトップヘ