Category: Uncategorized

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.

The RSS Blog is conducting a quick survey on RSS readers - stop by and fill out the survey.

A while ago, I downloaded a podcast series from iTunes. It's a series of lectures by Richard Muller, a Physics Professor at Berkeley. This podcast, along with a few others, are available free on iTunes.

These lectures have been a real delight. Muller has a great knack for covering topics at a level that doesn't dive too deeply beyond the comprehension of mere mortals. I usually find each lecture to have a mix of things I already knew and things I knew nothing at all about. As a measure of Muller's ability to communicate, I find I'm equally interested in both, as he always finds a novel way to convey these topics.

The name of the course, incidentally, is "Physics for Future Presidents," so a central theme of the lectures is that the student should absorb the concepts in the course, but not be expected to churn out calculations. That suits me just fine.

Understanding these ideas as they apply to our lives, on the other hand, is fascinating. Muller explains such things as the physics behind alternative fuels and global warming. As you might expect, some of the common wisdom surrounding these and other topics has a basis in physics, and Muller explains that. What you might not expect is that there are places where the common wisdom has completely failed to grasp the reality of these matters, and Muller covers those areas well, too.

Why a physics-lite class? What's the point, if students aren't intended to go on to dedicate their lives to physics? Easy. Muller understands that a broad understanding of the real forces that shape the world around us will equip anyone to call "bullshit" when somebody starts blowing smoke or selling FUD, either intentionally or out of ignorance. A little understanding equals better decisions.

So go ahead - blow off the drive-time drivel, and listen to some physics on your commute!

Physics for future Presidents
Physics 10 Physics for Future Presidents Podcast index
Muller's Home Page

I've seen this a thousand times. Some self-proclaimed technology pundit starts going on about how the world would be a better place if only "______" didn't exist (or, didn't exist anymore). I saw it again this week, and it's still not very pleasant.

I'm sure it began as the first higher-level languages began to elbow their way into the computer room next to assembly language, but it didn't start to become fashionable until computer "experts" began to predict the demise of COBOL. For the record, I think we're going on about 30 years of "COBOL's dead, haven't you heard?"

I didn't appreciate how ridiculous this really was the first time I heard it, but when I started to develop in Visual Basic, I was very aware that VB was considered an "inferior" language. Never mind the fact that I, as well as the former Mainframe developers I'd trained, were cranking out features a lot faster than the "smart" developers. While they were wading through inheritance stacks trying to find out which super-class was really responsible for setting the text of a window caption, I was building applications out of a bag of components I'd bought for a few hundred dollars. I'm not worthy!

So it was again with Java. I saw a lot of Java code and Java coders come and go. I saw some smart ones and some that weren't so smart, and I saw some fantastic applications and some that weren't worth a hill of beans. Through all of this, I'd dare say that the better the developer, the less likely he was to suggest that anybody who wasn't working with Java was a nobody loser has-been legacy programmer. The distinction wasn't lost on me.

Now, of course, it's becoming fashionable to dump on Java. Rails is far, far hipper, and .Net is rising fast. The more things change, the more they stay the same.

I'm working in C# now. I still hear the noise about those inferior languages and tools, and it still ruffles my feathers a bit. This week, I was in the middle of a design discussion in which the use of ADO.Net DataSets was proclaimed to be categorically evil.

This, of course, completely ceased to amuse me.

I can appreciate how the misuse of a technology can make a mess, but I just don't have a lot of patience for someone who suggests that a technology is without any redeeming qualities, let alone is destructive enough all by itself to ruin an application. I've seen far more applications ruined by developers who didn't understand how the technologies they were using really worked.

In case this escaped you to this point, ADO.Net DataSets are part of Microsoft's current technology stack. These classes ship with .Net and the Visual Studio development environment. They appear prominently in Microsoft's documentation and sample applications. They are not, contrary to popular opinion, the abandoned stepchildren of the modern Microsoft development stack.

I'm just not buying the line about DataSets being the spawn of Satan, and I won't buy it next time, either, when I hear a generalization made without any real understanding of the problem or the solution.

Save that for someone who doesn't know better.

I'm spending some time in a cube (ugghh, I know) next to a woman who seems really nice, except for one thing. When she's away from her desk for a while, her PC goes to sleep, and she's convinced that the way she needs to wake it up is to slide the mouse back and forth a couple of times, and then pick it up and smack it on the desk twice. Exactly twice.

Slide-slide-double-smack.

Apparently, by the time she's through executing "smack" number 2, her computer has been sufficiently jolted to be able to respond to her, because she ceases the beating at that point.

I'm sure there's a usability lesson in here somewhere, but it escapes me at the moment. My head hurts too much to think about that.

You've probably seen all the announcements about Ford's recent record-setting performance. They managed to cough up $12.7B -- that's the big "B", folks -- last year. This is tempered only by GM's $10.6B loss last year ("all the kids are doing it, Mom!").

I don't know about you, but the first few times these staggering numbers crossed my desk, I managed to brush them off. For one thing, $12.7B is large enough to go into my mental "Federal deficit" bucket -- the number's just too big for any kind of normal comprehension. After you cross the billion dollar threshold, I start to get a little glassy-eyed. Maybe we should measure Ford's loss in Gates' -- as in, "Ford lost a quarter of a Gates last year."

The other problem I have with these numbers is that it's just way too easy to chalk it up to Ford's management just having been numskulls last year. "Get your head out of your ashtray and build a car that people want," or "build a car that doesn't fall apart on its way out of the dealer's parking lot." Easy scapegoat.

But it turns out the problem isn't quite that simple. Take a look at this article from CNN Money. This is a great introduction to the hole that our big-three automakers find themselves in. The article points out that our nation's automakers are giving away a $2900 handicap per car to foreign rivals. Of this total, the biggest hits come from labor costs (especially health care), a weak dollar, and a negative brand premium.

So here's where this article started to get really interesting. The blame for the brand premium problem falls squarely on the shoulders of the bean-counters in Detroit. These people are every bit as capable as any other business executive of reading the tea leaves. Gas is going to jump every time the weather is colder than normal, or warmer than normal, or windier or rainier than normal. Gas is going to jump any time anyone hears any loud noise coming from the general direction of Mecca, or if a camel does his business on a pipeline. Any auto executive that doesn't get this should be stood up in front of Donald Trump -- end of story.

Same thing goes for styling. As in, get some.

But the rest of their problems -- who do you blame for those?

How about health care costs? What, *exactly*, is it going to take before our government collectively gets its act together and starts to make this better? Our health care problems clearly affect every aspect of our nation, including its overall economic performance.

How about labor costs? Most people have heard the quote, "What's good for General Motors is good for the rest of America", attributed to GM Chairman Charlie Wilson in his 1955 appearance before the U.S. Senate.

In those days, GM was considered invincible. The extent of their power and dominance was even greater than Microsoft's today, in part because of the big-capital, industrial nature of their product. They kept a whole lot of other businesses churning away, and this effect was very visible. You see a big factory cranking out steel a lot easier than you see the impacts of computer software.

The big automakers, then, tended not to get a lot of sympathy when the UAW came knocking. Contracts got bigger, workers gained protection, and pension funds were established. Now, of course, these decisions have become gifts that just keep on giving.

I have a feeling that there aren't too many executives at the big three who were around in the 50's. And once that ball got rolling, I can completely imagine that it was hard to slow it down.

Who do you blame?

Do you blame today's executives? Who's going to be the one to go toe to toe with the unions and weather a long, dry strike?

Do you blame the unions? Which union leader is going to go back to his guys and say, "Yeah, so it turns out we're asking for way too much from them. We're going to end up with no jobs at all if we keep this up, and we've got to reduce our costs."

I wouldn't want to bet on who's going to blink first.

What about the weak dollar? It turns out this is effectively a subsidy for foreign automakers to the tune of around a grand per car. No matter how good our automakers get, they're at a thousand-dollar disadvantage.

Who do you blame? Again, the problem here isn't GM or Ford. It's an international economic and political issue for the United States, and the solution has to come from Washington.

What if GM and Ford are the canaries in our coal mines?

I've known about AJAX since the acronym was first coined. I saw the buzz when Google first loosed "suggest" on an unsuspecting community of developers. A palpable murmur swept through online communities as thousands of developers brought up on GETS and POSTS asked, "How are they doing that?"

It turns out that the way Google was doing it was sophisticated, but not revolutionary. In fact, it was a great use of a collection of technologies that had been around for a bit; Google just managed to make them sing together.

The only bad news about AJAX was that it was ugly. No, the apps were beautiful -- it was the code that was ugly. So AJAX went on my personal radar screen of things that were going to change the way I do development... as soon as the kinks got worked out a bit.

The last 6 to 12 months have seen the tempo really start to pick up. In no particular order, we've seen:

• AJAX-enabled component suites have become common. There are really solid releases from well-known vendors like Infragistics, as well as strong newcomers like ComponentArt.
• Microsoft's Atlas is nearing release. Like many of their products, they're not breaking too much new ground, but their presence provides a much-needed center of gravity for developers and vendors alike.
• There has been an explosion of "2.0" sites using AJAX. They're literally everywhere you turn.

I've played with some of these control suites (Atlas, Infragistics, ComponentArt). They're nice. A whole lot nicer than that first Google JavaScript code. But they're still a fair bit of extra work, relative to making the same UI without the whizbang.

So I was just a bit skeptical when I saw a link pop up in some Google search I did about an open-source framework that claimed to produce AJAX-enabled web applications from Windows Forms projects.

Riiiighhhhht.

But it's true. Almost. It's almost true, and that's a whole lot higher than the current bar. The project is called Visual WebGui, and it damned near does exactly that. You develop in a WinForms application using a set of controls from Visual WebGUI (that's the first catch), and when you run it, you've got an application that looks impressively like a WinForms application, but it's running in a browser. And no, not just IE -- I created an app in less than two minutes and ran it in both IE and FireFox.

This project has some serious chops, and they're executing on more than just technology. Visit the web site, and you'll see a well-done web presence, complete with documentation and an impressive collection of video tutorials. Watch one or two and see for yourself if this is all I've made it out to be.

Is it ready for prime time? Not quite, if you want my honest opinion. In playing with this toolset for a couple days, I ran into a few too many cases where I had to blow a form away and start over because I got myself into an unrecoverable error state. This sort of problem isn't a deal breaker if it happens every once in a while, but at the frequency I saw problems, it would be a problem.

I can assure you, though, I'm keeping my eye on this project. I've seen hints that they're going to try to enable Mono support, too, which would score extra points in my book. I doubt this would ever be a mainstream deployment platform, but I think it's important to have that option.

So go take a look - I think you'll be impressed.