Saturday, February 28, 2009

昆布だし

妻が北海道旅行のお土産として知り合いから乾燥した利尻昆布をもらってきた。しかし、これまで顆粒の「だし」しか使ったことのない自分は、どうやってとればよいのかが分からない。そこでWebで調べてみると、おおむね以下のようなことらしい。
  1. 鍋にだし昆布と水を入れて30分以上つけておく(可能ならば一晩)
  2. そのまま火にかけ、沸騰直前に昆布を取り出す
ポイントは、「水から煮て」「煮立たせない」ことらしい。料理に入れたままにして煮立たせると、「臭み」や「ぬめり」の原因になるからだそうだ。

料理にそのまま入れっぱなしにして、長時間たてばたつほど「だし」が出るというものではないらしい。勉強になった。

Saturday, February 14, 2009

Ultimate Windows Tweaker

新しいPCを買って不満なのがOSだ。バンドルされてきたのはWindows Vistaなのだが、XPと比較して起動・終了がとても遅く、明らかにデグレードをしている。

色々レジストリをいじれば早くなるであろうということは分かっているのだが、そんな「環境設定」に時間を掛けられるほど自分はヒマではない。さらに言うと、何も新しいものを生み出さない環境設定やOSのセットアップに時間を掛けることは、バカバカしいとすら思っている。

そんなこんなでデフォルト状態でずっとVistaを使ってきたが、Life Hackerに「Ultimate Windows Tweaker」の記事が。


これは、レジストリの操作が必要なカスタマイズ項目をGUIで提供してくれるというもの。早速使ってみると、5分もしないで自分好みに設定ができ、スピードも速くなった。作者には本当に感謝。

Thursday, February 12, 2009

Firefox Plugin - Hide Menubar

これまで使っていたThinkPax X40に変えて、新しいHPのノートPCを買った。今、ワイド画面を満喫しているところだが、この横幅に慣れてしまうと、もっと縦幅が欲しくなる。
特にWebブラウザでは顕著だ。そこでFirefoxのPluginを調べてみたところ、Hide Menubarというプラグインが。

単にメニューバーが消えるだけなのだが、これだけでも相当縦幅が長くなった気がする。
メニューが欲しければAltキーを押すだけだし、ブックマークのロードなどのメニュー操作はいつもキーボードを使っているのでまったく問題ない。

また、新しく常用するプラグインが増えた。

Wednesday, February 11, 2009

Django雑感

最近、Djangoを使いはじめた。自分なりに色々触ってみての雑感は以下だ。
  • 設定ファイルをいろいろいじらないといけない
例えば開発用サーバでHTMLや画像といった静的コンテンツを表示するために追加で設定が必要だったり、アプリケーションやViewを作成するたびにsettings.pyやurls.pyというファイルを編集したりと、設定ファイルを頻繁に変更する必要がある。

これまでは、PHP + SMARTYやPythonでもmod_python + Cheetahという組み合わせを使っていたので、新たに作ったViewのためのファイルはそのまま使うことができたが、ちょっと勝手が違う。

つまり、ApacheのDocumentRootに置いたものはすべて閲覧/実行可能で適宜.htaccessで制限を掛ける、に対して、Djangoではデフォルトで何も閲覧できない状態で、公開するものをその都度設定する、という逆の発想なのだ。セキュリティを考えるとこちらの方が望ましいのだろう。
  • O/Rマッパーやフォームの自動生成
これは本当に便利だ。これまでゴリゴリ自分でDBのラッパを書いていた作業がなくなるのは本当にうれしいし、これはフォームの値のValidationについても同様だ。特に1.0で導入されたFileUploadは秀逸。
  • settings.pyのフルパス記述の強要
settings.pyのMEDIA_ROOTやTEMPLATE_DIRといったディレクトリを書く項目は、必ずフルパスが要求される。これまでは、動作させるサーバに依存しないためにWebアプリケーションは相対パスで書くようにしていたので、最初は少し戸惑った。しかし、この場合でも毎回settingsの値を参照するようにして、別のサーバ機に移行したときにはsettings.pyを編集すればよい、という点ではまったく同じだ。また、何かフォルダ定数ができるたびにsettings.pyに保存しておく癖をつければ、「とりあえずハードコーディングであとでiniファイルに落とせばいいや」で結局そのまま、という悪癖をなくすこともできる(まあ、これまでは自分の意思が弱かっただけ、といううわさもあるが)。

しかし、自分はアップロードした画像をファイルとして保存して扱うアプリケーションを書くことが多いので、ロジック中でMEDIA_ROOTを使い、Viewへ渡すときにMEDIA_URLベースに変更という作業が毎回発生して少しウザイ。

また、MEDIA_ROOT内の特定のフォルダを相対パスで指定してglobでトラバースした結果が空になるという動作には、本当にまいった(MEDIA_ROOTを使って絶対パスを使用すれば問題ない)。これで5時間ハマった。
まあ、これは画像もModel化してDBへ保存しろという神の思し召しかもしれない。

いろいろ書いたが、Django固有のAPIさえ頭に入れれば、快適快適。もう少し早く使い始めたかったと後悔しているくらいだ。