Siddharth Sharma
Ranked 30 in Phase 1 with 53 unique views, 28 counted upvotes and 12 counted downvotes

About the author

Hi, this is Siddharth Sharma from Mumbai, India. I've been a rubyist since 2008 and been programming pretty much every day since 1987. I'm the author of several datamapper gems and have some modest open source contributions. It has been very interesting to be a part of this wonderful community and to learn along with it the best way of building large, complex real world applications. I do believe I have one or two learnings to contribute and I'd love the opportunity to show you how I build Ruby applications and present them to the web! Do upvote my proposal on how to "build your own web framework in half an hour".


Everyone knows that in Object Oriented programming, the Single Responsibility Principal (SRP) is the bedrock of happy code. However, when it comes to our frameworks, we are happy with a separation of responsibilites largely into the Model, View and Controller type of responsibilites. This leads to various object oriented anti-patterns existing in our frameworks. It leads to the creation of layers that straddle the boundaries in the MVC paradigm such as service layers, presenters and so on. In this talk, I propose that MVC is no longer adequate for building applications in Ruby and what we need instead is a focus on classes that do only one thing.

Take for example, everyone's favourite whipping boy - the Controller. The Controller is responsible for authentication, authorization, assigning data and returning the response for index, new, show, create, delete, update, edit, destroy and any other action that you care to stuff into it. No wonder everyone hates controllers. They are an OO anti-pattern.

It's time to take matters into our own hands and use MVC not as a strict rule but rather as a convenient nomenclature and replace it with what is much better suited to building applications.

I will show the audience how to build an application first and then how to present it to the web using nothing but tiny classes with one responsibility each. I'll demonstrate how to deal with this level of modularity without going crazy and lastly, I'll demonstrate the benefits of this approach by turning the same application into a mobile app by changing nothing in the application, only its interface to the rest of the world.

Previous Next