На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Рассказываю о проекте, в котором мы реализовали корпоративное хранилище данных (КХД) на базе DATAREON Platform для компании, занимающейся поставками дорожно-строительной техники и запчастей.
Всем привет! Я Алексей Босенко, DevOps-инженер в компании KTS. В этой статье я покажу, как комплексно настроить быструю и эффективную сборку проектов в Kubernetes с использованием BuildKit, которая учитывает не только производительность, но и стоимость ресурсов.
Под этой громкой фразой я подразумеваю целый комплекс решений: как создать и настроить экономичный кластер Kubernetes для сборок (ведь цена вопроса всегда важна), как настроить GitLab Runners и как сделать эффективное масштабирование сборок. Особый акцент будет на том, почему мы выбрали BuildKit, какие варианты использования он предлагает, и как непосредственно настроить один из них.
Будет много подробностей о том, почему мы принимали эти решения и как внедряли их у себя, так что статью можно использовать в качестве Production-ready-мануала.
Всем привет! В этой коротенькой статье я попытаюсь вам доказать, что внешние ключи (foreign keys) в СУБД — не нужны и только вредны.
Бывает, разработчик завершил задачу, выполнил все по ТЗ. Но заказчик просит все переделать. Можно сколько угодно ворчать или брать оплату за работу, которая не попала в прод. Но ситуацию это не меняет: сырые задачи будут приходить, результат будет уходить в стол.
Решение — включить продуктовое мышление: задавать неудобные вопросы и не бояться менять ТЗ. В этой статье пример Mindbox, где разработчики проявляют продуктовое мышление, — посмотрим, как и зачем это делать.
Команда проекта Valhalla выпустила early-access сборку JDK с полной реализацией JEP 401 — value-классы и объекты теперь можно попробовать в действии! В новом переводе от команды Spring АйО — примеры использования, объяснение концепции, сравнение производительности с обычными объектами и практические советы для разработчиков.
Кхм. Громковатый заголовок, но я всё объясню.
Итак, у меня был сервис. Обычная молотилка данных, каждый с такой хотя бы раз да сталкивался - что-то на входе, что-то на выходе, а внутри походы в базу, HTTP-вызовы, шаблоны, скриптовая логика... В общем, много всякого.
Ну, ладно, тут стоит сразу уточнить, что сервис с особенностями - молотилка данных устроена так, что пытается работать с разными форматами на входе и выходе, а внутри держать всё в одном представлении. Но вот из-за этой потребности работать с разным, внутреннее представление это - мапы, слайсы, мапы в слайсах, слайсы в мапах, да ещё и из всех щелей торчит куча метрик.
Поэтому вот такая картина потребления памяти меня до недавних пор особо не смущала:
Тема безопасного и эргономичного взаимодействия между Rust и C/C++ была популярна на конференции RustConf 2025, состоявшейся в Сиэтле, штат Вашингтон. Чендлер Каррут выступил с презентацией, в которой представил различные способы взаимодействия между Rust и Carbon — экспериментальным языком, который можно условно обозначить как «(C++)++». Он резюмировал, что, пусть возможности стыковки Rust с другими языками со временем расширяются, в обозримом будущем не стоит ожидать, что будет полноценно решена проблема его взаимодействия с C++. Поэтому как раз появляется ниша для Carbon, который может предложить иной подход для постепенного совершенствования существующих проектов на C++. Вот слайды к его презентации — для тех, кто хотел бы изучить код его примеров более подробно.
CSV (Comma-Separated Values) — это универсальный язык для обмена табличными данными, который понимают все, от Excel до сложных баз данных. Вся его сила в простоте: это обычный текст, где значения разделены запятыми. Именно поэтому он стал стандартом для выгрузки отчетов, переноса контактов и подготовки данных.
Можно ли смоделировать хаос пуассоновских потоков бронирований и конечный автомат состояний рейса (от «по расписанию» до «приземлился») целиком внутри PostgreSQL? Мы решили, что для создания идеальной учебной базы данных — можно. Вместо старых статичных таблиц мы построили генератор, имитирующий жизнь глобальной авиакомпании. Рассказываем, зачем это было нужно и почему старая база на 2,5 ГБ перестала справляться с задачами.
Айти — как легендарный вечно ликвидирующийся магазин SUNLIGHT. Уже пару десятилетий наша любимая и родная сфера «умирает», «схлопывается» и «обрушивается» — при этом умудряясь постоянно расти. В 2010-м «поздно вкатываться, все уже написано». В 2015-м «поздно вкатываться, джуны никому не нужны». В 2020-х «поздно вкатываться, всех заменит нейросеть». Найти работу в IT «невозможно», «дефицит кадров» тотален — при этом в 2025 году индустрия в России (да-да) поставила рекорд по численности сотрудников, а вакансий открыты десятки тысяч. В этой статье мы делаем смелую попытку разобраться в том, что происходит с отечественным IT на самом деле.
Присматриваемся к Расту, как возможному кандидату на реализацию задачи Card DOM. Рассматриваем, как он поддерживает полиморфные структуры данных, в частности, приведение типов между трейтами.
Всем привет! Меня зовут Олег Смоляков, в Яндексе я больше 15 лет занимался разработкой, а теперь отвечаю за улучшение процесса найма разработчиков.
Наверняка многие из вас слышали мнения, что у нас много собеседований, их содержание непрозрачно, сам процесс очень долгий, а сверху всё сдобрено задачами на алгоритмы, которые у многих вызывают аллергию. Не буду лукавить: это восприятие не появилось из ниоткуда, и здесь действительно зарыто некоторое количество реальных проблем, о которых я в деталях расскажу дальше.
TLDR: мы решили обновить процесс найма, вместо порой хаотичных собеседований в каждом отдельном сервисе внедряем единую систему оценки по профессии и уровню (например, «Senior C++ Developer»), кандидат, успешно прошедший оценку навыков, теперь сможет претендовать на аналогичные вакансии в любом из 90+ сервисов компании, а всё это вместе делает процесс найма прозрачным, понятным, без дублирования технических интервью и в целом эффективным для всех участников.
А теперь подробнее о том, почему мы на это пошли и как всё устроено.
Меня зовут Илья Куликов, я руковожу разработкой веб-терминалов в компании «Столото». Сегодня хочу рассказать, как мы превратили ручные релизы и вечные конфликты в почти автономный CI/CD. За почти 10 лет в компании я прошёл путь от бэкенд-разработчика до руководителя направления, в «Столото» же за это время родился и вырос целый продукт — веб-терминал для агентов розничной сети. Изначально у нас был парк дорогих аппаратных терминалов, установленных у агентов. Но как расширить сеть и снизить входной порог? Возникла идея: а что, если сделать аналогичное приложение в браузере? Тогда любой желающий мог бы стать агентом — достаточно старого ноутбука и договора с нами. Так появился полноценный веб-аналог аппаратного терминала со всеми необходимыми функциями для продажи лотерей.
Но вместе с ростом продукта росла и боль: релизы занимали часы, всё постоянно ломалось на проде, а после каждого деплоя команда судорожно грепала логи в поисках причины падения. Мы поняли: без серьёзной перестройки процессов дальше — только хуже. И тогда решили кардинально пересмотреть наш подход к CI/CD. Отказались от классического GitFlow в пользу trunk-based development, полностью перестроили пайплайны в GitLab и внедрили автоматизацию на всех этапах — от сборки и тестирования до деплоя и мониторинга.
В этой статье я делюсь реальным опытом:
- как мы ушли от ручных релизов к автоматическому деплою в прод;
- какие практики и инструменты позволили нам перестать бояться каждого коммита;
- как повысить качество кода и ускорить вывод фич на рынок без ущерба для стабильности.
Этот материал будет особенно полезен техлидам, инженерам DevOps, разработчикам и командам, которые всё ещё живут в мире ручных деплоев, боятся нажимать «мердж» в пятницу вечером. Если вы задумываетесь, как перейти от хаоса к предсказуемости в релизах — вы по адресу.
А как мы этого добились — читайте под катом!
Привет! Меня зовут Марина Павлова, я технический писатель в отделе документации 1С-Битрикс. В этой статье я расскажу, как мы полностью переделали документацию по Bitrix Framework и как команде из двух человек удалось выпустить доку за 9 месяцев с помощью ИИ.
Забудьте о ручном склеивании строк: с pathlib пути элегантно конструируются с помощью оператора /. Проверка существования, чтение, получение родительской директории — всё это становится методами и атрибутами самого объекта. В результате код получается не просто чище и читабельнее, он становится более надежным и по-настоящему "питоничным" (Pythonic).
Вы уже научились отслеживать среднюю скорость запросов на проекте, и это большой шаг. Без преувеличений и какой либо иронии.
И теперь, когда вы перешли от "не измеряем ничего" до "измеряем среднее" — вы попали в ловушку.
Пока вы с удовольствием наблюдаете в отчетах красивые 200ms — ваши пользователи стучат в службу поддержки со словами "у меня все висит".
И они не врут, у них действительно TTF порядка 6 секунд. Но и вы не врете, у вас действительно 200ms в отчете!
Врет метрика, а вы ей верите.
Давайте разбираться.
Привет, Хабр!
Сегодня рассмотрим, как в .NET можно горячо подгружать, обновлять и выгружать сборки на лету. Речь пойдёт о AssemblyLoadContext, специальном механизме, благодаря которому мы можем создавать плагинные системы, изолировать зависимости и освобождать память, выгружая неиспользуемые сборки.
Рассказываю о философии «липкой паутины» и о том, как я сделал инструмент, который превращает разрозненные дела в целостную систему. Без дедлайнов и уведомлений.
Если вы когда-нибудь чувствовали, что тонете в бесконечных списках задач, выставляете галочки в трекере, но при этом не видите общего прогресса — вы не одиноки. Я много лет искал систему, которая показывала бы не просто «что сделано», а «как всё связано». И нашёл её в самом неожиданном месте — наблюдая за тем, как обычный паук плетёт свою сеть.
Традиционные инструменты (канбан, TODO-листы) учитывают задачи, но игнорируют связи между ними. Они измеряют скорость, но убивают целостность. Паутина же — идеальная визуальная метафора для любой сложной системы. И сегодня я покажу, как эта метафора воплотилась в работающий инструмент — Stickyweb.
Хочу поделиться небольшим кусочком кода для быстрого вычисления математических выражений из строк, который изначально был написан для моей инди игры. Проект я решил назвать Context EXpressions 🥰
После того как мы разобрались с парсингом Wildberries, логично двигаться дальше и освоить Ozon. Но здесь нас ждёт сюрприз. Ozon гораздо сложнее парсить из-за динамической загрузки контента и более строгих политик автоматизированного доступа.
В этой статье мы разберём, почему для Ozon нужен браузерный парсинг, как использовать Playwright для успешного парсинга и как обернём решение в Telegram-бота, который по запросу пользователя парсит товары и отправляет CSV-файл.