Интернет нового века

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

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

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

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

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

Читать далее

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

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

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

Читать далее

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

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

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

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

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

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

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

Читать далее

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

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

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

Читать далее