管理者のためのRubyの紹介

1. Why Ruby? ダオ ゴック タン

2. Q:今更ですが、なぜRubyを試したいですか？

3. Ruby が日本製だから ? :p

4. 管理者へのお勧め文書 Beyond Java JavaからRubyへ ―マネージャのための実践移行ガイド

5. 目次 Rubyの歴史と将来 Rubyで何ができる？（Javaと比較） Rubyでのウェブ開発プロセス

7. Rubyの歴史と将来 誕生 v1.8.6 ：安定版 v1.9 ：開発版 要注意： YARV ( 仮想マシン ) の導入により実行速度が 5~10 倍向上 2008 現在 公開 (Java と同じ ) 1993 1995 将来： 発展スペースはまだ一杯 （ Java は少ない？）

9. Ruby で何ができる？ （ Java と比較） 技術の面 プロジェクト管理の面

10. 技術の面 拡張性： Cライブラリ（既存ものまたは速度を上げるためプロジェクトで作るもの）とリンクしやすい -> 何でもできる

11. 技術の面 ライブラリがないと開発できない？ -> gem gem とは： ライブラリの管理（インストール、バージョンアップ・ダウンなど）、 PHP の PEAR 、 Perl の CPAN と同じ

12. gem RubyForge RAA – Ruby Application Archive -> ライブラリ数は Java 、 PHP とまだ匹敵できないが開発には十分

13. 技術の面 作るソースはコンパイルしない（ Java と違って） -> 開発が速い（ 5~10x ） -> しかしバグ（主にタイポ）は発見できない？ -> テストで対応 （テストがないと納品できますか？！）

14. 技術の面 (技術のことではないですが) 他の会社はRubyをまだ使わないから… -> Rubyが一般になることを待つとそれが自分の競争力（武器）にはならない

16. プロジェクト管理の面 ソフトを作るのが難しい。 失敗は色々な意味がありますが： 納品期限は守れない 品質が悪い 開発チームが疲れて、次のフェース・プロジェクトに参加できなくなる などなど

17. 失敗の原因 カーネギーメロン大学の調査により： チームの経験不足 ソフトウェア工学のベストプラクティス、開発プロセスの不足 チームワーク不足 要求の変更が多すぎ などなど ->Rubyで解決できる

18. PHP ： 実績がある Java: 便利 Ruby: 理解しやすい Ruby: 速い

19. チームの経験不足 ヶ月 1 2 3 4 5 6 Java ～ヶ月 のトレーニングで 実際のプロジェクトに参加できる Ruby ～週間 のトレーニングで 実際のプロジェクトに参加できる 出来事、経験

20. チームの経験不足 Ruby ・ Rails の 英語の本： ２年前： ~5 冊 現在： ~40 冊 日本語の本： もっと一杯 （翻訳本＋国産本） -> 参考資料が十分

21. ソフトウェア工学の ベストプラクティス 、開発プロセスの不足 ベストプラクティス = 経験 -> 経験不足に関連 （プログラミングの経験があっても、ソフトウェア工学の経験がない場合は多い） ウェブ開発のベストプラクティスと開発プロセス -> Ruby on Rails (あとで)

22. チームワーク不足 チームワーク = コミュニケーション 「 人月の神話 」の結論： スケジュールが遅れているプロジェクトにさらにプログラマを追加すると、そのプロジェクトはさらに大幅に遅れる 人数

23. チームワーク不足 Rubyチームの人数 = Javaチームの人数の1/2~1/3 ->理由： Rubyのおかげで１人のメンバーがより広いプロジェクトの部分がカーバーできる

24. ウェブの中模型プロジェクト Javaチーム：5~10人 Rubyチーム： 2~4人の（RubyとRuby on Railsに慣れた）メンバー 5人以上： 各メンバーの担当部分が重なってしまう ->開発しにくい? ->SE１人＋プログラマー３人

25. 要求の変更 要求の変更 -> ソースの変更 -> ソースが小さい = ソースが変更しやすい = 要求の変更に対応しやすい 同じ要求で、 Ruby のソース大きさ = Java のソース大きさ / 5~10

27. ウェブの開発プロセス Ruby on Rails （Rails）の紹介 ウェブの開発プロセス

28. Railsの歴史 公開 v2.0 ：安定版 REST のウェブ サービス（両方：プロバイダと コンシューマ ）の簡単化 2008 現在 2004

29. Railsの特徴 実際のウェブ開発のベストプラクティスから作られた ベストプラクティス : 設定よりも規約 埋め込まれたツール： rake, unit test, plugin… 第３者ツール（ Ruby のおかげでプロジェクトに追加すろのが非常に簡単）： rspec(BDD 開発プロセス ), capistrano （スモール・リリース） , mongrel （ロードバーランス）… IDE （統合開発環境）： Aptana

30. 設定よりも規約・プロジェクトのソースレイアウト すべてのプロジェクトのソースレイアウトが同じ（「置く場所」が決まっている） -> 理解しやすい -> 開発しやすい -> メンテナンスしやすい ソース

31. Javaとの違い ベストプラクティス、ツールが沢山ですが、ばらばらにならない 「中心」（１つの構造）があるから理解・開発しやすい

32. 例： rake C の make 、 Java の ant と同じ 分類： Rails フレームワークの rake プラグインの rake 自分の rake

34. よく使うrake rake db:migrate rake doc:app rake notes:fixme rake notes:todo rake stats rake test

35. 例： Aptana IDE

37. ウェブの開発プロセス (もちろんプロジェクトによって調整がある)

38. ウェブの開発プロセス 開発前（ビジネス） 開発 開発後 解析 基本設計 メンテナンス 次のフェース の準備

39. ウェブの開発プロセス リーダ（とメンバー）： 設計 リーダ： 全体構造（スケレトン）の作成 メンバー： トレーニング コーディング 自動単体テスト：自分が作ったコードは自分でテストする 時間 結合テスト スモール リリース （自動） タスクの分担、ソースコミット、バグ管理 毎日プロジェクトの進歩が目に見える 何かあったら要求を早目に変更できる コーディングと平行 テストは「最後」ではなく、普通のコードと同じ大切さ メンバーのアウトプット（能力？）が計れる

40. ウェブの開発プロセス 日本語ができないベトナム社員でも日本語のウェブが作れる： RubyGettext 開発時、ユーザインタフェースは英語かベトナム語で書き、後で文字列リソースを全部まとめて日本語へ翻訳