I started using Heroku three weeks ago since @_micho from teambox.com recommended it to me. He told me they had a free app tier with some basic functionality and you can upgrade if you need more power or other functionality.

I’ve been testing it for deploying several development and staging apps the last two weeks and Everyday Feed already runs on it in a production-kind-of way. I’ve come to a conclusion: always deploy your first deployment on Heroku.

So, why is this?

1. Because Heroku is an app-based deployment service instead of an instance or server-based deployment service you can focus on the application and making it work, without having to worry about server installations, best deployment settings, software etc. You deploy your app on Heroku so you can fix your app, and not waste time on fixing your server.
2. Heroku is totally Git-based so it will force you have a good Git-workflow right away, from the start of your first deploy. One of the advantages of using Git is of course that your code is in version management and you can easily manage various feature sets and rollback to previous deployments, but it’ll also help you right away when you get more team members.
3. Heroku forces you to configure all your things that run around your app, like cronjobs, sending email, doing queuing and caching. Because Heroku forces you to work in a very automated and modular way you’ll never mess up your app’s code with external things. This make sure you configure everything nicely in external files or in the Heroku admin panel so you never hardcode things in your code.
4. Heroku is free. Well at least the first database package they have (up to 5MB). I like this from a business point-of-view because you can also scope what you spend on Heroku with your income of the app. I have a simpel rule with Everyday Feed: I will not upgrade Heroku until the application has some users or advertisers that are paying. This way I make sure people want to pay for the core functionality and add extra features from there, when I can buy more power at Heroku.

When you have your application up-and-running on Heroku, it is probably a very clean application with all configuration outside the application logic. This means you should easily be able to migrate to another server or your own EngineYard Cloud or EC2 load-balanced cloud environment because your app is not tied to a hardcoded server configuration.

When you move away, you can even keep using Heroku’s add-ons because they have a lot of partnerships with external services like New Relic and SendGrid when you move away.

Of course, you can also just stick with Heroku because from what I’ve heard they provide excellent application hosting for all your needs.

I just wanted to share with you this presentation I created yesterday to communicate to other people and ourselves on how we use Scrum in Firmhouse. This is a first set of tools I’m creating for ourselves to get going with Scrum to create our products. But it can be a good piece of information for you too. The slides are great to keep as a reference on what kind of meetings you are going to have and what you need to discuss in them.

Expect more detailed Scrum and Agile Development stuff in the near future. We’re getting to an awesome workflow here. In the mean time, read 37signals excellent post about how they are going to approach development of new features in their products.

Here are the slides via SlideShare embed:

At Firmhouse, we are working on a new web service and we’re releasing an in-development demo to everyone who is interested. Normally, in demo apps security is less the case and there is always some disclaimer that says you shouldn’t use real production data like passwords and API keys. In my opinion, this sucks because you allways want to use your real-life data to test a demo and see if it’s useful for you specifically. That’s why, the best way to have some security in your demo app is by using a self-signed SSL certificate to secure passwords and other sensitive account information your demo users will be adding.

For our web app, we use Ruby on Rails running on Phusion Passenger, served by Nginx.

This blog post will guide you trough the process of adding a self-signed SSL certificate to your Rails app, running on Phusion Passenger and Nginx by following these steps:

1. Generating the required SSL key and certificate files for use with nginx.
2. Recompiling the nginx server through the passenger-install-nginx-module command.
3. Configuring your web app in nginx to redirect non-secure connections to the secure address of the app with https:// and make sure www. will get redirected on both versions as well.

I use a few other blog posts in this article, so I would like to thank the authors for providing the information publicly and freely.

Ok, now let’s start:

1. Generating the required SSL key and certificate files

This step is largely taken from the Slicehost Articles: http://articles.slicehost.com/2007/12/19/ubuntu-gutsy-self-signed-ssl-certificates-and-nginx.

First of all, generate an SSL private key to sign your certificate with:

openssl genrsa -des3 -out myssl.key 1024

And enter a passphrase for the key which we will remove later on.

Now, we need to generate a Certificate Signing Request:

openssl req -new -key myssl.key -out myssl.csr

This command will ask you various questions. Fill them as you see fit. You can skip the extra attributes by just pressing enter when asked.

Now, we are going to remove the passphrase from your key by making a copy and then generating it back to the original file without entering a passphrase. You can do this with the following commands:

cp myssl.key myssl.key.org
openssl rsa -in myssl.key.org -out myssl.key
rm myssl.key.org

We now have a key file, and a csr file. We can use these to generate the actual SSL certificate with the following command:

openssl x509 -req -days 365 -in myssl.csr -signkey myssl.key -out myssl.crt

We should now move these files to the SSL configuration directory on your host. On Ubuntu, this is /etc/ssl/certs and /etc/ssl/private. Do this with the following commands (assuming you use sudo):

sudo cp myssl.crt /etc/ssl/certs/
sudo cp myssl.key /etc/ssl/private/

All required SSL key and certificate files are in place so we can continue with the next section: preparing nginx to be SSL-enabled with the passenger-install-nginx-module command.

2. Recompiling the nginx server with the passenger-install-nginx-module command

By default, the passenger-install-nginx-module command does not enable the SSL compile option in the default installation steps. Here’s how to use the custom build step to configure nginx with SSL.

First of all, be sure you already have nginx installed with the passenger-install-nginx-module command because this will have downloaded the nginx source code in /tmp, which you will need to enter in the custom build steps. If you haven’t already done this, run:

sudo passenger-install-nginx-module

Press enter after you’ve read the introduction message and choose step one “Yes: download, compile and install Nginx for me” by pressing `1′. (recommended) when the installer asks for the install options.

After nginx has been compiled and installed you can now run the

sudo passenger-install-nginx-module

command again. Press enter after you’ve read the introduction message and choose step two “No: I want to customize my Nginx installation. (for advanced users)” by pressing `2′.

You are now asked for the directory of the Nginx source code. The recommended installer step should have downloaded and extracted the source code in /tmp/nginx-x.x.xx. At the time of writing, this was /tmp/nginx-0.7.64. So enter:

Where is your Nginx source code located?

Please specify the directory: /tmp/nginx-0.7.64

And press `Enter’.

The next question will ask you where you want to install Nginx to. The default is /opt/nginx. To leave it this way (I recommend this), just press `Enter’ again.

Now the installer will ask your for extra Nginx configure options as shown in the following screenshot.

Here you should add the --with-http_ssl_module argument which will make sure the configure script will enable the Nginx HTTP SSL module for compilation.

Extra arguments to pass to configure script: --with-http_ssl_module

The script will ask you for a confirmation if you really would like to modify the configure arguments. And yes, you would like to so press `Enter’ to confirm.

The script will now start to configure, compile and install Nginx in /opt/nginx.

Wait a few seconds or minutes for it to finish and continue to the next section: configuring Nginx to use the SSL certificate and create a secure connection for your Rails application.

3. Configure your Nginx to use the SSL certificate to secure the connection to your application

First of all, we will need to add a server block to the Nginx configuration so your application will listen on port 443 and use Phusion Passenger for serving your app. Open /opt/nginx/conf/nginx.conf and add the following block below everything else:

server {
    listen 443;
    ssl on;
    ssl_certificate /etc/ssl/certs/myssl.crt;
    ssl_certificate_key /etc/ssl/private/myssl.key;
    ssl_session_timeout 5m;
    ssl_protocols SSLv2 SSLv3 TLSv1;
    ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;

    server_name yourdomain.com;
    root /srv/apps/qloudwatch/current/public;

    passenger_enabled on;
    passenger_use_global_queue on;
}

Make sure you use yourdomain.com or www.yourdomain.com here (not both) for nice HTTP redirection to the correct domain name.

Now we need to configure that all non-secure request are redirected to the secure address of the web app. For example: all requests to http://yourdomain.com/ and http://www.yourdomain.com/ should be redirected to https://yourdomain.com.

To do this, add the following before the server section we just added:

server {
    listen 80;
    server_name www.yourdomain.com yourdomain.com;
    rewrite ^(.*) https://yourdomain.com$ permanent;
}

Now, restart your Nginx server by calling `sudo killall nginx -HUP’. Wait a few moments for Nginx to launch and try http://yourdomain.com/ to see if everything works.

And that’s all! You have just generated a self-signed SSL certificate, installed Nginx with the SSL-module enabled and configured the domain with your web application to be reached trough SSL.

I understand this can be quite something to take in if you’re new to SSL and Nginx so if you have any questions, any questions at all about this or other web app deployment strategies please post a comment, contact me on Twitter (@michiels is my account) or send me an e-mail.

Beanstalkd is a queueing deamon that let’s you queue messages from one client and let them be processed by another client. It has features like burrying messages for later usage if the command at the first time can’t be executed and more stuff like that.

We use it for queuing things in Ruby on Rails applications which are time-intensive. For example, executing an install command on a remote server can take some time and you don’t want your web application to block or queue op other requests in this case.

Beanstalkd has excellent Ruby bindings which you can use in  your Rails app. There’s even a gem for it:

gem install beanstalk-client

Using it is as easy as:

beanstalk = Beanstalk::Pool.new(['10.0.1.5:11300'])
beanstalk.put('hello')

beanstalk = Beanstalk::Pool.new(['10.0.1.5:11300'])
loop do
  job = beanstalk.reserve
  puts job.body # prints "hello"
  job.delete
end

Installing on Mac OS X

Beanstalkd depends on libEvent, so you’ll need to install that first:

wget http://monkey.org/~provos/libevent-1.4.12-stable.tar.gz
tar zxvf libevent-1.4.12-stable.tar.gz
cd libevent-1.4.12-stable
./configure
make
sudo make install

And then you can install Beanstalkd:

wget http://xph.us/dist/beanstalkd/beanstalkd-1.3.tar.gz
tar zxvf beanstalkd-1.3.tar.gz
cd beanstalkd-1.3.tar.gz
./configure
make
sudo make install