Бэкенд

Приветствую, коллега. Не так давно столкнулись с необходимостью реализовать взаимодействие с Graph Ql сервисом. Появилась задача аутентификации, настройки подключения, получения и передачи потребителям информации. В результате нашли много материалов, в которых описано, как развернуть Graph Ql сервис, как его использовать с базой данных. Например вот, и вот. Это подробные статьи, которые помогут решить сложные задачи. Но что делать, если стоит задача поменьше и хочется получить комплексное описание решения? Хочу предложить вариант, насытив его информацией, которая принесет пользу. Заказчик получит работающий сервис, разработчик необходимые знания и способ решения, который можно дополнять и улучшать для конкретных условий использования. Для погружения в Graph Ql и детали его использования есть статьи - вот, вот, вот и документация. Эта статья будет сосредоточена на задаче реализации клиента к Graph Ql серверу. Если для вас стоит подобная задача, то нам по пути.

Теория — это прекрасно, но мое "расследование" не могло закончиться на простом понимании проблемы, ведь конечная цель любого инженера — построить работающую и надежную систему. К счастью, проверенные решения существуют.

Эти решения можно разделить на две большие группы: реактивные и превентивные.

Это вторая статья в серии о поддержке DOM-подобных моделей в различных языках программирования.

Сегодня мы рассмотрим как JavaScript справляется с бенчмарком Card DOM.

При работе с C или C++ необходимо в какой-то степени разбираться в неопределённом поведении (UB): что это такое, каковы его эффекты, и как о него не споткнуться. Для простоты картины я буду в этой статье рассказывать только о C, но всё изложенное здесь также применимо и к C++, если явно не указано иное.

Привет, Хабр! Если вы работаете с Python дольше пары недель, вы наверняка сталкивались с конструкцией, начинающейся с символа @. Это декораторы — мощный инструмент, который делает код чище, читабельнее и соответствует принципу DRY (Don't Repeat Yourself). Но за элегантным синтаксисом скрывается несколько ключевых концепций языка, которые важно понимать.

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

За последние ~5 лет я много раз сталкивался с задачей собирать логи: обычно из маленьких или средних по размеру кодовой базы проектов. Отправлять логи из кода не проблема, у Java и Go для этого есть библиотеки практически из коробки. А вот разворачивать что-то для их сбора — головняк. Понятно, что решаемый (ещё до ChatGPT, а сейчас так тем более), но всё же. Все системы логов, прежде всего, ориентированы на большой-большой enterprise мир и его требования, а не на простых смертных с несколькими палками, клеем и дедлайном "вчера".

Запуск ELK для меня каждый раз испытание: куча настроек, нетривиальный деплой, а при заходе в UI разбегаются глаза от вкладок. С Loki и Graylog — немного проще, но всё равно функций сильно больше, чем мне нужно. При этом разделять логи между проектами, добавлять других пользователей в систему так, чтобы они не видели лишнего — тоже не самый очевидный процесс.

Поэтому примерно год назад я решил, что сделаю свою систему для сбора логов для себя: максимально простую в использовании и запуске. Чтобы разворачивалась на сервере одной командой, вообще без настроек и без лишних вкладок в интерфейсе. Собственно, так появился и теперь вышел в open source Log Bull: система для сбора логов для разработчиков с проектами middle-sized размера.

Каждый разработчик вынужден настраивать для себя среду разработки. Любую среду разработки можно условно разделить на две группы:

Простая - когда не требуется дополнительная конфигурация ОС, набор библиотек установленных в ОС соответствует требованиям разработки, мощности ПК разработчика полностью соответствуют решаемым задачам в процессе разработки.

Не простая - когда ваша конфигурация среды разработки не соответствует первому пункту.

Статья описывает как решить проблемы, возникающие с непростыми средами разработки, с помощью контейнеризации среды разработки.

StarRocks Lakehouse на практике: пошаговый гайд по интеграции с Apache Hive через Hive Catalog. На прикладочном сценарии «управление заказами» показываем, как построить слой ODS/DWD/DWS/ADS в озере данных и ускорить запросы без миграции данных: от создания таблиц и генерации тестовых наборов до подключения External Catalog. Разбираем включение Data Cache для ускорения чтения из HDFS/S3/OSS (Parquet/ORC/CSV) и применение асинхронных материализованных представлений в StarRocks для витрин DWD/DWS/ADS. Поясняем, как добиться быстрых запросов за счёт векторизированного движка и CBO, а также даём практические советы по настройке (Kerberos/HMS, конфигурация BE/FE, прогрев кэша, сбор статистики, MV‑rewrite). Материал будет полезен инженерам по данным и архитекторам DWH, которым нужна аналитика в реальном времени по данным озера без лишнего ETL.

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

От простейшего выделения сервиса в модуль в начале до решения проблем разрыва транзакций, SQL Join-запросов, задержек асинхронного API и непосредственно выделения нового сервиса. Использование event-driven архитектуры, редизайна модели данных и интеграционного слоя как основных подходов в процессе выделения.

Команда Spring официально представила поддержку Jackson 3 — одного из крупнейших обновлений в экосистеме JSON для JVM. Уже начиная с Spring Boot 4 и Spring Framework 7, Jackson 3 становится версией по умолчанию, а Jackson 2 помечается как deprecated. В новом переводе от команды Spring АйО поговорим про нововведения — улучшенную безопасность, переход к JsonMapper, отказ от MappingJacksonValue, поддержку новых API и настройку через builder-интерфейсы.

С распространением сценариев real-time аналитики, lakehouse & modern BI всё чаще сталкиваются две флагманские аналитические СУБД: ClickHouse и StarRocks. Одна из ключевых конкурирующих битв ведётся не на маркетинговом поле, а в производительности, гибкости архитектур и удобстве поддержки сложных аналитических схем.

ClickHouse, будучи зрелым и широко используемым решением, зарекомендовал себя как очень быстрый колонковый движок, оптимизированный для агрегаций, фильтров и чтения узкого поднабора колонок из огромных объёмов данных. ClickHouse+2Instaclustr+2 Он эффективен в задачах логов, телеметрии, веб-аналитики и других OLAP-нагрузках, где схемы часто «расстилаются» — с минимальным числом джоинов и высокой степенью денормализации. Decube+2Wikipedia+2

Однако подход ClickHouse — оптимизация работы с плоскими таблицами и минимизация связанных таблиц — становится ограничением, когда бизнес-сценарии требуют моделирования звёздной схемы (fact + dimension) и выполнения динамических запросов с join’ами. В таких случаях ClickHouse часто вынужден либо смягчать нагрузку через ETL денормализацию, либо сталкиваться с трудоёмкими запросами. CelerData+2StarRocks+2

Вот где StarRocks начинает оспаривать лидерство. Он предлагает архитектуру, ориентированную на эффективные join и агрегации “на лету”, поддерживая материализованные представления (MV), которые автоматически обслуживаются и подменяются при выполнении запросов. DZone+3StarRocks+3StarRocks+3 В бенчмарках StarRocks часто показывает преимущество: в тестах на SSB (набор из 13 запросов) StarRocks в среднем быстрее ClickHouse почти вдвое. StarRocks Docs+2CelerData+2

Вы наверняка знаете, Kubernetes просто повсюду. От разработчиков, тестировщиков, DevOps-инженеров и системных аналитиков ожидают умения работать с этим инструментом. Даже продакт-менеджеры иногда интересуются, что это такое.

Если вы только начинаете знакомство с Kubernetes и хотите понять, с чего начать, эта статья для вас. Разберем, какие задачи он решает, какие у него основные объекты и как можно управлять кластером без сложных команд в терминале. Подробнее читайте внутри.

Привет! Меня зовут Илья, я директор департамента разработки в ЮMoney. За каждым малозаметным обновлением может стоять месяц работы: проработка архитектуры, дизайна, код-ревью и множество проверок безопасности. В ЮMoney мы смогли совместить тщательный контроль с бешеной скоростью — и делаем до 100 релизов в день. Расскажу, как мелкие задачи спасают от больших рисков и что помогает нам «катиться» быстрее.

В прошлой статье мы рассказали, почему Compo Soft решила уйти от привычного PHP‑стека и перейти на Java ради выхода в сегмент Enterprise. Но если кто‑то подумал, что за этим решением последовал массовый найм Java‑разработчиков — нет. Мы пошли по куда более хардкорному пути: взяли всю свою PHP‑команду и начали переобучать ее на Java. Полностью c нуля. И без отрыва от производства.

При пиковых нагрузках отчётные и аналитические системы сталкиваются с лавиной схожих агрегирующих запросов: растёт загрузка CPU и увеличиваются задержки. В StarRocks эту проблему решает Query Cache — кэширование промежуточных результатов агрегаций в памяти с их последующим переиспользованием. В реальных сценариях даёт 3–17× ускорение, работает для семантически эквивалентных запросов, перекрывающихся партиций и append-only данных. Внутри — лучшие практики, пример настройки и метрики диагностики.

Привет! Это команда Яндекс Практикума. В первой половине года мы провели исследование рынка Python-разработки и узнали, как меняются требования работодателей и к чему стоит готовиться джуниору при трудоустройстве. Рассказываем самое важное.

Мнение после десяти лет в производственных окопах от Джастина Кормака, бывшего CTO Docker.

Несколько лет назад я провёл немало времени, отвечая на вопросы Федеральной торговой комиссии (FTC) по поводу покупки VMware компанией Broadcom. Их интересовало, можно ли считать контейнеры конкурентами виртуальных машин - они пытались разобраться в конкурентной среде вокруг VMware.

Это напомнило мне первые пять лет работы в Docker, когда все только и делали, что сравнивали контейнеры с виртуальными машинами. Контейнеры - это просто “облегчённые” виртуалки? Или это небезопасная ерунда, от которой все скоро откажутся и вернутся к старым добрым VM?

Многоагентная архитектура открывает несколько мощных паттернов. Здесь я начну с основ и опишу, как с помощью Temporal сделать создание многоагентных систем простым, надёжным и увлекательным.

Немного странно такую заметку писать, вроде что-то очень банальное и возможно многие скажут "да я с пеленок это знаю" - но вот опять сталкиваемся с тем что такая ошибка в достаточно важной ситуации наглядно портит кровь.

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

Если вы создали сокет, попытались его открыть и отвалились по таймауту - не переиспользуйте его! Для новой попытки обязательно создавайте новый сокет!

Это не вполне очевидно и в документации порой лишь вскользь упомянуто, либо не упомянуто вообще. Ниже немного подробностей с кодом, но в общем вся суть в этой фразе. Не переиспользуйте!