月別アーカイブ: 2009年8月

クロネコメール便って遅い

hero_osx_20090828

MacOS X の最新バージョン「Snow Leopard」を予約してあったんだが、まだ届かない。

発売日の8月28日にアップルから発送しましたメールが届いた。んー、発売日に到着じゃなくて、発売日に発送か。ま、配送業者名がヤマト運輸って書いてあるし明日には届くだろう。楽しみ,楽しみ。とりあえず配送状況チェーック!

8月28日20:07に品川の配送センターから発送されたという情報

おおっ、品川か。車で40分だよ。てことは明日の朝には最寄りの配送センターに届いてるだろうからやっぱり明日届くな。楽しみ、楽しみ。

ところが29日の夕方になっても届く気配なし。あれ? もう一度ヤマト運輸のホームページで配送状況を確認すると・・・・・

8月28日20:07に品川の配送センターから発送されたという情報のまま変化なし。え? 車で40分の距離なのに20時間かかっても届かないの?? 結局29日には届かなかった。

翌30日。朝飯食って、衆議院議員選挙の投票に行って、帰ってきてもまだ届いてない。ガックリしながら再度、ヤマト運輸のホームページで配送状況を確認。

8月28日20:07に品川の配送センターから発送されたという情報のまま!!!

車で40分の距離なのに・・・・・
車で40分の距離なのに・・・・・

車で40分の距離なのに、すでに40時間。品川からオレんちってどんだけ遠いってんだよ。ふと見ると「宅急便」じゃなくて「クロネコメール便」って書いてある。初めてみるサービスだ。googleで「クロネコメール便」について調べてみると、ずいぶん前からある配送サービスで、とにかく安いのが特徴らしい。そのかわり相当に遅いとかよく紛失されるとかイヤーンな話がいっぱい出てきた。はああああああああ。Snow Leopardはいつ届くんだろう。


30日18:00。配送状況は今も「28日20:07発送」のまま更新されてない。今日も無理っぽいな。いつ届くんだろう。


31日18:00。配送状況は今も「28日20:07発送」のまま更新されてない。今日も無理なんだろうか。いったいどういう方法で荷物を運んでるんだ?車で40分しかかからない距離なのに・・・・。


9月1日9:00。配送状況に「9/1投函予定」の行が追加された。やっと到着か。これから外出するけど帰宅するときには届いてるんだろうな、た・ぶ・ん。品川から車で40分の距離を運ぶのに4日かかるって・・・・郵便だって1日あれば届く距離だろ・・・・歩いたって4日もかからないよ・・・・ガックリ。

PG MBF-P02 ガンダム アストレイ レッドフレーム

アストレイレッドフレーム
アストレイレッドフレーム

ガンダムシード? ああ、テレビでやってたね。ちょっと見たけどつまんないから見るのやめたよ。特に後番組のガンダムシードディスティニーは1話見ただけでやめた。なんか初代ガンダムの劣化コピー作品みたいで。コピーとかオマージュはいいけど、劣化はいただけないな、劣化は。個人的感想だけどね。

じゃあなんでプラモデル買ったのかって? それはそれ、これはこれ。だってカッコいいんだもん、日本刀が。初回購入者には刀が2本付くっていうから初回で買ったよ。それにしてもパーフェクトグレードはデカイ。でかすぎる。できあがったレッドフレームを見たら長男が「オレも欲しい」って言うもんだから、1/144のハイグレードを買ってあげた。これはこれで良くできてるんだけど、その大きさの違いときたら。

パーフェクトグレード(1/60)とハイグレード(1/144)の比較
パーフェクトグレード(1/60)とハイグレード(1/144)の比較

さすがにパーフェクトグレードは内部構造にいたるまで作り込みが激しい。こんな大きいのに部品が小さい。小さい部品がいっぱいゴチャゴチャと、いったいこの部品はどこの部分になるんだかわからないほどの内部構造のつくり。作りごたえ満点。もうおなか一杯ですぅ。

大西洋連邦からモビルスーツの共同開発をもちかけられたオーブ連合首長国が契約に反して大西洋連邦の技術を使って作った自国防衛用のモビルスーツの試作機・・・・・らしい。が、まあオレにとってはどうでもいいや。シード見てないし。

アストレイレッドフレーム
アストレイレッドフレーム

アストレイレッドフレーム
アストレイレッドフレーム

フールドのデータを連番に更新するSQL

あるMySQLデータベースを更新するために、ローカルにデータベースを複製してここで更新したデータを差し戻すという方法をとったことがある。差し戻すときに追加データの場合、auto-incrementに指定してあるフィールドの値はよく確認しないと、ローカルで作業中にオリジナルのデータベースでもデータの追加が行なわれてしまっていた場合にIDがバッティングしてしまう。

たいていの場合はオリジナルのデータベースでその時点でのauto-incrementの最大値を確認してそれ以上になるようにローカルのデータベースのauto-increment値に一定値を加算するんだけど、今回はちょっとちがうことをしたくなった。

オリジナルのデータベースではデータ削除によってauto-increment値がとびとびになっている。ま、それはまったく構わないんだけど、大きく連番が空いている部分がある。今回のシステムではいったん削除したauto-increment値にまったく関係ないデータが入力されてもシステムの動作に全く問題ないので、追加分のデータはこのauto-increment値が連続で大きく空きができている部分に追加することにした。

そのためにはローカルで追加したデータのauto-increment値をある値からの連番に振りなおす必要がある。

で、そのためのSQL文が次の2行

SET @i := 0;
UPDATE `テーブル名` SET `カラム名` = (@i := @i +1) WHERE [条件]

これでカラムのデータを1からの連番に振りなおすことができる。