:neil_middleton

Ruby on Rails, Web Application Development and bollocks extraordinaire 
Tags


Filed under

Rails

 
July 20, 2010
 

Getting RPM working with Rails 3.0

Note:  This has only been tested to work with Heroku, my hosting service of choice.  It's not been tested anywhere else.  Regardless, you should still test everything yourself.

RPM is a fantastic tool for seeing how your Rails application performs in production, and to be honest, having run some production apps without it, you are completely blind if it's not set up.

However, the arrival of Rails 3.0 has brought some far reaching changes to the way the framework works, rendering the RPM gem useless with Rails 3.0.  However, NewRelic have a newly released version (2.13.0.beta5) which works with Rails 3, and I have running in a couple of production environments.

So how do you get it up and running?

Well Rails 3 means bundler, so first step is to include the following in your Gemfile:

One this is done, create config/initializers/newrelic.rb and simply include:

Deploy the code when you're ready, and then flip on the New Relic add-on at Heroku.  Hopefully, your apps still running, but now with added RPM goodness.


Filed under  //   Heroku   Rails  

Comments [0]

May 10, 2010
 

Rails 3 and escaped HTML

Something work remembering that keeps catching me out is surround Rails 3 and it's assumption that everything is NOT html safe (a change of opinion from Rails 2).

Now, all strings are html escaped by default:

To unescape the HTML (i.e you already know that the string is OK to render out), you need to mark it as html_safe:

Simple.


Filed under  //   Rails  

Comments [3]

April 28, 2010
 

Adding a LIKE criteria to a Rails Conditions block

Earlier I had a interesting problem setting conditions on a query using Rails and ActiveRecord.


Consider the following code which is to be thrown at an AR find:


I needed to add another condition which is a LIKE criteria on a 'profile' attribute. How could I do this, as obviously a LIKE is usually done via an array, not a hash key?

Well, as usual, it's actually pretty simple through the use of anonymous scopes.  You can pass around these scopes as first class objects using 'scoped' (a named scoped provided to you for free) as a way to build hairy queries on the fly.


So, to solve my original problem, I simply need to do this:


Job Done.


Filed under  //   Rails  

Comments [0]

April 27, 2010
 

Full Text Search in Rails with Thinking Sphinx

These days there's a common requirement to be searching data in a way that's not just a simple find query. People want to search against text, and do weird and wonderful things like fuzzy searching.  As I've been blogging about Rails a fair amount recently in a "Look Ma! I just figured this out!" way, I thought I would talk about how this could be done.  The requirement I have is to search property in a model that consists of text and  search it in as flexible way as possible (a LIKE just won't suffice here)

First up, I'm talking about using MySQL, so this probably won't apply to PostgreSQL or anything else.  Secondly, I'm also running this on Ubuntu Hardy in production and developing it on OS X 10.6.3.  If you're using Windows or similar to try and implement this, good luck.  You're on your own.

First up, I'm looking at using Sphinx, the full-text search engine.  The reason for this is that seems to be the most widely used and has a couple of nice gems out there for dealing with it in the shape of ThinkingSphinx and UltraSphinx.  For this project I'm using ThinkingSphinx due to the reasons laid out by Rein Henrichs from HashRocket back in 2008.

Once you've installed Sphinx and ThinkingSphinx int your application, you need to think about what you want to search.  In my case I only have one thing to worry about so I just need to define that in my model (the property I want to search is called 'goals'):

Simple.  Next up, I need to tell Sphinx to index the data I have in my database with a simple rake call, and then I need to fire up the sphinx process:

(Note that you can ignore the error about skipping the model - it's a Sphinx thing.

Next, is where you need to....do nothing - you're done.  You can now search your model with a string and get results back...

Now, obviously this is a very very high level overview on how to get started, so your best bet is to check up on the documentation, there's loads more info there.


Filed under  //   Rails  

Comments [0]

April 26, 2010
 

Using Memcached with Rails

Recently, during the development of BoxFile, I decided that I needed a nice caching layer on the site to alleviate unnecessary load on the server, but to also speed the application up on some of the more intensive pages such as the document view.  After a couple of minutes research, it transpired in Rails that this is actually pretty easy.

Enter Memcached (pronounced memcache-dee).  Essentially Memcached is a heap of key value pairs stored in a nice high performance service that available over the network.  Given that memcached is cluster-able, this means that you can practically have a infinitely big network cache for your application, which is great news.

However, most apps don't need anything like that amount of stuff, a cache of a few megabytes is ideal (and the heroku memcache makes it insanely easy to setup too).

But how do you use it?

Well, it's as easy as you could imagine.

Let's say I have a bit of view that I want to cache that contains a render of a blog post article.  In order to cache it with memcached, I simply need to install the memcached gem, tell Rails I'm using Memcached for my cache store,

and then mark out what needs caching with a block:

What Rails does here is spot the @post object, and generate a key based off that and it's updated date.  This then forms the key that gets used in the cache.  When the post changes, so does the key, which means no cache item is found and the item with re-generate and cache itself in the process.
Let's say for instance that the view thats, say, specific to a user in it:

works just as well, as does

Basically, if you can generate a unique key then that cache item can be found again.  If you need a new version, use a new key (hence the use of updated dates), and Memcached will automatically worry about expiring the old fragment when it needs to.

However, note that there's a catch in Rails 2.x.  If you're caching a view, remember that any code in your controllers will run regardless as the SQL itself will be cached.
There's a few ways around this given that Memcached doesn't only store Strings, but also hashes and so on.  ActionController::Caching::Fragments is your friend here.

In Rails 3.x this isn't an issue as queries are only executed by ActiveRecord when the query result is iterated over (and if it's cached, this won't happen)
So, all in all, it's pretty simple this caching game, to the point where I was able to implement all the caching I need for now in an hour or so, and whats more, I know it'll scale, unlike file system or database based caches.  For proof, read up on the Facebook implementation.

For more information, check out the screencast over on NewRelic.


Filed under  //   BoxFile   Rails  

Comments [0]

April 14, 2010
 

Rails 3 - error_messages and error_messages_for

One small gotcha that's worth noting about the Rails 3 release is one of the many deprecations that are in the release:

In the olden days you'd show user's error messages with:
 
<%= form.error_messages %>
 
Nowadays though, in Rails 3, this is deprecated and has been moved out to a plugin.  The more observant of you will have spotted the following in your console:
 
DEPRECATION WARNING: form.error_messages was removed from Rails and is now available as a plugin. Please install it with `rails plugin install git://github.com/rails/dynamic_form.git`.

So, do what it says...
 
Lo and behold, your error messages appear again...


Filed under  //   Rails  

Comments [2]

April 14, 2010
 

Rails 3 - the new sexy

At the moment, Rails 3, the new version of the Ruby on Rails framework is nearing the end of it's beta process before a release into the wild.  And being open source, it's a tool that everyone has a say in, and that everyone can affect in some way or another.

Whilst it might not really mean anything to a regular web user, this has a big affect for us developers.  Rails 3 means that we can now build better applications faster, and the resulting applications are faster, and more reliable. In addition to this, there's a fairly smooth upgrade path from Rails 2.

If you've not checked out Rails before, do so, it will open your eyes somewhat to what is possible with good tools, and if you're using Rails already, get up to speed with the new features.  Rails Dispatch is an excellent place to start.


Filed under  //   Rails  

Comments [0]