kazuho.exblog.jp
- 奥 一穂の飲んでから書くブログ。なにもかもアルコールのせいです
|
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 より、こちらで公開しています #
by kazuhooku
| 2004-11-18 12:32
| RSS & お気に入りナビ
CNET Japan の記事等で報じられているように、日本のソフトウェアの輸出入の比率は、輸出 1 vs. 輸入100 だそうである。その原因は何か。よく挙げられる候補は、これら3つだろう。
独創性については、ソフトウェア技術のうち特許で保護される部分はごく一部であるし、たいていの機能は競合製品と切磋琢磨していく中で実装されていくものであるから、該当しない。 開発技術についても問題ではないと思う。そもそも、開発技術とソフトウェアの売り上げに相関関係などないのではないか。開発技術については外部から見えない点も多いが、売り上げと品質に関係がないのは明らかだ。たとえば Netscape の実装 (オープンソース化された当初のもの) は、おそろしく低レベルなものだった。 言語障壁は、言い訳にすぎない。たとえば、他の東アジア諸国 (中韓台) のソフトウェアは、日本よりも輸出されている (と思う) 。 私には、問題点はただひたすら、外国の市場を考えない日本のソフトウェア業界の体質にあると思われる。 過去、一緒に仕事をした中韓台のソフトウェアハウスは、いずれも輸出を前提にソフトウェアを開発していた。彼らの目は世界を向いていたのである。 逆に、日本のほぼすべてのデベロッパーは、国内の市場が十分に大きいこともあり、国内市場向けに計画を立て、日本語版を最初に開発している。彼らの考えは、国内で成功すれば輸出してみようか、というものだ。 これではダメだ。 ソフトウェア業界は日進月歩である。新機能なんて、数ヶ月もたてば他のソフトウェアにも実装され、標準的なものになってしまう。たとえ開発に着手した時点で日本のデベロッパーが先行していたとしても、海外進出を果たす頃には同等以上の製品が既に開発されてしまっている。 しかも、相手は数倍の市場を持つ英語版。開発に投資できる金額が違う以上、太刀打ちできない (*1)。追いつき追い越され、やがて国内の市場も持っていかれるだけである。 対策はひとつしかない。日本語版と同時に英語版を作成することだ。 #
by kazuhooku
| 2004-11-16 02:09
| 雑想
Palmscape で画像表示が可能になったたのは、確か 2000 年初頭の Version 2.0 においてだったと思う。画像サポートにあたっては、 Palm OS デバイス上で直接 GIF / JPEG ファイルのデコードをせずに、イリンクスで用意した補助サーバを使用して独自形式に変換する方式を採用した。
その理由について、まとめてみる。
以上4点だろう。 2004 年末の現在から振り返ってみると、 2 は解決済。1, 3 も解決されつつある (Palm OS 6 で最終解決?) 。残るは 4 のみか。時の流れを感じる。 ちなみに、この補助サーバは大学在学中の 1996 年に書いた finger プロトコルのプロキシサーバを拡張したものである。当時、自分の書いたコードを8年にも渡って使い続けることになるとは思わなかった。 改良すべき点はたくさんあるし、支持してくれるユーザもいる。Xiino の製品寿命は、あとどれくらいなのだろうか。 #
by kazuhooku
| 2004-11-14 01:07
| Palm & 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? #
by kazuhooku
| 2004-11-05 01:04
| Palm & Xiino
ひさしぶりに Palm のコードを書きました。
Xiino/3.3 リリースのためです。 JavaScript まわりで、かなり痛いバグがあったりしましたが、全部直して一息... と思いきや、リリースしたソフトのバージョン番号が間違っていました。 正式版なのに、 3.3b1... ...ま、いっか。 次はランドスケープモード (横方向 480 ピクセルモード) を追加しようと思ってます。簡単にできそう。 #
by kazuhooku
| 2004-11-02 20:20
| Palm & Xiino
|
検索
以前の記事
2013年 12月
2008年 10月 2008年 09月 2008年 08月 2008年 07月 2008年 06月 2008年 05月 2008年 04月 2008年 02月 2008年 01月 2007年 10月 2007年 09月 2007年 07月 2007年 06月 2007年 05月 2007年 04月 2007年 03月 2007年 02月 2007年 01月 2006年 12月 2006年 11月 2006年 10月 2006年 09月 2006年 08月 2006年 07月 2006年 06月 2006年 05月 2006年 04月 2006年 02月 2006年 01月 2005年 12月 2005年 10月 2005年 09月 2005年 08月 2005年 02月 2005年 01月 2004年 12月 2004年 11月 カテゴリ
最新のトラックバック
その他のジャンル
ファン
記事ランキング
ブログジャンル
画像一覧
|
ファン申請 |
||