Announcing Tache – Just enough Mustache for end users

I’ve finally found some time (thanks to the xmas break) to have a crack at a ‘safe’ Mustache implementation in Ruby. By this, I mean an implementation that allows for templates to be edited by end users without fear of jeopardising an app’s security. This is useful in many situations, for example in a CMS or to allow users to customise email responses etc.

In order to gain a full understanding of how Mustache works internally, I decided to first write a full Mustache implementation from the ground up. Once this was done, I looked at ways to implement ‘safe views’ using Liquid as inspiration. Tache meets the current Mustache spec, apart from a few whitespace differences that I will be addressing shortly.

You can view the project on Github which contains the full documentation.

Happy New Year!

Pow, meet rbenv

I just ran into a problem with Pow when using rbenv for Ruby version management whereby Rails apps were not launching properly, giving the the following error message:

Error starting application
Your Rack app raised an exception when Pow tried to run it.

Bundler::GemNotFound: Could not find ??? in any of the sources

Turns out that Pow doesn’t know anything about rbenv unless you tell it. Thomas Fuchs tweeted a solution, suggesting that you just add the following to a ~/.powconfig file:

export PATH="/Users/username/.rbenv/shims:/Users/username/.rbenv/bin:$PATH"

Kill off your Pow process (I use the Powder gem for this i.e. powder down && powder up) and all should work just fine.

I personally prefer the solution mentioned in this related Github ticket as is saves having to hardcode your home directory:

export PATH=$(rbenv root)/shims:$(rbenv root)/bin:$PATH

Happy Pow’ing.

Using both Pow and Apache on OSX Lion

I have written previously about using Pow for Ruby/Rails development. Pow is great if you are purely developing in Ruby, however I’ve recently found myself needing to edit a WordPress site.

Pow intercepts requests to port 80 by default meaning that no requests can make it through to the default Apache installation on OSX. I’ve found the best way around this is to disable Pow whenever developing in PHP. The powder gem handles this nicely, so:


gem install powder

Now you can now disable Pow with the following, therefore letting requests through to Apache (assuming you have it enabled):


powder down

And once you’re done with the PHP development, enable it again with:


powder up

As a side note, I usually leave Apache disabled by default i.e. uncheck “Web Sharing” within the “Sharing” section of System Preferences until I am going to be doing some PHP development.

Hope this saves someone some time figuring out how to disable/enable Pow.

Loving MongoDB but Missing Transactions

I’ve been venturing into the world of MongoDB via Mongoid in a Rails app. On one hand it’s a breath of fresh air (no migrations, flexible schemas etc.) but on the other hand I really, really miss transactions.

If somebody asked me if I used transactions much in MySQL, I would probably have said no… however, now that I don’t have them I realise just how much I used them. Things that just work when using ActiveRecord such as creating a record and ensuring that an associated record gets created is sooo much harder.

MongoDB has “Atomic Operations” which means if you have an embedded relationship, all is good and the database will be rolled back if the entire document does not save. As soon as you have two top level collections and need to ensure that a record is created in both, things get a little hairy.

There seems to be a great deal of “if you need transactions just use a RDBMS” talk but what if you need a flexible schema and transactions, the last thing you want to manage is some kind of EAV system like Magento.

I’ve created a thread on the Mongo User forum with a typical example so feel free to join in the discussion. I’d love to hear experienced Mongo user’s views on how to overcome these kinds of situations and what kind of applications people are running with MongoDB.

Releasing IQ::Color

At SonicIQ we have a number of RubyGems used internally that we haven’t found time to open-source yet i.e. cleanup the documentation and get into state that people can find useful. I’m going to make it my mission to get some of these out there which first involves releasing some of the smaller Gems that the larger ones depend on.

IQ::Color is a really simple Gem for converting colour values to and from CSS(3) notation, this is used by a couple of our larger Gems but I can see it being of use on it’s own. A simple example:


color1 = IQ::Color.RGB.new(127, 127, 255)
color1.to_css #=> "#7f7fff"

color2 = IQ::Color.from_css('rgba(127,127,255,0.4)')
color2.red    #=> 127
color2.green  #=> 127
color2.blue   #=> 255
color2.alpha  #=> 0.4
color2.to_css #=> "rgba(127,127,255,0.4)"

More examples can be found on GitHub.

Ruby Causing MacBook Pro to Run Hot

The past couple of days the fan on my MacBook Pro has been constantly on and battery usage down to around a third. Launching Activity Monitor, it showed 3 Ruby processes all at 100% CPU usage. The solution was to force quit these processes and within seconds, the fan slowed up and the battery indicator went up. Force quitting these processes didn’t affect anything I was doing with Rails or IRB so I guess they were just stray processes.

If anyone else gets the same problem, just launch Activity Monitor which lives in the /Applications/Utilities folder, click the CPU tab if not already selected, select processes with a process name of “ruby”, click “Quit Process” and then select “Force Quit”. Just selecting “Quit” wouldn’t work for me hence the “Force Quit”.

I hope this saves someone else the head-scratching as to why their Mac is running hot.

Using Artifice to Stub Server Responses

In a recent project I needed a way to fake a response from a server in my Cucumber features. Specifically, I was testing integration with a payment gateway and wanted to stub it’s responses based on different requests.

In the past I have used FakeWeb, however it becomes a little hairy when you need to stub a response based on request body. I came across a couple of alternatives, firstly WebMock which looks promising but then Artifice from the mighty Yehuda Katz caught my eye…

Artifice lets you “replace the Net::HTTP subsystem of Ruby with an equivalent that routes all requests to a Rack application”. I like the simplicity of this solution as you can in essence use a Rack application to replace the responses of the service you are testing.

An Example

First we create a simple Rack application to stand in for the server we are interacting with.


app = proc do |env|
  [200, { "Content-Type"  => "text/html" },
    ["Hello world: #{env.inspect}"]
  ]
end

Then we simply use Artifice’s “activate_with” method to wrap any requests.


Artifice.activate_with(app) do
  response = Net::HTTP.start("google.com") do |http|
    http.post("/the_url", "foo=bar")
  end
  puts response.body
end

This allows for a Rack app to be used as a stand in for a complete API, it could be a Sinatra app for example allowing for easy route handling. We could go so far as to have a series of Rack apps that can be used as stand-ins for common API’s.

Why I stopped using Pickle with Cucumber

…no, not because it leaves a bitter aftertaste, I’m talking about the Pickle step definitions for Cucumber.

I have lately been using Pickle when writing Cucumber features, however I have come to the conclusion that this is a bad idea. The reason being that when using Pickle, you create entries directly, whereas the whole point of Cucumber is that it is for high level integration testing.

What I do now, is to create any entries by filling out and submitting the relevant forms with a step definition, for example I may have the following:

Given an admin has created the following products
  | Name    | Variants                                  | Featured |
  | T-Shirt | Small: 10.99, Medium: 12.99, Large: 14.99 | Yes      |
  | Keyring | Default: 2.99                             | Yes      |

I would then write a step definition for this that would log in as the admin user, break this table apart and fill in the relevant forms.

I would go so far as to say that using factories at all in features is a bad idea and instead everything should happen via the user interface for better coverage. For any data that is known to exist when the app is deployed via ‘rake db:seed’, this can be loaded in the ‘env.rb’ file e.g.


load 'seeds.rb'

Update 11/2/2010: Sometimes this is simply not practical due to slowdown which is a shame, as noted by Amos in the comments.

Devise Rails Authentication Gem Rocks!

I’ve had a set of rather bespoke requirements for authentication on a recent project and thought I’d give Devise a go.

Devise uses Warden, which is an authentication solution build on Rack making it extremely flexible and usable across multiple frameworks e.g. Rails/Sinatra. Also, Devise is extremely modular meaning to can easily write custom “strategies” for specific behaviour.

I have used Clearance in the past which is great if you want an engine that will just work. Devise however is by far the most flexible and extensible solution that I have come across with the same ease of use as Clearance. The only thing that you don’t get with devise that you do with Clearance is the signup stage, however as this is normally custom on a per-app basis I can live with this.

One more thing to note is that Devise lets you have multiple auth systems in play e.g. one for users and one for admins.