С 9 по 14 апреля в Копенгагене проходила конференция DjangoCon Europe 2019. Полный надежд и стремлений я прибыл на данное мероприятие, а уезжал в глубоком смятении. В статье я попробую передать мои впечатления от конференции и прокомментировать столь резкую смену отношения к Django.
Disclaimer: в статье присутствует нетолерантность, безаппеляционность суждений и неоправданная критика.
Привет всем, я Максим, живу в Австрии, в Тироле. Я преподаватель в GeekBrains и совладелец проекта winePad, это коллектор и продавец технических данных по алкогольным напиткам. Обычно это данные о винах.
Проект начинался в 2012 с Django 1.4 / Python 2.7 на сервере, и с Jquery на клиенте + JsonRPC сервером. Сейчас набор технологий увеличился. Все равно мы уперлись в буквальном смысле в Django.
Я подключился к проекту в 2015, переняв эстафету у тирольских разработчиков. От некачественной реализации шевелились волосы везде.
Рассказ о тирольских пастухах, резко переквалифицировавшихся в программисты, я оставлю за кадром. Если вы увидите их решения, уверен, вам резко захочется убивать всех, кто называет себя «тирольским программистом».
К февралю 2019 стало понятно: развитие проекта невозможно с текущим набором технологий. В поисках ответов я решил съездить на DjangoCon 2019, который очень вовремя проходил в Копенгагене. Что хотелось от конференции:
- Поучиться у профессионалов, посмотреть, что я могу улучшить в своей работе.
- Окунуться в мир новых решений для моей платформы.
- Потусить с такими же Django-задротами, как и я. Войти, так сказать, в тусовку.
- Понять, что не так с Django. С 2016 года регулярно посещают мысли, что я что-то упускаю. Только не могу понять что.
Что же из всего этого получилось:
Нулевой день
Во вторник днем, до начала конференции, проходило собрание Django Girls — это инициатива DjangoFoundation по продвижению Django в женские массы. С 17 часов началась регистрация. В роли бейджей выступали 3-дюймовые дискеты, любой желающий мог записать на дискету все, что хотел (ха-ха), USB-дисководы присутствовали.
Во все дни конференции было неограниченное количество крафтового пива с этикеткой «розовый Django-пони», из местной небольшой пивоварни. С одной стороны прикольно, с другой… так себе пиво. В оформлении залов присутствовали розовые летающие лошадки всех размеров.
От ненавязчивого символизма и ощущения причастности к сообществу лошадиных пастухов был особый веселящий привкус. Я познакомился с Russell Keith-Magee, многолетним бессменным разработчиком Django. Все прибывшие на эту конференцию зависят от его программных решений.
Покупая билет, я должен был согласиться на соблюдение правил конференции по открытости, толерантности, конструктивному критицизму и уважению сексуальных предпочтений участников. Соглашаясь на это, я и не подозревал, к чему это может привести…
Тут я впервые узнал про правило Pacman-a: если к кругу разговаривающих подходит ещё один человек, участники беседы ДОЛЖНЫ расступиться и освободить место для нового собеседника. В общем, можно было бухать и жрать чипсы (в любом количестве), знакомиться с прибывающими специалистами, присоединяться к абсолютно любому разговору, дергать организаторов.
Вечером я прогулялся по Копенгагену.
Милый городок на берегу холодного моря, немного напомнил Питер. Тут слишком перебарщивают с велосипедами, но за рыбные рестораны можно простить все. Это очень вкусно.
В первые три дня конференции доклады шли в зале на 500 человек (было 377 участников). Параллельно в отдельных залах были воркшопы. Большинство докладов записаны на видео, вы можете посмотреть их на YouTube. Трансляций воркшопов нет. Список и описание докладов и воркшопов тут. ВСЕ воркшопы без исключения были очень плохо подготовлены, это отмечали и остальные участники.
В перерывах предлагалось много еды и кофе. В этом плане конференция была хорошо подготовлена. Стенды спонсоров, в основном HR, ненавязчиво стояли в холле. Мне было интересно поболтать со скандинавскими хедхантерами.
День первый
Открывающая лекция про ситуацию с DjangoProject
Коротко: помогите кто чем может.
Воркшоп GraphQL
JSON для ленивых. Жизнь не станет лучше, если все начнут использовать другую нотацию запросов.
Life is hAPIer
Враппер Django REST, начните писать 4 строки кода вместо 6.
Воркшоп про переезд на новую версию кода без остановки сервера
История про десятимесячную операцию на
- Со старыми моделями.
- Со старыми и новыми моделями и возможностью online-переключения.
- Без старых моделей и переключателей.
Долго и дорого.
Из-за этого воркшопа я пропустил три лекции, о двух отзывались хорошо, буду смотреть в записи:
- pull-реквест на 750 000 строк.
- Django web-security-headers.
После перерыва с очередной цистерной кофе была лекция про DJANGO-ORM. Докладчик — Sigurd Ljodal. Это разработчик текущего ORM, его деятельность можно посмотреть по репозиторию Django.
Доклад полезный, но меня расстроил. С одной стороны — новая ORM-Django очень повзрослела. С другой стороны — Sigurd использовал в примерах недокументированные возможности
queryset.query. На последующем общении с Sigurd меня поразило, что он, как и большинство Django-разработчиков, не очень знает методы queryset.query.«Чего ж ты их в примерах используешь!» — вопрошал я. «Ну… вот так...» — отвечал Sigurd.
После всех докладов шли «lightning talks» («молнии»). Доклады-пятиминутки для тех, кто стихийно захотел выступить. «Молнии» в основном были интересны, но пять минут — этого мало. Цель докладчика заинтересовать, а люди потом могут спрашивать.
Несколько грузовиков с пивом и долгие разговоры после «lightning talks»… Первый день завершен.
День второй
Воркшоп: Бутстрап Django
Не получился.
Распознавание картинок, машинное обучение с Django
Никакого обучения, использование внешних ресурсов, косяки в распознавании, смешные картинки в примерах. Ни о чем, но весело.
Воркшоп по распознаванию картинок
Все заработало, и картинка по ее части была найдена среди 10 других. Но скорость работы перечеркнула все. 20 секунд на подготовку, 30-40 секунд на поиск. Я посчитал: на однократный поиск в нашем проекте по картинкам уйдут годы. А у нас в день десятки тысяч подобных запросов. Предложенное решение мне не подходит.
Визуальное тестирование изменений
Фронтэндщикам может быть полезно.
SQL-Alchemy vs Django-ORM
Докладчик Глеб из DjangoStars. С идеей согласен, но некоторые вещи я бы все равно реализовал через методы DJANGO-ORM. Главное, что я увидел, где можно применить алхимию в моем проекте.
Воркшоп: полный путь request/response по пищепроводу Django
Полезно было освежить знания. Django-разработчик, помни: все что ты делаешь — это настройка WSGI-приложения.
Дальше я загорелся идеей выступить на «молниях». Я делал презентацию и пропустил несколько докладов.
Божественный доклад о ведении документации проекта
От руководителя команды документации RedHat.
Я подскочил поблагодарить докладчицу после. Она понятно рассказала, почему я должен все бросить и начать документировать свой проект. В момент благодарности я прикоснулся к ее предплечью. Что тут началось!!! Это песец. Я думал меня посадят. Все обошлось словесным взысканием за неподобающее поведение по отношению к другому участнику конференции.
Пентестинг при помощи ZAP
Приложение попробует все известные ей методы взломать указанный сайт.
Сразу захотелось попробовать хакнуть свой проект.
Молнии были полезнее, чем в первый день.
Александр (DjangoStars) рассказал о вариантах хранения settings
Рассказ о враппере для полей моделей
Враппер следит за возвращаемым типом значения.
Доклад про установку заглушек вместо показа приватных данных клиентов
Пригодится на этапе разработки, тестирования и логирования. В эпоху поголовного действия закона о защите данных об этом стоит задуматься. Увы, автор так и не ответил, зачем он заново изобрел декоратор
@sensitive_variables. Похоже, что он просто не читал документацию.Доклад об использовании переменных с зоной видимости в рамках одного потока
Я использую подобное решение давно. Скажу только, использование глобальных переменных в Django — это от недостатка умений и от незнания архитектуры.
После двух дней конференции я был расстроен: пару полезных докладов за три дня. Очень мало про Django, очень много про посторонние и ненужные решения. WTF??? И даже Копенгаген меня не успокоил.
Гениальный третий день
Этот день окупил все страдания, развеял сомнения и принес еще больше печали. Мой совет — изучайте все, что вы найдете про доклады третьего дня. Такую крутую инъекцию знаний редко где можно найти.
Доклад про убийства в викторианскую эпоху
Девушка рассказала на пальцах причину появления закона о защите данных пользователей. Мне стала понятна глубинная причина появления такого закона. Проблема с защитой данных, как и проблема с электроизоляцией — случайно кого-то может убить.
Использование GeoDjango с примерами
От автора документации по GeoDjango. Красота.
У меня это запланировано в проекте. Теперь я знаю, как это реализовать.
Архитектор Эластик групп о программных продуктах компании
Сюда входит elasticsearch.
Понравился пример, как встроить график активности пользователей в админ-панель Django.
Полный цикл создания собственного поля модели
Мне понравилось: у меня есть несколько своих полей, но я многое упустил в процессе их создания.
Система «плагинов» Django
Плагин включается и выключается на лету, проверка включения через… сигналы. Слишком экзотичный вариант решения, чтобы использовать. Разок прокатит под соусом «смотри, как еще можно».
Потом я повелся на речи про elasticsearch и пошел на воркшоп. Тут я пропустил два доклада и потерял время.
А вот что было потом, можно многократно пересказывать в красках. С каждым разом приходит более глубокое понимание сути услышанного.
Редизайн вашего проекта Django
Разработчики рано или поздно сталкиваются с рекомендацией: Fat Models, skinny Views, stupid Templates (тупые шаблоны, тонкие вьюхи, толстые модели).
От себя дополню: выборка объектов только в методах
ObjectManager и в методах QuerySet, порожденных ObjectManager.Дальше такого перераспределения кода мало кто ушел. В докладе были примеры максимального устранения зависимостей и полного абстрагирования бизнес-логики.
Это солидный урок последователям каноничного стиля разделения кода. Устойчивость от изменений. Независимость решения… Все то, что и должно быть в качественном продукте. В конце доклада приводилась литература, которая поможет это реализовать.
Супер полезно.
Потом были речи и закрытие официальной части DjangoCon.
А потом был доклад, ответивший на все мои вопросы и подтвердивший мои ощущения.
Наброски для редизайна Django
Докладчик — Том Кристи, создатель Django REST framework. В слайдах Том рассказал и показал в примерах кода, почему Django (и, как следствие, DRF) больше не имеет возможностей развития. Да, можно исправлять ошибки, да можно добавлять финтифлюшки или улучшать ORM. Общая же форма Django все равно остается неизменной.
Когда Том сказал, «я вообще не думаю, что возможно построить высоконагруженную быструю систему на Python», народ притих.
Дальше Том показал примеры кода, как решить вопросы асинхронности в Django-проектах и какие проблемы последуют.
Для асинхронного ORM были упомянуты Ариадна и недоделанный асинхронный DB-драйвер. Для шаблонов Jinja и переделывание кода шаблонов.
Доклад четко обрисовал, что для создания из Django фреймворка, готового к современным технологиям, надо переписать все, что есть в Django. И желательно на другом языке. Было ясно, что Django в тупике развития, красивом, уютном, и устаревшем лет на 10.
Вариант, что делать дальше тем, кто хочет слезть. Пока нет решения «так же, как в Django». Был обзор существующих аналогов, быстродействие, сложности, перспективы. Я уже попробовал упомянутый GO, мне почти понравилось.
На молниях я рискнул выступить с призывом пилить Django и дальше. Только после выступления Тома Кристи — призыв звучал совсем неубедительно.
Следующие два дня состояли из спринтов. Те, кто остался, работали с Django: открывали сообщения об ошибках и правили их.
После успешной правки можно было подбежать и грохнуть в гонг на весь зал. Частота бумов была каждые 5-7 минут.
И мне стало совсем грустно:
- Правка содержит ошибку возвращаемого типа.
- В код добавлено две ненужных рекурсии.
- Автор, похоже, не понял, как работает
Decimal. - Тесты не проверяют все граничные случаи и возвращаемый тип данных.
Я переписал код и подошел к одобрившему предыдущую правку, и сказал: у вас тут ошибка! И выбрал неверную стратегию: программисты не очень любят, когда кто-то говорит про их ошибки, особенно про проверенные и одобренные.
Лучше бы было показать баг-репорт. Мне конечно же ответили, что это так и должно быть. Проверкой типов в питоне никто не занимается и, вообще, питон — язык без строгой типизации. И потому, мальчик, иди-ка ты лесом, тут и без тебя дел много. Столь неграмотного отношения к редактуре кода, и невосприимчивости к указанию на ошибку я не ожидал.
Отсюда вытекает еще одна проблема, почему Django такая, какая она есть: часто ошибки правят люди, не понимающие алгоритм или идею. Именно поэтому появляются новые ошибки, кривые методы типа
QuerySet.as_manager, неотключаемый GROUP_BY в запросе с base_sort=True (не проверял, может исправили), или же алогичные решения, как с формсетами и инлайнами в AdminModelForm.Кроме спринтов было пару воркшопов, мне понравился повтор про ZAP. Крякнуть сайт удалось, и дыры в безопасности были найдены.
Я посетил Христианию, погулял по каналам и посмотрел на русалочку.
Домой я уезжал в задумчивости. Я хотел увидеть новые возможности в Django… а нашел их где-то еще. Я хотел донести, что есть быстрое и верное решение… и не сумел (про баг я все же сообщу). Хотел войти в профессиональный мир… но что-то не так я себе это представлял. Знание приносит печаль. Главное, что я знаю, куда идти дальше.
P.S. Решение про мой проект принято, пока winePad останется на Django.
P.P.S. Я открыт для обсуждения как конференции, так и Django. Спрашивайте, если непонятно.
P.P.P.S. С 20-го июня 2019 на GeekBrains стартует мой курс по Django на факультете Python-разработки, я обязательно упомяну на курсе важные моменты, о которых я узнал на конференции.
Комментарии (58)
Tanner
24.04.2019 14:26Я не очень понимаю, почему кооперативную многопоточность считают «будущим» чего-либо. Для меня она тоже around since forever, взять twisted для примера, не говоря уже о том, чтобы выйти за пределы Python-экосистемы. Она действительно даёт возможность ускорить обработку запросов, иногда просто драматически. Но зато она сложна для понимания человеком, и ни промисы, ни async/await тут не помогут. И сто?ит чуть-чуть оступиться ? и у тебя в проекте блокировка, которую ты не знаешь, как отладить.
Как по мне, так ASGI и Channels ? это не тупик, а как раз шаг в правильном направлении, к компромису между производительностью программиста и машины.
danilovmy Автор
24.04.2019 14:44Tanner я думаю, что ты прав, в том, что речь идет еще об одном механизме. Он не лучше и не хуже, и не обязательно «будущее».
Я знаю Джанго, какая она сейчас. Это инструмент для решения определенного количества задач. Лично мой проект уперся в пределы «Джанго без доработок». Я тоже увидел решение в Uvicorn, Asgi и т.п. Жаль только, что я все еще остаюсь на Джанго с ее косяками. Меня не расстраивает будущее с батарейками. Меня расстраивает машинка, под батарейки.Tanner
24.04.2019 15:01Было бы интересно узнать об этом. В смысле пределов и косяков. Пишите ещё.
danilovmy Автор
24.04.2019 21:54НАПРИМЕР:
Косяки DjangoAdminForms:
В инлайнах нельзя вставлять инлайны, предлагалось решать чудовищным внешним «nested forms», хотя если влезть в код станет понятно, что проблема с фиксированным Fieldset встроенной формы. Правка кода — 4 символа. Я отправил тикет, сам у себя уже давно это исправил.
еще косяк: есть фиелдс, фиелдсет и инлайны. но инлайны нельзя класть посередине филдсета. Решения даже на сайте а лебедева публиковалось. через внешний виджет и доп поле. НО это бред. все Решается через создание инлайновых форм ссылающихся на саму себя и передачи в фабричный метод генератора инлайн псевдоинлайн модели. десяток строк кода.
Еще косяк: В инлайн модели метод адд фиелд добавляет поле удалить к любому объекту, даже к тому, который запрещено править текущему пользователю. Решается переопределением add_field
Это только один маленький пример про те вещи, которые мало кто пользует потому эти ошибки не исправлены с версии 1.2 до текущей. Мной открыты тикеты и предложены решения… но никому не надо. Я очень много работал с внутренним кодом, множество атавизмов остались от изначальной CMS, в официальной документации отмечено, что некоторые вещи исправляться не будут.
gostrit
25.04.2019 22:14Внесу свои 5 копеек. Существует очень старая проблема с DjangoAdmin. При сохранении/изменении объекта в админке, при наличии связей Many2Many, они затираются, и подставляются из формы. И если, допустим, ты захочешь автоматически проставлять связи, тебе придётся проделывать это дважды, при сохранении объекта и после очистки связей админкой.
mariner
24.04.2019 20:57плюсую комментарий выше. сам в сомнениях о ней. хотел бы услышать ваше мнение
danilovmy Автор
24.04.2019 22:07Мне нравится Джанго. На ней я могу решить все задачи, что у меня есть. Работать будет медленно но надежно. Я люблю GCBV, и мне приятно работать с ними.
Мне нравится режим очистки данных формами (для быстроты возьмем формы из реста).
Этакий ламповый конструктор, в котором уютно.
В Джанго не решена вообще проблема мультиязычности. Есть внешние решения HVAD и модель-транслейшн и все. В моем мультиязычном проекте пришлось городить велосипед, потому как ближайшее решение «парлер» еще хуже старого HVAD. Это один из существенных недостатков для меня.
Это милый-старый монстр который потихоньку сдохнет, если отношение Django Foundation к разработке проекта коренным образом не поменяется.
Сойдет за мнение?
immaculate
24.04.2019 14:40Offtopic по поводу прикосновения… Думаю, как хорошо, что я не эмигрировал в Европу/США, хотя сильное желание когда-то было, и начинал какие-то подвижки в эту сторону.
Недавно познакомился с девушкой, которая несколько лет живет в Европе. Рассказывает мне, что в кафе к ней несколько раз подсаживались знакомиться. Явно польщена таким вниманием. И тут же говорит мне: «Попробовали бы они познакомиться так со мной в XXX! Там все уже выдрессированы, что даже смотреть в мою сторону нельзя!» WTF??? Потом она же жалуется на проблемы с отношениями в Европе.
Мне одному кажется, что здесь есть какое-то фундаментальное противоречие?.. Или уж позволять знакомиться и смотреть на себя, или не жаловаться на проблемы со знакомствами и отношениями.
По поводу конференции: интересно и грустно. Вроде бы нашел на YouTube запись, постараюсь найти время посмотреть.
danilovmy Автор
24.04.2019 14:48-1immaculate это не оффтоп. Меня напугало обвинение в Харрасменте. Дичь какая-то. Размножаться они явно планируют пыльцой в будущем.
Я и раньше подозревал: Похоже, что у многие мужики тут сильно боятся неадекватных последствий со стороны женщин, и потому у них зарождается голубая мечта иметь друга.
m1kola
24.04.2019 18:53+1У меня много вопросов! :)
- С какой целью вы решили потрогать незнакомого человека?
- Вы считаете что трогать незнакомых людей (независимо от пола) — это не нормально?
- Вам самому приятно когда вас трогают незнакомые люди?
danilovmy Автор
24.04.2019 19:03+1Я телесно ориентирован, потому не всегда успеваю подумать перед потрогать.
По мне — трогать норм. Кто хочет меня потрогать — да на здоровье.
Хотя с этой конференции подозреваю чем такой подход может аукнуться.m1kola
25.04.2019 03:05+1Я к тому, что нужно учитывать что не всем это нравится и не во всех культурах это приемлемо. А международные конференции — это места где все должны себя чувствовать в безопасности независимо от пола, религии и сексуальных предпочтений.
P.S.: Во втором вопросе хотел написал "это нормально?"
bodqhrohro
28.04.2019 14:47Размножаться они явно планируют пыльцой в будущем
А оно нужно?
Во-первых, население планеты стремительно растёт, и с этим надо что-то делать. Хорошо, если обойдётся мирно.
Во-вторых, развитие медицины и пропаганда ЗОЖ привели к тому, что средняя продолжительность жизни сильно выросла. Конкретно в Европе, правда, рост замедлился сейчас, но в Северной Америке, например, продолжает стремительно расти. Если так пойдёт и дальше, то не исключено достижение точки сингулярности: когда люди просто перестанут успевать умирать (практически бессмертие). Нужны ли в таких условиях дети?
В-третьих, не за горами искусственная матка, а суррогатное материнство работает и становится всё доступнее уже сейчас. Зачем девять месяцев мучиться и ходить с брюхом, если можно поручить это дело исполнителю из бедных стран? Для извлечения половых клеток контакт между родителями не нужен совершенно. Мало того, полно детей в приютах — зачем зачинать своих?
В-четвёртых, семейная жизнь отнимает много времени, которое разумнее потратить на что-то полезное для общества — хобби, например, — а не распылять усилия на мизерную его ячейку. Вы, похоже, плохо знакомы с европейским менталитетом, они даже еду дома уже почти не готовят, пользуются повально общепитами — потому что так рациональнее. И воспитание детей уверенно становится уделом тех, кому это «по фану» (см. те же семейные детские дома), а не всеобщим занятием.
Umpiro
24.04.2019 15:54Когда Том сказал, «я вообще не думаю, что возможно построить высоконагруженную быструю систему на Python», народ притих.
А он только сейчас пришел к такому выводу, или раньше этот факт не имел значения?danilovmy Автор
24.04.2019 16:08Это впечатляюще прозвучало из уст Тома. Надеюсь, что видео передает тот шарм, с которым прошла лекция. Само «шоу» не опровергло того, что многие знали. Просто доклад Тома был красиво построен.
Например, есть соседняя тема про Moscow Python Conf++ 2019. Там лектор в докладе Python vs Go сказал что Go до десяти раз быстрее… и? Да ничего не произошло. Народ! В ДЕСЯТЬ РАЗ!!! Ага, да в 10 раз, и дальше что? и т.д.
Факт так и остался фактом. Питонировать никто не бросил.
worldmind
24.04.2019 16:20Сказать-то можно что угодно, некоторые говорят что производительность сравнимая:
Fast: Very high performance, on par with NodeJS and Go (thanks to Starlette and Pydantic). One of the fastest Python frameworks available.
TyVik
25.04.2019 09:35Да, Python медленный, но меня это не волнует
Python это совсем не про скорость выполнения. Если прям нужно выжать производительность до последнего, то есть Cython, PyPy и пр. Кстати, на том же Moscow Python Conf++ 2019 был доклад как ускорять код.
А то, что в Django и DRF много чего накручено — есть такое. В какой-то момент у нас сериализатор из DRF стал узким местом, но переписали на свой, и стало лучше.
worldmind
24.04.2019 16:17Когда Том сказал, «я вообще не думаю, что возможно построить высоконагруженную быструю систему на Python», народ притих.
Смотря что считать высоконагруженной asyncio + uvloop думаю вполне покроют требования среднего бизнеса, а вот гигантам да, придётся писать на чём-то вроде раста, но сколько их тех гигантов?
worldmind
24.04.2019 16:25В джанге меня смущает то, что они модель прибила намертво гвоздями к таблице в базе (это написано в доке), что вобщем-то не соответствует самому слову «модель», модель это отражение предметной области, её логика, а не только хранимые сущности.
Т.е. когда у вас REST/CRUD всё терпимо, а если в доменной области есть какие-то сценарии (обработка входящего платежа например), то это уже не вписывается в модель, хотя должно быть исходя их MVC.
dimuska139
24.04.2019 17:20На мой взгляд, такую логику надо выносить в слой сервисов. А в модели оставлять класс, отражающий сущность из бд и базовые методы типа get_table_name.
worldmind
24.04.2019 17:38Не знаю, что у вас называется слоем сервисов, но если речь про отдельные микро/макро сервисы вне джанги на каком-то другом фреймворке, то тогда вопрос насколько джанга нужна.
dimuska139
24.04.2019 17:42+1Нет-нет, я про service-layer в архитектуре приложений. Уровень абстракции, в котором удобно размещать бизнес-логику, чтобы избежать «толстых моделей» и бизнес-логики во view. Для этого удобно использовать библиотеку django-service-objects.
arheops
25.04.2019 00:05Я создаю отдельный класс типа paymentCore, в отдельном файлике(вообще в отдельном каталоге) и использую множественное наследование в View классе.
Удобно — относящиеся к платежам сущности у вас в git в отдельном месте.
IDE с этим нормально работает, хорошо читаемо.worldmind
25.04.2019 10:07Способов можно много разных придумать, но на то они и фремворки, чтобы давать правильный каркас.
Nikola_Piterskiy
26.04.2019 13:52А что скажете про streamfield от wagtail?
worldmind
26.04.2019 14:33Да вобщем-то ничего, к обсуждаемому вопросу, на первый взгляд отношения не имеет.
Anshi85
24.04.2019 16:36Спасибо за статью, работаю системным администратором, многое автоматизировал на работе с помощью Python, восхищён этим языком программирования, недавно начал изучать Django, в планах перейти потом в веб разработку, тем более что есть небольшой опыт в JS ( AngularJS, Nodejs), обидно что так с Django получается, неужели не стоит теперь для бекенда его рассматривать?
danilovmy Автор
24.04.2019 17:23Да рассматривай на здоровье. Норм фреймворк. Для начала уж тем более. Главное не забывай, джанго достигло своей формы. Ее будут шлифовать, править ошибки, но она останется синхронным фреймворком с синхронным ORM с синхронным драйвером к БД. Чего на 2019г тебе хватит в большинстве случаев.
xenon
25.04.2019 01:27+1Только на 2019?
Мне кажется, довольно правильной схема, когда пишем прототип, первую версию на чем-то простом, удобном, легком — так чтобы быстро и дешево реализовывалось. Набиваем шишки. Правим (тоже легко и быстро).
Затем проект либо умирает, либо остается на небольшом уровне (крутится на 1 среднем сервере). Либо же становится супер-успешным, дико растет, «новый Google». И вот только в третьем случае нам важно переписывать его на чем-то более шустром.
Одна из мудростей которые я постиг — не нужно решать проблемы, которые не возникли и вряд ли возникнут.
hardtop
25.04.2019 09:40+1Используйте Джангу на здоровье. В моём понимании, это лучшее, что было написано на Питоне для веба. Лучшая документация, туча компонентов, вполне достаточная скорость. Что ещё надо? Для 95% всех веб-сайтов и сервисов джанго нормально будет работать.
Просто в последнее время все кинулись в асинхронность, хотя это далеко не всегда надо и не всегда оправданно.
proofit404
24.04.2019 18:29+1Всем привет.
Очень порадовал доклад про поддержку большого проекта на 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 valisdanilovmy Автор
24.04.2019 19:09proofit404 Привет, там они что-то упоминали в презентации от Радослава Геогиева. Надо видео пересматривать, я уже не помню. И да, твой доклад очень похож. Это же круто! Люди продолжают развивать подобные мысли далее в разных странах. Мне показалось что большее ударение у них идет на композиции.
dzsysop
24.04.2019 23:52Давно собираюсь поизучать питон. Всегда держал на заметке джанго. После этой статьи мысли повернулись в сторону фласка.
Есть разница? Кто-то может подтвердить что с фласком все не так печально?
mjr27
25.04.2019 00:18Если честно, то все равно, на самом-то деле. Не хочу сказать, что они совсем-совсем одинаковые, но разницы между ними немного.
Плюс (для меня — большой плюс) django в том, что там из коробки огромная куча "батареек" (с одной из лучших документаций, которые я видел), которые для flask'а нужно искать и подбирать под конкретных проект. ОРМ, шаблоны, формы, админка, авторизация/регистрания и т.д и т.п.
hardtop
25.04.2019 09:50Да, фласк часто хвалят. Простые вещи там сделать легко. А вот со сложными — можно наплясаться с бубном.
Вот, несколько ссылок с критикой:
asvetlov.blogspot.com/2014/10/flask_20.html
habr.com/ru/post/320360
www.youtube.com/watch?v=7SmWn05m1Tk
Для начала посмотрите Джангу. Там многие вещи сделаны логично.
Umpiro
25.04.2019 15:29Мне кажется, лучше самому попробовать написать полноценный проект сначала на одном, а потом на другом. И сравнить.
Я иногда попиливаю свой проект на джанго, знаю его на уровне любителя. Часто говорят, что джанго уже содержит множество готовых решений 'из коробки', но у меня почему-то начинает сладываться впечатление, что эти решения очень часто все равно приходится переписывать самому.
mjr27
25.04.2019 00:12+1На правах ноунейма, которому Django обеспечивала кусок хлеба с сыром в период с v0.96 по v1.11, хочу констатировать два прискорбных наблюдения (не возьму на себя наглости назвать их фактами), к которым пришел года полтора назад.
Первый (более очевидный) django безнадежно устарел и не способен удовлетворить современные потребности в большей части задач, с которыми сталкиваюсь лично я. Список претензий длинный (и привычно ругаемая всеми ORM, что интересно, в него даже не входит). Основное — это то, что большую часть компонентов (шаблоны, формы, админка, DRF и т.п.) получается удобней не использовать изначально, чем через некоторое время упереться в стену "а дальше либо с костылями, либо никак".
Нет, это все еще отличных фреймворк для определенной категории сайтов. Только вот эта категория стала сильно реже встречаться. Сейчас все больше сервисы да толстые фронтенды. А вот с этим у django все ну совсем туго.
И второй (менее очевидный) — то же самое касается Python'а как такового в контексте web-разработки. Нет, это у меня все еще язык по умолчанию для автоматизации/одноразовых скриптов/конверторов и прочего. Но время, когда на вопрос "How fast is Python" был достаточен ответ "Fast enough" уже ушло в прошлое. Тут накопившийся список претензий у меня не менее длинный — и огромный virtualenv (для сборки которого еще зачастую нужно плясать с бубном в поисках нужных пакетов в multistage билдах), и GIL, и общая неторопливость языка (включая сборку мусора), да и динамическая типизация уже порядком утомила.
Это были хорошие 10 лет. Но сейчас есть и куда более продуктивные языки/платформы.
danilovmy Автор
25.04.2019 00:37mjr27 Спасибо. Только я выше ответ написал, что админские формы косячны как никогда, и вот еще одно подтверждение, что не только мне так кажется. И про типизацию тоже согласен, однако они уже начали это исправлять в р3. Но только, как говорят, горбатого не исправят мелкие доработки :)
А миграции косячные не напрягали? Сейчас получше но все равно. А распределение прав доступа? Тоже большой пласт недоработок.mjr27
25.04.2019 01:13+1начали это исправлять в р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 уже несколько лет как не нужен.
LighteR
26.04.2019 10:54Type hinting — это чисто поддержка в IDE. То же самое и в докстринге написать можно.
А как же mypy?
dakuan
25.04.2019 06:49Cлайд про thread-based vs co-operative вызывает некоторое недоумение: довольно странно приводить в качестве примеров «более нового» подхода Node и Go. В Twisted или ASIO это было реализовано, когда никакой Node еще и в помине не было, не говоря уже про Go.
danilovmy Автор
25.04.2019 22:24Привет, спасибо за твистед, Торнадо видел, а Твистед что-то мимо меня прошел. Они показались мне очень похожи.
А ASIO, что ты имел ввиду? asyncio, так он же только с недавнего питона? Или я что то упустил?dakuan
26.04.2019 01:25Не, я имел в виду библиотеку ASIO из C++, которая впоследствии стала Boost.ASIO :) Это, конечно, не совсем из области Web-фреймворков, но принцип работы тот же. Просто привел для примера, что подход отнюдь не новый, а появился примерно в то же время, что и первая спецификация WSGI.
l27_0_0_1
25.04.2019 12:37После просмотра sketching out django redesign мне кажется что мы с вами смотрели абсолютно разные доклады. Том не говорил что джанго надо переписать на другом языке, а сравнение с го и нодой было для того чтобы показать что питон с uvicorn по concurrency сравним с обоими. Более того переписывать пол-джанги нужно не потому что она такая плохая, а потому что ее архитектура (как и архитектура всех остальных завязанных на uwsgi решений) не совместима с async. Ну и закончилось все вообще довольно позитивно — предложенный им полностью асинхронный фреймворк с django-подобным api можно использовать хоть сейчас, несмотря на сырость. Ну и в конце он упомянул что есть вполне реалистичный путь для постепенного приведения джанги к этой архитектуре, так что мне этот доклад показался очень оптимистичным.
danilovmy Автор
25.04.2019 13:15Все верно. Мы смотрели одно и то же. Только общее ощущение от конференции видать повлияло на повествование.
valis
Я когда-то хотел войти в мир Django разработки и нашел на фрилансе заказчика с достаточно крупным проектом. Хотя я толком не имел опыта работы в Django но другие мои скилы заинтересовали заказчика и он сразу же попросил меня сделать тестовое задание на архитектора проекта.
Я не задумываясь пошел в бой, но по итогу выяснилось:
1. Архитектор в понимании заказчика это некая примесь бизнес аналитика и бекенд разработчика (точнее разработчика моделей с бизнес логикой) — того человека, который быстро вникнет в суть доменной области и перенесет это в код
2. Заказчик навязывает строго свою архитектуру хотя относится больше к продакт овнерам. Даже хватанул слово «толстая модель» что-бы это не значило.
3. Всем плевать на качество оформления кода. Нужно чтоб работало, о том как это рефакторить никто не думает (У заказчика это НЕ ПЕРВЫЙ крупный проект, он этим занимается с десяток лет!!!)
В итоге проконсультировавшись с другими Django разработчиками (не только из данного проекта) я провел аналогию Django с разработкой 1С — такой себе закрытый мирок со сложившимися правилами, люди хорошо понимают доменную модель и у них есть платформа у которой есть все из коробки, не самый сложный язык программирования а значит возможность быстро решать бизнес задачи не особо заботясь о других аспектах разработки.
P.s Простите уважаемые Django разработчики если я не прав. Все это личное мнение, основанное на моем скудном опыте.
Deepwalker
Зависит от того что и как разрабатывать. Если вот в описанном стиле, то хоть на хаскеле оно будет как в 1С. Это не проблема языка и фреймворка.
danilovmy Автор
valis, я согласен с Deepwalker, что нет зависимости какой это фреймворк. Мне кажется что есть эдакое время жизни проекта и сообщества вокруг него, после которого проект превращается в «закрытый мирок со сложившимися правилами». И, собственно, все.
syschel
Я когда, примерно после 8 лет, сидения на ПХП и его фреймворках/цмс, в первые попробовал питон/джанго. При том сразу на действующем проекте, так как переманили, но с правом пару месяцев вникать.
То я первый месяц жутко плевался на джанго и питон. Так как бизнес задачи я решал за 30м-2ч на пхп и потом переносил это на джангу, порой до нескольких дней.
Но прошёл месяц и я перестал плеваться.
Прошёл второй месяц и я понял, что больше никогда не вернусь в пхп. При этом я не жалею о годах, проведённым с ним.
SkyHunter
Я пришёл в мир Django из мира 1С и по поводу аналогии полностью с вами согласен :)