Author: dlambert

Here's another gem from Scott Guthrie.  I saw the announcement for this technology yesterday, and I completely missed how big it was.  I saw Scott's post this morning, and watched the video on a whim, and I was absolutely stunned.  This is huge.

The video that accompanies the blog post is done by David Ebbo, and it is absolutely amazing.  The "zero-to-website" time on this demo is flat-nothing, and there's tons and tons of sophisticated behavior shown in this demo that you'll have to see to believe.

Honestly, you'll appreciate the functionality shown here most of all if you've ever had to implement any of this stuff the hard way.  Handling customized grid cell rendering, editing, and validation, dynamic generation of columns, in-cell dropdown boxes, and so on -- it's true that these things are getting easier all the time, but it's generally still messy by the time you're done.  This demo knocks this stuff out without breaking a sweat.

You may also be aware of any number of code generation tools that will also whip out a working web application based on a database schema, but I think you'll agree that the approach and the execution here is really different.  Some of the scaffolding concepts here will be familiar to Ruby-on-Rails developers -- it's not a code-generation experience as much as a framework experience.  Once this site is made aware of your data, stuff starts happening automatically.  Probably the closest equivalent to this technology in the .Net world would be Subsonic, which does some of this scaffolding at the DAL and Business-Logic levels, but doesn't quite measure up to the Dynamic Data WebSite in terms of UI flexibility.

I haven't had a chance to play with this yet, but if there's one area I think  could be a weakness, it's going to be the rather direct link to the database.  This is the sort of thing that's going to show up as you start trying to work this into enterprises that are particular about how their applications' tiers are implemented, and when you start hitting really complex scenarios involving composite objects.

As an example, Rocky Lhotka's CSLA Framework is much more enterprise-friendly.  Its ability to deploy flexibly into single-tier environments and multi-tier environments, and to change the interconnect protocol with config-file changes lets you deal with demanding deployment scenarios.  Its use of "real" business objects also provides a helpful abstraction layer when you need to stitch several database concepts together to make a business object.

Since the Dynamic Data WebSite depends so completely on Linq, it's pretty static in its deployment model.  For the time being, this is going to rule out deployments where a separate business objects tier is mandated for performance or scalability reasons.

Part of the value of a technology like this, though, is to demonstrate concepts that might be of value elsewhere.  The scaffolding abilities, use of partial classes and partial methods, and aggressive use of custom attributes are pretty cool ideas that might jump-start some other tools, too.

Additional reading on Linq's static deployment model:

http://oakleafblog.blogspot.com/2007/10/avoid-linq-to-sql-data-objects-vs.html

http://oakleafblog.blogspot.com/2007/10/linq-to-sql-has-no-multi-tier-story.html

I don't normally jump on these sorts of bandwagons, but I saw this group writing topic on Web Worker Daily last week, and the timing couldn't have been better.  We'd just received our first snowfall of they year, you see, and the answer couldn't have been more obvious.

I believe 2008 will be the Year of the Web Worker because people can't drive anymore.  They can't drive when it's sunny, and they sure as hell can't drive when the roads are the slightest bit iffy.

We got about four inches of snow last Tuesday night, into Wednesday morning.  It took me almost two hours to get into work in the morning.  With clear roads, I could make the drive in about 20 minutes; most mornings, I'm there in a half hour, door-to-door. 

When I drove out of my driveway, I drove through about four inches of snow, but as soon as I got about two blocks from home, between the traffic and the snow plows, the roads had no more than 1/8 inch of slush on them.  Nowhere was there any real snow on the roads to speak of.

Yet, the roads were completely blocked.  It took me an hour just to get to the highway.  And the whole time, all the cars are sitting there burning gas and time.

The cost of this idiocy to our economy has to be staggering.

We seem not to want to educate drivers on how to handle this white stuff, and to be fair, I don't know that more education would do the trick while you've still got idiots talking on their cell phones and who knows what else while they're supposed to be driving.  No, I think the only reasonable way to go here is to do more telecommuting.

Does that constitute "the Year of the Web Worker?"  I don't know, but it's got to help.

You know I love RSS, so I was all over these news items.  The first one showed up in my reader this morning promising to analyze a feed and rank the best posts, so I just had to give this a try.  AideRSS will load your feed (or someone else's, if you prefer) and compute a "PostRank" for each post.  The PostRank appears to be driven mainly by "conversations" in the blogosphere (technorati, del.icio.us, and so on).  I ran into some problems where aideRSS coughed up a lung trying to analyze some feeds, but I'll assume that they're still working the bugs out.  As this service solidifies, I can see it being a real asset to the web manager.

The second announcement I saw was from Microsoft.  They'd previously been working on a research project called Simple Sharing Extensions (SSE), and it's gone live now as FeedSync.  The idea here (Ray Ozzie was originally behind this) is to use RSS as a transport for a multi-point peer-to-peer synching mechanism for whatever you'd want to synchronize.  Obviously, RSS doesn't need any help as a standard, but in order for FeedSync to take off, it's going to have to punch through the adoption curve catch-22.  Still, this could be a godsend for things like calendar syncing.  If you're an architect, I'd keep an eye on this.

http://www.elfyourself.com/?id=1170794836

That's a pretty broad accusation, so in sake of keeping this rant short, I'll limit my criticism to the Dependency Injection problems in these implementations, and reserve my right to complain about the rest of these factories later.

I saw an article on the MS Practices and Patterns site that mentioned a Web Client Software Factory.  Given my earlier experience with the Web Services Software Factory, I didn't necessarily expect this to be the greatest thing since sliced bread, but in my experience, there's almost always something to be learned from seeing someone put a framework like this together, and I wanted to take a look.

I looked in the downloads section of the PNP site, and found a page for a Web Client Software Factory Sample.  Cool.  I downloaded it and tried to install it.  Oops, I hadn't actually installed the factory first, so I had to go get that and install it.  And then I installed that, a nd got slapped down because I didn't have Guidance Automation Extensions (GAX) installed.  Small point of clarification: I actually did have GAX installed, but it looks like it was the wrong version.  Thanks for the distinction on the error message.

After downloading the newest GAX, its install errored because I had an older-version GAX installed.  Grrrr!  So you can see where this is going, right?  I tried to uninstall GAX, and the uninstall failed.  It told me that the uninstall had failed because there were a bunch of software factories installed that depended on GAX.  In order to upgrade GAX, I was going to have to uninstall ALL OF THE SOFTWARE FACTORIES I'D ALREADY INSTALLED, then install GAX, and then, presumably, go find updated versions of all the software factories, because the old ones wouldn't have worked with the new GAX.

ARE YOU KIDDING ME???

So this is where I bailed.  Absolutely unacceptable.  Isn't this ***precisely*** the sort of DLL hell that the .Net framework was supposed to relieve?  I haven't checked to see if any of my "old" software factories still work - I'm sure I'm in for another treat when I try that.

This is grounds to strike the word "Enterprise" from anything within ten yards of this junk.  Immediately and without prejudice.

This week, a post on the Joel on Software forum asked if Copy-Paste can be considered code reuse.  This one caught my eye, since I went through an exercise just last week to automate exactly this sort of thing.

I hate copy-paste programming.  Generally, if you're doing this, it means you should refactor that code to encapsulate it and just call the routine where needed.  Last week, though, for a variety of really bad reasons, I had to insert a bunch of repetitive code, and I'd already extracted and encapsulated everything I could.

"This calls for Snippets,' I said.

Have you seen Snippets?  They're the tribbles of Visual Studio development.  Microsoft introduced this cute little toolbox where you can keep all your little chunks of magic, and then recall them and drop them into your current context at a moment's notice.  If they're so cute and tiny and wonderful, then, what could be bad about trib -- er, Snippets?

All light-hearted ribbing aside, I think it's worth pointing out one last time that most of the time you think you need to copy and paste a bunch of times, you probably really need something different.  Find a base class to overload, or even use a custom attribute.  But every once in a while, you really do need to be able to paste in some code and change it up a little -- over, and over, and over.  In these cases, Snippets are a pretty nice way to do it.

It's been a "best of times, worst of times" year for Apple.  There's no denying the swell they're seeing from the iPhone, new iPods, and a new release of OSX.  Apple stock looks pretty golden in a fragile market.

And yet, if you're paying attention, there are some cracks in the facade.  One by one, people are starting to notice the little problems that other companies get crucified for.

Early examples were problems with iPhone activation, phone bills, and firmware updates.  Recent examples:

• Fear and Loathing Is Not A Great Brand Image

• Update: More Leopard Problems Plague Apple

• A true story about my Mac

• And finally, me.  A few weeks ago, I lost a hard drive.  I have a backup of all of my important stuff, but I didn't have a backup of this drive, because it contains stuff I can generally replicate from other sources.  This drive had my iTunes music on it, which I could generally reproduce by re-ripping all of my CDs, or (I thought) just plugging my damned iPod back in to my computer.  I was wrong on that last count.  I plugged my iPod back in after I rebuilt my PC, and iTunes said, "I need to purge this foreign content -- everything must go!"  I literally couldn't sync my iPod again until I wiped it and reloaded my music.  On top of everything else, I also lost all my song rankings, so I've got to "re-train" my iPod to know the music I like most.

So what?  Lots of companies have problems like this.  They work through them, and the move on.  Why would Apple be any different?

Apple's different because they convinced us that they're better.

In late September, Robert Scoble posted when some people's iPhones were bricked during an update.  I blogged a response back then, and I left a comment explaining why people were more upset about these problems with an Apple product than they'd be with someone else's product:

But Apple?s supposed to be better than Microsoft. That?s their hook.

[...]

Let?s face it - an important part of the Apple mystique is the experience. Stuff just *works* when it?s from Apple, right? When people start to question that image, it?s a blow to the brand.

I suspect this isn't something that Scoble didn't already know, but I'll take credit for planting a seed, because he came back and hit this topic again this week (The brand promise of Apple).  Here, Robert starts to look at a new facet of this dynamic: Apple users love Apple so much that they'd sooner believe they're idiots than to think that Apple's done something wrong.

Wow.

If there ever was any question about the marketing prowess of Jobs, this should put that to rest.  This is really good stuff.  Since the very first marketing consultant crawled out of the primeval soup and began surveying dentists, this is the holy grail they've sought.  It's lightning in a bottle, and it's the engine that drives Apple.

A handful of brands have achieved a measure of this success over the years.  Saturn was there when they first hit the scene, and to a lesser degree, the new Beetle.  When you hear about kids beating other kids to steal a pair of shoes, this elixir is at work.

When it happens, it makes people a little nuts.

And so it is with Apple.  People see only good, and look past the rotten, let alone evil.  When iTunes refuses to recover my music, or even my song ratings -- content that I generated on their hardware -- I'm not supposed to feel angry or alienated or betrayed.  I'm supposed to subserviently ask for forgiveness on behalf of my ill-behaved PC.  I had it coming for running Windows, anyway, right?

As soon as people start to question the infallibility of Jobs, Inc., the whole brand begins to look vulnerable.  This is a fragile ecosystem, and it's dangerously close to meltdown.

How do you feel about Saturns today?

Don't think that I'm writing this because I hate Apple.  On the contrary, I think the magic they've shown us over the last five years or so is the stuff legends are made of.  Very, very few of us will ever have a chance to achieve anything like the run Apple's had recently, so I believe we've all got a lot to learn from them.  Among the things we can learn, though, is how tough it is to do what they've done, and how quickly it can be lost if you're not careful.

For another great analysis on this balance, check out this article: Apple: What Could Go Wrong

Architecture has always been a tough sell.  Except in rare cases, it's not a feature that makes the front page of the color glossy sales brocures.  Even though a failed architecture is deadly, it always seems like a struggle to allocate time and budget to invest there instead of adding more features.

Steve McConnell manages to capture the "pay me now or pay me later" dynamics of architecture far better than I ever was able to in this article about Technical Debt.  By recasting a technical subject in terms taken from the Wall Street Journal, he captures the business risk involved here in a way that a CFO can grasp.

If you're an architect, you've got to read this article.

Over the last couple weeks, I've seen some announcements in the blogosphere that tell me that some winds of change are a-blowin', and we're going to see some really positive developments in ASP.Net tools and techniques in the coming months and years.  These improvements aren't about adding capabilities, they're about making the capabilities we've already got accessible to more developers.

The C# / ASP.Net platform circa Fall, 2007 is  astoundingly capable.  If there's something you can't do with this platform, you just haven't tried hard enough.  But this power too often comes at the price of coding complexity, or just as bad, coding overhead.  If I've got to write seven layers of infrastructure to get something done, I'm not too excited about doing it anymore.

The promise of a platform like .Net is that it should support both low-level code jockeys and higher-level applications developers who are working with the business on a daily basis, because the end-game is business productivity.

Enough preamble.  First development: Scott Guthrie's ASP.Net MVC Framework.  If you've read this blog for any length of time, you'll know that Scott's blog is a must-read.  His announcement of an MVC framework for ASP.Net is major news, though it was easy to miss.  So what's the big deal?  Lots of people have done some form of MVC in ASP.net -- why's this one any different?

The simplest answer is that this one, with any luck, will be the one MVC Framework to Rule Them All.  In short, there's a lot of value in having this become a standard for ASP.Net development just so that people don't have to worry about trying to do this themselves anymore.  Unless someone has needs so completely out-of-the ordinary that this framework is off the table, it's in as a default.  Fewer decisions = more productivity.

As a second-order benefit, I hope to see UI development move away from the "one big ASPX file per web page" model, toward a more component-oriented view.  Think about the way a screen is constructed in a CMS or something like Facebook or Myspace.  This is a whole lot more modular and flexible, but it'll require a shift away from the way most pages are put together.  Go read this and see if it sparks some ideas.

The second big news flash is related.  There's a guy named Rob Conery who's been working on an open-source data-access toolkit called SubSonic.   I almost referred to SubSonic as an ORM, but I think that wouldn't quite capture the spirit of SubSonic.  In any event, the news here is that Rob is going to work for Microsoft.  He'll be working in Scott's group, in fact.

Again, so what?  Again, it's about throwing enough weight and credibility behind SubSonic that it becomes an acceptable, if not brain-dead architecture choice.

Let me explain.  There are lots of other tools and frameworks out there that compete with SubSonic on some level.  I don't care if one of them is seven percent faster or requires eleven percent fewer lines of code.   What I care about is that SubSonic (and many of the other tools in this space) are better than working with ADO.Net alone.  But while this product space is fractured and chaotic, none of these tools will be a clear leader.

For me as an architect, that means that every time I'd like to use one of these tools, I've got to explain to someone that (1) it's a really good idea, (2) it's better than any of the other seventeen alternatives - including scratchbuilding, and (3) it's going to stand the test of time.  Let one of these tools win, and that argument goes away, and I can get on with building systems for business users.

And that makes me happy.

So all of this stuff is a done-deal, right?  No, of course not.  We'll have to watch these developments play out a bit.  Scott's blog targets the first-half of next year for the MVC Framework.  Rob is at Microsoft now, but we won't see any industry consolidation around SubSonic for a while yet.  But Microsoft's endorsement, even if only implicit, gives SubSonic some momentum.  I can't wait to see these bits working together.

Further reading:

How MVC, jQuery, and SubSonic Will Make You Smile

SubSonic: MVC Preview Video

Code Magazine ASP.NET MVC article

Microsoft's interesting "embrace" of Windows Open Source

When Microsoft introduced the .Net platform, they clearly wanted to reach out to the developer community and build some connections.  The "Start" page in Visual Studio and the "Community" menu sort of show what they were aiming for.  About the same time, the "gotdotnet.com" site showed up.

GotDotNet was a community site built for MS developers by MS developers.  To be honest, I don't know what involvement, if any, Microsoft had with this site, but it was clearly a good thing for Microsoft, since it gathered like-minded developers together and gave them a place to share tips and techniques.  There's no doubt that it added value for Microsoft by promoting its tools and covering some support burden via peer-to-peer support.

Time marches on, though, and a year or so ago, the folks running GotDotNet decided to ramp it down.  Other sites were to take its place, like Codeplex to host community-build code bases, and so on.

One big problem remains, however: GotDotNet continues to dominate search results for the stuff it used to have, and there's no forwarding address if you want to find this "old" material.

Case in point: Code Snippets for C#.

I'm dropping some timing code into a project, and it's repetitive work.  It occurred to me that this was exactly the sort of thing I'd expect a "snippet" to handle:

DateTime timr = MyLog.BeginTimingMessage("Unnamed timer", 0);

<< code to time >>

MyLog.EndTimingMessage("Unnamed timer", 0, timr);

So I Google "c# snippet", and the top results point at a blog hosted on MSDN.com (so I assume he's an MS employee, MVP, or equivalent).  The post is dated 2005, and it talks about a snippet editor called "Snippy".  It's apparent at this point that snippets are slightly more complicated than just chunks of text - hence, the need for an editor.   That's fine, I thought - I'll just go grab the editor and be on my way.

So I follow the link in the blog to GotDotNet, and see this "so long, and thanks for all the fish" message:

Great.  I did my best to find a breadcrumb trail leading out of this abyss, but to no avail.

In this case, it turns out it wasn't the end of the world.  I never did find "snippy", or any other snippet editor, for that matter, but I found the MSDN documentation that let me create the XML from scratch.

But the thing that really bugged me was that Microsoft would let this play out the way it did.  How much effort would it really have taken them to step in here and find new homes for the files on this site and to provide forwarding links to guide people to the new homes?  Don't they have interns??

Here's a site that's got a bunch of top Google spots for searches about Microsoft development topics.  All sorts of Microsoft developers are going to hit these links, and they're going to be spending real time navigating around on a wild goose chase for community content, all the while muttering about how they wouldn't have this problem if they were looking for something on Sourceforge.

It's a blown opportunity for Microsoft to take care of the developers who are driving the demand for their products.

Easy come, easy go.