Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

geoff (2013)

  {geoff} {at} {}

see [] for personal information, links to presentations, GPG key, and so on.

Journal of geoff (2013)

Tuesday June 09, 2009
12:38 PM

still kicking after 7 years...

apparently, the mod_perl cookbook appears in the new Cracker video. thanks to perigrin for the discovery.
Monday May 05, 2008
07:54 AM

please don't re-spam me

have email administrators not figured out yet that sending the From address "the mail you sent was spam" mails just doubles the amount of spam traffic? everyone knows the From address probably didn't originate the mail, right? have we learned nothing over the past, what, 9 years?
Friday December 21, 2007
09:22 AM

"it's just..."

I was in a meeting yesterday where a seasoned but non-technical person was surprised that the project at hand involved a substantial amount of re-coding. "I thought it was just..." the sentence began, which then continued (in my mind) as "completely re-thinking $concept and normalizing $concept data across 38 new tables instead of the current 5" but sounded like "switching around a few tables" to everyone else.

I've worked with lots of non-technical folks over the years, some good, many bad, and this person is one of the good ones, so I found it amusing rather than irksome. but, for the record...

there is no such thing as "it's just..." in software engineering anymore. at least not for mature applications with an established userbase where real money is involved.
Friday September 28, 2007
10:07 AM

on garbled profiles

anyone who has used dprofpp has seen entries like this:

Garbled profile, missing an enter time stamp at /usr/bin/dprofpp line 785, <fh> line 144174.


Modification of non-creatable array value attempted, subscript -1 at /usr/bin/dprofpp line 679, <fh> line 142590

ungarbling a profile is a lesson in patience and rote: you go down to the line in question, figure out what sub it's talking about (the number at that line), go to the top of the file, grep for that number, find the subroutine it's talking about, add that sub to your ignore list, lather, rinse, repeat until the problems go away.


while overloaded subroutines are notorious for this behavior, they are easy to weed out via a simple code scan. but once you remove the low-hanging fruit, it's a chore to ungarble a profile if your codebase is anything more than something very simple. and, for some reason, it always seems to boil down to DBI-based calls once I get to the bottom of things.

well, this morning I decided enough was enough, I'm going to figure this out.I generally don't care about specific, low-level DBI-ish things - the amount of time (and number of calls) to fetch() is much more important to see than what DBI is doing under the hood in that mire of package madness. so, using a lot of verbose Devel::Profiler tracing and some moxy, I was able to add these packages to by bad_pkgs entry:


which hides low-level DBI calls from the profiler but not those from specific drivers (which contain enough of the database overhead to be interesting). so, with my profiling back in order, I can see all the stuff I'm interested in, including entries like

  1.31   0.293  0.293   2365   0.0001 0.0001  DBD::mysql::st::execute
  1.02   0.229  0.229   4942   0.0000 0.0000  DBD::mysql::st::fetch

anyway, I hope this helps some of you out there. happy profiling :)

Thursday June 21, 2007
10:36 AM


after sitting in my /devel directory for a while, I finally released Devel::Profiler::Plugins::Template to CPAN yesterday.
Wednesday December 13, 2006
08:58 AM

making DBI writes no-ops

one of our databases consists of mysql myisam tables, which don't have transactions so you can't rollback. this makes debugging and 'dry-run' modes very difficult. one of my coworkers suggested DBD::NullP but that doesn't quite fit the bill - I want to pull data, inspect it, but no commit changes...

what I really need is some DBD driver that intercepts write statements (UPDATE, REPLACE, etc) and turns them in to no-ops. DBD::Proxy and/or DBD::ProxyServer seems to almost get me there, but I don't feel like I should have to go through a complex acl-style process for all my code - I should be able to swap out the driver and it should all just work. so, has anyone done anything like this? I'm contemplating writing something like DBD::NullWrites, which should be relatively simple once I get my head around the DBD API. and after figuring out whether I can make it generic to apply to any read-front-end (DBD::Oracle for reads, DBD::NullWrites for writes, etc). pointers from folks who have ventured into DBD:: space appreciated :)
Tuesday July 11, 2006
10:52 AM

on hope...

for those of us that can't figure ourselves out quite yet there might be hope
Thursday July 06, 2006
01:00 PM

you can find anything

so I'm working on my oscon slides, which this time involve quite a few screenshots. unfortunately, it seems that print screen doesn't capture the cursor, so I need to gimp-in my firefox hand if I want to illustrate clicking on a link. fine... if I can find the hand image on my filesystem.

then I come across this gem. the internet is great.
Thursday June 08, 2006
10:20 AM

"did you test that?"

I've decided that I'm going to start a new trend. I will no longer answer "yes" when someone asks "did you test it?" unless I can point to unit tests. instead, my response will be "I poked it and it seemed to work, but it doesn't have tests."

if we all start doing that maybe people will start to understand that tests you can point to count for a lot, while a few mouse clicks really don't.

feel free to join me :)
Saturday April 22, 2006
10:17 AM

API overkill

although I'm probably the last person on the internet to do so, the other day I started cross-posting my personal photos to flickr. of course, didn't want to do anything by hand, so I went off to CPAN looking for an API. there were a few to choose from, but Flickr::Upload caught my attention as being somewhat simple... but the process that followed was anything but - register for an API key from flickr, figure out this auth key thingy (which I still haven't), the download a slurry of dependencies (which included an Acme:: module, and which ended when I saw wanted to install SOAP::Lite). all this just to upload a picture every once in a while? granted, I'm sure the full API offers much, much more, but for my immediate needs, no thanks.

so, a bit of wandering through flickr showed they have an email upload option. so MIME::Lite, 10 lines of code, and 5 minutes later and I'm uploading photos. sometimes you need an uber API, and sometimes you don't...

so, will I start to receive photo spam as spammers hit random email addresses and stumble upon my upload address? hmm...