Yesterday I was experimenting with Google App Engine for a little project that I was working on. I literally started from ground zero and could do my thing after a long night. I’m blogging about it to share you the idea and save you some time googling solutions. So, here is the thing in brief: I wanted to parse some feed on periodical basis and send an email with new entries.

Looks like a 10 minutes with Nokogiri and cron jobs. Actually that’s true except of the fact that I need to pay for a VPS so that I can run the script with various gems (since I needed to do some work on the feeds before sending, but that’s for another topic) and for using cron jobs. Thus, I decided to try something new this time and I went with GAE since it has memecached that I can use as an LRU cache, also it has cronjobs and finally it has a mail system. I’m using JRuby and Sinatra for this project.

Here are the steps:

Install JRuby, I’m using RVM on my machine:

rvm install jruby-1.5.5
rvm use jruby

Install needed gems, those versions are the ones which worked for me:

gem install jbundle
gem install appengine-sdk -v "1.4.0"
gem install google-appengine -v "0.0.19"

Create a simple app:

appcfg.rb generate_app notifier
cd notifier

Now let’s create the following files (Please note that the following code can be further enhanced):

Gemfile

# Critical default settings:
disable_system_gems
disable_rubygems
bundle_path ".gems/bundler_gems"
 
# List gems to bundle here:
gem "appengine-apis"
gem "appengine-rack"
gem "sinatra"
gem "sinatra-reloader"
gem "jruby-rack", "1.0.4"
gem "nokogiri","1.5.0.beta.3"

config.ru

(fill the sender/receiver emails and the feed URL)

require 'sinatra' 
 
set :sender_email, 'SENDER_EMAIL'
set :receiver_email, 'RCEIVER_EMAIL'
set :feed_url, 'FEED_URL'
 
require 'app'
run Sinatra::Application

app.rb

require 'digest/sha1'
require 'appengine-apis/memcache'
require 'appengine-apis/logger'
require 'appengine-apis/mail'
require 'appengine-apis/urlfetch'
require 'sinatra'
require 'sinatra/reloader' if development?
require 'nokogiri'
 
 
class Fetcher 
 
  def initialize(sender_email,receiver_email,feed_url)
    @sender_email = sender_email
    @receiver_email = receiver_email
    @feed_url = feed_url
  end
 
  def act
    send_email(create_message(get_results))
    "done"
  end
 
  private 
	def memcache
    @memcached ||= AppEngine::Memcache.new(:namespace=>"cache")
  end
 
        # get the new results only
	def filter_results(results)
	  res = []
	  results.each do |hashed_guid,info|
	    if memcache.get(hashed_guid).nil?
	      memcache.set(hashed_guid, 1)
	      res << info
	    end
	  end
	  res
	end
 
        # parse the feed
	def get_results
	  results = {}
	  doc = Nokogiri::XML(AppEngine::URLFetch.fetch(@feed_url).body)
	  doc.css('item').each do |item|
	    title = item.at_css('title').content
	    link = item.at_css('link').content
	    description = item.at_css('description').content
	    guid = item.at_css('guid').content
	    results[Digest::SHA1.hexdigest(guid)] = {:title => title,:description => description, :link => link}
	  end
	  filter_results(results)
	end
 
        # create email message
	def create_message(results)
	  template = ""
	  results.each do |info|
	    template += <<-DOC
 
	      Title: #{info[:title]}
	      Description: #{info[:description]}
	      Link: #{info[:link]}
	      --------------------------------------------------------------------------------------------
	    DOC
	  end
	  template
	end
 
 
	def send_email(message)
    AppEngine::Mail::send(@sender_email,@receiver_email,"New updates for the site",message) if message.length > 0
	end
end
 
 
get '/' do
  "Hello World!"
end
 
 
get '/notify' do
  Fetcher.new(settings.sender_email,settings.receiver_email,settings.feed_url).act
end

cron.xml

(You can set the period here, I’m using 15 minutes intervals)

<?xml version="1.0" encoding="UTF-8"?>
<cronentries>
  <cron>
    <url>/notify</url>
    <description>fetch new data</description>
    <schedule>every 15 minutes</schedule>
  </cron>
</cronentries>

Now, create an application-id at appspot.com. Then go to Administration >> Permissions and make sure the sender/receiver emails play some role in the app. Personally, I granted them the developer role.

Now, go back to the source and modify the application-id in WEB-INF/app.yaml

application your-app-id

We should be ready now, start development server, watch the console and make sure no exceptions are there:

dev_appserver.rb .

If everything is OK, go to http://localhost:8080/notfiy and you should see “Done”.

Let’s go live now:

(the first time you execute this, you will prompted to submit the GAE email/pass combination)

appcfg.rb update .

It should now be running at http://your-app-id.appspot.com, and in few minutes you should be receiving the first email. If not, go to app engine page then to Main >> Logs and check what’s the problem.

I like this stack cause it’s Zero cent cost, Zero deployment time, flexible, and it gives me exactly the freedom I want in terms of needed gems. Give it a shot, you won’t regret it!

It’s true that I’m not the qualified guy to talk about Java’s power,as it has been 2 years since i last practiced it, but i feel like i have to communicate my thoughts to the people that didn’t give JRuby a trial yet, and why they should do so.
If you never worked with Java before, then don’t panic, cause in these article i would list several reasons why JRuby is so powerful even if you don’t know anything about Java.
Lemme start listing all the points that makes me feel the power of JRuby; the order here is irrelevant as i do believe that every point listed bellow has somehow the same rank that others might have:

1- Mixing the power of Java with the power of Ruby.
2- A faster(if not the fastest) Ruby implementation.
3- Native Threads.
4- Support for Foreign Function Interface(FFI).
5- Make use of the JVM (HotSpot).
6- Have a great community and support.

Mixing the power of Java with the power of Ruby

There are thousands of Java packages that are ready for you to use, and according to TIOBE, Java is continuing to be the most popular language, so why don’t you make use of the existing Java packages, and use them inside your code?
For example, you can use the swing package(a very powerful GUI package) inside your ruby code, the following snippet of code is taken from the samples folder in the JRuby distribution:

# Import Java packages
include Java
 
import javax.swing.JFrame
 
frame = JFrame.new("Hello Swing")
button = javax.swing.JButton.new("Klick Me!")
button.add_action_listener do |evt|
  javax.swing.JOptionPane.showMessageDialog(nil, <<EOS)
<html>Hello from <b><u>JRuby</u></b>.<br>
Button '#{evt.getActionCommand()}' clicked.
EOS
end
 
# Add the button to the frame
frame.get_content_pane.add(button)
 
# Show frame
frame.set_default_close_operation(JFrame::EXIT_ON_CLOSE)
frame.pack
frame.visible = true

You can also reference ruby code inside Java code, examples could be found here.

A faster(if not the fastest) Ruby implementation

JRuby team consider it a bug if they are slower on something than MRI, thus they keep enhancing the performance of JRuby.
According to Antonio Cangiano, the guy behind the great ruby shootout here and here:

Ruby 1.9 and JRuby are very close, respectively 2.5 and 1.9 faster than Ruby 1.8.7 (from source) on these benchmarks.

Surprisingly JRuby was slower than ruby 1.8.6 last year, but now it’s competeing 1.9 in terms of speed.
Charles Nutter the JRuby team leader commented on that saying:

I’m looking forward to seeing another update once JRuby finishes 1.9 support, since these JRuby numbers don’t reflect execution and library optimizations 1.9 provides. I expect that JRuby in 1.9 mode will perform much closer to Ruby 1.9.

Until then, it’s good to hear we’re the fastest 1.8 implementation. Thanks again!

Native Threads

The current ruby interpreter which is called MRI supports green threads, as opposed to JRuby which supports native threads.
Green threads are managed by VM, not by the operating system, and thus, by using them you lose a significant power called “concurrency” which is available to multi core processors, that’s because the VM will continue to use one core to serve the whole threads, as opposed to native threads which will use the full power of multi core processor, by being assigned to the available cores.
In general an application might be IO-bounded(lots of IO operations, like logging and database related ones) or CPU-bounded(lots of computation), and while green threads are useful for the IO-bounded applications, they are not useful for the CPU-bounded ones.
A CPU-bonded applications consumes the CPU, and thus you can increase the speed of your program by having multi core processor, but thus you need native threaded applications, to make use of the available cores.
JRuby comes to rescue as it supports native threads, and thus you have full concurrency when you have multi core processors.

Support for Foreign Function Interface(FFI)

According to wikipedia a Foreign Function Interface (or FFI) is :

A mechanism by which a program written in one programming language can call routines or make use of services written in another.

Why would a one need that? well many gems that we use like Rmagic,Hpricot and ruby-prof uses C extensions, either because of performance or because of the ready existing libs related matters.
Well that was causing problems for JRuby users as they couldn’t run those gems that have C extensions, and also for gem developers who had to maintain 2 versions of such gems to let them work for both MRI and JRuby.
That was a kind of disaster till Charles announced that FFI is available for ruby.
So now when you need to have C code inside ruby, then it’s highly recommended to use the FFI gem to save yourself having dual code, and also to make your code work on different ruby implementations.

Make use of the JVM (HotSpot)

Since Sun has announced it’s open source strategy, and lots of optimization work was done for the JVM(HotSpot), the reason behind these optimizations was the fact that many languages is adopting Java to be the hosting language for them, and thus having JVM as an open source technology helped to optimize it to better serve these languages. Some of these languages are: JRuby, Groovy, Scala and Clojure.
So you might be wondering “How this will affect me?”, actually it will affect you indirectly cause once you have a better JVM, it means you have a faster JRuby implementation, and a better management for your memory, as the JVM is considered to have the best garbage collector.
Also you might be able one day to work with other languages(Clojure for example) directly in your ruby code.

Have a great community and support

JRuby has a very nice community, and the guys behind it are very helpful and open to different opinions, just log to #JRuby channel on the FreeNode on IRC, or subscribe to mailing list and send your questions, and you will get the minimum support to let you go.
What i like about this community is their love to the Ruby community, they like to help any rubiest, they even worked with Merb(merb 2 is the core of Rails 3) guys to provide a better performance for merb users.
The current active JRuby contributers are: Charles Nutter, Tom Enebo, Wayne Meissner, Marcin Mielzynski and Nick Sieger, and here some of the past contributers: Ola Bini and Vladimir Sizikov

I hope that i could deliver some of the good points about JRuby, and would like really to have your comments, and what might be also missing from those points. You can find bellow a list of references.

References

*JRuby: What, Why, How…Try It Now by Charles Nutter and Tom Enebo

*JRuby: The Pain of Bringing an Off-Platform Dynamic Language to the JVM by Charles Nutter

*Charles Nutter blog

Update 1
The snippet of code was updated as a respond to Collin’s note