Мне тоже не нравится, но по прямо противоположной причине - это полумера, которая способна запутать код, поскольку без привлечения более мощных средств расширения проверок типов, например 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
Странная статья… Подавляющее большинство программистов работают удалённо. Не в том смысле, что из дома, а в том смысле, что в другой локации, нежели их заказчики, либо рынок сбыта — на аутсорсеров или просто на западных заказчиков или пытаются продавать продукт на западном рынке. И вот вопрос — а какая, в общем-то, разница — где сидит тушко такого вот специалиста? Сидит оно там, где ему удобнее и привычнее — вот и всё. На мой взгляд, нет смысла говорить о том, что мозги, таланты и прочее куда-то там ускользают или исчезают — в манящее "забугорье" или ещё куда-то. Они просто в независимости от локации присутствуют на мировом рынке и их услуги доступны всякому, кто готов за них эффективно конкурировать.
Так что давайте называть вещи своими именами — все эти стенания про "ускользания талантов" — это просто прикрытие желания избежать полноценной конкуренции за труд со стороны одного из неконкурентоспособных заказчиков в лице неконкурентоспособной части российского бизнеса и гос. сектора, пользуясь тем, что наши тушки тут локализованы. Им не нравится, что мы не хотим работать на тех, кто платит меньше, у кого задачи менее интересные, хуже менеджмент и кто создаёт худшие условия для работы. Ну и пусть не нравится! Потому что за те деньги и на тех условиях, что они платят, им доступны только индусы. Ну и что тут такого — российские программисты работают на западных заказчиков, а на российские компании и гос. сектор работают индусы? Нормальная ситуация.
IMHO, проблема не в AirBnB, а гораздо глубже — она в усилении деурбанизации. Городская инфраструктура в целом ветшает, и цена поддержки в следствии этого (электропроводки, канализации и прочих необходимых сервисов) в рабочем состоянии, естественно, растёт. При этом всё больше профессий переводятся в формат удалёнки, да и для остатков офисного планктона развитый транспорт позволяет ежедневно в приемлемый срок добираться всё более и более издалека, живя во всё более дальних пригородах. Так что смекнувшие это предприимчивые граждане всё больше продают своё жильё и переезжают в пригороды, в частный сектор, а их «доступное» жильё приобретают предприниматели и сдают через AirBnB. Потому что если кого-то из платёжеспособных клиентов всё ещё интересуют эти самые ветшающие города, пока они ещё сохраняют по крайней мере красивый внешний вид — так это туристов. В этой ситуации «незащищённые слои» бедняков (про которых ещё вопрос — не потому ли они бедняки, что не переехали в пригороды и платят втридорога налоги и прочие ЖКХ за то, что приросли к своим квартиркам попами) оказываются в проигрыше. И им это не нравится. Сочувствую им…
В Java 11 появился-таки простой метод считывания файла в строку — Files::readString, а так же записи в файл из строки — Files::writeString. Правда, остаётся проблема — как заюзать classloader для поиска файла, что бы не заморачиваться относительными и абсолютными путями, если знаешь, что файл в classpath’е (например, в папке ./src/main/resources проекта)? Решение придумал только такое — у кого получится более элегантно — напишите. У меня (с Lombok’ом и Vavr’ом) получилось так:
Жаль, автор опустил одну из моих любимых фич этой библиотеки — Either и CheckedFunction'ы — поскольку не Try'ем единым решаются проблемы с checked-exception'ами старых Java API. В остальном статья неплоха, спасибо! И ждём продолжения с лучшими практиками использования!
Из хоть как-то значимого для разработчиков бизнес-логики (не перформанс-инженеров) по сути появились 2 фичи:
1) JEP 330: Launch Single-File Source-Code Programs.
Суть: если файл с исходниками на Java не ссылается ни на какие другие файлы с исходниками, т.е. является SFSCP (Single File Source-Code Program), например:
// java HelloWorld.java
public class HelloWorld {
public static void main(String[] args){
System.out.println("Hello World!!!");
}
}
, то запустить его теперь можно просто так:
java HelloWorld.java
2) JEP 323: Local-Variable Syntax for Lambda Parameters (var`ы в лямбда-параметрах).
Суть — в лямбдах теперь перед параметрами можно поставить ключевое слово var. И тип тогда сам выведится. Какую проблему это решает, спросите вы? Ведь в лямбдах и раньше можно было не писать тип вовсе и он итак прекрасно выводился… На самом деле проблема в том, что иногда нужно аннотировать типы (фича появилась в Java 8) в лямбдах — и раньше для этого приходилось явно прописывать тип, а теперь можно вместо этого их выводить — поставить вместо типа var — и тип выведется из контекста, но теперь перед ним можно поставить аннотацию. Раньше было нельзя.
Это можно использовать в tools`ах типа CheckerFramework`а и доп. проверок в IDE — например, аннотаций типа NotNull и Nullable, предоставляющих такую фичу, как nullability в Java (не Kotlin, конечно, но лучше, чем ничего).
Если бы только это…
Stream, который тут неявно создаётся, должен быть закрыт вызовом метода close() (от чего, конечно, спасёт try-with-resources, но ещё удобнее Lombok`овская аннотация @Cleanup)
Кроме того, вариант для Java 8 плох тем, что часто у нас нет абсолютного пути файла, только его имя и уверенность, что он лежит где-то в CLASSPATH (так бывает, если он в папке "src/main/resources" или для тестов — "src/test/resources" — в Maven-Gradle проектной структуре), так что гораздо удобнее использовать для поиска ClassLoader.
В общем, у меня получилось так (Java 8+ и не забываем подключить в проект Lombok):
class MyClass {
@SneakyThrows
public static void doWithFileLines(String fileName, Consumer<String> stringConsumer) {
@Cleanup
BufferedReader reader = new BufferedReader(
new InputStreamReader(
MyClass.class.getResourceAsStream(fileName), UTF_8));
String line;
while ((line = reader.readLine()) != null)
stringConsumer.accept(line);
}
// Файл с таким именем должен лежать в ./src/test/resources в проекте
static final String FILE_NAME = "/text.txt";
// Дёргаем так:
@Test
@DisplayName("doWithFileLines method works correctly")
void testDoWithFileLines() {
doWithFileLines(FILE_NAME, line -> {
// Здесь пишем, что надо делать с каждой строчкой,
// например что бы вывести на консоль:
System.out.println(line);
});
}
}
Да и 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
Странная статья… Подавляющее большинство программистов работают удалённо. Не в том смысле, что из дома, а в том смысле, что в другой локации, нежели их заказчики, либо рынок сбыта — на аутсорсеров или просто на западных заказчиков или пытаются продавать продукт на западном рынке. И вот вопрос — а какая, в общем-то, разница — где сидит тушко такого вот специалиста? Сидит оно там, где ему удобнее и привычнее — вот и всё. На мой взгляд, нет смысла говорить о том, что мозги, таланты и прочее куда-то там ускользают или исчезают — в манящее "забугорье" или ещё куда-то. Они просто в независимости от локации присутствуют на мировом рынке и их услуги доступны всякому, кто готов за них эффективно конкурировать.
Так что давайте называть вещи своими именами — все эти стенания про "ускользания талантов" — это просто прикрытие желания избежать полноценной конкуренции за труд со стороны одного из неконкурентоспособных заказчиков в лице неконкурентоспособной части российского бизнеса и гос. сектора, пользуясь тем, что наши тушки тут локализованы. Им не нравится, что мы не хотим работать на тех, кто платит меньше, у кого задачи менее интересные, хуже менеджмент и кто создаёт худшие условия для работы. Ну и пусть не нравится! Потому что за те деньги и на тех условиях, что они платят, им доступны только индусы. Ну и что тут такого — российские программисты работают на западных заказчиков, а на российские компании и гос. сектор работают индусы? Нормальная ситуация.
Из хоть как-то значимого для разработчиков бизнес-логики (не перформанс-инженеров) по сути появились 2 фичи:
1) JEP 330: Launch Single-File Source-Code Programs.
Суть: если файл с исходниками на Java не ссылается ни на какие другие файлы с исходниками, т.е. является SFSCP (Single File Source-Code Program), например:
, то запустить его теперь можно просто так:
2) JEP 323: Local-Variable Syntax for Lambda Parameters (var`ы в лямбда-параметрах).
Суть — в лямбдах теперь перед параметрами можно поставить ключевое слово
var. И тип тогда сам выведится. Какую проблему это решает, спросите вы? Ведь в лямбдах и раньше можно было не писать тип вовсе и он итак прекрасно выводился… На самом деле проблема в том, что иногда нужно аннотировать типы (фича появилась в Java 8) в лямбдах — и раньше для этого приходилось явно прописывать тип, а теперь можно вместо этого их выводить — поставить вместо типаvar— и тип выведется из контекста, но теперь перед ним можно поставить аннотацию. Раньше было нельзя.Это можно использовать в tools`ах типа CheckerFramework`а и доп. проверок в IDE — например, аннотаций типа NotNull и Nullable, предоставляющих такую фичу, как nullability в Java (не Kotlin, конечно, но лучше, чем ничего).
Если бы только это…
Stream, который тут неявно создаётся, должен быть закрыт вызовом метода close() (от чего, конечно, спасёт try-with-resources, но ещё удобнее Lombok`овская аннотация @Cleanup)
Кроме того, вариант для Java 8 плох тем, что часто у нас нет абсолютного пути файла, только его имя и уверенность, что он лежит где-то в CLASSPATH (так бывает, если он в папке "src/main/resources" или для тестов — "src/test/resources" — в Maven-Gradle проектной структуре), так что гораздо удобнее использовать для поиска ClassLoader.
В общем, у меня получилось так (Java 8+ и не забываем подключить в проект Lombok):