rubyplanet

I am freezing this blog - Ruby material will in the future be posted to my main blog

2010-08-29T21:14:00.000-07:00

I am getting excited about the Rails 3 release

2010-08-24T21:06:00.000-07:00

I spent some time with Rails 3 pre last December but I have not done much since - I have been very busy this year. I installed the second release candidate tonight and have been kicking the tires again by starting a new application from scratch, getting used to the new command line interface, and reading a few online articles about new features and migration issues.

I used to use Merb a lot, and ever since the announcement of the Merb and Rails merge, I have been looking forward to the 3.0 release. I invested a lot of time learning Rails version 1.x, then 2.x, and I am enthusiastic about putting in the time for digging into 3.x.

Great news: Ruby 1.9.2 released

2010-08-18T09:12:00.001-07:00

I am doing an install from svn head right now:

rvm install 1.9.2-head

and it is picking up the latest release OK:

http://svn.ruby-lang.org/repos/ruby/branches/ruby_1_9_2

As an aside: I wonder how much Oracle's law suit against Google for a non-standard Java in Android will affect Java, Clojure, Scala, etc.? Probably not much at all, but this might be another small reason to favor Ruby :-)

Another way to do text search on MongoDB

2010-07-12T12:07:00.000-07:00

I wrote an article on my main technology blog last November on doing indexing and search using MongoDB with the MongoRecord ORM style gem.

Since then, I have preferred to use MongoDB closer to the metal using the mongo gem (and using lower level interfaces when I develop in Clojure). Here is a simple example:

require 'rubygems' # only for Ruby 1.8.*
require 'mongo'

include Mongo

host = "localhost"
db = Connection.new(host,27017).db('my-db-name')
things = db.collection('things')

things.remove
things.insert('guid' => 102, :name => 'John Smith', :email => 'jsmith@example.com')
puts things.count
things.find(:name => /^john/i).each {|x| p x} # good performance
things.find(:name => /smith/i).each {|x| p x} # no so good performance

Because of the way indices are created, you should only do prefix wild card searches if you need good performance.

Datamapper 1.0 released

2010-06-09T06:52:00.000-07:00

Here is the announcement.

I must say that I still use ActiveRecord slightly more often that Datamapper but that is largely due to working on legacy Rails apps. I have been using MongoDB more often because my largest customer uses it and the dm-mongo-adapter lets you mix data model backends of MongoDB and relational databases.

I have finally got with the program and installed rvm

2010-05-23T14:35:00.000-07:00

I always have installed each version of Ruby in my local ~/bin directory and setup bash aliases to tweak my PATH to quickly switch when needed. I like having the source code to all of the gems I use ready at hand, so my installation scheme has always worked well for me. Being able to ZIP up all of my Ruby installations and move them to another system was another big win, as is not having to sudo gem install...

I spent the time today to install rvm on my fast i5 Ubuntu laptop, with Ruby 1.8.7, 1.9.1, Rubinius 1.0, and Jruby 1.5.0. Very satisfactory. I still have everything in my home directory where I want it, and my setup is easy to backup and copy.

I do almost all of my real work with 1.9.1 but I have been enjoying using Rubinius for casual coding.

If Rubinius if good enough for Ezra, it is good enough for me

2010-05-15T11:24:00.000-07:00

On the Hacker News discusion of the new 1.0 release of Rubinius, Ezra Zygmuntowicz mentioned that he uses Rubinius for his day to day Ruby development. That really got my attention because Ezra's articles on Ruby, configuring nginx, etc. have been a great help to me over the years.

I just installed rbx, gem for rbx, and I am now installing the gems I need for the things that I usually work on.

I am super busy right now (doing artificial intelligence/text mining for a stealth startup, so I have almost no free time) so I'll have to stick with JRuby 1.5 and Ruby 1.9.1 for my Ruby work right now, but I think that Rubinius is the future.

BTW, a few years ago at a Merb Camp, Ezra asked me if I was into Clojure because of my long-time use of Lisp (I have been using Lisp for work since the early 1980s). At the time I had to say no, but recently most of my work has been using Clojure which is one reason the I started my new ClojurePla.net web blog. Ruby is still my favorite language but I am sensitive to what customers want to pay me to code in :-)

I open sourced my-foc.us Rails web app

2010-05-04T12:48:00.000-07:00

You can try it right now on my server or get the source code at github.

my-foc.us is an "anti TODO list" since its goal is help you drill down and focus on your most important tasks.

Nice: MongoHQ is now a beta Heroku add-on.

2010-04-30T14:29:00.000-07:00

I wrote an article (Heroku hosted Rails applications using remote MongoDB services) a few months ago about using an external MongoDB server with Heroku Rails apps.

Now MongoHQ is an ad-on service.

The pricing is reasonable enough to not bother running my own MongoDB instances if I am hosting on Heroku.

JRuby 1.5.0RC2 runs all of my code

2010-04-28T16:05:00.000-07:00

JRuby 1.5.0RC2 is available. I did a test install of gems I use with JRuby:

jgem install jruby-openssl rails heroku rest-client texticle \   
  postgres-pr mongo_record json_pure dm-core couchrest gemcutter \
  simplehttp sinatra geocoder neo4j --no-ri --no-rdoc

Nice. I tested all of my programs that I run with JRuby with no problems:

All JRuby example programs from my new "Practical Semantic Web Programming, Java edition"
Access to Sesame, AllegroGraph, MongoDB, CouchDB, and PostgreSQL data sources
Misc. utilities

I found nothing that did not run fine with JRuby 1.5.0 RC2 :-)

I removed Ruby 1.8.* from my development systems

2010-04-27T21:06:00.000-07:00

The only use I have recently had for Ruby 1.8.7 was for running the appengine gem (apps use JRuby, but the setup uses MRI). Because of the long loading request times for appengine apps written using JRuby, I have decided that the limited amount of appengine development that I do will be in Java (1 and 2).

While I use JRuby quite a bit when using existing Java libraries for NLP and the Semantic Web, most of my development is done in MRI and since Ruby 1.9.1 is so much faster than Ruby 1.8.* it seems best to make a clean break. I left Ruby 1.8.7 on one of my servers to support a few older projects for customers (just for low level of effort maintenance).

I truly believe that it is time for the "Ruby World" to move on to Ruby 1.9.*, JRuby, and other modern implementations like MacRuby.

Completely up and running with Ruby 1.9.1

2010-04-09T08:16:00.000-07:00

The last problem I had was getting my CookingSpace.com app on Heroku migrated to Ruby 1.9.1. (Thanks to Heroku tech support for help on a problem I was unable to figure out for myself :-)

I now have all of my Rails projects and those of my active customers running on Ruby 1.9.1.

4/27/2010 update: Forgot to mention: I had to patch the auto_complete plugin: search the plugin code for content_tag("ul", items.uniq) and change it to content_tag("ul", items.uniq.join).

Final results on Ruby 1.8.7, 1.9.1, and JRuby 1.4.0 benchmark using cookingspace.com

2010-04-03T11:26:00.000-07:00

I have done some more work to try to make the comparison as fair and accurate as possible. If I assign a performance value of 1.0 to Ruby 1.8.7 then the relative performance of Ruby 1.9.1 is 2.1 and the relative performance of JRuby 1.4.0 is 1.9.

The lesson is obvious: if you are running Ruby 1.8.* in production, then make a real effort to update your applications to either Ruby 1.9.1 or JRuby 1.4.0!

Memcached and ActiveRecord: a few easy performance improvements

2010-04-02T13:13:00.000-07:00

I have a web application where the data in some tables is never modified and other tables where the data is seldom modified. Here are a few simple things that I just did speed up my Rails app by about 35%:

Cache IDs of an active record class:

plan_list =
  Marshal.load(Rails.cache.fetch('plan_ids_list') {
    Marshal.dump(DailyPlan.find(
      :all, :conditions => . . . ).collect {|r| r.id})
 })

Here I am just using the caching mechanism built into Rails 2.1+. If I was using the in memory cache instead of Memcached then I would not have to marshal/unmarshal the cached Ruby data.

Supply a find method that will work with all ActiveRecord associations:

class Ingredient < ActiveRecord::Base
  has_many :weights, :foreign_key => :ndb_no

  # Using memcache to save ingredients since they are very static
  def self.find(*args)
    result = Rails.cache.read("ing_" + args.to_s.gsub(" ",""))
    if !result
      result = super(*args)
      Rails.cache.write("ing_" + args.to_s.gsub(" ",""),
                        Marshal.dump(result), :expires_in => 1.day)
    else
      result = Marshal.load(result)
    end
    result
  end
end

I could have used the Rails.cache.fetch trick from the last example to shorten the code, but this version shows more clearly what I am doing.

Part 2: Improved JRuby results for Ruby 1.9.1 vs. JRuby 1.4.0 benchmark using cookingspace.com

2010-04-02T07:09:00.000-07:00

I would like to thank Peter Cooper for pointing out that there was a problem with the benchmark I posted yesterday: the request time was likely most affected by database access time. I was using the postgres-pr gem with JRuby.

I just modified my Rails app to use the JDBC ActiveRecord gems and the results were better for JRuby: 13.8 requests per second compared to 15.8 requests per second using Ruby 1.9.1 with the native Postgresql gem. Results for JRuby:

Requests per second:    13.80 [#/sec] (mean)
Time per request:       362.446 [ms] (mean)
Time per request:       72.489 [ms] (mean, across all concurrent requests)
Transfer rate:          85.06 [Kbytes/sec] received

Here is how I set up my web app:

To start with, I installed:

jgem uninstall postgres-pr
jgem install activerecord-jdbc-adapter
jgem install jdbc-postgres

I then ran a generator to patch ActiveRecord:

jruby script/generate jdbc

I was able to leave my database.yml file as-is.

Ruby 1.9.1 about twice as fast as JRuby 1.4.0 for my cookingspace.com Rails app

2010-04-01T16:11:00.000-07:00

Update: I got better JRuby results in a second benchmark using the JDBC adapters with JRuby (13.8 requests per second with JRuby and 15.8 requests per second with Ruby 1.9.1).

My CookingSpace.com web app (something that I wrote for my own use) runs about twice as fast using Ruby 1.9.1. Also, instead of using mongrel (faster) I ran the Ruby 1.9.1 test using Webrick because I used Webrick for the JRuby test. The Apache Benchmark command line arguments used:

ab -n 20 -c 5 http://127.0.0.1:3000/site/show_random_plan

I let the JRuby test "warm up" Hotspot-wise for several minutes before taking these measurements:

JRuby 1.4.0 and Webrick

Total transferred:      125814 bytes
HTML transferred:       114781 bytes
Requests per second:    7.52 [#/sec] (mean)
Time per request:       664.628 [ms] (mean)
Time per request:       132.926 [ms] (mean, across all concurrent requests)
Transfer rate:          46.22 [Kbytes/sec] received

Ruby 1.9.1 and Webrick

Total transferred:      123214 bytes
HTML transferred:       111672 bytes
Requests per second:    15.82 [#/sec] (mean)
Time per request:       316.149 [ms] (mean)
Time per request:       63.230 [ms] (mean, across all concurrent requests)
Transfer rate:          95.15 [Kbytes/sec] received

Don't get me wrong: JRuby is an awesomely useful project, especially for me because I use my NLP libraries written in Java with JRuby - very convenient! And, the performance boost with Ruby 1.9.1 is fantastic for Rails web apps.

I am almost done converting completely from Ruby 1.8.x

2010-03-30T11:15:00.000-07:00

I don't have any deployed JRuby web applications right now, but except for cookingspace.com I have everything deployed using Ruby 1.9.1 (I am having some problems with Heroku's Ruby 1.9.1 beta stack, and I expect to be redeployed soon.)

The performance gain going from Ruby 1.8.x to 1.9.1 is substantial - well worth the effort!

My 3 articles on Heroku for DevX

2010-03-26T19:36:00.000-07:00

Pardon some self promotion, but you might find my 3 short articles interesting:

I must say that after spending a lot of time with CouchDB and a little time with Cassandra, I find that MongoDB is the best fit for what I need in a NoSQL style data store.

Switching to Ruby 1.9.x, part 2

2010-03-26T19:16:00.000-07:00

A year ago last January I went to a lot of effort to switch my development system to version 1.9. I decided to switch back to Ruby 1.8.x because all of my work for customers used 1.8. Recently several things convinced me to try a complete switch to 1.9 (again): Heroku started supporting a curated stack using 1.9, I am only doing Rails work for one customer right now and their web app is fully 1.9 compatible, and after I finish writing my current book project (soon!) I have scheduled lots of time for my own startup business and quite frankly want the performance boost of 1.9 for my own work.

Sinatra 1.0 released

2010-03-25T13:40:00.000-07:00

I have always enjoyed Sinatra for small (or medium size) web applications. Sometimes I want something simpler than Rails, really just needing routes, simple controller actions, and easy interface with Erb or Haml.

When I first started using Ruby and later Rails I liked the relative simplicity of the codebases. I used to keep the Ruby 1.8.x source code handy for perusal. Same for early versions of Rails. Now with the various dialects of Ruby and the much larger Rails codebase I have given up any attempt to read the code. Using Ruby and Rails as software black boxes is too bad, but for me it is now a necessity. At least with Sinatra the codebase is still small and easy to understand.

Also, while the Rails infrastructure of plugins and myriad options are great, for some projects it makes sense to just implement the bits that you need on top of Sinatra. Because Ruby is such a concise language it often takes very few lines of code to add in these application specific bits of functionality. You can end up with a much simpler system with advantages for both adding new features and easier for other people to use and modify the code.

Welcome to RubyPlanet.net

2010-03-24T17:33:00.000-07:00

I used to run a Ruby aggregator on the domain RubyPlanet.net but I decided to split the Ruby stuff off of my technology blog blog.markwatson.com into a separate blog.