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

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

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

Привет, Хабр! Меня зовут Сергей, я фронтенд-инженер в Банки.ру.

В этой статье расскажу, как Zod помог нам перестать писать валидацию на уровне полей, подружился с React Hook Form и стал единым источником правды о структуре данных.

К Zod мы пришли не сразу. Долгое время типы и валидация у нас жили в разных слоях приложения: TypeScript определял структуру данных во время разработки, а отдельные функции или библиотеки (вроде Yup) проверяли входящие значения в рантайме.

Это классическая проблема: дублирование логики и рассинхрон. Типы в interface поменялись, а валидация осталась прежней (или наоборот). Мы пробовали Yup, но он казался громоздким в связке с TS: типы приходилось выводить вручную или мириться с тем, что схемы выглядят непрозрачно. В какой-то момент стало непонятно: зачем тащить отдельную библиотеку, если проще написать if (typeof x === 'string')?

С переходом на Zod всё стало значительно проще: одна схема одновременно является и валидатором, и источником типа данных.

Привет, Хаброжители! Node.js — это технология, которая изменила современный веб. Более 10 миллионов разработчиков по всему миру используют ее для создания быстрых и масштабируемых приложений.

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

Вы научитесь создавать надежные, быстрые и масштабируемые приложения, востребованные в таких компаниях, как Amazon, Netfl ix, LinkedIn.

Недавно на Хабре вышла статья про создание RAG-системы для строительных ГОСТов. Команда Цифрового стандарта проделала титаническую работу — полгода вручную разбивали документы на смысловые чанки. Респект за настойчивость и результат.

Их история вдохновила поделиться собственным опытом. Мы тоже столкнулись с проблемой чанкования для умного поиска по базе знаний. Тоже прошли через RAG, векторные базы и поиски оптимального решения. Но пошли по пути полной автоматизации.

Всем привет, меня зовут Дима, я делаю ИИ-функции в Gramax. Эта статья для тех, кто сейчас воюет с чанками вручную или пытается найти оптимальный подход. Делимся нашим путем от быстрого прототипа до продакшен-решения с метриками 90%+.

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

Многие годы нам продают BDD (Behavior-Driven Development) как "серебряную пулю" для коммуникации...

Давайте честно, это чушь. Никогда не понимал, зачем мы кормим этого монстра по имени Cucumber. Тратим до 50% времени на поддержку регулярок («клея»), возимся с хрупкими .feature файлами и боимся переименовать шаг, потому что все развалится. При этом ни один менеджер в здравом уме не заходит в ваш репозиторий читать эти файлы. Они все смотрят только отчеты.

Так зачем нам Gherkin на этапе написания кода? Представляю вам новую методологию BDR (Business-Driven Reporting).

Почему классический BDD (Gherkin) - это ошибка?

Gherkin заставляет инженера работать внутри IDE, как в текстовом блокноте. Это абсурд.

Всем привет, меня зовут Паша и я Head of QA. Ну… был им до недавнего времени. Мы оказались в банальной ситуации: проект пришлось приостановить по независящим от нас причинам — и я снова оказался «в поиске интересных возможностей».

И опять упёрся в саму парадигму найма. Бесконечная война соискателей и рекрутеров: одни не могут нормально рассказать, что умеют, вторые не знают, кого искать. В итоге ищут не человека, а функцию — и важно не то, как ты думаешь, а какие теги у тебя есть, чтобы пройти фильтры ATS. Эта парадигма ломает саму суть задачи найма.

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

Так появилась идея сделать собственный сайт. Не классическое резюме и не список технологий, а персональную визитку, более ориентированную на техлидов и C-level, чем на эйчаров и автоматические фильтры. Сам сайт я хотел сделать нескучным и изначально видел в голове в стилистике окна персонажа из Fallout 2 — с атрибутами, самооценкой скиллов, перками, и ироничным описанием.

И я осознаю: сам, без ИИ, я бы за это никогда не взялся. У меня поверхностное знание фронтенда, я не дизайнер и не веб-разработчик. Но у меня есть опыт производства IT-продуктов в целом — и мне стало интересно проверить вайбкодинг на практике.

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

Если хотите — вот сайт: pavel.rocks (для полного погружения лучше смотреть с десктопа, под мобилу я постарался адаптировать на современный лад).

А под катом — подробный рассказ о процессе: как я к этому подошёл, на какие грабли наступал, почему мобильный адаптив оказался сложнее, чем весь остальной сайт, и при чём здесь дихотомИИя. Ну или просто заходите, если вы любите Fallout 2 так же как я.

Недавно я публиковал статью про HeadHunter. Судя по количеству комментариев, она взбудоражила сообщество и превратилась в настоящее поле для дискуссий.

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

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

Редизайн сайта Артемия Лебедева – каждый раз, когда я заходил на сайт tema.ru мне становилось интересно, а как можно его обновить. И вот однажды идея появилась, а потом проросла в моей голове. Сайты умираю, ИИ развивается и нам нужен принципиально новый формат. Шалость удалась — с радостью делюсь с вам получившимся результатом.

Задача. Сделать редизайн сайта.

Важно. Это не коммерческий заказ, a просто моё упражнение и развлечение для души и мозга.

27 апреля 2021-го года Международная типографическая ассоциация объявила об отказе от спецификации Vox-ATypI. Историческая классификация, которой типографы пользовались более полувека, канула в Лету. Что же пришло на смену этой классификации? Ничего!

Самое забавное, что сейчас, в первой четверти ⅩⅩⅠ-го века, конструкторы шрифтов, проектировщики интерфейсов приложений Веба и верстальщики гипертекста оказались в той же ситуации, что и типографы сто лет назад. С одной стороны нарастающее количество шрифтов и изменение технологии типографики (экранное отображение, вариативные шрифты и т.п.). А с другой — отсутствие надёжных ориентиров и навигации в этом типографическом океане.

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

Зачем изобретать свой Street View?

Все мы привыкли к Google Street View, но что, если нужно показать пространство, куда машина со 360-камерой не заедет? Интерьер офиса, музей, университетский холл. Коммерческие решения для виртуальных туров часто дороги или ограничены в кастомизации.

Мой друг попросил помочь ему с экселем. Он пусконалаживает-чинит-сопровождает всякие станки на всяких заводах и его контора, хоть и ведет дела в 1С, но это чисто бюстгалтерский учет и какому клиенту какая запчасть едет и на каком этапе ремонт конкретного станка — бюстгалтерии неведомо. Поэтому друг мой ведет записи в экселе. Точнее вел, пока станков этих было немного. А вот как их перевалило за десяток — тут-то его познания в экселях уперлись в потолок, а сам эксель стал как-то не очень шустро поворачиваться.

Я в экселях полный "тук-тук кто там", точно знаю что он понимает в его сортах гораздо круче меня, поэтому заинтересовался и за кружкой пенного стал выведывать его истинную боль. Ага, примерно как делают настоящие взрослые дяди-аналитики перед постановкой задачи нам, разрабам.

Потому что у заказчиков так бывает: в ТЗ написали одно, думали при этом другое, а на самом деле проблема предприятия в третьем.

Оказалось что у друга моего проблема вовсе не в экселе.

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

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

Простые вырезы теперь делаются в десять раз быстрее. Одной строчкой кода. Да, надо менять мышление и забывать про нарезку блоков. И как же это приятно!

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

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

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

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

Я не нашел на хабре достойного представления фрейморка Jaspr сообществу и решил представить сам. Flutter, безусловно, хорошая магия: один код для всех платформ, в том числе и Web. Но за магию приходится платить. Платить мегабайтами загрузки, муками с SEO и ощущением, что ты принёс на пляж боулинг — вроде и весело, но как-то не к месту. Команда Flutter и сама честно говорит: Flutter Web создан для веб-приложений, а не для веб-сайтов. Для сложных дашбордов, PWA, для всего, что живёт за логином — да. Для контентного сайта, блога, лендинга — увы.

Знакомьтесь, Jaspr. Веб-фреймворк на Dart, который осознанно отказывается от канваса и пиксельной магии Flutter в пользу старого доброго HTML и CSS. Он выглядит как Flutter, ощущается как Flutter, но на выходе даёт то, что поисковики и браузеры любят и понимают: обычный HTML-документ и DOM. А попробовать на вкус его можно здесь.

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

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

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

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

Что должен делать разработчик, чтобы проект, над которым он работает, не имел проблем? Очевидно — нужно просто исправить все баги и больше не писать новых. 

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

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

В этой статье — история трансформации 2ГИС ПРО: от перегруженного картографического интерфейса для гиков до гибкой платформы, где любой может собрать себе рабочее пространство под конкретную задачу.

Расскажу, как мы:

• отказались от устаревших слоёв в пользу виджетов,
• пересобрали интерфейс вокруг единого дашборда,
• внедрили независимую логику для виджетов,
• переехали на сетку, виртуализацию и архитектуру, вдохновлённую микросервисами,
• сделали миграцию незаметной для пользователей.

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

Мы привыкли видеть Telegram как список чатов и каналов на своём устройстве. Но это лишь малая часть большой экосистемы, ограниченная подписками каждого пользователя. А как выглядит вся экосистема целиком? Эта статья — о том, как мы провели масштабное исследование контента Telegram и разработали интерактивную карту с 500 000 каналами.

Январь 2026 года. Ты листаешь ленту за утренним кофе и видишь, как люди массово скупают Mac Mini или арендуют VPS сервера. Не для разработки. Не для монтажа видео. Для бота. AI-бота, которому нужен целый компьютер, чтобы работать 24/7.

За две недели проект набирает почти 100 000 звёзд на GitHub. Сто. Тысяч. Для сравнения: у React 234K за 11 лет. А тут за месяц чуть ли не половина этого. TechCrunch, VentureBeat, IBM, Cisco- все пишут. Cloudflare запускает специальный сервис под него, и их акции подскакивают на 20%. Anthropic присылает автору письмо: "Братан, переименуй, слишком похоже на Claude". Он переименовывает. Дважды (для контекста: сначала это Clawdbot, потом становится MoltBot и вот наконец января 2026 это OpenClaw, надолго ли?).