5月1日から磐梯方面に旅行に行ってきた。5月1日は予想外に早く起きることができたので、朝10時過ぎに出発。空いている東北道を北へと向かった。宿は五色沼付近に取っていたのだけれども、まっすぐ宿に向かうのはつまらないので、わざと福島西ICまで行って、そこから磐梯吾妻スカイライン、磐梯吾妻レイクラインを経由して宿へと向かうルートを選択。

福島西ICで高速を降りたところでガソリン残量があと1目盛り程度となっており、ガソリンスタンドを探しながら磐梯吾妻スカイライン方面へと向かったら、いつのまにやらガソリンスタンドなど全くない山の中に入っており、結局給油できないままに磐梯吾妻スカイラインの入り口料金所についたときには、ガソリン残量はあと0.5目盛りほどになっていた。料金所のおじさんに道のりを聞くと38kmあり、ガソリンスタンドは区間内には存在しないという。

うちの車の燃費は通常10km/l弱。ガソリン1目盛りでだいたい30kmくらい走れる。燃料メーターでマイナス0.5目盛りあたりまでは走った経験があるので、燃費のいい山道ならばぎりぎりなんとかなりそうな距離だ。磐梯吾妻スカイライン入り口に着くまでのガソリンスタンドがない道もかなり長かったし、引き返しても結構ぎりぎり気味だ。ならば燃費よく走って先に進んだ方が、今後のスケジュールを考えてもよさそう。

というわけで、残り0.5目盛りのガソリン残量で磐梯吾妻スカイラインに突入。途中眼下に福島市を臨む場所や、硫黄臭がする火山跡地っぽい場所など見所がいくつかあったのに、それらには目もくれず最高燃費運転だけを考えて、ひたすら山道を進む。無駄な減速をしないように運転したため、乗り心地がかなり犠牲にされてしまい、後ろの席ではムスコが車酔いをしてかなり気分が悪そうな表情になっていった。それでも山の中でガス欠になるよりはマシと、心を鬼にしてそのまま進む。

道程の三分の一も過ぎる前に、ガソリン残量は残り0目盛りとなった。しかも、磐梯吾妻スカイラインは単純に上って降りる山道ではなく、尾根沿いを上ったり降りたり繰り返しながら先へと進むタイプの道だった。後半下りが連続すればそこで燃費を稼いでなんとかなるかも、という淡い期待が徐々に薄れていく。後半はもはや最後まで行き着くことよりも、いざアクセルを踏んでも加速しなくなったときに、安全な場所で停車する方法を主に考えながら進んでいった。

しかし、道程の最後の2割に差し掛かったあたりからは、ほとんど下りが続く道に変わり、ほとんどアクセルを踏まなくても進むようになった。そこでカーナビに最寄りのガソリンスタンドを探させたところ、有料道路区間が終わって2kmほどのところにガソリンスタンドがあった。マイナス0.5目盛りあたりを差しているメーターをにらみながら、アクセルの反応をおそるおそる確かめつつ、なんとかナビが示したガソリンスタンドまでたどり着くことができた。ガソリンスタンドに車を入れ、止める。

しかし、どうもおかしい。変に荒れたスタンドだ。人の気配もない。まるで営業していないかのように見えるのだが、どこにも閉店などという文字は書かれていないので、それを信じて店の中をのぞいてみた。誰もいない。表の給油機を見てみると、片方の保証期間はすでに去年で切れていた。やばいこの店はすでに死んでいる。

次のガソリンスタンドをナビで探すと、次は6kmほど離れたところに2件あった。オクサンが片方を適当に選ぶ。エンジンがちゃんと再始動するかどうか不安になりながらもキーをひねったら、なんとかエンジンがかかった。再び神経をすり減らしながら6kmの道のり。なんとか次のガソリンスタンドまでたどり着いた。

しかし再び、停車しても店員は誰も出てこない。まさかここもつぶれているのかとビビりつつも、事務所の中に顔をつっこんだら、全然表の方に注意を払っていないおばちゃんが一人で事務仕事をやっていた。声をかけたら気がついてあわてて出てきて一件落着。給油量は燃料タンク容量＋3lだった。ちなみにその後、ナビが示していたもう片方のガソリンスタンド前を通りかかったところ、そちらは祝日閉店だった。あぶないあぶない。

その後はのんびりと磐梯吾妻レイクラインを通って五色沼付近に到着。予定よりも1時間ほど早く宿に着いてしまった。しかしすり減った神経で遊びに出かける気力はなかったため、宿でマンガを読みながらごろごろ。あとは風呂に入って飯を食ってマンガを読んで終了。

宿で朝飯を食べてから適当に行く先を考え、米沢方面へと向かう。湖沿いの山道を走ること1時間ほどで米沢に着いた。結構近いんだな。

まず上杉家御廟所に寄り、それから民芸品館みたいなところに寄り、駅前に行ったけれども車を停めやすい場所が見あたらなかったので、結局上杉神社（というか上杉博物館）に車を停めて、そこらをうろうろしつつ軽食を食べる。上杉神社に来たのは3回目か。

それから喜多方方面へと出発。こちらも1時間ほどで到着。喜多方ラーメン館のそばにあるラーメン屋で遅い昼飯。喜多方ラーメンってどこで食っても同じ味がする。味自体は嫌いじゃないけれども、わざわざ本場に行く価値はないよな。

で、それから宿方面に戻りつつ桧原湖の遊覧船に乗ろうかと思ったら、遊覧船は15時半で終了していた。あとは宿に戻って風呂に入って飯を食ってマンガを読んで終了。

まず五色沼にちょっと立ち寄り、それから猪苗代湖方面へと向かう。昨日桧原湖で乗り損ねた遊覧船に乗ろうと遊覧船乗り場を探しつつ、湖畔を東回りに一周しようとしていたら、南側で積雪通行止めの区間があった。そこで湖畔一周はあきらめていったん会津若松に向かう。

会津若松といえば、ということでひとまず鶴ヶ城に行ってみるが、息子を連れて天守閣まで上る根性が出なかったのでとっとと出る。で、そばにあった会津酒造博物館に入ってみたが、いまいち好みのタイプの酒がなかったので何も買わずに出る。ちょっと酔っぱらったのでオクサンに運転を代わってもらい、再び猪苗代湖方面へ。

猪苗代湖に二カ所ある遊覧船発着場のうち、北側の方を発見することができたので、ようやく遊覧船に乗ることができた。でも、単にぐるっと湖を走るだけのあんまりおもしろみのない遊覧船だった。鳥にえさをやって集めたりしてくれれば面白いのに。

遊覧船に乗り終わったのが夕方前くらいだったので、そのまま帰ると帰りのラッシュのど真ん中にぶつかりかねない。そこで福島市の方へとわざと遠回りして帰ることにする。しかし福島市といっても特に何か食いたいものは思いつかない。結局福島市は素通りしてそのまま国道4号を帰路につく。

あのあたりの国道4号はまるで高速道路のような作りになっており、平均時速も80km/h近い。なかなか快適だったのでしばらく下道を走り続けていたのだけれど、そのうちだるくなってきたので宇都宮の手前で高速に乗る。高速も空いていたので、燃費が悪くならないよう、飛ばしすぎないように気をつけながら浦和まで。家に到着したのは22時頃。

ペンションに泊まりといえばペンション蔵書マンガ読み。ということで、結構いろいろ読んだ。「バガボンド」既刊分全部。「MONSTER」全巻。「がんばれ元気」ラスト5巻。「めぞん一刻」ラスト4巻。「バリバリ伝説」最初の6巻。「七夕の国」全巻。「MONSTER」と「七夕の国」は途中まで読んで放置してあったので、ようやく最後まで読めてすっきり。どちらもそこそこ良くできていたけれども、ものすごく良いというほどでもなかったのでちょっとがっかり。まあストーリーもののマンガとしては すごく良くできていたけど。ストーリーマンガで最後までちゃんと終われるものは少ないからな。バガボンドは通してみたらそこそこ面白かったので、帰ってきてから思わず吉川英治「宮本武蔵」を買ってしまった。そっちの感想は別項で。

Ｙａｈｏｏトップページでマグワイアのユニフォームが出品されました。落札価格は、４３０１０００円です。それだけの価値はあるのかも知れませんが、落札したのは、Ｙａｈｏｏの人間です。当然、主催者、関係者は激怒したと思いますが、屈服したと思われます。再度、出品すえば、主催者、関係者が疑われます。落札ID=auction_test1,,,,そのつながりでID=mineki_yashiro,,,,,,y_charity_auction,,,,,,なんと、auction_test1とy_charity_auctionは、同じ人物のメールアドレスだったようす。Ｙａｈｏｏの言い分は、テストＩＤをオークションには反映されないものと勘違いして、ある人物が入札したので、次点の方に権利を移して欲しいと終了後にメールが来たそうです。このメールは、次点の方から５番目ぐらいまでＹａｈｏｏのメール付きで出されたようです。しかし、勘違いで、４３０万円を落札するでしょうか？このチャリティの関係者は、目玉中の目玉が、今も残っており困っているようです。Ｙａｈｏｏがオークションをぶちこわしてどうすんだ！価格を自身で吊り上げ、ＰＲしたかったのか？それとも本当にミスだったのか？どう思います？

お世話になっております。
Yahoo! JAPANの××でございます。

この度は私にこちらのメールが届きまして、おかしいなと思いながら調べてみますと弊社側でとんでもないミスを犯していることが判明いたしましたので、取り急ぎご連絡させていただきます。

実は今回最高落札者になっておりましたID: auction_test1 は弊社オークションにて管理しているテスト用IDでして、登録メールアドレスが私のアドレスになっております。　実はこのIDを弊社の者にテスト用として19日に渡したのですが、この者がテスト用だから本番に反映されないと思い込み実際にこちらのIDを使っていくつかのオークションにて入札を行いそのままにしていたところ、最終的にこちらの商品を落札してしまったという次第であります。
大変恐縮ではございますがこちらのIDの入札を削除していただき、落札権利を次の方にお譲りいただければ幸いでございます。
この度は弊社側の失敗によりこちらのオークションに大変ご迷惑をおかけしてしまい申し訳ございません。

まずはメールにてご報告させていただきます。
どうぞ宜しくお願い致します。

××

あちこちで話題になっているYahoo!オークションの社員による落札価格操作疑惑。さすがに「auction_test1」なんてIDで操作をしようと思うバカはいないだろうから、これは本当にミスなんだろう。

でもYahoo!オークションは、有料化の際に「出品者は、落札価格の3%を落札システム利用料としてYahoo!に支払う」という仕組みを用意しており（5/15より施行）、しかも、「落札システム利用料は毎月20日までに終了したオークションの月末時の落札額を基準に集計した料金の合計を翌月請求させていただきます。 」となっているため、イタズラで高額落札された場合にも落札金額の3％を支払わされかねないという、利用者に非常にキビしい内容となっている。ただでさえそのあたりのシステムの練られ方がアヤシイ状態なのに、いくらミスとはいえ高額目玉商品の落札に社員が関わっていたという事態（がばれたの）に、関係者数名にメールでお詫びしておしまいにしようってのはどうだろう。

もともと有料化システムの怪しさがクリアにならない限りは利用する気になれないでいたけれども、こういうことがあったんじゃシステムが（表面的に）まともになったところで今後利用する気になれないなー。ソフトバンクはまだ若い会社だからこういう正常系じゃない事態に対する対処法が甘いのね（Yahoo!BBしかり）、と考えてあげることもできるけれども、あれくらいでかい会社だったらさすがにそういう言い訳も一般的には通らないだろうし。

最近帰りが終電ぎりぎりで心臓に悪い日々が多いんで、今日は久しぶりにバイク通勤にしてみた。この間ちょっと遠出しておいたんでバッテリは一応充電されていたけれども、ここ数日寒い日が続いていたせいかやたらとエンジンのかかりが悪かった。でもまあ走り出してしまえばそれなりに安定。そういやチェーンオイル注さないとな。

去年からいろいろ試してみたけれども、結局渋谷までの一番マシなルートは地図上の最短ルートでもある旧17号−明治通りであるという結論に達した。池袋、新宿、原宿、渋谷とやたらと路駐＆タクシーが多くて混雑する、バイクにとってはものすごく走りにくいルートだけれども、それより多少マシな山手通りや環七を通ったところで、遠回りする距離のデメリットが大きすぎる。

走りにくい明治通りをのろのろ通ったところで会社までだいたい1時間。それより多少マシな気分で環七や山手通りを通ったところで、やっぱり会社まではだいたい1時間。運悪く環七や山手通りが混んでいることも少なくないことを考えると、最悪でもだいたい1時間でつける明治通りの方がマシだ。

それにしても、このくらいの時期のバイク通勤は着るものに困る。溝の口の頃みたいに30分以内の道のりならば服装なんてどうでもいいけど、1時間以上となるとちょっとしたツーリングみたいなものだし、あんまり軽装だと疲労が大きそうだ。それにどうせ帰りは夜中だからある程度寒くなることは目に見えている。だから防寒性能の高い上着は必須なんだけど、そうすると往きに着るのは暑いし持っていくのはじゃまくさい。日が暮れる前に帰れるんだったら、この時期のバイク通勤は快適だろうになー。

今やっている仕事は5月末完成目標なのに、いまだに基本的な部分の仕様が固まらない。もともと第一期目標の表面的な機能（現実）は低い位置に定めてあるんだけど、その裏側にある仕組み（理想）があまりにも高度すぎて、仕様策定段階で理想と現実とのどのあたりに着地点を見いだすべきかのポリシーが見いだせない。結局残された期間が短くなるにつれ、実装の手間を省く（作業時間を短縮する）ためにどんどん現実が理想を浸食していっている。

という夢と現実の狭間をさまよう議論を毎回のように行っているため、一回の打ち合わせ時間がめちゃめちゃ長くなる。週1、2回のペースで打ち合わせをやっているんだけど、最初のうちは3〜4時間程度だった打ち合わせが、今日はついに5時間半を超えた。そろそろ論理脳の活動限界に達した気がするんで、今日をピークに今後は打ち合わせ時間が減っていくといいなー。

久しぶりにバイク通勤したと思ったら、帰りは微妙な小雨だった。バイクを捨てて帰ろうかと思ったんだけど、ちょうど埼京線の下り電車がない時間帯（23時台前半）だったんで、根性出してバイクで帰宅。往きに厚着しておいて良かった。今の期間は深夜に明治通りで全面工事をやっているみたいで、夜の割にはあんまり流れが良くなかったんだけど、それでもドアトゥドアで50分弱で帰れた。往きはつらいけれども、帰りは終電を気にしなくてもいいし時間も短いからバイクの方が楽だなー。

前にネタにしたマイクロソフトの.netを使ったP2Pゲーム開発競争「Terrarium」ってもう始まってたんだね。すっかり忘れていたよ。実際にダウンロードしてサンプルをコンパイルしてみたりしたんだけど、やっぱり結構面白そうだなー。今もうちょっと暇だったら.net系言語のお勉強がてら遊んでみたいんだけど、6月にはいるまではそんなんやっている暇はないよなー。コンテストの期間（6/28まで）が終わっても、サーバー運営を続けてくれるといいんだけど。

関連記事 /.J「C#が人気急増中?」@IT「テラリウム徹底攻略ガイド」

ASP.NET（の中の主にVB.NET）に関する覚え書き第2弾。DBアクセス周りについて。

従来のASP（Active Server Pagesの方ね。Application Service Providerじゃなくて）ではADOを使ってDBアクセスを行っていたが、.netではADO.NETというオブジェクト群を使ってDBアクセスを行う。ADO.NETのコアといえるオブジェクトはDataSetだ。DataSetは一般的なDBMS（SQL ServerとかOracleとか）を利用したデータベースのみならず、XMLファイルなどもデータベースソースとして扱うことができる。概念としてのデータベースを（DBMSから切り離して）高度に抽象化したデータ操作オブジェクトとなっている。

というのがASP.NETの売り文句なんだろう。しかしそれを聞いて、「ふーん、DBMSだけしか扱えなかったADOと違って、.NETではXMLもデータベースとして扱えるように拡張されたんだ」と思ってしまっては罠にはまる。ADO→ADO.NETの変更は拡張ではなく、根本的なポリシー変更（＋おまけ的部分の拡張）だと考えた方が良さそうだ。

というのはなぜかというと、従来のADOでは基本的にデータベース＝DBMSに限定されていた分、ADOを通してDBMSの機能をほぼそのまま利用することができた。しかし、ADO.NET（の中のDataSetを使ったデータ操作）においては、データベースはDBMSとは直接は結びつかない。DBMSのみならずXMLもデータベースソースとして等価に扱えるよう抽象化された結果として、DataSetというのはデータベース上にあるデータそのものではなく、データベース上にあるデータをメモリ上にコピーしたものになってしまった。

「従来のADOを使ったDBアクセスだって（参照系においては）似たようなものだったじゃないか」と思う人もいるかもしれないが、いざとなったらDBMSと直接接続できる（カーソル、トランザクションが使える）ADOと必ずDBの内容をメモリ上にコピーしてからしか扱えないADO.NETとでは、参照系以外のDBアクセスの使い勝手がまったく異なる。今まで調べた限りにおいては、DataSetを使ったDBアクセスにおいて、従来カーソルやトランザクションを使って行っていたような処理を、従来と同程度に手軽に実現する手段は見つけていない（DataAdapter経由でDBMSに直接SQLを発行して、前と同じ内容を前より面倒くさい手段で実現することはできそうだけど）。

ちなみに、データベースの参照系の使い方においては、ADO.NETは非常に便利な拡張をたくさん用意している。従来一般的に使われていた、RecordSetを1行1行ループで回しながら出力していくような処理は、DataSetという形でまとめて表示用コンポーネントに引き渡すことで、ページング処理まで含めて簡単に実現できるようになった。でも、それは確かに実装上の手間を大きく省くかもしれないけれども、クラス仕様の実質としてはおまけ的な意味しか持たないだろう。

という理解の元で、ひとまずお勉強がてらADO.NETを使ってDBアクセスするサンプルをいくつか作ってみたところ、データの参照・更新などを行うプログラムは非常に簡単に作ることができた。しかし、DataSetを使ってお手軽に作ったプログラムにおいては主に更新時のデータ整合性の保証が全然ないように思える。ADO.NETは標準でデータ整合性を保証する仕組みをサポートしないつもりなんだろうか？　それとも俺の知らないどこかで保証する仕組みが動いているのか？　まさかADO.NETは同時更新が頻発する規模のDBアクセスは、標準的に想定外ってわけじゃないよね。

いろいろ調べているうちに、従来のADOを.NET上でADO.NETと（ほんのちょっとだけ）連携させて使う方法を発見したんで、参照系以外の処理は従来のADOを使ってやった方がいいんじゃないだろうか、というのが今のところの結論。でもADOとADO.NETでは互換性がほとんどない（ADOのRecordSetをDataSetにFillできるだけ）んで、両方使うのって重複する（けど書き方が違う）部分が大きくてあほらしい気がするんだよな。実はDBアクセスはすべてADOベースで行いつつ、ADO用の表示を簡略化するためのコンポーネント群を作った方が開発が楽だったりして。DataSetの代わりにRecordSetを食わせるDataGrid（一覧表示用コンポーネント）みたいなものって、結構簡単に作れるんじゃないか？