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

Если вы никогда не задумывались, на чём вообще держится индустрия путешествий, присаживайтесь. Рассказ будет недолгим — минут на сорок. Если вы хоть раз покупали авиабилеты онлайн, то наверняка заметили странную особенность даже самых «успешных» сервисов: они умеют ровно две вещи — найти билет и продать билет. Всё. Как только ваши планы внезапно меняются, магия испаряется, и начинается древний ритуал: вы берёте телефон, звоните в поддержку и слушаете саундтрек, который не выбирали. Бездушный автоответчик шепчет, что все операторы заняты, просит остаться на линии, а в трубке тихонько умирает ваше свободное время.

Когда‑то, лет этак шестьдесят назад, авиакомпании внезапно осознали, что продавать билеты через кассу в аэропорту — это, конечно, лампово, но хотелось бы чего‑то более… системного. Так родилась первая GDS — глобальная дистрибутивная система. По сути, это вселенский пылесос, который засасывает данные из PSS авиакомпаний: расписания, тарифы, доступность мест, правила, статусы бронирований. Всё то, что покоится в глубинах корпоративных недр. GDS собирает это добро, перемалывает и раздаёт турагентствам, сайтам и прочим желающим продавать билеты, не вступая в прямой контакт с динозаврами.

А PSS — Passenger Service Systems — это как раз те самые динозавры. Древние, массивные, неприкасаемые. В них живут бронирования, билеты, тарифные правила и вся логика, объясняющая, почему перелёт с пересадкой в Чикаго стоит как подержанная «Тесла». PSS — это священные реликвии, написанные в эпоху телетайпов и перфолент, и с тех пор тронутые примерно столько же раз, сколько египетские пирамиды. Работает? Работает. Значит, не трогаем. Любая попытка модернизации выглядит как попытка провести МРТ на мамонте: интересно, но зачем?

Начиналось как «сделаю себе сайтик про кино на пару выходных». Закончилось каталогом на десятки тысяч карточек, лентой, профилями, рейтингами, совместным просмотром и кучей фоновых задач. И всё это тащит один человек — я сам себе фронт, бэк, девопс, дизайнер и поддержка. Делюсь сжато: стек и грабли, без воды.

Стек выбирал не по хайпу, а по принципу «доеду и не утону в обслуживании»: FastAPI (быстро, асинхронно, автодоки), Next.js на React (SSR из коробки — критично для SEO), PostgreSQL (SQLite кончился на первых же конкурентных записях), Redis для кэша и рейт-лимитов. Nginx + systemd на обычном VPS. Никакого Kubernetes — для одного это способ обслуживать инфраструктуру вместо разработки.

Грабли, на которых посидел:

• Фоновое состояние в памяти + несколько воркеров = рассинхрон. Пользователи попадают в разные процессы, состояние не шарится. Лечение: либо общее хранилище, либо такие фичи в один воркер.

• Права на файлы после сборки. Собрал под одним пользователем, сервис под другим — EACCES и белый экран. Теперь chown в чек-листе деплоя.

• node_modules не переезжает Windows → Linux. Только чистая установка на целевой ОС.

• dev и prod базы — разные миры. Один запуск скрипта «не туда» — и долго гадаешь, почему данные не меняются (а они меняются, в локальном SQLite, который никому не нужен).

• Не запускай два тяжёлых процесса разом. Фоновая генерация + пересборка фронта = OOM-killer молча прибил процесс. Полчаса искал причину.

• Кэш сборки трогать нельзя — «почистил на всякий» и сломал инкрементальную регенерацию страниц на сутки.

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

Что понял за это время: маленькие шаги бьют героизм; скучные бэкапы и чек-листы важнее красивой архитектуры; готовое и работающее лучше идеального ненаписанного. Один человек реально тащит удивительно много — если не воюет сам с собой за идеальность.

Не ради пиара, а как живой пруф того, о чём пишу: всё описанное работает прямо сейчас — vibemuvik.ru Можно зайти и потыкать вживую.

А вы тащите что-то в одиночку? На каком стеке, как боретесь с выгоранием и бесконечным бэклогом?

llms.txt - это файл в корне сайта, который говорит языковым моделям, что у вас за сайт, какие источники канонические и что цитировать. ChatGPT, Perplexity и Claude уже его читают. Большинство сайтов в Рунете его не имеют, поэтому AI-краулеры цитируют их или плохо, или никак. Файл пишется за 30 минут, эффект на цитируемость в AI-выдаче появляется в течение 1–4 недель.

В статье разбираю: что такое llms.txt, чем отличается от robots.txt, какие 5 блоков должны быть внутри, как написать свой за час, и показываю живой пример с production-сайта.

ES6 ввел синтаксис деструктурирующего присваивания — лаконичный способ распаковки значений из массивов и объектов в отдельные переменные. Это одна из тех фич, начав использовать которые, ты удивишься, как раньше без нее жил.

Привет, Хабр! Это снова Алиса из сериала про Laravel рядом с Битриксом.  В первой части мы аккуратно подселили Laravel к Битриксу. Во второй — растащили события, авторизацию и тяжелую логику по нормальным сервисам, а в третьей — перестали мучить каталог SQL-запросами и отдали поиск OpenSearch.

Теперь добрались до места, где любой e-commerce начинает показывать характер: корзина и расчет заказа. Это каталог может тормозить незаметно. А вот если корзина начинает чудить — это уже чувствует бюджет.

Недавно я увидел видео, где маленький мальчик собирает кубик Рубика за 2,76 секунды (вот оно), и мне тоже захотелось научиться его собирать. Конечно, не за такое время, но главное — суметь сложить хотя бы за 10 минут. Главная проблема в том, что кубика у меня нет; можно купить, но это как-то скучно, на троечку. Поэтому я подумал: а почему бы не написать за выходные простой код, чтобы побыстрее посмотреть и покрутить кубик, а потом уже можно и купить. Заодно и разберусь, где что находится у кубика.

Если сейчас слышишь «проект на нейросетях», чаще всего это очередной чат-бот или AI-ассистент. Денис в феврале 2025 года искал что-то другое — задачу, где нейросети дадут результат, который без них не получить. В какой-то момент он увидел в ленте рекламу детективной настольной игры и понял, что вот этот продукт можно построить на нейросетях так, как раньше никто не делал.

Денис автор проекта True Crime Games, детективной игры в Telegram, где подозреваемые отвечают в реальном времени и не отличаются от обычных аккаунтов в чате. В команде он сам, жена и сестра. К маю 2026-го, через восемь месяцев после запуска, было продано более 800 копий игры по $40, выручка ~$30000. 

Navigation API предоставляет возможность инициировать (программно запускать), перехватывать и управлять навигацией в браузере. Он также позволяет исследовать (traverse) сущности истории (history entries) приложения. Это улучшенный вариант предыдущих возможностей веб-платформы, связанных с навигацией, таких как History API и window.location, который решает их проблемы и специально предназначен для одностраничных приложений (single-page applications, SPA).

Начинаете писать E2E-тесты? Думаете, нужно просто открыть страницу, нажать кнопку и написать expect?

Разберем на примере Playwright, почему отчёт может быть зелёным, но бесполезным.

Пока в приложении две роли и три проверки, авторизация умещается в if user.Role == "admin". Но стоит добавить пару ресурсов, ролей и исключений — и условные проверки начинают расползаться по хендлерам, дублироваться и жить своей жизнью.

В этой статье разберём, как навести порядок с помощью Casbin: вынесем правила доступа из кода в конфиг, пройдём путь от простого ACL до RBAC с иерархией ролей, соберём HTTP-сервер на Go с авторизационной middleware и обсудим грабли, на которые легко наступить по дороге.

Когда начался ажиотаж (хайп) вокруг закона о норме, даже в писательском сообществе я столкнулась с непониманием того, что требуется, в каких случаях, по какому закону. Некоторые утверждали, что дело касается только вывесок в реальном мире, другие — что нужно следить за всем, что написано русским языком. Многие вовсе отрицали необходимость изменений. Но постепенно бизнес выстроил новые процессы, проверка текста на соответствие нормам русского языка стала одним из обязательных действий, и пришло время заняться оптимизацией. А значит, выбрать максимально удобные инструменты.

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

У нас в комьюнити часто приходят с одним и тем же вопросом: стоит ли делать продукт, если в поиске по теме почти нет запросов. Женя Донцов 6 лет назад задавал его себе и услышал от маркетологов ровно то, что слышат все: «Бро, у тебя запросов в Яндексе достаточно мало. Ты на этом хочешь сделать бизнес? Come on. Займись чем-нибудь нормальным». Он не послушал.

Женя шесть лет делает Waterius, устройство, которое автоматически передаёт показания счётчиков воды в водоканал. Код выложил на GitHub, от инвесторов отказался, в Яндекс.Директе почти ноль продаж на десятки тысяч показов, блогеры принесли суммарно десяток заказов. Почти вся выручка идёт через маркетплейсы, которые забирают 50% с каждой продажи, и это оказалось единственным, что работает. Сейчас выручка около миллиона рублей в месяц, 150+ городов подключены, рост в 1,5 раза в год.

Передаю слово основателю проекта Евгению Донцову.

Если вы из тех владельцев сайтов / интернет-сервисов, которые:
• взяли образец пользовательского соглашения из интернета 
• разработали пользовательское соглашение самостоятельно без привлечения юриста
• считаете, что публикация пользовательского соглашения на сайте – это формальность
то этот материал точно для вас!

Благодаря ему вы сможете:
01 понять, в каких случаях нужно использовать пользовательское соглашение, а в каких иной документ
02 понять реальную цель и ценность данного документа
03 проверить, насколько хорош ваш документ с юридической точки зрения и требуется ли его замена / доработка.

Антидетект-браузеры обычно обсуждают в двух режимах. Первый — рекламный: «создай сто профилей, работай без банов, всё безопасно». Второй — морализаторский: «это инструмент для серых схем, тему можно закрывать». Оба режима скучные, потому что за ними теряется главное — техническая часть.

Почему сайт вообще может понять, что пять аккаунтов сидят из одного браузера, если у них разные cookies, разные почты и разные прокси? Почему обычная подмена User-Agent давно почти ничего не решает? Почему один профиль выглядит нормально, а другой палится на Canvas, WebGL, timezone, TLS или странной связке параметров? И почему антидетект-браузер иногда действительно помогает мультиаккаунтингу жить дольше, хотя никакой невидимости он не даёт?

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

Спойлер: оба, но по-разному - и это важно понимать.

Каждый раз, когда слышим «у нас все нормально с безопасностью, мы же не банк», что-то внутри сжимается. За этой фразой обычно стоят токены аутентификации в SharedPreferences, SQL-запросы без параметризации и Firebase без правил доступа. Эта статья - попытка честно сравнить два мира, найти точки пересечения и разобраться, почему одни проблемы одинаковые, а другие - принципиально разные.

Исходные данные: OWASP Top 10 Web 2025, OWASP Mobile Top 10 2024, статистика NVD/CVE-базы, данные реальных пентестов, IBM Cost of a Data Breach 2024.

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

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

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

Содержание

Кэширование — ключевой механизм оптимизации производительности веб-приложений, позволяющий снизить задержки и уменьшить нагрузку на серверы. В этой подробной статье рассмотрим пять основных уровней кэширования, применимых в современных веб-системах. Ты узнаешь о внутреннем и внешнем кэше, кэшировании на уровне reverse proxy, браузера и фронтенда. 

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

Иногда значение меняется на эквивалентное. И здесь существуют разные подходы к отсечению вырожденных вычислений…

В марте 2026 многие обсуждали ситуацию с доступом к изображениям из ЛС мессенджера MAX по ссылкам, сохранённым через WebArchive. Тогда же многих не устроил ответ компании.

К сожалению, ситуация хуже, чем кажется. Т.к. проблемы не видят не только в MAX, но и в других компаниях (столкнулся с этим, оповещая компании о похожих проблемах). В статье я расскажу, почему считаю ситуацию — проблемой для всех: пользователей, компании, багхантеров. И как связка «WebArchive + IDOR» может стать бомбы замедленного действия для компании.
Более того, эта ситуация — наглядный пример, как отлаженный механизм повышения безопасной разработки (что не найдут внутренние безопасники компании — отловят багхантеры) иногда даёт сбой.