Smart Content Dependency Management™の概要

[ホワイトペーパー] 最終更新日によって Joe Schaefer 金, 29 5月 2026 ソース

ツリー

抽象画

スマート・コンテンツ依存性管理™は、コンテンツ正規化原則に忠実でありながら、インクリメンタル・ビルドのサポートとファシリテーションの提供に関連するアイデアの円周です— についてパーマリンク コンテンツがソース・ツリー全体でどのようにキュレーションされ、結果のビルド・アーティファクトであっても、信頼できる唯一の情報源である必要があります。

この記事は、https://iconoclasts.blog/ 関連するグラフトポロジのベストプラクティスと分析のデモのためのケーススタディとしてのウェブサイト。

注意事項

これは、Webページ上のコンテンツを微調整する必要があるたびに、フルサイトの構築にかかる費用を比較検討する必要がある場合にのみ重要です。Webサイトのソース・ファイルが1K未満の場合はrelax、将来のニーズに注意して次をお読みください。貴社は、貴社ではなく貴社に合わせて拡張できるよう設計された当社のプラットフォームを使用することを選択しました。ほとんどのページでは、次の資料は、1Kページを超えるサイトの疎コンテンツ依存性グラフについてです。

例えば、The Apache https://www.OpenOffice.Org ウェブサイトは、このビルドシステムの元のApacheバージョンを使用して40K+ファイルを構築することができ、増分ビルドを完全に統合しました— 構成された依存関係がない— 従来のSSIテクノロジーだけを賢く利用する。

デフォルトでは、ビルド・システムでは、変更したファイルのみがビルドされ、ファイル内依存関係は考慮されません(指定しないかぎり)。%path::dependencies — 以上が下)。変更したファイルがtemplates/ またはlib/ 代わりに、完全なサイトビルドがトリガーされます。

あなたのウェブサイトの依存関係のグラフを一緒に編みます

数学的にトポロジ $\tau$ は、スペースのopenサブセットの完全指定です $X$ の目的は、points間の近接関係を示すことです。 $x$ スペースについて $X$ 。次の場合 $X$ グラフであるトポロジ $\tau$ 対象 $X$ グラフの頂点を接続するエッジを指定する量(ここでは、頂点はポイントとして表示されます) $X$ 、および接続エッジは、これらの点の近傍をトポロジのbasis open setsとして決定します。方向グラフ・トポロジは基本的に同じですが、位相埋込みへの参照が組み込まれています。 $(X,\tau)$ より大きな地質空間へ $(Y,\sigma)$ 埋め込みのエッジ接続は、方向、非交差(ヨルダン)カーブで表されます。

後者の概念は、dependencyグラフのトポロジについて説明する際に利用する概念です。 $\tau$ スペースに関連付けられている $X$ サイトのソースファイルの数content/ サブディレクトリ $(Y,\sigma)$ 次である $\mathbb{R}^n$ 次のメトリック・トポロジを使用します。 $n \in \{2,3\}$ のエッジと $X$ は、ファイルを接続する非交差、指示されたヨルダン曲線です $x \in X$ ファイルのセットに対して $x$ 依存: $\set{x^\prime \in X | x \rightarrow x^\prime}$ ).

取得Webサイトの依存関係グラフを明確に理解することで、当社の構築テクノロジのパフォーマンスを大規模に最大化できます。ご提供いただいた情報を%path::dependencies あなたのウェブサイトのビルドロード中にlib/path.pm ファイル、依存ファイルの逆マップを構築し、その逆マップを使用して、任意の指定のために構築するファイルの完全なコーパスを決定しますsvn commit あなたは私たちのシステムを作ります。

ソース・ファイル間の依存性関係は、%path::dependencies ビルドシステムの起動時のハッシュlib/path.pm あなたのソースツリーから、私たちの中に含まれているビルトインビューSunStarSys::View Perlパッケージは動作します。▲walk_content_tree, archivedおよびseed_file_deps インポート元のユーティリティ関数SunStarSys::Util は、%path::dependencies 大規模な増分ビルドを高速化するために依存関係キャッシュを管理するための組み込みのサポートを備えたハッシュ。

Here’s That Part Of Our Liveシングルlib/path.pm:

our (%dependencies, @acl);

# entries computed below at build-time, or drawn from the .deps cache file

walk_content_tree {

  $File::Find::prune = 1, return if m#^/(images|css|js)\b#;

  return if -d "content/$_";

  seed_file_deps, seed_file_acl if /\.(?:md|ya?ml|csv)\b[^\/]*$/;

  my $path = $_;
  utf8::is_utf8 $path or utf8::decode $path;
  state $count = 0;
  for my $lang (qw/en es de fr ru sv he zh-TW ar ko ja pt-BR/) {
    delete $dependencies{"/sitemap.html.$lang"} if ++$count <= 12;
    next if m!\.page/!;
    if (/\.md\.$lang$/ or m!/index\.html\.$lang$!) {
      push @{$dependencies{"/sitemap.html.$lang"}}, $path if !archived;
    }

    if (/^(.*)\.tex\.$lang$/ and -f "content$1.bib.lang") {
      push @{$dependencies{$path}}, "$1.bib.$lang";
    }

    if ($path =~ s!/index\.html\.$lang$!!) {
      $dependencies{"$path/index.html.$lang"} = [
        grep {utf8::decode $_; s/^content//}
        glob("'content$path'/*.md.$lang"),
        glob("'content$path'/*/index.html.$lang")
      ];
    }
  }
}
  and do {
    while  (my ($k, $v) = each %{$facts->{dependencies}}) {
      $dependencies{$k} = [grep $k ne $_, grep s/^content// && !archived, map glob("'content'$_"), ref $v ? @$v : split /[;,]?\s+/, $v];
    }

    open my $fh, "<:raw", "lib/acl.yml" or die "Can't open acl.yml: $!";
    unshift @acl, @{Load join "", <$fh>};
    my %cache;
    @acl = grep !$cache{$_->{path}}++, @acl;
    for (glob("content/*/index.md.*")) {
        next if /archives|categories/;
        s!/index\.md\.[^/]+$!!;
        push @acl, { path => $_, rules => {
             '@bloggers'  => 'rw',
             '@svnadmin' => 'rw',
             '*' => 'r',
        }} unless $cache{$_}++;
    }
  };

あなたのウェブサイトをどのように動作させるかについてのアイデアのために、そのコードを引き渡してください。はい、いくつかの合理的な複雑さがあります(Perlの正規表現とPerlのUNIX Cシェルの両方を含む) glob インターフェイス、非常に正確な方法) %path::dependencies これは、そのファイルに構築されますが、最適化作業として表示するのではなく、動的に生成された自動化された方法でlinkトポロジ*の主要な側面を制約するために必要な基本成分を提供していることを確認してください。

エントリの場所%path::dependencies 起源? 発生していない場合は、walk_content_tree { seed_file_deps ... }(基本的に、マークダウン・ソース・ファイルのヘッダーおよびコンテンツにダイブする)は、次のようにハードコードされます。lib/facts.yml ロード時に。

循環依存関係グラフは標準

現在のサイトは、2417 source files 場所content/。こちら100+ vertices x 600+ edgesこのサイトの英語ページ依存関係の最新のスナップショットのスクロール可能な2次元指向グラフ表現(GraphVizの使用dot):

英語の依存関係

かなり複雑で、こんな小さなサイトでも! テイク時に多くのエッジ交差 $n=2$ (寸法は不可) $n=3$ ). 特に注記は、当社のサイトの非アーカイブファイルにおける密で循環的な依存関係のコアセットです/essays/ ディレクトリ。グラフの中央右下に向かって、これは良いブログサイトの依存関係グラフのように見えるはずです。これらの依存関係は、red curves イメージで。

また、要素の内部で本質的に分離された相互接続性にも注意してください。/categories/*/* および/archives/2026/05/*。唯一の外部依存関係には、アーカイブされていないコンテンツが含まれます。/joe/*。これは設計によるものです— アーカイブされたエッセイは、おそらくそのエッセイの調整のためにのみadiabaticallyを変更する必要がありますCategory ヘッダー。これらの変更は、既存のコンテンツに重大な影響を与えないため、%path::dependencies.

もちろん、Orion Enterprise Wiki 循環依存に対処するのに苦労したことはない。

これはハイパーリンクだけではないでしょうか。

*いいえ!*実際、Webサイトのリンク・トポロジ*は、ソース・ツリーの依存関係グラフとはまったく別の問題です。検索エンジンは、linkトポロジを自然に解き放ちますが、dependencyグラフ*に関する洞察はありません。

こちら16k+ vertices x 90k+ edges当サイトの英語リンクトポロジグラフの現在の鳥目grqaphGraphVizの使用twopi):

English日本語

見つけられるかred edges dependency graphで指定されている。リンク・トポロジグラフは、前述の(劇的に小さく、相互接続されていない)依存性グラフとは、定性的および定量的に**非常に異なります。

SSIテクノロジーがどのように役立つか

従来型サーバー側インクルード (SSI)

Webサイトの依存関係グラフを、ページ配信レイテンシを犠牲にすることなく管理可能なサイズにプルーニングするための優れた
**大きなコミット・メッセージのボイラープレート・チャーンを減少させることで、構築された変更セットのピア・レビューと監視を改善
lousy (ドキュメント・ルートの階層内の別の場所にWebページ全体を再コンテキスト化する場合)

テンプレートAPI

ssiタグ

Syntax:

{% ssi `/content_rooted/path/to/source_file` %}

ルートのパスcontent ソース・ディレクトリ
ソース・ファイルのヘッダー部分をスキップします。ssi 含む
ターゲット・パスに含まれるコンテンツの絶対URLに相対URLを書き換えます。

ssiフィルタ

Syntax:

再帰的に評価ssi フィルタする値のタグ
大きい値(3+)の使用を避けるために有用quick_deps A @path::patterns entryの引数hashref。パフォーマンスに影響する可能性があります。

SymLinksを使用しない理由

安全にサポートすることが難しいファイルシステムの抽象化<VirtualHost> コンテキスト
伝統的な同じダウンサイドssi ウェブページ全体
私たちのOrion Enterprise Wiki システムはそれらをサポートしていません

パーマリンク用のビルドツール

文書キュレーション

Orionのビルドシステムは、私たちが「Document Curation」と呼ぶものに対する統合的なサポートを持っています。これは、あなたがどのように設定したかに基づいて、コンテンツを再テキスト化して再編成するプロセスです。Categories およびStatus Markdownソース・ファイルのヘッダー。これらの機能はデフォルトで無効になっていますが、category_root (カテゴリ・サポート用)またはarchive_root (アーカイブサポート用)関連するhashref引数で目的@path::patterns 入力。

アーカイブされたページ

当サイトでは、古いエッセイを積極的にアーカイブして、新しいエッセイのビルド時間を低くし、アーカイブされたドキュメントへのパーマリンクを破壊しません。依存グラフ /archives/ ディレクトリ(当社のサイト用)は、次のルールに従って合理的に自己完結しています。

テンプレートを使用して作成されたコンテンツssi パーマリンクの場所を指し示すタグ、Categories 構築されたソース・ページからのヘッダー
コンテンツ/(essays|clients)/ アーカイブ後も常にパーマリンクです。
アーカイブにより、パーマリンクの場所が依存関係グラフから効果的に削除されますが、パーマリンク自体はウェブサイトから削除されません

Lede

Markdownに埋め込まれたHTMLコメントは、LEDEコンテンツのフォーム境界を提示します。使用**{引合番号}*この目的のため。

導線の処理は、lede テンプレート・フィルタこれと結合すると便利です。ssi 複数のカテゴリ・ページを含むカテゴリ・ファイルを索引付けするためのフィルタ。

結論

構築パフォーマンスの観点から、Webサイトの依存関係グラフを扱う際には、興味深いデータ構造と関係がまだ明らかにされています。これは、データ構造とリンクトポロジを取り巻く関連問題に関する研究文献よりもはるかに新しい関心分野です。^1,2.

純粋なソフトウェア開発プロジェクトのための従来のインクリメンタル・ビルドはまだホット・トピックです。調査対象^3,4 2022年10月に、このエッセイが完了する約1ヶ月前に発表されました。pluto⁵ ビルド・システムには、当社の機能とほぼ同じ機能があります(ビルド自体は、依存関係を動的に再生成および再構築できます)。

良いニュースは、私たちがお客様としてカバーしていることです。私たちは、この分野におけるベストプラクティスとアートの状態を常に把握しますので、過去10年間、そして明日にかけて学んだ私たちの教訓から利益を得ることができます。

##脚注

リンク・トポロジに基づくWebグラフ内のクラスタの識別 2003年第7回国際データベース工学・応用シンポジウム手続き
リンク・トポロジからのWebコミュニティの推測ハイパーテキストとハイパーメディアに関する第9回ACM会議の進行: リンク、オブジェクト、時間とスペース— ハイパーメディアシステムの構造: リンク、オブジェクト、時間と空間— 1998年ハイパーメディアシステム
増分ビルド・ソフトウェア構成の利点と限界について: 調査研究 ICSE ‘22: 2022年5月、第44回ソフトウェア・エンジニアリング国際会議の進行
ソフトウェア構成の増分構築に向けて ICSE-NIER ‘22: Proceedings of the ACM/IEEE 44th International Conference on Software Engineering: New Ideas and Emerging Results 2022年5月
動的依存関係を持つサウンドと最適なインクリメンタルビルドシステム OOPSLA 2015: オブジェクト指向プログラミング、システム、言語、およびアプリケーションに関する2015 ACM SIGPLAN国際会議の進行2015年