The Code To Live video starts with an All-Girl AC/DC cover band. I'm not really sure what else you need to know. Steve Loethen is a Developer Evangelist for Microsoft here in Kansas City (or some such related job -- I never really remember what he does). We used to work together at this odd little company years ago. I'm certain he would be voted the Microsoft employee most likely to be mistaken for a biker. He and his co-host travel the country talking to developers. With a Harley. Dressed like bikers. I'm not sure who cast Steve in that...
MSDN has one of the better articles I've read on LINQ: The Evolution Of LINQ And Its Impact On The Design Of C#. It really helped to see the design history to understand why things are the way they are. Very good article.
I posted the source code for my SQL Server 2005 object scripting tool. The code reads like something I threw together to see if I could really do this. Because that's what it is. You can read a prior post that describes a little of what it does.
The ClickOnce deployment is available here: http://www.sqlteam.com/publish/scriptio/
It's at version 0.5.1 as I type this. New features include:
Connect to SQL Server using SQL Server accounts
Option to include collation in the script
Can optionally qualify creates, drops foreign keys with the schema
Update: Most recent install and source code: http://weblogs.sqlteam.com/billg/archive/2006/06/13/10208.aspx
After working with SQL Server 2005 I've discovered that I can't script out one object per file and include both the DROP and CREATE in the same file. Which is driving me absolutely crazy! So I wrote a little utility and thought I'd share it. If you'd like to see this functionality included in a future service pack you can vote for this feature through MSDN Feedback Center.
This utility requires .NET 2.0 and the SQL Server 2005 client tools installed on the machine. The application is deployed as a ClickOnce application. It can be installed at:
http://www.sqlteam.com/publish/scriptio/ (Location Updated)
I haven't released the...
Setting up automatic bug logging on FogBugz 4.0
I've updated my NAnt tasks to 0.94 (source and binary). I've added three new tasks.
The first is a task to load an Excel spreadsheet into a SQL Server table. We've found this to be a fair way to manage code tables. They're easy to edit and print out for review. They don't handle the foreign key checking until we load them in but that's been a fair trade-off for their ease of use.
The second task imports an image file into SQL Server. It's basically a mirror image of TEXTCOPY.EXE except that it's a NAnt task and the trust connection works.
This NAnt task will restore a database backup onto the target server...
That has to be most cumbersome title I've ever used but it describes what I'm doing. We recently started using FogBUGZ for our bug and inquiry tracking for a couple of applications we've developed. We're running it on a server behind a firewall. FogBUGZ gives you a way for your application to automatically submit any untrapped errors through a special ASP page. Instead of trying to make just that ASP page available through our firewall I wanted to create web site with only that page. It turned out to be a little more complicated than I thought but it works...
Here's a great little tool that helps you write a simple multi-threaded app. It gives you an easy way to move certain tasks to a background thread. Neat idea! Now I can move much of the database stuff to a background thread on one of the apps I'm working on.
Some new features in C# and Whidbey that I'm excited about.
Link to a humourous review of the leaked MS source code
Microsoft has been playing around with a language called Xen. It's a set of extensions to C# to manipulate XML and relational data. The article is fairly interesting to work through. It's an attempt to move the most common data storage mechanisms into the language. It's still only research at this point but it's a pretty interesting read.
I recently found an article comparing software development to the construction industry. Here's the response to a software developer who said he wanted to write software like people construct buildings:
I started to explain: "In software development, we are told we should manage our projects like construction projects, where a building is designed at the start, cost and schedule are predictable, and customers get what they expect."
Silence. "You're kidding, right?" "No, honest, that's what we're told."
Incredulity turns to laughter. The idea that programmers would want to manage projects like the construction industry strikes my classmates as ludicrous.