→ Flowdock（現在はサインアップできます）

アカウントを取得してメンバーを招待してはじめよう

アカウントの登録が終わったら自分のホーム画面に移動します。アカウント1つあれば、チームやプロジェクト毎に「Flow」と呼ばれる独立したワークスペース的なものを用意できます。使用するFlowをクリックするとそのDashboardが表示されますので、Flowに参加して欲しいメンバーをメールで招待しましょう。

既にFlowdockのメンバーであれば、招待メールのリンクから自分のアカウントでログインすることが可能です（そうでない場合はサインアップ）。

招待された人がログインすればほぼリアルタイムでDashboardにあらわれます。Flowdockの右側に見えるペインでは、チャットしたりファイルを添付したりといったやりとりが可能です。

このぐらいだったら別にFlowdockじゃなくてもいいわけですが（笑）、Flowdockはここからが違います。

「Influx」にRSSやTwitter、メールなどを読み込む

Dashboardの左に並ぶ3つのボタンの上から2番目「Influx」をクリックすると、外部のRSSや特定のTwitterのフィード、メールなどをストリームのような形で表示することが可能です。

フィードやTwitterのストリームの追加はこのダイアログから、メールはFlow毎に用意されるメールアカウントに対してメールを投稿することでここに表示されるようです。つまり、複数人が参加しているプロジェクトやグループ内での通知事項は、そのアドレスに投げておけば自動的にこの画面に現れると。

Influxに流れてくるものは、個々にコメントをつけたりすることもできるようになっていますので、メンバー同士で意見を交わすみたいなことができます。なので、別に仕事じゃなくて特定の趣味のグループを作って、そこでワイワイやるといった使い方もありでしょう。

特定の話題やファイルの検索は「Flowser」で

チーム単位での仕事になるといろいろな事柄が毎日毎日起こっていくはずです。「あの話ってどうだったんだっけ？」みたいに過去を遡るのも大変です。Influxで流れる内容にはコメントだけでなくタグを付与することもできますので、それらを見つけるにはボタンの上から3番目の「Flowser」を使います。

特定のタグを検索したり、ファイルだけを表示したりすることも可能と。

動作は軽快。仕事だけじゃなくても使えそう

こんな感じでGoogle Waveと比較されそうな感じのFlowdockですが、できることが明快な上に動作も軽快です。チーム内のコラボレーションはもちろんですが、1つのアカウントでFlow自体は複数作れるので、Twitterなどで仲良くなった人たちとお出かけするためのグループミーティングみたいな場としても活用できるかもしれません。

こんな感じで右側にある「＋」を押せば新しいFlowが作れます。

画面のインターフェイスは英語になりますが、できることが限られているので使い方に迷うようなことはないかな、と。日本語も通りますし。現在はまだパブリックβという扱いなので、今後の発展に期待したいと思います。

最近では、高機能なプロジェクトマネジメントシステムだったり、Google Waveなんかも出てきちゃったりで、複数の会社をまたいだプロジェクトのマネジメントというか、制作チーム単位での工程管理というか、複数人でコミュニケーションを取りながら仕事を進めるスタイルにも変化の兆しがありますね。

Google Waveも鳴り物いりで登場した割には、全体的に重いからなのか使い道が思いつかないからなのか、近頃はあまりその話を目にする機会も少なくなりました（使っている方も多いとは思いますが）。が、ここにきて新しい仕事のやり方ができそうなコミュニケーションツールが登場です。その名も「Flowdock」。

Flowdockは何やら良さそげですぞ

このFlowdock、日本時間の3月11日未明にベータアカウントの登録が可能になっていました。サイトにあるビデオを見る限りGoogle Waveに似た感じもありますが、Twitterなどとも連携しているようで何やら良さそうな雰囲気です。

ここで「…いました」とか「良さそうな…」と書いてるのには実は訳がありまして…（笑）。なんだかんだで一気に広まって急激な負荷がかかっているのか、今のところ正常稼働できてないようです（中の人のつぶやきによると）。で、残念ながら現在はインビテーションのリクエスト状態になっています。どうやら復活したようで、現在はサインアップできるようになっています（2010.03.11午前の段階で）。

ボクは速攻でアカウントをいくつか作ったんで「紹介でもしとこうか」とパソコンに向かったのですが、こちらも残念ながらこの画面より先に進めません（笑）。

追って使い方などを紹介できればと考えておりますが、そんなわけなので今日のところはこの辺で閉めたいと思います。興味のある方はサイトの紹介ビデオを見るなり、β版のインビテーションリクエストを送るなりしておくと良いですね。

ひょっとしたら仕事の仕方が変わるかもしれません。

（追記: 2010.03.11）
復活していたので簡単に使い方を書いてみました。

今朝方「そう言えば…」と思い出して、外部からパフォーマンスチェックができるサービスの一覧へのリンクを入れておきました。で、改めてお礼といってはなんですが、そこにも追加した「Load Impact」さんをちょっと紹介しておこうかな、と。

こちらにも無償で利用できるパフォーマンスチェックツールがありますので、それとあわせてここのサイトのサービスを使えばどういうことが確認できて、どういう対処の仕方があるのかを簡単に書いてみましょう。

同時接続数を変えてロード時間を計測できるLoad Impact

Load Impactは、スウェーデンのとある会社が提供しているオンラインのロードテストサービスです。こちらの主なサービスは、同時に複数のクライアントで接続して負荷をかけてロード時間の平均や使用帯域を計測することができるのが特徴です（お試し版は同時接続数50クライアントまでで一日3サイトまでかな？）。

大規模なアクセスがあるサイトなんかはロードバランサーなんか入ってて負荷分散されてたりするんでしょうが、中小規模のサイトではそうはいきません。とはいえ、プレスリリースやテレビに紹介されたとかで一時的にアクセスが増えてしまうことも考えられます。ホスティングの共用サービスだとサーバのチューニングなんかはできないでしょうけど、ちょっとした負荷でも問題なくアクセスできるようなサイトにしておくことも時には必要になります。備えあれば嬉しいな、です（違）。

インフラが全然ダメなのにいきなり10MBのコンテンツとかダウンロードさせてたら、サーバとクライアントのコネクションがなかなか開放されず、すぐ一杯一杯になることは容易に想像できます（どことは言わんけど 笑）。かといって、新しい接続のためにリソースが確保できるかって言うとそこにも限界がありますから、自分とこで対応できる限界を知っておくこともまた大事なわけです。

いろんなUAをシミュレートできるPage Analyzer

この類のサービスを専門にされている会社さんは、大体無償で利用できるパフォーマンス計測ツールを公開されています。Load Impactさんでも「Page Analyzer」なる計測ツールがあります。

ここのツールの特徴は、他のとこよりも格段に豊富なUser Agentsをシミュレートすることができることでしょうか。

IEはもちろん、FirefoxやChrome、Safariなどのいろいろなバージョンが用意されています（ブラウザ毎にコネクション数とか違いますからね *1）。おそらくストックホルムからのアクセスになるはずですが、比較的レイテンシも少なくて良い感じです。

うちのヘボいトップで大体3秒前後。Chartbeatを使って国内からアクセスされている皆さんの様子を見てる感じでは、平均2秒いくかいかないかぐらいですのでまぁ良しと。秒数うんぬんより、UAのシミュレートができるということで便利です。

段階的に同時接続数をあげ、負荷をかけてロード時間を計測する

いよいよ本題に入りましょう。単なるサーバの設定などを確認する負荷テストであれば、専用のツールなどがあるのでそれを使えばいいわけですが、コンテンツの表示にかかる時間となるとどっかからやんないとなかなかわかりません。

が、しかし。このLoad Impactさんのサービスを使えば、段階的に同時接続数をあげて負荷を与えつつ、表示までにかかってる時間をチェックすることができるんですね。しかも同時接続数50までなら無償でチェック可能！、250まで接続数を上げてもたった$9！ってなわけです（どこの通販だと 笑）。

ま、そんなわけでですね、とりあえず同時に50クライアントまで増やしながらテストしてみるには無償でも可能です。Webサイトのトップにある入力欄にURL入れて、上の図の左のFreeテストに進めばチェックできます。

ただし、チェック結果の保存にはアカウントの登録が必要だったかな？ アカウント登録しても最初はFree版なので大丈夫ですけどね。

有償版は同時接続数をもっと増やしたり、細かな設定をした上でテストが可能になっています。画面見ただけだとちょっとわかりにくいのですが、$9/per dayってなってるのは「24時間内にテストする」ワンタイムフィーみたいなもんです（他にもオプションがあります）。

有償でもそんなビックリする値段じゃないですし、ある程度の規模での同時アクセスが見込まれるコンテンツなどを制作されている方にはいいかもしれません。自分の作ってるコンテンツの限界点を知るためにも、とりあえず試してみるのが一番（笑）。

とりあえず試してみたらこうなった

いや、実はちょっと前からWordPressの設定やサーバの設定をいじってはチェックしていたんですけど、今回同時に100クライアントまで増やしてロード時間を計測してみました。一番安いプランではスウェーデンのストックホルムからしか計れなかったので、とりあえずそれで。

テストにはそれなりに時間がかかりますので、コーヒー飲んでたりしてればそのうち終わります（テスト数による）。この図は、10クライアントから段階的に10ずつ増やし、最終的に100クライアントの同時アクセスまでの結果です。

グラフの線は、できるだけ横方向に同じような状態が良いのは言うまでもないですかね。グラフの縦は表示までの秒数になっています。80クライアントのとこでちょっとだけあがってますけど、広い目で見ればストックホルムからでほぼ3秒前後なので良しとしましょう。

例えばグラフがこういうことになったら、サーバ側の設定をちょっと変更したりする必要があるかな？と。40クライアントが同時アクセスしてきたらガクッと時間がかかり始めたとか、そういうことがわかるわけです。このグラフの形によって意味があるので、それはフォーラムで解説されています（英語だけど 笑）。

最後に。ちゃんとアクセスされてます（笑）

「ホントにアクセスされてんの？」とか疑う方もいらっしゃるかもしれないので（笑）、うちのサーバを監視してる「MUNIN」の画面を出しておきます。

上の図はApacheのプロセスの数を表示したグラフです。左側の縦2つのグラフの右端がガクッとあがってますが、この時がLoad Impactで負荷テストをしている時間です（50と100と2回やってるので2箇所だけ急激にあがってますね）。

WebサーバのApacheはアクセスが増えれば自動的にプロセスを増やす仕組みになってるので良いとはいえ、テストしたらある数値から急激に時間がかかってる場合などは、サーバ側の設定やらコンテンツの作り方などもろもろを見直したりした方がいいかもしれませんね。

サーバの設定をいじるなんてみんながみんなできるわけではありませんし、システムのチューニングは餅は餅屋で任せた方が良いとは思います。でもまぁ、一応こういう負荷テストを使って、コンテンツの弱点を探すってのもありじゃないかな？と思ったので簡単にご紹介まで。

うちもとりあえず「100人乗っても大丈夫」のようです。

*1: ブラウザのバージョン毎の仕様はこちらが詳しいです

• Webサイトの高速化的な話をWD誌で
• YSlow!、使ってわかるあんなことこんなこと
• Page Speedでチェックついでに最適化
• Page Speedが1.6βになったようで

ここのエントリーに挙げた以外に、ちょっと前にゲリラ的にUSTREAMでくっちゃべってみたところ反響も大きかったようです（最初の回は特に他のどこ探してもないことも言いましたしね、フフフ）。

で、今回はこのブログでも使っているWordPressのパフォーマンスをアップさせるためにできることをいくつか紹介したいと思います。「できる」「できない」は設置されている環境で異なりますのであしからず。

最後にどこでも設置できるプラグインも含めておりますので、最後までお読みいただければ幸いです。すんごい長いので気合い入れてくださいね（笑）。

※一番最後にパフォーマンス計測のためのリンクを追加しました

まずはWordPressの仕組みからおさらい

CMSとしての活用事例も多いWordPressですが（海外ではね 笑）、「そもそも何故パフォーマンス改善が必要なのか」というところから話をはじめましょう。

WordPressは、基本的に静的なHTMLを生成するMovableTypeと違って、PHPを使ってリクエストのたびに動的にコンテンツを生成する仕組みです。ブラウザからのリクエストがWebサーバに届いたら、PHPがMySQLに格納されたデータを読み出し、テンプレートを使ってリクエストURLに応じたHTMLを逐一生成してる、と。

パフォーマンスチューニングされたホスティングにおいてあれば回線環境も処理速度も速いかもしれませんが、そういったケースばかりではありません。中には自宅サーバで運用されているうちみたいな貧弱な環境もあります。

そこで、Webサーバとその上で動いているPHPが処理する時間を改善し、さらにWebサイトの高速化のための手法を組み合わせることでパフォーマンスアップを図ろうじゃないか、ということですね。

閲覧側は高速なブロードバンド環境ばかりではありませんし、最近だとTwitter経由でiPhoneから閲覧することもあります。見にきてくれる人をいかに待たせないで、ストレスなく見てもらうかといったことも考えなければいけません。

ま、前振りはこれぐらいにして本編にいきましょう。

PHPの処理をキャッシュさせて速くする

VPS（バーチャル・プライベート・サーバ）やDedicated Serverみたいな比較的自由度の高いプランで契約されていれば、サーバの構成などを管理者側で設定できます。そのような環境に置かれていれば、PHPの処理そのものを高速化するといったことが可能です。このような処理をおこなうものに「eAccelerator」や「APC（Advanced PHP Cache）」、「memcache」などがあります。

ここでは詳しい話はしませんが、この辺りをサーバに突っ込んであげるだけでPHPの処理にかかる部分のパフォーマンスは大きく改善されるでしょう。ちなみにうちはAPCとmemcacheが入ってますが、それは後ほどあらためて。

動的生成しないでHTMLをキャッシュさせる

ここからがいわゆる普通のホスティングサービスでも採用できるかもしれない方法です。ここからはWordPressのプラグインを利用します。

先に述べたようにクライアント側からリクエストがあった場合、そのリクエストされたURLをWebサーバ側のWordPressが動的に生成します。この動的に生成している部分をMovableTypeのように静的なHTMLファイルとしてキャッシュしておいて、新たなリクエストがあった場合にはそれを送り返しちゃうと。

このような仕組みを実現できるプラグインはいくつかあるようなんですが、ここでは利用者の多い「WP Super Cache」と前述のPHPの高速化処理と組み合わせられる「W3 Total Cache」の2種類を紹介しましょう。

いずれのプラグインもWebサーバ側で「mod_rewrite」的なURLの書き換え処理ができる環境でないといけないかな、たぶん。なので、サイトを運用する時は安いプランだけじゃなくて、自由度をある程度高くしておいた方が都合が良いのです（笑）。

WP Super Cacheのインストールと注意事項

では、まずはWP Super Cacheから。iidaのサイトもこれを採用されてる風。

→ WordPress Super Cache

インストールは、プラグインの公開サイトからダウンロードしてもいいですし、WPの管理画面から直接インストールすることもできます。

次に紹介するW3 Total Cacheもそうなんですが、これらのプラグインのインストール時には、「wp-config.php」の中の「define(‘ABSPATH’〜」の行の前あたりに以下の記述を追加しなければなりません。

define('WP_CACHE', true);

ついでと言ってはなんですが、あらかじめ「wp-content」のパーミッションを「777」にしておくと、有効化の時とかにいちいちアラートが出てこないので楽です（終わったら755なり、元のパーミッションに戻します）。

日本語版にインストールすれば日本語で設定項目が出てきますので、特に設定に困ることはないですかね。いくつか設定項目をピックアップしてみます。

ま、こんな感じです。
一番上に「オン」「ハーフオン」「オフ」の切り替えボタンがありますので、そこでWP Super Cacheをの機能をオンにします。あとはWP Super Cacheの基本的な挙動のスイッチがありますので、必要に応じてチェックを入れましょう。

サイトによっては日本の携帯電話用にサイトをフォーマットしてくれる「Ktai-Style」やiPhone用の「WPtouch」などを利用しているかもしれません。そのような場合は「Mobile device support using」を必ず有効にしておきましょう。

WP Super Cacheは生成した静的なHTMLをGzip圧縮して送ることもできるようになっています。これを有効にすれば転送データ量を1/3程度に抑えられますが、必ずしもすべてのサイトでできるとは限りません（と書かれています 笑）。

WP Super Cacheで生成される静的なHTMLは「cache」ディレクトリに保存されますので、リクエストがあった場合はそちらにリダイレクトする必要があります。その役目を果たすのが「mod_rewrite」なので、指定された場所にある.htaccessに表示されている内容を追加しましょう。

設定を変更した場合も何か変わってないかチェックしましょうね。

その他、除外するファイルやURIなどは別で設定可能です。あとは、ファイルの有効期限などを設定すれば終わりです。これ以下にもろもろ設定項目が並んでいますが、ほとんど使いませんかね、たぶん。

以上が、WP Super Cache編でした。

W3 Total Cacheのインストールと注意事項

W3 Total Cacheは、WP Super Cacheと同様、静的なHTMLをキャッシュしてクライアントに送ることができるプラグインです。

→ W3 Total Cache

厳密には同じではなくて、より高機能で設定項目も多く、サーバの仕様にあわせて細かくカスタマイズできるのが特徴です。ページのキャッシュだけでなく、Minify化したものやデータベースのキャッシュも保持できたり、CDN（コンテンツ・デリバリー・ネットワーク）の設定までできる優れものなんですね。余談ですが、開発者の人はTwitterでも話しかけてきます（笑）。

インストールは、WP Super Cacheと同じ手順でおこないます。

残念ながらインターフェイスは日本語化されていませんが、「基本設定」「ページのキャッシュ設定」「Minifyの設定」「データベースのキャッシュ設定」「CDNの設定」といったところですね。

一番上のチェックボックスで機能のオン・オフを切り替えます。

こちらのW3 Total Cache、単に静的なページをディスクにキャッシュするだけではありません。ページのキャッシュ、Minifyのキャッシュ、データベースのキャッシュにmemcacheやAPCを使うことができます（それらがなければ、ディスクです、たぶん）。オン・オフは個別に設定できます。

とある海外サイトのパフォーマンス計測結果によるとページのキャッシュは「Disk（enhanced）」にしておくとより高速化できるといったことが書かれていました。ディスクに溜め込むので、当然mod_rewriteが必要になります。

うちも長らくWP Total Cacheのお世話になってましたが、先日ふと思い立ってこちらに乗り換えました。現在の設定は、ページキャッシュを「Disk（enhanced）」、Minifyとデータベースのキャッシュを「APC」にしています。memcacheでもしばらく回してみたんですけど、どうにも不安定で結局この設定です。

で、携帯向けの対応をしている場合に注意点があります。

先のKtai-StyleやWPtouchが入っている場合、それらに対してページのキャッシュやMinify化をしない方が無難です。ページキャッシュの設定にある「Rejected User Agents」に除外対象を追加しましょう（※一番下にあるモバイルのUAをまるごとコピペすればいいです）。

Minify化したキャッシュも同様。「Minify Setting」にあるリジェクトのところに先ほどの携帯端末のUA一覧を貼り付けておきましょう。ただし、iPhoneやiPod touchに対してはMinify化をかけても問題ないので、それから除外してもオッケイです（ボクの検証結果では）。

このW3 Total Cacheはかなり細かいところまで手が届くプラグインです。もちろん特定URlの除外やGzip圧縮などもサポートしています。WP Total Cacheに比べてmod_rewriteの記述も少ないですし、自由度の高い環境の方はこちらの方がいいかもしれません。

ただし、特定サイトのディレクトリ以下に配したマルチブログ的な環境だとうまくいかないかも（というか、うまくいかなかったｗ）。マルチブログ環境については、フォーラムにいろいろ書かれていました（WP次期バージョンに向けてどうこうとか）。

といった感じでW3 Total Cache編でした。

キャッシュできなくても、別の部分を改善する

「mod_rewriteとかそもそもなんなの？」とか「使えるかどうかわかんないしー」みたいな方でも、いくつかのプラグインに頼ることでWordPressの表示パフォーマンスは改善可能です（といっても、なんでも入れればいいってわけではない 笑）。

まずひとつめは、WordPressのプラグインなどに勝手に組み込まれるヘッダ内のJavaScriptなどの位置を変えて高速化を図る方法があります。

Head Cleanerで表示速度の改善をする

この類のプラグインもまたいくつかありますが、日本発の「Head Cleaner」が一度になんでもかんでも処理してくれるんじゃないでしょうか（ボクは入れたことはないんですが、かなりいろいろできるようです）。もちろんWP Super Cacheなどと併用することもできます。

→ Head Cleaner

何故このようなヘッダ内のお掃除が必要になるかというと、複数のJavaScriptの読み込みやscript要素の順番によっては、特定のブラウザでページの構成要素のダウンロードが妨げられたりします。

なので、複数のJavaScriptやCSSをひとつにまとめてリクエストを減らしたり、改行やコメントを取ってMinify化したりすることで転送量を減らすことができます。また、ページの描画に関係のないJavaScriptなどは</body>の直前に配置したりすれば、なおよろしと。

うちは何でもかんでもプラグインに頼るのもなんなので、プラグインの数も抑えてhead要素内に組み込まれるものは手動でまとめています。

WP Smush.itで画像を最適化する

次にできること。表示速度はページ内に含まれる画像の数にも左右されます。何の気なしにPhotoshopなどで書き出したJPGやPNG画像には実はいらないデータが含まれていることもあります（特にJPG）。アップする画像も実はさらに最適化を施すことでデータ量をガクッと下げることができるんですね。

→ WP Smush.it Wordpress Plugin

「WP Smush.it」は、アメリカのYahoo!の「Smush.it™」を経由してアップロード画像を最適化してしまうプラグインです。たまにミスることもありますが、その時はあらためて「Re-Smush」すれば大丈夫でしょう。最適化されたかどうかのチェックやRe-Smushは、メディアのライブラリで確認可能です。

すべての画像が最適化されるわけではなく、必要のあるものだけが最適化されます。JPGなんかはビックリするぐらいデータ量が減るかもしれません（笑）。ちなみにGIFとPNGだったら、PNGの方が軽いです。

とまぁ、キャッシュできなくても表示パフォーマンスアップのために役立つプラグインが公開されていますので、試してみてはいかがでしょうか。

見てくれる人のことを考えてやれることはやりましょう

以上で、WordPressのパフォーマンス改善のためのアレコレの紹介は終わります。まぁ、見に来てくれる人のことを考えれば、少しでも速く表示された方がいいわけです（自分だって他見る時そうでしょう？）。幸い、WordPressは仕様のせいもあってかこのようなプラグインが多数公開されています。制作者の方にお礼を述べつつ、使えるものは使ってみるといいかもしれません。

最後に。この辺の話はまたゲリラ的にUSTREAMで喋る予定です。ここに書いた内容を補足する感じになると思いますが、「文章じゃわかりづらいよ」って方はボクのTwitterでもリストに入れておいてください（フォローするとうざい 笑）。

（追記: 2010.03.10）
そういえば、パフォーマンスの計測ツールをご存じない方もいらっしゃるかもしれませんので、こちらで以前紹介していたリストのアドレスをご参考までに。

• Webサイトのパフォーマンスチェックサービス

新しく一個サービスを追加してあります。

いかんせんインターフェイスが英語になっちゃうので紹介するのはやめとこかと思ったのですが、使いようによってはクローズドなネットワークで使えるかもしれないので簡単に書くだけ書いてみます。

アカウントを作ればすぐ自分専用のサイトのできあがり

サイトの真ん中ぐらいにある「Create network」をクリックしてアカウントを作ります。アカウント登録時にタイトルや見た目なんかを指定できます。

完成すればこんな感じ。ほとんどTwitterです（笑）。

完全にプライベートモードにしたければ、これ自体をプライベートにしてTwitterとかFacebookと連動させないようにした方がいいですね。自分自身のアカウントもTwitterと連動できて同時投稿とかもできるんですが、それだとプライベートにはならないので注意が必要です（笑）。

PC用のサイトでは、参加メンバーの権限設定のようなこともできます。

iPhoneアプリはTwitterクライアントとしても

ShoutEmは既にiPhoneアプリが公開されています。

起動したら公開されているネットワークが表示されますが、それは無視してとりあえず先ほど作った自分のサイト名を入れて探します。

で、アカウントの情報を入れてログインしましょう。このアプリはTwitterのアカウントも別で登録できるので、Twitterクライアントとしても動作します（見た目は英語だけど、日本語も問題ありません）。

タイトルにあるように「Twitter+Foursquare」みたいなもんですから、チェックインの機能なんかもあります。つぶやく時は右にある「Shout」のボタンを押しましょう。あとは、写真を添付したり場所を添付したりとまぁ一通りのことができるようになっています。

とまぁ、大体こんな感じです。Twitterと連動させなければサイト自体を非公開にもできますから、趣味のグループなんかでの連絡とかにはいいかもしれませんね。果たして、Twitterとか他のものと併用するかどうかはわかりませんが（笑）。

以上、いざとなったらプライベートでロケーションベースのソーシャルネットワークサイトが作れるShoutEmの紹介でした。先々はプレミアムアカウントなんかもできて有料版もできるようです、はい。

そんなBuzzの使い勝手を解消してくれるサードパーティのiPhoneアプリ「Buzzie」が出たようです。あいにく無償ではなく230円になりますが（レートおかしいけど）、Webアプリよりはつぶやきやすいですし、フォロワーのつぶやきをみるのもコメントもしやすい感じですね。取り急ぎお知らせまで。

→ Buzzie（iTunesStore）

1サイトあたり52USDの有償のCMSですが、サイトで動くかどうかの「Compatibility Suite」も用意されているので購入前に試すことが可能です。ちなみに動作に必要なシステム条件は、PHP 5.x以上、MySQL 4.1.x以上になっています。

では、簡単に導入までのプロセスを。

設置は簡単2分で終わる

Perchのライセンスの購入は、必要事項を入力してPayPalで支払えば終わりです。自動的に自分のアカウントページに移動するので、そちらでライセンスの番号などを確認します（稼働サイトのドメインやテストサイトのドメインを入力する）。あとは配布ファイルをダウンロードして解凍後、中にある「perch」のディレクトリをサーバのルートディレクトリあたりに放り込むだけです。

放り込んだディレクトリにアクセスするとインストール作業の開始です。あらかじめDBを一個作ってMySQLの接続情報とPerchのシステムにログインするためのアカウント情報などを入力します。それが終われば、表示された初期設定のコードをconfig.phpにコピペしてお終い。setup用のディレクトは削除してしまいましょう。

編集対象を追加する

そのままPerchにログインしても何も表示されませんので、既存のサイトのコンテンツで編集対象を設定します。

.phpの拡張子だけでなく.htmlで利用したければ、.htaccessのAddTypeを使ってHTMLをphpとして動作させましょう。

AddType application/x-httpd-php .php .phtml .html

コンテンツにPerch側で編集可能なエリアを設定するには、対象ファイルの冒頭（HTMLだったら頭のDOCTYPEの前とか）に以下の記述を追加します。

<?php include('perch/runtime.php'); ?>

Perchのインストールディレクトリは適当に置き換えてください。で、上記のinclude文を追加したら、ページ内で編集対象にしたい箇所を以下の記述で置き換えます。

<?php perch_content('編集対象のラベル'); ?>

「編集対象のラベル」の部分が管理画面の中で編集対象のラベルになりますので、例えば「NewsSection」とか適当な名前に置き換えてください。これをページ内で編集対象にしたい箇所を必要な分だけこのコードに置き換えます。

設定はこれでお終い（笑）。

編集対象ブロックを定義する

Perchの管理画面にログインすると、編集対象に設定した箇所のリストが表示されて「New」のマークが表示されます。

この画面は設定後に撮ってしまったのですが、追加した編集対象のラベルをクリックすることでその部分に入るコンテンツの種別を設定し、中に入るテキストなどを編集して保存できるようになります。

例えば、こんな感じで特定のdiv要素内をまとめてコードブロックとして設定してHTMLを書くこともできます。もちろん、こんな使い方ではなく、任意のタグの中のテキスト1文だけを編集可能にしたり、画像だけを差し替えるようなこともできます（何ができるかはマニュアルで）。

また、この編集対象は特定ページだけで使う以外に、それをシェアすることでサイト内の複数ページにわたって内容を使い回すこともできるようになっています。ページの構成次第では一箇所変えれば、すべてに適用されるってことですね。

これぐらいシンプルな方がいいでしょう、きっと

MovableTypeやらWordPress、それ以外のCMSを導入するまでもないサイトはいっぱいあるはずです。かといって、Cotributeだと領域設定や使い方教えたりも必要になりますし、下手にFTPとか空けてガンブラーにやられても困るでしょう（笑）。既存のページの特定箇所だけを編集可能にするのはこれが一番簡単ですね。

サイトの更新をクライアントの担当者の方がおこなうと考えた場合、MTやWPのような複雑な画面だとContribute以上に操作説明が大変です。このぐらいシンプルな管理画面でやることが明確な方がいいですよね。PerchはAdmin権限とEditor権限の2種類のロール設定が可能なので、更新担当のアカウントはEditor権限にして必要な項目だけ表示させれば間違いもおきません。

インストールに2分、設定に3分で簡単なCMSができあがります。
ものは使いようってことですね（笑）。