Re: Production Environments and "Foreign" Code

in reply to Production Environments and "Foreign" Code

Most of my employers have had the attitude "Do whatever you like, but it's your $#%@ if it breaks." I personally have never run into a similar policy.

As for modules ... my feeling is that the "core" modules are a subset of the real "core" modules. I have never had a problem d/l'ing almost any CPAN module and having it work according to docs. (This doesn't mean that I didn't have to extensively augment/modify the module(s), but that's another story.) No data loss, no corruption, no nothing. YMMV.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Comment on Re: Production Environments and "Foreign" Code

Replies are listed 'Best First'.
Re: Re: Production Environments and "Foreign" Code by Revelation (Deacon) on Mar 12, 2003 at 23:27 UTC
My advice to you, and the poster of the root node is to "protect your $#@%@". (to the root node author, that's if you do convince your employer to allow you to use CPAN ;-) ) This means a couple things that people have already said as well as a couple more unique sugestions: Check http://testers.cpan.org, but don't take it to be the perfect. Take notice of whether the failures apply to you (meaning check whether the failures are platform specific, dependency problems, etc.) Check http://rt.cpan.org. This is a great. Since it's open source check the code on your own. Registered modules seem to be more reliable/better tested than unregistered modules. They also provide a DLSIP definition that can be very helpful in assessing the viability of the module. This is key to me; the most important things about it are the support level, and developmental stage. Check around with fellow perl coders. See if any of them have ever had trouble with the code. Check the version of the code (duh). 0.0x generally means something is beta or incomplete, treat it as such. Install the module on your/your companies test box, and test it. Don't only use their test software, do further regression testing, test the code in the environment you'll use it in (what will you use it for? ) If you still can't discern the credibility, email the author, and ask them if they have to 'fix' anything for the next version of the software. Check the author's credibility. Damian, Lincoln, etc. provide an instant credibility because their name is on their code. They can't publish crap because then their name value goes down. On the other hand, if you're using a module by a fool like me, you might want to think twice about putting it an environment where your job is on the line. { grin } Gyan Kapur gkapur@myrealbox.com	[reply]

Replies are listed 'Best First'.

Re: Re: Production Environments and "Foreign" Code
by Revelation (Deacon) on Mar 12, 2003 at 23:27 UTC

Check http://testers.cpan.org, but don't take it to be the perfect. Take notice of whether the failures apply to you (meaning check whether the failures are platform specific, dependency problems, etc.)
Check http://rt.cpan.org. This is a great.
Since it's open source check the code on your own.
Registered modules seem to be more reliable/better tested than unregistered modules.
They also provide a DLSIP definition that can be very helpful in assessing the viability of the module. This is key to me; the most important things about it are the support level, and developmental stage.
Check around with fellow perl coders. See if any of them have ever had trouble with the code.
Check the version of the code (duh). 0.0x generally means something is beta or incomplete, treat it as such.
Install the module on your/your companies test box, and test it. Don't only use their test software, do further regression testing, test the code in the environment you'll use it in (what will you use it for? )
If you still can't discern the credibility, email the author, and ask them if they have to 'fix' anything for the next version of the software.
Check the author's credibility. Damian, Lincoln, etc. provide an instant credibility because their name is on their code. They can't publish crap because then their name value goes down. On the other hand, if you're using a module by a fool like me, you might want to think twice about putting it an environment where your job is on the line. { grin }

Gyan Kapur
gkapur@myrealbox.com

[reply]

In Section Meditations