Django *

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

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

Одно из самых частых требований заказчика — wysiwyg редактор в админке. Wysiwyg редактор имеет (как правило) интуитивно понятный интерфейс и позволяет пользователям, не знающим html, подготовить текст для размещения на сайте. Редакторы позволяют: форматировать текст, вставлять изображения и таблицы, создавать списки и много другое. Но имеют и свои минусы, самый главный из них, пожалуй, большое количество лишнего html кода.
На сегодняшний день существует большое количество различных wysiwyg редакторов и приложений для интеграции этих редакторов с django. Сегодня я расскажу про самые популярные.
Помимо собственно разметки текста, на практике важными характеристиками wysiwyg редактора для клиента являются — удобная вставка изображений и перенос отформатированного текста из сторонних источников (Word, веб-ресурсы). Важно чтобы при переносе отформатированного текста редактор удалял стили, которые могут конфликтовать со стилями сайта, например, шрифт текста. Во время обзора приложений особое внимание будет уделено этим двум характеристикам.

В прошлой статье мы определили понятия профилирования и оптимизации, познакомились с различными подходами к профилированию и видами инструментов. Немного коснулись истории профайлеров.

Сегодня я предлагаю перейти к практике и покажу на примерах способы ручного профилирования (и даже «метод пристального взгляда». Будут так же рассмотрены инструменты для статистического профилирования.

Приятного времени суток!
Возникла необходимость настроить на своём сервере с PHP под Apache поддержку Django. Думал это будет не сложно и всё пройдёт как по маслу, но получилось не совсем так. Дело в том, что я решил настроить последнюю версию фраемворка с поддержкой третьего питона. Тут то и начали всплывать подводные камни.

Некоторое время назад я рассказывал о «Профилировании и отладке Django». После выступления я получил много вопросов (как лично, так и по email), с парой новых знакомых мы даже выбрались в бар, чтобы обсудить важные проблемы программирования за кружечкой отменного эля, со многими людьми я продолжаю общаться до сих пор.

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

Как я перетащил пакет Tastypie на Pony ORM и что из этого получилось.

Данная статья продолжает историю моей борьбы за производительность приложений на python и django.

Приветствую, хабралюди. Вчера в блоге популярного веб-фреймворка для питона, Django, появилась новость о релизе новой версии под номером 1.6.

Полный перечень всех новшеств, а также информация об изменениях (в том числе и обратно несовместимых) традиционно находится в заметках к релизу. По моим ощущениям, на этот раз разработчики сфокусировались в большей степени на работе с БД.

В данной статье-новости я хотел бы отметить основные, на мой взгляд, изменения.

В данном топике, будет рассказано о пошаговой настройке и конфигурации проекта и сервера с использованием связки pinba-engine + pinboard + django-pinba, для сбора и визулизации статистики проектов на Django.

Все проекты являются бесплатными и их исходный код доступен на GitHub под лицензиями GPL или MIT.

Почему pinba?

В команде есть проекты, которые были написаны на php. Посещаемость у проектов достаточно высокая(свыше 200к). Есть очень много узких мест. Часто после каких-либо обновлений и новшеств, мы получали огромные тормоза, о которых узнавали не сразу. Нужно было решение, которое повернуто лицом к заказчику и программисту. Закачик очень не любит zabbix и munin. Решение нашлось. Это был pinboard и pinba. Заказчику понравилось. Он попросил прикрутить pinba ко всем проектам, которые крутились на django.

Результаты djangodash.com/judging/2013/results

В этом году в призовых россиян нет. Ближайщие к первым местам — 6 место — github.com/xobb1t, 7 место bitbucket.org/veikab

Но с каждым годом все сложнее определить как же все-таки считается очки. За некоторые действительно интересные проекты идея 4 (например, djangodash.com/judging/c4/results/team/179), а на другие выше (думаю каждый определит сам).

Поздравляю всех!

UPD.
Появились подарки и куда-то пропал из списка github.com/xobb1t

Привет уважаемому сообществу!

В какой-то момент времени встала потребность перенести базу приложения на django с mysql на postgresql. Первые два захода на эту проблему были неудачными, но позволили разобраться с целостностью данных, искоренить проблемы для manage.py syncdb и manage.py migrate.

Предыдущий пост посвященный производительности, описывал Pony ORM, показавший фантастические результаты по сравнению с Django ORM и SQLAlchemy.

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

Привет.
Это топик о том, как относительно быстро и безболезненно настроить секционирование (партицирование) таблицы по месяцам, если вы используете Django+PostgreSQL. Многое из описанного подойдёт и для других фреймворков и ORM.

О том, что такое секционирование и зачем оно нужно, можно почитать, например, здесь, здесь и здесь.

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

Каждый раз писать запросы для включения секционирования не очень хочется, так что попробуем автоматизировать. Хорошо, если на выходе получится что-то, что может использовать и не сильно знакомый с SQL человек. I've read the docs, so you don't have to.

Рады сообщить всем хабровчанам, что PyCharm 3.0 — наша IDE для разработки на языке Python — выпущена в двух редакциях: бесплатной Community Edition с открытым исходным кодом и полнофункциональной Professional Edition.

В двух словах: бесплатная редакция PyCharm основана на открытом коде, зато платная содержит полную функциональность.

Релиз, конечно, этим не ограничивается: в него вошло много новых полезных фич, которые работают в обоих редакциях. Но обо всем по порядку.

Когда я читаю список плюшек, которые мне предоставляет какой-либо фреймворк, я представляю, что примерно под ними подразумевается. Когда я читаю документацию по плюшкам — я убеждаюсь, что всё в целом действительно так, как я и думал. Когда я пишу код, я постигаю дао. Потому что всё на самом деле совсем не так.

Многие ошибки, которые я допускал, были из-за того, что я был уверен, что это работает так, как я думаю. Я верил в это и не допускал возможности, что может быть иначе. Конечно, капитан Очевидность скажет, что не нужно верить — нужно читать документацию. И мы читаем, читаем, запоминаем, запоминаем. Возможно ли удержать все мелочи в памяти? И правильно ли перекладывать их на разработчика, а не на фреймворк?

Ну а чтобы не быть голословным — перейдём к примерам. Нас ждут:

1. Неудаляемые модели, которые мы удалим
2. Валидируемые поля, которые не валидируются
3. Два админа, которые портят данные

Регистрация на Django Dash 2013 уже идет.
Кто хотел, но забыл, пора принимать решение.

Django Dash, это такое ежегодное соревнование, для Django разработчиков, где вам предлагают за 48 часов создать проект, самостоятельно или в команде (до 3 человек), победителям призы, всем остальным интересное времяпровождение и коментарии судей.

Больше деталей по ссылке djangodash.com

Новости о прошедших мероприятихя на хабре habrahabr.ru/search/?q=djangodash

В больших проектах уже довольно давно привык к плюшкам ci: прогону тестов, отчётам и автоматическому деплою. При разработке небольших проектов этого не хватает. 1 и 3 покрывает travis-ci (ну или drone.io), но вот визуализации результата нет никакой.

И сразу придумалось простое решение:

• прогонять анализаторы на стороне ci;
• отправлять их себе;
• парсить результат и красиво отображать.

И это всё вылилось в небольшое приложение — coviolations.io (исходники сервера и приложения), сейчас оно

• работает с публичными и приватными репозиториями на github;
• работает с travis-ci, drone.io и при желании с jenkins;
• умеет парсить результат pep8, sloccount, python unittest, pip-review и testem;
• умеет рисовать статус-плашку ;
• умеет комментировать пул реквесты в публичные проекты, использующие travis-ci;
• не умеет работать с репозиториями организаций.

Здравствуйте! Моя основная область деятельности — разработка мобильных приложений (iOS, Android). И большая часть приложений, использует взаимодействие с другими пользователями, хранение данных и другие задачи требующие наличие единого сервера. Поэтому для большей части приложений приходится писать свой велосипедbackend. А так как я, в основном являюсь мобильным разработчиком, то написание этого сервиса всегда становится небольшой проблемой — приходится задействовать веб-разработчика или искать подходящий BaaS сервис, даже если надо написать всего пару запросов.
Поэтому было принято решение, попробовать найти инструмент, позволяющий в короткие сроки написать небольшой веб-сервис, который можно было бы использовать в мобильном приложении.

Как-то раз пришлось использовать чужое django-app, в котором было много форм, методов и всего остального. И, что само собой разумеется, автор решил не заморачиваться и не делать никакой защиты от спамеров, или от любителей понажимать F5 на тяжелой форме. Переписывать и форкать у меня желания не было, поэтому решил написать middleware, режущий кислород нехорошим людям.

Функционал

• maintenance режим, позволяет выключать view в целом, или отдельные http методы
• глобальные fallback-таймауты сайта для PATCH, POST и т.д.
• локальные таймауты для view в целом, или для отдельных http-методов

Проще показать пример конфига:

DJANGO_THROTTLING = {
    'all': 1000,
    'post': 'callable:helpers.trash.my_callback',
    'congestion': 'forum.views.congestion',

    'django.contrib.admin.options.change_view': {
        'post': False,
        'all': None,
        'uri': '/admin/forum/post/23/',
    },
}

Остальные примеры с описанием под катом.

Введение

На данный момент самым популярным решением для клиентского тестирования является selenium. Стоит заметить, что вполне заслужено — те возможности, которые предоставляет selenium в связке с webdriver'ом, действительно охватывают почти весь спектр пользовательского взаимодействия с веб-приложениями.

Для небольших проектов замечательно подходит вариант с плагинами для браузеров, функционал которых можно расширить добавлением сторонних компонентов (например, UI-element). Но когда проект становится достаточно большим, а многие его части многократно изменяются и даже полностью перепиливаются, после каждого изменения в структуре страницы или способе подачи данных приходится заменять сразу целые блоки тестов, заглядывая чуть ли не в каждый тест. После такого selenium плагины уже перестают казаться столь удобными. И тут на помощь приходят библиотеки selenium, реализованные для многих языков ассоциируемых с веб-разработкой (документация на официальном сайте)

Предлагаю вам посмотреть на возможности клиентского тестирования (в частности django проектов), которые дает python-selenium в связке с библиотекой lettuce.

У меня часто бывает так, что на новом ресурсе я теряюсь в море разных функций и настроек, и для того, чтобы не потерять из виду что-то интересное, открываю/дублирую вкладку. Это не всегда удобно, да и кнопка «назад» иногда работает непредсказуемо, например, в связи с push history, или из-за «сломавшегося» на редиректе обработчика POST (не зла, а эксперимента ради). Поэтому, чтобы не нервировать пользователя, я решил сделать recent pages. История об этом под катом.