前のエントリで書き損ねたのだけど、なんで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
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 上にいっぱい記事もあるんで機能面についてはさらっと書くと、
- アドレスバー一個で全部をまかなう
- リッチなスタートページ
- 「よく行くページ」をプレビュー付きで表示
- あとはきっとみんな知ってるよね? ということで省略 ;-)
- アプリケーションショートカット
- Mozilla Prism といえば早いか?
- クラッシュコントロール・タスクマネージャ
- シークレットモード: 履歴とか残さないブラウズモード
- セーフブラウジング: 各タブを SandBox に入れて安心安心
- 高いパフォーマンス: レンダリング&Javascript
Open プロジェクト
技術解説
主に Chromium からの引用なので、詳しくはそちらを参照のこと。
Chrome の内部構成は上図の通り (Chromium から似たような図を発見できなかったので手書き。Creative Commons 的にフリーです)。
WebKit はご存じ Konqueror のがベースで Apple が Safari を作るのに大幅に手を入れたやつ。
そのレンダリングエンジンだけもらって、グラフィックエンジンは自前の SGL というエンジンに入れ替えたと。SGL は Android などでも採用されている軽量高速なエンジンで、もちろんオープンソース。
Javascript の高速化はもう最近の潮流とも言えますが (イコール、Web アプリの高速化だものね)、ここもフルスクラッチで V8 というエンジンを積んできたと。
ただし、Chromium をソースコードからビルドするときは、コンパイルオプションで V8 ではなくて WebKit の Javascript エンジンを使うこともできるとか。これは主にデバッグ用途を意図しているようです。
もちろん V8 もオープンソースであります。
そして最近のマルチコア、マルチプロセスの流れに従った内部構造。
(see Multi-process Architecture on Chromium Developer Document)
メインプロセスには I/O スレッドとブラウザ (各タブを統括するもの) がいて、タブが一個
起きるごとにタブ内のレンダリングをするプロセスが起きると。当然プロセスなので IPC が走るんだけど、Windows の場合は COM なんだそうで。
そいでレンダリングプロセスは特権なしで動作するので、Javascript エンジンとかバグっててもプロセス一個殺せばすむ。他のプロセスには影響を与えない。
プロセスが別々だからマルチコアの恩恵が最大限に生かされる。と、まあいいことづくめ。
もちろんメモリ食うって欠点はあるけどね。
ちなみにプラグインはどうなってるかっていうと、
(see Plugin Architecture on Chromium Developer Document)
こんな感じで、プロセスを完全に分けてるんだそうな。
プラグインというのはいろいろ地雷なので、プロセス分けて IPC で遮断するというのはまあすぐ思いつくとはいえ、パフォーマンスとの兼ね合いもあるからめんどうなんだろうね。
Chromium.org に加入しよう
Chromium というのは Google Chrome の開発プロジェクトというだけではなく、Chrome からライセンシーの非オープンなソースを覗いた別のブラウザでもあるらしいです。
もちろんエンジンや内部構造は Chrome そのものなので、Chromium の開発 ~= Chrome の開発なわけだけど。
そんなわけで Chromium.org には以下のコンテンツが用意されてるそうです。
...
特にフォーラムについては英語以外で唯一日本語のフォーラムが用意されているし、Google の日本人も見ているのでバグ報告などをどんどんあげてほしいとのことです。
また Chrome の普通のリリースは BETA ですが、Dev Channel というリリース形態もあって、これは Weekly Build をぽんぽん出すようなもので、ちょっとのバグの可能性には目をつぶってどんどんアップデートしたい人向き。
さらに Cutting Edge な人は Git で trunk 取ってビルドも可能です。
Windows 版は Visual Studio 2005 でないとビルドできないそうですが (WebKit 側の問題らしい)、ビルドしてしまえばデバッガで遊んだりいろいろできるので面白いですね。
ということで、なかなか面白いプレゼンでした。
残念ながら現行の Chrome はまだ若干不安定ですが、コンセプト自体はよいものがあるので、安定度を上げてのリリースが望まれますね。
また Linux 版を壱からビルドするのはめんどくさいので rpm と deb で早くリリースされないかなって思ってます。
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 とはそもそも何か?
特徴としては以下のとおり。
- VM の導入
- ネイティブスレッドとファイバの導入
- Multilingualization
- 文法の見直し
- ライブラリの整備、Gems の標準化
では一つ一つ見ていきましょう。
Native Thread
Fiber *3
- ユーザレベルスレッドからコンテクストスイッチを取ったもの
- だから気軽に生成して気軽に使えるけど、スイッチングは自前
M17N
- 1.8 までの Ruby は String クラスはただのバイト列だった *4
- 1.9 では String クラスは明確に文字列を意味している
- I/O でも内部エンコーディング・外部エンコーディングをサポートできるようになった
- エンコーディングのデフォルトは起動時のコマンドラインやロケールで決まる
- ソースコード自身のエンコーディングはマジックコメントで指定。こんな感じ。
# -*- coding: euc-jp -*-
文法の改訂
あんま細かいこと覚えてないのだけど、Block まわりの文法が複雑だったのが簡素化されてわかりやすくなったとかなんとか。
Rails との関係
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種類
Migration について
HowTo としては:
- Magic Comment でエンコーディングを明記する
- 1.8 でも無害だから今のうちやっておきませう
- Block の文法変更に伴って手直し必要かも
- 文字列のエンコーディング違いで例外吐かれるかもしれないけど、それは潜在的に文字化けを起こしかねないソースだったんで、諦めて直そう
適切な時期は?
- Yugui さん曰く:
今の preview1 でショッピングサイトとか使ったら、たぶん私は使います。でもインターネットバンキングで1秒で億のお金が動くようなシステムを作るのは進められません。そういう品質だと思ってください。
普通には十分使えるレベルになっていると思います。
Q&A
- Q
- サポートライフは? とくに 1.8 系が心配。
- A
- 1.8 系も次のバージョンが出ることは確定しているし、しばらくは続くと思う。
- 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 圏の人が作った人間で日本語が通らないとかいうことになりうる。実際問題になっている」とのことで、ちょっと納得した。