BHS: Making of Diary Mobile

I started my job with, a London-based startup, back in August 2010. Since then, I’ve worked on their webapp, which is based on Ruby-on-Rails, and spearheaded the development of Diary Mobile app in a platform agnostic way for faster releases to both the Apple AppStore and Android markets.

Diary Mobile was already a mobile app on the Apple AppStore before I joined. However, it was based on native Objective-C technology.

The old Diary Mobile:

agenda screen

events screen
todos screen

It used to look ok but there were subtle issues with this version. It simply was not robust in syncing the device data with the REST based server interface and vice versa. Moreover, the Objective-C developer was not committed with the startup on full-time basis causing major concerns for the fledgling startup.

At the time of my joining, a very cool designer also joined, and together we worked on a new HTML5, Phonegap & Sencha Touch based rewrite of the mobile app.

This rewrite took the same amount of time as the original development of the native Objective-C app. However, we focused really hard on optimizing the syncing part and also improving the overall experience for the end user.

The new Diary MobileHTML5, Phonegap & Sencha Touch

dashboard screen

events screen

notes screen

todos screen

settings screen

The results were encouraging with a lot of downloads. However, there are still rough corners that need addressing. I’ll be detailing the development in my upcoming posts.


Ruby and threading for multi-cores

With the CPU manufacturers’ focus on multi-core architecture rather than GHz boost, a lot of debate and research has started to scale existing software applications to take advantage of this development.

Let’s consider Moore’s Law for a moment. This is not really a mathematical law but just a rule of thumb that CPU manufacturers aka Intel & AMD follow. Therefore the software industry expecting that much growth in processing power X months down the road always optimize their software to match the performance of the hardware at the time when their solution will be launched. This growth pattern is followed by all game developers, DBMS vendors, corporate solution vendors like SAP, Siebel etc. and others.

Optimizing software solutions to match raw GHz processing power was easy but matching it with multiple cores, 2\4\8, seems a rather difficult task. As the software languages of today don’t support auto multi-processing. That means to say that a lot of manual coding effort is required to keep parallel processing optimized for parallel tasks. Then there is the insurmountable work of synchornizing the manual threads to avoid deadlock situations, thread starvation, keeping critical section safe and the like. This is the situation with all the modern dominant languages like Java and C#.

On the other hand, its time for another software language shift. Industry consultants predict that after every 10 years, the dominant software language gets replaced by some other language. Case in point is, Cobol, Fortran, C++ and now Java.

The most appropriate successor to Java seems to be Ruby<period>

I found one of *the* most comprehensive coverage of threading in Ruby and the latest trends/research.
But the problem I figured out is that there is no pattern of thought process developing or research heading somewhere concrete.
Although Ruby MVM is posed as the best option available but still issues with this approach are mentioned. Also any successful work on that is hard to find.

It seems threading in Ruby will remain experimental in nature and may only improve with the advent of some other language that has a solid implementation of the threading experiments done in Ruby side.