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.

The slopes at Snow Summit and Bear Mountain have opened.  It's early season so it's only a couple runs are open and the services are a little limited, but crowds are also down.  We started skiing around 8:30/9 this morning went till a little after 11.  Took a lunch break till about 12 (this is the type of service that was a little limited...) Then went back out on the slopes till after 2:15 and took a break for about 30 minutes when I went back out for a couple more runs till almost 3:30.

For more infor on which runs are actually open up in Big Bear, I recommend this page which has two color coded maps (one for each resort) showing which runs are operating: http://www.snowsummit.com/photos.php

OK, I was prepping for next week's VS2005 launch event in Anaheim when an odd thought struck me.  I was looking at this slide where Microsoft was defining what a 'Smart Client' application is (as opposed to a Thin Client or Fat Client application) and I realized that the term "Dumb Client" really had dropped from the technical vocabulary.

Now I'm sure that there are some high school age kids that will classify 'dumb client terminal' right up there with punch cards.  I did a search for "dumb client terminal" and got a grand total of like 13 hits on google and like 3 hits of MSN Search.  The fact is the days when people would buy a terminal with a modem and connect to a server that ran programs on the server and provided a text only interface are long gone and with them this term.  By the way the definition of 'dumb client' meant that the client litterally had zero application processing locally. Only the UI bits are sent across the connection and keystrokes are sent down to the server for processing (every keystroke roundtrips on a dumb client and isn't even echoed to the screen until processed by the server.)

Now we talk about the 'thin client' - a browser or Remote Client Window (think Citrix) as the distributed solution, but even with a thin client the client has some level of processing - for example browsers have Java Script which requires a client processor.  We don't think about solutions that relied on true 'dumb client' hardware.  For example in a dumb client scenario even a solution based on Java Script would need to execute the Java Script on the mainframe server round-tripping the IO to the client. 

Citrix is the closest thing to a dumb client, but of course to run it you need a PC or other fat client capable machine, because Citrix itself is a fat client application, you need a client with processing power to run it.  Thus even the remaining dumb client emulator is a fat client.  Apparently the old 90's argument that there would be a balance between the fat - smart - thin - dumb client applications has been safely decided...  dumb clients are gone clients applications will always be at least thin clients moving forward - and with scripting even the thin clients are getting thicker so you can even see the trend line - heck most phones have more processing power then the old dumb client terminals, and even those mainframes that still run dumb client applications do so using a fat client based emulator...