Бэкенд

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

Привет, на связи Виктор Степанов, лид одной из core-команд ИИ-платформы для работы с кодом GitVerse. Сегодня я хочу поделиться коротким рассказом о том, как мы начали проектировать и разрабатывать публичный API для нашей платформы.

В Ruby‑разработке ActiveRecord давно стал стандартом: он интуитивно понятен, встроен в Rails и позволяет быстро проводить CRUD‑операции. По мере роста проекта его «удобство» нередко начинает оборачиваться скрытыми проблемами.

Когда-то давным-давно (то есть до C++20) мы форматировали вывод либо по-старинке через printf, либо используя громоздкие стримы ввода-вывода из <iostream>. Оба подхода, мягко говоря, не очень. printf работал шустро и лаконично, но требовал строгого соответствия типов, забудешь правильный %d или %s в формате, и получишь неопределённое поведение вплоть до падения программы. Компиляторы иногда предупреждают о несоответствиях, но полностью проблему не решают (особенно если форматируемая строка не литерал). Кроме того, printf не умеет выводить пользовательские классы, только примитивы.

Сейчас ситуация изменилась. В C++20 завезли библиотеку <format>, современный подход к форматированию строк, сочетающий лаконичность printf с безопасностью iostream. Инструмент называется std::format и объявлен в заголовке <format>. По сути, это адаптация популярной библиотеки fmt.

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

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

Привет, Хабр! Меня зовут Андрей Саранчин, и я разработчик СУБД Tarantool в VK Tech. Вот уже полтора года мы строим MemCS — новый колоночный движок Tarantool для HTAP. И вот парадокс: даже с индексами иногда не уйти от сплошного прохода таблицы. Поделюсь, почему мы не смогли миновать Sequential Scan и как мы смягчили эту проблему с помощью Data Skipping.

Эта статья написана по мотивам доклада для Saint HighLoad++ и отражает одну из проблем, которую мы затрагивали в этом докладе.

Надвигается очередной конец очередного года, в связи с чем люди неравнодушные к своей работе — наверняка собираются принимать участие в состязаниях «Advent of Code» в своих стеках. За последние несколько месяцев существенно ожесточились споры на предмет вайбкодинга (даже термин ублюдский придумали). Мне пришла в голову тривиальная мысль: а что, если вовлечь в соревнование ваших любимых стажё^W искусственных помощников?

Я лично собираюсь решать AoC по старинке, но при этом оставляю право AI посостязаться со мной в этом соревновании и даже обойти меня в нем. В комментариях к этому тексту я предлагаю публиковать решения, выполненные лично вами, или вашими раба^W помощниками, на всех возможных языках программирования. В англоязычном интернете — полно форумов, на которых люди делятся решениями и обсуждают их; хабр (ну, как минимум тот, про который мы иногда вспоминаем в кондитерском смысле) — идеальное место для подобных обсуждений на русском языке.

Привет, Хабр! Уверен, у вас тоже такое бывало: сидишь в проде, сервис падает, а нужного ответа нет ни в Confluence, ни в старых чатах. В итоге бесконечный скролл в «телеге», повторы вопросов в почте и потерянные часы на поиски того, что кто-то уже когда-то решал. Мы уперлись в эту проблему лбом и поняли, что нам нужен инструмент, который аккумулирует знания и делает доступными. 

Меня зовут Денис Селков, я техлид разработки внутреннего Q&A‑портал МТС DevTools Stack. С помощью этого продукта мы упорядочили накопление знаний, и в этом материале я покажу, что дает такая относительно простая механика и как ее можно прокачать с помощью ИИ-инструментов. 

По мере роста компании поток обращений распределяется по разным каналам — почте, мессенджерам, формам на сайте — и быстро превращается в хаос. Мы начали искать HelpDesk, который можно развернуть у себя, без внешних сервисов и ограничений по лицензии.

Подходящих проектов оказалось немного: часть давно не обновляется, часть сложна в установке, а многие используют лицензии, которые затрудняют коммерческое применение. Анализ десятков репозиториев показал, что современных permissive-лицензированных HelpDesk-платформ почти нет.

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

Боль: Аренда GPU-сервера стоит дорого ($300–$1000/мес), а простаивает он 90% времени. Serverless GPU решения часто имеют ограничения по времени выполнения или окружению, в которые видеорендеринг не влезает.

Решение: Самописная оркестрация "Одноразовых Воркеров" (Disposable Workers). Основной бекенд (Node.js) через API облака поднимает VPS с GPU только на момент рендера задачи и уничтожает его сразу после завершения.

Стек: Node.js (Orchestrator & Worker main process), Redis (State Machine), Python (Worker components), DigitalOcean API, FFmpeg, LLM провайдеры.

Экономика: Расходы снизились с $1100/мес (постоянный сервер) до ~$130/мес (оплата поминутно только за время рендера).

Никак не могу оставить в прошлом, одну историю, произошедшую со мной больше 7 лет назад.

На тот момент я, еще студент последнего курса универа, только получил свою первую работу в IT... Как сейчас помню свои эмоции. Наконец-то, спустя годы подготовок и отказов, вот, наконец получаешь свойпервый «настоящий» проект. Осмотревшись по сторонам, понимаю, что кругом меня не то что других джунов нет, но даже мидлов. Сплошные синьоры и лиды, как тогда казалось — грозные дядьки, с большим опытом... Ну ничего, сейчас я им покажу, что такое «молодая гвардия» 😂.

Получаю компьютер, креды для доступа, мне подробнее рассказывают про проект, присылают ссылки на минимальный набор сервисов, что нужно будет локально поднять для работы и отправляют настраивать окружение. В первый же день я сломал заботливо предустановленную мне убунту 😂 (удалил «не ту» версию питона, которая, как выяснилась, очень нужна), ну да ладно, мелочи, с кем не бывает?

Установил минт, начал настраивать IDE, окружение, забрал себе нужные сервисы, вроде все хорошо, НО в одном из сервисов стабильно падает один и тот же тест. Запускаю отдельно — все хорошо и стабильно. Запускаю через сборщик (mvn test) — падение. Пытаюсь разобраться, что происходит — ничего не понятно. Тест падает из‑за мока, которого вообще нет в этом тестовом сценарии. Больше того, смущает ситуация, что ни на ci, ни у кого из коллег такого не происходит. Тест стабилен, да и в нем не меняли ничего уже довольно давно. Вывод: проблема на моей стороне и разбираться мне с ней самому.

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

Короче, давайте с источниками и мемчиками пройдемся по теме ревью и пулл-реквестов.

Если вы пользуетесь Гугл календарём, то стандартное напоминание выглядит как «ДР у Петра» и очень хорошо что Гугл теперь отображает и саму дату рождения — ещё несколько лет назад этого не было. Приходилось гадать — сколько лет‑то человеку?

Хотя задача упрощается и дата рождения уже перед глазами, а контакт можно открыть одним кликом, но всё равно приходится считать в уме — это круглая дата или нет?

В 2025 году с отображением даты рождения стало гораздо проще, но проблема стара как сам Google Calendar. В 2019 году я уже писал о попытках решить её разными способами: через громоздкие скрипты и старые методы Calendar API в 2022 году. Но многое из того давно сломалось, а Calendar API устарело.

Поэтому сейчас решил сделать через People API аккуратную автоматизацию, которая будет показывать в календаре не только «ДР у Ивана», но и сколько ему исполняется.

В последнее время часто всплывает опенсорс-тул для создания приложений - Spec Kit. Его авторы утверждают, что инструмент «помогает сосредоточиться на сценариях использования и предсказуемых результатах, а не на вайб-кодинге с нуля». 50 тысяч звёзд на GitHub звучит убедительно и ложится в концепцию Context Engineering от Андрея Карпаты. Это еще описывается как Spec-Driven Development (SDD) подход (неужели я где-то это уже слышал?) - создание серьезной документации перед тем как начинать оголтело вайбкодить разработку. Мы (ТГ канал для разработчиков использующих AI) решили разобраться, что это за зверь Spec Kit, и сравнить его с нашим текущим подходом.

Всем привет!

Многопоточность в Java не стоит на месте, а многие до сих пор используют только synchronized и создают потоки через new Thread(). С этого дня я запускаю серию уроков по современной многопоточности: как её правильно строить, в чём преимущества новых подходов по сравнению со старыми и что из классики всё ещё стоит использовать. Постараюсь объяснять максимально просто и наглядно, чтобы уроки были полезны и стажёрам, которые только начинают разбираться в теме, и опытным разработчикам, которым интересно узнать современный стиль работы с потоками.

Поехали!

Команда Spring АйО подготовила перевод статьи Джеффа Атвуда о том, почему попытки «спроектировать всё заранее» только мешают реальной разработке. Атвуд утверждает: без живого прототипа любые архитектурные решения превращаются в гадание на диаграммах. Хотите делать осознанный дизайн — поднимайте зад с кресла и пишите код.

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

Cегодня поговорим о, наверное, самом серьезном этапе собеседования — live‑coding. На этом этапе вас просят писать код в реальном времени, под пристальным взглядом интервьюера.

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

Представьте консультанта в DNS/Ситилинке, который не навязывает «вот этот блок питания потому что остался на складе», а спокойно объясняет, чем один БП лучше другого под ваш билд, помнит, о чём вы спрашивали раньше и ещё просит вежливый фидбек.

В статье рассказываю, как собрал такого консультанта в виде Telegram‑бота «Кремний» — RAG‑бота по железу на бесплатных инструментах (Telegram Bot API, Groq с Llama 3.1 8B, sentence‑transformers) и что за «чуть‑чуть боли» произошло с NumPy и Pterodactyl при деплое.

KRepo: Никаких имплементаций или инъекций. Под капотом — динамический прокси, кэширование метаданных и независимость от фреймворков: плагины под Exposed, JDBC или MongoDB реализуются отдельно.

В этом семестре мы проходим в Висконсинском университете курс «Введение в алгоритмы» (577), где нам рассказывают о способах доказательства корректности программ, динамическом программировании, сетевом потоке и обстоятельствах, при которых Дейкстра изобрёл свой алгоритм поиска кратчайшего пути.

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

Чтобы доказать, что ты присутствовал на лекции, нужно указывать в TopHat четырёхзначный код (сообщаемый лектором). Достаточно ввести код на странице студента в TopHat, после чего он считается посетившим лекцию.

Однако, наверно, разработчики поняли, что у системы есть уязвимость, которую невозможно пропатчить — друзья. Если они учатся на том же курсе, что и ты, то лёжа в кроватке, можно отправлять им сообщения со слёзными просьбами поделиться кодом.

Поэтому для лекторов-параноиков TopHat реализовала фичу «надёжной проверки посещаемости», которая, согласно описанию, определяет местоположение «по геолокации устройства и близости к аудитории и другим студентам».

Всем привет. Ранее яуже публиковал статьи (раз и два), где рассказывал о проблемах IDEA Maven плагина, основная из которых — это импорт проектов. И о своем решении Easy Maven, как получить информацию о проекте с помощью нативного Maven плагина. Теперь я бы хотел поговорить о запуске и отладке проектов в IDEA. С ними на самом деле похожая проблема. Чтобы это все работало, нужно импортировать в IDEA все настройки компилятора из билд файлов, чтобы среда разработки могла сама компилировать и запускать проект. Но это не так то просто — постоянно появляются новые параметры и возможности компиляторов, также для каждого из JVM языка (Java, Kotlin, Groovy, Scala и так далее) есть свой компилятор со своими особенностями, annotation processors — которые надо дополнительно распознавать и загружать как jar‑файлы с их транзитивными зависимостями и импортировать в IDEA. Постоянно нужно за всем этим следить и нам опять приходить играть в догонялки. Только мы всегда находимся на шаг позади в роли отстающих и нужно тратить много ресурсов, чтобы заставить запускаться проект корректно из IDEA. Поэтому я решил и тут пойти другим путем — а зачем нам вообще все это делать и переносить настройки в IDEA, если мы можно просто выполнить Maven таск для соответствующего плагина — запуск теста или приложения? Поэтому я хотел бы остановиться на этом поподробнее и рассказать о своем решении.