Simple reusable DTO factory methods

I have just found a little bug in my app that to me was an issue with code duplication. It was a DTO not getting properly hydrated when is was getting translated from a domain object in the service layer. My DTOs are just objects with auto properties, no business logic methods; just data carriers. I sometimes have the need for a basic DTO with just simple info (ie for Lists) and a more detailed DTO with the objects child collections (as DTOs collections) for more detailed views. The problem I had was when I added a field on to the domain object then had to modify my factory (and test) to ensure the new field was mapped. What I forgot to do was to also do it for my detailed DTO. I wtote the test and realised that I was doing the exact same work in 2 places, which was one of the reason behind the bug. As i prefer not to use anything other than a default constructor for DTOs i was in a bit of a quandry. Other than using JBogard's AutoMapper i was not sure how to tackle this.
My goodness, i may actually have to engage my brain!
Well the result was incredibly simple.
The detailed DTO (xyzDetailedDto) inherited from the normal DTO (xyzDto) so i just created a private generic factory method in the publicly exposed Extension method class

private static T Create(xyzDomianObject domainObj) where T : xyzDto, new()
{
return new T
{
Id = domainObj.Id,
Name = domainObj.Name,
Details = domainObj.Details,
OtherThing = domainObj.OtherThing
};
}

As xyzDetailedDto inherited from xyzDto I could reuse the creation method and get back the correct type.
This all seems very simple and silly now, but this has drastically cleaned up my translation layer :)

Technical Competence and the Interview Process

As I begin the job hunt all over again I am renewed with the realisation that sales skills, although possibly only rarely used in day to day coding, are as important as ever. Over the last 2 days I have been talking with friends, former colleagues, recruiters, HR and connections from all of the above in the Perth IT market regarding jobs.
The people who dont know me just want to to know what in vogue technical skils I have. Buzz wordy stuff that pass with the wind like WPF, MOSS, Asp.Net MVC etc etc
These technologies are all great at helping us do our job faster, prettier and more consistently but they only HELP. Core coding concepts, IMO, are of a much greater importance. I am not a WPF guru. Can i learn it? Bet your ass I can, in fact I am now. I give myself 6 weeks to do so and to be come good at it. Why six weeks? As I have been around the block a few time i have picked up a few technologies, API's & languages over the time. What i find is the more technologies, API's & languages I learn, the faster I can learn the next one. There is such a thing as "learning to learn".
In the past 2 years I feel I have become a much better developer in general.
Alot of that knowledge has come from reading the dozens of books and thousands of blog/forum posts, watching multitudes of videos and seminars and attending and presenting gigs like the Alt.Net open spaces... basically all the things that have stolen quality time from my friends and loved ones. Alot of that knowledge has come from using 3rd party API's that both kick ass (like StructureMap) and suck (like Infragistics). You learn from both, however it is with continuual exposure to new APIs that you are exposed to overall patterns and styles that you begin to associate as good or bad.
for example: Over the last couple of weeks I have found myself talking to a few friends and colleagues about the Law of Demeter. Infragistics is a perfect example of why this law (or guideline) exists. Having 5 properties chained off to change a setting in the grid is stupid and shows poor API design. Having not used this API i may not have "got" that specific law (lemons => lemonade). ;)

Learning languages like Python, Boo, F# and Ruby highlight the strengths and weaknesses of my own day to day language C#. It also highlights the fact the Java, VB.Net and C# (or whatever other c based managed language) are basically the same and people who argue between C# over VB.net or Java over VB.net need to learn a new language. Possibly they just mean they believe the .Net framework or libraries are better than java (or vica versa etc) and don't realise it.
Anyway...
Having been in the position of the interviewee and interviewer now I can see what I look for is basically the opposite of what recruiters look for... well to a degree. I assume by the time the candidate has got to me the recruiter has figured out the candidate has
-used .Net for a number of years
-has used the basic technology we are interested in (win, web, services, messaging etc)

What I look for is if the candidate has just done the one technology, eg just Asp.Net over WinForms for example. I mean they can not help that their employer dictates that what they used, but they can, in their own time, investigate other angles. In this instance i would also ask
-Have you used an MVC framework such as Monorail or ASP.net MVC?
-When did you use it and which version?
-what did you find different/better?
-Did you ever use it in production?
-have you used JSP, Ruby on Rails or Groovy on Grails or any other web based framework in another language?
-What CMS's have you used... etc etc
I don't care really what the answers here are, I am just fishing to see if this guy is a 9-5er or someone genuinely interested in his job. A 9-5er would take what the boss has given him and stick with it. Someone serious about their job investigates things outside of his comfort zone and finds out why this alternative exists and evaluates if it can help him perform better.

I also look for basic OO skills. If the candidate has never used Asp.Net but has ninja coding skills and is passionate and enthusiastic I would take him on. I can teach a monkey Asp.Net in 3 weeks. I cant teach enthusiasm. By that notion i also look for the knowledge of test and mock APIs and the use of framework libraries (e.g. castle and spring) as they tend to show the candidate understands the benefits and quality of code that can come with using such a tool.

Unfortunately this logic does not bode well with recruiters who want to pattern match. So the sales hat goes on to please the gate keepers. My problem is I wont lie to get a job. It has probably cost me some pretty kick ass roles/pay packets but, you still have to look yourself and co-workers in the eye everyday. The problem is the recruiters encourage it. My tack is to try and sell the global picture, its just not that easy. The same is true for interviews with non technicals such as PMs. They don't care if i know the intricacies of 5 different IoC containers, they want to know if I delivered production ready software on time, and so they should! However they still have the notion of patten matching. My lack of an ultra specific skill may have cost me a job yesterday (you will never guess what that skill is!). The problem is the guy would have given the job to someone of much lesser ability who had the the skill listed on his resume in a previous job. He has been hunting for months for this person... which to me would mean alarm bells ringing if I was him. If i fell in to that situation i would look for good people that you can train. If the good person has the skill set, awesome! If not, get the best you can and train them, FAST.

Fortunately I know people in the market and luckily I haven't burnt any bridges and have forged some pretty good relationships here in Perth. Which is lucky, because Perth is a small very well connected network. So hopefully mouths start moving and the word gets out that a new developer is in town ;). Otherwise I may follow a good friends advise and make it a leisurely summer of freelance development and lying on the beach, corona in hand.... things could be worse ;)

I would like to hear other comments from others... from the perspective of both the candidate and the employer.

cheers
Rhys

Projects measuring success..

Nice post
http://leecampbell.blogspot.com/2008/08/projects-measuring-success-and.html

Assembla.com

We have just registered with Assembla.com to manage our international project code base. I wasn't expecting much, assuming
A: we were paying for it and
B: it would just be an SVN repository.
I have been pleasantly surprised (as both those assumptions were wrong). We are still kicking the tyres but the project management and code check in facilities are nice and clean, not a lot of clutter and provide the experience that i really wanted.
I can see this being a great way for Nick, Gum and I to get working together remotely and getting our code all playing nice. I would be keen to see how i could bolt on some continuous integration to the mix...

When is a bug not a bug?

I am sure the Tester at the place I currently work at secretly hates me. He is far too nice and far too professional to ever say... but i am sure of it.
He is in a position where he knows what the application we are building should do and how it should do it. Unfortunately this is only ever communicated to me after I have built the module. He doesnt write the use case so dosen't get a chance to prewarn me.
These changes are raised as bugs (as we only have the concept of bug, no concept of a change request) and so it looks like my code sucks as i have a couple of dozen bugs logged against my name (which is standard across the team). I dont like the idea of my code sucking. While looking through the buglist today, after reading the first 12 and realising that they were either A) Not bugs, but changes or B) not my bugs to fix; I got a little stroppy.
*begin blowing trumpet*
Now, when I get a use case I assume that this is what is required... I know, what an idiot... so I write my unit tests and do the whole Red, Green, Refactor like a good TDD agile boy,
*end blowing trumpet*
however I forget that we only call ourselves agile we are in fact... dreamers.
Huge numbers of tests fail and are left unattended, iteration after iteration... our scope is non existent.. our use case are guesses at what we kinda, maybe want and are completely ok to change at any time with the expectation to deliver on time still intact.
So I have tried to push back.
-A bug is raised
> If in use case ==> FIX NOW!
>Else ==>can be done in next iteration and is logged as "Not in spec/Functional change".

I thought this may rustle some feathers and hopefully means the uses case would be a little more robust. It also means the actual bugs got higher priority, as I think they should.
No...
Now we just do non-functional iterations where we do "bug fixes" on all the functionality that was never originally asked for.
As there are a few developers (6-12) all on UK rates (not exactly cheap) and one BA (still only UK rates, but only 1), I would think it would make sense to focus the effort on the up front work, hell maybe even hire another "BA" so the development team don’t have to handle code 2,3,4 + times.
It also means the teste (again on UK rates) has to test and then retest every time the change is made... how do you spell D.R.Y???
To say this annoys me is somewhat of an understatement. It is pretty hard to be focused and passionate about what you are doing, knowing full well in only a few hours/days/weeks it will all get thrown out because someone threw together a Use case, with out putting more than 5 minutes thought into it.
More time scoping => less time "bug fixing"*

*i.e. retrofitting missing functionality

Now I know Agile encompasses the ability to "handle change", but never getting the original scope correct... ever, through laziness, is not Agile, it's just software cowboy bollocks.

Unfortunately nothing is going to change. This could be a really good project, even a flag ship project for the company as it is using new exciting tools for the comapny (.Net 3.0, Nhibernate etc) and it would honestly only require the smallest extra bit of effort. But it wont and that’s a shame.

end of yet another rant...

Measuring Productivity

LOC is possibly the most stupid way to measure productivity. It really doesnt show anything and possibly encourages bloated code for the not so noble coder keen to grease up to the project manager.
Possibly a better option is measuring based on passing Unit Tests.
Why?

• A unit test usual defines one part of functionality.
• It encourages the developer to write untis tests and encourages more robust coding.

This is kind of a brain dump, but i think it may have merit...possibly.