emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Еще одна статья от Gregor Hohpe (автора EIP) на тему Agile. "Agile Is the Steering Wheel, Not the Gas Pedal" https://architectelevator.com/transformation/agile-steering/ #Agile #SoftwareArchitecture
Опубликована третья статья мини-серии статьей про Agile and Architecture by Gregor Hohpe (автор EIP)
"Conversation stopper: IT Should Become Agile"
https://architectelevator.com/transformation/agile-conversation-stopper/
#Agile #SoftwareArchitecture
"Conversation stopper: IT Should Become Agile"
https://architectelevator.com/transformation/agile-conversation-stopper/
#Agile #SoftwareArchitecture
The Architect Elevator
Conversation stopper: IT Should Become Agile
Finding business value without the business is going to be difficult.
Неплохую статью упомянул Максим Смирнов:
"The Scale Cube" by Marty Abbott
https://akfpartners.com/growth-blog/scale-cube
#Database #HighLoad #Scaling
"The Scale Cube" by Marty Abbott
https://akfpartners.com/growth-blog/scale-cube
#Database #HighLoad #Scaling
AKF Partners
The Scale Cube
How to use the Scale Cube to solve scalability challenges from the inventors of the Scale Cube, AKF Partners.
На вчерашней архитекторской тусовке ( @it_architect_party ) прозвучал вопрос: "что говорить разработчикам, злоупотребляющим микрооптимизациями"? И я вспомнил про подборку высказываний о premature optimization:
📝 "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason — including blind stupidity."
— W. A. Wulf
📝 "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
— Donald Knuth
📝 "Jackson's Rules of Optimization: Rule 1. Don't do it. Rule 2 (for experts only). Don't do it yet — that is, not until you have a perfectly clear and unoptimized solution."
— M. A. Jackson
📝 "No programmer has ever been able to predict or analyze where performance bottlenecks are without data. No matter where you think it's going, you will be surprised to discover that it is going somewhere else."
— Joseph M. Newcomer
📝 "If you make an optimization and don't measure to confirm the performance increase, all you know for certain is that you've made your code harder to read."
— Martin Fowler, "Yet Another Optimization Article" https://martinfowler.com/ieeeSoftware/yetOptimization.pdf
📝 "The interesting thing about performance is that if you analyze most programs, you find that they waste most of their time in a small fraction of the code. If you optimize all the code equally, you end up with 90 percent of the optimizations wasted, because you are optimizing code that isn't run much. The time spent making the program fast, the time lost because of lack of clarity, is all wasted time."
— "Refactoring: Improving the Design of Existing Code" 1st edition by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
📝 "The Pareto Principle, also known as the 80/20 rule, states that you can get 80 percent of the result with 20 percent of the effort. The principle applies to a lot of areas other than programming, but it definitely applies to program optimization. Barry Boehm reports that 20 percent of a program's routines consume 80 percent of its execution time (1987b). In his classic paper "An Empirical Study of Fortran Programs," Donald Knuth found that less than four percent of a program usually accounts formore than 50 percent of its run time (1971). Knuth used a line-count profiler to discover this surprising relationship, and the implications for optimization are clear. You should measure the code to find the hot spots and then put your resources into optimizing the few percent that are used the most. Knuth profiled his line-count program and found that it was spending half its execution time in two loops. He changed a few lines of code and doubled the speed of the profiler in less than an hour. Jon Bentley describes a case in which a 1000-line program spent 80 percent of its time in a five-line square-root routine. By tripling the speed of the square-root routine, he doubled the speed of the program (1988). The Pareto Principle is also the source of theadvice to write most of the code in an interpreted language like Python and then rewrite the hot spots in a faster compiled language like C.Bentley also reports the case of a team that discovered half an operating system's timebeing spent in a small loop. They rewrote the loop in microcode and made the loop 10 times faster, but it didn't change the system's performance — they had rewritten the system's idle loop! The team who designed the ALGOL language — the granddaddy of most modern languages and one of the most influential languages ever — received the following advice: "The best is the enemy of the good." Working toward perfection might prevent completion. Complete it first, and then perfect it. The part that needs to be perfect isusually small."
— "Code Complete" by Stive McConnell
#SoftwareDesign #SoftwareArchitecture #Career
📝 "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason — including blind stupidity."
— W. A. Wulf
📝 "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
— Donald Knuth
📝 "Jackson's Rules of Optimization: Rule 1. Don't do it. Rule 2 (for experts only). Don't do it yet — that is, not until you have a perfectly clear and unoptimized solution."
— M. A. Jackson
📝 "No programmer has ever been able to predict or analyze where performance bottlenecks are without data. No matter where you think it's going, you will be surprised to discover that it is going somewhere else."
— Joseph M. Newcomer
📝 "If you make an optimization and don't measure to confirm the performance increase, all you know for certain is that you've made your code harder to read."
— Martin Fowler, "Yet Another Optimization Article" https://martinfowler.com/ieeeSoftware/yetOptimization.pdf
📝 "The interesting thing about performance is that if you analyze most programs, you find that they waste most of their time in a small fraction of the code. If you optimize all the code equally, you end up with 90 percent of the optimizations wasted, because you are optimizing code that isn't run much. The time spent making the program fast, the time lost because of lack of clarity, is all wasted time."
— "Refactoring: Improving the Design of Existing Code" 1st edition by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
📝 "The Pareto Principle, also known as the 80/20 rule, states that you can get 80 percent of the result with 20 percent of the effort. The principle applies to a lot of areas other than programming, but it definitely applies to program optimization. Barry Boehm reports that 20 percent of a program's routines consume 80 percent of its execution time (1987b). In his classic paper "An Empirical Study of Fortran Programs," Donald Knuth found that less than four percent of a program usually accounts formore than 50 percent of its run time (1971). Knuth used a line-count profiler to discover this surprising relationship, and the implications for optimization are clear. You should measure the code to find the hot spots and then put your resources into optimizing the few percent that are used the most. Knuth profiled his line-count program and found that it was spending half its execution time in two loops. He changed a few lines of code and doubled the speed of the profiler in less than an hour. Jon Bentley describes a case in which a 1000-line program spent 80 percent of its time in a five-line square-root routine. By tripling the speed of the square-root routine, he doubled the speed of the program (1988). The Pareto Principle is also the source of theadvice to write most of the code in an interpreted language like Python and then rewrite the hot spots in a faster compiled language like C.Bentley also reports the case of a team that discovered half an operating system's timebeing spent in a small loop. They rewrote the loop in microcode and made the loop 10 times faster, but it didn't change the system's performance — they had rewritten the system's idle loop! The team who designed the ALGOL language — the granddaddy of most modern languages and one of the most influential languages ever — received the following advice: "The best is the enemy of the good." Working toward perfection might prevent completion. Complete it first, and then perfect it. The part that needs to be perfect isusually small."
— "Code Complete" by Stive McConnell
#SoftwareDesign #SoftwareArchitecture #Career
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Лучший способ не делать работу дважды (и более раз) - это учиться на чужом опыте. Т.е. работать с литературой. Практика подсказывает, что когда разработчик приступает к компромиссному, но знакомому ему решению, в надежде сэкономить время, то, в конечном итоге…
По итогам вчерашней встречи, я лишний раз убедился в том, что проблемы с velocity возникают именно в тех командах, которые не работают с литературой. По этому вопросу не могу не вспомнить свое же высказывание в одном из телеграм-чатов:
"Все просто. Или ты читаешь, или проект гниёт. Чем больше читаешь, тем меньше он гниёт, тем больше velocity команды, тем больше времени на чтение. Вы не представляете, сколько я встречал на практике косяков, которые уже давно были разобраны в литературе. Или ты учишься на своих ошибках, или на чужих. Последний вариант банально выгодней."
#Career
"Все просто. Или ты читаешь, или проект гниёт. Чем больше читаешь, тем меньше он гниёт, тем больше velocity команды, тем больше времени на чтение. Вы не представляете, сколько я встречал на практике косяков, которые уже давно были разобраны в литературе. Или ты учишься на своих ошибках, или на чужих. Последний вариант банально выгодней."
#Career
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
По итогам вчерашней встречи, я лишний раз убедился в том, что проблемы с velocity возникают именно в тех командах, которые не работают с литературой. По этому вопросу не могу не вспомнить свое же высказывание в одном из телеграм-чатов: "Все просто. Или ты…
В чате канала прозвучал очень хороший вопрос, на который лучше ответить здесь: "А как же вариант переусложнения как раз по причине "мы прочитали, надо так ..." ?"
В своей практике я не могу вспомнить такого случая. В нечитающих командах проблем всегда на порядок больше. Любое решение имеет свой контекст применения. Универсального решения не существует. Если решение не соответствует поставленной задачи, значит, читали не то или не о том. Т.е. не обладают теорией. Часто можно наблюдать ошибочное применение решений на основе разнообразных статей не самого высокого качества, в которых утрачен контекст применения (наглядный пример - бесчисленные на сегодня статьи о ТДД, в которых отсутствует даже элементарное понимание этой методики). Тут вопрос заключается просто в качестве источников информации - нужно просто быть избирательным и предпочитать работать с первоисточниками. По этому поводу красиво сказал Bertrand Meyer:
📝 "The zealots of an idea are often more extreme than its creators - the phase “more royalist than the King” captures that phenomenon - and you will find that foundational agile texts, such as those by Beck, Larman or Cockburn, occupy a higher plane of discourse; in particular they avoid below-the-belt hits at other approaches."
- “Agile!: The Good, the Hype and the Ugly” by Bertrand Meyer
К сожалению, многие считают, что, например, для понимания паттернов, достаточно почитать статью в Википедии, или послушать "пересказ книги". Эффект от такого экспресс-обучения будет, скорее, негативным, нежели позитивным.
Вторым, немаловажным моментом, является "Несовпадение фаз спиралей обучения"
- https://dckms.github.io/system-architecture/emacsway/soft-skills/learning-spiral-phase-mismatch.html
#Career
В своей практике я не могу вспомнить такого случая. В нечитающих командах проблем всегда на порядок больше. Любое решение имеет свой контекст применения. Универсального решения не существует. Если решение не соответствует поставленной задачи, значит, читали не то или не о том. Т.е. не обладают теорией. Часто можно наблюдать ошибочное применение решений на основе разнообразных статей не самого высокого качества, в которых утрачен контекст применения (наглядный пример - бесчисленные на сегодня статьи о ТДД, в которых отсутствует даже элементарное понимание этой методики). Тут вопрос заключается просто в качестве источников информации - нужно просто быть избирательным и предпочитать работать с первоисточниками. По этому поводу красиво сказал Bertrand Meyer:
📝 "The zealots of an idea are often more extreme than its creators - the phase “more royalist than the King” captures that phenomenon - and you will find that foundational agile texts, such as those by Beck, Larman or Cockburn, occupy a higher plane of discourse; in particular they avoid below-the-belt hits at other approaches."
- “Agile!: The Good, the Hype and the Ugly” by Bertrand Meyer
К сожалению, многие считают, что, например, для понимания паттернов, достаточно почитать статью в Википедии, или послушать "пересказ книги". Эффект от такого экспресс-обучения будет, скорее, негативным, нежели позитивным.
Вторым, немаловажным моментом, является "Несовпадение фаз спиралей обучения"
- https://dckms.github.io/system-architecture/emacsway/soft-skills/learning-spiral-phase-mismatch.html
#Career
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
По итогам вчерашней встречи, я лишний раз убедился в том, что проблемы с velocity возникают именно в тех командах, которые не работают с литературой. По этому вопросу не могу не вспомнить свое же высказывание в одном из телеграм-чатов: "Все просто. Или ты…
Но нередко на практике можно встретить и третий момент - неприняние отдельными разработчиками подходящего под проблему решения в силу психологических причин - "Эффекта Даннинга-Крюгера", "Психологической Защиты" и "Confirmation Bias":
- https://ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%94%D0%B0%D0%BD%D0%BD%D0%B8%D0%BD%D0%B3%D0%B0_%E2%80%94_%D0%9A%D1%80%D1%8E%D0%B3%D0%B5%D1%80%D0%B0
- https://ru.wikipedia.org/wiki/%D0%A1%D0%BA%D0%BB%D0%BE%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%BA_%D0%BF%D0%BE%D0%B4%D1%82%D0%B2%D0%B5%D1%80%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D1%8E_%D1%81%D0%B2%D0%BE%D0%B5%D0%B9_%D1%82%D0%BE%D1%87%D0%BA%D0%B8_%D0%B7%D1%80%D0%B5%D0%BD%D0%B8%D1%8F
- https://ru.m.wikipedia.org/wiki/%D0%97%D0%B0%D1%89%D0%B8%D1%82%D0%BD%D1%8B%D0%B9_%D0%BC%D0%B5%D1%85%D0%B0%D0%BD%D0%B8%D0%B7%D0%BC
- https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F_%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B0_%D0%B2%D1%8B%D0%B6%D0%B8%D0%B2%D1%88%D0%B5%D0%B3%D0%BE
Лечится это, опять же, ростом персональной компетентности участников команды. На эту тему уже был пост:
https://news.1rj.ru/str/emacsway_log/47
Как бы то ни было, а старина Леонардо да Винчи был прав:
📝 "Всякий, кто полагается на практику, не зная теории, подобен кормчему, вступающему на судно без руля и компаса, – он не знает, куда плывет. Практика всегда должна опираться на твердые теоретические основания."
- Леонардо да Винчи
Другой вопрос о том, что "чтения недостаточно". Да, недостаточно, на эту тему уже упоминалась превосходная статья Сергея Теплякова "О “вреде” книг: напутствие любому программисту":
https://sergeyteplyakov.blogspot.com/2017/02/reading-books-considered-harmful.html?m=1
И третий вопрос, по поводу "переусложнения" программы. Главный императив разработки ПО заключается как раз в управлении сложностью кода. А ценность хорошей архитектуры - в экономике разработки. Если принятые решения не достигают этих целей, значит, опять же, не хватает знаний о задачах архитектуры, и нужно улучшать полноту знаний.
#Career #SoftwareDesign #SoftwareArchitecture
- https://ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%94%D0%B0%D0%BD%D0%BD%D0%B8%D0%BD%D0%B3%D0%B0_%E2%80%94_%D0%9A%D1%80%D1%8E%D0%B3%D0%B5%D1%80%D0%B0
- https://ru.wikipedia.org/wiki/%D0%A1%D0%BA%D0%BB%D0%BE%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%BA_%D0%BF%D0%BE%D0%B4%D1%82%D0%B2%D0%B5%D1%80%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D1%8E_%D1%81%D0%B2%D0%BE%D0%B5%D0%B9_%D1%82%D0%BE%D1%87%D0%BA%D0%B8_%D0%B7%D1%80%D0%B5%D0%BD%D0%B8%D1%8F
- https://ru.m.wikipedia.org/wiki/%D0%97%D0%B0%D1%89%D0%B8%D1%82%D0%BD%D1%8B%D0%B9_%D0%BC%D0%B5%D1%85%D0%B0%D0%BD%D0%B8%D0%B7%D0%BC
- https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F_%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B0_%D0%B2%D1%8B%D0%B6%D0%B8%D0%B2%D1%88%D0%B5%D0%B3%D0%BE
Лечится это, опять же, ростом персональной компетентности участников команды. На эту тему уже был пост:
https://news.1rj.ru/str/emacsway_log/47
Как бы то ни было, а старина Леонардо да Винчи был прав:
📝 "Всякий, кто полагается на практику, не зная теории, подобен кормчему, вступающему на судно без руля и компаса, – он не знает, куда плывет. Практика всегда должна опираться на твердые теоретические основания."
- Леонардо да Винчи
Другой вопрос о том, что "чтения недостаточно". Да, недостаточно, на эту тему уже упоминалась превосходная статья Сергея Теплякова "О “вреде” книг: напутствие любому программисту":
https://sergeyteplyakov.blogspot.com/2017/02/reading-books-considered-harmful.html?m=1
И третий вопрос, по поводу "переусложнения" программы. Главный императив разработки ПО заключается как раз в управлении сложностью кода. А ценность хорошей архитектуры - в экономике разработки. Если принятые решения не достигают этих целей, значит, опять же, не хватает знаний о задачах архитектуры, и нужно улучшать полноту знаний.
#Career #SoftwareDesign #SoftwareArchitecture
Превосходная подборка статей с фундаментальной информацией в доступной форме о внутреннем устройстве PostgreSQL, от разработчиков PostgresPro:
- https://m.habr.com/ru/company/postgrespro/blog/442804/
- https://m.habr.com/ru/company/postgrespro/blog/458186/
- https://m.habr.com/ru/company/postgrespro/blog/459250/
- https://m.habr.com/ru/company/postgrespro/blog/460423/
- https://m.habr.com/ru/company/postgrespro/blog/461523/
Видеозаписи курсов по PostgreSQL: https://postgrespro.ru/education/where
#Database #PostgreSQL
- https://m.habr.com/ru/company/postgrespro/blog/442804/
- https://m.habr.com/ru/company/postgrespro/blog/458186/
- https://m.habr.com/ru/company/postgrespro/blog/459250/
- https://m.habr.com/ru/company/postgrespro/blog/460423/
- https://m.habr.com/ru/company/postgrespro/blog/461523/
Видеозаписи курсов по PostgreSQL: https://postgrespro.ru/education/where
#Database #PostgreSQL
Хабр
MVCC-1. Изоляция
Привет, Хабр! Этой статьей я начинаю серию циклов (или цикл серий? в общем, задумка грандиозная) о внутреннем устройстве PostgreSQL. Материал будет основан на учебных курсах по...
Jimmy Bogard: "ugh another "GraphQL vs REST" post" (см. весь тред):
- https://twitter.com/jbogard/status/1306960118270046210?s=19
Ранее он уже затрагивал эту тему:
- https://twitter.com/jbogard/status/1165968651863937024?s=19
- https://twitter.com/jbogard/status/1021460946315825152?s=19
#DDD #Microservices #SowtwareDesign #SoftwareArchitecture #REST #GraphQL
- https://twitter.com/jbogard/status/1306960118270046210?s=19
Ранее он уже затрагивал эту тему:
- https://twitter.com/jbogard/status/1165968651863937024?s=19
- https://twitter.com/jbogard/status/1021460946315825152?s=19
#DDD #Microservices #SowtwareDesign #SoftwareArchitecture #REST #GraphQL
Twitter
jimmybogard.usd 🇺🇦🍻
ugh another "GraphQL vs REST" post i just cannot anymore your API is bad and you should feel bad
Vaughn Vernon ответил на зарождающуюся тенденцию mAcroservices:
"Microservices and [Micro]services"
https://kalele.io/microservices-and-microservices/
[UPDATED]: Короткий пересказ:
https://twitter.com/VaughnVernon/status/1307531621235523586?s=19
#DDD #Microservices
"Microservices and [Micro]services"
https://kalele.io/microservices-and-microservices/
[UPDATED]: Короткий пересказ:
https://twitter.com/VaughnVernon/status/1307531621235523586?s=19
#DDD #Microservices
Kalele
Microservices and [Micro]services | Kalele
Kalele Vaughn Vernon discusses whether the size of a microservice matters. What do Domain-Driven Design Bounded Contexts have to do with Microservices.
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Vaughn Vernon ответил на зарождающуюся тенденцию mAcroservices: "Microservices and [Micro]services" https://kalele.io/microservices-and-microservices/ [UPDATED]: Короткий пересказ: https://twitter.com/VaughnVernon/status/1307531621235523586?s=19 #DDD #Microservices
Кстати, на тему размера microservice недавно писал Alberto Brandolini:
"About Bounded Contexts and Microservices"
https://blog.avanscoperta.it/2020/06/11/about-bounded-contexts-and-microservices/
Там же он рассматривает и вопрос связи Bounded Context с Microservice. Но лучше всех этот вопрос раскрыл, по моему мнению, Vladik Khononov ( @vladik_kh ):
- "Bounded Contexts are NOT Microservices"
https://vladikk.com/2018/01/21/bounded-contexts-vs-microservices/
- "Tackling Complexity in Microservices"
https://vladikk.com/2018/02/28/microservices/
- "DDDDD: Bounded Contexts, Microservices, and Everything In Between"
https://youtu.be/Z0RgR9xIQE4
#DDD #Microservices
"About Bounded Contexts and Microservices"
https://blog.avanscoperta.it/2020/06/11/about-bounded-contexts-and-microservices/
Там же он рассматривает и вопрос связи Bounded Context с Microservice. Но лучше всех этот вопрос раскрыл, по моему мнению, Vladik Khononov ( @vladik_kh ):
- "Bounded Contexts are NOT Microservices"
https://vladikk.com/2018/01/21/bounded-contexts-vs-microservices/
- "Tackling Complexity in Microservices"
https://vladikk.com/2018/02/28/microservices/
- "DDDDD: Bounded Contexts, Microservices, and Everything In Between"
https://youtu.be/Z0RgR9xIQE4
#DDD #Microservices
Avanscoperta Blog
About Bounded Contexts and Microservices | Avanscoperta Blog
Alberto Brandolini aka ziobrando answers questions such as "what is the right granularity of microservices?" or "are Microservices and Bounded Contexts the same thing?".
Очередной холивар титанов, на этот раз на тему паттернов проектирования:
https://twitter.com/copyconstruct/status/1306661608454721537?s=19
#OOP #SoftwareDesign #SoftwareArchitecture
https://twitter.com/copyconstruct/status/1306661608454721537?s=19
#OOP #SoftwareDesign #SoftwareArchitecture
Twitter
Cindy Sridharan
Design Patterns as evangelized by Boomer programmers are mostly dead though. No tech interview screens for it. When was the last time the “flyweight pattern” came up in a code review? The Gang of Four book isn’t even *readable* ffs. It’s the Atlas Shrugged…
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
На тему оценивания задач. Многие слышали про Story Point, но не многие знают его смысл и назначение, из-за чего он часто применяется неправильно. История создания и смысл Story Point приводятся на сайте Agile Alliance - организации, созданной основателями…
В продолжение темы о Story Point. Возможно, это удивит многих. Вот что говорит человек, который считается одним из его создателей:
Ron Jeffries:
> i was there when story points were invented and they are about time, no more and no less.
https://twitter.com/RonJeffries/status/1295135210976301057?s=20
Ron Jeffries:
> Story points as we originally defined them are in fact numbers. They are estimated days times a secret constant.
https://twitter.com/RonJeffries/status/1199794376949538817?s=20
Ron Jeffries:
> You seemed to be comparing time-in-queue plus time-in-development to story point estimate. Points as originally contemplated only consider time in development. That time starts when the team pulls the story.
https://twitter.com/RonJeffries/status/1192092142639943680?s=20
Ron Jeffries:
> Story points are time to implement once you start implementing, times an arbitrary constant. That's all they are. Much of what you wrote above sounded like cycle time ... and points aren't that.
https://twitter.com/RonJeffries/status/1191867124035158016?s=20
Ron Jeffries:
> OK, experts who think story points aren't about cost, and that cost isn't essentially time, educate me. What are they, what are they good for, why do we estimate them?
In answering, show no concern for the likelihood that I invented them.
If I did, I'm sorry now.
https://twitter.com/RonJeffries/status/1128296444845330433?s=20
Ron Jeffries:
> No. However, the whole point of story points, like all other forms of story cost estimation, is to figure out how long things will take (or, the equivalent, how much work to take on in some interval).
If they can't be added, they are entirely without value.
https://twitter.com/RonJeffries/status/1128290085714186242?s=20
Ron Jeffries:
> i was there when story points were invented, and while i don't like them and regret past support for them, i can tell you that they were built to be proportional to time, and additive.
https://twitter.com/RonJeffries/status/1128070252275884037?s=20
Ron Jeffries:
> neither hours nor points are discernibly better than counting stories. points were invented to disguise our use of “perfect” days, which was confusing to management. XP never used hours to my recollection.
cf. the no estimates idea.
https://twitter.com/RonJeffries/status/1097601165930442753?s=20
Ron Jeffries:
> we estimated stories initially in "ideal time", later in points, tracked number accomplished to adjust how many to pull each iteration. switched to points because ideal time confused people (why did 2 day story take 5 days).
it worked, i think, because we had low politics.
https://twitter.com/RonJeffries/status/1052858860539658240?s=20
Ron Jeffries:
> points are stories/time*constant. how long you work, not how hard you work.
https://twitter.com/RonJeffries/status/979096172273942528?s=20
Ron Jeffries:
> yes. we had estimated work in “perfect days” and since it takes more than one real day to equal one perfect day, our stakeholders were confused. so we just estimated the same way and called them points. today, i don’t recommend estimating stories at all. small stories [could be used instead]. count them.
https://twitter.com/RonJeffries/status/937207650353319936?s=20
Ron Jeffries:
> original story points were Perfect Engineering Days, one’s estimate of how long it would take if the bastards left us alone.
https://twitter.com/RonJeffries/status/834879258753449989?s=20
Ron Jeffries:
> I am not sure I invented story points but if I did I’m sorry now.
https://twitter.com/RonJeffries/status/943790497981706242?s=20
Ron Jeffries:
> I may have invented story points. If I did, I am sorry now.
https://twitter.com/RonJeffries/status/815924184257851392?s=20
#Agile
Ron Jeffries:
> i was there when story points were invented and they are about time, no more and no less.
https://twitter.com/RonJeffries/status/1295135210976301057?s=20
Ron Jeffries:
> Story points as we originally defined them are in fact numbers. They are estimated days times a secret constant.
https://twitter.com/RonJeffries/status/1199794376949538817?s=20
Ron Jeffries:
> You seemed to be comparing time-in-queue plus time-in-development to story point estimate. Points as originally contemplated only consider time in development. That time starts when the team pulls the story.
https://twitter.com/RonJeffries/status/1192092142639943680?s=20
Ron Jeffries:
> Story points are time to implement once you start implementing, times an arbitrary constant. That's all they are. Much of what you wrote above sounded like cycle time ... and points aren't that.
https://twitter.com/RonJeffries/status/1191867124035158016?s=20
Ron Jeffries:
> OK, experts who think story points aren't about cost, and that cost isn't essentially time, educate me. What are they, what are they good for, why do we estimate them?
In answering, show no concern for the likelihood that I invented them.
If I did, I'm sorry now.
https://twitter.com/RonJeffries/status/1128296444845330433?s=20
Ron Jeffries:
> No. However, the whole point of story points, like all other forms of story cost estimation, is to figure out how long things will take (or, the equivalent, how much work to take on in some interval).
If they can't be added, they are entirely without value.
https://twitter.com/RonJeffries/status/1128290085714186242?s=20
Ron Jeffries:
> i was there when story points were invented, and while i don't like them and regret past support for them, i can tell you that they were built to be proportional to time, and additive.
https://twitter.com/RonJeffries/status/1128070252275884037?s=20
Ron Jeffries:
> neither hours nor points are discernibly better than counting stories. points were invented to disguise our use of “perfect” days, which was confusing to management. XP never used hours to my recollection.
cf. the no estimates idea.
https://twitter.com/RonJeffries/status/1097601165930442753?s=20
Ron Jeffries:
> we estimated stories initially in "ideal time", later in points, tracked number accomplished to adjust how many to pull each iteration. switched to points because ideal time confused people (why did 2 day story take 5 days).
it worked, i think, because we had low politics.
https://twitter.com/RonJeffries/status/1052858860539658240?s=20
Ron Jeffries:
> points are stories/time*constant. how long you work, not how hard you work.
https://twitter.com/RonJeffries/status/979096172273942528?s=20
Ron Jeffries:
> yes. we had estimated work in “perfect days” and since it takes more than one real day to equal one perfect day, our stakeholders were confused. so we just estimated the same way and called them points. today, i don’t recommend estimating stories at all. small stories [could be used instead]. count them.
https://twitter.com/RonJeffries/status/937207650353319936?s=20
Ron Jeffries:
> original story points were Perfect Engineering Days, one’s estimate of how long it would take if the bastards left us alone.
https://twitter.com/RonJeffries/status/834879258753449989?s=20
Ron Jeffries:
> I am not sure I invented story points but if I did I’m sorry now.
https://twitter.com/RonJeffries/status/943790497981706242?s=20
Ron Jeffries:
> I may have invented story points. If I did, I am sorry now.
https://twitter.com/RonJeffries/status/815924184257851392?s=20
#Agile
Twitter
Ron Jeffries
@neil_killick @BischoffDev (and 2 others) i was there when story points were invented and they are about time, no more and no less.
Новая статья от Vladimir Khorikov @vkhorikov
"Domain model purity and the current time" https://enterprisecraftsmanship.com/posts/domain-model-purity-current-time/
#DDD #SoftwareDesign
"Domain model purity and the current time" https://enterprisecraftsmanship.com/posts/domain-model-purity-current-time/
#DDD #SoftwareDesign
Enterprise Craftsmanship
Domain model purity and the current time
I’m continuing the topic of domain model purity. This time, we’ll look at it with regards to getting the current date and time.
By the way, be sure to subscribe to my email list. Not all discussions fit the format of a blog post (including some shorter…
By the way, be sure to subscribe to my email list. Not all discussions fit the format of a blog post (including some shorter…
Когда у вас спрашивают для чего нужны DDD и другие методики управления сложностью. У меня эта картинка вызывает ассоциацию с "Законом магического числа семь плюс-минус два".
https://ru.m.wikipedia.org/wiki/%D0%9C%D0%B0%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D1%87%D0%B8%D1%81%D0%BB%D0%BE_%D1%81%D0%B5%D0%BC%D1%8C_%D0%BF%D0%BB%D1%8E%D1%81-%D0%BC%D0%B8%D0%BD%D1%83%D1%81_%D0%B4%D0%B2%D0%B0
https://ru.m.wikipedia.org/wiki/%D0%9C%D0%B0%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D1%87%D0%B8%D1%81%D0%BB%D0%BE_%D1%81%D0%B5%D0%BC%D1%8C_%D0%BF%D0%BB%D1%8E%D1%81-%D0%BC%D0%B8%D0%BD%D1%83%D1%81_%D0%B4%D0%B2%D0%B0
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
На широко обсуждаемую статью Uber "Introducing Domain-Oriented Microservice Architecture" https://eng.uber.com/microservice-architecture/ Уже отреагировали: Grady Booch: - https://twitter.com/Grady_Booch/status/1288246565988048896?s=19 Martin Fowler: - …
На Хабре есть перевод упомянутой статьи:
"Предметно-ориентированная микросервисная архитектура от Uber", автор оригинала: Adam Gluck
https://m.habr.com/ru/company/flant/blog/514830/
#Microservices #DDD
"Предметно-ориентированная микросервисная архитектура от Uber", автор оригинала: Adam Gluck
https://m.habr.com/ru/company/flant/blog/514830/
#Microservices #DDD
Хабр
Предметно-ориентированная микросервисная архитектура от Uber
Прим. перев.: недавняя статья от Uber Engineering рассказывает о путешествии этой крупной компании к своей улучшенной версии микросервисной архитектуры. Несмотря на то, что некоторые...
Весьма интересный workshop от Neal Ford:
How do you choose the appropriate granularity for microservices? There are better strategies than leaving this to chance.
"Architecture: The Hard Parts"
2 x 4 hours remote workshop with Zhamak Dehghani, Neal Ford, and Mark Richards
https://training.dddeurope.com/architecture-the-hard-parts-dehghani-ford/
И еще один workshop, заслуживающий внимания, от Vaughn Vernon:
Both of this week's virtual @IDDDWorkshop events sold out, EU and US/Americas. October has two more, EU & Asia/Australia (EU nearly sold out)
- 12-15 October 08:30 - 12:00 CEST
- 13-16 October
- 09:00 AM – 12:30 PM (SGT)
- 11:00 AM - 2:30 PM (AEDT)
https://t.co/MaOHsiiGop
#Microservices #DDD
How do you choose the appropriate granularity for microservices? There are better strategies than leaving this to chance.
"Architecture: The Hard Parts"
2 x 4 hours remote workshop with Zhamak Dehghani, Neal Ford, and Mark Richards
https://training.dddeurope.com/architecture-the-hard-parts-dehghani-ford/
И еще один workshop, заслуживающий внимания, от Vaughn Vernon:
Both of this week's virtual @IDDDWorkshop events sold out, EU and US/Americas. October has two more, EU & Asia/Australia (EU nearly sold out)
- 12-15 October 08:30 - 12:00 CEST
- 13-16 October
- 09:00 AM – 12:30 PM (SGT)
- 11:00 AM - 2:30 PM (AEDT)
https://t.co/MaOHsiiGop
#Microservices #DDD
Domain-Driven Design Europe Workshops
Software Architecture: The Hard Parts
Neal Ford — When you encounter novel problems (and they’re all novel when you become an architect), how do you make decisions if no “best practices” exist and no one has ever solved this problem…
Новая книга от Nick Tune: "Architecture Modernization with Strategic Domain-Driven Design"
A Guide for Technology Leaders
https://leanpub.com/arch-modernization-ddd
#DDD #SoftwareDesign #SoftwareArchitecture #Microservices
A Guide for Technology Leaders
https://leanpub.com/arch-modernization-ddd
#DDD #SoftwareDesign #SoftwareArchitecture #Microservices
Leanpub
Architecture Modernization: Product, Domain, & Team-Oriented
A good architecture enables organizations to innovate at speed. This book shows how to get there...
Новая статья от разработчиков Watermill
"Introducing basic CQRS by refactoring a Go project"
https://threedots.tech/post/basic-cqrs-in-go/
#DDD #Microservices
"Introducing basic CQRS by refactoring a Go project"
https://threedots.tech/post/basic-cqrs-in-go/
#DDD #Microservices
threedots.tech
How to use basic CQRS in Go
We implement basic CQRS in Go using our open-source project, solving issues with complex, unmaintainable models. We provide practical examples of commands and queries, explain naming best practices, and outline future optimizations we've successfully applied…
Уже не ново, но все еще актуально. Просто вспомнил сегодня об этом твите:
https://twitter.com/jbogard/status/1291744769266384899?s=19 .
Автор твита в представлениях не нуждается. eShopOnContainers - тоже.
#DDD #Microservices
https://twitter.com/jbogard/status/1291744769266384899?s=19 .
Автор твита в представлениях не нуждается. eShopOnContainers - тоже.
#DDD #Microservices
Twitter
Jimmy Bogard 🍻
maybe eShopOnContainers?
Несколько неплохих ссылок по CRDT для начинающих:
- https://github.com/ljwagerfield/crdt
- http://christophermeiklejohn.com/crdt/2014/07/22/readings-in-crdts.html
- https://habr.com/ru/post/418897/
#DistributedSystems #DDD #Microservices
- https://github.com/ljwagerfield/crdt
- http://christophermeiklejohn.com/crdt/2014/07/22/readings-in-crdts.html
- https://habr.com/ru/post/418897/
#DistributedSystems #DDD #Microservices
GitHub
GitHub - ljwagerfield/crdt: CRDT Tutorial for Beginners (a digestible explanation with less math!)
CRDT Tutorial for Beginners (a digestible explanation with less math!) - ljwagerfield/crdt
Сколько Martin Kleppmann заработал на своей книге "Designing Data-Intensive Applications" и что ему это стоило, рассказал вчера он сам в своем блоге:
https://martin.kleppmann.com/2020/09/29/is-book-writing-worth-it.html
#DistributedSystems
https://martin.kleppmann.com/2020/09/29/is-book-writing-worth-it.html
#DistributedSystems