本を読む

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

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

「多読術」

多読術 (ちくまプリマー新書)
松岡正剛
筑摩書房
売り上げランキング: 1821

 読書論というと、良書を読んで人生の糧にしなくてはならないみたいな話になりがちなのだけど、本書は、「コンビニでおにぎりを買うように本を読む」「酒を飲むように本を読む」「服を着るように本を読む」という、活字中毒な読書論。いわく「読書に貴賤なし」。最近では「千夜千冊」で知られる松岡正剛氏へのインタビューをまとめた本。読書人生をふり返る自伝的な感じ。

 本書でいう「多読」の論点は、単体の本ではなく、複数のものの関係性の中から能動的に新しいコンテキストを作り出すということだと思う。

  • 人生において同じ本を複数回読む:自分のとらえかたの違いを楽しむ
  • スポーツ選手がいろいろな筋肉を鍛えるようにさまざまな本を読む
  • 書いている対象と意識の二重進行
  • 対角線の編集読書:正反対のジャンルを決め、そのあいだをグラデーションをなすように読んでいく
  • 感読レセプター:理解できなかった本が、ほかの本を読んでから読むと理解できるようになったりする
  • 複合認知:読書体験には、内容だけでなく、たとえば文字の形や読むシチュエーションなども重層的に含まれる
  • 図書館や書店はそのものが読書
  • 本は、すでにテキストが入っているノート
  • 「書くモデル」を「読むモデル」にしていく
    • コミュニケーション
    • ズレと合致のゲーム
    • 意味の市場
  • 意識と無意識
  • 「情報の歴史」:本に登場する年号を片っ端から年表にマッピングした
  • リンクをふやす編集的読書法
  • 本棚の「三冊の並び」
  • 読前術・読中術・読後術
  • いろいろな読み方をする:机で読む、ソファで読む、風呂で読むなど
  • 好みの多様性
  • 読書は水たまり
  • インターテキスト
  • 類書を近い時期にまとめて読む
  • おもしろいと思った本から別の本に、ジグザグにつながっていく
  • 読書間隔を維持する
  • 「いい本」にめぐりあう確率は、最高で3割5分ていど
  • 「鳥の目」と「足の目」
  • 井上ひさしや本居宣長の「年表」「地図」作り
  • 単語の目録、イメージの辞書、ルールの群
  • 知人に薦められたり贈られたりした本を読む
  • 読書は他者との交際

 これを敷衍したのが、著者が以前から唱える「編集」論(すべての知的活動は広義の「編集」である、的な)なのだけど、それは置いておく。

 ちなみに、本書で紹介されている「餃子ロード」が読みたくなったのだけど、各種オンライン書店でも品切れらしい。残念。

餃子ロード
餃子ロード
posted with amazlet at 09.07.30
甲斐 大策
石風社
売り上げランキング: 323787
スポンサーサイト

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当日スタッフに
      • いい笑顔がみれました
    • 会場拍手
    • ドラ連発

「新クロサギ」3巻

 「導入詐欺」「留学詐欺」「制度融資詐欺」を収録。今回の手口は、ネタバレなので「続きを読む」で。

続きを読む »

「劇画ヒットラー」

劇画ヒットラー (ちくま文庫)
水木 しげる
筑摩書房
売り上げランキング: 26542

 水木しげるがアドルフ・ヒトラーの生涯を、自意識過剰なダメ男として描いた作品。断罪するのでも、カリスマとして描くのでもなく、等身大に話を進めているのが異色。しかし、いちばん描きたかったのは、最後の3ページなのかも。

「MW」1・2巻

MW(ムウ) (1) (小学館文庫)
手塚 治虫
小学館
売り上げランキング: 9
MW(ムウ) (2) (小学館文庫)
手塚 治虫
小学館
売り上げランキング: 10

 そういえば手塚治虫ってドストエフスキーに影響を受けてるよな、と思ったら、Wikipediaに本人の言葉が引用されていた。

Windows AzureでPHPを動かす話を聞いてきた

 7月16日に、マイクロソフトのWeb技術系イベントReMIX Tokyo 09が開催されました。中でも、PHPコミュニティの人がWindows AzureでPHPを動かした話をするということで、「Silverlight + PHP(FastCGI)+ Windows Azure で作る初めてのクラウド アプリケーション~初めてクラウド アプリケーションを作成するあなたにお届けする渾身の 60 分~」というセッションを聞いてきました。

 既存のWebアプリを移植するときに、RDBMSっぽいインターフェイスに対応しているというのが、Azureの売りのひとつのようですね。

 以下、メモ。

開田文雄(マイクロソフト)

  • Windows Azure Platform
    • 最近変更になった名前。旧Azure Services Platform
  • 単体ではない
    • Windows Azure
    • SQL Azure(旧SQL Services)
      • 1st releaseではDB本体のみ
      • BI、レポーティングもいずれ
    • .NET Services
      • アクセスコントロール、サービスバス
    • LiveServices
      • あとから(秋)提供予定
      • Liveの機能を提供
      • アイデンティティ、連絡先など
  • DCの構成
    • ホスティング
    • ストレージ
      • ファイルシステムとして提供されるのではない
    • ファブリックコントローラー
      • サーバーやアプリケーションを管理
      • インスタンスを増やすには、管理ポータルから定義ファイルをファブリックコントローラーに送り込む
    • ユーザーはハードウェアを意識することはない
      • アプリケーションだけ意識すればいい
  • SQL Azure
    • SQL (TDS):表形式
      • SQLServerと同じに使える
    • いままでのアプリの接続先を換えるだけで、SQL Azureに対応できる
    • ちょっと前はRESTかSOAPで、key-value storageだけだった
      • ユーザーからの要望が多かったので変更した
  • プログラミング
  • 開発
    • FastCGIでPHP、Python、Ruby、Javaが使える
    • Visual Studio
  • デバッグ
    • Azure SDK
      • Azureをエミュレート
  • デプロイ、運用
  • 管理ポータル
    • 管理は可能なかぎり自動化
  • Visual Studio
    • クラウドテンプレート
    • Webアプリケーションのプロジェクト
    • Silverlightのプロジェクトを追加してみる
    • Development StorageでSQL Azureをエミュレート
      • 2GBまでの制限
    • デプロイ
      • 発行ボタンで、パッケージが作られる(.cspkg、.ccscfg)
      • ポータルからアップロード
      • Staging(テストサイト)とProduction(公開サイト)
  • 秋のPDCごろにリリース
    • それまでは無料で使える
  • Visual StudioのWeb Developers Edition(無償)でも開発できる
  • Windows Serverとの違い
  • サービスアーキテクチャ
    • Webサーバーとアプリケーションの間の通信
      • ここの設計を間違えるとスケールしない
    • Webロール(Webサーバー)とWorkerロール(アプリケーションサーバー)
      • ストレージサービスを介してキューで非同期に通信
      • ロールごとにスケールアウトできる(インスタンス数を変えられる)
  • Windows Azureストレージ
    • 上のストレージサービスはインスタンスごとの一時的なもの
  • 永続的なデータ
    • ブロブ
      • バイナリデータ
    • テーブル
      • スキーマレスの表形式
      • レコードごとにカラムを変えられる
      • ブロブより粒度の細かいデータ
      • レコードごとにサーバーを変えられる
      • これがあるのでSQL AzureはSQLにした
    • キュー
      • メッセージ交換
      • REST
      • 秘密鍵で署名したメッセージのみ
  • デモ: http://www.asp.net/ に転がっているアプリをAzureに
  • アプリがASP.NETのプロバイダーモデルに対応しているので楽
  • 変更は1か所に
    • AzureStorageを読むように
    • ReadAndValidateXmlメソッドを変更
    • BlobStorage.create()
    • GetBlobContainer()
  • ついでに日本語に
  • ストレージ
  • http://www.codeplex.com/ にコードが
    • xmlを変更

亀本大地(アシアル/日本PHPユーザ会)

  • PHP on Windows Azure
  • PHPのメリット
    • 数多くの良質なオープンソースアプリケーションが存在する
    • 資産を活用
  • PHPをWindows Serverで使うメリット
    • *nixに比べると実績は少ない
    • が、プラットフォームを統一できる
  • Azureのメリット
    • 管理労力・コストの削減
      • LinuxとWindowsの両方の面倒をみたりする必要がない
      • プラットフォームの面倒をみなくていい
    • Webアプリケーションのことだけ考えればいい
    • SQL Azure
      • クラウドでRDBMSを使える
  • SDK上でやってみる
  • ツール
    • VS 2008
    • Azure SDK
    • Azure Tools for Microsoft Visual Studio
    • Windows版PHP(Non Thread Safe)
  • デモ
  • Visual Studio
  • クラウドテンプレートからプロジェクト
  • Webロールを追加
    • Cgi Web Role
  • FastCGIに必要なファイルが生成される
    • ServicesDefinition.csdefを開く
      • enavleNativeCodeExecution="true"
    • Web.config
      • system.webserverのFastCGIの設定
      • 拡張子php、scriptProcessorにphp-cgi
    • Web.roleconfig
      • php-cgi
  • PHPのバイナリをつっこむ
    • VSでphp.iniをコンテンツ扱いに
  • phpinfo()が動いた
  • PukiWikiを動かしてみた
    • あまりいじらないで動いた
  • 移植のチェックポイント
  • Linuxと変わる点
    • .htaccessの設定
      • web.configに書きかえる。だいたいできる
      • TechNet参照
    • PHPのCGI設定
      • cgi.force_redicect = 0
  • Amazon、Google、Azureの比較
    • Amazon:OS管理は自分で。ほか2者とサービスのレイヤーが違う
    • Google:SLAなし

続・LWPはHTMLのhttp-equivを解釈する

の続き。

 PerlのLWPを使っていて、最近どうも挙動がヘンだなぁと思っていたところ、上記エントリで書いたような仕様が変わっていました。ハマったのでメモ。

 Changelogより。

2009-06-15 Release 5.827

(略)

Don't let the parse_head callback append to the HTTP headers

 挙動としては、HTTPヘッダとmeta http-equivとで同じ項目がある場合に、後者が無視されるようになってました。

 LWP::UserAgent.pmより。

変更前:

               $parser = HTML::HeadParser->new($response->{'_headers'});
(略)
                   callback => sub {
                       return unless $parser;
                       $parser->parse($_[3]) or undef($parser);
                   },

変更後:

               $parser = HTML::HeadParser->new;
(略)
                   callback => sub {
                       return unless $parser;
                       unless ($parser->parse($_[3])) {
                           my $h = $parser->header;
                           for my $f ($h->header_field_names) {
                               $response->init_header($f, [$h->header($f)]);
                           }
                           undef($parser);
                       }
                   },

追記2009-07-21

 Web::Scraperは0.31で対応してました。それによると、レスポンスオブジェクトのcontent_charsetメソッドで調べるといいようです。Changesより。

- Use new LWP's content_charset method instead of HTTP::Response::Encoding
(Thanks to hanekomu)

「DRBD開発者Philipp Reisnerと語るゆうべ」に参加

 9月13日に、サードウェア社が中心になって開催された勉強会「DRBD開発者Philipp Reisnerと語るゆうべ」に参加してきました。

 DRBDというのは、Linuxのブロックデバイスのドライバーにはさまって、TCP/IPごしにミラーリングするソフトです。インフラ系でちょくちょく採用例を聞くようになってきているところに、作った人が中身の話をしてくれるということで、聞いてきました(遅刻しましたが)。MySQLがDRBDに対応していることもあってか、MySQLの中の人も何人か来ていました。

 質問歓迎ということで、パフォーマンスや障害時の挙動などに質問が集まりました。最近はディザスターリカバリー方面の機能強化がいろいろ着手されているようで、サードウェアでも検証のために回線遅延シミュレータを借りたりしているようです。

 懇親会でもそのまま質問が続き、ホワイトボードが図でいっぱいに。自分のまわりでも、「DRBDなデバイスからブートするのは可能か」「そりゃ無理」とか、「RAMディスクをDRBDでハードディスクにミラーする」というヨタとか、活発に議論がなされていました。ちなみに、最後には「Software Design」2009年6月号のサイン大会になりました。

 メモをとりながら聞いたので、とりあえずメモほぼそのまま載せておきます。支離滅裂ですが。英語も技術もよくわかってないので、間違いなどありましたらご指摘ください。自分がメタデータのあたりがよく理解できてないのが残念。

CacheとDisk Schedulerの間に入る

write-after-writeの依存関係
re-ordering
依存関係のある部分は順序にバリアを入れる
CPUのOut of order実行みたい

Q: すべてシリアライズしちゃう? 大量のDBアクセスとか。ネットがボトルネックになるのでは?
A: Yes、すべてシリアライズ。回線やNICの高速化(と"money")に期待

avoiding data diversion
通常、2つ以上の通信パスを持つ
コケた場合、リプリケーション先が古くなる
outdateマーク
bitmap
headtbeat / pacemaker
CRM constraintsベースの実装done

Q: リクエストを出したあとにコケたら?
A: つながったときに返事(?)。だから想定するとおりに動く

activityのロギング
クラッシュ後にフルに同期しなおすことはない
更新をためこむ
メタデータの更新は最小に
4MBのextent
同じ領域の書き直しをチェック(?)
LRUで置きかえ

Q: オーバーヘッドは
A: アプリによる。DBのロックなどは同じところを読み書き。アプリによってはランダム

Shared disk Semantics
どちらのノードも読み書きする場合
GFSなど
同時に同じブロックに書き込むと、たいていのファイルシステムではこわれる
Webに論文
考えられる組みあわせをsimulation

性能
GBe vs. 10GBe: Disk I/Oがボトルネック
シーケンシャルなアクセス: 3%落ち
bonnieベンチマークのアクセスパターン: 4%落ち

用途
DB: PostgreSQL、MySQL、Oracle
HA virtualization: Xen、KVM、VServer、OpenVZ/Virtuozzo
HA SAN: iSCSI
 複数のDCにあるiSCSIターゲットをインターネット経由でつなぐ
 それぞれのDCからはローカルなiSCSIターゲットにアクセス
HPCファイルサーバー: Lustre
Clustered Samba
Linuxアプリ

DRBD 8.3: Device stacking
DR用に第3のノードを接続できる
DC内は同期、DC間は非同期にできる
デイジーチェーン接続できる

1999スタート
AustriaのUniversity Vienna
8.2: online verify、end-to-end checksum
8.3: deice stacking、>4TB、checksum based resync (←DRBD+)

商用版
DRBD Proxy
でかいTCPバッファみたいなもの
非同期
4CPUサポート。もっと増やす

Roadmap
8.3: Compressed bitmap exchange、>16TB、Infiniband
9: もっとノード、フルにログ、モジュール化

Q: low latency
A: send more packets、big packets

Q: ファイルシステムのおすすめは
A: なんでも。ディストリビューションでサポートしてるものを。xfsはスケールするからいいんじゃないか(?)。raiserfsは使わないほうがいい(笑)細かいところを自分でいじっていて(?)エンタープライズ用途では使えない

Q: DRBD+の機能をマージした理由
A: ビジネスモデルの変更。サポートのほうで

Q: Infinibandはもう対応?
A: あと1-2か月
Q: モジュール化は
A: ロギングとか大変

Q: バージョン番号が0.8から8にひとけた飛んだけど(笑)
A: よくあること(笑)

「リスクをヘッジできない本当の理由」

リスクをヘッジできない本当の理由 (日経プレミアシリーズ)
土方 薫
日本経済新聞出版社
売り上げランキング: 74055

 マンガ「Q.E.D.」のエピソード「レッド・ファイル」で、金融工学に携わる数学者が「数式で市場の未来がわかるわけじゃないんだけど」と嘆くシーンがある。

 現在の、サブプライムローン問題をきっかけとする経済危機は、「100年に一度の危機」と言われる。が、この10年でも、ブラックマンデー、S&L危機、メキシコ通貨危機、LTCM崩壊、米国ITバブル崩壊と、金融危機を繰り返してきている。

 本書は、なぜ同じような危機を、頭のいい人達がくり返すのか、というのを一般向けにやさしく解説する新書。結論を言っちゃうと、市場の本質は、幅を想定できる「リスク」ではなく、想定できない「不確実性」であるというのが本書の主張だ。この主張を、行動経済学的な考えなどを用いて説明している(らしい。行動経済学も人間の行動を想定しようとする試みなのだろうと想像されるけど)。

 以下、本題とは関係なかったりもする細部のメモ。

  • 15年間勝ち続けるファンドが1つ残る確率は0.000448%
  • ジョージ・ソロス「市場は過去の経験から予測できるものではない」
  • トレーダーの心理的バイアス
    • 代表性の近道選び
    • 過信
    • 認知的不協和
    • 感応度逓減
  • 金融工学の価格モデルでは、ドリフト項(確実に上昇する部分)+ウィーナー過程(ランダム・ウォークする部分)の組み合わせで考える
  • ファットテール:正規分布にあてはまらない値動き
    • きっかけがわからず、値動きが速い
  • サンクトペテルブルクの逆説
  • 現代ファイナンス理論では、人が一気に損切りするような行動は想定されていない
    • 行動経済学の理論では、「参照点」を境に人は失う価値を2.0~2.5倍ほど重要視する
  • 2005年、「ファイナンシャルタイムズ」に「原油価格は144ドルになう」と予言した人物がいた
    • 実はウサマ・ビンラディン

「新ナニワ金融道」4巻

新ナニワ金融道 4 絶望銭色吐息!!編 (GAコミックス)
青木雄二プロダクション
Bbmfマガジン

 掲載誌を「SPA!」に移して新エピソード開始。今回は駅前商店街をめぐる仁義なき地上げ合戦。

 今回の豆知識はネタバレを含むので「続きは読む」で。

続きを読む »

「キリン」37巻

 ドタバタコメディ「WONDER NET WONDER」編の2巻目。道の向こうから海がせり上がってくる感じ、いいねぇ。イメージとしては三浦半島あたりなのかな。巻末には、H2マニアの人からの濃いツッコミを掲載。

「宇宙兄弟」6巻

宇宙兄弟 6 (モーニングKC)
小山 宙哉
講談社
いいとこだな ここは
何も気にせず見れる

 ムッタの選考とヒビトの出発。やっぱりキャラクターとエピソードがうまい。

「PLUTO」8巻

PLUTO 8 (ビッグコミックス)
浦沢 直樹
小学館 (2009-06-30)
ロボットは怒らないと思ったの?
ロボットは泣かないと思ったの?
ロボットは憎しみを持たないと思ったの?

 最終巻。絶望と希望をぎりぎりのところで均衡させていて、いい。

「謹製イロイロマンガ」「帽子男」「五万節」

 上野顕太郎のマンガが版元をまたいで3冊同時発売された。もちろん買った、ヒマだからな。

謹製イロイロマンガ
謹製イロイロマンガ
posted with amazlet at 09.07.05
上野 顕太郎
ぶんか社

 「謹製イロイロマンガ」は、あちこちに掲載された未発表短編を集めたもの。自分としては、さまざまなマンガや映画などを麻雀ネタでパスティーシュした「上野麻雀」が単行本に収録されたのがうれしい。ネタ細けぇ~!

 ほか、学習雑誌に連載された「熟語漫画」など、計448ページのボリュームで満腹。

帽子男 (BEAM COMIX)
帽子男 (BEAM COMIX)
posted with amazlet at 09.07.05
上野 顕太郎
エンターブレイン
五万節 (BEAM COMIX)
五万節 (BEAM COMIX)
posted with amazlet at 09.07.05
上野 顕太郎
エンターブレイン

 「帽子男」と「五万節」は、既刊の「帽子男は眠れない」と「帽子男の子守唄」(絶版)を再構成し、その他の作品も含めて復刊したもの。

 「帽子男」は、題名のとおり帽子男シリーズだけをまとめた本。「断崖の帽子男」を見ると、修正も入ってるらしい。新作の「帽子男は二度死ぬ」編も読めて、なんつーかシリーズとして芸風変わらないすね(いい意味で)。

 「五万節」は、掲載当時に上野顕太郎の名を世に知らしめた(私のまわりでだけど)「うえけん五万節」をはじめとして、短編を掲載。こっちは多才な感じ。デビュー作「煙草撲滅委員会」と、デビュー前に新人まんが賞の特別奨励賞を受賞した「Dを訪ねた2人」も読める。審査員の山上たつひこの「ギクシャクとしたおもしろさ」という評がイイな。

「Shibuya.lispテクニカルトーク#3」観覧

 Lispコミュニティ「Shibuya.lisp」のテクニカルセミナーイベント「Shibuya.lispテクニカルトーク#3」が開催されました。今回はGaucheの川合史朗(Shiro)さんも登壇するなど、やはりすごく面白い話をいろいろ聞けました。

 以下、観覧メモ。間違いがあったらご指摘ください。

 今回は、メイントークでCommon Lispの2件も継続を活用していたのが印象的でした。継続は力なり。あと、Lispとは関係ありませんが、なぜかプレゼンターのうち2人もタイル型ウィンドウマネージャを使っている方がいました。

開会の挨拶(佐野匡俊)

 前回からのアップデートが紹介されました。なんといっても、Shiroさんが開発した、Lingrを継ぐチャット「Chaton」が大きいトピックでした。一方、逆引きCL/Scheme/Clojureは停滞ぎみで、知りたい側の人の声が欲しいとか。

 次回のテクニカルトークはだいたい4か月後だけど詳細未定とのことで、まずは初回のようにスタッフのキックオフミーティングを開いて意気を上げることを考えているそうです。さらに、ネットをあまり見ずに研究してる人とかも交流したいという話も聞かれました。

世界一短いコードでwebアプリ作成ができるフレームワーク開発(松本智行)

 Common LispでWebアプリケーションフレームワーク「web4r」を開発した話でした。「プログラミングGauche」を読んで本格的にLispに入り、ほかの仕事はすべて断って未踏プロジェクトとして開発していたんだそうです。なので、アドバイスを期待したいとのことでした。

 web4rは継続ベースのWebアプリケーションフレームワークで、Arc、Kahua、Railsの影響を受けているそうです。記述の短さを最優先にしていて、冗長性を削りつつ、マクロで構文をいじったりCPSを活用したりしているとのこと。客席にはRubyのSinatora関係の人もいて、Sinatoraもコードが短いですねという話になっていました。

 まず、S式でHTMLを表現するマークアップする独自開発の「sml」を紹介しました。リーダーマクロでprintの式に展開するのだそうです。CSSふうのセレクタでエレメントを操作したりもできて、スペシャル変数の値でマークアップ言語(HTML、XMLなど)を変更する機能もあるそうです。「cl-whoとかを使わなかった理由は」という質問もあって、cl-whoはリストで渡すから長いのが嫌で、実はそのツッコミはよくもらうのでFAQにしたとの回答でした。

 Webサーバーとしてはhunchentootを利用。ページのアクションはdefun風のdefpage式で定義するようになっていて、引数としてURLやget・postなどのパラメタを受け取るそうです。CPSによるセッション管理はweb4rの特徴なのですが、継続を持ち続けるとメモリがいっぱいになってしまうので、1度呼び出したら破棄するようにしているとのこと。これはいちばん相談したいポイントだったようで、1度で破棄しちゃうとBackボタンに対応できないという問題点が指摘されたり、Kahuaでもそのへんは難しいとかheartbeatで監視して破棄しようかとかいうShiroさんの話もありました。

 面白かったのが永続化クラスというものです。これは、Railsでいうモデルのようなものと解釈しました。クラスのスロットがレコードのフィールドに対応して、そこに拡張オプションで挙動を指定するそうです。defpclassで永続化クラスを指定すると、あとはgenpages関数を呼び出すだけで雛形アプリができるというscaffoldっぽいことができて、会場から驚きの声が上がりました。ちなみに、「ちゃんと複数形も使ってますよ」とRailsな人向けのネタもありました。永続化クラスについてはShiroさんから、面白いし自分も昔考えたけど、たとえば性別の値によって項目をdisableしたりするなどの関連づけをすると大変になる、という体験談もあり、それに対して:hide-for allオプションを紹介しつつ、もう少し考えてみるという回答でした。

 ちなみに、「Lispコミュニティは初心者にやさしくないという声がある。これは真っ赤な嘘」というのも語られました。irc(ただし英語)でとても親切に教えてもらったそうです。ただし、日本語の情報はまだ少ないかもという話もありました。

R5RS完全準拠JVM日本語Schemeインタプリタ「Gino(仮)」(ilma)

 コミュニティや学会などには参加していなくて、ずっと独学でコツコツSchemeインタプリタを作ってきたという報告でした。年内に公開予定とのことです。

 Javaの上で二進木評価装置を作ったのをベースに、S式パーサを追加したりして、R5RS完全準拠のSchemeインタプリタを作ったそうです。処理系がgino.jarという1つの380KBのjarになっていて、最小メモリは4MB(JVM自体は除いて)。厳密なR5RSをベースにしているのでevalの引数が1つだとエラーになるのだけど、そのあたりの互換性をオプションで変更できるんだそうです。互換性の変更は、エラー処理のところで関数名を見てフックして処理しているそうです。

 ネットワークポートも使えて、TCP/IPごしのREPLを実演していました。

 面白かったのが、日本語でエラーメッセージが表示されること。これはJavaのロケール機能を使っているので、LANG=Cを指定すると英語でエラーメッセージが表示されるというデモもなされました。

 ほかに独自機能で面白かったのがトレース機能です。トレース機能を指定して実行すると、どの式が評価されてどういう値になり、それがどの式にどう渡って…という関係がツリー状に図示されます。継続の部分はツリーが切れて、これで初学者が継続を理解する助けになるのではないか、との話でした。

teepeedee2: fast IO in Lisp(John Fremlin)

 全部Common Lispで書いた高速なWeb(アプリケーション)サーバーの発表でした。発表者は、第2回テクニカルトークで、S式による高速正規表現ライブラリcl-irregsexpを発表した方です。発表が英語でしたし、Common Lispの黒魔法みたいなマクロ技を使いまくっていて、私はちゃんと理解できてません(汗)。

 COMETで通信してチャットやゲームをするようなのを想定しているそうで、大量のコネクションにも耐えるし、今話題のslowlorisでもダメージなしというのがポイントでした。1プロセス・1スレッド・1コアの上で、継続によるユーザースレッドでセッションをさばくとのことです。I/Oも、Linuxではepollを使ってノンブロッキングで処理するそうです。このあたり、COMETということで、Chaton開発者のShiroさんも反応していました。

 印象的だったのは、Common Lispのコンパイラにうまく乗るように作ったマクロなどの黒魔術でした。my-defunとmyというのがあってmy-defunの中でmyをスロットアクセスに使うとC++のように決めうちで速い(?)とか、defun-consistentはできるだけ定数にコンパイルしちゃう(?)とか、正直わかってません(汗)。ちなみに、文字列はエンコードとかすると遅いからバイト列で処理しちゃうんだそうです。

 Webアプリケーションの処理としては、web4rとも通じるdefpageとかHTML出力とかCSS出力とかをサポートしているところを見せました。さらに、ゲームを簡単に作れるDSLを紹介し、defgameとかdefplayerとかdefrulesとかを使ってポーカーゲームを作ってみせていました。

Inside c-wrapper(小黒直樹)

 GaucheからCのライブラリをそのまま呼べるようにするc-wrapperの紹介でした。(c-load "hoge.h")とかすると、hoge.hで定義されているライブラリ関数やデータ型を、Gaucheの関数やクラスとして使えるという驚きのしくみです。プレゼンは、「まんがでわかるLisp」のクダーと女の子(名前忘れた)を案内役に、ブロック崩し(breakout)をGaucheで作る過程を見せて、場内爆笑でした。

 考えとしては、Gaucheで拡張ライブラリを作るとstubを作るのが面倒で本体にたどり着くまでに疲れちゃうので、ヘッダファイルをパースして情報を得て使おうというものだそうです。そのため、よくも悪くもCの関数そのままの形式やメモリ管理になるそうです。Gauchaの関数もCの関数ポインタに変換するので、Cのライブラリにコールバック関数としてlambdaを渡せるのがいいですね。ただし、GCから保護するためにこのlambdaはハッシュテーブルに登録しているので、自分でハッシュテーブルから削除しないとメモリに残りっぱなしになっちゃうそうです。

 ただし問題になるのは、関数マクロやインライン関数などライブラリのシンボルテーブルにない「見えない関数」。これについては、ヘッダからパースした結果をS式に変換して関数にしているそうです。関数マクロは文字列操作なので関数にするには限界がありますが、実際にはいまのところ問題にぶつかっていないとのことでした。

 あと、ヘッダのincludeをたどっていくと、たとえばreadシステムコールの定義がパースされて、Gaucheのread関数が上書きされてしまっちゃったりという問題が起こりえます。そこで、c-loadに:importオプション(インポートするシンボルを指定)と:hide-symbolsオプション(インポートしないシンボルを指定)というオプションを設けて対応しているそうです。これには、たとえばgtkをそのまま読み込むと16,000シンボルをパースして定義しようとして遅いので、:importでパース対象を絞って高速化、という使い道もあるそうです。

 高速化としてはほかに、パーサをCで書き直したり、オブジェクト変換のオーバーヘッドを抑えたり、eval処理の時間を短縮したりといったチューニングをして、130倍速くなったそうです。パース結果から共有ライブラリをあらかじめ生成しておくcwcompileという機能も作ったそうで、インライン関数の制限がなくなるとか、Mac OS XでSDLを使うときの問題(スタティックライブラリを参照する)を避けるのに使ったりというメリットもあるようです。Mac OS Xといえば、dlloadが遅いので遅延ロードするという対策もやったそうです。

(現場のScheme)と(Gaucheの進化) (川合史朗)

 川合史朗(Shiro)さんのセッションは、「仕事でLispをするということ」と、「そのためにGaucheをどう使うか、どういう仕様を追加するか」が結びつけられて語られ、すごく印象的でした。

 Shiroさんは、自分のプログラマとしての仕事を「動くプログラムを納入することが至上命題」とし、自分を「モンスター退治の雇われ勇者」になぞらえ、「Gaucheという武器を常に磨いておく」ための必要をGaucheの進化の目的と語りました。

 以下、まとめきれないので箇条書きで。ちなみに、語られた機能はまだunofficialな構想で、無保証とのことです。

  • 性能
    • 「常に最速である必要はないが、確実に要求を満すには必須」
      • 確実に下限は切らない
    • 「Cで書かれた部分が律速」という人もいるが、実際には5割VM、3割GC、2割がCルーチン
    • GBオーダーのデータセットも日常的に扱う時代に
  • まっとうな手段もあるが、納期によってその場しのぎもアリ
    • 禁断の果実Macro
      • Gaucheのクラスは遅い。スロットアクセスとか
      • そこで、マクロを使ってベクタで代用
      • これは近い将来、組み込みのreord型に進化予定
  • compiler macro
    • いまtrunc
    • あとでapiを用意
  • beyond copompiler macro
    • macroからは外の環境を見るのは難しい
    • あとからわかる情報は使えない
    • シビアな制限
      • C++のテンプレートではできたりすることも
    • メタな情報を使えるマクロの構想
  • 「schemeが遅ければCで書けばいいじゃない」
    • extensionにするのは手順的に重い
    • 「この関数だけCにしたい」という用途とか
    • linline-stub
      • schmeソースの中に書ける
      • schemeのようなC
        • cise (C in S-expression)
        • 「私はなんべん無駄なforを書いたんだろう」
    • inline-stub + AOT compiler(後述)
      • ATOコンパイルされてなければ、ソース上でスルーされるだけ
  • 地道でまっとうな改善
    • JIT
      • v8に刺激されて実装してみた
      • 倍ぐらいのスピードになった
      • ただし、実装よりメンテの手間が問題なので、様子見
    • no consing重要
      • たとえば、関数のoptional引数はリストになるが、分解するだけ
      • スタックに置いてリストにしない仕様を実装
    • 浮動小数点数
      • 1ワードに入らない
      • ナイーブな実装だとヒープに置く
        • GCが多発
      • 専用のレジスタバンクに置く手法の論文を書いた
        • 一種の世代別GC
        • truncに
      • 「もうヒープにアロケートする時代ではない」
  • Conservative GCの限界
    • Boehm GC
      • Cのポインタに見えたらポインタにする
      • hashtableのchainedでfalse pointerになりがち
    • Compact Trieを使ってsparce tableを実装
    • util.sparse
  • Concurreency
    • ハードの力でパワーアップしようという案件もあるので、それに対応
      • thread-safe queue
      • thread pool / process poool
      • lock-free / wait-free data structure(未定)
      • immutability(clojureのような)(未定)
  • 簡潔さ
    • 「自分が生き残るために必要」
      • 4年前に納品したコードに機能追加、という案件
      • 5万行あったらたいへん
  • 関数名を短くするとかの、見かけの短さも、実は馬鹿にできない
    • lambdaを^におきかえるとか
      • 入れる予定
    • スロットのリファレンスを~で
    • haskellの「$」は迷っている
    • CLスタイルの引数はtruncに入れた
      • :optional、:key
    • util.matchへは組み込みへ。match-lambda。「^*」という短縮名
      • 関数型言語っぽい記法も?
  • パージングにPEG
    • util.peg
    • 性能上の問題が未解決
  • 多相
    • generic-functionのディスパッチが重い
    • メソッドキャッシュ、型宣言/推論?
    • mapとかは多相にして、list-mapとかを設ける?
  • lazyness
    • 必要ないのに1,000要素を作る必要はない
    • util.generator:Pythonのジェネレータふう
      • まだ予告
  • 関数の探しやすさ
    • メタ情報の検索サブシステム
    • emacsで、勝手にuseを追加してくれる機能とか
  • パッケージング
    • ソースを出したくないというお客さんからのリクエスト
    • AOT(ahead of time compilation)
    • Cに変換してコンパイルしてDSOに
  • Q: 短くするメリットとデメリットがあるが
    • A: いろいろやってみて。lamdaを短くするのはみんなが得
  • Q: 多相型の高速化
    • A: キャッシュすると速くなるが、Gaucheでは難しい
  • Q: ^* の形式はemacsでS式単位の移動がめんどうそう
    • A: 短くすることとのトレードオフ
  • Q: R6RSはコアが大きくなって、Haskellやclojureにユーザーが流れた。これに対してどう思うか
    • A: もともと流れるほどのユーザーがいたのかどうか(笑)
    • GaucheもR6RS対応モードは設ける考え。すべて対応というわけではなく、モジュールにしたり
    • R6RSはひとつのオプションであり、R5RSもScheme
    • たいていはちょっといじれば動く。そんなことを考えるよりSchemeのコードを書こう

LT: Scheme on Ruby on Rails(Yuumi3)

 ここからLT。今回のLTはQ&Aありでした。

 一番手は、第2回でGauche on Railsを発表したYuumi3さん。今回は逆に、Ruby上でSchemeふうの記法でRuby on Railsの処理を書けるようにしたという新技でした。仕組みとしては文字列を処理してRubyのメタプログラミングとして処理しているそうです。マクロにも対応したいとか。

LT: WebブラウザをインターネットOSのシェルにしてGaucheと対話する(源馬照明)

 インスタントメッセンジャーのプロトコル「XMPP」経由で使えるGaucheのREPLボットを作った話です。最初はおとなしくPidginでデモしたのですが、次にFirefoxの拡張機能版のクライアントを使うとCOMETのチャットみたいになって、さらにbotからcanvasに描画するJavaScriptを返すように変更するとSchemeの式でブラウザに描画できる、という展開が面白かったセッションでした。

LT: 失敗したら会社終わるようなプロジェクトでLispを使ってみた(mitamex)

 第1回テクニカルトークで発表された、携帯Javaアプリに組み込むLispインタプリタ「l4u」のその後で、実際に半年仕事で使った様子がレポートされました。

 やってみてわかったこととして、開発環境やライブラリー、ドキュメントの整備がたいへんだったそうです。やっぱり製品自体を作りはじめたらそっちのほうにパワーをかけることになりますよね。ちなみに、第1回でこだわっていた「携帯端末のREPL」は、作ったものの、使われていないんだとか。

 現場ではLispっぽい書きかたはされていないそうで、JavaScriptっぽいプログラミングがされているそうです。そういう意味でもAlgolっぽい糖衣構文にしてよかったというのを「どんないいひとだって、初めて会ったとき素っ裸だったら走って逃げられる」という比喩で語っていました。括弧は全裸ですか(笑)

 あと、クライアントとサーバーの両方を作ったけど、サーバーに投入するのは難しくて、クライアントだけ使っているそうです。それに関連して、S式にJSONの皮をかぶせていたのが、結局クライアントで直接CSVやJSONに対応するようにしたそうです。

 ちなみに、とあるゲーム会社がl4uという商標をとっているため、名前を変更するかもという話でした。

LT: Emacs上での携帯絵文字の表示と入力補完(IMAKADO)

 カヤックの方で、お若いのに「うしろ指さされ組」のファンだそうです。

 「携帯サイトは絵文字が命」。だけど絵文字の入力には数値参照を使ったりして、テンプレートが見た目わけわからないことになりがち、というのが問題として語られました。

 そこでemoji.elを開発。バッファの中の数値参照を画像に置きかえて表示したり、読みから入力補完したりというのをデモして、会場からおおっという声が上がっていました。ちなみに、候補表示はanything.elを使っているそうです。

 | HOME | 

Categories

Recent Entries

Recent Comments

Recent Trackbacks

Appendix

emasaka

emasaka

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

Monthly


FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。