Django最速デバッグ指南 PyConAPAC 2013

Preview:

DESCRIPTION

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

Citation preview

file:///home/hirokiky/Dropbox/sides/reveal.js­2.5.0/slides/pyconapac2013.html#/

Django最速デバッグ指南@hirokiky

hirokiky.org

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

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

バグ

photo by Brian searle

不具合瑕疵

デバッグは何が起こってるのかを知ること

photo by m4tik

何が起こっているのかを知る自分が何をしたいかを明確にするその差分を埋める修正をする

内容前置き: 5分デバッグ用ツール紹介

django-debug-toolbar: 10分django-pdb: 10分django-devserver: 5分

Logging: 10分

自己紹介 (ふつう)

21歳ドールと暮らしています

@hirokiky

Django好きです

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

自己紹介 (まじめ)

日本で4人目の 本体の貢献者の運営

仕事は でDjango/Python

Djangodjangoproject.jp

BePROUD Inc

最近作ったライブラリ紹介django-websettings

settings.pyライクなものWebインタフェースから設定値を編集できる

Django最速デバッグ指南

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やるよ

以上、 "Django最速デバッグ指南" でした@hirokiky

hirokiky.org

Recommended