• свой железный сервер с Ubuntu;
• множество docker-контейнеров с Ubuntu внутри;
• Java Virtual Machine внутри docker-контейнеров.

Статья об использовании реактивного доступа к базам данных из корутин. Spring все упрощает, но это плохо сказывается на понимании реальных процессов работы приложения. Для демонстрации был выбран фреймворк KTor (просто потому, что мне нравится смотреть на то, что делает JetBrains), который интенсивно использует корутины — чтобы задача сочетания Reactive Streams и этих самых корутин добавила интереса. В процессе работы пришло понимание, что происходящее — явный пример преобразования непонятного многим реактивного потока в понятное императивное программирование, на котором мы собаку съели. Я люблю реактивные цепочки, но почему бы не порадовать тех, кто любит армейский порядок?

Реактивные приложения завоевали сердца и посадили нервы многих разработчиков, причем эти множества заметно пересекаются. Посадили бы еще больше, если бы не усилия сообществ, адаптирующих чистый поток разума от создателей спецификаций в удобоваримые библиотеки. Так произошло со спецификацией R2DBC и фреймворком Spring (Boot) — разработчику виден уже привычный Spring Data API с уже привычными реактивными типами данных. Однако есть причины не использовать Spring: не хочется Spring и хочется чего-то нового. Ну, есть еще унаследованный код, но в этом случае вряд ли придется столкнуться с реактивным доступом к данным.

В этом случае придется посмотреть на R2DBC без прикрас. И он будет ожидаемо сильно отличаться от того, что нам предлагают в готовом фреймворке — так же, как JDBC отличается от Spring Data JPA. Плюс реактивность. И реактивность по спецификации Reactive Streams. А у нас на слуху корутины. Которые вроде как будущее и все равно под них переписывать.

Вступление

Название поста действительно «холиварное», но на мой взгляд и у Java, и у популярной библиотеки Guava есть ряд архитектурных проблем, которые в перспективе приводят к двусмысленностям и разногласиям в команде.

Предлагаю ознакомиться с расшифровкой доклада 2017 года Павла Сенина "Selenoid — сотни параллельных UI-тестов легко и быстро".

Виктор Васнецов, Рыцарь на распутье; fatcatart.com

Привет, Хабр! Здесь краткий пересказ интересной баги c GitHub. Для воспроизведения см. проект spring-flux-callstack.

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

at reactor.core.publisher.FluxSwitchIfEmpty$SwitchIfEmptySubscriber.onComplete(FluxSwitchIfEmpty.java:75)
at reactor.core.publisher.FluxSwitchIfEmpty$SwitchIfEmptySubscriber.onComplete(FluxSwitchIfEmpty.java:78)
at reactor.core.publisher.Operators.complete(Operators.java:135)
at reactor.core.publisher.MonoEmpty.subscribe(MonoEmpty.java:45)
at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:52)
at reactor.core.publisher.Mono.subscribe(Mono.java:4110)

Как вы уже поняли, это методы из Project Reactor, который обеспечивает асинхронную работу для Router Function в WebFlux.

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

Привет!

Если вы читали наши предыдущие посты (читали же?), то точно помните, что мы в RBK.money очень сильно за опенсорс. Настолько, что выложили в открытый доступ наш антифрод в виде открытых исходников под лицензией Apache 2.0.

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

Зачем мы это сделали? Как это работает внутри? Как теперь жить дальше? Читайте под катом. Я гарантирую, что такого вы еще не встречали — еще никто в мире не опенсорсил платежную систему такого уровня.

История меняется прямо сейчас на ваших глазах!

Как говорилось в одном анекдоте, «Салат Фибоначчи готовится из того, что осталось от вчерашнего и позавчерашнего салата Фибоначчи». Вот и сейчас попробуем на практике применить перехват системных вызовов через seccomp для целей ускорения минимизации исходника при сохранении инварианта. До кучи, проблема будет решаться посредством инжектирования форк-сервера, очень похожего на тот, который используется в American Fuzzy Lop. И всё это будет управляться из Java-кода.

Для тех, кто уже настроился почитать про модификацию чужих процессов через ptrace прямо из Java — нет, всё не настолько сурово, я просто на ходу собираю .so из .c и вгружаю через LD_PRELOAD.

Для тех же, кто уже подумал «Знаю я этот AFL — компилятор придётся патчить и пересобирать!», скажу, что в том и смысл использования seccomp: мы на ходу поймаем момент, когда произойдёт первое обращение ко входному файлу.

Есть конечно и ложка дёгтя: компилятор должен быть однопоточным, однопроцессным и на Линуксе, но в реально-тестовой задаче минимизации примера бага в компиляторе из OpenModelica удалось добиться ускорения раз в 5.

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

Этот перевод продолжает серию об IntelliJ IDEA:

• Лучшие плагины IntelliJ IDEA
• Сравнение файлов и папок
• Анализ зависимостей
• Настройка стиля кода для каждой папки
• Синхронизация и обмен настройками

В этой статье будут рассмотрены четыре декомпилятора — Fernflower, CFR, Procyon и jadx — и произведено их сравнение по нескольким параметрам.

Дисклеймер: сравнение неформальное и не претендует на научность. Скорее, это просто обзор всех актуальных (на осень 2019) декомпиляторов Java-байткода.

Автор — Анна Явейн (brontozyablik), разработчица Solar appScreener

От переводчика: несмотря на несколько рекламный характер этой статьи, автор приводит довольно-таки интересную статистику по текущему состоянию экосистемы Java. Надеемся, что эта статистика окажется полезной читателям

Версия этой статьи также ранее была опубликована в The New Stack.

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

Но это не значит, что нельзя попробовать примерно оценить состояние этой сферы.

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

Этот перевод продолжает серию об IntelliJ IDEA:

• Лучшие плагины IntelliJ IDEA
• Сравнение файлов и папок
• Анализ зависимостей
• Настройка стиля кода для каждой папки

Здесь опишу пример сериализции данных через Avro и передача в Kafka. Для Avro есть сериализатор данных для Kafka, он использует в своей работе реестр (registry) схем и поддерживает версионность на отдельном развернутом сервере. Здесь будет только сериализатор, а версионность если потребуется, то например может быть реализована своя, например в БД.

Как анализировать зависимости в IDEA с помощью Dependency Structure Matrix и других инструментов.

Этот перевод продолжает серию об IntelliJ IDEA:

• Лучшие плагины IntelliJ IDEA
• Сравнение файлов и папок
• Анализ зависимостей

// Для использования String.repeat нужен JDK 11 и выше:
final var needle = "A".repeat(500000) + "B";
final var haystack = "A".repeat(1000000) + "B";
System.out.println(haystack.indexOf(needle));

Это начало серии из нескольких статей, любезно предоставленных их автором, Linas Medžiūnas, и изначально опубликованых в блоге WiX Engineering.

Относительные локаторы

• above(): искомый элемент находится над указанным элементом
• below(): искомый элемент находится ниже указанного элемента
• toLeftOf(): искомый элемент находится слева от указанного элемента
• toRightOf(): искомый элемент находится справа от указанного элемента
• near(): искомый элемент находится на расстоянии не более 50 пикселей от указанного элемента. Существует также перегруженный метод, позволяющий указать расстояние.