今日はようやくテーブル設計がひと段落し、開発に着手できた。一時はどうなることかと思ったが、とりあえず週内に開発開始するという目標はクリアできたので、ペースは悪くないと思う。

一度開発が始まってしまえば、あとは家に持ち帰ってずっとコードを書いていればなんとかなると思う。早速サービス残業する気満々だが、正直レビューがボトルネックになる気がしているので、なんらかの工夫を考える必要がある。一人で土日とか深夜にコードを書いていたら、プロジェクトを私物化する化け物なので、バランスをとりつつ、同期２人のケツを叩いてやっていかねば。

メンバーは３人で、役割分担としては、２人がデザインで、俺がテーブル設計のレビューをひたすら打ち返しながら改善していく感じ。正直、レビューの内容を俺一人で受け止めて打ち返すのは精神的にも脳みそも結構疲れる。メンターの方々も色々レビューしてくれるのはありがたいんだけど、メンター全員のレビューをまともに反映していたらテーブル数がやたら多くなるし、いざコードを書き始めた時にはJOIN地獄に苦しめられるのは間違いないし、何よりいつまで経っても決まらないから、適当なところで「これで行きます」とGOサインを出さないといけない。そうしないと、同期２人もストレスが溜まってくるだろうし。中間管理職の疑似体験かも？

まぁレビューの内容自体はめちゃくちゃ勉強になっている。テーブル設計期間中に受けた指摘の例は以下のようなもの

命名が悪い（hoge_resultsは抽象的すぎる、resultsの具体的な中身が知りたい）
状態を別テーブルに切り出すこと。例えば、retired_atのようなカラムを持つ代わりに、retired_usersのようなテーブルを別で作るとか？
どちらかというと、余分なテーブルがあるとの指摘を受けた
外部サービス連携で外部サービスのデータを取得してアプリケーションがわで保持する際、テーブルはアプリケーション内の純粋なテーブルからは切り出しておいた方が良い。これはアプリケーションの外部依存を弱める働きがある
VARCHAR(255)の255の理由は、アルファベットの場合、1文字=1バイトなので、可変長の文字列全体は高々255バイト以下。そして、VARCHARでは文字列の長さという情報を持つために、文字列全体のバイト数を表現するプレフィックスを持つのだが、このプレフィックスが255までだと、1バイトで11111111として表現できるというメリットがあるみたい。で、色々改めて調べると、日本語は１文字あたり３〜４バイトなので、普通に255にしようが、文字列全体のバイト数は全然255を超えうるのであまり意味がない気もする。一応、慣習的に255が使用されているくらいの理解で良いと思う。

他にも色々とあるんだけど、思い出すのも疲れたからここら辺にしておく。

今回の研修に関しては、実際にアプリケーションの画面レベルまで機能を具体で考えている俺らと、テーマを知っているだけのメンターとでかなり認識のずれがあったから、こちら側が手を抜いた説明をしても、当然全く伝わらない。このように、必然的に仕方なく両者の解像度が異なるようなケースは往々にしてあると思っており、こういったケースでは伝えることを粘り強くしていかなければならない。

〜

進め方についても色々と悩んでいるんだけど、結局は技術力があれば俺の今の色々な辛みは一定解消される気もする。結局のところ、技術力がないので、あらゆる判断がトレードオフを突きつけるものなのか、それとも単に俺の知識不足が招いたミスなのかがわからない。技術力、技術力は全てを解決する。。。！！

〜

家でもlaravelで個人開発のアプリケーションを作ろうと思い、現在着手中。とりあえず昨日から詰まっていたデータベース周りのエラーを解決できた。環境変数周りをごちゃごちゃいじって解決した感じ。

直接の原因としては.env内のSESSION_DRIVERがdatabaseになっていたことが原因らしい。いろんな記事を参考にしたところ、SESSION_DRIVERのデフォ値はfileになっているはずなんだけどね。。。なんでだろ。

DBの接続周りでエラーが出た時は、とりあえず、.envのDB関連の環境変数周りと./config/database.phpあたりを読めば良さそうに思われる。

ちなみに、このsession driverというやつは、sessionをどこに保存するか的なことを司っているらしい。（ちなみにここでいうSessionはログインUser情報や、CSRFトークンなどのことらしい）。なんかこういった頼んでいない子がいつの間にか入っていて辛いのはどうにかならないかしら。

それでいうと、マイグレーションファイル周りはかなり辛くて、Zennで調べた内容とかが本当に役に立たない記事ばっかりだった。というのも、おもに詰まったのが別テーブルの主キーに対する外部キー制約をマイグレーションファイルの記述に使用するという箇所なのだが、どの記事も暗黙の了解として、テーブルの主キーは”id”という文字列を使用していたため、それによる差分によってうまくいかなかった。（laravelでは、主キーが”id”と命名されているケースに合わせて引数が省略されている→constrained()などがあり、こいつらの謎仕様のせいで主キーを’table名_id’と命名する会会員の我々が不利益を被っている）

何が言いたいかというと、AIコーディングの時代はAIが自動補完をよしなにしてくれるので、複数の書き方ができたり、タイピングの負担を減らせる必要はなくて、なんらかの行いたい場合に、それが一通りの方法によって達成されることのほうが大事なのでは？と思っている。

〜