Code of Architecture - "Distributed Systems, 4th Ed" #5 (Coordination)
Сегодня в 18:00 по Москве мы продолжим обсуждать книгу "Distributed Systems".
В этом выпуски мы обсудим главу про координацию частей распределенной системы.
Предыдущие выпуски были посвящены общему обзору книги, обсуждению архитектуры, процессов, коммуникаций, а теперь мы дошли до обсуждения следующих важных вопросов
- Как синхронизировать часы в разных частях распределенной системы
- Что такое логические часы (logical clocks)
- Как делать взаимные блокировки (mutual exclusion), чтобы совместно использовать ресурсы
- Как можно выбирать лидера (election algorithms)
- Как организовать координацию при помощи сплетен (gossip-based coordination)
- Как работает publish-subscribe в распределенных системах, то есть как распределено делать event matching
- Как оценивать близость двух частей распределенной системы между собой (location systems и GPS в качестве примера)
В выпуске участвуют
- Илья Зонов @ Tinkoff
- Даниил Кулешов @ Tinkoff
- Сергей Гоппиков @ Tinkoff
- Александр Поломодов @ Tinkoff
#SoftwareArchitecture #DistributedSystems #Architecture #SystemDesign #Software #CoA
Сегодня в 18:00 по Москве мы продолжим обсуждать книгу "Distributed Systems".
В этом выпуски мы обсудим главу про координацию частей распределенной системы.
Предыдущие выпуски были посвящены общему обзору книги, обсуждению архитектуры, процессов, коммуникаций, а теперь мы дошли до обсуждения следующих важных вопросов
- Как синхронизировать часы в разных частях распределенной системы
- Что такое логические часы (logical clocks)
- Как делать взаимные блокировки (mutual exclusion), чтобы совместно использовать ресурсы
- Как можно выбирать лидера (election algorithms)
- Как организовать координацию при помощи сплетен (gossip-based coordination)
- Как работает publish-subscribe в распределенных системах, то есть как распределено делать event matching
- Как оценивать близость двух частей распределенной системы между собой (location systems и GPS в качестве примера)
В выпуске участвуют
- Илья Зонов @ Tinkoff
- Даниил Кулешов @ Tinkoff
- Сергей Гоппиков @ Tinkoff
- Александр Поломодов @ Tinkoff
#SoftwareArchitecture #DistributedSystems #Architecture #SystemDesign #Software #CoA
👍13
An Elegant Puzzle. Systems of Engineering Management
Сегодня по дороге из Москвы в Сочи дочитал эту книгу, которую начал читать на этой неделе. Книга оказалась настолько интересной, что я почти не мог от нее оторваться пока летел и дальше ехал до Красной Поляны, куда внезапно уехал на выезд с коллегами:) Эту книгу написал Will Larson, который работал в Digg, Uber, Stripe. Этот же автор написал и книгу "Staff Engineer", которую я обозревал в двух статьях: 1, 2 и поэтому я знал, что чтение будет отборное:)
Сама книга состоит из 7 частей:
1. Introduction - здесь автор рассказывает про свой подход к engineering management
2. Organizations - здесь идет речь про определение размера команд, как оставаться на пути к высокоэффективным командам, как не оптимизировать сверху вниз (часто это работает плохо), как быть продуктивным в быстрорастущих компаниях, как планировать успех
3. Tools - здесь автор рассказывает про системное мышление и упоминает Медоуз с ее "Азбукой системного мышления" (про которую я писал ранее), как быть исполняющим обязанности продакт менеджера, как формлировать vision и strategy, как использовать метрики и baselines для организационного развития, как проводить масштабные миграции, как проводить инженерную организацию (и стоит ли это вообще делать), как формировать свои карьерные нарративы, как подходить к продвижению сложных тем без формального authority с использование подхода model-document-share, как делать презентации топ-менеджменту и управлять своим временем
4. Approaches - как не погрязнуть в управлении исключениями к собственным policies, как говорить нет, формулировать свою философию менеджмента, как понимать где у engineering managers возникают проблемы, как быть в партнерских отношениях со своим менеджером, находить себе зону ответственности и устанавливать направление развития организации
5. Culture - как формировать культуру инклюзивной организации с использованием возможностей и membership, как выбирать лидов проектов, делать своих peers первой командой, как балансировать positive и negative freedoms в культуре компании, отказаться от культуры героев в пользу устойчивого роста
6. Careers - как выстраивать процесс интервью, как проводить холодный sourcing, работать над воронкой найма, использовать performance management для развития уже нанятых сотрудников через понятные карьерные лестницы, как создавать специализированные роли вроде SRE или TPM (technical product manager), как проектировать циклы собеседований для желаемых позиций
7. Appendix - как оперировать в растущей оранизации: на уровне линейного менеджмента, уровне middle management и дальше менеджмента всей организации, а напоследок автор приводит список книг и white papers по интересным для него темам
#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering
Сегодня по дороге из Москвы в Сочи дочитал эту книгу, которую начал читать на этой неделе. Книга оказалась настолько интересной, что я почти не мог от нее оторваться пока летел и дальше ехал до Красной Поляны, куда внезапно уехал на выезд с коллегами:) Эту книгу написал Will Larson, который работал в Digg, Uber, Stripe. Этот же автор написал и книгу "Staff Engineer", которую я обозревал в двух статьях: 1, 2 и поэтому я знал, что чтение будет отборное:)
Сама книга состоит из 7 частей:
1. Introduction - здесь автор рассказывает про свой подход к engineering management
2. Organizations - здесь идет речь про определение размера команд, как оставаться на пути к высокоэффективным командам, как не оптимизировать сверху вниз (часто это работает плохо), как быть продуктивным в быстрорастущих компаниях, как планировать успех
3. Tools - здесь автор рассказывает про системное мышление и упоминает Медоуз с ее "Азбукой системного мышления" (про которую я писал ранее), как быть исполняющим обязанности продакт менеджера, как формлировать vision и strategy, как использовать метрики и baselines для организационного развития, как проводить масштабные миграции, как проводить инженерную организацию (и стоит ли это вообще делать), как формировать свои карьерные нарративы, как подходить к продвижению сложных тем без формального authority с использование подхода model-document-share, как делать презентации топ-менеджменту и управлять своим временем
4. Approaches - как не погрязнуть в управлении исключениями к собственным policies, как говорить нет, формулировать свою философию менеджмента, как понимать где у engineering managers возникают проблемы, как быть в партнерских отношениях со своим менеджером, находить себе зону ответственности и устанавливать направление развития организации
5. Culture - как формировать культуру инклюзивной организации с использованием возможностей и membership, как выбирать лидов проектов, делать своих peers первой командой, как балансировать positive и negative freedoms в культуре компании, отказаться от культуры героев в пользу устойчивого роста
6. Careers - как выстраивать процесс интервью, как проводить холодный sourcing, работать над воронкой найма, использовать performance management для развития уже нанятых сотрудников через понятные карьерные лестницы, как создавать специализированные роли вроде SRE или TPM (technical product manager), как проектировать циклы собеседований для желаемых позиций
7. Appendix - как оперировать в растущей оранизации: на уровне линейного менеджмента, уровне middle management и дальше менеджмента всей организации, а напоследок автор приводит список книг и white papers по интересным для него темам
#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering
👍25
Анонс моего выступления на Teamlead Conf, что будет в конце февраля. Если будете на конференции подходите пообщаться
Forwarded from TeamLead Сonf
⠀
📋 https://vk.cc/clA5d1
⠀
Наем инженеров обсуждается на конференциях довольно часто. Кто-то рассказывает про то, как нанимает за одну встречу, а другие говорят про свои многоэтапные интервью. А вот про наем технических руководителей (teamlead, engineering manager, director of engineering) рассказывают гораздо реже.
⠀
В этом докладе Александр попробует исправить эту несправедливость и поделится историей про то, как это выглядит в Tinkoff. Он расскажет про их этапы интервью, объяснит, зачем они им нужны и что они проверяют, а также даст рекомендации, как к ним подготовиться. Эта информация будет полезна слушателям, даже если они не собираются менять работу, так как она позволит им лучше исполнять роль технического руководителя на текущем месте работы.
⠀
Ждем вас 27 и 28 февраля на TeamLead Conf 2023 🖐
⠀
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8👏5
Вчера мы провели пятый стрим клуба Code of Architecture по книге “Distributed Systems”, в котором мы обсудили вопросы как организовать координацию разных частей распределенной системы между собой, поговорив про
- физические и логические часы
- взаимные блокировки
- выбор лидера
- подход publish-subscribe в распределенных системах
- близость узлов между собой и как ее можно оценивать
Гостями стрима были
- Сергей Гоппиков, руководитель команд платформы открытия продуктов Tinkoff Business
- Даниил Кулешов, архитектор новой системы авторизации для клиентов Тинькофф
Артефакты с этого стрима доступны по ссылкам
- Статья с кратким обзором
- Запись стрима
- Miro доска с презентацией
#SoftwareArchitecture #DistributedSystems #Architecture #SystemDesign #Software #CoA
- физические и логические часы
- взаимные блокировки
- выбор лидера
- подход publish-subscribe в распределенных системах
- близость узлов между собой и как ее можно оценивать
Гостями стрима были
- Сергей Гоппиков, руководитель команд платформы открытия продуктов Tinkoff Business
- Даниил Кулешов, архитектор новой системы авторизации для клиентов Тинькофф
Артефакты с этого стрима доступны по ссылкам
- Статья с кратким обзором
- Запись стрима
- Miro доска с презентацией
#SoftwareArchitecture #DistributedSystems #Architecture #SystemDesign #Software #CoA
Medium
Code of Architecture — “Distributed Systems, 4th Ed” #5 (Coordination)
Это пятый выпуск клуба “Code of Architecture” по книге “Распределенные системы” ван Стина и Таненбаума, в котором мы обсуждаем главу про…
👍13
Domain-Driven Design: Tackling Complexity in the Heart of Software
Это каноническая книга, в которой Эрик Эванс изложил концепцию Domain Driven Design. Про нее часто говорят, но гораздо реже ее начинают читать, а дочитывают до конца только избранные. Возможно, причина этого станет ясна, если посмотреть на приложенные изображения. Но несмотря на сложность, я рекомендую эту книгу к прочтению, хотя сам до конца ее так и не дочитал:))
#DDD #SoftwareArchitecture #Architecture
Это каноническая книга, в которой Эрик Эванс изложил концепцию Domain Driven Design. Про нее часто говорят, но гораздо реже ее начинают читать, а дочитывают до конца только избранные. Возможно, причина этого станет ясна, если посмотреть на приложенные изображения. Но несмотря на сложность, я рекомендую эту книгу к прочтению, хотя сам до конца ее так и не дочитал:))
#DDD #SoftwareArchitecture #Architecture
😁16👍6🤯2🤣2
Designing Distributed Systems
Автор книги является сооснователем kubernetes, поэтому его опыт в проектировании распределенных систем является довольно актуальным:) Книга мне показалось хорошей, но одновременно слишком простой. Но за счет этого она отлично подойдет новичкам вступающим на запутанную дорожку distributed systems:)
Книга состоит из 3х частей:
- одноузловые паттерны проектирования
- паттерны проектирования обслуживающих систем
- паттерны проектирования систем пакетных вычислений
Все паттерны даются в контексте контейнеров и их оркестрации, книга содержит практические примеры, для реализации которых используется инсталляция kubernetes и его примитивы, такие как pods, deployments, services, etc. Ближе к концу книги вы попробуете использовать helm для разворачивания etcd, kafka и иже с ним.
В первой части рассматриваются паттерны:
- sidecar: для https, динамической конфигурации и метрик
- ambassador: для использования шардированного сервиса и для сплита трафика для тестирования разных версий
- adapters: мониторинг, журналирование
Во второй части рассматриваются:
- репликация: для stateless сервсиов, sticky sessions, кеширование, …
- шардирование: консистентный хеш, шардирование реплицированных сервисов, …
- scatter-gather: распределенный поиск по документам
- FaaS и events: преимущества и недостатки FaaS, реализация декораторов на функциях
- ownership election: локи для распределенных систем
В третьей части рассматриваются паттерны проектирования систем пакетных вычислений:
- системы на основе очередей задач
- событийно-ориентированная пакетная обработка
- координированная пакетная обработка
#DistributedSystems #Architecture #SoftwareArchitecture #SystemDesign #Software #SoftwareDevelopment
Автор книги является сооснователем kubernetes, поэтому его опыт в проектировании распределенных систем является довольно актуальным:) Книга мне показалось хорошей, но одновременно слишком простой. Но за счет этого она отлично подойдет новичкам вступающим на запутанную дорожку distributed systems:)
Книга состоит из 3х частей:
- одноузловые паттерны проектирования
- паттерны проектирования обслуживающих систем
- паттерны проектирования систем пакетных вычислений
Все паттерны даются в контексте контейнеров и их оркестрации, книга содержит практические примеры, для реализации которых используется инсталляция kubernetes и его примитивы, такие как pods, deployments, services, etc. Ближе к концу книги вы попробуете использовать helm для разворачивания etcd, kafka и иже с ним.
В первой части рассматриваются паттерны:
- sidecar: для https, динамической конфигурации и метрик
- ambassador: для использования шардированного сервиса и для сплита трафика для тестирования разных версий
- adapters: мониторинг, журналирование
Во второй части рассматриваются:
- репликация: для stateless сервсиов, sticky sessions, кеширование, …
- шардирование: консистентный хеш, шардирование реплицированных сервисов, …
- scatter-gather: распределенный поиск по документам
- FaaS и events: преимущества и недостатки FaaS, реализация декораторов на функциях
- ownership election: локи для распределенных систем
В третьей части рассматриваются паттерны проектирования систем пакетных вычислений:
- системы на основе очередей задач
- событийно-ориентированная пакетная обработка
- координированная пакетная обработка
#DistributedSystems #Architecture #SoftwareArchitecture #SystemDesign #Software #SoftwareDevelopment
👍16🔥4
Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Шаблоны интеграции корпоративных приложений. Проектирование, создание и развертывание решений)
Эта классическая книга по паттернам интеграции, которая была издана почти 20 лет назад. Сегодня я решил про нее вспомнить, так как начал читать свеженькую книгу одного из соавторов, а именно Gregor Hophe "The Software Architecture Elevator" и дальше вспомнил, что про паттерны интеграции я еще в этом канале не вспоминал:)
Несмотря на недавнее совершеннолетие данная книга все еще является достаточно актуальной, ну за исключением главы “Новые стандарты и перспективы интеграции корпоративных приложений”:) А если серьезно, то в самом начале книги (2 глава) дается отличный обзор разных стилей интеграции приложений:
- передача файла (file transfer)
- общая база данных (shared database)
- удаленный вызов процедуры (remote procedure invocation)
- обмен сообщениями (messaging)
Для каждого из вариантов обсуждаются плюсы и минусы:) Исходя из названия книги, можно понять, что авторы, оценив и взвесив все варианты, останавливаются на интеграции путем обмена сообщениями.
Дальше авторы рассказывают про составные части системы обмена сообщениями, а в следующих главах подробно рассматривают паттерны для каждой из частей, а именно
- каналы обмена сообщениями
- построение сообщений
- маршрутизация сообщений
- преобразование сообщений
- конечные точки обмена сообщениями
В конце идет речь про вопросы управления системой, которые очень полезно рассмотреть, чтобы не погрязнуть в непроработанных заранее вопросах тестирования и отладки системы. Приятно, что в системе есть 3 практикума, где рассматривается создание несложных систем, с использованием только что рассмотренных паттернов. Изюминкой является рассмотрение процесса проектирования реальной системы по торговле облигациями в главе 13 данной книги.
#SoftwareDevelopment #SoftwareArchitecture #Architecture #SystemEngineering #DistributedSystems #SystemDesign #Patterns
Эта классическая книга по паттернам интеграции, которая была издана почти 20 лет назад. Сегодня я решил про нее вспомнить, так как начал читать свеженькую книгу одного из соавторов, а именно Gregor Hophe "The Software Architecture Elevator" и дальше вспомнил, что про паттерны интеграции я еще в этом канале не вспоминал:)
Несмотря на недавнее совершеннолетие данная книга все еще является достаточно актуальной, ну за исключением главы “Новые стандарты и перспективы интеграции корпоративных приложений”:) А если серьезно, то в самом начале книги (2 глава) дается отличный обзор разных стилей интеграции приложений:
- передача файла (file transfer)
- общая база данных (shared database)
- удаленный вызов процедуры (remote procedure invocation)
- обмен сообщениями (messaging)
Для каждого из вариантов обсуждаются плюсы и минусы:) Исходя из названия книги, можно понять, что авторы, оценив и взвесив все варианты, останавливаются на интеграции путем обмена сообщениями.
Дальше авторы рассказывают про составные части системы обмена сообщениями, а в следующих главах подробно рассматривают паттерны для каждой из частей, а именно
- каналы обмена сообщениями
- построение сообщений
- маршрутизация сообщений
- преобразование сообщений
- конечные точки обмена сообщениями
В конце идет речь про вопросы управления системой, которые очень полезно рассмотреть, чтобы не погрязнуть в непроработанных заранее вопросах тестирования и отладки системы. Приятно, что в системе есть 3 практикума, где рассматривается создание несложных систем, с использованием только что рассмотренных паттернов. Изюминкой является рассмотрение процесса проектирования реальной системы по торговле облигациями в главе 13 данной книги.
#SoftwareDevelopment #SoftwareArchitecture #Architecture #SystemEngineering #DistributedSystems #SystemDesign #Patterns
👍23❤2🔥1
Центральная станция (Central station)
Эта книга Леви Тидхара понравилась мне своей атмосферой будущего. Какого-то одного героя в книге нет, если не считать Станцию, на которой развиваются события и проносится жизнь разных персонажей, совмещающих жизнь в реале и виртуальности. Читать определенно интересно и есть отсылки как к реальным технологиям, достигли нового уровня, например AI, AR/VR, генная инженерия и биотехнологии в общем, так и на другую популярную фантастику. В общем, книга мне показалась заслуживающей прочтения:)
#SciFi
Эта книга Леви Тидхара понравилась мне своей атмосферой будущего. Какого-то одного героя в книге нет, если не считать Станцию, на которой развиваются события и проносится жизнь разных персонажей, совмещающих жизнь в реале и виртуальности. Читать определенно интересно и есть отсылки как к реальным технологиям, достигли нового уровня, например AI, AR/VR, генная инженерия и биотехнологии в общем, так и на другую популярную фантастику. В общем, книга мне показалась заслуживающей прочтения:)
#SciFi
👍16
Computing machinery and intelligence (Вычислительные машины и разум)
Это знаменитая статья Алана Тьюринга опубликованная в 1950 году в журнале Mind. В этой статье автор описал свой подход при поиске ответа на вопрос “Может ли машина мыслить”. Сейчас этот подход зачастую называют тестом Тьюринга, а сам автор назвал это игрой в имитацию. Знакомство с этим подходом сейчас как никогда актуально с учетом новой волны хайпа вокруг чатботов, которые умеют достаточно неплохо вести диалоги с пользователями.
Суть подхода Алана в том, что вопрос “может ли машина мыслить” слишком общий. Для того, чтобы на него ответить придется дать сначала определение того, что такое машина, потом что такое мыслить. Причем определение того, что мы понимаем под мышлением машины и мышлением человека может не совпасть. Поэтому Тьюринг предлагает сделать шаг в сторону и заменить изначальный вопрос на тот, что может быть относительно легко проверен, а именно сможет ли машина отвечать на вопросы человека так, чтобы он счел ее человеком. Если машина на это способна, то она проходит тест, который в наше время называется тестом Тьюринга. Забавно, что большую часть книги автор борется с возможными контраргументами относительно такого перехода и дальше относительно главного вопроса, причем борется успешно.
Чуть больше подробностей про контраргументы можно прочиитать в моей статье на Medium.
Плюс можно посмотреть фильм про Алана Тьюринга "Игра́ в имита́цию" ("The Imitation Game"), в котором рассказывается о вкладе Алана во взлом немецкой Энигмы во время второй мировой войны.
#ComputerScience #AI #PopularScience #ML #Software #Engineering
Это знаменитая статья Алана Тьюринга опубликованная в 1950 году в журнале Mind. В этой статье автор описал свой подход при поиске ответа на вопрос “Может ли машина мыслить”. Сейчас этот подход зачастую называют тестом Тьюринга, а сам автор назвал это игрой в имитацию. Знакомство с этим подходом сейчас как никогда актуально с учетом новой волны хайпа вокруг чатботов, которые умеют достаточно неплохо вести диалоги с пользователями.
Суть подхода Алана в том, что вопрос “может ли машина мыслить” слишком общий. Для того, чтобы на него ответить придется дать сначала определение того, что такое машина, потом что такое мыслить. Причем определение того, что мы понимаем под мышлением машины и мышлением человека может не совпасть. Поэтому Тьюринг предлагает сделать шаг в сторону и заменить изначальный вопрос на тот, что может быть относительно легко проверен, а именно сможет ли машина отвечать на вопросы человека так, чтобы он счел ее человеком. Если машина на это способна, то она проходит тест, который в наше время называется тестом Тьюринга. Забавно, что большую часть книги автор борется с возможными контраргументами относительно такого перехода и дальше относительно главного вопроса, причем борется успешно.
Чуть больше подробностей про контраргументы можно прочиитать в моей статье на Medium.
Плюс можно посмотреть фильм про Алана Тьюринга "Игра́ в имита́цию" ("The Imitation Game"), в котором рассказывается о вкладе Алана во взлом немецкой Энигмы во время второй мировой войны.
#ComputerScience #AI #PopularScience #ML #Software #Engineering
👍12❤1🔥1
Сегодня вечером в 18:00 по Мск будет шестой выпуск клуба "Code of Architecture" по книге "Распределенные системы" ван Стина и Таненбаума, в котором мы обсуждаем главу про именование. Предыдущие выпуски были посвящены общему обзору книги, обсуждению архитектуры, процессов, коммуникаций, координации, а теперь мы дошли до обсуждения следующих важных вопросов
- Зачем нужны имена, идентификаторы и адреса
- Что такое плоское именование (flat naming). Здесь в качестве примеров рассмотрим Distributed Hash Tables
- Что такое структурированное именование (structured naming). Здесь в качестве примеров рассмотрим работу DNS и Unix FileSystems
- Что такое основанное на атрибутах именование (attribute-based naming). Здесь вспомним про LDAP
- Что такое named-data networking
Встречаемся на ютуб-канале IT's Tinkoff.
#SoftwareArchitecture #DistributedSystems #Architecture #SystemDesign #Software #CoA
- Зачем нужны имена, идентификаторы и адреса
- Что такое плоское именование (flat naming). Здесь в качестве примеров рассмотрим Distributed Hash Tables
- Что такое структурированное именование (structured naming). Здесь в качестве примеров рассмотрим работу DNS и Unix FileSystems
- Что такое основанное на атрибутах именование (attribute-based naming). Здесь вспомним про LDAP
- Что такое named-data networking
Встречаемся на ютуб-канале IT's Tinkoff.
#SoftwareArchitecture #DistributedSystems #Architecture #SystemDesign #Software #CoA
👍9
Chaos Engineering. Building Confidence in System Behavior through Experiments
Эту книгу я прочитал лет 5 назад и мне она понравилась: отличная обложка и очень здравый и взвешенный подход для работы с комплексными системами
Книга начинается с главы "Зачем заниматься инженерией хаоса" и ее достаточно для того, чтобы определиться стоит ли читать книгу дальше. В первом абзаце авторы рассказывают о том, что Chaos Engineering используется для эмпирического исслледования поведения систем при помощи экспериментов. Чем-то этот подход напоминает мне лабораторные работы по физике/химии в университетские времена:) Основная цель эксперииментов узнать о потенциальных слабостях системы заблоговременно, а не в момент, когда они приводят к реальным проблемам. Хаос иненерия кардинально отличается от тестирования системы, т.к. в тестировании есть специфичные условия и ожидается специфичное поведение, тесты обычно имеют бинарную природу. В итоге, тесты не дают нам новой информации о системе.
В свою очередь, хаос инженерия в свою очередь при помощи экспериментов поззволяет нам лучше понять систему и узнать об особенностях ее функционирования.
В этой же главе рассказывается о пререквизитах для Chaos Engineering: для определения степени готовности вашей организации к использованию Chaos Engineering вам требуется ответить на 1 вопрос:"Достаточно ли устойчива ваша система к событиям реального мира, например, отказам сервисов или пикам сетевых задержек (network latency)".
Если ответ "нет", то до вы знаете что вам стоит сделать до того, как изучать данную книгу:) Думаю, что большая часть читающих книгу отсеивается на данных пререквизитах:)
Но представим, что мы ответил "Да" - в этом случае вы попадаете в прекрасный мир chaos engineering, который помогает контролировать сложность систем и спать спокойно:)
Если тема вас заинтересовала, то предлагаю вам самим ознакомиться с этой книгой:)
#Chaos #Engineering #SystemEngineering #SystemDesign #SoftwareArchitecture #Software #SoftwareDevelopment
Эту книгу я прочитал лет 5 назад и мне она понравилась: отличная обложка и очень здравый и взвешенный подход для работы с комплексными системами
Книга начинается с главы "Зачем заниматься инженерией хаоса" и ее достаточно для того, чтобы определиться стоит ли читать книгу дальше. В первом абзаце авторы рассказывают о том, что Chaos Engineering используется для эмпирического исслледования поведения систем при помощи экспериментов. Чем-то этот подход напоминает мне лабораторные работы по физике/химии в университетские времена:) Основная цель эксперииментов узнать о потенциальных слабостях системы заблоговременно, а не в момент, когда они приводят к реальным проблемам. Хаос иненерия кардинально отличается от тестирования системы, т.к. в тестировании есть специфичные условия и ожидается специфичное поведение, тесты обычно имеют бинарную природу. В итоге, тесты не дают нам новой информации о системе.
В свою очередь, хаос инженерия в свою очередь при помощи экспериментов поззволяет нам лучше понять систему и узнать об особенностях ее функционирования.
В этой же главе рассказывается о пререквизитах для Chaos Engineering: для определения степени готовности вашей организации к использованию Chaos Engineering вам требуется ответить на 1 вопрос:"Достаточно ли устойчива ваша система к событиям реального мира, например, отказам сервисов или пикам сетевых задержек (network latency)".
Если ответ "нет", то до вы знаете что вам стоит сделать до того, как изучать данную книгу:) Думаю, что большая часть читающих книгу отсеивается на данных пререквизитах:)
Но представим, что мы ответил "Да" - в этом случае вы попадаете в прекрасный мир chaos engineering, который помогает контролировать сложность систем и спать спокойно:)
Если тема вас заинтересовала, то предлагаю вам самим ознакомиться с этой книгой:)
#Chaos #Engineering #SystemEngineering #SystemDesign #SoftwareArchitecture #Software #SoftwareDevelopment
👍6🤔3🔥1
Agile Patterns
В свое время читал перечень этих паттернов в карточке с DZone, плюс есть сайт agilepatterns.org
Если кратко, в первой половине статьи с DZone автор выделяет шаблоны, которые помогают организовывать разработку по agile. Про них все всегда рассказывают и поэтому я не буду их здесь перечислять. А вот на последних страницах автор рассказывает об антипаттернах, которые могут пох...рить всю нашу работу по выстраиванию процессов:)
Среди таких антипаттернов присутствуют
- Cherry Picking - выбор членами команды самых "вкусных" задач из беклога вместо самых приоритетных
- Death March - продолжение проекта, который уже не нужен, но на который потратили много сил и его жалко закрыть
- Disguised Project - проект, который заказчик пытается пропихнуть как рутинные задачи
- Micromanagement - ну тут все ясно:)
- Unbounded Timebox - неопределенные границы для завершения проекта
- Undefined Done - ху..к-х..к и в продакшен:) и куча техдолга на выходе
- Unlimited WIP - неограниченный объем задач в работе
- Unresolved Proxy - много заказчиков без одного ответственного за продукт
- Waterscrumfall - гибрид из waterfall и scrum, признан нежизнеспособным в открытой природе:)
В общем, хорошая статья и читается легко:)
#Management #Processes #Scrum #Kanban #Agile
В свое время читал перечень этих паттернов в карточке с DZone, плюс есть сайт agilepatterns.org
Если кратко, в первой половине статьи с DZone автор выделяет шаблоны, которые помогают организовывать разработку по agile. Про них все всегда рассказывают и поэтому я не буду их здесь перечислять. А вот на последних страницах автор рассказывает об антипаттернах, которые могут пох...рить всю нашу работу по выстраиванию процессов:)
Среди таких антипаттернов присутствуют
- Cherry Picking - выбор членами команды самых "вкусных" задач из беклога вместо самых приоритетных
- Death March - продолжение проекта, который уже не нужен, но на который потратили много сил и его жалко закрыть
- Disguised Project - проект, который заказчик пытается пропихнуть как рутинные задачи
- Micromanagement - ну тут все ясно:)
- Unbounded Timebox - неопределенные границы для завершения проекта
- Undefined Done - ху..к-х..к и в продакшен:) и куча техдолга на выходе
- Unlimited WIP - неограниченный объем задач в работе
- Unresolved Proxy - много заказчиков без одного ответственного за продукт
- Waterscrumfall - гибрид из waterfall и scrum, признан нежизнеспособным в открытой природе:)
В общем, хорошая статья и читается легко:)
#Management #Processes #Scrum #Kanban #Agile
👍17
От основ к созданию роботов
Лет 5 назад я купил эту книгу для обучения сына премудростям создания роботов. Я ее конечно прочитал, но воплотить план обучения в жизнь не получилось, но это не проблема книги, которая отлично написана и оформлена иллюстрациями. Её приятно даже просто пролистать.Если переходить к сути книги, то авторам удалось весело и с простыми практическими занятиями раскрыть заявленную в названии тему:)
В первых главах были описаны разнообразные роботы и дана качественная характеристика, отличающая робота от радиоуправляемой игрушки:)
Дальше авторы рассказали о:
- программировании алгоритма работы робота
- булевой логике
- датчиках как органах чувств роботов
- беспроводной связи
- adruino и управления моторами при помощи ШМИ
В общем, книга действительно интересная и подходит для практических занятий робототехникой с сыном:)
#Robotics #ForKids #SoftwareDevelopment #Engineering
Лет 5 назад я купил эту книгу для обучения сына премудростям создания роботов. Я ее конечно прочитал, но воплотить план обучения в жизнь не получилось, но это не проблема книги, которая отлично написана и оформлена иллюстрациями. Её приятно даже просто пролистать.Если переходить к сути книги, то авторам удалось весело и с простыми практическими занятиями раскрыть заявленную в названии тему:)
В первых главах были описаны разнообразные роботы и дана качественная характеристика, отличающая робота от радиоуправляемой игрушки:)
Дальше авторы рассказали о:
- программировании алгоритма работы робота
- булевой логике
- датчиках как органах чувств роботов
- беспроводной связи
- adruino и управления моторами при помощи ШМИ
В общем, книга действительно интересная и подходит для практических занятий робототехникой с сыном:)
#Robotics #ForKids #SoftwareDevelopment #Engineering
👍11❤2