We love Heroku. It makes deployment so easy and quick. However, it can start to get pricey when you add additional dynos at $35 each a month.
With a small amount of work, you can get a lot more out of your Heroku hosting whilst drastically improving the performance of your site. You might need to spend a little bit of cash on other services, but a lot less than if you simply moved the dyno slider up a few notches, and the result will be much better scalability.
So how do we max out the performance of our Heroku apps? First we stop using Heroku for things it’s bad at, then we let it do more of what it is good at, running your application code.
I have an application where a lot of work gets done behind the scenes by worker processes, scripts and rake tasks. I have a sweeper for one of my models to clear out some caches that can’t be cleared automatically using DHH’s key-based expiration technique. The cache keys in this use case are simple strings.
You can file this in the “things I wish I’d known about years ago” pile along with the
bundle open command…
If you want to dump the contents of an object on the Rails console in a nice and readable YAML format, just use the function ‘
> y Company.first
Company Load (0.3ms) SELECT "companies".* FROM "companies" LIMIT 1
created_at: '2012-05-31 10:58:57.070819'
updated_at: '2012-06-27 10:47:44.662756'
I’ve no idea how it’s taken me this long to find out about it, but I’m glad I finally have.
Normally when I create a selection box in form it is linked to a fact-table model, a model that exists purely to represent the options in the select, but doesn’t have properties of its own.
No matter how good the documentation for a Ruby gem might be, from time to time you’ll probably need to dig around in the code to check or confirm exactly what it does, or what options it might take.
I recently ran into a bit of a gotcha concerning the way nested records get updated in Rails, which in hindsight makes total sense, but caused some confusion at the time.
In my spare time I’ve been working on a site to help people find their lost pets, Lost Pet Alerts. People sign up, tell it roughly where they live (postcode and country), and when pets near them go missing they get an email.
This is the first of a series of short posts on little features in Rails that are occasionally useful, but easily forgotten.
Sometimes it’s easy to forget that Rails’ ActiveRecord is built on relational databases and fall into the trap of doing things with comparatively complex bits of Ruby when they could be done in one go in SQL, more easily, and faster.