2018年振り返り

例年通り、簡単に今年を振り返ってみます。

• 2017年
• 2016年

料理

アイドルの誕生日にケーキをつくったり会社の飲み会で唐揚げを10kg以上つくったりと、わりと料理した年だったように思う。

ケーキは普通の料理より遊べることを発見したので、機会があればまたつくりたいが、設備が整ったキッチンを失ってしまったのでどうにかする必要がある。

s-dev talks

organizer のひとりとして、s-dev talks を立ち上げた。

s-dev-talks.connpass.com

勉強会を主催するということがそもそも初めてだったが、幸いにもいろんな人が参加してくれていてめっちゃ嬉しい。

継続的に開催していくのは決して楽ではないんだけど、立ち上げ時に「こうしたい！」と思っていたことは軒並み叶っている。ありがてぇ。

今後も、より良いコミュニティを目指してやっていきたい。

身の振り方を考えた

たぶんこれが今年を象徴する出来事。

異動して今までとは違う領域に触れてみたり初めての転職を決意したりした。

周囲の人達には迷惑をかけたと思ってるけど、自分の人生に責任を持てるのは自分だけなので、いろいろ考えた上で迷惑をかけると思いながらも思うようにさせてもらった。 *1

去年・一昨年の振り返りでは「挑戦と失敗が足りない」とか「覚悟が必要」とか言ってたけど、そういう意味では今年は一歩踏み出せたのかもしれない。

とはいえ、まだ一歩踏み出しただけなので、本当に重要なのはこれからですね。がんばります。

おわりに

今年1年間、本当にありがとうございました。

*1:＠関係者各位 その節はすみませんでした & ありがとうございました。

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

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

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

在籍中にやったこと

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

• クックパッド料理教室の開発
• 決済基盤の開発・運用

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

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

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

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

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

決済基盤の開発・運用

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

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

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

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

なぜ辞めるのか

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

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

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

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

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

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

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

これからやること

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

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

おわりに

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

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

おまけ

送別会の様子

一致した(させた)
マリオパーティーの破壊力がオリジナル超えた pic.twitter.com/WU94RfQRcS

— ıɥsıo ǝʞsıǝ (@eiskeoishi) 2018年11月22日

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

*2:マジで。

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