Saturday, February 28, 2004

 

NYC Crosswalk Buttons Don't Do Anything

Years ago, I worked on the New York City Vehicular Traffic Control System (VTCS), the system that controls several thousand computerized traffic signal throughout the five boroughs. Slashdot had an article today about a NY Times article that says few of the crosswalk buttons actually work.

It's not the first time I've read a Times article related in some way to that system. We made the paper a few times during system deployment, when traffic got snarled throughout the city. What proud feelings we had, knowing what an effect our work had on the lives of millions of people.

If I was malicious and uncaring, I could tell everyone about a lot of other aspects of the traffic system that may not work as some people would expect, or about some of the politics surrounding design and deployment (hint: the traffic system exists primarily as a source of unionized jobs; helping people move around the City is just a side-effect). But that would eliminate work for Times reporters, so I'll just leave them guessing.


 

My Evil Web Site

Using the Gematriculator, I am shocked to discover that my web site http://kristopherjohnson.net/ is 60% evil.

Luckily, my blog is currently 69% good, and my resumé is only 34% evil, so I may have hope for salvation.

This site is certified 33% EVIL by the Gematriculator

 

Branching and Merging

A few months ago, we started developing a new product that was a major extension of an existing product. While we may have been able to keep one codeline that supported both the old product and the new product, many factors led us to decide to branch the codeline. I have continued to maintain the old codeline for existing deployments, while I and a group of others have worked on the new codeline.

In the new codeline, we have tried to correct many of our past sins. The original product was developed under a tight deadline with vague requirements and insufficient testing, and the codeline reflects that. The new codeline has some significant architectural changes in addition to having the new features.

I have been trying to keep things in sync between old and new. When we find and fix a bug in one codeline, or when a feature change is made that is desirable for both codelines, I merge that change into the other. This was easy at first, but as the underlying architectures diverge, it has become more difficult.

One problem is that we are using SourceSafe, and I can't find any good features for assisting in analyzing the differences between branches to intelligently decide what needs to be merged and what does not. At the level of individual files, branches can be merged, but I can't find an easy way to get a report of all changed for all files in both codelines and to merge individual sets of changes. (Maybe SS has better features, but I can't find them.) So we have had an informal manual process, which relies on other people telling me about things that have to be merged, and on my having time to do the merge.

This situation sucks, so what I decided to do about it was to write some Python scripts to help me. The first script I've written just compares the files in two directories, and writes diff files to a third directory. My hope was that this would give me a list of a dozen or so non-matching files, and I could spend the weekend getting everything back in shape. I'd then just run the script every few days to find new changes.

Unfortunately, when I ran the script, I found that the number of non-matching files was 135. Each codeline also has a few dozen files that are unique (that is, not corresponding to a file in the other project). Clearly, this is going to take more than a weekend.

I'm not sure exactly what I should have done to prevent things from getting so bad. Obviously, having one person (myself) be the only person working on synchronization between the codelines was a problem. Not having automated unit tests is another factor, because without such tests, it is dangerous to have changes merged back and forth without a lot of analysis. A better version-control tool would have helped, particularly one that supports merging an identifiable set of related changes to multiple files rather than forcing an all-or-nothing merge of all changes on a file-by-file basis.

Ultimately the core problem is that our original codeline had to be thrown together hastily, leading to code that is difficult to adapt to our new requirements while still meeting the old requirements. So I can blame management for not giving us sufficient time. Unfortunately, management isn't going to fix my problem for me, so I'll be working this weekend.

(For another story about branching/merging issues, I recommend the story of Mac Word 6.0.)


Sunday, February 22, 2004

 

Considering an MBA Program

Lately, I've been thinking a lot about going for an MBA. A few years ago, I would never have considered such a thing, but now it seems like a solution to several "forces" in my life:

The University of Georgia has an evening MBA program at a location close to me. So I figure it can't hurt to sign up for a semester's worth of classes and see whether this is for me. If not, it's just a couple grand down the drain.


Saturday, February 07, 2004

 

My R/C Helicopter

I've had my Piccolo R/C model helicopter for a couple of weeks now. I've had a total flying time of about 60 seconds. The average flight lasts two or three seconds, and many of them end in a "crash", which I define as "a landing that makes me wait for glue to dry before I can fly again". But they say any landing you can walk away from is a good one, and I've walked away from them all.

I've spent about $50 for replacement parts over these two weeks (I've broken the swashplate, the tail rotor, the main rotor and one of the push rods). I've also preemptively purchased $50 worth of additional parts that I expect to need in the coming weeks. I was grounded for four days waiting for parts to arrive, so I'm planning ahead.

It's been a lot of fun. I haven't built any models since I was a teenager, so putting this thing together was almost a new experience. The instructions were clear enough to follow, but also cryptic enough that I had to figure out many things for myself. I had to develop my own assembly techniques for manipulating small parts; I never thought I'd be able to get the 1.5-mm-long bolts screwed into the right places with my normal-sized hands and tools, but I did it.

The one thing I haven't quite figured out is the Piccoboard, a little printed-circuit board that handles the mixing of main rotor and tail rotor throttles. It has a couple of potentiometers to be adjusted, and I'm not sure I'm doing it right. It seems that any adjustment either has no effect or has a disasterous effect. More experimentation is needed.

Most of my flying has been inside my apartment, which is really too small for a beginning helicopter pilot (hence the frequent crashes). The chopper hasn't done much damage to my walls or furniture. There is a nice open area in the parking lot where I have flown a few times, but it has been pretty windy lately.

I don't quite have the hang of stable hovering yet, but I'm pretty sure I'll be able to do it pretty soon. Using the computer simulator has helped me get accustomed to the controls, but controlling a real helicopter in front of me is a lot different from controlling an onscreen copter. I never have to worry about flying the helicopter into my own body with the simulator, whereas that is a constant concern with the real one. But the real one is actually a little easier, because I can use binocular vision and my ears to get a better sense of what the heli is doing and where it is heading.

Having a little helicopter is really cool. I've found that I get a lot less frustrated at work these days, because I'm always thinking about that next flight.


This page is powered by Blogger. Isn't yours?