В вашей картине мира все верно только для тех компаний, который готовы на обучение джунов. Это в основном крупный бизнес. И это в основном было до кризисных времен. Сейчас ситуация немного другая. Денег в стране стало сильно меньше, компаний - тоже (какие-то закрылись, какие-то ушли), а желающих войти в айти наоборот сильно выросло, потому что ситуация в целом по стране не сильно поменялась, да, у всех зарплаты обесценились, но у айтишников в среднем все равно больше. А компании сейчас сокращают штат даже из мидл+ спецов, просто потому, что содержать штат дорого, а прибыль стала меньше. В общем, если коротко - джуны из прошлой реальности сейчас нерентабельны от слова совсем, даже для крупных игроков рынка. Либо ищут на джунов условно свежих мидлов, требования к джунам сильно выросли. Это наша текущая реальность, увы.
Ох ребята, пробовал буквально вчера эту библиотеку. Подумал, что круто, синтаксис простой, как в Джанге, настройка вроде тоже. Но на первой же модели он мне сказал, что не может создать уникальный констрейн на текстовом поле. А у меня постгрес. WTF? Пошел в issues, вижу эту же проблему, кто-то завел уже, с января висит, и от мейнтейнеров ни решения, ни ответа. Посмотрел полный список issues, когда заведены некоторые, список pr, и понял, что у ребят, похоже, совсем нет времени на эти вещи. В общем, решил, что возьму я наверное старую-добрую алхимию.
Странная статья. Мне всегда казалось, что машину выбирают под задачи. Есть задачи, которые можно решить как на маке, так и на Линуксе, в целом одинаково комфортно, есть где одно удобнее другого, а есть, где одно подходит, а другое - нет, и тут уже "фи" не работает, потому что по-другому никак или очень неэффективно. А в статье описывается алюминий, ссд и ещё всякое, что очень косвенно влияет на решение рабочих задач. Холиварная статья на мой взгляд
Это в том случае, если начальство не умеет признавать свои ошибки. Но мы же все люди. Поэтому начальство начальству - рознь. Нормальный начальник как раз попытается разобраться в реальной проблеме. Потом исправить ситуацию всеми возможными способами, если это в его силах. А то, что вы описали - на мой взгляд ненормально. Потому что все мы люди, и все мы ошибаемся. И мудрый человек понимает это.
В целом конечно, в статье очень много утверждений, не подкрепленные каким-либо доказательством.
Идея проста и элегантна: код, который легко и удобно тестировать, — это хорошо спроектированный код.
Откуда это следует? Я вот совсем связи не прослеживаю. Код, который легко и удобно тестировать - легко и удобно тестируемый, но это не делает его автоматически хорошо спроектированным. Да, он может быть лучше спроектирован, чем код, который писался без оглядки на тесты, но до "хорошо" ему монет быть как до луны.
Представьте, что вы строите дом и в первую очередь думаете о том, как его будут проверять на прочность, безопасность и удобство. Логично, что такой дом получится качественным.
Так себе аналогия. В отличие от дома более-менее средний проект (если это не мвп или проект одной задачи) постоянно эволюционирует. И требования могут меняться, что может потребовать различных твистов, вплоть до переписывания большей части проекта. С домом такое редко бывает, разве что вы изначально не знаете, что вам нужно и дом постоянно перестраивается и стройка никогда не закончится.
Очень спорная статья. Я бы сказал, что хорошо спроектированным код - это код, который легко понимать и изменять под новые требования, само собой не ломая существующий функционал. А как этого достичь, это обширная тема, причем на только технического характера, но и организационная часть имеет тут немалое значение
Статья от фронтенд-разработчика. Там специфика такова, что в большинстве проектов большими объемами данных приходится оперировать очень редко. Отчасти из-за того, что хранить состояние на клиенте - моветон. Отчасти из-за того, что а этом просто нет необходимости, потому что можно получать данные частями и работать с такими банками вполне нормально без ограничения в функциональности для конечного пользователя. Поэтому и статья написана с таким учётом, хотя явно не указано. А стоило бы. Часть вещей фреймворко и языкозависимая.
У FastAPI есть какие-то серьезные отличия в процессе развертывания от других веб-проектов на Python, что для него требуется целый отдельной сервис? Инфраструктурные ж вещи вроде докера и кубера не делаются специально под конкретные библиотеки, поскольку очевидно, что это независимая часть. Или в этом сервисе чисто пару скриптов, да докер файл для сборки, все остальное к питону не имеет прямого отношения?
Ну вообще питон - язык общего назначения, а не только для обработки данных. Хоть он и не может похвастаться легковесностью для десктопа, но зато у него есть другое преимущество - скорость разработки и прототипирования сильно выше, чем у того же с++ за счёт более высокой абстракции кода и большой библиотеки (не только стандартной) для решения различных типовых задач. Популярность этого языка кстати не только в сфере обработки данных, его успешно применяют и для веб-разработки, и для машинного обучения.
Умеет ли пип правильно находить совместимые версии подзависимостей основных зависимостей? Когда я последний раз его использовал, он просто писал, что не может установить нужную версию, потому что конфликт версий. При этом поетри сам находил совместимую версию подзависимости, которая подходит для нескольких зависимостей одновременно.
Помилуйте , одним диктом все конфинурируется через dictConfig. Если хочется прям совсем просто, то basicConfig одной строчкой. Но если вам прям совсем лень даже доку прочитать на 15 минут, ну тогда наверное loguru для вас. До момента, когда понадобится понимать, как оно работает
Тестером качеств услуг хотите записаться?)
А подскажите пожалуйста, что можно почитать на эту тему, какие-то хорошие книги, курсы. Спасибо
В вашей картине мира все верно только для тех компаний, который готовы на обучение джунов. Это в основном крупный бизнес. И это в основном было до кризисных времен. Сейчас ситуация немного другая. Денег в стране стало сильно меньше, компаний - тоже (какие-то закрылись, какие-то ушли), а желающих войти в айти наоборот сильно выросло, потому что ситуация в целом по стране не сильно поменялась, да, у всех зарплаты обесценились, но у айтишников в среднем все равно больше. А компании сейчас сокращают штат даже из мидл+ спецов, просто потому, что содержать штат дорого, а прибыль стала меньше. В общем, если коротко - джуны из прошлой реальности сейчас нерентабельны от слова совсем, даже для крупных игроков рынка. Либо ищут на джунов условно свежих мидлов, требования к джунам сильно выросли. Это наша текущая реальность, увы.
Всегда хочется запилить что-то своё) И это интереснее, чем читать какие-то RFC)
А зачем смотрите тогда?)
Может это как раз в планах после получения инвестиций)
Для этого и нужны инвестиции. Чтобы все заработало.
Ох ребята, пробовал буквально вчера эту библиотеку. Подумал, что круто, синтаксис простой, как в Джанге, настройка вроде тоже. Но на первой же модели он мне сказал, что не может создать уникальный констрейн на текстовом поле. А у меня постгрес. WTF? Пошел в issues, вижу эту же проблему, кто-то завел уже, с января висит, и от мейнтейнеров ни решения, ни ответа. Посмотрел полный список issues, когда заведены некоторые, список pr, и понял, что у ребят, похоже, совсем нет времени на эти вещи. В общем, решил, что возьму я наверное старую-добрую алхимию.
Странная статья. Мне всегда казалось, что машину выбирают под задачи. Есть задачи, которые можно решить как на маке, так и на Линуксе, в целом одинаково комфортно, есть где одно удобнее другого, а есть, где одно подходит, а другое - нет, и тут уже "фи" не работает, потому что по-другому никак или очень неэффективно. А в статье описывается алюминий, ссд и ещё всякое, что очень косвенно влияет на решение рабочих задач. Холиварная статья на мой взгляд
У тс другие задачи, ему кроссплатформенная разработка не нужна. Была бы нужна, статьи бы не было)
И что же они умеют? Из заголовка ожидаешь какого-то сравнивая что-ли .
Это в том случае, если начальство не умеет признавать свои ошибки. Но мы же все люди. Поэтому начальство начальству - рознь. Нормальный начальник как раз попытается разобраться в реальной проблеме. Потом исправить ситуацию всеми возможными способами, если это в его силах. А то, что вы описали - на мой взгляд ненормально. Потому что все мы люди, и все мы ошибаемся. И мудрый человек понимает это.
В целом конечно, в статье очень много утверждений, не подкрепленные каким-либо доказательством.
Откуда это следует? Я вот совсем связи не прослеживаю. Код, который легко и удобно тестировать - легко и удобно тестируемый, но это не делает его автоматически хорошо спроектированным. Да, он может быть лучше спроектирован, чем код, который писался без оглядки на тесты, но до "хорошо" ему монет быть как до луны.
Так себе аналогия. В отличие от дома более-менее средний проект (если это не мвп или проект одной задачи) постоянно эволюционирует. И требования могут меняться, что может потребовать различных твистов, вплоть до переписывания большей части проекта. С домом такое редко бывает, разве что вы изначально не знаете, что вам нужно и дом постоянно перестраивается и стройка никогда не закончится.
Очень спорная статья. Я бы сказал, что хорошо спроектированным код - это код, который легко понимать и изменять под новые требования, само собой не ломая существующий функционал. А как этого достичь, это обширная тема, причем на только технического характера, но и организационная часть имеет тут немалое значение
Статья от фронтенд-разработчика. Там специфика такова, что в большинстве проектов большими объемами данных приходится оперировать очень редко. Отчасти из-за того, что хранить состояние на клиенте - моветон. Отчасти из-за того, что а этом просто нет необходимости, потому что можно получать данные частями и работать с такими банками вполне нормально без ограничения в функциональности для конечного пользователя. Поэтому и статья написана с таким учётом, хотя явно не указано. А стоило бы. Часть вещей фреймворко и языкозависимая.
У FastAPI есть какие-то серьезные отличия в процессе развертывания от других веб-проектов на Python, что для него требуется целый отдельной сервис? Инфраструктурные ж вещи вроде докера и кубера не делаются специально под конкретные библиотеки, поскольку очевидно, что это независимая часть. Или в этом сервисе чисто пару скриптов, да докер файл для сборки, все остальное к питону не имеет прямого отношения?
Ну вообще питон - язык общего назначения, а не только для обработки данных. Хоть он и не может похвастаться легковесностью для десктопа, но зато у него есть другое преимущество - скорость разработки и прототипирования сильно выше, чем у того же с++ за счёт более высокой абстракции кода и большой библиотеки (не только стандартной) для решения различных типовых задач. Популярность этого языка кстати не только в сфере обработки данных, его успешно применяют и для веб-разработки, и для машинного обучения.
Умеет ли пип правильно находить совместимые версии подзависимостей основных зависимостей? Когда я последний раз его использовал, он просто писал, что не может установить нужную версию, потому что конфликт версий. При этом поетри сам находил совместимую версию подзависимости, которая подходит для нескольких зависимостей одновременно.
Посмотрите в сторону uv, он позволяет несколько версий питона держать, разные виртуальные окружения на их основе.
Помилуйте , одним диктом все конфинурируется через dictConfig. Если хочется прям совсем просто, то basicConfig одной строчкой. Но если вам прям совсем лень даже доку прочитать на 15 минут, ну тогда наверное loguru для вас. До момента, когда понадобится понимать, как оно работает
В офф. документации есть пара способов) Не поленитесь зайти и почитать, если действительно интересно