Djangoアプリケーションを開発する際のデバッグ方法について紹介します。 標準のDebugモード以外に使える様々なサードパーティライブラリを中心に、 私が趣味/仕事でのDjangoアプリケーションを開発する通して学んだデバッグ方法を具体的に紹介します。 アプリケーション開発時の泥沼のデバッグ作業は誰しも避けたいものです。 その時間はたいてい無駄になりますし、開発者自身つらいものがありますね。 優秀なツール使い、その負担を軽減しましょう。 適切なロギングで、発生した問題に素早く対処できるようにしましょう。 このセッションでは少しでも開発の助けになるよう、 Djangoアプリケーションのデバッグ方法を紹介します。

1. file:///home/hirokiky/Dropbox/sides/reveal.js­2.5.0/slides/pyconapac2013.html#/
Django最速デバッグ指南
@hirokiky
hirokiky.org

3. 目的
Djangoでの開発を早くする
デバッグに疲れないようにする
問題に素早く対応する

4. 対象
Webアプリ開発をしたことがある
Djangoで開発をしたことがある

5. バグ
photo by Brian searle
不具合
瑕疵

6. デバッグは何が起こってるのかを知ること
photo by m4tik
何が起こっているのかを知る
自分が何をしたいかを明確にする
その差分を埋める修正をする

7. 内容
前置き: 5分
デバッグ用ツール紹介
django-debug-toolbar: 10分
django-pdb: 10分
django-devserver: 5分
Logging: 10分

8. 自己紹介 (ふつう)
21歳
ドールと暮らしています
@hirokiky

9. Django好きです
フルスタックで必要なものが揃ってて
各コンポーネント間で統合されていて
早く開発できる

10. 自己紹介 (まじめ)
日本で4人目の 本体の貢献者
の運営
仕事は でDjango/Python
Django
djangoproject.jp
BePROUD Inc

11. 最近作ったライブラリ紹介
django-websettings
settings.pyライクなもの
Webインタフェースから設定値を編集できる

12. Django最速デバッグ指南

13. デバッグ用ツール紹介
django-debug-toolbar
django-pdb
django-devserver

14. django-debug-toolbarとは
デバッグ情報を常に表示するツールバー

15. django-debug-toolbarの良い点
リクエストのヘッダ/パラメーターなどが見れる
使われたテンプレートとコンテキストを見れる
settings.pyの値を常に見れる
実行されたSQLを見れる
...などなど

16. RequestVarsDebugPanel
view関数
Cookieの値
Sessionの値
GET / POST パラメーターの値

17. TemplateDebugPanel
使われたテンプレート
渡された引数
コンテキストプロセッサーとそこで渡された値

18. Settings Panel
有効なsettigsの値
特にsettingsを分割/構造化してるときに有効

19. SQL Panel
実行されたSQLを実行時間でガンドチャート表示
取得された各カラムの値

20. Panelを追加する
django-debug-toolbarのパネルは標準以外もある
Memcacheへの入出力を見るパネルなど

21. django-debug-toolbar
アプリケーションの状態を表示してくれる
ボトルネックの発見もできる

22. django-pdb
Djangoでpdbを賢く使えるツール

23. django-pdbの良い点
コードを弄らずview内でデバッガーを走らせる
テストで落ちたらpdbを走らせる
テンプレート内でpdbを走らせる

24. ?pdbゲットパラメータ
pdbを実行したい画面に ?pdb というパラメータをつけて実行
view callableが呼ばれた時点からpdbが走る

25. runserverで落ちたらpdb
runserver --pm
runserver実行時に落ちたらpdb

26. テストで落ちたらpdb
manage.py test --pdbで実行
テストが落ちたら､落ちた時点からpdb実行

27. テンプレート内でpdb
{{ variables|pdb }}で実行
debug-toolbarで細かく見れなかった値をみるのに有効

28. django-pdb
pdbを欲しいときに楽に走らせられるツール

29. django-devserver
debug-toolbar同様デバッグ情報の出力

30. 出力先はコンソール
debug-toolbarと違いテンプレートが不要
API(テンプレートを使わないもの)でも有効
JSが走らないので画面の邪魔にならない

31. runserver --werkzeug
エラー時にWerkzeugのインタラクティブなデバッガーが使えます
runserverplusのためにdjango-extensions入れるより良い

32. 最近知ったばかりなのであんまり詳しくないです

33. logging

34. loggingについて
ここまでは夢のツールのお話でしたが
ここからはloggingのお話です

35. loggingすると良い点
状態を追える(デバッグ/障害時有効)
アラート/通知をすれば問題に即時対応
集約すれば傾向分析

36. 正しいロギングはどちらでしょうか
1. logger.error('Invalid code: %s' % 'azunyan')
2. logger.error('Invalid code: %s', 'azunyan')

37. 2が正しいです
logger.error('Invalid code: %s', 'azunyan')

38. 理由: ログ集約
第一引数のメッセージで同一ログと判断できます
logger.error('Invalid code: %s', 'azunyan')
logger.error('Invalid code: %s', 'miotan')

39. アンチパターン
logger.error('Invalid code: azunyan')
logger.error('Invalid code: miotan')

40. loggingに重要な点
正しく使う
ログレベルの認識を一致させる
ログの頻度の統一

41. 各ログレベルの使うべき状況
debug
info
warning (=warn)
error
critical (=fatal)

42. debug
開発時の値の追跡
printするなだdebugログ

43. info
動作の追跡
バッチなどの開始 / 終了
件数などの数字 (取り込み件数)
想定した動作だが残しておきたい情報
想定の範囲内でのスキップ動作

44. waring
機能は動作してるけど間違ってる
バッチは死んでないが処理に漏れ
バリデーションエラーくらいの問題

45. error
1機能が動作しない
500エラー(1画面/1機能で問題)
1つのバッチが落ちる

46. critical
複数/全機能に問題
想定しないよね

47. error => エラー通知メール
warning => ログ集約の対象
info => ファイル出力
debug => 開発時コンソールのみ

48. まとめ
ログを書きましょう(とくにバッチ/非同期処理)
ログレベルを理解/プロジェクトで共有しましょう
ログの頻度を各アプリで統一しておきましょう

49. and more
Pycharm: Python向けIDE(IntelliJ)
Sentry: ログ収集プラットフォーム

50. まとめ
デバッグには何が起こってるかを知るのが大事
ツールを正しく使えばデバッグの負荷を軽減できる

51. 最後に
PyconAPAC 2013のPythonコミュニティに対する多大なる貢献に感謝します

52. 3日目のSprintDayにDjangoSprintやるよ

53. 以上､ "Django最速デバッグ指南" でした
@hirokiky
hirokiky.org