Solving problems -- with help

I solved the link problem of yesterday. To do it, I needed some help. Not from other people, but from tools and techniques. Here's what I used:

- Version control. I used version control to track changes as I investigated the problem.
- diff and visual diff. With one working project and one failing project, I could compare the two and identify the differences.
- Automated tests. Once I made changes (and got things working), I ran the tests to ensure that the programs were working as I expected.

I could have solved the problem without these. But I feel much better with these tools and techniques. I have a higher degree of confidence that I have solved the problem and not introduced other problems.

Automated testing was useful later in the day, as I worked on a different problem. This task was to extend one of a series of programs. They use some common libraries, and I had to make changes to the libraries. How to ensure that all programs work after the change? Run the tests! I finished my changes at the end of the work day (a little later, actually), and I ran the tests, looked at the results, and knew I was finished. I left the office with a good feeling.

Back to tech

Frustration today.

I have two C++ projects in Visual Studio 2008. They both use a library to read and parse files. (The library is an in-house library, so we have source code and can modify it.)

One project compiles, links, and runs. (And works!)

The other project compiles... but does not link. Visual Studio complains about previously defined globals.

The one difference between the two projects is their source. One was originally built with Visual Studio 6 and converted to version 2008. The other was created in VS 2008. The one that works is the converted one.

I've looked at the project files (which VS 2008 conveniently keeps in XML) and can see no significant differences. I've tried various tricks to get the project to compile, to no avail.

Well, at least I know what I will be doing tomorrow!

Sometimes the job is more than programming

The team has been working long hours these past few weeks. The extra effort has been taking its toll. People are a little on edge, a little less patient.

I've been helping by listening. I am a neutral party, for a number of reasons. (I'm the "new guy", I'm a programmer and not an economist, and I'm a bit older than most folks.)

A group of us went out to lunch today. It was a "deli run": go out, get some sandwiches, and head back. The group was heading to the food court, but one person wasn't happy with that choice. I accompanied them to a local pizza place, letting the other folks head to the food court. It gave the one person an opportunity to vent. It was mild venting, but probably needed.

My job is to be part of the team, not simply a "hired gun" specialist. I think I achieved that today.

Back and forth on typedefs

A post about technical issues today.

I've been working with C++ and STL. While C++ is an old friend (dating back to 1997), STL is new to me. Yet it's not that big of a challenge. (Perhaps my experience with Perl and Ruby help me understand the goals of STL.)

One technique that I have been using is typedefs for STL types. STL has a syntax that leads to long type descriptions. For example, a simple list of strings might be:

std::vector<std::string>

and a hashmap with string keys and string values would be:

std::map<std::string, std::string>

Those are readable. Things get messy when the value for a hashmap is another type, such as a list of strings. Then you have:

std::map<std::string, std::vector<std::string>>

By itself, that's not bad. But you use this type in a number of constructs. It requires a lot of typing (or copying and pasting) and the elegant programmer in me winces at hard-coding the type throughout the program.  I fear a change in the data structure will require a lot of hunting for the references to the type, replacing the old type with the new.

The answer, in C++, is typedef. The typedef keyword lets you create your own tag for a type. So with

typedef std::mapstd::string, std::vector<std::string>> Map_Name_Entries;

You can create a simple-to-type name for your new type. In this case, "Map_Name_Entries". In addition to a shorter name, you get a descriptive name, one that can convey meaning to the programmer. (Me, or anyone else working on the code.)

At first, I was typedef-happy, using typedefs for all of my STL types.

Then I found that there were two classes of STL types. One class was generic, such as a list of strings. The other class was specific, with complex structures. The generic types had generic names; the complex types had specific names. In some cases, multiple complex types had the same structure but different names, since I used them in different contexts and for different purposes.

I changed my code and removed the typedefs. At first, I removed all of them. I found that using the raw STL syntax for the generic types made the code easier to understand. I also found that the raw STL for complex types was hard to understand.

So at this point, I have re-introduced the typedefs for complex types. My rules to divide simple and complex are unpublished and unvoiced. The decision to use the raw syntax or to use a typedef is more art than science, more emotional than rational. Yet they work, at least for me.

Always try something new

I attended the CALUG meeting last night. That is not new; I've been attending them (on and off) for about a year.

What was new is my route to them. Working in WAS and taking the train home means that I get home too late to drive to the meeting. (And I have to drive; they are outside of transit range.) Instead of coming all the way home and driving all the way there -- which involves some back-tracking -- I drove to a train station in the morning and then got off the home-bound train "early" and drive to the meeting.

This works because the meeting is located between BAL and WAS, and driving to a different train station positions me better in the evening. This trick does not work for the BaltoLUG meetings, which are north of BAL and not "on the way". I get no savings for those meetings.

The important thing here is to try something new. Step outside the box.

Or wait for the "Yellow line" to be extended to Columbia, which will let me attend CALUG meetings without driving. But that's several years away.