実はこのページを編集・更新している Perlプログラムが一昨日辺りから動作しなかった。記事を書いて更新しようとしたら、添付した写真ファイルのサイズがリミットをちょっとだけ超えたので拒否されてしまった。今までも超えたことはあったが その度に画像アプリで強く再圧縮してサイズを減らしてアップし直していたが、ここのところほぼ毎回になり面倒なので、それならリミットを書き換えようとプログラムのファイルの該当部分だけ書き換えてアップした。その途端、CGIの 500エラーが発生。書き換えたのは数値だけなので？？？状態。
その時は夜中だったし、今日になって落ち着いて調べたら、修正した元のファイルはPCに保存してあったファイルなのでローカルサーバーでの動作チェック用に PerlPathを書き換えてあった。瞬間納得。頭の１行を修正して何とか回復した。

---

以前にもアップしたが、サンシュユの実。以前はまだ葉っぱが残っていたので、２つ３つしか実がなさそうだったが、葉っぱが落ちたら随分とたくさん実があるのが分かった。

今まで、自分の Local PC上で Webサーバーと同じような httpプロトコルの表示が出来るように httpdというアプリや、その上で Perlというサーバープログラムを実行するアプリを使ってきた。今回少し時間が出来たので、またぞろ このHPの表示をいじっている。その中で、自分のPC上で Perlと同じようなサーバー上のプログラム言語の PHPを実行したいと思ってローカルな http上で PHPを実行できる(その他に PerlやデータベースのMySQLも実行可能)と言う XAMPPというアプリをインストールした。インストールの仕方はあちこちにあるので、それらを参考にしつつ。
しかし、XAMPPを実行しても 一向にページが表示できない。原因は下記の通りだった。
１．デフォルトでLocalhostのポートが 80になっているが、これがシステムと競合するらしい。(その後、上記リンクの中の情報で install\portcheck.bat を実行すると使用済みポート番号をチェックできると言うことが分かり、実行してみたら 80番ポートは空いていたが)
　　あちこち検索すると、元の80番ポートを使っているサービスを探して停止して・・とか書いてあるが、たまにしかこんなツールは使わない物の、使う時にいちいち停止するのは面倒くさい。別のページでは 81番ポートを使う方法が書かれているが、私のインストールしたバージョンでは 設定ファイル名がその情報とは違っていた。Grepでフォルダ内を検索して httpd.confという設定ファイルを見つけ、そのファイル内の 58行あたりの "Listen 80" を "Listen 81" に変更した。
実はそうしておいて、XAMPPをタスクバーから停止して再起動しても ポートの表示は変わらなかった。ポートを切り替えるには XAMPPのコントロールパネルから Apacheの Actionsの Stopボタンを押して、同じボタン(表示は Start)をもう一度押したらポートが 81に変わって、http://localhost:81/ で接続できるようになった。
２．やっと XAMPPが起動出来たので、ブラウザから テスト用 PHPをロードしたが "Object not found!"となってしまう。こちらは　よくよく確認すると ドキュメントルートが解説ページの誤植で、正しくは "C:/xampp/htdocs" だと言うことが分かった。

---

今日の写真はツワブキ。花の少なくなった街で濃い黄色が目立つ花。

続けてExcelマクロの話。
こちらはまだテストしていないが、デバック用に　処理命令を挟むアイデア。 VBAのデバック環境では エラーがトラップされていなければエラーが発生するとそこで処理が中止されてそこまでの変数内容などがチェックできるが、実際の実行時はエラーが発生したら継続は不可能。
簡単なエラーコードとそこまでのメッセージ表示などを頼りに考えられる部分を推測してカットアンドトライで超非効率なデバックをするしかない。
これを改善する目下のアイデアとしては、Perlでもやっていたことだが、処理のポイント　ポイントで変数にそのポイントの番号を代入していき、エラートラップの処理中でこの番号と、重要な変数をエラー記録ファイルに書き出していく。もしユーザーサイドでエラーが発生したらこのファイルを送ってもらえば、どんなルーチンをたどってどこまで処理が進んでエラーが起きたのか、その時の主な変数の内容などが分かるのでなぜエラーが起きたのかなどかなりデバックに役立つはず。早速サンプルでテストしてみよう。

---

毎年、今の時期になって咲いているのを見るとると田舎の風景を思い出して懐かしくなる花。ホタルブクロ。

シツコイけれど昨日の続きで。
記事の中に <img src=""・・・>　などと表示したい場合に特殊文字を考慮して、&lt; や &gt; というコードを使って書いたのに、編集画面で せっかくの &lt; や &gt; が < や > に変換されてしまうので場当たり的対処法として << のようなローカルな書き方をする改造をしたという事を書いた。
しかし、色々考えて試行錯誤しているうちに、上記の特殊コードの頭にある & に着目して、この & もCGIでは特殊コード &amp; と置き換えて表すので、編集画面に出力するときにだけ 単に & を &amp;としてやれば良い事に気付いた。
つまり、CGIプログラムで &lt; は &amp;lt; に、&gt; は &amp;gt; にしてブラウザに送れば、編集画面では&amp;の部分だけが変換されるので &lt; や &gt; と表示され < や > に変換されてしまうことはないのではと。これだと Perlでは
$str=~ s/&/&amp;/g;
という一行を、しかも編集画面出力の処理部分にだけ追加すれば済む。感激するくらい？簡単な対策だ。
どうやら上手くいっているようだ。・・・・とこんな事を書いても、読んでくれている人は元々の処理を知らないので誰も理解できないだろうし自分だって、メモのつもりが半年後には理解できなくなっているだろう。忘れないうちに別ページを立てて整理しておかないと。

---

今日の写真は この間のナツズイセンの仲間。ヒガンバナ(マンジュシャゲ)の白・・・と言うよりは黄色に近い。ナツズイセンの隣に咲いたんだが、今朝見たら早速花盗人がナツズイセン共々抜いていってしまったようで、この写真は昨日撮影したもの。

このところ ３日間ほど、凌ぎやすい気温の日が続いている。今朝も夜明けころに小雨が降ったようで、朝は高原を思わせるような風を感じた。目の前の中学校の校庭は、先週土曜日のクラブ活動ではスプリンクラーで一生懸命水撒きしても、すぐに乾いて「焼け石に水」状態だったのに、わずかの雨で今朝は砂埃もたたない。今更ながら自然に対して人間の無力さを感じさせてくれる。
こんな時に出かける用事ができてくれればいいのに、と思うが現実は雨予想の今夜が飲み会、暑さが戻る明日明後日と出かけなくては。本当に世の中は自分の都合の良い具合にはいかないもんだ。
話は変わるが、#904で書いた この e日記の Perlスクリプトのバグが分かった。オリジナルのスクリプトでは、記事を削除するとその記事Noは欠番になる仕様だったが、私が余計なお節介で番号を詰めるように改造した。その時、オリジナルのスクリプトの処理をよく理解しないまま「付け足し」で削除記事以降の番号を変更し、同時に画像ファイル名も対応が取れるようにリネーム処理をしていたが、動作をよく確認しないまま使ってしまっていたようだ。他人の作ったスクリプトを理解するのは厄介なので、思い切ってそのサブルーチンだけ最初から作りなおしてみた。ローカルホストでのテストでは問題がとれたようだ。
今日の写真は、オトギリソウだろうか？　雑草に隠れて、何となく歩いていると見落としてしまうくらいの小さな黄色い花。

別に InternetExplorerだけの問題では無さそうなんだが・・・・
キャッシュが更新されないという問題。
#904で書いたように、この e日記の Perlスクリプトに若干のバグが有り、それを追いかけていた。大体バグはとれたかな？ と思ったが、画像表示がおかしくなることがある。
動作としては、CGIの上である番号の記事を削除すると、その記事と対応した画像ファイルが削除され、その上の記事が順に埋められて画像ファイルの名前(固定文字列＋番号)もリネームするという処理なんだが、Localhost上で走らせてテストすると、画像の表示がおかしくなる。Explorer上で画像ファイルを見ると、きちんと名前はリネームされているのに、IE上では ファイル名に対する画像が古いまま。通常のリロードボタンでリロードしても表示は変わらない。「オヤッ」と思って、Google Chromeなど別のブラウザで同じページをみてみると正常にリネームされた画像が表示される。しかし、GC上で同じように編集操作すると、同じような現象になる。
どうやら一旦キャッシュされた画像ファイルはチットヤソットでは書き換わってくれないみたいだ。最終的には「Ctrl＋F5」のスーパーリロード？機能で表示が更新されることは分かったので大きな問題ではなくなったが、途中気づかずに スクリプトを一生懸命見なおしては火のないところを目皿で追いかけてしまった。
今日の写真は、名前が「シモバシラ」というらしい。シソ科の植物。どう考えたってこの季節に咲くのに「シモバシラ」は無いだろう。

ほとんど自分のメモ
この　「e日記」の画像ファイルのリンクが時々おかしくなる。リンク切れで気づくが、リンクが生きていても、表示される写真が1〜2枚ずれてしまう。アップした記事を削除操作した場合に、そこを欠番にしないで埋めるような操作をしているので、写真と記事の番号が一致しなくなると思われる。但し、どうにも分からないのは、現在合計 34ページあるのが何ページにも遡っておかしくなるが、頭のほう20数ページは正しいまま。しかも日常のHTML出力操作では狂わないが、ある程度記事がまとまった場合に新設ページとして出力した時だけこの現象が起きる。しかも・しかもFFFTPでファイル作成日付を表示させると別に作成日付は変わっていないのにリンク番号だけが書き換わってる？？？ Perlのどこの処理がおかしいのか？なぜ出力しようとしないページの画像のリンク情報や画像ファイル名まで変わってしまうのか？　謎は深いが、かなり行数の多いプログラムになってしまったので追いかけるのは大変で 暫くは見て見ぬふりを決めた。(と言いつつ気になると放っておけない性質なんだが)
今日の写真は、とある民家の塀の上に置かれた鉢に咲いていたキキョウの花。梅雨の真っ盛りから咲いていたが、どうも季節感覚が分からなくなった。

Web上にアンケートページを作りたくなった。 Web上で質問に答えを記入するとその答えがログデータとして蓄積され、それを管理者が閲覧できるというものだが、一般的には質問を記入する HTMLページとそのデータを受信して処理する CGIプログラムを作らないとならないんだが、これもPerlやPHP言語のサーバープログラムのフリーウェアがあって プログラム上で 質問ページを生成できるようになっている。
そんなフリーウェアの1つをダウンロードして設置してみたが、よく出来ていて簡単にアンケートが作れるのはいいが　やはりちょっとだけ希望にはそぐわない。
アンケート内容により、質問をグループ化して視覚的に分かりやすくしたいと思ったんだが、そこまでは出来ない。例えばアンケートに答えてくれる人の属性と、アンケート項目そのものを線で区切ったり説明を付加するなどの表示上の問題だが。
Perlのプログラムを修正しようかと思ったが、同等の技量のプログラマが書いたプログラムは他人が読んでもある程度理解できるが、技量が数段高いプログラマが書いたものは素人に近い私ではどこでどんな処理をして結果が出てくるのか追いかけるのが大変。
単にアンケート項目の堺に線を入れたり説明文を追加するというような簡単な変更もおいそれとは出来ない。
そこで一計。設置したフリーウェア上で一通り出来上がって表示されたアンケート画面のソースをそのままコピペして htmlページを作り、その上で表示を追加するようにしてみた。これだとHTMLページ上の質問項目とCGIプログラムが受け取る質問項目の対比が変わらないので工数がかなり削減できる。アンケートの記入は 閲覧者のローカルなパソコンのブラウザ上で行われるので コピペしたHTMLでも問題なく働くはず。「送信ボタン」が押された場合に起動する CGIプログラムのURLだけを該当のフリーウェアのパスに変えることで、本来のアンケートプログラムは自身が表示したページから起動されたのかコピペしたような別ページから起動されたのか関係なく起動してログを保存してくれるはず。これだと、アンケートページをゼロから作るのよりは随分簡単になる。
実際に作ったのはこのページ。試してみたが問題なく処理できた。
今日の写真は、クチナシの花。「くちなしの花の　花のかおりが　旅路のはてまで　ついてくる」という渡哲也の歌の歌詞にあるような強い香りがするのかと思ったけれど、これだけ咲いていてもかなり近づかないと香りは感じなかった。私の鼻もスギ花粉症で自衛的に感覚を鈍くしているんだろうか？

丁度一月前に Perlで Webのサイトマップを自動で出力する機能を付加した話を書いた。
その時から気づいてはいたが、出力される XMLファイルはファイル検索された順に書きだされて並んでいる。Googleロボットなどが出力されたサイトマップを読み込む場合はそのままでいいが、人間がチェックしようとすると更新日付の新しいファイルから順に並んでいてくれると、チェックがやり易い。サイトマップは別に人間が読むものではないから、余分なお節介とは思うが、プログラムだからソートするのは朝飯前のはず。
・・・・と思って、ちょこっとのつもりでつつき始めた。いつものことだが。
まぁ、一ヶ月前のようなことはなかったが、それでも 20行ほどの追加になってしまい、都合 2日かかった。2次元配列を SORT関数で降順並べ替えするなど、いままで全く使ったことのない処理には、それなりにステップごとの確認が必要で時間がかかる。
それでもその間、今後のことを考えて メインの Win7機に an httpd という Windows O/S上のサーバーと、そこで働く Perlエンジンをインストールして、完全ローカルな CGIのデバック環境を構築できたから、今後は少し効率的なデバックが可能になるはず。
今日の写真は、サツキの茂みの蔭で咲いていた小さな花。こんな蔭で咲いていると私のように背が高いと腰をかがめるか遠くからでないと目につかないような花だが、近づいてよく見ると綺麗な正三角形をした花で興味をそそられた。名前を調べたら 「ミドリハカタカラクサ(緑博多唐草)」とか「ノハカタカラクサ(野博多唐草)」もしかしたら「トキワツユクサ(常盤露草)」とか言う花らしい。花は 5mmくらいとかなり小さかったので後者だろうか？ 姿形に似ず、要注意外来種らしい。

Perlの話題を １０日ほど前に続けたが、再び。
ほとんど正規の書き込みのない私の掲示板だが、その割に毎日 数十回のスパム書き込みがある。ほとんどすべてが海外からの書き込みなので以下の対応策を順次入れてきた。
１．タイトルに平仮名などがない。
２．本文にURLリンクが ２つ以上ある。
３．一回スパムが書き込まれたURLや、ロシア語圏のIPからは受け付けない。
などの対策を盛り込んで、ほとんどは自動で撃退できているんだが、中にすり抜けるスパムもあって、それらは文字コードが異なるロシア語圏からのものと思われるが、IPは .com など USなどのサーバー経由からのもので、上記対応策では書き込みがリジェクトできないで残っていた。まぁ １周間に １回かそこいらなので、気づく度に手動で削除してきた。しかし、Perlの記憶を呼び覚ましたついでなので対策してみようと考えてみた。
どうやら そうした書き込みは 日本語文字コードに変換されると「ミエミセム・コミー ミセミアム貫紹ひ ミウミセ・・・・」のような片仮名が異常に多いので、それらもリジェクトするようにしてみた。
私の日本語環境のPCからそうした文字を書き込んでテストした結果では一応対応できた様子だが、実際の効果は １週間ほど見ればわかると思う。イタチごっこのようなスパム書き込みと対策の戦いだ。
今日の写真も名前を知らない花。草花だが、葉っぱはヨモギのような形、花は 3mmくらいの小さなピンクの花。背丈は 10cmくらいしか無いこれも目立たない花だ。今まで １ヶ月近く花が咲いていたが、最近はもう時期を過ぎたみたいでほとんど見なくなった。

Perlの便利な点は、モジュールと呼ばれる外部サブルーチンを利用することで、簡単に高機能なコマンド(ステートメント)を利用できること。基本的なコマンドだけで記述すれば 数十行になる処理が、１〜２行で実現できたりする。
しかし、自分が利用しているサーバーはどのモジュールが使えるのかがわからない時がある。パソコン自体で実行する Cなどの言語と違って、サーバー上で実行する CGIは入出力がブラウザだけなので、逆にエラーなどの情報は得られづらい。デバックのノウハウが効率的な開発の決め手になるが、そうしたチェックも便利なツールがあったりする。
今回利用したのは、構文チェックと利用可能モジュールなどの環境チェックが両方できるフリーのツール。
その名も「すぐ使えるCGI Perl環境調査CGI」というツール。O/Sから Perlのディレクトリ、使えるモジュールのチェックまで、実行することでほぼ必要なデータは揃う。
今日の写真は名前が形そのものの花。「チロリアンランプ」(ウキツリボク)。天地創造神が戯れた？としか思えない何とも面白い形をした花だ。

今日は朝から本当に久しぶりという気がする雨。
＜お天気仕事＞という訳ではないが、この間まで自作していたサイトマップで忘れかけていた Perl言語を少しだけ思い出したので、リハビリついでにほとんど利用されてはいないが掲示板のプログラムに、スパムの検出アルゴリズムを少し追加。実際の読者の書き込みの10倍以上スパムの書き込みで、しかもそのスパムのほとんどがロシアとかウクライナなど旧ソビエト地域の IPなので、IPアドレスから国記号を検索して対象の国からの書き込みの場合は一括書き込み禁止にしてみた。（逆に日本だけを許可するという方が正解かもしれないが、万が一　イヤ 億に一？　アメリカとかの日本人が書き込んでくれるかも・・・という根拠のない期待を捨てきれなかった）
use IP::Country::Fast; を使って
　my$reg = IP::Country::Fast->new();
　my$ctrycode = $reg->inet_atocc($host);
という 2行だけで、$hostにドメイン名やIPを入れてやれば $ctrycode に JPとか USとかの国記号が返される Perlならではの便利さ。でもちゃんと働いているかの確認は？　ロシアのプロキシを使うとか？　とりあえずテストプログラムを作ってそこに IPを記述して確認してみた。
今日の写真は、昨日の花とはかなり趣が異なるがこれもカタバミ？　花の色は綺麗な黄色。最近の園芸種は品種改良が激しいせいか同じ種類でも色や形が少しずつ違っていて名前のわからない花が多い。

昨日記したように、1日 1回自分で更新しなくとも、あるページが閲覧されたらサイトマップが更新されるような仕掛けをして記録をしてみた。
但し、1日 1回では結果が分かるのに時間がかかるので、86400 ＞ 3600 として 1時間に 1回。記録は以下の様な感じ。
Sat May 4 01:04:51 2013 :: auto exec done :: 357
Sat May 4 02:48:15 2013 :: auto exec done :: 357
Sat May 4 07:36:45 2013 :: auto exec done :: 357
Sat May 4 10:25:25 2013 :: auto exec done :: 357
この場合、私のトップページに<IMG src="">文を置いたので 真夜中も 1時間毎とまでは行かなかったが、一応夜中も狙い通り起動している事がわかった。
これで本格的に設置できる。
今日の写真は、近くの公園の藤棚のフジの花。別のフジの花の写真は半月ほど前にアップしたが、こちらの方が記憶に近い開花期。数日前の夕方、ジョギング中に花の香が漂ってきたので、翌朝の散歩の時　何の花か確かめたらどうやらこの藤の花だったらしい。太陽光を透かしたフジの花と若葉の色を見ると、5月だなぁ　と思う。私の誕生日も間もなくだ。

昨日の続きで Perlメモ
サイトマップの更新を自動で 1日1回程度やる方法だが、実際にはテストしてみるといくつかキモがあったのでそのメモ。
例えばあるHTMLページが閲覧された場合、sitemap.cgi というPerl記述のCGIを起動する場合は アクセスカウンタなどと一緒で　IMGタグを使って < IMG src=" URL "> などとやる。で、CGI側なんだけれど、一般的には 不用意な実行をされないように 頭の部分でパスワードチェックをしていると思う。アクセスカウンタの場合はカウントアップだけだから無制限に実行されないと困るが、一般のプログラムだと逆に万が一環境設定などが書き換えられては困る。だからパスワードチェックの後ろにサイトマップ作成ルーチンを記述してあると、折角 CGIがコールされてもサイトマップは更新されない。
そこで、サイトマップ更新のサブルーチンだけは パスワードチェックでNGとなっても終了コマンドの前に実行されるようにしておく。

# サイトマップの更新日付をチェックして、現在時刻との差が 24時間以上なら以降を実行する

my$modtime = (stat("sitemap url"))[9] ;
my$timenow = time;
if(($timenow - $modtime) > 86400){
&make_map;
}
exit;

のような感じで。くれぐれも サブルーチンの中に端末から操作が可能になるような実行文は書かないこと。
今日の写真は、やっと 4月中に撮影した白い花の写真が終わったので、紫の花。ツリガネスイセンだろうか？ 背丈 30cm くらいの小さな花だが、低木の蔭でよく見かける。光の加減で紫が薄くなってしまったが、実際にはもっとずっと濃い色だ。

昨日の続きで Perl/CGIの話。
１日１回の実行プログラムをどう実現するかなんだけど、WindowsのようなO/Sならタスクスケジューラで起動時間を定時で指定したり出来るんだが、レンタルサーバー上のプログラムではそうも行かない。起動しっぱなしにして時間が来るのを待つ、というのもその間資源を抱え込んでしまうのでサーバープログラムではご法度らしい。
で今のところ案は２つ。　一つは、アクセスカウンタのCGIに時間をチェックするプログラムを仕込んでおき、ある時間を過ぎてまだ該当の外部プログラムを起動してなかったらそのCGIを呼ぶというもの。アクセスカウンタはページがアクセスされた度に起動されるので、ほぼ目的は達せられる。
２つ目は、Windowsの端末のスケジューラに目的のCGIにアクセスする記述をしておくというもの。こうすれば、Windowsの起動中なら（起動していなければ起動後に）該当のCGIが呼ばれて実行されるので、こちらもほぼ目的は達せられる。
どちらもあまりスマートではないが、まぁ日曜プログラマーならこの程度でいいか。
今日の写真は、まだあった４月中に咲いた白い花。ツツジ。透明感のある真っ白いツツジの花は個人的には花の数などのせいか他の白い花より清潔感があって好きだ。

ホームページをアップしていて、Google などの検索順位のアップのため（SEO対策）サイトマップというホームページのURLのリストファイルを作る必要がある。このファイルは1つずつ 手で打ち込んでもいいが、何百ページにもなるととてもそんなことはやっていられない。
自動になると、Webサービスでリンクを辿ってリストを作ってくれるサービスがあるので、そこから出来上がったリストファイルをダウンロードしてきてもいい。あるいは、フリーウェアで Webのコピー元である PCのHDD上のHTMLファイルをリストしてくれるものもあるし、サーバー上のファイルのリスト作成は Perlなどの Webアプリでもあるにはある。しかし、更新日付情報などを入れたり、自分の気に入った仕様のものはやはり自分で作るしかない。
私も今までは 一旦 Webのサービスを利用してリストを作り、その後の変更は手で追加や修正を加えていたが、例えばこのページのように 頻繁に更新するページの更新日付をその度に書き換えるのはついサボってしまい、暫く放置することが多かった。
そこで今回、1日 1度 このサイトマップを自動で作り直すツールを作ろうかと思い立った。しかも、このページは CGI経由で直接 Web サーバー上のファイルを書き換えているので、ローカルのコピーのリストを生成しても意味が無い。そんな既存のフリーウェアは探した中ではやはり無かった。シェアウェアならありそうだが それに ５千円を払う気はない。で、参考になりそうなフリーの素材をダウンロードして、それの改造で作り始めた。もう殆ど忘れかけた Perlのコマンドを思い出しつつ、四苦八苦しながらも 1週間強でおよそ出来上がったんだが、それでサイトマップを作ってみて、今度はそのリストの中にどこからもリンクされていない孤立状態のページがあることに気づいた。
理由は、表示テストでアップして削除を忘れたり、中には折角ページを作ってアップしたもののリンクを忘れてしまったページなんかもある。
で、今度は サーバー上のそんなリンク切れの孤立ページをリストしてくれるツールが欲しくなった。そんなものがあるかどうか疑問だったが、こちらは個人使用ならフリーという便利なツールが見つかった。早速ダウンロードしてきて自分のサイト上に設置してみたが、法人や商用は 5,000円ほどするというだけあって結構出来のいいツールだ。
今日の写真は「白い」オダマキ・・・・だと思う。これで一通り　4月に撮影した白い花は終わり。