Честно говоря, вы похоже не участвовали в реальной разработке в реальных компаниях )) Сразу прошу у вас прощения, за такой переход на личности.
То что работает в мире "идеальных сферических сотрудников в вакууме" разбивается о скалы реальности.
Чрезвычайно сложно действовать в раздробленном мире, где ТЗ меняется на ходу, и никто ничего не может спланировать наперёд.
за такие слова в современно agile мире выгоняют с собеседований. Хотя это и правда так. Но так уж устроен мир разработки, такие тенденции сейчас на хайпе. И да, вы правы, это сложно, быть разработчиком. Ну так за решение сложностей компания и платит.
Ведь, тикет явно указывает, что нужно сделать, что и в какую сторону изменить. Разве не так?
Идеальный тикет именно такой. Жаль их не существует. Ибо проработка тикета до списка однозначных действий - и есть больше половины реализации. Об этом кстати сказано в обсуждаемой статье.
Разве процесс проектирования не заключается в том, чтобы сделать все задачи явными?
проектирование проводится на нескольких уровнях. И детальное проектирование на нижних уровнях часто входит в тикет, или само по себе является отдельным тикетом.
Неужели задача, связанная с обрабатываемым тикетом, столь велика, что допускает множество решений?
Да, а что вас удивляет? иначе программисты были бы не нужны, весь код бы генерировался из шаблонов. Вы не поверите, но когда я пишу письмо кому-нибудь, и мне нужно написать всего одну первую строчку приветствия (строго описанный тикет, не так ли?) у меня и то будет с лету 5-10 вариантов. А если хорошо подумать, то и гораздо больше.
если Вася и Петя пойдут разными путями, то они получат и разные результаты.
результат заказывает бизнес. И он часто оочень примерно знает какой ему нужен результат. Допустим бизнес хочет а-а-а-а-автомобиль. И даже четко описывает требования - 4 колеса, 4 двери, двигатель, коробка передач, руль, сиденья, фары и т.д. и т.п. Угадайте сколько возможных вариаций автомобилей можно ззапроектировать/произвести? Бесконечное количество. И кстати - они ВСЕ будут формально соответствовать исходным требованиям. А время на реализацию проекта будет разным. Т.е. разный результат - это нормально, пока он решает задачи бизнеса.
Как можно пытаться кодировать то, что может быть забраковано? Пускать в реализацию, кажется, можно только то, что принято и утверждено.
Манифест agile с вами несогласен) Любой код, любые принятые и утвержденные требования в будущем могут измениться и быть "забракованы". Сегодня вы пилите утвержденную фичу, а завтра изменилась ситуация на рынке, и фича стала не актуальна, или должна быть видоизменена.
Страшное дело! А зачем Петя пилил? Система прошла рефаторинг? Отменить все старые тикеты!
с какой стати-то отменить? т.е. после каждой выполненной задачи сразу стирать весь бэклог? на которые с вашим подходом убиты тысячи часов, чтобы декомпозировать и расписать и оценить всё до мелочей?
Простите, а почему у Вас один и тот же стенд для старой и для новой системы?
Простите, но мир так устроен. Есть компании, где всё идеально, и под каждую таску автоматически разворачивается отдельный тестовый стенд, со всеми сотнями сервисов, инфраструктурой, петабайтами обезличенных production-like данных... И есть реально существующие компании где часто нет тестеров, нет стендов, есть фиксированное количество стендов, стенды отличаются от прода, каждый стенд уникален как снежинка, развернуть и настроить стенд занимает от недели до месяца... Есть ли у компании ресурсы (а это может быть очень дорого) или есть ли руководства понимание/желание сделать хорошо - зависит не от разрабов и не от тимлидов, и даже не от ПО и ПМ-ов.
Да никак не решают. Вы же слышали про долгострои и переносы сроков в куче других областей. И в самолетостроении, машиностроении, и гражданском строительстве, и в "законотворчестве", искусстве. С ростом сложности, все больше неопределенности. Чем дольше срок, тем больше погрешность. Чем больше творческого и умственного труда, тем больше неопределенности. Зачастую менеджмент, просто не видит разницы между программированием и простым механическим, физическим трудом. "Законы Мёрфи", наверное, тоже все читали.
Потому что это невозможно. Реальный проект - это десятки тысяч тикетов, каждый из которых может содержать скрытые подзадачи. Почти не бывает идеально описанных тикетов, всегда есть подразумевающийся контекст, допущения, упрощения, просто ошибки, и "устные договоренности", возникшие во время разработки, и нигде не зафиксированные.
Берете два с виду одинаковых тикета. Но один делал Вася, а другой - Петя. У них разный опыт. И они выбрали разные пути решения. И Вася был после кранча/болезни, а Петя после отпуска. И кто-то внешний, менеджер на приемке, тестировщик на тесте, лид/коллега на ревью указал им на разные недостатки. И Вася пилил фичу до рефакторинга всей подсистемы, а Петя - после. А ешё за это время поменялся контракт взаимодействия с внешним сервисом. И оказалось что когда Петя закончит фичу - девопсы сломали тестовый стенд, и Петя потратит лишние пару часов на поиск причины.
Всё это и многое другое не будет учтено при оценке (и в гипотетической общей табличке оценок)
Их (массивы) точно лучше передавать по ссылке, как PHP передаёт объекты
Точно лучше? Вообще, явно передавать что-то по ссылке надо, только если вам это действительно нужно. Например, если вам надо изменять в вызываемом методе/функции содержимое огромного массива, так чтобы это изменение сохранилось в вызывающем контексте. Но это весьма частный кейс, и возможно вы что-то делаете не так.
Используйте for
Вот так, без каких либо условий, всегда? Так себе совет. Используйте for в тех случаях, когда вы знаете для какой конкретно цели он вам нужен. Например, если вам надо итерируясь по огромному массиву менять его содержимое, так чтобы они сохранилось по завершению цикла... Что также достаточно редкий кейс.
Это кто-то читал? Тем кто еще не читал, советую и не читать.
То ли кривой перевод, то ли сразу ChatGpt. Если все-таки перевод, то поделитесь ссылкой на оригинал, может там будет понятнее.
Мы поможем вам определить, как мы разделяем и распределяем нагрузку между различными типами работников в центре обработки данных
Каких работниках? зачем нам определять как вы разделяете?
Каждый раз, когда мы разрабатываем новое ИТ-решение, нам необходимо учитывать и учитывать определенные архитектурные аспекты, которые являются неотъемлемой частью любого чертежа систем
Учитывать и учитывать и учитывать? А что за чертежи?
архитектура доступна для наблюдения, если она предоставляет подсказки и подсказки о своих внутренних условиях
Нужно больше подсказок. Особенно об условиях.
Код базируется на контролируемых версиях системы контроля версий
we need to go deeper...
Состояние должно быть бесхранилищным
Бесхранилищный... это шедевр
Сервисы должны быть легковесными и обработчиками.
На улице шли двое - дождь и я.
Приложение должно быть развернуто на нескольких экземплярах.
На нескольких экземплярах чего?
Административные задачи должны выполняться через один-time-процессы
один-time-процессы - интересный термин. В копилку к "бесхранилищный".
Как SRE, наша первая задача дня — обеспечить разделение и балансировку рабочей нагрузки между общими ресурсами и вспомогательными службами.
Первая задача дня - это вместо дейлика, каждое утро?
Germany's Blue Card Долгосрочная виза для высококвалифицированных работников, право на получение определяется по системе баллов. Получатель: работник Диплом: да Семья: да Продолжительность: 4 года Возобновляемый: да Стоимость: не указана Требования: высокий уровень владения немецким языком и ваша работа должна позволять вам зарабатывать не менее 50 800 € в год Время рассмотрения: не указано
Вы многое путаете. Бальной системы для BlueCard нет. Это для нового третьего способа "Chancenkarte" который только обсуждают и еще не приняли.
Диплом был обязателен не на 100%, раньше можно было показать опыт работы около 3х лет на должности, которая требует сопоставимого уровня знаний. Но сейчас это не работает для граждан РФ.
Продолжительность 4 года - это максимум на который дают блюкард, но бывает и меньше. Потом можно продлевать. Некоторые после 4-5 лет так и остаются на блюкард, и не получают ПМЖ по собственному желанию. Первые 2 года вид на жительство (по блюкард, не ПМЖ) привязан к работодателю, и поменять работу можно только согласовав новый контракт в администрации по делам иностранцев.
Высокий уровень владения немецким языком - нет такого требования на получения визы и временного вида на жительство по блю кард. Показать знание языка потребуется потом, когда будете подаваться на ПМЖ и гражданство. От уровня зависит то, как рано сможете подать документы. Сейчас в процессе рассмотрения закон о новых сроках, типа паспорт за три года, если сдадите немецкий на C2. Закон пока не принят.
сколько времени надо провести в стране до получения ПМЖ (если это в принципе возможно) + условия сохранения ПМЖ (в некоторых странах достаточно выехать на полгода, чтобы потерять постоянный вид на жительство)
сколько времени до паспорта (если это в принципе возможно, некоторые страны не дают паспорт, кроме как по браку с гражданином(гражданкой))
есть ли разрешение на работу у супругов приехавших по воссоединению семьи
требования по знанию языков (далеко не в каждой стране будет комфортно только с английским, не все готовы учить язык на котором говорит меньше 1 млн человек в мире)
Про совместимость API: > Из возможностей, доступных в первом выпуске DragonFly отмечается поддержка протокола RESP2 и 130 команд Redis, что примерно соответствует функциональности выпуска Redis 2.8 Это было полгода назад. Разработчики постепенно добавляют поддержку команд из более новых версий Redis, но о полной совместимости говорить рано.
Про быстродействие: По бенчмаркам команды Redis (ниже приводил ссылку на офсайт), они быстрее чем DragonFly. При этом они конечно запускали не один инстанс Redis на многопоточном процессоре, а несколько.
можно, более того, именно это и советуют на официальном сайте Redis, в ответ на критику со стороны разработчиков многопоточных форков. И в ответ приводят бенчмарки, в которых видно что правильно приготовленный Redis даже быстрее конкурентов См. тут https://redis.com/blog/redis-architecture-13-years-later/
Это не мой пример, это ваш (и не только) пример. Он хорошо показывает "как работают генераторы" и плохо показывает "как получить пользу от применения генераторов". Я всего лишь спросил, надеясь на ваш богатый опыт, нет ли другого примера, где использование генератора приводит к реальной экономии ресурсов, которой не достичь без оного. Ну нет, так нет.
Попробую ответить самому себе, какое у меня к данному моменту сложилось впечатление (но может, у кого-то еще найдется пример): - Чтобы реализовать аналогичный функционал без генератора, вам придется или использовать свой объект с состоянием, или вынести весь код в тело цикла, где и будет состояние выполнения тех или иных операций. В первом случае все довольно просто, но дополнительная писанина и размножение сущностей. Во втором случае - может получиться сложночитаемая каша. Таким образом главная выгода от генераторов - сокращение и упрощение кода, но вовсе не экономия ресурсов. И выгода тем больше, чем больше этаких "задач с состоянием" мы пытаемся выполнить за такт цикла, и чем больше кода в каждой "задаче".
но зачем загружать файл в память целиком? Если вы его можете обрабатывать построчно с генератором, читайте так же построчно без генератора. обработали строку, выдали результат - взяли следующую.
И если вам для работы с файлом, по условию задачи, необходимо считать его весь в память (ну мало ли, что там за формат внутри) , то генератор вам уже не поможет, все равно придется считать.
Спасибо за статью, интересно. Но всё же, как надоел это пример про генераторы и корутины с чтением файла по строкам! "Конечно, нужно отметить, что мы получаем возможность работы с потенциально бесконечными задачами, что без генераторов невозможно."
Но почему-то всегда приводится этот пример, который элементарно переписывается без всяких генераторов. При этом, также останется чтение по строкам, без считывания всего файла в память. И в обычной работе, в коде вроде порой хочется ввернуть генератор. Даже напишешь, а потом понимаешь что можно проще и понятнее без него.
Может есть какой-то пример, где действительно без них никак, и есть настоящая польза?
В данном случае это вовсе не попытка придумать новый подход к разработке сайтов. Технически, подходы те же что и раньше, может чуть в другой обертке для отвода глаз. Так что же это за волна статей про всякий «no code»?
Я думаю это банальная попытка заработать. Кому-то будет очень выгодно, если все избавятся от своих программистов и начнут пользоваться для любых целей API, которые поставляются сначала условно бесплатно, а при каких-то объемах — за вполне серьезные деньги.
Сначала — откажитесь от своих почтовых серверов, пользуйтесь Гугл, майлру и т.д. и т.п.
потом — откажитесь от своих веб серверов, пользуйтесь хостингом, потом пользуйтесь облаками. Откажитесь от своих файловых хранилищ и БД — пользуйтесь облаками. Теперь — откажитесь от своего кода.
Итог — вырастили монстров вроде гугла, амазона и т.д., которые полностью контролируют всех вокруг. Они могут «забанить» пользователя за не соответствующее текущему хайпу мнение — и разорять целые компании без тени сожаления. Гигантские бездушные бюрократические машины.
Всё это распрекрасно API и сторонние сервисы — без них уже никуда.
Сторонний сервис может:
— не отвечать
— потерять (удалить) ваши данные
— поменять API сломав обратную совместимость
— внезапно прекратить существование. Не дав выкачать «все что нажито»
— допустить утечку данных ваших клиентов
— сбоить так что ваши клиенты потеряют деньги — не те покупки, не туда доставки и т.д.
Но вот у них происходит сбой — и ваш бизнес встал. И от вас ничего не зависит. И убытки вам никто не компенсирует, разве что часть месячной подписки. А еще за утечку «у них» государство (ну или ваши клиенты через суд) может наказать вас.
А мне наоборот, бегать — скучно. Все эти школьно-институтские кроссы, и километры на время. Вот если бегать со смыслом, например играя в футбол — вот это удовольсте от физкультуры.
А вот фехтованием (шпага) занимался с удовольствием. Тут тебе и азарт и игра к «кошки-мышки» с соперником и физ-нагрузки в одном флаконе. Жаль секцию прикрыли. До сих пор дома лежат запчасти для сборки нового клинка.
Примерно на том же уровне что и фехтование, мне нравится настольный теннис — там тоже надо быть быстрым, ловким и хитрым.
От таких физических нагрузок и получаешь удовольствие, а не от бесконечных монотонных повторений упражнений.
Честно говоря, вы похоже не участвовали в реальной разработке в реальных компаниях )) Сразу прошу у вас прощения, за такой переход на личности.
То что работает в мире "идеальных сферических сотрудников в вакууме" разбивается о скалы реальности.
за такие слова в современно agile мире выгоняют с собеседований. Хотя это и правда так. Но так уж устроен мир разработки, такие тенденции сейчас на хайпе. И да, вы правы, это сложно, быть разработчиком. Ну так за решение сложностей компания и платит.
Идеальный тикет именно такой. Жаль их не существует. Ибо проработка тикета до списка однозначных действий - и есть больше половины реализации. Об этом кстати сказано в обсуждаемой статье.
проектирование проводится на нескольких уровнях. И детальное проектирование на нижних уровнях часто входит в тикет, или само по себе является отдельным тикетом.
Да, а что вас удивляет? иначе программисты были бы не нужны, весь код бы генерировался из шаблонов. Вы не поверите, но когда я пишу письмо кому-нибудь, и мне нужно написать всего одну первую строчку приветствия (строго описанный тикет, не так ли?) у меня и то будет с лету 5-10 вариантов. А если хорошо подумать, то и гораздо больше.
результат заказывает бизнес. И он часто оочень примерно знает какой ему нужен результат. Допустим бизнес хочет а-а-а-а-автомобиль. И даже четко описывает требования - 4 колеса, 4 двери, двигатель, коробка передач, руль, сиденья, фары и т.д. и т.п. Угадайте сколько возможных вариаций автомобилей можно ззапроектировать/произвести? Бесконечное количество. И кстати - они ВСЕ будут формально соответствовать исходным требованиям. А время на реализацию проекта будет разным. Т.е. разный результат - это нормально, пока он решает задачи бизнеса.
Манифест agile с вами несогласен) Любой код, любые принятые и утвержденные требования в будущем могут измениться и быть "забракованы". Сегодня вы пилите утвержденную фичу, а завтра изменилась ситуация на рынке, и фича стала не актуальна, или должна быть видоизменена.
с какой стати-то отменить? т.е. после каждой выполненной задачи сразу стирать весь бэклог? на которые с вашим подходом убиты тысячи часов, чтобы декомпозировать и расписать и оценить всё до мелочей?
Простите, но мир так устроен. Есть компании, где всё идеально, и под каждую таску автоматически разворачивается отдельный тестовый стенд, со всеми сотнями сервисов, инфраструктурой, петабайтами обезличенных production-like данных... И есть реально существующие компании где часто нет тестеров, нет стендов, есть фиксированное количество стендов, стенды отличаются от прода, каждый стенд уникален как снежинка, развернуть и настроить стенд занимает от недели до месяца... Есть ли у компании ресурсы (а это может быть очень дорого) или есть ли руководства понимание/желание сделать хорошо - зависит не от разрабов и не от тимлидов, и даже не от ПО и ПМ-ов.
Да никак не решают. Вы же слышали про долгострои и переносы сроков в куче других областей. И в самолетостроении, машиностроении, и гражданском строительстве, и в "законотворчестве", искусстве. С ростом сложности, все больше неопределенности. Чем дольше срок, тем больше погрешность. Чем больше творческого и умственного труда, тем больше неопределенности. Зачастую менеджмент, просто не видит разницы между программированием и простым механическим, физическим трудом.
"Законы Мёрфи", наверное, тоже все читали.
Потому что это невозможно. Реальный проект - это десятки тысяч тикетов, каждый из которых может содержать скрытые подзадачи. Почти не бывает идеально описанных тикетов, всегда есть подразумевающийся контекст, допущения, упрощения, просто ошибки, и "устные договоренности", возникшие во время разработки, и нигде не зафиксированные.
Берете два с виду одинаковых тикета. Но один делал Вася, а другой - Петя. У них разный опыт. И они выбрали разные пути решения. И Вася был после кранча/болезни, а Петя после отпуска. И кто-то внешний, менеджер на приемке, тестировщик на тесте, лид/коллега на ревью указал им на разные недостатки. И Вася пилил фичу до рефакторинга всей подсистемы, а Петя - после. А ешё за это время поменялся контракт взаимодействия с внешним сервисом. И оказалось что когда Петя закончит фичу - девопсы сломали тестовый стенд, и Петя потратит лишние пару часов на поиск причины.
Всё это и многое другое не будет учтено при оценке (и в гипотетической общей табличке оценок)
Точно лучше? Вообще, явно передавать что-то по ссылке надо, только если вам это действительно нужно. Например, если вам надо изменять в вызываемом методе/функции содержимое огромного массива, так чтобы это изменение сохранилось в вызывающем контексте. Но это весьма частный кейс, и возможно вы что-то делаете не так.
Вот так, без каких либо условий, всегда? Так себе совет. Используйте for в тех случаях, когда вы знаете для какой конкретно цели он вам нужен. Например, если вам надо итерируясь по огромному массиву менять его содержимое, так чтобы они сохранилось по завершению цикла... Что также достаточно редкий кейс.
Я то думал, что основной минус Тайваня - возможность военного конфликта с Китаем и вмешательством третьих сил.
А оказывается - существование налогов и омс... не уверен что многие захотят жить в тех странах, где сейчас нет таких "основных недостатков".
Это кто-то читал? Тем кто еще не читал, советую и не читать.
То ли кривой перевод, то ли сразу ChatGpt.
Если все-таки перевод, то поделитесь ссылкой на оригинал, может там будет понятнее.
Каких работниках? зачем нам определять как вы разделяете?
Учитывать и учитывать и учитывать? А что за чертежи?
Нужно больше подсказок. Особенно об условиях.
we need to go deeper...
Бесхранилищный... это шедевр
На улице шли двое - дождь и я.
На нескольких экземплярах чего?
один-time-процессы - интересный термин. В копилку к "бесхранилищный".
Первая задача дня - это вместо дейлика, каждое утро?
даже боюсь читать дальше...
Вы многое путаете. Бальной системы для BlueCard нет. Это для нового третьего способа "Chancenkarte" который только обсуждают и еще не приняли.
Диплом был обязателен не на 100%, раньше можно было показать опыт работы около 3х лет на должности, которая требует сопоставимого уровня знаний. Но сейчас это не работает для граждан РФ.
Продолжительность 4 года - это максимум на который дают блюкард, но бывает и меньше. Потом можно продлевать. Некоторые после 4-5 лет так и остаются на блюкард, и не получают ПМЖ по собственному желанию. Первые 2 года вид на жительство (по блюкард, не ПМЖ) привязан к работодателю, и поменять работу можно только согласовав новый контракт в администрации по делам иностранцев.
Высокий уровень владения немецким языком - нет такого требования на получения визы и временного вида на жительство по блю кард. Показать знание языка потребуется потом, когда будете подаваться на ПМЖ и гражданство. От уровня зависит то, как рано сможете подать документы. Сейчас в процессе рассмотрения закон о новых сроках, типа паспорт за три года, если сдадите немецкий на C2. Закон пока не принят.
Виза это хорошо, но нужна еще информация:
сколько времени надо провести в стране до получения ПМЖ (если это в принципе возможно) + условия сохранения ПМЖ (в некоторых странах достаточно выехать на полгода, чтобы потерять постоянный вид на жительство)
сколько времени до паспорта (если это в принципе возможно, некоторые страны не дают паспорт, кроме как по браку с гражданином(гражданкой))
есть ли разрешение на работу у супругов приехавших по воссоединению семьи
требования по знанию языков (далеко не в каждой стране будет комфортно только с английским, не все готовы учить язык на котором говорит меньше 1 млн человек в мире)
в тексте договора медицинского страхования.
Про совместимость API:
> Из возможностей, доступных в первом выпуске DragonFly отмечается поддержка протокола RESP2 и 130 команд Redis, что примерно соответствует функциональности выпуска Redis 2.8
Это было полгода назад. Разработчики постепенно добавляют поддержку команд из более новых версий Redis, но о полной совместимости говорить рано.
Про быстродействие:
По бенчмаркам команды Redis (ниже приводил ссылку на офсайт), они быстрее чем DragonFly. При этом они конечно запускали не один инстанс Redis на многопоточном процессоре, а несколько.
А вот еще одно небольшое сравнение redis vs keyDB, и тут тоже не вышло превосходства keyDB в 5-25х маркетинговых раз.
можно, более того, именно это и советуют на официальном сайте Redis, в ответ на критику со стороны разработчиков многопоточных форков. И в ответ приводят бенчмарки, в которых видно что правильно приготовленный Redis даже быстрее конкурентов
См. тут https://redis.com/blog/redis-architecture-13-years-later/
Вроде уже было, комиксы про кубер:
https://www.cncf.io/phippy/phippy-goes-to-the-zoo-book/
Это не мой пример, это ваш (и не только) пример. Он хорошо показывает "как работают генераторы" и плохо показывает "как получить пользу от применения генераторов".
Я всего лишь спросил, надеясь на ваш богатый опыт, нет ли другого примера, где использование генератора приводит к реальной экономии ресурсов, которой не достичь без оного. Ну нет, так нет.
Попробую ответить самому себе, какое у меня к данному моменту сложилось впечатление (но может, у кого-то еще найдется пример):
- Чтобы реализовать аналогичный функционал без генератора, вам придется или использовать свой объект с состоянием, или вынести весь код в тело цикла, где и будет состояние выполнения тех или иных операций. В первом случае все довольно просто, но дополнительная писанина и размножение сущностей. Во втором случае - может получиться сложночитаемая каша. Таким образом главная выгода от генераторов - сокращение и упрощение кода, но вовсе не экономия ресурсов. И выгода тем больше, чем больше этаких "задач с состоянием" мы пытаемся выполнить за такт цикла, и чем больше кода в каждой "задаче".
но зачем загружать файл в память целиком? Если вы его можете обрабатывать построчно с генератором, читайте так же построчно без генератора. обработали строку, выдали результат - взяли следующую.
И если вам для работы с файлом, по условию задачи, необходимо считать его весь в память (ну мало ли, что там за формат внутри) , то генератор вам уже не поможет, все равно придется считать.
Спасибо за статью, интересно. Но всё же, как надоел это пример про генераторы и корутины с чтением файла по строкам!
"Конечно, нужно отметить, что мы получаем возможность работы с
потенциально бесконечными задачами, что без генераторов невозможно."
Но почему-то всегда приводится этот пример, который элементарно переписывается без всяких генераторов. При этом, также останется чтение по строкам, без считывания всего файла в память. И в обычной работе, в коде вроде порой хочется ввернуть генератор. Даже напишешь, а потом понимаешь что можно проще и понятнее без него.
Может есть какой-то пример, где действительно без них никак, и есть настоящая польза?
В IDE от JetBrains — например, PHPStorm
Я думаю это банальная попытка заработать. Кому-то будет очень выгодно, если все избавятся от своих программистов и начнут пользоваться для любых целей API, которые поставляются сначала условно бесплатно, а при каких-то объемах — за вполне серьезные деньги.
Сначала — откажитесь от своих почтовых серверов, пользуйтесь Гугл, майлру и т.д. и т.п.
потом — откажитесь от своих веб серверов, пользуйтесь хостингом, потом пользуйтесь облаками. Откажитесь от своих файловых хранилищ и БД — пользуйтесь облаками. Теперь — откажитесь от своего кода.
Итог — вырастили монстров вроде гугла, амазона и т.д., которые полностью контролируют всех вокруг. Они могут «забанить» пользователя за не соответствующее текущему хайпу мнение — и разорять целые компании без тени сожаления. Гигантские бездушные бюрократические машины.
Всё это распрекрасно API и сторонние сервисы — без них уже никуда.
Сторонний сервис может:
— не отвечать
— потерять (удалить) ваши данные
— поменять API сломав обратную совместимость
— внезапно прекратить существование. Не дав выкачать «все что нажито»
— допустить утечку данных ваших клиентов
— сбоить так что ваши клиенты потеряют деньги — не те покупки, не туда доставки и т.д.
Но вот у них происходит сбой — и ваш бизнес встал. И от вас ничего не зависит. И убытки вам никто не компенсирует, разве что часть месячной подписки. А еще за утечку «у них» государство (ну или ваши клиенты через суд) может наказать вас.
А вот фехтованием (шпага) занимался с удовольствием. Тут тебе и азарт и игра к «кошки-мышки» с соперником и физ-нагрузки в одном флаконе. Жаль секцию прикрыли. До сих пор дома лежат запчасти для сборки нового клинка.
Примерно на том же уровне что и фехтование, мне нравится настольный теннис — там тоже надо быть быстрым, ловким и хитрым.
От таких физических нагрузок и получаешь удовольствие, а не от бесконечных монотонных повторений упражнений.