.NET Traction at Microsoft?

According to this article from Richard Grimes, it appears that .NET has not gained as much traction inside Microsoft as anticipated:
http://www.grimes.demon.co.uk/dotnet/vistaAndDotnet.htm

“My conclusion is that Microsoft has lost its confidence in .NET. They implement very little of their own code using .NET. The framework is provided as part of the operating system, but this is so that code written by third party developers can run on Vista without the large download of the framework. Supplying the .NET runtime for third party developers in this way is similar to Microsoft supplying msvbvm60.dll as part of XP.”

I think his conclusion is a bit overreaching, but this isn’t a big deal to me either way, and I’m neither a raving Microsoft fan nor a rabid Microsoft detractor.

However, this is good news in at least one important way:

To the extent Windows itself is not built on .NET, that in a sense leaves more room for other, non-.NET runtime environments to flourish as first class citizens, leaving more room for Java (we ship a commercial Java application, so that’s good…) and also for other currently and upcoming dynamic language runtime environments.

Bar Camp, Code Camp

I met some of the Bar Camp guys:

http://barcamp.org/

at ETech last week:

http://conferences.oreillynet.com/etech/

and mentioned Code Camp to them:

http://blogs.msdn.com/trobbins/archive/2004/12/12/280181.aspx

These two non-conferences seem to have a lot in common, though one is vaguely MS-centric (it was briefly known as MSDN Code Camp) with the other isn’t. Brian Button is putting together a Code Camp here in St. Louis soon, it will be interesting to see how it works out.

http://www.agileprogrammer.com/oneagilecoder/archive/2006/01/22/11023.aspx

SQL Server Log Shipping Fragility

In a customer production system, we use MS SQL Server 2000 “log shipping” extensively to offload reporting DB load to secondary servers… a common use of the technology. This generally works very well, most of the time.
We’ve noticed, though, that it can be somewhat fragile, in that it is easy to inadventantly run a SQL operation (such as a large index update, schema change, etc.) that results in many, many pages shipped, and hence in large log backup files, and large “standby” files – all of which are processed surprisingly slowly by SQL Server. The result of this (the fragility) is that the log ship destination servers can then take many, many hours to return to an operatonal state.
It turns out that one cause of this is that log backup (and hence log shipping) apparently happens at the “page” level: if one bit on a page changes, all 8K of the page is shipped.

A second cause is that if a log backup happens during the middle of a large operation, it will ship the partially complete operation; the destination servers will then generate huge “standby” files (we’ve seen them over a gigabyte) in the restore process.
One path forward is to to move up to SQL Server 2005, which has numerous log shipping improvements. Imagine my dismay to find this today:

http://sqljunkies.com/WebLog/acalvett/archive/2006/03/12/18993.aspx

in which Andrew Calvett found that the log ship monitoring functionality is much worse in SQL Server 2005 than in SQL Server 2000.

As usual there is likely a third party tool to make this better. But since log shipping is such a powerful and flexible tool for scaling up SQL Server based applications, it is disappointing to see the monitoring get worse rather than better. Perhaps in SQL Server “2010”…

Sea change in Web vs. Desktop Development

In the late 1990s, I rushed in to web-app development with a million other developers, following the demand. At the time I accepted that it took more work to get a web app working than a desktop app, using the tools of the era.

But looking at Ruby / Rails and TurboGears:

http://www.turbogears.org/preview/docs/tutorials/eajaxtg/paper.html

It strikes me that it is now *less work and less code* to get the functionality shown here working in a web app w/AJAX, than it would be to get it working in a rich client with Swing or in a multi-tier application in Delphi. The idea above that desktop client apps are less work than web apps, is no longer true. We are now paying a penalty when we choose to create non-web-apps.

Switched to WordPress

After a few years of using a barely-maintained homegrown CMS / weblog engine, I’ve switched to WordPress 2.0. Through a few hours of tedious migration work, most of the old content has been preserved. Moreover, a set of Apache directives like this:

RedirectMatch story-275- http://kylecordes.com/2005/09/09/direct-swing/
RedirectMatch printable-275- http://kylecordes.com/2005/09/09/direct-swing/

makes all (or very nearly all) of the old URLs still work.