海の近くに住みたい
公開日時： 不明
朝からパチ屋へ行くつもりだったが起きれなかった。凄い疲労。毎日筋トレしてるせいだろうか。腕立て伏せと腹筋と背筋を20回ずつ。常人にとっては準備運動にもならん程度だが俺にはかなりキツイ。5年半ぐらい前は毎日100回ずつはやってたはずだが今は無理。腕立て20回やると立ち眩みみたいな状態になるし呼吸できんし自分が何やってるかわからんような状態になる。そのまま腹筋背筋を死に物狂いでやって気絶という毎日だ。そのせいで疲れてるんだろうか。それともパチンコだろうか。昨日はパチ屋に行ったんだったっけ？パチ屋へ行くのも行かないのも別に珍しいことではないし、毎日同じ事の繰り返しみたいな感じがするので昨日行ったのか一昨日行ったのか、それともしばらく行ってないのか、全く分からない。パチンコのデータを記録してるメモ帳を見れば分かるんだが、好きでもないもののことをイチイチ考えるほどマゾじゃないので放置。とにかく疲れてて朝は起きれなかった。厳密に言うと一応は起きた。松本孝弘のHouse Of Stringsが8時15分頃に激しい爆音で流れたから。でも目を覚まして腕を伸ばして電源切って終了。その際に腕を攣って猛烈に気分が悪くなった。吐きそうになりながら何で俺ばっかりこんな目に遭わねばならんのだ！とか思いながら気絶した。そして14時半頃起床。今日は例のCGI作成の仕事の報酬が振り込まれる日だ。10日までには振り込むと前のメールに書いてあった。急がねばならぬ。ケーブルテレビに引き落とされるのと同じ口座なので、ウンコエナジーがタイミングを絶妙に合わせてきてケーブルテレビに抜かれてしまう。普通の人は、どうせ払う金だからそれで払えばいいと思うのかもしれんが、俺の場合は金を稼ぐためには種銭が要る生活なのでダメなのだ。月末になれば勝手に金が入ってくるのではない。毎日金を葬りながら増やしていくのだ。手元に金を残しておかねばならん。だからケーブルテレビには悪いがもう少し待ってもらう。ケーブルテレビに引き落とされる前に下ろさねばならん。先々週ぐらいに払ったのはテレビの分だけで、ネットの接続料は数ヶ月滞納という状況だ。とにかく銀行に行かねばならん。めんどくせぇ。
とりあえずメールを受信。そしたら美探管理者（CGIの仕事やらせてもらった相手）からメールが来てた。携帯電話対応版検索CGIの動作テストの結果、エラーは無いとのこと。まぁそうだろうと思ってたのでそれは別にいい。しかし、PC版で、ある条件で検索するとアホみたいに表示に時間が掛かるという。その件について調べて欲しいと書いてあった。さらに、金は早ければ明日、遅くとも月曜までには振り込むと書いてある。今日までに振り込むんじゃなかったのかよ。餓死しちゃうぞ。で、まぁ仕方がないので、とりあえずその表示が遅くなるというのを試してみた。確かにおかしい。まともに見る気がしないほど遅い。ありえない。何が起きてるかはわからないが、他の検索条件で実行した時とは明らかに違う。店舗の情報量が多くなり過ぎてサーバーのメモリ消費量が多くなったことでそういう事が起こってるんじゃないかと思ってみたりした。それにしても遅すぎる。テキストデータだけで多くても数十KB程度のものを配列に読み込んだところでそんなに遅くなるはずがない。原因不明。思い当たるフシがない。それはとりあえず保留しておいて、携帯版の方を見てみた。俺が作ったのはCGI部分のみで、実際に表示されるHTMLや、CGIを呼び出すHTMLは向こうが作ったものだ。向こうから貰ったHTMLをCGIが書き出すという部分についてはおかしなところを一部勝手に修正したりもしたので問題は全く無いはずだが、CGIを呼び出す一番最初のページは俺はノータッチで全部向こうに任せてあるのでその部分がめちゃめちゃ不安だった。CGIに渡す値等は指示しておいたんだが、今までの事を考えるとたぶんちゃんとやってないだろうなと思ってた。で、ソースを見てみたら案の定だった。美容関係の店を検索するサイトなんだが、検索カテゴリーは業種とエリアとフリーワードの3種類ある。同時に複数カテゴリーで検索できるようになってるんだけどフォームを別にすることで単独検索もできる。そういうCGIなんだが、その検索元のページのソースを見たらフォームが2つあって、1つは業種＆エリアの検索、もう1つはフリーワード検索になっている。で、エリアの選択フォームでvalue属性が空欄のoption（値を送信しない＝検索しない）が無かったので1つ目のフォームで検索する際には必ずいずれかのエリアが指定されるように記述されていた。業種のみで検索することができない状態。業種は、本来optgroupで指定するoptionのグループ化の部分の見出し語を、i-modeがoptgroup要素に対応してないためにoption要素で代用し、そのためにvalue属性値のないoption要素（value属性の値が無いだけでなく、value属性自体が無いとoptionの開始タグと終了タグの間にある文字列が勝手に送られるので注意が必要）が作られたという多分深く考えられてない偶然によってグループの見出し語（のつもりのoption）を選択すれば何も値が送信されない状態（利用者はそうは思わないと思うけどどうなんだろう）になるようになってて、ここは上手くやれば業種未選択でエリアのみの検索は可能な状態だった。まぁこれだけでもずいぶんアクセシビリティが低いと言わざるを得ないが一応動くことは動く。しっかり動作チェックしたら不具合に気付くはずなのでエラー無しなどとメールが送られてくるのが不思議でならない。もう1つ致命的なのがあって、フリーワード検索のフォームで、input要素（検索語入力欄）のname属性の値をwordにしないと検索CGI側で正しく値を受け取って処理することができない。だからフリーワード検索のフォームフィールドのname属性の値はwordにしてくれと指定しておいた。これは昔に作ったPC版の頃から何も変わってない。この部分がname="textfield"となっていた。きっとどっかのHTMLエディタ（ホームページビルダーとかそういうやつ）でフォームフィールドを置いただけでソースをじっくり手直ししてないんだろうと思う。ブラウザとかで表示すれば見た目は同じだからな。完璧に手打ちしかしない俺には信じられないことなんだけどもHTMLエディタを使う人はよくこういうミスをする。結果、name属性が違うのでCGIに送ってもその値は相手にされない。つまりフリーワード検索は実行されない。何を打ち込んでも検索結果0件になる。動作チェックしてないんじゃないの？って激しく思った。携帯電話でアクセスしてみて、画面に表示できるかどうかだけを確認したんじゃないかと思えてならない。前からそういうフシがあったしな。どう表示されるかという事のみにしか興味がない感じ。だから論理的に全く必要ないタグも余裕で使いまくってファイルサイズが無駄にデカくなったり、仕様に沿ってない危なげなページを作ったりする。まぁ俺がやるのはCGI作成の部分のみなので、向こうが作るHTMLがいかにヤバイ物でもあまり口出しはしない。だが、CGIを起動させられないフォームを置いたページなんか作られたらたまったもんじゃない。それはCGIなんか元々要らないって言われてるようなものだ。CGIを利用者が起動できる最低限のページでなければならない。だからその事をメールに書いて返信しておいた。特定の検索で動作が重くなる件は原因不明なので色々考えてみると返事しておいた。
さて、一部の検索で動作が重くなる件に関しては、色々考えると言っておいたけどめんどくせぇし、放置してやろうかとか思ってみたりしたんだが、まぁ一応見ておくかと思った。なんだこのやる気の無さは。向こうにとってはかなり深刻な問題なのにな。まずFTPで向こうのサーバーにアクセスして（外注の他人にFTPアカウントとパスを教えるってのもなかなか凄いと思う。まぁ実際に会って遊んだこともあるし、ネット上では長い付き合いだし、そこそこ信用されてるのかもしれんが。）現在稼動している俺が作ったCGI全てと、登録されてる店舗データ（ディレクトリごと全部）自分のPCにダウンロードしてみた。で、港区でエリア検索すると2件しかヒットしないはずなのにその2件の表示が遅いというので、港区で登録されてる2店舗に絞って見ていこうと思った。まずは店舗の情報（紹介文とかメニューとか金額とかのデータ）が書かれてるデータファイルをテキストエディタで開いてみた。これは全部で402項目あって1項目1行で記述されている。何も設定されていない項目でも空文字列+改行という形になっていて、何行目が何のデータかということはキッチリと決まっている。だからどのデータファイルも402行しか無いはずなのだ。しかし、何故かその店舗のデータファイルは数千行もあった。これはおかしい。原因は明らかにこれだ。データ量が増えると処理が重くなるので、ファイルの中身を一気に配列に読み込んでしまうという方法はあまり使われることはない。掲示板のデータの処理等で深刻な事態が起こるかもしれないからだ。でもこのCGIでは402項目固定なのでそんなことは考えなくても大丈夫だろうということで、コードが簡単になるから（手抜きと言えなくもない）一気に配列に読み込んでしまって、各データには配列の添字を指定してアクセスする形式になっている。その402行のつもりのデータファイルが数千行になっているので、サーバー上で消費するメモリが格段に増えて処理が重くなっていたのだ。これはもう明らかにどこかに俺のプログラムミスがある。データファイルを更新するたびに余計なデータが追加されていくに違いない。一応全店舗のデータを見てみたが、店舗ごとにデータファイルの行数が違う。更新した回数によって変わっていくというので間違いないだろうと思う。ということはあの辺りにミスがあるんだなと目星をつけ、店舗編集CGIのデータファイル更新部分のサブルーチンを見てみた。一見何もおかしいところはない。メイン編集とメニュー編集の2系統に分かれてるんだが、データファイルは1つ。1〜82行ぐらいがメイン部分のデータ、残りがメニューデータということになっている。データ量が増えても実際に表示されるデータはちゃんと決められた場所に表示されているので、データの記録部分がズレているということはない。ということは末尾に不要な要素が記録されているということだ。実際に見てみたら403行目以降は改行コードのみだった。Perlではファイルを配列に読み込むと1行を1つの要素として扱うように処理される。なので、ファイルの行数＝配列の要素数とも言える。要素数が桁違いに増えているのでメモリ消費量がとんでもないことになっていたんだろう。昔、MSXのBASICでプログラミングしてた頃、当時はメインRAMが64KBしかなくて、ちょっと大きめの配列を宣言しただけでOut of Memoryとかいうエラーが出たものだ。配列はメモリを食う。いかに配列を使わずにプログラムするかという工夫をしなければならなかった。その体験があるので、この事態の恐ろしさは容易に想像できる。メイン編集を実行した場合、1〜82行目の変更部分を上書きしたものを一時変数に書き出し、新たなデータファイルにその変数を書き出し、その後ろにデータファイルの83行目以降のメニュー部分（更新されていない部分）を追加して書き込むという仕組みになっている。ここがおかしいに違いない。更新されてないメニュー部分を追加するという部分だ。この部分はデータファイルを全て配列に読み込み、その配列からspliceという関数で83行目以降を取り出していた。その後半部分だけの配列を、例えばprint FILE @array;のように書き込んでしまうと、1要素1行という形式では書き込まれない。全ての要素が連続して1行で書かれてしまう。なので、要素ごとに改行コードで区切って書き込む。あとで読み込む時に1行1要素として読み込まねばならないからだ。で、print FILE join("\n", @array), "\n";と書いていた。配列の要素を改行で区切って記録ということ。最後の要素にも一応改行コードをつけておいた。最後だけ無いのもおかしいからね。で、おかしいとすればここなんだが、別におかしいと思える部分はない。でも更新するたびに最後の改行が増えるというならここしかない。最後に改行コードが想定してるよりも1個多く付くんだろう。それを配列の要素として処理されるので、配列の要素を改行コードで区切って書き込みという部分で中身の無い要素を改行コードを追加して記録していくことになる。つまり更新するたびに2倍ずつ増えていくのだ。これは恐ろしい。10回更新すると1024行も増える。その先は考えるのも恐ろしい速度で増え続けてしまう。更新しない部分の配列としてspliceで切り出す部分で、spliceの第3引数（切り出す長さ）を省略すると配列の最後までということを意味する。82から最後まで、と考えてそう書いていた。しかしこれがどうやらダメだったようだ。最後にファイルに書き出す時に最後の要素にも改行コードを付けようという発想がダメなのかもしれない。とにかくこの2箇所を訂正した。82から320行抜くということにして、書き出し時には最後に改行をつけない。どっちみち読み込む時に全ての要素の末尾の改行コードをchomp関数で削除してから使うので問題はないはずだ。そのように修正してから、そのままいきなりサーバーにアップする勇気はないので自鯖で実験。過去に開発中に適当に作った仮想店舗のデータで実験する。その仮想店舗のデータファイルをエディタで開いてみてビックリ。402行とか数千行とかそんなもんじゃねぇ。数十万行もある。もっとあったかもしれない。恐ろしいファイルサイズだ。何故今まで気付かなかったのか不思議で仕方がない。とりあえず手動で403行以降を削除してからCGIを起動。そう言えば昔、自鯖のPerlがバグってアホみたいにメモリを消費してまともに動かないとかこの日記にも書いたと思うんだが、あの原因は間違いなくこれだと思う。ほんとにアホだな。数十MBのテキストファイルを一気に配列に読み込むなんてブルッちまうぜ。で、403行目以降を削除したデータファイルを使って店舗データ編集CGIを起動してブラウザ上から色々項目を弄って更新してみる。しっかり動いた。最後の要素に改行が付かないのが今までと違うが問題はないはずだ。一応もう一度編集CGIを起動し、最後の要素（メニュータブ8のメニュー8のコメント）のフォームを見てみた。データファイルに値があれば最初からフォームに書き込まれた状態のページが表示される。これは改行コードが末尾にあっても削除した状態でtextarea要素の中身として書かれるので問題ないはず。問題無いと思っても実際には問題があったりする場合があるので一応確認だ。でもやっぱり問題はなかった。もう一度更新してみてデータファイルを直接テキストエディタで見てみたりしたが、メニューを更新した時と、メイン部分を更新した時でラストの要素に改行が付いたり付かなかったりする。どちらでも問題は無いが何となく気分が悪い。でもここにはこだわる必要がない。spliceで切り出す長さを指定したので、もし変なデータが付け加えられても更新するたびに403行目以降は切り捨てられる。大丈夫だ。あとは、実際に向こうのサーバー上で動いてる店舗のデータファイルだ。これを全てテキストエディタで開いて403行目以降を削除し、FTPで向こうのサーバーにアップロードしておいた。結構ドキドキする。アップ先のディレクトリを間違えると大変だ。店舗Aのディレクトリに店舗Bの情報ファイルをアップしてしまったりしたら最悪だからな。慎重に確認しながら更新。その後で修正した店舗編集CGIをアップロード。これでOKだ。そして、原因を解明して修正した旨をメールに書き、最新版の店舗編集CGIを添付して送った。これで大丈夫なはず。一応念のためブラウザでアクセスして港区で検索してみたら快適に検索結果が表示された。めでためでたし。
腹が減ったので飯を食った。そしてうたばんを見た。何もやる気にならない。久しぶりに歌番組とハロモニ以外の番組をボーっと見てみたりした。でもすぐ飽きたのでやめてネット。愛キュンJaneで狼のスレをいくつか適当に読んでみたりした。でも疲れたのでヤメ。何もやる気になれん。でも眠くない。軽くギター弾いてみたりしたけど指が動かない。なんでこんなに無気力なんだろう。今日は何もしない1日だった。椅子タンが昨日ぐらいの日記で書くことがないみたいな事を書いてたが、何もしない日でも書こうと思えばこんなに書けるんだぞ。毎日毎日何もしなくても無尽蔵に書くネタが出てくる。むしろ何もしない日の方が饒舌。何か特別な事があった日は逆に「今日は何もしなかった」とか書いて1人でゾクッとしながら快感に打ち震えるのだ。そう、お前の思ってる以上にキチガイなのだよ。
| 公開日時 | 不明 |
|---|---|
| 本文文字数 | 7198文字 (タグ込み) |
| URL | https://orca.xii.jp/br/diary/diary.cgi?id=dogoo;date=20050310 |
コメントはありません。