.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. 

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.

Two topics merged into one.  Rod Paddock wants to talk about stored procs, and others want to learn how to explain NHibernate to other people who aren’t familiar with it (and minimize the jargon).

Rod uses a custom code-gen solution based heavily on sprocs - a data driven approach.  Sounds like it works well for him.  Oren concurs that this technique could be very effective in certain circumstances.  It will have problems with complex situations that deal with convoluted/difficult data scenarios.  He’s giving an example, but I just can’t keep up with him.  The point of Oren’s story is that a domain driven approach will would better when you’re not dealing with data but with data and behavior.

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.

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:

Once again, appealling to the niche (non-existant?) market, I give you a quick run down on using db4o, and the Castle Windsor db4o facility.  Yes, I know the link for the db4o facility link doesn’t work.  That is what prompted me to do this blog post. This is because, a while ago, the db4o facility was pulled from the Castle Project.  Apparently there was a licencing concern.  It’s my understanding that this has since been resolved, and I seen now that there is again the db4o facility.

As most Resharpies know, when you’re using Resharper you can reformat your code. A nice feature is that you can use this reformat code to also organize and layout your code files the way you like it.

For example, Kyle Baley did post on how to how to use the format code to get rid of regions. His techique is a bit unrefined - his revolutionary, dogmatic zeal he will clobber all regions and do nothing else - but still handy.   Myself, I’m a bit more compulsive / fussy when it comes to the layout of my code. Not only do I want regions gone, but I want the code to appear in a certain order. Lucky for me that Reformat Code does this for me. Here is the Type Member Layout pattern I use. If you want to use it, just paste it into the type member layout window in Resharper.

The past week I’ve been dabbling with an open source program called Open Dental - mostly trying to see if can get it to compile under Mono, and running under Linux.  I figure that this would be a good opportunity to and work with a cross platform application.

According to their website, Open Dental has been supported under Linux since v4.7.  Here are some notes of my efforts so far.

You will need Mono v1.2.5.  It seems that there is a problem with the Linux binary installer ( a known bug that will be corrected in 1.2.6).  I used the OpenSUSE 10.2 VMWare image which had a 1.2.5 install all set up.  That solved my problem of getting a current Linux distro with the most recent version of Mono.

One thing I noticed since I started doing ASP.NET programming back in 2002: I started using Javascript a lot less, and my copy of JavaScript: The Definitive Guide sits on the shelf gathering dust.  I’ve noticed a lot of developers I’ve worked with are the same way. In fact, I’d say that most of the ASP.NET programmers I’ve worked with these days really don’t know much about Javascript.

I don’t blame Javascript itself for this - I blame ASP.NET. Developers just get used to dropping the server side controls on their WebForms, and then doing everything server side. I’ve also worked at clients which had a “no client-side javascript” rule. All of this combines to cause our (my) Javascript skills to atrophy and wither. Kind of shame, really. (note: to a degree, I think the same can be said about CSS).

Recently, on one of the mailing lists I subscribe to, a member starting bashing .NET. A bit curious as to why there was this strong hatred of .NET, I posed a simple question:

What is wrong with .NET?

The answer I got back somewhat suprised me:

I guess the standard reply is, what is right about .NET?  .NET was invented so that M$ could provide software as a service. You would end up with a minimal OS on the disk, and no applications. When you turned your computer on, it would download whatever applications you needed, or did so on demand; if your subscription was paid up.