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:
- Generating the required SSL key and certificate files for use with nginx.
- Recompiling the nginx server through the passenger-install-nginx-module command.
- 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:
[click to continue…]
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
Michiel Sikkes is Technical Lead and partner at 
