＞
結城浩の日記 ＞
2005年6月
|
＞
結城浩の日記 ＞
2005年6月
| 検索 |
| プロフィール | 日記一覧 | 日記ダイジェスト | Twitter | RSS |
|
天の父なる神さま。 今日の一日も、あなたにすべてお委ねいたします。 イエスさまのお名前でお祈りします。アーメン。
月曜日はたんたと仕事。…ん？ ちがう。 月曜日はたんたんたと仕事。 あれ？
たん、たん、たんと。たんとたんたん。たん。とたんたん。とたんととたんと。たんとたんたんタンジェント。 たんとたんたんジェントルマン。たんとととるーとトルーマン。たんとくるくるマントル対流。 たんとる、ル・マンと、たんと溜まると。まるまるまるっと仲間と止まる。 止まる、ととまる、とととまる。とととととまるとおっとっと。 とっとと走ると、橋を走ると橋場知る。ばしばしばしると、岩ばしる。 萌え出ずる春と、いわば知る。 天知る、地知る、人ぞ知る。 るるるる、るるる、るるるるる。 るるるのはるに、春かえる。 蛙の春に遥か得る。
…淡々と仕事。
げ。 何個かの「仕事のかけら」は方針が間違っていたことが判明。 ここ3日分の仕事がまるまる無駄になってしまいました。 大ショック。
（…約10秒…）
まあ、でも、時間は無駄にしたけれど、 この3日分の仕事は破棄したほうが結果的にはよくなりそうだな。 それに、うまく改造すれば、別の場所で使えそうだしな。
というわけで、立ち直りっ。
いまあわてて修正すると間違えそうだから、 ここまで一回svn commitして、明日きちんと修正に入るとしよう。
感謝・感謝。
昨日は月曜日。今日は火曜日。
昨日は過ぎて、今日が来る。
昨日は、昨日の仕事をしました。 今日は、今日の仕事をします。
感謝しつつ。
月曜日は淡々と仕事。
無理のないサイズに仕事を分割し「仕事のかけら」をたくさん作っておく。 そして毎日決まった時間に「かけら」を手にとり、一個ずつ片付けていく。 無理のないサイズに分割しているから、時間は大してかからないし、 仕事にかかるときの心理的障壁も低い。
ワインバーグがこんなことを書いていたと記憶している。 「よい問題解決者は、大きい問題をひとつ抱えていることはない。 いつも、中くらいの問題をたくさん抱えている」
大きな問題をひとつだけ抱えているのは、 ブレークダウンが下手な証拠だ。 あるいはまた、 プラグマティックに問題を解決しようとしていないのかもしれない（「私はこの大きな問題を抱えているんだから他の問題を受け入れる余裕なんかないんですよ」という態度をとることによって自分を防御している人は、自分を守ってくれる大きな問題を本気では解決したがらない）。
大きな問題をひとつ抱えているとき、他の人は手助けしにくい。 中くらいの問題（特に独立した問題）がたくさんあるとき、 「じゃあ、この問題は君におねがいしてもいいかなあ」 と他の人に割り振れる。 助ける人がたくさんいれば、それだけ仕事のスピードが上がる。 自分の仕事を、そういうスケーラビリティ(?)の高い状態に保っておくことは 難しいけれど大事なことかもしれない。
仕事をどうブレークダウンして、どの「かけら」を誰に任せるか。 それは「現場」から「管理する側」に移りかけている人が考えるべきポイントかもしれませんね。
「自分がやったらすぐ済む仕事だけれど、あえて彼／彼女にまかせてみよう」という態度。 それはとても大切な教育的態度。
The Hyuki Support Teamから、私あてにメールが来ました。 どうやら私のパスワードが更新されたらしいです（苦笑）。
From: XXXXXXXXXX To: XXXXXXXXXX Subject: Your password has been successfully updated Dear user hyuki, You have successfully updated the password of your Hyuki account. If you did not authorize this change or if you need assistance with your account, please contact Hyuki customer service at: XXXXXXXXXX Thank you for using Hyuki! The Hyuki Support Team +++ Attachment: No Virus (Clean) +++ Hyuki Antivirus - www.hyuki.com
もちろん、 これはワーム型ウイルスメール MYTOB.EHですね。
おれカネゴンさんからMusical Baton(ミュージカル・バトン)というものが渡ってきました。 さくさく答えてみましょう。
●Total volume of music files on my computer... (私のコンピュータに入っている音楽ファイルの容量は…)
コンピュータで音楽を聴く習慣がないので、 ほとんどありません。 自分のリコーダーの演奏くらいなので、5MB程度。
●The last CD I bought was... (私が最後に買ったCDは…)
Andrew Lloyd Webber の 『オペラ座の怪人』 (The Phantom of the Opera)です(サントラCDなのでちょっと冗長)。 クリスティーヌ役のエミー・ロッサムが歌う、"Think of Me"が、私のお気に入り。 何度聞いても飽きません。
●Song playing right now is.... (ちょうどいま聞いている曲は…)
特にはありませんが、 最近頭の中でよく鳴っているのはムソルグスキーの『展覧会の絵』（ラヴェル編曲）です。 特にプロムナード。 あの冒頭部分は11拍子なのですが、5+6なのかな、それとも2+3+3+3なのかな、 とよく考えます。
それから長男が弾くバッハの『インベンション』を聞くのがとても好きです。 長男がピアノを弾いているのを見ると、ものすごくうらやましいです。
●Five songs I listen to a lot or mean a lot to me are.... (私がよく聞く、または私にとって大切な5曲は…)
次の5曲です。
●Five people to whom I'll be passing the baton are... (私がバトンを渡す5人の人は…)
事前連絡なし、事前承諾なしで指名しています。 無視・拒否してくださっても、もちろんかまいません。
otsuneさんところと 我が逃走の日々を読む。下記、otsuneさんのまとめを引用。
・RSS1.0ならdescriptionに500byteで要約を。content:encodedに全文 ・RSS2.0ならdescriptionに全文いれても歴史の経緯で許されるがcontent:encodedを拡張して全文いれるほうが綺麗
ふむふむ、なるほど。
といいつつ、自分の日記のRSSはどうしてたっけ、と調べる。 ずいぶん前に書いたスクリプトなので、忘れている。 調べてみると、
となっていた。なるほど。「最初の段落」にしているのは、途中で切るのがきっと面倒だったんだな＞昔の自分。 最初の段落が500バイトより長いときにはちょっと行儀が悪いRSSをフィードしていることになりますね。
定番の神崎さんのところをリンクします。
以下は、上記神崎さんのところからの引用です。
RSS 1.0ではitem要素の数は1つ以上で上限はありませんが、RSS 0.9との互換性を考えるならば、15までにしておくことが推奨されています。文字数に関する推奨も、後方互換性のためです。
これらの制約は近い将来取り除かれる方向で検討されており、あまり気にする必要はありません。ただし、description要素に日記やblog記事の全文を記載すると、コンパクトなサマリーを期待する読者には歓迎されないかも知れないので、description要素は短くとどめ、全文は後述するContentモジュールのcontent:encoded要素に記述すると良いでしょう。
ぐちゃっとしていた「声のかけら。」のスクリプトを整理した。 これまでは、HTML::TemplateのテンプレートにContent-typeも含めていたけれど、 ファイル出力のことを考えると分けたほうが便利なので分けることにする。 あとは (1) ドキュメント追従 (2) clover.cgi追従 (3) news.cgi追従 を行えば公開できるはず。 時間ができたとき(逃避したくなったとき)にやることにしよう。
この機会に、clover.cgiのテーマも入れ替えようかな。 いやいや、作業は一度にひとつずつしなくちゃね。
CGIでRSSを直接フィードせず、ファイル経由でフィードする修正も整理した。 ロジックはこうした。
まあここまでは当然。
ここで、 外部にRSSフィードとして公開するURLを https://www.hyuki.com/kakera/?rss ではなく、 https://www.hyuki.com/kakera/rss.xml にしておく。すると、
というメリットがある。
とすると、上記(2)のインタフェースは不要じゃないか、と思う人もいるかもしれない（私ははじめそう思った）。 rss.xmlを直接読ませることにする(※A)なら、CGI経由でRSSを読ませる口なんかいらないのでは、ということだ。
でも、「『外部からURLとしてアクセスできる場所に、CGIがファイルを作れない』というサーバ(※B)もあるのではないだろうか」と私は思った。 その場合、(2)の口がないとRSSフィードができなくなってしまう。 そこで私はCGIのコンフィギュレーションとして、次の変数を用意することにした。
この二つを調整すれば、※Aの場合でも※Bの場合でも対応ができる。
たとえば※Aの場合(RSSファイルを直接外部に読ませる場合)、次のように書く。
RSS_FILE => "/somewhere/public_html/kakera/rss.xml", RSS_URL => "http://www.example.com/kakera/rss.xml",
※Bの場合(RSSはCGI経由で見せる場合)、次のように書く。
RSS_FILE => "/somewhere/private/kakera/rss.xml", RSS_URL => "http://www.example.com/kakera/?rss",
こうすれば、 コンフィギュレーション用の変数を不自然に増やすことなく、 対応できると考えた。
以上、自分の作業メモ。どこかに書いておかないと忘れてしまうので。
HTMLベースの移行と、 301 Moved Permanentlyの効果を調べるため、 アクセスログで(GET|HEAD)に対し200を返しているものを数えてみました。 左が2005-06-02(before)で、右が2005-06-14(after)です。
CGI 6415 /diary/rss | XML 5142 /d/rss.xml
CGI 5617 /tf/?rss | XML 4825 /yukiwiki/rss.xml
CSS 3815 /common/style2.css | XML 4509 /t/rss.xml
CSS 2512 /yukiwiki/wiki.css | CSS 3808 /common/style2.css
GIF 2459 /yukiwiki/icon40x40.gif | CSS 2599 /yukiwiki/wiki.css
CGI 1620 /diary/ | GIF 2560 /yukiwiki/icon40x40.gif
CGI 1406 /yukiwiki/wiki.cgi?RssPage | 1431 /favicon.ico
1317 /favicon.ico | HTML 1297 /d/
CGI 1141 / | HTML 1190 /t/?rss.xml
CGI 1024 /tf/200505 | HTML 993 /
一目瞭然。
beforeではトップ10のうち6個がCGIでした。afterではCGIは一個もありません。 /t/?rss.xmlのエントリは意味不明（どこかに間違ったURLを書いちゃったのかな）ですが、/t/以下にはCGIはないのでいずれにしてもCGIは動いていません。
もちろんアクセス回数がそのままサーバ負荷ではないのですが、 少なくとも自分の行った対策が動いていることは確認できました。 プロバイダさんにサーバ負荷が軽減されたかどうかを現在問い合わせ中。
じっくりとお仕事。
サーバの負荷軽減の対策の一環として、 hyuki.comで動作しているYukiWikiと 声のかけら。のRSSをファイル化した。 でもスクリプトがぐちゃっとしているので、まだ公開はせず。
C MAGAZINEの原稿書き書き。 いつも遅くなってごめんなさい…。
otsuneさんのところの文章を読んで、私も「RSSに記事全文が入っていないとサイトへのアクセスが減る」に強く同感。
RSSフィードでさくさく文章を読んでいると、 ときどき「タイトルしかないサイト」がある。 そういうサイトはだんだん読まなくなっていく傾向にある。 逆に、RSSフィードで読んでいて（つまりそのサイトのデザインとは無関係にコンテンツだけ読んでいて）「面白いなあ」と感じるサイトは、 よく記憶しているように思う。 というわけで、みなさんRSSフィードにたくさん文章を入れましょう。 たとえば、はてなダイアリーを使っている方は、 自分の日記が「RSSフィードに全文を掲載する」オプションになっているか再チェック！（はてなダイアリーは全文をRSSに入れるかどうかを選べる）
「Webの世界は、公開したもん勝ち」というのが基本ですね。
追記
上では「みなさんRSSフィードにたくさん文章を入れましょう」と書きましたけれど、 ちょっと私の言いたいこととニュアンスが違ったかもしれません。 私の言いたかったことは、 「自分の日記やblogを、自分のRSSリーダーで読んでみて、 自分が期待した効果を読者に与えているかどうかを考えてみましょう」 ということでした。
たださんのところで見えた虹は、結城のところでも見えた。 じっと見ているうちに、 「内側の虹の色の順」と「外側の虹の色の順」が逆になっていることに気づいた。 長男にそういうと「外側の虹は内側の虹が映っているんじゃない？」という。 ふうむ。どうだろうね。
追記
日記の読者さんから、 虹の不思議というページを紹介していただきました。 これによると「水滴の中を何回反射するか」によるようですね。
追記 (2005-06-16)
otsuneさんが調べた、 古いRSSへのアクセスに301を返しているのだけど、自動的に移転処理をしてくれないRSSリーダーが結構あるは面白い。いろんなRSSリーダーがあるなあ。
はてなも自動移転はしないみたいですね。 （ 追記:「なるはや」 naoyaさんが対応するらしいですね。 ）
あ、 KissReaderも移転しない…。
今日は、地味にお仕事をする。
「301 Moved Permanentlyを出すようにすれば、一部のRSSリーダでは自動的に購読を切り替えてくれる」という情報をいただきました。 なるほど！
ところで…(^_^; CGIで200ではなく301を出すようにするのって、どうするんでしたっけ。 ＞ どなたか。
単にLocation:ヘッダを出すだけではだめなんですよね？
追記
Parsed Header Outputというリンクを教えていただきました。 ありがとうございます。 また、たくさんの方から関連情報をいただきました。感謝。
いちおう以下のように仕込んでみました(古い日記のRSSにアクセスしたときに走るコード)。
print <<"EOD"; Status: 301 Moved Permanently Location: https://www.hyuki.com/d/rss.xml EOD
これで bloglinesは自動的に切り替わるのだろうか。わくわく。 r.hatenaとかも切り替わるのだろうか。
追記
otsuneさんの記事を見て、 CGIを使わなくとも、.htaccessでよいことに気づいた。
Redirect permanent /diary/?rss https://www.hyuki.com/d/rss.xml
日記とtextfile.orgをCGIベースからHTMLベースへ移行するときに、 自分がやった作業の手順は次の通り。
こういった作業をするときには「一度には一種類の修正しかしない」ということが大切だと感じた。 たとえば、 たくさんのファイルをコピーするときにはコピーするだけに専念する。 コピーしながら修正はしない。 また、build.plを修正しているときには、 必要なHTMLファイルが作られるかどうかだけにまず専念する。 そのHTMLファイルの中身が正しいかどうかの調整はその次のステップにまかせる。 このように「一度には一種類の修正しかしない」というのは、 リファクタリングの姿勢と同じだと思う。 自己の能力を過信すると、いっぺんにたくさんの変更を入れ込んでしまいがちだ。 「あ、ここは間違っているから、ついでに直しちゃえ」という態度は危険。 階段を一歩一歩のぼるように進むほうが安全だ。
また、各ステップではSubversionやCVSのような バージョン管理ツールをふんだんに使いながら進むことも大切だと思う。 「小さなファイルだから、特にバージョン管理なんかしなくてもよい」という態度ではなく、 「小さなファイルだから、バージョン管理ツールの練習も兼ねてきちんと管理してみよう」という態度のほうがよい。
「textfile.org」もHTMLベースに移行しました。 RSSも変更になりました。 アンテナやRSSリーダなどで巡回してくださっている方は、お手数ですが変更をお願いいたします。
旧URL: https://www.hyuki.com/tf/ 新URL: https://www.hyuki.com/t/ 旧RSS: https://www.hyuki.com/tf/rss (もしくは https://www.hyuki.com/tf?rss ) 新RSS: https://www.hyuki.com/t/rss.xml
「結城浩の日記」はHTMLベースに移行しました。 元のURLからは可能な限り適切なページへのリンクを張るようにしましたが、 もしかしたらあちこちでリンク切れが起きているかもしれません。ご了承ください。 もしも大量のリンク切れが見つかりましたら、ご連絡いただければ感謝です。 RSSも変更になりました。 アンテナやRSSリーダなどで巡回してくださっている方は、お手数ですが変更をお願いいたします。
旧URL: https://www.hyuki.com/diary/ 新URL: https://www.hyuki.com/d/ 旧RSS: https://www.hyuki.com/diary/rss 新RSS: https://www.hyuki.com/d/rss.xml
あ、それから、 RSSリーダでうまく読めないなどの不具合がありましたら、 ご連絡いただけると助かります。よろしくお願いします。
追記
さっそく、RSS内のリンクで .html が抜けているというご指摘をいただきました。感謝します！
2004年9月から、日記はYuki::DiaryというCGIで動的に作成していたが、 サーバの負荷軽減のために、再びHTMLベースに戻すことにした。 といっても、これまでCGIでサーバ上で作成していたものを、 ローカルなマシン上でHTMLに変換するようにしただけ。 Yuki::Diaryというモジュールはそのままにし、 index.cgiを元にしてbuild.plを書いた。 2時間ほどでHTMLを作るところは完成。 その後、1時間くらいでHTML::Template用のテンプレートファイルを修正。 この機会に、これまでCVSで管理していたファイル群をSubversionで管理するように修正した。 ちょっと気分がよい。
今日は、久しぶりに、削除も編集もしない自動書記的な日記を書いてみよう。 心に浮かぶ言葉をそのままエディタに載せてみよう。 私がWebサイトを持ってから今年で10年。 ネットで10年なんて無限に等しいような感じがするけれど、 もちろん無限ではない。 私が33歳のときから42歳のいままで、私はWebでさまざまな活動をしてきた。 Webページを作る。CGIを作る。 フリー・ソフトウェアを公開する。メーリングリストを作る。 メールマガジンを発行する。自著のサポートページを作る。 いま、結城の日記を読んでいるあなたは、そのうちいくつかをご存知のことと思う。 「そういえば、結城さんのサイトに来てから、○年ぐらい経っているなあ」 と感慨にふける方もいるかもしれない。あなたに感謝。 私は、プログラムを書き、文章を書くことをなりわいとしている。 日々たのしみつつ、くるしみつつ、プログラムを書き、文章を書いている。 それはまことに感謝なことだ。 主の恵みと哀れみにより、幸福に満ちた家庭を築くことができている。 家族に感謝。 30代のころ、自分は本当に「自由」だと感じた。 （主の赦しと許しの中にあって）私は何をしてもよいのだ、という充足感を得ていた。 自由というのは、自分の狭い考えに縛られず、また他者のあれやこれやに引きずられないということを意味していた。 私が畏れるべき方は神さまただ一人であり、その愛のうちにあって、 私に与えられた能力を、私に許された範囲で、自由に用いてもよいのだという自覚があった。 私の場合には、自分を過大評価するよりも、過小評価することが多かった（私などがそんなことをしてもよいのだろうかという思い）から、 神さまは私に「自由にやってみなさい」というご指示を与えてくださったものだと理解している。 神さまは、私たち一人一人を「特別な」「かけがえのない」存在として、 スペシャルなメッセージを与えてくださると信じている。 非常に優秀な編集者さんたちや、いっしょにお仕事をしてくださる方にも恵まれ、 私はとても感謝している。 私自身は、正直にいえば、あまり能力はないと思っている。 つまり、世界の最先端を切り開くような能力という意味では。 でも、これまた正直に言えば、何か難しいことを解釈し、噛み砕き、誰にでも理解できるような形に変換する能力には長けていると思っている。 私は仲介者であり、注解者であり、インタプリタである。 もちろんそれは、父を通し、母を通し、神さまから与えられた能力であるわけだが。 そのような与えられた能力 —— gift —— を十全に用いることは、私の責務であると思っている。 自分のタラントを地面に埋めないようにしなければならない。 …ということを書くと、何人かの方からは「結局、自慢しているだけじゃん」というフィードバックをいただくのであるが、 それはそれとして、私は今日書くべきことを書こうと思っている。 自分の能力や、自分に与えられたgiftを、過不足なく見極め、活用することは、重要な義務だと思っている。 誤解や幻想に基づく傲慢も問題だが、謙遜なふりをした自己卑下もそれに劣らず問題だと思っている。 自分の優れたところも、劣ったところもきちんと見極めて、 すべてをまるごと受け入れたい、と私は思っている （なぜって、私が生まれたのは偶然ではなく、神さまが意図を持って私を創られたからだ）。 ありがとうというときには微笑みたい。ごめんなさいというときには心からすまないと思いたい。 私は、とても贅沢者で、幸せになるなら「本当に」幸せになりたいと思っている。 本当の幸せ？ それは、たとえば、たった一人。さ、これから眠ろうかなとベッドに向かうときに我知らず、 くすくすと笑いがもれてしまうような、そんな生活のことだ。 私は、私の中に自分があるわけではない。 この世で生きている間、この肉体は神さまからお借りしているもんだと思っている。 神さまからお借りしている。しばしの間。 なかなか不器用な、ぱっとしないところも多いこの肉体だけれど、 神さまから数十年お預かりして、ここまで動かし続けることができた。 ときおり、自分勝手に動かそうとしてとんでもない事態になるけれど、 何とかここまでやってきた。神さまに感謝。 これからも、願わくは神さまの御心のままに動かしていただきたいと思っている。 この世での務めを終えた後には、イエスさまにパラダイスまで引き上げていただくことが心から楽しみです。 そのときまで、いくら長くともあと58年(100歳まで生きるとしてね)。 毎日を悔いのないように、丁寧に生きてゆきたいなあ。 イエスさま、お願いしますっ♪
RSSの負荷改善のために、 otsuneさんや kanさんから、 FeedBurnerを紹介してもらう。 なるほど。
USBメモリなどの大容量でリムーバブルなメディアは、 なくしたときのことを考えるとそのまま持ち歩くのは怖いですよね。 ファイルシステムレベルで暗号化したくなります。 オープンソースではTrueCryptというのが見つかりました。
みなさんはどんなのをお使いでしょうかね。
2003年に出版された『暗号技術入門 —— 秘密の国のアリス』は コンスタントに増刷して、気がつくと6刷を重ねようとしています。 応援してくださる読者のみなさんに感謝します。 また、プログラマ向けの雑誌などでも Schneierの『暗号技術大全』を読む前にどうぞ、 といったニュアンスでご紹介いただいているようです。 あらためて感謝します。
…という今日の日記を書きながら、執筆当時のファイルを整理していて、 先日の事故でお亡くなりになった石井勝さんからのメールが目に入りました。 石井さんには暗号本のレビューアもしていただいたのでした。 結城の文章に対するレビューの中に、パターンやオブジェクト指向、 それに物理学やピアノの話題などが優しい文章で展開されておりました。 惜しい方を亡くしたのだなあ…とほんとうに残念な気持ちになります。
プロバイダさんから 「hyuki.comのサーバ負荷が高くなっております」 という丁寧な連絡をいただいた。 調べてみると、/diary/, /tf/, /yukiwiki/のアクセス数が突出して高い。 下記はある1日の(GET|HEAD)ログの上位。
6526 /diary/rss
5675 /tf/?rss
5086 /common/style2.css
3183 /yukiwiki/wiki.css
3011 /yukiwiki/icon40x40.gif
1633 /diary/
1602 /tf?rss
1458 /favicon.ico
1406 /yukiwiki/wiki.cgi?RssPage
1160 /
1024 /tf/200505
1006 /dp/dp2.jpg
961 /math/math.jpg
940 /tf/
実際にアクセス数で多いのはRSSだから、 RSSだけを静的なファイルにしてもよいのだけれど。 日記とtextfile.orgはかなり「富豪的」なプログラムになっているから、 これを静的なHTMLに戻そうかな、と検討中。
アクセス数の多いCGIを探すため、 アクセスログに残っているpathのうち、?以降を無視して総計を取ると、 次のようになる。
10003 /yukiwiki/wiki.cgi
6931 /tf/
6526 /diary/rss
5086 /common/style2.css
3183 /yukiwiki/wiki.css
3011 /yukiwiki/icon40x40.gif
1711 /counter/gounter.cgi
1699 /diary/
1693 /tf
1458 /favicon.ico
1217 /kakera/
1164 /
wiki.cgiの中でアクセス数の多いページを調べてみると、次のようになる。
1406 RssPage
510 人狼BBS
350 ネクタイの締め方
202 RecentChanges
194 ２chのファッション辞典
175 デスマーチが起きる理由
151 MagpieRSS
137 JAVA基礎
116 圧力鍋
108 SonicStage
104 UNIXの環境変数メモ
ちなみに、アクセスログから統計を取るのに使ったPerlのスクリプトは以下。
use strict;
require 'jcode.pl';
my %count;
while (<>) {
# if (m((GET|HEAD) (.*?) HTTP)) {
# if (m((GET|HEAD) (.*?)[ \?])) {
if (m((GET|HEAD) /yukiwiki/wiki.cgi\?(.*?) HTTP)) {
my $path = $2;
$path =~ tr/+/ /;
$path =~ s/%([A-Fa-f0-9][A-Fa-f0-9])/pack("C", hex($1))/eg;
&jcode'convert(\$path, 'sjis');
$count{$path}++;
}
}
for (sort { $count{$b} <=> $count{$a} } keys %count) {
printf("%10d %s\n", $count{$_}, $_);
}
アクセス数がそのままサーバの負荷ではないのだけれど、 まずは、対策案メモ。
「ティナ」を公開します。 ぜひ、ご感想をお寄せください。
気がつくと、もう6月になっていました。 ばたばた…。
あなたのご意見・感想をお送りください。 あなたの一言が大きなはげみとなりますので、どんなことでもどうぞ。