February 2009


After having a pretty hectic work schedule the last few weeks, and after reading Anthony’s post on the Pomodoro Technique, I thought I’d try it. I don’t know if I’ll keep using it long term, but for now, I see a few benefits. Here’s what I’ve noticed after a day.

The first thing is that it’s a lot easier to get myself to stop working. Hopefully this will translate into being able to predict when I’m going to get home, farther in advance than “I’m leaving now.” It also gives me periodic interrupts throughout the day when I can check email, read a blog post, get water, use the restroom, check the kanban board, etc.

I noticed how much time I spend on things. For example, yesterday I decided to transcribe some notes from paper into our work tracking system. It took almost an entire Pomodoro. Having the time box gave me pause — was it worth writing up what I was working on? I think this could help me become more self-aware, better able to recognize when I’m wasting time, in the future.

It was also nice to focus on one thing at a time. My work schedule usually is “charge!” That means work furiously on whatever comes to mind. It doesn’t make me relaxed, and probably doesn’t make me more effective.

I also noticed that I’m not very good at sticking to the time limits. I usually stop my pomodoro after 25 minutes and 16 seconds. I usually start the next one 15-30 minutes later.

And, when people come over and ask me for help, I’m still pretty likely to stop what I’m doing (i.e. interrupt my Pomodoro) and help them.

Finally, I feel really silly walking around thinking, “gotta keep doing this pomodoro thing” which, in english-only, is “gotta keep doing this tomato thing”. So I have a tomato timer on my apple computer. Whatever. It seems to help.

Advertisements

Today Team Foundation Server was offline in a mysterious way. The fix was pretty non-intuitive, so I’m writing it up.

First, we had done an upgrade of SQL Server over the weekend, and things (eventually) worked. Some users reported problems with some TFS queries, though, so we applied some updates that were supposed to fix it. Unfortunately, bigger problems ensued.

The errors generated when someone tried to access source control were

TF53002: Unable to obtain registration data for application VersionControl.
TF53002: Unable to obtain registration data for application VersionControl.
TF30040: The database is not correctly configured.

and then a warning and two info messages

TF53005: Unable to retrieve the Team Foundation Server installed UI culture.
TF10181: The Team Foundation source control server started at ...
TF10182: The Team Foundation source control server stopped at ...

… all right at once. This happened right after some updates had been installed.

I scrolled down in the error messages and noticed that the first three all had the message “TF30063: You are not authorized to access http://TFS:8080” so I assumed there was some basic auth[nz] thing that wasn’t working.

Google to the rescue! I looked for pairs of the error codes, and came across a post on MSDN’s forums about TFS being unusable after installing Windows 2003 SP1. Following the chain of “This other post solved my problem” links, I found KB 926642. It didn’t look related at all. Problems accessing windows shares via cnames?

Thinking about it a little more, it started to sound plausible. Our TFS server name is not the same as the machine name, we use a CNAME. The KB article had some other symptoms: “Event ID 537 is logged in the Security event log” – check; “you experience authentication issues when you try to access a server locally by using … its CNAME alias” – check (tried going to \\realmachine\c$ – works, \\tfs\c$ – tells me I’m not authorized).

I set the DisableLoopbackCheck flag (didn’t need DisableStrictNameCheckin) and restarted IIS (didn’t need to restart the entire machine), and things appear to work.