ついでなのでfeedflare-appengineをlivedoorクリップにも対応させました。
feedflare-appengine - Google Code
パーソナル・フィードフレアのURLとして「http://feedflare.as-is.net/livedoor」を指定するだけで、使い方はまったく同じです。
feedflare.as-is.netでホスティングしているFeedFlareのカタログは、以下のURLで確認できるようにしてあります。
他にあったらいいなというFeedFlareのアイディアがありましたらコメントをお願いしますね。feedflare-appengineのコミッターになっていきなり追加してくれる人も募集中。
ちなみにFeedBurner側でFeedFlareの内容を1時間くらいキャッシュするみたいです。すぐに反映されなくてムッキー！となりますが我慢してください。
livedoorのWeather Hacks、良いのですが、なぜgeo vocabularyが付いていないのでしょうか? だって天気情報とか地震情報って地理情報でしょう?
なんだかな～と思ったので、geo vocabularyを付加するサービスをでっち上げてみることにしました。とりあえずのプロトタイプとして、「http://as-is.net/maps/geolwws.fcgi?url=RequestURL」てな感じでlivedoor WeatherのRSS URLを渡すと、geo vocabulary付きのRSSを返すものを作ってみました。
http://weather.livedoor.com/forecast/rss/index.xml
↓
http://as-is.net/maps/geolwws.fcgi?url=http://weather.livedoor.com/forecast/rss/index.xml
今のところｌivedoor Weatherが提供しているRSSのうち、ldWeather:lwws要素を含むものにしか対応していません。geolwws.fcgiに渡すRequestURLはURL encodingされているべきですが、単にRSSのURLを渡す分にはencodeしなくても構いません。
geo vocabularyが付いているとどんなご利益があるかと言えば、何はさておきマッピングサービスとの統合が簡便に実現できるということです。例えば、Ogawa::Buzz: georss2kml.cgi: GeoRSSをGoogle Earthにマップするスクリプトを使って、天気情報をGoogle Earthにオーバーレイすることができます。
http://as-is.net/maps/georss2kml.cgi?url=...
georss2kmlをもう少しいじらないと見栄え的にアレですが...。
上でも書きましたが、ldWeather:lwss要素を含まないRSSは変換できません。今のところ、livedoor Weatherが提供するRSSのうち、(1)特定の地点の時系列データを表すRSS、(2)防災情報やアメダスのデータを表すRSSには、ldWeather:lwws要素が付加されていません。
(1)については、特定の地点ですからgeo vocabularyを与えることはできます。ただし、それが意味があるかどうかは微妙なところです。(2)については、天気情報と地域区分の方法やレベルが異なるために難しいです。例えば、アメダスは、天気情報の区分(全国の地点定義表)よりずっと細かい行政区に対する情報が与えられています。これらのすべての地点の座標情報を与えるのは、個人ではほとんど不可能だなあという印象です(だからこそ、本当はlivedoor Weatherで対応して欲しい)。
また、このプロトタイプの自然な拡張としては、RESTを利用したlivedoor Weather APIの出力結果にもgeo vocabularyを付加するというものがあるでしょう。もちろん、リクエストをまともにこなすことやAPIの持つ定義域・値域の膨大さを考えたら、このようなゲートウェイサービスを作るよりは、上流(livedoor Weather)か下流（クライアント）で付加する方が現実的、というのが妥当な判断だと思いますが...。
全国一斉ライブドア祭りの三日目ですが、みなさまいかがお過ごしでしょうか。
今日の時点で416円で売買単位は1株。もし今買いを出せば比例配分です。配分単位は1株なわけで、売り方からすれば相当の量自分で売っていない限りおそらく1株しか約定しないでしょう。業界最大手のイートレード証券の手数料が最低で472円(?)ですから、手取りは416-472=-56円。とんだ投売りですね…。ホルダーじゃないのでどうでもよいのですが。
数あるお祭り銘柄の中で、お祭り的観点から私が注目しているのは、やはりWIDE星人の星、吉村伸氏のメディアエクスチェンジ。先月半ばにライブドア組に入ったばかりですが、今月に入ってからのぶっ飛ばし具合はとても気持ちがよいものがあります。村井純氏の財布もすごい勢いで膨れたり縮んだりしてるわけです(ライブドアのTOBに応じてしまっている可能性はあるけれど)。
株式交換で子会社になったわけでもないし、ライブドアと大して取り引きがあるわけでもないし、ライブドアがもしぽしゃってもポータル事業をそのまま引き継げる子会社は多分ここだけ。平成電電にとってのドリテクのポジションをゲットできる千載一遇のチャンスかもYO。
2006-01-23追記: 念のため買い煽りではないですからね。個人的にはPER 15～20でお待ち申し上げております。
livedoor PICSですが、あまり使われていないそうなので(笑)、Flickrの画像をダウンロードしてきてlivedoor PICSにアップロードするスクリプトを作ってみました。50MBとはいえ貴重なネットワークストレージ、有意義に使いましょう。多分ある時点でlivedoor Blog並に(2GBくらいに)一気に増量されるのではないかと勝手に思っています。
http://ogawa.googlecode.com/svn/trunk/flickr2pics/
Flickrの画像情報を取り出すのにFlickr Servicesを、livedoor PICSにアップロードするのにlivedoor PICS WebServiceをそれぞれ使っています。「2.0」ぽいですね。Webでサービスしてもよいのですが、トラフィックが洒落にならんのとBrute force attackをされるとかなわんので止めておきます。
スクリプトを動作させるには以下のPerlモジュールがインストールされている必要があります。
スクリプトの冒頭の変数$FLICKR_USERNAME, $PICS_USERNAME, $PICS_PASSWORDを自分の環境に合わせて修正した後、コマンドラインから起動すれば動作するはずです。
このスクリプトはflickr.people.getPublicPhotosを使って$FLICKR_USERNAMEで指定されたユーザのPublic Photoのリストを取得し、それぞれの画像に対してflickr.photos.getInfoで詳細情報を取得しています。したがって以下のような制限・留意点があります。
また、PICSに反映される情報は今のところタイトルと画像ファイルだけです。Flickr2picsでは、Flickr APIを用いて画像に付加されたDescriptionやTagsなどの情報も取得していますが、PICSのAtomPPのインタフェースにそれらを追加する機能がないので反映しようがないためです。リバースエンジニアリングすれば見つかるかもしれません。これができると本当は面白いのですけれどね。
2006-01-12追記:
ひょっとしてdc:subjectでいいのかもと思った。後で試してみよう。
試してみたけど、×だった。XML::Atomでdc:subjectを複数追加するのが面倒な感じがした。
Flickrの劣化コピーとして一躍有名になったlivedoor PICSですが、アップロードしたオリジナル画像にアクセスする方法が提供されていないようなのでBookmarkletを作ってみました。
上記リンクを右クリックなどしてブラウザのお気に入りなどにブックマーク登録しておけば、livedoor PICSのページを閲覧中に元画像を表示することができます(新規ウインドウが生成されます)。
ちなみにlivedoor PICSでは、一画像を5種類のサイズで表示できるようです。Flickrにはこれらに加えてLargeサイズがあります(Flickr: Help: Photos)。オリジナル画像が小さい時にはLargeサイズが存在しない場合もありますけど。
上のBookmarkletは、単純にページに含まれるMediumないしLargeサイズの画像URLをOriginalサイズのURLにコンバートして表示するものです。
2006-01-11追記: 当初PICSの画像ファイルの拡張子は「.JPG」「.jpg」などアップロード画像と同じものが付いていましたが、いつの間にやら「.1」のように変更されていました。Bookmarkletもこの変更に対応しました。
白ピクミンなので久し振りで調子が出ないので毒でも吐いてみます。
Livedoorと言えば、最近はブログを全面に出したポータルのプロモーションを行っているわけなのだが、鳴り物入りでスタートしたように記憶している未来検索は今現在機能しているのだろうか。
http://sf.livedoor.com/blog?blog_id=http://as-is.net/blog/てなURLを叩いてみれば分かるのだが、11月29日以降更新されている気配はない。
ではというので未来検索のベースとなるコードを提供したと想像される宮川氏の分(http://sf.livedoor.com/blog?blog_id=http://blog.bulknews.net/mt/)も調べてみると12月21日以来更新されていない。一方ではちゃんと更新されているブログもあるので、平たく言えば仕様上の欠陥があるがそのまま放置されているということだ。サポートページでもサービス開始当初こそ「更新されへんがー」とクレームをつけている人もいたが、最近ではわざわざ指摘する人も稀だ。実用面で言えば、ブログ検索機能なら先発のTechnoratiの方が遥かに安定・充実しているし、検索結果をRSSとして表示する機能なら後発のMSN Search(RSS を使用して検索結果の更新内容を入手する)の方が意味がある。つまりは実用にはならないが、エチュードあるいはコンセプト作品としてわざわざ掲示されているのだろう。
ついでにLivedoorのWebベースのRSSリーダー(名前はなぜかBlogリーダー)にも言及しておきたいのだが、これを使っているというユーザーは現実問題としてどれくらい存在するのだろうか。こちらも未来検索ほどではないがあまり更新されない。私のブログの最新更新日時は4月25日だそうだが、26日(ブログの日)の直前に更新することになっているのだろうかと邪推したくもなるほどに、この遅延は容認しがたいものがある。尤も私はBloglinesの1～2時間の遅延すら容認できない狭量の持ち主である。
それよりも問題なのは画面のレイアウトなのだが。
1024×768の人々の視界:
...。
800×600の人々の視界:
...。なぜだか涙で視界が曇ってきてしまう次第。
私が言いたいことは、つまりは「もっとがんばりましょう」ということだ。
Web屋さん(Livedoor)が本当にミッションクリティカルなシステムを組むことが可能か、という貴重なproof-of-concept実験。
livedoor FX
livedoorFX辞めたの？
【無稼動】livedoorFX辞めたの?Part2【バグ付】
Apache Tomcat/5.0.28
なぜニュースにならないのかは不明ですが、したらばやblogと違って、現金の動くシステムのトラブルは業務改善、業務停止命令が出るから怖いですね。
でも...とちょっと思うのです。外為の証拠金取引業者は先物取引業なので金融庁の管轄じゃなくて経産省の管轄になるはずで、にも拘らずlivedoor FXをやっているライブドア証券は金融庁の管轄下にあります。とすると、この業者に行政処分を下すのはいったい誰なんでしょうか。
なんだかここにも役所間の綱引きの目がここにもありそうです。先物業者の預託金に欠損がある場合ならともかく、円滑な取引が阻害されていることに対して経産省が注意以上のことができるのでしょうか。今後の動きに注目したいと思います。
今回うかうかしていて分割権利を取ってしまい、新興市場名物ライブドアジェットコースターに乗ってしまった。金曜から4連続S高。しかしまだたかが4連続でしかない。これからがジェットコースターの真骨頂。
今日発表された近鉄球団の買収交渉は知名度向上を狙ったものに間違いないが、十分以上にお釣りが来たようだ。テレビニュースでもやたら放映されている。元手のかからない秀逸な広告戦略と言えるだろう。やるじゃないか。でもよく考えると、ピカツーの重田氏の転落(と言っても今も代表取締役会長だが)もテレビに出たあたりから始まったなあ、と…。
東スポ的にはこんな感じ↓
出品・入札・落札などのシステム利用料等が一切無料のオークション(livedoorなのがネック)。
livedoor SIP PHONEが大量出品されているのではないかとわくわくして見に行ってみたのだが、そんなことはまだなかった。社長のひとのしょぼい家具などの出品が目玉というあたり、例によって自己完結度高め。
