logo
/
0が1に変わる変化とそれ以外の変化を分けて考える
10000人のフォロワーより、10人のファン、2人の友人
10年も立てばより安価で良い技術が出てくるので、10年後も同じモノを使用するということは考えないほうがいい
10日で仕上げるタスクであれば、2割の2日で8割のタスクを終わらせる
1つに絞る
1つのツールで全てをこなそうとしない
20%ルール
20点と0点を選ばないといけない場合もある
30 day challenges
3Dをアニメーションに使うことに感じる違和感は、関数の無理な共通化と似ている
トップページ
設計手法(MVC・MVPなど)の考え方

MVC

Pasted image 20220812162333.png

MVP

Pasted image 20220812162345.png

結局同じ考え方

Pasted image 20220812162416.png
要はプレゼンテーション層・コントローラー層・データ層を分けて循環させる設計をして開発しようねということでよいと思う。 (ビジネスロジック層という言い方は好きじゃない)
MVCドメイン駆動
設計Twelve-Factor App「最初から一発で上手く行くように入念に準備するのが正しい」なんていうのは呪いの言葉コア部分はシンプルに制約をもたせた設計にして、必要な物は差し替えて拡張するコンポーネント設計システム設計一貫性が保たれていることの方が大事 @宗教で喧嘩するな信頼できる唯一の情報源(SSOT)安全にぶっ壊せる仕組みを作っておく設計はデータ設計がメインである
開発Reactのディレクトリ構造すべての関数は、それを変更する理由がただ1つになるように設計するオプションで分岐させるのはやめるフレームワークに依存する問題についてモダンな書き方を追っていきたいのだけど、いつかそれもリプレースが来るのならば古い（基本の）書き方を続けた方が良いんじゃないか依存関係逆転の法則創作の大義名分基本を忠実に、応用を頑張りすぎない大きく金を掴みたいなら行政(or to B)にアプローチするのが手っ取り早い新規開発は楽📐チートシート
月別アーカイブ