そうだ、教祖になろう。出エジプト記 第1章1節 S3で静的Webページをホスティングする
書を捨てよ街へ出よう
創世記では弊教団の教義を広めるWebサイトを構想して計画を立てました。
いやー長かった。
イスラエルの民がラムセスⅡ世に奴隷扱いされる日々のようでしたが、
いよいよクラウドの原野に歩みだしましょう。
はじめに神は静的Webページを創造された。
まずはただのHTMLを表示してみます。
こういう構成です。
S3は従量課金でファイルを格納できるオブジェクトストレージサービスですが、
ホスティング設定を行うことで静的Webページとして公開することができます。
こちらを参考にさせていただきました。
1年以内の記事だというのに途中のウィザード表示が微妙に変わっています。
AWSのサービス改良は目覚ましく、リリースが1時間に数千回という頻度で行われ、
1か月前に出たサービスはもう最新ではないというありさまのようです。
遥か未来の話みたいですね。
こちらは数千年前のモーセと同じように着実に約束の地へ歩を進めていきましょう。
以前ディープラーニングを勉強しようとしてとん挫していたAWSのアカウントがあったので、すべてのサービスを削除して使っていきます。
まずはS3にバケットを作りましょう。「＋バケットを作成する」をクリックします。
バケット名とリージョンを入力します。
バケット名は世界中で一意である必要があります。
ドメインに使う予定の文字列を入れておきましょう。
次はオプションの設定です。タグ管理とかログ出力とかいろいろやりたいのですが、最初は欲張らず、あとでやることにします。
Webサイトとして公開するため、アクセス許可の設定は「パブリックアクセスをすべてブロック」を外してあげる必要があります。
最後に「バケットを作成」をクリックして作成完了です。
「光あれ」
トップページのHTMLを作成します。
おなじみの"Hello, World!"ですが、
輪廻転生をフィーチャーする教団のサイトにおいてはなにか感慨深い響きがありますね。
これをバケットにアップロードします。
アクセス許可はスタンダードで。
「アップロード」をクリックして完了です。
静的Webホスティングの設定をします。
「プロパティ」タブから「Static website hosting」を選択します。
「インデックスドキュメント」をアップロードしたファイル名にします。
「パケットホスティング」にチェックが付きました。
次はアクセス権限の設定です。
「バケットポリシー」をクリックします。
バケットポリシーエディタでバケットの読み取り権限を付与します。
"PublicReadForGetBucketObjects"という名前ですべての"Principal"（ユーザ）に対する"arn:aws:s3:::shuffleplayism-contents/*"（さっき作ったバケットの中のすべてのデータ）への"s3:GetObject"（データ取得）アクションを許可するポリシーを定義しています。
"Version"はお決まりです。気にしません。
テンプレートのインデントはこちらに合わせました。
「パブリック」のオレンジ色が緊張感をあおります。
主が我らを見ておられます。
世界中の悪意のある攻撃者も我らを見ておられます。
こうして光があった。
では、アクセスしてみます。
さきほどの「Static website hosting」を開き、エンドポイントのURLをクリックします。
…
……
………
（実際は50ミリ秒もかかっていませんが、感覚的な時間の長さを表しています。）
こんにちは、世界！（ドン！！）
これで弊教団のWebサイトのトップページがインターネットに公開されました。
天地創造はまだ始まったばかりです。
そうだ、教祖になろう。創世記まとめ
せめて勤労者にひとしずくほどの感謝を
どうも。
風邪をひいて結膜炎を併発したので
病院に行ったら祝日は休診で
雨の中歩き回って3軒目の耳鼻科と4軒目の眼科で薬をもらってきた者、
人呼んで教祖です。
天もずいぶんな試練を与えるじゃあないか。
第3章1節という中途半端なところであらかた考えがまとまってしまいましたので、
この辺でまとめ回をやります。
アニメがネタ切れになったときにやるやつです。
新しい展開を楽しみにしていた子どもはテンションだだ下がりです。
俺のメモリは3bit カーマ・スートラはサンスクリット
ものごとを8種類しか覚えられない人のために
創世記の決定事項をまとめてみましょう。
創世記 第1章1節から前回まで考えてきた内容は以下の通りです。
- ただひとつの魂が輪廻転生を繰り返していると考えると他人に少し優しくできるのでは。
- この考えをもっと知ってもらいたい。
- 布教のためのWebサイトを作ろう。
- 最初のコンテンツはスライドショーにしよう。
- Vue.jsとAWSで構築しよう。
- データはGoogleスプレッドシートで管理しよう。
- サイトを作ってる様子をブログに書こう。
- アジャイル開発しよう。
8行で書けることを延々と8回に渡ってやってたわけですが、
次回からはいよいよ構築へ入っていきます。
次回予告
考えがまとまって意気揚々とチキンフィレサンドをほおばるシャッフル。
しかし、余裕しゃくしゃくで始めたサーバサイド構築は未体験作業の連続だった。
インフラ作業が不慣れなシャッフルをAWSの最新仕様が苦しめる。
追っ手を放つエジプト王。
迫りくるエジプト軍。
なかなか割れない海。
伸びないブログ閲覧数。
はたして我が教団の信徒は無事にWebサイトを作り上げることできるのか？
次回、そうだ、教祖になろう。
「出エジプト記 第1章1節 S3で静的Webページをホスティングする」にご期待ください。
良い現世を。
そうだ、教祖になろう。創世記 第3章1節 我慢できずに作ってしまう
細えこたぁいいんだよ
「いろいろ考えてるけどさぁ。ちょっと慎重過ぎなんじゃないの？」
「他のブログだと、だいたい1回の記事で何か作って動かしてるよ。」
「そろそろ動くもん見してくれてもいいんじゃあないの？」
…
「あとVue.jsじゃないとダメなの？」
「スライドショーぐらいならどっかのライブラリ使ってぱぱっと作れるんじゃないの？」
…はいはいはい。
脳内がうるさいので少し寄り道をしてみましょう。
スライドショーのライブラリを探してみます。
ありました。
slick
the last carousel you'll ever need
めちゃめちゃお洒落。
基本的には画像のスライドショーに使うようですが、HTMLタグならなんでもいいようです。
色々オプションを指定できてよさげ。
こいつをjsFiddleで試してみましょう。
jsFiddleは手軽にHTMLとJavaScriptを打ち込んで表示や動作を確認できるWebサイトです。
できたものがこれです。
まあ簡単。
5秒ごとに文章が交互に表示されるのが分かるでしょうか。
jQueryセレクタで指定したdivタグに表示オプションを渡したslickをかましています。
HTMLの"single-item"クラスのdivタグ配下をスライドとして認識するようです（この場合だと2つ）。
なるほど簡単ですね。
ただちょっと物足りないかな。
文章1行ずつ表示できた方が見栄えがしそうです。
画像用なんでしょうがないでしょう。
やっば細かい方がいいかも
文章を1行ずつ表示するのはこのサイト独自なので、いちから作る方がよさそうです。
続いてjsFiddleでVue.jsを使って試してみましょう。
playボタンを押すと動くようにしてみました。
1行ずつ出て最後に全行が消えます。
この方が雰囲気出てるんではないでしょうか。
ボタンの上のfalseはデバッグ用の変数なので気にしないでください。
ざっと中身を説明すると、JavaScript内のdata内がHTMLに動的に反映されるようになっています。
listの4つの要素のmsgがHTMLのliタグの中にバインドされています。
初期表示ではliタグはv-ifで制御されて非表示になっています。
playボタンを押すとshow変数にtrueが入り、liタグの表示アニメーションが始まります。
表示アニメーションはJavaScriptのenter関数で定義され、liタグごとに2秒ずつずれて始まり、1秒かけて表示を終了します。
afterEnter関数で最後のliタグの表示完了を検知すると3秒後にshowをfalseにします。
その後、2.5秒を掛けて各liタグは非表示状態へ戻ります。
非常に細かい設定が可能ですね。
調整すれば画像だけズラして消すとかもできるでしょう。
これだけでも結構疲れました。
ちょっと試す分にはいいんですが、画面系は細かいことに延々と時間を使ってしまいます。
画面のアニメーションだけではなくて、サーバサイドの構成とかやることは山ほどありますからね。
ご利用は計画的に。
やっぱり重要度の高い順から開発していく必要がありそうです。
以前もお伝えした通り、弊教団は私ひとりしかおりませんので、少しずつ進めていきましょう。
アジャイル開発を採用することにします。
アジャイルとは、簡単に言うと開発を小さい単位に区切って、要求→実装→評価を繰り返す手法です。
機能の追加や改善をバックログというリストで管理しますが、今は私ひとりなので単純なテキストで管理することとします。
リスト化してみましょう。
結構たくさんありますね。
アイデアだけはどんどん出てきますが、形にするのは手間がかかります。
これを優先度順に並べ替えて上から実装していくとしましょう。
そうだ、教祖になろう。創世記 第2章3節の欄外 安息日は休む
神はその第七日を祝福して、これを聖別された。
旧約聖書 創世記の第2章3節には上のように書かれています。
私はまったく「そのすべての創造のわざを終って」ませんが、
このブログも第7回目を迎えましたので、この辺でひと休みしたいと思います。
体力と気力の回復には休憩って大事ですよね。
しっかりと休んでいきましょう。
用語を考える
あー、暇だなぁー。
その宗教独特の言い回しがあるじゃないですか。
キリスト教だとキリストのことを「神の御子」って言ったり、
仏教だと仏陀の遺骨のことを「仏舎利」って言ったり。
あーゆーの宗教っぽくっていいですよね。
うちも何か欲しいなぁ。
うちの教団の特徴って言うと、輪廻転生、前世、来世、…ただひとつの魂。
この魂に名前をつけましょう。
一神教の『唯一神』をもじって『唯一魂』。
んー、もうちょっとひねりたい。
この魂に少し似てる概念のものがあるんですよ。
プログラミングのSingletonパターンです。
これは1つのプログラムの中にあるどんな処理からも必ずただひとつ生成される同一の型の変数を参照させたいときに使われるとてもポピュラーな方法です。
これをもじって『Single魂』はどうでしょうか。
伝わりづらいかなぁ。
じゃ、教団正式には『唯一魂』で発足時の信者は『Single魂』と呼ぶ人もいると言う無駄な設定を持たせてみましょう。
震えて眠れ
こんなこと言ってますけど、そのうち怒られるんじゃないかと心配なんですよ。
ブログのコメントが荒れるぐらいだったらむしろウェルカムなんですけど、本当に信仰心を持っている人が傷ついてしまうような事は避けたいですね。
前に東京の山谷と言う場所に行ったことがありまして、浅草の北にある建設労働者向けの安宿がたくさんある場所なんですけど、町自体が高齢化してて人なんかほとんど歩いてないんですよ。
閉まったシャッターばっかりの商店街の入り口に小さなキリスト教の教会があって、ボランティアで炊き出しをしてるんです。
仕事にあぶれたおじちゃんたち、というかもうおじいちゃんたちが炊き出しに並んでるその教会の裏で、そんな場所で、中東あたりから出稼ぎに来たであろう外国人の青年がほっそい路地のアスファルトに布敷いてメッカの方向に向かってひとりで一心に礼拝してるのを見つけて、あぁ信仰って尊いなって思ったんですよ。
だからって僕が作ろうとしているものが素晴らしいってことにはならないんですけど。
さて、気分転換したところで、次回は実際にモノを作る計画を立てていこうと思います。
そうだ、教祖になろう。創世記 第2章3節 キャッシュフローを考える
地獄の沙汰も金次第
弊教団は営利目的ではないものの、
サーバの運用にはある程度費用がかかります。
簡単に見積もってみましょう。
AWSはクラウド費用を見積もるためのツールSIMPLE MONTHLY CALCULATORを公開しています。
これを使います。
見積もれないサービスもあるようですが、微々たるもんなので問題ありません。
サービス名を探して想定の利用量を入力します。
月間100アクセスでも来れば大成功ですが、そんなゴミみたいな単位はないのでゼロにしちゃいます。
Route53
S3
これまで考えた構成を入力すると月額料金合計はこうなります。
全然少ないですね。
従量課金なのでこんなもんでしょう。
あとは独自ドメインの利用料が掛かります。
AWS以外で初年度無料のドメインもあるのですが面倒なのでRoute53で取得しましょう。
トップレベルドメインによって年額使用料が違うようです。
.casinoとか.goldとかお金関係が高いようですね。
一番安い.beにしときましょう。年間$9.00。
be 来世の自分という感じで収まりがいいです。
1か月のバランスシートを書いてみました。
| 収入 | - | 支出 | - |
|---|---|---|---|
| なし | $0 | 月額料金合計 | $0.50 |
| 独自ドメイン料 | $0.75 | ||
| 合計 | $0 | 合計 | $1.25 |
月額136円。
趣味としてはディアゴスティーニより良心な価格ですが、収入ゼロがちょっと寂しいですね。
もしもバズったときの従量課金の跳ね具合がちょっと不安です。
何か収益の方法を考えましょう。
AWSは利用料の上限を決められる機能があるのですが、せっかくバズったときにアクセスできなくなるのはもったいないですからね。
教祖系ブロガー誕生
サイトの画面にアフェリエイトを貼るのは雰囲気が壊れるので気が進みません。
サイトを作っている様子をブログに書くならどうでしょうか。
もしかしたらアフェリエイトを貼れば趣味代ぐらいは稼げるかもしれません。
実はサイトについて問題がもう一つあります。
どこから訪問者を誘導するかということです。
こちらもブログにある程度読者が付けば誘導にプラスです。
ブログサービスを選びましょう。
IT系ではQiitaが有名です。私も本業ではよくお世話になっております。
ただ、『プログラミングに関する知識を記録・共有するためのサービス』というだけあってあまり一般向けではありません。
はてなブログならはてなブックマークから読者を増やせる可能性もありますし、アフェリエイトも貼れそうです。
タイトルを決めましょう。
「シャッフル再生教」との関連性を示したいですね。
さらに他のものを作ることを考えてエンジニアの日常感を出しましょう。
『シャッフル技師の開発日誌』…、いや、
『シャッフル主任の進捗報告』がいいでしょう。
A journey to the stars
宗教の教義自体が著作権にあたるはわかりませんが、
同じようなことを考えている人がいるのか一応調べてみましょう。
結構いました。
NAVERまとめにもまとめられています。
また、人生はゲームキャラクターであり、この世界の外からユーザがログインして複数の人生をプレイしているという仮説を展開している方もいらっしゃるようです。
おもしろいですね。
また、現在ラノベ業界は転生ブームですから、過去に転生するストーリーもたくさんありそうです。
弊教団の骨子である『来世の自分かもしれない他人にやさしく』は探した限りでは見当たりませんでした。
似ている主張や作品をご存じの方がいたらコメント欄で教えてくれると嬉しいです。
そうだ、教祖になろう。創世記 第2章2節 データ構造を考える
私は私を生きてくんだ 私は私で生まれたんだし
画面イメージをパワポで書いてみました。
パワポといっても実際はPCバンドル版の
キングオフィスなんだけど。
この文章の各所をランダムで変えられるようにします。
定義すべき項目はこんな感じになりますね。
バリエーションかさ増しのために数値に関わる部分は
ランダムで変動するようにしてみます。
- だれが
- いつ生まれて（範囲内のランダム）
- どう生きて
- どういう感じで
- いつ死んだか（範囲内のランダム）
無数の命が輪廻している感じを出すには
かなり膨大なリストを書かないといけません。
通勤中とか就寝前とか思いついたときにすぐ書き足せる方法はないでしょうか。
私がよく使っているWebサービスにGoogleスプレッドシートがあります。
フリーで使えるクラウド版Excelです。
フォーマットを整えるとかの作業はPCで
ちょこっとした追加ならスマフォでできます。
試しに数行書いてみました。
これに随時追記していき、
サーバサイドで取り込んで使いましょう。
取り込みはサーバサイドからAPI（Application Programming Interface）を通して行います。
APIとは、プログラムがサーバにアクセスして
データを取得したり登録したりするための
接続ポイントです。
人がアクセスするわけではないため、画面を介さず
データをやり取りできるようになっています。
GoogleスプレッドシートのAPI仕様を見てみましょう。
rangeパラメータで読む領域を、fieldsパラメータで取得する列を指定するようです。
取得されてくる形がよくわかりません。
このAPIを使ってみた方のブログがありました。
レスポンスの中のvaluesの中に1行ずつ、
{
"range": "'シート1'!ある範囲",
"majorDimension": "ROWS",
"values": [
[
"アジアの小国の王様",
"1000",
"500",
...
],
[
"アジアの小国の王子",
"970",
"470",
...
]
]
}
という感じでで取れそうですね。
これをサーバサイドの処理で
あなたは（who）に生まれ変わりました。 （who）は（birth-min～birth-max）に生まれました。 （way-of-life）生き （cuase-of-death）（death-min～death-max）死にました。
とつなげば表示する文章が作れそうです。
サイト訪問者が想像しやすいように
実際にありそうな生き方を中心に書いていきます。
未来の生命についてはリアリティを出すために慎重に考える必要がありそうです。
サーバサイド（極楽）サイド再び
前回アーキテクチャを考えるといいながら
AWS（Amazon Web Service）使うよ。
だけで終わっていました。
Googleスプレッドシート含め、
少し具体的に書いてみましょう。
システム構成図です。
AWSが公開しているアイコンを使いました。
殺風景な我がブログに彩りが！
各要素の配置がわかりやすくなりました。
HTMLとJavaScriptを取得する流れと
1データを取得する流れが違うのは前回の通りです。
CloudFrontでS3とAPI Gatewayへのアクセスを統合します。
Route53はサイトを独自ドメインにするのに必要です。
Googleスプレッドシートには1データごとにアクセスしていますが、速度を考えると事前にAWS内のデータベースに取り込むとかした方がよさそうです。
また、Googleスプレッドシートにアクセスするには認証が必要なため、認証情報を格納しておく場所も必要そうです。
こう見るとサーバサイドが多いようですが、
クライアントサイドのHTMLやJavaScriptを生成する機構は今回はしょっています。
そうだ、教祖になろう。創世記 第2章1節 アーキテクチャを考える
私のお墓の前で泣かないでください。
アーキテクチャというのはシステムの構造です。
なんの要素がどういう役割を担うか。
処理が早くて安くて楽に作れて変えやすいシステムを作れるのが
良いアーキテクチャです。
今回のアーキテクチャを考えてみましょう。
Webシステムはクライアントとサーバで構成されます。
サーバはアプリケーションとデータベースを一元的に管理するコンピュータです。
クライアントはサーバにアクセスするためのPCやスマートフォンで複数あってよく、
インターネットを通じて世界中どこからでもサーバにアクセスできます。
仏教のお墓や位牌どこからでも極楽浄土の故人に祈りが通じるのに似ていますね。
クライアントにはサーバから返却されるWeb画面を表示します。
Web画面は見た目を定義するHTMLファイルと、
ブラウザ上での処理を定義するJavaScriptファイルから構成されます。
今回表示するのは文章と小さい画像だけなのでかなりコンパクトになります。
文章と画像は大量の候補からランダムに選びたいので
サーバのデータベースに持っておいて
クライアントからの要求を受けてサーバが選んだ結果を返すようにします。
クライアントは文章と画像をスライドショー形式で表示します。
ブラウザのページ遷移と同期せず、文章と画像の部分のみを挿し替えます。
シーケンス図で表してみました。
上から下に時間の流れ、それぞれの要素を縦の線、互いのやり取りを矢印で表します。
ブラウザがページ遷移するのはサーバからHTMLとJavaScriptを返却されたときだけで、
そのあとはJavaScriptがサーバと通信してブラウザの表示を更新していきます。
ページ遷移と一部のみの表示更新の違いが分かりづらいかもしれません。
Googleで検索した結果の2ページ目に行くときにリンクをクリックしますね。
あれがブラウザのページ遷移。
一方、TwitterやFacebookだと下にスクロールするだけで新しい記事が読み込まれていきます。
あれがブラウザの一部のみの表示更新です。
クライアント（お墓）サイド
ブラウザのページ遷移と同期せずにサーバと通信したり表示の一部を書き換えるWeb画面をSPA（Single Page Application）といいます。
Twitterなんかがその典型ですね。
このSPAの構造をいちから作るのは結構大変なのでフレームワークを利用します。
フレームワークとはあらかじめ規定された基本的な構造です。
開発者はフレームワークをベースに必要な処理だけを作っていけばいいわけです。
今回は私が前に少し触ったことのあるVue.jsというJavaScriptフレームワークを使いましょう。
サーバ（極楽）サイド
次はサーバです。
クライアントはサイト訪問者のPCまたやスマートフォンで動作しますが、
サーバはアプリケーションを動かすためのコンピュータを自前で用意しなければなりません。
以前は自宅に大きなサーバを設置してWebサイトを開く猛者もいたようですが、
今はクラウドが主流です。
クラウドはクラウド業者が持っているコンピュータを貸してもらう仕組みです。
時間課金や年間契約で支払い、コンピュータの性能で金額が変わります。
今回のWebサイトの場合、どのぐらいの人がサイト訪問者が来るか予想がつきません。
いや、はじめはほとんど来ないと言っていいでしょう。
ですので、常に一定のサーバ費用を掛けるのは割りに合いません。
そういった場合に適しているのがサーバレスアーキテクチャです。
サーバレスアーキテクチャでは必要に応じてコンピュータ資源を確保し、
使い終わったら解放します。
そのため、1秒で終わる処理なら1秒分の費用しか発生しません。
また、開発者がコンピュータを管理する必要がないため、
セキュリティパッチやライセンス管理などの面倒な作業がありません。
今回のプロジェクトに最適のソリューションというわけです。
いくつかのクラウド事業者がサーバレスアーキテクチャを提供していますが、
今回は現在最大手で私が少しかじったことのあるAmazon Web Serviceを利用しましょう。
