opgenorth.net

Well, it's about that time of year where I start thinking about my next laptop.  I was originally convinced it would be a MacBook Pro.  Sexy look and functional, couple with the chance to pretend I'm Justice Grey - who could resist (well, maybe those on a budget or with bad hair).  However, I then stumbled across the Asus G70.  Dual-HD, Dual-Core; how could I resist.  The fact that I've been using Asus laptops for the past three years (and been happy) helps as well.  Or, maybe I should just soldier on with my existing Asus z96j and get a Tavor. 

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.

One of the most, ummm, alternative things I picked up from altnetconf this past weekend was the game of MetaStones.  It's really hard to explain, you have to watch it in action.  Basically, it's kind of a drinking game.   Or not.  It certain does seem to work better if you're drinking lots.

The purpose of this talk is about how to introduce/use advance techniques in your software development, getting developers to understand, appreciate, and incorporate some or all of these techniques in their work.  I walked into this one late, so this might be a bit light. 

What are advance techniques:

• IoC:  Inversion of Control
• AOP: Aspect Orientated Programming
• ORM: Object Relational Mapping
• SoC: Separation of Concerns (Perhaps not so advanced, but something developers should know)
• SRP: Single Responsibility Principle (Perhaps not so advanced, but something developers should know)

General notes/observations, and what Scott Bellware wrote on the board:

• The best way to alienate developers is to tell them that you know how to do it better.
• You can either build up your team, and raise their skills, or get the application out fast.  You cannot do both.
• It takes time to get a team to form an opinion on new techniques, and to buy into them.  Charlie Poole comments that in thirty years of development, it is his experience that using agile techniques are the best way to do this (to date).
• Architects decompose work items.
• Architect reduces the amount of work that other do.
• Developers must be held accountable.
• Developers must understand why maintainability is important.
• Oren book recommendation: "Release It".

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.

• Setting up for the fishbowl. 
• This session is about how to present/market/sell agile to management.
• Management knows they are supposed to get time projections, documentation, hard dates, gantt charts.  They don't get that from Agile.  Makes them nervous.  Management also doesn't like (typically) the extra effort they have to put in (i.e. they must become more involved).
• Ray Lewallen :  Management doesn't trust staff, but the staff is expected to trust the mangement to make the right decision.  This one way trust makes it hard to introduce agile.
• Udi Dahan:  Perhaps we need to speak the language management understands.  Concentrate on finding out what the business wants (i.e. what will bring value).   Don't talk about what or how agile is, but about how to fulfill/meet those values as lean (agile) as possible.
• Chad Myers:  "Agile involves trust and communication."
• Developer/Manager anti-pattern:  Because the manager is, in an org chart, "above" the programmer, they feel that they have the right (authority) to dictate development.  There should be  clear separation of concerns:  managers may decide what is to be done, the developers shall decide how.  Maybe that should be burned into the contract.
• Misconception:  Business only cares about the bottom line.
• Sometimes you need to introduce agile incrementally.  Do it in phases.  Sometimes you have to prove the pain after the fact.  I.e. if we had unit tests, we would have caught this problem -> becomes a catalyst for bringing in TDD.
• Empathy is important.  Understand what the client wants, why the are where they are currently at.
  • Don't come in waving the agile banner and proposing it as a "silver bullet"
  • Empathy is not about pain.  It is about understanding.
  • Humility:  admit you don't know the answer.  Try to show correlations between the problems the client is currently having, and how agile was used to solve similar problems in your past experience
    • This helps build trust
• Dave Laribee book recommendation Rules for Radicals.
• Udi Dahan: 
  • from TPS:  It's always a people problem, and/or a process problem.  This is what needs to be addressed first. 
  • Build trust, build up people that care.
  • Chad Myers:  How can you dial up the trust when you are experiencing the pain (i.e. hard to trust the hand that hurts)?
  • You can't solve two problems at once.  Don't propose fixes for point in time problems.  Analyze the past and base proposals on that.  i.e.  Don't parachute in and yell TDD.  Examine the past, if you notice a lot of regression bugs, then maybe propose TDD as a way to address this.  Or maybe borrowing QA guys for a day or two.
• Find out what people care about, speak to that. 
• Agile should be presented as a set of tools to help management control projects.  Don't pitch as a methodology.
• Book recommendation from Jim Shore:  Fuck Yes.

Well, this discussion is losing interest for me.  Time to hear about DSL a the other side of the room.

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.

Brad Abrams brings up the point of noun centric vs. verb centric  designs.  Noun centric == data driven.  Verb centric == domain driven.

Oren talks about one of the big advantages of DDD.  We can very easily change the model, as it is all in code.  Tools like R# allow us to make changes quickly, and then NHibernate will allow us to update the database just  as quickly.  Databases are an implementation detail, part of the application, a mere persistence store.  A good domain design will generally lend itself to a  decent database design.

Apparently it is possible to suffer from an SQL injection attack with NHibernate.  According to Oren, you have to be pretty stupid for this to happen, but it can happen.  I did not know this.

Topic changes:  what do you do when you come to a client who has 1.5TB of established data and database.  How do you deal with that?  Ideally, you claim ownership of the data, and carry on.  This isn't very realistic.

Oren starts explaining that NHibernate can allow you to partition the data in existing databases to match your model.  He suggests that it might be better to speak with the DBA to make a new model, as this approach might take a lot of effort.  Might be smarter/better to change the persistence.

Oren's preference is to generate the HBM's by hand.  He wants the pain to be real.  The logic is that the pain will force you to thing about your model, and helps you focus on what is important to your model.  By generating the code, you end up with, for example, a domain model that has 200 classes/tables and classes with 700 fields.

Another advantage of using NHibernate:  you get a nice way to set up a unit of work, and can specify boundaries for your application.  For example, you can, via an HttpModule with your unit of work, limit the number of queries (trips to the database).  Oren:  Going to the database is the best place to optimize, not the query itself.  Minimize the trips to the database.  You can enforce this limit right away.  It is not a problem that will hit you out of the blue in production.

NHibernate is very complex, and the learning curve very steep.  Oren argues it is not overly complex, and this complexity allows you to very advanced things.  For the simple stuff, NHibernate is very easy.  It is very irresponsible to just parachute in, introduce NHibernate, and then disappear.

Oren quotes:

• "I tend to be nice to people that pay me"
• "Use a set, that is all"
• "Don't worry about performance until you see you have a hotspot and are using a profiler"
• "Whoever designed Linq bordered between genius and madman"

Ben Scheirman refers us to Chapter 6 in NHibernate.  Important for collections.

It seems that this session is not so much stored procs, but a Q&A session from the community about what exactly NHibernate can do.  Oren's knowledge and experience

The CLR is very fast, asserts Oren Eini.  Rod Paddock disagrees.  With WebForms, it isn't the CLR that is slower, it is all the stuff that goes on behind the scenes with the page lifecycle.

The question is asked:  Are datasets more efficient that NHibernate.  Apparently some people get hung up on these types of things, and claim that tools like ORM's aren't good because they add overhead.  Sounds like premature overhead to me.

Unrelated trivia:  This is the latest in the year it has snowed in Seattle since 1968.

I get here late, primarily because I went to the wrong room.  Thank goodness for the fishbowl format, as I manage to steal one seat of one of the guys in the fishbowl.  Sorry to whomever that was.

Aaron Jensen explains the AMC (auto mocking container)

• Basically, the AMC will take some of the lifting away from you.  It will help setup the code under test with the proper dependencies.  The dependencies mocked out.
• Glenn Block:  Anybody doing mocking should be using an AMC

Debates over the pros and cons of the various mocking frameworks.  Some don't like the verbosity of the record/playback syntax of Rhino.  Glenn points out that the use of lambas and generics in Moq can get kind of hard to read too.

Argument for not using mocks:  A mediocre/substandard programmer won't do it correctly.  Mocks are code, but the mediocre programmer doesn't write good code.  So getting him to write mocks might not really help/solve anything.  He won't know if he is testing what he should, or if he testing what he thinks he is testing.

• Oren counters using the example of the double entry technique the use in accounting.

Things that would help the adoption of mocks:

• Decent documentation (Oren puts up URL for Rhino.Mocks documentation).
• JP Boodhoo: people need to understand the concepts of contract based programming first, then the understanding mocking will follow.
• Another opinion:
• Reduce the chattiness of coding a mock.  Shouldn't need to use expect/verify syntax. 
• The fact that one has to use an interface shouldn't be required.  One should just be able to use a class if you want (I don't think I agree with this at all).

A couple of jokes about how TypeMock is the mocking framework for the Mort persona.  I got a license for TypeMock, I'm curious to see if this will bear true.  To bad Roy isn't here to answer these claims.

This is getting kind of tedious, so law of two feet.  I'm outta here.

Here are my random collection of notes on this session. What do you want in NUnit 3.0?

• Charlie Poole starts off giving a the history of NUnit.
• Jeff Brown (MbUnit) is here.  I see he has many Utlikilt.
• NUnit extensibility is, by design at the moment, for people that want to do extensions, not for people wanted to do tests.  This will probably change in 3.0, and you will be able to write your own extensions.
• NUnit 2.5 coming out shortly (would have been today, but Charlie had connection problems):
• New asserts.
• TestCaseAttribute:  takes the arguments for a method. 
• Allows for parameterized tests.  This marks something as a test, and provides the data
• Will take named parameters
• Can specify a return value
• Charlie sees that maybe this in the future might extend to putting tests on production code
• NUnit 3.0 is going to the Mono.Addins model to allow for more flexible extensions.
• Question from Roy Osherove:  How will you order the extensions you write?  Will it be possible to do this?
• Extensions will happen before the build-in stuff.
• Mutually excusive extensions:  don't do this.
• For "decorator attributes", you can specify a priority.  When the attribute registers itself it will get a priority.  The decorator will have its priority baked in.  If the priority conflicts, then it becomes indeterminate.
• In 3.0, everything will be an addin (again see Mono.Addins).  Think of the architecture for MonoDevelop.
• The NUnit 3.0 will be a core of base addins.  If you load and register your own addins, then they will take priority over the default/core addins.
• NUnit 3.0 will be a teardown/rewrite.  Doesn't sound like they will reuse much of the old code.
• NUnit 3.0 will require .NET 2.0 as a minimum.  .NET 1.1 will not be supported.
• Assert.Thows is in NUnit 2.5 alpha

Charlies changes direction , talking more about NUnit 3.0

• Will still be a WinForms GUI. 
• Will be a WPF GUI ("...mostly because it's cool.")
• Will be a GTK GUI.  For the Linux guys, because WinForms isn't as pretty on non-Windows.
• Jeff Brown:  What about Resharper?
• R# makes it pretty complicated to write an add-in.  Charlie would like to have somebody familiar with the R# structure to help out.
• Memorable quote from Charlie:  "Jetbrains wanted to exceed Microsoft in writing a complicated extensiblity framework, and they succeeded".
• Roy Osherove:  "What will be the differentator between NUnit 3.0 and MbUnit 3.0?"
• NUnit is not aiming at being a host for all frameworks.
• Not looking to emulate other frameworks (i.e. allow people to run their csUnit tests)
• NUnit 3.0 is not comparable to MbUnit. 
• The NUnit 3.0 platform is a bunch of stuff, consisting of the Nunit 3.0 framework and other stuff.  What is the difference between the NUnit platform vs. the NUnit 3.0 framework.
• Some extreme edge case stuff from NUnit 2.x won't work in NUnit 3.0.  This is the really odd stuff.

What will directly affect users in NUnit 3.0:

• Extensibility.
• Ability to use native code from different frameworks (3.5 stuff)
• Extension of syntax, and adding new syntax.
• Write DSL's on top of the framework.

List of things people would like to see in some sort of testing framework:

• Parallelism
• Theory.  This is an expression of a general concept, like " I multiple two integers and divide, I get the numbers back".  The test framework provides various random integers to the test, and checks the results.  This will happen multiple times, but you will only see one result from all attempts. 
• Pex integration.  Apparently there is an unpublished NUnit extension for Pex.
• multi-threaded support.

Funny quote from Charlie:  "... if you see something in NUnit, odds are you will see it in MbUnit very quickly.  And, odds are, in about 10 years, you will see it in MSTest".

And the session ends as the hordes come in from other sessions.  Of to figure out where I want to go next.

Well, it seems that there is something odd going on with mojoPortal.  When you post your comments, you will get an error saying something evil happened, and that the world will be ending shortly.

This is not the case.  Nothing evil has happened.  Your comments will be captured.  No men in black pajamas will fast-rope out of a stealth helicopter hovering over your house to whisk you away for interrogation.

I'll see what is up when I get home.  The error is pretty bizarre, and doesn't make a lot of sense to me.  Probably has to do with the VM image I'm running mojoPortal on.

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.

Well, I'm really behind on reading my blog roll (largely because of the surprisingly crappy bandwidth here - or maybe it's 2000 geeks descending on Seattle and burning it all up), so this is probably nothing new and/or surprising to most.

However, I was really pleased to see that Novell is now packaging Mono for Linux distros other than SuSE.  It looks like it's just RPM based distros, but still, this is good new none the less.  The offical line from Novell was always that they didn't have the resources to package Mono for distros other than OpenSuSE.  Nice to see this.