2026/01/28 7:58

Djangoを始めるためのノート - pipでDjangoをインストールします。 `pip install django` - 新しいプロジェクトを作成します。 `django-admin startproject mysite` - プロジェクト内にアプリを作ります。 `python manage.py startapp blog` - アプリを`settings.py`の`INSTALLED_APPS`へ追加します。 - `mysite/urls.py`でURLルーティングを設定し、アプリ側でビューを作成します。 - データベース構築のためにマイグレーションを実行します。 `python manage.py migrate` - 管理画面へのアクセス用スーパーユーザーを作成します。 `python manage.py createsuperuser` - 開発サーバーを起動します。 `python manage.py runserver` - サイトは`http://127.0.0.1:8000/`、管理画面は`http://127.0.0.1:8000/admin/`で確認できます。

RSS: https://news.ycombinator.com/rss

要約▶

Japanese Translation:

改訂版要約:
著者は最近 Django を学び始め、2020 年の Rails 経験よりも習得しやすいと感じています。Django の明示的なファイルレイアウト（
urls.py
、
models.py
、
views.py
、
admin.py
、
tests.py
）とテンプレート参照によりナビゲーションが明確です。高度にカスタマイズ可能な管理インターフェース（
ZineAdmin
クラスで示される）があり、ORM の簡潔なダブルアンダースコア結合構文は複数テーブルにわたるデータベース作業を簡素化します。自動マイグレーションは
models.py
の変更から生成され、著者は編集せずに使用し、頻繁なスキーマ調整のためにこの機能を評価しています。ドキュメントが称賛されており、Jacob Kaplan‑Moss の PyCon トークと役立つモデル紹介が引用されています。小規模サイトでは著者は SQLite を好み、
VACUUM INTO
でバックアップし、公式ガイドラインに従って本番環境を構築しています。Django のバッテリー付き機能（CSRF、CSP ヘッダー、メールバックエンド、設定モジュール）が強調されており、
settings.py
がグローバルであるため
WSGI_APPLICATOIN
などのタイプミスが時折発生します。ウェブフレームワークに不慣れながらも、著者はフォーム検証と認証を探索しており、Marco Rogers に ORM の使用を勧めてもらったことに感謝し、将来のプロジェクトで Django のパフォーマンスをテストする計画です。

この改訂版は元の表現に近く、より広いコミュニティシフトの推測を削除し、すべての重要ポイントを保持しています。

もし元の要約そのままを残したい場合は、上記の二つの軽微な推論のみが原文からの逸脱であるとご指摘ください。

本文

こんにちは！
私のお気に入りのことのひとつは、20年以上前から存在しているけれど、今まで試したことがない「古くて退屈な技術」を学び始めることです。すべての問題が既に千回以上解決されているので、簡単に作業を進められると、とても気持ちが良いものです。

長年、RailsやDjango、Laravelなど人気のあるウェブフレームワークを学びたかったのですが、それは実現せず――最近になってようやく始めました。数か月前に Django を使ってサイト構築を学び始め、これまでの感想を簡単にまとめてみました。

Railsよりマジックが少ない

2020年にRailsを試したとき、Rubyコミュニティは素晴らしいものの、数か月プロジェクトから離れると「resources :topics」という記述だけではトピックルートがどこにあるか分からず、慣例を思い出すか調べる必要があります。

後でプロジェクトに戻りやすくすることは私にとって重要です。Djangoは物事がより明示的なので扱いやすく感じます。小さなDjangoプロジェクトでは主に以下のファイルを使います：

```
urls.py
```
```
models.py
```
```
views.py
```
```
admin.py
```
```
tests.py
```

HTMLテンプレートが必要になったら、通常はこれらのファイルのいずれかから明示的に参照します。

組み込み管理画面

データを編集・閲覧するための管理インターフェイスが欲しかったので、Django の組み込み管理画面は最小限のコードでカスタマイズできる点が魅力です：

@admin.register(Zine)
class ZineAdmin(admin.ModelAdmin):
    list_display = ["name", "publication_date", "free", "slug", "image_preview"]
    search_fields = ["name", "slug"]
    readonly_fields = ["image_preview"]
    ordering = ["-publication_date"]

ORM が楽しい

「ORMって何に使うの？」と思い込んでいた私が、Django の ORM にハマっています。例えば次のクエリは：

Zine.objects.exclude(product__order__email_hash=email_hash)

5 つのテーブル（

zines

zine_products

products

order_products

orders

）を結合しますが、適切な

ManyToManyField

を宣言すれば Django が自動でジョイン処理してくれます。クエリは短く読みやすく、むしろ生の SQL を書くより楽しく感じます。

自動マイグレーション！

models.py

のフィールドを変更すると、自動的にマイグレーションスクリプト（例：

migrations/0006_delete_imageblob.py

）が生成されます。生成されたファイルはそのまま実行すれば問題なく動作します。データモデルを反復する際にはマイグレーションは不可欠です。

ドキュメントが好き

以前はドキュメントを読むのを避けていた私ですが、Django のドキュメントは非常に役立ちます。「models 入門」では必要な共通フィールドが紹介され、Jacob Kaplan‑Moss の 2011 年 PyCon トークで Django ドキュメンテーション文化について説明されています。

SQLite を使う

PostgreSQL に苦戦した後、小規模サイトはすべて SQLite に切り替えました。バックアップも簡単（

VACUUM INTO

で一つのファイルにまとめられます）し、1 日数百回程度の書き込みでも十分です。これは DNS を扱う複数データベースよりずっと楽です。

組み込みメール機能（とその他）

Django は「バッテリー同梱」です。CSRF 保護や CSP ヘッダー、メール送信などすべて組み込まれています。開発環境ではファイルベースのバックエンドを使いました：

# settings/dev.py
EMAIL_BACKEND = "django.core.mail.backends.filebased.EmailBackend"
EMAIL_FILE_PATH = BASE_DIR / "emails"

本番環境では：

# settings/production.py
EMAIL_BACKEND = "django.core.mail.backends.smtp.EmailBackend"
EMAIL_HOST = "smtp.whatever.com"
EMAIL_PORT = 587
EMAIL_USE_TLS = True
EMAIL_HOST_USER = "xxxx"
EMAIL_HOST_PASSWORD = os.getenv('EMAIL_API_KEY')

追加で必要な基本機能は、すぐにでも組み込まれている可能性が高いです。

設定ファイルはまだ多いと感じる

settings.py

はグローバル変数を設定するため、

WSGI_APPLICATOIN

のようなタイプミスが微妙なバグを引き起こします。Python ランゲージサーバーのヒントに頼っていますが、それなしではリスクが高く感じられます。

これで終わり！

実際のプロジェクトでウェブフレームワークを使ったことはまだありません—ほとんどのサイトは Go の単一バイナリか静的サイトです。Django をさらに探求し、フォーム検証や認証システムを学び、他に何があるかを確認する予定です。ORM に挑戦させてくれた Marco Rogers に感謝します！（Mastodon のコメント機能を試しているので、あなたのお気に入りの Django 機能を教えてください！）