Flurry: Analytics for your iPhone app

In this post, I will share my experience with one of the easy-to-use analytics library Flurry for your iPhone app. They claim in the documentation that the integration can be done in 5 min and I found it to be true to the certain extent. Flurry Analytics provides an incredible amount of actionable intelligence into how and where people are using your app. You can quickly identify your most engaged and valuable users by grouping them on key characteristics such as demographics, location, language preference, and usage of select features in your app. The Flurry iOS Analytics Agent allows you to track the usage and behavior of your iOS application on users’ phones for viewing in the Flurry Analytics system. Continue reading

Being Non-Relational

When I saw the first version of Majikal, it looked like the biggest challenge of my professional life. It was little better than ancient mainframe model to start with. The only good part was data interchange format (JSON) that made me believe I was looking at 2011 codebase.
MySQL database or any relational database for that matter is a good choice to build enterprise products where the requirement is not so dynamic as it is in the modern days. Whenever there is change in domain model, you need to make a lot of code change to support the backward compatibility. The ORMs present in the market are not really masking the complexity. As you know Database has strong influence on domain model, many domain objects make more complex mapping joins in RDMS and that will make the queries even harder to write. I also had to write lot of boilerplate code to map the JSON APIs to the normalized domain model. What if JSON was our primary model?
I started looking for document based databases. CouchDB was simple keystore, it gives great flexibility on schema design front but leaves a lot on developer to implement the domain model. Cassandra, on the other hand offers huge scalability but schema design was way too difficult. I found mongoDB quite upto the requirements as it was simple to use and can execute similar queries to RDBMs. On one hand it can store JSON natively.

One of the challenges that comes with moving to MongoDB is figuring how to best model your data. While most developers have internalized the rules of thumb for designing schemas for RDBMSs, these rules don’t always apply to MongoDB. The simple fact that documents can represent rich, schema-free data structures means that we have a lot of viable alternatives to the standard, normalized, relational model. Not only that, MongoDB has several unique features, such as atomic updates and indexed array keys, that greatly influence the kinds of schemas that make sense.