Чтобы проверить небольшую правку в микрофронтенде вместе с настоящим хостом, мне приходилось либо ждать полный CD-пайплайн, либо локально конфигурировать и поднимать хост, разводить порты, прописывать домены. Оба варианта меня не устраивали.
В статье рассказываю, как оставил всё окружение в Kubernetes, а локальную сборку начал синхронизировать прямо в pod через DevSpace.
Представьте типичную ситуацию. У вас есть сервер на каком-то языке (сейчас какой именно для нас не важно, но допустим, это Rust). И в нём по каким-то причинам нужно исполнить JavaScript-код. Например, фронтенд написан на React, и вы хотите рендерить HTML на сервере (SSR). Или есть бизнес-логика, которая проще пишется на JS. Или библиотека, которая существует только в npm, и переписывать её на Rust нет ни сил, ни желания. Таких примеров можно привести множество: markdown, dompurify, highlight.js и т.д.
Огромное количество разработчиков мечтают создать свой проект, который будет приносить им доход поверх зарплаты на основной работе.
Начинается все с большого энтузиазма, грёз о том, какой классный и полезный будет его продукт. Потом формирование основного функционала, планирование разработки, рисование архитектуры и инфраструктуры, создание репозитория и, конечно же, разработка. У кого-то это длится несколько недель, у кого-то годами. И вот когда заветный проект готов, назначается так называемая дата релиза. Проект уже запущен локально или в стейдж окружении, создатель его протестировал, все работает хорошо, возможно даже дал попользоваться нескольким знакомым, которые нехотя прокликали и сказали, какое же классное и полезное приложение.
В дату релиза проект деплоится в прод. Но почему-то там все также один пользователь — сам создатель.
Ты вроде и понимаешь почему, логично ведь, что без рекламы и маркетинга пользователей не будет, но пока пишешь код - делаешь, что умеешь, а маркетинг это что-то неизвестное и непонятно. На самом деле маркетингом нужно было заниматься с первого дня, даже раньше, чем пришла идея.Но пока вернемся к нашему наивному разработчику.
Он сидит, смотрит на свой проект и прям чувствует, как энтузиазм сходит на нет. Приходит понимание, что нужно как-то привлекать пользователей, но как? На самом деле на этом этапе уже многие так и остаются, и проект просто попадает на так называемое «кладбище пет-проектов».
Но если же нет, то этому разработчику приходится становиться в абсолютно диаметрально противоположное амплуа, к которому он не привык. Ибо с приходом нейросетей разработка стала менее ценной, проектов больше, конкуренция за пользователя выше, соответственно маркетинг сложнее.
На экране всё выглядело почти живым. Модель за несколько минут собрала страницу с карточками, статусами и бейджами. Казалось, мне можно закинуть ногу на ногу и допить кофе. Но затем код дошел до ревью. Под аккуратным интерфейсом скрывались styled.div, HEX-цвета и пропсы, которых в нашей дизайн-системе никогда не существовало. Получилось то самое лабораторное чудовище, которое хрипло дышит, но в проекте жить не может.
Поэтому я поставил эксперимент с одной фронтенд-задачей, одной моделью и четырьмя одинаковыми копиями проекта. В первом случае оставил агента без подсказок, во втором дал ему скилл с правилами проекта, в третьем подключил MCP с документацией дизайн-системы, а в четвертом совместил всё сразу. Мне хотелось узнать, какая комбинация превратит генерацию кода в эликсир скорости, а какая породит еще одно чудовище, не способное пережить встречу с typecheck и build.
Разработчик приложил к тикету свой токен целиком — чтобы ошибку авторизации можно было воспроизвести. Ошибку починили, тикет закрыли, токен так и остался в задаче, которую видит вся команда и подрядчики.
Токен выглядит как шифротекст: длинная строка из букв, цифр и дефисов, глазами не читается. Отсюда и распространённое допущение — раз не читается, значит, закрыто, и внутрь можно положить что угодно полезное.
На самом деле это base64. Читается одной командой, ключ для этого не нужен, и содержимое видно всем, через кого проходит токен: браузеру пользователя, расширениям в нём, промежуточным прокси, системам логирования.
Всем привет! Меня зовут Евгений, я фронтенд‑инженер с большой экспертизой в разработке современных веб‑приложений. Сегодня хочу рассказать про свой очередной open‑source проект для построения веб‑приложений на основе Angular.
За последние годы я провел не мало успешных экспериментов с высокопроизводительными веб‑интерфейсами, что дало мне четкое понимание структуры и архитектуру для проекта, о котором пойдет дальше речь.
Итак, встречайте Centrifugal. Посмотрите официальный сайт проекта, там очень много крутых примеров использования!
Проект разрабатывался изначально, чтобы создать набор высокопроизводительных, гибких инструментов и компонентов для построения веб‑приложений. Но на одной из итераций разработки я решил обеспечить поддержку для построения All‑in‑One интерфейсов, то есть добавил режим standalone‑приложений с отображением собственной виртуальной клавиатуры, которую можно полностью кастомизировать. Тем самым обеспечил полноценную поддержку создания пользовательских интерфейсов, например, под киоски самообслуживания и тому подобное.
Возьмём типичный отчёт воронки интернет‑магазина: «Каталог → Товар → Корзина → Оформление заказа → Оплата». До последнего шага дошло 38% сессий, остальные 62% потерялись между «Оформлением» и «Оплатой». Для продуктовой аналитики эти 62% — повод для гипотезы «форма оформления слишком длинная» и задачи на редизайн. Для команды разработки те же 62% — конкретная JavaScript ошибка. Но пока данные о конверсии и данные об ошибках лежат в разных системах, выбор между ними происходит наугад. Как перестать «угадывать» почему отвалились пользователи и какую в этом роль играет Customer Journey Map разберу в статье.
Ставил утилиту по инструкции с сайта проекта: блок с командой, кнопка «скопировать», вставка в терминал. Перед Enter посмотрел на строку — вставилось не то, что было в блоке.
Проблема в том, что сайт полностью контролирует, что окажется в буфере обмена. Показать он может одно, положить — другое. И у страницы есть несколько способов сделать это так, что при вставке вы ничего не заметите.
Полгода назад я начал писать веб-лист персонажа для D&D 5e, и почти весь код в нём пишет Claude Code. В какой-то момент лимиты подписки стали заканчиваться к обеду, и я распарсил транскрипты сессий, чтобы понять, куда уходят токены. Выяснилось: ответы модели — полпроцента расхода, а две трети съели 22 длинные сессии, в которых контекст рос на каждом шагу. В статье — скрипт замера на тридцать строк, разбор того, почему одна длинная сессия дороже пяти коротких, и восемь приёмов, которые я после этого внедрил: лимит сессии в Stop-хуке, карта кода вместо разведки грепом, запрет на повторное чтение файлов, вынос браузерных проверок в сабагента и рутины — на дешёвые модели.
Мы представляем Claude Fable 5.1 и Claude Mythos 5.1. Это самые продвинутые в мире модели для программирования и интеллектуальной работы, а их исследовательские возможности уже дают первое представление о том, как ИИ-модели смогут способствовать научному прогрессу.
Claude Fable 5.1 и Claude Mythos 5.1 это одна и та же модель, но с разным уровнем защитных ограничений. Fable 5.1 доступна всем пользователям, тогда как Mythos 5.1 предоставляется только в рамках наших программ доверенного доступа. Её механизмы защиты специально настроены для работы в сфере кибербезопасности и наук о жизни.
Помимо роста возможностей, в Fable 5.1 мы учли важную обратную связь от клиентов, связанную со стоимостью, хранением данных и защитными механизмами.
Роскомнадзор наделен полномочиями по проведению контрольного (надзорного) мероприятия по контролю без взаимодействия с контролируемым лицом. Это означает, что Роскомнадзор на основании полученных заданий делает выборку нескольких сайтов и осуществляет в отношении них проверку. При этом владельцев сайтов (операторов персональных данных) никак не уведомляет. Если на сайте нет нарушений в области персональных данных, то вы и не узнаете, что сайт проверялся. А если нарушения будут найдены, то получите от Роскомнадзора письмо «требования об исполнении законодательства о персональных данных». В соответствии с законодательством у владельца сайта есть 10 рабочих дней с момента получения требования, чтобы устранить нарушения и уведомить о принятых мерах Роскомнадзор.
Роскомнадзор достаточно лоялен к бизнесу. Выявив нарушения, он не сразу составляет протокол об административном правонарушении, а дает время адаптироваться (10 дней на исправление). Только в том случае, если требования органа не будут выполнены, то бизнес будет привлечен к административной ответственности. Поэтому главное правило – если получили такое письмо от Роскомнадзора, то ни в коем случае не игнорируем.
Далее я покажу и расскажу, как на практике выглядят требования Роскомнадзора. А также по моим рекомендациям сможете сделать аудит своего сайта на проверку соблюдения закона о персональных данных.
_________________________________
Очень важно всегда иметь доступ к официальной электронной почте, которую вы указываете для коммуникации с надзорами органами. Именно туда может прийти вот такое письмо, в котором будут перечислены все нарушения на сайте.
Фраза «завтра в 18:00» кажется простой, пока сервер и пользователь не оказываются по разные стороны полуночи. В Doday я сделал быстрое добавление задач из одной строки и обнаружил, что программа считает «сегодня» по UTC. Из-за этого дата сдвигалась, а указанное время могло остаться в названии.
В статье покажу, как передать часовой пояс из браузера, в каком порядке собирать локальную дату и время, зачем фиксировать текущее время в тестах и какие ещё ошибки нашлись у фраз «через месяц», «каждый понедельник» и меток с @.
Одна и та же страница, три варианта, медиана трёх мобильных прогонов Lighthouse 12: без счётчика — 99 баллов и TBT 0 мс, со штатным сниппетом Яндекс.Метрики — 70 баллов и 2289 мс. Самый популярный совет «выключите вебвизор в init» не даёт почти ничего: те же 70 баллов и 2196 мс.
Как отделить счётчик от остального шума на A/B-стенде из локальных копий страницы, почему сам Lighthouse показывает виновника неправильно (third-party-summary рисует 70 мс при TBT больше двух секунд, потому что вся работа падает в bootup-time и остаётся неатрибутированной) и как вернуть 99 баллов, не потеряв данные, ради которых счётчик и ставился.
Прочтя недавний перевод про запаковку БД в exe, решил рассказать об идеи, которую реализовал лет 6 назад в своем домашнем проекте. Сам проект недоделал, но речь в статье об архитектуре файлов и их запаковке.
Привет, Хабр! Меня зовут Завур, я фронтенд-разработчик в Selectel. Каждый день я работаю в привычной многим среде разработки VS Code. Однако в личных проектах, которые создаю для исследования новых инструментов и методов написания кода, часто использую Cursor.
Он классно ускоряет разработку, но мне давно хотелось проверить: способен ли искусственный интеллект самостоятельно воплотить сырую идею в полноценное рабочее приложение? Иногда хочется быстро увидеть прототип в действии, чтобы решить, стоит ли развивать проект дальше. Именно поэтому я не смог пройти мимо многообещающего сервиса Devin.
Давайте посмотрим, как на практике выглядит реализация идеи с помощью Devin, и попробуем разобраться, действительно ли перед нами потенциальный конкурент Cursor.
Почему исправные 20-мс аудиопакеты всё равно превращались в щелчки? В БОЛТУНе каждый пакет запускался как отдельный AudioBufferSourceNode — до 50 мини-плееров в секунду на одного говорящего. Мы заменили это расписание одним непрерывным AudioWorklet с кольцевым буфером и проверили новую схему тестами.
Совет про токен в адресе страницы кочует из статьи в статью в одной и той же формулировке: не кладите его в URL, иначе он уедет в заголовке Referer на все сторонние ресурсы, которые подключает ваша страница.
Совет правильный по выводу и неправильный по обоснованию. Через Referer он давно никуда не уезжает. А вот сам токен из URL утекает — просто в других местах, и там его обычно никто не ищет.
410 вариантов писем, сотня микросервисов и до 15 файлов, которые приходилось править ради одной нотификации. Добавление письма превратилось в квест: создай компонент, подключи, опиши параметры, зарегистрируй — и молись, что ничего не забыл.
Мы устали и автоматизировали это. Теперь описываем контракт письма в OpenAPI, а CLI генерирует весь boilerplate — от NestJS-артефактов до React-компонента с типизированными пропсами. Часы работы сжались до минут.
Меня зовут Денис, я фронтенд-разработчик в ЮMoney. В этой статье расскажу, почему мы пришли к кодогенерации, как устроили процесс и что в нём изменилось для разработчиков, дизайнеров и тестировщиков. Материал будет полезен тем, кто работает с React, NestJS или TypeScript и хочет перестать писать однотипный код вручную. Особенно если поддержка UI-компонентов и API-слоя отнимает время, которое лучше потратить на реальную логику.
Когда 180 тестов каждый раз проходят форму входа, авторизация начинает съедать десятки минут и ломаться на рейт‑лимитах, SSO и редиректах. Разберём рабочую схему: получить токен по API, закэшировать состояние и передать его браузеру до старта приложения.
Большинство backend‑проектов начинаются предсказуемо: HTTP‑запрос, бизнес‑логика, SQL и ответ клиенту. Но что изменится, если вместо очередного CRUD нужно одновременно искать собеседников, поддерживать долгоживущие WebSocket‑соединения и не допускать двойного matchmaking?
В этой статье я расскажу, как появился Fluent Swap, почему его первая версия работает без базы данных и как очередь в памяти одного Go‑процесса постепенно подводит архитектуру к Redis и горизонтальному масштабированию.
