YouTubeとかでFlashサイトとかでEmbedタグとかを吐いてくれる感じのやつ。

らんきん5!の場合はHTMLコンテンツなんで、iframeで埋め込むんだろうなーということで、ひとまずiframeで埋め込むコードを書いてみた。

うーん、iframeのサイズを指定しないと不格好だ。

じゃあ、javascriptでiframeをリサイズしてみるか。

と思ったけど、iframe内のコンテンツにはクロスドメインアクセスの制限がかかるから、iframe内のjavascriptでコンテンツサイズを取得しても、iframeタグを持つ外側DOMとは直接やりとりできない（他サイト貼り付けだから、基本iframe内外は別ドメイン）。

iframeのスクロールバーの状態とか見て、スクロールが必要かどうかを取得して、そこからiframe内コンテンツのサイズを逆算してみようとか思ったんだけど、スクロールバーとかも基本はiframe内扱いっぽいね。

じゃあ、外側HTMLの方でjavascriptでiframeタグをはき出しつつ、サイズ情報を動的に追加すればいいんじゃないか、とか考えたんだけど、コンテンツ表示サイズ情報がiframe内にあるんだから、サイズ変更JavaScriptコードが内外どちらにあろうと、クロスドメインの壁を越える何らかの方法がないとどうともならないのね。

じゃあクロスドメインとは関係ない、サーバーAPIとしてコンテンツのサイズ情報を取得できるものを用意して、JSONPとかで情報を取得すればいいんじゃね。

と思ったけれども、よく考えたらHTMLコンテンツの表示サイズなんて、ブラウザ側の仕様・設定によって違ってくるから、サーバーサイドAPIとしてコンテンツ表示サイズなんて取得できるわけないよね。まあ雰囲気だけの情報なら取得できなくもないけどさ。

困ったなーと思ってググってみたところ、クロスドメイン通信できるwindow.postMessageというのがあるらしい。それを使ってiframe内の別ドメインから通知を受けて、iframe外でサイズ変更している例があった。

最初window.postMessageで送るデータは、javascriptオブジェクトにしていたんだけど、chrome、firefox、safariとかはそれでも通るのに、IE9だとstringしか通してくれなかったんで、JSONで送って受信側でobjectに戻すようにした。

あと、最初は$(document).readyでのみメッセージを通知していたけど、iframeをwidth: 100%で生成しているんで、ブラウザウィンドウのリサイズによって、HTMLコンテンツの表示サイズは変わりうるから、$(window).resizeでもメッセージ通知した方がいいんだよね。

ってことで、主要なブラウザではだいたい動くようになった。

貼り付けができるのは、質問と回答。たとえば、最近好きなマンガは？という質問ページに行くと、「貼り付け！」というボタンがあるのでそれをクリックすると、以下のような貼り付け用JavaScriptコードが表示される。

[sourcecode language="javascript"]


[/sourcecode]

このコードをHTMLとして埋め込むと、以下のように表示される。

回答の場合も同様に、「貼り付け！」ボタンを押すと、

[sourcecode language="javascript"]


[/sourcecode]

というコードが表示されるんで、それを貼り付けると以下のように表示される。

ここ数年、スパムまみれになった1470.netの惨状をメンテする気になれずに、個人でWebサービスを構築したりするのをほとんどやらないでいた。

その間いろんな新しい技術に対しては、一応ドキュメントなんかは眺めて、雰囲気はだいたいつかんでみてはいるものの、まじめに使ってみるようなことはほとんどせず、実際に自分の手を動かしたらいろんな発見があるものだよね、ってことをすっかり忘れてしまっていた。

今回のたったこれだけのことでも、実際に手を動かすとやっぱりいろいろと発見があるし、特にサンプルコードレベル以上の一通りの機能がそろったサイトを構築してみると、さらにいろんな発見があったりする。

やっぱりいろんな技術に対しては、何となくドキュメントをながめて理解した気分になるだけでなく、実際にそれを使ったミニサービスくらいは作ってみた方がいいね。

というわけで、らんきん5!にはここ数年の遅れを取り戻すために、思いついたことはいろいろ試して盛り込んでいくつもり。

といっても、最近その他でいろいろ忙しくて情報収集できていないんで、さらっと。

まずは男子シングルスのドロー。

錦織、現在のランキングとしてはベストの第24シードをゲットした。初戦の相手はROBERT, Stephane、現在107位、キャリアハイ61位と、GS初戦としてはだいぶ楽な相手。錦織は直前のエキシビションでツォンガ、ロディックを倒すといういいコンディションで入っているので、ここは余裕があるはず。

その後ランキング上位が勝ち上がるとすると、EBDEN, Matthew、シモン、ツォンガ、マレー、ジョコビッチ、ナダルというドロー。さすがに3回戦くらいからは実績的には格上と戦うことになるけれども、ここ最近の錦織の調子を考えるとシモン、ツォンガあたりは格上の中ではだいぶ戦いやすい相手。マレーまでたどり着ければほぼベストの結果だろう。シモンに当たるよりも前に負けると今年の幸先がちょっと暗くなってくる。

そのほか日本人勢としては、ワイルドカードをもらって本戦から出場の伊藤竜馬は、初戦スタラーチェ、それを抜けてもラオニッチ、ジョコビッチと非常にきついドロー。だが、伊藤の場合はまずは初戦突破が目標だろうから、その先は勝ってから考えれば十分。今年は全GS出場と、ATPクラスへの定着を目指して欲しい。

ほかの日本人男子は残念ながら予選を突破できなかった。前哨戦では調子が良かったのにもったいない。ただし、添田は100位以内に入ってきたんで、全仏以降のGSはこの調子を維持できればストレートインできるだろうし、今年は100位以内定着を目指して欲しいところ。

続いてトップ4のドローを見てみる。

ジョコビッチは去年終盤フィジカルコンディション的に失速したのが不安だったんだけど、直前のエキシビションを見る限りは体調は完全に回復した模様。GSの2週間の長丁場は多少不安だけど、まあたぶん大丈夫でしょう。

ドロー的にも自分の山にはあまり伏兵的な存在は隠れていないように見える。ティプサレビッチ、フェレールが多少気持ち悪いけど、まずSF進出は固そう。

続いてナダルは、ドロー以前に去年中盤以降の燃え尽き症候群っぽさがちょっといやな感じ。自分自身の調子は悪くないのに、ジョコビッチに決勝で連敗したことと、生涯グランドスラムもナンバーワンも経験してしまったため、モチベーションのもっていきかたが難しくなってしまったんだろうなー。

で、現状のナダルはハードコートでは一昨年のような強さは陰を潜めてしまっているため、トップ4以外にも調子がいいハードコートが得意な選手には足下をすくわれかねない。

ナダル山の面子を見てみると、ベルディヒ、バグダティス、ナルバンディアン、ダビデンコ、ハースあたりが調子がいいとちょっと怖い感じ。ただまあ、その辺りの面子はナダルよりも安定感的な部分が弱いから、ナダルに当たる前に消えてしまう可能性はあるが。特に最近復活しつつあるバグダティスが一番怖いかな。ナダルはSFまで残るのも厳しそうだし、SF以降もトップ4対決は分が悪そうだ。

一度は4位まで落ちながらも、去年終盤に一気に巻き返して3位まで戻したフェデラーは、直前の前哨戦で背中の怪我で珍しく大会途中棄権したのがかなり不安。だが、逆に言うと滅多にやらない途中棄権までして、全豪に向けてのコンディションを整えてきているようにも見える。

ドロー自体は、QFで当たる可能性があるデルポトロが怖いくらいだけど、デルポトロも去年一気に順位を上げてきた弊害で、フィジカルコンディション的にはちょっと苦しくなっていたのが、現在どこまで回復しているだろう。フェデラーは比較的楽な勝ち上がりになりそうな気がする。

そしてマレー。去年はアジアシーズンで絶好調になり、最終戦直前で失速するという、相変わらずのピークの持って行き方が下手なところを見せてくれたけれども、全豪はスケジュール的にはそれほど変なことができない分、あまりおかしなコンディションで入ってくることはないだろう。前哨戦も調子が良かったし。

ただ、ドロー自体はあまり良くない感じ。初戦のハリソンとか、失うもののない伸び盛りの若手が、後のことを考えずに勝負をかけてきたりすると、まさかの取りこぼしとかやりかねない気がする。それ以降もグルビス、トロイキ、モンフィス、錦織、ツォンガと、序盤から中盤に当たるにはちょっと怖い相手がいろいろとそろっている。マレーはこけるならば早い段階でやらかしそう。逆に1、2回戦を突破できればそのままジョコビッチと当たるところまでいけるかな。

というわけで、今回の男子シングルスの優勝候補は、

といった感じです。よろしければあなたの予想も投票してみてください。Twitterアカウントがあれば投票できます。

続いて女子シングルス。といっても去年辺りから女子はほとんど見なくなってるんで、雰囲気だけ。

日本人女子は、ストレートインできている森田と伊達の二人だけの出場。予選突破者は出なかった。土居には期待していたんだけど予選1回戦で惜しい負け方をしてしまったし、去年はぐだぐだになっていた奈良は去年終盤からだいぶ復調してきたらしく、予選決勝まで残ったのに残念ながら負けてしまった。土居、奈良はいい加減WTAレベルに定着して欲しいんだけど。

森田の1回戦の相手は、CETKOVSKA, Petra。初戦からあまり楽な相手じゃないけれども、森田の場合は誰をひいてもあまり楽な相手とは言えないからなー。去年中盤くらいまでは結構いい感じでWTAレベルで戦えていた森田だけど、去年後半からまた格上に勝てない感じになってきているのが気になる。順当勝ち・順当負けではなく、格上にももっと勝てるようになるといいんだけど。ひとまず初戦突破を。

去年終盤から今年の頭にかけてのITF巡りで、またWTAレベルにランキングを戻してきた伊達の初戦の相手は、DANIILIDOU, Elen。伊達の場合は相手の強い弱いよりは、伊達の戦い方が通じる相手かどうかがでかいからなー。出だしからシードに当たらなかったんで良かったけど。できれば3回戦でスキアボーネと当たって、スピン対ライジングフラットのストローク対決を見せて欲しい。

女子の優勝争いはよくわからない。ウォズニアッキは順当に勝ち上がって行きつつも、クライシュテルス、リーナあたりと当たると厳しそうだなー。去年大ブレークをクビトバの方がGSでは可能性がありそう。QFで当たる可能性があるストーサーあたりまで安泰っぽい？　女子はランキング上位と実績上位のどちらも同じくらい可能性がありそうで、何とも予想しにくい。

ひとまず適当な予想は、

にしてみた。まあさっぱりわからないね。

もう初日のスケジュールは発表されていて、日本人勢は伊達、森田とコート8の1、2回戦に割り振られている。たぶんWOWOWは連続中継するんだろうな。

そのほか気になる組み合わせとしては、地元トミックがベルダスコと当たる。現時点ではまだベルダスコの方が上だろうけど、あの無理をしない省エネテニスでベルダスコに勝てるようだと、トミックの潜在能力の高さは末恐ろしい感じになる。

フィジカル的な問題が多発で去年はあまり試合数をこなせなかったクライシュテルスの初戦もある。すかっと勝ち上がって優勝候補に名乗りを上げられるか、それともやはりコンディション的な問題をまだ抱えている感じなのかの試金石。

ニーミネン vs. ナルバンディアンという地味に面白そうな組み合わせもあるけれども、きっとテレビ放送してくれないだろうなー。コールシュライバー vs. モナコとかもちょっと面白そう。

らんきん5! は永遠のベータ版なので、今後どんどん変わっていくかもしれないけれども、ひとまず現バージョンにおいての話。

サーバーはもともと利用していたさくらのVPS 512が3台。昔はさくらの専用サーバーを3台（10000円×3）借りていたことを考えると、さくらのVPS 512が3台（1000円×3）なんて安くなったものだなー。

ひとまずスモールスタートなので、さくらのVPS 512が1台で始めようと思っていたんだけど、どうせならばスケールアウトのテストもかねて無駄に3台使った構成から始めてみた。内容的には1台でも十分まかなえる。

WebサーバーはApache 2.2.3。スタティックドキュメント配信、アプリケーションサーバー、リバースプロキシー＆ロードバランサーとして利用。3台とも同一構成で並べつつ、1台にはmod_proxy_balancerを入れて、そこでいったんリクエストを受け付けてからstickysessionで3台に回している。

サーバーサイドスクリプトエンジンはPHP 5.3.8/mod_php/APC。フレームワークはZend Framework 1.11.11。ごくごく標準的なZend FrameworkのWebアプリケーション構成にしてある。

クライアントサイドJavaScriptフレームワークはjQuery。PC版もモバイル版も同じ。最初モバイル版はjQuery Mobileで作ろうとしていろいろいじってみたんだけど、このサイトではあまり手間対効果のバランスが良くなかったんでやめた。現状のスマートフォン版はレイアウトHTMLを別物に差し替えて、CSSレベルで見た目を調整しているだけ。

DBサーバーはMySQL 5.5.17＋mroonga。3台それぞれに同一構成でインストールしつつ、1台をマスター、残り2台をスレーブにしている。Zend_Db_Table/Zend_Db_Table_RowからDBアクセスを分散させる方法は、結構悩みどころだね。今回実装した方法がどのくらい使えるかはしばらく検証してみないと。

日本語全文検索エンジンは、最近はずっとtritonnを使ってきたんだけど、さすがにそろそろmroongaに乗り換えるべきだろうと、初めて使ってみた。ただ、最低限の日本語全文検索エンジンとしてしか使っていないんで、groongaらしい機能は全然触っていない。

memcachedを各サーバーに入れて、それぞれ用のセッションサーバーとして利用しているけれども、さくらのVPS 512だとメモリがもったいないんで、ファイルベースのセッションに戻しちゃうかも。

それぞれの詳しい内容については、またあとで。

らんきん5!  (http://rankin5.com) という新しい個人Webサービスを作りました。

どういうものかというと、ランキング形式でトップ5を回答するQ＆Aサイトです。

Twitterアカウントでログインするだけで利用できます。特にユーザー登録は必要ありません。

上記URLからサイトに行き、興味がある質問を見つけたら「この質問に答える！」をクリックすると、自分の答えを登録することができます。

何か人に聞いてみたいことがある場合は、「質問する！」をクリックすると、新しい質問を登録することができます。

最初は1件しか質問できませんが、いくつかの質問に回答することでまた新しい質問を登録することができるようになります。

質問や回答には、Twitterへ投稿するためのリンクが用意されているので、そちらを利用してTwitterと連携させることができます。

スマートフォンから利用する場合は、右上辺りに「モバイル版」というリンクがあると思うので、それをクリックするとスマートフォン向け画面に切り替わります。

基本的な機能についてはだいたいできあがったので、興味を持った方は是非使ってみてください。

永遠のベータ版方式で、つかいながらいろいろ機能を増やしたり削ったりデザインを変えたりしていきたいと思っています。

今年の正月休みはどこにも出かけなかったので、その間に一気に作ってしまおうと思ったのですが、酒を飲んだり酒を飲んだり酒を飲んだりしてしまったため、結局休み明けまで引っ張ってしまいました。

多言語（英語と日本語）対応にしてみたり、スマートフォン対応にしてみたり、非同期更新＋UIアニメーションを使ってみたり、いろいろいまどきっぽく作ってみました。

動作環境を構築するために、1470.netをだましだまし動かしていたサーバーの各種モジュールをいろいろアップデートしたところ、古いライブラリ（主にZend Frameworkの初期バージョン＋オレオレ拡張）をだましきれなくなってしまい、Webアプリ側が動かなくなってしまったため、1470.netフロントエンドは閉鎖してしまいました。バックエンドとデータは生きているので、新着URL情報などは一応Twitterに流し続けています。

といった感じで、よろしくお願いします。

ATP250ブリスベンの1回戦、錦織なんとかフルセットで勝利。

• 錦織 def. Cedric-Marcel Stebe 36 61 64

ファイナルセットを1-4でリードされているところから、勝手ストリーミングで見たけど、錦織が悪かったと言うよりはステーベが良かったっぽいな。ものすごく攻めが早くて、その割にはミスが少ない。出てきた当時の錦織みたいな攻撃力のあるストロークだった。しかもサウスポーだし。

去年の錦織は安定感重視のつなぐ球が多かったんだけど、ステーベの攻撃が早くて厳しいからつなぐ球を打つ余裕がなく、錦織の方も昔みたいに早い攻めをするようになっていた。

ファイナルセット中盤は互角のストローク戦を、ぎりぎり錦織が上回るような展開で錦織が押し返していき、ファイナルセット終盤はステーベの方のミスもちょっと増えだして、錦織は多少余裕を持ってショットのコースを選べるようになっていた。

これは年明け初戦＆全豪前哨戦としてはかなりいい試合内容だったんじゃないだろうか。次はバグダティス。そういえばステーベは比較的フラットなストロークがバグダティスにも似ていたな。バグダティス戦のちょうどいい練習にもなったんじゃないだろうか。

そういえばATP250チェンナイで決勝に進んでいた添田と杉田はどちらも予選突破した。

• 添田 def. E.Roger-Vasselin 64 76(5)
• 杉田 def. R.De Voest 76(0) 61

相手もちょうどATPレベルでぎりぎり戦っているクラスで、この辺りに勝てるとATPレベルの大会に常駐できるようになれそうなところ。添田の本戦1回戦の相手はGIL, Frederic、杉田の相手はROCHUS, Olivier。ATPレベルに定着するには本戦1回は勝っていかないと。

本当にプロテニスには正月もないなー。そして、今年の日本人男子は幸先よい。

錦織が本戦からの出場を決めているATP250ブリスベンで、竜馬が予選を勝ち上がって本戦出場を決めた。

• 伊藤竜馬 def. M.Look 46 64 64

竜馬は今122位でGS本戦ストレートインまであと少しのポジション。もう全豪には間に合わないけど、ここでもうひとがんばりしておけば、今年はGS本戦からの出場も夢じゃない。本戦1回戦はB.Mitchell、ニーミネン、A.Mannarino、ヒラルドの中の誰か。

錦織のドローは、1回戦はSTEBE, Cedrik-Marcel。81位のドイツ人か。それを勝ち上がったらバグダティス vs. ハリソンの勝者。その次がマレー。反対側の山に比べるとなんだかずいぶん厳しいドローだな。初戦＆全豪前哨戦として、少しずつ体を慣らしていこうというドローじゃないけれども、このドローでそこそこ勝ち上がれるようだと今年も期待できる。何とかマレーまでたどり着いて欲しいな。

さらにATP250チェンナイでは杉田と添田も予選に出場していて、今のところ二人そろって2回戦まで勝ち上がっている。杉田192位、添田120位。錦織を含めたデビスカップ代表達がみんなでATPレベルまであがってくると、日本人男子テニスの黄金時代がやってくるかも。

試しにやってみたらやたらとはまったのでメモ。

さくらのVPSに適当なバーチャルホスト（foo.example.com）を割り振り、そのバーチャルホスト宛に届いたすべてのメール（*@foo.example.com）をPHPスクリプトで受信したい。

CatchAllじゃないんだったら、受信したいアカウントの.forwardとかからスクリプトを呼び出せばいいんだけど、CatchAllとなるとまず受信したいアカウントというものが存在しないわけで、その辺から設定する必要がある。

具体的には、まず適当な受信用のアカウント（mailreciever）を用意する。

[sourcecode language="plain"] useradd -s /sbin/nologin mailreciever [/sourcecode]

で、そのアカウントとバーチャルホストのCatchAll転送先を結びつける。まずはバーチャルホストをsendmailが受信するドメインとして追加するために、/etc/mail/local-host-namesに以下を追加。

[sourcecode language="plain"] foo.example.com [/sourcecode]

そして、そのドメインのCatchAll転送先としてmailrecieverアカウントを登録するために、/etc/mail/virtualusertableに以下を追加。

[sourcecode language="plain"] @foo.example.com mailreciever [/sourcecode]

virtualusertableはコンパイルが必要なので、

[sourcecode language="plain"] yum install sendmail-cf # 必要ならば makemap hash /etc/mail/virtualusertable.db < /etc/mail/virtualusertable [/sourcecode]

mailrecieverアカウントに受信したときにPHPスクリプト（/path/to/script.php）を実行するように/etc/aliasesに以下を追加。

[sourcecode language="plain"] mailreciever: "|/usr/bin/php /path/to/script.php" [/sourcecode]

というのは実はうまく動かなかった。smrsh環境の制約に引っかかるらしい。そこで、

[sourcecode language="plain"] ln -s /usr/bin/php /etc/smrsh/php [/sourcecode]

のように/etc/smrshディレクトリ内にPHPのCLIバイナリのシンボリックリンクを作っておいて、先ほど書いた/etc/aliasesの内容を、

[sourcecode language="plain"] mailreciever: "|/etc/smrsh/php /path/to/script.php" [/sourcecode]

と変更するとsmrsh環境が原因のエラーを回避できる。

ちなみに/etc/aliasesもコンパイルが必要なので、

[sourcecode language="plain"] newaliases [/sourcecode]

を実行してコンパイルしておく。

これでlocalhost上で*@foo.example.com宛てのメールを送ると、ちゃんと/path/to/script.phpが起動できるようになったのだが、外部からメールを送ってもちゃんと着信していない。

ああ、もちろんそれ以前に、foo.example.comのドメインを該当サーバーのIPアドレスでDNS登録しておく必要があるけど、そういう問題ではない。

あと、自分でセットしたソフトウェアファイアウォールで25ポートINがふさがっているのかと思ったりもしたが、それもない。さくらインターネットが25ポートINを外側でふさいでいるのかと思ったのだが、それでもない。

正解は、さくらVPS＋CentOSでインストールされるsendmailのデフォルト設定は、localhostからのSMTPしか受信しないようになっている、だった。

sendmail.cfには触らないと心に誓っているんで、あきらめてpostfixにでも入れ直そうかと思ったんだけど、ググってみたらそれほど設定変更は大変そうじゃなかったんで、sendmailのまま設定を変えて対応した。

/etc/mail/sendmail.mcの

[sourcecode language="plain"] DAEMON_OPTIONS('Port=smtp,Addr=127.0.0.1, Name=MTA')dnl [/sourcecode]

という行をコメントアウトして、

[sourcecode language="plain"] dnl # DAEMON_OPTIONS('Port=smtp,Addr=127.0.0.1, Name=MTA')dnl [/sourcecode]

に変更し、

[sourcecode language="plain"] m4 /etc/mail/sendmail.mc /etc/mail/sendmail.cf [/sourcecode]

でコンパイルしてからsendmailを再起動したら、無事外部からのSMTP接続も受信してくれるようになり、foo.example.com宛てのすべてのエールを/path/to/script.phpで処理できるようになった。

なんかものすごくはまりどころが多かった。

PHPのJITコンパイラ「HipHop Virtual Machine」、Facebookがオープンソースで公開 － Publickey

HipHopの段階から試していないんだけど、これっていろいろ制限が大きそうな気がするんだけど、その辺の情報が見当たらなくて試してみるのも躊躇している。実際どの程度のPHPのコードにまで適用できるんだ？　大規模なフレームワークとかを使ったコードでも使えるの？　まあそんなの自分で試せって話なんだけど。

Tonny Xu: SQLiteを用いて、iOSで高速全文検索をしよう

SQLiteの全文検索って日本語でも使い物になるの？と思っていたけど、このベンチマークを見る限りはそれなりに使えるっぽいな。ただ、単語辞書だとこんな感じでいけるけど、実際に日本語文章を扱おうと思ったら、実データを使っていろいろ試してみてからの方が良さそうだ。

米Google、「Chrome上でスクエニなどのゲームがプレイ可能に」 -INTERNET Watch

あれ、C#にも対応しているの？　俄然興味が出てきた。と思ってSDKインストールしたりドキュメント読んだりしてみたけど、まだC#に対応してなくね？　将来はC#とかの他言語にも対応するつもりだよ、と書いているのしか見つけられないんだけど。

Microsoft、「Silverlight 5」正式版を公開 -INTERNET Watch

Windows 8のタッチUI用IE10はプラグインに非対応。FlashもSilverlightも使えず － Publickey

Microsoftでは、次期OSの「Windows 8（開発コード名）」に搭載されるInternet Explorer 10（IE10）について、Metroスタイル向けのIE10ではFlashやSilverlightなどのプラグインをサポートしないことを表明してい る。また、Silverlight 5のサポートライフサイクルが2021年10月12日までと長期に設定されていることから、海外のメディアなどではSilverlight 5が最後のメジャーバージョンになるのではないかと報じている。

マイクロソフトの迷走なのか、明確な戦略があってのそれぞれの技術開発なのか、現状だと前者にしか見えないのがいやだよなー。インターネット関連技術の発展にスタートからついていけなかったマイクロソフトが、圧倒的なシェアと資金力を背景にごまかしごまかし今までやってきたけど、いまだにインターネット関連技術には弱いまんまって感じだ。人材がいないわけはないから、会社がでかすぎてインターネット的な技術文化を会社に浸透させることができないって感じなのかなー。

【清水理史の「イニシャルB」】 第469回：拡張パック利用で3時間超の給電も可能！　UPS「APC RS XL500」 -INTERNET Watch

小型家電・PC周辺機器向けバッテリーパック規格で書いたネタに近い感じのイメージだな。この拡張バッテリーポートと接続ケーブルを規格化して一般家電でもそのまま使えるようにならないだろうか。特にハードディスクレコーダーとか録画機では標準採用して欲しい。東芝とかAPCと提携してやってくれないかなー。

Javascript (ECMAScript) の変なところ - fujlog

なんか知らないことが多い。というかJavaScriptの言語仕様はちゃんと知らない。JavaScript 第5版もGood Partsも買っただけでちゃんと読んでないし。早めにちゃんと読んでおいた方がいいんだろうなー。

Q4Mを簡単に導入する方法 - MySQL Casual Advent Calendar 2011 - blog.nomadscafe.jp

Q4M専用のMySQLを、データストレージ用MySQLとは別ディレクトリにインストールして、それぞれ別に手軽に利用できる環境を作るインストールスクリプト。Q4Mは環境条件が厳しくてインストールが面倒くさいから、これはとても便利そう。

なんかもう、Silverlightの普通の.NET Frameworkとの互換性のなさにはうんざりしているんだけど、その中でも特にうんざりしたWebRequest周りについて。

普通に.NET FrameworkでWeb APIとかにアクセスしたい場合、System.Net.WebClientとかを使うと簡単にできる。

[sourcecode language="c#"]
var client = new System.Net.WebClient();
var url = "http://example.com/path/to/api";
var values = new NameValueCollection(){{"key", "value"}};
var byteResult = client.UploadValues(url, values);
var stringResult = Encoding.UTF8.GetString(byteString);
[/sourcecode]

受け取った文字列がJSONだった場合は、

[sourcecode language="c#"]
var serializer = new JavaScriptSerializer();
var result = serializer.Deserialize(stringResult, typeof(ObjectForMapping);
[/sourcecode]

みたいな感じで受け取り用のクラス（ObjectForMapping）を用意しておいて、それにデシリアライズしたりとか。 あと、これだけだとCookieベースの認証とかが維持できないんで、webclient 継承 cookiecontainerでググると出てくるような感じで、

[sourcecode language="c#"]
class MyClient: WebClient
{
  protected CookieContainer _cookie = new CookieContainer();
  protected override GetWebRequest(Uri address)
  {
    var request = base.GetWebRequest(address);
    if (request is HttpWebRequest) {
      (request as HttpWebRequest).CookieContainer = _cookieContainer;
    }
    return request;
  }
} 
[/sourcecode]

みたいな感じでCookieを扱えるクラスを作っておくと、自動的にCookieを維持してくれるようになる。 でまあ、Silverlightでも同じようなことができるよね、と思って、クラスライブラリの名前空間とかファイルとかの構成がいろいろ変わっているのを乗り越えて、

[sourcecode language="c#"] 
using System.Windows.Browser; 
using System.Net.Browser; 
class MyClient: WebClient  
{
} 
[/sourcecode]

とやったところ、これはコンパイル自体は通るくせに、new MyClient()するコードブロックを通ったとたんに、何のエラーメッセージも出さずにそっと落ちる。 どうやらWebClientを継承したらだめなようだ。

けど、そんなドキュメント、どこにも見つからないし、だいたいコンパイルは通ってるんだけどなー。っつーか、結局WebClientを継承するだけでもだめだ、と気づくまでどれだけ時間がかかったことか。 しょうがないんで、自前でWebRequestを使って処理を行うような構成に変更することにする。必要に応じて、

[sourcecode language="c#"]
var request = WebRequest.Create(new Uri(url));
(request as HttpWebRequest).CookieContainer = _cookie; // 使い回すCookieContainer
request.BegubGetResponse(callback, request);
[/sourcecode]

みたいな感じね。でも、これが通らない。なぜかというと、

[sourcecode language="c#"]
var request = WebRequest.Create(new Uri(url));
[/sourcecode]

で返されるWebRequestがHttpWebRequestではなくBrowserHttpWebRequestってやつになっている。なんじゃそりゃ。それはどの辺のドキュメントに書いてあるんだよ。MSDN内で検索してもそのドキュメントが見つからないぞ。

いろいろ探し回った結果、方法: Cookie の取得と設定を行うというドキュメントを見つけた。解説自体は今までやっていたことを説明しているだけで、特に新しい情報はない。しかし、サンプルコードに見慣れない処理が入っている具体的には、

[sourcecode language="c#"]
IWebRequestCreate creator = WebRequestCreator.ClientHttp;
WebRequest.RegisterPrefix("http://", creator);
WebRequest.RegisterPrefix("https://", creator);
HttpWebRequest request = (HttpWebRequest)WebRequest.Create("http://api.search.live.net/clientaccesspolicy.xml")
[/sourcecode]

なんじゃこりゃ。WebRequestCreatorクラスのドキュメントを見てみると、

Silverlight では、ブラウザーとクライアントのどちらで Silverlight ベース アプリケーションの HTTP 処理を行うかを指定できます。既定では HTTP 処理はブラウザーによって行われるため、クライアントで HTTP 処理を行う場合は選択の必要があります。通常、HTTP の要求と応答の処理方法を指定するには、このクラスのプロパティを WebRequest の RegisterPrefix メソッドSilverlight では、ブラウザーとクライアントのどちらで Silverlight ベース アプリケーションの HTTP 処理を行うかを指定できます。既定では HTTP 処理はブラウザーによって行われるため、クライアントで HTTP 処理を行う場合は選択の必要があります。通常、HTTP の要求と応答の処理方法を指定するには、このクラスのプロパティを WebRequest の RegisterPrefix メソッドに渡します。に渡します。

なるほど、Silverlightってそこまでブラウザと密結合していたのね。 標準ではBrowserHttpWebRequestってのが使われるから、非Silverlight環境と互換性のあるHttpWebRequestを使いたい場合は、サンプル通りにSilverlight側でhttpスキームを処理するように指定してからWebRequest.Createしなければならないのか。そうやったらちゃんとHttpWebRequestが生成されるようになった。CookieContainerも使えている。

で、一通りコンパイルは通るようになったし、実行もできるようになったんだけど、なぜかCookieによる認証が維持されない。認証CookieがHttpOnlyなんで、中身をのぞけないからよくわからないが、少なくとも同じようなコードで通常の.NET Frameworkでは動作するものが、Silverlight環境ではうまくいかない。

うがー、どないなっとんねん。と、SilverlightのHTTP通信周りのドキュメントをもう一度良い返してみる。そうしたら、Silverlightの標準の方のBrowserHttpWebRequestでは、ブラウザの機能を使ってHTTPリクエストを処理するんで、ブラウザ側のCookieがそのまま使えるっぽい？　なんか非Silverlight用に作ったコードを移植しようとしていたのは無駄な努力だった？

というわけで、単純に認証Cookieを保持したいだけだったら、わざわざHttpWebRequestを生成して自前でCookieContainerを処理したりする必要はなく、何も考えずにSilverlight標準のWebアクセスクラスを使ってしまえば、ブラウザ相当のCookie処理が使われてくれる。

先に非Silverlight用のWeb APIクライアントコードを書いて、それをSilverlightでも動くように移植しようとしたせいで、無駄にはまったんだね。はじめからSilverlight用に書いていれば何も考えなくても動くものが作れた気がする。ただし、ブラウザ互換のWebアクセスクラスにも制約があるんで、それで全部いけるわけではないけど。

書き忘れていたけど、クロスドメインアクセス用のcrossdomain.xmlとかは、Flashとかと同様、サーバーサイドにあらかじめ用意しておく必要がある。

で、APIアクセスライブラリとしては一通り動くようになったから、SilverlightアプリケーションからWeb APIをコールして、その結果をTextBoxに表示するというテストアプリを作ってみた。が、「System.UnauthorizedAccessException: 無効なスレッド間アクセスです。」というエラーが出て表示できない。

どうやらAsyncCallbackから呼び出されるスレッドと、UI部品などを管理するメインスレッドとは別スレッドだから、直接は呼び出せないと言うことらしい。

いろいろググったところ、Silverlight 奮戦記 ファイルを読む β2 対応版という情報を見つけた。AsyncCallbackから呼び出されたメソッドから、さらにSyncronizationContect.Current.Post()を使ってメインスレッドとの同期を取ってから、メインスレッド側のパーツに対する処理を行えば回避できるみたいだ。でも、この辺の情報は公式ドキュメントではどの辺に書いてあるのかなー。

といった感じで、.NET Frameworkがらみのドキュメントは非常にわかりにくいし、同じ名前のクラスが多いくせに制限事項が違うSilverlight環境の場合は、それがさらにひどくなっているんで、あまり深入りしたくない気持ち満点になった。デバッグ環境としてできがいいVisualStudioなのに、Silverlightのデバッグだとうまく動かないことがあまりにも多いし。

connectFreeについて高木浩光さんのツイートまとめ（12/05 06:00まで） - Togetter

平成２３年１２月５日 コネクトフリー株式会社 お客様情報の取得に関するお詫びとご説明

Twitter / @craftgear: ほんとだ､コネクトフリーの会社概要から人名がごっそり ...

フリーのWebスペースで、メニューのオーバーレイとかやるのは見たことあるけど、あれはどうせWebサーバー握ってるところがやってるからなー。フリープロバイダー（WiFi）がHTTP通信中のHTMLをがんがん書き換えちゃいつつ、必要以外の個人情報も収集しちゃったのか。いまどき個人でやっている人たちだって、ここまでやったらやばいかなーくらいは考えそうなことを、あっさりと突き抜けて好き放題やっちゃってるなー。そして指摘されたら即時やめましたって、何も考えなさそうすぎて怖すぎる。

fladdict » アプリの翻訳を依頼するコツ

参考情報をあらかじめ相手に予備知識として提示しておく＋事後に起こりうる具体的なトラブル対策を考慮した出力形式を指定する、って感じかな。まさしくノウハウ。

一部の Android 端末でアプリ権限を迂回できる問題、端末データの削除など -- Engadget Japanese

別アプリのクリティカルな機能をインテントを使って呼ぶことができた、とかかなー。

カラム名／メソッド名の命名のための英語辞書 - CODIC

iPhoneの辞書アプリ（英辞郎）はほぼそのために買ったんだけど、これで代替できるかな。