対決シリーズ

JRA登録馬名を見ていて面白いと思った馬がいたので思い出しました。対決シリーズ。去年（２００８年５月）の社員旅行で香港マカオに言ったときに、バスの屋根に乗って意味不明な言葉を絶叫した社員をイギリスのソーシャル界にデビューさせようという話がきっかけでした。このビデオをYouTubeにアップし、イギリス在住の生粋のイギリス女性に審査してもらおうというものです。このときは、勝ち抜き戦を想定していました。対戦相手の募集と、審査員の募集について考えがまとまらず、頓挫していました。

名前対決〜JRA登録馬編

サイボーグ
父：タバスコキャット
母：パワフルレディ（母の父：マルゼンスキー）


対決シリーズは、様々な視点から、審査員の独断と偏見により優劣を競うソーシャルゲームです。投票したコメントに投票することもできます。ただしコメントへの投票による獲得ポイントは０．５ポイントとなります。また審査員ポイントが付与されます。ポイントの高い審査員は審査力が高いと見なされ、ランクが上がっていきます。同時に何回勝ち抜くと何を貰えるというのを独自に設定できるスポンサーを同時募集。スポンサーの独断で特別賞も設定できます。対決はマッチレース方式の勝ち抜き戦とトーナメント戦、総合ポイントを争うシリーズ戦、があります。


過去の対決
スター誕生編
自己PR（プロフィール、ビデオ、写真、他）でスター性を競います。

データの型としてのコンボボックス

Rails1.2でのマイグレーションのコードを書こうとしています。

 

class CreateMemos ＜ ActiveRecord::Migration

  def self.up

    create_table :memos do |t|

      t.column :tittle, :string

      t.column :info_source, :combo_box   ----- (1)

      t.column :description, :text

      t.column :photo_uri, :url ※

    end

  end

  def self.down

    drop_table :memos

  end

end

(1)で、データが何でコンボボックスに限定されるのか？それは可笑しい、というのが今までの考え方だと思います。私（か誰か他の人）が実現しない限り、それは正論でしょう。こういうコードを書きたければ（少なくともRails1.2では）自分で別なテーブル..info_sourcesを定義して、そのID...info_sources_idを定義し、それに対してhas_many、belongs_to 交換を行なう必要があると思います。そもそもコンボボックスかどうかはモデルには関係ない話で、関係させてはいけない、というのが常識だと思います。

しかしこれは、私もいま気づいてメモしているわけですが、実際にあるページをテンプレートにするという考え方と同じです。※これについてはブログエントリしてないかもしれません。

つまり、コンボボックスとして使うために普通あるべきデータの形、と読み替えることができます。その結果、コンボボックスで表現するに相応しいデータ形式が選ばれるのです。ですから、実際にページになるときに、それがリストボックスでも構いません。ただ、データを設計する（考える）という場合に何が重要で何が元になるかと言えば、どんな風なページにしたいかであることは言うまでもありません。ラフで書いたイメージ通りにデータが定義されれば、こんなに便利なことはないのです。

コロンブス的に言えば、みんな１つのUI部品を仮定すると、それが絶対的なものと思い込んでしまっていることでしょう。コンボボックスを右クリックしてリストボックスに変更できて、何か不都合がありますか？　もちろん縦長になる分レイアウトは崩れるでしょうが、リストボックスにしたいのですから、そんなことぐらい分かっているはずです。

これが概念交換機の姿なのです。

ただしRailsに組み込もうとすると、もっとRailsを詳しく知らなければならないでしょうし、組み込めるかどうかもわかりません。通常のオブジェクトとしてならまだしも、combo_boxを受けた側は一体どうすれば良いのか。CoC風にはinfo_sourceという名前からinfo_sourcesというテーブルを作成し、項目はデフォルトの_idとTitleぐらいを付けて、InfoSourceクラス（モデル）にhas_many ,  Memoクラス（モデル）にbelongs_to info_source_idを追加するという感じです。しかしすでにあるソースに行を追加するという芸当がRailsで出来るのか、という問題もあります。それならMashupEX!にRailsEX!を入れるというのが、やはり定石でしょう。

※は探すとRails2.0でこういう記述を見かけたことがありますが、私はまだ1.2なせいか、エラーになってしまいます。Rails本ではStringか何かで定義されていたと思います（間違ってたらごめんなさい）。

アラートをブログでも

ブログを書いていると、ブログを表示していることが多くなります。他のブログはどうか知りませんが、Bloggerの場合、自分のブログは（ログインしていれば）そのまま編集や投稿ができるので、ある意味自分の前線基地のような雰囲気を醸し出しています。

Yahoo!知恵蔵やOKWaveのようなQAサイトには、有りと有らゆる分野の質問に答えてくれる人たちが沢山いるようですが、こんな私でも”こういうこと”なら答えられるかもしれない、もしくは答えてみたいという質問があるかもしれません。しかしすべての新着Q＆Aに目を通すのはなかなか難しい。例えそれがRSS配信されていたとしてもです。できればGoogleアラートを質問に適用したいと思います。それで終わりではありません。それを自分のブログに表示するのです。自分がどんな質問に興味を持っているのか、どんな回答しているのか、というのは、ブログ読者との新たな共通点を生み出すに違いありません。来訪者が代わりに（といっても代理というわけではありませんが）答えてくれる場合も少なからず出てくるでしょう。つまりアクセスの増加にも繋がるわけです。これを知恵蔵が黙って見過ごすはずがありません。

もし無かったら、いま募集中のモバイルウィジェットコンテストに応募するついでに作ってみるというのも手ででしょう。

私はSNSを使ってないのですが、使ってる人たちはどうでしょう？あるいはiGoogleなどのポータルを使っている人たちは？FaceBookのようなプラグインなどにはもう既に実装されてるのかもしれませんね。

おやすみOliva。また明日ね！

仮オープンから早１年と２ヶ月、残念ながら、cafe2.0 concepto oliva は撤収することとなってしまいました。この間、結果を出すことができず、本当に残念ですが、得たものも沢山ありました。何から何まで初めてのことを、これだけ少ないリソースで実際に行動するのは現実問題として非常に厳しいものでしたが、私はこれを乗り越えていきます。そして近いうちに必ず素晴らしい”何か”をこの世に送り出します。それまでお店はちょっとお休み。この次、グッドモーニングでお会いしましょう。

ページコメントパーツ

このエントリはフィクションです。

ページに間違いを見つけたら、ウェブマスターにメールする、というのはいささか面倒です。そこでそれを伝えるためのページコメントパーツを使って、具体的なページ要素に簡単にコメントできるようにしましょう。

例えばいつも大変お世話になっているja.netbeans.org。最近（だと思うのですが）言語選択バーが出来てますます便利になりましたが、それもこれも翻訳されたページがあればこそ、なのは言うまでもありません。本当に感謝しています。

ただ、もちろん、中にはリンクが違ってたりすることがあったりするわけです。そんなときはメーリングリストにポストすると、嫌な顔一つせず、逆に教えてくれてありがとうございますと言ってくださいます。しかし、かといって、非常にささいなことをメーリングリストにポストするのは、何だかとっても躊躇われるのです。

そこで、本当は勝手にWikiみたいに修正できるのが良いのかもしれませんが、なかなかそうも行かない場合があるでしょう。そんなとき、修正イメージをどこかに書き込めて、それをウェブマスターが見ることができたら、随分手間が省けるし、ちょっとしたことですけど、助けにもなるじゃないですか。

ページコメントパーツは、主にページの明らかなる間違いをウェブマスターに知らせるためのツールです。コメント情報はページコメントサーバに置かれるので、評価されるウェブサイト側は何も用意する必要がありません。パーツスニペットを貼るだけです。

ページコメントサーバはデフォルトではコメントしようとしたときに初めて、修正用のJavaScriptを送信します。設定により、常に現在の修正通知を公開することもできますが、スパム等を考えるとお薦めできません。もちろん、修正通知できるのは登録ユーザに限定することができますが、それも完全ではありません。登録したての悪しきユーザがアカウント停止まで不当な情報を書きなぐる可能性があります。この辺は通常のブログのコメントと同じような扱いになっています。

ページコメントパーツは、ページ内のDOMを解析し、どの要素にコメントを付けるか、選択できるようにします。また、単にコメントを送る以外に正誤表ツールがあります。例えばリンクエラーを見つけて、しかも正しいリンク先もわかる場合は、現在のリンク：http://hoge.page.com/goodpage/now/、正しいリンク：http://hoge.page.com/goodpage/new/　のようにできます。これにより、より簡潔に間違いを通知することができるわけです。また、静的なHMTLページの場合に限りますが、自動的に修正したファイルを出力することもできます。通知内容はAtomフィードで受け取ることも可能です。尚、動的なページや、ページの更新と重なった場合など、通知されたコメントの場所が見つけられない場合があります。

バージョン管理と開発者間のコラボレーション
http://www.netbeans.org/features/ide/collaboration_ja.html

要素：table["products-navig-table"]/tr[2]/div/div/a[2].href
現在のリンク：/features/java/swing.html
正しいリンク：/features/java/swing_ja.html
備考：ページ右メニューの『Swing GUIビルダー』

ページコメントサーバでは、サイトに付けられたコメントの管理やHTML変更イメージの作成、コメント者のアクセス管理やお礼の返信など、様々な機能が用意されています。


このエントリはフィクションです。

サービスメール

暫く忘却の彼方にいましたが、最近また新たなスパムメールに遭遇して、メールアドレスを登録毎に生成、管理するサービスを思い出しました。GMailやYahooメールあたりに入れてほしい機能です。ただフリーメールを受け付けないサービスも最近残っていて、それ様を考えると、プロバイダのメールアドレスにもあると嬉しい機能かもしれません。

サービスメールアドレスサービスは、何かにメールアドレスを登録するとき、メールのエイリアス（いまも使ってるのだろうか？）かリアルなメールアドレスを付与してくれるサービスで、サービス名やホームページのURLなど、あとで分かりやすい情報や日時等を管理してくれます。

メールアドレスは推測し難い、従って人には分かり辛いものが良いのではないかと思いますが、いずれにしても、安直に元のメールアドレスが推測できないことが重要です。

私は安価なレンタルサーバを借りていて、メールアドレス数に制限がありませんので、すぐにでも実現可能ですが、それを一々手で設定したんではたまりません。私の使っているレンタルサーバではコントロールパネルと称するアプリでいろいろ管理できるようになっているので、ここで行なうメールの管理の中に入れ込みたいところです。それが無理であれば、せめて外部からcgiベースで設定できるようにし、それを行なう各種登録メール管理アプリを作ることが必要でしょう。メールサーバを自分で立ててるような方は割と楽にできそう。メールサーバにアクセスする部分を抜きにして作っておけば、各自の事情に合わせて使えそうな気がします。

しかし、ユーザの使い勝手を考えれば、メールクライアントソフトで全て管理できるのが望ましいと思います。ということはThunderbirdを改造するとか。Gmailを例にとれば、ブラウザからもThunderbirdからも使えるので、そういう位置関係のアプリが望ましいですね。

シナリオ：

1. ユーザが会員登録などでメールアドレスを要求するサービスに遭遇。

2. そのウェブページのURLをキャプチャ。

3. Thunderbirdから新規サービスメール作成ボタンをクリック。

　設定ダイアログが表示。

　・サービスメールアドレス表示と、このメールアドレスのキャプチャボタン

　・URL入力欄

　・メモ入力欄

4. キャプチャしたURLをURL入力欄にペースト

　・メモ入力欄は何かあれば入力。

5. OKボタンをクリック。

6. メールサーバもしくはメールアドレス作成アプリと交信し実際のメールアドレスの作成（失敗する場合もあり）。

7. 成功すると自動的にサービスメールアドレスがクリップボードにキャプチャされる。

　・設定で手動にもできます。

8. メールアドレスを要求するサービスにキャプチャしたサービスメールアドレスをペースト

こんなところでしょうか。

ほんとはこういうのをWanted!したいのですが、めんどくさい今日この頃。ほら、「めんどう」ですら「めんど」になってる。

読み返して思ったのですが、Thunderbirdを改造するならFirefoxにもプラグインを作ってメールアドレスのところで「新規サービスメール」ってやると、ぜんぶ自動でやってくれて、

1. ユーザが会員登録などでメールアドレスを要求するサービスに遭遇。

2. 右クリックで「新規サービスメール」

以上。

のほうが良さげです。

SproutCore

今すぐにでも乗換えたいんだけど、どうしようかなあ。。。

２つのウィンドウ”だけ”を並べて表示

ウィンドウのペアモード。

たくさん開いていても、任意の２つをペアにして表示。

あとウィンドウ管理画面。

いっそウィンドウをレイヤで。

ということでウィンドウリストがレイヤ表示を兼ねていて（といってもここでの上下はあまり用途がない）使われないウィンドウほど下に行く。任意のウィンドウ（＝レイヤ）を統合すると、そのどれかを選ぶと全部先頭に来る。その統合ウィンドウ内で並べて表示などのファンクションが使える。

以上。ディスミスト。

openshowcase.netと広告の素敵な関係

CMをコンテンツとして挟むと単に消されるだけだと思うかもしれない。それはCMに価値がないから。ではCM自体に価値を入れれば良いのではないか。

あるコンテンツにCMキューブを挿み、それを表示するとパスワードが書いてあって、次のコンテンツの取得の際に手入力すると続きが見れる。迂回するのは簡単だがそれを難しくするような仕組みも何か作れると思う。

予め会員としてログインすると見れる。無料会員は広告を見なければならない。

広告を見るとポイントが貰える。

しかし、一番やりたいのはそのどれでもなく、CM自体を有益な情報にすること。有益な情報でないCMは残念ながら対象外となってしまうが。

購買意欲をそそるというのは、それが優れた商品であることを訴求するということ。ヘッドホンが欲しいとすでに思っている人には、新製品情報やレビュー、特価情報といった、役立つ情報を流せば良い。欲しいと思っているならお客さんのほうからチェックしてくれるはずだ。だがそれがググるという手間を今は介している。それもいい。それを否定する訳ではない。ただ補うのだ。PUSHっていうのは何も無いと何も得られない。当たり前すぎるが、貪欲な人には物足りない。何か分かったら教えてと言って１ヶ月でも待てる人と、言い終わるまで待てない人とがいる。そのどちらにも必要とされるだろう。待ってられないから他"も"探す人にとって、選択肢は多い程良い。自分で探すのが面倒な人は、待っていれば探してくれる。

そうした情報をインターネットにアクセスしたその日からすべて設定できる人などいないどころか、ほっといたら誰も使ってくれない。しかし一度目にすれば、あとは自動的にやってくれるのだから、これほど便利なことはない。しかも余計な情報から自分が振り分けを行なう必要がないので、ググった最初の１０行に入る必要は全くない。如何に有用な情報であるか、という、情報の真価が文字通り問われるのである。提供者には依然として、いやSEO対策より厳しい場合もあるだろうが、ユーザにとってはありがたい。

Open Showcaseってどっかに書いたっけ？

取りあえずopenshowcase.net取りました。

openshowcase.orgにしなかったのは、whois情報の設定が煩わしいというお恥ずかしい理由の他、openshowcaseサービスは、主にWebAPIにより使用されるディレクトリだからです。もちろんカスタマー用に検索、登録などの管理画面、情報作成アシスタンスプログラムなどを置く予定ですが、それはあくまで補助的なものです。

openshowcase.netはロゴを募集中です。

openshowcase.netは様々な情報をマッシュアップするためのディレクトリを目指しています。

openshowcase.netはある意味、エバンジェリストであり、他のサーバにこれが分散されることを望んでいます。DNSやオープンディレクトリの構造は詳しくありませんが、そういったものに近いものです。

openshowcase.netは実際のコンテンツは何もホストしません。一時的に登録ユーザの作成したプレビューは残るかもしれませんが、だとしても一時的なものです。

1=1という隙のない論理

何か読んでストレスが溜まったら、それを書いておくというのは一つの発散方法です。私なりのですが。

この素晴らしいサイトの素晴らしい文書を読んで、それはちょっと、大げさな言い回しじゃないかと思ったわけです。自分の思い通りにいかないことがあるとストレスがかかったり、欲求不満に陥ったりする、それは別に科学を持ち出すまでもなく、一般的な経験則で十分です。それが統計で裏打ちされた長年の研究により科学的に立証されているかどうかなんて、どうでもいいことです（もっとも経験則を真っ向から否定する立場なら別でしょうが）。

そしてUIについてですが、これもいわゆる「直感的インタフェース」ってことでしょう。そしてそれには答えがありません。何か違うことに慣れしまった人に、初めて使う、あるいは使い込んでいって感じる良さを理解するにはハンデがあります。髪を綺麗に染めるには、一度色を落とさなければならないのです。

つまり基準や対象をどこに置くかです。Windowsユーザのために、通常のウィンドウボタンをわざわざ消してMacOSXのアクア風の綺麗なボタンを後付けにして「どうですお客さん、綺麗でしょう？」などと言う人は、この際どうでもいいじゃないですか。

それより、初めてパソコンを使う人に取って、どちらがどう使いやすいのか。あるいはWindowsからMacへ移行するのと、MacからWindowsへ移行するのとでは、とちらが最終的に快適になれるか、を議論するなら、大いに価値があるでしょう。

デザインの善し悪しが、誰のためであるか、ということを抜きに一般化して「ユーザ」という言葉を使うのは、少々乱暴でしょう。ウィンドウ枠の善し悪しに明確な答えがありますか？　　をっと、MacOSはWindowsユーザが最初から幸せになるために作られてたのではないと思いますよ。

(素晴らしい文書より引用)

『ユーザインタフェースのデザインが良いというのは、そう振る舞うだろうとユーザが期待したようにプログラムが振る舞うことである。』

(引用おわり）

いいえ違います。

『ユーザインタフェースのデザインが良いというのは、そう振る舞うことをユーザが許せる範囲でプログラムが振る舞うことである。』

です。つまり、1=1、満足した人が使うUIは、その人に取っては良いものなのです。

ただし最良かどうかはわかりません。誰か別の人が、こうやったらどう？と改良したプログラムを持ってきたら、そっちのほうがいい！となるかもしれないのです。

でもMacOS（9までの方）で、ウィンドウに細い枠があったのは、まさに窓枠だったのかと、今更気がつきました。それでサイズ変更じゃなく移動なんだと。MacOS9は殆ど使うことなく、MacOSXからMacユーザを始めた私ですが、MacOSXには窓枠がありません。だからリサイズには右下をつままないといけない。正直これは最初不便でしたが、今は慣れたのでそれほどでもないかな。

そしてMacOSXとMacBook ProやiMacとワイヤレスキーボード＆マウスに慣れ親しんだ元Windowsユーザは、今はMacが大好きです。そう、恐らく直感的か否かより、好きになれるかどうか、のほうが重要で、愛は苦難を乗り越えるものなのです。Fog Creekのカスタマーがそうであるように。

『ユーザインタフェースのデザインが良いというのは、そうあることを理屈抜きでユーザが気に入ることである。』

Ruby on Rails でMySQL AdministratorのWeb版を作るには

動的にスキーマやテーブルを作らなければならないわけですが、それってSQLを直接書く、でいいんでしょうか？　それともActiveRecordに動的にサブクラスを追加したり、メソッド類を追加したりするのでしょうか。ご教授頂ければ有り難いです。無論リソースのご紹介も大歓迎です。

ペアプロ・ザ・ウェブ

小野さんという方のペアプログラミングについてのブログを拝見しました。

たしかに。実際、なぜこのペアプロにたどり着いたかと言えば、RoRで動的にテーブルを作るにはどうしたらいいか、つまり、MySQL AdministratorみたいなGUIアプリケーションのWebバージョンを（RoR）で作るにはどうしたらいいか、を漁っていて、でした。どこからともなくhttp://www.mamezou.net/mamenight/documents/mamenight024/mame_rails_xpjug.pdfというデータに行き着き、そのスライドにあったXPJUGをググって、やっぱりエクストリーム系か、と思ったところでペアプロが頭に浮かんで、ウェブ上でペアプロってどうなんてるんだろう？ということで目にしたわけです。

特にプレッシャーを利用するという点、非常に分かる気がします。なので勢いペアプログラミングしたくなりましたが、今思い出しましたが、実は過去に何度となくペアプログラミングってしてきてるんですよね。もちろん「ペアプロやりまーす」と宣言してやるわけではなく、極自然に。制御系って実機がないとデバッグできなかったりするわけですが、私はICEを使えない環境でROM焼きした経験からか、まず机上で解決しようとするわけです。逆にとりあえずステップ実行して、わけもわからずprint文を入れたら動きました、というのはなかなか受け入れられないわけです（気持ちはわかりますよ）。そんなとき、岡目八目がよく効きます。でもこれは立場の強さ（私が上）というプレッシャーも重要で、さもなくば相手の目を誤摩化して、その場をやり過ごそうとしたりするから困ったものです。XP流のペアプロの場合、二人の力関係と誠実さの問題をどう解決しているでしょうか。

それと、見られたい願望についてですが、私のように願望がマイナスなプログラミングが嫌いな人間には、どう作用するのでしょうか。しかもアジャイルが大の苦手ときている私には。。

実際これだけオープンソース全盛の時代にあっても、自分に直接関係ないコードを見たい人っていうのは、どれだけいるのかという問題もあります。有名なオープンソース（例えばLAMP）ならいざ知らず、私の書いたどうってことないプログラムに、誰も関心は持たないでしょう。

考えていてもしょうがないので、ウェブでやるなら、リアルタイムとそうじゃないのと２通りあると思うのですが、特にリアルタイムじゃないほうが面白そう。これはペアプロとは呼べないかもしれませんが、ウェブならではの面白さが隠れてそうな気がします。そのための積極的なツールは見当たらないので、レイヤをサポートしたコードビューに、コードそのものと、コードに対するコメントやこうした方がいいんじゃない？コードを書けたり、逆に誰かに書いてほしいコードに関する説明を先に書いておけるとか、そういうペアというよりいわゆるコラボなツール。Project Kenaiのような新しめのコードホストにぜひ取り入れてほしいです。

まあ...自分でやりますか。

良いわがまま

例えばある言語で誰かが使っていない変数やメソッドに小さいアイコン（黄色いビックリマークとか）を表示して欲しいと思ったとします。でも評価するタイミングの問題もあって、使うまで常に表示されてしまうのが気に入らないと思う人もいるでしょう。スペルチェックみたいな感じでプリビルド的に走って欲しいとか。

そういう「わがままさ」が肝です。

使っているか否かという判定は言語処理系が担当し、表示系がユーザの望むタイミングで取得してコードビューに反映とすると、処理系にもっと静的解析系の機能を入れる必要があります。なぜならもちろん現状のツールのように、ツール自身で翻訳系の処理を行なうことも出来ますが、それは無駄以上に整合性の問題があるからです。

ところが処理系自体に手を入れられないとそうも言ってられません。かといって処理系自体を作るかと言えばコード解析にバックエンドは（全ては）必要ない。であればコード解析に必要な部分だけ新規に作るか、オープンソース系であれば言語処理系を改造するかになります。いずれにしても結局は整合性がないコード解析ツールになっていきます。

そうならないためには、突き詰めれば、異なるアプリケーションのコードをどこまで共有できるかということであると同時に、どこまで細かい単位で共有できるか。それが、気に入る気に入らないを左右する問題と、整合性とを、同時に解決することになるのです。

もちろんコードのリポジトリは膨大になるかもしれません。ですがまあ、そんなこと気にしないで、どこまでやったらどうなるのか、見てみることにしましょう。これは概念交換機よりもっと古くて基本的な考えですが、いつか何とかしたいですね。

WebArchive Extractor

FirefoxでWebページを別名で保存すると、表示に必要なファイルをまとめて保存してくれるのはとても嬉しいのですが、Finderで表示したとき、アプリケーションの「パッケージの内容を表示」みたいに(Finder自身で)展開してくれてもいいのに、と思うのは私だけでしょうか。

みんなどうしてるんだろうということでググりました、ありました。ずばり、WebArchive Extractor.

１つの

いまのところ全てのアラートをthunderbirdにまとめるというのがベスト。といってもthunderbirdというのはメタファに過ぎません。代表アラートシンボルは１つでよく、アプリケーションも１つでいい、という話です。

あ、これは今書きながら思いついたことですが、アプリケーションが１つでいい、というのは（自分の中では）新しい！　いままでコンピュータが１つになるという方向でモノを考えていましたが、アプリケーションが１つになるという考えの方が上手く行きそうです。概念交換機には、まさにうってつけです。

tablesorter

テーブルをJQueryを使って簡単に表示できるんじゃないかなと思ったら案の定、tablesorterとflexiGridが見つかりました。どちらもJQueryのプラグイン（JQueryに明確な”プラグイン”という基準や仕様があるかは分かりません）。まずはソートができてページネーション機能まで付いているtablesorterから行ってみたいと思います。

ところで、気がつけばGoogleドキュメントのガジェットが充実の一途（ろくに見てないで適当なこと言ってます）。こうしたガジェットをGoogle以外で使えるのかどうかわかりませんが、いずれにせよJavaScriptやFlashなどにより、小技の効いたアプリを簡単に作れるようになって来ているというのは本当に素晴らしいことです。

いずれオープンなショーケースとなるのはもはや時間の問題。在り方が問われます。結果を見てみましょう。

見たいんだけど見れない。でもRSSじゃないし。

気になるサイトも重たいと足が遠のく。そこでバックグラウンドでサイトにアクセスしスループットをスタッツするウィジェット。スループットの測定であることをサイト側で分かるようID（ブラウザ種別を修飾するとか）をつける。

似て非なるもの

メニューじゃなくて右メニュー。