世界を動かす技術を、日本語で。

Djangoの使い始めに関するいくつかのメモ

2026年1月28日原文(jvns.ca)

概要

  • Django を学び始めた体験のまとめ
  • Rails や他フレームワークとの比較
  • Djangoの強み (明示性・管理画面・ORMなど)の紹介
  • SQLiteの活用 や設定ファイルの悩みについても言及
  • 今後さらに Djangoの機能 を学ぶ意欲

Djangoを学び始めて感じたこと

  • 古くて枯れた技術 を学ぶ楽しさ ・20年以上使われている技術の安心感 ・過去の問題がすでに 解決済み で、すぐに作業できる利便性

  • Djangoを選んだ理由 ・RailsやLaravelにも興味があったが、DjangoでWebサイト作成を開始 ・数ヶ月使ってみて、 明示的で分かりやすい構造 に好印象

Railsとの比較:Djangoの「魔法の少なさ」

  • Rails は「魔法」が多く、久しぶりに触ると 構造を思い出すのが大変 ・例:routes.rbのresources :topicsだけではルートの詳細が分かりにくい ・Djangoは主要ファイルが明確で、プロジェクト放置後も 復帰しやすい

  • Djangoの主なファイル構成 ・urls.py, models.py, views.py, admin.py, tests.py ・HTMLテンプレートも 明示的に参照 されていて追いやすい

標準搭載の管理画面(Admin)

  • Djangoの管理画面 はデフォルトで強力 ・少しのコード追加で カスタマイズ可能 ・例:list_display, search_fields, orderingなどを簡単に設定

ORMの楽しさ

  • 以前は「SQL直書き派」だったが、 DjangoのORM が便利で楽しい ・__(ダブルアンダースコア)で JOINを表現 できる直感的な記法 ・複雑なクエリも 可読性が高く簡潔 ・パフォーマンスも問題なく、現状は ORMに満足

自動マイグレーション

  • models.py の変更に応じて 自動でマイグレーションファイル生成 ・生成されたスクリプトをそのまま使えて 運用が楽 ・データモデルの頻繁な変更にも 柔軟に対応

ドキュメントの質の高さ

  • これまで ドキュメントを読まない癖 があったが、Djangoの公式ドキュメントは 非常に分かりやすい ・Jacob Kaplan-Mossによるドキュメント文化の講演も存在 ・modelsのイントロなど、 必要な情報が整理されている

SQLiteの活用

  • Postgres運用でのトラブル経験から SQLite を選択 ・小規模サイトなら VACUUM INTO で簡単バックアップ ・DjangoでのSQLite運用方法も 公式手順 に従って問題なし ・1日数百件程度の書き込みなら 十分に実用的

バッテリー同梱主義(Batteries-included)

  • CSRF対策Content-Security-Policy、メール送信など 標準搭載 ・開発環境では メール送信をファイル保存 に切り替える設定も簡単 ・本番環境用のSMTP設定も 設定ファイル分割で管理

設定ファイル(settings.py)の悩み

  • settings.py はグローバル変数を手動で設定するため、 タイプミスが不安 ・例:WSGI_APPLICATOINと書いても エラーに気付きにくい ・Python言語サーバーによる 補完やエラー検出が効かず、やや不安

今後の展望

  • これまで 本格的なWebフレームワーク経験が少なかった ため、今後の学びに期待 ・Djangoの フォーム検証や認証機能 など、まだ未学習の部分が多い ・Marco Rogersに ORMの良さを教えてもらったことに感謝 ・今後も Djangoの新機能や活用法 を探求していく予定

コメント・フィードバック募集

  • Mastodon上で コメント受付中 ・「あなたのお気に入りのDjango機能」をぜひ教えてほしい

Hackerたちの意見

プロジェクトにはいつもDjangoに戻っちゃうんだ。めっちゃ素晴らしいよ。付属してる機能が十分にあって、すごくパワフルなんだ。

Djangoは、ウェブアプリケーション開発において、俺が今まで触ってきた中で最も生産的な「退屈な技術」だと思う。毎回のリリースで派手な機能を追加するわけじゃないけど、安定性を保っていて、過去のバージョンとの互換性もちゃんとあるんだよね。

Djangoの話は置いといて、これはすごく大事なポイントだと思う。プロジェクトを数ヶ月や数年放置して、また戻ってこれるっていうのは、俺にとってすごく重要なんだ(これが俺のプロジェクトのやり方!)。趣味でやる場合は特にそうだけど、大きな環境でも、XYZの仕組みを理解してる人を常に確保するコストがあるし、新しい人を育てるのも大変だよね。俺も、過去の自分とのやり取りが、良い習慣を学ぶのに役立ってるって感じてる。これが仕事にもプラスになってるんだ。

これが、私が個人プロジェクトに自動テスト(CIで実行するように設定)とちゃんとしたドキュメントを確保することにめちゃくちゃ厳格な理由なんだ。時間が経ってほとんど忘れちゃったときに、また取り組むのがすごく楽になるからね。

「冷血ソフトウェア」っていう表現、めっちゃいいね。https://dubroy.com/blog/cold-blooded-software/ (HN: https://news.ycombinator.com/item?id=46488261)

だから、私は小さな使い捨てプロジェクト以外は、正式な要件文書を書くようにしてるんだ。18ヶ月前に何を考えてたかを知るのがずっと楽になるから、当時の考えを書き留めておくのが大事だよ。

VACUUM INTOを使ってバックアップできるのが好きだし、その結果できたファイルをコピーするだけで済むんだ。素直に考えると、sqliteファイルをそのままコピーしちゃうかも。これって悪いアイデア?

VACUUM INTOコマンドについては、sqliteデータベースのバックアップ方法に関するガイドで学んだよ: https://litestream.io/alternatives/cron/

SQLiteが動いてないならそれでいいけど、ファイルが書き込み中のときにコピーすると破損のリスクがあるよ。VACUUM INTOを使うと、そのリスクがなくなるんだ。

DjangoのORMやマイグレーションは、幸福度の面でまだまだ無敵だね。

こんなに長い間経っても、Djangoみたいなマイグレーションがどの言語にもないのが信じられない。見た目はすごくシンプルでパワフルなのに、自動生成するには何か複雑なことがあるんだろうな。ElixirやRustに行ったとき、マイグレーションの話がもっと複雑で手動だったのには驚いたよ。ただモデルを変えてマイグレーションを生成してコミットするだけなのにね。LLMが普及する前は、ectoファイルを書いてたけど、Djangoに比べて大きなデータベース構造を定義するのがすごく繰り返し作業だった。

自動マイグレーションには本当にビビる。ElixirやEctoみたいにスキーマやマイグレーションを自分で書く方が好きだな。それに、同じテーブルに対して2つの異なるスキーマを持つオプションがあるのもいい(使わないけど)。

Hacker Newsで議論の続きを見る