Hashes

Model attributes are now stored using Redis hashes. If you have been following Redis closely, this also means that you get huge memory savings for free. The main Redis key space will also be a lot less cluttered.

From an API perspective, you probably won’t notice a significant change. If you plan to upgrade to Ohm 0.1.0, you simply have to execute the code:

Nest

In Ohm 0.0.x, most raw Redis operations were done using the following approach:

Ohm 0.1.0 introduces a dependency called Nest. Aside from making the API a little more object oriented, it also allows you to create key hierarchies in a very terse manner. Let’s see the example above written in the new style:

Array Syntax in Lists

Getting a subset of an existing List was possible only through raw Redis commands. If you had something like:

Ohm 0.1.0 introduces a syntax similar to Ruby’s standard Array#[] method. The example above would be:

Improved Documentation and Tutorials

We believe in good documentation, so much that we have spent a lot of time improving the API Documentation.

In addition, since a lot of people learn best through examples, we’ve written up a couple of tutorials to help you get up to speed and get some insight on the different design philosophy that comes with using Ohm and Redis.

If you have any questions, problems or suggestions just head up to #ohm at irc.freenode.net or checkout our Google group.

What’s a Widget?

The widget infrastructure was introduced by the jQuery-ui library.  You can think of it as a class that’s tied to a dom object.  $("#foo").my_widget(); would instantiate a new copy of the my_widget widget on the #foo DOM element. A key thing to note is that if you have a list of jQuery objects $("p").my_widget(), you’d get a separate instance of the widget for each item in that list.  A widget is only attached to a single DOM element.

Why Widgets?

There are a few key reasons to use jQuery’s widgets for your interaction code.

• The biggest is that it provides the level of code organization that is very hard to maintain outside of a widget structure.  It changes the code from being imperative (”do this, then that, then another thing, bind to click”) to declarative (”act like an expando thing”).  This frees you up to define what “expando thing” means, while not cluttering or changing the outer layer of your app.  No more multi-hundred line long $(document).ready() blocks.
• Instance variables inside the widget allows you to avoid having global lookup hashes, and similar code smells.
• Easy developer cooperation.  You’re working with another guy, he’s in toggle.js, you’re in window.js, and you know that you’re not going to accidentally step on each other.

What we use Widgets for at Citrusbyte

The Small Time Stuff

• Our home-grown tab library (show/hide various divs, custom events & callbacks)
• Togglable on/off switches
• jQuery UI Built-in widgets for draggable, droppable, resizable, and the rest.  Often as building blocks for
• Shared widgets between clients.  It’s pretty often that we need to write a generic widget that gets added to our library of easy-to-modify code.  Copy into new project, tweak, and deploy.  Saves us time, and our clients money.

The Big Time Stuff

• 100% JS interfaces where elements have significant state, change views, with custom events.  Look for our future case study regarding this particular client.

What’s a basic widget look like?

Key things to note:

• Widgets strings all start with `ui.` in their names.  Don’t be fooled into thinking this is a namespace. It’s not. You’re required to use `ui.` there. I’m not sure of the design decision behind this, but you need to watch out for it.
• Methods with an underscore are private, _init() is a magic one that jQuery calls when you initialize things
• Methods without an underscore are public.

Calling Methods After you’ve init’d the widget

Multiple Widgets on a Single DOM Element

Accessing the element from the Widget

The my_widget variable contains a reference to the current scope.  So you can call methods, and so on.  I like making it an explicit variable, rather than the implicit `this` because then it doesn’t get clobbered by event handler callbacks.

The $my_widget variable is the DOM element that this widget instance is attached to.  Just like any other jQuery DOM element, you can search for parents(), children(), appendTo(), toggle(), attach events like click(), hover(), and whatever else you need to do.

Composing Widgets

A fun trick is to have your widget initializer define further widgets it’s own element. Any given DOM element can have many attached widgets.  So you can define your own widget, and use composition to build out it’s features.

For instance:

As far as the jQuery outside world is concerned, you have a widget that attaches all that functionality in a single call to $("#foo").my_widget(). The element just automatically becomes draggable, resizable, or any other custom widget behavior you implement.

The Options Hash

You can pass an arbitrary hash of values into a widget.  These can include callbacks, strings, numbers, objects, or whatever else you have.

Default Options

You can set default options for your widget by simply having an options variable set.  Any options passed in by the user will overwrite your defaults.

Inheritance

Inheritance in jQuery widgets isn’t quite as smart as real class-based languages or Javascript frameworks.  What is happening is that it is starting with the parent widget (ui.world), and merging in the child widget’s hash of definitions (from ui.hello). Because there’s no true inheritance, there is no easily accessible way to call super.  You can still do it by doing some gymnastics with $.ui.world.prototype if you need to call the super’s copy. You can easily form a chain of widgets, each inheriting from another.

We’ve used this when we’ve needed to build out a set of different kinds of widgets that all needed similar base functionality (like drag&drop, or right-click-menu, or similar).

This kind of base functionality is provided by the jQuery UI library in the mouse class

Official Docs

http://jqueryui.com/docs/Developer_Guide

For some background, Resque is a Redis-backed Ruby library for creating background jobs, placing those jobs on multiple queues, and processing them later. It uses redis-namespace, a 187 sloc gem that adds a Redis::Namespace class which can be used to namespace Redis keys.

Yesterday, a discussion took place in #redis regarding redis-namespace compatibility with redis-rb 2.0.0. There even was a suggestion to incorporate redis-namespace into redis-rb, so all libraries could profit from that solution. Even if I opposed that move (I consider redis-namespace the wrong solution to a simple problem), the underlying issue was not with redis-namespace, but with Resque itself. None of the participants in that discussion were direct redis-namespace users: they only wanted Resque to work with redis-rb 2.0.0.

Not being a Resque user myself, I had not bothered looking at its code before. Turns out I was able to make Resque 100% compatible with redis-rb 2.0.0 by replacing redis-namespace with… nothing. It wasn’t needed at all, and the namespacing functionality is now handled by an attr_accessor called namespace.

This code lives at my without-redis-namespace branch. I sent a pull request yesterday, I hope it will be incorporated soon to the main repository.

Explicit > Implicit

The previous version of the client relied on method_missing to execute commands against Redis. While this was great for quickly putting together a simple client, it proved insufficient for more advanced commands like pub/sub, blocking pop, etc. Plus, relying on this technique lead to longer and more branched methods as new features were added to Redis.

The new version explicitly defines each command as a method in the Redis class. We strongly believe that explicit beats implicit. This way it’s much easier to follow what is going on for each command. We did leave method_missing in there because it’s a nice way of being able to run simple commands that are not yet known to the client, but we’ll keep adding new commands as needed.

A nice consequence of this change is that the complexity of the code was reduced drastically. Many branches were removed in favor of separate, smaller methods (this is something that could only be done with an explicit method for each command).

New protocol

This version uses the new protocol only. It means people running a Redis version older than 1.2 will be stuck with the 1.0 branch. This multi-bulk protocol is binary safe and will be the only one available once Redis 2.0 is released, for which a release candidate is expected soon.

Faster!

One of our concerns when refactoring was the impact on performance this decoupling would bring. We agreed that a good goal would be to have the new version performing at least as fast as the old one. To our surprise –and probably because of the removal of branches, hash look-ups and by avoiding method_missing– the new version performed even better.

Before:

$ ruby -Ilib benchmarking/speed.rb
7.88 Kops

After:

$ ruby -Ilib benchmarking/speed.rb
8.79 Kops

The higher the number, the better. It means that the new version executes almost a thousand operations more per second.

Redis::Distributed

The old client shipped with DistRedis, which included a hashring algorithm and supported a small subset of operations. As it wasn’t tested or documented, we started by defining all the test cases and proceeded to implement them. Some operations are impossible in a distributed scenario, but we would cover a lot of interesting cases and it is now a very reliable tool. Check the testing suite to see the range of commands that are now possible.

Support/Bugs/Help

Jump to IRC if you need instant help. We are most of the time available at #redis-rb on Freenode. If nobody can help you there, try #redis. You can also create an issue on GitHub, or fork the project and send a patch directly.

By using hashes, Ohm is able to squeeze all the object attributes in a single key instead of using one key per attribute, a common pattern in key/value datastores (for some history, check the article that inspired Ohm almost one year ago: case study for a Twitter clone).

This release candidate uses Redis-rb 2.0.0.rc3, the new client that is faster, binary safe and no longer relies on method_missing for building the commands.

Upgrading your database

You will need to migrate your database if you want to use Ohm 0.1.0. It comes with a helper just for that, follow the example code to upgrade.

You will also need Redis 1.3.10 or newer, grab it from http://github.com/antirez/redis.

Within a day of the request, Citrusbyte had the new frame up and running on the Official Sony Electronics Facebook page.  Take a look for yourself:

It also includes tasks for starting and stopping Redis, and overall should provide more hints about what to configure and where.

To try it, just run monk init myapp, then cd myapp and monk to check the available options.

If you never installed Monk, run sudo gem install monk. If you already have it, there’s no need to update the gem.

So, how would you declare a reference to a DataMapper model or a set of ActiveRecord instances within Ohm?

class User < ActiveRecord::Base
  def posts
    Post.find(user: self)
  end
end

class Comment
  include DataMapper::Resource

  property :id,          Serial
  property :body,        String
end

class Post < Ohm::Model
  attribute :body
  reference :user, lambda { |id| User.find(id) }
  list      :comments, lambda { |id| Comment.get(id) }
end

Each time Ohm needs to refer to User, it will call the lambda the way it calls other Ohm models.

>> user = User.create :name => "foo"
>> post = Post.create :user => user, :body => "bar"

>> post.user.name
=> "foo"

>> comment = Comment.new
>> comment.attributes = { :body => "baz" }
>> comment.save
=> true

>> post.comments << comment
>> post.comments.first.body
>> "baz"

And what about Sequel? Because Sequel behaves exactly like Ohm, there’s no need for a lambda. You can mix them directly.

In a recent Forbes article Brian Reynolds, chief designer of Zynga, said his company was “platform agnostic,” stating Zynga “just [wants] to be on whatever platforms enable good experiences. We’re also on MySpace, and we’ve done iPhone stuff. It’s all about which platform allows it to be most social.”

Today, Citrusbyte announces tools to help your Facebook game be just a bit more platform agnostic with only a few minor code tweaks.

Commissioned by MySpace, Citrusbyte developed a reference toolkit for porting any Facebook app to the MySpace platform. The document goes through Facebook’s Authentication and RESTful APIs, noting their MySpace equivilent or providing code snippets whenever necessary. The document concludes with a step-by-step example of how to port one Facebook app to the MySpace platform, including before and after code.

Following this guide, Facebook game developers can quickly and easily bring their apps to the MySpace platform, accessing over 100 million additional active users.