キー設定のはなし。
ウィンドウタブの切り替えは
“ウィンドウ・次のタブ”
“ウィンドウ・前のタブ”
ではなく
“ウィンドウ.次のドキュメントウィンドウ”
“ウィンドウ.前のドキュメントウィンドウ”
です!!
キー設定のはなし。
ウィンドウタブの切り替えは
“ウィンドウ・次のタブ”
“ウィンドウ・前のタブ”
ではなく
“ウィンドウ.次のドキュメントウィンドウ”
“ウィンドウ.前のドキュメントウィンドウ”
です!!
Ninjectを利用したサービスロケーターの例が載ってます。
今回は、NinjectをDIコンテナとして使用しただけで、まだまだ素敵機能満載なはずなのでいろいろ試したい。
※DependencyResolverのデフォルト実装がイケてないのはどうにかならないか?
スマホサイト作成のうち、URL振り分けについての解説。
[URL振り分け]
大まかには下記2種類の対応を行う。
(それ以外にある?)
1,PCサイトとスマホサイトでURLを統一
・CSSのメディアクエリーを使用したレスポンシブWebデザインにする。
→ MediaQuery まとめ - IT戦記 http://d.hatena.ne.jp/amachang/20080425/1209139140
・サーバーサイドで、出力するHTMLを制御する。
2,PCサイトとスマホサイトで別URLを持つ
・スマホでPCサイトへアクセスしたら、スマホサイトのURLへリイダイレクトする。
・リダイレクトはしないが、スマホサイトへの案内を表示させる。
・各種SNSのブログパーツ(イイネボタンなど)の管理が2重になる?
既存Webページのスマホ対応となると、2案で対応するほうが楽そうだが、各種SNSのブログパーツ管理が大変になりそう。
新規にWebページを作成するなら、1案での表示制御をあらかじめ考慮した設計で作成するべきだなと思った。
MS製なので、実業務にも導入しやすい?
また、.net標準クラスの動きを置き換えることができる、
ある意味めちゃくちゃなモックライブラリ。
[ライブラリ概要]
スタブとモックの両方が存在する。
スタブは、インターフェイスや抽象クラスの実装をラムダを用いてテストコード内で定義する。
モックで、既存実装の書き換えを行う。
利用方法はリンク先の通りで問題なし。
スタブ、モックの使い分け指針としては下記の通り。
スタブ:インターフェイス、抽象クラス
モック:静的クラス、既存・.net標準クラス
[.net標準クラスのモック作成]
※テストプロジェクトのAssemblyInfo.csに下記を追加する。
//■AssemblyInfo.cs
//DateTime型のモック作成を行う場合の設定。
//クラス毎にassemblyを追加するひつようあり。
[assembly: Microsoft.Moles.Framework.MoledType(typeof(System.DateTime))]
//■テストコード抜粋
[TestMethod]
[HostType(“Moles”)]
public void ドットネットクラスのモックを作成()
{
System.Moles.MDateTime.NowGet = () => { return DateTime.Parse(“2012/05/06 10:11:12”); };
Assert.AreEqual(2012, DateTime.Now.Year);
Assert.AreEqual(5, DateTime.Now.Month);
Assert.AreEqual(6, DateTime.Now.Day);
Assert.AreEqual(10, DateTime.Now.Hour);
Assert.AreEqual(11, DateTime.Now.Minute);
Assert.AreEqual(12, DateTime.Now.Second);
}
IEだけオブジェクトのlengthが1多い事象が発生したことがあるのだが、これが原因か? ケツカンマダメゼッタイ
ここを見て、自分のjavascriptコーディングスタイルが固まりました。とても参考になります。
今は下記のようにクラスベースのコードを書いてます。
var Hoge = function(initMsg){
var _cMsg = initMsg || ‘hoge!!!’;
var _setMsg = function(msg){
_cMsg = msg;
}
var _getMsg = function(){
return _cMsg
}
return {
setMessage : _setMsg,
getMessage : _getMsg
}
};
var objHoge = new Hoge(“ほげほげ”);
console.debug(objHoge.getMessage());
objHoge.setMessage(“ホゲホゲ”);
console.debug(objHoge.getMessage());
var objHoge2 = new Hoge();
console.debug(objHoge2.getMessage());
objHoge2.setMessage(“HOGEGE”);
console.debug(objHoge2.getMessage());
console.debug(objHoge.getMessage() + ” ” + objHoge2.getMessage());
QUnitの使い方についての日本語説明。 テンプレートは本家(http://docs.jquery.com/QUnit#Using_QUnit)を参照すべし。
ロールエントリーポイントクラスを拡張して、ロール起動時・終了時処理でApp_offline.htmの削除・配置を行うことで実現している。
コード内でできることであれば、スタートアップタスクを使用せずにロールエントリーポイントクラス拡張の方が(デバッグなど)しやすそう。
スキーマレスとエンティティ グループ トランザクションの利点を活かすことを考えると、テーブルをあまり細かく分割するのは有効な戦略ではないことがわかります。例えば、Person と Friends ならば、テーブルを同じにし、同じ人 (aPerson) のデータは同じパーティションに入れるような使い方が良いでしょう。
このデータ構造は、各個人のデータはトランザクショナルに処理されるが、人と人との間の通信はトランザクショナルではないことが前提になっています。例えば、A さんから B さんへメールを送ったときに、A さんのメールボックスの送信箱にはトランザクショナルに入れますが、B さんの受信箱には、非同期に非トランザクショナルに入れます。B さんの受信箱への送信処理は、Windows Azure Queue に A さんの送信箱のメールの ID を入れるようにします。
このような非同期処理はインターネットで使われているメール配信に似ており、スケーラブルな実装です。
.jpg)
| Entity Set Name | 内容 |
| Data | オブジェクトのデータ |
| Index | インデックス |
| Log | ストレージの変更履歴ログ |
Person、Payment、Order などのアプリケーション オブジェクトは、Data に入れます。Data 内には複数のクラスのインスタンスが入るので、Rowkey の先頭に Type を付けて区別します。
"— 4. Windows Azure Table を使ったストレージ設計 | Windows Azure Table の利用 | MSDN
TableStorageの性能評価
その道のプロによる評価
データ サイズ
データ サイズがストレージ性能へ及ぼす影響は小さいです (2 KB、8 KB は要注意)
→ TCP/IP レイヤーの遅延 ACK 設定の影響を大きく受ける。
http://p2pquake.ddo.jp/diary/20080501.html このあたりの話のようだ。
スループット
エンティティ グループ トランザクションを使うと、スループットが上がります。トランザクションが必要ない場合も、使えるときは積極的に使うべきです。
同一テーブルに異なったクラスを保存できる (スキーマレス) ので、関連するデータは同一パーティション キーにして同じテーブルに入れるとよいです。
スループット、レイテンシー、コストの兼ね合いで、バッチ サイズを選ぶべきです。
スケーラビリティ
スケーラビリティを考えると、パーティションを分割するべきです。
パーティション分割のペナルティは、複数パーティションをまたぐアクセスだけです。
VM サイズ
VM サイズの選択は、アプリケーションがどれぐらいメモリ、CPU を使うのかで決めます。今回のテストでは、S サイズだと、スレッド数が多くなると頭打ちになる傾向がありました。M サイズ 1 インスタンスで、ストレージの単一インスタンスのパフォーマンス上限に達しました。それ以外は、VM サイズによる違いは認められませんでした。
パーティションを分けてもパフォーマンスが頭打ちのときは、要注意です。
今回のような書き込みが大量に発生するバッチなどのパターンで、問題が起きることがあるかもしれません。
おすすめ
トランザクションが必要なデータは、同一テーブル、同一パーティションに入れます。
パーティションは積極的に使ったほうが分散されます。
更新は、まとめて行なったほうが良いです。