kentcowgill.org/blog

I just had the opportunity to learn two very important lessons in the ownership of an older home.

1. No matter how well you think you know how a circuit is laid out, you're almost certainly wrong.
2. So long as you have decent balance, getting zapped with house current at the top of a ladder won't actually kill you.

In retrospect, thinking that the entire garage's power was switched off with the solitary switch by the door was completely ridiculous. How else would the garage door opener work?

Naturally, the corollary is:
* Always locate and shut off a circuit before manhandling the wires connected to it.

This one is even later. I guess it just goes to show you that I've been a little busy :)

One thing I forgot to mention: Monday night was the BBQ BoF - a disjointed group of 50 or so of us took separate rides to Goode's BBQ. A few of the disjointed travelers wound up at either Goode's Seafood, Goode's Taquieria, or Goode's Coral - they were separate buildings within a few blocks of each other, and I guess some of us (well, them, really) weren't so good at reading the address indicators on the street signs.

Tuesday was a good day. I attended Cathartic Catalytic Conversion in the morning, and then went to Abigail's Perl 5.10 regular expressions talk. Wow. There's some really cool stuff coming in the next Perl5 release.

I skipped the next section where my choices were the first part of the Perl 6 update, a web framework called Gantry (or Bigtop?), and Perl Logging Practices. I've seen the Logging practices talk locally in Chicago, a new web framework didn't really interest me, and I really wanted to see Luke Closs' Agile Testing with Selenium, which gave me a lot better idea of how to go about using selenium.

Next was Perrin Harkins' Care and Feeding of Large Web Applications. I stayed in that room for a talk I was interested in - Casey West's MochiKit: Good Tools for the Web Developer. Unfortunately, about 15 minutes into the talk, I got an IM from work and had to help out an issue remotely. Which pretty much took my time for the rest of the day, keeping me from seeing any more talks. But that was OK, because there weren't any talks competing for my attention.

The official evening was capped off by the YAPC Dinner and TPF Auction - but after that, a few of us got together for the Beers of the World BoF. We first gathered in the basement "common room" of Oberholtzer Hall, but we got busted by the RA's - no drinking in common areas. So the 40 or so of us that were there crammed into one dorm suite. Very crowded, and I think I'm still amazed that we didn't encounter further resistance to our 'partying' efforts from the university staff.

So, it's a little late, but here it is anyhow.

Yesterday was not only my birthday, but it was also the first day of YAPC::NA 2007 in Houston.

The day got off to a nice start with a really good talk by cog, AKA JoséCastro about how to get the most out of a YAPC. Not much was news to me, but there were a bunch of first-timers in the audience, so it was well received.

Then a traditional keynote by Larry, a morale building talk by Richard Dice, and lunch.

After lunch, I went to Approximation Algorithms in Perl by Walt Mankowski. It was nice overview of coming up with approximate solutions to N-complete problems - travelling salesman, bin packing - unfortunately it was a little short.

After that, I stuck around for Making an AjAX GUI for GNU Screen - which was really pretty cool - essentially running a mini local HTTP server to build an AJAX-ified front end for finding out which of your 10+ screen sessions has what you're looking for.

After the small break, I went to Updating Your Testing Toolbox which covered a few tools that I already make use of - FireBug (ok, really it's just one, but it has so many different useful components) - and introduced a few that I had heard of, but not gotten around to using, like selenium. I'm going to give it a shot - I've already downloaded it and played around with the IDE, but this really seems like it's going to be a great way to do some functional testing of the websites I work on.

Finally I attended Abuse Perl which showed a few ways to inject your code into code that you're trying to debug without touching the original code.

Monday night was Game Night and we had a great time playing pool, air hockey, and all sorts of video games.

All in all, a pretty good time.

So, I'm sitting here in the lobby for one of the dorms at the University of Houston.

I arrived around 1:30pm or so, got my luggage, arranged for a shuttle, but had no idea of the address. So I had to find the University of Houston on a map to try to figure out an address to tell the shuttle company.

Finally arrived on campus, but the shuttle van just dropped me off by the front of the University. Oh, and it was raining.

Wandered around a bit, got my bearing, checked a campus map or two, found the building I'm supposed to check in at, checked in, get to my cell - wait, I mean drom room - unpack, and then I'm bored.

No ethernet cable, so I figured I'd go back to the main lobby of the other dorm building, and meet R. Geoffrey Avery.

Not much else to do since there's just the two of us, and he's busy downloading Apple's Developer Tools.

So, I'm officially an old codger now.

I busted a bunch of kids a few nights ago for hanging out way after curfew, way after the park was closed, and sounding like they were causing trouble.

It started simply enough - I was walking Spike at the end of the night. I got in late after the Perl Mongers meeting, so I was out at around 1:00am - right as the timed park lights shut off. I get to the park, I see a few kids walking towards me. Sorta. Seeing kids at night generally puts me a bit on the defensive - who knows what kind of dumb things get into kids' heads at night, so I proceeded cautiously until I saw that they weren't walking directly towards me any more. They were walking toward the now very poorly lit playground.

Spike does his business, I get busy bagging it. All the sudden I hear something behind me - it's a third kid. As I stand up and turn around, I realize he's just shuffling his way towards the same poorly lit playground. Ugh. I guess I was young once, so I understand.

However, at this point I no longer feel like it's a good idea to walk around the far side of the park, since I now know there are at least three kids most likely up to no good. So I turn back, walking slowly, making sure Spike has everything out of his system that he needs to get out. I keep an eye towards the playground, just in case anyone comes charging towards me. I see a few more than three silhouettes.

Then I hear noises which make me think someone has decided to empty the garbage cans by the playground and generally start vandalizing the playground. My mind is made up - I'm calling the cops. I have enough of a problem as it is walking Spike around the park because there tends to be broken bottles on the sidewalks. Not a big deal for me with my shoes, but poor Spike has no such protection.

I decided to test the timeliness of the cops' response - turns out it was pretty good. I decided I'd just walk back and forth on the far side of the park, but across the street. Not more than 5-7 minutes and I see the comforting blue and white cruising slowly past the park. They turn on the search light. Once the cops zeroed in on where the kids were all laying down (by now, they were trying to hide), they started to run. There must have been at least 15.

They made a beeline for the houses under construction across the street - the police tried to speed around the side of the park I was standing on to try to intercept the kids. Also I noticed another patrol car gunning it up the alley behind the houses the kids ran towards. A few minutes pass, the cops couldn't find them, but I watched them slowly walk out of the alley the cop car had zoomed up - they must have been hiding pretty good and let the alley cop pass them. I watched where they went. I was about to head home when the patrol car came by again, this time with his lights off. Good strategy, but it didn't pay off for him. I was going to flag him down to tell him which way they ran, but he turned up that street anyhow.

Again I started walking towards home, but then the cop made another pass. This time, determined to get some of those little stinkers in trouble, I flagged the cop down and told them where they went. I think he determined they had already completely dispersed, so he pulled away in the other direction.

No sooner than the cop is 15-20 feet away from me, and one of the little stinkers hurled a rock at me.

A rock.

A ROCK.

AT ME.

I heard it tear through some leaves, heard it bounce on the ground.

"OFFICER!"

He executes a quick 3 point turn, guns it towards me, stops long enough to hear me report the attempted assault, and he takes off after 'em.

VERY NEARLY A BOULDER.

At this point, I've had enough. It's 1:30am, the cop can't be watching everything, and the kids might come down another street and attempt to inflict more damage to me for calling the cops on them.

I walked back to my house, keeping an eye behind me, down the side streets, down the alley. I'm pretty sure they couldn't have been around to watch me go into my house. After all, they seemed to live in the other direction, and they have to worry about being spotted by a cop.

So what does this mean?

I might as well sit on my porch and yell at kids to get off my lawn and turn down the music.

Oh. I've already yelled out the door at people in cars with their music too loud.

:(

I've been tasked with setting up new QA and staging environments at work.

With a twist.

We have several teams working on several sections of our main website. One team migrates code from development to production on a regular basis. I believe I have mentioned this before. In case I haven't, they push files several times an hour. I honestly think they use the production cluster as their QA environment, but that's the subject of another rant.

Also, we are making fairly large changes to our backend. The front-end changes for the backend changes are to initially be carried out on this new QA server.

Do you see the problem?

While developer A makes changes on QA, they don't get reflected on dev, staging, or production.

Developer B makes changes on dev, and they go straight to production. QA and staging fall out of sync.

Hence the suboptimal code migration path:

Life would be much better if we just started using version control. :(

I was working on some code the other day and ran across this little gem. Granted, I've simplified (and removed any proprietary information from) all the expressions, because they're much more verbose than this. But I was pretty incredulous when I saw it, considering I was supposed to modify it to change its functionality. The formatting is about the same, though, but the linebreaks might be in slightly different spots. The important bit is that it was actually much more unreadable than this. The formats actually came from object variables (i.e. $obj->var->{DIRECT_HASH_ACCESS} - other than the one hard coded near the beginning) which helped to clutter everything up, and the %hash keys (and name) were much longer. I also wanted to make it fit in the page without making it expand too wide :)

push @arr, sprintf( q(<div long format string >%s</div>),
     join( '|', map { sprintf ( $_ eq $i ?  'formatA' :
     'formatB', $variable ? $_ : ( $uri !~ /regex/) ?
     join ( '/', 'something', $_ ) : join ( '/',
     'something/else', $_), $hash{$_}) } ( sort {
     $hash{$a} cmp $hash{$b} } ( keys %hash )) ));

If I ever come across the person who wrote this and left it as is, jumbled together and uncommented, I will punch them squarely in the face.

First, the lack of formatting makes it impossible to read. And there are superfluous parenthesis that help to clutter things up.

Then there's the superfluous use of the joins stuck in the middle. The joins don't do anything - I thought at first they might help avoid a "Use of uninitialized value in a concatenation" warning, but that can't happen if you're iterating over the keys of a %hash.

There also seems to be at least one of the ternaries I can avoid by doing a little work up front - it doesn't vary based on which %hash is currently being iterated over.

If you take care of those four things, it helps a bit, but overall it's still not all that great.

my $path = 'something';
if( $uri =~ /regex/ ){
  $path .= '/else';
}
push @arr,
     sprintf
       q(<div long format string >%s</div>),
       join '|',
            map { sprintf $_ eq $i ? 'formatA'
                                   : 'formatB',
                          $variable ? $_
                                    : "$path/$_",
                          $hash{$_}
                }
            sort { $hash{$a} cmp $hash{$b} }
            keys %hash;

I'm still not happy about the push sprintf join map sprintf ?: ?: sort keys %hash structure, and will probably end up breaking it into more readable chunks later. But at least now it's a little easier to follow - and most important, modify.

time passes

So I was able (according to the requirements) to rip out the differing functionality for various states, and as such was able to pull the ternaries out altogether.

my $path = 'something';
if( $uri =~ /regex/ ){
  $path .= '/else';
}
push @arr,
     sprintf
       q(<div long format string >%s</div>),
       join '|',
            map { sprintf 'formatB',
                          "$path/$_",
                          $hash{$_}
                }
            sort { $hash{$a} cmp $hash{$b} }
            keys %hash;

I think, through trial and error, I have stumbled on the recipe for what I consider to be an extremely delicious cheeseburger.

The ingredients are pretty consistent, but the measurements are at best approximations. This recipe is enough for two burgers.

• 1/2 lb. Ground Sirloin
• 2-3 tbs Sweet Baby Ray's Hickory and Brown Sugar Barbeque sauce
• 1-2 tbs Worcestershire sauce
• 1 tbs Onion powder
• 1/2 tbs Garlic powder
• 1 ts Paprika
• 1/2 ts Ground pepper
• 1/4 ts Ground Sea Salt
• 1-2 Handfuls of Hickory Chips

Optional (but highly recommended if you can stand hot stuff):

• 1 ts Dave's Gourmet Insanity Sauce

Get a hot fire going on a grill - gas, charcoal, or other. Soak the hickory chips (or don't - I don't, and they tend to flare up, adding an intensity to the smoke later on).

Meanwhile, mix together the barbeque sauce, worcestershire sauce, onion and garlic powders, optional insanity sauce, and the rest of the dry ingredients.

When combined, add the ground sirloin and mix either with your hands or a wooden spoon until well combined. Form into 2 patties, dousing with additional worcestershire and barbeque sauce.

Throw the chips into the grill and make sure they start to smoke or catch fire.

Have some buns handy, and put those on a top rack while you grill the burgers to your desired doneness.

When the burgers are nearly done on the second side, put some provolone cheese on them to melt. The buns are well browned by this point, so take those off.

I really recommend the following condiments: a thin layer of Grey Poupon mustard on the bottom bun, and a little mayonaise on the top bun.

When the cheese has melted and the burgers are done, transfer them immediately to the buns and serve.

I've gradually settled on this recipe, and can't get enough of these things. Delicious, juicy, spicy, and a unique combination of mild and not-so-mild flavors all enhanced by hickory smoke from the grill. Plus, the rest of the day you get to smell like a campfire, and that alone is worth it for the memories the hickory smoke can evoke :)

Another mini work-related rant. The names, projects, and task names have been changed to protect the innocent.

phb: "Please work on project X, which incorporates tasks Y and Z."

me: "Hey, how about we split those up into two separate projects? Z is pretty straightforward, Y will take some doing. Y and Z aren't really related other than the fact that they show up on the same web page."

phb: "No, as long as task Y doesn't take more than a few days, please do them together."

me: "So, what datasource do you want for those Y items?"

phb: "Oh, just pick the most recent Y items per category."

a few days pass, where I do the lions share of tasks Y and Z

phb: "Oh, by the way, some categories don't get new Y items very often - we want to have the one that gets displayed change more often. Can you build in some capability to do that?"

me: "Hrm, nothing in the database lets me select different Y's based on date updated or anything. I'll have to change the database, and the module that interacts with the database, as well as the internal application system that produces all these things..."

phb: "So, we've thought about it, and let's cancel task Y out of this project."

me: "You're kidding, right? I've already done Y and Z, and let me tell you - I put in a lot of effort into figuring out Y, but making it so that Y and Z show up when a user logs in, and have the old look when a user isn't logged in, that was tough. Not to mention that not even part of Z can be used (again which I've already done), since if you remove Y, that part of Z is now worthless, too."

It started out simply enough: implement a new design which pulls in new datapoints. In figuring out where the datapoints come from, the initial guess was wrong, which was to use the most recent data items for each category. It seemed likely enough, but once the business owner was asked about the source of the data, it turns out that guess was wrong - he wanted to be able to dynamically choose which datapoint was displayed per category.

Normally, this isn't a problem - in fact, that's what web developers do all the time. However, this project was for modification of a legacy application, which in a rather complex way, displays one of these datapoints dynamically - but without being from a specific category. In order to accomodate the new request, a lot of the backend of this system would have to be changed - the database, the perl modules, the content management system, the XML files.

And of course task Z is under intense deadline pressure.

Let this be a lesson to make sure all the requirements have been at least thought about before beginning a task.

Or perhaps, if a developer notes that tasks should be separated, he probably knows what he's talking about.

So I don't have much other excuse for this than to test out a few more capabilities of Text::Textile, my RSS feed, and I guess my vim wrapper for posting entries to my blog.

Spike and I were walking in the park last night, as we normally do, and again we saw a rabbit. They weren't twitterpated . In fact, there was just one. But I noticed he was fairly bold, and didn't seem to run away as easily.

In fact, the rabbit didn't seem to want to move at all. So it was fortuitous that I happened to have my cameraphone with me. Granted, I take it with me on every walk, just in case. But I thought it would be a good time to test how the "zoom" feature on my cameraphone actually worked. Also, it seemed in my viewfinder that I could hardly tell that the brown lump in the middle of the frame was supposed to be a rabbit.

Short story, it doesn't.

It more or less just "crops" an image. Same resolution, just smaller dimensions.

I was pretty disappointed.

The good news is that I can add images to blog posts fairly easily, and the formatting allowed by Text::Textile seems to be close enough to what it purports it ought to do. Also, the images show through just fine in my newsreader of choice, so anyone reading this via the RSS feed ought to see the fluffy bunnies just fine.

Also, turns out my vim blog post wrapper doesn't mangle intended Textile formatting, at least for images. Woo!