kazuho.exblog.jp - 奥 一穂の飲んでから書くブログ。なにもかもアルコールのせいです
<   2004年 11月 ( 6 )   > この月の画像一覧
ウェブ型 RSS リーダーの弱点
NDO::Weblog に ウェブ型 RSS リーダーの波 という記事が出ていた。いわく、 RSS リーダーの分野でビジネスの可能性があるのはウェブ型ではないか、と。

興味深い記事だし、収益を生むのはウェブ型のほうが楽、というのには賛成。

しかし個人的には、ウェブ型 RSS リーダーは以下の2つの理由によりニッチに留まると思っている。

1) PC 上で動作するクライアント型の方が便利
 ウェブ型は、どうしても操作性という点でクライアント型に劣る。たとえば、購読したい URL をいちいち RSS リーダーのサイトで登録するのは面倒である。
 これは、ウェブ型ブックマークサービスが普及しなかった理由である。

2) イントラネットや認証エリアへからのフィードをどうするか
 ウェブ型では、イントラネットのサイトからのフィードを受け取ることができない。また、インターネット上の認証つきサイトについても問題は同様である。認証つきサイトがニュース系のものであれば、ヘッドラインだけ無認証で RSS で流して、記事ページは要認証というモデルもあり得るだろう。しかし、 SNS のようなサイトでは RSS にも認証が必須である注1

 というわけで、でもないのですが、先週からクライアント型ならではの RSS リーダーを作っています。今月中には公開できるかなぁ。

注1) RSS feed の認証について標準的な方法は存在するんだろうか... 誰か教えてください (笑

2005/1/2 追記: 2004/12/10 より、こちらで公開しています
[PR]
by kazuhooku | 2004-11-18 12:32 | RSS & お気に入りナビ
日本のソフトウェアが輸出されない理由
CNET Japan の記事等で報じられているように、日本のソフトウェアの輸出入の比率は、輸出 1 vs. 輸入100 だそうである。その原因は何か。よく挙げられる候補は、これら3つだろう。

  • 独創性の問題
  • 開発技術の問題
  • 言語障壁の問題
しかし、いずれも当を得ていないように思われる。
独創性については、ソフトウェア技術のうち特許で保護される部分はごく一部であるし、たいていの機能は競合製品と切磋琢磨していく中で実装されていくものであるから、該当しない。
開発技術についても問題ではないと思う。そもそも、開発技術とソフトウェアの売り上げに相関関係などないのではないか。開発技術については外部から見えない点も多いが、売り上げと品質に関係がないのは明らかだ。たとえば Netscape の実装 (オープンソース化された当初のもの) は、おそろしく低レベルなものだった。
言語障壁は、言い訳にすぎない。たとえば、他の東アジア諸国 (中韓台) のソフトウェアは、日本よりも輸出されている (と思う) 。

私には、問題点はただひたすら、外国の市場を考えない日本のソフトウェア業界の体質にあると思われる。
過去、一緒に仕事をした中韓台のソフトウェアハウスは、いずれも輸出を前提にソフトウェアを開発していた。彼らの目は世界を向いていたのである。
逆に、日本のほぼすべてのデベロッパーは、国内の市場が十分に大きいこともあり、国内市場向けに計画を立て、日本語版を最初に開発している。彼らの考えは、国内で成功すれば輸出してみようか、というものだ。

これではダメだ。

ソフトウェア業界は日進月歩である。新機能なんて、数ヶ月もたてば他のソフトウェアにも実装され、標準的なものになってしまう。たとえ開発に着手した時点で日本のデベロッパーが先行していたとしても、海外進出を果たす頃には同等以上の製品が既に開発されてしまっている。
しかも、相手は数倍の市場を持つ英語版。開発に投資できる金額が違う以上、太刀打ちできない (*1)。追いつき追い越され、やがて国内の市場も持っていかれるだけである。

対策はひとつしかない。日本語版と同時に英語版を作成することだ。
[PR]
by kazuhooku | 2004-11-16 02:09 | 雑想
Palmscape / Xiino の画像サポート
Palmscape で画像表示が可能になったたのは、確か 2000 年初頭の Version 2.0 においてだったと思う。画像サポートにあたっては、 Palm OS デバイス上で直接 GIF / JPEG ファイルのデコードをせずに、イリンクスで用意した補助サーバを使用して独自形式に変換する方式を採用した。
その理由について、まとめてみる。

  1. CPU パワーの不足。当時の Palm デバイスの CPU (68328EZ/33MHz) では、 160x160 の JPEG をデコードするのに3秒程度かかった。これでは、たとえば XGA (1024x768) の写真データを表示しようとすると、90秒必要なことになってしまう。

  2. メモリ不足。256 色カラーをサポートした IIIc でも自由に使えるワークメモリは 140 KB 程度。画像の展開後のバッファ等も必要なわけだから、このメモリ量で JPEG のデコーダを動かすのは現実的でない。

  3. 同時接続可能な TCP/IP セッションの個数。Version 5 以前の Palm OS では、同時にオープン可能な TCP/IP ソケットの個数は4個だった。この4個の中には、DNS 参照に使用されるソケットや切断処理 (FIN_WAIT) 中のものも含まれるため、実際には HTML と画像を並行してダウンロードすることは不可能である。

  4. 転送データ量の低減。Palmscape では、文字サイズとの兼ね合いから画像を 50%
    に縮小し、かつ、(横スクロールをしないという観点から) 50% に縮小しても画面幅に収まらない画像については、画面幅にあわせて縮小する。また Palm OS 3.5 においては表示可能な最大色数は 256 色だったので、GIF / JPEG より低圧縮率/高速度な圧縮アルゴリズムを使用しても、変換してから転送するほうが、データ量が削減できた。

以上4点だろう。

2004 年末の現在から振り返ってみると、 2 は解決済。1, 3 も解決されつつある (Palm OS 6 で最終解決?) 。残るは 4 のみか。時の流れを感じる。

ちなみに、この補助サーバは大学在学中の 1996 年に書いた finger プロトコルのプロキシサーバを拡張したものである。当時、自分の書いたコードを8年にも渡って使い続けることになるとは思わなかった。

改良すべき点はたくさんあるし、支持してくれるユーザもいる。Xiino の製品寿命は、あとどれくらいなのだろうか。
[PR]
by kazuhooku | 2004-11-14 01:07 | Palm & Xiino
HTML コンパイラとしての Palmscape / Xiino
blog を習慣化するには何回かに分けて書くことができるネタを用意すればいいか、と考えた。

というわけで、 Palmscape / Xiino の実装について、特徴をまとめてみようと思う。

Palmscape のコーディングを始めたのは、たしか 1997 年 5 月。
当時最新の Palm デバイスは 16MHz の Dragonball に 1M のメモリを積んだ PalmPilot Pro 、これが唯一 TCP/IP スタックを積んだデバイスだった。

1MB のメモリといっても、そのうちワークメモリとして使えるのは僅か 10~20 KB。
残りは、読み込み only (書き込みは API 経由) のストレージメモリと TCP/IP スタックが使用する。この僅かなワークメモリで、どのように実用的なウェブブラウザを実装するか、というのが技術的課題だった。

(他製品のソースコードを読んだことがあるわけではないが) 一般的なウェブブラウザの実装は、 HTML から構文木を作成し、その木にレイアウト情報を付加していく、インタプリタ形式 (?) だと思う。

しかし Palm OS のワークメモリでは、 HTML を分割してレイアウト情報を負荷するだけの余裕がない。

必然的に Palmscape は、 HTML を逐次読み込みながら「カーソルを○○に移動して△△を書け」という中間コードへ変換し、ストレージメモリへ保存していく HTML コンパイラとして設計された。

この設計が、良くも悪くも Palmscape / Xiino の特徴となっている。良い点としては、

+ ワークメモリより大きな HTML ファイルを表示できる
+ ダウンロード終了後は中間コードを実行するだけなので、表示/スクロールが早い
+ 余計なタグ情報を保存しないので、ダウンロード後のサイズが小さい

等が挙げられる。当時の HTML は単純であったことから、コンパイラ型という選択は正しかったと思う。しかし、今日の複雑化した HTML では、デメリットも少なくない。

たとえば、テーブル等2パスのレンダリングが必要な場合 (1パス目でテーブルのセルの幅を決定し、次にレンダリングを行う) は、メモリの節約にはならないし、ダウンロード時にレイアウトが固定化されてしまうので、 JavaScript を用いてオンデマンドに画像を差し替えるといったことは困難である。

また、ワークメモリも増加し、コンパイル型を選ぶメリットは小さくなった。

今、仮に、1からブラウザを作るとしたら、コンパイラとインタプリタの双方の特徴を併せ持ったハイブリッドとして実装するのがベストな選択なのではないだろうか。

次回は、画像サポートについて書いてみたいと思う。
#その次は JavaScript?
[PR]
by kazuhooku | 2004-11-05 01:04 | Palm & Xiino
ひさしぶりの Palm プログラミング
ひさしぶりに Palm のコードを書きました。
Xiino/3.3 リリースのためです。

JavaScript まわりで、かなり痛いバグがあったりしましたが、全部直して一息... と思いきや、リリースしたソフトのバージョン番号が間違っていました。

正式版なのに、 3.3b1...
b0057078_2041926.gif


...ま、いっか。

次はランドスケープモード (横方向 480 ピクセルモード) を追加しようと思ってます。簡単にできそう。
[PR]
by kazuhooku | 2004-11-02 20:20 | Palm & Xiino
blog を始めることにしました
SNS デビューもしたことだし、 blog を始めようかと思います。

トップの写真は、安房白浜で撮影したものです。ケータイだから汚いなぁ。しかもナナメだし。
b0057078_19532761.jpg

[PR]
by kazuhooku | 2004-11-02 19:16 | 近況