QCon2009 Tokyo - Ruby on Railsで変わるエンタープライズ開発の現場
•Télécharger en tant que KEY, PDF•
3 j'aime•1,825 vues
The document of my speach in QCon 2009 Tokyo. Japanease only.
Recommandé
Contenu connexe
Tendances
Tendances (16)
En vedette
En vedette (20)
Similaire à QCon2009 Tokyo - Ruby on Railsで変わるエンタープライズ開発の現場
Similaire à QCon2009 Tokyo - Ruby on Railsで変わるエンタープライズ開発の現場 (20)
Plus de Yasuko Ohba
Plus de Yasuko Ohba (14)
Dernier
Dernier (9)
QCon2009 Tokyo - Ruby on Railsで変わるエンタープライズ開発の現場
- 1. Ruby on Railsで変わる エンタープライズ 開発の現場 株式会社万葉 大場寧子 2009.4.9 QCon Tokyo 2009
- 2. Ruby on Rails ✓知っている ✓ 使ったことがある ✓ 自社システム ✓ 受託開発案件
- 3. 今日のテーマ Railsを エンタープライズで 普通に使う
- 4. Railsの採用 •本当に使える？ • メリット • リスク • 成功させるコツ
- 5. 自己紹介 •大場寧子 • Award on Rails 2006 大賞 •株式会社万葉
- 6. 小槌 アカウント間で連携する Web家計簿
- 8. 逆引きクイック リファレンス • RoR開発の実践逆引き辞典 • 毎日コミュニケーションズ • 532p •3675円
- 11. Railsは本当に 使える？
- 13. 警戒される 楽しい = 怪しい
- 14. リスク
- 19. 理由は つながっている
- 22. 早いリリースの実現度 スキル ＆ 成功 ノウハウ 失敗 システムの規模・複雑さ
- 23. 早いリリースが 期待できる理由 •コード量が少ない • コンパイルを待たない
- 26. ある種の言語
- 27. 悲観的 性悪説 高い堅牢な壁
- 28. Rubyの風景
- 29. 楽観的 性善説 自由
- 33. Ruby Rails • 打鍵数が少ない • 把握すべきコードの絶 対的文字数が少ない • 時間的に有利！
- 34. コンパイルを 待たない • 書いたコードがそ のまま実行される •すぐ確認できる
- 36. 集中がとぎれる • フロー状態 • 中断されると、再開 に15分かかる Tom DeMarco & Timothy Lister Peopleware - 2nd Edition Productive Projects and Teams
- 39. 安く開発
- 40. 本当に？ • ある程度YES
- 41. 安く開発の成功度 スキル ＆ 成功 ノウハウ 失敗 システムの規模・複雑さ
- 42. 少人数での開発 少人数でも 開発体制、手順と Railsの組み合わせで 大規模開発に匹敵できる
- 44. 安さの源 Ruby、Railsの生産性 Railsのコストパフォーマンスを追求 プログラマが楽しい 単価 ※注）脳内イメージです
- 46. イメージ Railsの恩恵 コスト よくある要件 完璧さ
- 47. 変更に強い
- 48. 変更に強いことの ビジネス価値 •ニーズへの素早い対応 • 小さく始めて育てる • システムの寿命を長く
- 50. Ruby • 変更を阻害する壁が 低い • 読みやすく書ける
- 51. Rails • DRY • どこに何が書いてある べきか決まっている • DBの管理がしやすい
- 52. RDBのくびき からの解放
- 55. ほかのメリット •環境構築が簡単 • エンジニアが育つ • カスタマイズできる • 複雑なものを作るのに向く
- 58. エンジニアが育つ Railsには 開発に関して良い とされる プラクティスが 詰め込まれている
- 60. エッセンスの例 •MVC • DRY, CoC • O/R Mapping • TDD, BDD
- 61. カスタマイズ フレームワークに 不満があれば 自分でカスタマイズ
- 62. 複雑なものを 作るのに向く
- 65. イメージ コスト 複雑さ
- 66. メリットの１つ • プログラマが楽しい
- 67. ポール・グレアム 素晴らしい仕事をするには、それをするのに 無理をする必要がないほどに好きなことを何 か見つければいいからだ。 「How to Do What You Love - 好きなことをやるには」 http://www.naochan.com/deprecated/2006/01/19/
- 68. 情熱
- 69. Rails のリスク
- 72. COOKPAD
- 73. 頻繁な バージョン アップ
- 76. エンジニアの 調達
- 78. Rails活用のツボ
- 80. 戦略的な選択 Railsの恩恵 コスト よくある要件 完璧さ
- 81. 開発手法 • アジャイル • リズミカルに積み上 げる • テスト駆動開発
- 82. レイヤーで 担当者を分けない
- 84. せっかく Railsなのに
- 86. レイヤーごとに 分断するのは 大きなロス
- 87. どうするか • 機能で分担 • 全員、設計からテスト まで担当 • すべて他人と共有
- 93. 変更しやすくする •DRY • 名前 • 適切なところに書く • シンプルなほうを選ぶ
- 94. 変更しやすくする •適切な単体テスト • 変更を歓迎する文化 • git, SVN等を使う
- 95. 変更しやすくする •リリース工程の自動化 • 継続的インテグレー ション • CruiseControl
- 96. リスクへの 目配り
- 98. 情報の入手 •書籍 • インターネット • 英語で調べる • コミュニティ参加
- 99. バージョンアップ ついていく
- 100. バージョンアップ •速くなる • コードが少なくなる • 最新の技術 • 最新の考え方
- 103. 準備する • 合意を作っておく • バージョンアップ作 業を計画にいれておく • テストを書いておく
- 105. まとめ • Ruby、Railsを企業で 活用するには • 新しい考え方、スタイル • 始まっています
Notes de l'éditeur
- 捕捉すると、Railsでは後で述べるように少人数で開発することが多いので、15人というのはRailsを使うプロジェクトのなかでは大きいほうです。
- エンジニアが楽しいということには、お客さんを喜ばせることができるという点が含まれている 経営者にとってもいいこと そういう具合に、エンジニアが楽しいだけという話ではなくて いろいろつながっている
- リリースが早い 安く開発できる 変更につよい
- 型宣言なしは一例 型を宣言するタイプの言語では、これからこの変数を文字列として使いますとか、定義してあげる必要があるし、型を変換することに意識をつかわないといけないけれどそのあたりをショートカットすることができる。
- 逆に、コードを増やす要因として、堅い言語では、仕組みが堅固で、仕組みに沿った お作法でいろいろ書かないといけないということがある。
- Ruby もそうですが、Railsだとさらに
- DRYについては次に詳しく
- １時間に４回、１５分おきにしたとして、１日３２回 １回２分でも１時間使う計算になる
- 10年前に出た、プロジェクトの成功・失敗を人間の側の要因に光をあてて分析した本
- 安さの一つの理由として、少人数で開発するということがあります。 Railsでは少人数で開発することが多い。 それは、大人数に耐えられないというよりは、 少人数でもうまくやれば大規模開発に匹敵するもの（Webアプリケーションという分野になるけど）が作れるから
- Railsそのものだけじゃなくて　楽しいだけじゃなくて Railsの生産性が生きるようなWhatの選択　作るアプリをいかにレールに載せるか
- Railsのコストパフォーマンスを追求するというのはどういうことかというと
- これを頭に入れて、作るアプリをレールに載せれば安く作ることに成功する
- 「全部盛り込んでしまわないと後から変更は大変だ」という意識がある これは後から変更するのが実際に大変なことがあるから しかし、変更できるならその考えを変えることができる システムの寿命が長くなればその分、総合的にコストを抑えることができる
- 柔軟 読みやすい　＝　ＤＳＬ
- ここで半分 17:25
- だから、進化がとても早い。Railsはホット。
- やわらかくかみくだく Convention over Configuration 明示的な設定がないときは規約を使う
- ある程度Rubyが読み書きできればRailsの動作を変更することは可能 実は、フレームワークの制約で何かができなくなるといったリスクはとても低い
- 楽しいということは、生産性があがり、良い仕事ができるということ
- 情熱をもって仕事ができるのはとてもいいこと
- 月間2.8億PV(2008年7月リニューアル)
- 感覚的にはこの２年くらいで増えてきている気がするが エンジニアが調達しにくいというのは依然あるとおもう Javaエンジニアを育てるとしたらすぐ書き始め、３ヶ月でほどほど、半年くらいで一人前かな 社内アプリなど育てる環境があるといい
- 例えばこだわりのU/Iとか どうしてもPDF生成が必要だとか
- 密結合 テストとプロダクトコードの間でもいろいろ関連がある
- 新しい考え方として、 ・Railsのレールに載せてアプリケーションを作る ・変更に強くしたり、バージョンアップについていったり ・名前大事、多様性 ・実際にRailsを使っている企業の現場ではこういうことが当たり前になってきている Ａ）技術者としての夢 - すべてがDRYになって、やりたいことがいっぱいできるようになる 　　　煩わしい機械的作業から解放される 　　　でも花に水やるとか、やりたいことはやってかまわないけど Ｂ）Railsは普通にとても使える技術だし、どのくらい使うにせよ、体験して損のないものだと思います。RubyやRailsはコミュニティが活発で変化が早くホットなので、興味のある方はぜひいろいろなコミュティ活動に参加されるとよいと思います。