Comments 38
Образец правильной рекламы на техническом ресурсе.
+23
Отличная статья, как всегда на уровне. Спасибо!
Ну и пару вопросов, как водится.
По поводу аякса: кажется, можно было использовать django-pjax от Jacob Kaplan-Moss. Оно вроде бы делает ровно то же самое, но всё-таки велосипедом меньше :-)
По поводу виджетов и форм: мне кажется, что нет ничего страшного в том, чтобы задавать data-параметр в питоне: это всё-таки информация, а не её представление. Твик виджетов несколько усложнил для восприятия шаблоны. Или, как вариант, есть хорошее приложение для улучшения форм — django-floppyforms. Оно как раз реализует виджеты именно на шаблонах. Ну и, конечно, из коробки идёт несколько полезных HTML5-виджетов.
Ну и пару вопросов, как водится.
По поводу аякса: кажется, можно было использовать django-pjax от Jacob Kaplan-Moss. Оно вроде бы делает ровно то же самое, но всё-таки велосипедом меньше :-)
По поводу виджетов и форм: мне кажется, что нет ничего страшного в том, чтобы задавать data-параметр в питоне: это всё-таки информация, а не её представление. Твик виджетов несколько усложнил для восприятия шаблоны. Или, как вариант, есть хорошее приложение для улучшения форм — django-floppyforms. Оно как раз реализует виджеты именно на шаблонах. Ну и, конечно, из коробки идёт несколько полезных HTML5-виджетов.
+1
Да, 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.
0
в django-pjax, кстати, подход, аналогичный декоратору ajax_request — мне кажется, наследник TemplateResponse все-таки решает задачу лучше (меньше кода + более гибко).
0
Раньше пользовался django-pjax а потом перелез на django-tastypie + backbone-tastypie
0
Сравнивать pjax и backbone слегка некорректно. Первый — обёртка над браузерным History API. Второй — полноценный MVC-фреймворк. Да, в нём есть роутер, но использовать всю эту машинерию только ради аяксовых страничек… неразумно.
С другой стороны, если Вам нужен полноценный REST API, то и аяксовая навигация как таковая не нужна =)
С другой стороны, если Вам нужен полноценный REST API, то и аяксовая навигация как таковая не нужна =)
+1
Разумеется я не стал бы прикручивать столько ради аякс навигации — django-tastypie уже был в проекте изначально, а потом решили добавить backbone ну и только после этого отказались от pjax в пользу уже имеющегося функционала backbone. Оставалось только подружить tastypie с backbone и это было backbone-tastypie.
Кому интересно, тут есть пример проекта django-tastypie + backbone-tastypie. А еще вот один из хороших примеров django сайта где используется tastypie + backbone
Кому интересно, тут есть пример проекта django-tastypie + backbone-tastypie. А еще вот один из хороших примеров django сайта где используется tastypie + backbone
0
«Атомной артилерией» все равно является 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
0
Для того, кто питонирует с джанго подобные чтения висьма полезны. Полезно и интересно посмотреть, как другие решают распространенны проблемы, связанные с особенностями этого питоновского фреймворка.
+2
Отлично написано, вот так и надо писать о разработке!
Жду когда, кто-нибудь о RoR проекте так же напишет.
Жду когда, кто-нибудь о RoR проекте так же напишет.
0
У меня текст поплыл. Изображение.
0
Спасибо! Завел в треке баг №103 «у чувака с хабра текст поплыл», думаю, скоро починим)
+4
Мы попробовали исправить, если не сложно, можете посмотреть, починилось ли? И заодно, какая у вас ось/браузер?
Пробовал написать в личку, но хабр ведет себя потрясно — is.gd/gBPlA1
Спасибо!
Пробовал написать в личку, но хабр ведет себя потрясно — is.gd/gBPlA1
Спасибо!
0
Спасибо за крутую статью. Приятно и легко читалось. Хороший пример, как правильно нужно «готовить» Django. Многие говорят, что для больших проект джанги уже не хватает. Например у нас на проекте от джанги осталась только система пакетов, шаблонизатор, middlewares и наверное все. Остальное все самописное. Эволюционно как-то все менялось. Но многие большие проекты хорошо ложатся под Django. Например та же Instagram.
0
Спасибо!
Из «больших» на джанге можно еще, кстати, 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), но в остальном обычная джанга — так код понятнее и проще поддерживать (т.к. опыт с джангой есть у многих).
0
Еще есть пару вопросов:
1) А на чем крутиться сайт?
2) Как деплоите проект?
3) Какую стратегию ведения веток используете в репозитории? И используете ли вообще?
4) Производительность: какое посещение сайта сейчас, какие нагрузки на сервер получаются и какая тачка у вас на продакшне?
Спасибо :)
1) А на чем крутиться сайт?
2) Как деплоите проект?
3) Какую стратегию ведения веток используете в репозитории? И используете ли вообще?
4) Производительность: какое посещение сайта сейчас, какие нагрузки на сервер получаются и какая тачка у вас на продакшне?
Спасибо :)
0
Как раз об этом в следующей статье написать хотел, пол-стать уже готово) Про django-fab-deploy уже писал, но там поменялось многое, и несколько тонкостей есть. Сайт — на дебиане + апаче + mod_wsgi; деплоим fab push:migrate,pip_update из консоли; ветки используем, но меня не совсем устраивает, как (ветки production и testing для продакшн- и тестового сервера + ветки под фичи без спец. значений); сейчас нагрузка не очень большая, запустились недавно и рекламы никакой не было пока; запас прочности есть; сервер — hetzner 4S за 60$ в месяц (с линода перелезли) — дофига ресурсов за такие деньги.
0
А почему перелезли с linode? Используем его, вроде проблем нет.
0
Мне линод тоже нравится, и проблем с ним не было. Но у hetzner ресурсов сильно больше за те же $. В линоде за 60$ VPS с 1.5 RAM и 60Gb диска, в хетцнере за 60$ выделенный сервер с 32GB RAM и 2x3TB raid — искушение велико.
0
Увидев кнопку входа через facebook, подумал что странно что нет вконтакте, твиттеров итд… какие причины были выбрать только facebook?
0
Они будут слегка попозже. Будет даже мейлру.
+1
Ага, все делалось довольно быстро, «на скорость», методом вырезания и откладывания фич, и там много чего еще доделать можно.
0
А для социального входа используете что-нибудь типа django-social-auth, django-allauth? или с нуля под каждый тип?
0
Пробуем первый раз github.com/krvss/django-social-auth, посмотрим, как оно в деле.
0
Михаил, Вы пишите классные модули, двигайте правильные темы (особенно понравились 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 ради интереса хотя бы)
Извиняюсь, что не совсем по теме, просто давно уже хотел сказать Вам, да повода не было.
0
Баг-репорт и/или pull request про это в любой из проектов с радостью приму! Мне кстати комрады, с кем работаю (@obiwanus, например), тоже часто пишут, что вот именно с пробелами вокруг аргументов не всегда последователен :) pep8 уважаю, невнимательность стараюсь исправлять.
+1
Кстати, если параметры функции идут в несколько строк, то лучше выглядит, если вокруг равно есть пробелы.
Например,
имхо, выглядит хуже, чем
[ворчун mode]
> Михаил, Вы пишите классные модули, двигайте правильные темы
У вас русский язык тоже иногда не по pep8 :)
[/ворчун mode]
Например,
names = dict(
vasia="petya",
vova="serezha",
mashenka="sveta",
)
имхо, выглядит хуже, чем
names = dict(
vasia = "petya",
vova = "serezha",
mashenka = "sveta",
)
[ворчун mode]
> Михаил, Вы пишите классные модули, двигайте правильные темы
У вас русский язык тоже иногда не по pep8 :)
[/ворчун mode]
+1
А Вы заведите где-нибудь рядом с девелоперским сервером Jenkins, не исключая такие ошибки в настройках — быстро отпадёт желание писать пробелы у аргументов :) Увидите там Violations (pylint +600) и перехочется так писать)))
У меня, по крайней мере, так и было. Причём самый веский аргумент так не делать — чтобы не было возможности выпускать в продакшен проекты с ошибками.
У меня, по крайней мере, так и было. Причём самый веский аргумент так не делать — чтобы не было возможности выпускать в продакшен проекты с ошибками.
0
У нас «code review» ручной (просто коммиты друг друга читаем регулярно), пишут все неплохо, не вижу смысла в каких-то дополнительных механических методах, они разработку в небольшой команде не ускорят imho.
Насчет ошибок — тесты пишем, не то чтобы фанатики, но покрытие процентов 80 есть, тесты прогоняются автоматом при каждой выкладке на сервер (да и локально гоняем их), вот это помогает.
Насчет ошибок — тесты пишем, не то чтобы фанатики, но покрытие процентов 80 есть, тесты прогоняются автоматом при каждой выкладке на сервер (да и локально гоняем их), вот это помогает.
0
А если не секрет, сколько по времени длилась разработка сервиса такого уровня? И сколько девелоперов принимало участие?
Спасибо…
Спасибо…
+1
Делать начали в марте; первое время делали вдвоем с верстальщицей, потом еще человек подключился. К апрелю, в принципе, пользоваться сайтом с точки зрения пользователя было можно (24 марта — первая бронь), но многих вещей не хватало (вроде смс, входа через фейсбук и панели для ресторанов); мы публично тогда не запускались, но более-менее рабочий сайт упростил и ускорил заключение соглашений с ресторанами (а смысл в сервисе бронирования без них).
Ну и не стоит говорить о разработке в прошедшем времени, все самое интересное только начинается, останавливаться на достигнутом мы не намерены :)
Ну и не стоит говорить о разработке в прошедшем времени, все самое интересное только начинается, останавливаться на достигнутом мы не намерены :)
0
Спасибо за отличную статью
0
Sign up to leave a comment.
Рецепты от ПанГурмана