今日はこのへんで

プログラミングやプロダクト開発について。もしくはただの雑記。

最近の仕事ぶり

最近はもっぱらRailsを書いていて、ここ数ヶ月で自分がメインで書いた機能がプロダクションにもデプロイされるようになってきた。

そんななかで、自分はもう少しまともなコードが書けると思っていたが、全然そうじゃなかったな、と思うことも多い。つい先日は、N+1クエリを直したつもりでいたのに一部のデータで上手く動かなくて、結局変更を元に戻す、なんて馬鹿みたいなことをやったりした。

一緒に原因を調査してくれた同僚に「 Ruby のプロファイラって使ったことあります?」と聞かれ、使ったことないどころかライブラリの一つも頭に浮かんでこなかったときの情けなさといったらなかった。盲目的にクエリの数を減らせばまぁ早くなるだろ、と思っていた自分が恥ずかしい。

ちょうどその週末の Ginza.rb で Rails のパフォーマンス改善について k0kubun さんが発表していて、身につまされる思いだった。

Railsアプリケーションのパフォーマンス改善手法 / #ginzarb // Speaker Deck

会社では、Ruby 以外の言語も使えるようにしていきたいね、という話が少しく盛り上がっているけれど、個人的には自分は Ruby や Rails のことを知らなさすぎるのではという気がしていて、それどころではない。Go や Rust も良いけれど、それよりも、良い Ruby のコードに触れる機会を増やしたいと感じることが多い。

例えば上記のプロファイラの例で言えば、メジャーな Ruby プロファイラであるところの tmm1/rblineprof は RubyKaigi 2014 で紹介されたもので、もう3年も前の情報なのに、コミュニティの外にいるからなのか少しばかりエンジニア業から離れていたからなのか、そういう常識が抜け落ちている。

そう思ってRubyKaigiのYoutubeを見返したりしており、ちょうど松江Ruby会議での amatsuda さんの公演が良い指針になりそうだった。基本的に amatsuda/gem-src でいつでも gem を手元に置いておいて読める状態にしたうえで、yak shaving 駆動で gem を読んだりあわよくば直したりする、と。なるほど。

実際に gem-src を ghq と一緒に使ってみつつ、bundler では path を指定して手元のソースを読むようにすると、gem のブラックボックス感が薄れて良い。さらにエディタで定義ジャンプをするようにすれば、自然と gem のソースコードも読む習慣ができると思う。

話は逸れるけれど、技術情報をYoutubeで観るのは結構良いと思っていて、なぜなら最新の情報はたいていカンファレンスで発表されるし、メジャーなカンファレンスであれば最近はYoutubeに動画がアップロードされるのは普通だからだ。ブログのように「やってみた」レベルの話ではなく、本のように古くもなっていない、知見のつまったスピーチが聴けるのはYoutubeの良いところだと思う。(とは言え自分が観ているのは1年〜数ヶ月前のものばかりだけど)

(ということをPOSTDを運営していたときにもちらっと思って、そういう動画のまとめサイトみたいなのほしいなぁと思ったけれど思ったままだった)

Ruby/Rails 以外のレイヤーも、いくらでも学び直す必要性を感じていて、ちょうど Real World HTTP が出版されたので読みたいなと思っていた。これについては会社で読書会をすることになり、良い機会だと思ったので参加している。読書会というのに参加するのは初めてで、まだ一度しかやっていないけれど、参加者の知見が集まることで、自分の知識のヌケモレがなくなっていく感覚があり、とても満足度の高いものだった。引き続きやっていきたい。

と、仕事ぶりとしてはバリューも出せておらず、いまだに自己啓発や開発環境の整備といった領域から抜け出せていないけれど、いつまでもそんなことをやっていてもしょうがないので、ちゃんと技術と向き合っていきたい。