これはOSの環境変数とは異なるもの。shellipython入れると履歴とか管理してくれるから楽。回避できない警告が毎回出てくる。1.7等の標準settings.pyには既に準備がある。(CSRF)標準ではDjangoはCSRF対策を有効にしている。bootstrapを既存のプロジェクトに導入する例としてmysiteという名前のプロジェクトを考える。状況は以下を仮定する。プロジェクトが置かれている。簡単なviews.py等がある。指定されているこのmysiteプロジェクトにbootstrapを新たに導入したいここでは外部サーバに依存しない設定を考えるつまりhref="//netdna.bootstrapcdn.com/bootstrap/3.0.0/css/bootstrap.min.css"などとは指定しないbootstrap自体の詳細な利用方法はこの説明の範囲外とする。両方共静的ファイルを持つ。mysiteはbootstrapのファイル郡をどこかに用意しなければならない。これらの静的ファイルを一箇所に集めるための設定をする。ディレクトリ配下にbootstrap/を置けば良い。次に、集めたファイルを置くディレクトリをsettings.STATIC_ROOTに記述する。現在のユーザから書き込め、Apacheから読み込み可能である必要がある。関連する全ての静的ファイルが集約されているのを確認すること。最後に集約された静的ファイルをApacheが外部に公開する際のURLをsettings.STATIC_URLに記述する。記述した時に接頭辞になる。Apacheの設定ファイルに記述する。(これはApacheの関連する設定として記述すること。cssが読めることを確認する。これで外部への静的ファイルの公開は終わった。後はテンプレートの内部で実際に通常のHTMLの一部として記述し、cssやjsが利用できることを確認する。参考1.4と1.5で内容が大幅に違う。使ってる仕組みは割と同じなのに。https://docs.djangoproject.com/en/1.4/howto/static-files/https://docs.djangoproject.com/en/1.5/howto/static-files/自分的な課題この方式だとdjangoの認証・認可後に静的ファイルを提供する方法がない。innodb)のレベルでREPEATED-READになっていないか確認する。参考djceleryはMySQLを利用している。結果がある意味キャッシュされたかのような挙動を引き起こす。flushresetは古いコマンド。使って管理したいとする。デフォルトが大変古いため別件絡みで変更した。仮想環境があると仮定する。djceleryはDjangoのパスを通してceleryのネイティブコマンドを使うモジュール。workerを生み出すコマンドでデーモンではない。workerが本当の意味でdaemonsupervisorなしでpsすると分かる。supervisorで自分で作る必要がある。models.DateTimeField(auto_now=True)と新たにEntryというモデルを書いたとする。them.と、怒られる。Entryここでmigrations/0001_initial.pyが自動生成される。