とりあえず、『できたできた』と喜んでた Amazon S3 のアクセスログの件ですが、よくよく考えてみるとダメじゃん、ということに気付きました。というのも、dgsync.exe は、その名のとおり『同期を取る』ことが目的であって、更新されたかどうか、ってのを HEAD リクエストによって確認してるようです。
で、どうやら HEAD リクエストも課金の対象のようで。なので、ちょっと更新するたびに全 Web サイトの同期 & アクセスログのダウンロード、とかやってると、えらいことになりそうです。とはいっても、たかが知れてる金額ではありますが。
気になるのは気になるので、ちょっと方法を変えて、変更のあったファイルのみを s3.exe でアップロードし、アクセスログのダウンロードは週に一回タスクで実行するように。とりあえず、うまく動いているようなので、しばらく様子を見てみることにします。
Amazon S3 関連の移行が一段落しましたが、あとは、アクセスログが取れるようにする必要がある、ということで。すでに、ログ用のバケットにアクセスログが保存されるように、また、14 日後に削除されるようには設定してあります。
あとは、ログの解析、といったところ。とりあえず、AWStats あたりを使うことにします。ActivePerl をインストールして、AWStats のスクリプトを展開。コンフィグファイル ( awstas.model.conf ) をコピーして、↓のように修正しました。
Blog
Info
Tech
Mobile
Go to Top
LogFile="c:/awstats-7.3/tools/logresolvemerge.pl c:/awstats-7.3/logs/* |"
LogFormat="%other %virtualname %time1 %host %other %other \
%other %other %methodurl %code %other %bytesd \
%other %other %other %refererquot %uaquot %other"
SiteDomain="www.antoine.st"
DirData="c:/awstats-7.3/data"
DirIcons="icon"
LoadPlugin="timezone +9"
logs フォルダには、S3 からダウンロードした大量のログファイルが保存されてますが、このように設定しておけばマージと解析を一気にやってくれるのでいい感じ。あ。↑ で LogFormat は改行してますけど、実際は一行で指定してます。
で、あとは、以前作ったコンテンツアップロード & ログダウンロード用のバッチファイルのおしりに、↓のような内容を追加して終わり、と。
perl.exe c:\awstats-7.3\tools\awstats_buildstaticpages.pl \
-config=www.antoine.st -update \
-awstatsprog=c:\awstats-7.3\wwwroot\cgi-bin\awstats.pl \
-dir=c:\awstats-7.3\wwwroot
robocopy c:\awstats-7.3\logs\ c:\awstats-7.3\analyzed_logs\ /MOV /MINAGE:14
当初、解析の終わったログファイルを単に移動してたんですが、それをやると、毎回ダウンロードしてくることになっちゃってました。なので、robocopy コマンドを利用して、14 日より古いファイルのみを移動するようにしてます。想定どおりに動くか、ってのは、14 日後にわかることでしょう。
なにやらよくわからないタイトルではありますが、プログラムを書いてるときのこと。だいたい、規模的には数百行くらいのモジュールだと思ってください。詳細設計はプログラマが兼ねてる感じ。で、慣れてればささっとプログラムを書くことができますけど、チームのメンバー全員が同じスキルを持ってるわけもなく。
当然、コードレビューの時にボコボコにされるケースも出てくるわけです。『これは ( 詳細 ) 設計がダメダメな感じでしょ』とかってときにどうしましょう、というのが今回の主題です。もちろん、細かい指摘もそれなりにあるわけで、その辺を直すついでに ( 詳細設計が悪いとおぼしき部分も ) つじつまをあわせる感じの修正をする、って方法があります。
でも、それって、下手するといちからプログラムを作り直すより、手間がかかる難しいことだったりします。『修正』派の人が ( 詳細設計のまずさを吸収して ) いい感じに修正してくれればいいんですが、つじつまあわせを繰り返してそのうちスパゲッティが絡み合って、さらにわけがわからないことに...。なんてのもよくあるパターンです。
その辺の見極めは難しいところではありますけど、わたしはどちらかというと『作り直し』をする派です。( 皮肉でなく ) 楽しいプログラミングがまたできるわけですからね ( しかも、一度作ってるわけで、次回はさくさくプログラミングができるのは言うまでもありません )。
もうひとつが『コピペ』で、あまりにダメダメだったりすると、誰かが助け船を出す意味で『こんなサンプルあったよ』とか『時間かかりそうだから俺がちょっと書くよ ( それを参考にしてね )』なんてケースもあります。このときに、それをもらった側はどうするのがいいのか？
一番やっちゃいけないのが『コピペ』だと思うわけです。そりゃ、楽ちんですし、納期が迫ってるなら時間も惜しいです。でも、コピペしてちょっと直して、なんてことをやってたら、スキルは身につくわけがありません。ごく短期的に見ればいい ( しょうがない ) のかもしれませんが、いずれ独り立ちしていくプログラマなら、単なるコピペは止めといた方がいいと思います。
せめて『自分のプログラムと比較して』『なぜこういう書き方になるのか ( 書き方をするのか ) 考えて』『少しでもエッセンスをくみ取る』努力はした方がいいんじゃないでしょうか。さっきの『作り直し』の話もそうですが、今現在目の前にある仕事をしつつ、将来に役立つ ( と思える ) 方法を考えていく、って、とっても重要な気がします。
クライアント用のオペレーティングシステムで言えば、Windows Vista あたりから 64 ビット環境が広まった感じでしょうか。あれから 6 〜 7 年経って、とくに考えなければ 64 ビット環境が当たり前、といったところだと思います。
で、わたしもそんな感じで 64 ビット環境で生活してきたわけなんですが、諸般の事情により、最近、32 ビット環境も使っています。ところが、これが困ったことに非常にストレスフルです。CPU の世代としては結構新しいはずなのに、数世代前の 64 ビット環境よりも鈍重な感じで。Web ブラウザでぴょこぴょこタブを開いてると、いつの間にやら数ギガ消費していたりするのが大きいんでしょうか。
ちょっとプログラムを修正してビルド、とかってのにしばらく待たされたり。メモリをどかんを積める、ってのは、結構違うもんですね。64 ビットなんて、『1 プロセスで 4 ギガより多いメモリを使うことなんてそうそうない』とか思ってましたが、オペレーティングシステム全体で見ると結構影響が大きいんだなぁ、と感じる今日この頃です。
さらに、いまどき HDD なのが足を引っ張ってるような気もします。こればかりはどうしようもないんですが...。困った困った。
ある意味、技術的なネタではあるんですが、あんまり気にしないことにして、Amazon S3 移行関連のメモを書いときます。何かあったときに思い出せるように。
ドメインのレジストラ関連
Amazon route 53 関連
Amazon S3 関連
Outlook.com 関連
とりあえず、こんなところで。あと何かあったっけかな？ ま、思い出したらそのときに追加することにしておきましょう。アクセスログは、dgsync.exe を使ってダウンロードするようにしときました ( アップロードのバッチに組み込み )。
ということで、無事、Amazon S3 への移行も終わりましたが、そのときに使ったツールについて。コンテンツのアップロードには、『CloudBerry Explorer for Amazon S3』を使いました。一般的な FTP クライアントみたいな感じで、さくっと使えます。
日々のアップロードにはあまり使いやすそうな感じじゃないので、そっちは『DragonDisk』のコマンドライン版のツールを使おうかと。同期処理もできるし、低冗長化ストレージ ( RRS ) のオプションもあるしで、結構いい感じです。さっそく、Emacs から呼び出す用のバッチファイルを書きました。バッチファイルは、ヘルプを表示すると例が出てくるので、それが参考になります。
ところで、Amazon S3 はまだ無料利用枠が残ってるんですが、この ページによると、『5 GB の Amazon S3 標準ストレージ、20,000 Get リクエスト、および 2,000 Put リクエスト』が対象と言うことで、RRS は対象外のようですね。$ 0.01 ほど使用料金がかかってたので、標準ストレージに戻しました...。無料利用枠が終わってから、RRS に変更するか考えることにします。
これまで使っていた某ホスティング屋さんから、『別の会社に移管するから』という連絡がありまして。いろいろと不満 ( ドメインの更新が忘れられてたりとか、サポート対応がいまいちだったりとか ) があったこともあり、別のところに移行しようかと思ったわけです。
で、その対象として思い浮かんだのが Amazon S3 による静的ホスティングと。費用もそれほどかからない感じなので、とりあえず、ドメインを移管してもらってから試しながら移行していこうかと思っていました。
が、『移管の手続きができました』という連絡とともに、旧 Web サーバーにつながらなくなったのが今日の 19:00 頃 ( 実際はもう少し前だったのかも )。こりゃいかん、とばかりに、Amazon S3 への移行作業開始です。
とりあえず、
などなどの作業をやりまして、23:00 くらいにはひととおり移行完了、と。急に Web サーバーが止められると、ほんと困りますね。DNS の設定が反映されるのにちょっと時間がかかりましたが、こんなもので済む、ってのは便利だなぁ。
あとは、これまで FTP でやってたアップロードをどうするかってのと、アクセスログ解析をどうするか、ってあたりですが、その辺はおいおいと考えていこうと思います。
もう年明けしばらくたって仕事始め、といったところですが、明けましておめでとうございます。旧年中はお世話になりました。今年もよろしくお願いします。
さて、たいてい豊富やらなんやらを述べたりする場だったりするんでしょうけど、あんまりその辺は考えてません。『来た球を打つ』というか、『好きなコースに球が来るように工夫する』というか、そんな感じで行きたいところです。
とはいえ、何にも考えてないわけではなくて、いくつか考えてることもあるので、その辺を微妙に目標にしつつ、頑張っていこうと思います。とりあえずは、もう少し英語を頑張らないと。
Previous Page
Mail
RSS