今日も予報が外れて強風。昨日よりも強く、風速5〜6m/hくらい。

それでも二日目になるとだいぶ慣れてきたんで、追い風、逆風側でいろいろ試してみた。特にポジションとフットワークに気をつけてみたところ、だいぶ風で流れる球に対する入り方が安定した。

ただ、球の深さにだいぶ対応できるようになってくると、今度は左右のズレ(風で流されるだけでなく、風で球にかかっている回転の効果も強調されるんで、バウンド後の左右への変化も大きくなる)への対応が難しくなってきた。左右のズレへの心構えは、深さとはまた別の意識を持つ必要がありそうだけど、まだその具体的なコツは見つからず。

最後の方は、ネットプレイの頻度を増やしてみたんだけど、結果はぼろぼろ。風で変化する球相手にネットに出るのは、いつもにも増して難しい。途中までの軌道で打点を予測してボレーをしている場合は、ことごとく失敗する。最後までちゃんと球を見ないとなー。

そして練習が終わる頃には風がほとんど止んで、とてもいいテニス日和になっていた。今から始める人たちは幸せだねー。明日は風がないといいけど。

APIコールしたときの結果として、パラメータとして?format=xmlと書いたらXML形式で、?format=jsonと書いたらJSON形式で結果を返すようなやつを、どう書けばいいのか。

もちろんそれぞれ別々にアクションメソッドを用意するとか、ビューだけを差し替えるとかいろいろ手があるけれども、JSONに関してはJsonResultという便利なクラスが用意されているんで、それを使いたい。 元となる結果データは、シリアライズされること前提でクラスで定義することにした。

[sourcecode language="c#"]
public class ApiResult
{
  public string StringResult;
  public int IntResult;
  public bool BoolResult;
  public StringDictionary parameters = new StringDictionary();
}
[/sourcecode]

こんな感じの結果クラスを用意しておいて、

[sourcecode language="c#"]
public  ActionResult SomeApiCall(string format)
{
  ApiResult result = new ApiResult();
  // resultにいろいろセットする
  switch (format) {
    case "json":
      return Json[result];
    case "xml":
      var serializer = new XmlSerializer(typeof(ApiResult));
      var stream = new TextWriter(new StringBuilder());
      serializer.Serialize(stream, result);
      var xmlResult = new ContentResult();
      xmlResult.Content = stream.ToString();
      xmlResult.ContentType = "text/xml";
      return xmlResult;
  }
}
[/sourcecode]

こんな感じでいけるかと思っていたんだけど、JSONは思い通りにできたのに、XMLの方が思ったよりも大変だった。というのは、XmlSerializerがDictionaryのたぐいをシリアライズしてくれないから。

で、[PC][C]C#::DictionaryをXMLSerializerでシリアライズしたいんですが？を見つけて、これでDictionaryをXMLシリアライズしようと思ったんだけど、これでシリアライズすると、

[sourcecode language="xml"] keyname value [/sourcecode]

みたいな感じのXMLとしてシリアライズされる。JSON相当に読みやすい表現の

[sourcecode language="xml"] value [/sourcecode]

になってくれないかなー。というわけで試しに作ってみた。

[sourcecode language="c#"]
    public class SerializableDictionary : Dictionary, IXmlSerializable
    {
        public System.Xml.Schema.XmlSchema GetSchema()
        {
            return null;
        }


    public void ReadXml(System.Xml.XmlReader reader)
    {
        string key = null;
        object value = null;
        while (reader.Read())
        {
            switch (reader.NodeType)
            {

                case System.Xml.XmlNodeType.Element:
                    key = reader.Name;
                    break;
                case System.Xml.XmlNodeType.Text:
                    value = reader.Value;
                    break;
                case System.Xml.XmlNodeType.EndElement:
                    if (!string.IsNullOrEmpty(key))
                    {
                        this[key] = value;
                    }
                    else
                    {
                        reader.Read();
                        return;
                    }
                    key = null;
                    value = null;
                    break;
            }
        }
    }

    public void WriteXml(System.Xml.XmlWriter writer)
    {
        foreach (var key in Keys)
        {
            writer.WriteStartElement(key.ToString());
            writer.WriteString(this[key].ToString());
            writer.WriteEndElement();
        }
    }
}


[/sourcecode]

汎用Dictionary<Tkey, Tvalue>の場合の扱い方がよくわからなかったんで、Dictionary<string, object>に限定。あと、valueがさらに階層化されている場合の処理の書き方もわからなかったんで、一次元のDictionaryにしか対応しない。あとNode名としての妥当性チェックとかもしていない。といろいろ課題はあるけど、動く範囲では動く。

これで、最初に書いたようにDictionaryを含むResultオブジェクトを生成しておいて、それをXMLなりJSONなりで出力するようなAPIコードが簡単に書けるようになった。

ロンドンハーツ 2011/11/8

男の自分番付。もう飽きてきたな。

アメトーーク 2011/11/10

有吉のプレゼン企画。芸人の新ルールを考えよう‼

楽屋への挨拶。本番前の打ち合わせ。番組の強引なアンケート。大御所や俳優とのカラミ。評価表。却下。ロケ始まりの少し歩き。タクシーの見送り。全体として、さま～ずの立ち位置。

ブラマヨとゆかいな仲間たち　アツアツっ！ 2011/11/12

原口あきまさ。ものまね芸人の扱い。似ているより面白い。デフォルメはやり尽くされた。モノマネする勇気。

西澤保彦 殺す

「猟死の果て」の改題版だった。やられた。作者の新刊アラートしかけて買っているとこういうのにときどき引っかかる。乙一の平面犬とか。内容は、西澤保彦にしてはいまいち。

ハロルド作石 7人のシェイクスピア 5

メインの男の子供の頃の話。そして宗教。ひたすら不幸でフラストレーションがたまる話。

井上雄彦 REAL 11

野宮のトライアウトチャレンジ。十分健闘したが、これでなんとか合格してチームを変えていく話になるというのは、現状だと厳しそうだよなー。

JUNK 伊集院光 深夜の馬鹿力 2011/11/15

新幹線の空いているグリーン席で見知らぬおっさんと隣同士。なにゆえ？

奥さんと結婚記念旅行でお伊勢参り。お互い体調不良で意地の張り合い。ここのトークはまるでたけしみたいだったな。「…なんて言っちゃったりして」の連発。

最近BUMPっぽいバンドがすごい増えたな。BUMPは昔のBOOWYみたいな扱いになってるのか？

繁忙期以外の平日は、ぎりぎりになると格安のいい宿がネット予約に出てくるから、当日予約がお得らしい。知らなかった。今度試してみよう。

伊勢うどん。ふにゃふにゃの腰のないうどん。

ソニーのヘッドマウントディスプレイ。深海と宇宙とエロ。3D潮吹き。思わずよける。誰もいない部屋でHMDでエロビデオを観ているときにケーブルが膝に当たる。「誰かいる！」

自慰メン。賢者モードになったときの伊集院のテーマ曲。鈴木ヒロミツ「でも、何かが違う」。「また、つまらぬものを斬ってしまった…」

ATPファイナル（最終戦）の組み合わせが発表された。

• グループA
• ジョコビッチ
• マレー
• フェレール
• ベルディヒ
• グループB
• ナダル
• フェデラー
• ツォンガ
• フィッシュ

グループAは、ジョコビッチの肩がどのくらい治っているか。8割くらい戻っていれば、マレー以外には通じそうだけど、フェレールなんかは多少振り回してもミスせずついてくるだろうし、そうすると消耗戦になってしまって、ラウンドロビンを戦い抜くだけで、すり切れてしまいそうだ。

マレーはラウンドロビン抜けは問題ないだろう。ジョコビッチが力尽きた場合は、フェレールよりはベルディヒかなー。

グループBは、珍しくナダルとフェデラーが同じ組になった。というか、これはインドアハードでのナダル包囲網って感じの面子だな。といっても最終戦のメンバーの中で、このコートでナダルの方が分が良さそうな相手はフェレールくらいだし、単に最終戦の面子とコートの組み合わせがナダルに厳しいってだけか。

フェデラーは余裕の一抜けだろうなー。フェデラーとナダルが何試合目に当たるんだろう。早めに当たるとフェデラー有利、後で当たるとナダルもそれなりに戦えるようになってきそう。

それでもこのグループはナダルよりもツォンガの方が抜けて来そうだ。フィッシュは怪我の具合はどうだろう。この面子だと、万全の体調でも一勝するのもきつそうだが。

一応ラウンドロビンの結果を予想してみる。

グループA

	ジョコビッチ	マレー	フェレール	ベルディヒ
ジョコビッチ		1-2	2-1	2-0	2勝1敗(2位)
マレー	2-1		2-0	2-0	3勝0敗(1位)
フェレール	1-2	0-2		1-2	0勝3敗
ベルディヒ	0-2	0-2	2-1		1勝2敗

グループB

	ナダル	フェデラー	ツォンガ	フィッシュ
ナダル		0-2	1-2	2-1	1勝2敗
フェデラー	2-0		2-1	2-0	3勝0敗(1位)
ツォンガ	2-1	1-2		1-2	1勝2敗(2位)
フィッシュ	1-2	0-2	2-1		1勝2敗

休養十分のナダルでも、この面子とこのコートではあまりいい結果が出ないと予想。ジョコビッチに関しては今シーズンこれだけ活躍したんだから、最終戦ではこのくらいの結果は残して欲しいという願望が多く入っている。実際にはラウンドロビンの途中でキャンセルしてもおかしくないと思っている。決勝はフェデラー vs. マレーかな。

Facebookの恥汚染、数千の架空IDは、どうもあの国の仕業らしいの証拠 | More Access,More Fun!

友達数が500人以上と、「会ってない人と友達になっているのが明らかな、脇が甘い人」を狙って友人申請 複数の同一企業のOBと友人になった上で、同じ企業に勤務している人に友人申請 実在してそうな企業名にする

SNSを使ったソーシャルハッキングの第一歩って感じか。俺はFacebookとか知り合いじゃない人はフレンド申請されても無視してるなー。知り合いの知り合いとか、同じ出身地とか学校とか言われても、それは友達じゃないよ。誰でもいいから知り合い増やしたいとかも思ってないし。

cocos2dで簡単なゲーム作っていくよ（まとめ・サンプルコードあり） | リンゴにかじられたブログ

cocos2d for iphoneで簡単なゲームを作っていく。完成済み＆ソースコードはgithubで公開。

Twitter（別名デマッター）でネットジャーナリストを釣る方法（フリージャーナリスト） - 愛・蔵太のもう少し調べて書きたい日記

相変わらずお元気ですね。そしてそのコメント欄に感情的に書き込んじゃう人たち……。

 

今日は予報が外れて強風。風速3〜4m/hが常時吹き続けている感じ。しかも寒い。ただし天気はいいのが少しは救い。

昨日に続き今日もいまいち集中できず。せめて風への対応能力を少しでも向上しようと意識してみる。

逆風側は、できるだけ食い込まれない様に、玉が浅くならないように意識してみるが、コントロールがいまいち。深くを意識しすぎてバックアウトが増えてしまったり。その割にはショートクロスやドロップショットのクオリティも低い。

一方の追い風側は、最初力加減でコントロールしていたらつまらないミスが増えたんで、しっかり低い軌道で叩くようしたら安定した。ただし、相手の球が高く弾まない時限定。高い打点で打たされると、とたんに不安定になる。追い風サイドの高い打点の処理は今後の課題。

サーブに関しては、風でトスが流されるのを計算にいれつつトスをあげ、さらにトスが流された場合は、しっかり最後まで微調整しながら打つ、というのを意識していたんだけど、その辺りに集中するとコースとか確率とかがおろそかになるな。あと、向かい風側よりも追い風側の方が、風に流された時の対応が難しい。

全体としては今日の練習も不完全燃焼気味。ただ、そろそろ寒くなって来て練習もちゃんとできる日が少なくなるから、今のうちにちゃんとやっておかないと。

この前、ASP.NET MVC 3でファイルダウンロードする方法として、ネイティブなResponseオブジェクト処理をすればちゃんとできたという話を書いたけど、もっと圧倒的に簡単な方法があった。

普通のコントローラのアクションメソッドの戻り値では、ViewResultを返してViewでのレンダリング結果を返しているけれども、第3回　ActionResultオブジェクトでアクション操作も自由自在 － ＠ITにあるとおり、ActionResultにはFilePathResultなんていう、ファイルの内容をそのまま返すActionResultも用意されていた。ってことで、

[sourcecode language="c#"]
string filename = ""; //ダウンロードしたいファイルパス
string downloadname = ""; //  ダウンロードの際に指定したいファイル名
var result = new FilePathResult(filename, "application/octet-stream"); // content-typeは適当にどうぞ
result.FileDownloadName = downloadname;
return result;
[/sourcecode]

なんてアクションメソッド内で書けば、ファイルダウンロード処理が行われる。FileDownloadNameを指定するとContent-Dispositionヘッダがつく。

ASP.NET MVC 3はVisual Studio 2010で自動的にヘルプドキュメント検索が効かないから、こういう便利な機能があちこちに隠れていそうだな。でも、フレームワークのドキュメントを全部読むのはきついからなー。ぼちぼち隙間で読もう。

モバイル・デバイスに革命か―リチム・イオン電池の容量が10倍、充電時間が10分の1になる？

1、2年で実用化してくれないかな。

TPPで著作権侵害が非親告罪化されたら～同人誌・コスプレを守る方法とは -INTERNET Watch

TPPがどうなるにしろ、二次創作関連はそろそろ本格的に法的にグレーな状況から脱却する方法を考える必要がありそう。

サバクラ両方で動く JavaScript の大規模開発を行うために — Gist

JavaScript on サーバー＋クライアント 時代のWebアプリケーション実装のためのMVCおよび派生デザインパターンの実例付き紹介。そして、新しいResource-View-Presenterパターンの紹介。

ユーザー操作をViewで受け取るのではなくてコントローラー（とその前段のディスパッチャー）で受け取るパターンは、MVCじゃなくてModel2（MVC）というのか。

MVPとMVVMとの違いは、Modelでのイベント（情報変更）がViewModelを通してViewまで連動するところか。MVPだとPresentor上のロジックで明示的にViewをアップデートする必要があるのね。で、MVPおよびMVVMならば、PもしくはVMが、MとVとの結び付けを処理するんで、Vがサーバーサイドの場合でもクライアントの場合でも、ここで処理して両用に書くことができそう、と。

Backbone.jsの場合。DOMからの操作はViewが直接Modelを操作するのか。Modelの変更はイベントとしてViewが直接受け取って、その結果を反映させることができるのね。URL変化の場合は、ControllerがViewとModelを用意し、ModelにURLから受け取った変化を渡すと、その内容が自動的にViewに反映される、と。

Batman.jsの場合。ModelとViewを結びつけるデータバインディングエンジンをフレームワーク側が持っているので、Modelへの操作はバインディングエンジン経由でViewに反映される。Controller（ViewModel）から直接Viewを操作せず、Modelがデータバインディングエンジン経由でViewと結びつけられてしまうのか。なんかすごく用途が限定されそうだな。

リアルタイム対応するためには、ModelとViewがリアルタイムで結びつけられる必要があるので、Model2型だとうまくいかない。

どちらにしろ、今まで紹介したパターンは、クライアント・サーバー両対応で書くのは難しい。そこでResource-View-Presenter。この説明だといまいちどうなってるのかわからない。クライアントサイドではMVPっぽく動作し、サーバーサイドではModel2 MVCっぽく動作していて、でもPresenterとResourceが永続しているから、サーバーサイドでもリアルタイムに対応できるよ、って感じ？

どうもドキュメントを読むだけだと、いろいろと腑に落ちない感じだ。これはそれぞれのフレームワークで実際にサンプルを作るか動かすかしてみないと、納得できないだろうな。

岩上安身氏「デマといったね。デマだと立証してもらおうか」「えっ？」 - Togetter

その子供の先天性の異常が放射能に関係ないと、なぜ今の段階で断言できるのか、医者なら根拠を示してもらおう。

無脳症の件、デマといったね。デマだと立証してもらおうか。私はあの後も取材を続けている。

「可能性はゼロではないからあり得ると言ったが、今のところ具体的な根拠はない。それをデマだというならデマだと言う方が、可能性がゼロであると証明して見せろ」か。「事実がはっきりしないことを言う＝間違っているとも言い切れない＝デマ（虚偽）ではない」ということなんだろうな。デマという言葉を使わずに、「根拠がない憶測の段階で言うな」ならOKかな。

Chromeの「シークレットウィンドウ」はWeb開発にとても使える | Stocker.jp / diary

CTRL+SHIFT+Nで履歴やCookieを共有しないウィンドウを開くことができる。

昨日レーシック受けました - 歩きつづける　ゆり　咲きつづける

ひとまず初日はポジティブな感想の模様。今後に注目。

今日は朝練に出かけようと車に乗ったら、バッテリーが上がっていた。土日に出かけた時にシートアレンジを変更していて、帰ってから元に戻す作業をしたあとに室内灯を消し忘れていた。

しょうがないんで、半年くらい放置していた自転車のタイヤに空気をいれて、慌てて自転車で出発。自転車はちょっとギアチェンジが渋いくらいで、何とか普通に動いてくれた。

と、出だしからばたばたしたせいで、練習にはあまり集中できず。頭をろくに使わずに過ごしてしまった。筋肉疲労がない状態だったんで、プレイの内容的にはそれなりだったけど、中身の薄い練習だった。

車のバッテリーは外してチャージャー(昔バッテリーが弱い車に乗っていたんで、家庭用電源から12Vを充電するチャージャーを持っている)につないで来たから、夜までには充電されているだろう。明日からは平常営業に戻ってちゃんとやろう。

MySQL :: MySQL 5.5 Reference Manual :: 21.2.4.2 Tutorial: MySQL Connector/Net ASP.NET Membership and Role Providerが、関連ドキュメント。

ただし、machine.configを云々って説明がよくわからん。web.configのほかにmachine.configを用意して、そっちにMySqlMembershipProviderがらみの設定を書けってこと？　なんでweb.configじゃだめなんだ？　設定ファイルを分散させたくないんで、web.configで完結させる方向で試してみる。

まず上記ドキュメントを見ながら、configuration/system.web/membership/providers以下にデフォルトで書かれている、AspNetSqlMembershipProviderキーの内容を以下に変更。

ドキュメントのようにMySqlMembershipProviderというキーで定義しても、デフォルトのAspNetSqlMembershipProviderの方が参照されてしまうので、AspNetSqlMembershipProviderを書き換える方法を選んだ。

たぶんどこかで（machine.config？）デフォルト参照先のプロバイダー名を変更できるんだろうけど、RoleProviderとかTokenRoleProviderとかとの参照関係とかの内容がよくわからないので、追求するのはあきらめた。

[sourcecode language="xml"]

[/sourcecode]

ドキュメント上のサンプルではMySqlMembershipProviderのバージョンがずいぶん古い記述だったので、インストールされているバージョンに合わせた。

続いて、DB接続文字列をここで設定したApplicationServicesという名前で追加。

[sourcecode language="xml"]
    
[/sourcecode]

これで試しにASP.NET MVCアプリケーションのデフォルトのアカウント関連ページに接続すると、必要なテーブル（my_aspnet_*）が自動的に登録されているのが確認できる。

あと、ロール関連のプロバイダーもMySQLのものに変更。

[sourcecode language="xml"]
        
[/sourcecode]

typeで細かいバージョン名まで指定しないと読み込んでくれなかった。

これでASP.NET Webサイト管理ツールを起動したら、ユーザー登録情報の変更やロールの追加などが一通り動くようになった。

続いて、パスワード変更機能を有効化。単にリンクがないだけなんで、Views/Shared/_LogOnPartial.cshtmlのログアウトの後ろに、

[sourcecode language="c#"]
[@Html.ActionLink("パスワード変更", "ChangePassword", "Account")]
[/sourcecode]

を追加。

あと、自由にユーザー登録できるサイトじゃなくしたいんで、AcciontControllerのRegster関連アクションメソッドに[Authorize(Role="superuser")]属性をつけておいて、superuser権限を持つユーザー以外は呼べないようにしておいた。ただ、デフォルトだとユーザー登録したらそのユーザーでログインしてしまうんで、

[sourcecode language="c#"]
FormsAuthentication.SetAuthCookie(model.UserName, false /* createPersistentCookie */);
[/sourcecode]

をコメントアウトして、単なるユーザー登録のみの処理に変更。あとはログイン画面の登録リンクや文言を修正すれば、自由にユーザー登録できないサイトになる。

ちなみにビュー内でユーザー権限チェックなどで条件分岐したい場合は、

[sourcecode language="c#"]
@if (User.IsInRole("superuser")) {
  
superuser向けの表示
}
[/sourcecode]

なんて感じでUser経由でアクセスできる。