調査していったところ、HTML中の特定の文字列に反応していることがわかりました。

サーバ側の対策としては、HTMLのソース中の

<script type="text/javascript" src="http://xxx/xxx.js"></script>

の><部分にスペースを入れれば回避できる事がわかりました。

<script type="text/javascript" src="http://xxx/xxx.js"> </script>

サーバ管理をしている人で困っている方、お試し下さい。

＃あーびっくりした(^^;
＃というか、時間を返して～>AVGさん

追記：実際にAVGで誤検出となるページを２パターン作成してみました。AVGを使っていない人はただの真っ白の画面になります。ソースを御覧頂くとわかるのですが中身はたった2行です。PC Watchパターン(isobe君ありがとう)。日刊スポーツパターン。
2010/7/21現在での最新のAVGを使っている人は、ブロックされて以下のような表示になるはずです。

さらにページをめくるときに、縦モードだと、前頁の裏が透けて見えます。
こんな無駄なプログラムを書いた技術者に拍手です！

GizmodeをAviaryでキャプチャしSigilでePub化。iTunesでiPadに送りました。ちなみに、iTunes9.1で、バグ発見。PC上のファイルをダイレクトにiPadの「ブック」にePubファイルをドラッグ＆ドロップするとiTunesが落ちました。(^^; 　
一旦、「ファイルをライブラリーに追加」をして、ライブラリーからiPadにドラックすればOKです。
ちなみに、このディテールからiBookでパラパラ漫画を連想したのですがiBookの描画が遅くてだめでした。

個人的にはKindle for iPadよりiBookの方が読んでいる感があります。

問題は、iBookが日本では買えない事ですね。
ためしに適当なアメリカの住所を入れみたのですが、アメリカのクレジットカードでないと買えませんでした(アメリカ発行のiTunesカードなら行けるかもという話もあります)。
そうなると、日本では、日本のクレジットカードOKな、Kindle for iPadに軍配かもしれません。

iBookやamazonが日本上陸するまでの間、国産勝手storeの乱立と覇権を巡っての争いが展開されそうです。

新聞業界という複雑な体質の中、フル実装にこぎ着けられた裏方が非常に気になるところです。
また、電子版オンリーの金額設定が4000円という金額から、電子版オンリーでも購読者の地域の販売店にバックされるロジックがあるのでしょうか？
一般紙ではなく、セグメント化されたコンテンツホルダーならではなのですが、是非ビジネスモデルとして成功して欲しいと思う次第です。

気になるのは、iPadやiPhone Safariでの閲覧がどの程度の操作感になるかですね。

あとは、購読者の地域のチラシも一緒に読めるビジネスモデルは、広告集める販売店側も購読者もWelcomeな気がするのですがどうなんでしょうか？

少なくとも、ここからの１０年間。
私たちは、従来の紙の時代から変わりゆく歴史的転換点の目撃者になるのは間違いないなさそうです。

先日、iPhoneアプリからアダルトっぽいものはすべて削除されたそうです。
嘘かほんとかはわかりませんが、iPadに教科書をすべて入れて、子どもたちに配布するのが視野にあるからだという噂も。個人的には、ちょっと暴走気味な気もしますが、１０年後、子どもたちの重いランドセルが軽く小さくなる日が来るのかもしれません。

Google,Amazon,VMWare,Xen,etc

で、一つの結論があります。

弊社のように常に処理能力且つ低コストを要求されるシステムを構築する場合は、「クラウドを使わない従来スタイル（１サーバに１OSをセットし冗長化構成を構築）の方がハイパフォーマンス」という結論になりました。（あたりまえと言えばあたりまですが・・・）

「クラウド」は営業的にウケもよく、ビジネス的に儲かるかもしれません。いくらメンテナンス性や障害に強いといっても、客先の要求する処理能力と予算を満たせなければ、膨大な予算を使って「豚」なシステムを構築するだけになります。

しかし、そんな営業をされて取ってきた仕事を引き受ける技術者は悲惨な事になりそうに思います。「クラウド」はあるべき姿だと思いますが、弊社内のベンチマーク結果では、ms単位の処理能力要求があるシステムを構築するには時期尚早だという結論に達しました。

ベンチマーク結果を公表したいところですが、VMWareあたりは規約上NGらしいので。。。

なんかうちの会社、ベンチマークを取る度に、時代に逆行しているしているよな気がします。　＃だから儲からないんですね(^^;

でも、うちのアドバンテージは、技術屋として、ビジネスより質実剛健なシステム構築を優先する所にあると思っています。

しかし、昨今のHardware RAID カードは、メーカー独自フォーマットが主流となってしまいました。その影響で、サーバメンテナンス業者は、

• ＲＡＩＤカードが壊れると、そのハードディスクは、マザーに直接指しても全く読めないハードディスクになってしまう。
• ＲＡＩＤカードが製造中止になるとかなりまずい。
• 緊急時に別マシンで複製したりバックアップからリカバリーしたりするにも常に同じＲＡＩＤカード環境がないと作業が出来ない。

というリスクが伴います。

それでは、LinuxのSoftwareRAIDにしたら?という話になります。

ハードウエアRAID vs ソフトウエアRAID。

この論議を机上論で行うとハードウエアＲＡＩＤに軍配があがるのですが、実際の泥臭い現場の状況からすると、ハードウエアＲＡＩＤは結構痛い目に会うことが多いのは事実だと思います。これまで１４年間。数百台のサーバを作り最後まで看取ってきましたが、ハードウエアＲＡＩＤのホットスワップで得た恩恵の回数と、ＲＡＩＤカードを使った事によるトラブルに巻き込まれた回数とあまり変わらないように思います。やはりシステムの摂理として、シンプルなのが一番で、複雑になればなるほど事故も増加します。

そこで、システムが冗長化になっていれば、ホットスワップが出来ないＳｏｆｔｗａｒｅＲＡＩＤの方がメリットが多いのではないか？という切り口から、いまさらながら、ハードウエアRAID vs ソフトウエアRAIDのスピードテストを行ってみました。速度さえトントンであれば、この際、ハードウエアRAIDを捨てるのも現場的にはありかと思ったからです。

結果は、以下の通り。弊社ではこれを機会に冗長化してあるシステムにおいて、ハードウエアＲＡＩＤはやめる事にしようと思います。

■測定環境

マザーボード	Super X5DPR-8G2+
CPU	Intel(R) Xeon(TM) CPU 2.40GHz x 2
メモリ	2GB
ハードウエア RAIDカード	3ware 8006-2LP
ハードディスク	ST31000333AS x 2
OS	CentOS 4
データベース	PostgreSQL 8.1

■ 測定結果

以下SW=Software RAID, HW=Hardware RAID。水色が勝者。

▼bonnie++

○アクセス速度

	Sequential Output			Sequential Input		Random	Sequential Create			Random Create
	Per Chr	Block	Rewrite	Per Chr	Block	Seeks	Create	Read	Delete	Create	Read	Delete
	K/sec	K/sec	K/sec	K/sec	K/sec	/sec	/sec	/sec	/sec	/sec	/sec	/sec
SW	29738	76693	28425	26180	63601	387.5	33087	211403	35711	34286	273394	35336
SW(-n 256)	29221	76877	28401	26384	62070	377.2	19978	200433	509	11538	252888	266
HW	27081	57677	22943	25966	56936	379.2	29879	N/A	N/A	N/A	N/A	32170
HW(-n 256)	27983	56850	23303	24297	54209	352.6	19401	194718	715	11494	246347	377

○CPU使用率

	Sequential Output			Sequential Input		Random	Sequential Create			Random Create
	Per Chr	Block	Rewrite	Per Chr	Block	Seeks	Create	Read	Delete	Create	Read	Delete
	%CP	%CP	%CP	%CP	%CP	%CP	%CP	%CP	%CP	%CP	%CP	%CP
SW	97	44	11	78	10	1	97	100	100	99	100	100
SW(-n 256)	95	45	11	79	10	1	70	100	2	40	99	1
HW	89	32	9	75	10	1	90	N/A	N/A	N/A	N/A	98
HW(-n 256)	91	31	9	70	9	1	70	99	2	41	99	1

▼pgbench

○条件

transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 50
number of transactions per client: 200
number of transactions actually processed: 10000/10000

○結果

SW	123.03785 tps
HW	95.591599 tps

先日、お客さんのサイトでトラブルがあり、ログを比較していたところ、特定のセグメントに、
かなり偏りがあることが判明しました。

１年ぐらい前はそんなことはなかったので、DNSラウンドロビンの誤差とも思ったのですが、
ログの量がほぼダブルスコアでした。はじめ、ログ収集でミスがあるのではないかと
必死に追ったのですが、全く問題がありませんでした。
トラフィックを見たところ、トラフィックも間違いなくダブルスコアになっています。
間違った、比率で応答するDNSがいるのかとも思ったのですが、全く見つけられませんでした。

そんな中、鈴木君が、ログ解析システムで、データセンター毎のユーザエージェントを
眺めていて、「あれ？なんかデータセンター毎のユーザエージェントがおかしい」言い始めました。
そう、Vistaが特定のデータセンターに集中していたのです。

※OSとブラウザの組み合わせで出る問題なので、OSだけのデータでは語れないので参考値

いろいろと、調べて見ると、同じように騒いでいるページがあることがわかり、
結局、Vistaのgethostbynameが、DNSラウンドロビンの時は、
一番小さいアドレスを返す仕様（バグ？）であることが判明しました。

micorsoftさんもDNSラウンドロビンを使っているように見えるのですが、
みんな、困っていないのでしょうか？

Windows7でこの問題が治っているのを祈りたいところです。
それとも、getaddrinfoだと大丈夫なのでしょうか？
今後も改善されないとすると、結構、困ったことになりそうです。

その中で、ハーバード・ビジネススクールのクリステンセンの教材を使った講義がありました。
内容としては、HPが1990年代前半に世界で始めて開発した1.3inchのハードディスク「キティーホーク」が、技術屋主導でろくに市場調査もせず突っ走った結果、ビジネス的に大失敗に終わるという、実に耳が痛～い(^^;)ストーリーでした。

講義ではいかにこのプロジェクトが駄目だったかを袋叩きにしていたのですが、私は、技術屋として、このプロジェクトがうらやましく思い、こんな熱いプロジェクトをやってみたいと思った次第です。（大失敗はまずいですが・・・）

教材の最後にこんな一節がありました。
「失敗したプロジェクトで、これほど多くのチーム・メンバーがもう一度はじめからやり直そうという意欲を燃やすケースは見た事がない。プロジェクトは終わっていずれかの折に、ほとんどのメンバーが私のところに来てはこういった『リック、あんな楽しいことはなかったね』と。」
たぶん、受講生の中で、ここで鳥肌が立ち、目頭が熱くなったのは、私だけかと。。。

お金だけ見ると確かに大失敗だったと思うのですが、きっとこのプロジェクトを通じて、人も会社もお金では計れない大切な財産をGETとした事と思います。今のHPには、このときのメンバーが残っているかどうかは知りませんが、「今のHPをささえているのは当時のメンバーだった」なんて後日談があったら素敵かなぁ～と思う次第です。

日本のソフトウエア開発プロジェクトの多くが赤字だそうです。利益が出ても数パーセントしか出ないそうです。弊社ではいくばくかですが利益を出しつつ、大手より安いコストで開発・保守を行う事が出来ています。なぜでしょうか？

答えは簡単なのですが、
弊社では開発したメンバーが保守までワンストップで行っています。
故に、サーバに障害が発生しても、すぐに対応が出来て弊社としては当たり前の事なのです。
この当たり前の事が、外注や派遣に頼り分業しすぎている大手には真似が出来ない芸当のようです。

弊社では全メンバーが全てを見渡せるレベルの技術者ばかりで構成しているため基本的に技術面から外注に出す必要がありません。また、人手が足りず外注に出さなければ受注できない仕事は、金額に関わらずお断りさせて頂いております。（過去にお断りをさせていただいた方、本当に申し訳御座いませんでした）

なんか弊社のCMのような文面になってしまいましたが、大手じゃないと出来ないソフトも多くあるのも事実なので、大手のやりかたを否定するわけではありません。でも大手じゃなくても出来るソフトを大手に社運をかけて発注し痛い思いをしているケースを聞くたびに、個人的には、もったいないなぁーと思う次第です。

ステージ１は、2003年～2006年のコンピデータを使い予想ボットを各自で開発。
2007年のデータでの回収率を競うバトルとしました。

その結果、エントリーした35個のボットの内、6個のボットが100%越えを達成しました。（最高215%）

現在、各ボットのレギュレーションチェック中で、来週にはランキングが確定すると思います。

結構面白い結果となったので、このブログで発表できればと思っています。

Google App Engineが多くのソフトウエア技術ジャンキーを楽しましてくれればくれるほど

・データセンターがなくなる日
・ルータ・サーバ業者が商売にならなくなる日
・ネットワーク工事業者が商売にならなくなる日
・大手メーカーがさらに商売にならなくなる日
・ユーザはブラウザだけあれば全てが事足りてしまいOSはどうでもよくなる日
・ソフトウエア技術者がGoogle App Engineさえ使えこなせればよい日

の足音が聞こえています。

静かに、着実に、業界の歴史的転換点が近づいているように感じます。

その時、私たちは。。。。