Forwarded from Соер.Клуб | инженерный подход
В Соер.Клубе задали вопрос о карьерном пути. Хочу продублировать сюда мой совет, чтобы ты тоже мог им воспользоваться.
1. Я бы начал с простой классификации — «Матрица самооценки умений и предпочтений».
Верхний левый квадрат — «Я умею и мне нравится» — это твоё стратегическое преимущество. Если этот список пустой, то я бы начал решать проблему именно отсюда.
2. Дальше нужно понять, насколько другим людям нужно то, что тебе нравится и что ты умеешь. Если ничего востребованного нет, можно переходить к «Я умею, но мне не нравится» — и туда уже набирать навыки, которые реально пользуются спросом.
3. Последний шаг — разобраться с самопрезентацией. Если у тебя крутые скилы, но сложно говорить с людьми и ещё сложнее подать себя как классный продукт, это тоже нужно исправить.
А дальше - продавать то, что ты отлично умеешь, желательно, чтобы это ещё и нравилось, тогда сможешь гораздо эффективнее двигаться в выбранном стеке.
1. Я бы начал с простой классификации — «Матрица самооценки умений и предпочтений».
| | Нравится | Не нравится |
|-----------|-------------|---------------|
| Я умею | Тут список | Тут список |
| Я не умею | Тут список | Тут список |
Верхний левый квадрат — «Я умею и мне нравится» — это твоё стратегическое преимущество. Если этот список пустой, то я бы начал решать проблему именно отсюда.
2. Дальше нужно понять, насколько другим людям нужно то, что тебе нравится и что ты умеешь. Если ничего востребованного нет, можно переходить к «Я умею, но мне не нравится» — и туда уже набирать навыки, которые реально пользуются спросом.
3. Последний шаг — разобраться с самопрезентацией. Если у тебя крутые скилы, но сложно говорить с людьми и ещё сложнее подать себя как классный продукт, это тоже нужно исправить.
А дальше - продавать то, что ты отлично умеешь, желательно, чтобы это ещё и нравилось, тогда сможешь гораздо эффективнее двигаться в выбранном стеке.
🔥27👍3❤2 1 1
Вопросы с подвохом, которые могут задать на систем-дизайн интервью.
На интервью по системному дизайну есть пара вопросов с подвохом, которые неплохо знать. Первый — это знать, в чем разница между "связностью" и "связанностью". Тут легко решить проблему, используя слова "когезия" и "зацепление". Другой вопрос — разница между модулем и компонентом.
Есть общее представление, что компонент отражает функциональную суть задачи, а модуль — структурную. То есть компонент показывает "что будет делать система?", а модуль — "как она это будет делать?".
Проблемы начинаются, когда задается вопрос о подчинении этих двух понятий по отношению друг к другу. Кажется, что раз компонент отвечает за функцию, а модуль за структуру, то компонент должен декомпозироваться через модули (грубо говоря, "компонент включает модули"). Логично, но ломается на примере UI-компонентов: ведь условная функциональная единица интерфейса "кнопка" — очевидно, является компонентом, но мы знаем кучу примеров, когда подобные компоненты включаются в один модуль. Получается, что нарушается принцип подчинения "от общего к частному".
На самом деле эта неточность легко разрешается, если мы введем два уровня архитектуры:
1. "Уровень приложения", где компонент ведет себя согласно закону "от общего к частному".
2. "Уровень кода", где компонент, наоборот, ведет себя "от частного к общему".
Зачем это надо на практике? Это помогает уменьшить количество противоречий и "сюрпризов" на этапе документирования (а потом и реализации) системы и, соответственно, правильно определить границы модулей и компонентов для более точного разделения обязанностей.
На интервью по системному дизайну есть пара вопросов с подвохом, которые неплохо знать. Первый — это знать, в чем разница между "связностью" и "связанностью". Тут легко решить проблему, используя слова "когезия" и "зацепление". Другой вопрос — разница между модулем и компонентом.
Есть общее представление, что компонент отражает функциональную суть задачи, а модуль — структурную. То есть компонент показывает "что будет делать система?", а модуль — "как она это будет делать?".
Проблемы начинаются, когда задается вопрос о подчинении этих двух понятий по отношению друг к другу. Кажется, что раз компонент отвечает за функцию, а модуль за структуру, то компонент должен декомпозироваться через модули (грубо говоря, "компонент включает модули"). Логично, но ломается на примере UI-компонентов: ведь условная функциональная единица интерфейса "кнопка" — очевидно, является компонентом, но мы знаем кучу примеров, когда подобные компоненты включаются в один модуль. Получается, что нарушается принцип подчинения "от общего к частному".
На самом деле эта неточность легко разрешается, если мы введем два уровня архитектуры:
1. "Уровень приложения", где компонент ведет себя согласно закону "от общего к частному".
2. "Уровень кода", где компонент, наоборот, ведет себя "от частного к общему".
Зачем это надо на практике? Это помогает уменьшить количество противоречий и "сюрпризов" на этапе документирования (а потом и реализации) системы и, соответственно, правильно определить границы модулей и компонентов для более точного разделения обязанностей.
👍30 8 7❤4👎1🔥1👀1😎1
Forwarded from Соер.Клуб | инженерный подход
Перенасыщенный информационный поток — это верный способ посадить нервную систему. Современные люди потребляют конские дозы информации, которые не несут никакой полезной нагрузки, но требуют постоянных умственных затрат. Причём часто мы изнашиваем нервную систему дополнительным стрессом от прочтения всякой ерунды.
Избежать новой информации невозможно, поэтому для себя стараюсь максимально ограничивать потребление ненужной информации, а в остальном сосредоточиться только на чём-то полезном. Поэтому задаю два важных вопроса:
1. «Что я узнал нового?»
2. «Что из нового оказалось полезным?»
Во втором вопросе есть подвох: не всегда понятно, что считать пользой. Полезной я считаю информацию, которая либо напрямую делает мою жизнь лучше, либо расширяет профессиональную эрудицию.
Мне кажется, что между потреблением полезной и бесполезной информации выбор очевиден.
Теперь почему не получится «не потреблять информацию». Тут всё просто: технологии массмедиа сильно продвинулись вперёд и легко обходят наши защитные механизмы. Тут меч сильно опережает щит.
Кроме этого, в современном обществе есть явный культ знаний, и люди его периодически пытаются игнорировать. Но, как правило, это приводит к тому, что вместо спокойного ритмичного развития они развиваются рывками, в моменте нагружая свой организм огромными порциями информации. Это приводит к банальному выгоранию и потере здоровья.
В целом моя идея в том, что если информационного потока нельзя избежать, то нужно его контролировать и делать максимально спокойным и полезным.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥48👍15 12 6❤2👎2😁2👌2🤝2
В рекомендации выдалось хорошее видео по ACID, понравилось простое и понятное объяснение, без лишней воды. Просили делиться подобными видео, вот ловите -
https://youtu.be/s4_bROEL4vQ?si=aGzAf3JFxPJGZzXd
https://youtu.be/s4_bROEL4vQ?si=aGzAf3JFxPJGZzXd
❤23👍15
Forwarded from Соер.Клуб | инженерный подход
Что нужно знать про контейнеризацию
Через пару недель на курсе по монолитным архитектурам будем разбирать, зачем нужна и как устроена контейнеризация. Ради интереса посмотрел ролики на 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 6👌4❤3👎3 2😁1
Ветвление в git - это с одной стороны очень простая штука, а с другой мало кто пользуется ей на максималках. В общем, хочу поделиться классным тренажером, который поможет научиться делать и использовать ветки в git-е, если вы реальный соер - https://learngitbranching.js.org
learngitbranching.js.org
Learn Git Branching
An interactive Git visualization tool to educate and challenge!
2👍48🔥12 3❤1🙏1
Недавно на созвоне в Соер.Клубе обсуждали вопросы создания Architecture Decision Record (ADR), у нас была задача описать условия при которых целесообразно создавать и вести ADR.
Обсудили огромное количество деталей, которые хочется обобщить и зафиксировать в виде коротких подсказок. Возможно вам тоже будет полезно.
#cards #adr
Обсудили огромное количество деталей, которые хочется обобщить и зафиксировать в виде коротких подсказок. Возможно вам тоже будет полезно.
#cards #adr
1👍40 9 6🔥4
Forwarded from Соер.Клуб | инженерный подход
Первый шаг к понимаю архитектуры ПО - понимание контекста решаемого вопроса.
Я много консультирую, провожу воркшопы, делаю курсы по архитектуре и заметил одну важную деталь - часто люди упускают момент, который является основным ключом к пониманию архитектуры - контекст.
Сложность в том, что по архитектуре ПО нет общего стандарта, который можно было бы брать за основу и говорить всем "так и только так правильно", одни и те же термины используются разными авторами в разных контекстам по-разному (например, "зависимость" в UML и зависимость в DIP - имеют разные смыслы, или "пасивность view" в MVC и MVP тоже разные, более того есть свой вариант MVC для десктопов и веб).
Поэтому при проектировании я придерживаюсь следующего порядка:
1. Определить контекст
2. Определит архитектурную идею (об этом как-нибудь тоже расскажу)
3. Отразить схему или диаграмму для иллюстрации идеи.
Графическое представление идеи - очень важно, но без контекста может сильно запутать. Пока не появится привычки отделять "мух от котлет" ни о каком понимании речи идти не может.
Я много консультирую, провожу воркшопы, делаю курсы по архитектуре и заметил одну важную деталь - часто люди упускают момент, который является основным ключом к пониманию архитектуры - контекст.
Сложность в том, что по архитектуре ПО нет общего стандарта, который можно было бы брать за основу и говорить всем "так и только так правильно", одни и те же термины используются разными авторами в разных контекстам по-разному (например, "зависимость" в UML и зависимость в DIP - имеют разные смыслы, или "пасивность view" в MVC и MVP тоже разные, более того есть свой вариант MVC для десктопов и веб).
Поэтому при проектировании я придерживаюсь следующего порядка:
1. Определить контекст
2. Определит архитектурную идею (об этом как-нибудь тоже расскажу)
3. Отразить схему или диаграмму для иллюстрации идеи.
Графическое представление идеи - очень важно, но без контекста может сильно запутать. Пока не появится привычки отделять "мух от котлет" ни о каком понимании речи идти не может.
1👍10 4 3
Хочу поделиться с вами публичным гайдом Как правильно использовать и обрабатывать исключения в программе, который поможет улучшить обработку ошибок и исключений на бэкенде. Если хотите такой же гайд для обработки ошибок на фронтенде, то давайте соберем 100 отметок 💡 и я подготовлю материал для вас.
Please open Telegram to view this post
VIEW IN TELEGRAM
SOER.MEDIA
Как правильно использовать и обрабатывать исключения в программе (для бэкенда)
Я постоянно сталкиваюсь с глубоким непониманием того как должны обрабатываться исключения в современных приложениях, реализующих клиент-серверный подход. Поэтому решил собрать краткий гайд об основных моментах, которые нужно учесть при обработке исключен