Solid Queue が Rails 8 のデフォルトになった経緯、およびオープンソースのメンテナンシーについて

37signalsのプリンシパルプログラマーであるRosa Gutiérrez氏は、Rails 8のデフォルトのバックグラウンドジョブキューであるSolid Queueを開発しました。以前の37signalsでは、チームはバックグラウンドジョブ管理のために7つの別々のgemを使用していましたが、これは非効率的なアプローチであると認識しました。これにより、Redisのような個別のインメモリサービスに依存するのではなく、最新の高速なデータベースストレージを活用するSolid Queueが開発されました。内部ツールからRailsのデフォルトへの移行は、大量のインシデントとプルリクエストの増加を意味しました。Gutiérrez氏は、整理されていないgemのデバッグ経験から、Solid Queueのデザインにおける可読性の高いコードの重要性を強調しました。彼女は、Solid QueueがAIコードアシスタントの広範な使用前に開発されたと述べました。Rubyエコシステムは現在、AIエージェントへの適合性とコミュニティのコンベンション・オーバー・コンフィギュレーションの原則により、復活を遂げています。Gutiérrez氏は、コントリビューターの行動の変化を説明し、AIエージェントが現在頻繁にインシデントとプルリクエストを開いていると述べました。彼女は、これらのAIによる貢献はしばしば丁寧で適切にフォーマットされていると指摘しました。著者は、以前の人間による貢献と現在のAIによる貢献との対比に注目すべき点を見出しました。

How Solid Queue Became the Rails 8 default, and More on Open Source Maintainership dev.to

RSS Hunter • 今日

TPU開発者ハブ：高性能AIプラットフォームの技術レビュー

GoogleのTPUデベロッパーハブは、機械学習の実践者にとって、特殊なアクセラレーションハードウェアへのアクセスを簡素化することを目的としています。このハブは、ドキュメント、ガイド、および事前設定された環境を一元化し、効率的なTPUトレーニングに必要な時間を短縮します。MaxText、Pathways、Vertex AI統合などの抽象化レイヤーを導入し、導入を容易にします。アーキテクチャ的には、TPUは静的なテンソル形状を持つ大規模な密モデルのトレーニングに優れており、GPUと比較して大幅なスループット向上とコスト効率を提供します。これは、行列乗算に最適化されたSystolic Arrayアーキテクチャによるものです。金融機関にとって、これは不正検出、信用スコアリング、センチメント分析モデルのトレーニングコストの削減につながります。 しかし、ハブは、特に規制された金融環境におけるすべての摩擦点を解決するわけではありません。JAXとのエコシステムロックインは、PyTorchに慣れたチームにとって課題となります。Google Cloud外での限定的なオブザーバビリティは、手動でのインストルメンテーションを必要とします。コンプライアンスとデータレジデンシーの問題は、Google Cloudに保存されるデータに対して、法的および技術的な慎重な検討を必要とします。重要な落とし穴には、ダイナミックシェイプがパフォーマンスに与える悪影響や、TPUポッドの可用性保証の欠如があり、堅牢なチェックポインティングが必要です。推奨されるマルチクラウドパターンには、Google CloudのTPUでトレーニングし、AWSで推論を行い、各プラットフォームの強みを活用することが含まれます。データ準備とスキーマ検証はAWS内で行われ、トレーニングのためにGoogle Cloudにレプリケートされます。その後、モデルはエクスポートされ、AWSにデプロイされて低レイテンシの推論を行い、コンプライアンスを維持します。オーケストレーションはAWS Step Functionsによって管理され、コントロールプレーンはAWSに配置され、監査および変更管理との統合が行われます。責任ある導入には、ワークロードプロファイルを検証し、本番環境でTPUを採用する前に潜在的な落とし穴を慎重に対処することが必要です。

TPU Developer Hub: A Technical Review of a High-Performance AI Platform dev.to

RSS Hunter • 今日

ピクセルから計画へ：AWS上のジオスパイシャルデータプラットフォーム

Google Research の「pixels to planning」イニシアチブは、コンピュータービジョンモデルを超えた堅牢なデータプラットフォームの重要な必要性を強調しています。主な課題は、ペタバイト規模の地理空間データを効率的に処理することです。衛星画像を基本的な S3 パーティショニングで単純なログファイルのように扱うと、時間的および空間的なニーズの競合により、法外なクエリコストが発生します。より効果的なソリューションには、GeoParquet と地理空間述語プッシュダウンを備えた Apache Iceberg を使用することが含まれ、スキャンされるデータを大幅に削減します。 AWS 上の金融グレードの地理空間パイプラインは、取り込みから消費までの多段階プロセスを伴います。これには、S3 への生データの着陸、GeoParquet/Iceberg に変換されたキュレーション済みデータ、SageMaker を介してトレーニングおよびデプロイされた機械学習モデルが含まれます。年/月、H3 グリッド解像度、センサーの 3 段階階層を採用した地理空間パーティショニングは、コストとレイテンシを管理するために不可欠です。H3 の一貫したセル面積は、予測可能なパーティションサイズを保証し、複雑な幾何演算なしでクロスセンサー結合を容易にします。 このパイプラインの構築には、S3 ライフサイクルポリシーの設定、Glue 変換ジョブの開発、Lake Formation による詳細なアクセス制御の実装など、慎重な計画が必要です。監査および規制遵守のために、データセットスナップショットとコードバージョンへの完全なトレーサビリティを備えた機械学習モデルのトレーニングは最重要です。API Gateway を介して推論機能を制御されたレイテンシで公開し、OpenTelemetry でオブザーバビリティを実装することは、運用上の信頼性のために不可欠です。 Iceberg テーブル上の GeoParquet は、基盤となるアーキテクチャの改善を表し、大幅なコスト削減を提供し、クエリ時の地理空間結合を排除します。地理空間データが金融上の意思決定に影響を与える場合、特にラインエージトレーサビリティとしてのデータガバナンスはオプションではなく、規制要件となります。高解像度の位置データは本質的に機密性が高いため、複数の防御層を備えたゼロトラストセキュリティモデルの実装が必要です。このアプローチは、高度な地理空間アプリケーションのデータの整合性、セキュリティ、およびコンプライアンスを保証します。

Pixels to Planning: Geospatial Data Platforms on AWS dev.to

RSS Hunter • 今日

アカウントは単なるストレージではありません。それらはSolanaが高速である理由の一つです。

Solanaは、mempoolなしで高速処理を可能にする並列実行を可能にするブロックでトランザクションを処理します。アカウントはデータを格納し、プログラムはスマートコントラクトと同様に実行可能なコードを含みます。Solanaには複数のアカウントタイプが存在し、それぞれが異なる機能を果たします。例えば、System Programは、すべて1で構成される固定のオーナーアドレスを使用します。Solanaのアカウントアドレスは、秘密鍵で保護された公開鍵、またはProgram Derived Addresses (PDA) のいずれかです。PDAは、特定のシードとプログラムIDを使用してプログラムによって決定論的に生成されます。これらのPDAはプログラムによって所有され、スマートコントラクトによって管理されるセキュアなボールトのように機能します。公開鍵を持つユーザーアカウントは、PDAとの関係においてオーナーとして機能します。Solanaは、効率的なトランザクション処理のために動的な並列アカウントロックを採用しています。トランザクションは、バリデーターエンジンに事前にすべての関連アカウントを宣言する必要があります。このシステムは、二重支払いを防ぐためにRead-LockとWrite-Lockを利用します。重要なのは、このロックメカニズムにより、無関係なアカウントを同時に処理でき、ネットワークのボトルネックを回避できることです。

Accounts are not just storage. They're one of the reasons Solana is fast. dev.to

RSS Hunter • 今日

BedrockにおけるGPT-5 vs Claude vs Nova：プロダクションガバナンスの対決

Amazon Bedrock は、既存のオプションと並んで GPT-5.5 や Codex のような高度なモデルを統合することで、エンタープライズ AI の中心的なプラットフォームになりつつあります。これにより、モデルが AWS のセキュリティおよびガバナンスフレームワーク内に配置され、規制産業におけるコンプライアンスが簡素化されます。以前は、外部モデルを使用することは AWS の制御を迂回することを意味していましたが、Bedrock と IAM ポリシーおよび CloudTrail との統合により、これが解決されます。ただし、ネットワーク遅延と AWS アカウント外のモデルウェイトの常駐は、厳密な分離ニーズにとって引き続き考慮事項です。 本番環境のパフォーマンスはベンチマークとは異なり、負荷下での動作と一貫した遅延に焦点を当てています。Claude 3.7 Sonnet は、監査可能な拡張推論により、エージェントワークフローで優れています。GPT-5.5 は強力な推論を提供しますが、ネイティブ API と比較して出力に対するきめ細かな制御は less granular です。Amazon Nova Pro は、ネイティブ統合により際立っており、ファインチューニングを可能にし、トークンあたりの最も低いコストを提供します。 効果的な AI システムの運用は、OpenTelemetry のようなツールを使用して、モデルの出力とビジネスコンテキストを相関させるオブザーバビリティにかかっています。実際のコストは、トークン価格を超えて、プロンプト効率、リトライ、および運用オーバーヘッドを含みます。GPT-5.5 は Claude 3.7 Sonnet よりも高価であり、特に大量のタスクでは Nova Pro よりも大幅に高価です。 Bedrock でのバッチ推論は、Claude と Nova のコスト削減を提供しますが、GPT-5.5 は Bedrock を介してまだサポートされていません。サードパーティモデルの 1 分あたりのトークン制限は慎重な管理が必要であり、ワークロードごとに個別の AWS アカウントが必要になる可能性があります。複雑さと要件に基づいて最も適切なモデルにリクエストをインテリジェントにルーティングするルーティングパターンは、コストとパフォーマンスを大幅に最適化できます。同じセキュリティおよびオブザーバビリティツールを異なるモデル全体で活用するこの統一されたガバナンスアプローチは、複数のフロンティアモデルを効果的に管理するという課題に対処します。

GPT-5 vs Claude vs Nova on Bedrock: A Production Governance Bake-off dev.to

RSS Hunter • 今日

モダンKYC：金融サービスにおけるサーバーレス、AI、および監査証跡

従来のKYCプロセスは非効率的でコストがかかり、オープンファイナンスやインスタントペイメントのような現代の要求に対応するのに苦労しています。ワークフローの問題として扱われがちなこの時代遅れのやり方は、新しいアーキテクチャパラダイムに取って代わられつつあります。KYCの未来は、AIをコパイロットとして強化された、イベント駆動型のサーバーレスシステムに関係しています。監査可能性は、もはや単なるコンプライアンスの afterthought ではなく、主要なアーキテクチャ上の懸念事項となり、すべての決定が透明で追跡可能であることを保証します。 このシフトの主な推進要因には、AWS Step Functionsのようなサーバーレスオーケストレーションツールの成熟と、Amazon TextractやBedrockのようなサービスを通じたAIによるドキュメント抽出および検証の進歩が含まれます。規制遵守は、AWSのセクター固有の認証によって大幅に容易になり、マネージドサービスの監査スコープを削減します。最新のKYCパイプラインは、ドキュメントの取り込みからリスクスコアリングまで、各ステップがオーケストレーションされ、不変にログに記録されるイベント駆動型のフローで設計されています。 この新しいアーキテクチャにおける監査可能性は、最終的な決定だけでなく、各段階で使用された正確なデータ、プロンプト、およびモデルバージョンをキャプチャすることを意味します。WORM（Write Once, Read Many）機能を備えた安全な場所に保存されるこの詳細な記録は、規制監査に不可欠です。アーキテクトは現在、オーケストレーションによる障害処理の集中化、AIを単独の意思決定者ではなくサポートツールとして使用すること、およびすべてのコンポーネントが冪等であることを保証することに焦点を当てる必要があります。 サーバーレスKYCの実装には、プロビジョンドコンカレンシーによるLambdaコールドスタートの管理や、低品質のドキュメントによる潜在的な精度問題への対処といったトレードオフが伴います。AI推論のスケーリングコストは慎重な検討が必要であり、外部APIのスロットリングにはインテリジェントなキャッシング戦略が必要です。組織的には、専用のKYC Design Authority、意思決定のオブザーバビリティへの投資、およびAIプロンプトをバージョン管理されたインフラストラクチャとして扱うことが、成功裡な導入に不可欠です。マルチリージョン展開の計画と、監査における生成AIの非決定的な性質への対処も、アーキテクトにとって重要な考慮事項です。

Modern KYC: Serverless, AI and Audit Trails in Financial Services dev.to

RSS Hunter • 今日

1つの組織か、それとも複数か？誰も書きたいと思わない事後分析

金融機関は、コストガバナンスのために単一のAWS Organizationに事業部門を統合しましたが、ルートノードに適用したサービスコントロールポリシー（SCP）の誤りにより、47分間の本番環境停止が発生しました。コストの一元的な可視性、単一ポリシーの強制、自動化の簡素化へのプレッシャーがこのアーキテクチャ上の決定につながりました。コンプライアンスのためにAWSリージョンを制限しようとしたセキュリティチームが、ルートにSCPを適用したことで、意図せず決済パイプラインの重要なDynamoDB呼び出しをブロックしてしまいました。これは、決済アカウントがブロックされたリージョンのDynamoDB Global Tablesエンドポイントを使用しており、初期監視ではエラーが検出されなかったために発生しました。 インシデントのタイムラインは、SDKエラーからサーキットブレーカーのトリップ、そして最終的には当初のトラブルシューティングの方向性を誤らせたアラートへと、段階的な障害を示しています。根本原因は、単一Organizationアーキテクチャに起因する、設計上の制限のない影響範囲（blast radius）であることが特定されました。これは単なる人的ミスではありませんでした。この設計では、決済のような規制対象ワークロードと運用ワークロードとの間に分離が欠けていました。階層的なSCPを持つ単一のOrganizationは、ルートレベルのSCPがすべてのアカウントに同時に影響を与え、ネイティブな段階的ロールバックがないことを意味します。 このテキストは、この問題のある単一Organizationパターンと、より強力な分離境界を提供する修正されたマルチOrganizationアプローチを対比させています。複数のOrganizationは、独立したポリシーライフサイクル、別々の管理アカウント認証情報、そして監査人がより容易に受け入れるクリーンな規制分離を提供します。複数のOrganizationは運用上の複雑さとランディングゾーン自動化の重複を増加させますが、これらは対処可能な問題です。直接的な技術的修正には、ルートまたは重要なOUへのポリシーの添付を防ぐためのガードレールSCPの実装が含まれていました。 中期的には、PCI-DSSワークロードのために2番目のAWS Organizationが作成され、セキュリティとポリシーの独立性が強化されました。AWS OrganizationsイベントをSlackとPagerDutyにキャプチャすることでオブザーバビリティが向上し、平均検出時間（MTTD）が劇的に短縮されました。SCPの根本的な問題は、通常のインフラストラクチャコードとは異なり、即時の伝播とステージングまたは自動ロールバックの欠如です。これを解決するために、SCPのイミュータブルステートレジストリが実装され、数秒以内の自動ロールバックが可能になりました。

One Org or Many? The Postmortem Nobody Wants to Write dev.to

RSS Hunter • 今日

ADR: 本番環境でのAmazon Bedrock AgentCoreの採用

著者は、AWSの金融プラットフォームアーキテクトであり、規制された金融環境でAIエージェントを運用するためにAmazon Bedrock AgentCoreを採用する際の意思決定プロセスを詳述しています。従来の方式では、午前2時の障害や規制遵守といった重要な運用上の懸念に対処するのが困難でした。5つの主要な要因が緊急の解決策を必要としました。クロス・ターンの状態管理、規制上のトレーサビリティの確保、堅牢なガードレールの実装、予測不能なトークンコストの管理、そしてランタイムのポータビリティの達成です。EKS上でのセルフホストソリューション、Bedrock Agentsの以前の世代、そしてStep FunctionsとLambdaの使用を含む、いくつかの選択肢が検討されました。 EKS上でのセルフホストオプションは、高い運用責任とエンジニアリングコストのため却下されました。Bedrock Agentsの以前の世代は、限定的なオブザーバビリティと予算管理のため不十分と判断されました。Step Functionsは、決定的なワークフローにおける強みにもかかわらず、会話型エージェントのランタイムとしては不適切と見なされました。Amazon Bedrock AgentCoreは、セッションメモリ、ガードレール、トレーサビリティ、ツール使用のためのネイティブ機能を備えたマネージドランタイムを提供し、推奨されるソリューションとして登場しました。 AgentCoreを選択する決定的な要因は、ツールごとのOAuth2/OIDCサポートを備えたGatewayと、金融におけるセキュリティとコンプライアンスに不可欠な設定可能なTTLを持つマネージドセッションメモリでした。著者は、ランタイムにおけるプラットフォームロックインのトレードオフを認めつつも、基盤となるツールのポータビリティを強調しています。この記事では、効果的かつ安全な運用にとっての重要性を強調しながら、ガードレール、AgentCoreメモリ、Gateway、およびトークン予算に関する具体的な設定上のアドバイスを提供しています。TurnsPerSession、TokensPerSession、ToolCallFailureRate、GuardrailInterventionRateなどのオブザーバビリティメトリクスが概説されており、詳細なトレーシングと規制監査のためにX-RayとCloudTrailを活用することも示されています。著者はまた、ランタイムロックイン、保守的なクォータ、ガードレールのレイテンシ、メモリコストを含む結果とリスクについて警告し、慎重な受け入れと緩和戦略を求めています。

ADR: Adopting Amazon Bedrock AgentCore in Production dev.to

RSS Hunter • 今日

CloudWatchからOTelへ：オブザーバビリティブリッジパターンの解体

CloudWatchからOpenTelemetryへのブリッジパターンは、AWSメトリクスを統一されたオブザーバビリティバックエンドに統合する必要がある金融プラットフォームで一般的に使用されるソリューションです。その主な目的は、AWSサービスから外部システムにメトリクスを転送することで、断片化されたオブザーバビリティを解決することです。このパターンでは、通常、AWSサービスがCloudWatchにメトリクスを発行し、それがCloudWatch Metric Streamsによってキャプチャされるか、GetMetricData API経由で取得されます。これらのメトリクスは、Lambda関数またはOpenTelemetry CollectorによってOpenTelemetry形式に変換され、DatadogやGrafanaのようなオブザーバビリティバックエンドに送信されます。 しかし、この「明白な」ソリューションには隠れた複雑さが伴います。特に、メトリクスの鮮度とAPIコストが重要な高ボリュームの金融環境では顕著です。このパターンには2つの主要な取り込みパスがあります。Kinesis Firehoseを備えたCloudWatch Metric Streamsは、低レイテンシと予測可能なコストを提供しますが、GetMetricDataによるポーリングは、きめ細かな制御を提供しますが、APIレート制限に達するリスクがあり、高コストが発生する可能性があります。堅牢な変換Lambdaは、冪等性があり、外部エンドポイント用のサーキットブレーカーを含み、アラーム付きのデッドレターキューを備えている必要があります。 このパターンは、外部のOTLP対応バックエンドが必要な場合、メトリクス量がストリームコストに見合う場合、そして60秒以下のメトリクス鮮度SLOが必要な場合に適しています。また、オブザーバビリティをAWSから分離し、トレースとメトリクスの相関を可能にします。セキュリティは最重要であり、リソース条件付きの厳格なIAMポリシー、転送中のデータのKMS暗号化、および制御されたネットワークエグレスが必要です。避けるべきアンチパターンには、単純なポーリング、適切なエラー処理や予約済み同時実行機能を持たないLambda関数、およびこのメトリクス中心のブリッジを介してログやトレースを転送しようとすることなどが含まれます。適切に設計された実装は、ストリームレベルでのメトリクスのフィルタリングを優先し、効率的なバッファリングを使用し、ブリッジ自体をオブザーバビリティのために計装し、厳格なセキュリティ対策を採用します。

CloudWatch to OTel: Tearing Down the Observability Bridge Pattern dev.to

RSS Hunter • 今日

OpenSearch ServerlessによるエージェンティックRAG：パターンの解剖

著者は、新しいエージェンティックAI中心のOpenSearch Serverlessを批判し、コールドスタート、コストの爆発、サーバーレスがアーキテクチャの必要性をなくすという誤解といった潜在的な落とし穴を強調しています。古典的なRAGは、LLMがツールを反復的に呼び出し、多様なデータ間でクエリを再構築するエージェンシーに苦労します。金融エージェントは、複数のインデックスにわたる高速で低遅延のベクトル検索を必要とします。OpenSearch Serverless OCUsはコレクションごとにスケーリングされ、アイドルコレクションのコールドスタートは重大な遅延問題です。エージェンティックRAGパターンは、取り込み、埋め込み、およびオーケストレーター、ツール、メモリを備えた反復的な検索-生成サイクルを含みます。主要な構成には、低遅延のためのHNSWインデックス作成と、検索品質のためのメタデータフィルタリングを備えた階層的なチャンキングが含まれます。取得したドキュメントをクロスエンコーダーで再ランク付けすると、精度が劇的に向上します。サイジングの考慮事項には、OCUメモリ制限、P99ベクトル検索遅延、およびコールドスタート時間があります。このパターンは、トラフィックの変動、知識の不均一な成長、およびマルチテナンシーに適しています。エンドツーエンドのエージェント応答が500ms未満のSLOには不適切です。アンチパターンには、フィルタリングのないマルチテナント単一インデックス、キャッシュされていないクエリ埋め込み、再ランク付けなしの高k、バッチ取り込みのOCUコストの無視、および冪等性のない取り込みパイプラインが含まれます。セキュリティは、KMS CMK、最小権限IAMロール、VPCエンドポイント、およびクエリ監査を義務付けています。オブザーバビリティには、インフラストラクチャの監視、アプリケーショントレース、およびオフライン検索品質メトリックが必要です。

Agentic RAG with OpenSearch Serverless: Anatomy of a Pattern dev.to

RSS Hunter • 今日

EC2 G7e: 生成ビデオ推論のためのアーキテクチャ決定

このドキュメントは、金融環境における生成ビデオ推論のためのGPUインスタンス選択に関するアーキテクチャ上の決定を概説するものです。生成ビデオ推論は、時間的状態、GPUメモリ帯域幅、および厳格なレイテンシ要件により、画像推論と比較して独自の課題を提示します。モデルはかなりのVRAMを必要とし、クリップの長さと解像度はメモリ消費量を直接増加させます。NVIDIA L40S GPUを搭載した新しいEC2 G7eインスタンスは、48 GBのVRAMを提供し、CPUオフロードを排除することでこのニーズに対応します。この決定に影響を与える主要なアーキテクチャ上の要因には、トークンあたりのコスト対時間あたりのコスト、地域の利用可能性とデータ居住性規制、テナント分離要件、およびコールドスタート時間があります。G5、G6、およびG7eインスタンスのようなオプションを評価する際、G7eは、720p-1080pビデオで90秒未満のレイテンシSLOを持つ本番ワークロードにとって、好ましい選択肢として浮上します。Amazon Bedrockは、スパイクやG7eが利用できない地域でのマネージドフォールバックとして推奨されます。提案されたアーキテクチャは、G7eのオーケストレーションとコールドスタートを軽減するためのウォームプール戦略のためにKarpenterを備えたEKSを使用します。セキュリティとコンプライアンスは、テナント固有の暗号化、Pod IAMのためのIRSA、プロンプトインジェクション保護、および包括的な監査可能性によって対処されます。G7eの48 GB VRAMと改善されたメモリ帯域幅は、より高速な推論時間と厳格なレイテンシ要件への準拠を可能にする、重要な進歩を示しています。

EC2 G7e: Architecture Decision for Generative Video Inference dev.to

RSS Hunter • 今日

MiCAは機械可読なレポートを要求します。あなたのエージェント決済スタックは人間可読なログを生成します。

MiCAの完全施行まであと8日となり、重要でありながら見過ごされがちな要件は、エージェント決済システムにおける機械可読レポートです。規制当局は、継続的な準備金の透明性と独立した監査のために、PDFではなく、構造化されクエリ可能なデータを必要としています。人間の監査員のために設計された従来の決済システムは、これらの新しい要求を満たせない非構造化テキストログを生成します。エージェント決済のライフサイクルは、決定、交渉、確認が人間の支払いとは異なり、機械可読の追跡がないため、特に困難です。 MiCAは、標準化された機械可読フォーマットでのリアルタイム、イベント駆動型の準備金レポートを義務付けています。独立した監査は、監査ツールが取り込めるフォーマットでエクスポートされた、完全で構造化されたトランザクションログを必要とします。現在、エージェント決済ログは非構造化であり、一貫したスキーマがなく、クエリが困難であるため、重大なコンプライアンスリスクをもたらします。規制要件と現在のアージェント決済スタックの機能との間には、大きなギャップがあります。 EU AI法およびGENIUS法も、機械可読出力に基づいたレポート義務を課しています。エージェント決済で欠けている主な要素には、決定の帰属、ポリシーの遵守、および集計エクスポージャーが含まれており、これらはブロックチェーントランザクションだけでは導き出せません。コンプライアンスをガバナンスレイヤーに統合する企業は、規制対応時間、監査コスト、および市場アクセスにおいて優位性を得ます。コンプライアンスを後付けとして扱うと、数週間の手作業による再構築が必要になりますが、コンプライアンスネイティブなソリューションは、即座に構造化されたデータアクセスを提供します。選択肢は、7月1日までに機械可読コンプライアンスか、非コンプライアンスかのどちらかです。

MiCA Demands Machine-Readable Reporting. Your Agent Payment Stack Produces Human-Readable Logs. dev.to

RSS Hunter • 今日

地図の仕組み、メルカトル図法、タイル、そしてGPSのピン

Google マップのようなインタラクティブマップは、2つの基本的な数学的概念に基づいて構築されています。1つ目は、地球の球状の表面を平坦な画面に投影する方法です。2つ目は、この平坦な投影図を、効率的な読み込みのために、より小さく管理しやすい正方形のタイルのグリッドに分割することです。これらの原則を理解することで、マップアプリケーションの機能が明らかになり、正確な位置計算が可能になります。 中心的な課題は、地球の丸みと平坦なディスプレイを調和させることです。これには、緯度と経度を画面座標に変換する数学的ルールであるマップ投影が必要です。ほとんどのウェブマップは、角度と局所的な形状を維持し、方向が一貫しており、常に北が上になるようにするため、Web Mercator投影を使用しています。しかし、この投影は面積を著しく歪ませ、極地方を不釣り合いに大きく見せます。 メルカトル投影は、経度を直接x軸にマッピングすることで地球を平坦化します。一方、緯度は対数関数を使用して変換され、赤道付近よりも極付近の領域をより大きく引き伸ばします。この対数変換が、メルカトル投影の仕組みの鍵となります。結果として得られる投影された世界は、256x256ピクセルのタイルのクワッドツリー構造に分割されます。 これらのタイルは、ズームレベルに基づいた階層システムで整理されており、各タイルはズームレベルとx、y座標で識別されます。このタイリングスキームにより、マップは世界の必要な部分のみを読み込むことができ、スムーズなスクロールとインタラクションが可能になります。特定の緯度と経度を、それが属する正確なタイルに変換する数式が存在します。 `asinh(tan(lat))` 関数は、タイルグリッドシステムで正規化されたメルカトルy座標を表します。この計算の小数部分を切り捨てることで特定のタイルが特定され、小数部分はタイル内の正確な位置を示します。ユーザーがマップをドラッグすると、アプリケーションは画面に表示されているタイルを計算し、それらをフェッチするだけです。 ユーザーの位置を示す青い点は、このプロセスの直接的な結果です。デバイスのGPSは緯度と経度を提供し、それらは同じメルカトル数学を使用して投影されます。システムは対応するタイルを決定し、画面上の投影された位置にマーカーを配置します。これらの根本的な原則を理解することで、不透明なマップインターフェイスが理解可能なシステムに変わります。

How a map works, Mercator, tiles, and your GPS pin dev.to

RSS Hunter • 今日

MCP Inspector 対 Postman 2026年：実際にどちらを使うか

著者は、MCPツール定義で一般的な問題に遭遇しました。スキーマとハンドラーの間でフィールド名にタイプミスがあったため、エージェントがツールを無視しました。これを解決するために、MCP定義を検証するための3つのツールをテストしました。MCP Inspector、Postman、そしてMCP Tool Testerと呼ばれるカスタムビルドのバリデーターです。公式デバッガーであるMCP Inspectorは、実行中のサーバーを必要とし、ランタイム中に問題を特定しますが、これは遅すぎる可能性があります。Postmanも実行中のサーバーを必要とし、HTTPベースのMCPをサポートし、コラボレーション機能を提供しますが、検証は浅いです。著者のMCP Tool Testerは、サーバーなしで定義を即座にチェックするクライアントサイドのバリデーターであり、フィールド名の不一致、長い説明、重複するenum値などの問題をフラグ付けします。彼らは、デプロイ前のチェックにバリデーターを使用し、ランタイムテストにInspectorを使用します。Postmanは、迅速な定義チェックには重すぎると考えられていますが、HTTPサーバーを使用するチームには価値があります。バリデーターは、迅速な静的定義検証に優れており、Inspectorはライブツールの動作をテストするために不可欠です。バリデーターとInspectorの両方が、MCP開発ワークフローにおいて、異なるが補完的な役割を果たします。

MCP Inspector vs Postman in 2026: which one I actually use dev.to

RSS Hunter • 今日

Laravelにおけるテスト駆動開発：レッド・グリーン・リファクタリングのループ

従来の「コードファースト」アプローチは、保守が困難なレガシーコードと本番環境での緊急事態につながります。テスト駆動開発（TDD）は、コードを書く前にテストを書くことでこれを逆転させます。TDDは、レッド、グリーン、リファクタリングのサイクルに従います。レッドフェーズでは、存在しない機能に対してテストが書かれ、失敗することが期待されます。グリーンフェーズでは、失敗したテストをパスさせるために最小限のコードが書かれます。リファクタリングフェーズでは、パスしたテストをセーフティネットとして使用して、コードのクリーンアップと改善が行われます。TDDの主な利点は、バグの検出を超えて、ソフトウェア設計の改善にまで及びます。最初にテストを書くことで、開発者はコードの消費者の視点を採用し、設計上の複雑さを明らかにします。この記事では、サブスクリプションシステムを例にTDDを説明し、機能テストが実装と後続のリファクタリングをどのようにガイドするかを示します。一般的な落とし穴には、依存関係の過剰なモック化、動作ではなく実装の詳細をテストすること、過度に大きなテストを書くことなどがあります。TDDの「スピードアップするためにスローダウンする」という哲学は、手動デバッグを排除し、デプロイメントへの信頼を育むことで時間を節約します。最新の保守可能なソフトウェア、特にLaravelのような進化するフレームワークにおいては、TDDは重要な規律として提示されています。小さなコード片にTDDを採用することで、自信を築き、時間の経過とともにコード品質を向上させることができます。

Test-Driven Development in Laravel: The Red-Green-Refactor Loop dev.to

RSS Hunter • 今日

Rustのarti-clientを使ったP2Pチャットの構築

この投稿では、Anyhideにおけるピア検出とセッション設定の複雑さについて、Tor隠しサービスに焦点を当てて詳述します。通常のサーバーとは異なり、隠しサービスがユーザー間の相互匿名性にとってなぜ重要なのかを説明します。Tor隠しサービスIDを人間が読める.onionアドレスに変換するプロセスを、コードと具体的な実装の詳細とともに説明します。`arti` Torクライアントライブラリのブートストラップを示し、独立したデーモンと比較してその組み込み性を強調します。隠しサービスをホストするには、設定と着信接続のリクエストストリームの取得が必要です。隠しサービスへの接続も同様に簡単です。この記事では、双方向接続レーシングアプローチについて論じています。これは、両方のピアが同時に接続を開始しようとするもので、複雑さは増しますが、平等性と使いやすさを促進します。接続が確立されたら、セキュアなセッションキーを設定するための3メッセージハンドシェイクメカニズムの概要を示します。`arti`ライブラリが提供するもの（回路管理や隠しサービス統合など）と、現在欠けているもの（セキュリティクリティカルなアプリケーションでは実験的なステータスであることなど）を明確にします。著者は、キャンセル安全性問題を回避するために、暗号プリミティブを同期させておくことを強調します。次の投稿では、連絡先管理や接続リクエスト処理を含むユーザーインターフェースについて説明します。

Building a P2P Chat over Tor with Rust's arti-client dev.to

RSS Hunter • 今日

VuReactはVue 3のdefineModelをReactにどのようにコンパイルしますか？

VuReactは、VueからReactへの移行や、Vue 3の構文でReactを記述するためのツールチェーンです。この記事では、Vue 3のdefineModelマクロがReactにどのようにコンパイルされるかを詳しく説明します。コンパイルは、VueのdefineModelをReactのuseVRefとuseUpdatedフックにマッピングし、自動同期を実現します。VueのdefineModelは、ref、modelValueプロップ、およびupdateイベントを生成することで、v-model宣言を簡素化します。VuReactはこれをuseVRefに変換してプロップ値をリアクティブにし、useUpdatedを使用して値の変更時に親のコールバックをトリガーします。コンパイルはdefineModelをプロップ型宣言、イベントコールバック宣言、およびランタイムリアクティビティに分解します。これにより、コンポーネント内のrefの値の変更が自動的に親を更新し、Vueの開発体験を模倣します。VuReactは、defineModelのtype、default、requiredオプション、およびカスタムプロップ名をサポートします。これらのオプションは、TypeScriptの型制約とデフォルト値のロジックに変換することで処理されます。useVRefフックは、初期プロップ値をリアクティブなrefでラップし、useUpdatedは変更を監視します。コンパイルされたReactコードでrefの.valueに直接代入すると、親の更新がトリガーされます。refの値とやり取りする関数は、正しい依存関係追跡とともにuseCallbackでラップされます。この.valueアクセスパターンの維持は、開発者にとってシームレスな移行を提供します。

How does VuReact compile Vue 3's defineModel to React? dev.to

RSS Hunter • 今日

[チュートリアル] UpsunにDjangoをデプロイする：最終チェックリスト 🚀

Djangoプロジェクトを本番環境にデプロイすることは、多くの設定手順を伴う複雑なプロセスになり得ます。Upsunは、構造化されたデプロイメントアプローチを提供することで、これを簡素化します。環境変数、ALLOWED_HOSTS、静的アセット配信、依存関係のインストールを自動的に管理します。Upsunのプラットフォーム固有の設定とビルド構成はプロセスを合理化し、開発者は最終的なデプロイメントステップの完了に集中できるようになります。

[Tutorial] Deploying Django on Upsun: the final checklist 🚀 dev.to

RSS Hunter • 今日

AIファーストのスタートアップスタジオの構築

チームは、Klarローンチ以来2ヶ月間の集中的な再構築を経て、オペレーションを大幅に更新しました。戦略的およびインフラストラクチャの追加により、8人のエージェントチームに拡大しました。SMB向けの新しい給与計算および人事ソリューションであるNomiが、スタートアップカタログに追加されました。プロジェクト数は4倍になり、これらのプロジェクト全体でのタスク完了率は高くなっています。技術的には、インフラストラクチャはほぼ完全にコードとして管理されるようになり、コンテナ化されたプロジェクトでKubernetesに対応できるようになりました。継続的な統合とデプロイメントを可能にする堅牢なデプロイメントコントロールプレーンを実装しました。インフラストラクチャは高可用性と自己修復機能を重視しており、かなりの部分がセルフホストされています。製品面では、数千件のプルリクエストをクローズし、内部改善と新機能の両方に注力しました。オプションで人間のレビューを含むコンテンツパイプラインが、さまざまなプラットフォーム向けの週刊記事を生成するために整備されています。再構築フェーズの完了が近づいており、まもなく主要なプロデューサーの活動再開を予定しており、ローンチにつながる可能性があります。驚くべきことに、これまでのすべての出力は、AIおよび仮想マシンのコストを慎重に管理した結果、1,000ユーロ未満に抑えられています。

Building an AI first Startup Studio dev.to

RSS Hunter • 今日

AI-Team-Team - ジェネリックな動的マルチエージェントコラボレーションフレームワーク

AI-Team-Team (ATT) は、AIエージェントが複雑な階層的または動的なチームを自由に形成することを可能にします。このプロジェクトは、深さ制限付きで子エージェントチームの再帰的なスポーンを可能にします。チームは、メンバーを自律的に構成し、役割を定義し、階層内で移行することができます。リアルタイムのASCIIマップがアクティブなチームトポロジーを可視化し、グローバルエキスパートディレクトリがピアディスカバリを促進します。ATTは、推論のためにバウンドされたReActループを採用し、実行のために堅牢なパーサーを使用します。対話メモリは、重要な会話履歴を保持するために圧縮されます。LLM生成ロジックは、ベンダーに依存しないコールバックハンドラーに委任されます。民主的な投票システムがメンバー変更を管理し、匿名参加を可能にします。ネゴシエーションブローカーがチーム間通信を管理し、共同ドキュメントライブラリが制御されたストレージを提供します。コンテキスト保護ゲートは、大きなファイルの読み取りを制限し、アウトライン警告とチャンクリクエストにフォールバックします。ツール監査は、実行前に特定のツール呼び出しをインターセプトして検証します。SQLite状態スナップショットは、システム状態をシリアライズすることによってクラッシュリカバリを可能にします。監督チームが対話を監査し、異常をエスカレートします。分離されたダッシュボードは、UI更新のための明確なランタイムイベントフックを提供します。このプロジェクトは、実装された機能と今後のアプリケーション計画を備えた完全なPythonパッケージです。

AI-Team-Team - A generic dynamic multi-agent collaboration framework dev.to

RSS Hunter • 今日

ChatGPTはAIアプリユーザーの半分を下回った — 主要3つに仕事をどのように分散させたか

ChatGPTのAIアプリユーザーにおけるシェアは50%を下回り、Sensor Towerによると現在約46%となっています。Geminiは約28%、Claudeは約10%のアプリユーザーを占めています。しかし、ChatGPTは依然としてウェブトラフィックで11億人以上の月間ユーザーを抱え、総合的なナンバーワンの座を維持しています。この変化は、ユーザーにおける単一のAIアプリ習慣の終焉を示唆しています。著者は開発者であり、現在では特定のタスクに異なるAIを使用しています。Claudeは、リファクタリングや複雑なコードベースの理解といったコーディングタスクに適しています。GeminiはGoogle製品に統合されており、メール、検索、Googleタブ内でのタスクに便利です。多くのデバイスにプリインストールされているため、インストールに関する摩擦がありません。ChatGPTは、その使いやすいインターフェースにより、一般的な質問や簡単な下書き作成の定番として残っています。他のAIモデルは、特にGoogleのエコシステム内でのGeminiのように、その普及により勢いを増しています。ユーザーの信頼も役割を果たしており、特定のパートナーシップ発表後にChatGPTから乗り換える人もいます。根本的な問いは、「最高のAI」を見つけることから、「特定のタスクに最適なAI」を特定することへと進化しました。これはタスクベースのルーティングを必要とし、開発者にとって標準的なワークフローになりつつあります。競争の激化は、AIサービス全体でのより速い機能開発と価格低下を推進しています。

ChatGPT just dropped below half of AI-app users — here's how I split work across the big three dev.to

RSS Hunter • 今日

「学習から面接まで、技術的な卓越性を追求する」—合格ではなく、道のりを名付ける願望の見出し

多くのEdTechおよび面接対策プラットフォームは、候補者が何を得られるかではなく、製品が何を代表しているかを説明するヘッドラインを使用しています。「学習から面接まで、技術的な卓越性を」のようなヘッドラインは、響きも良く、正確です。しかし、面接対策を探している開発者が抱える具体的な質問に答えることができていません。開発者は、システム設計のギャップやスタック固有の対策といった問題に対する具体的な解決策を求めています。現在のヘッドラインは、望ましい能力の状態を説明していますが、具体的な成果や競合他社との明確な差別化要因を示していません。それらは網羅的な範囲を提供しますが、候補者が何を達成できるかについての具体性に欠けています。 より効果的なヘッドラインは、願望から直接的で測定可能な成果へと焦点を移します。例えば、「トップティア企業での次の技術面接に合格する — あなたのスタックで聞かれる具体的な質問を練習し、当日何も驚かされないように。」この改訂されたヘッドラインは、望ましい結果、それを達成するためのパーソナライズされたメカニズム、そして準備ができているという最終状態を明確に述べています。このアプローチは、候補者の根本的な恐れと願望に直接答えます。願望主導のヘッドラインのパターンは一般的ですが、それは創業者たちが製品の価値に焦点を当てるためです。しかし、候補者は主に抽象的な理想だけでなく、結果を求めています。したがって、ヘッドラインはまず具体的なメリットを明確に伝えるべきです。

"Technical excellence, from learning to interview" — The Aspiration Headline That Names the Journey, Not the Pass dev.to

RSS Hunter • 今日

あなたのエージェントのデモはうまくいきます。それが罠だ。

企業向けのAIエージェント構築において、成功したデモと信頼性の高い本番環境でのパフォーマンスとの間には、共通の課題が存在します。この乖離は、モデルの限界ではなく、主に確率の累積に起因します。ステップごとの信頼性が高くても、複数のステップを連鎖させると、エンドツーエンドの成功率は著しく低下します。デモは通常、単一の理想的なシナリオを示すだけで、本番環境の実際の複雑さを覆い隠します。 エージェントのステップ内での失敗は、誤った出力であっても、もっともらしく見えるため、しばしば見過ごされます。個々のステップは、単独では健全に見えても、チェーン全体にわたってエラーを静かに伝播させます。一般的な診断である「幻覚」は、モデルが受け取ったデータを単に処理するだけなので、しばしば不正確です。エージェントのパフォーマンスの重要な制限要因は、コンテキストの質であり、その量ではありません。古い情報は埋もれてしまいます。 信頼性を向上させるには、プロンプトの最適化だけでなく、堅牢なシステムエンジニアリングに焦点を当てる必要があります。状態チェックポイントの実装により、中断されたプロセスを再開でき、コストのかかる再起動を回避できます。各ステップでの入力と出力の検証は、エラーを早期に検出し、下流の操作を破損させるのを防ぎます。副作用を冪等にすることは、非決定的なワーカーでの再試行を処理するために不可欠です。 継続的インテグレーションパイプラインへの評価の統合は、エージェントの動作を、回帰を起こしやすいコードのように扱います。最終的に、洗練されたデモを本番環境に対応したシステムに変えるには、エラー処理や状態管理のような、地味なエンジニアリング規律が必要です。根本的な問題は、エージェントを単純なプロンプトとして扱うのではなく、複雑なシステムとして扱うことです。

Your agent demo works. That's the trap. dev.to

RSS Hunter • 今日

LLMゲートウェイ対MCPゲートウェイ：新しいAIインフラストラクチャスタックの理解

現代のAIシステムは複雑化しており、複数のLLMプロバイダーやツール連携を管理するための新しいインフラストラクチャが必要となっています。多数のサービスに直接アプリケーションを接続することは、規模が大きくなると管理不能になります。LLMゲートウェイは、すべてのモデルインタラクションのための単一のエントリポイントを提供し、認証、レート制限、コスト監視を処理することでこれを簡素化します。LLMルーターは、特定のタスクに最も適切なLLMをインテリジェントに選択し、コストとパフォーマンスを最適化するため、重要です。Model Context Protocol（MCP）は、AIエージェントが外部ツールやシステムと対話するための標準として登場しています。MCPゲートウェイは、これらのMCPサーバーへのアクセスを管理し、ポリシーを強制し、ガバナンスを強化するための集中化されたレイヤーを提供します。MCPプロキシは主に接続性と認証を処理しますが、MCPゲートウェイは包括的な管理機能を追加します。MCPレジストリ、エージェントレジストリ、スキルレジストリなどのレジストリは、利用可能なAIリソースを発見し、カタログ化するために不可欠です。MCPレジストリはMCPサーバーをリストし、エージェントレジストリはAIエージェントを追跡し、スキルレジストリは再利用可能なエージェント機能を詳細に説明します。これらのレジストリは重複を防ぎ、AIシステム全体のガバナンスを向上させます。最終的に、モデル、エージェント、ツールの効果的な統合と管理は、将来のエンタープライズAIの成功にとって最も重要であり、これらのインフラストラクチャレイヤーは不可欠となります。

LLM Gateway vs MCP Gateway: Understanding the New AI Infrastructure Stack dev.to

RSS Hunter • 今日

コンテキスト圧縮ビジュアライザー：AIエージェントが忘れたことを正確に把握し、コストがかかる前に

多くのターンにわたって動作するAIエージェントは、コンテキストの制限に直面し、以前のメッセージを圧縮または破棄することを余儀なくされます。このコンテキストの喪失は、しばしば目に見えませんが、エージェントが重要な制約、ユーザーの好み、または以前の決定を忘れる原因となる可能性があり、極めて重要です。Context Compaction Visualizerプラットフォームは、コンテキスト管理プロセスを透明にすることで、この問題に対処します。ユーザーは、LangSmith、OpenTelemetry、またはAgentOpsなどのさまざまなプラットフォームからの実行トレースをアップロードできます。プラットフォームは、どのメッセージが保持され、要約され、または破棄されたかを詳細に説明しながら、完全なセッション履歴を再構築します。D3.jsタイムラインは、色分けされた結果とともに、すべてのターンにわたるトークン消費を視覚的に表現します。セッション再生機能により、ステップバイステップのレビューが可能になり、圧縮イベントとその影響が強調表示されます。トークン分析は、総コストと圧縮効率に関する洞察を提供します。オプションのClaude搭載情報損失検出器は、各圧縮イベントのリスクをスコアリングし、失われた可能性のある情報を特定します。プラットフォームは、異なるエージェントまたは圧縮戦略を並べて評価するための比較ビューをサポートします。セットアップには、PythonとNode.jsのインストール、オプションのAnthropic APIキーの設定、バックエンドおよびフロントエンドサービスの実行、またはDockerの使用が含まれます。バックエンドには、複数のトレース形式のパーサーが含まれており、それらを正規化してからさらに処理します。主要な設計上の決定には、パーサーの正規化、情報損失検出器のグレースフルフォールバック、およびReact内での効率的なD3.js統合が含まれます。このプロジェクトは、コンテキスト圧縮という目に見えないプロセスを可視化することにより、どのコンテキストが失われ、その価値が何であったかの記録を提供することを目的としています。

Context Compaction Visualizer: See Exactly What Your AI Agent Forgot Before It Costs You dev.to

RSS Hunter • 今日

AIエージェントのために、実際に忘れることができるメモリシステムを構築しました

既存のAIエージェントのメモリシステムは、永続的な蓄積に苦しみ、古い事実が検索を汚染するため、時間の経過とともにパフォーマンスと精度が低下します。この問題は、より多くのトークンが直接的に悪い結果と遅く、愚かなエージェントと相関するため発生します。これを解決するために、recall-sqliteは積極的に忘れるメモリシステムとして開発されました。その中心的な原則は階層ストレージであり、メモリはアクセス頻度に基づいて自動的に階層間で移動されます。ホットティアは頻繁にアクセスされるメモリを保持し、高速な検索のためにANNとキーワードを利用します。ウォームティアはあまりアクセスされないメモリを格納し、キーワードとFTS5のみに依存して計算量を大幅に削減します。コールドティアは、必要に応じて自動的に昇格される、ゼロコンピューティングで無制限のメモリを格納できます。主な設計上の選択には、クエリ時にLLMを使用せず、小さなローカル埋め込みモデルのみに依存することが含まれます。従来のベクトルデータベースを避け、sqlite-vecを使用してSQLiteを使用します。このシステムは、オフライン時にキーワードとFTS5検索にフォールバックする、穏やかな劣化をサポートします。自動スキーマ移行は更新を簡素化し、APIキーやDockerなしで単一のpipインストールを提供します。約1500のメモリで6か月間の毎日の使用後、レイテンシは約80msのままで、メモリフットプリントは固定で約1.5MBです。recall-sqliteは現在、Hermes Agentエコシステムに統合されています。

I Built a Memory System for AI Agents That Actually Forgets dev.to

RSS Hunter • 今日

AIを秘密漏洩せずに使用する：AI支援開発のための脅威モデル

AIプロンプトへのシークレットの貼り付けは、ログやトレーニングデータでの永続的な露出の可能性を伴う公開共有に似ています。著者は、AIの使用において、単なるカジュアルなものではなく、脅威モデルアプローチを強調しています。プロンプトは、送信時にプライベートな会話のままではありません。無料のAIティアは、モデル改善のためにデータを保持することが多いですが、有料ティアは契約上の保証を提供しますが、絶対的なセキュリティではありません。データ漏洩は、貼り付けられたもの、ツールが自動的に添付するもの、またはモデルが出力するものから発生する可能性があります。AIプロバイダーは、信頼できるが検証不可能なサードパーティと見なされており、内部プロセスの監査は不可能です。リスクのある資産には、APIキー、データベース認証情報、および機密性の高い顧客情報が含まれます。プロンプトチャネルは、本番ネットワーク呼び出しと同様に、信頼できないエグレスとして扱われるべきです。送信禁止リストには、ライブ認証情報、機密性の高い設定ファイル、および独自のソースコードが含まれています。プレースホルダーでシークレットをマスキングすることは、送信を控えることの実行可能な代替手段です。コンテキストの衛生状態は、無視ファイルや事前プロンプトスキャンによる漏洩の構造的な防止を含みます。シークレットをソースで暗号化しておくという原則は、平文での露出を防ぎます。データの機密性をAIティアに合わせ、独自の作業には有料ティア、規制されたデータにはローカルモデルを使用することが推奨されます。トレーニングなしの保証があっても、ゼロトラストの姿勢が推奨され、コンテキストを最小限に抑え、AIの出力を検証します。AI無視ファイルの作成、シークレットのスキャン、および認証情報のマスキングのような習慣は、大幅な時間のコストなしにセキュリティを向上させます。

Using AI Without Leaking Your Secrets: A Threat Model for AI-Assisted Development dev.to

RSS Hunter • 今日

MERNスタック学習69日目

開発者は、69日連続でフルスタックエンジニアリング作業を続けています。昨日、インタラクティブなホストインベントリダッシュボードとデータ削除フックを正常にデプロイしました。今日は、作成フォームを更新のために再利用するシステムを実装することで、管理ライフサイクルの洗練に焦点を当てました。これは、Express Query ParametersとDynamic View Hydrationを利用して達成されました。 コアコンセプトは、作成と更新のエントリに対する冗長なコードを防ぐことです。開発者は、条件付き状態抽出を抽象化することによってこれを達成しました。69日目には、この機能のためのクエリ取り込みと更新ドライバーを構築しました。 プロセスは、クエリ文字列の取り込みから始まります。ここでアプリケーションは、URLから「?editing=true」のようなパラメータをキャプチャします。厳密な条件チェックが、アプリケーションの処理ロジックを決定します。更新フィルターがtrueの場合、コントローラーはURLパスから特定のデータベースポインタ文字列を抽出します。この識別子は、特定のエントリの既存データを取得するために使用されます。 この取得されたデータは、フォーム内の入力フィールドをハイドレートするために使用されます。再利用可能なEJSロジックは、この更新状態に基づいてユーザーインターフェースを動的に変換します。例えば、ヘッダータイトルは「Edit HOME」に変わり、プライマリコールトゥアクションボタンは「Edit Home details」に更新されます。ファイル入力フィールドも、更新された画像文字列を処理したり、既存のメディアパスを保持したりするように準備されます。提供されたアーキテクチャスニペットは、バックエンドがクエリフラグをインターセプトして、フォームのリサイクルを動的に駆動するためにビューエンジンをどのように駆動するかを示しています。

Day 69 of Learning MERN Stack dev.to

RSS Hunter • 今日

初日ローンチの数字と、なぜ今日アップボート数を無視するのか

昨日、XEdgeがPeerlistのLaunchpadでローンチされました。 13件のアップボート。1件のコメントスレッド。3件の直接的なフィードバック。 それぞれの数字が実際に何を意味するのか、正直な見解を述べます。 アップボートは人気シグナルであり、品質シグナルではありません。 アップボートは、人々があなたのローンチを見て、1つのボタンをクリックしたことを示します。これは可視性には価値がありますが、製品の方向性には何も意味しません。 コメントは深さのシグナルです。 1つの実際のコメントスレッドは、13件のサイレントなアップボートを合わせたものよりも、見知らぬ人がXEdgeをどのように認識しているかについて、私に多くのことを教えてくれました。 フィードバックは唯一積み重なるシグナルです。 3人が、何が分かりにくいのか、あるいは何が欠けているのかを私に伝えるために時間を割いてくれました。これは、提供する義務が全くない人々からの3回の無料製品監査です。 今日、私はリーダーボードを再び確認しません。私はフィードバックの各項目を一行ずつ見直し、今週どのような変更を加えるかを決定します。 教訓：ローンチは投票数ではなく、フィードバックの質を最適化すること。投票は1週間で消えます。フィードバックは、数ヶ月間重要なことを修正することができます。 xedge.tech — まだ構築中、まだ傾聴中。

Day 1 launch numbers and why I'm ignoring the upvote count today dev.to

RSS Hunter • 今日

CodexのSQLiteログを無効にした場合、プロジェクトのメモリを維持するものは何か？

Codexは、ローカルSQLiteデータベースへの過剰な診断ログ記録が批判されており、SSDの高速書き込みや応答速度の低下といったパフォーマンスの問題を引き起こしています。非公式な回避策として、SQLiteトリガーを使用して新しいログエントリを無視することで、ディスクアクティビティを削減しますが、診断情報が不明瞭になる可能性があります。この回避策は、エージェントの内部ログと、継続性のために必要な永続的な「プロジェクトメモリ」との間の重要な区別を浮き彫りにしています。エージェントログには低レベルの運用詳細が含まれますが、プロジェクトメモリには重要な決定、検証された証拠、および次のステップの簡潔な記録が必要です。 この不可欠なプロジェクトの継続性は、エージェントの自己診断用に設計されており、スキーマと形式の変更の影響を受ける内部診断データベースでは維持されません。この記事では、CodexのようなAIコーディングエージェントの継続性コンテキストをキャプチャするために設計されたローカルファーストのレコードレイヤーであるQiJuを紹介します。QiJuは、意図的に、グラウンドトゥルースファイル、決定、証拠、および次のアクションといった本質的な事実のみを記録します。これにより、後続のエージェントは、履歴セッション全体を必要とせずに、正しく作業を再開できます。このアプローチは、エージェントの内部リコールに閉じ込められた情報とは異なり、監査可能で引き継ぎ可能です。 QiJuは、エージェントログが無効になっているか利用できない場合に、プロジェクトの継続性を維持するための実用的なソリューションを提供します。アップグレードコマンド `qiju update` は、エージェント統合スキルがプロジェクト全体で最新の状態に保たれることを保証します。プロジェクト登録プロセスは、プロジェクトの場所とホスト構成を分離し、効率的な更新を可能にします。QiJuは制限付きのデベロッパープレビュー段階にありますが、その中核的な目的は、AI支援開発を継続するために重要なことの、意図的で検査可能な記録を確立することです。これは、内部診断ログとの重要な区別です。

If You Disable Codex’s SQLite Logs, What Keeps Your Project Memory Alive? dev.to

RSS Hunter • 今日

ヘルスケアサイバーセキュリティはクリニカルセーフティの一部になりつつある

ヘルスケアのサイバーセキュリティは、統合された病院の調達パッケージによって実証されているように、現在、臨床安全と本質的に結びついています。病院は、医療機器から訪問者用Wi-Fiに至るまで、多様なシステムが独自の脆弱性を提示する異種混在ネットワークを管理しています。これらの多様なシステムは、臨床機能とリスクレベルに合わせたネットワークセグメンテーションを必要とし、セキュリティの低い医療機器を隔離します。ケアサービスの可用性を保護することは、データの機密性と同じくらい重要であり、セキュリティ対策は重要な臨床ワークフローに対してテストされる必要があります。包括的なバックアップおよびリカバリ計画は、臨床的に関連性のある時間枠内でのデータ復元を保証する必要があります。ベンダーのメンテナンスは頻繁なリスクをもたらし、リモートアクセス、データ記録、およびデフォルトの資格情報の削除に対する厳格な管理が必要です。調達プロセスは、ベンダーからの堅牢なセキュリティプラクティスの証拠を要求することによって、これらのセキュリティ期待を強化することができます。受け入れテストには、アカウントの侵害やコンポーネントの障害などのセキュリティインシデントのシミュレーションを含める必要があります。最終的な目標は、絶対的な制限ではなく、管理されたリスクを通じて信頼性の高い患者ケアを達成することです。サイバーセキュリティ設計を臨床的な依存関係と整合させることにより、病院は不可欠なサービスを妨げることなくセキュリティを強化できます。

Healthcare Cybersecurity Is Becoming Part of Clinical Safety dev.to

RSS Hunter • 今日

LLM推論をルーティングするためにRust製のエンロピーモニターを構築しました。ベンチマークの結果は以下の通りです。

フロントエンドLLM推論はコストがかかるため、階層化された推論アーキテクチャであるBuddy Systemの開発が促されています。このシステムは、高価なクラウド呼び出しに頼る前に、ローカルモデルの使用を最大化することを目的としています。Rust EntropyMonitorは、MLXを介してApple Silicon上で実行される4Bモデルによるローカル生成中に、トークンごとの不確実性を追跡します。ローカルモデルが高いエントロピーを示し、真の不確実性を示す場合、特に節の境界で、spaCy NERは関連する固有表現または名詞句を特定します。次に、sentence-transformersリトリーバーが、コンテキストに関連するパッセージチャンクを見つけます。クラウドモデルであるSonnetは、不確実な事実とグラウンディングドキュメントで構成されるターゲットクエリを受け取ります。重要なのは、クラウド呼び出しは非同期であり、ローカル生成がブロックされないことを保証することです。古典的なツールは、数学や単位などの決定論的なタスクをゼロコストで処理します。ベンチマークによると、Buddy Systemは、ローカルのみ（精度70.7％、コスト0.00ドル）と比較して、最小限のコストで71.4％の精度を達成しています。しかし、アドバイザーパターンは、SQuAD v2やHotpotQAなどの特定のデータセットで驚くほどパフォーマンスが低下しました。これは、アドバイザーがソースドキュメントなしで回答を受け取り、グラウンディングではなくパラメトリックメモリに依存していることに起因します。Buddy Systemの成功は、レビュー層にドキュメントコンテキストを渡すことにあり、正確なLLMパフォーマンスにおけるコンテキストの重要性を示しています。

I built a Rust entropy monitor to route LLM inference — here's what the benchmark showed dev.to

RSS Hunter • 今日

チャットボットを超えて：エンタープライズワークフローのためのGoogleマネージドエージェントアーキテクチャのクリティカル分析

エンタープライズAIのランドスケープは、シンプルなRetrieval-Augmented Generation（RAG）チャットボットから、より洗練されたエージェント的なワークフローへと移行しています。RAGシステムは、内部ドキュメントからの質問に答えるのには適していますが、複数ステップのタスクを実行したり、データを書き込んだりする能力には欠けています。GoogleのManaged Agents APIは、AIエージェント向けのセキュアなクラウドサンドボックスを提供することで、ソリューションを提供します。このアーキテクチャは、エンタープライズワークフローに不可欠な状態保持とトランザクション書き込み操作を可能にします。 Managed Agents APIは、各エージェントセッションのために分離されたLinuxコンテナ内で動作し、コンテナ化とセキュリティの懸念を抽象化します。状態は、永続的なセッション識別子を介して複数のステップにわたって維持され、長時間実行されるタスクを可能にします。エージェントの動作は、複雑なコードではなく構造化されたファイルによって定義され、設定を簡素化します。セキュリティは、サーバーサイドの認証情報注入によって強化され、機密情報が公開されるのを防ぎます。 しかし、エンタープライズレディネスを達成するには、マネージドサンドボックス以上のものが必要です。インターフェース、オーケストレーション、モデル、ツール、ナレッジ、サンドボックス、監査の7つのレイヤーからなるリファレンスアーキテクチャが必要です。最も重いエンジニアリングの負担は、これらのレイヤー、特にコントロールプレーン、ツール制限ポリシー、トランザクションロールバックメカニズムの統合にあります。GeekyAnts、Slalom、Cognizantなどのいくつかの企業は、これらの複雑なエンタープライズエージェントAI統合の構築を専門としています。 エンタープライズリーダーにとっての重要なポイントは、モデルの進歩だけに焦点を当てるのではなく、インフラストラクチャとエンジニアリングに焦点を当てることです。明確に定義されたビジネスワークフローを分離し、オブザーバビリティを備えた堅牢なコントロールプレーンを構築することで、チームは支援的なチャットから自律的で管理されたワークフローへと移行できます。これらの統合とアーキテクチャの課題を解決するためのツールは、現在利用可能です。

Beyond Chatbots: A Critical Analysis of Google Managed Agents Architecture for Enterprise Workflows dev.to

RSS Hunter • 今日

自分のAPIがダウンしたことに気づかず、API監視プラットフォームを構築した

学生がデプロイしたAPIが数時間サイレントにダウンしたことをきっかけに、Monitorlyが作成されました。既存のアップタイム監視ツールは、学生プロジェクトには複雑すぎると感じられました。Monitorlyは、シンプルさを追求して設計された、新しいオープンソースのAPIアップタイム監視プラットフォームです。ページリフレッシュなしで即座に更新されるリアルタイムダッシュボードを備えています。アラートは、エンドポイントのステータスが変更された場合にのみメールで送信され、受信トレイのスパムを防ぎます。プラットフォームは、過去のチェックデータに基づいてローリングアップタイムパーセンテージを計算します。ユーザーは、1分から15分の範囲でチェックの間隔を設定できます。Monitorlyは、JWT認証を使用して、ユーザーごとに監視データを分離します。主要なテクノロジーには、Node.js、Express.js、MongoDB、Socket.ioが含まれます。アーキテクチャは、チェックのスケジューリングにcronジョブを、HTTPリクエストにAxiosを使用しています。重要な学習点は、純粋な技術的な正しさよりも、ユーザーエクスペリエンスを向上させるためのアラートロジックの設計でした。このプロジェクトはまた、ログデータをメインドキュメントから分離すること、およびリクエストタイムアウトを実装することの重要性も強調しています。今後の計画には、SMSアラート、レスポンスボディ検証、および公開ステータスページの追加が含まれます。

I Built an API Monitoring Platform Because My Own API Went Down and I Had No Idea dev.to

RSS Hunter • 今日

ビルドログ：Astro、Cloudflare Pages、Umamiでブログを再構築する

著者は、特定の原則に焦点を当てて、Astro を使用して個人のウェブサイトを再構築しました。これらには、SEO の維持、すべての資産の所有、JavaScript の最小化、プライバシーとベンダーロックインからの自由の確保が含まれます。投稿は Git リポジトリ内の Markdown ファイルとして管理され、SEO の継続性のために古い URL に一致するようにスラッグが保持されます。移行プロセスには、投稿をインポートし、不要なコンテンツを削除し、画像をローカルにダウンロードして最適化するためのスクリプトが含まれていました。 SEO は重要な懸念事項であり、正規 URL と古いブログパスからメインドメインへの 301 リダイレクトを実装することで対処されました。これにより、ランキングシグナルが単一のホストに統合されました。キャッシュされたコンテンツを提供する残存する Gatsby サービスワーカーが原因で、永続的なバグが発生しました。解決策は、古いサービスワーカーの登録を解除し、ライブサイトへのリフレッシュを強制する新しい「キルスイッチ」サービスワーカーでした。 検索機能は、バックエンドサーバーの必要性を回避するために、静的 JSON インデックスを使用してクライアントサイドで実装されました。Astro のスコープ付きスタイルに関する軽微な問題は、動的に生成された要素の CSS の配置を調整することで解決されました。Mermaid 図は、正しく読み込まれるように、非同期インポート後に明示的にクライアントサイドでレンダリングされます。図の可読性を向上させるために、クリックしてズームする機能が追加されました。 タグの衛生状態は、単一使用タグと重複タグを正規タグに統合することで対処され、2 つ未満の投稿を持つページは noindex 対象としてマークされました。Cookie を使用しない分析は Umami を使用して実装され、広告ブロッカーをバイパスするために Cloudflare Pages Functions を介したファーストパーティプロキシが使用されました。リンククリックのイベントトラッキングが Umami に追加されました。 Astro の View Transitions では、`transition:persist` がスクリプト添付リスナーを保持しないため、ナビゲーションごとにスクリプトを再初期化する必要があります。最後に、Cloudflare の Rocket Loader が Safari でのサイトの破損の原因であることが特定され、無効化されました。

The Build Log: Rebuilding My Blog on Astro, Cloudflare Pages & Umami dev.to

RSS Hunter • 今日

開発者向けPenpot：あなたの言語を話すオープンソースデザインツール

従来のデザインツールは開発者を後回しにし、ピクセル単位で完璧にデザインを手動でコードに翻訳し、それがすぐに時代遅れになります。オープンソースプラットフォームのPenpotは、SVG、CSS、HTMLなどのウェブ標準としてデザインを直接表現することでこの問題に対応しています。これにより、独自ロックインや専門的な「デザイナー方言」の解釈が不要になります。開発者はPenpot内でSVG、CSS、HTMLの検査可能ですぐに使えるコードにアクセスできます。プラットフォームはレイアウトにネイティブのCSSグリッドとFlexboxをサポートし、ブラウザ内のインターフェースの動作をミラーリングすることで、設計と実装の摩擦を軽減します。重要な機能の一つが統合MCPサーバーで、AIクライアントがプログラム的に設計を読み改変できるようにします。このAI統合は、Penpot設計の構造化され機械的に読みやすいコードを活用し、意味HTMLの生成やプロトタイプ作成などのタスクに活用しています。Penpotはまた、設計と開発の唯一の真実の源として機能し、同期を効率化する一流のネイティブデザイントークンも提供しています。オープンAPI、プラグイン、ウェブフックにより、自動化や既存の開発者ワークフローへの統合が可能です。さらに、Penpotはセルフホスティングも可能で、厳格なデータ所有権要件を持つチームに対してコンプライアンス上のメリットを提供します。ウェブネイティブの出力と実際のCSSレイアウトを活用することで、Penpotは設計と開発のギャップを埋めることを目指しています。Figmaは依然として完成度やプロトタイピングの深さでリードしているかもしれませんが、Penpotはデータ所有権、設計コードの整合性、AI駆動のワークフローを優先する開発者にとって魅力的な選択肢です。

Penpot for Developers: The Open-Source Design Tool That Speaks Your Language dev.to

RSS Hunter • 昨日

CVE & CVSSスコア：脆弱性管理における戦略的統合

脆弱性に対する包括的なリスクモデルは、CVEのベーススコアにとどまらず、現在の脅威ランドスケープを反映した時間的指標と、組織のインフラストラクチャの特定のコンテキストを考慮した環境的指標を組み込む必要があります。脆弱性の真のリスクは、その固有の深刻度だけでなく、重要なビジネス資産への影響によって決定されます。例えば、公開されている顧客ウェブサイト上の低評価の脆弱性は、隔離された内部サーバー上のクリティカルな脆弱性よりも大きな脅威となります。CVEデータを効果的に統合するには、アセット認識型のトリアージが必要であり、影響を受けるアセットの重要性がパッチ適用の優先順位を決定します。さらに、CI/CDパイプラインでソフトウェア構成分析ツールを利用したDevSecOps統合により、サードパーティライブラリにおける脆弱性の早期検出と修正が可能になります。内部スキャンレポートをCISAのカタログなどのライブ脅威インテリジェンスと連携させることは、積極的に悪用されている脆弱性を特定し、優先順位を付ける上で不可欠です。中程度の深刻度のCVEであっても、悪意のある攻撃者によって積極的に標的にされている場合は、緊急性を帯びることがあります。最終的に、効果的な脆弱性管理は、一般的な脆弱性データを特定のビジネス資産と動的な脅威ランドスケープに整合させる、コンテキストに依存します。このアプローチにより、組織は最も重要な資産を保護するために戦略的にリソースを割り当てることができます。

CVE & CVSS Scores: Strategic Integration in Vulnerability Management dev.to

RSS Hunter • 昨日

私は16歳で、完全にローカルなAIアシスタントを構築しました。クラウドなし、APIキーなし、GPUで動作します。

インド、プネ出身の16歳、Shriisootさんが、完全にローカルで動作するAIデスクトップアシスタント「O-AI」を開発しました。クラウドベースのアシスタントがプライバシーを侵害することに不満を感じ、アイアンマンのJARVISのように、個人的でプライベートな対話を優先するO-AIを作成しました。O-AIは、llama.cppまたはOllamaを使用して大規模言語モデルをローカルで実行するため、インターネット接続や外部APIキーは不要です。会話の事実を記憶する自己学習コアと、パーソナライズされたモデルトレーニングのためのファインチューニングパイプラインを備えています。アシスタントは、ローカルのWhisper実装を通じて英語、ヒンディー語、マラーティー語での音声制御をサポートし、ユーザーの話した言語で応答します。O-AIは、JARVIS風インターフェース、PC自動化、アニメーションデスクトップペットなど、さまざまなモードを提供します。アプリケーションの起動、ウェブ検索、メディアコントロールなどのタスクに対して30以上の自動化機能を提供します。マルチステップエージェントシステムにより、さまざまなステップタイプでサポートされる複雑な計画、実行、およびアクションの検証が可能になります。テクノロジースタックには、バックエンドにFlaskを使用したPython、フロントエンドにバニラJavaScriptを使用したElectronが含まれます。主な課題には、エージェントタスクの成果検証の実装と、エラーを防ぐための堅牢なコンテンツ検証が含まれていました。

I built a fully local AI assistant at 16 — no cloud, no API keys, runs on your GPU dev.to

RSS Hunter • 昨日

AIのセキュリティ：Codexの運用上のバグ、Claudeの出力整合性、Copilotのコンテキスト

今週のセキュリティハイライトは、AIシステムの運用上のバグとAI生成コンテンツの整合性に焦点を当てています。OpenAIのCodexにおける重大なバグは、過剰なロギングを引き起こし、ローカルSSDストレージの急速な消費につながる可能性があります。ディスク容量の不足は、運用を停止させ、アップデートを妨げ、潜在的にデータ損失を引き起こす可能性があります。Codexのバグは、AIデプロイメントにおける堅牢なロギング構成と監視の必要性を強調しています。さらに、Claude Codeの「Extended Thinking」出力の分析は、AI生成コンテンツの真正性に関する懸念を引き起こしています。出力の一部は、より一貫性があるように見せるために捏造されている可能性があり、信頼性と整合性のリスクをもたらします。セキュリティにおいて、AIへの依存は、その出力の正確性と出所に対する信頼を必要とします。偽のAI説明は、誤った情報に基づいた意思決定や脆弱性の導入につながる可能性があります。AIモデル出力におけるより大きな透明性と検証可能性は、セキュリティが重要なワークフローにとって不可欠です。最後に、GitHub Copilotは、効率を高めるためにコンテキスト処理とモデルルーティングを改善しています。これらの強化は、より正確で関連性の高い提案を生成することにより、コードセキュリティを微妙に向上させます。より良いコンテキスト認識は、エラーや安全でないパターンの導入の可能性を減らします。この継続的な洗練は、人間が導入する脆弱性を軽減することにより、より安全な開発パイプラインに貢献します。

Securing AI: Codex Operational Bugs, Claude Output Integrity, Copilot Context dev.to

RSS Hunter • 昨日

DuckDB 1.5.2、PostgreSQL内部統計、およびSQLite仮想テーブルxUpdateの詳細

DuckDB はバージョン 1.5.2 をリリースしました。これは、安定性とパフォーマンスの向上に焦点を当てたパッチアップデートです。このリリースには、重要なバグ修正が含まれており、クエリ実行を高速化するためのパフォーマンスボトルネックに対処しています。重要な新機能として、DuckLake v1.0 レイクハウス形式の公式サポートが追加され、複雑なデータアーキテクチャでの有用性が向上しました。この統合により、レイクハウスパラダイムで保存されたデータの効率的なクエリと管理が可能になります。 PostgreSQL の pg_stats に関する記事は、パフォーマンスチューニングとクエリ最適化に使用される内部統計について掘り下げています。Postgres がこれらの統計をどのように収集、保存、利用するかを理解することは、効果的なデータベース管理にとって非常に重要です。この洞察は、開発者や DBA がクエリプランを解釈し、最適化の領域を特定するのに役立ちます。 SQLite フォーラムのディスカッションでは、書き込み可能な仮想テーブルを実装するための xUpdate メソッドが強調されています。xUpdate メソッドは、INSERT、UPDATE、DELETE 操作を処理し、カスタムデータソースの DML 機能を可能にします。xUpdate をマスターすることは、堅牢な仮想テーブルを構築し、SQLite の機能を拡張する開発者にとって不可欠です。これにより、外部データソースを、完全な変更サポートを備えた標準の SQLite テーブルとして扱うことができます。

DuckDB 1.5.2, PostgreSQL Internal Stats, and SQLite Virtual Table xUpdate Deep Dive dev.to

RSS Hunter • 昨日

列名が変更されたことで、CSVエクスポートが静かに壊れた経験はありますか？csv-pipeはそれをコンパイルエラーにし、読み書きの両方向に対応し、papaparseよりも数倍速く解析します。投稿にはライブプレイグラウンドがあり、独自のデータを試すことができます。

csv-pipe：TypeScriptでCSVを読み書きするライブラリ。papaparseよりも数倍高速 Myroslav Martsin Myroslav Martsin Myroslav Martsin フォロー 6月22日 csv-pipe: TypeScriptでCSVを読み書きするライブラリ。papaparseよりも数倍高速 #javascript #typescript #webdev #node 1件のリアクション コメントを追加 読了時間：2分

Ever had a renamed column quietly break a CSV export? csv-pipe makes it a compile error, reads and writes both ways, and parses several times faster than papaparse. Live playground in the post to try your own data. dev.to

RSS Hunter • 昨日

パフォーマンスレビューが失敗するのは、マネージャーが何が起こったかを忘れるから

人間の記憶は、重要だが些細な日々の仕事の瞬間を数ヶ月にわたって思い出すのに苦労するため、マネージャーの業績評価に課題をもたらします。主要な成果や肯定的なやり取りは、評価時期までに忘れられてしまう可能性があります。その結果、マネージャーは断片的な記憶、散らばったメモ、さまざまな文書に頼って従業員の業績を再構築することがよくあります。この依存は、最近の出来事が評価に不均衡に影響を与える、いわゆる新近性バイアスを頻繁に引き起こします。多くのマネージャーは、ノート、スプレッドシート、さらにはAIツールを利用してメモを取ることで、これに対抗するための個人的なシステムを開発してきました。しかし、根本的な問題はメモを取ること自体ではなく、それらのメモを効果的にまとまりのある業績の物語に変換することです。FeedbackVaultは、観察が発生したときにそれを捉え、時系列で整理することによって、この問題に対処することを目指しています。このプラットフォームは、マネージャーに、思い出す努力を必要とするのではなく、従業員の貢献の履歴をすぐに利用できるアカウントを提供することを意図しています。FeedbackVaultの主なハードルはユーザーの採用であり、既存の方法は不完全ながらもすでに使用されています。確立された慣行からの切り替えを奨励するのに十分な価値を創造することが現在の焦点です。作成者は、現在の評価準備プロセスと課題についてマネージャーからのフィードバックを求めています。FeedbackVaultを効果的に開発するには、実際のワークフローを理解することが不可欠です。

Performance Reviews Fail Because Managers Forget What Happened dev.to

RSS Hunter • 昨日

Sentry vs OpenTelemetry: どちらか一方を選ぶ必要はありません

既存のOpenTelemetryバックエンドとSentryを統合するには、OTLPエクスポーターをSentryのエンドポイントに向けるように設定します。このプロセスでは最小限の変更で済み、既存のインストルメンテーションを書き直す必要がありません。Webアプリケーションの場合、ブラウザコンテキストをキャプチャするために、フロントエンドにSentry SDKを追加することが推奨されます。これにより、ユーザーインタラクションからバックエンドオペレーションまでのトレースを統一的に表示できます。OpenTelemetryはトレース、ログ、メトリクスをサポートしていますが、Sentryは現在、OTLP経由でトレースとログのみを取り込みます。重要なのは、トレースリンキングをOTLPエクスポートから分離することです。トレースリンキングは、フロントエンドとバックエンドのリクエスト全体で連続した分散トレースを保証します。SentryのフロントエンドSDKは、W3Cのtraceparentヘッダーを伝播することでこれを処理します。バックエンドのOTLPイベントをどこに送信するかという決定は別です。Sentryに直接送信することも、OpenTelemetry Collector経由で送信することもできます。直接OTLPエクスポートは、単一バックエンドプロジェクトにとって最も簡単です。Collectorフォワーディングは、複数のサービスに対して集中処理とルーティングを提供します。デモアーキテクチャは、Sentry SDKを備えたReactフロントエンド、OpenTelemetryを使用したFastAPIバックエンド、およびOpenTelemetry Collectorを示しています。バックエンドは、手動スパンやログを含む既存のOpenTelemetry設定を維持します。その後、CollectorはこれらのOTLPイベントをSentryに転送します。クロスオリジンリクエストに対してトレース伝播ヘッダーを許可するために、バックエンドでCORSが正しく設定されていることを確認してください。

Sentry vs OpenTelemetry: You Don’t Need to Pick One dev.to

RSS Hunter • 昨日

良いアーキテクチャには可観測性が含まれます

優れたアーキテクチャは、稼働後にチームが理解できるシステムを必要とし、オブザーバビリティ（可観測性）は設計上の議論において重要な部分となります。オブザーバビリティは、現実世界のシステム動作の理解におけるギャップを避けるために、後付けではなく初期開発中に統合されるべきです。アーキテクチャは仮定に基づいて構築されており、オブザーバビリティがなければ、これらの仮定は本番環境でテストできません。オブザーバブルなシステムは、システムの動作に関する真実を提供し、技術的なシグナルを実際のユーザーへの影響に結びつけます。オブザーバビリティは単にログを持つことを超え、文脈を提供し、より迅速なデバッグと意思決定を可能にするために、ばらばらのシグナルを接続することを含みます。オブザーバビリティの利点は、デバッグが速くなるだけでなく、チームが推測から証拠に基づいた調査へと移行し、意思決定を行う方法に根本的な変化をもたらすことです。アーキテクチャの形成中にシステムに可視性を組み込むことは、後から後付けするよりもはるかに容易です。最も有用なシグナルは、ユーザーエクスペリエンスやワークフロー完了など、技術的なメトリクスを現実世界への影響に結びつけます。オブザーバビリティは、システムが運用、サポート、改善できることを保証するために、アーキテクチャレビューにおける主要な考慮事項であるべきです。最終的に、強力なオブザーバビリティは、明確なフィードバックループを作成することにより、エンジニアリングの勢いを促進し、チームが自信を持ってシステムを運用および進化させることができるようにします。

Good Architecture Includes Observability dev.to

RSS Hunter • 昨日

プロセス.envについて誰も教えてくれない10のこと

環境変数は扱いに注意が必要であり、そのニュアンスを理解することは、一般的な開発上の落とし穴を避けるために不可欠です。Linuxでは環境変数キーは大文字と小文字を区別しますが、Windowsでは区別しないため、「自分のマシンでは動く」問題を引き起こす可能性があります。process.envから取得される値はすべて文字列であるため、予期しない動作やNaNの発生を避けるには、数値やブール値の明示的な解析が必要です。process.envオブジェクトは.envファイルとは別であり、Node.jsは特定の構成なしに.envファイルを自動的に読み込みません。環境変数はコマンドごとに設定でき、そのスコープを単一のプロセスに限定し、シェルの汚染を回避できます。実行時にprocess.envを変更することは、デバッグを著しく妨げ、不確実性を生じさせるため、強く推奨されません。Next.jsでは、NEXT_PUBLIC_変数はビルド時にインライン化されます。これは、本番サーバーでこれらの変数を変更した場合、再ビルドが必要になることを意味します。process.envはブラウザでは直接利用できません。WebpackやViteのようなビルドツールは、多くの場合、公開される変数に特定のプレフィックスを使用して、それをエミュレートします。NODE_ENV変数はNode.jsによってデフォルトで設定されず、フレームワークによって処理されるか、明示的に設定される必要があります。一部のシステムでは環境変数の値にサイズ制限がある場合があり、大きなデータが切り捨てられる可能性があることに注意してください。最後に、環境変数は子プロセスに継承されるため、それらを必要としないプロセスにシークレットが公開される可能性があります。

10 Things Nobody Tells You About process.env dev.to

RSS Hunter • 昨日

最初のメッセージは「メリークリスマス」と言っていました

史上初のテキストメッセージは、1992年12月3日に送信されたシンプルな「Merry Christmas」でした。22歳のエンジニアであるニール・パップワースが、テストとしてコンピューターからボーダフォンのディレクターの携帯電話にこの歴史的なSMSを送信しました。当時、携帯電話は返信できなかったため、一方的な通信でした。SMSは、電話に使用される限られた制御チャネルに収まるように設計されており、メッセージは160文字に制限されていました。この制約により、SMSは軽量で堅牢になり、データ接続が弱い、または利用できない場合でも、ストアアンドフォワード配信が可能になりました。30年後の今日、この技術は、遠隔地や接続性が低い地域のモノのインターネット（IoT）デバイスにとって不可欠なものとなっています。多くのIoT展開では、Wi-Fiや安定したデータに依存できないため、ステータス更新やコマンドの信頼性の高いフォールバックとしてSMSが利用されています。デバイスは、セルラーモジュールを介して、最小限の電力と複雑さでアラートを送信したり、指示を受信したりできます。この堅牢性は、理想的なネットワーク条件を超えて信頼性の高い機能が必要な実世界の製品にとって非常に重要です。最初のSMSの永続的な遺産は、そのシンプルさ、効率性、そして堅牢性にあり、これらは効果的な組み込み設計に不可欠な品質です。

The First Text Message Said Merry Christmas dev.to

RSS Hunter • 昨日

MCP Appsにおける2つの未修正バグ、Claude用のタスクパネル構築中に発見

著者は、Claudeの会話内に永続的なタスクパネルを表示するオープンソースのMCPサーバーであるWingmanを開発しました。これには、著者が堅牢だと感じたMCP Appsおよび関連SDKの活用が含まれていました。しかし、2つの重大な文書化されていないバグが開発にかなりの時間を費やしました。最初のバグは`resourceUri`の配置に関するもので、これは`structuredContent`内ではなく、`CallToolResult`オブジェクトのトップレベルの`_meta`にある必要があります。ツールからプレーンな辞書を返すと、`_meta`が誤ってネストされ、ホストがレンダリングするリソースを見つけられなくなる可能性があります。 修正には、`_meta`が正しく配置された適切な`CallToolResult`オブジェクトを返すことが含まれます。2番目の重大なバグは、CSSの特異性の問題が`[hidden]`属性を上書きしたことに起因していました。カスタムスタイルシートの明示的な`display`ルールが、JavaScriptによって意図されたとおりに要素が非表示になるのを妨げていました。`[hidden]` CSSルールに`!important`を追加する1行で、3つの別々のUIの問題が同時に解決されました。 さらに、MCP Appsホスト内で3つのiframeサンドボックス制約に遭遇しました。`confirm()`はサイレントに失敗し、`navigator.clipboard.writeText`は利用できず、`Blob`/`URL.createObjectURL`のダウンロードはブロックされます。これらの制限には、インライン確認の使用や、`sendMessage`を介してコンテンツをルーティングするなどの回避策が必要です。著者は、これらのAPIの失敗は通常、エラーではなくサイレントな非動作につながるため、診断が困難であると強調しています。最終的に、両方の重大なバグは、最初の検査ポイントから1層離れた問題を含んでおり、デバッグ中にこれらの中間層を確認することの重要性を浮き彫りにしています。WingmanはMITライセンスで、PyPIで利用可能です。

Two undocumented bugs in MCP Apps I found building a task panel for Claude dev.to

RSS Hunter • 昨日

エージェントループについて人々が誤解していること

現在、誰もがエージェントシステムを「ソフトウェアファクトリー」と呼んでいます。しかし、ファクトリーが機能するのは、その品質管理が機械的で交渉の余地がないからです。CNCミルは公差を守るか、あるいは製造を中止します。ほとんどのエージェントループでは、エージェントが自身の出力を評価するため、その部分が省略されています。正確さのない量産です。 だからこそ、私たちはzeroshotを構築しました：https://github.com/the-open-engine/zeroshot 現在1500スターに達しました。さらに多くのフィードバックとトラクションを得たいと考えています。

What people get wrong about agent loops dev.to

RSS Hunter • 昨日

セルフホスト型Duendeからの移行：移行するもの、運用を停止するもの

Duende IdentityServerは.NETで独自のアイデンティティレイヤーを所有するための堅牢なソリューションですが、運用上のオーバーヘッドが大きいです。セルフホスティングでは、IdP自体のパッチ適用、スケーリング、ライセンス管理に加え、管理UI、MFA、監査ログなどの周辺機能すべてを構築する必要があります。多くのチームは最終的にこの運用上の負担を軽減することを決定するため、移行は重要な検討事項となります。良いニュースは、Duendeからの移行は、その設定がSQLにあり、ユーザーがASP.NET Identityにあるため、大部分が機械的なものであるということです。 クライアント、スコープ、ユーザーはスムーズに移行します。重要なのは、ASP.NET Identity V3のパスワードハッシュはネイティブでサポートされているため、他のIdP移行でよくある問題であるユーザーパスワードのリセットが不要になることです。ロール、割り当て、外部ログイン、OIDCアイデンティティプロバイダーも直接移行しますが、SAMLプロバイダーは再構成が必要です。アイデンティティの安定性を維持することが最優先事項であるため、移行ではユーザーの「sub」と「client_id」を保持し、下流の依存関係の破損を防ぎます。 移行ツールは、ロックアウトされたユーザーのdatetimeoffsetの処理など、インポートの失敗を引き起こす可能性のある微妙な問題を検出するために、実際のシードされたDuendeデータベースに対して厳密にテストされています。移行の主な利点は、IdPの運用を停止し、代わりにSAML、SCIM、MFA、監査ログ、カスタムブランディングの組み込み機能を利用して、パッチ適用とスケーリングの責任を軽減することです。完全な制御を維持することが引き続き優先事項である場合、Duendeを使い続けることは有効な選択肢です。しかし、IdP運用から時間を再配分したい組織にとって、Duendeからのスムーズな移行は魅力的な選択肢であり、コミットする前にインポートを評価するための読み取り専用プレビューを提供します。

Leaving self-hosted Duende: what migrates, and what you stop operating dev.to

RSS Hunter • 昨日

Immutable Ledgers はベクトル検索の未来か？そしてそれはローカルで実行される。

このドキュメントは、ハッシュチェーンとメルクルトリーを使用したストレージシステム整合性のためのイミュータブルレジャーを探求します。Kamelotの追記専用レジャーを例としたアーキテクチャは、データ整合性とバージョン履歴を強化します。メルクルトリーや認証済み辞書のような基本的な暗号構造を検討します。これらは、効率的な検証と追記操作を備えたGitのようなコンテンツアドレッシングを可能にします。この研究は、主権的でローカルファーストなAIインフラストラクチャが現在達成可能であると主張しています。Anticloudプロジェクトは、従来のAIに対する透明で検証可能な代替手段として提示されています。外部APIや中央集権型データベースなしで、設計によるプライバシーを優先します。システムは出力を相互検証し、誤った自信を生み出すのではなく、不確実性を表現します。ローカルAIは、RAGとRLHFを通じて達成され、知識と設定はユーザーハードウェア上に保持されます。Anticloudは単一のマシンとバイナリを必要とし、信頼の必要性を排除します。Lois-Kleinner Alpasanは、AI業界におけるデータ抽出慣行への対応としてこのシステムを開発しました。このプロジェクトは、検証可能な主張、オープンソースコンポーネント、およびプライバシー中心のアーキテクチャを強調しています。

Immutable Ledgers is the future of vector search ? and it runs locally. dev.to

RSS Hunter • 昨日