BIGLOBEから来年Android端末が発売される。台湾Camangi製と、NEC製の2モデルが発売される予定．7インチのタッチパネルを搭載し、3GやWifi、WiMAXといったネット接続手段が利用できる。
まずはCamangi製モデルについて、来年2月からモニターテストを始め、その後3～4万円で販売する予定。
機器自体は7インチのタッチパネル搭載ということでちょっと大きいが、「クラウドデバイス」としてBIGLOBEの提供する各種サービスを利用できる。
来年1月からBIGLOBE会員向けにモニターの募集を開始。
NECだし、評価しようと思う．
2009年12月20日日曜日
Google Smart Book
Googleが1月初旬にリリースするといわれるAndroid携帯「Nexus One」.このインターネット企業が提供するハードウェアはスマートフォンにとどまらないようだ。現在Googleはあるハードウェアベンダーに対してChrome OSを搭載したNetbook製品の製造を持ちかける話し合いを行っている。
TechCrunchの話によれば、現在GoogleブランドのNetbook製造に向けた話し合いを進めており、技術的な詳細を記した提案書(Request for Proposal: RFP)を製造メーカーに対して送付しているという。出荷時期は来年2010年のクリスマスシーズンを見込んでおり、Googleからユーザーに対して直販する形式になるとみられる。
機能的な詳細で唯一わかっているのは、このNetbookがモバイル機能を標準実装していることで、ユーザーは1社ないし複数社との契約でモバイルブロードバンドを楽しむことが可能になるという。
TechCrunchではChrome OS自体がx86とARMプロセッサの両者をサポートしており、可能性としてはNetbookで一般的なAtomプロセッサではなく、ARMベースのプロセッサを搭載する可能性が高いと予測。
Googleが開発を計画しているのはNetbookではなく、むしろ「Smartbook」と呼ばれるカテゴリの製品が近いようだ。
この範疇のメディアは落としどころが難しい．iPhoneがあるのでって気がする．
TechCrunchの話によれば、現在GoogleブランドのNetbook製造に向けた話し合いを進めており、技術的な詳細を記した提案書(Request for Proposal: RFP)を製造メーカーに対して送付しているという。出荷時期は来年2010年のクリスマスシーズンを見込んでおり、Googleからユーザーに対して直販する形式になるとみられる。
機能的な詳細で唯一わかっているのは、このNetbookがモバイル機能を標準実装していることで、ユーザーは1社ないし複数社との契約でモバイルブロードバンドを楽しむことが可能になるという。
TechCrunchではChrome OS自体がx86とARMプロセッサの両者をサポートしており、可能性としてはNetbookで一般的なAtomプロセッサではなく、ARMベースのプロセッサを搭載する可能性が高いと予測。
Googleが開発を計画しているのはNetbookではなく、むしろ「Smartbook」と呼ばれるカテゴリの製品が近いようだ。
この範疇のメディアは落としどころが難しい．iPhoneがあるのでって気がする．
2009年12月19日土曜日
2009年12月17日木曜日
Note Taker
VisiCalcの作成者ダン・ブルックリンさんが最近は携帯機器のアプリ開発に興味を持っていて、iPhoneアプリの第一弾をリリース、『Note Taker』。iPhoneのキーボードでもたもたしてるよりも手で書いた方が速い、という場合に活躍してくれること間違いなしなアプリです。
意外とよく出来ていて、長い文章を書く場合にもかなり楽に作業できるようにデザインされています。
文字認識機能はついていないので、そこからメールにテキストとしてペーストして送信、というのは出来ないのですが、書き留めたメモを見ながらキーボードで打ち込むことは可能です。
手書きのページをそのままメールすることも可能。自分で書いた文字が解読出来ない方向けのツールではないですが、スケッチが好きな方やマインドマップをよく使う方、小さなキーを使ってバックスペースを連打しながらリストを作成するのが面倒な人にはかなりよく出来たツールです。
使っている時の感覚はノートパッドに書いているのと大差ないので、使っていればすぐに使い方にも慣れてくるはず。
特筆すべきはパーソナルコンピュータ界を大きく変えた存在であるダン・ブルックリンさんが、30年の時を経てもまだ新事業への情熱を失っておらず新しいプラットフォーム向けにソフトを作成した、という事実。彼自身の言葉によると：
この数ヶ月に亘り私は様々なメディアやビジネル環境について学んできました。9月中旬に24インチのApple iMacとiPhone 3GSを購入し、Apple iPhone開発者プログラムに参加しました。何冊か本を購入し、チュートリアルを一つずつこなしてみました。その際にアプリケーションのアイデアが浮かんできたので、早速試作品を作り、他の人の役に立つようにアプリの改善を重ねて来ました。
完成したアプリをApp Storeに提出したところ、無事承認され、ようやくどなたでもダウンロード可能となりました。VisiCalcから30年余、私の次なるステップはアップルハードウェアから始まるのです。
なぜか 世の中 捨てたものではないと 感心．
意外とよく出来ていて、長い文章を書く場合にもかなり楽に作業できるようにデザインされています。
文字認識機能はついていないので、そこからメールにテキストとしてペーストして送信、というのは出来ないのですが、書き留めたメモを見ながらキーボードで打ち込むことは可能です。
手書きのページをそのままメールすることも可能。自分で書いた文字が解読出来ない方向けのツールではないですが、スケッチが好きな方やマインドマップをよく使う方、小さなキーを使ってバックスペースを連打しながらリストを作成するのが面倒な人にはかなりよく出来たツールです。
使っている時の感覚はノートパッドに書いているのと大差ないので、使っていればすぐに使い方にも慣れてくるはず。
特筆すべきはパーソナルコンピュータ界を大きく変えた存在であるダン・ブルックリンさんが、30年の時を経てもまだ新事業への情熱を失っておらず新しいプラットフォーム向けにソフトを作成した、という事実。彼自身の言葉によると：
この数ヶ月に亘り私は様々なメディアやビジネル環境について学んできました。9月中旬に24インチのApple iMacとiPhone 3GSを購入し、Apple iPhone開発者プログラムに参加しました。何冊か本を購入し、チュートリアルを一つずつこなしてみました。その際にアプリケーションのアイデアが浮かんできたので、早速試作品を作り、他の人の役に立つようにアプリの改善を重ねて来ました。
完成したアプリをApp Storeに提出したところ、無事承認され、ようやくどなたでもダウンロード可能となりました。VisiCalcから30年余、私の次なるステップはアップルハードウェアから始まるのです。
なぜか 世の中 捨てたものではないと 感心．
2009年12月15日火曜日
Chrome OS 詳細
7月に明らかにした設計思想に忠実なOSという印象を受ける.
パソコン世代の者にとっては,実装があまりに“不自由”なことが気になった．
Chrome OSは，GoogleのWebブラウザ「Chrome」を動かす最小限の環境をセキュアに構築することに注力。プリインストール機の購入が前提。カーネル部分に手は入れられない。メイン・ストレージはクラウド。ローカル・データはキャッシュに過ぎない。プリインストール機前提なのはMac OS Xとそのファームウエアも同様だが，比較的簡単にroot権限を取得できる。
ユーザーはWebアプリケーションの利用に専念できる。PC管理に費やす時間があったら，使いたいときすぐWebを利用してほしい。それがGoogleのメッセージだ。
発表時にGoogleが提示したコンセプトは「速く，シンプルで，セキュアで，ほとんどの時間をWebで過ごすユーザーに向けた軽量OS」。
11月に公開したセキュリティ設計思想では，「カウチ・コンピューティング」「ちょっとした仕事をこなす2台目マシン」「喫茶店や図書館での貸し出し機」「家族で共有する2台目マシン」と，メインマシンとしての汎用性は初めから見切っている。
汎用OSでは互換性や利便性とのトレードオフから採用が難しかった手法をふんだんに取り入れた。
Chromeブラウザが動作する組み込みOSとして機能をスリム化。
ネットブック出荷後に加わる実行ファイルは，原則として不正なプログラムとして扱う、ホワイトリスト型のアプローチ。
セキュリティ以外の側面から，起動が高速で，無駄なシステム・サービスがメモリーを圧迫しない軽量なOS。
セキュリティ実装を軸にChrome OSのアーキテクチャを把握するために，
(1)ファームウエアとカーネルの起動プロセス，
(2)リソースの隔離機構，
(3)デスクトップ環境という三つのレイヤーをからみてみる。
(1)のファームウエアとカーネルの起動プロセスは，ファームウエアとカーネルの各プログラムに施した電子署名をチェックし，改変があれば復元する，というもの。この検証と復元動作に対する不正アクセスからの防護を，Chromeブラウザへの特化とプリインストールによって確保している。
難点は，すべてのプログラムに署名を施す手間がかかることだ。ただChrome OSは，Chromeブラウザの利用に特化しているためプログラムの数が少ない。
まずファームウエアの部分は，PC-AT互換機としてのレガシー・サポートなどを省いてブートに必要なプログラムのみに絞る。例えばフロッピー・ドライブは初期化しない。
カーネルについては，ごく少数のパッチを除いて，動的に追加可能なカーネル・モジュールを利用しない。「Upstart」という並列処理が可能な初期化プログラムを使うなど初期化の時間を節約する。セキュリティ・ホールが存在する可能性も低くなる。
カーネル以外のシステム・プログラムも最小限に抑える。バッテリ管理やネットワーク・ドライバの制御に使う「D-Bus」デーモン，ネットワーク周りの設定管理プログラム「Connection Manager」，無線LAN接続用のWPAサプリカント，自動更新，電源管理，スクリーン・セーバー，時刻同期のNTP，ログ管理のsyslog，タスク・スケジューラのcron。Chrome OSの主な起動プロセスはたったこれだけだ．
Chrome OS内部のプログラムを徹底的に隔離することで，不正なプログラムの進入や活動を防ぐ。隔離機構のセキュリティ・ホールに対しては，OSの自動更新で迅速に修正して被害を最小限に抑える。
Chromeブラウザは，コンピュータのリソース管理の単位であるプロセスをタブやChrome拡張ごとに生成する。プロセスはそれぞれ別の仮想メモリー空間を持つ。あるプロセスが不正アクセスを受けたとしても，他のプロセスへの波及を防げる。
さらにChrome OSでは，HTTP，HTTPSを処理するプログラムもプロセスとして独立させる。副作用として，プロセス間でデータをやり取り（プロセス間通信）する際のオーバーヘッド増加がある。このためChromium OSプロジェクトは，プロセス間通信高速化についてコミュニティの貢献を求めている。
プロセス分割の単位を細かくしたうえで，それぞれが利用可能なリソースは制限する。例えばファイル・システムでは，プロセスごとにアクセス範囲を変え，許可しないリソースへのアクセスは拒否する。隔離には，Linuxカーネルに取り込まれたTOMOYO Linux，ファイル・システムのルートを変えるchroot，Linux向け仮想OS技術の一つであるLinux-VServerなどを当面は採用。
不正アクセスが狙うユーザーのデータは，ローカル・ストレージの工夫で守る。ルート・パーティションは読み取り専用とし，ユーザー・データを暗号化。そもそも主ストレージは，Googleのデータセンターという位置付け。ローカル・ストレージはキャッシュとして割り切る。
これら保護策のセキュリティ・ホールを放置しないように，OSは随時自動でアップデートする。その際はSSLサーバー認証，ダウングレードの禁止，OS起動時と同様の電子署名チェックなどで，不正なプログラムが潜り込まないようにする。長期間オフラインで利用する場合はアップデートが滞ることになるが，Webアプリケーションの利用が前提であれば問題にならない。
「Chrome OSはユーザーがダウンロードしては使えない。プリインストール機を買う必要がある」というGoogleの方針だ。組み込み以外の提供を許すと，電源投入時から始まる動作チェックをすり抜けるパッチを当てられる場面を極力少なくするという設計思想のほころびにつながる。
Chrome OSを設計するうえで想定外としたセキュリティ侵害の一つに，ファームウエアへの物理的なアクセスがある。ファームウエアを格納するEEPROMの差し換えは物理セキュリティの領域というわけだ。
セキュリティ機構に加えてデスクトップ環境の構成を把握すれば，それがそのままChrome OSの全貌になる。
デスクトップ環境は，ウィンドウ管理に定番のX Window，半透明処理を追加するComposite extension，GNOME由来のユーザー・インタフェース・ライブラリであるClutter，コーデックやストリーミングを管理するOpenMAX，3D描画のOpenGL/GL ESと，これまでオープンソース・プロジェクトで開発が進んできたライブラリの組み合わせが核となる。
そのうえに，ブラウザとGoogleが開発したウィンドウ・マネージャが載る。基本的に他の一般的なウィンドウ・マネージャと同様の構成で，ICCCM（Inter-Client Communication Conventions Manual）とEWHM（Extended Window Manager Hints）というUNIXのウィンドウ・マネージャの仕様に沿っている。
IM（Input Method）プラットフォームはiBusを使う。Chromium OSでは，日本語入力用にibus-anthyを搭載済みだ（ただしターミナルを起動して初期化する必要がある）。将来の予定として，Chromium OSプロジェクトは日本語入力に「Google 日本語入力」を採用する。
徹底的にChromeブラウザ基盤としてのフェイル・セーフにこだわったChrome OS。多くの作業はWebアプリケーションで事足りるようになった。Chromeブラウザに感じていた物足りなさは，Chrome拡張のベータ版公開で変わりつつある。マウスジェスチャー機能やブックマーク同期機能など，最低限必要なものがそろい始めた。
ただパソコンを使い始めたときからブログにメモ書きし，ネットに写真や動画をアップロードするようなユーザーは，むしろ自由を満喫するはず。
パソコン世代の者にとっては,実装があまりに“不自由”なことが気になった．
Chrome OSは，GoogleのWebブラウザ「Chrome」を動かす最小限の環境をセキュアに構築することに注力。プリインストール機の購入が前提。カーネル部分に手は入れられない。メイン・ストレージはクラウド。ローカル・データはキャッシュに過ぎない。プリインストール機前提なのはMac OS Xとそのファームウエアも同様だが，比較的簡単にroot権限を取得できる。
ユーザーはWebアプリケーションの利用に専念できる。PC管理に費やす時間があったら，使いたいときすぐWebを利用してほしい。それがGoogleのメッセージだ。
発表時にGoogleが提示したコンセプトは「速く，シンプルで，セキュアで，ほとんどの時間をWebで過ごすユーザーに向けた軽量OS」。
11月に公開したセキュリティ設計思想では，「カウチ・コンピューティング」「ちょっとした仕事をこなす2台目マシン」「喫茶店や図書館での貸し出し機」「家族で共有する2台目マシン」と，メインマシンとしての汎用性は初めから見切っている。
汎用OSでは互換性や利便性とのトレードオフから採用が難しかった手法をふんだんに取り入れた。
Chromeブラウザが動作する組み込みOSとして機能をスリム化。
ネットブック出荷後に加わる実行ファイルは，原則として不正なプログラムとして扱う、ホワイトリスト型のアプローチ。
セキュリティ以外の側面から，起動が高速で，無駄なシステム・サービスがメモリーを圧迫しない軽量なOS。
セキュリティ実装を軸にChrome OSのアーキテクチャを把握するために，
(1)ファームウエアとカーネルの起動プロセス，
(2)リソースの隔離機構，
(3)デスクトップ環境という三つのレイヤーをからみてみる。
(1)のファームウエアとカーネルの起動プロセスは，ファームウエアとカーネルの各プログラムに施した電子署名をチェックし，改変があれば復元する，というもの。この検証と復元動作に対する不正アクセスからの防護を，Chromeブラウザへの特化とプリインストールによって確保している。
難点は，すべてのプログラムに署名を施す手間がかかることだ。ただChrome OSは，Chromeブラウザの利用に特化しているためプログラムの数が少ない。
まずファームウエアの部分は，PC-AT互換機としてのレガシー・サポートなどを省いてブートに必要なプログラムのみに絞る。例えばフロッピー・ドライブは初期化しない。
カーネルについては，ごく少数のパッチを除いて，動的に追加可能なカーネル・モジュールを利用しない。「Upstart」という並列処理が可能な初期化プログラムを使うなど初期化の時間を節約する。セキュリティ・ホールが存在する可能性も低くなる。
カーネル以外のシステム・プログラムも最小限に抑える。バッテリ管理やネットワーク・ドライバの制御に使う「D-Bus」デーモン，ネットワーク周りの設定管理プログラム「Connection Manager」，無線LAN接続用のWPAサプリカント，自動更新，電源管理，スクリーン・セーバー，時刻同期のNTP，ログ管理のsyslog，タスク・スケジューラのcron。Chrome OSの主な起動プロセスはたったこれだけだ．
Chrome OS内部のプログラムを徹底的に隔離することで，不正なプログラムの進入や活動を防ぐ。隔離機構のセキュリティ・ホールに対しては，OSの自動更新で迅速に修正して被害を最小限に抑える。
Chromeブラウザは，コンピュータのリソース管理の単位であるプロセスをタブやChrome拡張ごとに生成する。プロセスはそれぞれ別の仮想メモリー空間を持つ。あるプロセスが不正アクセスを受けたとしても，他のプロセスへの波及を防げる。
さらにChrome OSでは，HTTP，HTTPSを処理するプログラムもプロセスとして独立させる。副作用として，プロセス間でデータをやり取り（プロセス間通信）する際のオーバーヘッド増加がある。このためChromium OSプロジェクトは，プロセス間通信高速化についてコミュニティの貢献を求めている。
プロセス分割の単位を細かくしたうえで，それぞれが利用可能なリソースは制限する。例えばファイル・システムでは，プロセスごとにアクセス範囲を変え，許可しないリソースへのアクセスは拒否する。隔離には，Linuxカーネルに取り込まれたTOMOYO Linux，ファイル・システムのルートを変えるchroot，Linux向け仮想OS技術の一つであるLinux-VServerなどを当面は採用。
不正アクセスが狙うユーザーのデータは，ローカル・ストレージの工夫で守る。ルート・パーティションは読み取り専用とし，ユーザー・データを暗号化。そもそも主ストレージは，Googleのデータセンターという位置付け。ローカル・ストレージはキャッシュとして割り切る。
これら保護策のセキュリティ・ホールを放置しないように，OSは随時自動でアップデートする。その際はSSLサーバー認証，ダウングレードの禁止，OS起動時と同様の電子署名チェックなどで，不正なプログラムが潜り込まないようにする。長期間オフラインで利用する場合はアップデートが滞ることになるが，Webアプリケーションの利用が前提であれば問題にならない。
「Chrome OSはユーザーがダウンロードしては使えない。プリインストール機を買う必要がある」というGoogleの方針だ。組み込み以外の提供を許すと，電源投入時から始まる動作チェックをすり抜けるパッチを当てられる場面を極力少なくするという設計思想のほころびにつながる。
Chrome OSを設計するうえで想定外としたセキュリティ侵害の一つに，ファームウエアへの物理的なアクセスがある。ファームウエアを格納するEEPROMの差し換えは物理セキュリティの領域というわけだ。
セキュリティ機構に加えてデスクトップ環境の構成を把握すれば，それがそのままChrome OSの全貌になる。
デスクトップ環境は，ウィンドウ管理に定番のX Window，半透明処理を追加するComposite extension，GNOME由来のユーザー・インタフェース・ライブラリであるClutter，コーデックやストリーミングを管理するOpenMAX，3D描画のOpenGL/GL ESと，これまでオープンソース・プロジェクトで開発が進んできたライブラリの組み合わせが核となる。
そのうえに，ブラウザとGoogleが開発したウィンドウ・マネージャが載る。基本的に他の一般的なウィンドウ・マネージャと同様の構成で，ICCCM（Inter-Client Communication Conventions Manual）とEWHM（Extended Window Manager Hints）というUNIXのウィンドウ・マネージャの仕様に沿っている。
IM（Input Method）プラットフォームはiBusを使う。Chromium OSでは，日本語入力用にibus-anthyを搭載済みだ（ただしターミナルを起動して初期化する必要がある）。将来の予定として，Chromium OSプロジェクトは日本語入力に「Google 日本語入力」を採用する。
徹底的にChromeブラウザ基盤としてのフェイル・セーフにこだわったChrome OS。多くの作業はWebアプリケーションで事足りるようになった。Chromeブラウザに感じていた物足りなさは，Chrome拡張のベータ版公開で変わりつつある。マウスジェスチャー機能やブックマーク同期機能など，最低限必要なものがそろい始めた。
ただパソコンを使い始めたときからブログにメモ書きし，ネットに写真や動画をアップロードするようなユーザーは，むしろ自由を満喫するはず。
2009年12月12日土曜日
2009年12月9日水曜日
Google Goggles
Googleは携帯で撮影した画像で検索をかけることができるAndroid用のサービス「Google Goggles」を発表．
画像検索するにはAndroid携帯でGoogle Gogglesを立ち上げ、書籍やアルバムのカバー、ロゴや風景などを撮影し送信する。画像はGoogleのデータセンタに送られ解析され、Googleのもつ大量の画像データベースと照らし合わせられ、結果がユーザに返される。
Google Gogglesは現在まだGoogle Labsで実験段階にある．Android 1.6以上の携帯電話に対応しており、アプリケーションはAndroid Marketにて無料で提供されるとのこと。
画像が検索キーになる日が来た．マッチングの問題だが、どの程度のレベルなのだろうか？
画像検索するにはAndroid携帯でGoogle Gogglesを立ち上げ、書籍やアルバムのカバー、ロゴや風景などを撮影し送信する。画像はGoogleのデータセンタに送られ解析され、Googleのもつ大量の画像データベースと照らし合わせられ、結果がユーザに返される。
Google Gogglesは現在まだGoogle Labsで実験段階にある．Android 1.6以上の携帯電話に対応しており、アプリケーションはAndroid Marketにて無料で提供されるとのこと。
画像が検索キーになる日が来た．マッチングの問題だが、どの程度のレベルなのだろうか？
2009年12月7日月曜日
Net端末戦略
中島聡さんのブログから
Googleが選んだ戦略は、
（１）Android・Chrome OSを無料で提供することによりOSをコモディティ化すること、
（２）それらのOSがさまざまなCPUで動くようにする＝CPUをコモディティ化すること、
（３）政府にネットのオープン化を迫る＝通信事業をコモディティ化すること、
の三つである。
今年後半になってAndroidケータイが増えて来たのはまさにその結果だ．
２０１０年にはChrome OSのためにネットブック・ビジネスへの参入障壁が下がり、競争原理によりもっと値段が下がる。Chrome OSのために、ネットブックにおけるIntelアーキテクチャの牙城がくずれ、ARMベースのネットブックが売れ始める可能性さえある。１００ドル・パソコンの時代は目前だ。
Net-bookを使っている私には、通信事業のコモディティ化までは見えていない．マイクロソフトが築き上げてきたパソコンのコモディティ化＝PCビジネスは終焉を迎える ということだ．
Googleが選んだ戦略は、
（１）Android・Chrome OSを無料で提供することによりOSをコモディティ化すること、
（２）それらのOSがさまざまなCPUで動くようにする＝CPUをコモディティ化すること、
（３）政府にネットのオープン化を迫る＝通信事業をコモディティ化すること、
の三つである。
今年後半になってAndroidケータイが増えて来たのはまさにその結果だ．
２０１０年にはChrome OSのためにネットブック・ビジネスへの参入障壁が下がり、競争原理によりもっと値段が下がる。Chrome OSのために、ネットブックにおけるIntelアーキテクチャの牙城がくずれ、ARMベースのネットブックが売れ始める可能性さえある。１００ドル・パソコンの時代は目前だ。
Net-bookを使っている私には、通信事業のコモディティ化までは見えていない．マイクロソフトが築き上げてきたパソコンのコモディティ化＝PCビジネスは終焉を迎える ということだ．
2009年12月6日日曜日
Apple戦略
中島聡さんのグログを読んで．
今のAppleのビジネス戦略は、倒産寸前だった９７年当時に作った「３０年ロードマップ」に書かれた通りのシナリオを描いているという。
「映像・画像・音楽・書籍・ゲームなどのあらゆるコンテンツがデジタル化され、同時に通信コストが急激に下がる中、その手のコンテンツを制作・流通・消費するシーンで使われるデバイスやツールは、従来のアナログなものとは全く異なるソフトウェア技術を駆使したデジタルなものになる。アップルはそこに必要なIP・ソフトウェア・デバイス・サービス・ソリューションを提供するデジタル時代の覇者となる」である。
Final Cutが着実に画像編集ツールとしてのプロフェッショナルの間でのデファクトの地位を取りつつある部分だとか、WebKitがスマート・フォン向けブラウザーのデファクトになるつつあるなど、とても戦略的に思える。
「これから１０〜１５年の間にアップルが何をしてくるか」が自然に見えて来る。
Apple TVは「ひょっとしたら売れるかも知れない」などの軽い気持ちで作ったデバイスではなく、「アップルがリビングルームにネットを通して映像が提供される時代の覇者になるための最初の一歩」であること。日本でも米国でも光ファイバーを通した映像の配信はまだまだビジネスとして立ち上がっていないが、いつかはそんな時代が来ることだけは確実。Apple TVはそんな時代に向けた先行投資であり、いつかはApple TVをリビングルームのiPhoneのような存在にしようと企んでいることは明白である。
Appleが書籍・雑誌のデジタル配信ビジネスに本気で出て来ることがほぼ確実なこと。「デジタルで配信された書籍・雑誌を読むのに最適なデバイスは何か？」と考え、それに最適なデバイスをハードもソフトもサービスも含めて設計し、コンテンツ流通の仕組みと一緒に提供するのがAppleである。
ゲーム市場。最近のiPhone/iPod touchのアプリの宣伝の仕方でも分かる通り、Appleはすでに「ゲームを遊ぶ」をその二つのデバイスの主要なユーザー・シナリオの一つと位置づけている。わずか２年あまりの間に、iPhone/iPod touchは既にSony PSP、Nintendo DSに十分対抗しうる携帯ゲーム・プラットフォームに成長したのだ。
PS3／Wii／Xbox360に対抗する据え置き型のゲーム市場。何年後になるかはわからないが、次の世代のApple TVがOS-Xを搭載し、iTunes storeからゲームをダウンロードして遊べるようになる、という可能性は十分にある。
ロードマップが、出井さんの時代にソニーが掲げていたビジョンと酷似している点。９７年の時点でそこまでのロードマップが書けており、かつそれをこれだけ長い間ブレずに着実に実行して来ているという点が、まさに今のAppleの戦略の強さの源流だと思う。
久し振りに経営戦略を聞いた．おかしいほどに確かにソニーと似ている．出井さん去りし後のソニーの慮る私である．
今のAppleのビジネス戦略は、倒産寸前だった９７年当時に作った「３０年ロードマップ」に書かれた通りのシナリオを描いているという。
「映像・画像・音楽・書籍・ゲームなどのあらゆるコンテンツがデジタル化され、同時に通信コストが急激に下がる中、その手のコンテンツを制作・流通・消費するシーンで使われるデバイスやツールは、従来のアナログなものとは全く異なるソフトウェア技術を駆使したデジタルなものになる。アップルはそこに必要なIP・ソフトウェア・デバイス・サービス・ソリューションを提供するデジタル時代の覇者となる」である。
Final Cutが着実に画像編集ツールとしてのプロフェッショナルの間でのデファクトの地位を取りつつある部分だとか、WebKitがスマート・フォン向けブラウザーのデファクトになるつつあるなど、とても戦略的に思える。
「これから１０〜１５年の間にアップルが何をしてくるか」が自然に見えて来る。
Apple TVは「ひょっとしたら売れるかも知れない」などの軽い気持ちで作ったデバイスではなく、「アップルがリビングルームにネットを通して映像が提供される時代の覇者になるための最初の一歩」であること。日本でも米国でも光ファイバーを通した映像の配信はまだまだビジネスとして立ち上がっていないが、いつかはそんな時代が来ることだけは確実。Apple TVはそんな時代に向けた先行投資であり、いつかはApple TVをリビングルームのiPhoneのような存在にしようと企んでいることは明白である。
Appleが書籍・雑誌のデジタル配信ビジネスに本気で出て来ることがほぼ確実なこと。「デジタルで配信された書籍・雑誌を読むのに最適なデバイスは何か？」と考え、それに最適なデバイスをハードもソフトもサービスも含めて設計し、コンテンツ流通の仕組みと一緒に提供するのがAppleである。
ゲーム市場。最近のiPhone/iPod touchのアプリの宣伝の仕方でも分かる通り、Appleはすでに「ゲームを遊ぶ」をその二つのデバイスの主要なユーザー・シナリオの一つと位置づけている。わずか２年あまりの間に、iPhone/iPod touchは既にSony PSP、Nintendo DSに十分対抗しうる携帯ゲーム・プラットフォームに成長したのだ。
PS3／Wii／Xbox360に対抗する据え置き型のゲーム市場。何年後になるかはわからないが、次の世代のApple TVがOS-Xを搭載し、iTunes storeからゲームをダウンロードして遊べるようになる、という可能性は十分にある。
ロードマップが、出井さんの時代にソニーが掲げていたビジョンと酷似している点。９７年の時点でそこまでのロードマップが書けており、かつそれをこれだけ長い間ブレずに着実に実行して来ているという点が、まさに今のAppleの戦略の強さの源流だと思う。
久し振りに経営戦略を聞いた．おかしいほどに確かにソニーと似ている．出井さん去りし後のソニーの慮る私である．
2009年11月22日日曜日
解ける問題 解けない問題
野崎先生の本
話のもって行き方が野崎先生らしく前提を詳しく説明．
等分問題はさすがとです．
アルゴリズムへの展開もおもしろい．ヒルベルトの第１０問題
圧巻はマチャセヴィッチのフィボナッチ数列を使った証明．
知性の深い考察がみえる．
久しぶりに聞いた野崎先生の教訓でした
話のもって行き方が野崎先生らしく前提を詳しく説明．
等分問題はさすがとです．
アルゴリズムへの展開もおもしろい．ヒルベルトの第１０問題
圧巻はマチャセヴィッチのフィボナッチ数列を使った証明．
知性の深い考察がみえる．
久しぶりに聞いた野崎先生の教訓でした
2009年11月21日土曜日
Chrome OS 詳細
Chrome OSは、GoogleがNetbook向けに開発しているWeb OSだ、
ブラウザベースですべてのインターフェイスを実装し、アプリケーションはすべてWebベース。HTML5とCSS3.0によってリッチインターネットアプリケーション(RIA)を作成できるなら、シンプルにWebブラウザ中心のソフトウェア基盤だけで十分じゃないか、というGoogleらしい提案．
Googleが行ったChrome OSのデモでは、同OSはASUSのEee PCで7秒で起動し、さらに3秒でアプリケーションにログインした。
Contacts and panel 確かに軽い
Google Chrome OS 開発版 ダウンロード提供開始、普通のPCで動く．
Google Chrome OS は認証済みハードウェア構成とカスタムファームウェアを備えたデバイスにのみプリインストールで製品化される計画です．
開発版はもちろん普通のPCで試せます。公開されたのは、仮想環境で動くイメージ版。動かすためにはVMwareが必要です。イメージとVMware Player (無償)のダウンロードはリンク先から。BitTorrentやなにかでも落とせます。
ダウンロード - Chrome OS 0.4.22.8 VMware (300MBくらい)
ダウンロード - VMware Player
２０１０年まで 待てないかな？
ブラウザベースですべてのインターフェイスを実装し、アプリケーションはすべてWebベース。HTML5とCSS3.0によってリッチインターネットアプリケーション(RIA)を作成できるなら、シンプルにWebブラウザ中心のソフトウェア基盤だけで十分じゃないか、というGoogleらしい提案．
Googleが行ったChrome OSのデモでは、同OSはASUSのEee PCで7秒で起動し、さらに3秒でアプリケーションにログインした。
Contacts and panel 確かに軽い
Google Chrome OS 開発版 ダウンロード提供開始、普通のPCで動く．
Google Chrome OS は認証済みハードウェア構成とカスタムファームウェアを備えたデバイスにのみプリインストールで製品化される計画です．
開発版はもちろん普通のPCで試せます。公開されたのは、仮想環境で動くイメージ版。動かすためにはVMwareが必要です。イメージとVMware Player (無償)のダウンロードはリンク先から。BitTorrentやなにかでも落とせます。
ダウンロード - Chrome OS 0.4.22.8 VMware (300MBくらい)
ダウンロード - VMware Player
２０１０年まで 待てないかな？
Google Chrome OS
Googleが「Google Chrome OS」のプレビューが発表。Chrome OSはLinuxカーネルを採用し、Google Chromeブラウザを高速に動作させることだけに特化したオペレーティングシステム(スピード、簡単、セキュリティに焦点)。Linuxカーネル上にウィンドウシステム(といってもコアはX.orgで一から作ったわけではなし)を新たに作り、ブラウザ画面が中心となる。アプリケーションは全てWebアプリケーションで、チャットや音楽プレーヤはブラウザとは独立して表示できる。安全性を高めるため、全てにサンドボックスが適用されている。そして、必要のないものは全て削除し、スピードを上げることに努力している。
コールドブートの時間は7秒を約束(デモは12秒)
x86とARMアーキテクチャをサポート: ハードウェアはGoogleの定義するリファレンスの認証を受ける必要あり
最初はネットブックで登場: 内部ストレージはあくまでキャッシュのためであり、ハードディスクではなくSSDのみを利用
リリースは2010年末を予定
エイサー、アドビ、ASUS、Frescale、HP、レノボ、クアルコム、Texas Instruments、東芝はChrome OSのサポートを表明
ドライバは証明が必要: ストレージ、プリンタをサポート
ビデオコーデックはハードウェアアクセラレーションを使ったものを開発中
システムは勝手に自動更新される
オフラインではメディアの再生は可能だが、基本はオンラインである必要がある
開発版はブラウザ同様Chromium OSと呼ばれ、ソースコードがダウンロードできる
コールドブートの時間は7秒を約束(デモは12秒)
x86とARMアーキテクチャをサポート: ハードウェアはGoogleの定義するリファレンスの認証を受ける必要あり
最初はネットブックで登場: 内部ストレージはあくまでキャッシュのためであり、ハードディスクではなくSSDのみを利用
リリースは2010年末を予定
エイサー、アドビ、ASUS、Frescale、HP、レノボ、クアルコム、Texas Instruments、東芝はChrome OSのサポートを表明
ドライバは証明が必要: ストレージ、プリンタをサポート
ビデオコーデックはハードウェアアクセラレーションを使ったものを開発中
システムは勝手に自動更新される
オフラインではメディアの再生は可能だが、基本はオンラインである必要がある
開発版はブラウザ同様Chromium OSと呼ばれ、ソースコードがダウンロードできる
2009年11月16日月曜日
SPDY
Googleが「SPDY」（SPeeDY）という、新たなデータ送受信技術を発表.
SPDYはWebのコンテンツを高速に送受信するためのアプリケーションレイヤのプロトコルで、複数のストリームを同時に利用したり、リクエストの優先度付けやHTTPヘッダ圧縮といった機能を備えている。
現在Webで利用されているHTTPはシンプルでエレガントであり、現在でも非常に有用であるが、ウェブサイトやブラウザの進化に対応していくためにSPDY技術や、それをサポートするWebサーバーおよびクライアントを開発したそうだ。
SPDYはまだ開発中の段階であるが、実験ではWebページの読み込みを55％高速化できたとしている。
高速化は日本のお家芸だったが．．． ．
SPDYはWebのコンテンツを高速に送受信するためのアプリケーションレイヤのプロトコルで、複数のストリームを同時に利用したり、リクエストの優先度付けやHTTPヘッダ圧縮といった機能を備えている。
現在Webで利用されているHTTPはシンプルでエレガントであり、現在でも非常に有用であるが、ウェブサイトやブラウザの進化に対応していくためにSPDY技術や、それをサポートするWebサーバーおよびクライアントを開発したそうだ。
SPDYはまだ開発中の段階であるが、実験ではWebページの読み込みを55％高速化できたとしている。
高速化は日本のお家芸だったが．．． ．
2009年11月13日金曜日
Ｇｏ 継続
Goはご多分にもれずC風の構文を持つ．ガベージコレクタや、「チャネル」および軽量プロセス「ゴールーチン」といった並列プログラミング対応、イテレータ、クロージャ、リフレクションなどの特徴を持つ。
設計と実装にはかつてベル研UNIXチームに在籍した Ken Thompson、Rob Pike、Russ Coxの3人や、Google Chromeの高速JavaScriptエンジン開発で知られるRobert Griesemerなど、Googleならではの超豪華キャスト．
ベル研が開発した分散OS、Plan 9 をJava風にアレンジしたInfernoに搭載されていたLimbo言語にそっくりとう話もある
ベル研チームがGoogle移籍やオブジェクト指向の隆盛に嫌悪感を示していたRob Pikeが「JavaやC++よりもオブジェクト指向的」と積極的にぶち上げてる。
プログラムサンプル内に日本語がある。
Go公式サイトのプログラム例
package main
import "fmt"
func main() {
fmt.Printf("Hello, 世界\n")
}
05 package main
07 import fmt "fmt" // Package implementing formatted I/O.
09 func main() { 10 fmt.Printf("Hello, world; or Καλημέρα κόσμε; or こんにちは 世界\n"); 11 }
漢字ではなく日本語（とギリシャ文字）である。
youtubeにアップされた一時間のデモで「This is a 日本語 string」なるconst strが扱われている。
設計と実装にはかつてベル研UNIXチームに在籍した Ken Thompson、Rob Pike、Russ Coxの3人や、Google Chromeの高速JavaScriptエンジン開発で知られるRobert Griesemerなど、Googleならではの超豪華キャスト．
ベル研が開発した分散OS、Plan 9 をJava風にアレンジしたInfernoに搭載されていたLimbo言語にそっくりとう話もある
ベル研チームがGoogle移籍やオブジェクト指向の隆盛に嫌悪感を示していたRob Pikeが「JavaやC++よりもオブジェクト指向的」と積極的にぶち上げてる。
プログラムサンプル内に日本語がある。
Go公式サイトのプログラム例
package main
import "fmt"
func main() {
fmt.Printf("Hello, 世界\n")
}
05 package main
07 import fmt "fmt" // Package implementing formatted I/O.
09 func main() { 10 fmt.Printf("Hello, world; or Καλημέρα κόσμε; or こんにちは 世界\n"); 11 }
漢字ではなく日本語（とギリシャ文字）である。
youtubeにアップされた一時間のデモで「This is a 日本語 string」なるconst strが扱われている。
Go
Googleの有名開発者たちがGoというシステムプログラミング言語を発表。複雑だったことがシンプルに書けそう。スクラッチからプログラムを書く時代ではなく、既存プログラムやサンプルプログラムを拡張しながらプログラムを作る時代。既存のGoプログラムに手を入れやすいプログラミング言語か否かが普及するか否かを決めるのではないでしょうか。
マルチコアへの対応を重視しているようです。
Goを開発した理由として、「コンピューティングの状況が一変したのに、10年間以上システムプログラミング言語が登場していない」とのこと。ここ10年間、新しいシステムらしい新しいシステムは登場していない。
世の中が新規に開発された新OSを望んでいるかというと、技術者を含めて多くの方は、新しいOSよりも枯れたOSを機能強化した方が安定かつ安全でいいと言い出す状況。
システム記述言語としての 幕開けだが、特徴はみえない．
マルチコアへの対応を重視しているようです。
Goを開発した理由として、「コンピューティングの状況が一変したのに、10年間以上システムプログラミング言語が登場していない」とのこと。ここ10年間、新しいシステムらしい新しいシステムは登場していない。
世の中が新規に開発された新OSを望んでいるかというと、技術者を含めて多くの方は、新しいOSよりも枯れたOSを機能強化した方が安定かつ安全でいいと言い出す状況。
システム記述言語としての 幕開けだが、特徴はみえない．
2009年11月11日水曜日
Entity Group
Entity Groupとトランザクション処理
Entity Groupとは、一口で言えば「トランザクションを使ったアトミックな読み書きの対象となるEntity（＝データベース上のオブジェクト）の集まり」である。
同じEntity Groupに属するEntityのいずれかを操作する際には、db.run_in_transaction() という仕組みを使って一連の操作をAtomicに行う。一つのスレッドがトランザクションから抜ける時に、常にデータの整合性が取れた形になっていることを保証することにより、スレッドやマシンが何台に増えようと破綻することなくサービスを運営することが可能になるのだ。
Google App Engineの特徴は、このEntity Groupを自由な形でいくつでも作ることができる点。そして、データベースそのものが巨大になって複数のマシンにまたがってしまっても問題なくスケールする点。それぞれのEntity Groupに対してトランザクション処理ができるため、全体のスループットを落とさずに同時期に大量のトランザクション処理を行うことが可能になるのだ。
Google App Engine上でEntity Groupを作るには、一つGroupのルートとなるEntityを定め、他のEntityをその子孫（子供、孫、ひ孫、...）として関連づければ良い。
そんな親子関係を作っておくと、それらの（同じEntity Groupに属する）Entityを実際にディスク上で近いところに格納することにより高速なトランザクション処理を可能にする、というのもApp Engineのすぐれた所だ。
このあたりの「概念」からしっかりと把握した上でGoogle App Engine上のアプリを作ることをおすすめする。結局のところ、スケーラブルなウェブサービスが作れるかどうかは、Datastore上のデータ構造をどう設計するかにかかっているのだから。
トランザクション指向設計？な感じだ．確かに理論モデルは背景に見えないが、実用的な気がする．ＤＢの世界は論理設計になると、関係代数の世界になってしまう．いきなりＣＬＡＳＳの登場だ．
この違和感は 私だけなのだろうか？
Entity Groupとは、一口で言えば「トランザクションを使ったアトミックな読み書きの対象となるEntity（＝データベース上のオブジェクト）の集まり」である。
同じEntity Groupに属するEntityのいずれかを操作する際には、db.run_in_transaction() という仕組みを使って一連の操作をAtomicに行う。一つのスレッドがトランザクションから抜ける時に、常にデータの整合性が取れた形になっていることを保証することにより、スレッドやマシンが何台に増えようと破綻することなくサービスを運営することが可能になるのだ。
Google App Engineの特徴は、このEntity Groupを自由な形でいくつでも作ることができる点。そして、データベースそのものが巨大になって複数のマシンにまたがってしまっても問題なくスケールする点。それぞれのEntity Groupに対してトランザクション処理ができるため、全体のスループットを落とさずに同時期に大量のトランザクション処理を行うことが可能になるのだ。
Google App Engine上でEntity Groupを作るには、一つGroupのルートとなるEntityを定め、他のEntityをその子孫（子供、孫、ひ孫、...）として関連づければ良い。
そんな親子関係を作っておくと、それらの（同じEntity Groupに属する）Entityを実際にディスク上で近いところに格納することにより高速なトランザクション処理を可能にする、というのもApp Engineのすぐれた所だ。
このあたりの「概念」からしっかりと把握した上でGoogle App Engine上のアプリを作ることをおすすめする。結局のところ、スケーラブルなウェブサービスが作れるかどうかは、Datastore上のデータ構造をどう設計するかにかかっているのだから。
トランザクション指向設計？な感じだ．確かに理論モデルは背景に見えないが、実用的な気がする．ＤＢの世界は論理設計になると、関係代数の世界になってしまう．いきなりＣＬＡＳＳの登場だ．
この違和感は 私だけなのだろうか？
2009年11月10日火曜日
辞退の理由 - 完全なる証明
なぜグリゴリー・ペレルマンが、フィールズ賞をはじめとする数多の賞を辞退しつづけたのか。
グリーシャにとってフィールズ賞も一〇〇万ドルの懸賞金も、むしろ不遇度を上げるための道具立てに過ぎないのだ。どちらも自らの証明の証明には少しも貢献しないのだから。
「説明させ、それに耳を傾けること」だ。これこそが、グリーシャが求め、そして得るべき報酬だったのだ。
耳を傾ける人は、誰でもよいというわけではない。説明を理解できる人でなければならない。不運なことに、問題が高度になればなるほど、耳を傾けられる人は少なくなっていく。そんな数少ない人の一人が、マイケル・フリードマンである。ペレルマンの業績を最も評価し寿ぐべき立場にいる人だが、フリードマンはペレルマンの仕事を、トポロジーにとって「ちょっと残念なこと」だと述べ、ペレルマンがその分野で最大の難問を解いてしまったせいで、いまやトポロジーは魅力を失い、結果として「今いるような才能あふれる若者たちは、もうこの分野からいなくなってしまうだろう」と。
これで打ちのめされぬだとしたら、研究者ではない。
意味が理解できないが、数学者の孤独感を見た気がする．理解してほしい人の評価のあり方．確かに難しい．「わかる人」にわかることを拒絶されることは、そうでない人にそうされるより遥かにダメージが大きいのだ．
グリーシャにとってフィールズ賞も一〇〇万ドルの懸賞金も、むしろ不遇度を上げるための道具立てに過ぎないのだ。どちらも自らの証明の証明には少しも貢献しないのだから。
「説明させ、それに耳を傾けること」だ。これこそが、グリーシャが求め、そして得るべき報酬だったのだ。
耳を傾ける人は、誰でもよいというわけではない。説明を理解できる人でなければならない。不運なことに、問題が高度になればなるほど、耳を傾けられる人は少なくなっていく。そんな数少ない人の一人が、マイケル・フリードマンである。ペレルマンの業績を最も評価し寿ぐべき立場にいる人だが、フリードマンはペレルマンの仕事を、トポロジーにとって「ちょっと残念なこと」だと述べ、ペレルマンがその分野で最大の難問を解いてしまったせいで、いまやトポロジーは魅力を失い、結果として「今いるような才能あふれる若者たちは、もうこの分野からいなくなってしまうだろう」と。
これで打ちのめされぬだとしたら、研究者ではない。
意味が理解できないが、数学者の孤独感を見た気がする．理解してほしい人の評価のあり方．確かに難しい．「わかる人」にわかることを拒絶されることは、そうでない人にそうされるより遥かにダメージが大きいのだ．
2009年11月7日土曜日
ロードバランサ
負荷の上昇に伴って要求を複数のサーバに分散し、ユーザーに提供されるパフォーマンスのレベルを均等に保つ必要がある。ロードバランスは、受け取った要求を複数のサーバに分散するためのプロセスであり、受け取った要求を複数のサーバに分散するためのプロセスである．
高可用性がキーワード．
Apacheのmod_proxy_balancerエクステンションが代表例である．
その他の主技術は以下のものがある．
サーバの応答をバッファ化；負荷が高くなってきたらロードバランサが応答をバッファまたはキャッシュから取り出して返すようにすれば、サーバの処理能力を節約して、他の優先度の高いタスクに振り向けることが可能。
サーバの「健康診断」を実施して、ダウンしたサーバまたは過負荷状態のサーバを認識できる。サーバの稼働状況の診断は、ほぼリアルタイムに行うことも、定期的に行うこともできます。異常なサーバが見つかった場合は、それぞれのソリューションの要件や機能に応じて手動または自動で正常なサーバに置き換える。
大規模なポータルは、ハッカーからさまざまな手口で攻撃され、深刻な脅威にさらされる．例えば、同じURLを連続して要求してDoS（Denial of Service：サービス停止）攻撃や分散DoS（Distributed Denial of Service）攻撃を実行するプログラムは、サーバに極度の負荷を与える。ロードバランサは、このような攻撃を緩和または阻止する能力を備えている．
支援しているＰｊ で ふと思った ことでした
高可用性がキーワード．
Apacheのmod_proxy_balancerエクステンションが代表例である．
その他の主技術は以下のものがある．
サーバの応答をバッファ化；負荷が高くなってきたらロードバランサが応答をバッファまたはキャッシュから取り出して返すようにすれば、サーバの処理能力を節約して、他の優先度の高いタスクに振り向けることが可能。
サーバの「健康診断」を実施して、ダウンしたサーバまたは過負荷状態のサーバを認識できる。サーバの稼働状況の診断は、ほぼリアルタイムに行うことも、定期的に行うこともできます。異常なサーバが見つかった場合は、それぞれのソリューションの要件や機能に応じて手動または自動で正常なサーバに置き換える。
大規模なポータルは、ハッカーからさまざまな手口で攻撃され、深刻な脅威にさらされる．例えば、同じURLを連続して要求してDoS（Denial of Service：サービス停止）攻撃や分散DoS（Distributed Denial of Service）攻撃を実行するプログラムは、サーバに極度の負荷を与える。ロードバランサは、このような攻撃を緩和または阻止する能力を備えている．
支援しているＰｊ で ふと思った ことでした
2009年10月29日木曜日
麗しの天才科学者、五十嵐悠紀
五十嵐悠紀さん は現在、東京大学 工学系研究科 先端学際工学専攻 博士課程2年に在籍している。彼女はこれまでの研究成果で数々の賞を獲得してきた、いま注目のプログラマらしい．
http://www.acm.org/src/subpages/gf_entries_06/YukiMori_src_gf06.pdfの論文で注目され、
この論文では、ボリュームデータ（中身の詰まった3次元データ）の複雑な内部構造を解析するために、内部構造をよく表す断面を自動で提示する手法を提案している。
内部構造を可視化する研究では、半透明にしたり、等値面で表したりすることが主流であり、既存の断面生成システムでは、ユーザーの経験や知識を基に試行錯誤を繰り返して断面を指定するため、必ずしも内部構造の特徴を表せておらず、効率的でもなかった
ボリュームデータの位相的特徴をよく表した断面を自動的に抽出するシステムを開発、経験や知識のないユーザーにもボリュームデータの内部構造を解析することが可能となった。
http://www.ipa.go.jp/jinzai/esp/2005mito2/gaiyou/5-28.htmlのアイディアのはおもしろさで決定的になったと思う
コンピュータ上にマウスやペンタブレットでぬいぐるみをデザインすることで、コンピュータが自動で型紙を作成してくれる技術を研究。 素人がぬいぐるみを作る場合、市販のぬいぐるみキットや本の型紙を基に作るのが精一杯で、オリジナルのぬいぐるみを作りたいとき、完成図である3次元を想像しながら2次元の型紙をデザインすることは困難である。
それをコンピュータが支援し、自動で型紙を作り出し、ユーザーは3次的で思い描くものをコンピュータ上にスケッチすればよく、できた型紙は家庭用プリンタで印刷し、その型紙に沿って材料を縫い合わせればぬいぐるみが完成する仕組み。
学術的に新しいところは、常にシミュレーションを行いながら、ぬいぐるみにしかならないモデリング、ぬいぐるみモデラー（モデリングソフト）を作っていることです。つまり、モデリングとシミュレーションを融合して両方を同時に行うということです。
素人でも使えるインタラクティブなコンピュータグラフィックス（CG）、そのためのユーザーインターフェイス（UI）の研究に取り組んでいるそうで、3次元モデルからぬいぐるみやあみぐるみを作るものづくりに興味があり、作る過程で不可欠な教育も視野に入れて研究しているそうだ。
横浜国大の某女史に似ているが、好きなことをPG上で実現してしまうタフさがすごい．
人生においては収入よりも「好きなことができているかどうか」を重要視していきたいと考えています。生活のために必死になって働くのではなく、自分がやりたいこと、好きなことを楽しくやることができれば、それが一番ぜいたくであり、幸せだと思います。
この生き方には脱帽です．
http://www.acm.org/src/subpages/gf_entries_06/YukiMori_src_gf06.pdfの論文で注目され、
この論文では、ボリュームデータ（中身の詰まった3次元データ）の複雑な内部構造を解析するために、内部構造をよく表す断面を自動で提示する手法を提案している。
内部構造を可視化する研究では、半透明にしたり、等値面で表したりすることが主流であり、既存の断面生成システムでは、ユーザーの経験や知識を基に試行錯誤を繰り返して断面を指定するため、必ずしも内部構造の特徴を表せておらず、効率的でもなかった
ボリュームデータの位相的特徴をよく表した断面を自動的に抽出するシステムを開発、経験や知識のないユーザーにもボリュームデータの内部構造を解析することが可能となった。
http://www.ipa.go.jp/jinzai/esp/2005mito2/gaiyou/5-28.htmlのアイディアのはおもしろさで決定的になったと思う
コンピュータ上にマウスやペンタブレットでぬいぐるみをデザインすることで、コンピュータが自動で型紙を作成してくれる技術を研究。 素人がぬいぐるみを作る場合、市販のぬいぐるみキットや本の型紙を基に作るのが精一杯で、オリジナルのぬいぐるみを作りたいとき、完成図である3次元を想像しながら2次元の型紙をデザインすることは困難である。
それをコンピュータが支援し、自動で型紙を作り出し、ユーザーは3次的で思い描くものをコンピュータ上にスケッチすればよく、できた型紙は家庭用プリンタで印刷し、その型紙に沿って材料を縫い合わせればぬいぐるみが完成する仕組み。
学術的に新しいところは、常にシミュレーションを行いながら、ぬいぐるみにしかならないモデリング、ぬいぐるみモデラー（モデリングソフト）を作っていることです。つまり、モデリングとシミュレーションを融合して両方を同時に行うということです。
素人でも使えるインタラクティブなコンピュータグラフィックス（CG）、そのためのユーザーインターフェイス（UI）の研究に取り組んでいるそうで、3次元モデルからぬいぐるみやあみぐるみを作るものづくりに興味があり、作る過程で不可欠な教育も視野に入れて研究しているそうだ。
横浜国大の某女史に似ているが、好きなことをPG上で実現してしまうタフさがすごい．
人生においては収入よりも「好きなことができているかどうか」を重要視していきたいと考えています。生活のために必死になって働くのではなく、自分がやりたいこと、好きなことを楽しくやることができれば、それが一番ぜいたくであり、幸せだと思います。
この生き方には脱帽です．
2009年10月27日火曜日
商用クラウドコンピューティング
Amazonはバーチャル・サーバーの仕組みを、「一つのパワフルなサーバーを複数のバーチャル・サーバーとして小分けしてレンタルする」ことに使ってはいるものの、「サーバーを完全にバーチャルにしてハードウェアと切り離し、ハードウェアに問題があってもサービスには一切支障をきたさない」というレベルまでは使っていない。バーチャル・サーバーと呼ぶのであれば、「ハードの問題」とか「特定のCPUから別のCPUへの引っ越し」とかを見えなくしてほしい。
ec2を使っても「データベースのお守り」は自分でしなければならないこと。バックアップとか修復とか、それなりの手間はかかる。そして当然だが、データベースのスケーラビリティの問題を解決するのもサーバーの借り手の責任である。一つのデータベースで足りているうちは良いが、ユーザーが増えて複数のデータベースに分けなければならない段階になると、パーティショニングやリプリケーションやらといろいろと複雑な問題を解決しなければならない。
クラウドコンピューティングを「サーバー運営のアウトソース」という意味で見た時に、Amazon と Google では、セルフサービスの学食とフルサービスのレストランの違いぐらいがある。
「ハードウェアの故障にどう対応しよう」「ユーザーが増えた時にデータベースをどう分けよう」などのことは心配せずに、サービス作り・ソフトウェア作りに１００％集中したいのであれば、Google App Engineの方が格段の「おもてなし」である。
自分でOSのインストールまでできるAmazonと比べると以下のような制限がある：
1. Goolgle App Engine上のアプリケーションはサンドボックスの中で走る。OSのインストールはもちろんだめだが、それだけでなく、さまざまなリソースへのアクセスはかなり制限される（「ファイル」を作ることができない、デーモン・プロセスを起動したり、TCP/IPソケットを開きっぱなしにすることもできない）。基本的に、「入って来たHTTPリクエストを高速にステートレスに処理する」ことしか出来ない。
2. データベースはGoogleのDatastore（Big Table）を使わなければならない。MySQLやOracleのようなリレーショナル・データベースとは違い、スキーマレスのオブジェクト・データベースなので、リレーショナル・データベースに関するノウハウはほとんど使えない。作ったアプリケーションを他の環境（例えばAmazon ec2）に大きな変更を加えずに持って行くことは不可能。
3. 公式にサポートされている言語は、PythonとJava（Javaの上でRubyやPHPなどの他の言語を動かすことは可能）。
商用で評価できる状態になってきた、クラウドだが、そろそろ勝負がつき始めている．今からはじめるのは遅いと思うのだが
ec2を使っても「データベースのお守り」は自分でしなければならないこと。バックアップとか修復とか、それなりの手間はかかる。そして当然だが、データベースのスケーラビリティの問題を解決するのもサーバーの借り手の責任である。一つのデータベースで足りているうちは良いが、ユーザーが増えて複数のデータベースに分けなければならない段階になると、パーティショニングやリプリケーションやらといろいろと複雑な問題を解決しなければならない。
クラウドコンピューティングを「サーバー運営のアウトソース」という意味で見た時に、Amazon と Google では、セルフサービスの学食とフルサービスのレストランの違いぐらいがある。
「ハードウェアの故障にどう対応しよう」「ユーザーが増えた時にデータベースをどう分けよう」などのことは心配せずに、サービス作り・ソフトウェア作りに１００％集中したいのであれば、Google App Engineの方が格段の「おもてなし」である。
自分でOSのインストールまでできるAmazonと比べると以下のような制限がある：
1. Goolgle App Engine上のアプリケーションはサンドボックスの中で走る。OSのインストールはもちろんだめだが、それだけでなく、さまざまなリソースへのアクセスはかなり制限される（「ファイル」を作ることができない、デーモン・プロセスを起動したり、TCP/IPソケットを開きっぱなしにすることもできない）。基本的に、「入って来たHTTPリクエストを高速にステートレスに処理する」ことしか出来ない。
2. データベースはGoogleのDatastore（Big Table）を使わなければならない。MySQLやOracleのようなリレーショナル・データベースとは違い、スキーマレスのオブジェクト・データベースなので、リレーショナル・データベースに関するノウハウはほとんど使えない。作ったアプリケーションを他の環境（例えばAmazon ec2）に大きな変更を加えずに持って行くことは不可能。
3. 公式にサポートされている言語は、PythonとJava（Javaの上でRubyやPHPなどの他の言語を動かすことは可能）。
商用で評価できる状態になってきた、クラウドだが、そろそろ勝負がつき始めている．今からはじめるのは遅いと思うのだが
2009年10月24日土曜日
クラウドコンピューティング と SLA数値
可用性が99.9%ではダメとか、99.99%でも心配となる。確かに可用性は大問題なのですが、クラウドコンピューティングにはSLA値大小以前に本質的な問題がある。
クラウドコンピューティングではSLAに示された数値が妥当なのかを検証が難しい。
つまり 可用性の高低以前に、インフラ事業者が提示した可用性の真偽がわからないことがクラウドコンピューティングの可用性の本質的な問題なのです。
確かにクラウドなので 見えないのが当たり前なのだが、見えないところは、金融証券化が可能で、それをしたらと 吹きまくる人もいる．
シビアな可用性が必要なら 他を犠牲にしなくてはならない．
クラウドコンピューティングではSLAに示された数値が妥当なのかを検証が難しい。
つまり 可用性の高低以前に、インフラ事業者が提示した可用性の真偽がわからないことがクラウドコンピューティングの可用性の本質的な問題なのです。
確かにクラウドなので 見えないのが当たり前なのだが、見えないところは、金融証券化が可能で、それをしたらと 吹きまくる人もいる．
シビアな可用性が必要なら 他を犠牲にしなくてはならない．
2009年10月21日水曜日
2=1
国立ヨハネスブルク大学教授のイワノフ・ボスコノビッチ博士。
a=b
a*2 = ab ( *a)
a*2 - b*2 = ab- b*2 (-B*2)
(a+b)(a-b) = b(a-b)
a+b = b
2b= b (a=b)
2 = 1
論文として英数学誌「マスマティック・ロジスティック」１月号に投稿。以来世界中の数学者がこの論文の反証を試みたが、９月現在いまだに完全な解答と呼べる論文は出ていない。
「マスマティック・ロジスティック」誌の編集長であるジョン・ロック氏は「ボスコノビッチ博士の論文自体はいたってシンプルで、掲載された式だけならば中学生でも理解できる。しかし、それが誤りであることを証明するには非常に高度な数学の知識を必要とするため解明にはまだまだ時間がかかるだろう」。
論文は２と１が等しいという、一般的な通念とは大きく異なる結果を示しており、万が一この論文が正しいということが証明されれば、ユークリッド幾何学の根本を揺るがす大きな一石となる。
文字式のあや と思いきや 意外と a を掛ける こと 以外 疑問点がない
a=b
a*2 = ab ( *a)
a*2 - b*2 = ab- b*2 (-B*2)
(a+b)(a-b) = b(a-b)
a+b = b
2b= b (a=b)
2 = 1
論文として英数学誌「マスマティック・ロジスティック」１月号に投稿。以来世界中の数学者がこの論文の反証を試みたが、９月現在いまだに完全な解答と呼べる論文は出ていない。
「マスマティック・ロジスティック」誌の編集長であるジョン・ロック氏は「ボスコノビッチ博士の論文自体はいたってシンプルで、掲載された式だけならば中学生でも理解できる。しかし、それが誤りであることを証明するには非常に高度な数学の知識を必要とするため解明にはまだまだ時間がかかるだろう」。
論文は２と１が等しいという、一般的な通念とは大きく異なる結果を示しており、万が一この論文が正しいということが証明されれば、ユークリッド幾何学の根本を揺るがす大きな一石となる。
文字式のあや と思いきや 意外と a を掛ける こと 以外 疑問点がない
2009年10月20日火曜日
MVC
「Ruby on Railsフレームワークは本来のMVCとはほど遠い」「Ruby on Railsの上にMVCのことを意識せずに普通にアプリケーションを作ると、ビジネスロジックをControllerに混ぜ込んで書く事になってしまい、『データの整合性』を保つことが難しくなる」という点である。
「Railsを使って（データの整合性が大切な）アプリケーションを作る場合、素のままのActiveRecordにControllerから直接アクセスするのは避け、ActiveRecordの上に一枚皮をかぶせる形でビジネスロジックを含んだModelをきちんと設計・実装し、ビジネスロジックがControllerに浸食していくことを意識して避けることが大切である。
Javaにおいても同じような「えせMVC症候群」は蔓延しているようで、MVCの本質を理解していないエンジニアが、うすっぺらなDAO(Data Access Object)の上にビジネスロジックを含んだ分厚いControllerを書きながらそれをMVCと思い込んでいる、という話は良くあるらしい。
いつの世にも 似非＊＊＊はいるもので、表面的な理解が生んでしまう．特に単語人間にそれが多い．
「Railsを使って（データの整合性が大切な）アプリケーションを作る場合、素のままのActiveRecordにControllerから直接アクセスするのは避け、ActiveRecordの上に一枚皮をかぶせる形でビジネスロジックを含んだModelをきちんと設計・実装し、ビジネスロジックがControllerに浸食していくことを意識して避けることが大切である。
Javaにおいても同じような「えせMVC症候群」は蔓延しているようで、MVCの本質を理解していないエンジニアが、うすっぺらなDAO(Data Access Object)の上にビジネスロジックを含んだ分厚いControllerを書きながらそれをMVCと思い込んでいる、という話は良くあるらしい。
いつの世にも 似非＊＊＊はいるもので、表面的な理解が生んでしまう．特に単語人間にそれが多い．
2009年10月13日火曜日
O/Rマッピング
「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題。
・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題）
↓
・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない）
↓
・O/Rマッピングにより抽象化したデータは一見れっきとしたModelに見える（ここが誤解のもと）
↓
・O/RマッピングとHTMLテンプレートを使っただけで、自分は「MVCのデザインパターンに従った設計が出来る」という幻想を抱かせる（これが大きな誤解）。
↓
・本来ならModelの中に記述すべきビジネスロジック（ビジネスルールに基づいてデータベースにアクセスし、データの整合性に責任を持つロジック）をControllerの中に記述しはじめてしまい、結果的にController層が必要以上に分厚くメンテナンスしにくいアプリケーションができてしまう（スパゲッティのできあがり）。
「この業界でプロとして仕事をするなら、使う言語やフレームワークにかかわらず、オブジェクト指向とMVCのコンセプトだけはしっかりと理解した上で仕事をしてほしい。そして、O/Rマッピングを使う時には、それだけでModel作りが終わったと誤解してはいけない」。
オブジェクト指向と同じく、MVCのコンセプトは「はやりすたり」とは関係のない良いアプリケーションを設計する上での基本中の基本。
いつの世ににも 上滑りの人はいるもので、PROGRAMができれば！ではない世界があることを猛省している．
2009年10月11日日曜日
アジャイるとリーンのモデル？？？
- Chris Matts のモデル:
「意識」と「コンピテンス」のマトリクスになっている。
アジャイルが、企業の競争力を高めるための「意識的な課題の解決」に焦点を当てているのに対して、リーンは、この課題解決を「無意識化」する活動だ。この「無意識化」には知識の転送が必要だ。そう、リーン企業では、競争力は無意識化されているのだ。
ますます 心理学化 してしまう． このモデルに 何の 工学的モデルが 見出せるのだろう？
かんばん だって ベースは 理論的だと 思うのだが．
アジャイル
アジャイルは現実のソフトウェア開発の中で「ソフトウェア工学」が捉えそこなったものの１つだ。アジャイルが発見したことは、ソフトウェア開発のボトルネックは「ソフトウェア工学」の部分にはもうすでになくなっていて、ビジネスとソフトウェア工学を繋いでいる「ソーシャル活動」の部分にあることだ
スクラムは、「役割定義とビジネスと開発の間のコミュニケーションパターン」だということができる。アジャイルは、言ってみれば工学の考え方を開発のソーシャルな面に延長したのだ。
アジャイルは、「ビジネスとソフトウェア工学の間のコネクタ」ということだ。
理論的背景をを求めない 遠吠えに 聞こえるのだが．工学にできない理由を面ってどうなるのだろう？こつこつ メトリックス をして 工学に しなければ と 思う
2009年10月10日土曜日
HTML5時代
サービスを作り上げる段階よりも、運営のことを考えた設計が大切なこと。つまり、メンテナンスしやすい、テストしやすい、多少のミスをしても大丈夫、こまめなアップデートがしやすい、作業分担がしやすい、などである
テンプレート等を利用したHTMLのダイナミックな生成をすべてやめて、データ（JSONもしくはXML)だけをダイナミックに生成するようにし、HTMLはスタティック・ファイルをサーバー側に置いておく．CSS, HTML, JS, Media Filesはすべてスタティック・ファイル．
HTMLをスタティックファイルにし、JavaScriptでJSONなりXMLを引っ張って来て表示する設計にしておけば、さすがにそこの仕様定義をおろそかにはできない。
データベースの整合性の責任を１００％Modelに負わせ（つまりModelを単なるO/Rマッパーではなく、ビジネスロジックを含んだモジュールとして設計して作り込む）、そこだけは徹底的なテストケースを作って強固なものにしておくことにより、Controller側の変更で多少のミスをしてもデータベースの整合性が壊れたりしない、という設計にしておくとController側の変更がもう少し気楽に、かつ頻繁にできる．
HTML5の時代かなと思わせる．IEあやうしだ
2009年10月7日水曜日
要求定義
- システム開発の上流工程として最も重要なものとされている、本質的な課題として次の3点が挙げられる
- 要件の目的や要件を決めるべき役割の曖昧さの排除
- 経営層、業務部門、情報システム部門における納得性の高い合意形成
- 要件を洗練させ、十分な検討を経た上で期限内に確定させるマネジメント
新要件定義手法は、
- 要件の構造化
- 因果関係からみた要件の可視化
- 要件を成熟させるプロセス
といった3つの方法論から構成され、要件の階層構造データベース、関係分析ワークシート、要件定義の手順書、要件評価シートなどをユーザーに提供。
要件の構造化
「要件の構造化」では各要件を、経営層、業務部門、情報システム部門の3つの役割と、目的、手段の繰り返し構造によって整理。経営の目的、施策、業務要求、実現手段、システム機能の5つの階層で要件を構造化する。この構造化によって、役割ごとに定義すべき要件、部門間で合意するべき要件が明らかになるとともに、要件の安全性が確認できるため曖昧さを排除できる。
因果関係からみた要件の可視化
5つの階層で構造化した要件の関連をひとめで把握することができるワークシートを用意。 これにより、要件の充分性、妥当性などを客観的に分析することが可能になり、納得性の高い合意形成や優先順序づけにより、要件の絞り込みに貢献できる。
要件を成熟させるプロセス
「要件を成熟させるプロセス」では、要件定義の作業を経営層、業務部門、情報システム部門の間や、関連する業務部門間、部門内の部門長や担当者間といった利害関係者間の調整を考慮した合意形成のための5つのフェーズを用意、12のタスクに分けてタスクごとに利害関係者間の合意形成を、まんべんなくとるための作業を定義する。フェーズは、「スタートライン」「ステージ1」「中間レビュー」「ステージ2」「最終レビュー」と5つの段階。さらに、各タスクの完了時に各要件の検討度合いを38の軸から評価し、要件の成熟度を把握、適切なタイミングでの対策などを可能とする。
失敗するプロジェクトを分析すると、そもそも失敗する商談を獲得してしまうこと、上流工程における要件確定の不備が原因となっていることが多い ユーザー企業には要求と要件が違うということをわかっていただきたい。
要求とはやりたいことを洗い出すものであり、要件とは機能に着目し、投資金額や投資期限を前提として、できる内容を定義するものであり、両者の違いを明確化しなければならない．
富士通の新しい要求定義手法だが、目新しさはない．
2009年10月4日日曜日
登録:
投稿 (Atom)
