Jamz

BlogD って何 ? とか言われそうですが、Blog を使い始めたとき (2003/2004年頃) に自作のブログツールを作りたいなぁと思って取得したドメインが blogd.org

Linux のデーモンって xxd (e.g. httpd, vsftpd) と名称の最後に d をつけることが多いでしょ ? そこから blog のデーモンみたいなもの、ってことで blogd

なんとなく見た目を変えて BlogD

読み方は「ブロッディー」

さて、前回に続き、Django 初心者 (Python も初心者) がアプリケーションを開発していく過程で気づいたことや、つまずいたことをメモしていきたいと思います。

[J] BlogD ができるまで - Django でアプリケーション開発 その1 - Jamz (Tech)

なんとか二回目にこぎ着けた。

なにから考えれば (設計すれば) いいの ?

そもそも Django などのフレームワークを作って開発する時点で「こんなツールを作りたい」というのは描いているはず。

正しいアプローチなのかは分からないけど、私の場合、そのアプリケーションを実装するにあたり必要なモデル (データ、DB のテーブル) って何 ? というところから入る。

まぁ、これ (マインドマップ) だとなんだかちょっとよく分からないと思いますが、ER図なんかを使って考えるのが適当なんでしょうかね。

[J] WWW SQL Designer 2.1.1 の日本語化 - Jamz (Tech)

っで、ある程度モデルの想像がついてきたら、前回投稿のアプリケーションの分割部分をどうするかを考える。

[J] BlogD ができるまで - Django でアプリケーション開発 その1 - Jamz (Tech)

view の部分も考えないといけないんだけど、いろいろと実装始めると model がないことには前に進めない、開発が進まないので、モデルの定義から入っている。

なのでモデルドリブンな開発アプローチなんだけど、これって正しいのかな ?

settings.py

さて、モデルのコーディングを始めるわけですが、その前に settings.py の最低限の定義を済ませておきます。

リファレンスは後で紹介しますが、まずは以下のあたりを編集。

1. BASE_DIR の定義
2. TIME_ZONE = 'Asia/Tokyo'
3. LANGUAGE_CODE = 'ja'
4. MEDIA_ROOT = os.path.join(BASE_DIR, 'media_dir_name')
5. MEDIA_URL = 'media_dir_name'
6. ROOT_URLCONF = 'project_name.urls'

1 はスタンダードってわけじゃないようですが、慣習的にそうしておくと便利ということで。

import os
BASE_DIR = os.path.dirname(os.path.abspath(__file__))

2 の TIME_ZONE の定義は Japan/Tokyo と書いちゃいそうですが、Asia/Tokyo だそうです。

3 の LANGUAGE_CODE = 'ja' も ja_JP とか書いちゃいそうですが、RFC 的に ja_JP というのはないらしい。

• Django アプリケーションの国際化 - django-ja | Google グループ
• Using Language Identifiers (RFC 3066)

4, 5 あたりは好きなように。

強いて言うなら、django.contrib.admin で使う場合の media とうまくすみ分け ? できるよう気をつける。

っつか、admin の media を有効にする場合に適当な方法ってなんだろう。

以前は、site-package/django の中から該当するディレクトリをシンボリックリンクさせて httpd.conf とかで alias してた。

manage.py runserver したときは勝手にうまくいってるけど、これって Django の開発サーバーがうまいこと処理してくれているだけだよね ?

6 の urls.py は、django-admin で生成したプロジェクトの名称 (ルートのディレクトリ名) と同期しているので開発開始後にプロジェクトのディレクトリ名を変更した時なんかは要注意。

上記意外には、settings.py の分割なんかも知っておくとよいかも。

Django Settings.py

テスト環境がsqlite3で本番がMySQLのように変更する必要がある場合は、異なる部分だけを設定したcustom_settings.pyなどのファイルを用意して

(snip)

perezvonさんの使っている本環境のsettings.pyをdevelopment.pyなどのように名前を変えた開発環境用の設定ファイルで異なる部分だけ上書きするテクニックはより有効だと思います。

UeblogWiki

上記についてはどちらも有効だと思う。使う際のタイミングや用途が微妙に異なる気もするなぁ。

再配布を想定する場合は、上書きできるように local_settings.py などがあると便利だろうし、開発時はことあるごとに編集することがあるだろうから、settings.py をまるまるコピーして python manage.py --settings=dev_setting.py runserver しちゃう方が良さそうな気がする。

その 3 に続く

django.contrib.admin の扱い (使い方) が、古いバージョンの頃とだいぶ変わっているので、次回は admin について書こうかなぁ。