Andrew Cantino's blog
In order to post to our Campfire chat when the CI goes red, we threw the following script in script/campfire_post:
#!/usr/bin/env ruby
require 'rubygems'
require 'net/http'
require 'uri'
require 'json'
url = URI.parse('http://SUBDOMAIN.campfirenow.com/room/ROOM_ID/speak.json')
req = Net::HTTP::Post.new(url.path)
req.basic_auth 'API_KEY', 'X' # leave the X
req.body = JSON.dump({ :message => { :body => ARGV.first }})
req.content_type = 'application/json'
res = Net::HTTP.new(url.host, url.port).start {|http| http.request(req) }
case res
when Net::HTTPSuccess, Net::HTTPRedirection
# OK
else
res.error!
end
And then in cruise.rake:
desc "The task that cruisecontrol.rb runs"
task :cruise do
begin
rake "spec"
# etc
# etc
rescue
exclaim = ["Oh goodness, t", "OMG t", "Look sharp, t", "Attention everyone! T", "Ohnoes! T"][rand * 5]
system "ruby script/campfire_post '#{exclaim}he build just went red!'"
raise
end
end
And it's even cheeky!
Interesting Things
- If you are testing with jasmine, it's a good idea to include your CSS files in the test runner. This prevents, for example, issues where you've hidden an element in the CSS and expect it to be visible in your JavaScript. If you are using Sass, then you should regenerate your CSS from the Sass before running the jasmine tests. The current version of haml-edge updates the sass command-line tool with an update command. On one of our client projects, we added the following to our jasmine_config.rb file:
def update_sass
puts "Updating sass files..."
rails_root = File.expand_path(File.dirname(__FILE__) + "/../../../")
sass_path = "#{rails_root}/vendor/bundler_gems/ruby/1.8/gems/haml-edge-2.*/bin/sass"
puts `#{sass_path} --update #{rails_root}/app/stylesheets:#{rails_root}/public/stylesheets/generated`
puts "done."
end
alias_method :old_start, :start
def start(*args)
update_sass
old_start(*args)
end
alias_method :old_start_server, :start_server
def start_server(*args)
update_sass
old_start_server *args
end
Interesting Things
- When testing with jasmine and using jQuery live events, be sure to stop the events between tests. If you don't, they can cross tests and cause confusing results.
- RailsPlugins.org is asking that all Rails plugin developers register their plugins on the site. This will both help determine the set of plugins that are ready for Rails 3, and also provide a comprehensive directory of plugins.
Interesting Things
- Bundler is now at version 0.9.x. The 0.8 to 0.9 release included many improvements and large internal changes. Everyone should probably upgrade, but be aware that this may be disruptive to your project, as the bundle command has changed names. You should be aware of this before upgrading. Yehuda has posted a comprehensive blog post about using Bundler that is worth reading. Since Bundler is in beta, it will probably keep changing.
- Amazon has released a beta versioning feature for S3 that allows you to keep a full history of changes to your S3 objects. This looks useful.
- There is some question about what state of a DOM node is shown in the Safari console when
console.debugis called. Is it the state of the DOM node from exactly when the call was made, or is it some later state due to Safari asynchronously displaying the console messages? We are going to do some research and will update at a future standup.
Edit:
It sounds like the Safari issue occurs when logging a reference. Mentioned workarounds for the Safari issue include:
- explicitly logging the variables that you are interested in; i.e.,
console.log(obj.a, obj.b) - using the debugger
- transforming the object to JSON
- using
console.dir - logging a string
Interesting Things
A project reported that GemInstaller failed when installing Rails 2.2.2, because it attempted to list the remote Rails 3.0.beta gem. There's a bug open and awaiting more info, but since this is not reproducible on RubyGems 1.3.5, it may be due to an old RubyGems version not handling prerelease gems properly.
The GemInstaller author heartily recommends that you switch to Bundler anyway







