i’m a lumberjaph

This week, with Alexis’s help, I’ve been working on adding auto-(de)serialization to Dancer’s request. This features will be available in the next Dancer version, the 1.170 (which will be out before April).

The basic idea was to provides to developer a simple way to access data that have been send in a serialized format, and to properly serialize the response.

At the moment, the supported serializers are :

• Dancer::Serialize::JSON
• Dancer::Serialize::YAML
• Dancer::Serialize::XML
• Dancer::Serialize::Mutable

Configuring an application to use the serializer

To activate serialization in your application:

set serializer => 'JSON';

or in your configuration file:

serializer: "JSON"

A simple handler

Let’s create a new dancer application (you can fetch the source at github) :

dancer -a dancerREST
cd dancerREST
vim dancerREST.pm

package dancerREST;
use Dancer ':syntax';
 
my %users = ():
 
# create a new user
post '/api/user/' => sub {
    my $params = request->params;
    if ( $params->{name} && $params->{id} ) {
        if ( exists $users{ $params->{id} } ) {
            return { error => "user already exists" };
        }
        $users{$params->{id}} = {name => $params->{name}};
        return { id => $params->{id}, name => $params->{name} };
    }
    else {
        return { error => "name is missing" };
    }
};
 
true;

We can test if everything works as expected:

plackup app.psgi&
> curl -H "Content-Type: application/json" -X POST http://localhost:5000/api/user/ -d '{"name":"foo","id":1}'
# => {"name":"foo","id":"1"}

Now we add a method to fetch a list of users, and a method to get a specific user:

# return a specific user
get '/api/user/:id' => sub {
    my $params = request->params;
    if ( exists $users{ $params->{id} } ) {
        return $users{$params->{id}};
    }
    else {
        return { error => "unknown user" };
    }
};
 
# return a list of users
get '/api/user/' => sub {
    my @users;
    push @users, { name => $users{$_}->{name}, id => $_ } foreach keys %users;
    return \@users;
};

If we want to fetch the full list:

> curl -H "Content-Type: application/json" http://localhost:5000/api/user/
# => [{"name":"foo","id":"1"}]

and a specific user:

> curl -H "Content-Type: application/json" http://localhost:5000/api/user/1
# => {"name":"foo"}

The mutable serializer

The mutable serializer will try to load an appropriate serializer guessing from the Content-Type and Accept-Type header. You can also overload this by adding a content_type=application/json parameter to your request.

While setting your serializer to mutable, your let your user decide which format they prefer between YAML, JSON and XML.

And the bonus

Dancer provides now a new method to the request object : is_ajax. Now you can write something like

get '/user/:id' => sub {
    my $params = request->params;
    my $user    = $users{ $params->{id} };
    my $result;
    if ( !$user ) {
        _render_user( { error => "unknown user" } );
    }
    else {
        _render_user($user);
    }
};
 
sub _render_user {
    my $result  = shift;
    if ( request->is_ajax ) {
        return $result;
    }
    else {
        template 'user.tt', $result;
    }
}

If we want to simulate an AJAX query:

curl -H "X-Requested-With: XMLHttpRequest" http://localhost:5000/user/1

and we will obtain our result in JSON. But we can also test without the X-Requested-With:

curl http://localhost:5000/user/1

and the template will be rendered.

Hope you like this new features. I’ve also been working on something similar for Tatsumaki.

You may want to see the final version here: github explorer

For the last weeks, I’ve been working on the successor of CPAN Explorer. This time, I’ve decided to create some visualizations (probably 8) of the various communities using Github. I’m happy with the result, and will soon start to publish the maps (statics and interactives) with some analyses. I’m publishing two previews: the Perl community and the european developers. These are not final results. The colors, fonts, and layout may change. But the structure of the graphs will be the same. All the data was collected using the github API.

Each node on the graph represents a developer. When a developer “follows” another developer on github, a link between them is created. The color on the Perl community map represent the countries of the developer. One of the most visible things on this graph is that the japanese community is tighly connected and shares very little contact with the foreign developers. miyagawa obviously acts as a glue between japanese and worldwide Perl hackers.

The second graph is a little bit more complex. It represents the European developers on github. Here the colors represent the languages used by the developers. It appears that ruby is by far the most represented language on github, as it dominates the whole map. Perl is the blue cluster at the bottom of the map, and the green snake is… Python.

Thanks to bl0b for his suggestions :)

If you are using the version of SD hosted on github, you can now clone and pull issues very easily. First,

$ git config --global github.user franckcuny
$ git config --global github.token myapitoken

This will set in your .gitconfig your github username and api token. Now, when you clone or pull some issues using sd:

$ git sd clone --from github:sukria/Dancer

sd will check your .gitconfig to find your credentials.

Alexis (sukria) released Dancer 1.130 this weekend. Dancer is a small and nice web framework based on ruby’s sinatra.

Dancer have few dependancies (and it doesn’t depends anymore on CGI.pm). The path dispatching is done using rules declared with HTTP methods (get/post/put/delete), and they are mapped to a sub-routine which is returned as the response to the request. Sessions are supported, and two template engines (one of them is Template Toolkit) comes with the Core. Dancer::Template::MicroTemplate is also available on CPAN if you need a light template engine.

You can easily test it with a simple script

#!/usr/bin/env perl
use Dancer;
 
get '/' => sub {
  return "dancer";
}
 
get '/:name' => sub {
  return params->{name} ." is dancing";
}
 
dance;

and execute this script, point your browser to http://127.0.0.1:3000, and voila.

Dancer provides also a small helper to write a new application:

dancer -a MyApplication

If you create an application with this script, an app.psgi file will be created. You can now execute plackup –port 8080 (which comes with Plack the Perl Web Server) and test if everything works fine:

curl http://localhost:8080

This release remove some components from the core and they are now available as differents CPAN distributions. Two new keyword have also been added, header and prefix.

If you want to read more about Dancer:

• Dancer’s documentation
• rewiew by xsawyerx
• gugod’s review
• sukria’s blog

Until today, I had a script named “lifestream.pl”. This script was triggered via cron once every hour, to fetch various feeds from services I use (like github, identi.ca, …) and to process the result through a template and dump the result in a HTML file.

Today I was reading Tatsumaki’s code and some examples (Social and Subfeedr). Tatsumaki is a “port” tornado (a non blocking server in Python), based on Plack and AnyEvent. I though that using this to replace my old lifestream script would be a good way to test it. Two hours later I have a complete webapp that works (and the code is available here).

The code is really simple: first, I define an handler for my HTTP request. As I have only one things to do (display entries), the handler is really simple:

package Lifestream::Handler;   
use Moose;                     
extends 'Tatsumaki::Handler';  
 
sub get {                      
    my $self = shift;          
    my %params = %{$self->request->params};
    $self->render( 'lifestream.html', {
        memes    => $self->application->memes($params{page}),
        services => $self->application->services
    });
}
1;

For all the get request, 2 methods are called : memes and services. The memes get a list of memes to display on the page. The services get the list of the various services I use (to display them on a sidebar).

Now, as I don’t want to have anymore my lifestream.pl script in cron, I will let Tatsumaki do the polling. For this, I add a service to my app, which is just a worker.

package Lifestream::Worker;    
use Moose;                     
extends 'Tatsumaki::Service';  
use Tatsumaki::HTTPClient;     
...
sub start {
    my $self = shift;
    my $t; $t = AE::timer 0, 1800, sub {
        scalar $t;
        $self->fetch_feeds;
    };
}
....
sub fetch_feeds {
    my ($self, $url) = @_;
    Tatsumaki::HTTPClient->new->get( $url, sub { #do the fetch and parsing stuff });
}

From now, every 60 minutes, feeds will be checked. Tatsumaki::HTTPClient is a HTTP client based on AnyEvent::HTTP.

Let’s write the app now

package Lifestream;            
 
use Moose;
extends "Tatsumaki::Application";
 
use Lifestream::Handler;       
use Lifestream::Worker;        
...
sub app {
    my ( $class, %args ) = @_;
    my $self = $class->new( [ '/' => 'Lifestream::Handler', ] );
    $self->config( $args{config} ); 
    $self->add_service( Lifestream::Worker->new( config => $self->config ) );
    $self;
}
...
sub memes {
...
}
 
sub services {
....
}

The memes and services method called from the handler are defined here. In the app method, I “attch” the “/” path to the handler, and I add the service.

and to launch the app

my $app = Lifestream->app( config => LoadFile($config) );
require Tatsumaki::Server;      
Tatsumaki::Server->new(
    port => 9999,
    host => 0,
)->run($app);

And that’s it, I now have a nice webapp, with something like only 200 LOC. I will keep playing with Tatsumaki as I have more ideas (and probably subfeedr too). Thanks to miyagawa for all this code.