Веб-разработка *

 Я только что выполнил свой первый вайбкодинг-заказ по разработке небольшого интернет-магазина.  После статьи про ошибки хочется зафиксировать и обратную сторону вопроса. Не всё в этом проекте было криво и больно. Многие решения сработали хорошо и в итоге позволили довести дело до конца. Именно их я привожу ниже.

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.

Сейчас только ленивый не делает свой нодовый редактор.

Я решил помочь всем быть ещё ленивее и сделать вилку для макаронного монстра: открытый конструктор, в котором сам нодовый редактор собирается из готовых частей, а ноды перестают быть пленниками одной программы и превращаются в переносимые штуки. Ноду можно скачать, поставить себе, кинуть другому человеку, бросить в библиотеку, собрать из нескольких цепочку — а потом свернуть эту цепочку обратно в одну ноду.

Проект называется SnarkRoute. Рабочий публичный кусок сейчас живёт как BoojumRoute Lab — локальный блочный редактор маршрутов. А под ним лежит то, ради чего всё и затевалось: Open Route Protocol, переносимый формат для описания AI-, model- и API-воркфлоу.

Согласие на обработку персональных данных в Django-проекте часто начинается с одного BooleanField. Но затем оказывается, что недостаточно помнить только факт нажатия на чекбокс: пользователь мог видеть другую редакцию документа, отозвать согласие, выбрать лишь часть категорий файлов cookie, а администратору может понадобиться журнал действий и выгрузка в CSV.

Я сделал для этого два полностью независимых Django-пакета с открытым исходным кодом: django-consent-152fz для юридически значимых согласий и django-cookies-152fz для политики файлов cookie, категорий, подключённых сервисов и окна выбора. В статье покажу реальную модель данных, минимальное подключение и то, как устроены редакции, журнал событий и выгрузка данных.

В этой статье разберу JSON-LD для сайтов на Tilda: что именно размечать, как разделять общий код и код конкретной страницы, где проверять микроразметку и какие ошибки чаще всего появляются после правок сайта.

Материал не про то, как скопировать готовый JSON из генератора. Такой вариант годится только для самых простых страниц.

На коммерческом сайте разметку лучше собирать от структуры: есть сайт, организация, конкретные страницы, услуги, статьи, контакты, изображения, хлебные крошки и вопросы.

Часть этих данных относится ко всему сайту, часть - только к одной странице.

Если это не разделить сразу, дальше начинаются дубли, старые URL, одинаковые схемы на всех страницах и странные предупреждения в валидаторах.

Для примеров возьму нейтральную нишу - учебный центр.

Всем привет! Это Денис Сметнев. Последние пару месяцев я плотно сижу на вайбкодинге. Поднял свой сервер, запилил базу лидов из Телеграма и карту знаний, хотя последний раз кодил в 9 классе на Pascal. Вижу, что у многих появилась мысль: если я могу сам сделать себе любой софт под задачу, зачем тогда вообще нужны SaaS-продукты? Неужели они умрут? В этой статье хочу порассуждать, как на самом деле изменится рынок и почему хоронить софт пока рано.

На странице услуги пользователь видел цену «от 25 000 ₽», а meta description и JSON‑LD продолжали отдавать 50000. Валидатор был зелёным.

И это был собственный сайт веб‑студии!

Разберёмся, как валидная микроразметка начинает публиковать неверные данные, почему замена одного числа не решает проблему и что на самом деле нужно проверять после изменений сайта.

Это первая из двух статей о CancelledError — сигнале отмены задачи. В ней мы остановимся на стандартном asyncio. Узнаем, что на самом деле представляет собой CancelledError, с точки зрения event‑loop. Разберёмся, как работает счётчик отмены (cancel/uncancel), на котором построены TaskGroup и asyncio.timeout. Наконец, обсудим проблемы, которые возникают на практике, в первую очередь связанные с asyncio.shield.

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

Ошибок, конечно. не должно быть, как и других неприятностей в жизни, однако они иногда случаются. Вина ли это программиста, браузера, его расширений, операционной системы, звездного ветра — неважно. Нужно уметь принимать удар и не прятать голову в песок. Но в разных библиотеках мы сталкиваемся с очень разным поведением…

Это первая из трёх статей про сайты под управлением ИИ. В этой части — концепции и экономика без маркетинговой пыли: что такое нейросайт на самом деле, чем он принципиально не является, и почему дешёвый VDS за пару тысяч рублей тут вообще ни при чём с точки зрения железа под нейросеть. Во второй части будет внутрянка (MCP‑брокер, пайплайн деплоя, безопасность), в третьей — прод‑механика на тысячах страниц (SSG/ISR, индексация, массовые операции). Здесь сознательно держусь на уровне архитектурных решений, не уходя в реализацию — она дальше.

Мы рады объявить о релизе MDN MCP-сервера. MCP (Model Context Protocol) — это открытый стандарт, который позволяет ИИ-инструментам подключаться к внешним источникам данных. MDN MCP-сервер использует этот протокол, чтобы доставлять документацию MDN и данные о совместимости браузеров прямо в твой редактор кода или IDE.