One of the most important software development tools out of Redmond, remarkably, is Visual SourceSafe - In shops across the land, it is the source control system.
Granted those shops probably didn't kick the tires of the competitors, rigorously choosing amongst the competing SCM tools before investing their time and codebase to VSS. Instead they likely found it bundled in their MSDN subscription, or attached to some other Microsoft product, and read soothing words about the excellent integration with Visual Studio. They brought that poor, weepy-eyed little source control tool in from the rain, gave it some cocoa, and sat it down by the fireplace. Soon enough it became their hammer, and an integral part of their development process (probably a hated part of their development process. If you've ever fought with an offline complex Visual Studio project, you'll know what I mean by that).
The remarkable part of all of this is the absolutely terrible treatment that Microsoft has given this product. It recently got the first real update that it has gotten since Visual Studio 6, remaining largely static over the intervening period (with trivial little changes). While you could say that you shouldn't mess with something that works, Visual SourceSafe has carried some absolutely terrible flaws through the years, most obvious being the file database method of operation that led to endless security and reliability problems. SourceSafe 2005 didn't do anything to fix that fundamental problem.
Even with the new release, Visual SourceSafe users are still used and abused, though. I decided to put the product through its paces, both for consulting purposes, and for yafla software development, and I am absolutely amazed by the problems and pitfalls. From missing options (like turning off HTTPS from the client when trying to use the internet option), to terrible typos and transpositions in their instructions (did they read these things? Things like telling you to run aspnet_iisreg rather than the correct aspnet_regiis), to installs that just completely fail to work under anything but a cleanroom install (for instance it insists that you don't really have IIS if your first website isn't internally coded "1"). On three separate machines the internet hosting option (one of the major new options, finally adding marginal client-server functionality, albeit with a host of caveats and limitations) didn't install properly. I finally had to setup a new, freshly installed virtual machine to give it what was likely the only environment they tested it in, and it appears to install marginally properly.
If, through some magic, I get this product working properly, I'll post a quick summary (I had hoped to get some metrics of the savings that both the internet web service option, and the SSService option, brought to the table), but as it is I'm simply amazed at how botched this whole process has been. They've been working on this product for how long now?
One of the oft-mentioned improvements in Visual SourceSafe 2005 is what is affectionately called the "LAN booster" service. Configurable in the SourceSafe Administration tool under Server/Configure in the LAN tab, it can be enabled by checking the misleadingly titled checkbox "Enable LAN service for this computer".
After you've checked and applied, you'll notice a new process running - SSService.exe (appearing as a new service - Visual SourceSafe LAN Service - running under the LocalService account in your service manager).
There are a lot of claims that this module is doing wonders for performance - for instance that it is stream-compressing all of the content on the wire, improving the speed "3-5x!". However, after some analysis I've determined that it's doing nothing of the sort.
In other words the "LAN Booster" doesn't make SourceSafe an actual client-server source control system (the Internet web service sort-of does for a limited set of purposes, and again only with the plug-in in Visual Studio 2005), and its performance improvement is marginal at best in real world use.
One of the overlooked, but incredibly usable, benefits of SQL Server 2005's Management Studio over Query Analyzer are projects and solutions.
Not only is it great to be able to gather common scripts together into "projects" (e.g. "Server Maintenance"), and projects into solutions (e.g. "Insurance Administration Database"), but even better is the tight integration of source control into Management Studio - now you can actually have properly source controlled script repositories, even including common connections, with automatic change management. This will be an administrative and workflow panacea for a lot of teams, and will greatly improve script re-use.
Very nice.
I've come across comments about SQL Server "leaking memory" countless times during discussion group spelunking, seeing one yet again this morning. Generally it goes something like "after 5 days, SQL Server is consuming almost all of the server's memory, so we have scheduled a weekly reboot to deal with it. Man, I wish Microsoft knew how to write software!" (you could replace "SQL Server" with "Exchange").
While it is entirely possible that SQL Server does leak memory in some edge scenarios, what most people are seeing is actually nothing of the sort, and they are actually reducing their systems performance continually recycling it. This is because SQL Server is a memory caching system, and as it reads pages in it will attempt to memory cache data to satisfy future reads, using more and more of the available memory as a data cache, unless explicitly given a limit. It's for this reason that a 4GB server is generally faster than a 512MB server for large databases- more of it fits in memory, reducing the I/O requirements for reads (obvious writes are immediately persisted). SQL Server only grabs the memory on a need basis: When someone does a table scan of some occasionally touched table, it might request a memory cache for it, making SQL Server's memory footprint larger. If you monitor it over time it'll look like it's endlessly edging up, when in reality it'll release memory if something else starts asking for it, or as it approaches memory exhaustion.
In most situations this is ideal - or did you buy all of those memory sticks to sit unused? The only time that it really is a problem is on shared servers where SQL Server has to play nicely with another "use all of the memory" applications (like Exchange, or in some cases even the garbage collection model of .NET). In this case you might want to restrict both servers to a maximum amount of memory, or let them thrash it out.
The Canadian Launch Tour 2005 presentations and other material can be found online now at http://www.microsoft.com/canada/launch2005/event_presentations/default.aspx#ps. Well worth a look. I posted about this event on November 8th.
I had an interesting conversation today in relation to caffeine, and techniques to eliminate it from one's diet. I offered up my opinion, which was that the elimination of caffeine should be done gradually - this is true for most lifestyle changes - to minimize the negatives (e.g. headaches) and to maximize the probability that it will be sustainable. For instance in my case I cut caffeine by alternating "real" with swiss-water decaf in increasing ratios, even mixing up the blends, and by mandating a full cup of water between cups of coffee. It worked wonderfully, and in a short while I was off the dastardly white stuff.
What was more interesting than the coffee conversation, though, was the replies that came regarding my brief background story where I explained why I cut caffeine: I had mentioned that I was preparing for a trip to Italy for two weeks, and hearing about the extremely strong coffee there, and the general lack of availability compared to here, I wanted to avoid both stomach upset and spending half the trip searching for outlets of Anthony Hortinos. So I decided to eliminate coffee before leaving. It worked perfectly. Naturally this outraged some people: "But isn't coffee in Italy the best coffee in the world?"
Ignoring the entirely practical reasons why I didn't want to do coffee in Italy (and anyone who claims that convenience coffee is as widely available in Italy has never been here in Southern Ontario), the absolutism about such a subjective point is what strikes me as ridiculous: While sometimes a region has constituent accessibility that gives them an advantage or specialty (e.g. seafood is generally better on the East Coast where it's fresh from the ocean...unless it was on a long run trawler that is), often it is subjective regional preferences that people confuse with superiority or inferiority.
For instance a common mantra here in Canada is that our beer is "better" than in the US, because there the general American consumer prefers a lighter blend than Canadians do. We get misled into thinking that we have some sort of material advantage in beer making, confusing subjective choices with absolute measures. And of course the Brits think their beer is "better" still, because they prefer a thicker beer. It's all so inane.
I wrote about Riya previously, expressing a bit of skepticism about the technology. I should temper that by saying that I've never used it, and the most I've heard about it are some cursory micro-reviews, but my skepticism is based on the history of facial- and scene- recognition technology, and the barriers this product has supposedly overcome: Facial recognition, like character and voice recognition, has to be accurate enough that it is more beneficial than detrimental (e.g. nuisance false positives, and detrimental false negatives), and historically the latter is far more prevalent. Sure we'll get there, but it's just surprizing that a company could go from the primitive stage that we're at today to such an advanced stage, all in just one step.
Anyways, today I happened to look at my keywords to see that there has been an explosion of Riya postings - Google, or so the story goes, has put a $40 or $60 million dollar offer to buy Riya. If you follow the blogs around you'll discover the big circular authority that is prevalent in these sorts of "blog scoops", with A attributing his source to B, but B hilariously points to A as the authority. Remarkable stuff. Like the technology itself, it could very well be true...but I certainly would take it with a mountain-sized grain of salt.
Indeed, if Riya is as capable as we've been told, I'd say that $60 million would be grossly undervaluing the IP - This would make a photo service stand head, shoulders, and torso above its competition, and I'd be looking for a number more like $400-$500 million. Seriously.