このままいくと、端末の数次第では、執筆者は、70%印税の、
キンドルとiTunesストアーで本を販売するのが定番になり、
出版業界や印刷業界はさらにシャレにならない状況になっていくのかもしれません。

2000年台が、音楽業界において、データ販売の閉める割合が激増した10年とするならば
2010年台は、出版業界にといて、データ販売が本格的に加速する10年になるのかも。。。

iTunes経由で書籍・雑誌・漫画・新聞・etcをiPhoneとiPadで共有できるのであれば、
リビングでは、iPadで読んで、通勤電車ではiPhone,iPod Touchで続きを読む。
というライフスタイルはアリな気がします。

Amazonの戦略は、あらゆるタッチパネル端末と仲良くしまくって、
キンドルfor XXX を次々と出して、Appleに対抗するのがこれからの数年なのかもしれません。

また、iPhoneアプリ作者にとっては、これ以上の朗報はないのでは、ないでしょうか？（＾＾
うちも、iPhone技術者をもっとそだてなければなりませんね。

さて、あとは、Googleが予定しているPC向け新OSがどれだけ追撃ができるかですが、iPadが予想外に安く出てきたので、アプリ環境が整っているiPadに大きく水をあけられそうに思います。
Googleは端末側で世界を掌握するのは難しくなってきたかもしれません。
まぁ、Googleのクラウドのおかげで、iPhoneやiPodがブラウザさえあれば事足りる世界が創造されつつあるのですが・・・

久々にワクワクしてきました。

さて、iPod用のsshクライアント、使いやすいのだれか作ってくれないですかね？
＃あっ、脱獄すればいいのか（＾＾;

この時計は加速度センサーと無線装置を搭載していて、外部のPCと通信を行う事が出来る優れものです。

唯一残念なのは、スポーツ利用をイメージしておきながら、加速度センサーの最大値が8Gという事。
スタッフの森田君の試算や、佐賀大学の佐藤先生らの論文手首で計測した加速度による投球スピードの推定では、ピッチャーの手首の最大加速度は、60G(!)を超えるというデータがあります。

8Gじゃなくって80Gだったら、野球・ゴルフ・テニス・ハンドボール・卓球・バレーボールなど、あらゆるスポーツで利用範囲が一杯あったかも。。。と思ったのですが、なんとかならないでしょうか？＞テキサスインスツルメンツさん

・locationmatch、ファイルタイプ、クッキー毎にキャッシュの制御が出来る
・ある特定のファイルやDBの特定レコードが更新されると、関連キャッシュがすべて消去される

そんなに無茶な要求ではないと思うのですが、やっぱり作るしかないんでしょうか？

　このアプリの特徴は、

• 初めは無料。一ヶ月を過ぎると月額課金が発生。
• プッシュ機能により、「コンピ発表のタイミングで通知」「自分の賭けたレースの結果が発表されると通知」
• 課金はアプリ内のコラムや予想、ニュース単位でも課金が可能
• とiPhone OS3の機能をふんだんに使っています。月額課金は、コンテンツを返すゲートウェイサーバを弊社で開発。一ヶ月を経過したらStoreの支払いに飛ばす形となっています。

また、マーケティング的には、

• iPhoneの年齢層（おっさん）≒競馬の年齢層（ダビスタ世代以上）≒日刊スポーツ新聞の購読者層
• セグメントコンテンツ：コンピ指数は日刊スポーツの専売特許なので、絶対に真似したアプリは他では作れない
• 日刊スポーツ様は自社で、購買層向けの告知メディアを持っている

となってります。

あと、AdMobの社長ラーゲンさんのお勧めもあり、月額課金アプリなのにAdMobを搭載てみました。

さて、年末の有馬に向けて、どのぐらいダウンロードされるのか、今から楽しみです。(^^

■測定条件

time sync ; time sync ; time sync ; time pgbench -c 30 -t 100 -v test ; time sync ; time sync ; time sync

■測定結果

HDD : 約180トランザクション/sec(sync に300ms)

SSD:約1600トランザクション/sec(sync に300ms)

測定ミスかと思える程、かなり嘘っぽい出来すぎた数値になりました。

Google,Amazon,VMWare,Xen,etc

で、一つの結論があります。

弊社のように常に処理能力且つ低コストを要求されるシステムを構築する場合は、「クラウドを使わない従来スタイル（１サーバに１OSをセットし冗長化構成を構築）の方がハイパフォーマンス」という結論になりました。（あたりまえと言えばあたりまですが・・・）

「クラウド」は営業的にウケもよく、ビジネス的に儲かるかもしれません。いくらメンテナンス性や障害に強いといっても、客先の要求する処理能力と予算を満たせなければ、膨大な予算を使って「豚」なシステムを構築するだけになります。

しかし、そんな営業をされて取ってきた仕事を引き受ける技術者は悲惨な事になりそうに思います。「クラウド」はあるべき姿だと思いますが、弊社内のベンチマーク結果では、ms単位の処理能力要求があるシステムを構築するには時期尚早だという結論に達しました。

ベンチマーク結果を公表したいところですが、VMWareあたりは規約上NGらしいので。。。

なんかうちの会社、ベンチマークを取る度に、時代に逆行しているしているよな気がします。　＃だから儲からないんですね(^^;

でも、うちのアドバンテージは、技術屋として、ビジネスより質実剛健なシステム構築を優先する所にあると思っています。

これは先日のGTUGに使った、クラウドターミナルのGoogleガジェットのコンセプトデザインです。まだ、垢抜けているとは言えませんが、可能性は無限大だと思っています。何かすごいアイディアを思いついた方は、是非、メールをください。（＾＾

以下はクラウドターミナル対応のデバイス「GDevice(?)」があらゆる家電の規格として取り入れられたら・・・という妄想です。(^^;

去る9月9日にGTUG Tokyo #2 でクラウド・ターミナルの発表をしてきました。

自分の説明が下手くそだったと大きく反省。。。

ただ、終わったあとの端子君（温度ロイド君？）は、おかげでとても人気がありました。

今回発表して思ったのは、提言とか作り方の説明といったノリではなく、単独でもいいから

「半田ごて無しでいきなり使える、クラウドターミナルを商品として世に出してみたい」

という思いがさらに募ってきています。

私は行けなかったのですが、６月のモバイル大学での講演では異例の大人数を集めたジョン・ラーゲリン氏。行かれた方のお話では「へたな日本人の講演より実にエキサイティングだった！」との事。

お会いするのをとても楽しみにしていたのですが、いやー、すごかったです。　世の中には本当に凄い人が一杯いるんだなぁとつくづく思いました。（＾＾

ちなみに、一緒にいらしたAdMobの技術者の方、どっかでお見受けしたような気がするのですが・・・

＃本当にモウロクしました、思い出せません(^^;