Add an eventRubyConf India 2011 schedule
Saturday 28th May 2011
-
Building Rails Apps for the Rich Client
by Yehuda Katz
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.
-
Deciphering The Ruby Object Model
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).
-
I can haz HTTP: Consuming and producing HTTP APIs in the Ruby ecosystem
by Sidu Ponnappa and Niranjan Paranjape
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 thereofProducing 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 thisAt 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.
Sunday 29th May 2011
-
Let's Have a Cup of CoffeeScript
CoffeeScript is a great way to write javascript. It provides many abstractions that simplify the language, and a few syntax niceties that make it much less noisy than pure javascript.
In this introductory talk, we present the language through several examples, looking at many of the features CoffeeScript provides for simplifying the way we write JavaScript. Hopefully in a way that will inspire you to go out and try it!
-
Continuous Delivery in Ruby
by Brian Guthrie and Srushti
The Ruby community has driven a lot of technical innovation in deployment and configuration management over the last few years, and so the idea of delivering high-quality software rapidly should be familiar to most of us. But although our tools are state-of-the-art, getting them to work together properly can be surprisingly frustrating. In this talk, I'll explain how to implement a high-quality rapid build and deploy process using standard CI tools, Bundler, RVM, and Capistrano. I'll also discuss how to coach your developers, QAs, and client to be "production-ready, any time."
-
But the language supports it
by Niranjan Paranjape and aakash dharmadhikari
Discussing language constructs with fellow developers in the context of solving a particular problem is something we do routinely. While most such conversations are productive and useful, a fair portion degenerate into angry brawls. A pattern we've observed in the latter situation is that a surprising number of times the argument is that "Why shouldn't I use language feature X to achieve objective Y- after all, the language supports X."
In this talk Aakash and Niranjan walk through a few features of the Ruby language which when used wisely allows programmers to solve problems elegantly but if they are used without caution can lead to bad code.