RubyKaigi2008 スペシャル★レポート

RubyKaigi2008 1st day Photoレポート[随時更新]

この記事を読むのに必要な時間:およそ 8 分

基調講演「プログラミング梁山泊」(まつもとゆきひろさん)

画像
画像

午後一に行われたまつもとゆきひろさんによる基調講演は,プログラミングの世界におけるコミュニティをテーマに行われました。

優れた人が集まる場所を「梁山泊(Sanctuary⁠⁠」と表し,Lispにメタプログラミングやマクロなどの先進的な機能が古くからあった背景には梁山泊があったことにある,と説明しました。そしてLispのコミュニティから,次のような梁山泊の定義を導き出しました。

  • 技術者が集まる
  • 新しい技術が生まれる
  • 世界が変わる

その最初の部分の動画です。

ニコニコ動画:https://www.nicovideo.jp/watch/sm3726490

仕事の道具として使われ技術よりも結果に関心があるFortranやCOBOL,Adaなどは梁山泊とは言えない,いろいろな側面から見るとUNIXやSmalltalk,Javaなども梁山泊の領域に入るとのことです。

そして,Rubyにも梁山泊ができつつあると述べました。RubyはLispからメタプログラミング,Smalltalkからはオブジェクト指向など過去の良い技術を継承しています。Rubyは使う人や使う楽しさに注目しています。生産性や変化にすばやく対応する俊敏性を重視しているため,Ruby on Railsのようなフレームワークが生まれました。現在,数多くのRuby実装が活発に開発されている要因の一つにRubyのポリシーである「多様性は善」が挙げられます。各実装の互換性を合わせるために仕様を統一するRubySpecプロジェクトも立ち上がっています。

また,セッションの途中で,技術フェローとして関わっている楽天技術研究所で現在進行中のプロジェクトが紹介されました。⁠ROMA」と呼ばれる大規模分散メモリストレージは,いわゆる分散ハッシュテーブルの一種で,ホットスケールやデータの冗長保存,フェイルオーバの機能を持っているようです。次に分散並列処理フレームワークである「fairy」が紹介され,分散grepの例をスライドアニメーションと疑似コードにて解説しました。fairyは開発当初,GoogleのMapReduceを想定していたようですが,MapReduceでは厳しい処理が多くあり,違う計算モデルを検討しているようです。現在は両方ともPure Rubyで実装しており,パフォーマンス面で問題が出てきたら一部C言語に置き換えることも検討しているようです。

質問コーナーにて,Matz日記の更新が停滞していることを指摘され「今日帰ったら更新します」と答えていましたが,今現在更新されていないところをみるとまつもとさんの中ではまだRuby会議は終わってないようです。

以下は,松本さんのセッションの後半部分から終わりまでの動画です。

ニコニコ動画:https://www.nicovideo.jp/watch/sm3726641

ニコニコ動画:https://www.nicovideo.jp/watch/sm3726943

※これらのセッションの動画は,後日,公式サイトにきちんとした動画が掲載される予定です。

Ruby M17N(成瀬ゆいささん,Martin J. Durstさん)

成瀬ゆいさんとMartin J. Durstさんによる,Ruby 1.9から導入されたMultilingualization(同時に複数の言語を扱えるようにすること)の発表です。一般的に採用されることが多いUCS Normalization方式ではなくCSI(Code Set Independent)方式を採用し,独自の変換モジュールを持っていることが特徴です。

Rubyは1.9より,Stringにエンコーディングを持ちます。UTF-8,Shift_JIS,EUC-JPなどのASCII互換のエンコーディングはすべてサポートしており,UTF-16や32などはBOM対応が困難で非対応です。また,ISO-2022-JPとUTF-7もDummy Encoding(Encoding#dummy?でtrueが返るエンコーディング)としてとらえ,対応していません。

サポートしているエンコーディングを調べるにはEncoding.listを使います。1.9ではシステム全体の内部コードは決定不可能なため$Kcodeは使えません。1.9より文字列に対してエンコーディングがつきますが,当時1つの文字を表すCharacterクラスが導入されるかどうかが議題に挙がったようです。しかし「文字は1つの文字列である」とし,Stringで表すこととしました。

Ruby 1.8と1.9ではStringや文字リテラルの挙動が変わっています。また,Ruby 1.9よりString#eachはなくなり代わりにeach_byte,each_char,each_lineを使うようになります。文字列同士を比較・結合する時には若干注意が必要で,比較では双方が同じエンコーディングでなければ等しいこととはみなされません。

Rubyコードを書くファイルにはファイルの先頭(shebangの下)「# -*- coding: UTF-8 -*-」というMagic Commentを書く必要があります。-Kオプションは1.9でも有効になりますが,Magic Commentが優先されます。

IO#openに関するサンプルコードをいくつか示した後,Martin氏によるtranscoding(文字コード変換)の説明に移りました。詳しい使い方はテストコードを見ればよいそうです。

ファイル名や関数名などはtranscodeというネーミングが使われていますが,メソッド名はまつもとさんの要望によりString#encodeになりました。

実装の説明はコードやデータ構造レベルにまで及びます。str_encodeまたはstr_encode_bang関数で文字列を受け取り,str_transcode関数でパラメータ解析を行います。そしてtranscode_dispatch関数でtranscoderを決定し,1バイトずつtranscode_loop関数にて処理していきます。

変換する際に一対一で対応していくと膨大な数になるため,Unicode(UTF-8)を変換ハブとして利用しています。1バイトずつ,1つのバイトごとに2つのテーブル「offsets」⁠infos」を利用します。テーブルを2つ持つことの利点として,以下が挙げられます。

  • 同じバイトでinfoをシェアできる
  • 似たようなエンコーディングの時にコード構造をシェアできる

最後に,次にやるべきこととしてテーブル入れ換え処理の見直し,より多くのエンコーディング対応,テーブル生成処理の見直しなどが挙げられ,セッションのまとめが行われました。

質疑応答では,以下に挙げた項目があがり,エンコーディングに対する関心の高さが伺えました。

Cygwin環境は?
A: Unix環境と同じように動くはず。
RDocでMagic Commentがそのまま出る
A: RDocを直せばいいじゃない。
「自動変換はサポートする?
A: 将来,指定出来るようにする。

ほかにも,正規表現のエンコーディングの扱いについて熱い議論がされていましたが,正直,全然ついていけませんでした(汗。非常に内容の濃い,難しいセッションでした。

画像
画像
画像

著者プロフィール

角田直行(かくだなおゆき)

普段はお仕事でPHPやJavaを使ってWeb開発をしています。一部でセレブエンジニアとか言われてますが,全然セレブじゃありません。