いまさっき、唐突に思いついたんですが、

ソフトウェアの導入だけで、HDDを30倍～50倍速に、

つまりメインメモリと同等まで高速化する…！


…なんてことは、夢物語でしょうか？





いや、実のところ昨今のHDDの速度は別にイライラするほど遅くはない、というよりむしろずいぶん高速になったなぁと思うわけですが。


最近のHDDのヘッドは、ディスクの端から端までをなんと毎秒50回以上移動できるという超機敏なモーションが可能なのです！とかいう言い方をするとトテモスゲェーッ！と感じますな。
ちょっと、自分の人差し指を立てて突き出し、「切れてないですよ」とその指を左右に毎秒25往復の速度で振ろうとしてみてください。ほら、すごいでしょヘッドの動きって！（トテモスゲェーッ！


がしかし、ディスクが毎分7200回で回転している以上は
最低でも１秒間に120～240回以上アクセス（読み書き）が可能だという事実も知っていると全く違います。

つまり、ヘッドの移動待ちだけで実に4割～8割以上の時間を費やしているという最悪の光景も見えてきたりするわけで。




単一のアクセスに対していくら速くなったとしても、
それでもやっぱりHDDの遅さにイライラしてしまう場面は多々あったりして。


その主たる原因が、多重アクセスの瞬間。


ディスクを搭載しているHDDの構造上、一度に読み取れるのは一箇所のみ。（基本的に）
これはDVDやらCDやら、古くはレコード盤などと同様で、"円盤"と"針"の関係に脈々と由来しとるわけですね。

WindowsというOSは常にHDDに何やらアクセスしています。
もうあまりに複雑すぎて何のために何を読んだり書いたりしてるのか、もはや永遠の謎です。
ソフトウェアも様々なかたちで山のように同時起動できるようになった今、
こいつらもまた、ほかのソフトやOSなどお構いなしに自分のタイミングで勝手にHDDにアクセスを試みて、
案の定ほかの誰かと被りまくり。

しかも、ぶつかってもお構いなし。むしろ全く気付いてもいない。
HDDさんが同時に注文を受けすぎて空回りしてるという事に。
そして皆が皆「HDDよ、とにかく俺の指定したデータを早く読み取って来い」ときたもんだ。


そら遅くなるわ。問題はこの辺。

実際、ひとつのファイルAをコピーしようとした場合と、
それと同時にファイルBにも同じ事を行った場合とでは、
それに要する時間は単一の場合の倍の時間ではなく、
それこそ3倍～10倍にガンと跳ね上がるんです。


原因は前述したとおり、ヘッドの移動速度です。
複数の場所に同時にアクセスをかけた場合、どうしてもヘッドの往復運動が発生してしまいます。

例えばアクセスだけなら0.0016秒で終わるところを、
ヘッドの移動時間を間にたった1度挟むことによって0.0116秒になってしまうわけです。
その結果、実に7倍もかかってしまうことに！

これは、1秒で終わるはずのアクセスが7秒に！
10秒で終わるはずが1分10秒に！　60秒で終わるはずが7分に！という事を意味してます。
アクセス量がでかくなるほど、洒落にならない鈍足さを生み出します。

しかもこれは2つ重なった場合の話でして、
3つ重なった場合はさらにひどくなりまして、。なんと13倍！
4つ重なると…20倍！です。界王拳だと軽く"悟空レベル"に到達。


せめてこれが、2重なら2倍、3重なら3倍…なら、これほど大きな問題ではないのですが…。
これが、HDDの構造上どうしても避けられない致命的問題のひとつです。
HDDが進化し続けても、当面は（少なくとも10年くらいは）これが解決されることはないでしょう。
（不揮発性メモリの搭載によって大幅に改善される可能性はありますが、あるとしても主に書き込みのほうで、読み込みには同じ問題が残るでしょう）



さて、この問題、どうにか改善できないでしょうか。
いや、解決策は既にあります。
ヘッドの数を大量に増やせばいいのです。

人はそれをRAID 0という。
2台以上のHDDを束ねて１つのHDDのように扱うわけです。
しかし、2台や3台のRAIDでは14倍を2倍に圧縮する事は到底出来ません。

RAIDは各々のヘッドを効率よく動かしますが、並列化によって高速化を狙っているに過ぎません。
そのため、多重アクセスがかかった場合には複数のヘッドが皆同じように移動をくりかえしてしまうのです。
2台のRAID 0なら14倍の処理が半分になり7倍になるだけ。しかもRAID処理のためにかかるオーバーヘッドもバカに出来ないため、結局10倍以上かかったりして。

オーバーヘッドを無視した理論上でも、2重アクセスの鈍化を完全に相殺するには4台～7台のHDDでRAIDを組まなければならないとか、尋常ではない結論に達します。
3重アクセスの鈍化相殺には7台～14台のHDDが、4重の相殺には14台～27台のHDDが…これ以上は考えるだけ無駄ですネ。

もちろんそれほど多くのHDDでRAIDを組んだとすれば、通常の単一アクセスはバカっ速なので2重、3重のアクセスが起きてしまう前に他のアクセスを完了させるという神業を遺憾なく発揮し、大幅な改善が見込めるかもしれません。

が、RAID 0の場合はHDDがひとつ壊れたらデータ全滅ですので、この数まで来るとRAID 5やそれ以上の策を講じなければなりません。RAID5の場合、単純にHDD1台の無駄が生じる上にパリティ計算で処理時間がさらに伸びますので、HDDの総数はさらに非現実的な台数に…。

いやそれ以前に、7台でRAIDとかのたまう時点で家庭用コンピュータには非現実的ですな。
それだけで、何十万かかるんだヨ。。。







とまぁ、そんな具合でHDDがいかに遅くてダメっぷりを露呈している問題児かという点についてネチネチとこれほど長く書き綴った上で、これらがすべて前置きなんですがとか言い出すわけです、わしレベルになると！（ぇ


で、ここからがやっと冒頭の文章につながる本文なわけです、わしレベルにｎ（略


最近HDDの多重アクセス時の劇的鈍化問題について、
それを何とかお手軽にちょちょいと改善できないものか…！と、
マリオカートDSをしながら片手間で悩んでたところ、へろは思いつきました！ある方法を！














そこで、RAMディスクなんて、どうよ。（ぇー












うわ、なんかすっごい痛い！ なに？その見下すような視線の数々…！
ち、違いますよ！あれですよ！
RAMディスクっつっても、単なるあのRAMディスクちゃいますよ？！
それの拡張版？いや応用版？つーか逆転版？みたいな！みたいな！



…あ、てゆーか長話しすぎじゃない？！
うわごめんごめん！じゃあ一旦切るわ！またね！

と、無駄な長電話の結末みたいな感じでぶった切って記事アップ。詳細は次の記事で…！（ぅぉーぃ！

バグ一覧を更新しましょうか…面倒だー（ぉ

でもそろそろもう無意味になってる気も…。
Doblogさんのほうも黙々と直してるのかまったり通常モードなのか知りませんが…。

お久しぶりです、豪華自作PCプロジェクトですよ。


6月初頭、最後の一歩を踏み出したはずのプロジェクト、
一体どうなったのか、そろそろお話せねばなりますまい。
そう、「まだ出来上がってない」という事を！ orz


いや、痛ッちょっ、違うんですって、
あたッ！　硬い物は投げないで下さい！ねぇッ！
なんていうか、不可抗力なんです、わしのせいじゃないんですって。


「出来上がってない」んですが、実は一度組み上がってはいたのです……
がしかし、なんと言うか、大どんでん返しがありまして。
その１７の記事(6月上旬）のあと、数日後には全パーツの発注を行ったんです。
そして、一瞬全部揃った！ケド、一度OSのインストールまで行った！のだケレド…

えぇ、返品騒ぎに巻き込まれてしまいました。orz


もう、トークで説明するほど情熱が残ってませんので、起こった出来事を以下に箇条書きｗ


6月3日：
　秋葉原の某P店舗知人よりRadeon X1900XT入荷したとの一報。
　マザー・HDD・光学ドライブその他もろもろ本発注。

6月4日：
　G.Skill製メモリ1GB x 2枚 をオーバークロックワークスでネット注文。（その１６記事）
　某P店舗に注文したGIGABYTE製じゃなくSAPPIRE製が入荷した事が発覚。　向こうが間違えた模様。というかSAPPIREは入荷できないとの事。発注停止。交渉開始。

6月5日：
　同日、秋葉原のZOA店にCore Duo T2400をネット注文。

6月6日：
　オーバークロックワークスからG.Skill製メモリ1GB x 2枚 が届く。
　某P店舗、がんばって安くしてくれたので妥協、SAPPIRE製で再度発注。

6月7日：
　ZOA店からCore Duo T2400が届く。

　（この時点で、某P店舗に頼んだもの以外は全部揃う。）

　某P店舗の手違いで、HDDに付けたはずの保証が付いていない。発注停止。
　正式な金額が知らされて来ないので入金もできない。

6月8日：
　某P店舗、HDDの保証付けてもらって再び発注。
　某P店舗の銀行口座に代金を振り込む。

6月9日：
　某P店舗から発送完了のお知らせ。

6月10日：
　入金した合計額が間違えている事が発覚。（HDDの保険料が間違えて高くなっている）
　しかし、もう入金してしまっているのでどうしようもない。

6月11日：
　某P店舗から、やっと商品が届く。ついに全パーツが揃った。
　だが、RADEON X1900 XTが箱開けた時点でオカシイ。
　基板の後部が曲がっている、先端付近はヒビ割れも見える。不良品である。orz

　待ち過ぎてイライラしてたので「曲がっているだけなら大丈夫カモ」とか、わけのわからん事を考える。
　そのまま取り付けて、恐る恐る電源を入れてみると、とりあえず動く。
　OSインストして、FFベンチをかけてみると、軽快な結果。
　しかし、5時間後にはOS起動後リブートするようになる。

6月12日：
　1日後にはOS起動の直後にフリーズするようになる。
　某P店舗の知人にRADEON 1900XTの初期不良交換を申し出る。

6月13日：
　出来れば良品を先に送って欲しいと伝える。
　保険料の払いすぎている分の返金の件も一緒に頼む。

6月14日：
　やっぱ無理だから不良品先に送ってくれという話になる。
　保険料ミスで金額に誤りがある領収書も同梱、
　保険の証書も同梱して、某P店舗の店長代理宛で送り出す。

6月19日：
　某P店舗の本社サポートセンターからTELが来る。
　「物理破損のため交換には応じられません」
　「規約のほうに書かれております」
　「お客様が壊したというわけではありませんが、メーカー及び運送で壊れた証拠もありません」
　「メーカーからこのような物理破損の状態で納品された事は過去に一度もありません」
　意味のわからない論法で丸め込まれる。
　翌日の朝そのまま返送しますとの事。ふざけるにゃ。

　某P店舗の知人に話すと、サポートはノータッチのはずなので手違い、
　本店舗内で代理店と交渉してなんとか交換OKとなっている。
　サポートから物を取り返してくるという話に。

6月20日：
　朝一でサポートセンターから物を奪還したとの知らせ。ほっとする。

6月23日：
　保険料を余分に支払っていた件の返金処理を行ったようだと知らせ。

6月24日：
　自分の講座を調べると入金したと言っていた返金がされていない事に気付く。
　音沙汰が無いので知人に問い合わせると「まだ来てないの？」
　状況を調べて教えてくれと頼む。

　
6月27日：
　代理店に物を送り、現在それが帰ってくるのを待っている、との回答を得る。

6月30日：
　返金分が銀行に入っている事を確認。

7月10日：
　いくらなんでも遅いだろうと知人に問い合わせ。
　「うそだろ、もう返ってると思ってた遅すぎ」との事。
　状況は変わっていない。

7月15日：
　知人が腹痛でぶっ倒れ、入院する。盲腸の模様。
　絶食でマイっているが元気な様子で安心する。
　ただ、店とのパイプが切れているのが不安。

7月17日：
　そして、今もRADEONが帰ってくるのを待っている。








なに、Core2 Duoって？　Meromって？
もう知らないｗ

もう返品してから1ヶ月近いんですが、物が帰って来ません。
動いた日からするともうちょっとで2ヶ月ですぜ。orz

「すいません、印鑑かサインお願いします」

デジ欲侍へろのもとへ届いたお荷物は、大阪の友人から。
あ、これ10日ほど前の話なんですが。


中身はニンテンドーDS Lite！（白）
わぁ～い！


－14日前のメッセ－

「DSLite、定価でも欲しいですか？」
「えっ？　買います！」
という事で、あっさり入手ｗ

ドコもかしこも未だモノが無いのに、あるとこにはあるもんです…。
いわゆるひとつの裏ルートというやつですか。
いやぁ、世の中はいつもダークですネ。（何

詳しく語ると友人巻き込むハメになるんで言えませんが、
どうも大手外資系スーパー・モニョモニョのモニョモニョ店に在庫（?!）してあったよーです。
店員さんの分（及び家族の分）ならこっそり買えるシステム、って事らしい。

ほとんど言うてるやん。（ぉ


さぁ、なんとなく手に入ったDSLite。
どうしましょうかｗ（ぉ
あ、以前こんなの書いてましたネ。。。

よっしゃぁぁあぁああ！！
マリオカートDSやるぜぇぇぇ！！（今更

………はっ！
ゲームソフトが一本も無ぇえぇぇえぇぇぇッ！！（馬鹿

（※DSLite届いた日から2日ほど、ひとりでピクトチャットしてました。orz）

あ、ちなみに、DS Liteは…、２台届いたよ（ぇ

前回記事で悩んでると書いたところ、
chibisaruさんにいろいろアドバイスを頂きました。
おかげで問題点を思い出したり、新たな発想思いついたりして助かりました。どもども～

ちなみに、chibisaruさんには生のCSSを見られちゃったようで非常にハズカシーすｗ
でもまぁ今回の話のミソですし、URLを書いておきますね。
ｈttp://www.doblog.com//tcss/user/31000/t30628/real30628.css
↑これです。（リンクは一応なしね、先頭のｈを半角にしてちょ）

そう、ドブロガーのCSSは直リンクで読めるんですな。
Doblogの各ブログは、３つのCSSファイルから成り立ってます。
mypage.css
real#####.css
styletemplate_bc.css
これはhtml読めばすぐわかると思いますが。（#####は対象ブログのナンバーが入ります）

デザインカスタマイズで記述した内容は、real#####.cssに丸ごと入っています。
ほかの２つはユーザー側で弄られない固定ファイルです。
うちのブログの場合は、real30628.cssなわけですね。

うちのカスタマイズが気になるようでしたら、上記のURL直叩きで見てください。
コメントでも頂けるとうれしいですｗ
（本当は、その中にちょっと見せたくないURLとかあるんですがｗ）

で、問題の中心は、Iタグに設定した"ブロック囲い"。
このカスタマイズをしている件。

焦点は、この囲いが
「IEとIE以外のブラウザで表現が異なる」
という事です。




元々のIタグ設定 （CSSから該当部分を抜粋）

I {
　/* <I> [斜字]のカスタマイズ ◆ 現在の設定【枠囲み & 文字色・背景色付け】*/
　/*等幅フォント設定は現在停止中 → font-family:"ＭＳ ゴシック","Osaka－等幅",monospace ; */
　font-style: normal ; /* ←「Iタグ本来の機能（斜体表示）を無効化」 */

　color: #006080 ;
　background-color: #FFFFDD ;
　border: 1pt solid #FF9933 ;
　width: 98%;
　margin : 5px 8px ;
　padding : 10px 10px 10px 8px ;
}

これまで、上記のようにしていました。
特に、「width: 98%」となっている点が問題です。

本来、複数行で構成した要素（=文章）を罫線で囲うには、
まずはその要素の属性を「インライン」から「ブロック」に変更しなければなりません。
これは前のchibisaruさんのご指摘のとおりで、つまりこうなるべきです。

chibisaruさん的アドバイス
I {

　color: #006080 ;
　background-color: #FFFFDD ;
　border: 1pt solid #FF9933 ;
　display : block ;
　margin : 5px 8px ;
　padding : 10px 10px 10px 8px ;
}


こうすると、Iタグで囲んだ文字列がひとつの「ブロック要素」となり
単一行か複数行かにかかわらず、全体を囲う境界線を引く事が出来ます。

かつ、マージンとパディング（＝余白）が固定指定されている事によって
記事部分の幅に合わせサイズが自動決定されるというスグレモノです。



…ですが、これを使いませんでした。
当時（1年以上前）のわしはこれと同じ事を別の方法で実現しました。
それが前引用の「Width:98%」の箇所なのです。

そう、ブロック要素とせず、なぜかインライン要素のまま実現したのです。

IEでは、複数行の要素に対して横幅を指定すると、
インラインでありながらブロック要素のように扱われます。
このためブロック要素にした場合と同様、意図したとおりの囲いが形成されます。

なお、98%というほぼ行全体サイズへと強制している事で、
次の要素に何が来たとしても、その横に収まりきらない状況が発生、
その結果Iタグの次の要素はすべて、自動的に次の行へ送られるのです。

これで、インライン要素による擬似ブロック要素の完成というわけです。



しかし、これはIEがCSSを解釈した結果の挙動であって記述からするとあまり正しくはありません。
むしろ「インライン要素に幅を指定するとブロック要素として解釈する」IEの動きは間違えているとも言えます。

実際、他のブラウザではこのような実装になっているものはありませんし、
その結果今回の「IE以外での表示が正しくない」という事態を招いているわけで。。。


とはいえ、「FireFoxなどGecko系ブラウザの表示が正しいのか？」と言われると
「それも怪しいんじゃネ？」と言わざるを得ないんですが。。。


インライン要素が折り返して表示された場合にも、各行にはマージンとパディングが存在するはずですが、
しかしそれらが無視されています。実際、根本的な問題はこれです。
正確には、自らのマージンとパディングが自らに影響を及ぼしていない、という事です。


確かに領域の枠はこれらを踏まえた位置に配されますが、要素そのものの位置には反映されていない。
親要素から継承したline-height（行間サイズ）がそのまま適用されている…という事になるんでしょうか？
これが原因で、各行が前の行に被ってしまっています。
だから文字が読めなくなってしまっているのです。


この挙動が正しくないのでは？と考える理由はそこに矛盾があるからでして。

インライン要素だから行間の位置もそのままなのだ……とすると、
では、1行目の上側と左側、最終行の右側と下側では
マージンとパディングが考慮されているのはなぜか？
そして逆に中間行でこれらが考慮されないのはなぜか？


…この矛盾を解決するには、
・一行目と最終行の処理が間違えている
・中間行の処理が間違えている
このどちらかです。
どちらにせよ現在の実装が誤っている事になります。
へろは、どちらかというと後者のほうが正しいと思っていますが。

もしマージンとパディング、いや"領域"の処理が2行目以降にも正しく作用していれば、
表示はともかく、文字が読めなくなる事態は起きていないはずでした。





…で。こういった話をしても、結局のところ当ブログの問題は解決しないのでｗ
現実的に、うちのブログの問題を解決する方法を考えないといかんわけですよ。


そこでふと疑問が沸くわけです。今度は自分の矛盾とでも言いますか…。
わざわざ「インライン要素」として扱っているのはなぜか？という事です。
これを「ブロック要素」にしてしまえば、それで解決ではないのか？と。


確かにそのとおりなんですよ。（ぉぃ
chibisaruさんの指摘通り「ブロック要素」に直しますと、
IEでも他のブラウザでも正しく表示されちゃいます。そう、ある一点を除いては。

その問題となる点とは、記事内に画像がある場合です。


正確には、「フロートしてあるブロック要素が存在する場合」です。
当「破メモ」の場合、アップロードした画像が右側にフロートするように指定してあり、
この画像の横に来た要素（文章）はすべて左に回り込むようになっています。

Iタグで作られた「ブロック要素」も、この部分に来ると当然左側の領域に回りこみ…
そして引用画像の通り、なんと画像の下に潜ってしまうのです。
この現象はIEでもそれ以外のブラウザでも起こります。


フロートして回り込んだ場合、残りの幅が全領域として計算されるべきです。
即ちマージンとパディングも残りの幅に対して適用されなければならないと思うのです。

が、どういうわけかフロートを無視した元の幅から算出されています。
このため、Iタグで作ったブロック要素のサイズも横長に形成され、画像サイズを突き抜けてしまうのです。


そもそも、なぜブロック要素とせずに、あえてインライン要素のままにしていたのか。
その答えは、これだったのです。
インライン要素のサイズに%を指定した場合残りの幅から正しく算出してくれたのです。


そう、これはIE限定の解決策であったわけですが。
しかもブロック要素にすると、%指定してもやはり下側に行ってしまう。
%指定で回避するには、インライン要素でなければならなかったのです。


わしも忘れていた事実なんですが、
この「フロートがある場合の問題」を解決する術を見つけることが出来なかったため、
あえて、IEでしか正しく表示されない事を知っていて実装したのでした。



さて、chibisaruさんとのやりとりで出てきた「マージンとパディング側に%を指定する」というのも試してみましたが、結果は失敗でした。しかもIEですら意図しない形になりましたｗ


このままではFireFox等で全く読めない記事が量産されているわけで、
とりあえずの処置としてchibisaruさんのアドバイスに乗っ取った「ボックス」化を行いました。


この状態では「画像の横に囲いを使ってはならない」事になるんですが、
過去記事は特に該当するものが多くあります。
なんとか回避したいのですが、今もその方法を見つけられずにいます。orz

唐突に何を言うかとお思いでしょう。
えぇ、わしもそう思います。
最近S.A.C見てハマっている、ただそれだけですｗ


タチコマが欲しい、一家に一台！





（※画像は「1/24スケール ＡＩ戦隊タチコマンズ 製作日報」から引用させて頂きました。すげぇ！）
「AI戦隊タチコマンズのうた」

ひとーりで いても ふくすうけい！（ふくすうけい！）
せいべつー なんて ないけれどー

タチーコマンズはー （やーややー）
せいぎのみーかたー （やーややー）
タチーコマンズはー （やーややー）
へいわのあかーしー （やーややー）

わらいーじょうごーで なみだもろい
けんか いたずら どんとこい！（ほい）

いーのーちーは ないけれどー
いのちを すくう スーパーえーあい！ （えーあい！）

いーつか　てにいれるーぜ　あこがれのゴーストー
ああー　みんなのきぼーうさー　ばんのうロボットー

えーあい　せーんたい　タチーコマーンズっ！
（えーあい　せーんたい　タチーコマーンズっ）




当初、「AI！旋回！タチコマンズっ！」だと思って疑わなかったのは秘密。

いや、Doblogのバグの話ではないんですが…

当「デジ破」を IE以外（Firefox、Opera、Netscapeなど）でご覧になると、
デザイン不備により記事が表示されない（サイドバーの下端までぶっ飛ぶ）よーになっており、IE以外の皆様には大変ご迷惑をおかけしておりました。

で、そういえばこれ、こないだこっそり修正してました。
自分も忘れてましたが思い出したのでご報告ｗ


なお原因は、全角スペースでしたorz
CSS（カスタマイズ）の中に全角スペースがありました…
混ぜ込んじゃったわしもわしですが、これは発見するの苦労した…。

しかも発見方法が、
調査しても分からなくて煮詰まった頃たまたまエディタにコピペしたら、
特殊記号としてマーキングされたため偶然発見、みたいな。（滝汗

なお、IEだけはこの記述違反を無視しており、
全角スペースは半角スペースと同等に扱っているようです。
そのおかげでCSSを正しく解釈してくれてたんですね。

てか、大きなお世話ですな（汗

よし、これで全ブラウザ対応完了！

…かと言えば、まだ
ブロック要素の囲いがインラインになってしまう
とか残ってるんですが……

すいませんすいませんすいません…


どーやんだろ、いや何が問題なんだろ…。
分かったら直しまぁす。

と思ったら、午前0時には完全にストップしてたようですね。


1ヶ月近く音沙汰も無かったところに、
突然出された「緊急メンテのお知らせ」。（しかも"修正"ではなく、"調査"のため）
実施期間はなんと翌日。昨日の今日ならぬ今日の明日ですよ。
それはそうと、その停止期間は14時～16時の2時間ほどだったはず。


それが、どう間違えたら0時～17時、合計17時間停止の大メンテになっちゃうんでしょうか。

「メンテやってみたら、予期せぬ事態で終了が延びた」んならまだ弁解の余地もあります。むしろ延びるのはみんな覚悟してます。わしなんてその夜ずっとダメというところまで想定してます。

が、なぜに事前連絡なしで大幅前倒しですか？
そして、そこまでやってなぜ元の予定時刻すら超えますか？
わけがわかりません。
（単に鯖ダウンして、そのまま放置だったのかもしれないですね）


あぁ…、ほんと…、もう…ガクーン。orz



Doblogさん、なんで憶測してまでメタメタに言われるかわかりますか？
「経緯と結果を説明しない」からですよ。

------------------------
なお、この件はスタッフブログのコメントを読んで知りました。

そこには
「朝6時から書き込みが出来なかった」
「日付が変わってからメンテまでアクセスが出来なかった」
ことが書かれていました。

今日の午後5時半、当ブログのカウンタ表示を見たとき、「5件」でした。
この件数が正しいとすれば、少なくとも毎日10人以上来て下さっている午前0時台は完全に閲覧できない状態であったという事になります。それ以降の午前中も、ほぼ0件というのは有り得ません。この件数の少なさから、わしは一日中ずーっと落ちていたのだと判断するに至りました。

-------------------------------
【追記】

自前で搭載してた別のカウンタの事を思い出しました。
これがその画像です。
どうやら2時、3時にアクセスが1件あったようです。

ということは、午前0時から完全停止ではなかったのかもしれません。
かもしれないというのが、完全にメンテ中の15時にも1件アクセスがあるからです。
一時的に閲覧可となったのでしょうか? 謎です。

あぁそれと、前日の23時からアクセス数はオカシイです。
おそらく午前0時ではなく、前日23時から停止状態に陥っていたのではないかという新たな脱力ポイント発見…。

（※ この記事は一応、随時更新されますです）

夢から目が覚めると、開いたドブログのページが始終やたらと軽い。
勝手にログアウトもされず、書いた記事は絶対に消えず、
スタッフブログですべてのコメントに懇切丁寧に返事が書かれ、
開発者日記では夢のような新機能の話に花が咲いており、

すべてのドブロガーはニコニコと記事を書き上げ、
ソワソワもせずビクビクもせずに何のためらいもなく
サクッと記事投稿ボタンを押していくのだ。

…わぁ素敵なDoblogだなぁ、夢のようなドブログだなぁ、と思ったら夢だった。すべて。
そんな夢見がちなデジ欲侍へろです、ども（ﾉ∀｀）


ページが開かん！とかいう具合の不都合はいつもの事ですが、
バージョンアップで生まれ変わったドブログは、
不都合までもが超絶パワーアップしてそれまでどころじゃないわけで。

いやホント、そこは超絶パワーアップしてくれんでいいからｗ
Doblogコロコロ、Doblogコ～♪　おバグにハマってさぁタイヘン♪（ドングリかよ

で一ドブロガーとしてなんか出来るかなーと思ったところ、
とりあえずバグの一覧出してTB報告してみようかと。(※スタッフブログでバグ報告を受け付けてます）

第一、公式のバグ一覧ってドブロガーにとって微塵もアテになってないズェ。orz


新ドブログで起こっているバグ一覧　（マッタリと随時更新）
1) [作業中] Doblogツールバーでの投稿、ログインができない。（お知らせ・スタッフ）
2) [解決] 「トラックバックを書く」を用いた記事の関連リンクが誤っている。※（お知らせ・User記事）
3) [解決] 自分の訪問者リストに自分の名前がある。（スタッフ）
4) [解決] 削除したコメント、TBがサイドバーの新着リストから消えない。※（スタッフ・User記事）
5) [解決] 記事が1件もないユーザのRSS0.91をクリックするとエラーとなる（スタッフブログ）

6)[解決] 初回表示時にMyDoblogのデザイン・レイアウトが崩れる。※（スタッフ・User記事）
7) [作業中] 更新Pingが正常に動作していない。（スタッフ）
8) [作業中] 他の人と投稿時間が重なった時、サムネイル画像が入れ替わる。※※※（スタコメ・User記事・本記事TB）
9)　───　（欠番：　重複してたのでバグ1に統合）
10a) [作業中] Netscapeで「混雑」エラーなどで記事投稿できない。※※（スタッフ・User記事・へろ記事）
10b) [作業中] FireFoxで「重複投稿」エラーなどで記事投稿できない。※※※※（スタッフ・User記事・へろ記事）

(FireFoxの方へ：IE Tab （Firefoxユーザーがちょっとだけ楽に投稿する方法））

11) [解決] サイドバーのTBを開くとナビゲーションバー無しのウインドウ表示。※（スタコメ・本記事TB）
12) [解決？] 移行前に投稿された画像が存在せずリンク切れになっている。※※（スタコメ・本記事コメ）
13)　───　（欠番： 重複していたのでバグ8に統合）
14) [解決] トップページ(ポータル?Mydoblog?)が文字化けしている。（スタコメ）
15) カスタマイズのプレビューで長いTBタイトルが折り返さず表示が崩れる。（スタコメ）

16) [解決？] ドブログポータルの「自動ログイン」で「混雑」エラーが出る。（スタコメ）
17) [仕様？] 各記事リンクの挙動（ページ内容）が変更されている。※（TB）
18) MyDoblogページなのに自動ログインしてしまう。※（TB）
19) 新規投稿で「異常な値が設定されています」エラーが発生し投稿できない。※（TB）
20) 一部の「この記事のURL」で表示が誤っている。※（TB）

21) [仕様？] アクセス数の切り替えが0時付近にされている。※（TB・へろ）
22) IEで同じ記事URLを2度以上連続で開くと記事に飛ばない。IEのみ。（IEの仕様？）（へろ）
23) [解決？] 自分で表示してもアクセス数が増えてしまう/再読込でもカウントされてしまう。（へろ）
24) [解決？] ポータルで自動ログインを選んでいると、MyDoblogからログアウト出来ない。（へろ）
25) [解決？] 投稿のエラー時に内容を表示するが、シーン1しか表示されない。※（本記事TB）

26) [解決] メールお知らせ機能で、既存記事の編集を行っても送信されてしまう。※（本記事TB）
27) サイドバーに表示されるTBやコメントの件数が実際より少なく表示される。※※（本記事TB）
28) [作業中] ポータルの新着記事の一覧に表示されているサムネイル画像が違う。※（User記事）
29) [解決] 「この記事のURL」の表示でリンクがJavaScriptになっている。（へろ）
30) [解決？] サイドバーが横長になりレイアウトが崩れる。※（User記事)

31) [仕様？] 記事コメントのURLが、メンテ前とメンテ後で仕様が違う。※（TB）
32) [仕様？] RSS0.91/1.0/2.0/ATOMで時間が9時間ずれている/日本時間が標準時に。（本記事コメ）
33) [仕様？] MyPictureにGIFを指定するとPNGに変換されてしまう。(本記事コメ)
34) MyPicture削除時「Doblogユーザ以外のコメントを受け取らない」が勝手にONに。(本記事コメ)
35) [解決？] 訪問者リストの区切り線「<hr>」が無くなっている。（本記事コメ）

36) [解決？] ジャンル表示のHTMLに記述ミスがありデザインが崩れる。※(本記事コメ・User記事)
37) 「今日のアクセス数」がAM0時にリセットされず増え続ける。（へろ）
38)　───　（欠番： 重複していたのでバグ12に統合）
39) ポータルでブログ検索を行うと、ナビゲーション無しのウインドウになる。（へろ）
40) [解決？] サイドバー「最新記事」内の記事URLにSessionID等が含まれている。（へろ）

41) [仕様？] ログインのタイムアウトが長くなっている。/少なくとも50分以上　（へろ）
42) サイドバーの新着コメント・新着TBにPの開始タグが足りないか終了タグが多い。（へろ）


┏━【 カッコの意味 】━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　[解決]→公式に解決した事が発表されたもの。
　[解決？]→発表はないが、現在解決していると思われるもの。
　[作業中]→公式に発表で確認されており、現在調査中または修正中のもの。
　[仕様？]→発表はないが、バージョンアップで変更された仕様と思われるもの。
┠─────────────────────────────────────────┨
　お知らせ→公式発表　スタッフ→スタッフブログ　スタコメ→スタッフブログコメント
　TB→スタッフブログにTBしているドブロガーさん記事　User記事→発見したドブロガーさんの記事　
　本記事TB→TBして頂いたもの　本記事コメ→コメントして頂いたもの　※印→該当記事リンク┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛


なんか旧バグも織り交ざってる気もしますがキニシナイ。
上記以外のバグやツッコミ、解決・未解決に関する事など
何かありましたら是非コメントorTBでお知らせ下さいませませ。



┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　　※ここにあった古い更新内容は移動しました。
　　　　　（こちらに保管してあります）
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓

　・バグ12（旧記事の画像が消えた）にしっぽさんのリンクを追加しました。
　・Doblogスタッフブログの新記事にTBを送りました。

　今更ながら過去の画像が消えたしっぽさんの記事へリンクを張らせて頂きました…が、今見に行ったらすでに直ってましたｗ　他の方のもスタッフさんに言っている方はもう直ってますね。

　実は当時、わしは該当記事を見ておりました。
　確かに画像はサムネイルもろとも消えているのを確認しました。

　リンクURLが間違っているかも？と思って見てみると、どうも旧URLのままのようでした。
　しかし、何件か検証してみましたがimgで始まる画像URLを作り直接アクセスしても表示する事は出来ませんでした。

　つまり、URLの変換だけではなく画像そのものの移行にも失敗していた事になります。
　この事からバグ12の名称を「リンク切れ」とせずに「画像が存在せず」と付け加えました。
といってもリンクミスだったのかもしれませんが、
本当の原因は運営側にしかわかりません。


　しかし、この問題で本当に怖いのは「全ユーザーの過去記事が破壊されている可能性がある」事です。
　わしの過去記事も画像が壊れているかもしれません…。

　というより、今回の一連のバグの中でも厄介な問題は、随所にいろんなリンク切れが発生している事です。
　各バグをチェックしてみると、システムのあちこちでリンクの変換ミスが多発しておりそれがバグそのものであったり、バグを誘発している原因になっているだろう事が見て取れます。

　一番危惧している事は、このバグ12の解決が「バックアップからの手動復旧」という手段で行われたのではないかという事です。
　上記のしっぽさんのように偶然自分でミスを発見できた方々は運営側に自己申告しています。「申告したから修復されたではないか」と思えてならないのです。

　もしそうだとすると、現時点で気付いていないドブロガーさんの画像は未だに消えたままのはずです。
　そしてしばらくするとバックアップも破棄され、その時点で永久に消滅する事になります。
　記事数が多い方は特に過去の画像抜けなど気付けるはずがありません。
　自主的に探そうとしても、簡単に探す事が出来ないでしょう。

　これを回避するには、Doblog運営側でリンク切れをすべてチェックするしかありません。ていうかして下さい。お願いします。

　なお、しっぽさんやCAMUSさんその他多くの方によれば、過去の記事に貼り付けていたURLがリンク切れとなっている問題も多発しています。

　画像ならまだパッと目で見て分かりますが、ページのリンク切れを確認するにはすべてクリックして回らねばなりません。もしくはなんらかのリンク切れチェックソフトを用いてページをすべて絨毯爆撃していく方法も考えられますが、皆がそれをやるとDoblogの通信量は大幅に増大すると思われます。また回線が遅いユーザーは不可能です。

やはり、運営側で検索をかけるほうが遥かに効率の良い解決法と言えます。
っていうか壊したのも運営側なんですけどニャｗ

　今まで取り上げなくて申し訳ないんですが、
　このバグ12って実は非常に怖い問題だなぁと思ったわけだズェ。

┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [ 更新日時：2006/06/23 22:49 ] ━┛


┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓

　・新たにバグ41（ログイン時間の延長）を追加しました。
　・新たにバグ42（サイドバー新着のPタグ）を追加しました。
　・23日以前の過去の更新履歴を別記事に移転しました。


バグ41は多分、新しい仕様だと思いたいので[仕様？]マークとしました。
状況としては、自動ログアウトまでの猶予時間が少なくとも50分以上に延長されているようです。
以前はたしか30分未満でした。これにより、記事を記入中にタイムアウトしてしまって送信ボタン押した瞬間消滅という憂いが激減することでしょう。
ただ、なんか「jsessionidの誤出力」とか「ページ内自動ログイン」などのバグに付随するもの、かもしれず。そうだと悲しいですな。

新しいバグ42ですが、サイドバーの中の「新着コメント」「新着TB」内において</P>タグが多く追加されています。
具体的には元となる記事リンクの下に連なるブロックそれぞれに</P>タグが付いていますが、その開始となるタグが見当たりません。

ところで、HTML内のURL部にはjsessionidが山のように配置されているのを確認しました。
ですが、表示上は何も無かったように表示されたりしていますし、右クリックからリンクのコピーを行ってもjsessionidが含まれないURLが取得できます。(IE6)
へろ的にはjsessionidは（できれば見せないほうがスマートなんだけどまぁ仕様としては）「見えても良いもの」と認識しています。
といってもわしはネットワークに（特にサーバー系のシステムに）激しく疎いためアレなんですが。。。
とういことで、HTML内にjsessionidが見えてるという件はバグではなく正常な動作の一環であろうと考えています。ご意見があればバグ一覧表への追加も検討しようと思います。

それはそうと、なんでHTMLの中には書いてあるのに表示されないのかが非常に気になります。単に外部スクリプトにそれを消すサブ関数でも入ってるんでしょうか？

┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [ 更新日時：2006/06/26 15:36 ] ━┛


┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓

以前話した一覧表の記事分離化の件ですが、そこまでしなくてもいっか、という思いになって来たというか、いわゆるメンドクセー症候群が発症しましたのでこのまま行きます（ぉ
しかしまぁ、ちょっと長いし、直ってないバグと収まったバグに分離してみようと思います。
予定としては今日か明日行う次回更新にて。

┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [ 更新日時：2006/06/26 16:35 ] ━┛


┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓

・バグ8にリンクを追加しました。（Wisdom96さん提供）
・バグ10a、10bにリンクを追加しました。（へろ記事）
・バグ10aを[解決？]に変更しました。

またまたTBを頂きました。Wisdom96さんありがとうございます。
26日現在、まだバグ8は発生しているという報告です。orz
さすがにもう直ってるんだろうと思ってましたが、まだまだご健在のようです。
わしも昨日普通に画像投稿しましたが、わしの画像がどなたかの所に紛れ込んでいなければ良いのですが…。

バグ10a、10bについて自ら試して見た結果、26日時点で10aは起きず、10bは発生していました。
参照 ： 「新生ドブログでFireFoxとNetscapeを試してみたYO」

前々回話した「jsessionidは表示はされないがHTMLには残っている」という件ですが、どうやら勘違いだったようです。すいません。
あのあと再度確認したところ、HTML内のURLにも含まれている箇所はありませんでした。あのときは初回アクセス時のものを見ていた可能性が出てきました。

あれから、わしもそれなりにjsessionidの仕組みについて調べてみたら、

１）jsessionidはドブログユーザーを一意に特定するために使われるワンタイムIDのようなもの。
２）IDはできるならcookie内に置き内部的に処理すべきだが、cookieが使用できない場合はURLの中に含めて対処する。
３）今回cookieが使える状況下でもURLにjsessionidが含まれてしまうバグが発生した。

というのが大きな流れのようです。
この手順によれば、cookieがまだ無い初回アクセス時はURLにjsessionidが追記され同時にID入りのcookieが配布、以後は本来のURLに戻るという動作をします。
初回のみ画面が崩れるバグ2はここに原因があるとわかります。

またCAMUSさんがコメントで簡単な説明を下さいましたぁ。ありがとです。
この中で、「jsessionidが表示される現象と画像の取り違えバグのコンビによってブログ乗っ取りが起こり得る」との事です。ガクブルです。

ところで、FireFox等でうちが読めたもんじゃねぇ件、可及的速やかに対処いたします（滝汗

┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [ 更新日時：2006/06/27 13:01 ] ━┛



┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓

・バグ35を[解決？]に変更しました。

　お久し振りです、バグ一覧表、ちょこっとだけ更新。
　訪問者リストの横線が復活してましたので、[解決？]に格下げ(?)しました。
　他のものは全然調べてないのでわかりません。（ぉ

　今日、7日ですね。
　このバグ騒動は先月の6月15日から続いているわけですから3週間経過です。
　もう少しで1ヶ月間バグったままですね。おめでとうございます。
　その間に出されたお知らせは、スタッフブログ含めてたったの4回。
　あ、なんでだろ、見上げた夜空が霞んで見えますよ。

　そういえばjsessionidの件、なんだか致命的ポイらしいです。（じいやさんによれば）
　
　次更新するときこそは、解決と未解決に分離しよう。頑張れわし。（すいません）

┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [ 更新日時：2006/07/07 00:38 ] ━┛


┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓

・バグ25を[解決？]にマーク変更しました。（CAMUSさん提供)
・バグ36を[解決？]にマーク変更しました。（CAMUSさん提供)
・バグ22の[仕様？]マークを撤回しました。

次こそは…と言いつつ、同日に臨時アップデートです。
CAMUSさんからコメントでバグ解決情報を頂き、こちらでもバグ25とバグ36の修正を確認しました。
あと、バグ22ですが、別のブラウザ（FireFox・Opera・ネスケ・Sleipnir）ではちゃんと#アンカーに飛びます。IEコンポーネントのSleipnirでさえ。
ゆえにIE側に起因するバグとも仕様とも思えます。
当初Doblogからすれば「仕様」だろうと考えましたので、そのようにマークしておりましたが、IEを対応ブラウザとして掲げる以上「IE仕様上での正常動作は保証しなければならない」だろうと考え直しましたので撤回します。

記事URLのページを開いたとき該当記事がトップ位置に来ていた従来の表示法なら回避できるはずです。
しかし、このバグは実際にはURLを押した場合は問題なく、アドレスバーの移動を押したりF5キーで更新したりした場合ににみ発生します。まぁ実質は実害はないとも言えます。

　あ、あとCAMUSさんがコメントで「もにょもにょ」と教えてくれたんですが、
新たにトンでもない危険バグを発見しちまったらしいです。
詳細はちょっと公表できないとか…。
　まじっすか？(;´Д`)ﾄﾞｷﾄﾞｷ

┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [ 更新日時：2006/07/08 01:12 ] ━┛