Как можно собрать актуальный стек используемых библиотек и фреймворков чтобы комфортно заниматься разработкой если вы самоизолировались в глухой деревне, летите 8 часов в самолете или в вашей компании лимитирован доступ к всемирной паутине настолько, что вы не можете пользоваться публичными репозиториями артефактов, например таким, как maven central? Как же нам предоставить все необходимые артефакты, от которых мы зависим, включая транзитивные зависимости? Как потом их обновлять вместе с новыми версиями фреймворка?

Попробуем найти ответы на эти вопросы. В данной статье я хочу рассказать о нашем новом инструменте CUBA SDK — консольной утилите, которая позволяет определять все транзитивные зависимости для Maven-библиотек и управлять ими в удаленных репозиториях. Также в статье мы рассмотрим пример, который позволит вам использовать наши наработки для любого Java приложения с применением Maven-зависимостей.

Привет, Хабр! Представляю вашему вниманию любительский перевод статьи “Rethinking the Java DTO” Стивена Уотермана, где автор рассматривает интересный и нестандартный подход к использованию DTO в Java.

---

Я провел 12 недель в рамках программы подготовки выпускников Scott Logic, работая с другими выпускниками над внутренним проектом. И был момент, который застопорил меня больше других: структура и стиль написания наших DTO. Это вызывало массу споров и обсуждений на протяжении всего проекта, но в итоге я понял, что мне нравится использовать DTO.

Данный подход не является единственно верным решением, но он довольно интересный и отлично подходит для разработки с использованием современных IDE. Надеюсь, что изначальный шок пройдет и вам он тоже понравится.

Привет, коллеги! Так получилось, что наше приложение написано на java stack, но хостится в Azure. И мы пытаемся по максимуму использовать менеджмент сервисы клауд провайдера.

Один из них это Azure Service Bus и сегодня я хочу рассказать про особенности его использовать в обычном Spring Boot приложении.

Всем привет! Карантин прошел плодотворно и решил написать игрушку тайм-киллер «Быки и коровы». Игра не такая сложная, но довольно таки интересная. Обычно в игре используется 4 числа, которые нужно отгадать. Компьютер загадывает число, пользователь вводит свои 4 числа, если цифра в числе пользователя совпадает по позиции с позицией, в загаданном числе, то это бык, ну а если стоит не на своем месте, то это корова. Более подробные правила легко найти в интернете. В этой части разберемся с BackEnd'ом, в дальнейшем добавим FrontEnd, отгадывание числа пользователя и пожалуй все. Что ж, начнем!

Первым делом я создал класс BackEnd, который будет отвечать за всю работу программы. В нем есть поля:

    private int length;             //длина массива
    private int[] mas;              //задуманное компьютером число
    private int[] inputArray;       //число, введенное пользователем

Задумка в следующем: компьютер генерирует число mas длины length, пользователь вводит число inputArray и видит сколько в нем быков и коров, после чего побеждает или продолжает играть. Для начала мы будем выводить массив mas, что бы видеть число и дебажить код. потом уберем эту строку. Напишем вывод массива произвольной длинны:

    private void printMas(int[] mas) {
        for (int i = 0; i < length; i++) {
            System.out.print(mas[i] + "   ");
        }
    } 

В данный метод мы передаем массив, который будем выводить и через цикл for. Можно было сделать через поле, но так как мы будем выводить сначала mas, а потом inputArray, то я решил сделать так.

NPM — уникальный репозиторий пакетов из мира JavaScript. В основном здесь те JS библиотеки, которые можно использовать во фронтэнде/в браузере, но есть и серверные для использования в node.js и не только. Если вы программируете на Java и у вас появилась необходимость синтегрироваться с NPM репозиторием, то скорее всего у вас один из двух следующих случаев:

• Вы пишите Web приложение на одном из Java фреймворков и определенные NPM пакеты необходимы для клиентской стороны
• У вас Java приложение (например, для Андройда), которому необходимо уметь запрашивать зависимости и сами ресурсы/пакеты из NPM

Давайте посмотрим как это можно сделать в Java.

Привет, Хабр! Представляю вашему вниманию перевод статьи «Java Lambda Expressions» автора www.programiz.com.

Введение

В этой статье, с помощью примеров, мы изучим lambda-выражения в Java, их использование с функциональными интерфейсами, параметризированными функциональными интерфейсами и Stream API.

Лямбда выражения были добавлены в Java 8. Их основная цель – повысить читабельность и уменьшить количество кода.

Но, прежде чем перейти к лямбдам, нам необходимо понимать функциональные интерфейсы.

Когда вы написали серверное приложение, его нужно где-то развернуть. У нас в компании сейчас это реализовано с помощью VPS на Linux, bash скриптов, и небольшой Java программы. Это эволюционный процесс, и как по мне, получилось весьма неплохо.

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

КДПВ — архитектура системы, для части которой автоматизируем развертывание:

Приветствую, дорогой читатель.

Редко, но все же задачки из собеседований и обучалок имеют практическую ценность. Так, мне понадобилось реализовать на Java альтернативу арифметическим операциям над целочисленными значениями. Благо, первые страницы поисковиков пестрят готовыми решениями побитовых аналогов, и над большинством из них голову ломать не пришлось.

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

28 июля приглашаем на онлайн-лекцию о разработке приложений на Java Spring, Quarkus, Vert.x и GraalVM с деплоем в MicroK8s.

В программе лекции: Сергей Кошкинов и Андрей Смирнов покажут процесс создания приложения на Java-фреймворке Quarkus с деплоем в MicroK8s. А также сравнят производительность и потребления памяти приложений на Spring WebFlux, Spring Boot, Quarkus, Quarkus+Vert.x и скомпилированными в native code с помощью GraalVM.

Зарегистрироваться

Привет, Хабровчане. Сегодня мы с вами поговорим о RxJava. Я знаю, что о ней написано материала вагон и маленькая тележка, но, как мне кажется, у меня есть пара интересных моментов, которыми стоит поделиться. Сначала расскажу, как мы используем RxJava вместе с архитектурой VIPER для Android приложений, заодно посмотрим на «классический» способ применения. После этого пробежимся по главным особенностям RxJava и остановимся подробнее на том, как устроены планировщики. Если вы уже запаслись вкусняшками, то добро пожаловать под кат.

На встрече Владимир Бухтояров из DINS сделает обзор алгоритма Token Bucket, а Дмитрий Янтер из Технологического центра Дойче Банка объяснит, зачем разработчику знать высшую математику. Оба спикера ответят на ваши вопросы.

Встречаемся 22 июля в 19:00. Участие бесплатное, но нужно зарегистрироваться.

Подробная программа и информация о спикерах — под катом.

Перевод статьи подготовлен в преддверии старта курса «Backend-разработка на Kotlin»

---

В этой статье мы поговорим о том, как создать простое приложение на Spring Boot с Kafka и Kotlin.

Привет, Хабр! Представляю вашему вниманию перевод второй части статьи «Java Memory Model» автора Jakob Jenkov. Первая часть тут.

Аппаратная архитектура памяти

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

Вот упрощенная схема аппаратной архитектуры современного компьютера:

Современный компьютер часто имеет 2 или более процессоров. Некоторые из этих процессоров также могут иметь несколько ядер. На таких компьютерах возможно одновременное выполнение нескольких потоков. Каждый процессор (прим. переводчика — тут и далее под процессором автор вероятно подразумевает ядро процессора или одноядерный процессор) способен запускать один поток в любой момент времени. Это означает, что если ваше Java-приложение является многопоточным, то внутри вашей программы может быть запущен одновременно один поток на один процессор.

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

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

Одной такой функцией является Structural Search & Replace (SSR). Она может быть невероятно полезна в тех ситуациях, когда пасует всё богатое разнообразие других функций.

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

1. 3D-движка для создания игр jMonkeyEngine, как пример большого проекта, в котором всегда можно найти что-то интересненькое.
2. моего собственного проекта plantuml-native-image, в котором я провожу эксперименты по компиляции PlantUML в нативный исполняемый код с помощью GraalVM native-image.

Собственно, случай во втором проекте и побудил меня к написанию статьи. Но обо всём по порядку...

Привет, Хабр! Представляю вашему вниманию перевод первой части статьи «Java Memory Model» автора Jakob Jenkov.

Прохожу обучение по Java и понадобилось изучить статью Java Memory Model. Перевёл её для лучшего понимания, ну а чтоб добро не пропадало решил поделиться с сообществом. Думаю, для новичков будет полезно, и если кому-то понравится, то переведу остальное.

Первоначальная Java-модель памяти была недостаточно хороша, поэтому она была пересмотрена в Java 1.5. Эта версия модели все ещё используется сегодня (Java 14+).

Заявленный в заголовке Kotlin больше ассоциируется с Android-разработкой, но почему бы не поэкспериментировать? Мы с его помощью нашли способ немного упростить автоматизацию тестирования API одного из наших сервисов, а также облегчить работу тестировщикам, мало знакомым с программированием и нюансами языка Java.

Чем мы занимаемся? Разрабатываем сервис для отправки брокерских анкет для расчёта и получения решения по ним. И несмотря на то, что это банковское решение, разработку ведёт небольшая scrum-команда, тестированием в которой занимаются 1-2 специалиста в зависимости от загрузки и ситуации на проекте.

Под катом расскажем о результатах наших экспериментов, которые мы с удовольствием перенесли в продакшн.

Если вы разрабатываете корпоративные приложения, и не только, вероятно вы уже знакомы с протоколом сериализации Protocol Buffers от Google. В данной статье поговорим о его второй версии. И о том, что он заставляет писать много boilerplate кода, с которым мы и будем бороться.

Projector — это способ запускать IntelliJ IDEA на удалённом сервере. Недавно я писал об этом статью, но умолчал о важной для любого параноика вещи — шифровании данных на вебсокете.

Генерация и подкладывание ключей — довольно муторный кусок работы. Тут придётся познакомиться с особенностями Docker и криптографии в Java. К сожалению, убежать от этого никуда нельзя, потому что это Java, и ребята из JetBrains совершенно не виноваты.

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

Обнаружил секретный репозиторий на гитхабе JetBrains под названием Projector. Благодаря нему написал кусок кода в IntelliJ IDEA, запущенной на Android-планшете. Рассказываю, как это повторить.

В одном из старых проектов в кучу были навалены ассерты из JUnit, kotlin.test и AssertJ. Это было не единственной его проблемой: его вообще писали как письмо Дяди Федора, а времени остановиться и привести к единому виду не было. И вот это время пришло.

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

Сразу оговорюсь, что в статье не будет сравнения фреймворков для тестирования, подходов к тестированию и каких-то хитрых подходов к проверке данных. Речь будет идти про несложные ассерты.