はじめに
現場で使えるDjangoの教科書《基礎編》の読書会である、モグモグDjango読書会に参加してきました。
会場
会場はENECHANGE株式会社さんの提供でした。
勉強会終了後、ENECHANGE CTOの白木さんのご厚意でオフィスをぐるっと見学させていただいたのですが、とてもおしゃれなオフィスでした。
ちなみにENECHAGEさんでは、Djangoエンジニアを現在募集中だそうです！
勉強会の進め方
著者である@akiyokoさんが講師となって、Djangoの教科書《基礎編》の
- はじめに
- アーキテクチャ
- プロジェクト構成
- URLディスパッチャとURLConf
- ビュー
- モデル
を対象に解説していきます。
《基礎編》全体からすると対象は4割にとどまりますが、解説と参加者の質問が「濃い」ので、勉強会の4時間はあっという間に過ぎます。
流れとしては、各章ごとに
- その章に関する質問を共有のスプレッドシートに各自書き込み
- 上記の質問を踏まえつつ、akiyokoさんが各章のポイントや補足事項を事前準備した資料に基づいて解説
- 各参加者から前述のスプレッドシートに沿って質問し、akiyokoさんがそれに応える
- その後、3名程度がその章の感想を自由に述べる
といったサイクルを繰り返していきました。
参加人数は12名と比較的少人数な分、誰かが質問すると、それに触発されてまた別の質問が生まれて・・・と全員が積極的な参加スタイルとなった勉強会でした。
なお、「モグモグ」とある通り、各参加者が持ち寄ったお菓子をみんなでモグモグしながらの勉強会となります！
ちなみに私はカントリーマアムを持っていきました。
勉強会メモ
URLConfとURLディスパッチャ
- URLConfは、urls.pyのこと
- では、URLディスパッチャの正体は？
- django.core.handlers.wsgi.pyのWSGIHandler
Djangoアプリの適切な粒度
- アプリはできるだけ小さく
- 機能をひとことで表せる程度
- ひとつのアプリあたり、モデル数は3〜5個程度
- 例えばREST APIなら、モデルだけを持つアプリと、シリアライザ等のアプリといった感じで分割するなど
- (私からの質問)汎用的にカスタマイズしたUserモデルだけを持つusersアプリを作って、他の機能は別アプリに作り込んでいく方針はどうか？
- 良い方針だと思う。
クラスベースビューのビュー関数化
Djangoの教科書では、views.pyでクラスベースビューをビュー関数化している。
from django.views import View class HelloView(view): # ... hello = HelloView.as_view()
これはurls.pyからだけでなく、他のビューからも呼び出せるようになるというメリットがあるが、urls.py側でビュー関数化するのでも構わない。むしろ、そのやり方が多数派。
from django.urls import path
from .views import HelloView
urls = [
path('', HelloView.as_view(), name='hello'),
]
書籍では、ビュー関数化をURLConfの章で解説するよりもビューの章で解説した方が構成上わかりやすくなるので、そのようにしたとのこと。
models.pyの管理方法
- views.pyのロジックは最小限とし、models.pyにはビジネスロジックを寄せてファットにするのが良い
- ファットになり過ぎたら、utillsディレクトリあるいはutills.pyを作って、そこに機能を切り出す
- ファット過ぎるかどうかの基準は一概には言えない
最後に
参加者については
- 普段は機械学習や画像解析をされている方
- Railsエンジニアの方
- 日頃の業務の効率化にPythonを活用されている方
など、様々なバックグラウンドの方が来ていました。
こうした参加者の方とも交流が図れ、とても有意義な勉強会でした。
主催者の@shinseitaroさん、講師のakiyokoさん、会場を使わせてくださった白木さん、ありがとうございました。
