ところが自分が書いたコメントが反映されません。
コメントの一覧にも見あたらないと思ったら、、迷惑コメントに放り込まれてました…
原因は、自分が設定したキーワード。貼り付けたURLが引っかかったようです。
あんまり、大きな網をかけるものじゃないですね…
自分で設定して、自分が引っかかっているんじゃ世話がない…
最近は、こちらのDNSBLを試してます。
統合スパムフィルタ「スパムちゃんぷるー」のデータに基づくDNSBL(β)
効果は、まだよくわからないです。効いてる気はするんですが。
さて、次、更新するのはいつだろう…
パソコンの調子が悪いので、再起動したら…
次のファイルが存在しないかまたは壊れているため、Windows を起動できませんでした: \WINNT\SYSTEM32\CONFIG\SYSTEM
みたいなメッセージで、Windows2000が起動しません。
回復コンソールで、レジストリを初期状態に戻せばいいようなので、試してみたら、
C:\> dirディレクトリを列挙するときにエラーが発生しました
となってしまいます。よく考えてみたら、BigDriveのHDDでした。Windows2000のインストールディスクは、BigDriveを扱えないんですよね。
仕方がないので、HDDを外して、他のマシンにHDDを直接つないで、いじろうとしたんですが…
なんと、IDEケーブルをさしたとき変な音がしたと思ったら、HDDのピンが一本ちゃんとはまらないままIDEケーブルを差しんでしまい、1本ピンを押し込んで基盤からはがしてしまいました…
余計な仕事を増やして、状況を悪化させている自分がイヤになります。
青くなって固まっていても仕方ないので、半田ごてを取り出してきて、はがれたピンを半田付け。
半田がブリッジしたりして、苦労した以外は問題なく作業は終わり、復旧しました。大事に至らなくて、やれやれです。
さすがに、HDDに半田ごてを当てたのは、初めてです。
エラー メッセージ : 次のファイルが存在しないかまたは壊れているため、Windows を起動できませんでした: \Winnt\System32\Config\Systemced
このページを参考にして、他のPCに直接HDDをつないで、C:\WINNT\system32\repair\system にある初期状態のシステムハイブファイルを、C:\WINNT\system32\config に持ってきて、再びHDDを元のPCに戻し、起動してみると、ブルースクリーンで駄目。
INACCESSIBLE BOOT_DEVICEとなります。
よく考えてみたら、初期状態だとBigDriveは扱えないんですよね。たぶんこれが原因。
このあたりで、修復インストールを考えましたが、結局、インストールディスクは、BigDriveに対応してないからだめです。
事実かわかりませんが、システムパーティションのサイズを小さくしてあっても、システムパーティション以外のパーティションが破壊される可能性があるという話を見つけて、修復インストールは躊躇しました。
一か八か試してみる気には、とてもなれません。
念のため、Windows2000 SP4のインストールディスクを作成して、回復コンソールを試してみましたが、結局駄目でした。
どうやら、システムハイブが大きすぎるのが問題のようなので、
「クラスタ サービスが LANMANSERVER のファイル共有エントリを削除しない」を参考にして、
別のWindows2000マシンに、システムハイブファイルをコピーして、システムハイブの縮小を試みました。
しかし、ファイルが壊れているといって、レジストリエディタが読み込んでくれません。
WindowsXPのレジストリエディタは読んでくれるんですが、アクセス拒否になってしまい、レジストリキーを消せません。たぶん手順が間違っていたんでしょう。
修復セットアップは無理、システムハイブファイルは小さくならない、と八方ふさがりです。
悩んだあげく、WindowsXPのレジストリエディタで、ハイブを読み込み、それを何もせずに、「レジストリ ハイブ ファイル」形式で、エクスポートしてやりました。
そうしたら、それだけでファイルが小さくなったんで、元のマシンのC:\WINNT\system32\config に置いてやって、HDDを元のマシンに戻して起動したら、元通りになりました。
やれやれです。
収穫としては、システムハイブのサイズを縮小する方法がわかったことと、WindowsXPのレジストリエディタが出力したものを、Windows2000が扱えるということがわかったことですかね。
ピンをはがしたのは、完全に余分なことでした…
なお、真似して、どうかなっても責任は持てません(^^;
スラッシュドット ジャパン | データをすべてファイル名扱いにして高速検索を実現?
HOWS「ISSEI(イッセイ)」:ITpro
既存のRDBの限界を超える、高速検索が出来るようにデータの全てをファイル名に入れる事にした検索技術を作ったというものです。OSの機能で高速検索できると主張しているわけですが。
最初は、何か利点になるポイントがあるんだと思って読んでいったんですが...
つっこみどころが満載で、どこからつっこんでいいやら困ってしまいます。ジョーク記事かと思いました。
すくなくとも、解説を読む限りはつっこみどころ満載です。
世の中、解説だけがでたらめということはあるので。(これがそれだけの話とは正直思えないですが)
とりあえず、他の人たちもつっこんでいるように、「ストップウオッチ片手に高速化を追求」というところは、つっこんでおかないといけないでしょうね。なぜストップウオッチ…
OSの基本機能であるファイル名の検索機能を用いることで、ハードディスク内のファイル本体にアクセスせず高速に検索できるのが特徴だ
ファイル名の情報も、ハードディスク上にあると思うのは私の勘違いなのでしょうか?
なにか、ファイル名を取ってくるのは、どんなときでも高速であるという思いこみがあるような気がします。
そもそもファイル検索機能というのが何をさすのか、よくわからないのですが、Windowsのファイル検索のことなんでしょうか。
あれだって高速化するには、インデックスつけたりするわけでDBと同じ事なんですが。
つまり、結局、Windowsのファイル検索は速いよ、ということですか。
検索対象は、このファイル名の集合体。この方法によって、ハードディスクに保存されているファイル本体にアクセスすることなく、メモリーにキャッシュされたファイル名群を検索することで高速化を図っている。
なるほど。メモリに持っておくから速いんですね。
でも、ファイル名としてデータを保存するから速いんではなかったんでしたっけ?
結局、ファイル検索ってなに…?キャッシュとは普通のディスクキャッシュのことなんでしょうか?
それこそ、単にOSの機能では?
従来のDBは、
「ファイルの入出力にかかる時間がボトルネックで、検索速度が上がらないとの問題を抱えていた」というんですが、そこから、なぜ、ファイルの中身を読まずにファイル名だけ読めばよいという発想に至るのかよくわかりません。ファイル作成や、ファイル名の取得はボトルネックにならないと思ったのでしょうか?
次はOSメーカーと共同開発し、ISSEIをOSの標準機能として盛り込みたい。最終的にはISSEI専用チップをメーカーと開発するのが目標だ
OSの機能をそのまま借りるのが利点だという主張なのに、なぜ専用チップですか。
これは、他と比べて、非常にわかりやすいつっこみどころですね。
このままつっこみ続けると、全文引用してしまいそうなのでこの辺で。
「ゼロベースで発想」したそうですが、どういう意味でゼロだったのか…
ファイル名にプログラムから利用される何らかの情報を持たせるということは、普通にあります。有効な場面もあるでしょう。
でも、そういうのは、62進数で全部のデータをファイル名に入れるとか言う話とは違う話ですし、新技術とか言うものではありません。
とにかく、この技術がたとえ本当に速かったとしても、すごいのはMicrosoftなわけです。
ファイルシステム、ファイル検索といった、「既存のDB」を使っているだけなのですから。
書くべきか迷いましたが、あんまりな話なので書かずにいられなかったです。
なんというか、トホホな話です…
追記:
改めて、何に違和感があるのか考えてみると、引っかかっているのは単に技術的に変とかいうことではないんですよね。
自分はそこに着目しがちですが、記事だけでは詳細まではわかりませんし。
まあ、記事の書き方自体がなにか変なのは確かですが…
用途は限られるでしょうけど、ファイル検索機能に検索させるということ自体は、(もしかしたら)状況によっては意味があるかもしれない。
(Google Desktop Searchとかの方がいい気はしますが)
でも、新技術とか、既存のDB技術と一線を画すとか、革新的とかいう話じゃない。(一番大事なところが借り物)
そこのところに引っかかるんでしょう。
さて、HDD交換のついでにRAID1を組んだわけですが、そのときの操作をメモを兼ねて書いておくことにします。
RAID構築後に、以下のように、一度RAIDを停止させた場合。
# mdadm -S /dev/md1
次に、再びRAIDとして編成するときにどうするか。
ちゃんと調べないで停止させてしまったので、あわてて調べる羽目に。
最初は、こうやりましたが、うまく行きません。
# mdadm -A /dev/md1
/dev/md1 は編成されたRAIDアレイが使うデバイス名ですが、そのアレイの構成要素となるデバイス(/dev/hda1など)を識別する情報がないということなんでしょう。
結局、以下のようにして、まず、RAIDアレイのUUIDを調べ、
# mdadm -E /dev/hda1
その後、そのUUIDを指定して、一つ一つ編成しました。
# mdadm -A /dev/md1 -u xxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx
ここまでが、実際の作業で使った方法。
結局、後で調べたらもっとやりやすい方法があったわけです。
まず、/etc/mdadm.conf に以下のように、RAIDアレイを探す対象のデバイスを書きます
DEVICE /dev/hda* /dev/hdb* /dev/hdc* /dev/hdd*
そして、以下を実行すると、既存のRAIDアレイを編成するのに必要な情報が出てきます。
# mdadm -E --scan
ARRAY /dev/md2 level=raid1 num-devices=2 UUID=xxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=xxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx
これは、そのままmdadm.confで使える形式なので、以下のように/etc/mdadm.conf に追記します。
# mdadm -E --scan >> /etc/mdadm.conf
この後、以下のようにすれば、既存のRAIDアレイが編成されます。
# mdadm -A --scan
ただ、このやり方は実際には試せてないんですが…
ここまではソフトウェア的な話ですが、ここからはハードウェア的な話。
ミラーリングなのでHDDを2台つなぐわけですがが、HDDを両方ともATA100のプライマリチャネルにつなぎました。
1つのチャネルにミラーリングしているHDDを2つつなげるのはなんとなく遅いような気がしましたが、
手持ちのケーブルの長さが足りないので仕方ありません。
DVD-ROMドライブがケースの上の方に、HDD2台が下の方についてるんで、DVD-ROMとHDDを1つのケーブルのマスターとスレーブにするには、一度ケースの上の方のDVD-ROMドライブにつなげた後、下の方にあるHDDまで降りてこないといけません。
まあ、HDDの取り付け位置をDVD-ROMの近くにすればいいんでしょうけど、冷却の都合もあるわけで。
(そもそも、SATAにすればいいと言う話もあるわけですが(^^;)
でも、マスターとスレーブの間の長さは、15cmのものがほとんどです。
全体もやたら長いものの、マスターとスレーブの間が30cmのケーブルを見つけることが出来たので、つなぎ変えてみました。
さて、これで速度に変化はあるのか。
接続を変更する前後で、bonnie++というソフトを使って、計測しました。
Gentoo では、
emerge bonnie++
/usr/sbin/bonnie++ -d (ディレクトリ名)
rootで実行すると警告が出るので、root以外のユーザで実行します。
で、計測してみたんですが、正直あんまり変わってない感じです(^^;
まあ、そんなものでしょう。あんまり、こだわるところではなかったのかもしれません。
今回、RAIDを構築した後で、RAIDを構成するHDDの接続場所を変えてしまいましたが、起動時にRAIDを構成するデバイスを探しに行きますので、問題は起きません。
ただ、mdの初期化時にデバイスが存在しないとまずいので、USBとかでつなぐとだめなようです。
まず、今のケースでは小さすぎてHDDが2台のらないので、入れ替え。
Gentooのinstallcdをつかって起動し、古いHDDをUSB経由で接続して、作業開始。
経験上、Gentooのinstallcdは、USBのHDDでも簡単につながるので便利です。
LVMにしない(できない) /bootとrootパーティションは、同じサイズのRAID1のパーティションを作ってddでコピー、のつもりがミスで少し小さいサイズになってしまって失敗。
よく考えてみれば当たり前で、/dev/hda1と/dev/hdb1 を束ねて/dev/md1 を作るとき、/dev/hda1と/dev/hdb1 を古いパーティションと同じサイズにしても、先頭にスーパーブロックが書き込まれるから、その分減るわけです。なので、普通にファイルをコピー。
その他のパーティションは、LVMで作るので、LVM用のRAID1のパーティションを作り、それをVolume Groupに追加。そこから切り出して、以前のシステムのパーティションに相当するLogical Volumeを作っていきました。
各Logical Volumeは、前のサイズよりは、少し大きめになるように取っていきました。
そして、作ったLVに、元のHDDからddでデータをファイルシステムごとコピーし、
resize2fs /dev/(Volume Gruop名)/(Logical Volume名)
で、LVのサイズいっぱいに拡張して、コピー終了。
ただ、コピーにけっこう時間がかかりました。
普通にファイルシステム作ってから、そこにコピーした方がよかったか…
作業をしていると、祖母から電話がかかってきました。
IP電話が止まっているので、変だと思ったようです。
こいつが、ルータになっているのをすっかり忘れてました。
最後の仕上げに、/etc/fstab のデバイス名を新しいRAID1とLVMのデバイス名に変更、/etc/mdadm.conf を追加、grubのrootパーティションのデバイス名を新しいものに変更して新しいHDDにgrubをインストールしました。
その後、全てのボリュームをumount、LVMとRAIDを停止して、リブートし、やっと稼働し始めました。
(ちなみに、カーネルはあらかじめLVMとRAIDを追加して再構築してありました)
結局、12時間くらいかかりました。
コピーに時間がかかったのと、コピーの間、別の用をしていたのが大きかったような。
そもそも、最初にケースを入れ替える作業があったわけで。
とりあえず、順調に動いている模様です。
記録の意味でも、後でやったことをちゃんとまとめたいですね。(後でというとやらない予感…)
余談:
その後、ついでなので、放置していたblogのメンテナンスをしていたら、なんと知り合いからのコメントまで、スパムフィルタが拒否していたことが発覚。
ブラックリストの zen.spamhaus.org に基づいて、拒否してしまったようで。
apacheで拒否するようになる前だったので、コメント自体は残っていたため復活させました。
このブラックリストは、どうやらまずいみたいです。
前のエントリでやったapacheの段階でスパムを拒否する設定から、このブラックリストは外しました。
そもそも、Movable Type側のスパムフィルタからも外しました。危険です。
迷惑コメント・トラックバックがMovable Typeのデータベースに大量にたまっていきます。
(フィルタされたものは分類され未公開にはなりますが、DBにいったん入ります)
フィルタされてればいい方で、フィルタを通過して公開されてしまうものもかなり多いわけです。
アクセスのけっこうな割合がスパムなのは確実で、United Statesがアクセス数トップです。
Movable Type の SpamLookup プラグインでDNSBLをつかってフィルタ出来るんですが、もうブラックリスト入っていたら、Movable Typeに渡す前にフィルタしたくなってきました。
そうするとDBに入らないので、万が一誤検出した場合に回復する手段がないわけですが、どうせコメントはほとんどないし、とりあえず問題ないでしょう。
DNSBLを参照して、その結果を元にapacheに403を返させる方法がないかと調べてみたら、やっぱりそういうモジュールを作っている人がいるんですよね。
mod_setenvdnsbl : Apache module (nesitive thinking)|
早速インストールして、設定してみました。
インストールは、Makefileの先頭のAPXSのところを環境に合わせて書き換えて、make && make install するだけです。
設定はこんな感じです。
<Directory ...> <FilesMatch "mt-(tb|comments)\.cgi"> SetEnvIfDNSBL remote_addr zen.spamhaus.org spammer SetEnvIfDNSBL remote_addr bsb.spamlookup.net spammer </FilesMatch> ... Order allow,deny Allow from all Deny from env=spammer </Directory>
しかし、apacheでMT/WPのスパム対策 DNSBLのmod_setenvifdnsblを使ってみる (blog@browncat.org) でも指摘されているように、複数のDNSBLを指定すると、最初のものしか見に行きません。
apacheのモジュールなんて作ったことありませんが、ソースを読んでみました。
まあ、apacheのAPIを知らないんで、最初はさっぱりだったわけですが、結局わかったのは、SetEnvIfDNSBLの最初の引数が同じだと、複数の設定を内部的にひとまとめにするための処理があるということでした。
mod_setenvdnsbl.cの217-255行目あたりです。
この設定の場合、remote_addr という行が複数あるので、これらをひとまとめにしようとします。
が、内部のデータ構造にはDNSBLは一つの設定ごとに一つだけしか用意されていませんので、最初のDNSBLのドメインしか残らないわけです。
単純にこの処理を省いてやるだけで要求通り動くようになりました。
本来は、1つのDNSBLへのリクエストを1回にするための処理なのかなと予想したのですが、それにしては、データ構造がそれらしくないんですよね。
こんなわけで、最近Javaばかりだったんですが、久しぶりにC言語をさわりました。
これをやって収穫があったとすれば、DNSBLのクエリの仕組みを初めて知ったことですね。
恥ずかしながら、今まで知りませんでした。プロトコルがDNSだから、DNSBLだったとは。
確かにクエリも軽いし、プログラムも書きやすいですね。
あとは、apacheのモジュールの作り方がなんとなく見えたことですかね。
スパム対策?そういえばそれもありました(^^;
結局、ブラックリストだけでは駄目なので、キーワードベースのフィルタにキーワードを追加して、厳しめにしてみました。
DBには入りますが、スパムが公開されてしまうことは防げます。結局これが一番効いたような…
4日,5日と富士山に登ってきました.台風5号で1日延期,天気には恵まれました.
実は今回で2度目.3年前は高山病でものすごい時間がかかりました.
下りはもっと大変で,これまた非常に時間がかかりました.
まあ,体重が重い上に,体力など,すべてにおいて貧弱なので,当然といえば当然ですが.
今回はスケジュールに余裕がないので,頂上まで登れないかと思ったんですが,高山病が比較的軽かったおかげで,何とかほぼ予定通りに到着できました.
前回より1時間半早く登り始めたためもあって,ご来光に何とか間に合いました.7時間くらいかかったのかな.
といっても場所が悪くて,人や富士山自体の影になってたんですが.
向こうまで歩いていけばよかったんですが,へとへとなのと,日の出の位置に気づいたときにはもう遅かったのであきらめました.
下りはやっぱり大変でした.足が棒です...
加えて徹夜なわけで,帰ってきて今まで寝てました.すでに筋肉痛になりつつあります...
もう富士登山はいいや.3年前もそんなこといってた気がしますが...
なんだか,あっという間に1年すぎましたねえ.
もう,いい加減に慣れましたが,1度も利用していない店とか施設は未だにあって,探さないといけないですし,道も近くの主要道路は覚えましたが,細い道はもちろん,太い道もちょっと遠くになると全く分かりません.
探さないといけないのは,例えば病院.
実は,先月,2月の22日の夜から丸3,4日ほど,A型インフルエンザでぶっ倒れていたのですが,もうろうとした頭で内科を探すのに苦労しました.
幸いわかりやすいところを見つけられたのでよかったんですが...
今は,花粉症なので耳鼻科を探しています...これがなかなか良さそうなのが見つからないんですよね.近くで,ちゃんと耳鼻科を専門でやっている病院がいいんですが.
はっきり言って道がわかりにくいので,車で移動するときは,まだまだカーナビがたよりなところがあります.
太い道がまともにつながってない.前住んでいたところもわかりにくかったですが,そんなもんじゃないですね.
東京の職場の周囲も,駅とかで普段困らないくらいには慣れましたが,ちょっと離れるとだめです.
鉄道も,東京はもちろん,家の近くだって,通勤に関係ない路線はわかりません.
前住んでいたところでも,勝手が分かるようになるまで数年かかりましたから,1年じゃこんなもんでしょうかね.
]]>私は,会社のメールを携帯に転送してます.
POPで取ってきたメールについては,自作のフィルタでたいていのスパムメールは振り分けが出来るので,それでいいんですが,問題は携帯に転送している方です.
携帯電話がうるさくて仕方がない...
それで,SpamAssassinを使って,携帯に転送するものだけスパムメールを遮断するようにしました.
勝手に遮断する場合,普通は誤判定が問題ですけど,携帯に転送している方は誤判定されても,あまり困らないので.
.forward でメールを2つに分け,一方はそのままメールスプールへ,一方をprocmailになげ,スパムメールの判定をさせてから,携帯に転送するようにしました.
設定してから,あまりスパムが来てないので,正直なところ,どのくらいちゃんと機能しているのかはよくわかりません.もっとスパムが来てみないと何とも言えませんが,なんかうまくいってない気がします.
別に,スパムに来て欲しいわけじゃないのですが...なんか矛盾してます.
案外使うのが難しそうです.
もう今年も,1ヶ月終わってしまいました.1/12年,31/365年ですよ.
なんだか,時間の感覚がおかしくなってる気がします.
時間の感覚がおかしくなっているやつは他にもいたようで,今日(もう昨日か)は,まだ2月にもなっていないのに,季節の感覚の狂ったテントウムシが,事務所に迷い込んでました.
まあ,暖かかったですからねえ.もう春だと思ったかな.
歩き回っていたので,なんか,うまく撮れませんでした.
今年は,修了して,就職して,引っ越して,節目の年でした.
いろいろありましたが,一瞬で過ぎ去った感じです.
本当に,あっという間にすぎた2006年でした.
さて,2007年はどんな年になるのかな.
後,約2時間で今年も終わりですが...
では,良いお年を.
やっぱり腫れているわけで,さすがに圧力がかかるとちょっと痛いので,抜いた方ではできるだけ噛まないようにしているんですが.
気になるのは,縫合してあるので,たまに糸に食べかすが引っかかるくらいですか.
縫合の関係で,ちょうど食べ物がはまる隙間もできてるので,そこに食べかすがはまってしまうこともあります.
あとは,24日に糸をとるだけですね.
年内に片づきそうです.
といっても,まだ他の虫歯の治療は終わってなかったりするんですが.
最初に簡単に説明を受けました.
まず歯の頭をとるけど,残りが完全にとれなかったら,無理をしないで埋めますということでした.
まず表面麻酔.その後,麻酔をかけました.
麻酔が聞いたところで,早速,抜歯開始.
最初に,歯茎をぐりぐりやっている感触が.かなり埋まっているので,なかなか顔を出さないみたい.
なんか,乱暴にぐりぐりされているきがして,少し不安になりました.まあ,その後の処置の方がもっとすごかったんですが.
歯が露出したところで,電動カッターみたいなもので,歯を切断し始めました.
まあ,使っている器具はよく見えてなかったので,本当はどんな器具なのか,わからないんですけど.
ある程度切ったところで,別の器具を取り出してきて,ごりごりとこじっているようす.
ところが,なかなかとれない.
ほんと,ごりごりやっている感じなんですよね.
またカッターで切断してこじるを繰り返すけど,なかなか頭がとれないようす.
横倒しになっているので,下から歯をつかむようにして,固定されてしまっているのかもしれないと言う話でした.
ここで出てきた道具がレントゲン撮影の装置.
手のひらサイズくらいの長方形の板からコードがのびていて,その板を口の中につっこみ,歯の内側にあてがって,外からX線を照射して撮影するようでした.
デジタルのシステムなので,すぐ画像が見られます.
画像を見ると,どうも,切り方が足りない様子.
その途中で,もう1人いた別の歯医者さんが,レントゲンの画像を見て,下顎管(神経と血管が通っている管)が近いんじゃないか,みたいなことを言い出しました.
念のため,もう1,2枚撮影し,画像を指さしながら相談,というか議論してました.
結局,その結果,それは下顎管じゃなくて,もっと下のやつが下顎管だということになったようで,処置が再開されました.
切り方が足りないみたいということで,再び切断.
カッターで切断,こじる,切断,こじるを何度も繰り返して,やっと頭がとれたよう.
後でみましたが,歯はバラバラになってました.
これでやっと,本体を抜く準備が出来たということで,またこじりはじめました.
最初は無理かもしれないと言ってましたが,案外すぐに抜けました.
特に骨にくっついてしまったりはしていなかったようです.
抜けたけど,出口が狭くて出てこないので,再び切断.バラバラにして取り出してました.
最後に,傷口を縫合して終了でした.
処置にかかった時間は,15分くらいでした.2時間くらいかかることもあるそうで,簡単な方だったようです.骨を削ったりすることもありませんでした.
麻酔が効いている間はもちろん良かったんですが,1時間位して,麻酔が切れたらやっぱり痛い.
麻酔が切れた直後が一番きつかった気がします.
多少,腫れてきている感じです.
つらいのは,飲み込むときの違和感と,口を大きく開けないことですね.
明日,また歯医者に行ってきます.抜糸は1週間後の予定です.
余談ですが,歯医者では抜糸(ばっし)とは言わないらしいですね.抜歯(ばっし)しちゃったら困りますから.
JavaScriptというより,JScriptの話です.つまり,IEのせい.
いつも,Webアプリケーションの開発では,まずFirefoxを使って動作確認します.
デバッグ環境が充実していて,圧倒的に開発しやすいですから.
でも,IEで動かないのは困るわけで,ある程度の段階になったら,IEでもテストするわけです.
そこでたいていはまるわけで.今回のもそんな問題です.
いろいろ原因を考え,可能性を削っていってもさっぱりわからない.
らちがあかないので,prototype.js を読んで,中で何をしているのか調べました.
結局,問題になるのは単に以下ようなコードでした.
elements = $('フォームの名前').getElementsByTagName('input')
elements = $('フォームの名前').getElementsByTagName('select')
探し始めるノードを変えて,どんどん子の要素に降りていくと,うまくいく場合もある.
formの内側でtableを使っていたので,まさか,それが原因かとも考えますが,調べてもそんな話は出てこない.
生成するHTMLをいろいろ変えてみるとか,試行錯誤するも全く現象は変わらず.
そこで,問題のelementsとelements.lengthのプロパティを全部列挙してみました.
そうしたら,elements.length の中身が,どう見てもDOMの要素にしか見えない...
elementsのプロパティもよーくみて,原因が判明.
inputタグのname属性の名前が,そのままelementsのプロパティになっているじゃないの...
そして,そのプロパティの値はinput要素.
そこで気がついたのが,そういや,lengthって名前のinput要素があったなあ,ということ.
lengthという名前のinput要素に,本来長さを表すはずのlengthプロパティが上書きされてたみたいです.
まあ,何が言いたいかと言えば,もっと早く気づけよ俺,ふざけるなJScript,ということなんですが.
ふとした拍子に名前が衝突し,それも黙って上書きしてしまうという仕様,いいのかよ.
もしかしたら,この話は常識なのかもしれませんけど.
こんな事にずいぶん時間をとられてしまった日でした.
というわけで,LinuxルータをUPnP対応にしないといけないわけです.
LinuxルータをUPnPのInternet Gateway Deviceにするには,IntelのUPnP SDKと,linux-igdが必要です.
これらのソフトの導入作業は,光が開通した後で動きませんでした,では困るので,光回線導入のかなり前に済ませていたわけです.MSN Messengerとかで動作確認しました.
あとは,IP電話の開通を待つだけだと思っていたわけですが...
IP電話の開通後,設定をして外部からの着信も確認できて一安心と思っていたら,次の日,家族から電話が着信しなかったという電話が.
まあ,結論から言うと非常にばかばかしい原因だったわけですが.
/etc/upnpd.confに,ポートマッピングの有効期間が指定されなかった場合の,デフォルトの有効期間の設定があります.
そこに,こう書いてました.
duration = 3:00
でも,何かおかしい.どう見ても書き方が変です.
そのときは,時間がなかったので適当だったんですが,
やっぱり,秒なのに":"を付けるのはどう見ても不自然なので,調べなおしてみました.
設定ファイルの説明には,
# seconds | HH:MM - duration from the time of addition
このあたりは,linux-igd の config.c にデバッグ用と思われる main関数があったので,それを使っていろいろ試してみてわかりました.
というわけで,問題解決.
というか,説明を良く読めと言うことですか...
ちなみに,IP電話アダプタは,30分ごとにポートマッピングを再設定してきますので,それより長ければ問題ないようです.
さて,電話代はどのくらいやすくなるんだろうか.