雑

思いつきのメモ

謎タイムライン

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

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

実際切ってる

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

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

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

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

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

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

頻繁に自分の目に入る

雑に書ける

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

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

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

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

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

簡易ツールの扱い

こういう要求

PC跨いでも使いたい

シュッとアクセスしたい

永続化されてほしい

↑コレに対して、dev環境を用意すると、一応満たせるのだが、

schema変更に伴うmigrationがだるい

dev環境に加えてlocal環境も用意する必要が生じる

となって、地味に結構面倒くさい

localhostから繋ぐ

user scriptをlocal serverと通信して処理できないかな？

userscriptはgitで管理して

cosense上でアクションを起こした時に、

local server上で処理して書き換えるとか、

どこかからコードを取ってきて処理するとか

できないかな？csp的にムズいか？

例えばmarkdownをcosense記法に変換するやつ

外部の何らかの関数を実行した内容を戻すみたいな

プロと他ピング

v0で作るとUiによってしまう問題があるな

時間が無限にあると爆発する

時間を測って時間で区切る

全てを満たしたくなる

全てを理解したくなる

そのせいで本質的な部分が遅れる

↑これが起きるの、

自分の能力を過信しすぎ？

あるいは時間的なゴールを意識しなさすぎ？

なんというか、何らかのリソースがめちゃくちゃあると錯覚しているせいで起きていそう

あまり集中できないとき

この辺が原因そう

具体的な方針が決まってない

やることが多くて錯乱している

「今日やること」をかなり具体的に落とし込めるといい

何も考えずに実行できるぐらい、かなーり具体的にする

こういう順序

理想論を考える

道を考える

最速で価値を生む道を考える

とにかく「今必要なこと」にフォーカスする

マルチタスクできるがゆえに爆発してる

それ、マルチタスクできるとは言わないのでは？

時間をかけて良いものを作れないなら、時間を短くしても作れない

サイクルを回すとかの話はあるが、そういうことではなく

知見があるサービスのLLM.txtを読むの良いかも

contextの調整

contextが増えると阿呆になる

部分的にアイディアを検証する

contextが増えてきたら、上記のやり取りをすべてまとめて再生成するプロンプトを考え直してもらう

コンテキストをリセットしてそのプロンプトを貼り直す

いや別に負けてはないが

流行ってるやつは、1時間でも触ってみるというのを習慣づけないといけない

cursor

音声入力したい

figjam mcpある？

cosenseの箇条書きを一つのアイテムとしてfigjamに移行したい

別にmcpである必要はないが

youtrackのコピーがダルい

拡張欲しい

copyがdotfilesに入ってないの不便

cargoはhome-manager経由で入れてないのでcargo installでもはいらん

cliでシュッとtiktoken計算してほしい

ウェブにもあるがでかいファイル食わせたりしたい

ブラウウザとかの履歴、アクセスした時間よりも、タブを消した時間で見たいことが多い

e.g. next.jsのdocsを順々に読んでいく時

サイドバーから1つず読んでもよいが、リンクを飛んで脱線することもある

これを繰り返すとにどれが既読でどれが未読かわからなくなる

また、一通り読んで半年後、また新たなコンテンツが増えているが、どれが増えたのかぱっとわからない

優先順位の判断の軸

他者が関わる

全体効率が上がる

他者が関わる

現在の影響がでかい

継続的に影響がある

誰かと協業する際に、next actionとして立項するコト自体が面倒だな

思いついた瞬間にslackでメンション飛ばすとかそれぐらいの速度感の方が良い

その日updateされたcosenseページをまとめてピックアップして読みたい

社のcosenseはバンバン更新されており、全てを追うのは今のところ現実的でない

文脈知らないものも多いため

それでも、目を通すだけ得、というものは多いハズで

ピックアップ

また、可能ならその要約なり何なり、

というのを仕組み化したい

可能であれば社で共有すれば有益

これはpocketで感じている課題と同じっちゃ同じなので同時に解決できるかも

ただ要約するだけでもダメそう

個人private pageで構造化するとか

積極的に茶々入れて関係を作るとか

そういう取り組みは必要そう

一日経って、まだノイズがおおいきがしてきた

他者の課題をなぞるな、自分の課題にせよ

メンバーの数を減らせばマネジメントは楽になる

と、直観的に思う

では、一つのチームのメンバーを小さくすれば良い、となる

しかし、これって、根本的な解決をできていない気がする

問題の所在を数にのみ追求している

仕組みの部分に目が当てられていない

したがって、スケールしない

小さいチームがたくさんできたら破綻してしまう、うーん

「楽になる」の部分をもっと掘り下げないとね

何が辛いんですか？

新たな概念をおもろいと思えるか

こういうのが大事

既に考えたことがある

既に知っていることと近い

エジプトに行って、歴史の話を聞いても、正直、へぇ〜、としかならなかった

なんでそんなに昔の人のことを知りたいのか共感できない

それ知ってどうなるんといった気持ちになる

自分の中の何とも結びついていないせい

まあ、歴史をおもろいと思った方が良い、という固定観念はやや権威主義っぽいものもあるので、

お前がおもんないと思うなら別にそれでええんでは、みたいなのもある

おもろいと思えたほうが得だとは思う

勝手に消さないでほしい

https://gyazo.com/3a5e13e7a4c2d3603a6f4b5d80e3a3c2

代替作る？

薄く学ぶ拡張

Chromeで文章を読んでいる時に不明な単語が出てきた時に、フォーカスしてgptに説明させる

どれぐらいの規模感で説明してほしいかを簡単に指示できるインターフェイスを用意する

回答を待たずしてどんどん追記できるようにする

追加でチャットしたい場合は、chatgptなどのページへ移行する

cosenseに転機するボタンを用意する

結果をcosense記法に変換して、新しいページを作って転記する

理解の幅とベクトル

チーム開発で、実装速度をどれだけ上げられるか、を考えた時、

結局どこまでの範囲を理解しているか、に終着する

何かの機能を作ってと依頼された時に、

何かデザインの細かい要件を聞きそびれて迷ったりする

この時に、デザイナに確認を取ったりする

ここでコミュニケーションコストが発生する

本来は、これをデザイナに聞くのはベクトルがおかしい

自分で最適なデザインを考えようという話である

それができないと感じるのは、顧客理解が足りない、デザイン知識がない、といったところに起因する

じゃあそれは、次回までに準備しておこうねという話になる

障害が起きた時に、どう動けばよいかわからない

インフラの構成がどうなっているかわからない、権限があるか、といったところを理解してないと何もできない

障害対応は、長く考えることができない

準備する、事前の経験、事前の理解が重要になってくる

何をすればわからないときは、今回は何の役にも立たないので、次回どうすべきかを考えて、そこまで備えるしかない

外の会社を見たときのギャップは事細かにメモっておいても良さそう

継続的に

環境を変えることと替えないことの比較をする

さすがにprivateに

これ、うんうん考えても結論が出ない

考えるんじゃなくて、それっぽい仮説をいくつか出してみる

さっさと作ってそれを検証する

提案もできない

クライアントも優先順位を評価できない

作りたいと思って爆速で作れるようにしておくこと、

バグっていると気づいた時に爆速で修正できるようにしておくこと

この辺がプロダクトをやっていくために必要で

そのためには、

いわゆるコードのきれいさとか

どういうツールを採用するかとか、

そういうのが大事になってくるんやなあ

大事なこと」の、ハードルをとことん下げること、その仕組みを作ること

情報の取捨選択

Pocket、RSSを全部読もうとするのはだめだ、優先順位をつけたい

今読む

今要約を読む

後で読む→cosenseへ

読まない→捨てる

課題はモノなのかコトなのか

課題は属人性が在る

これを使えば、自動議事録取れたりしないかな

人間とAIが手直しする

便利の深堀り

ないと業務を遂行できない

代替策がある

対して大変ではないが頻度が多い

できるが、気持ち良くない

連鎖しているPRのレビューが面倒

rebaseしてforce pushしてCIが終わるのをPRごとに待たないといけないのどうにかできないかな

前からレビューして、後ろからmergeしていけばいいのか

レビューの順序、1→2→3→

このとき3のdiffは2と3の差なので

4を3にmege,　3を2にmerge, .. , 1をdevにmerge、という順番でmergeする

いちいちCIが走らない

いやこれactionsの指定の問題か

これの問題は、1のPRに、最終的に1~4全てのdiffが入ってしまうこと

あとからPRを見た時に、でかい

個人開発、もっと人のアイデアをパクって自分で使ってみるべきか

アイデアを過大評価しすぎ？で誰かやってたらやる価値ないか、となりすぎ

別に俺が思いついた！と言ってイキるわけじゃないんだから、自分の生活を良くするためにパクれるものはパクるべき

2つ指定するかどうかでarrrayかどうかの型が変わるの渋い

code reaidngを補助するツール

トップダウンに必要な情報を削ってAIに渡せればいい

最初はディレクトリ構造、モジュール、その命名から、

やや具体性を上げて、関数名、型などのシグネチャ、..

のようにスコープを調整しつつ、AIに読まれる情報量をコントロールする

トークンを削る

可視化、解説、どこを重点的に読むべきか、はAIに任す

経験が足りない

そういう分野をできれば個人開発でカバーしていかないといけない

nosqlとか甘い

ディスプレイの数が減ると効率が下がるの痛感する

画面サイズ、ディスプレイの数大事

カジュ面を受けると

この会社は絶対ないな、と、受けても良さそう、が割と明確に感じる

その差はなんだろう？

候補者側に興味が向いているか？というのも近いかもしれない

会社紹介をメインにしていると、

ただ上から言われたから紹介しているだけ、別に候補者にそこまで興味はない、という風に感じるのかも？

候補者側もアピールが必要なのと同様に、企業側もアピールが必要

顧客の気持ちを理解するのと同じ

でも、知られていない企業はそういうことを調査すること自体が難しそう

なぜうちに魅力を感じないですか？の回答自体が難しい

また、それを改善するのも難しい

ペルソナみたいな

それはミッション・バリューとかに表れるか

相手が思い通りに動かない場合、たいてい自分が悪い

思い通りに動いてほしいという解釈がおかしい

相手が動くように何か促すべき

マネジメント

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

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

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

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

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

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

視認性を上げたい

パッとみで理解したい

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

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

エラー率 (誤認率)

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

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

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

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

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

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

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

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

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

なんだろう？

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

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

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

それいいですね、的な

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

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

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

しかし、

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

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

etc.

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

あるいは別のライブラリ

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

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

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

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

具体的な構造

class

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

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

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

雑だが

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

機能過多

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

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

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

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

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

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

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

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

MVP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

denoのryとか

rubyコミュニティとか

どうなんだろ

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

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

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

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

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

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

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

cosense, vscode, notion, ...

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

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

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

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

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

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

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

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

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

そう考えれば、

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

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

タスク同士の関係

包含

時間的な依存

抽象度

計算のモデル化

そろばん

配置として記憶する

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

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

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

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

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

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

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

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

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

伝え方、の問題もある

業務の中の危険信号

発表のネタが溜まらない

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

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

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

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

etc.

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

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

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

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

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

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

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

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

髪を切る時の、なんとか

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

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

会社の部署(?)、

価値創造隊

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

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

作業遂行隊

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

ノイズ取り除き隊

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

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

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

みたいなのがある

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

分類が↑雑すぎ

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

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

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

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

pintcle読書会に参加すると

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

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

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

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

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

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

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

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

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

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

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

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

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

採用試験

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

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

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

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

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

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

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

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

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

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

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

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

例えば、何かを開発するときに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に着目する設計手法があったりするわけだし

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

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

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

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

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

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

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

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

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

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

PBFは構造の一面の表現

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

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

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

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

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

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

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