[AnnArbor.pm] Seeking advice on using Perl in a professional way

[Harold Tessmann]

Thanks for your reply.

On Thu, May 4, 2017 at 5:56 PM, John Wiersba <jrw32982 at yahoo.com> wrote:

> Partly, it depends on the target environment you're going to deploy to and
> how much control you have over that.
> How many different servers are we talking about in all?  What OS and
> system perl version are they running?  MS Windows?
> Can you easily install the modules you want on those servers?  Binary (xs)
> modules or pure perl?
>

I think I can get away with only UNIX-like OSes: a mix of Mac OS X on the
desktop and GNU/Linux on the server. (We have a few people on Windows, but
they have Ubuntu either via VM or the new Ubuntu-on-Windows.)

I’m not using any particularly new features, so I can live with the
built-in 5.18 from OS X 10.11 El Capitan. I do understand that that limits
me to Modern Perl 2014; if that becomes an issue, I’ll build my own.

All the modules I’ve used thus far are pure Perl (non-XS), and I should be
able to convince IT to install them on the server.


> Presumably you'd want to install those modules to be local to a user acct
> (local::lib), rather than into the system perl itself.
>

I use cpanm <https://github.com/miyagawa/cpanminus> to install them with
the --local-lib flag.


> Do you want/need to create a local perl environment (your own compiled
> perl, rather than the system perl; perlbrew, plenv)?
>

This is a good question. So far I’ve done with the system version, not
keeping up with the latest and greatest features. If necessary, I could
probably get a newer version installed.

The answers to the above questions may have a large influence on the
> approach you take.  For small-medium sized scripts on large numbers of
> diverse servers, sticking with the core modules (e.g. Getopt::Std,
> Getopt::Long) and pure perl may be just fine.  If you need binary modules,
> you'll have to take a more complicated approach.
>
> In any case, warnings/strict is a must in production code.  Hash-based
> native objects are fine for smaller projects.
> If you're going modern, then Moose.
>

Thanks again!
Harold


> ------------------------------
> *From:* Harold Tessmann <htessmann at control-tec.com>
> *To:* AnnArbor-pm at pm.org; Detroit-pm at pm.org
> *Sent:* Thursday, May 4, 2017 3:36 PM
> *Subject:* [AnnArbor.pm] Seeking advice on using Perl in a professional
> way
>
> Hi from YpsiArbor/Allen Park,
>
> I'm looking to productionize some Perl scripts, and as such, I want to
> adopt more structure than I use in disposable scripts. These scripts would
> be used within the bounds of my employer, not released to the general
> public (with maybe one or two exceptions). I know that TIMTOWTDI, but I
> like the “sometimes consistency is not a bad thing either” extension when
> it comes to common problems such as command-line option parsing, and the
> perldocs don’t go in depth on what people use in the real world. I’m
> looking for advice on topics including, but not limited to:
>
> • Modern Perl: I like it in general, and I can install it on my team’s
> machines. Are there reasons I shouldn’t use it?
>
> • Does anybody have a suggestion for a good blank script template? For
> instance, I know I want "use Modern::Perl 'version';" or "use
> warnings/strict;", etc., but there’s probably other things I would want in
> a basic script. I’ve handled this in a sort of ad-hoc manner, growing new
> scripts based on what I learned from the old, but I’d like to build a good
> template once and be done with it. I’d also like the template to include
> documentation, and that raises more questions. Is there a reason to put my
> pod block near the top vs. the bottom? Getopt::Tiny seems nice, including a
> feature to automagically build a usage block—should I use that or is there
> a reason to avoid it? Or is there a better option parser?
>
> • Do you run Perl::Critic on your code? I know I’ll disable some of the
> rules, but is it more hassle overall than it’s worth? Similarly, PerlTidy:
> it seems useful for generating HTML versions of documentation, but I write
> code in a very precise way, such it would take more time to configure it
> than I would save in reformatting.
>
> • Thus far I haven’t built anything complicated enough to warrant figuring
> out an object library; I can get by with basic hash-based structures. I’ve
> read a bit about Moose and Dancer: how do they compare? And what else
> exists that I should consider?
>
> Any advice is greatly appreciated.
>
> Thanks,
> Harold
> _______________________________________________
> AnnArbor-pm mailing list
> AnnArbor-pm at pm.org
> http://mail.pm.org/mailman/listinfo/annarbor-pm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/annarbor-pm/attachments/20170504/65603f69/attachment-0001.html>