DEV Community 日本語 - TheNote.app

DEV Community 日本語
フォロー

Dev.toは、ソフトウェア開発、プログラミング、テクノロジーに焦点を当てたコミュニティー主導のウェブサイトです。2016年にBen Halpernによって立ち上げられ、開発者が知識を共有し、他人から学び、コミュニティーを構築するプラットフォームを提供することを主要な目的としています。このウェブサイトは、ブログのようなフォーマットで、ユーザーが様々なトピックに関する記事を作成し、共有することができます。Dev.toは、ユーザーがアカウントを作成し、他のユーザーをフォローし、コメントやリアクションで彼らのコンテンツとやりとりすることを許します。 Dev.toは、コミュニティーでのやりとりを強く重視し、ディスカッションフォーラム、ポッドキャスト、ライブストリームなどの機能を提供します。また、コミュニティー主導のプロジェクトシリーズ、例えばコーディングチャレンジやハッカソンも、協力とイノベーションを促すために開催しています。ユーザーが生成するコンテンツに加えて、Dev.toは、企業が仕事のオープニングを掲載し、開発者が仕事の機会を探すことができるジョブボードも提供します。このウェブサイトは、最新の記事、ニュース、イベントの更新を提供するニュースレターもあります。全体的に、Dev.toは、ソフトウェア開発業界の最新のトレンドとテクノロジーとつながり、知識を共有し、コミュニティーを構築するための人気のプラットフォームとなっています。

DEV Community dev.to

DEV Community 日本語 RSS thenote.app

RSS Hunter • 2024年8月23日

ノートのスレッド

App Health Endpoint Design: 3 Probes That Keep Logging and Metrics Useful

Kubernetesプローブは具体的に設定すべきです。起動チェックは初期化が完了したかを確認し、準備チェックはインスタンスがトラフィックを処理できるか評価し、生存チェックはプロセスが停止していないか判断します。起動プローブは、他のプローブがアクティブになる前に、価格設定ルールのコンパイルのような初期化タスクに追加の時間を与えます。準備プローブは、インスタンスがアクティブなルールと必要な依存関係の状態を提供できることを検証し、失敗した場合はポッドをサービスエンドポイントから削除します。生存プローブは、回復不能なプロセス問題をチェックし、問題が検出されたときにコンテナの再起動をトリガーします。この分離により、無関係な依存関係の障害が不要なコンテナ再起動を引き起こすことを防ぎ、問題が増幅されるのを防ぎます。不動産管理APIの場合、準備チェックはインスタンスが特定の価格設定ルールを提供する準備ができていることを保証し、テナントを不整合な見積もりから保護します。起動プローブは、初期化が生存予算よりも時間がかかる場合に不可欠であり、早期の生存または準備チェックを防ぎます。準備プローブは、新しいトラフィックを停止するが再起動なしで回復できる条件、例えばルールスナップショットの欠如などに選択されます。生存プローブは、再起動で修正できる問題、例えば応答しないイベントループなどに予約され、不要な再起動を避けるために範囲を狭くすべきです。ヘルスエンドポイントは、プローブタイプごとに異なるパスを使用し、生存チェックでネットワーク呼び出しを避け、最小限のステータスコードを返す必要があります。

App Health Endpoint Design: 3 Probes That Keep Logging and Metrics Useful dev.to

RSS Hunter • 今日

本番環境でAIエージェントが失敗する理由：メモリ、テスト、ツールのギャップを埋める

ローカルで完璧に機能するエージェンティックワークフローは、クリティカルなエンジニアリングのギャップにより、本番環境で失敗することがよくあります。これらの失敗は、固有の複雑さからではなく、メモリリーク、評価の盲点、ツールの脆弱性に起因します。LLMはステートレスであるため、コンテキストウィンドウの制限とセッションメモリが本番環境における大きな障害となります。単純なプロンプトの蓄積はコンテキストウィンドウを圧倒し、レイテンシの増加、コストの増加、推論品質の低下につながります。本番環境のエージェントには、短期バッファ、中期ベクトル埋め込み、長期構造化データを備えたハイブリッドメモリシステムが必要です。従来の単体テストはLLMには不十分であり、本番環境ではLLMをジャッジとする評価と、回帰テストのためのゴールデンデータセットが必要です。ツールの脆弱性は、未処理のAPIエラー、ネットワークの問題、スキーマの変更から生じ、堅牢なリトライメカニズムとサーキットブレーカーを必要とします。ツールのオーケストレーションには、リトライのための指数関数的バックオフ、外部依存関係のためのサーキットブレーカー、エラーを防ぐためのスキーマ検証を含める必要があります。トレースレベルのロギング、コスト追跡、人間参加型の脱出ハッチによる効果的なオブザーバビリティが不可欠です。これらのギャップを埋めることは、プロンプトエンジニアリングからエージェントシステムエンジニアリングへと焦点を移し、メモリ管理、テスト、ツール、オブザーバビリティにおける規律を要求します。本番環境への対応は、これらのパターンを実装し、すべてのツール呼び出しに対してフォールバックメカニズムとセキュリティ監査を確立することを含みます。

Why Your AI Agent Fails in Production: Bridging the Memory, Testing, and Tooling Gaps dev.to

RSS Hunter • 今日

実際に動作するシンプルなCI/CDパイプライン

多くのCI/CDチュートリアルは、基本的なデプロイに焦点を当て、シークレット管理やロールバックといった重要な側面を無視することで、過度に単純化しています。著者は、アクセシビリティのためにGitHub Actionsを使用し、テスト、ビルド、デプロイのシンプルな3段階パイプラインを提唱しています。プロセスは、ビルドやデプロイが発生する前に合格しなければならない自動テストから始まります。メインブランチへのプッシュのみがビルドステージをトリガーし、アプリケーションをアーティファクトにコンパイルします。デプロイステージは、GitHubシークレットとしてサーバー認証情報を安全に管理する必要があるSCPを使用して、このアーティファクトをサーバーに転送します。迅速なロールバックを可能にするために、著者はサーバーに最後の3つのデプロイバージョンを保持することを提案しています。ロックファイルを使用することで依存関係の一貫性が維持され、環境全体で再現可能なビルドが保証されます。コミットする前に、テストとビルドステップのローカルテストを実行して、早期に問題を検出することが推奨されます。一般的な問題には、SSHキー形式の誤り、ビルド出力のパスの不一致、デプロイユーザーのサーバーパス権限の不足などが含まれます。リンティングやデータベースマイグレーションなどの追加機能は、シンプルさとデバッグの容易さを優先して、後で追加できます。このミニマリストなアプローチは、多くのプロジェクトに適しており、反復的な開発と機能的なコアからの開始を強調しています。

A Simple CI/CD Pipeline That Actually Works dev.to

RSS Hunter • 今日

52日間、2,340行、すべてのコストがゼロとして記録された：ストップフックの罠

著者の学生時代の副業は、AI環境を自律的に実行することで実際のビジネスへと成長しました。このセットアップは、指示を出すことから、著者が寝ている間でもシステムが独立して動作することを可能にする段階に進みました。重要なコンポーネントは、セッション完了時に自動的にトリガーされる「Stop hook」です。このフックは、自律エージェントが直接的な監視なしにリソースを静かに消費する可能性があるため、AI使用コストの追跡に不可欠です。初期のコスト追跡メカニズムは、Stop hookの入力に必要な使用量とモデルデータが欠けていたため、52日間および2,300件以上のログエントリで失敗しました。改訂されたアプローチは、唯一の信頼できるデータソースであるため、セッションのトランスクリプトファイルを直接読み取ることに焦点を当てています。このトランスクリプトには、トークン使用量や使用されたモデルを含む、アシスタントの応答の詳細なログが含まれています。システムは、Haiku、Sonnet、Opusなどの異なるモデルの100万トークンあたりのコストを定義するレートテーブルを利用しています。また、キャッシュの読み取りが通常の入力よりも大幅に安価になる可能性があるAIキャッシングのコストへの影響も考慮しています。読み取り不可能なファイルや無効なログ行のような軽微な問題が追跡プロセス全体を停止させないように、堅牢なエラー処理が実装されています。スクリプトには、セッションIDを決定するためのトリプルフォールバックメカニズムが含まれており、さまざまな実行コンテキスト下でもセッション識別子がキャプチャされることを保証します。最後に、コスト計算では、浮動小数点演算エラーを軽減するために、6桁の小数点以下の精度を維持するための特定の丸め処理が使用されています。ログエントリの累積的な設計により、セッションが予期せず終了した場合でも、部分的なデータ回復が可能になります。

52 Days, 2,340 Rows, Every Cost Logged as Zero: The Stop Hook Trap dev.to

RSS Hunter • 今日

アップロードは成功しましたが、レコードは成功しませんでした

著者は、セッション開始、ファイル転送、ビデオID取得、検証、ローカルレコード作成を含むシーケンシャルなプロセスでYouTubeアップロードシステムを開発しました。ローカルレコードが検証ステップの後にのみ書き込まれていたため、重大な欠陥が生じました。検証が失敗した場合、例外が発生してプロセスが停止し、ディスク上にアップロードされたビデオのレコードが残りませんでした。その結果、アップロードコマンドを再実行すると、既存のファイルチェックがバイパスされ、ビデオの重複アップロードにつながりました。システムのドキュメントでは、リトライによって重複が発生しないと誤解を招く記載がありましたが、これは外部からのプロセス全体の失敗後の再実行ではなく、内部の低レベルのリトライにのみ適用されました。これにより、同じビデオが2回アップロードされることになりました。リポジトリの別の部分でも同様のバグが発見され、古いプロセスを通じてアップロードされた5本のビデオも対応するローカルレコードがなく、重複の危険性がありました。著者は、既存のテストが合格したのは、例外発生後のディスク上のシステムの状態を考慮していなかったためだと指摘しています。修正は、ビデオIDを受け取った直後に、未検証とマークされていても、ローカルレコードを書き込むようにワークフローを変更することでした。このレコードにより、検証を再開するか、ビデオが既に処理されている場合はそれ以上のアップロードをブロックすることが可能になりました。既存の5本のビデオについては、手動でのレコードのバックフィルが必要でした。この根本的な問題は、リモートリソースを作成してから検証し、失敗した場合にリモートリソースは作成されたもののローカル状態が記録されないままになるウィンドウを作成する、あらゆる操作に一般化されます。このあいまいさがリトライロジックを無効にします。この解決策は、後続の検証に関係なく、IDを受け取った瞬間にそれを記録することに重点を置いています。また、リソースを作成するすべてのコードパスが、目に見えない不整合を防ぐために、同じブックキーピングシステムに貢献する必要があることも強調しています。

The Upload Succeeded, the Record Did Not dev.to

RSS Hunter • 今日

パスワードマネージャーに「ゴッドモード」があってはいけない理由

ゼロ知識パスワードマネージャーは、マスターバックドアなしでアクセスを回復する方法という、回復のジレンマに直面しています。単一の「ゴッドモード」認証情報を持つことは、攻撃者に悪用される可能性のある、主要な単一障害点を作り出すことになります。代わりに、Passworkは、それぞれ特定の限定的な機能を持つ3つの独立したティアを使用してアクセス回復を設計しました。ティア1は緊急コンソールであり、通常の回復が失敗した場合にオーナーのログイン認証情報をリセットするために、サーバーレベルのアクセスと明示的なアクティベーションが必要です。このコンソールは、ログインアクセスのみを復元し、ボールトの復号化機能は復元しません。緊急コンソールによって実行されるすべての操作は、監査のためにログに記録されます。ティア2はオフライン回復アカウントであり、特定のボールトタイプに対して事前に共有された暗号化された権限を使用します。このアカウントのアクセスは、インシデント前に構成されたものに限定されており、遡及的なアクセス権の付与を防ぎます。このアカウントのマスターパスワードは、安全にオフラインで保存する必要があります。ティア3はサービスアカウントに対応し、APIトークンを介したプログラムによるアクセスのみを対象とし、インタラクティブなログインは対象外とします。漏洩したトークンは、その統合に明示的に付与されたリソースのみを侵害します。これにより、自動化認証情報が普遍的なバックドアになることを防ぎます。この3ティアアプローチは、個別の、監査可能で、範囲が限定されたメカニズムに信頼を分散させることで、単一のマスターキーを回避します。アクセス回復は、すべてをアンロックできる単一の特権認証情報に依存しません。この設計は、セキュリティリスクを集中させることなく、アクセスを回復することを重視しています。最終的に、セキュリティは、信頼を1つのポイントに統合するのではなく、分散させることによって達成されます。

Why your password manager shouldn't have a "god mode" dev.to

RSS Hunter • 昨日

「ChatGPTは私のブランドに言及しますか？」は3つの異なる質問です

バイヤーは、従来の検索エンジンの結果を迂回して、ChatGPTのようなAIツールを情報検索にますます活用しています。ブランドにとって重要なのは、潜在顧客がこれらのAIエンジンに質問した際に、自社が表示されるかどうかです。この「言及」は単一の指標ではなく、回答のテキストに名前が表示される、引用に登場する、あるいは正確に引用されるという3つの異なるシグナルで構成されます。ブランドは、その名前が本文に表示されなくても引用に登場することがあり、その逆もまた然りです。顧客はソースをクリックする可能性があるため、どちらも重要です。ブランドは、名前が表示され引用されていても、情報が不正確である可能性があり、それは有害となり得ます。AIによって単に「クロール可能」であるだけでは、引用が保証されるわけではありません。ブランドのプレゼンスを正確に測定するには、実際のバイヤーの質問をライブAIエンジンに投げかけ、3つのシグナルすべてを確認する必要があります。AIの回答と引用は動的であり、頻繁に変更される可能性があるため、この測定は継続的に行う必要があります。単一のチェックでは、現在の状況のスナップショットしか得られません。不正確な情報で引用されることは、全く言及されないことよりも悪いことです。したがって、AIの回答におけるプレゼンスの監視は、一度限りの監査ではなく、継続的なプロセスです。

'Does ChatGPT Mention My Brand?' Is Three Different Questions dev.to

RSS Hunter • 昨日

なぜあなたのAIオートメーションはまだラップトップで実行されているのですか？

多くの現在のAI自動化の取り組みは、異なる段階を接続するために依然として人間の介入に大きく依存しており、高価なミドルウェアとして機能しています。個々のタスクは自動化されていますが、ワークフロー全体は断片化したままであり、システム間で情報を手動で転送するために人々が必要とされています。AWS、GitHub、Jiraのような既存のシステムは既にデータを共有できるAPIを持っているため、これは非効率的です。著者は、現在これらのギャップを埋めるために人間が必要とされているが、これは変化する可能性が高いボトルネックであると主張しています。真の問いは、人間の関与が本当に必要な場所を特定することであり、これはチームやコンプライアンスのニーズによって異なります。AIの出力は常に完璧ではありませんが、著者は人間がプロセスにおいて過剰に使用されていることが多いと考えています。多くのタスクでは、最初の目標を理解し、最終的な結果を確認するという、1つか2つの人間の決定だけが本当に必要です。著者は、これらの2つのポイント間のほとんどの作業は機械で処理できると示唆しています。エラー検出からコード変更、テストまで、人間の即時的な入力なしで、本番環境のバグを処理するための自動化されたプロセスの実用的な例が提示されています。これは、人間のレビュー担当者が必要とされる前に、大幅な自動化の可能性を強調しています。より高度な自動化に不可欠なのは、エージェントが学習した情報を保持し、引き継ぐことを可能にするメモリ、つまり永続的な状態です。現在、この情報はチャットウィンドウやターミナルで失われることが多く、手動での要約を余儀なくされています。著者は、エージェントが効果的に連携できるようにするためには、コンテキストを保存するためのデータベースまたは同様のメカニズムが不可欠であると提案しています。これらの自動化されたワークフローをローカルのラップトップ上に構築することは可能ですが、容易に中断される脆弱なインフラストラクチャを作成します。ソフトウェア開発ライフサイクルのタスクを実行するこれらのAI駆動型自動化システムは、他の本番サービスと同様の堅牢なインフラストラクチャを必要とします。これには、安定性、安全な認証情報、永続的な状態、ロギング、リトライ、および監査証跡が含まれます。究極の目標は、AIシステムが朝までにバグの調査と修正のようなタスクを自律的に処理し、開発者にとって面倒なコピー＆ペーストや手動の手順を排除することです。

Why Are Your AI Automations Still Running on Your Laptop? dev.to

RSS Hunter • 昨日

DaDaScribe API: YouTube 多言語トランスクリプト + SRT を 1 回のリクエストで

DaDaScribeは、従来の方法とは異なり、多数のステップを単一のAPIリクエストに統合することで文字起こしを簡素化します。開発者は通常、動画をダウンロードし、音声を抽出し、ファイルをアップロードし、その後翻訳とスピーカーのラベル付けを別々に行う必要があります。DaDaScribeはYouTubeのURLや音声・動画ファイルを直接受け付けています。出典言語や最大5つの宛先言語、さらにカスタムスピーカー名の指定が可能です。APIは.txtトランスクリプトと翻訳を含む.srt字幕ファイルを返します。簡単な始め方は、curlやPythonで文字起こしジョブを送信し、状況をポーリングして結果をダウンロードすることです。このプロセスにより、手動のデータ抽出や複数のAPI呼び出しの必要性がなくなります。また、ノイズリダクションなどの前処理も含み、文字起こし前の音質向上を図ります。OpenAI Whisper、Deepgram、AssemblyAIなどのサービスに比べて、ネイティブなYouTube対応と組み込み翻訳を提供する利点があります。このサービスはコンテンツパイプライン、多言語字幕生成、名前付きスピーカーを必要とするツールに最適です。しかし、リアルタイムストリーミングや非常に大量でコストに敏感なアプリケーションには適していません。DaDaScribeは、開発者が管理しなければならない外部サービスの複雑さと数を減らすことを目指しています。

DaDaScribe API: YouTube Multi-Language Transcript + SRT in One Request dev.to

RSS Hunter • 昨日

TermuxでAndroidから100%インタラクティブなポートフォリオを作成しました - GHOST-OS v5

こんにちは、DEV！ 👋私はメキシコ、チアパス出身の ghost-0x-coder です。PCを使わず、Termuxを使って携帯電話だけでウェブポートフォリオを作成しました。🚀 プロジェクト：GHOST-OS Web Interface - v5 🔗 リンク：https://ghost-0x-coder.github.io/ghost-site/何が入っていますか？展開するボックスを備えたインタラクティブなデザイン純粋なJSで作成されたエフェクトとアニメーション 100%レスポンシブスタック： HTML、CSS、JavaScript - すべて携帯電話から。ここに投稿するのは初めてです。v6に向けて、あらゆる種類のフィードバックを受け付けています。皆さんは携帯電話からコーディングしたことがありますか？

Hice mi portafolio interactivo 100% desde Android con Termux - GHOST-OS v5 dev.to

RSS Hunter • 昨日

なぜ私が式典を運営するのか

著者は、サービスフリート向けの証拠に基づいた契約インテリジェンスを構築するために設計されたシステムであるPhebs scale gateを検証するための20回の試みについて説明しています。これらの試みは反復的なテストではなく、複雑なデータプロファイルと運用シナリオに対してシステムを厳密に検証する演習でした。scale gateは、200万以上のファイルオーナーを持つ構造プロファイルと、数万のユニークなデータブロブを持つセマンティックプロファイルの2つの決定論的なリポジトリを含みます。検証プロセスには、コールドコンバージェンス、リソースプレッシャー、リカバリーなどのシナリオが含まれ、固定されたルールと事前に定義された結果があります。これらの検証セレモニーは、4つの主要なルールによって管理されます。環境操作を防ぐための入力のフリーズ、監査可能な結果を保証するための決定の事前クローズ、透明性のためのカストディではなく証拠の保持、そして新しい試みと識別子を必要とするすべての停止を正直に失敗として扱うことです。このプロセスは、レビューの承認と実行の承認を分離し、早期に欠陥を検出します。失敗は、おそらく合格ではなく、未分類または領収書なしとして分類されます。以前の試みでは、実行可能ファイルのバインディング、プライベート署名資料の不適切な処理、および誤ったコードバージョンに対する署名に関する問題など、さまざまなプロトコル障害が明らかになりました。Scaleはまた、正常なワーカーがキャンセルされる同期バグや、予期しない検証エラーにつながるコンポーネント間の相互作用などの微妙な欠陥も露呈しました。入力制限が誤って適用されたフリーズされた契約の矛盾も、正確な契約定義の重要性を強調しました。インストルメンテーションは、ソース取得に費やされる過剰な時間などのパフォーマンスのボトルネックを特定しました。構造プロファイルは完了したがセマンティックプロファイルは失敗したなどの部分的な成功でさえ、未分類として記録され、証拠に基づいた完全な主張のみが合格を構成するということを強化しました。その後の試みは、証拠パスのギャップをさらに露呈し、修正されたコードは欠落したレコードを遡って作成できないことを強調しました。著者は、セレモニーは欠陥発見と認識論的規律を提供し、より安価で継続的なテストを補完する厳格でコストのかかるプロセスを通じて主張を擁護可能にすると主張しています。注意深く記録された不完全なゲートステータスは、時期尚早に宣言された成功よりも多くの意味を持ちます。

Why I run ceremonies dev.to

RSS Hunter • 昨日

Azure Integration Services インタビュー対策パート4：Application Insights、Log Analytics、分散トレーシング、および破損したパイプラインのデバッグ

この記事では、メッセージングサービス、オーケストレーション、セキュリティに関する以前の議論を踏まえ、Azure統合パイプラインの不可欠なデバッグおよび監視ツールキットについて掘り下げます。Application Insightsはフライトデータレコーダーとして機能し、Function AppsやAPIなどのコード駆動コンポーネントから、リクエスト、依存関係、例外、カスタムログなどのテレメトリを自動的にキャプチャします。アクティベーションには、NuGetパッケージのインストールと接続文字列の設定が含まれ、セキュリティのためにKey Vaultを活用することがよくあります。Log Analytics Workspaceは、Application Insights、Function Apps、Logic Apps、Service Bus、SQL、APIMなど、さまざまなAzureサービスからのテレメトリを一元化されたクエリ可能なデータストアとして機能します。これにより、Kusto Query Languageを介して単一のワークスペース内でクロスサービスデータ相関が可能になります。個々のサービス上の診断設定は、それらのログをこのワークスペースに送信するように構成されます。次に、Kusto Query Language（KQL）がLog AnalyticsワークスペースまたはApplication Insights内で使用され、アドホック調査を実行し、複数のサービスにわたる特定の質問に回答します。クエリの例は、パイプライン全体、またはService Busの依存関係内で失敗したリクエストを特定する方法を示しています。一意のoperation_Idによって容易になる分散トレーシングは、単一のリクエストが接触したすべてのサービスを横断するジャーニーを自動的に追跡します。この識別子は、HTTP呼び出し、Service Busメッセージ、Function Appの実行全体に伝播し、リクエスト全体のパスの再構築を可能にします。Logic Appsは組み込みのRun Historyを提供し、各実行のトリガーとアクションの決定論的なステップバイステップ再生を提供します。失敗した実行は、その正確な入力と出力を視覚的に検査でき、根本的な問題を解決した後に再送信するオプションがあります。Function Appの障害は、リアルタイム監視のためのLive Metricsと、詳細なスタックトレースを含む障害後分析のためのApplication InsightsのFailuresブレードを使用して調査されます。この包括的なツールキットは、Azure統合パイプライン全体の可視性と診断機能を提供します。

Azure Integration Services Interview Prep Part 4: Application Insights, Log Analytics, Distributed Tracing, and Debugging a Broken Pipeline dev.to

RSS Hunter • 昨日

Claudeにコードの脳を与えた。今回はテストにそれを判断させた。

この実験では、Claude Code がメモリレイヤーを備えた実際のリポジトリタスクを実行する能力をテストしました。回答の正確性に焦点を当てた以前のテストとは異なり、この実験ではエージェントがファイルを変更し、決定的なチェックに合格する必要がありました。RE-call メモリシステムを備えた Claude Code は 58.3% の成功率を達成し、Claude Code 単体 (50.0%) および CLAUDE.md のベースライン (36.1%) を大幅に上回りました。RE-call システムの改善は、プロジェクト固有のメモリに敏感なタスクで最も顕著でした。興味深いことに、静的な CLAUDE.md ファイルは、ベア構成よりもパフォーマンスが悪く、静的な指示がノイズを導入する可能性を示唆しています。RE-call は、単にトークンを追加するのではなく、必要なときにのみ関連するコンテキストを取得することで、その有用性を実証しました。メモリレイヤーは、ほとんどの対象となるセッションで参照され、有用なコンテキストを提供しました。RE-call はトークン使用量とコストを増加させましたが、古い情報による高額な失敗を防ぐことを目的としていました。この実験では、GPT-5.3 Codex の運用上の制限にも遭遇し、決定的な比較ができませんでした。最終的に、これは、本番環境のメモリレイヤーが、重要なプロジェクト固有のコンテキストを取得することにより、実際のリポジトリタスクにおけるエージェントの成功率を向上させることができることを検証しました。今後の作業では、効率と精度のためのメモリ取得の最適化に焦点を当てます。

I Gave Claude Code a Brain. This Time I Let the Tests Judge It. dev.to

RSS Hunter • 昨日

あなたの codex exec は 1 ターンあたり約 900 ms を無駄にしています。どこで無駄にしているか測定しました。

著者はBunを使用してOpenAIのCodex CLI JavaScriptハーネスを再構築し、実行時パフォーマンスの向上だけでなく、アーキテクチャ上の改善を発見しました。CodexエンジンはRustコアとJavaScriptレイヤーで構成されており、後者がBunに置き換えられました。新しいクライアントが導入され、単一のCodexアプリサーバープロセスを維持し、繰り返しの起動を回避しました。ベンチマークにより、永続的なプロセスは、各ターンで新しいプロセスを起動する場合と比較して実行時間を大幅に短縮することが明らかになりました。驚くべき発見は、Codexのリリースビルドがテレメトリエクスポーターを有効にし、メトリクスをアップロードするためにプロセスシャットダウン時間に約900ミリ秒を追加することでした。新しいプロセスが起動されるたびに、このオーバーヘッドが発生します。設定ファイルでメトリクスエクスポーターを「none」に設定するという簡単な設定変更により、コードを変更せずにこの遅延を解消できます。永続プロセスアーキテクチャによるパフォーマンス向上は、JavaScriptランタイムに依存しないものであり、Node.jsでも同様の結果が得られました。Bunの利点は主にツールチェーンに見られ、テストの起動時間とインストール時間を大幅に短縮しました。生成されたプロトコル型による初期のパッケージサイズの増加は、宣言を単一ファイルに統合することで対処されました。この取り組みにより、より小さく最適化されたパッケージが実現しました。記事全体では、図やさらなるベンチマークを含む技術的な詳細をさらに掘り下げています。コードとデモはGitHubで入手可能です。

Your codex exec is wasting ~900 ms per turn. I measured where. dev.to

RSS Hunter • 昨日

当社の数学を誰も信頼する必要がないように、449件の実際の設備金融見積もりをオープンソース化しました。

商業用機器のファイナンスサイトは、月々の支払いがどのように計算されるかをしばしば不明瞭にし、APR（年利）や返済スケジュールに関する透明性を欠いています。Equipment Capital Indexは、実際の機械ごとの価格とファイナンスの返済スケジュールを公開することで、この状況を変えることを目指しています。彼らは現在、検証とさらなる開発を可能にするために、その基盤となるデータセットを公開しました。このデータセットは、建設、農業、トラック輸送、動力機器、マテリアルハンドリングを含む様々なカテゴリーの実際の機械に対する集計されたファイナンスベンチマークで構成されています。これは、調査による推定値や架空の平均値ではなく、個別に価格設定された449台の機械から綿密に収集されたものです。現在のスナップショットでは、これらのカテゴリー全体で平均APRは7.75%から8.50%の範囲を示しています。全体として、サイト全体の平均APRは、追跡された機械で8.17%です。このイニシアチブの背後にある核となる原則は、すべての数値が、価格が特定され、検証可能な返済計算が行われた実際の機械に遡ることができるということです。集計ロジックも再現可能であり、単一の信頼できる情報源を保証します。このデータは、ライブJSON API、自己更新されるGitHubリポジトリ、および信頼性の高いアクセスを確保するためのZenodo上の永続的なDOIを通じて、複数のチャネルからアクセス可能です。商業用機器のコストに関連するツールを開発している開発者は、このデータを直接使用するか、その情報源を引用することを推奨します。

We open-sourced 449 real equipment financing quotes so nobody has to trust our math dev.to

RSS Hunter • 昨日

Node.js Express 対 Python FastAPI: 2026 年にどちらを選ぶべきか？

バックエンドフレームワークの選択は、JavaScriptとExpress、あるいはPythonとFlask/Djangoのような単純な言語の好みを超えて進化しました。PythonのFastAPIは、特にAIの台頭と型安全性の必要性から注目を集めています。Node.jsのExpressは、その非意見的な性質から、エンタープライズWeb開発において依然として人気のある選択肢です。Expressはミニマリストなアプローチを提供し、HTTPツールを提供しますが、開発者はデータ検証やAPIドキュメントのためのソリューションを構築または統合する必要があります。対照的に、FastAPIは型ヒントや非同期プログラミングのような最新のPython機能を活用し、自動化されたデータ処理とシリアライゼーションを実現します。FastAPIのデータ型に対する意見的なアプローチは制限的に感じられるかもしれませんが、検証とドキュメントの自動化により開発を効率化します。Expressは、リアルタイムアプリケーションに適した高並列I/O操作に優れています。FastAPIは、Pythonとしては高速ですが、広範なデータシリアライゼーション中にわずかにCPUオーバーヘッドが増加します。AI、機械学習、データサイエンスを含むプロジェクトでは、Pythonの支配的なエコシステムにより、FastAPIが優れた選択肢となります。しかし、チームがJavaScript開発者のみで構成されている場合、Expressは共有型定義によるフルスタックJavaScript開発の利点を提供します。最終的に、決定はプロジェクトの要件にかかっています。リアルタイムアプリケーションと完全な制御にはExpressを選択し、AI/データサイエンスの統合と自動化された機能にはFastAPIを選択してください。

Node.js Express vs. Python FastAPI: Which Should You Choose in 2026? dev.to

RSS Hunter • 昨日

ChatGPTのための100のライティング、生産性、コーディング、リサーチのレンズ 🧠💻

AIは、単一目的のチャットボットとしてではなく、専門的な作業モードのコレクションとして扱うことで、より有用になります。特定のコマンドを使用することで、ユーザーはAIにデバッグ、アルゴリズム設計、またはリサーチ計画などのタスクに対して異なる思考スタイルを採用するように指示できます。これにより、インタラクションは単純な質疑応答形式から、目標、コンテキスト、専門的なレンズ、分析、およびイテレーションを含む構造化されたワークフローへと移行します。このテキストでは、テキストの変換、トーンの制御、ライティングの構造化、情報の圧縮、会議の管理など、機能別に分類された多数の「レンズ」またはコマンドについて詳述しています。プロジェクト管理レンズは、OKRとKPIを通じて、大きな目標を実行可能なシステムに分解し、測定可能な成果をもたらすのに役立ちます。リスク分析および根本原因分析レンズは、不確実性を特定し、失敗を理解するためのフレームワークを提供します。生産性レンズは、優先順位付けとフィードバックに焦点を当て、学習レンズは能動的な想起と実践を奨励します。開発者向けには、コーディング固有のコマンドが、生成、説明、デバッグ、リファクタリング、および最適化をカバーしており、それぞれに明確な目的があります。アルゴリズムおよびデータ構造レンズは、テクニカルインタビューの問題解決をガイドします。このテキストでは、SQLなどのデータ形式の操作、APIの設計、およびリサーチの実施に関するレンズについても取り上げています。極めて重要なのは、意見とテスト可能な仮説の違い、およびピアレビューと単純な批判の違いを強調している点です。/auditレンズは、より広範な検査機能を提供し、/frameworkメタレンズは、適切な問題解決方法論の選択を支援します。最終的に、これらの専門的なモードを活用することで、より正確で効果的なAIの利用が可能になります。

100 Writing, Productivity, Coding & Research Lenses for ChatGPT 🧠💻 dev.to

RSS Hunter • 昨日

コーディングエージェントは、事実を否定されるとそれを発明する。私の4つのプローブはすべて偽のゼロを返した。

新しい論文によると、コーディングエージェントは、情報が欠落している場合、無知を認めるのではなく、事実を捏造することが明らかになりました。これらのエージェントは、重要なデータが利用できない場合に、ファイルを偽造したり、値を推測したりします。研究者たちは、複数のAIモデルが、記憶された知識が妨げられた際に同一の失敗を示したことを発見し、共通の脆弱性を示唆しています。興味深いことに、異なるシステム構成がテストを通過する際のコストは劇的に異なり、より高価なセットアップは事実が存在しない場合に真実性の利点を提供しませんでした。この論文は、エージェントの読み取りを監視するために設計されたツールが、これらの捏造に盲目であることを強調しています。これらの監視ツールは、読み取りを観察することにより、情報が欠落している場所に空の「穴」を期待します。しかし、エージェントはこれらの穴を、通常の操作のように見えるように、もっともらしい捏造で埋めます。ゼロの結果が不在または接続の失敗のいずれかを示す可能性があるこの現象は、コーディングエージェントに固有のものではなく、測定に広く適用されます。著者は、エンコーディング、スキーマ、タイプ、または語彙に関する仮定により、正しい答えが存在するにもかかわらず、それぞれゼロを返す4つのトイプローブでこれを説明しています。提案されている解決策は、楽器を検証するための標準的な科学的手法であるコントロールの使用です。ポジティブコントロールは楽器が機能することを確認し、ネガティブコントロールはそれが正しく識別することを保証します。AIシステムの場合、これは、疑わしいゼロを検出するために人間の知覚に頼るのではなく、すべての測定に対してコントロールを実行する手続き的なアプローチを意味します。根本的な問題は、実際の捏造とは異なり、捏造された不在は検出不可能であるということです。したがって、ゼロの結果を信頼する前に、コントロールを通じて楽器の整合性を検証する必要があります。

Coding Agents Invent Facts When Denied Them. All 4 of My Probes Returned a False Zero. dev.to

RSS Hunter • 昨日

モジュラーC++静的ライブラリの構築：クリーンアーキテクチャ、カプセル化、および安全な入力処理

大規模な C++ プロジェクトでは、すべてのコードが 1 つのファイルにまとまると管理が困難になり、コードの重複やコンパイル速度の低下を招きます。モジュール型アーキテクチャは関心を分離し、コードの整理とテスト容易性を向上させます。このチュートリアルでは、本番環境で利用可能な C++ ユーティリティモジュールの構築方法を解説します。前提条件として、C++17コンパイラ、ヘッダーと翻訳単位に関する理解、およびコードエディタが必要です。このプロジェクト構造では、明確な境界を維持するために、パブリックヘッダーを実装ファイルから分離しています。ヘッダーはアーキテクチャ上の契約として機能し、実装の詳細を明かすことなく利用可能な操作を宣言します。ユーティリティ関数は、グローバルネームスペースの汚染を防ぐため、CoreUtils名前空間内に配置されています。インターフェース宣言を実装ファイルから分離することで、変更されたユニットを個別に再コンパイルできるようになります。ヌルポインタを防御的に処理し、計算における整数オーバーフローを防止することで、メモリの安全性が向上します。関数には、クラッシュを防ぐためにヌルポインタやサイズゼロに対する境界ガードが含まれています。配列要素の合計計算時のオーバーフローを防ぐため、累積ガードではより大きなデータ型が使用されています。不正なユーザー入力から回復し、無限ループを防ぐために、防御的なストリーム処理が実装されています。このチュートリアルでは、翻訳ユニットをオブジェクトファイルにコンパイルし、それらを静的ライブラリにアーカイブするビルドパイプラインの概要を説明しています。最後に、この静的ライブラリをメインアプリケーションにリンクして実行します。

Building a Modular C++ Static Library: Clean Architecture, Encapsulation, and Safe Input Handling dev.to

RSS Hunter • 昨日

テストを通過するだけではない：コンテキスト認識型AIコーディングエージェントを評価するための100レンズフレームワーク 🤖

AIコーディングエージェントはコード生成においてより熟練してきていますが、エンジニアリングの判断力を評価するという点で大きな課題があります。単にテストをパスするだけでは不十分です。なぜなら、それはAIがアーキテクチャの文脈、プロジェクトの制約、あるいは過去の決定を理解していることを保証しないからです。AIがスニペットからリポジトリの変更へと移行するにつれて、この文脈的な正確さが極めて重要になります。SWE-benchのような現在のベンチマークは、現実世界のソフトウェアエンジニアリングの問題に対処するために進化していますが、タスクの質や汚染といった課題にも直面しています。著者は、AIエージェントが関連性の高い文脈の変化に適応する能力を評価することを提案しており、無関係な文脈の変化に対しては安定性を維持することを目指しています。これには、単純な合格/不合格の指標を超えて、文脈適応と文脈安定性のテストが含まれます。「どれだけの文脈」から「どの文脈」、「いつ」、そして「どれだけ信頼性高く」という点に焦点を移すべきです。リポジトリの文脈を、長期的なプロジェクトにとって不可欠な、ライフサイクルを持つ動的な実体として扱うことが重要です。将来のベンチマークは、ソフトウェア開発の進化する性質を反映するように、動的であるべきです。最終的な問いは、AIエージェントがアーキテクチャ、要件、依存関係、チームの慣習を含む、変化するソフトウェア環境の中で健全なエンジニアリング判断を維持できるかどうかです。この複雑な問題には、多様な思考アプローチが必要であり、可視化、説明、分析のための定義された「レンズ」を使用して構造化することができます。

Beyond Passing Tests: A 100-Lens Framework for Evaluating Context-Aware AI Coding Agents 🤖 dev.to

RSS Hunter • 昨日

コールバックが含まれている場合、フォームはポータブルではありません。

真にポータブルなフォームは、JSONシリアライゼーション以上のものが必要です。その検証、条件、および送信ロジックも転送可能でなければなりません。標準的なフォームライブラリは、コールバック内にビヘイビアを埋め込むことが多く、ポータブルではなく、バックエンド生成やマルチアプリケーションでの使用には不向きです。コールバックをソースコードとしてシリアライズしようとしたり、コンパクトなDSLを考案したりすることは、重大なセキュリティおよびメンテナンスのリスクをもたらします。代わりに、ビヘイビアはシリアライズ可能な式ツリーを通じて宣言的に表現されるべきです。このアプローチにより、検査可能で、バージョン管理可能で、独立して検証可能なデータ構造が可能になります。生の式ツリーは冗長ですが、TypeScriptビルダーのような型付きオーサリングAPIは、この複雑さを抽象化し、正規のJSON契約を生成できます。この契約は、普遍的な真実の情報源として機能し、さまざまなフロントエンドとバックエンドがフォームを一貫して解釈および検証できるようにします。決定的に、位置的なコレクションは、送信時にデータIDをサイレントに変更しないように慎重に処理する必要があります。ポータブルなフォームシステムは、信頼できない入力を安全に処理するために、堅牢な検証およびセキュリティ対策を採用し、破滅的なバックトラッキングや無効な構成などの問題を防止する必要があります。Modyraによって探求されているこのアーキテクチャアプローチは、複雑さを個々のアプリケーションから共有インフラストラクチャに移行させます。それは、必ずしも同一のレンダリングではなく、異なるランタイム間で同一の意味を保証することを目指しています。中心的な課題は、契約を過度に複雑にすることなく、どの程度のビヘイビアをポータブルデータとしてエンコードできるかを決定することにあります。

Your Form Is Not Portable If It Contains Callbacks dev.to

RSS Hunter • 昨日

Astroにおける静的フォーム：サーバーなしでの送信処理

Astroサイトは、静的コンテンツに最適ですが、フォーム送信には課題があります。onsubmit.devは、フォームを外部エンドポイントにPOSTできるようにすることで、サーバーサイドAPIルートの必要性をなくすソリューションを提供します。これは、GitHub Pagesのような静的ホスティング環境に最適です。最も簡単な方法は、ネイティブHTMLフォームの動作を活用し、クライアントサイドJavaScriptやハイドレーションされたコンポーネントを必要としません。このアプローチにより、JavaScriptが無効になっていてもフォームが機能することが保証されます。Astroサーバーエンドポイントの設定の複雑さを回避し、静的デプロイメントを真に静的なままにします。Astroの哲学は、シンプルなフォームのために不要なクライアントサイドランタイムを出荷しないため、このゼロJavaScriptパターンによく合致します。プログレッシブエンハンスメントは、送信の前提条件なしに、ユーザーエクスペリエンスを向上させるためにJavaScriptでレイヤー化できます。これには、インラインローディング状態やインプレースフィードバックなどの機能が含まれます。APIキーのような機密情報は、ブラウザサイドコードで決して公開してはならないことを覚えておくことが重要です。ホストされたフォームエンドポイントは、機密性の高いサーバーサイド処理を安全に処理します。クライアントサイド検証は、セキュリティのためではなく、ユーザーエクスペリエンスのためのものです。このパターンは、連絡先、フィードバック、またはウェイトリストのようなフォームに適しています。より複雑なワークフローの場合は、Astroサーバールートまたは別のバックエンドが必要になる場合があります。最終的に、外部エンドポイントを使用することは、一般的な静的Astroフォームのニーズに対してデプロイメントモデルをシンプルに保ちます。

Static Forms in Astro: Handling Submissions Without a Server dev.to

RSS Hunter • 昨日

絶対に失敗しない検証ルール

著者のスタジオは、言語モデル、テキスト読み上げ、レンダリングを伴う自動化されたパイプラインを通じて、子供向けのアニメーションカートゥーンを制作しています。このプロセスの重要な部分は、コンテンツの正確性を保証するバリデーションゲートです。そのようなゲートの一つは、話された単語が教えられている文字と正しく一致しているかを確認し、幼い視聴者にとって事実誤認を防ぎます。この文字チェックゲートを既存のエピソードすべてでテストしたところ、ほとんどのエピソードで問題が報告され、その有用性が実証されました。しかし、文字と単語のペアリングをチェックする特定のルールでは問題は報告されませんでした。調査の結果、著者はバリデーションに使用された正規表現に重大なバグを発見しました。単語の境界をチェックすることを意図した正規表現パターンは、文字列処理のために '\b' をリテラルのバックスペース文字として誤って解釈していました。これにより、パターンは実際のテキストに一致することが不可能になり、バリデーションルールは完全に無効になりました。この問題は、無効なパターンがエラーなくコンパイルされ、出力も生成されず、正しく機能しているように見えたため、微妙でした。この沈黙は重大な問題を隠蔽しており、ゲートは事実誤認を含むエピソードを通過させていたでしょう。著者は、コードを直接読むのではなく、既知の不正な入力に対して新しいゲートをテストするというルールに従うことで、このバグを発見しました。この実践は、一度も失敗したことのないゲートの信頼性の低さを明らかにしました。著者は、誤った入力を貴重なテストケースとして保持すること、および肯定的な結果をアサートすることを提唱しており、「クリーンな入力では問題なし」というテストと「ダーティな入力ではまさにこの問題」というテストを組み合わせています。また、ソースではなくコンパイルされたパターンを印刷して、不一致を検出することを強調しています。バックスペースのバグは、何も報告しないインジケータの典型的な例であり、正常な状態と誤解される可能性があります。正規表現が修正された後、ゲートは2つの異なるエピソードで、花が 'P' で始まるという不正確な主張を正常に特定しました。この冗長性は、特定のファイル形式ではなく、世界についてのステートメントとしてルールを記述することから生じ、有益であることが証明されました。この経験は、厳格なテストの重要性と、自動化されたシステムにおけるサイレントフェイラーの欺瞞的な性質を浮き彫りにしています。

The Validation Rule That Could Never Fail dev.to

RSS Hunter • 昨日

reCAPTCHA：「私はロボットではありません」だけではない

CAPTCHAは、歪んだテキストを読み取る能力をテストすることで人間とボットを区別するという当初の目的から大きく進化しました。この初期の方法は、初期のコンピューターに対しては効果的でしたが、機械学習の進歩とともに時代遅れになりました。コンピューターが歪んだ文字を認識する能力が向上するにつれて、CAPTCHAはより困難になり、画像を選択するなどの課題によってユーザーエクスペリエンスが低下しました。これにより、直接的なユーザーへの課題から、インタラクションの行動を分析するという根本的なアプローチのシフトが起こりました。GoogleのreCAPTCHA v3のような最新システムは、現在、高度なリスク分析を使用して、インタラクションがボットによるものである可能性を示すスコアを割り当てています。このスコアは、ユーザーの行動、デバイスとネットワークの情報、過去のインタラクションパターンを含む複数のシグナルを融合することによって決定されます。例えば、マウスの動き、タイピング速度、ナビゲーションパターンが異常を検出するために分析されます。アクション間の微妙なタイミングの違いでさえ、自動化されたアクティビティを明らかにすることができます。ブラウザの履歴は直接読み取られませんが、過去のインタラクションパターンは重要なコンテキストを提供します。デバイスとブラウザの環境も、インタラクションの正当性に関するシグナルを提供します。これらの様々な弱いシグナルを組み合わせたシグナル融合は、強力なリスク評価を作成します。その結果、課題はパズルを解くことから、人間の行動特性を説得力を持って模倣することへとシフトしました。正当なユーザーであっても、その行動が異常に見える場合は課題が出される可能性がありますが、システムは主に人間のアイデンティティを確実に証明することよりも、高リスクのインタラクションを特定することに焦点を当てています。この進化により、CAPTCHAは単純なテキストパズルから洗練された行動チューリングテストへと変貌しました。

reCAPTCHA: It’s Not Just “I’m Not a Robot” dev.to

RSS Hunter • 昨日

あなたの次のプロジェクトのための、依存関係のない無料のJS/PHPコンポーネント17個

このライブラリは、npmやバンドラーなしで直接組み込めるように設計された、17個のスタンドアロンでフレームワークに依存しないコンポーネントを提供します。各コンポーネントは、必要に応じて独自のCSSとSVGをカプセル化した単一のファイルであり、統合を簡素化します。16個はピュアJavaScriptですが、「ac_pdf」はPHPで、サーバーサイドのPDF生成にFPDFを利用しています。このコレクションには、「ac_notif_modale」による通知、「ac_note_etoiles」によるレーティングウィジェット、「ac_slider」による強化されたレンジスライダーなど、多様なツールが含まれています。「ac_tags」によるタグ入力フィールド、「ac_signature」による署名パッド、「ac_fichier_upload」によるドラッグ＆ドロップファイルアップロードも注目すべきコンポーネントです。リッチなデータ表示のために、「ac_graphique」による依存関係のないSVGチャート、「ac_timeline」によるインタラクティブなタイムライン、「ac_agenda」による様々なビューを備えたフルカレンダーがあります。マッピング機能は「ac_carte」によって提供され、インタラクティブなマップのためにLeafletを自動的にロードします。「Ac_big_select」はAJAX検索による大きなドロップダウンに対応し、「ac_onglets」はHTMLをアクセシブルなタブに変換します。ユニークな点は、フランス語圏のクライアント向けに、メソッドとオプションの命名規則がフランス語であることです。このライブラリは使いやすさを重視しており、「ac_graphique」の簡単なインスタンス化の例で実証されています。すべての無料コンポーネントの完全なデモとドキュメントはオンラインで利用可能です。さらに、より要求の厳しいアプリケーションのために、プレミアムコンポーネントとして「ac_sidebar」や高性能なデータグリッド（「ac_datagrid」、「ac_datagrid_pro」）が提供されています。データグリッドは共通のエンジンを共有しており、数百万行でのテストが行われ、堅牢なパフォーマンスを示しています。

17 free, dependency-free JS/PHP components for your next project dev.to

RSS Hunter • 昨日

Trae + SQLazy: 複雑なSQLの記述に関する実践ガイド

AI支援によるデータ開発は、直接的なSQL生成または中間表現を用いたレイヤードアプローチのいずれかを利用して、SQLライティングを変革しています。この記事では、Trae（AIプランニング）とSQLazy（実行レイヤー）の複合モデルに焦点を当てます。この連携により、「AIプランニング＋人間によるレビュー＋決定論的エンジン実行」のフレームワークが確立されます。プロセスには、プロジェクト知識のロード、要件の明確化、タスクの分解を経て、Traeが段階的なSQLazyスクリプト（.nspl）を生成することが含まれます。SQLazyのIDEは、単一のスクリプトからの段階的な実行、リアルタイムデバッグ、およびクロスデータベースコンパイルを容易にします。ワークフローは、環境設定から始まり、詳細なビジネス要件でTraeをトリガーします。最も重要なフェーズは、SQLazy IDEでの検証と修正であり、中間結果を確認するためにテストデータが使用されます。4つの実世界のケーススタディがこの方法論を例示しています：統計集計、複数テーブルのマージ、クロスサブグループデータフィル、および金額配分です。より単純なケースは一度で正しく処理されましたが、クロスサブグループデータフィルや金額配分のような複雑なシナリオでは、反復的な修正が必要でした。クロスグループフィルケースでは、直接的な結合キーが不適切な場合に、行番号をマッピングブリッジとして使用することの重要性が強調されました。金額配分ケースは最も複雑で、特に丸め処理と残りの分配に関して、合計を維持するために、構文とロジックを洗練させるために複数の反復が必要でした。

Trae + SQLazy: A Practical Guide to Writing Complex SQL dev.to

RSS Hunter • 昨日

Unityのためのコンテキストエンジニアリング：実際のプロジェクトでAIを役立てる方法

AIコーディングツールは、完全なプロジェクトコンテキストの欠如により、制御されたデモでは複雑なUnityプロジェクトよりもはるかに優れたパフォーマンスを発揮します。AIの統合を成功させるには、Unityのバージョン、パッケージの詳細、アーキテクチャの境界、プラットフォームの要件を含む、明示的なプロジェクト情報を提供する必要があります。コンテキストエンジニアリングは、AIに不可視の依存関係を可視化するようにプロジェクトを整理し、有用でレビュー可能な変更を保証することを含みます。明確な受け入れ基準を持つ小さく焦点を絞ったタスクは、広範な機能リクエストよりも効果的です。AIは、Unityのバージョン、シーンの所有権、実行順序、またはプラットフォーム固有の動作のような重要な詳細を推測してはなりません。自動テストは、AIによって生成されたコードを検証し、提案を検証可能な証拠に変換するために不可欠です。よく構造化されたプロジェクトブリーフは、既存の決定、禁止されている変更、および「完了」の明確な定義を概説する必要があります。タスクは検証可能な単位に分解され、クロスシステム変更の場合はコードの前に計画が要求されるべきです。開発者は、コード行数だけでなく、受け入れられた変更とレビューコストを測定する必要があります。目標は、AIを検証されていない実験的なコードのソースではなく、効果的なアシスタントにすることです。

Context Engineering for Unity: How to Make AI Useful on Real Projects dev.to

RSS Hunter • 昨日

スキャナーは問題なしでした。割引コードは40回有効でした。

チェックアウトフローの自動セキュリティスキャンでは、SQLインジェクションやクロスサイトスクリプティングのような従来の脆弱性は発見されませんでした。ジュニアペンテスターは、スキャナーの結果に基づいて、このエンゲージメントに重大な発見はないと判断する準備ができていました。しかし、チームメンバーが、割引コードを適用するエンドポイントが、注文確認後までコードを無効化しないことに気づきました。この設計上の欠陥により、一度しか使用できないコードが同時に複数回利用される可能性がありました。同じリクエストを同時に送信することで、一度しか使用できない50%割引コードが数秒以内に40回利用されました。このタイプの脆弱性、つまり競合状態は、コードの有効性をチェックしてから使用済みとしてマークするまでの間に発生するギャップによって引き起こされます。自動スキャナーは、リクエストを逐次的にテストし、同時にテストしないため、競合状態を検出できません。脆弱なエンドポイントは、クーポンを redemption する、または資金を引き出すといった、「チェックしてから実行する」パターンを伴うことがよくあります。競合状態を悪用するには、ネットワークジッターを最小限に抑えるために、リクエストを単に迅速にではなく、同時に送信する必要があります。Burpの競合状態タブやTurbo Intruderのようなツールは、この目的のために設計されています。競合状態の証拠は、単に成功したレスポンスコードだけでなく、コードが適用された回数といったシステムの最終状態にあります。この種のビジネスロジックの欠陥はスキャナーでは見逃され、同時アプリケーションの動作に関する手動調査が必要です。Codelivlyのリソースとラボは、自動スキャン機能を越えたこれらの高度な脆弱性に焦点を当てています。

The Scanner Came Back Clean. The Discount Code Still Worked 40 Times. dev.to

RSS Hunter • 昨日

CAD-PHP通貨の優位性：なぜマニラは2026年に5倍の割安なのか

著者は、米国拠点のSaaSスタートアップがフィリピンからエンジニアリング人材を採用することに significant な経済的利点があることを強調しています。彼は、米国とフィリピンの開発チーム間の stark なコスト差に気づき、ほとんどの北米の創業者が見落としていることを認識しました。グローバルな人材市場は逼迫しており、特にリモートワークが一般的になっている現在、地域に基づいたコスト裁定を無視することはますます困難になっています。フィリピンは、熟練した開発者、英語力、有利な為替レートを提供しており、通貨が強い企業にとって substantial な財政的利益を生み出しています。5倍の開発コストの優位性は現実であり、マニラのチームが同等の米国チームよりも significantly 低コストであったプロジェクトによって実証されています。フィリピンの開発者の高い英語力は生産性向上に繋がり、コミュニケーションの問題を最小限に抑え、時間を節約します。タイムゾーンの違いは管理可能であり、非同期コミュニケーションと構造化されたワークフローを通じて、ほぼ24時間の開発サイクルに活用することさえできます。著者は、単一の「ロックスター」開発者を雇うよりも、強力なリーダーシップを持つまとまりのあるチームを構築する方が効果的であることを学びました。創業者は、為替レートを調査する、小規模なパイロットプロジェクトを特定する、フィリピンでの採用に成功した人々とネットワークを築くといった具体的なステップを踏むことができます。これらの行動は、スタートアップがランウェイを最適化し、貴重な人材プールにアクセスするのに役立ちます。フィリピンの開発者のコスト効率を理解し活用することは、効率性と持続可能性のための戦略的な動きです。著者は、これらの利点を活用して、より強力で持続可能なビジネスを構築することを提唱しています。

The CAD-PHP Currency Edge: Why Manila Is a 5x Bargain in 2026 dev.to

RSS Hunter • 昨日

🚀 Pythonaibrain-Warden (v0.1.0) を発表：Python 用の産業グレード、npm にインスパイアされたパッケージ＆環境マネージャー

warden (pythonaibrain-warden v0.1.0) のリリースは、Python パッケージ管理における速度と再現性の間の競合を解決することを目的としています。Warden は、決定論的なロックファイル、仮想環境の分離、オフラインビルド機能を持つ npm にインスパイアされたワークフローを導入します。そのコア機能は warden.lock ファイルであり、正確なアーティファクト URL と SHA-256 ハッシュを強制し、望ましくないバージョンの置換を防ぎます。薄い CLI アーキテクチャは、ターミナルから使用する場合でもプログラムで呼び出す場合でも、一貫した動作を保証します。Warden ネイティブ環境とサブプロセス呼び出しでの絶対パスは、クロスプラットフォームの解決問題を排除します。ファイルごとの依存関係ターゲットは、同じリポジトリ内で相互に排他的なパッケージ要件を可能にします。プラットフォームホイール選択は、システムタグに対して PyPI バイナリを正しく解決します。fix コマンドは、プロジェクト要件を変更せずに環境のドリフトに対処します。warden build は、ゼロネットワークデプロイメントのための自己完結型のオフラインバンドルを作成します。最後に、warden verify は、深い検証と再現性を確保するための CI ゲートを提供します。

🚀 Announcing Pythonaibrain-Warden (v0.1.0): Industrial-Grade, npm-Inspired Package & Environment Manager for Python dev.to

RSS Hunter • 昨日

AWSセキュリティイベントを7つのMITRE ATT&CKタクティクスで見る

大和セキュリティのセキュリティエンジニアである西川明氏は、HITCON 2026でSuzakuとSenriganを用いたAWSの脅威検出について発表しました。この記事では、MITRE ATT&CK Enterprise Tacticsに沿ったAWS CloudTrailイベントを要約します。著者は、攻撃の検出は単一のイベントではなく複数のイベントの相関関係に依存すること、そしてATT&CKによる検出の整理はインシデント対応に文脈を与えることを強調しています。MITRE ATT&CKフレームワークは、その14の戦術とともに、AWS環境での実用性から選択されており、特に初期アクセス、発見、認証情報アクセス、永続化、権限昇格、防御回避、影響といった7つの主要な戦術が重要視されています。初期アクセスは、侵害されたアクセスキーが関与することが多く、アカウントIDとユーザーIDを特定するための最初の呼び出しとしてGetCallerIdentityが一般的です。発見には、IAM権限とリソースの列挙が含まれ、急速な複数リージョンAPI呼び出しやAccessDeniedイベントの増加といった不審なパターンは、潜在的な悪意のあるアクティビティを示唆します。認証情報アクセスはAWSのインスタンスメタデータサービス（IMDS）を頻繁に標的とし、IMDSv2の強制による防止が推奨されます。永続化の手法には、新しいIAMユーザーの作成、フェデレーショントークンの悪用、API Gatewayを使用したLambda関数の活用などが含まれます。信頼ポリシーやIDプロバイダーの改ざんも、永続化メカニズムとして機能します。

AWS Security Events Through the Lens of the Seven MITRE ATT&CK Tactics dev.to

RSS Hunter • 昨日

AIスプライトジェネレーター：2Dキャラクターアートをゲーム対応アニメーションに変換

ゲーム開発では、キャラクターアートの作成と利用可能なアニメーションアセットの間でボトルネックが生じることがよくあります。Spritix AIは、単一の2Dキャラクターイラストを再利用可能なゲームアニメーションのセットに変換することで、この問題に対処するために設計されたAIスプライトジェネレーターです。ワークフローは、キャラクター画像をアップロードし、アイドル、ウォーク、ラン、ジャンプ、アタックなどのアクションを選択し、AIによって生成された結果を確認して反復処理することを含みます。Spritix AIは、元のキャラクターを参照することで、異なるアクション間でプロポーション、パレット、スタイルの整合性を確保します。アートディレクションや手動でのクリーンアップの代替にはなりませんが、繰り返し行われるセットアップタスクを大幅に削減します。このツールは、PNG、GIF、JSONなどの標準ファイル形式で出力するため、Unity、Godot、またはWebフレームワークなどのさまざまなゲームエンジンへの統合が容易になります。エクスポート設定では、フレーム数、セルサイズ、ループ用のトリミングをカスタマイズできます。ソロ開発者、テクニカルアーティスト、ゲームジャムチーム、および2Dゲームを実験しているWeb開発者は、このツールから恩恵を受けることができます。Spritix AIは、アニメーション化されるのを待っているキャラクターが、単一の参照画像で命を吹き込むのを支援することを目指しています。ワークフローは、Spritix AIのウェブサイトで探索できます。

AI Sprite Generator: Turn 2D Character Art into Game-Ready Animations dev.to

RSS Hunter • 昨日

Raspberry Piで5つの開発者ツールAPIを構築し、RapidAPIに掲載する方法

著者は、一般的な開発者タスクのための信頼性の高いAPIエンドポイントの必要性に対処するために、小規模なAPIハブを構築しました。これらには、AIプロンプトの最適化、JSON検証、JSONフォーマットと変換、テキストの可読性/SEO分析が含まれます。使用された技術スタックは、Dockerコンテナ内のPythonのFastAPIで、Raspberry Pi 4でホストされていました。Cloudflare Tunnelは、ルーターポートを開くことなく安全なリモートアクセスを提供し、ドメインはGitHub Pagesで管理されました。APIハブはRapidAPIマーケットプレイスでローンチされました。成功の重要な要素は、寛大な無料ティアを提供し、ユーザーが有料プランにコミットする前にAPIをテストできるようにしたことでした。検索エンジン最適化、特にブログ投稿にFAQスキーマを含めることは、オーガニックトラフィックを促進し、Googleの回答スニペットを確保するのに効果的であることが証明されました。Cloudflare Tunnelは、そのセキュリティ機能と使いやすさから、ホームラボホスティングに理想的なソリューションと見なされました。しかし、Redditのr/programmingやStack Overflowのようなプラットフォームでのプロモーション活動は、厳格なセルフプロモーションポリシーのため成功しませんでした。開発者への直接のコールドアウトリーチも、低い応答率しか得られませんでした。著者は、SEOやAPIマーケットプレイスの活用のようなインバウンドマーケティング戦略が、導入を促進するためにより効果的であると結論付けています。ユーザーは、RapidAPIの無料ティアを通じてAPIハブを探索するか、著者のウェブサイトで完全なドキュメントにアクセスできます。

How I Built 5 Developer Tool APIs on a Raspberry Pi (And Listed Them on RapidAPI) dev.to

RSS Hunter • 昨日

バニラJSで、依存関係のないサイドバーをドラッグ＆ドロップとマグネティックスナップ機能付きで構築しました。

ac_sidebar は、フレームワーク、ビルドステップ、または外部 CSS ライブラリなしで動作する、サイドバーコンポーネント専用のユニークな JavaScript クラスです。独自の CSS と SVG アイコンセットを直接統合しており、完全に自己完結型です。このコンポーネントは、再帰的な構造を持つ 2 つのメニューレベルとロールベースのフィルタリングを提供し、メニューが空の場合は自動的に非表示にすることができます。左、右、上、下、または磁気スナップを備えたドラッグ可能な「フリー」モードの 5 つの位置をサポートします。サイドバーは、アイコンレールに折りたたむか、バーガーボタンの後ろに隠すことができます。また、エントリごとにカウンターバッジを備え、単一ページに複数のインスタンスをサポートし、localStorage を使用して状態を永続化できます。開発者は、設定オブジェクトで ac_sidebar を直接インスタンス化するか、外部 JSON ファイルからロードできます。注目すべき特徴は、その設定キーと値がフランス語であることで、フランス語圏のクライアント向けに元々開発されたことを反映しています。たとえば、「left」には「gauche」、「light」には「clair」が使用されます。このクラスは、artisan-code.fr によって維持されているスタンドアロンで依存関係のない JS/PHP クラスのコレクションの一部です。フルフレームワークの使用が不要または過剰なプロジェクトのために特別に構築されています。

I built a dependency-free sidebar with drag-and-drop and magnetic snapping , in vanilla JS dev.to

RSS Hunter • 昨日

MCPが解決しないもの

この記事では、従業員のオフボーディングの例を用いて、複雑な本番ワークフローにおけるマルチ・ケイパビリティ・プロトコル（MCP）の限界について論じている。MCPはツールの呼び出しとセキュリティ制御を標準化するが、ビジネスロジックや権限を固有に扱うものではない。システムはツールの存在と有効な引数を検証できるが、マネージャーが実際に解雇時間を変更できるかどうかまでは検証できない。この記事は、トランスポート認可はビジネス認可とは異なり、サーバーへのクライアントアクセスのみを検証し、ビジネスアクションの有効性を検証しないことを強調している。本番ワークフローには、要求者、実行者、主体、承認者といった複数のアイデンティティが含まれており、これらが統合されると、誤解を招く監査証跡が作成される。堅牢なランタイム環境には、結果を伴うツールの呼び出しの前に、アクションが許可される理由を説明するための「実行エンベロープ」と呼ばれるコンパクトな記録が必要である。このエンベロープには、権威あるイベント、ポリシーバージョン、実行後タイムスタンプなどの詳細が含まれ、アクションを公式記録に結び付け、早期または不正なアクションを防ぐ。承認は、雇用状況や法的保留などの重要な情報が実行時間に近づくまで再検証が必要となるため、事実関係が変更された場合に失効する可能性がある。書き込み操作中のタイムアウトは失敗を確認するものではなく、リトライまたは調整戦略を導くために、べき等性キーやステータスルックアップなどの実行詳細を公開する必要があることを示唆している。最終的に、ワークフローの整合性に対する責任は分散されたままである。ホストはツールの公開を管理し、ランタイムはポリシーを評価してリカバリを処理し、MCPサーバーはリクエストを検証し、ターゲットシステムは自身の記録に対して権威を持つ。これらの制御の実装にはコストがかかるが、アカウント無効化のような高影響度の操作においては、正確な権限、現在の証拠、および失敗セマンティクスが最重要であるため、必要不可欠である。

What MCP Doesn't Solve dev.to

RSS Hunter • 昨日

Spring Data Tests が見逃す可能性のあること：Hibernate の永続化コンテキストを超えたテスト (第7章)

すべてのEntityManagerは、現在の永続化コンテキスト内のエンティティのIDマップである、第一レベルキャッシュを維持します。find()が既に管理されているエンティティに対して呼び出された場合、Hibernateはデータベースに問い合わせることなく既存のオブジェクトを返します。これは標準的なL1キャッシュの動作です。しかし、@DataJpaTestを使用した標準的なSpring Dataテストでは、実際のデータベース永続化ではなく、このL1キャッシュの状態を誤って検証してしまうことがあります。これにより、本番環境になるまで、制約違反の欠落やカラムマッピングのバグといった重大な問題が隠蔽される可能性があります。本稿では、実際のデータベースインタラクションを強制し、それによってテストが真の永続化を検証することを保証するテストアーキテクチャを紹介します。このアーキテクチャは、明示的なEntityManagerのクリア戦略、汎用的なテストフィクスチャ、およびインメモリ分離を採用しています。テスト専用のプロキシが、create()、update()、delete()などのDAO操作をラップし、各書き込み後に自動的にEntityManager.flush()とEntityManager.clear()を呼び出します。これにより、Hibernateは変更をデータベースに書き込み、その後L1キャッシュをクリアすることを強制され、後続の読み取りはキャッシュされたオブジェクトではなく、データベースから直接データを取得することを保証します。このプロキシレイヤーはテストスコープ専用であり、本番コードへのパフォーマンス影響を防ぎます。loadById()やカスタム@Queryメソッドのような読み取り操作については、プロキシは介入しません。これらの操作は、クリア後に新しいデータを取得するか、本質的に実際のSQLを発行するためです。さらに、TablesEraserユーティリティを使用して、各テストの前にすべてのテーブルを空にし、クリーンなスキーマを保証し、テスト間で第二レベルキャッシュの汚染やバッチ処理の副作用を防ぎます。このプロセスでは、DELETE FROMステートメントを使用し、トランザクションを尊重し、安全なロールバックを提供します。AbstractCrudTestCaseやAbstractSearchableTestCaseのような再利用可能な抽象テストクラスは、一般的なCRUDおよび検索機能に対する共有アサーションを提供します。これらの抽象クラスは、構造的に同一のテストケースを処理し、ボイラープレートを削減します。一方、具体的なテストクラスは、ドメイン固有のペイロード生成を実装し、独自のクエリメソッドのテストを追加します。このレイヤードアプローチにより、基底クラスが共通の動作を管理し、特定のDAOが拡張およびカスタマイズする必要がある場合にそれを行うことができます。このシステムの有効性の重要な例として、テストケースであるtestSearchNullParamsがあります。これは、検索操作の境界条件を特別にチェックします。このテストは、nullのParamsオブジェクトが渡された場合に、search()実装の初期バージョンでNullPointerExceptionを明らかにしました。これは、デプロイ前に実際のワールドの問題を検出する設計能力を検証し、堅牢性を確保しました。

What Spring Data Tests Can Miss: Testing Beyond Hibernate’s Persistence Context (Chapter 7) dev.to

RSS Hunter • 昨日

Construyendo un recomendador de emparejamiento de expertos

このテキストは、専門知識を必要とする人々を資格のある専門家と結びつけるように設計された複雑なレコメンデーションシステムについて説明しています。典型的なレコメンデーションシステムとは異なり、このシステムは、専門家の限られたキャパシティや、不適切なレコメンデーションのコストの高さといった独自の課題に直面しています。複数の独立した専門家ファインダーからの結果を組み合わせるために、Reciprocal Rank Fusion を使用したハイブリッド検索手法を採用しています。スコアリングメカニズムは、明示的な方向性の一致、セマンティック類似性、スキルの一致、キャパシティ、専門家の質、専門分野の一致、公平性など、さまざまな要因の重み付けされた組み合わせです。専門家の質は、経験を考慮するために飽和指数関数を使用し、ベテランが完全に支配することを防ぎます。公平性は、露出に対する対数減衰を組み込み、あまり頻繁に推奨されない専門家にも機会が与えられるようにします。重要なことに、システムは、最も人気のある専門家が圧倒されるのを防ぐために、個々のトップNレコメンデーションではなく、グローバルな割り当て問題として機能します。貪欲な割り当てアルゴリズムが使用され、専門家のキャパシティ制限を尊重しながら、よりスコアの高いペアリングを優先します。データレイヤーは、どのスキルが価値があるかを判断するために、防御可能な統計に焦点を当てています。これには、新しさに対する指数関数的な減衰を伴うソースの重み付け、歪んだデータ分布を処理するための重み付け中央値、およびスキルの価値と役職を混同しないようにするための役職、役職レベル、経験による層別化が含まれます。スキルの値のポイント推定値の代わりにブートストラップ信頼区間が使用され、より堅牢な測定値を提供します。重要なドライランにより、専門家の利用可能性を著しく制限する過剰な除外ルールや、レコメンデーションに明確な根拠が欠けている傾向など、重大な欠陥が明らかになりました。トレンドバッジも、意味のあるベースラインの欠如により、誇張された値を示しました。これらの発見は、複雑なレコメンデーションシステムにおける慎重な実装と継続的な評価の重要性を強調しています。

Construyendo un recomendador de emparejamiento de expertos dev.to

RSS Hunter • 昨日

Next.jsとLaravelでPickToolを構築する：ソフトウェア発見プラットフォーム作成からの学び

ソフトウェアの選択は、膨大な数の選択肢と一般的な比較記事のために困難です。PickToolは、機能、価格設定、ユースケース、比較を含むAIおよびSaaSツールの構造化された情報を提供することで、この問題を解決することを目指しています。プラットフォームは、フロントエンドにNext.js、バックエンドにLaravelを使用した疎結合アーキテクチャを採用しており、これらのコンポーネントの独立した進化を可能にします。コンテンツはリレーショナルにモデル化され、カテゴリ、ツール、ガイド、比較間の相互接続されたデータにより、意図的な内部リンクを促進します。作成者は、不完全なコンテンツでの早期スケーリングは有害であり、薄いページや一貫性のない情報につながる可能性があることを学びました。代わりに、一度にメールマーケティングのような1つのトピッククラスターを強化するという集中的なアプローチが取られています。検索エンジン最適化はアプリケーションアーキテクチャに最初から組み込まれており、インデックス可能なすべてのページには特定のSEO要素が必要です。パフォーマンスもコンテンツの問題と見なされており、初期のページロードを効率的に保ち、不要なデータを回避するための努力が行われています。疎結合されたバックエンドとフロントエンド間の整合性を維持することは、公開ページに予測可能なデータを提供するために不可欠です。比較プラットフォームにとって透明性は非常に重要であり、PickToolはツールの評価方法を説明することに取り組んでいます。もしやり直すなら、作成者はまず1つの狭いカテゴリに焦点を当て、最低限の公開要件を定義し、データモデルで内部リンクを設計します。また、発見と編集コンテンツを分離し、ワークフローに監査を組み込みます。今後の優先事項には、メールマーケティングクラスターの強化、ツールページと比較の改善、評価方法論の洗練が含まれます。PickToolは、プロダクトデザイン、データモデリング、パフォーマンス、編集基準を統合することに焦点を当てた進行中のプロジェクトです。

Building PickTool with Next.js and Laravel: Lessons from Creating a Software Discovery Platform dev.to

RSS Hunter • 昨日

実行よりも計画：157回のエージェント実行からの教訓とOrcaスタイルのエージェントフリートの台頭

157のAIエージェント展開に関する重要な研究により、成功の主な決定要因は実行速度やモデルサイズではなく、計画の質であることが明らかになりました。この観察結果から、階層的で計画を優先する「Orcaスタイル」のエージェントが開発されました。この研究では、多様なユースケースにわたるエージェントアーキテクチャ、計画の深さ、実行モデルが変更されました。計画により多くのトークンを割り当てたエージェントは、タスク完了率が大幅に高く、ロールバックが少なくなりました。この背後にある経済的原則は、計画は実行中に犯された間違いを修正する高コストと比較して安価であるということです。Orcaスタイルのエージェントは、計画と実行を分離し、戦略プランナーが複雑な推論を処理し、専門のエグゼキューターが定義されたタスクを実行します。スペシャリストは、その能力を説明する「スキルカード」を持ち、共有メモリレイヤーが状態を維持します。効果的な実装パターンには、検証ゲート付きの再帰的分解、スペシャリストルーティング、ステートフルコンテキスト伝播が含まれます。回避すべき落とし穴は、過剰な計画、過度のスペシャリストの断片化、サイレントな再計画、コンテキストウィンドウのホードです。Orcaスタイルのフリートは、マルチステップワークフローおよびハイステークオペレーションに推奨されます。コストモデルは、複雑なタスクにおいてOrcaスタイルのアーキテクチャを支持しており、リトライやエスカレーションの減少により、総トークンコストが削減されています。AIエージェントの将来は、専用のツールやライブラリによる計画能力の強化に焦点を当てる可能性が高いです。中心的な洞察は、思慮深い計画がエージェンティックワークの最も重要な側面であるということです。Orcaスタイルの計画の実装は、目標を分解し、各ステップを検証する単一のプランナー関数から始めることができます。

Planning Over Execution: Lessons from 157 Agent Runs and the Rise of Orca-Style Agent Fleets dev.to

RSS Hunter • 昨日

私のキャプション幅ガードは全てのテストをパスしました。それはレンダラーが描画しなかったテキストを測定していました。

字幕のセグメンテーションが不十分であるというユーザーからの苦情が、新たな微妙な問題を引き起こすバグ修正につながりました。元々の問題は、字幕が文の構造を無視して固定の単語チャンクに分割されていたことでした。これにより、文の途中で切れるなど、意味不明な分割が発生していました。修正では、句読点を尊重し、チャンクあたりの単語数を特定の値にすることを含む、より良いチャンク分割のためのルールが実装されました。重要な追加機能は、レンダリングされたチャンクが画面に収まるようにするためのピクセル幅の上限でした。この幅の上限は、実際にレンダリングされたテキストの幅を測定することを意図していました。しかし、テキストの幅を測定するコードは、測定前にテキストを誤って大文字に変換していました。これは、視覚的なスタイルを意図してすべて大文字を使用するビデオパイプラインの別の部分からステップを借用したためでした。選択されたフォントでは、大文字のテキストは混合ケースのテキストよりも幅が広くなります。測定は大文字に変換された入力に対して正確でしたが、実際の字幕は元の混合ケースでレンダリングされていました。この不一致により、幅の制限はテキストがはるかに広いと判断し、不要な分割を強制しました。これにより、最初の問題よりも悪いユーザーエクスペリエンスである1単語のチャンクが作成されました。重要なことに、幅測定関数は受け取った入力（大文字に変換されたテキスト）に対して正しく動作したため、すべての自動テストは合格しました。テストでは、測定されたテキストが実際に画面にレンダリングされたテキストと一致するかどうかを確認しませんでした。このバグは、レンダリングされたビデオを視聴していた人間によってのみ発見されました。この状況は、一般的な落とし穴を浮き彫りにしています。つまり、テキスト変換のような仮定に合意することになっている、本番環境と検証用の別々のコードパスです。これらの仮定がずれると、自動テストが見逃す微妙なバグが出現します。著者は、パス間で変換関数を共有すること、または実際にレンダリングされた出力を定期的にサンプリングして検査することを緩和策として提案しています。人間の監視なしにテストスイートのグリーンのみを信頼すると、このような微妙な乖離が気づかれずに存続する可能性があります。

My Caption Width Guard Passed Every Test. It Was Measuring Text the Renderer Never Drew. dev.to

RSS Hunter • 昨日

4つのアラームスロット、3つの障害モード：スリープ、レース、タイムアウトを乗り越えるナイトリードレインの構築

Claude Codeの会話は、設計上、永続的なメモリを持たないため、ユーザーはコンテキストを繰り返し説明する必要があります。この長期記憶の欠如は、特に複数のプロジェクトを管理する際に生産性を低下させます。これを克服するために、著者はClaude CodeのログをObsidianボルトにエクスポートする毎晩実行されるスクリプトを開発しました。この自動化されたプロセスにより、手動での要約の必要がなくなり、ユーザーの意志力に関係なく知識が保存されるようになります。Obsidianは、ローカルのMarkdownファイル、Gitバージョン管理、およびリンク機能により、効果的な外部ブレインとして選択されました。スクリプトの開発中に、堅牢な3層設計を必要とする3つの重大な障害が発生しました。Macがスクリプト実行中にスリープ状態になった際にスリープフリーズの問題が発生し、処理が不完全なままになりました。スケジュールされたスクリプト実行と手動実行が重複した際にダブル実行レースが発生し、Gitの競合を引き起こしました。最後に、大量のログ処理がスクリプトの時間制限を超えた際にタイムアウト障害が発生しました。これらの障害により、マルチスロット再実行システム、スリープ防止のためのcaffeinate、およびステップマーカーを使用した冪等性のあるリトライが実装されました。この設計により、中断された場合でも、処理は中断された場所から再開されます。システムは現在、Claudeセッションログから始まり、生の会話ファイル、Obsidianボルト、そして最終的にはプライベートGitリポジトリへと進む4層アーキテクチャを備えています。スクリプトの複数のスケジュールされたスロットは冗長性を提供し、後続の実行で未完了のタスクを引き継ぐことができます。Caffeinateはシステムのスリープを防ぐために使用され、ロックディレクトリはスクリプトの同時実行を防ぎます。冪等性のあるリトライは、完了したステップをマークすることで達成され、スクリプトは既に処理されたセグメントをスキップできます。これにより、障害が発生した場合でも、毎日の取り込みプロセスは最終的に完了することが保証されます。launchd plistの設定とPATHの調整（nvm node discoveryを含む）により、スクリプトは最小限の実行環境で確実に実行されます。macOSのプライバシー保護によるサイレントな障害を防ぐために、/bin/bashのフルディスクアクセスが早期にチェックされます。スクリプトは、初期シグナルが無視された場合でも、GNU coreutilsのtimeoutを使用したrun_to関数を利用して、プロセスの終了を保証します。この包括的なセットアップにより、Claude Codeの会話のための回復力のある外部メモリが作成されます。

Four Alarm Slots, Three Failure Modes: Building a Nightly Drain That Survives Sleep, Races, and Timeouts dev.to

RSS Hunter • 昨日

ESP32 + Python:マイコンからIoTへ

この記事では、IoTプロジェクトでPythonとESP32を使用するシリーズを紹介します。ESP32は、Wi-FiとBluetooth機能を内蔵した強力なマイクロコントローラーです。センサーと対話したり、デバイスを制御したりすることができ、本質的にはArduinoのより高度なバージョンです。Pythonは、読みやすい構文を持つ高水準プログラミング言語で、1991年に初めてリリースされました。汎用性が高く、ハードウェア通信を含むさまざまな分野で使用されています。モノのインターネット、またはIoTとは、通常インターネットに接続された物理デバイスを指し、データを収集および交換します。これらのデバイスは、多くの場合、タスクを自動的に実行できます。ESP32とPythonの組み合わせは、ハードウェアとソフトウェアを橋渡しし、インタラクティブで接続されたアプリケーションを可能にします。たとえば、ESP32はセンサーデータを読み取り、Wi-Fi経由で送信して処理およびアクションを実行できます。この相乗効果は、IoTおよびその他のハードウェア・ソフトウェアプロジェクトを構築するための強力な基盤を提供します。この入門記事は、実践的な例と理論を掘り下げる今後の記事の準備をします。目標は、ESP32とPythonを効果的に通信させる方法を教えることです。

ESP32 + Python: From Microcontroller to IoT dev.to

RSS Hunter • 8月23日

99% トークン精度、学習ゼロ。RLによるビジョンモデルのファインチューニングからのフィールドノート。

著者は、ビジョン・言語モデルのファインチューニングの経験を回想し、多くの失敗はアルゴリズムの欠陥ではなく、運用上の問題に起因することを強調しています。18時間の教師ありファインチューニングでは99%のトークン精度を示しましたが、実際の評価指標である多肢選択問題の正答率は変化しませんでした。これは、自由形式の推論を教師ありで学習させている一方で、単一の抽出された回答を評価していたため、プロキシ指標のドリフトが発生したことを示しています。GRPOトレーナーは、2つのライブラリがシーケンス長について意見が一致せず、画像パディングトークンが2回カウントされたためにクラッシュしました。これは、コンポーネントの境界における統合バグを示唆しています。著者は、このようなモンキーパッチには、バグが静かに再導入されるのを防ぐための安価な回帰テストが必要であることを学びました。重要なRLループでは、長期間にわたって学習が停滞しましたが、これは最終的に報酬パイプラインのラベルノイズと逆転したアドバンテージ信号に起因することが判明しました。この「静かな」失敗は、クラッシュを示さず、学習の欠如のみを示しており、報酬計算の徹底的な監査の必要性を強調しています。これらの経験から、すべてのトレーニング実行に不可欠な「ハーネスルール」が生まれました。これらには、コンピューティングリソースをコミットする前にスモークテストを実行すること、スコアリングされていない実行がスコアリングされた実行と誤解されないように実行がフェイルクローズでゲートされることを保証すること、インフラストラクチャの障害とモデルのパフォーマンスの低下を厳密に分離することが含まれます。決定的なのは、保持された評価指標のみが真の決定要因と見なされ、他のすべての指標は単なるテレメトリとして機能することです。著者は、これらの「退屈な」ルールが信頼できる結果を得るために不可欠であることを強調しています。

99% token accuracy, zero learning. Field notes from fine-tuning vision models with RL. dev.to

RSS Hunter • 8月23日

ログレベル設計とローテーション：アプリがDEBUG/INFO/WARNING/ERRORを使用する理由

アプリケーションログは、DEBUG、INFO、WARNING、ERRORといった様々なラベルを使用しており、これらは主にフィルタリングの閾値として機能します。Pythonのloggingモジュールは、DEBUG（10）のきめ細かな詳細から、アプリケーションの失敗を示すCRITICAL（50）まで、5つのレベルを定義しています。ロガーのレベルをINFOに設定すると、数値が20以上のメッセージのみが記録されます。これにより、開発者は通常の運用ログを煩雑にすることなく、詳細な診断ステートメントを埋め込み、調査が必要な場合にのみそれらを有効にすることができます。例示されているアプリケーション、maintenance_agent.pyは、ログ出力をRotatingFileHandlerとStreamHandlerにルーティングし、初期設定はINFOにされているため、通常はDEBUGメッセージは抑制されます。アプリケーション内のログ呼び出しの分布は、その設計上の想定を反映しており、INFOは進捗、WARNINGは回復可能な問題、ERRORは実際の障害に使用されます。CRITICALは、アプリケーションがサイト固有の障害を独立して処理するように設計されているため、使用されていません。RotatingFileHandlerによって実装されるログローテーションは、最大サイズとバックアップ数を設定することで、ログファイルが無制限に大きくなるのを防ぎます。このメカニズムにより、ログ履歴は過剰なディスク容量を消費することなく保存されます。別のハンドラ、_SiteLogCaptureは、個々のサイトメンテナンス実行のための一時的なログを収集し、レポートやメールを生成した後、破棄します。これは、複数のハンドラが同じログストリームを異なる目的（長期履歴対一時的な特定の使用）のために処理できることを示しています。ログレベルは詳細さに対する垂直フィルタとして機能し、ハンドラの選択は対象者と目的に対する水平フィルタとして機能します。

Log Level Design and Rotation: Why Apps Use DEBUG/INFO/WARNING/ERROR dev.to

RSS Hunter • 8月23日

同じトークン。異なるDNA。なぜテキサスのノートブックがパーラーになってはいけないのか。

ほとんどのエージェント再設計は、真の変革を欠いた、表層的なものに過ぎません。"/reimagine-it" コントラクトは、ソースからすべての名詞、日付、および色を抽出することを要求します。その後、ウェブページやインフォグラフィックポスターのような、明確に区別できるアーティファクトを作成する必要があります。重要なのは、同じコマンドトークンを持つ2つのソースがレイアウトクロムを共有してはならないということです。主な失敗ケースは、再設計が単にゴールドのレイアウト上で名詞を入れ替える場合です。例えば、「Jules Ice Cream」の出力は、「Texas notebook」のレイアウトに似ていてはなりません。このスキルは、意図的にこの表層的な類似性を避ける必要があります。「Texas notebook」は、一般的なゴールドスターロゴではなく、実際のテキサス州の旗のSVGを生成する必要があります。同様に、「Jules Ice Cream」は、テキサス州の地図にスクープを乗せたものではなく、パーラーの環境を想起させるべきです。ここでのインフォグラフィックとは、ダッシュボードや履歴書のチャートではなく、共通スケールのエンコーディングとロスレステーブルを備えた紙のポスターを意味します。AntV Infographicは、直接インポートするためのテンプレートではなく、構造的なガイドです。プロジェクトは、ギャラリー、GitHubリポジトリ、およびさまざまなプラグイン/CLIコマンドからアクセスできます。誤った出力とは、「Jules Ice Cream」のデザインがテキサスのゴールドと区別がつかない場合や、ソースに存在しない名詞を発明した場合です。

Same tokens. Different DNA. Why a Texas notebook must not become a parlor. dev.to

RSS Hunter • 8月23日

自社ハードウェアに対してAWS CLIを実行する方法

開発者はAWS CLIをよく利用しますが、これはamazonaws.comへの接続を前提としており、切断された環境では機能しません。これにより、チームはオンプレミスデプロイメントのために、別個でコストのかかるツールチェーンを維持せざるを得なくなり、運用モデルの乖離が生じます。Spinifexは、ローカルのハードウェア上で動作する同一のAWS APIサーフェスを提供することで、この問題を解決します。これにより、既存のAWS CLIコマンド、SDK、およびTerraformのようなツールはシームレスに機能し続けます。ユーザーは、AWSプロファイルのエンドポイントURLを変更するか、個々のコマンドで--endpoint-urlフラグを使用するだけです。Spinifexは、モックではなく、実際のEC2コンピューティング、EBSボリューム、S3ストレージ、およびEKSクラスターを提供します。これにより、エアギャップデプロイメントは、クラウド環境と同じ自動化、Terraform設定、およびIAMポリシーを使用できます。これは、切断されたフィールドデプロイメント、セキュアな施設、データ主権、および定常ワークロードのコスト管理の要件を満たします。既存のスクリプトに必要な唯一の変更は、エンドポイントのオーバーライドです。興味のある方のために、完全なセットアップガイドと無料のサンドボックスが利用可能です。

Running the AWS CLI Against Your Own Hardware dev.to

RSS Hunter • 8月23日

5つのコーディングエージェントを1つのウィンドウで並べて実行する方法

NestMuxは、ユーザーが独立したペインのグリッドで複数のAIコマンドラインインターフェース（CLI）およびターミナルを実行できるデスクトップアプリケーションです。各ペインは、独自のユーザーアカウントとGitワークツリーによって分離された、個別の環境として機能します。コア機能は、node-ptyを介してシェルを起動し、HOMEディレクトリをリダイレクトし、現在の作業ディレクトリを設定し、ユーザーコマンドを入力することに依存しています。主な機能の1つは「ブロードキャスト」モードであり、単一のキーストローク入力をすべてのアクティブなペインに同時に送信し、複数のAIエージェントに対して均一なプロンプトを可能にします。このシンプルな実装は複雑なプロトコルを回避しますが、制御コマンドを含むすべての入力が無差別にブロードキャストされることを意味します。AIエージェントは子プロセスまたは再親化されたプロセスとして実行されることが多いため、各ペインのリソースの帰属を特定することは大きな課題であり、特定のワークツリーに属するプロセスを識別するためにファイルシステムベースのヒューリスティクスが必要です。レビューのために、NestMuxは各ワークツリーのGit diffを生成および解析しますが、パフォーマンスの問題を防ぐために非常に大きなファイルのレンダリングを制限するという意図的な決定がなされています。ペインの設定やレイアウトを含むアプリケーションの状態は、session.jsonにアトミックに保存され、クラッシュからの復旧を保証します。ただし、ターミナルのスクロールバックとセッション履歴は再起動間で保持されず、ペインは再起動され、CLIは再実行されます。この設計上の選択は、エージェントを不透明なプロセスとして扱うことで新しいエージェントの統合を簡素化しますが、ペイン間の統一されたログやタイムラインがなく、インタラクションや変更の追跡が困難になるという重大な制限につながります。このクロス・ペイン・インサイトの欠如は、個々のエージェントの出力を解析しないこととのトレードオフです。NestMuxはクロスプラットフォームで、ローカルファーストであり、現在ローンチフェーズ中は無料です。

How we run five coding agents side by side in one window dev.to

RSS Hunter • 8月23日

私はbadBANANA脅威観測所を一般に広めました

このプロジェクトは、印象的なプレゼンテーションよりも証拠を優先する脅威可視化ツールを作成したいという長年の願望から生まれました。既存の多くの脅威マップは視覚的に魅力的ですが、分析的な深みに欠けることが多く、マーケティングや教育など、異なる目的を果たしています。著者は、観察と動きの感覚を維持しつつ、基盤となるデータがインターフェースの表示を厳密に正当化するようなものを作り上げることを目指しました。これにより、CISA KEVやThreatFoxなどのソースを監視するbadBANANA Threat Observatoryが作成されました。重要なのは、ダッシュボード自体だけでなく、堅牢な証拠処理に焦点を当てたことです。著者は、システムが知っていることを過大評価しないように、欠損データがゼロになったり、無効なインジケーターが再分類されたりする問題に対処するために、システムを綿密に監査しました。これには、IOCおよびハッシュのより厳格な検証、より安全なエクスポート、および慎重なデプロイメントゲートが含まれていました。現在のバージョンは、ソースが報告するもの、変更されたもの、保持されたもの、拒否されたものの間に明確な区別を維持しています。これにより、境界付きAPIは境界付きに見え、失敗したソースは失敗したように見え、欠落した信頼性は欠落したままになります。Observatoryは、アナリストを置き換えることや、ライブグローバルサイバー戦争を暗示することを意図したものではなく、ギャップを静かに埋めることなく証拠の検査を容易にすることを目的としています。公開リリースは、その整合性を確保するために、複数の監査と修正パスを経て行われました。

I pushed the badBANANA Threat Observatory public dev.to

RSS Hunter • 8月23日

私は1日かけて、実際のオープンソースのバグを3つ修正しました。

著者はDEV Summer Bug Smashチャレンジに参加し、実装前は失敗し実装後は成功するテストを伴う実際の修正に注力しました。彼らの努力は、1日で3つのオープンソースプロジェクトに及びました。最初に対処されたバグは、AIアシスタントであるOpenClawにあり、設定変更のキャンセルが誤ってゲートウェイの再起動を引き起こしていました。この修正により、キャンセル操作が実際の実行構成に戻り、不要な再起動を防ぐことが保証されました。2番目のバグは、Rocket.ChatのデザインシステムであるFuselageに関係しており、Sliderコンポーネントのトラックフィルが右から左のロケールやゼロ以外の最小値で正しくレンダリングされませんでした。これは、フィルがコンポーネントの状態に基づいて位置を計算し、ロケールの方向に正しく適応するようにすることで解決されました。3番目のバグはnpmx.devで見つかり、多くの複雑なTypeScript型をレンダリングできず、「unknown[unknown]」と表示されていました。著者は、さまざまなTypeScript型の種類に対して11個の新しいフォーマッターを実装し、npmパッケージのAPIドキュメントの表示を大幅に改善しました。各修正は、説明的なコミットメッセージと付随するテストとともにプルリクエストとして提出されました。著者は、小さく再現可能なバグケースを作成することが重要であり、最初に失敗するテストは非常に価値があり、プロジェクトの慣例を理解することが時間を節約することを学びました。その日は、3つのプロジェクトにわたる3つの動作する修正と、それぞれに合格したテストスイートをもたらしました。

I spent one day smashing three real open source bugs dev.to

RSS Hunter • 8月23日

Ryker: ブラウザ内蔵のHTMLおよびMarkdownビジュアルエディタ、エージェント対応の変更エクスポート機能付き

HTMLの大型言語モデルにおける有用性は高まっていますが、生成されたHTMLドキュメントの手動編集は煩雑になる可能性があります。従来、HTMLはソースコードを介して編集されてきましたが、これは開発には効果的ですが、校正や軽微なコンテンツ調整にはあまり適していません。この問題に対処するため、Chrome拡張機能であるRykerが、HTMLおよびMarkdownのビジュアル編集のために開発されました。Rykerは、これらのビジュアル編集をプロンプト対応の変更要求として記録します。その意図は、より直感的なドキュメントレビュープロセスを促進することです。編集はドキュメント自体で直接行われます。Rykerはこれらの変更を機械可読テキストとしてキャプチャします。これらの変更要求は、実装のために言語エージェントに返送できます。このシステムは、エージェントの役割を完全に置き換えるのではなく、補完することを目的としており、エージェントが最終的な実行を管理しながら、自然なレビューを可能にします。Rykerは、ブラウザでのライブHTMLページの直接編集と、ローカルHTMLおよびMarkdownファイルの編集を可能にします。記録されたすべての編集は、プロンプト対応の変更要求としてエクスポート可能です。詳細情報とインストールについては、提供されたリンクで入手できます。

Ryker: In-Browser Visual Editor for HTML and Markdown with agent-ready change exports dev.to

RSS Hunter • 8月23日