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

rubykaigi2008
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はどれだけ使っている？
  • スキルの低い技術者がいる場合の品質をどう確保するか？
    • 受け入れテスト