Perl

given & smartmatch in Perl 5.18

2013-05-30T12:55:41+02:00

As you might have heard, smartmatch (and thus given/when) have been sort of deprecated in Perl 5.18. Well, there not really deprecated, but converted to an experimental feature and thus issue a warning.

While I understand that some cases of smartmatch might be fuzzy / hard to understand, some cases are very simple, straightforward and lead to cleaner code. Especially if combined with give/when.

But as I did not participate in the discussions on p5p regarding the perceived problems with smartmatch, it's a bit late and lame to complain now (c.f. Fresse halten, selber machen).

Anyways...

Here is an example of some nice and simple code powered by smartmatch (from Blio::Node)

  given ($converter) {
      when ('html') { return $raw_content }
      when ([qw(textile markdown bbcode)]) {
          my $o = Markup::Unified-&gt;new();
          return $o-&gt;format($raw_content, 'textile')-&gt;formatted;
      }
      default {
          my $method = 'convert_'.$converter;
          if ($self-&gt;can($method)) {
              return $self-&gt;$method($raw_content);
          }
          else {
              return &quot;No such converter: $converter&quot;.$raw_content;
          }
      }
  }

Here I compare a string against a string (or a list of strings, in the second when). Turning this into an old-school if-else block is of course possible & easy, but ugly.

  if ($converter eq 'html') {
      return $raw_content
  }
  elsif (   $converter eq 'textile'
         || $converter eq 'markdown'
         || $converter eq 'bbcode') {
      my $o = Markup::Unified-&gt;new();
      return $o-&gt;format($raw_content, 'textile')-&gt;formatted;
  }
  else {
      my $method = 'convert_'.$converter;
      if ($self-&gt;can($method)) {
          return $self-&gt;$method($raw_content);
      }
      else {
          return &quot;No such converter: $converter&quot;.$raw_content;
      }
  }

So I decided to keep the given/when and use the also new(?) conditional no warnings thingy:

no if $] &gt;= 5.018, 'warnings', &quot;experimental::feature_name&quot;;

Unfortunately, there's a small error in the relevant section of perldelta, where it says

no if $] &gt;= 5.018, &quot;experimental::smartmatch&quot;;

But it should say

no if $] &gt;= 5.018, 'warnings', &quot;experimental::smartmatch&quot;;

I've already submitted a patch (my first contribution to the Perl core, albeit a very tiny one..)

So what's the point?

Hm, well, I just wanted to say that I like smartmatch and given/when and for now will rather use the no-warnings hack than downgrade back to if/else. Maybe this opinion can be considered in future discussions on smartmatch.

4 TPF Grant Proposals are waiting for some review

2013-05-05T13:17:21+02:00

Alberto just published the 4 TPF Grant proposals for Q2/2013:

YACT - Yet Another Conference Tool by Torsten Raudssus (Getty)
rpm.perl.it by Jozef Kutej
Review of Perl Web Frameworks by Neil Bowers
Next Release of Pinto With Key Features by Jeffrey Ryan Thalhammer

It makes the life of the members of the TPF Grants committee easier if the proposals get some community feedback. So please go to the TPF site and leave some comments at the respective proposal pages. The grant committee has to vote until mid of May, so please submit your feedback before that.

Bread::Board is the right tool for this job

2013-04-21T11:33:54+02:00

... with a big emphasis on this!

Maybe you remember my question from last week, where I asked if Bread::Board is the right tool for a project we are currently starting. (If not, I'll wait until you've read it..)

I've got some good feedback via IRC and in the comments, and building on that feedback we hacked together a system that seems to work. And which I will describe now, so you might also understand Bread::Board (and most notably Parameterized Containers) better. But also to get even more feedback on potential design errors and gross misunderstandings of Bread::Board concepts that might hide in our solution.

"this job"

For our newest project we want to use a new approach. Instead of building a very big, monolithic Catalyst application we want to implement lots of small(-ish) apps. Each app does one thing, and does it well and well-tested. The apps talk to each other over ZeroMQ. The apps depend on various components (0mq, DB, templates, caches, ...). The components need to be initiated slightly differently in different environments (prod, dev, testing, ..).

As you can see, this is a rather complex setup. And Bread::Board is the (a) right tool for complex setups.

Parameterized Containers

I took me a while to fully understand parameterized containers. For me, the most important part was to see that you sort of "pass in" a container into another container, thereby naming the passed-in container. The containing container can depend on services that will be provided by the passed-in container (sort of like a method that takes a callback as an argument).

Maybe a bit of code is clearer:

my $apps = container $class =&gt; ['Environment'] =&gt; as {
        container 'App' =&gt; as {
            service 'renderservice_worker' =&gt; (
                class        =&gt; 'OurApp::RenderService::Worker',
                dependencies =&gt; {
                    coder         =&gt; '/Environment/json_coder',
                    renderer      =&gt; '/Component/Renderer/TTnowrap',
                }
            );
        };
        container 'Component' =&gt; as {
            container 'Renderer' =&gt; as {
                service 'TTnowrap' =&gt; (
                    lifecycle =&gt; &quot;Singleton&quot;,
                    class     =&gt; 'Template::AutoFilter',
                    block     =&gt; sub {
                        return Template::AutoFilter-&gt;new( ... );
                    },
                );
            };
        };
   };

Or maybe not, so I'll explain that a bit...

In the above code snippet, I have set up Bread::Board container. A container is some sort of namespace that includes services. A service defines a way to initiate an object that is needed by the application.

Here I only define on app, "OurApp::RenderService::Worker". This app is a worker process that can render something. We plan to start lots of those (on different machines), so we can easily scale our app. The RenderService::Worker (well, the trimmed down version I use for this example) needs two objects: a coder to en/decode JSON and a renderer (in this case Template::Toolkit).

Besides the App-namespace we also define a Component-namespace (i.e. container). This container contains another container, containing a service, TTnowrap (this service has some more dependencies (eg INCLUDE_PATH) that I removed for the sake of a "simple" example).

In other parts of our Bread::Board, we can address this service as /Component/Renderer/TTnowrap. We can get to the RenderService::Worker via /App/renderservice_worker. And there we can depend on TTnowrap.

But we also depend on something called /Environment/json_coder. Which is nowhere to be found (yet). Well, in fact parts of it are already found (if you look at the first line of my example):

my $apps = container $class =&gt; ['Environment'] =&gt; as {

Here we tell Bread::Board that the container we're setting up takes another container as a parameter, and that the services defined in the container shall be accessible as /Environment in the containers and services we're just going to set up.

So we promise the container that later there will be a container named Environment, but just now we're very sorry, and we just don't know what exactly this container will contain.

The Parameter Container

So let's fulfill that promise:

my $env = container $self =&gt; as {
    service 'json_coder' =&gt; (
        class     =&gt; 'JSON::XS',
        lifecycle =&gt; 'Singleton',
        block     =&gt; sub {
            return JSON::XS-&gt;new-&gt;utf8-&gt;pretty-&gt;allow_nonref;
        },
    );
};

Now we create our final Bread::Board (i.e. the mix of general definitions and the environment):

my $bb = $apps-&gt;create( 'Environment' =&gt; $env );

Running the App

To initiate a new RenderService::Worker, we can now do:

my $worker = $bb-&gt;resolve( service =&gt; &quot;App/renderservice_worker&quot; );
$worker-&gt;run;

Putting it all together

We have on class, OurApp::BreadBoard. In this class we define all our Apps and all our Components in one big Bread::Board that expects one container as a parameter. This container is named Environment.

For each environment, we have a class (eg OurApp::BreadBoard::Env::Dev). In this class we provide the services that are "missing" in the general Bread::Board. They are missing because they are different for each environment.

Again in OurApp::BreadBoard we have a method called setup that looks sort of like this:

sub setup {
    my ( $class, $env_class_name) = @_;

    my $env_class = 'OurApp::BreadBoard::Env::' . $env_class_name;
    Class::Load::load_class($env_class);
    my $env = $env_class-&gt;new( name =&gt; $env_class_name );

    my $apps = container $class =&gt; ['Environment'] =&gt; as {
        ... # define all Apps and all Components
    }

    return $apps-&gt;create( 'Environment' =&gt; $env );
}

So in our scripts we can do:

use OurApp::BreadBoard;

my $env = $ARGV[0] || $ENV{BB} || 'Dev';

my $bb  = OurApp::BreadBoard-&gt;setup( $env );
my $app = $bb-&gt;resolve( service =&gt; &quot;App/render_worker&quot; );
$app-&gt;run;

Problem: Command Line Params

There is still one problem that I have: We can now no longer use MooseX::Getopt to make different options needed by different apps settable from the command line. It might be possible to solve that via parameters in Bread::Board (something completely different than parameterized containers!), but I haven't looked into this yet.

But there's more

Even though this example isn't really simple, it is still to simple to see the real benefit of Bread::Board. I will go into further detail in some future blog posts.

I also did not cover how we are using alias for fun and profit. Another nice side effect of Bread::Board is that we unified our scripts (and in fact replaced all of them with one script to rule them all) (which also explains why the services in Apps have lowercase names instead of CamelCase).

Stay tuned...

Is Bread::Board the right tool for this job?

2013-04-12T11:28:23+02:00

This post is a question / cry for help!

We're currently working on a new app that's going to need several components (web frontend, web admin interface, lots of small to big workers connected via ZeroMQ, cron jobs, ...). These components need to access various other services (DB, logging, templates, caches, ..).
So instead of defining these services in lazy_build attributes that live in roles and are applied to the components, we though we'd give Bread::Board a try. We also consider to use OX instead of Catalyst, and OX uses (no, is) Bread::Board.

Our idea is to define a set of services (DB, templates, ..) and their dependencies. Each component would also be a service (or a container?) and depend on the services it needs.

In a script that runs a worker, we could then do:

use OurApp::BreadBoard;
my $bb = OurApp::BreadBoard-&gt;new( name=&gt;'SomeWorker' );
my $app = $bb-&gt;resolve( service =&gt; 'Apps/some_worker' );
$app-&gt;run;

This seems to work.

But...

We have different environments: production, development, testing, ...

In production, the workers are distributed over several different machines. They use some fancy 0mq service discovery to figure out where to connect to.

In development we want all the workers to run on the same machine. So we need a trimmed-down version of the service discovery. We also want to use different databases. Log somewhere else. etc

So how can we tell Bread::Board to use different services (or to create the same services differently)?

Parameters

You can pass parameters to a service when you resolve it:

https://metacpan.org/source/STEVAN/Bread-Board-0.25/t/041_parameter_cache_handling.t
line 41:   $c-&gt;resolve( service =&gt; 'foo', parameters =&gt; { bar =&gt; 10 } );

But it does not seem to be possible to pass a parameter to ALL services, at least if I understand Bug #77229 correctly.

Stevans suggestion to just also resolve the dependency might work, but is sure very ugly (especially if you need to do it on several services/deps). I could just as well generate the objects myself and pass them around...

Bread::Board::Container::Parameterized

I cannot even tell is this might be a solution because it lacks docs, and I cannot figure out what it should do from the tests.

Moose attribute

Bread::Board is based on Moose. So we can add a regular attribute to our Bread::Board class and use this to discern the environments:

package Our::BreadBoard;
use Moose;
use Bread::Board::Declare;
has '+name' =&gt; ( is =&gt; 'ro', default =&gt; &quot;DefaultName&quot; );

has 'environment' =&gt; (
    is      =&gt; 'ro',
    isa     =&gt; 'Str',
    default =&gt; 'production',
    service =&gt; 0,
);

service => 0 seems to be crucial here, because this tells Bread::Board::Declare that this attribute is just a plain Moose attrib and no Bread::Board service.

Now I can access this attribute in the blocks building my objects (but accessing it isn't that easy, either..):

package OurApp::BreadBoard;
use Moose;
use Bread::Board::Declare;

has 'zmq_service_discovery' =&gt; (
    is    =&gt; 'ro',
    isa   =&gt; 'OurApp::ServiceDiscovery',
    block =&gt; sub {
        my ($service, $container) = @_;
        my $root = $container-&gt;fetch('/');

        if ($root-&gt;environment eq 'production') {
            return OurApp::ServiceDiscovery::Distributed;
            # or:
            # return OurApp::ServiceDiscover-&gt;new(
            #     mode =&gt; 'distributed'
            # );
        }
        else {
            return OurApp::ServiceDiscovery::Local;
        }
    },
);

has 'some_worker' =&gt; (
    is  =&gt; 'ro',
    isa =&gt; 'OurApp::Some::Worker',
    dependencies =&gt; {
        service_discoverer =&gt; 'zmq_service_discovery'
    }
);

# regular script launching the worker
use OurApp::BreadBoard;
my $bb = OurApp::BreadBoard-&gt;new( name=&gt;'SomeWorker' );
my $app = $bb-&gt;resolve( service =&gt; 'Apps/some_worker' );
$app-&gt;run;

# a &quot;meta&quot; script that starts all components, each running in a fork
# this should also start the web front/backend (via plackup)
use OurApp::BreadBoard;
my $bb = OurApp::BreadBoard-&gt;new(
    name=&gt;'MetaRunner',
    environment=&gt;'devel'
);
foreach my $app (qw[some_worker]) {
    if (my $pid = fork()) {
        # parent, manage childs etc
    }
    else {
        my $app = $bb-&gt;resolve( service =&gt; 'Apps/'.$app );
        $app-&gt;run;
    }
}

The Questions

Is this approach sane? Are there better / native ways to pass options deep into a Bread::Board stack? Is Bread::Board the completely wrong tool? We'd really appreciate any feedback / comments!

Acme::ReturnValue 1.001

2013-03-30T11:03:45+01:00

At the German Perl Workshop I did a lightning talk on Acme::ReturnValue and in the process of preparing the talk started to rework the module. I have now finished the slight modernization of the code (eg using Path::Class and Moose coercion) and fixed some issues (eg handling of __PACKAGE__->meta->make_immutable). I switched to Dist::Zilla, which (on the one hand) is very nice, but (on the other hand) caused me to upload a tarball to CPAN that included not only the rendered website but thousands of JSON files. Then I figured out how to configure the GatherDir plugin...

I've also did some modification to the website. The list of cool values is now arranged more clearly (the list of packages per return value is hidden via JQuery, so you can scroll through the funny values more easily). I've also added a disqus-powered comment box and fixed some minor HTML errors.

I still haven't set up a cronjob yet, but it should be much easier now, because I now remember which dists I already checked between each run. This changed the run-time from a few hours to a few minutes.

When my son asked me what I was doing (while I was working on the website), I explained the concept to him and showed him the site. He found it very funny! This reminded me that this whole return values "hacking" is a good representation of one of the core qualities of the Perl community: Fun!