osyoyu(星宮いちご), koba789(霧矢あおい), everysick(紫吹蘭)の三人(ソレイユ)で出た。
伝統のサーバーサイドプログラミング
我々はローカルで開発をしない。代わりに1台目のサーバーにログインし、本番サーバー内のコードを直接編集する。
メンバーのうち、私を含む2人(everysick, koba789)は歴史的経緯により dotfiles がほぼ同じ*1という仲だったため、残り1人(osyoyu)を犠牲にして、私の dotfiles を流し込んだ。
アプリケーションコードの変更は、使い慣れた設定の環境が使える私と everysick で一台のサーバー(作業環境)を奪い合いながら、ソースからビルドした emacs 26 を使って行った。ちなみに osyoyu は vim 使いである。
これによる利点は、必然的にペアプロが強制されるためにケアレスミスをとにかく減らせる点にある。
昨年からこの作戦を採用し、効果は十分に確認されている。
git利用可、ただしpush/branchは禁止
git 禁止という過激な選択をした昨年に引き続き、今年も git に関しては慎重な姿勢でチーム内のルールを決めた。
結果、merge が必要になるような操作は禁止し、必ず歴史が master 一本になるような運用でのみ、git を利用可能とした。
つまり、commit と revert くらいしかできないということである。
前述の通り編集は本番サーバー内で行うため、git の分散リポジトリとしての特徴は全くいらないという判断である。
log, diff が使えたのは git 禁止より便利だったので、この作戦は有益であるといえる。
mamiya.sh
昨年に引き続き、今年も登場した mamiya.sh。
これは編集用の本番サーバーから、他の二台にコードを撒くためのスクリプトであり、某の超優秀なデプロイツールから名前を借りている。
ただし、すごいのは名前だけで、実態は rsync と ssh くらいの小さなシェルスクリプトである。
前回は俺が当日に書いたが、今回は osyoyu が書いて持参してくれた。今回の osyoyu は事前準備賞である。
get_events2
前回の git 禁止の影響で、初期実装のコードを破壊せずに進めるクセがついていた。
そのため、 get_events の改善のために get_events2 メソッドを新規に定義して実装した。
API のエンドポイントを差し替えるときも /api2/ などとすることで git に頼らずに既存実装を保護した。
これのナイスポイントとしては、画面上で元の実装が確認しやすく、またバグったときに戻しやすい点が挙げられる。
総評
reservations のロックを潰せなかったのは悔しい。
ちなみに我々は計画的なので今回も素振りはありませんでした。精進あるのみ。
*1:大学入学直後の everysick に、同期だった俺が自分の dotfiles を勧めたのがはじまりで、彼の dotfiles は私のそれの fork なのだ
