Have you ever created an application where users are trusted to upload their own avatars? Wouldn’t it be great if there was an easy way to ensure the avatar contains a person’s face?
Has Face is a neat little gem that uses the face.com API to ensure that an image contains a persons face. It’s very simple to use and can be easily integrated into an existing rails application.
To get started add the has_face gem to your Gemfile and run a bundle install
Now we’ll need to make a face.com developer account. You can signup for a free account over at face.com. Once you have signed up, place your API key and API secret in the initializer config.
The last option in the initializer (skip_validation_on_error) will change the behavior of has_face when an error occurs. If set to true, when an error occurs a warning will be logged to the logfile with detailed information about the failure and face validation will be skipped. This can be useful if you want your application to function if the API service is not reachable. If the value is false then an exception will be raised when an API call fails, this will allow you to manually handle the exception yourself, please check the documentation for details on the errors raised.
Once the initializer settings are setup then we can add face validation to a model. In the example below I’m using carrierwave to attach the image to the model but other image attachment gems should also work fine (anything that correctly responds to `path` should be OK).
That’s it, that’s all we need to have a functioning face validator. There are a few other options that I haven’t covered here in this short guide, please consult the readme for more detailed information.
“Whilst prototyping the early stages of a new app with Filter Squad, we found ourselves prototyping a lot of API clients for new versions of APIs that were lacking up to date clients or in the case of other APIs, were missing functionality we required.”
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.