Souther - ドメインモデルをスラスラ書けることを追い求めた最果てのJVM言語
Javaでドメインモデルを素直に表そうとすると、型が増えます。従業員IDと文字列を分け、金額と整数を分け、申請の状態ごとに別の型を用意する。値の検証や業務上の却下も型と戻り値で表し、現在時刻やデータベースアクセスは外から注入する。業務上の違いをコードの構造へ反映するほど、コンストラクタ、アクセサ、変換処理などの実装も増えていきます。 問題は、それらが規約にとどまることです。検証を通らない構築経路を残すことも、業務上の却下を例外で返すことも、業務ロジックから直接データベースへ触ることもできます。設計を守るには、実装者が毎回同じ判断をしなければなりません。 Souther は、業務上の概念を型にするコストを下げながら、こうした規約を言語の制約として扱うために作った小さなJVM言語です。業務データ、値の制約、状態遷移、外界への依存を .sou ファイルに記述し、Javaから利用できる型と振る舞い
エンジニアの成果、結局どう測ればいいのか
行数や PR 数が「嘘の指標」なのではありません。連鎖の右端にある 途中経過 なのです。 途中経過を最終成果のように扱った瞬間に、おかしなことが起こり始めます 。 測った瞬間に指標は壊れる おかしなことが起こる理由には、名前がついています。グッドハートの法則 です。 イギリスの経済学者が指摘した現象で、後に人類学者の論文に登場する簡潔な言い換えで広く知られるようになりました。 測定が目標になると、それは良い測定ではなくなる PR 数を評価に使えば、PR は不自然に細切れになります。行数なら、冗長なコードやコピペが増えます。ベロシティを目標にすれば、ストーリーポイントの見積もりが膨らみます。 誰も悪意はなくても、評価される数字に行動が最適化されるのは人間として自然なこと です。 社会科学には似た指摘としてキャンベルの法則もあります。定量的な指標が意思決定に使われるほど、その指標は腐敗圧力にさ
ターミナルアプリの描画・入力・リソースを定量評価するベンチマークツール TerminalBench - Qiita
Noa というターミナルアプリを自作しています。開発していると、避けて通れない問いが 2 つ出てきます。この変更で描画は速くなったのか（遅くなっていないか）、そして競合のターミナルアプリと比べて今どの位置にいるのか。どちらも体感では答えられない。数値で答えるために書いたのが TerminalBench (tbench) です。 TL;DR シェルの起動と、ターミナルエミュレータの描画・入力・リソースを 1 コマンドで計測し、他のターミナルと横並びで比較できる Rust 製の単一バイナリです。 一部の値は近似（proxy）で、ツールが JSON の notes に但し書きを出します。 まずは bin/tbench run してから bin/tbench show。 ※ 名前は似ていますが、LLM エージェント評価の Terminal-Bench（laude-institute）とは別のプロジ
GitHub - xtdb/xtdb: An immutable SQL database for application development, time-travel reporting and data compliance. Developed by @juxt
Immutable - XTDB is optimised for current-time queries, but you can audit the full history of your database at any point, without needing snapshots or accessing backups. 'Bitemporal' - all data is accurately versioned as updates are made ('system' time), but it also allows you to separately record and query when that data is, was, or will become valid in your business domain ('valid' time). Dynami
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - satoshi7190/Shinjuku-indoor-threejs-demo: 新宿駅構内図
