class: title, smokescreen, shelf, no-footer # WWWコンテンツ管理をしてみよう <div class=footnote> <small> http://www.ex2022.fml.org/~user/ でアクセスできるようにしてもらいます </small> </div> --- class: compact # 演習: WWWコンテンツ管理をしてみよう <div class=footnote> <small> (脚注) 確認方法はプログラムによる自動チェックです。 プログラムは全ユーザのURLにアクセスし、 対応する学籍番号が書かれているか?を確認していきます。 <B> 学籍番号は半角英数字という想定なので気をつけてください </B> </small> </div> - 次頁の作業手順(必須課題)どおりに自分のホームページを作成してください - 作業がうまくいっていれば次のURLでアップロードしたコンテンツが見えるはずです ``` http://www.ex2022.fml.org/~学籍番号/ ``` (注: もちろん`~学籍番号`の部分は各自ことなります) - この作業を授業開始(2022/05/19 10:45)までに終えている人は、 作業結果の確認後、出席を入れれば今日は終わりです (おつかれ！本日は授業5分でしたね。ELも忘れずにね) - なお、発展課題をTA/SAさんにみてもらう**オプションあり(アピール,加点対象)**。 **申告制です。google formを用意しておきますので事前に申しこんでください** - **うまく出来なかった人は授業時間枠で一緒に手を動かしましょう** --- class: compact # 作業手順(必須課題) <div class=footnote> <small> (脚注) [ヒント] ディレクトリの作成には mkdir コマンドを使います </small> </div> 1. コンテンツ(`index.html`)のテンプレートをダウンロードし 1. コンテンツ(`index.html`)を編集し、自分の学籍番号を埋め込んでください 1. コンテンツ(`index.html`)をwww.ex2022.fml.orgへアップロードしてください <br> アップロード先は各自のホームディレクトリの`public_html`ディレクトリ以下です <br> つまり 「`/home/学籍番号/public_html/index.html`というファイルを作成すれば、 `http://www.ex2022.fml.org/~学籍番号/`というURLでアクセスできる」という意味です - [注] なお(デフォルトでは)各自のホームディレクトリに`public_html`というディレクトリは無いと思います。無い場合には`public_html`を作成してください --- class: compact # 発展課題(オプション,志願者のみ,申告制) - この用意したコンテンツ(`index.html`)のテンプレートは最小限の味気ないものなので、 基本課題とは違う「Myページを作ったから見て！」というアピールも受け付けます - ただし見栄えに興味がない授業なので 「このHTML5の何とかが...」とか 「この最先端のフレームワークとCSSがどうたらこうたら」 とか語られても加点は少しだけね - 歓迎される例 **(システム構成や連携の仕組みを説明する準備をしておいてください。 そこが評価ポイント)** - AWS Academy に自分のWWWサーバをたててコンテンツを置きました！ - AWS Academy では24時間運用できないので他の無料のサーバを使っています - システム全体の造りこみをアピールする芸風: 例: hugoを使ってイケてるページを作ることにしました。 サーバとの連携(コンテンツの転送)の仕組みはコレコレです <div class=footnote> <small> (脚注) 次頁からは (a)基本課題の詳細 (b)[発展]WWWコンテンツ管理の(静的,動的)方法について解説します </small> </div> --- class: title, smokescreen, shelf, no-footer # 解説<br>WWWサーバのコンテンツ管理 <div class=footnote> <small> (脚注) WWW = 毎日、世界規模でコミケを開催中！ (WWW = インターネットではないけれど、 一番有名なアプリが WWW なので実質「インターネットはデッカイコミケ」でOK) </small> </div> --- class: compact # http://サーバ/~ユーザ名/ の意味とは? <div class=footnote> <small> (脚注) この仕組みを使うには、apacheの場合userdirという設定を有効にします (設定ファイルを2ヶ所編集) </small> </div> - **一つのサーバを複数人で使いたい場合**、 **コンテンツの管理権限を分ける**ため、 こういった仕組みを使います (自分一人で使うサーバは好きにすればよいけどね...) - 自分のコンテンツを人に見せたいだけなら、 最近は自分でサーバを立てずともフリー(無料)のblogなりがたくさんあるので、 こういったURLも珍しくなりましたが、 老舗の「ユーザにWWWサーバをレンタルするサービス」で、この形式を見かけるはずです - このURLへアクセスするとapacheの内部では以下のファイル名と解釈(変換)されます ``` http://www.ex2022.fml.org/~ユーザ名/ -> /home/ユーザ名/public_html/index.html http://www.ex2022.fml.org/~ユーザ名/a.html -> /home/ユーザ名/public_html/a.html ``` - 通常、サーバOS上では自分のファイルだけを読み書きできます (他人のファイルは読み書きできません)。 この仕組みがあれば、 各ユーザは自分のホームディレクトリ(`/home/ユーザ名`)にある`public_html`以下のコンテンツを編集することで自分のコンテンツを維持管理できます。 そして複数人で一つのサーバを共有できます --- class: compact # index.htmlのダウンロード <div class=footnote> <small> </small> </div> - 授業でHTMLもロクにやってないそうですが大丈夫じょぶです。 「HTMLは人の(ソースコード)をみて真似る」 これが1990年代後半にインターネットが流行した原動力の一つ Q: 人のページのHTML(==ソースコード)を見るには? <br> A: ブラウザで真似したいページを表示 -> 右クリック -> ページのソースを表示 <br> 「ページのソースを表示」し、 その`<tag>`だらけのページをindex.htmlという名で保存してください。 保存される場所はブラウザ依存ですが、たいていは「ダウンロード」フォルダ 例: `http://www.ex2022.fml.org/~fukachan/index.html`のソースを表示したところ <br> (このHTMLソースコードをindex.htmlという名のファイルに保存する) ``` <html><body><h1>It (fukachan's home page) works!</h1></body></html> ``` --- class: compact # index.htmlの編集 ``` <html><body><h1>It (fukachan's home page) works!</h1></body></html> ``` を編集し、自分の学籍番号に変更、ファイルを保存(上書き保存)してください ``` <html><body><h1>It (学籍番号's home page) works!</h1></body></html> ``` --- class: compact # public_htmlディレクトリの作成 <div class=footnote> <small> (脚注) mkdirの引数public_htmlは<B>ホームディレクトリからの相対パス</B>と見なされています。 次頁の脚注を参照 </small> </div> - [方法1] サーバにログインして`mkdir public_html`を実行する ``` 例: 学籍番号が b2902900 の場合 ssh b2902900@www.ex2022.fml.org ``` ログイン後 ``` mkdir public_html ``` を実行 - [方法2] 遠隔でコマンド`mkdir public_html`を実行する (結局のところ裏側では上と同じことをしているんですけどね)。 **手元のPCのターミナルで次のコマンドを実行してください** ``` ssh b2902900@www.ex2022.fml.org mkdir public_html ``` --- class: compact # index.htmlのアップロード <div class=footnote> <small> (脚注) (前頁や本頁のような使い方で) サーバ上の場所をフルパス(full path)で記述しない(/で始めない)場合、 ホームからの相対パスとして扱われます。 相対パスでは、 自動的に「指定した場所」の左側にホームのパス(/home/ユーザ名)を追加して解釈されます。 例: public_html/index.html -> /home/ユーザ名/public_html/index.html </small> </div> (以下、今、ダウンロードフォルダにいると仮定した説明ですが) 次のように scp コマンドを使い「ネットワークごしにコピー」してください。 <br> (パスワードを聞かれると思うので、その時はパスワード ex@20220421 を入力) ``` 形式: scp ファイル ユーザ名@サーバ名:サーバ上の場所(ファイルパス) 例: 学籍番号が b2902900 の場合 scp index.html b2902900@www.ex2022.fml.org:public_html/index.html ``` cpコマンドに名前が似ているscpはssh付属のコピーをするコマンドで、 sshが作る暗号化された論理通信路上でコピーを実行するコマンドです。 つまりネットワークごしにファイルをコピーします --- class: compact # index.htmlがアップロードされたかを確認する うまく作業できていれば、このコンテンツが次のURLで見えるはずです ``` 例: 学籍番号が b2902900 の場合 http://www.ex2022.fml.org/~b2902900/ ``` --- class: compact # 発展課題をやりながら考えてみてね <div class=footnote> <small> (脚注) (1) -p オプションは何を問題としているのか? (2)(3) ファイル群の転送を具体的に実行する様子を実演 (3)では rsync の暗号化対応の理屈は?なども説明してもらいたいですね </small> </div> では考えて見てください。 確かに「単純なscpだけの利用」はダサいです。 普通は、こうでしょう！という内容を以下に書いておきます **(それぞれの課題について、 そうしないと何が問題で、 それをどう解決したか?をアピールしてくれるといいね<-加点)** 1. scpではなく`scp -p`(`-p`オプションは付けるだろう、ふつう) 2. sshならsftpというコマンドもありますね(どっちがいいの?いつ使うの?) 3. コンテンツがファイル一個だけってことはないよね?ファイル群ですよね?その時は? - scpのオプションでファイル群を転送するようにする - scpではなく他のコマンドを使う(例: rsync) 4. (1.-3.とは違う観点ですが)そもそもパスワード認証がダメです。 ふつうはどうするでしょうか? --- class: title, smokescreen, shelf, no-footer # [付録] コンテンツ管理 <div class=footnote> <small> (脚注) ちなみに、このサーバ lectures.fml.org は hugo で生成しています </small> </div> --- class: img-right,compact # コンテンツ管理の一般論 <div class=footnote> <small> (脚注) 静的コンテンツは複数のサーバが同じデータ群を持つことができます(コピーし放題)。 ユーザ数の多いショッピングサイトなどでは、 静的データ部分を次のように処理するCDN (Contents Delivery Network)というサービスを購入して運用するのが普通です。 あらかじめマスターサーバのデータをコピーしたサーバ群を世界中に配置し、 ユーザに近いサーバからデータを返します。 ユーザへの応答は高速になり、 広域のデータ転送も減り、 マスターサーバへの負荷も下がります。 マスターサーバは動的変化するデータだけを処理します (それでも一台では処理できないので複数のサーバ群を連動させますが、 この冗長構成の話題は秋学期のOSの担当) </small> </div> - WWWコンテンツとは、結局のところ、おおむね「ファイル(群)の維持管理」と言えます。 多くのWWWサーバはURLに対応するファイル群を単に表示しているだけです - ELやPortalサーバ、Amazon などのショッピングサイトでも99%くらい同様です。 正確には、 これらのサーバもコンテンツの多くは(静的=変化しない)ファイルもしくはデータですが、 一部の出力が動的に変化します。 ショッピングサイトを例にすれば、 カートの中身、商品の合計価格、在庫の数などはリアルタイムに変動します。 その一方、商品説明や商品の写真は変化しません(== 静的なデータ) - この静的部分についての維持管理について次頁以降で解説します --- class: img-right,compact # 静的コンテンツ管理 <div class=footnote> <small> (脚注) こういうソフトウエアがWWWの歴史と同じくらい古くからあります。 手元のPC上でウエブサイトのコンテンツ一式を維持管理し、 リリース時に本番WWWサーバへアップロードするという手順です。 商用インターネット黎明期からある (Flashでおなじみの旧Macromedia、現Adobeの)Dreamweaverが有名どころ。 オーサリングツールというジャンル。 いまは無料で優秀な(オープンソースの)オーサリングツールがたくさんあるので、 いまさらDreamweaverなんて買わないけれども </small> </div>  - 手元のPC上でウエブサイトのコンテンツ一式を作成・維持管理し、 リリース時に本番WWWサーバへアップロード - コンテンツの作成方法は世代によっていろいろですが、 現在のモダンなやりかたは**markdownで記述**する方法でしょう。 ユーザがmarkdownでコンテンツを準備し、ツールがHTMLへ変換します。 変換結果をアップロード --- class: img-right,compact # 静的コンテンツ管理 <div class=footnote> <small> </small> </div> - こういったソフトウエアを静的サイトジェネレーター(static site generator)とも言います。 一般にはオーサリングツール(authoring tool)かな? - 有名な例としては一昔前が Jekyll、いま hugo、もっと最近の例は google してね:-) (400を越えるジェネレーターがあるという噂も見た, 未確認) - [hugo](https://gohugo.io/)の紹介 - markdownをHTMLに変換するツール - この手のツールはスクリプト言語でかかれたものが多いけれど、 Go言語で書かれているhugoはhugo以前のツールにくらべ高速。 変に自己開発にこだわらず、 テンプレート変換機能はGo言語標準モジュールを使うといった設計方針も良い - シンプルなものから凝ったものまで様々な[テーマ(サイトテンプレート)](https://themes.gohugo.io/)があり、 好きなテンプレートを選んで用いる。 はじめから、このような仕様 (ユーザ参加型というか所謂オープンソース開発モデル) - [参考] - 21世紀版C言語たる[Go言語](https://exercises-aws.fml.org/ja/appendix/golang/) については[AWS構築ガイド](https://exercises-aws.fml.org/ja/) を参照 --- class: img-right,compact # 動的コンテンツ管理 <div class=footnote> <small> </small> </div>  - サーバ側にツールがあり、 ユーザがブラウザでサーバ上のファイル群を編集 - **[致命的] ツールにバグがあると、 ウエブサイトが乗っ取られます** - 有名なソフトウエアは wordpress でしょう。 こんなバグバグなツール使うなよ！ですが。 毎日アップデートを確認して、 まめにアップデートしつづけるならいいですけど.. wordpress のメンテをプロに任せるなら使ってもいいかも? <br> サービス例「[さくらのレンサバ](https://rs.sakura.ad.jp/)」 (月額524円〜) --- class: compact # 静的と動的コンテンツ管理どちらがおすすめ? <div class=footnote> <small> (脚注) 最後の方のくだりは、 きみたちビジネスの思想が身についてないな! (そういう授業してないから当たり前か!?) という話に進むのですが、 さすがに脱線なので、コラム(別のスライド)にしましょうか </small> </div> - 一般人は**静的**、巨大なショッピングサイトの類は**動的**でしょう - 動的コンテンツ運用では、 インターネットに晒しているオーサリングツールに穴があるかも? (実際wordpressはバグだらけ)という弱点が圧倒的なデメリットです - そもそも今時は、静的サイトでも問題なく今風のウエブサイトを構築できます - WWWコンテンツの今風の部分は普通Javascript(JS)ベースです。 JSはWWWブラウザがJSファイル(群)を読み込み、 ブラウザがJSを解釈して素敵な動きを見せているだけなので、 静的HTMLファイルのダウンロードと同じ動作です - **そもそも、なんでも自前で開発しようという設計思想が間違い** - URLはインターネット上のどこのサーバへもリンクできるのだから、 ショッピングカートやコメントの部分だけ**別のサイト (カートやコメント専門のサーバ)を利用**すれば、 **自分が維持管理する部分は静的コンテンツのみ**にできます - **使えるものは使う、連携できるものは連携、最小の開発コストで最大の利益を！** <br> **設計のセンス**が試されているところやね