Публикации с меткой «Django»

Я тут думал, что отказ от django-шаблонов в пользу mako — это довольно радикальное решение, по многим причинам это действительно так. Но сегодня я изменил своё мнение.

Люди совершенно с ума сходят.

У нас на завтре шаблон комментария один и дёргается из разных мест по разным причинам: когда создаётся новый коммент, в юзера летит отрендеренный шаблон, когда собирается страница статьи, циклом инклудится каждый шаблон и т.п. Инклуд в цикле, как оказалось (и это не удивительно) — узкое место джанго-шаблонов, несмотря на всю изкоробочную кеш-машинерию. Когда в одной из статей кол-во комментов перевалило за тысячу, это стало неиллюзорно сказываться. Среднее время генерации такой страницы стало чуть меньше секунды, что ни в какие ворота, конечно.

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

Так вот: время рендеринга шаблона любой страницы теперь пренебрежимо мало по сравнению с другими процессами. И та адская страница уже выплёвывается за 300мс в среднем. Ну и вообще:





Mako über alles!

P.S. Можно пойти еще дальше и сэкономить даже на спичках, запретив маке проверять mtime шаблонов.

P.P.S. Пики вызваны реиндексацией сфинкса, на который я тоже переполз, потому что солр припарил выедать всю память, а сфинкс спокойно сидит в своих 256 метрах и не жалуется. Реиндексация пока полная, дельты я не делал.

Здравствуйте! В продолжении серии статей про Class Based Views (далее CBV) переходим к разделу, посвященному редактированию объектов. В данной статье мы рассмотрим четыре класса с говорящими названиями: FormView, CreateView, UpdateView, DeleteView.

Часть 1, часть 2, часть 3, часть 4

Приветствую вас вновь, дорогие читатели! Публикую очередную статью из цикла немного про Class Based Views (далее CBV) в Django. На этот раз я, как и планировал, хотел бы рассмотреть ListView (отвечает за отображение списка объектов) и DetailView (отвечает за отображение информации об отдельном объекте).

Часть 1, часть 2, часть 3

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

Искал для себя шпаргалку. Не смог найти её здесь и нашёл у них) Делюсь с теми, кому она необходима, как и мне.
Оригинальная ссылка: PDF

Доброго времени суток, уважаемые читатели! Не так давно мной была опубликована первая часть статьи на данную тему. Я хочу еще раз поблагодарить всех пользователей, высказавших конструктивную критику, благодаря которой примеры в статье удалось привести к почти идеальному виду. В то же время я понял, что данный формат подачи материала является неэффективным: мы рассмотрели всего пару методов, реализованных в Class Based View (далее по тексту CBV). Во второй части я решил переработать подачу и далее постараюсь описать максимально возможное количество методов, представленных в API. Постараюсь, также, охватить те методы, которые были упущены в первой части. Очень надеюсь на конструктивную поддержку читателей и надеюсь, что и в дальнейшем у нас получится продуктивный диалог, в результате которого статья станет еще более информативной.

Вступление

Здравствуйте, уважаемые читатели! Для многих джанго-разработчиков не секрет, что с версии 1.3+ вместо используемых раннее generic views нам необходимо начинать использовать class based views. А с 1.4+ версии generic views вообще могут стать deprecated. Информация про class based views (далее CBV) в интернете довольно скупа (а в рунете и подавно). Нет, конечно есть превосходные статьи, в том числе тут на хабре. Одна из статей была опубликована буквально на днях. Но я отношусь к той категории людей, что привыкли все изучать на практике и данный топик написан для таких же людей.
В качестве практического задания мной был выбран классический вариант — создание блога. Для того, чтобы использовать возможности CBV по максимуму мы немного усложним задачу. Пусть это будет не просто блог, а блог, с возможностью публиковать приватные статьи, недоступные неавторизованным пользователям.
Дальнейшие рассуждения подразумевают, что читатель ознакомлен с фреймворком Django и имеет навыки в создании проектов.

В Django версии 1.3 были представлены class-based views — способ описания view в виде классов. Документация, однако, касается только generic views, не описывая общую технику написания «вьюх» в виде классов. Начав использовать generic views и затем пытаясь изменить их поведение, я постепенно дошел до того момента, когда мне пришлось смотреть исходный код, чтобы понять, как что-то сделать. Поэтому я решил написать этот текст. Цель его — объяснить, как использовать class-based view и чем это может быть полезно.

Facrtory-boy — это такая замена fixtures в django, которая позволяет более гибко и удобно генерировать данные для тестов с использование различных стратегий. Можно возвращать либо сохраненные модели, либо просто модели, пока еще не сохраненные, либо просто словарь атрибутов модели, связывать фабрики между собой. Раздолье для творчества. А написана она была Mark Sandstrom и сейчас активно развивается Raphaël Barrois. Идея была позаимствована из аналогичной библиотеки factory-girl для руби.

Некоторое время назад озадачился поиском способа развертывания проектов Django, к которому предъявлялись два требования:

1. Удобное управление запуском/остановкой/перезапуском нескольких проектов на одном хосте
2. Поддержка разных виртуальных сред для разных проектов

По второму пункту мой выбор склонился в пользу Nginx + uWSGI. По первому же, из рассмотренных мною вариантов больше всего понравились обвязки для uWSGI в Debian.

Когда мы подготавливали для Хабра свою последнюю статью о Django-батарейках, выяснилось, что про django-sphinx мы таки имеем что рассказать и наш рассказ тянет на отдельный пост. Собственно, вот он, как и обещали.

На сегодняшний день, существует несколько хороших решений для организации поиска в Django. Несколько — это два: Haystack и django-sphinx. Haystack работает с бэкендами-движками solr, whoosh и хapian и, увы, не работает со Sphinx`ом по каким-то абстрактным лицензионным причинам. django-sphinx же, как можно догадаться, работает со Sphinx`ом и только. Haystack это качественный, хорошо документированный и активно развиваемый продукт и мы, вне всяких сомнений, использовали бы именно его, если бы он хоть в какой-нибудь форме поддерживал Sphinx. Но этого, увы, пока не произошло. А Sphinx — наше всё, благодаря его скорости, гибкости и, что очень важно в наших географических широтах, способности учитывать особенности русской морфологии, чего не скажешь о его ближайших конкурентах. «Большие, но по 5… или маленькие, но по 3?» ©

Продолжаем делиться своим опытом использования полезных батареек для Django. Первая часть
Ещё рекомендуем «Сумбурные заметки про python и django» и «Django проект PR Hero: что внутри и полученный опыт».

Для Django написано огромное количество пакетов. Из них мы выбрали 10, которые использовали сами в своих последних проектах и которыми остались довольны. Все они есть на PyPI. Они продокументированы и покрыты тестами, где-то больше, где-то меньше. Исключение составляет django-sphinx, о котором отдельно.

Ну что же, спустя два месяца работы проекта уже можно делать какие-то предварительные выводы. Два месяца назад мы запустили новый сайт газеты "Завтра". Всё работает на 512-метровом рэкспейсовом vps, вместе с солром, и даже не думает ходить в своп, что интересно.

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

Без солра вообще было занято в среднем 100 метров памяти. Но джава взяла своё и съела остававшееся :)

Исходный код выложен тут. Полно сырых моментов, однако работает и не жужжит.

Буду краток:



Подробности, что еще не работает, и как это установить — под катом.