Архив за [undefined]

Спринтеры в Яндексе

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

Технические итоги спринта подвел очень лаконично Ваня Сагалаев, я же больше расскажу чуть про процесс.

И так, в субботу 12 июля в одном из московских офисов Яндекса, собрались люди чтобы подправить джангу. Собирались долго, поскольку для многих оказалось неожиданностью, что привычные шатлы от метро по выходным не ходят и надо добираться пешком. Сюрпризом это стало и для некоторых сотрудников самого Яндекса, к слову, которых набралось целых 3 человека.

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

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

Кстати, была группа, которая занималась не доводкой NFA, а реализацией улучшенного бекэнда для Oracle, как потом оказалось, из очень серьезной конторы:) Но об этом попозже.

Так, я оказался в числе тех самых, подготовленных, и выбрал ...

У админки новые формы

Опять говорю "Ура!". В предыдущий раз это это было в связи с апгрейдом ORM. На это раз кардинальным улучшениям подверглась ещё одна очень важная часть Django - автоматический CRUD, она же в официальной терминологии - админка. После достаточно продолжительного этапа разработки и тестирования NFA бранч влился в транк и подарил пользователям джанги кучу новых ощущений: от радости за сей факт, до тревоги по поводу необходимости переписывать имеющийся код. Но нас, любителей самых "свежих срезов", это никогда не останавливало.:)

Многие уже успели изменить транку с NFA брачем и некоторое время погонять новую админку в своих проектах. Но не все такие смелые:)

Вообще это очень интересный процесс когда ты видишь по увеличившемуся числу changeset'ов перед релизом чего-то нового, что вот оно скоро свершится. Так было с Малкольмом, когда он допиливал рефакторинг ORM и произошло сейчас, благо спринт организовали. На этот раз главная звезда Брайен Роснер. Эти приятные хлопоты по полировке деталей, правки уже кажущихся не очень существенными сообщениями об ошибках, именования переменных и функций, и т.п. - как часть неотъемлемая часть.

Так что же мы получили? Во первых случился важнейший переворот в принципе описания админки. Если раньше её описание было частью определения модели, то теперь оно происходит отдельно. Что, наконец, дает возможность кастомизировать ...

Декоративные изыски

Пока пост про спринт с фотками и видео по техническим причинам задерживает, я решил поразмышлять вслух о декораторах.

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

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

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

@a
@bb("dd","ff")
@ccc
def foobar(arg1,arg2):
   #...

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

Конечно, иногда декораторы избыточны. Если мы сами авторы функции, то мы можем и не использовать декораторы, а просто явно вызывать некие сторонние функции, которые делают работу декораторов. Но для этого надо чуть-чуть больше знать о том, что они делают и как. И к тому же мы теряем, так любимою мною, декларативность и "скатываемся" до условно императивных конструкций. Код выше мог бы выглядеть так:

def foobar(arg1,arg2):
   arg1 = a(arg1)
   arg2 = bb("dd","ff", arg2)
   if not arg2:
        return
   #...
   return ccc ...

Юзер или профиль?

Вы никогда не задумывались на что делать ссылку в модели, если надо привязать её к пользователю? К User или Profile (любой модели которая выполняет роль "профиля")? Этот вопрос, конечно, справедлив для тех проектов. где есть необходимость в профиле как таковом, иначе ссылка на User и все дела.

Я для себя какое-то время назад решил, что Profile выгоднее. Небольшой анализ всё же показал, что всё зависит от конкретного случая и вариантов использования результирующей модели.

Рассмотрим ситуацию, когда основная информация для работы приложения, относящаяся к пользователю, как раз хранится в профиле. Тогда при ссылке на User нужно будет каждый раз "дотягивать" ещё и профиль. Не очень удобно, да и накладно к тому же. Если же завязаться на профиль, то всё становится прозрачнее и оптимальнее. Тем более, если профиль реализован через наследование от User, то вообще разницы для клиентского кода модели не будет - профиль для него прозрачно становится юзером. Хочу лишь отметить, чтобы прозрачность была полной, не забудьте у профиля переопределить менеджер либо на UserManager, либо на его наследника с дополнительным функционалом.

В своих проектах я именно так и поступаю. Например в этом блоге посты (автор) связаны с профилем.

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