Get Lanyrd on your mobile (iPhone, Android and more) - check it out here

RubyConf India 2010 schedule

Unscheduled

  • Blood, Sweat and Rails 2010

    by Obie Fernandez

    Take a break from the technical mumbo-jumbo and listen to Obie leverage his wit and real-life experience in what promises to be an entertaining and insightful session geared towards current and aspiring Rails entrepreneurs. In early 2007, Obie took a leap from being a full-time coder into the treacherous world of business. Growing Hashrocket from a little 4-person boutique to 35+ people in two year without going broke and keeping clients happy has been a huge challenge. The RubyConf India version of this talk is fully updated for 2010 and includes new material never presented before.

    Coverage write-up

  • Building cross-platform Mobile (Smartphone) Apps with Ruby & HTML

    by Dasharatham Bitla

    An introduction to Rhodes” - Mobile Apps Development has taken by storm after the introduction of iPhone and the App Store. Its a long way with others like Android, Blackberry etc entering into the arena. Developing mobile apps for each device and mainting different code bases is not so DRY and its too time consuming. Presenting one of the frameworks that uses Ruby & HTML so effectively in developing crossplatform mobile apps with one single code base all written in Ruby!

    Rhodes is an open source Ruby-based framework for building locally executing, device-optimized mobile applications for all major smartphone devices. These applications work with synchronized local data and also take advantage of native device capabilities such as GPS, PIM contacts, camera, and SMS. Yet you write the majority of your interface with high productivity in HTML and Ruby. Rhodes allows you to write an app once and it will then run on all iPhone, Windows Mobile, BlackBerry, Symbian and Android smartphones. During this session we'll build a sample app for all mobile devices, from scratch, in minutes.

  • Concurrency patterns in Ruby

    by Sai Venkatakrishnan and Hari Krishnan

    Ruby is a wonderful language for rapid development, it is easy to learn, we have wonderful frameworks, an active and dynamic community. But when it comes to concurrency Ruby is plagued with problems, controversies and urban legends. A lot of people would know about green threads in Ruby, GIL and its inherent limitations. But that it only one part of the big picture. Ruby offers much more than threads to helps us with concurrency.

    This presentation explores other options of writing highly concurrent applications in Ruby and options available in it. We cover topics ranging from Actor like message passing concurrency in Ruby, dataflow concurrency of how we can coordinate across different threads, Event driven methods, coroutine based concurrency which never blocks ;) and finally Software Transactional Memory. We look at lots of code, some serious looking yet colorful performance graphs comparisons, and conditions at which each of these forms are concurrency are effective and ineffective.

    Coverage slide deck

  • Events, threads and writing robust client/servers in Ruby

    by Hemant Kumar

    I have been building client/servers in Ruby for past 3 years and drawing from that experience I would talk about Threads in Ruby, Reactor pattern in Ruby, Eventmachine, Revactor, Packet, Actor pattern in Ruby, protocol parsing (ragel). Touching upon various threading implementation in MRI1.8, Ruby1.9 and JRuby. Best practices regarding threading. Writing threaded clients/servers. When threading model suffices and when it breaks down. Non-Blocking IO in Ruby. Select VS other advanced selectors. When to use NIO model and when to look for alternatives. Using Actor pattern in conjunction with Reactors for better scalability. And at last if time permits, I would present my ideas on building better network protocols and using ragel for protocol parsing.

  • Exploring Rails 3 Through Choices

    by Nick Sieger

    One of the most eagerly anticipated aspects of the fast-approaching Rails 3 release is its inherent modularity, and how that modularity gives the application developer more choice. We'll start with a tour of some of the headlining differences between Rails 2 and 3, and then put Rails 3's internal architecture to the test by demonstrating how to plug in some non-standard standard components, including an example of how to wire in a Java library using JRuby.

  • GlassFish supports multiple Ruby web frameworks ... really?

    by Arun Gupta

    GlassFish is an open source and production-quality application server with full enterprise support from Sun Microsystems. In addition to traditional Java EE applications, it allows applications developed using different Ruby frameworks to be easily deployed as well. The choice of application frameworks is also available for Groovy/Grails and Python/Django apps and can be easily extended further.

    This talk will demonstrate how GlassFish provides an extensible framework that allow applications created using different Ruby frameworks can be easily deployed. The attendees will learn the different deployment models available in GlassFish through live coding examples and several customer use cases of Rails deployments on GlassFish. The talk will show how Rails, Sinatra, Merb and any Rack-based framework can be easily deployed on GlassFish. It demonstrates how popular Rails applications can be easily deployed on GlassFish without any modification, and shows how GlassFish Gem can be used as an effective alternative to WEBrick, Mongrel, and other traditional deployment models.

    It also explains the inner workings of GlassFish so that developers understand what’s happening under the hood. It will explain how standard Java monitoring technologies like JMX can be used to monitor/manage these applications.

    The session also demonstrates how NetBeans provides a comprehensive IDE for developing, running, and debugging a Rails application directly on GlassFish – all without using any Java code.

    Coverage slide deck

  • Hacking and Learning from Open Source Ruby

    by Sreekanth Vadagiri

    Coverage audio clip

  • IronRuby: The Ruby & .NET Love Child

    by Ivan Porto Carrero

  • Let’s build a Ruby application server

    by Vineet Tyagi

    Would you like to know how to build an application server from scratch? This talk would provide an insight to the thought process and the key decisions made while building WebROaR from grounds up using C & Ruby.

    What enables this server to deliver high performance and also offer a rich bouquet of integrated features like Analytics, Exception Notifications etc? If gaining knowledge about design of a good software product interests you, do join us for this interactive session.

  • MacRuby to The Max

    by Brendan G. Lim

    My presentation will be on the topic of MacRuby. MacRuby is relevent to Ruby developers because it allows us to dive into the world of Mac OS X development using Ruby 1.9. Unlike RubyCocoa, where we would need to use both Ruby and Objective-C, MacRuby's API allows us to just use Ruby.

    I will go into a brief history of MacRuby and explain just why it is important to us as Ruby developers. I will then do some live coding of a quick desktop application using MacRuby. Attendees will be able to take away from the presentation a good understanding of MacRuby and the passion to develop something of their own using it.

  • Managing entropy on long term Ruby and Rails codebases, or how not to kill a Ruby project in eighteen months

    by Sidu Ponnappa and Niranjan Paranjape

    All codebases have entropy and tend to degrade over time. Ruby is a hugely flexible language, and as a consequence Ruby codebases tend to suffer more than most from this kind of gradual degradation over time, especially in situations where part of the development team is new to either Ruby, or the project domain or both.

    This talk is about all the ways in which a Ruby codebase can be slowly drawn and quartered over time. We will talk about the kinds of the anti-patterns one can expect to see, the smells which indicate their presence and the mechanisms that can be used to prevent their occurrence or minimise their effect on the codebase. Examples are drawn from the presenters' experience working with a suite of integrated Rails applications ranging from four years old (legacy applications in Rails terms) to a few months old as well as their experiences in working on open source Ruby projects.

    We will cover runaway meta-programming (someone overwrote Object#responds_to?), poor performance (someone thought creating a Document for *every* response was a good idea - and used REXML) and other issues that are common, weird or simply entertaining.

  • Mortal Kombat: Developer vs. Designer

    by Kapil Mohan and Arun Jay

    Web front-end engineering has become way more complex than one imagined. There is HTML markup, content, CSS and Javascript intertwined to produce amazing web experiences we see all over the web. And this results in a problem which everyone must have faced - the developer/designer overlap.

    Here's an example of a typical development workflow: designers do wireframes, mockups, page layout, visual design, typography, CSS and markup. And hand it over to developers to wire it up with ruby code. It is quite unrealistic to assume that view layer will have zero ruby code (you will, at least, need print statements!). Now, once the markup is wired up with ruby code, maintenance becomes a problem for designers. A designer cannot go back and change the markup without a developer. Also, to multiply the problem, there are partials. So, designer can never look at the markup as ONE single HTML page and make design improvements. And if you'd look closely, the 'hand over markup' part suggests that this entire workflow is NOT agile!

    The underlying problem with this workflow is that the code and markup are not 'completely' separate. In an ideal situation, code, markup (page structure), CSS (visual design/style), javascript (behavior), media (flash, images, etc) should all be separate. Separation helps developers and designers focus on what they do best. The designer can focus completely on getting the final page exactly the way they designed it. This includes page structure, semantics, standards, accessibility, and optimization. This lets the developer focus on writing great code and solving their problems. Yes, we are talking about zero ruby code in the view layer.

    Enter hquery: Invented by (Chew) Choon Keat from Singapore (github.com/choonkeat), hquery is an unobtrusive server script implementation for Ruby on Rails - github.com/choonkeat/hquery. It is a rails plugin which lets you manipulate HTML markup using selectors etc, almost like jquery, except that it is on server. It was Choon Keat himself who introduced and demonstrated this powerful plugin to us while he was working with us at SlideShare. Since then, we've adopted this markup/code separation technique for all important pages at SlideShare. And it makes our developers and designers much happier. We find them playing Mortal Kombat on PS3 more than in their real lives now.

    The idea is that you have 2 files - .hquery and .hquery.html for every webpage you need. .hquery.html is ONE file with entire HTML markup needed to render the page. And, .hquery has code which uses hquery plugin to replace markup in the .hquery.html file with ruby code and turn it into a .erb file. .hquery file is used to compile .hquery.html into .erb files. Obviously, replacing markup with ruby code and then rendering it on the fly will get expensive soon. So, this transformation of plain HTML files to .erb files can happen once during the application deploy step.

    The end products (.hquery file and .hquery.html) are more maintainable, especially as logic piles on. There is a clear separation of the designed web page and it's structure (.hquery.html) and the server data that's weaved in (.hquery). The connecting factor is CSS class names that act as hooks to connect the two separate layers.

    During the talk, we'd like to show demos of how we use hquery and talk about pros/cons and more advanced stuff like code reuse etc.

    Coverage slide deck

  • Present and Future of Programming Languages

    by Ola Bini

    Programming languages are at the core of our profession. But we don't always give them as much credence as they deserve. The strength of Ruby lies in its heritage from a number of different languages, and a look at the history leading up to Ruby might reveal what lies in store for the future. At the moment a lot of attention is spent looking at programming languages and developers are realizing that your language is an important tool. I will talk a little bit about why languages matter, why you should know several, and what the future of languages might look like.

  • Project Fedena and Why Ruby on Rails

    by Arvind G S

    Fedena is an open source school management software based on Ruby on Rails framework. It is a web 2.0 web application being developed by Foradian Technologies. Fedena is currently in closed beta. Visit http://www.fedena.com/ or http://en.wikipedia.org/wiki/Fedena more info.

    The first part is about the birth of fedena. And why we chose Ruby on Rails for its development. My team was not experienced in Ruby on Rails. Actually they had no experience on practical programming skills other than the textbook knowledge on C and C++ that they get from and Electronics and Communication degree. They are now experienced programmers in ROR and are actively involved in various opensource ROR projects.

    The second part is about our experience on ROR and the advantages and disadvantages we felt while coding and deploying. The third part of the talk is about why we are giving fedena as opensource to the community. The business model of opensource software.

    Coverage slide deck

  • Ruby on Rails versus Django - A newbie Web Developer's Perspective

    by Shreyank Gupta

    As I have been developing Web Applications for just more than an year now, I can safely introduce myself as a Newbie Web Developer. A year ago, when I started out, my first choice when it came to building Web Apps was Ruby on Rails. The reason was the fascination. There was a steep learning curve from my Python background, but it was all worth it.

    Today, working in the industry as a Web Programmer, I program applications in both Ruby on Rails and Django. And during my coffee-breaks, when I sit down and retrospect, I start comparing. And when I compare, I come up with advantages and disadvantages of both the web frameworks.

    Both Ruby on Rails and Django are no doubt (in my opinion) the two best Web Frameworks in existence. Both have their own bits of Superiority and Inferiority when compared with the other. My talk aims to put these bits in front of the audience and have a little discussion on the areas of improvements.

    Coverage slide deck

  • Ruby OOP - Objects over Classes

    by Aman King

    Asked to design an object-oriented solution to a problem, most of us would come up with a list of classes and an idea of how they'd interface with each other. Some might even figure out the class hierarchies and the methods involved, not to mention the methods' arguments. Those who desire further details would begin thinking of the data fields to be placed in the classes. This class-driven technique for coming up with OO solutions is a well-known one, and almost all OO languages support this by providing constructs to represent classes, methods, attributes, inheritance, and so on.

    A language like Ruby, however, goes a step beyond to provide certain features that pertain not to classes but to "objects", independent of their class hierarchy. And yes, unlike conventional languages like Java, there is a clear distinction of whether the concept applies at a class-level or an instance-level. Take for example access modifiers:in Java, when a method is made private, its privacy is tied to theclass; two objects can call each other's private methods as long as the calling and called codes reside within the same class definition. In Ruby, if a method is made private, the method cannot be invoked by any other object, even from code that originates within the same class. Similarly, Ruby allows a method to be defined at an object-level, making it available only via that particular instance and not any other object, even of the same class. And, of course, there is "duck typing" which says that for a method to be invoked on an object, what matters is not what class the object belongs to but whether such a method exists for the object or not.

    Such features are shifting focus back to the "object", and are gradually leading programmers to think more about objects and their interactions, rather than class-related concerns. This makes for a more lax and open playing field that retains the cleanliness and maintainability of a class-based approach while encouraging newer ideas that tend towards a truly "object"-oriented solution. My session will expound on this thought, providing examples to delve deeper into the OOP mindshift that is coming about and the benefits thereof.

  • The Big Wave of Indian Startups - (Almost) Effortless Entrepreneurship using Ruby

    by Pradeep Elankumaran

    India's up and coming startup culture is one that's been long-overdue. While the country's large pool of talent and artistic minds is primed nd ready for starting up hundreds of innovative web companies, the reality is that not many exist, and the ones that do rarely compete on the global stage. While the problems facing new companies in India are well-known, there are alternatives to going the 'traditional' startup route.

    This open-ended talk will put forth some new techniques for Indian entrepreneurs to compete globally, by leveraging agile and rapid development efforts using Ruby that directly appeal to cash- and time-strapped founders. There will also be some discussion on growing your startup, finding good developers, helping build a community of like-minded individuals locally, and pointers to next steps. The last quarter of the talk will be an open-mic Q&A session that will help directly identify pain points for entrepreneurs in India and possible solutions to the same.

    Coverage audio clip

  • The Ruby on Rails I18n core API

    by Neeraj Kumar

    Across the world, natural or regional languages differ in many ways, (e.g. in pluralization rules). Therefore, Internationalization became a complex problem and it is hard to provide tools for solving all problems at once. Sven Fuchs focused to provide an extensible framework and easy to use gem that is Ruby I18n (internationalization) gem.

    The Ruby I18n gem is mainly designed for translating your application to a single custom language other than English or for providing multi-language support for your ruby on rails application. The pivotal point of the new I18n api in Rails is the I18n module which is provided as a gem and shipped with Rails (starting from Rails 2.2) in ActiveSupport’s vendor directory.

    Therefore, during my presentation I will try to go over some of the advanced optional features and architecture of I18n gem. Besides, I will also try to cover begin with I18n gem, setup, benefits, the work flow, what's in? and what's not? Etc.

  • The Taming of the View

    by Sarah Taraporewalla

    We know that testing is important; that separation of concerns is important; that modeling our domain is important; and that their are often many domains within an application. So why is it that most of the view engines make it so easy to break all these important activities?

    View engines, such as erubis and ERB, make it so easy to break the model-view-controller-paradigm by allowing turing-complete code in the view. It is so easy to pull the database into the template by making calls such as <%= Order.find(:all, :conditions => { :status => 1 }) %>. Oh no! Now separation of concerns is thrown out the window, closely followed by testability and domain modeling.

    Never fear - there is a better way! By following the teachings of String Template, we can introduce a strict enforcement of the model-view-controller-paradigm. In this session, we will highlight the problems with the existing engines, explore the possibilities of String Template and introduce Slippers - the ruby port of string template.