おがさわらなるひこのオープンソースとかプログラミングとか印刷技術とか

おがさわらなるひこ @naru0ga が技術系で興味を持ったりなんだりしたことをたまーに書くブログです。最近はてなダイアリー放置しすぎて記事書くたびにはてな記法忘れるのではてなブログに移行しました。

クリエイティブ・コモンズ・ライセンス
特に断りがない場合は、本ブログの筆者によるコンテンツは クリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスの下に提供されています。

関西オープンフォーラム 2008 2日目

前のエントリで書き損ねたのだけど、なんでKOFにある思いがあったかって言うと、「とにかく関西のコミュニティは熱い!」って話を聞いてたからのなのです。
関東のコミュニティは関西に比べると洗練されてるけど、熱さと言う意味では関西の方が……って話を聞いてたんで、じゃあ一度見に行ってみるか、ってことでね。

ということで前日の懇親会だけど、熱かったなぁ。
案外人見知りが激しいオイラはあんまりたくさんの人と話せなかったけど、この熱さはやみつきになりそうだね。


で、朝起きたら10時45分……なんじゃそりゃ。
目覚まし鳴らなかったんだよ。ちぇ。
しかし、幸いなことに午前中で聞きたいセッションはまるきり趣味の「 日本語プログラミング言語「なでしこ」で定型作業を自動化しよう!」 だけだったのでセーフ。
しかしなでしこのセミナーは OSC Tokyo/Fall 2008 でも体調不良で聞けなかったんだよね。呪われてるのか?


ということで昼まではブースを冷やかしてすごす。


なでしこのブースに行ってパンフをもらう。
前述のとおりセミナーを聞き逃した話をしたら「じゃあ本買ってくださいよ!」って言われちゃった。いや、面白そうなのはたまらなく面白そうなんだけど、ビジネスとは直結しないからなぁ。本買うまでのことは……(^^;)。


あとニコ動技術部の MZ-700アイマスムービーってのは激しくおかしかった。手ぶれしまくりだけどご容赦。


そのあとうぶんつなひとやでびあんなひとと話していたら、おっと、1時だ。

Ruby Lightning Talk

関西 Ruby の会の面々による「Ruby Lightning Talk」にちょい遅刻して参加。

途中から行ったので最初のいくつかは聞き逃したっぽい。
内容は:

Wii リモコンを Ruby でコントロール by ema さん
  • もちろん Pure Ruby ではかけないから C の拡張ライブラリで。
  • 何故に Ruby? ガワが Ruby の方がいろいろラクじゃん?
  • 注意点:加速度センサーは作用反作用の法則があるので振っても元に戻ってしまう。プログラミング上注意。

いやー、アホなことに使ってますねえ (褒めてます)。

男前 Ruby by よしだあつしさん
  • Ruby がいかに男前か訴え、女性ユーザに訴求する(そうか?)
  • 男前ポイント1. 素敵なメソッド名 Array#include? "?" 付きのあたりが超男前。
  • 男前ポイント2. 素敵なライブラリ名 例)"un" ruby -run touch hogehoge → 「走れ!」って感じで男らしい!
  • 男前ポイント3. Ruby は毅然としている 例) "1"+2 は例外
  • 男前ポイント4. Ruby は包容力がある 例)case 文は文字列なら比較だけど、正規表現なら match。

いやいや、強引な論法に笑わせていただきました。
会社の女の子に ruby 宣伝するときに使おう。

console on Rails by Nobuyuki Imai
  • irb の拡張でブロックとか複数文とか一気にヒストリで戻れるようにしたのがある
  • これを使って Rails の新機能を紹介

すんません、Rails よくわかんないんでピンとこなかったです。でも irb の拡張は便利そうだったなー。

Introducution of Lazy List (あ、Speaker の名前忘れちゃった)
  • Haskel 風の遅延リストを Ruby で実現したライブラリがあるのでこれでいろいろ遊ぼうって話
  • gem でインストール可能
  • map チェーンとかバシバシしてもパフォーマンス劣化しないのがうれしい

これは面白そうだ。あとで試してみたいな。

地方 SIer での Ruby 事情 by 吉川正晃@四国富士通さん
  • 主に情報系 Web アプリを手がける
  • 基幹系には厳しいが (Java)、情報系なら Ruby はお手頃
  • CRM とかも使うけど、大抵は cgi.rb ゴリゴリ
  • 最近ちょっと Rails とか使い始めた
  • 何で Ruby? →日本発なのでとっつきがよかった/erbが便利/tDiary のソースが勉強になった
  • 課題:昔のバージョンで構築した環境をどう保守していくか?

あんまり縁がない世界なので案外面白かった。
基本的には LL といいつつ時間に余裕があるので「あ、じゃあもうちょっと喋っていい?」とか温めの進行だったけど、それもまたよしか。

Google Chrome 完全技術解説

次は Google の及川さんによる「Google Chrome 完全技術解説」。さすがにほぼ満席の人気セミナーでした。

Why they're developing new Web browser?

「なぜ Google がブラウザ競争に参入したか」ということなのだけど、これは、

今ある最高の要素を取り入れたブラウザをゼロから開発できるとしたら?

というのが出発点だとのこと。
NCSA で Mosaic が開発された頃、誰も Web 2.0 なんてことは予想していなかった。
しかし今や、Google 社内では誰も Office アプリやグループウェアなど使っていない。すべて Web アプリ。そのインフラは JavaScript。さらに Dynamic HTML や Flash なんてのもある。
ということで、今の技術で Web ブラウザを作るって選択をしたと。

キーワードは二つあって、

  • Rediscover The Web (by Mozilla Project), but
  • Do Not Reinvent The Wheel

まあ当たり前のことではあるんだけど、最新の技術で今の Web 世界にふさわしいブラウザ、といっても、フルスクラッチで書くのは馬鹿げている。
だから使えるものは使おうと。

Google Chrome の機能面

Google Chrome についてはもう実際に使ってる人も Web 上にいっぱい記事もあるんで機能面についてはさらっと書くと、

  • アドレスバー一個で全部をまかなう
    • これまでの Web ブラウザは URI を入力する場所と検索バーとツールバーの入力画面と……とたくさんあった
    • どれ使っていいかわからんがな!
    • omni box: bookmark + 検索エンジン + 履歴 + ……
    • ソースがどれであるかをユーザに意識させない
    • ナビゲーションクエリ: ユーザは行きたいサイトを知っているが URL を知らない→こういう場合に適切なサイトを推奨してくれる機能
  • リッチなスタートページ
    • 「よく行くページ」をプレビュー付きで表示
    • あとはきっとみんな知ってるよね? ということで省略 ;-)
  • アプリケーションショートカット
    • Mozilla Prism といえば早いか?
  • クラッシュコントロール・タスクマネージャ
  • シークレットモード: 履歴とか残さないブラウズモード
  • セーフブラウジング: 各タブを SandBox に入れて安心安心
  • 高いパフォーマンス: レンダリングJavascript
Open プロジェクト
技術解説

主に Chromium からの引用なので、詳しくはそちらを参照のこと。


Chrome の内部構成は上図の通り (Chromium から似たような図を発見できなかったので手書きCreative Commons 的にフリーです)。

WebKit はご存じ Konqueror のがベースで AppleSafari を作るのに大幅に手を入れたやつ。
そのレンダリングエンジンだけもらって、グラフィックエンジンは自前の SGL というエンジンに入れ替えたと。SGL は Android などでも採用されている軽量高速なエンジンで、もちろんオープンソース

Javascript の高速化はもう最近の潮流とも言えますが (イコール、Web アプリの高速化だものね)、ここもフルスクラッチで V8 というエンジンを積んできたと。
ただし、Chromiumソースコードからビルドするときは、コンパイルオプションで V8 ではなくて WebKitJavascript エンジンを使うこともできるとか。これは主にデバッグ用途を意図しているようです。
もちろん V8 もオープンソースであります。

そして最近のマルチコア、マルチプロセスの流れに従った内部構造。
http://dev.chromium.org/developers/design-documents/multi-process-architecture/arch.png
(see Multi-process Architecture on Chromium Developer Document)

メインプロセスには I/O スレッドとブラウザ (各タブを統括するもの) がいて、タブが一個
起きるごとにタブ内のレンダリングをするプロセスが起きると。当然プロセスなので IPC が走るんだけど、Windows の場合は COM なんだそうで。
そいでレンダリングプロセスは特権なしで動作するので、Javascript エンジンとかバグっててもプロセス一個殺せばすむ。他のプロセスには影響を与えない。
プロセスが別々だからマルチコアの恩恵が最大限に生かされる。と、まあいいことづくめ。
もちろんメモリ食うって欠点はあるけどね。

ちなみにプラグインはどうなってるかっていうと、
http://dev.chromium.org/developers/design-documents/plugin-architecture/pluginsoutofprocess.png
(see Plugin Architecture on Chromium Developer Document)
こんな感じで、プロセスを完全に分けてるんだそうな。


プラグインというのはいろいろ地雷なので、プロセス分けて IPC で遮断するというのはまあすぐ思いつくとはいえ、パフォーマンスとの兼ね合いもあるからめんどうなんだろうね。

Chromium.org に加入しよう

Chromium というのは Google Chrome の開発プロジェクトというだけではなく、Chrome からライセンシーの非オープンなソースを覗いた別のブラウザでもあるらしいです。
もちろんエンジンや内部構造は Chrome そのものなので、Chromium の開発 ~= Chrome の開発なわけだけど。

そんなわけで Chromium.org には以下のコンテンツが用意されてるそうです。

  • ソースコード (前述のようにライセンシーが権利を持ってるソース以外)
  • 技術文書 (ビルドの仕方から内部構造まで)
  • フォーラム
  • BTS

...

特にフォーラムについては英語以外で唯一日本語のフォーラムが用意されているし、Google の日本人も見ているのでバグ報告などをどんどんあげてほしいとのことです。

また Chrome の普通のリリースは BETA ですが、Dev Channel というリリース形態もあって、これは Weekly Build をぽんぽん出すようなもので、ちょっとのバグの可能性には目をつぶってどんどんアップデートしたい人向き。

さらに Cutting Edge な人は Git で trunk 取ってビルドも可能です。
Windows 版は Visual Studio 2005 でないとビルドできないそうですが (WebKit 側の問題らしい)、ビルドしてしまえばデバッガで遊んだりいろいろできるので面白いですね。


ということで、なかなか面白いプレゼンでした。
残念ながら現行の Chrome はまだ若干不安定ですが、コンセプト自体はよいものがあるので、安定度を上げてのリリースが望まれますね。
また Linux 版を壱からビルドするのはめんどくさいので rpmdeb で早くリリースされないかなって思ってます。

KOF ツアー

お次は「オープンソースはプロレスだ!」を標榜する法林さんがガイドを務める、KOF ウォーキングツアー。

ま、一回参加すればいいかな、って気がする。
法林さんのトークは好きなので、今回は後悔はしてないけど。

ステージ企画:「Ubuntu 8.10ほかもろもろ」&「2008/09 リリース予定 Debian 5.0 "Lenny" について」

うかつに「Ubuntu/Debian 対決」って書いたらやまねさんに速攻で突っ込まれた

Ubuntu の水野さんのプレゼンも興味深かったけど、プレゼンとしてはやまねさんの方が面白かった。
「対決」って言葉を使った責任として采配を勝手に振ると、Ubuntu の方が確かに集客力は上だったけど、おもしろさという意味では Debian の方が上ということで、引き分け! (ううむ、実に日本人らしい日和見だ)。

Ruby 1.9 の話

最後は Yugui さんの Ruby 1.9 解説。
Yugui さんちょーかっこえー。まさに理想のリリースマネージャ。管理される方は大変かもしれないけど、まさにマネージメントかくあるべしだと思った。

などという雑感はともかく、プレゼンの内容をサラッと紹介。

Ruby 1.9 とはそもそも何か?
  • Ruby の次のメジャーバージョンアップであり、
  • 理想 (Ideal) の Ruby を目指す 2.0 に対する踏み台 (Step) である。

特徴としては以下のとおり。

  • VM の導入
  • ネイティブスレッドとファイバの導入
  • Multilingualization
  • 文法の見直し
  • ライブラリの整備、Gems の標準化

では一つ一つ見ていきましょう。

VM
  • 元々 YARV (やるぶ: Yet Another Ruby VM) と言っていたのだけど、本家に取り込まれたので止めよう……といいつつ、定着しちゃったのでたぶんこのまま*1
  • 実行スピードは約5倍*2
  • バイトコードレベルコンパチビリティを持つ。つまり x86バイトコードPPC 版に持っていったりしても動く。
  • ということは技術的には .class みたいなこと (= バイトコードコンパイルまではすませておいて、バイナリ配布) みたいなことは可能である (が、作ってる側の関心は薄そう)。
Native Thread
  • 衆知のとおり Ruby 1.8 までのスレッドはユーザレベルスレッド (つまり Ruby 処理系の中で一生懸命処理してた) だったが、1.9 からは OS の提供しているスレッド機能を使うようになった。
  • おかげでコンテクストスイッチが (OS 任せになったので) 高速化。
  • しかし欠点もあるので注意。
    • ネイティブスレッドはカーネルオブジェクトなので生成が重い。
    • 同じくカーネルオブジェクトなので数に制約がある。今までユーザーレベルスレッドだったので気軽にバンバン作ってたようなソフトがあるが、そういうのは移植に気をつけないとダメかも。
  • あとマルチコアでの実行はサポートしてない。一つのコアが動いてるときには他のコアを明示的に止めてる。
Fiber *3
  • ユーザレベルスレッドからコンテクストスイッチを取ったもの
  • だから気軽に生成して気軽に使えるけど、スイッチングは自前
M17N
# -*- coding: euc-jp -*-
文法の改訂

あんま細かいこと覚えてないのだけど、Block まわりの文法が複雑だったのが簡素化されてわかりやすくなったとかなんとか。

Rails との関係
  • たぶん速くなるとは思う。
  • まだ構想段階だけど、Rails みたいな規模が大きいシステムには Multi VM なんてのが効くんじゃないかって議論がある。
  • ただし YARV は eval が重いので、eval の山 (不要な所でも eval しまくり) の RailsYARV の効果と相殺になってしまうかも
  • 互換性については、そもそも今の Rails は 1.9 では動かない。
    • 主に Rails 自体が String クラスを大幅に拡張していることが 1.9 とのバッティングを起こしている
    • ただし Rails の開発チームは開発力があるので、1.9 が stable になったらすぐ追いついてくるだろう
Release Schedule
1.9.1 preview 2
2008-11-25
1.9.1 RC
2008-12-25
1.9.1 final
2009-1-25

RC と final が一月開いているのはクールダウンフェーズということだそうな。

Release Management

そもそも Yugui さんはリリースマネージャということだけど、そもそも Ruby におけるリリースマネージャとは?

  • 1.8.x の初期のころまではリリースマネージメントなんて存在しなかった
  • のでリリース予定近くになっても機能突っ込む奴とかいてグダグダ
  • 武藤さんキレる
  • ルール整備
  • それを改善しつつ踏襲して 1.9 のマネージメントルールを Yugui さんが決め今に至る

とかいってたような (なぜか手元にメモがない)。
今のリリースマネジメントはこんな感じらしい。

  • Support Level の明確化 (1.9 新規)
    • 環境によってサポートレベルを明確にする
    • 今は以下の5種類
Supported
メンテナが存在し、Daily Build の環境もあって、すべての機能が確実に動くことが保証された環境。現状 Debian i386 のみ。
Best Effort
メンテナが存在し、Daily Build の環境もあるが、一部機能に制約が存在するなど問題がある環境。Win32FreeBSD など。
Perhaps
Ruby プロジェクトとしては公式にサポートしていないが、多分動くだろう、という環境。Mac OS X や、Debian 以外の Linux など。
Not Supported
文字通り。OS/2 とか MS-DOS とか?
  • メンテナーのアサイン
  • Feature Freeze
    • あるバージョンの新機能入れ込みに締切りを設けること
    • ていうか 1.8.x の初期には決まってなかったらしい。そりゃ切れるわ。
  • Cool down phase (1.9 から導入)
    • RC を出してからしばらく寝かせること。バグ報告待ちだったりなんだたり。
  • issue tracker
Migration について

HowTo としては:

  • Magic Comment でエンコーディングを明記する
    • 1.8 でも無害だから今のうちやっておきませう
  • Block の文法変更に伴って手直し必要かも
  • 文字列のエンコーディング違いで例外吐かれるかもしれないけど、それは潜在的に文字化けを起こしかねないソースだったんで、諦めて直そう

適切な時期は?

  • Yugui さん曰く:

今の preview1 でショッピングサイトとか使ったら、たぶん私は使います。でもインターネットバンキングで1秒で億のお金が動くようなシステムを作るのは進められません。そういう品質だと思ってください。
普通には十分使えるレベルになっていると思います。

  • Rails な人は Rails の対応を待ちましょう
  • ライブラリ作者は一刻も早く対応を開始し、1.9 対応のライブラリをリリースしましょう
Q&A
Q
サポートライフは? とくに 1.8 系が心配。
A
1.8 系も次のバージョンが出ることは確定しているし、しばらくは続くと思う。
Q
1.8 と 1.9 で両方で動くソースを書くことはできるか?
A
iconv, kconv は互換のために残されているので、これでエンコーディングをうまく書いてやるしかないのでは。
Q
サポートライフを Ruby プロジェクトとして決めるつもりはないのか。多くの Linux ディストリビューションプロジェクトの様に。
A
今はまだ Ruby コミュニティにそこまでの余力がない。そういうものがあったらよいとは思う。
Q
マルチ VM って何がおいしいのか。プロセスが分かれて CPU のコアが活用できるということは分かるが。
A
まだ構想段階でありはっきりとしたことはいえない。1.9 のどこかで Selector Namespace の導入を検討しており、それとの組み合わせで機能提供されるのではないか。もちろん VM 間で情報のやりとりをするようなしくみは用意されるだろう。
Q
1.8→1.9 コンバータみたいなものは作れないのか?
A
Magic Comment で救えないものについては、何が正しいかを機械的に判断するのはムリ。

いやー、おもしろかった。
これにて KOF 2008 の全プログラムは終了。

Debian/Ubuntu 懇親会

そのあとなぜか、Ubuntu はタダのユーザだし、Debian にいたってはテスト環境を構築するぐらいのことしかしてないのに懇親会になだれ込む。
非常に面白かった。とりあえず「KDE の K は『北』の K」は笑った。
クルマなので飲めなかったのが少々残念。


まあとにかく、来年も必ずこようと誓ったのであった。
が、自走で行くかどうかは悩むところだ (^^;)
行きも帰りも眠くて眠くて、死ぬかと思ったからな。

でも次の日はこんなところで遊んでたから、ボート持っていって正解か?

2008.11.23 7:32 やっとタイトルから(仮)が取れましたよ。ふー。

*1:関係ないけど YARV のささださんはオイラの出身研究室の隣の研究室出身で、YARV は元々卒研テーマだったんじゃなかったかな?

*2:でも OSC/Fall Tokyo 2008 で聞いた限りでは、M17N で速度を食われてしまうのでそこまでは早くならないので、チューニングとして文字列が ASCII だったら M17N をバイパスするとかしてるらしい。

*3:ちょっと前から NT 系 OS にも入ってるから知ってる人は知ってるよね

*4:オイラはこれを Ruby の一つの見識だと思っていて、エンコーディングの自動変換をすると FULLWIDTHTILDE / WAVEDASH 問題みたいなのにハマるから、変換はしたい人がプリプロセスなりポストプロセスで好きなようにやってくれ、そのための道具立ては準備するから、気に入らなかったら手を入れてくれ、ってのは正しい姿勢だなって思ってたんで、これも OSC/Fall Tokyo 2008 で聞いてみたら、「それだと非 CJK 圏の人が作った人間で日本語が通らないとかいうことになりうる。実際問題になっている」とのことで、ちょっと納得した。