« 2005年09月 | メイン | 2005年11月 »
2005年10月26日
BlogWriteでLivedoor Blogでの画像投稿
Livedoorの新環境移行が済んで以来、LivedoorBlogで画像が追加出来るのか出来ないのか中途半端な状態が続いていました。
参照：BlogWriteからSo-net blog、Livedoor blogへ画像の送信（未遂）
ひょんな事から、今テストした所、BlogWriteからLivedoorBlogへ、画像付き記事を投稿することが出来る事を確認しました。何はともあれ良かった。
投稿者 BlogWrite担当 : 19:49 | コメント (0) | トラックバック
Google Base
ぐはぁ...。ここで、ちょっと大風呂敷広げたかな、なんて思っていたら、数日もしないうちに、こんなニュースが..
ユーザーから「売却する中古車のリスト」などの情報の提出を受け付けて検索データベースに加える「Google Base」の存在が明らかになった。
10月25日に一時的に公開されたbase.google.comのページによると、Google Baseでは、ユーザーはGoogleの検索データベースに情報を提出できる。 このページでは、Googleはユーザーが提出できるコンテンツの種類として、...（中略）...価格や不動産の種類、写真などの情報を入力するフォーム――おそらくは、賃貸あるいは売却する不動産の目録を掲載するためのフォームだろう――を含む別のGoogleページの画像が掲載されている。
『コンテンツ所有者が簡単にGoogleにコンテンツを送信できるようにする製品の初期段階のテスト版』という事でここ何年も個人的に注目してきたことに近いので、Googleがどれほど本気か分からないけど、とっても注目。
公開後しょっぱなは難しいとは思うけど、APIでCRUD出来ると最高ですね。多分やるんじゃないかと、むちゃくちゃ期待しちゃいます。 以前書いたように、多数のサイトからアグリゲイト（収集）するのもありだし、APIで投稿出来るようにするのもありなんで、楽しみ。とりあえずファイルから追加は出来るという噂も。
しかしこういう風に、期待させることをやってくれる所がGoogleの魅力ですね、やっぱり。日本のYahooは期待しても無駄っていうか。
追記：
『特定のコンテンツに関しては、もはやクローラーの時代ではなくなったのだろうか』
グーグル、「Google Base」の実験開始--イーベイと衝突の可能性も
そういう事かと思います。ゴミが増えすぎたのと、金額が関わってくるコンテンツの場合は特に。
『典型的なユーザーは手間をかけて素材を直接Googleに送るのだろうか』
一般的に言って現状多くのユーザーは実際、無駄に手間とお金をかけてやっている。けれど、この先にあるのはAPIだろうと、思ったりしてます。
投稿者 BlogWrite担当 : 11:18 | コメント (0) | トラックバック
2005年10月22日
Atom API ≠APP
プログラミングをしている人はもとより、検索をしたことがある人は、検索語句の内、一文字でも違ったら、探している情報を探し出せない、というのを身をもって体験していると思います。ですから現在のインターネットでは名称（の統一と正確さ）は非常に重要なものです。
というか、AtomAPI、またの名をAtomPP、またの名をAPP、正式名称Atom Publishing Protocolとかいうのいいかげんに止めたい.^^;
またまたAtomなんて厄介な名前をつけてくれたなという感じですが投票で決まったのだから仕方がありません。 それにAtomだけだと、あらゆるページの「RSS、Atomフィードはこちら」へ引っかかってしまって手に負えませんし...。
ということで、IETF以前の（つまり現在の）はAtom APIで通し、IETF以降のをThe Atom Publishing Protocol(APP)と呼ぼうと思います、個人的に。つまりAtom API ≠ APPということで、ダメかな...、うーん、いやーもうどうでもよくなってきた。
で略ですが、英語の文章では、前後の文脈や場によって略すことが可能な場合と可能かどうか微妙な場合があります。例えばAtomの話をしていて前後の文脈で明らかな場合、例えばAtomのML等での文章中、または文中すでに一度正式名称を使っている場合は、APPでOK。でも脈絡もなく突然Appだと？だし、Application等々の略でもあるのでNG。
そして私以外の日本の皆さん多くに使われ始めているAtom PPという略は...、一番無難なのだけれど、個人的にはちょっと微妙。あくまで個人的に。HTMLをHyper TML、HTTPをHyper TTPみたいなので個人的にちょっと違和感あるのと、PPが目立ってしまって（「ピー」というのは米口語（一般的に赤ちゃん言葉）で「オチッコ」という意味があったりして）聞いててつい、ピーピー言いながらチビッコが駆け回っている姿が頭に浮かんで始末におえません＾＾;
かといって、APIというのは実はこの場合不適切なんだそうです。アプリケーション・プログラミング・インターフェースではなく、プロトコルなので、はじめにAtomAPIと呼び始めた人が「失敗したー」と言っていましたが、もう遅すぎます。結局のところ「Atom（配信）フォーマット」「Atom（出版）プロトコル」でもいいような気がしますが、またまた別名が増えるのでこれなかった事に。
どちらにしても、Web上で書く場合は、検索エンジンに引っかかるように（つまり他の人の益のために）、面倒でも必ず一度は文頭で正式名称を書く、という風にしようと思います。
投稿者 BlogWrite担当 : 00:14 | コメント (1) | トラックバック
2005年10月21日
Feedフォーマットの歴史、バージョン、起源とか
一部でちょっとRSSというか、Syndication フォーマットというか、Web Feedsのバージョンとか歴史とか話題になってました。 確かに混沌としているのですが、簡略化すれば分かりやすくなるけれど、多くの場合、簡略化しすぎて間違いになってしまいます。
ということで、とりあえず作って見た図。 (OpenOffice2.0を使いたかっただけとも言う)
追記：OpenOffice.org 2.0 Draw形式のオリジナルファイルのダウンロードできます。改変自由、再頒布自由。
原典(ソース)を提示するのも大事なので、以下：
MFC (Apple->Netscape->W3C)
http://www.w3.org/TR/NOTE-MCF-XML/
http://www.w3.org/TR/NOTE-MCF-XML/MCF-tutorial.html
CDF (Microsoft->W3C)
http://www.w3.org/TR/NOTE-CDFsubmit.html
scriptingNews (Userland)
http://davenet.scripting.com/1997/12/15/scriptingNewsInXML
RSS 0.90 (Netscape)
http://www.purplepages.ie/RSS/netscape/rss0.90.html
RSS 0.91 (Netscape)
http://my.netscape.com/publish/formats/rss-spec-0.91.html
RSS 0.91 (Userland)
http://backend.userland.com/rss091
RSS 0.92 (Userland)
http://backend.userland.com/rss092
RSS 1.0 (RSS-DEV)
http://purl.org/rss/1.0/spec
RSS 2.0 (Userland->Harvard)
http://blogs.law.harvard.edu/tech/rss
Atom (The Atom Project -> IETF)
http://www.intertwingly.net/wiki/pie/FrontPage
http://www.ietf.org/html.charters/atompub-charter.html
ご指摘ご意見感謝。
下記ムックでもイントロ記事で、RSS＆Atomについてそれぞれのバージョンや違いについても詳しく書かせていただいてます。宜しければそちらもどうぞ。
技術評論社 (2005/09/23)
売り上げランキング: 6,326
Webサービスの適用事例を把握するのに大変有効投稿者 BlogWrite担当 : 20:13 | コメント (0) | トラックバック
2005年10月18日
第八回XML開発者の日
というのが11月24日 、開催されます。
RESTとAtom Publishing Protocol（AtomAPI、AtomPP、APP）を中心に、Web2．0時代を支えるRESTによるAPIや来年注目の技術トレンド話題のAtomAPIについてのイベントなのですが．．．。
えと、私もパネルでチョビット何か話す機会を頂きました。
なんか、はてなのNaoyaさん（アルファブロガー）とか、SixApartのhirataさん（日本のブログ界の立役者）とか、XMLの父とも言える村田さんとか、REST入門を書かれた yohei さん、RESTWiki を作った方、かの高橋メソッドの高橋さん．．．
そうそうたるメンバーです。
浮きそうです、というか浮いてます。
というか、AtomAPI、またの名をAtomPP、またの名をAPP、正式名称Atom Publishing Protocolとかいうのいいかげんに止めたい.^^;
投稿者 BlogWrite担当 : 16:21 | コメント (0) | トラックバック
2005年10月14日
ライブドアがフランチャイズ不動産事業参入、不動産とRSSエトセトラ
なになに...。 ライブドア不動産が不動産仲介フランチャイズ（ＦＣ)事業開始
加盟店と顧客の双方に利便性の優れた弊社ＦＣ加盟店を通した不動産取引が増加することでが業界自体の改革および活性化につながるものと考えております。
ITと不動産業界、という点ではかなり詳しいつもりですが、ライブドア参入という影響は注目したいです。「業界自体の改革および活性化」という所がとってもステキです。個人的経験からすると、エベレスト級に大変そうですが、彼ならもしかすると....。と期待しつつ、その前にここの内容の充実が先ではないかと思ったりする。
というか、レインズなど化石時代の代物を一度解体して、ライブドアに発注して１０００分の一の値段で、１００倍マシなのを作り直してもらえば良いのに、とココロの中で思ったのはナイショです。
冗談はさておき、今朝がた、不動産物件検索エンジンCGI公開を書いたばかりですが、開発しながら思った事が沢山あって、例えば、大抵の不動産会社は現状、自社サイトと各種ポータルサイト、 不動産ジャパン（国交省外郭団体＋業界団体運営サイト）、アットホーム、ホームズ、アドパーク、イサイズ、等々様々な場所に大抵はお金を払って物件情報を自分で登録するなどして公開している訳です（場合によってはFaxとか営業マンが足で回って集めてる）。さらにはレインズもありますが、これは物がまったく違うので別とします。
やって見ると分かると思いますが、入力作業は何気にかなり面倒です、コストもかかるし。理想は一度入力したら、あとは良きに計らえ、というものです。しかもコストをかけずに。
どうするかというと、例えば、個々の不動産会社が自社サイト上で、XML形式（またはマイクロフォーマットでも何でも標準化されたフォーマット）で物件情報を認証付きで配信し、アットホーム・ホームズ・不動産ジャパン、（ライブドア不動産でも良い）等のポータルサイトが、登録した個々の不動産会社のサイトから（RSS・Atomフィードを取得するのと同じように）物件情報を取得して、物件情報を取り込めば、個々の不動産会社は自社サイトでの物件情報だけ管理すればよくなるはずです。物件情報の内容が更新されたら更新Pingの発射です。
またライブドア社と協業で不動産の物件データにフィットするＲＳＳデータ形式やアフィリエイト広告ビジネスとの連携などの研究に着手する。
なんて事がさらっと書いてあった記事もあって、良ければお手伝いしますよ（笑）
つまりこれは実質、現状GoogleやYahooが個々のサイトを巡回して様々なページ情報を集めているのと同じです。不動産情報の場合、項目が多いし、言語解析の誤判定は避けたいので、XML形式等での特定の規格で配信する必要がありますし、認証で保護したいという理由もあるでしょうが、そういった事は対応可能ですから、あとはやるかやらないかという問題です。
もし上記のような事が上手く実現したら、不動産業界のウェブ上での下克上が起きると思います。
もちろん一人とか一社で出来ることであればすぐしているのですが、こういうのは全体的にそういう流れになるか、大手が始めるか、（結局無理だった業界団体主導でしか）ないとは思います。そういう意味でライブドアの動きは注目したい（長い目で）。
あとは、デスクトップ上（またはイントラネット内）の物件管理DBソフトから、アットホーム・ホームズ・不動産ジャパン等のポータルサイトへ直接一気に物件情報の公開が出来るような規格（API）を公開するとか..BlogWriteがLivedoorブログ、MT、シーサー等のブログサイトに投稿出来るのと同じ按配です。色々な点で、こっちの方が良くて、前向きな会社もあったのですが、一部のサービス運営会社にはかなりの抵抗感があるようでムリポでした。。
あと、他社付け（先物、流通）物件に関しても、同様で、他社付け可の物件を自社サイトでRSS等で配信しておけば、一々FAXなど送らなくても良いし、まだ空いているかどうかを各不動産会社が電話で問い合わせてくる手間も無くなって良くなるとか。埋まったものは既に埋まった物件はサイトから取り下げないといけない訳で、電話で確認＋取り下げ作業というのが大変な労力になると思います。やろうと思えばこれもある程度自動化できます。
不動産業界はかなり業界としてITに関して動きが遅れていて、逆に言えばチャンスがあると言っても良いのではないでしょうか。そういう意味でライブドアにしても、やり方次第でかなり面白いことが出来ると思います（ただし業界内の色々タブーとかを上手くなんとかすればですが）。
ご存知の通り、どれも技術的には簡単に出来る事で、同等の事は既に広く行なわれている事なのです。問題はこれを業界の人に分かりやすく説明する方法だったりしますが（笑）
追記：不動産情報と位置情報に関しても、技術的に可能だけど、上記で触れたエントリでも記述した通り、現状ムリポな一例です。
というか、この文章を最後まで読んでくださったあなたは相当な不動産Geekなこと間違いなしです。
投稿者 BlogWrite担当 : 15:53 | コメント (0) | トラックバック
iPod nano
耐えて耐えて、iPod miniもshuffleもスルーして、待ちに待ってiPod nanoがやっと届いたと思ったら、動画再生のiPodが発表とかやめてほしかったりします。
orz,
投稿者 BlogWrite担当 : 12:58 | コメント (0) | トラックバック
Movable Type 3.2 （再）
MovableType3.2についてですが、しばらく前に、下記のエントリでもお知らせいたしましたが、告知が早すぎたようで、MT3.2がリリースされた後もお問い合わせを頂くため、改めてエントリを起こします。（SixApart.JPさんもある程度アナウンスしてくれても良いのに...）
MovableType 3.2 と BlogWrite
BlogWriteから投稿される場合は、 MTの管理画面で設定する専用のパスワードが必要となります。詳しくはMTのマニュアルを参照ください。
さらに、Movable Type 3.2日本語版 Release-2が出ていますが、こういった不具合↓
http://kokogiko.net/m/archives/001347.html
http://kokogiko.net/m/archives/001349.html
http://kokogiko.net/m/archives/001350.html
も指摘されていて、MTの対応が待たれる所です。
MTのバージョンアップ、幾つかのサイトで予定があるのですが、まだ様子見です。MT3.2になってDBがBerkeleyDBだと重い、という話を聞きましたが、普通の共有レンタルサーバーなどではMySQL等では逆にボトルネックとなって高負荷時耐えられないと思うし、SQLiteをサポートしていないレンタルサーバーだとどうなるのか、ガクガク..
以前、DBがぶっ壊れるとか、コメント通知にしておいたのにメールがこない（でお客さんに怒られた）とか、かなり痛い目にあっているので、バージョンアップは慎重に。（^^;）
投稿者 BlogWrite担当 : 11:07 | コメント (0) | トラックバック
不動産物件検索エンジンCGI公開
いつのまにか間が空いてしまいました。ここ一ヶ月、降って沸いたような過激なスケジュールが続いていて、サポート等に対して大幅に反応が遅くなってしまい、ユーザーの皆様申し訳ありません。
という事で、突然ですが本日新しいソフトウェアを一つベータ公開しました。今回は一般向けではなく、不動産業務用のWebアプリケーションです。一言で言うとブログ風に物件を登録管理出来る「不動産物件検索エンジン」、とでも言ったらよいのでしょうか。
普通の不動産会社のウェブサイト上に設置出来る、物件の検索、一覧、問い合わせが出来るようにするものです。まぁ、よくあるタイプなのですが、いざ探して見ると既存のものはどれも個人的に今ひとつだったので、諦めて新たに作りました。
機能的には、
１．認証されたユーザが、不動産物件（賃貸：住居用、賃貸：事業用、売買：土地、売買：マンション、売買：一戸建て、のそれぞれ）に対し、新規物件の追加、削除、一覧、編集、検索の機能がある。
２．一般向けの検索画面、結果一覧、詳細表示、問い合わせまで用意
３．もちろん、結果一覧の並べかえ等々、細かい機能もある。アクセスログも。
４．テンプレート（雛型）で表示を切り分けているため、デザイン見た目は自由に変更出来る。 既存のサイトに組み込みも可。
５．複数ユーザー登録管理。将来的には、各レベルで編集権限等を設定出来るようにする。
ソフトウェアの要件は
一般的なレンタルサーバーで動くこと。拡張性を高めること。
将来的にAtomAPI等で、クライアントのデータベースと同期取れるようにする。Atom、RSS配信も。
技術的特長は、
言語：（当然）Perl
フレームワーク：CGI::Application
データベース：BerkeleyDB (SQLiteも良いのだけれどまだ一般的ではないので)
モジュール：CGI.pm、MLDBM、HTML::Template、etc
XHTMLとCSSによるページの記述
開発環境：SuSE 9.3
動作確認：IE、FireFox、Konqueror、Operaブラウザで確認。
 ← I. 認証したユーザーのみがログイン出来る管理画面。物件の登録、編集、一覧、検索、削除などが出来ます。管理者権限を持っているユーザーは、ユーザーの追加、削除、会社情報の設定なども出来ます。 |
|||
|
|
|
|
| II. 一般向け検索画面 | II. 一般向け検索結果一覧 | II. 一般向け詳細表示 | II. 一般向け物件問い合わせ画面 |
まだベータですが、デモをご覧いただけます。
□デモ管理画面
http://www.witha.jp/reps/demo/app/reps.cgi
ユーザーID：test
パスワード：testuser
□一般向けサンプル画面
http://www.witha.jp/reps/demo/index.html
フィードバック歓迎です。
まだ基本機能で手一杯ですが、最終的には、RSSによる物件（詳細ではない）情報の配信、AtomAPI（AtomPP）による、デスクトップ上の管理システムとの連携（これがやりたかったとも言う...笑）等々、バリバリにやるつもりです。
唯一残念なのが、Google Map APIを活用できないこと。APIを利用すれば、技術的には物凄く簡単に出来るのに、事情があって出来ない。 （「物件付近の地図」にはGoogleマップへのリンクをしています。これはAPIとは別です。）
事情とは、日本の不動産業界では一般的に、住所をすべて公開しないのです。一般的な検索サイト（不動産ジャパン、アットホーム、ホームズ、アドパーク）どれを見ても物件の住所が、丁目どまりなのに気が付くと思います。つまり住所が正確でなければ、geocodingも何もありませんし、Google Map上にピンも立てられません。（プロトタイプ作ったのに...）
では何故住所を公開しないのか、というと、色々大人の事情というものがあるらしく、色々な人に聞くと山のように理由が返ってきます。恐らく店舗や駐車場などなら、住所を公開しても良い、というケースがあるかも知れませんが、それだけ地図検索が出来てもなんだかなぁ、という感じです。
「 不動産情報をAjaxで提供」
http://www.100shiki.com/archives/2005/10/_truliacom.html
なんて話もチェックしてますが、日本で一般的になるのはまず（数年かかっても）無理。テナント専門の業者なら別かも知れないけれど...。