Rest In Peace Jack

by Nick Wednesday, June 22, 2005 4:06 PM
A man whose name you probably never knew died 2 days ago. A man who has influenced your life more than you think about day to day has passed. Jack Kilby, the inventor of the integrated circuit, died at age 81 after a brief fight with cancer. He invented the integrated circuit instead of going on vacation while working for Texas Instruments... can you imagine a world where he did go on vacation? I know my life wouldn't be the same. You will be missed, and your contribution not forgotten.

Anders Hejlsberg on C#... Again

by Nick Friday, June 17, 2005 8:26 AM
InfoWorld has an interview with Anders Hejlsberg from Microsoft TechEd 2005 in Orlando. (H/T to Eric Gunnerson). It's the standard Anders interview. Anders has been with Microsoft for about 8 years now (before that he was with Borland where he architected Delphi). He's been the man with the plan on C# and .NET for about 5 years now. All his interviews are the same, and it kinda grinds on me, because this guy is amazing, and I wish people interviewing him would branch out some more.

  • So what is C#... or sometimes... why do we need C# over C ?
  • How does it compare to Java? Why nobody asks how it compares to Delphi I don't know, because there are a lot of similarities (duh).
  • How do you feel about open source movements?
  • What's your feelings about Microsoft? He works for them... what do you think he's going to say?
They talked a little bit about C-Omega which is cool, but even then it was just boilerplate stuff. It's a nice interview, but come one... lets get some more meat to it.

Making Yourself Laugh in Code

by Nick Thursday, June 09, 2005 3:07 PM
Here is a comment I left in some code I wrote a couple months ago:

' If you can understand this code... then I congradulate you. See me for a cookie.

I'm not going to publish the code, as it wouldn't make sense out of context... but let's just say I had Hashtables containing Hashtables containing ArrayLists. I'm not saying it was the smartest idea, but it worked.

Anyway, I had to make a change to this code today, saw the comment, and had to laugh at myself.

@this and that

by Nick Tuesday, June 07, 2005 10:16 AM
Chris Sells points writes about a piece of C# code that freaked him out:

class Class1 {
   static void Foo(object @this) {
      Console.WriteLine(@this);
   }

   static void Main(string[] args) {
      Foo("hi");
   }
}

In case you don't quite see it... a keyword (this) is being used as a variable to represent something other than the current object. You can do this because placing the @ before a variable tells the compiler to ignore it as a keyword. It's kind of cool, but also confusing I think. VB has a similar ability if you wrap the variable in square brackets (for instance you can name something [Me]).

I knew about the square brackets in VB, but only thought an @ in C# could be used in front of a literal string. You learn something new every day.

What Does That Mean?

by Nick Tuesday, June 07, 2005 10:13 AM
I'm looking over some code that I wrote just prior to going on vacation, and have been forced to say to myself "What does that mean?" I have variables that I'm not sure make sense in context, and I'm not quite sure exactly what they represent despite the fact that I added comments after their declaration. Even after I go over more of the code further down, I'm not quite sure it's right, even though it seems to be working. Never before have I been baffled by my own code so soon after writing it. This process generally takes several months to occur, not two weeks. I guess I was already on vacation before I even left.

I'm Not Trying to Be a Jerk

by Nick Friday, June 03, 2005 10:11 AM
Honestly... I'm really not... though it may seem that way to some. One of my projects is in defect fixing mode. That of course means we get to wade through tester's descriptions of problems, and figure out what's causing them... or sometimes figure out if there is a problem at all. I'm a stickler for reproduction steps. Some may say I'm a jerk about it. If I don't see real steps to reproduce a defect, with example files that demostrate it where appropriate... I immediately reply asking for them. I'm not being a jerk... it's just experience.

This morning was a great example. I get a defect saying that every file that has a *blank* causes a problem when he does *blank*. I don't bother to check... I immediately respond with "Can you please provide an example file?" Of course the tester doesn't send me the file that caused the problem for him... he sends a list of files that have *blank* criteria in it that he says causes the problem. Of course there was the indignant tone in his email saying it's so easy to reproduce, try any one of these hundred. Fine.. that's not what I asked for, but I'll go through your list. I went through the first 6 in the list and couldn't reproduce the defect. I reply back. "Ummm... try the files that also have *blank*." Of course he still didn't send me the actual file that had caused him the problem. Fine. I go through the first one and still couldn't reproduce it. I was going to respond back after that one... but for grins I tried one more on the list and finally got the defect to reproduce.

As it turns out, the defect only reproduced under very specific circumstances... contrary to the original defect which made it sound huge, broad, and awful. It was a simple fix, but took 10 times longer to find simply because he never gave steps to reproduce. That's why I'm picky. Had he given me the actual file that he used to cause the problem, I would have been able to turn around that defect in 5 minutes. Sometimes testers just piss me off.

In Defense of Hungarian Notation

by Nick Thursday, June 02, 2005 8:47 AM
Joel on Software has an excellent article defending Hungarian Notation, which I highly recommend. It's an excellent article which gives examples of how Hungarian is still useful today. I'm a firm believer in Hungarian Notation, and still use it to this day (properly I might add) despite the evil looks from coworkers. The problem with Hungarian was that it was bastardized over the years. When it was originally invented by Charles Simonyi at the Microsoft Apps team (think Word and Excel), it was used to differentiate variables of the same type, that had radically different meanings. For instance, two variables might represent coordinates with DWORDs, but one might be relative to the screen, and one might be relative to the page. Assigning directly between the two would cause an error, but would be syntactically correct:

DWORD xwCell;   // Cell location relative to Window
DWORD xlCell;   // Cell location relative to Layout

// ... Later on

xwCell = xlCell;             // Logic Error
xwCell = XwFromXl(xlCell);   // This is Ok, we converted.

Somehow (and Joel explains this), Hungarian got bastardized so that the prefix was only used to denote the variables physical type. So you would get code that looked like this instead:

DWORD dwCell;    // Cell location relative to Window
DWORD dwCell2;   // Cell location relative to Layout

// ... Later on ... imagine a couple screens away

dwCell = dwCell2;   // Logic Error... but would you know it?

As you can see... the Hungarian that eventually took hold has much less utility. Sure it's nice to know that a variable is a DWORD, but that doesn't prevent the logic error. Maybe it's the fact that I'm a huge fan of code reviews that makes me like Hungarian. I actually print out code and go over it with a pen and highlighter. I write notes, I ask questions... and having conventions that make these errors pop out at you help more than you can know.

About Me

Nick Schweitzer Nick Schweitzer
Wauwatosa, WI

Contact Me
I'm a Software Consultant in the Milwaukee area. Among various geeky pursuits, I'm also an amateur triathlete, and enjoy rock climbing. I also like to think I'm a political pundit. ... Full Bio

Community Involvement

Twitter

Archives

Flickr Photos

www.flickr.com
This is a Flickr badge showing public photos and videos from Nick_Schweitzer. Make your own badge here.

Standard Disclaimers

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2014 Nick Schweitzer