Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Let the experts do their jobs, or, A Lesson Learned, or, the CPAN coulda saved by butt

by Hero Zzyzzx (Curate)
on Dec 01, 2001 at 02:06 UTC ( #128767=perlmeditation: print w/ replies, xml ) Need Help??

Monks,

Small epiphany of the obvious today. I am implementing/building a Content Management System in mod_perl. One of the things I worked quite a while on was figuring out how to store files on the filesystem but still have them plug into the security system I have.

So, clever me, I used File::MMagic to figure out the mime types of uploaded files and then stored them on the filesytem, along with data about them in a mySQL DB.

Rather proud of myself, I thought "cool. All I have to do is get the mime-type from the DB, open and print the file and voila! It fits into my security system."

A few issues-

  1. I'm using CGI::Application, which requires you NEVER TO PRINT TO STDOUT. You return your header properties and HTML from a subroutine, which CGI::Application intercepts and prints to stdout. This means I had to read the entire file into a variable, set the mime-type, and then "return" it.
  2. Byte-serving (page-at-a-time downloading) of PDFs wouldn't be implemented. This bugged me, but wasn't killer (even though I have a vast amount of large PDFs that we're managing). I could always adapt a script made by adobe to fix this.

Everything was working beautifully- docs on the filesystem were secure, things were humming along.

I started testing- downloading large PDFs (some 4 meg +). It took a little while (no byteserving, you know) but this wasn't a huge issue. Still, something didn't feel quite right about this system.

Then I looked at my HTTPD processes. Some were over 50 meg in size! Oof! This was because I had to slurp the file in and return it, and I'm programming in a persistent mod_perl environment.

Needless to say, I ditched the above system and wrote a mod_perl handler (my first serious one) to take care of access control based on my security system. Now I have byte-serving, sanely-sized HTTPD processes, and a much better solution overall.

When looking at the project at it's start, my intial thought was to write a mod_perl handler or use something like Apache::AuthzDBI, but I dismissed these because I didn't feel comfortable enough in mod_perl using anything beyond Apache::Registry. This was wrong, very wrong. The amount of time I took writing and rewriting was much more than if I had figured out Apache:AuthzDBI.

So, the moral of the story? Use the fruit of OTHER people's labors. Figure out what modules there are that solve your problems and use them. Hand-roll as an academic exercise, or if you absolutely have to.

-Any sufficiently advanced technology is
indistinguishable from doubletalk.

Comment on Let the experts do their jobs, or, A Lesson Learned, or, the CPAN coulda saved by butt
Download Code
Re: Let the experts do their jobs, or, A Lesson Learned, or, the CPAN coulda saved by butt
by IlyaM (Parson) on Dec 01, 2001 at 03:03 UTC
    Just a note about CPAN. Many modules are not written by experts. If you want to spend your time learning some module and adapting your program for it be sure to evalute alternatives. Often there exist several choises. Some of them is better suited for your task, some of them actually is just a pile of crap. Good example is templating modules. There exist so many of them on CPAN but people still upload new modules that do the same thing. IMHO some of them .. just doesn't deserve right for life :).

    Some criterias I use myself:

    • Look at sources: if I don't like how it is written it is very unlikely I use it.
    • Does module have automated tests? It is not very important criteria but usually good programmers tend to create them.
    • Is it supported by its mainteiner? Usually I try to avoid unmaintained modules.

    --
    Ilya Martynov (http://martynov.org/)

      Yeah, I always look at most of the modules I use (and even understand some of them!).

      I didn't mean "Let the experts do their jobs" like "I'm too dumb to possibly understand what's going on," more in the sense that we're lucky to have the CPAN and the ability to learn from/use the excellent work being done in the perl community at large.

      -Any sufficiently advanced technology is
      indistinguishable from doubletalk.

Re: Let the experts do their jobs, or, A Lesson Learned, or, the CPAN coulda saved by butt
by runrig (Abbot) on Dec 01, 2001 at 04:20 UTC
    Sometimes its just dumb luck, or being in the right place at the right time. Convert::TNEF was my first module, and I was most definitely NOT an expert at writing perl modules, and only somewhat competent at perl. But I was the first one to find all the proper docs on TNEF and the desire and need to put it all together in a module (I've since heard from others (w/more perl experience) who said they tried to do the same thing in the past but just couldn't find enough info on TNEF).

    <tongue-in-cheek>BTW, if IlyaM(above) ever gets a look at the code, he may decide not to use it because the indentation makes the code look truly horrid to most eyes</t-i-c> (it is consistent, but I was into one-space indentation at the time (lame excuse => sore thumb), and I've been meaning to run the whole thing through perltidy for awhile now :)
    But then again, using that sort of logic, anyone looking at the CGI code may decide not to use it :-)

    Update: Don't worry IlyaM, with any luck, you'll never have to use it :)

      Well, if there is no alternative I probably would prefer to use not very good modules (from my point of view) than reinvent the wheel. I rather send some patches if I have not choice. It depends on how afwul it looks to me :)

      As for CGI there exist good alternatives. Like CGI::Minimal or Apache::Request (this one is for mod_perl).

      --
      Ilya Martynov (http://martynov.org/)

Re: Let the experts do their jobs, or, A Lesson Learned, or, the CPAN coulda saved by butt
by perrin (Chancellor) on Dec 01, 2001 at 04:45 UTC
    Good post! The conflict between fear of learning other people's code and the efficiency often gained by doing so seems to be one of the central themes of Perlmonks, the mod_perl mailing list, and every place I've ever worked. You have to experience a few "oh man, that would have saved me so much work!" moments before you get over your fear of reading POD. Reminds me of the first time I found Template Toolkit...
      i personally believe in doing both (: i'll work on something for awhile
      and then look at a module already done, work on it some more, play with the module
      more, rinse.. repeat.. in fact i feel pretty lucky to have the other monks' problems and ideas (like this one!) to learn from: merlyn's articles are really good for that, amongst
      other monks' works. (to name the tip of the iceberg - Dominus, japhy, yourself for that matter)

      it's a theory of mine that if i read enough Good Code tm, it might eventually rub off. (: but at any rate, learning anything as complex as perl (in all it's shapes and sizes) solo is rather difficult, as this site's popularity states quite plainly.
      lately, i've been doing more RTFM'ing than actual coding though - i'm not certain if that's a good or bad thing.

      --
      Peace,
      strfry()

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://128767]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (15)
As of 2014-07-29 16:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (223 votes), past polls