There are already plugins out there to allow you to write your elasticsearch custom scripts in python, javascript and groovy (in addition to the default mvel), so why not ruby?

When you’re indexing data, the world is rarely as simple as each document existing in isolation. Sometimes, you’re better off denormalizing all data into the child documents. For example if you were modelling books, adding an author field to books could be a sensible choice (even if in the database that is your authoritative datasource the data is split into separate authors and books table). It’s simple and you can easily construct queries on both attributes of the book and the author’s name.

One of the cool things about elasticsearch is the ability to provide scripts that calculate custom ordering or that filter based on application specific logic. Out of the box elasticsearch supports mvel and there are also plugins that support python and javascript. I imagine that it would be pretty simple to provide a jruby one too.

You can also use so called native scripts, written in java. These are faster than the other alternatives and may also be handier if you need to integrate with some existing java code to calculate your scores. There is some info out there on how to build these but they presuppose a certain familiarity with java and its environment. If you’re anything like me then you can bumble through java syntax readily enough but classpaths, jars etc. are a bit of a mystery. So here’s how I got a native script running with instructions that (hopefully) presuppose almost no knowledge of java. I’m no java wizard - I may well be doing something dumb - but this is working well enough for us in production.

There are already some ruby bindings but I’ve written my own.

I mostly did this for fun, but I think swig sometimes gives you slightly unnatural feeling interfaces, because you’re focussing too much on mapping C++ classes to your ruby classes. For example some liblinear methods take a struct param argument. liblinear-ruby-swig mirrors this by proving an LParameter class that maps onto this:

1
2

  param = LParameter.new(:C => 1, :eps => 0.01)
  model = LModel.new(problem, param)

but I’d rather write:

1

  model = RubyLinear::Model.new problem, :c => 1, :eps => 0.01

I imagine that SWIG must incur some sort of overhead but I would have thought that was pretty negligible for something like liblinear where most of the heavy lifting happens in the library being wrapped.

If you’re writing an iOS app that uses Core Data then you may well want to ship it with an initial database (which potentially gets over the air updates later on).

On iOS, CoreData stores always use sqlite3 as their backend. You could create a sqlite database directly, but you’d have to reverse engineer the way apple uses sqlite, ensure that you use the same name manging for table and column names, generate the same meta data used for persistent store migration etc. Too brittle for my liking.