
За последние полгода вышли сотни материалов об ИИ-агентах. Особенно много говорят про OpenClaw и Hermes. Я изучил, пожалуй, добрую половину из них, протестировал сам и хочу поделиться выводами.

За последние полгода вышли сотни материалов об ИИ-агентах. Особенно много говорят про OpenClaw и Hermes. Я изучил, пожалуй, добрую половину из них, протестировал сам и хочу поделиться выводами.
Мне хотелось написать небольшое приложение. Я работаю fullstack‑разработчиком, поэтому для разработки я решил использовать web‑технологии. Мне хотелось, чтобы я мог написать код один раз, и чтобы он запускался на всех моих устройствах (windows, linux, android).
Мне хотелось использовать готовые инструменты. Я был уверен, что их мне будет достаточно. Посмотрел на существующие решения: electron, neutralinojs, apache cordova, tauri, capacitor, ... Все они мне не нравились по разным причинам. Разберём основные моменты:
ElectronЧитать полностью »
Эта история началась с обычного git push.
Я работал над проектом, не буду называть его, потому что статья не про конкретную компанию или проект и не про поиск виноватых. Она про то, как вредоносное ПО может попасть в привычный рабочий процесс разработчика, замаскироваться под нормальные Git-изменения и постепенно заражать другие проекты и машины.
Я хочу рассказать это на реальном примере, потому что такие истории обычно кажутся чем-то далеким: «ну это где-то в крупных компаниях», «ну это у тех, кто скачивает странные файлы», «ну я-то опытный разработчик, я замечу».
Когда в октябре 2024-го заблокировали Дискорд, я сидел в голосовом канале с друзьями. Связь оборвалась, все полезли за впн-ками, кто-то ушёл в Телеграм, кто-то просто пропал. Серверы, которые мы строили годами, с каналами, ролями, ботами, в один момент стали недоступны.
Я фрилансер, пишу на React и Node.js. В тот вечер подумал: а насколько сложно вообще сделать свой мессенджер с серверной структурой? Не чат на вебсокетах из туториала, а нормальный. С серверами, каналами, ролями, голосовыми комнатами, ботами. Такой, чтобы можно было перетащить своё сообщество и не чувствовать разницы.
Оказалось, сложно. Но я всё равно сделал.
В системах, где генерируются миллионы событий в день (например логи), первичные ключи часто строятся на основе UUID. Это логично: они глобально уникальны, не требуют централизованного генератора и хорошо масштабируются.
Сайты появились практически сразу после создания всемирной паутины. С каждым десятилетием браузеры и web-сервера развивались, каждое новое поколение меняло языки программирования и стандарты, с каждым разом индустрия предлагает всё более новый ��одход к разработке сайтов и web-приложений.
Знаете это чувство, когда открываешь контроллер в Express проекте, чтобы поправить одну строчку логики, и видишь ЭТО? Бесконечная вложенность, проверки на существование полей, ручной парсинг ошибок от базы данных и, конечно же, его величество try-catch, который занимает 80% файла.
Я тоже через это проходил. В каждом новом микросервисе я копипастил одни и те же функции обработки ошибок. В одном проекте я ловил ошибки Mongoose через err.name === 'ValidationError', в другом — через instanceof. Где-то мы отдавали { error: "message" }, где-то { status: "fail", msg: "..." }.
Эта статья о том, как настроить Squid proxy с SSL bump в Docker и организовать realtime-мониторинг логов. В качестве практического примера я покажу open-source решение на современном стеке (Bun + Redis + Vue), которое решает проблему устаревших инструментов мониторинга.
Исходный код проекта: GitHub
Сделал забавного бота который стал ещё и довольно полезным поэтому решил им поделиться. Хотелось сделать бота, который:
По запросу пойдёт в интернет и найдёт то, что мы обсуждаем прямо сейчас, так как он видит контекст беседы и часто понимает, о чём идёт речь, и в ответе даст ссылки на источники, которые найдёт
Понимает контекст беседы и не требует объяснять ему каждую деталь
Знает какой сейчас год и точное время и учитывает это при поиске информации и при ответах
Имеет характер и помнит, кто и как к нему относится в этом чате
Расшифровывает голосовые сразу для всего чатаЧитать полностью »
Когда руководство решило перевести проектный трекинг с Яндекс.Трекера на JIRA, мы быстро поняли: простого "экспорта-импорта" не будет. Ни одно из готовых решений не справлялось с задачей полноценно — а именно с сохранением всей истории, авторства, чек-листов, вложений, связей, ссылок на другие задачи и пользователей, и даже оригинальной нумерации задач из Яндекс.Трекера.
Что ж, вызов принят. Ниже расскажу, как я за 3 месяца написал систему, которая перенесла всё — до последней запятой в комментарии.