I will press many keys on my keyboard causing an implementation to occur.
The schedule for OSDCfr has been published last night.
My talk about Dancer will take place saturday afternoon, just after Ingy döt Net‘s talk about YAML, TestML and C’Dent.
Ingy is the special guest of OSDCfr, he’s one of the YAML authors and is involved in many projects regarding programming languages.
It’s quite impressive to speak just after him, I hope I won’t look too amateur ;)
Now it’s time to start working on the slides!
Posted in News
Last night on IRC:
03:01 < @stevan> sukria: I always think of William Gibson when I see Dancer uploaded
Wow, stevan pointed to me that dancer is the name of a drug in a scifi novel written by William Gibson: the Bridge Trilogy:
In William Gibson’s Bridge Trilogy, dancer is an addictive drug used in the near future setting. The books take place in a semi-dystopian future, and a properly noir drug is needed to make the setting complete.
That’s funny, I did choose that name for my microframework because of the flexibility and the grace of a dancer. I wanted the resulting webapp to wave and handle requests like a dancer does with her partners in a ballet. But well, I wasn’t aware of that! Dancer is a drug in a fictional world, that sounds both weird and exciting.
So I wasn’t aware of it, but what I did put to CPAN was actually … a webapp booster !
Posted in Programming
I’ve finished to polish the error catcher I was working on and thought it was a good idea to push it to CPAN. I did so a minute ago, expect it to be indexed by CPAN within the next hour.
The major feature of this new release is the error catching, let’s take a glance at that and see how Dancer now handles the nasty web errors we are so afraid of:
Let’s start by creating a new application from scracth, that’s very easy now thanks to the helper:
$ dancer -a NightClub + NightClub + NightClub/views + NightClub/views/index.tt + NightClub/views/layouts + NightClub/views/layouts/main.tt + NightClub/environments + NightClub/environments/development.yml + NightClub/environments/production.yml + NightClub/config.yml + NightClub/app.psgi + NightClub/public + NightClub/public/css + NightClub/public/css/style.css + NightClub/public/css/error.css + NightClub/public/images + NightClub/public/404.html + NightClub/public/500.html + NightClub/NightClub.pm + NightClub/NightClub.pl
The NightClub application is now created and is already working:
$ cd NightClub/ $ ./NightClub.pl >> Listening on 127.0.0.1:3000 == Entering the development dance floor ...
That’s good, but here we want to brutalize a bit the application in order to trigger an exception, so let’s do some buggy code in the main route handler of NightClub.pm
package NightClub;
use Dancer;
use Template;
get '/' => sub {
Travolta->dance;
template 'index';
};
We call the Travolta module, but hey, it hasn’t been imported yet, Perl won’t like it.
After restarting the application, we can see that output. Dancer shows us the catched error message, the source code from where it was sent, the caller stack and dumps out all the settings and environment variables.
This is pretty handy in development phase, but we clearly don’t want to show that to the real world when our application will reach a production phase.
Not a problem at all, Dancer supports environements: it loads a YAML file for settings initialization at startup, that file depending on the chosen environement. If not specified, the environement is the “development” one, so environments/development.yml gets loaded.
In that file, the setting “show_errors” is set to true, hence the error output show above. But in the “production” configuration file, guess what, show_errors is set to false.
If we run the application in production environement…
$ ./NightClub.pl -e production >> Listening on 127.0.0.1:3000 == Entering the production dance floor ...
… we get that output, which is clearly less chatty than the previous one.
Of course this is the default error page built on-the-fly by Dancer. If a file public/500.html exists, then Dancer will use it instead.
Now that errors are correctly handled, I will focus on the session/cookies support and then, will be close to release 1.0 \o/
Posted in Programming
When you’re writing a webapp framework, everything is important, because what you want is that your framework is as easy as possible to adopt.
That means, quite everything you implement should play in that direction, you have to make the life easier for the end-user, eg the web developer.
These daysnights, I work on writing a cool and extensible error catcher for Dancer, I want it to grab all errors or warnings and display them as informative as possible. The last item I wanted was to display to code region where the catched error did occur.
Perl did give me already the error message, the file and the line, what remained to do was to read the file and display to revelant part of it.
As a picture is better than a long story, please take a look at that screenshot.
The git commit is on the way ;)
Posted in Programming
EDIT : This is going to change as soon as CGI::PSGI is available, the “patched CGI” way won’t be needed anymore, see miyagawa’s post for details
Now that Dancer 0.9904 is released, I’ve took the time to upgrade my Dancer configuration for the official website from a proxy_balancer configuration to an Apache2 + PSGI/Plack architecture.
Here is how to proceed if you like to power your Dancer app up with Apache and PSGI/Plack.
First of all, you need Plack, at the time of this writing, it’s not yet in CPAN, so you should go to miyagawa’s place. Grab also his patched version of CGI.pm. Install both of them and you’re ready to continue.
Next step is to make sure your app is ready for a Plack run, the best thing to do is to run the helper that comes with 0.9904, it will write all the files needed in your application directory if they’re not already present.
Here’s all the files you should have:
$ dancer -a mywebapp + mywebapp + mywebapp/views + mywebapp/views/index.tt + mywebapp/views/layouts + mywebapp/views/layouts/main.tt + mywebapp/environments + mywebapp/environments/development.yml + mywebapp/environments/production.yml + mywebapp/config.yml + mywebapp/mywebapp.pm + mywebapp/mywebapp.pl + mywebapp/app.psgi + mywebapp/public + mywebapp/public/css + mywebapp/public/css/style.css + mywebapp/public/css/error.css + mywebapp/public/images + mywebapp/public/404.html + mywebapp/public/500.html
Note that your route handlers should be defined in mywebapp.pm, and not directly in the standalone server mywebapp.pl.
You should also have an app.psgi file in your application directory.
Make sure everything is allright by running the standalone webserver:
$ ./mywebapp.pl >> Listening on 127.0.0.1:3000 == Entering the development dance floor ...
Ok, now run it with Plack’s standalone server, to make sure the PSGI file is ok:
$ /path/to/Plack/scripts/plackup & $ curl -I http://localhost:8080/ HTTP/1.0 200 OK Content-Length: 0 Content-Type: text/html
Great, you’re ready to go. The last step is to mount the application in your Apache configuration, for instance with a VirtualHost:
<VirtualHost webapp.domain.com>
ServerName webapp.domain.com
DocumentRoot /srv/webapp.domain.com/public
<Location />
SetHandler perl-script
PerlHandler Plack::Impl::Apache2
PerlSetVar psgi_app /srv/webapp.domain.com/app.psgi
</Location>
</VirtualHost>
Restart Apache and enjoy your dances.
Posted in Programming
I’ve just published a new version of Dancer. It’s basically a PSGI/Plack support release but also provides a new piece of sugar: the bootstraping helper.
One can now create a new application from scractch with a single command, as explained on the website.
A big thank to Tatsuhiko Miyagawa who helped me when I was working on the PSGI/Plack support and to Sebastien Deseille who worked on the helper script.
Next step is to write some documentation about the Apache/PSGI integration and prepare the slides for the upcoming OSDCfr event where I’ll be talking about Dancer.
Posted in Programming
Unit-testing is the way to go in modern programing. When you’re at writing unit tests, chances are that you will eventually need the so-called mock objects.
You can find a pretty good definition of Mock objects here. In Perl, writing Mocks can be done with Test::MockClass and Test::MockObject which are pretty complete modules for that purpose.
However, I’ve came to gugod’s blog and found out his post about Mocking in Perl. I like his post and find his conclusion pertinent:
However, I still want my test program reads as simple as the rspec statement, it reads better. The most important of all, you don’t really need to know the whole pros and cons and the concept of “Mocking” to do it.
Hence I’ve been thinking at a module who could be named Test::Mocker – or even Test::EasyMocker – and who will be usable like the following.
use Test::Mocker 'Player'; Player->should( run => 42);
We could also imagine a more complex mock with a sub instead of a constant value:
use Test::Mocker 'Player';
Player->should( run => sub { return 42; });
As you can see, when importing Test::Mocker, we give it a list of packages we intend to mock in the test, that provides them with the “should” static method.
I like the ease of use of that syntax and find it pretty natural to write; I’d be happy to read your comments on this.
Posted in Programming
It was the first time I went to Lille’s “Braderie” and I must say the atmosphear was pretty warm. It’s like the whole city is turned into a giant market place for 48 hours.
Everywhere you can buy stuff (that’s the main purpose of it), eat the traditional meal: mussels and french fries and -of course – drink beers. There are also a couple of music bands, here and there playing some famous covers.
Here is a quick set of pictures that will show you in one glance what is meant by the two words “Braderie” and “Lille” ;-)
See you there next year ;-)
Posted in Uncategorized
Dear lazy web, this is my first attempt at publishing a selection of links I’ve recently bookmarked. Those links came to my attention mostly thanks to my twitter account. I’ll try to publish such a list every week (on sundays). Feel free to suggest me links either via Twitter or through this blog (comments are welcome).
If a topic emerges from all the links I’ve bookmarked, I’ll put it in the title of the post, like you can see, this week, the trend topic is “Security”.
So here we go, happy links and if I give no news until then, have a good week.
Apparently this weekend, a major exploit attack has been taking place on old versions of self-hosted blogging platform WordPress. If you are using WordPress for your blog, you should update immediately.
Once his blog has been exploited, a wordpress user doesn’t feel safe anymore. A discussion takes place in Friendfeed between him, Matt Mullenweg (WordPress author) and others…
Matt Mullenweg – WordPress author – writes some advices to keep your WordPress blog safe from exploits. “Upgrading is taking your vitamins; fixing a hack is open heart surgery.” he says.
What if designing a web site was like a Samurai fight? Then Samurai’s good practices should apply to web designers: “Matters of great concern should be treated lightly. Matters of small concern should be treated seriously.”
The Capslock key : an appropriate demotivator
Mozilla is going to check the version of installed Adobe Flash plug-ins and warn users if it discovers an outdated version with potential security holes. [...] Just recently, a study confirmed that 80 per cent of users surf with a vulnerable version of Adobe’s plug-in.”
Posted in Uncategorized