2006年2月アーカイブ

今後も、アプリケーションのサイズはあまり急激に変わるとは思えないが、対応させる端末だけは今度も増え続けるのは確かだ。
現段階で全キャリア全端末に対応させると考えると、Doja系、MIDP系（Ｖアプリ、EZアプリ、WILCOM）、BREW系と５種類もある。※Symbian向けも開発となると6種類になってしまう。
さらに Doja だけでもバージョンがいくつもあり、またそれぞれの端末毎に癖もある。また、状況によっては、その端末専用チューニングしなければならない状況も出てくるだろう。特にゲームの場合がそうだ。
端末ごとに性能等（CPUやメモリなど）が違うので、それにあわせて最適化して開発しなければならないのだ。

以上の面から考えると３が最適と思える。
ソースは独自言語のもの１つだけですみ、あとはコンパイラが自動でそれぞれの環境ごとにわけて出力できればよいのである。

ただし、問題もある。新しい環境（最近ではWILCOMが追加）が登場するたびにコンパイラに機能追加しなければならない。
それ以上の問題として、そうそう簡単に新しい言語を開発できるものでもないだろう。特にプロジェクトの合間に、片手間で出来るほど簡単ではない。
携帯電話向けアプリケーション専門で開発している会社ならともかく、携帯電話がメインでないのならば、そんな開発時間がとれるかどうか怪しいであろう。

そうすると２のパターンが一番現実的だろうか？
クラスやメソッドを統合させるだけのツールなら、そんなに難しくはない。（ツール作るのが無理だったら、そこは手動で）

まぁ一番良いのは、サイズも気にせずに開発でき、環境（VM？）が統一されているのが一番良いのだろうが、現実的にそれはありえない。
それぞれのキャリアごとに利害があるので、そうそう簡単に統合されるというものでもない。
ただ、いずれは MIDP と Doja が統合された Java 環境（スタープロジェクト？）と BREW 環境との、２つにしぼれるかもしれない。
しかし、Java と BREW の両者が歩み寄るとはいまのところありえないので、対応させる環境は２つ以上であるのは変わりないと思われる。

※ITmedia：DoJaを超えるJava仕様を提供する──ドコモとサンの「スタープロジェクト」

そんな日。

携帯電話向け開発パターン

１．最小限のクラスのみだけで、プログラムを書き上げる。

たとえば、２つのクラスのみでプログラミングする。

• Main クラス：それぞれの環境に対応したクラス。iアプリならば MApplication（IApplication）、Vアプリを含む MIDP アプリならばMIDlet、BREW ならば AEEApplet を継承したクラス
  
• コントロールクラス：アプリケーションの中身をすべてプログラムされたクラス 開発するアプリケーションによっては、この他にデータクラスがあっても良いだろう。

２．オブジェクト指向でプログラミングし、その後、統合する。

PC で C++ や Java でプログラミングしていたように、オブジェクト指向でプログラミングする。このとき、各種対応機種毎の環境に依存した機能は、別クラスで作っておくと移植が楽になるであろう。
プログラムが完成した後、統合する。統合はサイズオーバーしているときだけとする。統合とは、継承先のクラスのメソッド等を継承元（親）クラスへうつしたりすることである。 同様に何度も色々なところで呼び出されるメソッドは別として、あまり呼ばれることにないメソッドは、呼び出しているところへメソッドの中身をコピーしてしまう。このようにすることである。

なお、アプリを作るたびに、このようなことをするのは面倒なので、ツール等を利用し、自動で行っても良いだろう。

３．独自言語（コンパイラ）を開発する。

独自言語（コンパイラ）を開発し、その言語でアプリケーションを開発する。携帯用の独自言語を開発したことで、有名なのはやねう企画の Kascal だろうか。※公開はされていないが。

だいたい、この３パターンではないかと思われる。
１、２、３どのパターンにも一長一短あるが、携帯電話向けのアプリケーションに力を入れているならば、３のパターンが良いだろう。
それは、アプリケーションのサイズだけ考えてプログラミングするのならば、１でも２でも良いのだが、対応させる端末についても考えると３のパターンが良い。

その３へ続く。

そんな日。

いまさら？と言われそうだが、携帯電話向けアプリケーションの開発パターンを考えてみたいと思う。

主な理由は、増え続ける対応機種と、アプリケーションのサイズが一向に大きくならないからである。
WILCOMが携帯アプリケーションのサービスを開始したことにより、よりいっそう対応させる機種が増えてしまった。またFOMA 902iが登場したが、やはりアプリケーションのサイズは１００ｋのままだったのである。このようにサイズを気にしながら、複数の機種に対応させるのは、なかなか骨が折れる開発である。
企業向けである特定機種のみ対応させるならば、サイズだけしか気にしなくても良いだろうが、現実にはそうはいかないことが多々ある。

サイズが小さいということは、PC でのプログラミングのように、サイズを気にせずに開発してしまうと、 実機（携帯電話）で、動作させることが出来ない。 また対応機種が多い上に、開発環境が複数あるのでそれらに対応させるためには、従来の PC 開発のようにはいかないであろう。

その２へ続く。 

そんな日。 

最近のニュースを見ているとライブドアは虚業だけで、まったく技術力がないように印象を持ちますが、意外と技術系の会社です。

といっても、ライブドアは投資会社がテクノロジー部門を持っている、という僕の見解はいまだに変わりませんが。

連日のライブドア関連のニュースによってトラフィックが増加しているにも関わらず、いまだに耐え、サーバーはダウンしていません。（過去には何度か落ちているっぽいですけどね。フレームワークを変更してからは落ちてはいないみたいです）
一 日に数億のページビュー、何万というトランザクションをエラーやサーバーダウンをさせずに運用させるのには、結構技術力がいるものです。それと、技術資産 としては、サーバー増設容易にしたり、DB負荷分散のために独自のサーバーフレームワーク（Sledge）を構築しているようです。
Sledgeについては、Thinkit[シンクイット]というオープンソース関連のサイトに記事が載っています。http://www.thinkit.co.jp/free/tech/9/1/1.html
※なお、このフレームワークは某Bulknewsを作ってた人が構築したみたいです。

そういえば、つい最近ライブドア次世代テクノロジーセミナーというものが開催されました。（去年末だったかな？）
セ ミナーで発表された内容によると、サーバーソフトまわりはFreeBSD 4.x、Apache 1.3、MySQL 4.0、Perl 5.8で構築されているようです。Turbolinuxじゃないんですね^^； livedoor Blog のサーバー構成は、Web サーバー150台、App サーバー120台、DB サーバー250台、その他諸々として20台で構築されているようです。詳しくはネットで検索してください。

ライブドアには、グーグルのようなコアコンピタンスとなる技術はありません。
しかし上記に書いてあるように、サーバー技術に関してはあります。だが、その会社に技術があるかどうかって、コアコンピタンスを持っているかどうかで判断してしまいがちなんですよね。

話 は変わりますが、昨日のCNETによると、ライブドアがブログ検索を新しい検索エンジンに移行したようです。N-gram方式を採用した検索エンジンで、 検索ワードの一部しか知らなくても目的のサイトを見つけられる「部分一致検索」が可能になったようです。また同時にワンクリックで文字サイズを「大」「中」「小」に変更できる機能もつけたようです。

参照記事：http://japan.cnet.com/news/media/story/0,2000047715,20095741,00.htm?ref=rss