Coding Through 2015
An yearly roundup of all things tech here at Brndstr HQ.
This is the first instalment of what is hopefully to become a monthly affair of sharing some of the technical ideas, and learnings that have helped us improve as a team.
Since it is the first of its kind, and given the advent of the New Year, we’re going to touch upon all the fun nitty-gritties that have made us technically much more superior than how we had started the year.
At the start of 2015, we- at Brndstr HQ- found ourselves caught in a mesh of requirements and feature requests that would dictate how we would continue to develop software and also shaped how we would think about the bigger picture.
With our team, it’s always going to be about that bigger picture when developing software- it’s what separates us from just another band of code writing monkeys. There’s still a lot we need to learn, and a lot more room for growth, but 2015 really proved to us how much potential this team possesses!
So what did we learn? And what have we implemented?
Starting with our core web applications:
- Amazon Web Services (AWS)
We’ve finally fully migrated our services to AWS- Amazon’s cloud computing service. This means scalability- which could be a waking nightmare even for the best of web developers- is completely seamless.
AWS offers such a wide range of services, and it took us a bit of time to absorb. We were (and to some extent, still are) slightly skeptical when integrating or moving to a service provided by AWS. We do our fair share of benchmarking every time, but they have never failed to surprise us in terms of efficiency, ease of implementation, and scalability.
2. What are we looking at?
I am not authorized to share our plans on building the next Death Star, but here is a list of some of the stuff we looked into when porting to AWS:
- EC2 — Virtual hosting that is scalable to insane amounts, resulting in minimal head scratches and hair pulling. We used nginx with Phusion Passenger Application Server coupled.
- SnS — A cost effective messaging service that requires minimal configuration to let you test messaging and push notifications right off the bat.
- SQS — If one part of your app needs to talk to other parts, this is definitely the best solution out there. This service is at the very core of our operations and we literally can’t live without it. Literally!
- S3 — Of course but we just recently complemented it with Cloud Front CDN so our media download times reduced to mere 2 figured milliseconds.
- Elasticsearch — Also recently added to our stack, this is a blazing fast full text search engine. It does pose a design challenge but in the end it’s worth all that pain.
3. Service Oriented Architecture
AWS is great and all but it does require us engineers to do less configuration and more coding; which is what we exactly did. We managed to move to a Service Oriented Architecture. Our apps that used to run on Ruby on Rails now just run on Ruby and Grape which is a rack middleware. It does sound scary to remove Rails goodness from your app, but it also eliminates a lot of overheads. AngularJS is the right front-end tool to look into if you would like to dive into the world of SOA.
As for the mobile apps development…
… a lot has been learnt and done there too:
We discovered Fabric and the suite of tools it provides.
The best thing about Fabric is that it is in real time. One of the most used tools it provides is Crashlytics. With just 2 lines of code you get all your crashes on a nice looking dashboard and it also makes ad-hoc deployment a bliss. We also used Answers and put it up on our TV to see real time analytics of our apps. It just looked cool. Fabric also provides other tools like Digits, Twitter SDK which we are in the middle of implementing in our upcoming mobile apps.
2. Reactive Functional Programming Frameworks
For coding iOS and Android apps, we started using reactive functional programming frameworks. RX Java for Android and ReactiveCocoa for iOS. Reactive functionally programming does have a learning curve but this helped us immensely.
It helped us separate out our business logic from the view management by adopting the MVVM design pattern. This made writing our unit tests a joy and not just a chore.
Ask any mobile developer and one of their concern would be that their Activity or ViewController classes is insanely big. So, we recommend, Stop MVC and Start MVVM.
2015 was definitely was a big year for us, and I hope this post gives you a bit of an overview! My apple watch tells me that it’s “Time to stand!” so I better listen.
#Jasim / The iOS Dude