Today I went down to try and have Cherokee working well with RVM. I wanted being able to switch the Ruby version with ease, in order to allow for a painless upgrading when patches are released upstream. More, I wanted to be able to create gemsets and such. Cherokee is fast as hell, and much easier to maintain than Apache.

After a little bit of fiddling, I came up with a nice and easy solution, which roughly goes like this:

Create a rails user on your system. My advice is to lock it down with “passwd -l rails” after creation.

If you installed any gems as root, it’s best to remove them. Then, follow the normal instructions to install rvm su-ing as the rails user. Compile and set as default a ruby instance of your choice (“rvm use –default ruby-1.8.7“, for example).

Always logged in as the rails user, install any gem you may need. You can do this later, if you prefer. Test if your website starts manually, by calling script/server, or if it complains about missing gems.

chmod -R your rails project to rails:rails. I keep my production sites under /var/www, but you can put ’em in /home/rails, for example.

Use the standard wizard that comes with Cherokee to prepare the sources for your website.

Under the “Interpreter command” text field of each of the three newly created sources, prepend the command that’s already there with (“/home/rails/spawner.sh“). For example: “/home/rails/spawner.sh example-website script/rails server -b 127.0.0.1 -e production -p 38161“. I omitted “/var/www/“, but you can put it there if you want.

For each of the sources, set the user and the group the site will be served with to “rails“.

Create a new file /home/rails/spawner.sh, which will do the simplest magic we need:

Now, if someone of the Cherokee project would be so kind to fix that ugly “Bad gateway” error the first time you try to access a Rails site and the interpreter hasn’t been spawned yet, I’d be immensely grateful. 🙂

This week I finally managed to get my Bachelor’s degree in Computer Science with a final mark of 101/110. Here you’ll find my thesis about the project I implemented during my final internship: Gallows.

Gallows is a scaffold generator that uses ExtJS 3.0 to achieve CRUD actions on a editable grid, as well as on some associated controller views. The Gallows generator produces a grid view of records starting from a pre-existing model. The capability of modifying, creating and deleting items is achieved via AJAX, by setting up ExtJS 3.0 to use a JSON renderer.

It is necessary to run the generator two times: the first round it creates a stub of configuration file, which you can alter to achieve the wanted result in views. The second time, it generates a controller and the right JSON-based views.

The advantage of this approach is to allow you to get automatically some join capabilities across different tables/models, and to associate the right widget to the right field when more than one may apply. (Hopefully) sensible defaults will be auto-generated. The controller name (which can be namespaced) must match the model name.

However, ExtJS doesn’t like these kind of parameter names inside Ext.form.Combobox and Ext.DataView, to name two, since they use an XTemplate to render a list of items. The standard regular expression which is used to catch parameters inside a template allows only for digits, letters, ‘-‘ and ‘#’ (plus a little bit of other magic you really don’t want to read).

It turns out that you can override the ‘tpl’ configuration parameter to use XTemplate syntax for inline evaluation. For example, for a Combobox, you could move from the default to: