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

具体に依存せず、抽象に依存する

「逆転」という言葉が良くない
低レイヤーの実装→低レイヤーのInterfaceへの依存
高レイヤーの実装→低レイヤーのInterfaceへの依存 これが
こうなるということ

「逆転」を理解する

レイヤーは上に行くほど抽象化される
上→下への依存は抽象→具体への依存となる これを具体→抽象に逆転するので逆転と呼ぶ
（ちょっと無理矢理な感じがするけど）

上が下に依存することのおかしさ

サービス（上のレイヤー（抽象））を実現したいからシステムを構築するのに、実装技術にサービスが依存するような形はおかしい

関連

ドメイン駆動
依存関係package by featureクラス図の矢印は「BがAを知っている」方向に引く
開発Reactのディレクトリ構造すべての関数は、それを変更する理由がただ1つになるように設計するオプションで分岐させるのはやめるフレームワークに依存する問題についてモダンな書き方を追っていきたいのだけど、いつかそれもリプレースが来るのならば古い（基本の）書き方を続けた方が良いんじゃないか創作の大義名分基本を忠実に、応用を頑張りすぎない大きく金を掴みたいなら行政(or to B)にアプローチするのが手っ取り早い新規開発は楽設計手法(MVC・MVPなど)の考え方📐チートシート
抽象ブラウザの整理具体と抽象を行き来するということ文章のいらない部分を削る新しいアイデアは(具体)→抽象→具体→抽象→具体で生まれる
システム👀システム化とアドリブの良い使い分け方
月別アーカイブ