New stuff to play with

More stuff to go onto my "To play with" list
IronRuby: Relased today in a pre alpha state. Im actually quite excited with the DLR...
Rhino-ETL : Ayende is fast becoming a legend in my book. Coming from a background where intergration was part of the daily grind, this could be a nice tool to have in the tool box :) It may even work nicely with a project i am working on, on the side... hmmm

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.

Working in "Verticals"

I am currently wrapping up my time contracting/consulting to a company building a POS system in CAB.
Long story short the team seems to divide work in to verticals. i.e. can you build this piece of functionality.. the MVC components, the services, the persistence, everything. I really find it odd. I have raised the issue a couple of times and the team assures me that the system is so intermingled that you couldn’t possibly work in "horizontals" i.e. tiers. This has caused, IMO, a huge number of issues, including redundant work, rework and re-rework as people don't "get" certain patterns or reason for the code. It also means a Graphics guy is handling the DB and the DAL.
Jesus.
To be honest I would have put the juniors at the front end. They could have learnt all about MVC, Win forms, CAB with its dependency injection (of sorts) events & delegates... that’s plenty to take in for people new to C# and .net!!!
A proper DBA should have been in charge of the DB. Instead developers have clearly written it. Normalisation in my mind is generally a good thing. DB schema changes weeks out from release are not, especially when a DBA out of college could have spotted most of the mistakes.
The the intermediate & snr dev work on DAL, Services and business logic while the Lead (there never was an architect) focus on architecture, framework and code reviews.
Making mistakes is not always a bad thing, but you have to learn from them to get anything out of it. Perhaps I am not doing my job well enough if they still don’t get it. :(

Acknowledging progress

I quite like this idea:
When projects seem like they are going on forever... something like this could be quite a good motivator for the team. I probably wouldn't put in the direct eye of clients as it is pretty messy (but in my experience most coding environments are anyway...)

Open Source list

Jeff Atwood is pushing to help reward some of the .Net OSS community by donating $10k to the most deserving application (or the group that runs it). That’s pretty nice but I am much happier that there is a pretty comprehensive list of GOOD .Net OSS application/frameworks/tools here:

http://spreadsheets.google.com/pub?key=pKxDW35algYebfs8nssTjIQ

I don’t know if this link will work forever... perhaps just for the length of the "competition".

Shot Jeff!

SubSonic

Like a lot of people, writing Data Access Layers is not something I really want to spend a lot of time doing. Thankfully there are a vast number of ways that you can improve the process, ORM's and code generators are the two basic methods of assisting in this fashion. Many will be familiar with Hibernate (and its .Net equivalent), possibly the most popular ORM on the market. I quiet like it, but it’s fiddly and config heavy in terms of mapping files. You can Generate these thanks to product like MyGeneration but it often requires tweaking. once its up and running it really is a nice way to deal with persistence for very OO based applications. The other option I have used is Codesmith with it NetTiers templates. Well, up until finding Subsonic. It (so far) has been great.
What I like:

• Can have the benefits of SP’s and ORM


• Can set it to generate the code at build time, so you know every time you run it it is synched with the data base


• If you don’t like the generate on build option you can easily generate the class files for the DAL as well as the create scripts for DB including data, all from with in VS (great for Source control!)


• Author(s) seem to be very proactive in their support and maintenance


• Can be used with in VS as an external tool, meaning one click generation from within VS.


• Minimal additional config settings


• Video showing you how to do it.


• Its pretty fast

I last ran into Subsonic when it was ActionPack. Being happy with Codesmith I didn’t really follow it up. However, as I no longer have a license for CodeSmith, SubSonic being OSS is looking a lot nicer :)
No doubt as I continue to play with it I will find features and bugs, but so far so good.

"Just one test!"

I have read in a couple of places now (amongst other generalities) that a unit test per method is the standard "rule of thumb". I have been surprised at this. I understand that at least one test per real method (not one line getter/setters) is a minimum but to generalise it to only one is a bit odd.
This was kinda sparked off by this post http://blog.sidu.in/2007/06/pre-run-tasks-unit-testing-anti-pattern.html. I am not coming down on the poster at all and I may have over reacted to an aspect of the post that was certainly not the main point of the thread.
But just one test per method? It got me thinking.
I generally have a test to cover each of the paths in the method (to an extent).
I never really thought about it but I guess complete coverage* would come from tests that match each of the paths and therefore the cyclomatic complexity of that method. If you have an increasing number of tests for a method you may want to reconsider the functionality of the method. Can it be refactored?
This I believe is another benefit of TDD. It forces you to think about function design first not just start the torrent of code and hope that what comes out works. This is also a reason to write the tests first. I find it amusing that some still write the test after they write the code. I mean really, why not define what you want then build it.

* no im not a coverage nazi :p

ICloneable = mess

I have never really taken it consideration of the reasons of why not to use ICloneable. I know not to do it, so have never had any issues. However the current project I am working has object inheriting from a certain base object that implements ICloneable (why? I don’t know).
Now the fact that none (or very few) of the ICloneable methods returned anything other than null, could have been the first sign that it might not be the best interface to implement. Then there are the deep versus shallow clone issues... who know’s what is doing what.. and then the returning of type object. Excellent. :(
Unfortunately it was a Microsoft consultant that apparently suggested using it.

Now we have a non standard clone implementation that some time does deep and sometime does a kind of shallow clone. Yuk. At least some of it is now documented.
As the classes are shared across other projects a cant just go an remove the interface… not that it looks like any one is actually using the method; as it is returning null everywhere… weird.

Back to asp.net - PageMethods

A little bolt-in that I found a while back and have never used is finally getting a test drive.
PageMethods basically helps you "strong type" parameters for aspx pages, meaning you get such benefits as intellisense & compile type errors.
Again, I'm a sucker for little helpers like this, because errors like mispelt paramtars tend to really peeve me off. ;)