Mujtaba Hussain

I am, I want to be an engineer. I am not to be classified into cubicles called developer or operations. I don’t want to be a contractor or a consultant. I will not chuck my work over the wall to someone else to test and then move on! I will not inform someone with access to production systems of my migration at the end of an iteration. I will invite them to barbeques! I, Engineer!

I will keep my work transparent. I will talk to my tech leads and seniors and learn. I will say ‘I don’t know!’ when I don’t know. I will argue vociferously when I know I am right. I will listen to other people when they argue vociferously. I will compromise when I am not the only one who is right. I, Engineer!

I do not care what language I have to code in. I do not care what framework I have to use. I will do my best to deliver the best product that can be delivered. I will not rigidly adhere to a methodology for the sake of adhering to a methodology. I will not force a process on my team. I will encourage my team to try adapt processes to the ones that seem natural. I, Engineer!

I will automate my workload as much as I can. I will automate test suites and deployment and provisioning. I will not automate thinking. I will not outsource thinking. I will not contract out thinking. I, Engineer!

I will have a work life balance. I will go home and spend time with my family, a lot of time. I will not spend 20 hours a day at work. I will make sure that no one has to spend 20 hours a day at work.

I, Engineer

Some days ago Matt and I had to deploy a rails application. This was an application that both Matt and I had no idea existed about 2 days before we ended up deploying it so we were quite looking forward to it on a very rainy wednesday! (Why does it always rain when I am deploying???)

A day before Matt had tried to deploy the application to staging to see whether we could test it out before production got her hands on it, but the staging environment had not been puppetised for this particular app. When we realised that deployment to staging might not possible, we spoke to our resident friendly release manager Aaron and laid out several plans. The first action was for me to test the shi^H^H^H hell out of the app locally (with production data) as much as I could while Matt tried his best to puppetise staging.

Early wednesday morning, I managed to test the app completely and ensured that the changes some awesome developer *cough* had made worked. Matt had also finished his spike with staging but no goodness. So we both looked at each other and decided to deploy it, to production herself.
Four hours, a plate of sushi and a coffee later, the thing had been deployed and we had ensured that it worked in production and informed the relevant parties!

From this all, I have learnt a few things:

1. Even though we both knew nothing about the app, I ensured that Matt was involved in it from the very beginning, and it helped a great deal. Springing deployment surprises on OPS is not cool and helps no one, least of all you as a developer. JIRA and Zendesk are cool, but nothing, nothing will actually substitute going over and talking to your fellow OPS people.

2. Puppet. Puppet is cool. The fact that we could quickly spike things in staging and decide whether to deploy there or not was simply because puppet allowed us that level of automation. Invest of in such tools, whether they be puppet, chef or babushka

3. We did not panic and delay the release when we found out that we could not test it in staging. We sat with Aaron and figured out the risks of each scenario and associated rollbacks. We did as much testing as we could do before hand and then went ahead with the deployment. To quote my colleague Jon Eaves, “Fear is the mind Killer”.

Above all, it was great fun to work with Matt, and deploy something along the way . This has made me realise that software development, and deployment, is amazingly rewarding when done with awesome people.

sizeToFit ends up calling setFrame! So make sure you do not call them both in layoutSubviews. Its one or the other.

The creator of C and Unix Dennis Ritchie passed away recently.

The world is a tad less rich now!

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!.

In my daily perusal of Schneier’s website, my eye caught this; Most Common iPhone Passwords.

Nice article!

Ladies and Gentlemen, Blamer lives.

Please use it and let me know me know what you think. Suggestions and criticisms welcome

After almost a week, I have my registration. Very soon, Blamer should be available for download