Rollout.io Tech Stack
CloudBees Feature Management.io is an iOS SDK that allows developers to fix bugs and prevent catastrophes in production. It follows a simple flow:
Static code analysis checks how your application is built
Code is dynamically written (in precompilation stage) and acts as an adapter between SDK and your application.
Once the SDK is loaded it fetches the required hot patches and alters the application runtime on demand.
As some of this blog auditors mentioned, it is not a simple flow, we will ellborate more in a "CloudBees Feature Management.io - Under The Hood" post soon... Selecting a technology stack is no simple matter, you choose how much you'll bleed over it, what language you are going to write the code in, how your build process going to look, what IDE/text editors you're about to use, which services you'll be able to use and who you are going to hire. Inspired by Trello tech stack, we wanted to share the different parts of CloudBees Feature Management.io technology. This post describes what technologies we chose and why, we also supply our 2-cents based on the experience with various technologies. This post is correct for the time of it’s writing, we're always re-evaluating design and architectural decisions. So, lets dive inside:
Debugging can be a bit hard (source map is not working well for me with requirejs). The good thing is that the transformation to coffeescript is pretty straight forward.
Need to be used wisely, don't overuse missing brackets.
I miss the ternary operator.
Backbone.js (+ Marionette.js):
Go back to your backbone.js application and replace (almost) all your ".on" function calls to".listenTo" equivalent.
Sass (+Compass +Bootstrap):
Already made @mixins for CSS3
Takes too much time to compile (LESS is presumably much better), this is terrible
Bootstrap porting is based in class extending and not @mixin, which generates huge css files and takes ages to compile
Another layer of abstraction, harder to debug.
Bottom line: CSS for developers!
var heapdump = require('heapdump')
MongoDB is a document based database, it stores JSON objects (actually BSON) that can be indexed by any fields and can contain embedded documents. I was never that into relational DB, I always found it much easier to think in terms of object relations and not in terms of tables and joins. When the hype of NoSQL started we jumped on the train and (almost) never looked back. Why almost? When you are looking to hire someone that will deal with your DB if you choose an experienced DBA you'll be able to sleep like a baby, with mongodb, experienced DBAs are nowhere to be found.
) One server is like having none, make sure your application tolerates a DB machine crash (you need at least 3 machines to sleep good).
Yet another test framework for node.js We write our code test first (TDD), we use nodeunit for unit testing and usually roll our own mocks. I am a fanatic TDD’er and it took me some time to realize that there are things not suitable for TDD, it can be too hard and not cost effective to test UI components with TDD. I recommend going over IsTddDead
(it’s not) but it should become a tool in your toolbox (my best one) instead of your religion.
We didn't choose Ruby, some Xcode project reading and manipulation is needed in our SDK side, we chose to use the wonderful Xcodeproj library
(thanks CocoaPods) that is written in Ruby.
clang (pronounced as klang) is a frontend for the LLVM compiler. It was created to replace GCC, which prevents its usage for commercial products. It is a great open tool that enables better IDE and better diagnostic tools for C, C++ and Objective-C. libclang is a library tool for C that supplies, among other, source code inspection. We are using libclang to read customers code and create the structure of your application. Anyone experienced with AST trees will recognize the syntax. Unfortunately, I wasn’t :)
When building an SDK you should test everything. We are using XCTest and we roll our own mocks for now. TDD in xcode environment is not like using jUnit, it takes too much time to run the tests on the simulator. Any advices? I haven't found a good code coverage tool around... Any thoughts? Waiting for your comments! We didn’t cover this in details but we also use services from amazon, google storage, loggly, intercom.io and some tools like npm, bower, grunt, etc.. As mentioned before, we'll talk about how all these things come together in our next post.
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.