研究会に対して不満に思ったこととりあえずこれだけは書かないわけには行かないと思ってたので書く。なんで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セッション使ってその辺を掘り下げてたり一般化したりした話があってもいいくらいのテーマなのに、それが無かったのが残念だ。最後にいくつか不満は挙げたけども、各発表は興味深いものばかりだったし、この研究会を通じて知り合えた方々からもすごく刺激を受けた。全体としては本当に有益な時間でした。運営の方、発表者の方、休憩時間や解散した後の飲み会でお話させてもらった方、本当にみなさんありがとうございました。2.0読書会に参加してきた。読書会というのに参加したのは初めてだけど、皆で同じ本を読んで、読んだ部分に対して「ここがわからない」「いやそれは実はこういうことで...」というやりとりは中々面白かった。一人で読んでるとスルーしがちなところも拾ってみると勉強になるなぁ。それより何より、Objective-Cなんていうマニアックな言語の、読書会なんていうストイックな催しに、24人も集まったのが凄い。これもiPhone効果かーなんて思ったけど、現時点ではiPhoneを買うと表明した人が少なかったのも印象深かった。いや俺も買わないけど。言えなんだかんだで衝動買いしかねないけど。今日はCHAPTER2とCHAPTER3の途中までを読んだ。CHAPTER2はObjective-Cの基本的な特徴や構文、CHAPTER3がクラス定義と継承だった。2.0を読んでもらうとして、以下は読書会中に挙がった話の補足。init]についてObjCでクラスからオブジェクトを作る場合のイディオムについての話。「allocの後に続けて初期化処理を書かないといけないと言われたことがあるが、それは何故か、どう危険なのか、またそれが必須ならなぜ一纏めにしないのか」との質問が挙がった。allocの後にinitもしくはinit...で始まるメッセージを続ける理由は、呼び出し側でそれを分けて使うことがまず無いから。init];としたところで文法上は問題無いんだけど、NSObjectのクラスメソッドであるところのallocは単にメモリを割り当ててオブジェクトを生成しただけで、それがオブジェクトとして振る舞うためには最初にNSObjectのインスタンスメソッドのinitが呼び出されていなければならず、上のコードの変数objは「なんか別な処理」をしている最中には、「何もできないか、何かさせようとすると異常な挙動をする」。詳しくは見てないけど、NSObjectのinitは結構色々やってるはず。そんな不安定な状態のものを放っておくメリットはよっぽど特殊なケースでないと皆無なので、allocと初期化処理は同時にやってしまうようにしましょうと言う話。何でメモリ割り当てと初期化が別なんだ、一緒でいいだろ、と言われるとちょっと勉強不足で即答できないんだけど、内部的には未初期化のオブジェクトが効果的に使われてるところがあるのかもしれない。いう設計思想だからじゃないか、としかわかんないなー。ちなみに、「allocしてinitしたオブジェクトを返すクラスメソッド」はある。new];って書いても同じ意味になる。これだと引数なしのinitを呼び出すだけなので、引数付きで同等のことをやりたかったらそういうことをするクラスメソッドを定義してやる必要がある。あと、Cocoaのクラスでも初期化で色々ややこしいことしてるやつは、そういうクラスメソッドが用意されている。NSArrayのarrayWithObjects:とか。ちなみに、Fooクラスのクラスメソッドの「fooWithHoge:」と、Fooクラスのインスタンスメソッドの「initWithHoge:」は対応させるのが慣習になっているようだ。2.0には、初期化処理は通常次のようにする、と書かれている。self;}これは実は、次のように書いても大抵の場合問題ない。self;}スーパークラスの初期化処理を明示的に呼び出すことと、returnを省略できないのは変わらないんだけど、明示的なselfへの代入とnilチェックはしなくても処理できる。スーパークラスの初期化処理を辿ってNSObjectのinitが呼び出されると自動的にselfへオブジェクトが代入されるし、仮にselfがnilでも「nilに対するメッセージ送信は単に無視される」。インスタンス変数の扱いとかは危ういけど。何でわざわざselfへの代入を明示的にするのかと言えば、「selfに自分自身じゃないオブジェクトを代入してもいい」上に「スーパークラスのinitの返り値が自分自身とは限らない」から。いうトリッキーな実装も可能なので(例えばNSStringとかは実は結構トリッキーなことをやってる。その話が出てくるのは大分先だけど)、何か特殊なことをするのでない時は上のイディオムで書いた方がいい。selfが自分自身じゃなくてもいいって凄いな。superの意味selfが単にオブジェクトだったのに対し、superは変数に代入したり付け替えたりはできない。superは何かと言うと、「自分より上位の継承関係を辿って行って最初に見つけたクラスの実装を使って、自分のコンテキストでその処理を実行する」という構文。基本的には一つ上のスーパークラスを見て、なければさらに上へ...を繰り返して最終的にはNSObjectまで行く。ここで「一つ上からじゃなくて、スキップしていくつか上のクラスのメソッドを呼び出せるか」という話で盛り上がった。聞いて驚いたんだけど、実はすごくごちゃくごちゃしたコードを書けばできるらしい。実行時に既存のクラスの書き換えまでやってのけるObjective-Cにおいて、コード上の継承関係を元にややこしい処理を行なうのは危険すぎる。最終的には「できるかできないかより、そんなことをしなきゃならないような設計の方が問題だよね」というオチがついた。メッセージセレクタ「メソッドを呼び出す際に引数をつけるときには最後に:を付ける、複数の引数があるときは"keyword:"を並べる」というのを読んで、「第二引数以降にキーワードを付けるのは分かったけど、第一引数の前にはメソッド名があるだけでキーワードが無いけど、付ける方法はないのか」というの質問が上がった。ここはちょっと誤解しやすいポイントかも。メソッド名とかメッセージキーワードとかいう語彙が悪い。forKey:@"name"];こういうときの「メッセージセレクタ」は「setValue:forKey:」のひとまとまりであって、その際に:や後ろのキーワードも含む。Ruby風に書くと、以下のようなイメージ。"name")なので、「最初の一個目がメソッド名で、二個目以降がキーワード」というのは誤り。@selector(setValue:forKey:);などとして「メソッド名を生成」する。ちなみに、最初の「一個目の引数の説明はどこに書くのか」に対しては、「何の引数を取るのかわかるメソッド名にする」が一応答えかな。URLWithString:@"http://www.apple.com"];のように、何の引数を取るか分かるように命名するのが慣習になっている。さっきのsetValue:forKey:も、「最初が値になるオブジェクトで、次がキーになるオブジェクト」ってのが分かるようになってるね。"name")RubyCocoaでOSX::NSObjectを継承したクラスのメソッドを呼び出すときとほぼ一緒(まぁ、そういう風に作ってあるのだけども)。RubyCocoaからMacアプリの世界に入った人は案外、ObjCのメソッド送信がすんなり分かるかもしれない。それ以前にCocoaを知らないとRubyCocoaは分かりづらいって話はあるけど。今日はとりあえず「音読して、途中途中で質疑応答タイムを設ける」っていう形式だったけど、今後は色々試行錯誤していくとのこと。あと、今回は休日だったけど、2時間程度であれば別に平日でも良いのでは?との意見から次回は試しに平日にしてみることになった。2008に行ってきたの続き。拡張ライブラリの書き方講座(artonさん)RubyをCで拡張する方法の解説。朝からマニアックなセッションやるなぁ、と思ったら「朝のうちにマニアックなものをやっておく」という運営側の戦略だったらしい。朝一でつくばまでやって来てる人程マニアックな層なので、この戦略は当たりかもしれない。Rubyの拡張ライブラリは結構簡単に書けるらしい。面白そうなので今度Cの勉強も兼ねて書いてみようかな。大学6年生のhogelogでサンプルがあがってるけど、これはちょっと面白そうだ。あと個人的に興味深かったのは、artonさんがサンプルプログラムが上手く動かなくてその場でデバッグしはじめたとき。artonさんがあれこれ書き換えてる後ろで流されてるIRCのログに、みんなで「ここをこうすればいいんじゃないか」「arton、うしろうしろー!」などと協力してて面白かった。ペアプロならぬテラプロって誰が言ったんだっけ。仕事で使うRuby(ごとけんさん)仕事で使うツールやその運用方法などの紹介。HikiとかRedMineとか。trackingにも使われてるらしい。今度使ってみようかな。あとなんとオープンソース版Fastladderを紹介していただいた。日曜、月曜とFastladderのダウンロード数が増えてたのは間違いなくごとけんさんのお陰だろうと思う。その後twitterで「Fastladderってでも最近全然開発してないよね。飽きちゃったのかな」とか言われてるのを見て焦った。いやいやいやいや、本当すいません、飽きてないですちゃんとやります。中の人二名(二人ともRubyKaigiに行ってました)が中々手が空かず放置気味になってしまってたのだけど、俺の今季の個人目標にはちゃんと「Fastladderの開発」が入ってますので!Googleグループの方にも反応できてなくて本当に申し訳ないんですが、バグレポートや要望など挙げてもらえたら頑張って対応します。Sansonettiさんから。wktkする内容だったんだけど、それにしてもあの盛り上がりようはRubyistのマカー率の高さを示してるのかな。前半はRubyCocoaの紹介で、後半はRubyCocoaが抱える問題点をMacRubyというアプローチで解決していこうとしている、という話。具体的なところは以前書いた記事をご覧下さい。要は「ブリッジではなくObjective-CでRuby処理系を実装することで、ラッパーを介する際のオーバーヘッドや複雑さを避ける」というのが要旨。当然ながら処理速度が飛躍的に早くなるよってところで歓声が上がってた。RubyCocoa使いとしては「NSObjectが基底クラス」ってところが一番の目玉に感じたんだけど、Rubyist視点として興味深いのは、なるべく綺麗にObjective-Cのメッセージパッシングを実現するためにキーワード付き引き数を導入してること。MacRubyは今1.9ベースだけど、この機能は1.9にも無い。これが洗練されてくればMRIにも取り入れられるかもしれないってことで今後に期待。あと、ちなみにMacRubyはiPhoneで動かすことは当分できないそうだ。2.0のGCを使っているので、GCサポートが無いiPhoneのランタイム向けにコンパイルできないらしい。それから質疑応答の光景が中々面白かった。Laurentさんはフランス語が母語?だったようで、込み入った質問になると「日本語で質問→フランス語で通訳→英語で回答→日本語で通訳」とかになってた。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シャツを着てた俺が連れだって歩いてる光景は中々妙な感じだったんだけど誰にもつっこまれなかったのは、ツッコミ待ちなのがバレてたんだろうか。2008に行ってきた表題通り、RubyKaigiに行ってきました。大変に楽しかったし会場中にRuby愛が満ちていて充実した二日間だった。全体のレポートは既にそこかしこであがってると思うし、動画もUPされてるようなのでそちらを観てもらうとして、興味深かったセッションや出来事をいくつか。基調講演(まつもとさん)Rubyは梁山泊になりつつあるんじゃないか、という趣旨の話。それよりも印象に残ったのは「Rubyをキメるとキモチいい」。