I don’t do personal blog posts often. This post is an exception because the hemju blog was pretty silent for some time and I just wanted to let you know that the blog isn’t dead.
I worked till End of January for the Austrian startup Jumio. It was quite an experience (good and bad) and I learned a lot of how the startup scene works. Maybe I will write a follow up post about this experience because I believe many fellow start-uppers would benefit. However, time will help to give a more objective opinion.
So what I have done since then? I had the great luck to team up with a good friend of mine and start a company of our own, lingohub. lingohub will be what I envisioned for lingui.st. I won’t spoil much right now, but let’s say we want to change how software is translated for good. Actually our credo is, software that isn’t translated is broken. Hence, we set our standards high. You will hear a lot of it over the next few weeks and a beta is just around the corner.
So, the good news is you can expect this blog to be reactivated again. I will probably focus on development topics and startup topics like financing, contracts, HR, … as well. Should get very interesting.
This post is no longer valid, since face.com was acquired by facebook and doesn’t provide an open API anymore.
We all know that we can search web pages for text, but there are services that go beyond a simple text search and use features like location and or image data. The hurdle relying on these features is that normally the end users have to enter manually the appropriate data. When was the last time you tagged people Facebook? Now think what if we have a system that helps us to automate the process of face recognition. Lets understand face recognition and how you can use it with Ruby.
What is Face Recognition?
Face Recognition uses feature extraction from facial points (like detecting where the eyes, nose, mouth etc are) within images or videos to recognize people. As you can image such a task isn’t trivial and requires a lot of know how. But the good news are that facial recognition just got a lot easier for developers to include in their applications. Face.com, a company that specializes in facial recognition, opened its platform APIs, allowing developers to integrate its facial recognition technology in third-party websites and applications.
Developers Get Facial Recognition API from Face.com
The face.com API uses REST-like interface. This means that all calls to the API are made over the Internet, using HTTP GET and POST requests to the face.com API server. Hence, any programming language that supports HTTP can be used to communicate with the service. Face.com has some common libraries to get you started.
How to use it with Ruby ?
Step 1: Get your API Key from http://developers.face.com/account. Don’t forget to add Facebook API and Secret Key as well as Twitter API Key And Secret Key. Keep them handy to use in your application.
Step 2: To use Face Recogonition API in Ruby we have to install the gem called ‘face‘. sudo gem install face
Step 3: Now using api_key and api_secret, you can access get_client method of API.
>> client = Face.get_client(:api_key => ‘your_api_key’, :api_secret => ‘your_api_secret’)
Face Detection using Face gem in Ruby
Face gem provides three different ways to detect faces in an image.
Detect Faces with Urls
Detect Faces with Raw image data
Detect and Recognize faces with user auth
Lets understand with examples.
Detect Faces with Urls:
Suppose we want to detect face in the image located at this url. You will have to use faces_detect method as given below.
It will return photo detection output in the following way. Notice that you here you get face related information in a JSON format.
Detect Faces with Raw image data:
To detect faces from Raw image data, you will have to use following.
Detect and Recognize faces with user auth:
Hereby we are trying to recognize face with twitter credentials.
First we will have to initialize twitter credentials like this:
Step 2: To send the face recoginze request , write in the following way.
Note that uid is the id of the user on twitter.
The face gem provides facilty to detect faces from multi or single face images. Face gem is still under development. You can test it on face.com site. To get a feel for what is possible with the API you can browse some of the online examples, complete with source code, or play in the API sandbox. The face.com API has some decent documentation for those looking to dig deeper into the service, although the forums are fairly quiet at the moment.
In simple terms we can define scheduling as “the process of deciding how to commit resources between a variety of possible tasks“. The scheduling is basically a function which enables us to perform routine tasks at some predefined time or as part of a sequence. These tasks are normally executed in the background by so called “workers”.
Now the question is what’s the best way to run scheduled tasks in a Rails environment? Generally, Rails developers can use an application specific crontab to run application tasks. “Cron” is a time-based job scheduler in Unix-like operating systems (Linux, FreeBSD, Mac OS etc…). And these jobs or tasks are referred to as “Cron Jobs”. Downsides of Cron are:
Cron works well on a single server but what if you need to scale to multiple app servers? You’ll need to introduce some kind of lock to avoid concurrency problems. Also, you need to maintain these shared locks.
The other problem with Cron is that they are difficult to debug.
Cron is for scheduling things, not doing them.
This can almost always be better to place jobs in queue and place the worker system to perform or to execute those jobs. Luckily there is a very good gem named ‘resque‘ available in Ruby on Rails.
Introduction to Resque
Resque is a Redis-backed Ruby library for creating background jobs, placing those jobs on multiple queues and processing them later. The main benefit withResque is that it allows you to create jobs and place them on a queue, then, later, pull those jobs off the queue and process them.
For the backstory, philosophy, and history of Resque’s beginnings, please see the blog post. Besides that recently I came to know about other two plugins which are available in Ruby on Rails for job scheduling. One of them is resque-scheduler and the other is rufus-scheduler. Lets have a look at both both in detail.
Resque Scheduler – A light-weight job scheduling system
Resque Scheduler is an extension to Resque that provides both scheduled and delayed jobs. This service can replace cron and bring the ability to schedule task to execute at certain times. Resque Scheduler support job scheduling in two different ways: Recurring or Scheduled (a standard cron job) and Delayed.
Recurring or Scheduled job
A recurring/scheduled job is a task that is specified to be run at a certain time. For example you may want to update any indexes at midnight everyday; this is a scheduled job that runs based on a fixed schedule which is set at startup. The schedule is just a hash, but is most likely stored in a YAML. Delayed job
A delayed job is a job that gets put on the queue with a specified time in the future to run at. For example you may want to schedule a followup email to go out a few days after a user has signed up.
How To use Resque-scheduler?
First of all Install Resque Scheduler. Create sample application or you can get the sample application from the github.
Next step is to modify Gemfile to include
Run $ bundle install. Now its time to Configure Resque Scheduler. In our sample we use a Redis service, of course you can use your own Redis Server as well. Go to Redis To Go and sign up for the free plan. Once you have an instance, grab the URL given to you and modify the config/initializers/resque.rb as follows:
Create a job named eat in app/jobs/eat.rb
Inside config/initializers/resque.rb place the following code so that app/jobs/eat.rb is loaded.
Create controller file and add code
Add following line in routes.rb file
You also need to add file tasks/resque.rake
Finally create the crontab for Resque Scheduler. Create file config/resque_schedule.yml and insert the following text:
To load the schedule when we initialize Resque add the following line to config/initializers/resque.rb
At the end Start the Scheduler Process
Rufus Scheduler – scheduler for Ruby (at, in, cron and every jobs)
Rufus-Scheduler is the latest version of a scheduler previously known as openwferu-scheduler. It is a Ruby gem for scheduling pieces of code (jobs). Rufus-Scheduler understands running a job AT a certain time, IN a certain time, EVERY x time or simply via a CRON statement. But we must note that rufus-scheduler is no replacement for cron since it runs inside of Ruby. The scheduler doesn’t do any server-side tasks to get jobs to run, but relies on its scheduler being run up and maintained persistently (or semi-persistently, as with Rails app processes that will tip the scheduler into action).
It doesn’t require any database table, queueing mechanism, or separate process to manage. Just a simple scheduler to call out to your existing ruby code. No need to register at anything. You have to include only one file in config/initializers and add the task you want to schedule. Whenever you start your server that tasks are done or performed at specific time. So ultimately it saves the time of queuing and you get the work done.
How To use Rufus-Scheduler?
First of all create a sample application.
rails new sample_app
Then add rufus_scheduler in Gemfile
Install the gem with bundle
$ bundle install.
Add following lines in config/initializers/task_scheduler.rb
You can also test above code on console.
Rescue Scheduler offers a simple and easy way to add scheduling abilities to any queueing system and is well worth the move from cron. But if you do’t want queuing and want only some scheduled jobs than rufus-scheduler is the best option.
We all know that there isn’t a fixed roadmap/release date for Ruby on Rails 3.1, but there are definitely rumors about the new features and improvements. Yehuda Katz, a member of the Ruby on Rails core team, said “With 3.1 we’ll go back to basics and look at things that are less invasive internally, but could have a big impact on developers. If you want to check latest updates then click here and check milestones for Rails 3.1. It’s really a good news that just 26 tickets are remaining out of 68 total tickets.
Lets talk about new features which will be integrated with RoR 3.1.
Object Scopes in Rails 3.1
The change that is made to object scope is :
The above code describes that with Rails 3.1 it is possible to pass objects to scope methods that responds to the method ‘call’. Let’s understand what it means. Currently, with Rails 3 or Rails 3.0.x, scope works in the following way. For example, if we want to get all the products with name “Nokia” and with category “Mobile”, we used to create its scope method as given below.
Now to get required data, we use it like
But what if we have multiple classes that share the same logic for a named scope?? Suppose we want to get all the users with name = “John” and category = “Manager”. Think for a moment. In such cases it is obvious that we should be able to reuse same filter/scope code. Luckily, RoR 3.1 will provide exactly that kind of reusability. It will be possible to create classes that acts as scopes/filters.
In Rails 3.1, scope will be reused in other modules like this:
Its simply great !! Changing a simple is_a? to a respond_to? can unlock quite a power.
Rails 3.1 > Integration of Spriting
<% sprite_css(“icons”) %> this code does two things. First is to combine all the images within a single folder and second is to generating its CSS. The advantage of using such technique is to reduce dozens of HTTP requests into one cache-friendly image file.
Keep js/css close to the code in view folder
What is going to be deprecated in Rails 3.1??
Passing options hash containing :conditions, :include, :joins, :limit, : offset, : order, :select, :readonly, :group, :having, :from, :lock etc inshort, finder methods which are provided by any ActiveRecord class will now be deprecated in Rails 3.1.
In Rails 3 a couple of constants/methods were set deprecated. However, there are still plugins which use them. This ends normally in the annoying log message:
DEPRECATION WARNING: RAILS_ROOT is deprecated. Please use ::Rails.root.to_s. (called from <top (required)> at /Users/heli/hemju/programming/workspace/rubymine/linguist/config/application.rb:12)
So what to do when you want to get rid of them? Find them, (optional) create a patch, and report them to the plugin maintainer. One easy way to find deprecated elements is to override them and let them throw an exception or set them to nil. So in the above case, I would add RAILS_ROOT = nil to an initializer. At the next startup there will probably be an exception thrown and you know exactly where to find the deprecated method. Now start patching.