何でRuby

  • 2,983 views
Uploaded on

管理者のためのRubyの紹介

管理者のためのRubyの紹介

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,983
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
16
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Why Ruby? ダオ ゴック タン
  • 2. Q:今更ですが、なぜRubyを試したいですか?
  • 3.
    • Ruby が日本製だから ?   :p
  • 4. 管理者へのお勧め文書
    • Beyond Java
    • JavaからRubyへ ―マネージャのための実践移行ガイド
  • 5. 目次
    • Rubyの歴史と将来
    • Rubyで何ができる?(Javaと比較)
    • Rubyでのウェブ開発プロセス
  • 6.  
  • 7. Rubyの歴史と将来 誕生
    • v1.8.6 :安定版
    • v1.9 :開発版
    • 要注意: YARV ( 仮想マシン ) の導入により実行速度が 5~10 倍向上
    2008 現在 公開 (Java と同じ ) 1993 1995 将来: 発展スペースはまだ一杯 ( Java は少ない?)
  • 8.  
  • 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が一般になることを待つとそれが自分の競争力(武器)にはならない
  • 15.  
  • 16. プロジェクト管理の面
    • ソフトを作るのが難しい。
    • 失敗は色々な意味がありますが:
    • 納品期限は守れない
    • 品質が悪い
    • 開発チームが疲れて、次のフェース・プロジェクトに参加できなくなる
    • などなど
  • 17. 失敗の原因
    • カーネギーメロン大学の調査により:
    • チームの経験不足
    • ソフトウェア工学のベストプラクティス、開発プロセスの不足
    • チームワーク不足
    • 要求の変更が多すぎ
    • などなど
    • ->Rubyで解決できる
  • 18. PHP : 実績がある Java: 便利 Ruby: 理解しやすい Ruby: 速い
  • 19. チームの経験不足 ヶ月 1 2 3 4 5 6 Java ~ヶ月 のトレーニングで 実際のプロジェクトに参加できる Ruby ~週間 のトレーニングで 実際のプロジェクトに参加できる 出来事、経験
  • 20. チームの経験不足
    • Ruby ・ Rails の
    • 英語の本:
    •  2年前: ~5 冊
    •  現在: ~40 冊
    • 日本語の本:
    • もっと一杯
    • (翻訳本+国産本)
    • ->
    • 参考資料が十分
  • 21. ソフトウェア工学の ベストプラクティス 、開発プロセスの不足
    • ベストプラクティス = 経験 -> 経験不足に関連 (プログラミングの経験があっても、ソフトウェア工学の経験がない場合は多い)
    • ウェブ開発のベストプラクティスと開発プロセス -> Ruby on Rails (あとで)
  • 22. チームワーク不足 チームワーク = コミュニケーション 「 人月の神話 」の結論: スケジュールが遅れているプロジェクトにさらにプログラマを追加すると、そのプロジェクトはさらに大幅に遅れる 人数
  • 23. チームワーク不足
    • Rubyチームの人数 = Javaチームの人数の1/2~1/3
    • ->理由: Rubyのおかげで1人のメンバーがより広いプロジェクトの部分がカーバーできる
  • 24. ウェブの中模型プロジェクト
    • Javaチーム:5~10人
    • Rubyチーム:
    • 2~4人の(RubyとRuby on Railsに慣れた)メンバー
    • 5人以上: 各メンバーの担当部分が重なってしまう ->開発しにくい? ->SE1人+プログラマー3人
  • 25. 要求の変更
    • 要求の変更
    • ->  ソースの変更
    • ->  ソースが小さい =  ソースが変更しやすい =  要求の変更に対応しやすい
    • 同じ要求で、
    • Ruby のソース大きさ = Java のソース大きさ / 5~10
  • 26.  
  • 27. ウェブの開発プロセス
    • Ruby on Rails (Rails)の紹介
    • ウェブの開発プロセス
  • 28. Railsの歴史 公開 v2.0 :安定版 REST のウェブ サービス(両方:プロバイダと コンシューマ )の簡単化 2008 現在 2004
  • 29. Railsの特徴
    • 実際のウェブ開発のベストプラクティスから作られた
    • ベストプラクティス : 設定よりも規約
    • 埋め込まれたツール: rake, unit test, plugin…
    • 第3者ツール( Ruby のおかげでプロジェクトに追加すろのが非常に簡単): rspec(BDD 開発プロセス ), capistrano (スモール・リリース) , mongrel (ロードバーランス)…
    • IDE (統合開発環境): Aptana
  • 30. 設定よりも規約・プロジェクトのソースレイアウト すべてのプロジェクトのソースレイアウトが同じ(「置く場所」が決まっている) ->  理解しやすい -> 開発しやすい -> メンテナンスしやすい ソース
  • 31. Javaとの違い
    •  ベストプラクティス、ツールが沢山ですが、ばらばらにならない
    •  「中心」(1つの構造)があるから理解・開発しやすい
  • 32. 例: rake
    •   C の make 、 Java の ant と同じ
    •  分類:   Rails フレームワークの rake  プラグインの rake  自分の rake
  • 33.  
  • 34. よく使うrake
    • rake db:migrate
    • rake doc:app
    • rake notes:fixme
    • rake notes:todo
    • rake stats
    • rake test
  • 35. 例: Aptana IDE
  • 36.  
  • 37. ウェブの開発プロセス
    • (もちろんプロジェクトによって調整がある)
  • 38. ウェブの開発プロセス 開発前(ビジネス) 開発 開発後 解析 基本設計 メンテナンス 次のフェース の準備
  • 39. ウェブの開発プロセス リーダ(とメンバー): 設計 リーダ: 全体構造(スケレトン)の作成 メンバー: トレーニング コーディング 自動単体テスト:自分が作ったコードは自分でテストする 時間 結合テスト スモール リリース (自動) タスクの分担、ソースコミット、バグ管理
    •  毎日プロジェクトの進歩が目に見える
    •  何かあったら要求を早目に変更できる
    •  コーディングと平行
    •  テストは「最後」ではなく、普通のコードと同じ大切さ
    メンバーのアウトプット(能力?)が計れる
  • 40. ウェブの開発プロセス
    • 日本語ができないベトナム社員でも日本語のウェブが作れる: RubyGettext
    • 開発時、ユーザインタフェースは英語かベトナム語で書き、後で文字列リソースを全部まとめて日本語へ翻訳