2024/07/01
今日から1日1ページ運用してみる
夜風が気持ちよかったので散歩する
ep153 Monthly Ecosystem 202406
この話題だけで2時間酒が飲める
ダイアログとかpopoverの話だけで2時間酒が飲めそうだよなー
コンポーネント単体でテストがしやすくなったりしている
Type-safe module mockingでMSWとかなしでモックが作れる UI上からストーリー作れる
どのレイヤーにも属さないスタイルは最も優先度が高くなるという仕様があります。
個人的にはつかっていきたいけどまだ全然なれない自分がいるかも
render hooksは普通のコンポーネントを拡張した概念である
なるほど。。個人的には使う側でprops名が書いてあるほうが見やすさという点でいいとは思うんだけど、それも含めて使う側が考えずに抽象化できているならそれはそれでいいのか。。 ゲーム下手とは思えない
まあ元々ストーリーとか考えるのは天才だから操作とかはそこそこなのかしらね
眠い。。
https://gyazo.com/3f0a69feadea23c2f8161deaa5f45226
うおおお。マジか。行くところまでいったな・・
ガチでむずくて草
https://gyazo.com/23d99dd6abbb421e75e0547045986bcd
命名と構造化どちらがリファクタリング対象として対応するほうがいいかの調査結果
命名の読みにくさの方が回答率が多かったけど
しかし一方で命名だけを修正するのは本質的ではないので、構造から修正していくほうがいいという回答が多かった
つまり読みにくさだけを便りにコードを修正するのは避けた方がいい
構造化がおかしい場合バグにもなりやすい
構造的には読みにくさを感じないという結果もある
たしかに頑張れば読むことはできるもんね。。
名前とコードの中味や、やっていることが違う、という場面を発見したときには、脳内に黄色信号が灯るというか、これはコードの書き手との信頼関係が成立しないな、というモードになるんですよね。
抽象化されていればその名前の先を読みに行かなくてもいい、という信頼関係のもとにコードリーディングしていたものから、信頼せずに、その先で実際には何をやってるかを読みに行くモードにチェンジしなきゃいけなくなるんです。
わかる
ドキュメントと命名をしっかりすべき
この2つの思想の間の子がいいんだろうな。きっと
例えば関数をエディタ上でジャンプする回数を減らすとか、しかるべき責務に処理を置くとか
それぞれ言語や使っているライブラリのお作法を理解した上でコードを書かないと行けない前提で、なるべく上記を意識する
えきねっと、IDとパスワードを入力するとパズル認証画面が出てきて、そこに「目の見えない方やマウスの利用が難しい方へ」という案内があり、そこから「別の方法でログイン」として普通にパスワードを入力するとログインできてしまうんだけど、いったいパズル認証は何のために設置されているんだろうか
https://gyazo.com/67472c4a24822d73b8311bff3c2fce63
ロボットではないことを確認するのが一番だけど他のサイトとかだと「私はロボットでありません」のチェックボックスだけのところあるしそっちで代替はできるはずよね。
簡潔で良い場合がほとんど
すげー記事を読むだけでこんなに日報が埋まってしまう。。
まあええか
パッケージつくる人がそれぞれ協力してパフォーマンスとか依存関係とか可視化して良くしていきましょう、頑張りましょう的なもの？ 打ち上げ成功！
https://www.youtube.com/live/jNIkhZxE9vM
人工衛星は真上ではなく地球の周りの軌道に乗せないといけないので斜めに打ち上げる 行くか迷う。。。
あまりにも眠かったので昼寝した
公開した
資料作成しないと。。。。
見れたらみたい
https://www.youtube.com/live/1StFKvcyvAM
最近睡眠不足がひどいので今日な早めに寝るかも