Arnon Rotam-Gal-Oz talks about: ”Architect Soft Skills”

This is a very interesting article about the non technical skills an Architect should have: http://www.rgoarchitects.com/nblog/2008/10/26/ArchitectSoftSkills.aspx

Go ahead and read it.

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 :)

   
Basic tools:

• Visual Studio 2005 / 2008 I can’t remember last time I used Visual Studio 2003
• ReSharper, I want this everywhere, Gøran I would suggest you really try this one out
• SQL Server Management Studio 2005 / 2008
• Visual Studio Ruby Blue color scheme. I am not happy with how it presents xml related content (I’ll change that some time), but the code view is great for the eyes.
• NUnit
• Rhino Mocks
• Reflector
• Castle Windsor
• NServiceBus starting to use this
• Paint.Net
• PhotoShop
• Notepad it is surprisingly how often I use this.
• TortoiseSVN

Continuous Integration:

• CruiseControl.Net
• NAnt
• MSBuild.exe
• SubVersion
• WiX
• TFS

Information sources:

• Google
• Many many blogs via Google Reader

Currently looking into while reading “Building Domain Specific Languages in Boo”:

• Boo
• Specter
• SharpDevelop

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) :)

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

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!

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 :)

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 :(

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.