Sessions at RubyConf India 2011 on Saturday 28th May

We all know that Rails is great for building traditional web applications that serve dynamic HTML pages. But more and more, people are reaching to other tools, like Node.js, when they build web applications with a lot of logic in the client. People often use the argument that when you remove the view helpers, there isn’t much of value left in Rails.

In fact, because the Rails framework made an early bet on the REST architecture, it is extremely productive for building applications that mostly communicate over HTTP using JSON payloads. In this talk, Yehuda will talk about what makes Rails so good as the server for rich clients, and how to structure your application to take the most advantage of these properties.

By personal experience, while transitioning from the world of Java to the world of Ruby, I felt great pain and agony, whenever I read statements like "Everything in Ruby is an object; classes themselves are objects". It took me more than a while to get it all right. I am of the belief that the experience is the same for many who transitioned to the Ruby platform. If you didn't experience this...lucky you! My reason for this experience is that during the early days of learning Ruby, I felt that the Ruby Object Model is some advanced topic as it is comes under Ruby Meta-programming, and that I can do away with it until I'm more than an intermediate level Ruby developer. In reality, though, any decent programming in Ruby meant understanding rightly - the Ruby Object Model. Understanding the Ruby Object Model helps not just in learning Meta-programming, but also improves code design with enriched knowledge and appreciations of the object model.

In my presentation, I intend to talk about the Ruby Object Model, elaborating on the concepts of visualizing classes and objects in Ruby, how they are different from Java, method look-ups in Ruby, class/static methods in Java/C# vs. the ones in Ruby, mixins over inheritence and composition etc. All these concepts will be communicated by means of code snippets and no-nonsense visuals (object-like diagrams).

The Ruby ecosystem is pretty awesome when it comes to developing or
consuming HTTP APIs. On the publishing front, the Rails framework is
an attractive option because it supports publishing what are popularly
(but inaccurately) referred to as 'RESTful' APIs quickly and
effortlessly. On the consumer side, the Ruby ecosystem provides
several very fluent and powerful libraries that make it easy to
consume HTTP based APIs.

Since a significant proportion of projects today require that APIs be
both published and consumed, many of them wind up choosing Ruby as a
platform for the reasons mentioned above. This talk is targeted at
folks that are currently on such projects, or anticipate being on such
projects in the future.

We will cover:
Consuming HTTP APIs:
1) The basics of making HTTP calls with Ruby
2) The strengths and weaknesses of Ruby's Net::HTTP across 1.8, 1.9
and JRuby (possibly Rubinius if we have the time to do research)
3) Popular HTTP libraries that either make it easier to do HTTP by
providing better APIs, make it faster by using libCurl or both
4) Different approaches to deserializing popular encoding formats such
as XML and JSON and the pitfalls thereof

Producing HTTP APIs using Rails:
1) The basics of REST
2) What Rails gives you out of the box - content-type negotiation,
deserialization etc. and the limitations thereof
3) What Rails fails to give you out of the box - hypermedia controls etc.
4) What Rails does wrong - wrong PUT semantics, no support for PATCH,
error handling results in responses that violate the clients Accepts
header constraints etc.
4) How one can achieve Level 2 on the Richardson Maturity Model of
REST using Rails
5) Writing tests for all of this

At the end of this, our audience will understand how you can both
consume and produce HTTP APIs in the Ruby ecosystem. They will also
have a clear idea of what the limitations of such systems are and what
the can do to work around the limitations.