Бэкенд

Данные не ломаются сами по себе — их ломают люди. Уборщица шваброй, приложение, написанное «на отвали», админ в пятничной прострации. Причины разные — результат один: файлов нет, виноватого тоже.

Чтобы не восстанавливать инфраструктуру с нуля по скриншотам из Notion, в АЭРОДИСК ENGINE есть файловая репликация. Это не бэкап, это реальное дублирование файлов между хранилищами, которое спасает, когда кто-то опять «просто немного пофиксил в проде».

Без костылей, без CLI-гимнастики, без надежды на авось. Настроили — и пусть хоть полсервера ляжет, данные у вас уже есть в другом месте.

Разбираемся, как оно устроено, чтобы потом не было «ой, не знал».

Уже как три года я работаю над проектом со стеком Kotlin, Spring Boot, Maven. Все начиналось как небольшая учебная практика в вузе на коленке за пару недель и разрослось в приличную систему, которая уже использовалась по всей России.

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

Под катом – анимация, демонстрирующая сборку приложения для macOS в режиме реального времени:

Я расскажу, как она получилась, но для начала обрисую контекст этого проекта.

Компиляция конкретного софта может быть очень длительной просто потому, что в этой программе очень много кода — как, например, в проекте LLVM. Но бывает и так, что сборка идёт медленно по глупым и вполне устранимым причинам. Подозреваю, что большинство сборок просто тормозят из-за ерунды, но проверить это мне пока не удавалось. Поэтому я разработал кроссплатформенный инструмент для визуализации сборок (пока он существует в приватной бета-версии, ссылка в конце статьи). Он работает с любой системой сборки и с любым языком программирования (а не только C/C++/Rust).

Неважно почему, но иногда может появиться желание заняться рефакторингом ваших скриптов liquibase. В моём случае постоянно возникали конфликты в общем файле журнала изменений, количество скриптов превратилось в ужасно длинный список, а в самих скриптах невозможно было ориентироваться, поскольку они содержали по 1–2 команды, а в названии файла были только дата и действие. Долго это терпел, долго взвешивал плюсы и минусы, и всё время боролся с желанием всё отрефачить. И в какой-то момент дошёл до точки, когда желание взяло верх.

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

15 августа 2025 года Telegram выпустил обновление Bot API 9.2. Если прошлые версии (9.0 и 9.1) в основном усиливали возможности ботов в работе с платным контентом, подарками и чек-листами, то 9.2 делает шаг в сторону более тесной интеграции ботов с каналами и их экосистемой.

В этом релизе добавили поддержку прямых сообщений в каналах, инструменты работы с рекомендуемыми постами, расширили систему чек-листов и доработали механику подарков. Давай разберём, что это значит для разработчиков и администраторов сообществ.

По разным оценкам, до 10% уязвимостей в коде на C и C++ являются следствием использования неинициализированной памяти (источники: 1, 2). Задача MemorySanitizer (далее, MSAN) - выявлять использование неинициализированной памяти в коде, то есть мусора, например в блоке кода типа if (uninit_var) {...}. Кроме уязвимостей, неинициализированная память даёт о себе знать при портировании приложения на другую платформу, смене компилятора (или поднятии версии используемого), изменении уровня оптимизации или изменении кода таким образом, что то, что раньше "случайно" инициализировалось нулями, стало инициализироваться мусором.

MSAN не является статическим анализатором, то есть для его работы требуется выполнение кода (нужны тесты/fuzzing/реальная нагрузка). Прежде чем переходить к самому MSAN, сначала разберемся почему недостаточно (или достаточно?) статического анализа, ведь даже компиляторы умеют предупреждать об использовании неинициализированных данных.

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

Библиотека функций к Script-fu

В предыдущей статье мы рассмотрели имеющиеся в GIMP возможности векторной графики. Здесь мы рассмотрим как эти возможности использовать при построении графических примитивов — Фигур. Для построения абстракций фигур мы уже написали несколько классов: Фигуры рисуемых по контуру Кистью и Карандашом, Фигур заполняемых определённым цветом, Комбинированных Фигур, Фигур использующих Изображения и Фигур использующих Текст. Здесь я продемонстрирую, как легко и непринуждённо мы можем встроить новые абстракции в существующую иерархию классов. А заодно рассмотрим как вся эта иерархия классов может использоваться в языке функциональной геометрии, рассмотренном в предыдущем цикле статей.

Вероятно, вам уже попадались подобные руководства по CUDA: хрестоматийный пример «Hello World», в котором перемешан код для ЦП и графического процессора. Всё это сложено в один гетерогенный файл с исходниками на CUDA C++, а для запуска ядра применяется синтаксис NVCC с тройными угловыми скобками <<<>>>, который уже стал культовым:

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

Чтобы больше не попадать в такую ловушку, а также, чтобы вы тоже в нее не попадали, я исследовал почти все вакансии Go-разработчика, которые представлены в России на данный момент и посчитал, какие навыки спрашивают чаще всего. В данной статье я учитывал только технические навыки, а не "знание английского" или "понимание agile".

Я собрал ядро для Telegram‑ботов и описал архитектуру, которая держится на YAML‑сценариях и очереди в БД. Почему отказался от брокера, как экономлю апдейты в базе, как работает «разблокировщик» цепочек и что это даёт в предсказуемости. Показываю решения и компромиссы без «магии».

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

Микросервисы обещают решение. Гибкость. Масштабируемость. Независимые команды. Быстрые релизы. Звучит идеально. Но дорога к этой цели усеяна ловушками. Я видел проекты, которые провалились, потратив миллионы. Они просто поменяли один большой клубок проблем на десятки маленьких.

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

Идея этой статьи пришла ко мне год назад. При посещении Highload я был у стенда одной большой компании, которая очень любит алгоритмы. На нем предлагалась решить архитектурную задачу за мерч. Когда дошла очередь до меня, мне выпала задача — построить онлайн редактор с нуля. Это отличный вариант! Как раз такое мне уже приходилось проектировать. В процессе решения, автор задачи сказал, что я усложняю и вообще онлайн редктор — это гораздо проще. После разбора нескольких корнер кейсов, он согласился, что это всего лишь первый взгляд. Далее уже достаточно долго мы обсуждали а как вообще можно построить онлайн редактор. В тот момент и появилась идея поделиться своим опытом публично, но вот только сейчас дошли руки. Итак, приступим.

Привет! Меня зовут Игнат. В этой статье я расскажу про разработку адаптера для работы с EGTS-протоколом (Era Glonass Telematics Standard), который можно использовать для передачии телеметрии курьеров из курьерских служб в РНИС (РНИС - государственная информационная система «Единая региональная навигационно-информационная система города Москвы»). Код написан на Kotlin и подходит для использования в Java и Kotlin приложениях. Простота подключения модуля привела к идее вынести проект в опенсорс, чтобы его могли использовать курьерские службы с бэкендом на jvm. Поехали!

Надоела бесконечная реклама на сайтах-загрузчиках? Хочется простой и быстрый инструмент для скачивания видео с YouTube? Решение есть — написать его самому!

Ястолкнулся с такой проблемой: логика между доменами сложнее самих доменов

Если строить систему по DDD: домены, агрегаты, use cases, события - всё красиво.

Потом пришёл сценарий: «Отменить заказ»

Я думал: `Order::cancel()`, вызову `inventory.release()`, `pricing.refund()`, и готово». Но...

• Если доставка уже в пути - нужно создать возвратную накладную

• Если платёж падал дважды - отменить всё, а при первой попытке только заморозить баллы

• Если товара нет - перенести резерв на другой склад, пересчитать доставку, спросить клиента, если дороже

• Если клиент повторил платёж - восстановить резерв и доставку

И я решил:

Самая сложная логика тут не в доменах, а между ними.

А в книжках по DDD, Clean Architecture, Hexagonal об этом не пишут.

Это напомнило проблему в ООП, когда каждый объект отвечает только за свою корректность (инвариант), а логическую зависимость при взаимодействии должен обеспечить ещё один класс "чистая выдумка". Также, у ФП есть более простые и явные способы.

Я напишу на Rust, потому что этот язык удобнее управляет бизнес правилами.

Привет! Я Рома, бэкендер-питонист в KTS.

Это вторая статья в моем цикле об алгоритме архивации bzip2. Первую можно прочитать здесь, но для понимания сегодняшней темы она необязательна. Ниже я разберу преобразование Барроуза-Уилера — ключевой этап сжатия bzip2.

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

Go ценят за предсказуемость и простые решения в стандартной библиотеке, а в сервисах чаще всего упираемся в IP, разбор host:port, CIDR и сериализацию. Сегодня это удобно закрывается стандартным net/netip: компактные value-типы, корректный парсинг адресов и портов, работа с зонами, проверка принадлежности сетям и быстрые операции без лишних аллокаций. В статье рассмотрим этот пакет подробнее.

В первой части мы разобрали, как устроен Keycloak, какие у него сущности и зачем вообще нужен SSO в DevOps-инфраструктуре. Теперь — к делу. Во второй части переходим от теории к практике. Разворачиваем Keycloak в Kubernetes, настраиваем Terraform-провайдер, подключаем к нему Grafana, Argo CD и другие сервисы. Разбираемся, как выглядят реальные конфигурации клиентов, scopes и mappings, чтобы SSO действительно работал — с нужными токенами, ролями и группами.

Я 10 лет был клиентом AWS и контрибьютором проектов с открытым исходным кодом, а они удалили мой аккаунт и все данные без какого‑либо предупреждения. Ниже — история о том, как «верификация» у AWS превратилась в цифровую казнь и почему нельзя доверять облачным провайдерам, если у вас нет копий данных вне облака.

На 23 июля 2025 года AWS удалил мой аккаунт, которому было 10 лет, и каждый байт данных, который я там хранил. Без предупреждения. Без льготного периода. Без возможности восстановления. Произошла полная цифровая аннигиляция.

Ниже я расскажу историю о катастрофической внутренней ошибке в AWS MENA, 20 днях кошмарного общения с поддержкой, в ходе которого я так и не получил прямого ответа на вопрос «Мои данные ещё существуют?», и о том, что всё это показывает в отношении доверия облачным провайдерам.