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

На днях я стряхнул пыль с небольшого пет-проекта. Это простой блог, наверняка каждый из вас хотя бы думал о таком для себя.
В 2015 году я бы просто закинул файлы по FTP на хостинг за 100 рублей. Время деплоя: 30 секунд.
В 2026 году я потратил 4 часа. Я настраивал Edge Middleware, дебажил рассинхрон HTML между клиентом и сервером (hydration mismatch) и разбирался, почему облако не хочет дружить с моей базой данных из-за долгого пробуждения функций (холодного старта).

Где мы свернули не туда?
Это колесо Сансары, которое дало новый оборот.

Давно хотели «потрогать» IT своими руками, но боялись утонуть в сложных терминах, математике и алгоритмах? Давайте начнем с самого простого.
В этой статье мы без скучной теории и академичного снобизма разберем, как работает HTML — фундамент любого сайта в интернете. Спойлер: это не язык программирования, и здесь невозможно ничего сломать! А главное — всего за 20 минут мы с абсолютного нуля напишем вашу первую настоящую веб-страницу (сайт-визитку). Если вы искали идеальную песочницу для старта в веб-разработке — добро пожаловать под кат.

10 лет назад OpenVPN считался надёжным инструментом. Сегодня он блокируется за секунды. За это время сменилось пять поколений протоколов — каждый новый рождался как ответ на то, чему научился цензор. Это история гонки вооружений между математикой и политикой. И она ещё не закончена.

И где мы сейчас ?

🚀 Nginx на автопилоте: Как я перестал тратить время на конфиги и SSL

Бывает так: у тебя есть крутая идея для проекта, ты быстро кодишь бэкенд, но когда дело доходит до деплоя... Вечер превращается в бесконечную настройку Nginx, борьбу с Certbot, прописывание HSTS-заголовков и попытки вспомнить, как там правильно настраивается кеширование.

Знакомо? Мне — да. Именно поэтому я собрал nginx-template — инструмент, который превращает администрирование сервера в удовольствие. 🛠

Это не просто набор файлов, это полноценный пульт управления вашим сервером через один скрипт — manage.sh.

Почему вам стоит это попробовать:

🔹 Скорость деплоя: Добавление нового домена с автоматической выдачей Let's Encrypt занимает ровно одну команду. Без правок конфигов руками и перезагрузок.

🔹 Image Proxy из коробки: Хотите ресайзить аватарки на лету прямо через Nginx? Теперь это делается одной командой без сторонних микросервисов.

🔹 Умный CDN: Поднимайте кеширующие узлы для статики за секунды. Разгружайте основной сервер и радуйте пользователей мгновенной загрузкой.

🔹 Профессиональная безопасность: Конфиги уже оптимизированы под требования SSL Labs (рейтинг A+), включают защиту от эксплойтов и автообновление IP Cloudflare.

Никаких тяжелых интерфейсов и лишних абстракций. Только чистый, производительный Nginx в Docker и удобная автоматизация на Bash. Вы сохраняете полный контроль над каждым байтом конфига, но избавляетесь от всей рутины.

Пора тратить время на код, а не на настройку прокси. ⚡

🔗 Забирайте готовый стек здесь: github.com/Arlandaren/nginx-template

Понравился подход? Ставьте ⭐ на GitHub — это лучший способ сказать «спасибо» и поддержать развитие Open Source!

Еще пару лет назад веб жил в простой и понятной модели: есть сайты, есть поисковые роботы, есть пользователи. Роботы приходят, сканируют страницы, кладут их в индекс — дальше начинается привычная борьба за позиции в выдаче. Эта логика десятилетиями определяла, как мы строим сайты, настраиваем SEO и пишем robots.txt.

С появлением LLM-агентов эта модель начала трещать по швам.

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

Если вы пишете бэкенд на Python или только собираетесь вкатиться в эту тему, вы точно слышали про FastAPI. Он обещает скорость NodeJS, автодокументацию из коробки и строгую типизацию. Звучит круто, но для новичка любая новая технология выглядит пугающе.

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

Обзор на браузерные API, которые стали Widely available в феврале 2026. Раз в месяц я буду вам напоминать, что вы уже можете использовать в проде. В этом месяце всё довольно скучно и одиноко.

Каждый месяц выходят новые CSS-свойства, HTML-атрибуты, JavaScript-методы и WebAPI, но применять в проде мы их конечно же не будем. 2.5 года назад также каждый месяц выходили новые фичи в браузере, а вот их уже пора начинать применять.

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

Первая мысль — взять готовый движок и допилить под себя, в открытом доступе уже есть: lynx, vichan, wakaba, kareha, fchannel. Потыкался — ничего не понятно. Как ленивый человек решаю, что надо писать своё.
На тот момент я:

Не понимал разницу между HTTP и HTTPS

Не знал, что такое handler, router, middleware

Считал, что DNS — это какой-то раздел электронной музыки

Думал, что куки и кэш — это одно и то же

Не без труда отличал header от body

Не мог пропатчить kde2 под freebsd

Короче говоря, я был именно тем человеком, который должен был писать проект с нуля. Цель понятна, надо выбрать инструменты. Я неплохо знал питон и c++... поэтому языком разработки выбрал Голанг. Мой опыт с Голангом на тот момент ограничивался прослушанным фоном на х2 ШАДовским курсом. Прослушал я его в автопоездке Москва — Челябинск. Не написал на Го ни одной строчки кода, но суммарно прослушал — именно «прослушал», ибо рассмотреть мелкий шрифт на экране телефона, будучи за рулём, решительно невозможно — около 30 часов материала. Написать свой движок имиджборды - хороший повод попрактиковаться.

Если вы пишете сложный 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.