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

Conchango - apparently a British company has worked with (or has some relationship with Ken Schwaber) and they have released an add-in to the release version of TFS which applies the SCRUM principals to the Agile methodology in TFS.  So when you install TFS you'll find you get two process templates by default, after installing this freely available add-in you'll find you have a third template with it's own custom documentation.  My only complaint is Ken's picture - nothing personal Ken but I don't find you attractive enough to really want to see you picture all over the place

You can find the link for the free (with registration) download here: http://www.scrumforteamsystem.com/en/default.aspx

Hat tip to Rob Caron's blog for this info:  http://blogs.msdn.com/robcaron/

Being involved as an interviewer I thought I would offer a few personal (as in from me not officially from any company) tips to potential candidates everywhere.

First a note to the recruiters... Look I went through a recruiter many years ago when I got out of the Navy. I'm aware that after I interview your first candidate you are having that candidate call you and tell you what I asked and then you are using that information to brief the next candidate however:

1. Making your second candidate show up late while you wait to brief this weaker candidate is not a good plan - I may run longer then you expect on the interview and making a candidate late so there is time to brief them is just a mark against them at the start.

2. I (and others) don't ask simple questions with a right and wrong answer. The questions tend to be much more open ended - tell me about object oriented programming or web services. So prep time with our questions from the last candidate to your next candidate is pretty much wasted - just make them aware of the advice below. Of note the second candidate I interviewed did worse in my opinion then the first candidate. (Also note - none of the candidates I interviewed last week got to the important elements in my web services question.)

Fact is I don't interview with questions that you are going to prep for... I don't care what your candidate thinks their weakest attribute is ("Oh I just overwork myself to finish extra-requirements...") or if they can name 5 collection classes from .NET or some such - I want your candidate to tell me what they know.

Next for candidates - two golden rules:

1. If you put it on your resume be prepared for a question related to it! This doesn't mean a simple question it means that if you say you are an expert I will ask you expert level questions. Your resume was your intro to us and if you say you have experience on your resume, I will see if you are representing yourself appropriately. One or more candidates last week were noted as having heavily padded resumes. (BTW - don't assume the interviewer cares what .NET language you are most familiar with - one candidate last week listed C# as his/her primary language, said he/she did 50+% of their work in it - but had to be prompted with VB keywords in at least two cases... which was really silly since I'm a VB MVP and would like nothing better then to ask my questions with VB keywords and to hire VB programmers! Only a fool limits their selection of talented .NET developers based on a language preference.)

2. If you say in the interview you know something - be prepared to be asked about it. I'll ask most every candidate if they have any experience with certain technologies that might not be on their resume. I know with as heavily as people are padding resumes this is probably pointless... but sometimes it yields surprising results. For example there is the occasional candidate who will say "I know a little but not enough to really talk to that" which I can respect and will ask a simple follow up question to judge what they do know.... then there are the people who with the first question say "Yes, I've been working a with that recently/on my own time (or whatever)" who then choke when I ask a follow up question. While they don't usually make the same mistake twice - bad news, don't tell me you've used "VS2005/SharePoint etc." and then choke when I ask you about your favorite feature - that looks REALLY BAD and you are pretty much headed for Rejectville on the first attempt to snow me. The really sad part is - I don't care if you haven't worked with it, I'm just curious. You would in most cases be best off telling us flat out that you haven't worked with it then trying to pretend you have - I read your resume it wasn't listed I wasn't expecting at this point in the interview for you to know it.

Overall as a candidate expect that you will have at least one person who is a .NET expert in the room to interview and that you will face some very technically oriented questions based on the experience you list in your resume. Your interview may involve as many as four engineers depending on our availability. Be on time and dressed neatly - you don't need a suit but show up as if you were going to a client site (I may be in shorts and t-shirts but I'm not headed for a client site if I am, and for the interview you need to make me think I can send you to a client without too much supervision on proper attire.)

In general any company will hire people with all kinds of different experience levels from Junior engineers through Senior Engineers.

Oh yeah and before I forget - classic interview tips:

1. Don't argue with the interviewer - you thought technology A worked like X - interviewer says "no it works like Y". The interview is not the time to make your case - the case you will be making is your ability to work and play well with others - and you won't be getting a passing grade. If you feel you were wronged make a note and send documentation after the interview...

2. Don't tell the interviewer(s) that you are only at the interview because "your hero" works here and that you wouldn't be interested otherwise - companies aren't looking to hire fans for someone else already at the company - they are looking for engineers.