7. RRRSpecについて補足

分散テスト実行システムRRRSpecをリリースしました | クックパッド開発者ブログ

公開したらいろいろ反応があって嬉しいのだけれども、ちょっと補足したいところもあったし、様々な事情により今書いてしまうのが妥当なので、個人の日記でポエムっぽく補足する。

名前

RRRSpecで「とりぷるあーるすぺっく」。

マシンのスケーリングについて

「なんとか理論」って書いているが、実際のところすごく活用しているわけでは全くない。専門の人からしたら小学生ですか〜と言われるレベルなので、お断りとして大学の学部生が教養で学ぶレベルという形になっている。

ただ、こういうスケーリングに関係するところで、初歩的な方法ではあっても"It works"な結果が得られているので、勝てば官軍、動けば正義なところはある。実際、オークションの値段を決めるのにも、いくらで入札するのか、いくらまでだったら値上げするのか、落札できなかったときにどういうふうに振る舞うのか、複数のインスタンスタイプに対して複数価格でどういう構成で入札するのか、とかそういう問題が出てくる。こういう問題に対して「ええい」って適当に勘で決めるのと、わからないながらもいろいろ仮定をおきながら数式立てていじってみたら、これ線形計画問題になるじゃんってなってコード書いてシミュレーションして、はいこういう戦略です、っていう感じで決めるのでは、多少安心感に違いがある。やったことは全然大したことではないのだけれども、無いよりマシ、という程度のことはしましたよ、ということ。

ソースや設計が汚い件について

本当にすまなかったと思っている。しかし、週二回のバイトが成果を出してクビにならないためには、ソースが汚くても前進しなければいけないし、そもそも手探りで進めてきたので「いろいろ問題がわかってから落ち着いて設計しよう」なんてのんきなことは言えなかった。まぁ、これはバイトじゃなくても言えない気がする。

一応言い訳をすると、そもそもRubyを触りはじめたのがインターンをし始めたときなので2013年5月ぐらいで、「オープンクラスとか何言ってんだよくわかんないぜ」という状況。一緒にインターンしてた大学の同期はBundlerの並列化とかして成果をあげているなか、自分はこれといって成果なし。(ちなみに彼とは大学も一緒、入学年も一緒、専攻も一緒、研究室も一緒で同じく技術部アルバイトで苗字も鈴木。※たぶん公開情報)なので、ソースコード綺麗に書くとか、どうテストするか考えるとかそういうことが全然できずに焦りまくっていたので、コードの汚さはごめんなさいというレベル。むしろこのバイトとは別にもう1つバイトをやりながら修士の研究を進めて卒業までいったのだから偉い。

他人の問題を解決できるのかということ

まとめで次のように述べた。

同様の問題に直面している方でRRRSpecをそのまま運用できれば嬉しいですし、そうでなくても、RRRSpecで直面した問題とその解決法が、他の同様のシステムや別の問題に対して参考になれば幸いです。

ソフトウェアには二種類あって、他人の問題を解決できる奴と、自分の問題は解決できる奴とがある。RRRSpecは多分後者になる。

そもそもRRRSpecで実行しなければいけないテストスイートを持っているところが稀だろうし、あっても同じ問題を抱えていないことのほうが多いと思う。もちろん「RRRSpecはRSpecをそのまま置き換えることができて、ただ単にrspecってコマンドを打って実行してたところを、rrrspecって打つようにすれば超早くなるんだぜ。もっと早くしたいなら、rを増やしてrrrrrrrspecってすればもっと早くなるし、rが多すぎたらr7specでもいいんだぜ。」ってなればいいけれども、そうじゃない。

じゃあ公開したソフトウェアが他人にとって解決法として機能しないのであれば無駄かというとそうではない。そのソフトウェアを作る過程で、どういう問題に直面し、どういうふうに解決したのかというのがわかれば、他人の問題を間接的に解決できる可能性がある。

あと、大抵のソフトウェアって、わりと再実装されてしまう場合が多いし、腐らないソフトウェアは無いので、定期的に再実装されるのは健全なように思う。自分のように腐っていくソフトウェアを作っている身としては、どうせ再実装されるのであれば、途中で引っかかるであろう問題点とかを事前に出しておいてあげるのがせめてもの貢献ではないだろうか。ということで、RRRSpecでは直面した問題を説明したりとか、実行シーケンスとか、障害発生時の復旧の流れとかを書いている。

(ここで色々いいそうになったけど、自分の書いたコードはさっき述べたようにクソなので、ここで飲み込んで終わりにする)