コグノスケ

11/23現在、未だGoogle先生に捕捉されていない奇跡。できればこのままそっとしておいていただきたいね。
昨日に引き続きNTPの話です。Ring Server ProjectがNTPサービスを提供しているようです。適当なNTPサーバが見つからないなあとお困りのあなたはntp.ring.gr.jpを使ってみると良いでしょう。
研究室のNTPサーバの同期先をネット研（stratum 3、hakobe（学情）またはmfeedと同期）から SINET（stratum 1、GPSかな？）に変更しました。これはSINET利用機関専用のNTPサービスで、研究室から使って良いのか不明です。筑波大学の内部組織もまたSINET利用機関と言えるのか？という点がはっきりすれば解決します…。
実は hakobe.cc.tsukuba.ac.jp（学情のNTPサーバ、stratum 2）が使えれば一番楽です。はい。でもこれも勝手に使って良いのですか？誰か知りませんか？

話は変わって我が家のサーバについて。favicon.icoがないぞ、というエラーが溜まりまくってうっとおしいためルート（/var/www/）にfavicon.icoを追加しました。今のアイコンは適当です。そのうち差し替えます。
みなさんには関係ありませんがもう1つ。必要性を感じないため suEXECを無効にしました。参照:How to disable suexec of Apache.にDebian流の方法が載っています。Apache2系は初めからsuEXECが無効なようですね。

パソコンの時計は勝手にどんどんずれていきます。放って置くと1分くらいずれていることもしばしばです。
そこでNTPという時計合わせのためのプロトコルを用います。我が家ではntp.jst.mfeed.ad.jp（stratum 2）とバックアップにWAKWAK（stratum 3）のNTPサーバと同期しています。NTPで時刻の同期を行う場合、上の階層のサーバに負担をかけないように注意しましょう。
具体的には家の中の1台だけを上位のサーバと同期させ、他のマシンはその1台と同期させるようにします。だからってうちのサーバを使わないでね…しょぼいマシンなんでいじめないでください…。

JoyToKeyもどきはWTLを使って作り直すことにしました。GUIと関係ないロジック部分は使いまわしです。
というわけで今日は WTLを使ったGUIプログラミングに悪戦苦闘です。MFCの概念に慣れていないことや、WTLにはリファレンスがないことが相まって、わからないことだらけです。
Google先生で先人の知恵を借りる、ヘッダファイルを検索して関数を見つけるなどして粘ってます。せめてもの救いは Win32 APIと似た名前が多く関数名のアタリをつけやすいことかなあ。

情報システムデザイン論のレポートをやりました。UMLを手書きにしたら手が冷たくなりすぎて字が書けません。でもキーボードはちゃっちゃと打てます。昔は指が動かなくなると打ち間違いが増えてイライラしていたものですが、ブラインドタッチでかなり変わったなあ。
JoyToKeyもどきを改善中です。ファイル管理の部分を追加しました。具体的にいうとメモ帳の新規作成、とか保存とか開くとかの部分にあたります。このプログラムには悩みどころがあって、ジョイスティックの入力をキーボードやマウスの入力に変換する基本部分は割とすっきりしているのに、 GUIの部分が超やっつけ仕事なのです。直すとなると簡単なGUIライブラリを使いたいところです。
アプリケーションを作成する際に、ライブラリをどうするかは悩みどころです。学生なら、勉強として一から作ろうという見方もありますが、企業などならば車輪の再発明なんて時間の無駄ですから、迷わずWTLなど既存の優れたライブラリを使うでしょう。さて私はというと、作りたいという興味と面倒だなあという気持ちがぶつかり合って微妙な状態です。

昨日、寒いしたまにはシャワーじゃなくて湯船に漬かろうかなーと思って、風呂に入ったら死にそうに気持ち悪くなって、景色が暗転しました。やばそうだけど頑張って頭とか全部洗ってからあがったら、目の前が真っ暗になりました。な、何これぇ〜。根性で椅子まで辿り着いて、何とか気絶は回避しました。あんなぬるいのに湯あたりするとは思いませんでした。
って、昨日のエントリに追加しようと思ったら、大下さんも今日偶然にそうなったらしいので今日のとこに移動です。俺は気絶まではしていないけど奇遇です。お互い怪我せずに済んで良かったねえ。

全体ゼミで次は気をつけてね、見たいな事を言われました。明日ドコモの人にもお詫びのメールを出しておこう…。
若者敬語とかはどうでもいいのですが、単語の誤用は元の意味を知っていると気になります。例えば以下の文章を読んで「え？」と思う人は居ませんか？
「部長から与えられた仕事は、私では役不足です。部長にその事を直訴する前に親友に相談しようと思います。彼は気の置けない相手ですから、率直な意見を述べてくれると思います。」

この文章で「え？」って思った人は、昔の私と同じでいつかどこかで誤用するでしょう。
辞書を引いた人（※）はわかったはずです。文書は日本語としては間違っていませんが、言い換えればこうなります。
「部長から与えられた仕事は、私では「役目が簡単すぎ（るため不満）」です。部長にその事を直訴する前に親友に相談しようと思います。彼は「気を許して付き合える相手」ですから、率直な意見を述べてくれると思います。」
まあ、こういう誤用の多い言葉はそのうち誰も使わなくなって消えます。
※我が家の辞書（三省堂　新明解国語辞典　第四版）には「気の置けない」の項目に「気を許せぬ相手」という意味が（誤用からきた意味である、という注釈付きだが）載っています。元の意味が消える日も近いかもしれません。

家でセミナーのQAレポートをまとめていたら、阿部さんから電話がかかってきました。電話で「今日ドコモのミーティングなんだけど…」と言われて、初めて思い出す始末。もちろん準備もしていなかったため、駆けつけても意味がない。スケジュールにメモってあったのに度忘れするなんて初めてです。ぬかったあ。

東京国立博物館の北斎展に行きました。楽しかったのですが、版画作品は意外と小さくてちょっとがっかりしました。富嶽三十六景ってもっと大きい絵だと思いこんでいました。展示数が多すぎて見切れませんでした。
帰りの常磐線南千住駅で、電車が急ブレーキかけて止まったので何事かと思ったら、オーバーランしていました。自分はオーバーラン初体験で大層おどろきましたが、周りの人はそうでもない様子です。もしかしてオーバーランって頻繁に起きてるの？
薔薇絵亭で晩御飯を食べました。うまうま。上野駅で買った 1個300円もするプリンを2個一気に食ってやりました。うまうま。

授業に行って、研究室に行って、家に帰って、寝た。

じょーと桜のバーIssaに行きました。カクテル3杯くらいで6000円。学生が通うと考えるとお高い値段です。その後、田口邸に行き残っていたジョニ黒を飲みました。ウイスキーってのどがイーーッってなりませんか？そういえばIssaで飲んだボウモアは後味がすっきりしていました。あれ高いんだろうな。
Sunのやつは今日だったらしい。すっかり忘れていました。まあ自由参加だからいいのかな。

石岡市のダチョウ王国に行きました。ダチョウ肉を食するのと、動物と触れ合う「南のまきば」がメイン（たぶん）です。南のまきばではヤギが脱走していました。従業員のお姉さんが追いかけていたけど戻せず、別の従業員のおっさんは「あーヤギ？いいよほっといてー」って言い放っていました。で、本当に放置されていました。ヤギが枠の外にいるのに、客も従業員も誰も気にしちゃいない。ここはのどかだなあ。
その後、同じく石岡市の常陸風土記の丘でに行き、ずっと売店で買ったおもちゃで遊んでいました。手で引っ張るとプロペラが飛んでいく竹とんぼみたいなおもちゃです。最後は色々あって、全部壊れました。ありがとう200円のおもちゃ×2よ。
八郷町のやさと温泉ゆりの郷というところで、温泉に浸かり、晩御飯を食べて、じょーんところにお見舞いに寄ってから解散しました。
メンバー）北脇、小磯、鈴木、田口、山下、結城（敬称略、五十音順）

ビジーウェイトなしに正確な時間待つ関数を作るには？
昨日の続きです。負荷に応じて切り替える手法は、良さそうに見えて実は高負荷かどうか？という判定が意外に難しいことに気づきます。もっと単純かつ効果的なのはポーリングしているスレッドの優先度を1〜2段階上げることです。
既に知っている人は昨日の日記を読みながら、何だそれしきの事とニヤニヤしていたかな。うそ？それだけ？って思った人は実際にやってみて体感してください。キーワードはSetThreadPriority() です。
バックグラウンドで動かすなら、ポーリングの間隔は10ms以上が良いと思います。1msだと頻繁に起こるスイッチングの負担で他のアプリケーションが遅くなります。あくまでもこれは我が家のマシンでの体感です。他の環境だともっと間隔をあけなければならないかもしれません。
代替わりコンパに行きました。知らない顔がかなり増えていてびっくりですよ。せめて作業くらいは顔を出そうかな、と思いました。

たまには読まれもしない長文を書いてみようかなーっとぉ！（直ってない）

JoyToKeyもどきでは、デバイスを1ms間隔でポーリングしています。そのためには1ms経つまで帰ってこない関数が必要になります。現在の実装ではSleepとtimeBeginPeriodを使って（※）います。なぜなら、負荷が低い状態ならばSleep(1); はほぼ1[ms] で帰ってくるし、これによりCPUをアイドル状態にでき、電気代の節約にもなるためです。一石二鳥なのです。
しかしこのソフトを使うときはゲームしていることが多いため、ゲーム側で高い負荷がかかる事があります。高負荷時にはSleep(n); はn[ms] では帰りません。高負荷時にはSleep(1); が10msとか20ms後に帰ってくることもザラです。

Sleepとは現在このスレッドは暇だから、指定した時間が「過ぎるまで」他のスレッドにCPU時間を譲りますよ、とOSに教える事です。そのため自分以外に高い負荷がかかるスレッド（つまりゲーム）がいれば、Sleepを呼んだスレッドに制御を戻すのを遅らせてでも、高負荷のスレッドにCPU時間を割り当てるのは当然の動きです。低負荷ならばSleep(n); がn[ms] で帰ってくる傾向がある、というだけで常にSleep(n); がn[ms] で帰ってくることは誰も保証していないのです。
Sleepを嫌うとビジーウェイト（時間がたつまでループして待つ）ことになりますが、JoyToKeyもどきがCPU 100％食うようなアプリケーションだと嫌ですよね？…どうでもいい？チッ、皆が良くても俺は嫌なんです。

これは今作っているアプリケーションに限った問題ではなく、数msごと処理を実行するという部分があれば必ず出る問題です。ビジーウェイトなしに正確な時間待つ関数を作れれば、有用だと考えます。
現在考えているのは、低負荷時にはSleepを使い、高負荷時にはビジーウェイトに切り替える関数です。予想される弱点としては、低負荷時にSleepを使って待つため一時的に高負荷になるとSleepがデッドラインを超えてしまう可能性があることです。ゲームに用いると一時的な負荷で激しく処理落ちする欠陥と言われそうですが、JoyToKeyもどきには妥当な落としどころでしょう。実装できたらまた書きます。誰もここまで読んでないだろうけど、次回をお楽しみに。
※WindowsはtimeBeginPeriod(1); を呼ぶとなぜかSleepの分解能も変わります。この副作用は昔からあるようです。とりあえず呼んどけ。

セミナー発表が終わりました。その後の全体ゼミで、先生から昨日と比べるとだいぶよくなったと言われ嬉しかったです。
もうひとつ、発表のときに「ここはこうなります…っと」のような変な語尾（たぶん次のページに移る時に言う）はやめた方が良いと指摘されました。「はい、気をつけます」と返事したものの、無意識なので直らないかもしれないです。