昨日、ものすごい頑張って仕事をしたおかげで、今日はすぐにやらないといけない仕事はなくて、比較的穏やかな一日だった。　まだやるかどうか決まってないけど、レスポンシブ対応してないサイトがいくつかあって、時代の流れ的に対応させないといけないのかなぁと思っている。　が、それにはかなりの労力が伴うのでどうするか。　だが、近い将来やらないといけないことは明白なので、それならなるべく早くやっておきたい、というのもある。　3～5ヶ月くらいかかりそうな規模なので悩む……

昨日のランジジャンプの影響で、朝は軽い筋肉痛だなぁと思っていたが、夜になったらだんだんと筋肉痛がきつくなってきた。　普段走りに行く時間には雨は止んでいたが、筋肉痛なので走りにいかないでいいや。　多分もう治っているだろうけど、右太もも裏も不安だし。　日曜日まで休んで、月曜日から始動する。

夜は非Laravelの個人プロジェクトをLaravel化する作業をやっていた。　以前管理画面だけLaravel化済で運用しているが、フロントもやらないといけないなぁと思って。
日英の二か国語対応のサイトなのだが、初期に多言語化するのが面倒で、テーブル設計で手を抜いてしまった部分がある。　実際のテーブル名ではないけど、
・言語テーブル
id, name, key
1, 日本語, ja
2, 英語, en

・ユーザーテーブル
id, login_id, password, birthday
1, aaaaaa, encrypted, 2020-01-01
2, bbbbbb, encrypted, 1999-12-31

・ユーザー↔言語テーブル
user_id, lang_id, name, comment
1, 1, 田中太郎, こんにちは
1, 2, Taro Tanaka, Hello
2, 1, 斎藤花子, こんばんは
2, 2, Hanak Saito, Good Evening

のようにするのが正攻法で、例えば中国語を追加したい場合でもテーブル設計を変更せずに対応できる。

手を抜いてしまったのは「ユーザー↔言語テーブル」を作らずに「ユーザーテーブルを」
id, login_id, password, birthday, name, name_english, comment, comment_english
としてしまったこと。　これだと中国語を追加するとなった場合、テーブルのカラムがひたすら膨れ上がっていくし、メンテナンスも面倒になる。

ただ、全てのテーブルの手を抜いてしまったわけではなく、手を抜いてしまったのは1箇所だけである。　この例外の1箇所を考慮しつつ、データベースから取ってきた値の多言語対応というのに苦慮している。
最初から手を抜かずきっちり設計しておけば良かったし、今やるべきことはその状態で無理やり多言語対応するのではなく、テーブル構造を変更しデータ移行をするのが先だとは思う。
その辺りは非常に悩ましい。

仕事の話でも悩ましい話をしたが、面倒だけどこういうことは最初にやっておくべきだと何度も学ぶ。