toamitkumar's Code Blog

Ruby, Rails, RubyMotion, Chef, Puppet, Play and others. Opinions expressed here are my own and do not reflect those of my employer.

My First Impression at #inspect2013 - RubyMotion Conference

| Comments

The first RubyMotion Conference #inspect2013 happened in Brussels, Belgium. It was a very well organized conference, lots of talented people, awesome speakers, good food and yes ‘Belgian Beer’

One Man Army - Laurent Sansonetti

Many thanks to Laurent Sansonetti (@lrz) for making it successful.

The general gist of what happened there. Below are my observations and opinions.

What I saw at #inspect2013 - RubyMotion conference?

For people who don’t know about RubyMotion:



The Community:

Community plays a very important role in the success of Open Source Software. Even though RM is licensed, it has blessings from Ruby Community.

Rubyists (including me) who have tried Obj-C in the past have found it verbose and complex. We all embraced RubyMotion because of its simplicity and more important being a developer friendly language - Ruby.

At the conference I saw a lot of seasoned Obj-C developers who had tried RM and loved it. Now, they are using it for full fledged production applications. One of the big reason for this is Cocoa-Pods. They can still use their legacy Obj-C code / project in new a RM application. The build system takes care of linking and tying them during compilation. No need to re-invent the wheel, utilize the investment people have already done in iOS world. This is an interesting phenomenon because this is going to push the toolchain to next level.


It is less than a year and the RM community has grown exponentially from few rubyists to thousands of iOS developers. There has been tremendous contribution by people to build ruby-motion gems/libraries/wrappers around verbose Obj-C code.The list is very big but I should definitely mention:

A lot of talks at the conference were about these libraries and wrappers.

Focus on testing:

Ruby Community has successfully induced the importance of testing the code. Though RM comes bundled with a testing framework, its hard to do UI testing on iOS and Obj-C has suffered a lot because of this.

At the same time, it is unusual that Rubyists would not explore options to test their code on iOS platform.

In the conference I got to learn some awesome frameworks out of which ‘motion-calabash’ is really good. It gives you BDD style testing similar to what we are familiar in Ruby/Rails world - Cucumber.

You should definitely checkout . A sample app

The one thing I would like to explore is the possibility to test my HTML5 phone-gaped application using 'motion-calabash'.

When I am developing for mobile platform I miss Chrome Developer Tools a lot. Not any more. It blew my mind to see the demo by Colin Gray (@colinta). Motion-Xray: An iOS Inspector that runs inside your app, so you can debug and analyze from your device in real-world situations. It is amazing, go check it out

Broader Reach:

I was completely stunned to see presentation in a technological event by a visually impaired (I don’t mean to hurt anyone. I had never seen such a thing happening and it was a complete jaw-drop for me). Let me introduce Austin Seraphin ( . He is an iOS developer and iOS Accessibility Expert. He explains how iPhone and Accessibility changed his life. A completely new perspective. His slides if you are interested - I would urge to have a look at them.

Trend and My Reaction:

Laurent was the last to present at the conference - a noble decision I would say. He talked about roadmap and the future of RubyMotion. I see a focus shift to make the toolchain more developer friendly.

Some highlights:
  • High-level debugging support: right now it uses GDB technology which is pretty low-level.
  • Documentation: add more documentation to make it easier for newbies.

I definitely feel RM is going to change the way we are used-to doing native iOS development. So, don’t delay, hack and be awesome.

Finally, here is the presentation (Building Interactive Data Visualization Charts) @rubymotion conference:

Please share your thoughts.

Enjoy !

Permission Denied (Publickey)

| Comments

Adding the SSH keys on your github site is the simple solution. I am using 3 github sites; - 1 external - 2 behind the firewall

Each have their different email address for security reasons.

So, quite often, I get this error - if I mess up things. I was looking for a solution so that you can create a public rsa file for each github site.

The solution was to create config inside ~/.ssh directory.

The file:

  User git
  Port 22
  IdentityFile ~/.ssh/github_site1_id_rsa
  TCPKeepAlive yes
  IdentitiesOnly yes
  IdentityFile ~/.ssh/github_site2_id_rsa
  IdentityFile ~/.ssh/github_site3_id_rsa

Bingo !!

I am sure there are other better ways to solve this problem.

I would appreciate comments.

Agility and Component Driven Development

| Comments

Agile development has become the backbone of modern software development process. In a nutshell, it can be defined as - iterative, self-evolving incremental development that demands high collaboration and flexibility to change . Component driven development on the other hand augments to building reusable and testable components that be plugged together to form application foundation for delivering business functionality.

In our current engagement with Firm Account, they have started providing IT tools/solutions to their clients supplementing the strategic solutions they have been providing so far. They wanted to deliver the solution with rapid-prototyping and


The challenge was to deliver the solution in quick 2-3 months iterative cycles. The working software was to be delivered and handed over to IT department of the client. This meant the software has to be of high quality and maintainable with least amount of support


Each application we were building had certain common components. For eg:

- Authentication 
- Work flow process
- Data upload process
- Data crunching and cleansing 
- Data export
- User Management with corporate level security
- Background processing for data manipulation
- etc.

This problem can be easily solved with Service Oriented Design Pattern. But since most of the deliverables were ‘leave behind’, we started to observe an evolving pattern of Component Driven Development. There was two approach to establish a pool of commonly required components.

1. Staff a team that is responsible for building common components
2. 'Tax' teams to contribute 'components', if they use any from the components library.

The first seems more common but does not align with the paradigm of Agile Software Development. One team should not be responsible for building and maintaining the software. Over time this leads to quality compromises and delays in deliverables.

Extracting common components from existing applications and taxing teams (who want to use from pool) to contribute to common pool did the magic. Initially leap was a little difficult. It took sometime for us to institutionalize the mind-set of building component -based software that can be contributed back to pool. Once the team was adept with this working process, the pool expanded and became rich.

Impact and Benefits

  • Redundant work, development time: Developing every system from scratch means redundant development of many of these re-usable components. These can be shared shared across multiple applications reducing development time.
  • Time to market: Each application goes through rigorous process of QA and Security Assurance. This meant a lot of time was wasted testing the components that can be built and tested once. Using re-usable components reduced the time to market by ~40%.
  • Expertise sharing: Software reuse supports the sharing of knowledge naturally. This helps in learning from peers and improves the quality of deliverables
  • Focus on solving the actual business problem: Teams can focus on solving the business problem rather than spending time building the components that are common
  • Rapid prototyping support: Reusable components can provide an effective basis for quickly building a prototype of a software system. This provides the opportunity to get customer feedback early in the life cycle, thus supporting the conception of requirements.
  • Maintenance costs: Fewer defects can occur when proven components have been used, and less of the software system must be maintained.
  • High quality: Error fixes occur from reuse to reuse. This yields higher quality for a reused component that would be the case for a component that is developed and used only once.

What do you think ?