ClearMyRecord, a retrospective

So, I’m leaving ClearMyRecord and going to OmniTI. A few words are in order in parting.

First of all, why I came to CMR in the first place. ClearMyRecord is all about restoring dignity to people who have lost it, through their own mistakes. This is an honorable goal, and being part of creating the technology to achieve that goal was very appealing to me. And, while I was here, we did indeed help a lot of people obtain expungement of their criminal records, which is a ticket back to participation in community at a level that had been denied to them.

This has been my first real experience with management. I was a manager, sort of, at one former job, but treated it more like a team lead than a manager, and that experience didn’t go well. The less said about that, the better.

However, my management still is still very delegatory, if that’s a word. I assign tasks to folks that I feel can do them, and then I step back and allow them to be creative in how they do them. The side-effect of this, of course, is that sometimes things don’t get done, get done in ways that I didn’t envision, or get done far slower than I had hoped.

About halfway through my time here, I hired someone with far more management experience than myself. I suspect that he frequently didn’t agree with how I chose to operate, and sometimes he made that explicit. I learned a great deal from him, and I think that I will do things rather differently if I have an opportunity to be in management again. Now that I’m leaving, he’ll be taking my place, and the rest of the team will get to see how he chooses to manage. I’m very interested to hear more about this in the coming weeks.

As to what I would like to have done differently – I think that greater focus on the goals and specific deliverables would have resulted in meeting those goals earlier – months earlier in many cases. We had the tendency, as a team, to be pulled in dozens of different directions at once, and spend weeks at a time working on stuff that was completely outside of our core goals. Granted, this was often mandated from upstream, but I strongly suspect that I could have managed this better if I had been more forceful.

So, now I’m going back to a more hands-on position, where I can revive my Perl knowledge, as well as taking advantage of my 5 years of PHP experience, and my 15 years of Apache experience. Pretty exciting, all around. And maybe, just maybe, I’ll get to try my hand at management again at some point in the future. Meanwhile, I’m looking forward to working with my new manager, who, while younger than I, is someone that I have had some contact with over the last few years, and greatly respect.

Unit testing: A good habit, lost

When I was a Perl programmer, I was a strong believer in testing. I wrote tests before I wrote functions. I wrote tests before I fixed bugs. I ran the test suite every time before I committed changes to svn. I ran tests after I ran svn update.

When I became a PHP programmer, I quickly slipped out of the habit. There were two reasons for this.

First, my style of programming changed pretty drastically, with the move to being completely web-centric, and web front-end code is just harder to test.

Two, at that time, the available tools for unit testing were immature. Or, at least, so I believed, coming from the Perl world where testing is not considered optional, and is integrated into every aspect of the process, from design all the way up to ridiculing stuff that’s submitted to CPAN without adequate tests.

Now that I’ve been doing PHP programming for going on 5 years, I desperately want to get back into a testing mindset, but find that there’s an awful lot of inertia around not testing. If your code doesn’t have a test suite, it’s difficult to make that first leap to build one. And it’s also hard to convince management that it’s worthwhile spending time making a test suite when you’re behind deadlines.

And, since there’s not One True Way in PHP, like there is in Perl, you waste a lot of time and energy trying to find the right testing methodology. The PHP community could do themselves, and the rest of the world, a great service, by agreeing on one testing methodology, and then evangelizing it. Here’s another case where the quest for the best has woefully injured everyone, and led to a situation where people simply don’t test.

Now, I’m sure that the core PHP folks will disagree with me. Actually, I kind of hope that they will. Please disagree with me? Tell me that there is One True Way, and also that you do run the test suite every time you change a line of code. I greatly regret getting out of that habit.

OmniTI


It is with unmingled delight that I am now able to announce my new gig. Starting on August 24th, I will be working for OmniTI.

I’ve been aware of OmniTI for almost as long as it has been in operation, because I have known Theo roughly that long, and have been attending his Scalable Internet Architectures presentation on and off for almost ten years. Every time I attend that talk, I think, well, this is cool stuff, but I’ll never work on anything that gets more than a few thousand visitors a day,

So I’ve been admiring OmniTI from afar for a long time, wishing that I could work for them, or, failing that, some place where my knowledge of scalability could be something more than a vague theory, never put into practice.

For reasons beyond the scope of this blog, however, I am unwilling to move out of the Lexington, Kentucky area. This life decision closes many opportunities to me, but it’s a choice that I continue to make willingly.

Anyways, some time in the middle of July, when Chris blogged about leaving OmniTI, I was poking around the website and saw that I might just be qualified for some of the positions they were offering, and, on a whim, emailed Theo to ask if they’d be willing to hire me, and let me stay home. Turns out, they were willing, and that’s what I’m going to do.

My offices just keep getting better over the last few years. 🙂

Exactly what I’ll be doing, I’m not yet entirely certain. But it will be a mixture of Perl and PHP, as well as being able to utilize my Apache HTTPD expertise more than I’ve ever done before, which is very exciting all by itself. I’ll be working with some of the smartest people I know, as well as a lot of smart people that I don’t yet know. And I’ll have the most fabulous office I could ask for, overlooking the swimming pool. My biggest concern is that I’ll have trouble staying focused, but I expect that I’ll develop strategies for that pretty quickly.

As to why I’ve waited so long to mention this – after all, I’ve known about it for close to two weeks – we had a deadline, of the crisis variety, at work. The deadline was Friday August 14th, and it was determined by various people that it would be unkind to the rest of the team to announce my departure while we were working so hard to meet that deadline. I’ve been brimming with excitement and a desire to tell the world, but saw the logic in the request.

It’s been a great year and a half at ClearMyRecord.com. I’m leaving the team in very capable hands, and wish them all much success. I had the privilege of working with a very talented team here, and would be glad to work with them again.

Oh, and I should also take this moment to thank Andy. Whether or not you’re looking for a job, if you’re in the IT business – and probably even if you’re not – you should read Andy’s website. His advice is sensible, practical, and indispensable.

Ice Cream Scoops

As I’ve mentioned before, whoever is handling the ad campaign for the UNCF isn’t doing their research. In a new ad, they state that Alfred Cralle invented the ice cream scoop.

Which he did, but the picture shows a simple spoon-style ice cream scoop, rather than the variety that Cralle invented. What he invented was far cooler – a scoop with gears and lever which scoops the ice cream out of the bowl of the spoon.

So that’s another ad that they’re running where they claim that an african-american inventor invented something, when in fact he invented something much cooler. Why would they do this? Come on, folks, do your research a little better. Or, UNCF, get a better ad agency.

Swimming Pool

We finally have a swimming pool. It’s been a long and frustrating saga.

Last Friday evening, after the kids went to bed, we rolled out the pool, which had been delivered by UPS on Thursday. We followed the instructions (most of them) and started filling it with water.

Turns out, that bit about “level ground” was pretty important, as I should have known, since I was a physics minor in college. About 1000 gallons later, we had a pool with about two feet in one end, and maybe 6 inches in the other end, tilting precariously. We knew this wasn’t going to work, but decided to let the kids play in it before starting over.

Saturday morning, they came out and were tickled pink, which was the desired effect, but after about 2 hours of playing, the edge finally dipped, and all that water went thundering down the hill, washing away our gravel path and generally wreaking havoc.

Being impatient, we went for the quick fix, and bought a bunch of sand bags to prop up the bottom end. As the water reached the top of the sand wall, it dragged the side over to the other side of the wall, and there it lay, until finally we couldn’t prop it up any more, and we lost another flood down the hill.

Now ready to follow the instructions, we started digging, and have been digging all week, a few hours a day, until about 8 last night when we deemed it done. In retrospect, we should have taken a few more steps to smooth the ground, but we decided it was good enough, and by about 11 last night, we had a serviceable pool. It still needs to fill a little bit, but it’s level now, and ready for the screaming kids.

Unfortunately, neither of the kids are with us this weekend. But at least we can enjoy a little time in the pool now, and try to recover from our aches from a week of digging.

Take back the beep

Dear Mr. Siegel,

I believe it was 1982 when we got our first answering machine. We had a recording on it that said something like “at the beep, please leave your message.”

So, 27 years ago.

On my cell phone, I have a message. I say something like “I can’t answer your call, please leave a message.” But even that is unnecessary. Folks know what to do.

Unfortunately, after that message, there’s another message, in a stranger’s voice, telling the caller to … leave a message after the beep. I already told them, and they already knew before that.

If I were cynical, I would think that the sole reason for this additional message is so that the cell phone company can bill me for that additional 15 seconds of non-information. Ok, I admit it, I’m cynical. This is a cheap way to run up my phone bill, in exchange for no services rendered.

I understand that you’re one of the folks that can do something about this. Is that right? David Pogue told me about his grass-roots effort, on Twitter, and then directed me to this write-up: http://www.nytimes.com/indexes/2009/07/30/technology/circuitsemail/index.html?8cir&emc=cir

Anyways, please drop the message. Nobody needs it. Nobody wants it. And I don’t want to hear that every time I call my wife to leave a quick message. It’s silly, unnecessary, and nobody believes that it’s there for our benefit.

Thanks.

[DPI]

The Apache Web Server version 2.2.12 released today, including the following nugget of joy:

‘discardpathinfo|DPI’ (discard PATH_INFO)

In per-directory context, the URI each RewriteRule compares against is the concatenation of the current values of the URI and PATH_INFO.

The current URI can be the initial URI as requested by the client, the result of a previous round of mod_rewrite processing, or the result of a prior rule in the current round of mod_rewrite processing.

In contrast, the PATH_INFO that is appended to the URI before each rule reflects only the value of PATH_INFO before this round of mod_rewrite processing. As a consequence, if large portions of the URI are matched and copied into a substitution in multiple RewriteRule directives, without regard for which parts of the URI came from the current PATH_INFO, the final URI may have multiple copies of PATH_INFO appended to it.

Use this flag on any substitution where the PATH_INFO that resulted from the previous mapping of this request to the filesystem is not of interest. This flag permanently forgets the PATH_INFO established before this round of mod_rewrite processing began. PATH_INFO will not be recalculated until the current round of mod_rewrite processing completes. Subsequent rules during this round of processing will see only the direct result of substitutions, without any PATH_INFO appended.

It might also be handy, some day, to have a [DQS] flag that discards the query string explicitly, rather than having to do silly tricks to make it disappear.

httpd.conf – the Apache Web Server conference

The Apache Software Foundation and the Apache Conference Committee are delighted to announce httpd.conf – the mini-conference focusing on the Apache Web Server, embedded into the larger ApacheCon conference.

httpd.conf consists of two days of talks focused on the Apache Web Server, as well as two days of pre-conference training classes.

On Monday, November 2, and Tuesday, November 3, JimJag and I will be teaching a two-day training class on the Apache Web Server for the beginner who wants to get up to speed on how to run the server.

On Wednesday, you can take a look around you at some of the other Apache technologies.

Then, on Thursday and Friday, there’s a full day of httpd talks. Thursday is primarily focused on the administrator, while Friday is focused mainly on the developer.

And, of course, there’s also a full schedule of other ApacheCon events and talks, including the 10th anniversary party for the Apache Software Foundation. So make plans to come to Oakland in November.

The Margin Is Too Narrow