«Восстание машин» часть 1: continuous delivery для базовых Docker образов

А http://buildpacks.io рассматривали?

Эффективные надежные микросервисы

Если я правильно понял статью (после чтения по диагонали), то у вас используется:

• Сервисы связаны в кластер
• Шардирование
• Local queries / reads
• State replication
• Recovery через репликацию данных с других инстансов

Что делается "из коробки" (правда подозреваю менее эффективно, хотя интересно было бы сравнить) в Akka с помощью Akka Cluster + Akka Persistence и ещё пары штук возможно.

P.S. Олег, ты чего на "вы", не первый день знакомы ;)

Эффективные надежные микросервисы

Выглядит как своя реализация идей, доступных в Akka. Рассматривали её?

Как собрать образ Oracle DB для Testcontainers

С reusable containers Ryuk не будет прибивать контейнеры которые помечены как reusable, в том и смысл :)

Как собрать образ Oracle DB для Testcontainers

Начиная с Testcontainers 1.12.3, мы добавили "reusable containers", что позволяет переиспользовать контейнер между сессиями тестов при локальной разработке.

Так что теперь не обязательно использовать другой тул :)

R2DBC Arabba-RELEASE — новый взгляд на реактивное программирование для SQL

За репорт — респект!
Про "мультитредовые тесты" — надеюсь тоже репортил.

По ссылке на TechEmpower (который я кстати не очень люблю, учитывая что он был создан чтобы показать какой их фреймворк быстрый и ни раз был замечен делающим некорректные бенчмарки для других) r2dbc не нашёл.
Опять же, стоит мерять производительность реальных реактивных сервисов (JDBC + Thread Pool vs R2DBC), где каждый вызов JDBC будет идти через context switch т.к. блокировать текущий реактивный поток нельзя.

В "песочнице" R2DBC vs JDBC показывает себя неплохо (особенно с MSSQL, кстати), а так же есть куда оптимизировать. В таких вещах обычно первым идёт "сделать чтобы работало" а потом уже "чтобы быстро".

R2DBC Arabba-RELEASE — новый взгляд на реактивное программирование для SQL

А не поделитесь ссылками чтобы подтвердить своё мнение? На открытые баг репорты, бенчмарки.

А то иначе выглядит как вброс ;)

R2DBC Arabba-RELEASE — новый взгляд на реактивное программирование для SQL

Конечно, конечно… нет :D
Файберы и корутины упрощают для юзера, а реактивщина — делает чтобы быстро было!
Одно другому не мешает ;)

ИМХО файберы виртуальные потоки только улучшат adoption реактивных технологий — потому что можно будет не бояться "что-то там заблокировать", а всякие flatMap concatMap превратятся в обычный map.

Из Groovy ушёл Cédric Champeau‏

Как опытный Jenkins-овод, могу заверить:
1) "Groovy не работают в некоторых местах" — это скорее бага, чем особенность, которую они так и не смогли побороть
2) "тратить часы чтобы понять как оно вообще собирается и кто кого зовет" — так же применимо к Jenkinsfile-ам, иногда даже ситуация гораздо хуже, чем в Gradle.
3) "структуру можно полностью переопределить" — это не совсем так. В Gradle действительно можно "пачкать" variable scope, но нельзя, например, переопределить "configurations {}" блок, в итоге имеем структурированность практически как в декларативном Jenkinsfile-е
4) "stages" в Jenkinsfile только если использовать декларативный подход, он не всегда подходит, приходится использовать императивный, и там ад и содомия похлеще Gradle файлов

Из Groovy ушёл Cédric Champeau‏

зачем он весь (и Groovy вместе с ним) нужен

Так как уже есть jenkins pipeline

А ничего что Jenkinsfile это Groovy?:)

Строители против синтаксиса Java

Надо знать только этот класс, и на нём будут все методы.

И только в этом билдере в статье есть pantonymic

Не совсем. Юзер просто использует $DesiredUserType.Builder и видит все поля, которые можно "настроить" с помощью билдера.
Т.е. пользователь не ищет "а где же настроить pantonymic", он имеет тип, и видит какие параметры этого типа можно установить.

Строители против синтаксиса Java

Значительно упрощенный API благодаря этому.
Юзеру не надо знать о всех существующих билдерах, не надо знать в каком из них настаривается foo, а в каком — bar (типичная проблема композиции).

Строители против синтаксиса Java

Выделите все поля, которые должны быть во всех потомках, в отдельный дата-класс

Это уже не "наследование".

Строители против синтаксиса Java

1) дублирование объявлений полей
2) Да.

Строители против синтаксиса Java

data class RussianUser(override val firstName: String, override val lastName: String, val patronymic: String): User()

Даже ваш великий Котлин не спасает от тонны ненужного синтаксиса здесь. Особенно когда таких полей десятки.

Строители против синтаксиса Java

и никаких new

по-моему в вашем примере кол-во "new" удваивается при добавлении нового наследника ;)

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

Строители против синтаксиса Java

Тогда это уже не называется "наследование"

Строители против синтаксиса Java

Рассматривали.

С таким очень сложно работать, нет нормального способа хранить состояние (например, коллекции открытых портов, или переменных окружения), ну и не очевидный способ создания через прокси и вот это вот всё (в PR кстати чуть по-другому это решили)

Строители против синтаксиса Java

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

Строители против синтаксиса Java

class MyTag extends Tag {}

MyTag tag = new MyTag().setId("yo"); // <-- Error!

Летали. Знаем.