趣味・ケータイの最近のブログ記事

ATOKもASPで提供される時代

[ITmediaニュース] goo検索をATOKが支援 キーワード変換候補を“賢く”表示
「gooとATOKが連携してWeb検索を支援!」てな論調の紹介となってます。実際に使ってみるにはこのへんからどうぞ。

なんつーか、斬新ですなぁ。これに近いものとしてはAjax+自然言語技術を統合しているこの人が有名どころでしょうか。その中でも、「Ajaxを使った日本語Full IME」なんかは、力業でよくここまで仕上げたもんだという感想を持ったものです。で、先にニュースを読んだ感じでは、これのATOK版かな、とか思ってたわけです。

がしかし、実際にこの「gooサジェストβ with ATOK」を使ってみて思うのは、IME機能そのものをASPで提供するというよりは、ケータイでよく取り入れられている「推測変換(予測変換)」と国語辞書機能を統合したもの、という印象を受けます。先頭の数文字を入れるだけで単語候補が絞られるのは推測変換と一緒、候補として現れる単語の横にその単語の説明が添えられる、てなインターフェースです。つまり、ATOKがAjax使ってASP的に提供されるというよりは、推測変換+辞書機能がAjaxでASP的に提供されるといった方が近い気がします。

さてさて、このサービスの利用者層を考えてみましょう。明らかにPC上でのIME操作になれていない人がターゲットとなります。初心者向け文字入力支援システムとしては、ケータイのテンキー的なスクリーンをマウスでつつくシステムなんてのもありました。これは、キーボードタイプすら全くできないような人がターゲットであるといえるでしょう。これに対し、今度のはキーボードタイプはちょっとだけならできるけど、タイプミスや漢字変換がおぼつかないような人がターゲットとなるでしょう。

変換精度競争が終わり、関西弁やインターネット連携など新たな機能を模索するJustsystemにとって、いわゆる親指族のためのIMEインターフェースの模索は重要な戦力目標なんでしょうね。

トユーカ、数文字入れるだけでたくさんの単語候補とその単語の意味がずら〜っと出てくるの、なんかコワイくらいにスゴイ気がする。

やたら刺激されたんで、トラックバック送りつつリンクはらせてもらいます。にとよんの技術日誌: iPod+iTunes+iMac に想う

参考リンク

上記のエントリを簡単にまとめると、ホームサーバとしてのiMac、外にあるコンテンツブラウザとしてのiTMS、外と内両方にあるコンテンツブラウザとしてのiTunes、パーソナルモバイルメディアプレーヤ(パーソナルモバイルクライアント)としてのiPod、これらを統括するAppleは次世代コンテンツ流通インフラを制しつつある、てな感じです。まぁ順番に見ていきましょう。

これらの中で一番弱いのがiMacです。根本はMacに対し圧倒的なシェアを持つWindowsというところにあります。AppleはWindow向けにもiTunesを提供するという英断をしており、これが将来DLNAサーバとして機能するようになるかもしれません。が、これとて、Windows MCEやViiv(East Fork)の前では決して優位に立てるとは限りません。内にあるコンテンツのサーバとしてのiMacが一番弱いところでしょう。ビデオ対応iPodの発表と一緒に新iMacも発表しアピールしているのは、こういうところを意識しているのでしょう。

ただ幸いなことに、DLNAガイドラインの枠組みではコンテンツサーバは分散しているのが前提になっています。つまり、5年くらい前から騒がれているホームサーバは家庭内コンテンツのすべてを集約するという思想のもと提案され続け失敗し続けてきていますが、DLNAではコンテンツは分散したサーバが個々に持っていると前提をおいています。

内にあるコンテンツは著作権保護する必要がないため、内にあるコンテンツを保持するサーバはDRMやDTCP-IPを意識する必要がなく、サーバがクライアントのためにリアルタイムトランスコーディングする必要がないです。つまり、内にあるコンテンツのサーバはPCほどのCPUパワーが必要にはなりません。結果、DVRやコンポあたりでも内にあるコンテンツを分散保持していられるはずです。

外にあるコンテンツは著作権保護する必要があります。ホームネットワークで共有するためにはDRMやDTCP-IPを乗り越える必要があります。DTCP-IPの枠組みを考えると、クライアントのためにリアルタイムトランスコーディングする必要があり、結果CPUパワーを持ったPCが有利となります。外にあるコンテンツを保持するサーバは、CPUパワーが豊富であり決済機能を持っていることが求められます。

ViivやWindows MCEは結局、この外にあるコンテンツを保持するサーバの地位を争っていることになります。次世代コンテンツ流通インフラを考えると、そこまで大きなウェイトを占める地位ではないでしょう。・・・とか書いてみたものの、やっぱある程度重要な地位に思えてきた(ぉ) HD DVD/Blu-rayプレーヤは強力なCPUパワー(+GPUパワー:CGやJavaが絡む)が必要だし、デジタルテレビ放送の録画は著作権保護を意識せざるを得ないだろうし(コピーワンスは見直し協議中)。で、なんだかんだで、内のコンテンツより外のコンテンツの方が割合多いだろうし・・・そのためのiTunes+iTMSか?

なんか、書き出したら止まらないぞ(ぉ) まだまだ書きたいことのうち半分も書いていないぞ(ぉ)

外にあるコンテンツブラウザとしてのiTMSの地位は揺るぎないものになってきました。各社メーカがP2Pの違法コピーに頭を悩ませているコンテンツホルダーの顔色をうかがい二の足を踏んでいるうちに、AppleはiPodとiTMSを完全に広めきってしまいました。Appleのうまかったところは既存のMP3などを制限なしにiPodに転送できるようにした点でしょう。ユーザにiPodを買ってもらうための敷居を下げました。ただもちろんそれだけではなく、大量の音楽を徹底的に限界まで安く提供するiTMSも用意しました。買ってきたりレンタルしてきた音楽CDをMP3やAACに変換しアーティスト名と曲名を入れて管理するのは手間がかかることであり、iTMSならそれらがすでに処理されたファイルが簡単に手に入ります。近くの音楽店へそもそも置いているのかどうかすらわからない曲を求め永遠とさまようのは時間のムダであり、iTMSなら簡単に検索できます。しかも、どこの店にも売ってないような古い昔の曲もおいていることが多いです。iTMSは使い勝手の面を相当考えて作っている、と指摘する人も多いです(私は使ってないので何ともいえないんですが)。

iTMSは儲かっていないのは有名な話です。オンライン販売で儲けようとしているコンテンツプロバイダ(≠コンテンツホルダ)は、儲けなど考えていないiTMSには価格では勝てません。AppleはiTMSで音楽を売って儲けようとはしておらず、iPodを売ることで儲けようとしています。まぁそのせいで私的録音録画補償金制度が勃発しているわけですが。

で、上記で音楽だったところが今回動画になりました。Apple自身は以前から、そして今回も、iPodが動画対応したことをあまり積極的にアピールしないようにしています。いぜん音楽が大事だと言い続けています。ただ、iTMSで動画配信まで始まるとなると、皆はiPodが動画に対応したと騒ぎ立てます。ちょっと文化人を気取った人は、音楽と動画は利用スタイルの異なるコンテンツで動画対応は大事でない・音楽が大事だ、とAppleの話を真に受けます。しかし真実は、上記で音楽だったところは「デジタルコンテンツ」だったんですよ。電子書庫サービスにいつ参入するかもしれません、ゲーム配信だってあり得ます。私の頭が固いんでこれ以上出てこないんですが、「デジタルコンテンツ」なら何でもやりかねないことでしょう。一時期「iPod photo」とかいってましたが「iPod」に統一されました、今回の動画対応版も「iPod video」とは名付けられていません(勝手にそう呼んでいる人はいますが)。iPodはデジタルコンテンツのメディアプレーヤであり、決して音楽や動画だけに絞っているわけじゃないんです。この路線が成功すれば、iTMSは外にあるコンテンツのポータルサイトとなることでしょう。

iTunesとは何かを考えると実は難しいんです。ちょこっと調べてみると、「音楽プレーヤーソフト」「音楽管理再生ソフト」あたりが主流ですね。Appleのページには「No.1ミュージックストアを楽しめるデジタルジュークボックス」と書かれています。デジタルジュークボックスという言葉は、今回動画対応したことを意識しているんでしょう。iTunesは、音楽プレーヤだけではなく、音楽管理ソフトだけでもなく、iTMSへの窓口のソフトです。

さて、音楽は「デジタルコンテンツ」に置き換えられます。iTunesは、iTMSで販売されるデジタルコンテンツへアクセスするためのソフトです。まぁちょっと高機能で、デジタルコンテンツをそのまま再生したりiPodに転送したりできます。ここまでなら普通ですが、iTunesはデジタルコンテンツを管理できます。

私はコンテンツ管理ソフトが嫌いです。よく「スキャナで取り込んだ画像を管理するソフト」「デジカメで撮影した写真を管理するソフト」「CDからエンコードした音楽を管理するソフト」「OCRで文字にした文章を管理するソフト」なんてありますが、あのたぐいのものは大嫌いです。そんな私が使っているのは結局Windowsのエクスプローラです。エクスプローラはファイラでしたが、最近はそうでもなく、ムダにプレビュー機能を統合してくれたりしています。つまり、あのたぐいのものを嫌っていながら、使っていたファイラはあのたぐいのものへと向かってたんですよ。

話を戻しましょう。従来のコンテンツ管理ソフトがエクスプローラやiTunesと異なっている点は、ネットワーク対応です。従来のコンテンツ管理ソフトは自分(ソフトの動いているPC)で作り管理しているコンテンツしか再生できませんでした。エクスプローラやiTunesは、ネットワーク対応することにより、他の機器に存在するコンテンツをも再生できます。管理はちょっと微妙ですが検索くらいならできます。このようなソフトを、コンテンツ管理ソフトとまでは呼びきれないので、コンテンツブラウザと呼びましょう。

エクスプローラは、LANやイントラネットを対象にしたコンテンツブラウザでした。いわば内にあるコンテンツのためのブラウザです。iTunesはiTMSのためのソフトです。いわば外にあるコンテンツのためのブラウザです。しかしiTunesはネットワーク共有機能を持っています。これまではネットワーク共有されるのは音楽でしたが、音楽は「デジタルコンテンツ」なので、iTunesはデジタルコンテンツをネットワーク共有できます。つまり、内にあるコンテンツのためのブラウザにもなり得ます。

話がちょっとそれます、DLNAがらみの話でもあります。上のような感じでコンテンツブラウザは整備されつつあるのに、実は検索が非常に弱いままです。Windows(エクスプローラ)の検索機能が弱いのはよく指摘される点ですが、エクスプローラは内にあるコンテンツのブラウザであるため、結果内にあるコンテンツの検索機能が非常に弱いままとなっております。デスクトップ検索ソフトがはやっていたのは1年ほど前ですが、その流れのままイントラネット検索(ホームネットワーク検索)ソフトにまでいってほしかったですね。デスクトップ検索ソフトは自分のPCにあるコンテンツしか検索できません、内にあるコンテンツも検索できるようにしてほしいです。このへんはWinFS頼みだったんですが。というわけで、Appleの次世代コンテンツインフラのためにWinFS開発をがんばってください>MS

さてiPodです。これまでは、iTunesやiTMSはiPodのために用意したものであるという説明を聞き続けてきました。これに対し、上記の説明により、iTunesやiTMSがiPodのため(=iPodの付属品)にすぎないわけがなく、もっと重要な役割を担うことは理解していただけたかと思います。しかしここもAppleのうまかったところ。iTunesやiTMSはiPodのためのものと言い続けてきたのにはわけがあります。iTunesやiTMSをがんばって作っても決して儲からないのです。iTunesやiTMSは次世代コンテンツ流通インフラに不可欠ではありますが、そこから儲けを出そうとしなかったのです。ただの音楽プレーヤや管理ソフトに金出そうと思う人は少ないでしょう、オンライン販売はできるだけ安いところで買いたいでしょう。どれだけ次世代コンテンツ流通インフラに不可欠なものであろうとも、一般ユーザにしてみればただの音楽プレーヤや管理ソフトにすぎないのです。シェアを取るためには安く提供する必要があります、儲けを考えないくらいに。そこで目をつけたのがiPodです。iTunesやiTMSはiPodのためとウソをついて、その間に壮大な次世代コンテンツ流通インフラを構築しようとしているんですよ。

もちろんそのためにはiPodが飛ぶように売れてもらわないと困ります。iPodが飛ぶように売れるようにするためAppleがどんな戦略をしてきたのかというテーマで語らなければいけないところですが、このテーマは実はこれまでにおそらくたくさんの人々に語られてきた話だと思うんで、ここではあえてさけておきます。「実は知らないだけなんだろ?」とか脅迫じみたコメントは容赦なく削除いたします(ぉ) 事実なので反論できないだけです(ぉ)

iPodの背中が見えてきた!  ソニー「ウォークマン」の逆襲」とか笑わせてくれますね。当時朝日新聞でも「iPod vs ウォークマン」とかいう笑わせる記事を見かけました。ソニーは負けました。正確に言うなら、デジタルポータブルオーディオプレーヤ市場におけるブランド争いに負けました。iPodブランドは絶大です。今からがんばったんじゃもう間に合いません。たとえば、「Gigabeatが動画対応!」では誰も見向きもしてくれません。「iPodが動画対応!」ならほっといても一般人が布教してくれます。「Gigabeatッテナニ?」が通常の人の反応です。今からiPod対抗のHDDウォークマンでは視野が狭すぎます。iPod+iTunes+iTMSの次世代コンテンツインフラを意識して切り崩しにかからないと。(と書いてみたものの、Gigabeatってまだ動画対応してなかったのかよ)

そんなiPodの目指している方向は何なんでしょうか。音楽・動画などと来れば、当然ながらPDA的な地位が思い浮かびます。モバイル情報端末としてのPDAのコンセプトは非常に共感できるんですが、いかんせん誰も買いませんでした。近年PDAに取って代わろうな勢いなのがケータイです。ケータイが通話やメールの端末だと思っている人はすでに遅れていて、ケータイは実は音楽・動画・ゲームのための課金プラットフォームです。むろん、PDA的な軸を見据える人もまだいるわけですが、スケジューラやフルブラウザやアドレス帳やPDFビューアを喜んでいるのはコアな人だけでしょうね。おサイフケータイは・・・びみょー、まだよくわからん、向いてる方向は電子決済か?

iPodとPDA(or PDA的なケータイ)との違いは、パーソナルであるかどうかだと思ってます。音楽聴いてる途中で電話が鳴ったりしない、ゲームしてる途中でメールが入ってきたりしない、それがiPodのようなものに求められている機能です。・・・というようなことをどっかの有名な人がBlogで書いてたはずなんだけど、探しても見つからない・・・ケータイにカメラ機能がついたのは、ケータイがパーソナルな端末であることの象徴だと思います

ただし、ケータイがiPodに対し弱いのは、ケータイがキャリアの縛りを受ける点です。キャリアはコンテンツを囲っています。端末がどれだけ高機能化しようとも、コンテンツを持っていないメーカはキャリアの言いなりです。キャリアは以前ケータイは通話とメールの端末であると言い続けているため、iPodのようにパーソナルな端末にはなりきれないでしょう。そういう意味では、PSPやNDSの方がiPodに近いかもしれません。

また、別のケータイが弱い点としては、端末とキャリアのネットワークで閉じてしまっている点でしょう。最近でこそSDカードやUSB接続により内にあるコンテンツを共有できるようになってきましたが、以前はそれすらままなりませんでした。外にあるコンテンツはキャリアが囲っています。キャリアは自社インフラ越しでしか外にあるコンテンツの配信を認めません。こっちもパケット定額制導入によりましにはなりましたが、以前はいわゆるパケ死直結というユーザに優しくなさすぎるプラットフォームでした。これでも先進的なデジタルコンテンツ流通インフラだったんですよ。

そんなわけで、次世代コンテンツ流通インフラを制しつつあるAppleということで話をしてきました。そんなAppleにも弱みがあります。

まずDLNAガイドラインに賛同していないこと。AppleのDRM(FairPlay)をオープンにしていないことにも起因するんだと思いますが、iPod+iTunes+iTMSの自社製品で閉じようとしています。この路線は商売的に危険でしょう。自社以外にも解放するなら、そろそろDLNA賛同だとか表明してほしいところではあります。

次、オンライン販売の利益が薄いこと。上の自社で閉じていることとも関係しますが、最終的に超広く超薄くもうける路線に行きたいんでしょう。問題は、そこまで多くのユーザを抱えられるかどうかです。

最後、iPodにはPCが不可欠であること。これまた自社で閉じていることに関係しますが、iPodにコンテンツを転送しようと思うとiTunesが不可欠です。iTunesはPC(Macも含む)が不可欠です。ただ、この点は利用スタイルにも影響するのでそう簡単には解決できないでしょうね。iPodにEthernetコネクタ(or無線LAN)がついてiPod単体でiTMSにアクセスできるとして、果たしてそれは便利で使いやすいんでしょうか。ケータイは端末単体で通信できるのでこの点で圧倒的に有利です。ただ、ケータイの狭い画面でしか見られない映画なんて好き好んで買う人は少ないでしょうけどね。

さてさて、長々と語ってしまいましたが、最後に、Appleが次世代コンテンツ流通インフラを完成させるための手順について見てみましょう。

まずiTMSの強化があげられます。音楽や動画にとどまらないデジタルコンテンツ全般を網羅する最強のコンテンツポータルに仕上げる必要があるでしょう。

次はiMac(or iTunes)の強化。ホームネットワークまで視野に入れるならiPodやiTunesというプレーヤだけでは少なすぎます。テレビ・HD DVD(Blu-ray)プレーヤといったクライアントにデジタルコンテンツを届けるためのiMac(or iTunes)が必要です。

その次がiTunesの強化。外にあるコンテンツブラウザとして成長してきましたが、ホームネットワークを考えると内にあるコンテンツを見る機能の強化が求められます。NASに蓄えられた孫の写真を手軽に見たい老人の要望には応えるべきでしょう。

最後にiPodの強化。次のデジタルコンテンツが何であるかにもよりますが、たとえばテキストビューアの強化であったりフルブラウザ搭載であったりゲームのためのMIDP対応(Java対応)であったりするでしょう。

以下はタイトル文に合わせるための蛇足。

ここまでを考えると、これまでに考えられてきたホームネットワーク構想に足りなかったものは、コンテンツブラウザとパーソナルモバイルメディアプレーヤです。

DLNAガイドラインの貧弱さにもよるんでしょうが、まずコンテンツブラウザが弱すぎます。DiXiMでコンテンツがどのマシンにあるのかを意識させないインターフェースが実装され評価されたりしてますがそんなの序の口、iTunesのように外にあるコンテンツもシームレスに探せる必要があるでしょう。内か外かを意識させなくてもいいかも。外にしかないなら、買ってホームサーバにDRM保護つきで保存しDTCP-IPでそのままコンテンツブラウザ上で再生できればうれしいでしょうね。むろん、iTMSのように密着したオンラインストアが必須ですが。

で、パーソナルモバイルメディアプレーヤの存在です。現在でも音楽・動画を再生できたり電子書庫を転送できたりする端末はありますが、転送のための敷居が高すぎます。普通のユーザは、AACとかMP3とかWMAとかMPEG2とかMPEG4とか3GPPとかmovとかJPEGとかPNGとかXMDFとかEBKとか意識したいわけがないです。Ethernet端子がついてDTCP-IPで転送?家にいないときはどうするの?USBごしにストリームだけでなくコピーもできないとダメですね。著作権保護問題があるので難しいところでしょうが、iTunes+iPodという閉じた組み合わせだからこそできるわけです。

音声認識+アドレス帳

よく考えたら、ケータイで音声認識利用してアドレス帳を呼び出すだけのVアプリがないわな。まぁ端末自身で対応してたりするやつもあるから、あえて作る必要もないのかなぁ。

実用面を考えると、わざわざVアプリを起動してまで使おうと思ってもらえるだけのアプリにする必要がある。なので、起動早く・起動後即認識モード・認識結果の画面から簡単にメール送信or電話かける操作ができる、というかなりシンプルなアプリでいいんだろうか。

赤外線通信はプロトコルなどを考えるのがめんどいのでパスするとして、カメラやデータフォルダ・アドレス帳・メールフォルダ・音声認識あたりの拡張APIをうまく組み合わせれば、まだまだおもしろそうなアプリを作れるような気がする。そんな可能性があることに気づくのが遅すぎだとかいわないでね。。拡張API自体は1年以上前に公開されてるし。

ケータイ版自動時刻あわせアプリ

アプリゲット掲示板より「電波時計がほしい!まぁ一週間に一回あわせる時計」さすがに電波時計は無理ですが、ちょうどパソコンなどに使われているNTPのようなやつなら作れなくもないかなぁということで検討開始。ちなみに「電波時計」とは、標準電波を自動検出し、また自動的に時計のずれを修正する機能を持つ時計のことです。さらに余談ですが、ビデオデッキなんかではNHK教育の12時正午の時報を検出して時計のずれを直すやつもあったりすますよ。

で話は戻ってケータイです。NTPは通常UDP: 123を使うそうです。当然ケータイでそんなの使えるわけもありません、今のケータイでは事実上インターネットへはHTTPのみです。で調べてみるとこんなページ(JST Clock, www2.nict.go.jp)がありました。JavaScriptからはパソコンの時刻変更はできないため「ずれ」を表示するスクリプトだそうな。

ケータイからこんなサイズ5KBもあるページにアクセスするのははばかるところですが、いいこと思いつきました。HTTP/1.1のメソッドである「HEAD」を使えばヘッダのやりとりだけできるんですよね、しかも相手サーバはレスポンスとしてDateフィールドを返してくれる。リクエストが相手に届くまでの時間とレスポンスが相手から帰ってくるまでの時間が等しいと仮定すると、端末上でリクエストを出す直前の時刻Aとレスポンスが帰ってきた直後の時刻Bの中間の時点がDateフィールドの時刻が書かれた時点と一致なるわけです。(A+B)/2とDateフィールドの時刻を比較して、ずれ分だけ端末の時刻がずれているというわけで修正可能ですね。

やったー完成、と思いきや、ここで致命的なことに気づくわけです。Vアプリ・・・に限らず現在のケータイ端末全般では、Javaから端末上の時刻を変更することができないんですね。orz。こうしてらるるの1日は過ぎてゆくのでした。

時間・時刻・時点・時計、使い分けがややこいの。

ポケベル入力信者

少し前に周りの何人かに聞いたアンケートで、「ポケベル入力方式」が実は2割程度しか認知されていなくて、しかも実際に使ってるのは1割もいないということを知ってしまった。ドコモはムーバ(PDCシリーズ)の全機種でポケベル入力(2タッチ)をサポートするよう仕様として盛り込んでいるというのは有名な話ですが、ことFOMAに限ってはFとD(富士通と三菱)は対応してなかったりと、ポケベル入力方式信者としてはもはや選ぶ機種がなくなってくる危険すら漂う今日この頃です。

いわゆるマルチタップ・かな入力方式と比較してポケベル入力方式の方が効率がよいのを改めていう必要もなく(遠藤諭のケータイ出たとこレポートとかどうぞ)、これだけ「デフォルトがマルチタップ」というインパクトの強さが影響しているのもどうかなぁとか考えさせられるわけです。まぁ世の中、早打ちよりも効率打ち優先となっちゃってるししゃーないかなぁと思うわけですが、V601Tのポケベル入力時の予測変換精度を見ても、やはりポケベル入力をデフォルトとしてもいいじゃないかとかとかとも思わされてしまうわけで。

現に、enjornoではポケベル入力の改良版が「簡単入力」として搭載されてたり、P252iで「二コタッチ」が特徴として紹介されてたり、これからの老人ケータイ市場(言葉が悪い)での簡単入力方式としては、ポケベル+予測変換も十分にありだと思うんですよ。だから、とりあえずポケベル入力方式が消えちゃうのだけは勘弁してください。

とかとか思いながら、mixiのポケベル入力のコミュニティに登録したりしてたら、文章が長くなりすぎちゃいました。ケータイと文字入力・変換にどうでもいいことを書いておきました。

(余計なことを書くのに3時間も時間をとられてしまったorz)

ケータイアプリを作る心境

| コメント(2)

技術系がいい具合に「ピックアップニュース」のほうに移ってきているんで、こっちの日記ではもう少しだらだらした内容を書いてみようかと思う。

わざわざこの日記を見ている人なら、私がケータイ向け(Vodafoneのみだけど)のアプリを作って公開していることを知ってる人は多いと思う。ここみてもらえばどんなのを作っているのかがだいたいわかるでしょう。パソコンを本格的にさわりだしたのは大学入ってから、ちょうど5年半前になるのか。もともとプログラム系をやってみたかったということもあり、HTMLに始まり、JavaScript、コンソールC言語、簡単なJava遊びとやってきた。

転機は大学2年後期の4年前。某友人の某プロジェクトがらみでいろいろと教わった影響で、単なるプログラム遊びとシステム構築の違いなどをかいま見ることができた。オブジェクト指向とはなんたるやが何となく見えてきたのもこのころ。ただ、当時のNTTによる人間廃人化計画の完成系であるテレホの影響もあり、大学の勉強がおろそかになり、それが響いて留年となる。留年回避のため大学3年の時はかなりがんばったんだけどね。

大学4年の時、当時としてはそこそこ最先端だったJ-T51というケータイ端末を買う。で、この端末に電卓が標準搭載されておらず、しかもJ-T51専用サイトで配布しているJava製の電卓があんまりにもうざいという状況に出くわす。「おしゃべり電卓」と名付けられたこのJ-T51専用サイトで配布されたJavaの電卓は、起動に時間かかるわボタン押すと無意味に音が出るわ、しかも無駄に見た目のグラフィックにこだわるわで使いにくいと非常に評判でした。ちなみに、時効だと思うんで白状しちゃいますが、★★J-T51絶対買うぞ!★★PART2スレの1は私です。

そんな電卓に不満を覚えて、自分でJavaアプリで電卓作ったれということでケータイJava(J-PHONEのみ)の仕様を調べ始める。ちょうどこのころJアプリ★ゲットで公開されていた(今は見えない)開発入門記事が大いに助けになった。大学2年の頃の某プロジェクトの甲斐もあって仕様自体はすんなりと理解できました。まぁ開発自体の経験がほとんどなかったので、実際に作る上ではいろいろと苦労しましたが。ケータイJavaではdouble,floatの浮動小数点が使えないということもあって、小数扱える外部ライブラリ探したり結局自分で自作したりとなかなかおもしろい経験となった。結果、起動1秒で動作も軽快な電卓を作れました。まぁ各種関数を使った場合の有効数字は未だに結構怪しいですが。

大学4年の後半頃に初めてLinuxをさわり始める。いろんな小物作りのためにPerlを多用するようになり、結果Apacheの設定やらMySQLやらをちょっとだけ触れるようになりました。でも、未だにSQL構文理解が怪しいのはナイショです。大学5年の今からちょうど1年半ほど前に初自作PC組んだことで、ハードウェアについて一通りわかったような気になりました。そんな知識を生かし、現在rarul.comサーバは自宅サーバとして運用されてます。なので、ちょっと設定ミスったり雷で停電したり犬が回線を引っこ抜いたりすると、たちまちrarul.comはインターネットの墓場と化します。

まぁそんな経緯があって、今はstViewerというテキストビューア作ったりしているわけです。ケータイアプリを作る上では有料化するという選択肢もあるんですが、よほどの作り込みのあるアプリか私が生活に困るほどにならない限りは有料でアプリ提供するつもりはありませんね。いいとこ「カンパウェア」でしょう。有料にするとユーザも敬遠するし、こんなアプリはお金取れるほどのものとも思えないし、有料による「しがらみ」(金払ってるんだからサポート・機能拡張バグ取りしろといわれること)も受けたくないですし、何よりこれまで多くのお金いらないソフト使わせてきてもらってるわけですし。特に最後、数多くのソフトがあるんで全部上げ切れないですが、現状ではK2Editorをあげときます。テキスト類は全部このテキストエディタを使わせてもらってます。

文章の最初と最後でですます体が変わっていても(゜ε゜)キニシナイ

Vアプリ256K ver.2で変わったところ

Vアプリ256K ver.2向けの開発ドキュメント類が更新されてます。ver.2, ver.2と言われるだけで実際には256K(=J-SH53/V601SH)と比べてどこが変わったのかよくわからなかったんですが、今回のドキュメントで具体的にどのあたりが変わったのかが見えてきたんで簡単にメモっときます。「新機能導入の手引き2004 〜P6型端末編〜」というPDFのドキュメントにまとめてあります。。・・・・ということは、W-CDMA端末であるVGS向けのドキュメントも裏では存在するんでしょうか。。まぁそれは置いといて・・・

・英語の音声認識対応に拡張(API追加)
MA5対応
3DポリゴンエンジンVer.4対応(機能拡張)
・V-kara関連に新規対応
・グラフィック関連機能拡張(拡大縮小・マスクパターンタイルによる疑似半透過・明度調整・色調反転・モノクログレースケール変換・単色変換)→API追加
・タイマー起動アプリの廃止
・オフスクリーン(Image)の描画を規定内で高速化

私3D関連はいじったことがないのでこれは置いといて、追加されたAPI関連は以下です。
・com.j_phone.io.VoiceRecognition
・com.j_phone.util.GraphicsUtil
・com.j_phone.util.ImageUtil

で、追加されたMIDlet属性です。
・MIDxlet-LCD-Sync
・MIDlet-Karaoke
「MIDxlet-LCD-Sync」は、Zentek(PC向けエミュを提供してる会社)のエミュレータのドキュメントでは「MIDlet-LCD-Sync」と書かれてるんですが、これはたぶんZentek側のドキュメント記載ミスでしょう。で、MIDxlet-LCD-Syncが何のために利用するのかがよくわからんのですが。。描画の同期を取るとか曖昧でよくわからん。

まとめると、ver.2という名前だけあってたいした機能拡張はなされてないようですね。一番大きいのは3D関連かと思います。まぁver.2も、MIDP2.0準拠のVSCL2.0環境と端末が出るまでの短い運命です。・・・というかJSCL全部消えちゃうんですよね・・・?

このアーカイブについて

このページには、過去に書かれたブログ記事のうち趣味・ケータイカテゴリに属しているものが含まれています。

前のカテゴリは趣味・キーボードです。

次のカテゴリは趣味・ゲームです。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

月別 アーカイブ

ウェブページ

Powered by Movable Type 5.2.13