9月 092014
 

概要

  • L-02F で W4-820 を用いてインターネット通信をした場合、断続的に無通信状態が発生する
    • 途切れまくるので、正直そのままでは使いものにならない

環境

  • 使用ルーター : LG L-02F
  • 使用PC : Acer Iconia W4-820 (以下W4)
  • 使用SIM : ぷららモバイル LTE 定額無制限プラン

再現条件

  • 他 W4 端末でも再現する
  • PC側に iPod touch 5G, MacBook Pro, Nexus7, iPad mini 等を用いても再現しない
  • ルーター側に URoad-Aero, WR8700N を用いても再現しない
  • L-02F の PWLAN を利用して URoad-Aero 経由でインターネット接続しても再現しない
  • L-02F の Wi-Fi を用いて他PCと通信した場合も再現しない
  • L-02F の設定、W4 の NIC 設定、NIC ドライバで影響があるものは発見できなかった
  • W4 がバッテリ駆動の時は再現し、電源接続時は再現しない

回避策

powercfg -setdcvalueindex 381b4222-f694-41f0-9685-ff5bb260df2e 19cbb8fa-5279-450e-9fac-8a3d5fedd0c1 12bbebe6-58d6-4636-95bb-3217ef867c1a 0
パラメータ 説明
-setdcvalueindex バッテリ駆動 時の設定
381b4222-f694-41f0-9685-ff5bb260df2e バランス プラン
19cbb8fa-5279-450e-9fac-8a3d5fedd0c1 ワイヤレス アダプターの設定
12bbebe6-58d6-4636-95bb-3217ef867c1a 省電力モード
0 最大パフォーマンス(1~3は省電力 (低/中/高))
  • この回避策を用いても、Bluetooth にて Arc Touch Mouse Surface Edition を使用している際には不安定となった
    • Bluetooth と Wi-Fi の干渉はよく知られている問題
    • L-02F で 802.11b のみを用いることで多少改善された(割り込みタイミングの問題?)
    • URoad-Aero, WR8700N を使用している場合は問題ない(たまたま?)
    • どうやら 5GHz で接続していても切れることが分かったが、どうせ屋内でしか使えないモードなので放置……
8月 222014
 

戦闘結果

  • キラ付け : MI作戦以外は実施
  • 道中支援 : なし
  • 決戦支援 : E2とE6の最後のみ
マップ 攻略時間 出撃回数 ボス到達回数 ボス到達率 ボス撃破回数 ボス撃破率
E1 4時間 14 6 43% 6 100%
E2 4時間半 14 6 43% 6 100%
E3 2時間半 10 8 80% 8 100%
E4 4時間 16 10 63% 9 90%
E5 6時間半 25 10 40% 9 90%
E6 8時間 20 11 55% 8 73%

消費(遠征込み)

  • E4以降は途中に長時間休憩を挟んでいるため、実際の消費よりいくらか少ない。
マップ 燃料 弾薬 鋼材 ボーキ バケツ
E1 5977 4649 2949 389 51
E2 4790 3136 2660 980 50
E3 4967 3008 2913 3700 76
E4 7360 4412 4120 5390 73
E5 12303 4716 6186 3490 111
E6 22729 7388 24454 1318 79
トータル 47348 13140 28877 16392 382

Continue reading »

7月 232014
 
  • 調べた分だけ。
  • 割とわかりやすかった:Overview of Custom Storage Providers for ASP.NET Identity | The ASP.NET Site
  • 「ASP.NET Webアプリケーション」テンプレートの認証「個人ユーザーアカウント」で作成されたコードを眺めれば何となく分かる。
  • Microsoft.AspNet.Identity.EntityFrameworkとかはEFのCodeFirstでテーブル初期化とかDB読み書きとかやってくれるやつだけど、CodeFirstが嫌でIUserStore自作するなら不要な感じ。
  • UserManagerがASP.NET Identityの中心的存在の予感。
    • OWIN startup classの中でCreatePerOwinContext()にて初期化用Funcを設定する。

PasswordHasherの入れ替え

[csharp]

public class ApplicationUserManager : UserManager
{
public ApplicationUserManager(IUserStore store) : base(store) { }

public static ApplicationUserManager Create(IdentityFactoryOptions options, IOwinContext context)
{
var manager = new ApplicationUserManager(new UserStore(context.Get()));
manager.PasswordHasher = new HogePasswordHasher();
return manager;
}
}

public class HogePasswordHasher : IPasswordHasher
{
public string HashPassword(string password)
{
// 塩を振ったりストレッチングしたりしよう
throw new NotImplementedException();
}

public PasswordVerificationResult VerifyHashedPassword(string hashedPassword, string providedPassword)
{
if (hashedPassword == HashPassword(providedPassword))
return PasswordVerificationResult.Success;
else
return PasswordVerificationResult.Failed;
}
}
[/csharp]

ちなみに、ASP.NET vNext のデフォルトっぽいPasswordHasherは以下の様な実装。

  1. Rfc2898DeriveBytesでSaltサイズのみ指定(128bitでRNGCryptoServiceProviderによって生成されるランダムSalt)にしてパスワードハッシュ生成(1000回ストレッチング)
  2. Salt + パスワードハッシュな文字列を返す(DBとかに保存する文字列になる)

検証時は

  1. DB保存的文字列からSaltとパスワードハッシュを切り離し
  2. そのSaltを利用して、入力されたパスワードからパスワードハッシュを計算
  3. 照合

2.0.0のMicrosoft.AspNet.Identity.PasswordHasher.VerifyHashedPassword()も、vNextのコードで生成したハッシュを使って検証したら成功したので、多分同じロジック。

参考:Identity/src/Microsoft.AspNet.Identity/Crypto.cs

Roleによる認可的な

Controllerで

[csharp]
if(this.User.IsInRole(“Admin”))
{
}
[/csharp]
とか
[csharp]
[Authorize(Roles=”Admin”)]
public ActionResult Index()
{
return View();
}
[/csharp]
とか。

Viewで

[csharp]
@if (this.User.IsInRole(“Admin”))
{
}
[/csharp]
とか。

7月 222014
 

そのうちまとめるつもり。

  • .NETのカラマネ対応APIは、System.Windows.Media, System.Windows.Media.Imagingの中にちょっとだけある。ほぼWPF専用なのではないかという予感…
    クラス / 構造体 概要
    ColorConvertedBitmap WICで一度だけ色変換できるBitmapSource。微妙MarkupExtensionもあるよ。
    ColorContext ICCプロファイル的なやつ。
    Color sRGB/scRGBカラーを扱う。挙動が微妙なこともあり、カラマネ的には役に立たない可能性が。
    BitmapFrameと各種Encoder/Decoder 画像ファイルを取り扱うクラス群。画像プロファイルも読み書きしてくれるっぽい。中身はWICの模様。

  • 内部的にはICM / WCS, WICを利用している。
    • System.Windows.MediaがICMに対応して、System.Windows.Media.ImagingがWICに対応するイメージなのかな?
  • いずれの場合もTransformは使い捨ててるので、パフォーマンスは微妙。
    • WCSプロファイルはTransform生成がかなり遅い(iccの30倍位)ため、非常に残念な事になる。回避するには多分P/Invokeしかない。
  • 残念なことにデバイスプロファイル等、PC/ユーザーに設定されているプロファイルを取得する方法は用意されていないので、ファイルパスを指定するかP/Invokeするしかない。

System.Windows.Media.Imaging.ColorConvertedBitmap

  • 変換元、変換先のColorContextと、変換したいBitmapSourceを指定して色変換できる。
  • これ自身がBitmapSourceを継承してるので、Image.Sourceとかに指定できる。
  • 一度初期化したら変更できない。
  • 内部的にはIWICColorTransformを使ってる。
  • ColorConvertedBitmap のマークアップ拡張機能なんてのもあるが、各プロパティ指定できるの一度きりだし、果てしなく微妙。

System.Windows.Media.ColorContext

  • イメージ的にはICCプロファイルとかと同じ。
  • 内部的にはColorContextHelperを通してICMのOpenColorProfile()GetColorProfileHeader()を利用している。
  • PixelFormatを指定して初期化することでsRGBとかscRGBのColorContextを取得できることになっているが、実際に取得されるのは コントロールパネル>色の管理>詳細設定>デバイスプロファイル に設定されているプロファイルだったり。
    • これはICMのGetStandardColorSpaceProfile()を利用しているからで、sRGBのプロファイルIDを指定しているにもかかわらず上記のような結果になるという謎挙動が原因である。
    • 既定のデバイスプロファイルではなく、ちゃんとsRGBを指定したいならば、自分でURIを指定する必要がある。

System.Windows.Media.Color

  • 一見RGBを抽象化したものに見えるが、実際はsRGB/scRGBカラーを取り扱う構造体である。
  • FromValues()およびFromAValues()にてColorContextを指定できるが、これは非常にややこしいことに「指定されたColorContext」→「既定のデバイスプロファイル(大抵はsRGB)」という変換となる。
    • 最初は「指定されたColorContextのRGB」を表す型なのかと思ってたら全然違った。
    • ComputeScRgbValues()というprivate methodの中で、PixelFormats.Bgra32を用いて変換先ColorContextを初期化しており、このソースを見る限りは本当はsRGBを変換先とするつもりっぽいのだけど、上記ColorContextの謎挙動により既定のデバイスプロファイルが変換先となってしまっている。
    • この変換処理ではColorTransformというinternal classを使っている。それ使わせてくれよ…
      • ColorTransformは、ColorTransformHelperを経由してICMのCreateMultiProfileTransform()TranslateColors()をやってくれるクラス。
    • 一色変換するだけの処理にもかかわらずTransformを使い捨てしており、コスト的にも大分残念な感じになっている。何に使うんだろうこれ…

System.Windows.Media.Imaging.BitmapFrame とか

  • まだあまり試してないが、画像プロファイルの読み書きができそうで良さ気。
  • System.Windows.Media.Imagingは大体WICと同じ雰囲気っぽい?
  • 内部的には完全にWIC依存。
  • でもIWICColorTransformとかは使わせてくれない微妙な感じ…
  • BitmapFrame.Create時などにBitmapCreateOptions.IgnoreColorProfileを指定していないと、埋め込まれた画像プロファイルからsRGB (これも同様にデバイスプロファイルかも知れない) へ変換される
    • 変換されるくせに埋め込まれたプロファイルColorContexts[0]はsRGBに置き換えられず、そのままである
    • これに気付かずにColorConvertedBitmapに食わせると、二重に変換されたりして悲しい思いをする
    • BitmapCreateOptions.IgnoreColorProfileを指定した場合、元のカラースペースを保持した状態で読み込まれる
  • CMYK画像をBitmapFrame.Createする際にBitmapCreateOptions.PreservePixelFormatを指定していない場合も、RGB PixelFormatへ自動変換される
    • 同様に、プロファイルが埋め込まれていた場合ColorContexts[0]はCMYKプロファイルのままである
  • BitmapCacheOption.None以外で読み込んだ場合、その時に指定されたBitmapCreateOptionsで画像がキャッシュされ、再読込時のBitmapCreateOptionsは無視される
    • Streamから読み込む場合はキャッシュの影響は受けないようだが、即時読込するためにはBitmapCacheOption.OnLoadが必要な点に注意

モニタプロファイルの取得

  • .NET じゃ無理ぽ
  • EnumDisplayMonitors()GetMonitorInfo()MONITORINFOEX取得
    →取得したデバイス名からCreateDC()でデバイスコンテキスト取得
    GetICMProfile()でプロファイルパス取得
  • 実コードとかはそのうち…
7月 162014
 
6月 262014
 

VisualStudioの「テストの設定」>「配置」>「ディレクトリの追加」でディレクトリを追加しても、テスト時に配置されるのはディレクトリ自体ではなく、ディレクトリの中身という。。

ディレクトリ自体をコピーしたい場合、outputDirectory属性を指定すれば解決できる。

[xml mark=”5″]


これらはローカル テスト実行用の既定のテスト設定です。



[/xml]

「テストの設定」からは操作できない属性だが、他のファイルやディレクトリを追加しても追記したoutputDirectoryは削除されない模様(VS2013 Update2)。

参考:方法: テスト用のファイルを配置する

6月 262014
 
  • 「NuGet パッケージの復元の有効化」を有効にしてる
  • プライベートリポジトリなどデフォルト以外のリポジトリを利用している

この時、PackageSourceを追加しないと復元に失敗する。
VisualStudioのオプションで追加している場合は成功するが、未設定環境では当然ながら失敗するため、設定をソースと一緒に配信したくなる。

追加できる場所で、容易にソースと一緒に配信できるのは以下のどちらか。

  • .nuget\NuGet.Config
    参照:NuGet Config Settings
  • .nuget\NuGet.targets
    [xml title=”NuGet.targets”]





    [/xml]

  • ConfigではKeyの指定があるが、targetsにはない
  • Configは、%APPDATA%\NuGet\NuGet.Config等、他の同時に読み込まれるNuGet.Configの影響も受けてしまう
    • disabledPackageSourcesで当該キーのソースが指定されていると、無効化されてしまうため、注意が必要となる
    • VisualStudio のオプションでチェックボックスをオフにするとdisabledPackageSourcesに含まれてしまう
  • Reference の解説をさらっと見た限りではConfigの書き方しか書いてない
  • NuGetパッケージマネージャーをバージョンアップした時の影響は不明…
6月 132014
 

WPFにてアクティブなウィンドウが無い状態で引数のownerを指定せずにMessageBox.Show()した場合、メッセージボックスは非モーダルな状態で表示される。
通信等をトリガーにして通知を行う場合などで発生するケース。

参考: MessageBox.cs

モーダルな状態で表示するには、Window.Activate()でウィンドウをアクティブにしてしまうか、MessageBox.Show()の引数でownerとなるWindowを指定すれば良い。