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