← 2026-01-31 の一覧へ戻るホーム
**製品のようにドキュメントを構築する**

2026/01/30 6:11

**製品のようにドキュメントを構築する**

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

Summary

Scour のドキュメントは、単なる静的な API 参照や SDK ガイドではなく、動的でユーザー中心のリソースとして設計されています。ログイン状態に応じて変化するライブ検索バー、トグル、およびリアルタイムのトピック推奨機能を埋め込み、ユーザーがドキュメント内で直接コンテンツをフィルタリングできるようにしています。このインタラクティブなアプローチは、Hacker News（フロントページに掲載されていない投稿のライブ検索バー付き）、Reddit、Substack、および arXiv などのセクションでも同様に反映され、読者はドキュメントページから直接カテゴリを検索したり購読したりできます。
「Interests」ページでは、ランダムでユーザーが追加したトピック一覧が表示され、1つをクリックするとそのコンテンツページへ遷移します。ログイン済みのユーザーは、ドキュメント内でリアルタイムにトピック推奨（例： “Graphic Design”）を受け取り、コンテンツフィルタリングなどの設定もドキュメントページから直接変更できます。
これらコミュニティからのフィードバックにより、Scour のランキングアルゴリズムに関する詳細な説明が追加され、将来のアップデートでは “MASH stack” コンポーネントを使用したライブ例を強化することが目指されています。
個人ユーザーと広範な開発者エコシステムの両方にメリットをもたらすために、Scour はパーソナライズされた推奨とインタラクティブツールをドキュメントに統合し、Rust の 

axum‑extra
TypedPath トレイトを通じてリンクロトリスクを低減しつつ、開発者に即座に関連情報へのアクセスを提供します。

本文

2026年1月29日

Stripe は「アプリケーションのように感じさせる」設計で、従来型のユーザーマニュアルよりも優れた製品ドキュメントを提供していることで有名です。先週は Scour のドキュメント作成と執筆にほぼ専念し、その成果に自信を持っています。

インタラクティブドキュメント

Scour は SDK や API ではなく、個人化されたコンテンツフィードです。
コードやコピー可能なスニペットの代わりに、実際に動くインタラクションをそのままドキュメント内で構築しています。

Hacker News の隠れた宝石を探す

Hacker News 読者向けガイドは私のお気に入りの一つです。起源として「自分の興味に関連する投稿を、数千件中でフロントページに載らないものから抽出できるツール」が欲しかったことを語ります。

ガイド内には、フロントページに掲載されていない HN 投稿を検索するライブサーチバーが組み込まれています。
ぜひ試してみてください！ 隠れた宝石を発見できるかもしれません。

Reddit 使い、Substack 読者、arXiv 利用者向けのガイドも同様にインタラクティブ要素が含まれており、サブレディットやニュースレター、arXiv のカテゴリを検索・購読できます。ログイン済みユーザーはドキュメントから直接フィードを購読できます。

「示す」＝「語る」より

Scour の機能を説明する際は、常に実際に動く例があるかどうかを確認しています。

  • 興味ページ – 追加できるトピックは自由形式のテキストです。各ロード時にランダムで人々が追加した興味セットが表示され、一つをクリックするとそのトピックに関連するコンテンツが開き、自分も追加できます。
  • トピック推奨 – ログイン済みユーザーには実際の推奨（例：私の場合は Graphic Design）を提示しています。

設定はリンクではなく、直接操作

ドキュメント内で設定ページへのリンクを貼る代わりに、ログイン済みユーザーはドキュメントから直接設定を変更できます。
例として コンテンツフィルタリング ページでは「有料コンテンツを隠す」オプションをドキュメント内でトグル可能です。

実際のコンポーネントを使用

ライブ例はすべて Scour 本体と同じ MASH スタックで構築されたコンポーネントを使用しています。たとえば、投稿がどのフィードに表示されるかを示すセクションでは、複数フィードから最新の投稿を取得し、「…」をクリックするとその下にあるフィード一覧が展開します。

実際のコンポーネントで例示

ログインしていないユーザー向けにプレースホルダーが必要な場合、コードを分岐させる代わりに元々のコンポーネントをリファクタリングし、静的例でも動作するようにしました。

破損リンクは存在しない

使いやすいドキュメント体験を完成させる最後のステップは、破損リンクが一切ないことを保証することです。Scour は Rust の axum HTTP ルーティングライブラリを使用しています。

axum-extra
クレートの 
TypedPath
トレイトと derive マクロにより、構造体として定義したルートをルーティングだけでなくリンクにも利用できます。

use axum::Router;
use axum_extra::routing::{TypedPath, RouterExt};
use serde::Deserialize;

#[derive(Deserialize, TypedPath)]
#[typed_path("/docs/interests")]
pub struct InterestsPath;

async fn interests(_path: InterestsPath) { /* … */ }

#[tokio::main]
pub async fn main() {
    let router = Router::new()
        .typed_get(interests);
}

ドキュメント内で興味ページへのリンクが必要な場合は次のようにします。

use crate::docs::InterestsPath;

async fn other_docs() {
    let interests_path = InterestsPath.to_string();
}

Rust の型システムが、パスが変更されてもリンクが常に最新であることを保証してくれます。

フィードバック

ご覧いただきありがとうございます！ 何人かのユーザーから「Scour がどのように動作するか説明したページ」を求められており、今回のドキュメントは Scour のランキングアルゴリズムとその他想定される項目を詳細に解説しています。
ぜひフィードバックをいただき続けてください。ドキュメントを読んだ後でも疑問点が残っている場合は、お知らせいただければ改善します。

Hacker News や Lobsters でのディスカッションも歓迎です。

#scour

同じ日のほかのニュース

一覧に戻る →

2026/01/31 9:51

**Show HN:** 私は自分の中国語（普通話）の声調を直すため、9Mパラメータの音声モデルを訓練しました。

## Japanese Translation: > **概要:** > AISHELL‑1 と Primewords から約300時間分の文字起こし済み中国語音声を用い、SpecAugment と4台の RTX 4090 GPU を使用して、約9 Mパラメータのコンフォーマーモデル（Conformer）を訓練しました。ネットワークは40 msごとにトークン確率を出力し、Viterbi アルゴリズムでピンイン音調トークン列（各音節＋音調がユニークなトークン；中性音調はトーン5へマッピング）に沿ってアラインメントを強制します。語彙には1,254個のトークンと `<unk>`、`<blank>` が含まれます。 > このモデルでは Token Error Rate（TER）が約 5.3 %、音調精度が約 98.3 %です。INT8 量子化によりサイズを約37 MB から約11 MB に縮小し、TER は +0.0003 の増加のみで済みました。先頭の無音によるアラインメントミスを修正するため、 `<blank>` 確率が0.7 を超えるフレームは採点前に除外しました。 > 最終的な量子化モデル（約13 MB のダウンロード）は ONNX Runtime Web 経由でブラウザ上で完全に実行され、リアルタイムの発音フィードバックを可能にします。今後は Common Voice などの会話データセットを取り入れ、カジュアルまたは子供の話し言葉（通常より速く変動が大きい）に対する頑健性を向上させる予定です。 **短縮版（すべてのポイントを網羅）:** > **概要:** > AISHELL‑1/Primewords から約300時間分の中国語音声で、SpecAugment と4× RTX 4090 を用いて9 Mパラメータのコンフォーマーを訓練しました。40 ms ごとにトークン確率を出力し、ピンイン‑音調語彙（1,254トークン＋`<unk>`、`<blank>`）で Viterbi アラインメントを行います。TER は約 5.3 %、音調精度は約 98.3 %です。INT8 量子化によりモデルサイズが約11 MB に縮小され、TER は +0.0003 の増加のみでした。先頭無音のバグは、高い `<blank>` 確率（閾値0.7）を持つフレームを除外することで修正しました。13 MB の ONNX Runtime Web バージョンはブラウザ内で完全に動作し、即時発音フィードバックを提供します。将来的には会話データを追加してドメインシフトへの対処を図ります。

2026/01/31 5:40

ペアウェブ：WebTorrent を利用した分散型ウェブサイトホスティング

## 日本語訳: PeerWebは、WebTorrent技術を利用したピアツーピア（P2P）ネットワーク上で静的ウェブサイトを無料かつ検閲耐性のある形でホストできるサービスです。サイトはトレントハッシュ経由で配布され、少なくとも1人のユーザーがブラウザタブまたはデスクトップクライアントを開いている限りオンラインに留まります。 **動作原理：** - ユーザーはインターフェースにファイルをドラッグ＆ドロップするだけで、シンプルなHTML/CSS/JSプロジェクトをアップロードできます。各サイトにはユニークなPeerWebリンクが付与され、どこからでもアクセス可能です。 - サイトは `index.html` ファイルを必ず含み、相対パスのみを使用し、静的コンテンツで構成されている必要があります。 - キャッシュ前に PeerWeb は DOMPurify で全ファイルをサニタイズし、XSS 攻撃から保護します。 - キャッシュされたサイトは IndexedDB に保存され即座に再読み込みが可能です。キャッシュは7日間の非アクティブ後に自動的にクリアされます。 **セキュリティとパフォーマンス：** - コンテンツはサンドボックス化された iframe 内でレンダリングされ、リソース検証によって正当な資産のみが表示されます。 - 開発者はデバッグモード（`&debug=true`）を有効にして詳細な進行状況とリアルタイムメトリクスを確認できます。 **使用例：** デモリンクではテストページ、SomaFM ラジオ、チェスゲーム、およびテキストエディタアプリが紹介されています。 多くのピアにコンテンツを分散させることで、PeerWeb は従来のホスティング費用なしでサイトを利用可能にし、キャッシュによる高速ロードとマルウェアからの保護を提供しつつ、検閲にも耐えます。

2026/01/31 8:47

**Stonebraker氏のCAP定理とデータベースに関する論考**

## 日本語訳: **要約：** マイク・ストーンブレーカー氏は、CACMブログ記事「データベースシステムにおけるエラー、最終的な一貫性、およびCAP定理」で、CAP定理が最終的一致性を強制するという広く受け入れられているNoSQLの見解に挑戦しています。彼は、多くのデータベース障害はネットワーク分断ではなく、アプリケーション、管理、実装上のバグから生じており、実際にはパケット損失や設定エラーなど他のネットワーキング欠陥と比べても稀であると主張しています。ストーンブレーカー氏は、2ノード冗長スキームが大規模では不十分であり、業界が最終的一致性に依存することで実際の問題を隠してしまう可能性があると指摘しています。 彼はAmazon SimpleDB が最近完全一致性へ移行したことを、高いスケールでも厳密な正確性を保証できる証拠として挙げ、実用的な緩和策として「遅延削除」（削除マークを付けてからガベージコレクションを遅らせる）を提案しています。ストーンブレーカー氏は完全一致性を早期に放棄すると微妙なバグが発生し、運用リスクが増大する可能性があると警告しています。 この記事はNoSQLコミュニティに対し、多くのワークロードで最終的一致性が適切かどうかを再検討し、強い一致性が大規模でも達成できることを示唆しています。

**製品のようにドキュメントを構築する** | そっか～ニュース