Apropos the Blogjecting  Watchdog pattern,  In addition to blogging I recently added to our system the ability to twitter. I am using Tweet# from DimeBrain (thanks Mark Nijhof for the tip via twitter).

Tweet# makes using tweeter really simple (I included the code below in case you find it useful).

The tweeter sender is part of a PostOffice service (I thought that it would be problematic to present it as SpamServer which was its original name :) ).

Update 11/05 Here it is working on our staging environment :)

A few points about our design in general that are interesting in this regards are

• The PostOffice is a “Server” type service – we have 3 types of services: server which has one instance per node, channel which has multiple instances per node and algorithmic which has one instance per core
• The PostOffice implements a pattern I call “Legacy Bridge” – which is basically an SOA version of an adapter+facade in OO terms. The post office supports the events (over WCF) mechanism we have in our system from one side  and connects to external systems (SMS, coupons and twitter) on the other. The PostOffice, basically contains an Edge Component which accepts the requests and funnels them to *Sender classes that interact with the external systems.
• from contract design perspective – The events I added into the system are StatusEvent and AdminStatusEvent (and not TwitterEvent and DirectMessageEvent). this is better, in my opinion, as it carries the intent of what I want to achieve. It also means that if I choose to change technology or use multiple destinations the events will stay meaningful. For instance, the AdminStatusEvent will be used by our monitoring system to send a notification if the system crashes. I’ll probably want that as an SMS, maybe even a phone call as well as a twit (so the AdminStatusEvent will have a severity to designate how it should be handled)

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using System.Text;

   5: using Dimebrain.TweetSharp.Fluent;

   6:  

   7: namespace xsights.Apps.PostOffice.Server.Twitter

   8: {

   9:     class TwitterSender

  10:     {

  11:         private string account;

  12:         private string password;

  13:         private string admin;

  14:  

  15:         public TwitterSender(string tweetAccount, string twitterPassword,string adminAccount)

  16:         {

  17:             account = tweetAccount;

  18:             password = twitterPassword;

  19:             admin = adminAccount;

  20:         }

  21:         public void Update(string msg)

  22:         {

  23:              foreach (var tweet in BreakToTwitts(msg))

  24:             {

  25:                 var update =

  26:                     FluentTwitter.CreateRequest().AuthenticateAs(account, password).Statuses().Update(tweet).AsJson();

  27:  

  28:                 update.Request();

  29:             }

  30:         }

  31:  

  32:         public void SendAdminMessage(string msg)

  33:         {

  34:             foreach (var twit  in BreakToTwitts(msg))

  35:             {

  36:                 var dm =

  37:                 FluentTwitter.CreateRequest().AuthenticateAs(account, password).DirectMessages().Send(admin, twit).AsJson();

  38:  

  39:                 Retry(2,dm.Request,false);

  40:             }   

  41:             

  42:         }

  43:  

  44:         private IList<string> BreakToTwitts(string originalString)

  45:         {

  46:             var list = new List<string>();

  47:             for (int i = 0; i < originalString.Length; i += 140)

  48:             {

  49:                 var len = 140;

  50:                 if (originalString.Length - i < 140) len = originalString.Length - i;

  51:                 list.Add(originalString.Substring(i, len));

  52:             }

  53:             return list;

  54:         }

  55:  

  56:         private void Retry(int retries, Func<string> call,bool shouldThrow)

  57:         {

  58:            

  59:             try

  60:             {

  61:                 call();

  62:             }

  63:             catch (Exception ex)

  64:             {

  65:  

  66:                 if (retries > 0)

  67:                     Retry(--retries, call,shouldThrow);

  68:                 else

  69:                 {

  70:                     if (shouldThrow)

  71:                         throw;

  72:                 }

  73:             }

  74:           }

  75:           

  76:         }

  77:     }

  78:  

  79: }

"The SOLID principles are not rules. They are not laws. They are not perfect truths. The are statements on the order of “An apple a day keeps the doctor away.” This is a good principle, it is good advice, but it’s not a pure truth, nor is it a rule.

The principles are mental cubby-holes. They give a name to a concept so that you can talk and reason about that concept. They provide a place to hang the feelings we have about good and bad code. They attempt to categorize those feelings into concrete advice. In that sense, the principles are a kind of anodyne. Given some code or design that you feel bad about, you may be able to find a principle that explains that bad feeling and advises you about how to feel better."

       private void EventSender(object state)
        {
            var id = (Guid) state;
            try
            {
                    sagas[id].Dispatch();
            }
            catch (Exception e)
            {
               
                Logger.DebugFormat("EventSender: Exeption Details={0}",e);
                rwl.TryRLock();
                var isClosed = true;
                if (sagas.ContainsKey(id))
                    isClosed = sagas[id].IsClosed;
                rwl.ExitReadLock();

                if (!isClosed)
                    HandleSagaFault(id);
                
            }
        }

            try
            {
                rwl.TryRLock();
                var isClosed = true;
                if (sagas.ContainsKey(id))
                    sagas[id].Dispatch();
                rwl.ExitReadLock();
            }

bool raisedEvent = eb.RaiseEvent<SampleEvent>(new SampleEvent());

var evnt = new SampleEvent { data = somevalue};
var SagaId = Guid.NewGuid();
eb.RaiseSagaEvent<SampleEvent>(SagaId, evnt);

    public class SampleClassEvent :ImEvent
    {
        public string DataMember1 {set;get;}
        public int DataMember2 { set; get;}
    }

    [ServiceContract]
    public  interface IHandleSampleClass
    {
        [OperationContract]
        int  SampleClass(SampleClassEvent eventOccured);
        
    }

    [ServiceContract]
    public interface ImSampelResource : ImContract, IHandleSampleClass, IHandleSomeOtherThing
    {
    }

The bottom line: Languages like Java give you an object protocol: There is one way to do things with objects and classes and interfaces, period. Anything else, like adding generics or annotations, must be done outside of the language, it must be done by the creators of the language.

Languages like Common Lisp and Smalltalk give you a meta object protocol: You can decide for yourself how to do things with objects, classes, interfaces, generic functions, whatever you want. You don’t need to wait for a committee to try something different.

What if programming language implementations were object-oriented? What if you wanted to change one itty-bitty part of your favorite language? Say you wanted to add an exponentiation operator (^^). How hard would it be?

Wouldn't it be nice if you could "subclass" a language like C# and then add 5 lines of code to make it work and then use it? What if you could add Ruby-like method_missing support in 20 lines?

What if you could conceive of a new language and start experimenting with it in production code in an hour? What if it leveraged your knowledge of existing frameworks like .NET?

"The big takeaway from this litany of verbal spillage is when you design
applications you have to know how the end-user is going to use the
application and what the business requirements are.  Sitting down and
building an elaborate object model, while really fun and educational,
it is a big waste of time.  Don't do it.  Sit down and ask questions so
the behavior and business requirements can be accounted for.  Whether
you are using CSLA.Net or not the same thoughts must go into building
the application.  I hope this helps cements these concepts because I
know there is a large amount of disconnect with this out there among
developers who think everything is a perfect object graph like they
learned it in school. "

1. The "elaborate object model" Keith talks about has nothing to do with OOP.
   
2. Keith just drafts an "elaborate object model" but fails to note that it is a "Problem Domain Object Model" (PDOM) and a bad one at that (since it wasn't built with a domain expert involvement). The role of a PDOM is to form an initial working vocabulary with domain experts. It is usually a big mistake to use it as a foundation for development
3. Even as a PDOM and even considering it was built for the sake of argument, it still doesn't make sense to create a class for each type of dog. When you create a sub-class you need to have a new behavior not a different value in a property.
   
4. The example of the client side objects which do not match business side objects doesn't prove anything. client object (esp. search dialogs) tend to cross or aggregate domain boundaries. You can still have a meaningful OO domain model running in a backend.
5. The fact that the search screen aggregates data from multiple domain object doesn't mean that the other processes and screen don't use that but from the application type at hand I would bet that most of the screens only deal with CRUD which brings me to another point:
   
6. Another consideration Keith fails to mention is the type of application at hand. For the example given. It is probably a viable option to develop the whole thing as an Access application with embedded SQL in the controls. no OO and and no nothing.
7. In any event. It seems to me Keith doesn't provide enough requirements to justify either of the solutions

"However, there is one possible pitfall to this approach, as it makes this code possible:
Singleton obj = Singleton.Instance;
MyClass obj2 = new MyClass();

While I personally like the idea of having the freedom to use the same class in two different ways throughout the application, I know some people like their Singletons - well, single.
On the other hand, if you write a class from the start as a Singleton this is not an issue.

There is an inherit risk in decoupling a class from it's expected behavior, so take this into consideration before using this pattern."

"don't believe discoverability was a motivation for Singleton. The purpose was to ensure only one instance existed (a print spooler, a file system). You can get discoverability through the technique you explain but the primary purpose of singleton was a pattern of prohibition - to stop a programmer doing something they shouldn't do by accident by enforcing the primary goals of single point of access.

It is more than a global, and the OP, while comparing them to globals, does not acknowledge that this solves many of the problems which made "global" a 4-letter word. Knee-jerk reaction against globals is not healthy once you've mitigated their drawbacks.

It is true that usage of singleton can be misguided and cause coupling - which is why you need to ensure that the usage of the pattern matches the motivation in the first place.

This is a key point of design patterns which Alexander should have made clear in http://en.wikipedia.org/wiki/N...is_of_Form - the pattern is a result of a resolution of system of forces. It only satisfies that system - moving it to another different system will result in poor fitness. "

"design patterns are a sign of a deficiency of a language for the purpose that the design pattern addresses. In other words, the Visitor pattern used in Java points to the fact that Java is deficient in terms of list processing: the `map` and `filter` constructs need to be emulated with lengthy OO incantations."

1. The pattern is needed
2. The solution in the pattern is the best one for the language.
   

"Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template method lets subclasses redefine certain steps of an algorithm without changing the algorithm strucuture"

    class Program
    {
        static void Main(string[] args)
        {
            var alg = new Algorithm();
            alg.DoSomething(Funky);
        }

        static bool Funky(string value)
        {
            return value == "somevalue";
        }
    }


    class Algorithm
    {
        public void DoSomething(Func<string,bool>CanGoForward)
        {
            string someVariable = "somevalue";

            if (null!=CanGoForward && CanGoForward(someVariable))
            {
                //do one step
            }
            // whatever
        }
    }

" The Volta technology preview is a developer toolset that enables you to build multi-tier web applications by applying familiar techniques and patterns. First, design and build your application as a .NET client application, then assign the portions of the application to run on the server and the client tiers late in the development process. The compiler creates cross-browser JavaScript for the client tier, web services for the server tier, and communication, serialization, synchronization, security, and other boilerplate code to tie the tiers together.

Developers can target either web browsers or the CLR as clients and Volta handles the complexities of tier-splitting for you.  Volta comprises tools such as end-to-end profiling to make architectural refactoring and optimization simple and quick. In effect, Volta offers a best-effort experience in multiple environments without any changes to the application."

Objective

We have an application that runs in a monolithic environment, say the browser. We want parts of this application to run in other environments, such as servers. We don’t want to litter the application with plumbing code.

Rationale

The standard techniques for distributed applications infuse our code everywhere with information about what parts run where. This makes the code hard to change. Typically, once we make these decisions we can’t change them because it is too expensive. However, environments, requirements, and performance profiles change and we’re stuck with applications that can’t adapt to new realities. We need to separate the concerns about what the application does from the concerns about where parts of the application run.

Without Volta, we are forced to decide where code runs before we know everything it is going to do, in particular before we know the communication frequencies and delays. Development methodologies force us to make irreversible decisions too early in the application lifecycle. Volta gives us the means to delay decisions until we have adequate information to base them on.

Recipe

Volta tier splitting automates the creation of the communication plumbing code, serialization, and remoting. Simply mark classes or methods with a custom attribute that tells the Volta compiler where they should run. Unmarked classes and methods continue to run on the client.

We may base our decisions about tier assignment on any criteria we like, such as performance or location of critical assets and capabilities. Because Volta automates boilerplate code and processes for dispersing code, it is easy for us to experiment with and change assignments of classes and methods to tiers.

"...back in 2003, mainstream platforms typically used a distributed object approach to building distributed apps. Distributed objects were widely implemented and fairly well understood. You created an object like normal, but the underlying platform would create the actual object on a remote machine. You'd call functions on your local proxy and the platform would marshal the call across the network to the real object. The network hop would still be there, but the platform abstracted away the mechanics of making it. Examples of distributed object platforms include CORBA via IOR, Java RMI, COM via DCOM and .NET Remoting.

The (now well documented and understood) problem with this approach is that distributed objects can't be designed like other objects. For performance reasons, distributed objects have to have what Martin Fowler called a "coarse-grained interface", a design which sacrifices flexibility and extensibility in return for minimizing the number of cross-network calls. Because the network overhead can't be abstracted away, distributed objects are a very leaky abstraction.

"We will be partnering with Don Syme and others in Microsoft Research to fully integrate the F# language into Visual Studio and continue innovating and evolving F#. In my mind, F# is another first-class programming language on the CLR. "

• Leadership. Influencing others to accomplish tasks and following your guidance
  
• System thinking. Understand decisions and constrains in the
  wide scope pertaining to whole of the solution at hand. This includes
  the ability to abstract problems.
  
• Strategic thinking. Understanding decisions and constrains and their alighments to the overall business of the company.
  
• Organizational politics. Understand the environment you operate in and how it influences you.
  
• Communications. Making sure you get your point across.
  
• Human relations. Understand the "people" aspects or human
  factors and dynamics. This includes things like negotiation, pragmatism
  etc
  

• Negotiation/Persuation - Anything based on "Getting to yes","Getting past no" and "The power of a positive no" should be fine.

• Presentation Skills - While getting the architecture and technology right is what matters, if you can't explain it to the different stakeholders you're toast.

• Strategic Planning - This has to do with the vision thing I expect architects to manifest. Note that having a vision should not be confused with future-proofing a solution. future-proof means excess work not needed. Having a vision is knowing where you want to end - it can still be perfectly valid to completely re-write your applications along the way

• Architecture Evaluation - workshop 2-3 days - It is probably worthwhile to delve a little on scenario based evaluation techniques such as LAAAM and ATAM. While I prefer evaluating architecture in code, the scenario based thinking is very valuable for eliciting architectural requirements
• Distributed Systems Architectures workshop - I'll expand on this in the next post

Having just read Doron's Yaacoby's post on some of the insights he got  from reading Tom & Lister's Peopleware, I'd thought I'd repost a couple of posts I wrote about a year ago in my Dr. Dobb's Journal blog (with a few edits):

I just finished reading Software Conflict 2.0: The Art and Science of Software Engineering, by Robert L. Glass.

This is a reprint (with few new retrospective additions) of his 1990 book. While the technology mentioned in the book is outdated, many of the author's ideas and views are still valid. The book is a collection of short articles on various subjects, and one of the more interesting articles is about the cognitive side of design.

Glass explains that research done showed that design includes the (obvious) steps of understanding the problem, decomposing it into goals and objects etc. The essence of design, however, are the mental steps taken by designers:

1. They construct a mental model of proposed solution
2. They mentally execute the model (i.e. simulate the model to see if it solves the problem)
3. If the model isn't good enough (e.g., too simple) replay the simulation to find what wrong and remodel
4. Repeat 1-3 until the model seems to solve the problem

Glass also said that people tend to start with a model that worked on a similar problem and that good designers perform this process extremely fast. As I was thinking how one can train himself to get better at performing this task, it occurred to me that I heard something similar  somewhere... While not the exact process this is very reminiscent of TDD - only TDD makes the process explicit. In a way we can say that TDD will not only help make your design better it would also  trains you to design better altogether.

• Peopleware Second Edition by Tom Demarco and Timothy Lister (Second edition 1999, original 1987). Development should be centered on people and not on methods

• The Mythical Man-Month: 20th Anniversary Edition by Fred Brooks (20th anniversary edition 1995, original 1974). "No silver bullet" don't just add people to a late project it will only slow it down and many more.

• Code Complete by Steve McConnell (Second Edition 2004, original 1993). A great book on coding.
  
  
• An Introduction to General Systems Thinking (Silver Anniversary Edition) by Gerald M. Weinberg (silver Anniversary Edition 2001, original 1975). Observations on thinking processes
  
  
• About Face and About Face 2.0 (3.0 edition 2007, 2.0 Edition 2003, original 1995). UI mistakes and guidance, the second edition also details a scenario based approach to user experience design.
  

Getting back to TDD or at least the idea of test first. It seems (via Rob Keefer pomiet blog)  Gerald Weinberg talked about it more than 35 years ago in  Psychology of Computer Programming :

"By pursuing this test example to the point where he understands the problem, he will not only learn the one thing he did not know, but perhaps will learn others as well, for test programs such as this are often better learning instruments than are production programs.

As a matter of good practice, the test program should be constructed before the 'fix' is made to the production program. In the first place, there will be an all too human tendency to forget about the problem once the production program is working correctly, so we must impose a little discipline on ourselves. Possibly more important, however, is the chance that by the mere act of constructing the test case we shall discover the problem."

"The REST architectural style defines a number of basic rules (constraints), and if you adhere to these rules, your applications will exhibit a number of desirable characteristics, such as simplicity, scalability, performance, evolvability, visibility, portability, and reliability.

The basic rules are:

• Everything that's interesting is named via a URI and becomes an addressable resource
  
• Every resource exposes a uniform interface (e.g., GET, PUT, POST, DELETE)
  
• You interact with the resource by exchanging representations of the resource's state using the standard methods in the uniform interface

"

"Regarding the issue of extending classes (and partial classes) I am very sorry it was ever invented. Developers should be encouraged to divide large classes by decomposing them into decoupled sub-components using design patterns and not by simply splitting them between files. Even though a feature is called "extending" a class it is in violation of the Open Closed Principle..."

Modules should be both open (for extension and adaptation) and closed (to avoid modification that affect clients)

It is easy to see the benefit of having a class that answers this principle: When you need to add a requirement, instead of breaking dependent code (and tests) you just extend it somehow and everything is nice and dandy. Furthermore, violating OCP can result in Rigidity,Fragility, and Immobility.

But how do you do that? The obvious (and naïve) answer is inheritance. Every time something needs to change just add a sub-class. The parent class is not changes and voilà. However, if you add sub-classes all the time you'd get "lazy classes" or freeloaders--sub-classes without a real reason for existence not to mention a maintenance nightmare.

Thus, sub-classing is an option but we need to consider carefully where to apply it. Other (more practical ) OCP preserving steps include:

• Marking class fields as private


• Not adding getters/setters automatically. You may want to read "Why getter and setter methods are evil" by Allen Holub, and Martin Fowler's rebuttal/refinement in "Getter Eradicator".
  
• Inversion of Control strategies
  
  
  
  • TemplateMethod pattern
  
  
  • Strategy Pattern
  
  
  •  Anonymous delegates (in C# 2.0) and Closures in dynamic languages (also in C# 3.5)


• And don't forget to hide implementation details behind (stable) interfaces

class Foo
  def bar
    puts "foo.bar"
  end
end
   
obj = Foo.new
obj2 = Foo.new
def obj.bar  # redefining bar just for obj
  puts "foo.newbar"
end
obj.bar   # prints foo.newbar
obj2.bar # prints foo.bar

class Foo
  def bar(myProc)   # accepts a callable object
    foobar = "foo.bar"
    myProc.call(foobar) # call the object with a parameter
  end
end
   
obj=Foo.new
printer=Proc.new {|msg| puts msg}

obj.bar(printer)

class Foo
end
   
obj=Foo.new

# obj.bar - error
Foo.class_eval do           # this simplistic example can also use regular def
    define_method :bar do   # but class_eval can also evaluate strings to create
      puts "foo.bar"        # dynamic methods like setters etc.
    end
end

obj.bar

"Identify points of predicted variation and create a stable interface around them."