Revert "Update rule.md (#8366)"

This reverts commit e3d296c.

categories/project-delivery/rules-to-better-scaled-agile-framework.md

@@ -7,13 +7,11 @@ experts: https://www.ssw.com.au/people/?skill=Scrum
 consulting: https://www.ssw.com.au/consulting/scrum
 index:
 - use-safe-to-align-multiple-scrum-teams
-- prioritize-value-streams-over-individual-projects
-- establish-a-Lean-Agile-mindset-across-all-teams
-- implement-DevOps-practices-for-continuous-delivery
-- utilize-a-release-train
-- involve-stakeholders-in-pi-planning
-- measure-success-using-lean-agile-metrics
-- regularly-inspect-and-adapt-at-scale
-- foster-a-culture-of-relentless-improvement
-- ensure-compliance-and-governance-without-compromising-agility
+- do-you-implement-DevOps-practices-for-continuous-delivery
+- do-you-utilize-a-release-train
+- do-you-involve-stakeholders-in-pi-planning
+- do-you-measure-success-using-lean-agile-metrics
+- do-you-regularly-inspect-and-adapt-at-scale
+- do-you-foster-a-culture-of-relentless-improvement
+- do-you-ensure-compliance-and-governance-without-compromising-agility
 ---

categories/software-engineering/rules-to-better-large-builds-in-visual-studionet.md

@@ -3,9 +3,11 @@ type: category
 title: SSW Rules to Better Large Builds in Visual Studio.NET
 guid: 13a3a376-6df2-4674-bcc7-cb0f6f69102d
 uri: rules-to-better-large-builds-in-visual-studionet
-archivedreason: The better ways to manage these builds if by using Clean Architecture and Nuget package manager.
 index:
 - desired-features-of-structuring-large-builds-in-vsnet
+- method-1-using-project-reference-assemblies-within-vsnet
+- method-2-using-file-reference-assemblies-within-vsnet
 - scenarios-of-building-the-system
-
 ---
+
+If you still need help, visit [Microsoft Customer Relationship Management CRM | SSW Consulting Sydney, Brisbane & Melbourne](https://www.ssw.com.au/ssw/Consulting/MicrosoftCRM.aspx) and book in a consultant.

rules/do-you-know-the-common-design-patterns-part-1/rule.md

@@ -12,42 +12,40 @@ authors:
   url: https://ssw.com.au/people/adam-stephensen
 - title: Damian Brady
   url: https://ssw.com.au/people/damian-brady
-- title: Dhruv Mathur
-  url: https://ssw.com.au/people/dhruv-mathur
 related: []
 redirects:
 - do-you-know-the-common-design-patterns-(part-1)
 
 ---
 
-Design patterns are useful for ensuring [common design principles](/do-you-know-the-common-design-principles-part-1) are being followed.  They help make your code consistent, predictable, and easy to maintain.
+Design patterns are useful for ensuring [common design principles](/do-you-know-the-common-design-principles-part-1)are being followed.  They help make your code consistent, predictable, and easy to maintain.
 
 <!--endintro-->
 
 There are a very large number of Design Patterns, but here are a few important ones.
 
-* **IOC** | [Inversion of Control](http&#58;//en.wikipedia.org/wiki/Inversion_of_control)  
-In this pattern, control over the instantiation and management of objects is inverted, meaning that these responsibilities are handed over to an external framework like a DI container instead of being managed by the classes themselves. This separation enhances flexibility and decouples all the classes in the system.
+- **IOC** | [Inversion of Control](http&#58;//en.wikipedia.org/wiki/Inversion_of_control)  
+Control of the object coupling is the responsibility of the caller, not the class.
 
-* **DI** | [Dependency Injection](http&#58;//en.wikipedia.org/wiki/Dependency_injection)  
-DI is a form of IoC where dependencies are provided to objects rather than created by them, one instance of the dependency can be used by many. This pattern also reduces dependency coupling between components since the instantiation is handled externally, making the system easier to manage and test.
+- **DI** | [Dependency Injection](http&#58;//en.wikipedia.org/wiki/Dependency_injection)  
+Dependencies are "injected" into the dependent object rather than the object depending on concretions.
 
-* **Factory** | [Factory Pattern](http&#58;//en.wikipedia.org/wiki/Factory_pattern)  
-It is a creational pattern that deals with the problem of creating objects without specifying the exact class of object that will be created. This is done by defining an interface or abstract class for creating an object, which subclasses decide how to implement. This pattern helps in managing and maintaining code by encapsulating how any object is created.
+- **Factory** | [Factory Pattern](http&#58;//en.wikipedia.org/wiki/Factory_pattern)  
+Object creation is handled by a "factory" that can provide different concretions based on an abstraction.
 
-* **Singleton** | [Singleton Pattern](http&#58;//en.wikipedia.org/wiki/Singleton_pattern)  
-This ensures that a class has only one instance and provides a global point of access to it. This pattern is used to control access to resources that are shared throughout an application, like a configuration file or connection to a database. This ensures that only a single shared instance of a class is consumed by the application.
+- **Singleton** | [Singleton Pattern](http&#58;//en.wikipedia.org/wiki/Singleton_pattern)  
+Instantiation of an object is limited to one instance to be shared across the system.
 
-* **Repository** | [Repository Pattern](http&#58;//msdn.microsoft.com/en-us/library/ff649690.aspx)  
-A repository abstracts the data layer, providing a collection-like interface for accessing domain objects. It centralizes common data access functionalities and promotes a more organized data access architecture. By isolating the data layer, this pattern ensures that changes to the database access code are minimized when changes to the business logic or database specifics occur.
+- **Repository** | [Repository Pattern](http&#58;//msdn.microsoft.com/en-us/library/ff649690.aspx)  
+A repository is used to handle the data mapping details of CRUD operations on domain objects. 
 
-* **Unit of Work** | [Unit of Work Pattern](http&#58;//msdn.microsoft.com/en-us/magazine/dd882510.aspx)  
-It is a way to keep track of everything you do during a transaction that can affect the database. When it's time to commit the transaction, it figures out everything that needs to be done to alter the database as a result of your work. This pattern is crucial for maintaining the consistency of data within the boundaries of a transaction.
+- **Unit of Work** | [Unit of Work Pattern](http&#58;//msdn.microsoft.com/en-us/magazine/dd882510.aspx)  
+A way of handling multiple database operations that need to be done as part of a piece of work. 
 
-* **MVC** | [Model View Controller](http&#58;//en.wikipedia.org/wiki/Model%e2%80%93view%e2%80%93controller)  
-It is an architectural pattern that separates an application into three main logical components: the model, the view, and the controller. Each of these components handles different aspects of the application's data, user interface, and control logic, respectively. This separation helps manage complexity in large applications.
+- **MVC** | [Model View Controller](http&#58;//en.wikipedia.org/wiki/Model%e2%80%93view%e2%80%93controller)  
+An architectural pattern separating domain logic (Controller) from how domain objects (Models) are presented (View).
 
-* **MVP** | [Model View Presenter](http&#58;//en.wikipedia.org/wiki/Model_View_Presenter)
-This pattern is a simpler version of MVC designed for modern applications where the user interface (the view) just displays information and responds to user inputs. In MVP, a middle-man called the presenter handles all the decision-making behind the scenes. It takes care of updating the view and reacting to user actions, making the view very simple and straightforward. This setup makes it easier to test the user interface because the view itself doesn't contain any complex logic—it just shows what the presenter tells it to.
+- **MVP** | [Model View Presenter](http&#58;//en.wikipedia.org/wiki/Model_View_Presenter)   
+An architectural pattern deriving from MVC where the View handles UI events instead of the Controller.
 
-By leveraging these design patterns, developers can solve complex problems more efficiently and ensure that their applications are robust, scalable, and easy to maintain. It is assumed knowledge that you know these design patterns. If you don't, read about them on the sites above or watch the [PluralSight videos on Design Patterns.](https://www.pluralsight.com/paths/design-patterns-in-c)
+Choose patterns wisely to improve your solution architecture. It is assumed knowledge that you know these design patterns. If you don't, read about them on the sites above or watch the [PluralSight videos on Design Patterns.](https://www.pluralsight.com/paths/design-patterns-in-c)

rules/do-you-know-the-common-design-patterns-part-2-example/rule.md

@@ -14,102 +14,43 @@ authors:
   url: https://ssw.com.au/people/adam-stephensen
 - title: Eric Phan
   url: https://ssw.com.au/people/eric-phan
-- title: Dhruv Mathur
-  url: https://ssw.com.au/people/dhruv-mathur
 related:
 - do-you-name-your-dependencies-to-avoid-problems-with-minification
 redirects:
 - do-you-know-the-common-design-patterns-(part-2-example)
 
 ---
 
-Appropriate use of design patterns can ensure your code is maintainable and easy to read.
+Appropriate use of design patterns can ensure your code is maintainable.
 
 <!--endintro-->
 
-### Dependency Injection
+Always code against an interface rather than a concrete implementation. Use dependency injection to control which implementation the interface uses.
 
-We should implement Inversion of Control by using the Dependency Injection pattern to decrease the direct coupling of our classes. Seprating the creation of objects or instances of services from thier usage allows for more flexibility and testability.
+For example, we could implement Inversion of Control by using the Dependency Injection pattern to decrease the coupling of our classes.
 
-Lets look at an example, in this code, our controller is tightly coupled to the ExampleService and as a result, there is no way to unit test the controller.
+In this code, our controller is tightly coupled to the ExampleService and as a result, there is no way to unit test the controller.
 
 [This example is from the blog: http://www.devtrends.co.uk/blog/how-not-to-do-dependency-injection-the-static-or-singleton-container]
 
-```csharp
-public class HomeController
-{
-    private readonly IExampleService _service;
+`public class HomeController{    private readonly IExampleService _service;    public HomeController()    {      _service = new ExampleService();    }         public ActionResult Index()    {        return View(_service.GetSomething());    }}`
 
-    public HomeController()
-    {
-        _service = new ExampleService();
-    }
+Figure: Bad example - Controller coupled with ExampleService
 
-    public ActionResult Index()
-    {
-        return View(_service.GetSomething());
-    }
-}
-```
+`public class HomeController{    private readonly IExampleService _service;         public HomeController()    {      _service = Container.Instance.Resolve<IExampleService>();    }         public ActionResult Index()    {        return View(_service.GetSomething());    }}`
 
-**❌ Figure: Bad example - Controller coupled with ExampleService.**
-
-```csharp
-public class HomeController
-{
-    private readonly IExampleService _service;
-
-    public HomeController()
-    {
-        _service = Container.Instance.Resolve<IExampleService>();
-    }
-
-    public ActionResult Index()
-    {
-        return View(_service.GetSomething());
-    }
-}
-```
-
-**❌ Figure: Bad example - 2nd attempt using an Inversion of Control container but \*not\* using dependency injection. A dependency now exists on the Container.**
+Figure: Bad example - 2nd attempt using an Inversion of Control container but \*not\* using dependency injection. A dependency now exists on the Container.
 
 This is bad code because we removed one coupling but added another one (the container).
 
-```csharp
-public class HomeController
-{
-    private readonly IExampleService _service;
-
-    public HomeController(IExampleService service)
-    {
-        _service = service;
-    }
-
-    public ActionResult Index()
-    {
-        return View(_service.GetSomething());
-    }
-}
-```
-
-**✅ Figure: Good example - code showing using dependency injection. No static dependencies.**
+`public class HomeController{    private readonly IExampleService _service;         public HomeController(IExampleService service)    {      _service = service;    }         public ActionResult Index()    {        return View(_service.GetSomething());    }}`
+Figure: Good example - code showing using dependency injection. No static dependencies. 
+Even better, use Annotate so you can enlighten the developer.
 
-### Code against Interfaces
-
-Always code against an interface rather than a concrete implementation. Use dependency injection to control which implementation the interface uses. By doing this you create a contract for that service which the rest of the codebase has to adhere to.
-
-By creating an interface for each service and programming against the interface, you can easily swap out the implementation of the service without changing the code that uses the service.
-
-It is important to also control the scope of the injection. For example, in ASP.NET 8 application you have the option to register the concrete implementation in the DI container either as a singleton, scoped, or transient service. Each of them will have a different lifetime in the application and should be set as per the requirement.
-
-![](Code against interfaces - bad.png)
-**❌ Figure: Bad Example - Referencing the concrete EF context**
-
-This is bad code because now the controller is directly dependent on the implementation of the EF context. This also increase the effort for unit testing.
+![bad.png](Code against interfaces - bad.png)
+**Figure: Bad Example - Referencing the concrete EF context**
 
 ![](Code against interfaces - good.png)
-**✅ Figure: Good Example - Programming against the interface**
-
-This is good because now you can test the controller and the services independently. Also the controller only talks to the service through the functionality exposed by the interface, enforcing encapsulation.
+**Figure: Good Example - Programming against the interface**
 
 It is important to know when the use of a pattern is appropriate.  Patterns can be useful, but they can also be harmful if used incorrectly.

rules/dones-do-your-dones-include-a-url/rule.md

@@ -21,7 +21,7 @@ guid: ed0fa76a-418b-4b59-9e3b-2544c08b910e
 
 ---
 
-Always include the relevant URL to your emails, like when you want to request or just made a change to a webpage or document. This way people can easily check the details of the tasks. This is especially important for ["Done" emails](/reply-done-and-delete-the-email).
+Always include the relevant URL to your emails, like when you want to request or just made a change to a webpage or document. This way people can easily check the details of the tasks. This is especially important for ["Done" emails](reply-done-and-delete-the-email).
 
 If you are using a task tracking system like **Azure DevOps**, **GitHub**, or Jira, also include the link to the PBI/Issue/task.
 
@@ -57,7 +57,7 @@ Figure: Good example - Easy to check what was done + includes the context of the
 
 Before declaring a task 'done' with a link, ensure that your changes are live and accessible for verification.
 
-#### Scenario: ❌ PR waiting for approval
+##### ❌ **Scenario:** PR waiting for approval
 
 ::: greybox
 Done - ssw.com.au/rules/dones-is-your-inbox-a-task-list-only
@@ -83,7 +83,7 @@ Done - ssw.com.au/rules/dones-is-your-inbox-a-task-list-only
 Figure: OK example - Links are included, changes are not live yet, but people are aware
 :::
 
-#### Scenario: ✅ PR approved and merged
+##### ✅ **Scenario:** PR approved and merged
 
 ::: greybox
 Done - ssw.com.au/rules/dones-is-your-inbox-a-task-list-only
@@ -96,7 +96,7 @@ Figure: Good example - Final link is included and changes are live to be checked
 
 It is a common problem where someone CC'd will not have permissions to see a file and the sender knows this. You should still add the link but inform the recipient.
 
-#### Scenario: ❌ Recipient doesn't have permissions
+**Scenario:** Recipient doesn't have permissions.
 
 ::: greybox
 Done - onedrive.live.com/file-name.xls

rules/ensure-compliance-and-governance-without-compromising-agility/rule.md

@@ -1,15 +1,14 @@
 ---
 type: rule
 title: Do you ensure compliance and governance without compromising agility?
-uri: ensure-compliance-and-governance-without-compromising-agility
+uri: do-you-ensure-compliance-and-governance-without-compromising-agility
 authors:
   - title: Gert Marx
     url: https://ssw.com.au/people/gert-marx
   - title: Ulysses Maclaren
     url: https://ssw.com.au/people/ulysses-maclaren
 related:
 redirects:
-  - do-you-ensure-compliance-and-governance-without-compromising-agility
 created: 2023-10-13T17:56:00.000Z
 archivedreason: null
 guid: 684c1885-d097-4e9c-8e68-0998a81ff940
@@ -30,19 +29,19 @@ Achieving this balance means establishing processes and guidelines that provide
 
 ### Benefits of Balancing Compliance and Agility
 
-#### Risk Mitigation
+**Risk Mitigation**
 
 Balancing compliance and agility doesn't just help the organization meet its legal and regulatory requirements – it's a comprehensive risk mitigation strategy. By ensuring adherence to these standards, the organization not only avoids legal pitfalls and financial penalties but also safeguards its reputation and stakeholder trust.
 
 This aspect of risk mitigation is crucial in today’s business environment, where non-compliance can have far-reaching consequences. Simultaneously, maintaining agility within this compliance framework ensures that the organization remains dynamic and responsive, capable of quickly adapting to changing regulations and market conditions. Thus, this balance acts as a dual shield, protecting the organization legally and competitively.
 
-#### Operational Efficiency
+**Operational Efficiency**
 
 Striking a balance between compliance and agility paves the way for enhanced operational efficiency. In this framework, teams are empowered to be agile and responsive, navigating their tasks and projects with the necessary freedom to innovate and adapt. At the same time, they are not encumbered by excessive controls or rigid procedures that can stifle creativity and responsiveness.
 
 This equilibrium ensures that the agility of teams is not sacrificed in the name of compliance. Instead, it fosters an environment where teams can operate efficiently within a well-defined, yet flexible, governance structure. The result is a streamlined workflow that upholds compliance standards without dampening the agile spirit that drives productivity and continuous improvement.
 
-#### Business Alignment
+**Business Alignment**
 
 Balancing compliance with agility plays a critical role in aligning both governance structures and agile practices with the overarching business objectives. This alignment is key to ensuring that every regulatory measure and agile initiative not only coexists but also collaboratively drives the organization towards its strategic goals.