QCon2009 Tokyo - Ruby on Railsで変わるエンタープライズ開発の現場
Upcoming SlideShare
Loading in...5
×
 

QCon2009 Tokyo - Ruby on Railsで変わるエンタープライズ開発の現場

on

  • 2,175 views

The document of my speach in QCon 2009 Tokyo. Japanease only.

The document of my speach in QCon 2009 Tokyo. Japanease only.

Statistics

Views

Total Views
2,175
Views on SlideShare
2,074
Embed Views
101

Actions

Likes
3
Downloads
23
Comments
0

6 Embeds 101

http://ko.meadowy.net 96
http://static.slideshare.net 1
http://goas.no-ip.org 1
http://lifeast.net 1
https://twitter.com 1
http://s.deeeki.com 1

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • 捕捉すると、Railsでは後で述べるように少人数で開発することが多いので、15人というのはRailsを使うプロジェクトのなかでは大きいほうです。 <br /> <br /> <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • エンジニアが楽しいということには、お客さんを喜ばせることができるという点が含まれている <br /> 経営者にとってもいいこと <br /> そういう具合に、エンジニアが楽しいだけという話ではなくて <br /> いろいろつながっている <br /> <br />
  • リリースが早い <br /> 安く開発できる <br /> 変更につよい <br />
  • <br />
  • <br />
  • <br />
  • 型宣言なしは一例 <br /> <br /> 型を宣言するタイプの言語では、これからこの変数を文字列として使いますとか、定義してあげる必要があるし、型を変換することに意識をつかわないといけないけれどそのあたりをショートカットすることができる。 <br /> <br /> <br /> <br /> <br />
  • 逆に、コードを増やす要因として、堅い言語では、仕組みが堅固で、仕組みに沿った <br /> お作法でいろいろ書かないといけないということがある。 <br /> <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • Ruby もそうですが、Railsだとさらに <br />
  • DRYについては次に詳しく <br />
  • <br />
  • <br />
  • <br />
  • 1時間に4回、15分おきにしたとして、1日32回 <br /> 1回2分でも1時間使う計算になる <br /> <br />
  • 10年前に出た、プロジェクトの成功・失敗を人間の側の要因に光をあてて分析した本 <br /> <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • 安さの一つの理由として、少人数で開発するということがあります。 <br /> <br /> Railsでは少人数で開発することが多い。 <br /> それは、大人数に耐えられないというよりは、 <br /> 少人数でもうまくやれば大規模開発に匹敵するもの(Webアプリケーションという分野になるけど)が作れるから <br /> <br />
  • <br />
  • Railsそのものだけじゃなくて 楽しいだけじゃなくて <br /> Railsの生産性が生きるようなWhatの選択 作るアプリをいかにレールに載せるか <br /> <br /> <br />
  • Railsのコストパフォーマンスを追求するというのはどういうことかというと <br /> <br />
  • これを頭に入れて、作るアプリをレールに載せれば安く作ることに成功する <br />
  • <br />
  • 「全部盛り込んでしまわないと後から変更は大変だ」という意識がある <br /> これは後から変更するのが実際に大変なことがあるから <br /> しかし、変更できるならその考えを変えることができる <br /> <br /> システムの寿命が長くなればその分、総合的にコストを抑えることができる <br /> <br />
  • <br />
  • 柔軟 <br /> <br /> 読みやすい = DSL <br /> <br />
  • <br />
  • ここで半分 17:25 <br />
  • だから、進化がとても早い。Railsはホット。 <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • やわらかくかみくだく <br /> <br /> Convention over Configuration 明示的な設定がないときは規約を使う <br /> <br />
  • ある程度Rubyが読み書きできればRailsの動作を変更することは可能 <br /> 実は、フレームワークの制約で何かができなくなるといったリスクはとても低い <br /> <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • 楽しいということは、生産性があがり、良い仕事ができるということ <br />
  • 情熱をもって仕事ができるのはとてもいいこと <br /> <br />
  • <br />
  • <br />
  • <br />
  • 月間2.8億PV(2008年7月リニューアル) <br />
  • <br />
  • <br />
  • <br />
  • 感覚的にはこの2年くらいで増えてきている気がするが <br /> エンジニアが調達しにくいというのは依然あるとおもう <br /> Javaエンジニアを育てるとしたらすぐ書き始め、3ヶ月でほどほど、半年くらいで一人前かな <br /> 社内アプリなど育てる環境があるといい <br /> <br />
  • <br />
  • <br />
  • <br />
  • 例えばこだわりのU/Iとか <br /> どうしてもPDF生成が必要だとか <br /> <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • 密結合 <br /> テストとプロダクトコードの間でもいろいろ関連がある <br /> <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • 新しい考え方として、 <br /> ・Railsのレールに載せてアプリケーションを作る <br /> ・変更に強くしたり、バージョンアップについていったり <br /> ・名前大事、多様性 <br /> ・実際にRailsを使っている企業の現場ではこういうことが当たり前になってきている <br /> <br /> <br /> A)技術者としての夢 - すべてがDRYになって、やりたいことがいっぱいできるようになる <br />    煩わしい機械的作業から解放される <br />    でも花に水やるとか、やりたいことはやってかまわないけど <br /> B)Railsは普通にとても使える技術だし、どのくらい使うにせよ、体験して損のないものだと思います。RubyやRailsはコミュニティが活発で変化が早くホットなので、興味のある方はぜひいろいろなコミュティ活動に参加されるとよいと思います。 <br /> <br />

QCon2009 Tokyo - Ruby on Railsで変わるエンタープライズ開発の現場 QCon2009 Tokyo - Ruby on Railsで変わるエンタープライズ開発の現場 Presentation Transcript

  • Ruby on Railsで変わる エンタープライズ 開発の現場 株式会社万葉 大場寧子2009.4.9 QCon Tokyo 2009
  • Ruby on Rails✓知っている✓ 使ったことがある✓ 自社システム✓ 受託開発案件
  • 今日のテーマ Railsをエンタープライズで 普通に使う
  • Railsの採用•本当に使える?• メリット• リスク• 成功させるコツ
  • 自己紹介•大場寧子• Award on Rails 2006 大賞•株式会社万葉
  • 小槌アカウント間で連携する Web家計簿
  • Rails歴•2006∼2009• 15人くらいまでのチームで開発•SNS、旅行、EC、業務系など
  • 逆引きクイック リファレンス • RoR開発の実践逆引き辞典 • 毎日コミュニケーションズ • 532p •3675円
  • 2つの視点•経営者• プログラマ
  • ビジネス寄り•JavaからRubyへ• 元々軽量言語が好きだったわけではない
  • Railsは本当に 使える?
  • プログラマの主張Rubyは 楽しい
  • 警戒される楽しい = 怪しい
  • リスク
  • リスク•Ruby大丈夫?• エンジニア確保?• 楽しいだけじゃ困る
  • 楽しさとリスク•楽しくない言語Xに関するリスク•楽しい言語Yに関するリスク
  • 楽しさとリスクはあまり関係ない!
  • 楽しさの前に•楽しさは結果である• 結果には理由がある
  • 理由はつながっている
  • 経営者がRailsを使う3つの理由
  • 早いリリース•約束されている• 期待できる
  • 早いリリースの実現度 スキル & 成功ノウハウ 失敗 システムの規模・複雑さ
  • 早いリリースが 期待できる理由•コード量が少ない• コンパイルを待たない
  • コードが少ない•Rubyの特徴• 人間志向• 型宣言なし
  • Rubyは柔軟•壁を迂回しない• 本質を書くだけ
  • ある種の言語
  • 悲観的 性悪説高い堅牢な壁
  • Rubyの風景
  • 楽観的性善説 自由
  • Railsは少ないコードで 書ける
  • Railsとコード量•豊富な機能• 規約の活用• DRY
  • DRY•Don t RepeatYourself•同じことをあちこちに書かない
  • Ruby Rails• 打鍵数が少ない• 把握すべきコードの絶対的文字数が少ない• 時間的に有利!
  • コンパイルを 待たない•書いたコードがそのまま実行される•すぐ確認できる
  • コンパイルを 待つのは辛い•思考の中断• 待ち時間にほかのことを始める
  • 集中がとぎれる • フロー状態 • 中断されると、再開 に15分かかるTom DeMarco & Timothy Lister Peopleware - 2nd Edition Productive Projects and Teams
  • Rubyなら•最小限のコードで• 素早く確認しながら• 動くものが早く出来上がる
  • ビジネス価値•すばやく立ち上げる• プロトタイピング
  • 安く開発
  • 本当に?• ある程度YES
  • 安く開発の成功度 スキル & 成功ノウハウ 失敗 システムの規模・複雑さ
  • 少人数での開発 少人数でも 開発体制、手順と Railsの組み合わせで大規模開発に匹敵できる
  • 誤解Javaで作るのと同じように Rubyで作ったら安くなる
  • 安さの源 Ruby、Railsの生産性 Railsのコストパフォーマンスを追求 プログラマが楽しい 単価 ※注)脳内イメージです
  • Railsの生産性は、ある種の領域で高い
  • イメージ Railsの恩恵 コストよくある要件 完璧さ
  • 変更に強い
  • 変更に強いことの ビジネス価値•ニーズへの素早い対応• 小さく始めて育てる• システムの寿命を長く
  • 変更に強い理由•Ruby• Rails• 文化
  • Ruby•変更を阻害する壁が低い• 読みやすく書ける
  • Rails• DRY• どこに何が書いてあるべきか決まっている• DBの管理がしやすい
  • RDBのくびき からの解放
  • 文化•変更を嫌がらない• どんどん変える• 進化が早い
  • ただし特性を活かすか 殺すかで結果が変わる
  • ほかのメリット•環境構築が簡単• エンジニアが育つ• カスタマイズできる• 複雑なものを作るのに向く
  • 環境構築が簡単•フルスタック• DBツール、テストの仕組み、ログ、国際化etc
  • これだけ> rails MyApp
  • エンジニアが育つ Railsには 開発に関して良い とされる プラクティスが 詰め込まれている
  • Railsを学ぶと良いとされている開発の考え方を 同時に学べる
  • エッセンスの例•MVC• DRY, CoC• O/R Mapping• TDD, BDD
  • カスタマイズ フレームワークに 不満があれば 自分でカスタマイズ
  • 複雑なものを作るのに向く
  • 軽量言語の一般的イメージ•手軽• 簡単なもの向き• 複雑なものは無理
  • Rubyは•オブジェクト指向• 構造化しやすい• 複雑化に耐える
  • イメージコスト 複雑さ
  • メリットの1つ• プログラマが楽しい
  • ポール・グレアム素晴らしい仕事をするには、それをするのに無理をする必要がないほどに好きなことを何か見つければいいからだ。 「How to Do What You Love - 好きなことをやるには」 http://www.naochan.com/deprecated/2006/01/19/
  • 情熱
  • Rails のリスク
  • Railsのリスク•高負荷• 可用性• 速度
  • 工夫できる•分散• shared-nothing方式
  • COOKPAD
  • 頻繁なバージョン アップ
  • ついて行く?•作業が発生• 新しい不具合• 知識が固定化しない
  • 困る点•日本語の書籍や情報が追いつかない•プラグインが死亡するリスク
  • エンジニアの 調達
  • 認定試験•Ruby技術者認定試験• 2007年10月に開始
  • Rails活用のツボ
  • 取捨選択•80%達成で満足する• レールに乗る• こだわりは追求する
  • 戦略的な選択 Railsの恩恵 コストよくある要件 完璧さ
  • 開発手法• アジャイル• リズミカルに積み上げる• テスト駆動開発
  • レイヤーで担当者を分けない
  • レイヤーで分けると•設計する人•実装する人 •ビジネスロジックを書く人 •画面まわりを書く人•テストする人
  • せっかくRailsなのに
  • Railsでは•設計と実装が地続き• 行ったり来たりする• それが効率的
  • レイヤーごとに 分断するのは 大きなロス
  • どうするか• 機能で分担• 全員、設計からテストまで担当• すべて他人と共有
  • 開発体制の例•ペアで開発する• 4人くらいまでを1ユニットとして、ユニットを増やす•担当を固定化しない
  • 文化•良い名前をつける• コードをDRYにする• 多様性
  • 名前づけ•時間をかけてよい• 皆で決める• もっといい名前があったら変える
  • DRY•日常的に目指す• 2回目が重要
  • 多様性•強制はRubyの柔軟性・楽しさを殺す•方向を決め、やり方には多様性を持たせる
  • 変更しやすくする•DRY• 名前• 適切なところに書く• シンプルなほうを選ぶ
  • 変更しやすくする•適切な単体テスト• 変更を歓迎する文化• git, SVN等を使う
  • 変更しやすくする•リリース工程の自動化• 継続的インテグレーション• CruiseControl
  • リスクへの 目配り
  • パフォーマンス•セッションの使い方• キャッシュを意識する• ActiveRecord• 分散
  • 情報の入手•書籍• インターネット• 英語で調べる• コミュニティ参加
  • バージョンアップついていく
  • バージョンアップ•速くなる• コードが少なくなる• 最新の技術• 最新の考え方
  • ついていかないと•サポートされない• 新しいRailsやプラグインの生産性が得られない•技術力の相対的な低下
  • 問題は•バージョンアップすべきか?•バージョンアップするためにどうするか?
  • 準備する• 合意を作っておく• バージョンアップ作業を計画にいれておく• テストを書いておく
  • 覚悟する•いざとなったらRailsのコードを追う
  • まとめ•Ruby、Railsを企業で活用するには• 新しい考え方、スタイル• 始まっています