日記

Rails の config 周りのコーディングルールについて考えた

例え複数人でコードを書いていたとしても、一人の開発者が統一的に書いたように記述するべきだと思っており、この方針の優先度には個人的にはかなり重きを置いている。パターンの導出を助けるし、機械的なコードの生成にも繋がると思っている。ここでどれだけ一貫性のあるルールを素早く考えられるかというところで、プログラマのコーディング面での能力が推し量れると思う。知らんけど。

さて、この方針を守るためには、実現したい処理に対してコードの形が一意に定まるようなルールを設けるべきであり、実際のところ自分のコーディング作業というのは、このルールを考えること・従うことにほとんどの労力を費やしていると言っても過言ではない。

今日は Rails でアプリケーションの初期化時に行いたい処理のコードの配置方法について考える機会があり、こういうルールを持つのが良いのでは、という一案を考えた。

• config/application.rb では Rails.configuration と Bundler に対する設定と require のみ行う
• config/environments.rb では Rails.configuration に対する設定のみ行う
• config/initializers/*.rb では Rails.configuration に対する設定以外のことを行う

例えば development 環境のみで実行したい何らかの初期化処理があったとして、Rails.configuration に関するものは config/environments/development.rb、そうでないものは (例え Rails.configuration に設定した値と何らかの関連があろうとなかろうと) config/initializers/*.rb に配置する。

amakan anime が最終段階に入った

最終段階の定義を述べよ、という感じなんですが、データを投入して公開すれば全員が見られるようになるという状態まで進んだ。早速データ投入用の処理を実行しはじめたところだが、これは数時間掛かるので、朝起きたら完了しているか失敗しているはず。

進捗ってタスクの量を線形に分割して 30%、60%、90% のように考えたりするけれど、タスクの選択方法をランダマイズしない限り、簡単で効率の良いタスクから選びがちになる。そうなると幾ら時間を掛けても進まない効率の悪いタスクが最後に残りやすくなるので、時間感覚がおかしくなるんじゃ……ということを考えていた。リリース前になって、小さいくせにめちゃくちゃ重いタスクが詰まれていることに気付き、いや知ってたけど、重いな、今日はゲームがんばったし寝るか、ということが何度かあった。

成果の振り返り方

成果を1ヶ月とか1年とかの期間で振り返るときは、自分主観でやったことを並べるのではなくて、自分の顧客が自分の仕事によってどういう恩恵を享受できるようになったかという変化を並べる方が、より誠実な振り返りになりやすいと思う。この場において誠実さってなんなの、おいしいの、って話だけど。まあ後者の評価方法だと完全に逃げ場が無くて、本当はほとんど成果を挙げていないということが客観的に明るみに出てしまい、また自覚することでダメージを受けてしまう場合があるので、防衛的に前者の方に逃げがちであるという気持ちは分からなくもない。

Switch が発送された

数日前にたまたま予約できた Switch の発送のお知らせが届いていた。ゼルダの新作と Splatoon の試射会が楽しみ。インターネットと画面何枚かあるので、Switch 手に入れられなかった人も含めてうちで試射会会やるのも良いかも。