このたび「WordPress 高速化＆スマート運用必携ガイド」が発売されました。昨年の夏頃、WordPressのプラグインを公開したり最近話題のNginxのことにも詳しい@wokamotoさんにバックエンドの高速化を担当してもらって、フロントエンドの方はボクが書いてWordPressの高速化について書けば面白いんじゃないかな？と思い立ちましてね。

ボクの原稿の進みが遅いのもあって発売が今頃になってしまったのですが、この書籍はWordPressを中心にすえつつフロントエンドとバックエンドの双方の面からWebサイトのパフォーマンス改善について書いたものになっています。

これまで、2009年の12月に「Webサイトの高速化的な話をWD誌で」、2010年の夏には同じくMdNさんから「HTML+CSSコーディング ベストプラクティス」の中の一部の章で高速化について書いています。それから2年弱経ちましたが、まわりを見渡しても日本ではまだまだパフォーマンスを考慮したサイトの数は多くありません。世界レベルでみたWebコンテンツの平均値はこのような感じです。
→ HTTP Archive – Trends http://bit.ly/zaiu4W

ちょうどいい事例があったので…

こういうことを書くとDisってると誤解されるのであまりよくはないのですが、先日おこなわれた東京マラソンの公式サイトもどうやらWordPressで構築されています。大量のアクセスが想定されるなか前日には見事に落ちてましたが、これが落ちた一因はそのサイトの作り方にあるんじゃないかなぁ…と。普通に閲覧してる分には「そんな遅くもないじゃん」と思われるかもしれませんが、大量にアクセスが集中した場合には結構大変な作りになっているんですよね。

現在もそのままで公開されていますので、ちょっとHTMLソースを覗いてみましょう。レガシーブラウザへの対応のためか、CSSは頭のとこで＠importを使って読み込まれていますが、そこには再度読み込み指示があって19個のCSSが記述されています。またサイトの描画に必要なのか、JavaScriptも7つほど（うち1つはGoogleから）参照されるようになっています。

CSSにしてもJavaScriptにしても、HTMLがロードされたらそこに記述された内容を整形するために必要でしょうから、最初にロードされてきます。バックエンドがどうなってるかわかりませんが、同じサーバから出てくるのが合計25個。最初の段階でこれじゃダメですよね…。

HTMLの整形に必要なファイルをこれだけ多くのファイルに分割してリクエストを出していたら、ブラウザの1ドメインあたりのコネクション数を食いつぶします。これらが落ちないことにはどうレイアウトしていいかもわからないわけですから、表示にさえ至らないということになりますね。このサーバへリクエストしてからページができるまでのデータの流れを図式化したのが以下のものです。

→ データのウォーターフォールチャート（フルサイズ: 1.3MB）
→ データのウォーターフォールチャート（ミニサイズ: 880K）

どうでしょうか。海外からのリクエストなので秒数は多少さっぴいて考えたとしても、4秒ぐらいまではCSSとJavaScriptのリクエストです。それらが落ちて開放されない限り他の画像などの要素も落ちてきませんので、それ以降のリクエストが繋がるの待ち状態（青緑のバー）。ブラウザの並行ダウンロードが仮に6個ずつだとして…、表示が完成するまでにはこのような流れになってしまう。ブラウザ側へ落ちなければサーバ側も開放されません。つまり、大量のアクセスがあった場合は最初の段階で完全に止まってしまってもおかしくないわけです。

こういうのはフロントエンド側でもっと大量かつ高速にさばけるような改善もできるし、インフラをちょっと変えてあげてさらなる高速化をはかることもできます。要は作り方なのです。そんなことがこの青い本に書いてあります。

VPSのことについても書いてあります

本書はWordPressのことがやや多いものの、内容は多くのWebサイトの高速化にも役立つものだと思います。特にこれまでホスティングの自由度が高くないため、泣く泣く諦めてたかもしれないWebデザイナーさんたちのために、VPSの導入からサーバのインストールや設定についても書かれています。これまでパフォーマンスを意識したことがなかったWebデザイナーさん、バックエンドは得意だけどフロントエンドは詳しくなかったエンジニアの方のお役に立てれば。

最後に本書のはじめにをここに転載しておきます。本屋さんで見かけた際には是非手にとってパラパラと眺めてみてください。

今、Webサイトにはスピードが求められています。8秒ルールといわれていたのは昔の話、今ではブロードバンド回線の普及もあり、世界的な基準は3秒以内に表示が完成しないと遅いといわれており、その速度は検索ポータルの表示結果にも少なからず影響を与えるとされています。

また、この数年でスマートフォンやタブレット端末といった小型PC並の性能を持つスマートデバイス が登場し、自宅や会社以外から電話回線経由でのWebサイトのアクセスも増えています。

しかし、日本のWebサイトの多くは旧来のまま、全体的に見てもWebサイトの表示スピードは速いとはいえません。回線が速くなればページはすぐ表示されるもの、電話回線経由ではすぐに表示されてほしい、利用者の立場ならそう考えるのは至極当然のことといえるでしょう。

本書は、世界中で広く用いられているCMSである「WordPress」を中心に据えながら、このWebサイトの遅さの原因とその改善手法を紹介する書籍です。WordPressは、その仕組みから一般的なWebサイトと比較して反応速度が遅いと捉えられがちです。

しかし、実際のところはそうではなく、遅さの原因は作り手側の問題であることの方がほとんどです。この表示スピードが遅いという誤解をとくべく、HTMLやCSS、JavaScriptといったフロントエンドの面、そしてWebサーバやPHP、MySQLサーバといったバックエンドの面の双方から改善手法を解説しました。

さらに、安価で自由度も高く注目を集めるVPSについても、敷居が高く感じてしまいがちなWebデザイナーの皆さん向けに、その導入方法から運用における注意点にも触れました。

検索エンジンとも親和性の高いWordPressをより高速にして、利用者にストレスを感じさせないWebサイトに。本書が、Webサイトを運営される多くの方々の一助になれば幸いです。

→ WordPress 高速化＆スマート運用必携ガイド（Amazon）
→ WordPress 高速化＆スマート運用必携ガイド（Facebookページ）

＃本書の内容にプラスしながら、来る4月21日（土）には「WordBench 埼玉勉強会」でこの高速化について講師的な立ち位置で出席予定です。こちらもお時間のある方はいかがでしょうか。

で、その新しいプロフィール画面のタイムライン表示なのですが、リンクやいいね！したページなどの表示のされ方がこれまでとは扱いが変わっています。コメントとは別枠表示であることは従来と同じなのですが、ちゃんと枠どりされて表示されるようになっています。

流れていくフィードはもちろんですが、このプロフィールのエリアでシェアやいいね！されたリンク先の情報を綺麗に見せるためには、OGPの設定をちょっと見直した方がいいかな？ということでちょっと調べてみました。

「og:image」はサイズを「横幅100px × 高さ116px」、日本語の場合は「og:description」を80〜90文字以内ぐらいにおさめるのが良さそうです。Macでしかみてないのですが、ご参考までに。

最初はホームのアイコンから起動できる方が便利じゃね？と思ったんですが、考えてみたら他のアプリ起動中でもスルスルッと通知センターをドラッグすればアプリが起動できるので意外と便利です（笑）。では、いってみましょう。

（追記）8つ登録できる別のアプリも出たみたいなので下にリンク入れてます。

まずは、通知センターの設定を

最初に言っておきますが、有償（170円）のアプリです。

アプリをインストールして起動したら、通知センターの設定を変更しなければいけません。具体的には…、

• アプリの通知を有効にする
• 最新の5個を表示
• 表示方法は「None」
• バッジとかサウンドはオフ

こんな感じです。

通知を有効にして、最新の5つを表示します。

アラートの表示は一番左の「なし」でオッケイ。その下に並んでる「バッジ」とか「サウンド」はナシにしておきましょう。

通知センターから起動するものを追加する

App Switcherにもどって、左下の「Quick Launch」のタブを選択して、通知センターから起動したいアクションを追加します。右上の「＋」ボタンがアクションの追加です。

ポチッと押すと、アクションの追加画面に移動します。ここで設定できるのは、表示名とアイコン、そしてアクションの内容です。

初期設定されてるアイコンはタップすれば、プリセットされたものとかライブラリから選択できます。どのみち、通知センターの画面には出てきませんから何でもいいです（笑）。

通知センターに出てくる表示名をいれて、次にやりたいアクションを追加します。電話するのか、メールするのか、アプリを起動するのか、ってことですね。

アプリを起動する場合は「URL」をタップしましょう。インストールされたアプリは、たとえばTwitterなら「twitter:」っていう書き方をすれば呼び出すことができるんですね（このURLスキームってのはアプリ毎に違います）。

自分の使っているアプリとか調べたかったら「handleOpenURL」で調べることもできますし、有名どころのものはApp Switcherのサイトから直接登録することもできます。

こんな感じですね。

iPhone版が出て最近話題になっているFlipboardは「flipboard:」って入れれば大丈夫です。他をあげておくと…、Twitter（公式）は「twitter:」、Tweetbotは「tweetbot:」、Facebookは「fb:」とかですね。その他マニュアルはこちらに。

（追記）システム設定まわりのもろもろはこちらを参考に。

登録したアクションを通知センターに登録

アクションを追加しただけでは、通知センターには表示されません。今度はApp Switcherの右下の「Setup」のタブに切り替えて、4つの空欄に登録したアクションを追加します。

残念ながら4つまでしか登録できないんですが、通知センターに表示する順番で右側の「＋」ボタンを押してアクションを登録しましょう。

「Show Quick Launch」は、App Switcherの画面を表示しますので、アクション自体をたくさん登録しておけばそこから起動できます。登録が4つまでしかできないのが残念なところですが、他のアプリを起動中でも通知センターをスルスルッと引き出せばいいのは案外便利です。

→ Pepper Stuff – App Switcher

（追記）こんな記事を書いてたら、なんか8個登録できるのも出たみたいですね（笑）。詳しくは以下のサイトをご覧ください。

→ [FlashLaunch] – 通知センターにWi-Fi/輝度などの設定ショートカットを置くならApp SwitcherよりFlashLaunchがおすすめ | iPhone/iPadアプリを紹介するAppPot

OS XでWebサイトのテスト環境を作る方法はいくつかあります。お手軽なのはシステム環境設定から「パーソナルファイル共有」を有効にする方法ですが、これだとHTTPサーバである「Apache」が有効になるだけ。

じゃあということで、「MAMP」とかを使うと簡単に「Apache＋PHP＋MySQL」な環境は用意できるものの、あらかじめパッケージングされた内容になってしまう。環境をゼロから作ることを考えたら圧倒的に簡単ですが、サイト開発とか実行環境に必要なものを適宜導入しようと考えたらちょっと役不足。

ならばと、公開されているソースを必要に応じてコンパイルして…でもいいけどそれは面倒というかわかる人しかできません（わかっていても本業じゃないと面倒くさい 笑）。となると、「Fink」や「MacPorts」といったパッケージ管理ソフトを使って、システムに極力影響を与えないようにして別のUNIX環境を作る方法は割と一般的。

とは言うものの、既にOS Xで動いてるのも再度入れることになったり、OS自体をアップグレードしたら動かなくなったりもします。そうなったら、もいっかい環境を再構築したりと面倒なことこのうえないんですよね…。というわけで、今回はWordPressぐらいならすぐ動かせるように、できるだけシステムに手を入れることなく、でも比較的自由度の高いApache + PHP + MySQLな環境を作ってみたいと思います。

やさしめに書いてたら異常に長くなってきたので、まずは第1回目として「Apache編」として公開します。

ApacheとPHPは、システムに入ってるのでやっちゃうよ

OS自体は既にLionなボクのMacBook Pro。テスト環境をどうしようかと考えていたら、西の方から「MacPortsじゃなくて、Homebrew 使ってみたら？」という神の声が。「Homebrew」は、OS Xにインストールされていないソフトウェアをパッケージで管理するFinkやMacPortsと同じようなもの。それらとの違いは「システムにないものだけを入れる」というスタンスになっているとこでしょうか。

そこで今回は、「システムにあらかじめ入ってるものはそのまま使う。ないものはHomebrewで個別にパッケージを追加する」という形で構築することに。これなら同じソフトウェアの複数のバージョンが混在することもないし、何よりもHomebrew自体が簡単でわかりやすい。

で、今回の構成は以下のようにしました。

• Apache: OS Xの中に入ってるもの
• PHP: OS Xの中に入ってるもの
• MySQL: Homebrewで追加

段階的にやっていくので、自分が必要なとこで止めてください（笑）。ちなみに真っ新のLionを使ってますから、システムを上書きアップグレードしたようなその他の環境での動作を保証するものではありません。ご注意ください。

OS XのApacheを有効にする

OS Xには、世界的に圧倒的なシェアを誇るHTTPサーバの「Apache」が入っています。入ってますが、動いてません（笑）。Apacheを起動時に立ち上げるには、システム環境設定の「共有」にある「パーソナルファイル共有」を有効にします。チェックボックスをオンにするだけなので簡単です。

起動したら、適当にブラウザを起動してそこに書いてあるIPアドレスを入力すればサイトが表示されるはずです。上にある「パーソナルWebサイトフォルダを開く」を押した場所を今回は使っていきます。普通に起動したら「自分のホームフォルダ→サイト（もしくはSites）」が初期設定になってるはずです。まぁ、場所も名前も後からどうにでもできるので何でもいいです。

とりあえず、起動しといてください。

バーチャルホストを使えるようにする

次のステップです。初期設定では自分のホームフォルダの「サイト」フォルダ以下が、俗にホスティングサーバなどで言うところの「サイトルート（ドキュメントルート）」にあたるわけです。通常のホスティングサービスの「public_html」とか「htdocs」にあたるものだと思ってください。

静的なWebサイトを作るぐらいだったらサイトフォルダを使って相対パスでゴチャゴチャやっても問題ありません。ただ、「ドメインベースでテストサイトを作ってサクッと移行したい」って時には、ファイルのパスとかを書き換えたりするのは面倒ですよね。CMSのようにDB内にシステム情報が書き込まれる場合とか（置換すりゃいいだけとはいえ）。

だったら、プロジェクト毎に作ったフォルダ自体を仮想のホスト（Webサーバ）と見立てて、適当なローカルドメインや実際に稼働するドメインとかでアクセスできた方が都合が良い。そこで登場するのが「バーチャルホスト」。ホスティングサービスでもマルチサイトを管理できるところでは普通に使っている機能です。

Apacheの設定ファイル

はい、ここからは黒い画面（ターミナル）を使います。いかんせんシステムの中のファイルをいじったりするので、時にはスーパーユーザー（root）にならないと編集・保存ができないファイルもあります。今回は、直接OS Xの中に入ってるApacheとかの設定ファイルには極力変更を加えないようにしていますが、それでもこの先は黒い画面での入力が必須です。ターミナルを起動しましょう。

その前に、OS XのApacheの設定ファイルのこと。

• /etc/apache2
• /etc/apache2/httpd.conf
• /etc/apache2/other
• /etc/apache2/他いくつか

Apacheの設定は「/etc/apache2」にあります。「apache2」の中にはいくつかのファイルやフォルダが入っています。設定ファイルはその中の「httpd.conf」というテキストファイルです。ただ、この設定ファイル、1文字でも間違えようものならApacheが起動しなくなります（それだけは覚えておきましょう 笑）。「other」というフォルダは、そこに設定ファイルを書いて放り込めば内容を起動時に反映する仕組みになっています。

黒い画面になれてみる

じゃ、そろそろ黒い画面になれてみましょうか。ターミナルの黒い画面に「マシン名:~ ユーザ名$ 」ってのが見えていて、入力を促す長方形のキャレットがチカチカしてるかと思います。まずはそこに以下のテキストを入れてみます。

open /etc/apache2（リターン）

コマンドラインなので何か1行入力したらリターンを押すと（実行すれば）、そのコマンドを実行した結果が現れます。どうなりましたか？「/etc/apache2」のフォルダがFinderで開きますね。そこに先ほどの設定ファイルなどが並んでいるのがわかるでしょう。適当に「httpd.conf」とか普通のテキストエディタで開いてみてください。英語が一杯書いてありますね。じゃ、黙って閉じましょうか（笑）。

せっかくなので他のコマンドも試しましょう。

ls /etc/apache2

これを実行すれば、今見ている「/etc/apache2」に含まれるファイルが黒い画面の中に一覧表示されます。ただ、それだとファイルなのかフォルダなのかも分かりません。

ls -l /etc/apache2

「ls」に続けて半角スペースと「-l」を入れてまた実行してみましょう。今度はリスト表示されますね。「r–r–r–」とか「rwx-r-x-r-x」はファイルやディレクトリのパーミッション、「root」「wheel」はそれぞれ「所有者」「グループ」をあらわしています。「httpd.conf」などは「444」なので、実はそのままだと書き込み権限すらありません。こんな感じでコマンドには「-」で始まるオプションを指定することで、コマンドの実行結果が変わるということを覚えておきましょう。

困った時は、「コマンド名 –help」「man コマンド名」などを実行すれば何かヒントが出てきます。

バーチャルホストの設定をする

さて、初歩的な話はそれぐらいにして本題に。あやうく忘れるところでした、バーチャルホストの設定するんでした（笑）。実はバーチャルホストの設定のテンプレートは、「/etc/apache2/extra」の中にある「httpd-vhosts.conf」というファイルで、それを編集したりコピーしてもいいんですが今回はこれは使いません。

先ほど確認した自分のホームディレクトリの中のサイトフォルダに、新しく真っ新な設定ファイルを作って入れてしまいましょう。ローカルで作業するだけで外からのアクセスがないでしょうから、その方がバーチャルホストの管理がしやすいでしょうしね（※ホスティングとかではできませんし、決して同じようにしないでくださいね 笑）。ターミナルから次のコマンドを入力します。

touch ~/Sites/httpd-vhosts.conf

このコマンドを実行すると、サイトフォルダに「httpd-vhosts.conf」ができます。touchはファイルを作るコマンドです。「~（チルダ）」はホームディレクトリを意味しますので、「ホームディレクトリのサイトフォルダにhttpd-vhosts.confを作る」って意味です。ついでに新規でフォルダも作ってみましょう。

mkdir ~/Sites/logs（リターン）

「mkdir フォルダ名」は指定した名前でディレクトリ（フォルダ）を作ります。Finderでいうところの「Cmd+Shift+N」のこと。ファイルやフォルダを消す時は「rm 消したいファイル名」を実行しますが、フォルダは中にファイルがあるとそのままでは消せません。中身がある場合は「rm -r フォルダ名」とかで。ただし、ゴミ箱に移動するとかではなく、即削除されるのでくれぐれも注意しましょう。

これでサイトの中に「logs」というフォルダができました。ログが入るディレクトリなので、念のためパーミッションを「777」に変更しておきます。「chmod」というコマンドはファイルのパーミッションの変更です。「777」は「rwxrwxrwx」と同じ意味、読み書き実行のすべての権限を全てのユーザに与えた状態です。

chmod 777 ~/Sites/logs（リターン）

（追記）これでサイトフォルダの中に「httpd-vhosts.conf」と「logs/」のディレクトリができたのですが、先ほども書いてるようにあくまでローカル環境での構築、他の第三者のアクセスは想定していません。通常はこのように同じネットワークに繋がってれば閲覧できる「公開ディレクトリ」内にこういったファイルを置くことはしません。通常のホスティング同様、他からアクセスすることのできない「非公開ディレクトリ」に入れておく方が安全です。なので、ここでは説明を簡潔にするためにこうしていますが、「~/Sites/」以外のディレクトリにファイルは置いておきましょう（Thanks @sada_h）。

せっかくだから、viで編集してみよう

ではこれも有効に活用しつつ、以下の内容を空の「httpd-vhosts.conf」にコピペしましょう。「#」で始まる行はコメント行です。ところどころにある「/Users/name/Sites」の「name」は自分のユーザー名に置き換えてくださいね。コードが読みにくい方は、こちらのテキストファイルを使ってくださいな。

# ここから---
NameVirtualHost *:80

# ---ここまで

普通のテキストエディタで「httpd-vhosts.conf」開いてペーストして編集して保存でも構いませんが、せっかくだから黒い画面でやるならこうです。

cd ~/Sites（リターン）
vi httpd-vhosts.conf（リターン）

「cd」は作業ディレクトリの変更、「vi httpd-vhosts.conf」はviというエディタで「httpd-vhosts.conf」を開きます。vi（vim）のマニュアルというかコマンドの詳細は多く公開されていますので、そちらを検索してご覧いただくとして。

一度「i」のキーを押すとキャレットのある位置で「入力モード」に切り替わります（「a」を押すとキャレットの次から）。入力モードになったら「Cmd+V」で先ほどコピーした内容をペーストします。「esc」を一回押せば「コマンドモード」に戻ります。編集作業はマウスが使えません。キャレットの移動もすべてキーボード操作です。上下左右の移動は矢印キーでも大丈夫。

「:（コロン）」を押すとコマンドが入力できるので、それを開いたまま一旦保存するなら「:w」を入力してリターン。保存して終了するなら「:wq」か「ZZ」を。保存しないで閉じるなら「:q!」をそれぞれ入力してリターンです。キャレットの位置の文字を消す時はコマンドモードで「x」、1行消すなら「dd」、3行消すなら「3dd」という風に操作します。

下の方の「<VirtualHost *:80>〜</VirtualHost>」の部分がバーチャルホストの設定です。「#」のコメントを取って、内容を書き換えましょう。

コマンドモードで「/」を入力すれば文書内でキーワードを検索できます。この場合は「domain」と入力してリターンキーを押せば、その文字列部分にジャンプできます。

「ServeName」はサーバ名（ホスト名）、「DocumentRoot」にはバーチャルホストのドキュメントルートを絶対パスで指定します（この場合は、test01.local というディレクトリ）。あと、「DirectoryIndex」がインデックスファイル名。左から順番にファイルが探索されます。このあたりを書き換えるとこんな感じです。

<VirtualHost *:80>
ServerName test01.local
DocumentRoot "/Users/cipher/Sites/test01.local"
DirectoryIndex index.html index.php index.phtml
CustomLog "/Users/cipher/Sites/logs/test01.local-access_log" combined
ErrorLog "/Users/cipher/Sites/logs/test01.local-error_log"
</VirtualHost>

このように、バーチャルホストの設定はパスさえちゃんと書いてあれば、自分が置きたい場所を適当に指定して大丈夫です。今回は単に管理をしやすくするために「~/Sites/」以下にして、同じ記述でコピペで楽をしているだけです。

デスクトップが良ければ、「/Users/自分のユーザー名/Desktop/example.com」とかでも構わない、と。ログは「CustomeLog」と「ErrorLog」のそれぞれに先ほどの「logs」が指定されていますので適当に置き換えましょう。「CustomLog」の最後にある「combined」はログの記録モード指定です。

このひとつの塊がバーチャルホスト設定になります。同じ記述を繰り返してサーバ名やドキュメントルートを変更すればいくらでもバーチャルホストが作れます。ここは最低限のサーバ設定しか入っていませんが、普段ホスティングの「.htaccess」に書くような内容もココに書いてしまうこともできます。

詳しいことはApacheのマニュアルでご確認を。

バーチャルホストの設定を読み込む

バーチャルホストの設定は「/etc/apache2/httpd.conf」に直接書いても構いません。一般的には、バーチャルホストの設定は外部に書いておいて、httpd.confから読み込むという形にしているところが多いかな？ なので、今回のローカル環境も同じようにしています。直接システムのhttpd.confをいじくりまわすよりは楽だし安全です。

前述したように「/etc/apache2/other」の中に設定ファイルを放り込めば、Apacheの起動時にそれらが読み込まれるようになっています。先ほど作った「httpd-vhosts.conf」を読み込ませるためには、ファイルが「/etc/apache2/other」の中になければいけませんが、残念ながらそこにはありません（笑）。

では、どうするかっていうとそこにエイリアスを作ってあげます。「シンボリックリンク」を作ってあげるというのが正しい言い方ですね。ファイルの実体はサイトフォルダ、otherフォルダの中にはそのファイルへの参照を入れておくわけです。そうすれば、Apacheさんが起動時に勝手にそのファイルを読み込んでくれる、という流れ。

sudo ln -s ~/Sites/httpd-vhosts.conf /etc/apache2/other

「sudo」という新しいコマンドが出てきました。これは「su」コマンドが使えない場合に、許可されたコマンドだけ一時的にスーパーユーザー（root）として実行するためのおまじない。「/etc/apache2」の中身はスーパーユーザーでないといじれないのです。

あなたは自分がそのマシンの管理人だと思ってるかもしれませんが、実のところはシステムに雇われた管理人でしかありません。システムの中まで触ることは許されてないのです（笑）。続く「ln -s」はシンボリックリンクの作成です。

「sudo」でコマンドを実行する場合は、「Password:」と出てきてパスワードの入力を求められます。黙って、管理者アカウントのパスワードを入力しましょう。いちいち面倒ですが、言われるがままに従いましょう。いちいちうざったい場合は「sudo -s」とオプションを付けてあげると、ターミナルを閉じるまでは再度聞かれなくなります。ただ、セキュリティ上は宜しくないと思われますので、外部のサーバなどではやらないでおきましょう。

最後に「/etc/hosts」を編集する

バーチャルホストに指定した任意のドメイン名や特定のドメイン名をブラウザのアドレスバーに入力して、強制的にローカルの環境（127.0.0.1）で開けるようにします。通常、外部のドメイン名はDNSに問い合わせして行き先のIPアドレスを探しますが、「/etc/hosts」にドメインを指定すればそっちが優先されます。まぁ、そういう仕様なのです。

sudo vi /etc/hosts

ファイルを開いて、「127.0.0.1」の「localhost」の後に半角スペース区切りでもタブ区切りでもいいのでドメイン名を並べていきます。

127.0.0.1 localhost test01.local example.com

「httpd-vhosts.conf」のサーバ名（ServerName）に指定した名前にします。ここまでできたらほぼ終わり。後はファイルを保存して、Apacheを再起動して設定ファイルを読み込みなおしましょう。Apacheの起動・終了・再起動とかは「apachectl」ってのでできます。

sudo apachectl restart

以上です。ブラウザで指定したドメイン名を入力してアクセスできたらオッケイ。

といった感じで、Apache編終わり

本当ならWikiとか使って書いた方が読みやすいし、操作的な図版も一杯入れた方がいいのですが、さすがにそこまで時間が取れないのでこんな感じの第1回でした。

次回は、PHPを動かせるように変更してHomebrewまでいけたらいいなぁ…。

多くの方が既に参加レポートをあげてくださっていますが、ボクはボクなりに今回のWordCampの話を書き綴っておこうかと思います。

今回登壇するにいたるまで

@naokomcさんから「WordCamp Tokyoやるから出てくんない？」と打診をいただいたのが10月初旬。普段あまりWordPressのコミュニティに貢献しているわけでもないので、「こんなボクで何かお役に立てることならやりますよ」とオッケイを。実はもともと彼女とは旧知というか、世の中でブログが流行り始めた頃からその存在を知っていましてね。そう、皆さんご存じないと思いますが、ボクは日本で二番目にブログの本を出してまして、今や見る影もありませんがその昔はブロガー的な立ち位置だったのです（笑）。

と、そんなことはどうでもいいのですが、その後今回のWordCampの実行委員長の@waviaeiさんと三人集まって、都内某所で何を話すか会議を（というかご飯をｗ）。今回参加された皆さんはお分かりいただけたかと思うのですが、イベントに参加される皆さんのWordPressとの接し方は多岐にわたります。参加される皆さんひとりひとりをすべて満足させられるような話はできませんし、他のスピーカーの皆さんのこともあります。とりあえず、その場は何が良いんだろうね？ってトコからある程度の方向性だけを決めて、後日「レスポンシブネス」な話でいきましょうか、ということになった、と。

うまく枠にはめてきましたねｗ

10月中旬にはそういった方向性だけは決まっていたものの、その時点では他のスピーカーの方はもちろんタイムテーブルも出ていません。まぁその辺が決まってから話の内容や構成を考えようかな、とのんびり構えていました。「レスポンシブネス」といってもその指し示すところは広いわけで、実のところ「あまり視覚的な表現に振れない方向で」ということは言われてました。Webデザイン業界でいま話題になっている「Responsive Web Design」的なものは、多様なデバイスへの対応が前面に出ているので割と視覚的な部分と捉えられがちです。

で、他のスピーカーやタイムテーブルが明らかになるにつれ、「この人たちうまいこと枠にはめてきたなぁ…」と感心しました（笑）。ボクのセッションをお聞きになった方は、最後の最後で次のセッションへの案内を出したことでお分かりいただけたかと思うのですが、ボクの話は次のお三方のセッションすべてに繋がる導入セッションだったのですね。パブリッシング・プラットフォームとして、Webコンテンツに限らないレスポンシブなWordPressの使い方で、と考えたのです。

実際、後のお三方がどのようなお話をされるかは、タイトルと概要を見て判断するしかないのですが（すり合わせることはできるけどしていない 笑）、長谷川さんやたにぐちさんは普段からブログや講演をなさってますし、高橋さんは既にWordCamp Kobeで電子書籍の話をされています。幸いそんな感じで、皆さんがどういった内容を話されるかはある程度の想像が付いたので、そこに繋がるような構成で今回のボクのセッションの骨子ができあがりました。

でも、前日まで何もしていませんでした

とはいうものの、30分という限られた枠の中で講演内容を詰めていくというのは実は大変な作業です。ライトニングトークみたいな短時間なら勢いでどうにかできますし、45分や1時間ぐらいの枠であればデモを含めながらの講演も考えられます。でも、技術的な話をする場合の30分って実はすごく微妙な時間なんです。詰め込みすぎて時間オーバーするのもダメだし、かといって内容を薄くしたり早口になりすぎて早く終わりすぎてもダメ…。ましてやデモなんて、トラブったらそこで終わり…。百戦錬磨なはずの皆さんからも「30分なんだよなぁ…」と（笑）。

そんな30分をどう使うか、ということをずっと考えていたので、骨子ができた後も全然スライドに手がつきません。結局、スライドを作り始めたのは前日の夜。ある程度形になってから一回寝て、起きてからあらためて見直してまた修正。練習なんて一度もすることもなく、朝会場へ向かう電車の中でもう一度確認。でも、新宿から品川シーサイドまでの移動は20分で話す時間より短く、iPhoneに入れたPDFを使ってイメトレどころじゃない（笑）。会場について、機材チェックを終えてから控え室にこもって、ホントに直前までスライドを修正していました。つまり、正直なところ練習一度もなしのぶっつけ本番で挑んでしまいました、ごめんなさい。

聴講いただいた皆様にお礼を

当日午前中のデザイナートラックのお二方は満員御礼の大盛況。出番が近づくにつれ、変なプレッシャーがおそってきます（笑）。「おいおい、デザイナートラックなのに一枚も絵がないよ」「コードすらないじゃん」みたいな状態からは脱したものの、内容はデザイナー向けと言って良いのか？みたいなところもあって、「全然デザインの話ないじゃん！」とか言われちゃうんじゃないかと、ハラハラドキドキどうなることかと思ってました。幸いにも若干の空席はあったものの、多くの方に聞いていただいてホッとしました。

そんな練習すら一度もしていないボクのセッションをご覧くださった皆様、あらためてこの場を借りてお礼を申し上げます。ここまで登壇に至った経緯からそのバッググラウンドを書き連ねてきましたが、今回WordCamp Tokyoのボクのセッションでは、デザインのことも技術的なことも表面をなぞるぐらいしか触れていません。即効性のあるツールの使い方やちょっとしたTipsといったウケる話ではありませんでしたが、ひとりでも多くの方にこれからのコンテンツ制作、そしてコンテンツ配信の未来を考える何かしらのきっかけや気づきを与えられていたら幸いです。ありがとうございました。

＃もともと人前に出て話をすることどころか、結構な人見知りなもので懇親会なども端っこにいて交流もしなくてスミマセン（笑）。お会いして名刺交換などしていただいた皆さん、ありがとうございました。

あ、いっこ言い忘れてた

いろんな閲覧環境がますます増えていくことが想像できますから、見た目の同一性とかあんま細かいことにこだわりすぎない方がいいですよ（笑）。

それと、最後にいろいろ宣伝…

えっと、今回内容的には「Responsive Web Design」「HTML5」「電子書籍（ePub）」、そして「WordPress」とこれからのWeb技術などを織り交ぜて展開しましたが、実はいずれについても現在書籍を執筆中です。正確な発売時期や書名などは全然決まっていませんが、来年早々には書店に並ぶのではないか、と。また、この11月からアクティブ・カレッジさんで、HTML5の基礎講座、電子書籍の基礎講座、スマートフォン制作の基礎講座などを担当しておりますので、それらの技術に興味のある方はそちらもよろしくお願いいたします。

前回は「WordPressのパフォーマンス改善あれこれ」みたいな話をしましたが、今回はガラッと方向性を変えてデザイナートラックの午後一発目に「レスポンシブ・パブリッシング」というお題で30分ほど話をさせていただきます。

WordPress を使ったオンラインコンテンツも多様なデバイスに「レスポンシブ」に対応できることが望まれる昨今。視覚的な対応はもちろん、コンテンツそのものをさまざまな形態で柔軟に配信するための考え方や手法を紹介します。

というわけで、多様化していくデバイスやコンテンツ形態を見据え、これから先WordPressをどう使いこなしていけばいいか、といった内容になる予定でございます。視覚的なマルチデバイスへの対応は、後に続くたにぐちさんでも扱われると思うのでそこそこにしておきます（笑）。

当日のタイムテーブルをご覧いただくとおわかりいただけると思うのですが、多様なセッションが目白押しの1日となっております。まだ、参加登録は受付中ですので、日曜日の品川でお会いしましょう。

→ WordCamp Tokyo 2011 | 2011年11月27日（日）

＃ちなみに今回の公式サイトのトップの写真は、ボクが昨年の横浜で撮影したものです。手タレとして出ていただいてるお二方、ありがとうございます。

今頃公開するな、と言われそうですが去年のです。ごめんなさい。

今回こちらのパフォーマンスの話は別の切り口から@wokamotoさんが講演されます。その予習程度にご覧いただくといいかもしれません。

「電子書籍が売れてない」だの「Amazonがついに日本に」だのと話題も出ておりますが、世の中いろいろと移り変わっておりましてね。

どんどん、ePubへの流れが加速中なんです

最近の話題だと、あのYahoo! JAPANさんが電子書籍フォーマットのグローバルスタンダードともいえる「ePub」形式を採用されて「Yahoo! ブックストア」をオープンされましたし、オンラインショッピング大手の楽天さんもカナダの「Kobo」という会社を買収されました。Koboで読めるフォーマットは、PDFとePubだったりします（もちろんHTMLとかも）。

再生デバイスが限られる特殊なフォーマットで電子書籍を展開する場合、その売り上げは市場に出ているデバイスの規模に左右されます。つまり、現状の流れとこの先の未来を見据えた場合、専用のリーダーがいらない（というか、好きな環境で読みやすい）ePubを採用し、HTML5を採用した「ePub3」に照準をしぼるのがいいのではないでしょうか。津田大介さんも最近メルマガをePubで配信されていたりもしますね（笑）。

次の未来も見据えてね

ePubの中身はほぼHTMLですから、この先遠くない未来にWebブラウザで閲覧するような時代が来ても大した問題ではありません。それを流用すればいいだけの話です。前出のAmazonも現在はオリジナルのフォーマットを採用していますが、Kindleの次期フォーマットは「HTML5とCSS3」がベースとなるようです。

ePubの自体はツールを使って変換することもできます。でも、ツールを使ったからといってそのまま使えるわけではなくて、やはり人の手で多少修正する必要もあります。電子書籍制作には、「デバイスへの対応を含めた最先端のWebサイト制作の知識やテクニック」も欠かせません。

今回のこの講座では電子書籍界隈の基礎知識から、HTMLをベースとした実際の制作手法、他のフォーマットへの変換などを解説します（あ、もちろんハンズオンです）。出版関係の皆さんはもちろん、現在Web制作をおこなっている皆さんも新しいビジネスのひとつとして、世の中の動きに乗り遅れないように今のうちから準備をしてみませんか？

→ 詳細、受講のお申し込みはこちらから