The title of today's post refers to "Amazing", and there is a reason for this.  A while back I took some photos of some of the areas that we ride in Flightline.  For those not familiar with the area Lake Calavera is located near Canon and El Camino Real and Flightline our other riding area is located somewhat to the south near Palomar Airport Road and El Camino Real.  Calavera is mainly open space and the trails while technical are moderate in difficulty.  Flightline on the other hand has several trails which can only be described as difficult and in fact bordering on impossible.  Today we departed the skateboard park parking lot for a ride through flightline.  Mike headed us (Ryan, Tim, Kevin, Adam and I) through a brutal set of paths.  In fact the ride practically ran a couple people in the ground.  

Near the end of the ride Mike headed us down toward the cross over between Calavera and Flightline.  It is possible to transition between these two areas, although we normally go from Calavera to Flightline.  Below is a shot of the main technical portion of the crossing.  It's the drop to, and bridge over, the first of the two streams as you cross as you make this transition from Flightline.

Now the angle of this shot may not truly give you the real picture of just how steep this downward incline is nor how high that bridge is.  Suffice it to say that bridge can be walked under with significant head room.  Some people such as Tim will ride this and in fact Mike who was leading, rode down this today.  Behind Mike, Ryan showed that he has some good judgement in that he walked down the steep section here and across the bridge.  Behind Ryan was Kevin and behind Kevin were Tim and I.  As Ryan was getting across, Kevin (on his new bike) decided to go for it.  and started heading down, Tim and I were essentially in the location from which I had taken the picture above on a previous ride.

Kevin made it down the first set of ladder-like boards (in place to prevent erosion and for traction when people try to climb this) and made the slight right onto the second ladder and just as he neared the bottom of that ladder (moving slowly) he dropped his front wheel off the ladder.  This wasn't a big drop maybe 1-2 inches but his front wheel was up against the ridge and as he tried to stop (from what I could tell) his rear wheel which was 4 feet higher up came off the left side (stream side) of the ladder and that was a big drop.

As his rear wheel drops off the ladder Kevin loses it completely and falls to the left side with both he and the bike disappearing into the creek below.  The other four of us basically watched in horror as Kevin fell between 10 and 15 feet ( three and a half to five and a half meters) into the stream.

At this point we were all thinking about how we would carry him out and where Life Flight was going to land in order to rush his body to the hospital. Fortunately for Kevin, he missed the obstacles near the edge of the stream as he fell, and managed to go down ahead of his bike.  He hit the stream more or less sideways with his bike coming in more or less on top of him.   For about 2 seconds he was face down in the stream as the rest of us started to scramble - like I said we were trying to figure out what it was going to take to get assistance; as Kevin stood up and managed to get his bike off of himself.

The portion of the stream he hit was more or less rock free (that might be the old rocks under the bridge) and after his fall Kevin had only a scuffed knee, a slightly cut hand and a lot of basic soreness.  However, he somehow didn't crack open his skull, break any vertebrae or his legs. 

Which is what makes this wipe out 'amazing'.  Fact is Kevin shouldn't have walked away from this one, to say he was lucky is an understatement.  Once we had all been assured that he was OK, Kevin took a moment to step back into the creek so I could take a shot of him down in the creek for perspective. 

As you can see the bridge is taller then Kevin.  Note that the bridge also has a slight incline and that kevin fell from the steep section just beyond the bridge over the top of that 4x4 beam you see below.

We've all had our wipe outs, me over the handle bars to many times to count, Adam over the handlebars and most memorably losing it during a 5 foot drop and winding up landing on his head.  We've had Tim tear open his leg and require a trip to the hospital.  This wipe out was "amazing" because Kevin wasn't seriously injured.  So remember always try to calculate the price of failure into your attempt in this case Kevin was lucky in that he didn't pay a heavy price - me I'll keep walking on those sections where the price of failure is too high...

I haven't mentioned much biking this year.  In all honesty, I haven't got much in on my road bike for two reasons.  The first is that I've been limited with preparations for the Version 5.0 delivery that have cut back on my Saturday rides and just generally with teaching etc. I've been too busy and or unable to ride to work.  With V5.0 delivery due by May 5th that will resolve itself, in fact I have a couple weeks of vacation coming after delivery so that should help.

The second big reason is I've been getting more riders at work out on mountain bikes.  We've gone from a group of 3 regurlar riders (Tim, Adam and I) to a group of 5 regular riders with a few others either waiting in the wings or claiming they'll be joining us 'someday'.  So I've been doing more Mtn. bike rides and getting some people started.  This continued this past Thursday when I had two potential new riders who were going to head out into the area around Lake Calaveras with me.  (This is out in Carlsbad and basically we head in from the farm side at the intersection of Canon and College heading North on the Farm road then turning East.)

Unfortunately both ended up cancelling at the last minute so I ended up heading out on my own.  Rather then just doing a regular ride I figured I'd do some exploring so I headed up a fire road I've been meaning to check out for it's beginner ride potential.  (It could work, but I think it would be too much for most beginners...) Basically following the normal route to the base of the spine but from there I headed up the fire road instead of up the single track we call the spine. 

The fireroad eventually heads up on the area you see in the picture above.  There is a trail (not quite visible with my phone's lousy resolution) about 2/3's of the way up the fire road heading to the South or going right as you are looking at that picture.  I followed that trail around to just above what we call the 'Office'.  The office is located above and slightly right of center near the peak of the hill shown in the picture below.

From there I headed back to the large white building seen in the first picture and came back down the fire road to the trail you can just see in the bottom of the first picture heading to the left of the fireroad and off the bottom of the image.  This took back in above the lake and I came around in the reverse direction on our 'regular' route through Calavera.  When I got to the base of the peak (top of the spine) instead of heading down and out I went up to the top of the main peak.  That's where I took my photo's from including the next one looking down on the lake and a portion of our normal beginner route across the burm.

As you can see this is just above the old strip mine / quarry site that is cut out of the main peak.  Down along the portion of the lake you can see, is the burm which makes the lake and that is part of our normal beginner route... above that you can just make out a short portion of our regular route that is above the spine.  At any rate it was a beautiful day for a ride.  I also got out on Saturday for a brief ride in Flightline but that's another post.

Tim Sneath added a cool post showing you how to add the Glass UI that is part of Arrow to you winform based application.  Very cool effect for those looking to do a slick WPF application (not that IK is doing any of those   oh yeah - TSRI... here's the link:

http://blogs.msdn.com/tims/archive/2006/04/18/578637.aspx

By default ADO.NET, including ADO.NET 2.0, uses Named Pipes to connect to SQL Server. (Including SQL Server 2005) However, in some environments where there are firewalls and other network appliances between say your ASP.NET web client or other Windows Form client and the database you might find that Named Pipes don't work.

If you need to use TCP/IP to connect to SQL Server instead of Named Pipes then the solution is to use the connection string parameter "Network Library".  You simply add "Network Library=dbmssocn" to your connection string.  This is defined in the MS KB article at: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q315159 

One of my co-authors from Professional VB.NET and a well known Microsoft Regional Directory recently put together a somewhat tongue in cheek history of VB... it's a good read especially for developers interested in the progression to .NET:  http://www.dotnetmasters.com/HistoryOfBasic.htm

Over on my blog roll one of the blog sites I like to visit every so often is the Daily WTF.  This site essentially takes code samples and say - "OK, what were the people who wrote this thinking?"  Let me say up front I've never submitted any code to this site, but since I had a chance today to catch a breath I stopped by and they had an code that involves,  what for lack of a better term I would call a design pattern, the rules processor.

Now there are  several things that sound great when you talk about a rules processor, and generally the thought process goes something like:

" Wouldn't it be great if instead of writing an application that embedded business logic regarding how to process an order or handle a customer request and then having programmers need to make changes when our process or business rules change;

We could instead have an application that read our business rules out of a database and then ran these rules against the customer database."

As this post on the Daily WTF notes, this is a admirable desire, but unfortunately if you try to build it yourself from scratch - well don't be surprised if you wind up with something similar to what this post is highlighting: http://www.thedailywtf.com/forums/68489/ShowPost.aspx

Let me reiterate - I don't know where that code came from much less did I submit it.  However, I disagree with a couple things in that post.

First I think there is value in working to transfer rules out of code if those rules are dynamic.   It's that word dynamic that I think people sometimes forget.  Will the "number of days" to apply X ever change from being a number?  No, so don't make it a rule, put it in code.  Will the "maximum number of days" ever change - probably, so make it a 'rule' or at least a setting.

The difference is important because while I can create an engine to look for a generic rule to test for both the fact is the more rules my system needs the more complex the maintenance of those rules becomes and the greater the liklihood that I'll need a specialized employee to maintain those rules, thus defeating the original goal of the rules processor.

Secondly, look at what tools are already available on the market.  There are companies that specialize in making and implementing rules engines - consider purchasing one of these existing products.  More importantly, when I examine most rules processors what I find is that over time then tend to combine data validation based business rules with workflow based data processing.

Let me explain the what I mean by a difference.  A rules engine is applying rules to see if an action or set of data meets the business requirements necessary to accept that data or start an action.  A workflow engine takes data which is nominally valid and ensures that it flows to all the appropriate points in your organization or even across organizations, so that the customer's request to result in a desired outcome.

Now in a discussion around requirements these two things can sound very similar.  For example "Ensure the order has a maximum number of days duration." sounds very similar to "Ensure the order goes to fulfillment and is processed within X days."  However, these two requirements require entirely different approaches, one is focused on getting the correct information, the other is focused on how that data is handled.

Which brings us to Windows Workflow Foundation, similar to BizTalk, this is a technology designed to process your data.  If you start trying to take the 'workflow rules'  and apply them like definitions to data validation you will find yourself writing some *very* convoluted code.  Don't get me wrong both WWF and BizTalk do a certain level of data validation in order to accept an object for processing, but you'll note that validation isn't the same as what they do in their actual workflow process.

So when you are designing your system and the question of 'rules' comes up start thinking about:

1. What elements of the system need rules?
2. Keep the rules simple, otherwise even if they aren't compiled they'll require a programmer using a custom syntax to maintain.
3. Separate rules from workflow.
4. Leverage existing products to both speed your development and ensure a standard implementation.

I've been meaning to blog on this for a couple weeks and got some time this weekend.  In short one of the cool things with writing a book is seeing it come out.  Wrox actually has an advantage here because you not only get your name, but your picture on the cover.

Well when I first signed up with Wrox, (a surprisingly long time ago) one of the questions they asked was would like a copy of my book in other languages? I said 'yeah', I thought it would be cool if it ever happened.  Well in the mail a couple weeks ago, I got an unexpected package - and there it was - Professional VB.NET 2003 in Chinese.  Here's the cover shot:

Yeah as you can tell I don't quite rank with Bill Evjen and Billy Hollis - I'm the 'other' Bill on the book... actually it's entirely possible that they just used the names that went with the first two pictures... and who knows if one of those sets of characters represents my name or maybe those are the names of the book translators...  still it's cool to have your book (and picture) show up in a language you don't speak.  By the way they don't redo the screen shots, so all the screen images are the same as the english version.  This is especially cool since I managed to work the names of my first neice and nephew into a couple of the screen shots.

By the way that little blue square, that apparently is from the university that is using the book in one of it's courses, here is a close up:

So to the University and students of Tsinghua, thanks and good luck in your endeavors.

One of the characteristics I find interesting is how poor most developers are when it comes to writing.  Don't get me wrong growing up English class wasn't my best area of study (although I did manage to avoid Summer school).  Also back when I was in school most people associated programming with math.  After all most software was being written for science and engineer and in college my major was Computer Science.  All of which at the time was fine, but today more then ever being a software engineer is really about Writing code - not developing algorithms and executing calculations in the computer.

Modern development with tools like .NET is about writing a solution.  XAML takes this one step further, such that the logical paths aren't even available, XAML is primarily just specifying what you want available.  Yet seemingly regardless of the implementation language most developers write poor documentation.  Now as a published author both for magazine and book, I see these two tasks as extremely similar and thus I wonder - is an unwillingness or percieved inability to document their code and project something that should be difficult for a talented software engineer.

To write code you need:  to type, need to generally put your statements in a cohesive order, follow a design, have a syntax or grammar that must be followed and have your work interpreted (either by a compiler or at runtime).

To write documentation or articles you need: to type, need to generally put your statements in a cohesive order, follow an outline/design, have a grammar or syntax that should be followed and have your work interpreted (either by an editor or by another human).

These tasks seem completely related, so why is it that some developers I've worked with in the past who are excellent at writing code can't seem to write a cohesive paragraph?  Why aren't they through design documents and functional specifications and comments building the necessary writing skills?

One of the reasons I don't blog that frequently is that I get many of my opinions out via the Developer Update newsletter.  I don't think I've posted about it recently, the Developer Update newsletter is published by Penton which is the parent company of WindowsITPro and SQLServer magazine. Sometimes when I mention that I write a twice monthly free e-mail newsletter on developer issues I'm asked about where someone signs up.

To subscribe go to the Windows IT Pro free newsletter page and add your email address, then down near the bottom (under the SQL Server Magazine heading) you'll see the Developer Update newsletter.  Here's a link: http://www.windowsitpro.com/email/index.cfm

The next issue is this Friday.  However, be forewarned, my column contains opinion and as such you may be offended, so if you read this blog and you are easily offended you might want to avoid reading my opinions - they can cross the map, in fact in the next issue I've been asked to suggest a European trip to everyone... honest.

(How's that for a teaser trailer... doesn't it just make you wonder what I could be writing about... of course you could also google my past articles - there are about 120 out there on Penton and the MSDN sites; a couple still locked down but most are freely available.)