Django *

Доброе время суток, уважаемые читатели!

Ниже приведена увлекательная(?) история о том как наша организация решала проблему т.н. «деплоймента как у людей». Наш основной язык разработки Python, с примесями разных интересных (и не очень) пакетов (Django, Bottle, Flask, PIL, ZMQ, и т.д.).

Начнём с краткого описания одного из наших приложений:

• Django 1.4
• MySQL
• Celery для крон-имитации и поддержки вспомогательных функций в фоновом режиме
• Daemon-процесс, основанный на Django management command

Всё это дело работает под связкой gUnicorn и nginx, на ОС CentOS 5.8.

Детали, как принято, ниже.

В Островке есть два основных продукта: для пользователей (ostrovok.ru) и «админка» для отелей (экстранет), куда подписанные нами отели заносят данные. Это отдельные продукты, со своими командами и различным отношением к разработке через тестирование (TDD). Одинаковая платформа: django и postgres. В экстранете используют TDD и у них куча тестов. Поначалу тесты были и в ostrovok.ru, но ввиду ухода части адептов в экстранет и очень интенсивного развития их перестали поддерживать. В общем передо мной встала задача внедрить тестирование. Первые шаги сделаны и хочу поделиться этим опытом и решениями, которые были применены.

У нас есть отдел QA и Selenium автотесты, но это отдельно.

С django и тестами вообще дела обстоят довольно хорошо и конечно лучше с самого начала все покрывать тестами, наращивая функционал и делая рефакторинги.

В нашем случае уже существовал огромный функционал и очень много всесторонних зависимостей и интеграции с внешними API. И нужно, чтоб это все работало в тестовой среде. Про быстрый SQLite в памяти можно забыть, в проекте есть привязки к особенностям postgres, да и идентичность тестового окружения все-таки важна, поэтому тесты тоже работают на postgres.

Рассуждаем про декораторы

Каждый из нас не раз использовал декоратор login_required и скорее всего писал похожий декоратор(скажем для проверки пустая ли корзина). Давайте рассмотрим что делает данный декоратор:

Всем тем кто делает сайты с использованием фреймворка Django (и тем-более если частенько приходится делать магазины), не понаслышке знакомы такие проекты как satchmo, lfs, satchless, django-shop, cartridge, plata и другие. Относительно недавно эти ряды пополнил Oscar.

За время использования Django я накопил множество небольших инструментов: декораторов, шорткатов, кастомных полей и просто утилит, которые кочевали со мной из проекта в проект в виде сборного пакета handy. В конце концов, я решил поделится своим опытом, потому как такой код — это и есть материализованный опыт (даже лучше — код можно исполнить), и открыть наиболее полезные куски handy для всех желающих.

Пакет направлен на уменьшение необходимого boilerplate при использовании фреймворка джанго. На то, чтобы избавить от необходимости писать одно и то же раз за разом, сделать код короче и выразительней.

Наверное всем известно, что Django является одним из самых популярных фреймворков для web-разработки на python-е. И даже если в основе web-проекта лежит сторонний код, то зачастую при разработке используют отдельные части этого фреймворка — например ORM. В данной статье я хотел бы рассказать об особенностях использования Django ORM при работе с базой данных MySQL, а именно про транзакции и подводные камни, связанные с ними. Так, например, если в какой-то момент вы осознаёте, что вместо ожидаемых данных, возвращается совершенно другой результат, то возможно, данная статья поможет разобраться что к чему.

Разработчикам, не сидящим все время под windows, но иногда там появляющимся оная операционка частенько преподносит сюрпризы. Столкнувшись с одним из них спешу поделиться, ибо метод лечения крайне неочевиден. На понимание, что ни Django ни ваш код не виноваты может уйти не один час…

Еще с давних времен, когда интернет был молодым и медленным, самым распространенным браузером был не IE, а Mosaic, в интернет не ходили, а дозванивались… меня часто мучал вопрос — почему в файловых диалогах можно выбрать всего один файл? Почему если в форме есть три файловых поля, то в каждое из них надо тыкать? Неужели нельзя удобнее?
Шло время, появился javascript, CGI, но файлополя были все также эгоистичны. Потом появился флеш, html5, ситуация начала меняться, но… Файловое поле имеет ту-же самую суть — файл, а не файлы! Хотя есть множество обходных методов…

Все знают, что такое кэширование и зачем оно нужно. Посещаемость растет, нагрузка на базу данных увеличивается, и мы решаем отдавать данные из кэша. В идеальном мире, наверное, для этого будет достаточно добавить строчку USE_CACHE = True в settings.py, но пока это время не пришло, понадобится немного больше телодвижений.

Когда мы собираемся использовать кэш в Django, нужно сделать выбор: взять готовое решение, которое сделает сделает все «за кулисами», либо реализовать свое. В отличие от многих других ситуаций, тут этот выбор не так очевиден, так как в существующих на сегодня готовых решениях довольно много ограничений и потенциальных неудобств.

Сначала мы быстро рассмотрим готовые решения, а потом разберемся, как же лучше реализовать кэширование самостоятельно.

OK, it's live!

github.com/django/django

28 апреля Эдриан Холовати (Adrian Holovaty) сообщил в рассылке для разработчиков Django, что основной репозиторий кода был перемещён на GitHub. С этого момента коммиты в subversion больше не принимаются. В качестве багтрекера будет по-прежнему использоваться Trac, но pull запросы средствами GitHub всячески приветствуются. Ура!

подробности: groups.google.com/group/django-developers/browse_thread/thread/f7ef8fe7b7b3c81b

Пару лет назад посчастливилось мне иметь блог на WordPress. До наших дней блог, как и вся база постов к моему сожалению не дожила, но рассказать я хочу не о самом блоге, а о том с помощью чего вся информация публиковалась. В то время Microsoft не так давно запустила Windows 7, а вместе с ней и пакет приложений Windows Live. Вот и я решил взглянуть – чего в этом пакете вкусного? Больше всего мне приглянулось приложение Windows Live Writer – программа позволяющая набирать и форматировать тексты, и публиковать их в блог. Удобный интерфейс, множество инструментов для форматирования, возможность хранить черновики локально, и многое другое – я влюбился. Спустя некоторое время свой блог без Windows Live Writer я уже не представлял.

Недавно запустили сервис по бронированию ресторанов ПанГурман. Внутри это более-менее типичный django-сайт. Попробую рассказать, как там что устроено (с картинками). В статье не будет ничего супер-хитрого, но, надеюсь, кому-нибудь пара трюков или идей покажутся полезными и как-то упростят жизнь.

Под катом много букв, но не беспокойтесь — вы всех их знаете.

Вебразработчики частенько сталкиваются с классической задачей определения местоположения пользователя по его IP-адресу. Существует множество различных решений, например на основе мировой базы Maxmind Geolite или российской IpgeoBase. Все они обладают достаточно низкуровневыми API, ну оно и понятно: на входе айпишник, на выходе страна, либо город и, если повезёт, ещё какая-нибудь полезная информация.

У всех сайтов с GeoIP, которые мы запускали, есть общая черта: они не только нуждаются в простой геолокации, необходимо также выводить различный контент на сайте в зависимости от месторасположения пользователя. Чтобы упростить для себя эту задачу мы написали небольшую батарейку django-geoip, вдохновившись приложением django-ipgeobase.

В пятницу, не смотря, что она была еще и 13 апреля, команда создающая PyCharm, передовую IDE для Python от JetBrains, выпустила очередное обновление своего продукта — версию 2.5.
В этот релиз вошли важные нововведения по работе с Python-окружением и не только:

Привет. Была поставлена задача реализовать геолокацию (google maps v3) для пользователей в одном из проектов на django, хочу поделиться своим решением.

Необходимый функционал:

1. Вывод карты с маркером текущего положения, возможность перемещать маркер (dragged), ставить по click событию
2. Поиск по адресу (autocomplete)
3. Сохранение как координат, так и самого адреса (если он имеет место быть)

Добрый день.

Часто возникает необходимость иметь пользовательские (административные) настройки сайта, которые не могут быть определены в settings.py по двум простым причинам: настройки из settings.py не могут быть изменены без перезапуска сервера; и — самое главное — они могут быть изменены только программистом.

Модуль django-dbsettings (бывш. django-values) призван избавить Вас от этих ограничений: он предоставляет механизм хранения пользовательских настроек в базе данных, а также удобные виды для их редактирования.

И вроде бы все отлично… НО! Что же делать, если в качестве настройки нужна будет картинка: например, логотип сайта? Как выяснилось, django-dbsettings не поддерживает такого типа значений.

О том, как я добавлял поддержку ImageValue в django-dbsettings, я и собираюсь поведать.

Апрельская скидка на PyCharm. До 16 апреля 30% скидка.

Mock на английском значит «имитация», «подделка». Модуль с таким названием помогает сильно упростить тесты модулей на Питоне.

Принцип его работы простой: если нужно тестировать функцию, то всё, что не относится к ней самой (например, чтение с диска или из сети), можно подменить макетами-пустышками. При этом тестируемые функции не нужно адаптировать для тестов: Mock подменяет объекты в других модулях, даже если код не принимает их в виде параметров. То есть, тестировать можно вообще без адаптации под тесты.

Такое поведение — уже не надувные ракетные установки, а целая надувная земля, вокруг которой могут летать испытуемые ракеты и самолёты.

О новых фишках, изменениях, несовместимостях со старыми версиями Django и Python можно почитать тут.