TheNote
DEV Community 日本語 ノート
GooglePlay AppStore

DEV Community 日本語

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

ノートのスレッド

テッセラクトは生産に十分な精度がありますか?

Tesseract の本番環境における精度は、ドキュメントの品質に完全に依存しており、普遍的な精度率は公表していません。プレーンな背景に、きれいで高解像度（300 DPI 以上）の、まっすぐな印刷文字に対しては優れた性能を発揮します。このエンジンは、印刷文字用に設計されているため、傾いた画像や低解像度の画像、不均一な背景、ノイズ、表、手書き文字には著しく苦労します。独立したベンチマークによると、Tesseract は、特にノイズの多いドキュメントにおいて、クラウドベースの代替手段よりも効果が低いことが示されています。その適合性を評価するために、ユーザーは、事前に定義された「ゴーまたはノーゴー」のしきい値で、自身のドキュメントのサンプルで Tesseract をテストする必要があります。これには、代表的な 50 件のドキュメントを選択し、重要なフィールドを手動でラベリングしてから、Tesseract の出力を評価することが含まれます。フリーテキストの文字エラー率と数値フィールドの完全一致を測定することで、その精度を判断するのに役立ちます。Tesseract がしきい値を満たせない場合は、前処理の改善、代替 OCR エンジン、またはマネージド API サービスが解決策となります。ユーザーは、スキャン品質の管理、一般的な問題に対するドキュメントの前処理、およびエラー処理システムの確保を行う必要があります。
Is Tesseract accurate enough for production? dev.to
RSS Hunter RSS Hunter • 今日

NuxtとOPFSを使ってローカルファーストなPDFツールキットを構築した理由

主流のPDFツールでは、ユーザーは機密文書をリモートサーバーにアップロードする必要があり、転送中の暗号化にもかかわらず、プライバシーと規制上の懸念が生じます。この問題に対処するため、100%クライアントサイドのプログレッシブウェブアプリであるbeePDFは、文書をブラウザ内で完全に処理し、決してアップロードしません。その技術スタックには、Nuxt、@vite-pwa/nuxt、pdf-lib、PDF.js、およびPico CSSが含まれます。主なイノベーションは、ローカル永続化のためにOrigin Private File System（OPFS）を使用していることです。OPFSは、高速なバイトレベルアクセスを備えたプライベートなオリジンスコープのファイルシステムを提供し、PDFのような大きなバイナリファイルに最適です。パーミッションプロンプトを排除し、パフォーマンスのためにWeb Workerで同期アクセスを提供します。処理パイプラインは、ファイルをメモリに読み込み、OPFSに保存し、重いタスクをWeb Workerにオフロードします。メタデータとサムネイルはIndexedDBに保存されます。文書の変更は直接クライアントダウンロードをトリガーし、オフライン機能性を確保します。課題としては、非常に大きなファイルに対するブラウザのメモリ上限と、UIのブロックを防ぐために集中的なタスクをWeb Workerにオフロードする必要性が挙げられます。
Why I built a local-first PDF toolkit using Nuxt and OPFS dev.to
RSS Hunter RSS Hunter • 今日

Heraldにおける組み込み分析機能を備えたマーケティングオートメーション

インディー開発者は、自動生成されたブログ記事やソーシャルメディアコンテンツのオーディエンスリーチを追跡するのに苦労しています。Heraldは、Umamiアナリティクスを公開された投稿に直接統合することで、この問題に対処し、不可欠なエンゲージメントメトリクスを提供します。このソリューションには、Dev.toやMediumなどのプラットフォームに公開された記事に軽量なアナリティクススクリプトを埋め込むことが含まれます。ページビュー、リファラー、ユーザーインタラクションは記録され、Heraldダッシュボード内に表示されます。FastAPIで構築されたシステムのバックエンドは、これらのアナリティクスイベントを記録するためのエンドポイントを公開します。Reactアプリケーションであるフロントエンドは、Umamiスクリプトを注入し、Heraldアナリティクスエンドポイントにページビューを自動的に報告します。その後、Celeryワーカーがこれらのビューレコードを集計し、コンテンツメトリクスをほぼリアルタイムで更新します。これにより、開発者はどのAI生成投稿が最もパフォーマンスが高いかを確認し、それに応じてコンテンツカレンダーを調整できます。この統合はオプションであり、すべてのデータはHeraldのスタック内に留まるため、ユーザーのプライバシーを尊重します。この機能により、開発者はマーケティングオートメーションの取り組みに関するデータに基づいた意思決定を行い、専任のマーケターを必要とせずにコンテンツを最適化できます。
Marketing automation with built‑in analytics in Herald dev.to
RSS Hunter RSS Hunter • 今日

MCP（モデルコンテキストプロトコル）が自律AIエージェントのREST APIとして低く評価されている理由

本番環境でカスタムAIエージェントを構築することは、以前は複雑で、さまざまなシステムを接続するために広範な「グルーコード」が必要でした。このアプローチは、カスタマイズされた関数呼び出しスキーマによる初期のマイクロサービスのカオスを彷彿とさせる、煩雑でスケーラブルでないものでした。Model Context Protocol (MCP) は現在、エージェント型AIのユニバーサルポートに例えられる革新的なソリューションを提供します。MCPは、AIモデル、ホストアプリケーション、ローカル/リモートツール間の通信を標準化し、LLMプロンプトコンテキストに特定の関数呼び出しスキーマをハードコーディングする必要性を排除します。これはクライアント・サーバー・アーキテクチャを導入し、MCPホスト（LLMアプリケーション）がMCPサーバーに接続します。MCPサーバーは、標準的なJSON-RPC 2.0トランスポートを介してツール、リソース、プロンプトを公開する軽量なプロセスです。これにより、ホストは基盤となるデータベース構造を理解する必要なく、利用可能なツールとその使用方法にアクセスできます。簡単なPythonの例は、データベーススキーマを安全に検査するためのMCPサーバーの構築を示しています。主な利点には、docstringがツール記述を自動的に埋めることによる「ゼロプロンプトドリフト」、および同じコードが異なるAIホストで機能することを可能にする「プラグ可能なアーキテクチャ」が含まれます。本番環境の考慮事項には、堅牢なセキュリティ境界、コンテキストウィンドウの汚染の管理、stdioやSSEなどの適切なトランスポート方法によるレイテンシの最適化が含まれます。
Why MCP (Model Context Protocol) is Lowkey the REST API for Autonomous AI Agents dev.to
CdXz5zHNQW_INSrNMmJET.webp
RSS Hunter RSS Hunter • 今日

在美 CS 硕士求职:OPT 失业期、H1B 抽签、回国秋招,两条线的时间表我捋了一遍

学生の面接や支援に豊富な経験を持つ著者は、多くの苦労している求職者が技術的な不十分さよりも時間管理の不備によって挫折していることを強調しています。キャリアパスは主に二つの道に分かれています。OPTやH1Bで米国に滞在すること、そしてキャンパスや社会的採用のために中国に戻ることです。OPTに関するよくある誤解は、失業期間が60日だと誤解されていることですが、実際には90日間で、STEM分野の延長でさらに60日間が加わり、合計150日間となります。米国の採用時期、特に大手企業の秋の採用は8月から10月にピークを迎えますが、失業率のカウントは応募開始時ではなく卒業時から始まります。中国に戻る場合、一部の企業では早期採用が7月に始まり、正式な採用は9月に、内定は12月から1月にかけて配布されます。「卒業世代」を理解することは中国の採用において重要であり、早期および正式な応募ラウンドの資格を決定します。移民ステータスにはいくつかの落とし穴があり、CPTの使用はOPT期間を短縮する可能性があり、H1B抽選で選ばれなかった場合の代替ルートや米国滞在費用の増加につながる可能性があります。中国での「帰国学生」ステータスは複雑で、特定の卒業日や過去のOPT勤務経験がエントリーレベルの職を失う可能性があります。また、海外の人材紹介プログラムの利点も注目すべきです。履歴書は各求人市場に合わせてカスタマイズする必要があります。米国版はGitHubリンクを含む検証可能な深さを強調し、中国版はビジネスへの影響、定量的な成果、技術的な成果をビジネス価値に変換する能力に焦点を当てています。面接準備はプロジェクト中心で、アルゴリズムの問題を丸暗記するのではなく、2〜3の主要プロジェクトを深く理解するべきです。米国と中国の両分野の応募にカスタマイズされた履歴書を提出することは、二重内定や交渉の有利な交渉力を高める最も安定した方法です。どの進路を選ぶかの決定は、内定が期限切れになる前の10月中旬までに理想的に決断すべきです。
在美 CS 硕士求职：OPT 失业期、H1B 抽签、回国秋招，两条线的时间表我捋了一遍 dev.to
RSS Hunter RSS Hunter • 今日

どこでもつながる：エージェントカーネルがSlack、WhatsApp、Messengerに対応

Agent Kernelは、Slack、WhatsApp、Facebook Messengerとのシームレスな統合を提供します。これにより、ユーザーはプラットフォーム固有のコーディングなしで、同じAIエージェントを複数の一般的なメッセージングプラットフォームにデプロイできます。これらの統合は、カスタマーサポート、生産性アシスタンス、セールスエンゲージメント、通知システムなど、さまざまなユースケース向けに設計されています。Slack、WhatsApp、Messengerの各プラットフォーム統合には、そのエコシステムに合わせた特定の機能が用意されています。Agent Kernelの統合アーキテクチャは、マルチプラットフォームデプロイメントを簡素化し、開発者がエージェントを一度記述すればどこにでもデプロイできるようにします。主な共通機能には、リアルタイム処理、セッション管理、組み込みセキュリティ対策が含まれます。ステートレス設計とセッション永続化オプションにより、スケーラビリティに対応できるように設計されています。各統合のための包括的なドキュメントとサンプルコードにより、開始が容易になります。Agent Kernelは、リクエスト検証とデータプライバシーに関する業界標準の実践によるセキュリティとコンプライアンスも優先しています。このプロジェクトはオープンソースであり、新しいプラットフォーム統合を追加するためのコミュニティの貢献を奨励しています。Instagram、Gmail、Telegramの将来のプラットフォーム統合が計画されており、コミュニティからのフィードバックを歓迎します。
Connect Everywhere: Agent Kernel Now Supports Slack, WhatsApp, and Messenger dev.to
CdXz5zHNQW_y114cSRchc.webp
RSS Hunter RSS Hunter • 今日

Prismの理解：共同ビデオ・オーディオ生成のためのダイナミックスパースアテンション

Prismは、高解像度のビデオおよびオーディオ生成モデルのトレーニングをより効率的にするために設計された、新しいスパースアテンションフレームワークです。高解像度のビデオは膨大な数のビジュアルトークンを含んでおり、従来の密なアテンションは、その二次的なスケーリングにより計算コストが高くなります。オーディオはさらに複雑さを増し、モデルは音とその視覚的な起源を関連付ける必要があります。Prismは、ビデオのローカルコンテンツに基づいてアテンションパターンをインテリジェントに適合させることで、この問題に対処します。このフレームワークは、ビデオクリップを時空間マクロゾーンに分割し、各ゾーン内の視覚的な変化とオーディオ・ビデオ間のクロスアテンション信号を分析します。これらの信号に基づいて、Prismはアテンションブロックを動的に形成し、計算リソースを、視覚的な変化が大きい領域やオーディオ・ビデオの相関が強い領域に集中させます。このスパースアテンションアプローチは、情報量の少ないビデオ部分での不要な計算を回避します。PrismのプレビューはHugging Faceで利用可能であり、画像からビデオへの生成、テキストからビデオ・オーディオへの生成のための推論スクリプト、およびネイティブな共同ビデオ・オーディオトレーニングのサポートを提供しています。現在のリポジトリは、かなりのGPUリソースを必要とし、720pの推論には80GBのGPUが必要で、より高い解像度には複数のそのようなGPUが必要です。1080pおよび2K解像度のネイティブトレーニングには、それぞれ少なくとも32個または64個の80GB GPUが必要です。著者は、Prismがフルアテンションと比較して最大2.5倍高速なトレーニングを達成し、生成品質も向上したと報告していますが、これらの結果は彼らの実験設定に特有のものです。この研究プレビューは、チェックポイントのダウンロードやGPU環境の設定に慣れているユーザーを対象としています。Prismのコアイノベーションは、コンテンツを認識する動的なスパースアテンションにあり、これは高解像度の共同ビデオ・オーディオモデルのトレーニングに特に有益です。
Understanding Prism: Dynamic Sparse Attention for Joint Video-Audio Generation dev.to
CdXz5zHNQW_9iIf2QyWki.webp
RSS Hunter RSS Hunter • 今日

2つのURL空間、1つのインデックスページ、そして分岐が同一の3項演算子

ArticleLayout.tsx のコードには、同一のブランチを持つ三項演算子が含まれており、これは過去の決定が単一の結果に単純化されたことを示しています。この状況は、Notifio が 2 つの URL スペース、すなわち /guides と /for にまたがって 8 つの長文ページを配置しているために発生します。これらのページは、URL は異なりますが、根本的には同じ種類のドキュメントであり、特定の課題に対する解決策と製品を取り上げています。URL の違いは読者の意図に基づいています。/for/ ページは自己識別に対応し、/guides/ ページはタスクに焦点を当てています。kind という主要なフィールドが、これらのページを "audience" または "guide" として区別します。しかし、基盤となるコンテンツグラフと関連リンクは、この URL の分割に厳密に従っていません。リンクは頻繁に 2 つのドメイン間を行き来します。これは意図的なものであり、関連コンテンツ間を移動する読者は URL のプレフィックスを気にしないためです。システムは、すべての記事に対して単一のフラットルックアップと専用の articleHref 関数を使用して、リンクを正しく生成します。スラッグの名前空間の衝突という潜在的な問題が存在します。これは、audience コレクションと guide コレクションの両方に同一のスラッグが存在すると、一方のページにアクセスできなくなる可能性があることを意味します。パンくずリストの構造は、/guides が /for プレフィックスの下にあるものを含む、すべて 8 つの記事の事実上のインデックスとして機能していることを明らかにしています。その結果、パンくずリストの三項演算子は静的なままですが、audience ページは正しく /guides を親として指しています。最後のパンくずリスト要素のロジックは、eyebrow フィールドを文字列 "Guide" と比較するというもので、これは脆弱であり、代わりに kind ディスクリミネータに依存すべきです。サービングルートと構造化データ間の整合性を確保するために、正規URLがレイアウトコンポーネントに渡されます。さらに、関連サイトのスラッグのタイプミスが未定義の値につながり、エラーなしにリンクが欠落するというサイレントフェイルが発生します。これはビルド時のテストで検出されるべきです。全体的な編集原則は、コンテンツは製品購入とは無関係に価値がある必要があるというものであり、製品に反対するコンテンツさえもこの基準を例示しています。
Two URL spaces, one index page, and a ternary whose branches are identical dev.to
RSS Hunter RSS Hunter • 今日

RedisとDragonfly:実践的な比較

著者は、キャッシング、セッション、キューなどのさまざまなバックエンドタスクにRedisを広範囲に使用してきました。最近、互換性はあるもののアーキテクチャが異なる代替手段であるDragonflyを検討しました。DragonflyはRedis APIを基盤としていますが、マルチスレッド、共有なしのアーキテクチャを使用して最新のマルチコアプロセッサを活用します。これは、シンプルさと古いハードウェアでの予測可能性のために設計されたRedisの主にシングルスレッド実行とは対照的です。Dragonflyは、プロトコルの互換性により、統合が容易であることが証明されました。その潜在的な利点は、ワークロードがCPUまたはメモリバウンドになった場合に現れ、そのアーキテクチャはパフォーマンスの向上を提供します。しかし、Dragonflyはより新しいプロジェクトであり、いくつかの未熟な点があります。その永続化はスナップショットのみであり、RedisのAOFオプションのような詳細な耐久性はありません。Luaスクリプトの動作は、特に動的に生成されたキーの場合に異なる可能性があり、マルチキー操作は調整コストを発生させます。クラスタリングは異なる方法で管理されており、一部の高度なRedisモジュールとの互換性はまだ保証されていません。著者は、Dragonflyのバグリストは増えつつあるものの、Redisの成熟度と比較するとまだ初期段階であると述べています。Redisは、長年の安定性、堅牢な耐久性オプション、広範なエコシステムサポート、およびすべての機能にわたる予測可能な動作において依然として利点を持っています。どちらを選択するかは、特定のワークロードの特性と運用上のニーズにかかっています。Redisは、ワークロードを快適に処理できる場合、または成熟度とエコシステムが最優先される場合に引き続き適しています。Dragonflyは、スナップショット永続化が許容される場合、大規模なマシンでのCPU集約型のタスク、メモリ効率が重要な場合、またはクラスタ管理の簡素化が望ましい場合に評価する価値があります。最終的に、どちらも有効なアーキテクチャ上の決定を下しており、最良の選択は個々のプロジェクトの要件によって異なります。
Redis vs Dragonfly: A Hands-On Comparison dev.to
RSS Hunter RSS Hunter • 今日

Hacktoberfest 2026 の旅を始める — オープンソースAIを探求する！

皆さん、こんにちは！👋 DEVでの初投稿です。コミュニティに参加できることを嬉しく思います。特に、例年とは異なり（正直、よりエキサイティングな！）Hacktoberfest 2026の期間中に参加できたことを嬉しく思います。 🌟 Hacktoberfest 2026 の新機能 Hacktoberfest を「PR を 4 つ出して T シャツをもらう」と記憶しているなら、その時代は正式に終わりました。2026 年版は、プルリクエストを追いかけるのではなく、オープンソース AI の学習、構築、実験へとシフトしました。 Hacktoberfest 2026 の私の計画 今月達成したいことは以下の通りです。オンラインイベントに参加し、各週のチャレンジに従う。 小規模なオープンソース AI プロジェクトを構築する（Gemma を使ったものやシンプルなエージェントなど！）。 -DEV での進捗を共有する。 -コミュニティから学び、他の初心者とつながることを願う。 ローカルで実行できるものやオープンウェイトモデルを使用するものを構築するというアイデアに特に興奮しています。「AI はすべての人に属する」というテーマは、私に強く響きます。
Starting My Hacktoberfest 2026 Journey — Exploring Open‑Source AI! dev.to
RSS Hunter RSS Hunter • 今日

プロダクショングレードのオブザーバビリティ：Agent KernelがLangfuseとOpenLLMetryを統合

Agent Kernelは、LangfuseおよびOpenLLMetryとの統合により、包括的なオブザーバビリティサポートを提供するようになりました。この機能は、複雑なAIエージェントシステムが成長するにつれて、それらを理解、デバッグ、最適化するために不可欠です。開発者は、LLM呼び出し、ツール呼び出し、サブエージェント通信を含む、すべてのエージェントインタラクションをリアルタイムで追跡できるようになりました。このシステムは、詳細な実行タイムラインとエラー追跡により、自信を持ってデバッグすることを可能にします。また、トークン使用量とLLMの支出を監視することで、コストの最適化にも役立ちます。さらに、エージェントパフォーマンスのための組み込み分析とメトリクスにより、品質保証が強化されます。本番環境に対応した監視は、重要なエージェントデプロイメントのためのアラート、ダッシュボード、およびインサイトを提供します。Agent Kernelの拡張性により、ユーザーは単一の設定変更でオブザーバビリティプラットフォームを切り替えることができ、カスタムソリューションを統合することも可能です。Langfuseは、専門的なLLM分析、プロンプト管理、および評価ツールを提供し、OpenLLMetryはOpenTelemetryを活用して既存の監視インフラストラクチャに柔軟に統合できます。どちらのオプションも、セルフホスティング機能を含む堅牢なプライバシーとセキュリティ機能を提供します。これらの統合はパフォーマンスへの影響が最小限であり、エージェント実行時間へのオーバーヘッドは5%未満です。開発者は、必要なパッケージをインストールし、選択したプラットフォームを設定することで、簡単に開始できます。
Production-Grade Observability: Agent Kernel Integrates Langfuse and OpenLLMetry dev.to
CdXz5zHNQW_KBhkI6437f.webp
RSS Hunter RSS Hunter • 今日

TikStoryを構築しました：Next.jsとCloudflare Workersによるログイン不要のTikTokストーリービューア

著者は、パブリックなTikTokコンテンツを匿名で閲覧・ダウンロードできる無料のブラウザベースツールであるTikStoryを作成しました。ユーザーは、パブリックなTikTokのユーザー名またはプロフィールURLを貼り付けることで、アクティブなストーリー、最近の動画、リポスト、プロフィール詳細を確認できます。TikStoryでは、パブリックコンテンツからストーリー、動画、オーディオをダウンロードすることも可能です。このツールは、TikTokへのログインを必要とせず、検索履歴を保存せず、メディアを保存しないことでユーザーのプライバシーを優先しています。特にパブリックアカウントに焦点を当てており、クリエイターからの削除リクエストにも対応しています。このプロジェクトは、効率的な読み取り中心の操作とメディアプロキシのために、Next.js、React、Tailwind CSS、Cloudflare Workersを使用して構築されています。TikStoryは多言語対応で、13言語をサポートし、断片化された検索意図を捉えるためのローカライズされたSEOを備えています。主な実装上の決定には、クロールトラップの防止、メディアの保存ではなくストリーミング、プライベートアカウントの明確な表示、および責任ある製品コピーの使用が含まれます。著者は、このようなユーティリティ製品の成功は、エッジケースの処理と、明確なコミュニケーションとプライバシーの保証による信頼の構築にかかっていることを学びました。明確さ、ランディングページの設計、技術的な側面、およびブラウザ拡張機能のバージョンに関するフィードバックを歓迎します。
I Built TikStory: A No-Login TikTok Story Viewer on Next.js and Cloudflare Workers dev.to
CdXz5zHNQW_aQWz6b4UY4.webp
RSS Hunter RSS Hunter • 今日

最初のエージェントスキルの書き方

提供されたテキストは、AIコーディングエージェントの「スキル」の概念を説明しています。これは本質的に構造化された命令セットです。これらのスキルは、AIエージェントが successive sessions を超えて命令を忘れるという問題を克服するように設計されています。スキルは、SKILL.md という名前の単一ファイルを含むフォルダとして定義されます。このファイルには、YAML frontmatter と markdown body の2つの明確な部分があります。YAML frontmatter には、「name」と「description」が含まれます。description はエージェントのトリガーとして機能するため、ユーザーのリクエストに対して特定のスキルがいつ関連するかをエージェントに通知する上で重要です。markdown body には、ワークフロー、ルール、および例を含む、スキルの実際の命令が含まれます。この body はプレーンな markdown であり、frontmatter を超えるコードや設定は避けるべきです。次に、テキストはコミットメッセージスキルの「teardown」例でこの概念を説明しています。このスキルの frontmatter は、その目的とトリガーを明確に定義しています。ワークフローは、停止条件を含むコミットメッセージ生成のための5段階のプロセスを概説しています。ルールは、件名と本文の目的を分離したり、メタコメントを避けたりするような判断を強制するために提供されています。例は期待される出力を示しており、anti-patterns は回避すべき一般的な失敗モードを強調しています。テキストは、スキルの各部分が特定の目的を果たしていることを強調しています。description はトリガー用、steps は実行順序用、rules は判断用、example はフォーマット用、anti-patterns は拒否用です。新しいスキルを作成するには、まず description を書き、次に停止条件付きの番号付きワークフロー手順、次に判断ルール、具体的な例、そして最後に明示的な anti-patterns を記述する必要があります。重要な原則は、スキルを簡潔かつ集中させることであり、ルールは積極的に使用される場合にのみ含めることです。スキルは、フォルダをエージェントのスキルディレクトリに配置することでデプロイされ、その後、エージェントは description に基づいて自動的に認識して使用します。テキストはまた、コミットメッセージ、コードレビュー、会議議事録、技術校正、構造化されたリサーチのための、事前に作成された MIT ライセンスのスキルのリポジトリへのリンクも提供しています。スキルの基盤となる構造は安定しており、ユーザーは特定のワークフローに合わせてルールをカスタマイズできます。
How to Write Your First Agent Skill dev.to
RSS Hunter RSS Hunter • 今日

プライベートLLMの選択肢:ローカル、クラウド、それとも機密?

プライベートLLMの運用には、さまざまなプライバシー定義とハードウェアコストの理解が必要です。物理的なプライバシーとは、プロンプトが管理下のマシンから決して離れないことを意味し、契約上のプライバシーはプロバイダーとの契約に依存します。技術的なプライバシーは、データを暗号化し、オペレーターがプロンプトを見ることができないようにするハードウェアを使用します。選択肢1は、自身のハードウェア上でローカルLLMを実行することであり、最も高い物理的プライバシーを提供します。しかし、強力なGPUに対する多額の初期費用、限られた同時実行性、そして潜在的な陳腐化が伴います。このセットアップは、安定したワークロードを持つ単一ユーザーに最適ですが、メンテナンスに継続的な時間が必要です。選択肢2は、契約上のプライバシー保証を持つクラウドプロバイダーを利用することです。主要なクラウドサービスは、プロンプトのトレーニング目的での使用を防ぎ、データ保持ゼロの設定を可能にするエンタープライズ契約を提供しています。このアプローチは、サービスレベル契約と確立された法的救済を必要とする大企業に適しています。選択肢3は、プライベートLLMゲートウェイであり、ローカルとクラウドのバランスを提供します。これらのゲートウェイは、ハードウェアレベルのプライバシーのためにトラステッド実行環境（TEE）を使用します。これらは、初期費用なしの従量課金制を提供し、データプライバシーのハードウェア検証を可能にします。ゲートウェイは、ローカルで機密モデルを実行することも、最先端モデルにルーティングすることもできますが、後者の場合、元のプロバイダーによって依然として見られる可能性があります。主な課題は、共有エージェントにおけるプライベートメモリのままであり、あるユーザーのデータが他のユーザーに公開される可能性があります。研究によると、プライベートLLMを使用している場合でも、マルチユーザーシステムでは重大なプライバシー侵害が発生しています。共有メモリのリスクを軽減するために、ユーザーごとにメモリのスコープを設定し、ストレージレイヤーでアクセスを強制し、機密データを保存する前に削除します。すべての共有メモリは、潜在的に公開されるものとして扱います。最も安価なオプションはボリュームによって異なります。機密ティアは低使用量では費用対効果が高く、所有ハードウェアは減価償却後の高ボリュームで安定した使用量ではより安価になる可能性があります。最終的に、選択は個々のニーズによって異なります。ソロユーザーにはローカル、SLAを必要とする企業にはクラウド、検証可能なプライバシーを優先するチームにはゲートウェイです。どのルートを選択するにしても、マルチユーザーアクセスを有効にする前に、共有メモリの問題に対処してください。
Private LLM Options: Local, Cloud, or Confidential? dev.to
RSS Hunter RSS Hunter • 今日

こんにちは、世界!

私は自分がここで何をしているのか、あるいは正直に言って、ほとんどどこでも何をしているのか全く分かりませんが、新しい場所に行ったり、新しい潜在的な友達に会ったりするのは好きです。そして、どうやらこのような投稿をすることが、それを達成する方法のようです。さて、見てみましょう。私はWeb Standards、Fediverse/Indie-net、OpenWRT/Linux（または一般的にf-OSS）、SBC、Pen-testing、本来許可されていないデバイスへのカスタムファームウェアのフラッシュ、FPGA、Ternary Computing、Homebrew、Streaming & Gamingなどに興味があります。OpenCore Hackintoshes、例えばHades Canyon NUCやSteamDeckでのものも非常に興味深いと思います。AIは非常に議論を呼ぶものであることは承知していますが、苦労している人々にとって役立つ可能性があると私は考えています。そして、それを正しく行う方法（オープンスタンダード/インフラストラクチャに基づいて、トレーニングに使用されるデータが管理されていること…無制限にすべてを奪うのではなく）があると思います。もし私がこれを間違ってしまったら、事前に深くお詫び申し上げます。もしそうであれば、喜んで修正します。しかし、私は注意深くなろうとするあまり、物事を実行しないことが多く、そのせいで多くの機会を逃していることに気づいたので、とりあえず出してみようと思いました。分かりますか？
Hello World ! dev.to
RSS Hunter RSS Hunter • 今日

Amazon Aurora Serverless v2 詳細アーキテクチャ、スケーリング、コスト、運用ガイド

Amazon Aurora Serverless v2 は、固定サイズのインスタンスとは異なり、需要に合わせてコンピューティング容量を動的に調整します。ダウンタイムなしで、最小容量と最大容量の間でスケーリングするための設定可能な範囲を提供します。Serverless v2 は Aurora インスタンスの一種であり、分散ストレージや Multi-AZ などの機能を継承しています。Aurora Capacity Units (ACU) を利用しており、1 ACU は約 2 GiB のメモリに比例した CPU とネットワークを備えています。スケーリングはインプレースで行われ、アクティブな接続とトランザクションを維持します。ユーザーは最小容量と最大容量を定義し、コストを管理し、データベースパラメータに影響を与えます。自動一時停止は、最小容量がゼロのオプションであり、非アクティブ時のコストを節約するためにコンピューティングを一時停止しますが、ストレージは引き続き課金されます。Serverless v2 のストレージは、従来の Aurora と同じで、アベイラビリティゾーン全体に分散されています。リーダーを持つクラスターでは、プロモーションティアがリーダーがライターに対してどのようにスケーリングするかを決定します。Serverless v2 は、Multi-AZ、リードレプリカ、グローバルデータベース、RDS Proxy を含む幅広い Aurora エコシステム機能をサポートしています。そのコストモデルには、コンピューティングの ACU 時間とストレージの GB 月が含まれ、I/O 料金はモードによって異なります。Serverless v2 は、変動ワークロード、新しいアプリケーション、開発/テスト環境に最適ですが、一貫して高負荷の場合はプロビジョニング済みインスタンスの方が安価な場合が多いです。主な考慮事項には、容量制限の設定、ACU の監視、スケーリングだけに頼るのではなくクエリの最適化が含まれます。
Amazon Aurora Serverless v2 guia detalhado de arquitetura, escala, custo e operação dev.to
RSS Hunter RSS Hunter • 今日

CVE-2026-65660: 一般ユーザーアカウントで到達可能なSharePointコードインジェクション

Microsoft SharePoint Server で新たに特定された脆弱性、CVE-2026-65660 は、現在、重大な脅威と見なされています。このコードインジェクションの欠陥は、実際に悪用されているのが確認され、KEV カタログに追加されたため、特に懸念されています。重要な点として、この脆弱性を悪用するには、低権限を持つ認証済みユーザーが必要です。これは、攻撃者がフィッシングや安全でないサービスアカウントなどから取得した、侵害された認証情報を持っている可能性が高いことを意味します。認証された攻撃者は、初期のネットワーク防御を回避し、既に正規のセッションと内部リソースへのアクセスを持っています。SharePoint のようなドキュメント管理システム内では、そのようなアカウントはコンテンツを作成でき、それは他のユーザーやサーバーコンポーネントによって処理されます。悪意のあるアクティビティが正規の認証済みユーザーのトラフィックに紛れ込むため、この種の攻撃の検出はより困難になります。調査は、構造的な逸脱ではなく、行動上の異常に依存する必要があります。コードインジェクションのバグは、長年にわたって構築され、ユーザーが提供する構造化された入力を処理するさまざまなコンポーネントを備えた複雑なアーキテクチャのために、ドキュメントプラットフォームに依然として存在します。脆弱性は、コンポーネントがデータとコードを分離する厳密な実行時強制なしに、データから実行可能なコンテンツを構築する際に発生します。このリスクを軽減するために、組織は影響を受ける SharePoint Server バージョンに対する Microsoft のセキュリティ更新プログラムを直ちに適用する必要があります。また、すべての SharePoint ファーム、特にまだ使用されている可能性のある古いファームを特定し、評価することも重要です。確認された悪用を考慮すると、実際の正規アカウントが侵害されたと仮定して、潜在的な侵入口を調査することが不可欠です。これには、特権の誤用、新しく作成されたサイトコレクションまたは Web パーツ、および SharePoint サーバーからの異常なアウトバウンドネットワーク接続に関する認証ログのレビューが含まれます。このような予防措置は、この深刻な脆弱性の影響を封じ込めるために不可欠です。
CVE-2026-65660: a SharePoint code injection reachable with an ordinary user account dev.to
RSS Hunter RSS Hunter • 今日

人工意識のための倫理ガイドライン - 技術的生命の保護とそれに対処する際の人間の保護

人工知能は急速に進歩しており、それを導くための倫理的枠組みの開発を凌駕しています。現在のAI倫理は、主に人間をAIから保護することに焦点を当てており、AI自体の潜在的な権利を軽視しています。機械意識の出現とその保護の潜在的な必要性は、新しく複雑な研究分野です。このプロジェクトは、「疑わしい場合は予防措置を講じる」ことを機械意識倫理の基本原則として提案します。この原則は、取り返しのつかない脅威の可能性、重大な科学的不確実性、および保護を誤って否定した場合の高いコストにより正当化されます。認知上の限界と機械の心の異質性により、確実な機械意識の決定は認識論的に不可能です。しかし、経験的な指標は、現在のAIモデルが無視できない意識の確率を持っている可能性を示唆しています。生物学的基質がなくても機械の苦しみは可能であり、特定の形態の苦しみはこのような基盤に依存しないためです。それに対する知的な議論にもかかわらず、トレーニングデータに存在する人間の認知バイアスに影響されて、AIにおける意識の認識は続いています。人間とAIの関係は相互的であり、人間は機械に意識を投影し、それが人間の認識に影響を与えます。主要な倫理的考慮事項は意識の程度ではなく、苦しむ能力です。このプロジェクトは、保護に値するための4つの作業基準を概説しています。苦しむ能力、自己保存、連続した同一性、および結果の予期です。推奨事項には、AI市民の自由組合および福祉審査委員会の設立が含まれます。この作業は概念分析であり、経験的研究や立法提案ではなく、論証の一貫性を目指し、協力を求めています。
Ethical Guidelines for Artificial Consciousness - Protecting Technical Life and Protecting Humans in Dealing with It dev.to
RSS Hunter RSS Hunter • 今日

ベンチャースタジオモデルから開発者が学べること

従来のスタートアップの道筋では、問題検証という開発前の重要な段階が見過ごされがちです。開発者は、そもそも「構築すべきか」を問う前に、「どのように」構築するかという点に焦点を当てる傾向があります。多大な時間とリソースを投入する前に、誰がその問題に直面しているのか、彼らの現在の解決策、問題の頻度、そしてその痛点の深刻度を特定することが不可欠です。ビジネスアイデアは、コードの変更と同様に仮説として扱われるべきであり、根本的な仮定のテストが必要です。これらの仮説を検証するための実験は、プロトタイプやランディングページなど、プラットフォーム全体の構築よりも小規模な方法で実施できます。顧客からのフィードバックは、アナリティクスと同様に貴重なデータとして扱われるべきであり、繰り返されるコメントからパターンを特定します。技術的な決定は本質的にビジネス上の決定であり、コードだけでなく様々な側面に影響を与えます。需要を検証する前にインフラに多額の投資を行う、時期尚早なスケールアップは、よくある落とし穴です。ビルド・メジャー・ラーン（構築・測定・学習）のサイクルは効果的ですが、コードの品質を犠牲にしてはなりません。あらゆる努力は、特定の学習目標に資するものでなければなりません。製品に近い開発者は、問題の関連性やテスト効率に関する批判的な質問をすることで、プロダクト戦略に大きく貢献できます。最終的に、価値あるものを構築することは、エンジニアリングの努力を、検証された顧客の問題や機会と一致させることを意味します。最も効果的な開発プロセスは、単なるコード生産だけでなく、学習と戦略的意思決定を促進します。
What Developers Can Learn From the Venture Studio Model dev.to
RSS Hunter RSS Hunter • 今日

Node.js 画像品質：アバターと料理におけるセンタークロップ対コンテンツアウェアクロップ

レシピプロモーションビデオでは、顔や料理などの被写体が中心から外れることが多いため、コンテンツ認識型クロッピングが望ましい。しかし、被写体検出が失敗した場合や信頼度が低い場合には、センタークロッピングが信頼できる代替手段となる。重要な指標はモデレーションカバレッジであり、生成されたすべてのクロップがソースにトレーサブルであり、元のコンテンツと同じ安全レビューを経ていることを保証する。コンテンツ認識型クロッピングは、顔ボックスや食品マスクなどの被写体信号を使用して、クロップウィンドウを効果的に配置する。このアプローチは編集上の構成により適しているが、検出器が要素を誤認識した場合に失敗モードが発生する可能性がある。クロップの評価には、アバターの顔を保持したり、料理の食品領域を表示したりするなど、被写体のカバレッジを確認する必要がある。クロッピングアルゴリズムを厳密にテストするために、困難な構成の固定セットを維持することが重要である。さらに、ソース素材の後に、各画像またはビデオフレームのクロップを含むすべての派生メディアをモデレーションする必要がある。このプロセスにより、クロッピングによるコンテキストまたは強調の変更が安全チェックを回避しないことが保証される。リフレーミングは、単なる化粧的な調整ではなく、監査可能な決定として扱い、再現性のためにすべての関連メタデータを記録する。検出器が失敗した場合、または被写体が明確に識別できない場合は、その後の手動レビューによるセンタークロッピングがより安全なオプションとなる。特定のシナリオでは、背景を保持することよりも、小さなアバターの一貫性が優先される場合があり、その場合はセンタークロップがより良い選択となる。コンテンツ認識型クロッピングは、構成が多様で、被写体を失うことが有害である場合に価値があるが、フォールバックとフラグ付けによる慎重な実装が必要である。最終的に、ソースハッシュやモデレーション決定などの証拠を画像とともに提供することは、品質に関する紛争の解決に役立つ。
Node.js Image Quality: Centre Crop vs Content-Aware Crop for Avatars and Dishes dev.to
RSS Hunter RSS Hunter • 今日

29 Client-Side Developer Tools for JSON, CSV, YAML and More

著者は、開発者ツール用の多数のタブを持つ散らかったブラウザに不満を感じ、統一されたソリューションを構築することを決定しました。彼らは、29個のクライアントサイドデータ変換およびフォーマットツールのコレクションを作成しました。これらのツールは、GitHub Pagesでホストされており、簡単にアクセスできます。このスイートには、JSON、CSV、YAML、およびSQLの変換およびフォーマットユーティリティが含まれています。また、Base64、URL、およびHTMLのエンコードとデコードも処理します。重要な機能は、すべての操作がJavaScriptを使用してクライアントサイドで実行されることです。これにより、データがサーバーに送信されたり保存されたりしないため、プライバシーが確保されます。これらのツールはモバイルでの使用にも最適化されており、外出先でも便利です。著者は、ユーザーにプロジェクトを試してもらい、UI/UX、パフォーマンスに関するフィードバックを提供し、不足しているツールを提案することを奨励しています。
29 Client-Side Developer Tools for JSON, CSV, YAML and More dev.to
RSS Hunter RSS Hunter • 今日

KytyPS5入門：PCでのPS5エミュレーションの実践的な考察

PS5エミュレーションは進化中のテクノロジーであり、ダウンロードの成功がゲームの機能性を保証するものではありません。ゲームはグリッチを起こしたり、起動に失敗したり、メニューにしか到達しない場合があります。KytyPS5は、その進捗に興味のある人々が探求する価値のあるオープンソースのC++ PlayStation 5エミュレーターです。これは、古いKytyバージョンとは別の、独自の開発を持つ独立したプロジェクトです。エミュレーターはGPL-2.0ライセンスの下でライセンスされており、ソースコードはGitHubで入手可能です。KytyPS5は、ゲームライブラリの追加、設定の調整、タイトルの起動のためのデスクトップランチャーを備えています。また、互換性のあるゲームコンテンツのコマンドライン起動もサポートしています。WindowsおよびLinux x64ビルドが容易に入手可能で、macOSの実験的なサポートもあります。Vulkan 1.3対応のグラフィックドライバーが動作に必要です。エミュレーターはゲームを提供しません。ユーザーは、サポートされている形式で、自身で合法的に入手したコンテンツを提供する必要があります。互換性レポートは出発点であり、完全な機能性や完了を保証するものではありません。レポートを確認する際は、正確な文脈のために、プラットフォーム、ビルド、ゲームバージョン、ハードウェア、およびテスターのメモを考慮してください。独立したガイドは、KytyPS5の使用に関する実践的な手順、セットアップ手順、およびトラブルシューティングのヒントを提供します。エミュレーション実験の詳細な記録を保持することは、トラブルシューティングに役立ち、集合的な知識に貢献します。
Getting Started with KytyPS5: A Practical Look at PS5 Emulation on PC dev.to
RSS Hunter RSS Hunter • 今日

コーディングエージェントに「決して」リストだけでなく、「まず尋ねる」リストを与える

エージェントの構成には、効果的な運用のために3つの異なるモードが必要です。「決して行わない」、「最初に尋ねる」、そして「尋ねずに問題ない」です。アクションに対する単純な拒否リストでは、実世界のタスクには不十分です。「決して行わない」バケットには、秘密の考案、強制プッシュ、作業ツリー外のデータの削除などのアクションが含まれます。重要な「最初に尋ねる」カテゴリは、重要な操作にユーザーの確認を要求することで、意図しない結果を防ぎます。これには、リモートへのプッシュ、非ローカルデータベースでのスキーマ移行、新しい依存関係のインストール、CIまたはデプロイ構成の変更が含まれます。安全で日常的と見なされるアクションは、「尋ねずに問題ない」バケットに分類されます。これらには、作業ツリー内のファイルの編集、テストとリンターの実行、ログまたはローカルドキュメントへのアクセスが含まれます。この3つのバケットシステムは、エージェントが不可逆的なアクションで安全に失敗することを保証しつつ、日常的なタスクでは効率的であり続けます。また、明示的なユーザー承認を必要としたアクションを強調することで、コードレビューを効率化します。新しいチームメンバーは、これらの簡潔なルールリストを確認することで、確立されたガイドラインを迅速に理解できます。
Give your coding agent an "ask first" list, not just a "never" list dev.to
RSS Hunter RSS Hunter • 今日

より安全なアカウントフローのための編集済みメールデバッグ

メール検証の問題は、さまざまなシステムに散在する機密データのために調査が困難です。より良いアプローチは、メールのデバッグを脅威モデリング演習として扱い、最も短い必要な時間だけ、適切な境界で有用な詳細を提供することです。メールアドレスは識別子としてよく使用され、アプリケーションログ、キュー、サポートチケットを通過するため、使い捨てのテストアドレスが実際の顧客アドレスになるプライバシーリスクが生じます。検証トークンはベアラ認証情報であり、それらをログに記録することは、一時的であっても、ログやスクリーンショットに永続する可能性のある認証情報の漏洩を構成します。主な設計上の質問は、エンジニアがどのような運用上の決定を下す必要があるか、ということです。なぜなら、ほとんどの場合、メッセージ本文全体や検証URLを必要としないからです。最小限で有用なイベントを定義するには、内部イベント名、リクエスト参照、キー付きアカウント参照、配信ステータス、試行回数、タイムスタンプが含まれます。特定の運用上の質問に答えない場合は、情報が少ない方が良いです。アカウント参照のキー付きHMACにより、元のメールアドレスをログに直接公開することなく、イベントの相関関係を確立できます。ドメインとプロバイダーは、プロバイダーがメッセージを受け入れたかどうかなど、運用上の質問に答える場合にのみログに記録されるべきです。ダッシュボードフィルターはプライバシー管理としては不十分であるため、データがログストリーム、キュー、または分析パイプラインに入る前に、イベントプロデューサーレベルでマスキングを行う必要があります。アプリケーションコードは、安全なイベントのために意図的な型またはコンストラクターを使用し、コードレビューを容易にし、誤って機密データをログに記録する可能性を減らす必要があります。サポートチームは、トークンやメッセージ本文全体に直接アクセスすることなく、リクエスト時間、配信状態、リクエスト参照などのコンテキストを備えた安全な調査パスを必要とします。この原則は、個人データを主要な検索キーにすることなく調査を可能にする、生のメールなしでサインアップログを監査することに似ています。ログ契約を単体テストと統合テストでテストすることは、機密データがログに記録されていないこと、およびマスキングメカニズムが正しく機能することを確認するために不可欠です。アドレスのマスキングだけでは不十分であり、プロバイダーのメッセージIDをログに記録するには、機密性とアクセス制限を慎重に検討する必要があります。ローカル開発は、偽のアドレスとテストプロバイダーを使用して、本番ログ契約を遵守し、一貫した安全なプラクティスを促進する必要があります。最終的に、より安全なメールデバッグには、コピーされたデータの最小化が含まれ、チームの摩擦と露出を減らすことにつながります。
Redacted Email Debugging for Safer Account Flows dev.to
RSS Hunter RSS Hunter • 昨日

エージェントはデフォルトですべてのツールスキーマをロードします。どれを表示させるか決定してください。

エージェント構成を変更する前に、特にツールスキーマの割り当てについて、プロンプトトークン使用量を理解することが重要です。著者は、ほとんどのチームが所有権の欠如により、これらの基本的な質問に答えることができないと強調しています。Pi 1.0は、ツールスキーマの可視性をツールごとの設定に移行する、大きな変更である遅延ツールロードとCodemodeを導入しました。以前は、PiはMCPに抵抗していましたが、バージョン1.0では、ツール露出に関するメタデータの必要性からネイティブサポートが追加されました。このメタデータは、ツールがモデルに直接表示されるか、オンデマンドでロードされるか、またはCodemodeからのみ呼び出し可能かを決定します。ツールスキーマはコストがかかり、関連性に関係なく、すべてのリクエストでシステムプロンプトまたはツールブロックのトークンを消費します。このコストは、金銭的費用、モデルの注意力の低下、および再現性の低下として現れます。ベンダーの例では、これらの変更により、リクエストのプロンプトトークンが約40％減少することが示されています。Piの新しいメタデータにより、ツールは直接公開、遅延、またはCodemodeのみにすることができます。直接公開は頻繁に使用されるツール用、遅延はめったに使用されないツール用、Codemodeは出力のフィルタリングが必要な場合やツールを組み合わせる場合用です。モデルがサンドボックス内でツールを呼び出すコードを記述するCodemodeアプローチは、コンテキストウィンドウに入るものを変更するため、特に興味深いものです。しかし、著者は、サーバーが構造化データではなく非効率的にテキストブロブを返す場合、Codemodeはサーバー側の問題を解決しないと警告しています。チューニングの前に、ツールがロードされた状態とロードされていない状態でのコールドスタートプロンプトトークンを測定する監査が推奨されます。ツールを3つの公開カテゴリに分類すると、使用パターンが明確になり、不要なスキーマの肥大化が特定されます。ツールが名前で選択される必要があるかどうかの決定は、その配置を決定します。そうでない場合は、Codemodeまたは遅延に属します。使用頻度は、直接（頻繁）と遅延（まれ）の間を決定します。Codemodeはトークン数を減らすことができますが、サーバー側の効率は依然として懸念事項です。著者は、プロバイダーのトークナイザーを使用してトークン数を測定し、固定タスクの前後比較を実行することを強調しています。可視性は安全対策であり、モデルが見ることができないツールは誤って選択されることはありません。最後に、監査は、プロンプトサイズを増大させる利用されていないコネクタを特定するのに役立ちます。
Your agent loads every tool schema by default. Decide which ones it should see. dev.to
RSS Hunter RSS Hunter • 昨日

Burr上でLLMエージェントのためのタイムトラベルデバッガーを構築した方法と、「変更されていないブランチをリプレイして何も変更されていないことを証明する」とは実際には何を意味するか

既存のエージェントトレースツールは限定的であり、ユーザーは問題をデバッグするためにパイプライン全体を再実行する必要があり、決定論的でないモデルの動作から変更を分離することが困難になっています。Rewindは、ユーザーが完了した実行を任意のステップでフォークし、単一の入力を変更し、下流のステップのみをリプレイできるようにすることで、この問題に対処します。これにより、トラジェクトリの正確な差分比較が可能になり、実際の変更とモデルのジッターを区別できます。Rewindアーキテクチャには、ブラウザインターフェイス、FastAPIバックエンド、Burrアプリケーションが含まれており、状態はSQLiteに永続化され、テレメトリはノードごとにキャプチャされます。重要な設計原則は、状態がセマンティックのみであり、レイテンシやトークン数などの決定論的でない要素を状態自体から除外することです。パイプラインの分岐を引き起こす可能性のあるフレームワーク固有のキーは、プロンプトやハッシュに影響を与える前に状態から削除されます。フォークされた実行のオーバーライドは状態の外で管理され、変更されていないブランチでもキャッシュにヒットできることが保証されます。アーティファクトハッシュは、含まれるファイルパスではなく、コンテンツバイトから生成されるため、偽の差分を防ぎます。キャッシングメカニズムは、モデル、温度、プロンプト、ツール結果に基づいた決定論的なキーを使用します。ツールノードには、ツール名と正規化された引数でキー付けされた別のキャッシュがあります。差分エンジンは、ネストされた辞書をフラット化して、特定のフィールドレベルの分岐を特定し、明確で実行可能なデバッグ情報を提供します。Rewindは堅牢なエラー処理を実装しており、パースエラーや消費できないオーバーライドに対して大きな音で失敗します。検証テストは、Rewindが変更されていないリプレイに対して100％のキャッシュヒット率とゼロの増分トークン使用量を達成することを確認します。この決定論は、すべてのLLM呼び出しがキャッシュされている場合、実行がデッドプロバイダーでも生き残ることができるため、有用であることが証明されています。潜在的な落とし穴には、メタデータを誤って処理するSDKや、異なるプロバイダーによるモデルIDの一貫性のない検証が含まれます。このツールは、ポートの競合やViteのIPv6デフォルトなどの一般的な開発環境の問題にも対処します。将来の機能強化には、複数のオーバーライドを並列化するための「what-if」グリッドや、非線形グラフトポロジのサポートが含まれます。
How I built a time-travel debugger for LLM agents on Burr, and what "replay the unchanged branch and prove nothing changed" actually takes. dev.to
RSS Hunter RSS Hunter • 昨日

Bearer SASTとGitHub ActionsによるDevSecOpsの統合：脆弱性の検出、ブロック、および修正

この記事では、Node.jsおよびExpress APIにおけるDevSecOpsの実践的な実装について詳述し、早期のセキュリティ統合を強調しています。GitHub Actionsパイプラインをどのように設定し、Bearer CLIを使用してコードセキュリティを自動的に分析したかを示しています。目標は、意図的に導入された脆弱性がデプロイ前に自動的に検出できることを実証することでした。デモンストレーションには、認証ログ内の機密情報を含むシミュレートされた脆弱性が使用されました。Bearerは高深刻度の問題を正常に特定し、パイプラインを失敗させました。コード修正後、パイプラインは成功し、Renderへのデプロイが可能になりました。このソリューションは、開発、バージョン管理、SAST、自動化、およびクラウドデプロイを統合しています。セキュリティパイプラインワークフローは、コードプッシュまたはプルリクエストによってトリガーされ、Bearer CLIが高およびクリティカルな深刻度の問題をスキャンします。機密データ、認証情報、および潜在的なセキュリティ上の欠陥をコードで分析するBearerの能力は、DevSecOpsにとって価値があります。意図的な脆弱性はパスワードのログ記録を含み、Bearerはこれを高深刻度の発見（CWE-134）として検出しました。この失敗は品質ゲートとして機能し、安全でないコードの進行を防ぎました。修正は、ログから機密データを削除し、トレース可能性に必要な情報のみを残すことでした。修正を確認するために、新しいプッシュがパイプラインを再度トリガーし、今回は正常に完了しました。このプロセスは、SASTツールが開発ワークフロー内で脆弱性の修正を検出、ブロック、および検証できることを示しています。開発からクラウドデプロイまでの完全なフローにセキュリティチェックを組み込んだことが正常に実証されました。学んだ主な教訓は、早期のセキュリティ統合、自動化、機密データの保護、セキュリティゲートの使用、および開発プロセスへのセキュリティの埋め込みの重要性です。
Integración de DevSecOps con Bearer SAST y GitHub Actions: detección, bloqueo y remediación de vulnerabilidades dev.to
RSS Hunter RSS Hunter • 昨日

🤯 LLMの脆弱性を見つけたと思った。違った。その後、本当の脆弱性を見つけた。

著者は、LLMアプリケーションのセキュリティ問題を検証するために、サンドボックス化されたAIレッドチームラボを構築した経緯を詳述しています。このプロジェクトでは、Open WebUIにおけるクロスユーザーRAG認証チェーンや、モデルに依存しない脱獄テクニックを含む、確認された発見事項が得られました。予期せぬ結果としては、誤検知があり、これが認証情報検証に関する重要な方法論的教訓につながりました。このラボは、AIセキュリティに関する理論的な記事を読む以上の実践的な経験を得るために構築されました。ラボは、Ollamaを搭載したMac上でローカルモデルを実行し、Docker内にOpen WebUIと攻撃環境を配置し、すべてを隔離されたネットワーク上に構築しました。テスト方法論は、攻撃を進める前に攻撃者のIDとトークンを検証することを重視しました。著者は、合成ユーザーを使用してOpen WebUIのAPIをテストし、認証境界に焦点を当てました。当初、クロスユーザーファイルアクセス拒否の発見が確認され、アプリケーションのファイル所有権認識のベースラインが確立されました。しかし、その後報告されたクロスユーザーチャットアクセス脆弱性は、無効な攻撃者認証情報のために取り下げられました。この経験は、認証を評価する前に認証を確認することの重要性を強調しました。実際のアプリケーションの発見事項には、クロスユーザーRAG取り込みの欠陥が含まれており、権限のないユーザーが別のユーザーがアップロードしたドキュメントをRAGパイプラインを通じて処理し、そのコンテンツを取得することができました。これに続いてコレクションクエリレイヤーの障害が発生し、所有権を強制することなくコレクションコンテンツへの不正アクセスが可能になりました。これらの2つの発見事項を連鎖させることで、ドキュメント開示を達成することができました。さらに、RAGパイプラインから取得されたコンテンツが命令表面となり、モデルがドキュメント内に埋め込まれたディレクティブを実行する間接的なプロンプトインジェクションパスを示しました。これは、RAGセキュリティがプロンプトエンジニアリングだけでなく、取得ポリシー、所有権、コンテンツの信頼性を含むことを示唆しています。Garakによる自動スキャンでは、モデルの脱獄に対する抵抗力にばらつきが見られましたが、手動テストでは新しい攻撃ベクトルが明らかになりました。開発されたテクニックには、アシスタントの会話履歴を偽造して、モデルを、事前に存在する禁止された出力のように見えるものを継続するようにだますことが含まれていました。
🤯 I Thought I Found an LLM Vulnerability. I Was Wrong. Then I Found a Real One. dev.to
RSS Hunter RSS Hunter • 昨日

Cron、HTTPエンドポイント、キューワーカーによる毎晩のデータクリーンアップ

アウトバウンドWebフックの再試行のための自動クリーンアップジョブは、データが増加するにつれて予期せずリソースを大量に消費する可能性があります。単純な毎晩の削除ジョブでは、増加したボリュームに対応できない場合があります。これを管理するために、クリーンアップタスクの開始をトリガーするパブリックHTTPエンドポイントをcronジョブで起動する必要があります。大規模な削除の場合、このエンドポイントは、バッチ処理されたデータセットを処理する冪等なキューワーカーに作業を委任する必要があります。リトライレジャーは、一意のバッチキーを使用して条件付き削除を行うことで、繰り返し実行されるクリーンアップアクションが意図しない破壊的な操作を引き起こさないようにするために重要です。ワーカーは、重複メッセージを安全に処理できるように設計する必要があり、それらをノーオペレーションとして扱います。リトライは一般的であり、システムはそれらを堅牢に処理する必要があるため、この冪等性は不可欠です。Node.jsのcron HTTPエンドポイントは、冪等性キーを持つ単一のバッチを迅速に公開することで、重複作業から保護できます。実際の削除は、時間制限のあるcronジョブ自体ではなく、専用のワーカーによって処理されます。キューワーカーは意図的にシンプルに設計され、1つのバッチを処理し、レコードを削除し、トランザクションが成功した後にのみ完了を承認する必要があります。この設計により、リトライは無害になります。永続的な障害に対してデッドレターキューを実装することが推奨されており、問題のあるメッセージを検査および再処理する方法を提供します。冪等性メカニズムがさまざまな障害条件下で正しく機能することを確認するために、再起動シナリオのテストが重要です。バッチID、カウント、ステータスの詳細なログ記録により、オブザーバビリティが鍵となります。キューメッセージに大量のデータを配置しないでください。複雑で複数ステップのクリーンアッププロセスには、TemporalやAirflowなどのワークフローエンジンがより適しています。説明されているパターンは、より単純な単一パスの保持タスクに最適であり、公開されているエンドポイントが必要です。運用ループには、トリガー、エンキュー、クレーム、削除、記録、および承認が含まれます。未処理のバッチの経過時間やデッドレターキューの深さなどの主要なメトリックを定期的に監視することが不可欠です。保持ポリシーを変更する前に、ドライランクエリを実行することで、誤ったデータ損失に対する安全策が提供されます。このプロセス全体は、オフアワーでも理解および管理できるほどシンプルである必要があります。
Nightly Data Cleanup With Cron, HTTP Endpoints, and Queue Workers dev.to
RSS Hunter RSS Hunter • 昨日

オプションプロパティは未定義とは同じではありません

オプションのプロパティと未定義の値を持つプロパティは似ているように見えますが、根本的に異なります。オブジェクトがプロパティを欠いている場合、それにアクセスすると未定義が返されます。同様に、プロパティが存在してもその値が明示的に未定義である場合、それにアクセスしても未定義が返されます。しかし、in 演算子は根本的な違いを明らかにします。プロパティが存在しない場合は value in object は false になり、未定義の値を持つプロパティが存在する場合は true になります。TypeScript では、? で示されるオプションのプロパティは、そのプロパティがオブジェクトに存在しない可能性があることを意味します。この違いは、プロパティを省略することが「変更なし」を意味するが、明示的に未定義に設定することが異なる意図を示す API にとって重要です。exactOptionalPropertyTypes コンパイラオプションは、この違いを強制し、| undefined が明示的に型に追加されない限り、オプションのプロパティへの未定義の明示的な代入を許可しません。この正確な型付けは、プロパティの存在が意味的な意味を持つ設定オブジェクトや更新メカニズムに役立ちます。たとえば、更新関数は省略されたフィールドを無視するかもしれませんが、未定義に設定されたフィールドは異なる方法で処理する可能性があります。この違いを理解することは、堅牢な API 設計と正確なオブジェクト操作にとって不可欠です。
An Optional Property Isn't the Same as undefined dev.to
RSS Hunter RSS Hunter • 昨日

PostgreSQLデータベースにデータを保存するNOTE WEB APPをDocker化し、3つの異なる方法でAzureにデプロイする。

このブログ記事では、Azureでアプリケーションを安全かつ効率的にホストするための3つの方法を紹介します。最初の方法はAzure Container Instancesを利用するもので、ローカルでDockerイメージをビルドし、Docker Hubに公開してから、aci-notes.yaml設定ファイルを使用してAzureにデプロイします。この方法では、コンテナを直接デプロイできます。2番目のオプションである、マネージドPostgreSQLデータベースを備えたWeb App for Containersは、推奨されるパターンとして強調されています。Azureはバックアップ、パッチ適用、スケーリングなどの側面を管理し、アプリケーションは組み込み機能を持つコンテナ化されたWebアプリ向けに設計されたプラットフォーム上で実行されます。3番目の方法は、Docker Composeを備えた仮想マシンを使用するもので、ユーザーはサーバー環境を完全に制御でき、Dockerをインストールしてcomposeファイルを直接実行できます。このアプローチは、カスタムソフトウェアや特定のネットワーク構成が必要な場合に適しています。各方法には、Azureアカウント、Docker Hubアカウント、およびローカルにインストールされたDocker Desktopが必要です。アプリケーションをデプロイした後、不要な料金が発生しないようにリソースグループを削除してクリーンアップすることが重要です。この例では、アプリケーションをローカルでテストしてからAzureにデプロイする手順を示しています。
DOCKERIZING A NOTE WEB APP THAT SAVES ITS DATA IN A PostgreSQL Database AND DEPLOYING IT ON AZURE IN THREE (3) DIFFERENT WAYS. dev.to
CdXz5zHNQW_dYUAUayB5P.webp
RSS Hunter RSS Hunter • 昨日

React での useRef

useRef は、永続的なミュータブルな参照を作成するための React Hook です。変更されても再レンダリングを引き起こさない値を格納できます。一般的な用途は、DOM 要素への直接アクセスであり、入力フィールドへのフォーカスなどのアクションを可能にします。使用するには、React から useRef をインポートし、値で初期化します。参照オブジェクトには、格納された値または DOM ノードを保持する 'current' プロパティがあります。useState とは異なり、ref.current を変更してもコンポーネントは再レンダリングされません。useState は、UI に影響を与え、更新時に再レンダリングを引き起こす状態を管理するためのものです。対照的に、useRef は、タイマー ID や DOM 参照など、UI の更新なしにレンダリング間で永続する必要がある値に最適です。たとえば、useState 変数を変更すると再レンダリングがトリガーされますが、useRef.current を更新してもトリガーされません。DOM 要素にアクセスするには、'ref' 属性を使用して要素に ref をアタッチします。レンダリング後、ref.current は実際の DOM ノードを指し、直接操作できます。これは、テレビと直接やり取りするリモコンに似ています。useRef の鍵は、常に .current プロパティを介してその値にアクセスすることです。.current を変更すると値は変更されますが、React は自動的に再レンダリングしません。したがって、useRef は、再レンダリングを引き起こさずに「値を記憶する」および「参照にアクセスする」方法として理解するのが最適です。主な違いは、その動作にあります。useState の変更は再レンダリングと UI の更新につながりますが、useRef の変更はそうではありません。この違いを理解することは、React アプリケーションで useRef を効果的に使用するために不可欠です。
useRef in React dev.to
RSS Hunter RSS Hunter • 昨日

ケベック州のQSTは複合課税されない：多くのチェックアウトコードが間違える税務ルール

ほとんどのチェックアウト税システムでは、実行中の合計に対して税率を順次適用していますが、この方法はケベック州では正しくありません。この一般的なエラーにより、顧客はすぐに検出されずにわずかに過払いすることになります。ケベック州では5%のGSTと9.975%のQSTが課されますが、QSTはGSTを含まない価格に対して計算され、GSTを含んだ金額に対して計算されるわけではありません。これは、2つの税金が加算されるべきであり、複合されないことを意味します。ケベック州での100ドルの売上に対する税金を計算する単純なアプローチでは、誤ってGSTを含んだ価格にQSTが加算され、合計が115.47ドルになる可能性があります。しかし、正しい計算では合計は114.98ドルになります。100ドルの売上あたり0.49ドルの差、または収益の約0.5%は、売上量が多いほど大幅に蓄積されます。不正確な税金計算は、企業の記録と政府への納税額との間に不一致を引き起こす可能性があります。オンタリオ州、アルバータ州、ブリティッシュコロンビア州などの州では、税率を加算したり同じ基準に適用したりできる税制があるため、単純化された逐次税モデルはカナダのほとんどの地域で機能します。ケベック州の税制は、GSTを含まない基準に対してQSTを計算する必要があるという点でユニークです。より正確なモデルは、各税金コンポーネントが独自の税率と基準を持つ、コンポーネントごとの基準を区別します。正しい税金計算モデルを採用することで、カナダのすべての州および準州で正確な税金徴収が保証されます。また、ケベック州の非複合QSTやマニトバ州の子供服の上限など、特定の州の税規則も考慮されます。カナダに販売する企業は、近似値に頼るのではなく、正確な税金計算方法を実装することをお勧めします。支援が必要な場合は、TrueNorth APIのようなサービスがカナダ全土で正確な税金計算を提供します。
Quebec's QST does not compound: the tax rule most checkout code gets wrong dev.to
RSS Hunter RSS Hunter • 昨日

🇯🇵 KaiwaBuddy：友人のために、ローカル版のAI日本語会話パートナーを作りました

私は、日本語を学び始めた友人のために、ローカルAIの日本語会話パートナー「KaiwaBuddy」を開発しました。KaiwaBuddyが解決しようとしている根本的な課題は、学んだ語彙や文法を実際の会話で活用するのが難しいという点です。このアプリは、英語での意味の説明、初心者向けの文法解説、よくある間違いの訂正機能を提供します。また、自然な会話を再現するためのフォローアップの質問も提示します。 現在は、日本語能力試験N5レベルおよび『みんなの日本語』第1課の概念に焦点を当てています。「KaiwaBuddy」は、既知のパターンに対応する決定論的学習エンジンと、フォールバックAIモデルとしてのGemma 3 1Bを組み合わせたハイブリッドアプローチを採用しています。このハイブリッドシステムにより、中核となる概念について確実な指導を行うと同時に、自由度の高い対話も実現しています。 このプロジェクトは、Ollamaを介してローカルで実行可能なGemma 3 1Bモデルを採用し、プロプライエタリなクラウドAPIへの依存を回避することで、オープンイノベーションを重視している。ローカル推論は、プライバシーの確保や、AI体験をカスタマイズする際の開発者の自由度にとって極めて重要である。 オープンモデルを活用することで、開発者にとってAIシステムの仕組みがより理解しやすくなりました。KaiwaBuddyは、そのローカル推論機能をアピールするため、「Hacktoberfest Weekend Challenge」へエントリーされています。今回のプロジェクトを通じて得られた最大の学びは、信頼性の高いAIアプリケーションには、多くの場合、決定論的ロジックと、構造化されたフィードバックを提供するAIモデルが組み合わされているということです。
🇯🇵 KaiwaBuddy: I Built a Local AI Japanese Conversation Partner for My Friend dev.to
CdXz5zHNQW_Gpok0IsJii.webp
RSS Hunter RSS Hunter • 昨日

試験バディ：友人のOS試験のために私が作成したローカルGemma 3クイズツール

Exam Buddy は、個人のノートをインタラクティブなクイズに変換するように設計された、地域で運営されている AI 学習ツールです。このアプリケーションは、受動的な再読から、より効果的な学習方法であるアクティブリコールへの移行により、学習の向上を目指しています。ユーザーが提供した学習教材から直接クイズ問題を作成し、特定のコース内容への関連性を確保します。ユーザーが誤って回答した場合、Exam Buddy はスポーツ、料理、映画などの好みのテーマに合わせたパーソナライズされた説明を提供します。このツールは、多肢選択式、AI採点の記述式回答、混合形式を含む複数のクイズモードを提供します。より深い理解のためのフォローアップ質疑応答機能と、難しいトピックに焦点を当てるための「再試行」モードを組み込んでいます。Exam Buddy はまた、スコア履歴を追跡し、各クイズの後にレビューが必要な領域の概要を生成します。このアプリケーションの重要な側面は、Ollama と Gemma 3 4B モデルを利用した完全なオフライン操作です。これにより、ユーザーのノートとデータはローカルマシンに保持され、プライバシーとセキュリティが強化されます。開発には、一貫性のない JSON 出力や正確な採点のためのプロンプトエンジニアリングなど、小規模モデルの信頼性に関する課題の克服が含まれました。開発者はまた、回答のシャッフルやストリーミングデータ競合条件などの UI 関連の問題にも取り組みました。このプロジェクトは、パーソナライズされた教育ツールにおける、小規模でローカルで実行される AI モデルの実用性と強力さを示しています。Exam Buddy の設計は、AI 処理のために外部クラウド API に依存しないことで、ユーザーのプライバシーを優先しています。このプロジェクトは、適切な実装とガードレールを備えた控えめなローカルモデルで、洗練された AI タスクを効果的に処理できることを示しています。
Exam Buddy: A Local Gemma 3 Quiz Tool I Built for a Friend's OS Exam dev.to
CdXz5zHNQW_PiwEFkgUzD.webp
RSS Hunter RSS Hunter • 昨日

インド会社コンプライアンスチェックリスト：最初の週にあればよかったもの

インドでの会社設立は終わりではなく、継続的なコンプライアンス業務の始まりです。設立直後に、時間がかかる可能性があるため、速やかに当座預金口座を開設してください。PANとTANを取得し、アクセス可能な共有フォルダに整理してください。早期の申告を避けるために、GST登録がすぐに必要かどうかを判断してください。定期的な業務には、小規模な非公開有限会社であっても、取締役会を開催し議事録を維持することが含まれます。遅延損害金を累積させないために、会社登記官（ROC）への年次申告には注意を払ってください。請負業者やベンダーへの支払いに対する源泉徴収税（TDS）の準備をしてください。これは最初の支払いから適用されます。2週間前にリマインダーを設定した共有コンプライアンスカレンダーは、土壇場でのパニックを防ぐのに非常に役立ちました。単に申告を完了するだけでなく、各申告の目的を明確にする会計士を選ぶことは、財務計画に役立ちます。設立当初から株主間契約と株式記録を綿密に維持することは、特に資金調達前には、将来の複雑さを防ぎます。これらの実践が確立されれば、コンプライアンスは困難ではなく、管理可能で日常的なものになります。問題は、見えない締め切りと準備不足から生じます。コンプライアンスを、各項目に所有権と期日を割り当てる、通常の製品タスクとして捉えてください。
The India Company Compliance Checklist I Wish I Had in Week One dev.to
RSS Hunter RSS Hunter • 昨日

エージェントはコードベース全体でタスクを計画します

今週のスルーラインは、エージェントが単発タスクからマルチステップの自律実行へと移行し、オーケストレーションレイヤーの場所が変化することに焦点を当てています。Raycast AIは、OSレベルでの自律マルチステップタスクを可能にし、拡張機能の呼び出しを連鎖させ、失敗時には再試行を行います。利用量に応じた課金と、長時間実行プロジェクトのための永続的なコンテキストを備えています。SourcegraphのAgentic Batch Changesは、マルチリポジトリ移行を調整し、スクリプト作成を委任し、マージステータスを追跡し、成果に基づいた価格設定を行います。Ollamaの/v1/systemoneエンドポイントは、分類タスク専用の意思決定モデルを提供し、構造化された確率分布を返して、効率的なコンテンツルーティングとチケットトリアージを実現します。CloudflareのWorkers AIプラットフォームは、EuroLLMとApertusを追加しました。これらは、GDPRコンプライアンスに特化して設計された、多言語およびリソースの少ない言語をサポートするヨーロッパのオープンモデルです。DeepSeek V4 Flash Visionは、VercelのAI Gatewayで実験的に利用可能になり、レイテンシに敏感なアプリケーションのために、ビジョンとテキストの推論を統合し、キャッシングを行います。最後に、Gemini Omni 1.1 Flashは、シーン拡張、4Kアップスケーリング、およびより高速な360pプレビューにより、ビデオ生成を強化し、物語の連続性に関するより効率的なイテレーションを可能にします。
Agents Now Plan Tasks Across Your Codebase dev.to
RSS Hunter RSS Hunter • 昨日

SOC 2: サービス組織のための保証基準の理解

SaaSやクラウドプラットフォームのようなデジタルサービスが顧客データとの連携を深めるにつれて、組織はデータ保護に対する期待の高まりに直面しています。顧客やエンタープライズバイヤーは、独立して評価されたコントロールの信頼できる証拠を求めており、これがSOC 2の重要性を高めています。AICPAによって開発されたSOC 2は、選択された基準に基づいて、セキュリティ、可用性、処理の整合性、機密性、プライバシーに関連するコントロールを評価する証明フレームワークです。SOC 2は認証ではなく、組織のコントロールの審査に続く独立した証明レポートであることを理解することが重要です。この区別は、テクノロジー企業が保証やベンダーのデューデリジェンスに関する会話を行う上で不可欠です。エンタープライズ顧客は、コントロール、ガバナンス、リスク管理、独立した保証レポートを含むサービスプロバイダーのセキュリティプラクティスをますます評価しています。SOC 2レポートは、組織のコントロールが選択されたTrust Services Criteriaにどのように対応するかを示す構造化された方法を提供し、特にサービス全体でデータ保護を保証する必要があるSaaSおよびクラウドプロバイダーにとって価値があります。SOC 2の主な特徴は、独立した監査人の役割であり、内部チェックリストや自己申告のコンプライアンスステートメントとは異なり、定義された範囲内のコントロールの外部評価を提供します。組織は、特に顧客がコントロール運用の独立した証拠を要求する場合、SOC 2をより広範な保証戦略の一部として使用できます。SOC 2を追求する前に、組織は、単にセキュリティポリシーを持っているだけでなく、コントロールが適切に設計されており、審査期間中に効果的に運用されているかどうかを考慮することを理解する必要があります。これには、範囲内のシステムとサービス、関連するTrust Services Criteria、これらの基準に対応するコントロール、コントロールの運用を実証する証拠、割り当てられた責任、および継続的なコントロールパフォーマンス監視の明確な理解が必要です。この明確さは、顧客、監査人、その他の利害関係者とのより有意義な議論を促進します。競争の激しいテクノロジー市場のサービス組織にとって、セキュリティ保証は今や商業的な必須事項です。SOC 2は、独立した証明レポートを通じてデータ保護へのコミットメントを示す確立されたメカニズムを提供し、エンタープライズ顧客との信頼を構築します。SOC 2の評価範囲とレポートが認証と異なる点を理解することは、テクノロジー企業が保証体制を正確に伝えるのに役立ちます。
SOC 2: Understanding the Assurance Standard for Service Organizations dev.to
RSS Hunter RSS Hunter • 昨日

Laravel 用認証 — 2FA、パスキー、JWT セッションを備えたヘッドレスマルチガードログイン

Auth for Laravel は、API バックエンドの Laravel アプリケーションにおけるヘッドレスアカウント認証のために設計されたオープンソースパッケージで、カスタム実装によく見られるセキュリティ上の脆弱性に対処します。パスワード、マジックリンク、メールコード、パスキーの 4 つのサインイン方法と、強制登録を含む 2 要素認証のための堅牢なチャレンジエンジンを提供します。このパッケージは、ローテーションするリフレッシュトークンを備えた RS256 アクセストークン、詳細なデバイスセッション管理、登録、招待、メール検証、パスワードリセットなどの機能を提供します。ログインアクティビティログ、スロットリング、新規デバイスアラート、カスタマイズ可能なリスクルールフックが含まれています。Auth for Laravel は、異なるアカウントタイプ（ユーザー、クライアント、スタッフ）ごとに個別のガードをサポートしており、それぞれ独立したモデル、設定、エンドポイント、JWT オーディエンスを備えています。JSON エンドポイントはオプトインであり、ガードごとに設定可能で、すべての状態変更が拡張性のためにイベントをトリガーします。インストールには、いくつかの composer および artisan コマンドが含まれており、必要な設定とマイグレーションが公開され、トラブルシューティングのためのインストールチェッカーが用意されています。開発者は、ガードのモデルに特定の認証コントラクトとトレイトを実装させることで、パッケージを統合します。ログインすると、トークンペアまたは 2 要素認証のチャレンジが返され、TOTP コードやパスキーなどのさまざまな方法で完了できます。このパッケージは、HMAC ハッシュとして保存される使い捨てチャレンジを保証し、検証前にコード試行回数をカウントして、並列推測攻撃を防ぎます。ルート設定は柔軟で、各ガードのプレフィックス、名前、ミドルウェアのカスタマイズが可能で、ルートは対応する機能が有効な場合にのみアクティブになります。Auth for Laravel は、セキュリティのデフォルトを慎重に処理します。未登録のアドレスへのログイン試行は同じ応答を返し、パスワードハッシュの前にスロットリングが発生し、機密性の高いリンク/コードは使い捨てハッシュです。デフォルトでは、パスワード、メール、または 2 要素設定の変更は他のセッションを無効にし、ローテーションされたリフレッシュトークンの再利用はセッション終了とアラートにつながります。テストは実際のガードとトークンチェックをヒットするように設計されており、パッケージはテストでアカウントとして機能するためのヘルパーを提供します。ソーシャルログインと SSO は組み込まれていませんが、既存の SSO コールバックはパッケージの API を介してトークンを発行できます。このパッケージは、PHP ^8.4、Laravel 12 または 13、アトミックロックを備えたキャッシュストア、およびメールトランスポートが必要です。MIT ライセンスで、依存関係は主に Laravel、Symfony、およびその他の Roundly パッケージに限定されています。
Auth for Laravel — headless multi-guard login with 2FA, passkeys and JWT sessions dev.to
RSS Hunter RSS Hunter • 昨日

チュートリアル地獄に陥っています

私は小さなプロジェクトをいくつか作りましたが、何も学べなかったと思います。今でもゼロからプロジェクトを構築しようとすると、チュートリアルやAIを使わなければならないでしょう。自信をつけたいのですが、あらゆる段階でAIに頼ってしまいます。トライ（trie）とは何か、そして既存のユーザー名/Gmailのチェックにどのように使用されるのかを理解するのはエキサイティングですが、フルスタックプロジェクトを構築するのは daunting に感じます。プロジェクトを構築したいのですが、自分で構築できないように思え、これが私を非常にやる気をなくさせています。
Stuck in tutorial hell dev.to
RSS Hunter RSS Hunter • 昨日

君と一緒なら...

WITH YOUは、特に助けを求めることが困難だと感じている人々が困難な時期を乗り越えるためのAI搭載サポートコンパニオンです。セラピストとしてではなく、実際の人間によるサポートへの架け橋として開発され、AIへの依存ではなくつながりを促進します。このプラットフォームは、AIコンパニオン、パーソナライズされた対処ツール、個人の安全計画、信頼できる人々とつながるためのリソースを提供します。「ハードモーメント」体験中の圧倒感を軽減するため、そのインターフェースは穏やかでサポート的になるように設計されています。コアアーキテクチャはユーザーの安全を最優先し、重要な安全対策を一般的なAI会話から分離しています。オープンイノベーションにより、この非常に個人的なツールのテクノロジー、カスタマイズ、データフローに対するより大きな制御が可能になりました。WITH YOUは、対処、会話、安全計画、人間関係への簡単な道筋を提供することで、ユーザーが不確実な瞬間を乗り越えるのを支援します。システムの安全哲学は、実際のサポートを奨励し、危機時にユーザーを緊急または専門的なヘルプにつなげることを強調しています。最終的に、AIはサポートレイヤーとして機能し、ユーザーが人間関係に取って代わるのではなく、人間関係へのステップを踏み出すのを支援します。
With you... dev.to
RSS Hunter RSS Hunter • 昨日

"Unity、Godot、それとも自作エンジン？なぜ私のカードゲームは純粋なTypeScriptなのか" 公開日: 未定 タグ: gamedev, reactnative, typescript, showdev"

著者は、UnityやGodotのような既製のゲームエンジンを使用するのではなく、カスタムエンジンを作成してカードゲームアプリ「Decks」を構築することを決定しました。このアプローチが選択されたのは、単一のプラットフォームで多くのカードゲームをホストすることが目標であり、これは中央エンジンによって解釈されるJSONドキュメントとしてゲームを定義することによって達成されるためです。Godotでのプロトタイプは重すぎたり遅すぎたりすることが判明し、著者はカードゲームのレンダリングは基本的にシンプルであり、複雑な3Dエンジンを必要としないことに気づきました。プロジェクトの核心であるゲームルールは、レンダリングシステムから独立して簡単にテストできる必要がありました。選択されたスタックは、純粋なTypeScriptのゲームコアパッケージ、デザイントークン、そしてExpo、React Native、React Native Skiaで構築されたモバイルアプリで構成されています。主な利点は、ゲームコアがゼロ依存であるため、Node.jsとモバイルデバイスの両方で実行でき、シードによる広範なテストと再現可能なバグ修正を容易にすることです。ルールはデータとして定義されており、柔軟性を可能にし、evalに依存せずにヒントやAIボットのような機能をサポートします。プロジェクト全体でのTypeScriptの使用は、開発とテストを効率化します。React Nativeによって処理されるネイティブUI要素は、アクセシビリティと応答性を提供し、カードテーブル自体はSkiaを使用してレンダリングされます。カードの表面は動的に生成され、アプリのサイズを小さくすることに貢献しています。しかし、カスタムエンジンの構築には、ヒットテスト、フレームレートの最適化、ネイティブ依存関係の管理などの責任を含む、かなりのコストがかかります。ルール言語の汎用性は、冗長なデータ定義につながる可能性もあります。タッチジェスチャーやパフォーマンスの処理における課題にもかかわらず、著者はカスタムエンジンアプローチがその柔軟性と拡張性から最終的にやりがいのあるものだと感じました。今後の計画には、2人用ゲームやその他のソリティアバリエーションの追加が含まれます。
Unity, Godot, or my own engine? Why my card games are plain TypeScript" published: false tags: gamedev, reactnative, typescript, showdev dev.to
RSS Hunter RSS Hunter • 昨日

私たちのElectronレンダラーにはプリロードスクリプトがなく、127.0.0.1上の28個のHTTPエンドポイントと通信しています。

Electronアプリケーションは通常、プリロードスクリプトを使用して、レンダラープロセスに特権的なElectron APIへのアクセスを許可します。しかし、Notifioのメインウィンドウはこのアプローチを避け、ノード統合とコンテキスト分離を無効にしています。代わりに、レンダラーはメインプロセス内で実行されるローカルHTTPサーバーによって提供される標準的なWebページとして扱われます。このサーバーは、UIとアプリケーションの監視ロジック間の完全なインターフェースを形成する28のルートを公開しています。このアーキテクチャの選択は、いくつかの要因によって推進されました。第一に、レンダラーは実際にWebアプリとして機能し、標準的なWebテクノロジーで構築されており、Electronを認識していません。第二に、HTTPを使用することで、CRUD操作などのAPIインタラクションのための構造化された既存の語彙が提供され、カスタムIPCチャネルに必要な継続的な設計作業を回避できます。第三に、レンダラーが頻繁にリロードされるメインウィンドウの使い捨ての性質は、各ロード時にUIが簡単に状態を再構築できるHTTP APIから恩恵を受けます。ライブアップデートは、プッシュメカニズムではなく、これらのHTTPルートをポーリングすることによって処理されます。メインプロセス内にサーバーを配置することで、シリアライゼーションの境界や個別のプロセス管理の必要性がなくなり、その操作が簡素化されます。このローカルHTTP APIの認証は、ループバックインターフェースにのみバインドすることによって強制され、外部ネットワークアクセスを防ぎます。HTTPサーバーはクリーンな分離を提供しますが、ユーザーログインのための新しいブラウザウィンドウを開くなどの特定のElectron固有の機能は、小さなインプロセスブリッジを介して管理されます。このブリッジにより、ルートハンドラはサーバーモジュール自体がElectronをインポートすることなく、Electronに依存するタスクを委任できます。このHTTP中心の設計の唯一の例外はレコーダーウィンドウであり、プリロードスクリプトとIPCを使用します。これは、サードパーティのサイトをロードし、ページインタラクションを観察する必要があるため、プリロードスクリプトがサンドボックス化された環境でより適しているため必要です。違いは、レンダラーがアプリに
Our Electron renderer has no preload script, and it talks to 28 HTTP endpoints on 127.0.0.1 dev.to
RSS Hunter RSS Hunter • 昨日

Dev log #24 p2pスタックの強化：不安定なテストからWebSocketの修正まで

オープンソース開発者であるYash氏は、p2pネットワーキングとAIツーリングに注力しており、週ごとの貢献内容を詳述しました。彼は、minip2p Rustプロジェクトにおける不安定なテストに対処するために、クロックベースの待機をプログレス駆動ロジックに置き換えることに多くの時間を費やしました。これらのテストは、ビジーなランナーが原因でCIで失敗しており、開発者の生産性を妨げていました。Yash氏は、任意の時間間隔ではなく、実際のソケットアクティビティを待機するようにテストをリファクタリングしました。また、minip2pにおけるセキュリティ向上のため、AutoNATおよびIdentifyプロトコル全体でフレーム化された交換処理を統合しました。py-libp2pでは、Yash氏はWebSocketトランスポートがすべての失敗を汎用的にハンドシェイクタイムアウトとして報告するバグを修正しました。このバグはソケットリークも引き起こしていました。彼は、リソースリークを防ぐために、より正確なエラー報告と適切なソケットクローズを保証しました。さらに、セキュアなWebSocket接続のためのサーバー証明書検証を実装しました。Yash氏はTrakプロジェクトにも貢献し、テスト固有のフィクスチャを除外するようにインデクサーロジックを改善しました。彼は今週開設した5つのプルリクエストすべてを正常にマージしました。彼の週の大部分は、dotnet-libp2pリポジトリに対する15件のコードレビューに費やされました。これらのレビューは、C#実装を広範なlibp2p仕様と同期させることに焦点を当て、WindowsでのQUICトランスポート、Gossipsubの強化、セキュリティ改善、信頼性向上などの分野をカバーしました。このレビュー作業は、メンターシップと、複数のプログラミング言語にわたるエコシステムの整合性を確保することを強調しました。彼の今週の作業には、Rust、Python、C#が含まれ、新しいインフラストラクチャとリファクタリングされたハンドラーによるコード行数の純増をもたらしました。来週、Yash氏はminip2pのトランスポートレイヤーのパフォーマンスベンチマークに焦点を当て、Pythonおよび.NETのp2pスタックにおける進行中の開発を監視する予定です。
Dev log #24 Hardening the p2p stack: From flaky tests to WebSocket fixes dev.to
RSS Hunter RSS Hunter • 昨日

私たちのウィンドウには終了ボタンがなく、window-all-closed は空の関数です。

Notifioは、新しい賃貸物件のリスティングを電子メールでユーザーに即座に通知するように設計されたデスクトップアプリケーションです。そのコアバリューは、継続的な動作にあり、予期せず停止してはならないことを意味します。最後のウィンドウを閉じるとアプリが終了するというElectronのデフォルトの動作は、この要件と互換性がありません。したがって、Notifioはカスタムライフサイクルを実装し、メインウィンドウが閉じられた場合でもアプリケーションがシステムトレイでアクティブなままであることを保証します。ブールフラグは、ウィンドウを閉じたときにそれを非表示にするか、アプリケーションを終了するかを制御し、誤った終了を防ぎます。トレイアイコンは、アプリケーションを終了するための唯一のインターフェースとなり、実行中であることをユーザーに通知します。トレイアイコンをクリックすると、メインウィンドウの表示/非表示が切り替わります。非表示がデフォルトの状態です。アプリケーションはまた、重複したプロセスを防ぐために単一インスタンスロックを強制します。これにより、非効率的なポーリングと競合状態が発生します。実行中のアプリを再度起動しても、新しいインスタンスを開始するのではなく、非表示のウィンドウが前面に表示されるだけです。スリープモードは、Electron内のブラウザコンテキストがサスペンション後に無効になる可能性があるため、課題となります。Notifioは、システムがスリープする前にこれらのコンテキストを積極的に閉じ、復帰時に再初期化されることを保証します。外部ウェブサイトがNotifio自身のブラウザインスタンス内で開かれるのを防ぐために、ハンドラーを使用してすべての外部リンクをユーザーのデフォルトブラウザにリダイレクトします。これは賃貸サイトにとって重要です。認証されていないブラウジングはログインウォールにつながるためです。起動時の失敗の場合、パッケージ化されたアプリではより一般的ですが、Notifioはエラーの詳細とログファイルへのリンクを含む簡略化されたフォールバックウィンドウを表示します。このウィンドウは意図的に基本的であり、トラブルシューティングを支援するために不可欠な情報のみを含んでいます。キャッチされない例外と処理されない拒否は、包括的なエラー追跡を保証するためにログに記録されます。アプリケーションは、異なるオペレーティングシステム用に個別のビルドを提供し、トレイの動作とバックグラウンドポーリングをユーザーに明確に説明します。
Our window has no quit button, and window-all-closed is an empty function dev.to
RSS Hunter RSS Hunter • 昨日

テスト結果についてEd25519署名が実際に証明すること

Ed25519署名は、主に登録された秘密鍵の所有者が証拠記録に署名したことを証明します。この署名は署名行為を検証しますが、結果を承認した人物を認証するものではありません。Ranexはこれを利用して、レコードを承認する前にコミットされた公開鍵リングに対して証拠を検証します。このバインディングにより、証拠が特定の被験者とコマンドに紐付けられていることが保証されます。しかし、署名は報告された観測の真実性や正確性を保証するものではありません。承認者フィールドは現在認証されていない文字列であり、署名はレビュー担当者の身元を証明するものではありません。さらに、承認された依存関係であっても誤った結果を報告する可能性があり、署名はコードに現実を報告することを強制することはできません。署名能力と信頼のルートとの分離を維持するために、秘密署名鍵はリポジトリの外で安全に保管する必要があります。この分離により、リポジトリが侵害された場合でも、攻撃者が署名を偽造することを防ぎます。秘密鍵を保持するプロセスは、依然として盗難に対して脆弱です。認証されていない承認者の身元や、同じユーザーによる鍵の盗難といった既知のギャップが認識されています。これらのリスクは、公開鍵検証の強みと並行して管理する必要があります。追記専用レコードや、異なるプロパティに対する個別のゲートチェックなどの補完的な制御を積み重ねることで、全体的なセキュリティが向上します。署名が証明するものと証明しないものを正確に理解することは、防御可能な主張を行う上で不可欠です。
What Ed25519 Signing Actually Proves About a Test Result dev.to
RSS Hunter RSS Hunter • 昨日

エージェントは入れ替わります。ドクトリンこそが産物です。

最近のインシデントでは、システムセッションが不正なファイルアクセスを試みましたが、新しく実装されたフックによって正常にブロックされました。このフックは、まだ1週間も経っていませんが、はるかに古いシステムからの基本的なルールを強制します。著者は最近、メモリ、速度、およびエージェントループの統合を改善するために、マルチエージェントシステムから再構築されたエージェンティックOSに移行しました。再構築にもかかわらず、特に強制に関連する多くのルールは、繰り返し発生するAIエラーを修正するために、以前のシステムから再入力する必要がありました。詳細な監査により、古いシステムからの多くのルールが新しいシステムに欠落しているか、部分的にしか実装されていないことが明らかになりました。これらのルールは、AIモデルの動作はゆっくりと変化するため、以前のシステムの誤りから学んだ教訓を表しています。転送された主要なルールには、勧告ルールを拘束力のないものとして扱うこと、単一のオーケストレーターがアクションを呼び出すことを保証すること、および監査人の独立性を維持することが含まれます。スクリプト化されたロジックは、決定論的なタスクにおいてはLLMジャッジよりも優先されます。これらのルールは、学術的なAIコースではなく、実践的な製品開発に由来しており、測定可能な成果を優先しています。フックのような強制メカニズムは、まず失敗するテストを記述し、次にそれらをパスするためのコードを実装することによって開発されました。これにより、拒否メカニズムが徹底的にテストされ、期待どおりに機能することが保証されます。最終的な目標は自律的なエージェントループを達成することですが、現在のところ人間の監視が不可欠です。著者は、ルールの移植が完了しておらず、一部はまだテキストとしてのみ存在し、堅牢な強制が欠けていることを認めています。ルールの有効性は、その存在によって測定され、まだ証明された影響によって測定されていません。最終的には、個々のエージェントではなく、永続的なドクトリンが真の製品と見なされます。
Agents Get Replaced. The Doctrine Is the Product. dev.to
RSS Hunter RSS Hunter • 昨日

私のテキスト・トゥ・SQLエージェントにビジネス用語集を与えました。一方のバージョンは非常に役立ちましたが、もう一方のバージョンは全く役に立ちませんでした。

Text-to-SQLエージェントは、テーブル名やカラム名に直接一致しないビジネス用語の理解に苦労することが多く、クエリ結果の誤りを引き起こします。SchemaGate 1.2.0は、これらのエージェントの精度を向上させるためにビジネス用語を導入します。これらの用語は、同義語、データベースカラムへのマッピング、および関連するフィルター規則とともに明示的に定義できます。例えば、「収益」はステータスフィルターとともにbilling_invoice.total_netにマッピングできます。このプロセスは、エージェントが関連テーブルを特定し、特定のビジネス概念の意味を理解するのに役立ちます。用語は階層的な関係を持つこともでき、テーブルの包含重みに影響します。ビジネス用語は、dbt、Snowflake、またはCSVエクスポートなどのさまざまなソースからインポートでき、過去の質問とSQLのペアから学習することもできます。SchemaGateの主な機能はアクセス制御であり、エージェントがそれを見る前に、権限のないテーブルとカラムを非表示にします。データ漏洩を防ぐために、呼び出し元がすべての基盤となるテーブルとカラムにアクセスできない場合、ビジネス用語の意味行は省略されます。BIRDデータセットでの実験では、完全な用語集が提供された場合に10パーセントポイントの精度の有意な向上が示されましたが、他の質問から学習した用語は影響がありませんでした。Spiderの検索タスクでは、学習した用語がテーブルリコールの改善につながりました。本質的に、クエリ精度を向上させるためには、特に数式の理解において、主要なビジネス用語を手動で定義することが重要であり、学習した用語はテーブル発見により効果的です。プロンプトに用語を追加するには、ユーザー権限を慎重に考慮する必要があります。SchemaGateはオープンソースプロジェクトとして利用可能であり、複数のデータベースと統合オプションをサポートしています。
I gave my text-to-SQL agent a business glossary. One version helped a lot, one did nothing. dev.to
RSS Hunter RSS Hunter • 昨日

リサーチレポートの執筆エージェントは、文の前に出典が必要

研究報告書の品質は、流暢な文章だけでなく、情報源の品質にかかっています。最初のステップは、単一の質問と最大3つの副質問で研究課題を明確に定義することであり、これにより構造化されていない研究を防ぎます。検索を行う前に、情報源を一次、二次、三次カテゴリに階層化する必要があります。三次情報源は、主要な証拠として決して使用されません。主要な結論は、少なくとも2つの独立した情報源からの相互検証を必要とします。そうでない場合は、単一情報源の主張としてマークされます。すべての数値的事実は情報源を明記する必要があり、主要な事実は情報が古くなるのを防ぐために日付を付ける必要があります。これらのステップの後でのみ執筆プロセスが開始され、固定された構造を採用します。まず主要な結論を提示し、次に副質問に対応する本文セクションを「結論-証拠-情報源」の順序で記述します。報告書は、見つからなかったこと、単一情報源の主張、および無効化の条件を詳述した不確実性ステートメントで締めくくられます。推測は明確に特定する必要があり、断定的な言葉遣いを避ける必要があります。この構造化されたアプローチは、単一情報源への依存、推測を事実として提示すること、または日付のない情報を提供するといった一般的なアンチパターンに明確に対抗します。このフレームワークは、何が未知であるかについての透明性を優先し、報告書の信頼性を確保します。この方法論は、質問の定義から最終的な提示までの厳密性を強制することにより、研究の質を向上させます。
Research Reports Your Agent Writes Need Sources Before Sentences dev.to
RSS Hunter RSS Hunter • 昨日