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

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

вот пример:

SELECT
price * quantity AS total_price,
(price * quantity) * 0.15 AS tax,
((price * quantity) + ((price * quantity) * 0.15)) AS grand_total
...

Здесь price * quantity вычисляется несколько раз, и tax вычисляется дважды. Но это выглядит еще ок, в реальности это зачастую всякие монструозные свитч-кейсы с NULLIF, COALESCE и прочими ребятами.

Но не суть, вам хочется один раз вычислить значение, без дублирования кода.

Long story short, это делается так:

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

Всем привет, уважаемые читатели! В архитектуре проектов мы можем наблюдать применение паттерна BFF (Backend for frontend). При этом BFF может быть в архитектуре, где есть взаимодействие с клиентскими приложениями: веб, мобильное, смарт-устройства и т.д, но может быть всего-навсего один служебный фронтенд, доступ к которому возможен во внутрикорпоративном сегменте, например, банковская система, hr, логистика. Кажется, что при наличии одного фронтенда введение BFF избыточно.

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

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

Привет, Хабр!

Если вас заинтересовал заголовок, то вы, скорее всего, уже знакомы с разработкой Telegram или Discord-ботов. И что также вероятно: для получения обновлений вы используете обычный polling. Сегодня же я вам предлагаю ознакомиться с другим способом получения обновлений - через webhook.

Продолжаю серию статей про вайб кодинг для чайников (это я). Сегодня про главную боль: почему всё, что генерирует ИИ в плане веб-дизайна, выглядит одинаково пластиково, и что с этим делать на практике.

Хотелось бы свалить на конкретную модель и сказать - "надо просто выбрать вот эту и всё будет тип топ". Но на самом деле - это проблема подхода: по умолчанию ИИ пишет и оптимизирует код подходом "работает и не ломается", а не "выглядит как лучшие примеры с Awwwards". У него нет контекста вашего бренда, нет визуального фидбека на результат, нет источника вдохновения. Он берёт самый частотный паттерн из обучающей выборки, и вы получаете среднее арифметическое всех шаблонов интернета (стоит признать - иногда и так нормально). Давайте это починим в этой статье.

Как правило, работа с веб-сокетами сводится к паре строк: connect() и send(). Удобные абстракции библиотек превратили этот протокол в магическую трубу, по которой летают данные в обе стороны. Но магия заканчивается ровно в тот момент, когда соединение молча отваливается с кодом 1006, балансировщик рвет коннект, а в логах появляются странные ошибки фрагментации. В этой статье мы спустимся с небес высокоуровневых фреймворков на уровень байтов и битовых масок.

Мы пройдем полный путь WebSocket-соединения, опираясь на RFC 6455: от генерации ключа на стороне клиента до обмена закрывающими фреймами. Попутно разберем весь необходимый понятийный аппарат: что такое фреймы, какими они бывают, зачем их маскируют и фрагментируют и т.д. Цель не в том, чтобы научиться пользоваться конкретной библиотекой, а в том, чтобы понять, как протокол работает изнутри независимо от языка и реализации. Для иллюстраций по тексту статьи даны сниппеты на Python.

Netflix, Shopify, Vercel — что общего у этих компаний, кроме успеха? Они по-особому строят мост между фронтендом и сервером. Не просто «отдай JSON», а целые архитектурные подходы: BFF под каждое устройство, частичный prerendering, Server Components. В новой статье мы разберем, как современный фронтенд общается с бэкендом и почему старый добрый REST уже не всегда спасает. Спойлер: даже если вы бэкендер, после прочтения начнёте иначе проектировать API.

Всем привет! Кажется, настала пора поделиться изменениями в Азбуке, которые произошли с 2022 года, когда я выпускал прошлую статью. Наш текущий стэк: Vue 3, Nuxt 4, TS.

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

На Хабре десятки статей про вайбкодинг. Есть переводы сравнений v0 vs Bolt vs Lovable, есть манифесты «вы всё проспали», есть личные истории «навайбкодил сайт за три дня». Но ни одной статьи, где кто-то берёт одно конкретное ТЗ и прогоняет его через все доступные AI-генераторы — западные и российские — с честными скриншотами результатов.

Я это сделал. Одна бургерная, восемь платформ, ноль иллюзий.

В 2013 году на Randomwire была опубликована интересная статья. В ней автор указал на интересные особенности японского дизайна. Японцы известны своим минимализмом, но в случае сайтов у них, почему-то, всё наоборот. Страницы пестрят всевозможными цветами, что уже нарушает 3 принципа дизайна, плюс на них используются мелкие иконки и мно-о-о-о-го текста.  Да вы и сами видите пример этого буйства фантазии на скриншоте выше, сделанном в ноябре 2022 года.

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

И вот мне стало интересно, как обстоят дела сейчас, и можно ли как-то количественно оценить дизайн японских сайтов? Собственно, этим я и занялся.

Последние полгода ко мне приходили задачи, которые вынуждали покопаться в некоторых особенностях WebAssembly.

Это, в свою очередь, подтолкнуло меня покодить на Си (чего я не делал сто лет) всякое, ориентируясь на WASM.

А это уже натолкнуло меня на мысль: а не подойдёт ли связка JS+WebAssembly как инструмент для создания минифицированных проектов в духе демосцены?

Короче, хоть я к демосцене никаким боком, но что мешает мне написать игрульку в сайз-факторе 4K? Исключительно for fun.

Сегодня утром я прошёл лайв-кодинг в одну англо-продуктовую компанию. Написал ноль строчек кода руками. Задеплоил результат на свою VPS прямо во время звонка. Интервьюер сказал: "It's so wonderful just how much everything has changed." А неделю назад другая компания не зачла мне тестовое, потому что я забыл про запрет AI.

20+ собесов за последние месяцы. Фронтенд, бэкенд, фулстек, AI-инженер. Python, TypeScript. Разные рынки, разные компании, совершенно разное отношение к одному и тому же инструменту. Я не теоретик, который рассуждает о будущем. Я прямо сейчас хожу на эти собесы и вижу, как рынок разламывается пополам.

Это разбор реального опыта внедрения доступности в крупном веб-продукте с десятками микросервисов и сложным фронтендом. Без лозунгов, зато с кодом, ошибками, переработками дизайн-системы и неожиданными проблемами в CI. Поговорим про ARIA, серверный рендеринг, мобильные скринридеры, автоматическое тестирование и про то, почему доступность — это не про alt у картинок, а про архитектуру.

Когда я впервые услышал фразу сделаем доступность, я честно подумал: окей, добавим alt, поправим контраст, закроем задачу. Спойлер — это был самый наивный момент за весь проект.

Мы работали над крупной B2B-платформой. Много форм, таблиц, кастомных контролов, графиков, drag-and-drop, модалки внутри модалок. И в какой-то момент заказчик сказал: продукт должен соответствовать WCAG 2.1 AA. Причём не формально, а чтобы им реально могли пользоваться люди с ограничениями по зрению и моторике.

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

Давайте по порядку.

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

В части 1 мы выяснили, что объекты в Heap не освобождаются сами по себе этим занимается Garbage Collector. Но как именно GC решает, что можно удалить? Если подумать, задача не такая очевидная: объект не нужен - понятие логическое, а GC работает с физическим графом ссылок.

Ответ в том, что GC не пытается угадать намерения программы. Он задаёт более простой вопрос: можно ли добраться до этого объекта из работающего кода? Если нельзя объект недостижим, и никакой код уже не сможет его использовать. Значит, память можно вернуть.

Алгоритм, реализующий эту логику, называется Mark and Sweep.

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

Получается парадоксальная ситуация: людям, которые просто хотят посмотреть котиков на YouTube или спросить ChatGPT о какой-нибудь ерунде, снова начинают вставлять палки в колёса.

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

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

Всем привет! Меня зовут Саша, и последние 12 лет моя жизнь — это дизайн. Сегодня я руковожу дизайн-командой в KISLOROD, а в прошлом — помогал крупным брендам и миллионным сервисам обрести их уникальный голос и форму.

Сегодня расскажу о реализации удобного функционала фильтрации и сортировки товаров.

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

Веб-сокеты (WebSocket) — набор правил для двусторонней связи между браузером и сервером в реальном времени. Если HTTP работает по принципу "спросил - ответил", то протокол веб-сокетов предусматривает постоянный канал: сервер может сам отправлять данные браузеру, не дожидаясь запроса. Именно по этому протоколу работают чаты, онлайн-редакторы, многопользовательские игры.

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

Привет, друзья!

В этой небольшой статье я расскажу вам о новом свойстве события toggle - source, а также о новом атрибуте HTML-элемента dialog - closedby.

Свойство source позволяет определять источник переключения видимости поповера (popover), а атрибут closedby позволяет декларативно управлять логикой закрытия dialog, но обо всем по порядку.

Привет! Я — Аля, старший продакт-менеджер выделенных серверов в Selectel. Представьте, вашей команде нужно разработать новый интерфейс для продукта. Вы ставите задачу на дизайнера, а он приносит статичные картинки экранов в Figma. На встрече команда смотрит на них и понимает, что половина сценариев не продумана. Возникают вопросы: «Что будет, если пользователь нажмет на кнопку или данные не загрузятся?» И вместо того, чтобы передать задачу в разработку, вам приходится выяснять детали в комментариях и чатах.

Нам это хорошо знакомо. Долгие циклы согласований, переделки после релиза, сложности с тестированием — все это было частью нашего процесса. Чтобы решить эти проблемы, мы решили попробовать AI-инструменты для прототипирования. В статье расскажу, как Figma Make и другие сервисы помогли нашей команде ускорить создание прототипов и сократить количество правок. Будет полезно тем, кто устал от цикла «получить макет → найти проблему → подождать правки → повторить».