Tuesday, October 23, 2007

AOP vs IoC/DI???

An explanation to a colleague today that may be easier to understand than the typical ambiguous answer that he had recieved: "oh yeah its when you want to shove something in from the side"

AOP is different to IoC or Dependency injection (which is what Object Builder is) and can be used in conjunction with it.

IoC lets you code to interfaces and create object instances at runtime by calling the IoC Container (or dynamic factory) at runtime with the string key or Interface, to give you a concrete implementation of that interface (or sometime base class).

Spring.net and Windsor/Castle are the most popular open source IoC Containers and they both kind of do AOP as well, but it’s a bit convoluted.

Most people use AOP for “cross cutting concerning”, things like Logging, Security, Exception handling where you want a standard way of handling these things up and down the stack. The problem is that often at each tier, or even layer you get different people doing different things and it also mean you have code bloat like:

Public void MethodX(Type1 param1, int param2)
{
Log.(“enter MethodX);//Logging
Check.UserCanDo(MethodX);//Security
Try
{
Check.Ensure(param1 != null,”param1 can not be null”);//DBC
Check.Ensure(param2 > 10,”param2 must be greater than 10”);//DBC
… //Business logic
}
Catch(ExceptionY ey)//Exception handling
{
GlobalExceptionHandler.DoStandardExceptionHandling(ey);
Throw;
}
}

Where that whole thing can now be refactored to:

[StandardPublicMethodAOPHandler]//Logging, Security, Exception handling
Public void MethodX()
{
Check.Ensure(param1 != null,”param1 can not be null”);//DBC
Check.Ensure(param2 > 10,”param2 must be greater than 10”);//DBC
… //Business logic
}

Even better you can put that attribute on the method/class/assembly and then the normal devs don’t even have to worry about following standard procedure and code is a whole lot easier to read.

HTH. :)

Using AOP

I have been dodging AOP for a while now for the main reason that is "Looks to hard", especially when you have to explain it to PM's and other dev's who are still trying to get to grips with basic IoC and ORM concepts, after all projects are not solo efforts.
However I have now found a nice looking framework that may help.
PostSharp is an Attribute driven lightweight AOP framework that modifies the IL as a Post build event in the .Net framework.
This article here has got me very excited about implementing standardised Logging, Security, Exception Handling and maybe even Design by Contract.

Once i get my home development PC back from the dead I will post more about how easy it is (or isnt) and how it affect the project at runtime.
Should be interesting.

Friday, October 19, 2007

..made me laugh

I just got an email from Lloyds TSB (a bank) that I opened an account with weeks ago to say my online account is ready.

Yours sincerely,

Anita Hockin

Anita Hockin
Head of Internet

Head of Internet... that's an awesome title! She will however be getting emails from me when my wifi/browser stops working or when I cant log in to face book hehehe

On a side note, what took Lloyds TSB 6 weeks to do it took HSBC 1 day to do. It took 40 minutes from walking in the door to having 2 personal accounts, 2 business account and a credit card set up. I cant see me dealing with LTSB too much more...

Wednesday, October 17, 2007

Infragistics Controls

There are some time where a defined and limited structure is a good thing.
There are some time where a bit more flexibility is a good thing.
Then there are time when a blank canvas is ideal. I think Infragistics has gone for the third option.

I have been doing some UI work with the Win forms arena and the project i am on is using the Infragistics controls. I have no problem with that, at least they have define a UI standard in that regard. what i have problem with is just trying to find the most trivial operations on what should be basic controls.

I assume the Ultra Grid to be very flexible and somewhat insane as far how many methods and properties that are accessible... but a drop down list does not need to have that many options.

If it does, then a good idea would be to follow the basic MS naming standards so developers can find the appropriate properties/methods/events with out having to trawl through the slew of options intellisense give me... its been painful to say the least.

I cant see me buying the package for home any time soon.

Friday, October 12, 2007

"Public" API's

I have for along time prided myself on writing code that other developers would want to use. It was my brother that actual gave me that definition of good code and i think it is a good way to think of how to write code.

I have recently been using "legacy" code and am constantly amazed that none of the public methods /classes are commented or documented or have argument checks. What I find slightly amusing is the screeds of code that is commented out in certain code files. I have no problem commenting out code while running test etc, but delete before you check it in, that's what source control is there for! Certainly do not release code with all that crap in there...

If you write c# in the .Net framework you probably use VS. Turn on FX cop.
For gods sake its there to make you a better coder, not to just randomly show arbitrary message at the bottom of your screen. If i am working on a project i prefer the set warning to errors from the start, then the code stays clean.


Use ReSharper. Your code will be cleaner. I am the only one using it at my current place of employment and the HUGE amount of redundant code that shows up is unbelievable! It may go a way to explaining why after 14 week the U.I. was still not up and running.


Use GhostDoc. Its makes commenting a completely trivial task and also helps you name methods in a more appropriate manner. If I notice the comments don't make sense then instead of rewriting the comment I now rewrite the name of the method till the comment makes sense. The more you use it the less this occurs.


Check your arguments on all public methods. This is call Design By Contract. I basically check everything that isn't a Boolean.

These things all reduce the chance of you being one of those developers... the one that i curse at as i work with their code.

Look at your code.
Is it clean to look at, with out even reading it?
Can you, at any stage, generate meaningful documentation from your code?
Do you know off the top of your head what the code coverage is likely to be on your current coding project (assuming this is greenfields)? Is it appropriate?

Some colleague I have worked with think this is Gold Plating.
Bullshit. We get paid good money to do our job.
Number one priority is to develop working code on time, sure.
But I believe, certainly as a contractor who may never be seen again, it is also my duty to make it as easy and intuitive for the next guy, of whatever ability, to use, re factor, debug and modify my code.
These practices do not deter from our number One priority. In fact I have found the above implementations, along with TDD, usually mean that you are more likely to handle code once and not have rummage through it again later looking for bugs. And if you do, I guarantee it will be a lot faster than if you had not put these practices in place.


* certainly since I have been a contractor!

Monday, October 8, 2007

Still catching up..

Since I have been in the UK I have been trying to get back up-to-date with everything going on in the Geek world.

this has to be one of the big ones:
Releasing the .net source code!!!!

Holy cr@p!

Friday, October 5, 2007

VSS 6.0

Visual Source Safe sux.
It sucks ass.
It is a big pile of crap and I hate it.
Its up there with a poorly implemented Perforce.

Please bring me back to TFS...

Monday, October 1, 2007

Geek speak to Layman terms

Often I forget that the typical developer is not that well rounded; We are geeks and not all us have the best social skills. This article highlighted in a readable way, how you could articulate this to your geek team:
Can Your Team Pass The Elevator Test?

Something I think all employees should be able to do, especially in small agile* software houses in which your end developer may/probably will talk to the end client.

*agile in the true sense not necessarily the methodologies...