2009/03/10(火)Apache httpdのセクション評価順

tech
Apache httpdの設定を行うときに、やを書くことは非常に多いと思いますが、これらの優先順位はどうなっているのか、という話。

まずはドキュメントを当たってみる。
セクションのマージ方法
マージの順番は以下のようになっています:
1. <Directory> (正規表現無し) と .htaccess を同時に (.htaccess が許可されていれば、それが <Directory> を上書きします) 
2. <DirectoryMatch> (と <Directory ~> 
3. <Files> と <FilesMatch> を同時に 
4. <Location> と <LocationMatch> を同時に 
(中略)
後のセクションのディレクティブが前のセクションのものを上書きします。
さて、これを裏付けるはずのソースコードですが...正直よくわかりません。

http://example.jp/ そのものと
http://example.jp/ 以下のコンテンツ
これらに違う設定を与えたい場合は
<LocationMatch ^/$>
  hogehoge
</LocationMatch>
<Location />
  fugafuga
</Location>
と書けば良いような気がするんですが...思ったようには動いてくれませんねぇ...

2009/03/04(水)mysqlで自動更新されるtimestampをあえて更新しない

tech
世間でも言われていますが、mysqlのtimestamp型はいろいろバッドノウハウの固まりではないかと思います。
最近はできるだけdatetime型にするようにしているのですが、すでにtimestamp型依存で動いているコードがある場合、alter tableするのも難しかったりします。

10.3.1. DATETIME、DATE、そして TIMESTAMP タイプや10.3.1.1. TIMESTAMP MySQL 4.1での性質 (いずれもMySQLマニュアル)にも諸々書いてありますが、気になるポイントは以下のあたり。
  • 各テーブルの最初に現れるtimestamp型カラムは、明示的に更新をしていないとUPDATE, REPLACEで現在時刻に自動更新される
  • 各テーブルの二つ目以降のtimestamp型カラムは自動更新されない
  • 扱える期間が1970年～2037年である (datetime型は1000年～9999年)
特に自動更新関係は、気がつかないうちにデータが書き換わってしまったり、思ったように書き換わらないことがあるので妙なバグを発生させやすいように思います。

で、今回はそんなtimestamp型で「自動更新されるはずのカラムをあえて更新しないでレコードをUPDATEする」方法について、少々。

続きを読む

2009/03/03(火)暫くTwitterは放置していたのだけど (w2t_tiny.pl)

tech
Twitterが一時まったく安定していなくて、そのときにWasserを使い始めて以来なんとなくWassrに居ついていた。
暫くTwitterは放置していたのだけど、最近なんとなくfollowしてくれる人が出てきたみたいなので、何もポストしないのも気が引ける。

ということで、面倒だからWassrにポストしたコメントをTwitterに勝手に投稿しなおしてくれるスクリプトを作った。

w2t_tiny.pl WassrからTwitterへ自動投稿

ちょー手抜き。
cronで*/15で起動しているので、最大15分投稿が遅れます。

2009/03/02(月)pythonのお勉強 (DBアクセス編)

tech
(03/03追記は「続きを読む」の後)

相変わらずpython。
MySQLとOracleに接続する必要がある。
まあ、このあたりがとても参考になる。
Cafe de Paison: MySQLdb
Cafe de Paison: cx_Oracle

ところで、MySQLdbにはDictCursorという便利なものがあります。
しかしこれ、undocumentedなの？
みなさん普通に使っているみたいですが。
そもそもMySQLdb本家を見に行ってもドキュメントが空に見えるんですが...
help('MySQLdb')でオンラインドキュメントは出てきましたが、DictCursorについては書いてない様子。


一方、cx_Oracleにはそういうなのはないらしい。
MLでも「MySQLdbのDictCursor見たいなのはないの？」「自分で作ればいいと思うよ!」*1的なやり取りがあるようですが。

pythonはDBの抽象化レイヤがない代わりにDatabase API 2.0に準拠して作られているから大抵大丈夫だよ!という話を聞いていたのですが、パラメータのバインド方法に始まりDBごとに微妙に違う部分があって戸惑ってます。
Perlでもある程度は違うんだけどね。

↓03/03追記↓

続きを読む

2009/02/27(金)pythonのお勉強 (unix timestampを可読表現に)

tech
この期に及んでpythonを初めて触ってみる。

チュートリアルとかリファレンスとか読みながらぼちぼち書いているのだけど、なかなかピンと来ない部分がある。
たとえば、unix timestampを可読な文字列に変更しようとする場合。
>>> import datetime
>>> datetime.datetime.fromtimestamp(1235051482).ctime()
'Thu Feb 19 22:51:22 2009'
動作はしているけど、一見して何が何だかな表記ではある。

どうやら
・datetimeネームスペースになるdatetime型(クラス)のコンストラクタfromtimestamp()を呼び出す
→datetime型のオブジェクトが生成される
・datetime型のメソッドctime()が呼び出される
→string型の返値が得られる
ということらしい。
>>> hoge = datetime.datetime.fromtimestamp(1234567890)
>>> hoge
datetime.datetime(2009, 2, 14, 8, 31, 30)
>>> hoge.ctime()
'Sat Feb 14 08:31:30 2009'
このように書くとhogeにdatetime型のオブジェクトが格納されていると言うことが確認できる。
>>> fuga = datetime.datetime
>>> fuga.fromtimestamp(1234567890)
datetime.datetime(2009, 2, 14, 8, 31, 30)
すごく紛らわしかったのが、これ。
fugaには何が代入されてるのかというと、datetimeネームスペースにあるdatetime型の参照を代入していると言うことらしい...
>>> from datetime import *
>>> datetime.fromtimestamp(1234567890)
datetime.datetime(2009, 2, 14, 8, 31, 30)
とかやって名前空間をインポートしてしまえ、ということなんだろう。

photo
Pythonチュートリアル
鴨澤 眞夫
オライリー・ジャパン 2007-09-22

by G-Tools , 2009/02/27