blogs.perl.org

I am using PDL. I become to know PDL can write clean code than I had expected. PDL::Lite, NiceSlice and OO interface is good.

PDL have PDL::Lite module. This module don't import any functions to current name space. and piddle(PDL varialbe) can call many function as method call.

The following are example codes.

use strict;
use warnings;

use PDL::Lite;
use PDL::NiceSlice;

# Create data
my $nums = pdl [2, 4, 7];

# Output data
print $nums->at(0) . "\n";
print $nums->at(1) . "\n";

# Get PDL varaible
my $pdl_first = $nums(0);
my $pdl_second = $nums(1);

# Assignment
$nums(0) .= 5;

# Get PDL variable which contains multiple elements 
my $pdl_parts = $nums(1:2);

# Assignment multiple values to PDL variable
$nums(1:2) .= 8;

print $nums . "\n";

And PDL can call many functions as method from PDL variable.

use PDL::Lite;

# Create data
my $nums = pdl [4, 4, 2, 2, 2, 7];

# Max
my $max = $nums->max;

# Min
my $min = $nums->min;

# Total
my $total = $nums->sum;

# Initialize 0
my $data_zeros = pdl->zeros(2, 3);

# Initialize 0～19
my $data_seq = pdl->sequence(20);

In formal documentation, function style is used in many examples. but you can use OO style if you like OO.

Kavorka is a function signatures module, along the lines of Function::Parameters, Method::Signatures, and MooseX::Method::Signatures.

I really like the increased development pace for Perl5 starting with 5.10. It has led to many nice features in a relatively short time and I´m grateful for that. Occasionally however, the need for speed imho trumps sanity and reason...

Yesterday I tried to port a Moose App to Moo but got stuck when I found out it is using MooseX::Role::Parameterizable, a module not available in Moo. A quick visit in channel #moose on perl.irc.org later and I was told to give Package::Variant a try.

Few lines of conversation/debugging later and here is my parameterizable HTML::FormHandler role. Package::Variant is an extremly promising module to me that is really helpful when refactoring your code.

declare the HFH role

package MyApp::Role::Form::Step::Value;

use Package::Variant
    importing => ['HTML::FormHandler::Moose::Role'],
    subs      => [ qw/ has_field requires has around before after with / ];

sub make_variant {
    my ( $class, $target_package, %arguments ) = @_;

    my $name = exists $arguments{name} ? $arguments{name} : 'value';

    has_field $name => (
        type         => 'Text',
        required     => 0,
        noupdate     => 1,
        not_nullable => 1,
        element_attr => { class => 'detect_whitespace' },
    );

    around '_build_parameter_fields' => sub {
        my ( $orig, $self ) = @_;
        return [ @{ $self->$orig }, $name ];
    };
}

1;

And here is how you would use it.

package MyApp::Form::Step::CondSubTest;
use HTML::FormHandler::Moose;
use MyApp::Role::Form::Step::Value;
extends 'MyApp::Form::Step::Base';
with
  'MyApp::Role::Form::Step::SubTest',
  Value( name => 'value_a' ),
  Value( name => 'value_b' ),
  ;
1;

I've been loving my current contract but, sadly, it's coming to an end soon. If you'd be interested in hiring me, drop me a line at info@allaroundtheworld.fr. Obviously I can probably crib together a few lines of Perl for you, but if you specifically need someone to come in and beat your test suite into submission (or create it from thin air), I'm your man.

You might find it ironic that my wife and I do international recruiting and I'm posting here, but we focus on international relocation and I'm not planning on moving. Hence, me being here :)

I've got a couple of leads already, but nothing set in stone.

Perl-Critic-1.121 marks the first production release from the new GitHub repository. We've also moved all the RT tickets to the GitHub issue queue.

Going forward, all development on Perl-Critic will happen on GitHub. For now, other modules like Test::Perl::Critic, Perl::Critic::More, and Perl::Critic::StricterSubs still live in the old Subversion repository but I'll be migrating those as time permits.

I've been wanting to make this move for a long time. The Subversion repository has served us well, but I think GitHub makes it much easier to attract and manage contributions from the community. Huge thanks to Tim Bunce, fREW Schmidt, Andreas Marienborg, Graham Knop, and Andy Lester for making this all happen.

Let the forking begin!

The next version of Perl::Critic has been shipped to CPAN and it includes built-in themes tied to the CERT guidelines for secure coding. CERT divides their guidelines into "rules" and "recommendations". You can activate the Perl::Critic policies that CERT suggests like this:

# Apply all "rules"
perlcritic --theme certrule  YourCode.pm

# Apply all "recomendations"
perlcritic --theme certrec YourCode.pm

# Apply both
perlcritic --theme 'certrule || certrec' YourCode.pm

These are not new policies -- we've just classified the existing policies that overlap with CERT's guidelines. Perl::Critic does not cover all the CERT guidelines, so I suggest visiting their site to see more ways to improve the security of your code.

Thanks to Kirk Kimmel for making this happen!

I've been using roles lately and was going to write about them on perltricks.com. However I've come into difficulty in explaining how roles are functionally different from inheritance.

• Avoid complex inheritance hierarchies
• Better encapsulation and code re-use by focusing on "does" over "is"
• Enforce polymorphism through "requires"

The difficulty I'm finding is that all of these features can be provided though inheritance already.

Avoid complex inheritance hierarchies. This is equivalent to only allowing one level of inheritance. Besides, roles can use other roles (at least they can in Roles::Tiny), so this problem is not avoided by using roles. This concept can also be confused with package hierarchies (e.g. File::Text) versus inheritance hierarchies -> clearly subclasses can inherit from modules outside of their package hierarchy, hence the risks of multiple inheritance.