DAY19(2022 6/27) ~ DAY23(2022 7/1)
DAY19(2022 6/27)
- 画像レイアウトを修正した。
- 親要素を超えるとレイアウトが崩れるエラーを修正した。
- Webアプリケーションのテストケースをひたすら考えた。
- github copilotが凄すぎて感動した。推測されるコードが正しいかを自分で判断する力が大事だと感じた。
DAY20(2022 6/28)
- ひたすら作成したテストケースを手動テストした。
- レイアウトが崩れる問題をした。70%くらいやったが、インターバルでデータを取得してたり、色々複雑だったので一旦保留にさせてもらった。
DAY21(2022 6/29)
- サイズを変更した。
- レイアウトが途中で消えないような実装を追加
- オーバーレイを自力で実装した。
- 要素全体をtransform: scale(arg)で小さくした。
- 画像を別の画像に差し替えた。
- 不要なログを全部消した。
DAY22(2022 6/30)
- 5時30に起きる予定だったが、二度寝して6時20分くらいに起きた。ただ、頭の回転は朝のが良いので、夜遅くまで勉強するよりは朝にやるのがやっぱり良いなと感じた。
- テストをひたすらやっていた。
- バーのレイアウト修正をした。
- 旅行でも良いからシリコンバレーに行きたくなった。DeepL使っている場合じゃない、、
- build_associationに引数を持たせて、データ生成時に初期値を設定できるようにした。
DAY23(2022 7/1)
- バーのレイアウトをひたすら修正したが、うまくいかないので月曜やる。
- zero division errorを解決した。
- リリースが終わったので、飲みにいった。
開発における気づき
- Typographyにalignを設定するなら、width: fit-contentを指定してはダメ。Typography自体がテキストの親要素になるので。
- 親要素にposition: relativeを指定すれば、position: fixedでも基準を親要素に変更できる。
- overflow: scrollで要素に収まりきらない場合にスクロールできる。
- scrollTopはスクロールされた要素の最上部から可視コンテンツの最上部までの長さである。
- scrollHeightで画面上に表示されていないコンテンツを含む要素の高さを取得できる。
- reactにonScrollイベントがある。
- イベントを経由してDOMを取得するなら、useRefを事前に仕込まなくても良い。
- loadashは値を操作する便利メソッドを提供するライブラリ。配列の比較などが簡単にできるそう。
- transform: scale(arg)でx軸とy軸で拡大・収縮ができる。文字列とかdivでもいける。
- 真偽値を返す関数の名前がisから始められないなら、existsを使う。
- コミットIDはコミットタブからコピーした方が良い。
- ショートサーキット演算子&&や||は、オペランドがtruthy or falsyかを判定して、結果的にオペランドを返している。
- マウスは腕や肘、手を固定した方が動かしやすいかもしれない。
- gyazoでbefore、afterを撮る場合、検証ツールでスタイルを変えるだけの方が早いので良い。
- SaaSのカスタマーサクセスにおける「オンボーディング」とは、新規ユーザーが「自走」状態でサービスを活用できるまで導くプロセスのことです。
- Appcuesはオンボーディング最適化ツール。
- ブランチ切り替えて何か動作がおかしいなら、docker-compose upをする。
- プラスアドレスでアドレスを増やすことができる。本番で1@example.comとか使ってはいけない。ほんとにそういう人がいるとメールが送られちゃうので。
- ファイルをスクロールしない。
- コンポーネント探す時も検索機能を使う。
- booleanの変数名もisから初める。
- implicit_order_columnを使うことで、どのカラムでレコードを順序づけするかを決めることができる(デフォルトはid)。idにuuidを使っている場合、使う。
- allow_blank: trueで空の値の検証をスキップする。
- has_one_attachedのdependent: purge_laterオプションが設定されていない場合、レコードが破棄されるたびに添付ファイルが消去される。
デフォルト値をテーブルに設定すると、DBの設定を変えたりなど、変更するのに一手間かかる。そのため、コードベースでデフォルト値を設定した方が良い。after_createなどを使って。変更に一手間かかり、変更に弱いシステムになる。もし絶対に変更しないカラムなら、テーブルのデフォルト値にする。ここはチームによるかもしれない。
カラムのオプションの変更をしたが、それをなくしたいだけなら、ファイルを消して、スキーマのオプション部分を消して、DBを直接SQLとかでいじれば良い。流れをちゃんと理解していれば良い。Railsが結局何をやっているのかを理解すれば、Rails Wayに則ってなかろうが、自分で対応策を考えられる。
- schema.rbを直接いじっても、DBを直接変更すれば大丈夫。
調査すること
- optionalなpropsを渡さなかった場合、undefinedになるのか?それがonClickなどのイベントに設定されたらどうなるのか?
所感
Railsのコマンドが結局何をやっているのか?なぜそれを使うのか?それを使ったら何が起こるのか?をもっと知るべきだなと感じました。そのブラックボックスになっている部分をもっと知ることで、結局何をしているかが分かり、自分で対応策を考えることができるので。
CEOと話して、シリコンバレーに行きたい欲がすごい上がった。DeepL使っている場合じゃない、、
以上です。7/4からの5日間も頑張ってきます!