Django | Все любят Одувана

Checkio.ORG

Subscribe to Posts

Blogroll

04Feb

4 js строчки счастья

Django View Comments
Мы продолжаем дарить добро.
1. django.jQuery(function(){
2. $('body').append('<iframe name="fast_save" width="1" height="1"></iframe>');
3. $('.submit-row').append('<input class="fast_save" type="button" value="Fast save">');
4. $('.submit-row .fast_save').click(function(){
5. $('#task_form').attr('target','fast_save').submit().removeAttr('target');
6. })
7. })
А от какого гемороя избавляют эти красавцы – догодайтесь сами. Обязательно курить вместе со “4мя css строчками счастья”
Share and Enjoy:
Rating 3.00 out of 5

[?]
Tags: django, django-admin, JavaScript, JQuery, Python
03Feb

4 css срочки к Django-Admin и и жизнь налаживается

Django View Comments
Меня за….ло скролить длинные админки туда-сюда ради сабмита и вот
1. .submit-row{
2. position: fixed;
3. z-index: 100;
4. left: 220px;
5. top: 0;
6. }
И панель наконецто просто начинает за вами кататься

А чем ты занимаешься в свой выходной?
Share and Enjoy:
Rating 3.00 out of 5

[?]
Tags: admin, django, Python
08Apr

UCSVLOG and GitHub продолжение

UCSVLOG View Comments
django-ucsvlog и django-ucsvlog-analytics также перехали на github. Код там не сильно грязный, но за усердную отчистку и покрытие тестами еще не садился.

у python-ucsvlog небольшое обновлени в формате логов. Т.к. формат строки через “%” – это прошлый век, и format рулит – темлпейт для имен файлов поменялся, так что теперь файл лога с дневным рендерингом будет выглядить примерно так /var/log/django/{year}-{month}-{day}.ucsv
Share and Enjoy:
Rating 3.00 out of 5

[?]
Tags: django, django-ucsvlog, django-ucsvlog-analytics, Python, python-ucsvlog, ucsvlog
04Apr

UCSVLOG kyivpy#6 – Как облегчают жизнь качественные логи. Часть 3. Плюшки

UCSVLOG View Comments
Продолжаем о UCSVLOG. Начало читайте тут – Часть 1. Проблема и Идея, потом тут мы продолжили – Часть 2. Решение , ну а сейчас о плюхах

Плюшки это типо сладости, которые тебе дают, если ты прилежно все делаешь. Так и с логами. Если ты правильно и аккуратно их пишешь – то в результате получаешь правильную и четкую аналитику любой сложности и не только.

django-ucsvlog

Проект лежит на bitbucket.org

Первым для себя применением ucsvlog я нашел в как апой к Django. Он был создан за долго до того, как у Django появились свои логи. И пока миграцию на них я не планирую, а думаю, как объеденить и взять что-то хорошее с джанговских и сделать процесс миграции с джанговских на UCSVLOG более простым.

Блоком в данном случае у нас будет запрос пользователя. Подключается с помощью одной или двух мидлварь, каждая из которых открывает блок.

Первая ‘djucsvlog.middleware.LogRequestInfo‘ идет как самой первой в Вашем списке мидлварь,а значит должна запускаться еще до того, как какая-либо из них начнет работать.

Она открывает блок, в который кладется информация о запросе, а в settings задается список полей которые мы хотим записываться, например имя домена, путь, гет, пост параметры, файлы или BROWSER_UUID_COOKIE.

BROWSER_UUID_COOKIE – это простой механизм, который по средствам кук следит за действиями пользователя. Когда приходит пользователь и у нег нет нашей куки – мы ему создаем ее и при каждом его запросе кладет ее в лог. Далее это позволит сводить свою аналитику.
Как дополнительная возможность – это вести лог файлов, которые аплоадит пользователей. Т.е. мы в отдельное место сохраняем все аплоады пользователей, а в логах отмечаем – что и куда мы сохранено.

Вторая ‘djucsvlog.middleware.LogViewInfo‘ записывается последней мидлварей, она опциональная, т.е. работать будет и без нее, сюда кладется инфа накопленная с других мидлварь, например информация о залогиненом пользователе или любая другая информация, которая может быть собранная уже с ваших мидлварь.

Последнее – это указать у себя в сетингсах шаблон имени файла UCSVLOG_FILE, и можно начинать играться.

Во время работы сам объект логера лежит в глобальной области видимости. Т.е. воспользоваться им можно в любой момент.

За время работы с django-ucsvlog у нас накопилось много настроек для кастомизации этих логов. Все они лежат в djucsvlog.settings.py немного документированные, в лучших традициях опенсорса, с указанием дефолтных значений. Такие как – правило формирования отчет об ексепшене, буферизация, правило определение IP пользователя, возможность сохранять отдельно загружаемые файлы, а в лог класть инфу о том, куда мы сохранили текущий загруженый файл.
+ UCSVLOG_CHANGE_MODEL в этом дикте можно указать – за изменением каких моделей вы хотите следить ( предварительно указав ‘djucsvlog.components.change_model’ в списке компонентов UCSVLOG_COMPONENTS ), и какие поля этих моделей вы хотите класть в лог файл в момент их изменения. Т.е. теперь благодаря логам вы можете связывать изменения любой модели с определенным пользователем – ваще мечта.

Пример settings.py вашего приложения:
1. MIDDLEWARE_CLASSES = (
2. 'djucsvlog.middleware.LogRequestInfo', ##первый
3. 'django.middleware.common.CommonMiddleware',
4. 'django.contrib.sessions.middleware.SessionMiddleware',
5. 'django.middleware.csrf.CsrfViewMiddleware',
6. 'django.middleware.locale.LocaleMiddleware',
7. 'django.contrib.auth.middleware.AuthenticationMiddleware',
8. 'django.contrib.messages.middleware.MessageMiddleware',
9. 'django.middleware.transaction.TransactionMiddleware',
10. 'djucsvlog.middleware.LogViewInfo', ## Второй
11. )
12. UCSVLOG_COMPONENTS = (
13. 'djucsvlog.components.change_model',
14. ) # указываем список компонентов ( расширений )
16. UCSVLOG_FILE_VERSION = 'v3' # о смысле такого хука мы расскажем позже
17. UCSVLOG_FILE = '/var/log/django/console-%(year)s-%(month)s-%(day)s-'+UCSVLOG_FILE_VERSION+'.ucsv'
19. # По умолчанию False тоже, но если мы хотим, чтоб логи не велись, а выводились в консоль то делаем тру
20. UCSVLOG_PRINT = False
22. # Эти поля будут класться в лог в момент закрытия блока запроса, т.е. в самом конце
23. UCSVLOG_RESPONSE_FIELDS = ['status','ctype','content']
25. # кастомные пользовательские функции для логирования
26. def server_ip(request,*args,**kwargs):
27. return request.META.get('REMOTE_ADDR', '0.0.0.0')
29. def ucsvlog_last_login(request,*args,**kwargs):
30. return request.session.get('last_login','')
32. # поля, которые мы созраняем при открытии реквеста ( в первой мидлвари )
33. UCSVLOG_REQUEST_FIELDS = ['http_host','browser_uuid','remote_addr',server_ip,\
34. 'path','get','post','save_files','http_user_agent',\
35. 'http_referer','http_accept_language']
37. UCSVLOG_VIEW_OPEN_FIELDS = ['userid',ucsvlog_last_login] # во второй мидлвари
38. UCSVLOG_RESPONSE_FIELDS = ['ctype','content','status','headers'] #при закрытии
39. UCSVLOG_REQUEST_REQ_REMOTE_ADDR_REAL_IP = 'HTTP_X_REAL_IP'
40. # каталог с исходниками, относительно него будет писаться инфа о вызове функций
41. UCSVLOG_RELATED_FOLDER = PRJ_ROOT
Большая часть этих настроек имеют значения по умолчанию, поэтому заведется и с такими вот:
1. MIDDLEWARE_CLASSES = (
2. 'djucsvlog.middleware.LogRequestInfo', ##первый
3. 'django.middleware.common.CommonMiddleware',
4. 'django.contrib.sessions.middleware.SessionMiddleware',
5. 'django.middleware.csrf.CsrfViewMiddleware',
6. 'django.middleware.locale.LocaleMiddleware',
7. 'django.contrib.auth.middleware.AuthenticationMiddleware',
8. 'django.contrib.messages.middleware.MessageMiddleware',
9. 'django.middleware.transaction.TransactionMiddleware',
10. 'djucsvlog.middleware.LogViewInfo', ## Второй
11. )
12. UCSVLOG_FILE = '/var/log/django/console-%(year)s-%(month)s-%(day)s.ucsv'
django-ucsvlog-analytics

Проект лежит на bitbucket.org

Но все самое вкусное для этих логов, благодаря их хорошей структуризации – должно лежать в аналитике.
Аналитике представленна набором базовых коммнад, которые расширяются исходя из нужд конкретной задачи.
Приятной особенностью в написании логов является то, что на вход функций анализа приходят не массивы, а объекты класса Row , у которого есть множество свойтсв, заполеныне исходя из настроек django-ucsvlog. Т.к. к примеру, когда приходит row из первого индекса реквеста то у него уже есть к примеру аттрибуты row.data_path или row.data_ip
Но этот бонус также накладывает и свои ограничения, о которых я расскажу позже.

BaseSimpleAnalyticCommand – простой анализатор

Это самый простой метод анализа. Подходит в случае если вы своим логам хотите задать все один и довольно конктерный вопрос. “Дай мне количество хитов за период?” или “Дай мне топ стран”. В этом случае команде кормится набор логфайлов, а в вашу функцию collect_row передаются объекты строк, где вы можете проводить анализ и выдавать пользователю. Тут в принципе ничего сверхествественного не происходит.

Вот пример команды, которая собирает из Ваших логов топ accepted languages
1. from djucsvlog_analytics.analytic_commands import BaseSimpleAnalyticCommand
3. class Command(BaseSimpleAnalyticCommand):
4. data = {}
5. # переопределяя эту функцию – вы указываете,
6. # какие записи вы ходите видеть в анализе
7. # в нашем случае мы хотим видеть только
8. # первые записи блока реквеста,
9. # потому что только в них есть инфа о
10. # браузере пользователя
11. def filter_row(self,row):
12. return row.is_a_req
14. # собственно функция анализа тех записей, которые
15. # прошли через фильтер
16. def collect_row(self,row):
17. al = row.data_http_accept_language.\
18. split(';')[0].split(',')[0].split('-')[0]
19. if al in self.data:
20. self.data[al]+=1
21. else:
22. self.data[al] = 1
24. # и вывод результатов
25. def output_results(self):
26. for item in sorted(self.data.items(),\
27. key=lambda a:a[1]):
28. print item[0], item[1]
Если это сохранить как команду djucsvlog_test_simple_analytics то запуск будет выглядить следующим образом:
1. $ python manage.py djucsvlog_test_simple_analytics /var/log/django/stats-2012-3-21-v3.ucsv –settings=settings.analytics
djucsvlog_user_path_convertor

Это уже команда на основе базового класса BaseAnalyticCommand ( наследник от BaseSimpleAnalyticCommand ).

Очень полезна, когда для одних логов вы хотите провести более детальный анализ. Когда Вам нужен не просто маленький отчет, а когда Вам надо разобраться дельано со сложившейся проблемой с трафиком. Это очень похоже на то, когда трафик есть а продаже нет. Почему?

Идея проста convertor собирает из логов sqlite3 БД и кладет в один файл, при этом может дополнить его информацией о браузере, оси и стране пользователя. Таблици внутри него не просто набор строк, а связные таблицы. Хосты имеют много пользователей, пользователи имеют много реквестов, а реквес имеет много лог записей. Сам этот файл уже по сути часть анализа можно просто зайти в нее и на уровне SQL получать необходимые выборки и сводить статистику.

djucsvlog_user_path_convertor – это именно наша идея конвертации в такую вот струкруту БД. Если вы заходите сделать свой конвертато в БД, то просто пишите команду, наследник от BaseAnalyticCommand.

Ниже несколько примеров запуска такой команды в наших проектах
1. $ python manage.py djucsvlog_user_path_convertor /var/log/django/* \
2. –out=/tmp/django.userpath.db
Это мы просто конвертим все файлы из папки /var/log/django/ в базу
1. $ python manage.py djucsvlog_user_path_convertor /var/log/django/* \
2. –out=/tmp/django.userpath.db –force-new
Указываем, что если БД уже есть, то в нее не дописывать а создавать заново
1. $ python manage.py djucsvlog_user_path_convertor /var/log/django/* \
2. –out=/tmp/django.userpath.db –force-new\
3. –geoip-db=/var/geodb/2012-04-01.db
Передаем ссылку на базу GEO IP для добавления дополнительного поля со страной

djucsvlog_user_path_analytics

Но мы очень быстро поняли, что очень много задач не решаются просто SQL командой, поэтому мы к sqlite3 базе начали дописывать скриптики для ее анализа, и все это свернули в отдельную команды, на вход которой передается один или несколько sqlite файлов и параметры для анализа. Причем параметры разделаются на задачи и на условия. Т.е. мы при вызове команды можем передать ей на вход несколько задач например топ браузеров или топ стран, и условия например пользователи, которые зашли на определенную страницу, пользователи, которые сделали больше определенного количества шагов. Или как связка – дай мне следующий шаг после переданного.

Сама команда является наследником от BaseAnalyticReadCommand, а задачи являются наследниками от BaseAnalyticElement, список условий передаются при создании элемента задачи

Ниже несколько примеров использования этой команды:
1. $ python manage.py djucsvlog_user_path_analytics \
2. /tmp/django.userpath.db –get-entry-points
Получаем ТОП точек входа на сайт
1. $ python manage.py djucsvlog_user_path_analytics \
2. /tmp/django.userpath.db /tmp/django_2.userpath.db \
3. –get-entry-points
Для анализа можно указывать не один файл
1. $ python manage.py djucsvlog_user_path_analytics \
2. /tmp/django.userpath.db /tmp/django_2.userpath.db \
3. –get-entry-points –after-path=/
Какой был следующий шаг после /
1. $ python manage.py djucsvlog_user_path_analytics \
2. /tmp/django.userpath.db
3. –top-404
Невероятно полезная команда после переверстки
1. $ python manage.py djucsvlog_user_path_analytics \
2. /tmp/django.userpath.db
3. –get-country-ip
Дай топ стран
1. $ python manage.py djucsvlog_user_path_analytics \
2. /tmp/django.userpath.db
3. –get-country-ip –get-os
топ стран и топ осей
1. $ python manage.py djucsvlog_user_path_analytics \
2. /tmp/django.userpath.db
3. –get-country-ip –get-os –after-steps=3
топ стран и топ осей пользователей которые сделали на сайте больше 3х шагов

Тут мне даже сложно будет перечеслить все возможности которые есть у этой команды, а сколько всего Вы еще можете дописать!!!

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

BaseStreamCommand – отложеная статистика

Раньше, для сбора онлайн статистики о ваших пользователях – Вам надо было в момент захода этого пользователя раскидывать записи по таблицам и возможно совершать какие-то дополнительные расчеты. Причем это надо было делать максимально быстро, чтоб пользователь не видел никаких задержек. С четко структурированными логами, такими как ucsvlog, нет необходимости делать это в момент захода пользователя. Достаточно просто дочитывать периодически логи, которые пишутся, и уже в момент чтений, уже раскидывать статистику. При этом ваши расчеты уже никого не задерживают. Я назвал это “отложенная статистика”, т.к. мы откладывает всю работу по ее расчет в отдельную команду.

Вы пишите команду на вход которой подаются новые записи из каталога с логами. Причем подаются эти записи именно в хронологии возникновения их в логах. Т.е. если ваш сервис пишет 10 различных лог файлов одновременно и команда в момент запуска определила, что все они выросли с момента последнего запуска, то она будет выдавать к вам на вход записи с разных файлов в разброс в зависимости от того, где записи появляются раньше. Чтоб аналитика в этом случае была максимально четкой.

Особенности работы такой команды является индексный файл ( sqlite3 ), в котором она держит данные которые используются между ее вызовами, например такие как – последние размеры лог файлов

Помимо того плюса ускоренной работы пользователя является еще и то, что в случае, когда клиент захочет расширить онлайн статистику, например добавить в нее дополнительный ТОП – ему не надо будет ждать пока она накопится. Мы просто дописываем команду по сбору статистики, которая в момент первого запуска просто накопит недостающие данные и пойдет считать стату дальше.

Наследника BaseStreamBlockCommand, передает анализу не одну строку,а уже собранный блок.

BaseConvertBlockCommand – конвертация логов.

Последней плюшкой анализатора, которая нами в данным момент обкатывается еще – это конвертатор.

Меня всегда расстраивал тот факт, что логи надо удалять А при использования django-ucsvlog апетиты засунуть в них чего по больше только растут, в результате они и стают очень толстыми. Самое грустное, что единственным правилом для удаления логов всегда служил их срок, который прямо пропорционален размеру вашего винта и размеру плодящихся логов. Говоря короче большие логи живут меньше, т.к. надо удалять их быстрее, чтоб освобождать место другим логам.

Но я не хочу удалять все логи, я хочу удалять из логов только ненужное. Мне через месяц будет неважен call_info т.е. место, где были вызваны эти логи. Мне будет все также все равно на заходы пользователя на всякие информационные страници, или к примеру стуки всяких мониторингов меня тоже будут не волновать. Но я хочу держать как можно дольше процесс совершения покупки и процессинга карты. Для этого и делается конвертатор, который перегоняет логи из толстых, в которых часть инфы актуальна только несколько дней, в тонкие, в которых остается инфа, актуальность которой максимально долгая.

Ваша команда наследник от BaseConvertBlockCommand легко может с этим справляться.

Вот пример команды, которая делает это у меня:
1. class Command(BaseConvertBlockCommand):
2. def filter_convert_row(self,row):
3. if not row.is_a_req:
4. return True
5. return not(row.data_path.startswith('/info') \
6. or row.data_path.startswith('/test-exception') \
7. or row.data_path.startswith('/check-back') \
8. or row.data_path.startswith('/calculate-statistics') \
9. or row.data_path.startswith('/captcha') \
10. or row.data_path.startswith('/media') \
11. or row.data_path.startswith('/favicon'))
Тут указывается фильтр – какие строки надо оставить. Какие столбци надо оставить указывается в сетингсах. Детали смотрите в сетингсах, там под это выделен подраздел.

Самое приятное в стриминге и конверторе – это то, что абсолютно не важно – сколько сервисов ведут свой лог. У Вас может быть ucsvlog на твистеде, отдельный на Django, еще отдельные логи ведут кроновские команды. А вот стриминг с конвертором берут и объединяют их в один поток, в один файл, где вы в хронологии сможете посмотреть события каждого из них. ( Да и не только питон, сам формат логов очень простой )

Версионность логов.

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

Например, когда я только подключил ucsvlog к системе имена всех файлов логов оканчиваются на v1.ucsv. Потом я добавил дополнительные поля в строку открытия реквеста, и изменил формат файлов на v2.ucsv, но также создал файл analytics/v1.py в которую положил настройки для первой версии логов. Теперь когда я буду парсить логи из первой версии я буду использовать этот сетингс.
1. $ python manage.py djucsvlog_user_path_convertor \
2. /var/logs/django/*-v1.ucsv \
3. –settings=analytics.v1
Тоже самое с каждой следующей версией

Заключение

Как видите логи могут стать мощным средством для аналитики процессов системы и ее пользователей. Они могут даже стать часть коммуникации между вашими сервисами. С помощью них вы можете выделять самые главное и хранить это веками. И еще много чего они могут делать, чего я и сам еще не знаю

Вобщем подключайтесь, Вам понравится, я уверен
Share and Enjoy:
Rating 3.00 out of 5

[?]
Tags: analytics, django, logs, Python, ucsvlog
12Jul

Django. Быстрый способ сохранить копию объекта

Django View Comments
1. from money.models import Trans
2. cur_model = Trans.objects.all()[0]
3. // and make a copy
4. cur_model.pk = None
5. cur_model.save() //ha ha
Share and Enjoy:
Rating 3.00 out of 5

[?]
Tags: django, Python, tips
10Jun

Методология написания тестов в Django с использованием fixtures

Django View Comments
В Django есть такая удобная вещь для написания тестов — это fixtures. Удобство состоит в том, что ваши тесты могут входить в уже заполненный данными проект. Например тестируем работу админчасти статистики, надо иметь готовый массив данных, с которым оперируем и проверяем результаты. Неудобство состоит в том, что эти фикстуры надо где взять, надо поддерживать актуальными, такими-же актуальными как и тесты. Вот как раз и про неудобную часть, а также паре подводных камней я бы и хотел вам рассказать.

Получаем фикстуру
1. python manage.py dumpdata > all_data.json
Рассказывать, что это означает я не буду, но то есть хорошая документация по фикстурам у самой 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):
1. from settings import *
2. DATABASES['default']['ENGINE'] ='django.db.backends.sqlite3'
3. DATABASES['default']['NAME'] = 'lights.db'
Как известно, в любую команду можно передать не стандартное имя сетингс модуля.

Например, для того, чтоб запустить его и добавить новых данных:
1. python manage.py runserver 0:8001 –settings=settings_lights
2. python manage.py dumpdata –setting=settings_lights > all_data.json
А поддерживать актуальность фикстуры можно через миграции, которые вы создаете после изменения структуры базы
1. python manage.py migrate –settings=settings_lights
2. python manage.py dumpdata –setting=settings_lights > all_data.json
Тестирование

Для тестирования я использую тот-же settings_lights.py для того, чтобы использовать sqlite3 в тестах, при этом для тестов вся база будет держаться в памяти, что существенно ускорит процесс написания тестов и тестирования их.
1. python manage.py test –settings=settings_lights
Но я думаю как финальную проверку, после того, как вы закончили с разработкой ( доработкой ) тестов можно использовать и реальный Engine.
1. python manage.py test
А собственно сам текст тестов может выглядить так:
1. from django.test import TestCase
2. from django.test.client import Client
3. from django.contrib.auth.models import User
5. class SimpleTest(TestCase):
6. fixtures = ['all_data.json']
7. def setUp(self):
8. self.client = Client()
10. def test_details(self):
11. print User.objects.all()
Этот пример ничего не тестирует, а просто показывает Вам, что данные на момент запуска тестов в базе уже есть. Фикстуры можно хранить как в папке fixtures любой апы, не только тестируемой. А еще в сетингсах можно прописать:
1. FIXTURE_DIRS = (
2. '/path/to/myapp/fixtures/',
3. )
Проблема с сигналами

Про сигналы в Django вы можете почитать в документции.

Фикстура — это по сути сериализация ОРМ объектов, т. е. объект будет сохранен как json, как просто текст. А значит загрузка из фикстуры — это поочередное добавление всех объектов, а добавление объектов связано с вызовом сигналов, которые в свою очередь могу сами создавать объекты моделей или изменять существующие.

Например. У Вас есть 2 модели счета и транзакции. При добавлении транзакции — дергается сигнал, по которому изменяются балансы счетов участников этой транзакции. При подготовке фикстуры вы создали одну транзакцию между двумя счетами на сумму 100 рублей, т. е. после ее проведения на одном счету прибавится 100 рублей, а на другой вычтится. Вы сохраните полученные данные в файл фикстуры, в которой будут готовые записи со счетами и транзакциями. Во время тестирования этот файл будет загружаться и вначале загрузятся модели счетов – на одном 100, на другом -100. После загрузятся транзакции и дернут сигнал, который еще раз изменит балансы на счетах и мы во время тестирования увидим состояния на счетах 200 и -200.

Решение у джанги есть , но почему-то не документированное, и как по мне — очень не удачное.

В обработчик сигнала передается параметр raw который True во время загрузки фиксутры.

Так что, если вы не хотите, чтоб обработчик сигнала работал в момент загрузки фикстуры, то первые 3 строчки вашего обработчика могут выглядит так:
1. def trans_save(sender, instance, raw, **kwargs):
2. if raw:
3. return
Как по мне — это недокументированную возможность надо огромными буквами задокументировать в обоих разделах — тесты и сигналы, но я думаю будут решения и лучше этой проблемы.

У меня все. Я описал то, как с фикстурами работаю я, и очевидно, что они могут сэкономить очень много времени Вам при разработке тестов, а также могут помогать Вам делать более качественные и реальные тесты.

Хотелось бы в комментариях увидеть критику такого подхода, дополнения, подводные камни, с которым вы сталкиваетесь. Буду дополнять статью Вашими цитатами и идеями.

Спасибо, и удачных Вам выходных.
Share and Enjoy:
Rating 3.00 out of 5

[?]
Tags: django, fixtures, Python, testing
03Jan

UCSVLOG

Python View Comments
Я уже когда-то писал и думал о системе логирования на основе csv формата. С начало идею, а потом первую версию для джанги.

Но в процессе пользования этой системы вылезло несколько недостатков.

1. В таком формате легко потерять целостность логов. Например скрипт ведения логов упал в момент из записи. Срока разорвалась в момент записи одно из полей и все. Вся БД логов потеряна
2. Надо заранее знать количество полей в логе

Поэтому я разработал другой формат – UCSV. И модуль для ведения логов на его основе python-ucsvlog.

В этом формате нет конца ни у записи ни у ячейки, есть только начало записи и начало ячейки. В этом случае конец ячейки — это просто начало следующей или начало следующей строки.

Начало записи — это перевод строки
а начало ячейки — это просто ”
ну и из csv формата — кавычка в данных ячейки заменяеться двумя

В этом случае нам не надо волноваться за целостность всех логов. В случае падения мы потеряем только одну строку

Вместе с логером я написал потоковый парсер. Ему не надо знать, какого размера у тебя файл, он читает файл порционно и порционно импортирует данные в БД. Все это происходит довольно просто и без регекспов.

Класс импорта в SQLite — ReaderSqlite. Правда во время импорта данных у которых в записи неограниченное число ячеек столбцы добавляются по ходу.

Из csv логов я забрал идею древовидности логов. Когда у каждой записи есть ключ, привязанный ко времени создания и ключ парент записи. За это отвечают 2 первые ячейки в записи. А также авторендеринг — имя файла логов можно задавать в виде шаблона. Например ‘/logs/%(syear)s-%(month)s-%(day)s.ucsv’

Для джанги я создал отдельный пакет django-ucsvlog. Те кто пользовался django-csvlog смогут легко перескочить. Поддержку последнего я осуществлять более не буду.

По мере пользования этой системы логирования я буду собирать еще один компонент django-ucsvlog-analytics. В нем будут собраны скрипты для анализа логов. Например профилирование, оно очевидно из-за привязки ко времени логов. Можно сводить статистику — самые тяжелые страницы + самые часто запрашиваемые и получать то, что надо оптимизировать в первую очередь. Или например анализ юзабилити. Можно вычислять точки не возврата, страницы, которые пользователь посещал в последний раз, или на какую страницу переходят после указанной ( иногда только такая сухая статика может убедить клиента в неюзабельность предложенного им варианта ). Можно делать каунтеры посещений определенных страниц, сколько уникальных просмотров было на этом альбоме. Можно увидеть путь по сайту определенного пользователя.

Такие логи дают много возможностей, и список «можно» – можно продолжать бесконечно. Пробуйте.
python-ucsvlog, django-ucsvlog, django-ucsvlog-analytics
Share and Enjoy:
Rating 3.00 out of 5

[?]
Tags: analytics, django, logs, Python, ucsv, ucsvlog
01Jul

Допоплнительные точки расширения Вашего апа

Django View Comments
при создании нового джанго проекта я всегда выделяю две папки apps – для моих апов и compat – для сторонних апов, к разработки которых я не имею никакого отношения. Идея в том, что эти апы всегда остаются неприкосновенными для меня, и единственной точкой расширения остаются сеттингсы и возможно доп параметры, при инклюде урлов.

А представьте, что вы создаете апу с именем catalog, ее вы потом хотите выложить в общее пользования, и необходимо для нее сделать больше точек расширения. Структура такого апа может быть
- catalog
для 4 первых файлов можно просто вконце файла добавить строку, которая станет универсальной точкой расширения. Например для views.py
1. try:
2. from ex_catalog.views import *
3. except ImportError:
4. pass
таким образом, если кто-то будет использовать Вашу апу — точкой расширения будет дополнительная апа ex_catalog, в котором вы можете переопределить некоторый функции из view.py, и при этом ex_catalog не надо добавлять в список апов в настройках.

А теперь главный вопрос этого поста. Почему так не делают?
Share and Enjoy:
Rating 3.00 out of 5

[?]
Tags: apps, django, Python, tips
27Apr

Django.forms.MultiWidget

Django View Comments
Прям сначала пришла в голову идея реализации такой фишки, но предварительно порыл в исходники джанги, дабы удостоверится, что не мастерю лисипед. Оказалось таки мастырю.

В Джанго есть MultiWidget, при инициализации которого можно указывать массив виджетов, которые будут принадлежать одному полю и выведены в ряд. При этом значение, возвращаемое этим виджетом – очевидно будет массив.

Правда просто так он почему-то не захотел работать. Разработчики почему-то захотели, чтоб его использовали всегда только как базовый класс, а не как конечный, и требуют переопределения decompress. Поэтому переопределив его мы сделали конечный и многоразового использования.

Ниже пример поля с датой из 3х выпадающих списков:
1. from datetime import date
3. from django import forms
4. from django.utils.translation import ugettext_lazy as _
6. class ListMultiWidget(forms.MultiWidget):
7. def decompress(self,values):
8. if values:
9. return values
10. return [None]*(len(self.widgets))
12. YEARS_CHOICES = map(lambda a: (a,a), range(1950,2011))
13. MONTH_CHOICES = map(lambda a: (a,a), range(1,13))
14. DAY_CHOICES = map(lambda a: (a,a), range(1,32))
16. SplitDates = ListMultiWidget((forms.Select(choices=YEARS_CHOICES),
17. forms.Select(choices =MONTH_CHOICES),
18. forms.Select(choices =DAY_CHOICES )))
20. class SplitDatesField(forms.Field):
21. widget = SplitDates
22. def to_python(self,value):
23. try:
24. return date(int(value[0]),int(value[1]),int(value[2]))
25. except ValueError:
26. raise forms.ValidationError(_(u'Wrong Date'))
Share and Enjoy:
Rating 3.00 out of 5

[?]
Tags: django, field, forms, widget
31Jan

Конспект с pycamp

Django, Python View Comments
Сегодня рано утром вернулся с pycamp, который прошел в Киеве 30ого января в учебном центре i-klass.

Организаторы сказали, что это их первая попытка организовывать подобные мероприятия, и как по мне — у них для первого раза получилось довольно не плохо, правда розеток было мало, поэтому моя 17ти дюймовая малютка держалась на аккумуляторах.

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

Александр Шигин (гость из солнечного Рамблера) «Почему Python — тормоз и как заставить его меньше тормозить». Были небольшие обзорчики кода, со сравнениями производительности. Сравнение результатов работы алгоритмов, реализованные разными способами — картежи, дикты, классы. Первые быстрее, но мы и так это знали. Хотя местами были довольно интересные результаты. Был упомянут Cython, но только вскользь, хотя мне бы тема была куда интереснее. Так что после в кулуарах мы написали небольшой хелло ворлд на cython, получили сошник и заюзали в самом питоне.

Кратко выглядит примерно так

ваш скрипт
1. print "Hello World"
скрипт setup.py:
1. from distutils.core import setup
2. from distutils.extension import Extension
3. from Cython.Distutils import build_ext
5. setup(
6. cmdclass = {'build_ext': build_ext},
7. ext_modules = [Extension("helloworld", ["helloworld.pyx"])]
8. )
получаем сошник
1. $ python setup.py build_ext –inplace
и дальше его используем в ваших скриптах.
1. >>> import helloworld
2. Hello World
Но также не забываем, что у него есть ограничение, т.е. не любой питонячий код вы можете откомпилить – генераторы, вложенные функции, локалсы, глобалсы вы юзать не можете и небольшие ограничения в определениях классов.

Для себя отметил, что им как раз можно пользоваться для оптимизации питонячего кода практически без ограничений в использовании приятного синтаксиса питона. У себя в бложке буду освежать свои успехи в этом деле.

Юрий Юревич «Рецепты декораторов». Лично для себя ничего нового не увидел, кроме того, что довольно грамотно все разложено по полочкам и что несомненно помогло упорядочить в голове знания.

Михаил Кашкин (замляк из Днепра) «Работа с хранилищами данных в 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″
… пишите в комментах ссылки на свои посты о кемпе …
Share and Enjoy:
Rating 3.00 out of 5

[?]
Tags: django, pycamp, Python

« Previous Entries

Все любят Одувана

About blog:

Categories

Checkio.ORG

Tags

Subscribe to Posts

Meta

Blogroll

4 js строчки счастья

4 css срочки к Django-Admin и и жизнь налаживается

UCSVLOG and GitHub продолжение

UCSVLOG kyivpy#6 – Как облегчают жизнь качественные логи. Часть 3. Плюшки

django-ucsvlog

django-ucsvlog-analytics

BaseSimpleAnalyticCommand – простой анализатор

djucsvlog_user_path_convertor

djucsvlog_user_path_analytics

BaseStreamCommand – отложеная статистика

BaseConvertBlockCommand – конвертация логов.

Версионность логов.

Заключение

Django. Быстрый способ сохранить копию объекта

Методология написания тестов в Django с использованием fixtures

Получаем фикстуру

Подержание актуальности фикстуры

Тестирование

Проблема с сигналами

UCSVLOG

Допоплнительные точки расширения Вашего апа

Django.forms.MultiWidget

Конспект с pycamp

Recent Posts

Recent Comments