Как сделать RAG-чат для сайта, который не выдумывает цены: пять решений из моего бота

С июня я делаю AI-чат для сайтов, который не выдумывает цены и не соглашается с клиентом во всём подряд. К пяти решениям из статьи я пришёл через ошибки.

Прогрессивный JavaScript-фреймворк

С июня я делаю AI-чат для сайтов, который не выдумывает цены и не соглашается с клиентом во всём подряд. К пяти решениям из статьи я пришёл через ошибки.

Где в записи сессии оказываются чужие персональные данные, даже если пользователь ничего не вводил, почему маскировать их нужно ещё в браузере и какой режим маскирования безопаснее по умолчанию.
Привет! Я Паша, участвую в разработке сервиса записи сессий Broux. В этой статье я расскажу, как мы добиваемся соответствия продукта российским законам с точки зрения персональных данных, что в нашей нише не так уж просто. И я не юрист: юридическая часть ниже описывает, как мы это поняли. Проверяйте со своим юристом.
Первый вопрос, который задают про запись сессий: «а вы видите, что я ввожу в поле?». Честный ответ: технически скрипт записи видит всё, что видит браузер. Вопрос только в том, что он отправит на сервер.
Ниже о том, где обычно утекает лишнее, как с этим работать и при чём здесь 152-ФЗ.
Сделал калькулятор налога для самозанятых на Laravel + Inertia + Vue с SSR и выложил на обычный shared-хостинг. Сам калькулятор написал за пару вечеров. Всё остальное время ушло на то, чтобы поисковики увидели сайт так же, как браузер.
За два месяца: SSR-демон падал с EPERM, порт оказывался занят «через раз», главная месяц уходила в кэш пустой страницей, а проверка SSR в CI была зелёной, потому что не могла упасть в принципе. Плюс месяц блокировки хостером, о которой я не знал, и фильтр «малоценных страниц» от Яндекса.
Разбираю грабли по порядку — может, кому-то это сэкономит месяц.

Обсудим: composable, sharedComposable, pinia. Попробуем понять: а нужно ли вообще управлять состоянием? что значит управлять? кто должен управлять? и Какие существуют подводные камни в управлении состоянием. Методы и идеи их преодоления. Готовые библиотеки или примеры кода для использования.
Контекст статьи — PWA, в других контекстах тоже будет работать, но это не точно.
В статье будет критика Pinia. Если ты любишь этот инструмент, и не готов к конструктивной критике — лучше не читать, либо давай подискутируем в комментах. Я открыт к диалогу. Если ты уже думаешь о замене или уже ищешь её — это для тебя.

Есть Vue DevTools с галкой «Highlight updates». Есть react-scan в соседней экосистеме. Оба показывают одно и то же: вот этот компонент перерисовался.
Проблема в том, что знание «перерисовался» само по себе бесполезно. Ты и так видишь, что страница дёргается. Вопрос всегда другой: что именно изменилось. Какой проп, какой реф, какое поле стора. Без этого ты сидишь и комментируешь куски шаблона, пока не найдёшь виновника методом половинного деления.
В React иначе и нельзя: реактивность там на уровне «перерисовался компонент», причину приходится реконструировать диффом пропсов. А во Vue реактивность точечная — фреймворк знает, какая именно зависимость дёрнула рендер.
И он её отдаёт.

Хотя… не изобрел, а собрал. Я собрал свой MVP Simple Data Editor, так как хотел простое и миниатюрное решение, работающее везде, где есть браузер и чтобы при этом не происходило никаких обращений во вне. Но не только. Основная идея в реализации возможности представления одной и той же информации, но в разных форматах: текстовом, табличном ну а в перспективе и в графическом.

Два фронтенда, один C#-мозг — что действительно различается, что похоже сильнее, чем принято считать, и что говорит рынок труда.
До 2019 года моим фронтендом были семантический HTML и CSS. Div'ы, классы, разметка, которую я мог удержать в голове. Я был бэкенд-разработчиком, и меня это вполне устраивало.
Потом случились две вещи. Компания попросила меня залезть в проект на Vue, а Microsoft выпустила Blazor. В следующие годы я плотно поработал с обоими: с Vue — у двух работодателей, с Blazor — на личном проекте, который до сих пор работает.
Это не статья с бенчмарками. Это про то, как эти две технологии ощущаются, когда мышление у тебя C#-овое.

История о том, как одна команда разработала сложную форму для систем хранения данных. Делимся ценным опытом, о том как имея три разных сценария и один интерфейс, мы избежали дублирования состояния и хаоса в обработчиках.

Начну со спорного решения: я храню в базе готовый HTML с Tailwind-классами.
Не Markdown, не JSON-схему блоков, а буквально это:

Привет, Хабр!
Представляю твоему вниманию AcroTab — приложение, которое должно быть у каждого уважающего себя гитариста (у меня, например, есть).
кг/ам tl;dr: https://acrotab.org

Есть готовый сайт, написанный на Laravel + Vue. Руководство попросило сделать его мультиязычным. Зная, что для Laravel “есть все”, я сходу без чтения документации назвал кратчайший срок. Но когда зашел на страничку Vue I18n то понял, что ошибся. Мультиязычность Vue происходит на клиенте, файлы переводов по формату отличаются от файлов Blade. Другими словами, если брать все «из коробки», то переводы придется дублировать и держать в разных местах, js приложение раздуется от подключения плагина I18n и к тому же на клиента придется загружать словари переводов... очевидно же, что надо делать переводы на сервере, то есть все хорошо, но без Vue I18n.
ТЗ формулировалось так:

Всем привет! Сегодня я расскажу вам свой путь к написанию демона для работы с видеокартами (пока только с Nvidia).
Для начала немного предысториио себе, для меня линукс не новинка, но и не та ОС, с которой я долго взаимодействовал. Я разработчик с коммерческим стажем в финтехе, и с линуксом знаком был ранее только как с очень практичной ОС для серверов. И вот однажды я стал полноценным «линуксоидом», решив перейти к более практичной для кастомизации и гибкой настройки ОС. Выбрал я дистрибутив на основе Арча, а именно CachyOS, как и многие (наверное) я люблю при наличии свободного времени поиграть в игры.

Состояние во Vue обновилось, а интерфейс остался прежним — и начинается охота на watch, nextTick и принудительный ререндер. Разберём, где именно рвётся реактивная связь, почему это происходит и как находить такие проблемы до того, как вокруг них вырастут костыли.

Современные веб-приложения содержат сложную бизнес-логику, которая ранее традиционно располагалась на бэкенде. С ростом сложности возникает необходимость в эффективном управлении зависимостями для поддержания тестируемости, модульности и слабого зацепления этих модулей в приложении. Принцип Инверсии зависимостей (Dependency Inversion, DIP) и его реализация в лице механизма Внедрения зависимостей (Dependency Injection, DI) становится ключевым инструментом для решения этих задач.

Тема хранения токенов — одна из самых больных в авторизации. Многие, не до конца понимая, как авторизация должна работать, кладут оба токена в cookie или — что ещё хуже — в localStorage. В этой статье мы соберём схему, в которой access‑token живёт в памяти приложения, refresh‑token — в HttpOnly‑cookie, а фронтенд сам восстанавливает сессию после перезагрузки страницы и незаметно обновляет протухший access.
Бекенд — на Go, фронтенд — на Vue 3 (Vuex + vue‑router + axios), но концепция так же применима к React и Next.js. Верстку и стили оставляю за кадром — в статье только логика авторизации.

Реальный кейс с nested grids в GridStack:
— почему подход на addGrid() привёл к ручной синхронизации DnD, проблемам с lifecycle и множеству фиксов;
— как переход на subGridOpts упростил архитектуру и сделал поведение стабильным.
Часть 1. Как я делаю backend для браузерной игры три в ряд: server-driven персонажи и способности, общий контракт клиента и сервера, версионирование контента, транзакции, идемпотентность и админка.

Привет, Хабр! Меня зовут Эрнест Гилязов, я тимлид группы разработки интерфейсов Рунити. В этой статье расскажу, как мы переносим на новый стек проект Рег.ру, кодовой базе которого исполняется 20 лет, и почему в итоге Nuxt-приложение само раздает шапку и футер в легаси-монолит через обычный JSON-эндпоинт.

Как я сделал браузерную 3D-игру на Three.js и Vue: система аномалий, GLB-сцена, PS1-рендеринг и оптимизация под слабые устройства.

Тридцать лет я собирался написать игру, а потом за десять рабочих сессий довёл до продакшена браузерную Hexnome: 3D-поле, одиночный режим, онлайн-мультиплеер и серверный журнал команд. Получилось 245 промптов и 99 коммитов в основной ветке. Ещё 30 коммитов пришлось выбросить, когда первая архитектура мультиплеера оказалась «играбельной, но ненадёжной». Рассказываю, что именно ускорил AI — и какие решения он за меня не принял.