Rails アンチパターン - 怠けものサービス(Sluggish Services)
引き続きRails AntiPatternsという本を読んでいます。
https://www.amazon.co.jp/dp/B004C04QE0/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1
前回は7 Testingの2つめ「Lost in Isolation」についてまとめました。
今回は5 Servicesの2つめ「Sluggish Services」についてまとめます。
Sluggish Services
リモートサービス(外部APIなど)によっては、パフォーマンスやたまにエラーになる、メンテナンスになるなど、自分のアプリケーションに大きな影響を及ぼす。
Solution: Set Your Timeouts
失敗時にリトライするか、失敗しても問題ないようなサービスの場合はタイムアウトを設定することでパフォーマンスを改善することができる。
net/httpやfaradayなどの一般的なhttpクライアントはタイムアウトを設定してその時間だけ待ったら特定のエラーをあげてくれる。
Solution: Move the Task to the Background
リモートサービスのレスポンスがおそすぎる場合や、リトライを精密に行う必要がある場合には、ユーザにフィードバックを即時で返さなくていい場合に限り、処理を非同期にするという方法がある。
2017年現在だと非同期処理のgemはdelayed_job, resqueue, sidekiq, shoryukenなどがある。
まとめ
今回は特に言うことなく、外部サービスとのやりとりはタイムアウトを設けて非同期ジョブにするというのはよくある話です。
外部とのやり取り含め、バックグラウンドに持っていくことでパフォーマンス改善できるところは結構ありそう。
複雑化とのトレードオフではありますが。
Rails アンチパターン - モックにより失われた物(Lost in Isolation)
引き続きRails AntiPatternsという本を読んでいます。
https://www.amazon.co.jp/dp/B004C04QE0/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1
前回は4 Controllersの5つめ「Controller of Many Faces」についてまとめました。
今回は7 Testingの2つめ「Lost in Isolation」についてまとめます。
Lost in Isolation
モックを使ってテストを書いていると、unit testとしてテストできるようになるがつなぎの部分はテストされない。 メソッド名が変わったり引数が変わったりという変更に対して追従することができない。
Solution: Watch Your Integration Points
integration testをやろう。Rails5.1のSystem Tests、feature spec やturnip等がある。 開発の順序としては以下のようになる。
- まずintegration testを書き、それをパスするだけの実装をする
- 次にfunctional testを書き、それをパスするだけの実装をする
- 最後にunit testを書き、それをパスするだけの実装をする
まとめ
自分は何が何でもintegration testは書くべきという派です。 feature specはテストが遅くなるため導入の是非はあるのですが、そもそもfeature specを導入できないくらいの規模になってしまっているRailsアプリケーションは大きすぎるのかなという感じです。個人的な意見です。
あと「テスト戦略」については難しいと思っていて、functional testは書かない人も多いみたいです。 なんかテスト戦略関連のことがのっている本を読みたいなと思いました。
【Ruby/Rails勉強法】表参道.rbに行けなかったので勝手にまとめる #omotesandorb
はじめに
2017年6月1日に表参道rbが開催されました。 https://omotesandorb.connpass.com/event/58274/ 参加したかったのですが無理だったので、自分が勉強に使っていたものと、もし勉強法についてアドバイスする機会があれば何を伝えるかということを勝手にまとめていきたいと思います。
勉強に使っていたもの
本や情報など巷にあるものはだいぶ成熟してきた感じがあります。
各自合ったものを選べばよいと思いますが、自分が使ったものは以下です。
Ruby技術者認定試験
当時はRuby1.8系だったのですが、技術者認定のSilverとGoldを取得しました。Goldのほうは自分にとっては難しく2回も落ちてしまいました。
Rubyのメソッドや仕様をみっちり覚えることになった感じです。いまは覚えてない。
Railsチュートリアル
動くものを作ることができたのが良かったです。 回数重ねるたびに色々発見があるのもいいですね。
書籍集
この辺の中で自分に合いそうなものを試しながら読んでました。
るびまのコード添削記事
かなり古い記事なのですが、Rubyらしい書き方や考え方など参考になりました。おすすめ。
もしアドバイスするなら
モチベーション、モチベーション、モチベーション…
言語を勉強するのには基本的には時間と労力がかかるので、モチベーションをたもちつつ継続的にやるということを優先しましょう。 そのための回り道、非効率な勉強法などは、他の人にとやかく言われても気にせずいきましょう。 自分の場合はRailsを始めると少なからずjQueryをやることになるわけですが、Railsをやっていない人から「そんなんいいからReactやれ」みたいなことを言われてへこんだ記憶があります笑
インプットとアウトプット
一般的には学習プロセスでは"アウトプット"を大事にした方がいいという話をよく聞きます。 自分は"アウトプット"あまり得意ではないです。周りを見ても、"アウトプット"得意な人と苦手な人がいるなーという印象です。 色々と考えてきて、"アウトプット"と言うのは「人に見せる形にしろ」ということではなく「手を動かさずにわかった気になるな」くらいに捉えるようになりました。 写経でもいいしコピペしてきたものをちょっといじってみるでも良いですが、バズった記事が流れてきたのをみてふーんと思っただけでは勉強したことにはならないよということです(ブーメラン)。
情報の取捨選択
最近はいろいろ情報がありすぎて、普通にググっても求める情報が出てこないことも多いです。
例えば「form_for form_tag 違い」とか調べるとああ、、、となります。
(activerecordのモデルに紐付かないformを作る場合でも、form_objectを作ってform_forという選択肢にたどりつかない。)
情報の出処をはっきりさせて、自分で選ぶリテラシーを身に着けましょう。
Ruby/Railsの場合もすごい人がたくさんいて、〇〇gemを作った人、〇〇ブログの人、〇〇コミュニティーの人、〇〇株式会社の人などいろいろです。
twitterなりqiitaなりでfollowしていくといいと思います。
スキルの取捨選択
This is Why Learning Rails is Hard - Learn to Code | Code Fellows
Ruby on Railsを構成する技術要素は非常に多く、また追加もされています。特にフロントエンドやawsやコンテナ技術などもRailsサービスを公開する上で必要になるかもしれません。
全てを学んでいくのは難しいので、自分の強みや需要などを加味しながら学ぶべきスキルを決め、そこに向かって行く必要があります。モチベーションのところと若干矛盾していまうのですが、自分の興味と世間の需要あわせて考える必要がありますね。
自分は「こなれた感じのRails開発者」になりたいと思っています。どんなものかというと場合によってhelperやform_objectを使い分けながら薄いview、controllerと責務分割されたmodelを作れるエンジニアをイメージしています。 現場のRailsはおもったよりも汚いことが多いので需要はあるんじゃないかと思います。 長期的な技術スタックはもう少し考えないといけないですね。
まとめ
- 勉強法や資料はいろいろ、出揃っている感じある
- モチベーション大切
- アウトプットはすきなように
- 情報、スキルの取捨選択
Rails アンチパターン - 色んな顔を持つコントローラ(Controller of Many Faces)
引き続きRails AntiPatternsという本を読んでいます。
https://www.amazon.co.jp/dp/B004C04QE0/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1
前回は4 Controllersの4つめ「Monolithic Controllers」についてまとめました。
今回は4 Controllersの5つめ「Controller of Many Faces」についてまとめます。
Controller of Many Faces
内容はMonolithic Controllersパート2という感じです。
コントローラの認証の部分は責務過多になりがちです。よくあるのはUsersControllerにlogin
やlogout
というアクションを実装してしまうケースです。
認証はユーザのセッションを管理しているため、操作対象のリソースをuserモデルにする必要がないということに気づきます。
Solution: Refactor Non-RESTful Actions into a Separate Controller
解決策としては、SessionsController
をつくり以下のようにアクションをもたせます。
class SessionsController < ApplicationController def new # ... end def create # ... end def destroy # ... end end
newがログイン画面、createがログイン、destroyがログアウトになります。
狭義のREST
newとeditは、実はRESTfulなアクションではありません。たとえばweb apiとしてRailsを使ったときに2つのアクションはなくなります。getアクションとして返すものはなく、RailsのviewのUIのためのアクションであることがわかります。 ただし、これ自体悪いことではなく、逆に自分のアプリケーションを作る際に、controllerに定義していいアクションとして更にプレビュー画面用のアクションを追加することもできます。
まとめ
この章で出てきたSessionsController#new, #create, #destroyは本当にあるある(device gemやRailsチュートリアル)なので覚えておきたいし広めていきたいなと思いました。
Rails アンチパターン - モノリシックなコントローラ(Monolithic Controllers)
引き続きRails AntiPatternsという本を読んでいます。
https://www.amazon.co.jp/dp/B004C04QE0/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1
前回は7 Testの1つめ「Fixture Blues」についてまとめました。
waterlow2013.hatenablog.com 今回は4 Controllersの4つめ「Monolithic Controllers」についてまとめます。
Monolithic Controllers
解決策有りきなのだが、REST原則に乗っていないコントローラをRESTに乗せる。 以下のようなサンプルがあったとする。
class AdminController def users #... if not params[:operation].nil? if params[:operation] == "reset_password" # ... end if params[:operation] == "activate_user" #... end if params[:operation] == "show_user" #... end end user_order = 'username' if not params[:user_sort_field].nil? user_order = params[:user_sort_field] # ... end end end
URLは以下になります。
POST /admin/users?operation=reset_password?id=x POST /admin/users?operation=delete_user?id=x POST /admin/users?operation=activate_user?id=x GET /admin/users?operation=show_user?id=x GET /admin/users
users
はアクションではなくリソース名であるべきなのでうつす。また、operationの中身をアクションに移動する。
urlは以下のように変わる。
POST /admin/users/:id/password DELETE /admin/users/:id POST /admin/users/:id/activation GET /admin/users/:id GET /admin/users
コードも変わる
class UsersController < ApplicationController def index # ... end def destroy # ... end def show # ... end end class PasswordsController < ApplicationController def create # ... end end class ActivationsController < ApplicationController def create # ... end end
config/routes.rb
は以下のようになる。
namespace :admin do resources :users do resource :passwords resource :activations end end
まとめ
index, new, create, edit, update, show, destroy以外のアクションがある場合や、アクションが7つに含まれていても1つのアクションが大きくなっている場合はRESTに寄せつつコントローラを分け、先に書いた7つのアクションに乗せるのがいいと思います。
DHHのコントローラの作り方の記事にも書いてましたね! postd.cc
Rails アンチパターン - Fixtureの憂鬱(Fixture Blues)
引き続きRails AntiPatternsという本を読んでいます。
https://www.amazon.co.jp/dp/B004C04QE0/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1
前回は4 Controllersの3つめ「Bloated Sessions」についてまとめました。 waterlow2013.hatenablog.com
今回は7 Testの1つめ「Fixture Blues」についてまとめます。
Fixture Blues
fixtureはRailsにデフォルトで組み込まれているテストデータ作成機能だが、以下のような難点がある。
- 共通化すると変更したときに壊れやすい。
- 毎回作っているとfixtureが大量にできてしまう。
Solution: Make Use of Factories
- FactoryGirl gemを使おう。
- 各フィールド のオーバーライドが容易なので、fixture量産しなくていい。
正直fixtureをそこまでちゃんと使ったことがいので、fixture vs factoryに関しては何も言えません。rspec bookもfactory girlを取り上げつつも反対する意見があることも書かれています。 fixture vs factoryに関してはググると色々出てきますが、以下の記事がわかりやすいかも。 blog.jnito.com
Solution: Refactor into Contexts
- testunitでもcontext分けが出来るようになるgemの紹介と、context入れると明示的でかつDRYになるという話。特にテストデータのセットアップ。
これもrspecしか使ったことがないので、良さに関してはよくわからず…。
rspecにおけるdescribe, context辺の使い方は以下のwillnet氏のrspec coding stileを読むと良さそう。 github.com
まとめ
Rspecやfactory gilrに関してまだまだ知らない事があるなと思ったのでドキュメント読んだりして身につけていく必要があるなと思いました。 あとはfixtureやminitestもどこかでやりたい。
Rails アンチパターン - 太ったセッション(Bloated Sessions)
引き続きRails AntiPatternsという本を読んでいます。
https://www.amazon.co.jp/dp/B004C04QE0/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1
前回は10 Building for Failureの2つめ「Inaudible Failures」についてまとめました。 waterlow2013.hatenablog.com
今回は7 Controllersの3つめ「Bloated Sessions」についてまとめます。
Bloated Sessions
セッションに情報を入れておくとユーザやDBとの通信を節約でき、コードがシンプルになる可能性もある。 しかし、RESTの原則から外れるし、スケールアウトに向かない。またActiveRecordのオブジェクトをセッションやキャッシュに入れておくと、Railsのバージョン変更のときに動かなくなることがある。
Solution: Store References Instead of Instances
- sessionにはidのみを入れる 残りはDBに入れる。 current_userとか。Railsチュートリアルにもあったと思う。
- hiddenタグに入れてクライアントに持たせる。 formとかでよくやるやつですね。
まとめ
今回も反論の余地なしの回でした。 キャッシュにARのオブジェクト入れるのはよくやってしまうので気をつけたいです!