company_banner

DjangoCon Europe 2019. А не сдох ли ваш пони?

    image

    С 9 по 14 апреля в Копенгагене проходила конференция DjangoCon Europe 2019. Полный надежд и стремлений я прибыл на данное мероприятие, а уезжал в глубоком смятении. В статье я попробую передать мои впечатления от конференции и прокомментировать столь резкую смену отношения к Django.
    Disclaimer: в статье присутствует нетолерантность, безаппеляционность суждений и неоправданная критика.

    Привет всем, я Максим, живу в Австрии, в Тироле. Я преподаватель в GeekBrains и совладелец проекта winePad, это коллектор и продавец технических данных по алкогольным напиткам. Обычно это данные о винах.

    Про проект winePad
    У нас самая точная база данных в Европе. Это потому что все вина в базе проверены нашими специалистами лично. Коротко о нашей работе: бухать. И порой это бывает жёстко: когда по 40 апробаций в день, следующим утром я не всегда уверен, как попал домой. Ну или не помню, где припаркована машина.

    Проект начинался в 2012 с Django 1.4 / Python 2.7 на сервере, и с Jquery на клиенте + JsonRPC сервером. Сейчас набор технологий увеличился. Все равно мы уперлись в буквальном смысле в Django.

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

    Рассказ о тирольских пастухах, резко переквалифицировавшихся в программисты, я оставлю за кадром. Если вы увидите их решения, уверен, вам резко захочется убивать всех, кто называет себя «тирольским программистом».

    К февралю 2019 стало понятно: развитие проекта невозможно с текущим набором технологий. В поисках ответов я решил съездить на DjangoCon 2019, который очень вовремя проходил в Копенгагене. Что хотелось от конференции:

    1. Поучиться у профессионалов, посмотреть, что я могу улучшить в своей работе.
    2. Окунуться в мир новых решений для моей платформы.
    3. Потусить с такими же Django-задротами, как и я. Войти, так сказать, в тусовку.
    4. Понять, что не так с 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.

    Воркшоп про переезд на новую версию кода без остановки сервера


    История про десятимесячную операцию на сердце коде из 100 моделей. Проект был создан три раза:

    1. Со старыми моделями.
    2. Со старыми и новыми моделями и возможностью online-переключения.
    3. Без старых моделей и переключателей.

    Долго и дорого.

    Из-за этого воркшопа я пропустил три лекции, о двух отзывались хорошо, буду смотреть в записи:

    • 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, если вы не готовы пока бросать эту дохлую лошадь. Библиотеки, как интегрировать, как тестировать. Starlet, SQLAlchemy, Jinja-templates и т.д., подробнее смотрите в слайдах.

    Вариант, что делать дальше тем, кто хочет слезть. Пока нет решения «так же, как в Django». Был обзор существующих аналогов, быстродействие, сложности, перспективы. Я уже попробовал упомянутый GO, мне почти понравилось.

    На молниях я рискнул выступить с призывом пилить Django и дальше. Только после выступления Тома Кристи — призыв звучал совсем неубедительно.



    Следующие два дня состояли из спринтов. Те, кто остался, работали с Django: открывали сообщения об ошибках и правили их.



    После успешной правки можно было подбежать и грохнуть в гонг на весь зал. Частота бумов была каждые 5-7 минут.

    Для интереса, что происходит на спринтах
    Я посмотрел одну из одобренных правок: исправление ошибки конвертации числа в строку. (#30363 — Do not use exponential notation for small decimal) файл django/utils/numberformat.py
    И мне стало совсем грустно:
    • Правка содержит ошибку возвращаемого типа.
    • В код добавлено две ненужных рекурсии.
    • Автор, похоже, не понял, как работает 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-разработки, я обязательно упомяну на курсе важные моменты, о которых я узнал на конференции.
    Mail.ru Group
    1123,00
    Строим Интернет
    Поддержать автора
    Поделиться публикацией

    Похожие публикации

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

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

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

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

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

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

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

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


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


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


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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                Очень порадовал доклад про поддержку большого проекта на 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
                                                  0
                                                  proofit404 Привет, там они что-то упоминали в презентации от Радослава Геогиева. Надо видео пересматривать, я уже не помню. И да, твой доклад очень похож. Это же круто! Люди продолжают развивать подобные мысли далее в разных странах. Мне показалось что большее ударение у них идет на композиции.
                                                    0
                                                    Наш dependencies как раз про композицию.
                                                  0
                                                  Давно собираюсь поизучать питон. Всегда держал на заметке джанго. После этой статьи мысли повернулись в сторону фласка.
                                                  Есть разница? Кто-то может подтвердить что с фласком все не так печально?
                                                    0

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


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

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

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

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

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


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


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


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


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

                                                          0
                                                          mjr27 Спасибо. Только я выше ответ написал, что админские формы косячны как никогда, и вот еще одно подтверждение, что не только мне так кажется. И про типизацию тоже согласен, однако они уже начали это исправлять в р3. Но только, как говорят, горбатого не исправят мелкие доработки :)
                                                          А миграции косячные не напрягали? Сейчас получше но все равно. А распределение прав доступа? Тоже большой пласт недоработок.
                                                            +2
                                                            начали это исправлять в р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 уже несколько лет как не нужен.

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

                                                              А как же mypy?
                                                                0

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

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

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


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


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

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

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

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

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

                                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                        Самое читаемое