ネットの海の片隅で

技術ネタの放流、あるいは不法投棄。

クックパッド株式会社を退職しました。

日記 気持ち

2018-11-22 を最終出社日としてクックパッド株式会社を退職しました。 アルバイトを含めると、2015-04-16 入社なので、3年9ヶ月ほどいたことになります。

f:id:s_osa:20181122222312j:plain

ひとつの節目ということで退職エントリを書いておこうと思います。

在籍中にやったこと

大きく分けると以下の2つです。

クックパッド料理教室の開発

クックパッド料理教室というサービスをつくっていました。*1

時期によって増減するんですが、だいたいエンジニアが5人くらい、デザイナー・ディレクター・サポート・マーケティング・営業などの人たちを含めて20人くらいのチームでした。

この時期には、技術的なことだけでなく《サービスをつくる》ということについて、めちゃくちゃ多くのことを学ばせてもらいました。 間違いなく、この時の経験が s-dev talks を立ち上げるモチベーションになっています。

多くのことを学ばせてもらったにもかかわらず、サービスを軌道に乗せることができなかったのが申し訳ないです。

決済基盤の開発・運用

3年ほどサービスに携わったころに「もう少し裏側も触ってみたい」と思って相談した結果、異動した先が技術部決済基盤グループでした。

上記の料理教室時代にも自分のサービスの決済は触っていたんですが、他のサービスを含めクックパッドの関連サービスで広く使われている決済基盤を開発するのはプレッシャーを感じながらも良い経験でした。

また、決済は運用が結構重くて「新規開発をしつつも運用もやる、運用をやりつつも新規開発もする」という課題にどういう風に対処していくかを考えはじめるきっかけになったりもしました。

なんかめっちゃバズった技術基礎研修資料とかもこの時期の仕事です。

なぜ辞めるのか

理由はシンプルで2つだけです。

  • やりたいことができた
  • 自分が1人しかいない

昔から付き合いがある人に声をかけてもらって、話を聴くうちにやる気が高まってきたところで自分が1人しかいないことに気づいたので仕方なく辞めるという感じです。 （付け加えるなら、自分がそろそろいい歳になってきていろいろ振り返ってみたときに「今までに大きい失敗をしてない」ということは少し気になっていて、リスクを取りに行きたいという気持ちもある）

ともあれ、嫌になったから辞めるというわけではないです。

クックパッドという会社は Ruby を書き始めてしばらく経った頃から憧れの会社で、インターンもダメ元で受けてたくらいなんですが、なんやかんやあって入社できて、入ってみたらインターネット越しに眺めていた《すごいエンジニア》がいっぱいいて、毎年入ってくる新卒も恐ろしく優秀で*2、エンジニア以外も含めた同僚が誠実で、情報の透明性が高くて、働きやすい良い会社だと思っています。

もちろん、現実に存在する会社なので良いところだけじゃなくてしんどいこととかもなくはないんですが、それについての変えていこうと思えるし、それができる会社だと思っています。

もしクックパッドに興味がある人がいるなら（もちろん人によって合う合わないはあるだろうけど）、「良い会社だよ」と胸を張って言えるし、自分がもう1人いるなら残していきたいと思っています。

これからやること

詳しくはまた年明けくらいにブログを書こうと思っていますが、八百屋をテックカンパニーにする仕事をします。

事業領域も会社のフェイズも今までとは全然違うところで、今までと変わらず《技術で問題を解決する》ということに向き合っていきます。

おわりに

特に引っ越しとかはしないですし、次の勤務地も近所です。

詳しくは飲みにでも行って話しましょう。

おまけ

送別会の様子

*1:僕の異動後にリブランディングして、今は Cookpad Do! というサービスになっています。

*2:マジで。

Rails の before_action :set_* って必要？

Rails

表題の通り。

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 で喋ってきた。

食品衛生責任者になりました

日記

個人の日記どころかチラ裏のメモ。

食品衛生責任者とは

一般社団法人東京都食品衛生協会によれば、

食品衛生法施行条例第２条の公衆衛生上講ずべき措置の基準及び食品製造業等取締条例第６条の衛生管理運営基準により食品衛生責任者の設置として「営業者は、許可施設ごとに自ら食品衛生に関する責任者となるか、当該施設において従事者のうちから食品衛生責任者１名を定めておかなければならない

とのことです。

簡単に言うと、飲食店などにおいて衛生に責任を持つ人という感じでしょうか。

1日（6時間程度）の講習を受けることで食品衛生責任者になる資格を得ることができます。

動機

今までにも衛生面には注意しながら料理してきたつもりですが、最近は自分が料理したものを多くの人（100人とか）に食べてもらう機会が増えてきて衛生面が本格的に気になってきたので、勉強ついでに取っておくかというくらいの気持ちで受講することにしました。

「とりあえず徳丸本を読んでおこう」くらいの気持ちです。

別に飲食店を開業する予定はありません。

受講まで

受講するにあたっていくつかつらみがありました。

  • 講習会が平日の日中にしかやってない
  • 申込み方法が郵送のみ

講習会が平日の日中にしかやってない

「ぐおお、お役所……」となりつつも、有給は余っているので特に問題なく参加。

申込み方法が郵送のみ

Web に日程表が公開されてるんですが、この日程表を見た上で、用紙に第3希望まで記入して郵送するという感じになっていてつらい。

受講

情報処理試験とかと同じで、一番難しいのが起床。

そして、09:30には受付を終わらせておく必要があるため、通勤時間とぶつかって電車がつらい……。

午前（09:45-12:45）

衛生法規と公衆衛生。

衛生法規は保健所がやっている仕事とか営業許可の審査基準とかがわかって面白かった。ただ、営業許可の審査基準については「これ満たしてない店いっぱいあるやろ……」という感じがした。

公衆衛生で面白かったのは水道水の管理について「ここまでは水道局で、ここからは各事業者」みたいな責任分界点みたいなのが定義されていて、言われてみるとそうなんだろうけどなるほどなという感じ。

午後（13:30-16:30）

午後はまるっと食品衛生。

食中毒の主な原因をざっとながめていく。大きく分けると、

  • 微生物が原因のやーつ
  • 化学物質とかが原因のやーつ
  • 自然毒が原因のやーつ
  • 寄生虫が原因のやーつ

という感じ。

この中でも微生物が原因のやつが食中毒の9割を占めているらしく、ノロウィルス、カンピロバクター、サルモネラ、出血性大腸菌、黄色ブドウ球菌、腸炎ビブリオ、ウェルシュ菌、セレウス菌、ボツリヌス菌なんかが紹介される。

化学物質は洗剤とか消毒剤の混入の他にも、魚類の腐敗によるヒスタミンもここに分類されるらしい。

自然毒はキノコとかフグとかソラニン（ジャガイモの芽）でわかりやすい。

寄生虫はアニサキスが圧倒的。ここ数年、アニサキスが原因の食中毒が増えてて原因の第3位になっているらしい。

結果

食品衛生責任者になる資格を得た*1とともに、食品衛生責任者手帳を受け取りました。

f:id:s_osa:20180803174239j:plain

飲食店などで見る青いプレートは追加課金アイテム（800円）なんですが、せっかくなので買ってみました。 週明けに出社したときにテプラで自分の名前を貼りたいと思います。

講習を受けてみた感想としては「微生物（特にノロウィルス）、マジこえーな」という感じです。

食品衛生責任者資格、わりと面白いし（知識の更新とかは適宜やっていく必要はあるものの）面倒な更新とかはないのでみんな取ってみれば良いんじゃないかな。

余談

このエントリの URL を考えるために「食品衛生責任者 英語」でググったところ「food hygiene manager」というのが出てきて「ハイジーン・オフィサーじゃん！」となりました（アルファコンプレックス脳）

*1:つまり、タイトルは微妙にウソです。