Александр Кошелев

Ну вот. Даже как-то грустно. То чего все мы так долго ждали наконец свершилось. Джанга родилась в своем релизном варианте с гордым "1.0" на ярлыке.

Почему грустно? Да потому, что тот темп, с которым менялась джанга последний год(с лишним), приучил нас быть всегда в тонусе, следить за изменениями, подстраиваться под них и как-то менять своё видение этого чудесного фреймворка. А что теперь? Мне кажется что темп упадет, а значит и драйв обитания на trunk будет не такой как раньше.

Ну ладно с ним с драйвом, будем искать в других областях. Важно то что наконец джанга должна приобрести общепризнанный статус production/enterprise-ready и пойти в массы с ещё более быстрыми темпами. Компании (конечно в большей степени управленцы в них), которые раньше на этапе выбора платформы и инструмента воротили нос от продукта, который был, как им казалось, не готов для боевого применения, сейчас начнут пересматривать свои воззрения, и уже для новых проектов боле пристально смотреть на джагу как на реального кандидата в освоении и применении. Я на это надеюсь по крайней мере. Пусть для многих смелых и разумных, уже давно джанга вполне была готовой к бою, но всё равно оставались сомневающиеся.

Так же теперь в споре на лидерство на рынке ...

Недавно очень ясно осознал на собственном опыте, насколько же разными могут быть структурные модели XML. Разные они и по восприятию, и удобству обработки, и простоте создания. Но о вопросах генерации я могу только догадываться и предполагать, поскольку особо этим не занимался никогда, то про обработку могу действительно поделиться некоторыми мыслями, которые меня посетили после продолжительного периода "ковыряния" различных XML структур данных.

Горизонтальная модель показалась мне более читаемой. Т.е. она более похожа на табличные выборки из баз данных. И как не странно, её проще парсить и обрабатывать. Ставка на атрибуты, идентификаторы которых уникальны в приделах одного элемента, себя оправдывает и не порождает излишеств.

Вертикальная модель подразумевает активное использование дочерних элементов. Из-за этого документ получается более "толстым". Причем зачастую. использование дочерних элементов не очень оправдано. Они не используются как контейнеры для других элементов и даже CDATA там не хранится. А читать труднее. Хотя и появляется некая древовидная структура, но достаточно вырожденная и почти плоская. Ну и много "паразитной" разметки получается как следствие.

На практике выходит, что придерживаться только одного стиля не получает у схема-составителей. Обычно приходится иметь дело с гибридной моделью. Где вполне себе подчиненные логике мета-данные вынесены в атрибуты, другие же почему-то в дочерние элементы. Иногда кажется, что просто для ...

Вчера джанга сделал ещё один существенный шаг на пути к долгожданному релизу 1.0. На этот раз посчастливилось обновиться инфраструктуре сигналов. Основное и главное отличие новой подсистемы сигналов - это почти двукратное увеличение производительности.

Исторически сигналы в джанге были сделаны на базе пакета pyDispatcher. который почти без изменений был скопирован в django.dispatch. Со временем выяснилось, что он избыточен и медленен.

Сигналы практически везде пронизывают код джанги. Повесить обработчик можно и на изменение объекта, и на начало и конец обработчик запроса и рендеринг шаблона и много чего ещё. Причем они не только предоставляют некий интерфейс взаимодействия с внешним миром, но и активно применяются внутри самой джанги. Например, удаление загруженных файлов вслед за объектами и закрытие соединения с базой при завершении обработки запроса(!).

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

Возможности погонять тесты у меня нет, так что поверим разработчикам на слово. Лучше ...

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

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

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

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

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

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

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

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

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

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

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