В 1865 году британский журналист Томас Майн Рид написал роман "Всадник без головы", который послужит нам отправной точкой в вопросе о том, что же такое "безголовая" CMS и какие из них представлены сейчас на рынке веб-разработки.
Инженеры узнают о межсайтовом скриптинге (Cross-Site Scripting, XSS) тремя способами.
Счастливчики узнают о нем благодаря полезному анализу кода или проактивному правилу проверки кода. Внимательные — во время аудита безопасности, который выявляет уязвимость до того, как она попадет в продакшн.
А есть те, кто узнает о нем через страдания, когда их сайт становится уязвимым. Когда злоумышленник внедряет скрипт, который крадет токены сессий из localStorage, перехватывает файлы cookie или перенаправляет пользователей на фишинговый сайт. Я лично присоединился к клубу «пострадавших» еще в 2005 году, когда встроенная Flash-подпись на форуме, которым я владел, превратилась в кошмар с точки зрения безопасности… но это уже другая история.
В этой статье мы рассмотрим, как браузер, наконец, снимает с нас бремя очистки данных (sanitizing) благодаря новому HTML API Sanitizer.
Astro — фреймворк для сайтов, который минимизирует поставку JavaScript на клиент, обеспечивая высокую производительность. 22 июня вышла седьмая версия, в которой разработчики серьёзно прокачали скорость. Компилятор .astro переписали на Rust, туда же перенесли обработку Markdown и MDX, а движок рендеринга заменили на систему с очередями. Вкупе с Vite 8 и новым бандлером Rolldown сборки ускорились на 15–61% по внутренним бенчмаркам. А поскольку самая быстрая сборка — та, которую не нужно запускать вовсе, в Astro 7 также стабилизировали кэширование маршрутов и добавили экспериментальных CDN-провайдеров кэша для Netlify, Vercel и Cloudflare.
В Astro 7 добавили продвинутый роутинг: появляется точка входа src/fetch.ts, дающая полный контроль над конвейером обработки запросов в Astro. Для разработки с участием ИИ Astro теперь умеет определять coding agents, запускать dev-сервер в фоне и выводить структурированные JSON-логи, когда агентам нужен машиночитаемый ответ.
В начале мая в инструменте Lighthouse от Google появилась новая категория проверок «Агентный просмотр».
Привет, Хабр! Меня зовут Алексей Постригайло, я старший партнер ИТ-интегратора «Энсайн». Больше 20 лет занимаюсь системной интеграцией и управлением проектами.
Сейчас почти каждая крупная компания тестирует искусственный интеллект. Где-то запускают поиск по внутренним документам, где-то автоматизируют поддержку, аналитику или подготовку отчетов.
На пилоте такие решения часто показывают хороший результат. Модель отвечает быстро, сотрудники довольны, руководство видит потенциал. Затем проект останавливается.
Проблема обычно появляется в момент, когда тестовую версию нужно превратить в постоянную систему. Здесь становится ясно, что одной модели недостаточно.
Статья, которая поможет разобраться:
- такое tools, hooks и skills
- чем они они отличаются
- когда и что использовать
В предыдущих публикациях я уже рассказывал, зачем вообще появился Browser Policy Manager, почему я начал с Firefox Enterprise Policies и почему не стал делать «просто генератор policies.json». Эта статья — более техническая. Здесь я хочу разобрать, как Browser Policy Manager устроен внутри на версии 0.8.8.
Версия 0.8.8 для проекта важна тем, что в ней фактически сложилась основная архитектура продукта:
Немного насчет - «AI-агенты сделают разработку самоподдерживаемой».
Прогнал spec-driven агентный пайплайн на нескольких проектах, и картина каждый раз одна: узкое место, где тормозится разработка, не исчезает, оно сдвигается.
Для примера, один из таких полигонов - небольшой проект, приложение для книг на виртуальных полках, начинался как пет-проджект жены. В нем можно толкать агентные воркфлоу сильно дальше, чем я бы рискнул на нагруженном проде.
Как это работает на практике:
Хабр, привет!
Многие фронтенд-разработчики часто отдают предпочтение JavaScript при реализации интерфейсных элементов. Я же разработчик старой формации. Мы тогда стремились сделать всё с помощью HTML и CSS.
Так в интернете зародилось множество HTML- и CSS-решений. Думаю, вы видели эти костыли с переключением радиокнопок и стилизацией других элементов. У меня был период, когда я тоже загонялся по ним.
Честно говоря, это всё баловство. Но с развитием HTML и CSS появились классные подходы, которые частично заменяют логику, написанную на JavaScript. И мне хочется, чтобы вы использовали их как можно чаще. Поэтому сегодня я поделюсь с вами несколькими техниками, которые вы уже можете использовать в своих проектах.
Давайте посмотрим, что я вам подготовил.
Я только что выполнил свой первый вайбкодинг-заказ по разработке небольшого интернет-магазина. После статьи про ошибки хочется зафиксировать и обратную сторону вопроса. Не всё в этом проекте было криво и больно. Многие решения сработали хорошо и в итоге позволили довести дело до конца. Именно их я привожу ниже.
1. Постоянно делать предложения лидам
Если ты ведешь переписку с лидом, то буквально в каждом сообщении ему нужно предлагать что-то новое: идеи, варианты, заходы. Человеку важно дать понять, что ты не просто "на связи", а реально приносишь человеку пользу.
Рабочий пример:
Привет, как там ты, не передумал еще делать сайт? Смотри, какая есть идея. У меня есть клиент, студия импровизации. У них ситуация такая же, как у тебя: есть тг‑канал, но они хотят развиваться еще и в сторону сайта...
Нерабочий пример:
Добрый день! Хотел с вами встретиться, будет ли вам удобно в ближайшие дни, или на неделе?
2. Показывать демки
Невероятно важно показывать заказчикам демки. Без них сложно объяснить, в чем суть предложения. Человеку достаточно одного взгляда на демку, чтобы понять, что к чему. Оно и понятно: веб-разработка - визуальная история, поэтому и объяснять ее лучше визуально. А вот голосовые сообщения работают хуже.
Примеры:
Я только что выполнил свой первый вайбкодинг-заказ по разработке небольшого интернет-магазина. Изначально задача выглядела понятной: каталог, корзина, админка, оплата, деплой. Казалось, что это несложный CRUD-проект плюс дизайн по референсам заказчика.
В моем случае все началось с оценки: «три недели, а если пойдет хорошо, то и две». Но фактически проект занял месяц. Ниже я описываю 10 своих ошибок, из-за которых мой план разошелся с реальностью.
1. Разрабатывал только локально, на VirtualBox
Я установил виртуальную машину VirtualBox и вел всю разработку на ней. Это удобно: можно держать открытыми сколько угодно окон, не бояться что-то сломать и иметь полностью контролируемую среду.
Но мой VirtualBox не был доступен из внешнего интернета. Поэтому через несколько дней пришлось разворачивать staging-сервер на VPS для полноценного тестирования.
Пока для себя формулирую так: если проект маленький и завязан на внешние интеграции, staging нужно поднимать как можно раньше и использовать его не только для тестирования, но и как рабочую площадку для ИИ-агентов.
2. Слишком поздно занялся боевым сервером
Регистрацию домена и настройку боевого сервера я откладывал до последнего. Казалось логичным сначала закончить код, все протестировать и только потом выкатываться в прод.
Это решение оказалось ошибкой. В середине разработки понадобилось подключать онлайн-платежи, а банк запросил боевой домен. Пришлось срочно решать вопрос, но быстро это не получилось: домен нужно было регистрировать на заказчика, а он в этот момент был в отъезде. В результате работа встала на несколько дней.
Сегодня история Diaverse — мобильного приложения, которое помогает сформировать привычку ежедневно проходить 10 000 шагов через игровые механики и элементы геймификации.
На первый взгляд идея выглядит пугающе банальной. В мире уже существуют Apple Health, Google Fit, Fitbit, сотни, если не тысячи шагомеров и фитнес-приложений. Кажется, что придумать что-то новое в этой нише уже невозможно.
Тем не менее за первый год работы проект получил около 300 000 регистраций, привлек пользователей из 104 стран и сделал примерно $930 000 оборота.
Я поговорил с основателем проекта Игорем и узнал, как появился Diaverse, что это такое, откуда пошли первые деньги и почему пользователи готовы платить сотни долларов за виртуальных питомцев.
Под катом делюсь обзором своего самописного PHP-фреймворка Gy — попытки сделать легковесного «убийцу» Битрикса весом 350 Кб. Расскажу, как я реализовал вызов компонентов, зачем написал кастомный SQL-движок на текстовых файлах PhpFileSql.
Костыли, велосипеды, 3 года разработки по выходным, 315 коммитов, 14232 строки кода, поддержка практически всех версий PHP и ровно 0 пользователей.
Как-то вечером я поймал себя на том, что трачу по 20 минут на поиск цветовой палитры для каждого нового проекта. Coolors, Adobe Color, случайные пины в Pinterest — и всё равно ощущение «не то». Тогда я задал себе вопрос: а что если вместо колеса оттенков начинать со слова? «Рассвет», «шторм», «лакшери» — у каждого слова есть интуитивный цвет.
Так появился Колорит — инструмент, который превращает слово или фотографию в цветовую палитру с помощью ИИ. В этой статье расскажу про технические решения, prompt engineering для DeepSeek и пару неочевидных браузерных API.
Всем привет! Меня зовут Александр, я продуктовый инженер в KTS.
Недавно мы разрабатывали AI-копайлот для сервис-деска в виде расширения на Chrome. Копайлот подсказывал оператору ответы для клиента на основе контекста диалога, истории обращений и базы знаний компании. Уже на старте стало понятно, что разработка расширений сильно отличается от привычной фронтенд-разработки.
Основная сложность была не столько в реализации конкретных фич, сколько в архитектуре: где должен жить тот или иной код, как организовать взаимодействие между частями расширения и как не заложить проблемы на будущее. Дополнительно добавились нюансы интеграции в страницу и ограничения, связанные с публикацией в Chrome Web Store.
Поударявшись о всевозможные подводные камни, я решил написать эту статью. В ней я разберу ключевые этапы разработки и публикации, покажу удачные и неудачные подходы и на что стоит обратить внимание, если вы планируете делать браузерное расширение со сложной логикой.
Сразу задам фрейм: в статье речь пойдет именно о расширениях для Chrome (Manifest V3), хотя многие подходы будут применимы и к другим браузерам на базе Chromium.
Как мы спасали Magento 2 с 1 млн товаров и 10 млн CMS страниц от 504 ошибок.
Разбор реального кейса оптимизации Magento 2-магазина с более чем 1 миллионом товаров и 10 миллионами CMS-страниц. Покажу, почему возникали ошибки 504 Gateway Timeout, какие узкие места были обнаружены в архитектуре, и как использование Redis, Varnish, MariaDB и OpenSearch позволило добиться стабильной работы системы под высокой нагрузкой.
Когда в нашем PWA‑приложении возникла задача добавить загрузку изображений, первое, что пришло в голову — классическая схема: клиент → бэкенд → S3. Но стоило копнуть глубже и учесть особенности PWA (офлайн, кэширование), несколько типов файлов с разными правами доступа и требования масштабирования, как наивное решение рассыпалось. В итоге мы пришли к архитектуре с presigned URL, разгрузили бэкенд и получили гибкую систему модерации. Делюсь этим опытом и ключевыми шишками, которые набил.
За последний месяц я насчитал минимум семь свежих статей с заголовком в духе "Playwright быстрее Selenium на N%". Проблема в том, что N у всех разный: 23%, 42%, 63%, "1.85x". Методология почти нигде не раскрыта дальше фразы "controlled environment". Для решения, которое определяет CI-бюджет и архитектуру тестов на годы вперёд, это не цифры — это шум.
Здесь — что из этого шума реально на что-то опирается, почему остальное несопоставимо, и рабочий бенчмарк-харнесс, который вы можете прогнать на своём стеке за один CI-job и получить именно свои числа, а не чужие проценты.
Недавно под постом в канале MoscowJS разгорелся спор — со мной и организатором насчёт смола. Даже не столько насчёт смола, сколько в целом: стоит ли выбирать новые технологии или нет. Думаю, это касается не только смола, а любых новых фреймворков и библиотек.
Претензии вроде бы логичные, чтож, давайте разберем их
Мы уже разобрались с тем, что такое BaaS, почему появились Firebase и Supabase, чем они отличаются от обычного backend и можно ли самому собрать что-то похожее.
Как я и говорил в прошлой статье, сегодня мы наконец попробуем самостоятельно собрать альтернативу Firebase с Realtime исключительно на open-source компонентах!
Но важная оговорка: мы не будем делать полный клон Firebase с его тонной функционала, но мы соберем минимальную рабочую альтернативу, которую уже можно подключить к frontend через SDK и использовать почти как Firebase.
