Спасибо за обратную связь, вот что бывает когда мысли генерируются быстрее чем печатаешь текст :) Под нюансами подразумеваю на что нужно обращать внимание, чтобы не допустить тех ошибок, с которыми столкнулся на собственном опыте.
Потоки/процессы появились в Python за долго до asyncio. Я согласен, что переключением между потоками Python делает не оптимально, разработчик лучше понимает, где нужно переключиться на другую задачу и это можно реализовать с помощью asyncio. Но как вы правильно заметили, есть множество проектов написанных на синхронном Python, и не всегда удаётся переехать на асинхронную версию движка, поэтому про потоки в Python тоже не стоит забывать.
Возможно в каком-то будущем мы избавимся от них полностью, но не сейчас.
A: No. Although Curio provides a significant amount of overlapping functionality, the API is different. Compatibility with other libaries is not a goal. (Совместимость с другими библиотеками не является целью.)
Как он себя покажет если мы начнём строить большую систему, где за основу возьмём curio? Придётся ли нам переизобретать велосипеды из-за того что curio не поддерживает интеграцию с текущими библиотеками?
P.S. в статье и правда есть, лишнее, что-то незначительное убрал, но в целом это перевод другой статьи, если совсем причёсывать, то это будет не перевод, а пересказ:)
Да, всё зависит "от..", если вопрос касается фронт части, то тут мы можем сделать его максимально гибким и определять его структуру в бекенде. Подобное решение используется при разработке мобильных приложений, когда пользователь нечасто обновляет приложение на телефоне, но при этом структура приложения, например, меню/новые виджеты внутри нужно изменить.
Я рассматриваю семантическое версионнирование как часть составного решения, которое помогает определить, насколько сильно изменилась программа в новом релизе. В целом на проблему нужно смотреть комплексно и "проставление чисел" тому или иному релизу - это часть необходимого минимума при создании ПО/API
Да, тут глобально три разных направления, связанные с версионированием и совместимостью в приложениях, API и изменениях структуры БД. Цель была показать необходимость в поддержке прямой и обратной совместимости при изменениях и не важно где они происходят: в приложении, структуре БД или API.
Рассматривали, gRPC не защищает нас полностью, мы можем расширять модель, но только необязательными полями. А так тут те же проблемы в проектирование, что и у REST, если мы захотим изменить модель без обратной совместимости, например, добавить обязательное поле, то нам нужно обновить модели и у всех клиентов, то есть переработать множество интеграций с нашим сервисом
Упростил и разбавил своим личным опытом, теперь должно читаться легче или нет?
Согласен, но не все готовы выходить на рынок для очередного повышения, а расти хочется чаще чем раз в несколько лет.
Спасибо, за обратную связь
Добавил в статью кейс из личного опыта. Работа над open source это хорошая инвестиция, помимо того что это просто приятно делать, что-то полезное
Жена лучше любой gpt?
Добавил в статью кейс из личного опыта
У нас направлениями называют «Гильдии» — не формальное внутреннее(может быть внешнее) сообщество в компании
Спасибо, поправил
Спасибо за обратную связь, вот что бывает когда мысли генерируются быстрее чем печатаешь текст :) Под нюансами подразумеваю на что нужно обращать внимание, чтобы не допустить тех ошибок, с которыми столкнулся на собственном опыте.
*Поправил в статье этот момент?
С 3 месяцами мы слишком растянули. Если за это засесть плотно, то можно справиться с задачей за неделю.
Как показала практика, если забить и просто идти что-то разрабатывать, то пройдёт год и ничего толком не будет готово.
Потоки/процессы появились в Python за долго до asyncio. Я согласен, что переключением между потоками Python делает не оптимально, разработчик лучше понимает, где нужно переключиться на другую задачу и это можно реализовать с помощью asyncio. Но как вы правильно заметили, есть множество проектов написанных на синхронном Python, и не всегда удаётся переехать на асинхронную версию движка, поэтому про потоки в Python тоже не стоит забывать.
Возможно в каком-то будущем мы избавимся от них полностью, но не сейчас.
Спасибо, поправил
Интересный инструмент, почитал.
Единственное, что смущает:
Q: Is Curio meant to be a clone of asyncio?
A: No. Although Curio provides a significant amount of overlapping functionality, the API is different. Compatibility with other libaries is not a goal. (Совместимость с другими библиотеками не является целью.)
Как он себя покажет если мы начнём строить большую систему, где за основу возьмём curio? Придётся ли нам переизобретать велосипеды из-за того что curio не поддерживает интеграцию с текущими библиотеками?
P.S. в статье и правда есть, лишнее, что-то незначительное убрал, но в целом это перевод другой статьи, если совсем причёсывать, то это будет не перевод, а пересказ:)
Сколько боли в одном комментари?
Читая ваш комментарий, вспомнил про интересную статью на хабре: Темные века разработки программного обеспечения
Хорошая страшилка для новых разработчиков:)
Мешанина из кода это совсем плохо, тут либо неумение использовать версионирование, либо что-то не так с архитектурой.
Я говорил про канареечный деплой с разными версиями приложения, ассоциируемых с разными версиями исходного кода. Возможно, вы меня неправильно поняли.
Да, всё зависит "от..", если вопрос касается фронт части, то тут мы можем сделать его максимально гибким и определять его структуру в бекенде. Подобное решение используется при разработке мобильных приложений, когда пользователь нечасто обновляет приложение на телефоне, но при этом структура приложения, например, меню/новые виджеты внутри нужно изменить.
Я рассматриваю семантическое версионнирование как часть составного решения, которое помогает определить, насколько сильно изменилась программа в новом релизе. В целом на проблему нужно смотреть комплексно и "проставление чисел" тому или иному релизу - это часть необходимого минимума при создании ПО/API
А как же проводить канареечный деплой, если мы не можем развернуть одновременно несколько версий?
Да, тут глобально три разных направления, связанные с версионированием и совместимостью в приложениях, API и изменениях структуры БД. Цель была показать необходимость в поддержке прямой и обратной совместимости при изменениях и не важно где они происходят: в приложении, структуре БД или API.
Рассматривали, gRPC не защищает нас полностью, мы можем расширять модель, но только необязательными полями. А так тут те же проблемы в проектирование, что и у REST, если мы захотим изменить модель без обратной совместимости, например, добавить обязательное поле, то нам нужно обновить модели и у всех клиентов, то есть переработать множество интеграций с нашим сервисом