I took the release of Snow Leopard as an opportunity to do a clean wipe and re-install of Leopard and Snow Leopard. As usual, Dan Benjamin has a greatseries of articles on getting the latest and greatest setup.
I aggregated these articles into a bash script to automate installing MySQL, Ruby, Rails, RubyGems and Git.
Prerequisites
As Dan mentions, the prerequisites for this script are:
Mac OS X 10.6 Snow Leopard
The latest Xcode Tools (from the Snow Leopard DVD or downloaded from Apple — the 10.5 version won’t work)
Confidence running UNIX commands using the Terminal
Caveats
This has only been tested on a completely fresh install of Snow Leopard, not recommended for upgrades
When writing unit tests I tend to 1) use factories instead of fixtures and 2) keep my factories in synch with model validations. As such, I like to write a test to ensure that out of the box a new instance of a factory object will be valid. Here is a macro to help out with that:
class ActiveSupport::TestCase
def self.should_be_valid_with_factory
klass = self.name.gsub(/Test$/, '').underscore.to_sym
should "be valid with factory" do
assert_valid Factory.build(klass)
end
end
end
Put this in your ActiveSupport::TestCase definition and it will be available in all your tests. Simply call it by name with no params:
class BuildingTest < ActiveSupport::TestCase
should_be_valid_with_factory
end
Naming for this method was inspired by a similar method in Dan Croak's Blitz plugin.
One of the things I like most about TDD, and shoulda specifically, is that if a thought pops up of something I need to add I can add a deferred test and come back to it later. In shoulda you can do this with:
should_eventually "do something"
#or just leave off the block
should "do something"
This works great for models/controllers, but I also wanted a way to integrate a miscelanious todo list into the flow that would pop up in autotest or when running the whole test suite. To accomplish this I’ve been keeping a TodosTest in the integration tests directory:
require File.dirname(__FILE__) + '/../test_helper'
class TodosTest < ActionController::IntegrationTest
context "TODO:" do
todos = [
'add the jquery rounded corners plugin',
'add the jquery dropshadow plugin',
'scope actions in application.js to specific pages'
]
todos.each do |todo|
should_eventually todo
end
end
end
The output of this is:
* DEFERRED: TODO: should add the jquery rounded corners plugin.
* DEFERRED: TODO: should add the jquery dropshadow plugin.
* DEFERRED: TODO: should scope actions in application.js to specific pages.
Since this isn't really an integration test I usually add a line for this in the .gitignore.
Also - this is a handy bash alias to print the todo's without the deferred/should language:
alias todo="ruby test/integration/todos_test.rb | grep TODO | sed -e 's/DEFERRED: TODO: should //g'"
The cleaned up output is:
* add the jquery rounded corners plugin.
* add the jquery dropshadow plugin.
* scope actions in application.js to specific pages.
Giles Bowkett’s presentation from the RubyFringe conference has been getting a lot of attention lately, with good reason. InfoQ calls it a “highly politicized call to action in a career-defining presentation that is raucously hilarious yet unnerving in its practicality”. The initial demo of Archaeopteryx, in which Giles DJs using nothing but TextMate and Ruby is interesting, but the real action starts when he gets into a discussion of the empowerment of being on the fringe.
An in interview with O’Reilly, Rails creator David Heinemeier Hansson had an excellent response to the obligatory twitter question. To paraphrase, he says that the kind of person that users the A is B, B is C, therefore A is C logic that “Twitter runs on Rails, Twitter Can’t Scale, so Rails can’t scale” simply illustrates their shallow level of technical knowledge.
Engine Yard has just closed a second round of funding for $15m, including contributions from Amazon, with the focus on increasing their hosting platform and community-driven open source projects. According to Ezra, “We’re going to use this money towards making Ruby the platform of choice for cloud computing and web development in startups and the enterprise alike.” Some of the exciting developments coming out of Engine Yard these days are the merb framework, which is a leaner/quicker Ruby framework insipired by Rails and Rubinius, a pure Ruby implementation of the Ruby virtual machine which aims to solve some of the current performance issues with Ruby. Perhaps most interesting is the yet to be unveiled Vertebra project that has been described as “a new application programming platform for building distributed cloud applications with XMPP”. Rails developers can sleep a bit easier knowing that EY has 80 employees and some of the smartest minds in the community cranking away on the remaining pain points in the Ruby platform (hosting, performance)
At the end of last week Phusion, a Netherlands based IT company, launched the Passenger gem, which acts as a mod_rails for Apache. Without going into the technical details, this is as close as Rails has come to having an ‘ftp files to the server and it works’ deployment method. With deployment being one of the steepest learning curves in the Rails world, this announcement could potentially be huge.
So what does this mean for developers who have been using Rails for several years and those who have yet to pick it up? Many Rails developers, who have seen the progression from CGI to FastCGI to Mongrel, Mongrel Cluster, Thin, etc, have been forced to learn a good amount about unix, apache, nginx, monitoring servers, watching processes, etc. Unix command line skills have gone hand in hand with Rails development up to this point. In fact, entire businesses such as Rails Machine, Engine Yard, Planet Argon, etc. are built around the fact that Rails is hard for the average person to deploy (not to mention great open source tools like capistrano, vlad and mongrel itself).
Is this the beginning of a new era for Rails where the last barrier to entry has been removed? It will be interesting to see what kind of effect this has on the current Rails community as real-world data becomes available.
I spent most of this past weekend working through Michael J. Mangino’s book “Developing Facebook Platform Applications with Rails“(DFPAWR) from the Pragmatic Programmers. I’ve been interested in the facebook platform for awhile but the resources have mostly fallen into two categories: 1) Overly simple Hello World programs in PHP or 2) Exhaustive api references.
DFPAWR, which is still in Beta, walks the reader through creating a full application from start to finish using Chad Fowler’s excellent Facebooker library for Rails. While this is definietly a Rails-centric book, the author provides the underlying FBML code first and then explains how to achieve the same effect using the simplified syntax of the Facebooker library.
It should be noted that the book assumes a strong understanding of the Rails framework. However, this assumption is one of the book’s biggest strengths. DFPAWR is a perfect example of how fast author and reader can hit the ground running when they already speak the same language. Michael Mangino clearly knows his subject matter and readily points out many of the common pitfalls, security concerns, and Facebook terms of use issues (i.e. you can’t store a username in a local database) that those new to the platform would have to stumble through themselves.
It’s a great resource for Rails developers looking to get started on Facebook apps, and with mod_rails on the way it’s never been easier.
According to the site: God is an easy to configure, easy to extend monitoring framework written in Ruby.
While god is mainly intended for monitoring mongrels it is also a great way to keep an eye on apache itself. Below is our config for watching apache.
%w{80}.each do |port|
God.watch do |w|
w.name = "apache"
w.interval = 30.seconds # default
w.start = "apachectl start"
w.stop = "apachectl stop"
w.restart = "apachectl restart"
w.start_grace = 10.seconds
w.restart_grace = 10.seconds
w.start_if do |start|
start.condition(:process_running) do |c|
c.interval = 5.seconds
c.running = false
end
end
end
end
The code is pretty self-explanatory. We’re just looking to make sure apache is up every 5 seconds.
After gem installing god, save the configuration file anywhere you want and kick if off with this command:
god -c /path/to/your_conf.god
That’s it. To test, kill apache and in less than 5 seconds it will be back up and running.
