グループB フェデラー vs. フィッシュ

ファーストセットを見ていて、さすがにこの組み合わせだとフェデラーの楽勝だよねーと思っていたら、セカンドセットに入ってフェデラーがぐだる。本当に最近はいつ誰が相手でも気が抜けないなー。結局セカンドセットは最後まで復活できないままに落としたが、ファイナルセットではしっかり切り替え、結局フェデラーの勝利。

やっぱりこのコートだとツォンガの攻撃力がナダルのディフェンス力に勝っているな。ただ、この間のフェデラーほど圧倒できないのは、ツォンガのミスが多いからか。ツォンガのバックハンドはわかりやすく弱いからなー。攻撃力はあるけど安定感がなく、ディフェンス力が弱い。

ファーストセットはツォンガの攻撃をかわしきったナダルがタイブレイクまで持ち込むが、タイブレイクはサーブが強いツォンガが取り切って、ツォンガの7-6(2)。セカンドセットは競りながら、いいプレイと言うよりはお互いのミスがキーポイントとなって、ナダルが6-4で取り返す。ファイナルセットになるとナダルのミスがだいぶ増えてきた。ツォンガが2ブレイクアップ。しかしツォンガのメンタルの弱さ。サービングフォーザマッチをダブルフォルト2つで落としてしまう。しかしもうナダルのサーブは攻略されてしまっている。ツォンガがリターンを叩きまくり再度ブレイクし直して、6-3で勝利。

• ツォンガ def. ナダル 7-6(2) 4-6 6-3

これでグループBは、フェデラー1位、ツォンガの2位抜け。

ナダルはしっかり休んで練習してきたけど、ラウンドロビン敗退か。プレイスタイル的にこういう速めのハードコートでトップ選手を相手にしたときにはどうともならないなー。前みたいにフィジカルを、特に膝を痛めつけながら戦えば勝てるだろうけど、それをやるとまた長期欠場の原因になってしまうし。もう一度ナンバー1やハードコートのグランドスラムを狙うのならば、今の制限されたフィジカルの使い方の範囲内で、何か新しい戦術を追加しなければならないだろうけど、いったい何があるだろう。速いサーブは肩に負担がかかりすぎたから、今度はスライスをもっと多用してみるというのはどうだろうか。そこからの超反応を活かしたネットプレイ。ってそんなのナダルじゃねーな。

昨日のダメージが足にきていて、朝起きたら、左の太ももに張りがあり、右の膝が軽く痛んだ。そのため、フットワークで思い切りよく踏ん張れず、手打ちでしか打てない。

さらに今日は予報が外れて、4〜5m/h程度の強い風。逆風側だと風に逆らって打つのが非常にきつい状態。

ということで、今日の練習は軽めに流した。ときどき強打してみるが、やはり足の踏ん張りが足りないと、しょうもないミスがいつもにまして増える。

昨日の試合から得た課題がいくつかあったんだけど、全然トライできなかったんで、今後のためにまとめておこう。

• 浅いチャンスボールを無理せずコースや球種で決める練習をする。特にすべてスピンの強打にするのではなく、角度をつけたスライスやドロップショットなどの選択肢も考慮する
• 強打してこない相手に対して、無理やりネットに出て決める練習をする。単に前に出るだけじゃなく、しっかり決めにいくボレーが大事。ただし、速いボレーに限らず、深さや角度などで決めることも考慮する
• ポイントリードしたところで気を抜かない。先行されたり追いつかれたあとはいいプレイができるんだけど、先行している時に気の抜けたプレイをしてしまうことが多い。すべてのポイントでしっかりファイトできるようにする
• 強打が決まらずに何度も返されてしまう時の対応方法を考える。昨日は4、5回返されてしまうと、息切れしてきて一気にクオリティが落ちるか、無理な球を打って自滅してしまった。決まらなかった場合にどういうオプションがあるのかについて、自分で把握してグダグダしないようにする。あるいは息切れしないようなフィジカルトレーニングするべきか…

昨日は体調的な問題もあったんで、いまいちすっきりしないチャレンジになってしまった。次の月一定期チャレンジの前に、有給をとってイレギュラーチャレンジを追加したいところ。ぐだぐだと遅れていた仕事の方もようやくめどがついてきたところだし、来週あたりに何とか調整してチャレンジしたい。

Entity SQLで取ってきたデータに対して、まずCount()で全件数を取得してから、ページング用の実データをSkip、Takeするような処理を書き、それをforeachで回そうとすると、「クエリの結果を複数回列挙することはできません。」エラーが出る。

擬似コードで言うところの、

[sourcecode language="c#"]
var db = new dbEntity();
var sql = "select * from table order by id";
var parameters = new List();
var result = db.ExecuteStoredQuery(sql, parameters);
int count = result.Count();
int page = 1;
int pagesize = 20;
int pagecount = (int)(count / pagesize) + 1;
foreach (var row in result.Skip( pagesize * (page - 1)).Take(pagesize))
{
  // ...
}
[/sourcecode]

なんて感じの処理。

必ず出るわけでなく、出たり出なかったりするのだが、どうやらその条件は「パラメタライズされたクエリーかどうか」らしい。上記みたいにparametersが空の場合は問題なく動く。動的にwhere条件を組み立てたりして、parametersにその条件値を入れていたりすると、foreachのところで「クエリの結果を複数回列挙することはできません。」が出る。

LINQ to SQLの仕組み（ほぼEntity SQLと同じ仕様だと思われる）がよくわかっていないんで、内部的にどのタイミングでどういうSQL文が発行されているのかがわからないんだけど、LINQ to SQLのドキュメントを斜め読みした限りでは、実際のSQL文の発行はできるだけ遅延実行するようになっているらしいから、Count()とかTake()とかforeachでEnumerableにしたタイミングで、実際にSQL文を発行しているのかな？

で、Count()とかで一度SQL文を実行して、パラメータ埋め込みを実行してしまったあとに、もう一度SQL文を発行しなければならない処理を呼び出すと、「クエリの結果を複数回列挙することはできません。」エラーが出ている？　どうもすっきりしないけど、たぶんそんな感じのことが起こっているのではないかと推測。

ともかく、内部で何が起こっているのかよくわからないEntity SQLの機能を使うのはやめて、SQL文を組み立てるときに件数取得SQLと実体取得SQLの二つを生成しておいて、それぞれ呼ぶようにして回避。擬似コードで言うと、

[sourcecode language="c#"]
var countSql = "select count(*) as cnt from table";
var selectSql = "select * from table";
var parameters = new List();
var count = db.ExecuteStoredQuery(countSql, parameters).First();
var result = db.ExecuteStoredQuery(selectSql, parameters).Skip(offset).Take(limit);
[/sourcecode]

みたいな感じね。countみたいなデータを、モデルクラス以外の型でどうやって受け取ればいいのかには、しばらく悩んだけど、こんな感じでintで受けるといけるようだ。

昨日書いた「Entity SQLでtritonnの全文検索を行う « blog.ishinao.net」の話の続き。ローカル開発環境でだいたい動くようになったんで、サーバー環境でもちゃんと動くか試してみようと、サーバーに作りかけのアプリをセットアップしてみた。

ローカル開発環境のMySQL Connector Netのバージョンは6.4.3だったんだけど、MySQLのWebサイトに載っている最新版は6.4.4になっていて、まあマイナーバージョンの最後の一桁が1違うくらいならば、大して問題は出ないだろうとサーバーサイドは6.4.4をインストール。

で、動かしてみたらローカル開発環境では問題なかったのに、「MySqlParameter以外は受け取らないよ」エラーが、ExecuteStoreQueryの第2引数で出る。MySqlParameterをちゃんと渡しているんだけどなーと不思議に思い、明示的にキャストしてみたり、MySqlParameter[]な変数を定義してそれにコピーしてから渡してみたり、いろいろ試してみたけれども動かない。

おかしいなーと、試しにローカル開発環境のMySQL Connector Netも6.4.4にアップデートしてみたら、同じエラーが出るようになった。なんじゃそりゃ。6.4.3と6.4.4の間でそんな非互換性があるの？　あるいはバグ？

よくわからんが、そこを追求する気にはなれなかったんで、サーバーも開発環境も6.4.3に合わせたら、どちらでもちゃんと動くようになった。MySQL Connector Netを使うときにはバージョンに要注意。

グループA ベルディヒ vs. ティプサレビッチ

キャンセルしたマレーに変わって出場のティプサレビッチと、初戦ジョコビッチに競り負けたベルディヒの戦い。

ティプサレビッチのあまり無理しない範囲でコースで攻撃するスタイルに、それを上回ろうとちょっとずつ無理をするベルディヒ。各ショットのクオリティはベルディヒの方が上なのに、試合でのクオリティコントロールのうまさと安定感で、ティプサレビッチがベルディヒを上回っている。そしてファーストセットは、あっという間にティプサレビッチの5-1に。そこからベルディヒも少し抵抗するが、ティプサレビッチがしっかりレベルを上げてファーストセットは6-2でティプサレビッチ。

セカンドセットはキープキープの展開が続くが、ベルディヒが先にブレイクして5-3とリード。そのままサービングフォーザセットを取ってベルディヒの6-3。

ファイナルセットは競り合いながらキープキープの展開で、タイブレイクに。タイブレイクもキープキープできたが、ティプサレビッチの勝負した球がわずかにアウトして、ベルディヒがミニブレイクを先行。しかしすぐにティプサレビッチが取り返し、さらにもう一つミニブレイクして、ティプサレビッチのマッチポイントでのサーブ。いいアプローチからのボレーをわずかにアウトして、再びタイに。続いてのサーブはティプサレビッチがダブルフォルト。今度はベルディヒのマッチポイントでのサーブ。最後はティプサレビッチが逆をつかれて足をひねって転び、そのままベルディヒの勝利。

ティプサレビッチは最後のポイントでかなり強く足首をひねったようで、試合終了後びっこを引きながら荷物も持たずに会場を後にした。次の試合大丈夫か？

• ベルディヒ def. ティプサレビッチ 2-6 6-3 7-6(6)

グループA ジョコビッチ vs. フェレール

ジョコビッチのサービスゲームから試合開始。ジョコビッチはミスは出ているが、サーブもストロークでの攻撃もクオリティが高い。が、振り回されもしっかりついていきミスをしないフェレール。ジョコビッチが攻撃し、フェレールがディフェンスしながらじわじわと反撃するという展開。ジョコビッチは何とかフェレールを振り切ってキープ。

フェレールのサービスゲームは、ジョコビッチが強気に攻めた球をミスし、フェレールが簡単にキープ。

ジョコビッチ、早くも2本目のダブルフォルト。フェレールのフォアハンド側に多めに配球し始めている？　フェレールはバックハンドの安定感が高いから、フォアハンドでたくさん打たせたいのかな？　少々苦しみつつもジョコビッチは何とかキープ。

ここまでは、ジョコビッチのミスが多く、攻撃している割には苦しい展開になりがち。フェレールは安定したプレイで、ジョコビッチの攻撃をかわしている。

フェレールのサービスゲーム。ジョコビッチの攻撃のクオリティが上がっていき、フェレールを追い込み始めるが、ジョコビッチの攻撃がわずかにアウトとなることが多く、フェレールも何とか対抗し、キープして2-2。

続いてのジョコビッチのサービスゲームは、フェレールのミスが連続して、ジョコビッチはあっさりキープ。

フェレールのサービスゲーム。ジョコビッチをしっかり振り回して、最後は前に出てボレーでポイントを決める、フェレールのいいプレイ。フェレールもちょっと乗ってきたか。フェレールはラブゲームでキープ。

ジョコビッチのサーブゲーム。フェレールが早い段階でコースを変えてくるようになり、フェレールが先に攻撃することが増えてきた。流れがフェレールに傾きつつある。ブレイクポイント2つ。一発でフェレールが決めて、フェレールの4-3。

フェレールのサービスゲーム。ジョコビッチが反撃しようと試みするがミスが減らせない。今年のジョコビッチならばここですぐにブレイクバックして来たのだが、それができないジョコビッチ、させないフェレール。フェレールの5-3。

まだフェレールの流れが続いている中でのジョコビッチのサービスゲーム。このゲームをキープしつつ、フェレールの流れを止めたいジョコビッチ。しかし自分からのミスを止められない。もう一度ブレイクされてファーストセットはフェレールの6-3。

ミスを減らせないジョコビッチは、序盤は安全なプレイをしてきたフェレールに何とか対抗できていたが、途中から調子を上げてきたフェレール相手には、ほぼ自滅するようにポイントを失い続けている。ジョコビッチはミスを減らさないとどうにもならない。

セカンドセット、フェレールのサービスゲームから。ジョコビッチは強打を減らしつつ、コントロールショットでコートを広く使いフェレールを走らせるが、フェレールはしっかり対応。コントロールショットでもジョコビッチのミスが先に出てしまう。少しずつ粘り強いプレイが出てきたジョコビッチだが、フェレールがキープ。

ジョコビッチのサービスゲーム。またミスが連続して出るジョコビッチ。ダブルのブレイクポイントを握られるが、サーブ2本で何とか逃れる。しかしロングラリーを自分のミスで失い再びブレイクポイント。厳しい角度を狙えず、安全に真ん中に返した球をフェレールに叩かれて、フェレールがブレイク。

フェレールのサービスゲーム。開き直ったかジョコビッチがまた強打を使い始めた。しかし、ことごとくフェレールに対応されて、結局最後はジョコビッチのミスで終わる。ミスが出ても強く打つことをやめないジョコビッチ。コントロールショットでは勝ち目がないから、無理矢理でも強打を打っているうちに調子が上がってくることに賭けたか。しかしミスが減らせないままにフェレールがあっさりキープ。

ジョコビッチのサービスゲーム。いいサーブを入れてようやくキープ。ただし、サービス前の玉突きを始めるときの動作に何か違和感があるようだ。サーブへの入り方を何度か躊躇する。

フェレールのサービスゲーム。調子の良さを持続。いいサーブから、返ってきた甘い球を一発で決めるストローク。そしてサービスエース。

ジョコビッチのサービスゲームは、相変わらず苦しい。デュースを挟んでの競り合いは、結局ジョコビッチのストロークミスでブレイクされる。フェレールの5-1。

フェレールのサービングフォーザマッチ。結局ジョコビッチは最後まで自滅を繰り返し、フェレールの圧勝。

• フェレール def. ジョコビッチ 6-3 6-1

これでフェレールはラウンドロビン勝ち抜け確定。ジョコビッチの勝ち抜け条件はなんだっけ。Tennis - ATP World Tour - Final Standingsに条件が書いてあった。

• ジョコビッチ、フェレールが勝てば、フェレール1位、ジョコビッチ2位抜け
• ティプサレビッチ、フェレールが勝てば、フェレール1位、ジョコビッチ2位抜け
• ティプサレビッチ、ベルディヒが勝てば、ベルディヒ1位、フェレール2位抜け
• ジョコビッチ、ベルディヒがともにストレートで勝てば、フェレール1位、ベルディヒ2位抜け
• ジョコビッチがストレート勝ち、ベルディヒがフルセット勝ちだと、フェレール1位、ジョコビッチ2位抜け
• ジョコビッチがフルセット勝ち、ベルディヒがストレート勝ちだと、フェレール1位、ベルディヒ2位抜け
• ジョコビッチ、ベルディヒがともにフルセット勝ちだと、フェレール1位、ベルディヒ2位抜け

ベルディヒは勝てばたいていの場合は自力で勝ち抜けられる。唯一、ジョコビッチがストレートで勝って、ベルディヒがフルセットで勝った場合のみ、ベルディヒが勝っても抜けられないパターンがある。

ジョコビッチはただ勝つだけじゃラウンドロビンを抜けられない。フェレールが勝った場合は、基本的にジョコビッチが勝ち抜け。唯一ベルディヒが勝ってもジョコビッチが抜けられるのが、さっき書いたパターン。

ただなんにしろ、このジョコビッチのコンディションだと、決勝トーナメントに残ったところで、あまりいい結果が出る気はしないなー。何でこんなにエラーを減らせないんだろう。現在の調子だとフェデラーの圧勝っぽい？　せめてグループBはナダルも勝ち残って、決勝でもう一度ナダル vs. フェデラーになってくれないかなー。

今、話題の離婚式に行って来た！：日経ウーマンオンライン【気になる商品・サービス何でも試し隊！】

「こういうコント、昔のごっつええ感じであったよね」とか言ったら、空脳で捏造記憶を思い出す人がいそうだ。

新東名は法定速度１４０キロ…静岡県が要望素案 : 社会 : YOMIURI ONLINE（読売新聞）

国内では100km/hより上の法定速度ってまだないよね？　特に道交法的な制限はないんだっけ？

PHPでこんな情報が表示されるって知ってますか？ - カイワレの大冒険

うわ、なんじゃこりゃ。

日本のテレビがカットしたブータン国王の演説 - フランシスコの大麻解放日記

右翼脳なの？　「日本のテレビがカットしたブータン国王の演説 - フランシスコの大麻解放日記」の一部（ネットウヨク） - 愛・蔵太のもう少し調べて書きたい日記

「過去にはアジアの国々を植民地状態から解放し」てではなく「当時開発途上地域であったアジアに自信とその進むべき道への自覚をもたらし」「日本の後に続 いて世界経済の最前線に躍り出た数多くの国々に希望を与えて」きた。日本は「技術と革新の力、勤勉さと責任感、強固な伝統的価値観における模範」である。

グリー株式会社 | ニュースリリース | プレスリリース 2011年 | 訴訟の提起に関するお知らせ

DeNAは、昨年12月、上記違法行為を取りやめる方針を示しながら、その一方で、それ以後もMobageでゲームを提供しているソーシャルゲーム提供事業者がGREEでもゲームを提供しようとすると、これを妨害していると思われること

ここが一番重要なんじゃないかと思うんだけど、ここは「妨害していること」ではなく「妨害していると思われること」なの？　なんか「特に証拠はないけど」って言っているように見えるんだけど。

ＪＲ東海のＩＲ「リニア新幹線中間駅の建設費負担について」を要約するとこうなる : 市況かぶ全力２階建

お前ら『地元に１つは駅が欲しい』つったから、俺が『じゃあ半分くらい建築費負担してくれ』って頼んでも断ったよな。もういいよ。全部俺が持つから。でももうお前らのわがまま聞いてらんねーし、サッサと必要最小限の施設だけ作るから。最後にもいっかい言うけど、中間駅の建設費負担は、俺にとってはマジでホントに大変だけどもうお前らが何グチャグチャ言っても、もう聞いてられねーんで、場合によっては無人駅の駅前トイレみたいなチャチな駅になるかもしれないけど、納期には絶対仕上げるんで。

Titaniumでリジェクト・iCloud関連 | Selfkleptomaniac

基本的にはTitaniumの問題と言うよりは、iCloud対応によりiPhoneアプリがローカルストレージを使う場合の用途ごとのディレクトリの使い分けを厳密にチェックされるようになったという話。で、Titaniumのデフォルトではsqlite DBの保存パスが違反になってしまうので、それを回避する方法。

Microsoft、KinectにWindows向け専用デバイスを準備中―50cmで作動する近接モードをサポート

大きな改良点には近接モード（Near Mode）のサポートがある。これはセンサーから50cmの距離にある対象を3Dで同定、認識できる機能で、KinectをデスクトップPCで利用するためにこれまでにも強く要望されていた機能だ

PCのインターフェース革命を起こせるか。スティーブ・ジョブスとかにKinectを使ったUIを考えて欲しかったな。

まったり麻雀関係 - Togetter

まったり麻雀

そういや最近麻雀やってないな。強いらしいから試しにやってみよう。

4Gamer.net ― 【西川善司】AV誌に載らないCEATECネタ。遅延1フレーム未満のスキャンコンバータと，携帯電話でDirectX 11級グラフィックスのゲームを遊ぶ方法

様々なアナログ入力端子に対応し、ワーストケースでも1フレーム未満の遅延で済むというHDMIアップスキャンコンバータ、マイコンソフトのフレームマイスター。1台確保しておくと便利そうだな。いくらだろう。3万円台前半くらい？　それにしてもマイコンソフト、まだこういう製品開発してたんだ。

今日はインスピ中級シングルスの予約を入れていた日なんだけど、3、4日前に寝違えて痛めた背筋がまだ治っていない。可動範囲はだいぶ広がっているんだけど、限界を超えると激痛が走る。その限界は肩を回す角度によって変わるので、手加減の仕方が難しい。それでもドタキャンするのもなんだろうということで、できる範囲でやろうと参加。

1試合目 2-6

まだどのくらい体が動かせるかわからないので、おそるおそる試合を開始。体が温まる前に3ゲーム連取されるが、その後体が温まってきたら痛みを感じずにフルスイングできるようになった。しかしまだ思い切りよく振れていないのか、コードに引っかかるネットが多い。後半はだいぶ競るゲームも増えてきたんだけど、ミスの数を減らせずにそのまま終了。

2試合目 4-6

今回は序盤からフルスイングできて、押し込む展開が多かったので、勝ち目はありそうに思えた。が、押し込んでサービスラインくらいに浅く返ってきたチャンスボールをことごとくミスする。しょうがないのでペースを落としてコントロールで振り回していこうとしたら、角度をつけたボールの処理は相手の方が上手で、ドロップショットやアングルショットで切り返される。いろいろ試してみたんだけど、結局自分のミスが減らせないままに、苦し紛れの球を打ち始めて、そのまま終了。

3試合目 6-5

リーグ戦の三位同士の対戦。相手はサーブの確率は悪いが入った時には威力があり、ネットダッシュを頻繁にしかけてくるタイプ。だいぶ振れるようになっていたんで、しっかり振れた時のパッシングショットは悪くないのだけど、プレッシャーがかかるとコースに持っていけず、決められてしまう。中盤から有利な展開だったのだがサービングフォーザマッチを追いつかれ、5-5 40-40の相手のサーブでのマッチポイント（6ゲーム先取ノーアドのルール）で、ネットに出た相手を抜ききれず、届かないコースにボレーを打たれたのだが、ジャストワンボールアウトだったのでぎりぎり勝った。けどこれはほぼ負け試合だな。相手の方が最後まで攻めてのミスだから、内容は相手の方が上だ。

結局背筋痛は、動いている間は痛まないことがわかった。間が空くと痛み出すんで、テニスをやるならぶっ続けでやらないとだめそう。どうせ普段の練習もほとんど休みを取らずにやっているから、これなら練習は普段通りにできそうだ。

グループB ツォンガ vs. フィッシュ

この二人はタイプが似ているなー。ビッグサーブを持っていて、ネットプレイでのタッチがいい。ベースラインからのリスキーなビッグショットもある。けど、ツォンガは最近あまりネットに出ないな。最初にブレイクした2008年全豪ではドロップボレーを使いまくっていた印象があるんだけど。

ファーストセットは出だしにちょっとぐだり気味のブレイク合戦をしつつも、後半は競った展開。タイブレイクはツォンガが一気に突き放して7-6(4)で取る。セカンドセットも最初からブレイク合戦。しかしフィッシュはそこから集中力がきれたのかな？　ちゃんと見ていないうちに6-1と大きく差をつけられていた。

• ツォンガ def. フィッシュ 7-6(4) 6-1

フィッシュは微妙なジャッジにフラストレーションをためたのが敗因か。これでフィッシュのラウンドロビン敗退は決定。

グループB ナダル vs. フェデラー

ファーストセットはフェデラーのサービスゲームから。ダブルフォルトスタート。硬くなっているのか。しかしその後は強いフォアハンドでナダルからウィナーを連発。ダブルフォルト以外はとても強い立ち上がり。

一方ナダルのサービスゲーム。ナダルのいつものバックハンド攻め。そしていつものようにバックハンドは押し込まれてしまい、無理に強打するとエラーが出てしまうフェデラー。ナダルがキープ。

フェデラーのサービスゲームは順調。強くて確率のいいサーブで崩しつつ、フォアハンドで簡単にポイントを取っていく。ほとんどショートポイントで終わってしまうので、ナダルが反撃する余地がない。フェデラーの攻撃力がナダルのディフェンスを上回っている状態。

ナダルがフェデラーのフォア側にも配球し、逆襲を食らってポイントを失う。が、その後は強いサーブとバックハンド攻めで盤石。バックハンド攻めオンリーだとパターンに慣れられてしまう恐れがあるから、余裕があるポイントではフォアハンド側も見せておくつもりか。

フェデラーのサービスゲームは安定している。強いサービス＋フォアハンドで決めにいくショートポイントが多い。しかし、ナダル相手に無理矢理ネットについてのボレーミスと、バックハンドを強打で切り返そうとしてのミスも出ている。やはりこのパターンは相変わらずナダル相手には不利。

ナダルのサービスゲーム、フェデラーが強いフォアハンドでポイント先行し0-30。さらに回り込みフォアでナダルのバックハンドを厳しく攻撃して0-40。フェデラーもナダルのバックハンドをしつこく攻める。お互いバックハンド攻めを中心。フェデラーはバックハンド高く弾む球を、無理な強打で切り返そうとせず、スライスを使ってでもナダルのバックハンド側につなぐ。ナダルもしつこくフェデラーのバックハンドに返そうとする。バックハンドを我慢しつつフォアハンドで攻めたフェデラーがラブゲームでブレイク。フェデラーの4-2。

フェデラーのサービスゲームはいまだ安定。フォアハンドでの攻撃はさらに厳しいコースを攻めるようになり、フェデラーの5-2。

ナダルのサービスゲーム。フェデラーがナダルのバックハンド中心の攻めを読んで、バックハンドを無理しない範囲でしっかり返し、少しでもチャンスがあればフォアハンドでは強引に攻める。このゲームもフェデラーがポイント先行するが、ようやくナダルのバックハンドの強打が決まり、さらにフェデラーのバックハンドの強打がミスになって、ナダルがキープ。

フェデラーのサービングフォーザセット。フェデラーのサーブ＋フォアハンドでの攻撃が厳しい。ナダルの動きもだいぶ良くなってきて、フォアのランニングショットでのカウンターチャンスができるが、フェデラーのフォアハンドの威力が勝り、サイドアウト。最後まで攻めきったフェデラーがファーストセットを6-3で先取。

強いフェデラーに対して、ナダルはレシーブゲームでチャンスがない。ナダルの強みであるバックハンド攻めも今のところ徹底できていない。サービスゲームではバックハンド攻めを徹底しつつ、フェデラーのサービスゲームでも切り返すワンチャンスを見いだす必要がありそう。

セカンドセットはナダルのサービスから。ナダル、バックハンド攻めをと見せかけてのフォア側へのショートクロスのウィナーと、いい攻撃を見せる。一方フェデラーはナダルのバックハンド攻めセカンドサーブを完全に読んで回り込みフォアのリターンからポイント。フェデラーはナダルのバックハンド攻めを苦にしつつも、それなりに対応して逆襲するパターンもものにしている。ナダルの厳しいバックハンドクロスをフェデラーがフォアハンドのランニングショットでのカウンターを決めて、フェデラーがブレイクスタート。

今日のフェデラーは本当に強い。苦しいランニングショットにミスが少ないし、ディフェンスも攻撃もどちらも安定している。ナダル相手にバックハンド攻めをされても、ディフェンスが安定しているというのは、かなりのクオリティ。ランニングショットのクオリティも上がっているのは、フットワークが復活してきたのか。

続いてのフェデラーのサービスゲームは、今まで通り安定してキープ。

続いてのナダルのサーブゲームも苦しい。ナダルがバックハンド攻めをしようと思っても、フェデラーが無理攻めのミスをしてくれず、逆にナダルに対してもバックハンド攻めをやり返し、お互い我慢の展開から先に攻撃に転じるのはフェデラーの方。そしてフォアハンドを使えるようになったフェデラーがポイントを決める。再びフェデラーがブレイクして3-0。

フェデラーのサービスゲーム。サービスエース2本にフォアハンドウィナーであっさり追い込み、ナダルがあまり難しくないフォアハンドをエラーして、あっさりキープ。ナダルは集中力を失っているな。

続いてのナダルのサービスゲームも、ナダルには苦しい展開。セカンドサーブを回り込んで叩かれたり、調子がいいときならばカウンターに取るようなフォアハンド側へのスライスを仕留め損なったり、さらにはバックハンドリターンでもエースを取られてしまう。ブレイクポイントを握られるが、フェデラーがバックハンドでの強引な攻撃をミスして何とか逃れる。フェデラーはバックハンドを無理に攻撃しない方が強いな。ブレイクポイント1つは逃れたものの、その後もフェデラーの攻撃は止まらず、結局このゲームもブレイクしてフェデラーの5-0。

フェデラーのサービングフォーザマッチ。もうフェデラーの普通のストロークに対しても、ナダルがきちんと対応できなくなってきている。完全に集中力が切れている。フェデラーは強いサービスゲームを持続。フェデラーはあっさりキープしてセカンドセットは6－0。ナダルがベーグルを焼かれた。

• フェデラー def. ナダル 6-3 6-0

Entity FrameworkでMySQL＋tritonnを使って全文検索を使おうとして、無駄に長時間はまってしまったので、その件について。

Entity Frameworkでmatch against相当のSQL文を発行するには、Entity SQLを使ってネイティブSQL文を発行する必要がある。けど、なんかその辺のドキュメントがいまいちまとまっていない。

実際に使用するコマンドは、ExecuteStoreQuery(TElement) メソッド (String, Object[])で、シグニチャは、

public ObjectResult<TElement> ExecuteStoreQuery<TElement>(
    string commandText,
    params Object[] parameters
)

で、第2パラメータがObject[]になっていて、

parameters の値には、DbParameter オブジェクトの配列またはパラメーター値の配列を使用できます。 値だけが提供されている場合は、配列内の値の順序に基づいて DbParameter オブジェクトの配列が作成されます。

なんて書いてある。でも、DbParameterオブジェクトのコンストラクタは、

public abstract class DbParameter : MarshalByRefObject,
    IDbDataParameter, IDataParameter

と、抽象クラスになっているんで、直接生成できない。じゃあいったい何を使えばいいんだよ。

いろいろ探していたら、SqlParameterというのを見つけた。そこで、

var db = new dbContext(); 
string sql = "select * from table where match (field) against(@keyword)";
var parameters = new List<SqlParameter>();
parameters.Add(new SqlParameter("keyword", keyword));
var result = db.ExecuteStoreQuery<Table>(sql, parameters);

なんて感じで書いてみたが、「Parameter '@keyword' must be defined.」となってうまくいかない。 ちゃんとkeywordって名前のパラメータを追加しているのに何でだろう、ということでものすごく悩んだのだが、結局しょうもないミスだった。上の最後の行を、

var result = db.ExecuteStoreQuery<Table>(sql, parameters.ToArray());

とすれば動いた。そういやList<SqlParameter>で宣言していたんだから、Object[]に明示的に変換しなければならないのか。

ExecuteStoredQueryの第2引数が、paramsキーワードがついた可変長引数で宣言されているから、配列以外が渡されたときに自動的に可変長引数扱いになってしまったせいで、パラメータの型違いエラーもでず、単にkeywordが定義されていないとか言われてしまう。おかげで使っているオブジェクトの種類がだめなのかとか、長々悩んでしまった。実際に発行されるSQL文がどうなっているのかも簡単に知る方法が用意されていないから、どのレイヤーでのエラーなのかもわかりにくいし。

で、動かしてみたら今度は、MySqlParameterじゃなきゃだめだというエラーが出た。そうかSqlParameterってMS SQL Server向けのクラスなのか。MSプロダクトだとSQLほにゃららはMS SQLのことを指しているんだけど、字面的には汎用のRDB向けクラスのように見えるからわかりにくい。そこで、SqlParameterの部分をMySql.Data.MySqlClient.MySqlParameterに変える。最終的には、

var db = new dbContext(); 
string sql = "select * from table where match (field) against(@keyword)";
var parameters = new List<MySqlParameter>();
parameters.Add(new MySqlParameter("keyword", keyword));
var result = db.ExecuteStoreQuery<Table>(sql, parameters.ToArray());

とやることで動いた。なんかものすごく解決に時間がかかった。

ちなみに上記は@parameterName形式でSQL文中にパラメータを埋め込みたい場合の話で、{0}、{1}みたいにパラメータインデックス（パラメータ配列の序数）でパラメータを埋め込む場合は、

var db = new dbContext(); 
string sql = "select * from table where match (field) against({0})";
var parameters = new List<object>();
parameters.Add(keyword);
var result = db.ExecuteStoreQuery<Table>(sql, parameters.ToArray());

でいける。なんかもうたったこれだけのことでものすごくはまった。

ちなみにこうやってEntity SQLを使って検索した結果でも、ちゃんとEntity Objectに変換して扱えるんで、各行オブジェクトの機能に関してはADO.NET Entity Frameworkで自動生成されたモデルクラスを拡張する方法 « blog.ishinao.netで拡張したものをそのまま使える。

個の尊重はまず名前の尊重から - 404 id:sotarok Not Found

個人間の話し合いで個人の責任においてアカウントの譲渡手続きを行う（そして、サービス運営側はそれが可能な機能を用意する）ならともかく、サービス運営側が積極的にアカウント譲渡を仲介するってのは、なしだよな。dankogaiというサブドメインに占有権があるとなったら、じゃあほかのアカウントの場合ははどうなんだってなってしまうし。わざと混同されるような活動をそのサブドメイン上で行ったりしたら、民事で法的に訴えれば勝てそうだけど。っつーか、ishinaoは世の中には結構いるんだよなー。技術的に面白そうだったり先進的だったりするサービスは早めに確保するからいいんだけど、どうでもいい一般向けサービスだと結構先に取られてしまう。

今度は読売！悪意のメチャクチャ記事の（週刊 自転車ツーキニスト451） [疋田智の「週刊 自転車ツーキニスト」] - メルマ！

警察庁石井交通局長の見解がこの記事にあるとおりなのかどうか、をまず確認したいところ。もし本当にこういう見解だったら、警察庁内部で意見の対立があり、しかも前回発表された「自転車は基本的に車道」とは真逆のサイドに交通局長がついているってことになっちゃうな。

喧嘩上等のカメラ店が「ど素人」に教わった商売の極意

人はなんのためにカメラを買うのかってことだよね。すると、実はカメラを買ってるんじゃないってことが分かってくる。

カメラに詳しくて自分でなんでもできる人は、どこの店に行ったっていいんだよ。でも、カメラなんて全然分からなくて、使い方を知らない素人が世の中には8割も9割もいるわけだ。

カメラ屋じゃなくて、家電屋でもこういうやり方で成功している会社があったな。高齢者とかの自宅サポートとかを手厚くすることで、安売り商売から脱却したとか。ただ、こういう方法はほかが安売り競争をしているから、サービス品質で差別化できているんだろうけど、これからはこれだ！とみんなでまねし始めたらどうなるんだろうな？　また揺り戻しでその中での安売り体力勝負みたいになっちゃうんだろうか。

「多くの会社が報復をおそれている」　グリー田中社長、DeNA提訴を説明 - ITmedia ニュース

釣りゲームの著作権のときとか、グリーはいまいち怪しげな主張をしたがる感があるんで、この件もどれだけちゃんとした根拠があるんだろうかと、ちょっと不信感が強い。詳しく調べたら、実はサードパーティの自主的な自粛をDeNAがまだ圧力をかけてると勘違いした。とかじゃないのか。

JS→Objc 連続でのデータ送信不能問題とその解決法 « iPhoneアプリ練習帳

適当なDOMにリストで渡したいデータを突っ込んでおいて、shouldStartLoadWithRequest内でstringByEvaluatingJavaScriptFromStringして未取得のデータを取得＆取得後削除する、とかだとだめなのかな。JSの実行タイミングとかが非同期だったりしてうまくいかなかったりするだろうか？

Node.jsでつくるGood Old Web App

ある程度規模が大きくなったときに、どう対応するのがGood Practiceなのか知りたい。イベントハンドラ定義（ルーティング）はまとめて書いて、そのイベント実装は別ファイルに分ける？