Forwarded from S0ER.Teach
Монолитная архитектура - простая, мощная и часто недооцененная классика.
Я собрал для вас все основные моменты, которые необходимо помнить, работая с этим архитектурным шаблоном.
Постарался сделать емкои и без лишней воды.
Я собрал для вас все основные моменты, которые необходимо помнить, работая с этим архитектурным шаблоном.
Постарался сделать емкои и без лишней воды.
🔥98👍29
Искусственный интеллект меняет рынок. Готовы ли вы к новым правилам игры?
Искусственный интеллект шагает по планете, и пока идут споры о том, заменит ли ИИ программистов полностью или, может быть, отберёт работу лишь у самых ленивых, мы начали готовиться к новым условиям рынка.
Что нас ждёт?
Будущее — за 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. Ознакомиться с содержанием курса и подтвердить участие, нажав «Начать».
После этого вам нужно выполнить урок «Первые шаги при прохождении курса».
Искусственный интеллект шагает по планете, и пока идут споры о том, заменит ли ИИ программистов полностью или, может быть, отберёт работу лишь у самых ленивых, мы начали готовиться к новым условиям рынка.
Что нас ждёт?
Будущее — за 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. Ознакомиться с содержанием курса и подтвердить участие, нажав «Начать».
После этого вам нужно выполнить урок «Первые шаги при прохождении курса».
👎33🔥16😁5
Forwarded from S0ER.Клуб | паблик
Почему ИИ собеседуют правильно, а человека нет
Проблема собеседований лежит в том, что мы считаем, что у кандидатов-людей по умолчанию есть способность мыслить, в отличии от ИИ.
Как мы тестируем людей? Задаём кучу вопросов из серии "расскажи как устроено..." и если вдуматься, то это проверка памяти человека. Нам такой шаблон навязали ещё в школе - помнит, значит знает и понимает.
А вот с ИИ ситуация другая, никто не сомневается, что нейронка идеально помнит все знания интернета. Поэтому хочется проверить её способность мыслить и анализировать. Делается это очень просто - формулируется задание и проверяется результат.
И вот здесь возникает вопрос, какого лешего мы по-разному тестируем (собеседуем) людей и машину, ведь нас интересует одинаковый результат.
Если начать давать правильные задания, то выяснится страшная вещь - значительная часть кандидатов не может решать конкретные практические задачи, анализировать и делать выводы. И наше предположение, что такая возможность есть "by design" ошибочно.
Если бы нам нужен был инструмент с идеальной памятью, то проще было бы взять чат-гпт, но мы ищем человека потому что хотим получить не просто инструмент, а специалиста с инженерным мышлением.
Ну а пока, все ровно наоборот - круглое таскаем, квадратное катаем.
Проблема собеседований лежит в том, что мы считаем, что у кандидатов-людей по умолчанию есть способность мыслить, в отличии от ИИ.
Как мы тестируем людей? Задаём кучу вопросов из серии "расскажи как устроено..." и если вдуматься, то это проверка памяти человека. Нам такой шаблон навязали ещё в школе - помнит, значит знает и понимает.
А вот с ИИ ситуация другая, никто не сомневается, что нейронка идеально помнит все знания интернета. Поэтому хочется проверить её способность мыслить и анализировать. Делается это очень просто - формулируется задание и проверяется результат.
И вот здесь возникает вопрос, какого лешего мы по-разному тестируем (собеседуем) людей и машину, ведь нас интересует одинаковый результат.
Если начать давать правильные задания, то выяснится страшная вещь - значительная часть кандидатов не может решать конкретные практические задачи, анализировать и делать выводы. И наше предположение, что такая возможность есть "by design" ошибочно.
Если бы нам нужен был инструмент с идеальной памятью, то проще было бы взять чат-гпт, но мы ищем человека потому что хотим получить не просто инструмент, а специалиста с инженерным мышлением.
Ну а пока, все ровно наоборот - круглое таскаем, квадратное катаем.
🔥63👍18❤3😁2
Forwarded from S0ER.Клуб | паблик
Могут ли новички легко выполнять работу сеньора? Опыт погружения новичков в NarisApp.
Постепенно погружаюсь в мир обучения и разбираюсь с тем, что же на самом деле сложного в работе сеньора.
В этом мне сильно помогает опыт, который я получил, работая над проектом NarisApp. У меня была идеальная возможность погрузить людей в реальный проект со сложными процессами и посмотреть, как они справляются с задачами.
Первое, что я понял - сложно не программировать, сложно правильно настроить проект. Мне пришлось сделать целый видео-гайд, чтобы люди могли развернуть, запустить и настроить окружение. Но даже имея такой материал, многие не могли выполнить входное задание.
Второе - писать код и писать понятный код - это две разные задачи. Одному богу известно, сколько сил потрачено на то, чтобы переписать чужой код до вменяемого состояния.
Третье - первые неудачи полностью уничтожают мотивацию. Если человек начал буксовать на первом задании, то вероятность того, что он бросит всё через пару дней, стремится к единице.
В итоге я понял важную вещь - писать код может каждый, но далеко не каждый может свести работу программиста в единую систему, далеко не каждый умеет искать решение проблемы и не сдаваться при первой неудаче. Поэтому я согласен с теми, кто говорит, что писать код легко, но работа программиста гораздо сложнее и разнообразнее, и именно это разнообразие создаёт сложности.
Постепенно погружаюсь в мир обучения и разбираюсь с тем, что же на самом деле сложного в работе сеньора.
В этом мне сильно помогает опыт, который я получил, работая над проектом NarisApp. У меня была идеальная возможность погрузить людей в реальный проект со сложными процессами и посмотреть, как они справляются с задачами.
Первое, что я понял - сложно не программировать, сложно правильно настроить проект. Мне пришлось сделать целый видео-гайд, чтобы люди могли развернуть, запустить и настроить окружение. Но даже имея такой материал, многие не могли выполнить входное задание.
Второе - писать код и писать понятный код - это две разные задачи. Одному богу известно, сколько сил потрачено на то, чтобы переписать чужой код до вменяемого состояния.
Третье - первые неудачи полностью уничтожают мотивацию. Если человек начал буксовать на первом задании, то вероятность того, что он бросит всё через пару дней, стремится к единице.
В итоге я понял важную вещь - писать код может каждый, но далеко не каждый может свести работу программиста в единую систему, далеко не каждый умеет искать решение проблемы и не сдаваться при первой неудаче. Поэтому я согласен с теми, кто говорит, что писать код легко, но работа программиста гораздо сложнее и разнообразнее, и именно это разнообразие создаёт сложности.
👍59
Forwarded from S0ER.Клуб | паблик
Прошла первая практика по курсу Монолитных архитектур. Хочу поделиться впечатлениями.
Во-первых, понял, что удачно выбрал размер группы. Мы подробно проработали вопросы каждого участника, поэтому практика длилась вместо запланированного часа в 2,5 раза дольше. Если бы сделал группу больше, то пришлось бы жертвовать качеством.
Во-вторых, хорошо проработали практические вопросы:
- я показал четыре основных способа проведения границы в модульном монолите - через общую БД, через прямое взаимодействие, через абстрактный интерфейс, через распределенную транзакцию. Разобрали конкретные плюсы и минусы таких подходов
- проработали вопросы визуализации архитектуры, разобрали чем опасны нарушения логической и физической целостности модулей, как этого не допустить.
- поговорили про толстые и тонкие границы, как их выявлять, так же как не допускать излишней грануляции системы на компоненты.
И много других вопросов.
Как использовать эти знания для личной пользы?
👑 в первую очередь не пытаться причинять людям радость, пытаясь сделать рабочие проекты лучше. У многих программистов возникает желание сразу стрельнуть из пушки по воробьям и применить все знания на рабочем проекте. Этого делать категорически не следует.
👑 вместо этого нужно применить знания при внедрении новых фич и на участках где давно планировался рефактоинг. Нужно использовать полученные знания в обсуждениях с командой, обдумывании решений и написании нового кода. Сначала начать примерять для себя, а потом уже команда сама заметит улучшения и люди сами начнут задавать вопросы. Главный принцип - внедрять изменения постепенно, без авралов и "давайте все перепишем".
👑 не стесняться использовать знания для продвижения личного бренда, это куда важнее для карьеры, чем попытки доказать, что все плохо и надо переделать. Обычно программистам интересно изучение архитектуры, поэтому можно начать с помощи коллегам, а дальше двигаться в сторону публичных выступлений (для этого, конечно, нужно пройти все практики, а не только одну).
👑 менторы могут передать полученные знания своим менти, тем самым помочь им лучше справиться с секцией систем-дизайна на собеседовании.
В целом ощущения от практики офигенные, участники большие молодцы, стараются получить и закрепить новый опыт, а не просто нахвататься новых умных слов. Наша общая цель - практическая польза, и в этом я как раз могу помочь.
Во-первых, понял, что удачно выбрал размер группы. Мы подробно проработали вопросы каждого участника, поэтому практика длилась вместо запланированного часа в 2,5 раза дольше. Если бы сделал группу больше, то пришлось бы жертвовать качеством.
Во-вторых, хорошо проработали практические вопросы:
- я показал четыре основных способа проведения границы в модульном монолите - через общую БД, через прямое взаимодействие, через абстрактный интерфейс, через распределенную транзакцию. Разобрали конкретные плюсы и минусы таких подходов
- проработали вопросы визуализации архитектуры, разобрали чем опасны нарушения логической и физической целостности модулей, как этого не допустить.
- поговорили про толстые и тонкие границы, как их выявлять, так же как не допускать излишней грануляции системы на компоненты.
И много других вопросов.
Как использовать эти знания для личной пользы?
В целом ощущения от практики офигенные, участники большие молодцы, стараются получить и закрепить новый опыт, а не просто нахвататься новых умных слов. Наша общая цель - практическая польза, и в этом я как раз могу помочь.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23❤10👍6
Forwarded from S0ER.Клуб | паблик
#бриф
За последний месяц опубликовано много разных материалов, которые помогают развиваться и строить карьеру в АйТи, чтобы ты мог найти все полезное в одном месте ознакомься с брифом ниже.
Лекции по архитектуре
- Лекция. Введение в монолитную архитектуру
- Лекция. Процесс разработки ПО
- Лекция. Документирование при проектировании архитектуры
Воркшопы
- Воркшоп. Признаки монолитной архитектуры в реальных проектах
- Воркшоп. Создание монорепозитория
- Воркшоп. Разбираем пример документирования
Созвоны
- Созвон. Анализ опенсорс приложения и построение его архитектуры
- Созвон. Создание собственного проекта в репозитории
- Созвон. Проектирование и создание собственных решений с помощью ADR
Соер.Клуб
- Обсудили подход "Parse don't validate'
- Обсудили архитектуру мультиагентов ИИ
Гайды
- Как конкурировать с ИИ в ближайшие пять лет, если ты разработчик
- Полный гайд по использованию нетворкинга
- Гайд по карьерному пути для новичков: как системно повышать доход
- Гайд по карьерному пути для профессионалов: как пробить стеклянный потолок
Если хочешь получить максимум за минимальные деньги, то сейчас действует годовое предложение
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9👎6
Forwarded from S0ER.Клуб | паблик
В Соер.Клубе задали вопрос о карьерном пути. Хочу продублировать сюда мой совет, чтобы ты тоже мог им воспользоваться.
1. Я бы начал с простой классификации — «Матрица самооценки умений и предпочтений».
Верхний левый квадрат — «Я умею и мне нравится» — это твоё стратегическое преимущество. Если этот список пустой, то я бы начал решать проблему именно отсюда.
2. Дальше нужно понять, насколько другим людям нужно то, что тебе нравится и что ты умеешь. Если ничего востребованного нет, можно переходить к «Я умею, но мне не нравится» — и туда уже набирать навыки, которые реально пользуются спросом.
3. Последний шаг — разобраться с самопрезентацией. Если у тебя крутые скилы, но сложно говорить с людьми и ещё сложнее подать себя как классный продукт, это тоже нужно исправить.
А дальше - продавать то, что ты отлично умеешь, желательно, чтобы это ещё и нравилось, тогда сможешь гораздо эффективнее двигаться в выбранном стеке.
1. Я бы начал с простой классификации — «Матрица самооценки умений и предпочтений».
| | Нравится | Не нравится |
|-----------|-------------|---------------|
| Я умею | Тут список | Тут список |
| Я не умею | Тут список | Тут список |
Верхний левый квадрат — «Я умею и мне нравится» — это твоё стратегическое преимущество. Если этот список пустой, то я бы начал решать проблему именно отсюда.
2. Дальше нужно понять, насколько другим людям нужно то, что тебе нравится и что ты умеешь. Если ничего востребованного нет, можно переходить к «Я умею, но мне не нравится» — и туда уже набирать навыки, которые реально пользуются спросом.
3. Последний шаг — разобраться с самопрезентацией. Если у тебя крутые скилы, но сложно говорить с людьми и ещё сложнее подать себя как классный продукт, это тоже нужно исправить.
А дальше - продавать то, что ты отлично умеешь, желательно, чтобы это ещё и нравилось, тогда сможешь гораздо эффективнее двигаться в выбранном стеке.
🔥27👍3❤2
Вопросы с подвохом, которые могут задать на систем-дизайн интервью.
На интервью по системному дизайну есть пара вопросов с подвохом, которые неплохо знать. Первый — это знать, в чем разница между "связностью" и "связанностью". Тут легко решить проблему, используя слова "когезия" и "зацепление". Другой вопрос — разница между модулем и компонентом.
Есть общее представление, что компонент отражает функциональную суть задачи, а модуль — структурную. То есть компонент показывает "что будет делать система?", а модуль — "как она это будет делать?".
Проблемы начинаются, когда задается вопрос о подчинении этих двух понятий по отношению друг к другу. Кажется, что раз компонент отвечает за функцию, а модуль за структуру, то компонент должен декомпозироваться через модули (грубо говоря, "компонент включает модули"). Логично, но ломается на примере UI-компонентов: ведь условная функциональная единица интерфейса "кнопка" — очевидно, является компонентом, но мы знаем кучу примеров, когда подобные компоненты включаются в один модуль. Получается, что нарушается принцип подчинения "от общего к частному".
На самом деле эта неточность легко разрешается, если мы введем два уровня архитектуры:
1. "Уровень приложения", где компонент ведет себя согласно закону "от общего к частному".
2. "Уровень кода", где компонент, наоборот, ведет себя "от частного к общему".
Зачем это надо на практике? Это помогает уменьшить количество противоречий и "сюрпризов" на этапе документирования (а потом и реализации) системы и, соответственно, правильно определить границы модулей и компонентов для более точного разделения обязанностей.
На интервью по системному дизайну есть пара вопросов с подвохом, которые неплохо знать. Первый — это знать, в чем разница между "связностью" и "связанностью". Тут легко решить проблему, используя слова "когезия" и "зацепление". Другой вопрос — разница между модулем и компонентом.
Есть общее представление, что компонент отражает функциональную суть задачи, а модуль — структурную. То есть компонент показывает "что будет делать система?", а модуль — "как она это будет делать?".
Проблемы начинаются, когда задается вопрос о подчинении этих двух понятий по отношению друг к другу. Кажется, что раз компонент отвечает за функцию, а модуль за структуру, то компонент должен декомпозироваться через модули (грубо говоря, "компонент включает модули"). Логично, но ломается на примере UI-компонентов: ведь условная функциональная единица интерфейса "кнопка" — очевидно, является компонентом, но мы знаем кучу примеров, когда подобные компоненты включаются в один модуль. Получается, что нарушается принцип подчинения "от общего к частному".
На самом деле эта неточность легко разрешается, если мы введем два уровня архитектуры:
1. "Уровень приложения", где компонент ведет себя согласно закону "от общего к частному".
2. "Уровень кода", где компонент, наоборот, ведет себя "от частного к общему".
Зачем это надо на практике? Это помогает уменьшить количество противоречий и "сюрпризов" на этапе документирования (а потом и реализации) системы и, соответственно, правильно определить границы модулей и компонентов для более точного разделения обязанностей.
👍29
Forwarded from S0ER.Клуб | паблик
Перенасыщенный информационный поток — это верный способ посадить нервную систему. Современные люди потребляют конские дозы информации, которые не несут никакой полезной нагрузки, но требуют постоянных умственных затрат. Причём часто мы изнашиваем нервную систему дополнительным стрессом от прочтения всякой ерунды.
Избежать новой информации невозможно, поэтому для себя стараюсь максимально ограничивать потребление ненужной информации, а в остальном сосредоточиться только на чём-то полезном. Поэтому задаю два важных вопроса:
1. «Что я узнал нового?»
2. «Что из нового оказалось полезным?»
Во втором вопросе есть подвох: не всегда понятно, что считать пользой. Полезной я считаю информацию, которая либо напрямую делает мою жизнь лучше, либо расширяет профессиональную эрудицию.
Мне кажется, что между потреблением полезной и бесполезной информации выбор очевиден.
Теперь почему не получится «не потреблять информацию». Тут всё просто: технологии массмедиа сильно продвинулись вперёд и легко обходят наши защитные механизмы. Тут меч сильно опережает щит.
Кроме этого, в современном обществе есть явный культ знаний, и люди его периодически пытаются игнорировать. Но, как правило, это приводит к тому, что вместо спокойного ритмичного развития они развиваются рывками, в моменте нагружая свой организм огромными порциями информации. Это приводит к банальному выгоранию и потере здоровья.
В целом моя идея в том, что если информационного потока нельзя избежать, то нужно его контролировать и делать максимально спокойным и полезным.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥46👍14
В рекомендации выдалось хорошее видео по ACID, понравилось простое и понятное объяснение, без лишней воды. Просили делиться подобными видео, вот ловите -
https://youtu.be/s4_bROEL4vQ?si=aGzAf3JFxPJGZzXd
https://youtu.be/s4_bROEL4vQ?si=aGzAf3JFxPJGZzXd
❤23👍15
Forwarded from S0ER.Клуб | паблик
Что нужно знать про контейнеризацию
Через пару недель на курсе по монолитным архитектурам будем разбирать, зачем нужна и как устроена контейнеризация. Ради интереса посмотрел ролики на YouTube по этой теме и хочу указать на очевидные пробелы, которые заметил.
Итак, нам часто говорят: «Сегодня знания не нужны, всё есть в бесплатном доступе». К сожалению, это не так. В открытом доступе — в основном видео, где пересказывают документацию Docker. А когда речь заходит про контейнеры, звучит что-то вроде:
А потом мы удивляемся, когда разработчики говорят:
Между тем, отладка и поиск корневых причин сбоев — важнейшая часть работы инженера (соера). Без глубокого понимания сути процесса это просто невозможно.
Чтобы разобраться, как Docker работает под капотом, обязательно нужно рассматривать:
✅ механизмы изоляции в ядре: namespace и cgroups,
✅ как именно устроена изоляция,
✅ как получать доступ к ключевым метрикам работы контейнеров (например, через Berkeley Packet Filter),
✅ виртуальные сети, которые требуют понимания iptables (Docker активно их использует).
Постоянно возвращаюсь к вопросу: могут ли люди, которые сами учились по бесплатным мануалам и никогда не применяли инструмент на практике, помочь в его изучении?
Глядя на ролики в YouTube, создаётся ощущение, что это больше про пиар, чем про знания. Конечно, не все видео — просто пересказ документации, но в массе своей ситуация печальная.
Через пару недель на курсе по монолитным архитектурам будем разбирать, зачем нужна и как устроена контейнеризация. Ради интереса посмотрел ролики на YouTube по этой теме и хочу указать на очевидные пробелы, которые заметил.
Итак, нам часто говорят: «Сегодня знания не нужны, всё есть в бесплатном доступе». К сожалению, это не так. В открытом доступе — в основном видео, где пересказывают документацию Docker. А когда речь заходит про контейнеры, звучит что-то вроде:
«Это такая магия, которая как-то работает и делает легковесные виртуалки».
А потом мы удивляемся, когда разработчики говорят:
«Не знаю, почему не работает, у меня локально всё ок».
Между тем, отладка и поиск корневых причин сбоев — важнейшая часть работы инженера (соера). Без глубокого понимания сути процесса это просто невозможно.
Чтобы разобраться, как Docker работает под капотом, обязательно нужно рассматривать:
Постоянно возвращаюсь к вопросу: могут ли люди, которые сами учились по бесплатным мануалам и никогда не применяли инструмент на практике, помочь в его изучении?
Глядя на ролики в YouTube, создаётся ощущение, что это больше про пиар, чем про знания. Конечно, не все видео — просто пересказ документации, но в массе своей ситуация печальная.
Please open Telegram to view this post
VIEW IN TELEGRAM
4👍21
Ветвление в git - это с одной стороны очень простая штука, а с другой мало кто пользуется ей на максималках. В общем, хочу поделиться классным тренажером, который поможет научиться делать и использовать ветки в git-е, если вы реальный соер - https://learngitbranching.js.org
learngitbranching.js.org
Learn Git Branching
An interactive Git visualization tool to educate and challenge!
2👍48🔥10