Darrell Norton's Blog [MVP]

August 2003 - Posts

• Random Observation

  The people that probably know the most are also the ones trying hardest to learn. Posted Aug 27 2003, 04:10 PM by darrell with no comments

• Be careful using Server.Transfer

  Server.Transfer bypasses the authorization for the page you redirect to.  So if you use Server.Transfer instead of Response.Redirect (for other pros and cons of each see this article on managing navigation in ASP.NET by the excellent Mike Gunderloy), make sure that the authorization to access the target page is performed before the call to Server.Transfer.  If you use Response.Redirect, you do not have to worry about this.  Yet another reason why I almost always use Response.Redirect. Posted Aug 26 2003, 08:07 PM by darrell with 1 comment(s)

• [Verbatim Identifiers: Part 2]

  Paul Laudeman commented on my Verbatim Identifier post on how to differentiate identifiers from keywords in VB.NET.  I didn't want this to be lost in the comments section of the post, so I am reproducing his comment in its entirety. For anyone who is interested, the way to escape keywords in Visual Basic .NET is with brackets enclosing the keyword. For example: Public Property MyVariable as MyEnumType Get     Return _myVariableType End Get Set(ByVal Value As CalculationType)     If (Not [Enum].IsDefined(Value.GetType, Value)) Then         Throw New ArgumentException("Specified type is not valid.")     End If     _myVariableType = Value End Set End Property (notice the brackets around the keyword Enum). Maybe it's the fact that I've been buried in T-SQL for the last 3 weeks, but this is the same way T-SQL differentiates keywords from table and column names (just like the @symbol in my original post).  Is T-SQL something that Microsoft uses as the default answer to issues like this?  Or is it some overriding MS scheme?  Maybe soon we'll all be writing SELECT @variable1 = MyVariable. Posted Aug 25 2003, 08:05 PM by darrell with no comments

• NUnit v2.1 RC released

  NUnit v2.1 RC1 was released last night on SourceForge.  From the release documentation: * Support for the .NET framework versions 1.0 and 1.1 * The ability to run test suites across multiple assemblies * New TestFixtureSetup and TestFixtureTeardown attributes * Improvements to the GUI interface * New command line switches for both GUI and Console runners * Some degree of integration with Visual Studio * Tests now execute in the same order as they are displayed in the gui. * Substantial improvements in error and exception reporting. * Now runs on Windows 98 Support for v1.1 of the Framework is no big deal, all you had to do was change the application config file.  I'm interested to look into what the integration with Visual Studio is like and the improvements in error reporting.  I use NUnit more often than I fire up the debugger, so hopefully this will further reduce my dependency on VS.NET's debugger.  The TestFixtureSetup and TestFixtureTeardown attributes look like they can reduce the processing cycles required, and thus speed up running the tests, since the code in them is only executed once per TestFixture, instead of before and/or after each Test (which is what we are all doing now, right??).  I'm reserving judgement on the test execution order display.  Tests should be standalone, with no dependency on any other test.  I am afraid that such a feature will encourage bad development practices (i.e., writing code that depends on the order of the tests running instead of creating idempotent tests). Posted Aug 25 2003, 07:46 AM by darrell with 1 comment(s)

• The Design of Everyday...

  I brushed off my copy, it actually was dirty, thanks to my recent move, of The Design of Everyday Things and reread it over the weekend.  I have the 1990 edition (white cover). For those who have not read this wonderful usability tome, it discusses how difficult it is to use things that used to be simpler to use, before they became sophisticated.  One of Donald's favorites is the telephone, to whit he devotes about 10 percent of the book's pages to.  The reason for the frequency?  We use telephones everyday and its uses are well known, however the usability among different designs varies wildly.  Some examples reveal the book's age; this may have changed in the 2002 version, but I do not know for sure.  For example, one reference is to computer passwords that must be at least six characters long and contain no words.   Now, passwords must be at least eight characters containing a mix of lower and upper case letters, numbers, and some special or non-printable characters! After reading this book the first time, I was a usability "guru," or so I thought.  I walked around for the next two or three weeks pointing out bad usability design (in manufactured objects, not software) to myself or to anyone else unlucky enough to be nearby.  I felt like starting my own usability company and making some serious dough pointing out such deficiencies!  Of course, these were only things that were unusable to me, not necessarily everyone else. This time is different, however, probably due to significant experience in a career as a software developer.  I am struck that pointing out the usability issue is not the important part.  The important part, especially as it applies to me as a software developer (WIIFM), is the asking of "why?"  Asking why works really well in improving my understanding of such immense class libraries and hierarchies as the .NET Framework.  Why did the designer choose to do this?  Why was the API structured like it is?  Are there advantages to doing things this way?  How does it make developing easier on me?  If it makes certain things harder to do, are there other parts of the Framework that make it easier to do those things another way?  And with the ever-increasing size of .NET, I need all the help I can get! So, unlike the slogan for the [now defunct] Bud Dry product, "why ask why?", actually ask why! Bud Dry and its slogan are probably trademarks of Anheiser-Busch corporation. Posted Aug 24 2003, 08:25 PM by darrell with 2 comment(s)

• Verbatim Identifier

  Mark Michaelis posts about Using @ to Disambiguate Keywords from Identifiers in C#.  So, if you want to call a class “class”, you could do it like this: class @class {     static void Main()     {         @static(false);     }     public static void @static(bool @bool)     {         if (@bool)             System. Console.WriteLine("true");         else           System. Console.WriteLine("false");     } } Or, call a return variable “return”: public string GetName() {     string @return;     Console.Write("Enter your name:");     do     {         @return = Console.ReadLine();     }     while (@return.Length == 0);     return @return; } Cool, though it looks like a T-SQL variable now.  Thanks Mark! Posted Aug 21 2003, 08:31 AM by darrell with 4 comment(s)

• Development team facade

  One of Extreme Programming's practices is OnSite Customer (also see Martin Fowler's definition of OnsiteCustomer). Although it is good if each programmer can constantly ask questions of the customer whenever they need to, it is not good if the customer has the same ability.  Anytime the customer wants to ask a question, just being able to call up a developer kills that developers concentration, subsequently killing his productivity.  On the other hand, if the developer is able to get an immediate answer to his question, it maximizes productivity. The solution is to designate someone to run "interference" for the developers.  Who runs this interference?  In Brooks' The Mythical Man-Month, the role is assumed by the copilot, who attends all meetings, answers all technical questions, and acts as the general technical answer guru for the project.  This leaves the surgeon (chief programmer) with all his time devoted to programming.  In my own experience, I was the technical lead and ran interference for my team.  Although I might not have made much of a contribution to our body of code directly on some days, my real accomplishment was enabling the other 8 developers to contribute 100 percent every day (8 * 100% is much more than 9 * 80%). So what this really is is a facade for the development team.  The customer is supposed to speak with one voice, and they speak to one person who will get them the answer or pass it along to a developer.  Does this then break the facade?  I don't think that a developer has to go through the team spokesperson to communicate with the customer, but it helps.  In our case, it avoided anyone calling a developer back or stopping by our work area and standing over our shoulders for hours.  I don't tend to think of email as a distraction, since you can just not check it.  You might argue that most phones can have their ring disabled.  Most can, but I like to keep the phone as an option for extreme development emergencies, such as when the CEO puts you on the spot in the middle of a seemingly innocent status meeting. Devoted readers of Martin Fowler's bliki will note that in PleasingTheCustomer it says that a major source of enjoyment is direct developer-customer interaction.  While I certainly agree with this, I do not think that it requires 100 percent all-day everyday direct interaction.  Sometimes you just need to get things done... alone.  Completed iterations, milestone deliveries, or whatever progression of steps your project goes through, are excellent times for everyone (business people and developers) to get together and party.  In my experience this is usually enough, but if there needs to be more interaction to chase down a troublesome and elusive bug, then so be it.  As always in agile development, people over process. Posted Aug 20 2003, 07:28 PM by darrell with 2 comment(s)

• Everybody's in on it!

  Mark DiGiovanni, one of several excellent developers I have had the pleasure of working with, has started a blog right here on DotNetJunkies weblogs!  Subscribed, of course. Now if only we could get Brendan and Eric in.... Posted Aug 19 2003, 07:42 PM by darrell with 1 comment(s)

• Microsoft Programming Languages according to Microsoft

  MSDN just published an article on Microsoft Programming Languages.  Here's a summary (all terms are as presented in the white paper): VB.NET: task-oriented development C#: code-focused development Managed C++: power-oriented development J#: Java language development Very interesting reading... Posted Aug 18 2003, 07:21 PM by darrell with no comments

• Grant Killian is blogging

  ”Surround yourself with people smarter than you.”  And with that, I would like to welcome to the blogging community Grant Killian, President and co-founder (with me!) of the WeProgram.NET user group! Posted Aug 17 2003, 08:20 PM by darrell with no comments

• Blaster worm blogging: whose fault is it?

  There are a bunch of posts over on .NET Weblogs @ ASP.NET about the blaster worm and whose fault it is (see the original post, one response, another, and another).  Basically one side, the developers, says sysadmins are to blame.  The other side, the sysadmins, says that they are not to blame, they are so overworked, and it’s all the software developers fault. I’m going to have to agree with Frans’ post.  The blaster worm is coming through port 135, which should never be open on an Internet-facing network connection.  A simple firewall (which comes bundled with Windows XP/ 2003, or a free download) stops this attack even without the patch.  As one post mentioned, yes it takes a while to roll out patches in a production environment.  But you should have all the time in the world, since this worm should not get past a simple firewall configuration setup. So if you are an overworked sysadmin and your systems are crashing all around you, I’m sorry but don’t blame the software developers.  Either it is your fault for not setting up proper security, or it is your predecessor’s fault.  Blame him (or her) or yourself.  And for those sysadmins that complain about developers infecting the network via laptops that they took home at some point in time, that needs to be part of your security policy.  If you cannot handle the extra work that goes along with allowing multiple points of presence, then simply do not allow it. Now this might sound harsh, but at my previous job at a large defense contractor, there were many things we were not allowed to do (or which were insanely difficult to do) which seemed ridiculous at the time.  We complained all the time, honest.  But then we never fell victim to these types of attacks either. Posted Aug 15 2003, 06:14 AM by darrell with 5 comment(s)

• Paul Laudeman is blogging

  Fellow DotNetJunkie and my long time buddy Paul Laudeman is blogging.  He worked with me at our last company and got me my job at our current company.  If he's half the writer as he is a developer, you're in for a treat. Subscribed! Posted Aug 14 2003, 08:40 PM by darrell with no comments

• Pair Programming: the good, the bad, and the ugly

  I've been doing pair programming for the last week and-a-half (in T-SQL).  I've done pair design and code reviews before, but never tried true pair programming.  It is pretty hard, let me tell you. First, the good points.  We finished in just over 2 days what was scheduled to be completed in 5 days.  The quality is very high, things look good, and we know how to extend the base primer stored procs to accommodate future changes in required data.  I was better at T-SQL programming than my partner was, and he was much more familiar with the business logic and data model than I (since I've been working on the project about 5 days total).  He would explain what he was doing as he went along and I would ask questions if I did not understand something.  In the beginning, I just stared back at him as he talked.  I probably looked like I had an IQ of 20 (it's at least 25, honest!).  But as time goes on, I am picking up a good understanding of what we are dealing with and how it all fits together much more quickly. On the other hand, I contributed a lot of SQL knowledge and basic error-checking before we compiled and ran the procs (which, if we ran the entire set, took 20+ minutes), so this definitely sped things up.  Also many times, my partner would be thinking 2 steps ahead of his typing, and would skip something that immediately jumped out at me because I just saw him do it 5 minutes ago.  Time saver again!  Plus, it seemed like there was something that helped about having to explain and defend yourself to another person.  It forces you to be pretty darn sure of what you are saying. Now, the bad.  Many times it was very frustrating to have to "bring the other person along" when you were on a roll.  All aboard!  The train is leaving the station!  You don't want to have to stop the train to pick up the late passenger.  Another aggravating thing is when the other person does not use keyboard shortcuts!  So many times I wanted to scream "Use the keyboard shortcuts!"  (I bit my tongue instead, and I think it worked out better that way.) On the whole, I think this was a very good experiment with some very good results.  As we finish work on the critical base of this application and commence to writing easier report queries, I think we will split up.  I will be able to write queries without having to bother my partner too much, and he can figure out how to fix SQL errors without asking me all the time. Posted Aug 13 2003, 07:43 PM by darrell with no comments

• First time on a fast connection

  Hi-speed Internet baby!  Woo-hoo!!! Posted Aug 09 2003, 10:51 AM by darrell with no comments

• The Balance of Power in IT

  Steve Maine had a good post on Yukon and the balance of power in IT. I agree completely. The days of the strict "Admin DBA" are numbered (hopefully, anyway). Since most software development is moving to a more collaborative model, you cannot say "I only deal with schema," or any other specific technology or niche interest. To contribute and collaborate, you must be willing to work with your team and do whatever needs doing. Sometimes I make the coffee. Is that in my job description? Is that why I have a master's degree and a bunch of Microsoft certs? No, but somebody has to do it, and since I want some I might as well make some. (Luckily we have Starbucks, so life is good!) And in the end, team members and bosses notice this stuff. Posted Aug 08 2003, 06:30 AM by darrell with no comments