About four to five months ago, I was working in a space where the majority of work was done in web development. Specifically, I was dealing with a messaging system in Java and web system in Perl and Ruby on Rails. I had been working this space for sometime now and I felt that new challenges needed to be met with and I set my sights on the iOS space, specifically iPhone application development! After said number of months, we have updated our iPhone application and released our iPad app. I have learnt several valuable lessons during this journey that I would like to share with you guys (when I say guys, I mean the two guys who actually read this blog and the google bot).

Lesson #1: Just because you know ‘C’, does not mean you know ‘Objective-C’

They are not only different languages, they are different paradigms and require different ways of thinking. Since Objective-C is now mainly used to develop applications that people will touch and then use, you have to think more and more of interface design and user experience, as well as thinking of the underlying layer which involves C concepts like memory management and faster queues. You simply cannot be good at the latter and not be good at the former.

Lesson #2: Learn the UIView lifecycle and learn it inside out.

Understand what when things like drawRect and layoutSubviews get called. Understand what happens when you overload the two. Learn when to call setNeedsDisplay and setNeedsLayout and more importantly, learn who should be calling these!

Lesson #3: Always always have apple documentation open next to you.

The docs help a lot. Just having them open next to you is going to save you a lot of time trying to remember
the method, especially the animation ones which have long method names and multiple arguments. Not only that, most of the time (unless you are using the docs for Automation), the docs are all you need to resolve a issue.

Lesson #4: Write an app.

Whatever you learn from work or hobby or reading or podcasts or WWDC videos, put that knowledge into making your own app! That is the best way to learn. Make an app! Whatever you want, any idea will do and start putting whatever you learn into it. And start showing it to people who know more than you and ask for their feedback.

Lesson #5: Be prepared to stuff up.

If you are always scared of stuffing your work up, then you are not going to do much, or even learn much. This is not to say that you should cowboy your way through the work, but to have high expectations from yourself and to be prepared to be disappointed, but to never ever lower those expectations. There are millions of apps out there but only a few of them are watchwords. If you want yours to become one, you have to make a million mistakes before that!.

My thoughts on DevOPS on the REA Engineering Blog.


It should not be marketed as position to slot one person in, or even rotate people through. A software developer who writes the code should be as concerned about his/her code working in production as he/she is in development. Definitely operations are more experienced with deployment and maintenance of products in production like environments, but that does not mean a developer should not base his software decisions before being aware of implications of deploying it in production, or be unaware of the status of his code after it passes quality assurance. The thinking behind devops is the critical bit of software development.

The process of software development is long and hard. It goes through a lot of stages. Development is usually done on your laptop/desktop and once you are done, it is hopefully moved to a production like machine where your changes are tested. If passed, it then is passed onto production. All these different environments are configured differently and possibly access and enable different areas of the application being deployed. All this is usually managed by configurations.

The scenario mentioned here gives rise to the possibility of two different types of configurations and that is going to be my rant for today.

There is application configuration and there is environment configuration. If you have to turn features on or off in your application in production, or release something that you want a subset of your users to see for some testing purposes or for whatever reason, you want flexibility, then that setting is an application configuration.

Any change in environment, whether machines, URL’s, databases etc when you move software from one system to another in the development lifecycle requires environment configurations.

Usually, the way to go about them is to put the configuration in a YAML file. For example

ThisReallyIsSomethingIHate: 1
ThisIsSomethingMeLikey: &AliasForIt
    Name: Gandalf
    Default: #98AFC7
    Update: #FFFFFF

This works fine for environmental configurations which rarely change and which do not need to be altered every so often. But for application changes, where toggling of features on and off, before and after deployment is a common thing, we need something that works, in my opinion similar to a JMX console. An admin console, which tells us the health of the feature/application, and allows us to toggle the features on and off.

This involves moving the application configuration from a flat file into a persistent storage, perhaps a database. This ensures that Operations do not have to worry editing files but actually have a console to do it in, something that is easier to start and manage. This would also help out QA during testing, because now they do not have to write automation tests to edit configuration files but a simple selenium step will accomplish that for them.

I do not know whether this is the right way of separating application and environment configuration, but I do know that we need to separate them.