2008/07/31(木)アクセス(HTTPリクエスト)ごとにIPアドレスの変わるISPが存在しようがしまいがIPアドレスを信用しちゃダメ
正しくは「HTTP request毎に変化する」だね。
他社さんのことなので社名は上げないけど、個人向けのISPで実際にそういう風になっているところはありました。
(試してみて「あーっ」ってことに。本番投入前でよかった)
複数台のproxyが設置されていて、ユーザ側からのリクエストをL4的にラウンドロビンで分散させているらしい。セッションの継続とか(当然)考えていないので、アクセスごとに違うIPアドレスからくるように見えるわけです。
で、そもそもHTTPの規格に「連続した同一の人物(同一のセッション)のHTTPリクエストは常に同じIPアドレスからくる」なんて決まりはないので、「同じIPアドレスであることを期待する」ようなWebアプリ書いちゃいけません。
規格が全てではないけど、だからと言って規格にないことを「こうなってるはず！」で強行するのは失敗の元ですよ。
2008/07/13(日)PDO buffered query
コアの部分はperlで書いて1日で出来たのだけど、設定用のWebUIが全然作れない。ちなみにWebUIはPHPで書いてる。
で、PDOで絶賛はまり中。
Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute.
とか言われるんですが...こちらでも同じようなことではまってらっしゃる方おられる模様。
別に仕様としてそれでいいんですが、PDOStatmentクラスって明示的に結果を破棄するメソッドってないのね？
perlのDBIだと$sth->finish()で明示的に破棄できるんですが。
pdo-mysqlの説明にはattributeを指定するのは移植性が低いからfetchAllを使えと書いてあるのですが、それもなんだかなぁ。
ところでPDOってprepareに失敗してもexception投げないんですね。
例外でハンドリングできるだろうと高を括ってたら全然違うところでエラーになるんでやんの。
追記:
PHPからMySQLのクエリ送信のバッファリングについて - gounx2の日記
まとまってたので。
2008/06/23(月)Blu-rayいらずってわけじゃない
これでBlu-rayは不要？従来のDVDに9倍のデータを記録する技術が登場 - GIGAZINE
GIGAZINEの記事に対するトラックバックを見ていると「Blu-Rayが不要になった！」的な捕らえ方している記事があるけど、脊髄反射すぎるよなぁ。
ちょっとまとめてみよう。
いろいろ細かい話はあるけど、思いっきり省略。
以下、Blu-Ray DiscをはBDと省略。
DVDに対するBDのアプローチは、
・CD,DVDやBDはディスク上の「ピット」に情報を保持しているこれを実現するために、BDでは「波長が短い光」=青色レーザ光(Blue-ray)を用いています。
・ひとつの「ピット」に保存できる情報量は1bit
・「ピット」がたくさんあれば多くの情報を保持できる
・DBはDVDよりも小さなピットを細かく配置することで、同じサイズでも記録容量を増やしている
しかし、ピット密度を上げる方向での解決は
・青色レーザを発生するデバイスは(従来の赤色レーザに比べて)高価と言う問題があるわけです。
・ディスク上のピットの位置を特定するための精度を高める必要がある
で、東北大の新規の技術は
・ピットの密度は今のまま (=赤色レーザのまま、且つ位置特定精度も今のまま)ということを狙っています。
・ひとつのピットに複数の情報を保持できれば同じサイズでも記憶容量が増える
これを実現するために「ピット」という穴の中に複数の「方向」を持って情報を書き込むことで最大9倍(9bit)の情報を記録することに成功したようです。
ここで「方向」を実現するために使われたのが偏向フィルタで、これ自身は十分に実績のあるデバイスなので安価に・簡単に組み込みも可能であるということを主張しています。
・新規格はBDよりも(位置決めやレーザの波長などで)技術難易度が低いということになるわけです。
・低い技術難度でBDと同等の機能が実現できる
で、このあたりからgigazine読者が勘違いしまくっているところで、「開発設計レベルではデバイスを追加することは簡単」と言っても、すでに世に出回っているDVDドライブを簡単に改造できるとか言うレベルの問題ではありません。当然現在のドライブではこの新規格のディスクは読み書きできません。
結局、商業的には「DVD」「BD」とも違う第三の規格ができるだけです。
この規模の量産規格になってくると、もはや少々の技術難度の格差はコストには跳ね返ってこず、量産規模の支配力のほうが強くなります。
で、すでにBDの技術的課題はほぼ解決されており量産も立ち上がっているわけで、それを考慮するといくら技術的に簡単といえども後追いで出てきた規格がBDを追い越せる可能性はほとんどないわけですね。
ということで、「なんだBDいらないじゃん」ということにはなりません...
じゃあ東北大の技術は無駄なのかと言うとそうではなくて、「BDの次」を考えたときは有効です。
現在BDは青色レーザを使っていますが、このままピット密度を上げる方向を目指すと紫外線レーザなんて非常に扱いにくくてコストが高いデバイスを使う必要が出てきますし、位置特定もありえない精度が要求されます。
当然そんな話はみんな気づいていて、多層化するとか、ホログラフィを使ってピットあたりの情報量を増やすとか考えているわけですが、東北大のプレスリリースで指摘されているとおり、多層化したディスクは単純なスタンパだけでは量産できない(張り合わせ行程が必要になる)とか、ホログラフィは読み出しの光学系が複雑になるとか問題があるわけです。
その点東北大の技術は単なる偏向フィルタだけで大幅な改善をもたらしており、結構有力なんじゃないの？という話なわけです。
だから、「この技術をBDのピット密度に応用したら50GB*9=450GBも記録できるんだ！」ってのが正しい驚き方です。*1
ちなみに補足しておくと、BDはすでに2層張り合わせを行っています。
HD-DVD対BDの争点のひとつとして、この張りあわせが製造コストを押し上げるというのが東芝(HD-DVD陣営)の主張でしたが、結局2層についてはそんなに問題がなかった様子。ただ、このまま多層化(3層以上)が進められるかと言うと、やっぱり難しいかもしれない。
結局そういう技術と偏向フィルタを入れる技術のどっちがリーズナブルかってだけなんだけど。
(訂正)
当初規格名を「Blue-Ray」と書いていましたが、規格名としては「Blu-Ray」でした。指摘してくれたumeな人に感謝。
「なお、名称が「Blue-ray」ではなく「Blu-ray」になっているのは、「Blue-ray Disc」とすると英語圏では「青色光（で読み取る）ディスク」を意味する一般名詞と解釈される可能性があり、商標として使用できないからである。」(Wikipedia)らしいです。
2008/06/23(月)PHP on IIS
PHP on IIS あなたの可能性を広げる、Windows 環境へ
IBMのApache(httpd)+Rubyに対抗するのかな？
IBMはJavaのような重量級開発言語*1以外に軽量な言語が必要だと考えてRubyにコミットしていると思うんだけど、Microsoftも同じことを考えているのか...
そういう位置づけにはVBがいるかと思ったんだけど、結局VBはVisiulStudioがないと開発できないってことで、やはり敷居が高いのかなぁ。
そもそもVBはWeb向けじゃないし、そもそもASPでの開発はPHPやRubyでの開発とスタイルが違う(らしい)ので、世間にたくさん居るLL系開発者の取り込みを考えるとこうなるのかもしれない。
しっかし、PHPにコミットするのもいいけど、IronPythonとかどうするんだろ？(IronRubyもあるみたいだけど)
2008/06/10(火)Etherケーブルを自作するかどうか
http://www.itmedia.co.jp/enterprise/articles/0806/09/news019.html
システム構築の達人は、決してLANケーブルを既製品で済ますことはない――そんな言い伝えもまことしやかにささやかれる一方で、LANケーブルを自作できない方が増えてきた。のっけからこんな話が書かれていますが、そういうわけでもないんですよね。
実際ISPやインテグレーション構築の現場でもわざわざ自作することはほとんどないですね。
100Mbpsならいざ知らず1Gbpsが平気で流れる昨今、ケーブルに対する要求もシビアになってますので、自分で作ったケーブルが思わぬ障害の原因に、何てことも十分にあります。
ちなみにどのぐらい要求がシビアかと言うと、ケーブルの端をRJ-45コネクタに突っ込む部分でよりをほどきますが、このほどく部分の長さが何mm以下と決まっているちうぐらい。手でやってたんじゃよっぽど熟練してない限りできませんよ？
商用レベルでケーブルの自作を行う場合、記事にもあるとおり正しく結線されているかをケーブルテスターで調べるのが最低条件になります。これも1～2万円で売ってる結線だけをチェックするテスターじゃなくて、周波数特性まで確認できるまともなテスターが必要になります。
構築となると、小規模な案件でもケーブル20本とか50本は平気で使います。そんなのわざわざ手で作ってテストまでやってたら相当時間かかりますよ？手間(と工数単価)を考えると買ってきたほうが安いです(苦笑)
そしてインテグレーション案件の場合、ケーブルの施工不良なんて余計なリスクは取りたくないのです。実際トラブルになること多いですから...
ただ、ラック間の結線とか例外的な距離を配線する場合は自作(というより、配線してからコネクタをつける)ことになりますね。これは他にやりようがないので。
それでもデータセンターによってはラックをまたぐ配線はセンター側の責任での施工となる場合が多くて、結局ケーブリングの専門業者にやってもらうことになったりしますが。
長距離の場合安定性重視で光ファイバーで配線することも多いですが、こうなると自作は不可能ですね。(ちゃんとした業者に依頼しましょう)
本気で大規模なサーバ系案件の場合、別途ネットワーク収容架を設けてラック間は集合ケーブルでパッチパネルで渡したりします。この場合もやっぱり自作にはならないですね...
ま、そんなこといいながらもケーブルの自作ぐらいは出来て欲しいですね、やっぱり。
ということで隣の新人君は今日もケーブル作ってました ;-)