Хочешь сделать что-то полезное и рабочее — сделай его так, чтобы другие люди могли этим полноценно пользоваться, нормально это ревьювить, да и вообще вспоминать тебя добрым словом, а не темной стороной своего словарного запаса.
Для этого, кроме того, чтобы просто хорошо делать свою работу, писать правильный код, не бояться использовать современные технологии и в целом не тупить, надо обязательно обращать внимание на две штуки — документация и API. Без них человеку будет трудно понять, с чем вообще он имеет дело, как оно всё работает и что лучше не трогать вообще никогда. Конечно, можно гуглить, что обозначает та или иная спецификация, можно проверять в бою, чего и как (а потом так же бодро откатываться на предыдущую рабочую версию), но лучше, когда человеку дали подробную документацию.
Так вот, о чем я сегодня. В этом посте я расскажу, почему мы в RBK.money используем Swagger, как он помогает нам в работе и какие у него есть косяки.
Глубокое погружение в мир аннотации Spring Boot @Conditional с проработанными примерами реализаций классов доступа к БД Mongo и MySQL.
В моем посте «Почему Spring Boot?» было рассмотрено создание Spring Boot приложения, из которого вы едва ли сможете понять, что происходит за кулисами. Возможно, вы хотите понять магию автоконфигурации Spring Boot.
Перед этим вы должны узнать о Spring аннотации @Conditional, от которой зависит вся магия автоконфигурации Spring Boot.
Привет, Хабр.
В этой статье я хочу рассказать о своем опыте создания учебной среды для экспериментов с микросервисами. При изучении каждого нового инструмента мне всегда хотелось его попробовать не только на локальной машине, но и в более реалистичных условиях. Поэтому я решил создать упрощенное микросервисное приложение, которое впоследствии можно будет "обвешивать" всякими интересными технологиями. Основное требование к проекту — его максимальная функциональная приближенность к реальной системе.
Изначально я разбил создание проекта на несколько шагов:
Создать два сервиса — 'бекенд' (backend) и 'шлюз' (gateway), упаковать их в docker-образы и настроить их совместную работу
Ключевые слова: Java 11, Spring Boot, Docker, image optimization
Разработка Kubernetes конфигурации и деплой системы в Google Kubernetes Engine
Ключевые слова: Kubernetes, GKE, resource management, autoscaling, secrets
Создание чарта с помощью Helm 3 для более эффективного управления кластером
Ключевые слова: Helm 3, chart deployment
Настройка Jenkins и пайплайна для автоматической доставки кода в кластер
Ключевые слова: Jenkins configuration, plugins, separate configs repository
Каждому шагу я планирую посвятить отдельную статью.
Направленность этого цикла статей заключается не в том, как написать микросервисы, а как заставить их работать в единой системе.
Недавно наткнулся на подборку полезных Eclipse плагинов и решил поделиться этим здесь. Предыдущий перевод в моем профиле зашел, надеюсь, и этот пост придется полезным. Кому интересно — добро пожаловать под кат.
Мы сделали 2 подсистемы внутри Apache Ignite.
В статье расскажу про их архитектуру:
Продолжаем рассказ про API, которые появились в новых версиях Java.
Files.mismatch()На практике довольно часто возникает необходимость проверить, являются ли два файла в точности одинаковыми или нет. С помощью метода Files.mismatch(), появившегося в Java 12, это наконец-то можно сделать. Этот метод возвращает позицию первого несовпадающего байта в двух файлах или -1, если файлы идентичны.
Это может быть полезно, например, когда синхронизируешь содержимое двух директорий. Чтобы не перезаписывать файл при копировании тем же самым содержимым и лишний раз не нагружать диск, можно сначала проверить, идентичны файлы или нет:
public static void syncDirs(Path srcDir, Path dstDir)
throws IOException {
// Для простоты демонстрации считаем, что поддиректорий нет
try (Stream<Path> stream = Files.list(srcDir)) {
for (Path src : stream.collect(toList())) {
Path dst = dstDir.resolve(src.getFileName());
if (!Files.exists(dst)) {
System.out.println("Copying file " + dst);
Files.copy(src, dst);
} else if (Files.mismatch(src, dst) >= 0) {
System.out.println("Overwriting file " + dst);
Files.copy(src, dst, StandardCopyOption.REPLACE_EXISTING);
}
}
}
}
Вопросы авторизации и аутентификации и в целом аспектов защиты информации все чаще возникают в процессе разработки приложений, и каждый с разной степенью фанатизма подходит к решению данных вопросов. С учетом того, что последние несколько лет сферой моей деятельности является разработка ПО в финансовом секторе, в частности, систем расчета рисков, я не мог пройти мимо этого, особенно учитывая соответствующее образование. Поэтому в рамках данной статьи решил осветить эту тему и рассказать, с чем мне пришлось столкнуться в процессе настройки наших приложений.
"Avalanche — application framework for Java" — реализация технологии стирающей различия
между вызовами локального и удаленного кода. Отказоустойчивость, масштабируемость,
модифицируемость, непрерывная доступность идут в комплекте приятными бонусами.
В статье описан пример реализации универсального REST сервиса. В основу идеи реализации сервиса положено утверждение, что FrontEnd в каждый момент времени "знает", какими данными он манипулирует и что собирается запросить у BackEnd-а. Это утверждение позволило отказаться от разработки ORM в BackEnd-е и использования JPA при реализации универсального сервиса. Сервис способен манипулировать содержимым любой таблицы БД. Изменения структуры или созданные объекты БД сразу становятся доступны методам сервиса.
В сервисе реализованы методы трех групп:
В сервисе реализована система ошибок, которая однозначно позволяет понять причину и место возникновении ошибки. По умолчанию, поддерживается локализация сообщений ru и en. Не все сообщения могут быть локализованы, например сообщения ошибок выполнения SQL запросов, которые зависят от локализации среды выполнения.
Сервис поддерживает работу с данными в форматах XML и JSON.
Сервис реализован с использованием библиотеки Jersey 2.0.
Одной из проблем Java является ее многословность и объем необходимого стандартного кода. Это общеизвестно.
Давайте рассмотрим простой класс Cat на Java. Мы хотим, чтобы каждый объект Cat имел следующие атрибуты (поля):
Привет, Хабр.
Недавно я поделился опытом о том, какие параметры мы в команде чаще всего используем для Kafka Producer и Consumer, чтобы приблизиться к гарантированной доставке. В этой статье хочу рассказать, как мы организовали повторную обработку события, полученного из Kafka, в результате временной недоступности внешней системы.
Современные приложения работают в очень сложной среде. Бизнес-логика, обернутая в современный технологический стек, работающая в Docker-образе, который управляется оркестратором вроде Kubernetes или OpenShift, и коммуницирующая с другими приложениями или enterprise-решениями через цепочку физических и виртуальных маршрутизаторов. В таком окружении всегда что-то может сломаться, поэтому повторная обработка событий в случае недоступности одной из внешних систем — важная часть наших бизнес-процессов.
Привет! В этом посте мы расскажем о том, как провели первый в истории RBK.money CTF (capture the flag). Механика соревнования была примерно такой же, как и на привычных вам CTF, а вот результаты немного удивили. Впрочем, возможно, мы просто перестарались с задачами.
В рамках CTF нужно было в составе команды или, если чувствовал, что справишься сам, единолично получить определенный флаг, заботливо спрятанный нашими ребятами в коде. Чтобы его получить, надо было либо взломать участвующие в CTF сервисы, либо написать программу, либо просто найти в нашем коде уязвимость и не замедлить ею воспользоваться.
Участвовали примерно 100 команд, в некоторых из которых было по 5-7 человек, а в других — по одному. Особенностью CTF стали две вещи. Первая — отчасти соревнование было посвящено Erlang. Штука не самая популярная, да. Вторая — несколько задач решить не осилил никто из участников, одно из заданий было очень типично для Erlang, ещё одно — на извлечение информации из аудиофайла. То ли люди перестали увлекаться стеганографией, то ли мы немного переборщили.
В общем, было всё. Реверс-инжиниринг, фишинг участников со стороны самих участников, слишком сложные задачи и попытки помешать остальным найти флаги. Под катом — подробности и сами задания, если решите попытать силы.
Для большинства людей факторинг – услуга непонятная. По факту — это финансирование поставок компаний, работающих с отсрочкой платежа.
Предположим, вы небольшой производитель круп. Вы отгрузили товар в торговую сеть, но деньги получите в среднем через 60 дней после отгрузки. Многим компаниям ждать столько не под силу: ту же зарплату сотрудникам нужно платить уже сейчас. Одно из решений — факторинг. После заключения договора факторинга вы можете получить финансирование любой поставки. Достаточно после отгрузки товара отправить фактору подтверждающие документы (счета-фактуры, накладные, акты). Фактор верифицирует поставку у вашего покупателя и перечисляет вам деньги за товар, за вычетом собственной комиссии.
В сделке участвуют покупатель, поставщик и фактор, которые подписывают множество бумаг, уведомлений. Раньше взаимодействие с клиентом собиралось как паззл из разных кусочков: например, подписание договоров происходило при помощи сторонних операторов электронного документооборота, верификация поставок — пересылкой по e-mail excel-файлов, а в личном кабинете на сайте фактора поставщик мог посмотреть лишь статистику по сделкам. Было неудобно, трудоемко – и нам, и клиенту. Надо было собрать всё это в одну систему.