Opgenorth.NET

Wordy title.  To wordy.  Kind of like build files these days.

I remember when I first discovered Ant, and then Nant* .  I was pretty happy, as it allow a decent way to compile my Java (and C#) without using make files.  Life was good as I could finally introduce some structure into HOW code was compiled.  The build process was no longer using whatever “build” command the IDE exposed, hoping that I didn’t forget a compiler directive or a file or a reference to some other library along the way.  Other programmers could also compile the code with out fear as well.  Having a tool like Nant is pretty crucial to the whole concept of continuous integration.

Somewhere along the way, though, Nant lost it’s shine.  It isn’t to hard to find these monster Nant scripts with all kinds of crazy things happening inside them.  Trying to work with these files can be a bit of a burden, to say the least.

This takes me back to the title:  it seems to me that build tools like Nant have kind of peaked, functionally speaking.  What does that mean?  We can always add more tasks (created in a real programming language) to do things for us, but in a lot of ways Nant is constrained by the fact that it is just XML.  We can always add tasks to Nant, but somethings just can’t be handled by out of the box, one size fits all tasks from Nant (or NantContrib).  As soon as you run into those things, you need to start writing code.  XML is good for config files (to a point).  It’s bad for programming logic.  It is not at all uncommon to see in build files if statements doing all kinds of things.  We don’t need to (and should not) make XML into another programming language. 

I spent a bit of time tonight playing with Bake.  For those who don’t know, Bake is to boo what Rake is to ruby.  Or, in other terms, think of a build system that is actually based on a programming language, and not a configuration file.  Why did I pick Bake?  Well, it’s boo, and I want to learn boo.  Boo is .NET, so I can leverage what I already know.  Plus, I’m reading Ayende’s book Building Domain Specific Languages in Boo, so Bake just seems to be a natural fit.

So far, I’m liking it.  In the span of a couple hours, I managed to figure out how to create a quick bake script (~ 40 lines of boo) to compile some code.  I’d say that this script more readable (or soluble, to use the words of Scott Bellware) when compared to a Nant script.  Being pretty new, Bake doesn’t have as many tasks as Nant.  However, it does seem pretty easy to create tasks for Bake.  Plus, I have all the expressiveness of a programming language available to me now

I did have one glitch that is worth mentioning:  the task to compile my code was using the CSC.EXE from .NET 2.0.  This is a problem when you’re working with a .NET 3.5 codebase.  But, no fear, I hacked out a quick fix inside of about 15 minutes, and all is well again.

I imagine that someone soon will blog about using Rake to build your .NET projects.  I eagerly await such a post.  In the meantime, I’m going to continue on with Bake, and see if it will meet my needs.

* NOTE:  I lump MSBuild in with NAnt as MSBuild, IMHO, is a clone of NAnt.

On Thursday, April 24, at the Edmonton .NET User’s Group, I did a presentation on MonoRail (and a bit on Windsor and ActiveRecord).  Thanks to all for coming out hear me talk.

I found it to be a pretty hard topic to cover in not quite 120 minutes.  There is just so much to cover and explain.  As well, it seemed that there were a couple in the crowd that felt a bit overloaded.

Congratulations to Carlos for finding the spot in my sample code where <technobabble>dependency injection could be use to create a less-tightly coupled controller</technobabble>.  I was going to give him the Reshaper license for finding it, but he had already has one and so declined.  It was eventually raffled off at the end of the presentation.

For those who wanted the code and slide deck, here they are.

Someone else asked for a sample MonoRail application that they could look to help them learn MR.  Here are a couple

1. altnetconf on googlecode.  This is the code for the website of the first altnetconf held in Austin, TX in October of 2007
2. Gearblog:  a blog build on MonoRail
3. mr-blogengine:  Another blog build on MonoRail.  This code is part of a series of blog posts about incremental development in MonoRail.

Jeremy Miller talking about the trials and tribulations of keeping a codebase viable and useful over the past four years.  A lot of tips and explanations were backed with diagrams on the whiteboard.  Kind of hard to blog that stuff, so this will probably be just a collection of bullets.

Lessons learned – a lot of them relate back to what are considered good, OO practices:

• DRY, especially with the very small things.  When Jeremy was adding support for .NET 2.0, the generic support was problematic.  
  Example:  Want to resolve a Repository<T>.  You can’t just look for the class Repository`1: i.e. was trying to resolve the class by using  typeof(Repository`1).  This did not work.
• Tell, Don’t Ask.  Didn’t follow this to heavily at first, and so now effort has to be taken to rewrite code to adhere to this principle.
• Using a lot of Double Dispatch (hah!  look Jeremy the picture did turn out):
  
• If you need to refactor, do it now.  Procrastination only makes it (refactoring) harder and more costly.
• If you want to build a .NET framework and keep it around for four to five years, you should probably learn a bit about the fundamentals of .NET.
• Small steps, frequent commits to source code.
• Good solid battery of unit tests really helps with major changes.
• Moving more towards coarser grained tests.  Does the test check the functionality?  Not to worried about the intermediate steps.
  • Assertions based on side effects really don’t work well.  Not very expressive, sometimes hard to figure out what what you’re trying to test.
• It helps have tooling inside your tests in order to help you quickly create tests, especially the difficult to setup/create tests.  Will result in a faster feedback cycle.  This infrastructure is more strategic, can be very help.
• Jeremy recommends "Pragmatic Programmers"

Brief discussion about where to start learning all these pattern.  Advice is given to learn principles first (DRY, OCP, SRP, SOC, etc) as this will greatly help with the understanding and proper use of design patterns.

Joe starts polling to see what people want to talk about.  Most seem to be interest the libraries for Mono (being that they also work on Windows/.NET.  So, Joe starts talking about libraries for/from Mono.

1. Mono.Cecil.  For all your reflecting and assembly modification needs.
2. Mono.Addins.  I’ve been looking at this off and on today, and I have to admit it looks pretty intriguing
3. Mono.Rocks:  Handy extension methods.
4. Mono.Zeroconf: Zero configuration networking library
5. DBus#:  A C# implementation of D-Bus.
6. MonoCurses: An API for console based applications
7. GTK# vs Windows:
   • My suggestion is to consider the target environment.  If you targeting Windows, stick with WinForms.  If you’re targetting Linux/Mac, go with GTK#. 
   • Another issue that might influence your decision is that the documentation for GTK# is pretty sketchy, not very good.
8. IOMap.  Turning this flag on, will help you with some of the cross-platform development issues.  This is a portable library that will help resolve things like directory seperators, case sensitivity in paths, and that sort of thing.

A short session, which isn’t bad.  Gives me a chance to float around to check out some other things.

Well, this month EDMUG was hard up for speakers, so out of desperation they asked if I had anything to say.  I figured I could talk for about 30 minutes on MonoRail, and then read the newspaper out loud for the next 90 minutes.  Oddly, the EDMUG executive was okay with that.  This morning they sent out their notice to the membership:

Thursday, April 24th will not just be one of the greatest EDMUG evenings of all time, but it will also be the opportunity of a lifetime.  It will be your chance to rub shoulders with a legend that walks like a man.  And the name of that legend is:

Tom Opgenorth!! 

Yes, as unbelievable as it sounds, pick your jaws up off the floor because Edmonton’s newest Microsoft MVP is coming to chat with EDMUG about Monorail!  The man with the largest collections of Hawaiian shirts, functioning rifles, and spandex LuluLemon tops in the entire province will be here next Thursday for the presentation NO ONE dares to miss!  As per usual, the presentation will be at the Edmonton Public Library; doors are open at 5:30 and the presentation will start at 6 PM.  Be there or be riddled with gunfire*!
ABSTRACT:

Viewstate, PostBack, and Page LifeCycle! Oh My!

Interested in seeing another way to ASP.NET applications without using
Web Forms?  Come to the April meeting of EDMUG and experience Monorail
from the Castle Project.  What is this Monorail we speak of?  Monorail
is a mature, stable, open source MVC (Model-View-Controller) framework
for ASP.NET from the Castle Project.  Come learn about web
applications without the Web Forms.
BIO:
Tom Opgenorth is a local .NET aficionado and consultant who has a
tendency to dabble in Linux.  He was recently received a Microsoft MVP
Award for 2008 in C#.

* For the skittish, gunfire will not actually occur if you miss the presentation, but we highly recommend you attend

Really, I think that there should be two things banned:  One is Justice and writing, the other is D’Arcy and Paint.NET.

Yesterday myself, Don, D’Arcy, and Eric were wandering around Seattle, just checking out the sights after the MVP Summit.  We took a break from the usual "run down D’Arcy and Manitoba" shtick, and actually had a serious conversation on the relevance of stored procedures for your typical database development/line of business app.  D’Arcy blogged take on it already.  I was going to reply in his comments, but as the comments grew, I figured my own post was in order.

I wouldn’t go quite so far as to say that sprocs are obsolete, but I really don’t think that they are that important anymore.  Sure, there will be certain circumstances where you need stored procs:  reporting comes to mind, or maybe you need to to some really DB specific things.

However, for a lot of your day to day CRUD, you don’t need stored procs.  Use an ORM.  I use NHibernate, and as such will be speaking from that point of view.

To support your typical CRUD for a table, you usually need at least our stored procs:  Insert, Update, Delete, and Find.  Usually it’s more – a lot more because of querying concerns.  These have to be maintained, and versioned, and kept in sync with the application.  This is friction.  Using NHibernate, you have a mapping file per table that is typically embedded in your assembly as a resource.  This is frictionless (relative to stored procs).

It will be said that stored procs provide you with a single API for your database which will shield your application for DB changes.  Here, I don’t agree.  A lot of times if you’re making drastic changes like this to the database, you’re probably making changes to your application.  You’re probably going to be recompiling and sending out new binaries and new stored procs.

Now, I’m sure that everybody in the stored proc camp is loading up their blunderbusses full of "stored procs are faster" shot and getting ready to fire a volley.  And, I’m sure that they have the "dynamic SQL is insecure" ammo in easy reach for the second volley.  This is not true.  NHibernate creates parameterized queries – parameterized queries are just as fast as stored procs.  And, because these are parameterized queries, they are just as secure as stored procs (edit:  by secure, I mean resistant to injection attacks and the like).

Another point to consider is this:  most programmers are not DBA’s.  Their proficiency is in writing code (C#, VB.NET).  Keep your programmers doing what they do best: coding in the language they are most proficient in.  I don’t want to say that programmers write bad SQL, but that NHibernate will probably create the SQL statements that are just as good (or better) than what a programmer will do.  There isn’t just one database driver in NHibernate churning out generic SQL for all database platforms.  The database drivers are very specialized modules that are optimized for the database in question (i.e. MySQL, Oracle, SQL Server 2000, SQL Server 2005).

Honestly though, this debate (ORM vs stored procs) has been going on for while.  I know that there are still many places that are firmly entrenched and will only use stored procs.  So, to say that stored procs are obsolete might be a bit harsh.  I do believe that they aren’t as relevant anymore.

In April, 1908 the 101st Edmonton Fusiliers were established as Alberta’s first infantry regiment.  The first commanding office was Lieutenant-Colonel E.B. Edwards.  The 101st developed slowly, as most in the Edmonton area were attracted to the 19th Alberta Dragoons, a cavalry regiment which had been established in January of 1908.

When war broke out in 1914, there was some question about the legality of using the existing militia regiments to fight overseas in Europe.  As such, the newly formed Canadian Expeditionary Force was comprised entirely of new battalions and the 101st was not allowed to go overseas.  The 101st Edmonton Fusilier recruited and contributed 1,200 men to these new battalions of the 1st Canadian Division, C.E.F in 1914.

The 101st Edmonton Fusiliers are not longer around in any official capacity.  The legacy of the of the 101st Fusiliers is perpetuated today by the Loyal Edmonton Regiment.

The Loyal Edmonton Regiment was formed up in 1915 as the 49th Battalion, C.E.F. to fight overseas.  Many of the men that were originally recruited by the 101st Edmonton Fusiliers ended up serving in the 49th Battalion.  As such, it was decided at the end of the First World War that the 49th Battalion, The Edmonton Regiment would perpetuate the 101st Edmonton Fusiliers.

In 1943, His Majesty King George VI decreed by royal charter that the Edmonton Regiment would be know as The Loyal Edmonton Regiment.

If you do live in Edmonton, you might want to check out the Loyal Edmonton Regiment Museum at the Prince of Wales Armoury one day.  Lots of interesting history there, if you ask me.

Thanks to Phil Haack‘s online poll, there is a bit of controversy over where one’s unit tests should reside:  should the unit tests be housed in a separate project and assembly, or do they shack up in the same project as the code that they are testing?  Like Bil, I figured that rather than a big long blog comment, I’d be better of with my post.

Way back when I started out with TDD, I used to put the test fixtures in the same file as the class under test, sort of like:

public class ClassUnderTest

{

}


#if DEBUG

[TestFixture]

public class Tests_for_ClassUnderTest

{

}

#endif

My logic was basically this way, the test is right there – quick and easy to access.  Tests are, after all, supposed to serve as documentation, so by making the two classes share the same file, it was easy to find.  Plus, if you changed your class, you had quick access to your tests. When it came time to deploy, you could just did a RELEASE build, and the unit tests would not be included.  Or, if need be, send out the code with the unit tests included, and then your QA department could run your tests on their environment if desired.

However, I eventually moved away from this, for a couple of reasons:

I was still learning TDD, and I noticed I was doing a lot of thrashing.  This was because my test code is right next to my production code and I found myself falling into a "test last" pattern.  That is to say, I would write my code first, then my tests.  When my code didn’t work, I’d change it, and then "fix" my test so that my code would work.  I lacked the discipline and experience to write good, proper tests and I felt that part of the problem was it was to easy to fall back into the "Old Ways".

I found that by putting my test classes in a separate assembly, I would actually think about what I need, and that would result in better tests and (IMHO) better code.  After all, one of the real benefits about TDD is that it forces you to think about your design up front.  I found that by using a separate assembly to house my unit tests, I ended up changing how I approached TDD.  I spent a bit more time thinking about HOW my test would work, and HOW the code would be structured.  It sounds crazy, but it worked for me. 

In my experience, the good people in QA didn’t give two rips about our unit tests.  They added no value to them, as they were using their own tests.  So, if nobody cared to run the tests outside of the developers, there is no value in sending them out.  Think lean here:  no value, so no point to make the developer’s unit tests available.

Also, at the time, I didn’t like the idea that the code that was being deployed was the code that was being tested.  I’m not a big fan of compile time directives, and compile time directives change your code.  They always seemed to cause pain when you forgot one or misspelled it.  Of course, now that we’re older, and using Nant zealously, this isn’t really an issue.

So, for those reasons, I changed the structure of my solutions.  I briefly experimented with one test assembly per production assembly, but gave that up as to unwieldy.  If you had a project with six assemblies, then you’d double it up with six test assemblies.  Now when you wanted to run tests, you’d have 12 assemblies to compile and six to run the tests on.  Not a lot of fun.  Now imagine going onto a client site with 60 project solutions:  it gets nasty fast.

I eventually settled down to the conventional "…one test assembly to rule them all…" approach, and have been doing that for a while.  It seems to work well enough, and I never worried to much about the "urban sprawl" in my namespaces.  Resharper makes it pretty easy to find classes and such, so if the namespace of my testing assembly didn’t quite match up with that of my application, I never considered it to be a big deal.

I was never really concerned about making a class public, or a method public to aid in testability.  Most (all) applications I work on are basically in house line of business applications.  I’m not writing frameworks or API’s to be consumed to the general public.  The people that are using my classes can be trusted.  Besides, they all had access to the code anyway, so what is to stop them from just going in and change the class/method from internal to public anyway?

So, where should your tests live?  Really, I don’t think it matters.  It seems natural to me to have a separate test project, but that is only because I’ve been doing it that way for a long time.  I don’t really see anything wrong with putting your test fixtures in the same project as your production code.  I’d think it was great that you had unit tests (something one rarely sees here in Edmonton), so if housing tests and production code in the same assembly works for you, then why not?

In my last post, I described how easy jQuery makes it to call an ASP.NET Web Service via AJAX.

Currently, I’m developing on Windows XP (SP2), Resharper 4 (running inside Visual Studio 2008), and using the Visual Studio Web Server.  We deploy to Windows 2003 R2/IIS6.  When I pushed the code described in my last post to the development server to test it out there, the web service call kept failing with an HTTP Status of 500 (internal error).  This basically means something went wrong on the server.

This type of error situation drives me crazy, as in most cases it is a configuration error:  something different between the platform you are developing on and the platform you are deploying to.

After adding a bunch of logging code and some poking and prying, I determined that the web service was indeed working on the server and that authentication was NOT the problem.  The problem turns out that I had forgotten to allow HTTP POST as a protocol for invoking the Web Service.  The trick to allowing HTTP POST is to put this XML

<webServices>

  <protocols>

    <add name="HttpPost" />

  </protocols>

</webServices>

into your Web.config file in the system.web section.

Moral of the Story:  If your development platform is exactly the same as your deployment platform, you can avoid a lot of these problems

Just figured I point out ConnectionStrings.com.  I find this site rather handy because it shows you the syntax for the connection strings of pretty much every database you’d want to use in .NET.