雑

思いつきのメモ

謎タイムライン

このページを膨らませるのは良くない自覚はある

最終的に個別のページに切ろうと思ってる

実際切ってる

Twitterに書くよりはマシだろう

適度にページを切っていく

そもそもページを切って書けやという話もある

タイトル付けるの難しいんだよ

長く考えたいことを残しているというのもある

ここに書くことのメリット

頻繁に自分の目に入る

ここに書くことのデメリット

上部の検索バーから書き始めずに、ここを開いてから書き出すので、既存のノートに近いものがあることに気付けない

仮にこのページをどこかから参照されたときに、(そのうち移動するので)リンクが切れやすい

一定期間目に入るところにおいておきたい

優先順位というのはすなわち、お前のできる能力の範囲で最も大事なことを白という感じ

能力が上がれば、同じ時間でも大きい成果を出せる

関数型プログラミングは、この隙間が比較的小さく書ける感じがある

型のおかげなんだろうか

それもあるけどそれだけじゃないと思う

合致する組み合わせをすれば、基本合っている、みたいなイメージ

宣言的な書き方もそういうイメージ

インフラも宣言的に書いたほうが隙間が減る

手続き的に書くと隙間が増える印象

順序とか状態とかに依存する

目的以外も書かないといけないなら、それは注視すべきものが増えるということなので

Dockerでnetworkをごにょごにょするのはバグの入り込む隙間が多すぎる

Containerの起動ができているか、

Containerが起動できていたとして設定や読み込みが完了しているか

例えば、mysqlのでかいdump fileを読み込まして起動すると

起動は完了しているように見えるが、dumpをすべて読み込むまで数分かかる

この数分を待たずしてSQLを実行するとエラーになる

この時、そもそも設定がおかしいのか、待てばokなのかがハッキリしない

Container間の通信がうまくいっているか

etc.

この感覚の解像度をもうちょい上げたい

flakyさがない、とか

動くなら動く、動かんなら動かん

全部自分でできるようにする

実際にできるかどうかは置いておいて、そういうスタンスでいるのは大事そう

会社で言えば、インフラとかデザインとかもそうだし、経営とかマーケとかもそう

自分より何かできる人がいるなら追い抜くつもりでいて、

誰かが作った仕組みがあれば、作り直せるようにある

チームメンバーの全員がそういうスタンスであるのが理想ではある

それも個々が0から学ぶと時間が掛かるが、

先にそれに詳しい人がいれば、その人がポイントを伝えれば効率が良くなる

他の人に頼まないと進められない、他の人が作ったから仕組みがよくわからない、という状況をなくす

なにか新しいものを見たときに、気に入らないとなった時

旧来の考え方ではなく、別の軸で評価して潜在的な価値を探す

たぶんスライドを作るときとか、本や記事を書くときにも役立つ

あとの章で出てくる重要な単語の要素を、最初の章でしれっと出しておく

情報量が一気に来るのがしんどいので、それを分散させて徐々に学ばせる

出会う回数を増やす感じ

1回1回は薄い

文章内で見かける「これは後述する」とかもちょっと下手な同じこと、という感じ

書き手が楽している

後述する、ってできればあまり言わないほうがいい気がしている

教育

テキストでコミュニケーションが取れること

かつ読めること

これはかなり優先順位が高いと思われる

なんで？

主体的に学べる状態にする

学び方を伝える

それが身につくまでは

具体的に指示をする

関連する要素を減らす

例えば、最初から、ts, reactが複合するようなタスクを与えない

tsの知識だけ、でできるようなものを依頼する

できてきたら徐々に抽象度を上げる

特性にも依るけど、

最終的にはマネジメントできる人、自分の分身、自分以上の人を育てる必要がある

感覚的でわかんねえじゃんというやつも繰り返すことでわかってくる

例えばマーケティング

顧客が何考えてるかわかんないよ~

例えば転職活動

どういう内容を書けばウケるのかわかんないよ~

例えばスライド発表

こういうのも、無限に試行を繰り返せるのだから、何回も繰り返して掴んでいけばいい

最初の方は、そもそもどういう軸があるかさえわからないだろうけど

徐々に軸が見えていき、ウケづらい部分、ウケやすい部分が見えてくるはず

その中で、前者を他のものに変えたりし、後者を残し、というのを繰り返す

これが、振り返り、というやつか

逆に言えば、前回の反省点を活かさずに次に挑んでも全く意味がないとも言える

できれば、定量的な指標を見いだせると良い

次にそのサイクルをいかに高速で回すかという話になる

マーケティング施策の場合は、施策の早期から実施までのリードタイムを減らす工夫が求められる

実装の場合も同じで、新機能を思いつく、さっさと作って公開する、ウケたかどうかを分析する、改修する・消す、というのを高速で行う

プログラミング初期の難しさ

まず、動くものを書くことに対するハードルがある

書く前に、こういうものを組み合わせればできるな、というのが見えない

そもそもどういうパーツがあるのかを知らない

例えば、array操作のfilterとかそういう感じの小さいパーツ

動くものが書けるようになってからも大変

何かのlibraryを使って、実装していく中で、難しいなあという気持ちになる時

難しい理由が、自分の能力不足なのか、要件がおかしいのか、道具がおかしいのか、がわからない

有名で、よく目にするlibraryだったとしても、適用対象がマッチしてないとか、単に有名なだけで実際はダメとか、色々原因がありうる

アーキテクチャとか設計手法とかも同様

あとから良いツールが出てきたというのもあるが

道具に対する審美眼を培うことはかなり重要

ではどうやって培うのか....

最低限、触れる量を増やすのは必須に感じる

できるだけ遠い思想のものをいくつか触って体得するところまで行く

既に存在するものはだいたい押さえておく

それでもなければ自分で発想する

言語で言えばパラダイムが異なるものとか

道具のコンセプトを早く理解できれば、時間を短縮できる

新しいものに触れる

どういう課題を解決したのか、何が新しいのかに着目する

微妙に感じるものの理由をメモっておく

なんで微妙なのか、どうすればいいのかを考える

問題にぶち当たったときに、全く違う方針で考えてみるとか

量に頼らずに培うにはどうすればいいのだろう

小学生ぐらいの人に教えるならどうするか

いっぱい見ると良いよ、ってアドバイスとして面白くない

戦っているゲームのルールを把握する

特にエンジニアやデザイナで具体的な視野になっているとなりそう

もっと、経営目線(?)でみると、そもそもその機能に時間を割くより、

UXダメでもいいから、この課題を解決する機能を追加すべきだよね、

という意見を出さないといけなかったりする

Cosenseの多くは「自分のために書かれている」のが良い

↑Cosenseの個人プロジェクト

Twitterもブログも「公開するために書かれている」「誰かに読んでもらうために書かれている」ものが多い

表現を自分の中に取り込んで、メンタルモデルを構築して、再び表現する感じ

例えば、LLMが回答したコードをリファクタするとき

挙動としては正しく動いているものの、コードの構成に違和感があるとき

そのコードの表現の仕方がおかしいということ

表現を読んで、自分の中に取り込んで、

自分の中で構成し直して

再度、コードとして表現し直す

文章でも同じ

例えば、本に書いてあることや、LLMの出力した解説をメモするとき

例えば、誰か他の人が作った文章を修正してサービス上に公開するとき

その文章を抽象化して、意味を自分の中に取り込む

そこで使われている表現や文章の流れはいったん放棄することが大事

そして構成し直して、再度、文章として表現し直す

概念の分節

理解とはそういうこと

プログラミングの場合はモデリングが必要になるから、半ば強制的にそれをやる必要があるだけ

生きていくうえでそもそも大事な取り組みという感じもする

プログラミングとか関係なく

タスク依頼とか同じ

モジュールの話？

関数型パイプラインと本質

なんか入れ子構造みたいなやつをループするときに

その計算の本質を見つけて小さく処理して組み合わせる

というのをやると自動的にパイプライン的になることがおおい

共通化と抽象化の待ちのトレードオフ

将来的に同時に修正したいから、という理由で共通化したい

共通化していれば1箇所直せば、直し漏れがない

変な抽象化をしたくない

変な抽象化をするぐらいならインラインで書いている方がいい

余計に分かりづらくなる

上記2つがコンフリクトする

「良い抽象が発見できないもの」でほぼ同じものが2箇所以上現れたとき

どっちかを捨てるか、さっさと発見するかしないといけなくなる

抽象度を下げる

最近やったこの辺のリファクタの体感が良かった

元のコードは2ヶ月ぐらい前に自分で書いたもの

元のものはかなり抽象的だった

そもそも扱っている問題が複雑で、その抽象でカバーすべきものも多かった

設定ファイル的なものを流し込んで内部でよしなにやるというもの

体感として難しくて、やや嫌気がさすものだった

一部のケースでバグが発生するが、その修正も乗り気になれない

設定ファイル的なものを扱う場合は、その設定の範囲の全ての組み合わせをカバーしないといけない

もう少し具体性を上げたものに書き換えた

イメージとしては、DSL的な道具を提供して、個別にロジックを書いてもらうようにする

(全然DSLではないが書く前のイメージ)

利用側がいくつかの分岐のあるロジックを明示的に書く

これはかなりコードの可読性が上がる

3重ぐらいに重なる条件が明示的に記述されるので意味がわかりやすく、メンタルモデルと一致しやすい

本題と関係ないが、インターフェースが良かったので、内部を書き換えるだけで済んだのも気持ちが良い

また、今回は両ケースで多少の妥協をしている

要件のすごい細かい部分をカバーしていない

その場合も、具体性が上がったもののほうが、どこを妥協しているのかがわかりやすい

その要件も必要だよねとなったときに、どこを修正すべきかが明確になる

今回の良さを他にも活かすなら、

その分かりづらさの原因が抽象度が高いことにあるのなら、下げてみるアプローチも考えみる、とかか

最近、経営(?)周りを見るのも面白い

割と、面白ければ何でも良い、という感じもしている

ただ単に、プログラミングは面白さの極地にある、というだけ

結局は、会社にとって一番インパクトの有ることをしたい、というのがあって、

それがどの部分なのかを模索したいだけ

それがテックならテックをやるし、そうでないならそうでないことをしたい

データ分析とかは、テックと経営のわかりやすい中間地点という感じがする

徐々に広げていくためにはそのへんを通過するのが良いのかも

良いインターフェースを考える、という点においては

マネジメントもテックもあんまり変わらなくない？みたいなことを最近感じている

ユーザも、社内のメンバーも、自分も全部同じ

やりたくない作業はやりたくないし、面白い作業はやりたい

意味不明なことを言われたらムカつくし、親切にしてもらえたら嬉しい

それを他者に対して、自分に対して、行っているだけ

良いインターフェースを作る、爆速でコミュニケーションを取れるようにする

相手側の思考を考える、相手がよく動くようにする

何かやりたいことに対するノイズを除去していく

相手の理解に合わせて情報を与える、タスクを与える

課題を見つけて潰していく

という取り組み

読む本の優先度付をちゃんと考えたい

ここから、

本のグルーピング

今の仕事や生活における重要度

これがかなりリアルタイムに変わる

興味がかなりこれに引っ張られる

業務系に関心が移動しているときは、設計系の本を読む気にならない

その分野に対する今の理解度

ページ数、

作者、出版社、評価

などから

今一番読むべき本、みたいなのをはじき出したい

色々要件がある

読まなくて良い本を弾きたい

ロジックとUIの分離

やはり体感としてUIの修正が多い

その時にいかにロジックを触らずに完結できるか

抽象を扱う

データと操作を分離する

操作を分類する

public methodの方がprivate methodより抽象度が高い

故にこれがinterfaceとなる

OOPに登場するclassやinterfaceなどは、こういうコンセプトを基に表現されたツールである

近くで会議をしている声が聞こえる

自分は参加しておらず別のことをしている

発言していない人もいる

少数の人が主導しがち

いろんなアイディアが出るものの、まとめる人がいない(?)

それをそのまま実装に落とし込むとちぐはぐになりそう

課題(抽象)と機能(具体)がごちゃまぜになっている

機能を発想し、それについて発言する

どういう課題があって、それに対して他にいくつもの機能が発想できるという可能性が削られてしまう

時間がもったいない

情報収集のための参加というのもある

何も知らないのでとりあえず参加して聞いている

でもそれは録画したやつを倍速で見たり、文字起こしの要約を見たほうが早い

情報収集のためだとしても、何がわからないのかを先に準備しておいて、その場でどんどん質問すべき

道具の抽象度を考える

コードもそうだし、

サービス自体も同じ

意味のないものを作らない

要件を満たしたうえで、体験を良くする

優先順位は比較的表層に近い

つまり具体的

何段階かのレベルがありそう

そもそも列挙されているタスクの質

そのタスクの根本の要件に対する優先順位

また、実装コスの加味

タスクをフラットに並べて「優先順位を考える」というのは、たぶん考え方がおかしい

完成されたUIの表層だけを見て、価値を判断している感じ

中身、内部の構造に目を向けられていない

だから間違える

不要な情報量が多い

必要な情報にアクセスするまでのノイズが多い

継承ってそもそも何がしたいんだっけ？

また復習しよう

ポリモーフィズムをやるための一手段という立ち位置だっけ？

正解の使い方をしたときに何がどう嬉しくなるのかを忘れた

https://gyazo.com/f9fdd9fd595b01ed79d78e021a4ba4ca

Gyazoの画像ロック.icon

操作もコンテナと引数みたいにすればよいのか

reducerのeventみたいな感じで、

具体的な構造をラップする構造

をinterfaceとしても作る

目的の値部分は多相にする

例えばこんな

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レベルの差し替え

実体ではなく機能にフォーカスし、実装を差し替えられる

境界分離　

影響範囲の最初かと切り離し容易化にフォーカス

モジュール同士の境界

なんでだろう

「機能」って呼んでることに違和感があるのかも

「目的」に着目することが、

「操作」に着目することに繋がり、

結果的に、「抽象」の発券につながる？

https://gyazo.com/8d801aad1d0d3eacf72c39d92e15dbba

確かに、具体と抽象と、手段と目的を重ね合わせてみれば、

抽象を発見するために、目的に着目するのは意味がありそうだ

この辺の話おもしろい

https://gyazo.com/d5c0575a7fab6df7e30d735487443618

ものとしてモデリングすると低凝集になりがち？

https://gyazo.com/928e19171bf6cae728f9bbd694f7eb4f https://speakerdeck.com/minodriven/buisiness-purpose-system-design?slide=67

これ、そうなのだろうか？

わかる気もするが、根拠も乏しい

タイトルの「ものとしてモデリング」というのは、

「モデリングするときにモノという単位で考える」という意味だと思う

こっちを深堀りしたい

実際、eventに着目する設計手法があったりするわけだし

登場する概念をバーっと列挙して、適当にグルーピングして、

その中で持つべき特性、ふるまいのようなものを洗い出す

オブジェクトはネストになってるかもしれないし、そうでないかもしれない

それはあまり関係なく、とにかく振る舞いを洗い出す

これがインターフェースになる

しかし、そのふるまいの返り値の構造はどうやって決めるのという話もある

そのオブジェクトの構造に依存したものになるのか、振る舞い側が規定したものになるのか

理想的には後者になるべき

なんというか受動的すぎる

だから、Xで何かを宣伝するのも的を射ていない気がしてきた

誰に伝えたいの？誰にフィードバックしてほしいの？誰でもいいわけじゃないよね？あたりが考えられていない

主体的に臨むなら、ちゃんと特定の人物に対して「これについて意見をください！」と言うべき

ということは、その特定の人物と話せる距離にいるのが良いわけだが、

その特定の人物って誰やねんというのがある

イマジナリー強い人みたいになってる(なってない)

謎の承認欲求みたいなものの、本当の欲求をちゃんと探るべき

整備されていない環境を整備しつつぶちあげることと、

誰かが整備した心地の良い環境でぬくぬくやること

自分の能力を一番ブーストできる環境を考える

チームメンバの感じ、業務の内容、技術の種類、裁量、など

転職前にすること

明確な成果を上げる

他の人を全員超える

その会社特有のちしきをえる

例えば物流、倉庫など

知名度を上げる活動をしていくべき？

というのを漠然と思う

掘り下げを仕様

何のために

何が嬉しい

本当に達成したいことと知名度は関係ないのかもしれない

もっと効率的で直接的な方法がありそう

PBFは構造の一面の表現

MVP自体にもUXは大いに含まれるだろう

新しい機能を、何のスタイルもしていないボタンを1つ追加すれば、機能自体の有用性を測れるかも知れないが、

それによって、元のサービスの世界観が壊れたら台無しなわけで

アクセシビリティなどが後回しになりがちなのは、それの優先度が低いと判断してるからに過ぎない

MVPの篩からは振り落としました、というだけ

対象のユーザがそれを最も必要としていると知っていればそれの優先度が上がるだけ

MVPという方針を取っている以上、最初に含まれないのは仕方がない(?)

UIを考える頭と設計を考える頭は割と違う気もする

ここのスイッチングを1日の中でやるのはあまり良くないかも

日を分けたほうが良い気もする

決まったルールで自動生成する

性質を捉える

汎用的なものを組み合わせる

monoidとかそういうの

ADTも実際かなり単純なものの組み合わせ

和と積ぐらいしかない

ほったらかしにしてる

この辺をちゃんと整理しておきたい