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.
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.
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!.
Not that I needed further proof of the sheer awesomeness that is the X Files but when I saw the episode Kill Switch recently, I realised that they had thought of the Matrix long before the Wachowski brothers. Take that!
Ah! My precious X Files. I never knew beauty till I knew thee!
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
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.
. This has made me realise that software development, and deployment, is amazingly rewarding when done with awesome people. 