Thursday, November 26, 2009

The Gu Rickrolled no one

You may have heard about Scott Guthrie’s Rick Astley related stunt at the PDC in Los Angeles last week. I don’t think it qualifies as a rickroll. As a developer who uses Microsoft technologies, I have sworn to The Gu’s super-duper deluxe uber-geekiness.

IMO, to qualify as a rickroll, you must willfully click on a link expecting something juicy and end up on suffering through “Never Gonna Give You Up”. You make a bad decision that makes you worthy of such punishment.

If you clicked on a link for Paris Hilton’s latest video (wink, wink) and instead got Rick, you have been rickrolled! If you clicked on a link marked Rick Astley’s famous video, you haven’t been rickrolled, you are getting what you expected.

At the PDC, The Gu’s victims didn’t have the free will not to click the link or take the red pill. In this situation, The Gu launched the video.

If one of The Gu’s minions changed out the “real” video with Rick Astley without his knowledge, then he is the only rickrollee.

It could be argued that the attending a Scott Guthrie presentation is bad decision that qualifies one to be worthy of being rickrolled.

Thursday, November 12, 2009

Rant on XML Comments

The purpose of .NET XML comment is to help you generate outside documentation. When you tell Visual Studio to generate the XML file, you get tool tips when you hover over your method and you can use a tool like SandCastle to generate MSDN style help files based on your XML Comments. XML comments are really designed for Black Box documentation of Frameworks and API.

An XML comment is not the same as a development comment. When I am looking at a SandCastle generated help file, I care about how to use your class or method; I don’t care about why you chose to use a bubble sort over a quick sort.

I’ve seen comments like this:

///<summary>
/// DV
///</summary>

where DV is the initials of one of the developers. If you were actually use the XML comment feature, this comment would show up when you mouse over the class in Visual Studio or in the help file you created with SandCastle, same with this comment:

/// <summary>
/// This is the FooBar class!
/// I originally designed on a napkin after midnight after drinking 
/// a fifth of JD & eating 3 orders of hot wings.
/// I was inspired to write this class after Ellen, the goddess of 
/// the 327th Ave NE Pub down the street from my studio apartment,
/// who rejected me after I drank myself silly summoning up the 
/// courage  to ask her out.
/// </summary>

With the VS tooltip feature you lose all formatting, so if you have a comment like

/// <summary>
/// Foobar Class
///
/// Combines Bars with Foos and converts them from Metric to Imperial
///
/// 2005-04-13 – RN – Original implication 
/// 2005-05-03 – RF – Bug #12239 – g to # conversion issue
/// 2008-03-27 – VW – re-Implement Linq to Foo framework
/// </summary>

will appear on 1 or 2 lines without the linefeeds. The tags are ignored when VS creates tooltips.

I know that most of the projects I work on are not frameworks or API, but it still feel the need to avoid using XML comments for things other what I think they are designed for.

I am uptight about XML comments because I have used them, once. We created a help file for a client using SandCastle; the customer was impressed, though I bet they never used it.

Sunday, October 11, 2009

How bad is too bad?

I have been assigned the task of updating a program that isn’t terribly well designed.

How deep do I dive in trying to fix this program? Do I take all of the inappropriate code from the Form Classes and move them into Business Classes? Do I get rid of all the SQL queries in code? Do I tear the whole thing to shreds and start over with my brilliantly planned super object oriented design applying all 23 GoF design patterns? My inner geek screams yes, Yes, YES! But according to Joel Spolsky, rewriting software just to do it can be the biggest mistake “you” can make. (http://www.joelonsoftware.com/articles/fog0000000069.html).

I mean, the program basically works. If the world around the program wasn’t changing, it could probably go unchanged. But we’re replacing one system that this program talks to and replacing it with another one.

Looking at the code, I would date the program to around the 2003 timeframe with stuff added later as the program evolved. I see:


  • Int32 in place of int, String in place of string, etc. (I remember reading and hearing experts recommending that practice in the early days of .NET)

  • Long unstructured functions in the form class. Sort of like VB6 in C#, we know that a lot of that went on in the early 0's.

  • There is some object orientation grafted on to the edges of the program but the core is pretty old fashioned pre-OO .NET 1.0 code.

  • Uses finally in places where rational modern C# coders would use using.

So it isn’t wonderful code, but, for the most part, it works. But like any spoiled brat, I just wanna do it. Why: just because.

The program was written in the ancient times of yore (5 years ago). When .NET first came out, OO was just starting to catch on in the mainstream. Right now I am hearing rumors that the next big thing is going to be Functional programming; the justification is that it is easier to parallelize so elements of the Functional Fad will probably stick around for the long term. What will my elegant OO code look like to the Functional masters of the future?

Tuesday, September 22, 2009

SQL Funny Business

Today at work we were talking about mixing old (table, table where join criteria) and new (table join table on join criteria) style joins in the same query. So that got me to thinking about what ON really does. I ran the following queries against the infamous Northwind Database:

-- The modern style join:
SELECT *
FROM dbo.Orders o
 JOIN [Order Details] od ON od.OrderID = o.OrderID 
WHERE o.CustomerID = 'SUPRD'

-- The classic style join:
SELECT *
FROM dbo.Orders o, [Order Details] od
WHERE od.OrderID = o.OrderID
 AND o.CustomerID = 'SUPRD'

-- Inverted modern join (join criteria in WHERE, selection criteria in ON):
SELECT *
FROM dbo.Orders o
 JOIN [Order Details] od ON o.CustomerID = 'SUPRD'
WHERE od.OrderID = o.OrderID

All three queries gave me the same results set.

Is the ON clause just a different place to shove selection criteria (a phantom where). I like the modern style. You can put all the join information together. You could mix things up when you practice Job Security Based Programming.

I think it would be fun to have a obscure SQL programming competition, like the obscure C programming competitions in the days of yore.

Monday, August 31, 2009

Is it too late to wrap it into a function?

Today I was refactoring several properties in a Business Class from int to int?. I was in a hurry, so I was implementing the 10 properties using cut and paste inheritance (as if that is ever really faster).

After the 8th or 9th properties, the light went off in my mind: I should write a couple of functions to do the hard work and call the functions from the property get and set functions. Was it too late to to do it right?

I said NO.It did take me longer to write the functions than it would have taken to cut and past the 2 remaining properties. However, the code is easier to read, validate and change.

I guess I justify my earlier sloppy coding time as an opportunity to think of the right way. During the first go round I was planning to do the second one; I needed to do it wrong to see how to do it right.

Friday, July 31, 2009

New Team, New Ways of Thinking

I have recently started working on a new team.

The new team uses a different architecture, different naming conventions, file organization, source control, etc. The new team is uptight about different things than the old team.

I am learning to think differently, reevaluate my old ways and adapt the new things from the new team.

In the long run, I think it is a good thing; I need change to avoid ruts and learn new ways of approaching problems

Monday, June 15, 2009

Access 2007 Trap: Life without @@identity()

I came across some interesting behavior in Access 2007 that tripped me up for a little while.I needed to add a record to a table and then get the primary key value of the newly added record.

I wrote the code that I expected to work and I always got back the same number for the primary key every time I ran the code; the value of the primary key value of the first record.But I wanted the primary key value of the last record, the record that I just created. So, I added .MoveLast to get the last record.

   Dim rs As Recordset2
   Dim recordId As Integer
   Set rs = Application.CurrentDb.OpenRecordset("Table_1")
   With rs
       .AddNew
       !field_1 = "Field_1"
       !field_2 = "Field_2"
       ' I expected the the primary key value to be loaded here:
       .Update
       ' When you open a recordset, there is an implied "MoveFirst" call
       ' For whatever reason, Access doesn't refresh values after writing
       ' the record:
       .MoveLast
       ' Without the MoveLast, you get the record_id of the first record:
       recordId = !record_id
       .Close
   End With
   Set rs = Nothing

I guess the thing that screwed me up is that I expected all of the fields in the current record of a RecordSet2 point to the same record. In my mind, when I call Update, the value of the primary key should be retrieved and ready for me to reference.

In ADO.NET, the DataSet has the AcceptChanges() method. This is logical to me because a DataSet is disconnected. I guess a Recordset2 is "loosly" connected.

Access continues to weird me out.