use Perl

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?

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.

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.

or

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.

ugh

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:

  DBD::_::st
  DBD::_::db
  DBD::st
  DBD::db
  DBI::st
  DBI::db
  DBI::dr)

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 :)

after sitting in my /devel directory for a while, I finally released Devel::Profiler::Plugins::Template to CPAN yesterday.

http://search.cpan.org/dist/Devel-Profiler-Plugins-Template/

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 :)

for those of us that can't figure ourselves out quite yet there might be hope

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.

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 :)

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 CPAN.pm 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 @flickr.com email addresses and stumble upon my upload address? hmm...

it's been a while since I've used POE, but lately I've been reminded of this bit from it's documentation, which I think about constantly for some reason

POE is event driven. Wait. What does that mean? To draw a somewhat relevant analogy... For most geeks, life is event driven. Most of the day is spent waiting for something interesting to happen.

Ponder a friday evening. We're talking about a geek here so not much is going on. Just bad american tv. (is there any other kind of american tv?) Delivery Pizza arrives. This causes the geek to scramble for cash, pay the delivery man, and then hungrily devour pizza. When the pizza is gone, the geek resumes watching tv.

The arrival of the pizza is an event. This causes a Pizza Arrival state, the collection of actions including paying for the pizza and eating it. When the Pizza Arrival state ends, the geek goes back to a passive wait state, waiting for the next event in his/her life.

while I'm a fairly proactive coder, choosing to fill my idle times with yet more constructive coding, the past few weeks have felt remarkably event driven... in a bad way.