タグ

Sphinxに関するsgwr1129のブックマーク (3)

  • WebRTC SFU Sora ドキュメント

    2023.2.x から 2024.1.x への移行 レガシー録画機能から新しい録画機能 (セッション単位) への移行 レガシーストリーム(非マルチストリーム)機能からマルチストリーム機能への移行 リリースノート 用語集 既知の問題 実験的機能 非推奨機能 廃止機能 問い合わせ (サポート) FAQ トラブルシューティング Sora が期待どおりに動かない場合、または、動作に問題がある場合 Sora の仕様や使い方に関して質問がある場合 サポートライフサイクル 設定 チュートリアル 番稼働に向けて ライセンス ログファイル sora.conf リファレンス systemd Linux カーネルチューニング IPv6 での動作について メタデータ センシティブデータ アプリケーション連携 アプリケーション連携チュートリアル シグナリング WebSocket 経由のシグナリング DataCha

  • 技術ドキュメンテーションのためのreStructuredTextとMarkdownを比較する | POSTD

    Markdown と reStructuredText はどちらもマークアップ言語で、どのテキストエディタを使っても簡単に入力できるように設計されたプレーンテキスト形式構文です。どちらにもマークアップされたテキストをHTMLPDFなどの出版形式に変換できるツールが多数あります。 これらのマークアップ言語は多くのドキュメンテーションシステムの基礎となるため、昨今のソフトウェア開発者はマークアップ言語をよく知っておく必要があります。この記事ではプログラマ視点でMarkdownとreStructuredTextのトレードオフを分析します。 Markdownが輝きを放つ場所 テキスト入力による豊富な書式設定で複雑なドキュメント構造を記述することができるマークアップ言語は長く輝かしい歴史を持っており、その歴史は少なくとも1970年代初めの troff とTeXまで遡ることができます。 これらの形式

    技術ドキュメンテーションのためのreStructuredTextとMarkdownを比較する | POSTD
  • ドキュメント駆動開発v2

    前提 ここで言っているドキュメントは仕様書ではなく、顧客向け製品ドキュメント。 ミドルウェア製品を開発 小さなチーム パッケージ製品とパッケージ製品のクラウド版 そのため顧客に提供するドキュメントが必ず必要 GitHub を利用 自分で開発する場合のフロー 作りたい機能をぼんやりでいいので GitHub Issue に追加する feature ブランチを切る デザインドキュメントをリポジトリの doc/ 以下に書く デザインドキュメントに合わせてコーディングを進めてなんとなく動くところまで作る 動かなくてもいいのでイメージを膨らませるためにコードを書いてみる デザインドキュメントは書き捨て前提で、とにかくメモを書く 製品ドキュメントを書き始めて、一旦書き終える ブランチマージに向けてコーディングを進める 書ける範囲でテストを書く ドキュメントを平行して修正する プルリクエストをだしてレビュ

    ドキュメント駆動開発v2
  • 1