The nature of deliberation and its objects: choice is the deliberate desire of things in our own power.

We deliberate not about ends but about means. For a doctor does not deliberate whether he shall heal, nor an orator whether he shall persuade, nor a statesman whether he shall produce law and order, nor does any one else deliberate about his end. They assume the end and consider how and by what means it is to be attained; and if it seems to be produced by several means they consider by which it is most easily and best produced, while if it is achieved by one only they consider how it will be achieved by this and by what means this will be achieved, till they come to the first cause, which in the order of discovery is last. For the person who deliberates seems to investigate and analyse in the way described as though he were analysing a geometrical construction (not all investigation appears to be deliberation--for instance mathematical investigations--but all deliberation is investigation), and what is last in the order of analysis seems to be first in the order of becoming. And if we come on an impossibility, we give up the search, e.g. if we need money and this cannot be got; but if a thing appears possible we try to do it. By 'possible' things I mean things that might be brought about by our own efforts; and these in a sense include things that can be brought about by the efforts of our friends, since the moving principle is in ourselves. The subject of investigation is sometimes the instruments, sometimes the use of them; and similarly in the other cases--sometimes the means, sometimes the mode of using it or the means of bringing it about. It seems, then, as has been said, that man is a moving principle of actions; now deliberation is about the things to be done by the agent himself, and actions are for the sake of things other than themselves. For the end cannot be a subject of deliberation, but only the means; nor indeed can the particular facts be a subject of it, as whether this is bread or has been baked as it should; for these are matters of perception. If we are to be always deliberating, we shall have to go on to infinity.



Book III: Moral Virtue, Chapter 3,

The Nicomachean Ethics of Aristotle
translated by William David Ross, 1908

The full text can be found here:
http://www.sacred-texts.com/cla/ari/nico/nico025.htm

The Strategy pattern

This is one of the more simple patterns and is really useful. It is ideal for encapsulating rules and simplifying those if-else or switch statements.

If you have some code that looks at an object and makes a decision based on a property of the object, then you may need to consider the Strategy. You should also consider this if you think that you may, at some point, get asked to add another clause into that switch statement. Maybe the code calculates the exchange rate for US$, and Euro. But what happens when the Business decides they want the British £ also.
For that you may need to add an else clause or extend the Switch.

That's not good really as it breaks the Open-Closed principle. I have a post on this which contains a code example.

This diagram gives a general idea of the pattern.

As an example we could have an object that needs to calculate the exchange rate. So, at construction time we could inject the required calculator and the object calls the relevant method. If we want to add another currency calculator, say UKPound, then we create the new class UKPoundCalculator, it implements the interface IExchangeRateStrategy, and we pass it to the contact class. The beauty is, there are no changes made to the CalculateTheCost context class.

See:
Open-Closed Principle

Microsoft's Distributed systems. A potted history.

I began to wonder how many technologies for distributed system that we have moved through since the 90's when I first started using DCOM. COM in VB was my first foray. Happy days.

DCOM and COM+

In the 90's, when programming with Microsoft, we had Distributed COM, DCOM and COM+ to play with if we wanted to get computers to communicate and work together as a system. These technologies were RPC based, worked only with Windows and required the DCOM to be infrastructure available on each node. The COM acronym, Component Object Model, gives us a clue that these were component based technologies.

ES

With .NET came a wrapper for DCOM and Com+ and that was Enterprise Services. This therefore had the same paradigm attributes as pre-.NET, it was RPC and worked only on Windows machines.

Remoting

.NET Remoting came along and was very simple and useful. It was ideal for new developments on new contained systems but it required each node to have the .NET CLR installed. This therefore reduced the effectiveness to only managed code systems running on Windows. It too was RPC in style.

MSMQ

Running alongside these technologies has been Microsoft Message Queue, MSMQ. It has been around since NT 4 and Windows 95. This differed from the other technologies in that rather than the RPC model it concentrated on Messages. It was not component based. But it did still require the nodes to have the MSMQ infrastructure on each node.   

So we have:

DCOM/COM+ and ES

.NET Remoting

MSMQ

In the late 90's web-services became prevalent and this enables any platform to communicate to another. Linux to Mac to Windows to whatever. Utilising the ubiquitous HTTP protocol we can use XML for the message formats and they can be in a variety of types - SOAP or RSS etc. 

SOAP & REST

SOAP (Simple Object Access Protocol) was the most common protocol specification used and is still very popular.  http://en.wikipedia.org/wiki/SOAP

• SOAP is simple.
• It is an XML file.
• The message contains a SOAP ENVELOPE  element as the root.
• The Envelope contains a Body element and a Head element.
• Your payload goes in the Body and the some controlling specifications can go into the Header. The controlling specifications are for Security, Reliable Messaging and Transaction features.

The main differing feature between SOAP and RESTful services is tat SOAP is specified to be used on any transport mechanism. REST however is tends only to be used on HTTP.

The SOAP stack

SOAP can therefore be used on any platform and requires the service contract to be coded in a similar way to RPC

REST (Representation State Transfer) http://en.wikipedia.org/wiki/REST 

With REST we treat services as Resources with unique identifies and we use the  HTTP defined interface of 

• GET, 
• POST, 
• PUT, 
• DELETE and 
• HEAD.

ASP.NET Web Services 

Microsoft provided ASP.NET Web Services (ASMX) which provided early basic support for SOAP.

Web Services Enhancements

Soon after the ASMX came WSE. This provided some support for the Security, RM and Tx protocols. Also supported were some TCP support. There were however no support for REST. 

Microsoft started to create a single model for all their communication frameworks. This became the Windows Communication Framework.

WCF

Now we can use use WCF to write the communication logic and then we can use whatever features we need. 

This is a huge step forward. The developer can now write against one single framework even if the requirement is for binary communication over TCP, or SOAP or REST. 

Advanced fault finding techniques and Issue rectification

Software in pictures

Really quite good article here: Software in pictures.

Here are a some of the pictures from the article. But do go and read the original.
These two are pretty self explanatory.

Yes this next one's obvious too.

This next one is so true. Go read the article.