Why are you forcing anyone that hits perl blogs to watch this unpleasant video? It auto plays and sucked up a good chunk of my monthly mobile bandwidth. Also I find the images distressing since it looks to me like the moose got hurt falling down :(
]]>My gut feeling here is that the grant amounts are quite small and as a result we are treating grantees like volunteers mostly (and cutting them a ton of slack as a result) Perhaps that is the real issue.
]]>I would think some sort of short questionnaire at the minimum would assist.
]]>Try not to feel too bad. I've been happy in the last 3 of 4 jobs and the one job I was unhappy at also had this crazy and probably illegal hiring process. The other three jobs I was already known based on my blogging and open source contributions. I can probably guess the company but maybe its better not too (there are only so many larger companies that use Perl and I only know of one with a crazy interview process...) If I'm right I doubt you or any Perl programmer that considers themselves modern would be happy there.
If the interview process feels disrespectful then ultimately its good to pass. I know just when you really need a job its hard to see it that way. But you are going to be there a while so its very important to feel happy. If there were red flags to you during interview then I think this is really the best thing for you. Best of luck - nap
]]>Just to be devil's advocate, if something thinks things look complex maybe they are a bit? you never know, sometimes the outsider opinion has some meaning worth looking for...
In terms about scripts getting complex, I wonder if the script is so complex it needs a pile of stuff then y ou might want to use more modules or (as brian de foy's been calling them 'modulinos' which is a module that can get called in script context and work like a script. I've found that approach helps to make stuff make sense a bit. Specifiic comments
#! /usr/bin/env perl
Yeah do that, I found the shebang is not a place to hang wild and wait for the police to show up to kick you out of the club. Also installing a local perl (with perlbrew, plenv or Build::Perl (my favorite, no bells , just do "curl https://raw.githubusercontent.com/tokuhirom/Perl-Build/master/perl-build | perl - 5.16.2 /opt/perl-5.16/" and you are good to go.
Perl is not the only language that suggestsion separting runtime from development. I recall when I did Java back in 1994 you always had a JDK in addition to the java runtime (big pain at the time to take up so much drive space). Its just that for a while Perl devs were used to the idea of using system Perl... even though it hurt us.
use strict;
use warnings;
worth the two lines in my head, but again you can avoid them if all your real code is in a module
use Cwd 'abs_path';
use File::Spec::Functions qw(catpath splitpath);
use local::lib catpath((splitpath(abs_path $0))[0, 1], '../extlib');
use lib catpath((splitpath(abs_path $0))[0, 1], '../lib');
Personally I find this wonky. I really don't think its a good idea to have a script try to bootstrap its own environment. You are introducing a tight, structural dependency between the script and the filesystem. I would have just done (from the command line)
perl -Ilib -Iextlib/local/lib/perl5 $script
I know that seems like its just moving stuff around, but ultimately I think its right to say that the caller of the script is responsible for $ENV. that will save you trouble when moving things around or when you need to run them under alternative creds (like under cron).
use CE::Util::ScriptBootstrap;
Again if the scripts are complex enough that you need a helper to make sure new dev don't reinvent the wheel incorrectly, doing libs is probably better. Personally I always liked the idea that you only add exactly what you need, that you don't anticipate 'tomorrow I might need a database connection, so lets install all this extra stuff right now'. As long as what you do today isn't poorly designed it won't prevent you tomorrow from properly extending it to support evolving business requirements.
For scripts that need to stand alone consider fatpacker.
If you want to have a bash wrapper that you can use to invoke a script under a given local lib I already put something like that on CPAN about 5 years ago (see App::local::lib::helper, and I think steve put a copy of that in bin or something, but reading the original docs is worth it I think).
Making a makefile target can help as well (sometimes I do "make perl-llib @args" and that does the local lib and the application lib if people find that a good idea.
Ultimately I don't think Perl needs more setup time than other development environments (and most of it can be automated). Its just that community practices are uneven and that does result in confusion.
]]>Not sure if this would help you but a while back I tried to write a faq aimed at recruiters:
https://github.com/jjn1056/perl-recruiting-web
feel free to steal as much as possible
]]>I hate to even have to bring it up, but I feel I am forced to because as a working Perl5 programmer one of my unpaid job duties is fighting FUD and convincing my peers that Perl is not a weird programming choice. The existence of confusion around Perl6 makes that job harder. This is actually a serious matter for me, since I program Perl5 not just for fun, its how I support my family, so its not game without consequence. Anything we can do to help fight that FUD is worth doing. Perhaps the statement could be worded differently such as to not annoy Perl6 hobbyists. However I think its worthwhile since I still regularly see articles attacking Perl and using Perl6 as part of that attack (see http://news.dice.com/2014/10/09/5-programming-languages-marked-for-death/ which made the front page of Slashdot earlier this month). If you create a webpage like this its going to end up in Google and someone might find it that was not following Perl development close enough to understand that Perl5 continues to evolve.
]]>What in the relationship between Perl5 and Perl6?
Although Perl6 was originally envisioned as the next great version of Perl, the community now deems Perl5 and Perl6 as separate projects with separate development teams and project goals. Perl5 continues to flourish into its 3rd decade and there is no plan for it to cease development anytime soon. (maybe some relevant link here??)
]]>jnap
]]>