Joel Hainley : San Francisco Bay Area Software Consultant

I’ve been working on a new set of features revolving around tracking user’s statistics relating to their performance with the question pools. I am now tracking information about each question a logged-in user sees, whether they answer it correctly and a timestamp. At the moment this information is simply being logged to a database without any visible changes to the system. I’m going to let this data accumulate over a week or two period until I have a decent set of data to test the new features.

It’s probably obvious if you think about it, but adaptive learning is really what I’m implementing here, as well as the ability for the user to see how they perform with each section and even each question. I’ll be able to show a user a graph of their performance with each question, section over time no matter whether they are simply doing practice test after practice test, or are systematically reviewing the question pools with the review tools.

This will generate a new study tool as well, because I will be able to generate tests in real-time that give them exposure to questions they haven’t seen before, or questions that they have had problems answering. It should be another fairly useful way for people to prepare for the amateur radio tests. It will also give me a chance to play with more featurs in jpgraph and to finally dig into the generation of sparklines.

In addition I’ve been working on a couple of other features that aren’t related to the above that should get hamtesting.com a lot of exposure in a very short amount of time. I’ll be announcing these new tools/features soon and at that time I’ll try to map out for you my strategy for how this is going to work. Although sometimes it’s hard to map out a business strategy when my main primary intention is to provide these tools for free to the amateur radio community.

Chico Velo’s Wildflower Century was the start of my quest to ride a century a month for the next year. My cousin lives in Chico along the park and offered to let me stay at her place Saturday night so I went up Saturday afternoon. We stopped by the registration desk the night before so I was able to pickup my water bottle, t-shirt, bandana/map, wristband and other stuff. CV had some stuff sacks made up with the wildflower logo on them which was a very cool idea. Then I took her out to dinner, we visited for a while then I went to bed so that I could be up early and ready for my ride by 6am.

Waking up the next morning, I had my usual pre-century breakfast of cheerios and instant breakfast and decided to ride over to the fairgrounds instead of just picking up the ride as it passed close to where I was staying. I was a little nervous about the ride I’ve been really busy with work and travel and haven’t had a lot of time to train so I was a little concerned about how things would go. So I came up with a gameplan, “ride slow until after lunch”, I wouldn’t start pushing until after the hills were over and I was into the flats.

I rode to the fairgrounds, then did a u-turn and dropped in behind a group of people heading out, forcing myself not to pass them, to simply hang out and enjoy the ride..100 miles to go. I whistled Leave It To Beaver most of the day. The first climb after leaving town was up some dying road which reminded me of some of the worse parts of Morgan Territory road. Back down highway 32 to head towards Honey Run Road was fun..I passed lots of people while coasting. I carry spares of a lot of things on centuries mostly out of habit, because when I train, i tend to train alone, and I’m always trying to be sure I can make it home without having to call in a favor to get picked up in some remote part of the bay area. Carrying spares and some cytomax packets ( in case they run out..like adventure corps did in Death Valley Spring last year..nothing like riding into the last rest stop and finding out they only have coke and electrolyte tabs for your break ). All of the stuff I carry gives me a little more weight to pull up hills, but makes the downhills more fun! ;-).

Honey Run Road was humbling for some, I saw a joker riding a multi-gear that didn’t have a gear bigger than my fixed gear and was struggling up Honey Run. It was nice and cool going up Honey Run Road, and since I had my game plan I dropped to my climbing ring and just whistled my way up the hill. Looking at the views across the valley and the occasional view passing me .., “lots of purdy girls on this ride..might have to do this next year”

Arriving in Paradise I sent a note to Dad telling him I had reached the top of Honey Run, last time him and I rode up this hill I was 9 years old, he still twitches when we talk about it. I rolled into the first rest stop and had to deal with a few logistical things, water, food, bathroom, and I saw a few Diablo Cyclists in their jerseys standing around. I almost talked to them, I’d like to start riding their wednesday evening ride up Mt. Diablo with them but I’ve been too busy with things to really commit to that.

Most of the rest of the ride before lunch was characterized by “heat, climbing, heat, climbing”. Table Mountain was only nice when I realized I was the top, the climb wasn’t bad, but the heat sucked. There was a Ham sitting at the top assisting with communications for the ride, but he looked a little lost among all the cyclists and I was afraid if I started a radio conversation with him I’d be there two hours later.

It was a coast into lunch after that, then it was a coast into the farmlands, and from there it was sorta like before lunch except it was, “heat”, “wind”, “flats”, “heat”, “wind”, “flats”, I perservered and finished up the ride at just over 8 hours of riding time for the day and a little under 9 hours of total time for the ride. Total mileage was just over 103 miles.

The first time I did some work with PHPUnit I was writing out tests in preparation for some refactoring. So I put together a bunch of tests for my utility classes, and pure logic classes etc, database access classes, etc. So everything was trucking along wonderfully, things are falling into place and then I run a test that tests some database stuff.

The application was setup with a configuration file that defined all of the database connection information, this file is included by the database library providing a single set of database routines to be shared by the application. Pretty standard stuff here. Perhaps in a nod to the rails/java crowds it could have been put in a non-code file and read in by the application but as far as I’m concerned that’s just personal preference. At some point you’ve got to have some configuration information somewhere and this works as well as anything.

So now that you know how things were setup, we’re back to the PHPUnit test…it bombed, failed, crashed, whatever. After digging into it a bit I discovered that PHPUnit has a problem with munging the global namespace when it runs. Things that are global variables can’t be pulled down into local scope because they don’t exist there anymore. I did some reading and found numerous complaints about this in the PHPUnit bug system, all of them closed with “this issue resolved” when the issue most assuredly had not been solved. I even found a conversation where one of the developers stated that it was not a bug, that the user simply needed to modify their code to work with PHPUnit. Huh? Modify the architecture of your code to work with a testing framework?!?

I spent some time thinking about this and I think it could be said that he’s right, but for the wrong reasons. First off, if this is a technical limitation of PHP then just say so and let it go. If it’s an implementation problem with PHPUnit then say so and try to put together plans to fix it. However, I think in this particular instance the problems that I was experiencing with PHPUnit could indicate a larger problem in my application.

Here’s how..One of the things that I hated when I first started using PHP was having to pull things out of the global namespace into the local namespace to use them. When PHP5 came out and the object model finally had a good amount of maturity I moved to utilizing classes for most of my code and this allowed me to start using the $this operator for accessing a lot of variables that I needed to deal with. In fact, the only place I was really using globals was in my library routines. After thinking about this for a bit I realized that it was much more convenient to wrap all of the configuration data into Singleton then I’d have a single object that I could use to get all data instead of having to pull in everything I needed one variable at a time.

It was at that moment that I realized if I had a singleton that housed all of the configuration data I could instantiate it in all of the routines where I needed to access configuration data and it would avoid the problems that PHPUnit had with the global namespace. When I looked in the todo’s for the configuration file there was an item at the top “Maybe I should turn this into a singleton”…two birds with one stone? Ten minutes of work and I had everything setup and ran my tests and “bingo” everything worked.

So in the end, modifying the way that configuration information is disseminated throughout the system by using a singleton has been “the right thing”. I had some heartache over the responses from the PHPUnit developers about the “solution” to the problem their users were having mostly because the solution involved a lot of extra crap with addressing the global namespace in a particular way. Using a singleton ended up providing the needed functionality, didn’t do anything retarded with variable access, and ended up making the application much cleaner to work with.

One of the things that you notice if you are around development/engineering teams enough is that there is normally the existing solution, and the “next iteration”. Much has been written about the “second system” phenomenon and all of the pitfalls and failures that have resulted by second system thinking. Today I just want to talk about the importance of maintenance work to the growth of a developer towards understanding the hard problems within their chosen problem domain.

It seems like maintenance programming is, according to some developers, the lowest form of development on the planet. If you’ve ever been on a team in the role of maintenance programmer you have probably noticed that it’s not considered “sexy” by most of the team. Everyone is glad that you’re the designated maintenance programmer because that means that they AREN’T. Everyone wants to be working on the second system where “things are cleaner”, “we’re using better technology”, etc.

I’ve never agreed with this mentality, and here’s a dirty little secret, I LIKE maintenance work. There are few things as challenging as debugging a problem in a system you haven’t designed and fixing the problem in such a way that you leave the code better than it was when you got there. Here’s another amazing benefit of maintenance development, you learn the system and you learn how other people think and approach problems. In a similar way that Rorschach and Perceptive Aptitude Tests work, code is a projective tests for the thought processes of the developer who wrote the code. The other amazing benefit of supporting an existing application is that within a VERY SHORT amount of time supporting an existing application, a new developer is going to learn the system backwards and forwards. The developer will end up having a very deep understanding of the problems inherent in the existing design from a very realistic standpoint.

See new development is easy, you’re just trying to hit the 80% mark. If you’re in development you know what I’m referring to. “80% of the functionality is solved by 20% of the work.”. I’m willing to argue that the real work involved in a new application is done after the application is in production, that’s when you start to work on the last 20% of the application.

Maintenance work ( debugging production problems, adding new features, etc ) is when you start to solve the really hard problems that were not seen, or deferred, by the team creating the application. You often have to be creative in how you quantify the problems you are seeing, and you have to be a bit of an artist in terms of how best to quickly and easily ascertain what the hell is going on. The great part though is that you start to see how the choices made during the implementation of the system impact your ability to respond to certain things. This is the reason that I think solution architects should be in the trenches writing code with everyone else. They need to understand the results of their decisions at a very fundamental level, and the only way to do that is to keep their head in the game.

The other great thing about doing maintenance development is how easy it is to measure your contributions to the team. It normally goes like this, Tuesday morning the big client calls, he has found a bug that needs to be resolved by Friday or else they are going to have to leave the team. Tuesday, just before lunch, a meeting is called, and bad pizza is ordered. You are brought into the meeting and asked how in the world this can be fixed before Friday. If you just built the application but haven’t spent time doing maintenance since it’s release, you’re going to have to look into the application and reacquaint yourself with how it works, and see what new things have been added since you last saw the code. However, if you’ve been doing the maintenance work you can speak with authority right there in that meeting about what it is going to take to deal with that issue, and with any luck it’s already something that you have thought needed to be dealt with and have an idea about the best approach to take. So you grab two extra cokes and the last box of pizza and go back to your desk and solve the problem, test it, get it through qa and into production. A specific measurable result for your efforts, and something that others will remember.

Obviously I love to do maintenance work, I am VERY often called by clients to deal with legacy situations. I can’t count the number of times that I have had a client call up and tell me that the only person who knows anything about the application has left and “they have a huge bug and he’s trying to charge them $400 / hr to deal with it”, or they “have fired their consultant and are now left with a huge mess on their hands and could you help us”. I love this work, it’s real, it’s necessary and it’s often challenging and interesting. If you need maintenance work done feel free to contact me, I’m always looking for chances to sharpen my debugging, and code-reading skills.