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 は慣れてなくてつらい。。。
comment2008/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 とかは大変そうなので、あとまわし。
comment2008/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