Habemus Strehler!

Well, i worked a lot about it behind the scene, so i'm now a little excited to talk about Strehler, my most complex Perl work.

Link to github first: https://github.com/cym0n/strehler

As the README says, Strehler is a light-weight, nerdy, smart CMS in perl based on Perl Dancer2 framework. The story of his creation is very simple: I had to create a website (well, more than one) and after I decided to use Dancer2 I also decided to write the backend interface for it once for all, developing a tool easy to install on any type of webapp you need and with a lot of customizations available out of the box.

Strehler implements just the standard CRUD needed for a standard site. It can create articles, upload images, organize things  with tags and categories. I said more about it in the github wiki.

In my opinion the software reached enough stability to deserve version 1.0.0 tag. My hope now is for people to download it, try it and tell me where I'm wrong thinking this. At this point of development Strehler needs to be seen by fresh eyes, this is the reason i'm announcing that with so much emphasis.

You can try Strehler, you can use it, you can just find something you don't like and tell me. If you like collaborative work or if you think that Strehler can be what you need with some modifications, just work on it. Code is open and the git repository is there to be used. If you need some advice about how to improve the tool, try the TODO page. It's there for me as for everyone ho like to develope using Perl.

Strehler is ready! Cheers!

Ballroom Blitz (2)

Silence in the library

When you write a perl program you don't need just the perl interpeter, but also a lot of libraries that someone else wrote. It's easy to fetch them while you're in your developement environment, but when you go to production you have to manage a lot of issues about this problem.

First of all, there's the scenario where you don't have root access for the system where you are so libraries installation appear to be an impossible task. 

A worse scenario is the one where you have root access and you install the libraries directly in the system.

The worst case scenario is the one where you're installing things in the system, the system die and someone behind you start hitting you with a club. No, the problem is not the one with the club, the problem is you. The club is the solution.

Never do installations at system level. System level is just for... the system, the libraries installed that are the libraries need by your OS, not the libraries you need for your site. In many years of developement and deployment  people found many ways to do things better.

The article I linked last time, for this task, uses perlbrew, one of the best practices for that. Perlbrew manages not only libraries, but also perl version, so it can also be used to ensure that the bizarre incompatibilty between 5.16.0 and the cutting edge 5.18.0 is not an issue because you will configure on your machine just the version that works.

But timtowtdi so in this article I'll speak about probably the oldest practice about managing libraries, the oldest but still useful, clean and sharp: local::lib.

local::lib is a library that you have to install at system level:

(as root) cpan -i local::lib

 after that you'll have the power of playing with perl libraries just moving directories. Remember the directory where we decided to place our site, /var/www/com/example/my/?

Create under this directory a directory env and then a file named perl_sandbox with these lines:

libdir=/var/www/com/example/my/env
export PS1='\[\e[1;35m\]\u@\h:\w\$\[\e[0m\] '
eval $(perl -I$libdir -Mlocal::lib=$libdir)

Now source the file:

source perl_sandbox

This way your shell will become pink (the export PS1 line) and all the operations you'll do about perl libraries will have effect just on the env directory. However, with the perl_sandbox active, every perl command you'll use will see the libraries in the env directory.

Just a last tip: remember to install cpanm

cpan -i App::cpanminus

and use that for installations, with --notest option. Life is too short to let cpan to check all the repository every time you need an environment.

Up to the plack

Plack is a server used to run PSGI applications. PSGI is a interface that we can use to communicate with the webserver that will bring our site on the World Wide Web, so Plack is something we really need to make things work.

Talking about this issue, working with Dancer makes thing really easy because the standard bin/app.pl script that run your webapp can be used as is as a PSGI startup file, as the Dancer2 Deployment page says.

bin/app.pl script must run under a perl web server supporting PSGI. My favourite for this is starman (yes, I like David Bowie, but it's not just for that).

Copy&Paste from Dancer2 Deployment page how to run plackup and make your site works, however, is not enough for something that will need maintenance in the future.

The last piece of the puzzle is Server::Starter, a perl module that provide you the start_server script that will change you plackup server in a daemon (Argh! WItchcraft!), making easy for you stop/start procedures and monitoring.

After installing that module and after creating a /tmp directory under our site directory, you can try THIS copy&paste:

WORKINGDIR=/site/directory
PROJECT=/where/bin/directory/is

source perl_sandbox #as seen in the previous paragraph 

          cd $PROJECT

start_server \
--pid-file=$WORKINGDIR/tmp/starman.pid \
--status-file=$WORKINGDIR/tmp/starman.status \
-- \
plackup -E ec2 -s Starman --workers=2 -l $WORKINGDIR/tmp/plack.sock -a bin/app.pl & 

as your start_server script.

And this as last command:

start_server \
--pid-file=$WORKINGDIR/tmp/starman.pid \
--status-file=$WORKINGDIR/tmp/starman.status \
--restart

For restart.

For the timtowtdi section, take a look at Daemon::Control for an alternative implementation of the daemon. For a PSGI webserver general purpouse, one of the most used technologies of these days is uWSGI.

Gentlemen, start your NGINX

Last step is the easiest one. NGINX is just a proxy from the internet to your plackup structure. NGINX and Plackup will communicate using the plack socket that we configured in the start script: /my/site/dir/tmp/plack.sock. Obviously we're talking about an environment where Plack and uWSGI are on the same machine, otherwise you'll have to sail for the TCP/IP, as everything on the network.
Let's see nginx configuration:

upstream siteplack {
  server unix:/your/site/directory/tmp/plack.sock;
}

server {
  server_name www.yoursite.com;

  access_log /your/site/directory/logs/www.site.it_access.log;
  error_log /your/site/directory/logs/www.site.it_error.log;

  root /your/site/directory/project/src/public;

  location / {
    try_files $uri $uri @proxy;
    access_log off;
    expires max;
  }

  location @proxy {
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://siteplack;
  }
}

Few things to say. The public directory of the Dancer2 project should be server directly, because DancerApp has nothing to do with static things like css and javascripts. All the others things are just to copy and paste.

Restarting NGINX, praying all your gods, if all you did was did well your site will rise.
If not probably it will be my fault writing something wrong in here, but I'll be too far from you to be blamed. Just solve your problems and tell me how to fix the article. Comments are there for this reason.

Database around the clock

Probably this article is about something that everyone in the world knows. Problem is I did mistakes about this TWO times, without learning from them, so writing down it could be useful for this head of mine to remember how to do things right.

Writing a timestamp whenever a database row is created or updated is a standard task and everyone need it.  Many database systems can do it by themselves (MySQL), dumber ones cannot (SQLite). Are we interested in this? Obviously not, DBIX::Class (the one and only) give us a good abstraction about that and it's easy to use.

When you know the trap to avoid.

Syntax to have a timestamp that set itself on create is really simple. In your model class:


__PACKAGE__->add_columns(
  "timestamp",
  { data_type => "datetime", is_nullable => 0, set_on_create => 1 },
);


It's something so used that there's a flag to manage it. You set it to true, the timestamp will be written.

IF and only IF you remember this:

__PACKAGE__->load_components("TimeStamp");

and you installed DBIx::Class::Timestamp!

Are you hearing the Wotan worshipper roaring? Why should he? It's a procedure so clean!

Well, perl is a language that worship optimization (more than Wotan! Grrrrr). Often optimization means a fine grane library control. So in many important modules you see methods different from use... to load libraries. Most of these methods have a little side-effect: they don't give errors.
In this particular case you can write the first piece of code, forget the second or write the second and forget to install the library. The code will run. What will happen about the timestamp? Absolutly nothing.

But now I wrote this. Now this thing is encarved in my blog and in my mind. I will never be tricked again.

What were we talking about?