From b545508beee3fe005a63800cbf8bfec90b9dd0db Mon Sep 17 00:00:00 2001 From: rafiqulshopon Date: Fri, 24 Feb 2023 18:34:30 +0600 Subject: [PATCH 1/4] fixed typo --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 3cf2a2b..5af735f 100644 --- a/README.md +++ b/README.md @@ -31,7 +31,7 @@ The code represents the detail of the requirements and the details cannot be ign - Are you in a rush? - Do you try to go "fast"? -- Do not you have time to do a good job? +- Don't you have time to do a good job? - Are you tired of work in the same program/module? - Does your Boss push you to finish soon? From b486d3ea3c1767c63f9d734df27c3b48bd85bde5 Mon Sep 17 00:00:00 2001 From: rafiqulshopon Date: Fri, 24 Feb 2023 18:41:21 +0600 Subject: [PATCH 2/4] fixed more typos --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 5af735f..0813862 100644 --- a/README.md +++ b/README.md @@ -1212,9 +1212,9 @@ According to Kent Beck, a design is "simple" if it follows these rules

Chapter 13 - Concurrency

-Concurrence is a decoupling strategy. It helps us decouple what gets fone from when it gets done. In single-threaded applications what and when are so strongly coupled that the state of the entire application can often be determined by looking at the stack backtrace. A programmer who debugs such a system can set a breakpoint, or a sequence of breakpoints, and know the state of the system by which breakpoints are hit. +Concurrence is a decoupling strategy. It helps us decouple what gets done from when it gets done. In single-threaded applications what and when are so strongly coupled that the state of the entire application can often be determined by looking at the stack backtrace. A programmer who debugs such a system can set a breakpoint, or a sequence of breakpoints, and know the state of the system by which breakpoints are hit. -Decoupling what from when can dramatically improve both the throughput and structures of an application. From a structural point of view the application looks like many lit- tle collaborating computers rather than one big main loop. This can make the system easier to understand and offers some powerful ways to separate concerns. +Decoupling what from when can dramatically improve both the throughput and structures of an application. From a structural point of view the application looks like many little collaborating computers rather than one big main loop. This can make the system easier to understand and offers some powerful ways to separate concerns. ## Miths and Misconceptions From 47808ed0e867c9a7e0cfd883b84d076f4361e8ef Mon Sep 17 00:00:00 2001 From: rafiqulshopon Date: Fri, 24 Feb 2023 18:48:07 +0600 Subject: [PATCH 3/4] fixed more typos --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 0813862..3a0e28f 100644 --- a/README.md +++ b/README.md @@ -1114,7 +1114,7 @@ Interesting things happen at boundaries. Change is one of those things. Good sof ### The Three Laws of TDD - **First Law** You may not write production code until you have written a failing unit test. -- **Second Law** You may not write more of a unit tests than is sufficient to fail, and not comipling is failing. +- **Second Law** You may not write more of a unit tests than is sufficient to fail, and not compiling is failing. - **Third Law** You may not write more production code than is sufficient to pass the currently failing tests. ### Clean Tests @@ -1125,7 +1125,7 @@ The readability it's very important to keep clean your tests. ### One Assert per test -It's recomendable maintain only one asserts per tests, because this helps to maintain each tests easy to understand. +It's recommendable maintain only one asserts per tests, because this helps to maintain each tests easy to understand. ### Single concept per Test @@ -1136,7 +1136,7 @@ This rule will help you to keep short functions. ### F.I.R.S.T - **Fast** Test should be fast. -- **Independient** Test should not depend on each other. +- **Independent** Test should not depend on each other. - **Repeatable** Test Should be repeatable in any environment. - **Self-Validating** Test should have a boolean output. either they pass or fail. - **Timely** Unit tests should be written just before the production code that makes them pass. If you write tests after the production code, then you may find the production code to be hard to test. @@ -1176,7 +1176,7 @@ For most systems, change is continual. Every change subjects us to the risk that ### Isolating from Change -Needs will change, therefore code will change. We learned in OO 101 that there are concrete classes, which contain implementation details (code), and abstract classes, which represent concepts only. A client class depending upon concrete details is at risk when those details change. We can introduce intefaces and abstract classes to help isolate the impact of those details. +Needs will change, therefore code will change. We learned in OO 101 that there are concrete classes, which contain implementation details (code), and abstract classes, which represent concepts only. A client class depending upon concrete details is at risk when those details change. We can introduce interfaces and abstract classes to help isolate the impact of those details.

Chapter 11 - Systems

@@ -1194,7 +1194,7 @@ The Abstract Factory Pattern is an option for this kind of approach. ### Dependency Injection -A powerful mechanism for separating construction from use is Dependency Injection (DI), the application of Inversion of control (IoC) to dependency management. Inversion of control moves secondary responsibilities from an object to other objects that are dedicated to the purpose, thereby supporting the Single Responsibility Principle. In context of dependency management, an object should not take responsibility for instantiating dependencies itself. Instead, it, should pass this responsibility to another "authoritative" mechanism, thereby inverting the control. Because setup is a global concern, this authoritative mechanism will usually be either the "main" +A powerful mechanism for separating construction from use is Dependency Injection (DI), the application of Inversion of control (IoC) to dependency management. Inversion of control moves secondary responsibilities from an object to other objects that are dedicated to the purpose, thereby supporting the Single Responsibility Principle. In context of dependency management, an object should not take responsibility for instantiating dependencies itself. Instead, it should pass this responsibility to another "authoritative" mechanism, thereby inverting the control. Because setup is a global concern, this authoritative mechanism will usually be either the "main" routine or a special-purpose _container_.
From db3abe0031f6bd59b70faa96dfe1c6bfe9e3abdc Mon Sep 17 00:00:00 2001 From: Rafiqul Shopon Date: Tue, 28 Mar 2023 00:09:12 +0600 Subject: [PATCH 4/4] revert back some changes --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 3a0e28f..84005e8 100644 --- a/README.md +++ b/README.md @@ -31,7 +31,7 @@ The code represents the detail of the requirements and the details cannot be ign - Are you in a rush? - Do you try to go "fast"? -- Don't you have time to do a good job? +- Do not you have time to do a good job? - Are you tired of work in the same program/module? - Does your Boss push you to finish soon?