Бэкенд

Привет, Хабр.

Немного контекста, потому что я уже успел наступить на грабли: написал технический пост, получил пару «вежливых» комментариев, пару очень невежливых, и карма улетела туда, где зимой холодно.

Нюанс какой: я зашёл «с места в карьер», как будто все уже знают, кто я, откуда и почему я так пишу и так думаю. А по факту — нет, конечно. Поэтому этот пост — «паспорт»: кто я, откуда выросла идея, почему я вообще полез в код, почему у меня агенты, почему «завод», и что я могу обсуждать с инженерами предметно (а что — не могу и не буду, потому что там секреты/безопасность/коммерческое ядро).

Сразу честно: я не классический инженер. Я могу где‑то не знать «ритуальную формулировку» термина или перепутать модное слово. Но я фанат причинности: если система говорит «работает» — она должна уметь это доказать. Всё остальное — разговоры.

RAG на PHP - звучит непривычно. Делюсь опытом построения чат-бота для поиска по внутренней базе документов: Symfony, Qdrant с гибридным поиском, YandexGPT для embedding и генерации ответов. Внутри — готовый код, подводные камни чанкинга и советы, которые сэкономят вам время.

Эта статья не про инструменты и не про то, «как использовать ИИ». Она про то, почему автоматизация и AI могут снижать качество инженерных решений — даже в зрелых командах. И про то, почему большинство систем ломаются не из‑за багов, а из‑за решений, которые никогда не выглядели ошибками.

Продолжаем прорабатывать методы шардирования. В прошлой статье было предложено простое, но крайне трудозатратное решение по реализации динамического шардирования (когда ассоциация ключа и шарда лежат в отдельном сервисе, а не вычисляется при помощи функции). В этой статье предлагается универсальное решение, которое позволяет гибко настраивать параметры шардирования и при этом не быть перегруженной возможностями, из-за которых производительность неуклонно снизится.

Records, pattern matching и sealed-типы сделали Java куда более «функциональной» — читать вложенные данные стало легко и красиво. Но как только вам нужно изменить что-то глубоко внутри неизменяемой структуры, начинается боль: каскад пересоздания records, копирование полей, десятки строк ради одного изменения.

В новом переводе от команды Spring АйО рассмотрим, почему у современной Java всё ещё есть пробел в истории неизменяемости — и как оптики закрывают его. Если pattern matching — это про элегантное чтение, то оптики дают то, чего так не хватает, — композиционную запись: определили путь один раз и дальше меняете вложенные поля одной строкой, без ручной реконструкции и без циклов.

Проблема: никто не знает, кто кого вызывает

В 2012 году биржевой брокер Knight Capital потерял $460 миллионов за 45 минут.
Причина — активация устаревшего модуля, который начал массово размещать ордера.
Отчёт SEC указал на ключевую ошибку:

У меня была привычка. Вижу классную статью про архитектуру —-сохраняю. Репозиторий с примерами DDD - в закладки. Видео про CQRS - в плейлист «Посмотреть потом».

Вы знаете, чем кончаются плейлисты «Посмотреть потом».

В какой-то момент закладок стало 300+. Половина ссылок битые, треть дублируют друг друга, остальное - статьи, которые казались гениальными в два часа ночи. Я сел и вычистил всё до 106 ресурсов. Собрал их в awesome-list на GitHub.

Но статья не про список. Статья про три вещи, которые я для себя открыл в процессе и которые почему-то мало обсуждают.

Когда у вас 50+ узлов Tarantool в кластере, ручное управление соединениями превращается в боль. Узлы падают, реплики становятся мастерами, новые инстансы добавляются — и все это нужно отслеживать в реальном времени. 

Рассказываем, как мы спроектировали go-discovery — библиотеку для автоматического обнаружения узлов кластера Tarantool 3.0.

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

В этой статье я расскажу, как устроен централизованный, надёжный и удобный способ асинхронного взаимодействия сервисов внутри Wildberries. Я Виктор Такташов, Golang-разработчик в команде Trust & Safety. С задачами Highload знаком не понаслышке, потому что когда-то занимался сервером популярной онлайн-игры. К тому же я больше шести лет занимался борьбой, так что с проблемами расправляюсь умело и хладнокровно :-)

Почему мы решили сделать Databus

Несколько месяцев назад я поймал себя на мысли: я плачу за Cursor, плачу за Claude Pro, использую квоты, завишу от серверов в другой стране — и при этом сам инструмент закрытый, его нельзя ни изменить под себя, ни развернуть локально. А что, если сделать свой?

Идея казалась амбициозной. Но у меня уже были под рукой Google AI Studio с его бесплатным тарифом, Claude Chat как умный ревьюер кода, и желание разобраться — насколько далеко можно зайти, не написав самому ни строчки кода.

Спойлер: очень далеко.

Всем привет! Меня зовут Паша Агалецкий, я техлид команды платформы разработки Авито. В этой статье я расскажу о самых интересных и полезных фичах релиза новой версии Go — 1.26. Статья будет полезна всем, кто работает с Go и следит за развитием языка. 

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

Примеры на Ruby, Go, Java.

Анализируем структуру файлового формата parquet и читаем метаданные через thrift и python: индексы, страницы и их типы, кодировки (encodings). Статья является хорошим дополнением и иллюстрацией к документации формата parquet. С помощью кода из репозитория любой желающий сможет самостоятельно проанализировать метаданные файла в формате parquet на самом низком уровне.

Писать или не писать тесты — выбор очевидный. Конечно, писать. Но если проект масштабный, одних unit‑тестов будет недостаточно: они бессильны на границах модулей, в интеграциях и пользовательских сценариях, а значит в этих местах будут пролезать баги. Такой код будет сложно поддерживать, вносить в него изменения и получать ожидаемый результат.

В статье поговорим про разные стратегии тестирования под разные риски и кейсы. Поднимемся над привычными unit‑тестами и заглянем, что там есть еще. Спойлер: а еще там workflow‑, integration‑, property‑based‑ и resilience‑тесты.

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

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

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

Привет! Сегодня рассмотрим инструмент, который поможет вам с низкоуровневым кодом на Rust. Если вы пишете на Rust только безопасный код, возможно, никогда о нём не слышали.

А вот тем, кто периодически заглядывает в тёмные уголки unsafe, этот инструмент сэкономит нервишки.

Как масштабироваться, если новых нод не подвезут? Представьте, что вы управляете огромным высоконагруженным проектом, но находитесь не в облаке, а в on-premise. Никаких «запросить ещё одну ноду», никаких облачных щедрот — только то, что стоит в вашем серверном зале, и бюджет, который уже освоен. В таких условиях масштабироваться — всё равно что играть в «Тетрис» на харде: ресурсы ограничены, фигуры падают быстро и места всё меньше.

В этой статье мы — Илья Семёнов @ilc6 и Алексей Игнатов @AViIgnatov из Сбера, — расскажем, как мы построили собственный автоскейлер, который не запрашивает новые ресурсы, а перераспределяет существующие. Обойдёмся без магии облака, только логика, метрики и симуляция — и да, на DevOps Conf это вызвало оживлённые дискуссии.

Наша экспертиза — от разработки до архитектуры, в том числе высоконагруженных бэкендов, интеграционных, архитектурных и платформенных решений. Эта статья написана по мотивам доклада на DevOps Conf. Расскажем про наш собственный автоскейлер, который применяем к on-premise с инсталляцией, и какие решения для этого придумали.

Итак, поехали!

Привет, Хабр! (И тебе, питонист, который считает свой язык идеальным, и тебе, JS-ник, у которого уже вышел новый фреймворк, пока ты читал это предложение, и тебе, 1С-ник, который устал объяснять, что ты тоже программист всем во круг.)

Наткнувшись миллионный раз на статью «КАКОЙ ЯЗЫК ПРОГРАММИРОВАНИЯ ВЫБРАТЬ?» я задался вопросом, почему люди ещё не поняли ответа на этот вопрос, ведь он на поверхности.

Не рекомендуется для прочтения опытных разрабов считающих свей язык программирования самым лучшим.

Я Go-разработчик из крупной Bigtech-компании и один из основателей ИИ-помощника по налаживанию отношений Ближе. По сути это телеграм-бот, который принимает вопрос от пользователя по long-polling модели, обогащает его промтом, идёт в LLM, получает ответ, отправляет обратно пользователю. Контекст диалога и пользователи хранятся в Postgres, всего один инстанс приложения на Go, также cron, который отправляет уведомления с просьбой оставить обратную связь о продукте. Docker Compose для запуска нескольких контейнеров.

Также в моей команде есть product-manager, который отвечает за развитие продукта. Ему необходимо быстро тестировать гипотезы, понимать эффективность каналов продвижения, считать вовлечённость, удержание пользователей и желательно делать это всё с минимальными тратами.

Что происходит, когда вы вводите ls в терминале? Как 2 буквы превращаются в список файлов на экране? Я решил разобраться и написал свой терминал с нуля на C++.

В этой статье я объясняю через метафору ресторана, как работают три магических системных вызова — fork(), exec() и wait() — которые лежат в основе любого терминала. Вы узнаете, почему cd нельзя сделать обычной программой, как работает перенаправление >, и какой коварный баг я поймал из-за непонимания процессов. Без сложной теории — только практика и понятные объяснения.