はじめてのウェブサイト制作[1] - はじめに

blog.li.nu >
この記事が役に立ったら

 このシリーズでは、全くウェブサイト作りに触れたことがない人向けに、簡単なウェブサイト作成の道筋を示すことが目標です。 といっても、いきなり○○言語の文法といった話から入っても難しいので、最初に、具体的な話よりもウェブサイトを作るということはどういうことか、つまりHTMLとかデータベースとかいうものがどう結びついて一つのサイトとして成り立つのかについて概観し、それからだんだん具体的な内容に入っていきます。 なお、このシリーズでは、コードや文法そのものより、考え方、概念を非常に重視します。 そのため、特に今回がそうなりますが、事前説明が非常に長いです。まずは自分の知っている限り、初めての人が特に意識すべき事を列挙しているので、そこまで詳しくは読み込まず、一通りそうなんだと思ったら次へ進むと良いでしょう。

このシリーズで作るもの

環境の構築とか、Hello Worldを表示しようというのはこの手のシリーズの第一回にはありがちな話題です。 ただ、その前に考える必要があることは、「作りたいものが明確にあるのかどうか」ということです。 今はないけれども、将来は何かやりたいということであればこの後を読んでも大丈夫だと思いますが、プログラミングに限っては形から入るより、作りたい物を強く想定したもとで勉強するのが一番効果がある、ということは先に強調しておきます。
 といっても、全員がそこまで明確に目標を持っているとは限らず、特定の何かを作りたいというよりも、コンピュータ社会の教養の1つとしてという人々も当然いるでしょうから、このシリーズでの明確なゴールを設定することにしましょう。 あまりにも独自性がなさすぎてつまらないと思うかもしれませんが、ここでは簡単な掲示板システムの制作を目指します。 ただし、そのあたりに触れ始めるのはかなり後の方で、最初はちょっとしたパーツ(必ずしも掲示板のためのものとは限らない)でいろいろ遊ぶことが中心になります。 とにかく初めての場合は触れる事になるものが多いため、いきなり本題に入らず、少しずつ導入を交えて進んでいきます。

言語よりも大事なこと

次にプログラミング言語はどれがいいかという話しになるかと思いきや、それ以上に大事なことがあります。それは、ウェブサイトの最終的な規模を想定し、それに対応できるような仕組みを作ることです。 言い方を変えれば「サイトが成功すればするほど、最初に何も考えていないと後で苦労する」ということです。これは、仮にあなたのウェブサイトを作ったとして、あなたはどこまでそのサイトを大きくしたいのか、より正確には「どこまでサイトは大きくなる可能性があるのか」を見積もり、将来そのレベルになっても容易にシステムが耐えられることが最も重要だと言っています。 大規模なサイトを作った経験はないので、自前でサーバーを何台も持つとかいうレベルの話はさすがにできませんが、サイトの種類によっては数千人、場合によっては数百人程度のユーザーしかいなくてもこれは重要な話になってきます。

 自前でサーバーを用意できる人はそう多くはないと思うので、あなたはサイトの運営にレンタルサーバーを使っていたしましょう。 携帯電話のように、実はレンタルサーバーにはほぼ確実に「転送量制限」があります。つまり、誰かがあなたのページを訪問して、1MBの画像を見たら、1MB転送したとカウントされます。 現在、常識的な値段(行って3,000円未満)で、最も転送量について寛容であるとされるレンタルサーバーであっても、せいぜい100GB/日程度が限度です。 そんなの使い切れるわけがないと思ったら大間違いで、テキストではなく大量に画像を表示するタイプのサイトだとかなり厳しく、音声や動画だったら間違いなく何もできないレベルだと思ってください。 たとえば私が運営しているウェブサイトの1つでは、ソーシャルゲームのアイテムデータベース(+α)を提供しています。 画像1枚だけなら10KBとかその程度です。しかし、1つのイベントに属しているアイテム一覧を見たいとしましょう。 もしそのイベントに存在するアイテムが50個だとすれば、それだけで500KBです。もし1万人がこのイベントを見に行けば、それだけで5GBも消費されます。 もちろん、多くのユーザーはイベントをいくつも見に行きますから、実際には遙かに多く70~80GB近くが画像の転送量で占められています。 これに加えて、外部ファイル(スタイルシートやJavascript、ウェブフォントといったものから、HTML文書そのものまで)が加わることで、さらに転送量は増加します。

 実際、転送量を超えたらどうするのかですが、より転送量が寛容なところに移行するのもひとつの手です。 しかし、数十、数百GBものデータをいちいち別サーバーに移転させるのは、自分のサーバーでない以上大変なことですし、仮にそのような方針で転々としていっても、このまま利用人数が100万人になったら、そもそも1つのサーバーでは負荷に耐えられずダウンするかもしれません。 規模が大きくなったとき、1つのサーバーですべてを済ませることはできなくなるのです。 そこで、最初からできる最低限の対策として、たとえば他人にシステムを丸ごと公開・配布するといった予定がなく、自分、自分たちだけで使うシステムだとしても、要所要所の値をパラメータ化しておく、つまり、大本の設定ファイルを1個持っておき、そこを変えるだけであらゆる場所の変更も反映されるような作りにしておくということが挙げられます。
 ここでは、先ほどの画像の置き場所について考えましょう。 何も考えなければ、"img"というフォルダ(トップページ直下のimgという名前のフォルダ)に画像をまとめて置いておくことでしょう。 ここで、サーバーの転送量が毎日上限を超えてしまい、このままでは立ちゆかなくなったとします。転送量上限は100GB/日ですが、そのうち画像が占める割合は80GB/日です。 画像のファイル名は登録時にランダムに決定され、たとえば「1867163491.jpg」といった名前になるようあらかじめ約束として決めておいたとします。 当然大ピンチなので、別サーバーに画像だけ引っ越しをさせました。新しいアドレスは http://XXX.YYY/img/ です。
 このとき、先ほど述べた方法をとった場合としない場合でいかに面倒の度合いが変わるかについて簡単に考えます。 たとえば、このウェブアプリを構成するプログラムのうち、この画像の場所を参照するものが300個あったとします。 そのすべてで "/img/xxx.jpg" といったパス(ファイルの位置)を指定してしまっていた場合、http://XXX.YYY/img/xxx.jpg にすべて置換しなければなりません。 これは大変な手間です。といっても、正規表現と呼ばれるものを使って、全ファイルで探索を適切に行えば一斉置換自体は不可能ではありませんが、これはあまり賢い方法とはいえません。 なぜなら、本番環境と開発環境ではパスが異なるので、いちいち置換させるわけにはいかない上、正規表現にミスや見落としがあると、正しく置換されない箇所が出てきて、必ず不具合の元になってしまうからです。
 そこで、次のような方法をとるわけです。たとえば、ある設定ファイルに、「今後、(画像ファイルの場所) = "/img/" に読み替えなさいという命令を書いたとします。 これをすべてのファイルで読むようにすれば、(画像ファイルの場所) ="http://XXX.YYY/img/" にするだけで一発で変更が対応します。 画像を参照するような時は、 "img/XXX.jpg" のような固定の文字列にするかわりに "(画像ファイルの場所)" と "XXX.jpg" を連結させるようにすればいいわけです。 これならサーバーを急に移転してもすぐに対応できます。
 次に、その移転させたはずの画像も転送量が100GB/日まで膨らんでしまったとしましょう。そうなると、次に画像サーバー自体を2つに増やす必要が出てきます。 そのときはたとえば、画像がランダムであることを逆手にとって、数字の末尾は偶数/奇数がほぼ確率的に均等であるはずだと考えます。 そうすると、今度は単純な固定値での置き換えではなく、「画像のURLを表示する時、末尾の数字が偶数ならばサーバー1の画像フォルダ、奇数ならばサーバー2の画像フォルダを参照しなさい」という風な命令として作っておけば、勝手にプログラムが画像のURLからどちらのサーバーに読みに行くべきかを判断してくれて、負荷の分散がうまくいきます。
 実際にプログラムを始める前に意識したいことは、このように、可変にできることはできるだけ可変にしておくという方針です。 ファイルの置き場所各種や、データベース管理システム自体にログインするためのユーザー名/パスワードといったものがその典型例になるでしょう。 多少コードは初めての人にとっては読みづらくなるかもしれませんが、一カ所変えるだけで全体がすぐ変わるというのはこの上なく便利なことです。

今後使用する言語

 結局、何らかの言語がないウェブサイトは書けません。 次に、その選定をしたいのですが、実はウェブサイトを作るときの言語は、"C"とか"BASIC"のようにたった1つではありません。 「プログラミング言語」に限定せず、相手に正しく解釈させるための独自の書式のことも広義の言語ととらえれば、たいていの場合5つの言語を取り扱うことになります。 具体的には

です。誤解の無いように書くと、このすべてがなければウェブサイトが作れないわけではありません。これは場合によります。 見た目が20年前のホームページでよく、ただ情報を発信したいだけであるなら1番だけあれば十分ですし、同様にただ掲示板とか日記システムを作りたいだけなら1番と4番さえあれば十分に実現できます。
 それぞれがいったい何者で欠けるとどうなるのかを次に見ていきましょう。

HTMLとは?

 HTMLは、あなたが表現したい文書をブラウザが分かるようにするための言語です。 言語といってもいわゆるプログラミング言語ではなくて、マークアップ言語といわれるもので、 <xx>~</xx> で囲われた中に特定の効果を適用するタグと呼ばれるもので文書の構造を定義します。 つまり、あなたの意図したとおりの文書構造をブラウザに理解させるための言語です。
 あなたが自由に単なる文章を打ち込んでも、どこが見出しであるべきか、どこからどこまでは2段組にしたらよいか、等ブラウザは勝手に理解してはくれないので、それをあなたがブラウザに理解できるかたちにして書くということです。
 HTMLにはバージョンがいくつかあり、時代の変化とともに標準的に用いられるもの、使うべきタグが変化してきていますが、2016年現在ではHTML5と呼ばれるバージョンが広く用いられています。 また、HTMLは、文法的に厳格に作らなくても割とちゃんと見える文書を作れてしまいやすい、つまり文法的には誤っていたり、本当は推奨されていないタグの使い方をしているにもかかわらず、ブラウザで見たときは間違っているかどうか見分けが付かないという、利点にように見える問題点もあります。 このシリーズではHTMLについては非常に簡易的に、つまり動けば良いの精神で扱うことにします。
 ちなみに言語は大体そうですが(といいながらこれから早速紹介するPHPにはリファレンスはあっても言語仕様書はないのですが)、言語仕様書というものが定められていて、厳密にどういう記述が許されて、どういう挙動をするのかなどが決まっています。 分からないときは大体検索することになり、その辺のブログや知恵袋の回答を参照するのが非常にかみ砕かれて書かれていて手っ取り早く、素晴らしいことなのですが、それでも解決しない場合は、言語の仕様書を見るというのが最善である場合もあります。 普段見ることはほぼないとしても、そのようなものが存在するということは知っておくとよいでしょう。
 結果、HTMLについて知らない場合、それはただのテキストファイルであり、ブラウザでは何ら整形されない、単なる文字の羅列だけが表示されることになってしまいます。

CSSとは

 狭義には、HTML自信は文書の構造を伝えるためのもの(ここは重要、ここは見出し、ここからここまでは段落、ここからここまではページの1つの区切り等)であり、その見た目については特に明確には規定されていません。 たとえば見出しを意味するタグに h1, h2, h3, ... タグというものがあり、数字が小さいほど重要度が高い見出しという意味です。実際ブラウザで表示すると、数字の小ささに合わせて文字は大きくなり、また文字は太字で表示されます。 しかし、仕様書には、このタグに囲まれたものは太字で表示しなければならず、文字も大きくしなければならないといった決まりは特に書かれていません。 タグについて規定されているのは、文書における意味上の(難しい英単語でセマンティックとも言う)用法であり、視覚的効果は、例えば見出しなら本文よりは目立つだろうといった感じでブラウザが気を利かせているだけの副次的なものにすぎません。 そこで、実際に各タグ、あるいは特定の部分だけに何らかの視覚的な効果を定義するのが、CSSの役目です。
 CSSは、HTML文書の任意の部分について、その細かな見た目を指定できます。 たとえば、あるタグに囲まれた範囲は、段組表示にして、文字サイズも何%小さくして、色はこの色で、背景の画像は・・・といったことを逐一指定します。 その無数の組み合わせであのきれいな多数のウェブサイトができているのです。 なので、ウェブサイトのデザインだけを検証したいのであれば、HTMLとCSSさえあればできます。
 結果、CSSが欠けてしまうと、「見た目が極端に味気ない」ページになります。 といっても、CSSが一般的になる前の古いHTMLの名残で、HTMLのタグでも色や背景、フォントの種類や色などを規定することは実際できてしまいますが、現在そのようなアプローチを取ることは推奨されていません。

クライアント側のプログラミング言語

 クライアントとは、情報の受け手のことを言います。つまり、ほとんどの場合はブラウザといってもよいでしょう。 すでに紹介したように、HTMLとCSSだけでは、文書の構造とその見え方を規定しただけにすぎません。 しかし、あなたは他のサイトと同じように、たとえばメニューボタンを押せばスライドしてメニューが出てきたり、あるいは画面全体がメニュー表示に切り替わったりといったことを期待するでしょう。 このように、見栄えの次に「動き」を規定するのがクライアント側のプログラミング言語です。 このような目的を達成する言語として、Javascriptと呼ばれる言語が主に使われています。使おうと思えばVBScript等、他にもありますが、実用上はJavascriptだけだと思ってよいでしょう。 ただしJavascriptはプログラミング言語としてかなり面倒であるため、Javascriptを基本にして、それを扱いやすくしたライブラリが多く提案されており、特に広く浸透しているのがjQueryと呼ばれているものです。 なので多くの場合、入門用としては「Javascriptの基本文法を少々とjQuery」といった形で作っていくことになるでしょう。 別にJavascriptだけでも全部できますし、むしろできるならその方が高速になる上、ライブラリを使うにしてもjQueryだけが選択肢ではないのですが、メニューを表示とかそのレベルであれば基本この黄金タッグで問題はないはずです。 また、jQuery自体をさらにサポートするようなプラグインも多数出ています。 なので、面倒そうなもの、あるいはどうやっていいか見当も付かないが、多くのサイトでよく見るものはたいてい「やりたいこと jQuery」で検索すればプラグインが見つかって、それを使うことでさっさと実装できます。
 ただし、ライセンスには気をつけてください。ライセンスとは利用許諾のことであり、一部は「商用利用する場合は製作者の許可を得なければならない」とか、「ソースコードはすべてを共有財産として公開しなければならない」といった取り決めになっていることもあるので、もし通販サイトなどを本当にやるのであれば、そのプラグインやライブラリは本当に作者に無断で、あるいはお金を払わないで使って構わないのか確認する必要があります。
 結論として、Javascriptがないと、全くとまで言えば嘘になりますが、基本「動きがないウェブサイト」になります。

サーバー側のプログラミング言語

 利用者、クライアントはブラウザを使ってサーバーに要求を出します。 その要求に応じて、サーバーはウェブページとしてHTML文書を返し、ブラウザはそれを受け取って実際に利用者に表示を行います。 サーバーが返す文書が完全固定の文書ならただのテキストファイルみたいなものですが、もし、利用者ごとに専用の画面を出したいとしたらどうでしょう。 Aさんが接続した場合、Aさんだと認識して、Aさん専用のメニューを出すといったことは、ただのテキストファイルにはできません。 そこで、要求を受けたときのパラメータに応じて、Aさん専用の文書をその場で動的に作り出し、HTML文書として整形して返すことが求められます。 用語を使うと難しそうに見えますが、これは非常に簡単な事で、会員登録して、登録した会員専用のメニューがまさにそういう例です。 たとえばログインしている時に「ようこそ○○さん」といった表示を出すとき、○○の部分をそのユーザーの名前にする程度のことでも当てはまります。 その結果、あなたが思いつくほとんどの用途では、このようなユーザーの種類や行動に応じて「動的」にページを生成する必要があることが理解できます。 仮に登録ユーザーでなくても、投稿がたくさんあったとき、2ページ目を表示するとか、そういうものも「動的」な生成例に含まれます。ここでサーバー側のプログラミング言語の出番です。
 基本的にサーバー側の言語に期待されているのは、プログラミング的な汎用な処理はもちろんのこと、その結果をユーザーの分かる形で動的にHTML文書に整形して返すということです。 この話から分かるように、HTML文書はただのテキストなので、要求に対してテキストである(といっても、HTML文書そのものがテキストなだけで、ブラウザが適切に機能するには他にも考慮すべき事はたくさんあります)HTML文書を適切にクライアントに返す方法を持ってさえすれば別に言語は何でもかまいませんが、特にウェブ関係の機能を備え、適しているもの(か、拡張してそうできるもの)としては「PHP」「Python」「Ruby」が有名です(他にもあるので、興味があれば調べてみてください)。
 この辺はどれも発達しすぎていて、レンタルサーバーを借りて何かするくらいのレベルなら、できることの差は全く無いといって差し支えありません。 仮に優劣を調べようとしたとしても、どれが優れている、劣っていると主張する記事はもはや宗教戦争のようなものなので、真に受けないで好きなものを選んでください。
 といっても、結局言語は選ばないと始められないので、ここではPHPを採択します。 理由は単に私が主に使っているからですが、これから書くことは書き方は違っても他の言語で絶対にできることばかりなので、他を選んだ場合でも適宜調べてみてください。 ちなみに私がPHPを使っているのは何らかの信念があってではなく、元々私はC言語から本格的にプログラミングに触れ始め、PHPがC言語に限りなく似ていて親和性が非常に高かったというだけの理由です。 差はないと書きましたが、強いて今後差が出てくるとすれば、挙げられるのは拡張性でしょう。たとえば、特に最先端分野において、優れたモジュールが多く集まることでPythonは有名です。 が、共用レンタルサーバーを使っているうちは勝手に拡張することはできない上、今後そのようなモジュールが必要になることも、はなから高度な数値計算や人工知能、言語処理といったことを念頭においていない限りはないと思われます。 それに、別に言語は1つだけでなければならないという決まりはどこにもないので、十分になれてから、そういうことをするプログラムだけPythonで、後はPHPで、ということも十分に出来ます。 結局、最初のうちは、書くのにできるだけ苦痛を感じない、自分が一番合うと思う言語を選べることが重要でしょう。 そしてその合う合わないは、他人が素晴らしいといっているかどうかとか、機能性がどうとかではなく、適当なコードをいくつか見てみて、細かい事はよく分からなくても、この書き方は自分に親和性が高いかどうかで選ぶべきです。 特にこだわりがなければ、PHP自体、初心者でも簡単に使えることが長所でシェアも高い言語なので、PHPから使い始めても結構ですが、私の説明が意味不明という理由以外で途中で苦痛に感じた場合は、諦める前に、他の言語を使うことが解決になるかもしれません。
 結論として、サーバー側のプログラミング言語がないと、「あらゆる人物に対しても決まった文書を一方的に配信するだけのサイト」になってしまいます。昔のホームページやコメント欄の存在しない日記みたいなものです。ページを数個しか作らず、ユーザーからの問い合わせはメールだけで十分で、こちらから配信さえできればOKというような場合、たとえば小規模な企業・個人のページやなんかの団体の公式サイト程度なら別になくてもいいのかもしれませんが、ユーザーの登録を受け付けたり、それぞれのユーザーによって専用の画面を作りたいといった場合はこれがなければまず成り立ちません。

データベース言語

 現在のウェブサイト制作において、サーバー側のプログラミング言語と同じくらい取り扱えることが重要であるのはデータベース言語です。 そもそもデータベースとは何かですが、粗く言うと「あるルール(構造)を持って作られたデータの集合体」です。
 たとえば、あなたのウェブアプリに登録しているユーザーの一覧をサーバーに保存しておきたいとしましょう。 登録したら、「ユーザーのID」「ユーザーのニックネーム」「メールアドレス」「パスワード」を保存しておきたいとします。 であれば、少しでもプログラミングをやったことがある人なら、あるいはそうでない人も、たとえば次のようなことを思いつくでしょう。 つまり、適当なテキストファイルに、こちらで考えたルールに沿ってこれらデータを保存しておくこということです。 ユーザーの登録があるごとに、末尾にどんどん追加していけばよいですね。 一人分のデータは、上に書いた順番でたとえばカンマ区切りという風に決めておけば良いでしょう。 実際カンマでデータを区切る方法は、最も基本的なデータの構造化の方法の1つなので、CSV形式という名前で呼ばれています。具体的には、複数人のデータがあるとすると、次のような並びになっているわけです。

tanaka_taro,田中太郎,taro@xxx.yyy,taro1234,yamada_hanako,山田花子,hanako@yyy.zzz,hanako4567, ...
別にこれでもちゃんとデータベースの一種として機能します。データベースとは、構造化されたデータの集合体のことです。 この例の場合、カンマで区切ったとき、4個ずつを1人分のデータとみているわけですが、それはデータベースの言葉で「レコード」と呼ばれるデータの最小単位です。
 このように、「データをカンマで区切った時、最初から数えて4個ごとに1つのレコードと見なし、1番目からユーザーID、ユーザー名、メールアドレス、パスワードとする」という構造の解釈方法を定義したのであれば、これはデータベースだと言っても間違いではないということになります。 この構造の定義のことは「スキーマ」と呼ばれています。そして、このスキーマに沿って集まったレコードの集合体は、縦に並べれば表のように見えることでしょう。 そのため、これは「テーブル」と呼ばれています。 スキーマはテーブルの各レコードがどういう秩序で格納されるかを規定するある種の「概念」であって、データの実体を表すものではないことに注意します(といってもこの用語は当分出てこないので分からなければ飛ばしても害はないです)。 このテーブルを、異なるスキーマでもかまいませんが、複数集めたものの集合体が一般にいうデータベースの定義です。
 名前は知っているかもしれませんが、たとえばMySQLは、このデータベースを管理するための管理システムのことで、厳密には「データベース」というよりは、「データベース管理システム」(DBMS)と呼ばれています。 データベースはただの構造化されたデータの集合体のことであり、実際にそのデータベースにデータを追加したり、たとえば複数人が書き込み操作したときデータに不整合が生じないよう調整したり、連続的にデータが操作される場合、途中で失敗したら元の状態に復旧する等、データベースの総合的な管理を引き受けてくれるのがDBMSです。 しかしながら、事実、DBMSのことを単に「データベース」と呼ぶことは非常に多いので、誤解が無い場合はここでも「データベース」と単に呼ぶことにしましょう。
 話を戻すと、非常に小規模だったりシンプルなシステムならば、上のようなナイーブな方法(何も工夫しなくてよい場合、誰もが思いつくであろう最も単純な方法)でも何ら問題はありません。むしろ、DBMSをわざわざ使わなくていいのであればその方が楽な場合もあります。 が、これから目標とするシステムに対しては、というより、たいていの用途の場合は、DBMSを使ってデータの読み書きをした方が賢明といえます。
 たとえば2016年11月現在の運用状況を元にして数字を出しますが、私のウェブサイトの場合、全訪問者のアクセス履歴(数分以内に再アクセスした場合はカウントしない)がある時点から記録されていますが、だいたい5,000万レコードあります。 これだけでギガバイトクラスのデータです。もし、今最も旬のアイテムを知りたいとしたら、この5,000万レコードのうち、「閲覧日時が1週間以内で、かつ訪問しているページがアイテムのページであるもの」を抜き出し、アイテムごとに何回訪問されているかカウントして、そのカウントの多さの順番でソートするということをしなければランキングが作れません。
 上で書いたようなナイーブなCSV形式のテキストデータを解析したら、いったいどれだけの時間がかかるでしょうか。 そもそも時間以前に、その処理はどうやって実装すれば実現できるのでしょうか。別のテーブルでも似たことをしたい場合はどうでしょうか。
 このような面倒ごとをすべてSQLと呼ばれる言語を窓口にして引き受けてくれるのがDBMSというわけです。 DBMSは、上のような要求に対して、次のようなSQL文と呼ばれる文章を発行するだけで高速にデータを返してくれます。 ちなみにMySQLで実行させると、レンタルサーバー上(共用サーバ)で実際に運用されているデータに対して0.1秒くらいで終了します。
SELECT `アイテムのID`, COUNT(*) AS `カウント数` FROM `アクセス履歴` WHERE `アクセス日時` > NOW() - INTERVAL 7 DAY AND `アクセス種類`="アイテムの閲覧" GROUP BY `アイテムのID` ORDER BY `カウント数` DESC LIMIT 0, 30
構文に対する説明はここではしませんが、ORDERが順番という意味の英単語であるとか、DESCがDesend(降順)の頭文字であるとかが分からないくらい英語が壊滅的でなければ、だいたい想像はつくことでしょう。 このような文章をDBMSに投げるだけで、5,000万レコードの中から、1週間以内に記録されたアイテムに対する閲覧履歴を集計し、カウントが最も多いアイテムを30個上位から抜き出して結果を返してくれます。 どうすれば効率的にデータを抜き出せるかとか、どうすればソートできるかといったことは我々が考える必要は無く、DBMSが自動で行ってくれます。しかもそれはとても高速です。
 といっても、これはいくらか嘘が含まれているので注意してください。特に「高速」の部分ですが、高速に情報を抜き出すためには適切に「インデックス」と呼ばれるものを生成する必要があります。 これはタウンページみたいなもので、インデックス、つまり索引が適切に存在しないと、DBMSは最初のページからバラバラとタウンページをめくりはじめるので、結果何分、何十分といった実行時間になる恐れがあります。 さらに、インデックスは万能ではなく、特に集計が絡んでくるとともにデータが膨大である場合には、定期的にサーバー側で集計を取って、ユーザーにはリアルタイムで集計しないでその時の集計結果を見せるという方法が適切なこともあります。
 このようにDBMSは大量のデータを簡単かつ効率的に管理するために必要です。ここでは実装の簡便さというだけの観点から紹介しましたが、他にも、結合に代表される、テーブル同士の演算の柔軟性なども(リレーショナル)データベースの魅力です。 結果、DBMSを使わないと、(多くの場合)データの管理が非常に面倒になり、特に書き込みや書き換えが絡む場合、システム全体の信頼性も低下します。 たとえば複数のデータを一気に書き込みたい時(この一連の動作をデータベース用語で「トランザクション」と呼びます)、1個でも失敗したら普通は全部をなかったことにしたいでしょうが、そういう面倒なことも、命令さえ書いておけば具体的にどうすれば実現できるか特に考えることなくDBMSは結果が適切になるよう引き受けてくれるからです。 自分で実装したら、確実に劣化版になってしまうでしょうし、もし不具合があったらそれだけで謝罪もので、お金を取っているなら最悪訴訟に発展するかもしれません。
 なお、このシリーズでは、DBMSとしてはMySQLを前提にして進めていきます。別に他のDBMSを採用してもかまいませんが、その場合、SQL自体にも方言があるので注意が必要です。 SELECT文やUPDATE文といった基本的な構文はどのDBMSもほぼ一緒ですが、細かいところで用意されている便利な関数等がDBMSによって違ってきたり、一部書き方が全く違うところもあるので、他のものを選んだ場合は自分で調べて適宜動く形に読み替えていく必要があります。

普通のプログラミング言語と違うこと

 普通のパソコンやiPhoneで実行するアプリを作ったなら、万が一不具合が含まれていたとしても、プログラムがクラッシュ、あるいは最悪そのパソコンがダメージを受ける程度で済むでしょう。 初代ポケモンではよくありましたが、画面が突然めちゃくちゃになっても、笑えるだけで済みました。 しかしながら、ウェブサイトで不具合が含まれると、笑えない自体が発生する可能性があります。 なぜなら、特にユーザーの登録を受け付けるウェブアプリの場合、そこで取り扱っているデータ(メールアドレス、パスワード)はまさに個人情報であるからです。 もし1万人の登録者がいて、何者かがそれをすべて盗んでいき、悪用したらと考えると、非常に恐ろしいことです。 そして、インターネット上には、こういうことを狙ってウェブサイトに攻撃を仕掛ける人たちがいます。 もちろん、サーバーとして機能させるためのソフト、それからプログラミング言語そのものなど、インフラ的な存在に欠陥があってこのような問題が起きることもありますが、それ以上に恐ろしいのは、実はセキュリティ上の「隙」は実装次第で簡単に作れてしまうという事実です。
 後者が原因である攻撃の代表例として、SQLインジェクションやXSSといった攻撃手法があります。 先ほどSQL文の例を紹介した流れで、前者について簡単に説明すると、実はあのSQL文は、そんなことでいいのかと初めての人は思うかもしれませんが、プログラミング言語からそのままテキストとしてDBMSに送っています。 そして、例えばページ数や検索条件など、一部をユーザーの入力によって可変にしたいという欲求は当然あるでしょうから、実際にはその一部はユーザーの入力により可変です。 この事実を悪用して、その可変部分にうまい具合に文字列を流し込むと、例えば「表を全消去」とか「本当は検索条件に適合しないのに無条件で適合したことにする」といった文に書き換えられるような場合が出てきてしまうのです。
 もちろん、代表例というからには対策もあり、そうならないようにSQLの文法に絡んでくる特定の文字を無害化(エスケープ)したり、そもそも文の通知とパラメータを分けてDBMSに与えるといった方法(プリペアドステートメント)があるので、適切に実装すれば過剰に恐れることはありません。 攻撃はいろいろあるものの、基本的には適切に実装する限りリスクは最小限に抑えられるため、実装が悪いせいで攻撃の隙を与えてしまうことは、できれば避けていきたいところです。 と、書いている私もそういうシステムを作れていると100%言い切れはしないので、これからますます気をつけていきたいところです。

サーバー選び

結局、これからは「PHPと呼ばれるサーバー側の言語を使い、ユーザー情報といったデータの保存はMySQLで管理した上で、CSSで見栄えを、Javascriptで動きを加えたHTML文書を生成する」ことになることを理解しました。 いきなり全世界に公開は怖いので、広告とか分析ツールの話も含め、サーバー選び、ウェブサイト開始後についての話は最後の最後に詳しく検討することになると思いますが、まずは全体像を把握したいので、とりあえず紹介しておきます。
 あなたが、自分のパソコンでサーバーを建てるという、無限大の自由度と性能を追い求めるかわりにセキュリティや物理的、金銭的リスクを積極的に負うチャレンジャーでない限り、ウェブサイトを公開するにあたっては業者から次の3種類のどれかを有料で借りることになります。 どれもピンキリなので、ひとまとめにはいえませんが、傾向だけでいう上に行くほど安く、(金銭的、技術的などいろいろな意味で)難易度も低くなりやすいです。 現在ではVPSやクラウドサーバーといったサービスが急激に普及しているので、流行を追うならそのあたりから初めてもいいのかもしれませんが、拡張性を犠牲にする代わり、いろいろ管理が楽なので、できるなら入り口は共用サーバーの方が私はいいと思っています。

共用サーバー

 昔ながらのレンタルサーバーです。物理的なサーバーを多数のユーザーで共有して、そのサーバーのディスク容量の一部を借りる形になっています。 利点として、管理は全部提供会社がやってくれるのでメンテナンスが楽であること、月額料金が安いのこと、さらに基本的なシステムは全部入っているので始める敷居が限りなく低いことが挙げられます。
 問題点としては、拡張性が全くない、つまりサーバーにないものは(そのサーバーだけの契約で済ませることは)諦めなければならないということが挙げられます。 たとえばPythonで人工知能をやりたいといっても、そういうライブラリは移り変わりが激しく負荷も大きいので普通のレンタルサーバーには入っておらず、そういう場合は他の選択肢が好ましいといえます。 逆に言うと、そういう高度なことをやらないなら、こんなに楽な選択肢はないといえるでしょう。
 ただし、共用サーバーは他の選択肢に比べて拡張性はもちろんのこと、それ以外でも制限が多いのでそこはよく調査するようにしてください。 特に一部の業者の共用サーバーは想定する規模、用途によっては表面上そう見えなくても「地雷」になることがあります(転送量が低すぎる、性能が低すぎてまともにサイトを運営できない等)。 例えば私自身の体験談だと、元々さくらインターネットのプレミアムプラン(1,500円くらい)を使っていたのですが、MySQLがあまりにも遅すぎてストレスを覚えたため、性能が高いことを売りにしているXServerのX10プラン(月1,200円くらい)に引っ越したら、料金が安くなったのに速度が10倍以上速くなって驚いたことがあります(ただしこの話は1年以上前のことなので、今はもう向こうも性能が上がっているかもしれません)。

VPS

 最近流行っているのがこれらのタイプのレンタルサーバーですが、特に明確な必要性を見いだせないなら、VPSやクラウドサーバーにどうしても触れたいという何らかの前提がない限り、最初の一歩にはしない方がいいでしょう。
 なぜならば、利点・欠点がだいたい共用サーバーの逆だからです。こういうサービスは、物理的なサーバーに多数の仮想マシンが走っています。仮想マシンというのは、たとえばWindowsの中でWindowsやLinuxをたくさん起動して、1つのパソコンに複数台のパソコンが別々にあるかのように見せかける技術です。 このことを利用して、1台のパソコンにたくさんの仮想OSを入れ、その1つ1つを販売するのがこの手のサービスの特徴です。 つまり、あなたは1つのサーバーを、ハードウェア的には結果皆と共有しているのですが、あたかも自分専用のようにして自由度無限大で利用できるというのが利点です。 なので、何か入れたいと思ったらたいてい何でも入れることができます。 逆に欠点としては、自分でOS含めて管理しなければならないため、この部分だけで学習コストが大きくかかってしまうという点があります。
 また、このVPSと似ている選択肢として、クラウドサーバーと呼ばれる、CPUのコアとかメモリ、容量、その他多数のモジュールを購入して、好きな時に拡張、リソースが余っているときは削減して容量節約といった使い方ができるタイプのサービスがあります。 ただし、この手のサービスは、一般に拡張性や柔軟性を求めるほど、料金体系も携帯電話の上を行くくらい複雑になってくる上、利用料金も月額ではなくて秒間課金とか、転送量も従量課金など、分かっていないと非常に高額な請求を受けるリスクもある場合が存在するので、やはり最初の一歩にはしない方が無難です。 最初はできる限りウェブサイトそのものを開発運用することに専念できる環境を選びましょう。

専用サーバー

VPSからVを抜いたもので、文字通り物理的なサーバーをまるごと1台借ります。性能は無限大ですが、値段が非常に高く、だいたいまともな性能なものを借りると年間数十万~は免れません。 金銭的な意味で全くお勧めできない選択肢です。
 また、ある意味では自宅サーバーもこれに含まれますが、自宅サーバーはさらに止めた方がよいと私は考えます。 絶対にしてはいけないとまでは言いませんが、最初の一歩にしてはリスクが大きすぎます。 例えば先ほど紹介した「下手な実装」の上位層版で、最悪あなたのコンピュータが乗っ取られて、そこからさらに何らかの攻撃に荷担することになってしまうかもしれません。 さらに、一般の回線は上り制限、つまり一般利用者からの訪問で転送できるデータの上限を設けているものが多く、だいたい数GB~数十GB転送したらそれ以上はアップロード不可能になることや、普通のプロバイダはあなたのパソコンに固定でIPアドレスを割り振らないので、場合によっては普通のプロバイダではなくて法人向けの高額なプロバイダが必要になります。 しかも、自宅サーバーは基本無休で稼働することが求められます。電気代はそこそこの性能でも行って数千円レベルなのでせいぜいお小遣いが飛ぶレベルですが、心配なのはそんなことより安全面です。例えば安物電源なんかを使っていると、突然煙を噴いてご臨終といったリスクもあります。 サーバーが止まるだけならまだいいですが、それで火が出てもし火事になったら損害は電源とサーバーが停止していた時間だけの収益ではおさまらないかもしれません。

この後の流れ

 まずはウェブサイトの構成と、全体的な考慮事項を概観しました。 最初は環境構築を一通りやるという流れもあり得ますが、ひたすらインストール地獄で面白くないので、最初のうちはメモ帳とブラウザだけで済む HTML、CSS、Javascript (jQuery) に慣れることに専念していきます。 その後、これらを簡単に扱えるようになったら、実際に開発環境を導入して、PHP、MySQLの導入に入っていきます。

その他の記事

コメント

名前 :
電子メール :
URL :
コメント