За предвкушением 23-го февраля можно даже и не заметить, как вечер четверговых разговоров о шаблонизаторах для PHP может плавно перетечь в вечер пятничных.
В статье будет рассмотрено несколько тем, начиная с темы нужности шаблонизаторов вообще и в PHP в частности, и заканчивая заметками о процессе создания шаблонизатора dja (портировании кода с Python на PHP).
На практике пришлось столкнутся с некоторыми не очевидными особенностями производительности обработки шаблонов. Изучение вопроса породило небольшое исследование, результатами которого спешу поделиться.
Читать полностью »
В свежей версии PyCharm 2.7 команда разработчиков постаралась учесть пожелания сообщества, внесла несколько полезных улучшений и добавила поддержку свежей версии Django.
Более предметно:
В версии 2.7 PyCharm получил новую тему интерфейса в темных тонах (Darcula), знакомую по IntelliJ IDEA 12.
Если вы — счастливый обладатель новенького MacBook, то ваш глаз порадуют новые значки, разработанные специально для экранов Retina.
Близится тот волнительный миг, когда 23 февраля гостеприимный офис Ciklum распахнет свои двери перед участниками DneprPy#1.
Мы проведём Great Python Web Framework Showdown, где на примере одного проекта участники расскажут про свой любимый фреймворк:
за команду Django будут играть Андрей Ткаченко и Иван Колодяжный
знамя Pyramid будет нести Николай Скрыпник
честь Flask будет защищать Егор Назаркин
Сразу хочу попросить прощения за столь перегруженную статью, но для меня сейчас всё это актуально и связано. Думаю что некоторым это может пригодиться для будущей разработки. Хочу обратить внимание, что в этой статье я не стану рассказывать вам как устанавливать те или иные тривиальные вещи, установка которых, к тому же, зависит от той или иной платформы. Также в статье я не описываю телодвижения по настройке прав доступа к файлам сервера, опять же, это зависит от реализации. В статье описан процесс настройки на PDC сервер с именем tci.lan, все имена сохранены, в вашем случае их следует заменить на соответствующие вам. Данная статья содержит код, для улучшения читаемости он спрятан в спойлерах.Читать полностью »
После публикации на Хабре своей первой статьи, об одном из способов организации иерархии в реляционной БД, у меня осталось чувство не доведенного до конца дела.
Судя по комментариям, кто-то принимал предложенный метод за другой, спрашивали чем не устраивает “django-mttp”, рассказывали о поддержке деревьев в PostgreSQL…
Спасибо всем отписавшимся, но из-за сумбурного изложения в самой статье, думаю, что я не сумел донести до читателя то, что хотел. А “если я чего решил, то выпью обязательно”(с)
Поэтому, я решился на еще одну попытку изложения интересующего меня подхода. А именно — хранение иерархии в числовом коде, вычисляемом на основании данных о размерности дерева. То есть, заранее определены максимальные количество Уровней и количество Детей у каждого Родителя (возможные диапазоны достаточно велики, поэтому, заранее пугаться этого не стоит). При таких вводных, код, каждого иерархического элемента, будет являться и путем до него, и включать диапазон всех Детей. А это сулит скорость, и много еще чего…
Далее — с картинками и таблицами, без привязки к какой-либо БД (ибо это не важно). В конце статьи есть ссылки на реализацию на Django. Читать полностью »
Делая отладку производительности небольшого проекта, но с достаточно большой базой, столкнулся с неприятным спецэффектом.
Django при выборках с условиями по внешним ключам, связанным с проверкой на NULL, генерирует запросы, содержащие JOIN по каждому такому ключу. Читать полностью »
Есть множество способов организации иерархического хранения данных. В последнее время меня заинтересовал вопрос по структуре каталога, например, интернет-магазина. А именно, когда Группы и Товары хранятся в разных таблицах.
При навигации посетителя по Группам, должны выводиться Товары из всех Подгрупп.
Хотелось бы, имея код Группы, получить быстрый запрос к таблице Товаров, результатом которого были бы Товары из текущей Группы и всех ее Подгрупп.
Читать полностью »
.png "Django work flow (от создания до деплоя)")
Речь пойдет о быстром создании и деплое новых проектов, подробнее о том, как нужно экономить свое время.
Мы хотим, что бы начало нового проекта было максимально простым и удобным, как и его последующий деплой. В лучшем случаем нам бы хотелось иметь 3 кнопки: начать новый проект, задеплоить и обновить.
Эта тема не новая и уже достаточно освещена в разных аспектах, я лишь покажу свой вариант.
Для комфортной разработки нам понадобится: PyCharm (ну или какой другой редактор), Python (куда без него), fabric, virtualenv, git и pip.
Как известно, в Django предусмотрен очень лёгкий и простой механизм уведомления разработчиков о возникающих проблемах. Когда проект развёрнут на локальном компьютере и в настройках DEBUG имеет значение True, то отчёты об ошибках просто выводятся в виде HTTP-ответа, в виде удобной страницы с возможностью копирования traceback'а.
Если же это production-сервер, и DEBUG имеет значение False, то отчёты по умолчанию отправляются по электронной почте всем, кто указан в настройке ADMINS (кстати, если вы используете SMTP-сервер, то письма могут не приходить, так как SMTP-сервер не принимает адрес root@localhost — в этом случае просто укажите любой другой адрес, который будет принимать ваш SMTP-сервер, с помощью настройки SERVER_EMAIL).
Разумеется, ничего не мешает также написать свой logging handler (обработчик журналирования) и сохранять отчёты об ошибках в любом нужном виде — создавать задачу в баг-трекере, например.
Тем не менее, если для вас важна безопасность ваших пользователей, то возникает вполне закономерный вопрос — как сделать так, чтобы отчёты об ошибках были для них безопасны? То есть как сделать, чтобы никакая личная информация в них не сохранялась, и не отправлялась кому-либо по почте (ведь дело даже не в том, что кто-то из разработчиков может вести себя недобросовестно, а скорее в том, что подобную информацию вообще лучше не сохранять где-либо за пределами сервера — ведь почтовый ящик и взломать могут, а сервер обычно защищён лучше).
Читать полностью »
