November 6th, 2009
I’m teaching an all-day, introductory tutorial on Scala at QCon San Francisco, November 16th. You can find out more about it at the QConSF web site.
QCon San Francisco is a new conference (this is its second year), but it is already my favorite conference in the US for general coverage of software industry topics. It’s jointly organized by InfoQ and Trifork, the people who produce the highly-regarded JAOO conference in Denmark.
I hope to see you at any or all of those conferences!
November 20th, 2008
I posted an extended version of the slides from my QCon San Francisco talk, Radical Simplification Through Polyglot and Poly-Paradigm Programming (PDF). The PDF includes some slides I skipped in the actual talk, for time’s sake.
InfoQ.com may offer a video of this talk. Stay tuned.
October 2nd, 2007
September 29th, 2007
September 17th, 2007
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":http://aquarium.rubyforge.org/changes.html for more information.
July 2nd, 2006
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...;) ).
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.
DeploymentDave'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
|HTTP Method||Example URL||Meaning|
|POST||Edit Person with ID 1|
|GET||Read Person with ID 2|
|POST||Update Person with ID 3|
|POST||Delete Person with ID 4|
Instead, we should be writing more "CRUD'y" URLs of the form
.../model/idand 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||Edit Person with ID 1|
|GET||Read Person with ID 2|
|PUT||Update Person with ID 3|
|DELETE||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;updatewhere 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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
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
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 ToolsStefan 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.
MetaRailsThere 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!