電気ウナギ的○○

そうそう。先週の月曜日はもう一つ悲しいことがあった。

それは、10年も前に作った「Apache のアクセスログをあれこれ集計する Perl プログラム」のバグが発見されたこと。(^^;

今年の 1月分から集計がされてないというお客さんからの一報で調べてみると、ありゃりゃ、substr で「4桁の年の後ろ 2桁」を抜いているのだが、こりゃ、後ろ 1桁しか抜いてないよ。とほほ・・・。

2010年の'0'しか取らずに（その後前ゼロ補完してるので）'00'年（2000年）のログを見にいってる。今までは、例えば昨年なら'09'と取ってるつもりがやっぱり'9'しか取って無くても、その後 2桁に補完する処理を入れていたので、無事'09'年（2009年）のログに行き着いていたというわけだ。だから10年間もバグが発見されることがなかったんだな(^^;;;
テストはしたんだろうけど、2010年のデータまではやってなかったんだろうな。

まあ、今なら substr なんか使わずに正規表現でビシっと抜くんで、こんな失敗はないんだけど。

日付を見たら、2000年3月に「俺が」作ったプログラムだった。(^^;
ちっ、後輩が作ったプログラムだったら散々文句を言ってやろうと思ったのに！

しかし、このプログラムを作った時は、よもや移り変わりの激しい Web の世界で、10年も使い続けられるとは思ってもいなかったよ・・・(^^;

駐車券を発見してしまった・・・

ああ、明日は月曜日。

サラリーマンの人と違って、平日・休日関係なく働いているので一般的な「月曜病」というようなものは無いのだが、やはり長い間の習性で「サザエさん」を見終わって月曜日の仕事が始まるまでの間は、何となく寂しさがあるものよ。（笑）

ま、それはさておき、先週の月曜日は実に悲しいことがあった。

以前、「に、憎い・・・タイムズ観音本町第2駐車場が憎い・・・」で書いた「無くなった駐車券」が発見されたのだ・・・

場所は、仕事場の床の上。

もちろん無くした日にそこも探したのだが、床に置いていた資料の下に紛れ込んでいたようでその日は発見出来なかったのだ。
先週の月曜日は、床を這ってたLANケーブルにちょっと足を引っかけて、そのせいでケーブルが当たって資料がずれて・・・その下から黄色い紙がちょこっと顔を出した。

タイムズ観音本町第2駐車場の駐車券ですよ！！

ああ、なんということでしょう！？わずか数十分の駐車で 5千円も払わされた悪夢の「駐車券紛失事件」から二週間が経過し、心の傷も癒えてきつつあったというのに・・・（と言っても、あれ以来タイムズ観音本町第2駐車場には一切停めてないけど(^^;）

ああ、見つけとうなかった、なかった。
いっそ、出てこなければ「どこぞの道路で落としたのだろう」とあきらめがついたのに。
こうして仕事場から出てくると「何で、あの時もっとじっくり探さなかったのか！？」と悔やむ心に悶絶してしまうではないか！もうっ！神様の意地悪っ！嫌いっ！

・・・いかん、あまりのショックに心が少女化するところだった。

まあ、そんなわけで先週の月曜日は憂鬱だったわけだ。

今週の月曜日は良いことがありますように。

UNION で結合する表内で OREDER BY が使えない話なのだが。

ああ・・・今、ふと思ったが、単に ORDER BY したものをサブクエリにすればいいだけだ・・・

SELECT * FROM (SELECT * FROM table1 WHERE d1='B' ORDER BY d2) T1
UNION
SELECT * FROM (SELECT * FROM table1 WHERE d1='A' ORDER BY d2) T2
UNION
SELECT * FROM (SELECT * FROM table1 WHERE d1='C' ORDER BY d2) T3

ま、もう、プログラム内であれこれしてしまったので良いのだが。

ちなみに、UNION で結合する SELECT 文のサブクエリにはちゃんと名前をつけないと 'Every derived table must have its own alias' のエラーが出てしまうのでご注意を。

ありり？

UNION で結合する SELECT 文では ORDER BY って使えんのやったっけ？
エラーにはならないのだが、まったく無視されてるな・・・(^^;
もちろん、SELECT 文単体や、UNION した表全体に対する ORDER BY は問題なく使えるのだが。

UNION の場合、重複行を取るためのソートが表全体に対して行われるわけで、それで各表の ORDER BY は無視されるのかと思いきや、UNION ALL でも一緒やね。

はは。日頃 UNION 使わないもんで(^^;、細かい仕様知らなんだ。

A 003
A 001
A 002
B 102
B 101
C 310
C 320
...

みたいなテーブルから抽出したレコードを

B 101
B 102
A 001
A 002
A 003
C 310
C 320

みたいに並べたいんで（最初の項目の名前をd1、２番目の項目をd2とした場合）、

(SELECT * FROM table1 WHERE d1='B' ORDER BY d2)
UNION
(SELECT * FROM table1 WHERE d1='A' ORDER BY d2)
UNION
(SELECT * FROM table1 WHERE d1='C' ORDER BY d2)

としてたんだけど、

B 102
B 101
A 003
A 001
A 002
C 310
C 320

としか出んね。（テーブルに格納されている順番そのままに出てるだけ）

取りあえずソースが冗長化して格好悪いんだけど、来週にはテストをしたいんで、それぞれ個別に SELECT 実行してプログラム内で結合するようにするわ。

識者の方、良い SQL 文をご存じであればご教示ください。

今週は自治会の班長会議で「祖生民泊協力会班員の選出について」の話合いを行った。

平成23年の山口国体のカヌー競技が中山湖で行われるので、その選手を旧周東町で民泊の形で受け入れるのである。
全部で300名くらいの選手になるのだが、祖生で受け入れるのは 50名。上地区、下地区でそれぞれ25名ずつ受け入れることになる。

上地区、下地区で拠点になる場所があり、選手はそこでまとまって食事を摂ったりするのであまり拠点から離れた場所は民泊にふさわしくない。上地区は祖生公民館が拠点になるので、うちの自治会が距離的には限界だろうな。

まだ、それぞれの自治会に正式に人数が割り振られているわけではないのだが、うちの自治会は 7～8人くらい面倒をみることになるんじゃないかな。

で、各自治会から、

・総務班（全体取りまとめ）
・美化班（宿泊施設周辺の清掃・美化）
・歓迎班（駅までの送迎。歓迎会等の準備）
・調理班（食事の準備）
・宿泊班（宿泊場所の確保等）

といった作業班の担当者を選出しないといけないので、その話合いをしたわけだが、多分うちの家で新宅で2名、旧宅のほうで3名は受け入れられるので、「宿泊班は僕やりますよ」と立候補した。

宿泊班担当者は、宿泊場所を確保したり、布団などが足りなければリースの手配をしたり、選手、あるいは場所提供者の苦情窓口になったりといった役割なので、実際に宿泊場所を提供する人がやる必要はないのだが、俺がやるのが一番効率がいいだろうと。だって、7～8人中5人はうちに泊まってもらうことになるだろうから。

ま、問題は、その頃更に IT 不況が進み、社長の俺が「そんなことしてる場合じゃない」状態になってる可能性が多々あるということだけどねぇ・・・(^^;

一応、宿泊スケジュールは短くて 4泊 5日、長くて 6泊 7日。もしかしたら初日に負けて「負け帰り」する人がいたら 2泊 3日もあり得るかも・・・という話のようだが、負けたあとも帰らずに観光をしていく人も多いようなので、基本的にはフルに泊めるくらいのつもりでいたほうが良いということだった。

食事を用意する必要がないので、そこのところは、まあ、なんとかなるじゃろう。

出来れば汗臭い筋肉隆々のおっさんより、若い娘さんとかが泊まってくれた方が嬉しいな。もちろんおっさんでも歓迎しますよ（笑）

１月の初めの話なので、もう４週間近く前のことだが、メモ代わりに書いておこう。

前の会社にいた頃に、会社でも個人でも何度か利用したことのある「和さび　胡町店」が、いつの間にか「田の倉」という店に変わってた。
内装なんかはそのままだし、看板も、「和さび」の頃の山葵の絵がそのまま残ってるんで、経営者は一緒なんかな？

取引先の人３人と、「和さびの頃からそこそこ美味いものを出す店だったんで、ちょっとここに寄ってみますか？」なんて入ってみたのだが・・・

メニューを見て、「あれ？」と皆で顔を見合わせる。

「これ、なんか高くない？」

「和さび」の頃の値段を正確に覚えているわけではないが、何か、どれもこれも２，３割高い感じ。
例えば以前は 6百円くらいだったと思うブツが 9百円くらいするような。まあ、４人が４人とも「高くなってない？」と思ったんだから、実際そうなんじゃないかなあ？

４人とも四十歳を超えた中年男子だというのに、懐の寒いメンバーばかりだったので、どうしよう？出ようか？とても金が払えん・・・などと話合いが始まる始末。(^^;
結局、「まあ、新年なんだから、すこしくらい高くついてもヨシということにしましょうか」ということになり腰を落ち着けた。

「穴子の白焼き」「牡蠣フライ」「炙りがんす」「あさりの酒蒸し」「月見つくね」「ふんわりだし巻き玉子」「かりかりちりめんと水菜サラダ」「湯どうふ」「漬物盛り合わせ」といったあたりを注文。どれも美味かった。４人でちょっとずつ分けあって食べる姿が若干寂しかったが。

飲み物は、一発目から皆バラバラ。Ｋシさんはいきなりワインをハーフボトルで。ＳワさんとＯワさんは生ビールだが、俺は熱燗。
お客さんにこういう言い方は失礼なのですが、いやぁ、サラリーマンなのにフリーダムですなあ、みんな。(^^;

それから仕事の事や、好きな女優やアイドルの話題で盛り上がりつつも（中学生か、わしら）、値段が気になるので、何となく皆酒は押さえ気味です(^^;
俺も、いつもの半分くらいしか呑まなかったかなあ。でも、まあ、女優の話の時などは、皆、個人名が出てこないお年頃なので iPhone の Google アプリの音声検索が大活躍。楽しい時を過ごすことが出来ました。

で、支払い。

酒の量を絞ってたので、無茶苦茶高くついたわけではなかったが、やっぱ、まあ、そこそこ。(^^;

地場の素材などを使い「和さび」の時よりお金もかけてはいるんだろうけど、それが見た目や味に強く出ているわけではないので、やっぱどうも「損した気分」になってしまう。
「和さび」の時より高級感のある店にしたかったのなら、内装もごっそりやり変える等、昔の店の面影がないようにしないと駄目なんじゃねえの？

だって、「和さび」で食事をしたら以前より高い金を取られたって感じしかしないんじゃもん。（だって「和さび」の頃から、食い物はそこそこ美味かったし）

ということで、もう一度行くことはないだろうなあ・・・

一昨日、去年まで一緒に常駐の仕事をしていた＠マさん（仮名）と久しぶりに一杯。
つーか、以前は会社がらみの飲み会（忘年会とか歓送迎会とか）でしか一緒に呑んだことはなかったので、二人で呑むのは初めてだなあ。

安佐南区方面にお住まいなので、横川駅で待ち合わせてそのまま駅裏へ。
この間横川で呑んだ時は星のみち商店街の方まで行って失敗したからな。(^^;
ということで、以前、Ｗ■さんと行ったことのある「風の華　横川店」に入ってみた。

いやあ、一年近くお会いしてなくて、今は同じシステム開発業とは言え全然毛色の違う現場にいるわけだけど、話題に困ることはなく色々な話で盛り上がりました。
「IT不況」という負の話題が中心でしたけど（笑）

ほんと、是非また近いうちに一緒に呑みたいものです。

ところで「風の華」はやはりなかなか料理は美味かったですな。

腹一杯食ったわけではないけど、お互いビールの中ジョッキを４杯やって、「芝海老とガーリック炒め」「ほたてカツ」「明太オムレツ」「合鴨とトーフのサラダ」「スモークサーモンとイクラの親子サラダ」などをつまんで一人 4千円ちょっと。
まあ、料理の質からいったら適当な金額じゃないかな。

ちなみに、「スモークサーモンとイクラの親子サラダ」はいまいちだったなあ。店は自信のメニューのようだけど。
カレー味が付けてあるんだけど、あれってイクラと合わんじゃろう。(^^;
いやあ、確かにカルパッチョで生魚とカレー風味を合わせることはあるけど、イクラの苦みに合わないんだよねえ、カレー味。
いや、ま、人気メニューらしいので俺の舌の方が間違ってるんだろうけど、次回行った時にうっかり注文しないようにメモっとく。（笑）

ところで、一緒に呑んだ＠マさん。なかなかの酒豪でペースが速いので助かりました。
俺もそこそこクイクイいっちゃうので、ペースの遅い人と呑むと気をつかってチビリチビリになっちゃって美味くないんだよねえ、酒が。
一昨日は、俺の方が追っかける展開で良かったっす。度々＠マさんにはジョッキが空の状態で足踏みさせてしまって申し訳なかったですけど。(^^;

そうそう、「風の華　横川店」に言いたいことがもう一つあった。
座敷の足置くところにしいてあった剥き出しのクッション何？(^^;野球部がグランドに溜まった水を吸い取るのに使うようなやつ（笑）。ちょっと感触が気持ち悪かったんですけどお。(^^;

昨日の昼飯は、前から気になっていた東観音町の「薩摩地鶏　一歩」にて。

ここには１コイン（500円）ランチがあるので、IT不況の波に木の葉のように舞う零細経営者としては、押さえておかなくてはならぬ店であろう。あろう。だろう。

カウンターとテーブルが一つだけの狭い店。8人入ればきちきちのぎゅうぎゅうになる。そんな店。
カウンターの横には色々な焼酎の瓶がずらり。なるほど「九州っぽい」。地鶏の焼いたヤツをアテに焼酎をストレートでグビッとやれば、それはもう至高の一瞬だろうな。是非とも夜来たい店だ。

でも、今は昼。仕事もあるし焼酎というわけにはいかない。ランチだ、ランチ。

んで、500円ランチは 3種類あるようなんだが、俺は「唐揚げ定食」をチョイス。
キャベツの千切りが鬼のように盛られててボリューム満点。いや、そんなもんでボリュームを増しちゃいかんだろうという意見もあるでしょうが、ダイエット中の俺にはちょうど良い。
敢えてダイエットのために「野菜中心」の食生活にするつもりはないが、オーダーしたものにたっぷり野菜が乗っているのは嬉しいのだ。

唐揚げは４つだが、けっこう大きいのでボリューム的には十分。
残念ながら、唐揚げは地鶏ではなくブロイラー。それも、水気の多い（こういうのは肉汁とは言えん）あまりよくない肉質のヤツだよね、これ？
ま、500円のランチなんだからそれは仕方無いし、もちろん美味くは無いけど（笑）不味いわけでもないのでご心配なく。:-P

小鉢で付いてきた鯛の蒸したヤツ（？）は美味かった。味噌汁は熱々じゃなかったので残念。飯は水の量が多かったか、蒸しようが足りない感じ。ちょっとべちょっとしてたな。

残念な事件が一つ。
唐揚げには少し塩が振ってあるが、濃い味好きのデブとしてはもう少し味が付いている方が嬉しい。だからカウンターに置いてある塩の瓶をパパっと振って塩気追加！で、次にその隣の黒胡椒の瓶を振ると・・・

何も出てきませんよ。あり？空じゃん。

「空ですよお」と言おうと思ったんだけど、板さんも給仕のお姉ちゃんも忙しそう。こうなると人見知りの激しい俺には声をかけるなんて無理。泣く泣く塩味だけ強化して食べた。
調味料の残り量は、ちゃんと開店前にチェックしとこうよ！
だって、きれいに空っぽだったぜ、黒胡椒。開店直後だったのに。

いや、まあ、そのせいと言うわけではないが、もう一度この店でランチをするかというと微妙なところ。内容的にせいぜい 600円くらいのものかなあ・・・という印象で、そんなに激しい「お得感」が無かったからなあ・・・

もう２週間前の話ですが。

未だにショックが尾をひき、わざわざ駐車券が発行されない 100円パーキングまで車を停めに行く日々です。

いや、まあ、俺のミスなんだけどね。

この間、100円パーキング「タイムズ観音本町第2駐車場」に車を停めて、ラーメンを食いに行ったのですわ。
で、30分後に帰ってきて車を出そうとすると・・・駐車券がありません・・・

実は、タイムズの駐車券って、以前も落としたことがあるのよ。
そのときは自分の仕事場で落としたんですぐに見つかったんだけど、この日は一般道のどこかで落とし、しかも風が強い日だったので・・・
涙目で駐車場とラーメン屋の間を二往復したけど見つからず・・・

何故、タイムズの駐車券をそんなに落とすのか・・・！？
実は、タイムズの駐車券って紙質がすべすべしてて固いので、ばっちり iPhone の画面に収まってしまうのだ。大きさもベストフィットなんで。
んで、iPhone をポケットから取り出す時に 90% 以上の高確率で一緒に出てきちゃう。(^^;

いや、わかっていた。わかっていたのだけど、そのときは混む前に店に入りたいとか、色々焦ってたんだろう。ついつい忘れていたのだ。

ほんま、最悪。

で、諦めて、「仕方ねえな。2千円とか 3千円とか取られるんだろうな。ま、駐車券を落としたのは俺だからな」と精算しようとすると、俺の目に飛び込んできた信じがたい金額。

「ご・・・5千円！？」

あり得～ん！！

なんとまあ、１日停めてても 600円しか取らないタイムズ観音本町第2駐車場が、俺から 5千円ももぎ取ろうとしてるのですよ！！！！！！

久しぶりに立ちくらみが・・・

しかも、万札は使えんし！！

俺はもう一度車を元の場所に戻し、赤く染まった目で、「くそっ！くそっ！死ねっ！死ねっ！くそっ！くそっ！死ねっ！死ねっ！・・・」と悪態をつきながら近くのコンビニに両替に行ったのであります。

いや、もちろん、悪いのは俺だ。駐車券を落としたのは俺だ！俺が悪いのだ！

・・・しかし、5千円？30分だけ停めてた俺から 5千円！？
憎い、憎い、憎い・・・例え逆恨みであろうとも、憎い、憎い、憎い・・・

ということで、この日以来、少し歩いたところにある 100円パーキングへわざわざ行っておるのです。もう二度と、タイムズパーキングには停めねえ！あの憎き駐車券を発行するタイプの駐車場には停めねえ！

雨の日や寒い日など、ついつい仕事場に近いタイムズ観音本町第2駐車場に停めてしまいそうになる日もありますが、絶対、二度と使わねえ！という鉄の信念のもと、何とか利用を回避しております。

やっぱ、駐車番号入れて精算するタイプの100円パーキングが一番安心じゃね！

最近 MySQL では UTF-8 しか扱ってなかったのだが、今回作成したプログラムは「Shift_JIS で書かれた CSV ファイルを読み込んで DB に登録。もちろん NEC 特殊文字や NEC 選定 IBM 拡張文字もガンガン混ざってますぜ！」という香ばしいもの。

ソース自体は EUC-JP で書いたので、DB の中身も EUC-JP で保管するようにして、自前のコード変換関数で Shift_JIS→EUC-JP に変換している。
CREATE TABLE するときにも、ちゃんと DEFAULT CHARSET=ujis 付けてるしね。

なのに、データを登録した後で phpMyAdmin でチェックすると、日本語化け化けやん。

どうも、MySQL ではサーバ側で勝手に文字コードのエンコードをしてしまうので、UTF-8 以外のコードではこういう文字化けが発生してしまうという。
日頃 PostgreSQL ばかり使ってて、いきなり MySQL に来たら絶対ハマっちゃうよなあ、これは。

で、解決方法としては、本来の SQL を投げる前に、

SET NAMES ujis

という SQL を発行すること。

具体的には、

$query    =<<EndOfQuery;
SET NAMES ujis
EndOfQuery

$sth = $dbh->prepare($query);
$sth->execute();

としてから、本来の SQL を

$query    =<<EndOfQuery;
INSERT
INTO
  hogehoge
～本来の SQL～
EndOfQuery

$sth = $dbh->prepare($query);
$sth->execute();

と実行すれば良いと。

なんだかなぁ(^^; テーブル作る時に DEFAULT CHARSET=ujis なんて宣言している意味がなかったな。(^^;
まあ、DB に詳しい偉い人たちが文句を言ってないってことは、この実装も間違いではないんだろうけど、なんだかなあ(^^;

ちなみに、MySQL の設定ファイルや実行時のオプションであれこれする方法もあるようなのだが、今回使用しているのが安いレンタルサーバで、MySQL の設定ファイルは触れない仕様らしいので、毎度 SET NAMES ujis を発行する方法しかないようだ。

とほほ。またも無駄な時間を・・・