緒言

Windowsのライブラリは特にWindows 8/RTにとっては標準のフォトやミュージックといったアプリケーションを使うために非常に重要です。特に必然的にModern Style Appsでの作業が多くなるSurface等のWindows RT環境では特に重要です。しかし、ライブラリにはリムーバブルデバイスを追加できない制約があり、ストレージの制約からMicro SDカードをストレージとして扱いたいSurface RTの特に32GBモデルでは厄介な制約になります。

この制約に直面したとき、直ぐに思いついたのがリパースポイントで逃れられないのかでした。そして、実際にリパースポイントを設置して確認してみたところ、どうやらうまくいったので報告します。

本論

ライブラリでリムーバブルデバイスを登録できないのは純粋に技術的な見地ではリムーバブルなデバイスをライブラリに登録された場合、メディアの交換に伴って生じるデータベースの更新が問題になるからだと考えられます。しかし、Micro SDカードは交換を想定したデバイスとはいいがたくSurface RTでもキックスタンドの内側という交換しにくい位置に設置されています。従って、多くの場合、データベースの更新が必要になる可能性は低くこの問題は生じにくいと考えます。

そうなると、どのようにしてシステムのデバイスの認識を騙すかが問題となりますがライブラリの登録時にはドライブレターでデバイスの情報を取出し、判断を行っていると推定されます。従って、ドライブレターにデバイスを割り当てずリパースポイントで固定ディスクと認識されるデバイスの下位のディレクトリにリンクすればこの制約を逃れられる可能性があります。

方法

今回はSurface RT上でmklinkコマンドを使用しジャンクションを作成して対応した。

Usage:

MKLINK [[/D] | [/H] | [/J]] <リンク> <ターゲット>

       /D          ディレクトリのシンボリック リンクを作成します。既定では、
                  
ファイルのシンボリック リンクが作成されます。
       /H         
シンボリック リンクではなく、ハード リンクを作成します。
       /J         
ディレクトリ ジャンクションを作成します。
      
リンク      新しいシンボリック リンク名を指定します。
      
ターゲット  新しいリンクが参照するパス (相対または絶対)
                  
を指定します。

であるので、今回は

MKLINK /J c:\users\\SDCard d:\

とした。

結論

そして、作成したジャンクションをライブラリに登録することにより、本アーティクルの目的であるMicroSDカードをライブラリに登録することができた。

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

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

情報送信の承諾済みのユーザーに関しては、取得送信を停止し、今後一切の情報の取得収集は行いません。新規ユーザーに対しては、情報送信の許諾画面は表示させず、情報送信取得も行いません。但し、収集サーバとの疎通確認を目的として1回程度通信が発生する点はご了承ください。 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 物理エンジン

| コメント(0) | トラックバック(0)

日々是遊戯のアーティクルで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のコードが課題ですね。

Windows 8 and WinRT

| コメント(0) | トラックバック(0)

現在開催中の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#がファーストチョイスなのは間違いないです。多分、こういう選択の過程だと考えています。

緒言
参戦中のInstall Maniax 5において、WordPressをWindows Azure上にインストールしました。Windows AzureへのWordPressのインストールにおいては既にコンパニオンがリリースされています。コンパニオンを用いたWindows Azure環境のインストールにおいてはできるIM5のアーティクルに従えば難なくインストールすることが出来ました。
手順
1. Windows Azure Companionの選択と入手
2. Windows Azure Companionのための環境づくり
3. ServiceConfiguration.cscfgの修正
4. Windows Azure CompanionをAzureにデプロイする
5. Windows Azure CompanionからWordPressをインストールする
6. WordPressの設定

1. Windows Azure Companionの選択と入手

Windows Azure CompanionはInstall Maniax 4のレギュレーションで選択できる最も小さいスケールのSmallを使用しました。今回の大会でこれ以上のスケールを選択してもコストがかかるだけですので今回はSmallとしました。

2. Windows Azure Companionのための環境づくり

Install Maniax 4に参加していたので、基本的な設定はそのままInstall Maniax 4のインスタンスを削除したサブスクリプションをそのまま活用したので基本的に再設定の必要な項目はありませんでした。

3. ServiceConfiguration.cscfgの修正

今回引っかかったのはここでできるIM5のアーティクルには問題があり、xmlタグが閉じていないことと大文字・小文字の間違いが一か所あります。フィードURLを指定するタグは修正の必要があります。

4.以降はできるIM5の通りで、今回はWordpressのDBにはAzureインスタンス上に展開した、MySQLを用いました。

旧サーバからの再掲記事です。

"X-FRAME-OPTIONS" は InternetExplorer 8.0 で導入された HTTP レスポンスヘッダです。単純に言うと、自サイトのコンテンツが外部のサイトのフレーム上に表示されることを制御します。それにより、透明度などを操作することでユーザのクリックを横取りするような企図を阻害することを狙っています。

X-FRAME-OPTIONS には "DENY" と "SAMEORIGIN" の二つが存在します。"DENY" は他の Web ページ上からの frame や iframe でのコンテンツ参照を禁止します。"SAMEORIGIN" は Top-level-browsing-context が一致しないページからの表示を禁止します。

"SAMEORIGIN" は判りづらいんですが、HTML 5 の "5 Web browsers" ではこう説明されています。

The browsing context with no parent browsing context is the top-level browsing context of all the browsing contexts nested within it (either directly or indirectly through other nested browsing contexts).

それ以上の親が存在しないブラウジングコンテキストは Top-level-browsing-context であると。で、ブラウジングコンテキストとは何よというと、この辺は HTML 5 のアプリケーションキャッシュでも使われているんですがまだ理解が追い付いていません。Mozilla developer center の "offline resources in Firefox" でも登場する概念なんですが。

とりあえず、当 blog のコンテンツは他ページからのフレームでの利用を想定していないので X-FRAME-OPTIONS "DENY" を設定しました。

No SQLの虚実

| コメント(0) | トラックバック(0)

No SQLというバズワードが喧伝されてしばらくが経ちます。しかし、この本質を捉えた議論はあまり見られませんが結構、見どころのあるアーティクルをいくつか拝見しましたので紹介します。

  1. NoSQLをRDBの代わりに使うと、どういう恐ろしいことが起こるか。PARTAKEの作者が語る (publickey1.jp)
  2. RDB開発者におくるNoSQLの常識 (@IT)
  3. あえてNoSQLでクラウド上にエンタープライズアプリを作ってみる(小野和俊のブログ)

根本的には1.で語られているようにNo SQLはDomain Specific Databaseです。一言でいえばたった一つの目的のためにそれ以外すべてをあきらめたモデルです。よく言われるようにNo SQLのほとんどのDBはCOUNTすらなく数を数えることもできません。

しかし、現実的には2.のようにDomain Specificであるという特性はほとんど語られません。ある特定領域のためのシステムであるということはほとんど語られることはないです。

No SQLが強力なのはCAP定理のうちAとPに的を絞っているからです。結果的にはアプリケーションとしては何十万人・何百万人が同時アクセスするようなニーズに向きます。反面、アクセスがそこまでではなく、むしろデータの整合性が重要な業務システムには全く向きません。

それに一般に言われるスキーマに縛られないというのも眉唾物で、確かに固定したスキーマは持ちませんがキー構造はスキーマから導かれるので、実はスキーマ変更は構造化したSQLデータベースよりも深刻な結果を招きます。この問題は先の1.のアーティクルが参考になります。

3.のように「RDBMS or NoSQL」という二者択一の考えを捨て、これまでの経験やスキルにも固執せず、適材適所で両者を使い分けていくことだとする意見もありますが、論理的にNo SQLで作れてRDBで作れないアプリケーションはほとんどないということです。ただし、パフォーマンス的にRDBでは実用にはならないアプリケーションは存在します。

したがって、No SQLをうまく使うには事前の設計が重要です。確かに固定のスキーマはないんですがキー構造を後から組み替えるのはかなり面倒なことになるのでどのようにデータを引いてくるかという設計が欠かせないです。この部分の設計はかなり重要ですが、システムの要件がかっちり決まりきっているわけでもない限り結構、要件が後で変わることは多いです。そうなると、かなり面倒です。

ウェブページ

Powered by Movable Type 6.0.3