Java *

В предыдущей статье мы поговорили о том, что такое graphQL, почему решили на него переходить, какие у него есть достоинства и недостатки. Но что делать дальше, если вы всё-таки решились внедрить graphQL в java-проект? Какие на данный момент есть фреймворки, чем они отличаются и какой вообще выбрать? Именно с этими проблемами мы и столкнулись почти год назад и не нашли адекватного ответа в одном источнике. Собрав по крупицам инфу из разных ресурсов (статьи, документации, доклады) и потыкав палочкой несколько фреймворков, мы сформировали общую базу знаний о них, которой и захотелось поделиться.

Если вам интересно, какие есть современные graphql-фреймворки на java, как выбрать подходящий и посмотреть, как он может выглядеть в продакшне — эта статья для вас.

Всем привет! Меня зовут Артем, я бэкенд-разработчик в hh.ru. Сегодня мы поговорим о современных решениях в GraphQL-мире на Java.

Статья также доступна в видео-формате.

Как на практике реализовать все принципы и упростить разработку тестирования BDD ?

Примером будет интеграционное тестирование, но вам ничего не помешает реализовать для End2End

Что делать, если накануне переезда повысилась тревожность, а привычные методы не приносят успокоения?

Конечно же вырабатывать дофамин через решение упоротых инженерных задач!

Мне стало интересно - насколько тяжко было бы сделать свой интерпретатор байт-кода Java? И насколько сложно было бы научить его “новым трюкам”?

Писать я буду на Rust, поэтому и проект, не мудрствуя лукаво, назвал Rjava.

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

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

Привет, хабр! Сегодняшняя статья навеяна довольно стандартной ситуацией – существует некий «большой» объект, но для работы приложения далеко не всегда требуется загружать его полностью в память. Для решения такой проблемы существует ленивая загрузка полей. Суть её состоит в том, что загрузка поля объекта откладывается до того момента, как оно [поле] понадобится.

В продуктовой Java-разработке часто требуется сохранять дату и время в базу данных. Это может быть фиксация времени создания\последней модификации какого-либо объекта или указание срока действия документа, билета и т.п. Сама по себе эта задача несложная. Трудности возникают, когда мы хотим подобную систему протестировать и оценить, как она будет вести себя, скажем, через полгода или год. В будущем. Ниже я покажу несколько простых и изящных приёмов, которые позволят вам почувствовать себя настоящим доктором Стрэнджем…

Всем привет! Меня зовут Алексей, я занимаюсь автоматизацией тестирования на Java/Kotlin в Tele2. Уже около полутора лет принимаю участие в найме новых сотрудников в роли технического интервьюера.

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

Как написать программу, чтобы победить на конкурсе плохого кода? Этот вопрос я задал сам себе, когда прочёл о необычном челлендже на форуме reddit. Да, вы правильно поняли. Это статья не о чистом коде и правильных тестах. Но здесь не будет и речи о плохом, заурядно плохом коде, том коде, который мы очень часто видим в наших проектах. Я расскажу об экстремальном, невообразимом, гениально плохом коде, коде, который использует те возможности джавы, о которых вы, скорее всего, и не догадывались, и те приёмы, которые вы никогда не встретите в обычных проектах. Сможете ли вы использовать эти приёмы на практике? Думаю, нет. Если вы прагматичный человек, то сэкономите своё время и остановитесь. Не читайте эту статью. Однако если вы хотите немного отвлечься от повседневной рутины, увидеть и узнать что-то новое о нашем любимом языке Java, - милости просим!

Всем привет. Как вы все знаете после определенных событий у нас случился ресурсный кризис. И появился запрос на оптимизацию потребляемых ресурсов.

Темой и станет оптимизация потребления ресурсов микросервисов и уменьшение времени выполнения наших запросов.

В этой статье рассмотрим, как реализовать аутентификацию с помощью централизованного сервера авторизации (Authorization Server) и API-шлюза (API Gateway).

Описывается, как можно инициировать автообновление клиентов Spring Cloud Config Server без использования Spirng Cloud Bus или какой-либо иной вспомогательной технологии в качестве посредника

Несмотря на то, что мы уже успели достаточно подробно рассмотреть целых шесть сборщиков мусора (Serial, Parallel, CMS, G1, ZGC, Epsilon), у OpenJDK еще есть, что нам предложить. Эта статья посвящена Shenandoah, тому самому сборщику, "который смог" (с таким слоганом он обычно подается).

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

TestContainers это отличный инструмент, позволяющий тестировать свой код в prod-like окружении.

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

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

Достигнем этого при помощи кастомизации тестового контекста + всеми любимого BeanFactoryBostProcessor'а.

Сборщики мусора из OpenJDK, которые мы успели рассмотреть к этому моменту (Serial и Parallel, CMS и G1, ZGC), были нацелены на как можно более быструю и эффективную сборку мусора, для чего использовали техники различной степени сложности и изобретательности. Это вполне ожидаемо, ведь исходя из названия, борьба с мусором — это их основная обязанность.

Но сегодня у нас на рассмотрении сборщик, который выбивается из общей картины. Его разбор будет недолгим, но полезным, так как позволит взглянуть на один не рассматривавшийся до этого аспект работы сборщиков. Давайте немного отдохнем от сложных технических трюков и разберемся с Epsilon GC — самым простым из входящих в состав OpenJDK сборщиков.

Добрый день! Меня зовут Александр Леонов, я руководитель группы разработки одной из распределённых команд Usetech. Сегодня я хочу рассказать вам о том, как написать карманный тест производительности на неблокирующий код Webflux. Статья рассчитана на разработчиков, которые разрабатывают API или выполняют оптимизационный рефакторинг медленного кода. Итак, начнём.

Привет, хабр! Применение switch-case в коде - давняя тема холиваров на форумах на предмет чистоты кода. Лично я склоняюсь к простому мнению: инструмент необходимо использовать по назначению.

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

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

Если каждый в сети знает k других людей, то можно упрощенно предположить, что, начав от этого человека и совершив n переходов от узла к узлу, мы найдем kⁿ человек. Учитывая экспоненциальный рост, потребуется совсем немного времени, чтобы построить путь от любого конкретного человека до любого другого в графе.

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

В главе 20 книги Networks Crowds and Markets ее авторы Дэвид Изли и Джон Клейнберг дают теоретический аппарат, описывающий, как в реальном мире могут возникать феномены, укладывающиеся в граф «мир тесен». В этой теории сочетается идея гомофилии, согласно которой схожие люди кучкуются вместе, и идея слабых связей, где отношения ветвятся в масштабах всей сети. Объяснение основано на работе Дункана Уоттса и Стива Строгаца. Давайте проследим эти примеры при помощи кода, написанного при помощи Neo4j.