できるけどやらない

大学院を卒業して就職したときは与えられた仕事をこなすのに必死だった。 自分の能力なんて全然分からず、できるか分からないけれどもとにかく与えられた仕事をやりきろうとした。

しばらく経つと自分のポジションで必要とされる技術が身についてきた。Ruby はまぁ学生の頃から書いてたけど、Rails の知識だったり Web の知識だったり AWS の知識だったり。 そうすると自分が何をできるのか徐々に分かってきて、社内で改善したいことが色々見つかり、自分にできることを色々やるようになった。 この頃は多少の優先順位は考えつつもやりたいことを色々やらせてもらった。 その過程で自分にできることが更に少しずつ広がっていった。

またしばらく時間が経って、チームが変わって目標が変わり、自分のポジションも変わった。 技術面でもそれ以外でもできることは更に広がっていた一方で、自分がやらなければならない仕事も増えたし、チームがやらなければならない領域も広がった。 このあたりで自分の生産性の限界にはっきりぶち当たったように感じた。 つまり、やりたいこと、できること、やったほうがいいことの量に対して自分が限られた時間内に実際に取り組める量のほうが明らかに小さくなったのを感じた。 そこで自分の中で意識的に自分の時間に対する重要度を判断するようにして、自分の時間を使うほどの重要度は無いと考えたものは触れないようにした。 自分で取り組まないようにするのはもちろんのこと、やりたいことやできることの中には他の同僚が取り組んでいることも含まれていて、「自分はこうしてほしいのに」と思う箇所があったとしても口を出さないようにすることが増えた。 自分の主張をぶつけて議論や再検討に時間を使うよりもお互いに別のことに時間を使ったほうが良さそうかどうかを強く意識するようになった。

これは今現在の話なので、良かったのか悪かったのかはまだ分からない。 ただ、こうやって「できるけどやらない」判断を意識的にしていないと、限られた時間の中で何も生み出せなくなっていたようには思う。

2019年の思い出

しゃかいじんろくねんめ

去年は https://eagletmt.hateblo.jp/entry/2018/12/31/204204

仕事

内定者アルバイト期間も含めると5年と数ヶ月くらい所属していた技術部開発基盤グループが今年の1月で消滅し、インフラ部 SRE グループと統合され技術部 SRE グループになり、僕はそのグループのグループ長兼テックリードという立場になった。いわゆるマネージャーではないものの、チームの目標を決定したりチームメンバーと定期的な 1on1 を実施したり部長を補助する形で評価やフィードバックを行ったりといった役割が増えた。 その後チームの分割や退職があって、最終的には元インフラ部 SRE グループのメンバーに僕一人がグループ長として加わった形になっていた。僕が開発基盤グループ時代の最後にやってた仕事は SRE グループに近かったとはいえ、部のレベルで分かれていたので目標や考え方といった面でギャップを感じ、その中で同じチームとして、そしてグループ長としてどう折り合いをつけていくか最初の頃は大いに悩んだし苦しかった。半年くらい経ってようやくまともに回せるようになった…… と思う。 今の立場で一年間やってみて、自分が強く興味のある領域でチームレベルの目標を立てることはできてもそこまで興味無い領域だと難しいねということと、1on1 や評価を通じてチームメンバーの成長を促す的なことはそんなに嫌いじゃないことが分かってきた。

自分個人の仕事としては引き続き ECS 関連の地味な改善を続けつつ、様々な AWS リソースをアプリケーションあるいはプロジェクトの単位で Terraform によって管理された状態にすべく色々やっていた。しかし前述のような役割追加によって自分で手を動かす時間が減ってるので、自分で技術的に何かを作ったり改善したりといったものは減った。 8月にはシアトルの AWS のオフィスを訪問して AWS の中の人と直接話す機会があった (EBC と呼ばれている)。ECS の中の人とも直接話すことができ、こちらから要望を伝えて何があったら要望を満たせるのか話したり、今後のロードマップを聞きながらこちらでのユースケースを確認したりと、なかなか楽しい場だった。

趣味

今年は色々なライブに行くようになった。これはライブの楽しさが分かってきたという面もあるけど、正直なところアイカツシリーズの存続がかなり怪しく思えてきて終了したときのダメージを減らしておこうという気持ちもあった。アイカツ卒業勢のライブに行ってみたり、プリパラ・プリ☆チャンに加えて WITH の単独ライブや i☆Ris のツアーに行ってみたり、オンゲキやイロドリミドリのライブに行ってみたり、花譜 (これは LV だったけど) やヒメヒナのライブに行ってみたり、ANIMAX MUSIX に行ってみたり。もちろん BEST FRIENDS! のライブにも行った。ラ○○○○祭りのことは忘れた。 来年も1月からリリカルなのはのリリカル☆ライブだったり、アイカツオンパレードのツアーだったり (運良く宮城公演だけ通った。全員揃わないとはいえあのキャパの小ささは何なんだ……)、ホロライブのノンストップ・ストーリーだったりに行くことになっている。 アイカツやプリティーシリーズで CG が歌って踊るのを見るのは元々好きだし、DMM VR THEATER も楽しめていたので、vtuber のライブイベントへの適正の高さを感じる。

アイカツの DCD は継続してる…… けどフレンズ2年目の途中からコンプする気は失せていって、オンパレードのときには完全に失った。オンパレードをいつまでやるのか分からないけど、オンパレードの期間中はたぶんずっとこの調子だと思う。

チュウニズムのレートは5月にプラレを達成して以降完全に伸び悩んでいる。MAX 14.63 で虹まで遠い。定期的に少し上手くなってる実感はあるが…… まぁレートが伸びなくても楽しいので普通によく遊んでる。 オンゲキも同じくよく遊んでいて、こっちのレートは MAX 14.86 まできている。チュウニズムの難易度は SSS < AJ だけどオンゲキは SSS < ABFB < SSS+ に感じていて、わりと ABFB 取れるので気持ち良い。半年以内くらいには 15.00 に届きたい。

Switch で今年一番やったゲームは FE 風花雪月だった。FE if 以来の完全新作で、FE は大好きなシリーズの1つだけど期待以上にめちゃめちゃ面白かった。リシテアちゃんが魔道系ユニットで強くて可愛くて最高。 あとは最近はポケモン剣盾をよくやっている。シンボルエンカウントはピカブイで体験済みだったのでそこまで感動しなかったけど、ワイルドエリアで視点移動できるようになった感動は大きかった。

2018年の思い出

しゃかいじんごねんめ

去年は https://eagletmt.hateblo.jp/entry/2017/12/29/001156

仕事

引き続き ECS を中心とした運用関連のことをやっていた。ECS 自体というよりはその周辺がメインで、たとえば docker logs の保存先を S3 にしてみたり、コンテナインスタンスをスポットインスタンスにしてみたり。このへんの話は https://speakerdeck.com/eagletmt/building-a-steady-ecs-infrastructure で話した。

あとはインターンやアルバイト時代からずっと所属していた開発基盤チームが内部的に2つに分かれて お台場プロジェクト を進めるチームとマイクロサービス的な基盤 (ECS とかサービスメッシュとか gRPC とか) をやる2つのチームになり、後者のほうのリード的な役割になった。来年からはまた少し立場が変わるので不安も大きいけどやっていきたいですね。

インフラ

VPS の環境に Kubernetes クラスタを立てて、今まで Kuroko2 で動かしてたものを CronJob にしてみたり、いくつかの雑 Web アプリをデプロイしてみたり、といった構成変更を行ってた。Kubernetes クラスタを立てるの難しすぎて最終的に Arch Linux から Ubuntu に変えてお手軽なセットアップにした……

自宅のマシン用に NVMe SSD を買った。実際に I/O が速くて HDD -> SSD にしたときと同じくらいの感動があった。

アニメ

去年から引き続きほぼ女児アニメしか見てない。プリキュアが新シリーズになるのは毎年のことだけど、プリティーシリーズとアイカツシリーズが同時に新シリーズに切り替わることになって負荷が高かった。アイカツフレンズは世界観が少し初代に戻ったように感じて個人的にはこっちのほうが好き。

魔法少女リリカルなのは Detonation がついに公開され、長年のリリカルなのはシリーズファンにとってはたいへんよい作品だった…… GoD を知ってる側としては紫天一家の扱いとか気になったりはしたけど、Reflection と Detonation だけで見れば整合してるし、何よりこれまで暗に描いてきた高町なのはというキャラクターの本質に迫っているのが最高だった。

ゲーム

Switch、3DS

ドンキーコング トロピカルフリーズは Switch 版も楽しめた。気持ち良い死に覚えゲー。 OCTOPATH TRAVELER を買ったけど途中で飽きた。元々 RPG そんなに好きじゃない自覚はあったけど、やっぱりポケモンとアトラス製以外の RPG はできないっぽい。 世界樹の迷宮 X はとても面白かった。ただ裏ボスはパーティー再編成必須でまぁいいやと思って諦めた。 ペルソナ Q2 は合わなかった…… 第二迷宮のボス戦の手前でやめた。最初は単純なバランス調整不足かなぁと思ってたけど、ゲームシステムレベルで面白くないように感じた。 ピカブイは前情報での印象とは違って思ったよりポケモンっぽくて楽しめた。とはいえやり込むほどではないなと思って四天王突破くらいで終わりとした。

アーケード

相変わらずアイカツの DCD はやってるんですが、個人的に今年の大きな変化の一つはチュウニズムをやり始めたことだと思う。 アイカツの排出が渋すぎて長時間のプレイを強いられるので休憩がてらにアケフェスをやってたんだけど当時の追加曲の譜面がつまらなくて別のゲームを求めていて、元々少しだけプレイしたことがあったのでチュウニズムを何度かやってみているうちにある日突然レベル9の EXPERT 譜面が普通に S でクリアできるようになり、そこから楽しくなってはまっていった。 年内に レート14を達成 し、最終的なレートは 14.02 (MAX 14.04) となった。 あとイロドリミドリのライブにも行った。

アイカツ

アイカツスターズが終わって次のシリーズに切り替わったり歌唱担当が世代交代したりはあるかなと予想していたけど、歌唱担当全員が卒業し歌唱担当という制度自体も廃止されフォトカツも終了するというのは予想外すぎてショックが大きかった。卒業と言いつつ 5th フェスに一部出演したり、来年のランティス祭りにほぼ全員出演したりするけど…… このへんについては色々と思うところがあるけど長くなりそうなのでこれ以上は別の機会に。

各種イベントには引き続き行ってる。今年からというとフレンズに切り替わったタイミングで DCD のほうの大会に行くようになったことだろうか。THE 3RD PLANET×マグレブ 多摩センター店は神。

しかしライブツアー、武道館、5th フェスの全部が今年あったことなんだな…… 来年の後半くらいにはフレンズで大きなイベントができるといいですね。

送り手のコストと受け手のコスト

自分の中でなんとなく納得がいっただけでとくに結論は無い。 そして今年ここに全くエントリを書いてなかったことにいま気付いた。

ふとしたきっかけで発表するのを好む人の気持ちが気になった。その人は発表スライドだけ見ても話の内容が十分に伝わらず、その場のトークと資料が合わさって初めて成り立つような発表をするタイプのように僕には見えた。その人に限らず、こういうタイプの人はまぁ普通によくいると思う。 一方僕は真逆のタイプで、スライドだけを見てもそれなりに伝わるものを作りがちだ。スライドを読み上げてるだけじゃんという意見も目にしたことがあるけど、実際その通りで口頭で発表するよりドキュメントやブログ記事を書いて公開したほうが良いと思っていて、発表というのはまぁ宣伝効果があるとかそれくらいにしか思っていないところはある。

で、なんで自分はそう思ってるんだろうと考えてみると、受け手側が参照するコストをできるだけ下げたいのではないかと思った。ブログ記事で書いた内容は URL で簡単に共有できて、受け手側はまぁ長くても10分とかそれくらいあれば読める。 一方発表の場合、そのイベントに参加してないとそもそも聞けないこともあるし、動画が残っていたとしても見るのに数十分はかかるだろう。発表が素晴らしいものであったとしても気軽には他人と共有できず、自分がその発表から得られたものがあったとしてもそれを他人に伝えるときのコストが大きい。 良い記事は良い発表よりよくスケールする、と表現できるかもしれない。

逆に発表するのが好きな人は何がメリットなんだろうと考えてみて、まず思いついたのはその方が楽ということだった。 もちろん良い発表をするには事前の準備であったり、その場で受け答えできるだけのしっかりした知識であったりが必要なわけだけど、伝えたい情報を誤解なく伝えるのはドキュメントを書くよりも対面で口頭で説明するほうが楽だと思う。 なので送り手側のコストと受け手側のコストのトレードオフを考えたときに、どっちを優先するかが分かれ目なのかなと思った。 送り手側のコストを下げるというと聞こえが悪いかもしれないけど、情報発信が活発になるという点では良いんじゃないかという気はしているし、文章より対面のほうが正確に伝えやすいというのもその通りだと思う。 そう考えると、僕は情報を整理して後からそれだけ見ても必要な背景や情報に辿り着けるような issue を書くことを好むけど、一方で Slack で気楽なやりとりをして進める人や、あるいは対面で話したがる人がいるのも理解が深まってきた。 YouTube で1時間のライブ配信メインでやってる vtuber が多いのは動画編集のコストが低いからで、一方しっかり編集された動画を作ってると1本が短いので他人に勧めやすく、ヒットしたときの伸びがずっと大きい、みたいな話も思い出した。

ここまでは送り手の話だったけど発表というのは送り手だけでなく受け手もいて初めて成り立つもので、じゃあ受け手側は何故高いコストを払ってまでやってくるのかを考えてみると、そこでしか聞けない話があるというケースもありそう *1 だけど、そういうのを抜きに考えてみるとまぁなんか不思議な気がする。 僕は数年前まではアニメのおたくをやっていたけどライブのようなイベントに興味が無くて、でも去年初めて行ったら楽しくて、Blu-ray の映像を見ているときよりその場にいたほうが楽しい何かはある気がする。双方向感? 一体感? ライブ感? このへんはまだうまく言語化できていない。

というわけで、色々話が発散しつつも、受け手側のコストを気にしてそれができるだけ下がってスケールするように自分がコストを払うか、自分が払うコストをそこそこにしてとにかく発信するか、という間のバランス感覚の違いが人それぞれあって、そこから色々な差が生まれるのかなと思った。 この文章だって酒でも飲みながら適当に話していればすぐ終わってしまいそうだし、そのほうが楽しいかもしれないけど、時間をかけて文章にまとめると多くの人に届きやすい。この文章は別に多くの人に届けたいと思ってないけど。 そんなことを今日の昼休憩の間に考えていたのでした。

*1:送り手側が発表を好むタイプで、ドキュメントや記事を書いてくれないので仕方なく行くパターン

2017年の思い出

しゃかいじんよねんめ

去年は http://eagletmt.hateblo.jp/entry/2016/12/31/215421

仕事

相変わらず hako 関係がメインだった。 とはいえ hako 本体の改善はそこまで力を入れてなくて、それを支える社内の基盤の安定化やスケーラビリティの改善や hako-console の開発が今年の大きなトピックだった。 あとは、この規模の Web アプリケーションの作り方みたいなのがなんとなく分かった気になってしまって代わり映えがしないと感じたので、別なこととしてデータ基盤的なところをやってみたいなぁと思っていた。 具体的には こういうの に絡んだことをやってみたくてちょっと話したりしてたんだけど、結局あんまりうまくいかず。

発表

対外的には Rails Developer Meetup で話した https://speakerdeck.com/eagletmt/web-application-development-in-cookpad-2017 だけ。採用イベントとか社内では他にも少し話したけど。 Ruby に対する興味が年々薄れてきていて今年は RubyKaigi すら参加しなかった。

趣味開発

Rust を使ってみたくて https://github.com/eagletmt/idolmap を書いたくらい。もっと細かいのだとこれまで Ruby で書いていたものを Rust に書き直したりはしたけど、とくにこれといって趣味ではコードを書いてないね……

インフラ

経済的な余裕が生まれてきたこともあって、DB は (録画システムのもの以外は) 全部 Google Cloud SQL を使うようにした。アプリケーションサーバはともかく、DB サーバは壊れたときの消耗が半端なくて、Cloud SQL 高いけど金で解決したい気持ちが強くてそうした。 ストレージサーバも同様で、これまで WD Red を買って保存していたものもどんどん Google Cloud Storage へアップロードするようにしている。

あとはずっと使い続けている ISP の So-net が IPoE の宣伝をしてきたのを始めとして、IPoE に切り替えたり光コラボに切り替えたりその上で何かのオプション *1 を追加したりしたら、IPv6 で Google Cloud Storage への上りが安定して70 - 80MB/s くらいでる環境になってとても快適になった。 それとあわせて DS-Lite で IPv4 でも安定して速度の出る環境になった。

アニメ

ついに最終的にアイドルタイムプリパラとアイカツスターズしか見なくなっていた……

アニメ映画も含めると今年は魔法少女リリカルなのは Reflection がついに公開されましたね!! まさか前編だとは思ってなかったけど!!! 初日に見に行って劇場に入る直前に Reflection と同じビジュアルで Detonation を宣伝するポスターを見た人の気持ちを考えてほしい。 Reflection の内容はちゃんとよかったです。Detonation でちゃんと話を一区切りつけてくれる前提ですが。Detonation ではマテリアルズの出番が増えてほしい。 Reflection が完全に GoD ベースだったので、2017年にもなって PSP と GoD を探して買ってプレイしていた。ハートブレイクマトリクスを劇場で見たい。

ゲーム

Nintendo Switch のおかげでだいぶやった。Switch とゼルダの伝説 BotW は発売前から予約していたけど結果的に大勝利だった。最近になってようやく普通に Switch を手に入れられるようになったらしいけど、なんで発売前から予約してないんですか?? とマウントをとっていた。 Switch ではゼルダの伝説 BotW、Splatoon 2、スーパーマリオオデッセイと順調にプレイしていた。Switch のコントローラが左右に分かれているのも (カジュアル用途では) 非常に動かしやすくてよかった。 Switch 以外だと 3DS で FE Echoes、ウルトラサン・ムーン、真・女神転生 DEEP STRANGE JOURNEY をやった。DSJ についてはまだ最後までいってなくてやってる最中だけど。 来年の Switch のソフトも色々出そうで楽しみ。

アイカツスターズをきっかけとしてゲーセンに行く習慣ができたわけだけど、アケフェスは相変わらずちょいちょいやってる。最近だと Listen to my heart!! がフルコンできて喜んでた程度の実力だけど。未だに Aqours に馴染めてない身としては μ’ｓ の曲を聞きながら遊べるだけで幸福度が高い……

アイカツ

独立したセクションにしてしまったけど今年は Nintendo Switch に並んで個人的にはアイカツの年だった。 ミュージックフェスタ2017でほぼ初めてライブに行ってみたら楽しかったのを皮切りに、様々なミニライブやイベントに行くようになったし、今年は5周年記念ということもあって色々なイベントがあったのでできるだけ参加していた。 ラゾーナ川崎に行ったりラクーアに行ったり、DMM VR THEATER での公演に何度も行ったり、オールナイト上映でバルト9に行ったり、札幌でのアニ ON に旅行を合わせて行ったり、富士急ハイランドに行ったり。 どれも楽しくて本当にありがとうアイカツという気持ちと、これまでの数年間の (とくにスターズになる前の無印の) イベントに参加してなくて非常にもったいないことをしたという後悔があった。テレビアニメはずっと見続けてたんだけどね。 去年の終盤から始めた筐体のほうにもずっと通い続けていて合計でいくら注ぎ込んだのかよくわからない。でもソシャゲよりはマシだと思う(?)。 気付けばもう来週末からライブツアーでそちらもとても楽しみです。

*1:電話でのやりとりだったので詳細を覚えてない

ISUCON7 予選を通過した

ISUCON7 予選に†空中庭園†《ガーデンプレイス》として @ryot_a_rai、@mozamimy と参加して2日目1位で通過することができた http://isucon.net/archives/50956331.html 。

リポジトリは https://github.com/ryotarai/isucon7q

当日まで

例年 Ruby で参加していたけど、今年は発表された初期実装に Ruby が含まれていなかったこと (※後から追加された) もあり、@ryot_a_rai から Go で参加したいという話が出て Go を選択した。 僕と @mozamimy は Go はまぁまぁ書いたことはあるくらいの状態だったので、事前に一度 Go で練習したり pprof の使い方を教えてもらったりしていた。

Go は個人的にはあんまり好きになれなかった言語ではあるんだけど、ISUCON で使う上では普通に書けば普通に速くなるし、 制限時間があってプレッシャーが高い状況で typo とか型エラーとかのつまらないミスをコンパイル時に検出できるので、Ruby よりやりやすく感じた。 おかげでアプリケーションの改修中にほとんどバグを出さずに進めることができた。

当日

僕は主にアプリケーション側の改修を担当していて、MySQL の設定とか Redis をインストールして使える状態にするとか、deploy.sh を用意して git pull && make && systemctl restart && nginx のログローテートを自動化したりとか、そのへんは他の二人に任せていた。 以下、各サーバは isu1、isu2、isu3 と呼ぶことにする。初期状態で nginx とアプリが動いていたのが isu1 と isu2 で、MySQL が動いていたのが isu3。

とりあえずベンチマークを実行してアクセスログを見て GET /icons/:file_name が遅いことがわかり、コードを読むと MySQL に画像を入れてることがわかったので、社内 ISUCON でも見たな～と思いながらとりあえず Redis に入れることにした。 この時点では MySQL の負荷が高かったので Redis は isu2 に入れた。 これで速くはなったんだけどそれでもまだ icons が支配的で、 :file_name が画像の SHA1 値になっていてパスをキーにしてキャッシュできるので nginx の proxy_cache を使ってキャッシュを入れてみたもののほとんど改善せず。 CPU もメモリも余ってるのになんでこんなにスコアが出ないんだ? というあたりで public 側の帯域によるものだと気付いた。 isu1 と isu2 の両方をベンチマーク対象にしたらスコアは伸びたが、それでもリソースは余っていた。 これをなんとかするには画像を配信しないようにするしかなくて、いつかの ISUCON で見たように Cache-Control なのか?? となっていた。 レギュレーションに 304 のケースに関して明確に記述されていて、スコアが100分の1になってしまうものの帯域で詰まってる以上この先に進むには 304 を返せるようにするしかないと決めて試すことにした。 最初は Last-Modified と ETag をアプリケーション側で返すようにして tcpdump をしながら様子を見ていたけど If-Modified-Since や If-None-Match が icons に対して送られてこなくてうーん? と思いながら Cache-Control も返すようにしたら挙動が変わって 304 を返せるようになって一気にスコアが伸びた。 この時点で 16:15 くらいで 98840 点だった。

icons の壁を越えると MySQL や Redis がボトルネックになってきて、ここからは N+1 クエリを直すとか、Redis に移せるものは Redis に移すとか、select のカラムを絞るとか、いつもの作業になった。 MySQL のテーブル定義は変えてない気がする? そのへんは任せていたのでよくわかっていない。 微妙に JS や CSS のリクエストでエラーになっていたので、gzip_static on にしたり Cache-Control 系のヘッダを返すようにしたりしていた。 一通りやりきると MySQL や Redis が空いてきてアプリケーションの CPU 負荷がボトルネックになってきたので、Redis を isu2 から isu3 に移したりしていた。 isu1 と isu2 は nginx とアプリが動いていて、isu3 は public 側の帯域確保のために nginx が動いていてベンチマーカからのリクエストを isu1 と isu2 にプロキシしつつ、Redis と MySQL が動いている状態。

最後に Redis の負荷を分散させるために3台に Redis を入れてシャーディングするというのをやっていた。均等にばらけるのか不安だったけど id を3で割ったり icons のハッシュ値を適当に数値化して3で割ったりして接続先の Redis を切り替えるようにした。 MGET とか HMGET を使っている箇所が面倒だったので、そこは3台に同じクエリを投げてからその結果をマージするようなコードを書いた。 いま振り返るとちゃんと必要なキーだけ集めてクエリを投げるように直してもよかったな。 isu3 だけアプリが動いてなくて CPU 負荷が若干低かったので isu3 にウェイトを置くようにして比率を調整したりもしてみたが、あまり効果もなさそうだったので 1:1:2 の比率で決定にした。 このへんでコードフリーズということにして、pprof の削除やロギングの削除をやった。

ラスト1時間で再起動試験と最終スコアの確定をやった。レギュレーションでは最後のスコアが使われることになっており、今回のベンチマークは同じコードで実行しても一割くらいスコアにぶれがあることがわかっていたので、ここまでのベストスコアが59万点だったため58万点以上が出たらそれを最終スコアにしようという風に決めてベンチマークを実行した。 実際には再起動後のベンチマーク一発目で58万点が出たので、もう少し試したい気持ちもありつつも、最終的にはこのときのスコアのまま終えた。

感想

icons の 304 をさっさと試して最初の帯域の問題を早くクリアできたのが大きかったかなと思う。画像をファイルシステムに置いて nginx に任せるとかせずすべてアプリケーション側で扱うようにした結果、Last-Modified や ETag のずれではまるのも意図せず回避できていた。 アプリケーションの改修でバグを出さなかったのも調子がよくて、最後のシャーディングも一発でベンチマークが通って気持ちよかった (スコアはそこまで伸びなかったけど)。 予選から3台のサーバを使う問題で、ベンチマーク対象を複数指定できるという新鮮な設定で楽しめました。ベンチマークもエンキューしたらすぐに実行されるような環境で体験がよかった。 本選でもよいスコアを残したい。

present? と blank? が嫌い

params の中身のように入っているオブジェクトのクラスが事前に分からないものに対して空っぽい文字列の場合と存在しない場合を区別したくないときに限って blank? を使うのは分かるけど、 nil チェックをするために blank? を使ったり、配列が空かどうかをチェックしたいだけなのに blank? を使ったりすると、 blank? の挙動を正確に理解して nil と空配列を区別したくないから使っているのか、それとも nil がくるかどうか分からないので適当に防御的に blank? を使っているのか、 あるいは blank? しか知らないのかが読みとれずにめんどくさいと思うことがよくある。 かわりに empty? を使っていれば empty? を持っているオブジェクトは blank? を持っているオブジェクトより少ないので読み手に伝わる情報量が大きくなるし、 かわりに nil? を使っていればその変数や引数が nil かもしれないことが考慮されているということが伝わりやすい。 blank? を気軽に使う人たちは ' '.blank? や '　'.blank? の結果を知って使ってるのかも気になる。 これらを知った上で blank? が適切だと判断し blank? を使ってるならいいけど、そうは思えないようなコードをよく見る。

似たような理由でブロック無しの any? が嫌いで、 !ary.empty? のかわりに ary.any? と書く人たちがいるけど、[nil].any? や [false].any? の結果を知った上でその挙動を意図して書いているのか、単に ! と empty? を書くのがめんどくさくてそうしているのかが読みとりにくい。