最近は、暇を見つけて「Simply Lift」を写経してたりします。

Simply Lift
http://simply.liftweb.net/

練習台の一つとして、cometを利用したchatアプリケーションを作るチャプターがあります。
せっかくなので、cometの動作見ようぜ！ってWin8仮想環境立ち上げてみようとしたら思うように動かなかった。。。というお話。

まずは、Mac上のChromeで動かしてみると

問題なく追加されます。
ちなみに、Safariを立ち上げて確認しても当然問題なく動作する。

この状態でWin8上のIE10からアクセスすると・・・

追加されているはずのメッセージが出てきません。
しかも、開発者ツールで見てみると。。。

JavaScriptのエラーが出ている状態です。
上記画像ではcloneNodeで失敗していますが、それを通り過ぎてもjQuery関係で軒並みエラーになる状態。
jquery.jsのダウンロードが出来ていない訳ではないので、ちょっと原因はわからない。
リロードすると文字を読み込んでくれたりもしますが、
JavaScriptのエラーが出る事に変わりはなくて文字の追加はやっぱり出来ない状態になります。

わかっている回避策

もしかしたらHTML上のソースをいじる事で何とかなるのかもしれないけど、
このチャプターではほとんど自分でページを作っておらず、Lift任せ。

とりあえず、前回のIE10問題よろしく

ローカルエリアネットワークなどのサイトへ登録すると、ちゃんと動きました。

と言うことは、セキュリティ関連の問題では無いだろうか？と言うことで

イントラネット上のセキュリティをインターネット側と同様に「中」へ。
さらに保護モードをONに変更して試してみたが、問題なく動作してしまった。

うーん、この辺り結構微妙な動きしているなぁ。
さて、これバグだとは思うんだけど何が原因で起きているんだろう・・・？
ちょっと詰まってしまったな。

Windows8のConsumerPreviewがリリースされてから随分と経ちますが、
ボチボチとIE10に関してもいじり始めています。

IE10での動作を確認する上で、気をつけなければいけないのは、
「デスクトップスタイル」と「Metroスタイル」のIEが2つあるということですね。
FlashやActiveXなどを利用しているサイトの場合はデスクトップスタイルのIE一択になるとは思いますが。

IEの9から10にかけての変更点はいくつかあるものの、既存のサイトが動かなくなるような変更はそれほど加えられてはいないし、
デスクトップスタイルとMetroスタイルは内部的なエンジンは共通と言うこと。、少し油断していたのですが。。。

こんなページが出てしまった。
デスクトップスタイルで試してみるが、こちらでは表示出来る。

見ての通り、このサイトはローカルにたてたサンプル用のテストサイト。
いっさいFlash等は使用していないし、使用していたとしてもその部分が表示されないだけではないだろうか？

一つ前の、PlatformPreviewの段階では細かくは確認していないとはいえ、一応表示は出来ていた記憶はあるんだが…。
どういうことだ？
ということで、ちょっと調べてみたらこんなPostを見つけた

Understanding Enhanced Protected Mode
http://blogs.msdn.com/b/ieinternals/archive/2012/03/23/understanding-ie10-enhanced-protected-mode-network-security-addons-cookies-metro-desktop.aspx

これの、少し下に行ったところ。「Private Network resources」セクションに

However, for historical and other reasons, Security Zones consider this dotted hostname to be an Internet-Zone address by default, which means that if you attempt to navigate to the Router configuration page in Metro-style IE, you may encounter a Page Cannot Be Displayed error page. If you enable EPM in the Desktop mode of the browser, you can use the F12 Developer tools to see why the request was blocked:

えーっと、端的に言うとセキュリティのために”.”区切りのアドレスでアクセスした場合にはエラーを出すよって事かな？
いやいや、別に今回直接IPアドレスでアクセスした訳ではないんだが。。。

とりあえず、出ているエラー内容は同じなので、回避策も同じではないかと試してみた。
示されている回避策は

• “.”区切りではなくする
• 信頼済みサイトに入れる

と言うもの。

とりあえず、信頼済みに登録してみることに。

https限定のチェックを外して登録を押す。

すると、表示出来た。

ちなみに、「信頼済みサイト」ではなく「ローカルイントラネット>サイト>詳細設定」で追加しても表示出来る事を確認した。

どういう事か？

この現象が発生するのは、Metroスタイルというよりも、

• 「拡張保護モード」がON
• ネットワーク接続の形態が「プライベートネットワーク」
• 「信頼済みサイト」もしくは「ローカルイントラネット上のサイト」として登録されていない

という条件のように見える。

デスクトップスタイルのIEに対して、インターネットオプションから拡張保護モードをONにする事でも現象を確認していて、
さらにネットワーク接続が「プライベート」ではなく「パブリック」では発生しない。

パブリック時に発生しないと言うことは、共有設定と関係しているのかな。
当初はLANの中には危険がいっぱいなので、拡張保護モードがONの場合には制限してしまえっ！って事なのかと思ったが、
インターネットオプションでLANとして登録した場合に問題が起きなくなるというのは変な話だ。

うーん、これ。
単純に判定ミスってるバグなのかな？

実際のところ、企業ではイントラ上にサイトを立ち上げている事なんか山のようにあるだろうし、
それらについてわざわざ登録して行くというのは非常に面倒。
拡張保護モードオフにしてしまえばいいじゃないかって話は無くはないんだけど、
それはそれでこの機能の存在意義が無くなってしまう訳で。。。

ちなみに、Windows8でネットワークのプロファイルを「パブリック」、「プライベート」等に変更するには

を選択して、接続情報を右クリック＞「Turn sharing on or off」を選択。

こちらで切り替える事が可能です。
なにげにこの変更方法を知るのにずいぶんと時間をかけてしまいました。。。

二日間に及んだMicrosoft社の初音ミクイベントWindows Developer Dayが終わりました。

キーノートでクラウディアさんが初音ミクの音楽に合わせて流れ、
さらにその制作風景とかを順を追って[@waki]さんが説明し始めた時には
一瞬何のイベントかわからなくなりましたが。
ちなみに私の隣の席にいた人は、キーノート中でしたがイヤホンしてニコ動にアクセスし始めてました。

さて、そんなこんなで二日目です。
引き続きMetro関連セッションが多い中で、HTML+JavaScript+CSSで作るMetroアプリに関するセッションをいくつか聞きました。

HTML+JS+CSSによるMetroアプリ

IE10によってHTML5やCSS3の多くがサポートされるからといって、
そのメリットがどれだけあろうが実際のWebページを作る上ではまだまだIE8~9を切る事が出来ない状態は続きます。
これは、例えIEの自動更新が行われてもしばらくは言えると思っています。

ただし、Metroアプリという形であればそもそも後方互換を取る必要がない。
気にする事無くHTML5によるアプリケーション開発が行えるという話でした。

もちろん、Metroアプリになるわけなので純粋なWebアプリとは異なる要素を多く考えなければいけない。
WinRTを利用するコードやWinJSを利用するコードが出てくる事になる。
オフライン、オンラインへの対応や多彩な解像度への対応等々考えなければ行けない事は色々ある。
でも、HTML5を使うという敷居としては下がったような気もする。

最後のセッションでは、既存のWebアプリをMetro対応する場合の話が出ていた。
少し気になったのは、今回。MicrosoftはMetroアプリという枠組みに関してはかなり力を入れている。
UIに対するガイドラインも充実している。
Metroアプリであれば、どれも、共通した操作性の良さと言うものを体験出来るように目指している。

非同期による通信/操作が基本となり、徹底してユーザーに待たせるような事をさせないようにしむけている。

それと、この既存のWebアプリ移植は果たしてマッチするのだろうか。
UIのガイドラインはアプリ審査に影響を与えるのだろうか？
というか、アプリの審査基準はどうなっているんだろう？

Windows アプリの証明書の要件
http://msdn.microsoft.com/ja-jp/library/windows/apps/hh694083.aspx

2.4 ユーザーがアプリのコンテキスト外のエクスペリエンスにリダイレクトすることなく、アプリ内で主要なタスクを実行できるようにする必要がある
アプリは単に Web サイトを開くもの、または単に Web サイトの動作を模倣するものであってはなりません。

まず、そのままではダメだと。
まぁ、これはその通りでしょうね。ただのお気に入りであればピン留めすればいいだけですし。

3.5 アプリは、Windows 8 のタッチ言語に記載されているタッチ操作を完全にサポートしなければならない
アプリは、ユーザーが対話要素をタッチしたときに視覚的なフィードバックを返す必要があります。

ん、これはちょっとどういう意味か微妙かも。
完全にサポートというのはどういう内容の事を言っているのかな・・・。

うーん、さすがに「UIがMetroっぽくない」で審査を落とす事は無いのかな？
どうなるんでしょうね

Microsoft社のイベントであるWindows Developer Day 1日目に参加してきました。

今年はWindows8を予定しているだけあって、ほぼその関係セッションで埋め尽くされている感があるイベント。
最近自分自身がWindowsアプリケーションを作っていないという、何とも歯がゆい状態であるのですが、

• Metroという考え方
• IE10

を柱として今回のイベントに参加する事にしました。

Metro

Windows Phoneで一躍話題になったMetroUI。
Windows8でもスタート画面がMetroになっているという事で、デスクトップモードはあるものの
誰もがMetroに強制的に触る事になります。

Metroは電車の窓をイメージ。
電車が動くと風景が横に流れて行く。そんな感じを表現したUIと言うことです。

考えてみると、今のPCディスプレイはどれもワイドスクリーンになっています。
しかし、Webブラウザやワード等のアプリケーションは、比較的縦方向のナビゲーションが多い。
スクリーンの形状はワイドが多くなっているとは言え、すべてがワイドではない以上あまり横方向へ
展開しすぎても・・・って事で、少し横が寂しい状態になってしまいがち。
そういう意味では面白いかもしれないと思った。

また、Windows8の推奨の解像度もそれを表している。
最低ラインとしては1024*768。

この状態でファイナンスアプリを起動するとこんな風になる訳ですが、

推奨としている1366*768のワイドスクリーンで見ると、右側に続きが見える状態になります。

1024*768状態では、ただの一枚絵があるだけですが、ワイドで見ると自然に横方向への視線誘導が出来ています。
（ちなみに家のPCではVirtulBoxで動かしていて、解像度をワイドにするやり方がよくわからないのでずらしているだけです）

その他、Metroに関しては盛りだくさんすぎてちょっとまとめきれません。
まだまだ英語の資料が多いようですが、少しずつ日本語訳されている記事を含めながら確認して行きたいですね

Metro スタイル アプリの UX ガイドライン
http://msdn.microsoft.com/ja-jp/library/windows/apps/hh465424.aspx

さて、ただしやはり問題となるのはMetroがどこまで受け入れられるか。

今のところ、「見る」目的のアプリケーションに関しては比較的敷居は低いように感じます。
そういう意味ではOfficeでもPower Pointなんかは移植はそれほど難しくはないかも？

でも、「入力する」事を目的としたアプリケーションはかなり工夫がいりそう。
もちろん、入力すると言っても入力の仕方は様々な訳だから一概には言えないんだろう。
ただ、ワードやエクセルはどうしたものかなぁ、と思ってしまう。

この辺り、発想を変えて望まないと行けないのかもしれない。

IE10

いや、実はIE10に関してはそれほど面白いネタがある訳ではなかったんですよね。

実際問題、IE10としては

• HTML5
• CSS3
• Metroモード

という点。HTML5とかに関しては、これまでの延長線上にある話。
そういう意味で新しいネタとしてはやっぱりMetroに落ち着いてしまうんですよね。

Metro版のIEとデスクトップ版のIE。
この違いは基本的に、プラグインの有無になります（もちろんUIがMetroというのはあるとして）

面白いのは、Windowsが64Bit版だった時にIEは64Bitが立ち上がるのか32Bitが立ち上がるのか？が異なると言うこと。
これまでは64OS上でも互換性維持を意識せざるを得ずに基本的に32Bitだったそうです。

ところが、Metroではプラグインが無いと言うことで、その点の互換性を気にする必要が無くなりデフォルトで64Bit版が立ち上がる。
ところがデスクトップ版では、引き続き互換性の問題が持ち上がるために32Bit版が立ち上がるという。
いやはや、苦労しているな。

Metroの特徴の一つに、スタートメニュー上でのタイルに対して情報を送る事が出来る

Metro IEも、ピンを留める事でスタートメニューにタイルとして登録する事が出来、Metaタグ等でこういった情報を送る事が出来る。
そう考えると、Webアプリケーションで機能別にピン留めしておいて、その最新情報をタイルに表示・・・なんて事も出来そうだ。
タイルの色とか見た目とか、工夫すれば意外と使いどころは多いかもしれない。
これがうまい事回れば、スタートメニューを簡単なRSS状態にする事も可能だったりして。そんなに多くスタートメニューに置きたくは無いか・・・。

まだまだ続くよ

Windows8のRelease Previewが6月1週という事なので、それに向けて少しずつ準備が必要ですね。
Windows Developer Day自体は明日も続きます。

内心ではMetroに関してはだいぶお腹がいっぱいになってきたので、ちょっと変わり種としてHadoopや互換性関連に目を向けて行こうかと。
まぁ、明日は明日の風がふくと言うことでわかりませんが。

既に報じられている通り、MS公式ブログにて次期WindowsバージョンであるWindows8のエディションや機能構成が公開されています

Announcing the Windows 8 Editions
http://windowsteamblog.com/windows/b/bloggingwindows/archive/2012/04/16/announcing-the-windows-8-editions.aspx

ちなみに日本語の記事としてはマイナビニュースがわかりやすいです

次期OS名称は「Windows 8」に正式決定、8/Pro/RTの3エディションに
http://news.mynavi.jp/news/2012/04/17/077/?google_editors_picks=true

そう、これまで端々でWindows8と呼ばれてきたこのバージョン。
この呼び名って結局これまでは仮だったんですよね。
結果としてはそのまま正式名称に決まってしまいましたが、この流れは続くのかな？
同様に仮名のままで公開されているWindows8Serverがどうなるのかも気になるところですね。

エディション構成としては、VistaやWin7のエディションとは異なり、すっきりと３つにしぼってきました。
これは、あれこれ余計な事を考えなくて済むので非常にありがたい事ですね。
主にMCPを検討した場合に覚える事が少なくなっていいです。

Vistaの時はどのディションが何に向いてるかとか、MS側のコンセプトを覚える必要がある一方で、
実際にはそんなに細かい使い分けを自分自身がしないという何とも言えない気分を味わいましたし。

関係ない話ですが、上の二つのページを見てわかるように、日本と外国とでは対応している機能につけるマークが異なります。
日本では、対応している機能には○を。対応していない場合には×や-をつけますが、
諸外国では対応している機能に×をつけます。

これ、何かの時（ここが変だよ日本人みたいな系統だったと思う）に知ったのですが、こうやって改めて見ると
自分自身が表や仕様書を作る時に、誤解の無いように作らないと行けないな・・・と思ってしまいました。
変に記号に頼らないほうが誤解が少ないかもしれませんね。

ここ最近、ずっとという訳ではないが頭を悩ませていた問題がようやく原因っぽいものが判明して少し安堵している。

現象としては

• 当該サーバー上でアプリケーションを操作する分には問題なし
• 別端末からサーバーに対してアクセスした時に、通信が途絶える（応答がなくなる）
• サーバー側では端末からの処理要求は来ているが、応答することが出来ずにタイムアウトとなる
• データ量によって出来たりできなかったりするような動きが見える
• 単純に大きなデータを受け渡しするようなプログラムを作って検証したら問題なかった

という感じ。
アプリケーション側の問題というよりはネットワーク関連の問題ではないかとは思っていたのだが、帯域に制限がかかっている訳でもないしファイアウォールのルールのような制限を受けているという訳でもなさそう。

結局のところ、原因としてはWindows Server 2003 Service Pack 2から導入されたSNP(Scalable Networking Pack)が悪さをしていたようだ。

Scalable Networking Pack

これは、ネットワークに対してこれまでOS側が実装してきた処理の一部をドライバ側に譲渡させることによって更なる効率化を可能にしようとした技術らしい。
餅は餅屋よろしくネットワークのことはネットワーク担当に任せて、CPUの負荷を下げることが出来る・・・とのこと。

ただ、これが最初に有効状態で出荷されたWindows Server 2003 Service Pack 2ではメーカによるのか組み合わせによるのか。うまく動かないことが多発してMicrosoftが設定を無効化するパッチを出すところまでいってしまったもの。
内容と設定の無効化方法に関してはこちらの記事を参照されたい

ネットワーク設定を標準で使ってはいけない (IT Pro)
http://itpro.nikkeibp.co.jp/article/COLUMN/20100824/351391/

実はこれが問題を引き起こすということは2003SP2が出た時に経験していたのだが、今回問題となったサーバーは2008のR2だしいい加減その辺りは問題にならないだろうとタカをくくっていた。
2008サーバーでこれまで問題にはなっていなかったということもある。

結局原因調査のためにネットワークモニタをインストールしてトレースまでとって、トレースの出方が変だったことから再度疑ってみたらビンゴするという結末だった。
この問題の厄介なところは、”いまいちよくわからないけどうまく行かないパターンがある”って見えて原因の予測がたてられなかったところ。
いや、予測という意味では早期にネットワークを疑った訳だが、具体的にネットワークの何が問題なのかが傍目から見えないんですよね。

そもそもSNPはよほどのトラフィックが発生する状況でなければあまり気にしなくてもいいレベルとも見受けられるので、今後は無条件に無効にしてしまうのがいいかもしれないな。

いやはやいやはや、やれやれだ
「やってはいけない」なんて記事が書かれているようなことをデフォルトで有効にしておいてほしくないし、ドライバ側のメーカーもそんな状態を放置しないでほしいというのが正直なところだが、大人の事情があるのだろう。