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

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

в армии кстати тож есть признаки секты - там например для управления коллективом используется страх неназванного наказания "плохо жить тут будешь" и страх отрыва от коллектива "че не как все да" (плохо работает кстати вне коммунизма)

но вообще как по мне управляющие воздействия крайне тяжело ложатся на критическое восприятие адекватного человека - управляющий сразу выглядит театральным актером если на его пассажи задаться вопросом "а почему я обязан?"

бизнес готов платить за такой процесс, потому что таким образом программист отделяется от интеллектуальной собственности, невозможно предъявить права на то, что обслуживается 10 людьми с черными ящиками на каждом слое. если бы разработчики торговых алгоритмов знали насколько просто устроена платформа торговли, они бы все были ИП

в моей практике важнее обозначить критерии приемки задачи, чем цели и мотивации, если не сказать как будешь проверять, ничего и не будет сделано

грустный раян Гослинг.жпг

года в 4 человек тоже повторяет одно и то же слово пытаясь высказать мысль, тут главное читать его ответы детским голосом

если бы сим-карты были сделаны с поддержкой ООП, то нам бы пришлось переплавить всю луну на телефоны

когда в классе 1 экземпляр все хорошо если экземпляров программы не миллионы по всему миру, иначе в конечном итоге за читабельность кода заплатит экология)

под динамический я имею ввиду создаваемые на время экземпляры с полиморфными методами, одно время это применялось при написании вирусов, умерло из-за сложности трассировки

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

на самом деле очень не хватает структурированной инфографики кем пойти работать в IT, если для специалистов по качеству линейку развития специалистов дают на первой же лекции по STQB, то для программиста ничего подобного нет, это хорошая статья для планирования своего развития в инфобезе, но ее бы хорошо дополнить инфографикой с пирамидкой интерес-специальность-компетенции

как вариант точки роста: вместо pod.status"running" воспользоваться liveness пробой, ее результаты можно получать из команды kubectl

describe pod namepod

Warning Unhealthy 10s (x3 over 20s)

...

суть в том, что если у pod зависимость от другого сервиса (деплой которого наше изменение пайплайна опосредованно сломало), тестовый pod может начать ребутиться каждые 30сек но статус running у него будет присутствовать

спасибо большое за исследование, так действительно все прозрачно стало по генерации ссылок

не могу согласиться, могло быть в презентациях для внутреннего использования, да и после разрыва отношений рф с сша могли выпилить

технология чебурашка - это действительно ракета ангара5, он не выдумал

Вы сделали прекрасный базис для тестирования rest-api сервисов, к сожалению api бывают еще и всякие разнообразные RPC, мир живет не только на http, думаю поэтому статью минусят.
По моему опыту большая часть проблем с авто-тестами немножко все ж не на уровне базового слоя, голый pytest + request достаточно читабельный, а вот уровень тест-дизайна страдает по максимуму - даже при помощи вашего фреймворка можно будет понаписать лапши, которая не бьется ни по одной из техник https://highload.today/blogs/8-tehnik-test-dizajna-s-primerami/#8
Если честно, мне кажется ваш цикл статей пытается решить организационные вопросы менеджмента разработки небольших компаний с помощью кода вместо использования софтскилов.
Проблема подхода в том, что без оглядки изобретается велосипед, который уже проработан у корпоратов, я помню очень похожий слой авто-тестов предлагал оператор МТС, но их авто-тесты жили в парадигме TDD и писались до создания сервисов - на зафейленный тест тут же заводился автоматом баг и разрабы писали код сервиса под тесты

эт не просто статья, это Ерошенко, он легенда

надеюсь в конце концов окажется что это все делал chatgpt чтобы оплатить свои мощности

а вот в azure kubectl это про тоже самое ? хотелось бы какую-то сводную статью про все эти подходы управления инфраструктуры в облаках, когда что даёт преимущества