お問い合わせ
会社概要 ソフトウェア 開発ブログ サポート

2007年08月16日

開発用PCをVistaに移行

開発マシンをVistaに移行しました。無謀です。Windowsはサービスパックが出るまで手を出すな、というのは有名な話ですが、今回はちょっと事情があって先週開発PCをアップグレードして、Vistaを入れました。

やっとアプリケーションとデータの移行が終わってひと段落した所ですが、まだBlogWriteを含めて開発環境が移行しきれていない部分もあります。以前まではDelphi7でしたが今回からDelphi Studio 2006にしたので色々と移行作業が残っています。

さて、Vistaの正式版が出る前、ベータ版の頃から使っていた訳ですが、Vistaは使えるのかというと…残念ながら、まだまだ本格的利用には耐えられないと思います。個人用のも含めて複数台のVistaを利用していますが、最新のUpdateを当てた状態でも、それぞれで問題が起きています。ほとんどがドライバーとの問題で、無線Lanのドライバーのせいで突然ブルースクリーンで再起動がかかったり、USBスティックを挿すとドライバーを検索していますのまま固まったり、などなど…。 大体は問題の組み合わせを突き止めたので、地雷を慎重に回避すれば大体動いているのですが、普通はそんな事はしたくないですよね。

一番厄介だった問題は、VistaのUltimateの機能である、MUIのインストールと、PC完全バックアップの機能が、これといったエラー文も無く単に失敗する現象でした。 同様の現象は検索すると色々出てきます。 散々調べたのですが解決策が見つからず、色々試した挙句、判明したのが、ハードディスクが二つあって、Slaveの方にVistaを入れてある場合にこの現象が起きるようです。 デュアルブートにしているPCだったのでちょっと特殊な環境ではありますが、なんだかなぁ…と。いずれにせよ、Masterの方を抜いて起動して実行すると何事もなかったかのようにMUIのインストールが成功しました。とりあえずこれで簡単にWindowsを英語表示にしたり出来ますので、開発したアプリケーションの国際化も多少楽になりそうです。

問題も色々ありますが、いくつか良い点もある(見た目がXPよりはマシ、とかMUIとか)ので、他の問題はマイクロソフトが改良していくのを待つしか無いようですね。

投稿者 BlogWrite担当 : 20:52 | コメント (0) | トラックバック

MTをSQLiteからMySQLへ

しばらくぶりのブログ更新になってしまいました。 忙しかったというのもあるのですが、どうもMovableTypeが調子悪くて不安定になっていた為、モチベーションが下がりまくってしまったというのもあります。

休み明けの機会に、本格的に調べて見たのですが、原因はSQLiteのデータベースファイルが400MBにもなっていたからでした。 このブログはちょっと放って置くとあっという間に迷惑メールやトラックバックが溜まって恐ろしい事になってしまいます。

通常の手順だとSQLiteからMySQLには変換出来なかったので、この記事を参考にして、テーブル毎に変換するようソースを弄ってなんとかデータをMySQLに入れる事が出来ました。共有のMySQLサーバーなので動作は速くは無いですが、安定して動いてくれているようです。 

DB変換前はログインすら出来なくなっていたので大幅に改善されました。投稿ボタンを押したら「インターナルサーバーエラー」とかもホントやる気を無くしてくれます。やっぱりブログを書くのは楽しくないと行けませんね。 という事でブログを書くならBlogWrite^^;

あ、あと一時的に記事に対するコメントとトラックバックをオフにしています。何しろ多い日は一日に数百件の迷惑コメントとかがあって負荷が高いので、なんらかの解決策を考え付くまでちょっとオフにさせてください。済みません。

投稿者 BlogWrite担当 : 20:16 | コメント (0) | トラックバック

2007年02月26日

Vistaで使うと他で化ける文字

Vistaで変更された例のアレ(詳しくは知らない)で、文字表記にまつわる混乱があるそうですが、今に始まったことではなく、またか、という感じです。

基本的にはどうも、字体の変更なので大きな影響はないよ、という事らしいのですが、一部、事情により、新たな字体が追加され、旧字体に加え、新規に文字が追加されたようです。

http://www.jisc.go.jp/newstopics/2005/040220kanjicode.pdf

表外漢字字体表(1,022字)の一部については、技術的な制約から、新しい漢字として追加を行った。」

実は、これが曲者で、

「漢字は、国際標準であるISOにおいても規格化されている。ISOの規格では、今回新規に追加した文字と既存の文字を別の字として扱っている。したがってISOの規定に合わせるため、10字については追加の規定を行った。」

という上記に該当する、既存文字と追加文字が共存する一部例外の文字に関しては、BlogWriteにおいて(HTMLエディタの方では)入力しただけで化けるようです。もちろん、例え正常に入力出来たとしても、それらの文字を使った場合、XPやそれ以前のパソコンで見ると化けて表示されてしまいます。 (なので、このまま、入力した時点で化けます、という方がBlogWrite的には良いかも)

また、幾つか実験した限りでは、Web上のCGIアプリケーション等でも、これらの文字を入力すると、数値参照に変換されてしまったりという問題も確認しました。

しかし、困ったものです…。一応、変換時に候補一覧を表示させると、「環境依存文字」と表記されるのですが、気をつけていないと、つい間違って使ってしまいそうです。一目では字体の違いがわからない同じ文字が二つ並んでいるのですから…。

投稿者 BlogWrite担当 : 20:39 | コメント (0) | トラックバック

2007年02月23日

日本発のソフトが少ないのは

404 Blog Not Found: 日本発のソフトが少ないのは日本がアメリカではないから

これに関しては、昔から色々考えていたので少し言いたい所があります。 私も以前から日本発のソフトウェアはもっと増えて良いのではないか、と考えていました。(自分の事は棚の上の天井に置いておいてw)

で、少ないことの原因を、「日本発のソフトが少ないのは日本人が英語が苦手だから」 というのは、語弊がある、またはほんの一面の中の一部しか説明していないと思う訳です。というのも、

(1)そもそも魅力的なソフトウェアが無い現実
海外でウケルだろうな、とか革新的だ、という日本製のオリジナルなPCソフト、ウェブサービスが思い浮かばない。微妙にセンス(見た目や操作性、求める機能)が違う、例えば笑いのツボが異なるような感じで、何かちょっと違うという事も多い。 それに常に2歩3歩遅れている、黒船到来してから慌ててキャッチアップしてる状態じゃぁ・・・。

(2)海外での展開なんて頭から考えていないケース
あまりにも、日本固有の事情に合わせて便利にしすぎて海外へ持っていけないというのも多い。細かい所こだわって高品質、日本人ユーザーにとっては高機能なんだけど…

(3)日本の大手ソフトウェア開発企業の根源的弊害
政府系の仕事や、天下り団体から随意契約しちゃって、下請け、孫受けに丸投げするだけの大手企業がスーパープログラマを抱え込んでしまって、人材が腐ってる。

(4)ソフト(ウェア)といっても、じゃあゲームソフトは、というのは弾氏が指摘している通りだし。

最後に、弾氏が指摘するように、アメリカをアメリカたらしめている魅力が世界から人材を集め、さらに魅力あるものになっていくというスパイラル。このせいで、多くのソフトウェアがアメリカ発(のように見える)なのでしょう。実際には氏が指摘しているように、結果として有名なソフトウェアを作った人が行き着く所がアメリカ、という事も非常に多い。

だって、アメリカから声がかかったら行きたくなっちゃうでしょw 大抵の人は。で、
>英語を操れないと世界デビューはままならず、そして世界デビューした途端に合州国から声がかかる。このジレンマをどう解決していくか。

これには、日本自体が魅力ある、つまり、声がかかったらつい来たくなる所にする必要がある、という事ではないでしょか。mixiを作った方のように優秀な方が自然と集まってくるような所に…

もちろん、最終的には英語は必要になるし、日本にいても最新動向を追っ掛けたり、基礎技術や規格文書を読むのに、英語(に限らず)読解能力はソフトウェアエンジニアとして有益なことは確かです。

但し、英語さえ出来れば、と考えてしまうと、後で大きなパンチを食らうんじゃないかと思います。英会話なんて後からついてくるもんです。まずは、物とやる気ありき。さあ徹夜だ、違w という事で、あとは若い世代に任せた。

投稿者 BlogWrite担当 : 19:20 | コメント (0) | トラックバック

2007年02月17日

rimo.tv スクリーンセーバー (for Win)

rimoなんですが、はてなブックマークで見つけた、rimo.tv.screensaverrimo.tv.screensaverとは)をみて、「面白いアイデア! Windows版もちょっとしたら10分ぐらいで作れるんじゃ?」と思って、試しに作ってみました。(実際は1時間ちょっとかかったorz)

動作環境
 Windows (Vistaで確認)

ライセンス
 フリー

ダウンロード
 rimo_tv_screensaver.zip (244KB)

一応、マウス操作の有効・無効を設定できます。

投稿者 BlogWrite担当 : 16:06 | コメント (0) | トラックバック

2007年01月30日

Windows Vistaの悩み

Windows Vistaが発売開始されましたね。実に悩ましいです。

いえ、買うか買わないか、ではなく(Windowsアプリケーション開発者として選択肢はない)、またひとつPCが増えてしまう事…、また開発環境は移行すべきかどうか。

問題のひとつは、今使っているハードウェアではVistaはまともに動作しないので、新たにPC毎新調する必要がある事です。Vistaは去年のBeta2からRC1としばらく使って見ましたが、最低CPU 2GHz以上、メモリ1Gはないとつらい感じです。さらに、複数のアプリケーションを起動して色々するというヘビーな利用するのであれば、メモリは2Gないとつらいです。グラフィックカードもましな物にしないと…。

つまり、いまどきのCPUとメモリを買うー>マザーボードから丸ごと入れ替えー>新調した方が、となり、Vistaの為に一台買わないといけなくなります。今まで利用してたまったく問題のないPCをどうすれば良いのか、というのに悩むのです。まったく問題なくある程度満足しているPCと環境を捨てるのもどうかと思うし、開発環境として取って起きたい…。ノートはすでにXPのがあるし...。

ただでさえ、Windowsアプリ開発用Windowsマシンと、Webアプリ開発用Linuxサーバーに挟まれているのに、Vista用買ったら3方囲まれてしまいます^^ 排熱で茹で上がりそう。

こういう時こそ仮想マシンの出番なのですが、仮想マシン上では確かAeroとか有効にならなかったのでテストにならない上、仮想マシンだけの為にVistaのライセンスが1つ必要なのはなんとも無駄。

で、開発環境で使うマシンはどちらにするか…。個人的には、今までのWindows OSの中ではWindows 2000が一番堅牢でしかも軽い(余計なのがついてない)と思っていて、開発マシンは未だにそれなのです。いずれは移行しなければと思っていますが、なかなか捨てがたいのです、これが。

開発環境は主にDelphi7で行ってきました。しかしVistaではDelphi7は互換性がないアプリケーションに登録されていて、動くには動きますが後々問題になりそうなので、問題なく動くDelphi Studio 2006に移行する事も考えなくてはなりません。Delphi Studio 2006は既に持ってますが、開発環境を移行する、というのは開発者にとっては実はおおごとなんです。

また、エディタで有名な秀丸の開発者の方も、古いWindowsでも動くように、何世代も前の開発環境を使って開発しているらしいですが、私も同様にそういうのも大事だと思っています。

結局私は、Windos2000の起動さえもっと早くなれば、100%それで満足なんですよ!えぇ。

投稿者 BlogWrite担当 : 13:08 | コメント (0) | トラックバック

2006年12月09日

なにかNHKで..インターネットの匿名性について議論やってますが

議論自体は両方の意見を出しているのでOKですが、「免許制に」、「匿名をやめる」、「信憑性の無い情報は、削除させるべき」、「国が規制し、監視すべき」などの意見が普通に出てくるのが怖い...

やめて~、中国や韓国みたいになってしまう...orz  この番組を知った韓国の人が皮肉を込めて曰く、

インターネット匿名性問題 <- 韓国では簡単です!


1. すべての国民に個人別識別番号(住民番号)を生まれる時から与えます

2. インターネットサイトに加入する時は住民番号を必ず記入しなければなりません!

3. 誰か悪意性 threadをあげれば, 住民番号を問い合わせして簡単逮捕します!

これが韓国式デモクラシー, 言論の自由です!  誇らしいです!

追記:
うわ、番組の続きで、韓国のこの制度を「日本が注目している制度」とNHKが紹介した..orz

KBSという韓国公共放送の番組で「インターネットの魔女狩りは許されるのか」という番組があったという。では、国が行なう魔女狩りは許されるのだろうか? 参照:「親日反民族行為真相糾明委員会、「親日派」名簿106人公表」 。他にも情報倫理委員会が、親日的ウェブサイトを次々と停止している状況も同時に取り上げるべきでしたね。

言論統制や検閲を行なった時点で、どれだけ国民が事実無根の煽動に惑わされやすくなるか、韓国人と中国人そして北朝鮮の人たちと歴史討論してみればすぐ分かります。対して、情報を規制せずに、critical thinkingを重視する欧米特にアメリカ人と討論してみれば、何が重要かが分かるでしょう。

実名登録、監視、規制強化云々は、実際に沢山の人を殺している車、排気ガスを出して環境汚染をする車、今すぐ全廃すべき、と言うのと同じぐらいピントが外れている気がします。

投稿者 BlogWrite担当 : 21:11 | コメント (0) | トラックバック

2006年11月28日

第9回XML開発者の日

先週末に開かれた第9回XML開発者の日、行ってまいりました。

今回は、サンフランシスコの宮川さんと日本の会場を、二台のPCで結んだオンライン経由でのプレゼンをしていただくという稀有な事があったのですが、音質もクリアで思ったより良かったと思いました。微力ながらお手伝いしたのですが、録画するとかそげな余裕はございませんでした、済みません(笑)

そんなこんなで午前中は準備などで、落ち着いてじっくりと発表を聞いている余裕が無かったのですが、後半は沢山勉強させて頂きました。皆さんのお話を聞いているだけで、なぜか色々とモティベーションがアップするから不思議です。個々の内容について感想は一杯あるのですが、まとめ切れない気がするのでまたの機会に。

所で、コメントした内容で少し言葉足らずの所があったかもしれないので、例の、Webサービス認証に関して少し補足です。 もうかなり前になりますが、WSS認証の混乱については、こんな経緯があったんです(今は解決しているはずですが)=> ココログ Atom API の小さくて大きな問題

認証周りは色々大変ですね。 個人的には、Atom出版プロトコルでの挙動が標準的な流れになってくれないかとずっと期待してますが、もう決まるだろうと思ってたのですが、まだです...。また詳細に追っかけ始めますので、また何か出てきたらエントリに起こしていきたいと思っています。

ともかく今回は無事終わって良かったです。 ご協力いただいた皆様、この場を借りて多謝。

投稿者 BlogWrite担当 : 21:11 | コメント (0) | トラックバック

2006年08月24日

Gmailで致命的に足りない機能

ITmedia Biz.ID:Gmailまとめ

Gmailが招待制から登録制になったという事で(一般紙にも掲載されていましたね)この機会に前から気になっていた事を...

Gmailってスレッド表示出来なくないですか?

カンバセーション(会話)という括りで纏められるけれど、本来のスレッドの枝がバッサリとフラットになってしまって、会話がまったく追えないのでとても不便しています。特にメーリングリストの場合、スレッド内で個々のメールへの返答とかが誰から誰のどのメールへの返答だかまったく分からなくなる場合があってとても困ります。

誤解の無いように一応書いておきますが、Gmailは上記の一点を除けば素晴らしいメールサービスです。特にスパム判定率が高いので個人的なメールアカウントとメーリングリスト用のメールアカウントをすべてGmailに転送しているほどです。ただ、スレッド表示が出来るようになってくれさえすれば…

追記:
よく考えたら、Webメールサービスはもう5年ほど使っていないので最近の他のWebメールサービスではどうなっているのか知らないです。もしかして、所謂カンバセーションという括りすら無いのかもしれない(笑)

本来のスレッド表示(秀丸メール)
  thread.gif

投稿者 BlogWrite担当 : 11:44 | コメント (0) | トラックバック

GData API for Google Base

という事で、期待していた通り、Google Base APIが公開されたようです。

New GData API: Google Base
http://code.google.com/apis/base/

ただ、やっぱりGoogle Base自体がまだ内容的に欧米セントリックという所があるので、(というかGoogle Base自体日本語化されていない?)ちょっと残念ですが、このAPI公開は多方面で非常に意味があるなぁと思います。検索エンジン業界にとってもその他の分野でもこの意味は長い目で大きな影響がある気がします。

関連記事:
Google Base
不動産物件情報とXML(Google Base)

投稿者 BlogWrite担当 : 04:11 | コメント (0) | トラックバック

2006年08月17日

Google不動産検索

Googleのサイトを色々弄っていたら、Googleの試験用のサイト内で、潜在的な新サービスを見つけちゃったよ、という話。

What's in Google's Sandbox? 
日本語版画像

その中で、「Google不動産検索」とあったらしい。他にも「Google イベント」「Google Guess」「Google オンライン評価」「Google RS2」「Google Writely」「Mobile Marketplace」「SSD」「Weaver」「WiFi」「トーク」「ローカル ビジネス センター」等々14のサービス。

Google Baseでも簡単な物件リストを追加することが出来たがあくまでも超シンプルなリストの上にあまりインパクトが無かったです。不動産検索に特化したサービスが出てくるとしたら大歓迎ですね。

あまり一般には知られていないのだけど、日本では、不動産物件情報を公開するのに、一件につき幾ら、という感じでサイトにお金を払っています。

つまり、日本ではコンテンツを持っている不動産会社が、お金を払ってコンテンツを提供しているのです。そう、普通お金を対価として受け取ってコンテンツを提供したり、無料で提供して無料でサービスを受け取る、のとはまったくの正反対。

例えば、Yahoo!Japanに物件情報を掲載する事で、お金がYahoo!Japanに流れるわけです。そしてYahoo!Japanは物件情報をネタにして集めた閲覧者を対象にした広告を出して、別途広告料を広告主からもらう分けです。

さすがYahoo!Japan

Googleだったら普通に完全に無料で物件掲載するでしょうけど。

ブログでいうと、一記事掲載するのに700円払って、且つ広告が勝手に挿入されるというありえない状況。いつまで放置するのでしょうかねぇ...この状態。

投稿者 BlogWrite担当 : 16:59 | コメント (0) | トラックバック

2006年06月06日

波ダッシュ、チルダの件

ずっと昔からの問題となっていたわけですが、最近やっとチラホラと表舞台?で広く取り上げられつつある(というかそう期待している)波ダッシュとShift_JIS(CP932)の件なのですが...。

特に最近になって問題が表面化したのは、APIやRSS関連で、下記のようなケースが増えてきたからではないでしょうか。

(1)サーバー側でEUC-JPベースでデータを保存、または開発コードを作成。
(2)クライアント側がWindows(つまりShift_JIS)環境。
(3)両者のやり取りはUTF-8で行なわれる。

XML-RPCとかAtomAPIとかもろにこのようなケースに当てはまる事あ多く、実際BlogWriteでは以前から内部的に非常に美しくない様々な対処をしています。

■Livedoorブログ
「~」が「?」になってしまいます。ちょっと前までは、「~」が「〜」になってしまうだけで、少なくとも無理やり置換する事で対処出来ました。「〜」は普通にWindowsでは扱えず(左のは数値参照で表示させています)、「?」「・」「〓」に化けたりします。

ところが、いつの頃からかLivedoorブログ側で変更があったようで、投稿した段階かデータを取得した時点で既に「?」になってしまっています。これ BlogWrite側では復帰出来ない(本来の「?」と区別がつかない)感じ。

■Seesaaブログ
ちょと前まで、livedoorブログと同じく「~」が「〜」または化けた状態になってしまっていた。

という事で、仕方がないので、両者に対応するため、「~」をBlogWrite側で事前に、数値参照「&#65374;」に置換して送信していました。 所が、Seesaaブログでは何時の頃からか、「~」が表示されないという現象が起きるとの報告を最近ユーザーの方から頂きました...。数値参照を表示させない仕様になったようです。理由はわかりません。しかし、「~」自体は化けることはなくなったので、これに関しては内部で対処されたのでしょう。

という事で、Livedoorブログでの問題に対処しようとすると、Seesaaブログで問題が... Seesaaブログも数値参照を非表示にするなんて意味わからない...。

もうお手上げ状態。

大体において、Perlの例えば、Jcode.pm等を素で使ってEUC-JP <=> UTF-8変換した日本語をWindows環境で読み書きしたりすると化ける訳で、私の場合、Danさんには本当に申し訳ないですが、2年ほど前から自分が開発するPerlのアプリでは一切Jcodeの利用を取りやめ、代わりにUnicode::Japaneseを利用させてもらっています。

Jcode.pm等をメンテされてこられた開発者の立場のDanさんの仰っている事は100%納得できる訳で(対処しろとか言うつもりもまったくないです。Jcodeが悪いわけじゃないですから)すが、利用者としてはより実際問題として問題の起きない方を利用したい(して欲しい)となるのも同様に御理解いただきたいところであります。

なので、Livedoorさんも化けない方法を模索していただきたいなぁと思ったりしています。

関連リソース
http://www.kawa.net/works/jcode/uni-escape.html
http://as-is.net/blog/archives/000735.html
http://ja.wikipedia.org/wiki/%E6%B3%A2%E3%83%80%E3%83%83%E3%82%B7%E3%83%A5
http://www.asahi-net.or.jp/~wq6k-yn/code/wavedash.html

投稿者 BlogWrite担当 : 18:43 | コメント (2) | トラックバック

2006年06月01日

クロスプラットフォームでのアプリケーション開発のまとめ

アプリケーションを開発、頒布していると、たまにMac版はありませんか?とかLinux版は?といったお声をいただきます。ですが、現実は中々難しい所があって、往々にしてそれぞれのOSにあわせて一から作り直すぐらいの労力がかかります。

しかし、やはり多環境向けのソフトウェア提供というニーズは以前からあり、特に最近になって要望が増えている気がします。そこで、最近の状況をちょっと調査してみました。ここでは、Windows、Mac、Linux上でのGUIアプリケーションについてのみ扱います。フォームがあってボタンをクリックしたりして操作するアプリケーションのことです。

wine - Linuxなどの環境で、Win32アプリケーションを動かす。Win32API互換を目指している。

BlogWriteを含む一般的なWindowsアプリケーションは、Windowsに用意されているWin32APIを直接・間接的に叩いて動作します。wineはそのWin32API環境を用意することによってLinux上などでWindowsアプリケーションを動かすものです。

wineの完成度はかなり高いのですが、Win32APIすべてに対応しているわけではなく、対応されていない部分も多いです。ですが、試しにシンプルなアプリケーションを作って、wineで動かして見たら、ちょっと見た目が崩れる所もありましたが普通に動きました。動かない代表的な例として、IEコンポーネント(MSHTML)を利用したアプリケーション(BlogWrite含む)は使えません。WinInet(インターネット通信)周りも動作がかなり微妙。その他地雷多数あり。

結局、一部のアプリケーションしか完全には動かないのと、wineで動かす事を考慮に入れつつ開発しなければならないという制約が出てきてしまいます。その上、wineで動かしても、ネイティブな環境の動作や見た目(テーマや外観)からするととても違和感があります。MacOSX上でWiindowsアプリが動いている感じ。最近出たLinux向けPicasaなんかはかなりの出来だけれどもやっぱり一部機能は削ってあるようですね。

上記の制約をクリアすれば、とりあえず動作させることは可能ですが、ちょっとした修正で動くものでない限り、あえてwineを選択するのは現状ではお勧め出来ない感じがします。

Java - かつてwrite once run anywhereと喧伝されたが...

Javaで開発されたアプリケーションは、

1)大きなJavaランタイムをダウンロードして入れなきゃ動かない。
2)GUIアプリは動作が重い(ネイティブウィジェット使っても)。
3)見た目に違和感がある。
4)Javaランタイムのバージョン違いで動かなくなるとか、
5)他

など、色々あって、Javaで作られた一般向けデスクトップアプリケーションにはほとんどお目にかかったことがありません。というかよく使われるJavaアプリでは開発用のIDE、eclipseぐらいしか個人的には聞かないかも...。

.NET/mono - マイクロソフトが推し進めるJava対抗路線。複数言語による共通ランタイムによるアプリケーション実行環境。

伏兵。もしかしたら将来的に、一番可能性があるかもしれない。けれども...

現状では、.NETを利用する意義はほとんどない感じです。.NET上じゃないと出来ない事っていっても特にない(文字コード周りがすっきりしているのが一番の利点、とかぐらい?)ですし...。(もっともVB6とかで業務アプリ等を使っているなら.NETに限らずどれかに移行した方が良いけれど...。)

1).NETランタイムをダウンロードしてインストールしなければならない。
2)ネイティブのアプリケーションと比較してやっぱり動作がもっさり。

上記二つは時間が解決する感じです。次期WindowsのVistaが出てくる頃には、上記の問題は無くなっているとなると、複数言語で共同開発出来るのと、ランタイムさえあれば何所でも動くという利点が急に光って見えてきます。

そこで登場するのが、monoです。monoはNovellが中心となって勧めている、Linux(+MacOSX)環境での.NET環境(ランタイム)で、既に最近のLinuxでは実用的に使われています。例えばSuSEでは、デフォルトでmonoが入っていてパッケージ管理やらデジカメ画像管理ソフト音楽プレーヤ等々mono上作られて動くアプリケーションが幾つもバンドルされています。

つまり、純.NET向けのアプリケーションであれば、今後WindowsとLinux環境(あとMacもか...)で違和感なく簡単に動作するようになる可能性大、と個人的に感じました。但しmonoが頑張ってくれれば、の話です。現状、GUIデザイナーの出来がまだまだなのと、Windows.Formsの扱いや複数言語のサポートなど、まだまだの所があります。あとIEコンポーネントの代わりにMozillaエンジンをどれだけシームレスに扱えるのかとか個人的に興味あり。

ただ、速度や機能を求めて.NET外のネイティブ機能を利用したくなるものですが、それをしたとたんクロスプラットフォーム性がなくなるという制約もありますが、ある程度は仕方が無なくて、コンパイラスイッチみたいなので対応するしかないのかなと。

Linux上でのRAD環境が無いと言っていい現状、monoとmonodevelopによってLiunx上でのアプリケーション開発容易になるというキラーアプリな感じ...。ただ、現状各環境に合わせたUIの切り分けがイマイチはっきりと見えないのが残念。

Python - 地味に使われてたりする

Pythonには元々GUIライブラリというかウィジェットは無い感じなのだけど、好きに選んで利用出来るというもので、幾つか個人的にも使ってた事もあるクロスプラットフォームのJuiceとかPythonで作られてました。ただやっぱり各プラットフォーム毎に作リ直す作業は膨大なもの。

あと、個人的には..Pythonという言語的には好きな系統なのだけれども...Delphiの洗練されたコンポーネント指向の開発に慣れているとあえて手を出しにくい感じが...。

Delphi/Kylix

元々本命と目されていた?Delphi言語によるクロスプラットフォーム向けの開発ですが...ボーランドがLinux上でのKylixというIDEの開発をパタっと止めてしまっていて頓挫中。物凄く可能性があるんですけどねぇ。

Delphiという言語+VCL(ビジュアルコンポーネントライブラリ)は、Cの柔軟性と、C++のオブジェクト指向と、VBのコンポーネント指向を合わせた感じの開発言語、IDE、ライブラリ環境です。ただ、最近ボーランドによる、Delphi Studio等IDE関連の再編でゴタゴタしています。いっそのこと、NovellあたりがKylixだけでも買収して欲しいなとか密かに希望してたりします。

一応、Delphi互換のフリーの実装として、Lazarusなんてのもあります。Linux上では元祖RAD環境と言って良いかもしれません。Write once compile everywhereって事で、とりあえず、Mac、Windowsでも動くようです。でもKylixの方が良かったと個人的に思うのでまだ手は出してません。Lazarusもやっぱり動きの速いLinux環境に対応していくのに苦労している感じです。

Xul - Mozillaのツールキット
FireFoxとかのやつ。XULrunnerを使えば単体で動くクロスプラットフォームのアプリケーションが作れる、らしいですが、本格的なのは微妙かもしれません。詳しくは触っていないのですが...。

以上、クロスプラットフォーム向けのアプリケーション開発の現状簡単なまとめでした。

一言でいうと、ずいぶん進んだけれど、まだあと一歩かなという所のようです。ただ、実感したのがLinuxの勢いです。個人的にはとても注目していますが、逆に進歩が早すぎて逆に対応が難しかったりします。Macも旧Mac9からMacOSXで*nix系に移行して直ぐにIntelのCPUに移行したりで大変そうです。そんな中で、意外に.NET/monoが色々な違いを吸収できる可能性が一番大きいのでは、と感じました。もっとも余裕であと数年は必要かと思いますが..。

そんなこんなで、もしかしたら仮想PC、特にVmwareやXenなどを使って、OSの中で異なるOSを動かすという形が一般的になって一気に解決してしまうかも知れませんね。vmwareの完成度はもうまったく素晴らしい出来で、Linux上でWindowsを動かすなんて事が簡単に出来ます。まったくもって、どう転ぶのか分かりません。

susewin-ss.png左の画像は、SuSE Linux上でSuSE LinuxとWindows 2000が同時に動いている所。複数のバージョンのWindowsを動かして動作テストや英語版を入れて国際版の開発、はたまた仮想ネットワークを作って負荷試験など色々使えそうです。一昔前は何台も実際のPCを使ってテストしたものですが...便利になったものです。


 

投稿者 BlogWrite担当 : 03:11 | コメント (1) | トラックバック

2006年03月06日

Trackback標準化の件

昨日のことなのですが、このブログに対して短時間の間に80件もの(英語の)トラックバックスパムを受け、その後も数時間に渡って続き、総数100件以上に達しました。

1日の内にこんなにまとめてTrackBackスパム攻撃受けたの初めてです。サーバーにかかる負荷を考えただけでゾッとします。(ロリポップサーバーよく頑張ってるなぁ)
もちろん、とりあえずの対策で、「言及なしTrackBackを拒否する」プラグイン(NaoyaさんThanks)を入れてますが、どうもそれも看破されたようです。やはりこのブログもMovableType3.2にアップデートする潮時かもしれません。問題はその時間が取れないという事なのですが...。

そこで、ちょっと前のTrackBackの標準化の件に改めて注目して見ました。

SixApartのTrackback規格をIETFの下でワーキンググループ作って、標準化しようという事で、企業の姿勢としてもとても素晴らしいと思います。だって、例えば某企業とかだったら、スパム対策用に別途有料ソフトを導入するように、なんて売り込みかねないですが、そうではなくオープンに議論して解決策を探るというのは評価すべきと。

で、ここら辺で、現状のドラフトとかを見れます。
http://www.lifewiki.net/trackback
メーリングリストにも参加してみました。

あまり詳しく読んでないけれど、ドラフト仕様では、国際化の件(文字コードの指定)が含まれているのが大きいですね。
あとAutoDicoveryの方法が増えて、RSSやAtomと同じ形式

<link rel="trackback"
           type="application/x-www-form-urlencoded"
           href="http://example.org/trackback-url" />

も使えるようになってます。
IDもAtomチックな表現になってます。

現在議論中の案は、
*TrackBack送信結果の取得を標準のHTTPのステータスコードを使うなど、Atomを参考によりREST風にというかよりシンプルに、とか、
*送信元を見に行って言及リンクがあるか判定する
*TrackBack仕様のバージョンを指定出来るように
などがあるみたいです。

現在のドラフトやIssuesListを見ても特に具体的な認証方法とかについてはまだ言及がありません。大雑把に「HTTPの認証を活用する」といった程度で、後は「モデレーション」とか「IPアドレスでBlackList」とかの対応についての言及があります。でもHTTPの例えばBasic認証かけても、TrackBackの送信先毎にユーザ名パスワードなんて覚えてられないのであまり現実的ではないなぁと。

OpenIDとかTypeKeyが活用できるようになると良いと思って、出来るだけ標準化には参画していきたいと思います(と言いつつ、Atomワーキンググループの方も時間的に今は追っかけるだけで精一杯ですが^^;)。

個人的には、送信者のTypeKey等のOpenなIDが必須で、IDがBlackListに登録されていない言及ありTrackBackのみ受け付ける、とかの指定がしたいなぁ。それかキューに溜め込んでのモデレーションとOpenIDやTypeKey等のIDによるBlackList管理がベストかなと思います。IPアドレスのBlackList管理はあまり効果的ではないと思います。ダイアルアップなんか特にそうだけどIPアドレスはコロコロ変わるので意味ないですし、無実の人も弾くことになるのが落ちのような気がします。

でも、TypeKeyをTrackBackの送信に使えるようにするには、ここで書いたような事なども解決し無ければならないのかもしれませんね。一筋縄ではいかなそうだ...。

投稿者 BlogWrite担当 : 17:39 | コメント (0) | トラックバック

2005年12月28日

気が付けば

物凄く間が空いてしまいました。気が付けば今年も残す所あと数日です。気分が乗らないから...とかではなく、文字通り書く時間が取れない状況が続いていて非常に残念です。

これではいけない、という事もあって地道に一緒に働いてくれる人を探していたのですが、今月から(まだフルタイムではないですが)一人、加わってくれることになりました。実は私の高校時代の友人だったりするのですが、しばらく前に個人事業主になった、との連絡をもらい、密かに狙っていた人材でした。即戦力になってくれているので非常に心強いです。

と同時に、この暮れの時期に、色々な非常に興味深いオファーを各方面から頂いていて、会社としても年明けから階段を一つ二つ上がるステップアップの予感がします。来年からは、新体制で、飛躍の年になるように頑張りたいと思いますので今後とも宜しくお願いいたします。

年末年始の方が逆にブログを書けるかもしれないので、ご挨拶は抜きで(笑)

投稿者 BlogWrite担当 : 13:51 | コメント (0) | トラックバック

2005年12月10日

[フィードとは] 日本語版作りました

 かなり前になりますが、http://xml.feeds.jp/ というドメインを個人的に勢いで取っていたのですが、特に使い道が見つからず、ずっと寝かしたままになっていました。で最近、IE7でWeb Feedsという名称を使うとかなんだかで、注目されてきて、何か有意義な利用方法がないかとずっと思っていたのですが、時間も無いので放置してたという訳です。

で、本日仕事でMT3.2のブログのテンプレートを弄っていたら、下のような[フィードとは]というリンクがあって、RSSやらAtomフィードの説明リンクがありました。ところが、リンク先が米SixApart社のサイトのページで当然ながら英語です。

このブログのフィードを取得
[フィードとは]

これでは親切ではありません。ちょっと検索しましたが、中々適当な替わりのサイトが見つかりません。そこで、 http://xml.feeds.jp/ に、サクッと作って見ました。もし同じようなことで悩まれたことがあればご自由にご利用ください。

まったく個人で保持しているドメインなので、商業サイトとして利用するつもりもありません。無保証ですが、大した維持費用もかかってませんので、近い将来急になくなるとかはありませんし、他の用途に用いる予定も今の所まったくありません。

内容的なフィードバックは、とりあえずこのエントリのコメントでお願いいたします。

投稿者 BlogWrite担当 : 17:09 | コメント (3) | トラックバック

2005年12月04日

サポートについて

お陰様で色々とお問い合わせを頂くことも多くなり、サポートもサポートフォーラムが大活躍しておりまして、Google Analyticsをみても、サポートフォーラムへのアクセスが結構ある事が分かっています。

そこで、今後一般公開するソフトウェアの種類も増えそうなことも踏まえ、現在のフォーラムからXoopsを使ったシステムに移行することにしました。今ここらへんで作業中です(まだ使わないでください、出来たらまたお知らせします)。

PhpBBとかも検討しましたが、XoopsのサポートBBS(正確には、モジュール)が高機能で、結構気に入っています。しかし、このフォーラムでは、ユーザー登録をしなければ書き込めないので、現状よりちょっと敷居が高くなってしまいます。もっとも、広告スパムを書き込むアホが存在するので、ユーザー登録も仕方がない所として御理解いただければと思います。もちろん現状どおり、ソフトウェアの購入ユーザーのみの対象ではなく、全てのユーザーを区別することなく対応します。

弊社のソフトウェアサポートに関しては、基本的にかなり誇れるものであると思っています。パッケージソフトなどにおいてはサポートすらない場合もありますし、問い合わせても定型の返事しかこないことがあります。弊社では、メールでのお問い合わせにも、サポートフォーラムでのお問い合わせにも、基本的にそのソフトウェアの開発者自らが対応します。中々そうそう普通じゃできることではないのではと思います。(「はてな」とかはもっと凄いけど、あそこぐらいでしょう)

最近これが逆目にでて、サポートの対応だけで、半日以上潰れてしまう事が多々ありまして、開発にも支障をきたしかねないところがあるので大変です。かといってサポート人員を増やせばよいかというと、単に増やしても、サポートの質の低下、開発者へのフィードバックの低下など良くない現象が発生します。それに、開発者ならその場で判断できる事も、単なるサポート人員だと、数十倍の時間がかかったりして効率も悪いです。これは一般的にいって、ユーザーの数が一定の割合を超えると、基本的な質問はユーザーの方同士でのやりとりなどが発生して楽にはなると思います。なのでサポートを閉じるのではなく、システムを充実させる方向で動いています。

いずれにしても、ユーザーサポートフォーラムは、開発、メンテナンスをする上で大きな原動力になっているので、大事にしていきたいと思います。

投稿者 BlogWrite担当 : 21:43 | コメント (0) | トラックバック

2005年12月01日

なにげにはてな検索

今日公開された、はてな検索というのが何気に凄い。同じく今日、日本版公開でやっと日本語化されたYahoo!検索WebサービスのAPIを利用しているらしいのだけれど、検索結果のページそれぞれに「はてなブックマーク」で何人登録しているかが表示され、クリックすると、コメント等が見れること。

これにより、より精度の高い(より多くの人に実際に役立った)検索結果へ素早くたどり着けます。

凄い

これぞ集合知を利用した、というか、ここ(ソーシャルブックマークについて)で言っていた事が少し現実化したのがとても嬉しい限りです。

これは是非、Google版でもやって欲しい!(Google の場合APIの利用回数に制限があるから今は無理か...)

因みに、Yahoo!検索WebサービスのAPI解説は、 下記ムックで解説されています。本家米国Yahoo!のを元にしています。日本のは幾つか機能を削ったものになっているようです。(CCライセンスの指定とか、地域検索とかニュース検索とか...)

最新WebサービスAPIエクスプロ-ラ ~Amazon、はてな、Google、Yahoo! 4大Webサービス完全攻略
Software Design 編集部
技術評論社 (2005/09/23)
売り上げランキング: 6,326

投稿者 BlogWrite担当 : 23:09 | コメント (0) | トラックバック

2005年11月16日

続Google Analytics:90対8

tm_Untitled-1.gifこのサイトのアクセス元の概要を見ると、全体では、42%がGoogle、26%が直アクセス等、5%がはてなブックマーク、5%がbloglines、Yahooは3%、その他。

検索エンジンでいうと、90%がGoogle、Yahooが8%、MSNが2%

この結果から、Yahooが弱いからYahooにもっと注力すべきなのか、Googleが効果あるからGoogleを重視すべきなのか...。一般的には、既に効果のあるGoogleをより重視、という事なのでしょう。 (もっともこのサイトでは広告とか打つ必要性を感じないので、以前からログとかあまり気にしていなかったり...)

しかしYahooよりはてなブックマーク経由の方が多いとは...。

日米の検索エンジンシェアというページによると、米国では圧倒的にGoogle(*1)、所が日本ではYahooのシェアが高いという結果(最近では日本でも肉薄しているという調査も)。そこで、なぜGoogleではなく、Yahoo! JAPANか?:「Google は実利を優先する、ITリテラシの高い層に支持されている」という事が見えてきます。

では、一般サイトだとこの90対8という比率がどうなるのか、というのは近く普通の企業サイトでの結果を見てみたいと思います。

(*1)実際Web2.0カンフェレンスで普通のアメリカの高校生がYahoo嫌い、利用するのはGoogle、と口をそろえていっていた。

因みに、ブラウザはIEが61%、FireFoxが30%、Opera、Safariが3.8%でした。
 

追記:
アクセス元地域でいうと、アメリカのCupertino(シリコンバレーに位置し、米Appleの本社の所在地)や、Redmond(米マイクロソフト本社の所在地)とかからのアクセスが地図上に表示されていて面白すぎる。 これは英語版のサイトを作れという事だろうか...作らないけど。

 

追記2:
どうしても一言。本当に重要なのは、アクセスに一喜一憂する事ではなく、目的意識をしっかりと持ち、それを見失わないようにする事が重要だと思います。

投稿者 BlogWrite担当 : 19:09 | コメント (0) | トラックバック

2005年11月14日

Google Analytics使ってみる

すごすぎ。またGoogleがやらかしてくれた。Google Analytics。(ニュース元:こことかここ

GoogleAnalytics.gif

嬉しいのは、経営者向けと、マーケティング担当者向けとウェブマスター向けのレポートがあること。たすかりますね。

驚いたのが、「サイト上のデータ表示」でiframe内に実際のページが表示されて、リンク上にマウスをもってくると、クリック数から平均スコアとか出る。(追記:リンクがたくさんあるページだとFireFoxが固まるかも^^;)

アクセス元の地図上の位置も出てくる。これはIPアドレスを元にしているのだと思われ。

もちろん、ブラウザの種類や画面解像度、OS種類、等々もあって、サイトごとに「このサイトではMacIEは切り捨て!」みたいな決断も出来る。

目標到達プロセスのナビゲーションってナニヨ、見たいな感じですが、後で勉強します。

マーケティング的にも、(CPCってナニヨってのはナイショ)キーワードのアドバイスってのがぱっと見嬉しい。

うちのお客さんにはぴったりなので勧めてみたいと思います。

ログ解析とか専門の会社さんは大打撃だろうな...。

追記1:アクセスが集中しているのか、12時間以上過ぎた今もまだレポートが表示されず。一時アクセス出来るか出来ないかもちょっと怪しかった。

追記2:48時間以上経ちましたが、まだ「データの待機中」となっていました。ところが構わずレポートの表示をさせると、おおっ、データが表示されています。

追記3:なぜかはじめの2日分しかデータが表示されずにいると思ったら、下記の表示がされていました。

The demand for Google Analytics surpassed even our highest expectations and as a result some customers may temporarily experience report-update delays. All data continues to be collected and no data has been lost. We are currently adding resources to ensure high-quality service. We apologize for any inconvenience.

Google Analyticsへの要求が私達の想定の上限をもはるかに上回っており、現在一部のお客様のレポートの表示遅延が発生しております。全てのデータは収集され続けており、データのロスはありません。現在ハイクオリティなサービスを提供すべくリソースの増強をしています。ご不便をお詫びいたします。 (いいかげん訳)

安定するまでしばらく様子見です。

投稿者 BlogWrite担当 : 15:04 | コメント (2) | トラックバック

2005年11月10日

デスクトップアプリケーションの将来:Desktop2.0

Web2.0には相反する二つの感情を抱いています。一つは盛り上がるのは全体にとって良い事だし、共鳴する点も多い、というのと、一方では一部の用語(AJAX)などがhypeとならないかという心配もあったりします。しかし、私としてはそれよりももっと気になる点があり、前々から気になっていたことがあるので少し詳しく書きたいと思います。

最近のWeb2.0という流れで、デスクトップソフトウェアは時代遅れ、過去のもの、といった風潮が広がっている気がしています。しかし、私は全体的にいってデスクトップソフトウェアの重要性はまったく減少していないと思うのです。

オライリー氏自身なども言っているように、Web2.0は既成のデスクトップの焼き直しをWebに移すのではなく、Webの特性を最大限生かした新たなサービスを生み出す原動力となるものだとすると、デスクトップアプリケーション、ウェブサイト、ウェブアプリケーション、ウェブサービスそれぞれの重要性の比率は変わっていないはずです。

相対的に言って、新たな分野の開拓という点で、ウェブ系アプリケーションに可能性と開拓の余地が増えているというだけであり、デスクトップアプリケーションの重要性と利便性はまったく以前と変わっていない、と前から感じています。

これを言うと、デスクトップアプリケーションを販売しているからそういうのだ、というご意見を頂くかもしれませんが、私の仕事の内、デスクトップアプリケーションの開発とWebサイト、Webアプリケーションの開発は半々です。両方フルでやっています(どっちも中途半端だけど)。 ですから、もしかしたらほとんどの方よりも、客観的に見れる立場にいるのかもしれません

実際、オライリー氏曰く、Web2.0らしさを最も体現しているのはiTunesであると指摘しています。ご存知iTunesは、EC Webサイト、iTunes(デスクトップ音楽プレーヤソフト)、iPodの三つがインフラとなっており、デスクトップソフトウェアも重要な役割を果たしています。

困惑したのが、多くの人がAJAXでOpenOfficeアプリケーションをWeb版で動かす、という事を期待している様子が見受けられた事です。既存のデスクトップアプリケーションを単にWebに移植するというのはほとんどの場合、無理です。無理というのは、中途半端な「モドキ」になってしまうか、お遊びでやってみたものであり、実際の使用(業務等)には多大な不都合が起きます。 (注:AJAXを否定するものではまったくないし、使い方によっては素晴らしいものだと思う)

その理由には沢山の問題(セキュリティの問題、ブラウザの制限、非互換性、ユーザーの習慣の問題、ネットワークの信頼性、プライバシーの問題、UI、ユーザビリティの問題)ありますが、何よりも、業務で使われるソフトウェアにおいては、OSでのデフォルト動作(ルック&フィール)にあっている事が予想外に重要なのです。これはデスクトップ市場におけるJavaの失敗を見れば分かると思います。

いかに優れたWindowsのソフトでも、そのままMacに(例え可能だととして)移植してもMacユーザーは誰も使わないでしょう。使いづらいからです。また、そもそも大抵のデスクトップアプリケーションは、OS固有の便利な機能を利用するために、ブラウザからは利用できない様々なシステムAPIを利用し機能性と利便性を高めています。

ユーザーがこれらの機能を求める限り、デスクトップアプリケーションの役割と重要性は変わらないでしょう。

Web2.0の観点から今後のデスクトップアプリケーションに求められることは、API等を活用し、よりWebとの密接な連携を意識していかなければならない、という事だと思います。次世代のデスクトップアプリケーション開発、Desktop2.0。

Desktop2.0では、Web2.0と重なる点が多々あると思います。データは重要です。ただ、2.0も何も、もともと多くのデスクトップ業務ソフトはデータの管理のためにあると言っても過言ではありません。今後はデスクトップアプリケーションが保持しているデータをDesktop内だけにとどめて置くのではなく、選択的に限定されたデータのみをWebへと流し込んでいくという役割を担っていくと思われます。

例えば、OpenOfficeをフロントエンドとし、OpenDocumentをフォーマットとしたデータの注入が起こり、そのウェブデータを利用したサービスの登場とか。

Desktop2.0 コアコンピタンス
・パッケージソフトウェアではなく、オンラインソフトウェア:ユーザーの反応をダイレクトに受け取って機能に反映。
・プロプラエタリーなファイルフォーマットではなく、オープンなフォーマット(例:OpenDocument):データソースの確保の方を重要視。
・ベータ版の公開と試用版の公開:(現状では試してから買える業務ソフトは少ない)

最後に、将来的にデスクトップアプリケーションの足元をすくう可能性がある事といえば、Web2.0等ではなく、足元のOS自体の分断と多様化にあると感じています。

現在のWindowsネイティブなソフト、Vista以降の.Net、最近人気のAppleのMac、そして私自身も使っているLinux、さらに言えば、モバイル。今後これらのOSにユーザが分散していく事が十分考えられ、特定OSのターゲットユーザー数の低迷、または複数OSサポートの負担、などが問題となってくるかもしれません。

実際のところ、現在でもこれらに嫌気を感じて、Web系が大きく取り上げられているという事もあるのではないかと感じています。しかし何度も言いますが、オライリー氏が言う「プラットフォームとしてのインターネット」を文字通りとって、これからはWindowsなどのOSとデスクトップアプリケーションにとって変わって、Webアプリケーションなんだ、という風にとるのはちょっと違うのではないかという事は述べておきたいと思います。

Web 2.0:次世代ソフトウェアのデザインパターンとビジネスモデル
Web 2.01: It's a mistake to rule out the desktop

投稿者 BlogWrite担当 : 09:08 | コメント (0) | トラックバック

2005年11月06日

XML開発者の日:パネルのお題目

先日お知らせした、第八回XML開発者の日ですが、最終セッション4にてパネルディスカッションが設けられています。

そこで、このパネル討論での題目を皆さんから募集しようという事になりまして、担当を任せていただいたので、下記ページ
http://xml.feeds.jp/
にフォームを用意いたしました。ご協力いただけると幸いです。

分かる範囲でトラックバック打ちましたけれど、不公平感のないように参加者の方などでブログをお持ちの方は、この件について言及していただくと助かります。

PS.
というかドメイン、カッコ良くないですか?ないですかそうですか...

投稿者 BlogWrite担当 : 14:01 | コメント (0) | トラックバック

2005年10月26日

Google Base

ぐはぁ...。ここで、ちょっと大風呂敷広げたかな、なんて思っていたら、数日もしないうちに、こんなニュースが..

ユーザーから「売却する中古車のリスト」などの情報の提出を受け付けて検索データベースに加える「Google Base」の存在が明らかになった。

 10月25日に一時的に公開されたbase.google.comのページによると、Google Baseでは、ユーザーはGoogleの検索データベースに情報を提出できる。  このページでは、Googleはユーザーが提出できるコンテンツの種類として、...(中略)...価格や不動産の種類、写真などの情報を入力するフォーム――おそらくは、賃貸あるいは売却する不動産の目録を掲載するためのフォームだろう――を含む別のGoogleページの画像が掲載されている。

[WSJ] Google、案内広告サービス「Google Base」をテスト

 『コンテンツ所有者が簡単にGoogleにコンテンツを送信できるようにする製品の初期段階のテスト版』という事でここ何年も個人的に注目してきたことに近いので、Googleがどれほど本気か分からないけど、とっても注目。

公開後しょっぱなは難しいとは思うけど、APIでCRUD出来ると最高ですね。多分やるんじゃないかと、むちゃくちゃ期待しちゃいます。 以前書いたように、多数のサイトからアグリゲイト(収集)するのもありだし、APIで投稿出来るようにするのもありなんで、楽しみ。とりあえずファイルから追加は出来るという噂も。

しかしこういう風に、期待させることをやってくれる所がGoogleの魅力ですね、やっぱり。日本のYahooは期待しても無駄っていうか。

追記:

 『特定のコンテンツに関しては、もはやクローラーの時代ではなくなったのだろうか』
グーグル、「Google Base」の実験開始--イーベイと衝突の可能性も

そういう事かと思います。ゴミが増えすぎたのと、金額が関わってくるコンテンツの場合は特に。

 『典型的なユーザーは手間をかけて素材を直接Googleに送るのだろうか』

一般的に言って現状多くのユーザーは実際、無駄に手間とお金をかけてやっている。けれど、この先にあるのはAPIだろうと、思ったりしてます。

投稿者 BlogWrite担当 : 11:18 | コメント (0) | トラックバック

2005年10月14日

ライブドアがフランチャイズ不動産事業参入、不動産とRSSエトセトラ

なになに...。 ライブドア不動産が不動産仲介フランチャイズ(FC)事業開始

加盟店と顧客の双方に利便性の優れた弊社FC加盟店を通した不動産取引が増加することでが業界自体の改革および活性化につながるものと考えております。

ITと不動産業界、という点ではかなり詳しいつもりですが、ライブドア参入という影響は注目したいです。「業界自体の改革および活性化」という所がとってもステキです。個人的経験からすると、エベレスト級に大変そうですが、彼ならもしかすると....。と期待しつつ、その前にここの内容の充実が先ではないかと思ったりする。

というか、レインズなど化石時代の代物を一度解体して、ライブドアに発注して1000分の一の値段で、100倍マシなのを作り直してもらえば良いのに、とココロの中で思ったのはナイショです。

冗談はさておき、今朝がた、不動産物件検索エンジンCGI公開を書いたばかりですが、開発しながら思った事が沢山あって、例えば、大抵の不動産会社は現状、自社サイトと各種ポータルサイト、 不動産ジャパン(国交省外郭団体+業界団体運営サイト)、アットホーム、ホームズ、アドパーク、イサイズ、等々様々な場所に大抵はお金を払って物件情報を自分で登録するなどして公開している訳です(場合によってはFaxとか営業マンが足で回って集めてる)。さらにはレインズもありますが、これは物がまったく違うので別とします。

やって見ると分かると思いますが、入力作業は何気にかなり面倒です、コストもかかるし。理想は一度入力したら、あとは良きに計らえ、というものです。しかもコストをかけずに。

どうするかというと、例えば、個々の不動産会社が自社サイト上で、XML形式(またはマイクロフォーマットでも何でも標準化されたフォーマット)で物件情報を認証付きで配信し、アットホーム・ホームズ・不動産ジャパン、(ライブドア不動産でも良い)等のポータルサイトが、登録した個々の不動産会社のサイトから(RSS・Atomフィードを取得するのと同じように)物件情報を取得して、物件情報を取り込めば、個々の不動産会社は自社サイトでの物件情報だけ管理すればよくなるはずです。物件情報の内容が更新されたら更新Pingの発射です。

またライブドア社と協業で不動産の物件データにフィットするRSSデータ形式やアフィリエイト広告ビジネスとの連携などの研究に着手する。

なんて事がさらっと書いてあった記事もあって、良ければお手伝いしますよ(笑)

つまりこれは実質、現状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) | トラックバック

2005年08月04日

iTMS アフィリエイト Webサービス APIを希望

思いっきり仕事の途中ですが、iTunes Music Store Japanが登場しましたね。

そこでなんですが、ブログの各エントリーに、このようなiTunesボタンを付けたい場合ってiTunesのCOM APIやWebサービスで何とか出来ないんでしょうか。いや、というのもBlogWriteのNowListeningプラグインというのがあるのですが、単に曲のタイトル・アルバム名・アーチスト名だけをエントリに挿入するのではなく、上記のページにあるように、ボタンのワンクリックで視聴、ショッピングカートに入れて購入まで出来るようにしたいと思うわけです。

今の所アフィリエイトのように何かしらのインセンティブがないのはちょっとアレですけどぜひ 追記:iTunes アフィリエイトプログラム発見!残るはAmazonのような WebサービスAPIですね。linkshareという所と提携しているようですが、WebサービスAPIは未提供の模様、とても不便。これではamazletのようなサービスも作れないし、BlogWriteのプラグインにも出来ないです。Appleさんにはぜひ(技術力あるのだから)自前でトライしていただきたいなと思ってみたり...。

関連:ブラウザーからiTMS内を検索するiTunes Link Makerも日本版に対応

投稿者 BlogWrite担当 : 16:05 | コメント (0) | トラックバック

アクセス数という指標の曖昧さ

この三ヶ月、このサイトへのアクセス数はおかげさまで順調に倍程度増えている訳ですが、そんなことをチラッと人に話すと、「で、いくつなんだい」と数字を聞かれるんですよね。このいわゆるアクセス数、とんでもなく誤解される事が多くて以前から問題だと思っていました。

単に(あくまで例えば)月間9万アクセスがあります、というと、人によっては「ほう、9万人が読んでいるのかっ」と言われてしまうからです。知っている人は知っていると思うのですが、単純にアクセス数といっても何のアクセス数かどう解析したかによって数字はどうとでもなってしまいます。9万アクセスがあっても実は一人の特定の人間しかそのサイトを見ていないという事もありうるのです。

そういった知識のない方に単なる数字を話すのは、わざとうそをついているようであまり気分がよくありません。かといって数字を言わない理由を説明しようとすると、「これだからパソコンやってる奴は理屈だらけで...」と言われてしまい、とても凹みます...。単純に正直に話そうと思っているだけなんですが...。正直ものは馬鹿を見る...。

アクセス数といっても色々あります。(それに詳しい人はアクセス数とリクエスト数は違う、と言うかもしれませんし、ページビューというのもユニークIPとか色々あります)

ファイルへのアクセス(ヒット)数。
一ページのHTMLには場合によっては数十以上の画像やCSS、JavaScriptファイルが埋め込まれていて、一ページ読まれただけで、数十のアクセスが発生します。

フレームのページ。
フレームによってページを分割しているページ(これ自体アクセシビリティ最悪で非推奨だけど)の場合。例えば左、上、右に3分割している場合、一ページ読み込んだはずが、実は一度に4ページのアクセスがあるのです。

インターネット高速化・先読みツール。
こういったツールを利用すると、実際には読んでもないし読もうとも思っていないページにもアクセスが発生します。

ロボット・スパイダー。
よく更新されるサイトほど、検索エンジンのスパイダーが頻繁にチェックに来ます。最近では本当に様々な検索エンジンがありますし、同じ所から一日に何回もアクセスしてきます。これらは人が読んでいるのではなく、検索エンジンに反映させるために機械的にアクセスしているだけです。

スパマー。
ブログを設置していると、ブログのコメントやトラックバックに対する大量のスパム行為を受けます。実際ここでもかなり弾いています。(言及なしトラックバック弾くプラグインとか、コメント承認制とかで)。さらに、メールアドレスを収集するロボット等々。こういった英語・中国語等の意味のないスパマーからの機械的なアクセスも多いわけです。

RSSリーダー。
で最近顕著な問題となってきたのが、RSSリーダー。ほんの数ヶ月前まであるRSSリーダーで5分間隔でアクセスできるようなものもありました。という事は一人がRSSリーダーを10時間起動しているだけで、一日大量のアクセス(リクエスト)があることになります。そして、RSSで全文配信している場合、内容はしっかり読んでサイトには一度もアクセスしない事もあります。特に最近のRSS・Atomによる配信・購読という流れで、もう、一定数超えたら正確な訪問者数なんて計測するのは無理でしょ、見たいな気持ちです。

ちょうど、Webサイトのトラフィック計測基準,英国でRSS User-Agentsを削除という記事がありました。UAで弾くというものですが、世界中の無数にあるRSSリーダーをすべてリストアップするというのも中々大変そうです。

はてなアンテナやMyRSS等
通常のHTMLページの更新を見張るサービスも定期的にアクセスしてきます。

こういうのを見ても分かると思いますが、アクセスといっても色々なのが分かると思います。

実際、某広告営業の方がいらっしゃって話した時、「このサイトは10万アクセスがあって...ですから広告費は月20万です」と言われて見せられたのが、良くあるanalogのアウトプット。モロにファイルアクセス数....orz。つまり、仕事とかお金に関る所で単純にアクセス数、と言われた場合、鵜呑みにせず、アクセス数とはなんの事かしっかり質問して把握しましょうという事だったりします。

では一日に何人の人間ブラウザでサイト内のページを任意に読んだのか正確に知る方法はあるのでしょうか。結論から言うと通常、数学的な正確さでは不可能です。毎回パスワード入力させたりるか、会員制のサイトでは別ですけど。現状では、例えばすべてのページを動的生成にして、アクセスしてきたPCにクッキーを食わせて、かつアクセス元IPアドレス比較し、UAでロボットは除くようにして...というのがもっとも有望ですが、これもまったく正確とは言い難い。何しろGoogle等のキャッシュで読まれた場合、会社・学校等のプロキシ・NAT経由、クッキー無効、UA偽装...いくらでも補足しきれない要因があります。最近ブラウザーのセキュリティの向上で埋め込みビーコンも効かなくなってきているし。もちろん大規模サイトでは上記の併せ技を駆使して出来るだけ正確に近い数字を出しているところもあるでしょうが、普通のサイトでは難しいと思います。

と書いていて、我ながら、「これだからパソコンやってる奴は」と言われるのも分かる気がしてきました^^;。頭の中でif ..then .. else .. if .. if . select case ..case ... else...if...

もし、絶対確実な手法というのはなくても、アクセス数を計測する標準的なアルゴリズムというか手法が指針として確立されているならぜひ知りたいです(除くべきUAのリスト一覧とかも)。でなければ同じログ解析ツールを利用とかしないと、正確なアクセス数の他サイトとの比較などまったく意味をなさないです。

将来的にはアクセス数などだけではなく、RSS・Atomフィード購読者数やサイト内のパーマリンクに対する総ブックマーク数とかも一つの指標にしていけたらいいなと思うこの頃です。

追記:
Hits Files Pages Visits Sitesの違いについて、詳しい。やっぱり「ヒット数にだまされてはいけない!」「かなり曖昧」だそうです。

投稿者 BlogWrite担当 : 04:29 | コメント (0) | トラックバック

2005年07月27日

「Hatena ID Auto-Discovery」について

これといった提案があるわけではないんですが、今朝いつもどうり、ITConversationsのポッドキャトを聞いていたら、どこかで聞いた話だな~と思われる事が出現したので、参考までに。

始まりは「そのページが誰のものなのかを示す識別子を埋め込む仕様を考えています」だったわけですが、

くしくも、時を同じくして、 ITConversationsの中の人のブログで:

Blogarithms ≫An Identity Challenge

For the new project we need to make sure we have authorization to record and publish tens of thousands of events every year from all over the world. How can we be reasonably certain that the person who gives us such permission is who they say they are and that they’re authorized to grant such permission?

I thought of one way we could do this, based upon the technique that Technorati uses to allow someone to claim an RSS feed. To demonstrate that the person has some association with an event, we could require that they add some invisible unique string to the HTML of one of the web pages associated with the event. We parse the HTML, find the secret string and close the authentication loop. The only problem is that we’re then limited to events with an on-line presence.

Got any better ideas for this one?

というエントリがあったのでした。「ITConversationの新プロジェクトにて、カンフェレンスやイベントの録音と公開をしても良いかの許可を得たい。しかし世界中で沢山のイベントがあり、誰が実際の許可を与える権限を持っているかを確認する方法はあるのだろうか?」「一つの方法として、Technoratiが利用しているテクニック:イベントに関連するHTMLページに見えないユニークな文字列を埋め込んでおく。私たちはそのHTMLページを解析して秘密の文字列を取得し、承認手続きを完了する」

似てませんか?Blogarithmsのエントリのコメントを始まりとして議論が広がりつつあるようですので、興味のある方はどぞ。

・はてなのケースでは、知りたいのは作者を識別するはてなID。
・ITConversationで知りたいのは、権限を持っている人(のコンタクト先なのか秘密の文字列?か何なのかは具体的には不明)

少なくとも手法は参考になるかもしれないですし。AtomAPIでもTypePadでの拡張の代わりにBook、Gallery、ブックマーク等でmicroformatを活用しようという動きがあります。これをきっかけに新たなmicroformatの策定なんてなったら面白いですね。

注:TechnoratiってHTMLページ内埋め込みするような何かしてましたっけ?本家テクノラティのサイト見ても見つけられませんでした。 コメント参照。感謝。

注2:ITConversationの新プロジェクトについては、要約詳細を参照。
- 「the goal is to capture, produce and publish recordings of all events, anywhere in the world.」

------------------

追記:

microformat仕様を作るときの心得は「pave the cowpaths」だろうと思います。XML.com: What Are Microformats?

つまり、誰もが何度もやっていることをこそまず便利にしよう、と(牛の通り道を舗装する=めちゃめちゃに使われてでこぼこになっちゃってる場所をキレイにする)。世の中にない新しい事柄をホゲるためにhogeってタグを作るってのはmicroformatsの目指すところではないのでしょう。

 どうやら microformats は固有のサービスの独自仕様のために用いるべきものではない、ということがわかりました。

という記述を見かけましたが、「pave the cowpaths」が意味するところは「だれもが何度もやっていることをこそまず便利にしよう」ではなくて、「adapted to current behaviors and usage patterns」既存の挙動やパターンに合わせよう。「Only create a new format to serve an existing application」既存のアプリケーションで利用できるようにしよう。

で言い換えると、 「not an attempt to get everyone to change their behavior and rewrite their tools」 つまり、「皆にいつもしている事を変更させたり、アプリケーションを書き直したり(専用のアプリケーションが必要になったり)させないようにしよう」というものです。
http://developers.technorati.com/wiki/MicroFormats
http://ifindkarma.typepad.com/relax/2004/12/microformats.html
http://www.xml.com/pub/a/2005/03/23/deviant.html

ですから、はてな固有のサービスの独自仕様のために用いても全然OKな訳です。OKにするために、既存のパターンを壊さないように(例えばXHTMLに)する、というが「pave the cowpaths」 の意味する所なのです。もちろんITConversationsの新プロジェクトでも使えるような設計上の汎用性を持たせるものを作るのも望ましいというかその方が面白いですけれど。 (ただし、「Development should be decentralized」非中央集権的なフォーマットの開発が推奨されています)

投稿者 BlogWrite担当 : 08:41 | コメント (1) | トラックバック

2005年07月25日

ソーシャルブックマークについて

ソーシャルブックマークについてまだ書いていなかったと思います。

個人的によく利用するのは、http://del.icio.ushttp://b.hatena.ne.jp/です。こういったのはどうせ三日坊主になるだろうと思っていましたが、なぜか気がついたら必須なものとなっていました。

Webの拡大・情報量の増加と共に、(個人的には)ブラウザーでの「お気に入り(ブックマーク)」管理が破綻し、すでに「お気に入り」(だけでなくIEも)を使わなくなって5、6年経ちました。Googleでちょっと検索すれば見つかるのと、RSSの登場というのが大きかったのですが、それ(お気に入りの代わりにググル)より良い解決策がこのソーシャルブックマークだったというわけです。

個人的には、Deliciousとはてなブックマーク、両者の使い分けとして、英語のブックマークはDelicious、日本語のははてなブックマークに登録しています(両方のサービス使いたかったから)。気づいた特徴としては...

・情報量や早さでは圧倒的にDelicious有利ですが、全体的な話題の追っかけやすさでははてなブックマークの方が分かりやすく、今話題の記事は...なんてのが一目で分かります。はてなブックマークのコメントなどは、まさに「ソーシャル」って感じですよね。

・Deliciousではタグの入力がヒジョーに楽。はてなブックマークでは実際にブックマークしなくても登録しているユーザー数(とコメント)が分かるのがイイ。個人をお気に入りとして登録すれば、まとめて人のブックマークを見れるのも好し。

個人的な利用目的は二つ。

・情報整理術のツールとして。
 調べ物等で検索して見つけた物で後になって必要になりそう、または重要そうなものをブックマーク。ただしブログ等で言及した(する)もの、または既に良く知ってい事に関するものは除く。 タグ付けして後で見つけやすいように。

・情報収集の源として。
 ・知識として::特定のタグごと、または個人のブックマークをRSSでヲォッチ。視野が狭くなり勝ちなので、新しい発見(へぇ、みたいな)の機会も掴む。能動的に検索行為を行うのではなく、受動的にカウチポテト状態を楽しむ。
 ・反響・市場調査::自分の書いた記事が、コメントもトラックバックも0件だけど、実は多数の方にブックマークしてもらっていたんだ、という事が分かると嬉しいものです。Webサーバーのアクセスログ(私の場合まったく見ませんが)では分からない反応(コメント等も)もはっきり分かって今後に役立ちます。 また、話題になっている事をとりあえず鳥瞰出来る。

以上が、個人的な利用方法と雑感でした。 はてなブックマークはその便利さから言って、もっとユーザーが増えてもよいはずだと思うので、まだ使ったことがない方は一度試してみると面白いんではと思います。

こうやって考えてみると、ソーシャルブックマークによって蓄積された情報を利用すると結構面白い事が出来そうな気がします。なにしろ、元来個々の人たちの自分自身のためのブックマークなので、有益な情報が集まりやすい訳です。つまり 「人」を利用した情報抽出。おまけにタグ付けされているし。で、これにGoogleのPageRankの考えを持ち込むと...

・多くの人にブックマークされた“Permalink”はRankが上で検索結果の上位に来る。
・多くの人に「お気に入りの人のブックマーク」登録されている人がブックマークしたPermalinkにはRankを加算する。
・当然時間の概念も取り入れアルゴリズムを調整。
・以下同様のパラメータ追加...。

なかなか面白そうな検索エンジンが出来上がりそうではないでしょうか。検索エンジンの超短い版の歴史としては:
1.Yahooがはじめた特定の人が収集・分類するディレクトリ型のサイトー>Webの情報量が多すぎて破綻(一時期Googleの検索エンジンを使い最近独自のエンジン開発)。
2.Googleによる、機械的に何でもかんでもすべての情報を集め、高度なアルゴリズムによって多種多様でごった煮の情報から有益な情報を絞りだす検索エンジンの登場。
そこで次にくるのは:
3.ソーシャルブックマークを利用した不特定多数のユーザーによるユーザーのための民主的な検索エンジンの登場...。というのがあっても良いのではと思います。(Open Directory dmozはコケ気味だけど...)

別に検索エンジンにこだわらなくても、ソーシャルブックマークでのデータがGoogle等の検索アルゴリズムに(どんな方法であれ)反映されるというのもありかなと思います。実際今でもはてなブックマークの検索結果はかなり使い勝手あります。

一例を挙げると、例えばAtomAPIとは何なのか詳しく知りたいとします。GoogleでAtomAPIを検索すると、結果は「LivedoorBlogがAtomAPIに対応しました」が一番上。はてなブックマークでAtomAPIを検索すると、「The Atom Project - Atomとは何か」が一番上。どちらが求めているものに近く情報量が多いかと言えば、一目瞭然かと(我ながら^^;)思います。さらに言うと、はてなブックマーク検索はすでに、はてな自身の検索サービス、はてな検索をも凌駕してます(はてな検索でのAtomAPIの検索結果:3件...orz) 。

なんて事を最近つらつら考えていたのですが、はてなアイデアに出すには冗長すぎw。 こういう時に「Hatena ID Auto-Discovery」でこのページ内にはてなIDを埋め込んでおくと投げ銭でうはうはなのですね!(アサマシモード)

うーん全然まとまらなかった。

投稿者 BlogWrite担当 : 23:06 | コメント (1) | トラックバック

2005年07月16日

Googleマップの好きな場所に好きな文字で噴出しピンを立てる

maps.gif

Googleマップの好きな場所に好きな文字で噴出しピンを立てる方法。 JavaScriptでページ内に埋め込むのとは別に、URLを人に送る時など。たいした事ではないのですが、人に説明する時に忘れそうなのでメモ代わりに。

追記:コメント欄参照!

1.Googleマップの地図上で目的の地点をダブルクリック等で中心にもってきます。

2.ページ右上の「このページのリンク」でURLを取得。(下記のようなアドレス)
http://maps.google.co.jp/maps?ll=35.692899,139.386313&spn=0.007334,0.013393&hl=ja

3.先ほどのURLの赤い部分(下参照)をコピー
http://maps.google.co.jp/maps?ll=35.692899,139.386313&spn=0.007334,0.013393&hl=ja

4.Googleマップの検索欄に、(3)でコピーした数値を入力後、スペース(半角英数)の後に括弧(半角英数)で好きな文字列を括ります。(サンプル文字列下)

35.692899,139.386313 (ここです)

5.検索ボタンを押します。検索が終わると、噴出しつきでピンが立っていると思います。

6.この状態で、また「このページのリンク」でURLを取得(下)。これを人に送ります。

http://maps.google.co.jp/maps?q=35.692899,139.386313+(%E3%81%93%E3%81%93%E3%81%A7%E3%81%99)&hl=ja

7.拡大率(縮尺)も指定したい場合は、始めのURLから、&spn=0.007334,0.013393の部分を付加します。

http://maps.google.co.jp/maps?q=35.692899,139.386313+(%E3%81%93%E3%81%93%E3%81%A7%E3%81%99)&hl=ja&spn=0.007334,0.013393  <-拡大率
 

もっと簡単な方法があったら教えてください。

投稿者 BlogWrite担当 : 20:20 | コメント (7) | トラックバック

2005年07月15日

GoogleマップとIEの「開けません。 操作は中断されました」

昨日から凄いことになってる、Googleマップなんですが、早速管理している某サイトでページ内に地図を埋め込んで使ってみました。が、IEでチェックし忘れて、「見れない」とか言われてしまいました。FireFoxではまったく問題ないのに、マイクロソフト様のIEでは

---------------------------
Microsoft Internet Explorer
---------------------------
インターネット サイト http://www.***.***.*** を開けません。
操作は中断されました
---------------------------
OK  
---------------------------

などという意味不明なエラーを頂いてしまいました。Google.comとかのAPIドキュメントのサンプルや色々なのを参考にしたんですが、サンプルと大きく異なる所があるでもなく、どうも原因がつかめない、と悩んで検索した所、どうもロードされるタイミングの問題らしく、スクリプト部分をHeadに持っていって、functionにして、BodyのOnLoadイベントで呼ぶようにしたら見事エラーがも無くなりちゃんと表示されました。めでたしめでたし。

もし似たような事がありましたら是非お試しあれ。

投稿者 BlogWrite担当 : 12:28 | コメント (2) | トラックバック

2005年07月13日

テレビブログ=?

テレビブログというブログサービスが立ち上がったらしいですが、個人的には「無料で使えるTypePad」ということで非常に貴重かと認識しております。将来的に有償になるかもですが。 (追記:ウワっ橋本さんの会社だった、し失礼いたしました^^;)

因みにテレビ繋がりで、地上波放送局がWebでテレビ番組配信か、とか言うとすわっ「放送と通信の融合の試金石か」とか昨日今日になってメディア(*1)(*2)が書きたてますが、USENのGyaoなどは、とっくに各種番組放送しているわけで、なにか時代錯誤というか、既存メディアの現状認識とWeb上の動向の乖離が激しい気がするのですよね...。 それに、「融合」ってそんなもんなのか、という疑問も残ります。堀江さんはもっと別のこと念頭に置いていたと思うのですが...。放送するだけじゃ、所詮放送であって、通信はどこにいったの?ともかく、日本は地理的事情もあってケーブルテレビはアメリカほど普及しないわけですが、多チャンネルなWebの特性もケーブルテレビとか有線では普通のことなので、とても相性が良いですし、今後も期待してます。

しかし、Gyaoが無料なのに対し、日テレ、フジともに視聴が有料だというのですから失敗するつもりで始めるのか、よっぽど番組に自信があるのかのどちらかでしょうか。

因みにGyao、IEでしか見れないのは酷く苦痛ですが、今やってる「ピッチブラック」やら「Dune砂の惑星」など美味しいです^^;

投稿者 BlogWrite担当 : 22:15 | コメント (0) | トラックバック

2005年06月17日

Googleの新たなランキング手法が明らかに

GoogleのUS特許申請から、新たなランキングアルゴリズムの幾つかが明らかになったそうです。

Google'sSite Ranking Secrets(Slashdot.org)
Great Site Ranking in Google The Secrets Out

例えば、Googleはあるサイトが登録されてからどのぐらい経っているかを見て、期間が長いサイトであればよりランクを上にする判断材料にするそうです。例えばあるサイトが立ち上がって(ドメイン名の登録日から)一年未満であると、ランキング的には不利な条件となります。

他にも、サイトへのリンク数などが重要な要因だとされていますが、それが順位付けにおいて実際どういう役割をもっているかも解説されています。

例えば、あるサイトへのリンク数の増加率というかスピードまでもが、アルゴリズムのパラメーターとなっているようです。これは、スパムとかを利用して、一気に多くののリンクを一日で作ったりすのを判別してるのでしょうか...推測ですけど。

SEOに詳しいと称する人たちは残らず上記リンクサイトに掲載されているリポートを研究する必要があると思われます。

余談ですが、個人的には小手先のSEOでなくて(ゴテゴテした見た目でもなく)、大事なのは中身かと思っています。過去、いくらSEOに凝ってもだめなサイト、まったくSEO無視して有益な情報を載せただけで4年間Google検索結果のトップをキープしているサイト、個人的に両方作りました。(といっても別にSEO軽視しているわけではなく、記述はXHTMLでちゃんとしてますし、長年やってるので無意識にキーワードを意識した文章とかをそれをHタグでくくったりしてしまう^^;のですが、騒ぐほどの小手先な事はしていません)

ですから、順番的に、SEOより、まず中身を用意すべきだ、といつも(声を大きくして言いたいけれど)心の中で思っているんですよね...。

投稿者 BlogWrite担当 : 01:12 | コメント (0) | トラックバック

2005年06月16日

総務省による子供総ブロガー計画

子どもはみなブログを持て!」(読売新聞)
 総務省は14日、小中高校生のだれもがブログ(日記風の簡易ホームページ)を書くような環境をづくりをめざす方針を決めた。同省が設置した「情報フロンティア研究会」(座長=國領二郎・慶応大学教授)が、日本の「IT(情報技術)力」を強化する方法として、「あらゆる児童・生徒がブログを持つべき」と報告書で提言したのを受けたものだ。

物凄いことになってますね。なんというか、コメントする言葉が見つかりません...。

投稿者 BlogWrite担当 : 02:57 | コメント (2) | トラックバック

2005年06月14日

BloggerのRate Limit

どうもBloggerでは「Rate Limit」というのが導入されていたらしく、ある特定の回数Bloggerに記事を投稿すると、”Rate Limit”に達して、一度Bloggerのサイト上でログイン+人間にしか読めない(という事になっているが時には人間にも読めないという噂の)画像に表示された文字を打ち込まないといけないらしいです。これはAPI経由の投稿だけでなく、Webベースの投稿も同様だそうです。

これにより、スパマーによる悪用を防ぐという効果があるからだそうです。では何回ごとにこのリミットに達するのか、というのはナイショらしいです。つまりは、ここまで対策をしなければならないほどひどく悪用されているという事でしょう。

とっても危ういと思うのは、日本ではExcite(なぜか独自APIですが)とかS*e***さんのブログのように、API経由でプログラミング的に自動でアカウント作成からブログの作成、記事の投稿、トラックバックまで打ててしまうと、スパマーに悪用される危険が非常に大きい(Bloggerよりも)のではと思います。 (BloggerではアカウントもブログもAPIでは自動で作れないようになっている)

スクリプトでちょちょいとやると、あっというまに...。数千のアカウントに万のゾンビーブログが手当たりしだいトラックバックスパムを連射しまくり、という悪夢を想像してしまいます。

各サービスの対応はどうなんでしょうか...

以下考察...

IPアドレスで弾くのも無理があるし...。関係ないネットワーク丸ごと弾くというリスクもあるし...

クッキー食べさせるー>そのたびにクッキー破棄されたら無効

...結局、ExciteブログとかS*e***ブログさんとかは、BloggerのまねしてRate Limitのようなものを導入するか、アカウント作成する独自APIを捨てるしかなくなるんじゃないか、と...。少なくともこれ読んでなにかしら対策をしてくれると少し安心かもしれません...

もっともAPI使わないでやる方法もあるにはあるので、悪用される可能性があるのはどのブログサービスでも同様かとは思いますが、悪用し易さというか敷居の低さは大きいと思います。

投稿者 BlogWrite担当 : 18:13 | コメント (0) | トラックバック

2005年05月29日

kijiji その2

前回記事書いてから、忘れた頃にトラックバックをもらって、ああそう言えばそんなのあったけ状態...だったのは秘密です。

この機会にkijiji Japanの将来に関してちょっと無責任に考えてます。

本家とも言えるCraigslistはかれこれ10年近くこつこつ地道にやって爆発したのと比較すると、まぁあまり早々に結論は出したくないですが、現状kijiji Japanの注目度、利用度共に低いのは事実のようですね。

では、Kijijiに足りないものは何か...

一番はマーケティングなんでしょうが、これ私得意じゃないんで横に置いておいて、Kijijiに求められる機能、サービスとは何かという点なら少し言えるかもしれません。

・アルファギークに好まれる機能
最近のパターンでは、1.影響力のあるアルファギークに気に入れられるー>2.一般ブロガーがクールなものとして話題にするー>3.Web系メディアが取り上げるー>一般メディアが、よく分からない「ネット」とかいう世界での世にも不思議な現象かのように扱うー>マスへリーチ。という黄金パターンが出来上がりつつあるように思います。

じゃ、アルファギークに気に入られるサービスとは?リサーチしろ、空気嫁...ではつまらないので、ざっと今のKijijiに無くてあって当然のものから上げると...。
Ⅰ.RSS配信。RSS配信してないなんて、オクレテルーというのが****の言い分です。
せめて、最新投稿の告知、カテゴリ毎のRSS・Atomを配信しないと相手にされません。
Ⅱ.API公開。
アルファギークご用達のflickrはてなフォトライフはみんなAPIを公開し、外部やサードパーティ製のソフトウェアからアクセスし操作する事が出来ます。これないと、クールとは言われません。

顔が見える事
どこの誰がどういった思想を持って開発・運営しているのかが分かると、安心するものですし、コミュニケーションが発生することによって様々なプラス効果が出てくるわけで、ブログぐらい立てましょうよ。

BlogWriteとの連携(ボソ)
いや、だって告知の投稿ってめんどくさそうなので...、あと自分の告知の管理とか煩雑そうだし、第一自分が投稿したやつ忘れるのがオチかと。だったら、API公開してBlogWriteみたいな専用クライアントから管理できたら楽じゃん、と安易に考えます。はい、お問い合わせは弊社お問い合わせ窓口よりどうぞ

以上、マーケティングする前にやることがあるだろう、というのが眠くて脳みそ飛んでる私の適当な感想でした。

追記:
あ、そう言えば日本には、"Classifieds"という概念がないんだった。単純にいうと、新聞の「売ります・買います・探してます」って奴なのだけど、日本の新聞では全然一般的じゃないから、ユーザーにこの概念を理解してもらうのから始めるわけで日本では物凄く大変かも...。

投稿者 BlogWrite担当 : 22:53 | コメント (0) | トラックバック

2005年03月25日

Skypeで仕事

ホテルや短期賃貸マンションにもSkype端末、無料通話が可能に - CNET Japan
という記事を読んでいて思い出したのが、
来客・来訪の対応業務を全てSkypeだけにする試み - Slashdot.jpでも話題になった、
「有限会社グローバル・フレックス・プランニングは、2004年12月、訪問、来訪対応などの一切の対面対応を行わないと発表した」件。

そして、その結果報告が面白い。

「最初にSkypeをほめたり、けなしたりの時間が3-4分あったのですがあとは通常の電話と同じ感じでした」

フフフ
経験アリマス(笑

Skypeで打ち合わせしましょうと言ったらその後連絡が途絶えた会社 2社

ウムム
技術的に出来なかったのか、それほどまでの重要性がなかったのか...それとも...

私の場合の利用方法は、最近ブログによる企業サイトを作る際の担当の方とのやり取りに使う事が多いです。事の始りは、お会いしてお話している時の「地理的に距離が遠いからSkypeを使うという手もありますね」、という会話からでした。

一昔前まで、個人的にはチャットのようなものは作業時の集中を妨げる、と思って嫌っていたのですが、一緒に良いモノを作ろう、というパートナーとしてのお客さんとの距離がとても心地よく、最高のコミュニケーションが出来ます。

ウェブサイトを作る上での確認や要望を話合う際、Skypeで相手先の担当の方が、今オンラインであるか、忙しいかどうかが一目でわかり、気軽に通話出来ます。

実は昨日も、夜の11時だというのに、「どもすみません、例のブログのサイドバーなんですが...」なんて会話をしてました。通常の電話では、夜遅くに担当の方のご自宅に電話なんて、よっぽどじゃないととても出来ません。Skypeでオンラインだと確認できるからこそ、気軽に通話and/orチャットして聞いてみるか、となります。

Skypeで担当の方とお話し、その場で即断、即決、即実行。ページを編集してその場で作り、確認してもらう事もあります。仕事とはこうでなくては、と思います。(もちろんいつもそう出来る訳ではありませんが...)

投稿者 BlogWrite担当 : 22:29 | コメント (0) | トラックバック

2005年03月20日

GISデータが無償公開される...らしい

国土地理院、月内にも全国のGISデータを一般に無償公開

当然といえば当然?

米国では国勢調査局かなんかが無償公開していた気がします。

もちろん、クオリティとか、付加情報などで民間の方が優れているケースがほとんどなので、なんとも言えないと思うのですが、何十万、何百万円投資しなくても、一個人が気軽に利用出来るようになるというこの事実が、物事を大きく前進させるのは確実だと思います。これは民業圧迫でなく、民業活性化だと思われ...(そう思わなければやっていけないとも言う...)。それに税金による成果物を国民に還元するのは当然ですものね...。(天気予報のデータがXML公開されないのは例によって例のごとく天下り団体が...さfdlkぃjsd以下省略)

発見元

追記:
オライリーから「Mapping Hacks」と、「Web Mapping Illustrated」の二つが発売されるのを待っているのだけど、マーダー?

投稿者 BlogWrite担当 : 17:28 | コメント (0) | トラックバック

2005年03月05日

Mac mini で日本語キーボードの問題

今話題のMac mini をしばらく前に買いました。と言うのも作ったサイトを、Mac版のIEで表示確認したり、他にもゴニョゴニョ使い勝手がありそうだったからで、決してMac上で動くソフトウェアを開発しようなどと大それた事は考えていません。すみません。
(表示チェックと言えば、MacOSXの標準ブラウザSafariは、中身はLinuxはKDEのKonquerorと同じなので、SuSEで確認していたのですが、未だに古いMacをお使いの方がいらっしゃるのでMacIEもチェックせざるを得ない、ゆえMacが必要と...。Netscape4.xは早く消えて無くなって欲しいので無視。基本はFireFoxで...。)

で、早速普通のWindows用のUSBキーボードを買ってMac miniにつないでタイプしてみると、もろに英語101のキーボード配列ではないですか...。まず100%普通の日本語JISのキーボードを誤認識します。個人的に始めて触ったキーボードは英語101だったので、個人的には不都合ないですが...ムムム。「Mac miniでいろんなキーボードを試す」

ところが、ちょっと見つけにくいのですが、探すと修正する方法がありました。WindowsキーボードをMacで使うで紹介されている方法で非常に簡単に修正する事が出来ました。感謝...。

しかーし、どうもUSBの認識が良くないようで、Mac miniの起動時にUSBキーボードを認識してくれないようで、起動後にUSBケーブルを抜き差ししないとタイプ出来ません...。まぁ安物のキーボードを買ったからなのですがちょっとショック...。

さらに、CPU切り替え機でディスプレイとキーボード&マウスの切り替えも出来ないのがさらに追い討ちを....。


Macはかれこれ5年以上前に仕事で無理やり使わされたきりで、あの古いMacOS9.xにはかなりの悪感情がありますが、新しいMacOSXはUnix系なので、ハッピー、ハッピーです。見た目の派手なLinuxという感じで...。

投稿者 BlogWrite担当 : 12:23 | コメント (1) | トラックバック

2005年01月24日

某業界の話

某業界の話なのですが...。
現在、ある業種で使われる業務ソフトを特定の一業務ソフトに絞り、業界団体として会員企業に利用を推奨して行こうという動きがあります。
その理由は、より良いソフトを低価格で利用したい、という事のようです。つまり、団体会員企業に大量導入する代わりに、市場価格の6割、7割引きで市販のソフトを購入し利用出来るだろうという計算かと思われます。

具体的な事を批判や反対するつもりはまったく無いのですが、しかし、ここには考慮すべき問題があります。

結論から言うと、この動きは中長期的に見てソフトを利用する消費者の利益に結びつかないのではないか、という事です。

特定のソフトが、その市場を独占に近い形で広まった場合、そのソフトは市場原理の競争にさらされません。そうなると、その業務ソフトは、より良い機能や新しい機能を追加する必要がなくなってしまいます。さらに価格も市場価格を意識する必要もなくなり、最終的に値段の設定もベンダーの意のままとなります。

ソフトの販売価格を、市場の原理を無視した低価格の設定にすることにより、ソフトベンダーは長期的な利益を得るために別の方法で収入を考えなくてはなりません。つまり売り切りで一時的に収入は入りますが、独占に達した段階で売り上げはパタッと止まります。ベンダーは継続してやっていくために、例えばサブスクリプション形式、つまり、ソフトの利用料を徴収しなければなりません。
業界がやろうとしているのは、まさにこれです。これは、いわゆる「ひも付き」です。業務ソフトですから簡単には他のソフトに乗り換えるのが難しいわけですから、5年も使えば、月々の利用料は相当なものになります。結局利用者は、市場価格で買うよりも高額な買い物をする事になります。しかも独占状態で他のソフトが蹴散らされた結果、利用者は選択の自由もなくなります。そのソフトを使い続けるしかなくなるのです。

価格だけではなく、市場を破壊してしまう事によって、その業界のソフトの発展も改良も進歩もなくなるわけで、結果として利用者の不利益となります。

では、なにをすべきか。
自由競争を促進し市場の原理にゆだねる事です。具体的にどうすれば自由競争を促進できるのか。
それは、情報をオープンにする事です。

業界団体として、良い業務ソフトの基準を設け、各種ソフトを集約し、評価し、それを一般に公開し情報を提供していく事などが考えられます(例えば価格.comのように)。 どのソフトを使うかは市場の原理、ニーズに任せ、より市場を活性化させる事を目指すのが良いと思います。

なぜかというと、なぜ独占禁止法が存在するのか、という理由と同じです。

ITの世界では常識なので、これをお読みになった一部の方は、「何を今さら」と思う方もいらっしゃるかもしれません。マイクロソフト対米司法省、日本の公正取引委員会の件、他にも、独占的ファイルフォーマット、ファイルシステム、ブラウザー戦争、Windowsに音楽プレーヤーをバンドルさせた件の裁判...ETC
そして、その結果こうむったさまざまの不利益をユーザとして実際に体験しています。

しかし、他業界に身を置くと中々気がつきにくい事なのかもしれません。また当事者であると見えにくい事も外部から見ると別の視点が見えるだけかもしれません。
という事で、第三者的立場として、一傍観者として、全体の利益を考え、一応私個人の意見を述べさせていただきました。(関係者の方たちへ^^;)

投稿者 BlogWrite担当 : 22:59 | コメント (0) | トラックバック

2005年01月19日

[Witha]人材募集..?

こんな所で突然ですが、人材募集するかもしれません。
今現在、不動産業務ソフトの開発が大詰めになっていて、さらに私勝手プロジェクト「ブログ作成請負、RSSリーダ、ブログクライアント開発」と暴走中のため^^;、恐らく、以下のような募集になるかも知れません。

・業務アプリケーション開発補助
C/C++(Borland)によるDB開発経験者

・Webサービス開発他
PerlによるWebアプリ開発経験者

WWWに関する知識と、XML(DOM、XSLT、XML Schema)必須

詳細は未定ですが...。上記以外でも一緒に働きたいと仰る奇特な方歓迎;-)

投稿者 BlogWrite担当 : 17:54 | コメント (0) | トラックバック

2004年10月08日

グーグルランクに変動

Googleランクに変動があったようですね...。

ここはポータルサイトでもないのに、ページランク6をもらっていたのですが、更新をサボってるためか、5に落とされました。

気になって調べていたら、同じく個人としてはまれな6を持っていた、Naoyaさんの所も5に落ちていますね...

ちなみに、ランク上げるためにセコイ手などは一切つかっていません。TrackBackすら10回に一度打つかどうかというぐらいです。

と、こういうどうでもよい記事書くから落ちるわけで...精進します。

投稿者 BlogWrite担当 : 19:47 | コメント (0) | トラックバック