S0ER

Хочу поделиться с вами публичным гайдом Как правильно использовать и обрабатывать исключения в программе, который поможет улучшить обработку ошибок и исключений на бэкенде. Если хотите такой же гайд для обработки ошибок на фронтенде, то давайте соберем 100 отметок 💡 и я подготовлю материал для вас.

Первый шаг к понимаю архитектуры ПО - понимание контекста решаемого вопроса. Я много консультирую, провожу воркшопы, делаю курсы по архитектуре и заметил одну важную деталь - часто люди упускают момент, который является основным ключом к пониманию архитектуры - контекст. Сложность в том, что по архитектуре ПО нет общего стандарта, который можно было бы брать за основу и говорить всем "так и только так правильно", одни и те же термины используются разными авторами в разных контекстам по-разному (например, "зависимость" в UML и зависимость в DIP - имеют разные смыслы, или "пасивность view" в MVC и MVP тоже разные, более того есть свой вариант MVC для десктопов и веб). Поэтому при проектировании я придерживаюсь следующего порядка: 1. Определить контекст 2. Определит архитектурную идею (об этом как-нибудь тоже расскажу) 3. Отразить схему или диаграмму для иллюстрации идеи. Графическое представление идеи - очень важно, но без контекста может сильно запутать. Пока не появится привычки отделять "мух от котлет" ни о каком понимании речи идти не может.

Недавно на созвоне в Соер.Клубе обсуждали вопросы создания Architecture Decision Record (ADR), у нас была задача описать условия при которых целесообразно создавать и вести ADR. Обсудили огромное количество деталей, которые хочется обобщить и зафиксировать в виде коротких подсказок. Возможно вам тоже будет полезно.

Ветвление в git - это с одной стороны очень простая штука, а с другой мало кто пользуется ей на максималках. В общем, хочу поделиться классным тренажером, который поможет научиться делать и использовать ветки в git-е, если вы реальный соер - https://learngitbranching.js.org

Что нужно знать про контейнеризацию Через пару недель на курсе по монолитным архитектурам будем разбирать, зачем нужна и как устроена контейнеризация. Ради интереса посмотрел ролики на YouTube по этой теме и хочу указать на очевидные пробелы, которые заметил. Итак, нам часто говорят: «Сегодня знания не нужны, всё есть в бесплатном доступе». К сожалению, это не так. В открытом доступе — в основном видео, где пересказывают документацию Docker. А когда речь заходит про контейнеры, звучит что-то вроде:

«Это такая магия, которая как-то работает и делает легковесные виртуалки».

А потом мы удивляемся, когда разработчики говорят:

«Не знаю, почему не работает, у меня локально всё ок».

Между тем, отладка и поиск корневых причин сбоев — важнейшая часть работы инженера (соера). Без глубокого понимания сути процесса это просто невозможно. Чтобы разобраться, как Docker работает под капотом, обязательно нужно рассматривать: ✅ механизмы изоляции в ядре: namespace и cgroups, ✅ как именно устроена изоляция, ✅ как получать доступ к ключевым метрикам работы контейнеров (например, через Berkeley Packet Filter), ✅ виртуальные сети, которые требуют понимания iptables (Docker активно их использует). Постоянно возвращаюсь к вопросу: могут ли люди, которые сами учились по бесплатным мануалам и никогда не применяли инструмент на практике, помочь в его изучении? Глядя на ролики в YouTube, создаётся ощущение, что это больше про пиар, чем про знания. Конечно, не все видео — просто пересказ документации, но в массе своей ситуация печальная.

В рекомендации выдалось хорошее видео по ACID, понравилось простое и понятное объяснение, без лишней воды. Просили делиться подобными видео, вот ловите - https://youtu.be/s4_bROEL4vQ?si=aGzAf3JFxPJGZzXd

👑 Почему в современном мире нужно постоянно учиться Перенасыщенный информационный поток — это верный способ посадить нервную систему. Современные люди потребляют конские дозы информации, которые не несут никакой полезной нагрузки, но требуют постоянных умственных затрат. Причём часто мы изнашиваем нервную систему дополнительным стрессом от прочтения всякой ерунды. Избежать новой информации невозможно, поэтому для себя стараюсь максимально ограничивать потребление ненужной информации, а в остальном сосредоточиться только на чём-то полезном. Поэтому задаю два важных вопроса: 1. «Что я узнал нового?» 2. «Что из нового оказалось полезным?» Во втором вопросе есть подвох: не всегда понятно, что считать пользой. Полезной я считаю информацию, которая либо напрямую делает мою жизнь лучше, либо расширяет профессиональную эрудицию. Мне кажется, что между потреблением полезной и бесполезной информации выбор очевиден. Теперь почему не получится «не потреблять информацию». Тут всё просто: технологии массмедиа сильно продвинулись вперёд и легко обходят наши защитные механизмы. Тут меч сильно опережает щит. Кроме этого, в современном обществе есть явный культ знаний, и люди его периодически пытаются игнорировать. Но, как правило, это приводит к тому, что вместо спокойного ритмичного развития они развиваются рывками, в моменте нагружая свой организм огромными порциями информации. Это приводит к банальному выгоранию и потере здоровья. В целом моя идея в том, что если информационного потока нельзя избежать, то нужно его контролировать и делать максимально спокойным и полезным.

Вопросы с подвохом, которые могут задать на систем-дизайн интервью. На интервью по системному дизайну есть пара вопросов с подвохом, которые неплохо знать. Первый — это знать, в чем разница между "связностью" и "связанностью". Тут легко решить проблему, используя слова "когезия" и "зацепление". Другой вопрос — разница между модулем и компонентом. Есть общее представление, что компонент отражает функциональную суть задачи, а модуль — структурную. То есть компонент показывает "что будет делать система?", а модуль — "как она это будет делать?". Проблемы начинаются, когда задается вопрос о подчинении этих двух понятий по отношению друг к другу. Кажется, что раз компонент отвечает за функцию, а модуль за структуру, то компонент должен декомпозироваться через модули (грубо говоря, "компонент включает модули"). Логично, но ломается на примере UI-компонентов: ведь условная функциональная единица интерфейса "кнопка" — очевидно, является компонентом, но мы знаем кучу примеров, когда подобные компоненты включаются в один модуль. Получается, что нарушается принцип подчинения "от общего к частному". На самом деле эта неточность легко разрешается, если мы введем два уровня архитектуры: 1. "Уровень приложения", где компонент ведет себя согласно закону "от общего к частному". 2. "Уровень кода", где компонент, наоборот, ведет себя "от частного к общему". Зачем это надо на практике? Это помогает уменьшить количество противоречий и "сюрпризов" на этапе документирования (а потом и реализации) системы и, соответственно, правильно определить границы модулей и компонентов для более точного разделения обязанностей.

В Соер.Клубе задали вопрос о карьерном пути. Хочу продублировать сюда мой совет, чтобы ты тоже мог им воспользоваться. 1. Я бы начал с простой классификации — «Матрица самооценки умений и предпочтений».

|                     | Нравится    | Не нравится |
|-----------|-------------|---------------|
| Я умею      | Тут список  | Тут список  |
| Я не умею | Тут список  | Тут список  |

Верхний левый квадрат — «Я умею и мне нравится» — это твоё стратегическое преимущество. Если этот список пустой, то я бы начал решать проблему именно отсюда. 2. Дальше нужно понять, насколько другим людям нужно то, что тебе нравится и что ты умеешь. Если ничего востребованного нет, можно переходить к «Я умею, но мне не нравится» — и туда уже набирать навыки, которые реально пользуются спросом. 3. Последний шаг — разобраться с самопрезентацией. Если у тебя крутые скилы, но сложно говорить с людьми и ещё сложнее подать себя как классный продукт, это тоже нужно исправить. А дальше - продавать то, что ты отлично умеешь, желательно, чтобы это ещё и нравилось, тогда сможешь гораздо эффективнее двигаться в выбранном стеке.

⬛️⬜️⚫️⚪️ Брифинг SOER.PRO #бриф За последний месяц опубликовано много разных материалов, которые помогают развиваться и строить карьеру в АйТи, чтобы ты мог найти все полезное в одном месте ознакомься с брифом ниже. 🎤Сейчас идет курс по монолитной архитектуре, который поможет разобраться с тем как проектировать модульные монолиты, кто не хочет проходить уроки и делать домашку, может ограничиться просмотром материалов. Лекции по архитектуре - Лекция. Введение в монолитную архитектуру - Лекция. Процесс разработки ПО - Лекция. Документирование при проектировании архитектуры Воркшопы - Воркшоп. Признаки монолитной архитектуры в реальных проектах - Воркшоп. Создание монорепозитория - Воркшоп. Разбираем пример документирования Созвоны - Созвон. Анализ опенсорс приложения и построение его архитектуры - Созвон. Создание собственного проекта в репозитории - Созвон. Проектирование и создание собственных решений с помощью ADR Соер.Клуб - Обсудили подход "Parse don't validate' - Обсудили архитектуру мультиагентов ИИ Гайды - Как конкурировать с ИИ в ближайшие пять лет, если ты разработчик - Полный гайд по использованию нетворкинга - Гайд по карьерному пути для новичков: как системно повышать доход - Гайд по карьерному пути для профессионалов: как пробить стеклянный потолок Если хочешь получить максимум за минимальные деньги, то сейчас действует годовое предложение 👑 со скидкой 50%, чтобы им воспользоваться у тебя должна быть действующая подписка STREAM или WORKSHOP (можно оформить эти подписки и сразу апнуться до PRO), далее в разделе "Подписки" нужно щелкнуть "Изменить" и выбрать годовую подписку PRO. Подписка дает максимальный доступ ко всем материалам и год на ознакомление с ними (включая новые материалы). 💡💡💡

Прошла первая практика по курсу Монолитных архитектур. Хочу поделиться впечатлениями. Во-первых, понял, что удачно выбрал размер группы. Мы подробно проработали вопросы каждого участника, поэтому практика длилась вместо запланированного часа в 2,5 раза дольше. Если бы сделал группу больше, то пришлось бы жертвовать качеством. Во-вторых, хорошо проработали практические вопросы: - я показал четыре основных способа проведения границы в модульном монолите - через общую БД, через прямое взаимодействие, через абстрактный интерфейс, через распределенную транзакцию. Разобрали конкретные плюсы и минусы таких подходов - проработали вопросы визуализации архитектуры, разобрали чем опасны нарушения логической и физической целостности модулей, как этого не допустить. - поговорили про толстые и тонкие границы, как их выявлять, так же как не допускать излишней грануляции системы на компоненты. И много других вопросов. Как использовать эти знания для личной пользы? 👑 в первую очередь не пытаться причинять людям радость, пытаясь сделать рабочие проекты лучше. У многих программистов возникает желание сразу стрельнуть из пушки по воробьям и применить все знания на рабочем проекте. Этого делать категорически не следует. 👑 вместо этого нужно применить знания при внедрении новых фич и на участках где давно планировался рефактоинг. Нужно использовать полученные знания в обсуждениях с командой, обдумывании решений и написании нового кода. Сначала начать примерять для себя, а потом уже команда сама заметит улучшения и люди сами начнут задавать вопросы. Главный принцип - внедрять изменения постепенно, без авралов и "давайте все перепишем". 👑 не стесняться использовать знания для продвижения личного бренда, это куда важнее для карьеры, чем попытки доказать, что все плохо и надо переделать. Обычно программистам интересно изучение архитектуры, поэтому можно начать с помощи коллегам, а дальше двигаться в сторону публичных выступлений (для этого, конечно, нужно пройти все практики, а не только одну). 👑 менторы могут передать полученные знания своим менти, тем самым помочь им лучше справиться с секцией систем-дизайна на собеседовании. В целом ощущения от практики офигенные, участники большие молодцы, стараются получить и закрепить новый опыт, а не просто нахвататься новых умных слов. Наша общая цель - практическая польза, и в этом я как раз могу помочь.

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

Почему ИИ собеседуют правильно, а человека нет Проблема собеседований лежит в том, что мы считаем, что у кандидатов-людей по умолчанию есть способность мыслить, в отличии от ИИ. Как мы тестируем людей? Задаём кучу вопросов из серии "расскажи как устроено..." и если вдуматься, то это проверка памяти человека. Нам такой шаблон навязали ещё в школе - помнит, значит знает и понимает. А вот с ИИ ситуация другая, никто не сомневается, что нейронка идеально помнит все знания интернета. Поэтому хочется проверить её способность мыслить и анализировать. Делается это очень просто - формулируется задание и проверяется результат. И вот здесь возникает вопрос, какого лешего мы по-разному тестируем (собеседуем) людей и машину, ведь нас интересует одинаковый результат. Если начать давать правильные задания, то выяснится страшная вещь - значительная часть кандидатов не может решать конкретные практические задачи, анализировать и делать выводы. И наше предположение, что такая возможность есть "by design" ошибочно. Если бы нам нужен был инструмент с идеальной памятью, то проще было бы взять чат-гпт, но мы ищем человека потому что хотим получить не просто инструмент, а специалиста с инженерным мышлением. Ну а пока, все ровно наоборот - круглое таскаем, квадратное катаем.

Искусственный интеллект меняет рынок. Готовы ли вы к новым правилам игры? Искусственный интеллект шагает по планете, и пока идут споры о том, заменит ли ИИ программистов полностью или, может быть, отберёт работу лишь у самых ленивых, мы начали готовиться к новым условиям рынка. Что нас ждёт? Будущее — за T-shaped специалистами, которые: ✔ Глубоко разбираются в своей области, ✔ Освоили System Design (да, это теперь must-have даже для фронтенда), ✔ Эффективно используют нейросети в работе. Мой прогноз: Обычные разработчики скоро станут не нужны — спрос будет только на тех, кто понимает архитектуру и умеет применять AI-инструменты. Такие специалисты — новая «нефть» для бизнеса, потому что их работа в разы эффективнее. Архитектура — непростая область. Я давно занимаюсь этим направлением: консультирую компании, сам работал в области архитектуры, запустил проект soer.pro, где собрал кучу материала. Поэтому у меня есть чёткое понимание того, что я хочу донести до людей. Проблема в том, что информации слишком много, а 90% — это «вода». Поэтому я сделал концентрированную выжимку и запланировал три практических курса: - Монолитная архитектура - Сервис-ориентированная архитектура (SOA) - Микросервисная архитектура Старт первого курса — 30.06.25! «Практическая архитектура монолитных приложений». Мы будем фокусироваться на: 🔹 Архитектурное проектирование 🔹 Документирование (без «магии» и лишней теории) 🔹 Максимум практики Подробная программа курса Как получить доступ? 📌 Все курсы доступны по подписке. 📌 Подписчики Stream и Workshop могут апгрейднуться на годовую PRO за полцены. (Количество мест в группе ограничены, цена на курс будет расти по мере наполнения группы, поэтому чем дольше ждете, тем дороже, даже с учетом скидки) Чтобы попасть на курс, нужно оформить заявку на участие. Для этого: 1. Зайти на platform.soer.pro; 2. Перейти в раздел «Обучение»; 3. Если у вас нет начатых курсов, нажать «Выбрать курс», если есть — щёлкнуть по кнопке «+» внизу страницы; 4. Выбрать курс «Практическая архитектура монолитных приложений (1.0.0)», нажав «Начать»; 5. Ознакомиться с содержанием курса и подтвердить участие, нажав «Начать». После этого вам нужно выполнить урок «Первые шаги при прохождении курса».

Монолитная архитектура - простая, мощная и часто недооцененная классика. Я собрал для вас все основные моменты, которые необходимо помнить, работая с этим архитектурным шаблоном. Постарался сделать емкои и без лишней воды.

На soer.pro вышел новый гайд для подписчиков уровня STREAM. Сегодня рассматриваем как расти после достижения стеклянного потолка Гайд по карьерному пути для профессионалов: как пробить стеклянный потолок. Это вторая часть из двух гайдов, которые помогут вам лучше прокачаться и мягко выйти на рынок. В первой части речь шла про получение первого опыта и первой работы, а во второй части я рассмотрел «боевые» советы для тех, кто уперся в зарплатный потолок и хочет сменить стратегию "меня выбирают" на "я выбираю". Итоговый список материалов по построению карьеры на платформе: 👑 Гайд по карьерному пути для новичков: как системно повышать доход (публично) 👑 Гайд по карьерному пути для профессионалов: как пробить стеклянный потолок (для STREAM) 👑 Приоритет архитектуры для ИИ (публично) 👑 Полный гайд по использованию нетворкинга (для STREAM) 👑 Как конкурировать с ИИ в ближайшие пять лет, если ты разработчик (для STREAM) 👑 Личные метрики (для STREAM)

Cursor CEO: Going Beyond Code, Superintelligent AI Agents, And Why Teste Still Matters (Рубрика #AI) Посмотрел интересное интервью Michael Truell с Garry Tan. Они говорили про будущее разработки и это действительно интересно, ведь Майкл — соучредитель и генеральный директор Anysphere, компании, создавшей Cursor, один из самых быстрорастущих AI-инструментов для кодирования. А Гарри — президент и генеральный директор Y Combinator, известного стартап-акселератора. Это интервью было 11 июня и оно проходило во время Demo Day Y Combinator Summer 2025, где представляются новые компании из текущего набора Y Combinator. Ниже представлены ключевые идеи интервью в моей интерпретации 1. Революционное видение будущего программирования Основная цель Cursor — изобрести новый тип программирования, где разработчики смогут просто описывать желаемый результат, а не писать сложный код. Майкл предвидит, что программисты будут становиться "дизайнерами логики", фокусируясь на высокоуровневом проектировании, а не на написании низкоуровневого кода. Интересно, что раньше часто говорили про языки программирования новых поколений, например, третьим поколением были стандартные C, C++, C#, Java и JavaScript, но люди говорили про четвертое поколение. Но оно особо не полетело:) А теперь новым поколением языков программирования похоже будет plain english/russian/whatever text (но лучше с правильными промптами). Интересно, что Майкл считает, что за следующие 5-10 лет произойдет значительное изменение в способах создания софта. 2. Текущее состояние AI в программировании Наибольшие изменения уже заметны в небольших кодовых базах, где разработчики могут работать на более высоком уровне абстракции. В среднем разработчики используют AI для написания 40-50% кода в Cursor, но все еще требуется человеческий контроль и понимание. Майкл говорит о том, что vibe coding пишется без глубокого понимания и не рекомендуется для долгосрочных проектов (а для прототипов он отлично подходит) 3. Технические вызовы и ограничения Ограниченный размер контекстного окна AI затрудняет работу с большими кодовыми базами, содержащими миллионы строк кода (что типично для больших компаний). Существующие модели испытывают трудности с непрерывным обучением и сохранением контекста организации и предыдущих решений. AI-модели пока не имеют четкого представления об эстетике, что требует участия человека-дизайнера. 4. История и эволюция Cursor Команда основателей из MIT первоначально работала над AI для автоматизированного проектирования (CAD), но позже переключилась на программирование. GitHub Copilot и исследования OpenAI о масштабируемости моделей стали ключевыми источниками вдохновения для создания Cursor. Вместо создания расширения для условного VSCode команда решила разработать собственный редактор, что оказалось важным преимуществом. 5. Рост и успех компании Anysphere достигла оценки в 9,9 миллиардов долларов после привлечения 900 миллионов долларов инвестиций. Компания достигла 100 миллионов долларов годового дохода всего за 20 месяцев после запуска, а затем выросла до 300 миллионов за два года и более 500 миллионов к середине 2025 года. Cursor используется в крупных технологических компаниях, включая OpenAI, Stripe, Spotify и других. 6. Будущее AI и программирования Способность создавать программное обеспечение станет доступной гораздо большему числу людей. Появится больше специализированного программного обеспечения для конкретных отраслей благодаря снижению барьеров для разработки. Несмотря на автоматизацию, "чувство вкуса" останется незаменимым человеческим качеством — оно позволяет определить, что именно нужно создать и как это должно работать. Если подводить итоги, то это действительно интересный взгялд на будущее программирование от гостя, который не просто его предсказывает, но и создает своими руками, так как Cursor стремится быть на переднем крае этой трансформации. По мнению Тралла, мы находимся в начале эпохи интеллекта, которая значительно расширит возможности создания для всех. #AI #ML #Software #DevEx #Engineering #Development

Ловите фундаментальное видео по чистой архитектуре, там есть вся теория. Автор реально заморочился, респект за проделанную работу.

Попросил ИИ написать акронимное предложение для "Соер - сила", он мне выдал: "Строгие ограничения естественно работают — современные инженеры любят архитектуру." Как говорится "и в чем он неправ?"

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