Thursday, December 27, 2007

MythBusters Nerd Edition: Actually Running "FORMAT C:" Was a Big Let Down

I've heard many people (myself included) joke that the best solution to a problem is to do a "FORMAT C:"

Growing up in the around computers, it was one of the most feared commands I could think of typing.

Armed with the benefit of a Windows XP Virtual PC image, I thought I'd actually confront my childhood fear:



What a let down! It won't even let you do it. I even tried a forced quick format.

Alas, another myth broken. I guess there's always "rm -rf /"

UPDATE: Check out Jonathan's post where he was much more persistent in his attempt.

Saturday, December 22, 2007

How the legacy of a dead mathematician can make you a better programmer

When was the last time you were challenged by an algorithm? As professional programmers, we often spend our day tackling things like:

The list goes on and on.

But again I ask, when was the last time you were challenged by an algorithm?

I remember when I was 13 and writing a program for my aunt to help her schedule appointments for people. I had to make sure that people weren't scheduled on holidays like Christmas. I was writing the program in BASIC and it required me to learn things like Julian dates. Days like Christmas and the 4th of July were easy because they always fell on the same day each year. The first one to really give me problems was Thanksgiving. Every stinkin' year it was on a different date!

The solution baffled me at the time. I even made use of my access to this new thing called the "Internet" and asked puzzle gurus there for help. I believe later that day I went to Old Country Buffet with my family and kept thinking about it. After loading up on food, we were walking back to our car and it hit me: "start with the first Thursday in December and subtract 7 days!!" I already had code that told me what day of the week a Julian date fell on, so this was easy. After realizing this wouldn't work for Thanksgiving 1995 which was two months away, I think I corrected it to find the first Thursday in November and then calculate the right number of days afterwards.

I'm sure you're laughing at my early struggles. It's probably "intuitively obvious to [you,] the most casual observer" what the right algorithm is, but for my 13 year old self, it was hard.In college, I especially remember being challenged by algorithm problems like figuring out what words to suggest for a mispelled word. The algorithms were non-obvious and took time to figure out. However, in the end, I usually ended up growing in my understanding of computer science as a result of solving them and in the process added a few more tools to my algorithmic toolkit.

After graduating and entering "the real world," I rarely had to wrestle with an algorithm and instead focused on more tactical issues like the bullet points above. This always nagged at me; I felt as if I was somehow "rotting" in my computer science abilities. My thinking was that if I kept getting bogged down in the tactical, day-to-day stuff, I'd never be able to "hit the high notes" as a developer. It's been this fear of skills rot that has pushed me to look into Lisp, Haskell, F#, Erlang, and other languages to avoid The Blub Paradox. It's what drives me to attempt to attack code bloat, read modern papers and watch videos of people way smarter than myself. It's what makes me think of books like Code Complete, Code Craft, and Framework Design Guidelines each time I write code.

And lately, it's what drove me to the legacy of a dead mathematician. I found ProjectEuler.net last week. It is a website dedicated to problems that can be solved efficiently with a good algorithm that runs for less than a minute. It's in memory of the master mathematician, Leonhard Euler, who loved to "tinker" with mathematics and algorithms. I'm sure he'd probably work at Google if he were alive today.

What I love about ProjectEuler is that while some of the problems are very challenging, they are at least possible for me to solve. I've seen way too many contests that just are no fun because they take too long to solve or are just too hard.

Some took me only a few seconds to figure out, some have taken me an hour, and some I still haven't been able to solve. The real fun part is that once you solve the problem, you are granted access to a forum where people discuss their solutions. It's there where I've been most humbled. I might have taken 40 lines of code to figure out something someone did in a few minutes using a one line program in J, a language that I had never even heard of before. Still others will do it in Haskell or Python in a couple lines of code. Some brave guy consistently writes his solution in x86 assembler.

My approach has been to use C# 3.0's new features whenever possible. I was thrilled to be able to solve problem #19 in 1 line using LINQ concepts. I also really had fun with #56, writing an algorithm to decode a secret message. Although the site looks heavy on math, it's more about thinking algorithmically and no problems require fancy math beyond what you would have learned by high school.

I'm not saying ProjectEuler.net is the only way to improve as a developer. I'm sure some folks have very busy schedules with kids and other activities that make it almost impossible to study anything outside of work. However, I've found tackling a ProjectEuler problem can easily be more fun than watching an average weeknight TV show or just surfing the web in general, but that's just me.

What do you do to sharpen your algorithm saw? Are you registered on ProjectEuler? If so, what's your username? (Here's my profile) I'd love to learn from you if you post your solutions on the forums. It could be fun to have a friendly competition.


kick it on DotNetKicks.com

Saturday, December 15, 2007

VB: The 800 lb (363 kg) Gorilla in a C# Fanboy World?



In show #92 of Hanselminutes, Paul Vick mentioned something that really surprised me and others. It wasn't the fact that Visual Basic .NET Express Edition is the most downloaded Express Edition, but that the C# Express Edition was a distant third behind C++.

I trust Paul's data, but what could explain this? Does this simply mean that the majority of .net programmers have professional Visual Studio licenses or does this data reflect the real usage as a whole?

When I was in college and .net just came out, I immediately jumped into using C# 1.0 because I was immersed in Java and C++ programming at the time. After graduation and starting working in the "real world," I drifted more towards VB.NET (when writing managed code anyway) because I was doing quite a bit of COM interop with Office and I despised the fact of having to explicitly declare "missing" parameters to the methods of the Office object model. Furthermore, I thought that the VB syntax was easier to maintain. I even defended the decision saying that great projects like DotNetNuke proved VB was a viable language.

After a few years though, I drifted back to C#. More than anything, I came to admire its terse syntax quality. While VB has no problem with things like "End If", C# simply says "}" In the latest generation, it's more of the difference between the lambda syntax of "Function(x) x + x" versus "x => x+x".

Maybe there's something to be said about the last statement? Maybe C# attracts those that just prefer terse notation? I'm sort of reminded of 16th century mathematics when solving a cubic equation (e.g ax^3 + bx = c) was all the rage. What's most impressive is that this was done using rhetorical methods instead of modern algebraic notation that would kicked off by Vi├Ęte a few decades later.

I don't mean to imply that VB is inferior. I owe a lot to BASIC, it was GW-BASIC that got me started in my love of programming. It's just that VB (and BASIC in general) has a rhetorical quality of being easier to pick up since it looks closer to natural language rather than the symbolic mathematical world. This is probably why lots of people are using it to get started programming. I think that's fantastic since it brings more people to the .NET platform. Sure, they might be "spreadsheet gurus" who started in VBA, but at least they're learning.

Maybe we can learn from the three thousand years of the evolution of mathematics. It wouldn't surprise me that in 15 years, a language like F# ranks third place or higher. Maybe the popular language will be closer to Sun's Fortress?

What do you think? Were you surprised that C# ranked third? Will terseness win out? Feel free to comment.

UPDATE: When I wrote this post, I forgot about Paul's post on "The silent majority." It and its comments are a better discussion of the topic than I gave it.


kick it on DotNetKicks.com

Thursday, December 13, 2007

Live from the IndyNDA VS2008 Installfest

This post is coming to you live from IndyNDA's Visual Studio 2008 InstallFest.

I have been coming to IndyNDA for about 18 months and this is by far the largest turnout (outside of Indy Tech Fest). It's amazing what giving away tons of stuff for free will do to the crowd size. I had a good time listening to what other people have been doing with Visual Studio 2008 and the 3.5 framework that came out last month. In addition, I hope the turnout to this event will continue to encourage Microsoft that Indy is capable of hosting a TechEd or maybe a PDC once our updated convention center is up running at its new capacity.

Some highlights: I was shocked and humbled to win the demo award with around 36 votes. I won a Zune! Thanks Dave! In addition, I also won a raffle prize of a brand new Microsoft Press Best Practices book on defect prevention.




P.S. Afterwards, I watched Dan and Aaron play Guitar Hero on the XBox 360 for a little bit:



I don't think I have the hand-eye coordination for that one.

UPDATE: IndyNDA's site has a few pictures of me up front: [1], [2], [3], [4]

Saturday, December 8, 2007

Thought Snippets for the Week Ending 12/8: Shock absorbers and getting Visual Studio to do VIM's % trick



  • "Software should have shock absorbers and circuit breakers" - Michael Nygard. I think far too often we think about having exception handlers and think we're done. I really like Michael's analogy. It makes the case for a more comprehensive, watching out for the user, software design.

  • By far, the biggest tip I started to employ this week was using "Ctrl + ]" to do brace matching in Visual Studio. For over 5 years I have been using this feature in VIM by pressing the % key. It was a joy to learn that Visual Studio does it as well.

Thursday, December 6, 2007

Tip: Organize RSS Feeds by Tag Tiers

I have this odd interest in being fascinated how people organize their desktop, outlook folders (ooo, they have a 'BlogIt!' folder!), and especially RSS feeds. A few months ago, I saw a screenshot of someone's Google reader setup and he had tags like "technology-tier1." His post wasn't even his organization system, but I immediately thought it was brillant -- so I borrowed stole the idea (I honestly can't remember who I got the idea from). It's worked out pretty well. Here's a snippet from the left side of my reader:



This has led me to create fuzzy heuristic such that if I really like a feed, I'll put it in tier1 right away. If it starts to be boring, I'll move it down a tier maybe 1-2 weeks later. If it persists, it goes even lower. Alternatively, if a blog has reasonably good content, but not fantastic, it might go into tier2. If I find myself enjoying the posts, it might eventually make the move into tier1. If a blog has the occasional gem amongst lots of noise, it might permanently remain at tier3. If it looks like no gems will ever come, it gets removed altogether.

Why use tiers? Well, I have a personalized Google home page that I probably frequently during the day since it is my, well home page. It has several reader gadgets each with one focused tag. I typically only have my tier1's (software is the exception and has tier2 stuff on a different personalized tab). That is, I have boxes like this:




This makes it really fast access to good stuff and keep current. For tier2 and tier3 stuff, I'm forced to actually open up Google Reader (which I do much less frequently), and even then I typically just skim things and press "mark all as read" unless I see a possible gem.

Tiers are the only sane way I've found to keep up with the 320+ feeds I have now. Each feed made it in because it had something good on it and I like the wide coverage. It's hard to imagine that I actually used to go to sites one by one before. RSS has really changed the way I get information.

How do you organize your feeds?

Saturday, December 1, 2007

An Often Neglected Feature: Task Lists in Visual Studio

Often in code, I would put comments like this:

// TODO: This needs a better name


which is quite normal. But I almost never took advantage of them fully by having the Task List feature turned on: Which puts a nice window at the bottom:


That will allow you a simple double click access to any comment that starts with "TODO", "HACK" or "UNDONE"

In an effort to get better at tapping the power of Visual Studio, I've added Sara Ford as a top feed in my reader.

Thought Snippets for the Week Ending 12/1/2007

Here's the first of a perhaps weekly series of things that I thought were interesting in the past week, but are just too short to warrant a full post:

  • Hanselminutes Episode #90 - "Software architects are there to make sure the project doesn't fail" and "[one should] architect for referrals."
  • "grep" comes from the Unix program ed command of g/re/p which does a global regular expression search and prints the results. I never knew this before
  • I knew about the GC.SuppressFinalize method to tell the garbage collector that an object shouldn't have its finalizers called, but while reading more about IL, I found out that there indeed is a GC.ReRegisterForFinalize just in case you made a mistake :)
  • Although it should have been insanely obvious, it wasn't until I saw in the IL that all methods of interfaces are indeed virtual. Although, in hindsight, it sorta makes sense.

UPDATE: After thinking about it for awhile, I've decided not to keep this series up on a weekly basis since that might generate too much noise.