You are browsing the archives of f.
モバイルシステム開発勘所
以下の記事を見てちょっと思うところがあったので書いてみる。
クライアント技術の動向とコーナーへのフィードバック － ＠IT
http://www.atmarkit.co.jp/fdotnet/chushin/chushinsurvey_02/chushinsurvey_02_01.html
思うところがあった、というのも、ASP.NET MVCを身につけたいスキルとしている回答がとてつもなく少ないことに軽くショックを受けました。というかASP.NETを身につけたいスキルとして選ぶ人がちょっと信じられないくらい多い。
まぁそもそも、アンケートの回答母体自体、C/S中心な人が多そうなのでこんなもんなのかもしれません。
閑話休題。
さて、先日ついに正式に、ASP.NETによるモバイル開発に死刑宣告がされました。
モバイル開発、今後はASP.NET MVCでなんとかしてね、あとjQueryの方がASP.NET Ajax Libraryより良いのでASP.NET Ajax Libraryはフェードアウトするよ、みたいな内容です。さもありなん。（でも記事のアドレスは失念しました。誰か教えて）
まぁ死刑宣告も何も、ASP.NETモバイルコントロールは百害あって一利なし、真面目にやろうとするとデスマ必死、VS2008からは標準でサポートすらされなくなり、Connectで「お前サポートする気ないならUA判定で間違ったヘッダ返すとか余計なことすんなよ誤爆してんだよ使えねーな」と問い合わせると「Web.configでなんとかしてね、ちなみに今後サポートする予定も無いよ」みたいな返事が返ってきてたので、今更と言えば今更なお話。
そして今日に至っても、日本国内のガラパゴス携帯(?)がスマートフォンに駆逐されるわけもなく、各キャリア独自仕様でWeb開発者を悩ませ続けています。
というわけで、2010年4月現在、モバイルWebサイト開発で最低限考慮しなくてはいけない部分を覚え書きがてらメモしてみました。多少間違いや既に改善してる箇所があるかもしれません。
HTMLについて
表現力を考慮すると、XHTML 1.0 Transitionalを利用するのが無難。文字コードはShift-JISにすること。
各種制限
DoCoMoは新しい機種以外Cookieが使えないので、原則Cookieは利用しない。
→つまりセッションはURLの引数やフォームのHiddenにセッション管理トークンを埋め込んで管理する。
Javascriptは原則利用できないと考えてよい。CSSは別ファイルにせず、インラインで記述する必要がある。
画像
端末により、表示できる画像サイズ、容量が異なる。真面目にやるなら、機種の画面解像度データを持って、機種ごとに画像サイズを自動調整したい所。（有料でデータを売っている会社がある）
自動画像調整という点では、Keitai Pictureなどのサービスがあるが、このテのサービスはどこもかなり高額。
なお、画像フォーマットは普通のjpgやgifを利用可能。プログレッシブJPEGやCMYK JPEG、pngは利用しないこと。
絵文字
以下のように記述する。絵文字コードは各社で統一されているわけではないので、対応表を内部で持って、各キャリア向けに変換する必要がある。
なぜなら、DoCoMoの絵文字はAUのEZwebで表示しようとすると自動的に変換してくれるが、Softbankは何もしてくれないキチガイ仕様となっているため。
以下に変換例（記述例）を示す。（他のやり方もある）
DoCoMo
<code src=””>
AU
<img alt=”" localsrc=”44″ />
Softbank

なお、絵文字相互変換マッピングはPHP関連でおなじみのアシアル株式会社のブログにて、 JSONによる変換データが公開されいるので参考にするとよい。
フォーム
各社携帯電話のブラウザのテキストボックスに設定する入力制限あるいは既定入力モード。
例えば電話番号を入力する場合は、入力する際に入力モードが半角数字になっている、など。
全角
既定値なので各キャリア何もしない。
半角かな
textboxのstyle=”"に以下の値を入れる。
DoCoMo
-wap-input-format:"*<ja:hk>"
AU
-wap-input-format:*M;
Softbank
-wap-input-format:"*<ja:hk>"
半角英数（よく使います）
DoCoMo
textboxのstyle=”"に以下の値を入れる。
-wap-input-format:"*<ja:en>"
AU
textboxのstyle=”"に以下の値を入れる。
-wap-input-format:*m;
Softbank
textboxに以下の属性を記述する。
mode=”alphabet”
wap-input-formatを指定すると、入力初期値ではなく入力制限値になってしまうので、style=”"の値は設定できないというキチガイ仕様。
日本語が不自由な連中に丸投げして作らせたとしか思えないキチガイっぷり。
半角数値（よく使います）
textboxのstyle=”"に以下の値を入れる。
DoCoMo
-wap-input-format:"*<ja:n>"
AU
-wap-input-format:*N;
Softbank
-wap-input-format:"*<ja:n>"
端末識別
Cookieが使い物にならないため、ログインIDの記憶などは、DB上に端末識別用のIDを利用するのが無難。
また、キャリアによって識別子がSSLで送信されたりされなかったりするため、非SSL領域でのみ利用すること。（確かAUだけSSLでも送信された気がする）
他にも取得できる識別子もあるが、ものによっては機種変更でリサイクルされる？など不穏な情報もあり。
勝手サイト（笑）で利用するにはHTTPヘッダから取得できる以下の識別子を使うのが無難。
当然、簡単に偽装できるため、このIDのみでログイン状態にするなどの運用は厳禁。あくまで仮ログイン的な使い方や、個人情報を含まない（割とどうでもいい）認証にのみ使うこと。
DoCoMo（iモードID）
HTTPヘッダ上のx_dcmguidを利用する。大文字小文字違いで別端末が存在するため、照合順序などでは大文字小文字を区別する必要があるというキチガイ仕様なので注意。
また、URLの引数にguid=ONというクエリストリングが含まれていないと送信されないというキチガイ仕様なので注意。
AU（EZ番号）
HTTPヘッダ上のx_up_subnoを利用する。
SoftBank
HTTPヘッダ上のx_jphone_uidを利用する。
※ヘッダのキーについては、大文字小文字、-と_にイマイチ自信がないので良い感じに正規表現で抽出してください。
はい、というわけでモバイルサイト開発の最低限の勘所でした。キチガイ仕様満載ですが、これが最低限のレベルです。ユーザビリティに凝り出すともっとめんどくさいところが大量に出てきます。
HTMLメインの勘所なので省略していますが、これ以外にもRFCをガン無視したメールアドレスや、連続送信でブロックされるSMTPなど、とにかく面倒なことが山積みです。
.Netでこれからモバイル開発を初めてやる！という人は、これらのキチガイ仕様群を眺めて頭が痛くなってきても仕方がありません。
特にDoCoMoとSoftbankには軽く殺意が沸いてきてもそれは仕方のないことかと思います。
…で、これをどうやってASP.NET MVCでやるかと考えるともうね…
MS SQLServerの日付型キャストの仕様が面白い。
いや面白くないけど。
-- SQL Server 2000 SP4
-- Japanese_CI_AS
SELECT CAST('２０１０－０４－０１' AS DATETIME)
-- 構文エラー。文字列から日付/時刻に変換できませんでした。
SELECT CAST('２０１０-０４-０１' AS DATETIME)
-- 2010-04-01 00:00:00.000
SELECT CAST('2010-04-01' AS DATETIME)
-- 2010-04-01 00:00:00.000
-- SQL Server 2005 SP3
-- Japanese_CI_AS
SELECT CAST('２０１０－０４－０１' AS DATETIME)
-- 文字列から datetime 型に変換中、変換に失敗しました。
SELECT CAST('２０１０-０４-０１' AS DATETIME)
-- CHAR データ型から DATETIME データ型への変換の結果が日付/時刻の値の範囲外です。
SELECT CAST('2010-04-01' AS DATETIME)
-- 2010-04-01 00:00:00.000
-- SQL Server 2008 SP1
-- Japanese_CI_AS
SELECT CAST('２０１０－０４－０１' AS DATETIME)
-- 文字列から日付と時刻、またはそのいずれかへの変換中に、変換が失敗しました。
SELECT CAST('２０１０-０４-０１' AS DATETIME)
-- varchar データ型から datetime データ型への変換の結果、範囲外の値になりました。
SELECT CAST('2010-04-01' AS DATETIME)
-- 2010-04-01 00:00:00.000
-- Japanese_CI_AS
SELECT CAST('２０１０－０４－０１' AS DATETIME)
-- 構文エラー。文字列から日付/時刻に変換できませんでした。
SELECT CAST('２０１０-０４-０１' AS DATETIME)
-- 2010-04-01 00:00:00.000
SELECT CAST('2010-04-01' AS DATETIME)
-- 2010-04-01 00:00:00.000
-- SQL Server 2005 SP3
-- Japanese_CI_AS
SELECT CAST('２０１０－０４－０１' AS DATETIME)
-- 文字列から datetime 型に変換中、変換に失敗しました。
SELECT CAST('２０１０-０４-０１' AS DATETIME)
-- CHAR データ型から DATETIME データ型への変換の結果が日付/時刻の値の範囲外です。
SELECT CAST('2010-04-01' AS DATETIME)
-- 2010-04-01 00:00:00.000
-- SQL Server 2008 SP1
-- Japanese_CI_AS
SELECT CAST('２０１０－０４－０１' AS DATETIME)
-- 文字列から日付と時刻、またはそのいずれかへの変換中に、変換が失敗しました。
SELECT CAST('２０１０-０４-０１' AS DATETIME)
-- varchar データ型から datetime データ型への変換の結果、範囲外の値になりました。
SELECT CAST('2010-04-01' AS DATETIME)
-- 2010-04-01 00:00:00.000
JAPANESE_CI_ASなんだからそこらへんもうちょっと適当でいいじゃん、とか思うんだけど、それはともかく2000から2005のタイミングで全角数字が拒否されるよう仕様変更されている件。
もちろんWhere句などで利用しても同様のキャストは行われるので、日付っぽい全角文字列で比較などするとエラーになります。
設定とかで旧仕様に戻せるのかなこれ。
FastCGI for IIS7.0のアップデート
件のIIS用FastCGIモジュールがREQUEST_URIなどのサーバー変数をUTF-8でやり取りできない問題の続き。
IIS5.1、IIS6についてはVer1.5 RTW+レジストリ操作で解決しましたが、IIS7.xにいては対応がまだでした。
が、やっとIIS7.0についてアップデートが提供されました。
http://blogs.iis.net/ruslany/archive/2010/03/10/important-update-for-iis-7-0-fastcgi-module.aspx
Windows7やWindowsServer2008R2のIIS7.5用FastCGIのアップデートはまだだがな！
なお、各OSでのFastCGI for IISの状況はこちら。
http://ruslany.net/2010/02/fastcgi-module-differences-across-iis-versions/
Using UTF-8 encoding for server variable valuesがIIS7.5だけNoという。
いやこれ、実質URIにマルチバイトを含めないわけで、非英語圏のアプリケーション的には致命度が半端ないんですが…
WindowsServerAppFabricBeta2をインストール
最近料理のエントリが少ないのは鍋シーズン終了のため。
さて、たまにはBlogも更新しないとMySQLが可哀想なのでエントリ追加のお時間。
AppFabric Beta2のインストール記事。いやインストールとかクリックしてるだけで出来るだろ、って話もあるんだけどこれが地味に難しい。
前のエントリでも書きましたが、AppFabricBeta1を入れている場合は、Beta1のアンインストール、.Net Framework 4 Beta2のアンインストール、
そして.Net Framework 4 RCのインストールをあらかじめやっておく必要があります。
あとはインストーラーを起動するとこんな感じ。
Velocityのみを使いたいのであれば、Cache関係にだけチェックをつけます。ちなみに今回から、サービス名はVelocityではなく、
AppFabric Caching Serviceになりました。
あとは普通にインストールが完了するハズです。ここでエラーになったことは無いので大丈夫なはず。
そしてインストールが完了すると、ConfigurationWizardが立ち上がります。
例によって、Change…ボタンをクリックして、前もって作成しておいたDistributedCache用のデータベースを指定します。
Createなんたらをチェックすると、入力したデータベース名で、クラスタ管理DBを新規で作ろうとします。
まぁ、色々と面倒なので、前もって作っておいた方が良いとは思いますが。
新規クラスタ（通常はこっち）の場合はNew clusterを選択してください。
二台目以降の場合は、一台目で指定したDBを選択した上で、Join clusterを選択することで、クラスタに参加させることが出来ます。
あとは適当に次へ進めばインストールが完了します。どうにもうまいいかないよー、って場合は、DBでのクラスタ管理をあきらめてXMLにするとか、とにかく色々試してるとうまくいったりします。ぶっちゃけよくわかりません。
環境によってはすんげぇ積むと思います。このあたりまだまだ煮詰まってない感じなので、RC版ではかなり改善されると思いますが…
ちなみに今回のBeta2での更新ですが、DLLの名前空間が変わりました。Microsoft.AppFabric、みたいな。
あとは若干使えるメソッドやクラス名が変わっている感じ。
にしてもAppFabricは全然盛り上がりませんね。他の2つはどうでもいいんだけど（いやよくないが）、Distributed CacheはMicrosoftの人ですらMS版memcachedだと認めるぐらいなのに。
一般に公開されるインターネット Webアプリケーションには必須のサービスだと思うんだけどなぁ。トラフィックの多いWebアプリなんて、どこもmemcachedなどのKVSを駆使して負荷軽減に四苦八苦してるのに…
やっぱ公開WebアプリじゃASP.NETなんて使わねーよってことなのかねー。
Windows Server AppFabricを試す（続き…のハズが
なんかもうBeta2出てるし…どういうことなの…
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=a1ed6018-ddd1-4bd8-b4af-6561e910ebb4
ちなみに会社のパソコンで試してみた限りは、.Net Framework4.0 Beta2が入ってるとダメ。先にアンインストールして、.Net Framework 4.0 RCをインストールするのが良さそうです。
AppFabric Beta1もアンインストールする必要があります。Windows Firewallが有効になっていると失敗するのも同じ。（と思いきや、Server2008R2だとWindowsFirewall無効でもうまく完了するし…）
AppFabrice Beta1のときのVelocityは、キャッシュRemoveのタイミングがどうにも不可解な動きしかしてなかったので、そこらへん分かりやすく動いてくれるといいなー。
（追記）
QuickStartGuideのStart Cache Host Services for the First Timeの節にも書いてありますが、初めてキャッシュクラスタを利用する場合は、以下のコマンドをPowerShellで叩いてあげる必要があります。
Use-CacheCluster
あとは通常通り、
Start-CacheCluster
でキャッシュクラスタを開始できます。
ただし、Beta 1と違い、デスクトップにDistributed Cache管理コンソールへのショートカットが作成されません。
同等のものを作成できるはずですが（やり方がわかりませんが…）、モジュール読み込み済みのPowerShellからでも上記コマンドを操作可能です。
コントロール パネル\すべてのコントロール パネル項目\管理ツール\Windows PowerShell Modules
（さらに追記）
どうもAppFabric Beta 1より先に.Net Framework 4 Beta 2をアンインストールすると、AppFabrice Beta1がうまくアンインストール出来ない感じ。
再度.Net Framework 4 Beta 2をインストールして、AseSetup_adm64_6.1.exe（ページが消えてるのでGoogleのキャッシュから）を管理者権限で起動することで、なんとかアンインストール出来ました。
あとは.Net Framework 4 Beta 2をアンインストールして、.Net Framework 4 RCをインストールして、AppFabric Beta 2をインストールして・・大変だなこりゃ。
電源故障中…
メインPCの電源がついに死亡。通電はしてるんだけど、電源ピンをショートさせても、ファンがちょっと回って止まって無反応。
サーバーの予備機の電源を使ってみると、一応動くのでメインPCのエナマの電源が死亡しているということで、Amazonで在庫あるSeasonicの80PLUS GOLDの電源をポチる。
まぁ、5年ぐらい動かしていた電源なのでそろそろ壊れても仕方ない。というか十分安定稼働してくれました。お疲れ様。
・・まぁ、実はあまり紫蘇好きじゃないんだけど、在庫あって翌日に届く、割と新しめの電源って全然数無いんだよねぇ。
Windows Server AppFabric Beta1を試す～その1～
12月と1月は妙に忙しく、まったく検証できなかったので今更ながらWindows Server AppFabricを試していきます。
まずはこちら。英語ですが。
http://msdn.microsoft.com/en-us/windowsserver/ee695849.aspx
インストーラはこちらにあります。
が、依存プログラムが多いので、Web Platform Installer 2.0からインストールした方が楽ちんです。
http://www.microsoft.com/web/downloads/platform.aspx
WebPIを起動。
左下のオプションをクリックして、
エンタープライズにチェックをつけます。というかせっかくなので全部にチェックをつけておきます。
すると、WebPIの画面にEnterpriseにタブが出てきます。タブをクリックして、「カスタマイズ」をクリックすると、
AppFabric Beta 1がチェック可能になります。
あとはインストールすれば完了。ただし、注意点が二つ。
- すでにDeveloper版が入っている状態でもSQL Server 2008 Expressをインストールされそうになる
- Windows Firewallが有効になっていないと、Velocityの設定で失敗する
特に後者が致命的なのでご注意ください。アンチウィルスがファイアーウォール機能を備えているからといって、Windowsファイアーウォールを有効にしてると、
Velocity（Microsoft Distributed Cache）用のファイアウォール例外を追加するのに失敗しやがります。
ちなみに前者については、今試したらSQL Server (SQLEXPRESS)のサービスを新規に作りやがりました。ご注意ください。
…と、ここまで書いておいてナンですが、私の環境ではWebPIではDistributedCacheのサービスが動いてないので、手動で再度インストールします。
（というか、会社の環境でもWebPIでうまくいった試しが無い、というかConfigurationWizardが立ち上がらない）
上の方に書いたDownloads/DetailのページからAppFabric Beta1のインストーラをダウンロード（asesetup_amd64_6.1.exe）して、右クリック→管理者として実行をクリック。
WebPIでインストールしてしまっていたので、いったんRemoveします。再起動して、AppFabric Beta1のインストーラを再度実行。
規約を読んで次へ。
DistributedCacheをインストールするよう、チェックをつけて次へ。
DBへのConnectionStringsを指定されるので、前もってMonitoringとPersistence、DistributedCache用のDBを作成しておきましょう。
こんな感じでDistributedCacheの設定をします。こっちもEditボタンで、DBを指定しておきましょう。
後は次へボタンでインストール完了。こちらもWindowsファイアーウォールが有効になってないと、例外追加で失敗するのでご注意。
無事インストールが完了すると、サービス一覧に Microsoft project code named “Velocity” CTP4として追加されます。
続きは次回。