日本Ruby会議2009＠学術総合センター 2日目

ruby rubykaigi2009

2日目です。
まつもとゆきひろ氏の基調講演がありました。
感謝することが大切です。

Ruby 1.8 のゆくえ（卜部 昌平氏）

  • Ruby 1.8.6
    • MentorがKirk Hainesに変わった
    • セキュリティ、バグ、パフォーマンスについては、メンテしていく
    • 結構長くメンテするかも！？
  • Ruby 1.8.7
    • commitの約1/3がBug fix
    • メンテする優先度は、1)security、2)bug、3)Test fix、4)Document、5)Build System fixの順
  • Ruby 1.8.8
    • stable branch
    • 2008年にリリース予定でしたが、何とも・・・
    • これまで動いたコードは動く
    • 1.8の機能は一応の完成
    • 1.9移行時のギャップを少なくしたい
  • Ruby 1.8.9
    • ないです
    • 1.9へ移行しましょう

Ruby 1.9.2ロードマップ（Yugui氏）

  • Ruby 1.9.1 p243、回線の事情でリリースできず(セッション終了後、リリースするとのこと)
  • Ruby 1.9.2リリーススケジュール
  • Ruby 1.9.2の機能
    • Socketの変更
    • Timeの変更
    • BigDecimal+Rational
    • BOM
    • 1.9.2は機能的には地味。でも地味さから安定度を感じてほしい。
  • 1.9の未来
    • 使用するユーザ数で決まる。現状は、あまりライブラリが移植されていないので、ユーザが増えない。
    • 1.8との非互換はほとんどないので、使ってほしい。
  • 1.9は本当に使えるか？
    • Scriptingなら問題ない
    • Railsはダメ*1
  • 1.9.3
    • 1.9.2同様、地味です
  • 不満はPatchに変えて下さい

Ruby リファレンスマニュアル刷新計画 2009 夏（okkez氏）

Rubyist Magazine が出来るまで（ささだこういち氏）

  • 5年間続けられた事に、感謝している
  • 是非、読み返してほしい
  • るびま

基調講演(Ruby羅針盤) - まつもとゆきひろ氏

  • 我々はどこにいるのか？
    • 2009年日本、100年に1度の大不況 ->あまり実感ない
    • プログラミング黄金時代
      • 90年代のプログラミング環境 ->コンピュータパワーがない
      • 不遇な時代な言語 ->Lisp
      • Rubyも90年代は不遇だったが、現在はコンピュータパワーとプログラマの意識変化でRubyブーム
  • アイデンティティ
    • Ruby作者*2
    • 言語オタク
      • ありとあらゆる言語を愛している
    • プログラマ
      • プログラミングができる環境になった喜びは大きいし、その喜びは持続している
    • 文筆家
      • コードの世界
    • 更新しないブロガー
    • twitter(yukihiro_matz)
  • 我々はどこを向いているのか？
    • アティチュード
    • 感謝
      • 様々な賞の受賞 ->一人の受賞ではない
      • Ruby関係者への感謝
    • 酸っぱいブドウ
      • 自己正当化
      • 真実から目を背ける
      • Ruby(のコミュニティ)は、そのような態度は取らない。問題があるのに、放置しない。
    • 割れ窓(理論)
      • OSSは活きている事が魅力
      • 枯れたソフトウェアは面白くない(常に変化)
    • 責任
      • 言語はいろいろなことができると危ない？風潮
      • 信頼して、責任を与えた方が、パフォーマンスが良くなる ->責任が取れる範囲でパワーを与える
    • 原則
      • フェアである
      • 自己責任
      • 信頼する
    • Rubyのコミュニティは、正論が通じる
  • 開発環境
    • Emacs
    • Subversion
    • StGIT (Stacked GIT) like quilt written by python
      • VCS on top of Git
      • Patch Stacking
      • 未公開スタック(27スタック、ほとんど実験的)
  • まとめ
    • フェアである
      • 正論が届く、コミュニティ
    • 自己責任
      • Rubyは皆さんを信じている
    • 信頼する
    • 継続する
      • 皆さんのおかげで継続できた
    • 感謝
    • Rubyは良くなり続ける

Lightning Talks

  • Arduinoに興味あったので、もう少し見たかった
  • ギャルゲー、面白そう

The Samurai Ruby（小島 克俊氏）

  • この一年の状況
    • Cloudでハードウェアが売れない
    • 要素技術(Ruby)でもうけるのは大変
  • 社会・会社の情勢がどうあれ、やる気がある技術者が独自に実践している
    • 自分の技術力がよりどころ
  • そのようなエンジニアを認める仕組み
    • 資格制度
  • Rubyの生まれた町、松江市
    • まだ、鎖国してる
    • 男は甲冑
    • オフィスが城

Ruby,Railsによる「ケータイ」ポータルの作り方（成田 智也氏、浜中 慶氏）

  • ケータイサイトの特徴
    • 使用変更当たり前
      • 要件が増え続ける
    • 機種依存当たり前
      • 機種毎の細やかな対応
    • ターゲット層と使われ方
      • PCよりもピーク時間がバラバラ
      • ライフスタイルにあった利用
      • 手元にあるので、レスポンスが速い
    • スピード勝負
  • @niftyケータイポータル要件
    • 量産
    • 継続的なエンハンスが必須
    • メンバーの入れ替わりに柔軟に対応
  • 開発スタイル

実戦投入Rails - RubyKaigiEdition

WEB + DB PRESS Vol.51では、大人の事情で書けなかったこと。

  • プロジェクトは燃えているか？
    • クライアントとの定例が怒られに行くこと
    • 既存システムの複雑化
    • Railsの提案 ->実績は？最初は渋られた ->既存システムとRailsの共存 ->Railsのレールに乗せる
  • WEB + DBでは伝えられなかったこと
    • すべては健全なシステムのために
      • 作る事が目的ではなく、使い続けてもらうことが目的
    • 健全なシステムは、健全な人が作る ->プログラマの至福

Railsサイト安定運用の心構え ~8つのサービスから学ぶ（大井 宏友氏）

  • 以下の構成で、13VMsくらい稼働してます
    • Hardware
    • VM
      • 1G Memory
      • 10GB Disk space
      • 8CPU cores available
  • RubyとPerl/PHPではリソースの使い方が異なるので、同サーバで稼働している

CとRubyとその間（須藤 功平氏）

  • Ruby
    • メリット ->直感的、柔軟
    • デメリット ->高速に動かない
  • C
    • メリット ->高速に動く
    • デメリット ->直感的、柔軟ではない
  • Rubyのデメリットを補える
  • 全文検索エンジン「groonga(グルンガ)」
    • Cで実装

オープンソース開発をはじめよう（松村 章弘氏、黒田　雄一氏、諸橋 恭介氏）

  • OSSで開発する上での問題点
    • 場所の壁 ->コミュニケーション不足
      • SKIPで解決
    • 環境の壁 ->開発状況を把握できない
  • OSSにしてよかったこと(奇跡) ->大きな成果
    • 不具合報告
      • たくさんの視点からの不具合報告
    • パッチ
      • パッチを貰った ->開発パワーが上がった
    • セキュリティ報告
    • 国際化
    • 国際化して使いたいとのことで、パッチをもらった

Ruby による楽天の大規模サービスと基盤技術（後藤 幸生氏、西澤 無我氏）

  • Railsのパフォーマンス
    • CakePHPよりパフォーマンスが良かった
    • CPUの限界がRailsの限界だった
    • 中規模〜大規模でもいけると判断
    • CPU性能向上でスケールできるのではと判断
  • 開発時の課題と解決方法
    • サーバのメモリ量
    • アプリの使用メモリ
    • キャッシュの為、500MBが空き容量になるようにした
  • Railsに限らず、DBがボトルネック
    • テーブル分割
      • Modelに手を入れて吸収した
      • アプリにはテーブル分割を意識させない
    • KVSでキャッシュ
    • 運用
      • Apacheのログローテートと、Passengerの問題
  • ROMA ->RubyによるKVS
    • ROMA特徴
      • memcachedと互換プロトコル
      • スケールアウト可能
      • 障害耐性が高い ->冗長度を利用者が変更可能/自動Fail-Over etc...
      • プラグイン機構(リスト操作コマンド/非同期DB書き出し機能)
    • 導入予定事例
      • 閲覧履歴
      • セッション情報とか画像等
    • 今後
      • 社内で実績を出し、OSS化


日本Ruby会議2009

*1:yugui.jpはRailsだけど、まだ1.8系です

*2:寝坊して、名札忘れても会場に入れる