日本Ruby会議2008 2nd day メインセッションAM1

後から書き直すのが面倒なので、講演を聞きながら取ったメモを直接載せておきます。時間帯別にエントリを分けました。

メインセッション 2008/6/22(日) 9:00-12:00

拡張ライブラリの書き方講座 (artonさん)

C言語によるRuby拡張ライブラリの書き方。速すぎてあまりついていけなかった。

  • Rubyのライブラリを書くには、Rubyソースコードを理解できる必要がある。
    • 一次情報: ruby.h, intern.h, rubyio.h, rubysig.h, version.h, st.h
  • 要求される技術
  • 作ったライブラリの配布
    • setup.rb (青木さん作)、gem, binary (MSI, apt, dmg)
  • デモ: extrails によるgemの作成
  • 何を拡張ライブラリで書くか?
    • ×テキスト処理、ネットワーク処理、ファイル操作
    • ○アドレス操作、割り込み操作、ネイティブAPI呼び出し
  • デモ: GCを可視化

さらに仕事に使うRuby (ごとけんさん)

  • 業務への活用事例
    • 開発案件に入る割り込みをどう処理するか?
  • 顧客との連絡ツール:Hiki
  • 案件管理ツール (内部用): Redmie
    • all-in-one: issue tracker, repository browser, wik, カレンダー
    • 安定した開発、分かりやすいUI、Webベースの管理、(Railsのサンプルとして)
    • 問題点: 日本語ファイル名がUTF-8である必要がある
  • 伝票管理: BTS影舞 Kagemai
    • 簡単で十分な機能、単純なワークフローに適合
  • イントラアプリ (RSS非対応) 向けRSSフィーダの自作

erbを偲んで(関将俊さん)

  • 代表作は <%=h %>
  • MVC原理主義者 vs. Webアプリ業界に流入した普通の人
  • GUIにおけるview
    • 最初は、コードの中に全部書く
    • 座標とか色とかかくのは面倒、異質なコードが入り込む
    • 部品の記述をコードを外へ → テンプレートと呼ぶ
    • 2つの世界: コードとテンプレート、独立しているが単体では存在できない
  • viewとは
    • テンプレートではなく、View Object
    • 実行環境+テンプレート
    • なぜ使う? → その方が楽だから/分業のためではない
  • ERB way
    • Rubyを文書に埋め込む
    • Rubyアプリの中に埋め込む

日本Ruby会議2008 2nd day メインセッションAM2

matzを説得する方法 (田中哲さん)
  • Ruby開発プロセス
    • 何かを提案→matzが受け入れる→提案した変更が採用される
    • Rubyを変えるためにはmatzを説得する必要
  • YARVの例: 実行速度
  • バグレポートは通りやすい
    • 明らかに変であること (SEGVなど)、再現可能な報告 (実行例)
  • 新機能・機能変更
    • バグレポートよりも難しい
    • 変更の動機は何か? 何が問題か?
  • 事例: スタックとレースの途中が省略される
    • MLに投げると、自分で表示するコードを提案
    • 受け入れられた理由: 省略の意図を尊重、設定がない、繰り返し話題が出ていることを指摘
    • 受け入れられなかった案: 設定 (クラスメソッド、コマンドラインオプション、.rubyrc)
  • 受け入れられやすい条件
    • 副作用がないこと、一般的な問題 (特定個人の問題でない) であること、他言語で採用されている、余計な変更を含まない、など
  • その他のノウハウ
    • 一貫性よりも便利であることが優先
    • 名前問題: 良い名前が決まらないために入らないこともある
    • 互換性問題: 短期的な互換性よりも長期的な利点が優先、ただし短期的な痛みの軽減も重要
    • 他言語でのアプローチを調査
日本Rubyのリファレンスマニュアル2008・初夏 (青木峰郎さん)

独習Java第4版

  • 執筆支援システムReVIEW (青木さん自作): 他の著者に使ってもらえた
  • リファレンスマニュアル刷新計画とは
    • より完全で便利なマニュアル
    • 2006/8スタート
  • 改善点
    • しっかりしたプロジェクト体制→うまくいっていない
    • 高品質なドキュメント、より厳密でメタデータを取りやすいファイルフォーマット
  • タイムライン
    • 2006/8 プロジェクト開始
    • 2007/1 メソッドエントリ完了
    • 2007/12/15 1.8.6マニュアルリリース
    • 2008/5/3 スナップショット #1 リリース
    • 2008/5/30 スナップショット #2 リリース
  • 現在のリリース
    • メソッドカバー率 31.2% 標準ライブラリ
    • tkとSOAP抜き: 52.0% (2007年 2%)
    • 組み込みライブラリ: 97.2% (1.8.7追加、1.9追加も含む)
  • RedMineによるITS導入
  • システム改善
    • Ruby言語仕様などが表示できるようになった
    • メソッド検索ができるようになった
  • 今後の予定
    • 2008/6 1.8.7対応マニュアルをリリース予定 組み込みライブラリ 100%を目指す
    • クラスリファレンス 2009Ruby会議までに100%を目指す (tk, SOAP以外)
    • 合宿でREXMLを撃破
    • Ruby言語仕様: 青木さん執筆予定→無理っぽい 水面下で交渉中
    • C APIリファレンス: プランなし
    • システム (BitClust): 静的HTML出力、新しいデザイン
    • ライセンス変更: (現在) 変な独自ライセンス → CCの「表示・継承」(Creative Commons Share-Alike License): 複数のMLに提案→一定期間放置→ライセンス変更実施
  • Q&Aから
    • ReVIEW: 青木さんSVNレポジトリでひっそり公開
    • 他言語版の扱い: 当面は各言語で独立して作成、BitClustの他言語対応は考慮されていない
The future of Ruby in Mac OS X (Laurent Sansonettiさん)

藤本さん (RubyCocoa作者)

  • MacOS Xに触り始める
  • Rubyは前から触っていた
    • irbを使ってメソッドの動作を確認
    • irbを使ってCocoa APIの動作を確認したい → NSObject を叩く拡張ライブラリを実装
    • ウィンドウが開けるように拡張
    • いろいろいじっているうちに、アプリが作れるまで機能拡張

中川さん (LimeChat on RubyCocoa作者)

Laurent

  • デモ
    • Interface BuilderによるGUI作成
    • Rubyでロジックを記述
  • RubyCocoaはどうやって動くのか?
    • Cocoaオブジェクト (NS*) に対応して、Rubyのプロキシオブジェクトを作成
    • プロキシオブジェクト−Cocoaオブジェクト間通信、プロキシ側での型変換
  • 問題点
    • プロキシによるメモリの浪費と遅いディスパッチ
    • マルチスレッド使用時に不安定
  • MacRuby

Q&Aから

  • iPhoneMacRubyは載るか?
  • MacRubyはいつMacOSに載るか? そうなると、RubyCocoaはフェードアウトするか?
    • 時期は分からない。RubyCocoaは存続する。]
  • MacRuby: Ruby 1.9の開発に追従するのは難しいのでは?
    • 2週間ごとに変更をマージしている。確かに手間が大きい。

日本Ruby会議2008 2nd day メインセッションPM1

REST信者から見たRuby and Rails (山本陽平さん)
  • RESTとRubyは仲良し
  • RESTとRailsも仲良し
    • RESTful Web Service: 原著では、表紙にDHHが登場
  • RESTとは
  • 抽象化レベル
  • ROAの構成要素
    • addressability, stateless, connectedness, uniform interface
    • 全部が均等に重要というわけではない A>C>U>>>>>>>>>S
    • 現実的には、cookieなどによりstatelessを守るのは困難なので、statelessにこだわる必要なし
  • Addressability
    • クライアントに対して見せたいデータがあるとき、それをリソースとして定義
    • リソースごとにURIを降る
    • URI駆動開発 URIの設計→URIの実装
    • Railsのルーティング: シンプルではあるが、コードの構造に依存しがち i.e. コードが変わると、URIも変わる
    • URIは設計目標であって実装結果ではない」
  • Connectedness
    • 現在のページ == アプリケーション状態/リンクをたどることによって、アプリケーション状態が遷移する
    • アプリケーション設計 == ハイパーメディア設計
    • Railsの場合: url_for, link_to - リンクの意味を意識できればベター → Web+DB Press 45参照
Real-World Enterprise Ruby (大場光一郎さん、高井直人さん)
  • CTCによるSIサービスで、Javaに加えてRubyを使用
  • エンタープライズ
  • エンタープライズRuby
    • 自社 (顧客企業) でRubyをどう位置づけるかが重要
  • どうやってRubyが会社の利益に貢献するのか
    • うまくいかなかった: 開発者が楽しい、生産性が高い
    • うまくいった: 新規顧客・案件の獲得
  • 推進体制
    • 教育/技術支援体制、開発標準 (SLCP2007)、運用/サポート体制
  • 営業現場や開発現場からの疑問
    • 営業資料をコピペで済むように用意
    • 実績ってあるの? → 開発メンバーが伊藤忠ウェブテクノロジーラボに武者修行
    • 見積もり → Javaと同じ手法/FP法で見積もり精度向上
    • 開発者っているの? → 教育体制の整備
    • 開発の技術支援 → コードレビュー
    • 開発環境 → NetBeans (本音ではEmacs使いたいけど…)
    • Rubyなんて訳分からないもの使っていいの? → 役員クラスの後援者を見つける
  • まとめ
    • 必要なものをお膳立て (例: 営業資料)
    • 疑問に対してデータで回答
    • きちんとビジネスに向き合う (例: どういう収益構造になっているのか?)

Q&Aから

  • 新規顧客の獲得: Rubyだから導入というお客さんはいたのか?
    • 小さいサイズの開発に対して、Javaでは受注できない→後で大きくなるかも
  • JRubyはどれだけ使っている?
  • スキルの低い技術者がいる場合の品質をどう確保するか?
    • 受け入れテスト

日本Ruby会議2008 2nd day メインセッションPM2

16:00から別の予定が入っているので、私のRubyKaigi2008参加メモはここで終了です。

Developing and scaling iKnow! (Zev Blutさん)
Inside Tabelog's Backend (京和崇行さん)
  • 食べログ
    • CGM型グルメサイト ユーザが口コミを投稿 → ランキング
    • Windows + ASPRailsにリニューアル
  • Mongrel
    • 問題: メモリ使用量 4-5日稼動すると8GB食いつぶす
    • 対策: 再起動用シェルスクリプトをcronで回す、アプリケーション改良
    • 基本的には安定/過負荷状態、メモリ不足のときに落ちることがある (プロセス消滅)
  • スケールアウト
    • セッション情報の共有 → Railsが標準でサポート
    • DBの分散アクセス対応
  • DB分散アクセス
    • Magic Multi-Connections: テーブルの数だけコネクションを張る→不採用
    • ActAsReadonlyable → 採用
  • Act〜 問題点
    • フェイルオーバー非対応

Q&Aから

  • 食べログの評価値はどのタイミングで計算しているのか?
    • 1日に1回バッチで計算。かなり複雑なクエリが走るので、その場で計算するのは負荷が高い。
  • 1日に1回Mongrelを再起動という話があったが、サービスの継続はどうやっているのか?
    • mongrelサーバを複数置いて、順次再起動をかけている。
ガラパゴスに線路を敷こう: 携帯電話用RailsプラグインJpmobile (しだらようじさん)
  • 携帯電話キャリアごとの非互換性
    • 携帯電話サービスの開発はバッドノウハウの宝庫
    • とは言え、捨てるには惜しい
    • Rails風にスッキリと開発できないか?→Jpmobile
  • スープカレー
  • Jpmobileの機能
    • 携帯電話のキャリア/機種の判別: そんなに単純には済まない
    • テンプレート切り替え: PC/モバイル、キャリアごと
      • 例: mytemplate_mobile_docomo.html.erb
    • GPSからの位置情報の取得 緯度、経度
    • 端末製造番号/契約者識別番号の取得 → 単独では信頼できないので、IPアドレス帯域との組み合わせで多少改善
    • IP帯域情報の取得
    • cookie取得: 対応していない機種の場合、セッションIDをURLなどに埋め込む必要あり
    • 画面情報 (画面サイズ、色数) 取得: HTTPレスポンスヘッダ or 機種名からテーブルlookup
    • 絵文字の相互変換: 文字集合エンコーディング 超複雑 近いうちに、PC上で絵文字を表示できるように拡張予定
  • お願い
    • 検証機の調達は不十分 → もし不具合を発見した場合は連絡plz