User
В новом переводе от команды Spring АйО, Siva Katamreddy, девелопер адвокат в AtomicJar (Testcontainers), поделился своими мыслями о популярных в наши дни TDD, Clean, Hexagonal, Onion и Ports & Adapters. Он также постарался ответить на вопрос, который, возможно, волнует не только его: "Действительно ли мы, разработчики, так любим всё усложнять?".
У каждого программиста бывает желание велосипедостроения. Это случилось и у меня. Решил зарефакторить кусочек кода в приложении на текущей работе. Было приложение, которое выполняло работу в бесконечном цикле. И в этом цикле работа выполнялась, когда приложение было активно. То, что приложение активно в данный момент определялось через группу булевых значений. То есть каждую итерацию цикла приложение проверяла все эти булевы условия. Я подумал, что не лучше ли будет проверять одно значение вместо пачки. Так родился простой велосипед небольшого хранилища булевых условий в битах целочисленного типа.
В статье все примеры взяты из головы. Все совпадения случаны
Я написала этот текст из желания помочь разработчикам, которым только предстоит познакомиться с Camunda. С чего начать и как не потеряться - подробно, с кодом и скринами.
Привет, Хабр! Меня зовут Сергей, я техлид в команде PT BlackBox. Мы с коллегами разрабатываем продукт, который позволяет обнаруживать уязвимости в приложениях методом черного ящика. Фактически мы сами и пишем веб-приложения, и именно о них пойдет речь в статье.
Я бы хотел с вами поделиться своими наработками по теме бэкенд-приложений и предоставить вам шаблон-прототип, который, как мне кажется, может закрыть подавляющее большинство потребностей при их разработке.
Для написания прототипа я буду использовать Litestar, FastStream и dishka. Эта статья будет особенно полезна тем, кто пишет на Tornado, Django, Flask или AIOHTTP и хочет перейти на более актуальные технологии для дальнейшего развития своих проектов на современных рельсах.
Впервые я услышал термин "Lakehouse" в 2019 году, когда пролистывал документ Dremio. Будучи по своей натуре консервативным человеком, я предположил, что это просто очередной маркетинговый термин. Но пять лет спустя, кажется, уже все говорят о Lakehouse (после того, как наговорятся об ИИ :d); все крупные облачные хранилища данных теперь поддерживают чтение форматов Hudi, Iceberge или Delta Lake непосредственно в хранилище объектов, и даже BigQuery имеет специальный механизм запросов для этой задачи. На этом инновации не заканчиваются: Apache XTable (ранее OneTable) предоставляет абстракции и инструменты для трансляции метаданных формата таблиц Lakehouse. Недавно компания Confluent объявила о выпуске TableFlow, которая передает данные из Apache Kafka непосредственно в озеро данных, хранилище или аналитический движок в виде таблиц Apache Iceberg.
Это заставило меня пересмотреть свои прежние предположения: так был ли Lakehouse просто маркетинговым термином?
Статья родилась, как водится, из рабочей задачи — нужно было внедрить аудит-логирование в некоторые микросервисы на Java и Spring.
Эта статья по Spring Boot 3.2 посвящена надстройке над WebClient, которая называется RestClient и представляет собой более интуитивный и современный подход взаимодействия с RESTful сервисами.
В мире Spring Boot отправка HTTP запросов к внешним сервисам является весьма распространенной задачей. Традиционно при достижении этой цели разработчики полагались на RestTemplate. Однако, по мере развития Spring Framework, на свет появился новый и более мощный способ обработки HTTP запросов: так называемый WebClient. Spring Boot 3.2 представил нам надстройку над WebClient, которая получила название RestClient.
RestClient предлагает нам более современные и интуитивно понятные способы взаимодействия с RESTful сервисами.
Микросервисы – это парадигма, где приложение разбивается на небольшие независимые компоненты, каждый из которых отвечает за конкретную функцию. Это как отделы в офисе, каждый офис – это отдельный сервис, который может быть разработан, масштабирован и развернут независимо.
Почему асинхронность так важна для наших микросервисов? Представьте себе множество людей, ожидающих в лифте – каждый из них хочет двигаться своим темпом, и никто не хочет ждать, когда лифт подойдет к нужному этажу. Так и в мире микросервисов – каждый сервис может заниматься своей задачей, не блокируя другие. Асинхронность позволяет нам этим заниматься: вместо того чтобы ждать ответа от одного сервиса, мы можем отправить запрос другому и эффективно использовать время, пока ждем ответа.
В этой статье я хотел бы рассказать об архитектурных шаблонах Transactional Outbox и Idempotent Consumer. Кроме того, я хотел бы показать собственную реализацию, содержащую интересное сочетание технологий, выходящее за рамки этих шаблонов, значительно упрощающее реализацию и эксплуатацию.
Довольно часто коллеги спрашивают меня о том, почему я решил какую-то задачу именно так, а не иначе, или почему я считаю, что какой-то другой способ в будущем приведет к огромным проблемам, а я не могу ответить на эти вопросы чётко и вразумительно - вместо этого я ограничиваюсь общими фразами. Часто бывает, что чтобы объяснить выбранный путь, нужно сначала объяснить целую Вселенную, и открывая рот, я просто не знаю, с чего начать. Раньше я думал, что эту проблему можно преодолеть - стоит только научиться излагать мысли внятно и структурированно. Но потом я осознал, что эта невозможность простого и лаконичного объяснения идёт из самого того подхода, по которому я работаю уже долгие годы - программирования в стиле дзэн.
Привет! На связи Миша Меркушин. Я тимлид команды Ruby Platform, ответственной за разработку внутренних библиотек и улучшение архитектуры микросервисов на Ruby в СберМаркете. Эта статья про архитектурный паттерн Outbox и инструмент, который мы создали и итерационно развивали внутри команды и лишь недавно «выпустили» его в мир. Он решает проблему обеспечения надежной и согласованной отправки сообщений из приложения, гарантируя, что сообщение будет отправлено после успешного завершения транзакции базы данных.
Всем нам хорошо известен ответ на вопрос, какими могут быть отношения между сущностями в Hibernate и JPA. Вариантов всего четыре
Привет, Хабр!
Асинхронное программирование уже давно является полноценной частью Java. С появлением Java 8 и введением класса CompletableFuture, асинхронное программирование стало более доступным.
CompletableFuture — это класс в пакете java.util.concurrent, предоставляющий возможности для асинхронного программирования. Он поддерживает выполнение задач в фоновом режиме, цепочки задач, обработку исключений и многое другое.
По мнению Артема Закируллина*, одна из фундаментальных проблем, с которой сталкиваются разработчики при анализе кода – высокая когнитивная нагрузка. Это не абстрактное, а реальное ограничение возможностей, которое стоит времени и денег. На чтение и понимание кода, тратится больше времени, чем на его написание. Поэтому, разработчику нужно постоянно задаваться вопросом: не пишет ли он код, чтение которого создает чрезмерную когнитивную нагрузку?
Подробнее о том, с какими проблемами от высокой когнитивной нагрузки сталкиваются разработчики и какие решения помогут упростить понимание кода для последующей работы с ним читайте под катом.
*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.
Я потратил на изучение данной библиотеки немало нервных клеток, и уверен, что узнал далеко не все способы и лайфхаки, но постарался донести информацию с практической стороны, чтобы вы с самого старта не испытывали "нежданчиков" и сэкономили свое время в попытках найти работающий способ.
В конце февраля этого года Илон Маск заявил, что первое испытание чипа Neuralink на человеке проходит успешно. Пациент чувствует себя хорошо, он уже перемещает указатель мыши силой мысли и постепенно учится делать клики. Скоро он сможет листать Хабр, не пошевелив ни единой мышцей своего тела.
