django最速デバッグ指南 pyconapac 2013
DESCRIPTION
Djangoアプリケーションを開発する際のデバッグ方法について紹介します。 標準のDebugモード以外に使える様々なサードパーティライブラリを中心に、 私が趣味/仕事でのDjangoアプリケーションを開発する通して学んだデバッグ方法を具体的に紹介します。 アプリケーション開発時の泥沼のデバッグ作業は誰しも避けたいものです。 その時間はたいてい無駄になりますし、開発者自身つらいものがありますね。 優秀なツール使い、その負担を軽減しましょう。 適切なロギングで、発生した問題に素早く対処できるようにしましょう。 このセッションでは少しでも開発の助けになるよう、 Djangoアプリケーションのデバッグ方法を紹介します。TRANSCRIPT
file:///home/hirokiky/Dropbox/sides/reveal.js2.5.0/slides/pyconapac2013.html#/
Django最速デバッグ指南@hirokiky
hirokiky.org
目的Djangoでの開発を早くするデバッグに疲れないようにする問題に素早く対応する
対象Webアプリ開発をしたことがあるDjangoで開発をしたことがある
デバッグは何が起こってるのかを知ること
photo by m4tik
何が起こっているのかを知る自分が何をしたいかを明確にするその差分を埋める修正をする
内容前置き: 5分デバッグ用ツール紹介
django-debug-toolbar: 10分django-pdb: 10分django-devserver: 5分
Logging: 10分
Django好きです
フルスタックで必要なものが揃ってて各コンポーネント間で統合されていて早く開発できる
自己紹介 (まじめ)
日本で4人目の 本体の貢献者の運営
仕事は でDjango/Python
Djangodjangoproject.jp
BePROUD Inc
最近作ったライブラリ紹介django-websettings
settings.pyライクなものWebインタフェースから設定値を編集できる
Django最速デバッグ指南
デバッグ用ツール紹介django-debug-toolbardjango-pdbdjango-devserver
django-debug-toolbarとはデバッグ情報を常に表示するツールバー
django-debug-toolbarの良い点リクエストのヘッダ/パラメーターなどが見れる使われたテンプレートとコンテキストを見れるsettings.pyの値を常に見れる実行されたSQLを見れる...などなど
RequestVarsDebugPanelview関数
Cookieの値
Sessionの値
GET / POST パラメーターの値
TemplateDebugPanel使われたテンプレート
渡された引数
コンテキストプロセッサーとそこで渡された値
Settings Panel有効なsettigsの値
特にsettingsを分割/構造化してるときに有効
SQL Panel実行されたSQLを実行時間でガンドチャート表示
取得された各カラムの値
Panelを追加するdjango-debug-toolbarのパネルは標準以外もある
Memcacheへの入出力を見るパネルなど
django-debug-toolbarアプリケーションの状態を表示してくれるボトルネックの発見もできる
django-pdbDjangoでpdbを賢く使えるツール
django-pdbの良い点コードを弄らずview内でデバッガーを走らせるテストで落ちたらpdbを走らせるテンプレート内でpdbを走らせる
?pdbゲットパラメータpdbを実行したい画面に ?pdb というパラメータをつけて実行
view callableが呼ばれた時点からpdbが走る
runserverで落ちたらpdbrunserver --pm
runserver実行時に落ちたらpdb
テストで落ちたらpdbmanage.py test --pdbで実行
テストが落ちたら、落ちた時点からpdb実行
テンプレート内でpdb{{ variables|pdb }}で実行
debug-toolbarで細かく見れなかった値をみるのに有効
django-pdbpdbを欲しいときに楽に走らせられるツール
django-devserverdebug-toolbar同様デバッグ情報の出力
出力先はコンソールdebug-toolbarと違いテンプレートが不要
API(テンプレートを使わないもの)でも有効
JSが走らないので画面の邪魔にならない
runserver --werkzeugエラー時にWerkzeugのインタラクティブなデバッガーが使えます
runserverplusのためにdjango-extensions入れるより良い
最近知ったばかりなのであんまり詳しくないです
logging
loggingについてここまでは夢のツールのお話でしたが
ここからはloggingのお話です
loggingすると良い点状態を追える(デバッグ/障害時有効)アラート/通知をすれば問題に即時対応集約すれば傾向分析
正しいロギングはどちらでしょうか1. logger.error('Invalid code: %s' % 'azunyan')2. logger.error('Invalid code: %s', 'azunyan')
2が正しいですlogger.error('Invalid code: %s', 'azunyan')
理由: ログ集約第一引数のメッセージで同一ログと判断できます
logger.error('Invalid code: %s', 'azunyan')logger.error('Invalid code: %s', 'miotan')
アンチパターンlogger.error('Invalid code: azunyan')logger.error('Invalid code: miotan')
loggingに重要な点正しく使うログレベルの認識を一致させるログの頻度の統一
各ログレベルの使うべき状況debuginfowarning (=warn)errorcritical (=fatal)
debug開発時の値の追跡printするなだdebugログ
info動作の追跡
バッチなどの開始 / 終了件数などの数字 (取り込み件数)
想定した動作だが残しておきたい情報想定の範囲内でのスキップ動作
waring機能は動作してるけど間違ってる
バッチは死んでないが処理に漏れバリデーションエラーくらいの問題
error1機能が動作しない
500エラー(1画面/1機能で問題)1つのバッチが落ちる
critical複数/全機能に問題想定しないよね
error => エラー通知メールwarning => ログ集約の対象info => ファイル出力debug => 開発時コンソールのみ
まとめログを書きましょう(とくにバッチ/非同期処理)ログレベルを理解/プロジェクトで共有しましょうログの頻度を各アプリで統一しておきましょう
and morePycharm: Python向けIDE(IntelliJ)Sentry: ログ収集プラットフォーム
まとめデバッグには何が起こってるかを知るのが大事ツールを正しく使えばデバッグの負荷を軽減できる
最後にPyconAPAC 2013のPythonコミュニティに対する多大なる貢献に感謝します
3日目のSprintDayにDjangoSprintやるよ