Programming by Python, JavaScript, ActionScript, PostgreSQL, MySQL for Game Creation and Web Develop. Also about Open Source, Debian and Project Management.
Мы продолжаем дарить добро.
А от какого гемороя избавляют эти красавцы – догодайтесь сами. Обязательно курить вместе со “4мя css строчками счастья”
Tags: django, django-admin, JavaScript, JQuery, Python
Меня за….ло скролить длинные админки туда-сюда ради сабмита и вот
И панель наконецто просто начинает за вами кататься
А чем ты занимаешься в свой выходной? 
В Django есть такая удобная вещь для написания тестов — это fixtures. Удобство состоит в том, что ваши тесты могут входить в уже заполненный данными проект. Например тестируем работу админчасти статистики, надо иметь готовый массив данных, с которым оперируем и проверяем результаты. Неудобство состоит в том, что эти фикстуры надо где взять, надо поддерживать актуальными, такими-же актуальными как и тесты. Вот как раз и про неудобную часть, а также паре подводных камней я бы и хотел вам рассказать.
Рассказывать, что это означает я не буду, но то есть хорошая документация по фикстурам у самой Django .
Я «обплетал» тесты уже готового написанного проекта. В нагрузку с проектом идет дамп базы, которая, как это не удивительно, может быть не целостная. Самый часты бок — это когда записи по форенключу нет. Например у Вас есть профиль, но нет юзера или есть транзакция между не существующими счетами.
Самое обидное, что Джанго Вам не поможет решить эту проблему. И получите что-то типа
Error: Unable to serialize database:
Нагугил тикет в Django Code:
https://code.djangoproject.com/ticket/6773
К которому прилагается команда, которая показывает Вам «разбитые модели», т. е. модели не полные с неверными данными в ForeignKey .
Я ее немного приукрасил возможностью удалять их автоматом https://gist.github.com/1018947. Для реальных данных удаление автоматом — это не очень обдуманный шаг, но мне сейчас надо получить хоть какую-то фикстуру.
Для поддержки актуальности базы между всеми разработчиками используется django-south, мне кажется это уже давно стало стандартом Django разработки. Тот же механизм можно использовать для поддержки актуальности с фикстурами, поэтому я одну фикстуру полностью перегоняю в sqlite3 базу, которую как и фикстуру держу в репозитарии проекта и для доступа к которой использую отдельный сетингс.
Сеттингс файл для этого состоит из 3х строчек (settings_lights.py):
Как известно, в любую команду можно передать не стандартное имя сетингс модуля.
Например, для того, чтоб запустить его и добавить новых данных:
А поддерживать актуальность фикстуры можно через миграции, которые вы создаете после изменения структуры базы
Для тестирования я использую тот-же settings_lights.py для того, чтобы использовать sqlite3 в тестах, при этом для тестов вся база будет держаться в памяти, что существенно ускорит процесс написания тестов и тестирования их.
Но я думаю как финальную проверку, после того, как вы закончили с разработкой ( доработкой ) тестов можно использовать и реальный Engine.
А собственно сам текст тестов может выглядить так:
Этот пример ничего не тестирует, а просто показывает Вам, что данные на момент запуска тестов в базе уже есть. Фикстуры можно хранить как в папке fixtures любой апы, не только тестируемой. А еще в сетингсах можно прописать:
Про сигналы в Django вы можете почитать в документции.
Фикстура — это по сути сериализация ОРМ объектов, т. е. объект будет сохранен как json, как просто текст. А значит загрузка из фикстуры — это поочередное добавление всех объектов, а добавление объектов связано с вызовом сигналов, которые в свою очередь могу сами создавать объекты моделей или изменять существующие.
Например. У Вас есть 2 модели счета и транзакции. При добавлении транзакции — дергается сигнал, по которому изменяются балансы счетов участников этой транзакции. При подготовке фикстуры вы создали одну транзакцию между двумя счетами на сумму 100 рублей, т. е. после ее проведения на одном счету прибавится 100 рублей, а на другой вычтится. Вы сохраните полученные данные в файл фикстуры, в которой будут готовые записи со счетами и транзакциями. Во время тестирования этот файл будет загружаться и вначале загрузятся модели счетов – на одном 100, на другом -100. После загрузятся транзакции и дернут сигнал, который еще раз изменит балансы на счетах и мы во время тестирования увидим состояния на счетах 200 и -200.
Решение у джанги есть , но почему-то не документированное, и как по мне — очень не удачное.
В обработчик сигнала передается параметр raw который True во время загрузки фиксутры.
Так что, если вы не хотите, чтоб обработчик сигнала работал в момент загрузки фикстуры, то первые 3 строчки вашего обработчика могут выглядит так:
Как по мне — это недокументированную возможность надо огромными буквами задокументировать в обоих разделах — тесты и сигналы, но я думаю будут решения и лучше этой проблемы.
У меня все. Я описал то, как с фикстурами работаю я, и очевидно, что они могут сэкономить очень много времени Вам при разработке тестов, а также могут помогать Вам делать более качественные и реальные тесты.
Хотелось бы в комментариях увидеть критику такого подхода, дополнения, подводные камни, с которым вы сталкиваетесь. Буду дополнять статью Вашими цитатами и идеями.
Спасибо, и удачных Вам выходных.
при создании нового джанго проекта я всегда выделяю две папки apps – для моих апов и compat – для сторонних апов, к разработки которых я не имею никакого отношения. Идея в том, что эти апы всегда остаются неприкосновенными для меня, и единственной точкой расширения остаются сеттингсы и возможно доп параметры, при инклюде урлов.
А представьте, что вы создаете апу с именем catalog, ее вы потом хотите выложить в общее пользования, и необходимо для нее сделать больше точек расширения. Структура такого апа может быть
для 4 первых файлов можно просто вконце файла добавить строку, которая станет универсальной точкой расширения. Например для views.py
таким образом, если кто-то будет использовать Вашу апу — точкой расширения будет дополнительная апа ex_catalog, в котором вы можете переопределить некоторый функции из view.py, и при этом ex_catalog не надо добавлять в список апов в настройках.
А теперь главный вопрос этого поста. Почему так не делают?
Сложные выборки. Например, какая-то страница результатов. Там где много-много фильтров, + еще какие-то сортировки появились + все это надо прогнать через пейджирование. Выглядит страшно, но тем не менее задача банальная. Меня в этой задаче больше всего расстраивает шаманство с урлами. Ведь по факту Вам все эти параметры выборки надо уместить в урл, и каждой функции, например, смены страницы или смены направления сортировки — надо переформировать ссылку.
Через несколько минут у меня появился тег, который как всегда выношу на Ваш суд. Перед просмотром исходников, покажу, как он работает:
тут мне уже не нужно думать, о том, как сформировать урл, я просто знаю, что эта ссылка пейджирования должна просто изменить параметр пейдж и все, весь остальной урл доформировывается отталкиваясь от текущего.
Исходники чуда тега можно увидеть тут.
Пока в голове крутится одна проблема, не очень актуальная но тем не менее. По средствам этого тега пока нельзя сформировать урл, который удалит один параметр из текущего урла.
Прям сначала пришла в голову идея реализации такой фишки, но предварительно порыл в исходники джанги, дабы удостоверится, что не мастерю лисипед. Оказалось таки мастырю.
В Джанго есть MultiWidget, при инициализации которого можно указывать массив виджетов, которые будут принадлежать одному полю и выведены в ряд. При этом значение, возвращаемое этим виджетом – очевидно будет массив.
Правда просто так он почему-то не захотел работать. Разработчики почему-то захотели, чтоб его использовали всегда только как базовый класс, а не как конечный, и требуют переопределения decompress. Поэтому переопределив его мы сделали конечный и многоразового использования.
Ниже пример поля с датой из 3х выпадающих списков:
Сегодня рано утром вернулся с pycamp, который прошел в Киеве 30ого января в учебном центре i-klass.
Организаторы сказали, что это их первая попытка организовывать подобные мероприятия, и как по мне — у них для первого раза получилось довольно не плохо, правда розеток было мало, поэтому моя 17ти дюймовая малютка держалась на аккумуляторах.
Доклады мне понравились не все, но негатив я высказывать свой не буду, поэтому просто небольшой обзорчик того, что понравилось и запомнилось.
Александр Шигин (гость из солнечного Рамблера) «Почему Python — тормоз и как заставить его меньше тормозить». Были небольшие обзорчики кода, со сравнениями производительности. Сравнение результатов работы алгоритмов, реализованные разными способами — картежи, дикты, классы. Первые быстрее, но мы и так это знали. Хотя местами были довольно интересные результаты. Был упомянут Cython, но только вскользь, хотя мне бы тема была куда интереснее. Так что после в кулуарах мы написали небольшой хелло ворлд на cython, получили сошник и заюзали в самом питоне.
Кратко выглядит примерно так
ваш скрипт
скрипт setup.py:
получаем сошник
и дальше его используем в ваших скриптах.
Но также не забываем, что у него есть ограничение, т.е. не любой питонячий код вы можете откомпилить – генераторы, вложенные функции, локалсы, глобалсы вы юзать не можете и небольшие ограничения в определениях классов.
Для себя отметил, что им как раз можно пользоваться для оптимизации питонячего кода практически без ограничений в использовании приятного синтаксиса питона. У себя в бложке буду освежать свои успехи в этом деле.
Юрий Юревич «Рецепты декораторов». Лично для себя ничего нового не увидел, кроме того, что довольно грамотно все разложено по полочкам и что несомненно помогло упорядочить в голове знания.
Михаил Кашкин (замляк из Днепра) «Работа с хранилищами данных в Google App Engine, отличия от реляционной модели». Я Апсы еще не юзал вообще. Но в скором времени мне таки придется уткнуть свой нос у туда. И пока то, что я узнал — мне не очень понравилось. Реляционных БД там нет вообще. Только их не реляционная БД и мемкеш.
Мое первое впечатление — это модели бд, как в классической ОРМ, при этом кладутся данные в виде модели и в виде этой же модели забираются, с вытекающими ограничениями. Фишка которая сразу смутила весь зал — если вы копили-копили данные, а потом захотели добавить еще одно поле в модель, то старые данные, построенные на старой модели не обновятся, а нужно руками доставать каждого и задавать ему новое поле, и по словам Михаила — чем больше вы делаете выборку, тем дольше она получается.
В кулуарах мне рассказали немного больше о самом App Engine. Он не совсем на шару, а в нем есть лимиты, я пологаю, что лимиты на все. Причем при приодалении этих лимитов вам просто закрывают доступ к сайту, хотя по совести их просто надо не давать использовать больше. И хотя питон с джангой были первыми в арсенале App Engine – они там со своими ограничениями. Так что 40 минут доклада оставило для меня много вопросов.
Александр Соловьев. «Redis: Дикий Запад баз данных». Если коротко — то Redis — этот мемкешед, который сторит данные на винте с промежуточным хранилищем в памяти. С типами данными не только строки но и инты, листы, сеты. И с довольно обширным функционалом для их применения. Мастер-Слейв репликация, кстати только в этом наверно редис проигрывает мемкешу, т.к. мемкеш может использовать несколько серверов и данные между ними отлично распределять ( но редис держит данные на винте а не в памяти ). Ну и конечно же, Александр, как авторитетный велосипедист не мог не написать к редису чего-то своего pyredis ( питонячий клиент для редиса )
Не мог не оценить подачу материала Александром. Очень живо, я даже подумал что презентация получилась в стиле теле-магазина: «Вы хитите это — пожалуйсто — редис отлично с этим справляется, это – и это вы можете сделать как 2 пальца об асфальт и то и то…». Но я бы на его месте такой продукт подавал как Стив Джобс — Макбук Аир. «Представте систему, которая быстрее мемкеша но данные сторит на винте, с типизацией ячеек и т.д. и т.п. И в конце Редис» Ну что-то в этом стиле.
В любом случае, Александру спасибо. Будем смотреть, будем пробовать. Интересно, он кешовый бекенд для редиса на джанге уже написал?
Владимир Пузанов и Владимир Кирилов «Расширения и встраивание Python». Эти два молодых хакера рассказали о том где можно применять питон, с чем и как его можно связывать. Jython, IronPython и многое другое, что я еще не запомнил. Надеюсь где нить раздобыть их презентацию. Но для себя отложил Stackless Python — у него очень «крутые» треды, на сколько крутые — я уже буду пробовать ручками сам. И когда я говорю о Stackless мне уже какой раз предлогают глянуть на greenlet. Общее впечатление о докладе осталось очень хорошее – хороший обзор, живая подача материал и оставило много вопросов (как и должно быть в подобных докладах). В конце парни показали прикольный примерчик как они питоном хачат сафари и меняют в нем титл через его жсный движок. Хотелось бы ответить всем бегающим по залу участникам с вопросам «Нафига надо было хачить софари». Объясняю — просто так!!! Просто точка ( довольно прикольная ) в докладе о расширениях и встраиваниях питона, обидно, что многие из всего доклада запомнили только эту точку.
Андрей Мишковски «Использование Python в ГИС» . Проблематика Гиографические Информационные Системы для меня была нова, но подача информации была доступна и понятна даже слушателю не знакомым с темой. Так что если кто хочет может просмотреть презентацию, и дождаться выхода видео.
Сергей Кирилов. «WebSockets в twisted». WebSockets — это новое расширение протокола HTTP в сторону двухстороннего взаимодействия клиент-сервер с одним коннектом, которая описана в стандарте HTML5. Поддерживается пока не всеми ( поэтому пользуемся библиотечкой, которая подменяет стандарт для тех, кто его еще не поддерживает ). Я мог пропустить, но по моему twisted-у был отведен один слайд, на котором выведено 42 строчки кода и сказано, что их 42 Кстати нагугли и хабровскую статью на эту тему.
Не могу не оценить рисковый ход Сергея — реальная демонстрация продукта. Заработало почти с первого раза. У меня так никогда не получалось. Простенький чатик с инпутом и кнопочкой сабмит — впечатлил всех но не демострацией работы а то что почти все, у кого был ноут и получалось воспользоваться вайфаем — начали болтать и прикалываться друг с другом на большом экране, да так что в зале поднялся шум и гам, было очень весело, но по-моему не все успели задать вопросы.
Сергей, если у вас сохранилась копия этой болтавни в чате — выложите куда-то, было прикольно
И последний из понравившихся мне докладов был у Ивана Моргуна, сразу после нее я и убежал, т.к. надо было успеть на поезд обратно. Доклад был о «Работа с платежными системами в Django (PayPal, WebMoney)». Из джанго я ничего интересно для себя не вынес, но некоторые интересные моменты для PayPal подчеркнул.
Организаторам, спонсорам и докладчикам мероприятия огромное спасибо. У вас все отлично получилось. Давайте как нить повторим.
Еще о pycamp:
curvedbrain.org “Мысли по мотивам PyCamp Kyiv”
Макс Ищенко “мысли к вчерашнему pycamp”
Vladimir PyCamp впечатления
Дмитрий Гайворонский “PyCamp @ Kiev, 30 Jan 2010″
… пишите в комментах ссылки на свои посты о кемпе …
Видео с DjangoCon 2009.
Правда работы много, но буду как нить пробовать в перерывах проглядывать. Скажите, может кто-то смотрел уже. Что интереснее, а что на оборот, не стоит тратить времени.
Всем привет. Да, знаю, я давно не писал. Ну простите, и как это не банально, был занят. А заставила меня написать одна мысля. И пожалуйста, дочитайте это до конца, потому что или это очень круто или я опять что то не понимаю, и с температурой 38 мне лучше за клаву не садиться.
Кеш. Я им пользуюсь для того, чтобы данные, которые я долго вычисляю — положить в память куда нить, чтоб если они понадобились — быстро их оттуда взять. Ну а если их там нет, то просто пересчитать и положить. Если вы им пользуетесь также, то читайте дальше иначе напишите комментарий, который начнется со слов: «Тю, блин, а я его совершенно по другому юзаю, глянь…»
Т.е. на сетах и гетах все сводится к примерно следующему алгоритму.
где l_value — это ссылка на функцию, значение которой будет получено, в случае если его нет в кеше.
Вот этот умопомрачительный алгоритм у меня лежит в основе кеширования.
Хух… если у вас также, то идете дальше. Надеюсь сейчас осталось достаточно народу.
Прогуливаясь легкой и непринужденной походкой по блогосфере рунете я уже в который раз натыкаюсь на довольно странное решение следующей проблемы.
Если есть какие либо данные которые системе нужны часто, но вычисляются долго, то их прямое получение по алгоритму, описанному выше — просто убивает систему. Потому что как только они пропадают из кеша — все, кому нужны эти данные — начинают скопом — все вместе их получать. Например статистика по пользователям у вас вычисляется 5 сек, а выводится на главной странице, с посещаемостью 50 чел в сек, значит одновременно эти данные будут получать 250 процессов – что, может привести к смерти.
Решение рунета — 2 кеша. В один кладем с одним эксперейшеном, в другой с таким же, но чуть больше. Я думаю многие натыкались на такие решения, но вкратце — если заэкспаирилось в первом — берем из второго, но первый, кто узнал, о том, что заэкспаирилось — пересчитывает.
Тут просто тьма тьмущая узких мест
1.Старт у системы должен быть особый. Т.е. в нулевой точке в кеше уже должны быть часто доступные данные.
2.У вас двойные данные в кеше, т.е. две копии, а ведь часто бывает и такое, что трудновычисляемые данные — это и большие данные.
3.И последнее — если процесс, который вычисляет заекспаревшиеся данные — умирает. То умирают все. Явно теряем в отказоустойчивости.
Кратко опишу свой алгоритм решения, и построенный на нем джанговый кешовый бекенд (за базовый взят мемкешовый).
Если в ячейку с ключем класть не данные, а хеш из двух значений — данные, и время, когда их надо обновить. (ТАДАМ избавились от второго пункта)
А что если ты перед началом вычислений будеш класть в другой системый и уникальный ключ в кеше время, когда первый, начавший вычисления – планирует их закончить. А остольные процессы, которые захотят получить данные и не увидят их — смогут орентироваться на системный ключь, чтоб понимать, что данные скоро будут и их необходимо подождать или мы не дождались и попробуем еще раз. (ТАДАМ избавились от первого и третьего)
А теперь скучный код. Чтоб легче было читать — его необходимо скрестить с алгоритмом, который я описывал выше. И если функция гет — вернет None то эти данные сразу начнут вычисляться.
Небольшой рандом необходим, чтоб все процессы сразу не набросились вычислять после первого сдавшегося, а нарастающий таймаут необходим для быстрого избавления от быстрых данные и размеренного ожидания долгих.
И на всякий случай. Если вы все таки считаете это отличной идее. Кладем это в файлик с незамысловатым названием smart_cache.py рядом с settings.py, а в settings.py записываем
Recent Comments