2008/08/25 (月)

今日は日帰り京都出張。
普段の京都移動は羽田から伊丹へ飛行機で飛んで、高速バスで京都駅というパターンだけど、今回は 7:10 の新幹線を事前にエクスプレスIC予約。
EX-IC が出来てから新幹線も便利になった。事前発券がいらない。Suica と EX-IC を重ねてタッチ一発。

が、日頃の習慣というのは変えるべきじゃないものなのね。
ゆうべの大雨による影響でばっちり運行に遅れが出てしまった。
6時過ぎに家を出るときに見た JR の web には遅れ出てなかったのになぁ。ぶつぶつ。。。

いま、私のそばでは出張サラリーマンとおぼしき若い男性が、立ったまま駅弁つついてる。泣けてくるなぁ。
せめて新幹線車両で着席して待てればよいのだけれど。。。

2008-08-25:mysqldump の charset

当サイトをホスティングしているサーバをリプレイスしました(このために京都のデータセンターに出張だった)。
しばらく文字化けに苦しみましたが、現在は復旧しています。

文字化けの理由は、旧サーバが mysql 4.1 で、新サーバが 5.0 なんですが、この際のデータダンプ移行で文字コードにはまる、という

超ありがち

なもの。
mysqldump –all-databases で旧サーバでデータをとったのだけど、–default-character-set で binary が指定できず、ujis でしかダンプがとれなかったのが最初のつまづき。
その後、ダンプファイルを nkf でいろいろほげほげしてから新サーバでインポートして、mysql クライアントでつないだら、中身の日本語が見えたので、いったん安心してしまった。
文字化けが php の方かなと、php.ini の mbstring まわりのセッティングをみたり、Debian の /etc/apache2/conf.d/charset にはまってるのに気づいてなおしたり、とするが、ここの文字化けはなおらず。

結局、DB 内の文字コードがだめだったのが原因。
4.1 からダンプしたときのデータの CREATE TABLE 文に DEFAULT CHARSET がないのが問題でした。
5.0 に入ったデータを再度 mysqldump -default-character-set=binary で出力し、文字コードを utf8 に変えたあと、CREATE TABLE 文の DEFAULT CHARSET=latin1 を sed で DEFAULT CHARSET=utf8 としてからインポートしなおして解決しました。

やっぱり mysql は慣れてなくてつらい。。。

comment

2008/08/24 (日)

今日もちょくちょく雨の降る天気。
ジャケット・ネクタイともに着用で外出するが、そこそこ汗もかく。

公認会計士試験も今日で最終日。いよいよ選択科目の統計学。
というわけで、都内某所で解答速報の作成作業。
気がつくとこの作業も3年目かぁ。

2008/08/15 (金)

あまりこの日に雨が降るイメージはないけど、今年もよい天気。
正午のタイミングで自席で黙祷する。

西日暮里のオフィスはお盆休みをとる者が多く、今日は自分含めて2人のみの日中。
正確に言うと、うちの会社はお盆休み制度はなく、里帰りする人は各自有休をこのタイミングでとるカタチ。
今日の出社者はふたりとも埼玉県南部出身者。

2008-08-15:new jasmine 準備

リプレイス予定の京都のデータセンターに置いているサーバのセットアップ作業。
まずは先日焼いておいた Debian etch のインストール DVD でベースのインストール。
ただ、サーバに載っている Atheros L1 というネットワークアダプタが、インストール DVD に入っている 2.6.18 では対応していない。http://atl1.sourceforge.net/ からドライバソースをもらってきてビルドして使えるようになった。
# もちろん今回のサーバからはソースを取りにいけないから、他のマシンで落として USB メモリでコピー。

ネットワークが通るまではサーバにモニタとキーボードをつなげて、サーバの前で作業。
ネットワークが通った後は、自分のデスクで使い慣れた手元の環境からのリモート作業に切替。
とりあえず、必要なパッケージを sudo aptitude install する祭り。

あと、今日はメールまわりだけ設定。
postfix + procmail + courier-imap + fetchmail という環境。
postfix は /etc/postfix/main.cf を適当にいじる。
courier-imap は、一応 CRAM-MD5 で認証できるようにしたりしてみた。ssh でトンネル掘っての利用だから別にいいんだけどね。
~/.procmailrc は現在京都で使っているものをコピーしてきて、サーバで mail コマンドでメールを自分宛に投げて、~/Maildir/ 以下に実ファイルができたことを確認してから、手元のメールクライアントでつないでみる。。。ちゃんとメール見れたわーい。
fetchmail はまだ設定せず。プロバイダからのメールは直前まで京都が拾うようにしないと。。。

DB とか web とかは大変そうなので、あとまわし。

comment

2008/08/04 (月)

今日も夕方にひどい雷。
光と音が0.5秒以内のこともあって、けっこうドキドキワクワク。
デスクトップPCの電源を落として、コンセントとか引っこ抜いておこうかとも思ったけど、結局そのまま粘って仕事を続けてしまった。

いつものように、東京アメッシュのアニメーションで今後の展開を予想するも、今日は雨が移動しないので予想しづらい。まいるなぁ。。。

2008-06-30:PostgreSQLとMySQLのUPDATE構文

あるテーブルに UPDATE かけたくて、しかし対象行の検索には別のテーブルを結合したいビューを使いたい、という場合のオハナシ。

PostgreSQL の場合、UPDATE 文に FROM 句が使えて、ここに WHERE 句で使いたいテーブル・ビューを記述できる。
例を書くと、

UPDATE table_name as t
   SET target_column_name = value
  FROM view_name as v
 WHERE t.where_column_name = v.where_column_name
   and v.search_column_name = search_value;

のような形。

が、同じことを MySQL でやろうとしたら、怒られた。MySQL では FROM 句が使えない。
MySQL の場合は単純に UPDATE のターゲットテーブルと併記すればよい。

UPDATE table_name as t, view_name as v
   SET target_column_name = value
 WHERE t.where_column_name = v.where_column_name
   and v.search_column_name = search_value;

SQL92 標準的にどうなのかは知りません。だれか教えてください。:-)

そんなことより、今日 MySQL のマニュアル読んでてびっくりしたのは、UPDATE 文にORDER BY 句が使えること。指定した順で更新されていく。

なんの意味があるんだろう?

やっぱり MySQL は変態だなぁ、と思った(誉めてます)。

comment