Все потоки

История создания открытой настольной CO2-станции на базе микроконтроллера ESP32-C3, круглого дисплея GC9A01 и честного фотоакустического NDIR-сенсора углекислого газа Sensirion SCD41.

Большинство бюджетных мониторов воздуха используют дешевые eCO2-датчики, которые лишь угадывают уровень углекислого газа по качеству летучих веществ. Этот проект — полностью открытая альтернатива. Прошивка написана на чистом фреймворке ESP-IDF, использована моя собственная графическая библиотека. Устройство передаёт данные по протоколу MQTT, откуда информацию может забирать умный дом или любая другая похожая система. В настоящий момент показания интегрированы в Home Assistant.

Представьте: вы наконец посчитали, сколько денег утекает из дома через плохую теплоизоляцию. Пришли к владельцу с цифрой в 200 тысяч в год на отоплении. Он посмотрел, кивнул и сказал: «Ну окей, запишем в убытки».

Примерно так выглядит разговор про техдолг с бизнесом. Пока это «у нас легаси» – руководство кивает и говорит «разберитесь», а стоит принести конкретные рубли вообще тему закрывают. Парадокс в том, что цифра без плана погашения – это не аргумент, а счёт, и на счёт без понятного ROI у CFO всегда один ответ: списать и забыть. 

Мы потратили какое-то время на то, чтобы разобраться, почему так происходит. В процессе нашли три методики, которыми на западе считают техдолг в деньгах – у каждой свои допущения, слепые пятна и сценарии, в которых она врёт. И отдельно поняли, что сама по себе цифра это только половина задачи. Вторая половина упаковка, без которой CFO скажет «спишем» при любой методике.

Об этом и поговорим.

Я сисадмин. Олдскульный. Работал с сетями, писал скрипты, поднимал VPNы, отлаживал маршрутизацию в три часа ночи. И люблю читать фантастику. Но почти всегда, когда в книге появлялся «хакер» или «системный администратор», меня передёргивало.

То он взламывает Пентагон за пять минут через ноутбук через взлом IP‑адреса, то пишет код в виде случайного набора слов или набор команд, не имеющих вообще никакого смысла. В лучшем случае программист — это какой‑то шаман, который раз — и всё сделал.

И все эти годы где‑то на подкорке мне хотелось бы почитать про себя в главной роли, про очкарика с клавиатурой, который находит нужные данные не перебором комбинаций, а через grep, и ломает сервер не выстрелом, а через ssh и chattr +i

Бизнес часто незаметно сливает бюджет на нейросети: купили доступы, раздали сотрудникам, запустили «вау-демо», но так и не встроили ИИ в процессы. Компания платит за инструменты, а сотрудники продолжают руками собирать отчёты, писать однотипные письма, переносить данные между таблицами и ждать друг друга в чатах.

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

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

Привет, Хабр! Меня зовут Михаил, я backend-разработчик в команде Managed Kubernetes в VK Cloud. При работе с K8s всем нам приходится сталкиваться с множеством конфигураций, которые мы используем постоянно, и Service не является исключением. И вот тут мне стало любопытно: а может ли с виду безобидный конфиг Service сломать нам весь кластер? Ну или хотя бы подпортить жизнь какому-то сервису?

Зачем мне это? Во-первых, это просто интересно: сломать что-то, понять, как оно работает, узнать, как то, что кажется обыденностью, может стать проблемой. Во-вторых, если удастся что-то накопать, то мы получим список потенциальных ошибок нашего кластера и будем думать над способами защиты и обнаружения. Так что приступим!

Статья будет полезна DevOps, безопасникам, админам и просто юным любителям Kubernetes. 

В прошлой статье цикла «РБПО для бедных» мы разобрались, что такое разработка безопасного программного обеспечения, зачем она нужна стартапам и как может выглядеть минимальный конвейер безопасной разработки. Теперь пора переходить от схем и планов к практике.

В этом материале мы рассмотрим:

— создание виртуальных машин в VirtualBox для сервисов безопасной разработки ПО;

— подготовку виртуальных машин к дальнейшей работе;

— установку Ubuntu Server с ручной настройкой статического IP;

— первичную настройку серверов: часовой пояс, базовые утилиты, брандмауэр UFW, установку Docker и docker‑compose.

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

Так что запасаемся терпением, запускаем VirtualBox и начинаем строить нашу небольшую лабораторию безопасной разработки.

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

Маленький сервис, который можно спокойно пилить по вечерам, постепенно продвигать, а он со временем начнёт приносить вторую зарплату.

Я тоже так думал.

Полтора года назад мы с другом начали делать свой небольшой продукт. Потратили на него примерно 100 000 ₽, вложили кучу времени и сил. Сервисом воспользовались более 5 000 человек. А заработали мы примерно 1 000 ₽.

И теперь я пытаюсь понять, где именно мы облажались.

Каждый раз, когда нужно добавить новую модель в проект, приходится писать буквально одинаковый код: с одинаковыми проверками, с одинаковыми корректировками, с одинаковыми Codable, с одинаковыми тестами.

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

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

Привет, Хаброжители! Практическое руководство по подготовке к OOD-собеседованиям в ведущих IT-компаниях. Книга предлагает четкую 4-этапную схему проектирования, глубокий разбор основ ООП и SOLID, а также 14 готовых к реализации систем (парковка, кинотеатр, банкомат, ресторан, лифты и др.). Каждый кейс сопровождается сбором требований, UML-диаграммами, рабочим кодом и проработкой граничных случаев. Дополнительно — паттерны проектирования и советы по коммуникации. Идеальный инструмент, чтобы перейти от теории к уверенной практике.

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

Привет, Хабр! Меня попросили доработать кастомизированный телекастер JET JT-300 SB. Сейчас мы его рассмотрим и послушаем, а заодно научимся делать автоотсечку хамбакера стандартным трёхпозиционным переключателем и корректировать звучание датчиков простыми пассивными фильтрами.

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

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

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

Всем привет! Это команда курса по вайбкодингу в Практикуме. В этой статье хотим поразмышлять о формирующейся роли Business Logic Owner: что это, почему стало актуальным и какие специалисты станут первыми BLO. 

Я техписатель, чьи тексты принимают за ИИ-шные. И вот что выяснилось…

Так случается: пишешь текст сам, вычитываешь, вычищаешь, убираешь воду – а потом коллега спрашивает: «Это ChatGPT?»

Привет!

Это 17 выпуск Frontend Status — дайджеста по фронтенд-разработке.

В этом выпуске:

📺 Страница отрисована, а интерфейс всё ещё «оживает»: отложенная гидратация в TanStack Start на карусели Jack Herrington и подкаст с Андерсом Хейлсбергом — от Turbo Pascal до того, как ИИ меняет ремесло, когда код пишут не построчно — чтобы понять, где теряется скорость и куда движется разработка.

🤖 Половина кода уже с ИИ, а доверия меньше: опрос State of AI 2026 (54% сгенерированного кода), Яндекс и тысячи конфликтов при мерже Chromium, перцептрон 1959 года и «чтение мыслей» модели Anthropic — чтобы смотреть на внедрение ИИ цифрами и без иллюзий.

🛡️ Пустили агента в репозиторий — а что он может сломать: разбор Positive Technologies и история, когда ИИ «находит» CVE, который уже был в обучающих данных — чтобы не открывать доступ вслепую.

💫 Анимация замирает вместе с React: управление бесконечными CSS-циклами без прыжков и сравнение CSS, Motion и GSAP на главном потоке — чтобы интерфейс оставался плавным без лишнего JavaScript.

⚡ Нужна коллаборация как в Figma и Miro: Hocuspocus от Tiptap на Y.js и CRDT без гонок правок — WebSocket, офлайн и Redis — чтобы собрать совместное редактирование в своём редакторе без тяжёлого бэкенда.

⚡ Поиск раздувают до эмбеддингов и LLM: Fuse.js ~6 КБ с нечётким поиском, кириллицей и Web Workers в 7.4.0 — чтобы находить по списку в браузере без сервера и векторной базы.

⚡ TypeScript кажется очевидным, пока не упёрлись в типы: 15 коротких приёмов от Matt Smith — satisfies, проверка «все варианты учтены», строгий режим — чтобы писать безопаснее и без лишних аннотаций.

⚛️ React-шаблон на 35 000 звёзд без хаоса в репозитории: разбор Bulletproof React на Habr и MUI X 9.3 — чтобы взять проверенную архитектуру и не собирать стек с нуля.

🔥 Ember 7.0 без сюрпризов при мажоре: в основном сняли устаревшее, путь через 6.12 и Vite по умолчанию — чтобы обновиться без лотереи.

🅰️ Angular 22 меняет правила игры: OnPush по умолчанию, signal forms и инструменты для агентов в API — чтобы заложить новый проект на актуальных примитивах, а не по инерции.

𝐒 Svelte: $state.eager и pending больше не рвут зависимости, батчи идут связным списком — чтобы асинхронный UI вёл себя предсказуемо после обновления.

📦 Solid 2 в бета-версии, звонки WebRTC в production и шрифтовые иски на 15,3 млн ₽: асинхронность как примитив, грабли CallKit и SFU, PHP-парсер для проверки сайта — чтобы не удивляться ни релизу, ни иску.

🌎 Браузер снова забирает вёрстку у хаков: column-rule и row-rule в зазорах grid/flex и HTML внутри canvas за флагом — чтобы меньше DOM-обходов и проще UI поверх 3D.

🌐 Стандарты без костылей: сравнение объектов по значению (Composites в TC39) и элемент <install> для PWA без своего JavaScript — чтобы меньше полагаться на ссылки и самописные кнопки установки.

🛠️ Агенты под контролем: statewright с фазами и лимитами, свой Claude Code за вечер на DeepSeek и экспериментальный агент доступности GitHub н

С вами снова Илья Вязников, инженер сопровождения SOFROS. Продолжаю делиться практическими приёмами, которые упрощают жизнь при эксплуатации и доработке интеграций.

Не так давно я рассказывал, как вынести повторяющуюся логику в C# функции, но в любом серьёзном проекте со временем накапливаются не только функции, но и куча параметров: адреса сервисов, таймауты и т.д. Сначала их прописывают прямо в коде, но очень быстро это превращается в проблему.

Сегодня расскажу про глобальные константы — один из полезных инструментов платформы для централизованного хранения таких параметров.

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

Но для 1С такой подход опасен. Если система стала критичной для компании, оборудование под ней – уже не просто «железо». Это часть производственного контура. Через него проходят документы, продажи, склад, производство, расчеты, отчетность и интеграции. Когда инфраструктура перестает справляться, бизнес теряет не абстрактную производительность, а скорость операций.

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

Для ИТ-команды такая жалоба – не диагноз, а точка входа в расследование. За ней может стоять как прикладная проблема, так и ограничение инфраструктуры: от блокировок и настроек СУБД до дисковой подсистемы или некорректной конфигурации кластера.

Если начать разбор с предположений, команда быстро уходит в спор: разработчики смотрят на администраторов, администраторы – на 1С, бизнес – на всех сразу. Экспресс-аудит нужен, чтобы заменить спор фактами и быстро понять, где система действительно теряет производительность.

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

Дисклеймер по традиции: я не профильный разработчик, пишу свой симулятор школы по вечерам, и вполне допускаю, что местами мои решения покажутся вам наивными или кривыми (или вообще НЕВЕРНЫМИ). Я просто рассказываю про проблему, в которую упёрся сам, и про то, как из неё выбирался. Если знаете, как лучше --- буду рад в комментариях.

Сразу про важное, чтобы не было завышенных ожиданий: игра - это прототип. Что-то в нём работает прилично, что-то держится на гвоздях, часть систем существует в режиме «работает, но я иногда удивляюсь - почему». Так что это не рассказ «как надо», а просто один из кейсов и один из способов решения. Но очень полезный способ! ОЧЕНЬ

Это еще одна статья из цикла про разработку игр без прикладного опыта. Если вам интересна эта и подобные темы - подписывайтесь на мой ТГ-канал Homemade Gamedev, где посты выходят чаще, и я пишу про текущие задачи в проекте.

Я не руководил проектами, а просто строил дачу, но именно там понял, зачем нужны планы, оценки сроков и понимание бюджета. Делюсь опытом и выводами.

Во время настройки SOAR произошёл любопытный случай. Я прямо разрешил AI предложить блокировку атакующей машины. Он прочитал инструкцию. Подумал. И отказался. Причём оказался прав.