記事：2024/6/10-
kzk4043ルールなど
とりあえず全部開く
2,3分で読めそうなやつはすぐ読んじゃう
その他はgptに要約してもらってからメモ取りながら読む
土曜日中に読めなかったものは諦めるか、読みたければ繰り越す
今週分
https://blog.sentry.io/why-dont-we-talk-about-minifying-css/
https://javascript.plainenglish.io/write-a-react-component-like-a-pro-4852109ffee5
https://levelup.gitconnected.com/sorry-localstorage-now-im-in-love-with-localforage-2767d38cb81c
https://zenn.dev/cybozu_frontend/articles/fd16d9f427e335
https://zenn.dev/knowledgework/articles/98a730f1d9cf78
https://qiita.com/Yametaro/items/caf16bd79402b1c820e6
https://qiita.com/dnote/items/6b1f53aeaae8cb5ca67b
https://snyk.io/blog/10-modern-node-js-runtime-features/
https://medium.com/@FlowMapp/8-ui-animation-trends-make-your-design-standing-out-of-competitors-060ab2c4a3e7
kzk4043
やっぱみんな思うのね…笑
そしてちょうど先日、PPR相当のServer islandsの実装が検討され始めたようです。
そしてやっぱAstroでもやろうってなるか
PPRではサーバー側のstatic/dynamicな境界を設計する必要があります。一方RSCアーキテクチャではクライアント側でのインタラクティブ/非インタラクティブな境界を設計する必要があります。
これがわかりやすい。
- PPR
- ビルド時に決まるもの（static）とオンリクエスト時に決まるもの（dynamic）の分離
- アイランド、RSC
- サーバサイドでの処理（ビルド時、リクエスト時は問わない）とクライアントでのインタラクティブな処理の分離
つまりPPRはさらにクライアントでの動的処理も別途あるということよな…？まあでもdynamicがユニバーサルだから？
kzk4043
重要な変化と重要でない変化を見分けられない
軽微な変化をスルーできずに消耗する
重要な変化をスルーして詰む
技術の変化の歴史は一見すると振り子に見える
でも実は螺旋構造。同じところには戻ってこない
差分と、それを可能にした技術が重要
kzk4043
localForageというライブラリが、IndexedDBの学習コストを下げてくれるらしい
- 非同期IO
- 500MB
kzk4043
- http compressionが優秀
- multiplexingでさらに速く
- 最近のフロントFWはOOTBで最適化
kzk4043
例外処理の種類
- try, catch
- optional, result
個人的な所感としては、戻り値型の方がミクロなレベルでのハンドリングはやりやすく、FWなどでの共通処理はtry-catch型の方が簡単です。このあたりは何を重視するかにも大きく左右される点でしょう。
kzk4043
- デフォでenvファイル読めるようになってる
- import.metaってastroでもみたけどこっからきてる？
kzk4043
- Actionいまいちわからん
- metaタグを直接書けるようになった
- ForwardRefがいらなくなる
kzk4043
フロントの成果物
- ウェブサイト：wikipediaとか
- Webアプリケーション：gmailとか
- ウェブ技術を使ったネイティブアプリ：discordとか
kzk4043JAM stackわかってない
あれ、ただのSSG…？
どっちかというとインフラ構成とかに重きを置いた言葉…？
割とPPRとかAstroと相性よさそうな感じする。
kzk4043
自分はzenn scrapが小さな変化を積み上げる場です！
kzk4043
コード作者の観点から生じるバイアスに影響されないフィードバックを提供すること
ある変更がより広い対象にとって理解可能かどうか試す最初の試練
コードは書かれるより読まれる回数が多くなるため、この観点は生死を分ける程に重要
コードレビュはコードの正しさについての万能の解決策でも唯一のチェック方法でもなく、ソフトウェアをめぐるそのような問題に対抗する多層防御のいち要素
結果として、コードレビュが成果を上げるためには完璧である必要はない
- 動いているからOKよりは意味がわかったからOKとする
- 指摘よりも質問を心がける
- 指摘が増えてしまうのはチームの状態の凸凹を示している
- ペアプロやガイドライン作成