Comments 32
Пользуюсь форком этого замечательного тулбара — в нем немного меньше багов чем в оригинале. Правда недавно вылезла пренеприятнейшая особенность — при включеном тулбаре отваливается jquery.ui и jquery плагины.
в форке какой-то совсем ерундовый sql-модуль. Или я что-то не понимаю?
Форк запросы и Explain показывает на одной странице, нормально форматирует запрос. Не может выполнить запрос и сделать SQL-профайлера нет. Правда, не знаю, насколько он необходим… Пользовался пару раз всего.
Зато есть настоящий профайлер Python.
Только его нужно отключать иногда — с ним всё работает в 8 раз медленнее.
Зато есть настоящий профайлер Python.
Только его нужно отключать иногда — с ним всё работает в 8 раз медленнее.
+ 1
в debug-toolbar'е мне пришлось сразу переделывать стили, т.к. он отображался некорректно, в отличии от форка, да и немного удобнее он будет…
в debug-toolbar'е мне пришлось сразу переделывать стили, т.к. он отображался некорректно, в отличии от форка, да и немного удобнее он будет…
Спасибо, добавил в статью. Интерфейс впечатляет. И заработал без изменений в коде. Про jquery-плагины пока не смотрел…
В Symfony это было года 3 назад точно.
В Симфони чтоб выбрать больше одного объекта (разные таблички) в одном запросе — надо парсить руками через doSelectRC, тоесть еще хуже чем просто руками сделать запрос и непонятнее (да еще и надо за порядком следить, а если критерии взбредит выбрать после апдейта не «книги, читатели» а «читатели, книги» то всё поломается при hydrate'е).
хорошая штука, только, помню, с mootools она не подружилась, приходится на время отладки js отрубать из шаблонов
Спасибо большое, очень не хватало такой вещи.
Проблеммы
Проблемы
я один после прочения полез смореть https://dev.google.com?
а вот меня наличие жиквери на странице сильно огорчает. переписываю под мутулз.
Поставил форк, так как интерфейс больше понравился :) В джанго новичок, но думаю надо к отладке привыкать. Тем более люблю когда все под контролем.
Почему всегда, когда я что-то хочу установить и попробовать, на хабре появляется подробный ман по этому. Хабр читает мои мысли? Спасибо ^__^
Такой вопрос:
Насколько правильно, в плане производительности, писать подобные конструкции в коде проета?
if DEBUG:
Я имею ввиду не только Settings, но и повсемесно в коде
if DEBUG:
logging.info('опять упала !')
Насколько правильно, в плане производительности, писать подобные конструкции в коде проета?
if DEBUG:
Я имею ввиду не только Settings, но и повсемесно в коде
if DEBUG:
logging.info('опять упала !')
В данном случае использование if DEBUG совершенно оправдано: мы включаем консоль только в режиме отладки.
А насчет использования в коде — точно не знаю. Нужно потестировать. Возможно, поможет вывод сообщений с разными уровнями отладки…
Я еще не привык ловить такие мелочи (как, например, в статье по аналогичной проблеме в Perl). Мне вообще очень странно и непривычно, что страница генерится 43 миллисекунды, а не 2 секунды :-)
А насчет использования в коде — точно не знаю. Нужно потестировать. Возможно, поможет вывод сообщений с разными уровнями отладки…
Я еще не привык ловить такие мелочи (как, например, в статье по аналогичной проблеме в Perl). Мне вообще очень странно и непривычно, что страница генерится 43 миллисекунды, а не 2 секунды :-)
А насколько корректно использовать для объектов, которые разные в debug и production просто паттерн strategy? Ну и менять стратегию для дебага и продакшна.
Ну и вообще, более глобальный вопрос. Насколько полезно писать полностью-ООП программы на питоне?
Когда-то я написал полностью-ООП движок для PHP, чем-то походящий на Turbine под Java. Искоренил «скриптовый» подход везде где можно, остались только классы организованные по базовым паттернам. Потом свершилась работающая версия… увидел сколько времени всё это выполняется, и выбросил код в помойку.
Когда-то я написал полностью-ООП движок для PHP, чем-то походящий на Turbine под Java. Искоренил «скриптовый» подход везде где можно, остались только классы организованные по базовым паттернам. Потом свершилась работающая версия… увидел сколько времени всё это выполняется, и выбросил код в помойку.
конкретно в случае logging стоит писать logging.debug('опять упала!')
уровень выводимых сообщений настраивается
уровень выводимых сообщений настраивается
Верно говорят про logging.debug('опять упала !'), но не стоит, конечно, передавать ему какой-нибудь объект, который при str() выдаст простыню на 100 килобайт и задумается на две секунды.
Архикрутая вещь. Спасибо огромное за обзор.
Шикарно, множество print в коде исчезнут :)
«Жепь ебрило» :) отлично
Спасибо за обзор.
Спасибо за обзор.
Спасибо, это спасет кучу нервов и драгоценного времени.
За такой интерфейс отладчика кто-то мог бы продать душу дьяволу! Нужно попробовать.
Ха, по сравнению с внешним вид нынешнего, на ноябрь 09, стандартного, не-форкнутого дебаг тулбара (0.8.х) это — просто крокодил. Штука стала выглядеть ГОРАЗДО круче
Sign up to leave a comment.
Отладка в Django