yohei-y:weblog: Javascript HTML のデザインパターン
僕もご多分に漏れず 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
yohei-y:weblog: 良い URI の設計
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) 問合せパラメータな
yohei-y:weblog: Web らしく URI で連携する方向
前のエントリで触れた ID だけのディスカバリの問題点ですが、 他にもこんなのもあります。 僕が自分のブログにはてな ID を埋め込んだとして期待するのは、 ブログを訪れた人が自分のブックマークやアンテナを見に来てくれたり、投げ銭してくれたりすることです。 でも僕がはてなで何を使っているかは僕にしかわかりません。 僕の場合はてブとはてアは使ってるけど、 はてダは更新を止めちゃった、はてフは知らん、という状況です。 もしかしたらアサマシは嫌いだから投げ銭してほしくない、という人もいるかもしれない。 これって「はてなID」の埋め込みだけでは実現できません。 自分ははてなのこのサービスを使っているよ、という主張をできないからです。 ではどうするか。 自分ははてなのこのサービスを使っているから見に行ってね、という宣言をしたらどうでしょう。 head 内で宣言するんだったらこんな感じ。 <link
yohei-y:weblog: Hatena ID Auto-Discovery について
昨日は SIGMOD-J の大会に行った後にアルファギークなお二人と食事をしてきました。 大会ではやはり naoya さんの Web 2.0 についての話が一番面白かったです。 周りにいた人の反応も一緒でした。 ちなみに僕は naoya さんは初対面。 食事に途中参加の高林君とはちょうど4年ぶりだったことが今判明。オリンピックみたいだ:-)。 naoya さんは普段から blog やブックマークを見ているので、ぜんぜん初対面な気がしなかったんですが、 僕としては REST だの Folksonomy だの microformats だのといった単語をガンガン喋ったり聞いたりするのが新鮮かつエキサイティングでした。 やっぱり直接会って話すのは大切だと実感です。 以下本題です。僕は話題に出遅れてしまったんですが Hatena ID Auto-Discovery について。 naoya さんには
yohei-y:weblog: Atom 1.0
Atom Syndication Format 1.0 が Tim Bray からアナウンスされましたね。 いろいろなところで言及されていますが、 XML cover pages がいつもながら一番まとまっています。 ちなみに RSS/Atom のこれまでの流れは Robert Sayre の記事によくまとまっています。 これで syndication format の本命は RSS 2.0 と Atom 1.0 に絞られたわけですが、 これからどうなるか注目です。 両者の比較は Tim Bray のもの(日本語版)がありますが、 はっきりいって機能的にはそんなに違いませんね。 Atom 1.0 の方が後出しジャンケンなので全体的にすっきりしていますが、 普及状態から言うと圧倒的に RSS 2.0 が勝っています。 Atom の方はもちろん syndication format 単体で使え
yohei-y:weblog: 今後10年
この weblog のアクセス数がいつもの10倍になっていて、 なんだなんだと思ったら naoya さんとこで言及されてました。 Remix や Folksonomy という考え方はすばらしいのだけど、 それらを実現する手段としてよりシームレスなものっていうのは一体何なんだろう。 使い手がそれらを意識することなしに、その恩恵を得られるもの。 自分の両親が blog を使いはじめて整えられたアーキテクチャでウェブサイトを構築し、 RSS や Atom でシンジケーションするということはもしかしたらありえるかもしれないけど、 Greasemonkey で Remix して tagging で情報をうまく整理するなんてことはどう考えてもあり得ない。 Remix とか Folksonomy ってそんなに難しい話なんですかね。 tagging だの microformats だの api だのといっ
yohei-y:weblog: REST -> AtomPP -> blog -> Permalink -> RSS/Atom -> Remixing (Ajax/Microformats/Folksonomy)
REST -> AtomPP -> blog -> Permalink -> RSS/Atom -> Remixing (Ajax/Microformats/Folksonomy) 少し前の話だが、Blog Hackers Conference 2005 に行った。 miyagawa さんのキーノートも、naoya さんの講演も、キーワードは Web 2.0 (的なもの)だなという印象だった。 中でも特に気になったのはこのスライドで blog が missing piece を埋めた、という話だ。 こちらのコメントにも書いたのだけれど、 ここでいう blog というのはいわゆる weblog system/service だけを指すのではなくて、 blog 周辺の技術 (RSS, Atom, AtomPP, REST, Permalink) が方法論として、プラットフォームとなる、というの
yohei-y:weblog: CDF を…覚えていますか?
CDF を覚えている人はいるだろうか。 たとえば このファイル をダウンロードして、デスクトップに保存してみてほしい。 Windows を使っている人なら、アンテナのアイコンが現われるはずだ。 ためしにダブルクリックしてみよう。 あやしげなダイアログボックスが表示されるだろう(キャンセルしといてね)。 右クリックしてみよう。 いっぱいメニューが出てくるはずだ。 エディタで開いてみよう(「右クリック→編集」でもよい)。 タグ名が大文字の見なれない XML ファイルである。 これは XML の創世記に話題となった Channel Definition Format (CDF) だ。 覚えていない人、あるいはそもそも知らない人のために解説すると、 CDF は XML の最初のアプリケーションとして 1997-1998年当時に大変注目されていた技術である。 タグ名が大文字なのも、当時としては普通の
yohei-y:weblog: REST 入門(その8) REST でないもの
» REST 入門 目次 WWW は REST アーキテクチャスタイルのアーキテクチャを採用した実装のひとつですが、 REST アーキテクチャスタイルでないアーキテクチャの WWW アプリケーションもかなり存在します。 REST でないものを一言で言ってしまうと、 URI と HTTP を正しく使っていないもの、ということになります。 以下では URI と HTTP の誤った使い方について説明します。 URI をクライアントで組み立てる URI をクライアント側でごちょごちょ組み立てなければならないのなら、それは REST ではありません。 たとえば、はてなブックマーク AtomAPI が、こんなインターフェースだったらどうでしょう? ブックマークをキーワードで検索する。 POST /uso/bookmarkSearchService HTTP/1.1 Host: b.hatena.ne.
yohei-y:weblog: REST 入門(その10) 終わりに
» REST 入門 目次 前回まで、REST 入門ということで、 REST アーキテクチャスタイルとは何なのか、 について基礎的なところを結構細かく :-) 説明してきました。 REST 入門はこれで終わりですが、最後にロイ・フィールディングの論文から REST アーキテクチャスタイルの各制約を抜き出して説明します。 Null スタイル 最初は、制約がまったくないところからはじまります。それが Null スタイルです。 クライアント・サーバ 最初の制約はクライアント・サーバです。REST がクライアント・サーバから派生していることは、 "2. アーキテクチャスタイルとは" で解説しました。 ステートレス REST スタイルにおいて、サーバはクライアントの状態を管理しません。すべての状態はクライアントで持ちます。 クッキーでの状態管理が REST でないことは "8. REST でないもの"
yohei-y:weblog: REST 入門(その9) REST と SOAP
» REST 入門 目次 前回、WWW のうち REST アーキテクチャスタイルに従っていないものについて解説しました。 今回は「その筋」では有名な REST と SOAP の対決の概略を解説します。 Google で "REST vs SOAP" あるいは "SOAP vs REST" を検索すると、 たくさんの Web ページが見つかります。 いろいろな立場の人が、それぞれの意見を述べ合っていて、 ここで全ての主張や意見を解説するのは不可能です。 これから解説する内容は、あくまでも個人の意見ということをご了承ください(まー weblog なんてそんなもんですが)。 ところで最初からこんな話をするのもアレですが、 REST と SOAP は比べられるものなのでしょうか。 REST はこれまで何度も述べてきたとおり、ネットワークシステムのアーキテクチャスタイルです。 一方で SOAP はプ
yohei-y:weblog: 疎結合と XML
疎結合(loosely-coupled)って何でしょう? 僕自身、適当に疎結合という言葉を使ってしまいがちですが、 ちゃんとした説明なり定義なりが必用だと感じています(自分のために)。 いいかげんな定義で話をはじめると、 各人の方向性がずれまくって議論ができないですよね。 Web サービスしかり、 SOA しかり、REST しかり。 ということで今回は僕なりに疎結合ってこんなもの、 というのを考えてみます。 ものすごく一般化してしまうと、 疎結合というのは複数のコンポーネント間の結び付きが ゆるいことを指すんでしょうね。 たぶん、ここまでは誰でも同意してくれるはず。 ただこれだけでは議論ができなくて、 このコンポーネントに何をもってくるかを決めて、 はじめて具体的な話ができます。 僕がここで話したいのは Web サービスの文脈での「疎結合」ですから、 コンポーネントは Web サービスにな
yohei-y:weblog: REST 入門(補足2) POST と PUT
» REST 入門 目次 kwatch さんから以下のようなコメントをもらいました。 POSTとPUTの説明が逆では？たしかPUTが新規作成であり、POSTは送ったリソースの処理を指定したURIに任せるということだったと思いますが。 コメント欄では返答が書ききれなかったので、補足として新しいポストを追加します。 RFC2616 では PUT の動作が二つ規定されています。 指定した URI がすでに存在している場合 PUT はその URI のリソースを修正(更新)する 指定した URI が存在しない場合 PUT はその URI のリソースを新規作成する PUT を規定している 9.6 節には POST と PUT の違いとして以下の記述があります。 The fundamental difference between the POST and PUT requests is reflect
yohei-y:weblog: まっとうなソフトウェア工学に期待すること
naoya さんのダイアリーに端を発してちょっとだけ議論が起きている。 まず naoya さんのオリジナルのポスト。 はてなが従来のいわゆる世間一般の開発手法を採用せず Perl でアジャイルな開発手法をを選ぶ理由として、 その開発するソフトウェアサービスの性質と 動的型付け言語の開発効率を挙げている。 対してオリオナエさんは naoya さんがソフトウェア工学を軽視している(ように見える)点を、 薬学と建築工学の例を使って批判している。 吉松さんははてなのサービスとオリオナエさんの薬の例のギャップを指摘して、 いわゆるソフトウェア工学的手法に疑問を投げかけておられる。 Don'tStopMusic さんもオリオナエさんの例とはてなの違いから いわゆるソフトウェア工学(と Java)ははてなには合わないという主張だ。 ここまで読んで思ったのは、みなさんの「ソフトウェア工学」感のずれだ。 そ
yohei-y:weblog: Web Services Considered Harmful?
WWW2005 のパネルディスカッション "Web Services Considered Harmful?" に行ってきた。 いやー楽しかったなー。 パネリストは Rohit Khare (Moderator) Tim Bray Fumiaki Yshimatsu Mark Baker Adam Bosworth という超豪華メンバー。以下、簡単にメモです。しょうもないメモですみません。 他のブログでまとめているのを見つけたら、更新しておきます。 まず Rohit Khare から背景の説明 SOAP, WSDL から 5年 WS-* 問題 表面的には標準化の問題 実際は技術の問題 Tim Bray Web サービス二つの側面 ひとつはネットワーク越しの API もうひとつは XML で表現されたメッセージ交換 WS-* はあほみたいに仕様書のページがある 吉松さん Amazon Web
yohei-y:weblog: ソーシャルブックマーク雑感
REST 入門はちょっとお休みして、weblog っぽく日々の雑感でも。 僕は現在 del.icio.us とはてなブックマークを使ってます。 この二つ、いちおう使い分けています。 del.icio.us 自分用。主として英語ページのうち、わりと目に留まって読もうと思ったものをクリップ。 その後読んだ後に感想を追加。後から検索する はてなブックマーク del.itio.us にポストしたもののうち、コメントがついたものをコピー。 主として自分と同じ興味の人を探すため。今のところ見つけたのはたとえば hiromark さんとか naoya さんのこのポストを読んで思ったのは、 そういやカテゴリとかキーワードとかぜんぜん使ってないなーということ。 僕もまさに **users しか使っていなかった。 改めて自分のブックマークのカテゴリやキーワードを見てみると、 特に英語系は厳しいですね。 僕自身
yohei-y:weblog: REST 入門(その7) ハイパーメディアの可能性
» REST 入門 目次 前回は REST で受け渡しされるリソース同士が、 URI を使ったハイパーリンクで相互に結び付けられることによってハイパーメディアを実現し、 その機能拡張には XML 名前空間などが利用できることを説明しました。 今回はより応用的なハイパーメディアと REST の関係を見ていきたいと思います。 例によってはてなブックマークを使って説明します。 リソースの URI はひとつではない 現状のはてなブックマークでは、 ひとつのブックマークエントリ(リソース)の URI は僕が知る限り以下の三つがあります。 ブックマーク一覧 http://b.hatena.ne.jp/yohei/20050429#187800 人間用 Edit URI http://b.hatena.ne.jp/yohei/edit?eid=187800 Atom API 用 Edit URI htt
yohei-y:weblog: REST 入門(その4) HTTP GET -- その絶大な効果
» REST 入門 目次 前回は、リソースの特徴について解説しました。 しかし、なぜリソースが重要なのかはまだわからないと思います。 今回はその一部を紹介します。 まず、おさらいしましょう。 僕たちは以下のリソースを例に使っています。 東京の天気予報 2005年8月24日のスケジュール 新花巻駅の写真 Dijkstra 著 "Go To Statement Considered Harmful" 僕の最近のブックマーク そして、それぞれのリソースの識別子(URI)は以下のようになります。 http://weather.yahoo.co.jp/weather/jp/13/4410.html https://example.com/schedule/20050824 http://www.flickr.com/photos/60043209@N00/6337155/ http://www.ac
yohei-y:weblog: REST 入門(その5) 四つの動詞 -- GET, POST, PUT, DELETE
» REST 入門 目次 前回、URI で特定できるリソースに HTTP の GET という動詞を適用して、 ある時点・条件での状態の表現を転送するのが REST だという説明をしました。 URI (名詞)に適用できる動詞は GET だけではありません。 今回は GET 以外の三つの動詞を紹介します。 前提知識 ここでは実際に稼動している REST 実装の例としてはてなブックマーク AtomAPI を使います。 はてなブックマークそのものの説明はしませんので、あらかじめご了承ください。 はてなブックマークに登録したひとつのブックマークを考えてみてください。 このひとつのブックマークエントリが、対象のリソースになります。 たとえば REST 入門の目次をブックマークしたとします。 このブックマークの URI は http://b.hatena.ne.jp/atom/edit/175062 で
yohei-y:weblog: REST 入門(その3) 全てはリソースから
» REST 入門 目次 では(やっと) REST の具体例を見ていきましょう。 REST で最も重要な概念はリソースです。以下にリソースの具体例を挙げてみます。 東京の天気予報 2005年8月24日のスケジュール 新花巻駅の写真 Dijkstra 著 "Go To Statement Considered Harmful" 僕の最近のブックマーク REST においてリソースとは名前のつくあらゆる情報を指します(つまり名詞ですね)。 たとえば、「東京の天気予報」というリソースには今日の天気予報も明日の天気予報も含まれるでしょう。 あるいは「2005年8月24日のスケジュール」には僕のスケジュールだけでなく、 あなたのスケジュールも含まれるかもしれません。 リソースで重要なのは、その意味です。 リソースの実体は時間や条件によって変化するかもしれませんが、 その意味は不変です(これが名詞たる所
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
