Маркина. Системно

🪡 Карта канала «Маркина. Системно»
Когда я начинала этот канал, у меня была идея: писать про системный анализ и системное проектирование, разработку, карьеру и преподавание. Делать это сразу стала структурно с тегами.

🗺 Рубрики, по которым живёт канал
🔹 #Термины — разбор понятий. Словари, этимология, практика.
🔹 #Карьера — про рост, собеседования, баланс, навыки, обратную связь. Всё, что касается работы и развития.
🔹 #Инструмент — конкретные технологии, нотации, фреймворки.
🔹 #Байки — живые истории. Честно и с душой.

Если Вы недавно и хотите узнать про меня, то это самый второй пост.

🌂 Что уже есть в канале
Некоторые примеры, чтобы вам было проще листать:
#Термины
— Функционал vs Функциональность
— MVP
— Vertical Slice vs Onion
и другие...
#Карьера
— Харизма vs экспертиза
— Насмотренность
— Травля на работе
— M‑Shape
и другие...
#Инструмент
— TypeSpec
— Профстандарты в ИТ
— Git
и другие...
#Байки
Ищите по тэгу, тут нет структуры, а только как чувствую 😉

💻 День системного администратора — как всё начиналось
Сегодня, в последнюю пятницу июля профессиональный праздник тех, кто держит на своих плечах всю цифровую инфраструктуру. С праздником, сисадмины!

🗓 А знаете, как появился этот день?
В 2000 году системный администратор из Чикаго Тед Кекатос увидел в журнале рекламу HP: счастливый сисадмин сидит в своём закутке, а благодарные пользователи выстроились в очередь к его столу с цветами, фруктами и корзинками с подарками за установленные принтеры. Тед как раз недавно установил несколько таких же принтеров у себя в компании. Он показал коллегам рекламу и спросил: «Где моя благодарность?» Его осмеяли, но Тед решил, раз никто не догадался поблагодарить сисадминов, это сделает он сам. Зарегистрировал домен SysAdminDay.com, разослал друзьям приглашения и устроил пикник на окраине Чикаго в пятницу 28 июля 2000 года.
С тех пор последняя пятница июля — День системного администратора.

🇷🇺 Как отмечают в России
У нас этот день превратился в традицию с размахом: ежегодный Всероссийский слёт сисадминов собирает в Ярославской области тысячи участников из десятков городов.
В Екатеринбурге гуляют у легендарного Памятника клавиатуре — с метанием компьютерных мышей, силовым жимом жёстких дисков и шуточным сожжением чучела ламера.

🎓 Вместо резюме
Системный администратор — это тот, кто:
✅ делает резервные копии, когда вы думаете, что всё и так работает
✅ не спит, когда сервер упал за час до релиза
✅ знает, где лежит тот самый кабель, без которого ничего не работает
✅ слышал «всё сломалось» больше раз, чем мы сказали «спасибо»
Кто для вас системный администратор?👇
Если у вас в чате есть сисадмин — подойдите сегодня, пожмите руку, угостите пиццей или просто скажите «спасибо». Вам несложно, им — приятно .
С праздником! 🎉 Пусть сервера не падают, коллеги не дёргают по пустякам, а сети работают стабильно. Спасибо, что вы есть 👨‍💻👩‍💻

#Байки

Что такое система и её главное свойство
Заметили, что постоянно говорим о системах? Знаете ли вы что же такое система? Легко можете сформулировать определение?

📖 Что такое система
Классическое определение даёт Большая российская энциклопедия:

(греч. σύστημα, позднелат. systema, буквально – состав, от συνίστημι – составлять, ставить вместе; лат. compositio), совокупность элементов, находящихся в отношениях и связях друг с другом, которая образует определённую целостность, единство.

Новая философская энциклопедия приводит схожее определение с небольшим уточнением:

(от греч. σύστεμα - целое, составленное из частей, соединение) - совокупность элементов, находящихся в отношениях и связях друг с другом, которая образует определенную целостность, единство.

Также определяет её как совокупность элементов в отношениях и связях друг с другом.
Философ Андре Конт-Спонвиль в своём «Философском словаре» добавляет важный нюанс:

Упорядоченное соединение элементов, каждый из которых необходим для поддержания целого и в то же время зависит от него. Именно в этом смысле мы говорим о нервной системе, о Солнечной системе, об информационной системе и т. д. В философии системой чаще всего называют совокупность идей, «рассматриваемую больше с точки зрения их взаимосвязи, чем с точки зрения их истинности» (Лаланд).

В системной инженерии (ГОСТ Р 57100-2016) определение звучит как прикладное:

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

Далее стандарт уточняет, что в инженерной практике

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

🖊 Ключевые признаки любой системы
✅ Целостность — свойства системы не сводятся к сумме свойств её элементов.
✅ Иерархичность — каждый элемент системы сам может быть системой, а сама система — частью более крупной.
✅ Взаимосвязь со средой — система формирует свои свойства во взаимодействии с окружающим миром.

⚡️ Эмерджентность
Эмерджентность — «свойство системы, заключающееся в возникновении новых, качественно отличных характеристик, которые не присущи отдельным её компонентам, но проявляются в результате их взаимодействия и объединения в целостную систему».
Эмерджентные свойства (по определениям из системного анализа):
➖ не могут быть выведены из свойств элементов;
➖ присущи только системе как целому;
➖ исчезают при разрушении системы как целого.
Примеры из разных областей:
🔹 Физика: два булыжника (хоп и система) могут высекать искры, этого не делает ни один из них по отдельности.
🔹 Химия: соединение водорода и кислорода в пропорции 2:1 даёт воду (хм, а вода вроде как тоже система...) — у неё есть свойства (например, быть жидкостью при комнатной температуре), которых нет у газов по отдельности.
🔹 Биология: стая птиц (и это вы спросите тоже система?) может синхронно менять направление — ни одна птица по отдельности не обладает этим свойством, оно возникает только в группе.
🔹 Машиностроение: автомобиль — это не просто кузов, колёса и двигатель. Способность «ехать» не присуща ни одному из элементов по отдельности. Она возникает только когда элементы соединены правильно и взаимодействуют.
В системной инженерии эмерджентность описывают ещё через «сверхаддитивный эффект» — свойства целого возникают как нечто большее, чем сумма свойств частей, при их объединении и появлении новых связей.

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

Сталкивались в работе с эмерджентными свойствами, которые появились «сами собой»? 👇

#Термины

😇 А вы сегодня заботились о себе?
Знаете, какой сегодня день?
Можете не искать, я подскажу. 24 июля Международный день заботы о себе.
Дата выбрана не случайно, если написать 24/07, то появляется ассоциация 24 часа в сутки и 7 дней в неделю и это не работать, это напоминание, что заботиться о себе нужно 24 часа в сутки 7 дней в неделю.
Звучит красиво, но в реальности, особенно в ИТ-среде, где дедлайны, бесконечные созвоны и «давай ещё одну фичу», кажется не реализуемым.

Нашла статистику, что каждый четвёртый айтишник (23%) признаётся в усталости и выгорании, а 28% считают, что их профессиональное развитие остановилось.

Мы привыкли думать, что забота о себе — это про спа-салоны, йогу и правильное питание.
На самом деле это ещё и про:
✅ Выключать уведомления после 20:00
✅ Соглашаться на «нет» без чувства вины
✅ Не входить в рабочие чаты, когда в отпуске
✅ Помнить, что вы — не машина для генерации задач

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

А вы на сегодня запланировали сделать что-то для себя? А на выходные?👇

#Карьера

Возможно вы заметили, что я люблю выступать и ходить на конференции и митапы. Несколько ИТ-компаний (ИнфоТеКС, Nexign, Okko, Garage Eight, Сбер) устраивают в Петербурге Летний ТехФест 2026. Меня пригласили помочь и я рекомендую зарегистрироваться на все даты сразу, участие в мероприятии бесплатно, а полученные знания, умения и контакты - бесценны!

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

📅 4, 11, 18, 25 и 30 августа
Подробности о мероприятии можно прочитать в канале

Регистрируйтесь по ссылке🖱

До встречи на Летнем ТехФесте💛

🤓 Про ИИ, Линуса и страх, который мы все чувствуем
Когда я читаю про ИИ в разработке, я задумываюсь о роли человека в разработке и сам собой всплывает вопрос: «А не заменит ли ИИ все роли в разработке через пару лет?»
И тут появляется Линус Торвальдс, как будто отвечая на мои вопросы. Тот самый, который создал ядро Linux, на котором работает почти весь мир. Он, тот кто в 2024 говорил, что это всё хайп, теперь уже признаёт эту реальность, под которую надо адаптироваться.

🧑‍💻 Что произошло
Недавно разработчики Linux начали использовать ИИ-инструмент для ревью кода Sashiko. Конечно было много споров. И тогда Торвальдс сказал то, что обычно говорит — жёстко и прямо: «Если вам не нравится, что мы используем ИИ, сделайте форк и катитесь. Linux — не анти-ИИ-проект. Год назад это ещё было не очевидно, а сегодня — очевидно».

📈 Про цифры, которые меня поразили
Линус привёл статистику: за последние полгода количество изменений в ядре выросло на 20%. Сначала он думал, что это из-за нового релиза. А потом понял: причина в ИИ.
Люди входят в проект быстрее, пишут код быстрее, находят ошибки быстрее.
При этом Sashiko нашёл 53,6% ошибок, которые разработчики потом исправили.

📩 Что я об этом думаю
Мы же используем компьютеры, а не печатную машинку, а кто-то уже даже только голосовой набор без клавиатуры. Студенты приходят с ChatGPT. Коллеги из PT пробуют LLM. Я сама также использую "умные" чатики.
Как я вижу ситуацию — это не заменяет мышление, только ускоряет процессы, повышает количество задач, которые можно успеть.
Компилятор в своё время не заменил программиста. И ИИ не заменит. Тот, кто умеет пользоваться компилятором — пишет быстрее, а кто умеет пользоваться ИИ — ещё быстрее.
Как обычно есть нюансы. Вайб-кодинг, по словам того же Линуса, может быть опасен для серьёзных проектов. Если ты пишешь приложение на коленке — ок. Если ты строишь систему, которая будет жить 10 лет — ИИ не заменит понимания архитектуры.
Но для новичков это отличный способ войти. Для рутины — спасение. Для сложных размышлений — всё равно нужна голова.

🎓 Моё резюме
Согласна с человеком, который строил ядро Linux 35 лет, надо адаптироваться.
Страх устареть — нормален, но я считаю, что ИИ не заменит нас. Он точно заменит тех, кто отказывается его использовать.
А вы уже используешь ИИ в работе? Или он тебя пока пугает? Признавайся 👇

🔞 Когда анализ встречается с безопасностью: мой день на ProIT Fest VIII

На Летнем ProIT Fest VIII, который прошёл 11 июля, я побывала в секциях, где мои два любимых предмета в ИТМО сошлись в одном. Организаторы подготовили целый поток Hard Tech, который раскрывает доменные области IT: FinTech, Ecom, TravelTech и другие. Необычный был не только формат с маленькими залами в пространстве СЕНО, но и мерч: презерватив и смазка...

🎤 Что я послушала
Егор Марюшка @egormaryushko, создатель платформы знаний умений и навыков СА, рассказал о том как начать вайбкодить и какие ошибки можно избежать. Уже не раз начинала это и всё бросала, но после рассказа — приступила повторно уже без ошибок.
Наталья Козлова, начальник отдела системного анализа в Код безопасности и спикер множества конференций, презентовала моделирование угроз в формате игры Elevation of Privileges, где на примере S.T.R.I.D.E. (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) мы искали уязвимости в реальной системdoctorponos
Александр Князев, руководитель развития ИИ агентов "AMA" провёл мастер-класс по взлому ИИ агентов, было увлекательно на практике поломать сайт через чат-бот.

📝 Что можно было найти ещё
Интерактив и живые дискуссии. Организаторы сделали ставку на диалог, а не на обычный доклад-монолог. Секция Fight Club — место споров и оппозиционных мнений. Конечно же спорили "до хрипоты", перебивали спикеров, задавали неудобные вопросы.
Честные истории о фейлах. Особенно зашёл формат Oops, секция, посвящённая эпическим фейлам различных масштабов. Специалисты из sec, devops, ops, sre, mlops рассказывали о том, как всё у них ломалось. Я считаю, что учиться на ошибках ценнее любых учебников.
Нетворкинг. Поговорила с коллегами из других компаний. Оказалось, у всех одни и те же боли: как объяснить заказчику, что безопасность — это не "лишняя работа", а часть продукта.

🎓 Моё резюме
Быть слушателем без дополнительных обязанностей — отличный отдых. Ходить на спикеров, а не на конференции.

А вы были на ProIT Fest? Какая секция зашла больше всего? 👇

Два аналитика выходят на сцену: один — прагматик, открыто признающий, что использует триггеры, полуправду и «иллюзию выбора», чтобы протащить архитектуру через сопротивление; второй — оппонент, который каждый день противостоит таким приёмам и знает их механику изнутри. На Analyst Days 22 Татьяна Маркина и Тарас Шевченко разобрали те травмы, о которых в профессии принято молчать.

В докладе:
✅ Техника влияния, которую вы уже используете (и почему не стоит делать вид, что это не так).
✅ Тело и голос как API влияния: почему одинаковая фраза в другом исполнении читается как «статус» или как «попытка имитировать статус».
✅ Коммуникационный патч vs выживание: когда «маленькая манипуляция» превращается в условие работы команды.

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

Смотреть видео: https://vkvideo.ru/video-137540756_456240178

📉 M‑Shape: ваш страховой полис против AI или просто модный термин?
Все слышали про T‑shape — глубокую вертикаль в одной области и широкий кругозор по смежным. Этот формат долго был идеалом.
Но сегодня ИТ-рынок говорит: одного «Т» больше недостаточно. Почему? AI всё лучше справляется с узкими типовыми задачами. Он не заменит архитектора, но легко заменит «исполнителя», который умеет только крутить гайки в своей вертикали.
На сцену выходит M‑Shape (или Comb‑shape) — профиль с несколькими глубинами в разных карьерных треках, соединённых широкой базой. Звучит красиво. Давайте разберём, что это на самом деле.

🧠 Чем M отличается от жирного Т?
Важное уточнение: если бэкенд-разработчик знает ещё и DevOps — это не M, это просто очень прокачанный сеньор с широкой экосистемной экспертизой.
M‑Shape — это когда ваши вершины лежат в разных дисциплинах, которые редко пересекаются:
➖ Инженерия + Продажи (Pre-sale)
➖ Аналитика + Управление продуктом
➖ Разработка + Бизнес-стратегия
➖ Инфраструктура + Клиентский опыт
Вы не просто «добавили скилл». Вы научились думать на двух разных языках и переводить между ними.

🔍 Примеры M‑профилей из ИТ (и почему это работает)
🟡 Системный аналитик, который глубоко знает архитектуру, управление требованиями и продуктовую стратегию с метриками.
Он не ждёт, пока продакт напишет ТЗ. Он сам переводит бизнес-запрос в архитектурные ограничения и видит, что из этого выйдет по срокам.
🔴 Инженер данных, который разбирается в ETL-процессах, бизнес-аналитике и безопасности данных.
Он проектирует хранилище так, чтобы не закладывать костыли под будущие отчёты, и знает, какие данные нельзя светить в дашбордах.
🟢 Разработчик, который сочетает бэкенд и продуктовый дизайн (UX).
Он не пишет «технически правильный» код, он пишет код, который не бесит пользователя.
В чём здесь ценность? Такой человек не закрывает всё сам (это было бы безумием). Он ставит корректные задачи профильным спецам, спорит с ними на их языке и не даёт команде свернуть не туда.

📊  Кому это выгодно и как качать
По данным исследований, сотрудники с несколькими экспертизами быстрее растут и получают выше рынка. Но дело не только в деньгах.
Главная выгода для компании: на старте проекта или при кризисе M‑специалист заменяет двух-трёх узких игроков и видит риски на стыках, которые другие не замечают.
Главная выгода для вас: если одна экспертиза просядет (а такое бывает), вторая страхует вашу карьеру. Это ваш профессиональный страховой полис.
Как качать M‑профиль без выгорания:
1️⃣ Прокачайте первую глубину до уровня «кормит». Нельзя строить вторую вершину на слабом фундаменте.
2️⃣ Выберите вторую дисциплину из другой вселенной. Аналитик → в продуктовый менеджмент. Разработчик → в продажи или архитектуру. Маркетолог → в аналитику данных.
3️⃣ Находите пересечения в ежедневной работе. Не просто «изучайте теорию», а берите задачи, где эти две области сталкиваются. Только там рождается реальная глубина.

⚠️ Честный минус M‑Shape
Вы всегда будете чувствовать себя немного самозванцем. В каждой из вершин вы уступаете «чистому» профильному специалисту. И вам придётся это принять. M‑Shape — это не про «быть лучшим во всём». Это про быть самым полезным в нестандартной ситуации.

🎓 Моё резюме
M‑Shape — это не модный ярлык для сеньоров. Это новый способ думать о своей карьере. Мир становится сложнее, AI берёт рутину, и выигрывают те, кто умеет соединять несоединимое и говорить на нескольких профессиональных языках.
А вы уже чувствуете, что одной глубокой экспертизы становится мало? Какие вторые «вершины» видите для себя? Или считаете, что M‑Shape — это перебор и глубокий Т всё ещё рулит?
👇 Давайте поспорим в комментариях.

#Карьера

🔲 Законы Мерфи в ИТ: когда всё идёт не так (и это нормально)
«Если что-то может пойти не так, оно обязательно пойдёт не так» (Точный перевод: «Если есть какой-либо способ сделать это неправильно, он найдёт его»). Эту фразу знают все. Она стала символом человеческой ошибки, случайности и неидеальности любых систем.
В ИТ она работает особенно ярко, потому что здесь ошибка — не просто досадная мелочь, а потеря денег, времени, репутации.

🧐 Откуда взялся закон Мерфи
В 1949 году инженер Эдвард Мерфи участвовал в эксперименте по определению перегрузок. Датчики показали нулевые значения — техник установил все 16 датчиков неправильно, хотя, казалось бы, ошибиться можно было лишь в одном из двух вариантов крепления. Раздосадованный Мерфи произнес фразу, которую его коллеги сократили до «Если есть какой-либо способ сделать это неправильно, он найдёт его». Позже коллеги сократили её до известного нам «Если неприятность может произойти, она произойдёт».
В 1977 году писатель Артур Блох собрал и систематизировал эти законы в книгу, добавив множество следствий из жизни инженеров и программистов. С тех пор «законы Мерфи» стали культурным феноменом.

💻 Законы Мерфи для программистов и аналитиков
У программистов есть свой «свод правил». Вот самые узнаваемые:
✅ Любая работающая программа уже устарела.
✅ Любая программа обходится дороже и требует больше времени, чем казалось в начале.
✅ Если программа полезна, её обязательно переделают. Если бесполезна — тщательно документируют.
✅ В программе всегда есть ещё одна ошибка.
✅ Сложность программы растёт до тех пор, пока не превысит способности программиста, призванного её поддерживать.
Закон Брука (Фредерик Брукс, «Мифический человеко-месяц»): добавление людей в опаздывающий проект только сильнее его задерживает.
Правило 90–90 (Том Каргилл, Bell Labs, 1985): первые 90% кода отнимают 90% времени, оставшиеся 10% кода — ещё 90% времени.
Закон Хофштадтера (Дуглас Хофштадтер, книга «Гёдель, Эшер, Бах», 1979): любое дело всегда длится дольше, чем ожидается, даже если учесть сам этот закон.

🧩 Законы для системных аналитиков и архитекторов
У систем есть свои закономерности. В «Полном собрании законов Мерфи» есть несколько:
🔹 Любая рабочая сложная система когда-то была рабочей простой системой.
🔹 Система, созданная с нуля, скорее всего, не заработает. Начинать нужно с простой версии и наращивать сложность.
🔹 Все системы бесконечно сложны. Иллюзия простоты возникает, когда мы сосредотачиваемся на одном аспекте .
И фундаментальные постулаты:
✅ Все, что угодно, — система.
✅ Все, что угодно, — часть более крупной системы.
✅ Все системы бесконечно сложны. Иллюзия простоты возникает от того, что внимание сосредотачивается на одном или нескольких вариантах.

🎓 Моё резюме
Законы Мерфи — это не оправдание для фатализма. Это инструмент планирования.
Когда вы знаете, что программа устареет, а задача займёт больше времени — вы закладываете буфер. Когда вы знаете, что сложная система, созданная с нуля, не заработает — вы начинаете с простой версии и наращиваете сложность.
Как пишут эксперты по управлению проектами, закон Мерфи не настраивает на пессимистический лад, а напоминает о неизбежности сбоев и необходимости быть к ним готовым .
И если что-то пошло не так — вы хотя бы не удивляетесь.
А какие «законы подлости» чаще всего сбываются в вашей работе? 👇

#Байки #Термины

Ⓜ️ Мандраж: слово, которое живёт в речи, но прячется от словарей
Есть слова, которые звучат так, будто их придумали вчера. А есть те, что живут десятилетиями, переходят из уст в уста и остаются с нами. Мандраж — как раз из таких.
Я люблю это слово. Оно точное, хлёсткое и сразу передаёт состояние: когда коленки трясутся, в груди холодок, а в голове одна мысль: «А вдруг?». Но откуда оно взялось?
Честно говоря, я не знала. И решила разобраться.

🕵️‍♂️ Что говорят источники
Точного ответа нет. Языковеды признают: происхождение многих жаргонных слов остаётся туманным. И «мандраж» — один из таких случаев .
1️⃣ Из бильярда и цирка
В романе Льва Славина «Наследник» (1930 год) слово уже используют бильярдисты. Там описывается «та крайняя растерянность сил, которая называется у бильярдистов мандражем».
Актёр Юрий Никулин вспоминал, что слово жило и в цирковой среде: «Как говорят в цирке, нас бил мандраж. Откуда пошло это слово — мандраж, не знаю. Означает оно страх, волнение».
2️⃣ Из воровского жаргона
В словарях арго слово фиксируется в двух значениях: «испуг» и «страх разоблачения, задержания» . То есть это был сленг людей, которые постоянно жили в опасности. Оттуда слово могло уйти в широкую речь.
3️⃣ Связь с диалектами
Автор «Словаря московского арго» В. С. Елистратов приводит несколько диалектных слов, предположительно связанных с «мандражем»: «мандара» — «земля, берег», «мандровать» — «странствовать», «мандрыка» — «лепёшка» . Но прямое родство не доказано.
4️⃣ Пикантная и сомнительная
Некоторые источники допускают, что «мандраж» — это замаскированное нецензурное слово, которое потеряло грубость . Авторы указывают, что «внешний псевдофранцузский вид слова „мандраж“ — дань стремлению к эвфемизации неприличного слова» . Но эта гипотеза не подтверждена.

🎭 Моя любимая догадка (до того, как я залезла в словари)
Честно говоря, я всегда была уверена, что «мандраж» — заимствование из французского.
Ну правда, звучит же: «мандраж» — как будто от французского mandrage или mandragore. Тем более во французском есть слово mandragore — так называется растение мандрагора . А в средневековой английской лексике встречается слово mandrage — как раз в значении «мандрагора» .
И я думала: ну вот, скорее всего, пришло из французского через какую-то диалектную цепочку.
Но нет. Как пишут лингвисты, «происхождение многих жаргонных слов является затемнённым» . Никаких следов французского заимствования в этимологических словарях нет. «Псевдофранцузский вид» — это лишь внешняя оболочка, а не реальное происхождение.
Так что моя догадка не подтвердилась. Но она была красивой.

📖 Есть ли оно в словарях?
Да, но с оговоркой.
Ефремова включает «мандраж» с пометкой «разговорное»: «состояние страха, неуверенности в себе, нервозности».
Викисловарь даёт ту же трактовку и приводит пример из литературы.
Словарь арго фиксирует слово с вариантами: «испуг, ужас; волнение, озабоченность» .
Но вот что важно: «мандраж» отсутствует в академических словарях русского языка. Его нет в словаре Ушакова. Его нет в Большом академическом словаре. Это слово живёт в разговорной речи, жаргонах и спортивной среде, но не получило статуса «литературного».

🎭 Пример классического жаргонизма
«Мандраж» — идеальный пример того, как жаргонное слово приживается, но остаётся на периферии.
Оно есть в разговорной речи. Его используют в спорте, в цирке, в бильярдных, в ИТ-командах перед релизом. Оно точное и понятное. Но в официальную литературную норму не входит.
И это нормально. Жаргонизмы — не «плохие» слова. Они обогащают язык, делают его живым.

🎓 Моё резюме
История «мандража» — как любой уважающий себя жаргонизм: недоказуемая, запутанная и полная догадок. Моя гипотеза о французском происхождении не подтвердилась, но я даже рада — так история интереснее.
Слово живёт, потому что оно точное и человечное. Оно называет то, что мы все чувствовали перед важным событием.
Вы используете слово «мандраж»? Или у вас есть свой любимый синоним для предрелизного состояния? 👇

#Термины

🇷🇺 Вход на сайты — только по-российски. Штрафы ввели, а закон действовал уже два года
Важное уточнение: Сам закон, обязывающий владельцев российских сайтов использовать для авторизации только отечественные системы, был подписан президентом ещё 31 июля 2023 года и вступил в силу в декабре того же года .
Однако до сих пор за его нарушение не было административной ответственности. Теперь — есть. 26 июня 2026 года президент подписал поправки в КоАП, которые вводят конкретные штрафы .

📜 Что изменилось и для кого
Закон 2023 года обязал владельцев российских интернет-ресурсов предоставлять пользователям вход только через:
➖ российский номер телефона
➖ портал «Госуслуг» (ЕСИА)
➖ единую биометрическую систему
➖ иную систему, владельцем которой является гражданин РФ или российское юрлицо 
Теперь за использование только зарубежных сервисов для входа (например, Google или Apple ID) владельцам ресурсов грозят штрафы :
➖ для граждан (например, владельцев блогов): от 10 000 до 20 000 ₽
➖ для должностных лиц: от 30 000 до 50 000 ₽
➖ для юридических лиц: от 500 000 до 700 000 ₽
При повторном нарушении суммы увеличиваются в два раза.

🧠 Важные нюансы
Закон не имеет обратной силы. Уже зарегистрированных пользователей не обязывают менять иностранную почту на российскую .
Штрафы накладываются на владельца ресурса, а НЕ на рядового пользователя.
Сама по себе возможность входа по логину и паролю с адресом зарубежной почты не является нарушением, если ресурс проводит авторизацию самостоятельно, а не через иностранный сервис .

🎓 Моё резюме для ИТ-команд
Если ваш продукт работает с российскими пользователями, самое время проверить:
✅ Какие системы авторизации вы используете для новых пользователей.
✅ Если у вас есть единственный способ входа через Google, Apple ID или другой зарубежный SSO — это прямой путь к штрафу.
Технически задача решаема: подключите вход через «Госуслуги», СМС-код или российский OAuth. Но на это нужно время.
Уже перешли на российские системы авторизации или пока на паузе? 👇

#Карьера

🔞 PROVOKE: история, которая началась на улице
Сегодня на Хабре вышла моя статья — первая из серии про наш с Тарасом доклад «PROVOKE: системный анализ между соблазнением, манипуляцией и властью», который занял 3 место на Analyst Days 22.
Она не про слайды, не про структуру и не про то, как мы репетировали. Она про то, как мы придумали тему. Про прогулку по Москве после первой конференции, про разговор на улице, про ужин, про кафе на следующий день. Про то, как идея родилась не тогда, когда мы её искали, а когда просто шли и говорили.
Это история о том, как решение делать доклад вдвоём принимается за один вечер. И о том, почему лучшие решения приходят быстро — без долгих обсуждений, без взвешивания «за» и «против». Просто смотришь на человека и знаешь: да, это он. Это мы.

❓ Зачем пишу этот пост
Во‑первых, чтобы вы знали: Хабр читают. И на нём стоит публиковаться. Если у вас есть что сказать — говорите. Если у вас есть идея — записывайте. Если вы сомневаетесь — попробуйте. Это не первая моя статья на Хабре, но после долгой паузы и я планирую продолжать.
Во‑вторых, анонсирую продолжение. В следующих частях я напишу:
— как мы готовили доклад за 1500 км друг от друга
— с какими сложностями столкнулись, выступая вдвоём
— как мы спорили о каждом слайде и что из этого вышло
Подписывайтесь на мой блог на Хабре, чтобы не пропустить.
В‑третьих, вопрос к вам: читаете ли вы Хабр? Пишете ли сами? Или считаете, что эта площадка уже не та, что была раньше? 👇 Мне правда интересно.
Ссылка на статью
Ссылка на доклад
Ссылка на первую статью на Хабре

#Байки

🤓 Что такое RFC и почему их должен знать каждый ИТ-специалист
Вы когда-нибудь задумывались, почему интернет работает так, как работает? Почему ваш браузер понимает сервер, а сервер — ваш запрос?
За этим стоят RFC — Request for Comments («Запрос комментариев»). За этим скромным названием скрывается основа основ: от того, как устроен TCP/IP, до того, как работают email и веб-протоколы.

📜 Что такое RFC простыми словами
RFC — это документы, в которых описаны технические спецификации интернета. Они публикуются IETF (Internet Engineering Task Force) — открытым международным сообществом разработчиков и исследователей, которые и создают интернет-стандарты.
Первый RFC появился в 1969 году. С тех пор их выпущено уже больше 9000. И да, среди них есть даже первоапрельские шутки — например, RFC 1149 про передачу IP-пакетов по голубиной почте. Кстати, формально этот документ имеет статус «Experimental», но это не мешает ему быть классикой юмористических RFC.

🧠 Главное, что надо знать об RFC
1️⃣ Не все RFC — это стандарты
Это распространённое заблуждение. Некоторые RFC носят информационный характер. Другие — экспериментальные. Только часть из них попадает на «стандартный трек».
Современный путь к статусу «Интернет-стандарт» выглядит так (с 2011 года):
Internet‑Draft (черновик, живёт 6 месяцев) → Proposed Standard (предлагаемый стандарт) → Internet Standard (получает номер STD).
Промежуточного статуса «Draft Standard» больше не существует — его упразднили, чтобы ускорить процесс стандартизации.
И даже статус стандарта не вечен — он может устареть и быть помечен как «Historic».
2️⃣ Философия RFC: «Грубый консенсус и работающий код»
Главный принцип IETF, который в 1992 году сформулировал Дэвид Кларк: «We reject kings, presidents, and voting. We believe in rough consensus and running code» («Мы отвергаем королей, президентов и голосования. Мы верим в грубый консенсус и работающий код»).
Стандарт должен быть не просто красиво написан. Он должен быть реализован и протестирован на практике. Поэтому для перехода на уровень «Internet Standard» требуется как минимум две успешные, независимые реализации.

🎓 Моё резюме
RFC — это язык, на котором говорит интернет. Понимать их — значит понимать, как устроена основа вашей профессии.
Вы знали об их существовании? Какой последний прочли? 👇

#Термины

🫁 Микрофронтенды vs SPA: когда монолит перестаёт дышать
SPA (Single Page Application) — это классика. Один фронтенд-репозиторий, одна сборка, одна точка входа. Загрузился раз — и дальше роутинг живёт внутри браузера без перезагрузок. Всё просто и предсказуемо.
Microfrontends (Микрофронтенды) — это «микросервисы на клиенте». Большое приложение собирается из независимых модулей (виджетов/микро-приложений), каждый из которых может разрабатываться отдельной командой, на своей технологии и выкатываться по своему графику.

⚔️ SPA: плюсы и минусы
✅ Плюсы:
После загрузки — молниеносный роутинг
Один стек на всю команду — проще онбординг
Легко шарить утилиты, UI-кит, логику через общий код
Сборка и деплой — тривиальные (одна команда build)
❌ Минусы:
Первая загрузка может раздуваться до огромных размеров (бандл толстеет со временем)
Код превращается в монолит: страшно менять что-то в «старой» зоне, потому что непонятно, кто ещё это использует
Любое изменение — пересборка и перекат всего приложения целиком
Разные команды в одном репозитории начинают мешать друг другу (конфликты в package.json, разный стиль кода, очереди на деплой)

🧩 Микрофронтенды: плюсы и минусы
✅ Плюсы:
Команды полностью независимы: каждый сам решает, когда выкатывать фичу
Можно обновить один модуль без пересборки всего остального — деплой точечный
Технологическая свобода: команда А пишет на React, команда Б — на Vue, команда В — на Angular (и это реально работает через Module Federation или Single-SPA)
Масштабирование разработки: 10+ команд работают параллельно, не наступая друг другу на пятки
❌ Минусы:
Инфраструктура резко усложняется: нужна сборщица (оркестратор), которая склеивает части в рантайме
Дублирование кода — общая боль. Каждый модуль тащит свою копию React, свои стили, свои утилиты, если не настроить разделение зависимостей
Роутинг и общее состояние (например, корзина в маркетплейсе) требуют отдельной архитектуры, которую надо продумывать с нуля
Высокий порог входа: новому разработчику надо понять, как работают 5 модулей, а не один монолит

🎯 Когда что выбирать
SPA подходит, если:
➖ Команда до 10–15 человек
➖ Приложение не разбито на жёсткие доменные зоны
➖ Вы не переживаете, что не сможете обновить часть без переката всего
➖ Хотите быстро стартовать и минимизировать инфраструктурные затраты
Микрофронтенды оправданы, если:
➖ Команда более 20 разработчиков (или активно растёт)
➖ У приложения есть чёткие домены: каталог, корзина, личный кабинет, админка
➖ Разные команды хотят быть независимыми в выборе технологий и графиков релизов
➖ Это Enterprise, где части продукта могут развиваться разными темпами
Классический пример:
Веб-версия маркетплейса. Команда «Каталог» пишет на React, команда «Корзина» — на Vue, команда «Личный кабинет» — на Angular. Все три собираются в одну страницу через Webpack Module Federation или Single-SPA. Пользователь видит единый сайт, а внутри — модули от разных команд.

🎓 Моё резюме
Микрофронтенды — это не про «круто», а про «больно, но надо, когда выросли». Это те же микросервисы, только на фронте: та же независимость и та же головная боль с инфраструктурой.
Мой совет: не начинайте с микрофронтов. Начните с хорошего SPA-монолита. Используйте правильную архитектуру внутри (FSD, модули, чёткие слои). Когда монолит начнёт душить вас организационно — тогда и задумайтесь о разделении.
А у вас что за проект? SPA или уже микрофронтенды? Если делите — как именно? В рантайме или на сборке? 👇

#Термины #Архитектура