Monday, July 23, 2007
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
Possibly a better option is measuring based on passing Unit Tests.
- A unit test usual defines one part of functionality.
- It encourages the developer to write untis tests and encourages more robust coding.
Tuesday, July 17, 2007
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.
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. :(
Thursday, July 12, 2007
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...)
Tuesday, July 10, 2007
I don’t know if this link will work forever... perhaps just for the length of the "competition".
Saturday, July 7, 2007
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.
Wednesday, July 4, 2007
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
Monday, July 2, 2007
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.
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. ;)