2020/03/03 にっき - hanachin temporary

るりまのレビューをいくつかした

とりあえずマージしてあとで直す用のissueを建てた

https://github.com/rurema/doctree/issues/2196

4kテレビを置いて再度4k環境を試していた。4k大画面のことを考えていないUIのサービスを使うとものすごい使い心地が悪い

こないだは90x50で試していたんだけど今回は120x75で試してる

ダイニングテーブルの方が奥行きが出やすいのでダイニングテーブルを使うといいのかもしれない

しかしダイニングテーブルの上に常時4kテレビとか重たい本を置いておくだけの設計になっているのかは疑問

ruby-jpでmigrationのupでデータ移行してもいいのかみたいな質問が来ていてあんまりレスついてなかったので答えた

書いていいか悪いかでいうと、書いていいと思います。書くかどうかはいろいろと考えてきめています。

例えばマイグレーションでデータ移行をする際に処理がすごく重くて時間がかかりデプロイ時間が伸びてしまう場合は、マイグレーションとデータ移行を分けて実行しています。マイグレーション実行後にデータ移行のrakeタスク実行みたいな感じで。

一方、時間がかからなさそうならマイグレーションでやってしまうこともあります。

マイグレーションの中でseed的なモデルをcreateしたりとかはよくやる気がします。

考えそうなことは多分いろいろあると思います、一例をあげると

マイグレーション実行時間が伸びるとデプロイに影響がでるか

マイグレーションと同時にデータ移行を行わないとアプリケーション側の処理がうまく動かなくならないか

デプロイでアプリケーションを止めてもいいかダメか

特定のマイグレーション後にデータ移行スクリプトを実行する手順をヌケモレなく行えるよう周知できるか（例えばSaaSで提供しているアプリケーションをオンプレ向けにも提供していて運用が違う場合）

データ移行のスクリプトがコケたときリトライできるかどうか（migrationとデータ移行が分けていればデータ移行だけリトライしやすい）、データ移行は結構考慮もれとか想定外データが入っててエラーとかが起こりやすいので

SQLだけで書けるか・ActiveRecordのモデルが必要か

もしもマイグレーションでやる場合はこのへんとか https://qiita.com/nay3/items/ef773006cd7f815a07cd

このへん気をつけてます https://blog.onk.ninja/2017/10/18/use_reset_column_information

趣味のアプリケーションなら両方試してみてマイグレーションの筋トレしてもいいかも...

そのあと神速さんがrakeでやると困る例をだしたり

データ移行をrakeでやる場合、そのrakeに依存するマイグレーションがあとで落ちることがあります。説明が難しいので、具体的な例を説明すると 1. Aさんが重複データを消す rake タスクを作る 2. Aさんがユニーク制約をつけるマイグレーションを作る 3. Aさんが重複データを消す rake タスクを「使用済みなので削除」と削除する 4. Bさんがマイグレーションを実行する（ローカルDBに重複データが残ってマイグレーションが死ぬ）チームの人数が少なければSlackで周知するとかで回避できますが、人数多いと周知が難しく、マイグレーションが落ちる理由に気づけなくてハマったりする。

消す話をしたり

移行タスクは一定期間残しておくのと、 lib/tasks/migrations/20200303_migrate_xxxx.rake みたいな感じで時系列が分かるようにしておいた方が良いかもしれません。

pockeさんが順序があると大変な話をだしていて「そうだよねうんうん」と思いながらみていた

周知の問題もあるし、 migration A -> rake task A' -> migration B のように実行しないとmigration Bがコケてしまう場合とかも面倒ですねえ。うちはrake taskなんですが人数が少ないからまあギリギリ回っているかなという感じです

昨日は子の食事をつくった。野菜の水煮食べなくなってきてるので味++して3品つくって冷凍。

玉ねぎと豚レバーミンチの卵とじ
玉ねぎ人参のカレー風味炒め
ツナと人参とブロッコリーのトマト煮

4日分ある

すごい話を聞いたのでとりあえず体を動かした

こないだ悲しんでいたら妻にだいたいいつも寝たら直ると言われて寝たら直ったので今日も多分寝たら直る

行動経済学の本おもしろかったしもう1度読み直そうかな