Как стать автором
Обновить

Комментарии 71

Я когда-то хотел войти в мир Django разработки и нашел на фрилансе заказчика с достаточно крупным проектом. Хотя я толком не имел опыта работы в Django но другие мои скилы заинтересовали заказчика и он сразу же попросил меня сделать тестовое задание на архитектора проекта.
Я не задумываясь пошел в бой, но по итогу выяснилось:
1. Архитектор в понимании заказчика это некая примесь бизнес аналитика и бекенд разработчика (точнее разработчика моделей с бизнес логикой) — того человека, который быстро вникнет в суть доменной области и перенесет это в код
2. Заказчик навязывает строго свою архитектуру хотя относится больше к продакт овнерам. Даже хватанул слово «толстая модель» что-бы это не значило.
3. Всем плевать на качество оформления кода. Нужно чтоб работало, о том как это рефакторить никто не думает (У заказчика это НЕ ПЕРВЫЙ крупный проект, он этим занимается с десяток лет!!!)

В итоге проконсультировавшись с другими Django разработчиками (не только из данного проекта) я провел аналогию Django с разработкой 1С — такой себе закрытый мирок со сложившимися правилами, люди хорошо понимают доменную модель и у них есть платформа у которой есть все из коробки, не самый сложный язык программирования а значит возможность быстро решать бизнес задачи не особо заботясь о других аспектах разработки.
P.s Простите уважаемые Django разработчики если я не прав. Все это личное мнение, основанное на моем скудном опыте.
Зависит от того что и как разрабатывать. Если вот в описанном стиле, то хоть на хаскеле оно будет как в 1С. Это не проблема языка и фреймворка.
valis, я согласен с Deepwalker, что нет зависимости какой это фреймворк. Мне кажется что есть эдакое время жизни проекта и сообщества вокруг него, после которого проект превращается в «закрытый мирок со сложившимися правилами». И, собственно, все.
Я когда, примерно после 8 лет, сидения на ПХП и его фреймворках/цмс, в первые попробовал питон/джанго. При том сразу на действующем проекте, так как переманили, но с правом пару месяцев вникать.
То я первый месяц жутко плевался на джанго и питон. Так как бизнес задачи я решал за 30м-2ч на пхп и потом переносил это на джангу, порой до нескольких дней.
Но прошёл месяц и я перестал плеваться.
Прошёл второй месяц и я понял, что больше никогда не вернусь в пхп. При этом я не жалею о годах, проведённым с ним.
Я пришёл в мир Django из мира 1С и по поводу аналогии полностью с вами согласен :)
Я не очень понимаю, почему кооперативную многопоточность считают «будущим» чего-либо. Для меня она тоже around since forever, взять twisted для примера, не говоря уже о том, чтобы выйти за пределы Python-экосистемы. Она действительно даёт возможность ускорить обработку запросов, иногда просто драматически. Но зато она сложна для понимания человеком, и ни промисы, ни async/await тут не помогут. И сто́ит чуть-чуть оступиться − и у тебя в проекте блокировка, которую ты не знаешь, как отладить.

Как по мне, так ASGI и Channels − это не тупик, а как раз шаг в правильном направлении, к компромису между производительностью программиста и машины.
Tanner я думаю, что ты прав, в том, что речь идет еще об одном механизме. Он не лучше и не хуже, и не обязательно «будущее».
Я знаю Джанго, какая она сейчас. Это инструмент для решения определенного количества задач. Лично мой проект уперся в пределы «Джанго без доработок». Я тоже увидел решение в Uvicorn, Asgi и т.п. Жаль только, что я все еще остаюсь на Джанго с ее косяками. Меня не расстраивает будущее с батарейками. Меня расстраивает машинка, под батарейки.
Было бы интересно узнать об этом. В смысле пределов и косяков. Пишите ещё.
НАПРИМЕР:
Косяки DjangoAdminForms:
В инлайнах нельзя вставлять инлайны, предлагалось решать чудовищным внешним «nested forms», хотя если влезть в код станет понятно, что проблема с фиксированным Fieldset встроенной формы. Правка кода — 4 символа. Я отправил тикет, сам у себя уже давно это исправил.
еще косяк: есть фиелдс, фиелдсет и инлайны. но инлайны нельзя класть посередине филдсета. Решения даже на сайте а лебедева публиковалось. через внешний виджет и доп поле. НО это бред. все Решается через создание инлайновых форм ссылающихся на саму себя и передачи в фабричный метод генератора инлайн псевдоинлайн модели. десяток строк кода.
Еще косяк: В инлайн модели метод адд фиелд добавляет поле удалить к любому объекту, даже к тому, который запрещено править текущему пользователю. Решается переопределением add_field
Это только один маленький пример про те вещи, которые мало кто пользует потому эти ошибки не исправлены с версии 1.2 до текущей. Мной открыты тикеты и предложены решения… но никому не надо. Я очень много работал с внутренним кодом, множество атавизмов остались от изначальной CMS, в официальной документации отмечено, что некоторые вещи исправляться не будут.
Внесу свои 5 копеек. Существует очень старая проблема с DjangoAdmin. При сохранении/изменении объекта в админке, при наличии связей Many2Many, они затираются, и подставляются из формы. И если, допустим, ты захочешь автоматически проставлять связи, тебе придётся проделывать это дважды, при сохранении объекта и после очистки связей админкой.
я думаю, проще было бы переопределить в modeladminform.save_m2m()
плюсую комментарий выше. сам в сомнениях о ней. хотел бы услышать ваше мнение
Мне нравится Джанго. На ней я могу решить все задачи, что у меня есть. Работать будет медленно но надежно. Я люблю GCBV, и мне приятно работать с ними.
Мне нравится режим очистки данных формами (для быстроты возьмем формы из реста).
Этакий ламповый конструктор, в котором уютно.

В Джанго не решена вообще проблема мультиязычности. Есть внешние решения HVAD и модель-транслейшн и все. В моем мультиязычном проекте пришлось городить велосипед, потому как ближайшее решение «парлер» еще хуже старого HVAD. Это один из существенных недостатков для меня.

Это милый-старый монстр который потихоньку сдохнет, если отношение Django Foundation к разработке проекта коренным образом не поменяется.

Сойдет за мнение?

Offtopic по поводу прикосновения… Думаю, как хорошо, что я не эмигрировал в Европу/США, хотя сильное желание когда-то было, и начинал какие-то подвижки в эту сторону.


Недавно познакомился с девушкой, которая несколько лет живет в Европе. Рассказывает мне, что в кафе к ней несколько раз подсаживались знакомиться. Явно польщена таким вниманием. И тут же говорит мне: «Попробовали бы они познакомиться так со мной в XXX! Там все уже выдрессированы, что даже смотреть в мою сторону нельзя!» WTF??? Потом она же жалуется на проблемы с отношениями в Европе.


Мне одному кажется, что здесь есть какое-то фундаментальное противоречие?.. Или уж позволять знакомиться и смотреть на себя, или не жаловаться на проблемы со знакомствами и отношениями.


По поводу конференции: интересно и грустно. Вроде бы нашел на YouTube запись, постараюсь найти время посмотреть.

immaculate это не оффтоп. Меня напугало обвинение в Харрасменте. Дичь какая-то. Размножаться они явно планируют пыльцой в будущем.

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

Интересно, что было бы, если в ответ назваться геем и сказать, что пришлось себя перебороть, чтобы проявить такой жест уважения как к замечательному лектору? Извинялись бы перед вами? :-)

А мне нравится идея! Жаль не могу заплюсить.

У меня много вопросов! :)


  1. С какой целью вы решили потрогать незнакомого человека?
  2. Вы считаете что трогать незнакомых людей (независимо от пола) — это не нормально?
  3. Вам самому приятно когда вас трогают незнакомые люди?
Я телесно ориентирован, потому не всегда успеваю подумать перед потрогать.
По мне — трогать норм. Кто хочет меня потрогать — да на здоровье.
Хотя с этой конференции подозреваю чем такой подход может аукнуться.

Я к тому, что нужно учитывать что не всем это нравится и не во всех культурах это приемлемо. А международные конференции — это места где все должны себя чувствовать в безопасности независимо от пола, религии и сексуальных предпочтений.


P.S.: Во втором вопросе хотел написал "это нормально?"

Чьто этот ʁусский дикаʁ себье позволат? ;-)

В некоторых местах принято гостей в губы целовать, например. Всех подряд. Вы бы как на это отреагировали? А им норм.
НЛО прилетело и опубликовало эту надпись здесь
Я тут подумал, что использование тела для коммуникации у меня появилось уже тут, в Австрии. В начале я язык знал не очень хорошо. Пока работал горнолыжным инструктором, для коммуникации использовал жесты и прикосновения (типа повернись сюда). И за десять лет это, похоже, укоренилось. Подозреваю, что для людей не из спорта это может быть странным.
Размножаться они явно планируют пыльцой в будущем
А оно нужно?

Во-первых, население планеты стремительно растёт, и с этим надо что-то делать. Хорошо, если обойдётся мирно.

Во-вторых, развитие медицины и пропаганда ЗОЖ привели к тому, что средняя продолжительность жизни сильно выросла. Конкретно в Европе, правда, рост замедлился сейчас, но в Северной Америке, например, продолжает стремительно расти. Если так пойдёт и дальше, то не исключено достижение точки сингулярности: когда люди просто перестанут успевать умирать (практически бессмертие). Нужны ли в таких условиях дети?

В-третьих, не за горами искусственная матка, а суррогатное материнство работает и становится всё доступнее уже сейчас. Зачем девять месяцев мучиться и ходить с брюхом, если можно поручить это дело исполнителю из бедных стран? Для извлечения половых клеток контакт между родителями не нужен совершенно. Мало того, полно детей в приютах — зачем зачинать своих?

В-четвёртых, семейная жизнь отнимает много времени, которое разумнее потратить на что-то полезное для общества — хобби, например, — а не распылять усилия на мизерную его ячейку. Вы, похоже, плохо знакомы с европейским менталитетом, они даже еду дома уже почти не готовят, пользуются повально общепитами — потому что так рациональнее. И воспитание детей уверенно становится уделом тех, кому это «по фану» (см. те же семейные детские дома), а не всеобщим занятием.
Я живу в Австрии, в Тироле уже 10 лет. Есть друзья Австрийцы. Знаю ли я менталитет? Европа-ли этот Тироль? Но как-то тут все проще кажется, чем в этих ваших европах. :)
Когда Том сказал, «я вообще не думаю, что возможно построить высоконагруженную быструю систему на Python», народ притих.

А он только сейчас пришел к такому выводу, или раньше этот факт не имел значения?
Это впечатляюще прозвучало из уст Тома. Надеюсь, что видео передает тот шарм, с которым прошла лекция. Само «шоу» не опровергло того, что многие знали. Просто доклад Тома был красиво построен.

Например, есть соседняя тема про Moscow Python Conf++ 2019. Там лектор в докладе Python vs Go сказал что Go до десяти раз быстрее… и? Да ничего не произошло. Народ! В ДЕСЯТЬ РАЗ!!! Ага, да в 10 раз, и дальше что? и т.д.

Факт так и остался фактом. Питонировать никто не бросил.
Сказать-то можно что угодно, некоторые говорят что производительность сравнимая:
Fast: Very high performance, on par with NodeJS and Go (thanks to Starlette and Pydantic). One of the fastest Python frameworks available.
Да, Python медленный, но меня это не волнует
Python это совсем не про скорость выполнения. Если прям нужно выжать производительность до последнего, то есть Cython, PyPy и пр. Кстати, на том же Moscow Python Conf++ 2019 был доклад как ускорять код.

А то, что в Django и DRF много чего накручено — есть такое. В какой-то момент у нас сериализатор из DRF стал узким местом, но переписали на свой, и стало лучше.
Когда Том сказал, «я вообще не думаю, что возможно построить высоконагруженную быструю систему на Python», народ притих.

Смотря что считать высоконагруженной asyncio + uvloop думаю вполне покроют требования среднего бизнеса, а вот гигантам да, придётся писать на чём-то вроде раста, но сколько их тех гигантов?
В джанге меня смущает то, что они модель прибила намертво гвоздями к таблице в базе (это написано в доке), что вобщем-то не соответствует самому слову «модель», модель это отражение предметной области, её логика, а не только хранимые сущности.
Т.е. когда у вас REST/CRUD всё терпимо, а если в доменной области есть какие-то сценарии (обработка входящего платежа например), то это уже не вписывается в модель, хотя должно быть исходя их MVC.
На мой взгляд, такую логику надо выносить в слой сервисов. А в модели оставлять класс, отражающий сущность из бд и базовые методы типа get_table_name.
Не знаю, что у вас называется слоем сервисов, но если речь про отдельные микро/макро сервисы вне джанги на каком-то другом фреймворке, то тогда вопрос насколько джанга нужна.
Нет-нет, я про service-layer в архитектуре приложений. Уровень абстракции, в котором удобно размещать бизнес-логику, чтобы избежать «толстых моделей» и бизнес-логики во view. Для этого удобно использовать библиотеку django-service-objects.
Да, это похоже на правильное решение, спасибо за наводку.
Я создаю отдельный класс типа paymentCore, в отдельном файлике(вообще в отдельном каталоге) и использую множественное наследование в View классе.
Удобно — относящиеся к платежам сущности у вас в git в отдельном месте.
IDE с этим нормально работает, хорошо читаемо.
Способов можно много разных придумать, но на то они и фремворки, чтобы давать правильный каркас.
А что скажете про streamfield от wagtail?
Да вобщем-то ничего, к обсуждаемому вопросу, на первый взгляд отношения не имеет.
Спасибо за статью, работаю системным администратором, многое автоматизировал на работе с помощью Python, восхищён этим языком программирования, недавно начал изучать Django, в планах перейти потом в веб разработку, тем более что есть небольшой опыт в JS ( AngularJS, Nodejs), обидно что так с Django получается, неужели не стоит теперь для бекенда его рассматривать?
Да рассматривай на здоровье. Норм фреймворк. Для начала уж тем более. Главное не забывай, джанго достигло своей формы. Ее будут шлифовать, править ошибки, но она останется синхронным фреймворком с синхронным ORM с синхронным драйвером к БД. Чего на 2019г тебе хватит в большинстве случаев.
Только на 2019?

Мне кажется, довольно правильной схема, когда пишем прототип, первую версию на чем-то простом, удобном, легком — так чтобы быстро и дешево реализовывалось. Набиваем шишки. Правим (тоже легко и быстро).

Затем проект либо умирает, либо остается на небольшом уровне (крутится на 1 среднем сервере). Либо же становится супер-успешным, дико растет, «новый Google». И вот только в третьем случае нам важно переписывать его на чем-то более шустром.

Одна из мудростей которые я постиг — не нужно решать проблемы, которые не возникли и вряд ли возникнут.
веб-разработка на питоне не ограничивается джангой :)
Используйте Джангу на здоровье. В моём понимании, это лучшее, что было написано на Питоне для веба. Лучшая документация, туча компонентов, вполне достаточная скорость. Что ещё надо? Для 95% всех веб-сайтов и сервисов джанго нормально будет работать.

Просто в последнее время все кинулись в асинхронность, хотя это далеко не всегда надо и не всегда оправданно.
Всем привет.

Очень порадовал доклад про поддержку большого проекта на Django 10000 коммитов спустя.

Гексагональная архитектура Кокбёрна и Чистая архитектура Мартина очень крутые и массивные штуки.

Что Django, что Flask, не дают никаких инструментов для их построения.

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

Как раз чтобы решить эту проблему начал писать проект dry-python.org

Это набор небольших инструментов для построения высокоуровневой архитектуры приложения. Проект ставит целью дать ответы на вопрос «Как грамотно декомпозировать и реализовать бизнес задачу.»

Например, описывать Юзкейсы можно декларативным DSL. Из него растет продвинутая интеграция с Sentry, Pytest и Debug ToolBar stories.readthedocs.io/en/latest/why.html

Отделить реализацию от бизнес логики можно с помощью Dependency Injection. Из плюсов опять же интеграция с Django, Flask, Celery и Pytest. dependencies.readthedocs.io/en/latest/why.html

Есть проект на Django с примером реализации небольшого магазина, реализованный на утилитах dry-python github.com/dry-python/tutorials

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

cc danilovmy dimuska139 valis
proofit404 Привет, там они что-то упоминали в презентации от Радослава Геогиева. Надо видео пересматривать, я уже не помню. И да, твой доклад очень похож. Это же круто! Люди продолжают развивать подобные мысли далее в разных странах. Мне показалось что большее ударение у них идет на композиции.
Наш dependencies как раз про композицию.
Давно собираюсь поизучать питон. Всегда держал на заметке джанго. После этой статьи мысли повернулись в сторону фласка.
Есть разница? Кто-то может подтвердить что с фласком все не так печально?

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


Плюс (для меня — большой плюс) django в том, что там из коробки огромная куча "батареек" (с одной из лучших документаций, которые я видел), которые для flask'а нужно искать и подбирать под конкретных проект. ОРМ, шаблоны, формы, админка, авторизация/регистрания и т.д и т.п.

Да, фласк часто хвалят. Простые вещи там сделать легко. А вот со сложными — можно наплясаться с бубном.

Вот, несколько ссылок с критикой:
asvetlov.blogspot.com/2014/10/flask_20.html
habr.com/ru/post/320360
www.youtube.com/watch?v=7SmWn05m1Tk

Для начала посмотрите Джангу. Там многие вещи сделаны логично.
Мне кажется, лучше самому попробовать написать полноценный проект сначала на одном, а потом на другом. И сравнить.
Я иногда попиливаю свой проект на джанго, знаю его на уровне любителя. Часто говорят, что джанго уже содержит множество готовых решений 'из коробки', но у меня почему-то начинает сладываться впечатление, что эти решения очень часто все равно приходится переписывать самому.

На правах ноунейма, которому Django обеспечивала кусок хлеба с сыром в период с v0.96 по v1.11, хочу констатировать два прискорбных наблюдения (не возьму на себя наглости назвать их фактами), к которым пришел года полтора назад.


Первый (более очевидный) django безнадежно устарел и не способен удовлетворить современные потребности в большей части задач, с которыми сталкиваюсь лично я. Список претензий длинный (и привычно ругаемая всеми ORM, что интересно, в него даже не входит). Основное — это то, что большую часть компонентов (шаблоны, формы, админка, DRF и т.п.) получается удобней не использовать изначально, чем через некоторое время упереться в стену "а дальше либо с костылями, либо никак".


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


И второй (менее очевидный) — то же самое касается Python'а как такового в контексте web-разработки. Нет, это у меня все еще язык по умолчанию для автоматизации/одноразовых скриптов/конверторов и прочего. Но время, когда на вопрос "How fast is Python" был достаточен ответ "Fast enough" уже ушло в прошлое. Тут накопившийся список претензий у меня не менее длинный — и огромный virtualenv (для сборки которого еще зачастую нужно плясать с бубном в поисках нужных пакетов в multistage билдах), и GIL, и общая неторопливость языка (включая сборку мусора), да и динамическая типизация уже порядком утомила.


Это были хорошие 10 лет. Но сейчас есть и куда более продуктивные языки/платформы.

mjr27 Спасибо. Только я выше ответ написал, что админские формы косячны как никогда, и вот еще одно подтверждение, что не только мне так кажется. И про типизацию тоже согласен, однако они уже начали это исправлять в р3. Но только, как говорят, горбатого не исправят мелкие доработки :)
А миграции косячные не напрягали? Сейчас получше но все равно. А распределение прав доступа? Тоже большой пласт недоработок.
начали это исправлять в р3

И да и нет. Type hinting — это чисто поддержка в IDE. То же самое и в докстринге написать можно. Хочется, чтобы оно этап создания AST цепляло, а этого и в планах нет.


TypeError: unsupported operand type(s) for +: 'int' and 'str' 

Не икнулось? )


миграции косячные не напрягали

Это вы еще в Entity Framework миграций косячных не видели.


А распределение прав доступа?

Я их в последний раз видел, когда django учил, если честно. Они странными получились. Вроде как очень функциональные, гибкие… но в то же время ни на одну нужную систему прав так и не ложились, приходилось костылить. Is_staff, is_admin, а остальное — по стариночке.


Оффтопик о том, куда бежать

Вообще немного проспойлерю (выше все равно спалился) — я в итоге остановился на asp.net core и в целом доволен. Раздражающие вещи, разумеется, есть (куда ж без них). Но это очень близко к тому, о чем я мечтал последние лет 10.


Переносил по свободе один специфический "микросервис" с django, удивило, что кол-во LOC выросло всего процентов на 20, если скобочки не считать. Response time снизился в 2.5 раза. Докер-контейнер на прод вместо 5 минут стал собираться за минуту, а прод билд — это пяток файлов на 3-5мб в сумме. И всё.


Не хочу сказать, что скорость разработки выросла, но и не упала.


Короче рекомендую взлянуть. Windows уже несколько лет как не нужен.

Type hinting — это чисто поддержка в IDE. То же самое и в докстринге написать можно.

А как же mypy?

Согласен. Если честно, совсем забыл о его существовании.
В свое оправдание могу сказать одно — когда я его в последний раз смотрел, cо stub'ами все было очень плохо, а без них терялся всякий смысл. Что сейчас — честно скажу, не знаю.

может я ошибаюсь, но исходя из сказанного вами пайтон не стоит рассматривать как современный язык от слова совсем?!
Мне Python нравится, и его потихонечку допиливают до нормального состояния. Вопрос в том, как долго его будут пилить. Пока получается как в мультике с черепашкой, которая никак не могла подобрать правильную одежду под время года.
За это время появились более молодые языки, которые агрессивно входят на рынок ЯП.
Выбор за тобой.
Вопрос больше был mjr27, но благодарю, что ответили) Молодые этот тот же Rust and Go? Или еще что?! Думаю, что проблема допиливания, это проблема всех «старых» языков. Да, конечно важно, чтобы язык отвечал современным требованиям, но, думаю, что тут проблема, а что делать с теми тоннами строк кода которые уже были написаны. Это не вопрос даже обратной совместимости, а поддержки, что ли. Поэтому скорее всего во время допиливания, приходится все время оглядываться назад, имхо.

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


Если на задачу "налазит" интерпретируемый язык с динамической типизацией, то я большинстве случаев все еще выберу python — количество библиотек и продуманный синтаксис с минимумом визуального мусора сильно помогают.


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

благодарю за ответ, да к сожалению или может к счастью) универсальных решений нет. Для каждой области свое подходящее решение. И везде есть свои prons and cons)
Cлайд про thread-based vs co-operative вызывает некоторое недоумение: довольно странно приводить в качестве примеров «более нового» подхода Node и Go. В Twisted или ASIO это было реализовано, когда никакой Node еще и в помине не было, не говоря уже про Go.
Привет, спасибо за твистед, Торнадо видел, а Твистед что-то мимо меня прошел. Они показались мне очень похожи.
А ASIO, что ты имел ввиду? asyncio, так он же только с недавнего питона? Или я что то упустил?
Не, я имел в виду библиотеку ASIO из C++, которая впоследствии стала Boost.ASIO :) Это, конечно, не совсем из области Web-фреймворков, но принцип работы тот же. Просто привел для примера, что подход отнюдь не новый, а появился примерно в то же время, что и первая спецификация WSGI.
После просмотра sketching out django redesign мне кажется что мы с вами смотрели абсолютно разные доклады. Том не говорил что джанго надо переписать на другом языке, а сравнение с го и нодой было для того чтобы показать что питон с uvicorn по concurrency сравним с обоими. Более того переписывать пол-джанги нужно не потому что она такая плохая, а потому что ее архитектура (как и архитектура всех остальных завязанных на uwsgi решений) не совместима с async. Ну и закончилось все вообще довольно позитивно — предложенный им полностью асинхронный фреймворк с django-подобным api можно использовать хоть сейчас, несмотря на сырость. Ну и в конце он упомянул что есть вполне реалистичный путь для постепенного приведения джанги к этой архитектуре, так что мне этот доклад показался очень оптимистичным.

Все верно. Мы смотрели одно и то же. Только общее ощущение от конференции видать повлияло на повествование.

Все понятно, но ничего не ясно…
Вопрос был:
Назовите пожалуйста докладчика «Редизайн вашего проекта Django»
Отвечаю:
Доклад: «Maintaning a Django codebase after 10k commits»
Speakers: Joachim Jablon, Stéphane «Twidi» Angel
Интересно мнение автора об фреймворке Websauna. Давно его использовал, но тогда он был намного гибче чем Django. Правда порог входа повыше.
Из всех Django конференций, на которых мне довелось быть, больше всего понравилась Django Under the Hood, традиционно проходящая в Амстердаме. Выступают исключительно главные разработчики или члены совета Django (Django core team member, member of the Django foundation). Слабых докладов нет вообще. Рекомендую.

По поводу дохлого пони. В целом, все решаемо. Django отличный framework, а Том Кристи отличный докладчик. Если собираешься обслуживать миллиарды клиентов, не стоит заблуждаться насчет того, что все будет шикарно работать на одном хосте. Облака — белогривые лошадки. Времена изменились. Научитесь «понимать» «между строк».
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.