Заканчиваю прохождение практикума по k8s. Давно хотел закрыть этот гештальт. Тем более, что на работе появляется все больше соответствующих задач как в уже имеющихся, так и в новых кластерах, которые только предстоит поднять.

На прошлых выходных завершил работу над финальным заданием / проектом. Нужно было подготовить helm chart'ы для разворачивания окружения (NFS provisioner, EFK, Prometheus-стек, cert-manager, nginx-ingress-controller) и настроить Gitlab CI/CD для приложения с базой данных. Оставалось только защитить проект перед ментором на очной встрече.

Но в дело вмешалась миграция платформы в Yandex Cloud 😢 Случилось то, чего я ждал, но боялся... Если кластер на старой платформе был версии 1.27, то на новой — 1.30. Сами ноды также были настроены по-другому. Если раньше мы прописывали DNS на Cloudflare, то теперь доступа к какому-либо API не осталось.

Чарты перепишем, ноды донастроим, но с DNS то что делать? Буду использовать nip.io. Это бесплатный без смс и регистрации DNS-сервис, который предоставляет wildcard DNS-записи для любого IP-адреса. Как это работает? Если создать доменное имя, заканчивающееся на .nip.io, то оно автоматически разрезолвится в указанный в имени IP-адрес.

Теперь на пальцах. Если у меня есть публичный IP-адрес 51.250.34.211, то при обращении к 51.250.34.211.nip.io, это доменное имя разрезолвится в 51.250.34.211. Поддомены также работают: grafana-51-250-34-211.nip.io и kibana.51.250.34.211.nip.io разрезолвятся в 51.250.34.211.

Очень даже удобно для учебных задач, разработки и тестирования, когда требуется доменное имя вместо IP-адреса. Можно использовать даже в локальной сети или за NAT! Главное — ничего дополнительно настраивать не надо ⌨️.

Пока, правда, не разобрался, почему Let's Encrypt сертификат не подтягивается. Думал сначала, что не прошел ограничение rate limiter'a Let's Encrypt по домену (не один же я такой умный nip.io использовать), но в логах failed to perform self check GET request, хотя конфиг по адресу /.well-known/acme-challenge/ лежит ☔️. Будем разбираться!

Этот код вбил последний гвоздь в крышку гроба изменяемого/мутабельного состояния в моем коде.

Что произошло? На ревью я увидел следующее (с точностью до нейминга):

@ConfigurationProperties
data class SomeProperties (
    val property: ImportedJavaLibClass,
    ...
)

@Service
class SomeService(
    val someProperties: SomeProperties,
) {

  fun doSomeImportantThing{
    ...
    return someProperties.property.apply { someField = calculatedValue }
  }

}

Мы изменяем состояние приложения (через состояние SomeProperties) каждый раз, когда вызывается doSomeImportantThing ⚰️. Мне кажется, что на несколько минут я потерял дар речи. Самое интересное, что это решение работает в проде и не создает проблем. Или мы о них пока просто не знаем?😃 Чудеса, да и только!

Это яркий пример того, что если API позволяет допустить ошибку, то разработчик ее совершит. Несмотря на то, что Kotlin весь такой "будем использовать val и const вместо невыразительных final и static final", "интерфейсы List, Set, Map будут отвечать за коллекции, предоставляющие read-only доступ", "будем повсеместно использовать неизменяемые data-классы вкупе с невероятно удобным copy()", к сожалению, наследие в виде развесистых Java-библиотек никуда не делось 😢.

Kotlin автоматически генерирует свойства на основе того, как они объявлены в Java: для final — val, в противном случае — var. Что тогда мешало изначально в библиотеке сделать все поля final? Да просто это реально стремно выглядит. Собственно поэтому final и не используют повсеместно.

В нашем ImportedJavaLibClass без дополнительных манипуляцией someField продолжит считаться мутабельным в Kotlin, а значит его в любой момент можно будет изменить. Признавайтесь, хватит решимости идти править библиотеку 😐?

С nullability дела обстоят гораздо лучше. Мы можем навесить аннотации @NotNull или @Nullable для полей библиотечных Java-классов. Останется только надеяться, что в других проектах мы никому при поднятии версии библиотеки не поломаем использование рефлексии. Но, должны же на это быть тесты написаны, правда 🤣 ?

Я часто страдаю от того, что при возникновении вопросов первым делом не обращаюсь к документации. Даже не знаю, что повлияло на отсутствие этой полезной привычки. Вероятно, мне просто не хочется выискивать и компилировать ответ самостоятельно. Это ж думать надо 😰 Всегда есть надежда, что на твой вопрос в 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 стал украшением этой работы. Даже захотелось взять себе на вооружение несколько цитат на будущее.

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