Почти каждый день в ленте я вижу новости про очередного "революционного" AI-агента. AutoGPT, BabyAGI, Devin, Cursor, Perplexity, Atlas.... мол они заменят программистов, копирайтеров а в итоге....
Я, как хотел бы инструмент, который просто работает, мол "Зайди в гугл, найди доку, скажи мне ответ" ради интереса - я решил написать свой AI-тул....
Мне очень нравится идея потоков данных в Node.js - data streams. Они используются всюду: чтение файлов, сетевые запросы, архивирование файлов.
Не путать с потоками выполнения процессов - threads! Это совсем другое!
Есть много хороших статей по философии, теории и применении потоков, Хабр не стал исключением:
Ментальная модель потоков в Node.js
Много раз я сталкивался с необходимостью реализовывать свои потоки данных. И каждый раз я путался с кучей методов: write, push, _write, _read, с кучей событий - end, close, finish. В чем отличие write от _write?! Буквально почти все время, когда я имею дело с потоками у меня открыты доки Node.js - https://nodejs.org/api/stream.html.
Недавно, в моей статье про кастомный транспорт для ShadowSocks мне потребовался функционал передачи разных потоков данных по одному потоку (каналу)данных. Это задача мультиплексирования данных.
Я думаю, что эта задача является хорошей практикой для новичков в Node.js и программистов, любящих кодить всякие алгоритмы.
Во время программирования я встретился с несколькими "программистскими задачами" aka "подводными камнями", которые мне пришлось решить, и это было увлекательно, что и вылилось в данную статью.
Знаете это чувство, когда открываешь контроллер в Express проекте, чтобы поправить одну строчку логики, и видишь ЭТО? Бесконечная вложенность, проверки на существование полей, ручной парсинг ошибок от базы данных и, конечно же, его величество try-catch, который занимает 80% файла.
Я тоже через это проходил. В каждом новом микросервисе я копипастил одни и те же функции обработки ошибок. В одном проекте я ловил ошибки Mongoose через err.name === 'ValidationError', в другом — через instanceof. Где-то мы отдавали { error: "message" }, где-то { status: "fail", msg: "..." }.
В какой-то момент мне это надоело. Мне захотелось инструмент, который я могу просто подключить одной строкой, и он сам поймет, что "E11000" от Mongo — это 409 Conflict, а ошибка Zod — это 400 Bad Request. При этом я не хотел тянуть в проект тяжелые зависимости.
Так родилась библиотека ds-express-errors. Сегодня я расскажу, зачем я ее написал и почему она может сэкономить вам кучу нервов.
Node.js Stream предоставляют мощное средство для эффективной обработки большого обьема данных, например файлов с миллионами строк. Тем не менее их использование сопряжено с некоторыми трудностями, такими как не совсем прозрачное API и не тривиальная построчная обработка текстовых файлов. Чтобы разобраться в этом процессе, напишем несколько Transform стримов, изучим преобразование chunk и декодирование байт в строки.
Привет, Хабр! Меня зовут Вадим Королёв. Я руководитель команды разработки в X5 Tech. Очень люблю Next.js и решать проблемы, которые он приносит. С ним всегда происходит что-то интересное. Расскажу о причине утечки памяти в Node.js, которая оказалась глубже, чем можно было подумать.
В декабре, перед самым Новым годом, наше приложение начало вести себя так, будто вот-вот рухнет. С ростом пользователей посыпались алерты, вырос трафик, а из команды мониторинга сообщили, что поды в Kubernetes перезагружаются. Пока не падают, но выглядят плохо.
В этот момент я занимался архитектурой и оптимизацией Node.js в музыкальном стриминге. Открыл графики и увидел явный рост памяти, который уходил в пик и приводил к перезапуску подов. Так началась «классическая предновогодняя история». Next.js в Kubernetes внезапно начал есть память так, будто у него внутри чёрная дыра.
В компьютерных сетях (как и, в принципе, при любой передаче информации) есть и всегда будут существовать две задачи:
конфиденциальность (confidentiality) - я отправляю письмо Маше, это всем известно, но что в этом письме - можем прочитать только мы с Машей
анонимность (anonymity) - все могут прочитать содержимое письма, но от кого оно и куда - непонятно (понимаем только мы с Машей)
Соответственно, имея те или иные цели есть множество решений этих задач.
Итак, хорошо. Вот я подключаюсь к своему любимому серверу, и делаю я это по SSH. В целом - мне не так важно, что кто-то узнает, что именно Я подключаюсь именно к ЭТОМУ серверу, больше меня беспокоит, чтобы никто не прочитал мои пароли, мой трафик, и влез таким образом в мои дела. Т.е. в данном случае речь идёт о конфиденциальности. Если бы я делал это по старому доброму Telnet, то увы, здесь я полностью под вашей властью - и по IP меня можно вычислить, и все передаваемые данные в открытом виде.
Рано или поздно вы решите написать чат. Да, свой чат. И, возможно, вспомните про эту статью.
Изложу свое понимание, видение на построение системы любого чата, будь то чат между 2 пользователями, групповой чат (открыто и закрытого типа), чат с контактом в другом мессенджере, канал.
Все изложенное субъективно. Искал разные источники, анализировал другие чат-платформы. Надеюсь, будет полезно.
И так.
Что такое чат? Мы каждый день общаемся в чатах, чаты в разных приложениях похожи и не похожи одновременно.
Сделаем несколько обобщающих утверждений, на которые будем опираться далее.
- Чат - это хронологическая лента сообщений.
- Сообщение - некая единица контента (текст, файл, картинка, аудио, видео, стикер, оповещение, ...)
- также у сообщения есть дата-время создания сообщения.
- У сообщения всегда есть отправитель.
- В чат сообщения могут добавлять разные отправители (пользователи, боты, система).
- В чате есть участники. По сути - это подписчики, которые подписаны на получение новых сообщений в чате.
В этой статье я расскажу, как я для себя понимаю архитектуру десктоп-приложений — и почему в какой-то момент Rust перестал быть «языком, который я когда-нибудь посмотрю», и стал практичным решением.
Сразу оговорюсь: это не попытка доказать, что «Electron — зло», а Rust — «спаситель». Это скорее дневник архитектора, который хотел собрать удобный продукт и по дороге несколько раз наступил на грабли. Некоторые грабли были с подогревом.
Если вы работаете с BI‑системами, наверняка сталкивались с ситуацией, когда стандартных визуализаций не хватает. Хочется добавить свой график, который идеально подходит под задачи бизнеса.
В Modus BI такая возможность встроена в саму платформу — вы можете создавать свои плагины визуализаций. В этой статье мы шаг за шагом разберем, как собрать с нуля простой, но гибко настраиваемый прогресс‑бар. Руководство будет полезным для разработчиков, которые хотят самостоятельно создавать уникальные визуализации на базе Modus BI.
Разработка эффективных и безопасных приложений требует не только хорошо продуманного API, но и правильного выбора протокола передачи данных. Веб-приложения обычно используют текстовые форматы, такие как JSON или XML, но для высокопроизводительных систем, требующих минимальной задержки и небольшого объема передачи данных, может быть выгодно использовать бинарные протоколы.
В этой статье мы рассмотрим, как разработать собственный бинарный протокол для приложений на основе Node.js и WebSockets, добавить авторизацию с помощью JWT и изучим преимущества бинарного протокола по сравнению с другими форматами данных.
Всем привет! Меня зовут Алексей Золотых, я тимлид команды веб-редакторов в МойОфис. Недавно мы запустили новое шоу АйТир Лист. В каждом выпуске мы берём одну тему из мира разработки и раскладываем всё по тир-листу: от FAIL до GOD.
В пилотном выпуске мы с коллегой — Александром Коротаевым, фронтенд-гуру и энтузиастом креативного кодинга, прошлись по популярным опенсорс-инструментам для фронтенда: от тех, которые пора отпускать, до тех, что стали эталоном. Эта статья — расширенная версия выпуска. Под катом рассказываем, что у нас попало в FAIL, кто выжил на уровне MVP, кого мы поставили в SENIOR и кто, по нашему мнению, заслужил звание GOD.
Дисклеймер: мы с большим уважением относимся ко всем упомянутым проектам. Многие из них помогли индустрии вырасти. Но сегодня мы смотрим на них через призму вопроса: что бы мы посоветовали новичку или команде в 2025 году.
Дело было вечером... Сидел я, развлекался переписыванием фронта маркетплейса с React на Preact с Brotli и нативным CSS, чтобы протестировать максимальную оптимизацию. В попытках добиться предельной производительности и скорости решил провести эксперимент по переписыванию бэка на Rust с сжатием БД в Redis — но это совсем другая история. В общем, эксперименты привели меня к идее сделать SSR на Rust, и по бенчмаркам вышел на 95,000+ RPS на M4. Это уже само по себе неплохо, ниже расскажу подробнее.
Привет, Хабр.
Меня зовут Роман, я основатель Somazone — платформы для сохранения голосовой памяти о близких людях. Пользователь загружает аудиозаписи, мы клонируем голос и создаём AI-агента, с которым можно общаться.
Звучит просто, да?
Два месяца без выходных. Рефакторинги в три часа ночи, когда глаза уже не фокусируются, но ты точно знаешь, что если не починишь сейчас — утром будет хуже. Прод падает в субботу вечером, когда ты наконец-то решил поужинать с семьёй. Баги, которые воспроизводятся только на проде и только у одного пользователя из Владивостока (почему Владивосток? мы так и не поняли). WebSocket-соединения, которые умирают по непонятным причинам. FFmpeg, который выжирает всю память на сервере и роняет всё вокруг.
Это была весёлая поездка. И я хочу поделиться граблями, на которые мы наступили, чтобы вы могли их обойти. Или хотя бы посмеяться над нашими страданиями.
Написал бота на Google Gemini, который ведет себя как живой участник чата: у него есть характер, он помнит обиды (система репутации) и может послать, если вы это заслужили.
А еще он бесплатно расшифровывает голосовые (лучше Telegram Premium), понимает контекст переписки и обходит лимиты API через ротацию ключей. Под капотом — Node.js, никаких баз данных (только JSON) и чистый KISS-принцип.
Статья в формате шпаргалки, для тех кто понимает о чем тут написано и зачем оно надо. Я вчерашний был бы рад, если бы такая статья существовала. Тут максимально кратко изложен мой опыт, без воды и отступлений. По итогу получим полностью готовую инфраструктуру под свои проекты на n8n.
«Свой мини-мониторинг как сервис»: Python-демон, Next.js-дашборд и файловая архитектура без лишней инфраструктуры — как я сделал лёгкий self-hosted инструмент для наблюдения за маленькими проектами, который проверяет API, страницы, базы, очереди, TLS и Docker, пишет JSON-снапшоты, сам управляет процессами через встроенный supervisor, умеет следить за ресурсами, логами и сроком жизни сертификатов, собирает стримы производительности и при этом не требует ни базы данных, ни внешнего backend-сервера; просто ставишь рядом с приложением, настраиваешь конфиг, запускаешь демон и получаешь живой Next.js-дашборд, читающий отчёты.
У аббревиатуры BFF кроме Backend for Frontend есть и другая расшифровка — Best Friends Forever. И в контексте статьи это только отчасти шутка. Общение фронтенда и бэкенда не всегда происходит гладко (опустим тот факт, что существует множество мемов о противостоянии фронтендеров и бекендеров): клиент запрашивает данные, бэкенд отдаёт то, что запросили, но часто данных сильно больше, чем нужно, а это значит, что запрос будет возвращаться дольше, фронтенд будет отрисовываться тоже дольше и всё это отразится на опыте конечного пользователя.
А что если между фронтендом и бэкендом построить мостик, который распределит нагрузку и сделает всех дружелюбнее? Примерно в этом и состоит суть паттерна BBF, а в статье разберём подробнее: зачем его внедрять и какую роль он играет в масштабировании современных сервисов; как мы реализуем этот подход в рамках RUTUBE, какой профит он нам даёт; почему мы отказались от GraphQL; в чём отличия от API Gateway и как вообще проектировать такие сервисы.
Раньше у меня был сайт на Тильде. Стандартные шаблоны Тильды скучные, поэтому его делал дизайнер на zero-блоках. И каждый раз, когда надо было что-то на этом сайте добавить, приходилось дергать дизайнера в духе «Привет, добавь этот отзыв на сайт, пожалуйста».
Статьи добавлять поудобнее, но тоже не идеально. На том же Вордпрессе можно просто скопировать статью из гуглдока — и все, она вместе улетит вместе со всеми скриншотами. На Тильде надо тыкать каждую картинку руками, это бесит.
И вот я решил, что сайт устарел, его надо полностью переделать, а раз уж этим занимаюсь, можно и с Тильды заодно переехать. Например, на Вордпресс, к которому я как-то больше привык.
Стало интересно, а может ли Claude Code сделать сайт на Вордпрессе. С этим вопросом я к нему и пришел.
Claude сказал, что конечно может, но Вордпресс это скучно, и лучше делать сайт на Next.js + headless CMS. Я на тот момент даже не знал, что это такое. Ну так, слышал что на Next.js сайты делают — и все. Решил, что будет интересно разобраться и попробовать.
Спойлер — у нас (у меня и Claude Code) все получилось, сайт работает, мне нравится, даже трафик из SEO не просел.
От красивых демок к законченным проектам: что я понял за полтора года работы с Claude Code
Я не программист. Я гуманитарий, который научился использовать ИИ для создания рабочих приложений. Но если эта статья поможет и вам господа разработчики, то моя гуманитарная тушонка будет вопить от счастья.
В общем с чем я столкнулся. С тем, что с виду все в ИИ кодинге красиво, но по факту большой проект, например свою LMS ты не соберешь, ИИ сдохнет.
Проблема была не в промптах и не в архитектуре. Просто процесс разработки с ИИ постоянно буксовал: Claude выдавал код с API прошлого года, поиск нужной функции занимал по 15 минут, после третьего рефакторинга я терял нить и бросал проект, начинал терять что было сделано, сколько не суй ему to-do листы.
Потом я нашёл свой стек из MCP-серверов, которые действительно повысили эффективность в разных случаях от 2 до 8 раз, позволили экономить до 80% токенов, не терять контекст и совершать на 8 из 10 ошибок меньше.
Команда AI Dev Team разработала ChamelOn за 3 месяца как реальный заказ от клиента — крупного колл-центра с тысячами записей разговоров в день. Система уже работает в production на реальных клиентских проектах.
