用語
YDA
YDA（ウァイ・ディ・エイ）は、Yamato Daiwa Automationと言う此の説明書サイトの対象 と成っているツールの省略名。 此処で「Yamato Daiwa」は 株式会社やまとダイワ に参照し、カスタムウェブ開発、そしてエンジニア育成及びフレームワークやYDAを含むツールの開発に専門している。 日本語の資料では「やまとダイワ自動化」と日本語名でも表記する。
プロジェクト
プログラム文脈に於いて、具体的なディジタル製品（ウェブサイト、ウェブアプリケーション、コンソールアプリケーション、ネイティブアプリケーション、 ライブラリ等）の開発に必要で、共通の親ディレクトリを持っているファイル 及びフォルダの揃いである。 やまとダイワ自動化は個別のファイルではなく、プロジェクト専用のものだ。
プロジェクト構成
「過程」及び「ファイルの揃い」と言う２つの意味が有る。
- 過程としてプロジェクト構成はソースコード及び其の他の材料ファイルを元に 出力ファイルの生成である。 此の過程は、やまとダイワ自動化がしている中に主な事である。
- ファイル揃いとしてプロジェクト構成は全ての出力 ファイルの揃いである。 此のファイルの揃いは常に「構成ディレクトリ」と呼ぶ共通ディレクトリの下に出力される事が多いが、やまとダイワ自動化はこう言った 規制は無い。
どれの技術でもプロジェクト構成概念が有るとか限らない。 例えばウェブサイト又はウェブアプリケーションは純粋HTML、CSSと PHP（最後の奴は解釈されるプログラミング言語、詰まりファイルはコンパイルせずに直接実行される）で作られた場合、 構成するものは無い。 やまとダイワ自動化だと、Pug、Stylus、 とTypeScript言語専用なので、そろぞれHTML、CSS とJavaScriptに変換されなければいけない。 其の他に、元の画像ファイルと出力画像ファイルは最適化の為異なる事も有る。 ソースファイルを処理せずにそもままで構成に使えば良い時、ソースファイルと出力ファイルを交ぜない様に、一般コピーを設定する事も可能。
課題 (Task)
プロジェクト構成文脈の於いて、課題はプロジェクトの構成自動化の中に コンピューター専用の特定の仕事。 やまとダイワ自動化が専門している課題の中に、下記の項目は主だ。
- Pug言語で書かれた構造設計記（マークアップ）の処理
- Stylus言語で書かれた意匠設計記法（スタイルシート）の処理
- TypeScript言語で書かれた挙動制御記法（ロジック）の処理。 当言語はプリプロセッサで呼ばれる事は少ないが、此れのインタプリタが普及されない限り、事実上プリプロセッサ言語である。 ブラウザー専用JavaScriptにも、Node.jsにも変換（トランスパイリング）可能。
- 画像の処理
- 活字、動画、オーディオ及び其の他の種類のファイルのコピー
- プロジェクト処理構成に応じてブラウザーの自動起動及び出力コードの更新に応じてブラウザーのページの自動リロード
- プロジェクト処理構成に応じてNode.jsサーバの自動起動及び出力コードの更新に応じて此のサーバの自動再起動
作業順序・シナリオ（Scenario）
YDA及びGulpの様にプロジェクト構成手段の文脈に於いて]、作業順序（シナリオ）は順番・並行で並べてある 課題の揃いである。
正常可能、パフォーマンスの最適化、両方課題の正しい並び順に依存している。 例えば、構造設計記法（マークアップ）の処理は其の他の種類のファイルの処理が終わってからでなないと、 意匠設計記法（スタイル）や画像等にパスの算出が可能。 そして、ブラウザーの自動起動、構造設計記法を含めて全てのファイルの処理が出来てからにしなければいけない。
YDAはGulpに比べてより高水準の手段なので、利用者にとって 課題を順番・並行で並べる事に就いて構う必要は無く、利用可能な 作業順序を知るだけで良い。
現在、YDAは下記の作業順序を提供している。
- プロジェクト増分構成 (Incremental building of project)
- 先ずは完全なプロジェクト構成が実行され、其の 後、ソースファイルの編集の更新と共に選択的な再構成が行われる。 此の様に、アプリケーションは手動停止されられないか、致命的なエラーが発生する迄に実装し続けられる。 必要に応じて、プラウザーの自動起動（プロジェクトにフロントエンド部分が有る場合）若しくはローカルサーバ自動起動 （プロジェクトにNode.jsバックエンド部分が有る場合）が設定出来る。
- 納品系 (Production-like building of project)
- プロジェクトが完全に構成されてから、YDAが正常 終了する。 此のシナリオの用途上、ブラウザーページの自動リロードの様な機能は、此の作業順序には無い。
プロジェクト構成モード（Project building mode）
両方の作業順序は複数のプロジェクト構成モードで行われ、 各モードは特定が有る。 YDAは下記の5件のプロジェクト構成モードを提供。 ウェブサイトか、GUIアプリケーションの開発の場合、当モードを段階として見做しても良いが、 プロダクト全体開発の段階ではなく、特定の一ページ又は特定の機能の開発の段階である。
- 増分（Incremental）
プロジェクト増分構成作業順序に該当。 此の作業順序通り、先ずプロジェクトの完全な 構成が行われてから、ソースコードの変化と共に、自動的に変わった分だけ再構成される。 全てのプロジェクト増分構成モードにとって、プロジェクト構成ツールから良い パフォーマンス最適が求められる。 尚、ウェブサイトとGUIアプリケーション開発の場合、ブラウザーの自動的なページリロードや、其の他のプロダクト開発を便利にしている 対策が需要と成り、HTMLコード妥当性違反の様に様々な問題に就いて可能な限り早い通知を含む。
- 静的プレビュー（Static preview）
- 開発者が完全にマーカップ及びスタイルのみに集中 している様な開発の段階として考案され、JavaScript挙動且つサーバ側の開発は其の次の 段階と成っている。 此の様に、当プロジェクト構成モードの対象はウェブサイトとGUIアプリケーションだけ。 プロジェクト構成ツール宛ての要求は、
技術知識やnpmやGitの様にエンジニア向けソフトウェアが無くても 、依頼側や経営側に依り出力ファイルがブラウザーに開かれた際、画像や其の他の復号媒体ファイルを含めて、正常な表示の確保。 簡単に言えば、「ダウンロードされたHTMLファイルをブラウザーで開くと、全部正常に表示される」と言う原理が守られなければいけない。 - ローカル開発 (Local development)
- ウェブサイトやGUIアプリケーションの場合、直前の段階と違って、此の段階ではクライアント側の本格的な JavaScript動態、そしてサーバー側の実装が行われている。 此の段階ではプロジェクト構成ツールから、上記の増分構成モードの共通要求以外、 出力ファイルの更新に応じてローカルサーバーの自動再起動の様に追加機能が求められている。
- 納品系 (Production-like)
ウェブサイト又はアプリケーションを公開する前に、テストサーバ―に実行され、以前の段階で検出されなかったバグを検出する為にテスターの為に有限なアクセス が設定される事は普通。 此の段階群だと、構成されたサイト・アプリケーションはローカルコンピューターではなく、遠隔 サーバーでの実行専用なので、ファイルの更新に応じてプロジェクトの自動再構成やブラウザーページの自動リロードの様な機能は無い。 当構成は公開専用版（「納品」、だから当モードの群は「納品系」と呼ぶ）に近くなければいけないが、具体的なモードに依ってログのレーベルやデータセットの様な 特性に違いがある。
- テスティング (Testing)
- ローカル開発モードと違って、此のモードで構成されたサイト・アプリケーションにテスターや営業者や其の他の関係者がアクセスがある。 名前から自明的ではあるが、該当している段階の主な目的はテスティングを行う事に依り不具合（バグ）を発見する事。
- ステージング（Staging）
- 大規模のプロジェクトに於いて、テスティング版と他に「ステージング」と呼ぶ似た様な版もよくある。 違いが多くなく、主にテストしやすいデータではなく、実データに近いデータの利用。 其の御蔭で、依頼側は公開されたサイト・アプリケーションを使っている印象がある。 だからこそ、依頼側に提示したい場合、テスティング版ではなく、ステージングを提示すれば良い。
- 納品 (Production)
- 此のモードで構成されたウェブサイト・ウェブアプリケーションは公開・対象利用専用。 以前の構成モードに比べて、セキュリティーの最厳設定が必要に成り、データを何気無く変更・削除すると、様々な規模の損害 が発生するので、注意して取り扱わなければいけない。 尚、此の段階では開発者がブラウザーコンソールへの出力を可能な限り少なくする傾向がある。
初期位置・子ファイル (Entry points / children files)
初期位置は英語・片仮名語表記の「エントリポイント」に該当するものであり、デザインパターンの名前。 一般的にプログラムが実行が始まるファイル、関数又はクラスの メソッドを意味し、 詳細な意味は技術に依って異なる。
殆どの現代プログラミング言語及びプリプロセッサはソースファイルを何れでもの成分に別ける機能がある。 此処で親ファイル及び子ファイルを判別する必要が有る。 子ファイルも成分に別ける事が出来るので、ツリー系の階層構造と成り、一番上に在るのは初期位置である。
ファイル種類毎
マークアップ
マークアップの場合、初期位置は 完成したHTMLドキュメントに該当している。
初期位置は子ファイルが無いが合い、HTMLへの変換の結果 妥当なHTMLドキュメントが取得される。 子ファイルが有った場合、独立的にHTMLに変化したはならなく、 変化すると妥当なHTMLドキュメントにはならない。
一般HTMLファイルを複数のファイルに別ける事が不可能だが、 Pugを含めてHTMLプリプロセッサはソースコードの段階で此の機能が有る。 Pugプリプロセッサを活用しているYDAに於いて初期位置 はソースPugファイルにも出力HTMLファイル にも適用。 子ファイルを初期位置又は他の子ファイルに含むには includeディレクティブが利用される。 extendsディレクティブも子ファイルの利用を意味し、理由としては 継承されるファイル自体は完成したHTMLドキュメントを代表しているとは限らない。