Grayrecord

話題になっている2011年10月定例会 "Big Data"アプリ情報（applog)が描くアンドロイドの未来を見てみた。彼らが言っているのはログに過ぎない。しかし、ログというのは感性という最高度の主観を含んでいる。彼らの主張の最大の問題点はどうデータの解析を解析するというところにだけ立っていてどう集めるかというところに鈍感なところであった。しかも、厄介なことにapplogSDKはapplogを最初にインストールしたアプリケーションの開発者にのみ利益が供与される仕組みであるという問題点がある。その意味ではWin-Winになっていない。そして、言うまでもないプライバシー上の問題。最終的には高木氏のTwitterでの”もうAndroidは推奨できないそういう声が多々出始めている”というコメントにまで結びついてしまった。

この事態を招いたのはAndroid Marketに対する信頼が崩れたことである。一般にセキュリティの観点からは信頼できるアプリケーションの入手元が肝心である。まさか、すべてのユーザがアプリケーションをソースコードで入手して検証し安全性を担保するという訳にはいかない以上、アプリケーションの入手元の信頼性が肝心である。この部分が崩れてしまうとどうにもならなくなる。でも、今のアンドロイドはMarketの信頼性が揺らぎ、アンチヴィルスソフトウェアのようなものも十分ではないというところから非常に危険な分水嶺にあると思う。

一般に、書きにくいパターンの一つが非同期的な動作です。今日、一般的なC言語の流れを汲む言語の場合には多くの場合、コールバック関数若しくはその類型のようなパターンを取るためプログラムが複雑化しデバッグも困難になりがちです。Reactive Extensionsはそういった非同期的な動作を平易に書くことのできるライブラリです。公式サイト上ではReactive Extensionsはなんであるかという、回答として以下の記載があります。
a library to compose asynchronous and event-based programs using observable collections and LINQ-style query operators.

公式サイトの文言がすべてと言えますが、非同期系とイベントベースのプログラムを書くためのライブラリということができます。国内だとneueccさんの記事が多分、入門としてはベターなんですがさくっと示すと、基本的に非同期系のコードは一般にコールバックの形態を取ります。まあ、C#なんかだと匿名関数が使えるのでコールバックは匿名関数として書くとしても、結果的にカッコのネスト構造はどんどん深くなります。しかも、通信系なんかだと例外処理は必須ですからその辺を考慮するとすごいことになります。この辺はneueccさんの説明がいいかと思います。これは、既にWindows 8時代を見据えたアプリケーションの構築で触れたので繰り返しません

とはいえ、サンプルでもないと判りづらいんですよね。知られているサンプルとしては101 Rx Samplesがあります。WinRTではある程度の待ち時間を発生させる機能は基本的には非同期呼び出しということになるようなのでRxは知っておいて損はしないですね。

AppLogSDKサービスの停止が株式会社ミログより発表された。

株式会社ミログ（以下、弊社）が2011年9月28日に公開したAppLogSDKに関して、一部ご指摘頂いている脆弱性の対応及び、AppLogSDKのサービスをよりよいものへと改善していくために、AppLogSDK全てのサービス、情報収集送信を停止させて頂きます。

情報送信の承諾済みのユーザーに関しては、取得送信を停止し、今後一切の情報の取得収集は行いません。新規ユーザーに対しては、情報送信の許諾画面は表示させず、情報送信取得も行いません。但し、収集サーバとの疎通確認を目的として１回程度通信が発生する点はご了承ください。 AppLogSDKの新規配布は10月3日以降停止させて頂いております。導入済みアプリ開発者様には、AppLogSDKを外して頂くことを促しており、別途対応を協議させていただきます。

AppLogSDKサービス再開に際しては、関連省庁、関連業界団体への事前説明ほか、アプリケーション開発者様、ユーザー様に対しても十分にヒアリングを行っていき、皆様のご理解を頂いた上でのサービスを再開を目指して改善に努めて参ります。サービス再開のタイミングは、別途時期が決まり次第、告知をさせて頂く予定です。

弊社は、今後もアプリケーション情報という次世代のライフログ情報の可能性を追求する取組を継続的に実施し、真摯に改善に努めて参ります。皆様からのご意見は可能な限り参考に開発に活かして参りますので、今後ともどうぞ宜しくお願いいたします。

先日来、巷間を賑わせているAppLogはAndroidのアプリケーション分析サービスであるが、問題は使用に同意しようがしまいがAndroid IDを送信するなど困った動作をする。また、アプリケーションの収益化を謳っているものの実のところ、最初にAppLogのインストールをしたアプリにのみ収益が分配される構造であるためかならずしも無料アプリを収益化できるわけではない。

その上で、既に朝日新聞の報道にあるとおり端末のIDや他にインストール済みのアプリケーションのリスト、各アプリケーションの起動時間帯などの情報を一日一回送信する。そして、どのようなアプリケーションにAppLogが組み込まれているのか判らない。通報君Zというアプリケーションの結果によれば一部の無料の電子書籍や動画アプリにも組み込まれているという。

正直、カレログといいAppLogといい、こういう結果になることは判りそうなもんなんだが。頭の中でシミュレーションしなかったんだろうか?

カリフォルニア大学バークレー校の研究チームが、fMRIを使って人間の見た映像を再構築することに成功し、Current Biologyで発表したというニューズ。オリジナルのアーティクルはReconstructing Visual Experiences from Brain Activity Evoked by Natural Moviesだと思う。Current Biologyのサイトで著者名で検索。各種報道機関による報道は以下の通り。

1. 朝日新聞: 夢が撮られちゃう？！ 米研究員ら、脳活動から映像復元
2. ITmedia: 脳の中、のぞけるようになる？ 脳内映像の再現に成功

mixiの日記等でITmediaのアーティクルから、書かれた記事を俯瞰すると、この研究成果に対して一種の恐怖を感じているアーティクルが出てくる。引き合いに出されているのはスプリガンの「人工進化」、キノの旅の「人の痛みが分かる国」あたりか。どちらも、技術の暗黒面を取り上げた題材だけれども、技術というのは概ね光と暗黒双方を内包している場合が多い。まあ、原子力関連みたいに光が遠い技術もあるけれど。

確かに、この種のBMIというのは怖さを内包している、今まで見えなかったものを可視化できる可能性があるから人工進化や人の痛みがわかる国を連想できるとは思う。方向性としては洗脳や人格の上書きのような方向に暴走する可能性もなくはない。ただ、そういう人には榊一郎氏のスクラップド・プリンセスのサプリメント3 「聖地に流れる円舞曲」の言葉が必要だと思う。つまり、技術というものは覚悟無き者に対しては呪いとなり、そうでないものに対しては祝福となるということ。

つまり、技術には光と闇双方が内包される。技術に意思はない、結局のところできるということは、それを扱う人間の意志で善にも悪にも使われえるというと。そして、暗黒面に恐怖し、一歩も外へ踏み出ることができないというのはそれ自体も負けに等しい、自分に対しての。というのも、この場合、見るのを放棄するということは光もまた放棄するということだから。

どういう光が考えられるのか、おそらくは理想像はソードアート・オンラインの7巻「マザーズ・ロザリオ」に書かれているものだと思う。恐らく、今考えられるBMIのもっとも理想的な使い方、つまり難病等で外の世界に出ることがかなわなくなった人に対して、仮想的とはいえ動く機会を提供する。ソードアート・オンラインは仮想世界を基礎としているので暗黒面的な使い方も光としての使い方もシリーズの中で両方が描かれている。アニメ化も決まったことだし、多くの人が触れるといいなと思う。

技術者としての立場を言えば、一番近いのはプロジェクト・リムーバーの風間基樹の立場だと思う。上に技術者はただ求められたものを作っていればいいという趣旨の言葉を言われて基樹が返したセリフ「ええ。でも、それではノーベルですから」使用する人間の思惑は発案者の想像を超えて暴走することを危惧したセリフですが、技術者はある種、その技術の使われ方を最後まで見届けるべきだとする基樹の立場は私のある種、根幹となっています。

1. 榊一郎: スクラップド・プリンセス サプリメント3 聖地に流れる円舞曲, 富士見ファンタジア文庫 ISBN 4-8291-1658-7
2. 河原礫: ソードアート・オンライン7 マザーズ・ロザリオ, 電撃文庫 ISBN978-4-04-870431-1
3. 篠崎砂美: プロジェクト・リムーバー 人の姿を備えしもの, 電撃文庫 ISBN4-07-307419-9

日々是遊戯のアーティクルでeuphoria物理エンジンのデモムービーが出ていた。かなりリアリスティックな動きになっています。以下にムービーを埋め込んでおきます。

基本的には筋肉等のシミュレーションやコリジョンなどの判定の組み合わせのようですが、かなりよくできています。モーションキャプチャなどのサンプリングなしと考えると、かなりです。確かにGTAならいちいちモーションをキャプチャしていたら、世界を構築するのは骨になりすぎるので有効だと思います

フォトリアリスティックなレンダリングによって、確かにいろいろな映像をレンダリングできますがモーションのところで躓いていてはまずいですから。そういう意味ではこういった物理シミュレーションの技術というのは重要になるだろうと思います。

基本的にはWindows環境で稼働するUIの手段は、いろいろあります。C/C++でGDIベースでがりがり書く手からHTMLとJavaScriptで動かす方法まで。Windows 8でMicrosoftがプッシュしているWinRTを使ったMetro-styleのアプリケーションはXAMLというUI構築手段とクラスライブラリの両面でWPFやSilverlightと共通性があります。HTML+JavaScriptにしても古くはActiveXベースのHTML Applicationまでさかのぼれると思います。

WPFやSilverlightのアプリはクラスライブラリを含めてWinRTのライブラリ群とはかなり共通性があり、Windows Phone 7のクラスライブラリとも整合性が取れるのでまとめた形でメインテナンスするのが現実的だと思います。Windows FormsはクラスライブラリがほぼGDIに一対一で対応しているのでWPFやSilverlightとは違いすぎるのが難点ですね。WebRequestなどのAPIもWIndows Formsならほぼ同期呼び出しだと思いますが、Silverlight等では非同期呼び出ししかサポートされていませんし。まあ、非同期呼び出しはBegin～Endパターンでかなり前の.NET Frameworkでも使えるので非同期で書いておくというのはいいと思います。

非同期呼び出しはそのまま手で書くと大体こんなパターンです。

• Begin～で処理開始、処理完了の移譲を渡す
• 処理完了時に呼び出されるメソッドでEnd～を叩いて終了情報を取得

ただ、そのまま書くとすごくめんどくさくなります。同期呼び出しだと状態遷移がそのままコードに流れとして現れますけど、非同期だと移譲をクロージャで書いていくとだんだんとネストが深くなっていってスパゲッティ化の兆候が表れます。

非同期系に関しては.NETではReactive Extensionsっていうベストプラクティスがあります。これに関してはneue ccさんのスライドが非常にいいのでembedしておきます。

こういった、今でも使えるベストプラクティスである程度、処理を括りだしていくとWindows 8でもカットアンドペーストを入れればかなりのコードを使いまわせると思います。逆に言うと、Windows Formsのコードが課題ですね。

現在開催中のBUILDで次期WindowsのWindows 8とWinRTの実像がだいぶ見えてきました。まあ、++C++; // 未確認飛行 C ブログのアーティクル "Windows 8、WinRT"の説明がわかりやすいと思います。

基本的にはWinRTというのはCOMの焼き直しなネイティブAPIと(純粋なIUnknown系だと結構パフォーマンスイーターですからね)、.NET的には単純に名前空間にマップされたクラス群と言えます。新規のところは同じものをHTML5+JavaScriptからも呼べることでしょう。そういう意味ではActiveX Strikes backとも言えます。

さすがに新規の名前空間なんで名前空間はかなりきれいです。その辺は整理されていると思います。この辺はWindows Forms、WPFと時間経過とともにリリースされる成果物は整理されてきていると思います。

まあ、WPFやSilverlightで、ライブラリをきちんと選んで使っているならば低コストでコードを移行できると思いますね。Windows Forms、残念ですとだけ言っておきます。GDIに直連結しているので残念な結果にしかなりませんからね。

これからのUI系の技術選択はWindows 8、WinRTの記事の通りだと思うんで重複を避けますね。まあ、XAMLをきちっと勉強していればあまり困らないと思います。

TGSが酣ですが、PlayStation Suite SDKの開発言語はC#らしいという情報が飛び込んできました。まあ、なぜかというのはロジカルに組み立てていけばある程度推測はできます。まず、PlayStation Suiteを整理すると、

• PlayStation CertificatedなAndroid端末(Experia PLAY、Sony Tabletなど)、PlayStation Vita向けの開発環境
• 開発されたアプリケーションは仮想マシンで実行

以上の2点が発表済みです。

で、問題は仮想マシンだと思います。僕の知る限り、商業的に現実的な完成度の仮想マシンは4系統しかありません。

• Oracle Java VM
• Google Dalvik VM
• Microsoft .NET CLR
• Xamarin Mono CLR

Sonyのこれまでの経緯から言って、何事もなければおそらくJava VMを使っていたと思います。ところが、言うまでもなくOracleによるSun Microsystemsの買収があり見通しが狂ったと思います。さらにはゴスリングを初めとしたJavaの中核スタッフの流失とこのところのOracle関係は騒動含みです。GoogleのDalvikはAndroidと不可分ですし、Oracleとのごたごたがあるのでやはり騒動含み。そうすると、特定の強力なプラットフォームホルダの参加にない完成度の高い仮想マシンはXamarin Mono CLRだけかもしれないです。

特にSonyはLinuxベースのカーネルではないかもしれないPlayStation Vitaで仮想マシンを動かす必要があるので仮想マシンの移植性というのがおそらく必要でしょう。少なくとも、DalvikはLinux以外の環境における実装例を聞いたことがないのでこの部分に関しては未知数です。Mono CLRは現状でもWindowsとLinux、MacOS Xで稼働しているので移植性に関してはある程度、実証済みだと考えられます。

Mono CLRは.NET CLRの互換品で必要なクラスライブラリの実装を含んでいます。そして、.NET/Monoで開発言語を選ぶとするとC#がファーストチョイスなのは間違いないです。多分、こういう選択の過程だと考えています。