Technotext

«Где мои логи — в /var/log/messages, /var/log/syslog или только в journalctl?» — этот вопрос рано или поздно задает себе каждый инженер, который вынужден переключаться между разными дистрибутивами: Ubuntu, CentOS, Alpine, корпоративные Unix системы. 

Типичный сценарий: вы заходите на сервер, ищете /var/log/messages, а его или нет, или он есть, но journalctl показывает гораздо больше событий, чем файл. 

Иногда сервер внезапно начинает сильно использовать CPU, и в итоге причиной оказывается агрессивное логирование. 

Если к этому добавить разнородный парк, где рядом с Ubuntu живут динозавры на AIX и Solaris, путаница приобретает глобальный характер. 

Сейчас мы живем в эпоху «двоевластия»: systemd‑journald уже стал стандартом де‑факто, но rsyslog все еще присутствует во многих дистрибутивах по инерции или ради совместимости. Эта статья для инженеров, которые хотят понимать, кто именно пишет логи в Linux, почему они дублируются, где теряются CPU и I/O, и как настроить логирование так, чтобы диск не превращался в помойку. 

Мы пройдем путь от бинарных логов AIX до journald, а в конце разберемся, как практически использовать journalctl с популярными инфраструктурными службами. 

В этом посте поговорим о дизайне мнемосхем: когда "лучшее — враг хорошего", почему не всё нужно отражать на мнемосхемах детально, а скучные цвета — это хорошо.

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

Последние месяцы я строил систему, которую внутри называю «аниме-заводом»: на вход она получает исходный эпизод, а на выходе собирает готовый YouTube Shorts с динамическим кадрированием, субтитрами, постобработкой и метаданными для публикации.

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

В статье я покажу, как устроен этот пайплайн, почему я пошел в модульную архитектуру вместо end-to-end black box, где система ломалась и какие решения в итоге сделали ее реально рабочей.

Как понять, что ваш маркетплейс-бизнес уже убыточен: 5 вопросов, которые должен задать себе каждый селлер 

Я, Ирина Чекулаева, люблю BI и многие годы занимаюсь построением систем бизнес-аналитики. К Международному женскому дню хочу рассказать историю про платья. Но на самом деле это история про архитектуру и аналитику данных. Она началась с того, что в какой-то момент селлеры поняли, что продавать через маркетплейсы - это не значит просто загрузить товар и получить деньги.

Бренды и предприниматели массово заходили на Wildberries и Ozon с ощущением, что сейчас будут «золотые горы». И правда, сначала выручка росла, продажи увеличивались, и казалось, вот оно - бизнес-счастье.

Проблема проявилась позже. Оборот растет, производство работает на полную мощность. А где прибыль?

Знакомая ситуация: просишь Claude Code добавить авторизацию — он переписывает половину проекта. Просишь поправить одну функцию — получаешь удалённые тесты и новую зависимость, о которой не просил. За час строишь рабочий прототип, а потом три часа разгребаешь то, что Claude наворотил при «улучшении».

Я Python-бэкенд разработчик, веду свою компанию CREATMAN и кожу в основном один. У меня нет роскоши держать QA-инженера, который будет ловить регрессии после каждого промпта. Мне нужно, чтобы AI-агент помогал быстрее шипить, а не создавал новые проблемы.

После нескольких недель исследования — чтения доков, обсуждений на Reddit, разбора чужих сетапов — я собрал конфигурацию, которая реально работает. Собрал всё в открытый репозиторий с готовыми файлами: claude-code-antiregression-setup. В этой статье — что именно и почему.

Тимлид — не повышение. Это смена профессии.

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

За каждым вопросом — не сухая теория, а реальный опыт и истории живых людей.

В индустрии проектирования, строительства и управления недвижимостью сегодня много говорят о «цифровизации», «информационном моделировании», о использования в работе «BIM / ТИМ — моделей», о формировании «Цифрового двойника (Digital Twin)». Однако термины BIM (Building Information Modeling) / ТИМ (Технология Информационного Моделирования) и Цифровой двойник (Digital Twin) часто используются как синонимы, что является не совсем верным. Для участников проекта объекта капитального строительства (ОКС), заказчика, инвестора и главное, для службы эксплуатации понимание этой разницы — вопрос не терминологии, а миллионов рублей сэкономленного бюджета и часов простоя в случае использования их в своей работе, но шума обсуждений много, как понять что использовать?

В этой статье я разберу, что есть что, в чем разница и почему переход от BIM / ТИМ - моделей к цифровому двойнику важен для жизненного цикла (ОКС).

Сколько себя помню, меня всегда привлекали счётчики памяти в Linux: смотришь в условный htop – в плане потребления CPU вроде всё +/- понятно, а вот память всегда считалась как-то не так, как ты это на первый взгляд ожидаешь, и долгое время у меня было довольно наивное и ошибочное представление о механизмах её работы.

Со временем некоторые вещи прояснялись, приходило понимание, как именно оно работает под капотом (до определённой степени). В какой-то момент возникла рабочая необходимость понять, куда уходит память на реальной системе – и этот случай в очередной раз показал, что местами оно устроено довольно неочевидно, и на этот вопрос не всегда просто дать ответ. Ну а помимо рабочей необходимости у меня дома давно стоит сервер, обвешанный метриками, и всегда хотелось высветить себе их в понятной форме, чтобы потом в реальном времени наблюдать, как ведёт себя система, когда в ней происходят те или иные процессы.

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

Привет! Меня зовут Никита Соболев, я core-разработчик языка программирования CPython, а так же core-разработчик фреймворка Litestar, пакета django-stubs и множества других пакетов для Django.

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

Если хотите похоливарить в коментах на тему того, какой фреймворк самый лучший и удобный – залетайте! Обсудим.

Ларингалы – самые загадочные звуки праиндоевропейского языка, не сохранившиеся ни в одном из живых индоевропейских языков. Звуки-призраки, которых никто из ныне живущих не слышал. И звуки-атланты, на которых держатся все реконструкции праиндоевропейского. Почему учёные так уверены в их существовании? Можем ли мы хотя бы представить себе их звучание? И как их можно записать, кроме нижних индексов? Обо всём по порядку – в этой особой статье по заявкам читателей.

В статье рассказывается про python библиотеку, с помощью которой можно обучить ИИ для прогноза волатильности, без знания машинного обучения вообще. Нужно лишь разбираться в python.

Многие предприятия до сих пор эксплуатируют системы автоматизации зданий (BMS) на базе оборудования Johnson Controls предыдущих поколений. Часто возникает задача модернизации или расширения системы.

Цель данной работы — исследовать механизм обмена данными протокола N2Bus по интерфейсу RS-485 и проверить возможность подключения современных устройств Modbus RTU непосредственно в ту же физическую шину, где "живут" контроллеры Johnson Controls.

Важно: Все приведённые данные использованы исключительно для целей локальной интеграции. Материал предназначен для образовательных и исследовательских целей в контексте интеграции в системы автоматизации зданий.

Последнее время я экспериментировал с AI-агентами на Raspberry Pi 5.

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

Как отправить робота на автономное патрулирование и научить его «видеть»? Разбираем реальный кейс создания роботизированной системы мониторинга на базе отечественной платформы: выбор оборудования, интеграция ИИ и примеры кода. Делимся опытом, как научить робота собирать данные, обходить препятствия и почему отказались от модной робособаки.

Привет! Меня зовут Антон Рогозин и я разработчик машинного обучения в Контуре. В этой статье расскажу про своё увлечение 3D-печатью, а точнее о том, как я подгорел от того, сколько нюансов надо учесть, чтобы распечатать под ключ маленькую фигурку хорошего качества. 🤌 Хотите узнать, как выглядит процесс изготовления 3D-моделей, какой принтер купить и сколько стоит инвентарь для печати? Тогда приглашаю под кат. Ещё внутри этой статьи затаилось много полезных ссылок, которыми я советую пользоваться, и, конечно же, фото моих фигурок из настольной ролевой игры D&D (подземелья и драконы).🧌 Заходите оценить.

В феврале этого года я [писал на Хабре](https://habr.com/ru/articles/883590/) про автоматизацию тестов для САПР. Мы делали систему с записью действий в JSON и воспроизведением через pyautogui. Работало. Но только для одного конкретного проекта.

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

Что изменилось? Убрал привязку к конкретному софту. Добавил умный поиск элементов вместо тупых координат. Сделал так, чтобы QA мог записать тест без единой строки кода. Прикрутил UI-ассерты, мониторинг системы, файловые проверки.

Короче, то что начиналось как решение для одной задачи, выросло в полноценный фреймворк. И оказалось полезным не только мне.

Неделю назад по сети пронеслась новость о том, что генеральный директор Y Combinator Гарри Тан с помощью ИИ Claude пишет десятки тысяч строк кода ежедневно и имеет виртуальную команду из 10+ ролей. Я решил проверить насколько это решение действительно рабочее и не является ли оно очередным хайпом. В этой статье мы разберемся, что за инструмент использует CEO Y Combinator и в чем его особенности. А также попрактикуемся в его использовании.

Я перепробовал несколько способов вести документацию по базе данных — и у каждого были свои проблемы: информации недостаточно, сложно поддерживать, непонятна команде. Хуже всего, что плохая документация по БД тянет за собой проблемы с требованиями к данным — а это не только таблицы, но и миграции, и данные в коде. В какой-то момент я понял, что пытался решить одним документом три разные задачи.

Почему REST API не всегда подходит для общения микросервисов?

Разбираем на примере интернет-магазина, как Kafka решает проблемы синхронной коммуникации, масштабирования и отказоустойчивости.

ИИ‑агенты вроде Claude Code и Cursor умеют писать код. Но одного файла с инструкциями им хватает ровно до первых сложных задач. Дальше агент молча трогает семь модулей вместо одного, уверенно додумывает чужой API и третий раз подряд наступает на одни и те же грабли. На тридцатом проекте становится ясно, что нужен полноценный инженерный стандарт, а не набор личных правил. В индустрии такого стандарта до сих пор не было, поэтому пришлось написать его самому. Так появились SENAR (открытый стандарт инженерного процесса для разработки с ИИ‑агентами) и фреймворк TAUSIK к нему. Первая статья из шести рассказывает, из какой конкретно боли они выросли.