Наконец таки статья о том как я облажался. Точнее — как облажалась команда, но ответственность все равно моя. Это разбор конкретной ошибки, которая стоила реальных денег.
Что делать, если после статьи на Хабре количество пользователей выросло вдвое (даже если их стало всего десять)? В этой статье я пройду путь от "крепкого" монолита до взрослой архитектуры с разделением на API, Web и Auth. Поделюсь опытом создания изолированного тестового контура и разберу, почему модная связка Bun + Vercel на реальном продакшене может стоить вам нескольких седых волос и часов дебага.
Бесплатный агент с 100K+ звёзд на GitHub, который реально выполняет задачи — не просто отвечает текстом.
Детскую игру на листочке переводим в браузер с помощью ИИ. Повайбкодим и испытаем на себе, на сколько это возможно, чтобы за тебя писал код ИИ на самом простом примере.
Всем привет.
В этой статье мы продолжим дорабатывать базовые инструменты для работы с инвестициями и начнем изучать индикаторы.
Здравствуйте, товарищи! Недавно мне понадобилось сделать простой бэкенд для онлайн-песочницы в своем open source проекте. Сейчас для таких задач есть много конструкторов и low-code решений, типа n8n. Но я "по старинке" решил взять serverless с лямбдами, поскольку в позапрошлой компании плотно работал с этим стеком.
Вспоминая тему serverless, я обнаружил, что в русскоязычном пространстве, и на Хабре в частности, почти не освещена одна полезная техника. Пришло время исправить ситуацию и заполнить пробел данной статьей!
В JavaScript есть уникальная особенность, переменную или функцию можно использовать по коду выше, её объявление...
За 8 дней частичной занятости я собрал RAG-систему на NestJS + PostgreSQL (pgvector), которая обрабатывает ~11 000 чанков документов.
Первая версия отвечала около 4 минут, после оптимизации - 40–60 секунд.
Главный вывод: RAG - это не «векторный поиск + LLM», а в первую очередь подготовка данных, фильтрация контекста и аккуратная работа с промптами.
Кратко о том, почему я не использую фреймворки, зачем пишу всё с нуля и к чему это привело.
Я написал полноценный SDK для web-приложений как концепт альтернативной ветви развития, если бы web-индустрия пошла по пути игровых движков.
У вас есть продакшен-сервер. Он спокойно работает часами. А потом внезапно падает. Без предупреждения, без graceful-деградации. Просто мёртв.
Виновник? Одна строчка кода, которая выглядит совершенно безобидно...
В этой статье я подробно опишу 5 стадий принятия неизбежного уровней оптимизации. В качестве примера рассмотрим, как я пытался оптимизировать функцию для инструмента командной строки, который я сам и написал I (monorepo-hash).
Примечание
Я не настаиваю на том, что изложенное здесь — 5 священных заповедей инженерии производительноcти, а также не утверждаю, что приведённые здесь приёмы точно соответствуют каким-либо «карьерным уровням». Их можно сравнить просто с вешками на пути.
Это всего лишь тот путь, который проделал я сам. Есть в нём доля эго, пару раз я свернул не туда, бывали и случаи «я знаю, как тут срезать дорогу», за которыми сразу следовало раскаяние.
Также отмечу, что значительную часть этого CLI я написал при подспорье ИИ-моделей. Считайте, что это лёгкий способ подмечать ошибки и находить, что можно оптимизировать.
Кликбейтный заголовок? Что ж, даже, если так — вы же открыли статью, значит, он сработал :)
В предыдущих статьях мы подробно рассмотрели воркеры в JavaScript. В этой уделим внимание похожему на них механизму, созданному для параллельных вычислений. В модуле child_process, определены функции для запуска других программ как дочерних процессов.
Если воркеры запускают отдельный поток внутри одного процесса в котором работает программа, то модуль child_process порождает новый процесс в ОС, что является гораздо более тяжёлой операцией. Архитектура многопоточки в JavaScript, такова что потоки максимально изолированы друг от друга и не имеют общей памяти. Тем не менее есть масса способов обойти это ограничение если очень нужно и в своих статьях я приводил подобные примеры. С процессами всё иначе. Они жёстко изолированы, один от другого и пробить этот барьер способов нет.
Если говорить простым языком то воркер, это как нанять ещё одного гребца на Вашу галеру. С ним можно быстро и легко общаться, ведь вы буквально находитесь на одном суде (процессе) и даже на прямую без посредников обмениваться сообщениями (SharedArrayBuffer). Но вот если он зарулит на скалы, то и потоните вы тоже вместе. Дочерний процесс же это как построить новую галеру с другим капитаном и экипажем. Дорого, долго, обменивать данными можно только через медленные записки (IPC), зато он полностью независим от Вас, а Вы от него.
Проверенные в бою паттерны для проектов на React + TypeScript: фабрики ключей запросов, server actions, права доступа через CASL и многое другое.
Один из наших проектов нужно было перенести на Kotlin, чтобы включить его в общую экосистему клиента и упростить поддержку. Мы должны были курировать процесс и следить за итоговой реализацией, в которой заказчик решил использовать ИИ.
В этой статье рассказываем о реальных возможностях нейронки для миграции бэкенда и про то, с чем лучше к ней не обращаться — чтобы не тратить ни время, ни нервы.
Всем привет.
В этой части мы познакомимся с базовыми понятиями, необходимыми для понимания процесса инвестирования и перейдем к практическому применению, где подключим API ТБанка, настроем отображение портфеля и сделаем первые заявки на покупку и продажу.
Дома у меня лежали несколько старых Android-устройств. Они работают, но давно не используются и просто лежат без дела.
Я стал думать, как их можно использовать. Хотелось чего-то простого и полезного: показывать информацию и иногда вводить данные. Ничего сложного, просто что-то, что реально будет использоваться. Так появилась идея превратить их в дашборды.
Потом я понял, что для этого нужна веб-часть и мобильное приложение. Сделал веб-приложение на Analog и Android-клиент на Ionic Framework. В разработке активно помогал AI-ассистент из Qoder — он сильно ускорял работу и решал много задач сам.
Проект пока ещё в процессе, но я решил написать о нём пост. Возможно, кому-то пригодятся мои наработки.
Почти каждый день в ленте я вижу новости про очередного "революционного" 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 и декодирование байт в строки.
