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

Всю свою карьеру разработчика я пользовался Postman. Помню его ещё простым расширением Chrome, слегка облегчавшим тестирование API. Жизнь в времена была гораздо проще. Сегодня я присоединяюсь к растущей толпе разработчиков, отказывающихся от этих инструментов, потому что они продались.

Великое предательство: как наши любимые инструменты обернулись против нас

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

Postman, когда-то бывший любимцем всех разработчиков, стал наглядным примером такой трансформации. Переломным для многих моментом стало удаление Scratchpad (офлайн-режим). После этого — снижение производительности и привязка к облачному сервису. Внезапно мы оказались вынуждены синхронизировать свою работу с облаком Postman для доступа к базовому функционалу (привет, Microsoft?). Во-первых, это вставляет палки в колёса разработчиков, работающих над конфиденциальными проектами в сфере банкинга и здравоохранения, а также в государственном секторе. В этом и есть смысл — заставить их платить за инструмент, максимизировать прибыль руководства, поэтому наносимый отрасли сопутствующий ущерб не учитывается.

Недавно я внедрил blue‑green деплой в проде. Реализация довольно простая и кастомная, но справляется со своей задачей на ура! Также сообщу, что используется обычный докер композ на виртуалке — возможно, кому‑то такой подход будет полезен.

Для фоновых процессов (воркеров)

В приложение добавляется специальный инфрастуктурный singleton класс с флагом is_accepting, и обертка на consumers. В каждом консьюмере перед обработкой проверяем этот флаг: если True — обрабатываем задачу, если False — переносим задачу на повторную обработку (например, в rabbitmq делаем сразу nack(requeue=true))

Привет! Меня зовут Максим Иванков, я развиваю школы программирования и робототехники для детей уже 9 лет. Сегодня расскажу про то, над чем работал последние 9 месяцев с перерывами — про свой собственный скрейч. Назвал я его Кубоша. Это визуальный редактор блочного программирования в стиле майнкрафта, в который я встроил задачи с автоматической проверкой и интегрировал в свою онлайн школу.

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

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

С формами в Next.js проблема обычно начинается не на уровне кнопки submit. Кнопка как раз почти всегда работает. Настоящая путаница начинается позже, когда форма уже живёт в проекте какое-то время. В одном месте ошибка показывается под полем, в другом только общей строкой сверху. Где-то кнопка блокируется на pending, а где-то можно отправить запрос несколько раз подряд. Клиент считает данные валидными, а сервер отвечает, что правило нарушено. Поле уже зелёное, а сохранение всё равно не прошло. В этот момент становится видно, что форма была собрана как кусок UI, а не как контракт.

Используем как примеры паттерны из проекта Workbench. Полезно смотреть на форму не как на набор input и submit, а как на договор между UI, валидацией и местом записи данных. У такого договора есть простая форма - какие данные считаются допустимыми, где и как они проверяются, в каком виде ошибка возвращается в интерфейс, что происходит на pending, когда форма блокируется, что считается успехом, а что общей ошибкой, не привязанной к конкретному полю.

Как только форма описывается так, код перестаёт расползаться. И здесь Zod в Next.js даёт не просто удобную схему, а способ удерживать client и server в одном наборе правил.

Привет. Я фронтенд-разработчик. По мнению тех, кто, по мнению некоторых, перекладывает джейсончики туда-сюда, я крашу кнопочки. Но сам я себя идентифицирую иначе: я тоже перекладываю джейсончики, и у меня всё точно так же, как у них. Даже архитектура. У меня тоже есть контроллеры, сервисы и хранилища, и я также обрабатываю запросы пользователей. Даже больше, я делаю HATEOAS, «тру» RESTful, если хотите. Давайте расскажу, как я к этому пришел.

Когда-то давно я только верстал. Накидывал разметку, добавлял классы, идентификаторы и стилизовал ЦСС-ом. И было хорошо. Потом от меня потребовали динамичности — пришлось добавить JavaScript. И было очень хорошо.

Технологии развивались, и мне хотелось пробовать новое. Я попробовал AJAX. Это было так волнительно... Я сказал бэкендерам: основную разметку жду от вас, а опции для выпадающего списка, например, отдавайте джейсоном по запросу. Они были не в восторге. «Одному HTML подавай, другому CSV, третьему ещё что-то — безобразие!» Но мы нашли компромис. Бэкэндеры сказали: «Вот вам, мол, джейсон, дальше сами как-нибудь». И назвали это REST API.

Сначала было очень круто! Мы, верстальщики, организовались. Мы стали фронтендерами! Конечно же, мы сразу побежали решать ещё нерешённые сто раз решённые задачи. Мы писали библиотеки и фреймворки — четыре миллиона штук! Да у нас даже есть библиотека с функцией для умножения чисел — lodash.multiply. Мы придумывали свои паттерны и архитектуры, например FSD. Короче, мы стали очень крутые.

Но то уже были «мы», а не я. Мне было сложно. Шутка ли, изучать по одному новому фреймворку в неделю? А ведь еще переписывать всё надо, стек-то устарел... В общем, в какой-то момент я перестал поспевать за модой и справляться со сложностью. Переходишь из одного проекта (на React) в другой (на Vue), а там всё иначе. Берешь нового разработчика в команду с опытом в React, например, а ему нужно время, чтобы вникнуть, потому что в его старой команде был другой «стейт-менеджер». Вавилон, никто друг друга не понимает.

Около года назад моё желание кастомизировать десктопный клиент популярного музыкального сервиса привело меня в некое сообщество. Всё началось с попытки восстановить заброшенную тему «Blurity» после очередного обновления Electron-хоста, которое сломало все селекторы. Но проект быстро перерос рамки обычных правок CSS.

В этой статье я расскажу, как ChromaSync эволюционировал из простого визуального патча в полноценную инженерную систему — runtime-аддон со сложной архитектурой. Мы разберем «анатомию» плеера, создание декларативной системы из 70+ настроек и перенос тяжелой математики аудиореактивных эффектов в изолированное ядро на WASM. Это история о том, как 700 строк JavaScript превратились в 10 000, а обычная «разукрашка» — в оптимизированную экосистему, умеющую балансировать между визуальной насыщенностью и производительностью системы.

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

Мы сделали интерактивный дом-таймлайн про телевидение 90-х и 00-х. Под катом: как команда без разработчиков дошла от JSON-файла на VPS за до корпоративного Kubernetes

У меня был один телефон, на котором я создавал проект, редактируя файлы в nano.

9 месяцев свободного времени (которого у работающего электрика не так уж много) ушло на то, чтобы из полного нуля сделать работающий P2P-видеосервис.

Прежде чем погружаться в архитектуру, давайте посмотрим на контекст, в котором всё это происходит.

По данным исследования McKinsey 2022 года, технический долг составляет до 40% всего технологического портфеля компаний. И это не просто цифра в отчёте. Согласно опросу 2024 года среди технических руководителей, у более чем 50% компаний технический долг занимает свыше четверти всего IT-бюджета, блокируя внедрение новых функций. (Источник: vFunction, 2025)

При этом исследование Carnegie Mellon выяснило, что наибольшим источником технического долга являются именно архитектурные проблемы — а не баги и не плохой код на уровне функций.

Теперь о Go. По данным Go Developer Survey 2024, главной проблемой команд, работающих с Go, названо поддержание единых стандартов кода — в том числе из-за разного уровня опыта участников и привнесения не-идиоматических паттернов из других языков. (Источник: go.dev/blog/survey2024-h2-results)

Это напрямую про нашу тему: люди приходят из Java, Python, C# и приносят с собой архитектурные привычки, которые в Go не работают. Clean Architecture и DDD — не исключение. Их часто реализуют "как в Java", а потом жалуются, что Go — многословный и неудобный язык.

Давайте разберёмся, как делать это правильно.

Как мы сюда попали?

Представьте: вы начинаете новый Go‑сервис. Читаете статьи, смотрите видео, решаете «делать по‑взрослому». Создаёте структуру:

Привет!

Это 13-й выпуск Frontend Status — дайджеста по фронтенд-разработке.

В этом выпуске:

📺 Для тех, кто хочет делать игровые интерфейсы быстрее: видео про 2D-игры с AI и Phaser, где генеративные инструменты работают как напарник, а не как «чёрный ящик».

🤖 В AI-разделе — разбор того, что уже можно брать в прод: micro-ml на Rust/WASM, кейс крупной техкомпании с роем из 50+ агентов, Flint Alpha и практическая интеграция Claude с видео.

🛡️ По безопасности фокус на снижении рисков: прикладной XSS, бесплатная оценка уязвимостей кода от GitHub и дорожная карта крупной техкомпании по постквантовой криптографии.

🎨 CSS-блок про баланс визуала и доступности: почему box-shadow не заменяет outline в forced-colors и как сохранить корректный фокус.

⚛️ React-секция для тех, у кого интерфейсный слой растёт в сложности: управление модалками без хаоса, UI без брейкпоинтов и состояние компонентов через radio state machine.

⚡ В JS/TS — практичный набор без перегруза: Pretext для текста, k-means для палитр, модульная архитектура, Intl API и Web Audio API в Node/Bun.

🅰️ Angular-раздел посвящён Signal Forms в v21 и тому, как перейти к типизированным формам без ручных подписок.

🌐 В стандартах и дизайне — что уже можно внедрять сейчас: CSS Image Animation, Baseline за март, Liquid UI и UX-подходы для legacy-систем.

…и многое другое.

После трех лет в IT меня меньше всего бесит код. Код хотя бы честная сущность. Если он сломан, он обычно не делает вид, что это часть командной культуры.

Гораздо сильнее меня начали бесить вещи вокруг разработки.

Бизнес-чаты в Telegram — это не только флуд, но и доска объявлений с услугами и вакансиями. В нем нет структуры, но есть запросы на поиск подрядчиков, советы или просьбы о помощи. Мы поняли, что если системно отслеживать чаты, то можно найти клиентов для услуг нашего агентства, то есть организовать канал для лидогенерации. Искать эти лиды вручную довольно сложно, и потому с помощью вайбкодинга сделали бота, который автоматически находит потенциальных клиентов в чатах. Рассказываем, как с помощью ИИ и всего за 5000 рублей в месяц мы получили стабильный поток заявок.

Помните времена, когда цвета в CSS выбирались почти наугад? Белый фон — #FFF, чёрный текст — #000, акцент — какой-нибудь #3498db, который просто нормально смотрится? Для раннего веба этого хватало. Интерфейсы были проще, экраны — одинаковее, а требования к доступности, темам и визуальной консистентности ещё не давили на разработку так сильно, как сейчас.

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

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

Вы уверены, что ваш бандлер вырезает неиспользуемый код? Я тоже был уверен — пока бандл Next.js проекта не оказался в два раза тяжелее, чем нужно. Прогнал одинаковый тест на webpack, rollup, vite, esbuild и Next.js — 5 из 7 ломаются на банальном barrel файле. Полез в исходники, нашёл основную причину — и она оказалась не там, где ожидал.

Вы сделали open source проект. Потратили на него недели или даже месяцы: продумали архитектуру, аккуратно написали код, добавили нужные фичи. Даже сами начали им пользоваться.
А потом открыли GitHub… и ничего не произошло. Ни пользователей. Ни обсуждений. Ни pull request’ов. Иногда даже звёзды не появляются.

И в этот момент возникает вполне логичный вопрос:
“Что не так?”

Разбираем, что мешает проектам получать пользователей и контрибьюторов, и как это изменить.

Привет, Хабр! Вот два факта:

R&D - это единственный путь к реальным инновациям, которые дают конкурентные преимущества и, потенциально, меняют или даже создают новые рынки

Большинство менеджеров и представителей бизнеса боятся столкновения с R&D-задачами как огня, и решаются эти задачи, часто, “вопреки”, а не “благодаря”

Давайте разберемся, почему так происходит и что с этим делать.

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

Привет, Хабр! Меня зовут Сергей. Я работаю инженером в Selectel, а в свободное время пишу пет-проекты для души. Недавно я прикинул: а что, если прямо сейчас мне понадобится запустить свой бренд или продукт? Первое, во что упираешься в таких раздумьях — это выбор домена. В этой статье я покажу небольшой проект, благодаря которому можно подбирать доменные имена не вручную, а автоматически с применением ИИ-агентов. Удобно или нет, решайте сами, подробности под катом.

Авторская колонка CMO Veai

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

Это уже не будущее. Это ежедневная реальность - для команд разработки и для команд маркетинга одновременно.

Но именно сейчас, когда это время наконец появилось, возникает по-настоящему важный вопрос: а куда мы, собственно, идем?

Агент выполнит любую задачу, которую мы ему дадим, - быстро и точно. Но если задача неверно сформулирована, он с той же скоростью и точностью приведет нас к неудаче.

Поэтому самый важный навык нашего времени - не освоить очередной инструмент. А научиться правильно ставить цель и видеть, что стоит за ней: какую ценность она защищает, какой результат на самом деле нужен. Именно это определяет, куда в итоге придет агент - и вся команда вместе с ним.

Бесконечный backlog с P0 у каждого тикета

Есть популярная управленческая метафора: цели - как камни в банке. Сначала клади крупные, иначе мелкие займут все место. Для разработчиков и аналитиков это описание не работает, потому что жизнь - не банка. Это бесконечный backlog, где у каждого тикета стоит приоритет P0.

Доставлять фичи быстрее - P0. Качество кода - P0. Безопасность - P0. Семья - P0. Здоровье - P0. Рост команды - P0.

Классический тайм-менеджмент здесь ломается: нельзя «просто расставить приоритеты», когда все одинаково важно. Работает только одно: понять, какую ценность защищает каждый тикет. Тогда конфликт между целями становится управляемым.