Seattle Startup Weekend

The next Startup Weekend has been announced and it's in Seattle. I've been somewhat involved in helping to get things going and am really excited to see how it turns out. The event will be Jan 25-27th. More details to follow.

You can register for the event or read up on what startup weekend is at the Seattle Weekend Announcement. It will likely fill up quickly.

You know the fun Restart Now/Restart Later Windows pop-up that shows up when you have updates that you need to install? The one where if you click later it will just pop up again in a few minutes? I'm term serv'ed into a server that I don't have administrator rights on and it popped up. Only since I don't have shutdown/restart rights the restart button is grayed out. Since I have no choice in the matter why does the freakin thing even show up?

So I just drag the little window off to the edge of the screen where it will sit quietly and not bother anyone anymore.

Creating Something Beautiful

I was catching up Joel Spolsky's blog earlier and he had a series of posts containing the transcription of a talk he gave at Yale (part 1, part 2, and part 3). The posts are long but I thought they were worth reading. In particular there were two things he touched on that I thought were interesting.

Testing
In part 1 he talks about testing and the fact that there's no realistic way you could have automated tests cover everything. He argues that at the very core the only thing you can do is check to ensure that one program behaves like another or according to a set of tests. Those tests however can't possibly cover everything that needs testing.

He gives an example of the move at Microsoft to more of an automated test process and the rumored laying off of testers who don't know how to code to bring in SDETs who can program those automated tests. He points out that those tests can't test a number of things that require someone actually look at the product such as whether thing were laid out in an orderly and logical fashion and whether the product has a feeling of continuity.

You can test a lot of things through automated testing but there's always going to be a need for someone with a sharp eye to go through and make sure everything is ship shape.

In-House Programming
In part 2 he writes about why an in-house programmer sucks. He gave three reasons and they are all very good but the one that really struck me was the second:

"So, the number two reason product work is better than in-house work is that you get to make beautiful things."

Numbers 1 and 3 are that you never get to do things the right way and that at a software company your business is software so there's more incentive for the company to treat developers like rock stars (and who doesn't want to be treated like a rock star now and again).

Number 2 stood out to me because it struck a chord somewhere and reminded me why I started getting interested in programming. I wanted to create something cool and useful and beautiful.

I played guitar for a long time and I didn't do it to pick up chicks (though I may have used it in that way a time or two), I did it because I wanted to create something. I wanted to write something that would touch someone or cause someone to open up their eyes to a new perspective or challenge an existing perspective. I wanted to create something beautiful. I used to sit and play for hours, now I only play around on the guitar here and there when my son (who is 18 months old on Saturday) points to it and either wants to watch me play and dance a bit here and there or wants to sit in the case after I've pulled the guitar out.

Currently I'm working on various small (on a scale of all development undertakings) projects. Some of them are pretty cool (like the one I'm working on now that I'll post about once it launches) and some of them aren't as cool (like forms). Though I can still work towards creating flexible and elegant solutions. In the grand scheme of things they may not be groundbreaking or hugely significant but they're still opportunities for elegance.

Someday I'd like to create something beautiful and significant. And I will.

I'm still so SO super busy. That said there's some sql stuff I wanted to post.

Copying One Table To Another
Want to copy all the data including the structure (with the exceptions of the constraints) to a new database?

Insert Into NewDatabaseName
Select * From OldDatabaseName

Want to just copy the structure without the rows?

Insert Into NewDatabaseName
Select * From OldDatabaseName
Where 1 = 2

What could be easier.

Unions
Unions are pretty cool. That said if you're using text, ntext, or image types you need to use a Union All. If you don't you'll get an ugly error like this:

Server: Msg 8163, Level 16, State 4, Line 1
The text, ntext, or image data type cannot be selected as DISTINCT.

Stored Procedure Output Parameters
If you're running a stored procedure that returns a data set you'll need to call SqlCommand.ExecuteReader(). If you also have an output parameter specified in the procedure you might be tempted to do something like this:

sqlDataReader = command.ExecuteReader();

string outputParam = command.Parameters["foo"].Value;

while (reader.Read()) {
//read your rows
}

reader.Close();
command.Connection.Close();

The above code will compile fine but you'll get strange exceptions on the line where you're reading out the param value. If you investigate you'll find that even though command.Parameters["foo"] isn't null command.Parameters["foo"].Value is. That's because when you're using a sql reader you need to close the reader before you can read the output param(s):

sqlDataReader = command.ExecuteReader();

while (reader.Read()) {
//read your rows
}

reader.Close();
string outputParam = command.Parameters["foo"].Value;
command.Connection.Close();

Now you know. And knowing is half the battle.