Ada Lovelace Day: Julie Lerman

Apparently today is Ada Lovelace Day (more information here). It's an opportunity for bloggers to write about women in technology who have inspired us. That makes this the perfect time to write a few sentences about one of the programmers who has been an inspiration and friend for around 5 years now - Julie Lerman.

I originally met Julie because she runs our local .NET user group. She works tirelessly for this group. She ensures the meetings are scheduled, maintains the web site, arranges for speakers, getting little gifts for them and presents her own topics when speakers are hard to come by.

Her technical skills, energy and humor are wonderful. But that's not why I wanted to write about her on this day.

It is Julie's dedication to community which is inspiring. She continually works to foster a real sense of community among the people who attend the user group. There's the usual call for people to raise their hands if they are looking for work or looking to hire (what I call the "Love Connection" portion of the meeting). She encourages people to get up and do their own presentations - both at our meetings but also at regional code camps (we don't have a local one... yet). At our last meeting she took a moment to lead a discussion to brainstorm how we as members of the same community (professional and regional) might support one another in this period of economic uncertainty. Julie is sure to introduce you to people "you've got to meet."

Julie's dedication to community transcends our small state, by the way. She travels the world speaking at conferences and user groups. She participates on "women in technology" panels (perhaps inspiring an upcoming Ada Lovelace). She blogs and has written a book. Julie is one of those people that wants to see others succeed and will do a lot to try and help.

She's a true leader and an inspiration.

Debugging tips from the MSDN Roadshow

Yesterday I attended the VT leg of the MSDN Roadshow. While I was unable to stay for all the presentations I picked up some good tips during Jim O'Neil's overview of debugging with Visual Studio 2008 (with a preview of VS2010 debugging). As is my habit, I'm putting my notes from the session here so I don't lose them and so others might benefit from them.

But if you write bug free code you can stop reading here.

One thing that used to bother me was that if I had a line of code that chained or nested several method calls I would have to step into/out of all the methods until I got into the one I wanted. Apparently Visual Studio supports the ability to step into a specific function. I saw Jim do it yesterday, I can see the web sites describe it, but I can't find it in my environment. So it's something to research.

There is another thing I saw and can read about but can't find in my environment. Apparently there is a setting under Tools | Options | Debugging which allows you to step over property and operator calls by default. Again, something to research.

One thing I do see in my environment, and which I believe I can find use for, is the HitCount property of breakpoints. The breakpoint window displays this property for each breakpoint and should prove useful when trying to identify which iteration within a loop is causing a problem (for example).

Finally, Jim reminded me of the DebuggerDisplay attribute that we can use to decorate our classes to make them more user friendly in the debugger. Here's one overview of that attribute and another from Scott Hanselman.

Love the free training...

I don't care what they say... 6 != 4

When writing a SQL query today (against SQL Server 2005) I came to realize I can't trust the len function. Well, ok, I can trust it but not if the value being evaluated has trailing white space. Take this code:

Declare @value char(10)
Set @value = ' 123  '
Print Len( @value)

Notice I set @value to ' 123 ', that's [space][1][2][3][space][space]. Now even if I count like my 6 year old that's 6 characters. But what does the code above say? 4. Four?!?!? Lies!!!

And it lies to me if I declare @value as char, nchar, varchar and nvarchar data type. I can see varchar because it's a variable length data type. However char is a fixed length data type so I was expecting either a length of 6 (I did, after all, assign a string literal with 6 characters) or 10 because @value was declared as a char(10).

So I don't know what to believe anymore.

Ah-ha! I knew I never liked that feature

Part of the new job is re-familiarizing myself with ASP.NET development. I've done this before, obviously, notably at my last job writing web services. But it's been a few years since I've done web pages. So I'm reading Dino Esposito's book "Programming Microsoft ASP.NET 3.5". It's a thorough book; or at least it is so far - I'm only into chapter 2. But what I find I just had in chapter 2.

One of the things the developers at my last shop used to "debate" was whether to develop web applications and do development testing against IIS or the embedded local web server available to Visual Studio 2008. I was always an advocate for developing so the various web services I needed would be available via my box's IIS - I liked the fact I could have a web service available to me without having to included it in my solution. Other developers liked the fact they didn't have to maintain their IIS setup. Once we discovered a project can be set up to allow the developer to work as they prefer we stopped having these "discussions" (because updating the project file from source control no longer messed you up).

But I just read the definitive reason why I would advise people to not use the embedded web server. When your code runs using that server it assumes the level of credentials of the windows account you're signed in as. For far too many of us that means our web code would be running as administrator on the box. This rocks for us as developers because we don't have to worry about all those pesky security issues we would otherwise encounter.

But we're really just kicking that can down the road. For me it comes down to addressing those security issues sooner rather than later. Because it's not like those security concerns aren't going to be raised when the code is put on the test server, or production, and by then it's more expensive to fix (not to mention embarrassing).

So I say:
<FrankensteinVoice>
Embedded web server -baaaaddddd
</FrankensteinVoice>

I hope you do, too.