You've always hear about the five stages of grief, and there is no one currently experiencing more grief than the Republican Party. With the low Presidential approval rating, the fiasco in Iraq, Woodward's new book, and now with the Foley affair, they have plenty of grief to go around, and it's almost fun to see them go through the various stages.

First, we had Bargaining as KIrk Fordham tried to bribe ABC News into not publishing the IMs from Foley.

Then, we had Anger as various Republicans started blaming each other for the mess.

Now, we are getting into denial. According to James Dobson and Matt Drudge, the Foley affair NEVER happened. It was a joke. Yeah, that's the ticket. A prank. One of the pages must have made Foley do it!

However, some Republicans have already come to the final phase, Acceptance. According to this Robert Novak article, an unnamed Republican says that Representative Hastert's resignation from Majority Leader in the House is really moot.

We are sure to lose the house, and [Republican Majority Leader] Denny [Hastert] never would want to be minority leader.

Somewhere depression is suppose to come in, but I suspect that will hit the Republicans after this November's election.

Have you seen those super automatic espresso makers? These machines things cost as much as $3,500. Who is going to buy one of those?

I would for one. In fact, I've bought two. A few years ago when I was a theoretical Internet millionaire, I bought my mom one for her birthday. I bought a second one for myself not too long ago.

These machines are amazing marvels of technology. Coffee beans go in one end, and after the machine makes a few rather terrifying noises, out comes espresso on the other end. The machine automatically grinds the beans, tamps them down, and brews the coffee. A cup of espresso comes out one end, and a little coffee doot is ejected and goes into the coffee doot holder that has to be emptied periodically.

A good coffee maker will make a cup of espresso with a good rich creme (Italian for coffee scum). The funny thing is I actually didn't drink coffee until about eight months ago.

My son Daniel was the first coffee drinker at our house. He was getting up at 5:30am to get to his high school and didn't get home until five or so at night. He started drinking instant coffee, and my wife was concerned with it. So was I. I told him right out:

Daniel. I don't want to see a young teen sitting there drinking instant coffee. You might as well learn to drink the good stuff. I bought him a drip coffee maker and later on a coffee grinder, so he didn't have to drink Folger's which according to the Geneva convention, cannot be served to prisoners of war. I soon got a job which made my son's hours seem quite reasonable, and tea was just not cutting it.

I quickly learned the wonders of coffee. I use to drink coffee, but only with sugar. When I was diagnosed with diabetes, I decided to give up all sweetened beverages. I quickly got use to unsweetened tea, but never got use to the taste of unsweetened coffee. Now, a half dozen years later, and I decided it wasn't that bad after all.

The secret is decent coffee. The stuff at my job is awful, and I won't drink it straight. It's thick and bitter with a bad burned flavor. I found that if I started with decent beans and ground them myself, I could get a decent cup of drip coffee.

My downfall was a restaurant near my job called Cafe K. I had ordered a cup of Latte, and loved it. I have ordered latte before at Dunkin Donuts and it was pretty much coffee with a lot of milk and some bubbles on top. This however, was wonderful. It was rich and smooth with a deep coffee flavor. The texture was creamy and a consistent finely textured foam throughout. I ordered espresso and it was strong without being bitter or burned with a red creme resting on top. This was no coffee as much as Java based heroin. I was completely hooked.

Right before Passover, I bought a refurbished Saeco automated coffee maker from Whole Latte Love and I'll go through a couple of cups of coffee per day, and I'm not even around during the day. We are thinking of getting Costco club membership just so we can buy beans in bulk. Even my youngest uses the machine, although not for making coffee. He uses the steamer to steam milk for hot chocolate.

I am still working on my milk steaming skills. I have a pretty fine foam texture on my milk, but I am missing something. At Cafe K, the coffee and milk mix into a luxurious foam. However, I can't seem to get the texture right. Mine seems to separate. It looks okay, but its not the same that I can get at Cafe K. I am thinking of quitting my job and working at Cafe K just so I can learn how to make a decent latte.

For over 14 years, I've been a ClearCase administrator, and ClearCase has been very good to me. However, lately I've been telling all of my friends that ClearCase is quickly becoming a dead end version control system, and that they should start learning Perforce. I believe that Perforce will become the most important version control system, and it is all thanks to Subversion. To understand why ClearCase is in trouble, you have to understand Cado Computers.

Cado Systems built business computers way back in the late 1970s and early 1980s. The basic Cado 20/24 system was based upon the eight bit Intel 8085A and came with 48K (that's Kilobytes, not Megabytes) of memory. Despite this, Cado Computers could handle up to four users simultaneously. While similar computers like the IBM Datamaster were over $100,000, a typical Cado system could be had for around $20,000. That was an amazing price breakthrough. A typical small business could finally afford a real computer! They could easily save the cost of a Cado Computer in just a single year by having the computer handle much of the accounting and ledger keeping.

A Cado Computer can track invoices, and help keep money flowing into your organization. It could print your invoices, checks, and bills automatically. The closest competitors couldn't produce a computer with this feature set for five times the price! So, how was Cado able to produce a computer that could do so much for so little money? Simple, Cado realized that hardware was much more expensive than software. By optimizing the hardware, Cado pushed everything off to the people who handled the software. For example, Cado had no file system. If the developer wasn't careful, they could easily place two files over the same area of the disk, or put a program on top of a file. The developer actually wrote down on a piece of paper where each file and program was stored on the disk.

Cado saved hardware costs by allocating only 2K for each user for program space. In order to fit programs into that tight amount of memory, developers were given few resources in order to program. Developers only had 26 six byte numeric registers, nine alpha registers that ranged in size from 20 bytes to 40 bytes, and five 255 byte long buffers for data storage. All these resource were shared by the developer and the OS, so the OS might decide to use a particular buffer which meant that any data the developer saved there would be overwritten.

Sure development was slow and difficult, but as long as hardware costs were high, it made sense to push these tasks onto the developer. In fact, the whole architecture of a Cado Computer was built upon the premise the Hardware was always going to be more expensive than software. You could say that Cado Computers bet the company on this fact.

By the mid 1980s, that assumption broke down, and Cado quickly saw its sales plunge. PCs were dirt cheap and plentiful. Software tools like Dbase made developing complex business software much easier. When PCs prices really dropped, and millions of PCs were out on the market, PC accounting software could be written that was more flexible and more powerful than could fit on the anemic Cado hardware. The cost of developing that software could be spread over millions of PCs. By the late 1980s, you could by a PC based accounting system for under $10,000 that could outperform anything found on a $20,000 Cado. Cado simply disappeared in a wave of sales and mergers.

ClearCase got its start almost 20 years ago by a little company called Atria. Most version control systems are fairly similar: The user creates a working directory on their local computer, and then retrieves the version of the software they want from the version control system. The user has to keep retrieving the software, and has to make sure they have enough disk space to get all of the files they need. Compiling the files into a software package was a long process since most computers had slow processors.

ClearCase changed all of that. Unlike most version control systems, ClearCase used views that could be stored on a large and very fast server instead of a slow and small desktop system. To a typical ClearCase developer, once you set up your view, it appeared that you directly accessed the software from the source archive. The slow process of copying all of the files to your local workspace was no more. Better yet, you really didn't need a local workspace since your view and the smoke and mirrors of the VOB handled what versions of the software you would see.

And, ClearCase also had another magic trick. Why bother compiling code if someone else already compiled it for you? What if the version control system looked at what you wanted to build, said to itself, "Hey Ralph has already built this piece of code!, why not simply give you what Ralph built instead of you wasting your time compiling it yourself?". This was called winking in and was one of ClearCase's most highly touted features.

In the past 20 years, things have really changed. That slow and small desktop system contains a really fast and powerful processor (maybe even two), and now you've got at least 40 or more gigabytes of space sitting on your desktop. Meanwhile, networks have become more ubiquitous and more crowded. Now, ClearCase isn't the only thing that wants to use your network, and the heavy traffic used by ClearCase bogs everything down.

To handle the change in environments, ClearCase introduced what are known as static views. Static views download all needed files to your local system where you can do your development. Of course, this simply makes ClearCase just like any other version control system, except that ClearCase costs more, takes more resources, and is slower. Besides using snapshot views means you can no longer do winking in already built objects.

Except that ClearCase's winkin feature isn't as important as it once was. You see, that powerful piece of iron on your desktop compiles code in no time flat. By the time ClearCase searches its database, finds a view that has the same code you're compiling, and then transfers that to your view, you've already built that code. What takes long now is linking all those little pieces of code together, and that takes quite a while thanks to the much more complex structure of the software and underlying API. And, linking over a network is much slower than linking on a local machine.

So, you see that like Cado, ClearCase made basic assumptions about its environment that are no longer true. However, Rational and later IBM have found a way to keep ClearCase sales up. Developers may hate ClearCase, but IT departments love it.

In a large corporation IT departments want to control development, and ClearCase's centralized structure makes it easy to do. ClearCase is very complex to setup and use and local expertise is expensive. However, if you have a centralized IT organization, that cost of expertise can be shared among all development organizations. Rational Software (and later IBM when it bought Rational) understood this, and was able to encourage ClearCase sales by making ClearCase part of a larger IT strategy. Fortunately for Perforce, Subversion was released.

Subversion was released about three years ago as an open source version control system. It was pretty much everything ClearCase was not. Where ClearCase was extremely expensive, Subversion was free. And, where ClearCase was hard to setup and understand, Subversion was easy to use. Although Subversion was not as feature rich than ClearCase, it was much easier to use, and being free meant that anyone could down load it and use it. And, that's just what happened.

As I said, developers hated ClearCase as much as IT loved it. And, what developers really hated was the way IT could control the use and workflow of ClearCase. Want to start a new project? You'd had to contact IT. Add a new user to your development group? Contact IT. Change something around in your development? Create a new branch? Add new files? IT needed to approve it. And, IT's approval could take days. However, what if the development organization could bypass IT by downloading their own version control system. A system that is freely available, and easy to setup and install? Thousands of development departments broke their corporate policy, bypassed IT, and setup their own Subversion development environment.

When IT found out, their typical reaction was try to stomp it out. Unfortunately, you couldn't. How can you prevent someone from downloading and using a freely available piece of software? And, when push came to shove, local managers would side with their development departments. After all, their department needed the software, and bypassing IT allowed more flexible development and less downtime.

In the last year or two, IT is recognizing that you cannot force developers to use ClearCase anymore. However, there are legitimate concerns with local development shops using Subversion. First of all, most of these Subversion archives are sitting on people's desktop machines and not getting backed up. Not something you want for important commercial assets. Second of all, Subversion really was missing some important features. For example, Subversion does not really have built in account protection. It depends upon the operating system or Apache server to provide it. Subversion also didn't allow users to delete individual versions of a file (or entire versions of a file). Normally, this was a good thing, but what if a user checked something into an archive that shouldn't be there such as proprietary information?

There were also problems scaling Subversion, and with Subversion's ability to handle more complex development strategies. Plus, who is IT going to call if they have a problem with Subversion? This is where Perforce comes into play. Perforce is fairly straight forward to use and liked by most developers. Perforce is also more feature rich than Subversion. Plus, unlike Subversion, there's a company you can call for support. Although Perforce is more expensive than Subversion, Perforce is much, much cheaper than ClearCase.

The results is what I call the great compromise. IT gives up their ability to control every single aspect of CM. In return, local developers allow IT to take care of the iron, training, and other tasks that local development shops never liked in the first place. Developers have a fast and efficient system for development, and IT has secured the corporate software assets from disasters. All in all, not really a bad compromise.

Ever since the first version control system, SCCS, came out from AT&T's unix distribution over 30 years ago, version control systems allowed one to branch their code. Merging, however, was a completely different story.

The biggest problem with merging is that it can be quite difficult. In order to merge two different files, you not only need the two versions being merged, but you also have to identify the base to use for the merge. This base selection process is very difficult because the results of the merge depends heavily upon the selection of the base. Plus, any merging algorithm has to take into account the chunk size that will be used for the merge process, whether or not the merging algorithm will recognize line movements, white space issues, and even the syntax of the code.

Whitespace means things like tabs, spaces, and line endings. Windows and Unix systems use two different line ending characters, so if one version of a program was done on Windows, and another on Unix, each line could be different even though not a single line was changed in the code. Another problem is that Python scripts and Makefiles are whitespace specific file formats, but most programming languages like C++, Java, and Perl are not. Most merging algorithms get around this issue by allowing you to decide whether or not to ignore whitespace.

Then, there is the chunk size of the code to consider. What if only a single character on the line changes? Do you consider that as a single change, or do you do the whole line. How about non-line oriented languages like HTML or XML. Should your merging algorithm recognize various language syntaxes? Most merging algorithms simply look for line changes since that will work with almost all files. However, ClearCase does not only do regular text files , but also does XML diffs too.

So, most version control systems let you branch, but avoid merging. Enter ClearCase to change all of this. When Atria created ClearCase, they spent a lot of time and effort making sure merging two versions of a file is a smooth and mostly automatic operation. It is such a rare feat, that it takes developers quite a long time to get use to the idea of allowing a program to automatically handle their merging. ClearCase does such a great job, that branches proliferate in places that use ClearCase. In most places, each developer has their own branch off of the main line of code. They merge the main line of code to their branch, and then when they are ready for the world to see their efforts, merge this code back into the main line. A single development shop could have hundreds of active branches at once, and it isn't too unusually for a single developer to use multiple branches at once.

Perforce also worked hard at merging. You have to if you want your software to be considered a world class version control system. However, Perforce looked at branches in a somewhat different light than ClearCase. In Perforce's view, developers work directly on the main branch, and not on development branches as one wold do in ClearCase. Branching is mainly done to prevent code freezes.

A code freeze happens when you are almost ready to deliver a piece of software. You send the release candidate to your Quality Assurance (QA) organization. QA tests the release and sends you back that list of defects. Your developers fix the defects, then send a new release to QA for testing. Adding new features at this point may add new defects, so all new development is forbidden and only defects are fixed. Meanwhile, you are now paying your developers to twiddle their thumbs while they wait for QA to finish testing.

In order to more efficiently use your development workforce, you create a release branch. All new development continues on the main line while only defects are fixed on the release branch. Now, most of your developers can continue working on without worrying that they are possibly adding new defects to the release candidate. Defects that are found on the release branch can be fixed by only one or two members of your development team while the rest continue their work on the main line.

If a defect is discovered on the release branch, Perforce allows you to fix that defect on the release branch, and merge that change back to the main line development branch.

Although Perforce merging algorithm works great on release branches, it doesn't work very well when developers use branching like they do in ClearCase. Most developers have discovered that Perforce does not handle the back and forth merging required by the rebase/deliver method used in most ClearCase branches, and ask "Why doesn't Perforce just do what ClearCase does?".

At the Perforce European Users Conference, Laura Wingerd gave an excellent presentation about branching strategies and explained about the two different types of branching and why Perforce and ClearCase tend to handle branching differently.

ClearCase handles what she called Convergent Branching. That is, the differences between the two branches tend to converge over time. A developer creates a branch from the main line development, and uses it to do their development. Every once in a while, they rebase by merging any new changes on the main line branch to their development branch. After a while, they do one final rebase, and then deliver their changes by merging their development branch back to the main line branch. ClearCase is perfectly tuned for this rebase/deliver algorithm.

This type of branching is called convergent because, as they merge the code back and forth between the branches, the two branches will remain pretty much in sync. After all, the developer wants to start off with a copy of what the main line development looks like. And, when the developer delivers their code, they pretty much want the main line branch to match what is on their branch. Although the branches can differ, the differences will generally disappear over time.

Perforce, on the other hand, handles what Laura Wingerd calls divergent branching. That is, the differences between the two branches tend to diverge over time. In my above example, the code on the release branch is generally frozen while the main line keeps developing. Within six months, the differences between the main line and the release branch will be fairly large. In two years, they'll be even larger.

However, not all divergent branching involves release branches. For example, you might have a Unix product that you port over to Windows. This involves quite a few changes in the code because of the way the OSs handle internal calls, and probably differences in the API calls. Later on, you want features developed for one OS will be merged onto the other. However, the differences between the two branches will never be 100% reconciled and may grow during time.

Perforce merges were designed to handle divergent branches. ClearCase always picks for the base the version of the file that was the most recent common ancestor of the two branches being merged. Perforce, on the other hand, finds the ancestor with the most rich history in common between the two versions. Perforce also tracks not only that a merge was done, but whether it was a copy or a merge, and whether the merge or copy operation was done without modifications, or if the developer had to edit the results. And, Perforce tracks exactly which versions of a file were considered for a merge operation. ClearCase can only track that a merge took place between two versions of a file.

This results in ClearCase having difficulties with divergent merging and most developers simply perform divergent merges in ClearCase manually. However, for all of its smarts, Perforce has problems when it comes to convergent merges. Most of the time, Perforce simply picks the wrong base to use for convergent merges because it attempts to over analyzes the situation and doesn't realize that in convergent branches, most of the differences between the branches have already been accounted for in the last merge.

To get around its problems with convergent merges, Perforce recommends what they call a Merge Down/Copy Up strategy. That is, you merge changes from the parent branch to the child branch for rebase operations, but you copy the files from the child branch back to your parent branch for delivery. Although the rebase step in Perforce is fairly straight forward (you do the merge the standard way), the delivery operation becomes a complex seven step dance which involves running the merge operation twice.

Perforce recognizes this issue and promises that they will simplify the process of thecopy down operation, and maybe completely automating it in future versions. Meanwhile, Laura Wingerd's presentation has helped clarify the question on when it comes to merging, "why doesn't Perforce just do what ClearCase does?" in merge operations.

A bit over six years ago, I weighed somewhere around 275 pounds. I had high blood pressure, low HDL cholesterol, felt fatigue, and had high triglycerides. I then got diagnosed with diabetes, and decided maybe it was time to loose a bit of weight.

I exercised, watch what I ate and dropped down to a more reasonable 175 pounds. For over six years, I've kept the weight off. My blood sugar is normal, my HDL cholesterol (the good stuff) is excellent, my blood pressure is under control, and I still exercise (run four miles per day and walk six) and watch what I eat (haven't touched a potato chip in years). I did all that work, so I wouldn't be fat.

Now, I find out that if I didn't bother going through all that trouble, I wouldn't be fat today. Instead, I would have Metabolic Syndrome -- a disease that affects 75 million Americans.

Oh, is there anyone who can save us from this terrible epidemic?

Why yes, the same people who brought you Viagra, Xanax, and Viox have come up with a whole slew of pills to help us fight this new found epidemic. Researchers have found this syndrome convenient as a way of getting funding. Doctors have found this syndrome useful in diagnosis because by classifying obesity as a disease, you can now recommend a course of treatment as can be seen in this before and after demonstration:

BEFORE
Patient: Doctor, I weigh almost 300 pounds, I can't fit in airline seats, and I have no energy, so I sit around all day and watch TV. What is wrong with me?

Doctor: Oh my, I have no idea!

AFTER
Patient: Doctor, I weigh almost 300 pounds, I can't fit in airline seats, and I have no energy, so I sit around all day and watch TV. What is wrong with me?

Doctor: You have Metabolic Syndrome. Here's a prescription.

Look, for most of my adult life, I was a blubbery mess. I didn't take my health seriously until I was diagnosed with diabetes. I know it isn't losing weight, and I know it isn't easy keeping it off. I watch everything I eat, walk six miles per day back and forth to work, and run another 4 1/2 in the middle of the day.

However, why I was fat was no mystery. I ate like a pig, and sat around all day at work typing into my computer. On my way home, I would get hungry, stop at a local 7-11, and buy a Big Gulp and a king sized candy bar (about 600 calories worth of junk food). Once I got home, I was too tired to do anything, and I would watch TV and eat whatever snacks I could find.

Yes, there is a obesity epidemic in this country, but that's mainly because we eat out more than we use to, eat more calorie rich processed foods, and do a lot less physical activity. Not long ago, changing channels on your TV would involve you getting out of the chair, trekking across the room, and turning a knob on the TV set. Now we have the remote. Heck, if I did decide to get up to change channels on my TV, I couldn't do it without the remote. Our TV has no channel buttons on it.

When I was a kid, a typical McDonald's meal contained a bit under 500 calories (burger, fries, and Coke). The standard McDonald's meal now contains over 1000 calories (medium burger, medium fries, and a medium Coke). Supersize it, and you're talking over 1500 calories. And, a typical customer now goes to McDonald's three times per week (up from twice per month when I was a kid). And, don't even get me talking about things like Cinnabon's (670 calories or 1100 calories for their Caramel Pecanbon).

There are five symptoms to Metabolic Syndrome: Obesity, high triglycerides, low HDL, high blood glucose levels, and high blood pressure. Other symptoms can include swelling and joint pain. However, if someone is officially obese (that is they weight at least 30% more than they should), body circulation starts to get poor which can lead to edema and high blood pressure. Excess fat around the waist increases insulin resistance which can cause high blood glucose levels. High glucose levels cause your body to produce more insulin, and that can cause high blood pressure and higher triglyceride levels.

Remove the excess body fat, and all the other symptoms completely disappear. Before losing the weight. My HDL cholesterol was 21 mg/dl, my blood pressure was 165/115, and my HgA1c was 17 (HgA1c measures average blood glucose levels. 5 is considered excellent, 6 is good for a diabetic). Now, my HDL cholesterol stands around 65 mg/dl, my average blood pressure is 121/85, and my last HgA1c was 4.8.

People have asked me how I managed to not only lose the weight, but keep it off. There is no great secret. I lost about 100 pounds because I went on a strict calorie limiting diet, and the pounds have stayed off because -- even six years later -- I am still on a strict calorie limiting diet. In fact, I have resigned myself to stay on this strict diet for the rest of my life. I also exercise like a maniac. I run and walk so much, that I wear out my sneakers about every three to four months.

I understand how hard it is to lose weight. I understand that in our society it is damn difficult not to be fat. You have to break accepted cultural norms, plan your meals, and find time to exercise. However, before you attempt to find some magic pill to cure you of Metabolic Syndrome, take a good look at what you eat, and how much exercise you do. Look at the Nutritional Facts on the side of everything you eat, and see how many calories it contains. Remember to take into account what you're eating as a serving vs. the stated serving size. For example, a bottle of Snapple is considered 2 1/2 servings. That means, a bottle of Snapple isn't 125 calories as stated on the Nutritional Information panel, but 325 calories. Also remember that an average adult only needs about 1600 to 2000 calories per day.

The last thing we need is another pill to cure another newly discovered disease.