akiyoko blog

akiyoko の IT技術系ブログです

Django 5.0 で削除された「USE_L10N」とは何だったのか? そして今後はどうなるのか?

この投稿は 「Djangoのカレンダー | Advent Calendar 2023 - Qiita」 15日目の記事です。

小ネタです。


Django 5.0 で「USE_L10N」が削除されました。

https://docs.djangoproject.com/ja/5.0/releases/5.0/#features-removed-in-5-0 より



そもそも Django には「USE_I18N 」と「USE_L10N」という設定があり、その変数名からそれぞれが「国際化 (internationalization) 」と「ローカル化 (localization) 」に対応するかと思いきや、Django においては、「USE_I18N 」は言語設定に合わせたテキストの多言語対応、「USE_L10N」は言語設定に合わせた日時や数字のフォーマット対応を扱います。 これらの変数の微妙なネーミングには歴史的な経緯があるとのこと。

国際化 (internationalization)
ソフトウェアをローカル化に備えさせることです。通常、開発者によって行われます。
ローカル化 (localization)
翻訳およびローカルな表示形式を記述することです。通常、翻訳者によって行われます。


Translation is controlled by the USE_I18N setting. However, it involves internationalization and localization. The name of the setting is an unfortunate result of Django's history.
(翻訳はUSE_I18N設定によって制御されます。しかし、これは国際化とローカライゼーションに関わります。この設定の名前は Django の歴史が生んだ不幸な結果です。)


https://docs.djangoproject.com/ja/5.0/topics/i18n/ より



なお、多言語対応については、芝田さんの「実践Django Pythonによる本格Webアプリケーション開発」に詳しく書かれているのでぜひどうぞ。

あとは、公式ドキュメントの 翻訳 | Django ドキュメント | Django あたりをご参照ください。




本題に入ります。

Django 4.2 まで使われている「USE_L10N」は、先に述べた通り、言語設定に合わせた日時や数字の表示形式を扱うための設定です。

もっと具体的に言えば、主にテンプレートに変数を表示する際、変数が数値型・日時型・日付型・時刻型の場合に、「USE_L10N」と「LANGUAGE_CODE」の設定内容にしたがったフォーマット変換をしてくれる設定 ということになります。


もちろん、管理サイトのモデル一覧画面などの表示にも適用されます。




Django 4.2 以前は、「USE_L10N」は次のように動作します。

「USE_L10N」が False の場合、設定ファイルの「DATETIME_FORMAT」や「DATE_FORMAT」のフォーマットに変換される(設定が無ければ、global_settings.py のデフォルトのフォーマットに従って変換される)。


「USE_L10N」が True の場合、(設定ファイルや global_settings.py のフォーマット設定に関係なく)「LANGUAGE_CODE」で指定した言語ごとのフォーマットに変換される。


「LANGUAGE_CODE」で指定した言語ごとのフォーマットというのは、「conf/locale/ja/」のようにロケールごとに置かれた「formats.py」に書かれたフォーマットを指します。例えば、日本語の場合は次に示す formats.py がデフォルトで用意されています。

django/conf/locale/ja/formats.py

# This file is distributed under the same license as the Django package.
#
# The *_FORMAT strings use the Django date format syntax,
# see https://docs.djangoproject.com/en/dev/ref/templates/builtins/#date
DATE_FORMAT = "Y年n月j日"
TIME_FORMAT = "G:i"
DATETIME_FORMAT = "Y年n月j日G:i"
YEAR_MONTH_FORMAT = "Y年n月"
MONTH_DAY_FORMAT = "n月j日"
SHORT_DATE_FORMAT = "Y/m/d"
SHORT_DATETIME_FORMAT = "Y/m/d G:i"
# FIRST_DAY_OF_WEEK =

# The *_INPUT_FORMATS strings use the Python strftime format syntax,
# see https://docs.python.org/library/datetime.html#strftime-strptime-behavior
# DATE_INPUT_FORMATS =
# TIME_INPUT_FORMATS =
# DATETIME_INPUT_FORMATS =
DECIMAL_SEPARATOR = "."
THOUSAND_SEPARATOR = ","
NUMBER_GROUPING = 3


Django 5.0 以降で「USE_L10N」が削除されますが、言語設定に合わせて日時や数字の表示フォーマットを変更できなくなるわけではありません。「USE_L10N」が常に True 扱いになったと考えればよいだけです。 ご安心ください。


Django 5.0 以降で日時や数字の表示フォーマットをデフォルトのものから変更するには、Django 4.2 以前と同じように「FORMAT_MODULE_PATH」*1 を使って、言語に合わせた formats.py のフォーマット設定を書き換えてあげればよいです。


(ディレクトリ構成例)

.
|-- conf
|   |-- __init__.py
|   `-- locale
|       |-- __init__.py
|       `-- ja
|           |-- __init__.py
|           `-- formats.py
|-- config
|   |-- __init__.py
|   |-- asgi.py
|   |-- settings.py
|   |-- test.py
|   |-- urls.py
|   |-- views.py
|   `-- wsgi.py
・
・


config/settings.py

LANGUAGE_CODE = 'ja'

FORMAT_MODULE_PATH = 'conf.locale'

(Django 5.0 以降では「USE_L10N」の設定は不要です。むしろ、設定してもまったく意味がありません。)


conf/locale/ja/formats.py

DATE_FORMAT = 'Y-m-d'
DATETIME_FORMAT = 'Y-m-d H:i'


現場ではどんな Django パッケージがどれくらい使われているのか(Django パッケージ利用実態調査:2022年12月)

この投稿は 「Django Advent Calendar 2022」 23日目の記事です。


ふと、「実際の現場ではどんな Django パッケージがどれくらい使われているの?🤔」 という疑問が湧いてきたので、自分で次のようなアンケートを採ってみることにしました。


docs.google.com



本記事では、この利用実態調査アンケートの結果発表に加えて、ちょっとした分析をしてみたいと思います。なお、本アンケートには40人の方から回答をいただくことができました。皆さま、ご協力ありがとうございました。





 

Q1.回答者の Django 経験年数

Q1.Django の経験はどのくらいですか?

  • 経験なし
  • 1年未満
  • 1〜3年くらい
  • 3〜5年くらい
  • 5年以上


回答者の Django 経験年数の分布は次のようになりました。



一番多かったグループは「1〜3年くらい」で 40%でした。なお、「1年未満」の階級値を「0.5」、「1〜3年くらい」を「2」、「3〜5年くらい」を「4」、「5年以上」を「7.5」として計算した 回答者の Django 経験年数の平均は 3.8 年 でした。



 

Q2.Django パッケージ利用状況

代表的な Django パッケージ 35個について、それぞれの利用状況を「聞いたことがない」「聞いたことはあるが使ったことはない」「試しに使ったことがある」「現場で使っている(過去に使っていた)」の4択でアンケートしました。

パッケージの選定にあたっては、毎年数千名が参加する Django 開発者向けアンケート「2022 Django Developers Survey」の「お気に入りのサードパーティ Django パッケージは?」という質問の選択肢をそのまま利用しました。*1

Q2.次の Django パッケージをそれぞれどのくらい利用していますか?

  • 1: 聞いたことがない
  • 2: 聞いたことはあるが実際に使ったことはない
  • 3: 試しに使ったことがある
  • 4: 現場で使っている(過去に使っていた)

Django パッケージの選択肢


回答結果を 4 > 3 > 2 > 1 の優先順に並べ替えた利用度ランキングがこちらになります。






3人に2人が現場で使っているという「djangorestframework」(DRF)がダントツの1位でした。 「試しに使ったことがある」を足し合わせると95%というのも衝撃の結果ですよね。「django-cors-headers」の利用度も高いことから、現場で DRF を使って API 開発をしている方が多いことが伺えます。

次点の 「django-debug-toolbar」は2人に1人くらいが現場で使っているという結果になりました。 私は開発時にはどのプロジェクトにも「django-debug-toolbar」と「django-extensions」はとりあえず入れるようにしていますが、そんな感じで「とりあえず生!🍺」みたいに使われているのかもしれません。*2


「4: 現場で使っている」「3: 試しに使ったことがある」「2: 聞いたことはある」を足し合わせたものを「認知度」とすると、認知度が高いほど、現場で使っている割合が全体的に高い傾向にありますが、認知度の割には現場で利用されていない(現場で使っていない割には認知度が高いとも解釈できる?)パッケージとして「django-allauth」「django-crispyforms」「django-channels」などが挙げられるでしょうか。



なお、「django-celery」は開発が長年停滞していて現時点で公式サポートされているバージョンの Django には対応していないようなのですが、今回のアンケートでは過去に現場で使っていたということで票が入ったのでしょう。*3




 

経験年数による変化

ここで Q1. とQ2. の結果を組み合わせて、少し考察をしてみたいと思います。

まず、経験年数のグループごとに「現場で使っている」と回答したパッケージ数の平均を比較してみます。




3〜5年くらいを境にして、利用しているパッケージの数が跳ね上がっている ように見えます。だいたい3年目くらいから複数の現場を経験するようになるということなのかもしれませんね。


次に、「Django 経験が長い人ほど利用度が高くなるパッケージはどれか?」を調べるために、経験年数とパッケージ利用度の相関を計算してみました。相関が高い Django パッケージランキングの上位5つを下に示します。


# Django パッケージ 相関係数
1 django-cors-headers 0.64
2 django-silk 0.60
3 django-extensions 0.57
4 django-channels 0.55
5 django-filter 0.54


これらはベテランならではのニーズに答えてくれるパッケージということなのでしょうか。まだこれらのパッケージを試したことがないという方は、ぜひチェックしてみてください。



 

PyPI ダウンロード数のランキングとの比較

The 10 Most-Used Django Packages | LearnDjango.com」という記事にインスパイアされ、PyPI のダウンロード数を元にした別角度での利用度ランキングを作成してみました。PyPI のダウンロード数は「Top PyPI Packages」というサービスから取得しました。




パッケージ名の右側のカッコ内の数字は先に示した「現場で使っている」ランキングの順位ですが、多少のブレはあるものの今回の結果と比較して違和感のない結果になっている印象です。

直近のダウンロード数を元にしていることで、プロジェクトがすでにアーカイブ済みになっている「django-rest-swagger」のダウンロード数が少なかったり、開発が長年停滞している「django-celery」などのパッケージがランキング外になっていたりするのは、まさに現時点での「利用実態」を表していると言えるでしょう。


 

GitHub スター数のランキングとの比較

次に、12/14 時点の GitHub スター数で並べた人気ランキングを見てみます。




同じく、カッコ内の数字は先に示した「現場で使っている」ランキングの順位ですが、(PyPI のダウンロード数ランキングと比べて)少し乖離が大きいような感じがします。

例えば、上位にランクインしている「Wagtail」は8年以上、「django-allauth」は12年以上も継続しているリポジトリということでスター数が多くなっている可能性がありますし、「django-channels」は Django の公式コミュニティが開発しているということで注目度が高いためにスター数が多くなっている可能性があります。また、現在のスター数は多いけれども実際はもう使われなくなってしまったリポジトリもあったりするので、実際の利用実態と乖離していることもあるでしょう。


ということで、パッケージを選定する際には、GitHub スター数を「人気度」として参考にしつつ、PyPI の直近のダウンロード数を「利用度」として判断材料にする のがよいのではないでしょうか。なお、実際の選定にあたっては次の点も留意するのがよいでしょう。

  • 開発が停滞していないか(直近の PyPI ダウンロード数である程度把握できる)
  • Issue が放置されていないか
  • 公式ドキュメントが充実していること
  • コントリビュータが数人以上いること(ぼっち開発は危険)



 

まとめ

独自のアンケートを採って、「実際の現場ではどんな Django パッケージがどれくらい使われているのか?」を調査しました。

「Q2.Django パッケージ利用状況」の結果のグラフを見ると、特異的に認知度が高いものがいくつかあったものの、全体的に、認知度が高いほど現場で利用されている度合いが高い傾向にあることが分かりました。結果としては、「djangorestframework」が認知度・利用度ともダントツのトップでした。

今回は、私が全然知らなかった Django パッケージも含めてアンケートをすることができたので、大変興味深く調査することができました。アンケートにご協力いただいた皆さま、誠にありがとうございました。改めて御礼申し上げます。



参考までに、アンケート結果の可視化に利用したコードは ↓ にアップしています。

github.com




 

(おまけ)ChatGPT による Django パッケージの説明

今回のアンケートの選択肢として挙げたそれぞれの Django パッケージの説明文を載せておきます。ちなみにこの説明文は、最近話題の「ChatGPT」の回答を使わせていただきました。ざっとチェックしましたが、しれっと大嘘をついている可能性があるかもしれませんのでご注意ください。

Django パッケージ 説明文
djangorestframework Django フレームワークで RESTful な Web API を作成するためのライブラリです。このライブラリを使用することで、Django アプリケーションを通じて RESTful な Web API を提供することができます。 djangorestframework には、API のエンドポイントやリクエストとレスポンスのシリアライザ、API の認証や権限管理など、RESTful な Web API を実装するための必要な機能がすべて提供されています。このライブラリを使用することで、Django アプリケーションから RESTful な Web API を提供することができるようになります。
django-debug-toolbar Django にて、開発時にデバッグを行うためのものです。このパッケージを使用することで、Django アプリケーションの開発時に、リクエストやレスポンスなどの詳細情報を表示することができます。
django-filter Django アプリケーションでクエリセットをフィルタリングするためのライブラリです。このライブラリを使用することで、クエリセットを簡単に様々な条件でフィルタリングし、特定の条件にマッチするデータのみを取得することができます。 django-filter を使用することで、データベースからデータを抽出する際に、より細かいフィルタリングを行うことができるため、データをより正確かつ効率的に取得することができます。
django-storages Django フレームワークでさまざまなクラウドストレージサービスを使用するためのライブラリです。このライブラリを使用することで、Django アプリケーションで Amazon S3 や Google Cloud Storage などのクラウドストレージサービスを簡単に使用することができます。 django-storages を使用することで、Django アプリケーションで保存されるデータや画像などのファイルをクラウドストレージ上に保存することができます。これにより、アプリケーションのデータを安全かつスケーラブルな方法で保存することができるようになります。
django-cors-headers Django にて、クロスオリジンリソースシェアリング(CORS)を扱うためのものです。CORS は、異なるオリジン(ドメイン)間での Web ページのやり取りを許可する仕組みです。
django-extensions Django フレームワークのためのサポートライブラリです。このライブラリには、Django アプリケーションを開発するためのさまざまな便利な機能が含まれています。例えば、コマンドラインから Django プロジェクトを作成するためのツール、データベースのスキーマを表示するためのツール、データベースのデータをダンプするためのツールなどがあります。このライブラリを使用することで、Django アプリケーションの開発プロセスをよりスムーズかつ効率的に行うことができます。
django-environ Django アプリケーションで環境変数を簡単に使用できるようにするためのライブラリです。このライブラリを使用することで、アプリケーションの設定値を環境変数から取得することができます。これにより、アプリケーションの設定値を外部から安全かつ簡単に管理することができます。
pytest-django Python のテストフレームワークである pytest を用いて Django Web アプリケーションのテストを実行するためのプラグインです。このプラグインを使うことで、Django アプリケーションのテストを簡単に実行し、結果を比較することができます。また、pytest-django は、Django アプリケーションのデータベースを自動的にセットアップ・クリーンアップするため、データベースのテストも容易に行うことができます。
django-import-export Djangoフレームワークでのデータのインポートおよびエクスポートを簡単に行うためのライブラリです。このライブラリを使用することで、Djangoのモデルデータを様々な形式のファイル(CSV、JSON、Excelなど)とやりとりすることができます。django-import-export を使用することで、データのインポートおよびエクスポート操作を管理画面から直接実行することができます。
django-allauth Django にて、多要素認証を提供するためのものです。このパッケージを使用することで、Django アプリケーションで簡単に多要素認証を実装することができます。また、django-allauth は Django のログイン認証システムを拡張しており、既存の Django アプリケーションでも簡単に導入することができます。また、django-allauth は様々な外部サービス(Facebook、Google、Twitter など)との連携もサポートしています。
djangorestframework-simplejwt django-rest-framework を使用した RESTful な Web API にJSON Web Tokens(JWT)を使用した認証を実装するためのライブラリです。JWT は、トークンベースの認証方式の一種です。djangorestframework-simplejwt を使用することで、django-rest-framework で作成した RESTful な Web API に JWT を使用した認証を実装することができます。これにより、API を利用するアプリケーションがAPIに対してアクセスする際に、トークンを使用して認証を行うことができるようになります。
django-redis Django フレームワークで Redis を使用するためのライブラリです。Redis は、速度が非常に速いキー/値型のデータベースです。django-redis を使用することで、Django アプリケーションで Redis を使用してデータを保存することができます。これにより、Djangoアプリケーションのデータ保存や取得が高速化されます。また、django-redis は、Django のキャッシュフレームワークと組み合わせて使用することで、アプリケーションのパフォーマンスをさらに向上させることができます。
django-celery Web フレームワークである Django と、Python のタスク駆動フレームワークである Celery を組み合わせるためのものです。このパッケージを使用することで、Django アプリケーション内で Celery を利用して、非同期タスクを管理することができます。
dj-database-url Django を使用したアプリケーションで、データベースの接続文字列を簡単に扱うためのライブラリです。このライブラリを使うことで、データベースの接続情報を環境変数や設定ファイルから読み取り、Django の設定に渡すことができます。その結果、Django アプリケーションのデプロイやテストを容易に行うことができるようになります。また、dj-database-url は、様々なデータベース管理システムをサポートしているため、どのようなデータベースを使用しているかに関係なく利用できます。
django-silk Django フレームワークでリクエストとレスポンスをモニタリングするためのライブラリです。このライブラリを使用することで、Djangoアプリケーションで発生するHTTPリクエストとレスポンスを管理画面から簡単に閲覧することができます。django-silkを使用することで、アプリケーションのパフォーマンスやエラーを把握することができるため、デバッグやトラブルシューティングがより容易に行えます。また、django-silkは、リクエストとレスポンスの中身を表示するだけでなく、リクエストを再現したり、リクエストやレスポンスを検索したりすることができます。
django-model-utils Django フレームワークでモデルを定義する際に便利なユーティリティクラスを提供するライブラリです。このライブラリを使用することで、モデルの作成やカスタマイズがより簡単かつ効率的に行えます。
django-crispyforms このパッケージを使用することで、Django アプリケーションで簡単にフォームを美しくレンダリングすることができます。また、django-crispy-forms は Bootstrap を使用したフォームのレンダリングをサポートしています。
django-rest-swagger Django フレームワークで作成された RESTful API に Swagger を組み込むためのライブラリです。Swagger は、RESTful API を文書化して公開するためのツールです。django-rest-swagger を使用することで、Django アプリケーションで作成した RESTful API を Swagger を使用して文書化することができます。これにより、API を使用する開発者が API の仕様や使用方法を簡単に理解することができるようになります。また、django-rest-swagger を使用することで、API のテストやモックを作成することができます。
dj-rest-auth Django の REST フレームワークである Django REST framework にて、ユーザー認証を提供するためのものです。このパッケージを使用することで、Django アプリケーションで簡単にユーザー認証を実装することができます。また、dj-rest-auth は Django のログイン認証システムを拡張しているため、既存の Django アプリケーションでも簡単に導入することができます。
Wagtail Wagtail は、Django フレームワークを使用した CMS(Content Management System)です。このCMSを使用することで、WebサイトやWebアプリケーションのコンテンツの管理をより簡単かつスムーズに行うことができます。 Wagtail には、ページやブログ記事の管理、メディアライブラリ、ページのテンプレートやカスタマイズ、検索、ユーザー管理などの機能が備わっています。これらの機能を使用することで、WebサイトやWebアプリケーションのコンテンツを効率的に管理することができます。また、Wagtail はオープンソースであるため、カスタマイズや拡張も容易に行うことができます。
django-compressor Django にて、JavaScript や CSS のファイルを圧縮するためのものです。このパッケージを使用することで、Django アプリケーションで簡単に JavaScript や CSS のファイルを圧縮することができます。
Djoser Django フレームワークで作成された RESTful な Web API にユーザー管理機能を実装するためのライブラリです。このライブラリを使用することで、Djangoアプリケーションにユーザー登録、ユーザー情報の管理、パスワードの変更などの機能を簡単に実装することができます。また、Djoser は、JSON Web Tokens(JWT)を使用した認証をサポートしているため、JWT を使用した API の認証も実装することができます。Djoser を使用することで、Django アプリケーションにRESTful な API を作成し、ユーザー管理や認証を実装することができるようになります。
django-channels Django にて、WebSocket や Server-Sent Events(SSE)を扱うためのものです。このパッケージを使用することで、Django アプリケーションで WebSocket や SSE を利用した通信を実装することができます。
django-celery-beat Django フレームワークと Celery というタスクキューライブラリを組み合わせて使用するためのツールを提供します。Celery は、バックグラウンドで処理を行うタスクを管理するためのライブラリです。django-celery-beat を使うことで、Django プロジェクトで Celery のスケジュール処理をより簡単に利用することができます。また、django-celery-beat には、Django のデータベースを使って Celery のスケジュールを管理するためのツールが提供されているため、Django プロジェクトで定期的なタスクを実行するためのインフラストラクチャを構築することができます。
django-taggit Django フレームワークでタグを扱うためのライブラリです。このライブラリを使用することで、Djangoアプリケーションでタグを作成したり、タグを付けられたオブジェクトを取得したりすることができます。django-taggit を使用することで、アプリケーションにタグ付け機能を簡単に実装することができます。また、django-taggit は、既存の Django モデルにタグを追加することもできます。これにより、タグを使用してデータを管理したり、検索したりすることができます。
model-bakery Django プロジェクトで使用されるモデルを生成するための Python パッケージです。model-bakery は、モデルを生成し、操作し、評価するためのツールを提供します。
django-dbbackup このパッケージを使用することで、Django アプリケーションで簡単にデータベースのバックアップを管理することができます。また、django-dbbackup は様々なクラウドストレージサービス(Amazon S3、Dropbox、Google Cloud Storage など)との連携もサポートしています。
pylint-django pylint-django は、Django フレームワークで作成された Python コードを検証するための Pylint プラグインです。Pylint は、Python のコード品質を測定するツールです。pylint-django を使用することで、Django フレームワークを使用した Python コードに対して、Pylint が提供する様々な品質指標を適用することができます。これにより、Django フレームワークを使用した Python コードの品質を向上させることができます。また、pylint-django は、Django フレームワーク固有の構文や API を理解しており、Django フレームワークを使用した Python コードをより正確かつ効率的に検証することができます。
django-braces Django にて、様々な拡張機能を提供するためのものです。このパッケージを使用することで、Django アプリケーションで簡単にビューやミックスインなどの拡張機能を実装することができます。また、django-braces は他の Django パッケージとも組み合わせて使用することができ、Django プロジェクトで様々な拡張機能を組み合わせることができます。
django-configurations Django にて、複数の環境に対応した設定を管理するためのものです。このパッケージを使用することで、Django アプリケーションで簡単に複数の環境(開発環境、本番環境、ステージング環境など)に対応した設定を管理することができます。
django-click Python の Webフレームワークである Django を使用したアプリケーションで、コマンドラインインターフェース(CLI)を簡単に構築するためのライブラリです。その結果、Django アプリケーションの管理や操作を、より便利でスムーズに行うことができるようになります。
django-test-plus Django フレームワークでのユニットテストを実行するためのライブラリです。このライブラリを使用することで、Django アプリケーションのユニットテストをより簡単かつ効率的に行うことができます。 django-test-plus には、ユニットテストを実行する際に便利なユーティリティ関数やアサーションが含まれています。例えば、ビューやURLのテストを行うためのヘルパー関数、フォームやモデルのテストを行うためのアサーションなどがあります。これらの機能を使用することで、Djangoアプリケーションのユニットテストをよりスムーズかつ効率的に実行することができます。
django-money Djangoフレームワークで組み込みの「Money」フィールドを提供するライブラリです。このライブラリを使用することで、データベース内での金額を貨幣単位を考慮した形で保存することができます。django-money を使用することで、金額を扱うアプリケーションを作成する際に、正確かつ柔軟な金額処理が行えるようになります。また、django-money は、様々な通貨をサポートしており、通貨の相互変換も可能です。
dj-rest-knox Django の REST フレームワークである Django REST framework にて、トークンベースの認証を提供するためのものです。このパッケージを使用することで、Django アプリケーションでトークンベースの認証を実装することができます。また、dj-rest-knox は Django REST framework の上に構築されており、Django のログイン認証システムを使用している場合は、すぐに使用することができます。
django-lifecycle Python の Web フレームワークである Django を使用したアプリケーションで、モデルの作成や更新時に実行される処理を定義するためのライブラリです。このライブラリを使うことで、Django のモデルを作成、更新する際に、特定の処理を自動的に実行することができます。例えば、モデルが作成されるときに、特定のメールを送信する処理や、モデルが更新されるときに、特定のログを記録する処理などを定義することができます。これにより、Django アプリケーションの動作をより自動化し、処理の追加や変更を容易に行うことができるようになります。


 

宣伝

Django の技術同人誌をこれまでに4冊出しました。開発のお供にどうぞ。



現場で使える Django の教科書《基礎編》

「現場で使える Django の教科書」シリーズ第1弾となる Django の技術同人誌。Django を現場で使うための基礎知識やベストプラクティスについて、初心者・初級者向けに解説した本です。B5・本文192ページ。Django 3.2 LTS に対応。


★ Amazon(電子版/ペーパーバック)


★ BOOTH(紙の本)



現場で使える Django の教科書《実践編》

《基礎編》の続編にあたる「現場で使える Django の教科書」シリーズの第2弾。認証まわり、ファイルアップロード、ユニットテスト、デプロイ、セキュリティ、高速化など、さらに実践的な内容に踏み込んでいます。現場で Django を本格的に活用したい、あるいはすでに活用している方にピッタリの一冊。B5・本文180ページ。


★ Amazon(電子版/ペーパーバック)


★ BOOTH(紙の本)※在庫なし



現場で使える Django REST Framework の教科書

Django で REST API を構築する際の鉄板ライブラリである「Django REST Framework」(通称「DRF」)にフォーカスした、「現場で使える Django の教科書」シリーズの第3弾。B5・本文228ページ。Django 3.2 LTS に対応。


★ Amazon(電子版/ペーパーバック)


★ BOOTH(紙の本)※在庫なし



現場で使える Django 管理サイトのつくり方

Django の管理サイト(Django Admin)だけに特化した、ニッチでオンリーワンな一冊。管理サイトをカスタマイズする前に絶対に読んでほしい本です。B5・本文152ページ。


★ Amazon(電子版)


★ BOOTH(紙の本)

*1:そもそもなぜこの35個が選ばれたのかというのは分かりませんでした。。orz

*2:私は飲めませんが。。

*3:Django 2.2 未対応 という致命的な問題があるため、「django-celery-results」や「django-celery-beat」が代替となっているようです。

Django パッケージ利用実態調査アンケート(2022年12月)について

この投稿は 「Calendar for Django | Advent Calendar 2022 - Qiita」 4日目の記事です。


Django Advent Calendar のネタ探しをしていて、ふと 「どんな Djangoパッケージがどれくらい使われているの?🤔」 という利用実態調査みたいな記事なら自分もぜひ読んでみたいと思ったので、アンケートを採ってみることにしました。


ということで、ぜひアンケートにご協力よろしくお願いします 🙇‍♂️🙇‍♂️🙇‍♂️(回答者の情報は収集していません)

docs.google.com



アンケートの回答〆切は 12/15 23:59 までとさせていただき、12/16 以降の Django Advent Calendar のどこかで発表する予定です。


なお、Q2. の Django パッケージの選択肢を以下に列挙しますが、これは 2022 Django Developers Survey というワールドワイドな Django 開発者向けアンケートの「お気に入りのサードパーティ Django パッケージは?」という質問の選択肢をそのまま利用しました(なぜこの選択肢になったのかは私にも分かりません)。


Django パッケージ 説明文
dj-database-url Django を使用したアプリケーションで、データベースの接続文字列を簡単に扱うためのライブラリです。このライブラリを使うことで、データベースの接続情報を環境変数や設定ファイルから読み取り、Django の設定に渡すことができます。その結果、Django アプリケーションのデプロイやテストを容易に行うことができるようになります。また、dj-database-url は、様々なデータベース管理システムをサポートしているため、どのようなデータベースを使用しているかに関係なく利用できます。
dj-rest-knox Django の REST フレームワークである Django REST framework にて、トークンベースの認証を提供するためのものです。このパッケージを使用することで、Django アプリケーションでトークンベースの認証を実装することができます。また、dj-rest-knox は Django REST framework の上に構築されており、Django のログイン認証システムを使用している場合は、すぐに使用することができます。
dj-rest-auth Django の REST フレームワークである Django REST framework にて、ユーザー認証を提供するためのものです。このパッケージを使用することで、Django アプリケーションで簡単にユーザー認証を実装することができます。また、dj-rest-auth は Django のログイン認証システムを拡張しているため、既存の Django アプリケーションでも簡単に導入することができます。
django-allauth Django にて、多要素認証を提供するためのものです。このパッケージを使用することで、Django アプリケーションで簡単に多要素認証を実装することができます。また、django-allauth は Django のログイン認証システムを拡張しており、既存の Django アプリケーションでも簡単に導入することができます。また、django-allauth は様々な外部サービス(Facebook、Google、Twitter など)との連携もサポートしています。
django-braces Django にて、様々な拡張機能を提供するためのものです。このパッケージを使用することで、Django アプリケーションで簡単にビューやミックスインなどの拡張機能を実装することができます。また、django-braces は他の Django パッケージとも組み合わせて使用することができ、Django プロジェクトで様々な拡張機能を組み合わせることができます。
django-celery Web フレームワークである Django と、Python のタスク駆動フレームワークである Celery を組み合わせるためのものです。このパッケージを使用することで、Django アプリケーション内で Celery を利用して、非同期タスクを管理することができます。
django-celery-beat Django フレームワークと Celery というタスクキューライブラリを組み合わせて使用するためのツールを提供します。Celery は、バックグラウンドで処理を行うタスクを管理するためのライブラリです。django-celery-beat を使うことで、Django プロジェクトで Celery のスケジュール処理をより簡単に利用することができます。また、django-celery-beat には、Django のデータベースを使って Celery のスケジュールを管理するためのツールが提供されているため、Django プロジェクトで定期的なタスクを実行するためのインフラストラクチャを構築することができます。
django-channels Django にて、WebSocket や Server-Sent Events(SSE)を扱うためのものです。このパッケージを使用することで、Django アプリケーションで WebSocket や SSE を利用した通信を実装することができます。
django-click Python の Webフレームワークである Django を使用したアプリケーションで、コマンドラインインターフェース(CLI)を簡単に構築するためのライブラリです。その結果、Django アプリケーションの管理や操作を、より便利でスムーズに行うことができるようになります。
django-compressor Django にて、JavaScript や CSS のファイルを圧縮するためのものです。このパッケージを使用することで、Django アプリケーションで簡単に JavaScript や CSS のファイルを圧縮することができます。
django-configurations Django にて、複数の環境に対応した設定を管理するためのものです。このパッケージを使用することで、Django アプリケーションで簡単に複数の環境(開発環境、本番環境、ステージング環境など)に対応した設定を管理することができます。
django-cors-headers Django にて、クロスオリジンリソースシェアリング(CORS)を扱うためのものです。CORS は、異なるオリジン(ドメイン)間での Web ページのやり取りを許可する仕組みです。
django-crispyforms このパッケージを使用することで、Django アプリケーションで簡単にフォームを美しくレンダリングすることができます。また、django-crispy-forms は Bootstrap を使用したフォームのレンダリングをサポートしています。
django-dbbackup このパッケージを使用することで、Django アプリケーションで簡単にデータベースのバックアップを管理することができます。また、django-dbbackup は様々なクラウドストレージサービス(Amazon S3、Dropbox、Google Cloud Storage など)との連携もサポートしています。
django-debug-toolbar Django にて、開発時にデバッグを行うためのものです。このパッケージを使用することで、Django アプリケーションの開発時に、リクエストやレスポンスなどの詳細情報を表示することができます。
django-environ Django アプリケーションで環境変数を簡単に使用できるようにするためのライブラリです。このライブラリを使用することで、アプリケーションの設定値を環境変数から取得することができます。これにより、アプリケーションの設定値を外部から安全かつ簡単に管理することができます。
django-extensions Django フレームワークのためのサポートライブラリです。このライブラリには、Django アプリケーションを開発するためのさまざまな便利な機能が含まれています。例えば、コマンドラインから Django プロジェクトを作成するためのツール、データベースのスキーマを表示するためのツール、データベースのデータをダンプするためのツールなどがあります。このライブラリを使用することで、Django アプリケーションの開発プロセスをよりスムーズかつ効率的に行うことができます。
django-filter Django アプリケーションでクエリセットをフィルタリングするためのライブラリです。このライブラリを使用することで、クエリセットを簡単に様々な条件でフィルタリングし、特定の条件にマッチするデータのみを取得することができます。 django-filter を使用することで、データベースからデータを抽出する際に、より細かいフィルタリングを行うことができるため、データをより正確かつ効率的に取得することができます。
django-import-export Djangoフレームワークでのデータのインポートおよびエクスポートを簡単に行うためのライブラリです。このライブラリを使用することで、Djangoのモデルデータを様々な形式のファイル(CSV、JSON、Excelなど)とやりとりすることができます。django-import-export を使用することで、データのインポートおよびエクスポート操作を管理画面から直接実行することができます。
django-lifecycle Python の Web フレームワークである Django を使用したアプリケーションで、モデルの作成や更新時に実行される処理を定義するためのライブラリです。このライブラリを使うことで、Django のモデルを作成、更新する際に、特定の処理を自動的に実行することができます。例えば、モデルが作成されるときに、特定のメールを送信する処理や、モデルが更新されるときに、特定のログを記録する処理などを定義することができます。これにより、Django アプリケーションの動作をより自動化し、処理の追加や変更を容易に行うことができるようになります。
django-model-utils Django フレームワークでモデルを定義する際に便利なユーティリティクラスを提供するライブラリです。このライブラリを使用することで、モデルの作成やカスタマイズがより簡単かつ効率的に行えます。
django-money Djangoフレームワークで組み込みの「Money」フィールドを提供するライブラリです。このライブラリを使用することで、データベース内での金額を貨幣単位を考慮した形で保存することができます。django-moneyを使用することで、金額を扱うアプリケーションを作成する際に、正確かつ柔軟な金額処理が行えるようになります。また、django-moneyは、様々な通貨をサポートしており、通貨の相互変換も可能です。
django-redis Django フレームワークで Redis を使用するためのライブラリです。Redis は、速度が非常に速いキー/値型のデータベースです。django-redis を使用することで、Django アプリケーションで Redis を使用してデータを保存することができます。これにより、Djangoアプリケーションのデータ保存や取得が高速化されます。また、django-redis は、Django のキャッシュフレームワークと組み合わせて使用することで、アプリケーションのパフォーマンスをさらに向上させることができます。
django-rest-swagger Django フレームワークで作成された RESTful API に Swagger を組み込むためのライブラリです。Swagger は、RESTful API を文書化して公開するためのツールです。django-rest-swagger を使用することで、Django アプリケーションで作成した RESTful API を Swagger を使用して文書化することができます。これにより、API を使用する開発者が API の仕様や使用方法を簡単に理解することができるようになります。また、django-rest-swagger を使用することで、API のテストやモックを作成することができます。
django-storages Django フレームワークでさまざまなクラウドストレージサービスを使用するためのライブラリです。このライブラリを使用することで、Django アプリケーションで Amazon S3 や Google Cloud Storage などのクラウドストレージサービスを簡単に使用することができます。 django-storages を使用することで、Django アプリケーションで保存されるデータや画像などのファイルをクラウドストレージ上に保存することができます。これにより、アプリケーションのデータを安全かつスケーラブルな方法で保存することができるようになります。
django-silk Django フレームワークでリクエストとレスポンスをモニタリングするためのライブラリです。このライブラリを使用することで、Djangoアプリケーションで発生するHTTPリクエストとレスポンスを管理画面から簡単に閲覧することができます。django-silkを使用することで、アプリケーションのパフォーマンスやエラーを把握することができるため、デバッグやトラブルシューティングがより容易に行えます。また、django-silkは、リクエストとレスポンスの中身を表示するだけでなく、リクエストを再現したり、リクエストやレスポンスを検索したりすることができます。
django-taggit Django フレームワークでタグを扱うためのライブラリです。このライブラリを使用することで、Djangoアプリケーションでタグを作成したり、タグを付けられたオブジェクトを取得したりすることができます。django-taggit を使用することで、アプリケーションにタグ付け機能を簡単に実装することができます。また、django-taggit は、既存の Django モデルにタグを追加することもできます。これにより、タグを使用してデータを管理したり、検索したりすることができます。
django-test-plus Django フレームワークでのユニットテストを実行するためのライブラリです。このライブラリを使用することで、Django アプリケーションのユニットテストをより簡単かつ効率的に行うことができます。 django-test-plus には、ユニットテストを実行する際に便利なユーティリティ関数やアサーションが含まれています。例えば、ビューやURLのテストを行うためのヘルパー関数、フォームやモデルのテストを行うためのアサーションなどがあります。これらの機能を使用することで、Djangoアプリケーションのユニットテストをよりスムーズかつ効率的に実行することができます。
djangorestframework Django フレームワークで RESTful な Web API を作成するためのライブラリです。このライブラリを使用することで、Django アプリケーションを通じて RESTful な Web API を提供することができます。 djangorestframework には、API のエンドポイントやリクエストとレスポンスのシリアライザ、API の認証や権限管理など、RESTful な Web API を実装するための必要な機能がすべて提供されています。このライブラリを使用することで、Django アプリケーションから RESTful な Web API を提供することができるようになります。
djangorestframework-simplejwt django-rest-framework を使用した RESTful な Web API にJSON Web Tokens(JWT)を使用した認証を実装するためのライブラリです。JWT は、トークンベースの認証方式の一種です。djangorestframework-simplejwt を使用することで、django-rest-framework で作成した RESTful な Web API に JWT を使用した認証を実装することができます。これにより、API を利用するアプリケーションがAPIに対してアクセスする際に、トークンを使用して認証を行うことができるようになります。
Djoser Django フレームワークで作成された RESTful な Web API にユーザー管理機能を実装するためのライブラリです。このライブラリを使用することで、Djangoアプリケーションにユーザー登録、ユーザー情報の管理、パスワードの変更などの機能を簡単に実装することができます。また、Djoser は、JSON Web Tokens(JWT)を使用した認証をサポートしているため、JWT を使用した API の認証も実装することができます。Djoser を使用することで、Django アプリケーションにRESTful な API を作成し、ユーザー管理や認証を実装することができるようになります。
model-bakery Django プロジェクトで使用されるモデルを生成するための Python パッケージです。model-bakery は、モデルを生成し、操作し、評価するためのツールを提供します。
pylint-django pylint-django は、Django フレームワークで作成された Python コードを検証するための Pylint プラグインです。Pylint は、Python のコード品質を測定するツールです。pylint-django を使用することで、Django フレームワークを使用した Python コードに対して、Pylint が提供する様々な品質指標を適用することができます。これにより、Django フレームワークを使用した Python コードの品質を向上させることができます。また、pylint-django は、Django フレームワーク固有の構文や API を理解しており、Django フレームワークを使用した Python コードをより正確かつ効率的に検証することができます。
pytest-django Python のテストフレームワークである pytest を用いて Django Web アプリケーションのテストを実行するためのプラグインです。このプラグインを使うことで、Django アプリケーションのテストを簡単に実行し、結果を比較することができます。また、pytest-django は、Django アプリケーションのデータベースを自動的にセットアップ・クリーンアップするため、データベースのテストも容易に行うことができます。
Wagtail Wagtail は、Django フレームワークを使用した CMS(Content Management System)です。このCMSを使用することで、WebサイトやWebアプリケーションのコンテンツの管理をより簡単かつスムーズに行うことができます。 Wagtail には、ページやブログ記事の管理、メディアライブラリ、ページのテンプレートやカスタマイズ、検索、ユーザー管理などの機能が備わっています。これらの機能を使用することで、WebサイトやWebアプリケーションのコンテンツを効率的に管理することができます。また、Wagtail はオープンソースであるため、カスタマイズや拡張も容易に行うことができます。


ちなみに、説明文は最近話題の「ChatGPT」の回答を使わせていただきました(なのでしれっと間違っている可能性もあるかもしれません)。冗長な説明があったのを削除して調整しましたが、スゴイですねこれ。

Django のビューから Django コマンドを実行する方法

この投稿は 「Calendar for Django | Advent Calendar 2022 - Qiita」 3日目の記事です。

小ネタです。


Django のビューから直接 Djangoコマンドを実行するには、django.core.management.call_command を使えば簡単 です。*1


こんな感じで使います。

api/views.py

from django.core import management
from rest_framework.response import Response
from rest_framework.views import APIView


class CallCommandView(APIView):
    def post(self, request, *args, **kwargs):
        # Djangoコマンドを実行
        management.call_command('loaddata', 'test_data', verbosity=0)
        # レスポンスオブジェクトを作成して返す
        return Response({'success': True})


これは Django REST Framework(通称 DRF)を使用したビューの実装例ですが、Django 単体でも同じように利用することが可能です。



config/urls.py

from django.urls import path

from api import views

urlpatterns = [
    path('call-command/', views.CallCommandView.as_view()),
]


実行結果





ちなみに、Django コマンドの「--no-input」オプションは call_command() に「interactive=False」を指定することで利用可能です。

management.call_command('flush', verbosity=0, interactive=False)


標準出力をファイルに書き込むこともできます。*2

with open('/path/to/command_output', 'w') as f:
    management.call_command('dumpdata', stdout=f)


cron などで定期実行している Django コマンドを、API で呼び出すなどといった利用方法が考えられますね。

*1:ビューからでなくても、モデルでもどこでも実行可能です。

*2:https://docs.djangoproject.com/ja/3.2/ref/django-admin/#output-redirection

既存テーブルに単一の主キーがない場合に Django モデルを使いたい場合の解決案(Django で複合主キーを使う方法)

この投稿は 「Calendar for Django | Advent Calendar 2022 - Qiita」 2日目の記事です。

最近こんなの見つけたよという緩い内容になっているので、「こんなのもあるんだな」という軽い気持ちで読んでいただければと思います。そしてもし、「現場で使ってるよ」という方がいれば教えていただければありがたいです。

課題

まず大前提ですが、Django モデルの仕様として、それぞれのモデルごとに単一の主キーを持たせる必要があり(「primary=True」オプションを持つフィールドをモデルに明示的に含めるか、さもなくば「id」という名前のフィールドが自動的にモデルに追加され、それに対応したカラムがテーブルに作成される)、複合主キー(composite primary key)はサポートされていません。 *1


そのため、例えば、単一の主キーを持たない(が複合主キーを持っている)既存のテーブルを Django モデルで扱うことは困難です。



ところで Django で複合主キーっぽいことをしたければ通常は、「id」という名前のサロゲートキーを主キーとして別に用意しつつ、複合ユニーク制約を利用しますよね。具体的には、Django 2.2 から追加された UniqueConstraint を利用して次のように実装します。


models.py

from django.db import models


class Employee(models.Model):
    """従業員モデル"""

    class Meta:
        db_table = 'employee'
        verbose_name = verbose_name_plural = '従業員'
        constraints = [
            models.UniqueConstraint(fields=['branch_code', 'employee_code'], name='unique_employee')
        ]

    branch_code = models.CharField('支店コード', max_length=3)
    employee_code = models.CharField('従業員コード', max_length=5)
    name = models.CharField('従業員名', max_length=255)

    def __str__(self):
        return f'{self.branch_code}-{self.employee_code}'


この従業員テーブルの仕様としては、支店ごとに従業員コードが振られていて、従業員コードはレコード全体としてはユニークになっていない(支店コードと従業員コードを合わせるとユニークになる)という想定です。

ちなみに複合ユニーク制約を実現するには unique_together を使うことも可能ですが、将来的に非推奨になる可能性があり、UniqueConstraint の方が多機能なので、UniqueConstraint の利用が推奨されます。



 

解決策

最近見つけたのですが、(次期リリースではありますが)「Viewflow」というライブラリの「CompositeKey」を使えば、既存テーブルに主キーがないテーブルを Django モデルで扱うことが可能になります。

使い方は次の通りです。

pip install django-viewflow --pre

# or

pip install django-viewflow==2.0.0a2


models.py

from django.db import models
from viewflow.fields import CompositeKey


class Employee(models.Model):
    """従業員モデル"""

    class Meta:
        db_table = 'employee'
        managed = False
        verbose_name = verbose_name_plural = '従業員'

    id = CompositeKey(columns=['branch_code', 'employee_code'])
    branch_code = models.CharField('支店コード', max_length=3)
    employee_code = models.CharField('従業員コード', max_length=5)
    name = models.CharField('従業員名', max_length=255)

    def __str__(self):
        return f'{self.branch_code}-{self.employee_code}'


これで、CompositeKey の columns で指定した複数のフィールドの値を「{'branch_code': '001', 'employee_code': '00001'}」のような JSON 文字列で保持する「id」という名前の 仮想フィールド を持つことができます。

「managed = False」*2 を指定しないとマイグレーションで「id」カラムが作成されてしまうのですが、CompositeKey が威力を発揮するのは「managed = False」を指定してモデルをマイグレーションの対象外にした場合で、主キーを持たない既存のテーブルに影響を及ぼさずに Django モデルを用意することができます。事例としては、次のように複合主キーを持った既存テーブルから Django ORM を使ってレコードを抽出(読み取り専用)したいというニーズに応えることができます。


Django 管理サイトでも動作するというのも高評価です。

*1:Django で複合主キーをサポートするかどうかは、17年前から議論が続いています… #373 (Add support for multiple-column primary keys) – Django

*2:https://docs.djangoproject.com/ja/3.2/ref/models/options/#managed

Django REST Framework はじめの一歩 〜押さえておきたい3つのポイント〜

この投稿は 「Djangoのカレンダー | Advent Calendar 2022 - Qiita」 1日目の記事です。


この記事では、11月に「みんなのPython勉強会#87」で発表したトーク 「Django REST Framework はじめの一歩 〜押さえておきたい3つのポイント〜」の内容を詳しく説明したいと思います。トークの目的は「Django REST Framework(通称 DRF)がどんなものかをざっくり理解する」です。 DRF はよく分からないけど、Django なら何となく分かるという DRF 初心者の方を理想のトーク対象者として想定しています(もちろん Django を知らなくてもウェルカム!)。

ちなみに、各種バージョンは

  • Django : 3.2 LTS(現時点での最新 LTS)
  • DRF : 3.14(現時点での最新バージョン)

で動作確認をしています。



 

はじめに



今回のトークに先立って事前に Twitter でアンケートを取ったところ、約73%の方が「DRF を使っている」と回答していた のですが、私の予想を遥かに超えて DRF が使われていることに驚きました(正直半々くらいかなと思っていました…)。

ここで、アンケートにご協力いただいた皆さまにこの場を借りて感謝申し上げたいと思います。ご協力ありがとうございました。





また、「Django Developers Community Survey 2021」という7000名を超える開発者アンケートでは、「好きな Django パッケージは何ですか?(複数回答ありで5つまで回答可)」という質問に対して、DRF が第1位に選出されていました。2位の「django-celery」と比較してもダブルスコアというぶっちぎりの結果になっていますね。



 

DRF とは?



本題に入る前にまず、DRF とは何か?を説明したいと思います。一言でいえば、DRF は「REST API を作成する際の多彩なニーズに応えるための超ド定番 Django パッケージ」です。 Django 単体では不足しているさまざまな機能を、DRF で補完してくれているというイメージになります。特に、Django 開発者なら理解しやすい作りになっているというのが、Django 開発者にとってうれしい特徴です。






続いて、REST API の概要についても説明します。
REST API はスマホや SPA のバックエンドとして よく利用されています(左図)。そして、REST API は、URI でリソースを特定し、HTTP メソッドでそのリソースへの操作を表すという直感的に理解しやすいシンプルな設計になっています(右図)。そんな共通の枠組みに則ったデータを介すことで、フロントエンドとバックエンドが疎結合化、すなわち、お互いのプログラミング言語やアーキテクチャを意識することなくデータをやり取りすることができるのです。なお、REST API はリソース中心の設計となっているので、モデル中心の Django と親和性が高いというのも DRF を使うメリットになるかと思います。






DRF が一番得意なのは、単一リソースの CRUD を処理する REST API です。上の表に示したように、単一リソースの CRUD を処理する REST API は、「GET」「POST」「PUT」「PATCH」「DELETE」という HTTPメソッドそれぞれに意味を持たせ、リソースを表す URI と組み合わせて、「リソース一覧の取得」「リソース詳細の取得」「リソースの登録」「リソースの更新」「リソースの一部更新」「リソースの削除」といった API を構成します。これを DRF で実装するのはすごく簡単で、モデル除けば最短20行くらいで書くことができます(コード例については後ほど紹介します)。






ここで、DRF についてよくある「誤解」を紹介します。
よくある誤解その①「DRF では単一リソースを扱う API 以外は作れない」は「✕」です。先に説明した 単一リソースを扱う REST API 以外にも、上の表に示したような、リソースがネストした API、独自アクションを追加した API、リソースに紐付いていない API なども DRF で作成することができます。





よくある誤解その②「DRF なしでは JSON のやり取りができない」も「✕」です。Django 単体でも(やろうと思えば)JSON データを受け取って JSON データを返すことができます。下の例を見てください。

api/views.py

import json
from django.forms.models import model_to_dict
from django.http.response import JsonResponse
from django.views import View
from shop.models import Book


class BookCreateView(View):
    """本モデルの登録APIクラス"""

    def post(self, request, *args, **kwargs):
        """本モデルの登録APIに対応するハンドラメソッド"""
        data = json.loads(request.body)
        # バリデーションを実行
        if not data.get('title'):
            return JsonResponse({'message': 'タイトルは必須です。'}, status=400)
        # モデルオブジェクトを登録
        book = Book(**data)
        book.save()
        # レスポンスオブジェクトを作成して返す
        return JsonResponse(model_to_dict(book), status=201)

入力パラメータとなる JSON データは request.body に入っているのでそれをパースして、(この例ではめちゃくちゃ適当ですが)バリデーションを適宜実行して、モデルオブジェクトにデータを詰め替えて永続化して、最後に JsonResponse オブジェクトを作成して返しています。でもこんなことを毎回するのは大変ですよね。できれば Django っぽい書き方で、こういった処理を共通化したいというニーズから DRF が誕生したんじゃないかなと思います。






次は、DRF を使うメリットについて。
まず、Django のノウハウやエコシステムが活用できるというのが、DRF を使う大きなメリットになります。 むしろこれがほとんどすべてと言っても過言ではありません。DRF プロジェクトのベースはあくまでも Django なので、ORM やマイグレーションを始めとする多くの機能をフル活用できたり、いつも使っている Django パッケージが使えたりといったように、Django のノウハウやエコシステムをほぼそのまま使うことができます。

そして次に、人気があって枯れていることもメリットです。DRF は Django で REST API を作るとなった場合にほぼ一択になるほど人気で、特に英語圏での情報がたくさんあります。 公式ドキュメントやチュートリアルも(英語になりますが)かなり充実しています。

機能が充実していることも DRF ならではのメリットです。 例えば、Cookie認証、トークン認証、JWT認証などの API でよく利用される認証を簡単に利用する ことができます。また、アクセス権制御をするための「パーミッション」機能、クエリ文字列による検索をするための「フィルタリング」機能、「ページネーション」機能、APIの利用回数制限をするための「スロットリング」機能などが用意されており、それぞれが差し替えできるようになっています。さらに、画面で API を実行確認できる「Browsable API」と呼ばれるテストクライアントがすぐに使えたり、OpenAPI に準拠した API ドキュメントを出力 したりすることもできます。こういった REST API を作成するのに必要な機能がたいてい揃っていて、簡単な設定をするだけで幅広いニーズを満たすことができるというのが大きな特徴になります。






逆に、DRF にはどんなデメリットがあるのでしょうか。

ズバリ… 複雑です。

Django だけでも十分複雑なのに、そこに DRF が加わったらさらに複雑になってしまいますよね。






そこでここからは、DRF 初心者が押さえておきたい次の3つのポイントを解説していきたいと思います。

  • ポイント①:全体像を把握しよう
  • ポイント②:シリアライザはフォームっぽく使える
  • ポイント③:起点は DRF 用ビュー

この3つについてそれぞれ詳しく説明していきます。



 

ポイント①:全体像を把握しよう

ポイント①「全体像を把握しよう」について。



まず比較のために、Django プロジェクトの全体像と登場人物について説明します。図の左側から来たリクエストを、URLディスパッチャと呼ばれる Django のコアコンポーネントがハンドリングし、URLconf で登録したビュー関数を呼び出して、ビューの中でフォームやモデル、テンプレートを使って、レスポンスを作成して返し、URLディスパッチャがレスポンスを処理するという流れになっています。ミドルウェアは、ビューが呼び出される前や後で何らかの処理をするために利用されます。






REST API を構築するための DRF プロジェクトでは、(HTML のフォーム要素を扱わないし、レスポンスとして画面をレンダリングした HTML を返さないので)基本的にフォームとテンプレートは使いません(後述しますが、Django を共存させる場合にはその限りではありません)。その代わり、DRF では「シリアライザ」というコンポーネントを使います。 シリアライザは入出力の JSON(およびモデルとの連携)定義とバリデーションを担当します。ポイント②で詳しく説明しますが、シリアライザはフォームに似せて作られていて、フォームと同じように使うことができます。

そしてビューは、DRF用のビューを使います。これもポイント③で説明しますが、図を見ると分かるように、DRF の起点となるのは「DRF 用ビュー」です。図では「✕」で示していますが、通常の Django のビューを URLconf に登録しておくことも可能です。

それ以外のモデル、URLconf、ミドルウェアは通常の Django と同じように使います。






ポイント①のまとめです。DRF では、DRF用のビュー を作成して URLconf に登録します。そしてシリアライザというコンポーネントを使い、フォームとテンプレートは使いません。ただし、Django と DRF のビューをそれぞれ登録することができるので、そういった共存をさせる場合にはフォームもテンプレートも使うことになるので誤解のないようにしてください。それ以外は通常の Django とだいたい同じように使います。こういった全体像を押さえておくのが第一のポイントです。




 

ポイント②:シリアライザはフォームっぽく使える

ポイントその②「シリアライザはフォームっぽく使える」について。



その前にまず、DRF の独自コンポーネントである「シリアライザ」の使いどころを説明します。シリアライザが担当する役目は、

  • 入力データのバリデーション
  • モデルオブジェクトの永続化
  • 出力データの作成

です。上の図はどこでシリアライザを使うかを示しているのですが、登録API、更新API、取得API のそれぞれでシリアライザの使いどころが異なります(削除API のようにシリアライザを使わない場合もあります)。例えば登録 API だと、リクエストされた JSON データを元にしてシリアライザオブジェクトを作成し、シリアライザオブジェクトのバリデーションメソッドを実行し、シリアライザの永続化メソッドを実行して、最後にレスポンスオブジェクトの引数にシリアライザのデータを渡すという流れになります。このように、ほとんどの場合でシリアライザを使うことになるため、DRF を使うときにはシリアライザは避けて通ることができません。






さて、本題です。シリアライザはフォームっぽく使えるということについて説明します。リソース(すなわちモデル)と紐付いた REST API の場合は「ModelSerializer」を使うのが基本なのですが、ModelSerializer の使い方は(フォームで特定のモデルを扱うための)ModelForm とほぼ同じです。 ModelSerializer と ModelForm の引数や属性、バリデーション、永続化の流れを上の図に並べて示したのですが、仕組みがほぼ同じになっています。バリデーションメソッドは「is_valid」、永続化メソッドは「save」でこちらも同じです。ただし、バリデーション済みのデータは「validated_data」となっていて、ModelForm(親クラスの Form も同様)と変数名が異なるので注意してください。






シリアライザの実装イメージは次のようになります。

api/serializers.py

from rest_framework import serializers

from shop.models import Book


class BookSerializer(serializers.ModelSerializer):
    """本モデル用シリアライザ"""

    class Meta:
        model = Book
        fields = ['id', 'title', 'price']

ModelSerializer を継承したシリアライザクラスを用意して、Metaクラスの「model」属性に連携させるモデルクラス、「fields」属性に JSONの入出力フィールドとして利用するモデルのフィールド名を指定します。フィールドは、fields 属性以外に、除外するフィールドを excludes 属性で指定することもできます。

使い方は ModelFormとほぼ同じで、引数「data」にリクエストのパラメータ(DRF では JSON データ)、更新時には引数「instance」にモデルオブジェクトを指定します。バリデーションをおこなたいときは is_valid()、モデルオブジェクトを永続化したいときは save() メソッドを実行します。

>>> from api.serializers import BookSerializer
>>> serializer = BookSerializer(data={'title': 'DRFの本', 'price': 1000})
>>> serializer.is_valid()
True
>>> serializer.validated_data
OrderedDict([('title', 'DRFの本'), ('price', 1000)])
>>> book = serializer.save()

>>> serializer = BookSerializer(instance=book, data={'price': 2000}, partial=True)
>>> serializer.is_valid()
True
>>> serializer.save()
<Book: DRFの本>




ポイント②のまとめです。モデルと紐付いた REST API の場合は ModelSerializer を使うのが簡単で、その使い方は ModelForm とほぼ同じです。




 

ポイント③:起点は DRF 用ビュー

最後のポイント「起点は DRF 用ビュー」について。



DRF には「rest_framework.views.APIView」というクラスが用意されているのですが、「APIView」は DRF の起点となる基底ビュークラスで、これを継承することで、さまざまな前処理と後処理をやってくれます。

1. リクエストオブジェクトを DRF 用に変換
2. レンダラクラスとメディアタイプを決定
3. バージョニング
4. 認証チェック
5. パーミッションチェック
6. スロットリング
7. 例外ハンドリング

これらの処理は差し替え可能です。2. 〜 6. には代表的な処理クラスがいくつか用意されていて、デフォルトの設定を設定ファイル(settings.py)の「REST_FRAMEWORK」で上書きして全体的な設定をしたり、クラス変数をオーバーライドしてビュークラス単位での個別設定をしたりすることができます。






DRF 用のビューは大きく分けて3種類あり、用途に応じて

1)rest_framework.views.APIView
2)rest_framework.generics.CreateAPIView などの 汎用 APIView
3)rest_framework.viewsets.ModelViewSet 系ビュー

のいずれかを継承して作成します。 どれを選択するかによってそれぞれカスタム性やコード量が異なってきますが、この後で具体的な実装を見ながら説明していきます(コードがたくさん出てきますが、雰囲気を理解してもらえれば大丈夫です)。

ちなみに下の図で示すように、2) と 3) のビューは「APIView」の子クラスで、APIView は「基本汎用ビュー」と呼ばれる Django の「View」クラスの子クラスです。







まず、1)の APIView を継承したビューの書き方について説明します。

例えば、更新 API で呼び出される post メソッドでは、モデルオブジェクトと入力データからシリアライザオブジェクトを作成し、is_valid() で入力データのバリデーションをおこない、save() でモデルオブジェクトを更新して、最後にシリアライザの data 属性の値を使ってレスポンスオブジェクトを作成して返しています。

api/views.py

from rest_framework import status, views
from rest_framework.generics import get_object_or_404
from rest_framework.response import Response

from shop.models import Book
from .serializers import BookSerializer


class BookRetrieveUpdateAPIView(views.APIView):
    """本モデルの取得(詳細)・更新APIクラス"""

    def get(self, request, pk, *args, **kwargs):
        """本モデルの取得(詳細)APIに対応するハンドラメソッド"""

        # モデルオブジェクトを取得
        book = get_object_or_404(Book, pk=pk)
        # シリアライザオブジェクトを作成
        serializer = BookSerializer(instance=book)
        return Response(serializer.data, status.HTTP_200_OK)

    def put(self, request, pk, *args, **kwargs):
        """本モデルの更新APIに対応するハンドラメソッド"""

        # モデルオブジェクトを取得
        book = get_object_or_404(Book, pk=pk)
        # シリアライザオブジェクトを作成
        serializer = BookSerializer(instance=book, data=request.data)
        # バリデーションを実行
        serializer.is_valid(raise_exception=True)
        # モデルオブジェクトを更新
        serializer.save()
        # レスポンスオブジェクトを作成して返す
        return Response(serializer.data, status.HTTP_200_OK)

コードは長くなりますが、好きなように書くことができます。しかし、単一リソースの CRUD 処理をする場合、モデルとシリアライザだけが違うビューを追加する場合に同じようなコードを何度も書くのはさすがに冗長ですよね。






そんな場合に利用したいのが、2)の「汎用 APIView」です。上の表に示したように、対応アクションごとにいろいろな汎用 APIView が用意されているので、用途に合わせてどれかを継承して、モデルオブジェクトを取得するためのクエリを指定するための「queryset」とシリアライザクラスを指定するための「serializer_class」をクラス変数を加えるだけです。

これでだいぶ短く書くことができますが、単一モデルのCRUD処理をするというのを逸脱した API を作ろうとすると、親クラスのメソッドをオーバーライドして拡張する必要があります。


api/views.py

from rest_framework import generics

from shop.models import Book
from .serializers import BookSerializer


class BookListCreateAPIView(generics.ListCreateAPIView):
    """本モデルの取得(一覧)・登録APIクラス"""

    queryset = Book.objects.all()
    serializer_class = BookSerializer


class BookRetrieveUpdateDestroyAPIView(generics.RetrieveUpdateDestroyAPIView):
    """本モデルの取得(詳細)・更新・一部更新・削除APIクラス"""

    queryset = Book.objects.all()
    serializer_class = BookSerializer

config/urls.py

from django.urls import path
from api import views

urlpatterns = [
    path('api/books/', views.BookListCreateAPIView.as_view()),
    path('api/books/<pk>/', views.BookRetrieveUpdateDestroyAPIView.as_view()),
]




最後に、3)ModelViewSet 系ビューを継承したビューの書き方です。冒頭で「単一リソースの CRUD を処理する REST API なら超簡単」で「20行くらいで API が全部書ける」と言っていたのはこちらです。

上の表に書いたように ModelViewSet は「一覧」「詳細」「登録」「更新」「一部更新」「削除」という6つの API を全部網羅しています。 実装は、下に示したように ModelViewSet を継承して、「serializer_class」と「queryset」の指定をするだけです。

api/views.py

from rest_framework import viewsets

from shop.models import Book
from .serializers import BookSerializer


class BookViewSet(viewsets.ModelViewSet):
    """本モデルのCRUD用APIクラス"""

    serializer_class = BookSerializer
    queryset = Book.objects.all()


あとは、ViewSet 用の SimpleRouter(または DefaultRouter)を利用して URL パターンを URLconf に追加してあげれば、これで API の実装は完了です。シリアライザを含めて最短20行ほどで書くことができます。

config/urls.py

from django.urls import include, path
from rest_framework import routers
from api import views

router = routers.DefaultRouter()
router.register('books', api.BookViewSet)

urlpatterns = [
    # すべてのアクション(一覧・詳細・登録・更新・一部更新・削除)をまとめて追加
    path('api/', include(router.urls)),
]

なので、単一モデルの CRUD を処理する REST API をまるっと実装したいというニーズには「ModelViewSet」が一番最速で実装できる ということになります。






ポイント③のまとめです。単一モデルの CRUD を処理する REST API をまるっと実装したい場合は ModelViewSet 系ビューを使うのが一番簡単で、複雑なことがしたい場合は APIView(または GenericAPIView)を継承したビュークラスを使うのがよいでしょう。



 

まとめ

最後のまとめです。



DRFを使う場合、Django に DRF の要素、コンポーネントが加わることになるので複雑になります。なのでまずは、全体像を把握しましょう。一見複雑にみえますが、新しい要素は「シリアライザ」と「DRF用ビュー」です。

「シリアライザ」は入力データのバリデーション、内部に保持したモデルオブジェクトの永続化、出力データの作成を担当するクラスで、Django のフォームと同じような使い方ができます。

「DRF用ビュー」は大きく3種類あり、まるっと API 全部を実装できてしまうものもあれば、複雑なカスタム API にも対応できるものもあるので、用途に合わせて親クラスと書き方を使い分けてください。


さてこれで、DRF がどんなものか完全に理解できたでしょうか。もっと DRF のことを深く知りたいという方は、「現場で使える Django REST Framework の教科書」という 220ページ以上まるまる DRF について書かれた素敵な本があるので、そちらを読んでみてください。ここで説明した内容をもっとディープに解説しています。そして何と、今月この本が改訂予定です。Django 3.2 LTS、DRF 3.14 対応で、Vue 3(+ Vite)と Vuetify 3 でチュートリアルを刷新しています。




トークのスライドはこちらにアップしています。

speakerdeck.com




 

宣伝

Django の技術同人誌をこれまでに4冊出しました。開発のお供にどうぞ。



現場で使える Django の教科書《基礎編》

「現場で使える Django の教科書」シリーズ第1弾となる Django の技術同人誌。Django を現場で使うための基礎知識やベストプラクティスについて、初心者・初級者向けに解説した本です。B5・本文192ページ。Django 3.2 LTS に対応。


★ Amazon(電子版/ペーパーバック)


★ BOOTH(紙の本)



現場で使える Django の教科書《実践編》

《基礎編》の続編にあたる「現場で使える Django の教科書」シリーズの第2弾。認証まわり、ファイルアップロード、ユニットテスト、デプロイ、セキュリティ、高速化など、さらに実践的な内容に踏み込んでいます。現場で Django を本格的に活用したい、あるいはすでに活用している方にピッタリの一冊。B5・本文180ページ。


★ Amazon(電子版/ペーパーバック)


★ BOOTH(紙の本)※在庫なし



現場で使える Django REST Framework の教科書

Django で REST API を構築する際の鉄板ライブラリである「Django REST Framework」(通称「DRF」)にフォーカスした、「現場で使える Django の教科書」シリーズの第3弾。B5・本文228ページ。Django 3.2 LTS に対応。


★ Amazon(電子版/ペーパーバック)


★ BOOTH(紙の本)※在庫なし



現場で使える Django 管理サイトのつくり方

Django の管理サイト(Django Admin)だけに特化した、ニッチでオンリーワンな一冊。管理サイトをカスタマイズする前に絶対に読んでほしい本です。B5・本文152ページ。


★ Amazon(電子版)


★ BOOTH(紙の本)

Django 組み込みのパスワード再設定(パスワードリセット)の仕組み

この投稿は 「Djangoのカレンダー | Advent Calendar 2021 - Qiita」 1日目の記事です。


akiyoko です。
この記事では、Django 組み込みで提供されているパスワード再設定(パスワードリセット)の仕組みを深掘りします。 Django のパスワード再設定機能に関しては、利用方法についてはさまざまな記事で紹介されていたりするのですが、その内部仕様について詳しく紹介した記事をあまり見かけたことがなかったので、自分のメモがてら残しておこうと思い、ほぼ一年ぶりに筆を執りました。何かのお役に立てば幸いです。




検証環境

  • Django 3.2


 

はじめに

Django は Webアプリケーションを作成するために必要な機能が何でも揃っているフルスタックフレームワークで、ユーザー認証まわりの機能(ユーザーモデル、パーミッション、ユーザーセッションなど)などの便利な機能がデフォルトで用意されています。そしてあまりよく知られていませんが、パスワード再設定(パスワードリセット)機能(で利用できるビューやフォーム)もユーザー認証まわりの機能の一部として「django.contrib.auth(認証システム)」パッケージに含まれています。

なお、「django.contrib.admin(管理サイト)」パッケージにはパスワード再設定系のテンプレートが用意されているので、管理サイト内でパスワード再設定機能を利用するのは非常に簡単です。


 

管理サイトでのパスワード再設定機能の利用方法

管理サイトではパスワード再設定系の機能はデフォルトでオフになっているため、利用するには次のように URLconf にパスワード再設定用の4つの URLパターンを追加しなければいけません(詳しくは公式ドキュメント *1 を参照)。

config/urls.py(URLconf)

from django.contrib import admin
from django.contrib.auth import views as auth_views
from django.urls import path

urlpatterns = [
    path('admin/password_reset/', auth_views.PasswordResetView.as_view(), name='admin_password_reset'),
    path('admin/password_reset/done/', auth_views.PasswordResetDoneView.as_view(), name='password_reset_done'),
    path('reset/<uidb64>/<token>/', auth_views.PasswordResetConfirmView.as_view(), name='password_reset_confirm'),
    path('reset/done/', auth_views.PasswordResetCompleteView.as_view(), name='password_reset_complete'),
    path('admin/', admin.site.urls),
]


上で示した「admin_password_reset」というURLパターンが登録されていれば、管理サイトのログイン画面に、次のように「パスワードまたはユーザー名を忘れましたか?」というリンクが表示されるようになります。




この追加設定により、次のような画面遷移ができます。


それぞれの挙動は参考情報に示したビューやフォームを読めば分かるのですが、ちょっと理解しずらいのが「パスワード再設定メール」の仕組みです。


パスワード再設定メールの仕組み



パスワード再設定メール送信画面で「パスワードをリセット」ボタンを押下すると、django.contrib.auth.views.PasswordResetView がリクエストを受け取り、入力したメールアドレスに紐付くアクティブ(is_active が True)なユーザーが存在する場合にのみパスワード再設定用のメールが送信されます。

例えばホストが「127.0.0.1:8000」の場合のパスワード再設定メールは次のようになります。

Subject: 127.0.0.1:8000 のパスワードリセット
From: webmaster@localhost
To: admin@example.com
Date: Fri, 26 Nov 2021 21:47:26 -0000
Message-ID: 
 <163796324660.443.3589748126282107509@1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa>
このメールは 127.0.0.1:8000 で、あなたのアカウントのパスワードリセットが要求されたため、送信されました。
次のページで新しいパスワードを選んでください:
http://127.0.0.1:8000/reset/MQ/awrev2-3a07a0471392cfbc3b885b713b2846d5/
あなたのユーザー名 (もし忘れていたら): admin
ご利用ありがとうございました!
 127.0.0.1:8000 チーム

メール本文にはパスワード再設定画面に遷移するためのリンクが含まれており、リンクの有効期限はデフォルトでは3日間となっています。*2


このリンクの URL は、「password_reset_confirm」という URL パターンで URLconf に登録されている「reset/<uidb64>/<token>/」に相当します。<uidb64>の部分、すなわち上のメールの例の「MQ」は、Base64 でエンコードされたユーザーの PK で、Base64 でデコードすると「1」になります。

<token>の「-」の左側の部分(上の例では「awrev2」)は、メール送信時のタイムスタンプ(2001/1/1 00:00:00 からの経過秒数)を Base34 でエンコードしたもので、リンクの有効期限をチェックするために使われます。残りの右側の部分(上の例では「3a07a0471392cfbc3b885b713b2846d5」)は改ざん防止のためのハッシュです。*3


django.contrib.auth.views.PasswordResetConfirmView では、パスワード再設定URL のリクエストを受け取ると、URL の妥当性(ユーザーが存在するかどうか、URL が改ざんされていないかどうか、有効期限を過ぎていないか)が検証され、「/reset/<uidb64>/set-password/」にリダイレクトされてパスワード再設定画面が表示されます。



ちなみに、URL の<token>は(ハッシュ化された)パスワード文字列などから生成されているため(下記参照)、パスワード再設定によってパスワードが変更された後は同じ URL は利用できなくなります。

django.contrib.auth.tokens.PasswordResetTokenGenerator._make_hash_value

    def _make_hash_value(self, user, timestamp):
        """
        Hash the user's primary key, email (if available), and some user state
        that's sure to change after a password reset to produce a token that is
        invalidated when it's used:
        1. The password field will change upon a password reset (even if the
           same password is chosen, due to password salting).
        2. The last_login field will usually be updated very shortly after
           a password reset.
        Failing those things, settings.PASSWORD_RESET_TIMEOUT eventually
        invalidates the token.

        Running this data through salted_hmac() prevents password cracking
        attempts using the reset token, provided the secret isn't compromised.
        """
        # Truncate microseconds so that tokens are consistent even if the
        # database doesn't support microseconds.
        login_timestamp = '' if user.last_login is None else user.last_login.replace(microsecond=0, tzinfo=None)
        email_field = user.get_email_field_name()
        email = getattr(user, email_field, '') or ''
        return f'{user.pk}{user.password}{login_timestamp}{timestamp}{email}'




 

まとめ

Django はパスワード再設定(パスワードリセット)機能を組み込みで提供しており、管理サイト内でパスワード再設定機能を利用するのは非常に簡単です。管理サイト外でパスワード再設定を利用する場合は、「django.contrib.auth(認証システム)」パッケージのビューやフォームを使用し、「django.contrib.admin(管理サイト)」パッケージのテンプレートを参考にすればよいでしょう。

パスワード再設定系のビューやフォーム、テンプレートについては次の参考情報をご確認ください。


 

参考情報

パスワード再設定系のビュー・フォーム

  • django.contrib.auth.views.PasswordResetView
  • django.contrib.auth.views.PasswordResetDoneView
  • django.contrib.auth.views.PasswordResetConfirmView
  • django.contrib.auth.views.PasswordResetCompleteView
  • django.contrib.auth.forms.PasswordResetForm
  • django.contrib.auth.forms.SetPasswordForm

パスワード再設定系のテンプレート

  • django/contrib/admin/templates/registration/password_reset_form.html
  • django/contrib/admin/templates/registration/password_reset_done.html
  • django/contrib/admin/templates/registration/password_reset_confirm.html
  • django/contrib/admin/templates/registration/password_reset_complete.html

(メールタイトル・本文のテンプレート)

  • django/contrib/auth/templates/registration/password_reset_subject.txt
  • django/contrib/admin/templates/registration/password_reset_email.html


 

宣伝

Django の技術同人誌をこれまでに4冊出しました。開発のお供にどうぞ。



現場で使える Django の教科書《基礎編》

「現場で使える Django の教科書」シリーズ第1弾となる Django の技術同人誌。Django を現場で使うための基礎知識やベストプラクティスについて、初心者・初級者向けに解説した本です。B5・本文192ページ。Django 3.2 LTS に対応。


★ Amazon(電子版/ペーパーバック)


★ BOOTH(紙の本)



現場で使える Django の教科書《実践編》

《基礎編》の続編にあたる「現場で使える Django の教科書」シリーズの第2弾。認証まわり、ファイルアップロード、ユニットテスト、デプロイ、セキュリティ、高速化など、さらに実践的な内容に踏み込んでいます。現場で Django を本格的に活用したい、あるいはすでに活用している方にピッタリの一冊。B5・本文180ページ。


★ Amazon(電子版/ペーパーバック)


★ BOOTH(紙の本)※在庫なし



現場で使える Django REST Framework の教科書

Django で REST API を構築する際の鉄板ライブラリである「Django REST Framework」(通称「DRF」)にフォーカスした、「現場で使える Django の教科書」シリーズの第3弾。B5・本文228ページ。Django 3.2 LTS に対応。


★ Amazon(電子版/ペーパーバック)


★ BOOTH(紙の本)※在庫なし



現場で使える Django 管理サイトのつくり方

Django の管理サイト(Django Admin)だけに特化した、ニッチでオンリーワンな一冊。管理サイトをカスタマイズする前に絶対に読んでほしい本です。B5・本文152ページ。


★ Amazon(電子版)


★ BOOTH(紙の本)

*1:https://docs.djangoproject.com/ja/3.2/ref/contrib/admin/#adding-a-password-reset-feature

*2:有効期限をデフォルトの3日間から変更したい場合は、「PASSWORD_RESET_TIMEOUT」を設定ファイルに定義することで変更可能です。なお、Django 2.2 以前で利用されていた「PASSWORD_RESET_TIMEOUT_DAYS」は非推奨になっており、Django 4.0 で削除される予定です。https://docs.djangoproject.com/en/3.2/internals/deprecation/#deprecation-removed-in-4-0

*3:ハッシュ化アルゴリズムには Django 3.1 以降でデフォルトになった「sha256」が使われています。