Posts Tagged ‘Perl’

Dancer 1.160 released

A new version of Dancer has been published to CPAN a few minutes ago, it’s also available from the official website, in the download section.

As you can see, the project has now its own domain name: http://perldancer.org, it’s clearly more shiny than the previous subdomain I used ;) So feel free to update your bookmarks (even though the old domain name now redirects to the new one).

Oh, and there is also a mailing list now, for people who like to share experiences about Dancer; feel free to join.

The change set for 1.160 is impressive, thanks a lot to everybody who got involved!

Happy dancing.

Tags: ,
Posted in Programming 1 Comment »

About performances

I recently focused on Dancer’s core with a single target in mind: optimization.
After having heavily refactored the Dancer::Route class, I started benchmarking Dancer.

To start with, I’ve created a set of test applications, in order to bench different kinds of application (from a hello world app to a huge one).

All these applications are available in this repository, if you like to see more precisely what I did.

The first test I did was to bench a “hello-world” application, with PSGI, Dancer 1.150 and the last version of the master branch.

hello.psgi .................... 1420 req/s
hello.dancer (1.150) .......... 1260 req/s
hello.dancer (github/master) .. 1320 req/s

You can see that Dancer “master” is about 100 req/s faster than 1.150, this is mainly thanks to Dancer::Route::Builder: Dancer now compiles all the routes defined by the application at startup time, and don’t spend time whenever a request is handled to do that job.

Moreover, thanks to SawyerX, Dancer now caches route resolution via Dancer::Route::Cache, and that increases response-time drastically when accessing an application with lots of routes.

Here is another bench that I did against an application with 676 routes handlers.

big.dancer (1.150, no cache, no route compiler) ...  110 req/s
big.dancer (GH, no cache, route compiler) .........  130 req/s
big.dancer (GH, cache, route compiler) ............ 1300 req/s

It appears clearly here that with a big number of route handlers, Dancer’s response-time decreases. I wanted to see more precisely how that occurs, and I run a bench in order to compare the response-time when varying the number of route hanlders.

As you can see on this graph, thanks to route caching, we now have a roughly constant response-time, no matter how many route handlers we have in the applicaiton.

These improvements will be shipped with the next CPAN version, either 1.151 or 1.160 if we have the time to add some new features as well.

Stay tuned.

Tags: ,
Posted in Programming 1 Comment »

Dancer 1.150 released

I’m happy to announce the release of Dancer 1.150.

This release has been made possible by six people, so it’s quite the first community-driven release of Dancer, and nothing could make me more happy than that.

I really like the fact that different people, from different places come and contribute ideas, documentation and patches. This is how open source works, and this is how great tools are written. I’m glad to see Dancer taking that path. I can only hope that it will be like that for a long time.

This new version provides mostly bugfixes and documentation updates. See the changelog for full details. Oh, and thanks to David Precious, we now have a shiny Cookbook!

Major new features will come with 1.160, but that’s for another blog entry ;)

Enjoy your dances.

Tags: , ,
Posted in Programming 1 Comment »

Dancer’s development update, near to release 1.140

Lots of good things happened recently in Dancer’s development, here they are:

HTTP::Server::Simple::PSGI

After my last post about Dancer, Tatsuiko Miyagawa suggested to build Dancer’s standalone server upon a PSGI-aware layer, rather than on HTTP::Server::Simple::CGI.

A couple of days later, he released HTTP::Server::Simple::PSGI, which is actually based HTTP::Server::Simple (which itself doesn’t depend on any non-core modules).

A few patches later, the standalone server was refactored and running on this new guy. That means when writing a Dancer app, you can now always rely on PSGI environment goodness, whereas you’re using the standalone server, or the Plack architecture. That just rocks, again kudos to @miyagawa.

Dancer::Request

The Dancer::Request class got also heavily refactored and enhanced, it can now provide the user with an access to the raw body of the incoming request (thanks to RasterBurn for the report).

By the way, this class needs still so more features, and I’m actively working on it. I may release Dancer 1.2 when I’m happy with that one.

Oh and it also now provides a complete documentation. POD FTW.

Dancer::Route

I also gave a shot at Dancer::Route, which has been recently patched to support some new features (prefix and conditional matching, thanks to Frank Cuny)

No more CGI.pm, really!

I also found that CGI.pm was still used in one very place for rendering and HTML page. This was a shame as we wanted Dancer to be 100% CGI.pm-free. Hence the patch that actually allow us to say it now, for REAL ;)

All of this freash meat is available on my GitHub repo and will be soon released to CPAN, under version 1.140. Stay tuned!

Tags: ,
Posted in Programming, The Void 1 Comment »

Dive into Dancer’s code: core and extensions

The discussion that is rising these days about frameworks and libraries reminds me I did not even take the time to talk about the last version of Dancer.
I should have, hence this post.

Last version of Dancer, 1.130, is the first version which is “plugin-aware”.
That means since 1.130 anyone can write their own template, logger or session engine and rock the app by just setting the appropriate value to the corresponding setting.

The plugins that existed before the split have been extracted from the core distribution in order to be shipped separately, that’s much clean and makes more sense that way:

If you have a template, logger or session engine you’d like to see in Dancer’s ecosystem, I invite you to take a look at the corresponding interfaces you have to implement, it’s pretty straight forward.

The concept is pretty easy, basically, here are the steps to follow to add a new engine:

  • choose a setting name that is available for template, session or logger, according to what you’re doing.
  • implement the interface of the engine you like (Dancer::Template::Abstract, Dancer::Session::Abstract, Dancer::Logger::Abstract)
  • Name your class with a camelized version of the setting name

Here is an example, let’s say you have a great template engine you’d love to use for rendering your views in your Dancer app, let’s name it “HTML::IronMark”.

  • First of all, create Dancer::Template::Ironmark which implements the interface Dancer::Template::Abstract
  • Then change the setting template to "ironmark"

And well, you’re done. This is pretty much the same job for logger and session engines.

Feel free to contact me if you want to write your own and need more precisions.

Tags: ,
Posted in Programming 7 Comments »

PSGI/Plack the ultimate Perl Web Server

Google has to realize like we all do, that Plack is the utlimate Perl Web Server.

The first slot will be hard to reach though, because of that sourceforge page which has “perlwebserver” in its hostname.

Tags: , ,
Posted in Programming Comments Off

Getting rid of CGI.pm in Dancer’s code

Yes, I finally took the decision to stop using CGI.pm in Dancer’s code. It was not an easy decision to take, mainly because of the following reasons:

  • it’s in the core (I’m a “less-CPAN-deps-ships-better” freak when it’s about Dancer!)
  • it provides a stable and well-known way of dealing with the HTTP interface (params, methods, path infos …)
  • and well, to add a third reason, why should I want to change it if it works?

Well, actually, we did find a bug recently in CGI::PSGI that prevented a Dancer app from being deployed under Plack::Server::Apache2. Oh, of course, the bug was almost instantly fixed when it has been discovered (the #plack people are really reactive).

But that enlightened something: CGI.pm is old, really old, and that means, when you’re using it, you take with you a lots of lines of code coming from years ago. Moreover it is well known that CGI.pm does addresses different matters, such as providing a request interface and generating HTML content as well. Conceptually, it sucks.

After thinking about all that, I decided to drop CGI.pm out of Dancer’s code. I then have the option to use the pretty fresh Plack::Request interface. It looks really nice and does exactly what you can expect from it.

But, it’s important for me that Dancer can be used without Plack. I want the dependency barrier to be as low as possible:
If a user wants to test Dancer, he should not have to install Plack in my opinion. If he likes it, and wants to goes on production, then yes, Plack is a must-go. He then installs Plack and goes on with Dancer’s app.psgi.

So depending on Plack::Request was one more dependency I’d rather not add to Dancer.

With all this in mind I came to the decision to write Dancer::Request, reading carefully the PSGI specs (miyagawa++ again).

It was all good except for processing the POST data. There’s so much work to do when it’s about multipart form, url-encoded form, or even file uploads that I chose not to push the “reinvent-the-wheel” thing too far, and I decided to copycat Plack::Request on this topic: using HTTP::Body.

This module does the job pretty well, with an object-oriented interface.

The conclusion might look like a failure (I rewrote something that worked by adding a new dependecy.) But deep inside I’m happy with this refactoring; because Dancer is now on a way where all of its code will be fresh, based on PSGI specs and won’t ever rely on CGI.pm to do something.

I hope Dancer’s users/developers will agree with that. feel free to comment on this post if you want to share your point of views. Yes, I know this might trigger a troll or two… ;)

Tags: , ,
Posted in Programming 4 Comments »

Dancer 1.100 released

A new version of Dancer has just been published on CPAN. It was a good time to do it, according to the changelog, as you can see:

    * Support for multiple method routes at once with 'any'
    * Templates engines
      + Bug fixes in Dancer::Template::Simple (Jury Gorky)
      + Refactoring of the factory
      + option for disabling the layout in the template helper.
    * New session engine based on encrypted cookies (Alex Kapranof)
    * More HTTP codes supported for a better REST compat (Nate Jones)
    * Documentation updates
    * script/dancer now requires an appname
    * New Makefile.PL with better metadata (CPAN Service)

I’m pretty glad to underline that this release is the first one where most of the changes are written by other developers than me, that’s really exciting to see more and more people involved with the project.

This release should also fix the test-suite which looks to be broken on most of the CPAN testers under version 1.000 (but sadly not on my workstation, so I wasn’t aware of it).

UPDATE Jan. 7th 2010 : The CPAN-testers reports show that 1.100 passes 100% of the tests under Linux and FreeBSD, that’s a good start!
Stay tuned for next dances!

Tags: , , ,
Posted in Programming 7 Comments »

Migrating homebrew Rails blog-entries to Wordpress with Perl

I was facing a challenge recently at work: migrating a bunch of blog entries stored in a Postgres database of a home-made Rails application to a Wordpress blog.

This challenge was trickier than you may first think because of the following reasons:

  1. I don’t have manual access to the Postgres DB, I can only run a Rails console that connects to it
  2. The Postgres DB and the Wordpress Blog are installed on two different servers that are not in the same LAN.

Here is how I did the job, of course, using Perl as my weapon was the only option I considered, and I’m glad of it.

First step : exporting the data, JSON FTW

As the only way I had to handle the data source was a Rails console, I chose first to use YAML for exporting the data into a file, but I wasn’t able to parse it with Perl then, because of badly-written multiline scalars (I don’t know whose fault it is, either Ruby or Perl YAML modules, but it didn’t work out of the box).

Then I tried JSON:

# dump_posts.rb (to be run with ./script/runner -e production)
posts = MyRailsPost.find(:all)
f = File.new("/tmp/posts.json", 'w')
f.write(posts.to_json)
f.close

I then uploaded the json file to my second server, where I have access to the Wordpress DB and started writing an importer.

From a JSON file to a Wordpress DB

Now I have my data in JSON format, I can write a Perl script that will parse it and insert each post item found in the Wordpress “wp_posts” table.

First, I’ll write a Coat::Persistent class to handle Wordpress blog posts:

package WPPost;
use Coat;
use Coat::Persistent
    table_name => "wp_posts",
    primary_key => "ID";

has_p post_author => (isa => 'Int', required => 1);
has_p post_date => (isa => 'DateTime', coerce => 1);
has_p post_excerpt => (isa => 'Str');
has_p post_content => (isa => 'Str');
has_p post_title => (isa => 'Str');
has_p post_name => (isa => 'Str');

sub BUILD {
    my $self = shift;
    my $class = ref($self);
    $class->dbh->do('SET NAMES utf8') or die $!;
}

Coat::Persistent->disable_internal_sequence_engine();
__PACKAGE__->map_to_dbi(mysql => "MYDATABASE", "DBUSER", "DBPASS")

Please note that we tells DBD::mysql to send data in utf8 (SET NAMES utf8), this is very important, if we don’t, we’ll endup in Wordpress with a mess of utf8/latin1 crap.

The post_date field will be set with Rails’ created_at attribute, and it might be in a different format than YYYY-MM-DD HH:MM:SS, so I’ll write subtypes and coercions to handle that cleanly:

use Coat::Types;
use Coat::Persistent::Types;

subtype 'DateTimeSec'
    => as 'Str'
    => where { /\d{4}-\d\d-\d\d \d+:\d+:\d+\.\d+/ };

subtype 'DateTimeWithTZ'
    => as 'Str'
    => where { /\d{4}-\d\d-\d\dT\d\d:\d\d:\d\d\+\d\d:\d\d/ };

subtype 'DateTimeWithT'
    => as 'Str'
    => where { /\d{4}-\d\d-\d\dT\d\d:\d\d:\d\d/ };

coerce 'DateTime'
    => from 'DateTimeWithTZ'
    => where { s/\+.+$//; s/T/ /; return $_ };

coerce 'DateTime'
    => from 'DateTimeWithT'
    => via { s/T/ /; return $_ };

coerce 'DateTime'
    => from 'DateTimeSec'
    => via { s/\.\d+$//; return $_ };

Now, I have all I need, I can write the scrit:

#!/usr/bin/perl
use strict;
use warnings;

# slurping my JSON file
open FIC, '< ', $ARGV[0] or die $!;
my @lines = ;
close FIC;
my $content = join '', @lines;

# processing posts
my $data = from_json($content);
for my $post (@$data) {

    my $p = $post->{rails_post_class}; # JSON output in Rails works this way

    my $wp = WPPost->create(
        post_author => 1,               # admin
        post_date => $p->{created_at},  # coercion will occur here
        post_excerpt => $p->{excerpt},
        post_content => $p->{body},
        post_title => $p->{title},
        post_name => $p->{permalink},
    );
    print "+ ".$wp->post_title." -> #".$wp->ID."\n";
}

Note: you can consider this post as the first-and-last item of my 2009 Perl Advent Calendar ;)

Tags: , , ,
Posted in Programming Comments Off

Dancer 1.000 is out!

Well, here it is, after five months of development, Dancer is stable and feature-rich enough to be released as a shiny, stable, 1.000 version.

Major changes for this version are the following:

  • Support for cookies
  • Support for YAML-file-based sessions
  • Support for Memcached-based sessions
  • Support for Syslog logging
  • Less dependencies than ever (only HTTP::Server::Simple and Exception::Class are mandatory to start writing a Dancer app)

The test suite has also been heavily enhanced, covering now more than 80% of the source code.

I’ve just uploaded the tarball to the CPAN, so expect it to be cpan-able in the next couple of hours.

I welcome very much feedback on this release, please feel free to give it a try ;)

Bugs reports are also welcome here.

Oh, and by the way, today is a special day ;-)

Tags: , ,
Posted in Programming 1 Comment »

Get Adobe Flash playerPlugin by wpburn.com wordpress themes