Детскую игру на листочке переводим в браузер с помощью ИИ. Повайбкодим и испытаем на себе, на сколько это возможно, чтобы за тебя писал код ИИ на самом простом примере.
Всем привет.
В этой статье мы продолжим дорабатывать базовые инструменты для работы с инвестициями и начнем изучать индикаторы.
Здравствуйте, товарищи! Недавно мне понадобилось сделать простой бэкенд для онлайн-песочницы в своем 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 и декодирование байт в строки.
Привет, Хабр! Меня зовут Вадим Королёв. Я руководитель команды разработки в X5 Tech. Очень люблю Next.js и решать проблемы, которые он приносит. С ним всегда происходит что-то интересное. Расскажу о причине утечки памяти в Node.js, которая оказалась глубже, чем можно было подумать.
В декабре, перед самым Новым годом, наше приложение начало вести себя так, будто вот-вот рухнет. С ростом пользователей посыпались алерты, вырос трафик, а из команды мониторинга сообщили, что поды в Kubernetes перезагружаются. Пока не падают, но выглядят плохо.
В этот момент я занимался архитектурой и оптимизацией Node.js в музыкальном стриминге. Открыл графики и увидел явный рост памяти, который уходил в пик и приводил к перезапуску подов. Так началась «классическая предновогодняя история». Next.js в Kubernetes внезапно начал есть память так, будто у него внутри чёрная дыра.
В компьютерных сетях (как и, в принципе, при любой передаче информации) есть и всегда будут существовать две задачи:
конфиденциальность (confidentiality) - я отправляю письмо Маше, это всем известно, но что в этом письме - можем прочитать только мы с Машей
анонимность (anonymity) - все могут прочитать содержимое письма, но от кого оно и куда - непонятно (понимаем только мы с Машей)
Соответственно, имея те или иные цели есть множество решений этих задач.
Итак, хорошо. Вот я подключаюсь к своему любимому серверу, и делаю я это по SSH. В целом - мне не так важно, что кто-то узнает, что именно Я подключаюсь именно к ЭТОМУ серверу, больше меня беспокоит, чтобы никто не прочитал мои пароли, мой трафик, и влез таким образом в мои дела. Т.е. в данном случае речь идёт о конфиденциальности. Если бы я делал это по старому доброму Telnet, то увы, здесь я полностью под вашей властью - и по IP меня можно вычислить, и все передаваемые данные в открытом виде.
Рано или поздно вы решите написать чат. Да, свой чат. И, возможно, вспомните про эту статью.
Изложу свое понимание, видение на построение системы любого чата, будь то чат между 2 пользователями, групповой чат (открыто и закрытого типа), чат с контактом в другом мессенджере, канал.
Все изложенное субъективно. Искал разные источники, анализировал другие чат-платформы. Надеюсь, будет полезно.
И так.
Что такое чат? Мы каждый день общаемся в чатах, чаты в разных приложениях похожи и не похожи одновременно.
Сделаем несколько обобщающих утверждений, на которые будем опираться далее.
- Чат - это хронологическая лента сообщений.
- Сообщение - некая единица контента (текст, файл, картинка, аудио, видео, стикер, оповещение, ...)
- также у сообщения есть дата-время создания сообщения.
- У сообщения всегда есть отправитель.
- В чат сообщения могут добавлять разные отправители (пользователи, боты, система).
- В чате есть участники. По сути - это подписчики, которые подписаны на получение новых сообщений в чате.
