にっき

Diary 2010. 5

5月2日 (日) 天気も良いので

チャリンコに乗って道明寺まで長持山古墳から出土した阿蘇凝灰岩製の石棺の写真を撮りに行ってきた。ビルの谷間？のさらに屋根のある展示台の上に載っているので、どうしても光量が不足しがちである。

そこでフラッシュを焚いて撮ったのだが、どうも見たときの色と色合いが違う。フラッシュと焚かずに撮ったものを見ると、こっちは見た色、あくまで記憶であるが、に近い感じである。

カメラが悪いのか、腕が悪いのか、目が悪いのか・・・。

んで、そのついでに、以前、古市を訊ねたときに回り忘れた墓山古墳の周りを一回りしてきた。この墓山古墳、墳丘長が225mもあるのだが、誉田御廟山古墳の陪冢扱いになっている。確かに誉田御廟山に比べると規模は劣るが多量の鉄製武器や武具が出土したことで有名な野中古墳など複数の陪冢を従える巨大古墳である。とは言え、やはり現実は誉田御廟山の陪冢扱いなので後円部にそれを示す石碑が建っていた。

帰りに、別の陪冢にも寄ってみたら同じ様な石碑が建っていた。こっちも前方後円墳のよう（墳丘は二つあった）に思うが墳丘長は30mほどだろうか。こいつもk前方部北西角から直線距離で300mほど離れているので、本当に陪冢なのだろうか？まぁ規模が規模だけに一番近い大きな古墳といえば誉田御廟山になるので妥当ではあると思うが・・・。

そうそう、最後にgekoのバッテリの設定であるが、先日一日使ったまま、今日も3時間強使ったが、まだまだ余裕があるようだ。やはりバッテリーの設定で電力消費になんらかの違いがあるんでしょうねぇ。ただ、落ちだしたら早いと言う恐れもあるので予備の持参は必須でしょうね。

画像は左から、墓山古墳の石碑、ちょっと離れたところにある陪冢の石碑、gekoのバッテリー残量インジケータ。

5月5日 (水) 別荘生活

一昨日、一昨日と瀬戸内海の人口46人の島の別荘へ遊びに行ってきた。鉄格子の付いた別荘ではなく、れっきとした別荘である。魚は釣れまくり、みかん取り放題とオマケまで付いているとの事だった。別荘は知人の奥方様の勤務先のオーナーさんの持ち物で、頻繁に使わなくなったので従業員に開放しているとの事である。

残念ながら魚も釣れなかったし、みかんの木も見かけなかったが、天候にも恵まれ楽しいひと時を過ごすことが出来た。日頃からノンビリしてるのでウサなど溜まっていないと思っていたが、やっぱり海の近くでのんびりと釣り糸を垂れながらビールなど飲んでいると非常に快適と言うか、癒される感じがした。そんなのんびりした島であるが牛のように大きい鹿がいて作物や樹木を食い荒らすとの事。島内をブラブラ散歩しているとキバの生えた猪のようなブタのような体長2メートル近い生物を見かけた。立ち入り禁止と書かれたロープの向こうでこっちを見て鼻を鳴らしていたが、そうこうするうちにゴロリと横になってしまった。

ブタに牙はないし、猪にしては体毛が薄いし・・・。イノブタ？島の神？一体なんでしょうかねぇ。

そんなこんなで、二日間だけであったが、楽しい時間を過ごす事が出来ました。昨年までの黄金週間は篠山のキャンプ場でバンガローを借りることが多かったので、それと比べるとベッドもあるし、風呂もあるし、食器もあるし、ブランデーもあるし、言う事なしであった。その上、利用料が掛からないので激安である。ほんま、金持ち企業に勤めていると貧乏会社に勤めているのでは味わえない贅沢も味わえるのである。これでイイのだ。

写真は別荘の窓からみた風景、野獣の昼寝とキバ

5月6日 (木) ログ

ほぼ毎日、簡単にではあるがhttpdのアクセスログだけは確認している。最も殆どがgoogleクローラーのアクセスなのでそれほど確認に時間は掛からない。

そんな中、なんで？と思うような所からアクセスがあった。リファラーはgoogleのサーチエンジンかれであった。何か超マヌケな事でも書いてたのかなぁ・・・

5月9日 (日) chmの呪い

ふとしたことで今日は散々な一日になってしまった。もうその時何をしようとしたのかさえはっきり思い出せないがphpのヘルプ、当然文字化けの無いヤツ、を手に入れたいなぁと思ったのがきっかけである。
その上、googleさんで検索してトップに出てきたサイトに書かれていた通りにやってみたのだが、キーツールででデコンパイルすると現れたhtmlファイルは10000超。これの文字コードを変更して、メタタグのキャラクターセットの表示を書き換えて・・・こいつを行うのに途方も無い時間が掛かった。最初に利用した文字コード変換ツールがフォルダ指定できないので対象となるファイルをエクスプローラーから所定の場所にドロップするのだが、GUIで10000を越すファイルを選択するのには途方も無い時間が必要である。幸いなことに、メタタグを書き換えるソフトはフォルダ指定できたので事なきを得たが、これだけでウンザリであった。

で、ここまでの処理を終えたら、5分弱ほどで再コンパイルすれば出来上がり。やった！と思って開いてみると、文字化けは解消されているが、左側が表示されない。そう、わけのワカランセキュリティー設定の所為である。で、早速プロパティーを開いてブロックを解除しようと思ったが、そんな項目は見あたらない。考えたら、インターネットから落としたものでは無いので当然である。

これは、デコンパイルする前のファイルの時点で先にブロックを解除したからに違い無いと思い、再度ダウンロードし直し、ブロック解除せずにデコンパイルし同じ作業を行ったが、結果は同じ・・・ならば、ネットから落とした状態にすればと思い、オノレのサイトにアップしてからプロキシ経由でダウンロードしたところ、ブロック解除の項目が見事が現れ、解除してみたが結果はやはり同じ。

で、最後はなんとか・・・と思いイロイロ調べると、cvsを使ってソースからコンパイルするなどと言う情報も見かけたのでCVSをインストールしてみたが、何が何やら使い方がサッパリ解らず断念。結局8時間ほどかけてパソコン内にゴミを収集しただけに終わった。

途中でウィルススキャンが始まったり、リライトエンジンに邪魔されたり、テレビを見たり、飯を食ったりしたので、それほど集中して作業できた訳では無いが、アレコレと4回ほど同じ作業を行ったので疲れ果てた。それとGUIで多くのファイルを扱うときの不利さと言うのも痛感した。コピーするにしろ、移動するにしろDOS窓から操作すれば数秒の事をマウスグリグリでやろうとすれば数分以上も掛かってしまう。

あーあ、ムカツく一日でした。全く休んだ気がしません。救いは阪神の勝利かな。笑=====>えません。

5月12日 (水) 寒いなぁ

どないなっとるねん。今日の日中の最高気温が17度。先週は27度もあったのにである。その上、明日は霜の恐れもあると言う事。

お陰で数日前からこっちは体調を崩して喉の調子が悪い。咳が出るほどでも無かったが、なんかいがらっぽくで、久々にうがい薬でうがいを行った。

週末はまた天気が悪そうやし、来週も気温はましになるが天候は悪そうやし、ほんまに今年は一週間ごとに平年の気温から高くなったり低くなったりと乱高下を繰り返している。

この先ずーつと続くのかなぁ？それならそれでもエエけどね。

5月15日 (土) 9日の日記に

phpのヘルプのことを書いたが、その問題が解決した。といっても自力解決した訳ではなく、グーグル先生に尋ねて、どこかの親切なサイトに教えられただけなのであるが・・・
ともかく、文字化けもしてないし、右側のウインドウもちゃんと表示されるし、使用に耐えうるものが出来たのでは無いかと思う。

で、何がイケなかったのかと言うと、右側のウィンドウが表示されないのはデコンパイルしたときにディレクトリ構造までデコンパイルされなかった？ため、右側のウィンドウが指すリンク先が存在しなかったからである。（これは、ひょっとしたらkeytoolの使用上のミスかも知れない）
文字化けに関しては、文字コードを変更したり、メタタグを書き換えたりせずにコンパイルして問題なかったので、オリジナルをコンパイルされた方の環境が日本語にマッチしていなかった事によるのかも知れない。

ともかく、デコンパイルした後、hhcファイルをエディタで開いてそこに書かれたリンク先となるようにresディレクトリを作成し、ファイル配置を変更したら上手く行った。もちろん、hhcファイルの方を変更しても上手く行くと思う。むしろこっちの方が正解なのかも知れない。 ( 参考にしたサイトはこちらの手法を採っていた )

と言う事で、オノレでリコンパイルしたchmファイルを開いたときに『このプログラムではこの Web ページを表示できません』などと表示された時はhhcファイルやhhkファイルに記されたhtmlファイルへのリンク先とディレクトリ構造が一致しているか確かめるべしと言う事ですな。

5月17日 (月) アップデート

久しぶりにfreshclam.logを見たら

WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.95.2 Recommended version: 0.96

などと出ていたのでyum　--enablerepo=rpmforge clamadで更新しておいた。なぜかclamav-dbが更新されなかったので、単独で更新する必要があった。インストールしたときはclamdを入れたら全部入ったような記憶があるのだが・・・

ついでにclamsmtpの最新版もチェックしてみたが、こちらは更新されていない様子だった。

最後に普通にyum check-updateしたら170近いアプリが更新対象になっていた。黄金週間前後にチェックしたときは一件も無かったのに・・・。

メンテナーの方々がせっせと連休の間に更新作業をされていたのだろうか？誠に以って有難い話である。

5月20日 (木) memory_limit

画像投稿掲示板を設置した。ちょっと理由？があって投稿可能サイズを10MBに設定した。当然、表示速度はかなり遅くなる事が予想されたので、試しに職場からアクセスすると、予想通り無茶苦茶遅かった。使用しているLANカードがショボく社内のファイルサーバにすら上手く繋がらない事があるので、当然と言えば当然なのだが、反対にここでストレスをそれほど感じずに表示できたらどこからアクセスしてもほぼ問題ないハズである。

ちゅうことで、その目的を達するために表示用にサムネイルを作成することにした。と言っても、一から自分で作るのも大層なので、web上で見かけたスクリプトを拝借することにし、BBSのソースに適当に埋め込んでみたが、元ファイルのサイズが6.5MB程になるとサムネイルが作成されない。

原因は何かとイロイロやってみたら、memory_limitの設定にあることが解ったので、.htaccessを使ってオーバーライドすることにし、設定値を変更しながら試したところ、6.5MBのファイルからサムネイルを作成するのに48MB近くのメモリが必要になるようであった。あまり細かく必要量を探った訳では無いが、32MBでは作成されなかったです。

あとは職場からどの程度で表示されるか・・・
う～ん、明日、出勤するのが楽しみなんて！未だかって有った事が無い！

ちなみに作成されたサムネイルのサイズは幅を200ドットに変更したもので16KB程でした。なんか劇的すぎるわ。

5月21日 (金) APC

まず、昨日のサムネイル作成の確認結果であるが、誠にもって素晴らしい結果となった。なんのストレスも無く職場の劣悪ネットワーク環境で表示された。そら6MB強のファイルが13KBほどになってる訳やから当然と言えば当然である。

で、今日のネタは先月、某DDNSサービスの勉強会に参加した時に聞いたphpのアクセラレータAPCを導入してみることにした。ひょっとしたらサムネイル作成処理の助けになるかなぁ？との単純なドシロウトの発想からである。

で、イロイロ調べると、導入にはpeclと言うpearのコマンド？を使う必要があるとの事だったので、php-pearとhttpd-develを導入してからpecl install APCでインストールを行った。ただ、ここで訳のワカラン問題に遭遇した。インストール途中で

Use apxs to set compile flags (if using APC with Apache)? [yes] :

と訊ねられるので「y」と入力したらコンパイルが始まるのだが

Sorry, I was not able to successfully run APXS. Possible reasons:

1. Perl is not installed;
2. Apache was not compiled with DSO support (--enable-module=so);
3. 'apxs' is not in your path. Try to use --with-apxs=/path/to/apxs

と怒られてインストールが完了しない。perlが入ってない訳ないし、ApacheがDSOサポートしてない訳もないし、phpinfo()にもapacheのパスが表示されているので、1～3のどれも当てはまらない。ひょっとしたらPerlなどと言うアプリでもあるのかとyum searchしてみたが当然そんなもんは無い。

途方に暮れて、「Sorry, I was not able to successfully run APXS」でググルと答えがありました。

Use apxs to set compile flags (if using APC with Apache)? [yes] : を良く見ると[yes]とあります。決して「y」では有りません。もしくはそのままEnterを押下すれば良いとの事。
で、そのようにしてみたら、順調にコンフィギャ、メイクが終了し、無事インストールされました。
最後に「You should add "extension=apc.so" to php.ini」と出てたので、その様にしてからapacheをリロードしてphpinfo()すると、APCが有効になっておりました。

まぁ使うための勉強はこれからですが、とりあえず、/usr/shar/pear/apc.phpをapacheの読めるところへコピーし、パスワードを設定してからアクセスすると、イロイロ情報が出てきました。

はてさて使いこなせるのか？

5月23日 (日) APC

これって別に「使いこなす」ようなモノでは無いらしい。phpで書かれたファイルと言うか、書かれた部分全てを対象にキャッシュしてくれるようである。なので、設定？はデフォルトの動作状況をapc.phpで確認してから行うと言う事のようだ。
で、その確認すべき項目と言うのはphpのマニュアルを見る限り、Cache full count と言う項目で、この値が出来るだけ小さくなるように、メモリの割当量を指定するapc.shm_sizeやメモリが全て使われたときに新たなエントリが発生した際にどう振る舞うかを指定するapc.ttl、( メモリの使用量に関連して ) キャッシュ対象のファイルを絞り込むためのapc.filterなどのディレクティブを適宜設定すれば良いようである。他にも、apc.statと言う、キャッシュされたファイルにアクセスが発生した時に、元ファイルが更新されているかどうかを確認するかしないかを設定するディレクティブもあるようだ。

ま、とりあえずと言う事で一晩利用した状態でapc.phpを見てみると、なんとCache full countの値は「0」である。ちゅうことはすでに「出来るだけ小さな値」になっているようなので、特に設定を見直す必要は無いと言う事であろう。強いて言えば現在35MBになっているapc.shm_sizeをもう少し小さな値にしても良いのかも知れない。

近いうちにwikiにまとめておこう！

| 1 | 2 |