Download as PDF, PPTX
![Rubyのメリット
◦ ワンライナー
◦ ブロックもオブジェクトの為、メソッドに渡す事ができる。
◦ 例)
◦ ダックタイピング
◦ > もしもそれがアヒルのように歩き、アヒルのように鳴くのなら、それはアヒルである
◦ 例)
◦ 標準ライブラリの充実
◦ csv: CSV/TSVを扱う
◦ json: JSONを扱う
◦ net/ftp: FTP プロトコルを扱う
◦ Gemにより簡単にライブラリが追加できる
◦ 例) $ gem install bundler
◦ アップデートすればするほど便利になる。
[1, 2, 3].map { |num| “‘#{num}’” } # 各要素に対して処理を行い、結果からなる配列を作成 =>["'1'", "'2'", "'3'"]
.join(", ") # 配列を繋いだ文字列を作成
# => "'1', '2', '3'"
["P226E2", ["ハイキャパカスタム"], :px4] # 異なる型が混在した配列
.map(&:size) # 配列の各要素に対して「size」メソッドを実行し、結果からなる新配列を作成
# => [6, 1, 3]](https://image.slidesharecdn.com/ruby-160129222142/85/Ruby-7-320.jpg)
Rubyのススメ
- 1.
- 2. 目次 1. 自己紹介 2. Rubyが良いと聞き、仕事で使ってみた 3.Rubyとは 1. Ruby導入事例 2. Rubyの言語的特徴(Javaと比較) 3. Rubyのメリット 4. Rubyのデメリット 5. Ruby on Railsとは 4. Rubyは仕事に使えるか 5. Ruby採用・不採用の判断基準 1. アリなプロジェクト 2. ナシなプロジェクト 6. 結論 7. まとめ 8. おまけ 1. おまけ: Ruby導入で失敗しないために 2. おまけ: CAS Serverなるものが便利
- 3.
- 4.
- 5.
- 6. Rubyの言語的特徴(Javaと比較) Ruby Java 純粋なオブジェクト指向 すべてのデータはオブジェクト 演算子もメソッド呼び出し 例) 1 + 2 # => 1.+(2) プリミティブ型と参照型の混在 例) 1 + 2 “hoge” == “hoge” “hoge”. equals(”hoge”) スクリプト言語 > rubyhoge # => そのまま実行! コンパイル言語 > javac Hoge.java // => コンパイル > java Hoge // => 実行 強い動的型付け hoge = “hoge” # String型でも hoge = 10.3 # Float型でも入るけど hoge = hoge + “piyo” # 異なる型の演算はエラー 強い静的型付け String hoge = “hoge”; // String型の変数には // hoge = 10.3; // double型は入らない メソッド! プリミティブ型に対する制御構文 参照型に対する制御構文 参照型に対するメソッド
- 7. Rubyのメリット ◦ ワンライナー ◦ ブロックもオブジェクトの為、メソッドに渡す事ができる。 ◦例) ◦ ダックタイピング ◦ > もしもそれがアヒルのように歩き、アヒルのように鳴くのなら、それはアヒルである ◦ 例) ◦ 標準ライブラリの充実 ◦ csv: CSV/TSVを扱う ◦ json: JSONを扱う ◦ net/ftp: FTP プロトコルを扱う ◦ Gemにより簡単にライブラリが追加できる ◦ 例) $ gem install bundler ◦ アップデートすればするほど便利になる。 [1, 2, 3].map { |num| “‘#{num}’” } # 各要素に対して処理を行い、結果からなる配列を作成 =>["'1'", "'2'", "'3'"] .join(", ") # 配列を繋いだ文字列を作成 # => "'1', '2', '3'" ["P226E2", ["ハイキャパカスタム"], :px4] # 異なる型が混在した配列 .map(&:size) # 配列の各要素に対して「size」メソッドを実行し、結果からなる新配列を作成 # => [6, 1, 3]
- 8. Rubyのデメリット ◦ 演算子すらメソッドなので、良くも悪くも自由に定義できてしまう。 ◦ 安易に行うべきではないが、有効活用すれば直感的に分かりやすいモジュールを作ることができる。 ◦動的型付けが故に、実行時まで型の保証がない ◦ メソッドの型指定ぐらい欲しいよね。でもRubyではOptional Typeは導入しないそうです。 ◦ 書き方の自由度が高いために、可読性が低くなりがち ◦ Rubocopという静的解析のgemがあるので、必ず導入するべき。 ◦ 遅い ◦ 開発スピードと天秤にかけて考えると良い。 ◦ アップデートすると動かなくなる可能性もある ◦ Ruby界隈ではテストコードは必ず書くのが常識らしいです。
- 9. Ruby on Railsとは ◦ Rubyで動くフルスタックWEBフレームワーク ◦ その名の通り、レール(要はルール)に則って開発すると、便利機能が唸る。 ◦他のフレームワークとの主な違いとしては ◦ RubyのWEBフレームワークではほぼ独占状態なので、良い意味で選択の余地がない。 ◦ RESTfulを非常に重視している ◦ GET: 取得 hoge.com/toygun トイガン一覧を表示する ◦ POST: 登録 hoge.com/toygun トイガンを登録する ◦ PATCH: 更新 hoge.com/toygun/3 トイガンNo.3を更新する ◦ DELETE: 削除 hoge.com/toygun/3 トイガンNo.3を削除する ◦ 控えめなJavaScript ◦ なるだけJavaScriptの記述量が減るような機能を提供している ◦ ActiveRecord（O/Rマッパー）によりSQL要らず ◦ DB設計をRails流にする必要あり ◦ 便利なgemが大量にある ◦ Device: ログイン認証機能 ◦ ※他のフレームワークもRailsから大きな影響を受けており、実は同様の機能は他のにも結構あったりします
- 10.
- 11. Ruby採用・不採用の判断基準 ◦ アリなプロジェクト ◦ スタートアップサービスの開発 ◦マイクロサービス ◦ WEB APIの活用に積極的 ◦ どうせひっくり返るから、とりあえず適当に作って、軽く見てもらってから細かいとこ決めよう ◦ ナシなプロジェクト ◦ 技術者の発言権が弱い ◦ 人多くすれば、その分早く開発できるだろう。 ◦ テストコードより、人力が好き ◦ DB設計をWEBアプリ寄りにできない。 ◦ 保守性が〜、特定の技術で何とかしたい。
- 12. アリなプロジェクト ◦ スタートアップサービスの開発 ◦ Javaに比べると、記述がしやすいため、手っ取り早くサービスを立ち上げる事に適している。 ただし、サービスが大きくなると速度面、保守性で問題になる事がある。 ◦※Twitterはパフォーマンスの観点から、途中でJavaに移行した。 Rubyの速度は年々改善しており、CookpadはRubyで運用できている。 ◦ マイクロサービス ◦ アクセス数が増大した場合、パフォーマンス、保守性などの観点から、 他の技術に移行する可能性もあるため、WEBアプリをなるだけ細かく分割すると良い。 ◦ WEB APIの採用に積極的 ◦ 画面開発はRails、データの取得はWEB APIという風にしておくと、 パフォーマンスの面で問題になった際、WEB APIだけGo言語で、など対策が安全に取れる。 ◦ どうせひっくり返るから、とりあえず適当に作って、軽く見てもらってから細かいとこ決めよう ◦ 開発がスピーディに行える為、少数で開発、修正を繰り返しリリースを目指すのに適している。
- 13. ナシなプロジェクト ◦ 技術者の発言権が弱い ◦ Rubyが技術者の楽しさを追求した言語である為、言語のアップデートが多少大胆。 だがアップデートの恩恵が大きい為、アップデート、テストコードの工数を確保する事が重要。 ◦人多くすれば、その分早く開発できるだろう。 ◦ 良くも悪くも自由な書き方ができる為、なるだけ少数先鋭が良い。 特に新規プロジェクトの土台はできる人に任せた方が良い。 ◦ テストコードより、人力が好き ◦ 書きやすさの反面、型指定がない、良くも悪くも自由に書ける等デメリットがある。 特に、アップデートの観点から、テストは絶対に書かなければならない。 ◦ DB設計をWEBアプリ寄りにできない。 ◦ Rails側でDB設計に規則が推奨されているため。 ◦ MySQL, PostgreSQLなど、オープン系DBと相性が良い。※SQLServerで四苦八苦した経験あり。 ◦ 保守性が〜、特定の技術で何とかしたい ◦ 全部Cで書いていれば良いさ。
- 14. 結論 ◦導入した方が良いプロジェクト ◦ チーム間の連携ができる ◦ 技術者の意向を汲み取ってくれる ◦とんがってる・新しいもの好き ◦導入しない方が良いプロジェクト ◦ チーム間に壁がある ◦ 技術者に発言権がない ◦ 保守的
- 15.
- 16. おまけ: Ruby導入で失敗しないために ◦ Bundler ◦ Rails標準で使用するパッケージ管理のライブラリ。 Gemfileに入れたいライブラリを書いて、 $ bundle install するだけで入る!のですが、 $ bundle install --pathvendor/bundle としないと、全環境共通のGemとして入ってしまう。 ◦ Rubocop ◦ Rubyの静的コードチェックをしてくれるGem。 プロジェクトの初期から必ず入れるべき。 ◦ Rbenv ◦ プロジェクト毎に使用するRubyのバージョンを変更できる。 バージョンアップ時のリスクヘッジにもなるので、必ず入れるべき。 ◦ いい感じのIDEがRubyMineという有償のものしかない! ◦ 代替手段としては、Vimというテキストエディタにプラグインを導入だが、IDEほどのやり易さではない。 なるだけRubyMineを導入してもらった方がいい。。。
- 17. おまけ: CAS Serverなるものが便利 CASinoなるGemがあるのですが、 これ使うと簡単に共有認証用のアプリが構築できた。 ◦ できる事 ◦ 複数のアプリのログイン認証を統一する事ができる。 ◦LDAPと認証してダメなら、DBのユーザで認証確認、とかも可能。 ◦ CASとかいう認証規格?を使用しているので、認証アプリがRubyだとしても、 クライアントアプリはPHPでもJavaでも、アプリをCASに対応させれば認証可能。 ◦ CAS認証アプリを構築するGem ◦ CASino https://github.com/rbCAS/CASino ※LDAPと認証する場合: https://github.com/rbCAS/casino-activerecord_authenticator ◦ クライアントアプリ ◦ Rubyの場合は: devise_cas_authenticatable https://github.com/nbudin/devise_cas_authenticatable 資料が英語なので、Google翻訳の出番 CAS認証 サーバ WEBアプリ サーバ1 人 WEBアプリ サーバ2 プリズンブレイク見たい ログイン済み？ ２４見たい ログイン済み？ DB UsersLDAP Users ログインしてよ LoginID & PW IDとPW確認 IDとPW確認 適当なイメージ図 ※私の中での適当な イメージ図なので、 あまり当てにしないでね。
- 18.