engineering perfection on rails

Memories of conf.KDE.in

Well they say in solitude you sometimes remember your fondest memories, I would like to share with one you folks.

Today morning I realized that it was March, now March might be an ordinary month for most of you but looking back I can say for sure it was and it still is special for me;  I can clearly recall the events that occurred and how they changed my life.

A year back the first KDE conf India happened from 9-13th of March, I remember I was more of an ordinary student in the class, I had a decent GPA and I used to get by without much trouble for the most part but somehow on 9th I had an urge to attend KDE conf despite it had 700 bucks for registration and my HOD(Head of Department) had clearly denied the request to attend it, but I still went for the conference as it was happening right below my department.

I wish I could say that after attending the very first talk of the conference my life changed but in actuality nothing happened ;  I met really smart people but that just increased my insecurity and I couldn’t follow most of the talks. I was doubting if I made right choice of attending it in the first place, both 9th – 10th went without any feelings that I learned something valuable, something which I could have followed and used in my daily life.

Than came 11th March, the day was normal till the afternoon after that we had a hands-on bug squashing lab, where young KDE developers would guide us by fixing a bug from KDE bugzilla. Since it was the last day for the talks and I was tired with all the information i received which I couldn’t made sense of; I wanted to skip the lab but somehow I didn’t do that for some reason. In the lab we had to solve a bug in Rekonq (a browser bundled with KDE) the bug description said that it had to something to do with ad blockers, now I used to browse the internet before and I knew a thing or two about how Ad-blockers work; so I quickly found the code/file which needed to be patched and it was more of a lucky guess then any real skill involved but that was enough as it impressed the KDE developer that were there.

One particular (Vishesh Handa) came to me and told me that I knew things and I should  use my knowledge to write patches for KDE and there is something about it; when a complete stranger sees your work for the first time and praises you for it. I think I was on cloud nine for rest of the day; when I reached my apartment I started looking for sub project to contribute to and I found Nepomuk junior job page which basically consists of easy bugs which can help new people learn about the project, bug fixing and writing patches but I was naive and I didn’t know where you can actually find the source code, let alone any knowledge about version control systems.

Luckily next day it was a hacking session for the speakers; I took that opportunity to meet them and learn how to solve bugs and where to find help in case you don’t know what to do. They even gave me a simple bug to get started on which was quite trivial and would take around 3-4 lines of code to solve it but with all things that look simple while looking back, the bug took me more than 6 hours to fix as I was clueless on where exactly i needed to put that code in the first place.Though all of that work didn’t go to waste as I remember the feeling when that patch was committed on the next day. I was hooked after that commit and in 3-4 days I submitted even more patches which eventually got committed. After a month or so I finally received my KDE developer account to push my own commits.

Looking back, if I had not attend the lab or if that KDE developer (Vishesh Handa) hadn’t said those things to me, my entire life would have been completely different and I would be a normal guy today working at a MNC but thankfully life had better plans. So many great memories are the result of that one moment and in my heart I still have gratitude for KDE without it I wouldn’t have become a contributor, a GSoCer, made smart friends, visited different places, improved my programming skills and maybe biggest of all I wouldn’t be a part of c42 (The place I work at). My entire life from that single moment to the moment when I received my first salary is indebted to KDE.

Recently, I finally had the chance to catch up with one of my friend from KDE (Shantanu) whom I first met at conf.KDE.in . We kept delaying our meet because of our busy schedules but we finally caught up last Sunday and the last Sunday was on 11th March. eh, coincidences can be funny sometimes

Our RubyConf XI talk on Continuous Delivery

Ruby Software Continuously Delivered and Exhaustively Explained from Srushti Ambekallu on Vimeo.

This is the recording of our talk at RubyConf 2011 at New Orleans where Brian and I gave a slightly different version of our talk from RubyConf India 2011.

In this talk we focused on the value of Continuous Delivery as a practice and how it's an extension of Agile methodologies, and being able iterate on the product in quicker cycles helps deliver value to and gather feedback from users faster.

We spent some time going over tools you can use to automate the process, like Chef, Puppet & Capistrano among others.

We also discussed various branching strategies you can use and their relative pros & cons. Branching becomes a requirement for features that require a long time to develop (where you can't make incremental deploys) and when you are doing continuous deployment.

Our RubyConf XI talk on Rails services

Rails services in the walled garden from Sidu Ponnappa on Vimeo.

This is the recording of our talk at RubyConf 2011 at New Orleans where Niranjan and I speak about "Rails services in the walled garden."

In typical service oriented architectures, monolithic applications are sliced along domain verticals to create several independently evolving 'services' that can be used in combination to achieve various outcomes.

Rails applications lend themselves to this architecture beautifully and are slowly making inroads in big organisations for this reason.

One of the big problems with this approach is that analyzing and managing large quantities of data from multiple services to produce a result becomes very hard. What was originally a relatively simple task when all data sat in the same database as part of a monolithic application, becomes, when split into multiple services, a whole different beast. This talk will focus on our experiences building a system involving about a dozen rails based services integrated over HTTP and XML and the issues we had to deal with when working with large data sets.

We are speaking at RubyConf US 2011!

Three C42ers will be speaking at RubyConf US this year. Srushti, lead developer on the Goldberg CI server will be pairing with Brian Guthrie of ThoughtWorks to deliver a talk titled "Ruby Software Continuously Delivered and Exhaustively Explained."

Niranjan and I will be pairing on the second talk titled "Rails services in the walled garden."

This will be our second year speaking at RubyConf, and we're really looking forward to it.

If you'd like to see our other presentations, do take a look at the videos of our talks from RubyConf US 2010 and RubyConf India 2011.

RubyConf India 2011 - But the language supports it

In RubyConf India 2011, Aakash and Niranjan spoke about a few features of the Ruby language which when used wisely allow programmers to solve problems elegantly but if they are used without caution can lead to bad code.

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."

For more talks by us at various conferences, please look for posts tagged 'conference.'

But the language supports it from Innovation & Technology Trust on Vimeo.

RubyConf India 2011 - I can haz HTTP

Niranjan Paranjape and Sidu Ponnappa of C42 Engineering recently spoke about consuming and producing HTTP APIs in the Ruby ecosystem at RubyConf India 2011. Here are the slides we used and a recording of the talk itself.

I can haz HTTP: Consuming and producing HTTP APIs in the Ruby ecosystem from Innovation & Technology Trust on Vimeo.

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.

For more talks by us at various conferences, please look for posts tagged 'conference.'

RubyConf India 2011 - Continuous Delivery in Ruby

Brian Guthrie of ThoughtWorks & Srushti Ambekallu of C42 Engineering spoke at RubyConf India 2011 about the tools & practices that will ensure you are able to continuously deliver your Ruby projects.

Continuous Delivery in Ruby from Innovation & Technology Trust on Vimeo.

Ruby is generally accepted as a language that lends itself to being able to develop and release features quickly. But, how can we really crank up the frequency of getting to features to the market? And just as importantly, how can we make sure we can deploy with confidence?

For more talks by us at various conferences, please look for posts tagged 'conference.'

Our RubyConf X talk on offshoring Ruby

India::Ruby - Offshoring Ruby (RubyConf X, New Orleans) from Sidu Ponnappa on Vimeo.

This is the recording of our talk at RubyConf X. This talk draws on our experiences over the last four years of working with Ruby in India, starting with a Ruby based product startup in 2006, two years spent working on offshore Ruby projects at ThoughtWorks India followed by nearly a year building and running C42 Engineering.

For more talks by us at various conferences, please look for posts tagged 'conference.'