Фронтенд

30 лет без дизайна и миллиард в кассе

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

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

Для тех, кто не в курсе: Craigslist - это что-то типа Авито, но в США, т.е. такая гигантская доска объявлений. Ее дизайн застрял где-то в 1998 году: синие ссылки, простейшая верстка, ноль графики. По любым современным меркам UI/UX - это катастрофа. При этом компания с крошечной командой зарабатывает сотни миллионов (а по некоторым оценкам - более миллиарда) долларов в год. Работает там от силы 50 человек (!) Если пересчитаем выручку, то окажется, что на каждого сотрудника приходится 4 млн. долларов в год (!) Очень круто!

И тут я смотрю на Craigslist и понимаю: их «ужасный» сайт — это моя «неудобная» гостевая книга, только в масштабе всей Америки. Они поняли то, чего не понял я в 20 лет, и не стали «чинить» то, что не сломано.

Почему этот «примитивный» дизайн работает и приносит миллиарды?

1. Скорость. Сайт загружается мгновенно. Нет тяжелых фреймворков, мегабайтов JavaScript и аналитических скриптов. Чистая функция.

2. Плотность информации. Никаких баннеров, всплывающих окон и модных карточек. Только текст и ссылки. Вы видите максимум полезной информации на одном экране.

3. Отсутствие трения. Хочешь разместить объявление? Нажимай и размещай. Не нужна регистрация (как я понял), подтверждение почты и двухфакторная аутентификация, чтобы продать старый стул. Сервис не мешает тебе делать то, зачем ты пришел.

4. Привычка. Миллионы людей пользуются им десятилетиями. Они знают каждую ссылку наизусть. Любой редизайн вызовет у этой аудитории не восторг, а гнев. Они потеряют свой привычный и предсказуемый инструмент.

Мой «улучшенный» форум вводил трение: регистрация, создание тем, сложная структура. Я убил легкость и анонимность. Точно так же любой «современный» редизайн Craigslist с React, модными анимациями и персонализацией убьет его главное преимущество - скорость и простоту.

Вывод для любого IT-руководителя:

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

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

А в вашей практике есть свой внутренний «Craigslist»? Старый, неудобный, но незаменимый сервис, который все мечтают переписать, но боятся трогать?

---

Понравилась эта история? Это пример того, как я анализирую ошибки и извлекаю из них практические уроки. В моем ТГ канале Код ИТ-директора я гораздо чаще делюсь подобными мыслями, короткими кейсами и полезными инструментами, которые не всегда доходят до формата большой статьи.

Там — больше «живых» заметок из окопов управления IT-бизнесом и возможность напрямую задать вопрос.

Подписывайтесь, что бы получать больше инсайтов без воды Тыц

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

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

Теперь реки, озёра и моря на карте 2ГИС стали реалистичнее — с солнечными бликами и волнами.

Для начала, чтобы придать поверхности глубину и рельефность, мы перешли от плоских текстур к текстурам с нормалями. Это позволило воде реагировать на свет: в зависимости от направления освещения она начинает вести себя по-разному — появляется объём, тени на гребнях, есть ощущение материи.

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

Увидеть это великолепие уже можно в веб-версии 2ГИС и в самых свежих версиях для мобильных платформ.

Про текстуры ещё можно прочитать в наших статьях про небо и освещение.

🔥 Монолитный фронтенд тормозит ваш проект? Пора задуматься о микрофронтендах!

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

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

📅 Дата: 14.08.2025

⏰ Время: 17:00-18:00 (Мск)

👨‍🎓 Спикер: Акманова Елизавета — старший аналитик ГК «Юзтех», преподаватель школы системного анализа.

Что будет на эфире?

✔️ Разберем объективные причины, которые подтолкнули нас к смене архитектуры.

✔️ Реальные плюсы и минусы микрофронтендов.

✔️ Практические кейсы, неочевидные вызовы и решения.

✔️ Честные выводы и советы, чтобы ваш переход был максимально гладким.

👉Зарегистрироваться

SOLID как священная корова? 🤔
Я думал, что пост о «фальшивых сеньорах» пройдёт спокойно — ну, очередной крик души о собеседованиях. 😅 Но нет! Хабровчане увидели слово «SOLID» и решили, что это вызов их святыне. Хотя я ничего плохого про него не сказал — просто отметил, что в React 2025 спрашивают про него по инерции. 😕

Где магия, а где фарс? ✨
Комментатор с саркастичным «быдлокод» (спасибо за реакцию, коллега!) будто подтвердил мою мысль: SOLID — это не религия, а инструмент. 🛠
SRP (Single Responsibility) в React — это о компонентах. Но если ваш «компонент формы» содержит логику, стили, валидацию и даже полёт на Марс, это не нарушение SOLID’а, а просто плохой код. 🌙
DIP (Dependency Inversion) в мире хуков и Context API чаще выглядит как «передать пропс» или «создать useClient», чем как «абстрактный фабричный фасад». 🧩
LSP (Liskov Substitution) в функциональном программировании? Его там просто нет. Или вы верите, что Button и IconButton должны наследоваться от AbstractClickable? 🤔

Если кандидат не может объяснить даже это, а только бормочет о «SOLID — это про ответственность» и использует ChatGPT, это не про принципы, а про некомпетентность. 🙅‍♂️

Про GPT и кандидатов-попугаев 🦜
«Чатжпт вам расскажет» — именно! Но если человек не может пересказать своими словами, он не понимает. А если не понимает, как он будет применять это на практике? 😵

Вывод 📜
SOLID — это хорошо. Плохо — догматично использовать его без понимания, где он нужен, а где создаёт лишние сложности. 🚫

🤡 «Фальшивые сеньоры»: как меня пытались обмануть кандидаты

Кандидат с «идеальной памятью»

Сидит передо мной разработчик. Отвечает на вопросы... странно:

Простые вещи вроде «что такое замыкание» — щёлкает как орешки.

Сложные вопросы — делает паузу на 15 секунд... и выдаёт академический ответ.

Решил проверить на практике:

✅ Теория — 10 из 10

❓ Практика — 6 из 10: простые и типовые задачи легко, рефакторинг с адской болью

❌ Объяснить, что и для чего делал — 0 из 10. Поддержать диалог, хоть как-то отойти от шаблонов — это всё не про таких кандидатов.

Напоминает студента, который выучил билеты, но не понимает предмет. Скорее всего, ему кто-то подсказывал, или он просто зазубрил типовые ответы.

«SOLID? Ну это когда ответственно»

Обычно я не люблю спрашивать про SOLID (кому вообще это нужно в React в 2025?). Но тут поведение кандидата было подозрительным — решил проверить.

Диалог:

— Расскажи про SOLID

— Это принцип единственной ответственности!

— Я жду продолжения

— Всё...

— Больше ничего не помнишь?

— Ну это основная часть....💥

Тут всё еще грустнее, видимо, GPT просто выкинул перед кандидатом 5 принципов без пояснения, что все 5 принципов образуют SOLID.

Так к чему это я:

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

MoscowJS 67 X A?.Frontend

Приглашаем вас на регулярную встречу фронтенд-сообщества в неформальной обстановке 28 августа. В этот раз — MoscowJS в гостях у Альфа-Банка.

В программе:

• От JavaScript к DeFi: как инженеры могут изменить мир финансов. Спикер: Даниил Швецов, Full Stack Engineer.
  Доклад познакомит JavaScript-инженеров с основами DeFi: ключевыми концепциями, математическими моделями и работой с JS SDK.

• Архитектура микрофронтендов: от А до Single Spa. Спикер: Павел Шлыков, Team Lead Frontend.
  Поговорим о микрофронтендах с нуля: от принципов и базовой реализации до инструментов вроде Module Federation и single-spa. Разберёмся, как всё устроено, и рассмотрим нестандартные подходы.

• Под капотом платформы. Спикер: Антон Марченко, Ведущий разработчик.
  Доклад об опыте сборки платформы из готовых решений и объединения приложений через iframe, Module Federation и webview. Узнаете про выбор подходов и работу с командами.

• Гильдия: место, где разработчик перестаёт быть одиноким кузнецом. Спикер: Владислав Сазонов, Head of Frontend.
  Чувствуете себя одиноким фронтендером? Есть решение — гильдия. В докладе — о том, как этот формат помогает расти, делиться опытом и не выгорать, а также краткий исторический экскурс.

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

Где: г. Москва, Андропова пр-т., 18, к. 3 (офис Альфа-Банка)

Вам не нужен Activity Bar в vscode!

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

Раз. Убираем Activity Bar. В нем есть три типа иконок: нужные нам часто, нужные иногда, совсем ненужные. Логика такая: для нужных мы создаем горячие клавиши (или пользуемся существующими). Для средне-нужных используем cmd+p и выбор команды. Ненужными – не пользуемся :)

Кастомные настройки для горячих клавиш для управления разными View (плюс к стандратным):

[
    {
        "key": "shift+cmd+g",
        "command": "workbench.view.scm",
        "when": "workbench.scm.active"
    },
    {
        "key": "ctrl+shift+g",
        "command": "-workbench.view.scm",
        "when": "workbench.scm.active"
    },
    {
        "key": "shift+cmd+o",
        "command": "outline.focus"
    }
]

Два. Убираем Side Bar. Большую часть времени он не нужен. В основном нам просто нужно читать и реже писать код. Зачем нам Side Bar? Убирается основной по cmd+b, а второй по cmd+alt+b.

Но если оставить Side Bar справа, то его появление / скрытие будет двигать код. Что будет мешать. Потому – убираем его вправо.

Настройки:

{
    "workbench.activityBar.location": "hidden",
    "workbench.sideBar.location": "right"
}

Три. И не забудьте поместить Command Palette в центр рабочей области. Так будет удобнее: появяться она будет сразу перед глазами. Просто перетаскиваем мышкой.

Ссылка со всеми материалами: https://github.com/sobolevn/the-best-python-course/blob/main/minimal_vscode Там будет много полезного.

TypeScript и C++ в одном бинаре. Первый open source-проект от МойОфис

Команда МойОфис выложила в open source собственную разработку — компилятор tsnative. Это кроссплатформенный инструмент, который объединяет удобство TypeScript с производительностью C++ в одном приложении. Исходники — на GitHub под лицензией Apache 2.0.

Компилятор tsnative — это первая и ключевая часть более масштабного проекта под названием AntiQ, в котором мы переосмысляем подход к кроссплатформенной разработке без тяжёлых фреймворков.

AntiQ разделен на два самостоятельных компонента. Сейчас в open source опубликован только tsnative — главный модуль, в котором сосредоточена основная логика и заложены архитектурные принципы всей платформы.

Зачем это нужно?

tsnative — это кроссплатформенный компилятор, преобразующий TypeScript в нативный машинный код. Он обеспечивает бесшовную интеграцию с C++ без glue-кода или JavaScript-движков, объединяя удобство высокоуровневой разработки с производительностью системного кода. В результате вы получаете один бинарник, собранный из двух языков.

Как это работает:

• C++-функции помечаются TS_EXPORT;

• генерируются .d.ts-декларации для TS;

• TypeScript- и C++-код собираются через LLVM;

• на выходе — один исполняемый файл, без обёрток.

// math.cpp
#include "TS.h"
TS_EXPORT int add(int a, int b) {
return a + b;
}
// index.ts
console.log(add(2, 3)); // -> 5

// index.ts
console.log(add(2, 3)); // -> 5

Проект может быть интересен тем, кто:

• делает нативные приложения, но хочет писать часть логики на TS;

• ищет замену закрытым коммерческим компиляторам;

• любит ковыряться в сборке, кросс-компиляции и низкоуровневом коде.

Открытый код — не просто «выложили и забыли». Мы хотим, чтобы проектом пользовались, коммитили, обсуждали. Поэтому будем рады pull request’ам, issue и звёздочкам. Всё как обычно :)

Исходники на GitHub

Если у вас есть вопросы или комментарии, вы можете задать их в чате проекта: https://t.me/antiqmyoffice

Представлен обучающий курс по Python под названием Advanced Python Mastery от Дэвида Бизли, автора нескольких книг-бестселлеров по этому языку программирования и одного из главных знатоков Python. В базе курса представлены данные по работе на уровне процессора и компилятора до продвинутых концепций программирования на Python и самых актуальных фреймворков, а также десятки материалов с PyCon.

Как провести идеально бесполезное собеседование для фронтендера!

Шаг 1: Берем «элитный» шаблон Яндекс.Мультитрека.

Шаг 2: Удаляем всё ценное — оставляем только хаотичный набор вопросов.

Шаг 3: Делаем вид, что это «специально под вакансию» (спойлер: одни и те же 40 вопросов получают все — от стажера до лида).

Главные хиты программы:

— «Назови 5+ способов центрировать div» (ведь React-лид должен уметь это с закрытыми глазами). — «Расскажи про Event Loop как стихотворение» (иначе как проверить лидерские качества?). — «SOLID наизусть, включая историю создания каждого принципа». — Секретный прием: задаем общие вопросы, но с видом эксперта ждем «правильного» ответа (который знает только интервьюер).

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

Гарантированный результат:

• Кандидат либо засыпает, либо пишет гневный пост.

• Ваша компания экономит на зарплатах — никто не доходит до оффера.

• Вы получаете статус «самое запоминающееся собеседование в карьере». Если узнали свою компанию — не переживайте, вы не одиноки в этом увлекательном квесте!

Где учиться фронтенду

Привет! Мы на Хабр Карьере собираем сотни онлайн-курсов в IT или digital на маркетплейсе курсов и каждую неделю делаем подборки обучений для тех, кто хочет учиться какой-то специализации с нуля или для тех, кто уже в профессии, но чувствует, что хочет прокачать навыки.

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

— HTML/CSS

Разметка и стилизация веб-страниц. HTML задаёт структуру, CSS отвечает за внешний вид, адаптивность и анимации.

— JavaScript

Язык для добавления интерактивности на веб-страницах. Используется в браузере и на сервере (через Node.js), лежит в основе большинства фронтенд-фреймворков.

— Git

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

— React

JavaScript-библиотека для создания UI. Использует компонентный подход и виртуальный DOM. Разрабатывается Facebook.

— Angular

Фреймворк от Google для построения SPA. Включает собственную архитектуру, TypeScript, DI, роутинг и инструменты для тестирования.

— Vue.js

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

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

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

→ Смотреть курсы по всем специализациям

minimal vscode: открываем окна

Нет, не от духоты, ее в видео как раз не будет 🌚️️️️
Видео короткое, динамичное, практичное.

Перед тем как учиться пользоваться vscode, необходимо:

1. Её поставить

2. Научиться её открывать

3. Располагать её на рабочем пространстве

Мой конфиг: https://github.com/sobolevn/dotfiles

В видео поговорили про: hotkey managers, тайлы, всякие красивости для macos.

Менеджеры горячих клавиш:

• jumpapp для Linux: https://github.com/mkropat/jumpapp и https://linux.die.net/man/1/wmctrl

• AutoHotkey для Windows: https://autohotkey.com

• whkd для Windows: https://github.com/LGUG2Z/whkd

• skhd для macos: https://github.com/koekeishiya/skhd

• skhd-zig для macos: https://github.com/jackielii/skhd.zig

Тайловые менеджеры:

• macos: https://github.com/rxhanson/Rectangle мой конфиг: https://github.com/sobolevn/dotfiles/blob/master/config/RectangleConfig.json

• macos более продвинутая альтернатива: https://github.com/ianyh/Amethyst

• самая продвинутая альтернатива для macos: https://github.com/koekeishiya/yabai

• Windows: https://github.com/LGUG2Z/komorebi

• Linux: ТЫСЯЧИ ИХ

Полезности:

• Top Notch для macos: https://topnotch.app

• HazeOver для macos: https://hazeover.com/ru

• Brewfile: https://docs.brew.sh/Brew-Bundle-and-Brewfile мой конфиг: https://github.com/sobolevn/dotfiles/blob/master/Brewfile

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

Сравнение производительности React-компонентов: Gravity UI vs другие библиотеки

Я core‑разработчик Gravity UI, и периодически нам в команду поступают вопросы про производительность react‑компонентов из нашей библиотеки @gravity‑ui/uikit. Я решил сделать небольшое исследование этого вопроса, и всё написанное ниже является отправной точкой для дальнейших исследований и попыткой ответа на вопрос «Почему Gravity тормозит?»

Обычно этот запрос пишут без дополнительных деталей, поэтому я исхожу из предположения, что одна (но, конечно же, не единственная) из основных проблем производительности — долгое время отрисовки. В рамках этого исследования мы рассмотрели затраты на первый рендеринг отдельных компонент каждой из библиотек в изолированной среде. Для сравнения были выбраны библиотеки @adobe/react‑spectrum, @mui/material и antd.

Методология исследования

Технический стек:

• Playwright — фреймворк для автоматизации тестирования кода в разных браузерах (подробнее).

• PerformanceObserver API — браузерный API для измерения производительности (подробнее).

Условия выполнения тестов:

• Каждый тест запускается в отдельном контексте браузера.

• Единовременно выполняется только один тест (настройка workers в конфиге Playwright), что гарантирует выделение одинакового количества ресурсов на каждый тест.

• Каждый тест повторяется 50 раз.

• Тесты проводятся с разным количеством нод (10, 100, 1000).

Порядок выполнения одного теста:

1. Открытие новой страницы в браузере.

2. Инициализация PerformanceObserver.

3. Начало сбора метрик.

4. Рендеринг компонентов.

5. Завершение сбора метрик.

Процесс измерения:

В начале каждого теста создаётся PerformanceObserver, который отслеживает события типа 'measure'. Все собранные метрики сохраняются в глобальном объекте __PERFORMANCE_METRICS__. Observer автоматически собирает данные о времени выполнения операций, включая название метрики, тип события, время начала и продолжительность. С помощью события measure мы логируем наше измерение total‑render‑time.

Результаты

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

1. @gravity‑ui/uikit показывает конкурентоспособные результаты:

   • В большинстве тестов находится в верхней части рейтинга.

   • Демонстрирует стабильное время рендеринга при разном количестве нод.

   • Особенно эффективен в компонентах Button, Checkbox и Switch.

   • Имеет проблемы со временем рендера компонента TextArea.

2. @mui/material также показывает хорошие результаты:

   • Лидирует почти во всех категориях (например, Text, Label) на небольшом количестве нод.

   • Имеет видимый рост времени рендера в зависимости от количества нод.

3. antd и React Spectrum:

   • Показывают более высокое время рендеринга в большинстве тестов.

   • Имеют больший разброс между минимальным и максимальным временем.

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

В этой статье я раскрыл один из примеров, как мы работаем с библиотекой. Но нам очень важна обратная связь от сообщества: если у вас есть конкретный пример, где Gravity UI показывает себя сильно хуже других библиотек, или если вы видите ошибку в нашей методологии тестирования, приходите в комментарии к этому посту или создавайте issue, обсудим. А также не забывайте ставить звёздочки проекту!

Обновлена информационная база JBook по изучению Java полностью на русском языке. Проект помогает выучить язык с полного нуля и до уровня поиска работы, включая концепции, приёмы, актуальные фреймворки, ООП, основные алгоритмы, паттерны решения задач и видеоразборы. Есть множество упражнений разного уровня сложности к каждой лекции. Проект развивается с 2018 года и постоянно обновляется вместе с версиями Java, документацией и новыми подходами к разработке.

Как скрыть Webvisor от Яндекс.Метрики во вкладке "Сеть" в DevTools

При отладке фронтенда или анализе сетевых запросов в DevTools часто возникает проблема: запросы к mc.yandex.ru (Webvisor) загромождают вкладку «Сеть» и мешают сосредоточиться на действительно нужных данных. Особенно если на странице активно работает Яндекс.Метрика с включённым Webvisor.

Хорошая новость: эти запросы легко отфильтровать или полностью заблокировать. Делюсь несколькими способами, как это сделать.

Этот способ касается и других типов запросов, мне лично мешают запросы от mc.yandex.ru.

Способ 1. Фильтрация через DevTools (Network)

Если не хочется ничего ломать, просто исключите Webvisor из отображения:

1. Откройте DevTools (F12 или Ctrl+Shift+I / Cmd+Option+I).

2. Перейдите на вкладку Network (Сеть).

3. В строке фильтра введите: -mc.yandex.ru

Способ 2. Полная блокировка через Request Blocking

Если вы не хотите, чтобы эти запросы вообще происходили:

1. Откройте DevTools.

2. Нажмите на три точки в правом верхнем углу панели → More tools (Другие инструменты) → Network request blocking (Блокировка сетевых запросов).

3. В появившемся окне добавьте правило: *mc.yandex.ru*

4. Включите галочку Enable request blocking.

Теперь DevTools будет блокировать запросы к Webvisor ещё до их отправки.

Способ 3. Расширения браузера (например, uBlock Origin)

Для более глобального решения можно использовать расширения:

1. Установите uBlock Origin.

2. В настройках фильтров добавьте правило: ||mc.yandex.ru^

Теперь все запросы к mc.yandex.ru будут блокироваться на уровне браузера.

Заключение

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

Если у вас есть свои хаки по "чистке" вкладки Network — делитесь в комментариях 👇

Выводим Соера на чистую воду разбирая дискуссию с ним про принципы SOLID

Топ перлов

• Если ты манки-патчишь объекты, то ты функциональщик.

• Ты должен сначала залезть на гору, а потом уже решить надо было тебе сюда или нет.

• Если люди по разному воспринимают принцип - это здорово, ведь он подталкивает людей к размышлению.

• SOLID позволяет легче (т.е. не задумываясь) принимать не идеальные (т.е. сомнительные) решения.

Упомянутые материалы

• Деконструкция SOLID

• Систематизация вариантности типов

• Инверсия контроля на голом Инверсия контроля на голом TypeScript без боли

Копилка благодарностей

⚙️ Настройка разных пользователей Git для разных проектов

В домашней директории есть три папки:

- ~/ProjectHome/
- ~/ProjectWork/
- ~/ProjectOther/

В каждой нужно работать от своего пользователя:

- userHome
- userWork
- userOther

Чтобы работать в каждом проекте без дополнительных переключений, нужно сделать следующее:
1. Добавить настройки в .gitconfig

Откройте файл ~/.gitconfig и добавьте в него:

[includeIf "gitdir:~/ProjectHome/"]
path = ~/.gitconfig-home
[includeIf "gitdir:~/ProjectWork/"]
path = ~/.gitconfig-work
[includeIf "gitdir:~/ProjectOther/"]
path = ~/.gitconfig-other

2. Создать отдельные конфиги для каждого пользователя
Создайте в домашней директории три файла:

- ~/.gitconfig-home
- ~/.gitconfig-work
- ~/.gitconfig-other

3. Прописать пользователя и SSH-ключ в каждом конфиге
Пример содержимого для ~/.gitconfig-home:

[user]
name = userHome
email =userHome@mail.ru
[core]
sshCommand = "ssh -i ~/.ssh/id_userHome_ed25519"

Аналогично создайте .gitconfig-work и .gitconfig-other, указав соответствующего пользователя, почту и путь к ключу.

⚠️ При этом из основного .gitconfig нужно удалить секции [user] и [core.sshCommand], чтобы не было конфликтов.

4. Указать правильный remote для каждого проекта в своей папке

Для проектов в ~/ProjectHome/:
git remote set-url origin git@github.com:userHome/ProjectHome.git

Для проектов в ~/ProjectWork/:
git remote set-url origin git@github.com:userWork/ProjectWork.git

Для проектов в ~/ProjectOther/:
git remote set-url origin git@github.com:userOther/ProjectOther.git


💡 ProjectHome.git, ProjectWork.git, ProjectOther.git - это просто примеры названий репозиториев, они могут быть любыми.

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

5. Разместить SSH-ключи

В директории ~/.ssh/ должны находиться три приватных ключа, которые вы сгенерировали для каждого пользователя.

Например:
- id_userHome_ed25519
- id_userWork_ed25519
- id_userOther_ed25519

Убедитесь, что имя ключа соответствует указанному в параметре sshCommand внутри соответствующего .gitconfig-*

✅ Результат

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

Можно добавить и больше папок с пользователями - принцип остаётся тем же.

Добавлю еще вариант, подходит для Gitlab:
https://qna.habr.com/q/1400592