I recently heard about Koding.com. I signed up and was delighted to discover native Perl support in both their default runtime container and IDE; with support for syntax highlighting and code completion. I cloned an existing Git repository, and I felt almost like I was working in a normal linux environment (albeit, in the cloud from a web browser).
If you don't mind using my referral (free RAM upgrades for me)...
https://koding.com/R/zjtzjt
At least now the links to critic and padre go to articles now. So, we should be in good shape now.
Content still might need some more fleshing out though. Plus, we might want to add an article for Tidy just to be safe.
]]>Despite what Wikipedia says - Wikipedia's List of tools for static code analysis - Perl has plenty of tools for static code analysis.
e.g. Perl::Critic and Perl::Tidy
Let's fix this. Anyone a Wikipedia editor?
]]>However, there is one big drawback to logadm. Whenever it runs, it stores a timestamp for each log it rolls in the logadm configuration file itself. I'll leave it to the reader to question the sanity of this.
For example:
/var/adm/messages -C 4 -a 'kill -HUP `cat /var/run/syslog.pid`'
Is changed to:
/var/adm/messages -C 4 -P 'Sat Apr 09 21:27:21 2011' -a 'kill -HUP `cat /var/run/syslog.pid`'
My immediate dilemma is that I like to put everthing important into version control. But since the logadm configuration file is constantly modified, it isn't practical to store it in version control without it getting overwritten every time it is deployed to the system from version control.
So, I wrote this simple perl script that takes both files in as arguments and spits out a version of the file that can be safely deployed. There is nothing complex about this script, but I share it here for the benefit of others that run across this dilemma.
#!/usr/bin/perl my ($configfile, $systemfile) = @ARGV; # check input unless ( $configfile and $systemfile and -f $configfile ) { print "usage: $0 configfile systemfile\n"; exit; } # nothing to fix if ( ! -e $systemfile ) { exit; } # open each file for reading open my $systemfile_fh, '<', $systemfile or die "can't open $systemfile: $!"; open my $configfile_fh, '<', $configfile or die "can't open $configfile: $!"; # read in each line of the file that does not have the -P timestamp while ( my $configfile_line = <$configfile_fh> ) { chomp $configfile_line; # then read in each line of the file that has the -P timestamp while ( my $systemfile_line = <$systemfile_fh> ) { chomp $systemfile_line; # if the line has the -P timestamp if ( $systemfile_line =~ /(.*)(\-P\s+'.*?'\s*)(.*)/ ) { # remove the -P timestamp and see if it is identical in both files my $systemfile_line_sans = $1.$3; my $insert = $2; if ( $configfile_line eq $systemfile_line_sans ) { # if the lines match then we will want to use the replace the # line with the version that has the -P timestamp $configfile_line = $systemfile_line; } } } # print out each line, whether we have swapped it, or not print $configfile_line."\n"; } close $configfile_fh; close $systemfile_fh;]]>
JT unveiled the game and the underlying technology at the latest Madison Perl Mongers meeting.
]]>One factor that can help me decide is the number of CPAN dependents each module has. (Don't confuse "dependent" with "dependency"; I use the word "dependent" to mean: other modules that depend on it.) If a module has lots of other modules that depend on it, then I can be relatively certain that the module might be worth relying on.
The information about the modules' dependents is exposed by http://deps.cpantesters.org/depended-on-by.pl, which is rather cumbersome to use.
So, I created a greasemonkey script which dynamically shows the number of dependents for each module on the search.cpan.org search results. It then displays the list of distributions in order of their numbers of dependents.
CPAN Search Dependents - is the link to the greasemonkey script.
Here is a screenshot of the script in action.
Note that it works better if you show 100 modules at a time, otherwise you might miss distributions that aren't displayed in the first 10 results.
Showing CPAN dependents is only one small factor in measuring the popularity of a module, and popularity isn't the only factor. Down the road I would like to display other information, such as data from Google search.
]]>
Perhaps web developers who want to know what technology is being used to run your awesome web app would look.
it's not a great idea volunteering too much extra information
I agree. But ServerSignature Off / ServerTokens Prod still shows "Apache". So I don't think it's that big of a deal to show "mod_perl"
Leaving out "/2.0" seems wise (although it doesn't indicate the actual version.)
FWIW, I pulled the config line out of an old document created by the mod_perl developers in a discussion about promoting mod_perl.