今日の注目トピック

plugin.jsonをrootに置き、Skillsとmcp.jsonを固定位置で発見。1.0.0はWorking Draft、permissionとsandboxはclient側
Agent PluginsAgent SkillsMCPInteroperability

Agent Plugins 1.0.0、SkillsとMCP設定を共通package化するWorking Draft

これは何?Agent Pluginsは、AI agentの手順書と外部toolへの接続設定を一つにまとめ、異なるagent application間で持ち運ぶための共通package仕様です。

Agent Plugins 1.0.0は必須のplugin.json、固定位置のskills/*/SKILL.md、stdio・Streamable HTTP・SSEを記述できるmcp.jsonを定め、対応clientが同じpackageを段階的に読み込めるようにします。package外へ解決するpathは拒否し、client固有機能はreverse-domain namespaceへ隔離します。公式仕様のstatusはWorking Draftで、distribution、installation、permission、UX、subprocess sandboxはportable coreの対象外です。

なぜ重要か

agentごとのdirectory再配置と設定変換を減らせる一方、portableであることは同一のsecurity policyを意味しません。導入側はformat validationと、実行時permission・secret・network accessの審査を別々に設計する必要があります。

読むべき人
AI agent platform、developer tools、MCP server、Skill・plugin配布の担当者
はてな
37 bookmarks
予約と台帳をMySQLのACID transactionへ統合。真の上限はqueryやCPUでなく、別処理が保持するconnectionだった
MySQLRedisSKIP LOCKEDObservability

Shopifyの在庫予約、RedisをMySQLへ統合しconnection保持時間から真因を特定

これは何?Shopifyのoversell protectionは、決済処理中の商品を短時間予約し、同じ在庫を複数の購入者へ販売しない仕組みです。

ShopifyはRedisの予約とMySQLの在庫台帳を跨ぐ非atomicな処理を解消するため、1在庫単位を1行で表すbounded poolとSELECT FOR UPDATE SKIP LOCKEDで予約をMySQLへ統合しました。複合primary key、READ COMMITTED、lock順序統一でcontentionとdeadlockを抑えましたが、負荷testの真の上限は別checkout処理のconnection長期保持でした。SQL tagとProxySQL集計でcaller別保持時間を可視化し、primary readを50%、transactionを33%削減したうえで、Redisとのshadow modeから段階移行しました。

なぜ重要か

data storeを統合するとreserveとclaimを同一ACID transactionにでき、oversell・undersellのfailure modeを減らせます。ただしbounded row poolはworkload依存のtrade-offであり、lockだけでなくconnection ownershipをend-to-endで観測しなければ隣接処理を含むcapacity limitを誤診します。

読むべき人
database、checkout、inventory、high-contention workload、SREの担当者
HN
327 points / 242 comments
postmarketOSのdriver不足からstock Androidへ回帰。Termuxをhost、rooted chrootをapp層にしてVPSを代替
AndroidTermuxSelf HostingARM64

CMF Phone 1でVPSを代替、Androidをhostに残しrooted chrootでARM64 appを運用

これは何?VPSはcloud上で借りる小型serverで、この記事は個人のweb appを常時動かす役割を使っていないAndroid phoneで置き換えた運用記録です。

seg6氏はCMF Phone 1へpostmarketOSを入れたもののWi-Fiなどのdriver不足でstock Androidへ戻し、TermuxにOpenSSH・Tailscale・Caddy・runitを置くhost control planeを構成しました。Linux ARM64 appは当初PRootで動かしましたがChrome workloadのsystem-call overheadが大きく、root化したreal chrootへ移し、Ansibleでdigest固定release、power設定、health check、rollbackを管理します。静音・低消費電力・battery backupを得る一方、同一kernelを共有するchrootはsecurity boundaryではなく、off-device backupとAndroid updateへの備えが必要です。

なぜ重要か

consumer deviceの既存driver・power managementを捨てず、control planeとapplication compatibility layerを分ける再利用例です。root化、battery、background制御、共有kernelというriskを明示しており、安価なhome serverを再現可能な運用へ引き上げる条件が具体的です。

読むべき人
self-hosting、Android、ARM64、home lab、platform engineeringの開発者
HN
481 points / 233 comments
固定data pixelの輝度誤差を周囲8 pixelへ先に拡散。二段階ditherで画像noiseを減らすが、scan耐性との交換条件あり
QR CodeDitheringError DiffusionImage Processing

QRの固定data pixelを先にerror diffusion、画像noiseを減らして読み取りを維持

これは何?この記事は、URLなどを読み取るQR codeの白黒patternへ写真を組み込み、読み取りやすさと見た目を両立する画像生成手法の解説です。

Andrew Taylor氏はQR codeのdata moduleを3×3領域の中心pixelへ縮小して写真用の面積を作り、固定された白黒data pixelと元画像の輝度差を周囲8 pixelへ先に拡散する二段階ditheringを実装しました。続くFloyd-Steinberg passで画像全体を1-bit化し、salt-and-pepper noiseを抑えます。error correctionでdata pixelまで変更するoptionは画質改善が小さくscan耐性を落とすため、印刷物では十分なmarginと冗長性を残すよう注意しています。

なぜ重要か

protocol上変更できないbitを画像処理のerror budgetへ組み込み、機能性と見た目のtrade-offをalgorithmとして説明しています。生成時にscanできた事実だけでなく、camera・印刷・照明を跨ぐrobustness testが必要だと分かります。

読むべき人
image processing、QR・barcode、frontend、print designの開発者
HN
353 points / 41 comments
memory、local SSD、object PUT、durable majorityで成功応答の意味が変化。速さはindex・compaction・repairへ仕事を移す
StorageDurabilityWALDistributed Systems

高速writeは仕事を消さない、acknowledgement pointと後段処理でdurabilityを読む

これは何?databaseのwrite durabilityは、成功と返した書き込みがmachineやnetworkの障害後にもどこまで残るかという保証で、この記事はその保証と応答速度のtrade-offを解説します。

Shayon Mukherjee氏は1回のclient PUTをmemory、local SSDのfdatasync、object storage、replicated WALのdurable majorityまで追い、成功応答を返す地点ごとにlatencyと耐えられるfailureが変わると整理しました。group commitやlocal WALは前段を速めますが、batch待ち、remote upload、index、compaction、replica repair、leader electionへ仕事を移します。Big OやNVMeというinterface名だけではdurability latencyを表せず、benchmarkではack後に失い得るdataと未完了cleanupを確認すべきだと論じます。

なぜ重要か

同じwrite latencyでもsuccessの定義とfailure domainが違うため、benchmark値だけでstorage engineを比較するとdurability gapを見落とします。SLOには応答時間だけでなく、acknowledgement point、backpressure、recovery責任を含める必要があります。

読むべき人
database、distributed systems、storage、performance engineeringの開発者
HN
53 points / 19 comments