Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
Tracking change and innovation in the enterprise software development community
Posted by Luciano Ramalho on Jan 21, 2007 03:33 PM
Ruby on Rails 1.2 is finally out, as a release numbered 1.2.1 that updates many key components of the framework. 'Mature' is perhaps the best adjective to describe the latest version. The most important change is arguably "REST, and general HTTP appreciation", to quote the official announcement. In other words, the framework now leverages more advanced features of HTTP. For instance, CRUD operations can now be directly mapped to the native HTTP verbs POST, GET, PUT and DELETE. REST-style mapping simplifies URLs by reducing the need for naming actions in the path, and paves the way to refactoring bloated controllers into simpler, more focused ones. Another major enhancement is better support for UTF-8 encoded strings.
David Heinemeier Hansson appears to have pored over Roy Fielding's PhD dissertation, which defines the acronym REST (Representational State Transfer) as the architectural style of the Web. Fielding is one of the founders of the Apache project, the lead author of the HTTP/1.1 standard, and his work put HTTP and the whole WWW on solid theoretical grounds.
Besides using additional HTTP verbs, Rails controllers can now render multiple formats from the same base URL invoked with different file extensions (i.e. /blog and /blog.rss both invoke the /blog controller, but one renders HTML and the other RSS). David's keynote at the 2006 RailsConf (video, slides) previews these changes, and shows how they support his opinionated (and agile) approach to SOAs without the baggage of SOAP. By digging into HTTP, the Rails team once again shows an easy to follow path towards building web apps the right way.
Ruby is set to finally support Unicode by the end of 2007. Meanwhile, the Rails team has created a Chars class to proxy the native String class and provide encoding-safe operations, such as a slice method that does not mangle multibyte characters. ActiveSupport::Multibyte adds a String::char accessor which returns a Char instance representing the String, so if you do title.chars[0,7] you get a Char instance containing the first seven Unicode characters of the title string (and not the first seven bytes).
It's reassuring the see the Rails team committed not to bells and whistles, but to perfecting the architecture and the infrastructure of the framework. Another sign of maturity: 57 distinct developers sign the changelog for 1.2, more than twice the number in the previous minor releases (27 in 1.1, 18 in 1.0). There are 108 items in the 1.2 changelog, versus 62 in 1.1, which was released in March, 2006. Ruby on Rails definitely seems poised for another year of explosive growth.
Ensuring Code Quality in Multi-threaded Applications
Usage Landscape: Enterprise Open Source Data Integration
Agile Development: A Manager's Roadmap for Success
The Agile Business Analyst: Skills and Techniques needed for Agile
Anyone else notice how they are sometimes putting ";edit" in the URL to map it to the edit action? I'm not a Rails expert, but that seems a bit non-RESTful to me. Anyone want to comment what the difference between the edit and the update actions are for a non Rails guy? Dan Diephouse, Envoi Solutions
Adding ;edit to an individual resource URL tells Rails that you want the edit form in order to do an update (via a PUT)
Dan, the ";edit" on the URL is purely as a work around for browsers and firewalls which don't support PUT/DELETE - so its a way of differentiating operations when only GET and POST are supported. i.e. its a way to support loREST as well as hiREST. Basically you can use Rails in a perfectly RESTful way - the REST support in Rails is awesome (as is the rest of it :). James LogicBlaze
> the ";edit" on the URL is purely as a work around for > browsers and firewalls which don't support PUT/DELETE Wrong. There's a separate hidden field in the POSTed form for that. ";edit" is essentially a hint used with a GET URL. It says to the server "Give me the specified resource in an appropriate format for editing". So "GET /users/1" might return the user details formatted as a report while "GET /users/1;edit" returns the user details in a form. If and when the form is the browser sends the form params to "PUT /users/1". Except, because of the problem Dan mentioned, PUT can't be relied to work, so instead POST is used and a hidden form field is used to signal to the webapp framework that it should treat it as a PUT. David
There's nothing unRESTful about that ;edit URI. Doing a GET on it is "safe", the only difference is the one pointed out by David. I asked the combined REST commuity about the Rails REST concepts in the Yahoo! mailing list; IIRC, there was no significant criticism. The only exception is the hidden form field workaround, which is used not only by Rails, but also by Google's GData (for example) -- some consider this wrong and believe applications should not try to work around the PUT/DELETE limitations in many firewalls. The reasoning is that firewall admins a) need to learn the errors of their ways b) have good reasons for blocking PUT and DELETE. I don't subscribe to this point of view.
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.
This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.
This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.
This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.
After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.
IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.
Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.
5 comments
Watch Thread Reply