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.

Lets face it most of us tend to search MSDN using Google.  It's not uncommon and regardless of what we think about censorship politics etc, and although MSN Search is improving at this point old habits die hard.  So for about the past day or so I've found that some (but not all) of my Google searches into MSDN result in a page which is totally missing the formating for MSDN.  For example:

msdn2.microsoft.com/en-us/ library(d=robot)/ms173150.aspx

About the second or third time it happened I looked at the url and realized it had that (d=robot) string embedded in it.  Recognizing that search engines use 'robot' browsers to surf and index the web I removed that string from the directory hierarchy of my search result and lo and behold there was the formatted page which was human readable.

Don't know if Google isn't accounting for their robot or Microsoft has suddenly redirected robots (my suspicion) in order to better scale traffic.  But if you suddenly get an unformated MSDN page - look for the d=robot string in your url and make it go away...

Just a quick note as I prepare for tonight's presentation to the .NET Beginners User group.  http://www.sandiegodotnet.com/SDNETUG/DesktopDefault.aspx?tabid=24

Things have been a little hecktic, since I've become an instructor for the University of California San Diego (UCSD) Extension program in addition to my day job.  Between all my recent presentations, articles and Version 5.0 I have been neglecting my posts here.  Time to get back at it in preparation for next week's MSDN WebCasts.  The ASP.NET team is doing a series showing that ASP.NET isn't a IE only technology.  I have two presentations one on Tuesday the 14th and the other on the 16th.  The program is also offering free copies of Visual Studio Standard Edition if you participate in a few of the web casts.  For more information and to sign up go here: http://ad.doubleclick.net/clk;26540614;12550611;s?http://www.learn2asp.net/campaign.aspx

Now it's time to present the .NET Framework A to Z...

Just a couple quick hits from this weekend's code camp.

Firstly, I'll have the materials from all three of my sessions posted on either Wed. or Thursday of this week.  I've got another presentation Tuesday night at the San Diego .NET User Group which I'm currently focusing on, but you are welcome to attend that meeting it's down in San Diego here's their website for more information: http://www.sandiegodotnet.com

Secondly after my session on Visual Studio 2005 and SQL Server 2005 I was asked a pair of questions.  The first question was "We are seeing tools put the T-SQL text of database statements into our source code.  Is this as good as using stored procedures?".  The answer to this question was easy.  Never use text based queries in your code as that leaves the possibility that you will be susceptible to SQL Injection.  There are several tools that will try to help ensure that this isn't possible by blocking special characters etc.  but the fact is the easiest solution which is also one of the most performance enhancing is to ALWAYS USE STORED PROCEDURES.

The second question they asked however caught me off-guard.  It was "We've seen that Microsoft tends to separate the Create, Update and Delete statements into separate stored procedures.  However, other tools have combined these with a simple flag to indicate which action should be taken.  Is there a specific reccomendation?".  Here my answer was that I couldn't think of anything specific and that although I always separated the items I couldn't think of a reason that mattered beyond style.  In this case the person asking was saying they liked to have a smaller number of stored procedures.... which has it's own disadvantage with multiple developers.   But anyway after the day was over and I was driving home the correct answer came to mind, which is that you should NOT COMBINE the CREATE, UPDATE, and DELETE statements in a SINGLE STORED PROCEDURE.

The reason is quite simple, security (again).  In this case it has to do with the fact that you of course are not using your 'SA' account for your website.  You should be using an account with limited permission (for a whole host of reasons).  So what's the big deal, well in most cases we design systems that don't allow a user to Delete an entry from one of our tables.  So if I have a stored procedure that creates my entries and I of course give anonymous or external customers access to that stored procedure then that's in the scope of what I expect a hacker might at somepoint compromise and I accept that risk.  However, if that stored procedure also contains the entry delete logic, then I have no way of limiting a user's permissions at the database level to prevent a hacker who might violate a small portion of my application's logic from doing significant damage to my application.  By separating out the Create, Update and Delete logic, I can create a security model which will prevent an anonymous hacker who get's unfettered access to my create logic from also being able to delete valid data from my database.

That's the short of what I consider to be a very good reason to not combine your Create, Update and Delete logic in a single stored procedure.