RubyKaigi2008 2nd Day

Ruby

引き続き二日目のメモ。
# 詳細なメモはきっといろんな方が公開すると思うので、 (^^;
# 発表者や IRC での発言で印象に残ってるものを自分用にメモしときます。

  • 朝、激しく早い...眠いっす
  • 雨雨
  • 「拡張ライブラリをつくるには Ruby のソースがわかっているのが前提」
    • マヨネーズ本
    • README.EXE、README.EXT.ja
    • RubyExtentionProgrammingGuide
    • RGC
    • ruby.h、intern.h、rubyio.h、...
  • ポインタの本は多いけど、コードリーディングやセキュアコーディングの本少ない、偏ってる
  • 拡張ライブラリでやること
    • アドレス操作、割り込み操作、ネイティブAPI
    • GC のビジュアル化のデモがよかった
  • RubyKaigiオリジナル曲
  • 「まあircのログは公開しないのがirc文化のような気はする。」
  • 「個人的にはインターネットでながしたモノはその時点ですでに公開されてると思うけど。」
  • 提案を受け入れてもらうには、「一貫性ではなく感性重要」
    • 名前重要
    • Perl でどう解決してるか重要
    • たくさんのひとが必要としてるか、明確な用途を書くこと
    • まともなサンプル重要
    • 「matzは日曜にメールを読まない -> 埋まる -> それっきり」
  • リファレンスマニュアル刷新計画、組み込み系は 97% のカバー率
    • Tk と soap を抜けば 標準添付で 50%
    • メソッド検索ができるようになった
    • Ruby言語仕様、デスマにまきこまれてるので書けない
      • 「ksh は Ruby に負けましたorz」
      • 「デスマーチは事故みたいなもの」
      • 水面下で交渉中
    • ライセンスは CC の表示/継承 を検討
    • 英語はいまのところまったく考えてないっす
  • 執筆原稿用の ReVIEW 公開されている
  • RubyCocoa 楽しそう
  • MacRuby!
    • 開発体制は Laurent ひとり、しかもフルタイムじゃない!？
    • キーワード引数
    • RubyCocoaより10倍早い
    • プロキシ用意してブリッジするのではなく、直接メッセージをおくれる
    • 「クリティカルなアプリケーションでもRubyCocoaが安心して使えるように」
    • GC機構がのってないので、iPhone アプリで Ruby をかくのはむずかしそう
    • RubyConf で MacRuby0.3 くるか
    • リッチキルマーと昨晩(初日の夜)かあ HotCocoa.rb つくったよ (手ぇ早いなぁ)
    • AppleScript のおきかえを狙う!
  • RESTful ウェブサービス、DHH 序文でバカ売れ
  • Resource Oriented Architecture
    • A:アドレス可能性、S:ステートレス性、C:接続性、U:統一インターフェース
    • 4つ守る必要はない (主観的重要度: A > C > U >>>>>> S)
    • 「URI は設計目標であって実装結果ではない」
    • (認証とか)セッションは今のままでいいっっす、レプリケーションもそこそこスケーラブルだし-- ステートレスにするには全部の情報が URL またはリクエストヘッダに乗ってなきゃいけない
  • CTC のRuby 普及事例
    • 「スーツ襲来!!」
    • 売上3192億、従業員6377
    • 2006年からRuby
    • Ruby関連で4.5億円の売上
    • まずはきちんと自社でRubyを位置付けましょう、経営レベルでのコンセンサス重要
      • 開発者が楽しい、生産性が高い (説得失敗)
      • 新規顧客、案件の獲得 (成功)
    • 会社のビジネスをひろげるのが Ruby (Java to Ruby ではなく、 Java + Ruby)
    • 体制つくった、教育体制や技術支援体制
    • とはいえ、現場おあちこちから色々なが疑問もでてくる
      • 営業向けの提案資料ってあるの?
      • 実績ってあるの?
      • 見積はファンクション法で (最初は Java と同じでそのうち実績ベースで)
      • 開発者はいるの?
      • 技術支援は?
      • 開発環境は?
      • Rubyなんて使っていいの? => 役員クラスにパトロンをみつけましょう
      • CTCと島根県の提携ってのがあるらしい、これでずいぶんBootしやすくなったとさ
  • Ruby は足元を撃つことはできる
    • でも顧客の機能要求を保証するのはテストでしょ
    • そこで品質を担保します
  • 必要なものはすべて膳立てしておく
    • 想像ではなく、データで回答する
    • きちんとビジネスと向き合う
  • 食べログの事例
  • mongrel の不可解な挙動に悩まされた
    • 4〜5日で8GB (1筐体あたり15プロセス)
    • 50MBで起動して2日で140MBくらいに育つ
    • 再起動シェルをcronで (実際にはほぼ毎日デプロイw)
    • mongrel が request をさばききれてなかったときにしれっと落ちる
      • ログにもなにも残らない、ソンビ化よりはマシだが原因究明できてない
    • ピーク時で秒間50アクセスを想定
    • 実際には平均0.2秒/リクエスト
  • AR は複数DB接続に未対応
    • 候補1: magic_multi_connections
      • テーブルの数だけコネクションを張ろうとする
      • 100プロセス*150テーブル => 没
    • 候補2: ActAsReadOnlyable
      • 実装方法がシンプルで採用
      • すべてのスレーブへ接続する (プロセス数=コネクション数)
      • フェイルオーバーしない
  • Rails の routes は使っていない
    • パフォーマンスも悪いらしい？ので、mod_rewrite + create_url
    • でもテスト書きづらくてメンテナンスコストも高い
    • routesとパフォーマンス比較したい
  • cache には memcached
  • 1:N の include はなるべく避ける、重ねると危険
  • セッションはDBに格納
  • 7000万PV/日でもふつーにやって運用できてる
    • Ruby、Rails も成熟していきている証拠
    • 「結局律速はネットとDBだからRubyでも大丈夫」
  • protected を private にしちゃうかも？
    • send で遅れば回避できるし
  • selector namespace
    • using xxx と書いたクラスだけで挙動を変えられるってのを検討中
    • プロセス全体が書きかわってしまうのは危険
    • でも予約語は増やしたくない
  • 「Matz は RubySpec を動かしたことがない」


準備から当日の運営(、そしてふりかえり)までいろいろ大変だと思いますが、毎年楽しく RubyKaigi を楽しませていただけるのも、スタッフの皆様のおかげです。
スタッフの皆様、ほんとにどうもありがとうございました。 <(_ _)>