EmptyRoom

鯖を立てるに当たって、やっぱり固定IPじゃないとダメなような気がした。
固定IPじゃないと、いつ自分のルータのIPアドレスが変わるかわからないからだ。
そこで、So-net(自分の使っているプロバイダ)の固定IPサービスを見てみたんだが、

月額 1260円

…うえぇー、ちょっと高いな。
と、思ったら、ダイナミックDNSサービスがあるではないか。
どうやら、IPが変わっても、自動的にDNSに登録しなおしてくれるらしい。
しかも、月額210円とな！や、安い！
こ、これだ！これしかねぇ！
…と思ったんだけど、WWW以外では使えないとのこと…
なんだよそれー。
まぁ、確かにHTTPでほとんど出来るもんだけど、納得いかねぇ…

ん？ ピコーン！ひ、閃いたぞ！

このサービスと、今使ってるDynDNSの合わせ技で良いんじゃないのか！？

IPアドレスが変わる
↓
DynDNSで登録したアドレスではアクセス不能になる
でも、So-netで登録した方はHTTPでだけだがアクセス可能
↓
nslookup(IPアドレスの正引き)で、IPアドレスゲット
↓
DynDNSで登録し直す。
↓
ウマー

うほっ！これなら月額210円でHTTP以外のプロトコルも使えるじゃん！
俺、頭良いな！(マジか

でも、理想を言えば、IPアドレスが変わった瞬間に、
メールか何かで新しいIPアドレスを自動通達してくれるのが
一番良いんだけどね…できるのかな、そういうこと。


注)nslookupについて。
Windowsならコマンドプロンプトを開いて試しに
nslookup www.yahoo.co.jp
と入力してみると、Yahoo鯖のIPアドレスがずらーって出てくる。
あと、 ここでも調べることが出来る。
逆に、IPアドレスからドメイン名を調べるwhoisコマンドもある。
…けど、Windowsじゃ動かないのか…
ここでどうぞ。

WindowsXP上でApache鯖(Web Server)が出来ました。
SuSE Linux上でもやったんだけど、
なぜかlocalhosotでしかページが表示出来ない…orz
要研究。

っていうか、もう楽だからWindowsで良いかな、鯖構築(ぉ


ところで、 Rioの製品が価格改正するみたいで、
ちょこっと見てみたんですが、

Live airがすごいことになってます…

なにこの値下げ率。

旧値段の39800円って、ワシが以前使ってた YAMAHA MSP-5に肉薄しそうな値段なんだけど、それが、5980円ですか…
(まぁ、MSP-5の方は店で買った値段だけど…)

なんか、すげぇ欲しくなってきたぞ(ぉ

だ、誰か人柱キボン！

気に入ったら、TV、ゲーム用に一台買っちゃうかも！
(値段相応の音がすればいいなぁ。)

PHP日記システムを軽量化してみました。
軽量化アルゴリズムは前日の日記の1番、本文の文字数を記録する方法。
コメントの方もこのアルゴリズムを採用しました。

ですが！

現在のPHP日記システムのレスポンスが今より明らかに遅くなるまで、
アップデートはしないことにします！(えぇぇぇぇぇぇ


…おかしいなぁ…
あの日記書いてる付近では確かにレスポンスが遅かったんだけどなぁ…

さて、結構な頻度でワシの日記ページを見ている人なら、
もしかしたら気づいているかもしれない。

日記ページだけ他のページよりレスポンスが遅い

という事に。
いつかこうなることはわかってた。
でも、どのくらいの量のテキストを読ませるとレスポンスが下がるのか知りたかった。
ということで、今まで放置していたんだけど、
そろそろ本格的に日記システムの軽量化について考察しなければならないようだ。

今の記録形式は単純なものだ。

<>日記No.<>日付<>タイトル<>本文<>(改行)

のような感じになっていて、"<>"が各データの区切り文字になっている。
そして、1行が1日分の日記になってる。
各データの取得は文字を一文字一文字比較して区切り文字の間だけを
データとして得られるようにプログラムを組んである。
おそらく、これが遅い。
単純に考えて文字数の分だけループが回ってるのだから。
(現在、ログファイルのサイズは130KBくらいなので、
少なくとも13万回以上、ループが回っていると考えられる。)

ファイルを開くのに時間が掛かる説もあるけど、
ログファイルは数百KBしかないからこれはおそらく白。
(いずれこれがネックになる日が来るのだろうが、相当先。)

レスポンスを改善する手段として、

1.最もループ回数が多い"本文"の文字数をあらかじめデータに書き込んでおく。
(一文字一文字ループを回して区切り文字と比較する必要が無くなる。)

2.ログファイルの情報(登録件数、No.xxの日記は何行目に書かれているか等)
を書き込んであるファイルを別途出力し、
それを参照して読み込むデータ量を最小にする。

3.最もアクセス数の多い日記の最初に表示されるページをHTML化しておく。
(日記の更新、コメントの投稿のたびにHTMLを出力する。)

4.過去の日記と最近の日記でログファイルを分割する。

5.SQLなどのデータベース技術を導入する。

おそらく、今回、一番現実的な方法は1番と2番のコンビだろう。
一つだけ選ぶなら、1番かな…
プログラム的に楽なのは1番。
ただ、ログファイルの互換性が失われるので、
ログファイルコンバータを自作する必要がある。
(大して難しくはないけど…)

3番はレスポンス改善というよりは、サーバ負荷の改善だな…
4番はデータが散乱するので嫌。
5番は下手すると1から作り直しになるし、覚えなくちゃならないことが増える。

こういう事をやるたびに思うことは、
「プログラミングは構想しているときが一番楽しい」
ということだな…
動いたときも楽しいけどさぁ…

さて、TBSですごい放送事故がありましたね…
今日はその子細にでも。

始まりは25日25:55。
・野球中止により苺ましまろは25:55から放送される予定だった。

・苺ましまろの前に台風情報をはさみ、アニメは26:00から放送される
と、TBSオフィシャルに情報が掲載される。

・25:55 台風情報が放送される。

・25:58 突然OP無しでいきなり苺ましまろが始まる。

(ここで、TBS情報を信じた録画組が死亡)

・さらにAパートの途中で いきなりニュースがはさまる。
「先ほどは失礼しました。」で始まる。
これはアニメを中断したことを謝罪してるわけでは無いところに注意。
(台風情報を十分に伝えられなくて)失礼しました。の意。

・Bパートは普通に放送されるものの、ニュースにより遅れていたため、
25:55から録画予約した人はここでラスト数分が切れることに。

・結局アニメに関する謝罪は一切無し。

・TBSオフィシャルに
「苺ましまろ延長のため、青木さやかの〜は5分繰り下げで〜」
と書かれる。印象が非常に悪い。アニメが延長って初めて聞いたよ…

・スポンサーからの苦情か(？)再放送決定。

まぁ、再放送してくれるだけでも良心的かと思うが、謝罪無しなのはいかがなものか。

そして、26日21時頃放送事故が起こる。
Yahooの記事
朝日の記事
(実は21時だけでなく、19時頃からカラーバーが出たり、おかしかった。)

この事故で中断された分の謝罪は24時現在確認してない。
ニュース23でもこの放送事故が無かったかのように始まる。
「野球延長により15分繰り下げでお送りします。」で始まった。
放送事故を無かったことにしようとしているように思える。

なんつーか、ここまで 視聴者をバカにしている局も無いんじゃなかろうか…