DjangoやKayを使って新しいアプリを作る方法の自分用メモ

何事も始める時が一番腰が重いものであり、腰を軽くするためには考えずに作業出来る必要があり、その為には手順を記録してなんども修正して洗練させる必要がある、だからとりあえず記録。DjangoやKayを使ってウェブアプリを作る方法

サービス名称を決める
  • 他人に話してみる。「ダサッ」とか「え、何々って意味？(誤解)」とか言われたら考え直す。
  • ドメインが取れるかどうかを調べる。Google App Engineならその名前のアプリを作れるか調べる。取れないなら考えなおす。
  • ドメインを取る。アプリの名前をとる。作ってから取れなくなってたらガッカリするから。
プロジェクトフォルダを作る

僕はBitbucketでホスティングされているプライベートのMercurialのリポジトリの中に作る。

フォルダの中でstartprojectする

RATIONALE: ここで作られるフォルダのルートにはapp.yaml, settings.pyなどのファイルが複数おかれて散らかるし、それらのファイルとそのプロジェクトの「ウェブアプリではない何か」とが混在しておかれるのはややこしいから。いずれGAEにアップロードする必要のない資料とか画像とかスクリプトとかができてくるから。

startapp coreする

RATIONALE: appが単一である時の「適当な名前」は以前までmainにしてたが、これはmanage.pyと2文字目まで同一なのでcdなどで移動するときにmai[TAB]の4文字打たなければ行けない。coreならc[TAB]でいい。

hg addとhg commitをする

RATIONALE: この後の操作でファイルのコピー位置を間違えることがある

app.yamlを書き換え

applicationとversionあたりを。後でstaticを使うならついでに:

- url: /static
  static_dir: static
  expiration: 3000d
settings.pyを書き換え

特にINSTALLED_APPSとAPP_MOUNT_POINTSとSECRET_KEYを。APP_MOUNT_POINTSを指定し忘れて404とかなったりする。authやsessionを使う予定があるなら今のうちにやっとく。

INSTALLED_APPS = (
  'kay.sessions',
  'kay.auth',
  "core",
)

APP_MOUNT_POINTS = {
    "core": "/"
}

MIDDLEWARE_CLASSES = (
  'kay.sessions.middleware.SessionMiddleware',
  'kay.auth.middleware.AuthenticationMiddleware',
)

AUTH_USER_BACKEND = 'kay.auth.backends.datastore.DatastoreBackend'
AUTH_USER_MODEL = 'core.models.User'

AUTHにこの設定を入れたならmodels.pyにこれが必要

from kay.auth.models import DatastoreUser

class User(DatastoreUser):
    pass
GoogleAppEngineLauncherにドラッグドロップし、サーバを起動してブラウザで見えることを確認
staticフォルダを作ってYUI reset-font-gridとJQueryUIとを入れる

YUI Library、jQuery: The Write Less, Do More, JavaScript Library。Developer's Guide - Google AJAX Libraries API - Google Codeを使うという選択肢もあるみたい。

.hgignoreの無視リストにYUIとJQueryを入れる
Google Analyticsで新しいプロフィールを作る
template/_base.htmlを作る
  • 既存のアプリからコピーしてきてtemplate/_base.htmlを作る。
  • Google Analiticsのトラックコードを書き換える。
  • タイトルを書き換える
  • template/index.htmlを{% extends "core/_base.html" %}にする
  • R: テンプレートの継承ツリーは(何も継承しないテンプレート)→(_base: タイトル、Analitics、ヘッダなどの「見せるための準備」はあるが中身のないテンプレート)→(index: トップバナー、カラム、末尾の連絡先などの一揃いついたテンプレート)としてある。これはログイン情報の表示にiframeを使っていたときにCSSとかは同じようについているけどタイトルがないページが欲しくて作ったものなので、全部のページに同じようにヘッダとフッタがついてよければこれをする必要はないかも。
README.txtを作る

プロジェクトフォルダのルートにREADME.txtを置く。何を作ろうとしたのか、何をする必要があるか、などを書き連ねる。

  • R: とりあえずこれを書き連ねてない状態で中断して暫く間が開くと「何するつもりだったんだっけ…」となるので。
  • 実行可能なことは□(TODO)を前置する。終わったら■に書き換える。うっかり□を書いたものでも、実行不可能だと思ったら-に書き換える。「なになにはどう実装する？」はTODOじゃない。
データベース保存場所の変更

Macの場合、開発サーバのデータベース保存場所をプロジェクトフォルダの中に指定しておく。ランチャーのEdit-Application Settingsで--datastore_path=/...projdir.../database_projnameとか。

  • デフォルトだと/varの中に作られて、マシン再起動の時に消されるようなので。
作りたいところから作る。

まあ大体はmodel.pyを書かないとなにもできないわけだけど、今回は一番重要なブックマークレットから作り始めた。前回も冷静に考えるとコンテンツを作り出すスクリプトから作ったなぁ。

  • 未実装の部分には必ず raise NotImplementedErrorを書く。書かないで困るのは自分。
  • Emacsの話。modelsやviewsを書く際には、新しく作る方のmodels.pyを開いてから、別のアプリで作ったmodels.pyも開く。動的略語補完でdb.Iとかからdb.IntegerPropertyと補完されるので「db.IntegetPropertyと書いてしまってエラーになる」なんて時間のロスを防げる
CSS
def css(request):
  r = render_to_response(
    'core/style.css', dict())
  r.content_type = "text/css"
  return r
認証

認証は多少普通と違うからといって1から自分で作ろうとしたこともなんどもあったけど結局は既存の物に吸収されたので、今後はなるべく自分で作らない。

/admin

/adminをつくる。公開する前にちゃんと@admin_requiedすること。ad hocなコード(付け替えやなんかのキックなど)はここへ。そのうち肥大化してくるので別ファイルに切り出す。

utils.pyなど

欲しいページ、欲しい機能を実装していくとおそらくview.pyが真っ先に肥大化する。ある程度以上のサイズになると脳内でどこに何があったか思い出せなくなってくるのでかぶっているコードをどんどんくくりだして短くする。

tests.py

ページの種類が3枚以上になったあたりで「何かを修正した後に全部の機能をテストしてない」という状態になるからテストケースを書き始める。さもないと「新しい機能をつけてupdateしたんだが、ふと気がついたらわずか1行の修正が足りないせいでこっちの機能が壊れてるじゃん！」という自体が起きて心臓に悪い。

  • ローカルの開発環境で自分が操作して挙動を眺めているのは「手作業によるテスト」だと自覚すること。