Creating Custom ListViews in Android using RubyMotion

While working on a Android app in RubyMotion I wanted to create a layout that is a list of editable key-value pairs like this


Android already has a view to display items in a list called ListView. By default, a ListView can store a collection of values and displays those values in a TextView, which the user cannot edit. So, the list of key-value pairs will have to use a custom implementation.

The default ListView uses an Adapter to store and manage the values in the list. The Adapter in turn contains a collection of items and implements a method called getView. The getView method returns a View for the nth item in the Adapter's collection.

Overriding the getView method in custom Adapter is pretty much the trick to creating a custom ListView.

So, for the custom implementation, the KeyValueAdapter will be a subclass of the BaseAdapter and will override the default getView method. The KeyValueAdapter will also contain an array of key-value pairs that stores the keys and values. Why not a hash of key-value pairs? Because the Adapter needs a to fetch the key-value pairs by index in the getView method.

The KeyValueAdapter will look like this

The source code for the layout is uploaded here.


Shishir is an engineer at C42 Engineering. If you liked this post, please consider...


Hand Rolling attr_accessor In Ruby

Ruby is a dynamic language that allows us to do great things at runtime. Today, we are going to see how we can use metaprogramming to add methods to an object after it has been created.

Let us create a method my_attr_accessor which mimics Ruby's built in attr_accessor. attr_accessor is used to dynamically create getters and setters for the fields of a class.

We will need to define my_attr_accessor in - please pay attention, this may be confusing - the class Class as an instance method. This makes my_attr_accessor available in all classes as a class methed.

It does nothing at the moment, so we expect NoMethodError to be thrown if we try to use the getter and setter for max_speed.

To be able to run the specs that are present in each of the file snippets below, please make sure that you have rspec gem installed. To run, use the command rspec <filename>.rb

To create a getter and a setter, we are going to use ruby's Object#define_method. This method allows us to add a method definition dynamically, at runtime, to our object.

Now that we have the method definitions in place, we will need to add the actual implementation for accessing and modifying each of the attributes in order to get the specs to pass. For this, we seek the help of Object#instance_variable_get and Object#instance_variable_set.

Object#instance_variable_get allows us to access the instance variables by just sending a string-name of the variable as an argument to it.

Object#instance_variable_set allows us to modify the existing value of the instance variable by sending a string-name of the variable and the value to which it has to be modified.

And there you have it. A hand-rolled implementation of attr_accessor.

Vineeth is an engineer at C42 Engineering. If you liked this post, please consider...


Hack of the Week - Vagrant & Chef-Zero

Chef cookbooks quickly get complicated as with deployment strategies change over time. You may waste weeks of your time getting things right. One way to reduce this overhead is to start with a simple one machine build using Vagrant and Chef-Zero to provision it, then move to a multi-machine build and evolve accordingly. As Captain Picard said, we don't jump directly to warp speed, we start with an impulse then engage to warp drive.

Automating DevOps can be time consuming in the short term, but it is essential that it be done properly to sustain continuous delivery on a project. Provisioning machines and making sure that provisioning is idempotent is one of the more time consuming activities involved in setting up automation.

Vagrant and Chef-Zero are two of the tools we use daily to automate the setup of deployment environments. Working with these tools reduces our time by a big factor because of their local runtime and cookbooks caching on developer machine, so no unnecessary network latency while provisioning. We spend majority of time in writing cookbook recipes, as cookbook development cycle is reduced three simple steps write a recipe, provision virtual machine and check if changes are applied to virtual machine. Initial step this simplified development cycle requires developer input in writing cookbook recipes whereas second is automated with vagrant (which requires either chef-solo or chef-zero to converge chef recipes); and third can be automated using test-kitchen (an integration tool for developing and testing infrastructure code).

Previous to chef-zero announcement we used chef-solo to provision virtual machines. Chef-Zero in addition chef-solo features includes improvements such as in-memory and fast-start Chef server intended for development purposes. Although Chef Team have no immediate plans to deprecate chef-solo, they will eventually remove it from Chef. A good reason which made us to shift from chef-solo to chef-zero. (source From Solo to Zero)

To leverage the true power of chef-zero a compatible vagrant configuration is needed. We use following Vagrant configuration as our template.

This Vagrant configuration requires a some vagrant plugins to be pre-installed.

  • vagrant-chef-zero
  • vagrant-berkshelf
  • vagrant-hostmanager

We use Berkshelf to manage our cookbook dependencies. Using Berkshelf gives us a project-like structure to our cookbook.


It's hard to conclude an infrastructure recipe, as software changes so does infrastructure. Starting with a smaller local build then evolving to complex remote build requires a lot of changes made to cookbooks. Before you converge these cookbooks to remote machine, provision a local virtual machine using Vagrant and Chef-Zero to ensure their correctness. Remember, all big things have small beginnings.

Ranjeet is an engineer at C42 Engineering. If you liked this post, please consider...


Garden City Ruby Conf - 2015

Here is our deck from the Garden City Ruby Conf 2015 Closing Keynote.


Entropy & Broken Windows

While looking from a 30,000 feet view, most of the physical systems no matter how complex they are; appear to have a great sustainability. Software is no different, while it's immune to almost all physical laws, but entropy still applies to it.

In thermodynamics, entropy is a measure of the number of specific ways in which a thermodynamic system may be arranged, commonly understood as a measure of disorder.

When this measure of disorder increases in a software system, then it's called software rot.

Out of many factors that contributes to software rot, one that seems to be crucial is project's psychology or work culture around it. A project's psychology completely defines its development pace and milestones. A project with a negative psychology or poor work culture around it results in a failure; while another project with positive psychology or good work culture, tends to survive even in the dire consequences. Yet to overcome the project's psychology issues one must select the team of developers based on how they'll cope with the project deadlines. This team of developers is need to be well disciplined and should share responsibility for their actions other than blaming each other to meet those project deadlines.

Don't Live with Broken Windows

Researchers have discovered a trigger that leads to urban decay.

Once a window in a building is broken and left unrepaired, the building starts to go downhill rapidly. A car can be left on a street for a week, but break one of its windows, and it will be gutted in hours.
— Wilson/Kelling, Atlantic Monthly

Similar things also apply to software projects, where broken windows are replaced by bugs. When one is under market pressure, then the project deadlines and estimates are calculated to maximize profit by sacrificing codebase design. Or, when software project's critical decisions taken in haste without considering its consequences leaving many broken windows. Time is also one of the constraints that directly decides the number of broken windows or bugs that can be fixed before shipping out the product.

Fixing or Avoiding Broken Windows

Since, Don't Live with Broken Windows happens to be an issue for most of the software projects which contributes bad designs, wrong decisions and poor code. Where,

  • Bad designs can be avoided by using a better methodology of software development like test driven development and behavior driven development.

  • Wrong decisions are the result of time shortage, where all the solution paths weren't discovered before the final decision was made. Just to avoid such a wrong decisions in code, developer can comment out offending code or display Not Implemented or substitute with dummy data instead.

  • Poor code can also be avoided by refactoring mercilessly when code smells.

Ranjeet is an engineer at C42 Engineering. If you liked this post, please consider...