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
The latest update to our app makes following an event much easier. Now you can follow an event directly from search result and we have also made it frictionless. Give it a try and let us know what do you think about it.
The update contains:
✔ Like events directly from search result
✔ Now you can view full event name in the description even if the name is too long
✔ Liking an event is frictionless, if you want to add a comment use the comment option instead
✔ Fixed the App Icon in retina iPad
✔ Miscellaneous bugfixes
Enjoy and make your life Majikal.
Today, I came across a very interesting slide made by Flurry which highlights the explosive growth of smartphones globally. The key highlights of the slides showing mobile outlook for 2013 using the past few years’ analytical data are:
- Smartphone is a global phenomenon (China is catching up very fats to US in number of active iOS and Android devices)
- 30+ countries doubled number of iOS and Android devices in last 12 months
- People spending minutes per day on TV and Web has remained stagnant from last 3 years but for mobile it has almost doubled in Dec 2012 from Dec 2010
- App revenues are growing at 129% cumulative annual growth rate (CAGR) [2008-2012]
- Majority of the time spent in social category of app is on social networks (47%), messaging (29%) and photo/video sharing (19%)
- 7pm to 11pm is highest usage of media and entertainment apps (behave like TV’s prime time)
- Females use more of shopping in Day time than their male counterparts
Read the full slide here:
I’m always excited by new startups inventing new ways to disrupt not just established players but routine things we don’t give a second thought. There is suddenly a new way of doing things because someone somewhere was smart enough to invent it! I was quite excited when I heard about Using Miles, a startup which allows us to track our miles and membership points in a single across the board interface. And one of the first things that I always do with a new service is try out the “Forgot my password” option. I wasn’t expecting any surprises from UsingMiles.com but to my horror they seem to have emailed me the password in plain text! I shudder to think what other private user information they might be inadvertently exposing!
As a founder and startup in its early stages, I empathize with my fellow beings over the pressures of creating something new and taking it to market. However, startup founders have this annoying little habit of cutting corners when they should have known better. And one of those often cut corners is handling user data in a safe and secure manner. It is amazing that when even a simple google search can reveal the top things to be done, startups continue to ignore basic facets of security. This is even more so deplorable when it comes from a startup that has been in TechStars and funded well! Apparently we don’t learn much from history!
I’m writing this post to layout simple steps and process flows that should be followed for managing such things as user email and password. If you’re a CTO/CEO in a startup do make sure that your team is following these as the least necessary to do what is needed. These are not by and far a comprehensive list of items related to user data security, but it should be a good start.
One of the first things to recognize is that users will invariable use weak passwords and they will also reuse their passwords across sites. This often means that if one site or database is compromised, it puts every other site where the user may have an account at risk! This brings us to the first rule “A password stored in secured manner will continue to be secure even if it is exposed in its encrypted or source form”. Thus,
“All passwords must always be stored with a randomly generated salt and hashed using a cipher scheme such as PBKDF2.”
Once you’ve done this you’ve created the first line of defense which will protect in the unlikely event of a hack. Beware of anyone who tries to convince you to use BCrypt or any other scheme! Now that you’ve followed the above, it is important to understand that encryption is not selective. If you’ve already decided that data is worth protecting it is important to be consistent in your approach to it. There is no point in securing it in one place and then flinging it around in emails! This brings us to our second law “The rate at which your security is affected by outside factors is directly proportional to the weakest link your security chain“. Thus,
“Never send passwords in plain text either via email/sms or any other mechanism of communication no matter how secure the communication channel may seem to be.”
If your developers are trying to convince you that it’s only a temporary password that they are sending to users, make sure you remember to spank them for being lax with data security!
The last and third law of security is quite simple, “A taunt force exerted on group of hackers will come around to bite you in the ass”. As those in Gawker Media learned this the hard way when they challenged 4chan that ended up compromising all of their sites! If any of your employees have a favorite pastime which involves inviting people to attack your system, you better have an army of security experts at your beck and or call; or make sure that your employees understand security is nothing to be taken lightly or joked about on public forums.
I hope this should provide you with enough knowledge to go and discuss this in detail with your development team. As for UsingMiles, I’m going to give them a pass until they can improve upon basic security.
You said and we listened, thanks for the invaluable feedback. We have incorporated some of your feedback in this release and are still working on others.
In this release (v1.0.1):
- Support for iPhone 5
- Important bugfixes
- Better user experience: now you can add personal comments while sharing, following and check-in into an event.
- Better integration with Facebook
- Performance improvements
You will also note that we have changed the app name from “Majikal” to “Majikal – explore & follow local events“.
Download the app from here and don’t forget to write a review and send us feedback.
Bawaal Labs has today officially launched its Majikal (pronounced: magical) app on the iPhone platform. Majikal is a location aware, social mobile platform that lets you discover and explore events happening around you. It aims to redefine the social experience around events.
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.