先日、待望の長女が誕生したmikioです。あまりにかわいいから育児ブログでもつけようという魂胆ではありませんが、今回は自作のCMSであるTokyo Promenadeについて語ります。

Tokyo Promenadeとは

以前の記事で、Tokyo Cabinet（TC）を使ったCMSを作ることを予告しましたが、Tokyo Promenade（TP）がまさにそれです。TCのテーブルデータベースを使って記事を管理する軽量なコンテンツ管理システム（CMS）の実装です。例によってC言語のみで記述され、libc以外の全実装が "made by mikio" な製品です。

読み方は「東京プロムナード」です。プロムナードとは散歩道のことですが、東京メトロの広告に出てくる宮崎あおい的なキャラが写真付きブログを書いちゃうようなユースケースをイメージして名づけました。まあ実装はそんな洒落た感じとはほど遠いですし、実際に私が使う際には小賢しい技術ネタを書きなぐることになるでしょうけども…。

まずはデモサイトにアクセスしてみてください。ヘルプに基本的な使い方は書いてあります。デモサイトなので、SandBoxの記事を追加したり編集したり削除したりしていただいて構いません。

掲示板なの？ Wikiなの？

この質問はFAQでありつつ、回答に困ってしまうものの代表です。TCのようなスキーマレスのデータベースを使っている場合、掲示板（またはブログ）とWikiのデータ構造は全く同じであるとみなすことができます。双方とも、各記事は内部IDで識別され、名前（タイトル）やタイムスタンプや著者名などの属性を持つレコードとして記事を記録し、その属性によって表示対象と並び順を定義したビューを構成できて、ユーザからの入力をもとにビューの決定と記事の操作を行うシステムです（まあそのレベルで抽象化したらほぼ全てのDBアプリはそういうアーキテクチャに収まるとも言えますが）。

掲示板とWikiの主な違いは、トップページで提示するビューが「時系列リスト」なのか、人間の編集者がおすすめする「フロントページ」なのかということです。TPのデフォルト設定では掲示板として時系列リストを提示する掲示板仕様になっていますが、設定ファイルで任意の記事をフロントページを指定するとWiki仕様になります。なお、作成日順の時系列リストを提示すると普通の掲示板として使えますが、更新日順の時系列リストを提示すると「２ちゃんねる」のようなフローティングスレッド掲示板風に使うこともできます。

ということで、質問への回答としては「掲示板とWikiはビューの違いに過ぎないので、あなたがどう使うかでどちらであるかが決まるのです」ということになります。個人的には名前とか分類とかはどうでもよくって、「HTMLとかHTTPとか難しいことなんて知らなくても誰でも簡単にお洒落なWebサイトが作れる」というCMSの醍醐味が味わえればそれでいいかなと。

TPの素敵ポイント1：シンプルでロジカルなUI

私はw3mというテキストブラウザが結構好きで、実はTPのユーザインターフェイスはw3mで最も見やすいように調整されています。しかし市場のブラウザシェアを考えればIEやFirefoxやSafariでそこそこ綺麗に表示できないと話になりませんので、CSSを駆使してそれらでもできるだけ読みやすくなるように努力しています。華美な装飾を施すのではなく、各記事の著者がWiki記法で記述した論理性をいかに直感的に読者に伝えるかということを追求しています。

テキストブラウザで読みやすくするためには論理構造のみをHTMLに記述するという選択が自然になされるため、結果的にロジック（HTML）とスタイル（CSS）の分離が徹底されることになります。また、ロジックの部分をできるだけ論理的に記述してもらうために、Wiki記法では論理的に必要だと思われる表現のみを厳選しています。そういった仕様策定のヒントにしたのは、研究者が論文などを書くときによく用いられるLaTeXというシステムです。LaTeXの文書でよく使う見出しやリストや図表といった構造のみがWiki記法で選択できるようにしています。CSSによるスタイルも、LaTeXっぽい見栄えになるように調整しています。

TPの素敵ポイント2：アクセシビリティ

ロジックとスタイルを分離した結果として、いわゆるフルブラウザはもちろん、テキストブラウザでも、視覚障害者用の音声ブラウザでも、モバイル端末でも、プリンタでも、それぞれの環境なりに最善を尽くした表現ができるようになっていると思います。このように様々な環境および様々な境遇の人に対して情報の授受ができる程度を指してアクセシビリティと言うことがありますが、世に数多あるCMSの中でTPはかなりマシな方だという自負があります。

ただ、デフォルトの状態では多様な環境で読みやすいようにしている分、個々の環境に最適化できているわけではありません。最適化の要求があるユースケースでは、出力用テンプレートをカスタマイズすることで対処できるし、またそうすべきだと考えています。音声ブラウザを使っていない私が音声ブラウザに最適な表現を定義するのは無理ですし、iPhoneを持っていない私がiPhoneに最適化された表現を定義するのも辛いものがありますので、個々のユースケースへの最適化はユーザの皆さんに任せるのが現実的です。出力用テンプレートはTCのテンプレート直列化機能をそのまま使って実装されています。テンプレートファイルはHTMLの中に [% ... %] という形式のディレクティブを記述した単純な構造なので、プログラマでなくても簡単にHTMLレベルの構造を変更することができます。

TP以外の多くのCMSでは記事にHTMLを直接記述できる機能があります。そうすると備え付けのWiki記法では不可能な表現方法を自由に使うことができるからです。しかし、それをやってしまうと論理構造がめちゃくちゃになってしまうし、validなHTMLを書けるユーザの割合は著しく低いので、TPでは禁止しています。そのおかげで、TPが出力するHTMLはXHTML 1.0に完全準拠することが保証されます。したがって、JavaScriptやXSLTで加工するのも容易ですし、スクレイピングをして外部アプリケーションを作るのも容易です。

基本事項ではありますが、コンテンツを表示する際には以下の点に心がけるようにしています。

• ブックマークの名前として識別しやすいtitle要素をつける。
  • 複数の記事をリスト表示する際にはサイト名と機能名をつなげた文字列
  • 記事単体を表示する際にはサイト名と記事名をつなげた文字列
• 各ページで最も強い見出しをh1要素にする。そしてh1要素は必ず0個か1個にして複数は置かない。
  • 複数の記事をリスト表示する際にはサイト名をh1にし、各記事の名前はh2、見出し1以降はh3以降
  • 単体の記事を表示する際には記事の名前をh1にし、見出し1以降はh2以降
• 見出しには各記事のIDおよび見出しの階層を反映させたid属性を付与してリンクされやすくする。
• データベース内の日付はカレンダー時間で保持するが、表示時にはローカル時間に変換する。

各記事のタイトルや見出しは特定のHTML要素に単純に変換させるわけではなく、ビューに基づく相対的な順位で要素が決められるというあたりが私なりのこだわりです。とはいえCSSでスタイルを割り当てる際の利便性を考えて、記事毎の絶対的な見出し順位もきちんとclass属性として指示しています。

TPの素敵ポイント3：快適な画像挿入

テキストブラウザな人は画像とかあんまり興味ないでしょうが、世の一般的なブログなどではほぼ全ての記事に写真やイラストを載せるのがトレンドだというのも否めません。私が育児ブログをつけるとしてもおそらくそうすることでしょう。そのようなユースケースでは、画像をいかに美しく挿入できるかがCMSとしての良し悪しを左右することになります。

画像はさすがにWiki記法では記述できない（Base64で貼り付けるなどの方法は不可能ではないが現実的ではない）ので、ファイルアップロード機能を実装しました。また、アップロードした画像に任意の名前（デフォルトはローカルでのファイル名）がつけられますが、タイムスタンプで識別されるので同じ名前のファイルが複数個あっても問題ありません。

画像を記事に挿入する際には、「@」の後ろにURLを書くだけです。「http://」で始まるURLでWeb上にある任意の画像データを参照できるのはもちろん、「upfile:」で始まる内部識別子でTP内にアップロードした画像を参照することもできます。URLでなく内部識別子を使った方がサイトを移設した際のリンク切れを回避できるので有利です。

画像を挿入するような記事の著者はおそらくタブブラウザを使っているでしょう。記事を執筆すべく編集画面を開きながら、画像が挿入したくなった段階で別タブでアップロードファイルの管理ページを開き、検索機能やサムネイルを駆使して対象の画像を特定し、そこに張られた内部識別子を右クリックでコピーしてクリップボードに入れます。それから編集画面に戻って任意の位置にペーストすれば作業完了です。原始的なようですが、JavaScriptでURLを挿入するタイプの挙動だと元の編集画面が勝手にスクロールしてしまってイラつくことが多いので、敢えてこの素朴な方法を推奨しています。

挿入した画像の表示位置も簡単に制御できます。「@ hoge」と書けばその位置に画像がそのまま表示されますが、「@< hoge」と書けば左寄せ、「@> hoge」と書けば右寄せで表示されます。左寄せなら本文は右に回りこみ、右寄せならば左に回り込むようになります。結果として、雑誌の記事のような見栄えで写真を紹介できるようになります。

TPの素敵ポイント4：Wikipedia大好き

著者には既知だが読者に未知であるかもしれない一般的な概念を記事の中でわざわざ説明するのはだるいものです。一般的な概念であればだいたいのことはWikipediaで説明されているので、該当の記事にリンクを張れば十分です。ということで、リンク先に「wpja:」で始まる識別子を書くと、自動的にWikipedia日本語版のその名前の記事へのURLに直す機能があります。「wpen:」はWikipedia英語版へのURLになります。いわゆるInterWikiですね。小ネタのような機能ですがかなり時間の節約になります。

実装の苦労

TCのテーブルDBとテンプレート直列化機能とオブジェクトシステムがめちゃくちゃ強力なので、Wiki記法だのユーザ管理機能だのファイルアップロード機能だのを満載している割には、TPの全ソースコードは3000行未満に収まっていて非常にコンパクトです。なので、実装について語ることはあまりありません。ご興味のある方はパッケージ内の promenade.c を読めばだいたいの流れが理解できると思います。

敢えて苦労した点を挙げるなら、拡張子とMIMEタイプの対応表を手でハードコーディングしたりとか、時刻表現は10進数とW3CDTFとRFC1123形式を全てサポートしたりとか、クッキーを暗号化するためにRC4を実装したりとか、ファイルアップロードのmultipart/form-data形式のパーザを自分で書いたりとか、1バイトたりともメモリリークしないようにvalgrindでほぼ全てのコードを調べたりとか、全画面がXHTML 1.0でvalidかどうか確かめるためにxmllintとhtmllintで出力を調べたりとかがありました。それより何より、一番面倒だったのはWiki記法を解析してHTMLに直すコンバータを書くことでした。得にリストがネストする構造が厄介で、途中でやめようかと何度も思ったものです。

とはいえ、全ての課題はクリアされ、現時点で私の欲しい機能が全て実装されているCMSが完成しました。スクリプト言語の処理系やデータベースサーバをインストールせずに使えるし、貧弱なマシンでも軽快に動くし、それでいてテンプレートをいじって簡単にカスタマイズできるし、シンプルで飽きの来ないデフォルトのデザインも付いてくるし、我ながら結構イイ感じです。

インストールしてみましょう

ここまで読んでみてTPを使いたくなってくれた人も少数ながらいるかと思いますので、インストール方法について超要約で説明します。WebサーバとTCが予めインストールされていることを前提とします。

# TPをダウンロードする
wget http://tokyocabinet.sf.net/promenadepkg/tokyopromenade-0.9.1.tar.gz

# TPをインストールする
tar zxvf tokyopromenade-0.9.1.tar.gz
cd tokyopromenade-0.9.1
./configure
make
sudo make install

# CGIスクリプトなどを置くベースディレクトリを作る
mkdir /home/mikio/public_html/cms
cd /home/mikio/public_html/cms

# TPの各種ファイルをベースディレクトリにコピーする。
cp /usr/local/libexec/promenade.cgi .
cp /usr/local/share/tokyopromenade/promenade.* .
cp /usr/local/share/tokyopromenade/passwd.txt .

# データベースファイルとアップロードファイル用ディレクトリを作る
prommgr create promenade.tct
mkdir upload

# CGIスクリプトがデータベースやディレクトリを更新できるように適宜設定する
chmod 666 promenade.tct*
chmod 777 upload

# 気が向いたら、ヘルプファイルをインポートする
prommgr import promenade.tct /usr/local/share/tokyopromenade/misc/help-ja.tpw

あとは、設置したCGIスクリプト「promenade.cgi」にWebブラウザでアクセスすれば使い始めることができます。デフォルトで管理者ユーザのアカウントが名前「admin」およびパスワード「nimda」として定義されていますので、それでログインして記事を書いたりユーザを作ったりファイルをアップロードしたりしてみてください。

「promenate.tmpl」というファイルがテンプレートファイルになります。これをいじることで、出力されるHTMLのほぼ全てをカスタマイズすることができます。デフォルトでは掲示板スタイルの時系列表示がトップページに設定されていますが、テンプレートの冒頭にある「[% CONF ... %]」のディレクティブをいじってフロントページを設定するとWikiとして使うことができます。

まとめ

Tokyo Promenadeの概要について述べました。設定によって掲示板（ブログ）風にもWiki風にも使えるシンプルなCMSです。C言語だけでも、DBMだけでも、GNOMEなんたらやApacheなんたらを使わなくても、そこそこ実用的なシステムを作れることが伝われば幸いです。

シンプルっていいですよね。複雑なシステムってだいたいすぐに嫌気が差してしまいますし、特定のユーザのユースケースに特化した機能を操作の選択肢として全員に提示するのは、全体のユーザビリティを下げることにつながります。大多数のユーザが必要最低限の機能を迷わず使えるという大前提を確保した上で、慣れたユーザはその学習曲線に応じて個々のユースケースに最適化された使い方ができるようにするのが理想です。その理想に照らすとTPはちょっとシンプルさが行き過ぎた感もありますが、TPが想定するユーザ層である「ワープロでなくテキストエディタを使う人達」にとってはこれくらいがバランスポイントだと思っています。

TPの今後ですが、RSS配信機能やメールによる更新機能をつけたりといった今のトレンドに合った機能追加を行う予定です。あと、そもそもの開発の動機として英語ブログを立ち上げてTokyoシリーズについて語りまくるというのがあるので、近日中にやりたいと思っています。レンタルサーバとドメイン取得で最もコスト（手間含め）が低いオススメの方法があれば教えてください >識者。

はじめまして。07年入社エンジニアのあまやんです。
今日はmixi Engineer’s Blog初（？）、弊社エンジニアの社外での活動レポートをお届けしてみたいと思います。

去る3月29日、東京・お台場の「東京カルチャーカルチャー」にて、ウェブ業界の若手社員たちによる交流イベント、その名も「Web2.0 中の人ナイト」が開催され、弊社からは「オンラインコーヒーメーカー 萌香」でお馴染みのきょろと私あまやんが出演しました。

イベントには「cookpad」「livedoor」「楽天」「@nifty」「GREE」「Yahoo!」といった大手サイトの「中の人」が勢ぞろい。
普段なかなか表に出てくることの少ない作り手の顔を知ってもらおう！ということで、お互いの仕事場環境や、各自が取り組んでいる本業以外のものづくり（弊社ではOne Day Free（ODF）制度）の内容についてショートプレゼンを行いました。

会場の様子。客席はレストランも兼ねていて、食事やお酒を楽しみながらイベントを楽しめる素敵な場所でした。

弊社きょろのプレゼン。

話題はやっぱりコーヒーメーカー。

オンラインコーヒーメーカー「萌香」、実はテレビCM(風の動画)まで作ってしまったのです。このイベントにて初のお披露目となりました。
キャラクターボイスを担当されているのは、声優の永井真衣さんです。

ニコニコ動画のアカウントをお持ちの方はこちらからどうぞ（H.264/高画質）

併せて会場では「萌香」の実機と、きょろが学生時代に開発した割り箸製（！）の「どこでもペンタブレット」を展示。興味津々な来場者の皆さんと会話する彼は本当に幸せそうでした。

他社の皆さんのプレゼンは、さらに多彩で新鮮なものばかり！

livedoorの佐孝さん。「作っちゃいましたメソッド」といって、エンジニアが仕事以外に趣味で作った試作品が、実サービスへ採用されることが多いのだそうです。

Yahoo!の吉田さん。Hack Dayという、3日間の社内Hackathonにて、iPhoneカメラを用いたOCR翻訳ソフト「翻訳ルーペ」を開発されたそうです。

@niftyの森藤さん。社内で繰り返しなされることの多い事項のチェックリストを共有できるサービスを開発。いまや「イタリア旅行」や「燻製の作り方」といったプライベートな項目にまでどんどん情報がアップされているそうです。

ユーモアに富みながらも、細かいところまでコミュニケーションデザインがなされたアプリケーションたち。
遊ぶときも本気って、こういうことを言うのでしょうか・・・！
このバイタリティと想像力が、日々私たちの暮らしに楽しみを生むサービスを作り出す原動力になっているんだな、と強く感じることしきりでした。

ショートプレゼンのあとは、各社メンバー集合によるパネルディスカッションでした。

「うれしかったユーザーさんは？」「サービスの予想外の使われ方」など、ウェブでご飯を食べている人ならではのナマの声が沢山。私自身、壇上に立ちながらも、他の出演者のみなさんの洞察豊かな発言にビリビリしっぱなしでした。

「何百万人と見るレシピを、あなたの母親が作ってWebに公開する時代。情報は誰にでも発信することが出来るということがWeb2.0なのではないか」
「Webに2.0も3.0もなくて、Webの進化によってみんなの生活が豊かになっていくということが大事なんだと思う」

すべては、リアルなこの世界を楽しく過ごしていくために。

ネット上に「場」を作り出していく「中の人」たちの情熱にひたすら元気をもらい、ウェブでご飯を食べていくということはどういうことなのだろう、ということを深く考えさせられた1日でした。
バーチャル世界であるウェブをきっかけに、こうしてリアルなイベントという形でアウトプットをするということ自体新鮮で、とても刺激になりました。今後も積極的にこのような機会を設けていければと思います。
ご来場いただきました皆様、本当に有難うございました！

　はじめまして！08年度新卒エンジニアの「きょろ」こと井上恭輔と申します。ミクシィではコミュニケーション開発チームというところで、mixi上の色々なコミュニケーションサービスの開発を担当しています。
　就職で東京に出てきて早10ヶ月、最初は周囲の歩く速度に付いて行けなくて悩んでいましたが、今では新宿駅を迷わず歩けるまでに成長しました。本日は慣れたついでに、そろろそエンジニアブログにも仲間入りしたいなと思いましたので、記事の初投稿に挑戦してみようと思います。
　曰く「ハードボイルドな技術ネタ」の多い当ブログですが、今回は頭を使わずに読める、文字通り「コーヒーブレイク」的な記事をお届けできればと思います。駄文ではありますが、お付き合い頂ければ幸いです。

エンジニアのガソリン「コーヒー」

　みなさんコーヒーはお好きですか？私はコーヒーが大好きで、1日にかなりの量のカフェインを摂取します。朝はブラックコーヒーを飲まないと始まりませんし、コーヒーが無ければコーディングの質も量も低下するような気がします。学生時代からの感覚値ではありますが、どうも研究者やエンジニアという生物にはコーヒー好きが多いようで、「コーヒーが無いと生きていけない！」と思っている人もきっと少なくは無いはず。ある意味「プログラマとはコーヒーに含まれるカフェインをコードに変換する職業」だと言っても過言ではありません。コーヒーは言わばエンジニアを動かすガソリンのようなものであり、私たちの「生命の源」だと言えるでしょう。

図1 エンジニアの朝は一杯のコーヒーからはじまる

マイ・コーヒーメーカーから始まった物語

　配属当時、残念ながらミクシィ開発部には美味しいブラックコーヒーを飲める環境がありませんでした。ティーサーバで紅茶・緑茶・玄米茶・烏龍茶、コーヒーサーバでラテ・カプチーノ・エスプレッソなどを自由に飲むことは出来ましたが、私が求めるのは“穢れ(けがれ)”を知らない純粋で無垢な無糖のブラックコーヒーであり、ミルクやシュガーは不純物以外の何者でもありません。 「美味しいブラックコーヒーを毎日浴びるように飲みたい！」 この想いは日々強くなっていき、ある時、カッとなった私は自腹でコーヒーメーカーを購入し、自席の横に設置することにしました。

図2 導入されたコーヒーメーカー

　毎朝漂うコーヒーを炒れる豊潤な香り。　出社後にメールチェックをしながら飲む至福の一杯。 　私の導入したコーヒーメーカーは意外にもチームメンバーや周りのエンジニアの方々に暖かく迎えられ、次第にコーヒーメーカーを利用してくれる方も増えてきました。しかし、全てが幸せに思われた一方で、何日か運用する過程でいくつかの問題点も出てきました。

• 仕事に集中してるとコーヒーが入ったことに気づかない
• やはりコーヒーは炒れたてが美味いので抽出直後に飲みたい
• 遠くの人にコーヒーが入ったことを連絡するのが面倒
• 一日にどのくらいの回数炒れているのか、今ストックしてあるコーヒーはいつ炒れたものなのかわからない

　弊社のエンジニアは私も含め、モニタに向かいヘッドホンで音楽を聴きながら仕事をしていることが多いので、コーヒーメーカーが近くにあっても、なかなか抽出完了に気が付きません。また、コーヒーが出来たことを離れた席の人に毎回伝えるのも面倒ですし、運用上は抽出記録が残らないのも何かと不便です。そこで私は、金曜日が自由研究時間になるODF（One Day Free）制度を利用して、コーヒーのドリップ状況をネットワークを介して通知してくれる機能を持った「オンラインコーヒーメーカー」を開発しようと考えました。

オンラインコーヒーメーカー「萌香」

　オンラインコーヒーメーカー「萌香（もか）」は、コーヒーのドリップ開始と完了時に、社内のIRC及びtwitterでコーヒーの抽出状況を教えてくれる機能を持った次世代コーヒーメーカーです。ドリップ完了時には抽出時間などに応じて一言メッセージも付け加えるようにしました。　利用者は既存のIRCクライアントやtwitterクライアントを使用することで、手軽にドリップ状況を知る事ができます。

図3 「萌香」によるIRC及びtwitter通知動作画面

　萌香の発言内容はtwitterでリアルタイムにご覧頂く事ができます。地球の裏側からミクシィ開発部のコーヒーメーカー動作状況を確認する場合などにご利用ください。

【Twitter/mixi_mocha】 http://twitter.com/mixi_mocha

　既製品のコーヒーメーカーを改造し、センサーと自作の制御回路を組み合わせることでコーヒーのドリップ状況を検出し、情報を私のPCに伝えます。私のPCでは萌香の制御ソフトがバックグラウンドで動作しており、検出状況に応じてIRCやtwitterにメッセージを投稿する仕組みです。

図4 「萌香」のシステム構成図

　コーヒーメーカーは安全性の観点から分解が難しい作りになっている場合が多く、改造は思ったよりも大変な作業でした。ドリップ状況の検知は、衛生上の観点からもタンクの残り水量を外付けセンサーで取得することはナンセンスです。また、抽出時は内部の部品が非常に高温になるため、物理的なセンサーの接触は極力避けなければいけないという制約事項もありました。　そこで、コーヒーメーカーのドリップ終了時の「自動電源OFF機能」に着目しました。パイロットランプの点状状況を光センサ(CdS光導電セル)で検出し、マイコン（今回はAVR-ATmega88を使用）を用いてA/D変換を行っあと、その値をUSBを経由してPCに送り、検出状況を制御用プログラムで判別してIRCやtwitterへの各種投稿処理を行います。パイロットランプが消灯→点灯で「ドリップ開始」、点灯→消灯で「ドリップ終了」と言った具合です。抽出量などは点灯時間を計測することで把握できます。

図5 「萌香」の制御回路はブレットボード上に実装

　萌香の導入後、チーム内のコーヒーコミュニケーションが劇的に効率化しました。離れた席でも炒れたてのコーヒーを常に知る事ができ、私もコーヒーを入れるたびにお知らせをする面倒から開放されました。光センサーゆえ、お昼時の直射日光が差し込むと、たまに暴走して発言が止まらなくなることもありますが、そこは「ドジっ子」という設定でフォローできちゃうのも擬人化ゆえの素敵なところです。萌香の設定に関して下記にまとめまておきますので、興味のある方はご覧ください。

図6 萌香たん

　萌香のイラストは友人のつてを借りてイラストレータの「さもに凰花」さんにお願いさせて頂きました。あまりのかわいさに、ついカッとなって壁紙も作ってしまいましたので、ご興味のある物好きな方はご利用ください（笑）

萌香たん壁紙1280×1024 (439KB)
萌香たん壁紙1024×768（289KB）

従来までのコーヒーポット状況通知システム

　実は、今日までのコンピュータ発展の歴史の中において「コーヒーメーカーの状況通知」というテーマはいつの時代にも考えられてきた事であり、様々な手法が提案されてきました。しかし、現代的な実装という点で考えた場合、どの手法もニーズを満たすものではありませんでした。

ケンブリッジコーヒーポット方式の問題点

　「コーヒーポットをネットワーク越しに監視する」というアイデアの最初期、かつ最も有名な実装として「ケンブリッジコーヒーポット」というものがあります。これは、1993年にイギリスのケンブリッジ大学のコンピュータ研究室に所属する学生たちによって作られたものです。「コーヒーを飲むためにポットのところに行ったら、まだコーヒーがたまっていなかった！」という非常に残念な問題を解決するために、コーヒーポットの前にビデオカメラを設置し、その画像をリアルタイムにウェブにアップロードすることで、自席に居ながらにしてコーヒーポットの残量を確認することができるという画期的なシステムです。今では「それ、ustreamでできるよ。」と軽く流されてしまいそうなものですが、当時はWindows95すらも発売されていない時代。日本の家庭にはまだインターネットがなく、当時の最新機PC-9821とパソコン通信が花形の時代です。地球の裏側のコーヒーポットの状況をリアルタイムに把握できるというのはまさに革命的な出来事で、新しい時代の到来を予感させるものでした。ケンブリッジコーヒーポットは設置からその後8年間稼動を続け、2001年の大学移転に伴ってスイッチが切られました。このコーヒーポットはeBayのオークションにおいて83万円の値が付き落札されたそうです。
　さて、このケンブリッジコーヒーポット、Webカメラを使った一見シンプルかつスマートで、エレガントな解決策のように思われますが、１つの大きな構造上の問題を抱えています。それは「コーヒー残量が目視できるガラス製のコーヒーポットでしか使用することが出来ない」ということです。ガラス製コーヒーポットは安価に入手可能ですが、その構造上、保温性が低く、残量がある限り常に底部のヒーターでコーヒーを加熱し続けなければいけません。コーヒーの保温には多くの電力を消費するため、エコが叫ばれる昨今の社会的情勢にマッチした解決策とは言いがたいものがあります。また、常に加熱を続けることでコーヒーが煮立ち、本来の味を損なってしまうのもコーヒー好きには許しがたいことで、現在ではポットに魔法瓶を採用した保温性の高いコーヒーメーカーが市販されています。オフィスにおいて非同期的に消費されるコーヒーには、魔法瓶式コーヒーメーカーの方が適しているため、ケンブリッジコーヒーポット方式は現実的なソリューションではありません。

図7 ケンブリッジコーヒーポットの確認ページ

HTCPCPの問題点

　HTCPCP(ハイパーテキストコーヒーポット制御プロトコル）はRFC2324で定められた世界標準のコーヒーポット制御用プロトコルです。　いわゆるジョークRFCと呼ばれるものの一種ですが、仕様自体は実装可能なものであり、HTCPCPに準拠したコーヒーメーカーの制作例なども存在します。しかし、実際の現場においてHTCPCPはあくまで「ジョーク」の領域を出るものではなく、次に上げるような問題点があり使い物になりません。

• HTTPの拡張であるため、プロトコルシーケンスはクライアント駆動であり、コーヒーメーカー側から非同期にメッセージを送ることができない
• たとえば、コーヒーメーカーから「コーヒーが入ったよ！」という通知を送るはできない
• コーヒー炊き立て通知を実装するにはCOMETなどによるロングポーリングの手法を用いる必要があるが、コーヒーポットへの組み込みサーバは一般的に貧弱なため現実的な解決策ではない
• IE、Firefox、Safari等、主要なブラウザはcoffee://URIスキームに対応していない。デファクトなクライアント実装も無い。開発しても利用者にインストールしてもらうのは面倒
• というか、コーヒー粉をセットするときに席を立つんだから、その時にスイッチを操作したほうが便利だろ常識的に考えて
• そもそも、RFCの内容がふざけており、適当すぎる。（ジョークRFCなので仕方ない）
• ミルクやシロップを設定する拡張フィールドがあるが、俺はブラック以外をコーヒーとは認めない

　上記のような問題を解決した「萌香」は、Web時代におけるモダンなコーヒーメーカー状況通知システムの実装なのではないかなと勝手に考えております。

まとめ

　Web時代における現代的なコーヒーメーカー状況通知システムとして、オンラインコーヒーメーカー「萌香」を開発し、その開発背景と歴史、実現機能、実装方法などを紹介させて頂きました。また、「ミクシィのODF(OneDayFree)制度ってどのくらいFreeなんですか？」とよく聞かれることがあるのですが、「会社で朝からハンダこてを握って電子回路を組んでコーヒーメーカーを改造できるくらい自由です！」という事が少しでもお伝えできたなら幸いに思います。　Web企業でのハードウェア制作というのは、一見して異質な畑違いの行為のような感じもしますが、コミュニケーションを創造する仕事に従事するからには、ヒューマンインタフェースに関する研究やデバイスを通してのコミュニケーションのあり方についても積極的に考えて行きたいと個人的には思っています。コミュニケーションはブラウザの上で完結するものではないのですから。

図8 金曜日の私のデスクはWeb企業に見えない

　この他にも、色々とハードウェアを絡めたデモプロダクトなんかを作っていたりします。機会があれば、今後もご紹介して行けたらいいなと思っていますので、生暖かい目で見守って頂ければ幸いです。 　ハードウェアに興味を持たれる方がどれほどいるか不安で仕方ないのですが、もしこんな記事でもブクマなどが付くようでしたら、次回は「萌香」の実装に関して回路の制作方法、マイコン制御用プログラムの開発方法やソースコード、壁紙第２弾なんかを晒してみようかなと思っています。 それでは、最後までお読み頂き誠にありがとうございました！