そんなわけでこのサイトは自宅建て替えに伴い先月自宅サーバから某VPSサーバに移設。その際ようやくオリジナルのドメインを取得し新たな環境(まあ中身はしばらく変わらないですが)での運用を開始しました。
 それからしばらく、元サイトからのリダイレクトと通常検索結果の効果か順調にアクセス数が増加し「いやー、やっぱ細々と自宅サーバ運用してるよかよいわー」とか思ってたのもつかの間。ほぼ運用開始から1ヶ月経過した今月頭、アクセス数が激減し始めました。
 その前後チャイナ系やらコリア系やらの不正アクセスが増加してたのでIPエリア単位でブロックしてたのが影響したのかなぁとも思ったのですが、どうも調べてみるとそう言うことではないらしい。
 Googleは新規ドメイン(ホスト?)を確認すると一定期間そのサイトを比較的上位に表示させ、その間の利用状況の推移を計測。結果あまり有用なサイトじゃないと判断した場合1ヶ月程度でそのランクを激減させる、という事があるらしく、「Googleハネムーン」などという用語で呼ばれてるらしい。そっかー。

 お話によるとしばらくすると妥当な数値に落ち着くらしい。まあこっちも新Verサイトの準備なども進めてるし(※よーやくドメインを操作できるようになったのでヴァーチャルホストとかも視野に入れつつ) しばらくは様子見になるかと思います。

 ちなみにその結果今このサイトへのアクセスは相対的にYahoo検索からのものが比重を上げてるのですが、今Yahooって検索エンジンどうしてるんだっけ?

2013-06-17 [日記]

  ブログの画像リンクが絶対パスで旧サイトを見てたらしく旧サイトを停止させたら見えなくなってしまったー。
 明日から引っ越しだから直してる暇ないなあ。くそう。 

関連タグ:サイト運営話
2013-05-30 [日記]

 以前、表示上は特に問題ないのにGoogleのサイト解析でやけに404エラーが発生した場合の話を書きました。
 これはApacheでRewrite設定をしてる際に「/」(スラッシュ)をURLエンコードして出来る「%2F」がURLに混じってると404エラーになる、でもZendFrameworkだと表面上は問題なく表示されるので分かりづらい、という話でした。
 対策としてhttpd.confに「AllowEncodedSlashes On」を入れて終了。
 先日サイトを自宅サーバからVPSサーバに引っ越した際にも同設定を書き込んで(※引越し時に何の設定だか忘れてて軽く悩みましたが)終了…のハズでした。

 ところがサイト移転から数週間。Googleのサイト解析曰く「404エラーが増えてきたよ」。
 最初は移転以降のゴタゴタかなぁと思ってあまり真剣にとらえてなかったけど、状況は時系列と共に悪化。一定割合で増えている。というかsitemap.xmlに従うクロールの増加とともに増えている感じ。試しに自分でエラーの出てるURLにアクセスして(※閲覧は普通にできて)すぐログを確認すると確かに404エラーが発生している。ついでにログをgrepかけると結構な数の404エラーが発生している。このタイミングでようやく上記「AllowEncodedSlashes」の存在を思い出したが、やはり上述の通り既に設定は完了している。

 うーん、とりあえず「AllowEncodedSlashes」について本家Apacheサイトに調べにいったところ、

 
 コンテキスト:    サーバ設定ファイル, バーチャルホスト

 
 …なるほど。
 実はVPSサーバ導入と同時によーやくオリジナルなドメインを取得したのでDNSも自前で運用することに。その際ついで、というか後々の拡張性を考えて公開用ホストFQDNをネームベースのVirtualHostに変更したのでした。
 てなわけで該当する<VirtualHost>内にも「AllowEncodedSlashes On」を記述。Apache再起動。…無事404エラーが出なくなったのでした。

 まー当たり前と言えば当たり前な話だったのかもしれないですが、こーゆー設定は全設定で共有してくれても良いと思うんですけどねぇ。否定したい時だけOffと明示すれば良いだろうし。
2013-05-27 [日記]

 そんなわけでここ数年自宅サーバで運用していた本サイトを外部のVPSサーバを借りて移管いたしました。

 理由としては大したことはない…というかサイト運営とかサーバ運営とか全く関係なく、自宅を建て替える事になった→今の家を解体することになったため。しばらくは借家住まいなわけですが、そこで自宅サーバとして運営するのもどうだかなぁと思ったのです。
 まあ他にもそれっぽい理由としては、震災直後の回線断・停電によりしばらく運営できない状態が続いた事への対策。ディザスタリカバリ対策ですな。そこまでしてリカバリする事もあるかいとは思うがw
 
 まあともかく。
 これまでso-netの提供サービスを使ったなんちゃってオリジナルドメインで運営してたところを、今回完全にオリジナルなドメイン(やっすい.infoドメインですが)を取得。サーバ自体も某VPSサービスの一番安いヤツなんだけども、まあ回線・サーバスペックとも、Bフレッツ&古いノートPCを流用してた自宅サーバよりよっぽどよくなりましたね。アクセスが早くなった。管理人が言うんだから間違いないw
 自宅サーバは自宅サーバできっと用途はあるだろうから、家の建築が終わって戻ってきたら復活させるかもしれませんが、多分サイトの公開はこのままこちらで行うものと思います。せっかくドメインとって自分でサイト名好きに出来る状況になったし、それを利用した新たなサイト構成、Ver.6(最近だとMark.6といった方がよいかw)の構築も視野に入れたいとか思ってマス。
関連タグ:サイト運営話
2013-05-02 [日記]

 そんだけで何か特別な機能を追加したわけではないんですけどね(苦笑)。
 あ、でも微妙なレベルでjQueryとか使ってるかも。ホント微妙なレベルでw
関連タグ:サイト運営話
2012-10-18 [日記]

 ふとGoogle Analyticsで本サイトの状況を確認してみると、やけにページが見つからない場合の404エラーが多発していることに気づいた。
 が、しかしである。そもそもZend Frameworkを使用するためにRewrite設定でほとんどのリクエストをindex.phpにリダイレクトかけてるので404エラーの発生率はほとんどないハズ(無いわけではない)。
 と思ってアクセスできないページとやらにアクセスしてみると普通に表示される。なんだろう、一時的なものかなー、と思いGoogleのツールで再取得させてみると「取得できません」。あれー?
 次にブラウザのプラグインでHTTPヘッダをとれるヤツを起動、問題のページにアクセスしてみると、ページは表示されるのだがレスポンスは404エラーが出てRUUUUUUUUUUU!!

 なんだこら、404出てるのに表示されるってなどーゆー了見だ、ととりあえず問題のURLを漁ってみると、URL内で「/」をURLエンコードした「%2F」が入ってると404エラーが発生してることが判明。そこから更に調査して、Apacheの場合URLにこのエンコードしたスラッシュが入っているとデフォルトだと404エラーを返す事も判明。それを抑止するためにhttpd.conf等にて「AllowEncodedSlashes on」を設定すれば良いことも判明。設定→再起動→確認。無事404エラーの抑止に成功しましたとさ。

 解析ツールのログ、グラフを見てみると今年の1/20頃から急にエラー扱いのページが増えている。別にこの頃から「%2F」を使いだしたわけでもないし、Apacheの設定を変えたりしたわけでもない。ひょっとするとGoogleの解析方法が若干変わったということだろうか。色々あるもんですなぁ。ちゃんとチェックしておかないと。
2012-03-28 [技術]

 てなわけで夏に合わせてサイトカラーを涼し気な感じに変更してみました。ある意味節電対策ですな。まあもっとも白方向に変更したのでむしろディスプレイ的には消費電力増してるような気もしますがな!w

 ちなみにいつでも以前の黒モードにも戻せるんですが時間帯によって変更させるかとか変なコトも考え中。
関連タグ:サイト運営話HTML
2011-07-06 [日記]

 タイトル通り本サイトの構成を微調整しております。昨年11月のサーバ不具合→新システム再稼働後から今に到るまでの間、間に震災を挟んだこともあり搭載を予定しつつもしきれなかったもの、運用の中で追加を検討したものなどをじわじわとのっけております。全てじゃないですが。

 ワリと気分で載せたり載せなかったりを切り替えてるのでしばらくの間ちまちまと見た目が変わるかもしれませんが、まあ気にしないでください。
関連タグ:サイト運営話
2011-06-23 [日記]

 先日、本サイト稼働用の自宅サーバの「/home」領域としていたUSB外付けHDDが不調に、でも少し様子見する、とゆー話をしたがその後やっぱ不調が続いたのでなんとか入れ替えることに。

 前回は余り物の320GB2.5インチHDDをUSBHDDケースに入れてext3フォーマットしようとしたのだが、mkfsのところでよくわからないエラーになって完遂できず。
 試しにそのHDDをWin7につないでNTFSフォーマットしてみたところ問題なくできたので「CentOS5のファイルシステム系コマンドにはバグがある説」が濃厚かなぁと思いつつ、面倒だからNTFSフォーマットしたそのHDDをそのままマウントしちゃうことに。
 「mount -t ntfs…」しかし「Unknown」。あれー、man的にはできるみたいに書いてあるけどなー、と思い軽く調べたところ、CentOSはいくつかパッケージを追加しないとNTFSをマウントできないとの事。ここでそれらパッケージを入れてもよいのだが、次にOS毎再構築する必要が生じた際に、追加パッケージを導入しないとHDDをマウントできないとゆーのは互換性から考えるとあまりよろしくない気がしたので途中で却下。

 とりあえず違うHDDで試してみるか、とパーツ入れを漁ったら正体不明な1.5TBのHDDを発見(苦笑)。中を見ると32bitとおぼしきWindowsがインストされ、かつインスト直後で放置されてたよーなほぼまっさらの状態。いったい何のためにこんなん作ったんだっけ…と疑問に思いつつ、おそらくいらないモノだろーと判断。USBHDDケースに入れ替えてext3フォーマット。お、今度はフツーに完了。

 完了したところで適当にマウントさせ、元々のHDDのコピー作業に入る。さすがに何度かI/Oエラーでこけて完全にはバックアップできなかったものの重要なデータはほぼ無事で、復旧率は80%といったところ。

 さて次に新旧HDDのマウントポイントを入れ替え。/etc/fstabを書き換え…ようと思ったら最近は(※最近、とゆーにはだいぶ前からのようだが)デバイスを直接指定しないでデバイスに「LABEL」とゆーのを割り当てれば良いようになってるのね。なってるのね、と言いつつ普段デバイス名を認識して管理してる人にはかえって分かりづらくなってるのかもしれないが。
 ともかくコマンド「e2label」で旧HDDのラベルを別名に変更、新HDDのラベルを元々のラベルに振り替え。ちなみにちゃんと動作するかどうかは不明が別のデバイスに同じラベル名をつけることもとりあえずは可能だった。多分おかしくなるだろうからちゃんと別物に変更したが。

 ひと通り設定を終えたところで再起動。ちゃんと新しいHDDが「/home」として自動マウントされましたとさ。
2011-06-20 [日記]

1.
 本サイトはSSDに換装したCF-R3+USBの外付けHDDで構成された自宅サーバで稼動しているわけだが、今日の朝頃から外付けHDDにエラーが発生。/home領域にしか使っていないHDDであるためシステム本体には影響ないが、一部ログなどを書き出してるところでもあるのでシステムが多少不安定になった。しかもリモートで何度か再起動してたところ、何度目かでとうとう応答がなくなったため、本日昼頃~21:00頃まで本サイトを休止せざるを得なかった。
 帰宅して、とりあえずファイルチェックをかけるがそれだと特に問題が出ない。でもまあ24時間フル稼働させて既に数年、そろそろ危険域なよーには思うので一度別のHDDに待避させようと、先日導入したA50-WA531に元から入っていた(かつSSD換装のために使わなくなった)320GBHDDを別の外付けケースに格納。ext3でフォーマット・・・するところでコケた。エラーっぽい表記はあったので少し調べてみたが、HDDの故障だったりmkfs系コマンドのバージョンの問題が疑われたりと複数の情報が。だが面倒だったのでここまで。前述の通り一応元のHDDも動作はしてるのでしばらく様子見することにした。

2. 
 ちと古めのアニメのOPとかをつべで流し見してたところふと「かってに桃天使」の存在を思い出して検索。ヒット。改めてみると、特にⅡのOPがすげく出来が良い。あの短い時間にストーリー性とヒロインの孤独性が凝縮されてる感じだ。
 そして何度か見直してると、今度は「グレンラガン」を想起した。そいやアレはアレでコナミ関連ではあったような。実は根っこで繋がってたりするのだろか。
関連タグ:サイト運営話
2011-06-17 [日記]

 省電力ががおーんと叫ばれる昨今、普段使いのPCの消費電力を計測してみたところ、それなりに省電力になるように構築したマシンにも関わらずアイドル時で130Wほど消費していた。あるいは130Wで済んでいるというべきかもしれないが。
 一方、PCは自室にいる間はつけっぱなしにしていることが多い割に、ブラウジングにメール、ちょっとムービー、ゲーム程度と、さほどパワーを要しない内容が多い。であれば普段使い用と重作業用のPCを分離して省電力に努めるのもアリではないかとオモタ。

 で、オモタ結果、以下のE-350Fusionベアボーンを購入してみた。OS以外一通り揃ってる点、USB3.0を持つ点がポイント。
A50 AMD Fusion APU E-350 ホワイト ベアボーンキット A50-WA531W
 
 さてWin7を入れる前に、ここ最近省電力サーバとして若干の力不足を感じているCF-R3の代わりに「Linuxサーバとして稼働できるか」とゆー実験を行ってみることに。
 CF-R3は省電力サーバとして実はかなり優秀なものの、IDEがDMA33に固定されるとゆー問題を抱えていることもあり、スペック的にはそろそろ微妙になりつつある。ヘタすると10Wを切る低消費電力は惜しいが、そろそろ世代交代を検討した方が良いかなと思いつつ、じゃあまずはこのE-350機はどうよ、というわけである。
 入れるOSは毎度おなじみCentOS5.5。最初インストールメディアが見当たらず、先に見つかった5.2をインストールしようとしたのだが、こちらは相性の問題かメディアの問題かインストーラが途中でコケた。その後5.5のメディアを発掘し再度挑戦。今度は何のトラブルもなくインストール成功。全機能を確認したわけではないがNIC、サウンドを含めて一通り認識している様子。
 肝心の消費電力はアイドル状態で16W程度。なかなか低い。インストール直後だとcpuspeedが働いてクロックが800MHzに落ちてたんで停止させて1.6GHzにしてみたが消費電力は変わらず。電力は違うところで食ってるようだ。
 では次に、標準の320GBHDDをSSDに換装してみる。SSDは数年前にメインPCで使用していたCFDの80GBくらいのヤツ。当時はプチフリがあったので継続して使うかは微妙だがとりあえず消費電力のテストにはなるだろう。

 …と、ここでHDDの入れ替えが発生するワケだが、分解方法がわからずちょっと手間取った。まあ小型ベアボーンだから仕方ないが、よく考えると「ベアボーン」ってフツーはカスタマイズが基本だよなー。
 困ってる人もいるかもしれないので簡単に説明しとくと

  1.本体周辺バンパーぽいところのネジを3本外す。
    →うち2本はシールの裏に隠れてるのではがして開ける。
     なおこの時点で保障は受けられなくなると思われるので自己責任で。
  2.ネジ側に近いサイドパネルをマイナスドライバーなどでパキパキ剥がす。
    →この際WiFiアンテナ?を接続するケーブルを傷つけないよう力加減に注意。
  3.外周に沿って逆側パネルを押さえているネジ、マザーを押さえているネジを外す。
    →外すのは同じ種類のナベ小ネジ。
  4.逆サイドのパネルをパキパキ外す。
    →ファン部とヒートシンクの接続部が変にならないように注意しながら外す。
  5.マザーの裏側からHDDを押さえているネジ3本外して入れ替え。

 なおメモリ交換や無線LANカードを外す場合も同様の手順。そう頻繁にいじるところではないとは言えなかなかめどい。

 さてHDDとSSDを入れ替えてOSインスト。…しかしこの段階で既にちょっと消費電力が「高く」なってることに気づく。ディスク領域はどちらも全て初期化してるわけだが、そういった派手にディスクにアクセスする際の消費電力はどうもSSDの方が高い様子。一通りインストを終えてアイドル状態になっても消費電力は17W前後と若干高め。
 標準のHDDは5400回転の2.5インチSATA。確かにHDDとしては低消費電力の方ではあるがちょっと意外な結果に。

 と思って軽く調べたところ、SSDだからといって必ずしもHDDより消費電力が下がるとは限らず、特にモノによってはアイドル時の消費電力がむしろ高めのモノもあるらしい。今回低いHDD→高いSSDに入れ替えてテストしたのがこーゆー結果になったとゆー事だろか。
 SSDと言えばIntelの製品の評判がよく、メインPCのSSDもIntel製なワケだが、消費電力についても他製品とは一線を画した性能を持つらしい。余裕があったら入れ替えを検討しても良いだろうか。

 さて結果的に、省電力サーバとして稼働させる余地は十分あるように思う。まだインストール直後の標準状態なので、これで無線LAN、サウンドなどサーバに不要な部分を停止させるなどの小細工をすれば更に落とす事も可能だろう。まー金銭とのご相談にもなるのであくまで検討の価値ありとゆーレベルで。
2011-05-23 [日記]

 何故か昨日辺りからPhpMyAdminの脆弱性などを狙ったアクセスが増加してきた。具体的には

 /PHPMYADMIN/scripts/setup.php

 等の管理ページへのアクセスを狙ってくるもの。アクセス元は国外でバラバラ。まあアテにはならないが。
 本サイトはMySQLを使用してないので当然PhpMyAdminも存在しないのだが、ZendFrameworkのルーティング機能を用いているため、とりあえずどんなアクセスでも受け付けつつErrorControllerに流され、結果404エラーが返らないようになっている。何かしら応答がある!と思ったbotがチョーシに乗ってるのかもしれない。もっとも404を返したとしても試行されるのは変わらないだろうが。

 まあパターンは分かってるのでそのうちFBIにでもリダイレクトするように仕向ける予定。
2011-02-10 [セキュリティ]

 2011年初頭から1ヶ月経過して2月。本サイトver.5のβ版運用が始まってからはほぼ2ヶ月。その間ちまちまと完成に近づいてはいるが、逆に言えば未だ完成は見えず。そのココロはと問われると、ひとえにめどいからと答えよう(苦笑)。さすがに全コーディングをイチから見直すとなると大変でのぅ。今回コードの再利用率は10%未満だろーからなぁ。まあZendFrameworkのおかげで相当高速で書けてはいるし、主要な機能はできあがってるのでまあ良いのだが。

 そんな中、先日じみーに機能復活したのが「カウンタ機能」。最近はあんま流行らなくなった機能だけども、せっかく今までじみーにカウントしてたのがもったいない気もしたので。それに、どーせアクセス制御系の機能とアクセスログ系の機能は作らなきゃいけないから、それに組み込めばいい話だし。そんなわけで、復活したカウンタ機能の裏ではアクセス制御機能とアクセスログ機能が同時に復活したわけです。

 アクセス制御はその名のとーりアクセス可否を判断する機能。特定条件によるアクセスの拒否から、一定時間内過度アクセスの排除などを担うと共に、カウントアップ実行の判断などを行っております。カウントアップするかしないかはクローラ等除外の他、同一IP一定時間内カウントアップ禁止などを行ってます。以前はその判断のためにDBにアクセス時間を書き込んだ上で都度検証を行ってたワケですが、それは当然相応のトランザクションの発生を意味しており、それなりに速度低下を招いていただろなぁ、と。
 それに対し今回は、先日ちと話題に出したmemcached+Zend_Cacheを利用したメモリキャッシュ方式に変更。生存時間を設定できるキャッシュのおかげで大した苦労もなく判定できるようになった。アクセス制御等も同様。ちなみにカウンタ値も実は普段はメモリキャッシュに書き込みつつ、一定確率でDBにアップデートかけるGCもどき風味に。若干カウンタ値の欠損の可能性があるものの、これも負荷軽減にはけっこー効果があるんじゃないかと。

 アクセスログは…まあアクセスログ(苦笑)。別にApacheのログ+Webalizerでええやんとゆー話はあるものの、検索エンジンのキーワード解析とか、それらのデータマイニングを考えると、自前で取って且つDBに入ってた方が都合がよいので。
 こちらも以前は全てDB…PostgreSQLに都度書き込んでいたワケだが、やっぱそれはそれでトランザクションがアレ的な事になるだろう、と。前Verではログ書き込み部分をWebアプリ部から分離してシェル化し、表面的な体感速度の向上は図ってたので、更に今回はログの書き込み先をsqliteに変更してトランザクションそのものを分離。DBファイルは1日単位で作成する形式とし、1日単位でのデータ解析をやりやすいように。まあ逆にトータルでのデータ解析はやりづらくなってるかもしれないが(苦笑)、まあデータの統合はいつでもできるので。
 また、メインDBであるところのPostgreSQLは高速性を考慮して実体をSSDに置いてるが、ログDBはそんな必要もないので外付けのHDDへ書き込み。…これはむしろSSDの寿命を考慮しての事だったりする(苦笑)。

 …とまあこんなカンジで、表面上はほとんど現れない部分に結構苦労してたりします。めんどくさいのは分かってたのでイマイチ手を出す気になれなかった部分。でもまあ苦労の甲斐あって、以前と比べて色々高速化・最適化されたカンジがします。苦労したと言いつつ前verよりも環境整ってるんで比較で言えば楽だったんだけどね。
 あとメモリキャッシュ周りに手を出したついでに、頻繁にアクセスされるであろうトップページ(ルート)のデータ、及びRSSのデータをメモリキャッシュに置くことでの高速化も搭載してみた。ここんトコはアクセス解析と併用すれば更なる効率化が望める事だろう。

 つーことでちょびっと完成に近づいた。完成目標は今年度内!…ではあるものの飽きたらその限りにあらず(苦笑)。
2011-02-01 [日記]

 本日、本来このサイトの主な目的だった(ハズの)「ギャラリー」を復活させました。下部「ギャラリー」ボタンから移動して下さい。

 や、まあ、復活つーても画像データその他は全部残ってたんで復旧させるだけだったらすぐ終わったんですが、もののついでにこれまで単なるhtml管理だった(※Smartyのテンプレート化はされてたが)ギャラリーを、ブログと同様に専用のCMSを作ってその管理下に置こうと。で、登録システムやらなにやら作ってたら結構時間かかった、と。
 まあ実は登録システムとかまだいい加減なんだけど、ブログとかと比べるとここの更新頻度はとても低いもので(苦笑)。システムとしての完成度はそんなに高い必要がないとゆーのが実情。
 とは言え、今後ブログの画像も同様のシステムで管理するかなーとか思ってるんで後で余裕が出来たら調整する予定。

 あとそれとは別に、以前「駄文」というページ内にあった各種情報の一部をブログに統合しました。アレはアレでやってる事はブログと変わらないのに古いシステムからの名残でhtml管理してたものでね。今回やっとシステム配下に置く気になった。それに伴って「駄文」ページは廃止することにしました。また、一部情報が古くて意味を為さなそうなページをいくつか廃止することに。なお、旧URLからでも新URLにリダイレクトできるよーにはなってます。まあ検索エンジンから来る人とかじゃないと意味ないと思うけど。
 なおこの駄文→ブログ統合はまだ完了してません。まあフツーに量が多くて時間がかかる。尼糾弾ページとかは需要が多いんで優先して移植したけども(笑)。でもあのページも改めて見ると情報古いよなぁ。
関連タグ:サイト運営話
2010-12-13 [日記]

 つーわけでまだ再構築途中な本サイト。現在「ギャラリー」の復活…というか、以前は結局単なるhtmlの羅列だったギャラリーページをちょっとシステム化すべく対応中だが、例によってまた少しやる気がダレてきた辺り(苦笑)。

 それはそうと、とりあえず以前も入れてた「ブログスカウター」をあるタイミングで再導入しサイトのアクセス状況を見ていた。
 再導入直後は以前とさほど変わらない数字が出ており、ああ、半月以上休止してても検索エンジンとかの状況は変わらないもんだな、と思ったら、ここ数日それがまた急激に落ち込む事態に。
 うーん、若干のタイムラグはあったもののやっぱ休止の影響があったのかな、まあ一からやり直すつもりじゃないとダメかなー、等と思っていたのだが、どうも原因はそこではないらしく、やはり一から作り直したRSS表示機能に一部ミスがあって、タイトルやらテキストやらのURLエスケープを失念してた。そのため「&」とかの文字列が入りRSS、というかXMLとして不正な形状になってしまった挙げ句、WeblogPing等でサイトを探しにきたサーバやフィードにエラーを返してた模様。FireFoxのフィードだと途中まで表示されてエラーも出ないから気づかなかった。ふと思い立ってIEで見たらエラーで表示されないもんだから発覚。やっぱ再構築には色々忘れてた事が発生するなぁ。URLエスケープなんて何度も通った道のハズだけどなぁ(苦笑)。
関連タグ:サイト運営話
2010-12-10 [技術]