Привет! Я Оля, лид дизайн‑системы Альфа‑Банка на мобильных платформах и я всерьёз считаю, что знания о вёрстке незаслуженно списали со счетов, особенно в 2026 году, когда дизайнеры всё чаще думают, что ИИ сделает за них всю работу, а вёрстку вообще можно не трогать.

Увы и ах. Вёрстка — это не просто «разложить прямоугольники на макете». Это мост между дизайном и кодом.

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

Сайт запустили два месяца назад. Дизайн стильный, кнопки нажимаются, оплата проходит. Но органического трафика – ноль. SEO-специалист проводит аудит и выдаёт вердикт: «Нужно переписывать половину сайта. Каталог отрисовывается на клиенте через JavaScript – поисковый робот видит пустую страницу. URL-адреса выглядят как /page?id=37841. Структура заголовков отсутствует. Бюджет на разработку уже потрачен, и каждый час переделок стоит новых денег.

Знакомая ситуация? Она повторяется в половине проектах что приходят ко мне. Внедрение SEO на этапе разработки просто не запланировали. А ведь любой баг, пойманный на стадии проектирования, обходится в разы дешевле, чем тот же баг после релиза. Для SEO это правило работает точно так же: исправить структуру URL в проекте – 15 минут. Переделать маршрутизацию на продакшене – несколько спринтов и нервы всей команды.

Эта статья – мостик между SEO-специалистами и IT-командой. Вы узнаете, в какие именно точки жизненного цикла разработки ПО (SDLC – Software Development Life Cycle) встраиваются SEO-требования, и как разговаривать с разработчиками на одном языке.

Вчера на Хабре вызвал шумиху пост об ужасных неудобствах Mac. В комментариях много было сказано о неинтуитивности macOS: мол, зачастую без гугления не поймёшь, как что-то сделать. И даже не узнаешь, что это вообще возможно сделать. И всё это значит, что с UX что-то не так.

Тут возникает вопрос «а поняли бы мы Windows без гугления, если бы не были знакомы с ней с детства?» Но я хочу не ввязываться в бесконечные споры «какая ОС лучше» а подойти конструктивнее. Действительно, при переходе с Windows возникает ряд неинтуитивных моментов. И чтобы при этом не приходилось гуглить кучу разных вопросов или читать длиннющие пользовательские руководства, я решил описать в одном тексте самые главные вещи, которые приходят мне в голову.

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

После очередного звонка с шефом в 22:00 я психанул и написал заявление.

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

80% из 250+ сайтов к аналитике которых у меня есть доступ уже получают трафик из нейросетей. ChatGPT, Perplexity, Алиса, DeepSeek, Cloude — новые источники трафика растут месяц от месяца.

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

Представляю вашему вниманию перевод статьи "Prompt Engineering" (Промпт-инжиниринг) авторства Lee Boonstra - Software Engineer Tech Lead, Office of the CTO в Google.

Это первая часть из цикла трех статей, где мы разберем основы промпт-инжиниринга и базовые техники взаимодействия с большими языковыми моделями. Вы узнаете, как настраивать параметры моделей, использовать различные типы промптов и получать предсказуемые, релевантные результаты. Несмотря на фокус оригинала на Gemini/Vertex AI, описанные принципы применимы ко всем современным моделям ИИ.

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

С 12 марта 2024 года показатель FID (First Input Delay) из семейства Core Web Vitals заменён новой метрикой — INP (Interaction to Next Paint), которая отражает скорость отклика сайтов. Необходимость такой замены, среди прочего, подтверждают данные об использовании Chrome: согласно им, 90% времени пользователь проводит на странице после её загрузки. Таким образом, важно тщательно измерять скорость реагирования сайта на протяжении всего жизненного цикла страницы. В этом и помогает метрика INP.

Меня зовут Коновалов Илья. Я Performance Engineer и Front-end Developer в медицинской компании «СберЗдоровье». В этой статье я расскажу, что такое INP и как работать с новой метрикой.

Эта статья - сборник разных вопросов и ответов на них, которые звучали в комментариях к моим предыдущим статьям (Современные технологии обхода блокировок: V2Ray, XRay, XTLS, Hysteria, Cloak и все-все-все, Bleeding-edge обход блокировок с полной маскировкой: настраиваем сервер и клиент XRay с XTLS-Reality быстро и просто и других из той же серии) и в личных сообщениях.

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

Вы, наверняка, помните отличный цикл статей на Хабре в прошлом году от пользователя MiraclePtr, который рассказывал о разных методах блокировок, о разных методах обхода блокировок, о разных клиентах и серверах для обходов блокировок, и о разных способах их настройки (раз, два, три, четыре, пять, шесть, семь, восемь, десять, десять, и вроде были еще другие), и можете спросить, а зачем еще одна? Есть две основные причины для этого.

Для любого разработчика глубокое понимание основных принципов системного проектирования является необходимым условием для создания стабильных и масштабируемых программных систем, способных обеспечивать высокую производительность. Системное проектирование (System Design) включает разработку архитектуры и структуры программной системы, направленную на удовлетворение специфических требований и обеспечение требуемых показателей производительности.

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

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

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

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

Как с помощью Jobs To be Done принимать продуктовые решения, и почему сейчас мы используем этот подход для работы над нашими продуктами.

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

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

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

Меня зовут Денис Соловьев, и так получилось, что я работал и продолжаю работать как раз на таких внутренних ИТ-продуктах. Я хочу сравнить, какие из инструментов и подходов работают для них.

В жизни любого разработчика наступает момент, когда он роняет прод. Представьте: полдень, в Skyeng час пик, тысячи запланированных онлайн-уроков, а наша платформа лежит… 

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

> С 10 апреля 2024, 3 месяца спустя,
> данная статья заблокирована РКН на территории РФ,
> её также удалили с веб-архива archive.org.
> Статья на Хабре осталась доступна с IP других стран.
> Да, теперь, чтобы читать про ВПН, нужен ВПН.

На фоне прошлогоднего обострения цензуры в РФ, статьи автора MiraclePTR стали глотком свободы для многих русскоязычных айтишников. Я же хочу приоткрыть дверь к свободной информации чуть шире и пригласить «не‑технарей» («чайников»), желающих поднять личный прокси‑сервер для обхода цензуры, но дезориентированных обилием информации или остановленных непонятной технической ошибкой.

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

Статья рассчитана на «чайников», не знакомых с предметной областью. Однако и люди «в теме» могут найти нечто полезное (например, чуть более простую настройку проксирования через CloudFlare без необходимости поднимать nginx на VPS).

Если у вас ещё нет личного прокси для обхода цензуры — это знак.

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

В начале — пару слов о себе. Меня зовут Полина и я работаю «Rocket Business» уже несколько лет. Свой путь от джуна до тимлида прошла именно здесь. Поэтому своим мини-пособием решила делиться в корпоративном блоге: оставляю в помощь потомкам и аудитории Хабра. 

Привет. Я Марат Сибгатулин — сетевик в Яндексе, работаю в команде Yandex Infrastructure. И сегодня я расскажу вам одну поучительную историю.

Жили были два сервера. Да и не сервера вовсе, а виртуальные машины. Жили не тужили, добро наживали, скриптами разными обрастали. Три года они трудились на славу облака да во имя автоматизации. Пока не наступили чёрные дни для RAID-массива на гипервизоре.

Привет! Меня зовут Дима, и я почти два года работаю в Ozon. Я пришёл продакт-менеджером, а через год стал руководителем отдела, при этом продуктовая составляющая моей работы никуда не делась. Сейчас моя команда развивает платформу для создания чат-ботов, где наш флагман — это чат-бот клиентской поддержки внутри нашей WebCRM, где происходит вся магия общения с пользователями. 

Исторически сложилось, что в Ozon основной объём поддержки осуществляется через чат. В 2020 году бот закрывал 27% от общего числа обращений, а в 2022-м — уже 62%. Это сотни тысяч тикетов в день, при этом качество ответов не ухудшилось. Важность чат-бота выросла в разы.

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

Все, кто сталкивался с версткой писем, знают, что там по-прежнему используется табличная верстка, инлайновые стили, css хаки, устаревшие теги и т.д. И все это ради поддержки всех (или, вернее сказать, большинства) почтовых клиентов: различных версий Outlook, веб-интерфейсов почтовиков и мобильных почтовых клиентов.

Но индустрия не стоит на месте - все активнее для верстки писем применяются емейл-фреймворки. О них и пойдет речь дальше. Сравним 2 из них: MJML и TJML framework (хотел добавить еще и Zurb Foundation for email, но они в последних публикациях уже не говорят о поддержке outlook, да и в принципе устарели).

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

TJML- это мой емейл-фреймворк, который создавался на основе личного многолетнего опыта работы в сфере емейл-маркетинга. В нем я постарался учесть все те проблемы и сложности, с которыми сталкивается верстальщик писем. Идея была в том, чтобы не просто обеспечить “приемлемое отображение” в большинстве клиентов”, а дать свободу верстальщику, при этом не обременяя его вопросами совместимости с устаревшими почтовыми клиентами. Ну и, плюс ко всему, дать возможность заложить в единый код как html, так и AMP-версию письма. Но в этой статье речь пойдет пока что только о html.

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