I really like the concept of the Uniform Interface. One of my favorite things to do is spend hours on my whiteboard (and sometimes days) fiddling with ideas that express what I consider to be elegance. This ranges from macroscopic elegance (ie: the architecture level) to microscopic elegance (ie: the function/method level). Somewhere in the middle lies my fascination with sets, my favorite topic in Discrete Mathematics.

I think one of the reasons I like the Uniform Interface so much is that it groups things together into a set (all things that respond to the same method or methods), which lets you conjure up powerful abstractions at any point in the macroscopic to microscopic elegance scale.

One reason I like REST is because of its HTTP implementation’s Uniform Interface, the most common request methods being CREATE, UPDATE, PUT, DELETE, and HEAD. Programs using MapReduce also use a Common Interface for both the map and reduce functions… and there are many, many more examples.

The difference between the Uniform Interface and Interface Polymorphism is subtle. The Uniform Interface is more general (ie: applying to REST, which is a service), whereas Interface Polymorphism specifically applies to programming. Thus, Interface Polymorphism is a specific kind of Uniform Interface.

The term “Duck Typing” is mentioned in Ruby circles sometimes, and it’s mostly just another name for Interface Polymorphism. This is probably because Ruby has no such thing as an interface. Java on the other hand does, which is how I learned about the concept first. In Java, if a class implements an interface then it absolutely has to define the interfaces methods in its class definition. In Ruby, duck typed methods simply have to be defined by the time an object is called (even if they weren’t there during the objects initial class declaration, or even during the objects initialization). Notice I used the word “object”, but don’t forget that in Ruby a class represented through a constant is an object too. So, the only difference is that Duck Typing is more often used when talking about dynamically adding Interface Polymorphic methods.

Let’s sum it all up with a Ruby class definition and some inheritance.

class DuckTyping < InterfacePolymorphism < UniformInterface
end


As some of you know, when I’m not working I’m taking classes in Information Systems at UCF. One of the classes I took this semester was Web Systems II, which is essentially a server-side course that focuses on ASP.NET development.

One particular assignment was creating a “Category Code Manager”, which I had never heard of previously. I think the professor made the term up, but the concept is simple nonetheless. There are categories (ie: fruits) that each can have many codes (ie: apples, oranges). I think the purpose of the assignment was to get used to working with foreign keys, and building dynamic drop downs as a tool to display this sort of relationship. Another gotcha is that the categories can have parent categories.

The class had a participation grade that I must have overlooked… Needless to say that didn’t bode well for me, so I created this screencast as an introduction to Ruby on Rails (beginner level) using the new Rails 2.0 (final source code included.) I tried to follow best practices where possible (ie: TDD), and covered the topics of:

• Database agnosticism & environments
• Using rake to create databases, and to run
• Scaffold generator
• has_many & belongs_to relationships within ActiveRecord
• The interactive Rails console
• The new integration of the ruby debugger, and a drop of live metaprogramming
• Test Driven Development with Test::Unit
• Intro to REST’ful architecture within Rails

But, I left some things out to avoid making the screencast even longer, and avoid it being confusing for beginners. Just so you all know, some changes I would have made include:

• Create some helper methods for things like populating the select tags
• Use nested routing (I did this first, but renaming all the named routes, having to explain the routing, etc made this too complex for a beginner video)
• Use RSpec for testing (RSpec’s scaffold uses mocks and stubs, which are just a little too much to explain when already introducing all of Rails and testing)
• Use a REST’ful abstraction plugin (we developed an internal one at work, but unfortunately we haven’t been able to open source it yet… until then check out make_resourceful)
• Use the ObjectMother pattern for creating objects during tests

Enjoy the screencast!

I’ve been doing a lot with REST and ROA on and off the job lately (mainly with Eric and Dray, who still does not have a blog.)

The way Rails implements resources is through Controller classes. One thing that came up yesterday, was the argument that the implementation is improper due to the inclusion of both an index and a show action in one Controller. In REST, a resource can be its own entity (ie: an apple), or a collection of of entities (ie: a fruits resource composed of apples, grapes, oranges, etc.) At first glance, the challenge to Rails Controllers seems to stand because a GET to the index action returns a collection of resources, whereas a GET to the show action just returns one resource.

Upon closer inspection though, you’ll see that the confusion comes from focusing on Controller actions. What should really be looked at is the resource (the controller), and how those two requests are addressed (the URI.) Firstly, notice what kind of resource we have… it’s a fruits resource. Next, look at the URI, it is /fruits.

Now that we’ve established that our FruitsController represents a plural resource (a collection of fruit resources), we can move on to explaining the confusion that the index and show actions introduce. A request to /fruits will return all of our fruits. But, the world has many fruits and we don’t want to request them all. Instead, we will fire a GET at /fruits?page=2?limit=10. Although most of you will recognize this as simple pagination, in ROA it is known as the concept of addressibiliy to indicate state in the URI.

Here’s where the confusion is cleared: a request to /fruits/1337 is not requesting a singular resource (in this case a cherry, the most elite of all fruits.) Instead, it is requesting a collection resource (fruits) but using addressibility to indicate state. It is okay to use the URI in REST different ways for addressiblity, because REST is a style and does not have a specification for addressing via URI’s. For example, another way of getting to /fruits/1337 might be /fruits/?page=1337?limit=1.

As a closing note, even though we used the fruits resource collection here and addressed cherry, we could have done it differently still. If you really wanted a singular cherry resource, you can do so in routes.rb by replacing map.resources :fruits with map.resource :cherry (notice that “resource” is singular.) This would map to a singular CherryController to implement the resource. You could access it with a get request to /cherry, which would map to the show action (in this case the index, or list, action does not make sense because cherry is singular.)