Examples of each of the following

CA - Relational databases - The data is persisted using the ACID properties of a transaction thus keeping it consistent. Availability is achieved by storing data on multiple nodes.

AP - NoSQL databases - The data is made available by persisting it on multiple nodes. The nodes are partition tolerant by allowing the clients to access the data on different nodes even if the nodes are not in sync or consistent

CP - A system with a master slave configuration. The data is always consistent across the master and slaves with read-write on master and read on slaves. If master goes offline, then slaves are still available for read but no updates are allowed to the system.

That said, a system should be designed with a balance in mind, giving priority to the more relevant two capabilities and not fully leaving out the third.

Developers new to Git often find this as a stumbling block and have a bit of learning curve. This post will help in getting quickly up to speed without having to dig deep to find the end to end process.

Below are the steps to perform a Git code review. (assumptions: you know how to get to the portal of your git repository)

1. Create a topic branch from the master and publish the branch.

2. Make your necessary code changes in your topic branch

3. Commit your changes to your topic branch (this could be done multiple times)

4. When you are ready to get your work reviewed, from the web portal, create a pull request

5. Select your topic branch as the source and the branch you want to merge into as the target branch.

6. Specify the title, description, and assign reviewers.  (Reviewers can be a team name), after submitting for review, click on email on the left hand menu to notify the reviewers).

7. Reviewers make comments on specific lines of code. To target a specific block of code, highlight it before inserting the comment.

8. To act on the feedback,the requestor revises the code on their dev machine and pushes the changes so that reviewers can see them

9. Each reviewer approves or rejects the pull request.

10. When the requestor and the reviewers are satisfied that the pull request is ready to merge, perform the merge from the portal.

11. After the merge, the master branch is updated with the changes from the topic branch

12. You can reuse the topic branch for future requests.

Hopefully this will help you quickly get an overview of the steps involved in a VSO Git code review process.

For full details refer to the blog

http://blogs.msdn.com/b/visualstudioalm/archive/2014/06/10/git-pull-request-visual-studio-online.aspx

The simple answer is “They are similar but different”. The implementations are similar but the intentions are different. To give an analogy, a city bus and school bus are both similar vehicles, but they are used for different purposes. One is used to transport people between various parts of the city as a commuter service. The other is used for transporting kids to schools.

Let’s start with the definitions of each of these patterns and then look at some practical applications.

Strategy Pattern:

• Define a family of algorithms, encapsulate each one, and make them interchangeable.

• Strategy lets the algorithm vary independently from the clients that use it.

• Capture the abstraction in an interface, bury implementation details in derived classes

• A bind once behavioral pattern.

Bridge Pattern:

• Decouple an abstraction from its implementation so that the two can vary independently.

• Publish interface in an inheritance hierarchy, and bury implementation in its own inheritance hierarchy.

• A structural pattern.

Enough of theory. Let’s get to some scenarios and learn when to use each of these patterns.

Strategy Scenario:

As part of my daily exercise routine, I want to choose an appropriate workout strategy for the day before starting my workout.

  
  
An exercise routine consists of a specific workout. Before the workout begins, a workout strategy is chosen by the client. The following code snippet explains the behavior.

          var routine = new ExcerciseRoutine(new AerobicsStrategy);

          routine.Workout();

The algorithm for the specific type of workout is encapsulated from the client who interacts only with the interface of the strategy.

Bridge Scenario:

Let’s see if we can apply the same concept of an exercise routine for the Bridge pattern.

As part of my exercise routine, I want to have a weekday exercise routine and a weekend routine. The routine involves running either on a treadmill, park or sidewalk.

The client sets the Runner type and invokes the workout as below

    var weekdayRoutine = new WeekdayRoutine();

    weekdayRoutine.Runner = new Treadmill();

    weekdayRoutine.Workout();

    //Change the Runner and perform the workout again

    weekdayRoutine.Runner = new Sidewalk();

    weekdayRoutine.Workout();

An exercise routine can vary independently of the implementation of the run. For example, I may decide to add a new runner SchoolPlayground without having to change the client. On the other hand, I can add a new routine MondayRoutine without impacting the implementation of the Runner.

Hope this helps understand the difference between a Strategy and a Bridge pattern.