Почти три года я в одиночку строил бэкенд-фреймворк поверх Next.js App Router. По дороге мой ишью закрыл создатель C#, синтаксис подсказал Copilot, а три пакета-адаптера пришлось убить. Рассказываю, что вышло и какие грабли собрал.
В данной статье рассматриваются примечательные ошибки при работе с Kafka, в том числе при использовании библиотеки KafkaJS, а также способы их устранения и методы увеличения производительности при публикации и обработки сообщений.
Предполагается, что читатель имеет базовое представление о Kafka (раздел "Общие термины" поможет освежить информацию) и функционале библиотеки KafkaJS.
В первой части разбираются аспекты, связанные с публикацией сообщений.
В первой части я рассказал, что такое капсула, откуда берётся эта идея и зачем вообще упаковывать опыт. Если вы её не читали — советую начать оттуда, иначе дальнейшее может быть непонятным.
В этой части перейдём от теории к практике. Я покажу, как мы создавали собственный капсульный фреймворк для микросервисов, что закладывали в его основу и как он стал ДНК наших проектов.
Всем привет! У многих из нас куплена максимальная подписка на Google AI Ultra - правда же? Да, она стоит не копейки - по акции первые 3 месяца обходятся в $124.99/мес, а потом ценник подрастает. Но мы заставим ее отработать каждый цент.
Очередная история из тяжкой жизни пользователей BSD или что делать, когда нужная программа ненавидит вашу операционную систему.
В помощь начинающему, продолжающему и заканчивающему автору.
Effect-фреймворк, который никого не может оставить равнодушным. Читая комментарии к другим постам, я заметил, что добрая часть хабра считает, что эффект это избыточно сложная и не особо нужная технология. В своей статье я обозначаю 10 причин, почему эту технологию стоит попробовать, даже если вы дико предвзятый разработчик, а также даю экскурс по базам фреймворка.
Текст в ленту: AI-агент пишет код. Другой AI-агент его ревьюит. Первый фиксит замечания. Ревьюер проверяет фикс. 9 параллельных субагентов, 18 000 токенов в минуту каждый, и вопрос, который никто не задаёт: а кто проверяет ревьюера?
Эта статья будет полезна в первую очередь студентам и начинающим разработчикам. В начале своего пути получения навыков проектирования и разработки программ каждому начинающему специалисту нужно на что-то опираться. Потом появится собственный опыт и собственные представления о том, как хорошо и как правильно. Я предлагаю познакомиться с идеями, которые могут стать такой первоначальной опорой.
Всем привет! Меня зовут Сергей, и у меня есть жгучее желание поделиться с вами концепцией разработки через капсулы. Если вы пока не понимаете, что это означает — это нормально. Термин новый, и его определение я как раз дам в этой статье. Я решил ввести понятие «капсула», потому что не нашёл существующего термина с нужным смыслом — пришлось придумать свой.
Статья будет посвящена в основном процессам разработки внутри одной абстрактной компании: их организации и улучшению с помощью нового термина «капсула». Я приведу примеры из своего опыта осознанного применения капсул в разных проектах и процессах. Но прежде чем дать определение самому термину и рассказать, как это работает, важно разобраться в причинах его появления. Поэтому начнём с самого главного — с опыта.
Эта статья не о том, что Puppeteer плохой инструмент. Puppeteer — отличный. И грамотный TLS-фингерпринтинг вынесет большинство защит. Но есть класс задач, где даже идеальный сетевой стек не спасает — потому что детект давно приземлился на уровень поведения рендеринг-движка. Разберём, как Cloudflare и Akamai палят вас через WebGL и Canvas, и почему "чистый" код больше не работает.
Один разработчик, один AI-напарник (Claude), ноль инвесторов. Рассказываю, как за 4 месяца я построил платформу автоматизации контент-маркетинга с 14 микросервисами, собственной очередью задач на SQLite вместо Redis, мультимодельным AI (MiniMax, YandexGPT, Replicate) и circuit breaker для автоматического fallback между провайдерами. Всё на одном сервере, всё через npm install.
В части 1 мы выяснили, что объекты в Heap не освобождаются сами по себе этим занимается Garbage Collector. Но как именно GC решает, что можно удалить? Если подумать, задача не такая очевидная: объект не нужен - понятие логическое, а GC работает с физическим графом ссылок.
Ответ в том, что GC не пытается угадать намерения программы. Он задаёт более простой вопрос: можно ли добраться до этого объекта из работающего кода? Если нельзя объект недостижим, и никакой код уже не сможет его использовать. Значит, память можно вернуть.
Алгоритм, реализующий эту логику, называется Mark and Sweep.
AI-агенты пишут код за секунды.
Через месяц этот код начинает ломаться — не из-за багов, а потому что мир вокруг него изменился.
Я столкнулся с этим, когда Express API, сгенерированный Claude, умер через 28 дней.
Перегенерация помогала… ровно до следующего обновления зависимостей.
В итоге я попытался решить не проблему кода, а проблему воспроизводимости AI-решений — и случайно пришёл к идее CI/CD для мира, где код пишет не человек, а модель.
В статье — про «гниение» AI-кода, Execution Plans, проверку смысла вместо проверки файлов и почему в большинстве случаев чинить можно без повторного вызова LLM.
Долгое время я использовал пакет request (теперь устаревший) для выполнения HTTP-запросов в Node.js. Затем в моду вошли промисы (promises), и я переключился на request-promise (также ныне устаревший). Затем я начал использовать axios и думал, что на этом все... но ошибался. История HTTP в Node.js продолжает эволюционировать, и это прекрасно.
Выполнение запросов HTTP - одна из самых распространенных задач в Node.js. Будь то обращение к API, получение данных из внешнего сервиса или разработка веб-скрейпера (scraper), важно знать, как делать это эффективно. Хорошая новость состоит в том, что начиная с Node.js 18 в качестве глобальной переменной доступен стандартный fetch(). Если вы использовали fetch() в браузере, то уже знаете, как использовать его на сервере. Никаких дополнительных зависимостей, никаких оберток, только тот же знакомый API, предоставляющий все необходимое для выполнения запросов HTTP современным способом в Node.js.
Последние пару лет изменили то, как пишется код. Copilot, Cursor, ChatGPT, Claude - все это генерирует вполне работающий JavaScript быстрее, чем успеваешь сформулировать задачу. Это удобно. Но у этого удобства есть обратная сторона, сгенерированный код работает правильно в смысле делает что просили, но не всегда правильно в смысле не течет по памяти и не роняет прод под нагрузкой.
Модели хорошо знают синтаксис и паттерны. Они значительно хуже разбираются в том, что происходит под капотом конкретного движка. Closure, захватывающий лишние данные. Event listener, который никогда не снимается. Объект, который непреднамеренно продлевает жизнь половине DOM дерева. Все это - настоящие ошибки, которые реально встречаются в проде и ни один линтер их не поймает.
Чтобы замечать такие вещи при ревью, нужно понимать, как именно V8 хранит объекты и когда решает их удалить. Это не академическое знание - это инструмент, который меняет то, на что смотришь в коде.
Эта серия состоит из трех частей. Первая - про то, как V8 вообще организует память, что такое Stack и Heap, чем они отличаются и что такое pointer. Вторая - про сборщик мусора, как он определяет, что живо, а что нет и как делает это, не останавливая программу надолго. Третья - практическое применение, откуда берутся утечки памяти, как их искать и как писать код, который не создает лишней работы для GC.
В прошлой части я остановился на том что собрал свое приложение, наладил работу и залил в google play. Здесь будет не то чтобы полноценный гайд, скорее тот путь что я прошел и попытка получить опыт в написании статьи
Представим ситуацию: идет тяжёлый спринт, вы выполнили кучу задач, написали тонну нового функционала, готовитесь к релизу и вдруг обнаруживайте, что часть фич перестала работать! Идёте разбираться и обнаруживайте, что оказывается бэкендер Вася в последний момент решил переименовать поля в json-е, а вам об этом не сказал!
Ситуация образная, но позволяет быстро обрисовать одну из болей во время разработки. В этой статье я бы хотел рассказать об одном из вариантов её решения в коде с помощью подхода Единого источника истины(Single source of truth).
Вы когда-нибудь писали плагин для semantic-release? А хотели бы? Если да, то идем дальше. Расскажу, как это сделать и самое главное это не сложно. А в конце Вас ждет репозиторий, который вам поможет начать проект.
Привет! Меня зовут Алексей, я работаю в команде Авторизации Банки.ру. Сегодня хочу познакомить Вас с тем, как можно написать свой плагин для semantic-release.
Многие проекты рано или поздно утыкаются в «потолок» стандартного поиска. Обычный LIKE перестает справляться, когда данных становится больше 100 тысяч строк, а пользователи начинают ошибаться в каждом втором слове. Типовым решением в такой ситуации считается внедрение Elasticsearch или Meilisearch.
Но внешние движки — это всегда «налог» на инфраструктуру: лишняя память, задержки на сетевой хоп и, самое главное, головная боль с синхронизацией данных. В этой статье мы разберем, как выжать из PostgreSQL производительность специализированного поисковика, используя Node.js как оркестратор параллельных стратегий и механизм AbortSignal для предотвращения лишней нагрузки на БД. Разбираем внутреннее устройство SDK pg-smart-search.
Архитектура большинства гарант-сервисов неразрывно связана с рисками: ошибками, возможностью мошенничества, сложными и непрозрачными схемами. Ее можно заменить аналогом с принципиально другим уровнем безопасности — системой по модели эскроу. В ней нет необходимости доверять человеку, только математике.
Показываем, как реализовать технические гарантии безопасности сделок с помощью MultiSig-кошельков, Node.js, smart-контрактов, TronWeb v5. Разбираем код и логику проектирования P2P-платформы, которая не может украсть деньги пользователя (даже если захочет) 👇
