Я часто страдаю от того, что при возникновении вопросов первым делом не обращаюсь к документации. Даже не знаю, что повлияло на отсутствие этой полезной привычки. Вероятно, мне просто не хочется выискивать и компилировать ответ самостоятельно. Это ж думать надо 😰 Всегда есть надежда, что на твой вопрос в Google найдется ответ по первой ссылке, которая по удачному стечению обстоятельств ведет на StackOverflow. А если еще и ответ залайканный будет... Хотя бы несколько десятков, а лучше сотен и тысяч лайков. Но чем сложнее вопрос, тем меньше знает Google. Хорошо, что можно еще в ChatGPT заскочить🤤.

В этот раз ко мне ученик пришел с простым вопросом (на скрине). Я, честно говоря, забыл уже, что это за backing properties и backing field, но тема должна была быть очень простой и объясняться парой предложений. Первым делом хотелось провалидировать ответ ChatGPT, который ему показался непонятным. Я задал ChatGPT (странный, если быть в контексте) вопрос:

Расскажи, в чем разница между backing properties и backing field в Kotlin?

Ответ мне не понравился. По крайней мере захотелось поискать другие источники или задать уточняющие вопросы. Я загуглил еще пару статей на эту тему. Тут мне попадались уже более интересные экземпляры, которые давали больше контекста, но ученику их скидывать все равно не хотелось. Я решил посмотреть, а что собственно написано в документации? Это был прекрасный пример того, какой она должна быть: лаконичные примеры кода, понятные комментарии и идеи, которые за ними скрываются. Тут же стало ясно, что все увиденные мной статьи являются перефразированными, но в то же время менее информативными копиями оригинала. В итоге для новичка получился такой ответ, в котором я лишь еще раз подсветил основные идеи:

Что такое backing properties и backing field хорошо описано в документации https://kotlinlang.org/docs/properties.html

В примере с backing fields https://kotlinlang.org/docs/properties.html#backing-fields вместо использования имени свойства counter для присваивания, компилятор нам предоставляет идентификатор field. Для чего? counter = value представляет из себя вызов сеттера для свойства, который мы непосредственно сейчас определяем, что приведет к рекурсивному вызову сеттера внутри сеттера.

В примере с backing properties https://kotlinlang.org/docs/properties.html#backing-properties для работы открытого свойства public val table просто используется дополнительное скрытое свойство private var _table, которое можем назвать любым образом. Это своего рода трюк/лайфхак, про который нам решили рассказать авторы документации.

Так что если изучаем Kotlin, то обращаемся к документации. Это must have. В свое время мне также очень помогли Kotlin in Action и Atomic Kotlin, которые, к сожалению, давно не обновлялись, но все же могут быть полезны, если вас не интересуют последние нововведения. Качественные книги могут не просто пересказать документацию, а более глубоко раскрыть заложенные идеи и концепции изучаемой темы. Такие книги, однако, придется ещё поискать...

Мой друг, кстати, только по доке Golang выучил. Он большой любитель почитать, man'ы ⌨️.

Кроме того некоторые документации часто версионируются, что позволяет сравнить разные версии. Например, документация по всеми любимой PostgreSQL. Вот еще один яркий пример. Даже инструкции по миграции между версиями в наличии.

Вроде тема и совсем капитанская, но, как мне кажется, актуальная для многих. Если вы на постоянной основе не взаимодействуете с качественными источниками информации (вроде книг или документации) по интересующей вас теме, то из раза в раз будете черпать обрывочные знания из несвязанных друг с другом источников, что в средне- и долгосрочной перспективе отсрочит достижение поставленных вами целей.

Мой друг рассказал мне, наверное, уже с год назад о сервисе, который разработает витаминный комплекс под твои потребности. Как это работает? Сначала сдаешь длинный список анализов крови. После того, как придут результаты — тебя проконсультируют врачи (правда, консультация другу не зашла) и пришлют в реально! красивых металлических баночках разноцветные гранулы.

Из того, что не подпадает под историю с витаминами, но что очень зашло — наличие в анализах некоторых популярных онкомаркёров. Кажется, что это те несколько тысяч, которые все же стоит заложить в своем ежегодном бюджете.

Звучит и выглядит все круто, однако есть 2 НО.

Я немного не доверяю комплексам, куда входят сразу много компонентов. Если хотите просто дополнить свой несбалансированный рацион, то ок. Но, кажется, тут подойдут и обычные витаминно-минеральные комплексы, которые можно найти в аптеке или в магазине спортпита (там они ядрёнее: выше концентрации). Но если у вас есть выраженный дефицит... Для его закрытия врачи мне прописывали убойные дозы. Чтобы усвоиться они должны приниматься не только независимо от других витаминов, но и от некоторых продуктов, приемов пищи и в определенное время (чаще утром) 🚨.

D3 мне таким образом удалось поднять с дефицитных 15 единиц до приемлемых 43. Кто сталкивался с этим, поймут меня.

И второе НО. Хотя все и очень удобно, но цена кусается. В этом сентябре я тоже решил организовать себе такой чекап, но самостоятельно. На том же сайте я посмотрел список анализов и сдал его урезанный вариант в лаборатории недалеко от дома. Получилось что-то около 20 т.р. Приемлемо 💳 Что по результатам? Сходил к терапевту за интерпретацией.

Холестерин по верхней границе нормы. Вроде фастфудом и жирной пищей не увлекаюсь, но сидячий малоподвижный образ жизни нельзя списывать со счетов. Уже пью Омега-3 ПНЖК. Надо вернуть тренировки по сквошу, но ноги пока не доходят. Продолжаю пить D3, так как хочется дойти до середины нормального уровня (~60 единиц), тем более ,что начинается осенне-зимний период. Сейчас понял, что забыл еще спросить про повышенный ферритин. Оставлю это до следующего визита.

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

Всем крепкого здоровья! Не болейте 🫶

На меня нахлынула волна ностальгии... Шесть лет назад, будучи молодым и зеленым 😏, я хотел пройти сертификации по Java от Oracle: OCA и OCP. Я усердно готовился, но до экзаменов так и не дошел.

Что они из себя представляют?

OCA оценивает знание фундаментальных основ Java Core. Почти каждый вопрос будет пытаться вас обмануть, проверяя, насколько вы хороший компилятор 😃. Тут и вызовы методов с некорректными сигнатурами, и неправильный нейминг, и необработанные исключения, и так далее по списку... В OCP рассматриваются более высокоуровневые концепции, например, Collection API, Streams, Concurrency и др., приправленные той же проверкой на внимательность.

Эмм, проверка на внимательность, опечатки?.. Звучит сомнительно? С одной стороны — да. Кажется, что хороший программист — не тот, кто не ошибается в синтаксисе. С другой стороны — опытный разработчик должен все это видеть и знать, как само собой разумеющееся. Тут понимаешь, что составляли экзамен авторы старой закалки, для которых такой уровень понимания в порядке вещей. От вас требуется всего лишь знание концепций языка и то, какое отражение в программном коде они находят. Как по мне, в эпоху ИИ, который пишет код сам, экзамен стал еще более актуальным.

Тут, наверное, стоит ответить на вопрос: «Что мне дала эта подготовка?» Это был своеобразный мостик между наивным использованием конструкций языка и:
1) сильными идеями Computer Science, заложенными в язык
2) логикой работы компилятора
о которых узнаешь и начинаешь задумываться. В голове возникал ряд вопросов:
• откуда и почему в коде видны static и non-static переменные вкупе с разными модификаторами доступа (не зная принципов, отгадать очень сложно)
• чем на самом деле являются вложенные классы (синтаксический сахар)
• почему стандартная библиотека Java нарушает принципы SOLID (иммутабельные коллекции и принцип подстановки Барбары Лисков)
• в чем причина использования final и effectively final переменных в анонимных классах (отсутствие полноразмерных замыканий с захватом по значению, а не по ссылке)
• и многие другие

Если у вас все же есть желание подготовиться к этим сертификациям, то существует ряд специализированных книг (OCA, OCP). Я еще пользовался такими тестами. Говорят, что они очень приближены к реальным. Для пущей уверенности можно прикупить дампы реальных экзаменов.

При подготовке я составлял для себя майндкарты (mind maps):
Java Core / OCA
Java Core / OCA / Non-Primitive Types
Java Core / OCP

Боюсь вспоминать, сколько времени было потрачено, хотя объем проделанной работы сейчас не кажется мне большим. Чтобы мои материалы использовать для подготовки в качестве единственного источника требуется серьезно их доработать. Буду это делать по мере возможности.

В любом случае это был увлекательный аттракцион, к которому, возможно, я еще вернусь в будущем. Но абсолютно точно тех ощущений уже не вернуть... Мой первый коммерческий опыт в роли разработчика, никакого ковида, путешествия c друзьями по Европе...

Буквально по горячим следам после моего последнего поста вышло видео на канале Вадима Do4a Иванова про чекап организма.

Это бизнесмен из СПб, а в прошлом — спортсмен, который пережил инфаркт, после чего начал пристально следить за своим здоровьем.

Плюсом к анализам крови он затронул тему проведения УЗИ, которая выпала у меня из головы.

Чем УЗИ так хорошо?
1️⃣ стоит недорого
2️⃣ не вредит организму
3️⃣ делается быстро

Если вы обращались за лечением по ДМС, то знаете, что УЗИ и общий анализ крови назначают практически по-умолчанию, что еще раз подтверждает их эффективность: вас нужно вылечить с минимальными вложениями.

Я мельком посмотрел комплексные предложения от клиник. Диагностика по +- следующему списку:
• органы брюшной полости
• почки
• щитовидная железа
• сердце
• органы малого таза
• сосуды головного мозга и шеи
стоит 5–15 т.р.

Почему могут так отличаться цены, если не брать основной фактор – наценку на услуги. Это, конечно, квалификация врача и уровень оборудования (пока для меня Vivid S70, CANON APLIO 500, Logiq P6 и др. не более чем набор буков).

Есть еще такие виды исследований, как рентген, МРТ и КТ, но они любо не безвредны, либо дороги. Самостоятельно назначать их себе я бы не стал. Кстати, врач при лечении может МРТ и КТ вам даже не предложить (потому что дорого для среднестатистического гражданина), поэтому я всегда спрашиваю, не стоит ли их сделать для получения ясной картины. То же касается и в целом любых дополнительных анализов.

Ок, чекап сделали. Что дальше? Как я уже говорил — консультируемся с врачами. Но этого, к сожалению, мало. Нужно не забывать следить за своим самочувствием ✍️. Вы находитесь со своим организмом 24/7 в отличие от врача. Только вы можете знать все его особенности, фиксировать причинно-следственные связи. Если вы не соберете такой анамнез, то у вас не будет хорошего подспорья перед всего лишь 15-30 минутной консультацией. Можно, конечно, пытаться отвечать на наводящие вопросы непосредственно на приеме, но качественно сделать это сходу у меня еще не получалось 😨.

Врачи, однако, тоже бывают разные. В начале года в местной поликлинике меня сразу после недельного стационара хотели выписать с больничного с диагнозом пневмония, хотя все черным по белому было написано в выписке, правда, второй строчкой, после гриппа 😃. Найти заинтересованного в вашем здоровье профессионала за вменяемые деньги пока тоже не кажется мне простой задачей (смотрю на опыт друзей), но это не повод не начать этот поиск.

На этом свою просветительскую миссию считаю выполненной. Дальше дело за вами 😎

Посмотрел запись от 2018 года с конференции DevOxx, где Джошуа Блох (один из разработчиков платформы Java) распинается перед другими опытными? разработчиками о том, как эффективно! писать код на Java в функциональном стиле, используя λ и Stream API. Это при том, что все рассматриваемые фичи присутствовали уже в Java 8, которая вышла аж в 2014 году. Неужели такая хайповая тема так долго разгонялась?

С другой стороны надо же было отрекламировать запоздавшее третье издание своей книги Effective Java. Она, стоит отметить, учитывает нововведения Java 9, вышедшей в 2017 году. Тем не менее делать упор целиком на фичи 4-х летней давности выглядит странно, но простим ему это.

Кажется, что индустрия сейчас работает на совсем других скоростях. Чего стоит только 36-секундное интро в ролике😂. Любой (ну почти) Java-стажер на собеседовании воспроизведет всю эту теорию. Хотя не удивлюсь, если в 2028 году мы продолжим c упоением обсуждать Project Loom.

Тема функционального программирования в Java, действительно, остается, популярной у авторов и по сей день. Ее изъездили вдоль и поперек: написаны многочисленные книги, статьи и курсы. Я каждый год сталкиваюсь с очередной статьей на habr, где стабильно наблюдаю заплюсованный комментарий с просьбой переключиться уже на другую тему.

Я не останусь в долгу и вкину свои пять копеек 😀. Все таблички, систематизирующие Method Reference, которые я встречал, мне не понравились, поэтому я нарисовал свою (прикреплена к посту).

Самым интересным здесь является тип Bound. Попробуем разобраться с ним при помощи байткода на следующем примере:

class Example {
    public static void main(String[] args) {
        Instant then = Instant.now();
        Predicate<Instant> p1 = then::isAfter;
        Predicate<Instant> p2 = Instant.now()::isAfter;
        Predicate<Instant> p3 = otherInstant -> Instant.now().isAfter(otherInstant); // Idea предлагает такой рефакторинг для p2 с оговоркой There are possible side effects found
    }
}

В p1 берется заранее созданный объект then со стека:

ALOAD 1
DUP
INVOKESTATIC java/util/Objects.requireNonNull (Ljava/lang/Object;)Ljava/lang/Object;
POP
INVOKEDYNAMIC test(Ljava/time/Instant;)Ljava/util/function/Predicate; [
  java/time/Instant.isAfter(Ljava/time/Instant;)Z, 
  (Ljava/lang/Object;)Z
]

Логика p2 схожа с p1, но объект создаётся вызовом Instant.now() при инициализации. Каждое использование этой лямбда-функции ссылается на создаваемый единожды экземпляр Instant:

INVOKESTATIC java/time/Instant.now ()Ljava/time/Instant;
DUP
INVOKESTATIC java/util/Objects.requireNonNull (Ljava/lang/Object;)Ljava/lang/Object;
POP
INVOKEDYNAMIC test(Ljava/time/Instant;)Ljava/util/function/Predicate; [
  java/time/Instant.isAfter(Ljava/time/Instant;)Z, 
  (Ljava/lang/Object;)Z
]

Внутри p3 создаётся новый Instant при каждом вызове, что отличает эту реализацию от p1 и p2:

INVOKEDYNAMIC test()Ljava/util/function/Predicate; [
  Example.lambda$main$0(Ljava/time/Instant;)Z, 
  (Ljava/lang/Object;)Z
]

private static synthetic lambda$main$0(Ljava/time/Instant;)Z
 L0
  INVOKESTATIC java/time/Instant.now ()Ljava/time/Instant;
  ALOAD 0
  INVOKEVIRTUAL java/time/Instant.isAfter (Ljava/time/Instant;)Z
  IRETURN

В целом все очевидно, но нужно быть внимательными 👍

P.S. не удержался и доработал майндакрты из поста

А что если сравнить Stream API в Java c конвейером/пайпланом ввода-вывода в Unix? Это уже сделал за нас некий Diomidis Spinellis в своем блоге. Выглядит по меньшей мере любопытно.

В процессе чтения разблокировалось воспоминание о методе peek(Consumer<? super T> action), который позволяет (от англ.) подсмотреть, что течет в нашем конвейере. Когда-то я услышал байку: метод изначально хотели назвать tee (от T, который своей формой напоминает неожиданно T-образный перекресток), как в Unix. Команда tee позволяет перенаправить вывод в 2 источника, например, файл и консоль:

cat file.txt | tee intermediate.txt | grep "keyword"

Этот пример сохраняет содержимое файла в intermediate.txt перед выполнением поиска по ключевому слову.

Разветвления сигнала (например, посмотреть вывод в консоли) не очень соответствует идее функционального подхода, поэтому от сбивающего с толку названия tee отказались. Использование имени peek как раз подчеркивает встраиваемость в конвейер.

Но название — это полбеды. К peek всегда были вопросы с точки зрения дизайна API, так как он предназначен в первую очередь для отладки. Очевидно, что в prod-среде его лучше не использовать, так как он подразумевает наличие side-effects: от банального вывода в консоль до изменения состояния приложения. Все зависит от фантазии разработчика 😃.

А байка оказалась вовсе никакой не байкой. Похоже, что мне удалось найти ту самую переписку уважаемых авторов, где топикстартер, Kevin Bourrillion, дал точную оценку происходящему:

tee() stands out like a sore thumb. I'm not surprised that Brian says "this method is mostly for debugging."

It just feels very, very strange to let the user inject a side-effect into the middle of their stream somewhere, for mysterious hidden later execution maybe.

If it really must stay, I think I do like "peek" or "observe" over "tee". But I would love to drop it.

Свой teeing в Stream API все же появился, но только в Java 12 и в формате коллектора результатов двух независимых коллекторов:

Double average = Stream.of(1, 2, 3, 4, 5, 6)
        .collect(teeing(
                summingDouble(i -> i),
                counting(),
                (sum, n) -> sum / n));

Реализация получилась зубодробительной 🤔

Необходимость писать многопоточный код появилась не от хорошей жизни. Мы вынуждены это делать, потому что в свое время человечество столкнулось с серьезными технологическими ограничениями, в связи с чем тактовая частота процессоров перестала расти. Почему? Выше частота — выше тепловыделение, а эффективно охладить CPU с их TDP — непростая задача.

На заре 21 века для решения этой проблемы появились многоядерные процессоры: будем не частоту увеличивать, а число ядер. Однако ядра не берутся из ниоткуда, их нужно было встраивать рядом с уже имеющимся ядром. Как этого достичь? Можно увеличивать число транзисторов на единицу площади (уменьшение техпроцесса), пытаясь обуздать физику p-n перехода и свойства полупроводников. Можно увеличивать размер кристалла, что связано с увеличением брака, или количество самих кристаллов (чиплетная архитектура).

Ок, большое число ядер — большие вычислительные мощности. Однако мы, как разработчики, теперь сталкиваемся с задачей вертикального масштабирования наших приложений на многоядерные CPU. Иными словами мы должны задействовать потанцевал потенциал каждого из предоставленных нам ядер, чтобы занять как можно больше процессорного времени.

Если мы говорим о написании бизнес-кода, то зачастую управление потоками любезно скрыто от нас под капотом удобного API фреймворка или библиотеки. За это хочется сказать отдельное спасибо их мейнтейнерам: при перекладывании json'а 🐵 нам почти не приходится задумываться о том, что мы работаем в многопоточной среде. Почему "почти"? К сожалению, при совместном доступе к разделяемым данным проблемы вроде race condition или data race все еще могут возникнуть. Если ваш бизнес-код взаимодействует с внешними ресурсами (БД, кэшем, файлами и т.д.), то ошибки проектирования могут проявиться даже при использовании высокоуровневых абстракций. И все же написание многопоточного кода стало довольно нишевой штукой, которая чаще всего встречается при разработке самих фреймворков и библиотек.

Разработчики начали понимать, что без базовых знаний, как работать в многопоточной среде не обойтись, хотя на собеседованиях многие все равно недоумевают от вопросов по этой теме. Но жизнь идет и настаёт время новых вызовов. Сейчас в России их два:
1️⃣ крупные компании испытывают проблемы с получением современного железа в желаемом объеме (значительно выросли цены и усложнились логистические цепочки)
2️⃣ рост трафика на внутренние сервисы (ведь доступ к зарубежным ограничен)

В этих условиях от разработчика требуется не только чтобы приложение работало быстро. Оно должно эффективно утилизировать имеющиеся ресурсы. Если говорить о CPU-intensive приложениях, то тут в первую очередь нужно будет работать над реализацией эффективных алгоритмов. Если же говорить о сервисах с большим числом интеграций, то один из способов увеличения пропускной способности — избегать любых блокировок потоков (VPN тут не поможет 😃). Блокирующие операции, такие как ожидание завершения другого потока, ответа от базы данных или очередного микросервиса, приводят к простоям приложения. Избежать этого помогают асинхронные неблокирующие подходы. Делаю предположение, что количество проектов, реализующих такую концепцию, в энтерпрайзе будет только расти.

Как с этим обстоят дела в полях? Мне довелось общаться с Java-разработчиками из разных компаний, и я часто слышал, что Reactor/WebFlux у них не прижился из-за сложности разработки и поддержки написанных на нем приложений. Понятно, почему все так полюбили Go — там асинхронный неблокирующий код относительно легко готовить. В Kotlin асинхронные цепочки спрятаны за корутинами, если вы используете библиотеку kotlinx-coroutines-reactor, что достаточно сильно упрощает бизнесовый, но не библиотечный код.

В новому году посмотрим, сбудется ли мой прогноз. По крайней мере рост числа проектов на Go уже заметен. Посмотрим, что будет с таковыми на Java и Kotlin 😎.

Кажется, на новый год мне пожелали мало здоровья — проболел все праздники 😁 ОРВИ, будь она неладна...

В мои планы на эти длинные каникулы входило разобраться наконец c Istio (Service Mesh в k8s), так как изученного в прошлом году ванильного кубера для решения рабочих задач решительно не хватает. Но, как вы понимаете, этим планам не суждено было сбыться. Вооружившись таблетками и спреями, я лежал на диване у купленного почти три месяца назад, но почти не использовавшегося, 65-дюймового ТВ.

В обычное время я сериалами не увлекаюсь, как-то не до них, но раз выдалось подходящее время, то почему бы не глянуть пару-тройку? Настроение было смотреть сериалы про времена СССР. Интересное настроение, не правда ли 😅?

Оказалось, у нас умеют снимать хорошие сериалы. Я, конечно, и раньше знал об этом, даже некоторые смотрел, но тут прям несколько подряд и все понравились.

Комитет — про хороший СССР. Бодрый и бойкий сериал о работе и жизни трех друзей КГБшников от НТВ кто бы сомневался😃. Сюжет тянется через года: начали в 1970-ые, а закончили — в нулевые. Менялись политический строй, общество, люди. На этом фоне было увлекательно наблюдать, как друзья проживали такие похожие, но в то же время такие разные судьбы.

Игры — реалистично? про СССР. Сериал про Олимпиаду 80 и события, которые ей сопутствовали. Намешали целый ворох клеше, но странным образом это сработало. Мне было увлекательно и интересно. Я этой истории поверил.

Красная королева — про плохой СССР. Сериал про советскую модель с непростой судьбой от Первого канала. Спойлер: от серии к серии жизнь главной героини становится все невыносимее, причем воспринимается все очень органично. Эту историю было морально тяжело смотреть. Без КГБшников тут не обошлось. Увы, хэппи энда не случилось. Кажется ,что такое лучше не показывать на федеральном канале. Правда, жена сказала, что она с бабушкой по ТВ в детстве только такие сериалы и смотрела .

Чтобы разбавить это историческое трио, я обратился к дуэту про Папу Римского. Тем более хотелось посмотреть что-то более жизнеутверждающее. Молодой Папа и Новый Папа — хорошо показывают, что такое церковь и какой она должна? быть. Мне оказался по душе этот микс сарказма, эпатажа и философских размышлений. Джуд Лоу в роли Пия XIII стал украшением этой работы. Даже захотелось взять себе на вооружение несколько цитат на будущее.

Как видите, каникулы прошли не так уж плохо: мой диванный режим был по-настоящему насыщенным. Сегодня, в первый рабочий день, я чувствовал себя отдохнувшим. Возможно именно потому, что мои грандиозные планы сорвались.

Кажется, что после предновогоднего поста можно было бы списать Java со счетов: уж больно сложно на нем писать асинхронный неблокирующий код. Встроенный CompletableFeature имеет существенные архитектурные ограничения в виде невозможности отмены асинхронной таски, а Reactor/WebFlux сложны, да и реактивность не всем нужна.

Для интереса на github выполнил два поисковых запроса: "Flux<" language:Java вернул 158k результатов, а "Mono<List" language:Java — 19k. Ни на что не намекаю 😃

Грусть, печаль и тоска. Так Java уже все или еще нет? Мы же совсем недавно заикались о Project Loom здесь. Идея проекта в том, что JVM научили переключать поток на выполнение чего-то полезного, если он заблокирован, например, IO.

Крупные ребята, вроде Netflix, уже вовсю тестируют силу виртуальных потоков, и огребают, но не по собственной вине, о чем рассказывали у себя блоге. В чем была причина? Если кратко, то виртуальные потоки пока плохо дружат с synchronized методами и блоками, что может приводить к deadlock'ам. В марте в 24-ый релиз Java должны завезти фикс. Если он все же не станет LTS, то придется ждать до сентября, если роадмап не поменяют. Так что пока нужно быть осторожнее, тем более в проде.

Как виртуальные потоки выглядят в коде?

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
  var user = executor.submit(() -> userRepository.find(userId));
  var projects = executor.submit(() -> projectRepository.find(userId));
  return new Profile(user.get(), projects.get());
}

Вполне симпатично, почти как в Kotlin:

val Dispatchers.LoomDispatcher: CoroutineDispatcher
    get() = Executors.newVirtualThreadPerTaskExecutor().asCoroutineDispatcher()

...

suspend fun getProfile(userId: String): Profile = withContext(LoomDispatcher) {
    val userDeferred = async { userRepository.find(userId) }
    val projectsDeferred = async { projectRepository.find(userId) }

    Profile(userDeferred.await(), projectsDeferred.await())
}

Даже Structured Concurrency выглядит сносно, хотя scope.join() выглядит криво:

try (var scope = new StructuredTaskScope<>()) {
  var user = scope.fork(() -> userRepository.find(userId));
  var repositories = scope.fork(() -> projectRepository.find(userId));
  scope.join();
  return new Profile(user.get(), repositories.get());
  }
}

В общем не все так плохо. Project Loom — сильная фича, которая почти не потребует роста экспертизы разработчиков, но значительно повысит пропускную способность уже написанных проектов. Kotlin тоже выиграл, так как корутины дружат с виртуальными потоками. Так что с Go мы еще поборемся 🔫

Может я сильно придираюсь? Позвольте мне наехать на процесс восстановления пароля на сайте pochta.ru 🤣

На волне различного рода утечек на всех ресурсах, где это было возможно, я подключил двухфакторную аутентификацию (two-factor authentication, 2FA). Обычно в качестве второго фактора в дополнение к паролю используются sms- или email-коды. Эти факторы могут не сработать, если ваша почта недостаточно защищена или вы потеряете/оставите без внимания смартфон, на котором:
1️⃣не будет установлен пин-код на сим-карте (злоумышленник просто вставит ее в свой смартфон и начнет получать смски). Как его установить?
2️⃣ не настроена блокировка экрана (с паролем/FaceID и т.п.)
3️⃣ не защищены паролем приложения почты и смс-сообщений и уведомления от них

Но на этом настоящие тревожные пирожочки не останавливаются.

На волне мошеннических действий с SMS-кодами я перевел, где это было возможно, 2FA на one-time password (OTP) для лучшей защиты своих аккаунтов.

Почему это актуально? Во-первых, есть такая угроза, как SIM Swapping или SIM-jacking (замена SIM-карты через сотрудника вашего оператора). Во-вторых, я не видел ещё ни одной новости, где жертва передала OTP-код: если с смсками глаз у многих уже замылился, то к OTP пользователи относятся более внимательно.

Конечно, такие меры защиты наиболее актуальны для аккаунтов банков, Госуслуг и других государственных структур. Так вот, если вы начнёте процедуру смены пароля на сайте Почты России, то второй фактор будет выключен (о чем вам сообщит соответствующее письмо выше). Останется только один фактор в виде кода из смс. Выглядит несекурненько.

Какие варианты решения проблемы я вижу?
* использовать email как второй фактор
* использовать заранее выданные проверочные коды (такие, например, Github выдает, когда вы 2FA подключаете)
* использовать для проверки авторизацию через Госуслуги

Надеюсь, что Почта все же залатает эту брешь в нашей с вами безопасности 🎹