2009年2月28日土曜日

対決シリーズ

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

名前対決〜JRA登録馬編

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


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


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

2009年2月27日金曜日

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

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 交換を行なう必要があると思います。そもそもコンボボックスかどうかはモデルには関係ない話で、関係させてはいけない、というのが常識だと思います。

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

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

コロンブス的に言えば、みんな1つの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か何かで定義されていたと思います(間違ってたらごめんなさい)。

2009年2月26日木曜日

アラートをブログでも

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

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

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

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


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

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

2009年2月24日火曜日

ページコメントパーツ

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

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

例えばいつも大変お世話になっている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変更イメージの作成、コメント者のアクセス管理やお礼の返信など、様々な機能が用意されています。


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

2009年2月19日木曜日

サービスメール

暫く忘却の彼方にいましたが、最近また新たなスパムメールに遭遇して、メールアドレスを登録毎に生成、管理するサービスを思い出しました。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

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