Заметка на полях. Models and Methods of Software Configuration Management
В поисках того, что вообще есть на тему, решил начать с поиска статей. В качестве отправной точки попалась [статья]. Что лично меня подкупило:
✅ В качестве ключевого слова указан Model-driven approach
✅ Множество родных DevOps-у слов во введении.
Обсуждаемая проблема:
Как быстро и наименее болезненно получить достаточно формальный процесс выпуска версии продукта.
Что вынес полезного:
Корни сложностей при работе с управлением конфигурациями:
1. Мало кто знает, что такое "управление конфигурациями" кроме глубоко погружённых в сложные проекты.
2. Существующие инструменты как раз для сложных проекта, и внедрять их сходу - жесть.
3. В связи с быстротой изменения процессов и прочего один раз разработанные инструменты и сценарии нуждаются в постоянном сопровождении [1].
4. Инструменты позволяющие что-то моделировать слабо поддерживают процессы управления конфигурацией и слишком сложны или не применимы в общем случае [2].
Помимо этого можно отметить следующее:
1. Понятно, что управление конфигурацией, похоже, будет вотчиной девопсов. Или уже стало, но мы пока не заметили.
2. Можно говорить, что подходов к снаряду сделано достаточно много, и есть куда копать, прежде чем пытаться сходу решать проблемы.
3. Видно, что могут пригодиться знания CMMI и ITIL.
4. Придётся заниматься интеграцией множества тулов, а следовательно и моделей в них лежащих.
По содержательной части статьи:
К сожалению, статья оказалась не очень ценной, поскольку:
1. Авторы называют статью как обзорную, но не дают де-факто обзора технологий. А в качестве примеров ссылаются на собственные предыдущие работы.
2. Авторы попытались смоделировать техническое решение, без разбора "А где там собственно сложность, которую приходится решать" и "Как в общем виде выглядит процесс управления конфигурацией".
Вывод:
Нужно копать дальше, и походу придётся проблематику доставать из своей головы.
#идейное #управлениеконфигурацией #рабочее
В поисках того, что вообще есть на тему, решил начать с поиска статей. В качестве отправной точки попалась [статья]. Что лично меня подкупило:
✅ В качестве ключевого слова указан Model-driven approach
✅ Множество родных DevOps-у слов во введении.
Обсуждаемая проблема:
Как быстро и наименее болезненно получить достаточно формальный процесс выпуска версии продукта.
Что вынес полезного:
Корни сложностей при работе с управлением конфигурациями:
1. Мало кто знает, что такое "управление конфигурациями" кроме глубоко погружённых в сложные проекты.
2. Существующие инструменты как раз для сложных проекта, и внедрять их сходу - жесть.
3. В связи с быстротой изменения процессов и прочего один раз разработанные инструменты и сценарии нуждаются в постоянном сопровождении [1].
4. Инструменты позволяющие что-то моделировать слабо поддерживают процессы управления конфигурацией и слишком сложны или не применимы в общем случае [2].
Помимо этого можно отметить следующее:
1. Понятно, что управление конфигурацией, похоже, будет вотчиной девопсов. Или уже стало, но мы пока не заметили.
2. Можно говорить, что подходов к снаряду сделано достаточно много, и есть куда копать, прежде чем пытаться сходу решать проблемы.
3. Видно, что могут пригодиться знания CMMI и ITIL.
4. Придётся заниматься интеграцией множества тулов, а следовательно и моделей в них лежащих.
По содержательной части статьи:
К сожалению, статья оказалась не очень ценной, поскольку:
1. Авторы называют статью как обзорную, но не дают де-факто обзора технологий. А в качестве примеров ссылаются на собственные предыдущие работы.
2. Авторы попытались смоделировать техническое решение, без разбора "А где там собственно сложность, которую приходится решать" и "Как в общем виде выглядит процесс управления конфигурацией".
Вывод:
Нужно копать дальше, и походу придётся проблематику доставать из своей головы.
#идейное #управлениеконфигурацией #рабочее
ResearchGate
(PDF) Models and Methods of Software Configuration Management
PDF | The paper provides collection of experience of developing models and methods for implementation of software configuration management process.... | Find, read and cite all the research you need on ResearchGate
Заметка на полях. Управление конфигурацией.
Наткнулся на цикл статей пол CM 12-ти летней давности. Интересно бы было ретроспективно рассмотреть.
Ссылки:
•Начало
•Опорные срезы
•Изменения
•Контроль версий
•Метрики и документация
•Средства контроля версий
•Книжки рекомендуемые автором (2010-й год)
Очевидно, что проблема старая, но почему-то я про неё вообще не слышу ничего в публичном поле. Как будто либо не забота архитектора, либо решённая проблема. Но последнее очевидно не так.
#управлениеконфигурацией #рабочее
Наткнулся на цикл статей пол CM 12-ти летней давности. Интересно бы было ретроспективно рассмотреть.
Ссылки:
•Начало
•Опорные срезы
•Изменения
•Контроль версий
•Метрики и документация
•Средства контроля версий
•Книжки рекомендуемые автором (2010-й год)
Очевидно, что проблема старая, но почему-то я про неё вообще не слышу ничего в публичном поле. Как будто либо не забота архитектора, либо решённая проблема. Но последнее очевидно не так.
#управлениеконфигурацией #рабочее
Хабр
Цикл статей по основам Software Configuration Management
Пролог Что такое управление конфигурацией в разработке ПО? Зачем оно нужно? Думаю, немногие способны полностью и внятно ответить на этот вопрос. Большинство обычно вспоминает системы контроля версий,...
Заметка на полях. Восьмая глава "Изучаем DDD". Архитектурные паттерны.
Что порадовало:
✔️Даётся набор конкретных инструментов.
✔️Сказано какова ценность применения паттернов.
✔️Как и обычно указаны границы применимости.
Чего хотелось бы добавить или сделать лучше:
✔️Мне, как человеку напрямую не разрабатывающему ПО главы 5-9 кажутся слабоинтересными. Да, понятны рассуждения, но конкретной практической применимости я пока для себя не вижу.
✔️Как мне кажется в восьмой главе много крутится вокруг CAP-теоремы, но при этом основные выборы между С, А, Р - не указаны. Наверное стоит про это рассказать больше.
✔️Мало уделено внимания аспектам вычислительной сложности (ресурсоёмкости) с другими подходами. Хотя может быть это тема другой книги.
Какие выводы:
✔️Сложно делать конкретные выводы, поскольку это не моя тема.
Что дальше:
✔️Читаем дальше. Копим обратную связь.
#книжное #DDD #ПОП #глава8 #Хононов
Что порадовало:
✔️Даётся набор конкретных инструментов.
✔️Сказано какова ценность применения паттернов.
✔️Как и обычно указаны границы применимости.
Чего хотелось бы добавить или сделать лучше:
✔️Мне, как человеку напрямую не разрабатывающему ПО главы 5-9 кажутся слабоинтересными. Да, понятны рассуждения, но конкретной практической применимости я пока для себя не вижу.
✔️Как мне кажется в восьмой главе много крутится вокруг CAP-теоремы, но при этом основные выборы между С, А, Р - не указаны. Наверное стоит про это рассказать больше.
✔️Мало уделено внимания аспектам вычислительной сложности (ресурсоёмкости) с другими подходами. Хотя может быть это тема другой книги.
Какие выводы:
✔️Сложно делать конкретные выводы, поскольку это не моя тема.
Что дальше:
✔️Читаем дальше. Копим обратную связь.
#книжное #DDD #ПОП #глава8 #Хононов
Заметка на полях. Что есть относительно современного в SCM (Software Configuration Management).
Все материалы, которые нынче мне попадаются по теме УК ПО достаточно старые. Примерно года до 2016 выпуска. Заход через поиск статей и описаний готовых методов решений показал, что найти хорошую статью по интересной теме нынче проблема. Поскольку за последние лет 5-6 достаточно много поменялось в этой теме, решил попробовать зайти с раскопок обзоров имеющихся публикаций. Хотя, поскольку инженерная работа в основном не про академические публикации, самое лучшее, что я надеюсь там найти - это широко обсуждаемые темы, и интересные источники по основаниям этой предметной области. О практически применимых теориях и результатах работы я в настоящий момент не надеюсь найти сильно.
В результате поиска через google scholar не получилось найти ни одного современного обзора литературы по этой теме. Похоже, что тема на данный момент ещё пока не признана областью содержащей какую-то проблематику привлекающую внимание, либо считается, что все задачи уже давно решены. Что достаточно удивительно.
#управлениеконфигурацией #рабочее
Все материалы, которые нынче мне попадаются по теме УК ПО достаточно старые. Примерно года до 2016 выпуска. Заход через поиск статей и описаний готовых методов решений показал, что найти хорошую статью по интересной теме нынче проблема. Поскольку за последние лет 5-6 достаточно много поменялось в этой теме, решил попробовать зайти с раскопок обзоров имеющихся публикаций. Хотя, поскольку инженерная работа в основном не про академические публикации, самое лучшее, что я надеюсь там найти - это широко обсуждаемые темы, и интересные источники по основаниям этой предметной области. О практически применимых теориях и результатах работы я в настоящий момент не надеюсь найти сильно.
В результате поиска через google scholar не получилось найти ни одного современного обзора литературы по этой теме. Похоже, что тема на данный момент ещё пока не признана областью содержащей какую-то проблематику привлекающую внимание, либо считается, что все задачи уже давно решены. Что достаточно удивительно.
#управлениеконфигурацией #рабочее
Forwarded from Книжный куб (Alexander Polomodov)
Programming's Greatest Mistakes • Mark Rendle • GOTO 2023
Превосходный стендап на тему ошибок в разработке софта, от которого я действительно смеялся. Суть в том, что автор - опытный разработчик софта, который всю дорогу рассказывает про факапы, причем начинает со своего, а дальше раскручивает спираль дальше и упоминает многие известные истории. Давайте я кратко опишу факапы, которые обсуждаются
- The med file Unf*cker - факап автора, где он для устранения бага в повреждении сохраненных файлов сделал софт для их исправления (с интересным неймингом)
- Y2K - проблема 2000 года, когда год должен был помещаться в YY, но в 2000 году надо было перейти к YYYY. И дальше весь софт надо было доработать под эти изменения
- The Kennel club "Dog 38" - забавный пример с хранением чисел в римском формате
- Agile в enterprise в виде SAFe, AutoScrum 1.1 от Accenture и The Agile Landscape v3 от Deloitte - по картинкам видно, что Agile в корпорациях тут зашел куда-то не туда:)
- The Pentium FPU - проблема с плавающей точкой в процессорах Intel, эту ситацию прикольно описал Энди Гроув в книге "Выживают только параноики", про которую я уже писал
- Null - история про появление nullable значений и как там поучаствовал Tony Hoare, который это назвал "Null References: The Billion Dollar Mistake"
- Hartford Center - история про то, что спроектированное в CAD не всегда хорошо чувствует себя в реалььности (тут про обрушение здания из-за снега)
- Knight Capital - эпичная история про high frequency trading и как экстренное обновление программного обеспечения с багом и отключенной защитой от дурака обанкротило за несколько часов большой хедж фонд
- Mariner1 - про баг в формуле, которую транслировали в Fortran, что привело к крушению
- Mars Climate Orbiter - про имперскую и метрическую системы (дюймы и футы) и как из-за этого космический аппарат для исследования Марса вместо того, чтобы исследовать его с орбиты, решил примарсится:)
- Ariane 5 - про то, как при миграции софта с Ariane4 на Ariane5 в 16 битное float поле положили 64 битное значение и к чему это привело
- The Big Rewrite - про факап самого автора
- Javanoscript - язык, который собрали за 10 дней, а дальше он стал супер-популярным и настолько же неконсистентным:)
- Лейтенант Станислав Петров - как советский офицер предотвратил 26 сентября 1983 года потенциальную ядерную войну после ложного срабатывания системы предупреждения о ракетном нападении со стороны США.
#Fackup #Humor #Reliability #SRE
Превосходный стендап на тему ошибок в разработке софта, от которого я действительно смеялся. Суть в том, что автор - опытный разработчик софта, который всю дорогу рассказывает про факапы, причем начинает со своего, а дальше раскручивает спираль дальше и упоминает многие известные истории. Давайте я кратко опишу факапы, которые обсуждаются
- The med file Unf*cker - факап автора, где он для устранения бага в повреждении сохраненных файлов сделал софт для их исправления (с интересным неймингом)
- Y2K - проблема 2000 года, когда год должен был помещаться в YY, но в 2000 году надо было перейти к YYYY. И дальше весь софт надо было доработать под эти изменения
- The Kennel club "Dog 38" - забавный пример с хранением чисел в римском формате
- Agile в enterprise в виде SAFe, AutoScrum 1.1 от Accenture и The Agile Landscape v3 от Deloitte - по картинкам видно, что Agile в корпорациях тут зашел куда-то не туда:)
- The Pentium FPU - проблема с плавающей точкой в процессорах Intel, эту ситацию прикольно описал Энди Гроув в книге "Выживают только параноики", про которую я уже писал
- Null - история про появление nullable значений и как там поучаствовал Tony Hoare, который это назвал "Null References: The Billion Dollar Mistake"
- Hartford Center - история про то, что спроектированное в CAD не всегда хорошо чувствует себя в реалььности (тут про обрушение здания из-за снега)
- Knight Capital - эпичная история про high frequency trading и как экстренное обновление программного обеспечения с багом и отключенной защитой от дурака обанкротило за несколько часов большой хедж фонд
- Mariner1 - про баг в формуле, которую транслировали в Fortran, что привело к крушению
- Mars Climate Orbiter - про имперскую и метрическую системы (дюймы и футы) и как из-за этого космический аппарат для исследования Марса вместо того, чтобы исследовать его с орбиты, решил примарсится:)
- Ariane 5 - про то, как при миграции софта с Ariane4 на Ariane5 в 16 битное float поле положили 64 битное значение и к чему это привело
- The Big Rewrite - про факап самого автора
- Javanoscript - язык, который собрали за 10 дней, а дальше он стал супер-популярным и настолько же неконсистентным:)
- Лейтенант Станислав Петров - как советский офицер предотвратил 26 сентября 1983 года потенциальную ядерную войну после ложного срабатывания системы предупреждения о ракетном нападении со стороны США.
#Fackup #Humor #Reliability #SRE
YouTube
Programming's Greatest Mistakes • Mark Rendle • GOTO 2023
This presentation was recorded at GOTO Amsterdam 2023. #GOTOcon #GOTOams
https://gotoams.nl
Mark Rendle - Creator of Visual ReCode with 7 Microsoft MVP Awards & 30+ Years of Experience Building Software @that_rendle
RESOURCES
https://twitter.com/markrendle…
https://gotoams.nl
Mark Rendle - Creator of Visual ReCode with 7 Microsoft MVP Awards & 30+ Years of Experience Building Software @that_rendle
RESOURCES
https://twitter.com/markrendle…
👍1
Forwarded from Russian Association of Software Architects (Sergey Baranov)
Поступил запрос:
Нужен внешний архитектурный наблюдательный совет, – проверять наши решения на корректность, предлагать альтернативы.
В таком подходе есть перспектива, обсудили узким кругом, краткое саммари обсуждения.
Кто желает, может высказать свое мнение, риски, предложения.
Консультативный совет, как площадка для дискуссий и выработки предложений
Организационные задачи
⁃ Прописать функции и компетенции
⁃ Прописать перечень рассматриваемых вопросов
Например: рассмотрение ИТ-стратегии перед утверждением, рассмотрение опер модели ИТ, определение политики управления технологиями
⁃ Прописать структуру подчинения и эскалации
⁃ Описать схему работы
Например: мониторинг принимаемых внутренним органом решений с возможностью эскалации
Риски
⁃ Требование проектирования без работ по проектированию на уровне «скажите нам как надо»
⁃ Не вовлеченные в повседневную работу люди будут восприниматься как противники, как следствие - возможен саботаж
⁃ Интересы совета будут расходится с интересами команды
⁃ Отсутствие полного контекста снижает возможности по обоснованию решений и доверию к ним
⁃ Контекст меняется быстрее погружения в контекст
Условие
⁃ Не должно быть прессинга на внутренних специалистов
Нужен внешний архитектурный наблюдательный совет, – проверять наши решения на корректность, предлагать альтернативы.
В таком подходе есть перспектива, обсудили узким кругом, краткое саммари обсуждения.
Кто желает, может высказать свое мнение, риски, предложения.
Консультативный совет, как площадка для дискуссий и выработки предложений
Организационные задачи
⁃ Прописать функции и компетенции
⁃ Прописать перечень рассматриваемых вопросов
Например: рассмотрение ИТ-стратегии перед утверждением, рассмотрение опер модели ИТ, определение политики управления технологиями
⁃ Прописать структуру подчинения и эскалации
⁃ Описать схему работы
Например: мониторинг принимаемых внутренним органом решений с возможностью эскалации
Риски
⁃ Требование проектирования без работ по проектированию на уровне «скажите нам как надо»
⁃ Не вовлеченные в повседневную работу люди будут восприниматься как противники, как следствие - возможен саботаж
⁃ Интересы совета будут расходится с интересами команды
⁃ Отсутствие полного контекста снижает возможности по обоснованию решений и доверию к ним
⁃ Контекст меняется быстрее погружения в контекст
Условие
⁃ Не должно быть прессинга на внутренних специалистов
Заметка на полях. Моделирование и типы моделей.
Интересная статья на habr-e. Где один из аналитиков рассуждает о типах моделей с которыми приходится сталкиваться и с их особенностями. Главные выводы:
1. Нужно различать когда мы моделируем реальный объект в мире, а когда моделируем представление о реальном объекте. Т.е. можно выделить модели "объектные" и "мнимые". Первое - про штуки, второе - про то, что мы об этих думаем в голове.
2. Моделирование одного и того же объекта, не важно реального или мнимого, можно делать разными способами. Через атрибутирование понятия, через выделения методов относящихся к объекту, через отношения между несколькими объектами. Важно понимать ограничения этих методов моделирования и цели моделирования. Мне кажется, что тут много про методы проектирования
3. Запоминаем как "Отче наш...", что модели предназначены для коммуникации, и важно не то, что мы напишем в модель, а то, что там прочитают. Поэтому писать надо не себе будущему, а "ему" прошлому =)
#идейное #моделирование #boro
Интересная статья на habr-e. Где один из аналитиков рассуждает о типах моделей с которыми приходится сталкиваться и с их особенностями. Главные выводы:
1. Нужно различать когда мы моделируем реальный объект в мире, а когда моделируем представление о реальном объекте. Т.е. можно выделить модели "объектные" и "мнимые". Первое - про штуки, второе - про то, что мы об этих думаем в голове.
2. Моделирование одного и того же объекта, не важно реального или мнимого, можно делать разными способами. Через атрибутирование понятия, через выделения методов относящихся к объекту, через отношения между несколькими объектами. Важно понимать ограничения этих методов моделирования и цели моделирования. Мне кажется, что тут много про методы проектирования
3. Запоминаем как "Отче наш...", что модели предназначены для коммуникации, и важно не то, что мы напишем в модель, а то, что там прочитают. Поэтому писать надо не себе будущему, а "ему" прошлому =)
#идейное #моделирование #boro
Хабр
Типы моделей
Правильно заданный вопрос быстро приводит к правильному ответу. Недавно меня спросили: «Почему стандарты бизнес-анализа сконцентрированы на выявлении требований, но ничего не говорят о превращении...
Заметка на полях. Системотехника в забугорьях.
Откопал курс по основам системной инженерии в MIT. 10 лекций, про то, как в Масачусетсе понимают "Systems engeneering". Да, 2015-й год. Да, не такое свежее. Но вряд ли что-то там радикально меняется в основаниях.
В ближайшее время засяду пересмотреть, и возможно сворую к себе.
Хотелось бы иметь в своём запасе базовый курс по системотехнике, куда можно послать своих товарищей.
На всякий случай там же рядом лежат презентации с этого курса.
#рабочее #системотехника #MIT #учебное
Откопал курс по основам системной инженерии в MIT. 10 лекций, про то, как в Масачусетсе понимают "Systems engeneering". Да, 2015-й год. Да, не такое свежее. Но вряд ли что-то там радикально меняется в основаниях.
В ближайшее время засяду пересмотреть, и возможно сворую к себе.
Хотелось бы иметь в своём запасе базовый курс по системотехнике, куда можно послать своих товарищей.
На всякий случай там же рядом лежат презентации с этого курса.
#рабочее #системотехника #MIT #учебное
MIT OpenCourseWare
Class Videos | Fundamentals of Systems Engineering | Aeronautics and Astronautics | MIT OpenCourseWare
This page provides selected class videos for MIT course 16.842 Fundamentals of Systems Engineering of Fall, 2015.
👍3
Заметки на полях. Системотехника в забугорьях
Я тут задремал, и пропустил обновление SEBoK!
А оказывается он тут обновился 20.11.2023!
В ближайшее время попробую построить diff между версиями 2.8 и 2.9!
Коротко, что нового:
✔️Добавили статью о реверс-инженерке с применением ажаля на примере беспилотной машинки. Мне кажется будет интересно почитать;
✔️ Заменили статью про безопасность в системотехнике на новую;
✔️Заменили статью с обзором руководства по программной инженерии;
✔️Обновили статью о "Системотехнике движимой потерями" про метод наблюдения за атрибутами качества.
✔️ Обновление статьи про "Самовосстановление" систем (System Resilience)
✔️ Набросали новых сценариев применения самого SEBoK для конечных пользователей. Говорят, что будет более дружелюбен к читателям.
✔️ Всякого по мелочи
Я щасливый! Есть, что почитать на досуге и куда закопаться.
#рабочее #системотехника #стандарты #SEBOK
Я тут задремал, и пропустил обновление SEBoK!
А оказывается он тут обновился 20.11.2023!
В ближайшее время попробую построить diff между версиями 2.8 и 2.9!
Коротко, что нового:
✔️Добавили статью о реверс-инженерке с применением ажаля на примере беспилотной машинки. Мне кажется будет интересно почитать;
✔️ Заменили статью про безопасность в системотехнике на новую;
✔️Заменили статью с обзором руководства по программной инженерии;
✔️Обновили статью о "Системотехнике движимой потерями" про метод наблюдения за атрибутами качества.
✔️ Обновление статьи про "Самовосстановление" систем (System Resilience)
✔️ Набросали новых сценариев применения самого SEBoK для конечных пользователей. Говорят, что будет более дружелюбен к читателям.
✔️ Всякого по мелочи
Я щасливый! Есть, что почитать на досуге и куда закопаться.
#рабочее #системотехника #стандарты #SEBOK
👍1
Forwarded from Книжный куб (Alexander Polomodov)
Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services
Я уже рассказывал про знаменитую CAP теорему за авторством Eric Brewer. А сегодня я расскажу про whitepaper 2002 года от Seth Gilbert и Nancy Lynch, в котором гипотеза стала теоремой. Сама гипотеза для доказательства звучит так
Все эти свойства желательны в реальных системах. Но для того, чтобы доказать это утверждение, требуется для начала формализовать все три свойства
1) Начать стоит с consistency, где авторы идут в сторону atomic data objects или линеаризуемой консистентности (linearizable consistency)
Такие гарантии косистентности пользователям проще воспринимать и для такой модели проще проектировать клиентское приложение, которое будет взаимодействовать с такой распределенной системой.
2) Второй характеристикой является availability, где для непрерывной доступности каждый запрос, попавший на несбойную ноду системы должен получить свой ответ. Таким образом любой алгоритм для генерации ответа сервисов должен оканчиваться в конечном счете (eventually terminate). Интересно, что это слабое определение доступности, так как нет верхней границы на время ответа - это позволяет unbounded computation. Но если рассматривать это с позиции устойчивости к разделению, то это может рассматриваться как сильное определение доступности - даже если происходят сбои в сети, каждый запрос должен завершиться.
3) Для моделирования partition-tolerance авторы предлагают считать, что в сети может теряться произвольное количество сообщений, что отправляются от одной ноде к другой. А значит мы можем моделировать любой паттерн потерь
Дальше авторы переходят к доказательствам
1) Начнем сначала с асинхронных систем
Доказывается эта теорема на пальцах методом от противного. Представим, что такой алгоритм существует. Дальше представим систему из двух нод G1 и G2. Дальше считаем, что у нас теряются все сообщения между G1 и G2. Дальше происходит запись в G1 и позже чтение из G2. В итоге, чтение с G2 не сможет вернуть значение, что было записано в G1. В самой статье есть и более формальное доказательство.
2) В реальном мире у нас используются не полностью асинхронные системы, а частично синхронные. В них у нод есть свои часы, которые позволяют замерять время и использовать таймауты. Но даже в более мощном сетапе мы получаем похожий результат
Доказательство тут похоже на предыдущее как две капли воды:)
Оставшаяся часть white paper посвящена Delayed-t consistency в частично синхронных системах, про которую мы тут говорить не будем.
А в следующем посте поговорим про теорему PACELC.
#Software #Architecture #DistributedSystems #SystemDesign
Я уже рассказывал про знаменитую CAP теорему за авторством Eric Brewer. А сегодня я расскажу про whitepaper 2002 года от Seth Gilbert и Nancy Lynch, в котором гипотеза стала теоремой. Сама гипотеза для доказательства звучит так
It is impossible for a web service to provide the following three guarantees: consistency, availability, partition-tolerance
Все эти свойства желательны в реальных системах. Но для того, чтобы доказать это утверждение, требуется для начала формализовать все три свойства
1) Начать стоит с consistency, где авторы идут в сторону atomic data objects или линеаризуемой консистентности (linearizable consistency)
Under this consistency guarantee, there must exist a total order on all operations such that each operation looks as if it were completed at a single instant. This is equivalent to requiring requests of the distributed shared memory to act as if they were executing on a single node, responding to operations one at a time.
Такие гарантии косистентности пользователям проще воспринимать и для такой модели проще проектировать клиентское приложение, которое будет взаимодействовать с такой распределенной системой.
2) Второй характеристикой является availability, где для непрерывной доступности каждый запрос, попавший на несбойную ноду системы должен получить свой ответ. Таким образом любой алгоритм для генерации ответа сервисов должен оканчиваться в конечном счете (eventually terminate). Интересно, что это слабое определение доступности, так как нет верхней границы на время ответа - это позволяет unbounded computation. Но если рассматривать это с позиции устойчивости к разделению, то это может рассматриваться как сильное определение доступности - даже если происходят сбои в сети, каждый запрос должен завершиться.
3) Для моделирования partition-tolerance авторы предлагают считать, что в сети может теряться произвольное количество сообщений, что отправляются от одной ноде к другой. А значит мы можем моделировать любой паттерн потерь
When a network is partitioned, all messages sent from nodes in one component of the partition to nodes in another component are lost. (And any pattern of message loss can be modeled as a temporary partition separating the communicating nodes at the exact instant the message is lost.)
Дальше авторы переходят к доказательствам
1) Начнем сначала с асинхронных систем
Theorem 1 It is impossible in the asynchronous network model to implement a read/write data object that guarantees the following properties:
• Availability
• Atomic consistency
in all fair executions (including those in which messages are lost).
Доказывается эта теорема на пальцах методом от противного. Представим, что такой алгоритм существует. Дальше представим систему из двух нод G1 и G2. Дальше считаем, что у нас теряются все сообщения между G1 и G2. Дальше происходит запись в G1 и позже чтение из G2. В итоге, чтение с G2 не сможет вернуть значение, что было записано в G1. В самой статье есть и более формальное доказательство.
2) В реальном мире у нас используются не полностью асинхронные системы, а частично синхронные. В них у нод есть свои часы, которые позволяют замерять время и использовать таймауты. Но даже в более мощном сетапе мы получаем похожий результат
Theorem 2 It is impossible in the partially synchronous network model to
implement a read/write data object that guarantees the following properties:
• Availability
• Atomic consistency
in all executions (even those in which messages are lost).
Доказательство тут похоже на предыдущее как две капли воды:)
Оставшаяся часть white paper посвящена Delayed-t consistency в частично синхронных системах, про которую мы тут говорить не будем.
А в следующем посте поговорим про теорему PACELC.
#Software #Architecture #DistributedSystems #SystemDesign
Telegram
Книжный куб
CAP Theorem
Знаменитой CAP теореме исполнилось 25 лет, поэтому хотелось что это такое, зачем она и как появилась. Про это есть отличная статья от Eric Brewer, автора теоремы, который написал ее больше 10 лет назад, которую хотелось вспомнить, так как она…
Знаменитой CAP теореме исполнилось 25 лет, поэтому хотелось что это такое, зачем она и как появилась. Про это есть отличная статья от Eric Brewer, автора теоремы, который написал ее больше 10 лет назад, которую хотелось вспомнить, так как она…
Заметки на полях. Инженерное.
Нашёл интересный доклад на ютубе и украл к себе.
Это очень старая тема, но в разработке ПО пока не слишком развитая. Разбор доклада чутка попозже добавлю)
UPD: Благодарю автора доклада за улучшенную версию!)
Нашёл интересный доклад на ютубе и украл к себе.
Это очень старая тема, но в разработке ПО пока не слишком развитая. Разбор доклада чутка попозже добавлю)
UPD: Благодарю автора доклада за улучшенную версию!)
YouTube
Balancing Coupling in Software Design — Vlad Khononov, O'Reilly Author and Trainer // TechSpot
📌 In this session, you will learn what coupling is, and how to use it for designing evolvable and maintainable systems. Let's explore the different models of evaluating coupling — and then, discover a simple function that allows us to assess the expected…
Forwarded from emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc. (Ivan)
За что отвечает архитектура?
1. За выявление наиболее существенных требований и за разрешение противоречивых (конфликтующих или обратно-коррелирующих требований).
2. За устранение напряжения между требованиями и конструкцией (это когда то, что хотим, - не можем, а то, что можем, - не хотим).
3. За выбор способа разрешения неопределенности требований путем выбора соответствующей SDLC-модели разработки. Т.е. за выбор соотношения предиктивного и адаптивного способов разрешения неопределенности.
4. В случае выбора адаптивного способа обработки неопределенности (итеративная SDLC-модель разработки и её производные) - за достижение Quality Attribute Modifiability. Т.е. за максимизацию количества открытых решений, где открытость определяется стоимостью изменения решения. Т.е. за опеспечение постоянства скорости разработки по мере роста размера системы. На практике этот график обычно обретает характер роста близкий к логарифмическому, и задача архитектуры - предотвратить экспоненциальный рост. Достигается это путем минимизации когнитивной нагрузки, т.е. путем управления сложностью, и локализацией изменений. Если этого не сделать, то адаптивный способ разрешения неопределенности утратит экономическую целесообразность, поскольку стоимость реализации будет существенно зависеть от момента принятия решения.
5. В случае выбора многокомандной инкрементальной SDLC-модели разработки и её производных (Scaled Agile) - за обеспечение постоянства скорости разработки по мере увеличения количества команд разработки, т.е. за решение Проблемы Брукса. Достигается это путем минимизации коммуникативной нагрузки на команды разработки за счет выявления правильных границ Bounded Contexts.
Это те функции, для осуществления которых нанимается архитектор.
Теперь подойдем к часто обсуждаемому в профессиональных сообществах вопросу.
Давайте представим пациента, госпитализированного с острым воспалительным процессом, которому доктор назначил лечение в виде курса антибиотиков. Пока еще можно обойтись консервативным лечением, но если его не осуществить вовремя, то потребуется уже хирургическое вмешательство. А если и его не осуществить, то возможен летальный исход. И тут пациент говорит, что у него сегодня важная бизнес-встреча, и нужно бухнуть вискаря, тем самым нейтрализовав антибиотики. Что делает в таком случае доктор? Он выписывает пациента из стационара за нарушение предписанного режима, и тем самым он снимает с себя ответственность за последствия, которые от него не зависят. Потому что иначе это будет называться преступная халатность. Она не может быть оправдана тем, что доктор получил за халатность деньги (т.е. наличием корыстного умысла). Доктор-убийца никому не нужен. Он получает деньги за исполнение возложенных на него функций.
Размытость в понимании своих функций иногда на практике приводит к тому, что архитектор начинает противодействует им, оправдываясь тем, что "кто платит, тот и танцует". Такое, конечно, тоже может быть, только это уже не функции архитектуры. И если человек не осуществляет функций архитектуры, то называть его архитектором уже ошибочно.
1. За выявление наиболее существенных требований и за разрешение противоречивых (конфликтующих или обратно-коррелирующих требований).
2. За устранение напряжения между требованиями и конструкцией (это когда то, что хотим, - не можем, а то, что можем, - не хотим).
3. За выбор способа разрешения неопределенности требований путем выбора соответствующей SDLC-модели разработки. Т.е. за выбор соотношения предиктивного и адаптивного способов разрешения неопределенности.
4. В случае выбора адаптивного способа обработки неопределенности (итеративная SDLC-модель разработки и её производные) - за достижение Quality Attribute Modifiability. Т.е. за максимизацию количества открытых решений, где открытость определяется стоимостью изменения решения. Т.е. за опеспечение постоянства скорости разработки по мере роста размера системы. На практике этот график обычно обретает характер роста близкий к логарифмическому, и задача архитектуры - предотвратить экспоненциальный рост. Достигается это путем минимизации когнитивной нагрузки, т.е. путем управления сложностью, и локализацией изменений. Если этого не сделать, то адаптивный способ разрешения неопределенности утратит экономическую целесообразность, поскольку стоимость реализации будет существенно зависеть от момента принятия решения.
5. В случае выбора многокомандной инкрементальной SDLC-модели разработки и её производных (Scaled Agile) - за обеспечение постоянства скорости разработки по мере увеличения количества команд разработки, т.е. за решение Проблемы Брукса. Достигается это путем минимизации коммуникативной нагрузки на команды разработки за счет выявления правильных границ Bounded Contexts.
Это те функции, для осуществления которых нанимается архитектор.
Теперь подойдем к часто обсуждаемому в профессиональных сообществах вопросу.
Давайте представим пациента, госпитализированного с острым воспалительным процессом, которому доктор назначил лечение в виде курса антибиотиков. Пока еще можно обойтись консервативным лечением, но если его не осуществить вовремя, то потребуется уже хирургическое вмешательство. А если и его не осуществить, то возможен летальный исход. И тут пациент говорит, что у него сегодня важная бизнес-встреча, и нужно бухнуть вискаря, тем самым нейтрализовав антибиотики. Что делает в таком случае доктор? Он выписывает пациента из стационара за нарушение предписанного режима, и тем самым он снимает с себя ответственность за последствия, которые от него не зависят. Потому что иначе это будет называться преступная халатность. Она не может быть оправдана тем, что доктор получил за халатность деньги (т.е. наличием корыстного умысла). Доктор-убийца никому не нужен. Он получает деньги за исполнение возложенных на него функций.
Размытость в понимании своих функций иногда на практике приводит к тому, что архитектор начинает противодействует им, оправдываясь тем, что "кто платит, тот и танцует". Такое, конечно, тоже может быть, только это уже не функции архитектуры. И если человек не осуществляет функций архитектуры, то называть его архитектором уже ошибочно.
👍2
Forwarded from Архитектура ИТ-решений
Нашел чек-лист для проверки опровержения CAP теоремы. Если вы считаете, что сумели придумать решение, сочетающее в себе доступность, согласованность и устойчивость к разделению (consistency-availability-partition tolerance), то загляните сюда https://ferd.ca/beating-the-cap-theorem-checklist.html
👍2❤1
Forwarded from Книжный куб (Alexander Polomodov)
AI для разработки - базовый навык для 2024 - Владислава Куклева - Agile Days 2024 (Рубрика #AI)
Интересный доклад Владислава Куклева, CEO агенства Agentcy, про AI тулинг. Понятно по названию его компании, что финальным аккордом является история про мультиагнетные системы, но до это Владислаав успевает пробежаться по вопросам
- Архитектуры языковых моделей (рассказ про LLM на уровне сложности для обывателей)
- Проблемы LLM (галлюцинации и угадывание), но OpenAI дотюнила модели обучая на размеченных диалогах с пользователем + появился промпт инжиниринг, про который рассказывает автор. Правда, он не упоминает, что по новейшим исследованиям промты для LLM сами LLM пишут лучше, чем люди:)
- Создание при помощи LLMs дизайна, слайдов, диаграмм (mermaid.js)
- Помощники для написания кода: GitHub Copilot, Cursor, Phind
- Цепочки запросов и AI-агенты - как это устроено и почему сейчас это очень перспективное направление
- Мультиагентские системы и как отдельные агенты могут объединятся в команду - подробнее в whitepaper "ChatDev: Communicative Agents for Software Development"
#AI #ML #Software #Processes #Management
Интересный доклад Владислава Куклева, CEO агенства Agentcy, про AI тулинг. Понятно по названию его компании, что финальным аккордом является история про мультиагнетные системы, но до это Владислаав успевает пробежаться по вопросам
- Архитектуры языковых моделей (рассказ про LLM на уровне сложности для обывателей)
- Проблемы LLM (галлюцинации и угадывание), но OpenAI дотюнила модели обучая на размеченных диалогах с пользователем + появился промпт инжиниринг, про который рассказывает автор. Правда, он не упоминает, что по новейшим исследованиям промты для LLM сами LLM пишут лучше, чем люди:)
- Создание при помощи LLMs дизайна, слайдов, диаграмм (mermaid.js)
- Помощники для написания кода: GitHub Copilot, Cursor, Phind
- Цепочки запросов и AI-агенты - как это устроено и почему сейчас это очень перспективное направление
- Мультиагентские системы и как отдельные агенты могут объединятся в команду - подробнее в whitepaper "ChatDev: Communicative Agents for Software Development"
#AI #ML #Software #Processes #Management
YouTube
AI для разработки — базовый навык для 2024. Доклад Владислава Куклева
«С начала 2023 года я использую ChatGPT для разработки продуктов. За это время я набрал коллекцию промтов и инструментов, которые ускоряют каждый этап разработки. На этом докладе я поделюсь своими наработками, которые каждый сможет вынести и начать применять…
👍3
Forwarded from Grisha Skobelev
Сделал анонс в телеграмм, твиттере и линкедин, буду благодарен тебе если поделишься анонсом с коллегами и друзьями в своих соц сетях.
Telegram
{ между скобок } анонсы 📣
28 июля 12:00 по мск “Learning Domain-Driven Design Часть I. Cтратегическое проектирование / Геннадий Круглов”
Встретимся обсудить первую часть книги Learning Domain-Driven Design от Влада Хононова. Рассмотрим ключевые аспекты анализа бизнес-стратегий и…
Встретимся обсудить первую часть книги Learning Domain-Driven Design от Влада Хононова. Рассмотрим ключевые аспекты анализа бизнес-стратегий и…
❤2
Заметки на полях. Прочитал тут оригинал "MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS" Dr. Winston W. Rovce. E WESCON, August 1970, page 8-9. Institute of Electrical and Electronics Et)gineers,,
.328 Inc. Originally published by TRW.
Поводом стал очередной холивар в сообществе одном из крупнейших сообществ айтишников РФ про "ажайл-версус-вадапад". Собственно это одна из основополагающих статей про "программную инженерию". Первое ,что бросилось в глаза - количество ссылок на источники представлений о прекрасном. Их ровно 0. Т.е. товарищ описывает "ВАДАПАД" не ссылаясь вообще ни на что. Типа "Ну вот всё сложное софтовое создаётся так. Я сказал". Хотя надо заметить, что прослеживается отсылка на Гуда, Маккола "System's Engeneering". Она же "Системотехника" (перевод под редакцией Тарасенко, Перегудова).
И дальше товарищ начинает рассуждение о том, что неплохо бы (ОБОЖАЖМОЙ) проверять, что именно на каждом "ЭТАЖЕ". Более того, он утверждает, что единственное место, где производится тестирование - это самый конец разработки, перед вводом в эксплуатацию. Опять же, исходя из того, что он обсуждает свой собственно придуманный концепт.
А весь смысл статьи в том, что "Давайте проверять, что то, что мы делаем в софте - оно хорошее, и достаточно зрелое".
Т.е. он сразу говорит, что работать без обратных связей и проверки качества постановки задачи - дело гиблое.
Но камон! Кто сказал, что так вообще кто-то когда-то делал в сложных системах? Перед тем, как что-то сделать сложное всегда проходила куча экспертиз. Плюс в 1970-м году вообще машинное время - это ппц дорогой ресурс, там одна ЭВМ - это холодильник.
В общем у меня такое ощущение, что мы до сих пор говоря про "ВАДАПАД ПРОТИВ АЖАЙЛА" обсуждаем фантазию деда 50-ти летней давности, про которую он сам сказал, что: - "Нинада так делать".
Жесть)
.328 Inc. Originally published by TRW.
Поводом стал очередной холивар в сообществе одном из крупнейших сообществ айтишников РФ про "ажайл-версус-вадапад". Собственно это одна из основополагающих статей про "программную инженерию". Первое ,что бросилось в глаза - количество ссылок на источники представлений о прекрасном. Их ровно 0. Т.е. товарищ описывает "ВАДАПАД" не ссылаясь вообще ни на что. Типа "Ну вот всё сложное софтовое создаётся так. Я сказал". Хотя надо заметить, что прослеживается отсылка на Гуда, Маккола "System's Engeneering". Она же "Системотехника" (перевод под редакцией Тарасенко, Перегудова).
И дальше товарищ начинает рассуждение о том, что неплохо бы (ОБОЖАЖМОЙ) проверять, что именно на каждом "ЭТАЖЕ". Более того, он утверждает, что единственное место, где производится тестирование - это самый конец разработки, перед вводом в эксплуатацию. Опять же, исходя из того, что он обсуждает свой собственно придуманный концепт.
А весь смысл статьи в том, что "Давайте проверять, что то, что мы делаем в софте - оно хорошее, и достаточно зрелое".
Т.е. он сразу говорит, что работать без обратных связей и проверки качества постановки задачи - дело гиблое.
Но камон! Кто сказал, что так вообще кто-то когда-то делал в сложных системах? Перед тем, как что-то сделать сложное всегда проходила куча экспертиз. Плюс в 1970-м году вообще машинное время - это ппц дорогой ресурс, там одна ЭВМ - это холодильник.
В общем у меня такое ощущение, что мы до сих пор говоря про "ВАДАПАД ПРОТИВ АЖАЙЛА" обсуждаем фантазию деда 50-ти летней давности, про которую он сам сказал, что: - "Нинада так делать".
Жесть)
👍1
Вот годный вброс на тему, кто такой системный аналитик, и чем он занимается. Весьма хорошая отправная точка, чтобы посмотреть, и ответить на вопрос:
- А зачем Системный Аналитик нужен в проекте именно нам?
- А зачем Системный Аналитик нужен в проекте именно нам?
Telegram
Денис Бесков, Systems.Education in Comments 4 Денис Бесков
спросил пока у ясеня, в целом почти так:
Конечно, вот перечень задач для каждой из подролей системного аналитика:
а) Инженер по требованиям:
1. Сбор и документирование требований пользователей и стейкхолдеров.
2. Анализ и проверка требований на полноту…
Конечно, вот перечень задач для каждой из подролей системного аналитика:
а) Инженер по требованиям:
1. Сбор и документирование требований пользователей и стейкхолдеров.
2. Анализ и проверка требований на полноту…
👎3👍1
Заметка на полях. Статья подъехала. Ребята нашли достаточно сильное статистическое подтверждение тому, что неоднородность вселенной и наблюдаемое расширение - следствие гравитационного взаимодействия и не требует введения "тёмной энергии". И вообще, расширение вселенной может быть иллюзией наблюдателя) В самой статье они заявили достаточно громко, что требуется некоторый пересмотр стандартной Фридмановской модели. Так что, покупаем попкорн и ждём шуток про физиков в тёмной комнате, которой нет.
Для меня примечателен оказался и метод исследования в т.ч. Обрабатывались исходные данные Байесовскими статистическими методами. Генеративная АИшечка в таких вопросах, кстати, должна давать достаточно серьёзные преимущества в построении предсказаний на моделях с достаточно большим количеством весов. Если кто-то думает в эту сторону (обработка данных наблюдений всякими корелляционными методами и построение предсказаний LLMами) попрошу ещё прокомментировать это предположение. Что там есть перспективного нынче.
Для меня примечателен оказался и метод исследования в т.ч. Обрабатывались исходные данные Байесовскими статистическими методами. Генеративная АИшечка в таких вопросах, кстати, должна давать достаточно серьёзные преимущества в построении предсказаний на моделях с достаточно большим количеством весов. Если кто-то думает в эту сторону (обработка данных наблюдений всякими корелляционными методами и построение предсказаний LLMами) попрошу ещё прокомментировать это предположение. Что там есть перспективного нынче.
Заметки на полях, как фиксация некоторых размышлений на тему.
В профильных чатах разработчиков всяких ИТшненьких систем пронеслись несколько мыслей, которые стоит для себя зафиксировать:
1. Современная разработка скорее строится на народных приметах вида: "Скрам-мастер без татух - к беде"
2. В итоговом ИТ-продукте будут реализованы только те качества, за каждый из которых есть выгодополучатель.
Если ещё плюсом немного подытожить наблюдения, то можно построить типовую модель качества ИТ-системы примерно так:
- Функциональное качество (а-ля UX)
- Инфраструктурная доступность сервиса
- Стоимость вывода в пром.применение "следующей версии"
Что интересно, есть ещё один значимый, но конфликтогенный параметр - это Стоимость подержки (оно же управление инцидентами, исправление ошибок эксплуатации и т.п.). Конфликтогенный он потому, что за разработку и поддержку отвечают разные организационные единицы, чаще всего, и разработанный исходный код передаётся "как есть" тем, кто его будет дальше эксплуатировать, и "забор" проходит по приёмке "отелом девопсов".
Это хорошо кореллирует с ситуацией ещё и тем, что мы в целом чаще конформны к сложившейся среде. т.е. толерантны к негативным событиям, если они происходят в сложившемся окружении. В ИТ-шечке это можно выразить следующим образом:
- Если пользователь начал пользоваться продуктом, то он гарантированно будет ждать следующей версии, не смотря на все проблемы, которые ему это будет нести с большей вероятностью, чем искать новое решение.
Т.е. если пользователей продукта в моменте достаточно для его поддержания, то качество продукта - ПРИЕМЛЕМО. И для владельца актива по производству продукта важно защитить основных поставщиков качества. А в нашем случае это: Кодописатели, админы инфраструктуры, менеджеры с палками, которые штрафуют ФОТ.
Лично меня эта картинка подвигает на то, чтобы снижать порог толерантности, выражающийся в безусловном принятии как допустимого, и последующем бездействии к тому, что меня не устраивает в используемых мною продуктах.
В профильных чатах разработчиков всяких ИТшненьких систем пронеслись несколько мыслей, которые стоит для себя зафиксировать:
1. Современная разработка скорее строится на народных приметах вида: "Скрам-мастер без татух - к беде"
2. В итоговом ИТ-продукте будут реализованы только те качества, за каждый из которых есть выгодополучатель.
Если ещё плюсом немного подытожить наблюдения, то можно построить типовую модель качества ИТ-системы примерно так:
- Функциональное качество (а-ля UX)
- Инфраструктурная доступность сервиса
- Стоимость вывода в пром.применение "следующей версии"
Что интересно, есть ещё один значимый, но конфликтогенный параметр - это Стоимость подержки (оно же управление инцидентами, исправление ошибок эксплуатации и т.п.). Конфликтогенный он потому, что за разработку и поддержку отвечают разные организационные единицы, чаще всего, и разработанный исходный код передаётся "как есть" тем, кто его будет дальше эксплуатировать, и "забор" проходит по приёмке "отелом девопсов".
Это хорошо кореллирует с ситуацией ещё и тем, что мы в целом чаще конформны к сложившейся среде. т.е. толерантны к негативным событиям, если они происходят в сложившемся окружении. В ИТ-шечке это можно выразить следующим образом:
- Если пользователь начал пользоваться продуктом, то он гарантированно будет ждать следующей версии, не смотря на все проблемы, которые ему это будет нести с большей вероятностью, чем искать новое решение.
Т.е. если пользователей продукта в моменте достаточно для его поддержания, то качество продукта - ПРИЕМЛЕМО. И для владельца актива по производству продукта важно защитить основных поставщиков качества. А в нашем случае это: Кодописатели, админы инфраструктуры, менеджеры с палками, которые штрафуют ФОТ.
Лично меня эта картинка подвигает на то, чтобы снижать порог толерантности, выражающийся в безусловном принятии как допустимого, и последующем бездействии к тому, что меня не устраивает в используемых мною продуктах.
👍2