In  DBI Part 1 I introduced how to connect and how to DBI  can run hard-coded SQL statements. But to be truly useful it must be able to bind variables to placeholders.

With the following SQL,

SELECT city FROM locations WHERE location_id = 1800

we would like to replace the 1800 with a placeholder. We could just use Perl for this, which would look something like this:

my $loc_id = 1800;
$sql = "SELECT city FROM locations WHERE location_id = $loc_id";

This is called in-line binding. It can work quite well for simple SQL, but what if we get an SQL statement such as this?

SELECT city FROM locations WHERE location_id = 'IT';

Almost identical statements, but we have to add nasty single quotes to make the statement work. So our Perl will look like this:

my $country_id = 'IT';
$sql = "SELECT city FROM locations
WHERE location_id = '$country_id'";

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.

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...

A little History

Since its inception by Tim Bunce in 1994, DBI (DataBase Interface) has been the de facto standard for interfacing databases with the Perl language. Thanks to the designers' foresight, DBI is database-independent, with methods, variables, and conventions that provide a consistent programming interface, no matter what database management system is being used.

Standard API?

So, in theory, programs written with DBI should work the same between DBs, Reality is a little different as it seems that each RDMS try to outdo each other in the number of non standard SQL function they implement as well there are a number of 'Drivers' that do not even access a RDMS or even a DB for that matter. Fortunately DBI make no attempt to force you to use a standard SQL or even SQL. Think of DBI as the glue that the Perl language uses to link to a specific 'Driver' to a data store giving us a common platform to work with.

Handles

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!

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.

Last time, I showed you how to write non-blocking (web) applications using Mojolicious. In those examples, each action only had to perform one non-blocking action. In this article I’m going to take things a little further, introducing you to Mojo::IOLoop::Delay. I will use a delay object to perform multiple simultaneous non-blocking actions and wait until they complete before moving on, all without blocking the server for other requests.

Just wanted to share a new little debugging tool, Devel::Quick.

It allows you to write DB::DB subroutines on the fly, and provides a few variables by default to make things simpler.

Background

DB::DB (the DB subroutine under the DB package) -- if defined when Perl is run under '-d' -- will be executed before every line in the Perl source being run. If the DB::DB call is within a subroutine, you can also peak at the arguments passed into the sub.

Example

A simple example of a module using this is Devel::Trace, which will print out the source code about to be executed for every line.

With Devel::Quick, we can recreate this functionality like so:

$ perl -d:Quick='print ">> $filename:$line $code"' prog.pl

Or with -e

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!

Does your Git wrapper support commit messages encoded in latin-1? (encoding header) In Shift-JIS? Actually, any encoding you can think of, given that Git doesn't care.

Do you know about multiline headers? Like in signed commits? (gpgsig header)

About this posting series

These days Perl/CPAN is not king anymore. It no longer has the largest number of modules or the most complete collection in every aspect. But it still compares very favorably overall and is still regarded as one of the repositories that have the best supporting infrastructure/ecosystem (e.g. CPANTesters).

Each post will mention a few modules/applications that exist and live on other language's software repositories like Python's PyPI, RubyGems, or npm, but currently do not have their equivalents on CPAN (at the time of posting, according to my observation).

How to view this negatively

So what? Well, read on.

You have $LANG envy!. So what? :-) Envy is good, I heard it's one of the virtues of programmer (well yeah, hubris is a mispelling). It's nice to be able to have things that others have.

Well, I couldn't resist...had to start with the typical "Hello, world!" This is a blog site about a programming language, is it not?

I am currently a high school student, and computer programming is one of my interest/hobbies. I have a website where I offer Perl tutorials for beginners, and I really like making tutorials. That said, I myself am not a very advanced programmer, by any means...I really don't know much at all. One of the ways that I learn is by taking on programming challenges/tasks, but the issue is, I don't know how effectively I am completing the task. I am sure there are better ways to approach some problems from both logical and technical standpoints. Therefore, I am mostly starting this blog as a place to get feedback from others about the scripts that I write as to what the potential weaknesses/drawbacks might be, and how I can make my scripts (and my programming skills in general) better.

Welcome to Planet Moose, a brief write up on what's been happening in the world of Moose in the past month, for the benefit of those of you who don't have their eyes permanently glued to the #moose IRC channel, or the MetaCPAN recent uploads page.

Thanks for contributions from Damien Krotkine; and thanks to Upasana Shukla for allowing me to interview her. If you'd like to contribute some news for next month's issue, you can do so on the wiki.

Ricardo Signes' App::Cmd has been praised a lot so I gave it a try for my recent command line app. In summary, the module is great although I missed some minor features and documentation (reminder to all: if you miss some feature in a CPAN module, don't create yet another module but try to improve the existing one!). One feature I like a lot is how App::Cmd facilitates writing tests for command line apps. After having written a short wrapper around App::Cmd::Tester my formerly ugly unit tests look very simple and clean. Have a look at this example:

Previous reports: Apr-Jun 2013, Jan-Mar 2013, ...

After a lack of hactivity in the previous quarter, I've slowly resumed development work. Sadly I failed to achieve last quarter's target to setup CPANLists and GudangAPI, and instead have been mostly busy getting my workflow more {d,r}efined, for development of CPAN modules as well as other non-CPAN Perl projects. I blogged about that here and here. I made some progress on a tool called riap, which is a command-line shell Riap client and will make debugging/browsing Riap-supporting API services (like CPANLists and GudangAPI will be) easier. This will be released in a few days. I also released App::ListRevDeps to help me see who uses my modules.

New modules that got created during this period: Carp::Always::Dump (like Carp::Always but dumps data structures in arguments), App::osnames, DateTime::Format::Indonesian, App::ParseCPANChanges, Media::Info and Media::Info::Mplayer, version::Restrict, RSS::From::Twitter.

I write a metric crap ton of code. It’s pretty much what I do from the time I wake up until the time I go to bed on most days. I do it because I love it, but there’s something that’s always bothered me about code, or rather coders. All too often we try to make code perfect, when what we should really be trying to do is make it work. 

We try to keep things loosely coupled, modular, and using the right design patterns. We apply all kinds of best practices, optimizations, and the latest paradigms. In reality though, if we make something that works, there will be time to go back and fix it, because making it work often means making money, which gives you options. 

My earlier post --
Seeking collaborators: native puppet cpanm provider has already attracted feedback and interest from four individuals on at least two continents.

Thinking out loud about creating a real puppet package provider to handle perl modules, led this afternoon to a conversation on #perl-help with ilmari_ who pointed out that the lack of a real package manager for perl will frustrate efforts to wrap that missing functionality in a native puppet provider for its package resources. He called what we have now 'module installation tools' which fail to rise to the level of a real package manager. At a minimum, he suggested a real perl package manager would also require the ability to uninstall a module, as well as the ability to query the system about the modules installed there, perhaps the ability to query upstream about available packages.

This immediately created a threat for scope creep as I now explore what would be required to provide that missing functionality, as prelude to writing a puppet provider which might wrap it.