Fugato

Seems unprofessionally short and concise. A 432MB installation needs a more majestic name.

How about adding “Customer Technology Preview Limited Beta Release Candidate Ultimate Enterprise Communication Expression Interactive Presentation Foundation” at the end?

And maybe sprinkle in a few ™s and ®s? The crowd loves those.

Update: As an afterthought, I think I’ll add a couple of ☺ ☺ smileys here. This blog series ended up getting terribly negative!

If that were ever true, you wouldn’t see it.

My current software installation has been saying that for about three minutes now.

Yeah, Team Foundation again.

When we started using Subversion at work (AnkhSVN in alpha and no VisualSVN yet), I managed Subversion adds and commits and updates manually using the excellent TortoiseSVN, and left Visual Studio out of it.

The downside of that was moving and renaming files. Doing it in Visual Studio left Subversion unaware of the change, and doing it in Subversion left Visual Studio unaware of the change. Either way, one of them ended up seeing one file missing, and another file popping up that they knew nothing about.

Generally I renamed in Subversion and then manually edited the .csproj project file accordingly. Not everybody is happy doing that, and if you happen to do it when Visual Studio has unsaved changes to the project file, then it gets a little messy.

So moving to Team Foundation (and hence SCM integration) should have made file renames less painful.

Indeed, renaming a file is now a single operation in Solution Explorer. But it takes a full minute.

I’m not pulling that number out of anywhere dark and unhygienic. I measured just now. 78 seconds.

78 seconds renaming a file!

Okay, two files. It’s a workflow class file with a .Designer.cs sidecar file. But still. Renaming one file took 38 seconds, measured just now.

38 seconds renaming a file!

And these are files that haven’t even been checked in yet. They’ve just been added. And it’s not auto-updating references to the class name in my solution, because there aren’t any.

It’s like that every time, even late at night when I’m alone in the building. It’s not because of load. Team Foundation is set up on a virtual machine in one of my company’s VMware container machines a dedicated monster machine with 6 CPUs and silly amounts of RAM, serving maybe 60 or so developers. Our Subversion server was a wee VMware machine also running Trac and some other stuff, and was plenty fast enough (but to be fair, it was only serving about 15 people). Our admins assure us that the machine is not overloaded. If it’s a matter of “killing it with iron,” then TF sure needs a heck of a lot of iron.

The clincher: it took me less time to do the rename manually (flipping out to Explorer, renaming in TortoiseSVN, editing the project file in a text editor, reloading the project in Visual Studio) than it now takes Visual Studio to do the rename automatically.

And, of course, Visual Studio is completely locked up during the operation, so my work gets to wait. Because, you know, background operations are just too much to ask.

OK, I feel better now. Just had to vent. Sorry.

My Visual Studio output window just now, showing output from Source Control – Team Foundation.

All files are up to date.
All files are up to date.
All files are up to date.
Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Implicitly suggested course of action: reboot, followed by ignore-it-and-hope-for-the-best?

… are over, because we moved our source code to Team Foundation.

Yea, verily I say unto thee, that is a modal dialog box.

So my Visual Studio is locked up — completely — until somebody gives the server the kick it deserves.

I did try clicking cancel — but, of course, the cancel operation hangs too.

This costs thousands of dollars. Thousands! The usability is less grievous than SourceSafe (and that’s not saying much) — but the reliability, at least in my experience here, is worse. Fancy that.

I miss my Subversion.

Here’s a completely unfair, unfounded, superficial and silly observation on productivity when working with Microsoft’s Smart Client Software Factory.

I came across this “Where to start” page, and impaled my eyes on this heading:

Creating the HelloWorld (2 hours or more)

That sounds … not very promising. :-)

When you find yourself generating N lines of code looking like this:

case "str_PhoneNumber":
	return "PhoneNumber";
case "str_AddressLine1":
	return "AddressLine";
case "str_AddressLine2":
	return "AddressLine2";

then you may think you have a great tool. I say you have a problem.

That kind of code burns the soul and blackens the skies. And, going through the Service Factory hands-on lab at TechEd-Developers and finding myself under those ominous skies, I couldn’t help thinking “This is an abomination. There must be a better way.”

And then I went to Hejlsberg’s LINQ overview.

Oh, the neatness, the directness, the sheer design beauty.

Just as we now look back with disbelief to the days when we used to have open sewage canals in the cities, public stonings on Tuesdays, organized religions with enormous political influence and indoctrination of the masses from birth (wait, oops, we still have that), ruthless state oppression, and ubiquitous slavery sanctioned by church and state, we will one day look back to case "str_PhoneNumber": return "PhoneNumber"; and think “wow, it really used to be that way.”

I’m at the TechEd-Developers conference in Barcelona. In addition to just the enjoyment of being in Barcelona, I’ve enjoyed several things particularly:

• sessions on testing and continuous integration with Roy Osherove. These were lively and fun, and obviously he is an authority on the subject. His pre-conference sessions each ended with short songs. These should have been still shorter. But his advice on testing is spot on.
• an excellent presentation by one Brian Long on alternative debugging tools for .Net production debugging. Long is a sharp Briton with a delightful flair for erudite, witty language, but he also knows his way around WinDbg and SOS.dll.
• the TV monitors in the hallways, which feature a video on a repeat loop of hardly more than a minute or two, much of which is Microsoft CEO Steve Ballmer inflicting some marketing on innocent viewers. The combination of Ballmer’s slightly-too-wide-open eyes and the slightly-too-loud volume setting and the more-than-slightly-brainwashy marketing message, imparts a delightful 1984 feeling.
• Anders Hejlsberg’s sessions on the LINQ framework and other language extensions in C# 3.0. Hejlsberg has designed a major programming language (C#), yet he has neither a large beard nor long hair, and is socially capable and an excellent presenter. And LINQ is really, really cool (not many code demos inspire spontaneous applause). All this comes adorned with an agreeably slight Danish accent, and a frequent “hahah” that I will call Hejlsberg’s Little Chuckle.

I am dying to use LINQ, though I guess I won’t get to do that at work for a while. I do get to be agile though … and I don’t doubt I’ll continue to have occasion to use a debugger as well. So it’s only the Ballmer bit that’s pure, unadulterated entertainment.

IE6 started to throw this JScript error in my face, “Stack overflow in line: 0″, in a mildly involved bundle of one-off Javascript I was cobbling together.

It was a series of calculations trickling down from an initial textbox change through cascading onchange events and homemade callbacks, and it worked, that’s not the problem — but once it was done this error message popped up each time. It didn’t happen during the calculations, it happened outside my code. I did not have any infinite recursion anywhere. Firefox showed no problems.

When I disabled the deepest part of the calculations (where the execution stack went deepest), this didn’t occur at the end. I could pinpoint just where I had to stop such that this wouldn’t happen at the end. This was around 10 stack frames, if I recall correctly.

Googling turned up nothing in the way of an explanation or a fix.

I finally worked around it by wrapping one call in setTimeout(function() { call(); }, 0); to put the rest of the execution on a fresh stack.

That worked around the spurious error dialog … but I still don’t know what was going wrong. Can’t stand that!

I know, I know, priorities, cost-benefit, concentrate on features, etc. But still.

It’s 2006. Eight years of development and four major versions released. Why does a 250-billion-dollar company’s flagship development product still squeeze large, frequently used, tabular user interfaces into non-resizable dialog boxes?

Tables with tens of thousands of rows, some of them containing astounding stretches of text such as TeamFoundationContextMenus.SourceControlPendingChangesSourceFiles.Compare.TfsContextPendingCheckins.CompareWithWorkspaceVersion (honestly!) — squished in a 374×49-pixel porthole quivering in its puniness in the center of my 1920×1200-pixel screen. Who perpetrates this kind of obscenity?

In that last one, how do we tell the four different ActiveDirectory exceptions apart? Well, we can mouse over them to get a tool tip. Or we can drag the eminently draggable-looking column separator line such that the checkbox columns disappear off the right edge.

I don’t doubt that this product got usability tests up the wazoo. Some triaging group meeting must have reviewed the (surely inevitable) suggestions of resizable dialog boxes, and concluded: “nah.”

Hey, maybe in late 2008.