先日、Erlang分散システム勉強会で、最近私が追っている CouchDB というオープンソースのドキュメント指向分散データベースについて紹介してきました。発表資料をおいておきます。 ドキュメント指向データベース CouchDB(PDF) 分散システムでしかも Erlang というニッチっぽい勉強会でしたが、30人の参加者が一瞬で集まり、非常に熱い会でした。私も自分の好きな話を好きなように話してしまい、参加者のみなさんはドン引きだったかもしれません… これだけでは何なので、ついでに手元の Fedora7 on coLinux に CouchDB の trunk を入れたときの手順と、簡単な couchdb の使い方をご紹介しておきます。 基本的にはオフィシャルwikiにあるとおり、yum でモジュールを入れていけば問題ありません。素の coLinux からの場合、以下のモジュールが必要でし

少し前の話ですが、RESTful Web サービス読書会に参加してきた山本です。 この会は kunitさんが企画・運営されている読書会で、毎月第二土曜日の午後をほぼフルに使って、田町のキャンパスイノベーションセンターで開催されています。 私は初回に監訳者としてリアルで参加し、第2回はリモートで ustream の中継を見ながら lingr 等のチャットで観戦・参戦しました。 こういった読書会に参加するのは初めてだったのですが、普段なかなかお会いできない異業種の方(今回の場合はPHP)と、直接話すことができて大変有意義な会でした。土曜日の午後、田町に出かけられる人にはぜひお勧めの勉強会です。 また、リモートでもかなりきちんと試聴できるので、関東近県以外にお住まいの方も参加可能です。さすがにリモートでの発表はちょっと難しそうですが、チャットでの議論もかなり役に立つと感じています。 こういうこと

RestWiki をたまに見直すと新たな発見があって面白い。 たとえば先日、「ステートレスなやりとりとは何か(What is Stateless Interaction?)」という箇所を見つけて、興味深く読んだ。このページは以前も絶対に読んでいるはずなのだが、 人間は忘れてしまうものである。 RestWiki の例でも充分わかりやすいのだけれど、自分でも例を思いついたので書きとめておく。 ステートフルサーバとステートレスサーバはどう違うのか。 まずは、ステートフルの例: 客: こんにちは 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ポテトで 店員: ドリンクは何になさいますか? 客: ジンジャーエールで 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: Mでいいです 店員:

AtomPub がついに RFC になりました! RFC 5023 The Atom Publishing Protocol RFC 5023 The Atom Publishing Protocol(HTML) 関係者のブログ Joe Gregorio: RFC 5023 - The Atom Publishing Protocol Sam Ruby: <appdraft>no<app:draft> RFC になるまでずいぶんと長かったように感じますが、 その分完成度は上ったのだと思います。 interop もすでに何回も開催されており、その結果も良好です。 AtomPub は全ての、とはいかないまでも、多くの Web サービスのベースとなることが できるプロトコルです。 たとえば blog 、何らかのデータベース、画像/映像リポジトリ、 Wiki、カレンダー、ソーシャルブックマークなど

NTT コミュニケーションズの朝倉さん(実は NAIST の研究室の先輩です)と一緒に 7/30 に Atom Publishing Protocol の接続試験を東京で行います。 http://intertwingly.net/wiki/pie/July2007InteropTokyo 4月に Google Campus で行われたものの日本版です。 今のところ参加する予定なのは あさくらさん(ntt.com) 丸本さん(ウィザ) shigeta さん miyagawa さん(リモート) たけまるさん 我々 参加されたい方は上記 Wiki に名前を書く、あるいは僕(yoheiy at gmail dot com)までメールください。APP の実装をお持ちの方はぜひ。

自己紹介� 名前�� YAMAMOTO Yohei 職業­ ソフトウェアエンジニア(XML guy) 興味 XML/Web サービスの設計一般 連絡先�� yoheiy at gmail dot com 注意書き この日記に記述されている内容は、筆者の個人的な主張や考えであり、筆者の勤務する企業や属する組織とはまったく関係ないことをお断りしておきます。

しばらく時間が空いてしまいましたが、最近気になった本を3冊紹介します。 まずは Flickr の中の人、Cal Henderson の Building Scalable Web Site。 REST が設計思想からスケーラビリティを攻めているのに対し、この本は実践からいかにスケーラブルなサイトを構築するかを攻めています。 似たような話は古くは LiveJournal の中の人から、 Flickr の中の人まで、 さらに最近は mixi の中の人や はてなブックマークの中の人 (ビデオ)、 ライブドアの中の人まで さまざまなテクニックや経験則を公開してくれていて、まさに高速道路建設中なわけですが、 この本はその高速道路のひとつの出口になるんじゃないでしょうか。 ぜひ日本語版もほしい一冊だと思います。 Building Scalable Web Sites Callum Henderson

前のエントリでこんなことを書いたばかりだけれど、REST ってやっぱりどうよ、という気分になったので久々に blog を更新してみる。 ただただしさんのおれだったらフォト蔵APIをこうするを読んで、僕が del.icio.us に書いた感想は +1。ID == URI ですよね。Cool URI は名詞であるべき、というのは強調したい。「日本REST協会」入りたくないなー(笑)。みんな休んでそう というもの。たださんのエントリでは URI と書くべきところが ID になっててちょっと気になったり、「作法」は「アーキテクチャ」じゃなくて「アーキテクチャスタイル」だ、とか思ったのだけれど、でも本筋としては納得の内容だった。 しかし、たださんのエントリの、たかはしさんや mizzy さんのコメントを読んでうーんと唸ってしまった。 僕にはお二人の言いたいことがわかる。んで両方間違っていないと思う。

なんか催促されちゃったみたいなので :-) 詳しく書いてみます。 はてなのブックマーク件数取得 API いいですね。 今さら xml-rpc かよ! というツッコミは置いておいて、 データ重要な世の中で有用なコンテンツ(メタデータ)にリーチする 方法が増えるのは喜ばしいことです。 そうそう、こういう API を AtomPP で実装するとしたらどんな感じなんだろう。そもそもうまくフィードで定義できるのか。教えて偉い人! 偉い人じゃないけど、結論からいえば、 Atom Publishing Protocol (APP) そのままじゃ無理です。 やってもいいけどどうしても無理が出てしまいそう。 そもそも目的が違うのだから、ここは野良 XML/プロトコルでいいのでは。 ただ、結果をフィードで取れるとそれなりに嬉しいかもしれない。 普通 REST で検索するときは query string を使っ

昨日、第八回XML開発者の日が開催されました。死ぬほどつかれたけれど、死ぬほど面白かった。こんなにまじめに一日中頭を使って人の話を聞いたのは久しぶりです。 僕の発表資料とパネルのときに即席で作ったスライドです。発表資料の方はもんたメソッドなのでスライドショーで見てください。パワーポイントない人は OOo でお願いします。(2006-04-11 置き場所修正) 以下、感想とまとめです。 REST入門 山本陽平(株式会社リコー) REST の入門編を喋ってみました。 なるべく基本的なところを丁寧に話したかったんですが、成功したかどうか… コネクタの話をしなかったので、高橋さんにちょっとご迷惑をおかけしました m(_ _)m はてなとREST API 伊藤 直也(株式会社はてな) モテ重要、ということでなんではてなが APP を採用したのか、 その根底に流れるデータ重要という考え方、 サーバサイ

僕もご多分に漏れず Javascript で遊んだり調べたりしています。 いろいろなクールなサイトの生 Javascript を見て勉強しているのですが、 まず面白いなと思ったのがロールオーバーの実現方法です(JavaScript や HTML をわかってる人には当たり前の内容だと思うので、ツマラナイ話だと思いますが)。 WaSP の左上の画像のロールオーバーは <img id="logo" src="/img/logo.gif" height="100" width="103" alt="Web Standards Project logo" /> 生 HTML はこんなかんじで onmouseover/onmouseout 属性を記述せず、 JavaScript で function initRollOvers() { var logo; if (document.getElement

URI は綺麗であるべき、と常々思っているんですが、よいページを発見しました。 Michael Eakes のこのエントリです。 Tanya Rabourn がリストアップしている文献一覧からエッセンスをまとめてくれています。 曰く、よく設計された URI とは 変らない(don't change) 人間が推測可能(are human guessable) 論理的(ファイルシステムを反映する必用がない) (are logical (no need to mirror a filesystem)) サイト構造をビジュアライズするのに役立つ(help visualize the site structure) 短い(are short) 小文字を使う(use lowercase) 予期されない記号を使わない(don't use unexpected punctuation) 問合せパラメータな

昨日は SIGMOD-J の大会に行った後にアルファギークなお二人と食事をしてきました。 大会ではやはり naoya さんの Web 2.0 についての話が一番面白かったです。 周りにいた人の反応も一緒でした。 ちなみに僕は naoya さんは初対面。 食事に途中参加の高林君とはちょうど4年ぶりだったことが今判明。オリンピックみたいだ:-)。 naoya さんは普段から blog やブックマークを見ているので、ぜんぜん初対面な気がしなかったんですが、 僕としては REST だの Folksonomy だの microformats だのといった単語をガンガン喋ったり聞いたりするのが新鮮かつエキサイティングでした。 やっぱり直接会って話すのは大切だと実感です。 以下本題です。僕は話題に出遅れてしまったんですが Hatena ID Auto-Discovery について。 naoya さんには

前のエントリで触れた ID だけのディスカバリの問題点ですが、 他にもこんなのもあります。 僕が自分のブログにはてな ID を埋め込んだとして期待するのは、 ブログを訪れた人が自分のブックマークやアンテナを見に来てくれたり、投げ銭してくれたりすることです。 でも僕がはてなで何を使っているかは僕にしかわかりません。 僕の場合はてブとはてアは使ってるけど、 はてダは更新を止めちゃった、はてフは知らん、という状況です。 もしかしたらアサマシは嫌いだから投げ銭してほしくない、という人もいるかもしれない。 これって「はてなID」の埋め込みだけでは実現できません。 自分ははてなのこのサービスを使っているよ、という主張をできないからです。 ではどうするか。 自分ははてなのこのサービスを使っているから見に行ってね、という宣言をしたらどうでしょう。 head 内で宣言するんだったらこんな感じ。 <link

» REST 入門 目次 前回、WWW のうち REST アーキテクチャスタイルに従っていないものについて解説しました。 今回は「その筋」では有名な REST と SOAP の対決の概略を解説します。 Google で "REST vs SOAP" あるいは "SOAP vs REST" を検索すると、 たくさんの Web ページが見つかります。 いろいろな立場の人が、それぞれの意見を述べ合っていて、 ここで全ての主張や意見を解説するのは不可能です。 これから解説する内容は、あくまでも個人の意見ということをご了承ください(まー weblog なんてそんなもんですが)。 ところで最初からこんな話をするのもアレですが、 REST と SOAP は比べられるものなのでしょうか。 REST はこれまで何度も述べてきたとおり、ネットワークシステムのアーキテクチャスタイルです。 一方で SOAP はプ

naoya さんのダイアリーに端を発してちょっとだけ議論が起きている。 まず naoya さんのオリジナルのポスト。 はてなが従来のいわゆる世間一般の開発手法を採用せず Perl でアジャイルな開発手法をを選ぶ理由として、 その開発するソフトウェアサービスの性質と 動的型付け言語の開発効率を挙げている。 対してオリオナエさんは naoya さんがソフトウェア工学を軽視している(ように見える)点を、 薬学と建築工学の例を使って批判している。 吉松さんははてなのサービスとオリオナエさんの薬の例のギャップを指摘して、 いわゆるソフトウェア工学的手法に疑問を投げかけておられる。 Don'tStopMusic さんもオリオナエさんの例とはてなの違いから いわゆるソフトウェア工学(と Java)ははてなには合わないという主張だ。 ここまで読んで思ったのは、みなさんの「ソフトウェア工学」感のずれだ。 そ