雑

思いつきのメモ

謎タイムライン

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

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

実際切ってる

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

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

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

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

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

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

頻繁に自分の目に入る

雑に書ける

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

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

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

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

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

アウトプットを測る質問

環境構築にどれぐらい時間がかかりますか

いや一概には言えないか

扱っている技術にも依るし

userscriptのパターンをまとめておきたい

というか誰かにまとめて欲しい

公開プロジェクトの何処かに書いとけば良い？

どういうAPIがあるのかの一般化や、使っている例を紐付けておいてくれればいい

ハンマーを持つ人にはすべてが釘に見える

〜〜〜〜〜には全てがreducerに見える

というくだらないことを思いついたが完成度が低い

就職は、

人の課題へのタダ乗り

人が作った文化へのタダ乗り

ただなのか？

Cosense上のメモに適度に批判、コメントしてくれるbotが欲しい

何も考えずに吐き出している部分も多いので、

一言「コレってどういう意味？」とツッコまれるだけで、

あ、考え甘かったです...というのに気付ける

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

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

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

伝え方、の問題もある

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

ドンドン結論を先回りして言ってしまうのは微妙

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

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

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

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

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

業務の中の危険信号

発表のネタが溜まらない

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

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

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

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

etc.

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

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

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

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

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

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

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

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

髪を切る時の、なんとか

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

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

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

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

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

というのを感じている

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

何か前にもこれ書いたな

創造がなさすぎるのか

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

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

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

今の自分が知り得る範囲で、最も効果がありそうな課題を見つけて、取り組むということの繰り返し

新規の分野でのプロジェクトに関わるときを考えるとその分野の知識は薄い

要件を考える最初の段階も同じ

調査などして調べるけども、どこかの時点でその効果が逓減していく

調査ばかりもしてられない

どこかのタイミングで作って、そこから新たなフィードバックを得られる

その、「どこかのタイミングで作って」のこの段階で何を作るか、という話をしてる

将来の変更の可能性を考えて、というのも経験や知識に依存するので限界がある

サービスを作ってる時のイメージで

会社の初期とか、サービスの初期とか、リソースが足りない時にまずすべきは優先順位の判断ということになる

最も解くべき課題を1つに絞れるかどうか

詰め込み型プロダクト

シンプルが良い、ということの実感

よく聞くけどこれを実感、体感をして得るのはかなり難しい

えっ、まじでそんなに絞るの！？みたいな

しかもこれ、ただ小さいことが良いのではなく、抽象化、軸が良いことが前提にあるから難しい

ただ小さくしただけで上手くいかなかったら、成功体験として得られない

メンバーは、ここもここもターゲットにしたい、これもこれも要素として詰め込めたい、と思いがち

それをメンター、投資家に伝えると、もっと絞ったほうが良いねとアドバイスを受ける場面がよくあった

ビジネス、マーケ、実装、どれでもよくある

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

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

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

会社の部署(?)、

価値創造隊

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

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

作業遂行隊

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

ノイズ取り除き隊

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

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

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

みたいなのがある

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

分類が↑雑すぎ

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

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

思い出せなくて適当書いてる

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

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

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

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

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

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

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

技術を目的化するの、少人数チームベンチャーでは無理

というのを思った

ビジネスの性質にも依るけど

売上が最優先になってしまいがち

高速で解決しないといけない課題が多すぎて

技術的調査とかをやっている暇が無い

その筋が良いかどうかは関係がない

メジャーな方針とは外れた構想を打ち出して、それを形にするまでの技術力と時間的余裕がある

こういうことがやりたいなら、他の部署が金を集めてくれているような中規模以上ぐらいの会社に行って、R&D的な部署に行くのが良いのかもしれない

プロジェクトの最初の方の進め方を覚えてないな

プロジェクトの存在意義、を確定させる

これをやらないことには、スケジュールもクソもない

やる必要のないもののスケジュールを組んだとて仕方がない

問題を分割する

moduleを分けて理解していく

一緒くたに話されると複雑になる、どれが優先順位の高い課題なのか判断できない

メンバーの能動性、活かすも殺すもトップ次第?

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

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

pintcle読書会に参加すると

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

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

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

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

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

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

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

初見でのメンタルモデルの構築が苦手？

そこができるまで一生理解できない

それを説明するための個々の語彙に対するモデルも作らないといけない

会社を調べる力をつけたいな

職探しのためにも、市場を知るというためにも

株とかやると、そのへんの興味も湧くのだろうな

だいぶ別軸な気はするけど

小さい会社を調べるなら向いてないし

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

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

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

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

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

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

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

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

人生はメタ学習、モデル化

というのがわかってきつつ、それはそれでおもんないなという気持ちになってきた

知的生産力を頑張るというもの

子どもが生まれたらそういうことを早めに身につければ良さそうだな、とか思ってて

学校の勉強にしても、運動にしても、趣味にしても、恋愛にしても、

結局、メタ学習力、構造化の能力が高ければ、全体的にうまく行きやすい

ただ、その、目的の達成だけを追い求める人生のつまんなさ、単調さ、みたいなのも感じる

世界をシンプルに捉えて、わかった気になって、勝手に満足している感じ

おもんないのは作ってないからか(?)

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

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

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

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

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

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

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

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

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

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

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

ドメインの理解

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

直観による補助

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

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

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

ツールに対するりかい

分析の仕方に対する理解

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

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

モデル化能力

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

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

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

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

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

採用試験

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

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

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

自分に今足りない能力が何なのかわからない

こういうのは自分より視野の広い人に話を聞くのが早そう

独りで進めるとかなり沼りそう

キャリアって課題駆動じゃないんだよな

完成されたプロダクト

Cosenseとか

根本的に何か変わることはないだろう

Infoboxみたいに、今のコアを活かした革新的な機能は表れうる

今からCosenseチームにジョインしたときの立ち回りは、アイディア出しになりそう

プロダクト自体ではほぼ完成していて、後は認知を伸ばすだけ、みたいな

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

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

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

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

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

自分の中で構成し直して

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

文章でも同じ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

↑Cosenseの個人プロジェクト

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

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

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

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

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

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

ここから、

本のグルーピング

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

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

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

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

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

ページ数、

作者、出版社、評価

などから

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

色々要件がある

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

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

和と積ぐらいしかない

ほったらかしにしてる

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