« 2005年11月 | メイン | 2006年01月 »
2005年12月22日
18日間更新をお休みします
やはり休暇の告知には犬の写真を貼るのが流儀か(謎)、犬飼ってないけど。(写真は GFDL )
今年は祝日の配置がいい感じなので、有給追加して明日から 18 連休にした。「社員ブログ」だし、休暇中は当ブログの更新もお休みということで。
ネットから離れて Bloglines や del.icio.us も封印したいところだが、ネット中毒なのでそこまではできそうにない。でもまあ、まとまった時間をいつもと違うことに使うのは大事な気がするので、この休暇ではじっくり何かに取り組んでみたいと思っている。
以下は、僕の知り合い向けへの個人的な連絡:
アメリカから日本に帰ってきた時すら誰にも連絡しませんでした。いろんな人に不義理をしております。
ですが、どこかから見つけてきてこのブログを読んでいただいているとしたら、秋元は今年も一年息災でした、とこの場を借りてお伝えさせてください。地元の同級生達、学校の仲間達、前職での同僚、社外勉強会での知人、それ以外の友達、みなさんの 2005 年が実り多き年であられましたように。
たとえ十年会ってなくてもみなさんは僕にとって大切な友人です。もう年賀状をやめて15年ぐらい経ちますので、今年も年賀状は出しませんが、何か相談があればいつでも遠慮なく連絡ください、また特に用が無いけど会おうと言っていただけるのも、こんなに嬉しいことはありません。
ではみなさま、メリークリスマス、ハッピーハヌカー、クワンザー、whatever、よいお年を。
投稿者 秋元 : 17:08 | コメント (3) | トラックバック
2005年 技術ポッドキャスト ベスト10
The 10 Best Tech Podcasts of 2005 だそうな。
あとで聴く。こんなにいろいろ面白そうなトークが公開されているとは。
やっぱ音楽聴く生活に戻ろうか。押入れにMPMAN F60 があるけどこれじゃもうキツイなあ。なんか携帯プレイヤー買うか。。。
Ajax ジェスチャー認証
via Ajaxian
ジェスチャーによる認証のアイデア自体はそれほど新しいものではないと思うが、Ajax でジェスチャー認証はけっこう面白いのではないか。
デモの使い方を説明する。
文中中央下の二つのボックス、左の "Record" ボックス内でマウス左ボタンを押しながら、自分のジェスチャーを記憶させる。
続いて、右の "Login" ボックスでマウス左ボタンを押しながら、自分のジェスチャーを伝える。
右で入力したジェスチャーが、左で保存していたジェスチャーと合致したら、ログイン成功となる。何回かやってみたが、それなりに似たジェスチャーを再現しないとログイン成功にはならない。
マウスで描いた軌跡で認証、というのは、サインの国の人らしい発想ではあると思った。
Ajaxian では、他にも同じブログから、写真に写された「概念」をヒントにクリックさせることでスパムロボットを振り落とすアイデアも紹介されている。
2005年12月21日
広告収入を再分配する検索サービス Gravee
via TechCrunch
Google から遮断された kozoru の話を書いたばかりだが、同じく Google 等大手検索サービスの結果を再利用している新サービス Gravee のベータ版が登場している。
- Gravee の検索結果に出てくる広告がクリックされたら、その収入の最大 70% が、検索結果 1~10 位のサイトのオーナーに支払われる。
- 自分のサイトに Gravee の検索ボックスを張り、そこからのアクセス経由で広告がクリックされれば報酬(全広告収入の 35 %)が支払われる
Gravee からの広告収入の分け前を受け取るには、サイトの持ち主として登録しないといけない。もちろん、サイトの持ち主であることを証明するような仕組み(technoati の profile で使われているようなものかもしれない)が用意されているだろう。
参加者と広告収入を分かち合うことで、利用者を増やそうということで、アイデアは面白いと思う。これが本当に当たるなら、Google や Yahoo が同じことをしてくるかもしれないが、それはそれでサイト運営者には損が無い。
これなんか、Google 等の検索結果にタダ乗りした上で、自分の広告に差し替えるということでは kozoru と同じ程度に危ないサービスのように思うのだが。
検索結果は誰のものか
kozoru という検索エンジンベンチャーがある。一年以上前からあり、けっこうな資金を集めているが、その「画期的なサーチエンジン」は一般公開されていない。
漏れ聞こえてくるところでは、Google や Yahoo などの検索結果を再利用して、より賢い、少数に絞った結果を返してくれる検索サービスだという。
この kozoru の創業者が、ちょっと前に Google などの大手検索サービス会社を相手に kozoru サービスのデモをし、Google とその後何度か話し合いをしたが、ある日ぷっつり連絡が来なくなった、電話をかけてもメールしても相手が捕まらない、といった顛末をブログに書き、そのこともいくつかのブログで取り上げられていた。
kozoru という名前自体が日本語から取られているらしいとか、創業者のブログ名が「THE LONE RONIN(孤高の浪人)」だったり、親日派なんだろうかというのは余談。
今回のブログでは、Google が kozoru からのアクセスを遮断した、と書かれている。他にもたくさん Google の検索結果を再利用しているサービスがあるのに、とも。
ブログへのコメントでは、「しかたないね。Alexa の新 API 使うんだね」みたいな反応が多い。まあ、お金を払って保証されたサービスを使うというのはやり方として正しいので、それはそれで正論だが。
Google が、ウェブ検索や Google News などの結果の再利用に対して、アクセス数が多いと制限をかけたりするのはよくあること。サーバリソースの問題もあるので、誰かがプログラムで短時間に大量取得しようとするなら、それを止めるのは仕方がない。しかし kozoru のサービスは公開すらされてない。Google の面子の前でデモしただけだ。
しかし、もしアクセス遮断の理由が「うちよりよい結果を出すから」とか「検索結果は Google の財産だから」ということだと、なんとなくしっくりこないところはある。というのも、検索やニュース検索の結果自体は、Google で作ったものではなく他から集めてきたものだからだ。情報の再利用で飯を食ってる Google が、自分のところの再利用は制限する、という形になる。
もちろん、関連性の高いものをスパム等を排除して並べることには多大な努力が払われているし、単なる Google のコピーサイトを作るような相手なら遮断していいだろう。今回もそういう風に判断したのかもしれない。まったく返答が無いということなら理由もわからないだろうが。
kozoru の創業者が書いたように、Google の結果を使っているサービスなんていくらでもあるが、協力的な相手とそうでない相手でデータの提供方針を変えてこられるとしたら、ちょっと嫌な感じだ。
# kozoru のほうが怪しいベーパーウェア企業で、注目を惹くためにこの騒動を起こしてるってことはあるのかなあ。
投稿者 秋元 : 17:47 | コメント (4) | トラックバック
2005年12月20日
あなたの企業、URL で損していませんか (2) www を揃える理由
前回のコラムでは、“www.”のつく URL、つかない URL の実例を挙げて、“www.”があってもなくても Web サイトに辿り着けるようにすることの重要性を書いた。
今回は、“www.”の有無に関わらず企業サイトにアクセスできるようにする方法の比較と、その効用について説明しよう。
前回あげた4つのタイプの企業 URL から、“www.”があってもなくてもアクセスできる大手サイトの例として、（3）、（4）を再掲する。
（3）どちらでも接続できる Web サイト
| Yahoo! Japan | http://www.yahoo.co.jp/ | http://yahoo.co.jp/ |
| ライブドア | http://www.livedoor.com/ | http://livedoor.com/ |
（4）どちらでも接続でき、どちらか一方に転送される Web サイト
| 楽天 | http://www.rakuten.co.jp/ |
| Mixi | http://mixi.jp/ |
ブラウザから入力して、その企業サイト/サービスに行くことができる、という意味では、（3）と（4）にはまったく違いがない。しかし、（3）のタイプの設定をしている URL では、潜在的な顧客を取りこぼしている可能性があるのだ。
■ SEO（検索エンジン最適化）に関する逸失利益
検索エンジンで上位に表示されるための要素の一つに、被リンクの数や質がある。非常に簡略化して言うと、人気投票的に「たくさんの人（他のサイト）からリンクが張られているサイトは良いサイト」というものだ。
この場合に、上記の（3）のケースが思わぬ差を産む。あるサイトからは http://www.example.co.jp/（www.つき）に、他のサイトからは http://example.co.jp/（www.なし）にリンクされていたとすると、検索エンジンによってはこの二つを別々に集計してしまうことがあるのだ。
あるドメインへリンクしているページを検索する方法があるので、この二つの差を見てみよう。
Google で調べた www.yahoo.co.jp へのリンク 59万3,000件
Google で調べた yahoo.co.jp へのリンク 1,770件
この通り、見つかったページ数から、Google の場合は“www.”ありとなしが別々にカウントされていることがわかる。検索エンジンによっては、このように“www.”つきとなしの二つを別のサイトとして認識してしまうことがある。
この例では“www.”なしの件数は非常に小さいが、この数が伯仲しているようなケースがあれば、せっかく張られた100のリンクの SEO 効果が、たとえば60程度に落ちてしまっている、つまり、検索結果の順位を損している可能性が高い。
■ ネット上のクチコミサービスに関する逸失利益
はてなブックマーク という共有ブックマークサービス（ソーシャルブックマークサービス）がある。ここでは、ブラウザのお気に入りとは違い、より多くの人が登録したサイトが「人気サイト」や「注目サイト」として目立つような仕組みがあり、その結果を参考に、ある企業サイトの評判や企業の知名度を判断する人もいる。
このはてなブックマークで、http://www.yahoo.co.jp/ をブックマークしている人 は288人なのに対して、http://yahoo.co.jp/ をブックマークしている人 は20人である。
http://www.rakuten.co.jp/ をブックマークしている人 は55人なのに対して、http://rakuten.co.jp/ をブックマークしている人 はいない。
つまり、タイプ（4）の URL を持つ楽天は、注目してくれた55人全員を一つのブックマークに集めることができているのに対して、タイプ（3）の Yahoo！Japan のほうは、本当は308人が注目しているのに、20人分の注目度が別にそれてしまっているということだ。
この二つでは、ブックマークしている人の数自体に差があるが、もし興味を持っている人の数が同じ、たとえば100名だったとして、100個のブックマーク一つがついている企業サイトと、30個のブックマークがついている（あと70個は URL の違いで存在に気づかない）企業サイト、ユーザはどちらが人気のある企業だと判断するだろうか？
結論として、「“www.”があってもなくてもユーザーが辿り着けるようにする」、という前回の工夫に加えて、「“www.”があってもなくても結果的に同じ URL となるように誘導する」ことが、よりよい Web サイト集客のために重要である。
「同じ内容を返す URL は常に一つ」という概念のことを“Permalink”といい、今回例にあげた SEO や共有ブックマークに限らず、Web における重要な概念の一つとなっている。“Permalink”関連で注意すべき他の事例については次回に説明させていただく。
注：記事中の検索結果数やブックマーク数は、2005/11/30時点のもの
投稿者 秋元 : 10:15 | コメント (2) | トラックバック
2005年12月19日
Bloglines の停止予定 in 日本時間
del.icio.us といい Bloglines といい、使ってない人には関係なくて申し訳ない。
この二つが止まると情報収集に支障をきたしまくりな最近。
その Bloglines がデータセンター移転(パフォーマンスが改善する見込み。 Year-hoo!)に伴い停止するとのこと。案内が出ている。日本時間で書いてないとわかりにくいので変換しておく。
なぜか PDT (アメリカ太平洋「夏」時間)と書いてあるが、PST (冬時間)のはず。
2005/12/20 07:00 JST 新規購読が不可に
2005/12/20 09:00 JST サイトが完全にオフラインに
2005/12/20 13:00 JST 停止中の新着を受信した状態で復旧予定
del.icio.us がまた止まっている
ごめんね文がより丁寧に改善されて、また止まっているよ。。。
Due to the power outage earlier in the week, we appear a number of continued hiccups. We've taken everything offline to properly rebuild and restore everything. I apologize and hope to have this resolved as soon as possible. Thank you for your continued patience.Updates will be posted on our blog as we have them.
修復の状況はブログで伝えられるらしいよ。
第7回 PHP 勉強会に行ってきた
株式会社びぎねっと さんのセミナールームにて。参加者は20名ほど。
CBL_ActiveRecord の話題が 2 回、CBL_RememberMe の話題が 1 回出てきた。サイボウズラボの成果物公開が、PHP コミュニティへも何らかの影響を与えることができているということで、とてもありがたいこと。
いろいろ発表がありよかったが、個人的に一番気になったのは ActiveGateway。CBL_ActiveRecord が PHP5 の新機能を最大限活用しているのに対し、Maple の kunit さんが発表された ActiceGeteway は、PHP4 による ActiveRecord 実装。非常に使いやすそうで本リリースが楽しみ。Maple とは独立したライブラリとして使えるようになるということで、まだ PHP4 から抜けられない人にとても嬉しいライブラリ。
社長と同じ苗字と思っていた hata さんに会えて、漢字は違うことが判明とか。僕は元々 Java+Ant ラヴなので S2Container.PHP5 とか phing が気になる。
東京進出された nazoking さんに会えたのも収穫。ずいぶん昔から nazonoDiary と nazonoWatch は Bloglines 経由で読んでいたので。
勉強会後の懇親会、今朝まで忘年会議で飲んでたのもあってあまり元気出せず。
2005年12月18日
忘年会議 2005 に行ってきた
朝5時まで飲んで語る。ひじょーに面白かった。
忘年会議で取り上げてもらえるなんて思ってもいなかったのでびっくりした。これからも海外技術情報をじゃんじゃん紹介せよ、という激励と思ってがんばる所存。
百式バンドを購入。知らない人が見たらほっとけないバンドに見えるだろうなあ。
他の人がレポートを上げてるので詳細はそちらで
# レポート書いた人はここにもトラックバックしてもらえると探す&書く手間がはぶけて嬉しい。
2005年12月17日
ジャパンブロガーズカンファレンス 2005 に行ってきた
ことについて、ここにあとで書く。
翌日の忘年会議が理系に寄ってたのに比べ、こちらは文系に寄っている。
ブログを始めたきっかけ、書き方、注意点、ブログから得られたもの、などを、3部にわたって有名ブロガー、準有名ブロガーらから聞き出すというこのお祭り、ブログを書いている人なら(ほとんどの参加者はそうだと思うが)楽しめたのではないだろうか。僕は非常に楽しめた。
二次会も含め、ネットに距離は関係ないけども、こうして同じ東京にいて交流ができるということは素晴らしいし、交流の機会を作ってくれたカンファレンス主催者の FPN のみなさんには感謝するばかり。
2005年12月16日
週末のカンファレンス/勉強会予定
今はやりの Structured Blogging (構造化ブログ)で書いてみる。hCalendar 形式
ジャパンブロガーカンファレンス～ブログの向こう側を考えてみよう～
12月16日(金)
東京ウィメンズプラザ
忘年会議2005
12月17日(土)
デジタルハリウッド大学 秋葉原メインキャンパス
PHP 勉強会 in Tokyo
12月18日(日)
株式会社びぎねっと
全部忘年会付き :) そして月曜日もラボの新人歓迎会
音楽検索 Musipedia, Google Music, MusicStrands
via TechCrunch
紹介した Musipedia のメロディ検索方式が一部に受けたが、音楽検索の新顔が登場している。
ひとつは Google。映画や株価同様、検索結果で音楽(CD)を特別扱い表示するように。音楽に絞っての検索も。
MusicStrands という音楽検索サイトも、SNS, タグ, リコメンデーション機能などを拡充してリニューアル。いわゆる Web2.0 的な進化か。
サイト検索やブログ検索などと違い、音楽検索といっても検索条件の入力や結果の閲覧でいろいろと手間取るし、著作権の問題も絡んできて日常的に使うようになるかどうかは難しい。一番進化してるのは iTMS かもしれないが、これも iTMS が提供してない楽曲は出てこないし。
2005年12月15日
del.icio.us が止まっている
del.icio.us が今朝 10:00 頃から、もう 4 時間ぐらい止まっている。。。
del.icio.us is down for maintenance. we'll be back in one hour.
昨日は変なエラーメッセージも見たし(他にも見た人が)、大丈夫かいな Yahoo! に買われたばっかなのに。
追記: 18:40 に見たら直ってた
feedmeter ランキング入り
ついに feedmeter のランキング 300 位に入った。今 282 位。いちおう社員ブログを始めたときに自己設定した目標の一つである。開始から 4ヶ月半でなんとかここまで来ることができた。
feedmeter の人気度はどうも蓄積型っぽい(どうやって出してるのかは企業秘密らしいが)ので、長いことやってると有利なんじゃないかなあと思う。新興ブログにはつらいところではあるが、さらに上積みできるようがんばろう。もちろんエントリの内容でね。
2005年12月14日
Google Homepage API
Google のパーソナライズページ(Homepage)に自作パーツや他人の作ったパーツを貼り付けられるようになった。このパーツを作る方法が Google Homepage API。
Google 自身がサンプルとして出してきてる Module がこれら。
これも面白そうなんだけど、Alexa の新 API のドキュメント読みで手一杯で遊ぶ暇がない。
うろ覚えの曲をサーチ (Alexa Web Search Platform 利用サイト )
Wall Street Journal の Alexa Web Search Platform に関する記事中に、
「Rainer Typke というオランダの大学生が、この Alexa Web Search Platform を既に活用中である」と書いてある。
なんでオランダの学生が、発表前の Alexa Web Search Platform を使えているのか、どう使っているのか、がわからないのだが、そのサービスはこれらしい。
メロディから曲を検索するための検索サービスで、サービス自身は2004 年からやっているようだ。
Alexa の新サービスを使うことでより多くの曲を検索できるようになった、ということだが、、、はて? どこに活用されてるのか見えないんだが。
でもまあ、サービス自身が面白いので是非別途ご紹介したかった。サービスは、メロディを入力して候補となる曲情報を得る検索サービス。
Java Applet でキーボードを叩かせたり、歌った音声ファイルをアップロードしたり、といった、他でも見る入力方式のほかに、Persons Code という、「次の音が前の音より上がったか下がったかだけ」を入力するという方式が提案・実装されていて、面白い。
こんなのを入れると、"uuudrudrududdduuuuuddddudduuduuudd"
ありました、って言ってこんな結果が出てきた。
[C] Bach, Johann Sebastian: Cantata/147 No. 10 Jesu Joy (accomp't) BWV147
完全に正しくなくても、似た曲を列挙してくれる。
この入力方式は、T9 とか Palm のグラフィティ を連想させられた。
ブラウザのフォームからうろ覚えのメロディを入力させるとき、現実の制約を考えると、こういう簡略化した入力方式は便利だ。アイデア賞ものだなと感心させられた。
ライブドアのセミナーに参加
昨晩は、Alexa の新サービスについて資料を読んでる途中で、申し込んでた
ライブドア 次世代テクノロジーセミナーシリーズの時間になってしまい、エントリが中断していた。
セミナーは、livedoor ポータルの裏側をどのように運営しているのか、技術的な事柄を惜しみなく紹介していただき、行って良かった。
その後の飲み会でもいろんな人に会えて満足。謎の主賓のヒトとか、かなり昔(10年前ぐらい?)に fj でよくお名前を拝見した方とか、同じくけっこう前から技術系の ML とかでよく見かける人とか、それ以外にもいろいろと。
2005年12月13日
Alexa Web Search Platform の衝撃 - 誰もが検索サービスに参入できる
via John Battelle's Searchblog
Alexa Web Search Platform というのがベータ公開されている。
Alexa は Amazon の子会社、ウェブサイトのアクセス数情報(サンプリングによる推測だが)やオーナー情報などをデータベースとして提供している。Alexa によるトラフィック情報は、(じつはそれほど正確なものではないのだが、)他に適当な指標もないことからウェブサービス同士の人気比較などに参照されることが多く、ご存知の方も多いだろう。
今回の新サービスは、Alexa がインターネットに巡回させているクローラーや、Alexa 側のサーバ資源(CPU やディスク、帯域)をウェブサービスとして公開利用させる、というものだ。
ユーザは、scp を使って自分のデータを Alexa のサーバに送り、サーバ内で Alexa の膨大なデータを使った処理をさせた上で、結果を scp で取得することができる。
これを使うことで、Alexa の持つインデックスデータベースに「乗っかる」ことで、特定用途向けの検索サービスなどを、自前のクローラーや大規模なデータベースを持つことなく作ることができるようになるという。
さすがにこのサービスがまったくの無料というわけではなく、利用に応じた利用料がかかる、とはいえ、800万サイトの40億ページを巡回できるクローリングシステムなど誰にでも作れるわけではなく、その一部のデータを利用して自分のアイデアを実現したい、というエンジニアからしてみると、よだれのでそうなサービスだ。
Google / Yahoo / MSN が検索エンジンの覇を競って久しいが、まだこんな手があったか、というサービスだと思う。
検索サービス以外では、オープンな API による開発者を巻き込んだサービス伝播の例をいろいろと見ていながら、Google API (や競合他社の公開 API)のような、結果検索が再利用できますよ、程度のサービス公開レベルがあたりまえだと思い込んでいた。
Alexa 、というより親会社の Amazon は、以前に書籍データを開発者達に API 公開する、Amazon Web Service によって、Amazon のサイトでないインターネットのあちこちに Amazon のアフィリエイト広告を載せること、つまり「WWW 全体を Amazon の出店にする」という成功を一度達成している。
検索エンジンの検索部分の利用権を売るというこのサービスでも、開発者がほしいものを大胆に提供することで、開発者を巻き込んだ再度の成功を狙っているのではないだろうか。
Read/WriteWeb など、いくつかのブログでは Ning.com との類似性が指摘されている。
この Alexa のサービス自身も広まってほしいし、儲かってほしいと思うが、これに刺激された先行 3 社も、クローラーや検索結果データのオープン化やその対価の低価格化を競うようになってくれると、非常にいいと思う。Google などがどう応対するのか、あるいはしないのか、を注目していきたい。
ユーザガイドの PDF より
サービスを使うべき人
- 研究者
- すごいアイデアのあるスタートアップ企業やホビープログラマ
- 現行ウェブサービスを機能強化したい企業
Platform 内に送り込んで使える言語
- C
- Perl
- Java
参考リンク
デモサイト: カメラの検索サイトを Alexa のデータを使って実現している。
Alexa の Geoffrey Mack による公式ブログでの発表
The Wall Street Journal オンラインの記事
Wired News の記事: あなたの Google を始めよう
Kickstart my heart さんの trackback 経由ご指摘: Web Service 公開までがサポートされている。(たしかにこれ重要そう)
Rauru Blog::ultraviolet さん経由、「サーチエンジンはコモディティ化する」
Read/WriteWeb: Alexa turned into web service - Amazon back to its innovative best
MYCOM PC WEB: Amazon傘下のAlexa、Web Crawl公開で垂直型検索サービス構築を支援
eWeek 翻訳: Amazonがレンタル開始――商品ではなく、検索エンジンを
2005年Web 2.0大賞
The Best Web 2.0 Software of 2005 の訳を POLAR BEAR BLOG のアキヒトさんがされてるのでご紹介。
このブログでも書こうかなと思いつつ面倒なのでやめたもの。紹介されたサービスの3分の1ぐらいは知らなくて、個人のブログだから嗜好の違いもあるんだろうけど、まだまだ調査が足らんなあと反省。
2005年12月12日
ネタネタネタ
なんかネタの流量が多いなあ。ということでまとめて棚卸し。
ロシアのファイト一発男達(動画)
投稿者 秋元 : 18:56 | コメント (2) | トラックバック
OpenOffice と Firefox の裏技
via digg
digg.com で、なんか連続して Easter Egg のネタが続いているのでご紹介
OpenOffice 2.0 で、どのセルでもいいから '=Game("StarWars")' と入れると、インベーダーゲーム風のゲームがはじまる。
...確かめるために OpenOffice1.1.4 だったのを 2.0 にあげちゃったよ。
追記: Going My Way さんのところでゲーム画面を動画配信されてる
Firefox で、 "about:mozilla" というリンクを辿ると、聖書風にもじった「モジラの書 7章15節」が表示される。
同じく Firefox で、 "https://http//www.anydomain.com" と入れるとマイクロソフトへ飛ぶ。
投稿者 秋元 : 14:19 | コメント (2) | トラックバック
Google が NASDAQ 100 入り
via reuters
Google の株価が、NASDAQ 100 指数に組み込まれるようになった。あと Expedia(楽天トラベルみたいな会社) と Monster(リクナビみたいな会社) も。ついでに RedHat や NVidia も。
2005年12月10日
Yahoo! が del.icio.us を買収
Yahoo! の検索ブログからの発表、 del.icio.us の開発ブログからの発表
del.icio.us がどこかに買われるだろうことは明らかだったが(儲けてないし、単体で儲ける方法も不明だった)、Yahoo! が手中に収めたようだ。
Flickr の買収と統合で起こったことが再現するのであれば、一年以内には del.icio.us のアカウント ID が Yahoo! ID にまとめられるような動きがあるのかもしれない。Yahoo! の場合、そうなると国ごとに異なる ID 体系を持っているため、米国外の del.icio.us ユーザには面倒が増えるが。つまり、Yahoo! Japan の ID では del.icio.us にはアクセスできない、とか。
投稿者 秋元 : 13:47 | コメント (2) | トラックバック
2005年12月09日
Yahoo! Answers 登場
via John Battelle's Searchblog
米国 Yahoo! で Yahoo! Answers がサービス開始された。元々は Yahoo! Korea 知識検索 で大ヒットし、Yahoo! 知恵袋(2004/4 サービスイン)でのローカライズ成功を受けて、いよいよ本家 Yahoo! への登場ということか。
インターネットの歴史が長い米国では、もちろん人力検索サービスの歴史も長い。が、なぜか韓国や日本に比べるとユーザ数や盛り上がりに欠けるところがある。
僕の場合は 1999 年頃から Experts-Exchange を使っており、検索エンジンでもメーリングリストの過去ログでも見つからず、メーリングリストや IRC で訊いてもわからなかったときに、最後の手段としてここで質問していた。そこまで回答が見つからないことは滅多にないが、ここでやっと回答が得られたこともある。
Experts-Exchange は 1997 年開設ということで、初期からやっていたこともあり、気が付いたら技術者ばかりが参加する、技術の質問しかできない場となっていた。また、参加者を増やして広告で儲けるのではなく、過去の回答をクローズドにして高級会員からお金を取る方向に行ってしまった。
あとは、お金を払って検索してもらう Google Answers, 質問の集積というより、回答の FAQ 化のほうに力が入っている(Wikipedia などの方向にちょっと近い) eHow , Wondir などが競合といえば競合だろうか。
今のネットサービスは米国から輸入されたものが多いが、アジアで普及して米国へ、という方向でこのサービスの人気が出るかどうかは興味のあるところだ。
追記: 日本語の質問と回答、ちゃんと書けるよ、と思ったが、後日(7日後)、"not in English" という違反で削除しました、というメールを受け取った。システムは受け付けるけど人間による管理で除去してるということか。たいへんな話だ。
どうしてみんなトイレで勉強したがるんだろう
台湾のメーカーが、トイレットペーパーに RSS を出力できる機械を出したという。
rsstroom (Restroom + RSS) と名づけられたこの機械は、トイレットペーパーにフィードから取得した最新のニュース等を印刷してくれるので、トイレでゆっくり最新ニュースをチェックできる。
アイデアとしては、2003 年に報道された、トイレットペーパーにネット情報を書き込むものがあるそうなので、今回の製品は量産実用化ということだろう。
トイレットペーパーに印刷した単語帳とか小説など、この手の商品は昔からよく見るけど、自由に好きな情報を載せることができるとなると、そういう商品に飛びついた人たちにとっては福音かもね。
# "Yi Tien Electronics" のサイトがどうしても見つけられないので、本当にこの製品が実在するのかどうかはまだはっきりしない。というか、尻が真っ黒になるのでは。。。
投稿者 秋元 : 16:44 | コメント (2) | トラックバック
2005年12月07日
サイボウズ本社の求人
サイボウズ・ラボは依然技術者募集中、という前回のリマインダから、ありがたいことに応募数も復活しつつある。メールでの問い合わせや見学も増えてきていい感じ。ありがとう。引き続きサイボウズ・ラボでは尖った技術者を募集中。
便乗での宣伝エントリになって申し訳ないが、サイボウズの本社開発部も、とにかく人が足りないようなので告知させてほしい。
グループウェアのサイボウズでは、ソフトウエア開発エンジニアやソフトウェアアーキテクトなどを募集している。アーキテクトやプロジェクトマネージャについてはこちらの記事もご覧いただきたい。
ラボは中長期的な研究開発が主体となるが、本社ではパッケージ製品やサービスで作ったものが短期間でユーザの目に触れる開発となる。ユーザを喜ばせることに楽しさを感じる技術者のみなさんには是非検討対象に入れていただければと思う。
最近いろいろなところで技術者の方とお話させていただいているが、日本にはとにかく受託開発だけの会社が多いようだ。大規模な受託やチャレンジングな受託もあるとは思うが、受託開発の仕事に行き詰まりを感じていて、開発物が数百万ユーザに使われてフィードバックが得られるパッケージ製品やネットサービスに興味のあるやる気のある開発者の方は、ぜひサイボウズも検討いただきたい。
ラボは一匹狼的なプログラマも多いが、本社開発では「チームでの開発ができること」が重要となる。技術的に難しい問題については、勉強会などを通してサイボウズ・ラボの面々と共同で取り組むことも多いので、一緒に情報共有ソフトウェアの未来を創っていこう。
投稿者 秋元 : 15:50 | コメント (1) | トラックバック
2005年12月06日
あなたの企業、URL で損していませんか（1）www を再チェックしてみる
“http://”ではじまる URL = Web サイトのアドレス、が一般にも理解されるようになってしばらく経つ。ネット上で商売/広報を行う企業にとっては、URL こそが企業やサービスの存在を指し示すネット上の住所といえる。
実世界で会社の本社所在地が二種類あったり、二つの事務所が本社を名乗ったりしたらどのような混乱が起こるだろうか？ 会社の Web サイトのトップはここですよ、という会社の代表 URL だが、意外にもこの URL がおろそかにされているケースが多い。
あなたが、ある潜在的な取引先から口頭で URL を聞いたとしよう。「株式会社イグザンプルで、後ろは co ドット jp です」
帰社してから言われたことを思い出し、ブラウザに URL を入力する。
http://example.co.jp/
しかし、なぜか企業サイトには接続できず、エラーとなってしまった。
ここで少しネットに詳しい人なら、先頭に“www.”をつけて
http://www.example.co.jp/
で無事企業サイトを閲覧できるかもしれない。しかし、万人にそれを求めるのは難しいだろう。会社の綴りを間違えて聞いたか、などと思いあきらめてしまうかもしれない。
歴史的に、ドメイン名の前に“www”がある場合とない場合のどちらでも同じようにつながるようにしよう、という設定をしている組織は多い。が、それは必ずしもルール化されているわけではないため、どちらか一方でしかつながらないサイトも多い。
実際の企業で調べてみよう。
(1) “www”が無いと接続できない Web サイト
| 朝日新聞 | http://www.asahi.com/ |
| トヨタ | http://www.toyota.co.jp/ |
| ソフトバンク | http://www.softbank.co.jp/ |
(2) “www”があると接続できない Web サイト
| del.icio.us | http://del.icio.us/ |
(3) どちらでも接続できる Web サイト
| Yahoo！Japan | http://www.yahoo.co.jp/, http://yahoo.co.jp/ |
| ライブドア | http://www.livedoor.com/, http://livedoor.com/ |
(4) どちらでも接続でき、どちらか一方に転送される Web サイト
| 楽天 | http://www.rakuten.co.jp/ |
| Mixi | http://mixi.jp/ |
(5) まったく別々の内容が出てくる Web サイト
大手サイトではこのケースは見つからず。“www.”をつけたときとつけないときで出てくるコンテンツが異なるという設定だが、混乱の元なのでこういった設定はおすすめしない。
（1）や（2）のタイプの設定がされている Web サイトでは、“www”があるか無いかを、訪問者が正確に覚えたり、打ち込んだりすることを要求していることになる。この時点で、どちらでも接続できる（3）や（4）のタイプの設定をしている企業サイトに比べて、訪問者を取りこぼしている可能性があることになる。
今現在（1）や（2）で運営している有名企業サイトは、いまさらネット経由のユーザーを取りこぼすことに対してはあまり気にしていないのかもしれない。すでに有名な企業であれば、Web サイトがあることは疑いがないし、検索エンジン経由で辿り着いてもらえるだろう。しかし、あなたの会社がそれほど有名でないとしたら、こういった URL について改善することで何も損はしないはずだ。
（3）と（4）の違いによって企業サイトの集客にどのような差がつく可能性があるか、については次回述べることにしたい。
投稿者 秋元 : 11:04 | コメント (3) | トラックバック
japan.internet.com でコラムを書くことになった
japan.internet.com でコラムを書くことになった。カテゴリは Web テクノロジー。頻度は、数週間に一本の予定。
コラムは、Web サイトの製作を発注する側の立場で、どのようなチェックによって製作側のスキルを確かめることができるか、というテーマで書いていく予定。このブログで想定している読者の方とは少し異なるジャンルになる。
このブログでは、技術的に最新の情報を(ときどき誤報など失敗もあるが)お伝えしようとしているが、あちらのコラムのほうは、ある程度知っている人には自明のことも含まれるだろう。コラム内容は当ブログでも併載していくが、内容のばらつきについてはご容赦いただきたい。
また、僕自身が間違って理解していたり、突っ込みが足りなかったりということもあるはず。みなさんからの情報を頼りに、なんとか続けていければと思う。
japan.internet.com 上での初回コラムはこちら。当ブログ上での第一回は次のエントリにて。
人力電光掲示板
キーボードを叩いてみる。そんだけ。K の字が笑わす。
2005年12月05日
CEO Eric Schmidt の語る Google の掟 10 か条
via Google の CEO、エリック・シュミットらによる Newsweek への寄稿記事
ナレッジワーカー(知識労働者)の生産性を上げるためにグーグルが守っている 10 個のルールを CEO の エリック・シュミットが自ら紹介している。
# 中身まで訳すと Newsweek の人に怒られるだろうから項目名だけ。たぶん Newsweek 日本版にもそのうち翻訳が載るんじゃないか
- グループによる採用
- 社員がほしい設備・施設は何でも与える
- 社員を隣り合わせに詰め込む
- メンバの協同作業をやりやすく
- 自社製品/サービスを自分達がまず試す
- 創造性を称揚する
- 合意への執念
- 邪悪なことはしない
- データによって判断する
- 効率よくコミュニケートする
また、シュミットは Google が直面してる問題として 4 つを挙げ、これらの解決にがんばっているという。
- 過剰な技術偏重主義
- 「自分で作ったほうがうまくいく」症候群
- 成長に伴う様々な社員すべてにとって魅力的であり続けること
- 世界企業となった上でのコミュニケーション問題
Javascript のみによるイメージ拡大鏡
via Ajaxian
ハンガリーから美しい Javascript の佳品。イメージの部分拡大するルーペ機能を、Javascript だけで実現している。
カーソルの上下で拡大率を変えられるし、左右ではルーペの大きさも変えられる。すばらしい。自分のページに組み込むのも簡単だ。
写真は フォト蔵 から まさと さんによる CC by による公開。ルーペで養老の滝のフォントを探求しよう。
追記: 2006-03-02 BubbleShare という写真共有サイトで、この効果を使った拡大鏡がついた (via TechCrunch)
投稿者 秋元 : 22:23 | コメント (1) | トラックバック
GAP の広告
GAP の広告。何かと思った(動画、音が出るので注意。)
ネタバレは以下
店舗改装のお知らせ、だね。
投稿者 秋元 : 08:07 | コメント (3) | トラックバック
2005年12月04日
情報収集のための11の質問
情報収集のための11の質問、サイドフィード社の赤松さん(元サイボウズの赤松さんともいう)からじきじきに指名されてしまった。(サイドフィード社のサービスを使いまくってるからかも)
ということで謹んで回答させていただく。
1. RSSリーダーを使っていますか?
yes. Bloglines. 登録は 239 フィードだった。
2. アンテナを使っていますか?
no. 7,8年前にちょっとだけ WWWC を使ってたことがあるが、基本的に使う習慣が無い。今は MyRSS.jp があるのでほとんどのサイトのチェックは RSS リーダーで済むし。MyRSS でも RSS にならなければ無理しては読まない。
3. ソーシャルブックマーク(SBM)を使っていますか?
yes. 情報整理用に del.icio.us, それと記事の反応をチェックするのに はてなブックマーク
4. その他情報収集に使っているツールはなんですか?
GMail。メールでしか取れない情報はすべて GMail アカウントに放り込む。
これまでは各種検索エンジン等から手で情報クリップ用 RSS を生成してたが、今後は freshfeed の利用が増えると思う。
5. 他人にこれはお勧め!と思う方法は?
del.icio.us で自分と同じ記事をよくブックマークするユーザのブックマークを購読する
6. 逆にこれはお勧めできないな、と思う方法は?
うーん。なんだろう。タブ機能のないブラウザを全画面に拡大してネットサーフィンとか?
7. 情報収集で良く参照するサイトは?
del.icio.us popular, tech.memeorandum, eWeek , CNET News あたり
8. 自分のブログで良く言及･リンクするサイトは?
TechCrunch, Ajaxian.com, Read/Write Web あたり
9. 逆にここは参照してはいけない、と思うサイトは?
情報雑食なので何でも目につけば読んじゃうなあ。
10. WEB以外で良く情報源にするものは?
サイボウズ・ラボの尖りまくってる同僚達。あと来訪者、見学者、採用応募者からも。
11. 最後にあなたが情報収集方法を知りたい人は?
いくらでもいるけど、思いついた順で、idea * ideaの田口さん、Goodpic さん、Sooey の juno さん、nazoking さん、 phpspot 管理人さん などなど。del.icio.us でチェックしているブックマーカー達も。購読していて面白いブログを書くかたはみんな知りたいが、必ずしもバトンを渡したいという意味でもない。僕自身バトン類は苦手なほうなので。
最後に企画自体の感想を。これだったら、ブロガーなら、遊びの人も仕事の人も回答できそう。みんなの知りたい気持ちと見せたい気持ちをうまく突いた好企画かも。
2005年12月03日
Ajax を使うべき 10 個のポイント
10 個ないじゃん。とりあえず数を書いとけ、ってのが最近の流行だろうか。
Ajax を使って意味があるのはどんなところか、Ajax によって事態が悪化するようなところはどこか、というのを考えて列挙しているエントリ。Ajax の適用箇所を悩んでいる人にはいい参考になると思うのでおおまかに紹介。
Ajax を使うといいところ
- フォームによる多量の入力
- 深い階層の木構造をたどらせるところ
- ユーザ間のコミュニケーションを行わせるところ
- 投票、「はい/いいえ」、評価ボタン
- フィルタやソートなどのデータ表示操作
- テキスト文入力時のヒントやオートコンプリート
Ajax を使うべきでないところ
- 非常に単純で、失敗が許されないフォーム
- ライブサーチなどの検索
- 基本的なサイトナビゲーション
- 大量のテキストの置換
- 大々的な表示の変化
- 無意味な Widgets (UI 部品)の利用
個々の「べき・べからず」を主張している理由はさまざまなので、特定の項目に対して異議や疑問のある方は原文の解説を当たられたし。著者は別途 Wiki も用意してこれに関する意見を集めている。
投稿者 秋元 : 14:03 | コメント (1) | トラックバック
Web2.0 の遺伝子
via TechCrunch
用語 Ajax を定義したことで知られる Adaptive Path に所属するシニアコンサルタントの Brandon Schauer によるブログエントリ Experience Attributes: Crucial DNA of Web 2.0 では、今現在 Web2.0 の要素、特徴として言われていて、
Web2.0 以前から存在した Web2.0 的な構成要素を7つの属性としてあげている。(この7つは、Tim O'Reilley があげている図中の7つの要素とは一致していない。)
それらWeb2.0 的な7つの属性が元々いつ、どこから発生しているのかを、美しい図(pdf)とともにまとめている。
この図の中で彼は、Web2.0 の属性を Foundation (基礎的)なものと Experience (体験的)なものに二分し、Foundation Attributes (ユーザによる補助的なデータ参加、ロングテール、ネットワーク効果)は1990年代から Amazon や eBay などによって提供されており、そこに後から Experience Attributes (分散化、 ユーザによる全面的なデータ作成、 リミックス-ability、 全体をまとめあげて新しい価値を作り出すシステム)といった要素が次々と加わって、現在に至っている、としている。
この図を見ながら思ったが、10年前と今を並べた時系列のどこにも、「ここから Web2.0 だ」という線が引けるわけではないことにあらためて気づかされる。Web2.0 と誰かが言い出したから Web2.0 が出来たわけではなくて、Web2.0 はあくまでこれらの流れを振り返って(そしてこれまでの流れをさらに未来へ延長することを考えて)定義されたムーブメントでしかない。
図の作者は、コンサルタントなわけだし、「あなたの会社は図のどこにいます? 欠けてる要素はなんですか?」みたいに締めている。
cybozu.nite 2.0 に行ってきた
cybozu.nite 2.0 に行ってきた。新 cybozu.net 社のお披露目パーティーだ。
サイボウズ・ラボはサイボウズ本社の 100% 子会社、cybozu.net はサイボウズ本社の 40% 出資(残りの 60% はサイバーエージェント社)ということで、本社を通して親戚会社ということになる。
パーティーは抽選や招待でいらした100名以上のみなさんで盛り上がった。最近いろんなところで知り合うようになったブロガー諸氏との再会や、新たな出会いもあり、面白かった。とはいっても挨拶できてない人が半分以上いたが。
新 cybozu.net のエンジンとなる feedpath の開発中画面デモも大スクリーンでチーフの小川浩氏による紹介がされた。開発もたいへんだろうとは思うが、ぜひ del.icio.us から移行したくなるようなサービスになってほしい。
あと料理がうまくてお酒も美味しかった。cybozu.net/Feedpath のスタッフのみなさんお疲れさま!
追記: この晩はちょうど Binary 2.0 とぶつかってて、そっちに行ったラボメンバーも。
あと、巡回先等で見つけたレポート: ZDEA Blog , Michi-kusa , POLAR BEAR BLOG , 神保町ではたらく社長のここだけの話 , R30::マーケティング社会時評 , SW's memo
などと手作業でリンク集を作りつつ、Web2.0 とか XML とか言ってるなら、開催案内ページ に参加者がトラックバックぐらい打てるようにしててもいいんじゃないかな、とは思った。ここがそうなのかな? R30 さんじゃないが cybozu.nite 3.0 がもっとすごくなることを期待。
2005年12月02日
「あとで読む」専用ブックマークサービス looklater
looklater は、あとでチェックしよう、と思うようなサイト/ページをブックマークすることに特化したネットサービス。
Bookmarklet をブラウザに登録しておけば、見ているページや、そこからリンクされている他のページを、looklater に登録することができる。登録された URL は、日付ごとなどに整理されて、あとで見返したり、もう見たと思えば削除することができる(登録済ページのサンプル)。ブックマークレットの利用についてはデモがあるのでそちらを見てもらうのが早い。
このサービス自身は、個人があとで見返すというところに注力しているようで、共有機能などは無い。del.icio.us などと競合するつもりも無いようで、looklater サービスからは、del.icio.us への登録や、各種検索エンジンに飛ばすなどいろいろリンクが用意されている。
僕の場合は、どうしても今読めないものや読む気にならないものは、ブラウザで開いたまま何日も放置したり、ブラウザのブックマークに入れたりしている。なんとなく「あとで読む」というマークをつけても2度と読まない気がしてしまうからだ。ま、これは性格がいいかげんだからかもしれない。ブラウザのホームページを「あとで読む」タグの一覧ページにしてしまえばいいのかも。
「あとで読む」というタグがオンラインブックマークサービスで特別な意味を示しているのは確かで、人によってはブックマーク先のページを表すわけでもないこの手のタグが増えることを嫌がる人もいる。looklater の試みは面白いと思うが、できれば、del.icio.us などが直接「あとで読む」をより使いやすく運用できるための(そして、folksonomy による分類が崩れないようにするためにも)機能を追加してほしいように思うのだが。
追記: 仕事が終わったあと、cybozu.nite 2.0 に行ってきた。EC ナビ 社長で ｃybozu.net 社長でもある宇佐美さんと初めてお会いすることができたが、そのときさっそくこの looklater 紹介エントリについて「読みましたよ」と言われびっくり。ついさっき書いたばかりなのに。
そのときも補足したが、最近はやりの SBS に対し「ソーシャルでない」ところに特徴があるわけではなくて、ベースが SBS でもいいのだけれど、「あとで読む」とか対象のページの分類とは別系統の、ブックマーク利用者の行動に関わる特性は、別扱いすることで便利になる可能性があるのでは、というのが僕の意見。EC ナビラボさんも ECナビ人気ニュースという SBS をお持ちなので、そんな機能はどうですか、とお願いしてみたりした。
投稿者 秋元 : 13:34 | コメント (6) | トラックバック
2005年12月01日
アナログをデジタルにつなげる - 手紙から電子メールへの変換サービス
Remote Control Mail は、紙の手紙をメールで受け取ることができるという有料サービスだ。サービスは限定的にはじまったばかり。
指定の住所に届いた自分宛の手紙について、まず封筒表側をスキャンしてネット経由で閲覧可能にしてくれる。その表書きを見た利用者は、それぞれの封筒について、さらに以下の処理をさせることができる。
- 自宅や会社へ転送
- 開いて、中身をスキャンして PDF 化、メールで転送(ただし、これは2006年開始予定)
- シュレッダーにかけて捨てる
コストは、$2.5/月の基本料金と、上記の「させること」の内容や件数に応じた従量課金の組み合わせだ。
紙の手紙を主に使う人と、eメールを主に使う人の橋渡し的なサービスになる可能性があるのではないかと思う。
技術者として、新しい技術、新しいサービスばかり見てしまうことがあるが、実際のサービスの対象ユーザを考えた場合、今あるサービスからの段階的な移行をどうするかについて考えることも重要で、またそういうところにこそビジネスの芽があるのかもしれない、と感じた。日本でもほしいサービス(もし既にあったら教えてほしい)。
