Rails の before_action :set_* って必要?
表題の通り。
Rails でよくある
class HogesController < ApplicationController before_action :set_hoge, only: %i[show] def show end private def set_hoge @hoge = Hoge.find(params[:id]) end end
みたいなのっているの? という話。
set_*
がつらい理由
暗黙的に副作用があることが行なわれている
インスタンス変数の初期化と代入という重大な副作用がしれっと暗黙的に行なわれている。
暗黙的な順序依存性が発生しがち
はじめはシンプルに
before_action :set_hoge
とかしていても、機能追加などをしていくうちに
before_action :set_hoge before_action :set_fuga before_action :set_foo before_action :set_bar
みたいなことになりがち。
これらの set_*
が完全に独立していればまだ良いが、実際には関連するリソースを扱うことが多くて、「set_fuga
を呼ぶ前には set_hoge
を呼んでおかなければならない」みたいなことになりがち。
action の関心がわかりにくい
Rails の controller におけるインスタンス変数は view で使う変数、すなわちレスポンスとして送り返すために必要なものが入っている。
インスタンス変数が暗黙的に代入されると、その action がどういうことに関心があるのかがパッと見ではわからない。
代わりにどう書くか
シンプルな場合
そのまま書けば良い。
class HogesController < ApplicationController def show @hoge = Hoge.find(params[:id]) end end
これくらいの場合で set_*
するのは慣習以外の何物でもなく、メリットがない気がする。
上記ほどシンプルではない場合
具体的には、複雑だったり重要だったりする絞り込みを行なっていて、それを重複させたくない場合。
そういうケースでは set_*
な private method を書くんじゃなく、find_*
な private method を書けば良い。
先に find したオブジェクトへの依存がある場合は依存を明確にするために引数として渡す。
class HogesController < ApplicationController def show @hoge = find_hoge(params[:id]) @fuga = find_fuga(@hoge) end def edit @hoge = find_hoge(params[:id]) end def update @hoge = find_hoge(params[:id]) if @hoge.save else end end private # @param id [String] # @return [Hoge] def find_hoge(id) Hoge.very.complex.condition.find(id) end # @param hoge [Hoge] # @return [Fuga] def find_fuga(hoge) hoge.fugas.very.important.condition.first end end
「暗黙的な書き方 vs. 明示的な書き方」という好みの問題もあるかもしれないが、少なくとも自分にとってはこの方が何が行なわれているか明白だし action の関心も明らかにされていてわかりやすい。
before_action を使うべきとき
念のために書いておくと、すべての before_action
を滅ぼしたいわけではない。
使ったほうが便利なケースも存在していて、ざっくり2種類かなと思っている。
認証など
よくあるメソッド名でいうと authenticate!
とか verify_token
みたいなもの。
action が呼ばれるにあたって、満たしておくべき事前条件のようなものが存在し、その条件を満たさないときは action を実行しないような類のもの。
別の言い方をすると、before_action
の旧名である before_filter
という名前がしっくり来る感じのやつ。
横断的に使用される変数の初期化・代入
典型的には set_current_user
のようなもの。
そのアプリケーションにおいて、ある程度横断的に使われる変数の初期化・代入は set_*
でやってしまっても良いと思う。
理由としては、いちいち各 controller に書くのはさすがに面倒というのがひとつ。
もうひとつは、アプリケーションの全体もしくは論理的に分けられた一部分で横断的に使われるのであれば、そのアプリケーションを開発する人が知っていて然るべき知識としてしまって良いと思うから。
横断的に使用されるという性質上、この類の set_*
は ApplicationController
や Admin::BaseController
のような場所に定義されることになる。
おわりに
Rails で標準的に使われているけど、違和感を覚えている before_action :set_*
について書いてみた。
なんやかんや言いつつも Rails はべんりなので、いい感じに折り合いをつけて付き合っていきたい。
追記
表参道.rb #38 で喋ってきた。
食品衛生責任者になりました
個人の日記どころかチラ裏のメモ。
食品衛生責任者とは
一般社団法人東京都食品衛生協会によれば、
食品衛生法施行条例第2条の公衆衛生上講ずべき措置の基準及び食品製造業等取締条例第6条の衛生管理運営基準により食品衛生責任者の設置として「営業者は、許可施設ごとに自ら食品衛生に関する責任者となるか、当該施設において従事者のうちから食品衛生責任者1名を定めておかなければならない
とのことです。
簡単に言うと、飲食店などにおいて衛生に責任を持つ人という感じでしょうか。
1日(6時間程度)の講習を受けることで食品衛生責任者になる資格を得ることができます。
動機
今までにも衛生面には注意しながら料理してきたつもりですが、最近は自分が料理したものを多くの人(100人とか)に食べてもらう機会が増えてきて衛生面が本格的に気になってきたので、勉強ついでに取っておくかというくらいの気持ちで受講することにしました。
「とりあえず徳丸本を読んでおこう」くらいの気持ちです。
別に飲食店を開業する予定はありません。
受講まで
受講するにあたっていくつかつらみがありました。
- 講習会が平日の日中にしかやってない
- 申込み方法が郵送のみ
講習会が平日の日中にしかやってない
「ぐおお、お役所……」となりつつも、有給は余っているので特に問題なく参加。
申込み方法が郵送のみ
Web に日程表が公開されてるんですが、この日程表を見た上で、用紙に第3希望まで記入して郵送するという感じになっていてつらい。
受講
情報処理試験とかと同じで、一番難しいのが起床。
そして、09:30には受付を終わらせておく必要があるため、通勤時間とぶつかって電車がつらい……。
午前(09:45-12:45)
衛生法規と公衆衛生。
衛生法規は保健所がやっている仕事とか営業許可の審査基準とかがわかって面白かった。ただ、営業許可の審査基準については「これ満たしてない店いっぱいあるやろ……」という感じがした。
公衆衛生で面白かったのは水道水の管理について「ここまでは水道局で、ここからは各事業者」みたいな責任分界点みたいなのが定義されていて、言われてみるとそうなんだろうけどなるほどなという感じ。
午後(13:30-16:30)
午後はまるっと食品衛生。
食中毒の主な原因をざっとながめていく。大きく分けると、
- 微生物が原因のやーつ
- 化学物質とかが原因のやーつ
- 自然毒が原因のやーつ
- 寄生虫が原因のやーつ
という感じ。
この中でも微生物が原因のやつが食中毒の9割を占めているらしく、ノロウィルス、カンピロバクター、サルモネラ、出血性大腸菌、黄色ブドウ球菌、腸炎ビブリオ、ウェルシュ菌、セレウス菌、ボツリヌス菌なんかが紹介される。
化学物質は洗剤とか消毒剤の混入の他にも、魚類の腐敗によるヒスタミンもここに分類されるらしい。
自然毒はキノコとかフグとかソラニン(ジャガイモの芽)でわかりやすい。
寄生虫はアニサキスが圧倒的。ここ数年、アニサキスが原因の食中毒が増えてて原因の第3位になっているらしい。
結果
食品衛生責任者になる資格を得た*1とともに、食品衛生責任者手帳を受け取りました。
飲食店などで見る青いプレートは追加課金アイテム(800円)なんですが、せっかくなので買ってみました。 週明けに出社したときにテプラで自分の名前を貼りたいと思います。
講習を受けてみた感想としては「微生物(特にノロウィルス)、マジこえーな」という感じです。
食品衛生責任者資格、わりと面白いし(知識の更新とかは適宜やっていく必要はあるものの)面倒な更新とかはないのでみんな取ってみれば良いんじゃないかな。
余談
このエントリの URL を考えるために「食品衛生責任者 英語」でググったところ「food hygiene manager」というのが出てきて「ハイジーン・オフィサーじゃん!」となりました(アルファコンプレックス脳)
*1:つまり、タイトルは微妙にウソです。
s-dev talks についての個人的お気持ち
少し前から s-dev talks というサービス開発について話すイベントをやっていて、organizer のひとりとして参加しています。
第2回も終わって一旦落ち着いたので、このイベントについて抱いている気持ちについて書いてみようと思います。
はじめに
これは僕個人の気持ちです。 僕が思っていることを書きたいように書いています。 s-dev talks 公式の見解や声明などではありません。
こういう考えを持った人間が現時点で organizer にいるのは事実ですが、今後 s-dev talks が向かっていく先は他の organizer との議論や参加者からのフィードバックを元にして決まっていくはずです。 フィードバックお待ちしています 🙏
s-dev talks とは?
Connpass のグループページから引用します。
以下のようなコミュニティです。
s-dev talks はサービス開発者の草の根コミュニティです!
ここでの「サービス開発者」は良いサービスをつくりたいと思っているすべての人を意図しています。 典型的にはプロダクトオーナー、ディレクター、デザイナー、エンジニアなどが含まれますが、そういった人たちに限らず多様なバックグラウンドを持った方に来てほしいと思っています。 我々は「良いサービスをつくるためには様々なスキルを持った人たちが協力し合う必要がある」と考えています。
s-dev talks はあらゆる垣根を越えて、サービス開発のためのスキルや知見をカジュアルに共有できる場を目指しています。
Organizer は僕 @s_osa_ の他に @spicycoffee66、@ukstudio、「とくなり餃子大好き」こと @to9nariyui でやっていて、諸々のグラフィックデザインを @tomoya_tsuji_ に手伝ってもらっています。ありがとう。
#1 「仮説検証」、#2 「チームビルディング」と順調に回を重ねています。
s-dev talks をつくった理由
厳密には「s-dev talks をつくるのに乗っかった理由」です。 発起人をひとり選ぶなら @spicycoffee66 だと思うので。
さて、肝心の理由ですが、だいたいは上の引用文に書かれている通りです。 上の文章は僕が叩きをつくって organizer のみんなにいろいろ修正してもらいました。
と、これで終わらせるのもアレなので、もう少しだけ詳しく書いておきます。
チームにはサービスをつくる上で生じる課題を解決するために、いろいろなスキルや視点を持った人が集まっています。 僕だったらエンジニアリングという専門性を持ってチームに加わっていますし、デザインやマネジメントをはじめとして、みなさんそれぞれの専門性を持って加わっているでしょう。
「フレンズによって得意なこと違うから」
これがチームを組んでサービスをつくる主な目的だと思います。
しかし、いろいろなスキルや視点を持った人が集まっている一方で、我々は全員「ユーザーの課題を解決するサービスをつくる」という目的の下に集っています。
持っているスキルや視点は違えど、最終的な目的は同じです。 そのために同じ方向を見て、同じものを思い描いて、チーム全員で「良いサービスをつくる」ということを考えていく必要があります。
こうして考えたときに、前者の各専門領域については勉強会などが活発に開催されていますが、後者の「サービスをつくる人」が集まるイベントがあまり見当たらなかったので「じゃあ、つくるか」となりました。
s-dev talks をどういう場所にしたいか
いろんな人が集まる場所
いろんなところに書いているように、様々なバックグラウンドを持った人が集まる場所にしたいです。
「全員『サービスをつくる人』だ! バックグラウンドなんて関係ない!」という気持ちがある一方で「望むと望まざるとにかかわらず、それぞれの専門によって見えているものが違う。ある人の当たり前が他の人にとってそうではないことは結構ある」という気持ちがあります。
現時点ではまだまだ Web 界隈のエンジニア・デザイナ・PO・PM といった人たちが多いですが、業種も職種も飛び越えていろんな人に来て欲しいし喋って欲しいと思っています。マジで!!!
いろんな人に届けられる場所
サービスをつくっている人たちに聞いてほしいことがあったときに、それを効果的に伝えられる場所にしたいと思っています。
実は大阪の人から「中継とかはないんですか?」といった問い合わせも貰っていて*1、そういう意味でももっといろんな人に届けられるようにしたいと考えています。
勉強会というよりコミュニティ
「s-dev talks 〜サービス開発勉強会〜」と銘打っていますが、「勉強会」という感じにはしたくないなと思っています。
学びがあるのはもちろん良いことですし、過去のイベントではいろんな学びがあったんですが、いろんな目的で来る人がいて良いと思っています。
そのときどきで抱えている課題を懇親会で相談する人がいても良いと思いますし、他の人が難題に立ち向かっている姿を見て元気をもらうのも良いと思います。
明日の行動が少し変わる場所
s-dev talks で話されることは必ずしも「すごいこと」じゃなくて良いと思っています。
世の中には日々試行錯誤しながらサービスをつくっている人たちがたくさんいます。 そんな人たちが現場で得た学びや気付きを共有することによって、他の人の「これ試してみよう」とか「明日、チームの人に話してみよう」といったアクションにつながれば良いなと思っています。
小さな行動がたくさん生まれる場所にしたい。
おわりに
以上、現時点での個人的なお気持ちを書いてみました。
s-dev talks 〜サービス開発勉強会〜 #3 「ユーザーインタビュー」の募集が始まっています。以前からの 5分枠(LT)に加え、今回から20分枠も公募になったので、ご応募お待ちしています!!