Да зарплата кота обычно не столь обременительна, что бы менеджер охотился за ним как за "Самым слабым звеном" команды в надежде сэкономить бюджетные деньги проекта без существенного падения общей продуктивности... Ему разве что когтеточку надо, что бы на замену мебели потом тратиться не пришлось, ну и к лотку приучить, что бы ковролин по-реже менять, ну и может ещё по весне ему что-то эротишное придумать, либо операцию - обычно это не напряжно...
В Vavr'е можно дёргать непосредственно классы, т.е. вместо Stream.of(...) дёргать Stream(...). Это делается посредством static-import'а из его класса io.vavr.API, где собраны наиболее популярные статические методы генерации. Такой код выглядит элегантнее и больше похож на то, чем в основном вдохновляется Vavr — т.е. на Scala.
Хм... ну вообще-то есть намного более простой и стандартный способ - использовать spring-boot-configuration-processor. Тогда пользователь стартера увидит дефолтные значения в подсказках IDEA'и, когда будет их редактировать - они будут в файле spring-configuration-metadata.json и IDEA будет их отображать в подсказках пользователю.
Мне тоже не нравится, но по прямо противоположной причине - это полумера, которая способна запутать код, поскольку без привлечения более мощных средств расширения проверок типов, например CheckerFramework'а, трудно будет обеспечить гарантии. Ну вот пишу я метод - как мне сказать компилятору "Проверь обязательно, что бы в ScopedValue при вызове моего метода обязательно по такому-то ключу лежал объект такого-то типа с таким-то дженериком, а при попытке вызова без этого - вали компиляцию"? Никак. И когда это сделают в CheckerFramework'е, и вообще - сделают ли — непонятно... На мой взгляд, чем такой труднопроверяемый огород городить, нужно было бы просто сделать implicit-параметры, как в Scala - и проблема была бы решена наилучшим образом, а так - это полумера, которая только дополнительную неразбериху создаёт и вынуждает перекладывать ответственность на сторонние инструменты, типа того же CheckerFramework'а...
Брать СССР в качестве примера - это, возможно, "ошибка выжившего", а я говорю об IT'шниках в целом - не только о IT'шниках в РФ. Даже сейчас, уже после 40 лет развала стран Варшавского договора, разница видна невооружённым глазом: в капиталистических странах уровень преступности неплохо коррелирует с налогами: высокие налоги - низкая преступность, низкие налоги - высокая преступность. Я вот одно время думал передраться в Калифорнию, например, но увидел, что там очень высокие налоги и стал разузнавать - где там налоги по-меньше? Выяснил, что в Сакраменто, но - там же и самая высокая преступность... Спокойно в Швейцарии, Дании... А вот в странах бывшего соц. лагеря, как бы люди ни были бедны, преступность обычно низкая - Болгария, Венгрия, Польша... Наши "лихие 90-е" одно из немногих исключений. Так что, несмотря на исключения, мне кажется, что правило-то работает...
IMHO, проблема не в этом, а в социальной составляющей. IT'шники - это в среднем более умные в техническом отношении люди, которые пошли в эту сферу потому, что она в своё время выглядела хорошим "социальным лифтом" - если ты из бедноватой семьи, но "котелок у тебя более или менее варит", вперёд - делай карьеру, решая сложные задачи для бизнеса, сидя в комфортных офисах или даже удалённо, выплачивай свою (теперь - ещё и специальную, льготную IT'шную) ипотеку, отдыхай где хочешь, переезжай куда хочешь и - жизнь более или менее удалась! По крайней мере, она у тебя лучше, чем у многих твоих менее умных соседей или одноклассников. Меритократия. Да, и раньше были подозрения, что IT - это пузырь, НО (!) - если так, то это пузырь, который общества и государства сознательно или нет, но по факту создали во многом для того, что бы утилизировать массу неимущих, но при этом талантливых в технических сферах людей, что бы они в целях осуществления своих амбиций даже и не думали смотреть в сторону криминала и прочих деструктивных для общества и государства направлениях, а "мыслили позитивно". Если IT - это пузырь, то нашими зарплатами общество от нас откупается. Потому что иначе - есть такое подозрение - правоохранительная система и спецслужбы просто не справятся с такой массой "умников", у которых не будет никаких перспектив в жизни и, соответственно, им будет нечего терять кроме своих кандалов (ипотек и прочих обязательств). Это, ведь, будут не отморозки-амбалы, а скорее "злые гении", которе так всё запутают, что имеющихся Пуаро и Шерлоков Холмсов на них системе явно не хватит. Конечно, не все уволенные программисты назавтра же станут профессорами Мориарти, но они будут появляться - пускай хотя бы каждый тысячный - возможно, этого уже хватит, что бы перевернуть лодочку... А уж хакерство-то как расцветёт! Особенно учитывая, что весь мир уже практически отказался от нала (или кто-то думает, что в коде, написанном нейронками по промптам, дыр будет меньше, чем в тех, что люди пишут?)...
Я думаю, что люди на верху это понимают и не станут лопать этот пузырь, даже если с т.з. бизнес-результата это и будет оправданно. По крайней мере, пока не придумают какой-то другой перспективный способ утилизации нашей активности... Пока же массовый переход на написание промптов выглядит не достаточно привлекательно - боюсь, когда и если допилят эту систему, то таких специалистов понадобится на порядки меньше, чем программистов сейчас...
Прямо вспомнилось из С. Минаева: "– Вот что интересно. У меня родня в Нижнем Новгороде. Так вот, там пиво местное стоит тринадцать рублей. А в Москве оно же уже двадцать пять. – Ну, – отвечает второй, – это понятно почему. Доставка там, тыры-пыры, вот и стоит в Москве дороже. – А! – радостно взвивается брейкер. – А почему тогда колбаса клинская и в Москве, и в Новгороде стоит почти одинаково? Чё, доставки нету? Или чё? Лицо его собеседника, выхватываемое из темноты тамбура придорожными фонарями, покрывается морщинами, вызванными бешеной работой мозга в поисках решения данной экономической проблемы. – Да… – говорит он вслух, – непонятки… – Ага. И мне непонятно. Скорее всего [чудаки] они там все. Или считать не умеют, или тупые. Понятно и ежу, что скока бы ни стоила (ну в пределах там) – всяко бы покупали. – Да… – окончательно запутавшимся голосом ответил второй. – Точняк. Vox populum, скажу я вам, – страшная сила. Есть в ней что-то такое от гуннов. Конницей сметающее на своем пути все те ажурные замки социальных, экономических и философских схем, ежедневно (и за нехилые бабки) выстраиваемых учеными мужами. Гениями маркетинга и менеджмента. Если бы эти местные Бивис с Батхедом знали бы, какие катастрофически огромные деньги получают все эти отделы маркетинга, логистики, региональной дистрибьюции и планирования. Сколько времени тратится на расчет цены в далеком регионе, на уменьшение издержек, сокращение маржи и прочее и прочее. Чтобы там, в удаленном от Москвы регионе, какой-нибудь брейкер мог позволить себе купить под водочку колбасы, чтобы не ударило это по его облегченному покупкой водки карману. Чтоб покупал он чаще и больше. И за разумные деньги. А тут – нате. Острый, как заточка гопника, аргумент: «Скорее всего [чудаки] они там все. Или считать не умеют, или тупые». В такие моменты особенно остро чувствуешь свою удаленность от народа. Понимаешь всю никчемность своих трудов и усилий. Свою, а следовательно, и многотысячной армии менеджеров любых звеньев экономической цепи. Цепи, которая бьет тебя другим концом по голове, хотя кажется, что ты ее крепко держишь и направляешь. На самом деле – это она держит тебя."
Что-то у меня при чтении об этом жгучем желании по-меньше налогов платить, возникла бизнес-идея - открыть коворкинг в аэропорту, в дьюти-фри зоне - ведь, осуществляемая там деятельность не может считаться осуществляемой на территории хоть какого-либо государства - даже Грузия не сможет взять свой 1%, так?.. ;) А ещё лучше - открыть плавучий коворкинг и пусть IT-шники работают в нейтральных водах!..
Можно поднимать вопрос в русле экономики - есть так называемые "теории стоимости". Грубо говоря, есть:
Трудовые теории стоимости - стоимость всякой вещи зависит от кол-ва труда, вложенного в её производство с учётом всего скрытого труда вплоть до труда на получение квалификации, необходимого для её производства;
Теории стоимости, основанные на полезности результата для потребителя - и тут уже, действительно, возможны сверхприбыли в случае, если ты делаешь что-то очень ценное и очень быстро.
Полутона - теории, которые пытаются эти два подхода как-то объединить...
Я убеждён, что чистый первый подход в IT уже давно не возможен и многим хотелось бы перейти ко второму подходу, а не утопать в третьем, но на практике проблема IT в том, что цепочка операций от непосредственной деятельности программиста до получения прибыли от её результата настолько длинная и сложная, что, как мне говорили некоторые знакомые, не позволяет выстроить прямые и внятные прозрачные трассировки, что бы плата за результат была справедливой и отражала реальный рынок с его конкуренцией. Возможно, задачу полного и окончательного перехода от трудовой к полезности удастся когда-то кому-то решить (в частности, тут можно посмотреть доклады Егора Бугаенко - он, насколько я понимаю, как менеджер, пытался и может быть даже пытается выстроить именно такую систему и охотно про это рассказывает), но пока это сложно, лучшее на что мы можем рассчитывать - это те самые переходные "полутона"...
Spring Cloud тоже имеет maven'овского parent'а (который в свою очередь наследуется от Spring Boot Parent'а, так что Вы ничего не теряете - все Boot'овые конфигурации зависимостей прилетают к Вам точно так же): org.springframework.cloud:spring-cloud-starter-parent:2020.0.4
Правда, он немного отстаёт от Boot'а - например, сейчас, на состояние 7 октября 2021'го года, актуальная версия Boot'а 2.5.5 , а приведённая выше последняя актуальная версия Cloud parent'а 2020.0.4 тянет Boot версии 2.4.10 , так что если хочется use'ать последние фишки Boot'а - описанный Вами подход с Boot'овым parent'ом и Cloud'ным BOM'ом имеет смысл.
На мой взгляд, делать целый Java-проект только ради того, что бы поставить одну аннотацию над main-классом и прописать конфиг - слишком громоздко. У Cloud'а есть CLI, который устанавливается в качестве расширения для Spring Boot CLI. Несколько устаревшая документация по нему доступна тут - https://cloud.spring.io/spring-cloud-static/spring-cloud-cli/current/reference/html/ - он позволяет запустить, например, eureka'у без создания проекта и вообще без единой строчки кода - просто набрать в командной строке: $ spring cloud eureka и она стартанёт точно так же.
В этом случае необходимую для запуска конфигурацию можно расположить в поддиректорию "config" в текущей папке, назвав файл по имени сервиса - eureka.yml
Странная статья… Подавляющее большинство программистов работают удалённо. Не в том смысле, что из дома, а в том смысле, что в другой локации, нежели их заказчики, либо рынок сбыта — на аутсорсеров или просто на западных заказчиков или пытаются продавать продукт на западном рынке. И вот вопрос — а какая, в общем-то, разница — где сидит тушко такого вот специалиста? Сидит оно там, где ему удобнее и привычнее — вот и всё. На мой взгляд, нет смысла говорить о том, что мозги, таланты и прочее куда-то там ускользают или исчезают — в манящее "забугорье" или ещё куда-то. Они просто в независимости от локации присутствуют на мировом рынке и их услуги доступны всякому, кто готов за них эффективно конкурировать.
Так что давайте называть вещи своими именами — все эти стенания про "ускользания талантов" — это просто прикрытие желания избежать полноценной конкуренции за труд со стороны одного из неконкурентоспособных заказчиков в лице неконкурентоспособной части российского бизнеса и гос. сектора, пользуясь тем, что наши тушки тут локализованы. Им не нравится, что мы не хотим работать на тех, кто платит меньше, у кого задачи менее интересные, хуже менеджмент и кто создаёт худшие условия для работы. Ну и пусть не нравится! Потому что за те деньги и на тех условиях, что они платят, им доступны только индусы. Ну и что тут такого — российские программисты работают на западных заказчиков, а на российские компании и гос. сектор работают индусы? Нормальная ситуация.
Да зарплата кота обычно не столь обременительна, что бы менеджер охотился за ним как за "Самым слабым звеном" команды в надежде сэкономить бюджетные деньги проекта без существенного падения общей продуктивности... Ему разве что когтеточку надо, что бы на замену мебели потом тратиться не пришлось, ну и к лотку приучить, что бы ковролин по-реже менять, ну и может ещё по весне ему что-то эротишное придумать, либо операцию - обычно это не напряжно...
Сам таких людей называю "катализаторами" (довольно близкий термин из химии, если кто вдруг не знает).
В Vavr'е можно дёргать непосредственно классы, т.е. вместо
Stream.of(...)дёргатьStream(...). Это делается посредством static-import'а из его классаio.vavr.API, где собраны наиболее популярные статические методы генерации. Такой код выглядит элегантнее и больше похож на то, чем в основном вдохновляется Vavr — т.е. на Scala.CheckerFramework :)
Хм... ну вообще-то есть намного более простой и стандартный способ - использовать spring-boot-configuration-processor. Тогда пользователь стартера увидит дефолтные значения в подсказках IDEA'и, когда будет их редактировать - они будут в файле spring-configuration-metadata.json и IDEA будет их отображать в подсказках пользователю.
Есть ещё книга Kevin Hoffman "Beyond the Twelve-Factor App" - https://www.oreilly.com/library/view/beyond-the-twelve-factor/9781492042631/ - там более глубокая критика и не только дополнения, но и удаление устаревших факторов из этих классических 12-и...
Да и scope'ы в Java EE можно вспомнить - context, session, request... Такая же история по сути.
Мне тоже не нравится, но по прямо противоположной причине - это полумера, которая способна запутать код, поскольку без привлечения более мощных средств расширения проверок типов, например CheckerFramework'а, трудно будет обеспечить гарантии. Ну вот пишу я метод - как мне сказать компилятору "Проверь обязательно, что бы в ScopedValue при вызове моего метода обязательно по такому-то ключу лежал объект такого-то типа с таким-то дженериком, а при попытке вызова без этого - вали компиляцию"? Никак. И когда это сделают в CheckerFramework'е, и вообще - сделают ли — непонятно...
На мой взгляд, чем такой труднопроверяемый огород городить, нужно было бы просто сделать implicit-параметры, как в Scala - и проблема была бы решена наилучшим образом, а так - это полумера, которая только дополнительную неразбериху создаёт и вынуждает перекладывать ответственность на сторонние инструменты, типа того же CheckerFramework'а...
Расширение существующих классов -> @ExtensionMethod в Lombok'е и @Extensions в Manifold'е
Остальное - ждём от VAVR'а и новых версий Java...
Допускаю, скажем так...
Разве результат работы человека на должности Системного аналитика - это не достаточная для нейронки формализация?
Брать СССР в качестве примера - это, возможно, "ошибка выжившего", а я говорю об IT'шниках в целом - не только о IT'шниках в РФ. Даже сейчас, уже после 40 лет развала стран Варшавского договора, разница видна невооружённым глазом: в капиталистических странах уровень преступности неплохо коррелирует с налогами: высокие налоги - низкая преступность, низкие налоги - высокая преступность. Я вот одно время думал передраться в Калифорнию, например, но увидел, что там очень высокие налоги и стал разузнавать - где там налоги по-меньше? Выяснил, что в Сакраменто, но - там же и самая высокая преступность... Спокойно в Швейцарии, Дании... А вот в странах бывшего соц. лагеря, как бы люди ни были бедны, преступность обычно низкая - Болгария, Венгрия, Польша... Наши "лихие 90-е" одно из немногих исключений. Так что, несмотря на исключения, мне кажется, что правило-то работает...
IMHO, проблема не в этом, а в социальной составляющей. IT'шники - это в среднем более умные в техническом отношении люди, которые пошли в эту сферу потому, что она в своё время выглядела хорошим "социальным лифтом" - если ты из бедноватой семьи, но "котелок у тебя более или менее варит", вперёд - делай карьеру, решая сложные задачи для бизнеса, сидя в комфортных офисах или даже удалённо, выплачивай свою (теперь - ещё и специальную, льготную IT'шную) ипотеку, отдыхай где хочешь, переезжай куда хочешь и - жизнь более или менее удалась! По крайней мере, она у тебя лучше, чем у многих твоих менее умных соседей или одноклассников. Меритократия.
Да, и раньше были подозрения, что IT - это пузырь, НО (!) - если так, то это пузырь, который общества и государства сознательно или нет, но по факту создали во многом для того, что бы утилизировать массу неимущих, но при этом талантливых в технических сферах людей, что бы они в целях осуществления своих амбиций даже и не думали смотреть в сторону криминала и прочих деструктивных для общества и государства направлениях, а "мыслили позитивно". Если IT - это пузырь, то нашими зарплатами общество от нас откупается. Потому что иначе - есть такое подозрение - правоохранительная система и спецслужбы просто не справятся с такой массой "умников", у которых не будет никаких перспектив в жизни и, соответственно, им будет нечего терять кроме своих кандалов (ипотек и прочих обязательств). Это, ведь, будут не отморозки-амбалы, а скорее "злые гении", которе так всё запутают, что имеющихся Пуаро и Шерлоков Холмсов на них системе явно не хватит. Конечно, не все уволенные программисты назавтра же станут профессорами Мориарти, но они будут появляться - пускай хотя бы каждый тысячный - возможно, этого уже хватит, что бы перевернуть лодочку... А уж хакерство-то как расцветёт! Особенно учитывая, что весь мир уже практически отказался от нала (или кто-то думает, что в коде, написанном нейронками по промптам, дыр будет меньше, чем в тех, что люди пишут?)...
Я думаю, что люди на верху это понимают и не станут лопать этот пузырь, даже если с т.з. бизнес-результата это и будет оправданно. По крайней мере, пока не придумают какой-то другой перспективный способ утилизации нашей активности...
Пока же массовый переход на написание промптов выглядит не достаточно привлекательно - боюсь, когда и если допилят эту систему, то таких специалистов понадобится на порядки меньше, чем программистов сейчас...
<reuseForks>true</reuseForks> не нужно писать - это default'ное знаение - https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#reuseForks
Помню, как-то на гик-пикнике выступал с темой "Как войти в IT, потом выйти из IT и зайти обратно?" Название напомнило))
Прямо вспомнилось из С. Минаева:
"– Вот что интересно. У меня родня в Нижнем Новгороде. Так вот, там пиво местное стоит тринадцать рублей. А в Москве оно же уже двадцать пять.
– Ну, – отвечает второй, – это понятно почему. Доставка там, тыры-пыры, вот и стоит в Москве дороже.
– А! – радостно взвивается брейкер. – А почему тогда колбаса клинская и в Москве, и в Новгороде стоит почти одинаково? Чё, доставки нету? Или чё?
Лицо его собеседника, выхватываемое из темноты тамбура придорожными фонарями, покрывается морщинами, вызванными бешеной работой мозга в поисках решения данной экономической проблемы.
– Да… – говорит он вслух, – непонятки…
– Ага. И мне непонятно. Скорее всего [чудаки] они там все. Или считать не умеют, или тупые. Понятно и ежу, что скока бы ни стоила (ну в пределах там) – всяко бы покупали.
– Да… – окончательно запутавшимся голосом ответил второй. – Точняк. Vox populum, скажу я вам, – страшная сила. Есть в ней что-то такое от гуннов. Конницей сметающее на своем пути все те ажурные замки социальных, экономических и философских схем, ежедневно (и за нехилые бабки) выстраиваемых учеными мужами. Гениями маркетинга и менеджмента. Если бы эти местные Бивис с Батхедом знали бы, какие катастрофически огромные деньги получают все эти отделы маркетинга, логистики, региональной дистрибьюции и планирования. Сколько времени тратится на расчет цены в далеком регионе, на уменьшение издержек, сокращение маржи и прочее и прочее. Чтобы там, в удаленном от Москвы регионе, какой-нибудь брейкер мог позволить себе купить под водочку колбасы, чтобы не ударило это по его облегченному покупкой водки карману. Чтоб покупал он чаще и больше. И за разумные деньги.
А тут – нате. Острый, как заточка гопника, аргумент: «Скорее всего [чудаки] они там все. Или считать не умеют, или тупые».
В такие моменты особенно остро чувствуешь свою удаленность от народа. Понимаешь всю никчемность своих трудов и усилий. Свою, а следовательно, и многотысячной армии менеджеров любых звеньев экономической цепи. Цепи, которая бьет тебя другим концом по голове, хотя кажется, что ты ее крепко держишь и направляешь. На самом деле – это она держит тебя."
"Духless, повесть о ненастоящем человеке", 2006г.
Что-то у меня при чтении об этом жгучем желании по-меньше налогов платить, возникла бизнес-идея - открыть коворкинг в аэропорту, в дьюти-фри зоне - ведь, осуществляемая там деятельность не может считаться осуществляемой на территории хоть какого-либо государства - даже Грузия не сможет взять свой 1%, так?.. ;)
А ещё лучше - открыть плавучий коворкинг и пусть IT-шники работают в нейтральных водах!..
Можно поднимать вопрос в русле экономики - есть так называемые "теории стоимости". Грубо говоря, есть:
Трудовые теории стоимости - стоимость всякой вещи зависит от кол-ва труда, вложенного в её производство с учётом всего скрытого труда вплоть до труда на получение квалификации, необходимого для её производства;
Теории стоимости, основанные на полезности результата для потребителя - и тут уже, действительно, возможны сверхприбыли в случае, если ты делаешь что-то очень ценное и очень быстро.
Полутона - теории, которые пытаются эти два подхода как-то объединить...
Я убеждён, что чистый первый подход в IT уже давно не возможен и многим хотелось бы перейти ко второму подходу, а не утопать в третьем, но на практике проблема IT в том, что цепочка операций от непосредственной деятельности программиста до получения прибыли от её результата настолько длинная и сложная, что, как мне говорили некоторые знакомые, не позволяет выстроить прямые и внятные прозрачные трассировки, что бы плата за результат была справедливой и отражала реальный рынок с его конкуренцией. Возможно, задачу полного и окончательного перехода от трудовой к полезности удастся когда-то кому-то решить (в частности, тут можно посмотреть доклады Егора Бугаенко - он, насколько я понимаю, как менеджер, пытался и может быть даже пытается выстроить именно такую систему и охотно про это рассказывает), но пока это сложно, лучшее на что мы можем рассчитывать - это те самые переходные "полутона"...
Пара чуть упрощающих жизнь дополнений:
Spring Cloud тоже имеет maven'овского parent'а (который в свою очередь наследуется от Spring Boot Parent'а, так что Вы ничего не теряете - все Boot'овые конфигурации зависимостей прилетают к Вам точно так же): org.springframework.cloud:spring-cloud-starter-parent:2020.0.4
Правда, он немного отстаёт от Boot'а - например, сейчас, на состояние 7 октября 2021'го года, актуальная версия Boot'а 2.5.5 , а приведённая выше последняя актуальная версия Cloud parent'а 2020.0.4 тянет Boot версии 2.4.10 , так что если хочется use'ать последние фишки Boot'а - описанный Вами подход с Boot'овым parent'ом и Cloud'ным BOM'ом имеет смысл.
На мой взгляд, делать целый Java-проект только ради того, что бы поставить одну аннотацию над main-классом и прописать конфиг - слишком громоздко. У Cloud'а есть CLI, который устанавливается в качестве расширения для Spring Boot CLI. Несколько устаревшая документация по нему доступна тут - https://cloud.spring.io/spring-cloud-static/spring-cloud-cli/current/reference/html/ - он позволяет запустить, например, eureka'у без создания проекта и вообще без единой строчки кода - просто набрать в командной строке:
$ spring cloud eureka
и она стартанёт точно так же.
В этом случае необходимую для запуска конфигурацию можно расположить в поддиректорию "config" в текущей папке, назвав файл по имени сервиса - eureka.yml
Странная статья… Подавляющее большинство программистов работают удалённо. Не в том смысле, что из дома, а в том смысле, что в другой локации, нежели их заказчики, либо рынок сбыта — на аутсорсеров или просто на западных заказчиков или пытаются продавать продукт на западном рынке. И вот вопрос — а какая, в общем-то, разница — где сидит тушко такого вот специалиста? Сидит оно там, где ему удобнее и привычнее — вот и всё. На мой взгляд, нет смысла говорить о том, что мозги, таланты и прочее куда-то там ускользают или исчезают — в манящее "забугорье" или ещё куда-то. Они просто в независимости от локации присутствуют на мировом рынке и их услуги доступны всякому, кто готов за них эффективно конкурировать.
Так что давайте называть вещи своими именами — все эти стенания про "ускользания талантов" — это просто прикрытие желания избежать полноценной конкуренции за труд со стороны одного из неконкурентоспособных заказчиков в лице неконкурентоспособной части российского бизнеса и гос. сектора, пользуясь тем, что наши тушки тут локализованы. Им не нравится, что мы не хотим работать на тех, кто платит меньше, у кого задачи менее интересные, хуже менеджмент и кто создаёт худшие условия для работы. Ну и пусть не нравится! Потому что за те деньги и на тех условиях, что они платят, им доступны только индусы. Ну и что тут такого — российские программисты работают на западных заказчиков, а на российские компании и гос. сектор работают индусы? Нормальная ситуация.