buffington

Doing a lot of work with Ruby's IRB or a Rails app's console? Create a file called .irbrc in your home directory with the following Ruby code and you'll have tab completion and most importantly, input history across IRB sessions. A huge time saver.


require 'irb/completion'
require 'irb/ext/save-history'
ARGV.concat [ "—readline", "—prompt-mode", "simple" ]
IRB.conf[:SAVE_HISTORY] = 100
IRB.conf[:HISTORY_FILE] = "#{ENV['HOME']}/.irb-save-history"

I'll be doing a presentation on llor.nu tomorrow at the AjaxWorld Conference in Santa Clara, so I decided to pull llor.nu out of sabattical and get it back online and ready for play. I'll leave it this way until the new version comes out.

If you're at the conference, come say hello. Here's what I look like.

Enjoy!

I love subversion, the version control software. It seems crazy to me that only a little over a two years ago I didn't really get it. I understand and used version control software before, but not something as clean and easy to use as subversion. I can't imagine not using it for any development project now.

But I don't like maintaining subversion repositories on web accessible servers. It's not that it's all that hard, but it's just one more thing I have to worry about, one more step in my perfect stack.

I recently started using svnrepository.com to host a lot of my personal projects, and even a few client projects. I have eight Rails application repos currently being hosted (some of them quite large) and I'm using a sum total of 430kb in space. For $6.95 a month, svnrepository.com gives me 2GB of repo space (which I'll likely never fill at my current pace) and provides a very usable interface to build repos and control user access. The interface doesn't yet allow you to give anonymous checkout access (something I needed for one of my repos) but sending an email to the admins got an instant response.

If you have any subversion repositories at all, I highly recommend svnrepository.com. I find them worth every penny.

**Update**

I totally forgot to mention one more killer feature. Hosted Trac, as well as a web interface to administering Trac. That alone is worth $6.95 a month, and you can associate an entire Trac instance for each svn repository, as well as control who else has admin rights to that instance.

Rails and Capistrano, by default, don't quite handle the concept of deploying to multiple production environments. I often find myself deploying production ready applications to a staging virtual host on the same machine the production virtual host runs on so the client can approve work before pushing it live.

I settled on a pretty clean setup today to make this kind of thing dead simple. I'm assuming you're already familiar with how to setup mongrel clusters, and that you've got the balancer in Apache or whatever forward httpd server figured out and running.

## Step one: Create two mongrel cluster config files
### Call the first one staging.cluster.yml


—-
cwd: "/path/to/staging/yourapp/current"
port: "8000"
environment: production
address: 127.0.0.1
pid_file: "log/staging.pid"
servers: 3


### Call the second one production.cluster.yml


—-
cwd: "/path/to/production/yourapp/current"
port: "8003"
environment: production
address: 127.0.0.1
pid_file: "log/production.pid"
servers: 3


## Step two: Modify deploy.rb


require 'mongrel_cluster/recipes'
ENV['DEPLOY_TO'] ||= 'staging'

set :application, "yourapp"
set :repository, "http://path/to/svn/repo"
role :web, "192.168.1.1"
role :app, "192.168.1.1"

set :deploy_to, "/path/to/#{ENV['DEPLOY_TO']}/#{application}"
set :mongrel_conf, "#{current_path}/config/#{ENV['DEPLOY_TO']}.cluster.yml"
set :svn, "/usr/local/bin/svn"


## Step three: deploy

No need to setup any custom tasks for each production environment, I simply set an environment variable and tell capistrano to deploy. Because I default ENV['DEPLOY_TO'] to staging, deploying to staging is dead simple. I made it harder to deploy to production because one would think that if you have a staging step in your deployment processes at all, chances are typing the few extra characters to indicate a production deployment are worth it.


DEPLOY_TO=production cap deploy

I got a bit obsessive tonight and set myself up with a challenge. After watching one of CNN's international news broadcasts, I got interested in recreating their new on screen headline graphics with HTML and Javascript. Here's what it looks like:

Watching Luis von Ahn talk about building games to help solve problems with humans that computers can't figure out is incredibly inspiring to me. He does a great job of breaking down what seems to work, and what doesn't work, when designing a game that takes otherwise totally boring, menial tasks and turns them into compelling challenges.

While making the menial fun is great, I'm even more inspired by how simple some of these problems are to solve. I've mapped out several game ideas that, if executed with the same approach as Luis' games, would be dead easy to build.

With that said, I'd like to present splog attack. This is what Luis would describe as a symetrical verification game. Player 1 sees a blog entry, and makes a single determination - is it spam or not. Player 2 makes the same determination. If both come to the same conclusion they get points, and both move on to another round.

But there's a twist, interestingly, thrown in to fight against bots fouling the results. In addition to having to determine if the blog entry is spam, the players see three blog entries at a time from different blogs. Both players get the entries in random order, and must agree on all three blog entries, matching a spam label to the same spam label their counterpart matched. It doesn't totally eliminate bots from making random choices, but it certainly makes it harder.

So what can you do with the results? Wired Magazine just ran an article talking about some of problems search engines face with detecting spam blogs, and how they are having a difficult time weeding out the good from the bad. It's very easy for a human to see even just a sentence and make the determination that something isn't right, but far more difficult for a computer.

Push a particular blog through that filter enough times and you end up having a pretty clear picture of what's spam and what's not. Reward players for figuring it out quickly, and they may even outpace the production rate of spam blog bots, turning the tide. Provide search engines with the results, and spam blogs may become irrellavent.

While part of me would love to see the game succeed in killing spam, I'd miss the weird sort of anonymous interaction with another human mind. When you're both right, it feels great, and out ranking others doing the same thing is a lot of fun, especially knowing it's helping fight spam blogs.

I found a great little how-to on replacing sendmail with postfix on FreeBSD. My once sick contact form is now fixed because of it.

Because postfix replaces sendmail entirely, it works seamlessly with Ruby on Rails as the default outgoing mail handler.

In the hopes that I will write less words more often, I've changed the visual format of the site. Please don't get lost, and do say hello from time to time.

For the curious, I've also switched to a new server, and new blog software. It's not that I don't like MovableType, because I do, I'm just ready for something new.