Eclipseで良いPHP開発環境が無いかと思って探したのですが、まずはZendのPHP IDEを試そうとしたところ、何しろ他feature/pluginのrequirementが多いのなんの。で、色々と苦労して必要な機能を導入したのですが、EMF(Eclipse Modeling Framework)のバージョン2.3が入っているのに、「EMF 2.2もしくは同等版が存在しない」と文句を言われる始末。
面倒なので一旦Eclipseをフォルダごと削除し、再びPHP IDEありきでセットアップ再開ですわ。。。orz
2006年12月31日日曜日
Eclipse日本語化成功
やはり、eclipse.iniを探し出さねばと思い、アプリケーション(/Applications)以下でfindしたところ、なんとFinderからは普通には辿れない(っぽい)Eclipse.appというディレクトリの下にeclipse.iniを発見。
見事日本語化に成功しました。しかも、起動時のスプラッシュスクリーンが変わってるし。。。凄いな、このPleiadesっていうプラグイン。
見事日本語化に成功しました。しかも、起動時のスプラッシュスクリーンが変わってるし。。。凄いな、このPleiadesっていうプラグイン。
2006年12月29日金曜日
Eclipseが日本語化出来ん
Eclipseには素晴らしい日本語化パッケージがありますが、残念ながらWindows向け、もしくはGTK+向け(実質Intel Linux及びIntel Solaris向けらしい)しか無く、MacOS Xの場合は手が出ない。
そして、エクリプスで拝見したMacOS X向けのローカライズ方法も試したが、上手く日本語化出来ん。しかも、修正しろと書かれている"eclipse.ini"なるファイルが見つからん・・・orz
探し方が悪いのかな。
そして、エクリプスで拝見したMacOS X向けのローカライズ方法も試したが、上手く日本語化出来ん。しかも、修正しろと書かれている"eclipse.ini"なるファイルが見つからん・・・orz
探し方が悪いのかな。
来年のコンピューティングの潮流は?
2007年もマルチコア化と仮想化が大きな潮流に
IntelがNetBurstアーキテクチャを用いた(主にクロックの向上による)プロセッサの高速化を断念してマルチコアプロセッサへ舵を切ったこともあり、IntelやAMDというPC向けプロセッサだけでなく、SunのUltra SPARC T1 (コードネームNiagara)も加わって、時代はマルチコアプロセッサ一色といった感じ。
PCだけでなく現在はMacもIntelにプロセッサを切り替え、現行のモデルではCore2 Duoというデュアルコアプロセッサを標準搭載している状況なので、既にコンシューマ向けは少なくともデュアルコア、ハイエンドではクアッドコアのプロセッサを搭載している事が当たり前になりそうだ。
ただ、問題はこの記事でも指摘されている通り、同時に多数のタスク(プロセスもしくはスレッド)を処理する事が使命であるサーバに対して、コンシューマ向けのPC(もしくはMac)ではそれ程の同時処理能力が要求されていないのが現状だと思われる。それには、マルチスレッド化されたコンシューマ向けアプリケーションが少ない事が原因であり、さらに進めるとアプリケーションをマルチスレッド化する事が面倒くさいというのが原因なのではないかと思う。
実際にマルチスレッドのアプリケーションを書いてみるとすぐに分かるが、スレッド間での同期やリソース共有というマルチスレッドアプリケーションに特有の難しさがあり、その為余程のメリットが得られるのでなければ敢えてマルチスレッド化しないというのが普通だろう。
従って、今後はますます採用が進むマルチコアプロセッサを活かす為に、マルチスレッドアプリケーションをより容易に開発する為の支援ツール等の登場が望まれるのではないだろうか。さもないと、コンシューマ向けPCに搭載されたマルチコアプロセッサは、単なる宝の持ち腐れになり兼ねない。
ちなみに、Windows XPやVistaがマルチタスクOSだからマルチコアプロセッサの恩恵を得られる、というのは、理屈としては正しいが現実的には間違っている。主に人間とのインタラクションを行う対話型のアプリケーションが多いコンシューマ向けの環境では、厳密にはほとんどのプロセッサ実行時間においてその負荷はかなり低い。実際の所、音楽や動画のエンコーディング以外のタスクでは、あまりプロセッサの負荷は上がらないだろう。
例外としては、ソフトウェアでシミュレーションを行う様な、特殊な人々(ソフトウェア開発者やソフトウェア関連の研究者)にとってはマルチコアプロセッサは役立つかも知れない。
話が脱線してしまったが、要するにマルチスレッドアプリケーションの開発支援ツールが必要だ、ということである。そういう意味では、何だかんだ言ってJavaのマルチスレッドサポートは素晴らしいので、これからはJavaがまた流行るかも知れない。C#は全く知らないので何とも言えないが。
IntelがNetBurstアーキテクチャを用いた(主にクロックの向上による)プロセッサの高速化を断念してマルチコアプロセッサへ舵を切ったこともあり、IntelやAMDというPC向けプロセッサだけでなく、SunのUltra SPARC T1 (コードネームNiagara)も加わって、時代はマルチコアプロセッサ一色といった感じ。
PCだけでなく現在はMacもIntelにプロセッサを切り替え、現行のモデルではCore2 Duoというデュアルコアプロセッサを標準搭載している状況なので、既にコンシューマ向けは少なくともデュアルコア、ハイエンドではクアッドコアのプロセッサを搭載している事が当たり前になりそうだ。
ただ、問題はこの記事でも指摘されている通り、同時に多数のタスク(プロセスもしくはスレッド)を処理する事が使命であるサーバに対して、コンシューマ向けのPC(もしくはMac)ではそれ程の同時処理能力が要求されていないのが現状だと思われる。それには、マルチスレッド化されたコンシューマ向けアプリケーションが少ない事が原因であり、さらに進めるとアプリケーションをマルチスレッド化する事が面倒くさいというのが原因なのではないかと思う。
実際にマルチスレッドのアプリケーションを書いてみるとすぐに分かるが、スレッド間での同期やリソース共有というマルチスレッドアプリケーションに特有の難しさがあり、その為余程のメリットが得られるのでなければ敢えてマルチスレッド化しないというのが普通だろう。
従って、今後はますます採用が進むマルチコアプロセッサを活かす為に、マルチスレッドアプリケーションをより容易に開発する為の支援ツール等の登場が望まれるのではないだろうか。さもないと、コンシューマ向けPCに搭載されたマルチコアプロセッサは、単なる宝の持ち腐れになり兼ねない。
ちなみに、Windows XPやVistaがマルチタスクOSだからマルチコアプロセッサの恩恵を得られる、というのは、理屈としては正しいが現実的には間違っている。主に人間とのインタラクションを行う対話型のアプリケーションが多いコンシューマ向けの環境では、厳密にはほとんどのプロセッサ実行時間においてその負荷はかなり低い。実際の所、音楽や動画のエンコーディング以外のタスクでは、あまりプロセッサの負荷は上がらないだろう。
例外としては、ソフトウェアでシミュレーションを行う様な、特殊な人々(ソフトウェア開発者やソフトウェア関連の研究者)にとってはマルチコアプロセッサは役立つかも知れない。
話が脱線してしまったが、要するにマルチスレッドアプリケーションの開発支援ツールが必要だ、ということである。そういう意味では、何だかんだ言ってJavaのマルチスレッドサポートは素晴らしいので、これからはJavaがまた流行るかも知れない。C#は全く知らないので何とも言えないが。
2006年12月27日水曜日
Samba開発者がNovellからGoogleへ移籍
NovellのSamba開発者、Microsoftとの提携に抗議の退社──Googleへ移籍
漢(おとこ)だ。。。
確かに、NovellがMicrosoftと提携した例の一件は、私もどうなのかと思っていた。 オープンソースがMSの特許を侵害しているとか、それに伴って訴訟を起こすなんて話は、はっきり言ってMSのブラフに過ぎないだろうと思われる。しかし、法的に白黒をつける前にお金を払ってバンザイしてしまったのがNovellだ。
そういう意味で、Samba開発者として彼はこの提携に耐えられなかったのだろう。 SMBプロトコルを開示しないMSに対して、パケットダンプやネットワークアナライザで対抗してSambaを開発してきた(と私は聞いた)男の中の男であるSamba開発者としては、MSの脅しの前に簡単にバンザイしてしまったNovellの行為は裏切りとも取れるだろう。
しかし、今回のGoogleへの移籍は、私を含めたSambaユーザにとって良いことかも知れない。
Googleは、MSに対抗する砦として堅固であるだろうし、まだまだMSとやりあう気がマンマンであろうからだ。
Googleの豊富な資金力とオープンソースソフトウェアに対する敬意をもって、Sambaの開発がより加速されることを切に祈りたい。
漢(おとこ)だ。。。
確かに、NovellがMicr
そういう意味で、Samba開発
しかし、今回のGoogleへの
Googleは、MSに対抗する
Googleの豊富な資金力とオ
2006年12月22日金曜日
PASMOは来春開始
関東のJRも私鉄もバスも1枚で——PASMO、3月18日スタート
遂にPASMOが始まる模様。JRがSUICAを始めて、「便利だな〜。地下鉄も始めないかな〜」と思っていたが、やっとと言った感じだ。相互運用性も当初から確保されている様だし、これは広まるのも早いかな。
最近、東京メトロはECHIKAとか言って駅構内のモールを作ったりしているし、こういうところで使える電子マネーにもなるのだろうな。。。ま、とにかくSUICAとパスネットを二枚持たなくて良いだけでもありがたいわ。
遂にPASMOが始まる模様。JRがSUICAを始めて、「便利だな〜。地下鉄も始めないかな〜」と思っていたが、やっとと言った感じだ。相互運用性も当初から確保されている様だし、これは広まるのも早いかな。
最近、東京メトロはECHIKAとか言って駅構内のモールを作ったりしているし、こういうところで使える電子マネーにもなるのだろうな。。。ま、とにかくSUICAとパスネットを二枚持たなくて良いだけでもありがたいわ。
2006年12月19日火曜日
ソフト開発におけるあれこれ
どうしたら日本のソフトづくりは強くなれるか?
私はソフトとは言ってももっぱらSIでのカスタム開発だったので、製品開発の経験は無い。ただ、人月見積の問題点というのはとてもよく分かる。
「どうしたら日本のソフトづくりは強くなれるか? 黒岩氏のアドバイスは明快である。こまかなPDCAのマネジメントサイクルを作り出すこと。ここでいうマネジメントとは、統制や管理ではなく、改善への支援という緩やかなものだ。その結果生み出される明るい職場が、生産性向上に果たす役割は大きい。」
ここでとても共感できるのは「統制や管理ではなく」という点だ。SIでは、痛い目を見ればみるほど、よりきつい管理を行ってリスクを排除しようとする。しかし、そのせいでかえって管理コストが増大し、プロジェクトマネージャがボトルネックになって疲弊していったり、また管理のきつさによって現場の開発メンバーもモチベーションや生産性が低下する、というのはよくあるようだ。私も個人的に体験した事が何度かある。
ここで書かれている「生産性向上」というのが、一つのポイントを端的に表していると思う。
つまり「よりメンバの性能を発揮する」ことを目指しているわけである。しかし、「統制や管理」では、どちらかと言うと「よりメンバのミスを無くす」ということを目指している様に思う。
非常にシンプルに言ってしまえば、前者は加点法、後者は減点法に近いかも知れない。しかし、そう考えると両者の場合のメンバのモチベーションがどうなるかは、容易に想像がつく。
減点法では、人はのびのびと働く事は出来ない。
正直言って、ソフト開発、特にSIの現場では、どうやったら成功できるのかさっぱり分からない。むしろ、私は「SIは失敗するし儲からない物」であると割り切っている。だから、個人的にはもうSIはやりたくないのである。
私はソフトとは言ってももっぱらSIでのカスタム開発だったので、製品開発の経験は無い。ただ、人月見積の問題点というのはとてもよく分かる。
「どうしたら日本のソフトづくりは強くなれるか? 黒岩氏のアドバイスは明快である。こまかなPDCAのマネジメントサイクルを作り出すこと。ここでいうマネジメントとは、統制や管理ではなく、改善への支援という緩やかなものだ。その結果生み出される明るい職場が、生産性向上に果たす役割は大きい。」
ここでとても共感できるのは「統制や管理ではなく」という点だ。SIでは、痛い目を見ればみるほど、よりきつい管理を行ってリスクを排除しようとする。しかし、そのせいでかえって管理コストが増大し、プロジェクトマネージャがボトルネックになって疲弊していったり、また管理のきつさによって現場の開発メンバーもモチベーションや生産性が低下する、というのはよくあるようだ。私も個人的に体験した事が何度かある。
ここで書かれている「生産性向上」というのが、一つのポイントを端的に表していると思う。
つまり「よりメンバの性能を発揮する」ことを目指しているわけである。しかし、「統制や管理」では、どちらかと言うと「よりメンバのミスを無くす」ということを目指している様に思う。
非常にシンプルに言ってしまえば、前者は加点法、後者は減点法に近いかも知れない。しかし、そう考えると両者の場合のメンバのモチベーションがどうなるかは、容易に想像がつく。
減点法では、人はのびのびと働く事は出来ない。
正直言って、ソフト開発、特にSIの現場では、どうやったら成功できるのかさっぱり分からない。むしろ、私は「SIは失敗するし儲からない物」であると割り切っている。だから、個人的にはもうSIはやりたくないのである。
GoogleOSに関する妄想、再び
うわさの尽きないGoogleOS:結局のところ何が出てくる?
分かる分かる。この手の妄想をしたくなってしまう気持ち。ただ、この記事の最後にまとめてある様に、Googleが何かの具体的なアクションを起こす可能性が高い事は、それなりに納得のいく理由で裏付けられると思う。Googleにとっては、MSのサーチエンジンが普及しては困るのは自明の理であるし。
私の個人的な感覚としては、三番目のアイデア「ライトなLinuxベースのOS」あたりがありそうな案だと思う。カスタマイズしたLinuxディストリビューションを出すのではあまりに捻りが無いし、それに記事にもある様にGoogleは今までに、Gmail、Docs、SpreadsheetなんかのサービスをWebアプリとしてリリースしており、今更クライアントサイドにフルセットのOSを乗せなければならない必然性は無いと思う。
これはいわゆる「シンクライアント」の話に関連するが、シンクライアントではいかにクライアントサイドの管理コストを減らすか、という点が一つのポイントであり、そういう意味ではクライアントサイドにフルセットのOSが存在する限り、管理コストは減らない訳だ。しかし、Firefoxが動作するだけのシンプルかつシングルタスクなOSであるならば、かなり管理コストは減って、シンクライアントに近い感じになるのではないか。
Googleがシンクライアントを目指しているのかと言われると、それはきっとNoなのだろうけれど、それにしても彼らには「サーバサイドで検索技術をフル活用したアプリを」という信念がある様に思えるし、アプリがサーバサイドにある以上は、シンクライアント的な発想になるのは自然な事だと思う。
さて、そこでやはりGoogleの次の一手に話が戻るが、以前私が妄想した様に
なんか、知らないうちにこういう事が水面下で進行してるんじゃないのかな〜。どうなんだろうか。
分かる分かる。この手の妄想をしたくなってしまう気持ち。ただ、この記事の最後にまとめてある様に、Googleが何かの具体的なアクションを起こす可能性が高い事は、それなりに納得のいく理由で裏付けられると思う。Googleにとっては、MSのサーチエンジンが普及しては困るのは自明の理であるし。
私の個人的な感覚としては、三番目のアイデア「ライトなLinuxベースのOS」あたりがありそうな案だと思う。カスタマイズしたLinuxディストリビューションを出すのではあまりに捻りが無いし、それに記事にもある様にGoogleは今までに、Gmail、Docs、SpreadsheetなんかのサービスをWebアプリとしてリリースしており、今更クライアントサイドにフルセットのOSを乗せなければならない必然性は無いと思う。
これはいわゆる「シンクライアント」の話に関連するが、シンクライアントではいかにクライアントサイドの管理コストを減らすか、という点が一つのポイントであり、そういう意味ではクライアントサイドにフルセットのOSが存在する限り、管理コストは減らない訳だ。しかし、Firefoxが動作するだけのシンプルかつシングルタスクなOSであるならば、かなり管理コストは減って、シンクライアントに近い感じになるのではないか。
Googleがシンクライアントを目指しているのかと言われると、それはきっとNoなのだろうけれど、それにしても彼らには「サーバサイドで検索技術をフル活用したアプリを」という信念がある様に思えるし、アプリがサーバサイドにある以上は、シンクライアント的な発想になるのは自然な事だと思う。
さて、そこでやはりGoogleの次の一手に話が戻るが、以前私が妄想した様に
- かなり性能と機能を絞ったH/W
- 極めてライトウェイトなOS
- その上で稼働するウェブブラウザ
- AJAXでリッチ化されたウェブアプリ
なんか、知らないうちにこういう事が水面下で進行してるんじゃないのかな〜。どうなんだろうか。
2006年12月12日火曜日
WebLogicと仮想化
BEA、仮想化技術に対応したJava APサーバ「WebLogic Server Virtual Edition」を発表
ぬあ?と思って読んでしまったニュース。
WebLogicが仮想マシン上で直接稼動??何じゃそりゃ???といった感じ。
VMWareにおけるHypervisorの説明(Hypervisor, part of ESX Server virtualization)を読むと、どうやらHypervisorとは仮想化レイヤを抽象化する(<=書いてて「んあんじゃそりゃ!?」と一瞬思う)物らしい。Hypervisorより下にはOSが無く、直接H/Wらしい。
そうすると、ここからは想像だが、WebLogic Server Virtual Editionのスタック構造は以下の様になると思われる。
まぁ、仮想化云々はとりあえず置いておくと、この構図が真だとすれば、以下の等式が成り立つ様な構造が出来上がることになる。
WLS + JRockit + Liquid VM = Applications + OS + VMWare VM
つまり、WLS Virtual Editionはある仮想化された空間で唯一稼動するプロセスであり、その中でJavaのスレッドが動作することになる。イメージとしては、シングルプロセス内に複数のタスク(要するにスレッド)が稼動するμITRONアプリケーションみたいな感じだろうか。
ん?本当か?
ただ、理論的に上記のやり方を行うメリットは裏付けることが出来ると思う。
まず、WLSをVMWare VM上のOS内で稼動させると、WLSはJava VM上で稼動しかつJava VMは1つのプロセスとして稼動するから、OS内で発生するプロセススケジューリングによるコンテキストスイッチ、それに伴うパフォーマンス劣化が避けられない。
しかし、WLS Virtual Editionでは、WLS及びそこに搭載された全てのアプリが単一プロセスとして動作し、スレッド切り替え時にもコンテキストスイッチは発生しない。従って、WLS上で稼動するアプリのパフォーマンスは、確実に上がると思われる。
なるほど。確かに面白いかも知れない。
# VMWare ESX Serverについて知れたのも収穫
ぬあ?と思って読んでしまったニュース。
WebLogicが仮想マシン上で直接稼動??何じゃそりゃ???といった感じ。
VMWareにおけるHypervisorの説明(Hypervisor, part of ESX Server virtualization)を読むと、どうやらHypervisorとは仮想化レイヤを抽象化する(<=書いてて「んあんじゃそりゃ!?」と一瞬思う)物らしい。Hypervisorより下にはOSが無く、直接H/Wらしい。
そうすると、ここからは想像だが、WebLogic Server Virtual Editionのスタック構造は以下の様になると思われる。
- WebLogic Server (Java based middleware: 以下WLS)
- JRockit (Java VM)
- Liquid VM (a replacement of a normal VMWare's virtual machine)
- VMWare Hypervisor
- H/W
まぁ、仮想化云々はとりあえず置いておくと、この構図が真だとすれば、以下の等式が成り立つ様な構造が出来上がることになる。
WLS + JRockit + Liquid VM = Applications + OS + VMWare VM
つまり、WLS Virtual Editionはある仮想化された空間で唯一稼動するプロセスであり、その中でJavaのスレッドが動作することになる。イメージとしては、シングルプロセス内に複数のタスク(要するにスレッド)が稼動するμITRONアプリケーションみたいな感じだろうか。
ん?本当か?
ただ、理論的に上記のやり方を行うメリットは裏付けることが出来ると思う。
まず、WLSをVMWare VM上のOS内で稼動させると、WLSはJava VM上で稼動しかつJava VMは1つのプロセスとして稼動するから、OS内で発生するプロセススケジューリングによるコンテキストスイッチ、それに伴うパフォーマンス劣化が避けられない。
しかし、WLS Virtual Editionでは、WLS及びそこに搭載された全てのアプリが単一プロセスとして動作し、スレッド切り替え時にもコンテキストスイッチは発生しない。従って、WLS上で稼動するアプリのパフォーマンスは、確実に上がると思われる。
なるほど。確かに面白いかも知れない。
# VMWare ESX Serverについて知れたのも収穫
Macあれこれ
MacBookはどこで買うのが安全か?
次はもうPCはやめてMacBookにしよう!と思っていた矢先に。。。
なんか、サポート酷いみたいですね。あと、製品の品質もかなりバラつきがある様ですね。まぁ、良い製品を掴んだ方はラッキー、というところなんでしょうか。
日本人は品質に煩いですから、PCからMacへの移行は、もしかすると日本車から外車へ乗り換えるような覚悟がいる行為なのかも知れませんね。「すぐに壊れるけどLexusよりBMWが良いわ!」ってな感じです。
う〜ん。どうしたものか。
でも、仕事でどうせPC使うんだし、やっぱ私物はMacBookが良いなあ、、、
次はもうPCはやめてMacBookにしよう!と思っていた矢先に。。。
なんか、サポート酷いみたいですね。あと、製品の品質もかなりバラつきがある様ですね。まぁ、良い製品を掴んだ方はラッキー、というところなんでしょうか。
日本人は品質に煩いですから、PCからMacへの移行は、もしかすると日本車から外車へ乗り換えるような覚悟がいる行為なのかも知れませんね。「すぐに壊れるけどLexusよりBMWが良いわ!」ってな感じです。
う〜ん。どうしたものか。
でも、仕事でどうせPC使うんだし、やっぱ私物はMacBookが良いなあ、、、
2006年12月11日月曜日
ワンセグとビジネス
最近の携帯電話端末には、いわゆるワンセグ視聴機能が付いている端末も増えてきた。
私はauユーザなのだが、例えばW44S、W43SA、W43Hなんかがワンセグ対応の最新機種だ。
ところで、携帯電話の端末へのワンセグ視聴機能搭載は全く否定しないのだが、この機能がもたらす「端末製造メーカーへのメリット」とは何なのかがちょっと気になる。
携帯電話というサービスモデルにおける登場エンティティは、主に以下の様な感じだろう。
さて、ワンセグ視聴機能とは基本的には「地上波ディジタル放送」の視聴機能なので、垂れ流されるディジタル放送の電波を拾って画面に表示する為の機能だ。つまり、ユーザが勝手に電波を拾ってそれを無償で見ているわけだ。
これだけでは、キャリアにとっても端末メーカーにとっても直接のメリットは無い。直接のメリットとはつまり、ワンセグ視聴に対してリニアに反応するような売り上げは上がらないということだ。何しろ、視聴は無料だし端末は買い切りだから、視聴の為に後から支払うお金は強いて言えば端末のバッテリの充電に使う電気代くらいだ。
したがって、ワンセグ視聴対応機能を携帯端末に追加しても、「この端末ではワンセグが見られます」というだけの付加価値しか提供できないわけで、極端な話全てのキャリア、メーカーからワンセグ対応の端末がリリースされてしまえば、ワンセグ対応は差別化の要素にはならなくなってしまう。
まぁ、コモディティ化してしまう、と言ってしまえばそれまでなのだが、これだけではあまり面白い解決策とは言えない。
そもそも、ネットワークが発達して双方向通信が可能となった現代において、ダウンストリーム限定の垂れ流し通信である「放送」という物のあり方が問われているのかも知れない。
*****
(12/11 16:50追記)
「ワンセグ」じわり普及 放送と通信連携、手探り否めず
やはり、文中にもある様に「携帯各社は対応端末が増えても通信料が増えなければ、開発費だけが積み重なり、稼ぎが減りかねない。」という懸念は依然として強い様だ。
通信量が増えないと結果的にキャリアは儲けにならないわけで、儲けにならない場合は端末開発のコスト増や端末頒布の為のリベート負担についても厳しくならざるを得ないのだろうと容易に想像できる。
私はauユーザなのだが、例えばW44S、W43SA、W43Hなんかがワンセグ対応の最新機種だ。
ところで、携帯電話の端末へのワンセグ視聴機能搭載は全く否定しないのだが、この機能がもたらす「端末製造メーカーへのメリット」とは何なのかがちょっと気になる。
携帯電話というサービスモデルにおける登場エンティティは、主に以下の様な感じだろう。
- キャリア
- 端末メーカー
- コンテンツプロバイダ
- ユーザ
さて、ワンセグ視聴機能とは基本的には「地上波ディジタル放送」の視聴機能なので、垂れ流されるディジタル放送の電波を拾って画面に表示する為の機能だ。つまり、ユーザが勝手に電波を拾ってそれを無償で見ているわけだ。
これだけでは、キャリアにとっても端末メーカーにとっても直接のメリットは無い。直接のメリットとはつまり、ワンセグ視聴に対してリニアに反応するような売り上げは上がらないということだ。何しろ、視聴は無料だし端末は買い切りだから、視聴の為に後から支払うお金は強いて言えば端末のバッテリの充電に使う電気代くらいだ。
したがって、ワンセグ視聴対応機能を携帯端末に追加しても、「この端末ではワンセグが見られます」というだけの付加価値しか提供できないわけで、極端な話全てのキャリア、メーカーからワンセグ対応の端末がリリースされてしまえば、ワンセグ対応は差別化の要素にはならなくなってしまう。
まぁ、コモディティ化してしまう、と言ってしまえばそれまでなのだが、これだけではあまり面白い解決策とは言えない。
そもそも、ネットワークが発達して双方向通信が可能となった現代において、ダウンストリーム限定の垂れ流し通信である「放送」という物のあり方が問われているのかも知れない。
*****
(12/11 16:50追記)
「ワンセグ」じわり普及 放送と通信連携、手探り否めず
やはり、文中にもある様に「携帯各社は対応端末が増えても通信料が増えなければ、開発費だけが積み重なり、稼ぎが減りかねない。」という懸念は依然として強い様だ。
通信量が増えないと結果的にキャリアは儲けにならないわけで、儲けにならない場合は端末開発のコスト増や端末頒布の為のリベート負担についても厳しくならざるを得ないのだろうと容易に想像できる。
携帯の買い替え時
KDDI、デジタルラジオ&ワンセグ対応「W44S」を発売開始
今日は、たまたまauの販促キャンペーンにぶち当たって、思わずビンゴなんかやったりして販促品のLISMO!タオルをゲットしようとしたのだが、思いっきり失敗したりして(-v-)。
さて、W44Sは「ヒンジが変」、「ごつい」、「厚い」といったありがちな批判もまったくごもっともな形状なのだが、実際どんなものかと思って販促キャンペーンのデモ機を試してみたところ、意外とワンセグって画質良くないのね、ということが分かった。いわゆる、ローパワーのCPUで無理やりMPEG2をソフトウェアデコードした際に発生する様な、ブロックノイズ(?)がたまに発生する。これは携帯端末のハードウェア的な制約なのかも知れないが、ともかく最新機種のW44Sをもってしてもその様な感じであるわけだ。
現在、発表から1年半ほど経過したW31Tを使っている私としては、そろそろ端末買い替えの良い時期にあたるのだけれど、どうしたものかと悩み中だ。とりあえず、上記のような感じなのでW44Sは構想から外れたかなあ、といった感じ。
更に現在使っているBluetoothのハンズフリーも、Bluetooth対応端末が最新でW44Tになってしまう為、今日のキャンペーンでは実機にも触れなくてちょっと困った。何しろ、東芝からはW45TとW47Tも出ているのだ。暫く待ったらBluetooth対応の最新機種が出てくれるのだろうか。。。
今日は、たまたまauの販促キャンペーンにぶち当たって、思わずビンゴなんかやったりして販促品のLISMO!タオルをゲットしようとしたのだが、思いっきり失敗したりして(-v-)。
さて、W44Sは「ヒンジが変」、「ごつい」、「厚い」といったありがちな批判もまったくごもっともな形状なのだが、実際どんなものかと思って販促キャンペーンのデモ機を試してみたところ、意外とワンセグって画質良くないのね、ということが分かった。いわゆる、ローパワーのCPUで無理やりMPEG2をソフトウェアデコードした際に発生する様な、ブロックノイズ(?)がたまに発生する。これは携帯端末のハードウェア的な制約なのかも知れないが、ともかく最新機種のW44Sをもってしてもその様な感じであるわけだ。
現在、発表から1年半ほど経過したW31Tを使っている私としては、そろそろ端末買い替えの良い時期にあたるのだけれど、どうしたものかと悩み中だ。とりあえず、上記のような感じなのでW44Sは構想から外れたかなあ、といった感じ。
更に現在使っているBluetoothのハンズフリーも、Bluetooth対応端末が最新でW44Tになってしまう為、今日のキャンペーンでは実機にも触れなくてちょっと困った。何しろ、東芝からはW45TとW47Tも出ているのだ。暫く待ったらBluetooth対応の最新機種が出てくれるのだろうか。。。
2006年12月8日金曜日
IT投資≒バクチ(?)
IT投資はバクチ並に難しいのである
まさにこちらの著者の仰る通りなのである。
最近はすっかり離れてしまったけれど、私もかつてはSEだのITコンサルだのといった職種で、顧客の企業システム開発を担当していたわけだが、この(短いけど濃いぃ)経験からも、この記事の仰ることは非常に納得が行く。
まぁ、この記事で「こうしない方が良い」と指摘されているポイントは、個人的にはいわゆる「ウォーターフォール型開発」で典型的なやり方なのだと思う。長期間(半年〜1年)使って要件を定義し、設計し、それを実装に落とす。一度に決まる要求は「業務全部に渡る」なんて大規模なことはザラで、まさに「やっちゃいけないポイント」満載だ。
ただ、これはITベンダや開発者側の意識として認識すべき問題であることに異論は無いのだが、この記事で指摘している事項を実施するには、どちらかと言うと発注側の意識改革や業務改革がより求められるのかな、と感じた。
というのも、発注側は既存のシステムもしくは既存の(システム化されていない)業務フローの問題点を集積し、それがある程度の閾値を超えたところで予算確保し、それに基づいてシステム開発(改善)に入っていると思われるからだ。
発注側の予算確保がそういうやり方だと、どうしたって「まとまった予算」で「まとまった機能を開発(改善)」する必要が生じてしまう。つまり、システム開発という(繰り返しではない)業務フローが発生する際の一番のスタートポイントである「予算確保」の部分から、その粒度を落としていく必要があるのではないかと感じた。
ただ、これに対しては発注側の啓蒙活動を行う以外に効果的な方法が思いつかない。 エンジニア出身のCIO等、発注側のマネージャに「システム開発の本当のところ」を知っている人が就任すれば、ちょっとはマシな状況になるのだろうか。。。
まさにこちらの著者の仰る通りな
最近はすっかり離れてしまったけ
まぁ、この記事で「こうしない方
ただ、これはITベンダや開発者
というのも、発注側は既存のシス
発注側の予算確保がそういうやり
ただ、これに対しては発注側の啓
2006年12月1日金曜日
バイラルマーケティング(?)
バイラルマーケティングには可視化とリスペクトが必要だ(上)
うむ。非常に納得です。
特に、
「宣伝広告のためだけに存在する個人ブログは、拒否されやすい。」
や、
「iTSのアフィリエイトをしている人たちは儲けようと考えているのではなく、自分がその曲に持っている思い入れを多くの人に知ってほしいと思っているだけだ」
の部分に共感しました。
結局、「自分の持つ価値観」というものを前面に押し出し、その結果特定の商品なりサービスに対する評価をブログとして書く、という姿勢があるからこそ他者から評価されるのでしょう。つまり、あるAさんという人のブログでは、Aさんの嗜好性に基づいて様々な商品やサービスが評価され、その嗜好性と評価を組み合わせることで、ブログの読み手はそれぞれの商品やサービスについて自分なりの理解や認識をする、ということなんでしょうね。
あくまで
「自分の主観に基づいて書いてます。参考にして頂ければ幸いです」
というスタイルが、これからは支持されていくんでしょうね。
納得。
うむ。非常に納得です。
特に、
「宣伝広告のためだけに存在する個人ブログは、拒否されやすい。」
や、
「iTSのアフィリエイトをしている人たちは儲けようと考えているのではなく、自分がその曲に持っている思い入れを多くの人に知ってほしいと思っているだけだ」
の部分に共感しました。
結局、「自分の持つ価値観」というものを前面に押し出し、その結果特定の商品なりサービスに対する評価をブログとして書く、という姿勢があるからこそ他者から評価されるのでしょう。つまり、あるAさんという人のブログでは、Aさんの嗜好性に基づいて様々な商品やサービスが評価され、その嗜好性と評価を組み合わせることで、ブログの読み手はそれぞれの商品やサービスについて自分なりの理解や認識をする、ということなんでしょうね。
あくまで
「自分の主観に基づいて書いてます。参考にして頂ければ幸いです」
というスタイルが、これからは支持されていくんでしょうね。
納得。
SCO v.s. IBM (Linux)の行方
SCOの対IBM訴訟、申し立ての大半が無効に
う〜ん、実際のところ、SCOが所有している(Novellの主張によると「SCOが所有していると主張している」)UNIXの著作権を侵害したコードがLinuxのコードベースに存在するのかどうか、私は知らないし確かめる術も無いわけなのだが、どうもこの訴訟はSCOに分が悪いような気がしてならない。
無責任な第三者として、そしてLinuxとその未来を支持する一人のエンジニアの端くれとして見ると、x86系コンピュータ向けの商用UNIXとしてUnixwareを展開してきたSCOが、Linuxの台頭によってもはやお先真っ暗になったので、なりふり構わず訴訟に持ち込んだ、という感じがしてならない。
この訴訟の行方がどうなるにしろ、SCOはもう終わりなんだろうなあ・・・とも思う。
まぁ、Linuxに非があれば(UNIXの著作権を侵しているコードが紛れ込んでいるならば)その点は修正して欲しいが、とにかくLinuxの未来に暗い影が落ちない様に早くこの問題を片付けて欲しいものだ。
う〜ん、実際のところ、SCOが所有している(Novellの主張によると「SCOが所有していると主張している」)UNIXの著作権を侵害したコードがLinuxのコードベースに存在するのかどうか、私は知らないし確かめる術も無いわけなのだが、どうもこの訴訟はSCOに分が悪いような気がしてならない。
無責任な第三者として、そしてLinuxとその未来を支持する一人のエンジニアの端くれとして見ると、x86系コンピュータ向けの商用UNIXとしてUnixwareを展開してきたSCOが、Linuxの台頭によってもはやお先真っ暗になったので、なりふり構わず訴訟に持ち込んだ、という感じがしてならない。
この訴訟の行方がどうなるにしろ、SCOはもう終わりなんだろうなあ・・・とも思う。
まぁ、Linuxに非があれば(UNIXの著作権を侵しているコードが紛れ込んでいるならば)その点は修正して欲しいが、とにかくLinuxの未来に暗い影が落ちない様に早くこの問題を片付けて欲しいものだ。
GoogleとOS
Google OSをジョークで済ませていいんだろうか?
このエントリでフォーカスしているのは「GoogleがAJAXで動作するOSライクな環境を提供する」ことなのだが、私としてはむしろそのことと共にやってくるであろう以下のことを考えた。
それは、Googleが極めて機能が絞られて価格が抑えられたデスクトップOS(とそれを含んだPC)をリリースするのではないか、ということだ。
仮にGoogleが何でもサーバサイド(w/AJAX)でやっちゃえ、とゴリゴリ進めて行った場合、ローカルに必要なのはもはや JavaScript が動作するウェブブラウザだけになってしまう。そうすると、そもそもWindows XPやMac OS Xの様な高機能なデスクトップOSは必要なく、機能を絞ったLinuxベースのOSにFirefoxがあれば良い、ということになる。
ここで、例の「100ドルPC」を思い出してみよう。
これは、発展途上国向けに寄付することを前提として開発されたPCなわけだが、機能を絞ったとはいえ汎用PCが100ドル(プロトタイプは150ドル)で開発できることを世に示したわけだ。となると、ネットワーク機能とLinux+Firefoxが稼動するPCなんて、商用ベースに乗せれば100ドルで十分出来てしまいそうだ。
さて、このPCをコンシューマに配って1年間使ってもらうとしよう。そうすると、1年で100ドルだから、1ヶ月当たり約8ドルの支払いで済んでしまう。
これ、下手すると、ユーザの利用料が月当たり3ドル、広告でカバーする費用が月当たり5ドルとかで、タダ同然で世の中に配れてしまうのではないか?
で、これでGoogleがどうやって儲けるのか?
う〜む、そこが問題なのだよね・・・(笑)。
ただ、オフィスソフトに関してASPモデルでの提供を行えば、十分ビジネスにはなる気がする。
このエントリでフォーカスしているのは「GoogleがAJAXで動作するOSライクな環境を提供する」ことなのだが、私としてはむしろそのことと共にやってくるであろう以下のことを考えた。
それは、Googleが極めて機能が絞られて価格が抑えられたデスクトップOS(とそれを含んだPC)をリリースするのではないか、ということだ。
仮にGoogleが何でもサーバサイド(w/AJAX)でやっちゃえ、とゴリゴリ進めて行った場合、ローカルに必要なのはもはや JavaScript が動作するウェブブラウザだけになってしまう。そうすると、そもそもWindows XPやMac OS Xの様な高機能なデスクトップOSは必要なく、機能を絞ったLinuxベースのOSにFirefoxがあれば良い、ということになる。
ここで、例の「100ドルPC」を思い出してみよう。
これは、発展途上国向けに寄付することを前提として開発されたPCなわけだが、機能を絞ったとはいえ汎用PCが100ドル(プロトタイプは150ドル)で開発できることを世に示したわけだ。となると、ネットワーク機能とLinux+Firefoxが稼動するPCなんて、商用ベースに乗せれば100ドルで十分出来てしまいそうだ。
さて、このPCをコンシューマに配って1年間使ってもらうとしよう。そうすると、1年で100ドルだから、1ヶ月当たり約8ドルの支払いで済んでしまう。
これ、下手すると、ユーザの利用料が月当たり3ドル、広告でカバーする費用が月当たり5ドルとかで、タダ同然で世の中に配れてしまうのではないか?
で、これでGoogleがどうやって儲けるのか?
う〜む、そこが問題なのだよね・・・(笑)。
ただ、オフィスソフトに関してASPモデルでの提供を行えば、十分ビジネスにはなる気がする。
登録:
投稿 (Atom)