Георгий Клюковкин из DINS сравнит стандарты разработки API и расскажет, как выбрать подходящий для вашего проекта. Иван Белозор из КРОК покажет несколько инструментов, которые стоит использовать при разработке JavaFX-приложений на Kotlin. Участие бесплатное, но нужно зарегистрироваться.
Подробная программа и информация о спикерах — под катом.
В наш век распределенных микросервисов постоянно возникают распределенные проблемы. Это самые обычные computer science проблемы, но они распределены по разным серверам или даже разным датацентрам. Для их решения часто выдумывают много разного. Не делайте так, просто возьмите ZooKeeper. Он, несмотря на то что придуман бумерами, просто работает. Он решит немалую часть ваших проблем с распределенными системами.
Всем приветы. В прошлом посте https://habr.com/en/post/565020/ мы сравнили gRPC и REST. И собственно, прежде чем писать новый сервер на gRPC, давайте попробуем понять нужен ли он нам действительно. Нашей команде была необходима кодогенерация на разные языки программирования. На эту роль не плохо подходил Swagger, Thrift и gRPC со встроенным кодогенератором. От Thrift, спустя какое-то время, пришлось отказаться, из-за его особенностей и сложностей поддержи на c# (по-моему это была основная причина отказа). Дальше был выбор между Swagger + REST и gRPC. В целом оба варианта хороши, но если мы думаем гонять много и часто данные между клиентом и сервером, то почему бы не протестировать gRPC?
Структура проекта будет выглядеть следующим образом.
Вы, наверное, знаете, с любых доходов нужно платить налоги, в т.ч. с доходов от торговли ценными бумагами и производными инструментами (проще говоря, от игры на бирже). Очень удобно, когда брокер делает расчеты за вас, перед тем как вы выведите деньги со счета, выполняя функции налогового агента.
Но если брокер такой как у меня - Interactive Brokers (организация, третьего дня запрещенная на территории РФ), декларацию вам придется делать и подавать самому. Делать это всем, конечно же лень, и неплохо бы отдать подготовку на аутсорс...
Всем привет. Сегодня я хотел бы поговорить о многопоточности. Вернее, не о многопоточности вообще, а о таком её механизме как ForkJoinPool. Нельзя сказать, что данная технология является новой (она появилась ещё в Java 7), или что в сети нельзя найти материалы по данной теме. Информации хватает. Например, для глубокого погружения могу порекомендовать лекцию блистательного Алексея Шипилёва, которую можно без труда найти на YouTube. Но лично мне большинство этих материалов показались либо слишком сложными, либо наоборот – поверхностными. Так же некоторые из них содержат явные ошибки, что вносит ещё большую неразбериху в данную тему. Судя по тому, что в комментариях под одной из этих статей я нашёл вот такую картинку, подобные проблемы были не только у меня.
Модуль WebFlux появился в 5й версии фреймворка Spring. Этот микрофреймворк является альтернативой Spring MVC и отражает собой реактивный подход для написания веб-сервисов. В основе WebFlux лежит библиотека Project Reactor, позволяющая легко запрограммировать неблокирующие (асинхронные) потоки (streams), работающие с вводом/выводом данных.
Следует учесть, что WebFlux для работы требуется встроенный в Spring сервер Netty. Со встроенными Tomcat и Jetty настроить реактивность сложнее и они, как минимум, должны поддерживать Servlet 3.1. Следующая диаграмма иллюстрирует особенности окружения, в котором работает WebFlux [1].
Существует множество способов реализации REST-API. Большой популярностью пользуется Spring MVC на основе блокирующих вызовов, но все чаще попадаются проекты, использующие WebFlux на неблокирующих вызовах. В этой статье разберемся, какой из этих двух фреймворков работает лучше.
Вместо тысячи слов... Хотели бы вы обрабатывать json в терминале таким образом?
Эта серия заметок служит введением в разработку реактивных веб-приложений с использованием Spring Boot, Project Reactor, WebFlux и R2DBC. Это руководство по реактивному миру для новичков, но предполагается, что читатель уже знаком с Java и Spring Boot.
В первой части представлен обзор различных концепций реактивного программирования и их истории. Вторая часть представляет собой введение в Project Reactor с большим количеством коротких примеров кода. В третьей части рассматривается WebFlux - реактивный веб-фреймворк Spring. И, наконец, четвертая часть посвящена R2DBC - Reactive Relational Database Connectivity.
Это четвертая часть серии заметок о реактивном программировании, в которой будет представлено введение в R2DBC и описано, как мы можем использовать Spring Data R2DBC для создания полностью реактивного приложения.
Это третья часть серии заметок о реактивном программировании, в которой будет представлено введение в WebFlux - реактивной веб-фреймворк Spring.
Это вторая часть серии заметок о реактивном программировании, в которой представлен обзор Project Reactor, реактивной библиотеки, основанной на спецификации Reactive Streams.
Это первая часть серии заметок о реактивном программировании, в которой представлен обзор различных концепций реактивного программирования и их истории.
Сложные системы логируют большой объем информации. Хорошо продуманные и детализированные записи могут помочь в поиске и устранении серьёзных проблем. У большинства систем нет ограничений, какое логирование использовать ― синхронное или асинхронное. И всё же многие высокопроизводительные системы обычно предпочитают использовать асинхронное логирование без мусора (garbage-free), чтобы избежать задержек при сборке мусора (GC events) и операциях ввода-вывода (IO operations). В этой статье мы заглянем под капот библиотек логирования Java Log4j и Gflog и посмотрим, чем они отличаются с точки зрения управления памятью. Мы узнаем, как они реализованы, чтобы максимально сократить создание короткоживущих объектов.
Всем привет! Меня зовут Варвара и я Java Developer в компании “Цифровые привычки”. Я прошла их курс по Java-разработке и по окончании получила оффер от компании. Сейчас я хочу поделиться материалом с одного из воркшопов, который нам проводил один из лекторов - Алексей Романов, Software Architect и преподаватель Бауманки.
В этой статье мы научимся создавать простые REST приложения. Напишем свое приложение с использованием SpringBoot, создадим свои контроллеры, воспользуемся JPA, подключим PostgreSQL.
Мы будем разрабатывать приложение в 3 этапа.
Lombok — это отличный инструмент, с которым Java-код становится чище и лаконичнее. Однако есть несколько нюансов, которые надо учитывать при его использовании с JPA. В этой статье мы выясним, как неправильное применение Lombok может повлиять на производительность приложений или даже привести к ошибкам. Разберемся, как этого избежать не теряя преимуществ Lombok.
Гитхаб экшены, как я познавал ci/cd
Всем Алоха. Все слышали про ci/cd, про то что он должен быть в каждой компании и то что он упрощает нам жизнь. У всех свой ci/cd.
Кто-то предпочитает Jenkins. Особенно если у вас куча микросервисов, команд и процессов, то при помощи Дженкинса можно достаточно гибко настроить ci/cd в компании. Кто-то использует GitLab actions и для каждого репозитория настраивает свои пайплайны и процессы. Достаточно удобно и просто настраиваемый механизм сборки и доставки артефактов на стенды. Не чуть не хуже GitHub actions. Это было открытием для меня что в GitHub появился такой функционал, о котором мы поговорим позже. Ну и конечно всеми «любимый» скриптовый ci/cd. Пачка скриптов, которые нужно выполнить в определенной последовательности чтобы собрать и задеплоить артефакты. Есть ещё так сказать хэнд мэнуал ci/cd. Но это особый вид извращения, с которым не пожелаю столкнуться никому. В котором нужно собрать артефакты у себя на машине и по какому нить ридми выполнять команды в терминале, лазить по ssh смотреть, что все копировалось, перезапускать сервисы и другие развлечения.
Передо мной стояла задача спроектировать и написать новый сервер для проекта. Изначально я закидывал джарники на сервак руками, чтобы проверить работоспособность и настроить сервер. Хэнд мэнуал деплой. В какой то момент меня это начало бесить и я задумался об автоматизации этого процесса. Как вы понимаете девопса или того кто шарит в этом у меня под рукой в компании не оказалось. Очень круто, если у вас есть такой человек. У меня был выбор сделать скрипт деплой, чего я искренне не хотел, потому что в целом не любитель копаться в терминале и скриптах, когда этого можно избежать. Поднять дженкинс и настроить там джобы и пайплайны. Вариант оч классный для большой компании, а мне нужен деплой лишь одного сервера, а не тысячи микросервисов. Да и чего таить, знаний как настраивать дженкинс с нуля у меня было чуть меньше чем ноль.
Создайте архетип из существующего проекта и сгенерируйте новые клоны с минимальными усилиями. Прекратите копи-паст проектов и создайте архетип!
Если вы создаете облако микросервисов или находитесь в среде, где вам нужно сгенерировать несколько проектов или модулей maven, очень полезно создавать архетипы для разработки этих новых модулей/проектов.
Некоторые ошибки трудно воспроизвести на вашем персональном компьютере, но их легко воспроизвести на производственных или тестовых машинах. Это обычная ситуация, с которой часто сталкиваются профессиональные Java-разработчики. Для отладки таких проблем OpenJDK предоставляет два инструмента: remote debugging и jdb. Эта статья посвящена jdb.
Для приложений Java типичными производственными и тестовыми машинами являются серверы Linux без графического интерфейса, поэтому доступны только инструменты командной строки. И мы не можем использовать профессиональные IDE, такие как IntelliJ IDEA, Eclipse или Apache NetBeans IDE.
В таких сценариях мы можем использовать jdb. jdb - это отладчик командной строки, входящий в состав OpenJDK.
Это перевод руководства для начинающих. Очевидно эксперты все это знают и им не стоит тратит время на его чтение...
