Hnoss

Hnoss

さーてと。GitLabランナーのインストール編終了です!
カレンダー

文書タグ

フノス(訳者)(155) IT(127) 解説記事(82) オープンソース(49) GitLab CI(34) Linux(32) メディア(31) ウェブ制作(23) DTM(19) HTML5(19) コンテナ(18) Libre Music(18) おすすめ オープンソース・ソフトウェア(17) 百科事典(14) プラグイン(13) 文化(12) ミキシング(11) ソフトウェア(11) 録音(11) MIDI(10) 西アジア/中東(10) 料理(9) ジョージア(9) グルジア(9) 東ヨーロッパ(9) シーケンス(8) 芸能(8) 音楽編集(8) セキュリティ(8) 音楽(7) マスタリング(7) 経済(6) WordPress(5) アプリ(5) 業務効率化(5) JACK(5) コマンド(5) Windows(4) 映像制作(4) Android(4) GNU(4) 音楽プレーヤー(4) マイクロサービス(4) Google(4) Java(3) ワークフロー(3) ソーシャルメディア(3) DAW(3) 欧州(3) Ubuntu(3) Python(3) 北米(3) アニメ(3) ホームオートメーション(3) アニメーション(3) IoT(3) Ardour(3) 社会(3) 有角神(2) ERPシステム(2) 電子ブック(2) エジプト(2) ALSA(2) OS X(2) トヨタ(2) Krita(2) 電子書籍(2) ERP(2) バト(2) ウィッカ(2) Twitter(2) GPL(2) オカルト(2) ロスレス音源(2) iOS(2) スマホ(2) 牛(2) ニュース(2) GNOME3(2) 歴史(2) 仮想通貨(2) マーケティング(2) PlayStation(2) 古代エジプト(2) アモン(1) セイラム魔女裁判(1) ねじ巻きラジオ(1) 3D(1) EU(1) イボ人(1) 国際公文書館会議(1) マイナビ(1) キリスト教(1) レビ記(1) アマナイ(1) 広告(1) KXStudio(1) 絵文字(1) サンフランシスコ(1) イケンガ(1) リクルート(1) ユダヤ教(1) ウルガタ聖書(1) 科学技術(1) Blender(1) 出エジプト記(1) 観光案内(1) ツイッター(1) Youtube(1) パキスタン(1) CC(1) ハトホル(1) パン(1) 地方(1) 羊神(1) ギリシャ(1) 高速道路情報無線(1) ゲーム(1) 法律(1) 中南米(1) モヘンジョ=ダロ(1) 悪魔(1) ラジオ(1) OpenToonz(1) 電子教材(1) アレクサンドロス大王(1) ローマ(1) ポッドキャスト(1) パシュパティ(1) アピス(1) 宗教(1) テレビ(1) BountySource(1) 船乗りの柱(1) シリア(1) GPS(1) 日記(1) アフリカ(1) リグ・ヴェーダ(1) F-Droid(1) 教育(1) bi-modal IT(1) ムネヴィス(1) ネオペイガニズム(1) コミュニティ放送(1) アンビソニック(1) Papagayo(1) 写真(1) 元ネタ(1) ケルヌンノス(1) ナイジェリア(1) 聖書(1) 任天堂 DS(1) 学校(1) 日本(1) 魔女宗(1) アクティブSETI(1) バイノーラル(1) アップストリーム・パッケージング(1) 画像(1) 意味(1) コシディウス(1) インド(1) ユーコン(1) サウンドフォント(1) UNIX(1) ヤーウェ(1) CD(1) タブレット(1) 羊(1) ベルゼブブ(1) デジタルサイネージ(1) VR(1) ポータブルソフトウェア(1) 由来(1) グンデストルップの大釜(1) カナン(1) カナダ(1) 詩篇(1) チップチューン(1) バ・ネブ・デデト(1) コットン・マザー(1) クラウドキャスティング(1) VST(1) リーナス・トーバルズ(1) エリファス・レヴィ(1) マサチューセッツ(1) 考古学(1) 申命記(1) スタジオジブリ(1) クヌム(1) 魔女裁判(1) オンデマンド(1) 政治(1) バフォメット(1) 国際(1) クリエイティブ・コモンズ(1) 黙示録(1) Synfig(1) 独占(1)
リファレンス

first-time visitors
user guide
謝辞

「みんなの翻訳」は情報通信研究機構言語翻訳グループ東京大学図書館情報学研究室による共同プロジェクトであり、三省堂国立情報学研究所連想情報学研究開発センターが開発に協力しています。三省堂には「グランドコンサイス英和辞典(36万項目収録)」の使用を許可していただきました。

連携研究グループはこちらをご覧ください。

「みんなの翻訳」を使っている翻訳グループについてはこちらをご覧ください。

バナー

logo

ポスター

poster

フライヤー

poster poster
Mozilla Firefox ブラウザ無料ダウンロード
本サイトはブラウザ「Mozilla Firefox」推奨です。
Firefox3で動作確認しています。

Valid XHTML 1.0 Transitional

site_image
SSGs Part 1: Static vs Dynamic Websites  | about GitLab.com / Marcia Ramos
https://about.gitlab.com/2016/06/03/ssg-overview-gitlab-pages-part-1-dynamic-x-static/
Hnoss Hnoss     最終更新:2017-09-23 11:23:00    PDF


 ウェブサイトは静的なものと、動的なもの2つに分かれますが、それらにはどのような違いがあって、どのような長所があるのでしょう。
 GitLab Pagesで扱えるのはどっちだろう?
 静的サイト・ジェネレータなんて聞きなれないな。なんだろう?

 そんな方のために、この記事を作りました。
 「静的サイト・ジェネレータ(SSGs)」について知っておくべきポイントをおさえた3連企画です。

 進行を大まかに説明します。

 パート1(この記事):動的 vs 静的ウェブサイト -それぞれの違い、長所短所について

 



 注:今回は、ウェブ開発に関する知識をある程度持ち合わせている人を対象にした記事です。
 静的サイト・ジェネレータに興味があり、特にGitLab Pagesへのデプロイを真剣に考えている方は、ぜひご一読ください。


 


  静的サイト、動的サイトとは?

 静的ウェブサイトとは、
 HTMLマークアップ言語  (主にサイトの文章)、
 CSS   (スタイルやレイアウトの設定)、
 JavaScript  (要素の動きの設定。フェードイン・アウト、ホバーなど)
 を組み合わせて作成したウェブサイトのことです。

 ページはこれらの言語で作られた単純なファイルとして、ウェブサーバー上にあるVPSなどに保管されています。

 私たちはウェブブラウザでURLなどを打ち込んでページに移動しますね。そのときに、私たちのブラウザ(クライアントと呼ばれます)は、ウェブサーバーにHTTPリクエストを送信します。
 実はここで「どのファイルの情報を欲しているか」という情報をサーバーに送っています。そのリクエストの返答(HTTPレスポンス)として返ってきたものを、ブラウザが解読して表示したものが、ウェブページです。

(訳者より: HTTPリクエストを「選局」、ブラウザが解読して表示することを「視聴」と捉えるなら、実はブラウザにはあくまで「ラジオ」のような機能しかないことがわかります。
 ウェブページが「放送局」、そしてウェブサーバーは、「発信基地」や「電波塔」に相当します。ブラウザは電波塔から出された指示に従って、ページを表示しています。)

 動的ウェブサイトの場合、これらの動作がやや複雑です。
 静的ウェブサイトにあるような、文章、スタイル、要素の動作などの項目の他に、様々な情報を付け加えなくてはなりません。

 たとえば、オンラインショッピングを例にとって説明しましょう。
 これは皆さんすぐにお判りでしょうけど、モノの価格や在庫状況などは変化していくものですよね。これらの情報をウェブページに反映させる必要があります。

 このように日々刻々と変動していくデータを更新し、収容しているのが「データベース」という機構です。これとウェブページとをつなげて情報のやり取りを行っていきますが、それらの処理は、ウェブサーバーとはまた別のサーバーが行わなくてはなりません。

 動的サイトの場合、クライアントであるブラウザにウェブページを表示させる前に、
 まずサーバーが最新の情報を取得したり、ウェブページを更新したりしなくてはなりません。

 ちなみに、サーバーが処理をすることは「サーバーサイド・プロセシング」と呼ばれます。

 さて、2つのサイトの仕組みが大まかに理解できたところで、次は2つのサイトがどのような目的で作られたかについて解説します。
 

 どうしてできた?静的/動的サイト

 今から約25年前、1990年に Tim Berners-Leeという人物が発表した、ほんのちょっとのタグとリンクとで構成されたページが、世界で最初のウェブページです。
 そして、こちらは静的ウェブサイト

 それから3年後の1993年に、コモン・ゲートウェイ・インタフェース(CGI)が開発されて、ウェブサーバー側が予めスクリプトを処理して、ブラウザに表示させることが可能になりました。
 これ当時としては、大変画期的なシステムだったんです。

 そしてそれ以降、どちらかというと「動的ウェブサイト」のほうが、ウェブサイトの覇権をにぎっていくことになります。

 動的ウェブサイトの普及をより一層推し進めるきっかけになったのが、ウェブコンテンツ・マネジメント(WCMS)の到来です。
 これによりウェブサイトの作成はもとより、データベースの維持管理も簡単になりました。

 サーバーサイドの処理にバリエーションが増えることで、ユーザーはより高いレベルのウェブサービスを受けられるようになりました。
 これのおかげで「ウェブアプリ」というものが開発・発達していくことになります。
 もちろん、GitLabもその中の1つですよ。

 コンテンツ・マネジメントシステムも段々とその種類を増やし、 WordPressJoomla!DrupalMagentoGhostなど、実に数多くのサービスが世に出回ることとなりました。

 しかし、動的ウェブサイトが広まった理由は、データベースに接続してリッチなコンテンツを展開できることだけではありません。


 実は、テンプレートシステム目当てに利用する人々が多かったことも、大きな理由です。テンプレートがあるぶん、開発は効率的に、アップデートはより簡単に、そして極力ミスを減らしてウェブサイトを制作できるようになりました。

 しかし、思わぬところで落とし穴が発生します。サーバーサイド処理の人気に火が付いたことがきっかけで、脆弱性を攻撃されることが増えたのです。

 これもまた月並みな話ですが、脆弱性が見つかって、それに対処するとなると、それはもうとてつもない時間と手間がかかります。

 もはやこのままでは、ユーザーも運営者もサーバーも守り切れないという状況で、とあるセキュリティ担当者がこんなことを考え付いたそうです。

 テンプレートシステムさえ使えれば、作れるものは静的ウェブサイトでもよかったんじゃないか。このような理由で開発されたのが、静的サイトジェネレータ(SGGs)です。
 ウェブサイトを記述するソフトウェアは動的だとしても、実際に発表するサイトは全て静的であることが特徴です。

 静的サイトジェネレータは、2000年代の前半にはすでに登場しています。 Blosxomは2003年、 WebGenは2004年の発表です。
 そして2008年、 Tom Preston-Werner によって、今や静的サイトジェネレータの代表格といわれる Jekyllが発表されました。

 静的サイトジェネレータの人気は、ここ2,3年ほどで急激な上昇傾向を見せています。(Google Trendsのグラフ


 サーバー処理

 まずは、こちらの画像をご覧ください。

 静的サイトと動的サイトとが、サーバーとどのようにやり取りをして表示されているかが表されています。

 どれだけ動的な言語でプログラムされていたとしても、 ApacheNGINXIISなどのウェブサーバーソフトウェアは、静的ファイルしか保管・読み込みできません。
 なので、これらのサーバーの利用者は、HTML、CSS、JavaScriptしか使えないと考えておいた方がよいでしょう。

 ちなみにGitLabPagesは、NGINXサーバーで運営されています。なので、静的ファイルしか保管できません。


 動的なサイトにはウェブサーバーの他にコンテンツを処理するサーバーが必要です。
 そのサーバーには、アプリケーションソフトウェアが搭載されています。これがないとサーバーで動的なスクリプトを扱うことができません。代表的なものは、 PHPCold FusionASP.NETなどです。

 いかなるブラウザ(クライアント)も、HTTP(HyperText Transfer Protocol)と、URL (Uniform Resource Locator)とを介して、ウェブサーバーにしかアクセスできないようになっています。

図A[静的サイトの場合]:
クライアントがURLを宛先として、HTTPリクエストをウェブサーバーに送信しました。
ウェブサーバーはこのリクエストに応じて、URLに符合したHTMLファイルを探し出します。
該当したファイルを、すぐさまクライアントにHTTPレスポンスとして返信します。
ブラウザが返信されてきたコンテンツを翻訳して、ディスプレイに表示します。
このとき、ブラウザが行っている翻訳処理のことをクライアントサイド・プロセシングと言います。

図B[動的サイトの場合]:
クライアントがウェブサーバーにHTTPリクエストを送信します。
すると、ウェブサーバーは至急スクリプト処理をするよう、アプリケーションサーバーに指示を出します。
さらにアプリケーションサーバーが処理に必要なデータを参照するために、データベースに情報の送信を要求します。
データベースから送られてきた情報をもとに、アプリケーションサーバーが処理を開始しました。
アプリケーションサーバーが処理した情報を、今度はウェブサーバーに送付します。
ウェブサーバーが与えられた処理結果をもとに、HTMLファイルを作成します。
ようやくクライアントにHTTPレスポンスを返信することができました。
これがサーバーサイド・プロセシングです。

 両者の最も分かりやすい違いは、動的サイトの方が静的サイトに比べてやり取りをするサーバーの数が多く、ウェブサーバー1つでは処理が不可能であることでしょう。
 HTTPリクエストに何らかのレスポンスを行うことについては共通しています。

 当然、動的サイトの方がHTTPレスポンスにやや時間がかかる傾向にあります。
 

 もちろん、動的サイトの方がサーバーにより大きな負担をかけています。

 仮に、1ページのHTTPリクエストを受け取るたびに、情報を更新した方がよい内容でもないはずなのに、動的サイトに掲載したとしたら、どうでしょう。
 それだけ無駄な処理が発生しています。

 単なる日記ブログや覚書のようなサイトに、動的サイトを使う意味はそんなにありません。
 「ページを追加する」という変更があったとしても、そのページ書いてある内容が常に変動するわけではないからです。

 つまり、個人が作成するほとんどのサイトが、静的サイトにした方がよいのではないかという状態です。

 なにより、構造が複雑になれば、セキュリティの隙が生まれます。
 動的サイトが処理を行うには、ユーザーのデータを収集しなくてはならない場合もよくありますが、そのデータを盗み見される事案が後を絶ちません。
 

 あなたのサイトでは、ユーザーのことを詮索する必要が本当にあるのですか。
 あなたは、ほとんどだれも知らぬ間に自分の大事な情報を抜き取るサイトに毎日訪れたいと考えますか。

 結論

 動的サイトは、やっていることの規模や、スクリプトの内容から考えて、「ウェブアプリを配給するために作られたものだ」と大まかに割り切ってしまいましょう。

 実際、動的サイトを作ってみると、先ほど紹介した図Bよりも遥かに複雑な世界があなた待ち受けています。

 それに比べて、静的サイトは単純なもので、図Aとほとんど同じ構造です。
 メンテナンスにお金をかける必要も、ほとんどありません。
 この単純さが、GitLabで静的サイトを無料で公開しても全く支障がない最大の理由です。

 ウェブ開発者のほとんどが、静的サイトの制作に「時間がかかってアップデートが面倒だ」というイメージを抱えて、動的サイトを選びがちです。
 しかし、先ほども申しましたように、その問題は静的サイト・ジェネレータがほとんど解決しています。

 次回の記事では、最近の静的サイト・ジェネレータ事情をご紹介します。
 静的サイト・ジェネレータがどのように動作するのか、どのように使えば便利なのかについてお教えします。

 それでは!

原文:https://about.gitlab.com/2016/06/03/ssg-overview-gitlab-pages-part-1-dynamic-x-static/
Creative Commons License
この作品は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。
クリエイティブ・コモンズ・ライセンス外部リンク
新着文書(Hnoss)

Install GitLab Runner
GitLab Runner > GitLab Runnerをインストールする  GitLab Runnerは、GNU/Linux、 macOS、 FreeBSD、 Windowsでインストールと使用すること...
GitLab Runner bleeding edge releases
GitLab Runner > GitLab Runnerをインストールする >nightly版をインストールする 警告: この操作でインストールされるランナーは、まだテ...
Run GitLab Runner on a Kubernetes cluster
GitLab Runner > GitLab Runnerをインストールする >Kubernetesクラスターにインストールする  KubernetesでGitLab CI Runnerをお使いに...
Install GitLab Runner on FreeBSD
GitLab Runner > GitLab Runnerをインストールする >FreeBSDにインストールする 注: FreeBSDでは、現在 ”開発最先端”とされて...

新着文書

Revisit to resist: Histories of the movement to end gender-based violence
抵抗のための再検討:ジェンダーに基づく暴力を終わらせるための活動の歴史 2017年11月8日 記憶は抵抗である。あなたの話が沈黙させられ挑まれたな...
What do women’s rights have to do with the SDGs and the internet?
女性の権利はSDGsとインターネットにどのような関係があるか? 2017年8月2日、スリランカ 女性は均質な集団ではなく、科学技術へのアクセスもまた、...
Sexual rights and the internet: Third EROTICS global survey now launched!
性的権利とインターネット:第3回EROTICS国際調査、現在開始! 2017年7月19日 EROTICS国際調査が戻ってきた! もしあなたが、インターネットを自ら...

新着Wikipedia翻訳

Air gap malware
エアギャップ・マルウェア エアギャップ・マルウェアとは、様々なエアギャップの隠されたチャネルを使い、安全なコンピュータ・システムのエアギャッ...
Air gap (networking)
エアギャップ(ネットワーク関係) エアギャップ(air gap:空隙)またはair wall(空気壁)、エア・ギャッピング[1]とは、ネットワーク・セキュリ...
HTTP Public Key Pinning
HTTP公開鍵ピニング HTTP公開鍵ピニング(HPKP: HTTP Public Key Pinning)[1]とは、HTTPヘッダによって実現されるセキュリティの仕組みであり、HT...

更新履歴

※文書量によっては処理に数十秒かかる場合があります
バージョン 比較対象 更新日時 更新者
1(最新) 2017-09-23 11:22:58 Hnoss
2 2017-09-23 11:22:01 Hnoss
3 2017-09-22 23:00:31 Hnoss
4 2017-09-22 23:00:30 Hnoss
5 2017-09-20 23:35:19 Hnoss
6 2017-09-17 23:02:48 Hnoss
7 2017-09-14 22:26:57 Hnoss
8 2017-09-14 18:59:18 Hnoss
9 2017-09-14 18:54:27 Hnoss
10 2017-09-14 18:52:25 Hnoss

    
ブックマーク登録

タグを「;(半角セミコロン)」区切りで入力して下さい(例)tag1;tag2;tag3
10タグまで登録可能。各タグ30文字まで

履歴
状態 作業中 作業予定あり 作業予定なし 作業完了
テーマ 社会 政治 法律 経済 文化 芸能 科学技術 IT 健康/医療 スポーツ メディア 植物 動物 菌類 地方 国際
地域 日本 東アジア アフリカ 南アジア 東南アジア 西アジア/中東 太平洋 北米 中南米 欧州
ジャンル ニュース 解説記事 論文 日記 百科事典

コメントを入力して下さい
0 / 250
    
ブックマーク登録

ブックマークに登録しました。


言語選択

    
ファイルプロパティ

使用許諾条件
ファイル情報
あなただけがこのファイルを閲覧・編集できます。
みんながこのファイルを閲覧できますが、
編集ができるのはあなただけです。
あなたに加えて、指定された人やグループが
このファイルを自由に閲覧・編集できます。
公開設定
編集設定
グループ:0組 翻訳者:0人
    
アクセス属性
この文書は「非公開」設定になっています。
一般公開する場合は、編集ページの書誌情報で「公開」設定に変更して下さい。
翻訳者選択

※メニュー「翻訳者管理」で翻訳者、グループを追加することができます。


    
ノート

非公開ノート
0 / 2000 ※「公開・編集」権限を持つ翻訳者のみに公開されます。
公開ノート
0 / 2000 ※文書を「公開」にした場合、一般に公開されます。

言語選択

 →