Been very swamped with contract work, but I have managed to roll a Facebook App called Now Hiring into production for Taleo.
I had a list of updates, but the blog died a horrible and fatal death, and I can’t for the life of me remember what they where.
Except pagination in Rails with will_paginate is so good it’s terribly terribly frightening
Mocha is a library designed to let you mock objects in your test environment. It’s very useful for testing around external dependencies
Inside one of my controllers I am calling a SOAP Service:
message_result = SOAPService.send_message(message)
This leaves me with a problem in my functional test - external dependencies are not conduive to self-contained test. Enter Mocha to the rescue!
Mocha lets me create a stub for a method on any instance of my object. This means that I can intercept the calls in my test, without needing to touch the code inside my controller.
SOAPService.any_instance.stubs(:send_message).returns( MessageResult.new )
get :respond
assert_match(/
The get :respond call above would normally invoke a SOAP call, but using any_instance.stubs(:send_message).returns( MessageResult.new ) means that the SOAPService.send_message method now will return a new MessageResult. My controller doesn’t care and now my functional test is tight and focussed, and tests the controller logic without the external dependency being a factor.
Did you find this Ruby on Rails article useful? Why not recommend Toby at Working With Rails?
I received my Linode account for the Rails Rumble.
I logged in and the first thing I have to do is pick the Linux distro I want to install and use for the Rumble.
There are far too many options!
The available distros are:
I’m not really a systems person … I know my way around Linux, but I don’t have a whole lot of experience setting a machine up from scratch. I’ve been lucky that for the last several years I’ve worked with truly awesome sys admins who take care of all this stuff for us.
So what to use?
I am leaning toward Ubuntu 6.06 (Dapper Drake) because it looks like there are some good tutorials around (I even think the Peepcode guys have been using Ubuntu for some of their work - it might be time to subscribe).
Any ideas are appreciated. I am definitely going to learn a lot this weekend.
You can find all my notes for the RailsRumble in Backpack.
I changed my mind, I am going to keep my notes here in the blog.
Go self.Team!
I’ve registered for the RailsRumble as a one-person team called, cunningly: self.Team
See what I did there?
I am going to be building a game - a browser-based, AJAXified wargame loosely based on the Roll Out The Gun Barrels ruleset. I’ll be posting a few design ideas over the next week.
Rails Rumble has been announced. 48 hours to build an application from scratch.
I am going to enter … as a solo developer. I think I will attempt to build the game I have been occasionally designing for the last couple of months. Or maybe my idea for a Google Adwords Landding Page Manager. I’ve already signed up for the AdWords API …
There are a couple of these around, but I rolled my own because I wanted something quite simple.
# S3 Backup Task for MySQL
# Assumes InnoDB tables
# Database User needs the "reload" permission on the database (for --flush-logs in mysqldump)
#
# Stores files in Amazon S3 using the excellent AWS Gem: http://amazon.rubyforge.org/
# For information about Amazon S3: http://aws.amazon.com/s3
#
# Installation
# 1) Install AWS Gem
# 2) Enter your S3 Bucket, access_key_id and secret_access_key in this file
# 3) Run (rake db:backup)
#
# Inspired by code from:
# http://blog.craigambrose.com/articles/2007/03/01/a-rake-task-for-database-backups
# http://www.rubyinside.com/advent2006/15-s3rake.html
namespace :db do
require "aws/s3"
desc "Backup database to Amazon S3"
task :backup => :environment do
BUCKET = "bucket"
begin
AWS::S3::Base.establish_connection!(
:access_key_id => "access_key_id ",
:secret_access_key => "secret_access_key "
)
db_config = ActiveRecord::Base.configurations[RAILS_ENV]
backup_path = "db/backup"
File.makedirs(backup_path)
datestamp = Time.now.strftime("%Y%m%d%H%M%S")
file_name = "#{RAILS_ENV}_#{db_config['database']}_#{datestamp}.sql.gz"
backup_file = File.join(backup_path, file_name)
sh "mysqldump -u #{db_config['username']} -p#{db_config['password']} --single-transaction --flush-logs --add-drop-table --add-locks --create-options --disable-keys --extended-insert --quick #{db_config['database']} | gzip -c > #{backup_file}"
puts "Created backup: #{file_name}"
puts "Storing file in S3: #{BUCKET}"
AWS::S3::S3Object.store(file_name, open(backup_file), BUCKET)
puts "Backup Complete"
rescue AWS::S3::ResponseError => error
puts error.response.code.to_s + ": " + error.message
end
end
end
I’m speaking at the Melbourne Ruby User Group next week. Either on using Amazon Web Services. or hacking with Prototype (probably focussed on the new 1.6.0 features).
Lineup & Location
ThoughtWorks
Level 11, 155 Queen St
The REST stuff is really fun to play with … I am finding it breaks a little in the real-world with non-trivial use-cases. Start adding auto-completes and other AJAX elements to your page and you start bending the RESTful model a little. I am figuring it’s best to have the core REST architecture and build on it, rather than bend my code to adhere mindlessly to some REST ideal.
I {heart} Rails.
Scalability of the favourite argument topics of the technically inclined. Having developed some fantastic, all-singing, all-dancing, user-generated social networking Web 2.0 platform*, someone will invariably ask:
“Oh, you used {LANGUAGE X}”
“Will it scale?”
You have to imagine the slightly derisive tone for yourself.
Trouble is, languages don’t scale, systems do.
Assessing scalability on the basis of a particular programming language is like saying to someone who is writing an Encyclopedia: “English won’t scale”.
Systems scale.
If you wrote your Encyclopedia the same way you wrote your product brochure, it wouldn’t scale - small page format, lots of pictures, minimal text with plenty of whitespace. If you write an Encyclopedia, you need to develop a system for handling the information - table of contents, indexing, cross referencing, multiple volumes, alphabetical organisation, thin paper, multiple columns of text, readable fonts.
The language used to write the Encyclopedia or Brochure is secondary to the system that delivers it.
The same is true of Web Applications.
Languages are irrelevant to scale and frameworks (being very close to languages and essentially an extension) only have a minimal impact.
I moved to Ruby on Rails from PHP. The standard argument against Rails from PHP developers is that “Rails won’t scale”**. However, this focus misses the point entirely. I have seen arguments from PHP developers who suggest using single quote for strings ‘ rather than double quotes “, because single quotes parse faster in PHP. This thinking is radically broken.
Scalability has nothing to do with processing performance at the language level.
Scalability is about the system as a whole.
At some point as an application scales, it will invariably require multiple servers and multiple databases, and there is very little any language or framework can do to mitigate this requirement. These requirements are system level, not language level - your only real option is to be ready to build your system out accordingly as it grows. The only trouble you find is when you have made decisions early on that limit the way your application can grow out.
As a corrolary to the scaling issue, my final point is this:
You aren’t going to scale
Call me cynical, call me pessimistic, but lots of people build for scale prematurely.
The focus should always be on creating great user experience.
Unless you have the load to warrant a particular system decision you should not be creating that system (but always within the framework of sensible architectural decisions). Scaling issues are often unpredictable (you don’t know your load profile until you hit it, or are hit by it) but worrying about them before you have to wastes valuable developer resources on infrastructure rather than the interface.
In the Web 2.0 world, scaling problems are a sign of success, but the focus should be on the user, not the system.
* We don’t develop applications or, god forbid, sites anymore, we develop platforms.
** I am aware the argument is a bit confused here, because PHP is compared to Rails, when Rail is a framework based on the Ruby Language and should be compared to a PHP framework like CakePHP.