How to become a Strehler developer

Strehler is a strange package to develope. It's easy to install from repository and use, but while you are just writing it you have to arrange many tricks to be confortable with the work. For example, Strehler needs a Dancer2 site to run, something the respository doesn't contain.

In this little tutorial I'll try to explain how to setup an environment to become a Strehler developer, because Strehler needs you, as any of the packages published on CPAN. It's a very basic tutorial, useful for beginners too.

I hope it will help.

The repository

You probably already have a sandbox created in one of the many ways available for perl development. I'm still a fan of the good'ol local::lib but it's good to use also, for example, perlbrew. Your sandbox has to be active during Strehler development and you have to put in it Dancer2

cpanm --notest Dancer2

But NOT Strehler. After installing Dancer2 most of the library useful to work with Strehler will be in place, but probably you'll need something more, libraries specific to Strehler work. Just install them in your sandbox the same way using cpanm when running the code point out their absence..

You'll surely need:

• Dancer2::Plugin::DBIC
• Dancer2::Plugin::Ajax
• HTML::FormFu
• Authen::Passphrase::BlowfishCrypt
• IO::Prompt
• DateTime::Format::SQLite

All this packages are in the requirements of Strehler package and would come automatically installing Strehler for CPAN. Installing them manually is the cleanest way to obtain them, but you can try some trick, like installing Strehler and then deleting it from repository, keeping all its dependencies.

The code

Just pull down all the source from the git repository in a directory you like

git pull git@github.com:cym0n/strehler.git 

Downloading the repository you'll have a directory named $GITURL/src/lib and one named $GITURL/src/script. These two directories will come useful soon.

The environment

Now that you have Strehler code it's easy to modify it and manage changes using git. Less obvious how to use this code and see it working. We just need to customize a little the environment. Open a file named strehler-devel and put in it

alias perl="perl -I$GITURL/src/lib"

alias strehler="perl -I$GITURL/src/lib $GITURL/src/script/strehler"

When the file is ok source it.

source strehler-devel

Testing site

All Strehler power is now available, coming directly from the git repository on your machine. Now you can easly create a testing site with Strehler onboard using strehler script itself.

strehler demo 

Just run it as

perl bin/app.pl 

to see Strehler and (eventually) your modifications in action.

Ballroom blitz (1)

I read this interesting article about Dancer2 deployment. I have a lot to learn about Dancer2 deployment so I thought seriously about apply this practice to my sites. However, working on it, I didn't feel so confortable with the techniques applied there, probably because of my habist more than other reasons.
So, at the end, I came to a different solution and I want to describe it here, to clarify it in my head and to demostrate, once more, that timtowtdi.
I will skip the part about the provider subscription, I want to focus just on the technical issues and I don't want to talk about a specific environment. Let us think just about you having a server, anywhere you want, and the Power of Root is in your hands.

Who's the man?

When you're young and stupid you can think that root is enough, because root is powerful, shiny, charming and has a silver armour with gold drawings on it. Uncle Ben died to teach you that with great power comes great responsibility and you're still so stupid to use root and just root, also for pron watching!

Then you grow up and you know that there're three type of users:

• root: the boss. Period. You don't annoy the boss with stupid deployment issues.
• human users: they have to log in on your machine and do dirty things. They need a little, walled garden (some guards on the wall, too)
• application users: they're on the machine just to work. They're strictly linked to the processes they run.

So, you need to start your app deployment and you have to choose a user that will do it. For this issue, after years chasing not-so-writable directories and evoking the sacred chmod sevensevenseven, I chose the easy way: do all using the nginx application user (nginx or www-data, usually). It's not perfect, it's not the cleanest way, it's not the most secure, but it's tidy enough and give you a lot of space to manage things.

From now on, consider yourself logged as nginx. It's home directory will be /var/www.

Where's the man?

Just a small paragraph about directories. If you don't have a strict discipline your system will become a mess. It's its destiny, it's nature. Entropy is part of every job in the universe.

My favourite idea about how to organize different sites on the same machine is to use reverse domain as subdirectories.

So, mylittlepony.evilgenius.com will go under /var/www/com/evilgenius/mylittlepony and fluffy.bunny.org will be /var/www/org/bunny/fluffy.

This way it will be easy to find the site you're looking for and directory names will never be too long. The policy for domain names is also one of the strictest of the computer science, so you'll never have to manage UTF-256 characters or things like that.

Beam me up Scotty!

This article will speak also about the obvious. 

The easiest way to put the code of your webapp on your server is through some versioning system like git. You just have to pick up an account on github or bitbucket and then, after finishing the development, push all you did on a repository. Then, on your webserver, you just have to clone the project and then maintaining that pulling every update you push.

There's a part of me that don't like working this way. The cleanest and most clever way to deploy a software is packing it someway and then installing it on the server. Packing and installing must be done through a clean, sharp and smart suite of scripts tailored on the software you are managing.

This is the old school procedure and as a lot of old school procedure it's still good, but I have to admit that git is easier and perfect for lazy people.

But! Remember! :

• Think about if you need a private repository. It could be that someone doesn't want that the code of the site is exposed to everyone with a google bar. I know, I know, open is better, open is good, open i what tender kittens wants, but sometimes it's not what YOU want.
• gitignore is the most important file of your repository. Design it thinking that nothing about your server environment should be in the git repository. For two simple reasons. One: if you have on git something related to an environment it could change the environment configuration on deploy just because on your developement server something is different and making a git pull a disaster. Two: you don't want your production database password written on a public github repository... and probably you don't want it also on a private one, if you don't know all the contributors to your project.
• Take a branch as the production branch and never touch it before deploy time. When you have to develope a feature branch from production and develope there. On deploy, merge your new branch with production and push. You have to trust in production branch. Every time you go on your server and do "git pull origin production" you have to know exactly what will happen. Nothing, in the most cases, the deploy of something you planned, on the happy release date.
  Again, if you don't trust all your contributors, there're many ways to prohibit people to push on production. Enforce them. Your contributors are not always malicious, but they're still users. They do users' things. Users things are often stupid things. Stop them.

This project about Dancer2 deployment will be quite long. I'm putting in it a lot of random things from my experience. So I stop it now and I put a number on the title. We'll be back, i hope soon.

404 Ghost workaround

A little recap:

Here I stated a problem about phantom 404 and  a (wrong) solution to it.
Here I confessed I was working on the issue.
Here It's the work I'm doing with a long and boring description of the problem that I'll not repeat in this blog.

...but probably you don't want to wait until the problem is really closed because you have (as me) a package that you want on CPAN to share it with the world.

Oh yes, the problem! Let me say it with few words:
You have a plugin that modify the request path in a before hook. You want that, when the user write (for example) /prefix/good/path, your plugin change it to /good/path. Obviously the code that will answer to this will be:

get '/good/path' => sub {...}

You don't define anything about /prefix/good/path because the plugin will always change it, so you'll never need to answer with it.
This works! I can swear it calling Wotan on my side. But when you try to test it with dzil test the test you wrote fails.

Long explanation for why this happen, as I said, is here. Little workaround you can use to stop this happening is adding a public directory under the t with just a dummy file. This way fix the problem and make you test suit running flawless!

Dancer2::Plugin::Multilang

So, my wonderful Dancer2 plugin to manage multilanguage sites is released on github!

I wrote in this blog something I learned developing it, so I think that this place is the right one to make the announce.

I tryed to design this plugin as "plug-and-play" as possible. With it, you should be able to make your site multilanguage with no other effort then... translate the contents.

Netx step is releasing it on CPAN but I never did something like that so I have to learn how. I hope to learn it well enough to come back and writing about it in my blog, but now I don't have enough time to do it, so this topic has to wait a little.

In the meantime download, try, fork and play with my plugin as long as you want. Feedbacks (yes, bad feedbacks too) are welcome!