2月1日付で転職しました。

前職はソシャゲ屋さんで4年ほどマネージメント成分多めのエンジニアをやっていましたが、

• ゲーム系の技術ばかりやっていると、Web/アプリ系技術に触る機会が少なすぎて、技術的なトレンドの（私にとっての）メインストリームに疎くなる
• 会社が大きくなるにつれマネージメントの比重が重くなり、ますます現場レベルでの技術に疎くなる
• ソシャゲ的なお客さんとの向き合い方、コンテンツの作り方がどうもしっくりこない

というあたりに行き詰まりを感じていました。

ゲーム系の技術もそれなりに面白くはあるんですけど、ゲーム系の技術はやはりフロントエンド寄りのほうが華という感じで、バックエンド方向への興味が強い私にとっては、それだけで満足という感じにはならなかったんですよね。

で、やっぱり自分の志向としては、マネージャーよりもエンジニアのほうが好みだし、ゲーム系よりもWeb系だよなーということで、現場レベルのWeb系技術をやらせてくれるところを探していたところ、roomclipというサービスをやっているTunnel株式会社に声をかけてもらい、そちらでお世話になることになりました。

もういい年齢でこういう志向の人間を雇ってくれるというのは、なかなか懐の深い会社だと思います。エンジニア35歳定年説？　なにそれおいしいの？

そっち方面に転職するのにあたって、あんまりWeb系へのブランクが大きすぎるとまずいかなーと思い、転職前にリハビリがてらFirebaseを使ってtwEssayというサービスを作ってみたりしたんですが、Web系フロントエンド技術からずいぶん離れていたため、mBaas+Vue.jsで開発するのになかなか手間取り、結局作りかけのまま時間切れになってしまいました。

本当は、今は亡き日記猿人（才人）やテキスト庵みたいな日記/雑文サイトのコミュニティをTwitterベースで再現する、みたいな感じのものを作ってみたかったんですけど、データ設計的にもコミュニティ設計的にも行き詰まってしまいました。

というわけで、twEssayは単に長文テキストを画像化してTwitterに投稿するだけのサービスになってしまっています。

そのうちモチベーションが上がったら続きを作りたいところですが、業務で色々覚えたり慣れたりしなければならないことが多く、しばらくの間は技術的な興味はそちらで充足してしまう気もするので、手をつける気になるのは大分先のことになるでしょう。

でもFirebaseならば維持費もほとんどかけずに放置できるのがいいですね。一昔前ならばサーバー維持費もおもりをする手間もかけなければならなかったのに、Firebaseならば低コストで維持しておけるし、まかり間違って流行ったところで勝手にスケールしてくれるはず。

レンタルサーバー→自宅サーバー→個人向け専用サーバー→VPS→クラウドサーバー→○aasと、個人でWeb系サービスを立ち上げる環境もずいぶんと変わってきたものですなー。

なんかインターネット老人会濃度が高い。

久しぶりのブログで発散気味なので、これにて終了。今後はちょっとは発信頻度が高い感じになるといいな。

ドメイン売らないかメールが来たのをみて、放置していた1470.netドメインのことを思い出し、最近仕事以外ほとんど何もしない状態が続いているんで、twe-tdからネタを抽出して一言コメントをつける形のまとめブログを始めてみました。

ゆるいネットの話題を追う作業を習慣化して、オンラインリハビリします。

去年の4月に、SIer風何でも屋からオンラインゲーム制作会社に転職し、初めての正月を迎えました。

開発部門を社内に持たずにやってきた会社に、新しく社内で完結した開発体制を構築するため、技術基盤整備と人員確保にばたばたしつつ、合間に開発業務を行っているうちに過ぎ去った半年ちょっと。

ネット徘徊やブログ書きなどもろくにやれませんでしたが、ようやく人員も八割方確保できたので、今年はもうちょっと余力がある感じでやれるんじゃないでしょうか（でもまだ人材募集中です）。

もともと、SIer系のお仕事では使うことができなかった、最新技術を実践できることを期待して転職したんですが、やっぱりオンラインゲーム関係はその辺りの技術が使いやすくていいですね。

前職の頃は、業務ではできない最新技術もろもろは、個人の趣味の範囲でいろいろ試してみたりしていたんですが、数十台規模のサーバーを使ったあれこれなどはなかなか実践できませんでした。

また、個人でやっているサービスではアクセス数なども知れていますし、ユーザーのバリエーションやリアクションもあまり期待できません。

一方オンラインゲームでは、アクセス集中時の負荷は個人でやっているサービスとは比べものにならず、かつては技術要素だけは試してみたことがある各種負荷分散対策を、実践でいろいろ試すことができました。

また、ユーザーのバリエーションやリアクションも多いので、それらに対しての事前準備や事後対応、それらを行うための環境整備など、技術的な課題としてやりがいのあるあれこれを実践することができました。

といった感じで、あれこれブログに書いても良さそうなネタは転がっていたんです。

しかし、ゴミが多すぎてGoogle様を使ってもまともな記事を見つけるのが困難な昨今、中途半端なゴミ記事を追加するのも気が引けるし、かといってそれなりのクオリティの記事を書くほどのモチベーションもない。

特に、技術的な記事の内容が現状に即しているかどうか識別することが難しい状況が多すぎるので、そろそろGoogle様は記事の内容の鮮度を明示する仕組みを導入するべきじゃないでしょうか。更新日時ベースだとコピーブログにやられちゃうから、ちゃんと内容を見る仕組みが必要だよね。あと、技術系ブログはできるだけ記事執筆日時を目立つようにレイアウトしておいてくれると助かりますよ。

とか昔同じようなことを書いた記憶があるな。もう7年まえから状況変わってないのか。

転職する前に最後の個人サービスとして作ったtwe-tdですが、ほぼノーメンテで済ますつもりが、集計結果テーブルだから大丈夫だと思っていたら、1年も持たずにint(11)があふれてしまいbigintでprimary keyを付け直す羽目になりました。やはりTwitterのデータ流速はなめちゃいけません。

今年はほとんど巡回することもないまま、いつの間にか存亡の危機を迎えて乗り越えたらしいLivedoor Reader改めLive Dwango Readerを久しぶりに使おうかと思い、ついでに更新が途絶えた登録フィード群を整理していったところ、ブログ系フィードが半分くらいに減りましたよ。

面倒くさいので，自動移転に対応していない引っ越しをした人は追わなかった（ブログ系サービスはフィードの301 redirectに対応するべき）のですが、オンラインから姿を消した人もたくさんいるんでしょうね。逆に、昔と全く変わらない感じで活動し続けている人達も見かけて感心。

Ruby界隈は息が長い人が多いのはtDiaryのおかげでしょうかねー。「日記」は続けやすいけど「ブログ」は続けにくいしねー。あと今ではTwitterが個人が持つ日記的なコンテンツを吸収しちゃうあたりも、ブログを続けることを難しくしている。

遙か昔のWeb日記界隈の人で生き残っている人って、どれくらいいるんでしょうね。日記猿人とか各種アンテナ群にかつて登録されていた方々の、現在の動向をまとめたページとかないかな。ネットストーカー度が高いコンテンツだけど。

今年もプロテニス観戦はまめにやってました。錦織人気がすごくなると天邪鬼が出てブログとかに書く気になれない感じですが。自分でプレイする方のテニスは頻度が1/3くらいに落ちてだいぶぐだぐだです。身体能力がた落ちです。F1は遂に一戦もちゃんと見ませんでした。まあフジテレビNEXTは解約しちゃってたんで、もともとライブでは見られなかったんだけど。motoGPの方がよほどちゃんと見たかも。

BUFFALOのゼン録は2回の故障交換を乗り越えた後1年間もったんですが、年末差し迫った頃にまたエラーで停止していたので、パナソニックのBXT970買っちゃいましたよ。一週間全録から一ヶ月全録にステップアップですよ。一ヶ月だとそう簡単に消えないんで、前よりもテレビを見る頻度は逆に落ちちゃいました。

紙の本を買うのをほぼ辞めました。今家にある本もほとんど全部処分して、欲しかったらデジタルで買い直すことにしました。今度ブックオフを呼んでまとめて処分します。今まで紙で買っていた本も、ほとんどがデジタルで続きを買えるようになってくれたのですが、たいてい紙より発売が遅れることと、ごく少数いまだにデジタル化しない出版社（あるいは作者）があるのが腹立たしいです。

思いつきがだいぶ発散しているので、そろそろおわります。今年もよろしくお願いします。

【PC遠隔操作事件】第2回公判傍聴メモ・最初の検察側証人は「ファイルスラック領域」を強調(江川 紹子) - 個人 - Yahoo!ニュースを読んでの感想をTwitterにいくつか書いたんだけど、なんか端的に書くと中途半端感が否めないんで、もうちょっとちゃんとまとめておく。

警察側の証言の要旨は、『押収したPCを調査した結果、OSレベルで見えるファイルシステムからは、事件に関連する情報はほとんど得られなかったが、HDDのセクターレベルに残された情報からは、事件に関連すると思われる情報がいくつか見つかった。それらは、そのPC上の暗号化された仮想Fドライブにおいて、問題のウイルスを開発した可能性が高い痕跡だった』と言うもの。

この仮想Fドライブの存在に関しては、片山氏も身に覚えがあるが、そこにウイルスのソースコードが置かれていたことには気がつかなかった、と言っている。そして、それらの情報は自分のPCが犯人によって遠隔操作されてできた、偽の証拠だろうと主張している（のだと思う）。

しかし犯人が、氏を犯人に仕立て上げるために偽の証拠を残そうとしたのだとしたら、どうして『暗号化ドライブ』のような『証拠が残りにくい』場所に証拠を残そうとしたのだろう。

暗号化されているため捜査側がそこから証拠を取り出すことは難しいし、実際警察は暗号化ドライブ自体から証拠を取り出すことはできていないようで、OSやプログラム開発環境が非暗号化ドライブ上でテンポラリ的に使用するファイルの痕跡から、暗号化ドライブ上での作業内容を推測している。わざわざ偽の証拠を残そうとしたにしては、あまりにも証拠が弱すぎる。

もちろん『犯人はわざとそういう遠回しな証拠を残したのだろう』という主張もできなくはない。しかし『自分のPC上で開発した痕跡をできるだけ隠そうとした』と考える方が自然だ。このあたりは犯人の能力をどのくらい大きく評価するか、でどちらの説が有力に思えるかが変わってくるだろう。

あるいは『犯人は、自分のPCでウイルスを開発して自分のPC上に痕跡を残すことを恐れて、すべて他人のPC上でウイルスを開発したのだ』という考え方も、あり得るかもしれない。偽の証拠を残そうとしたのではなく、片山氏のPCが犯人のメイン開発環境であった、という主張だ。

その場合は、できるだけ（普段PCを使用している片山氏にも）痕跡が見つからないように、暗号化ドライブ上で開発を行うことも十分にあり得るだろう。

ただその場合、Visual Studioのような比較的重い開発ツールを使って（しかもVisual Studioのインストール自体も犯人がリモートでやった？　この辺片山氏はどう主張しているんだろう）、ウイルス関連の様々なプログラムの開発およびテストを、完全に氏のPCの遠隔操作のみで作る、というなかなか難易度が高い作業を犯人が行ったということになる。

また、Visual Studioを平日午前中に使用した形跡が残っていることを考えると、その日片山氏がそのPCで作業していたかどうかはわからないが、普通に会社が営業しているであろう時間帯にも、犯人は遠隔操作でウイルス開発作業を行っていた、という推測されるため、かなり状況の妥当性に無理が出てくる（それとも片山氏も、Visual Studio自体は（C#以外の言語で）使っていたと主張しているのかな？）。

推測も多いし、どちらにしろ決定的な判断基準となるような証拠はないわけだけど、今までマスコミ報道で出てきた怪しげな証拠と比べると、今回の話はとても真っ当な内容で、警察が片山氏を犯人と考えている理由は納得できた。それが裁判で有罪になるくらいの証拠なのかどうかはわからないし、ましてやコンピュータおよびプログラミングについて深い知識がない人間にどこまで通じるのかわからないけど。

あと、「遠隔操作ではファイルスラックのスペースは自由に残せない」というのは、警察が証拠を見つけ出したのはOSのインストールドライブからだと思われるので、遠隔操作するためのリモート接続プログラムは、OS上のアプリケーションやサービスとして動作している以上、遠隔操作している状況下でOSインストールドライブに対してHDDの低レベルアクセスはできないから、ということだと思われる。

chkdiskみたいなHDDへの低レベルアクセスが必要なプログラムを実行しようとすると、いったんWindowsを終了し、オンメモリで動作するDOS互換な環境で起動し直してから、そこで実行されるよね。あんな感じ。

Bluetoothレシーバーのバッテリーが切れるのにうんざりしている人、ポケットとかに適当にしまったイヤフォンを取り出すたびに、いちいち絡まったケーブルをほどくのにうんざりしている人にオススメ。最近買って大当たりだった組み合わせ。

まずは、micro USBケーブルで充電しながら使えて、バッテリー持続時間も8時間程度と長めのBluetoothレシーバー『BTTC-200』。値段も3000円ちょっとと、Bluetoothレシーバーとしてはお安め。

micro USBで充電しながら使えるBluetoothレシーバー『BTCC-200』[/caption]

私は普段移動しながらiPhone/Androidの音声を、仕事をしながらPC/Macの音声をイヤフォンで聞いている。そうやって一日中音声を聞くとなると、どんなにバッテリー持続時間が長いBluetoothレシーバーでも、短くて4時間、長くて8時間程度でバッテリーが切れてしまう。

しかもたいていのBluetoothレシーバーは、充電しながら使用することはできないので、せっかくBluetoothレシーバー経由で音声を聞いていても、バッテリーが切れるとBluetoothレシーバーを充電器にセットして、iPhoneやPCにイヤフォンを指し直す必要が出てくる。

でもBluetoothレシーバーで音声を聞くのに慣れてしまうと、iPhoneに直接イヤフォンをつないだ状態でのケーブルの取り回しがうざいし、PCなんかだとちょっと席から離れるときなんかに、いちいちイヤフォンを外すのも面倒くさい。Bluetoothレシーバーならばトイレに行くくらいの距離ならば、そのまま音楽を聴き続けることもできるのに。

というわけで、このBluetoothレシーバー『BTTC-200』。これならば普通に使っていても比較的バッテリーの持ちがいい上に、使っている最中にもmicro USBケーブルをつないで充電することができるので、PCで使っているときに時々micro USBケーブルをつないで充電しておけば、バッテリー切れの心配がなくなる。

小さくて軽いのでどんなに小さいポケットに入れても大丈夫。イメージとしてはちょー軽い懐中時計サイズ。

充電しながらの利用は、バッテリーの寿命にあまり良くない影響を与えるという定説があるわけだけど、まあ値段も大して高くはないんで、バッテリーが劣化したら買い直せばいい。

おまけとして、この『BTTC-200』はレシーバーとしての機能だけでなく、トランスミッター（送信機）としての機能も持っている。Bluetooth機能を持たないミニコンポとかのイヤフォン端子にこれをつなぐと、他のBluetoothレシーバーでその音声を受信することができる。バッテリーが劣化してきたら、micro USBケーブルつなぎっぱなしにして、そういう用途で使うのもいいかもしれない。

ずいぶんBluetoothレシーバー『BTTC-200』の紹介が長くなってしまったが、もう一つのオススメ商品は靴ひも風のケーブルを使ったイヤフォン『アルペックス クツヒモコードイヤフォン SLYP』。

ポケットにぐしゃぐしゃに突っ込んでから取り出した状態[/caption]

普段から外出中も仕事中もイヤフォンを使っているんで、常時イヤフォンを持ち歩いていて、普段使っているイヤフォンは使わないときはポケットに突っ込んでしまうことが多い。そうすると、使おうとしてポケットから取り出すと、イヤフォンが絡んでしまっていて、それをほどいてから使わなければならなくなる。

じゃあ、ケーブルが絡まないような、巻き取り式のイヤフォンとかを使えばいいんじゃないか、と思っていくつか買ってみたのだが、どうも巻き取り式イヤフォンは、巻き取り部分の機構がなめらかに動かなかったり、最初のうちはちゃんと動いていても、そのうちだんだん動きがしぶくなっていったり、巻き取りの仕組みのためか普通のイヤフォンよりも断線などの故障率が高い（3、4個使ってみての経験談）など、今ひとつ満足いくものがなかった。

ポケットから取り出した状態からでも、すぐに使える状態に[/caption]

そこで、この『アルペックス クツヒモコードイヤフォン SLYP』。「絡まないようにすることが難しいならば、絡んでもほどきやすくすればいいじゃない（マリー・アントワネット風に）」。

実際、ポケットにぐしゃぐしゃに突っ込んでおいても、ケーブルが太いためか絡んでいることが少ないし、多少絡んでいたとしても、すぐにほどける。これならば使わないときにポケットに突っ込んだり、カバンに突っ込んだりと、気を遣わずにしまっておいても大丈夫。

これをBluetoothレシーバー『BTTC-200』と組み合わせて使うと、いつでもポケットに突っ込んで持ち運び、使いたいときに取り出して接続したいデバイスとリンク、micro USBケーブルが確保できる場所では使いながら充電、といった感じの使い方で、ほぼ充電切れの心配なしに一日中使い続けられる。

というわけで、ここ数年間日常的に微妙なフラストレーションを感じていたBluetooth＋イヤフォン関連の問題がすっきり解消されて幸せになれたので、久しぶりに物欲日記を書いてみた。

まだ耐久試験が終わっていないから、それによってある程度評価の上下はあるけれども、Bluetoothレシーバー『BTTC-200』の方は1年程度もってくれれば上等、『アルペックス クツヒモコードイヤフォン SLYP』の方は半年程度もってくれれば十分だ。もちろんそれ以上使えるならそれにこしたことはないけど。

その後、いろいろ複雑なことを考えて、テストコードを書いてみたりしたんだけど、なんかうまく収束する方向に持っていけない。

基本的なアプローチとして、実際に自分がテニスをやるときに考えていることや、行動していることをパラメータに置き換えながら何とかしようとした場合、あまりにもパラメータとシチュエーションが多くなりすぎて、どうしても発散してしまうようだ。

そこで、そういう実際にプレイ中のその場その場で出てくる要素をパラメータ化するアプローチはあきらめ、実際のプロテニスプレイヤーをどの程度パラメタライズしたら、そのキャラクターというものが十分に表現できるのか、というアプローチで考え直してみた。

今のところ考えているのは、次のようなパラメータ。

• サーブ（Serve）
• レシーブ（Recieve）
• フットワーク（Quickness）
• フォアハンドストローク（Forehand）
• バックハンドストローク（Backhand）
• ネットプレイ（Net）
• ショットセレクション（Tactics）
• フィジカルタフネス（Physical）
• メンタルタフネス（Mental）
• 安定感（Consistency）
• ハードコート適性（Hard）
• クレイコート適性（Cray）
• グラスコート適性（Grass）

このパラメータで試しに主だったプレイヤーをSABCDEFでランク付けしてみると、

名前	S	R	Q	F	B	N	T	P	M	C	H	C	G
ふぇで	S	B	A	S	B	B	S	A	S	S	S	A	S
なだ	B	B	S	S	A	C	C	S	S	S	A	S	S
じょこ	A	A	A	A	A	C	A	B	A	A	S	A	A
まれ	A	A	S	B	A	B	A	A	B	B	S	B	A
ふぇれ	B	A	A	B	B	C	C	S	A	A	A	A	B
ろで	S	C	C	A	C	B	C	B	B	C	A	C	A
つぉん	A	B	B	A	C	A	B	B	B	B	A	C	A
こり	C	B	A	A	A	D	A	C	B	C	A	B	B
でんこ	B	B	B	B	B	D	B	B	B	C	A	A	D
でるぽ	A	B	B	A	A	C	C	B	A	C	A	A	B
そえだ	B	C	C	C	C	C	C	C	C	C	C	D	C
かるろ	S	C	C	C	C	A	A	C	B	B	A	D	S

なんて感じ。異論は認める。というか、やっているうちにだるくなってきて後半だいぶ適当になっちゃったな。

でも、このくらいあればだいぶ選手の個性を表現できているように思える。あとはこのパラメータを使って、スタティスティクスが出せる程度のシミュレーションができるかどうかだ。

ちなみに俺が出したいスタッツは、ツアーレベルのやつじゃなくて、GSレベルのやつ。具体的には、

• ファーストサービス確率
• ファーストサーブポイント獲得率
• セカンドサーブポイント獲得率
• サービスエース数
• ダブルフォルト数
• ネットプレイ成功率
• ウィナー数
• アンフォーストエラー数
• ブレイク数/ブレイクポイント数

あたり。あと、

• プレイヤーごとの対戦成績
• コートサーフェイスごとの成績

なんてあたりも生涯成績として表示できるようにしたい。というか、基本は数値シミュレーションなんで、その程度の細かい情報が出てこないと面白くない。

なんか話が逸れつつあるけど、ひとまずこんな感じのパラメータ表現で、どうやって細かいスタッツが出せる程度のシミュレーションを行うか。そのシミュレーション結果がリアルなスタッツと同じ感じになるように調整できるか。ってあたりをサンプルコードを書きながら調整していきたい。

まずは数値計算上試合が成立するところまでサンプルを作ってみよう。

どういう内容のシミュレーションを行うかを考えるにあたって、まずは実際のテニスのプレイ中に取る行動や考える内容について、できるだけ細かく分解して考えてみる。

まずはサーバーがサーブを打つ前の段階。

• センターもしくはワイドぎりぎりに、エースを狙って打つ（入れば優位を取れる）
• 相手の読みを外すコース（センター、ワイド、ボディ）・球種（速さ、スピン量の調整）で打つ（威力ではなくプレースメントで優位を取ろうとする）
• 相手の苦手なサイドや球種で入れにいく（ある程度読まれていても不利な展開になりにくい）

あたりが普通の選択肢か。

一方レシーバーサイドがサーブを待っている状態で。

• エース級のサーブを警戒し、予測と賭けで何とかレシーブしようとする
• 手の届く範囲の球を、安定して深くに返そうとする
• 手の届く範囲の球は、強引に叩いていこうとする
• ポジションを上げて、相手のサーブを早いタイミングで叩いていこうとする
• コースを読んで（回り込みなども行い）、読みが当たった場合はレシーブを叩いていこうとする

とかかなー。

これはまだボールが動く前の段階での、プレイヤーの頭の中での選択肢。

続いて、実際にサーバーがサーブを打つ。

• 狙った球種とコースで、サーバーの能力のn％の速度や回転を持つサーブが入る
• 狙った球種だがコースがずれ、 サーバーの能力のn％の速度や回転を持つサーブが入る
• フォルトになる

サーブの結果としてはこんな感じかな。ポイントとしては、

• 球種はサーバーが決め、それはその時点で確定する。
• コースは、狙い自体はサーバーが決めるが、ある程度のぶれは出てくる。また、厳しいコースを狙った場合は、ブレ＝フォルトになる可能性が高い。
• 速度や回転（切れ）は元々のサーバーの能力以上の結果はあり得ず、どのくらいベストに近い球を打てるか、という問題になる。
• 当たり損ね、フォルトの種類（ネット、アウト）、レットによる打ち直しなんかは省略。

なんて感じ。

そのサーブに対するレシーバー。

• 読み or 反応 or フットワークが悪くて触れない（サービスエース）
• ぎりぎり追いついたがきちんとラケット面に当てられずにリターンが返らない
• ぎりぎり追いついたがスライス面で返すだけ
• 追いついたが苦しい体勢でリターン
• 追いついてフォアハンド or バックハンドで深くにリターン
• 追いついてフォアハンド or バックハンドで（ネットダッシュしてきた相手の）足下にリターン
• 追いついてフォアハンド or バックハンドで（ネットダッシュしてきた相手の）パッシングを狙う
• 予測が当たって攻撃的にリターン

このくらいのバリエーションでいいかなー。ポイントとしては、

• 読み＋反応＋フットワークでレシーブポジションに入れるかどうかが決まる。
• レシーブポジションへの入り方によって、レシーブの打ち方に制限が出る。
• ブロックリターン能力が高い場合は、ぎりぎり届いた場合もリターンを深くに押し戻すことができる。ブロックリターン能力が低いとリターンミスもしくは相手のチャンスボールになる。
• レシーブポジションへの入り方に余裕があるほど、レシーバーは攻撃的なリターンを選択することが可能になる
• 相手がベースラインにいる場合と、ネットダッシュしている場合とでは、レシーバーの行動選択肢が変わる。
• 事前の戦術選択肢＋実際にボールを打つ瞬間の状況によって、実際にボールを打つ瞬間の選択肢が決まってくる
• リターンも通常のストロークとショットバリエーションは基本的に変わらないが、ストロークとは別系統の、読み＋反応能力が必要。
• サーブは、通常のストロークよりも強力なショットになりがちなので、レシーブは通常のストロークよりも、ポジションに入ることが難しいことが多い。

なんて感じか。

サーブとレシーブを考えるだけでも、だいぶややこしくなってきたなー。

ストローク戦の方がもっとバリエーションが多いだろうから、ひとまずこのサーブとレシーブの考え方を下敷きに、ストローク戦に対するアプローチも考えていこう。

現状でサーブとレシーブに関して必要そうなパラメータを考えてみる。まずはサーブ。

• サーブの読みにくさ
• サーブの威力（主にフラットサーブのスピード）
• エース狙いのサーブのコースの厳しさ
• エース狙いのサーブの確率
• 入れにいくサーブの威力（セカンドにしては強いサーブが打てるか）
• 入れにいくサーブの打ちにくさ（読まれても叩きにくいサーブが打てるか）
• 入れにいくサーブの確率（これはいらないかなー。入れにいくサーブが入らないレベルまで考える必要はないだろう）
• 状況（重要なポイントなど）におけるメンタルへの影響

続いてレシーブ。

• サーブに対する読みの良さ
• レシーブ時の反応の良さ
• ブロックリターン能力（苦しい状態）
• 基本的なリターン能力（通常）
• 攻撃的なリターン能力（叩きにいったとき）
• 相手のネットダッシュに対する反応
• フォアハンドリターン能力
• バックハンドリターン能力
• 状況（重要なポイントなど）におけるメンタルへの影響

とひとまず考えてみたけれども、通常のストロークをどう扱うかを考えてからじゃないと、レシーブの扱い方は決めようがないな。レシーブはストロークの延長だからなー。

あと、今考えているのは絶対的な能力の高低を数値で表すイメージなんだけど、実際のテニスでは相手との相対評価の方が大きい場合もある。いわゆる相性の悪い相手の問題。

こういうのは、単なる数値の大小だけでなく、特定の能力を持つ相手に対する強さ・弱さを表現する仕組みを用意しないと、表現しきれないだろうか。工夫すれば、数値の大小だけで表現しきれるか？

テニスの数値育成シミュレーションゲームってないのかな？

ググってみる限りは、変なチーム戦の携帯ゲーっぽいものは見つけたけど、リアル志向の数値育成シミュレーションゲームは見かけていない。

バーチャテニス（パワースマッシュ）のツアーモードからアクションゲーム要素をなくして、もっとリアルな感じにするイメージ。

面白そうなのに。というか、あったら俺がやりたいのに。

ということで、自分で作ってみる前提でいろいろ考えてみる。

内容としては、自分の分身となるプレイヤーを作成し、その初期パラメータを調整し、トレーニング内容と参加大会によってパラメータを調整しつつ、試合結果によってランキングポイントをため、上位大会に出られる権利を得て、さらに上位ランキングを狙う。

カード集めゲーム的なものは嫌いなので、カードを集めて能力を向上させる的なものは基本なしの方向で。ただ、成長過程で取得できるバッジ（特殊能力付与）的なものはあってもいいかもしれない。

お金的なものは、あるべきかどうか悩みどころ。あるとしたら、収入は賞金とスポンサーからの資金。支出はツアーを回るための経費や、トレーニングメニューの向上など。

ラケットやシューズなどについては、あまり細かく扱う気はない。ただ、プレイスタイルごとに合わせた数種類のタイプくらいはあってもいいかもしれないか。この辺もスポンサーとかがあるなら、それとの絡みが出てくるな。

怪我という要素は、実際のツアーではかなり大きな要素なので入れておきたい。が、実際に長期離脱とかやっちゃうと面白くないだろうなー。長期離脱の代わりに、パラメータの大幅ダウンとかで表現するならありか？　それを食らうとかなりのショックだろうけど。

加齢という概念も入れておきたい。時間軸をどういうペースで扱うか、参加プレイヤーをすべて同一時間軸上に存在させるのか、とか根本的な問題があるけれども、それはひとまず置いておいて、加齢によるプレイヤーのパラメータ変動と、その結果としての引退による入れ替わりはあった方が面白い気がする。

野球シミュレーションならば、打率や打点、ホームラン数などの細かい数値情報が一通り見れないとつまらないのと同様に、テニスシミュレーションならば各試合ごとのStatistics（それもWinner/Unforced Error/Net Point Wonまで含めた）とかも見れないと面白くない。オールタイムのサーフェイスごとの勝率とかも見たいよな。

というか、ATPのサイトで確認できるようなデータが一通り見れるようになるのが理想。そこまで行ったらすごいだろうな。

となると、少なくともデータ上は細かいStatisticsが見れる程度の粒度のデータとしてシミュレーションを行う必要がある。さすがにHawkEyeのリプレイ（TennisTVで見られるような）並の細かいデータはいらないだろう。

というわけで、実際にテニスの試合をどういうデータを持たせて、どういうシミュレーションをするとそれっぽい結果データが出てくるのか、いろいろ考えてみているんだけど、なかなか設計が難しい。ほどほどのシンプルさで、それなりの表現力とリアリティがある感じに落とし込めるといいんだけど。

個人サイト制作者に、新たな収入源となり得るのか！？　クリックされる度に７６円の現金収入になる「秘密ボタン」について徹底調査まとめ！！ | APPGIGA!!（アプギガ）を読んで、昔考えた投げ銭のサービスを思い出したんで書いてみる。

普通にJavaScriptとかでボタンを貼り付けて、そのボタンをクリックすると投げ銭する仕組み。ただし基本的には、誰が誰にいくら投げ銭したのかだ けを記録しておき、特にその場で決済は必要ない。コンテンツ制作者には、「いくら投げ銭された」という金額が通知され、それがプールされていく（コンテンツ制作者には、「誰が」「いくら」投げ銭したか、という細かい情報は見えない方がいいと思う）。

そして、投げ銭した人 の気が向いて、後からその投げ銭サービスに対して入金したら、その金額分が、今まで投げ銭した分に対しての支払いに当てられる。今まで投げ銭した総額よりも多ければ、すべて支払いに充てられ、残った金額は後からの投げ銭支払い用にプールされる。もしも足りなければ、今まで投げ銭された分の一部の支払いに充当される。

ただし、特に入金を強制することはしない。必ずしも入金しなくてもいいと言うことは、コンテンツ制作者側にも投げ銭する人にも明確にしておく。だから、投 げ銭しっぱなしで入金せずに放置しておいてかまわない。入金しなくても、それはあくまでもバーチャルな金額という形で、コンテンツ制作者に対するポジティブなフィードバックとして伝わる。

昔Web日記の頃とか空メール（単に読んだと言うこと を通知するだけの本文のないメール）がくるだけでもそれなりに楽しかったし、別にお金じゃなくてもポジティブなフィードバックであると言うことが伝わるだけで、十分にコンテンツ制作者の報酬にはなり得る。しかもこの仕組みならば、コンテンツ制作者はもしかしたらそれが実際のお金に替わるかも、という期待感も持つことができる。

お金が絡むサービスは個人で運用したくないんで作らなかったけど、このくらいのゆるい投げ銭サービスだったら、もうちょっと使う人も増えるんじゃないかな。

って書き終わってから自分の日記を検索したら、「「へぇ」で投げ銭 」でもう似たようなことをすでに書いていた。こっちの方がもっと具体的な仕組みに踏み込んで書いてるな。

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!にはここ数年の遅れを取り戻すために、思いついたことはいろいろ試して盛り込んでいくつもり。