雑
https://gyazo.com/382026bcaff09f3ad802e38965b0a295←ここに目隠し画像がある
思いつきのメモ
謎タイムライン
このページを膨らませるのは良くない自覚はある
最終的に個別のページに切ろうと思ってる
実際切ってる
Twitterに書くよりはマシだろう
適度にページを切っていく
そもそもページを切って書けやという話もある
タイトル付けるの難しいんだよ
長く考えたいことを残しているというのもある
ここに書くことのメリット
頻繁に自分の目に入る
ここに書くことのデメリット
関連ページリストに「雑」が出てきてノイズが増えたり、情報量が減ったりする 上部の検索バーから書き始めずに、ここを開いてから書き出すので、既存のノートに近いものがあることに気付けない
雑のボリュームが上がりすぎて、雑を書いているときに関連ページリストが全く目に入らない 仮にこのページをどこかから参照されたときに、(そのうち移動するので)リンクが切れやすい
一定期間目に入るところにおいておきたい
工数計算のいくつかの種類
自分用
厳し目、モチベート
見せる用
合意、予算のため
いくらかの余裕を設ける
優先度付の難しさ
優先度をつけるのはなぜ難しいのか?どうすればできるようになるのか?
具体を見たり、混在しているものを比べても仕方がない
抽象に揃えたとて、価値判断が難しい
データがある
論理的に判定できる
自分がペルソナであり直感で判断できる(?)
ミニマリスト的志向
いかに捨てられるか
プログラムにおける抽象(インターフェース)の設計の難しさにも似てる
小さな口で大きな効能を生み出す
近くで会議をしている声が聞こえる
自分は参加しておらず別のことをしている
発言していない人もいる
少数の人が主導しがち
いろんなアイディアが出るものの、まとめる人がいない(?)
それをそのまま実装に落とし込むとちぐはぐになりそう
課題(抽象)と機能(具体)がごちゃまぜになっている
機能を発想し、それについて発言する
どういう課題があって、それに対して他にいくつもの機能が発想できるという可能性が削られてしまう
道具の抽象度を考える
コードもそうだし、
サービス自体も同じ
意味のないものを作らない
要件を満たしたうえで、体験を良くする
優先順位は比較的表層に近い
つまり具体的
何段階かのレベルがありそう
そもそも列挙されているタスクの質
そのタスクの根本の要件に対する優先順位
また、実装コスの加味
タスクをフラットに並べて「優先順位を考える」というのは、たぶん考え方がおかしい
完成されたUIの表層だけを見て、価値を判断している感じ
中身、内部の構造に目を向けられていない
だから間違える
不要な情報量が多い
必要な情報にアクセスするまでのノイズが多い
時代の流れ、
一手でできることが増える
今まで複雑に思えたものが一手でできるようになる
そうすると今までおざなりにしていた他の部分にも注力できる
10年前の時点でFigmaのようなアプリケーションが出ていてもおかしくない
しかし、実装コストが高すぎた
発見されていない抽象も多すぎた
作れはするが、完成までの工数が大きすぎる
バグったときのメンテナンスコストも高すぎる
webは進化した、ライブラリも進化した
その中で良い抽象が発見され続けている
Floatよりもgridのほうがいいじゃん、ということに気づいて形になった
継承ってそもそも何がしたいんだっけ?
また復習しよう
ポリモーフィズムをやるための一手段という立ち位置だっけ?
正解の使い方をしたときに何がどう嬉しくなるのかを忘れた
https://gyazo.com/f9fdd9fd595b01ed79d78e021a4ba4ca
Gyazoの画像ロック.icon
操作もコンテナと引数みたいにすればよいのか
reducerのeventみたいな感じで、
具体的な構造をラップする構造
をinterfaceとしても作る
pay = <T>(item: T, a, b) => numberみたいに
目的の値部分は多相にする
a, bは常に必要ななにかの値
例えばこんな
code:ts
type Calc<Frill> = (
frill: Frill,
cutOffSize: CutOffSize,
count: BaseFabricCount,
) => CutOffFrillLength;
事業
値を一段抽象レベルを挙げると関数になる
それをそのまま一弾挙げると高階関数ということになる
と言えそう
UIを考える時も具体的な値に着目しすぎない
要素の配置は手段である
グルーピング
ユーザの操作
行う順番、時間的
行う頻度、
GPTsに1on1してもらえば良いじゃない、みたいなことを思った
あるいはハッカー飯?
状態の変遷を明示する
「注文」のような、同じものが状態が更新されていくのはイメージしやすい
一方で、それを捉えられていなくてだいぶ詰まったことがあった
入力が多めのアプリケーションで、
inputs → calc→recipe→length→price→instance
まあこれも、同じものの状態更新とみなしてもいけたかもしれない
moduleというもの考えたときに、構成物という切り口でしか見えていなかった
時間的な遷移というのが抜け落ちていた
良いインターフェースと良い抽象化ってかなり類似する?
外部との結合をできるだけ小さくする、即ち、境界をできる限り薄くする
それでいて十分に機能を果たすことができる
interfaceの開け方がミスっていると、それを補強するために別のinterfaceを設置する必要が出てくる
その結果、結合がどんどん大きくなっていく
例えば、monadはjoinとpureだけ、reducerはeventsとstateだけ
たった2つ程度のinterfaceだけで、広範な機能を表現できる
中身の構造が全く異なるものだったとしても、
Interfaceを使う3つの目的
特性表現
オブジェクトの振る舞いや能力にフォーカス
機能を表現する
差し替え可能性
実装の切り替えにフォーカス
Componentレベルの差し替え
実体ではなく機能にフォーカスし、実装を差し替えられる
境界分離
影響範囲の最初かと切り離し容易化にフォーカス
モジュール同士の境界
そこまで外してないけどちょっと腑に落ちない感じがあるmrsekut.icon
なんでだろう
「機能」って呼んでることに違和感があるのかも
「目的」に着目することが、
「操作」に着目することに繋がり、
結果的に、「抽象」の発券につながる?
https://gyazo.com/8d801aad1d0d3eacf72c39d92e15dbba
確かに、具体と抽象と、手段と目的を重ね合わせてみれば、
抽象を発見するために、目的に着目するのは意味がありそうだ
この辺の話おもしろい
https://gyazo.com/c5ad5e99ac523d262852692048b1ddd2 https://gyazo.com/e7c6a195d33e3c2a79c6f0295312a26c
https://gyazo.com/d5c0575a7fab6df7e30d735487443618
https://gyazo.com/8fc19adc32f04ed5652e5c7ddd92690ahttps://gyazo.com/00863b1d28bb28c69c332e94ff2f4d1a
ものとしてモデリングすると低凝集になりがち?
https://gyazo.com/928e19171bf6cae728f9bbd694f7eb4f https://speakerdeck.com/minodriven/buisiness-purpose-system-design?slide=67
これ、そうなのだろうか?
わかる気もするが、根拠も乏しい
データクラスのことを言っているならそうだと思うけども (図の下の文章)、 タイトルの「ものとしてモデリング」というのは、
「モデリングするときにモノという単位で考える」という意味だと思う
こっちを深堀りしたい
実際、eventに着目する設計手法があったりするわけだし
登場する概念をバーっと列挙して、適当にグルーピングして、
その中で持つべき特性、ふるまいのようなものを洗い出す
オブジェクトはネストになってるかもしれないし、そうでないかもしれない
それはあまり関係なく、とにかく振る舞いを洗い出す
これがインターフェースになる
しかし、そのふるまいの返り値の構造はどうやって決めるのという話もある
そのオブジェクトの構造に依存したものになるのか、振る舞い側が規定したものになるのか
理想的には後者になるべき
フィードバックがほしい、という欲求微妙だなmrsekut.icon
なんというか受動的すぎる
だから、Xで何かを宣伝するのも的を射ていない気がしてきた
誰に伝えたいの?誰にフィードバックしてほしいの?誰でもいいわけじゃないよね?あたりが考えられていない
主体的に臨むなら、ちゃんと特定の人物に対して「これについて意見をください!」と言うべき
ということは、その特定の人物と話せる距離にいるのが良いわけだが、
その特定の人物って誰やねんというのがある
イマジナリー強い人みたいになってる(なってない)
謎の承認欲求みたいなものの、本当の欲求をちゃんと探るべき
整備されていない環境を整備しつつぶちあげることと、
誰かが整備した心地の良い環境でぬくぬくやること
を比べると、たぶん前者のほうが面白いmrsekut.icon
自分の能力を一番ブーストできる環境を考える
チームメンバの感じ、業務の内容、技術の種類、裁量、など
転職前にすること
明確な成果を上げる
他の人を全員超える
その会社特有のちしきをえる
例えば物流、倉庫など
知名度を上げる活動をしていくべき?
というのを漠然と思う
掘り下げを仕様
何のために
何が嬉しい
本当に達成したいことと知名度は関係ないのかもしれない
もっと効率的で直接的な方法がありそう
PBFは構造の一面の表現
MVP自体にもUXは大いに含まれるだろう
新しい機能を、何のスタイルもしていないボタンを1つ追加すれば、機能自体の有用性を測れるかも知れないが、
それによって、元のサービスの世界観が壊れたら台無しなわけで
アクセシビリティなどが後回しになりがちなのは、それの優先度が低いと判断してるからに過ぎない
MVPの篩からは振り落としました、というだけ
対象のユーザがそれを最も必要としていると知っていればそれの優先度が上がるだけ
MVPという方針を取っている以上、最初に含まれないのは仕方がない(?)
UIを考える頭と設計を考える頭は割と違う気もする
ここのスイッチングを1日の中でやるのはあまり良くないかも
日を分けたほうが良い気もする
決まったルールで自動生成する
性質を捉える
汎用的なものを組み合わせる
monoidとかそういうの
ADTも実際かなり単純なものの組み合わせ
和と積ぐらいしかない
ほったらかしにしてる
この辺をちゃんと整理しておきたい