タオルケット体操

サツバツいんたーねっとでゲームとかガジェットのレビューとかをします

一週間くらいCursorでAIコーディングに触れてみた所感

意識が泥沼よりも低い位置にあるのでいままでAIコ〜〜ディングはしてまへんでした。

がしかし、いい加減状況も落ち着いてきたみたいだしショートカットできそうな雰囲気があったのと、色々と状況が好転したのもあり試す機会に恵まれたので現時点で感じたことを書いておこうかなと。
ちょびっとだけ試しておもったことをバババっと書いてるだけなのでかなり的外れになっている危険性はある。備えよう。

ちなみにClaude3.7ばかり使っていて他のモデルはようわからん状態だが、いうほどのデカい違いはないはずだ。

超尖った新人プログラマー

続きを読む

シンプルさに極振りしたSPAルーターが欲しかった

古くはReactRouterとか、Remixとか両者の統合とか(コロコロコロコロ変わるからもうよくわかってない)……
いまはPages RouterとかApp Routerとか(複雑すぎてわかってない)……

とにかくルーティングライブラリは複雑な割に破壊的変更がはいりまくりまくって本当にしんどいです。
ていうかあたしディレクトリ構造とページを一対一にしたいモチベーション全然わかんないし……
主戦場がちょっと特殊なのでRSC採用する必要ないし……

というかRSCとかその辺とルーティングって密結合にしないとダメなの?なんかmiddleware的な仕組みでプラガブルにできないん(マジでよくわかってない)?

とにかく、シンプルさに極振りしたSPAルーターが欲しかった。
URLをみて、レンダリングを制御する。マジでそれだけやってて欲しい。あとnpmの余計な依存とか連れてこないで欲しい。
そういう夜もある。
ただし型安全性、テメーは必要です。

とにかくシンプルなやつを採用すればメンテが止まっても自分で同じ様なモン書けばなんとかなる。シンプルにまとめればルーターなんて数時間もあれば書けるんだから。
……そういうモチベーションでRoconを採用してました。

そしたら更新が止まったので「そろそろなんとかしねえとな」ということで、書きました。

github.com

できたてほやほやなのでまだ割と問題はありそう。

続きを読む

「だから言ったじゃん」って言わせてやれ

正しさカードゲームと化した現代コミュニケーション環境において、人はとにかくお行儀よく振る舞うことを求められます。
社会のお行儀、というのはおおむね「多数派である俺らを不愉快にさせるんじゃねえぞ」というプロトコールです。

みなさんの記憶にあるかどうかは定かではないですが、まずいラーメンを出すな理論はそれに対するカウンターです。
「現場の一体感」より、ちゃんと本質に向き合え。おれらは客にものを出す立場やぞ。

こういった強めの言語化をもってしても打ち勝つのが難しいのが現場の空気感ってやつです。
前向きであれ、否定的なことはいってはいけない(おお、みんな大好きブレスト!)


どっからどうみても失敗は必至、あるいは成功しても意味がない見当違いのプロジェクト。
そんなアホみたいな状況に冷や水を浴びせるのは大変な勇気が必要です。
「みんな成功させようと頑張ってるんだから!」
「後ろ向きなやつがいると成功するものもしないだろ」
どんなに良かれとおもっていても、一体感に酔った人たちに諫言は届きません。
確証バイアスってやつです。

会社員とは、結局のところ悲しいソルジャーです。
墓穴と知っていても、上司が命じてそこにサラリーが生じるなら掘るしかないのです。

続きを読む

ReactにとってStoreライブラリなんてもんはほんまにどうでもいい

まとめ

  • なんでもいい、どうでもいいと言い出すやつはだいたい内心でどうでもよくないと考えている

  • Storeの話をするまえに https://react.dev/learn を読んでReactの基礎を理解しよう

  • experimental state management frameworkと一生言い続けているライブラリをプロダクションで使うべきではない

  • experimentalと一生言い続けているライブラリをプロダクションで使うならその部分は特に気をつけて疎結合にすべき

  • ライブラリの話をしてないでreact.dev/learnのThinking in Reactを読もう

  • とにかくreact.dev/learnを全部読んで、Reactのstateの基礎コンセプトを理解してからStoreへ移動しよう

  • useContextは似て非なる存在で擬似的な流用はできるがまともな代用たりえない

    • useStateも同様
  • なぜReactのhookだけでStore管理しよう論者の多くはuseReducerやuseSyncExternalStoreに言及しないのか

  • React世界からみてStoreライブラリの詳細とかどうでもいいので癒着の余地はない

    • よくない場合、アプリ実装に原因がある
  • ライブラリの批判をする前にreact.dev/learn LEARN REACTを読もう

  • Store的機構の流用自体は有用だが、覚悟をもってやるべき。あとそういう目的外利用の結果でライブラリに文句をいってはいけない

  • 初心者は、Reduxは使わないにしても Style Guide | Redux には一度目を通しておこう

    • お前がこれから踏む地雷の位置がだいたい書いてある
  • https://react.dev/learn は、やる気があるぶんだけ無料で読めちまうんだ!

続きを読む

いいかげんAtomic Designを捨てて別の統一解が欲しい

Atomic Design、どうですか?
フロントエンドをやってる系の人たちはぶっちゃけしっくりきてないとおもいます。
僕を含めて、当初より「これ微妙やね(まぁ流行ってるし適当ではあるから使っておくか)」という見解の人はチラホラみかけました。

それもそのはずです。
朧げな記憶ではありますが、Atomic Designはそもそもプログラマーのために作られたメソッド……ではありません
デザイナーの方が考案した、デザインシステム構築のためのフレームワークです(そうだよね?)。

Sketchでデザインコンポーネントを作成する際に(たしかSketchだったはず。懐かしいですね)、Sketch上のコンポーネントの再利用性を高めて使いやすくするためのものだったのです(だったはずです)。

それが「増えまくったReactコンポーネントをいい感じにフォルダわけしてえなあ」という需要と噛み合って流行ったと認識しています。

筆者のメインフィールドはReactですが、コンポーネントの表示上の見た目と実装や内包するDOMの複雑度はAtomic Designの方法論で抽象化できない、と当初より感じていました。

続きを読む