Saturday, October 25, 2008

What tools I use when developing software

Gøran Hansen was so kind to tag me with a question what kind of tools I use when developing software. Well looking at his post and at Lars Wilhelmsen, who started this series, post I am not so much a tools kind of guy I guess :)

The new .Net Framework logo   Yay ReSharper

Basic tools:
Continuous Integration:
Information sources:
Currently looking into while reading “Building Domain Specific Languages in Boo”:
As for tagging others, I wouldn’t know who to tag, so I tag every reader of this blog :) (that should get at least two or three geeks) :)

Tuesday, October 21, 2008

Crack.Net by Josh Smith

Catchy name for a debugging tool :)

Ever needed to fix a bug that didn't happen on you development machine, but does in test (or production, but the disclaimer clearly states not to use it in production ;) well now you can try this new tool. It injects itself in a running .Net application and allows you to browse and change the objects in the managed heap of that _running_ application.

http://joshsmithonwpf.wordpress.com/2008/10/21/new-release-of-cracknet-on-codeplex/
http://joshsmithonwpf.wordpress.com/cracknet/

A more detailed article about Crack.Net

http://joshsmithonwpf.files.wordpress.com/2008/10/cracknet-article1.doc

-Mark

Thursday, October 16, 2008

James Kovacs talks about ” Roll-Your-Own IoC” on dnrTV

Here is a very interesting video about Dependency Injection (DIP), Inversion of Control (IoC), Test Driven Development (TDD) and how to write your own simple IoC container. And along the way you'll see some cool R# tricks. This is one of the basis NDA stands on and this is a really clear and easy step through conversation on how to implement DIP, and understand the ideas behind it.

http://codebetter.com/blogs/james.kovacs/archive/2008/10/15/dnrtv-episode-126-roll-your-own-ioc-with-me.aspx

Go Watch it!

Friday, October 10, 2008

My ToDo list

I have too many projects right now:

  • Currently reading “Building Domain Specific Languages in Boo” from Ayende Rahien. This is a very interesting book and I’ll definitely write some blog posts about that.
  • NDA, thinking what the next post should be about, I like to explain by example so finding a good example is the next step.
  • A friend of mine is creating a new design for my blog; this is becoming very cool, not as corny as this current look (I don’t dare calling the current one a design).
  • Converting the new blog to Community Server Express edition
  • Unit testing XAML definitions, I need to finish that.
And these are only the technical projects that I am talking about; there is also the family :)

Wednesday, October 1, 2008

New design of my blog

I just created a quick new design for my blog because I didn't like the way the Blogger templates look. So let me know what you think. I am also looking into the free version of Community Server, but those guys take more than 2 day to send me a download link :(

Monday, September 29, 2008

Is NDA in conflict with YAGNI?

I got a question on my previous post (The No Dependency Architecture (NDA)) if NDA is not in conflict with YAGNI, and when I was writing the response it became more or less an actual post, so there you go :)

Explaining the thought behind the No Dependency Architecture (NDA) in combination with YAGNI in one sentence would be something like this: “You anticipate change at a technical level, not at a functional level”.

I believe that the “You Ain’t Gonna Need It” (YAGNI) principle does not imply that writing software accordingly to the SOLID principles is bad practice. When you are following these principles (and there are others that are good to follow too) then you are writing software that assumes change, right? I believe that YAGNI is more targeted to functional overhead.

I.e. using a IoC container to fulfill the Dependency Inversion Principle (DIP) is not in conflict with YAGNI because that is at a technical level, but when you are writing extra code for no other reason than that you assume the object might be used in a certain other way also, then you are violating the YAGNI principle because then you are creating additional functionality that is not needed.

From Wikipedia ( http://en.wikipedia.org/wiki/You_Ain't_Gonna_Need_It) YAGNI, short for 'You Ain't Gonna Need It', suggests to programmers that they should not add functionality until it is necessary

So I would recommend using the various SOLID principles when writing your software assuming things will change because that is just good practice. Change is a fact, we just don’t know what will change, but by conforming to SOLID we can handle these future changes without too much headache.

As to using an Event Driven Architecture, I am surely not saying each object should only interact using events, that would not make much sense, but most (larger) systems will be build up using multiple sub systems. Having these sub systems communicate via events is a very good way to isolate them from each other. Then it is unknown to each sub system who they are really talking to (i.e. dispatching the events to). In fact it is a 1 to n relationship where the dispatched event might have no, one or many subscribers.

To make the actual handling of subscribing and publishing easier you could use a service bus that deal with that for you. This will also make the system easier adaptable to change. You can also specify that the event can be handled by any instance of the same subscriber enabling load balancing.

“Don’t call us, we call you” ( http://en.wikipedia.org/wiki/Hollywood_Principle); is the basis of an Event Driven Architecture, and this is very true, because no system is waiting on an answer from another system. They fire events and they act on events, it is merely coincidence if these events have anything to do with each other.

So I would also recommend using an Event Driven Architecture (EDA) straight from the beginning, perhaps not using a service bus from the start, but just using EDA will make refactoring to use one at a later stage a lot easier.

Thursday, September 25, 2008

The No Dependency Architecture (NDA)

We already have many, many, many acronyms in our profession; TDD, BDD, DDD, SOA, EDA, DIP and SOLID just to name a few. So who am I to add yet another one in the mix, well I am a nobody. Having covered that, I would like to continue explaining this new one.

NDA is a software architecture that has no dependencies between the different components. It’s all in the name :)

By combining the Dependency Inversion Principle (DIP) and an Event Driven Architecture (EDA) we can achieve software that has no dependencies, not internal not external. So why would we want that? Well it enables you to just replace any part in your software solution with something else without it affecting the rest of the solution. And you will be able to scale the solution much easier.

So let’s look a bit more into the details, first I would like to start with DIP. Dependency Injection can be achieved using an Inversion of Control (IoC) container. An IoC container will provide an already instantiated object that (when done properly according to DIP) is based on an interface. The consumer of the object is only using the interface and does not know anything about the actual implementation.

One simple rule about how to provide the dependent objects is that when the consumer object cannot work without the dependent object it should be provided in the constructor of the consumer object; if the consumer object can continue without the dependent object (i.e. logging module) than that object should be provided via a setter property of the consumer object.

Modern IoC containers can Auto Wire the dependencies when creating an object, meaning that if a object of the requested type is present in the configuration you will not have to specify the dependent object in the constructor arguments of the consumer, this will be done automatically. I am a fan of keeping the configuration of the IoC container in a configuration file, this way I can easily provide a different implementation of the requested objects by just changing the configuration file. No need to recompile anything. I currently am working a lot with Castle Windsor which is a great IoC container.

So this should take care of dependencies your code may have between other parts of your code (i.e. object between object). Now we can move on to try and get rid of dependencies between different systems or major parts of your system (i.e. between services and consumers). When using an Event Driven Architecture your code is basically sending out events when something happens and does not care who or what is acting on those events. Different systems may subscribe to these events and may do their own thing. And to take this one step further you should consider using a service bus architecture, which basically means that events will be published into a cue. Consumers of these events subscribe to the cue and will get notified whenever there is an event waiting for them. There can be as many consumers subscribing to the events via the service bus as needed. The publisher does not know nor care about the consumers; it fires the event and moves on. Consumers don’t know or care about the source of the event, just that it is the type of event they are interested in.

As you can see this decouples the different systems from each other, since none of them know about each other there can be no dependencies between each other. Currently I am looking into NServiceBus, I got a real nice demo today from my college John that started this current thought process.

So now I believe we have a system that does not depend on anything, well realistically it depends on things, but these things can be switched, replaced, multiplied and even be offline nobody knows. I plan to go over these different parts in the coming posts, so if you have any comment I would love to hear from you.

Castle Windsor http://www.castleproject.org/container/index.html
NServiceBus http://www.nservicebus.com/