Tuesday June 09, 2009
still kicking after 7 years...
Monday May 05, 2008
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
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
on garbled profiles
anyone who has used
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
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
Wednesday December 13, 2006
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
Thursday July 06, 2006
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
"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
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...