Twiddle-waka way of specifying gem versions in Gemfile for a rails application.

Recently I came across situation when I spent really bad time resolving conflicts between gem version specified in Gemfile. This rails project had a Gemfile with all gem version specified in very strict way, for e.g. –

gem ‘rails’, ‘3.0.3’

gem ‘devise’, ‘1.1’

gem ‘omniauth’, ‘0.1.6’

gem ‘mysql2’, ‘0.2.6’

gem ‘twitter’

Showing above some of the gems from the Gemfile. I came across some bugs with currently used version of twitter gem while connecting to Twitter api’s. So I tried to upgrade twitter with

bundle update twitter

This was giving issue, that newer version of twitter required to have newer version of faraday gem. While bundler couldn’t install faraday, as omniauth was depending on this older version of faraday. I tried removing the version no. of omniauth from Gemfile, and ran ‘bundle update’. That way, bundler upgraded all gems and including omniauth, faraday and twitter and resolved all the dependency issues itself. This fixed old bugs with twitter, but my omniauth was now failing, as API for newer version of omniauth was changed.

So finally I posted a question over stackoverflow. This question generated some very good discussion but that didn’t cleared all the confusions with me as bundler solves many a problems like –

– Different systems should have same gem versions.

This is the requirement that all the developers should have same gem versions. Also development, production and staginging boxes should share same gem versions. This can be solved with Gemfile.lock file, and not by strictly declaring version numbers in Gemfile. One of blog post by Yehuda Katz explains this a bit, and encourages application developers to include Gemfile.lock in version control. I previously used Gemfile, without any version specification and it worked quite well as well, until one of the developer did ‘bundle update’. Running bundle update causes all gems to upgrade. This has high changes of breaking app, as newer versions of gem may have upgraded/changed/deprecated API.

– Application should stick to compatible gem version all the time.

This is to stay away from major upgrades to the gems, which come with gem API changes. These type of upgraded has potential to break application.

While searching a bit more about it, I found one good solutions – twiddle-waka.

Twiddle-waka can be said a pessimistic way of versioning. For example, a versioning should go as follows or as explained here

Version 2.1.0 — Baseline

Version 2.2.0 — Introduced some new (backward compatible) features.

Version 2.2.1 — Removed some bugs

Version 2.2.2 — Streamlined your code

Version 2.3.0 — More new features (but still backwards compatible).

Version 3.0.0 — Reworked the interface. Code written to verion 2.x might not work.

For above gem, if one uses version 2.* while developing, and then upgrades to 3.*, app is supposed to broke. But with pessimistic versioning i.e. using twiddle-waka, safer version can be specified as ‘~> 2.2’. With this, app will be using something strictly below 3.0 while bundle having more options to resolve dependencies with 2.* versions.

The only issue with this way can be said as quoted from Dan Croak’s post –

I think most people are in favor of this in principle but are not consistent in practice. This leads to confusion: “Which libraries are consistent and which aren’t? Is this gem safe to declare as a dependency at the major, minor, or patch level?”

It seems like a simple way of clearing up the confusion is for authors to declare their intention of consistent versioning by using the twiddle wakka in their README’s installation instructions. If I see this…

gem “clearance”, “~> 0.9”

… then, I feel the author is assuring me of the “safety” of this gem at the minor level.


So I would say, strictly specifying gem versions in Gemfile is not a good way unless exceptionally needed. This way bundler lefts with very few options to resolve dependencies and hence too much version conflicts may arise.

Not specifying gem versions at all in a Gemfile is also not a good practice. This way, some bundle update ran by some developer may update all of your gems, causing app to break.

Hence, the middle way is twiddle-waka. Specify gem versions, but with safe version range. This way bundler can have options to resolve dependencies and that is great help.

On your own.. With your sword.. Into the wild…

Wanted to write this blog post since so long, finally here it is. A blog post about so much a change moving ahead in career. i.e. about leaving one startup and being into another one, i.e. leaving weboniselab and being into rainingclouds.

I really liked a post by Matt Aimonetti about motivations and purpose of work. He referred to one of the RSA animation video which awesomely explains things  –

Link to YouTube video

So, when you think of work performance and work satisfaction, it all boils down to following things –

  • Autonomy: engagement vs compliance
  • Mastery: get better at stuff
  • Purpose: be disruptive but make the world a better place

WeboniseLab was a very good place I worked at. When we started last year, it was full of learning, enthusiasm, and always surrounded by very smart people. But a year down the lane, I lost the motivations, may be with lack of purpose.

So what next – 

When decided to leave webonise, I thought on many of the options, discussed a lot with my close friends. After all the discussions we decided to give ourselves a chance and do a startup to work on our own ideas – discussions ended with start of RainingClouds Engineering. Me and two very close friends of mine Aniket Awati and Amit Yadav will be team.

At RainingClouds we will be working on technologies we like, doing services to sustain, and building products for fun. 😛

Somewhere I read once, not having boss is actually a biggest challenge as there won’t be any todo lists from him anymore to finish and go, but those to be created on one’s own and take things to perfection with self-motivations. Things surrounding look more like – all the variables without single formula for success – as like saying – on your own, into the wild, with your swords.

Ratnadeep(rtdp) Deshmane,

Geeky Co-Founder, RainingClouds Engineering. 😉

Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)

Just got bitten these types of errors and lost an hour nearby, so making a note here if that helps. If you ever get error while installation a gem that – Gem Install ExtensionBuildError that means, you are missing some libs.

As of now, I have following three types of installations generally failing at my machine – 1. Nokogiri (workaroud for this can be found on nokogiri website.)2. mysql gem installation.3. pg installation.4. sqlite3 installation.

In above, for 2nd, 3rd and 4th – all are databases, and if you don’t have dev packages for them, it fails. For e.g. in my openSuse 11.04 system, by default it doesn’t has the mysql-dev, postgresql-dev and sqlite3-dev libs installed and it fails for sure. For ubuntu these package names may differ.


Ruby Conf India – Day 1 summary.

Sharing here some of the updates form Ruby Conf India, Bengaluru 2011 for the day one. I have written here only about the sessions which I managed to attend, as session were going in two tracks I missed some of them.

Starting key note – Yehuda Ketz

When building API heavy applications with rails, many people think that why to use rails, if we are just rendering json objects. They tend to think something like sinatra would do the job. But Yehuda had a point that Rails is not just about views and controllers and it has lot to do with abstraction over other things like – http requests, common security threads. He even made a point that for a developer to work on a rails application, he didn’t even required to know the http protocol details. Then he mentioned about upcoming gem, – bulk_api, a must look out for developers building api’s with rails.

Ruby Plus Rails Plus Your Application Minus Rails – Brian Guthrie

This was one of the most humorous talk of all. He briefly covered good practices in ruby/rails on the lines of – create classes, build api’s and test objects. All of this was explained with examples of Dosa stands getting comments and they being searched. He ended the session by talking about  his own secret of – how to learn ruby – 1. Read Ruby Code 2. Code Ruby 3. Code Outside Rails and understand where ruby ends and rails starts.

Deciphering The Ruby Object Model – Karthik Siransanagandla

This was very good enlightenment over objects and classes in ruby. Karthik started by taking everyone on ride by telling things like – classes are subclasses of Class class of class 😛

He then went on to shown hierarchical structure of ruby Objects, Module and Class and then subclasses. This talk was intervened by some very interesting question-answer sessions over the issue – Though Class is object in ruby, that doesn’t mean we can inherit from objects in ruby (especially for java developers, old concepts over oop holds true here).

Make your own Rails Framework – Pankaj Bhageria

Speaker Pankaj started encouraging and urging Indian rails community to participate more in Open Source contributions. He then live coded a basic frameworks with rack which can talk with web server and responds to requests.

Service (Keynote over video conference) – Chad Fowler

This talk ended the day on very high node. Chad’s 45 minutes of highly inspirational talk covered various values regarding service industry. The way he embedded the examples while explaining those values was absolutely amazing, i can’t recreate that all here.

Day one ended with much learning.. waiting for day two with lot of excitements….

Martin Fowler at Thoughtworks Pune about Software design and Architecture in 21st century.

Just today had a chance to attend Martin Fowler’s talk about Software design and Architecture in 21st century here at Pune, organized by Thoughtworks. In this post, I am iterating through some of his thoughts from today’s talk plus links to some of his very good articles and videos.

Martin Fowler’s talk was preceded by a talk from Mr. Vivek Singh about Architecture, Architects and Agile – A journeyman’s perspective. He talked mostly about architect’s (i.e. senior most person in agile team) role in team. In some interesting observations form him was how a manager’s timetable Vs maker’s time table works. Manager’s generally schedule there day in terms of hours, where they set out for different meetings and hourly completable tasks, while a maker’s time table i.e. developers time table is scheduled in two parts of day – before lunch and after lunch. A maker needs time to dig into his things and come up with some creative things. So, for architects, as being team leader it is better suited to schedule there time alternatively in these two paradigms.

After that, Mr. Fowler as he said, rather than giving a single long boring talk, divided his talk in three small boring talks(though there wasn’t any). First topic was about continuous integration. In first

few slides, he covered how continuous integration can help from version control point of view. Rather than few developers working together and merging the feature branches after many days to find out that both groups made some basic architecture changes and come back to original fork point to solve conflicts, it’s good with continuous integration to discover these things earlier and correct them. With graph of pain Vs deployment time deply he justified that rather than having all pain in the end because of late deployment, have a chunks of pains with continuous deployment.

More about continuous deployement from Martin Fowler –

Second topic was about Utility vs Strategic dichotomy. He reminded one of the incidents from past where one of salesman had to listen from prospect that “software is like sewage pipes, I want it to work reliably but I don’t want to know about the details and what goes through it”. Most of the software development comes under utility sector, while it’s very less as strategic. Strategic softwares are characterised by speed, innovation need for business to do it better.

He revealed his secret of taking good photographs – take many. As you take many photograph, chances are at least some will be good i.e. to having one innovation means having many failures. Same applies for software. But here with agile you have advantage of failing fast, and so you may get leisure to fail more. 😉

About Utility Vs Dichotomy –

One more video talk – here

Third talk was about Domain Specific Languages. Some links from his blogs –

So, this solved many of questions about agile, architecture but also created new and many questions, building more interest towards it.