openapi-codegen работает значительно лучше, по крайне мере для python и typescript. Он поддерживает не все фишки, к сожалению, но клиенты работают довольно неплохо.
Не выкидывайте. Но суть в том, что расшифровки докладов и текстовые трансляции — это штуки, которые в большей мере служат для рекламы этой конференции и делаются в рамках рекламной компании… Не будет хабра — они появятся на других крупных площадках, тот же medium или reddit.
И в рамках тезиса "Хабр — это довольно доверенный источник информации," использовать их в качестве примера классный технических статей мне кажется неправильным.
инициаторы и самые активные комментаторы-кармонытики, как правило, пользователи с сильно (ну или не сильно) отрицательной кармой.
Звучит как "Борцы за права афроамериканцев, как правило, афроамериканцы". Удивительная тенденция, но люди чаще выступают против проблемы, когда столкнулись с ней.
Особенно забавным мне кажется, как легко слить карму в комментариях и как тяжело в них же ее заработать.
Скорее пилить с нуля на Odoo, но без модулей sale, mrp и так далее, из-за того, что бизнес-процессы заказчиков сильно отличались от бизнес-процессов заложенных в эти модули и где-то на середине разработки они начали только мешать внезапным поведением, которые приходилось костылить.
Хабр — это довольно доверенный источник информации, на статьи отсюда ссылаются преподаватели, ссылки на готовые решения в постах и на Тостере (тот что нынче Хабр Q&A) кидают друг другу коллеги в компаниях, по постам на Хабре о работодателе судят соискатели, а сами работодатели изучают профили соискателей. Поэтому если на него рванёт «пикабушное ажайти» — это будет резкий удар по достоверности и хардкорности информации.
Эм… простите, а вы на каком хабре сидите? Мне кажется, соотношение классная детальная техническая статья/обычный пост, как на медиуме уже давно не в пользу этого утверждения. А если еще выкинуть расшифровки докладов, то станет очень печально.
Во-вторых, за всё надо платить. Мой код пожертвовал возможностью менять требования в угоду сокращения объёма дублирования. Цена этой жертвы была слишком высока. Например, позже нам понадобилось обрабатывать множество особых условий и вариантов поведения для различных маркеров разных фигур. Мою абстракцию для поддержки подобных требований пришлось бы основательно усложнить. А вот в исходную «неаккуратную» версию кода подобные изменения вносились легче лёгкого.
То есть проблема в том, что была написана некорректная абстракция и залита в обход код овнера, но попрощались вы с чистым кодом? Оооооооок
Pip не встроен в Python, и никогда не был. Есть в стандартной библиотеке модуль ensurepip, который ставит pip из там же лежащего sdist, и всё. Причём даже этот модуль отсутствует, если Python ставить из Debian репозиториев. Насколько я понимаю, связано это с запретом на вендоризацию зависимостей в Debian пакетах, что и не позволяет sdist вложить вовнутрь Python пакета.
Ну, офицальная дока pip говорит так: "pip is already installed if you are using Python 2 >=2.7.9 or Python 3 >=3.4 downloaded from python.org", а вендоризация пакетов это вопрос уже другой и боле печальный.
Хотелось бы иметь удобный способ запустить тесты для всех зависимостей проекта.
На самом деле не хотелось бы. Потому что те же тесты в python в таком случае должны быть бережно покрыты всякими skipif, что бы покрывать одновременно и опциональные зависимости, и не падать, если их нет. А еще откровенно непонятно, что делать если тесты в пакете просто плохо написаны.
Что касается других языков, мне нравится, как работа с зависимостями реализована в Go
Да, там все сделано было предельно классно. Версионирование по коммитам, вложенный вендроинг и так далее. Классная работа с зависимостями :)
В Go сразу есть все необходимое, чтобы работать с зависимостями. В Python нужно все доустановить снаружи, причем еще нужно понять, что именно. Чаще всего достаточно pip, но сейчас появляются другие варианты.
Но ведь встроенный pip модуль в python установки появился еще до выхода go с вендорингом, разве нет?
Как минимум, когда ты хочешь обновить зависимости, то все зависимости просто обновлять страшно, потому что не факт, что даже если прошли тесты, всё будет работать. Например, часто такая ситуация возникает с Celery, потому что полностью протестировать Celery в тестах просто не получается. Можно что-то замокать, что-то упростить, но то, что воркеры запускаются, проверить не получается.
А тут проблема с python или в сложности тестирования условной очереди задач? По идее, данная ситуация вообще не зависит от языка.
И, тем не менее, в Poetry много странного, много привычных фич не поддерживается.
Например, не поддержится отключение проверки ssl сертификата :( Которое благодаря некоторым пакетам (привет, requests !) довольно необходимо.
А так самый печальный вывод из всей статьи — пора валить с pipenv, очень жаль, мне он нравился.
Если это к тому, что вот разработчиком быть просто, а сталеваров это прям круто и прям в разы сложнее, то это тоже довольно смешно.
У сталеваров тоже есть опытные мастера, а есть всякое пьянчуги, которые сидят на заводе и ничего им нормальные мастера стараются не доверять делать в одиночку.
К сожалению, нет. Просто в монолите вы можете нарушать контракт более вольготно за счет того, что его легко менять, но соблюдение четких контрактов там работает исключительно на ревью кода.
Стоит так же учесть, что в монолите серьезной проблемой является удерживание архитектурных границ и нерешаемой проблемой скалирование части функционала монолита.
Сфера услуг не может быть прибыльнее производства в нормальном мире
Почему? Это довольно нелогичное утверждение, учитывая, что в случае, если услугу предоставляет ПО, то она скалируется на достаточно большое количество людей, куда больше, чем может покрыть производство.
Интеллект, необходимый для кодирования CRUD в любом веб-фреймворке, — заметно ниже среднего.
Очень смешно.
Я не говорю, разумеется, о настоящих разработчиках, которые рассчитывают траектории движения ракеты в NASA, или пишут программное обеспечение для аппаратов стимуляции сердечного ритма.
Очень смешно x2.
Вы понимаете, что написание трактории движения ракеты и реализация тонны бизнес-логики это задачи вполне сравнимой сложности (а в зависимости от количества бизнес-логики, ракета еще и проигрывать начинает). Особенно учитывая, что формулы для описания траектории обычно разрабатывает пачка ученых, а не лично сам разработчик.
openapi-codegen работает значительно лучше, по крайне мере для python и typescript. Он поддерживает не все фишки, к сожалению, но клиенты работают довольно неплохо.
Я, например, менюшку просто не вижу, она у меня не отрисовывается :(
Не выкидывайте. Но суть в том, что расшифровки докладов и текстовые трансляции — это штуки, которые в большей мере служат для рекламы этой конференции и делаются в рамках рекламной компании… Не будет хабра — они появятся на других крупных площадках, тот же medium или reddit.
И в рамках тезиса "Хабр — это довольно доверенный источник информации," использовать их в качестве примера классный технических статей мне кажется неправильным.
Звучит как "Борцы за права афроамериканцев, как правило, афроамериканцы". Удивительная тенденция, но люди чаще выступают против проблемы, когда столкнулись с ней.
Особенно забавным мне кажется, как легко слить карму в комментариях и как тяжело в них же ее заработать.
PS. На момент комента у меня было -5, если что :)
Скорее пилить с нуля на Odoo, но без модулей sale, mrp и так далее, из-за того, что бизнес-процессы заказчиков сильно отличались от бизнес-процессов заложенных в эти модули и где-то на середине разработки они начали только мешать внезапным поведением, которые приходилось костылить.
Эм… простите, а вы на каком хабре сидите? Мне кажется, соотношение классная детальная техническая статья/обычный пост, как на медиуме уже давно не в пользу этого утверждения. А если еще выкинуть расшифровки докладов, то станет очень печально.
Бегите, глупцы.
А так каждая подписка жрет коннект к postgres, а они там не очень дешевые, разве нет?
У нас такое было с Odoo. В итоге после того, как смотришь назад, приходит понимание, что лучше было с самого начала пилить с нуля :)
То есть проблема в том, что была написана некорректная абстракция и залита в обход код овнера, но попрощались вы с чистым кодом? Оооооооок
Ну, офицальная дока pip говорит так: "pip is already installed if you are using Python 2 >=2.7.9 or Python 3 >=3.4 downloaded from python.org", а вендоризация пакетов это вопрос уже другой и боле печальный.
На самом деле не хотелось бы. Потому что те же тесты в python в таком случае должны быть бережно покрыты всякими skipif, что бы покрывать одновременно и опциональные зависимости, и не падать, если их нет. А еще откровенно непонятно, что делать если тесты в пакете просто плохо написаны.
Да, там все сделано было предельно классно. Версионирование по коммитам, вложенный вендроинг и так далее. Классная работа с зависимостями :)
Но ведь встроенный pip модуль в python установки появился еще до выхода go с вендорингом, разве нет?
А тут проблема с python или в сложности тестирования условной очереди задач? По идее, данная ситуация вообще не зависит от языка.
Например, не поддержится отключение проверки ssl сертификата :( Которое благодаря некоторым пакетам (привет, requests !) довольно необходимо.
А так самый печальный вывод из всей статьи — пора валить с pipenv, очень жаль, мне он нравился.
Достаточно же просто не использовать в коде async, если функция чисто расчетная… разве нет?
Асинхронные операции, которые нужны для оптимизации IOWait плохо работают там, когда нет никакого IOWait. Срыв покровов века!
Если это к тому, что вот разработчиком быть просто, а сталеваров это прям круто и прям в разы сложнее, то это тоже довольно смешно.
У сталеваров тоже есть опытные мастера, а есть всякое пьянчуги, которые сидят на заводе и ничего им нормальные мастера стараются не доверять делать в одиночку.
К сожалению, нет. Просто в монолите вы можете нарушать контракт более вольготно за счет того, что его легко менять, но соблюдение четких контрактов там работает исключительно на ревью кода.
Стоит так же учесть, что в монолите серьезной проблемой является удерживание архитектурных границ и нерешаемой проблемой скалирование части функционала монолита.
Попробуйте недельку питататся стальными балками и на них ездить. Проблема та же. Или вон на угле.
Почему? Это довольно нелогичное утверждение, учитывая, что в случае, если услугу предоставляет ПО, то она скалируется на достаточно большое количество людей, куда больше, чем может покрыть производство.
Очень смешно.
Очень смешно x2.
Вы понимаете, что написание трактории движения ракеты и реализация тонны бизнес-логики это задачи вполне сравнимой сложности (а в зависимости от количества бизнес-логики, ракета еще и проигрывать начинает). Особенно учитывая, что формулы для описания траектории обычно разрабатывает пачка ученых, а не лично сам разработчик.
Стоило чего? Разработки? Ну, python это open source, так что чуваку, который законтрибутил ок, наверное. А какие минусы?
Аналогичное же раньше делалось через bool переменную, так что какая разница?
Это стандартизация такая. В CPython методах такое было, а в обычном python нет. Вот исправили.
Да, потому что в примере на js 100% нужно читать доку, попробуй угадать, что нужно передать :)