本を読む

読書やコンピュータなどに関するメモ

RubyKaigi 2009に参加しました

 7月17~19日に、RubyKaigi 2009というイベントに参加しました。プログラミング言語Rubyに関するカンファレンスです。あっという間の3日間だったなあ。講演者やスタッフなどの皆さん、ありがとうございました。

 鳥頭の私は、聞いているだけだとすぐ忘れてしまうので、メモをとりながら話を聞きました。実際、メモを見返したら、すでに忘れていることがいろいろあったという次第。とりあえず、メモの整理と内容の復習をかねて、ブログに載せておきます。間違いなどありましたらご指摘ください。

1日目(7月17日)

Using Git and GitHub to Develop One Million Times Faster(Scott Chacon)

 一番手は、みんな大好きGitHubを作った人の講演。gitの効率的な使い方と、それを実現するための道具としてのGitHubを解説しました。なお、Chaconさんは、gitの解説サイトgit-scm.comも運営していて、解説書をPDFで公開しているそうです。講演の内容は、早口の英語でしたが、図をまじえて、構成もわかりやすくなっていました。

 Chacon氏は、まずgitとはなにか解説しました。Linuxカーネルの開発のために作られたのオープンソース分散バージョンコントロールシステムで、完全分散、速い、すべてのクローンはバックアップなのでオフラインで使える、Immutable(データは消えない)という特徴があるとのことです。

 続いてgitの基本操作と内部構造を解説しました。詳細は省略しますが、データオブジェクトがユニークな識別値を持って、それがリポジトリ、インデックス、ワーキングディレクトリの3種類の場所を行き来します。コミットオブジェクトが一つ前のコミットオブジェクトを指していくことで、一連の更新が表現されます。

 ここでブランチの概念が登場します。ブランチはコミットオブジェクトへの軽いポインタで、複数を作って、現在作業しているブランチを切り変えたり、マージしたりできます。

 それをふまえて、gitは個人で使うにも便利という話になりました。ネットワークなしでも使えますし、差分やファイル履歴を高速に見られます。そこで、Quiltのようなパッチ管理システムがわりに、「直線的じゃない開発工程」のためにgitのブランチを使う方法(トピックブランチ)を紹介しました。パッチが固まったら、git format-patchでまとまったパッチを生成してメンテナにメールし、メンテナはgit amでマージできます。メンテナはブランチを切ってからマージすれば、テストもできるし、駄目だったら簡単に戻せます。また、git rebaseのしくみと使い方も解説されました。

 個人の次は、一人ではなくチームで共同開発する場合の話です。全員が使う共有リポジトリを1つ立てるという方法もありますが、pushしたあとに別の人がpushすると、pushしようとしたときにエラーになったりします。

 そこでgit的な方法が、各開発者が公開リポジトリを持つ方法です。各開発者は各自のリポジトリにpushして、メンテナなどが変更を取り込むには各自のリポジトリからpullします。まさにGitHubのやりかたですね。たとえば、linuxカーネルはサブシステムごとのリポジトリがあって、「独裁者」がpullするようになっているそうです。また、gitなら、中央リポジトリがダウンしたらテンポラリなリポジトリにpushすればいいので、SPOF(single point of failure)にならないという話もありました。

 最後はもちろん、GitHubを使おうという話です。cloneもフォームも楽だし、パッチも楽に公開できる。いわく、75%のフォークしたプロジェクトは本家に反映されているし、18,000のプロジェクトに最低1人のwatcherがついているとのことです。また、プロジェクトやソースの検索も簡単です。GitHubにホストされたプロジェクトの実例として、Ruby用gitライブラリGritや、GitHub自身などが紹介されました。

 なお、質疑応答によると、GitHubを作った動機は「gitサーバーを用意するのはとてもめんどうくさいから」だそうです。

Pragmatic Patterns of Ruby on Rails - 現場で役立つRuby on Railsパターン(大場寧子)

 RailsやiPhoneのアプリを開発している、株式会社万葉の社長の大場さんが、「Railsの定石テクニック」をいくつか紹介しました。大場夫妻や万葉は「Ruby on Rails逆引きクイックリファレンス」(毎日コミュニケーションズ)も書いています。

 Railsを使ってチームでアプリを開発するときのの課題として、書きかたがばらばらになってソースごとに癖があったり、品質が揃ってなかったりする問題があります。そこで大場さんは、コードをいい状態に保つためのいい設計やパターンが重要だと語り、読みやすくわかりやすいコードであれば間違いにも気付きやすく効率も上がるという利点を上げました。想定している規模は、10人以上が4~5か月開発し、数年間メンテするアプリです。

 基本はActiveRecordの特性や機能を生かすこと。オブジェクト指向で書けて、複雑さに耐えられ、実用的ということです。

 最初に出された例は、アクセスしたユーザーが権限を持つレコードだけを表示する方法。モデルクラスのfind系クラスメソッドを使う方法はいくつかあるが、条件を忘れても気付きにくいという弱点がある。そこで、データのモデルとユーザーのモデルをhas_manyで関連づけて、モデルオブジェクトを起点としてインスタンスメソッドのfindを使う方法が紹介されました。問題があったときに気付きやすいし、データの権利者がひとめでわかるということです。

 続いて、上の例の発展形として、ユーザーをグループに変えた場合です。ユーザーはrestful_authenticationで与えられますが、グループは事前にグループのモデルを取得しなければなりません。この場合、個々のメソッドでfindするのではなく、findするメソッドを作ってbefore_filterに設定する方法が紹介されました。このようにactionの前後に行いたい処理をフィルターにすると、宣言的でDRYになります。アクセス制限を変えるのも楽ですし、グループでの絞り込みを忘れないという意味でセキュアになります。コーディングスタイルでも自然な強制力がはたらいて新しいメンバーも合わせるようになりますし、controller名の直後に書かれるのでわかりやすいとのことです。

 次の例は、複雑なロジックをcontrollerではなくmodelに書くためのパターンです。ビジネスロジックは、テストしやすさや再利用しやすさ、コードが分散しないことなどから、できるだけmodelに書きたいところです。が、modelに移すというだけでは、modelにdo_crateやdo_destroyというメソッドを作るという、まるでcontrollerのような再利用性が低いコードになりかねません。そこで、Webのフォームのチェックボックスによって保存形式を変えるコードを、controllerからmodelへ移すときの例を紹介しました。

 まず、viewを変更してチェックボックスを単独のformとし、paramsで取れるようにします。モデルのほうではチェックボックスの値をmodelでattr_accesorにし、その値で分岐します。続いて、チェックボックスの値によって保存する形式を変えるために、データ変換処理をprivateメソッドにしてbefore_saveでかませます。これで、条件分岐のロジックがmodelに実装されます。この処理場所はいろいろあるので、適切な場所に入れることで、バリデーションをするかしないかなどをうまく選べます。

 まとめとしては、ビジネスロジックをテーブルではなくmodelで表現すること、DRY・CoC・RESTfulというRailsの原則にしたがうこと、modelの基本的な流れ(CRUD)に乗せること、という「Rails において何が自然か」が重要と語りました。そして、Railsプログラマにとって標準的な書き方は読みやすいし、そのためにこそRubyの柔軟性が使える、と締めました。

『エンタープライズRails』に学ぶ企業ユーザのためのRails活用の極意(高井直人)

 このセッションを聞いたのですが、メモをなくしてしまいました。面白かったのですが、残念。

 記憶によると、内容は、新刊「エンタープライズRails」(オライリー)のエッセンスを紹介したものでした。エンタープライズな現場では、複数アプリがデータベースにアクセスするので整合性が保証されず、それを保証するためにデータベースの制約条件を活用しようという話。紹介したケースの中では、Railsにまかせると複雑なSQLになってしまうのを制約で単純化する例などもありました。ただし、これらを使うにはMySQLでは機能が足りず、PostgreSQLがいい、というのが原著者の主張だそうです。あと、それ用のSQLは自分で書いてexecuteする必要があるそうです。

 Web系とエンタープライズ系では考え方がまったく違う部分がいろいろあるけど、Web系の人も「エンタープライズRails」を読んで、違いを知ってほしいとの話もありました。

 ちなみに、スーツコスプレと飄々とした語り口で笑わせていました。

From Rails to Rack: Making Rails 3 a Better Ruby Citizen(Yehuda Katz)

 Rails 3にマージされる予定の、Merbの開発者による講演です。MerbはRailsから分岐して独自に進化したフレームワークです。英語もMerbもよくわかってないので、聞きとれた(つもりの)範囲でのメモです。

 Katzさんは、かつてPHPなどでプログラミングしていましたが、RailsからRubyに入り、今はEngine Yard社でRailsやRubyの仕事をしているそうです。タイトルも、「Ruby市民としてよりよいフレームワーク」という意味だそうです。

 Merbは3年前に開発を始めました。Katzさんによると、シンプルなコアを中心として高速で強力なフレーワークとのことです。MerbはRack、JSON、Erubisなどを取り込み、DataMapper、jQuery、CouthRestなども組みあわせるようになっています。これをeco systemと表現しました。

 また、通常のRubyコードとの親和性を意識していて、ほかのRubyコードからMerbのパーツを利用できる、コンポーネント化がなされているそうです。たとえば、通常のRubyのオブジェクトをモデルとして扱い、バリデーションなどもできるActiveModelが紹介されました。

 MerbはRailにくらべて分離したアーキテクチャを取っています。Rails 2.3では、3つのMVCのgemがけっこう密接に関係していますが、Merbでは3者を分離します。また、Rails 2.3では「require "active_support"」とすると大きなライブラリを読み込んでしまいますが、Merbでは「require "active_support/all"」や「require "active_support/ruby/shim"」のようにパーツごとにrequireできるそうです。これを、Pythonの「from * feature *」構文になぞらえて説明しました。

 ActionPackの処理も巨大で遅くなっているので、sinatraのようなシンプルな記述でルーティングなどを定義できるActionController:Httpクラスなども用意します。

 また、コントローラのアクションで、layoutメソッドでクラス全体のレイアウトを指定しつつ、アクション単位でrenderメソッドに:layoutオプションを指定できるようになっています。このようなRuby的なオーバーライドの機能によって、ハックなしにレイアウトを変更できて、RJSテンプレートをつけはずししたりもできるとのことでした。

 そのほか、JSONのバックエンドを影響少なく切り変える機構や、moduleのextendedとdepends_onでクラスっぽくメソッドの継承やsuperが使える機能、isoltation testの機能なども紹介されました。

 質疑応答では、高度になって入門者にわかりにくくないかという疑問が出されました。これに対し、デフォルトの部分は大きく変えず、高度な使い方をする場合に今回紹介した機能を使えるようになっているという説明でした。また、Rails2Compatibilityモジュールにより、method_missingなどが提供されるとのことです。また、プラグイン機構が大きく変わることについては、いままでちょこちょこ変更されていたので、今度はしっかりしたAPIを決める、との回答でした。

LT:前説(前編)(igaiga)

 初日はここからLightning Talk(LT)でシメでした。最初はスタッフのigaigaさんが、前説として2分半で発表。LTに応募したものの、落選したので、LT用のタイマーソフト「TwTm」を作って採用された話。IRC表示の機能やスター表示の機能などがあるそうです。

 ちなみに実は、会場に入るのがちょっと遅れて、これの最初のほうを聞きのがしました。

LT:パターン、Wiki、XP、そしてRuby(江渡浩一郎)

 最近出版した書籍「パターン、Wiki、XP」の内容をもとに、上記の4つが実は同じルーツを持っているということを話しました。自身のルーツとしては、Wikiに興味を持って独自のWikiエンジンqwikWebを開発。qwikWebに機能を追加するうえで、Wikiの本質を理解しようと調べたところ、クリストファー・アレグザンダーやSmalltalkの思想が源流になっていたということで、書籍の骨子を説明しました。

 なお、書籍についてブログでの感想を求む、とのことでした。

LT:Ruby/Tkは本当にダメな子なのか?(永井)

 ウィンドウなどのGUIライブラリ「Ruby/TK」について、批判が多いということでユーモラスに反論するトークでした。開発が止まってはいない、オブジェクト指向のAPI、使ってない人が「使わない」と言う、大クラス主義、多数の拡張、など「実は奥が深い」と説明されました。ただし、ドキュメント不足という批判には「ごめんなさい」とのことでした。

LT:たぶん一番かんたんなRails on GAE/J(あんどうやすし)

 Google AppEngine/JavaでJRubyとRailsを動かす話。JRubyのコミッターの人が、GAE/Jがでた翌日にRailsをうごかしてみせたけど、ファイル数制限や容量制限などの単純なところが大変、そこでRails 2.3のテンプレートを作った、使いそうなライブラリもついてるよ、という話でした。

LT:IronRuby on Rails(荒井省三)

 マイクロソフトの言語処理系マニアとしてその筋では知られる荒井さんのトーク。IronRuby 0.5.0でweblickが動いたということで、Railsを動かしてみせました。ActiveRecordでSQLServerに接続するそうです。起動にちょっと時間がかかるのが弱点だそうです。あと、フィードバック募集中、とのこと。

LT:むいちゃいました(仮)(gaooh)

 ドリコムでCGMサイトを作るために開発したRailsアプリケーションunshuを、オープンソースにしたということで紹介するトークでした。「オープンソース化」=「むいちゃう」とのことです。ブログやSNSなど、さまざまなWebアプリの基盤になるもので、ドリコムの使っているプラグインを標準装備しているとのこと。安心のテストコード、迷わないためのルール、冗長化や負荷対策などの機能があり、Webアプリをmixiアプリにする機能や管理画面なども開発中とのことです。

LT:Wakameで手早くRailsを大規模サイトにする(山崎泰宏)

 仕事の忙しいときにアクセスが激増、明日までにスケールアウトしなくちゃならない、というときに、Amazon EC2なら安心、でも新しいインスタンスのセットアップは面倒、ということで開発されたツールwakameの紹介でした。たとえばPassengerを10個に増やすとか、MySQLを5個に増やすとかを設定して、あとはみてるだけだそうです。wakameで、スケールアウトの大規模サイトの運用経験のない人でも安心、ということでした。

LT:JCLのご紹介(相澤歩)

 COBOLなレガシーシステムからのマイグレーションの話。COBOL自体はそんなに問題じゃなくて、JCLによるリソースの割り当てと開放などの処理が大変とのことで、Rubyの内部DSLで相当する処理をするようにしたという話でした。ほか、DB関係も問題になるとのことでした。

LT:Arabesque, a brand new Ruby queue(Mohammad A. Ali)

 Berkeley DBを使ったインプロセス型のキューサーバーの紹介。マルチコアCPUで、1プロセスが書き込んで複数プロセスが読み出すというのを並列化できるスケーラビリティが特徴とのこと。データは共有メモリに置かれ、RubyのGCの対象外になるそうです。ただし、弱点としては、複数のサーバーではスケールしないとのことでした。

LT:MiyazakiResistanceを作ってみたよ(おおいしつかさ)

 TokyoTyrantはKey-Value型DBですが、表構造を持てるので、ActiveRecordのようなAPIのライブラリを作ったという紹介でした。名前も、「TokyoTyrant」に対して「MiyazakiResistance」だそうです。レプリケーションやデュアルマスターにも対応しているそうで、なんと勤務先の食べログでも実験的に使っているそうです。

LT:ローカル環境向けKey-Valueストアの紹介(仮)(こしばとしあき)

 おそらくこの日のLTでいちばんウケた発表でした。オンメモリで動きつつ永続化でき、一般のビジネスパーソンが使えるGUIフロントエンドを持ったKey-Valueストアを、Rubyアプリのバックエンドに採用した、その名もExcel!という話でした。

LT:WebスタートアップにやさしいRailsの育て方(松本一輝)

 世界中の人が母国語を教えあうSNS「Lang-8」のバックエンドの紹介でした。Amazon EC2上でRailsを使ってスケールアウトしようとするのだけど、クラウドDBは遅いので、RDBMSに見せるラッパーを作ってそこでキャッシュしまくって、まあ実用的な速度になった、という報告でした。

2日目(7月18日)

Ruby 1.8のゆくえ(卜部昌平)

 2日目は、Ruby 1.8と1.9の現状をそれぞれメンテナさんが解説するところから見ました。

 まずは、Ruby 1.8の安定版のメンテナの卜部さん。まず、コミットやブランチの進み具合をグラフで説明しました。1.8系は最近ではリリース間隔が伸びていて、またブランチごとにそれぞれメンテナがついているという状況だそうです。

 1.8.6は、Kirk Hainesがメンテナ。もともと終了の方向だったのだが、1.8.7が1.8.6と互換性がないと一部ユーザーに「誤解」されたため、メンテナンスの要望が出て、Kirkさんが立候補したそうです。卜部さんは、彼らが長くメンテすることに期待すると語っていました。

 Kirkさんは、メンテナンスのほかに独自にパッチを取り込む方向だそうで、メモリ管理まわりを大きく変更するMBARIパッチや、x86に特化してスレッドを高速化するJoe Damatoさんのパッチなどの採用を考えているそうです。ただし、会場ではMatzさんがMBARIパッチに反対の意を示していました。

 1.8.7は、卜部さんがメンテナの安定版。「安定にしようとしているけど、バグが減らない」とのことで、「コミット数に0.3をかけるとバグフィックス数になる」と自虐ネタも語っていました。フィックスの優先順位は、セキュリティ対策、バグフィクス、テストのフィックス、ドキュメントのフィックス、ビルドシステムのフィックスの順だそうです。

 1.8.8開発版は武者さんがメンテナ。機能としては一応の完成で、「1.9への移行を楽にする」のがテーマだそうです。移行を楽にするという実例としては、たとえば「if RUBY_VERSION >="1.9.0"」で1.9用のコードと1.8用のコードを切り分けて実行時に判別しようとしても、現状の1.8では1.9のコード部分が(実行はもちろんしないものの、その前に)パース段階で文法エラーになってしまうことがあるそうです。これを、実行はどもかく文法エラーにならない方法を考え中だそうです。鬼車の正規表現とかキツいと思うけどがんばりたい、JRubyなども同様に切り分けられるようにしたい、とのことでした。なお、1.8.8については、リリース予定などはまだ未定だそうです。

 今後については、1.8.9は出さないで1.9に移行してもらう方向、1.8.5は1.8.8が出たら終了の方向。1.8.7は、いままでのポリシーからするとずっとメンテナンスすることになるが、それは考え中とのことでした。

Ruby 1.9.2ロードマップ(Yugui)

 続いて1.9メンテナのYuguiさん。まず最初に、Ruby 1.9.1-p243とRuby 1.9.2 preview1を会場からリリースできるとカッコいいと思ったけど、転送が間にあわなかったので後でリリースする、と話しました(その後、無事リリース)。

 1.9.1-p243はパッチレベルリリース。10月にまたパッチレベルリリースをして、2010年1月に終了する予定だそうです。一方、1.9.2 preview1はとりあえずビルドして動くところまでのレベルで、動かして意見やバグレポートをくださいという性質のリリースだそうです。1.9.2は今後、8月にprevie2、10月にRC1、11月にRC2を経て、12月24日に正式リリースということを予定しているそうです。

 1.9.2の新機能としては、ソケットの仕様が変わってまともなRuby APIになった、Timeが変わってepoch time以前も扱えるようになった、BigDecimalとRationalとを計算できるようになった、open()の引数で文字コードを指定するときにBOMありを指定できるようになった、といったことが紹介されました。「地味ですね」とコメントしつつ、機能が安定してきている、1.9系の機能(グランドデザイン)がおおむね固まったのではないかと見解を示しました。

 Ruby 1.9の現在の課題としては、dlライブラリがi386しか考えていない、Ruby文法パーサーのripperのバグがとれていなくて1.9.2のテストでコケる、Tkのスレッドが落ちることがある、irbで例外が発生することがある、ということがあるそうです。

 また、1.9.1と1.9.2の非互換性については、原則なし、-Wフラグぐらいとの話でした。Ruby 1.9ではcompat-versionという概念を導入していて、ライブラリパスが「/usr/lib/ruby/1.9.1」のようになっていた場合の「1.9.1」の部分は1.9.2でも共通だそうです。いわく、「1.9.1と1.9.2はpythonのマイナーバージョン違いみたいなもの」とのことでした。

 いっぽう、1.8から1.9の非互換性については、拡張ライブラリ仕様の非互換性、M17Nの非互換性などが上げられ、ドキュメントをDoygenで作るようになったことなども紹介されました。

 今後、Ruby 1.9への移行については、ライブラリがまだ移植されていないのが問題で、鶏と卵の関係になるものの、「ライブラリを作る人がまず移植してください」ということが強く訴えかけられました。Yuguiさん自身もライブラリに片っ端からパッチを送っているそうで、またRails 2.3がRuby 1.9.1に対応したのもAsakusa.rbの努力によるものだそうです。

 利用面については、スクリプティング用途ならOKとのこと。「1.9.1は1.8.0のように安定です…よく落ちましたねぇ」といいつつも、1.8よりずっといいとのことでした。さすがに実運用サービスについては、Yuguiさん自身もRuby 1.8+Railsを使っているという話で、まずはライブラリが移植され十分なユーザーに使われることを望むと繰り返し訴えかけられました。

  • Q:1.9でProc中のconst lookupがかわった。理由は
    • A:ささださんがそう実装してしまって、Matzが誰も困らないと言った。私は反対したが(yugui)
  • Q:変更してもらうには
    • A:ささださんに言う
  • Q:両方サポートしたい拡張ライブラリを作っている。1.9の拡張ライブラリ(emasaka注:名前失念)の機能が1.8で使いたいが、入れてもらえるか。メンバ変数のアクセスが足りていない。
    • A:入れ忘れかも。1.8.7の最新版には入っている(なかださん)。忘れていることも多いので、指摘してほしい
  • Q:1.9で、NokogiriとかSQLiteとか、標準に入れる入れないの判断は
    • A:新しく入れるものは、合意があれば、次リリースには入れてかまわない。パッチレベルリリースには入れない。合意は入れない方向がデフォルト。rubygemsを標準で入れたので、標準ライブラリをあまり増やしたくない
  • Q:FFIは
    • A:入れたい。dlをFFIの上に再実装したいが、人手がない。Visual C(nmake)に対応していない

Rubyリファレンスマニュアル刷新計画 2009 夏(okkez)

 「るりま」こと、Rubyリファレンスマニュアル刷新計画の進捗報告を、okkezさんと、途中から青木峰郎さんが加わって説明しました。成果物は現在、Webは1日1回更新、chmは毎月更新で公開しています。が、とにかく手が足りないので、できるところをやってまずリリースすることを優先したい、との話がなされました。

 計画は2006年10月に第1段階を開始し、現在、第3段階を継続中だそうです。第3段階では、組み込みライブラリと標準ライブラリのメソッドエントリをすべて記述する、質はともかくとにかく書くという方針とのことでした。

 とにかく、TODOの数が0になったら終了なはずがさんさんたる状態で、Ruby 1.9の開発にマニュアルの作業が追いついていない賽の河原状態とのこと。そこでまず、なんらかのリリースすることを最優先にして、1.9.1のことだけ考える、1.9.2で消えるライブラリを外す、大きいライブラリ(SOAP、tk、XML、opensasl、cursesなど)は優先度をさげる、という対象を絞り込みをして、現在は1,500のTODOが残っているそうです。

 ちなみに質疑応答では、「ライブラリを作る人はドキュメントを書かないのか」という質問も出て、青木さんが「もちろん」と即答していました。

 リリース予定は、12月または1.9.2にあわせてなにかリリースするとのこと。会場でも話し合いをして、ライセンスはCC 3.0 BYにする予定で合意したそうです。

 メンバーからのメッセージはやはり「手伝ってほしい」との一言。「すぐできること」として、るりまのMLに参加すること、issue trackerに参加して間違いを報告することが上げられました。また、「がんばればできること」として、レビューや執筆への参加が上げられました。質疑応答では、Wikiにしてハードルを下げてはどうかという意見が出て、青木さんが過去にWikiでカオスになったと反論、ただしWikiの編集がパッチになってコミッタが判断する方式というのはアリか、という声もありました。

Rubyist Magazineが出来るまで(ささだこういち)

 YARVの開発者でもあるささださんが、日本Rubyの会のささださんとして、Webマガジン「Rubyist Magazine」(るびま)をふりかえってみせました。報告というより、ささださんと聴衆がみんなで「るびま」の記事を「あったあった」という感じでふり返る場になっていたと思います。ささださんは、前日の晩に資料として過去のるびまを掘り返しているうちに、朝まで感慨にふけっていたそうです。

 「るびま」は、もともとRubyのドキュメント不足を解消する一環として、当時発足した日本Rubyの会が始め、いまも続いています。連載がいくつか書籍になったりもしています。ささださんは、リリース間隔を「人気のKey-Valueストア」で集計したグラフを画面に映して、だんだん間隔が長くなっているようでもあるけど、まあそれなりにコンスタントに続いてるんじゃないかと振り返り、継続してきたことが重要なんじゃないかとしみじみ語りました。

 作業フローも紹介されました。まず、リリース日を決定して(サバを読んで)MLに告知。記事を決めて担当編集をつけ、(サバを読んで)記事を依頼、執筆と確認をくりまえします。こうしたあと、最後は全員でチェックしてリリースとなるそうです。

 ツールとしては、QuickMLを使って、編集者MLと、各記事ごとのMLを作って連絡。記事もHikiで編集用Wikiで執筆を進め、最後に手作業(スクリプト)で本番用Wikiに移して公開するそうです。また、句読点などの詳細な編集規則も決めているそうです。

 記事をふり返る中では、連載インタビュー「Rubyist Hotlinks」や、幻のApril Fool特別号(Web Archiveなら見れる)なども紹介されました。ちなみに、壇上からMatzさんに原稿催促などもありました(笑)

 これからについては、ブログ等からるびまに収録するようなこともやってみたいとか、規則の簡略化ってのもアリかとか、有料化はアリだろうかとか、いろいろアイデアレベルで語られました。また、やはりしみじみと、「るびま会議」なんかもやりたいと語っていました。

コミュニテイアピール

 各地域のコミュニティからやってきた人が、短い時間(1分ぐらい?)で自己紹介する時間でした。それぞれの芸風が出ているのが面白く見られました。

shanghaionrails
中国語でまくしたてたあと、最後の最後に日本語で訳というスタイル。Google Groupと定期ミーティングなどをやっているそうです
Ruby札幌
みんなスタッフでがんばってるので東京の人(須藤さん?)が代理で紹介
Tokyu.rb
しゃべくり漫才スタイル。飲み会とか肉とか
Rubyist九州
産学が集まって、Kyushu RubyKaigiに200人満員になるぐらい盛り上がっているそうです
Asakusa.rb
Rubyコミッターからふつうの人まで集まって、花火大会見物などもやっているそうです
Mitaka.rb
新宿より西で集まって、食べもの屋さんから決める「おいしいRuby」でやっているそうです
Ruby勉強会@青森
Ruby札幌の応援もあり、1年続けてきたそうです。ドメインもとって、これからサイトを作る、とのこと
Ruby Taiwan
中国語と英語で説明。定期ミーティングとかやっているそうです
toRuby
那須でミーティングを開催。dRubyの写経などをやっているそうです
engineyard.rb
MerbのYehuda Katzさんでした

基調講演(まつもとゆきひろ)

 Rubyの父、まつもとゆきひろ(Matz)さんの基調講演は、今回のRubyKaigiのテーマである「Change」を念頭に置きつつ、RubyとRubyistの立ち位置を確認する、とても興味深い内容でした。題して「Ruby羅針盤」。われわれはどこにいるのか、どこに行こうとしているのかというテーマが語られました。

 話は、現在は100年に1度の不景気と言われるけど、実は「プログラミングの黄金時代」なんじゃないかという話から始まります。思えば80~90年代前半はひどい時代だった、コンピュータのパワーがないく、コンピュータの都合でねじまげられた技術がいろいろある、と語りました。いまは、コンピュータの限界に縛られず、すぐれた技術が技術者に注目されるようになった、ということです。Rubyも、こうした流れで支持を得るようになってきたという位置付けがなされました。

 そんな時代の中で、RubyとRubyistがどこを向いているのかということで、「アチチュード」が重要と続けました。まずは「感謝」。Rubyで賞をもらったけど、自分ひとりで作れたわけではない。たくさんの人が貢献し、使い、愛し、指摘してくれたわけで、みなさんも賞をもらったのだと考えてほしいと語りました。

 続いて「すっぱいブドウ」。言語コミュニティ間の感情的反発で、真実でないことを正当化することがあってはならない、というのを、Rubyコミュニティとして公式に宣言したいと訴えました。

 次は「割れ窓」。OSSは生きて常に変化し続けることが魅力であり、その一環としてバグや間違いは積極的に修正したいと語りました。ただし、ここのところバグフィクスが追いついてないという事情もコボしていました。

 続いて語られたのが、「責任」という重い言葉でした。Matzさんは、子供のころに鉛筆削り用に肥後の守を渡され、ときには怪我をしながら自己責任を学んだ、という体験を背景に、不自由より自己責任を、という考えを語りました。プログラミング言語でも、「いろいろなことができると危ない」という意見もありますが、でも、そういう人はどこでも危ないことをするし、それよりは、生産性を高めるほうにフォーカスしたい、自分のできることを最大化したい、との意見をあらわしました。

 後半は、思いついて塩漬けにしてある実験的なパッチを紹介して、言語オタクっぷりを見せつけました。自身は、GitをバックエンドにQuiltをイメージして作られたStGIT(Stacked GIT)というツールを使って、これらのパッチを管理しているそうです。ちなみに、StGITはPythonで書かれているそうです。

  • 複素数リテラル
    • 互換性問題なし
    • Yuguiさんの承諾必要
    • 実は複素数をほとんど使ったことはない
  • true_division
    • 「1 / 2」の結果を有利数1/2にする
    • 正規化が必須
    • 互換性の問題が大きい
  • as_conv
    • to_a(明示的な変換)、to_ary(暗黙的な変換)のように、to_xxxメソッドに2種類があるのを整理
    • as_XXXは明示的変換(同じようなもの)、to_XXXは暗黙的変換(同じじゃないもの)に
  • math_error_check
    • Math関数のエラーは戻り値で例外じゃない。これを例外で返るようにする
    • Math関数以外は? 例:0.0/0.0
  • 01_bitmap_marking
    • GCのとき、forkのcopy on writeにやさしい
  • nloop
    • 多重ループを1度に宣言
    • ブロック呼び出しが遅いのを回避できる?
  • sym_gc
    • シンボルをGCの対象とする
    • GCが遅くなる
  • private_ivar
    • スーパークラスと共有しないインスタンス変数
    • @__fooでprivate
    • でも以外と@_fooというインスタンス変数が使われている
    • ぜんぶひっくり返したい気もするが、それをやると互換性が
  • blok_local_vars_eq
    • :=で代入した変数はブロックローカルとする
    • 放置
  • module_as_trait
    • その場でモジュールを合成
    • module + moduleで足し算
      • 2つの機能を持つmoduleを作る
      • メソッドが重複したらエラー
      • あとから元モジュールにメソッドを追加しても反映されない
    • module - moduleで削除
    • 間違いが早く見つけられる
    • 元のモジュールと共存するのが気持ちわるい
    • 放置
  • open_class_override
    • メソッド再定義すると、superで呼べる
    • アスペクト指向のベースに使える
    • 互換性の問題
  • キーワード引き数
    • 文法だけ作った
  • lvar_propagate
    • ブロック内で宣言している変数をブロックの直後で参照すると、参照できる仕様
    • 未完成
    • ささださんいわく「気持ち悪い」

 このように、誰にも見せられないようなパッチを日々書いていると説明し、「アジャイルなだけじゃなくてフラジャイルでありたい」と語って締めました。

LT:前説(後編)(igaiga)

 2日目もLTの時間がありました。しかも途中。

 1番手(0番手)は、昨日と同じく、igaigaさんによるタイマーソフト「TwTM」の前説(2分半)。Nadoka(ささださん作)を利用しようとして遅延、そこでプロトコルを調べてそのとおりにRubyから呼び出すようにした、文字がUTF32 big endianなのをRuby 1.9のkconvで変換できる。いずれはRuby 1.9でNadokaを動かしたい、との話でした。

LT:次世代数値演算ライブラリDecimalという再発明の意義(斎藤ただし)

 正確な小数の計算をするライブラリとして、既存のBigDesimalに対して新しくDecimalを作ったことを例に、再発明がうけいれれれるには何が重要かを説明しました。具体的には、Bignumなどを利用してよりコンパクトで安定した動作をすること、sqrtの呼び方などでRubyの慣習を踏襲したこと、シンプルであること、速度などが上げれられました。

LT:Morumotto, a jruby-based OpenID service using visual authentication(Han Kessels)

 新しい画像認証システム「morumotto」の紹介。ふたつのふたつのノイズっぽい画像を重ねあわせたときに文字が浮かぶようにするのが基本原理だそうです。OpenIDをベースにしたサービスとして実装しているそうで、JRubyで開発、日本語版もある、プラグイン不要、J2MEも対応。現在パブリックベータで、数週間で正式公開するとのことでした。

LT:Monitoring the sun with Ruby(Benjamin Smith)

 太陽光発電インバータという、ちょっと変わった業種の会社でRubyでシステムを開発しているという話でした。太陽光発電のシステムは、分散、高信頼、高効率、データが多いという特徴があり、それを制御するのに1007年からRubyを使っているそうです。

 会場でも、Webベースのグラフィカルなモニタリングシステムをデモしました。カッコよかったです。やっぱり働く機械は技術っ子の憧れですね。

LT:RomanticRuby!(Rubyでギャルゲー)(久保優子)

 株式会社万葉の専務さんがコスプレで元気に登場。今回、いちばん破壊力のあったセッションじゃないでしょうか。

 話を進めていくタイプのゲームが好き、具体的にはギャルゲーが好きということで、女の子プログラマが出てくるギャルゲーをMacでやりたいのでRubyで作るという話でした。Ruby技術者認定試験の勉強になるそうで、合格者の喜びの声も出てました。「使ってるエディタ」の話をしたりするそうです。社長の稟議があっさりとおったとか、Romantic Ruby略してRoR(嘘)とか、年明けリリースしたいとかいう話。最後はnice boatで終わりました。

LT:Ruby on Arduino(高野光弘)

 jusの、というよりハッカーズカフェのtakano32さんが発表。Arduinoの紹介であると同時に、Arduinoによるプレゼンでもありました。Terminalからプレゼンを表示して、同時にArduinoを制御してLEDの二進数でページ番号を表示していました。

LT:rubyrep - database replication that doesn't hurt (developed in ruby)(Arndt Lehmann)

 Webアプリのバックエンドなどで使うデータベースを、できるだけ簡単にリプリケーションするrubyrepの紹介でした。Railsのconfig系っぽいDSLを使って定義、キーなしやバイナリなどのテーブルもサポート、差分レプリケーション対応、zero installation、JRubyベースとのことでした。

LT:BABY - 初心者のためのグラフィックライブラリ(黒田拓)

 昔の子供たちがBASICパソコンで簡単なグラフィックゲームを作って動かしていたようなことを、RubyでやるライブラリBABYの紹介でした。基本はRuby/SDLで、BASICみたいに簡単に書けるようなラッパー(DSL?)を作って簡単な命令(メソッド)で絵が描けるそうです。irbでも動くそうです。大学生など向けにはOpenGL版もあって、ほぼ同じAPIで数値計算グラフなども描けるとのことでした。近日公開。

LT:Rubyでの(力技)でのネットワーク運用(植村優一)

 ネットワーク管理系の話で、NTT Comの人とか。単純な監視だけなら汎用製品(Hinemosなど)でいいけど、監視に連係してアクションするにはそれだけじゃ済まないので、プログラムで制御するためにRubyを使ったとか。具体的には、故障発生時にすべての装置にtelnet/sshでログインして情報をとるとか。さらに、安定して使うためには、よくテストされた基本クラスを継承して使う、テスト重要、テストの自動化、といったことが語られました。

LT:rubyによるお手軽CDN作成のすすめ(荒木靖)

 同じくネットワーク管理系。DebianのパッケージリポジトリをCDNで分散したcdn.debian.netをRubyで作った話。へー、Rubyだったんですね。cdn.debian.netは42か国にわたるCDNで、2分ごとに監視、Geo IPとDNS-Balanceで接続先を決定、という仕様で、ftpサーバーに手を入れなくても使えるのが特徴だそうです。ただし同じディレクトリ構成が前提。たまにサーバーから監視アクセスについて文句をもらったりもするとか。これからについては、ssh DRbとか、監視情報をtwitterに(やったらあふれた)とかいうことも語られました。

LT:Facing your daemons(Kenneth Kalmer)

 さらにネットワーク管理系が続いて、Rubyによるデーモン監視フレークワークdaemon-kitの紹介。Railsの影響を受けているようで、DRYがウリ。具体的には、Rakeタスク、複数の実行ステージ(Development、Testing、Staging、Production)、YAMLやDSLによる設定、などがあるそうです。ほか、pidファイルの管理、ログの管理(ローテーション含む)、監視と落ちたときの対策など。これからについては、スレッド対応や、sysvinitのスクリプトの生成などを考えているそうです。

ActiveLdap(須藤功平)

 LDAPエントリをRubyのオブジェクトとして直感的に扱うライブラリActiveLdapの紹介。ちょうどこの日、1.1.0がリリースされました。

 ActiveLdapでは、LDAPエントリをActiveRecordふうに扱うそうです。これによって、Railsとの高い親和性、つまりvalidationやhas_manyなどを使えるし、スキーマはActiveLdap::Baseを継承したクラスとして作れるそうです。LDAPパーサはRFC準拠で、厳しめに検証して親切なエラーメッセージを返す方針とのこと。LDAPのクライアントやサーバーはいろいろ選べるそうです。また、日本語チュートリアルもあるとのことでした。

分散並列処理フレームワークfairyと分散オブジェクトシステムDeepConnect(石塚圭樹、増田創)

楽天技術研究所で開発しているMapReduceタイプの技術fairyと、fairyが利用している分散オブジェクトシステムDeepConnectの解説でした。

 まずは、楽天技研の増田さんがfairyを紹介しました。

 分散処理は複数サーバーを意識しないで作れるようにするもので、複数サーバーに散らばったデータや大容量のデータを処理するのが得意です。GoogleのMapReduceや、Java実装のHadoopが有名です。Ruby実装にはstarfishやSKYNETなどがありますが、決定的なものはないそうです。

 fairyもこうしたRuby実装のひとつで、MapReduceをベースに、より生産性を高くすることを狙っているそうです。具体的には、フィルタインターフェイスを使い、スクリプトを配布しておかなくてもよい、Rubyプログラマに書きやすい(メソッドチェーンできる)などの特徴があるそうです。現在α版が稼働中で、主なAPIや分散Key-ValueストアROMAとの連係機能は実装したそうですが、まだ足りない機能もあるとのことです。

 毎度おなじみ単語の出現数を数える場合を例に、fairyが解説されました。input、mapで単語分割、group_by、mapで単語の出現数を数える、output、というようにフィルタの数珠つなぎで記述します。このとき、それぞれのmapはローカルで動き、group_byはnode間の通信が必要になるという説明でした。プロセスには、実際の計算をするnode、nodeを管理するmaster、コードを書いて処理をサブミットするclientの3種類があり、データは仮想分散ファイルVFileとしてやりとりします。

 すでに、zip、direct_product、join、shuffle、splitなど豊富なフィルターが用意されているそうです。数十万件の画像処理のバッチ処理が13倍高速になったという事例も紹介されました。ただし、データを大量に流す処理ではフィルタ間のやりとりがボトルネックになるということで、パフォーマンス改善のためにいろいろ作り直しているそうです。オープンソース化を検討しているとの話でした。

 続いて、石塚さんが、failyで使われているDeepConnectを説明しました。DeepConnectは分散オブジェクトシステムを実現するためのフレームワークで、ようするにdrbの親戚みたいなものだそうです。1996年に初披露したものの放置していて、1999年にdrbが登場して、そちらが使われるようになったとか。で、failyで適用開始のため、再スタートしたそうです。パフォーマンスは「drbより良くない」とのことでした。

 DeepConnectでは、サーバー側でオブジェクトをエクスポートすると、クライアント側でインポートすれば、クライアント側でふつうにRubyの式から使えるそうです。メソッドの引数も参照渡しで、ローカルのコードから修正がいらないのが特徴だそうです。

 また、接続するとメソッドをすべて使えてしまうので、インターフェイス宣言したメソッドだけが利用できる。ShallowConnctモードもあるそうです。

 共有されたオブジェクトは自由に参照できますが、たとえばArrayが共有されてポインタ参照されていることを忘れて使うと、eachしたりしたときにそれぞれ通信コストがかかるので注意との話でした。なお、==はeql?(ポインタ比較)になっているそうです。

 共有されたオブジェクトにはリファレンスカウントで実装された分散GCが働き、リファレンスされているものはGCされないようになっているとのこと。分散した循環参照などは、ごみが残るので、明示的なリリースメソッドを用意でしているそうです。

 fairyでいうと、@input.eachで上流のenumeratorに対してeachするというふうに、ローカルとリモートの違いを吸収するそうです。ローカルからリモートへの変更は5%程度との話でした。ただし、性能のためStringはコピーして渡すとか。このあたり、メソッドに対してMethodSpecが指定できて、deep copyとかshallow copyとかを選べるそうです。このように、fairyが激しくて動的なので、使われることでDeepConnectの品質が向上したとか。

 DeepConnectは、fairyのオープン化にあわせてオープン化予定という話でした。

偉大なBigTableとぼくのおもちゃ(関将俊)

 dRubyの咳さんのセッションです。すごく面白かったのですが、表面的な仕様を追いかけていれば聞いた気になれる話ではないため、素人の私が聴いたうちで、ある意味いちばん難解なセッションでした。そのため、以下はメモほぼそのまま。

  • MapReduce=単語数を数えるシステム
  • カウント対象:eval.cはよくやる
  • かっこいいバッチ処理
    • 重要なのは処理内容
  • 出力
    • 巨大なordred list
    • BigTable?
  • reduceを呼ぶ係?
    • どうやって動く
    • 要素を1つずつ見て?
  • COBOLでいえばコントロールブレイク
  • [key, value]のデータを共有する空間
    • 分散処理
  • Rinda(LindaのRuby版)と似ている
    • タプルスペース
    • 並列処理
    • dRuby本で
    • くわしくはtoRubyで
  • Rindaで単語を数えるシステム
    • 単語と単語数のタプル
    • 数えよう
    • 最初の単語を知る手段がない
      • 全サーチ
      • ひどい
    • 次の単語
      • 残りを全サーチ?
  • だれかが単語を並べる必要がある
    • Hashも同様に微妙
  • HashやTupleSpaceにkeyの順序はない
    • 知ってるkeyの有無の確認は得意
  • Linda
    • 並列処理言語
    • プロセス間協調
    • 糊言語?
    • reduceには分類が必要
    • Lindaの出番
  • KVS
    • 定義がさっぱりわからない
    • Hash?
  • mapとreduceの間を見てみる
    • Hashっぽくない
    • key-values(複数形)
    • 同じキーがたくさん
  • keyで並んでる
  • 高速な検索とアクセス
  • keyってなに?
  • 転置インデックス
  • boolean検索
    • and or 検索
  • ソートされていると検索しやすい
  • keyそのものに値を入れたほうが?
    • ソートされる
  • 実験
  • keyに順序がある集合
    • BigTable
    • TokyoCabinet
  • TokyoCabinet
  • 並列性よくわからん
  • Koya
    • QDBM→TCで書いたOODB
    • Object IDと中身
    • Keyを階層構造にすれば表で
  • Koyaのねらい
    • サーバークライアントはdrbで
    • それ以外
  • rubyはロールバックないのにトランザクション
  • RBTree
    • RG木
    • 順序がある
  • インメモリ
    • インメモリ+ログでたいていじゅうぶんだよ
    • フォロワーたくさん
      • memcached
  • メモリに入らないとき
    • プロセスをわける
    • drubyでマシンを分ける
  • 転置インデックス
  • テスト大変
    • 大量のデータを作らなくちゃならない
    • CVSのコミットと時間でデータを作る
  • 検索システムを作る
  • Ruby/CVS
  • 履歴は減らないので追記だけ
    • 更新もない
    • 超楽
    • 「,v」を検索するというのは、手段のためなのでだめ
  • 実装
  • TokyoCabinetのBDD
    • ちょっとしったキャッシュつきデーモンの中
    • Webrickの4行スクリプトから接続
  • 瞬時に検索
  • Q:順番がついているといいとは
    • A:値がソートされていてほしい。keyだけでならべるとvalueが並ばない。両方がならんでほしい。そこで「恵比寿:1」「恵比寿:2」とか
  • Q:reduceするときにマージソートみたいなことをすればいいのでは
    • A:空間を十分に用意できれば。メモリに乗らない量があると処理できない。メモリに入っちゃうならなんでもいい

concov:時系列に注目したテストカバレッジビューア(遠藤侑介)

 Rubyのテストメンテナとして、テストのコードカバレッジを上げるために、時系列でカバレッジの変化を追いかけるツールconcovを開発した話でした。

 まず、テストは1回書いたら終わりではない、ソフトが変化するにつれてテストは劣化するので修正しなくてはならない、ということが語られました。理想的には開発者がテストを書くのがいいのだけど、それはしょうがないし、テストを正しく書くのは難しい、テスト環境の構築も面倒、ということで、実際には後から誰かがテストを書くことになるそうです。

 テストメンテナとしては、コミットログを追いかけているのだけど、しばらく見ないとRubyが大きく変わっていたりもするとか。そこで、コードカバレッジの変化の追跡を補助するツールconcov(continuous coverage)を開発したとのことでした。

 ここで、実際の画面が紹介されました。Web上で、5つのviewから分析できるそうです。day view(現在のカバレッジ状況、各ファイルの中の行単位)、week view(週単位、大きな変更がおきたときなど)、diff view(2つの日の異なる箇所を表示して比較、いちばん使う)、changes view(ディレクトリやファイルのカバレッジ履歴、いつからカバーされなくなったかがわかる)、chart view(半年のカバレッジの変化をグラフで表示)

 concovで見た結果、テストも書かずに新機能追加とか、コミット後にカバレッジ率がのきなみ低下とか、逆にテストつきでコミットしているケースとか、Ruby開発のさまざまな実態が可視化されたそうです。

 concovの実装としては、ソースを定期的にビルドして、テストや測定を動かして結果をDB化し、そのデータを表示しているそうです。RubyのC実装部分のカバレッジ測定のほか、Ruby 1.9のカバレッジ測定用に拡張ライブラリcoverage.soというのもあって、1.9に標準添付されているそうです。

 この実装について、Windowsなどプラットフォーム固有のコード(Winとか)はテストされないのではという指摘が会場があり、たとえば、テストだけほかのマシンで実行して決まったフォーマットでデータを渡してもらうというのならできる、という議論がありました。

 今後については、ドキュメントを書くのが課題とのこと。また、ささださんが「同じしくみでベンチマークもやってもらえないか」と提案し、「考えます」との回答がありました。

 なお、時間が余ったので(計画的?)、Quine大好きという自己紹介で、QRコードとRubyのソースコードを相互変換するQuine(QR=QuineRuby?)を披露していました。ほか、アナログ時計形AAのソースを実行するとデジタル時計型AAのソースを表示し、それを実行すると次の時刻を表示するコードや、「require "_"」とする"_"だけでプログラムを書くコード、ソースコードで15パズルといった、驚異的なコードが披露されました。

RubyのGC改善による私のエコライフ ~レジ袋は結構ですよ(2009夏)~(nari)

 RubyのGCを改善した話でした。コミッターの方もいろいろ参加していたため、質疑応答がかなり活発で豪華でした。

 現在、GCのアルゴリズムを解説する本を執筆しているとのことで、実装例としてはPythonやJavaVM(OpenJDK)、android、v8などを紹介しているそうです。出たら買う人を聞いたらほぼ全員が手を上げていました。ちなみに、gc.cを読んだことのある人もけっこういました。

 まず現在のGCの問題として、copy on writeの問題が語られました。forkしたときに、copy on writeが使われていると、GCのマークをつけたときにwriteしてしまい、無駄なコピーが発生してしまいます。そこで、マークビットをオブジェクトの中ではなく専用のbitmap領域に置くBitmap Marking GCという方式が考えられています。これは、Passenger用に改造されたRubyであるRuby Enterpriseで採用されているそうです。

 ただし、Bitmap Marking GCの問題として、オブジェクトのアドレスからヒープスロット(どのヒープか)を見つける方法をどうするかという問題点が語られました。Ruby Enterpriseは線形探索するので、forkしないときは遅くなるそうです。1.8系のヒープスロットは増えても20個ぐらいだが、1.9系ではヒープスロットの数を増やしてメモリ効率を上げる方式のため数百個になったりもします。一方で、オブジェクトにヒープのポインタを持たせると、メモリ消費が大きくなってしまうという問題もあります。

 そこで、アラインメントを利用する方法を実装したそうです。ヒープのどこかには下位14bitがすべて0のアドレスがヒープのどこかにあるので、そこにビットマップを置くと、O(n)からO(1)になるというアイデアです。論文も書いたそうです。ただし、Matzさんの基調講演にもあったように、パッチ袋に入ったままとか。

 まあforkを使わなければ気にしなくてよいということで。Androidではいっぱいフォークしているので、Bitmap Markingをしているそうです。

 もうひとつの改善として、構文木オブジェクトの問題も解説されました。Rubyのオブジェクト使用状況を調べたところ、構文木オブジェクトが半分を占めていたそうです。1.9ではYARV命令列になったら不要なはずではありますが、インラインキャッシュなどで長寿命なオブジェクトだそうです。

 そこで構文木だけ世代別にする方法を実装したと説明されました。長寿領域をわけて、マークスイープ回数を減らす方法です。これでGC回数が減って、総GC時間が減ったそうです。また、ライトバリアはコア内部で完結していて、構文木がコアから分離されたので、ライトバリアの問題もクリアされたそうです。この実装は、trunkにとりこまれたそうです。ただし、最近では、構文木はGCの対象外にすることが検討されていて、しょんぼりとか。

 今後は、いろいろなGCを試したいと語られました。そのひとつとして、BoehmGCを試したものの、すごく遅くなった、チューニング必要、という結果だそうです。

  • Q:長寿命のオブジェクトから通常のオブジェクトを指している場合は
    • A:ライトバリアで参照をセット
  • Q:普通の世代別GCは
    • A:ライトバリアの問題があって難しい
  • Q:BoehmGCが速くならない理由
    • A:オブジェクト単位じゃなくてそれより細かいポインタ単位になって無駄が多い
  • Q:構文木のGCは1.8限定?
    • A:1.9はライトバリアが限定されている。1.8はnodes.hが拡張ライブラリに公開されているのでやばそう(ささだ)
  • Q:BoehmGC版Rubyいじりたい。公開できないか?
    • A:がんばります
  • Q:去年言っていた並列GC ready-sweepは
    • A:rejectされました
  • Q:(ささださん)なんでrejectしたんだっけ?
    • A:まつもとさんに聞いてみます
  • Q:(Matzさん登場)自分で取り下げたんじゃかった?
  • Q:GCのパッチはいつもrejectされるのだけど、なぜ? Rubyならではの基準など?
    • A:重要なこと「SEGVしない」w 速いこと。RubyのGCが保守的なGCなので、やることが制限される(コピーGCなどはできない)
  • Q:「ヒープという名前がよくない」という意見が。私のパッチがrejectされたり。なにかいい用語はないか。ほかの処理系で(ささだ)
    • A:pythonはarenaとか…

3日目(7月19日)

TermtterKaigi

 3日目の午前は、TermtterKaigiに参加しました。コマンドラインのTwitterクライアント「Termtter」の集まりで、要するにBOFです。

 最初は参加人数が2人だったのですが、だんだん増えていって、最後には会議室がいっぱいになるぐらい人が集まりました。

 とりあえず、メモ。

  • termtterのしくみ
    • 入力とTaskManagerの2スレッド
    • コマンドとreloadの両方の処理をTaskManagerに食わせて、かちあわないようにする
  • readlineをプラグインに分離したい
    • コアの部分を軽くする
    • vimから使いやすいように
  • readlineのrefreshメソッドは、Ruby 1.9に取り込まれた
    • TermtterがRubyを変えた!
  • データベースを標準に
    • DBを抽象化して、Cacheなどを作ったときに同じように扱えるように
    • タイムラインと同じデータ構造
  • データ構造の変遷
    • ハッシュになったりクラスになったりして、いまstruct
    • 扱いが楽
    • RubytterをTermtterべったりにはしたくない
  • ハッシュタグ補完機能
    • みんな知らなかった。便利。その場でタイムラインにハッシュタグが。
  • ユーザー名を補完すると先頭に"@"を自動的に補完してくれる機能がほしい
  • コマンド名なしの入力をupdate扱いにしたい
    • readline分離にあわせてできそう
  • ユーザー切り替え機能をやりたい
  • jugyoさんが作り始めたきっかけ
    • Linuxで動くtwitterクライアントでいいのがなくて
  • ujihisaさんがブログで取りあげて知られるようになった
    • 発言を動的にフィルタリングできるクライアントがほしかった。Rubyで拡張できるので
  • specを充実させる
    • テストのためにAPI叩く?
    • fixtureのようにデータを与えられるといい
  • プラグインを作るためのドキュメント必要
  • 基調講演
    • 羅針盤
    • エコ

How Lazy Americans Monitor Servers(James Edward Gray II)

 Railsのサーバー監視ツール「Scout」の発表でした。JamesさんはRuby 1.9でcsv.rbとして取り込まれたFasterCSVの作者でもあります。

 たくさんのRailsアプリが動いていると、たくさんのサーバーを監視しなくてはならなくて辛い。そこで監視ツールとしてScoutを作ったという話でした。可視化、傾向分析、警告が主な機能で、たとえばSQLのクエリが急上昇とかいうのを警告してくれるそうです。主にRails用ですが、ほかの用途でも使えるそうです。

 構成としては、サーバーにエージェントをインストールして、Scoutアプリがエージェントと通信するようになっているそうです。また、Scoutはプラグインでさまざまな機能を追加できるそうです。なお、すべてRuby製だそうです。

 以前のエージェントは、10分間隔で実行するものでした。ただし、サーバーにログインして設定する必要がありましたし、パースが難しいデータの扱いなどの問題もありました。そこで今年から、常時監視してsleepで待つ、新しいエージェントの仕組みに変更したそうです。

 目標としては「常に動いている」「安全な実行」とのこと。以降、いかに安全に、クラッシュやメモリーリークなしで監視を続けられるかが語られました。私には細部まで聞きとれませんでしたが、力技もふくめて、細かいところまで練られているなと思いました。

 たとえばメモリを安全に管理する手法として、作業をするワーカープロセスをfork()で生成し、作業が終わったらプロセスを終了するという方法が使われているそうです。これなら子プロセスがメモリーリークしても回収でき、いわく、「最高のGCはexit()」とのことでした。

 以下、とりあえずのメモ。

  • プラグインの書き方
    • needs "hoge"でライブラリをロード
    • option()でオプションを取得
    • reportで出力
  • プラグインをテストするコマンドもある
    • scout agent test hoge_plugin.rb
  • RubyスクリプトからScoutと話すには「require "scout_agent/api"」
  • 3,000行のバグのないコードを書くのは大変だが、2,000行なら大丈夫なので、2000行のコードから3,000行のコードを保証
  • プロセス間の通信にSQLiteのRuby拡張ライブラリamalgaliteを利用
  • プロセスを監視して必要な場合にはProcess.kill()で再起動
  • 最悪のケースへの対応として、OSの状態や、APIコール、networkコードを監視
    • いうほど難しくはない
  • セキュリティ機能として、本物のScoutサーバーであることを確認するSSL認証や、コードレビューのプラグインなどを計画

 なお、コードは事前に十分なテストをしたいが、fork()やパイプ、signalなどの動作はテストしやすくはありません。そこで、テストプロセスからテスト対象をプロセスとして呼ぶようにしているとのことで、そうしたミニプログラムをたくさんストックしているそうです。

 結論として、大変なRailsサーバー監視はRubyで解決して、余った時間で日本語を勉強しました、とまとめました。

  • Q:requireでなくneedsなのはなぜ?
    • A:サーバー上のエージェントでrequireがエラーになると対応できない。needsはscoutにエラーが飛ぶ。
  • Q:プロセス管理は単独のライブラリにしない? 便利そう
    • A:やりたい。が、90%ぐらいの出来なので、完成したら。
  • Q:RRDtoolを使っていると聞いた
    • A:RRDtoolの上に実装したら、ruby bindingがよくなかった。で、ラッパーを作った。いまは別の方式にしている。RRDtoolに戻すことを考えている。
  • Q:エージェントはどのぐらいメモリを使うか
    • A:15~20MBぐらい? FAQでチェックして。正確な数字は難しい。fork()とかあるので。
  • Q:何故プロセスを並行で走らせないのか
    • A:並行でやるのも実装した。が、子プロセスが複数あると時間がわからない。また、サーバーのCPU時間を使ってしまう。
  • Q:待つ時間を超えないしくみは作れないか
    • A:実行時間が長すぎるプロセスはチェックして処分している

Journey through a pointy forest: XML parsing in Ruby(Aaron Patterson)

 日本のMLにも「ひげの山男」として陽気な「ヘンなガイジン」キャラで登場しているアーロンさんが、XMLやHTMLをパースするうえでの問題点と、Nokogiriライブラリについて解説しました。

 壇上に上がったアーロンさんは、予想にたがわず「ヘンなガイジン」っぷりを披露。酒屋の前掛け+頭にてぬぐいというスタイルで、黒子の忍者を連れて登場しました。なんでも去年のRubyKaigiでアメリカンジョークがすべったので、「笑って」のフリップを出す「笑う忍者」を用意したのだとか。で、いわく「私は海賊」。

 内容は題して「XMLを知ることは苦しみを知ること HTMLも同様」。まず基礎として、XMLのノードや名前空間の話をしました。

 そして、XMLパーサーをさまざまな方式ごとに紹介しました。まずはSAX parser。イベントのコールバックを設定してパースする方式で、REXML、libxml-ruby、nokogiriが対応しています。アーロンさんいわく、REXMLだと「parser.parse」という変な記法になるけど、Nokogiriは「parser.parse xml」と自然な記法とか。SAXの利点としては、速くてメモリの消費が少ないことが、不利な点としては、検索が苦手、document handlerが長い、巨大なステートマシンということが上げられました。

 続いてpush parser。私にはSAXとの違いはよくわからなかったのですが、Nokogiriが対応しているそうです。

 3つ目はpull parser。求められたnodeだけをyieldするもので、「cursorと同じ」だそうです。REXMLとlibxml-ruby、Nokogiriが対応しているそうです。ただし、REXMLのpull parserは5年ぐらいexperimentalのままになっているそうです。あと、libxml-rubyの「LibXML::Reader::string」という名前にアーロンさんがツッコんでました。利点としては、メモリ消費が少ないこと、最速(のはず)のことが、不利な点としては、cursorと同じ働きなこと、プログラマーに優しくないことが上げられました。

 これらSAX系のパーサーに対してアーロンさんのお気に入りと紹介されたのがDOM interfaceです。メモリ上に木構造を作って検索するもので、REXML、libxml-ruby、Hpricot、Nokogiriが対応しています。HpricotやNokogiriでは、XpathやCSSセレクタで検索できます。アーロンさんは、REXMLやlibxml-rubyの仕様にツッコんでみせつつ、HpricotやNokogiriをシンプルで優れていると自賛しました。利点としては、データ抽出が簡単なことl、プログラマーにやさしいことが、不利な点としてはメモリ消費が大きいことと、SAXより遅いことが上げられました。

 同様に、HTMLパーサーについてもDOM interfaceを紹介しました。ここで、「p[a]」はXPathとしてもCSSセレクタとしてもありうるという問題や、XPathとXMLの名前空間のサポートなどについて語られました。

 といっても、HTMLは人間が書くこともあるので間違いがあります。HTMLにおいては「ブラウザが神様」なので、HTMLに間違いがあるときの挙動をブラウザに合わせる苦労を語りました。たとえば、</td>がない<td>が2つ並んでいる場合、SafariやNokogiriはそれぞれ</td>を補いますが、Hpricotでは1つ目の中に2つ目が含まれていると解釈します。また、headの中にbodyがあってもう1つ普通のbodyがある場合、SafariとNokogiriはheadの中のbodyを削りますが、Hpricotは2つのheadとbodyと解釈します。ただ、SafariとNokogiriとHpricotが違うケースもあり、「いやになっちゃった」と。まあでも、60%は成功とのことでした。

 ここでジョークネタでenterprise rubyというのを披露しました。Rubyはenterpriseじゃない、XMLはenterprise、ならばRubyのコードを実行可能なXMLに変換しようというもの。S式の木構造をXMLに置きかえるそうです。ここで、XMLをNokogiriでパースして式を変更、もう一度Rubyコードに戻す、というのもやってみせました。

 最後は、NokogiriをRuby標準ライブラリにしたいという話。REXMLは遅いし、Nokogiriのベースになるlibxml2は多くの人に使われてテストされているので、技術的にはこちらが優れている、と。計画として、REXMLに互換性のあるコードを書くか、それともMatzに賄賂するか、というジョークで

  • Q:NokogiriはJRubyで動く?
    • A:動く。FFIで
  • Q:XPathのid()がlibxml2で使えない。Nokogiriでは
    • A:それはXPath2の仕様。NokogiriはXPath 1なlibxml2の対応に頼っている
  • Q:bodyが2つあるケースでは、修正すると情報が消えてしまう。残せないか
    • A:text nodeとして残せばいいかも。あるいはHTMLじゃなくてXMLとしてパースすれば
  • Q:yak shavingの話を
    • A:サーバーサイドで動くJavaScriptのテストが欲しかった。そこで、JavaScriptを扱うJohnsonを書いて去年のRuby会議で披露した。でもDOMに対応していないので、Hpricot等を調べた。その結果、Nokogiriができた
  • Q:JohnsonとNokogiriを組みあわせてJavaScriptでDOMをパースできるように?
    • A:DOMをRubyで生成するTakaプロジェクト。いまDOM level 1。Dom level 2はまだ

Erubis徹底解説(桑田誠)

 pure RubyのeRuby処理系「Erubis」が解説されました。merbでも標準採用されています。

 特徴は高速で高機能なこと。ライブラリとして動くほか、erubyコマンド相当のerubisコマンドもあるそうです。

 機能として最初に紹介されたのが、デフォルトでHTMLエスケープする機能。<%= %>の結果がHTMLエスケープされ、エスケープされたくない場合には<%== %>を使うそうで、重宝がられているとのことでした。この動作はオプションで変更できるそうです。

 次に紹介されたのは、埋め込みパターンを<% %>から変更する機能。オプションでパターンを渡すことで変更できるため、eRubyを使ってeRubyを生成する場合(tDiaryの中でもやってる)のに便利とのことでした。

 また、値(コンテキストデータ)を渡すのに、BindingのかわりにHashやObjectを使うこともできるそうです。これで、渡す値が明白にできるのがメリットとのとでした。コマンドラインからも、YAMLのインライン形式またはRubyのコード、あるいは*.yamlファイルや*.rbファイルでコンテキストデータを指定できるそうです。

 機能を拡張するEnhancerと呼ばれるmoduleを追加することもできます。Erubisの内部は細かくメソッドが分かれているため、メソッド単位で上書きして拡張しやすいそうです。標準でいろいろなEnhancerを用意しているのでマニュアルなどで確認してほしいとのことでした。

 細かい機能では、<%=== 式 %>で標準エラー出力にデバッグプリントを出力できる機能も披露されました。また、PHP、Java、JavaScript、Perl、Scheme、cといった複数プログラミング言語に対応しているとのことで、C言語ではprintfのフォーマットで「<%= "%d", i %>」のように記述するそうです。

 こうした新機能に続いて、実装にあたっての問題点とその解決策が解説されました。

 bindingを使って変数を渡すと、ローカル変数がローカルじゃなくなって、トラブルになることがあります。しかも、値を変更している箇所が離れていて発見がむずかったり、すべてのローカル変数が渡されるのでより問題が大きくなったりします。これについてErubisでは、ハッシュ渡しやオブジェクト渡しでコンテキストデータを渡せるため、こうした問題を防げると説明がありました。

 また、テンプレート処理では実行コストより構文解析や変換のコストが高いということもよくあります。Erubisでは変換コストを下げるために変換結果をファイルにキャッシュする、解析コストを下げるためにProcオブジェクトで保持するというキャッシングをしているとのことでした。

 eRuby処理系では、出力に余分な改行が含まれるため、特にHTML以外で問題になることがあります。ERBではさまざまなtrimmodeを用意していますが、複雑になっています。Erubisではこれに対し、<% 文 %>なら改行をとりのぞく、<%= 式 %>ならそのまま、という単純な方法をとったそうです。

 ただし、「<%= form_for :foo do |f| %>」のような場合、ERB+Railsの場合は<%= %>は式が完結している必要があるため<% %>で書くことになるが、Erubis+Merbの場合はendを<% end =%>として終わりを示すという形式になるそうです。

 HTMLとRubyが混在するため、文法エラーがみつけにくい、特にendの対応が見つけずらいという問題もあります。erubisコマンドでは展開を確認するさまざまなオプションを用意して確認できるようにしているとの話でした。-xでスクリプトを表示、-Xで埋め込み文と式だけを表示、-Nで行番号付き、-Uで空行を1行に圧縮、-Cで空行を削除、となっていて、-XNCのように重ねて指定できるそうです。

 最後に、テンプレートシステムに関しての桑田さんのアイデアが語られました。テンプレートもコードなので、プログラミングの各種概念がテンプレートに使えるのでないかという点です。

 まず、テンプレートはメソッド定義と考えると、コンテキストデータも仮引数を指定する形式があってもいいのではないかというアイデア。続いて、モジュール化のアイデア。オブジェクト指向の類推で、継承したテンプレートで部分をオーバーライドするアイデア。AOPの類推で、Photoshopでレイヤーを重ねるように、HTMLとプレゼンテーションロジックを分離しておき、重ね合わせてテンプレートにできるのではというアイデア。エスケープなどに合わせてStringとHTMLを別の型とするアイデア(ただしHTMLとStringを連結した場合とか、SQLとか、考えだすときりがない)などが語られました。

 最後に「one more thing」として、ERBもErubisもテンプレートエンジンというよりテキストプロセッサと断じ、Web用のテンプレートエンジンとして必要な機能を実装した「Tenjin」も作ったと紹介して締めました。

基調講演:Rubyと私、そして日本Rubyの会(高橋征義)

 3日間のRubyKaigiのトリは、日本Rubyの会の高橋会長による基調講演でした。羽織袴で登場、最初にステージ中央で正座であいさつするなど、格調高い雰囲気でした。

 内容は今回のRubyKaigiのテーマでもある「変わる/変える」について。ちなみに、前回のテーマが「多様性」であったのを受けて、単に多様であることを確認するだけではバラバラなだけ、なにかしら変えるべき、ということで設定したテーマだそうです。

 第1部では、まず自身とRubyについて紹介しました。出会いは1997年で、Ruby 1.1のころ。ソースを自分でコンパイル、基本的な部分はほぼ安定、という時代で、w3mでアーカイブを読んだあと、1998年1月20日に初投稿したというメールを画面に映しました。

 高橋さんいわく、自分はコミッターではなく、一般ユーザーができることとして、書籍の執筆やイベントの開催、日本Rubyの会の設立などをやってきたとのことです。

 それをふまえて、第2部では、「ユーザー視点」でRubyがどう変化してきたかを紹介しました。視点としては、なにかを捨てなければ変化できない、というもので、宇多田ヒカルの「みんなの願いは同時にはかなわない」という歌詞を引用していました。

 昔のRubyはまつもとさん一人が開発していました。問題としてはまつもとさんがよく知らないもの、興味ないもの、使ってない環境への対応(Windows)は入らないということがありました。また、まつもとさんひとりでは、言語の変化や規格の変化、新規格、ライブラリ、世の中の流れに追いつけないという面もありました。そこで、コミッターが増加して、みんなでメンテしました。それとひきかえに失ったものは、統一性であり、対応の早さ(意思統一)であったと高橋さんは分析しました。

 次にRuby 1.6を開発していた時代には、「Programming Ruby」をきっかけとする海外進出の本格化が起りました。これは、Railsへの下地でもあります。それとひきかえに失ったものは、英語圏のコミュニティと日本のコミュニティの意思疎通であり、分断が起きたと高橋さんは分析しました。

 続いてRuby 1.8の時代には、RailsをきっかけとしてRubyが一般に普及しました。それとひきかえに失なったもの、起きた問題は、開発プロセスがどんどん重くなること、使わされるユーザーが増えてネガティブな声が増えてくること、Rails文化とRuby文化の分断であったと高橋さんは分析しました。

 このようにRubyが変化してきたことについて、「変わらないほうがよかったか?」という疑問に高橋さんは「No」と答えます。重要なのは、喪失をおそれないこと、それを超える収穫を得ること、変化を選別しコントロールすることだと語りました。

 第3部では、自身に変えられるものとして、「日本Rubyの会はどう変わるのか、どう変えていくのか」について語りました。

 日本Rubyの会としての活動は、日本Ruby会議、地域Ruby会議の支援、るびま、るりま、地域コミュニティのハブとしての活動などがあります。

 ここで問題点として「多様化できていない」「手が回らない」「情報公開できていない」ことが上げられ、原因として「私がボトルネック」「私ができることがRubyの会の限界」と反省していました。解決策はぜんぜん未定とのことですが「私がいなくても回るような形」にしたい、「私が知らない新しい人が、私が知らないことをどんどんやってくれる未来」にしたいと語って、講演を終えました。

closing

 閉会式は、早変りした高橋会長がTシャツ姿で登場。さっきまでの基調講演とテンションちがう感じで、3日間のRubyKaigiを締めくくりました。

RejectKaigi

 ボツLTが集うRejectKaigiが、今年も会場撤収と同時に開催されました。以下、一気に箇条書きで。

  • Wilson
  • require "php"
    • ドワンゴの人
    • 「==」演算子をPHPと同じようにする
    • 1 == '1' => true
    • 100 == "0x64 => true
    • "1e2" == "0x64" => true
    • true == 1 => true
    • nil == false => true
    • nil == '' => true
    • nil == [] => true
    • nan == nan => true
  • AlphaGripper(ukstudio)
    • キーボードの勢力:HHK、Kinesis、Other
    • 新たにAlphaGrip
    • ソファでリラックス
  • TDD、アジャイル…(yamashiro)
    • Java-jaから来ました
    • 黄金の回転
    • すべてのプログラマはジョジョを読んでいる
    • 才能(スタンド)じゃなくて技術
    • 宮本武蔵はアジャイラー
      • 各個撃破
    • レッド、グリーン、リファクタリングの回転
    • java-ja.rbを
  • OOPJog(tsuyoshikawa)
    • オブジェクト指向の話をしながら皇居のまわりをジョグる集まり
    • 毎週
    • Rubyの伝導
    • http://bit.ly/oopjog
  • 日本sinatoraの会
    • 当初の設計思想は変えずに内部構造を変えてきた
    • 思春期の終り
    • R.I.P. Sinatora
    • 私が守るから
  • MySQL/Ruby終了のおしらせ(とみたまさひろ)
    • MySQL/Ruby
      • MySQLのCライブラリーのラッパー
      • Railsも利用。超重要
      • 作者俺
      • 「Macでコンパイル」Macください
      • 「Win...」Winいりません
      • 「1.9...」ごめんなさい(今は動く)
    • Ruby/MySQL
      • Cつかってない
      • 作者俺
      • 今後こっち
      • MySQL4.3以降
      • 互換性ない
      • おそい
      • コンパイル不要
      • GPLにしばられない
      • queryにprepared statement直接書ける
    • 「AR使ってるから関係ない」orz
  • (Yoshiori)
    • おととい高橋会長に「Rubyist名乗っていいよ」と言われた
    • kaigifreaks += 1
    • RubyKaigiのタイムテーブル
      • タイムゾーンが書いてない
      • チケット販売だけかよ!
    • そこでスウォッチインターネットタイム
      • めんどい
      • 作ってみた
      • require "itime"
    • タイムテーブルにあてはめてみた
    • tDiaryプラグイン書いた
  • Ruby/tkのデフォルトウィジェットセット(永井)
    • まじめっぽい内容をすごく早口で語るネタ
    • tileとよばれていたもの
    • ttk_wrapper.rb
    • Ruby/Tkスクリプトをテーマエンジンに対応させる
    • Tk.default_widget_set = widget_set
    • ウィジェット集合の切り替え
    • 条件の組み合わせがすごくややこしい
    • オートロード多用
    • ややこしいことをやったおかげで1つの式できりかえができるようになった
  • Rubyとドラクエのフシギな関係(hogelog)
    • 右端のターミナルのemacsからRubyの式を評価してプレゼン
    • スライム=SLIME
    • インタプリタ型言語というならemacsの選択した部分を評価できてしかるべき
    • Rubyを評価するサーバーと通信
  • Rubyでつくる新プログラミング言語DT(faultier)
    • Rubyの処理系を作ろう
    • 無理。方向変換
    • Rubyで処理系を作る
    • 「oo君って童貞」とかのシナリオがソース
    • インタプリタ
    • 抽象構文木
    • llvmバイトコードへのコンパイラ
    • githubで公開中
    • デモ
  • エクストリームSass開発(すがまさお)
    • Haml/Sass
    • sassコマンドでCSSに変換
    • めんどくさい
    • Saagツール
      • githubで公開
    • ソースの変更を感知して自動的に変換
    • デモ
  • (yugui)
    • 口頭
    • Ruby 1.9は速すぎる
      • 遅くして1.8互換にするネタを考えた
      • でも最適化をオフにしても速い
      • ボツ
    • Rubyは人が足りていない
    • みなさん手伝ってください
      • るりま
      • ruby-devの英語への翻訳
      • redmineの改造
      • リファレンスマニュアルのツールの開発
      • 2chにたまに入る有益な提案を監視してMLに流す人
    • やれることはたくさんある
  • RubyKaigiスタッフになるべき理由(mootoh)
    • 2007年は参加者
      • 友達ほしい
    • 2008年はLTスピーカー
      • もうちょっと
    • 2009年はスタッフ
      • 人としゃべれる
      • スタッフやさしい
      • 友達がふえた
    • あなたも
  • GitHub
    • 日本はトラフィックNo.4
      • US、UK、Germanに続く
    • Github を社内ネットワークに
      • ruby code
    • JRubyはfantastic
    • Enterprise company
      • proprietary code
    • Grip
      • Jruby compatibility version gem
    • GitHubを使えばJRuby対応
  • Qt(gitorious)
    • 3月に新しくなりました
      • ノキアによる買収
      • モバイル対応
      • IDE
      • LGPLでフリー
    • QtRuby
    • Ruby 1.9にすごい勢いで対応してきている
    • WebKit
    • Qtを検索するときは「-quicktime」を忘れずに
  • VER
    • Ramazeの人
    • vi emacs ruby
    • viとemacsのいいとこどりのテキストエディタ
    • pure ruby
    • 設定もRuby
    • 基本的なところは動いている
    • Rubyのコードをバッファで評価したり
    • github.comにあるよ
    • 宗教戦争をなくしましょう
  • Ruby、Rails教育で2番目に大切なこと(yuumi3)
    • 2番目は「EY-Officeに相談」w
    • 1番は
    • 完璧なテキストではない
    • カリキュラムではない
    • 名人講師というのはあるけど、あまりいない
    • やはり自分たちで教育すること
      • テキストよりコードで語りましょう
  • (匿名希望)
    • Javaのえらいひとがガツンと「仮に、Javaのほうが二倍コードを書く必要があったとしても」
    • グラフにしてみる
    • 2倍じゃすまないw
  • (takesako)
    • change→変→変態?
    • 記号polyglot
    • Perlでも実行
    • Rubyでも動く
    • 1.9で動作が変わる
    • JSでも動く
    • 無名の質w
    • 記号しかないキーボードでも大丈夫
    • 真偽値の違い
    • 1.8と1.9文字列の違い判定
    • C88/89
    • C++
    • すげー
  • るりまをけんさくするn個の方法(kouduki)
    • Ruby 1.9
    • ドキュメントはるりま
    • 検索はGoogle
    • 見つからない
    • そこでFirefoxのUbiluity
    • デモ
      • "ruby api search String"
      • "ruby api search String g":Googleで検索
    • サイト作ったほうが楽だったかも
  • iPhone app作成にRubyを活用したりしなかったり(アカイシュンペイ)
    • iPhone SDKはいい
    • Webスクレイピング
    • libxml/SAX+C/Objective-Cは苦行
    • RubyでNokogiri
    • さくっと作る
    • 移植
    • Appleにリジェクトされた
    • 不適切
      • ふたばちゃんねると4chan
  • ニコニコ動画とスクレイピング地獄
    • 新着動画を残さずチェック
    • 検索ページをすべてスクレイピング
    • ページが変更されると動かない
    • 変化しにくい場所
      • Xpathだと変更に弱い
      • URL
      • APIl
        • スクレイピングしない 最強
    • APIも変更される
      • 予告がある
      • @koizuka
    • リクエストパラメータをチェック
    • 「表示回数」というラベルからたどる
      • 実は未実相
    • APIほしい
  • 拡張ライブラリを作るとリア充(さいとうただし)
    • 流れるようなプレゼン(スクロール)
    • Desimal
    • Ruby 1.9対応した
      • まだリリースしてない
    • なぜ拡張ライブラリ
    • リア充
    • バグをくいまくり
    • 「やった、SEGVだ」
    • 変な仕様ががんがんみつかる
    • 君の文句で仕様が直る
      • うれしー(棒
    • Decimalの歌
      • ドラふたつw
  • 拡張ライブラリをD言語で作るとリア充(tama)
    • Cで拡張ライブラリを作るのはやめたい
    • Cの次といえばD
    • Cを直接呼べる
    • けっこうRubyっぽい
      • むりやりshbang
    • gdc+1.8のみ
    • GCまわり危ない
  • Tsukuba.R was born in RubyKaigi(syou6162)
    • 来年から関西
    • KaigiFreaks
    • Rのコミュニティ
      • 統計処理の言語
      • グラフも
    • 大学で勉強会をやっていたが人が集まらず消滅
    • KaigiFreaks 2008
      • 学んだ
      • みんなで楽しむ
    • 2008.7 Tsukuba.R開催
      • 4人がRubyKaigi当日スタッフに
      • いい笑顔がみれました
    • 会場拍手
    • ドラ連発

コメント

コメントの投稿

管理者にだけ表示を許可する

トラックバック

http://emasaka.blog65.fc2.com/tb.php/643-dd2fcd86

 | HOME | 

Categories

Recent Entries

Recent Comments

Recent Trackbacks

Appendix

emasaka

emasaka

フリーター。
連絡先はこのへん

Monthly


FC2Ad