kimiya

あらためて、よろしくお願いいたします u-zero.com/posts/20260115

生きててよかった

ゴルフ、東京に戻ってビール

memento mori

価値が分からない人に売ってはいけない。モノもヒトも自分も。 そして、価値が分からない人を説得するくらいなら、価値が分かる人を探した方が早い。 世界は広く、深くて、なぜか狭いので、案外、近くに居たりする。

シンプルさでは誰も昇進できない(Nobody Gets Promoted for Simplicity)　という記事から： ・エンジニアリングの世界では、シンプルで優れた仕事よりも、過剰で複雑なシステムを作った人の方が高く評価される傾向にある ・昇進の審査において、複雑な設計は成果として見栄えが良いが、シンプルに解決したという事実は言語化しづらく目立たないため ・この問題は採用面接やデザインレビューの場でも起きる ・将来への過剰な備えや拡張性を提案する方が賢く見えてしまう ・問題に見合っていない不必要な抽象化や複雑化は、かえってコードの可読性や保守性を著しく下げてしまう ・もちろん、本当に複雑な仕組みが必要な場面もある ・だが、多くの場合は対処不要な未来のために不必要な複雑さが持ち込まれているのが実態 ・真に優秀なエンジニアとは、新しい技術をむやみに導入する人ではなく、それらを使わないという判断ができる人 ・エンジニアは、複数の複雑な手段を検討した上でシンプルな方法を選んだという「複雑さを回避したプロセス」を自らアピールする必要がある ・不要な機能の追加を求められた際は、今作るコストと将来作るコストを比較し、実装を見送る合理的な提案をすることが大事 ・エンジニアリングリーダーは、複雑なシステムを作った人ばかりを評価するのではなく、シンプルな解決策をデフォルトの基準にするよう評価体制を見直した方が良い ・リーダーは、不要なコードを削除した人や、今はまだ作らなくてよいと正しく判断できたエンジニアを公の場で積極的に称賛すべきだろう terriblesoftware.org/2026/03/03/nob…

晩ごはんはステーキ

晩ごはんは水炊き

【#Devin 年中無休自律開発の実現✨】 Playbooksで独自ルールを定義し、24時間ノンストップで進捗する非同期開発サイクルを確立🔄 ✅Playbooksの使い分けで支持を最適化⚙️ ✅PRの自動修正機能でレビューサイクルを高速化🚄 ✅タスク細分化で実装精度を向上⤴️ 詳細はこちら👇 findy-tools.io/products/devin…

晩ごはんは水炊き

晩ごはんはシチュー

「OOPを何か悪いもので置き換えているのではないか」(We are replacing OOP with something worse) という主張の記事から： ・オブジェクト指向プログラミング（OOP）は消え去ったわけではない ・OOPは適用される領域が移動しただけであり、それは悪いことだと、記事の著者は考えている ・昔のプログラミングはシンプルだったが、複数人で作業すると問題が起きた ・バグは機能と機能の接点で発生しやすいことがわかった ・そこでインターフェースという契約で機能を切り離す発想が生まれた ・プログラマーの行儀の良さに頼るのではなく、言語仕様として強制するようになった ・カプセル化や継承といった概念が、情報のやり取りを制限するために作られた ・これと並行して、OSの世界でもプロセスの境界線が作られた ・OSはプログラム同士が互いに干渉しないように監視する保護者になった ・コンピュータ同士が通信するようになり、信頼関係はさらに希薄になった ・信頼できない相手に対して、開発者は強固な壁を築くようになった ・その結果、プロセスやネットワークの境界が、かつてのOOPの役割を担うようになった ・現代はマイクロサービスやDockerやKubernetesの時代である ・多くの人がJavaのようなOOPを批判しながら、実は同じ構造を巨大化させて再構築している ・現代のアーキテクチャは、OOPと同じ欠点を持ち、さらにそれを悪化させている ・OpenAPIスキーマは、かつての型チェックの代わりである ・Docker Composeは、かつてのサービスファクトリの代わりである ・Kubernetesは、かつてのイベントループの代わりである ・コンポーネント間の呼び出しには、今や多くの失敗リスクが伴う ・データのシリアライズとデシリアライズという遅い処理が必要になる ・カーネルのスケジューラを通る長い旅も必要になる ・キャッシュの無効化やソケットのポーリングといったコストがかかる ・単なる関数呼び出しだったものが、重たいHTTPリクエストに変わった ・記事の筆者は、OOPの約束事にも懐疑的だったが、現代の代替案はさらに信用できないと考えている ・現代のシステムは、OOPの哲学をプロセス単位やネットワーク単位に置き換えただけであり、その置き換えには、パフォーマンス上の莫大なコストがかかっている ・マイクロサービス化は、OOPの悪い部分を10倍に拡大したようなものである ・開発者はお互いのソフトウェアのことを知らず、信頼もしていない ・信頼がないため、最大限の防御壁としてネットワーク境界を利用しているのだろう ・結局のところ、OOPを捨てて、もっと悪いものを使っているに過ぎないのではないか blog.jsbarretto.com/post/actors

渋谷、好きな街

ソフトウェアエンジニアリングのおけるセンスの話の記事： ・ソフトウェアエンジニアリングにおける「技術的センス」は「技術的スキル」とは異なる ・スキルは高くてもセンスが悪いこともあれば、その逆もあり得る ・センスとは、料理ができなくても美味しい食事がわかるように、優れたソフトウェアを自分で作れなくても、それが何かを理解できる能力に似ている ・どのようなコードが「良い」または「ひどい」と感じるか、どのような設計判断に満足するかは、センスの指標となる ・エンジニア個人のセンスは、その人が最も重要視するエンジニアリング上の価値観の集合によって構成される ・エンジニアリングの価値観には、回復力、速度、可読性、正確性、柔軟性、移植性、スケーラビリティ、開発速度などがある ・「センスが悪い」とは、自分の好む価値観が現在のプロジェクトに適していない状態を指す ・センスの悪いエンジニアは、「ベストプラクティス」という言葉を使い、文脈を無視して自分の好きな手法を押し付けがち ・このようなエンジニアは、自分の好みがプロジェクトのニーズと一致する特定のニッチな分野では有能かもしれない ・だが、プロジェクトの性質が変わったり、職場を移動したりすると、すぐに立ち行かなくなる ・「センスが良い」とは、直面している特定の技術的問題に対して、適切なエンジニアリング価値観を選択できる能力のことである ・自分が設計に大きく貢献したプロジェクトが成功することが、センスの良さを示す一つの指標 ・良いセンスを身につけるには、多様なプロジェクトに取り組み、ソフトウェア開発に関する普遍的な「正しい方法」という考えを捨てる柔軟性が重要

日を追うごとに、あるいは私が慣れてむかしを忘れてしまっているのか、claude code / codex etc. への指示を小さくしていかないと納得できるアウトプットが得られなくなり、結局これ grep, sed でいんじゃねーか？っていう... そんなに大きなコードベースでもないし、docも整備してるんだけど...

スタジオ、1時間だと短い。2時間だと長い。

> 「これは深刻なほど何かが大きく間違っている」（DHH氏） publickey1.jp/blog/25/rails_…

ウイスキーは示唆に富んでいる

コーディング支援ツール、使い込むと視点が狭くなる感覚がある

ruby/rails + serena には solargraph gem が必要か検証中（LanguageServerTerminatedExceptionで起動しなくなった）