Stories
Slash Boxes
Comments
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 ]

jjohn (22)

jjohn
  (email not shown publicly)
http://taskboy.com/
AOL IM: taskboy3000 (Add Buddy, Send Message)

Perl hack/Linux buff/OSS junkie.

Journal of jjohn (22)

Monday January 20, 2003
08:34 PM

Resume writing tips

[ #10090 ]

One of my clients has me looking a fairly complex mod_perl application that has several dozen modules arranged to varying degrees in object heirarchies. There are several examples of empty subclasses that exist to as aliases for their parents. There are very nice examples of method overriding whose purpose isn't entirely until the parent class is examined. Of course being a mod_perl app, one can't fire up the debugger and trace a live program's execution. Still, I think I've done pretty well at understanding this byzantine code.

Can I list the following skill on my résumé:

can stick his head up the ass of any perl code base

I think so.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Apache::DB is your very good friend when you've got a mod_perl app that's too entangled with the workings of Apache to be debugged separately.

    Personally I'm rather keen on moving application logic out into a separately testable and runnable layer that doesn't make mod_perl assumptions, but time pressure often stops that happening in real life...
    • I have heard of Apache::DB and I really do need to look at it more carefully. The application in question is a framework (never easy to debug anyway). Let me do my homework on Apache::DB and see if it can help in a situation as difficult as this.