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

Я занимаюсь разработкой уже больше пятнадцати лет. Наверное, меня можно отнести к “прошлому” поколению разработчиков — тем самым старперам, которые вручную писали код на высокоуровневых языках вроде Java, PHP, JavaScript, Go. Уже давно замечаю за собой, что становлюсь всё более консервативным в вопросах выбора инструментов и технологий для проектов, за которые отвечаю. Поэтому к AI-хайпу, копилотам, агентам и прочему отношусь с осторожностью и скепсисом.

Но всё же решил попробовать — и делюсь с вами своими наблюдениями: что работает, а что нет.

Сразу скажу: мне в целом понравилось. Я бы даже сказал, что впечатлён.

Рынок digital-услуг в России в 2025-м остается хаотичным, без четких стандартов и объективных критериев качества. Клиенты не могут заранее понять, кто выполнит работу хорошо, а кто просто продаст красивую презентацию. Изначальные причины этого понятны. Агентства не продают готовый продукт, а оказывают услугу по созданию этого продукта, поэтому их реальный уровень становится очевидным только после начала работы. Это базовые условия, проблем не в этом факте, а в том, что происходит дальше.

За этапом пресейла часто можно увидеть как даже масштабные проекты передают людям без опыта на непосредственное исполнение. Вчерашний школьник, освоивший Figma за пару вечеров, может легко получить заказ, потому что границы профессии размыты. Достаточно разместить вакансию «senior дизайнер» и посмотреть отклики, чтобы убедиться в масштабе проблемы, и кто сегодня считает себя дизайнерами такого уровня. HR разбираться с квалификацией не будут, им надо затыкать дыры, и так вчерашний студент может оказаться в перегруженном агентстве у которого нет лавки с резервом ресурса (потому что это дорого) на большом проекте, делать же кому-то нужно.

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

Проджект-менеджмент страдает еще сильнее. Если про дизайнеров и разработчиков хоть отраслевые стандарты и школы начинают формироваться, то управление проектами воспринимается как факультативная функция. Многие проджекты не знают, что такое PMBoK, не различают Agile и Scrum, а зачастую вообще не понимают своей роли, и просто доделывают за исполнителями про компетенцию которых я писал двумя абзацами выше.

В первой части мы построили бэкенд на FastAPI, Aiogram, Redis и Centrifugo, заложив основу для анонимного чата в Telegram. Теперь пришло время развернуть фронтенд и создать стильный и отзывчивый интерфейс с использованием VueJS 3 в формате Telegram MiniApp.

В этой статье мы:

- Разработаем интерактивный UI с фильтрами поиска, анимациями загрузки и real-time чатом.
- Настроим мгновенный обмен сообщениями через Centrifugo без лишних запросов к серверу.
- Интегрируем монетизацию для заработка на рекламе в приложении.
- Выполним деплой на удаленный сервер и подготовим проект к продакшену.

Если вы хотите создать быстрый, удобный и монетизируемый анонимный чат в Telegram, который работает без задержек и перезагрузок, — эта статья для вас!

Наверное, каждый, кто сталкивался с frontend`ом, хотя бы раз использовал адаптивную flex-сетку на N-ном количестве колонок. В данной статье мы не станем рассматривать область применения такого подхода, его плюсы и минусы, а разберем теорию и напишем собственное решение, с брейкпоинтами и настраиваемым спейсингом!

Данная статья, в первую очередь, будет полезна новичкам, однако надеюсь, что и опытные разработчики найдут в ней что-то интересное. Для упрощения жизни, будем использовать SCSS, продублировав CSS «под спойлер».

Если нужно быстро освежить память о жизненном цикле бина в Spring, эта шпаргалка для вас. Здесь коротко и по делу: ключевые этапы — создание, внедрение зависимостей, инициализация, пост-процессинг и уничтожение. Разберем их на понятных примерах, без лишней воды.

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

Если вы тоже ищете способы сделать свой код чище и поддерживаемым, или просто хотите обсудить разные подходы к архитектуре, — добро пожаловать в комментарии. Давайте разбираться вместе!

При развертывании высоконагруженных веб-приложений часто приходится взаимодействовать с прокси-сервером. Помимо прямого прокси-сервера (Forward Proxy Server), существуют также обратный прокси-сервер (Reverse Proxy Server), цель которого заключается в повышении безопасности и производительности, а также в управлении трафиком путем обработки запросов от клиентов и распределения их между несколькими внутренними сервисами. Также обратный прокси-сервер используется для сокрытия реального IP-адреса сервиса, тем самым повышая уровень безопасности. Сегодня мы рассмотрим программный продукт Nginx Proxy Manager, который можно использовать как reverse proxy (обратный прокси) для веб-приложений.

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

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

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

В этой статье поделюсь быстрым способом настройки геотаргетинга на nginx + GeoIP2 в связке с локализацией Next.js на примере решения реальной задачи.

Вы узнаете как подключить и настроить GeoIP2 к nginx, как приоритизировать и настроить критерии выбора домена и локали, и как подружить это с Next.js

По итогам голосования под прошлым постом Идеальное рабочее место, эта тема стала наиболее актуальной для обсуждения.
Давайте разберемся, почему джуниору не стоит соглашаться на первый попавшийся оффер от IT-компании. Из-за большого наплыва новичков в сферу появилось множество сомнительных предложений и схем.

Дата — это всего три числа, но даже такой маленький элемент интерфейса может серьезно повлиять на пользовательский опыт.

Зачастую нам приходится описывать API-запросы или переписывать уже имеющиеся ввиду изменения каких-то DTO (Data Transfer Object) или параметров у запросов. Это вполне естественно для разработки, но часто оказывается скучным и однотипным процессом, не требующим размышлений или особых навыков. В этой статье я рассказываю, как автоматизировать всю эту историю.

Привет, хабр! Больше года назад я впервые узнал про сигналы, а три месяца назад @Sin9k записал видео на эту тему. И поскольку сигналы по-прежнему обходят стороной, попробую немного исправить ситуацию)

В материале будет использоваться обёртка signals-react, так как изначально рассматриваемая библиотека написана под Preact.

Привет, Хабрчане! Это Леша Жиряков, техлид backend-команды витрины KION. В прошлый раз я писал о секретах популярности Python, а сегодня будет пост о разработке на React. Расскажу, какие библиотеки стоит добавить в свой набор в 2025 году, приведу плюсы и минусы каждой, данные с GitHub и примеры использования. Начнем!

В современном мире тема ИИ возникает чуть ли не везде. Что уж говорить про ИТ‑сервисы, которые стремятся бежать впереди паровоза и пихают модную технологию где надо и где не надо. Меня это с самого начала стало раздражать, поскольку к теме ИИ отношусь с изрядной долей критического подхода и даже скепсиса. Я не вижу, что в нужных мне приложениях ИИ приносит хоть какую‑то ощутимую пользу.

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

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

Привет, Хабр. Меня зовут Дмитрий, я Frontend-разработчик в компании Webest. В этой статье расскажу, как эффективно использовать семантический HTML, какие теги (от <header> и <main> до <article> и <aside>) действительно приносят пользу, и в каких ситуациях они работают лучше всего. 

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

Хабр, привет! Я стабильно пишу здесь о CSS. Мне радостно, что моя работа вам полезна. Но хочется чего-то нового. Вызывающего споры. В общем, я к формату статей в виде вопрос-ответ. Вопросы будут те, что я спрашиваю на интервью. Так что у вас будет повод сказать: «А зачем это надо?».

При составлении вопросов я хотел проверить понимание базовых моментов, которые есть в вёрстке любого проекта. Ещё будут вопросы на знание более редких аспектов и «новинок» в CSS. В общем, я хочу вас завалить, чтобы казаться супер умным! (здесь ирония).

Пожалуйста, не воспринимайте мои вопросы серьёзно. Давайте просто весело проведём время. Плюс попробуем узнать что-то новое. Ведь у каждого вопроса будет мой ответ. И вы тоже можете оставить свой в комментариях. Я обязательно буду их читать.

Так, вы готовы? Давайте посмотрим, что я вам подготовил.

В процессе работы с HTML-документами часто возникает необходимость получить доступ к конкретным элементам DOM. Обычно это делается с помощью уникальных идентификаторов, которые присваиваются нужным элементам. Однако существует вероятность, что в большом документе может оказаться несколько элементов с одинаковыми идентификаторами, что может привести к путанице.

Чтобы избежать этой проблемы, я разработал библиотеку dom-scope, которая позволяет создавать искусственные области видимости (скоупы) внутри DOM. Я хочу поделиться своим решением с сообществом Хабра.