Комментарии 71
Я не задумываясь пошел в бой, но по итогу выяснилось:
1. Архитектор в понимании заказчика это некая примесь бизнес аналитика и бекенд разработчика (точнее разработчика моделей с бизнес логикой) — того человека, который быстро вникнет в суть доменной области и перенесет это в код
2. Заказчик навязывает строго свою архитектуру хотя относится больше к продакт овнерам. Даже хватанул слово «толстая модель» что-бы это не значило.
3. Всем плевать на качество оформления кода. Нужно чтоб работало, о том как это рефакторить никто не думает (У заказчика это НЕ ПЕРВЫЙ крупный проект, он этим занимается с десяток лет!!!)
В итоге проконсультировавшись с другими Django разработчиками (не только из данного проекта) я провел аналогию Django с разработкой 1С — такой себе закрытый мирок со сложившимися правилами, люди хорошо понимают доменную модель и у них есть платформа у которой есть все из коробки, не самый сложный язык программирования а значит возможность быстро решать бизнес задачи не особо заботясь о других аспектах разработки.
P.s Простите уважаемые Django разработчики если я не прав. Все это личное мнение, основанное на моем скудном опыте.
То я первый месяц жутко плевался на джанго и питон. Так как бизнес задачи я решал за 30м-2ч на пхп и потом переносил это на джангу, порой до нескольких дней.
Но прошёл месяц и я перестал плеваться.
Прошёл второй месяц и я понял, что больше никогда не вернусь в пхп. При этом я не жалею о годах, проведённым с ним.
Как по мне, так ASGI и Channels − это не тупик, а как раз шаг в правильном направлении, к компромису между производительностью программиста и машины.
Я знаю Джанго, какая она сейчас. Это инструмент для решения определенного количества задач. Лично мой проект уперся в пределы «Джанго без доработок». Я тоже увидел решение в Uvicorn, Asgi и т.п. Жаль только, что я все еще остаюсь на Джанго с ее косяками. Меня не расстраивает будущее с батарейками. Меня расстраивает машинка, под батарейки.
Косяки DjangoAdminForms:
В инлайнах нельзя вставлять инлайны, предлагалось решать чудовищным внешним «nested forms», хотя если влезть в код станет понятно, что проблема с фиксированным Fieldset встроенной формы. Правка кода — 4 символа. Я отправил тикет, сам у себя уже давно это исправил.
еще косяк: есть фиелдс, фиелдсет и инлайны. но инлайны нельзя класть посередине филдсета. Решения даже на сайте а лебедева публиковалось. через внешний виджет и доп поле. НО это бред. все Решается через создание инлайновых форм ссылающихся на саму себя и передачи в фабричный метод генератора инлайн псевдоинлайн модели. десяток строк кода.
Еще косяк: В инлайн модели метод адд фиелд добавляет поле удалить к любому объекту, даже к тому, который запрещено править текущему пользователю. Решается переопределением add_field
Это только один маленький пример про те вещи, которые мало кто пользует потому эти ошибки не исправлены с версии 1.2 до текущей. Мной открыты тикеты и предложены решения… но никому не надо. Я очень много работал с внутренним кодом, множество атавизмов остались от изначальной CMS, в официальной документации отмечено, что некоторые вещи исправляться не будут.
Мне нравится режим очистки данных формами (для быстроты возьмем формы из реста).
Этакий ламповый конструктор, в котором уютно.
В Джанго не решена вообще проблема мультиязычности. Есть внешние решения HVAD и модель-транслейшн и все. В моем мультиязычном проекте пришлось городить велосипед, потому как ближайшее решение «парлер» еще хуже старого HVAD. Это один из существенных недостатков для меня.
Это милый-старый монстр который потихоньку сдохнет, если отношение Django Foundation к разработке проекта коренным образом не поменяется.
Сойдет за мнение?
Offtopic по поводу прикосновения… Думаю, как хорошо, что я не эмигрировал в Европу/США, хотя сильное желание когда-то было, и начинал какие-то подвижки в эту сторону.
Недавно познакомился с девушкой, которая несколько лет живет в Европе. Рассказывает мне, что в кафе к ней несколько раз подсаживались знакомиться. Явно польщена таким вниманием. И тут же говорит мне: «Попробовали бы они познакомиться так со мной в XXX! Там все уже выдрессированы, что даже смотреть в мою сторону нельзя!» WTF??? Потом она же жалуется на проблемы с отношениями в Европе.
Мне одному кажется, что здесь есть какое-то фундаментальное противоречие?.. Или уж позволять знакомиться и смотреть на себя, или не жаловаться на проблемы со знакомствами и отношениями.
По поводу конференции: интересно и грустно. Вроде бы нашел на YouTube запись, постараюсь найти время посмотреть.
Я и раньше подозревал: Похоже, что у многие мужики тут сильно боятся неадекватных последствий со стороны женщин, и потому у них зарождается голубая мечта иметь друга.
Интересно, что было бы, если в ответ назваться геем и сказать, что пришлось себя перебороть, чтобы проявить такой жест уважения как к замечательному лектору? Извинялись бы перед вами? :-)
У меня много вопросов! :)
- С какой целью вы решили потрогать незнакомого человека?
- Вы считаете что трогать незнакомых людей (независимо от пола) — это не нормально?
- Вам самому приятно когда вас трогают незнакомые люди?
По мне — трогать норм. Кто хочет меня потрогать — да на здоровье.
Хотя с этой конференции подозреваю чем такой подход может аукнуться.
Я к тому, что нужно учитывать что не всем это нравится и не во всех культурах это приемлемо. А международные конференции — это места где все должны себя чувствовать в безопасности независимо от пола, религии и сексуальных предпочтений.
P.S.: Во втором вопросе хотел написал "это нормально?"
В некоторых местах принято гостей в губы целовать, например. Всех подряд. Вы бы как на это отреагировали? А им норм.
Размножаться они явно планируют пыльцой в будущемА оно нужно?
Во-первых, население планеты стремительно растёт, и с этим надо что-то делать. Хорошо, если обойдётся мирно.
Во-вторых, развитие медицины и пропаганда ЗОЖ привели к тому, что средняя продолжительность жизни сильно выросла. Конкретно в Европе, правда, рост замедлился сейчас, но в Северной Америке, например, продолжает стремительно расти. Если так пойдёт и дальше, то не исключено достижение точки сингулярности: когда люди просто перестанут успевать умирать (практически бессмертие). Нужны ли в таких условиях дети?
В-третьих, не за горами искусственная матка, а суррогатное материнство работает и становится всё доступнее уже сейчас. Зачем девять месяцев мучиться и ходить с брюхом, если можно поручить это дело исполнителю из бедных стран? Для извлечения половых клеток контакт между родителями не нужен совершенно. Мало того, полно детей в приютах — зачем зачинать своих?
В-четвёртых, семейная жизнь отнимает много времени, которое разумнее потратить на что-то полезное для общества — хобби, например, — а не распылять усилия на мизерную его ячейку. Вы, похоже, плохо знакомы с европейским менталитетом, они даже еду дома уже почти не готовят, пользуются повально общепитами — потому что так рациональнее. И воспитание детей уверенно становится уделом тех, кому это «по фану» (см. те же семейные детские дома), а не всеобщим занятием.
Когда Том сказал, «я вообще не думаю, что возможно построить высоконагруженную быструю систему на 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 это совсем не про скорость выполнения. Если прям нужно выжать производительность до последнего, то есть Cython, PyPy и пр. Кстати, на том же Moscow Python Conf++ 2019 был доклад как ускорять код.
А то, что в Django и DRF много чего накручено — есть такое. В какой-то момент у нас сериализатор из DRF стал узким местом, но переписали на свой, и стало лучше.
Когда Том сказал, «я вообще не думаю, что возможно построить высоконагруженную быструю систему на Python», народ притих.
Смотря что считать высоконагруженной asyncio + uvloop думаю вполне покроют требования среднего бизнеса, а вот гигантам да, придётся писать на чём-то вроде раста, но сколько их тех гигантов?
Т.е. когда у вас REST/CRUD всё терпимо, а если в доменной области есть какие-то сценарии (обработка входящего платежа например), то это уже не вписывается в модель, хотя должно быть исходя их MVC.
Удобно — относящиеся к платежам сущности у вас в git в отдельном месте.
IDE с этим нормально работает, хорошо читаемо.
Мне кажется, довольно правильной схема, когда пишем прототип, первую версию на чем-то простом, удобном, легком — так чтобы быстро и дешево реализовывалось. Набиваем шишки. Правим (тоже легко и быстро).
Затем проект либо умирает, либо остается на небольшом уровне (крутится на 1 среднем сервере). Либо же становится супер-успешным, дико растет, «новый Google». И вот только в третьем случае нам важно переписывать его на чем-то более шустром.
Одна из мудростей которые я постиг — не нужно решать проблемы, которые не возникли и вряд ли возникнут.
Просто в последнее время все кинулись в асинхронность, хотя это далеко не всегда надо и не всегда оправданно.
Очень порадовал доклад про поддержку большого проекта на 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
Есть разница? Кто-то может подтвердить что с фласком все не так печально?
Если честно, то все равно, на самом-то деле. Не хочу сказать, что они совсем-совсем одинаковые, но разницы между ними немного.
Плюс (для меня — большой плюс) 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 лет. Но сейчас есть и куда более продуктивные языки/платформы.
А миграции косячные не напрягали? Сейчас получше но все равно. А распределение прав доступа? Тоже большой пласт недоработок.
начали это исправлять в р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?
За это время появились более молодые языки, которые агрессивно входят на рынок ЯП.
Выбор за тобой.
Не-не-не. Python не на пустом месте стал "языком по умолчанию" в большинстве областей. Не могу сказать, что его знать на сегодняшний день прямо таки обязательно, но очень желательно.
Если на задачу "налазит" интерпретируемый язык с динамической типизацией, то я большинстве случаев все еще выберу python — количество библиотек и продуманный синтаксис с минимумом визуального мусора сильно помогают.
Просто универсальных решений нет, и быть не может. Ниша python огромна, но не всеобъемлюща, и под мои задачи мне в какой-то момент стали оптимальны другие решения.
По поводу дохлого пони. В целом, все решаемо. Django отличный framework, а Том Кристи отличный докладчик. Если собираешься обслуживать миллиарды клиентов, не стоит заблуждаться насчет того, что все будет шикарно работать на одном хосте. Облака — белогривые лошадки. Времена изменились. Научитесь «понимать» «между строк».
DjangoCon Europe 2019. А не сдох ли ваш пони?