キーボードとともに押し入れから出てきたウィザードリィをプレイしようとインストールしたら、インストールそのものは成功するものの、どうにもゲームのプレイまで行きつかない。具体的には、＃４か＃５かを選択する画面で、どちらを選んでもエラーをはいて終了してしまうのだ。
こうなったらしょうがない。
早くSDLを覚えて、そのうちウィザードリィ風ゲームを作らなくちゃいけないだろう。
そんなわけで、いつものとおりcoLinux managerからcoLinuxを立ち上げるわけだけれども、やっぱり右クリックへの反応がいまいち…というか、右クリックメニューが出てこないことが多々ある。
そんなわけで、多少改造できないものかとソースをダウンロード。
誰もやってくれないので自分で改造してみることにした。
が、いろいろとファイル構造が複雑。
うーん。。。こんなのいじってられないなぁ。。。
ドキュメントもないし。。。
ということで、リビルドだけ通してみることに。
対象の.NET Frameworkを1.0→3.5にあげてリビルドしてみた。
いまのところ、右クリックへの反応がいまいちだった症状は改善されているように見える。
今後、どうしても困ることがあったら、より深くソースを見ていこう。
バルーンヒントのON/OFFぐらい調節できるようにしたいしな。
8.03.2008
矩形同士の当たり判定
ゲームには欠かせないね。
コリジョン判定ってやつ。
まだ矩形同士だけどｗ
そういえば、今は昔、SFC版ドンキーコングが神ゲームと称えられていた頃、ドンキーたちの当たり判定は、サルよりやや内側に切られた矩形での当たり判定だったなんて話を聞いたことがあるなぁ。（ソースはない。だから、記憶違いかもしれない。）
なるほど、あれだけアクション豊かなサルたちの当たり判定をどうやってるのか気になったけど、それなら解決できるのかと思った記憶が…。
そろそろテーブルゲームぐらいなら作れそうな予感。
さて、その話とは別に、キーボードが変わったわけだけど、さすがに1年以上触ってないと、US配列に戸惑うね。
アンダーバーとか、プラスとかマイナスとかコロンとかイコールとか、特に記号の入力で凡ミス連発。
特に多いのがカッコ。
微妙に位置がずれてるだけあって、意識しないで入力してしまうことが多々ある。
でもまぁ、この調子で毎日SDL使ったコードを書いてれば、すぐなれると思う。
それ以上に、Fキーが普通に利くことと、これまで利きの悪かったCtrlキー（正確にはCapsLockキー。日本語配列でも、こればっかりは入れ替えて使っていた）が、普通に聞くのはうれしい。
さっとしたタッチでもうまーく入力してくれて、さすがHHKといったところか。
どうしても困ったら、日本語配列のHHKを買おうかと思うけれど、たぶんないなぁ。
きっとこのままUS配列に慣らしちゃうんだろうな。
ともなれば、次にPCを購入するときはデスクトップか、ノートでもUS配列が選べるようにしないと、モバイルに不便だな…。
キーボードを持ち歩かないのは、HHKの理念からは外れてしまうんだろうけど（笑）
コリジョン判定ってやつ。
まだ矩形同士だけどｗ
そういえば、今は昔、SFC版ドンキーコングが神ゲームと称えられていた頃、ドンキーたちの当たり判定は、サルよりやや内側に切られた矩形での当たり判定だったなんて話を聞いたことがあるなぁ。（ソースはない。だから、記憶違いかもしれない。）
なるほど、あれだけアクション豊かなサルたちの当たり判定をどうやってるのか気になったけど、それなら解決できるのかと思った記憶が…。
そろそろテーブルゲームぐらいなら作れそうな予感。
さて、その話とは別に、キーボードが変わったわけだけど、さすがに1年以上触ってないと、US配列に戸惑うね。
アンダーバーとか、プラスとかマイナスとかコロンとかイコールとか、特に記号の入力で凡ミス連発。
特に多いのがカッコ。
微妙に位置がずれてるだけあって、意識しないで入力してしまうことが多々ある。
でもまぁ、この調子で毎日SDL使ったコードを書いてれば、すぐなれると思う。
それ以上に、Fキーが普通に利くことと、これまで利きの悪かったCtrlキー（正確にはCapsLockキー。日本語配列でも、こればっかりは入れ替えて使っていた）が、普通に聞くのはうれしい。
さっとしたタッチでもうまーく入力してくれて、さすがHHKといったところか。
どうしても困ったら、日本語配列のHHKを買おうかと思うけれど、たぶんないなぁ。
きっとこのままUS配列に慣らしちゃうんだろうな。
ともなれば、次にPCを購入するときはデスクトップか、ノートでもUS配列が選べるようにしないと、モバイルに不便だな…。
キーボードを持ち歩かないのは、HHKの理念からは外れてしまうんだろうけど（笑）
8.02.2008
Fキー対策
やっぱりFキーが聞かないのは不便。
たとえばEmacsの移動でもCtrl+Fを多用するし、私の場合、メールアドレスもFが入ってる。
Fが打てないor打ちにくいというのは、わたしにとって致命的なわけだ。
そこで、以前使っていたものの、諸般の事情から押し入れで眠っていたHHKLite２を引っ張り出してきた。
配列こそUS配列になってしまうけれど、2，3日もすればなれるだろう。
言うまでもなく、ノートパソコン標準のものよりずっとキータッチがいいし、Fが打てることで作業も快適になりそう…。
# あ、Debianのキーマップを変更しなくちゃいけないのか。
その必要はなかった。
よく考えてみれば、Putty経由で利用してるんだから、当たり前っちゃ当たり前なんだよね；
たとえばEmacsの移動でもCtrl+Fを多用するし、私の場合、メールアドレスもFが入ってる。
Fが打てないor打ちにくいというのは、わたしにとって致命的なわけだ。
そこで、以前使っていたものの、諸般の事情から押し入れで眠っていたHHKLite２を引っ張り出してきた。
配列こそUS配列になってしまうけれど、2，3日もすればなれるだろう。
言うまでもなく、ノートパソコン標準のものよりずっとキータッチがいいし、Fが打てることで作業も快適になりそう…。
その必要はなかった。
よく考えてみれば、Putty経由で利用してるんだから、当たり前っちゃ当たり前なんだよね；
周りは夏祭りに出かける中、涼しくコーディング。
SDL, Lesson16.
今回は画像を動かすという話。
キーボードの上下左右キーに対応して、画面内の丸が画面を動き回るというもの。
きちんとDotクラスを設計して処理してるから、たとえばニュートンの運動方程式（ma=F）に従って、落下運動をするボールのシミュレーションとかなら、すぐに書けそう。
背景はFillで白い矩形に塗りつぶしているけれども、別の画像に差し替えてもよさそう。
（カラーキーの項目でやったのを応用すればいい。）
あと、いい加減Fキーの利きにウンザリしてきた。。。。
どうにかならないものか？？
今回は画像を動かすという話。
キーボードの上下左右キーに対応して、画面内の丸が画面を動き回るというもの。
きちんとDotクラスを設計して処理してるから、たとえばニュートンの運動方程式（ma=F）に従って、落下運動をするボールのシミュレーションとかなら、すぐに書けそう。
背景はFillで白い矩形に塗りつぶしているけれども、別の画像に差し替えてもよさそう。
（カラーキーの項目でやったのを応用すればいい。）
あと、いい加減Fキーの利きにウンザリしてきた。。。。
どうにかならないものか？？
DirectX SDK を入れ替えてみる。
私にとって影響のありそうな変更はなかったものの、なんとなく気になったので入れてみる。
また400MB強をダウンロードしてしまった…。
おかげでWiiのバーチャルコンソールで落としたゼルダがだいぶ進んだ。
落としたら、前回同様Windowsにインストール→Linuxにコピー→Windows側のSDKを削除。
コンパイル＆リンクも問題なし。
前回と同じ内容のプログラムだが、stripしたら9KBというコンパクトサイズで実現できた。
（いや、DLLが下請けしてくれてるからってことなんだけど）
最近気になってるのが、coLinuxManagerの安定性。
0.7.0以降更新されていないみたいなんだけど、タスクトレイに常駐するのはいいものの、たまに右クリックメニューが出てこないことがある。
バルーンヒントのON/OFFも調整したいし、いじってみるかと思ってダウンロードしたら、ソースがC#だった。
…開発環境入れるのが面倒だから、とりあえず我慢しよう。
あと気になってるのが、キーボードのFキー。
たまに利かないことがある。
4年目で色々ガタが来てるし、そろそろ修理なり買換えなり考えないといけないんだけれども、そんなお金はないんだよなぁ…。
よし、そのうち考えよう。
また400MB強をダウンロードしてしまった…。
おかげでWiiのバーチャルコンソールで落としたゼルダがだいぶ進んだ。
落としたら、前回同様Windowsにインストール→Linuxにコピー→Windows側のSDKを削除。
コンパイル＆リンクも問題なし。
前回と同じ内容のプログラムだが、stripしたら9KBというコンパクトサイズで実現できた。
（いや、DLLが下請けしてくれてるからってことなんだけど）
最近気になってるのが、coLinuxManagerの安定性。
0.7.0以降更新されていないみたいなんだけど、タスクトレイに常駐するのはいいものの、たまに右クリックメニューが出てこないことがある。
バルーンヒントのON/OFFも調整したいし、いじってみるかと思ってダウンロードしたら、ソースがC#だった。
…開発環境入れるのが面倒だから、とりあえず我慢しよう。
あと気になってるのが、キーボードのFキー。
たまに利かないことがある。
4年目で色々ガタが来てるし、そろそろ修理なり買換えなり考えないといけないんだけれども、そんなお金はないんだよなぁ…。
よし、そのうち考えよう。
ムペンバ効果騒動、ここまでのまとめ。
スラッシュドットで話題になっていたので、ちょっと取り上げてみる。
（われらがボルツマンの敗北か！？と一瞬気になったのでｗ）
はじめに、ここまでのムペンバ効果に関する流れを整理しておくと
１．NHKのためしてガッテンにて、ムペンバ効果なる効果が取り上げられる。
２．大槻名誉教授のもとに、あれって本当なの？というメールが届く。
３．熱力学的にありえないだろｗｗｗと、大槻教授がブログで批判。
４．他ブログやニュースサイトでも取り上げられる。
５．NHKは何度か実験しましたと主張。ブログ読者からも、実験しないで批判とは何事かと、大槻教授が批判される。
６．大槻教授も実験。すると、NHKの主張とは違った結果がでた。
７．ためしてガッテンを監修した北大教授が、複数の条件下ではあり得ると反論。
８．日本雪氷学会が本格議論へ。
といったこところ。
私が考える、今回の一連の騒動でまずかったと思えるところは
・NHKは、まるでお湯のほうが（どんな場合にも）早く結氷するように報じてしまった。（条件を整えるとなるとか、確率的な現象であるという説明があったが、それはほんのオマケのようなものだった）
・科学の世界では謎というような、昨今の脱科学、似非科学、オカルト科学な風潮を煽る（具体的にいえば、大槻教授がかみつきやすい）報道をしてしまった。
・NHKが何度も実験したとする実験も、いくつか疑問点が残る実験だった。
・大槻教授は、ためしてガッテンを確認せずに実験／批判を行った。
といったところ。
一部ブログでは、本筋と離れたところから大槻教授の主張を批判したり、本筋とは全く関係ないところに突っ込みを入れてるようなブログもある様子。
#（お祭り好きの集まりみたいな状態になってるという印象。
きちんと議論するつもりは無いんだろうね。こういう人たちは。）
ひとつひとつ、問題点を紐解いていこうと思う。
まず、NHKがお湯のほうがどんな場合にも結氷するかのように報道したことについてだが、最近のテレビの流れだと、これは仕方なかったと思う。
でも、視聴者にそういう誤解を与えたならば、報道局として謝っておくのがいいんじゃないだろうか？
次に、似非科学風味な報道をしたということについてだが、これも昨今の報道スタイルとしては当たり前な気がする。（いつだかの、でんじろう先生を使った歯磨き粉のCMに関して書いたときと同じ気持ち。）
3番目に、NHKが何度も実験したとする実験についてだが、疑問点については後に挙げる参考サイトが詳しいので、そちらを参照してもらいたい。
最後に、大槻教授の行った実験のまずかった点だが
・70℃と17℃という、実験の前提条件から大きく外れた水で実験を行った
（Wikipediaによれば、この効果を確認するには、35℃と5℃の水で実験するのが望ましいとされる）
・東京都水道局のページに掲載されている、対流が結氷に影響を与えるような、深い製氷器を利用しなかった
・深い製氷装置としてペットボトルを選択してしまった。
（ムペンバ効果の（再）発見者とされるムペンバ君の報告では、熱のやり取りは水の界面を通じて行われるとのことだったので、口の小さいペットボトルでは、それほど良い成果が得られないと考えられる）
・実験条件を整えないまま実験して、批判してしまった
というところじゃないだろうか。
この問題について、私が言えることは、
お湯を作るにも、お湯を結氷させるにもエネルギーが必要で、そのエネルギーは、水を結氷させる場合より大きくなることは明らかであるから、エネルギー問題が叫ばれる昨今、ホイホイとやるのは良くないよねってこと。
いろいろ調べてたら、よくあるお祭り状態になっていて、結局どっちが正しくても、みんなかまわないんじゃないだろうかと思った。
だって、お湯を沸かし始める時間から結氷させれば、結局水を結氷させるのと同じぐらいの時間を使っちゃうんじゃないかなと思うし。
よくわからない結論になったけど、要するに大槻教授はもう少し問題をきちんと把握してから批判しましょうってことと、NHKは科学者に批判されないような報道を心がけましょうってこと。
お祭り騒動に疲れた方は、どうぞコメントにて身近な環境問題対策についてお話しください。
以下、参考サイト。
スラッシュドット・ジャパン
大槻教授のブログ
Wikipedia - ムペンバ効果
水のおもしろ実験「お湯のほうが先に凍る？」- 東京都水道局
Archives - ムペンバ効果調査中（１）
Archives - ムペンバ効果調査中（２）
Archives - ムペンバ効果調査中（３）
Archives - ムペンバ効果調査中（４）
（われらがボルツマンの敗北か！？と一瞬気になったのでｗ）
はじめに、ここまでのムペンバ効果に関する流れを整理しておくと
１．NHKのためしてガッテンにて、ムペンバ効果なる効果が取り上げられる。
２．大槻名誉教授のもとに、あれって本当なの？というメールが届く。
３．熱力学的にありえないだろｗｗｗと、大槻教授がブログで批判。
４．他ブログやニュースサイトでも取り上げられる。
５．NHKは何度か実験しましたと主張。ブログ読者からも、実験しないで批判とは何事かと、大槻教授が批判される。
６．大槻教授も実験。すると、NHKの主張とは違った結果がでた。
７．ためしてガッテンを監修した北大教授が、複数の条件下ではあり得ると反論。
８．日本雪氷学会が本格議論へ。
といったこところ。
私が考える、今回の一連の騒動でまずかったと思えるところは
・NHKは、まるでお湯のほうが（どんな場合にも）早く結氷するように報じてしまった。（条件を整えるとなるとか、確率的な現象であるという説明があったが、それはほんのオマケのようなものだった）
・科学の世界では謎というような、昨今の脱科学、似非科学、オカルト科学な風潮を煽る（具体的にいえば、大槻教授がかみつきやすい）報道をしてしまった。
・NHKが何度も実験したとする実験も、いくつか疑問点が残る実験だった。
・大槻教授は、ためしてガッテンを確認せずに実験／批判を行った。
といったところ。
一部ブログでは、本筋と離れたところから大槻教授の主張を批判したり、本筋とは全く関係ないところに突っ込みを入れてるようなブログもある様子。
#（お祭り好きの集まりみたいな状態になってるという印象。
きちんと議論するつもりは無いんだろうね。こういう人たちは。）
ひとつひとつ、問題点を紐解いていこうと思う。
まず、NHKがお湯のほうがどんな場合にも結氷するかのように報道したことについてだが、最近のテレビの流れだと、これは仕方なかったと思う。
でも、視聴者にそういう誤解を与えたならば、報道局として謝っておくのがいいんじゃないだろうか？
次に、似非科学風味な報道をしたということについてだが、これも昨今の報道スタイルとしては当たり前な気がする。（いつだかの、でんじろう先生を使った歯磨き粉のCMに関して書いたときと同じ気持ち。）
3番目に、NHKが何度も実験したとする実験についてだが、疑問点については後に挙げる参考サイトが詳しいので、そちらを参照してもらいたい。
最後に、大槻教授の行った実験のまずかった点だが
・70℃と17℃という、実験の前提条件から大きく外れた水で実験を行った
（Wikipediaによれば、この効果を確認するには、35℃と5℃の水で実験するのが望ましいとされる）
・東京都水道局のページに掲載されている、対流が結氷に影響を与えるような、深い製氷器を利用しなかった
・深い製氷装置としてペットボトルを選択してしまった。
（ムペンバ効果の（再）発見者とされるムペンバ君の報告では、熱のやり取りは水の界面を通じて行われるとのことだったので、口の小さいペットボトルでは、それほど良い成果が得られないと考えられる）
・実験条件を整えないまま実験して、批判してしまった
というところじゃないだろうか。
この問題について、私が言えることは、
お湯を作るにも、お湯を結氷させるにもエネルギーが必要で、そのエネルギーは、水を結氷させる場合より大きくなることは明らかであるから、エネルギー問題が叫ばれる昨今、ホイホイとやるのは良くないよねってこと。
いろいろ調べてたら、よくあるお祭り状態になっていて、結局どっちが正しくても、みんなかまわないんじゃないだろうかと思った。
だって、お湯を沸かし始める時間から結氷させれば、結局水を結氷させるのと同じぐらいの時間を使っちゃうんじゃないかなと思うし。
よくわからない結論になったけど、要するに大槻教授はもう少し問題をきちんと把握してから批判しましょうってことと、NHKは科学者に批判されないような報道を心がけましょうってこと。
お祭り騒動に疲れた方は、どうぞコメントにて身近な環境問題対策についてお話しください。
以下、参考サイト。
スラッシュドット・ジャパン
大槻教授のブログ
Wikipedia - ムペンバ効果
水のおもしろ実験「お湯のほうが先に凍る？」- 東京都水道局
Archives - ムペンバ効果調査中（１）
Archives - ムペンバ効果調査中（２）
Archives - ムペンバ効果調査中（３）
Archives - ムペンバ効果調査中（４）
8.01.2008
SDL + DirectX9 + Direct3D + MinGW + Debian/GNU Linux での、DirextX9アプリケーションのクロスコンパイル
フレームレートの計算ばっかりじゃ面白くないなぁと思っていたら、手が勝手に動いてました（笑）
8月一発目のネタがこれとはね。
そんなわけで、やたら長ったらしいタイトルの通り、ド変態クロスコンパイル環境に、さらに変態な環境を付け加えてみようという試み。
まず理解していただきたいのが、DirectXを利用することで、確かに最近の3DCGで話題な機能の恩恵を受けることができるものの、SDLを使う意味はほとんどないということ。
つまり、SDLの利点であるマルチプラットフォームとか、高い移植性とか、そういうのをガン無視できる人だけがやっていい裏ワザ的なものだということ。
（もしマルチプラットフォームを捨てたくないならば、素直にOpenGLを使うべきですよ）
それから、そんなにWindows環境に依存したアプリを書きたいというのなら、素直にクロスコンパイル環境じゃなくてVisual C++とかを使うべきだということ。
この辺を理解していないと、（理解していても）「？？？」が頭に残る展開になること請け合い。
まず、前準備としてDirectX 9 SDK（以下SDK）をダウンロードしておく。
（執筆時点での最新版はMarch 2008。ライブラリファイルを覗くと、すでにd3d10.libとかが用意されてる。違った。よく調べてみると、June 2008が最新らしい。時間があったら差し替えようか…。でも、そんなに大きな変更はないみたいだしなぁ…。悩むなぁ…。）
ダウンロードしておいたSDKを展開して、インストールを開始する。
入れるのはヘッダーとライブラリのセットだけ。
x86版に限れば（SDKにはx64版も付属している）、ヘッダーとライブラリを合わせてzip圧縮かければ、せいぜい3MBちょっと。
それに対してSDK全体の容量は圧縮時で400MB強、展開時で1GB弱。
なぜMicrosoftは必要なものだけダウンロードしてくれる、JavaSDKタイプのインストーラーにしなかったんだろうと小一時間考えたら、インストールしたヘッダーとライブラリをいつもの場所にコピー。
ヘッダーはめんどうならベタでコピーしてもいいけど、私はDXってディレクトリを新たに切って、そこに放りこみましたよ。（ライブラリはベタで放り込んだ）
いつもどおりの事だけど、ライブラリの変換作業とかそんなのは必要なかった。
いつからMinGWはこんなに進化したんだろう？
それが出来たら、チュートリアルサイトを見ながらコードを組む。
あ、WindowsにインストールしたSDKはもう必要ないから、削除してかまわないですよ。
出来上がったらコンパイル。
ここでもコンパイルコマンドには気をつける必要があって、
※ 必ずSDL関連ファイルを先頭に指定するというのがミソ。
あとはできたものをWindowsにコピーして実行すればOK。
サンプルそのままだと、全画面表示になるので注意。
ソースをみてもらえば分かると思うけど、コードはほとんどが通常のをDirectXを使ったプログラミングで使われるものがそのまま使われている。
というのも、DirectX自体、渡されたウィンドウハンドルを持つウィンドウに描画を行うかららしい。
だから実は、SDLで作られていようが、WinAPI直叩きで作られていようが、DirectXさんにとっては何の関係もないものということだ。
それなら私は、ウィンドウ生成が楽チンなSDLを選ぶなぁ。実行時にDLLが必要って手間はあるけどさ。
そうそう、コンパイルしたバイナリを動かすには、最新のDirectXランタイムが必要だから、動かない場合はそちらをインストールするとよさげ。
8月一発目のネタがこれとはね。
そんなわけで、やたら長ったらしいタイトルの通り、ド変態クロスコンパイル環境に、さらに変態な環境を付け加えてみようという試み。
まず理解していただきたいのが、DirectXを利用することで、確かに最近の3DCGで話題な機能の恩恵を受けることができるものの、SDLを使う意味はほとんどないということ。
つまり、SDLの利点であるマルチプラットフォームとか、高い移植性とか、そういうのをガン無視できる人だけがやっていい裏ワザ的なものだということ。
（もしマルチプラットフォームを捨てたくないならば、素直にOpenGLを使うべきですよ）
それから、そんなにWindows環境に依存したアプリを書きたいというのなら、素直にクロスコンパイル環境じゃなくてVisual C++とかを使うべきだということ。
この辺を理解していないと、（理解していても）「？？？」が頭に残る展開になること請け合い。
まず、前準備としてDirectX 9 SDK（以下SDK）をダウンロードしておく。
（
ダウンロードしておいたSDKを展開して、インストールを開始する。
入れるのはヘッダーとライブラリのセットだけ。
x86版に限れば（SDKにはx64版も付属している）、ヘッダーとライブラリを合わせてzip圧縮かければ、せいぜい3MBちょっと。
それに対してSDK全体の容量は圧縮時で400MB強、展開時で1GB弱。
なぜMicrosoftは必要なものだけダウンロードしてくれる、JavaSDKタイプのインストーラーにしなかったんだろうと小一時間考えたら、インストールしたヘッダーとライブラリをいつもの場所にコピー。
ヘッダーはめんどうならベタでコピーしてもいいけど、私はDXってディレクトリを新たに切って、そこに放りこみましたよ。（ライブラリはベタで放り込んだ）
いつもどおりの事だけど、ライブラリの変換作業とかそんなのは必要なかった。
いつからMinGWはこんなに進化したんだろう？
それが出来たら、チュートリアルサイトを見ながらコードを組む。
あ、WindowsにインストールしたSDKはもう必要ないから、削除してかまわないですよ。
出来上がったらコンパイル。
ここでもコンパイルコマンドには気をつける必要があって、
mingw-c++ filename -lmingw32 -lSDLmain -lSDL -ld3d9 -ld3dx9 -mwindowsのように指定する必要がある。
※ 必ずSDL関連ファイルを先頭に指定するというのがミソ。
あとはできたものをWindowsにコピーして実行すればOK。
サンプルそのままだと、全画面表示になるので注意。
ソースをみてもらえば分かると思うけど、コードはほとんどが通常のをDirectXを使ったプログラミングで使われるものがそのまま使われている。
というのも、DirectX自体、渡されたウィンドウハンドルを持つウィンドウに描画を行うかららしい。
だから実は、SDLで作られていようが、WinAPI直叩きで作られていようが、DirectXさんにとっては何の関係もないものということだ。
それなら私は、ウィンドウ生成が楽チンなSDLを選ぶなぁ。実行時にDLLが必要って手間はあるけどさ。
そうそう、コンパイルしたバイナリを動かすには、最新のDirectXランタイムが必要だから、動かない場合はそちらをインストールするとよさげ。
登録:
投稿 (Atom)