Presentation on Aquarium with Exercises

2007-10-02T14:06:00-05:00

I’ve posted a PDF for the presentation I did last night on Aquarium at the Chicago Ruby Users Group (Chirb).

I also posted a zip file with three exercises that are adapted from the examples on the aquarium web site.

Speaking at the Chicago Ruby Users Group (Chirb)

2007-09-29T08:30:28-05:00

I will give a presentation on Aquarium at Chirb this Monday evening, Oct. 1st. David Chelimsky will also be speaking on new developements in RBehave and RSpec. Details are here.

David and I will be doing a joint presentation at the December meeting. It will be a tutorial on Ruby metaprogramming.

ANN: Aquarium v0.1.5 released

2007-09-17T21:15:00-05:00

This is primarily a bug-fix release. I labeled it “v0.1.5” instead of “v0.1.1”, because a non-trivial API change was required; Aquarium no longer automatically adds methods to Object, due to collisions with Rails. This means that users of the “DSL methods” will need to require a new file or include a new module.

See the “CHANGES” file in the distribution of here for more information.

Announcement: Aquarium v0.1.0 - An Aspect-Oriented Programming Toolkit for Ruby

2007-08-23T17:18:00-05:00

I am pleased to announce the first release of Aquarium, an Aspect-Oriented Programming toolkit for Ruby.

I created Aquarium to address a few goals that aren’t adequately addressed by other AOP toolkits for Ruby. Most of these goals reflect the issues you encounter when using sophisticated aspects in large systems.

First, the most important feature of any AOP toolkit is the “pointcut” language it provides, which is how you succinctly specify the “join points” across a system where behavior changes are required to support the “cross-cutting concern” that the aspect implements.

Most people assume that Ruby doesn’t need an AOP framework because its built-in metaprogramming facilities make method interception and wrapping easy. This is the “advising” part of an AOP toolkit. However, the real value of AOP is the modularity capabilities provided by the pointcut language. One goal for Aquarium is to match and even exceed the power of the AspectJ pointcut language. I also hope to make it as user-friendly as possible.

Next, Aquarium seeks to handle the issues that arise when multiple advices are applied to a single join point, including precedence control.

Another goal is the ability to add and remove advice dynamically. For example, you might want to insert troubleshooting advice in a running system, then remove it later when the issue is resolved. The first release already implements this feature, with some limitations.

Finally (for now), I want to use Aquarium as a vehicle for experimenting with DSL implementation ideas. For several years, there has been discussion (started by Ivar Jacobson) of the idea that aspects share an affinity with Use Cases (or User Stories), because both concepts cross-cut the application domain object boundaries, in one sense or another. So, if I define a DSL that directly represents a user story, can I map it quickly and efficiently to the implementation objects using aspects? We’ll see.

There is extensive documentation at the Aquarium site. Please give it a try and let me know what you think!

RailsConf 2006

2006-07-02T23:13:00-05:00

I attended the first annual Ruby on Rails RailsConf in Chicago last weekend and I’ve finally found the time to blog about it ;)

About 500-550 people attended, from novices to Rails experts, including 8 out of 11 of the Rails “core” team. The atmosphere was collegial and somewhat cozy. Everyone realized that future Rails conferences will be a lot bigger and probably more commercial too, given the growing interest in Rails.

Dave Thomas’ Keynote

Dave’s was the first keynote of the conference. He described the top-3 unsolved problems on his list of TODO’S for Rails. The list contains somewhat conventional items that you might expect, but what was interesting about the keynote was how the list anticipated some spirited philosophical discussions throughout the weekend.

Data Integration Improvements

Dave would like ActiveRecord to extract more information from the schema into the models, such as constraints and associations. He would like better foreign key and compound key support. He would like non-database back-ends supported, like JMS/MQ systems and he would like support for distributed transactions with two-phased commits, etc.

These are all reasonable requests from someone familiar with the typical challenges of “enterprise” (more on that word below…) applications, especially legacy systems. However, this surfaced an on-going debate between the two Daves; Dave Thomas and David Heinemeier Hansson (DHH). DHH has made clear his preference for keeping all domain logic in the application and using the database as a relatively simple-minded storage vehicle.

As subsequent presentations and discussions indicated, the Rails “core” will get smaller in the future and plugins will provide added support for things not considered “core”. No doubt people will implement plugins for all the things Dave (Thomas) wants, but they won’t be part of the Rails core. But this is okay, as it will satisfy various needs, yet keep Rails lean, mean, and architecturally clean (you can quote me…;) ).

CRUD and Scaffolding

Create, Read, Update, Delete (CRUD) operations are the core of typical database-based applications. Dave argued that the Rails scaffolding, which is used to generate stubs for functionality, etc. could be improved to better reflect the growing capabilities of Rails. He would like scaffolding that supports table relationships, in-browser validation JavaScript, AJAX, etc., etc.

Who could argue with that? Well, some people feel that scaffolding is too much of a crutch that discourages neophytes from understanding Rails and adapting it to their needs. Others feel that the scaffolding command-line tools are too primitive and should be more sophisticated. For a promising example of the latter, see the forth-coming Streamlined.

Perhaps most interesting was DHH’s own keynote, where he discussed his thoughts on more fully realizing the “vision” of CRUD in rails, but more on that later.

Deployment

Dave’s third item was deployment of applications. While Capistrano is a widely-praised tool for automating deployments, it does have some limitations. For example, out of the box, it really assumes that the developer does the deploying. This may be true for many small shops, but larger enterprises typically have system administrators who handle deployments. The Developers know what to deploy and administrators know the where, when, how, etc. for the deployments. So, Dave advocated enhancements that logically-separate application and deployment configurations. He sighted one example where J2EE got it right (at least in theory); packaging applications as “archives”, WARs, EARs, etc., which can be deployed to any standard server.

Deployment was a popular topic at the conference, with several sessions devoted to Capistrano, server topology considerations, etc.

David Heinemeier Hansson’s Keynote

Jumping ahead to DHH’s keynote on Saturday, he replied to some of Dave Thomas’ comments by reaffirming his opinions on topics such as the roll of the database and how far ActiveRecord should go in supporting various database features. For example, he was emphatic that composite keys are a known evil in the database world and ActiveRecord should not support them, at least not as a core feature. Perhaps someone will write a separate plugin, but DHH believes that if you do bad stuff, it should be painful, not easy.

For most of hist talk, however, DHH focused on more fully realizing the “vision” of CRUD in Rails. Create, Read, Update, and Delete are the standard operations in database-backed applications. In forthcoming versions of Rails, DHH wants to make this model more consistently applied throughout Rails.

For example, HTTP actually defines four methods, GET and POST, which we all know an love, but also PUT and DELETE. Roughly, these correspond the Read, Create, Update, and Delete operations in CRUD.

Our current way of organizing models, controls, and the behavior they offer is reflected in URLs of the form

.../model/action/id

For example:

HTTP Method	Example URL	Meaning
POST	`.../person/create/1`	Edit Person with ID 1
GET	`.../person/read/2`	Read Person with ID 2
POST	`.../person/update/3`	Update Person with ID 3
POST	`.../person/delete/4`	Delete Person with ID 4

Instead, we should be writing more “CRUD’y” URLs of the form

.../model/id

and using the HTTP method to indicate the CRUD operation. This would allow Rails to apply more conventions for these typical controller operations, thereby minimizing code. For example:

HTTP Method	Example URL	Meaning
POST	`.../person/1`	Edit Person with ID 1
GET	`.../person/2`	Read Person with ID 2
PUT	`.../person/3`	Update Person with ID 3
DELETE	`.../person/4`	Delete Person with ID 4

Unfortunately, browsers don’t usually support PUT and DELETE, so Rails is adopting a convention that hacks around this limitation. For example, the URL for the update case will look something like

.../model/id;update

where the idea for using the semicolon ”;” is based on some documentation written by Tim Berners-Lee himself (for “Semantic Web” concepts, I think).

But there are more ways to “embrace the CRUD.” Consider a typical example with a Person model and a Group model, where one or more Persons can be a member of one or more Groups. Typically this is handled thusly:

    class Person << ActiveRecord::Base
      belongs_to :group
      ...
      def remove_from_group ...
      def add_to_group ...
      ...
    end

    class Group << ActiveRecord::Base
      has_many :people
      ...
      def remove_person ...
      def add_person ...
    end

Where should those add and remove methods really go? DHH pointed out that if we reify (not his term) the relationship between Person and Group, that is, treat it as an model object in its own right, then we can use CRUD conventions to manage the relationship itself. In this example, a class Membership could encapsulate membership of people in groups. The CRUD creation operation would add a Person to a Group, deletion of memberships would remove the relationship, etc.

Perhaps the most interesting thing about his keynote was how it demonstrated his thorough commitment to pushing design principles to their logically limit in Rails. Where most of us would have been satisfied with the current design, DHH sees that it can be made even more consistent to the CRUD vision, and thereby further increase the use of common (and automated) conventions. No wonder Rails is so good!

Rails Application Optimization Techniques and Tools

Stefan Kaes

Stefan has done an extensive analysis of Rails performance issues. His detailed talk listed some of his findings. He is working on a book that is due next year, published by Wiley, that promises to be valuable for developers concerned about optimizing performance.

In a nutshell, he listed the following as the top performance problems:

slow helper methods,
complicated routes,
associations, especially when loading one object retrieves all associated objects automatically,
retrieving too much data from the database (related to the previous point), and
slow storage of session information.

For more details about his findings and recommendation, see Stefan’s blog and his recent InfoQ article.

MetaRails

There were many more interesting talks, but since I’ve taken over a week to get this blog done, I’ll finish with a comment on the excellent MetaRails talk by Stuart Halloway, with an assist from his Relevance partner, Justin Gehtland.

Stuart discussed some interesting uses of metaprogramming within the Rails core that make Rails the amazing environment that it is. Rails is a treasure trove of patterns and idioms that are well worth learning. As neither Stuart nor Justin are members of the core team, they provided an outsider’s perspective.

Stuart mostly praised the quality of the Rails code, but he pointed out one area where he felt it isn’t DRY enough, the way many ActiveRecord methods are aliased and then replaced with methods that add support for transactions, etc. There are apparently several different areas where the same methods are aliased this way, where each alias provides a different “enhancement.” As these alias statements are not co-located, it would be easy for one such modification to stomp on another. Also, how do you ensure that one alias takes “precedence” (i.e., gets applied first) over another? For example, you might always want authentication and authorization to happen first. (Note that Stuart’s follow-up blog mentions that the DRY problem has been partially solved since he started his analysis.)

In fact, he described a classic case that motivates Aspect-Oriented Programming. Even in dynamic languages like Ruby, where metaprogramming facilities are easy to use, AOP provides a conceptual framework for thinking about certain design issues, like adding transactional behavior to persistent objects or invocation of authentication and authorization challenges before executing otherwise normal-looking methods. Yes, Ruby metaprogramming facilities allow you to implement AOP-like behavior, but you have to “switch paradigms” to do so. I don’t know how Ruby implements Object-Oriented behavior, but you could image that similar metaprogramming approaches are used or could be used if no OO support were provided. So, yes, you could do OOP, in this case, but isn’t it nicer to think in objects when you are writing OO code, rather than have to switch gears mentally and think in meta-object protocols? The same argument can be made about providing AOP facilities in a language, even if those facilities are relatively small additions. For example, AspectR, an AspectJ-like Ruby clone, is only about 200 lines of Ruby code.

I’m going to blog about the role of AOP in dynamic languages like Ruby in the next few days, so please check back. Also, I’ll be doing a talk on AOP in Ruby and Python at the Dr. Dobbs Architecture and Design World in Chicago, July 17-20. I hope to see you there!

RailsConf 2007

Finally, it was announced that next year’s conference will be May 17-20 in Portland, Oregon.

Dean Wampler's Mind: Category Ruby and Ruby on Rails