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.
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'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.
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.
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 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?
Over the past year we've made it the norm in our family that we have a salad with most dinners (some dinners don't really work well with a salad, so this rule is more general than absolute). We buy big tub things of mixed greens (Fortinos, a local branding of Loblaws - I think they made an Italian sounding name to pander to the nearby Hamilton market - has an awesome very high quality, organic, already cleaned tub with something like 2KG of mixed greens for ~$5. With proper storage it lasts for about a week), and then add in some cut green onions, grape tomatoes, cucumbers, and whatever else tempts our taste buds that night.
The health benefits are unquestionable, but more importantly it's an epicurean delight.
It is remarkable how accessible, and inexpensive, such quality-of-life improvements really are.