It’s been a busy few months at The Frontier Group.
Firstly, a congratulations to our very own Darcy Laycock for winning a Ruby Hero award. The Ruby Hero awards are put in place to recognise people that have gone above and beyond in the Ruby community.
We’ve rolled out our new Frontier Group blog design, and would love to hear what you think of it in the comments below. We’ve also added a Featured Posts section in the sidebar, so you can see what other visitors (and hopefully you) are interested in too.
We’ve been heavily featured in a range of Podcasts recently, such as Ruby5 and The Ruby Show. Also we’ve been featured in prominent Ruby and Rails websites such as Ruby Weekly and Ruby Rogues.
We’d love you to keep visiting. Sign up to receive our newsletter using the form to the right, or stop back here from time to time. Don’t forget to check out the rest of our site and see what we’ve been working on.
So all you’re doing is setting the cached instance variable to the environment you want.
Follow Up (June 20, 2011)
So two distinct issue have come up as a result of the above content.
Firstly, there was no ensure meaning that if an exception was raised in the middle of the stub then the environment would be changed for the remaining tests. This was a stupid mistake but, it happens, so I’ve updated the gist and my code.
Secondly, the issue of checking environment in code. The solution for this would be to have a constant in each env file that defines whatever it is you are using the env check for. So in the example I was working with each env file would have a EMAIL_TARGET constant.
You still need to test this, so the stub provided is still useful in this regard.
The only problem I encountered is that including Compass in the previously detailed way does not include any of the Sass Extensions. They’re written in Ruby, so just setting a SASS load path isn’t sufficient.
Update: see my updated post with details of a newer, better solution.
If you’re like me, you’re probably already playing around with the Rails 3.1 release candidate. If not, go take a peek at why you should be excited. (Thanks Ryan Bates!) If so, like me, you’re probably also wanting to play with all your old friends, like Compass.
Compass, by default, manages SASS for you. It gives you a place to put it, app/stylesheets, and takes care of bundling everything together. The new Rails 3.1 asset pipeline does this all for you using Sprockets instead, and does it nice and cleanly in a consistent manner with CoffeeScript and whatever else you might eventually integrate.
The problem is, I don’t want Compass managing my SASS. I like love the asset pipeline. But by default, from the asset pipeline I can’t use Compass. It doesn’t know what or where it is. So, I’ve added this to my new rails 3.1 projects:
I’m also a heathen and like SASS, not SCSS, and it took me a minute to realise that it’s just as easy to use. Instead of mystyle.css.scss, name your stylesheet mystyle.css.sass. To make rails do this by default when you’re generating controllers et al, add this into your config/application.rb‘s config section:
You can even rename the default application.css to application.css.sass and all the sprockets require_* machinery still works. Make sure you change the /* ... */ comments to // comments.
I was part-way through submitting an answer on Stack Overflow when the initial question was deleted. The developer was having an issue with Rails thinking that the singular of “faxes” was “faxis” when in fact it should be “fax”.
I thought it was an interesting problem, so here’s the answer I prepared:
You can overwrite or set Rails’ singularizations and pluralizations (properly called inflections) in config/initializers/inflections.rb
As you can see below, Rails now understands how to count “faxes” correctly. One fax, two faxes, three faxes, and so on. You can test that from within the Rails console: