雑

思いつきのメモ

謎タイムライン

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

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

実際切ってる

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

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

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

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

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

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

頻繁に自分の目に入る

雑に書ける

書いている時点ではまとめる気がない、まとめる時間がない時

仕事中にパッと思いついて、単に頭の中身を出力する時とか

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

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

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

こういう系の要望は、微妙に評価がしづらい

こういう機能がなくて、これができない、という課題は、機能を作れば

使いづらいとかはあるかも知れないが、「これ」はできるようになる

文字を大きくして欲しい、などは

そのまま捉えると、何ピクセルまで大きくしたらok、という基準が分かりづらい

そのまま捉えなかった場合でも、要するに

視認性を上げたい

パッとみで理解したい

といったところになるが、定量的に示しづらい

多くの人が使っている場合は

エラー率 (誤認率)

読んで理解するまでの時間

とかで定量化できるかも知れない？

お利口さん

慣習・思想に則る

これの本来の目的は、

それに沿っていたほうが、問題が起きづらい、将来的な変更で影響を受けづらいってだけ

だから則ること自体が正しいわけでもない

偉い人がいったパターンを取り入れる

プロダクトづくりの感覚と、ライブラリづくりの感覚

なぜか今までここをあまり関連付けて考えてこなかったな

プロダクトづくりはニーズを満たすものを作っていく感じ

ライブラリは発見した抽象を切り離して再利用できるようにするイメージが合った

何故か自分の中でここが少し分断していた

初期のLinuxの設計とかする際に、ニーズがあるから、みたいな考え方ってあったんだろうか？

エンジニアが技術目的で良いものを作るのと、経営者がサービスを作るのって、なんか感覚が違う気がする

なんだろう？

今まで働いてきて、このチームが良かったとかはありますか？またその理由は？

自分の質問に対して、相手が答えてくれた後の返答が難しい

無難に「ありがとうございます」で終わらしてしまう

なんか良い感じに感想を言えるといいけど

それいいですね、的な

話す前に、その企業の復習をする

例えば、ミッション、バリューとか

2024,2025

振り返り

抱負

上に決められたことを遂行すると、自分ごとにしづらい

読んでも読まなくても良いが、読みたいなら読みたい状況にあること

会社の全体ミーティングとかで決定事項のみを話された時に、納得感がないことも多い

かといって、わざわざ発言して、どういう過程でそういう決定に至ったんですかと聞いても長くなりがち

決定者もわざわざ何回も回答するの面倒だし、決定したことをひっくり返されるのも面倒

ci の設定ファイルとか全部copilotに作らせればいいのでは

ライブラリと手動作成のバランス

作ることを目的とするなら、高速で作りたいので、ライブラリはどんどん頼っていくべき

しかし、

ライブラリのメンテがされてない

そのライブラリで賄っていた範囲を超えた

etc.

のようなことが起きたら即座に手動実装に移行できるようにしておくべき

あるいは別のライブラリ

ライブラリに依存することの問題点は、突き詰めるとすぐmoduleの話になるはずで、

moduleのことを考えれば、ライブラリ使用の問題はほぼほぼ解決できそう

価値に繋がらないものを作ったらアウトになるハッカソンみたいなのあるとおもろい(おもんない)

手癖でなんかかっちょよくしたくなるのをツッコミで防御される

というか、開発と分けている意味がよくわからない

初期デザインを何で作るかみたいなやつ

道具の話

頭の中にあるデザインを、どれだけ高速に、どれだけノイズ少なく出力できるか、というところ

コードを書いて出力する場合、

頭のデザインを、コードに変換して、出力するため、1ステップ増える

コードは形式的だが、直観的ではない

例えば、普通のwebデザインとは外れた特殊な配置をしようとすると詰まったりする

ただまあこれも、単純に、その人がhtml/cssを完全に道具化できてないだけ、という可能性もある

道具側がそのイメージに対して適切な抽象を持っていない、という可能性もある

html/cssはprimitiveすぎるというか

イメージを作る時に、細かく座標がなんぼとかどうでもいい

繰り返しがどうの、コンポーネントがどうの、とかhowがhowすぎる

また、

コードの良し悪し

デザインの良し悪し

の2点を気にする必要があり、これは「デザインを考える」という目的に対してはノイズである

デザインに対して評価をしたいので、コードの良し悪しはどうでもよく、そもそもコードは必要ない

LLMを通しても同じ

デザインを自然言語で説明して伝える必要があり、1ステップ増えている

自分の語彙がショボいとLLMが意図を汲み取ってくれない

それよりも、直感的に、手動で図面を動かして配置や色などを変えるほうが直感的、ステップが少ない

頭の中のものをそのまま出力できる

それも別にFigmaのようなツール側で吸収できるなら関係ない

具体的な構造

class

汎用的に使えるが、抽象としては具体より

ただ単に汎用的に使える、というだけであって、汎用に適切に使える、というわけでもない

classという10のインターフェイスをもつ機能の内の3を使ってControllerにしてる、みたいな

雑だが

状態を持ってないのに、methodを持ってないのに、classという構造で表せるから表しているだけ

機能過多

classという構造自体が、単一責任(?)でないみたいな

逆に、無駄に汎用に使えてしまうせいで、全てをclassで表現する、みたいな変な方向性が生まれる

それなら、データ構造と関数といったもっとプリミティブなものだけを提供して

それを組み合わせclass的なものエミュレートできるようにしたほうがいい

class的な物が欲しいときだけそれを使えばいい

これも結局インターフェイスの話

プログラミング言語自体のインターフェイス

プロダクトの差別化、強み、競合

コミュニケーション

忙しい、プロジェクトの掛け持ちが多すぎると、時間をとって話ができない

プロジェクトが崩壊する

非同期コミュニケーションならいける

この辺全部同じだなあ

オンボーディング

コードの可読性

使用しているツールさえ理解していれば、人に聞かなくても意味がわかる状態になっていること

理想を言えば、ツールの理解も甘くても、意味がわかること

コードで説明するか、それが無理ならドキュメントで説明するか

最小の時間で最小の良いものを作る時

MVP

何のツールを使うのかはかなり重要

同じ目的達成も、primitiveすぎるツールを使うと無駄に時間がかかる

コード書いている時に

それと同じような関数、すでにあるぞとか、標準ライブラリであるぞ、みたいな突っ込みをAIにして欲しい

定義済み関数に対しても類似とか

似てるやつないか聞けるとか

自然言語でも、型でも

grepは名前を覚えてないと探せない

ast-grepも形式的すぎ

根幹のEntityらへんのモデルの構造がおかしいと、それの上に作られる全ての構造がおかしくなる

組織の構造もこれに似ている気がする

特にトップやコアメンバーがそれに当たる

構造の中核、数学の公理みたいな、スタート地点の筋の良さ、みたいな

めっちゃ良いサービスでも、使い始める直前のハードルが高い

良いと知ってても始めるハードルがある

めっちゃ良い文章でも、読み始めないと良いとわからないのに似てる

この人が書いた、バズっている、いいねが多い、みたいな箔がないと読まれない

ペイ系サービスの流れを見たい

OSS、技術コミュニティにも文化がある

文化のコアが一人に依存していることも多い

ちゃんとコミュニティに伝搬できているところもある

denoのryとか

rubyコミュニティとか

どうなんだろ

「コミュニティ」に関してはあまり関心なかったが、

「企業」と関連付けて考えると興味が湧くな

もっと簡単にオレオレエディタを作れるようになるべき

htmlで標準にあるAPIがショボすぎる

エディタを作りたい人、みんなが同じようなところで詰まっているのでは

良いインターフェイスが発見されていない？

発見されてるけどシランだけか

cosense, vscode, notion, ...

自分にしかできないことをしたい、という気持ちもありつつ、それって何？というのもある

仕組み化することが好きな人は、荒野に行って仕組み化することが強みで

仕組み化して誰でもできる環境を作れたら、他の場所に飛び立つ、みたいな

仕事で作るプロダクトの、あるいは仕事そのものの、手段さ目的さを考えていて

漠然と目的なものがいいなと思っていたが

あらゆるプロダクトって、何かしらの手段で

目的に近いものもあれば、それも結局、人生という目的の手段に終着するから考える意味がない

また手段感(to B感)がある方が、道具感もあるし、インパクトという意味でも大きい

その道具が掛け算となって効果を生み出す

そう考えれば、

突き詰めると、課題解決と創発とプログラミングができれば、

割と本当に業種は重要でない気もしてきた？

タスク同士の関係

包含

時間的な依存

抽象度

計算のモデル化

そろばん

配置として記憶する

情報量が増えてるのに記憶できる

逆か、情報量が増えるから記憶できる

数字というのは極度に抽象化され、サイズが小さすぎて見分けがつきづらい

最も抽象的なものに辿り着く？

最初からデザインを作って実装をするというフローが根本的におかしい

LPみたいな、特に機能のない、デザイン比重の高いものならそれでもokだろう

コミュニケーション全般そうだよな

オンボーディング、ティーチング、タスクの依頼の仕方、etc.

本読んだり、記事読んで意味がわからないのも、それも大きい

伝え方、の問題もある

人生のネタバレと広げることの度合い

とはいえ、広がりがないと調べるキーワードがない、

APIの話をしている時に、雑談で

curl, Linux, CUI, 低レイヤ, OSSというところまで派生していった

後で振り返って、これ関係ないこと話しすぎたか？と思ったけど、まあ別にいいかとなった

それぞれの詳細はあまり重要でなくて、そういうキーワード、そういう世界があるのだよとチラッと頭に入れてるだけで、ボトムアップに構造が作られてくるのでは

業務の中の危険信号

発表のネタが溜まらない

創造がないことを意味する

新しい技術学びました！とかはあるかもしれないがおもんない

直近3ヶ月を振り返っても職務経歴書の厚みが出ない

転職ドラフトで何も上がらない

etc.

音楽で言うところのベース

「低音がいい」というモデル化

これって、人間が知識より先に感覚で捉えられるものなんだろうか

知識として「低温が大事」と一度聞けば、それを捉えられるようになり、その重要性がわかる

肌色を書く時に、まず緑を塗るやつ

緑を塗った後に、色を重ねて、最終的に肌色にするやつ

捕食を先に塗ると良い感じになる、というモデル化

料理を作る時の、なんとか

髪を切る時の、なんとか

素人が完成形を見た時、そこからモデルを推測しようとしても表面でしか判断ができない

周波数が何とかで、感覚的に感じているものはあれど、それをモデル化して再現することができない

スクボ読書のURLとページ数を2つ渡したら要約が返ってくるAPIを作りたい

更にそれがuser scriptで書けると便利

つまらん人間になってきた

というのを感じている

「良さ」の評価軸が生産性だけになっていてすごく狭く貧相

何か前にもこれ書いたな

創造がなさすぎるのか

社会をなぞりすぎているような

今考えているのって、タスク管理で、タスク管理ってありきたりすぎる

別にいいんだけど、面白いかと言われると面白くはない

課題のノイズが多いと発想というのがまず無理

なにかの課題について考え続けてふと発想する、という体験

プロジェクトがデカくて、そもそもの課題がどこにあるかわかっていないような状態だと、その準備段階にすら至っていない

会社の部署(?)、

価値創造隊

新たなアイディアを発想して価値を生み出す

e.g. 経営者(?)、発想のあるエンジニア、企画考える人とか

作業遂行隊

日々の発送業務とか、経理?

ノイズ取り除き隊

人事?、スクラムマスター的な人、仕組み化するエンジニア

リファクタリング業務とか

型やテストを頑張るのもここ

みたいなのがある

下2つは、良い道具を採用すればある程度なくせる

分類が↑雑すぎ

部署というかタスクの種類？

採用とか手段のための手段なんよな

なんか妙に自信過剰になっているので2年に一回ぐらいぶちのめされる体験をしたほうが良い気がする

環境変えるか、何かに飛び込むかして

副業、転職、社会人大学院、etc.

初見のコードを文字情報だけで解読するのかなり効率悪いな

文字情報というのは、コード、ドキュメント、ディレクトリ構造、など

やっぱり関係性が可視化できるのがデファクトスタンダードとして存在していて欲しい

形式的に解析しなくても、AIに丸ごとツッコんでAjaxばりに部分的に可視化するとかできんかな

複数の問題を同時に話しすぎて、コミュニケーションが無駄に複雑になっているのを整理していったらマシになった

機能もドキュメントも使われて初めて価値が出る

pintcle読書会に参加すると

自分が会社的な思考に染まりすぎてるのを感じる

仕事で成果を上げたとして、だから何なんだという気持ちも生まれている

今かなり視野が狭くなっている気がする

ギリ引き戻してくれる大事な機会という感じがする

人生における大事なこと、みたいなのを明確にしないとキャリアも職選びもクソもないな、と思う

話していてこの人頭いいなあ〜、って思う人

話してて「自分の考え方は具体的すぎるな」って気付かされる人かもしれない?

会社がやや大きくなってきて、(自分含む)初期メンバーはナチュラルに意識が高いのだなと実感した

後から入ってきた人と、根本的に向き合い方が異なる

しかし、これ、昔は自分もそうだったはずで、

どうすればこういう意識を伝搬できるのか、と考えると難しい

能動性、というのは必須でポイントになってくるのだとは思うけども

アートも技術力も幸福も全て資本主義に回収される

抵抗せずに傾倒した方が楽に生きれるかもしれない

そもそもアートや技術を信じているわけでもないし

抽象化？というか、本質を抜き出す能力？というか

データというものは、無限の軸で見れるわけだが、

その中から最も筋の良い軸で切って

最も筋の良い見せ方をすることで、

初めて正確な解釈をすることができる

これは書籍になどで紹介されるアルアルのパターン

例えば、売上ごとのヒストグラム、とかそういうやつ

練習の範囲ならそれで十分

しかし、実際のビジネスで使うなら、

あらゆるパラメータについての理解

収集しているデータについての定義がわかる、その質の評価ができる、とか

ドメインの理解

例えば、現状の売上だけを見て顧客をセグメントすることの何が問題なのかわかる、とか

直観による補助

さすがにこんな結果になるのはおかしい、前提がズレていそう、と気づけるとか

などを総動員して立ち向かう必要がある

よくあるパターンで可視化して、はいok、とはならない

ツールに対するりかい

分析の仕方に対する理解

分析して得られた数字に対する理解

経営目線で次のアクションが云々とか

モデル化能力

単純に、データ分析に対する構造が自分の中で構築できてないから過剰にすごくに見えているだけな気がしてきた

ドメイン理解したり、モデル化したり、表現したり、というのは別に同じやな

確率分布を腑に落としたい

知識として知っているだけ

実際のデータを適用してみて、あ、ほんまに従ってるやん、すごい、というのを一つずつ体感したい

採用試験

自社のサービスを無料で利用してもらって、課題を発見してもらうとか

「課題を発見すること」自体の能力を測れる

技術者として、一顧客目線で、市場などを加味した広い目線で、どういう視座で発見できるか

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

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

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

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

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

自分の中で構成し直して

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

文章でも同じ

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

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

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

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

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

データにおけるトップダウンとボトムアップ

例えば、データをマーケに活用しようというときに、

まずあるデータを見てから、解釈するよりも

こういう目的を達成したい

そのためには、こういう数字を見ればよいのではないか

既存にあるデータだとこういう組み合わせで表現できる

もし表現できないなら、別にこういう数字も取る必要がありそう

という順序のほうが良さそう(?)

プログラミングでも似てるケースがある

例えば、何かを開発するときにNode.jsを使おうとなったときに、

前者の場合は、Node.jsのAPIを全部見てから、作るものを考える感じ

データを見る、データを分析する、というのは手段

元の目的を別で達成できるなら別に見なくて良い

でも、先に網羅しないと手が動かないこともある

HaskellのList操作の標準関数の挙動をざっくり知らないと、

どういうものの組み合わせでできるのかが発想できないことがある

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

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

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

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

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

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

ロジックとUIの分離

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

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

抽象を扱う

データと操作を分離する

操作を分類する

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

故にこれがinterfaceとなる

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

道具の抽象度を考える

コードもそうだし、

サービス自体も同じ

https://gyazo.com/f9fdd9fd595b01ed79d78e021a4ba4ca

Gyazoの画像ロック.icon

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

reducerのeventみたいな感じで、

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

をinterfaceとしても作る

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

例えばこんな

code:ts

type Calc<Frill> = (

frill: Frill,

cutOffSize: CutOffSize,

count: BaseFabricCount,

) => CutOffFrillLength;

それをそのまま一弾挙げると高階関数ということになる

と言えそう

UIを考える時も具体的な値に着目しすぎない

要素の配置は手段である

グルーピング

ユーザの操作

行う順番、時間的

行う頻度、

状態の変遷を明示する

「注文」のような、同じものが状態が更新されていくのはイメージしやすい

一方で、それを捉えられていなくてだいぶ詰まったことがあった

入力が多めのアプリケーションで、

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も実際かなり単純なものの組み合わせ

和と積ぐらいしかない

ほったらかしにしてる

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