IEブラウザの互換性問題の緩和方法

blog の更新をサボって早一年以上。たまにお客様にお会いすると、「blog もう更新しないんですか?」とかよく聞かれるのですが;、最近は Windows 8 タブレットアプリ開発に全力投球していたのでそれどころではありませんでした;。が、ようやく半年ぐらい苦しんでそこそこ軌道に乗ってきたので、ちょっと気分転換も兼ねて blog を書いてみようかと思ったりします。お題は IE ブラウザの互換性問題の緩和方法です。 そもそもこの記事を書こうと思った経緯は、あるお客様でこんな話を相談されたからでした。 「ブラウザを IE から別のブラウザに乗り換えたいと言っているお客さんがいる。理由としては、以前、クライアントの更改時に IE のバージョンアップに伴う再検証作業に恐ろしいコストがかかったため。他社製ブラウザだったらそういうことが起きないと思うので、IE から乗換をしたいと言われている。何か助言をもらえないか?」 ええええ;;、それはあり得ないでしょう;、と思ってしまったのですが、その後いろんなところで話を聞いてみると似たような話が次々と出てくるので、おそらくこれはきちんと現場に情報が伝わっていないのだろうと思った次第。実はマイクロソフトも様々な情報を出してはいるのですが、ぶっちゃけ情報の正確性を意識するあまりどの説明も難しくなりすぎているので、誤解を恐れずにポイントだけをざっくりまとめてみよう、というのがこの記事の趣旨です。 現在のブラウザを取り巻く環境 IE のバージョンの変遷 IE のドキュメントモード(レンダリングエンジン) レスポンス HTTP ヘッダーによるドキュメントモードの調整方法 (参考)リクエスト HTTP ヘッダー/サーバ側の挙動/ブラウザ側での解釈 クライアント OS やブラウザのバージョンアップに対する戦略 OS やランタイムのバージョンアップをなるべくラクにするために Rapid Release 時代の到来による変化と対応の考え方 それでは早速スタートです^^。 [現在のブラウザを取り巻く環境] 改めて言うまでもないですが、昨今の IT 環境の進化はものすごく速いです。例えば今や IT 業界を席巻しているタブレットの急先鋒である iPad が発売されたのは 2010 年 5 月、つまり今からたったの 4 年前。ブラウザの世界もまた非常に進化が激しく、HTML5 や CSS3 などの進化は目覚ましいものがあります。こうした中、ブラウザ各社はいち早く新機能を市場に提供するために、リリースサイクルをどんどん短くしていくことになりました。Wikipedia…

1

Part 3. Hello World, Windows Azure アプリケーションの開発 その 4

※ 本エントリは その 3 の続きです。(エントリが長すぎて投稿できなかったため分割しています) [アプリケーションの修正と Azure 環境への再配置(アップグレード)] さて、開発用ファブリックと Azure 本番環境では様々な相違点があります。Azure 本番環境で問題となりやすい制限事項としては、以下のようなものがあります。 この中でも、国際化対応に関連する問題はよくひっかかりやすいポイントになります。例えば、以下のような簡単な処理でも、Windows Azure 環境では、開発環境とは異なる動きをすることになります。 これらについては、基本的に以下の対策を行うとよいでしょう。 web.config ファイルに、データカルチャと UI カルチャを変更するための設定を追加する。 アプリケーションの中の時刻処理を、タイムゾーンを意識したコードに変更する。 1: <configuration> 2: <system.web> 3: <globalization culture="ja-jp" uiCulture="ja-jp" /> 4: </system.web> 5: </configuration> 1: // 従来であれば以下のように実装していたところを… 2: // DateTime now = DateTime.Now; 3: // 以下のように実装する 4: DateTime now = TimeZoneInfo.ConvertTimeBySystemTimeZoneId(DateTime.Now.ToUniversalTime(), "Tokyo Standard Time"); では実際に、これらの修正を加えて…

0

Part 3. Hello World, Windows Azure アプリケーションの開発 その 3

※ 本エントリは その 2 の続きです。(エントリが長すぎて投稿できなかったため分割しています) [Azure 運用環境への展開] さて、開発用ファブリック上で Web アプリケーションを開発・デバッグし終えたら、いよいよこれを本番環境である Windows Azure 運用環境へとアップロードします。この運用環境への配置(デプロイ)のためには、主に以下の作業が必要になります。 Windows Azure プラットフォームのアカウントの取得 SQL Azure データベースサービスへの移行 Windows Azure ストレージサービスへの移行 Windows Azure コンピュートサービスへの移行 このうち、1 点目のアカウント取得に関しては、すでに様々な blog などで紹介されていること、また人によって利用可能なオプション(例えば MSDN 特典など)が異なると思いますので、本エントリでは解説しません。利用可能なオプションについては、Windows Azure の PM (プロダクトマネージャ、要するに製品担当)である馬田さんの blog や、クラウド系エバンジェリストとして有名な砂金さんの blog などを参考にしてください。ここでは、アカウントを取得した後の作業を中心に解説していくことにします。 SQL Azure データベースサービスへの移行 まずはデータベースの移行です。SQL Azure データベースサービスを管理するには、まず管理サイトである https://sql.azure.com/ にアクセスし、以下の作業を行います。 SQL Azure プロジェクトを作成し、管理者アカウントを作成する。 作成時にデータセンタを選択することになりますが、通常は東南アジアのデータセンタを選択すればよいでしょう。 (ってあれ....今、地図を見たら東アジアの香港の方が近い気がする....orz) ファイアウォールの設定を緩和する。 SQL Azure…

0

Part 3. Hello World, Windows Azure アプリケーションの開発 その 2

※ 本エントリはその 1 の続きです。 [開発用ファブリック上での動作確認] 引き続き、”CloudService1” プロジェクトをスタートアッププロジェクトに変更し、Ctrl + F5 キーで実行します(※ サーバエクスプローラが pubs.mdf を握っているとエラーが発生するので、デタッチしてから実行してください)。すると、タスクトレイに “Development Fabric” と呼ばれる Windows Azure エミュレータ環境が起動し、この中でアプリケーションが起動します。 一見すると、先ほどと変わりなく動作しているように見えますが、実際にはかなり異なる環境で Web アプリケーションが動作しています。これについて以下に解説します。 開発用ファブリックのランタイム構成 最終的な運用環境では、このアプリケーションは、ファブリックコントローラによって Windows Azure コンピュートサービスのインフラ上に展開され、複数の仮想マシン(VM, Virtual Machine)が起動します。 通常、IIS 7 ではワーカプロセスとして w3wp.exe が利用されますが、Windows Azure コンピュートサービスでは、専用のワーカプロセスとして WaWebHost.exe というものが用意されており、これが起動します。この WaWebHost.exe には、以下の特徴があります。 IIS 7 のモジュールをロードして動作するため、内部動作は w3wp.exe とほぼ同じ。 内部では、ASP.NET ランタイムが統合パイプラインモードで動作している。 1 仮想マシン(サーバ)あたり 1 ワーカプロセスが起動する。(=1 つの VM の中で、複数のワーカプロセスが起動することはない) これに対して、開発用ファブリックでは、運用環境で利用される…

0

Hello World, Windows Azure Platform !!

というわけで、みなさま明けましておめでとうございます。更新が滞っているこの blog ですが、面白いネタがないとなかなかエントリを作成できないのも本音なところ。がしかし、今年最初のビックニュースはなんといっても 1 月から始まった Windows Azure の商用ラウンチ。興味がある方も非常に多いと思いますが、「そもそも Windows Azure ってなによ?」というのがなかなか分からない、という方も多いと思います。実際、いろいろなところで話を伺うと、以下のものが混同されているような場合が少なからずありました。 クラウドコンピューティング S+S (Software plus Services) Windows Azure (コンピュートサービス/ストレージサービス) Windows Azure Platform そこで今回は、技術者向けに Windows Azure Platform がどのようなものなのかについて解説したいと思います。 ※ あくまで技術者向けの資料として書きますので、ビジネス寄りの話や、お茶を濁すような書き方は敢えて避けたいと思います。(その方が、現場のエンジニアにとってはわかりやすいと思いますので。) Part 1. マイクロソフトのクラウドコンピューティング “S+S” 概要 (その1, その2, その3) クラウドコンピューティングとは何か マイクロソフトの製品とサービスの分類 インフラから見た場合のシステム形態の分類 利用者から見た場合のシステム形態の分類 クラウドコンピューティング時代のビジネスチャンス クラウドコンピューティングに関する FAQ Part 2. Windows Azure Platform 概要 (その1, その2, その3) Windows Azure…

0

単体入力エラーチェックの実装パターン

さて Part 1. のエントリでは、業務処理の終了パターンの分類と、各アプリケーションタイプにおける基本的な実装パターンを整理しました。要点をまとめると、以下のようになります。 業務処理の終了パターンは、以下のように分類される。 突き合わせエラーについては、バックエンドのモジュール(BC や DAC)との連携によるチェック作業が必要になる。UI 部単体でチェックが可能なのは、単体入力エラーに限られる。 .NET Framework では、UI 開発技術として、ASP.NET, Silverlight, WPF, Windows フォームなど、様々なテクノロジが提供されています。これらの技術には、いずれにも、UI 部において、単体入力エラーチェックを効率よく実装していくための機能が備わっています。(これらの機能は、いずれも単体入力チェックを効率よく実装するための機能であり、突き合わせエラーのチェックや、システムエラーに関する対処を実装するための機能ではありません。いや無理矢理使えば使えるかもしれませんが;、それはこれらの機能が用意された目的や意図とはズレた使い方だと考えるべきだと思います。) ① ASP.NET Web フォーム : 入力検証コントロール ② Silverlight 3, WPF 3 : 例外ベースの双方向データバインド ③ Windows フォーム 2.0, WPF 3.5 : IDataErrorInfo ベースの双方向データバインド さてこれらの機能は、いずれも「単体入力チェックを行う」「フィールド単位のチェックとインスタンス単位のチェックを行う」という点においては違いがありません。しかし、その実装方法や、エラーチェックに対する考え方は、全くといっていいほど違います。この実装方法の特性の違いを理解しておかないと、単体入力エラーチェックをうまく実装できないばかりか、開発生産性をかえって大幅に損なう結果に繋がりかねません。特に、ASP.NET Web アプリケーション開発の入力検証コントロールの使い方に慣れた人が、Windows フォームや WPF などのテクノロジを遣うと、おそらく入力検証のやり方が全くといっていいほど違うため、相当に戸惑うことになるはずです。(というよりも私はむちゃくちゃ戸惑いましたよ....orz) 本エントリの目的は、これらの各テクノロジにおける、実装パターンの違い(実装方法やエラーチェックに対する考え方の違い)を明確化することです。 ① ASP.NET Web フォーム : 入力検証コントロール 検証コントロールを使って、「正しい文字列」を作成する方式 ②…

6

エラーチェックの体系的な分類方法

まず最初のエントリでは、「エラーチェック」とひとくくりにされている「エラー」を、体系的に分類することを試みてみます。このエントリでは、Web / Windows、あるいは Java / .NET などといった技術論とは無関係な部分についての解説を進めていきたいと思います。 エラーチェック(ユーザ入力検証)の意味 正常終了/業務エラー/システムエラーの分類 業務エラーの細分化 アーキテクチャから見たエラーチェックの実装場所 ※ なお、本エントリで解説されている分類方法や命名方法は、あくまで nakama 個人の考え方・整理方法です。もしかしたらもっとよい設計パターンなどがあるかもしれませんので、その辺についてはあしからずご了承ください;。 [エラーチェック(ユーザ入力検証)の意味] まずは、そもそもどのようなケースでエラーチェックが必要になるのか、ユーザ入力検証にどのような目的があるのかを考えてみましょう。 一般的に、業務アプリケーションは、参照系アプリケーションと更新系アプリケーションに大別されます。 参照系と更新系では、求められるアプリケーションの機能が大きく異なりますが、更新系アプリケーションでは、適切な入力エラーチェックをどのように実装するのかが、極めて重要なポイントになります。そもそもなぜ更新系アプリケーションでは、適切な入力エラーチェックが重要になるのか? ユーザ入力検証(エラーチェック)には、大別して以下の 2 つの目的があります。 アプリケーションの保護 ユーザから入力された値をそのまま利用すると、エラーやセキュリティ脆弱性の原因になってしまうため、適切にフォーマットチェックなどを行う必要があります。(SQL 挿入、Cross-Site Scripting など) ユーザビリティの向上 エンドユーザに親切なエラーメッセージを表示するように作成すると、使いやすいアプリケーションを実現することができます。 しかし、このようなユーザ入力検証機能(エラーチェック機能)を場当たり的に実装すると、開発生産性を大きく損なうことになります。このため、通常のアプリケーション開発では、ランタイムが持っている「ユーザ入力検証のための機能」をうまく活用して実装していくことが重要になるわけです。 こうしたランタイムのユーザ入力検証機能を利用する上で欠かせないのが、以下の 3 つのポイントに関する知識です。 アプリケーションの終了パターンの分類 正常終了/業務エラー/システムエラーを正しく分類できること。 業務エラーが、さらに単体入力エラーと突合せエラーに分類されることを知っていること。 アーキテクチャ的な観点から見た、エラーチェックの実装方法 論理 3 階層型アプリケーションにおいて、どこで何をチェックすべきかを判断できること。 ランタイムが持つバリデーション機能(エラーチェック機能)の狙い ランタイムが持つバリデーション機能のコンセプトの違いを理解していること。 どの部分をカバーする目的で作られているのか、どこまでできるのか、その限界点を理解していること。 本エントリでは、まずこのうち最初の、「エラーパターンの分類」の部分について解説します。 [正常終了/業務エラー/システムエラーの分類] 業務アプリケーションの「入力エラー」を考える上で欠かせないのが、ひとくくりに「エラー」とされているものを体系的に分類することです。これを考えるには、業務処理が終了するパターンを、以下の 3 つに分類するのが最初のスタートポイントになります。(※ この終了パターン分類は、nakama による勝手な分類で、業界標準でもなんでもありません;。あしからずご了承ください、とつぶやいてみる^^) 正常終了 : 特に問題なく、期待通りに業務処理が終了できた 業務エラー :…

0

エラーチェックの体系的な分類と実装パターン

というわけで久しくエントリをアップしていなかったこの blog ですが、最近、複数方面からお叱りの言葉が……; 忙しかったこともあってエントリをサボっていたこともあったのですが、ちょうどいいネタがなかったのも実際のところ。がしかし、先日 2009/9/26(土) に行った、わんくま同盟さんでの勉強会のネタが blog 化するにはちょうどいいだろう、という感じなので、その資料を使いつつ、blog エントリを書いてみることにします。 今回の解説ネタは、更新系業務アプリケーションで求められることになる、エラーチェックの実装パターンを体系的に分類してみる、というものです。ASP.NET や Windows フォームなどには様々なデータ入力検証のフレームワークがあるのですが、名称こそ同じ「データ入力検証」となっていても、データ入力検証に対する考え方は、フレームワークごとにかなり異なっています。そこで、本エントリでは、特に .NET Framework 標準のデータ入力検証機能である、以下の 3 つを横並びにして解説してみて、各データ入力検証にどのような食い違いがあるのかを解説してみたいと思います。 ASP.NET 検証コントロール Silverlight 3, WPF 3 の例外ベースの双方向データバインド Windows フォーム 2.0, WPF 3.5 の IDataErrorInfo ベースの双方向データバインド なお、今回のサンプルコードは以下になります。エントリ中では、キーポイントとなるコード部分についてしか触れませんので、詳細なコードについてはこちらのサンプルコードをご覧ください。 [Agenda] Part 1. エラーチェックの体系的な分類方法 エラーチェック(ユーザ入力検証)の意味 正常終了/業務エラー/システムエラーの分類 業務エラーの分類  アーキテクチャから見たエラーチェックの実装場所 Part 2. 単体入力エラーチェックの実装パターン ① ASP.NET Web フォームの場合 ② Silverlight 3, WPF 3 の場合…

0