X(Twitter) Zenn GitHub RSS 共有

一時保存場

作成日時：2025-07-23
更新日時：2025-12-11

別の文書やカテゴリに振り分けていないメモの集合。

記事

仕事における自身の思想を抽象化したもの

少々短速の原則

SQLや外部リソースだけはでなく、対人にも該当しないか？
質問量、質問回数、占有時間、理解容易性

外部リソース = 他者。

TanStackDB

フロントのDB

LLM

障害対応

情報の保持

LLMにしても、障害対応にしても、開発にしても
結局は情報を文書として残し保守しなければならない。

SECI、情報の共有。

技術でなんやかんやするより仕様を変えたほうが早い

Enumの状態遷移

複雑ならHelperクラスに置けばいい。

コマンド・クエリの分離

動機付け

心的なものだけではなく、環境も整える。
そもそも他者に期待するな。
「成長してくれる」はギャンブルに過ぎない。

BFCache

Chrome。
ブラウザバック時における高速化手法。
このせいでレイアウトのずれやscriptが発火しなかったりする。

Chrome DevTool

パフォーマンスからレンダリングのスクショをとれる

Gridによるレイアウトシフト

Google Chrome(PC)でのみ発生。

事象

Grid Layoutで要素を並べたことで、ブラウザバック時にスクロールの位置がずれた。

  1. 画面A表示
  2. 画面Aでスクロール
  3. 画面Bに遷移
  4. 画面Aにブラウザバック
    • この時に2の位置と異なる場所にスクロールした

下記の場合もずれた。

原因

Grid Layout内の各要素の縦幅を固定しなかったため。

ウィンドウサイズによって、要素の横幅や縦幅が動的に変わるように定義した。

|1234|
↑幅が十分あるときは1列

|123|
|4  |
↑幅が小さくなると自動で改行

要素ごとの横幅が小さくなると、それに比例して要素の縦幅が変動する。
これによって全体の縦幅の計算がうまくできず(推測不可)、本事象が発生した。

他のブラウザは、おそらく縦幅が確定した後にスクロール位置を復元していた。

対応

要素の縦幅を固定する。

知見

情報の質: コロコロ変わる

reactやvueにおけるkey

チェックリスト

チェックリストの目的は、文字通りチェックをすること。
それに加えて概念の認知を促す。

ハゲの定義

ハゲとは何か。
つるっぱげに髪の毛を1本加えてもハゲか？
つるっぱげに髪の毛を2本加えてもハゲか？
つるっぱげに髪の毛を10,000本加えてもハゲか？
境界値は何か。

仮に髪の毛が生えそろっている人がいたとする。
その人がストレスによって円形脱毛症、つまり10円ハゲができた場合、その人はハゲか？

頭頂部の半径3cm以外を剃り上げている部族が居れば、その部族の中ではハゲではない。
その半径3cm内の喪失がハゲである。

スキンヘッドはハゲか？

結局は主観的評価と社会的評価による。
プラグマティズムだね。

ナレッジマネジメントとLLM

これまでに蓄積された知識をLLMに渡せば精度があがるのでは。
これまで以上にナレッジマネジメントの重要性が高まる。

ReadとWriteでメソッドの分離

はじめに認知ありき

問題を認知しなければ、改善は発生しえない。
→マグレガー、正当化によるマインドコントロール

プラクティス

結論

“適切な”情報の取得を目指す。
“適切”は状況による。

個人としては、既知の未知の増大。
集団としてはナレッジマネジメント。

その他

KM

認知療法の本を読んだ。
本とは全く関係ないが、プラグマティズムはメンタル不調の予防薬ではないかと思った。
絶対的真理を否定し、その時点における最適を模索するという点において、認知のゆがみを抑えられる。
マインドフルネスも「今、この瞬間」という概念において。

6NFとサマリーテーブル

必要な情報だけを抜き出した一時テーブルを作っておけば、処理を高速化できるよね。
TRUNCATE→作成→ANALYZE。

既存のテーブルから作ってもいいし。
ユーザーのリクエストを元にした一時テーブルでもいいし。

prepared statement上限

製品によって上限がある。
使わずに手動でエスケープすれば上限は理論上消えるけども。

しかし、そうするとSQLの長さの制限に引っかかりかねない。
1,000件ずつとかで分割して実行したほうが安牌ではある。

MyBatis Generator

接続文字列に参照するスキーマを指定していても、
テーブル定義にスキーマを記載しないと、すべてのスキーマの同名テーブルを参照するっぽい。

テーブル構造を変更して生成しても、変更分が反映されていなかった。
原因は変更分を反映したORMを作成してはいたが、別スキーマの同じテーブルの内容で上書きしていた。

ログに同じファイルが何回も出ていれば、原因はそれ。

build.gradleのmybatisGeneratorの設定に、overwrite=trueを定義しておけば上書きされず、すべてのファイルが生成される。

セキュリティは多層防御が基本

全部で防御。

ブルックスの法則に関して

適切な管理下であれば人員追加は有効。

でも基本的に適切なマネジメントをしている組織は炎上しない。
なので、ブルックスの法則は常に正しくなる。

リーン

さっさと作って
さっさとFBをもらい
さっさと直す

レガシーコードはラップする

リアルタイム議事録によるずれの修正

会話者が話しながら議事録を作ったほうがいいのでは。
リアルタイムで認識の齟齬を検出できるし。
そのまま資料として残せる。

ストーリーマッピングからMVPを作成する

ビッグバンリリース

細かく分けて統合したほうがバグが出ないよね。
30の機能を一気に追加するより、3つのスプリントに分けて10ずつ追加したほうが、統合時のバグを減らせる。
スクラムの手法は正しい。

トラウマ

トラウマも認知しなければ存在しないので、悩む必要が無くなる。

結局他者とは分かり合えないし、分かり合えたというならば、それは錯覚である

さっさと情報を渡す

SESと狩野

提案

  1. 改善提案
    • 既知の未知の増大
  2. 機能提案
    • 圧倒的当事者意識
    • PdMの考え

経験と教育

デューイ。

心理学的に言えば、「良きスキーマの形成」こそが教育か？
では「良きスキーマ」とは何か。

ラーメン屋の存在を認知しなければ、行くことすらない

ワーキングメモリはどうすれば大きくなるか

筋肉と同じ。
適度に負荷をかけることと、ストレスや疲労を避けること。

根拠なき信頼は責任の放棄

「〇〇さんだから大丈夫」は何をもってして大丈夫なのか？
本当に問題ないかを検証するのが面倒で、〇〇さんにぶん投げているだけでは？

処理を見た目上だけ早くする方法

  1. リクエストを送信
  2. サーバは非同期で処理する
  3. ポーリングで処理が終了したか確認
    • 終わってなければ、「99%完了」を返す
    • 終わっていれば「100%完了」を返す
  4. 見た目上はすぐに99%になったように見える。

法的にグレーなのでやってはいけない。
セーフにすることもできるけど、基本的に相手を騙しているのだから。

手段-目標分析とクリティカルシンキング

GoDoc

GoDocっていいよね。
A is Bでコメントを書く。
まず、それが何であるかを最初に明示している。

WhyとHowの周知

プロジェクト開始時に明確にしておくべき。

戦略的利己主義

自己の利益のために他者に貢献する。
どうするのか？
自社にはKMによる認知の提供。
顧客には狩野モデルベースでCSの提供か。

文書の優先順位

AとB
BとA

先に書いたほうが印象に残る。

フロントのテスト

・コンポーネント/ロジックテスト
→jestやvitest
　ロジックの検証や、レンダリング時に属性が妥当な状態かを検証
・GUI
→StroyBook + α
　VRTなどグラフィカルなテスト
・E2E
→Playwrightなど統合的なテスト

キャンベル

「顧客からの問い合わせを減らす」と言って、お問い合わせフォームを消して「問い合わせ0です！」ってなるか？
目的はUXの改善では。

Simple Factoryパターン
staticを使うとモックを作りづらくなる。
factoryはcreateが慣習

interface DataWriter {
  void write(Data d);
}
class DataWriterFactory {
  DataWriter create(FileType type) {
    if (type == FileType.CSV) return new CsvWriter();
    if (type == FileType.XLSX) return new XlsxWriter();
    if (type == FileType.HTML) return new HtmlWriter();
    throw new IllegalArgumentException("不正なファイルタイプ" + fileType);
  }
}

factory methodパターンはこれと異なる。
template methodパターンの亜種のようなもので、
メソッド内で使うクラスの生成メソッドを具象クラスで実装する感じ

abstract factoryは関連するオブジェクト群を生成

DIP:具象に依存せず、抽象に依存する。

メンター

経験年数が離れている人間をメンターにしてはいけない。
技術の呪いがある。
間にミドルを入れて、プロキシ・メンターにするならばマシ。

interface

デフォルトメソッドはtemplate methodパターンに使えるよね

AAA

そのままアレンジ・アクト・アサートパターンだった。

シングルトンはテストしづらい

メモリは潤沢なので、都度生成でもいいかもしれない。
生成コストが無視できるならば。

二重貯蔵モデル

LTSからSTSへのデータのロードも認知負荷となる。

Git Flow

releaseブランチはリリース作業用。
QAが終わったら、mainにマージしてタグ発行。

記事

知識の呪いがあるから、ミドルに記事を書いてほしい。

static

staticメソッドはあまり使うべきではない。
テスト容易性の観点から。
Simple Factoryもインターフェイスのstaticメソッドではなく、クラスを作っておく。

リファクタリングとIF

IFで呼び出しを決めれば中身は自由

設計は凍結した瞬間、陳腐化する

YAGNIとJIT

決定を遅らせる。
未知の上程で進めても、技術負債になるだけ。

コーディングはただの手段に過ぎない

コンフリクトを発生させない

ビッグバンリリース、長いリードタイムが原因。
細かく小さく素早くやっていく。

ステークホルダーが関わりやすい場の構築

心理的安全性然り

変更しなければ壊れることは無い

しかし、機能を追加しなければ競合他社に負けるし、
セキュリティ的にもよろしくない。

デプロイ

デプロイ頻度を挙げれば、最善との乖離をすぐ検出できるし、ビッグバンリリースも防げる。
すぐに直せる状態となる。

関連を減らす

シンプルならば設計書は詳細に書かなくてもいい

DKNF

AIを絡めれば実質実現可能では？
パフォーマンスは下がるだろうけど。

正規化

受注と受注明細が1テーブルに格納されているとする。
同一の受注で受注先はユニークであるとする。
受注のデータは同一受注内で重複して格納される。
この場合において、新規参画者は、同一受注内に複数の受注先が存在することを懸念するのでは。
不要な認知負荷の発生。
かつ、システムとして許容されてしまっている。