Когда я впервые увидел .gitlab-ci.yml, мне показалось, что это какой-то древний магический свиток. Сплошные stages, artifacts, непонятные правила... Но на самом деле всё гораздо проще — это просто рецепт: что, в каком порядке и как делать с твоим кодом.
Давайте разберём мой рабочий пайплайн по косточкам. Не как сухую документацию, а как реальный пример, который живёт у меня GitLab.
Вы играете в Minecraft? Вы играете в Counter-Strike? Если вы играете в эти игры и они ваши любимые - то эта статья для вас. Название уже говорит про суть статьи. Это был мой первый опыт в маппинге Minecraft и Counter-Strike.
Привет! Я работаю с инфраструктурой резервного копирования и системами восстановления данных. За последние годы мы всё чаще сталкиваемся с одной и той же ситуацией: формально резервные копии есть, правила соблюдены, а вот уверенности в восстановлении — нет.
Поэтому я предлагаю перевод статьи о том, как работает правило 3-2-1, почему оно перестало быть универсальным, какие уязвимости оставляет в современных средах и как эволюционировало, чтобы соответствовать современным требованиям к защите данных.
Правило резервного копирования 3-2-1 на протяжении многих лет считалось золотым стандартом защиты данных. Его привлекательность заключалась в простоте: хранить три копии данных, размещать их на двух разных типах носителей и держать одну копию вне основной площадки.
В течение многих лет такой подход обеспечивал практичную и надёжную защиту в эпоху, когда резервное копирование в основном было локальным, а угрозы — значительно менее сложными.
Но это было когда-то.
Сегодняшнее разнообразие угроз кардинально изменилось. Кибератаки стали целенаправленными и многоэтапными: злоумышленники нападают не только на рабочие данные, но и на систему резервного копирования, стремясь устранить все возможные пути восстановления. Одновременно с этим ИТ-среды эволюционировали в сторону гибридных архитектур, постоянно работающих сервисов и облачно-ориентированных моделей. В результате, то, что хорошо работало в простых инфраструктурах, сегодня с трудом справляется с масштабом, скоростью и сложностью современных угроз.
Когда мы говорим об обучении глубоких нейронных сетей, первое, о чём думают — это архитектура, функция потерь, learning rate. Инициализация весов кажется скучной технической деталью: «ну Xavier/He поставил и забыл». Но за этой простотой скрывается фундаментальная проблема.
Xavier (Glorot, 2010) и He (2015) инициализируют веса из случайных распределений с дисперсией, масштабированной под размер слоя. Это работает хорошо для неглубоких сетей, но с ростом глубины возникает системная проблема: спектральный радиус матрицы весов отклоняется от 1, и сигнал либо затухает, либо взрывается при прохождении через десятки слоёв.
Динамическая изометрия — концепция, которая говорит: чтобы сигнал сохранялся, нужно $\rho(W) \approx 1$ на каждом слое. Добиться этого статистически сложно, особенно стабильно. Но что если взять структуру, где это гарантировано алгебраически?
За два месяца я перепробовал три ASR-движка, шесть моделей Whisper, адаптивное чанкование, T5-коррекцию и ансамблевое голосование — и большая часть идей оказалась тупиком. В статье — подробный разбор шести тупиков и одной находки: почему GigaAM от Сбера на обычном CPU показывает 3.3% WER на русском, обходя Whisper large-v3-turbo на RTX 4090 (7.9%) в 2.4 раза. С бенчмарками, кодом и честными оговорками.
Привет, я Лена, это мой первый пост здесь, и он про техническую задачу, с которой мы столкнулись: как заставить LLM писать текст так, чтобы его нельзя было отличить от написанного конкретной редакцией. Не «хороший текст», не «грамотный текст», а такой, который звучит как этот конкретный городской портал или этот Telegram-канал.
Всем привет! Меня зовут Василий Калинин, я senior-аналитик в отделе ML-аналитики музыкального сервиса Звук. Про то, чем занимается наша команда, мы уже писали ранее (можно почитать в этой статье).
Мой сегодняшний рассказ будет посвящен метрикам онлайн-оценки рекомендательных систем, использующихся в нашей компании.
Никогда не предполагал, что погружусь в математическое моделирование, компьютерные симуляции и прочие непростые материи. В планах было создавать компьютерные игры, грезил о том, чтобы играть тяжёлый металл — но уж никак не создавать какие‑то цифровые двойники. Однако жизнь, как выясняется, не то, чтобы сложнее, чем думалось, но куда интереснее. А может, просто страннее? Впрочем, это не важно.
Наверное, мой путь покажется довольно стандартным. Школа – университет – работа. Попробую немного рассказать про каждый из этих этапов.
В статье приведено подробное решение одной задачи из классического задачника Воробьева -- Савченко. Отмечены подводные камни, имеющиеся в ее формулировке. Статья является научно-популярной и адресована продвинутым школьникам и студентам, изучающим теоретическую механику. Может быть также полезна преподавателям физики.
Дисклеймер: у нас было 2 пакета импортных микросхем, 75 плат от древных телевизоров и компьютеров, 5 банок кислоты, пол-банки растворителя и целое множество Советских микросхем всех сортов и расцветок, а также микроскоп кафедры микроэлектроники, станок ЧПУ, фрезы, тиски и пинцет. Не то что бы это был необходимый запас для написания курсового проекта. Но если начал получать образование, становится трудно остановиться. Единственное что вызывало у меня опасение - это публикация статей. Нет ничего более беспомощного, безответственного и испорченного, чем авторы статей. Я знал, что рано или поздно мы перейдем и на Хабр.
@STriple и @Nemilandr в своих статьях вскрывали микросхемы Отечественных производителей: «Бештау», ООО "ИТР" (ООО "Интегральные Телематические Решения"), АО "ДжиЭс Нанотех" (GS Nanotech), ООО "НЭК.ТЕХ" (Нартис), Энергомера, Микровел ПТИ.ЛТД (MICROARRIS) и "Миландр". В этом посте мы покажем маркировки кристаллов зарубежных и Cоветских производителей микросхем. Анонсируем серию постов, носящих исследовательский характер. В этом посте посмотрим на кристаллы микросхем
Рассказываю историю создания Mumin API — современной Open Source платформы для работы с хадисами. Внутри: битва с «кривыми» PDF-сканами через регулярки Python, ускорение Fuzzy Search в PostgreSQL почти в 2 раза с помощью GIN-индексов, публикация Kotlin SDK в Maven Central и опыт работы с AI как с Senior-напарником. Без «воды», только код, архитектура и реальные грабли 16-летнего разработчика
Совсем недавно сложно было представить что простым людям так быстро станут доступны инструменты ИИ агентов. Но технологии не стоят на месте. И вот в конце января 2026 года набирает популярность бесплатный и автономный агент, разработанный Питером Штайнбергером - OpenClaw (ранее Clawdbot и Moltbot). Инструмент очень быстро набирает популярность и буквально за считанные дни репозиторий в github становится самым быстрорастущим за всю историю площадки, обогнав Kubernetes. Такая популярность не могла не привлечь и широкое внимание конкурентов. Так появляется PicoClaw легковесный агент от китайских разработчиков, написанный на языке Go. Вот список некоторых особенностей PicoClaw:
Сверхлёгкое потребление ресурсов: работает на менее чем 10 МБ ОЗУ, что примерно на 99 % меньше, чем у OpenClaw (>1 ГБ) и значительно меньше NanoBot (>100 МБ). Это позволяет запускать ИИ-ассистента на очень дешёвом оборудовании.
Минимальные аппаратные требования: запускается даже на устройствах стоимостью около $10 (например, RISC-V платы вроде LicheeRV Nano), в то время как многие альтернативы требуют мощности серверного класса или ПК.
Молниеносный запуск: стартует за <1 секунду, даже на медленных процессорах с частотой ~0.6 ГГц, обеспечивая гораздо более быстрый отклик, чем у конкурентов, где загрузка может занимать десятки или сотни секунд.
Высокая переносимость: представляет собой один бинарный файл на Go, без тяжёлых зависимостей, и поддерживает разные архитектуры — RISC-V, ARM64 и x86, что упрощает использование на разнообразных устройствах.
TL;DR: Обновил UnblockPro до v2.0. Discord теперь реально работает — не только проходит тесты, но и загружает приложение, подключается к голосовым каналам и ведёт себя как положено. Разобрался, почему «всё ОК» в тестах, но Discord молча висит на «Проблемы с подключением». Оказалось, проблема была в архитектуре фильтрации — не хватало трёх ключевых правил, и DPI тихо дропал соединения, которые тесты не проверяли. Код на GitHub — by-sonic/unblock-pro.
Предыстория
Два месяца назад я выложил UnblockPro — Electron-приложение, которое в один клик обходит DPI-блокировки Discord и YouTube. Статья набрала 50к+ просмотров, 200+ звёзд на GitHub, 192 закладки на Хабре. Люди скачивали, пользовались, ставили звёзды.
И параллельно писали в issues: «YouTube работает, а Discord — нет».
Причём у части пользователей всё работало отлично. А у другой части — Discord висел на «Connecting...» или «Проблемы с подключением», хотя приложение рапортовало: «Стратегия X работает!». Тесты проходили. Логи были зелёные. Но Discord — нет.
Я потратил неделю на поиск причины. И нашёл. Проблема оказалась гораздо глубже, чем я думал.
Вы наверняка слышали эту фразу: «Предприниматель должен обладать интуицией». Звучит красиво. Но на практике интуиция часто превращается в «гадание на кофейной гуще». Мы запускаем продукты, потому что «нам кажется, что это выстрелит», открываем филиалы, потому что «сосед открыл», и тратим бюджеты на рекламу, которая бьет в пустоту.
Ошибки в бизнесе стоят дорого. Иногда — слишком дорого.
Меня зовут Андрей Васючков, я занимаюсь стратегическим маркетингом. В этой статье я расскажу, как перестать опираться только на ощущения и начать принимать решения на основе фактов. Мы разберем, зачем нужен анализ рынка, как сделать это без раздутого штата аналитиков и почему цифры из открытых источников могут принести вам больше денег, чем кажется.
Вы все это видели.
Стартап на три человека. Идея простая - агрегатор скидок в районных парикмахерских. Бэкенд еще не написан, но архитектура уже утверждена.
Конечно же, микросервисы. Конечно же, Kubernetes. Обязательно кафка для обмена сообщениями, потому что "нам нужна асинхронность". И база данных - непременно NoSQL, желательно шардированная, ведь мы готовимся к миллионам пользователей. Сразу. В первый день.
Проходит полгода.
Продукт не запущен. Деньги инвесторов (или личные сбережения фаундера) сгорают на оплату кластеров в облаке. Два сеньора, которых наняли за большие деньги, целыми днями настраивают CI/CD пайплайны и спорят о правильной гранулярности сервисов.
А бизнес-задача? Она потерялась. Мы не решаем проблему пользователя, мы решаем проблемы, которые сами себе создали, выбрав инструменты не по размеру.
Привет, Хабр! Меня зовут Александр Воробьев. За моими плечами разработка более 100 электронных устройств, пуско-наладка АСУ ТП и множество проектов, где нужно было "прикрутить" датчик к микроконтроллеру, написать веб-интерфейс и заставить это всё работать вместе. Каждый раз — это горы кода, даташитов и времени. В какой-то момент я задался вопросом: а можно ли автоматизировать этот процесс? Чтобы инженер думал над архитектурой, а не над синтаксисом? В этом посте я поделюсь своим путем создания инструмента, который позволяет собирать сложные IoT-системы за минуты с помощью AI-агента, и покажу это на реальных кейсах.
Если у вас есть бот в Телеграме, то наверняка уже поглядываете в сторону Max — аудитория растёт, игнорировать сложно. Первая мысль: наверняка кто-то уже написал удобный Go-клиент. Чем всё закончилось, вы уже догадались — своим клиентом.
Язык программирования Zator представляет собой интересный и четко очерченный пример доменно-ориентированного языка, разработанного не для универсальных задач программирования, а для решения одной конкретной, но все более значимой проблемы — построения сложных генеративных пайплайнов для создания текста и изображений = Его философия коренится в стремлении минимизировать "шаблонный" код, который традиционно мешает созданию содержания, и предоставить разработчикам, дизайнерам и другим создателям контента высокоуровневые абстракции для работы с передовыми технологиями искусственного интеллекта . В отличие от мощных, но часто громоздких общепurpose языков, таких как Python или JavaScript, Zator делает ставку на простоту, скорость и специализацию, что определяет его место в экосистеме инструментов для ИИ =
Основная идея, лежащая в основе Zator, заключается в том, чтобы стать "языком описания пайплайнов", который работает поверх существующих сервисов искусственного интеллекта, а именно KoboldCpp и Stable Diffusion = Задача создания последовательностей, где результат одного шага (например, сгенерированный текст) используется как вход для следующего (например, промпт для генерации изображения), требует сложного взаимодействия с API. Это обычно включает в себя написание кода для сетевых запросов, управления состоянием, парсинга JSON-ответов и обработки файлов. Zator призван инкапсулировать всю эту сложность внутри нескольких ключевых функций, таких как generate_text() и generate_img(), которые абстрагируют низкоуровневые детали и позволяют пользователю сосредоточиться исключительно на логике своего пайплайна . Таким образом, язык позиционируется как инструмент, снижающий порог входа для людей без глубоких знаний в области системного программирования или веб-разработки, позволяя им быстро экспериментировать и создавать сложные генеративные сценарии .
Привет, Хабр!
Если вы когда-нибудь сталкивались с задачей запуска сотен изолированных фоновых процессов на одном сервере (будь то парсеры для клиентов, торговые боты или обработчики данных в SaaS), то вы знаете, как быстро всё усложняется.
Можно, конечно, вручную поднимать Docker-контейнеры и писать костыли для мониторинга. Можно развернуть полноценный Kubernetes, но для одной ноды это часто — оверкилл, требующий отдельного администратора. Можно использовать Celery, но он управляет задачами, а не контейнерами, и изоляция на уровне процессов — это не тоже самое, что изоляция на уровне контейнеров.
Мы столкнулись с этой болью и написали инструмент, который закрывает этот пробел. Встречайте: RedTailFox — легковесный оркестратор на Python, который управляет Docker-контейнерами с вашими воркерами на одном сервере. Он сам решает, когда поднять новый контейнер, сам следит за здоровьем слотов и сам себя чинит.
