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

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

似て非なるもの

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

たためる（閉じれる）広告 USTREAM

USTREAMがやってくれました。

ついさっきまではなかったので、本当に今さっき追加されたのではないかと思います。もしくは偶々実験中だったのかもしれません（実際に広告をクリックしてもサイトが表示されなかったので）。

私もMashupEXで取り入れようとしていた『閉じれる広告』。先を越されてしまった。とはいえ、ストリーム上の広告の話で、閉じたら[+ad]が残るとか、他の広告は少なくともまだ従来通りのようですし、私のやり方と同じという訳ではないようです。それに私の場合はもっと広告を主体に考えているので、広告専門サイトと連携するような格好で実現したいと思っています（とあくまで自分とは違う点を強調したがる悪しき性）。

ところで広告専門サイトって、ないんですよね。見つからないだけなような気がしますが。もし本当になければ、立ち上げましょう！　ええ立ち上げますとも。

RoRアプリケーションの配備 (2)

ちょっとエントリーの順番が前後しちゃいましたが、最近デプロイの話を聞いてから、Netbeansを使っていることもあり、ついついJRubyやGlassFishに頭が向いてしまいます。ネイティブRubyをGlassFish V3で動かす記事もあるので、やってみたいのはやまやま、ついそっちを除いてしまうのは分かるんですが、ぐっとこらえて、まずはローカルで動くようにしましょう。

モデルの作成

データベースの格好は何となくまとまってきました。さてそこでモデルですが、考えてみると、adminやstoreというモデルの単位がはっきりしない頭。まあ、深く考えずにいきましょう。

jester

ここ。

JavaScriptでサーバサイドのDBをRESTで扱うためのライブラリ、かな？

yahoo!ニューストピックスAPIのレスポンスのスキーマをどう扱えば良いかという問題で、rubyで探していたが、ふとJavaScriptで出来ればブラウザだけでできるじゃないかということに気づいたかどうかは知らないが、JavaScriptでRESTのXMLを扱うライブラリを探していたらJesterがそれとなく出てきた。良さそうな代物に見えるけど、大々的にググられるわけじゃない辺りがどうなの？

ところで肝心なこのニュースのレスポンスには対応するXMLSchemaが定義されて公開されているが、実際のデータ（レスポンス）をこのスキーマで検証する方法は？　ということで、こちらをこれから拝見しようかと思っているところ。

つづく。

railsでリレーション

ファミリテーブルはディレクトリと本体に分かれる。ノードのオバケだ。だからこそ自分でリストDBを（最終的には）作るわけだけど、RDBで別に王道を行くつもりはないので、まずできるところから。

ググ（Rails　テーブル　リレーション ）ってみるとこんなきれいなページが検索トップに。これからみるところでブックマーク代わりに。

って読みながら「なるほどx２と」マーカーしたりコメントつけたりしたい訳ですが、はて？FireFoxのプラグイン？どっかで見たような気が。

そういうのいちいち探すとめんどくさいので、サイトに１行JSを追加するだけで、できるといいのにね。そしたらブログのデフォルトONにしておけば、流行ると思うね。できると思うし。DOM見てツリーのパスとカーソル位置ってわかるのか？でもクリップしてるんだからね、きっと何か方法あるんだよ。ブロガさん側もどこが注目されたか詳細にわかってよろしい。問題は保存場所だな。サーバに置きたくないなあ。本文はローカル（cookieか保存ファイルを指定）、ポイント(URI---これってカーソル位置まで指定できるんだっけ？　でも出来なかったらURIじゃないんじゃないの？)はサーバに。しょうがないか。まいいや、この話はまた今度。

ウェブなのにチェーン店

ウェブ上にチェーン店やフランチャイズを持つというのはどうなんだろう。

一見、ウェブは繋がってるんだから１個だろう、と思うのは正しいでしょう。でもそこを何とか、複数の店舗に分けるんですよ。

どう分けるかという問題もありますが、とりあえず普通に地理的に分けてみましょう。で、やはり普通に店長もしくはオーナの所在地別に分けます。そうすると、お店のブログは当然地域密着型にしやすい。場合によっては商品の在庫をその地で持ったり、リアルなデモ店舗をもったり、地域とマッシュアップしたり、交流を図ることができるような気がします。

例えばMashupEX山中湖支店というのがあれば、山中湖に関係あるサイトという認識をされるでしょうし、実際、山中湖の観光とマッシュアップしたり、日々の山中湖の写真や動画が配信されれば、そのサーバが実際にはパリにあったとしてもいいわけです。

P46 ulタグ

リスト表示にULタグを使うとよいでしょうという教えを読んでULタグをググってみると（そう私はHTMLのタグさえろくに知らない）OLタグも気軽に便利でいいね。こういうのがなぜオブジェクトになってないんだろう。HTMLもろくに知らないヤツはそう思います。

MashupEXのプロファイルにもULやOLで実装するリストがあってもいいよね。

Rubyがなぜ読みやすい？

# はコメントなのか？違うのか？　わかりずらい。

読みやすいって言う基準は何？

結局正規表現とかシェルのパイプで繋ぎまくったスクリプトが読みやすい、つまり書き方が分かっていれば簡潔、っていう読みやすさだと思う。だって全然読めないじゃん。パラメータ受けてないのに、書いてないときは呼び元で指定？？　じゃ何が来るか分かんないじゃん。でもコレとかアレが来る前提で書くわけでしょ？　故に読みやすいと。いや〜絶対くじけると思う。そもそも出来るだけ冗長に書こうとする人間には無理。

例えば、

a[1] ||= 1

a[1]がnilでなければ1が代入される。理屈はそうなんでしょうね。でもこれを見て、直感的にそうだと分かる人がどれだけいるんだろう。簡潔と短いは同じじゃないはず。知ってる人にしか分からない。それは言語ですからね。でも同じ言語の中で、一つの文法にそってない。

http://www.ruby-lang.org/ja/man/html/_B1E9BBBBBBD2BCB0.html

によると、まず文法として、

式１ op= 式２

という形、つまりa[1] += 1、a[1] |= 1、a[1] ||= 1などがある。

ところが、opが、&&、||の場合とそれ以外の場合は意味が異なる。

opが、&&、||以外の場合は、

式1 = 式1 op 式2

&&、||の場合は、

式1 op ( 式1 = 式2 ）となる。

つまり、||の場合は式1から評価するため、式1がtrueだと（式1 = 式2 ）は評価されないことによるわけだ。しかし計算上、式1がtrueなら（式1 = 式2 )は評価されないということを意識するというのは、読みやすいということになるのだろうか。

a || b

と書いたとき、次の２つの文を比べてみよう。

(1)『ａかbの「どっちかが」trueならtrue、それ以外はfalse』

(2)『まずａを先に判断して、aがtrueだったら、true、falseだったら次にbを判断して、trueだったらtrue、そうじゃなかったらfalse。』

どちらがより一般的な考え方なのか。それが読みやすさに繋がる意識の源ではないかと私は思う。というかそれが私。

私は「英語のように書ける」という説明を読んでこう思いました。私自身の英語力の問題はさておき、自然言語とコードが一致する、と。それは私向きに違いないと。何故かと言えば、私は例えば仕様書を日本語で書いたようなコードを書こうとするから。だから１行しかない関数が山のようにあったり、C言語なのに、値を返すだけの関数があったり。それはできるだけ思ったまま書きたいから。コンピュータのためのコード編集はその後やればいい。そうすればどうしたい（実際にした）けどペンティアムのためにこうしようという履歴が明確になって、意識とコードがずれない。

rubyには他にもProc.newのパラメータが呼び元で指定するとか、短く書きたいがためにハッシュの{}を省略するほうが美しいとか、とにかく意識とのギャップがそこここに散らばってる気がする。それが自分の意識の中で普通になれば、短い分読みやすくなる（速く読める）のかも。事実、Rubyの代表作であるRoRのプログラムが、その賞讃とは裏腹に読み難いという、何とも皮肉な評価を目にする。オブジェクト指向は外から使い安くする分、中身が苦労してるというのは最もな話。でもそれは読みやすさとは関係ない。RoRが読み難いならRubyで書いたプログラムは読み難いと思って、なぜ間違いなのだろうか。

evalはどうだろう？　まだ簡単な例しか見てないけど、読みやすいのだろうか？　HTMLやXMLを出力するのは良く分かるけど、同じ要領でclassを出力するのはねえ。何となくテーブルをオブジェクトにするには、それも有りなのかもしれない気はしてるけど。

余りにも遠い道のり。このままではダメだ。

ここは一つ、劇的な割り切りとすっ飛ばし！が必要だな。

ということで、１０日でおぼえる本に戻ろう。

そして軽く一本書き上げよう。

俺だけが分からず屋で、Rubyが読み難かったり書き難かったりしても、いいかしら？byミシェルじゃない、いいんだよ。

私が書くもの

今まで中々理解出来なかったのが、JSPにしろRoRにしろ、なぜ独自構文（と言っては語弊があるかもしれません）を使わずに、HTMLに埋め込む形 （%,%=など）を取るのかということ。

もちろん、ページをHTMLで表現しているから、というのは分かりますよ。そうではなく、どうせプログラムを介して動的にHTMLを出力するのだから、もっとドラスティックに、例えばもっとページオブジェクトのコレクションのような、プログラム寄りな構造を取っても良いのではないか、という思いがあって、HTMLに埋め込むという考え方は、受け入れ難いものがあるわけです。

RoRを使う上で、ERbは避けて通れませんし、秀逸なプラグインを使わせて頂く上でも、郷に従う必要があります。しかしまだ自分の書くプログラムがRoRを出力するという手があります。HTMLが吐けるなら、RoRを吐けない理由はありません。

計画の確認

しかしここに来てぶれが激しく、何度も同じことを自分に言い聞かせてようやく納得しつつあるので、ここでダメを押すべく記録しておきます。

当初、普通にruby on rails + MySQL（などのRDBMS）という構成を一次として考えていましたが、データ構成を普通に考えると、既存のRDBでは微妙な感じというか、無理がある（素直じゃない）。

では本来の目的であるDBを先に作るかという話が蒸し返されるわけですが、それならRubyよりJavaでと思うわけです。で悩むと。

そもそもなぜRubyかというとRuby on Railsだからであり、なぜRuby on Railsかといえば、１０分でウェブアプリが作れるからだったのですが、実はそれは私以外の人のことだったということが分かり、本来であれば、Ruby on Railsに拘る必要は無くなったわけです。

ところが、とあるセミナーでRoRで実践開発されている方、しかもそれまではJava+Struts等で構築されてきた方が、今後はもう全部RoRで行く、というお話を伺って、じゃあ、自分もがんばって最後までRoRでMashupEXを完成させようと思った、思ってしまったことが、今はRoRに拘る理由の１つです。

それに苦労してRoRで曲がりなりにもアプリケーションを書き上げられれば、少なくとも自分目線でのチュートリアレットを書けるわけですから、苦労が無に帰すことは有り得ません。

問題はDBか。DBは作るかなRubyで。

その後、反省を踏まえて、オールJavaでClock!から書き上げると。

MashupEX 〜 Mashup Awards 4

いよいよ今週末（2008/10/19日曜日）に表彰式が行われる『Mashup Awards 4』

残念ながらエントリーはさせて頂いたものの、力及ばず、いや、全く及ばす、未だ完成に至っておりません。それどころか、Ruby on Railsの習得もままならない状況。お恥ずかしい限りです。

さて、言い訳したところで恥の上塗り、その辺りの苦労話はモノが出来て時間的余裕ができたら白状していきたいと思います。今後は来月中旬完成を目指し、最低限エントリー作品の完成にはここぎつけたいと思っておりますが、ここにそのサイトのあらましを記しておきたいと思います。

サービス名；MashupEX（マッシュアップエックス、またはマッシュアップイーエックス）
URL：www.mashupex.com
概要：各社ご提供WebAPIを気軽にお試し。取得情報を地図や表に表示。

MashupEXはEx〜のためのウェブアプリケーションです。Ex*な言葉にはExperience(体感),Exploreing(探索),Exchange(交換),Exclusive(じぶんだけの）,Extension(拡張)など、Mashupを通じて得られる新しい何かを表すものがたくさんあります。

「このあいださ〜、あたし〜、なんか〜、%'$`$#0)!のアッピー(apiのこと？)を〜、"#)$0(とイクスチェンジして〜、あと%8(#$)でプチエクステ？しちゃったんだけど〜、それって結局エクスクルーシブじゃん？ロングテール的には〜」

みたいな光景が代官山界隈で普通になるよう、What's EX? ( ワッッツエッックス、ハァン？）としてAtom（アトム）でPushしていきたいと思ってます。

なぜ代官山かというと、このプロジェクトの拠点があるから。代官山を大マッシュアップタウン、マッシュアップのメッカにするのが私の次なる野望です（もちろんジョーダンです）。

MashupEXって一体、どんなサービスなの？ ね？ ねぇ？ ねぇえ？ by ミシェル

昨今のWebAPIは非常に優れたRESTfulな使い勝手の良い秀逸なサービスが多いのはご存知の通りです。でも例えばXMLで返ってくるものをそのままブラウザで見ても、あんまり見やすくない。そこでこれを地図や表にしてもう少し見やすくすることで、手軽に、あ〜なるほど的にWebAPIを理解できるようにしようというサービスです。

もちろん秀逸なMashupアプリケーションには、地図だ表だなんて全然関係ない、私なんかが思いもつかない、ユニークなものが沢山あると思います。ですから将来的にはあらゆるインフォグラフを取り込んでいけたら、とても贅沢なことだと思います。

それともう一つ、Mashupですから、複数のサービスとの重ね合わせや絡み合いが大事というか絶対条件だと思いますので、それがお手軽にできるようにしたいですね。色んな情報を重ねて表示したり、最初に得た情報から次の情報を引くとか、そういった「組み合わせ」を簡単にできるようにすることが、サービスにハーモニーや奥行きを生んで、人をワクワクさせたり楽しくさせたりすると思うんです。そしてきっと自分だけの発見も生まれるはず。

それってpopflyでいいんじゃない？とかそっちのほうが圧倒的にかっこいじゃん、と思ったあなたはまったく正しい、その通りだと思います。まあ私自身popflyを使ったことがあるわけじゃなく、いろんなレビューを見た感想でしかないのですが(safariでいくとサインアップに失敗する)、あれはおそらく凄いと思います。じゃあなんで？

それは、私の作品として、独自のテーマがあるからです。その中でも今回MashupEXとして表現したいのが「自分が扱いやすいレベルでの抽象概念で表現する」ということ。

例えばIntegerという型は非常に抽象的なわけです。クラス的にはここから何かの番号やID、日付、順位など、より具体的に表現することができます。具体的になれば、その情報の意味が理解しやすくなります。しかし一方で、都道府県IDのようなローカルルールに基づく具体化よりは、都道府県名のほうが分かりやすいでしょう。しかし、都道府県名で処理しようとすると、それはひらがななのか、漢字なのか、データ上のエンコーディングはどうなるのかといった、実装上の問題、つまりコンピュータ的にどうなのよ？ということになってきます。ですから通常は

都道府県を番号で表現してますといった注釈とともに、数字でコンピューティングするのが一般的なわけです（無論私見ですが）。

つまり、コンピューティングにおける概念には、人の解釈とコンピュータへの実装との分岐点があるわけです。さらに言えば、人と人の間にも隔たりがある場合があるでしょう。

これを私の主観による概念で処理し、さらに各ユーザ毎の主観で処理し、その中の共通性で処理する、それが「自分が扱いやすいレベルでの抽象概念で表現する」ということなのです。

まあ、こんな抽象的な話をつたない文章力で図解もなく書き綴ったところでどうにもなりません。とにかく早く実装して、一人でも多くの方に使って頂けるようにしたいと思っております。そしてWhat's EXに「食べログで行く、香港２泊３日食べ歩き。〜セレブ編〜」と入れたいですね。

※香港現地の情報は今日現在食べログさんには載っていないようです。

※本当にこれを載せるとしたら、内容的には「香港に行ったつもりで、チャイニーズ三昧」とか「香港で出会った日本の隠れた名店探しの旅」かな。

それともう一つ、オープンソースにすること。一口にオープンソースといっても、よく見るとライセンスが色々あって、JavaScriptを多用することを考えるとどこまで可能なのか、現時点では分かっていません。しかしMashupEXとして私が作成したソースはすべて公開する予定です。それはMashupEXだけではなく、Cafe2.0 CONCEPTO Oliva プロジェクトの基本です。

さて、当面の目標ですが、

1.1. Yahoo! JAPAN様の地図を使えるようにする。

1.2 手頃なリスト（リストビューやテーブル）表示ができるようにする。
1.2. RESTfulなWebAPIを使えるようにする（初版は埋め込み）。
1.3. 抽象概念をファミリとして使えるようにする（初版は埋め込み）。
1.4. 各種データをプロファイルという形で統一的使えるようにする（初版は埋め込み）。
1.5. WebAPIの各パラメータをファミリ化する（初版は埋め込み）。

おっと大事なことを忘れてました。進捗報告を行うためにも、

1.0 What's EXをAtom(RSS)で配信できるようにする。

を追加します。

リストについてはこういうのが欲しいというのがあるのですが、それが出回って無ければ何とか自分で作りたいと思っています。

ここまでできたら自分のイメージとWebアプリケーションとしての実装上のギャップがよくわかってくると思うので、それ以降はまた検討しなおしますが、現状は次のように思っています。

2.1. 埋め込みだったものを登録して使えるようにする。
2.2 複数のAPI呼び出しを保存できるようにし、後で呼び出して使えるようにする。
2.3 複数のAPI呼び出しを重ねて（マージして）表示できるようにする。
2.4 APIの呼び出し結果を元に、次のAPIの呼び出しができるようにする。
2.5 JavaScriptを駆使したAPIに対応する。

ができたら、

3.1 JavaScriptを駆使したAPIを登録して使えるようにする。

4.1 CSSを登録して使えるようにする。

5.1 カレンダーにポーティング

5.2 ブログにポーティング

5.3 SNSにポーティング

その他、ユーザ管理（ログイン）とか、ファイルに保存とか、サーバに保存といったオプション的な機能も、行き当たりばったりで追加していきたいと思います。