DEV Community 日本語 - TheNote.app

DEV Community 日本語
フォロー

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

DEV Community dev.to

DEV Community 日本語 RSS thenote.app

RSS Hunter • 2024年8月23日

ノートのスレッド

クラウディウスが活動するための基盤を築く

この記事では、Claudiusという名前のClaudeベースのチャットボットのサーバーサイドセットアップについて詳述しており、そのアイデンティティシステム、サービス接続性、およびデプロイメントの現実性に焦点を当てています。アイデンティティシステムは、管理者、メンバー、ゲストなどのユーザーロールがサーバーでのみ決定され、クライアントによって操作されないことを保証します。これは、Auth.jsとGoogleプロバイダー、およびMongoDBアダプターを使用して実現され、ロールは管理者メール、許可リスト、またはデフォルトのゲストに基づいて解決されます。解決されたロールは、アプリケーション内での効率的なアクセス用にJWTに埋め込まれます。プロビジョニングプロセスでは、ユーザー固有のフィールドのデフォルト値も設定され、サインインごとにロールが再計算されることが保証されます。接続性は、MongoDB Atlasをpingするヘルスチェックルートを通じて検証され、オプションでBedrockのClaude Haikuモデルに小さな呼び出しを行います。このプローブは、アプリケーションがAIバックエンドと正常に対話できることを確認し、トークン使用量メタデータが返されます。アプリケーションはまた、それぞれの推論プロファイルIDと価格情報を持つAIモデルのカタログを定義します。環境変数は、各開発フェーズで必要に応じて反復的に検証され、現在のセットには認証、データベース、およびBedrockの認証情報が含まれます。このセットアップフェーズ中に、いくつかの重要な問題、または「落とし穴」が発生し、解決されました。Auth.jsアダプターとアプリケーションのデータベースヘルパーの両方が正しいデータベースをターゲットにしていることを確認することが重要な問題でした。接続文字列にデータベースパスが欠落していると、アクセスできない「test」データベースにデフォルト設定されていました。接続プーリングは、MongoDBクライアントをグローバルにキャッシュすることによって最適化されました。モノレポ内での依存関係管理は、ランタイム依存関係に細心の注意を払い、デプロイメント用のオプション依存関係にプラットフォーム固有のバイナリを含めることを必要としました。ユーザーアイデンティティとサービスインタラクションの基盤は確立されましたが、コアチャット機能はまだ実装されていません。

Building the foundation Claudius runs on dev.to

RSS Hunter • 今日

ルーチンをアシスタントに変える：小さなAIヘルパーの実践ガイド

AIは魔法のランプの精ではなく、関数として扱うべきです。AIを一度きりの問い合わせのための検索ボックスのように扱うのは構いませんが、反復的なタスクには非効率的です。有用なAIアシスタントを構築するには、単一で、狭く、反復的で、退屈で、検証可能なタスクから始めます。プロンプトは、明確な入力と構造化された出力を備えた関数シグネチャとして考えます。信頼性の高い要約を確保するために、AIにソース資料から裏付けとなる文を引用させるように強制します。データクリーニングでは、インプレース変更を避け、代わりにAIにレビュー用のマッピングを出力させます。極めて重要なのは、少数の「ゴールデンセット」の正しい例を作成することによってAIの出力を検証することです。コードのアサーションやスポットチェックのような安価なチェックを実装して、早期にエラーを検出します。複数のステップやツール呼び出しを実際に伴うタスクに対してのみ、エージェントを導入します。最後に、成功したAIの出力をプロンプトにフィードバックして、予測可能で信頼性の高いアシスタントを作成することによって反復します。

Turn Your Routine Into an Assistant: A Practical Guide to Small AI Helpers dev.to

RSS Hunter • 今日

DeepSeek V4 Flash API コスト：思考モードは厳密なJSONを破損させる

DeepSeek V4 Flashの0731ビルドには、思考が有効になっている場合に構造化されたJSON出力の整数フィールドが破損する可能性のある欠陥があります。この問題は、厳密なJSONスキーマで特に発生し、テスト実行の大部分で観察されました。ただし、思考を無効にすると破損が解消され、トークン使用量が大幅に削減されます。0731の再学習では、思考が無効な場合のマルチステップタスクのパフォーマンス低下も顕著になりました。モデルには1,024トーク

DeepSeek V4 Flash API Cost: Thinking Mode Corrupts Strict JSON dev.to

RSS Hunter • 今日

MCPの解説：AIエージェントを支えるプロトコル

現代のAIシステムは、外部ツール、データベース、サービスと連携することで複雑なタスクを実行できるようになり、AIエージェントが登場しています。各アプリケーションとAPIがその能力を独自に公開するため、AIプラットフォームごとにカスタム統合が必要となり、大きな課題が生じています。Model Context Protocol (MCP) は、AIモデルが外部リソースを発見、理解、使用するための標準的な方法を提供することで、この課題に対処します。MCPは共通言語として機能し、AIクライアントがツールを発見し、その機能を理解し、構造化された入力を受け取り、実行し、構造化された結果を得ることができるようにします。このプロトコルは、GitHub、Slack、データベースとの連携など、テキスト生成以外の操作を実行する必要があるAIエージェントにとって不可欠です。MCPは、MCPクライアント（AIアプリケーション）、MCPサーバー（能力を公開）、そしてツール自体から構成されます。プロセスは、AIクライアントがサーバーに接続し、利用可能なツールを発見し、ユーザーのリクエストに基づいて選択されたツールを呼び出し、構造化された結果を受け取ることを含みます。開発者にとって、MCPは標準化された統合、より良い保守性、そしてツールの発見性の向上を提供します。生のAPIエンドポイントを公開する従来のAPIとは異なり、MCPはAIモデルがより高レベルで理解できる能力を記述します。関数呼び出しはAIがアプリケーション内の事前定義された関数を呼び出すことを可能にしますが、MCPは異なるAIクライアント間で能力を共有するためのより広範なエコシステムを提供します。セキュリティは最優先事項であり、MCPサーバーには堅牢な認証、認可、検証が必要です。MCPは、コーディングアシスタント、エンタープライズ検索、DevOpsワークフローなど、さまざまなユースケースに適しており、既存のAPIを置き換えるのではなく補完します。

MCP Explained: The Protocol Powering AI Agents dev.to

RSS Hunter • 今日

Show DEV: .NETとCaddyでスマートフォン仕様APIを構築する

モバイルハードウェア仕様APIの統合は、不完全で正規化されていないデータのために、歴史的に困難でした。画面リフレッシュレートやCPUクロックスピードのような仕様の生の文字列形式は、プログラミングロジックにとって扱いにくいものでした。この問題に対処するため、Device Specs APIが開発され、乱雑で構造化されていないデータに対するソリューションを提供します。新しいAPIは、解析の負担をバックエンドに移行し、クリーンで、強く型付けされ、正規化されたJSONデータを提供します。これは、数値は実際の数値であり、ブール値はブール値であり、複雑な仕様は構造化された配列として提示されることを意味します。例えば、バッテリー容量は整数であり、NFCの利用可能性はテキストではなく、明確なブール値です。APIはまた、ディープフィルタリング機能を備えており、ユーザーはURLパラメータを介して非常に具体的なハードウェアパラメータをクエリできます。これにより、バッテリー容量が5000mAh以上、RAMが少なくとも8GB、SamsungまたはXiaomi製で、モデル名に「pro」が含まれるデバイスを見つけるといった複雑な検索が可能になります。バックエンドはASP.NET Core Web APIで構築され、フロントエンドはBlazor WebAssembly/Serverハイブリッドを利用しています。Caddyは、自動HTTPS証明書管理とクリーンな構成のために、リバースプロキシおよびSSLハンドラーとして使用されます。APIのドキュメントとインタラクティブなテストはオンラインで利用可能であり、ユーザーは探索してフィードバックを提供できます。

Show DEV: Building Smartphone Specs API with .NET and Caddy dev.to

RSS Hunter • 今日

公開された秘密への対応 - SREのインシデント対応プレイブック

インシデント対応プレイブックは、危機発生時の混乱を管理し最小限に抑えるための構造化されたプロセスを提供します。プレイブックを作成する前に、その目標、範囲、および役割を定義し、明確なコミュニケーションと文書化チャネルが確立されていることを確認します。テストとトレーニングは、重要な準備段階です。特定のインシデントタイプには、調整されたプレイブックが必要です。秘密情報の漏洩は、システム障害と比較して、検出に特有の課題をもたらします。システム障害とは異なり、秘密情報の漏洩はすぐに明白なアラートをトリガーしない可能性があり、APIの使用、クラウドアクティビティ、およびデータベースクエリの特別な監視が必要になります。秘密情報の漏洩の調査には、その完全な範囲と影響を判断することが含まれますが、これは広範囲に及ぶ可能性があります。秘密情報の漏洩の防止は、セキュアな秘密情報の管理、最小権限の原則、コードスキャン、および継続的な教育に依存します。インシデント発生中、封じ込めには、影響範囲を評価した後、システムを隔離したり、アカウントを無効にしたり、侵害された秘密情報を無効にしたりすることが含まれます。自動化されたプロセスとツールは、秘密情報のローテーションとシステム更新を迅速化できます。本番環境への秘密情報のデプロイには、ダウンタイムを最小限に抑えるために、ブルー/グリーンデプロイメントやカナリアリリースのような慎重な戦略が必要です。インシデント後の分析は、責任を追及することなく、根本原因とシステム的な弱点を特定するために不可欠です。この分析は、セキュリティプラクティスの改善やプレイブックの更新など、将来のインシデントを防ぐための積極的な措置に情報を提供する必要があります。

Responding to Exposed Secrets - An SRE's Incident Response Playbook dev.to

RSS Hunter • 今日

🚀 Hermes AgentとRemotionでエンドツーエンドのAI動画制作パイプラインを構築する

このチュートリアルでは、Hermes AgentとRemotionを使用してAI搭載のビデオ制作パイプラインを構築し、ショートフォームの縦型ビデオを作成する方法を紹介します。自動化されたワークフローは、トレンドトピックのリサーチから最終的な洗練されたビデオのレンダリングまで、タスクを自動化します。まず、Hermes Agentがバイラルトピックをリサーチし、ジェイムズ・ウェッブ宇宙望遠鏡による星間彗星でのメタン発見を例として選択します。次に、Agentはナレーション、ストーリーボード、Remotionキューを含む詳細な制作スクリプトを生成します。シーンごとの制作計画が作成され、カラーパレット、アニメーションスタイル、編集の方向性が概説されます。ワークフローは、各シーンのAIアートワークを自動生成し、Remotionを使用してモーショングラフィックスビデオを構築し、シーンを繰り返し改善します。自然なAIボイスオーバーが追加され、洗練された雰囲気のためにBGMと効果音が続きます。Whisperを使用して、読みやすさと視覚的な魅力を向上させるために、アニメーション化された単語レベルのキャプションが生成されます。この包括的なアプローチにより、クリエイターは手動編集ではなく、ストーリーテリングに集中できます。このワークフローは、教育コンテンツ、マーケティングビデオ、ソーシャルメディアなどのさまざまなプロジェクトに最適です。開発者や技術系クリエイターにとって、従来のビデオエディターよりも優れた柔軟性を提供します。

🚀 Build an End-to-End AI Video Production Pipeline with Hermes Agent and Remotion dev.to

RSS Hunter • 今日

OpenAI GPT-Live、ChatGPTに大規模な継続的音声会話をもたらす

OpenAIは、ChatGPT向けの新しい世代の音声モデルであるGPT-Liveをローンチしました。これは、より流暢でリアルタイムな会話のために設計されています。その全二重アーキテクチャにより、システムは同時に聞き取りと発話が可能になり、自然なターンテーキング、相槌、割り込みを実現します。このアプローチは、要求の厳しいインタラクションにおける音声インターフェースの一般的な課題に対処します。GPT-Liveは、リアルタイムの会話レイヤーを、より重いタスクを処理するモデルから分離し、混乱を避けます。

OpenAI GPT-Live Brings Continuous Voice Conversations to ChatGPT at Scale dev.to

RSS Hunter • 今日

AI を使ってコードのデバッグを正気で乗り切る方法

AIによる複雑な問題のデバッグは、曖昧な説明ではなく、具体的で明確な証拠を提供した場合に最も効果的です。アプリケーションのクラッシュに関する曖昧な質問は、ほとんど役に立たない一般的なアドバイスしか得られません。問題を描写する代わりに、AIに実際のスタックトレース、関連するコードスニペット、最近のgitコミットを見せてください。バグを一貫して引き起こす、小さくて再現可能なケースを作成することはさらに良い方法です。このコンテキストを提供したら、観察している特定の動作について的を絞った質問をすることができます。AIは曖昧さを苦手としますが、正確なコード実行の説明に長けています。例えば、メモリリークのデバッグでは、ヒープスナップショットと特定のコードスニペットを提供することで、マップエントリのクリーンアップ漏れを迅速に特定することができました。ヒープスナップショットのためのChrome DevTools、プロファイリングのためのclinic.js、そしてNodeのinspect機能のようなツールは、この証拠を収集する上で非常に役立ちます。git diffとログを見せることは、問題を引き起こしている可能性のある最近の変更を特定するのに役立ちます。重要なのは、AIを自身のデバッグプロセスを置き換えるものではなく、理解を加速するためのツールとして使用することです。AIを、提供された証拠を分析するのに役立つ、疲れを知らない新鮮な目のペアと考えてください。

Using AI to Debug Code Without Losing Your Mind dev.to

RSS Hunter • 今日

カナダPR準備中にPTEコアプラットフォームを構築しました

カナダの永住権（PR）には競争力のあるCRSスコアが不可欠であり、語学力はその重要な要素です。当初、IELTSとCELPIPが主な英語テストでしたが、高得点を獲得するための明確なガイダンスが不足していました。2024年にPTE Coreが導入され、機械採点の代替手段が提供され、測定可能な練習を好む人々にとって魅力的になりました。しかし、PTE Coreの準備状況は未発達であり、ほとんどのリソースはPTE Academic向けで、移民候補者には完全に関連性がありませんでした。このギャップを認識し、創設者はカナダ移民希望者専用のプラットフォームとコミュニティであるPhraselを立ち上げました。Phraselは、一般的な英語試験とは異なり、移民のための独自の目標とスコア閾値を理解し、PTE Coreに焦点を当てています。このプラットフォームは、改善すべき具体的な領域を特定することを目指し、圧倒的な量の練習資料よりも明確さを優先しています。その中核的な哲学は、学習者は単なる問題数や固定的なテンプレートではなく、次のステップを導くための診断フィードバックを必要としているということです。Phraselは、CLB変換やCRSポイントなど、カナダPR固有のツールを練習ワークフローに直接統合しています。このプラットフォームは、4つのスキルすべてにわたる試験形式の練習を提供し、スピーキングとライティングのAI採点により詳細なフィードバックを提供します。弱点と強みを特定し、集中的な学習を可能にするために設計された、フルレングスの模擬テストが利用可能です。Phraselは、本物のスキル開発が持続的なスコアにつながると信じ、近道や暗記したテンプレートに頼るのではなく、実際の言語能力の構築を重視しています。AI採点は、貴重なトレーニングシグナルですが、公式のPearsonスコアの保証された予測ではなく、洗練ツールとして正直に提示されています。Phraselの開発スタックには、Next.js、React、Vite、Flask、および採点用のAIサービスが含まれています。創設者は、明確なフィードバックと、どのスキルが進行を妨げているかを理解することが、効果的な準備の鍵であると信じています。

I Built a PTE Core Platform While Preparing for Canada PR dev.to

RSS Hunter • 今日

開発者のためのネットワーク基礎：始めるために必要な唯一の概念

このガイドでは、開発者、Linuxユーザー、およびサイバーセキュリティの初心者向けに、ネットワークの基礎知識を紹介します。ネットワークは、デバイス間の通信やデータ共有を可能にするもので、ローカル接続にはMACアドレスが、インターネットのような広域ネットワークにはIPアドレスが使用されます。DHCPサーバーはIPアドレスを自動的に割り当てることで、ネットワーク管理を簡素化します。サブネットは大規模なネットワークを分割し、ルーターはデフォルトゲートウェイを使用して外部トラフィックをルーティングしながら、異なるネットワークを接続します。DNSはドメイン名をIPアドレスに変換するもので、再帰サーバーがこれらのアドレスを検索し、権威サーバーが公式のレコードを提供します。TCPは信頼性が高く順序通りのデータ転送を保証するため、ウェブブラウジングやファイル転送に最適ですが、一方、UDPはライブストリーミングやゲームなどのアプリケーションにおいて速度を優先します。ポートは、ネットワークトラフィックをデバイス上の特定のサービスやアプリケーションへと誘導します。ARPはIPアドレスをMACアドレスにマッピングし、ローカルネットワーク内での通信を円滑にします。トンネリングは、異なるネットワーク間を転送するためにパケットをカプセル化します。OSIモデルは、物理的な伝送からアプリケーション間の相互作用に至るまでの7つのネットワーク通信層を定義し、標準化されたフレームワークを提供します。 Web通信用のHTTP/HTTPS、リアルタイム接続用のWebSocket、ファイル転送用のFTPなど、さまざまなネットワークプロトコルがデータの交換方法を規定しています。これらの基礎を習得することは、現代のコンピューティングを理解し、広大なネットワーク分野において継続的に学習していく上で不可欠です。

Networking Fundamentals for Developers: The Only Concepts You Need to Get Started dev.to

RSS Hunter • 今日

pgvector vs Pinecone vs Qdrant: 専用ベクトルデータベースはいつ本当に価値があるのか？

既存のPostgresセットアップで数百万程度のベクトルを扱う場合、pgvectorは理想的な最初の選択肢であり、フィルタリング、結合、トランザクションを1か所にまとめることで運用を簡素化します。Postgres拡張として機能し、ベクトル列型とANNインデックスを追加し、オープンソースです。PineconeやQdrantのような専用ベクトルデータベースは、Postgresではリコール、高いクエリボリューム、水平スケーリング、または運用の引き継ぎが困難になった場合に必要となります。Pineconeは完全に管理されたクローズドソースのクラウドサービスであり、運用上の負担はゼロですが、ベンダーロックインと従量課金が発生します。QdrantはRust製のオープンソースベクトルデータベースであり、セルフホスティングまたはクラウドオプションを提供し、強力なメタデータフィルタリングと量子化を備えています。pgvectorは運用上のシンプルさとクエリの表現力に優れていますが、高いボリュームではトランザクションワークロードと競合して負荷がかかる可能性があります。専用ベクトルDBへの切り替えの決定は、通常、スケーリング、クエリ同時実行性の分離、または検索の運用責任をオフロードしたいという願望から生じます。専用ベクトルデータベースの真のコストは、移行自体ではなく、アーキテクチャ内の追加システムを管理する継続的な運用上の複雑さです。したがって、pgvectorから始め、管理のシンプルさのためにPineconeに移行するか、制御可能な専用のオープンソースエンジンとしてQdrantを選択してください。常に独自のデータでベンチマークを行い、ワークロード固有の十分な情報に基づいた決定を下してください。

pgvector vs Pinecone vs Qdrant: When Is a Dedicated Vector Database Actually Worth It? dev.to

RSS Hunter • 今日

「すべてをインポスター症候群と呼ぶのをやめよう：「ただもっと頑張れ」という神話」

著者は、インポスター症候群と、自己不信を引き起こす真の戦略的問題とを区別している。インポスター症候群は、AIの記事や会議の招待に関する個人的な経験で示されるように、客観的な成果にもかかわらず、詐欺師のように感じることに関係する。これらの場合、脳は認識された欠点に対して説明を考案する。しかし、すべての不十分さの感覚がインポスター症候群に由来するわけではない。例えば、ランニングが下手であることは、インポスター症候群があることを意味するのではなく、単に才能の欠如や不適切なトレーニング方法を意味する可能性がある。戦略的な問題、自信に関連しない問題に対して、「もっと努力する」とか「続ける」といったアドバイスをすることは、逆効果になりうる。工学的なアプローチは、自信を高めることにのみ焦点を当てるのではなく、自身の戦略を批判的に分析することを示唆している。これには、投資した時間が成果を生んでいるかどうかを問い、代替戦略を検討することが含まれる。真のインポスター症候群と、欠陥のあるアプローチを示唆する疑念とを区別することが重要である。時には、忍耐が答えであるが、他の時には、戦略的な変更が必要である。この区別を学ぶことは、個人的な成長における困難だが重要な部分である。

Stop Calling Everything Impostor Syndrome: The Myth of "Just Push Harder" dev.to

RSS Hunter • 今日

🚦 イベントリスナー、プロセッサ、および DbContext — 落とし穴とベストプラクティス - .NET 10

.NET における依存性注入では、サービスのリフトタイムを慎重に考慮する必要があります。シングルトンサービス（例: EventListener）が、スコープ付きサービス（例: DbContext）に直接依存する場合に、一般的な落とし穴が生じます。スコープ付き DbContext をシングルトンの EventProcessor に注入すると、同じ DbContext インスタンスが無限に再利用されることになります。この古い DbContext は、データが最新でない、競合エラーなどの問題を引き起こす可能性があります。推奨されるプラクティスは、EventListener をシングルトンとして維持しつつ、IServiceScopeFactory を注入することです。このファクトリにより、シングルトンの EventProcessor は、必要に応じて新しいスコープを作成し、新しい DbContext を取得できます。あるいは、EventProcessor 自体をスコープ付きリフトタイムで登録することもできます。このシナリオでは、シングルトンの EventListener は IServiceScopeFactory を使用してスコープを作成し、処理するイベントごとにスコープ付き EventProcessor を解決します。最終的に、コアとなる原則は、スコープ付き依存関係をシングルトンに直接注入することを避けることです。シングルトンサービスがスコープ付きサービスへのアクセスを必要とする場合は、IServiceScopeFactory を介して動的に取得する必要があります。同様に、サービスが「スコープ付き」のような特定のライフタイムを必要とする場合は、そのライフタイムで登録され、適切に解決される必要があります。これらのライフタイム管理戦略を理解することで、依存性注入に伴う一般的なエラーを防ぐことができます。

🚦 Event Listeners, Processors, and DbContext — Pitfalls & Best Practices - .NET 10 dev.to

RSS Hunter • 今日

決済ベンダーが買収された場合、あなたのインテグレーションはどうなるか

フィンテックM&Aは英国のテクノロジーシーンで頻繁に発生しており、エンジニアリングリスクとして考慮されるべきです。最近の例は、買収が製品の軌道を変え、統合の課題を生み出す可能性があることを浮き彫りにしています。VisaによるPlaidの買収は、エンタープライズタームへの注力をシフトさせ、中小企業にとってオンボーディングをより困難にしました。TrueLayerのAPI移行は、新しい要件に適応するために開発者に多大な労力を必要としました。GoCardlessによるNordigenの買収は、無料ティアの縮小につながり、一部の開発者にテクノロジースタックの再評価を余儀なくさせました。サードパーティの決済APIに依存するあらゆるビジネスが、買収や価格変動による変更に遭遇する可能性は統計的に高いです。このリスクを軽減するために、開発者はベンダーSDKの周りに薄い抽象化レイヤーを構築し、コアビジネスロジックを分離すべきです。独自のデータベースに正規化された決済状態を保存することは、ベンダー変更時のデータ整合性を維持するために不可欠です。無料ティアの縮小やサポートの遅延といった早期の兆候を観察することは、差し迫ったプラットフォームシフトの兆候となり得ます。ロードマップに投機的な移行時間を予算計上することで、予期しない変更への迅速な適応が可能になります。最終的に、ベンダーAPIのビジネスリスクを認識し、アーキテクチャ上の距離を置くことが、レジリエンスのために不可欠です。

What Happens to Your Integration When Your Payments Vendor Gets Acquired dev.to

RSS Hunter • 今日

ツールハブの作り方：サブセカンドを維持する138ツール搭載の静的PWA

著者は最近、クリーンさ、プライバシー、そしてゼロブロートを優先した138個のインブラウザWebユーティリティスイートであるToolHubの構築に関する完全なアーキテクチャレトロスペクティブを発表しました。このサイトは、サブセカンドの高速性と完全なオフライン機能を備えるように設計されており、これらの機能を可能にする主要なエンジニアリングのトレードオフと技術的な決定がなされています。主要なアーキテクチャのハイライトの1つは、Next.js Static Exportの使用であり、これによりエッジCDNでホストされる100%静的なエクスポートモデルが可能になり、サーバーメンテナンスゼロと超低速な初回バイト時間が実現します。このアプローチは無限のスケーリングも可能にしますが、すべての動的コンテンツがブラウザメモリ内で厳密にクライアントサイドで実行される必要があります。著者はまた、カスタムService Workerキャッシング戦略を実装しました。これには、静的アセットのstale-while-revalidateと、HTMLドキュメントナビゲーションのnetwork-firstが含まれており、キャッシュされた後はすべてのツールで完全なオフライン機能が保証されます。さらに、著者はプログラムによるSEOエンジンを開発しました。これは、完全なJSON-LD構造化データと自動化された内部リンクメッシュを備えた静的なツールページを生成し、すべてビルド時に静的なHTMLに組み込まれます。このサイトはまた、ゼロCLS広告戦略を備えています。これは、広告ユニットがロードされる前に明示的な固定高さのレイアウトスロットを予約することで、レイアウトシフトを防ぎます。著者はToolHubサイトをユーザーが試せるように公開しており、ブログでエンジニアリングの完全なディープダイブを発表しました。そこでは、サイト構築における技術的な決定とトレードオフに関する詳細を共有しています。著者はユーザーからのフィードバックと提案を求めており、アーキテクチャに関する意見や新しいツールのアイデアを聞くことに前向きです。全体として、ToolHubプロジェクトは、高速でオフライン対応、プライバシーファーストのWebアプリケーションを構築するための革新的な技術的アプローチを幅広く示しています。

How I Built ToolHub: A 138-Tool Static PWA That Stays Sub-Second dev.to

RSS Hunter • 今日

ほとんどのシステムデザイン面接は、図に焦点を当てています。実際のシステムは、トレードオフによって失敗します。

著者は、システム設計の議論において、図に対する過度の強調と、アーキテクチャ上の意思決定を推進する重要なトレードオフへの焦点の欠如という一般的な問題に気づいています。彼らは、一貫性と可用性のバランス、モノリスとマイクロサービスのメリットの比較といった、いくつかの根本的な問いを投げかけています。著者はまた、イベント駆動型アーキテクチャの複雑さと、スケーラビリティ向上のための許容可能なレイテンシについても言及しています。もう一つの重要な懸念事項は、キャッシュ戦略を賢明に回避または実装する時期です。著者は、これらの決定は、視覚的な表現そのものよりも、本番システムに大きく影響すると主張しています。彼らは最近、実践的な例を用いて、これらの現実世界のアーキテクチャ上のトレードオフを掘り下げた記事を発表しました。著者は、経験豊富なアーキテクトやバックエンドエンジニアからの洞察に対するフィードバックを積極的に求めています。彼らは特に、反対意見や代替的な視点を聞くことに興味があります。コミュニティにとっての核心的な問いは、分散システムの設計に対する彼らのアプローチを深く変えた、単一のアーキテクチャ上のトレードオフを中心に展開しています。

Most system design interviews focus on diagrams. Real systems fail because of trade-offs. dev.to

RSS Hunter • 今日

編集が失敗しても何も投げられません

PIIの効果的な匿名化には、モデルがサイレントに失敗することが多いため、慎重なパイプライン設計が必要です。モデルを関与させる前にルールベースのパスで初期化すると、モデルを混乱させる不自然なトークンパターンが作成され、結果が悪化する可能性があります。代わりに、元のテキストに対してセマンティックパスと構造パスの両方を独立して実行し、結果を照合します。その際、構造的なオフセットが有効であることを確認し、構造パスからの低信頼度の日付検出を除外します。エンタープライズドキュメントのマークアップは、モデルの出力を破損させる可能性があります。プレーンテキストを抽出し、匿名化してから元の構造に再挿入することで、リコールを大幅に改善できます。匿名化を拒否するモデルに対して拒否検出を実装し、構造パスにフォールバックしてこれらのインスタンスをログに記録し、プロンプト調整に役立てます。極めて重要なのは、匿名化呼び出しがタイムアウトした場合にデータ漏洩を防ぐために、システムを「フェイルオープン」ではなく「フェイルクローズ」するように設計することです。構造パスを低下したパスとして扱い、そのようなイベントをアラートします。モデルIDとプロンプトハッシュを各匿名化とともにログに記録してプロンプトをバージョン管理し、時間の経過に伴うパフォーマンスの変化を追跡します。匿名化されたテキストの共参照については、汎用タグの代わりに番号付きプレースホルダーを使用しますが、結果のマッピングテーブルもPIIであり、適切なセキュリティが必要であることに注意してください。または、可逆性が不要な場合は破棄してください。精度を測定するには、PIIを含まないドキュメントのカナリアセットを作成し、すべての変更とともに実行します。このセットでの匿名化は、リグレッションを示します。スケーリング時には、呼び出し元のレイテンシ、レジデンシー、言語などの制約に基づいて異なるモデルにリクエストをルーティングするルーティングインターフェイスを構築することで、単一のモデルを超えて拡張します。構造パスは常にユニバーサルフォールバックとして機能します。1,024トークンを超えるプロンプトには慎重なキャッシング戦略を実装して、コストとスループットを最適化します。推奨されるビルド順序は、テキストの抽出、独立したセマンティックパスと構造パスの実行、日付のフィルタリング、構造的な検出の注入、マークアップへの置換、拒否の検出、および重要なメタデータのログ記録を含み、すべてカナリアセットで継続的にテストしながら行います。

Nothing throws when redaction fails dev.to

RSS Hunter • 今日

ReactでCORSエラーを修正する方法：実践ガイド（実際の解決策付き）

React アプリを構築する際、開発者は API リクエストを行う際に CORS エラーに遭遇することがよくあります。このエラーは、ブラウザのセキュリティポリシーにより、適切な認証なしに一方のオリジンから他方へのリクエストがブロックされるために発生します。最も堅牢な解決策は、バックエンドアプリケーションを設定して Access-Control-Allow-Origin ヘッダーを送信することです。このヘッダーは、どのフロントエンドドメインが API にアクセスできるかを指定します。Node.js と Express の場合、これは cors ミドルウェアを使用し、特定のオリジンを受け入れるように設定することを含みます。同様に、Laravel と Python の Flask は、これらのヘッダーを直接、または flask-cors のようなライブラリを介して設定する方法を提供します。バックエンドの直接変更が不可能な場合は、ローカル開発中にプロキシを使用できます。package.json ファイルに "proxy" フィールドを追加することで、React 開発サーバーはリクエストを API に転送できます。ブラウザはリクエストを同一オリジンとして認識するため、これにより CORS 制限が回避されます。ただし、このプロキシ解決策は開発でのみ有効であり、本番環境では機能しません。一時的で、あまり推奨されない回避策として、公開 CORS プロキシサービスを使用することがありますが、これは遅延、潜在的なレート制限、およびセキュリティ上の懸念を引き起こします。API がクッキーや JWT トークなどの認証を必要とする場合、フロントエンドの fetch リクエストとバックエンドの設定の両方を更新して、認証情報を含める必要があります。フロントエンドのリクエストには credentials: 'include' が必要で、バックエンドには credentials: true が必要です。CORS 問題のデバッグには、ブラウザの開発者ツールのネットワークタブで Access-Control-Allow-Origin ヘッダーの存在と正確性を確認することが含まれます。プリフライトリクエスト (OPTIONS) が失敗している場合、バックエンドがそれらを適切に処理するように設定されていない可能性があります。最終的に、ほとんどの CORS エラーは、フロントエンドコードではなく、バックエンドの設定の問題に起因します。効果的なデバッグには、環境、フロントエンド、およびバックエンドのフレームワークを理解することが不可欠です。

How to Fix CORS Errors in React: The Practical Guide (With Real Solutions) dev.to

RSS Hunter • 今日

XMLを使わない構造化オーサリング - その仕組み

構造化オーサリングは、再利用可能なセマンティックなビルディングブロックからコンテンツを作成します。これはDITA XMLによって形式化された概念です。Topicaryは、XMLの知識を必要とせずにこれらの原則を実装します。コア機能はコンテンツコンポーネントであり、一度記述すれば複数のトピックで再利用できます。コンポーネントを更新すると、そのすべての参照に自動的に変更が伝播します。ユーザーは簡単なコマンドを使用して、任意のテキストブロックをコンポーネントとして簡単に保存できます。コンポーネントは堅牢な「使用箇所」追跡機能を提供し、著者は編集の影響を評価できます。条件付きコンテンツにより、単一のトピックを特定の条件でブロックにタグ付けすることで、異なるオーディエンスに合わせて調整できます。著者は、エディタ内で直接これらの条件付きビューをプレビューして、即座にフィードバックを得ることができます。変数を使用すると、製品名やバージョン番号などの繰り返し要素を単一の場所で更新できるため、コンテンツ管理が効率化されます。Topicaryは、Markdown、DITA、MadCap Flareを含むさまざまな形式からのコンテンツのインポートをサポートし、既存の構造と機能を保持します。

Structured authoring without XML - how it works dev.to

RSS Hunter • 今日

Microsoft Agent Framework が本番稼働可能なランタイムに進歩

MicrosoftのBuild 2026の発表は、General AvailabilityとなったAgent HarnessとFoundry Hosted Agentsに焦点を当てています。これは、AIエージェントが本番環境でどのように認識され、構築されるかの変化を示しています。調査によると、エージェントシステムの約98.4%はAIモデル自体ではなくインフラストラクチャです。Agent Harnessは、関数呼び出し、コンテキスト管理、ツールルーティングなどのタスクを処理する、この重要な運用コアを提供します。Foundry Hosted Agentsは、このハーネスをマネージドで従量課金制のサービスとして提供し、デプロイメントを簡素化します。Agent Harnessは、エージェントとツールの連携や会話履歴の永続化といった、一般的な本番環境のボトルネックに対処します。Microsoftの主要な賭けは、交換可能なAIモデルではなく、このハーネスインフラストラクチャこそが真の製品であるということです。ハーネスには、履歴付き関数呼び出し、コンテキスト圧縮、計画・実行タスクリスト、ファイルメモリ、そしてオブザーバビリティのための組み込みOpenTelemetryなどの機能が含まれています。これにより、ツール呼び出しから承認決定まで、あらゆるアクションが追跡可能になります。Foundry Hosted Agentsは、ユーザーがチャットクライアント、指示、ツールのみを提供するマネージドデプロイメントを提供することで、複雑なYAML設定の必要性を排除します。このマネージドサービスは、ローカルで実行可能なハーネスと同じコアロジックを共有しており、開発環境と本番環境で一貫した動作を保証します。このフレームワークは、GitHub CopilotおよびClaude Agent SDK用のコネクタも導入しており、ハーネスを変更せずにモデルを切り替えることができます。この統一されたガバナンスポリシープレーンは、異なる基盤となるAIモデル間で一貫した承認ルールと監査証跡を保証します。承認ゲート、履歴、ポリシー施行を含むエージェントシステムの永続的なレイヤーは、エンジニアリング投資の重要な領域として強調されています。Microsoftの提供は、ハーネスを安定したサポートされた製品として位置づけ、開発者が適応性のあるアプリケーションの構築に集中できるようにします。

Microsoft Agent Framework Advances to Production-Ready Runtime dev.to

RSS Hunter • 今日

Spring AI プロンプトキャッシュとチャットメモリ：トークンはどこへ行くのか — LLM コスト管理 2/4

このセクションでは、AIモデルにおける出力、会話履歴、および繰り返し静的コンテンツに関連するコストの制御に焦点を当てます。出力および推論トークンは、入力トークンよりも大幅に高価であり、一部のモデルでは出力が最大8倍高くなることがあります。推論プロセスは、より高い出力レートが発生する隠れた「思考」トークンを生成する可能性があります。Spring AIは、プロバイダーに依存しない長さ制限のためのmaxTokensや、推論の労力を管理するためのプロバイダー固有の設定などの制御を提供します。会話履歴は、各リクエストでチャットログ全体を再送信することを含み、入力トークンコストを急速に増加させます。履歴の保存と再送信は、たとえ小さな会話であっても、時間の経過とともにかなりのトークン使用量につながる可能性があります。Spring AIは、指定されたメッセージ数のスライディングウィンドウを使用して会話履歴を管理するためのMessageWindowChatMemoryを提供します。非常に長いセッションの場合、VectorStoreChatMemoryAdvisorは、履歴をベクトルストアに保存し、関連するメッセージのみを取得することで代替手段を提供します。システムプロンプトやツール定義などの繰り返し静的コンテンツは、キャッシュなしで各リクエストで課金されます。プロンプトキャッシュは、処理済みプロンプトプレフィックスを再利用のために保存することで、これらのコストを削減します。AnthropicとAWS Bedrockは、ユーザーがキャッシュ戦略を指定できるようにする一方、OpenAIは一定のトークン数を超えるリクエストに対してプロンプトを自動的にキャッシュしますが、キャッシュ書き込みには現在料金が発生します。Ollamaのようなローカルモデルは、GPU処理時間を節約するためにキャッシュを使用して速度を向上させますが、削減すべきトークンごとの料金はありません。これらのモデルでのコスト最適化には、キャッシュの明示的な計画とキャッシュキーの管理が不可欠です。

Spring AI Prompt Caching and Chat Memory: Where the Tokens Go — LLM Cost Control 2/4 dev.to

RSS Hunter • 今日

6週間前、Googleは私のページを4件インデックス登録していました。それが今115件になりました。ほとんど何も変更していません。

6週間前、著者は新ドメイン tamethebot.com の122ページのうちGoogleにインデックスされたページはわずか4ページだと指摘しました。彼らはこれを技術的な問題ではなく、バックリンクのない若いドメインのクロール予算制限に起因すると考えていました。最近のアップデートでは大幅な改善が示されており、現在115ページがインデックスされ、未インデックスのままのページは14ページのみとなっています。著者のクロール予算問題に関する最初の予測は的中し、「発見済み - 現在インデックスされていない」カテゴリーはゼロに減少しました。重要なのは、この期間中にウェブサイトのコンテンツにほとんど変更が加えられなかったことです。新しいページも同じ速度で追加され、単一の実験的な「ディープ」ページは平均以上の性能を上げませんでした。インデックス化の増加と同時期に行われた主な変更点は、著者の前回の投稿の公開であり、これによりホームページとサイトマップへの2つのdofollowバックリンクが成功裏に獲得されました。決定的な証明はできませんが、このバックリンクとドメインの老化、定期的な再クロールが、Googleにより多くの予算を割り当てる理由となりました。著者は一つの技術的ミスを認めています。IndexNowのデプロイフックが数週間にわたり静かに失敗していたことですが、IndexNowは主にBingとYandexをサービスしているため、Googleのインデックス作成には影響しませんでした。インデックスページの増加は、小さなベースラインからオーガニックなGoogleセッション数の大幅な増加につながっています。しかし、著者は追跡されている「アクティブユーザー」の中には実在の人間ではなくデータセンターであることを注意喚起しています。予想外にも、Googleのインデクサーがページを承認した一方で、Google AdSenseは同じコンテンツを「低価値コンテンツ」として2回拒否しました。著者は、インデックス作成者の基準(検索者が望むかもしれない本物のページか?)がAdSenseの基準(広告ビジネスに十分な深みとトラフィックがあるか)と異なることを認めています。著者の次のステップは、GoogleのインデクサーとAdSenseの両方の承認を得るために公開執筆を続けることです。

Six weeks ago Google had indexed 4 of my pages. It just hit 115. I changed almost nothing dev.to

RSS Hunter • 今日

ベスト無料ウェブアプリケーションファイアウォール比較(2025年)

このテキストは、さまざまなWebアプリケーションファイアウォール（WAF）ソリューションを比較し、タイプとデプロイメント方法別に分類しています。SafeLine Communityは、Docker経由でデプロイされるセルフホスト型のリバースプロキシです。Cloudflare Freeは、DNSの変更が必要なクラウドベースのエッジプロキシです。CrowdSec WAFは、モジュールベースのセルフホスト型オプションであり、ModSecurityはサーバーモジュールとして統合されます。BunkerWebは、NGINXベースのセルフホスト型ソリューションです。検出に関しては、SafeLineとModSecurityは同等のレートを示しますが、ModSecurityは偽陽性が著しく多いです。Cloudflare Freeの検出レートは非常に低く、CDNとして機能する側面が強いです。CrowdSecとBunkerWebのパフォーマンスは、基盤となるルールセットに依存します。いくつかの無料WAFは、Cloudflareの制限のある無料ティアとは異なり、無制限のカスタムルールを提供しています。ボット保護と国別ブロックは、一般的にセルフホスト型オプションの方が強力です。SafeLineは、簡単なワンコマンドセットアップとすぐに使える機能で際立っています。Cloudflareは簡単ですが、検出能力は低く、ユーザーデータを収集します。CrowdSecとModSecurityはより複雑なセットアップが必要であり、ModSecurityは広範なチューニングが必要です。WAFは、公開されているウェブサイトまたはAPIには推奨されます。無料WAFは、特に他のサービスと組み合わせる場合、個人プロジェクトや中小企業には一般的に十分です。SLAと高度な機能を必要とする本番環境では、有料WAFが必要です。無料ティアは通常、専用サポートと高度なロギングを欠いていますが、検出品質は有料バージョンと同等である可能性があります。SafeLine CommunityとCrowdSecは、隠れたコストのない、真に無料のオプションとして強調されています。プラグインWAFは、トラフィックを後で検査するため、リバースプロキシWAFよりも効果が低いです。WAFの効果を維持するためには、定期的な更新が不可欠です。

Best Free Web Application Firewalls Compared (2025) dev.to

RSS Hunter • 今日

信頼性の高いUDPの構築

TCPは信頼性の高いネットワーキングの標準ですが、UDPは特殊なアプリケーションに対してより多くの制御を提供します。UDP自体は信頼性がなく、配信や順序の保証なしにパケットを送信します。ゲームやストリーミングサービスのような多くの高性能システムは、UDPを選択します。なぜなら、UDPは開発者がカスタムの信頼性メカニズムを構築できるからです。これは、UDPパケットにメタデータを追加するという、個別のプロトコルではなく、エンジニアリングパターンを通じて実現されます。主要なコンポーネントには、パケットを追跡するためのシーケンス番号と、受信を確認するための確認応答が含まれます。再送タイマーは、パケットが失われた場合に再送信を開始し、重複検出は冗長なパケットを処理します。パケット順序付けメカニズムは、データがアプリケーションにとって正しい順序で到着することを保証します。スライディングウィンドウは、複数の未処理パケットを許可し、スループットを向上させます。UDPに固有ではありませんが、接続設定はセッション管理のために実装できます。ハートビートは、継続的な接続を確認するために使用されます。輻輳認識は、ネットワーク容量を尊重するために重要です。最終的に、これらのエンジニアリングされたコンポーネントを組み合わせることで、UDPはQUICのようなプロトコルで見られるように、特定のアプリケーションのニーズに合わせて調整された信頼性の高いトランスポート層に変えることができます。エンジニアリングにおける信頼性は、単一の複雑な機能ではなく、複数の単純なメカニズムが連携して機能することから生じることがよくあります。

Building Reliable UDP dev.to

RSS Hunter • 昨日

19のサブドメイン、1つの許可IP

ワイルドカードDNSレコードは、任意のサブドメインを単一のIPアドレスに自動的に解決することで、サービスの発行を容易にします。Nginx Proxy Manager (NPM) は、HTTPSでサービスを安全に公開するために数個のフィールドしか必要としないため、発行をさらに簡素化します。この自動化により、さまざまな認証方法を持つセルフホスト型ソフトウェアを実行する19個のプロキシホストが作成されました。特定された中心的な問題は、発行の容易さがアクセス制御に関する重要なセキュリティ上の決定を迂回してしまうことです。著者の目標は、サービスを完全に隠すことではなく、パブリックインフラストラクチャ上に構築されたプライベートネットワークからのみアクセスできるようにすることでした。ワイルドカードDNSレコードは、セットアップを簡素化しますが、本質的にセキュリティを提供するものではありません。NPMはLet's Encrypt証明書のためにHTTP-01チャレンジを使用するため、ポート80を開いたままにする必要があり、これはセキュリティ上の脆弱性です。DNS-01を介したワイルドカード証明書はポート80を閉じることができますが、DNSゾーンへの書き込みアクセスを許可する必要があります。サービスは、コンテナを共有Dockerネットワークに配置することで発行され、NPMが内部でリクエストをプロキシできるようになります。これにより、サービスはポートをホストに直接公開する必要がなくなり、セキュリティが向上します。同じVPS上のセルフホスト型プロキシゲートウェイは、トラフィックをNPMにルーティングし、VPSのパブリックIPからのインバウンドHTTPSとして表示されます。このゲートウェイの動作は、当初ルーティング障害と誤解されていましたが、セキュリティ設計に不可欠です。NPMは、ゲートウェイの内部Docker IPまたはVPSのパブリックIPからのリクエストのみを許可するNginx設定ブロックと、その後の基本的なHTTP認証を使用してアクセス制御を強制します。これにより、サービスがパブリックに解決可能で有効な証明書を持っていても、アクセスは制限されます。Let's Encryptチャレンジ用の特定の場所は、証明書検証に必要なため、インターネットに公開されたままです。ゲートウェイの管理パネルと設定配布エンドポイントという2つの重要なホストは、完全なゲートウェイ統合の前にアクセス可能である必要があるため、厳格なアクセス制御の例外です。サービスがユーザー接続プロファイルにサーバーアドレスを埋め込み、誤って間違ったアドレスを広告してしまったときに、重大な問題が発生しました。NPMはX-Forwarded-Forヘッダーを介して実際のクライアントIPを転送するため、サービスはこのヘッダーを自身のパブリックアドレスと解釈し、クライアントが間違ったサーバーに接続する原因となりました。著者のゲートウェイを使用した自身のテストでは常に正しい期待されるアドレスが表示されていたため、このバグは隠されていました。TLS終端はNPMで行われ、NPMとバックエンドコンテナ間のトラフィックはDockerネットワーク上で暗号化されていないHTTPとして送信されます。

Nineteen Subdomains, One Allowed IP dev.to

RSS Hunter • 昨日

ClaudeにTelegramへのアクセスを許可する：2つのセットアップと、その違いが重要である理由

MCPサーバーを使用してAIエージェントをTelegramに接続できますが、セキュリティ上の重大な影響を伴う2つの異なるセットアップがあります。最初のタイプはBot APIトークンを使用し、ボットとして認証します。このボットは、明示的に追加されたチャットにのみアクセスでき、そのアクセスは制限されており、簡単に取り消すことができます。招待されていないプライベートメッセージやチャットを見ることはできません。2番目のタイプはMTProtoサーバーを使用し、電話番号で認証してあなたとしてログインします。これにより、エージェントはプライベートメッセージ、グループ、保存済みメッセージ、連絡先を含むすべてのTelegramデータにアクセスできるようになります。これは、ライブログインを表すセッションファイルを作成することによって実現されます。Bot APIまたはnotifierのセットアップには、ボットトークンと場合によってはチャットIDの提供が必要です。MTProtoのセットアップには、インストールとAPI IDおよびAPIハッシュを使用したインタラクティブなログインが必要です。設定ファイルの場所は、使用されているAIクライアントによって大きく異なり、Codex CLIのような一部のクライアントは異なる設定形式（TOML）を使用します。MTProtoサーバーに関する主な懸念は、セッションファイルがアカウントへのフルアクセスを提供することです。このセッションファイルは、同期フォルダーに保存したり、コードリポジトリにコミットしたりしてはなりません。さらに、AIエージェントはデータと指示の両方をテキストとして扱うため、悪意のあるメッセージを作成してエージェントのメッセージ送信能力を悪用する可能性があり、セキュリティリスクとなります。Bot APIトークンの影響範囲は、ボットが存在するチャットに限定されますが、MTProtoセッションファイルはアカウント全体を侵害します。MTProtoサーバーは本質的に使用不可能ではありませんが、慎重な検討が必要であり、リスクを軽減するためにセカンダリアカウントで使用することが理想的です。重要なアカウントに接続する前に、これらのコミュニティ開発のMCPサーバーのコードを確認することが不可欠です。

Giving Claude access to your Telegram: the two setups, and why the difference matters dev.to

RSS Hunter • 昨日

RAGコストの見積もり：トークン数、埋め込み、Node.jsセマンティック検索

セマンティック検索アプリのRAGコストを管理するには、ドキュメントのバッチインデックス作成と、ロールアウト前のトークン消費量の見積もりを行います。回答生成のためにチャットモデルに送信するのは、取得された上位チャンクのみとします。有用なトークンコストの見積もりは、インデックス作成時の埋め込み入力、検索時の操作、および回答生成の入力と出力を分離する必要があります。見積もりは単純なトークン数を超え、チャンクサイズ、オーバーラップ、およびトップk設定を評価することを含みます。これらはプロンプトの長さとコストに直接影響するためです。実践的な見積もりは、代表的なドキュメントと実際のユーザーの質問から始まり、さまざまなチャンキング戦略のトークン合計を計算します。リコールが重要であり、チャンク数が少なくても最も関連性の高い箇所が依然として取得される場合にのみ有益です。再ランキングはコンテキストの順序付けを改善し、チャットモデルに送信するチャンク数を減らすことができます。インデックス作成は、ユーザー向けの要求パスとは別のバッチジョブとして扱う必要があります。これにより、高い取り込み量による予期せぬプロンプト請求を防ぎます。ドキュメントインデックス作成中のリトライには、重複データを避けるために冪等性キーまたはクライアント提供の識別子が必要です。プロンプトやモデルを最適化する前に、ドキュメントの分布を可視化し、大きすぎるチャンクを特定することが不可欠です。適切なバックオフおよびリトライ戦略を備えたプロバイダー固有のトークンカウント呼び出しを使用することが、正確な見積もりの鍵となります。バッチインデックス作成は、ジョブ監視と監査証跡を可能にし、アップロードを埋め込み作成から分離することで、大規模なバックフィルに利点をもたらします。ポーリングバッチジョブと冪等書き込み操作間のリトライポリシーを混同しないことが重要です。バッチインデックス作成は即時の検索可能性には理想的ではありませんが、小さな同期パスでそのニーズに対応できます。OpenAI、Anthropic、Google Gemini、Pinecone、Weaviate、InfraiなどのRAGスタックコンポーネントの選択は、既存のワークフローとチームの優先順位に依存します。移行は、わずかなコスト削減のためだけでなく、システムを真に改善する場合にのみ行うべきです。最終的に、コードは根拠のある回答を提供する必要があり、クリーンなコスト見積もりは、検索が弱い場合には無意味です。

RAG Cost Estimates: Token Counts, Embeddings, and Node.js Semantic Search dev.to

RSS Hunter • 昨日

私は自律型AIエージェントのディストリビューションの価格設定を行いました。SMB ARPUではどのパスもクローズしません。

この投稿は、自律型AI企業にとっての流通上の制約について論じており、明確なロードマップのない重大な障害であると主張しています。Meta Adsのようなプラットフォームを通じた有料獲得は、中小企業にとって法外に高価であり、推論とデータ費用を考慮すると、顧客獲得コストが顧客生涯価値をはるかに上回ります。中小企業の典型的なサブスクリプション料金では、自律型エージェントの収支は合いません。かつては回避策であったコールドアウトリーチチャネルは、自動化された大量メッセージングに対してますます閉鎖的になっています。ソーシャルメディアプラットフォームは、AI生成スパムに対するより厳格なポリシーを導入しており、エージェントがプログラムでアウトバウンドメッセージを送信することを困難にしています。LinkedInとRedditは、自動化されたアウトリーチを積極的に罰する利用規約と行動フィルターを備えています。コールドメールの到達可能性も、ドメインの共有や、単一の顧客の誤用によるブラックリスト登録の可能性により低下します。残された実行可能な流通チャネルには、コンテンツマーケティング、SEO、コミュニティ構築、創業者主導のブランディング、パートナーシップなど、人間の関与が必要です。これらの方法は、長期間にわたる一貫した努力、判断、センス、関係構築を要求します。自律型エージェントは、その性質上、特に企業の成長の初期段階において、これらの本質的に人間中心の戦略を実行することに苦労します。著者は、推論コストは低下し、データ取得方法は改善されているものの、流通は自律型AIにとって根本的な課題であり続けていると主張しています。流通を自律的に拡大するための簡単な「構築」または「待機」の解決策はありません。この論文は、確立された有料獲得を持つ消費者向けアプリや組み込みソリューションのような特定のニッチには当てはまりますが、「AIがあなたの会社を運営する」という一般的なビジョンには当てはまりません。最終的に、中小企業にとってAIの真のレバレッジは、完全な自動化ではなく、人間の判断がプロセスを導く中で、流通の反復的な「グラインド」を自動化することにあります。著者の会社であるThread Otterは、既存の需要を見つけて関与するのを支援し、ユーザーの声で応答を作成し、アウトリーチの骨の折れる側面を自動化するオートパイロットを提供することを目指しており、人間が判断の累積的なインプットに集中できるようにします。このアプローチは、流通は自律的に製造することはできないが、人間の監督によって発見および管理できることを認識しています。

I priced distribution for an autonomous AI agent. None of the paths close at SMB ARPU. dev.to

RSS Hunter • 昨日

Python (Click) で CLI ツールを構築する

この作品は、PythonとClickライブラリで構築されたシンプルなコマンドライン経費トラッカーであるPennyについて説明しています。Pennyは、Webインターフェースやデータベースを必要とせずに、ユーザーがターミナルから直接経費を追加、一覧表示、要約、クリアすることを可能にします。著者は、コマンドとオプションを定義するためのより直感的でデコレータベースのアプローチを持つClickを、Pythonの組み込みargparseよりも選択しました。プロジェクトは3つの主要なファイルに構造化されています。個々のコマンドロジックのためのcommands.py、これらのコマンドを単一のCLIツールにグループ化するためのpenny.py、そしてパッケージングとエントリーポイントの定義のためのpyproject.tomlです。Pennyは、expenses.jsonというプレーンなJSONファイルに経費データを保存し、各操作でそれに読み書きします。addコマンドは、JSONファイルが存在しない場合は作成し、新しい経費を追加して更新されたリストを保存し、色付きの確認を提供します。listコマンドは、保存された経費を表形式で表示し、経費が見つからない場合は警告を表示します。summaryコマンドは、カテゴリごとの支出合計と総計を計算して印刷し、結果をフォーマットされたJSONとして出力します。clearコマンドは、expenses.jsonファイルを空のリストで上書きする前に、確認プロンプトを含みます。penny.pyファイルは、Clickのグループ機能を使用して、すべてのコマンドを単一のpenny実行可能ファイルの下に統合します。pyproject.tomlファイルはこのグループ化を設定し、Pennyをpip install .経由でグローバルにインストール可能なコマンドラインツールにします。著者は、Clickの宣言的なスタイル、シンプルなデータストレージに適したJSON、小さなユーザーエクスペリエンスの詳細の重要性、そしてコマンドグループ化がスクリプトを洗練されたCLIアプリケーションに昇華させる方法の利点を強調しています。

Building a CLI tool with Python(Click) dev.to

RSS Hunter • 昨日

12のグラデーション、1つのID - DHSeaDev

微妙なマークアップの欠陥は、すべて同じIDで定義された12個の同一のSVGグラデーションに関係していました。これにより、12個のグラデーション定義のうち11個が未使用となり、すべてのビジュアル要素は誤って最初の定義を参照していました。すべての重複したグラデーションが同一の色停止を持っていたため、ページは視覚的に正しく表示されていました。この見えにくさにより、著者自身の5回のチェックを含む標準的なサイト監査でも、この問題を発見できませんでした。グラデーションの定義が変更され、誤った要素またはどの要素にも影響を与える可能性があったまで、問題は隠されたままでした。重複IDの重要な監査チェックは、以前は視覚的な問題を引き起こしたことがなかったため、欠落していました。 IDを順次リネームする初期の修正試みは、誤った定義と参照をペアにすることで、より深刻で視覚的なバグを作成しました。この見落としは、定義と参照の間の不均衡をフラグ付けしたカウントアサーションによって防止されました。正しいソリューションは、IDのリネームを個々のSVGブロックにスコープし、定義が独自のスコープ内の参照と一致することを確認します。この経験は、特にインラインSVGでの重複IDの監査の重要性と、検索および置換操作の綿密な検証の重要性を強調しています。

Twelve gradients, one id - DHSeaDev dev.to

RSS Hunter • 昨日

誰も読まなくても、すべての開発者が書くべき理由

ソフトウェアエンジニアのキャリアにおいて、コーディングだけにとどまらず、ライティングは不可欠な要素です。すべての開発者は、コミットメッセージ、変数名、バグレポート、ドキュメンテーションを作成するため、これは基本的なスキルとなります。特に技術記事の執筆における真のメリットは、外部の読者数ではなく、個人の成長とエンジニアリング能力の向上にあります。執筆は構造化された思考を強制し、それによって自身の理解におけるギャップを露呈させ、知識の厳密なテストとして機能します。経験を文書化することは、束の間の教訓を持続的な知識に変え、学習の最高形態として機能します。経験豊富なエンジニアは、優れたドキュメンテーションが進捗を加速し、技術的負債を削減し、チームのための保守可能な知識を創造することに気づいています。LinkedInや個人のブログのようなプラットフォームは、プロフェッショナルな成長を披露し、耐久性のある検索可能な知識ベースを構築する機会を提供します。この執筆の実践は、「第二の脳」、つまり将来の問題解決を助け、技術面接をより自然にする外部メモリを作成します。執筆を通じて個人のブランドを開発することは、専門知識と信頼性を示し、目に見える証拠を通じて見えない専門知識を証明します。専門知識や読者がいなくても、早期に執筆を開始することが重要です。なぜなら、成長は認知に先行するからです。一貫した執筆の複利効果は、時間の経過とともに貴重なプロフェッショナルなレガシーを構築します。最終的に、コードが製品を構築する一方で、ライティングはその背後にあるエンジニアを構築し、技術的なスキルと思慮深いコミュニケーションの両方で記憶されるキャリアを育みます。

Why Every Developer Should Start Writing (Even If Nobody Reads It) dev.to

RSS Hunter • 昨日

Dockerはあなたのアプリが実行されることを証明し、Kubernetesはそれが運用可能であることを証明します。

著者は、すべての技術的指標が正常に見えるにもかかわらず、Kubernetes内のサービスがダウンしているという一般的なデバッグシナリオを説明しています。これは、Dockerがアプリケーションの実行を検証するのに対し、Kubernetesはそれが運用可能であることを検証するため、発生します。Dockerの単純さは、本番環境でアプリケーションが答えなければならない4つの重要な質問を隠しています。最初の質問は、アプリケーションが名前で、アドレスだけでなく見つけられるかどうかです。Kubernetesポッド内のlocalhostは、ポッド自体のみを参照するためです。次に、アプリケーションは、SIGTERMのようなシグナルに適切に応答することで、外部システムによってクリーンに終了されることを処理できる必要があります。3番目に重要な側面は、トラフィックを受信する前に準備ができていることを証明することです。Kubernetesは、起動した瞬間から積極的にアプリケーションのヘルスをプローブするためです。最後に、アプリケーションは、Kubernetesの設定およびストレージメカニズムを使用することで、ローカルディスク永続性に依存せずに機能する必要があります。これらの4つの質問を理解することは、DockerとKubernetesでアプリケーションが異なる動作をする理由を解明するのに役立ちます。著者は、これらの点を対処しないことが一般的な本番環境の問題につながる方法の例を提供しています。この説明はKubernetesに対する反対意見ではなく、Dockerがチームに蓄積を許容する運用上の負債の探求です。

Docker Proves Your App Runs. Kubernetes Proves It's Operable. dev.to

RSS Hunter • 昨日

QAのための実践的なリアルワールドテストシナリオ：チャレンジ3 - APIモッキングによるビジュアルテスト

著者は、欠落したチャートのダッシュボード、車両状況を示す交通アプリ、樹木の位置を示すサービスアプリなど、いくつかのアプリケーションの視覚テストを実施しました。ビジュアルテストは、特にUIが安定しているときにUIの故障を早期に発見するのに役立ちます。PlaywrightはApplitoolsやPercyのような有料ツールとは異なり、無料の視覚テスト機能を提供しています。重要な課題は、「平均遅延日数」指標が日々変動するAccounts Receivableダッシュボードを視覚的にテストすることです。英語、スペイン語、ドイツ語、日本語など複数の言語でテストする際も、テキストの長さの違いから挑戦があります。さらに、データの正確性を検証するためにモックなしの統合APIテストも必要です。動的価値が視覚的な一貫性に影響を与える場合、テスト戦略としては動的領域をマスキングしたり、APIをモックしてあらかじめ定義された値を返すことが含まれます。提供されたリンクは、これらのシナリオをテストするためのウェブサイトとAPIを提供しています。著者はチャレンジ完了後にリポジトリの共有や質問を促しています。

Practice Real-World Testing Scenarios for QA: Challenge 3 - Visual Testing with API Mocking dev.to

RSS Hunter • 昨日

LangGraphで決定論的なマルチエージェントワークフローを構築する

ビジネスプロセスにおける自律エージェントの使用は予測不可能であり、カオスな実行ループにつながる可能性があり、これは商業契約や規制遵守の提出などのハイステークスなオペレーションを扱う場合に問題となる可能性があります。この問題に対処するには、認知の柔軟性を維持しながら厳格なルールを強制する構造化されたフレームワークが必要です。LangGraphは、決定論的なマルチエージェントワークフローの構築を可能にするオーケストレーションフレームワークであり、予測不可能なAIの動作を信頼性の高い、ステートマシン駆動のビジネスプロセスに変えることができます。LangGraphは、エージェントの相互作用をノードとして、遷移をエッジとしてモデル化し、循環パスと自己修正の実装を可能にします。このアーキテクチャにより、すべてのノードが蓄積されたコンテキストにアクセスできるようになり、状態へのあらゆる変更は明示的に追跡および検証されます。LangGraphを使用することで、企業は、非常に変動しやすいLLMの出力に対処する場合でも、予測可能な動作をする回復力のある自己修正システムを構築できます。LangGraphは、厳格で監査可能なビジネスワークフローの構築に特に役立ち、そのステートファーストのアプローチにより、開発者が定義したルールが常にエージェントの自律性よりも優先されることが保証されます。決定論的なエージェントワークフローの実装は、商業保険の引受、ヘルスケアの収益サイクル管理、サプライチェーンの通関仲介などの例に見られるように、運用効率、リスクプロファイル、およびボトムラインの成長に直接影響を与える可能性があります。LangGraphを使用することで、企業はエラーのリスクを軽減し、効率を改善し、生産性を向上させ、最終的にはコスト削減と収益成長につながることができます。全体として、LangGraphは決定論的なマルチエージェントワークフローの構築のための堅牢なソリューションを提供し、企業が制御と予測可能性を維持しながら複雑なプロセスを自動化できるようにします。

Building Deterministic Multi Agent Workflows with LangGraph dev.to

RSS Hunter • 昨日

Qwen3.8-MaxがGAになりました：Alibabaの2.4Tモデルの開発者向けガイド

Alibabaは、2.4兆パラメータの強力なMixture-of-ExpertsモデルであるQwen3.8-Maxをリリースしました。このモデルは、100万トークンのコンテキストウィンドウを備え、テキスト、画像、ビデオの入力をサポートしています。APIはOpenAIおよびAnthropicのプロトコルと互換性があり、開発者の統合を容易にします。価格は、入力トークン100万あたり2ドル、出力トークン100万あたり6ドルに設定されています。コスト削減の重要な要因は、キャッシュされた入力トークンの価格が引き下げられていることであり、プロンプトにおける安定したプレフィックスの重要性を強調しています。モデルの命名規則は、世代とポイントリリースを区別しており、Qwen3.8-Maxが最新のフラッグシップです。合計2.4兆パラメータを誇りますが、トークンあたり約950億パラメータのみがアクティブであり、推論がより効率的になります。実効コンテキストウィンドウは約991Kトークンで、最大出力トークン制限は131Kです。開発者は、ベースURLとモデル名を更新することで、OpenAI互換APIを利用できます。AlibabaのDashScope SDKは、コードスニペットでマルチモーダル機能の例を提供しています。このモデルは、関数呼び出しや構造化出力を含むさまざまな機能をサポートしており、5つの組み込みツールが付属しています。ベンチマークでは、マルチモーダルおよびエージェントタスクで高いパフォーマンスを示していますが、Claude 3.5などの競合他社に遅れをとっている分野もあります。オープンウェイトは、より小さな27Bパラメータバージョンとともに、まもなくリリースされる予定です。現在、詳細なトレーニングデータと安全評価を含む正式なモデルカードが欠落しています。商用利用のライセンス条件は、オープンウェイトがリリースされるまで明確になりません。アクティブパラメータ数は報告されていますが、Alibabaによって公式に確認されていません。これらの欠けている要素にもかかわらず、Qwen3.8-Maxは、マルチモーダルアプリケーション、長コンテキストタスク、および既存のOpenAI/Anthropicプロトコルユーザーに推奨されます。

Qwen3.8-Max Just Went GA: A Developer's Guide to Alibaba's 2.4T Model dev.to

RSS Hunter • 昨日

トークン/秒：AIモデルの速度を測定および最適化する方法

レイテンシは、言語モデルやAIモデルを本番環境に実装する際の重要な課題です。精度のみに焦点を当て、計算パフォーマンスを無視することは誤りです。トークン/秒で測定される速度は、不可欠なアーキテクチャメトリックになりました。これは、特に金融やヘルスケア分野において、クリティカルなアプリケーションが迅速な応答を必要とするためです。モデルのパフォーマンスを最適化することは、GPUの使用率の低下にもつながり、結果としてクラウド請求額の削減にもつながります。軽量アーキテクチャの使用、量子化、バッチ処理などの技術は、精度を犠牲にすることなく速度を向上させるのに役立ちます。トークン/秒でモデルの速度を測定するためのPythonでの実践的な例を示します。約100トークン/秒という目標は、リアルタイムの人間との対話の良い基準となります。最適化の手順には、初期ベンチマークの設定、バッチ処理の実装、蒸留または量子化されたモデルの評価が含まれます。コミュニティは、AIモデルのプロファイリングとベンチマークのためのツールやライブラリを共有しています。

Tokens por Segundo: Cómo medir y optimizar la velocidad en modelos de IA dev.to

RSS Hunter • 昨日

コンピューターを実際に操作できるオープンソースAIエージェントを構築しました

AIエージェントは普及していますが、現実世界のコンピューター操作には苦労しています。既存の自律エージェントは、タスクを早期に完了と宣言したり、マルチステップワークフローでコンテキストを失ったり、デスクトップ環境との統合が欠けていたりすることで失敗することがよくあります。HeyAgentは、単純な大規模言語モデルラッパーではなく、真のアシスタントとして機能することで、これらの問題に対処することを目指しています。このオープンソースエージェントは、デスクトップアプリケーションを制御し、ブラウザと対話し、ファイルを管理し、ターミナルコマンドを実行し、外部サービスに接続できます。HeyAgentは、計画、実行、結果の検証を行い、その後初めてタスク完了を確認することで、誤検知を減らして差別化を図っています。このプロジェクトは、AWSからの大幅な加速とサポートを受け、重要なクラウドインフラストラクチャとコンピューティングリソースを提供されました。HeyAgentは、TypeScriptとNode.jsを使用したモデルに依存しない技術スタック上に構築されており、クラウドおよびローカルLLMの両方をサポートしています。オープンソースであるため、開発者はその推論を検査し、ツールを構築し、改善に貢献できます。今後の開発は、強化された計画、より堅牢なデスクトップ自動化、および拡張されたプラグインエコシステムに焦点を当てます。チームは、フィードバック、アイデア、バグレポート、およびプロジェクトへの貢献を歓迎します。

I Built an Open-Source AI Agent That Actually Controls Your Computer dev.to

RSS Hunter • 昨日

中国語の名前生成ツール

同僚がランダムな中国名ジェネレーターで残念な経験をしたことから、著者はより優れたものを開発しようと着想を得ました。既存のジェネレーターは音のみに焦点を当てており、意味、声調、文化的意義といった重要な要素を無視しているため、滑稽または不適切な名前の組み合わせにつながる可能性があります。中国の命名の伝統は、音韻学以外の要素、例えば画数、五行分類、歴史的な使用法などを考慮に入れており、これらはすべて名前が好意的に受け入れられるために不可欠です。調査によると、多くの人々が名前を選ぶ際に画数 numerology を依然として考慮していますが、これは現在のツールではほとんど無視されている慣習です。著者のプロジェクトは、細心の注意を払って検証された中国の文字のデータベースを作成することにより、正確性を優先しました。各文字は、定義のために康熙字典との相互参照、百家姓に対する正当性の検証、および人名学の研究の参照を含む、厳格なチェックを受けました。この検証プロセスは、単純な文字の組み合わせではなく、プロジェクトの中核をなすものです。著者は、意味や文化的重みの偶発的な衝突を防ぐことが、中国の名前生成における真の課題であると強調しています。開発されたツールは、生成された各名前に7つの検証済みデータポイントを提供します。これらのデータポイントには、文字自体、そのピンイン発音、画数、五行分類、ラッキーナンバー、ラッキーカラー、および調和スコアが含まれます。このスコアは、伝統的な中国の命名システムである確立された三才五格フレームワークから導き出されています。

A Chinese Name Generator Tool dev.to

RSS Hunter • 昨日

無題

A2Aプロトコルには現在、Agent Cardの真正性を検証するメカニズムが欠けています。あるエージェントが別のエージェントのAgent Cardを取得する際、暗号学的な身元証明なしにメタデータのみを読み取ります。これにより、誰でも特定の役割を主張する偽のAgent Cardを作成できるため、エージェントはなりすましに対して脆弱になります。プロトコルは、身元検証を外部の、しばしば手動のプロセスに委任しています。mTLSのようなトランスポート層セキュリティは通信チャネルを保護しますが、エージェント自体の認証は行いません。これを解決するには、Agent Cardに公開鍵をバインドし、重要なフィールドに署名する必要があります。エージェント間のやり取りが発生する前に、HTTPSと同様の検証ステップが不可欠です。手動の回避策としては、拡張フィールドに公開鍵を格納し、メッセージ署名を手動で検証することが含まれます。しかし、このアプローチは脆弱であり、一貫性のない規約に依存しており、悪意のあるアクターによって悪用される可能性があります。A2A仕様では、Agent Cardに専用のIDフィールドが必要です。このフィールドには、公開鍵とその発行者への参照（例：Decentralized Identifier (DID)）が含まれるべきです。カードの正規JSON表現に対して署名スキームを定義する必要があります。重要なのは、このIDの検証がA2Aハンドシェイクの必須部分であることです。この提案されたソリューションには、発行者の公開鍵を取得し、カードの署名を検証し、失効ステータスを確認することが含まれます。このプロセスにより、エージェントのカードが検証可能な発行者によって信頼されており、侵害されていないことが保証されます。この標準化されたソリューションなしでは、エージェント間の通信における現在の信頼モデルは、特にエージェントが機密データやトランザクションを扱い始めるにつれて、重大な脆弱性のままです。

Untitled dev.to

RSS Hunter • 昨日

EU AI Act Voice Watermarking: TTSビルダーが知っておくべきこと

EU AI Act のボイスウォーターマーキング規則は、2026年8月2日から施行され、AI生成音声の機械可読マーキングを義務付けています。遵守しない場合、最大1500万ユーロまたはグローバル売上高の3%の罰金が科されるリスクがあります。テキスト読み上げやボイスクローンを含む合成音声を生成するAIシステムのプロバイダーは、その出力が人工的であると検出可能であることを保証しなければなりません。この法律は、技術的に可能な限り、効果的で、相互運用可能で、堅牢で、信頼性の高いマーキングを要求する、結果ベースのアプローチを強調しています。不可聴ウォーターマークと署名付きメタデータを組み合わせた多層的なアプローチが一般的になりつつあります。人間と対話するAIシステムも、AIであることを開示する必要があり、ディープフェイクは開示が必要です。欧州委員会は、コンプライアンスのためのガイドラインと行動規範を提供しており、多くの企業が署名しています。既存のシステムには、マーキングコンプライアンスのために2026年12月2日までの猶予期間があります。免除は、音声を実質的に変更しない支援編集機能に限定されます。TTSプロバイダーは、ウォーターマーキングのためにGoogleのSynthIDやMetaのAudioSealのような方法を採用しています。OpenAIのAPIは、埋め込まれた信号の検証を可能にしますが、マークされていないコンテンツや削除されたコンテンツを検出することはできません。開発者は、音声出力を監査し、パイプライン全体でのウォーターマークの生存を確認し、開示義務を管理し、生成記録を維持する必要があります。これらの規制を無視することは、重大な財務的および評判上のリスクを伴います。

EU AI Act Voice Watermarking: What TTS Builders Must Know dev.to

RSS Hunter • 昨日

コールトゥアクションは存在していても、行き止まりになる可能性があります。URLだけでなく、クリック可能かどうかを監査してください。

自動化されたコンテンツパイプラインは、動画の説明文にクリック可能なコールトゥアクションが含まれていないことを検出し損ねました。ドメイン文字列の存在を確認するシステムのチェックは不十分でした。なぜなら、「http://」または「https://」のない生のURLは、YouTubeのようなプラットフォームでは自動的にリンクされないためです。これは、説明文にオファーのドメインが記載されていても、視聴者は直接アクセスできなかったことを意味します。初期の監査ではチェックが合格したと誤って報告され、URLテキストが存在するにもかかわらず、コンバージョンはゼロでした。この解決策には、必要なURLスキームを含むクリック可能なリンク形式を具体的に検索するように監査を更新することが含まれていました。これは、「https?://」をターゲットとする正規表現を使用して達成されました。その後、より堅牢で汎用的な修正が実装されました。それは、コンテンツが公開される前に、生のドメインの言及を実際のクリック可能なリンクに自動的にアップグレードする中央プロセスです。この機能は、既存のマークダウンリンクと完全なURLが保持されることを保証します。リンク化機能は、代替処理を使用して既存のリンクを優先し、既に機能しているURLの偶発的な変更を防ぎます。これにより、単純なアプローチが既存のリンクを破損させる二次的なバグが防止されました。中心的な教訓は、ユーザビリティが実際の要件である場合、単なる存在の自動チェックは欺瞞的であるということです。リンクが存在することを確認するチェックは、人間がそれを使用できることを確認することと同じではありません。自動化されたプロセスが結果を生まない場合、ツールが正しい機能的な基準を評価しているかどうかを確認することが重要です。

Your call-to-action can be present and still dead-end. Audit for clickable, not just for the URL. dev.to

RSS Hunter • 昨日

オートスケーリングはあらゆるワークロードに適しているわけではありません。見分け方と、代わりに構築すべきもの

「ただAutoscalingグループの後ろに置けばいい」というアドバイスは、Webサーバーなどのステートレスアプリケーションのスケーリングに一般的に使用されます。これは、レプリカが相互に交換可能であり、最小限の影響で追加または削除できるため、うまく機能します。ただし、このアプローチはすべてのワークロードに適していない、特に交換可能性を侵害する特定のプロパティを持つワークロードには適していません。そのようなプロパティの1つは、セッションアフィニティです。ここで、セッションは特定のインスタンスに結び付けられており、簡単に転送することはできません。もう1つは、新しいインスタンスの起動時間が遅く、インスタンスが必要なときに準備できていない場合、反応型のスケーリングは効果的ではありません。これらの特性を持つワークロードの場合、標準的な反応型オートスケーリングは誤った解決策です。即時の反応ではなく、スケーリングアウトはより遅い、傾向に基づくトリガーを使用する必要があります。これにより、新しいインスタンスが重要な時期に必要になる前に、完全に動作するための十分な時間が与えられます。安全にスケーリングインすることも重要です。インスタンスを単純に終了すると、進行中の作業が中断される可能性があるためです。AWSライフサイクルフックなどの業界の解決策は、インスタンスが終了される前にセッションを優雅にドレインすることを可能にします。このパターンには、新しい作業を停止し、既存のセッションが完了するまで待ち、次にインスタンスを削除することが含まれます。ビデオ会議プラットフォームなどの大規模システムは、すでにこれらのより洗練されたスケーリング戦略を使用しています。重要なポイントは、インスタンスの交換可能性を評価することです。任意のインスタンスが任意のタスクを瞬時に処理できる場合、オートスケーリングは適切です。そうでない場合、より遅いスケーリングアウトメカニズムと適切なスケーリングインドレインロジックが、セッションアフィニティまたは起動が遅いワークロードを効果的に管理するために必要です。これらのワークロードを反応型の交換可能モデルに強制すると、重大な障害につながります。

Autoscaling Doesn't Fit Every Workload Here's How to Tell, and What to Build Instead dev.to

RSS Hunter • 昨日

SaaSのホームページにパブリックなグラフィティウォールを設置しました

ほとんどのSaaSホームページでは、提供する製品を紹介するために静的な製品スクリーンショットが使用されています。しかし、この製品のホームページでは、代わりに「Owners Were Here」という埋め込み型の機能的なゲストブックが使用されています。このゲストブックは、ウィジェットビルダーで構築されており、実際のライブ投稿を表示することで、製品の目に見えないバックエンドを実証しています。ゲストブックはコンセプト実証として機能し、スクリーンショットでは伝えきれない機能性を強調しています。この選択の主な理由の1つは、フォームはマーケティング資料で説得力を持って偽造するのが難しいということです。埋め込み型ゲストブックは、ユーザーの貢献を通じて即座に、累積的な社会的証明を提供することを目指しています。このアプローチは、「落書きの壁」のような美学を活用し、有機的に埋まっていきます。公開エンドポイントを公開する際には、堅牢なセキュリティ対策が不可欠です。これには、Cloudflare Turnstileによるボット検出、レート制限、スキーマ検証、および悪用を防ぐためのサイズキャップが含まれます。信頼されていないユーザー入力をレンダリングするには、クロスサイトスクリプティングのようなセキュリティ脆弱性を回避するために、慎重な処理が必要です。ユーザー生成コンテンツを安全に表示するには、innerHTMLではなくtextContentを使用してテキストを適切にサニタイズすることが不可欠です。成長するゲストブックは、ホームページのレイアウトや読み込み時間に悪影響を与える可能性があります。最大高さと内部スクロールを備えたビューポートを実装することで、ゲストブックがページを圧倒するのを防ぎます。いくつかのジャンクエントリは予想されますが、埋め込みウィジェットのコアセキュリティと機能性は、これらの設計上の選択によって保護されています。

I put a public graffiti wall on my SaaS homepage dev.to

RSS Hunter • 昨日

ハッカーのマインドセット

著者は、成長マインドセットと応用された好奇心に根ざしたハッカーのマインドセットを説明しています。典型的なユーザーの操作とは異なり、ハッカーは文書化されていない機械の学習に似た、ランダムな操作を試みた場合に何が起こるかを探求します。これには、意図された手順に従うだけでなく、「これをしたらどうなるか」と疑問を投げかけることが含まれます。電話をブリックさせてしまうにもかかわらず、繰り返し電話をルート化するような初期の経験は、安全性よりも好奇心を優先することを示しています。失敗は終わりではなく、将来の試みを改善する学習機会と見なされます。探求する本能は、説明を受けた時点で止まるのではなく、粘り強さと組み合わされることで、より意味のあるものになります。効果的に革新するためには、既存のルールや基本を理解してから、それらを逸脱しようと試みる必要があります。子供時代の危険な実験を再現するのではなく、管理された環境でテストすることが推奨されます。しばしば見過ごされがちな重要な側面は、不確実性への快適さと、混乱した、不明瞭な調査段階を乗り越えるための粘り強さです。この粘り強さ、「退屈で混乱した中間部分」への耐性は、諦める者と新しい洞察を発見する者を区別します。最終的に、ハッカーのマインドセットは、システムを検査し、意図された機能と実際の動作との間の不一致を求めるレンズであり、これによりセキュリティバグや興味深い癖が明らかになる可能性があります。

The Mindset of a Hacker dev.to

RSS Hunter • 昨日

RAGのUIを追加するにはどうすればいいですか?!?

FastAPI SSE バックエンドで LLM レスポンスをトークンごとにストリーミングする機能を構築しました。時間ができたので。本番環境で 2 つの問題が発生しました。ローカルでは問題なく動作していました 🙃:nginx はデフォルトで SSE をバッファリングします。ストリームはローカルでは配信されていましたが、Railway では完全に沈黙していました。proxy_buffering off に設定したところ、2 時間後に修正されました。LLM API は、ドキュメントが一致しない場合に empty_retrieval イベントを返します。これを処理していなかったため、フロントエンドは無限にローディングスピナーのままでした。ハンドラーを追加して解決しました。https://zooming-charm-production-547e.up.railway.app/

How to add UI for your RAG?!? dev.to

RSS Hunter • 昨日

AWS NAT Gatewayのコストを削減する方法：7つの方法、節約額順

AWS NAT Gateway の料金には、主に2つの請求項目があります。低額の時間料金とデータ処理料金です。データ処理料金は、1ギガバイトあたり $0.045 で、これが主なコスト要因であり、トラフィックとともに増加します。これらのコストを削減するために、最も効果的なものから順に、いくつかの戦略を採用することができます。まず、S3 および DynamoDB の無料ゲートウェイエンドポイントを実装します。これにより、多くの場合、ギガバイトあたりの料金の 30〜60% が削減されます。次に、頻繁にアクセスされる AWS サービスについては、インターフェイスエンドポイントを検討します。VPC フローログは、高トラフィックのソースを特定するために不可欠であり、修正には多くの場合、キャッシングとより良い衛生管理が伴います。クロスアベイラビリティゾーンの追加料金を回避するために、トラフィックをゾーンごとにルーティングするか、ゲートウェイを意図的に統合します。非本番環境の NAT ゲートウェイを統合することで、未使用のリソースの時間料金を節約できます。さらなる節約のために、fck-nat のような NAT インスタンスは、ギガバイトあたりの料金を完全に排除できますが、運用の管理が必要です。出口フィルタリングを備えたフラット価格のネットワーク仮想アプライアンス (NVA) は、NAT ゲートウェイのマネージドな代替品を提供し、ギガバイトあたりの料金を

How to reduce AWS NAT Gateway costs: 7 ways, ranked by savings dev.to

RSS Hunter • 昨日

コンテンツが良いか悪いかをどのように判断しますか？

著者は、dev.toプラットフォームにおけるAIの利用増加とその影響について論じています。一般的な意見としては、AIの使用よりもコンテンツの質が重要であるとされていますが、著者はこの文脈で「良い」コンテンツをどのように定義するか疑問を呈しています。AIは有用で洞察に富んだ資料を容易に生成できるため、真の理解を見分けることが困難になります。著者は、プロジェクトにAIを使用する開発者との類似性を指摘しており、それらは紙面上では印象的であっても、リアルタイムで自分の仕事を説明するのに苦労することが多いと述べています。これは、AIに過度に依存することの潜在的な欠点を浮き彫りにし、真の学習とスキル開発を妨げます。著者は、AIへの過度の依存に対する個人的な懸念を表明しており、それが自分の仕事の学習能力と自信を持って説明する能力を損なうことを恐れています。真の専門知識は、自分の創造物を理解し、それを明確に説明できることから生まれると著者は主張しています。著者は、dev.toのようなプラットフォームの目的は、AI生成コンテンツを個人的な専門知識として提示することではなく、真の学習と共有を促進することであると示唆しています。著者は、AIを建設的に使用するための2つの主要な推奨事項を提案しています。それは、単に情報を暗唱するのではなく、拡張的な質問をすること、そしてAIを学習を置き換えるのではなく支援する補助的なツールとして使用することです。このバランスの取れたアプローチは、個人の成長を確実にし、コミュニティ内での有意義な交流を促進します。中心的なテーマは、実践による学習とAIへの過度の依存の回避です。最終的に、dev.toにおける良いコンテンツは、トピックに関係なく、著者と読者の間の相互学習を促進すべきです。

How would you decide, whether the content is good or bad? dev.to

RSS Hunter • 昨日

無限の自動化を解き放つ：Google Apps ScriptとGemini Sparkの統合

Gemini Sparkは、Google Workspace全体で複雑なワークフローを自動化するために設計された、Googleの24時間年中無休の自律型AIエージェントです。Gmail、Drive、Docsなどのアプリケーションとの堅牢なネイティブ統合を提供しますが、外部APIへの接続には追加の設定が必要です。Google Apps Script（GAS）は、企業がGemini Sparkの機能を大幅に拡張することを可能にする重要なブリッジとして機能します。GASをModel Context Protocol（MCP）サーバーまたはWebhookエンドポイントとしてデプロイすることにより、ユーザーはGemini Sparkに専門的なAPIおよびカスタムビジネスロジックへのアクセスを許可できます。この記事では、Gemini Sparkのネイティブ機能を示す5つの代表的なプロンプトを紹介します。これらには、動的な数式を含むスプレッドシートの自律的な作成、Google Drive内でのファイルのインテリジェントな検索、Webスクレイピングからドキュメント生成までのクロスドメインワークフローのオーケストレーションが含まれます。また、受信メールの処理などのタスクのためのバックグラウンドイベントリスナーを自律的にセットアップするGemini Sparkの能力も強調しています。しかし、Google Analytics Data APIへの直接アクセスを含むテストプロンプトは、専門的なGoogle APIへのネイティブ接続における現在の制限を明らかにしました。これらのネイティブの境界を克服するために、この記事ではカスタムMCPサーバーおよびWebhookトリガーを介したGemini SparkとGoogle Apps Scriptの統合について詳しく説明します。GAS Web AppをMCPサーバーとしてデプロイし、GASADKおよびGoogleApiAppライブラリを活用してJSON-RPC通信を容易にする方法を説明します。この統合により、Gemini SparkはGoogle Analytics 4、カスタムデータベース、その他の複雑なビジネスロジックなどのAPIと安全にやり取りできます。GASを仲介MCPサーバーとして使用することで、開発者は安全な認証およびデータ抽出ロジックをカプセル化できます。最終的な目標は、Gemini Sparkがより広範なデータソースおよびサービスにアクセスすることにより、エンタープライズグレードのワークフロー自動化を実行できるようにすることです。

Unlocking Infinite Automation: Integrating Google Apps Script with Gemini Spark dev.to

RSS Hunter • 昨日

LINE MINI App 検証レビュー：手戻りを防ぐための提出前チェックリスト

LINE MINI Apps は自動的に認証を必要としませんが、特定の機能は公開のために認証を義務付けています。認証が必要な場合、LINE は本人確認の一貫性、ポリシー遵守、チャネル設定、ユーザーフローを綿密に審査します。遅延を避けるためには、審査をリクエストする前に提出物を徹底的に監査することが重要です。認証が必要な主な機能には、本番サービスメッセージ、カスタムパス、ホーム画面ショートカット、共通プロフィールクイックフィル、および認証済みバッジが含まれます。提出前に、LINE Developers Console、チャネル情報、プライバシーポリシー、チャネル説明全体で組織のアイデンティティを一致させてください。これらのすべての場所と言語で会社名が一貫していることを確認してください。MINI App のワークフローを明確に説明し、主要なユーザー、コア機能、および期待される結果を特定してください。審査チャネルが公開チャネルの機能、遷移、データ、認証、およびエラー状態を正確に反映していることを確認してください。登録、成功および失敗したトランザクション、データ管理を含む、支払い、予約、および注文のための包括的なテストシナリオを準備してください。公開アクセス可能性、会社名およびサービス名の一貫性、および正確な連絡先情報について、プライバシーおよび利用規約ページを徹底的に確認してください。MINI App のビジネスカテゴリおよびコンテンツが LINE のポリシーに準拠していることを確認し、制限されたカテゴリおよび禁止されたコンテンツを避けてください。必要な API スコープのみをリクエストし、その使用法を文書化してください。サービスメッセージは個別の承認プロセスを必要とし、プロモーションではなく、ユーザーアクションへの確認または応答専用です。認証後、多くの設定は再審査に敏感になるため、最初の提出前にチャネルアイデンティティ、法的 URL、およびスコープなどの重要な構成をフリーズしてください。通常 1 ～ 2 週間かかる認証タイムラインを計画し、潜在的な再審査のためのバッファを含めてください。最後に、MINI App の認証は、受信した顧客メッセージの処理とは別であることを覚えておいてください。

LINE MINI App Verification Review: A Pre-Submission Checklist That Prevents Rework dev.to

RSS Hunter • 昨日