Comments 38
Образец правильной рекламы на техническом ресурсе.
Отличная статья, как всегда на уровне. Спасибо!
Ну и пару вопросов, как водится.
По поводу аякса: кажется, можно было использовать django-pjax от Jacob Kaplan-Moss. Оно вроде бы делает ровно то же самое, но всё-таки велосипедом меньше :-)
По поводу виджетов и форм: мне кажется, что нет ничего страшного в том, чтобы задавать data-параметр в питоне: это всё-таки информация, а не её представление. Твик виджетов несколько усложнил для восприятия шаблоны. Или, как вариант, есть хорошее приложение для улучшения форм — django-floppyforms. Оно как раз реализует виджеты именно на шаблонах. Ну и, конечно, из коробки идёт несколько полезных HTML5-виджетов.
Ну и пару вопросов, как водится.
По поводу аякса: кажется, можно было использовать django-pjax от Jacob Kaplan-Moss. Оно вроде бы делает ровно то же самое, но всё-таки велосипедом меньше :-)
По поводу виджетов и форм: мне кажется, что нет ничего страшного в том, чтобы задавать data-параметр в питоне: это всё-таки информация, а не её представление. Твик виджетов несколько усложнил для восприятия шаблоны. Или, как вариант, есть хорошее приложение для улучшения форм — django-floppyforms. Оно как раз реализует виджеты именно на шаблонах. Ну и, конечно, из коробки идёт несколько полезных HTML5-виджетов.
Да, django-pjax — примерно то же самое. Там клиент на jQuery, а у нас mootools+behavior используется. Серверная часть там тривиальная в общем-то.
Насчет усложнения шаблонов, верстка:
превращается в
вроде проще некуда, кастомные атрибут скопипастить можно)
В django-floppyforms хорошо то, что вся верстка в шаблонах, а не в питоне. Но с django-floppyforms все равно для изменения стандартного поведения рендеринга (== прикручивания верстки) нужно питоний код трогать и еще один шаблон определять, в отличие от django-widget-tweaks.
Насчет усложнения шаблонов, верстка:
<input type='text' name='email' id='id_email' class='b-input' placeholder='Введите email'>
превращается в
{% render_field form.email class='b-input' placeholder='Введите email' %}
вроде проще некуда, кастомные атрибут скопипастить можно)
В django-floppyforms хорошо то, что вся верстка в шаблонах, а не в питоне. Но с django-floppyforms все равно для изменения стандартного поведения рендеринга (== прикручивания верстки) нужно питоний код трогать и еще один шаблон определять, в отличие от django-widget-tweaks.
в django-pjax, кстати, подход, аналогичный декоратору ajax_request — мне кажется, наследник TemplateResponse все-таки решает задачу лучше (меньше кода + более гибко).
Раньше пользовался django-pjax а потом перелез на django-tastypie + backbone-tastypie
Сравнивать pjax и backbone слегка некорректно. Первый — обёртка над браузерным History API. Второй — полноценный MVC-фреймворк. Да, в нём есть роутер, но использовать всю эту машинерию только ради аяксовых страничек… неразумно.
С другой стороны, если Вам нужен полноценный REST API, то и аяксовая навигация как таковая не нужна =)
С другой стороны, если Вам нужен полноценный REST API, то и аяксовая навигация как таковая не нужна =)
Разумеется я не стал бы прикручивать столько ради аякс навигации — django-tastypie уже был в проекте изначально, а потом решили добавить backbone ну и только после этого отказались от pjax в пользу уже имеющегося функционала backbone. Оставалось только подружить tastypie с backbone и это было backbone-tastypie.
Кому интересно, тут есть пример проекта django-tastypie + backbone-tastypie. А еще вот один из хороших примеров django сайта где используется tastypie + backbone
Кому интересно, тут есть пример проекта django-tastypie + backbone-tastypie. А еще вот один из хороших примеров django сайта где используется tastypie + backbone
«Атомной артилерией» все равно является dojox.data.JsonRestStore + dojango, в сочетании с Django-Piston, хотя, в свете последнего Class-based generic views, Django-Piston уже не особо нужен, ибо REST-API можно организовать и нативными средствами Django.
Хотя да, backbone подкупает своей компромисностью функционала и простоты. Наверное стоит упомянуть тогда и про github.com/af/djangbone
Хотя да, backbone подкупает своей компромисностью функционала и простоты. Наверное стоит упомянуть тогда и про github.com/af/djangbone
Для того, кто питонирует с джанго подобные чтения висьма полезны. Полезно и интересно посмотреть, как другие решают распространенны проблемы, связанные с особенностями этого питоновского фреймворка.
Отлично написано, вот так и надо писать о разработке!
Жду когда, кто-нибудь о RoR проекте так же напишет.
Жду когда, кто-нибудь о RoR проекте так же напишет.
У меня текст поплыл. Изображение.
Спасибо! Завел в треке баг №103 «у чувака с хабра текст поплыл», думаю, скоро починим)
Мы попробовали исправить, если не сложно, можете посмотреть, починилось ли? И заодно, какая у вас ось/браузер?
Пробовал написать в личку, но хабр ведет себя потрясно — is.gd/gBPlA1
Спасибо!
Пробовал написать в личку, но хабр ведет себя потрясно — is.gd/gBPlA1
Спасибо!
Спасибо за крутую статью. Приятно и легко читалось. Хороший пример, как правильно нужно «готовить» Django. Многие говорят, что для больших проект джанги уже не хватает. Например у нас на проекте от джанги осталась только система пакетов, шаблонизатор, middlewares и наверное все. Остальное все самописное. Эволюционно как-то все менялось. Но многие большие проекты хорошо ложатся под Django. Например та же Instagram.
Спасибо!
Из «больших» на джанге можно еще, кстати, pinterest отметить — в январе 2012 у него больше трафика было, чем у LinkedIn, YouTube или Google+ — вот уж действительно большой сайт на джанге :) Пишут, что используют «patched django», а что именно patched — не отвечают :)
У нас как-то так получается, что в основном не заменяем части джанги полностью, а надстраиваем. В шаблонах/формах — widget-tweaks, в моделях — model-utils, в тестах — factory-boy и django-webtest, обработка ошибок — sentry как логгер и т.д. Некоторые части не используем в принципе (contrib.comments, свои виджеты для форм, form preview, form wizard, flatpages, humanize, serialization, sites), но в остальном обычная джанга — так код понятнее и проще поддерживать (т.к. опыт с джангой есть у многих).
Из «больших» на джанге можно еще, кстати, pinterest отметить — в январе 2012 у него больше трафика было, чем у LinkedIn, YouTube или Google+ — вот уж действительно большой сайт на джанге :) Пишут, что используют «patched django», а что именно patched — не отвечают :)
У нас как-то так получается, что в основном не заменяем части джанги полностью, а надстраиваем. В шаблонах/формах — widget-tweaks, в моделях — model-utils, в тестах — factory-boy и django-webtest, обработка ошибок — sentry как логгер и т.д. Некоторые части не используем в принципе (contrib.comments, свои виджеты для форм, form preview, form wizard, flatpages, humanize, serialization, sites), но в остальном обычная джанга — так код понятнее и проще поддерживать (т.к. опыт с джангой есть у многих).
Еще есть пару вопросов:
1) А на чем крутиться сайт?
2) Как деплоите проект?
3) Какую стратегию ведения веток используете в репозитории? И используете ли вообще?
4) Производительность: какое посещение сайта сейчас, какие нагрузки на сервер получаются и какая тачка у вас на продакшне?
Спасибо :)
1) А на чем крутиться сайт?
2) Как деплоите проект?
3) Какую стратегию ведения веток используете в репозитории? И используете ли вообще?
4) Производительность: какое посещение сайта сейчас, какие нагрузки на сервер получаются и какая тачка у вас на продакшне?
Спасибо :)
Про деплоинг kmike уже писал.
Как раз об этом в следующей статье написать хотел, пол-стать уже готово) Про django-fab-deploy уже писал, но там поменялось многое, и несколько тонкостей есть. Сайт — на дебиане + апаче + mod_wsgi; деплоим fab push:migrate,pip_update из консоли; ветки используем, но меня не совсем устраивает, как (ветки production и testing для продакшн- и тестового сервера + ветки под фичи без спец. значений); сейчас нагрузка не очень большая, запустились недавно и рекламы никакой не было пока; запас прочности есть; сервер — hetzner 4S за 60$ в месяц (с линода перелезли) — дофига ресурсов за такие деньги.
Увидев кнопку входа через facebook, подумал что странно что нет вконтакте, твиттеров итд… какие причины были выбрать только facebook?
Они будут слегка попозже. Будет даже мейлру.
Ага, все делалось довольно быстро, «на скорость», методом вырезания и откладывания фич, и там много чего еще доделать можно.
А для социального входа используете что-нибудь типа django-social-auth, django-allauth? или с нуля под каждый тип?
Пробуем первый раз github.com/krvss/django-social-auth, посмотрим, как оно в деле.
Михаил, Вы пишите классные модули, двигайте правильные темы (особенно понравились django-widget-tweaks), но я ещё с pymorphy заметил, что Вы совсем не следите за пробелами внутри аргументов методов/функций. Как вот тут, например, у choices
Не по pep8 же. Да и просто не красиво выглядит… Заведите у себя pep8/pyflakes ради интереса хотя бы)
Извиняюсь, что не совсем по теме, просто давно уже хотел сказать Вам, да повода не было.
transfer_type = models.CharField(u'Тип', max_length=20,
null=True, blank=True,
choices = TRANSFER_TYPE_CHOICES)
Не по pep8 же. Да и просто не красиво выглядит… Заведите у себя pep8/pyflakes ради интереса хотя бы)
Извиняюсь, что не совсем по теме, просто давно уже хотел сказать Вам, да повода не было.
Баг-репорт и/или pull request про это в любой из проектов с радостью приму! Мне кстати комрады, с кем работаю (@obiwanus, например), тоже часто пишут, что вот именно с пробелами вокруг аргументов не всегда последователен :) pep8 уважаю, невнимательность стараюсь исправлять.
Кстати, если параметры функции идут в несколько строк, то лучше выглядит, если вокруг равно есть пробелы.
Например,
имхо, выглядит хуже, чем
[ворчун mode]
> Михаил, Вы пишите классные модули, двигайте правильные темы
У вас русский язык тоже иногда не по pep8 :)
[/ворчун mode]
Например,
names = dict(
vasia="petya",
vova="serezha",
mashenka="sveta",
)
имхо, выглядит хуже, чем
names = dict(
vasia = "petya",
vova = "serezha",
mashenka = "sveta",
)
[ворчун mode]
> Михаил, Вы пишите классные модули, двигайте правильные темы
У вас русский язык тоже иногда не по pep8 :)
[/ворчун mode]
А Вы заведите где-нибудь рядом с девелоперским сервером Jenkins, не исключая такие ошибки в настройках — быстро отпадёт желание писать пробелы у аргументов :) Увидите там Violations (pylint +600) и перехочется так писать)))
У меня, по крайней мере, так и было. Причём самый веский аргумент так не делать — чтобы не было возможности выпускать в продакшен проекты с ошибками.
У меня, по крайней мере, так и было. Причём самый веский аргумент так не делать — чтобы не было возможности выпускать в продакшен проекты с ошибками.
У нас «code review» ручной (просто коммиты друг друга читаем регулярно), пишут все неплохо, не вижу смысла в каких-то дополнительных механических методах, они разработку в небольшой команде не ускорят imho.
Насчет ошибок — тесты пишем, не то чтобы фанатики, но покрытие процентов 80 есть, тесты прогоняются автоматом при каждой выкладке на сервер (да и локально гоняем их), вот это помогает.
Насчет ошибок — тесты пишем, не то чтобы фанатики, но покрытие процентов 80 есть, тесты прогоняются автоматом при каждой выкладке на сервер (да и локально гоняем их), вот это помогает.
А если не секрет, сколько по времени длилась разработка сервиса такого уровня? И сколько девелоперов принимало участие?
Спасибо…
Спасибо…
Делать начали в марте; первое время делали вдвоем с верстальщицей, потом еще человек подключился. К апрелю, в принципе, пользоваться сайтом с точки зрения пользователя было можно (24 марта — первая бронь), но многих вещей не хватало (вроде смс, входа через фейсбук и панели для ресторанов); мы публично тогда не запускались, но более-менее рабочий сайт упростил и ускорил заключение соглашений с ресторанами (а смысл в сервисе бронирования без них).
Ну и не стоит говорить о разработке в прошедшем времени, все самое интересное только начинается, останавливаться на достигнутом мы не намерены :)
Ну и не стоит говорить о разработке в прошедшем времени, все самое интересное только начинается, останавливаться на достигнутом мы не намерены :)
Спасибо за отличную статью
Sign up to leave a comment.
Рецепты от ПанГурмана