:neil_middleton - Ruby on Rails, Web Application Development and bollocks extraordinaire

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.

Loading mentions Retweet

Filed under // Heroku Rails

Comments [0]

June 8, 2010

Case Insensitive searching with PostgreSQL

Earlier today (well, a few minutes ago), I had a requirement to make an existing LIKE search case-insensitive with PostgreSQL.

Normally this would prove to be messy, by trying dirty tricks such as downcase-ing content in the search (using UPPER and LOWER) - however, it's pretty straightforward.

For instance, the case-sensitive code would be something like:

Whereas, to make it case-insensitive, try a bit of Borat:

Job done.

Loading mentions Retweet

Comments [0]

May 24, 2010

And people thought the App store was big...

"There are over 100,000 applications leveraging the Twitter API"

- http://blog.twitter.com/2010/05/twitter-platform.html

Loading mentions Retweet

Comments [0]

May 17, 2010

It's amazing what people want signed off

So, it's now been a month or so since Boxfile launched into beta, and it's been a busy one. We've been getting a fair few signups, but what is more interesting is what people have been getting signed off.

Aside from the usual suspects of requirements documents, invoices, and designs, we've had a fair few interesting use cases so far.

For instance, we've had some timesheets that someone needed their employer to sign off. We've had a couple of TV ads that someone was posting on YouTube as part of a viral ad campaign. We've even had the entire floor plans for a local hotel signed off as part of a redevelopment.

It's been really interesting talking to people and finding out how they've been using the tool and what ideas they have for the future. I've already got a list of things that people have fed back on that will only serve to make the application better in the long run - hopefully I'll be able to post about those soon. In the meantime, if you've not checked it out, please do so, it might help you out with some other use case I'd never even thought of.

Loading mentions Retweet

Filed under // BoxFile

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.

Loading mentions Retweet

Filed under // Rails

Comments [3]

May 5, 2010

Forget Mobile, the web is where it's at

Over the last few months, it would appear that global internet thermonuclear war has set in.

This, for the most part has been surrounding the mobile platforms out there. Apple's i(Phone/Pad/Pod Touch) has been battling Google's Android, Apple has been battling with Adobe over Flash, and then there's the patent wars between Apple, Google, HTC and Microsoft.

It's a pretty big fight.

So, what do developers do? From a skills point of view we want to be aligned with the most popular platform that will give us the most marketability - yet from a business point of view we want our applications to work on as many platforms as possible to maximise the 'attack surface' in the various markets out there and gain the most revenue.

Then there's the different markets - Apple have their draconian approval process, but provide the class leading App Store, whereas Google is all about free-love and sell it how you want.

Then there's the platforms. Objective-C, Java, Regular C, Flash etc etc etc etc. The list goes on.

So what are we developers to do - how are we supposed to navigate through this minefield of options? Well, it's pretty simple actually:

Ignore it.

Every mobile phone manufacturer is striving to produce a browser on their phone that can view the whole web in a similar way to a desktop computer, and all are striving to support the latest and greatest. Therefore, surely the easiest way for us web developers to bring an application to a phone is to simply look at it through a browser?

Picture this, you have an application out there in the wild, you want it to work on the iPhone, so use Safari - job done. It'll also work on Android with no changes, and is also not dependant on Apple's approval or anything else, you can do it how you want. Additionally, with libraries like JQTouch you can access phone hardware should you want to.

But OK, this isn't ideal for all situations. You won't have offline access as such, you won't be able to build games, you won't get amazing performance - but for the most part, that's not a big trade off for most business focused applications.

So, in short, why are we worrying about learning all these different tools to make our applications available on different mobile platforms, when we are already expert in the single tool that will make our app truly cross platform - the good old world wide web...

Loading mentions Retweet

Comments [0]

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.

Loading mentions Retweet

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.

Loading mentions Retweet

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.

Loading mentions Retweet

Filed under // BoxFile Rails

Comments [0]

April 20, 2010

Why sign off sucks...

It's a fact of modern life that projects don't always go the way they should, be it for lack of time, budget or a scope that's too large. Another major reason for projects going awry is that of misunderstanding. It happens every day, and every single one of us at some point has generated some work for someone without fulling understanding what was required, and thus having to waste time doing more work to make things good again.

And if that's not happened to you, you're a dirty liar ;)

So, what do we do to get round this? Well, for starters we collectively hold a belief that a signature will make everything good. We believe that a note from a client saying "Yes" makes it all good, and we'll never waste time farting about getting things wrong.

Unfortunately that's not what happens. Most small business get their agreements in a completely haphazard way. Those that have a process for sign off are by far and away in the minority.

So what?

Well, put yourself in the position of a client. You've been dribbled some designs and requirements from your agency, but notice that something you need isn't explicitly mentioned. You recall that the only agreement you've given was as a side comment on phone call so you go for broke. You phone up your agency, and proclaim that you DID want your site to support IE6, and yes, it is a definite requirement that's been mentioned lots of time.

Bugger

You the agency don't have anything explicitly stating IE6 would or would not be supported so what do you do? Do you refuse and ask the client for more money, and potentially risk pissing them off and losing them, or do you take it on the chin and bear the cost of the work, because you can't prove the client never asked for it?

All this costs money.

Well, imagine this. Imagine that you were able to store documents in a location, and know that when the client has signed off that you have a read-only store of what the client has agreed to. Imagine that you can turn round to a client and say "Sorry Bob, that's not mentioned in the documents you've signed off, so that's an extra charge...". Imagine being able to take that snapshot that a particular user agreed to a particular set of information and be able to prove that to anyone that's interested at any time.

This is where BoxFile comes in, and where I've primarily focused the application. If you find that sign off is a bit of a problem for you, please, have a look, have a play and use it for a bit. There's already a fair few people using the system and loving it, but I would be directly interested in your own feedback. As a reward for getting involved, all sign ups in this beta phase will be awarded a 10% discount for life once the application comes out of beta (there will still be a free version if you don't fancy that). Beta accounts are free and unlimited, so it's a great time to have a try.

What's more, if you like BoxFile and blog about it, send me a link (neil [at] theskunkworx [dot] com) to the blog post with your BoxFile account details, and you'll be set for a 25% discount for life.

Loading mentions Retweet

Filed under // BoxFile

Comments [0]

Tags