Author: dlambert

Here are a couple of things you should definitely check out if you work with data access in .Net 2.0. This stuff should tide you over until you're ready for Linq.

Scott Guthrie just posted a great list of ASP.Net data access tutorials. By the way, if you aren't already subscribed to Scott's blog, do so right away. He's a great source of information about the latest in Visual Studio development tools.

Also in his post is an announcement for a Beta 3 release of SubSonic 2.0. From the announcement: SubSonic is a zero code data access layer for ASP.Net. Sounds pretty cool to me.

When I was a developer learning my trade, I picked up a copy of Steve McConnell's Code Complete. It was wonderful. An entire book filled with practices to my my trade easier and more reliable.

Much of it seemed like common sense, building on a lot of what I'd learned as I gained experience in object-oriented design and development. Concepts like understanding what a routine does and making sure that a method accomplishes one and only one objective resonated with me because they reinforced the things that worked well for me in my own experience.

There were other principles that seemed so basic that they might not even need to be covered in a book about the craft of software development. A programmer should be able to understand inherently that a six-page function wasn't maintainable, right?

Sadly, there was a reason these ideas had to be included in the book back when it was initially published, and there are still individual developers who don't find these principles to be second nature.

To this day, I see coders who have a hard time understanding the principles that make code reliable, extensible, and maintainable. Requirements change, architectures change, and refactoring happens. If you're a developer, you have to see this coming, and you have to do the right things to prepare for change.

If you're a manager, and any of your developers haven't seen this book, buy it for them and encourage them as strongly as you can to read the book.

If you're a developer and you haven't read this book (or haven't read it recently), pick up a copy, and read it.

Please.

If you're a fan of frequent automated builds, these links are guaranteed to be side-splitters. If you're not, you really had better look into it before you get an email from one of these ladies:

• You broke the build!
• Builds on my machine!
• Where's the build?

Incidentally, this is pretty clever marketing. I've never even seen their product, and I'm already a fan.

About the time that the Windows Home Server beta program was announced, I decided to give it a shot. The product looks interesting, and my biggest reservations came from lack of familiarity, and there's only one way to fix that. I applied, and was accepted. Woohoo!

So I started scouting for a suitable machine. I toyed with building up an old wreck I had laying around, but quickly came to the conclusion that by the time I patched it up to working order, I'd have sunk more into it that I'd like.

I was also trolling ebay, and noticed that some really nice old servers were going for not a lot of money. The bad news is that they're big and heavy, so shipping was expensive -- but not if I found one locally. Long story short, I ended up finding a Dell PowerEdge 2400 with a single 866mhz P-III processor, integrated SCSI and RAID, and 1gig of ECC RAM. I paid $59.

I wasn't ready to install yet, as I had no storage for the box, but that was easily remedied with a Promise TX4 SATA controller, an Asus SATA DVD, and two 320mb Seagate SATA drives from Newegg. I also found a second processor for $10 shipped. I was ready to roll.

When I got all the parts together, I did an install of W2K3 Standard just to make sure that all the moving pieces were working. No problem. Then, I fired up the WHS install with great anticipation, and got a minute into the install when it crapped out on me with a vague error about the UI.

Nuts.

I hit the forums, and posted my problem. I got a few suggestions:

• Verify the checksum on the DVD image. Done.
• Update your bios. Done.
• Put the Promise drivers on a USB stick. Done.
• Update the bios of the Promise card. Done.

All that, and no joy.

So, here I sit, waiting for a fix. Maybe they'll have a Beta 3.

I saw a pretty entertaining post this week on one of the Channel 9 forums. A guy there reacted to some Windows Home Server bug counts from their beta program. Personally, I found this guy's reaction to be humorous all by itself:

I definitely like this topic:

Of the bugs that have been addressed, Sullivan said that only 15% have actually been fixed. The remainder are issues that are in the server by design (13%), not reproducible (21%), will be postponed to later versions (11%) or likely won't be fixed (7%).

Bloody hell... ALL REPRODUCIBLE BUGS MUST BE FIXED! (Or never made!). There is no such thing as "bug by design". It was invented by big corps to cover own failures, as "excuse".

An energetic, uninformed rant is always worth a little chuckle, but in this case, my interest extends beyond the first reaction. You see, this person represents a real constituency out there who know enough about a software development process to be dangerous.

To ship software, just fix every bug until none remain. Any software that ships with > 0 bugs is proof that the software company is just a money-grubbing corporate blight on the face of the industry.

Simple, right?

Ok, fess up - how many of you have really shipped commercial software? How many have shipped software out for testing, and then fielded unsolicited "help" from these testers. I've done these things on a smaller scale than Microsoft is doing here, and the numbers don't startle me a bit.

In fact, if you develop commercial software or plan to do so someday, I'd recommend you start watching the Windows Home Server Blog. I know I was critical of the opacity of the initial marketing launch for this product, but the subsequent transparency of the development process is really impressive. Pay attention, because you're getting a glimpse inside the sausage factory.

You see, when you open testing up beyond a tightly-controlled QA environment, there are only two ways to get a grip on your bugs. You either throttle them before they come in, or you sort and categorize them after they're reported. The former method is almost always impractical, not to mention making the tester feel oh, so valuable ("Thanks for the report. I'll just put it here on this stack to review before I enter it into the system. We'll be sure to let you know if it's entered as a 'real' bug").

Categorization is really your only option for a beta program like this, and when you let anybody report any bug, you're going to get a lot of chaff. Again, the distribution reported by the WHS team looks pretty reasonable, and the team is doing a great job of explaining the numbers along the way.

I guess it's hard to fault Microsoft for being opaque sometimes when openness like this is turned against them by a misinformed public. Still, I hope we see more of this face of Microsoft.

If you're a .Net developer, manager, or architect, you've got to read this guy's blog. Who is Miguel de Icaza, and why should you care?

Miguel is a the driving force behind Mono, the open-source port of Microsoft's .Net CLR. I've been watching this project since Miguel first began working on Mono 1.0, and his progress has been really impressive.

To be honest, it seemed like an uphill battle when he started, and when he hit 1.0, Microsoft was releasing 2.0, so I figured there was no way he was going to be able to keep up. But he and the other Mono developers (with some support from Novell along the way, if I'm not mistaken), have kept on driving, and the movement is growing.

They're supporting .Net 2.0 features now, and along the way, they've picked up some of the UI tools needed to support WinForms, plus support for VB.Net. Perhaps more importantly, though, are some of the ancillary projects popping up around Mono. There are open-source IDE's, and a great product called Grasshopper that lets you deploy your .Net app on a Tomcat Java application server running on Linux (Grasshopper is built by a company called Mainsoft who sells a commercial product that lets you do the same thing, but deploy it to Enterprise-class app servers on any hardware platform).

So why is Miguel's blog a must-read?

It's all about understanding your options. As a developer / manager / architect, you need to understand how the technology you use connects to the needs of your business. Mono could be an important part of that in the future.

Microsoft has paced the field in development tools for a long time, and by most accounts, they're still tops. It's pretty hard to top .Net's development experience, despite the great gains by Eclipse over the years. The weak link in an all-Microsoft development strategy is that it implies an all-Microsoft deployment strategy. This can feel burdensome from time to time, and like like cement shoes whenever there's a new OS release (upgrade or die...no pressure).

What would it be worth to your company to develop in .Net and distribute onto Linux servers? How about for a hosting company? Can Mono turn into the next LAMP?

Miguel doesn't post often, but when he does, it's worthwhile. Sign up with your favorite RSS reader, and you'll know the next time he has some news. Check out today's post, The Race to Linux 2.0, where he talks up an upcoming contest to pump up Mono's 2.0 support.

Scott Adams (of Dilbert fame) has a blog, and I've been a subscriber for a while. In today's blog, he's gotten himself pretty wound up about Google's ability to email you an alert whenever your keywords appear for the first time in its massive index. Pretty cool, I'll admit.

He's asked his readers to chime in on a technology that they think is cool. Normally, of course, I'd just drop a comment on his blog, but in this case, I think I'll just let Google send him an email. 😉

So, what do I think is cool?

I'm a software guy. The mechanics of an individual piece of software frequently impress me because I can appreciate the work it takes to get an application to jump through hoops. I was awe-stricken when I saw Google Suggest for the first time. But that feeling quickly fades. The relentless advance of software marches on, and pretty soon, you can get Ajax free in a box of breakfast cereal.

Yawn.

But here's what's cool. There's finally enough standards-based infrastructure, and enough collective development gray matter, and enough boardroom comfort with technologies like XML, web services, RSS, Ajax, and Flash that people are moving past the wow of the technologies and beginning to build some pretty useful applications.

Once, as a friend of mine used to say, it wasn't necessary for the dancing bear to dance well for it to be impressive. Any dancing bear was a good show, or so I've been told. Today, though, if your bear isn't ready for "Dancing with the Stars", you're yesterday's news. The bar has been raised.

So the cool thing for me is to be aware of the immersion that we broadly tag "Web 2.0". Here are some of the things that are so cool, we don't even stop to appreciate them anymore:

• RSS News Readers. I've loved RSS since way before it was cool to love RSS. I'm a news junkie, and RSS is a mainline into my frontal lobe. The cool part is that it's seamless now. When RSS started, it was rare to find a feed, and hooking it up was accomplished with all the grace of - well, a dancing bear. Now, every site you go to lights up a little orange button on your browser, and when you hit the button, you're done - no drama at all.
• Social networking that works. The phenomenon that was MySpace tuned everyone in to the scale that social networks could achieve. There were online bulletin boards and email lists, of course, back in the dark ages of the internet. While this technology was found exclusively in dark rooms warmed only by the glow of computer monitors, it never had a chance of becoming mainstream. Today, though, social networks are fun, but they're also real business tools. LinkedIn is at the top of my list, and MyBlogLog is gaining ground. I've made several quality acquaintances through these networks; really top-notch business leaders who I very likely would never have met before.
• Virtual Machines. Ok, you're not going to get too warm and fuzzy about this one unless you're a technophile, but I think it's pretty cool, and you will, too eventually. I've experienced the breathtaking excitement of shoving thirty-some diskettes into a computer, one-by-one, for hours on end to get OS/2 or Windows-Stonehenge-Edition set up, only to find that you bungled the video setup, and you were going to have to start over because you foolishly chose a refresh rate used only in an obscure part of Lower Elbonia, and you were now sadly unable to read the screen where this error was blinking helpfully. I've also endured ten years of developers telling me, "it works on my machine!" -- as if this somehow mitigates the fact that the QA system has turned into a boat anchor. There's something to be said for setting up software by copying a Virtual Machine file to a server and powering it up, and for restoring a bricked system by copying yesterday's image back over the smoking remains of today's.

So those things are pretty cool. We can tell that a technology's really made it, though, when we start seeing new tech built on yesterday's cool tech:

• Podcasts. I hesitate to call this new tech, but it's a perfect example of cool tech that's built on platform tech -- in this case, RSS. To the untrained eye, RSS is nowhere to be found in your typical Podcast, but that's just the way it should be. This is a harbinger of things to come -- we're now starting to see video-cast feeds, completing the multimedia sweep.
• Web Services. You can now snipe an eBay auction or tag your MP3 collection with album art from Amazon using web services, and never be aware of how it's happening. That's seamless, and that's cool.
• Yahoo Pipes. This one is out there a little bit, but it shows how multiple Web 2.0 technologies can do when they come together. Sadly, Pipes is so cutting-edge that it's down from time to time. Like now.
• Mashups. Not a day goes by without a half dozen new Google Maps mashups. Or a Technorati / Flickr combo. Or any other crazy combination that someone can think of. The apps are sometimes pretty goofy, but the fabric that enables this Frankenstein-inspired architecture is big-time serious, and it's ready to make a difference in your business.
• One-touch link blogging. When I'm reading your RSS feed in Google Reader, I press one button if I like your article, and it's instantly re-published on my Google Shared Feeds link. Delicious and CoComment sit on my toolbar and store my links and track the comments I leave on other peoples' sites.

And we almost take all of this stuff for granted. It's infrastructure; it's on all the time at the flick of a switch. And *that* is wicked-cool.

So, by the time you're through reading this article, Scott Adams says his Blackberry will be buzzing. What's up, Scott?

I'll admit this may not be a subject on the tip of America's tongue, but there are some things that are bugging me about the state of the software development profession, and I thought that perhaps a good place to start would be with something that's working extraordinarily well.

Type safety, by the way, has nothing to do with an airbag on your keyboard, so this article will be a bit technical, but I'll try to keep my explanations simple enough for a wide audience. You may also recall a recent article about Generics -- these concepts are very closely related, as you'll seen shortly.

The concept of type safety in a programming language simply means that the compiler and runtime environment know the type of each variable, and can use that information to protect you from a lot of errors you might otherwise see. A variable's type can be a primitive type, like a string, or an integer, or a Date. It can also be a complex type or an object. A Customer object, also has a type, and it's different from an Invoice object.

What good are types?

Types help us in two main ways. First, the compiler can produce much safer code. When the compiler can check the types of our variables, we aren't allowed to shove square pegs into round holes, and we are safe from many type conversion bugs that plague non-typed languages.

The second contribution we get is coding support from our development environment. In Visual Studio, for instance, its intellisense features help with things like auto-complete and refactoring. None of these features is due strictly to how .Net handles types, but many of them are made possible when we know about our variables' types.

There are some downsides, too. There are times when you know full well that you're copying one variable to another, and they're supposed to be of the same type, but the compiler gives you an error. These problems are easier to take once you get the hang of explicit type declarations and even easier to take when you see the types of errors these checks prevent.

You may have made the connection to Generics by now. Generics simply let us extend all of this type-safe goodness to classes where a type will take multiple forms depending on where it's used.

The overall affect on the developer is to make it much easier to crank out lots of code in a hurry, with a reasonable expectation that it'll run right when it's compiled. The development environment actually predicts what I'm going to type in some cases because it knows enough about my objects to be able to understand the most typical coding patterns as I start them.

It's also possible for all that help to lead to developer dysfunction, but that's a topic for another day.

When Apple started running its latest version of the "Mac guy vs. PC guy" campaign, I was a little indignant. This most recent installment features the large, dark-suited fellow representing the firewall. "You're coming to a sad realization.. accept or deny" -- you've probably seen this by now.

"It's not that bad," I felt. You click a few things to set up some policies, and then it doesn't bother you any more. Well, here's an interesting post on Channel 9 that shows that maybe Apple's got it right in this ad after all. This looks just like the Apple ad -- a whole bunch of dialogs to click through just to be able to install a Vista gadget.

But wait. Is it really as bad as it looks?

Let's start with the last dialog. This one indicates that the code in this example wasn't signed correctly. Developers see this all the time, because we're building unsigned code ourselves, and because we use a lot of beta or experimental programs that might not be signed. For a "normal" user, though, this is a legitimate red flag. They absolutely, positively, should question what's going on if they see this dialog.

The second window (the one about operating outside of protected mode) makes it look like this gadget is requesting resources or access above and beyond what would be normal for this type of program. I haven't seen this particular warning, but I've set up .Net security policies that are used to drive exactly this sort of behavior. The whole idea is that the application developer indicates the minimum set of resources and permissions needed to run the program.

Gadgets are designed to work in a protected "sandbox" very much like the environment Java applets run in. There's a mechanism that developers can employ to ask for additional resources, and it'll result in a dialog like this. Again, this indicates that there's really a heightened need to access stuff on your PC (meaning that you should trust the publisher before accepting) or that the developer goofed (meaning that you should punt this back to the developer until they fix it).

So when you look at what's happening in these dialogs, it makes sense.

The thing that doesn't make as much sense, and therefore, the thing that lets Apple go on making fun of PCs, is that the communication with the user is waaayy too technical and jargon-filled. Programmers are going to want to know about the information on these screens; very few users will.

I was looking forward to .Net Generics since I learned they'd be included in .Net 2.0. Having to build an entirely new class to implement a strongly-typed collection was a drag, when Collection(of..) or Collection<> would have solved the problem in a fraction of the time.

So I've been using them for typed collections, and they're great. The part I didn't anticipate was what a lifesaver they'd be in a thousand other instances.

So far, besides using them for Collections, Lists, Dictionaries, and so on, I've used Generics in places like these:

• Building a base class to handle properties that can track Dirty. Since the property types vary, this would have meant creating them as Object before. This is much, much better syntactically, and especially with respect to type safety.
• Abstracting me from Oracle hell. For reasons known only to the Royal Order of Oracle DBAs, local chapter #666, some of our lookup tables use Integer keys, while others use two-characters "codes". They're all the same to me, thanks to Generics. I set the ID up as a Generic type, and I'm off and running (it's slightly more complicated than this, but not by much).
• I used Generics to wrap some common functionality around a bunch of DataSets, where the DataSets had to remain strongly-typed in order for things to work right (so I couldn't just write against DataSet).

Bottom line: once you get used to thinking in Generics, you'll find all sorts of problems that cry out for them.

One of the things you'll have to get used to is the slightly weird meta-syntax you have to deal with from within the Genericized class. You can't just use == or != for instance, becuase those operators might not be defined for all generic types.

So crack open the help files and recall how .Compare works, and while you're in there, check out the Where syntax for use when declaring your Generic class -- it lets you specify specific interfaces that you require your implemented object to support.

For example, if you want to create a class that works with any IEnumerable object, you can specify that using Where on your class declaration, and then you can use this class Generically only with objects supporting IEnumerable. This isn't too difficult to get a handle on, and it's a small price to pay for real type-safety.

If you have any questions, or you'd like to see some examples, leave a comment -- I'd love to hear from you.