My point is, Perl is like water. It will fit in your bowl, whatever its shape. It’s a language that will reflect your way of thinking most than any other language. I know some Python developers that are pretty in love with their language just because of the opposite spirit: in Python, there should be only one good solution for any given problem. That’s what they like, and what comes together with this philosophy is a very strict language that forces you to be a good citizen.

I can understand that. Strictness is a very good ally for a developer. But I want my strictness. Not the one that comes with the box. The strictness of my programming should be as I want it to be, it’s personal, and if I’m in a team, it should be a set of rules everyone are aware of.

This is were, again, I’m very happy to use Perl.

A couple of weeks ago, at work, I wanted to set a strict Perl environment for my everyday needs. I ended up writing a pre-commit hook that has the following features:

• filter the code with PerlTidy
• prevent any commit that violates a Perl::Critic policy
• run the test suite with Devel::Cover and make sure the total coverage rate is not lower than it was before the commit

Of course, as I said above, I want my strictness, so PerlCritic and PerlTidy use respectively .perlcriticrc and .perltidyrc in the local directory, so I can tweaks the rules on a per-project basis.

After two weeks working with this hook, I realize that my code is now much more robust and very well tested (100% coverage is easy to reach when you start working on a project like that).

If anyone is interested in this commit hook, it’s on GitHub.

• Test the devel branch (which provides a new core and new features)
• Improve the documentation
• Improve the test coverage and reach 1k tests (we have 977 so it shouldn’t be difficult ;)

If you like Dancer and want to help, feel free to join us, this will hapen on irc.perl.org, chan ♯dancer, see you there!

Happy dancing.

I’m going to use that event as an opportunity to give my point of view on Dancer, this entry will be a reference for exposing the philosophy of the project.

1. Is Dancer a port of Sinatra ?

No. It clearly isn’t. It’s written quite everywhere in the documentation that Dancer was inspired by Sinatra. But the project clearly took its own path.

Don’t expect Dancer to be a Perl 5 clone of Sinatra, it isn’t and will never be. Dancer is a micro-framework, based on the concept introduced by Sinatra. But it provides features of its own, may do things differently and address other issues than Sinatra.

That being said, Sinatra has been a huge source of inspiration.

2. How is Dancer being developed?

Dancer quickly attracted lots of users. Lots of feedback received mentioned “a feeling a fresh air thrown in Perl5″ and we are very glad to see such support from our users. We give a lot of attention to users, we take every suggestion seriously and most of the time, a feature is added because the community itself agreed on the concept.

Dancer is clearly community-driven. As the project-leader, I make decisions when there is some kind of hesitation, but as long as an idea makes sense, I don’t see why I should refuse it.

Dancer is a young project: it’s going to be one year old in august, so we’re aware the code isn’t perfect. That’s why most of our energy is spent in refactoring and bug-fixing. The only priority for me is to release Dancer 1.2 which should be a rock-solid release.

Our code base is very well tested (we have near 1k tests, about 90% of code-coverage).

We are very pleased with the feature-set, our users don’t stop telling us they’re very happy with Dancer, and actually enjoy working with it. This is the best thing that can happen when you do free software: seeing that your work is enjoyed by others).
So, our priority is to make the whole thing robust and well-designed.

Once we have something like that, Dancer 1.2 will be out. And the beer will flow all the night. Yay.

3. How are planned the new features?

One of the attacks was about the fact we stole features from another framework, so I understand people can start thinking this is true.

Of course it’s not. And if it was, I would undestand that as a greeting to the related framework, anyways.

As I said in the section above, we plan our development mostly according to our user requests. Almost all of the issues reported on our tracker originate from our community.

Of course, when a good thing happens somewhere, we may start paying attention to it, like websockets. Some of our users asked for websocket support and we started investigating. I now understand it may look like we started stealing code (what does “stealing” mean if the code is public anyways?) but we’re not, we’re following our users, as we always did.

4. What’s Dancer philosophy regarding other Perl 5 frameworks?

We are definitely Perl lovers. That means we truly think that there is more than one way to do it. Dancer is one way to go. If you don’t choose that way, that’s perfectly understandable, maybe it lacks a feature you have in another framework, maybe you don’t like Dancer’s syntax, whatever the reason, we understand we can’t be the only way to go.

But we know, on the other hand, that Dancer addresses one way to do web development, and it clearly looks like lots of people like that way.

We think that having many frameworks out there is a good thing for Perl 5, and a sign of vitality of the language. We want nothing more than a peaceful cohabition between Perl 5 frameworks. That’s why we don’t think that attacking another framework is a smart thing to do, we don’t see why we should be aggressive if we’re pleased with our project.

We do think that friendly competition is better and let good ideas flow between different implementations.

Let me end this article with Tolkien, in a poetic way:

Three Frameworks for the Elven-kings under the sky,
Seven for the Dwarf-lords in their halls of stone,
Nine for Mortal Men doomed to die,
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.

One Language to rule them all, One CPAN to find them,
One PSGI to bring them all and in Plack bind them

Don’t forget, enjoy your code. Whatever happens.

• We started the meeting by demonstrating how Dancer and Plack middlewares can be powerful and easy-to-use. We did a live demo of a scaffolded Dancer app configured to run with Plack::Middleware::Debug. That was neat. Just editing the config file allows you to enable and disable middlewares, you don’t even need to know about Plack::Builder, Dancer does all the black-magick for you. I ended the demo by showing how to get all your logging messages in your Firebug console thanks to Plack::Middleware::ConsoleLogger and Dancer::Logger::PSGI. That was a piece of cake:
  1. $ sudo cpanm Plack::Middleware::ConsoleLogger Dancer::Logger::PSGI
  2. in config.yml :

     logger: "PSGI"
     plack_middlewares:
       - ConsoleLogger:
     

  3. restart the app with plackup

  And that was it. Impressive :)

• We talked about the implications of supporting mountable Dancer applications inside Dancer’s core, in order to fix the whishlist item #82. We all agree on the fact that this would allow lots of good things (like generic reusable application bricks); but the rewrite needed is massive. We may wait for 1.2 to be released before starting wroking on that.
• We plan to write three articles for “Linux Magazine France”. The money earned by those articles will be spent in a pro GitHub account. The first article to be written is an introduction to Dancer, the second one should present PSGI/Plack and the third would explain how to use Dancer with Plack middlewares.
• Franck plans to work on an asynchronous handler so Dancer can be non-blocking. This would allow support for websockets.

Next meeting will probably occur in september as we may be very few in Paris during august.

The first meeting takes place this evening, in order not to come with empty hands, I’ll write down here a list of topics I’d like to discuss with the team:

• “Linux Mag” articles : Franck and I have planed to write a serie of three articles about Dancer and Plack for the french “Linux Magazine”. I already have a first draft of the first article
• Dancer 1.2 release : discussions about plans, key-feature, and maybe a timeline for the next major release of Dancer.
• What about the mountable feature ? A recent whishlist item was posted to our issue tracker, the idea is pretty interesting, but implies a major rewrite of Dancer’s internals. Should we open a new branch where Dancer’s core willm be basically rewritten?

Stay tuned for the report…

my Perl Dancer talk (update)

Now that Slideshare has finally processed my slides, I can embed them here, enjoy.

BibLibre, Dancer and authentication middlewares

First of all I’ve met Marc Chantreux who works for BibLibre and wants to use Dancer at work.

Marc is looking for the good way to implement an authentication layer for his Dancer app. Looks like the way to go is with a Plack::Middelware. Indeed, Franck Cuny explained us that middlewares are a really great way to address this kind of feature. That way the authentication layer is separated from the application. Thanks to his Dancer::Session::PSGI, this could be done really easily.

I’m really glad Marc and his company give so much interest and trust into Dancer, I’m pleased to see such things happening and I’m going to give them as much help as I can in their daily needs with Dancer.

Not to mention that Marc already contributed an interesting patch to Dancer’s code, providing better pattern matching and named-captures support in our route handlers. He also appeared to be very motivated and had plenty of ideas and questions regarding Dancer’s development. I’m sure he can become quickly a regular contributor to the project.

About WebSocket support in Dancer

I’ve talked a lot with Franck about Dancer, that was really interesting to met him in real life for a couple of days and share ideas and remarks regarding our code.

I’ve asked him about websocket support and it appears that it’s “just” a matter of having a non-blocking “request handler”. Dancer is not currently non-blocking, unless you choose to deploy with Plack and Twiggy. What we plan to do is to provide a third handler, named Dancer::Handler::Async which would depend on Twiggy and would force a non-blocking context. But we have to investigate more prcesiely that. Franck is willing to dig in that direction, so maybe we can have more to say in a month or two.

A Dancer implementation in Perl 6 ?

After my talk about Dancer – you can grab the slides here – I’ve been at a Perl 6 workshop that was handled by Martin Berends. We first started to install rakudo and he showed me some Perl 6 stuff. Then we ended up talking about … well, guess what, Dancer :)

He was very excited about the project. He then suggested the idea of a Perl 6 implementation. Martin already implemented an HTTP::Daemon module for Perl 6, and I suggested to look at HTTP::Server::Simple::PSGI which would be the very first dependency Dancer would need. That would be awesome to have Dancer in Perl 6, wouldn’t it?

Well, I hope I don’t forget anything important to say in this report, the event was great, and I should stop writing now and go take some rest :)

Happy hacking.

That’s why the design of our website is not as shiny, webbish and cool as it could be. At first, we were thinking at raising some money via donations for paying a profesionnal designer. But quickly some people volunteered here and there, and the idea to build a new design on goodwill did fit better the Free Software philosophy than paying someone to do it.

Today, more than 3 people volunteered to submit a proposal, so this gave me the idea to run a contest, let me explain what I have in mind:

The contest is to build a complete new visual identity for the Perl Dancer project. There are 3 categories in the contest: Website design, Logo, Web Banner for dancer-powered websites.

Here are the instructions a proposal must follow to be accepted:

• The artist is totally free regarding colors, visual elements, logo and CSS techniques.
• The following baseline should be visible: The easiest way to write web applications with Perl
• If any visual element is added to the design, it should recall the idea of one or more of the following concepts: Lightness, Easiness, Extensibility

Here is how to submit your proposal:

Update

After some feedback I’ve received, I’m now aware that asking someone to submit a full, finished project on the off chance that it might be used, is a bit unfair. It’s indeed a lots of work to polish the design completely. So I’m now changing the conditions for accepting a proposal: any design can be submited as a static HTML file, or as a screenshot.

This will be enough to let users vote. That way, the designer will work on all the details when they know they’ve won the contest.

First, install Dancer in order to be able to run your website clone locally:

$ curl -L http://cpanmin.us | perl - Dancer

Then create an account on GitHub if you don’t already have one.

Fork the perldancer-website project and clone it:

    $ git clone YOUR_FORK_URL
    $ cd perldancer-website

You can now work on your design by editing views and see your changes by running the dancer script:

$ ./perldancer.pl
>> Dancer server 527 listening on http://0.0.0.0:3000

Open a browser at http://localhost:3000 and see your design in action with the real website content. That’s how we dance ;)

When your design is ready for a proposal, make sure you’ve commited all your changes and push to your fork. Then ask for a pull request:

$ git push origin master
...

Note that there is no deadline yet, but we could choose one soon.
As soon as we have enough proposals, we’ll be able to open a vote for electing the winner.
All dancer users will be allowed to vote, this will probably happen on the users mailing list.

Please fire up your beloved cpanminus and try it out.

This release provides some new features such as new logging facilities, better filters and plugins support, complete documentation cleanup and of course, has many bugfixes as we can manage to commit.

The next major release will be 1.2.

Note that the French Perl Workshop 2010 is coming very soon and that I’ll give a talk there about Dancer.

UPDATE If you upgrade to 1.18, please make sure you’re aware of Issue #69 (Expect 1.1801 to come soon for fixing this issue).

Dancer – Bootstrapping a website

Since my review last week, a couple of new releases of Dancer hit the CPAN claiming to fix installation on Win32. Just to prove it, I’ve done this week’s testing on my conference presentation laptop instead of my desktop machine.

Dancer installed first time cleanly on the new machine. And the hello world script from last week runs correctly. So all good there.

The first round of the contest put some light on something we weren’t aware of: support for Win32 environments. Indeed, none of the core developers of the project are Windows users. We did work last week on that, and started a basic-yet-strict QA procedure to avoid test regressions.

Our GitHub repository is now splitted into two main branches: master is dedicated to prepare CPAN releases. Only documentation, packaging and bugfix commits are allowed there. New features are developed in the devel branch, and when we want to release a new major version of Dancer, we’ll start by packaging some DEVELOPER releases from the devel branch before merging it into the master branch.

So we now have a sane development/release cycle, thanks to the packaging/QA issues enlightened by Alias’ first report.

After a more-complete-than-last-week read through the main Dancer search.cpan.org page one thing jumps out quite sharply about the Dancer API in general. And this is that it isn’t object-oriented, which is something or a rare thing these days.

Indeed, this a choice that goes in the same way as Sinatra does: provide powerful, expressive and intuitive syntactic sugar to the end user to avoid as much as possible administrative code. This is – if you ask me – one of the best idea of Sinatra, and I clearly want it to be a key-feautre of Dancer.

Or at least, it doesn’t LOOK object-oriented. Judging from the distribution page there’s plenty of classes and I’m sure the internals are all done largely in an OO fashion.

You’re absolutely right, everyting inside Dancer’s internals are made in an OO fashion, Dancer::Object is the base-class of every object you can find, and some abstract class are also heavily used for engine (see Dancer::Engine, Dancer::Template::Abstract or even Dancer::Session::Asbtract if you want to see some examples).

This is also for this reason why I chose to provide access to the params and request objects through function calls, rather than forcing the user to unroll @_ in the route handlers:

For instance, this route handler…

get '/' => sub {
    my ($request) = @_;
    $request->params->{foo};
};

…becomes with Dancer syntax:

get '/' => sub {
    params->{foo};
};

So yes, Dancer is a DSL and it’s a major design choice behind the project (so don’t expect it to change in the future).

The main API that you get with “use Dancer” sports a similar kind of “Do What I Mean” command interface that reminds me a bit of the Module::Install command interface.

This means that the code to show the index template is going to look like this.

get ‘/’ => sub {
    template ‘index’;
};

I’m not entirely sure what I think about this idea, despite the fact that I’m the maintainer of M:I and created it’s Domain Specific Language inteface. This kind of thing usually raises red flags.

I can see this API strategy either descending into API chaos or becoming one of Dancer’s best and most loved features. Or quite possibly both depending on the scale of the project.

For the moment, given Dancer is meant to be taking a micro-framework approach (which should be optimised more for small websites) I’m willing to suspend my disbelief and run with it until I can make a better judgement.

Well, considering the success of Sinatra, I won’t reconsider this API choice, this to me one of the key-feature of micro-framework: allowing expressive-yet-powerful syntax. If you have to deal with objects everywhere in your application code, you can’t have the benefits of lightweight DSL syntax.

The documentation in general is oddly structured. For a command-oriented API like this I would expect to find documentation for each of the available commands. This section of the documentation does exist, but it doesn’t contain a list of all the commands.

Instead, some of the commands are described down in sub-headings related to a logical area instead. And if you look at the table of contents on the search.cpan page the logical grouping doesn’t appear very, well, logical.

There’s some other indications the documentation has built up in bits and pieces rather than being addressed in a complete fashion. Some features are glossed over quickly, leaving me a bit stumped still. Other go into way more detail than is needed for a small website to the point of information overload.

Yes, we’re totally aware of that, and we started a complete documentation rewrite in the development branch.

We target a full and complete rewrite of the docs for the next major release: 1.2. When this rewrite is complete, we’ll have the following documentation structure:

• Dancer : evry syntactic keyword will be documented here, this will be the documentation of all exported symbols
• Dancer::Tutorial will provide the user with concrete, step-by-step example in order to start working with Dancer
• Dancer::Cookbook will be a good assistant for anyone who wants to solve common issues you can face when developing a web application
• Finally, Dancer::Deployment will provide help and configuration examples for deployment issues, most of the time involving Plack and webservers

The section on config files seems to suggest I should make three config files, a global config and then a pair of development/production config files that overlay the global. And these files go in different directories for some reason, unless I “put it all at the top of the program” (without saying how I embed this YAML in the program). A bit later on I realised they meant embed via the “set” command.

This is an idea that comes from Rails, which I like and decided to port into Dancer’s conventions: You can set common and global configuration in a single file (here named config.yml. But if you want to be able to switch between different configuration contexts easily (like development to a production) then you can use environment configuration files.

When starting your Dancer app, you can choose which environment you want to enable, dancer will then first load the config.yml file, and then the environment-specific one.

This is pretty convinient for switching log levels, or even the strictness of the code. But again, all of this is optional, you can go without configuration files, putting all your settings along with your code, using – as you spoted it – the set keyword.

Overall, I think the documentation is reasonably thorough but just needs some love to clean it up into a more learning-friendly structure, with some sections shrunk down in the main Dancer page to just the most basic and common uses and references out to other pages for using more advanced features.

As I said above, this is a work-in-progress in the devel branch and should be released, if not with 1.18 (the next stable release), with 1.2.

Stuck on something I wasn’t sure about, I resorted to running the built in skeleton generator (mentioned prominently on the Dancer::Cookbook page) to at least get a better idea of what I was supposed to be doing.

C:\Users\Adam>dancer -a top100
+ top100
+ top100\views
+ top100\views\index.tt
+ top100\views\layouts
+ top100\views\layouts\main.tt
+ top100\environments
+ top100\environments\development.yml
+ top100\environments\production.yml
+ top100\config.yml
+ top100\app.psgi
+ top100\public
+ top100\public\css
+ top100\public\css\style.css
+ top100\public\css\error.css
+ top100\public\images
+ top100\public\404.html
+ top100\public\dispatch.fcgi
+ top100\public\dispatch.cgi
+ top100\public\500.html
+ top100\top100.pm
+ top100\top100.pl

For a few seconds this shocked me, because compared to the simplicity of helloworld.pl this is a lot more files.

Well, I understand it can shock you if you expect to build your app with only one Perl script, but wait, you’re asking the scaffolding script to… well scaffold something! :) So yes, it creates a full-featured application skeleton, and that’s what it’s designed for.

We could imagine some kinds of scaffolding-levels maybe though, in order to let the user choose which features they want in their scaffolded application.

At this point I hadn’t even remotely considered the idea of site-customising my error pages, and there’s 5 entirely different types of Perl application files in this list. I (newbie me) don’t even know what PSGI is, let alone why I need one. And don’t get why I have a dispatch.cgi in addition to my top100.pl script.

Frankly, I don’t even really WANT to know what all these things are (yet?). But this did at least confirm where all the files should be living and the demo app did actually start and run properly. So in my case, it solved the problem I needed to solve.

But I certainly don’t want to use it as the basis of my Top 100 site. It’s just a bit overwhelming for my level of experience, and I don’t want to have to go exploring and work out what all these different files do, so I know which ones are safe to delete.

Well, the scaffolding tool is here to makes your life easier if you want to build a full-featured application with Dancer. So yes, it provides you with any file you might need for Plack deployment, layout design, and error pages customizations. It’s designed for that actually.

Templating was largely straight forward, mostly because the docs do everything to steer me towards Template Toolkit short of installing it for me (yes, you have to install Template Toolkit yourself to get the generated skeleton website working).

I suspect the reason for this is because their embedded default templates are not PARTICULARLY featured. The documentation sums up the feature set of the built in templates as the following.

< % var1 %>

No other features are described, making Template Toolkit the obvious choice.:)

Indeed the default template engine that comes with Dancer is utterly limited, and that was also a choice. If the user wants complex template support, they have to upgrade to a powerful template engine, and CPAN has plenty of them.

I’m totally fine with this, but what I’m not entirely sure about is why on earth they have chosen to make Dancer’s default tag style for Template Toolkit different to Template Toolkit’s default tag style for Template Toolkit.

The only reason I could uncover from the documentation is that it makes TT compatible with their built in template engine. The one whose list of features is “variables”.

The only other guess other than “we like it more that way” I can make are that it’s done to be compatible with Sinatra, the Ruby toolkit I’ve never heard of but which I’m told was the inspiration for Dancer.

Yes, I must say this was a bad idea, my fault here. At the very begining of Dance’s development I was really in the idea of porting Sinatra into Perl, and I thought it should be a good idea to use the same template tags as they do in Rubyland. Time said it wasn’t, as every Perl developer expect TT to use [% %]. So we might consider going back on this, in the future, but that would mean some backward compatibility issues, which is something I want to avoid.

Switching it back to regular Template Toolkit tag style requires a slightly annoying block of config file entries I can easily imagine myself repeating in every Dancer program I will ever write.

To help you in gauging my annoyance level on this topic, allow me to show you now the complete working Dancer application at the end of this week.

#!/usr/bin/perl
 
use Dancer;
use Template;
use CPANDB {
    maxage => 3600 * 24 * 7,
};
 
# Configuration block
set template => ‘template_toolkit’;
set engines  => {
    template_toolkit => {
        start_tag => ‘[%',
        stop_tag  => '%]‘,
    },
};
 
# Route block
get ‘/’ => sub {
    template ‘index’;
};
 
dance;

Well, you could have put that in config.yml. But I agree with you, this is too much configuration for making Dancer behaving “the default TT way”. We should fix that I suppose.

It’s not a problem as such, but I’m sure it’s one of those things that’s going to niggle at me. If I wasn’t trying to emulate a newbie, I’d probably switch over to the Template::Tiny plugin in the short term. Unfortunately, it’s not particularly well known and so is probably out of bounds for this competition.

Given their strong preference for Template Toolkit, in their situation I’d probably have inlined the entire Template::Tiny package as the “house template” engine. Then you still have a direct upgrade path when people hit a feature T:Tiny didn’t support but you get to keep the default tag style. But the current predates Template::Tiny, and so be it.

I also had a momentary confusion over whether I should call my template “index” or “index.tt” or “index.html” or “index.html.tt”, but I put that mostly down to playing with Mojo’s double-dotted templates (which I’ll get to later). A quick look at the generated skeleton made it pretty clear what the naming is.

In the future, I plan to let template engines define their template extensions. So it will be less confusing for the user.

Adding the static files was very simple and easy to understand, following the convention of “if there’s a “public” directory, everything in it is a static file”.

However, I did hit a problem when I tried to add my logo image.

Weirdly, although my Dancer application was happily sending me css and my favicon.ico file, it didn’t appear to support PNG images. Bemused, I placed my first (legitimate) visit to the #dancer channel to ask a What The Hell.

Dancer uses MIME::Types under the covers, and the bug only happens on Windows, and they confirmed they can replicate it. Beyond that there’s no more information yet, but I’ve worked around the problem temporarily on my Dancer application by converting the PNG files to GIF.

And given the speed with which they chased down the previous Windows problems, I’m hopefully that by next week the problem will have gone away.

Indeed, I think we’re doomed with Windows environments ;) We have a lead though on this PNG-Win32-IE-only (!!) issue, and we coudl imagine it’s fixed by the next round, hopefully.

[...]
Overall, the process was relatively straight forward with the exception of the PNG problem and a general feel that the documentation/tools dump you in the deep end a bit too quickly and need polishing.

So as I understand it, no major issue there, except for the overkill configuration needs to get TT behaves as you expected. The documentation is being completely reorganized for the next stable release and we should fix that PNG issue pretty soon.

See you next round, and happy dancing!

Franck will also speak about Plack so we can imagine we’ll have interesting time speaking about state-of-the-art web development.

I think my talk will be divided into two parts: an introduction to Dancer first, covering all of its core features (basically a refresh of my previous talk about Dancer); and a second part dedicated to cover all the new stuff we’ve been working on since we opened the development branch. This last part will be a teaser for the upcoming version 1.2, actually.

Oh, and as a bonus, we may unveil the official Dancer logo during the talk, if it’s ready ;)

See you there!