How It Will Happen

Yesterday while grabbing coffee, Paul McKellar, entrepreneur in residence at SVAngel, presented a great idea when I brought up the concept of Twitter bootstrap themes: serving up CSS files on a per-request basis. It’s a model that Typekit has been using for a while now: charge people based on the number of pageviews they get to their site. It’s a significant contrast to WordPress Themes which have historically been priced on a per theme basis.

Clearly WordPress themes have a much greater audience: millions of people use wordpress to power their blogging activity. However there are countless startups that are using Twitter Bootstrap as a quick way to get up and running without having to wait on a design team. Take Swole.me as an example. I found them through Twitter last night and immediately recognized the design. If you want to know other sites that leverage Twitter Bootstrap, you can check out this blog which is dedicated to covering all the sites built with the framework.

By charging on a pageview basis, theme creators could quickly start generating revenue without much risk to the developers who simply want to get ideas out there. Obviously there’s always the opportunity to charge a flat-fee, but this market is not yet as large as wordpress. I wouldn’t be surprised if it became just as large though: developers and hobbyists are the ones responsible for the success of WordPress.

The market is definitely similar: people who want to quickly get a nice-looking site up and running without a lot of configuration. Granted, Bootstrap doesn’t exactly have a powerful back-end to power their system but that’s also the beauty of the product. With the rapid adoption of Twitter Bootstrap, I’m willing to make a significant wager that we’ll see a emergence of a cottage industry built around Twitter Bootstrap themes.

If you’re a new mobile startup, your primary desire will be to deliver a service that works on both Apple devices and Android devices. Unfortunately, this is unrealistic from a cost perspective. The first version you release probably won’t be successful and the last thing you want to be doing is iterating on multiple platforms simultaneously. Yet just about every person you meet will more than likely have a phone powered by the opposite platform than the one you built for. That’s just the way it goes.

With a larger audience than iOS, there’s no doubt that building for Android is insanely compelling. While developers may not enjoy building on Android (and may even be insulted by Schmidt’s statements on the matter), the business potential is too great to ignore. Developers are still ignoring it though. Why? Programming for Apple is awesome.

My own experience with building on iPhone was great. In general you can pretty much build an app and it will run across multiple versions of iOS with few modifications. Additionally, the documentation provided by Apple is incredibly thorough. Given that all great programmers are lazy by nature, Apple’s general consistency across platforms makes programming a joy. With Android, you are going to have to make exceptions for the numerous types of phones out in the market (the fragmentation problem).

Developers can complain all they want though. If you’re a funded startup building a consumer application, you are going to have to build an Android app at some point. Yes, Instagram has built an iPhone-only community. There are also plenty of others that are exclusive to iOS. Bootstrapped companies will always be forced to go one route and for now, iPhone still provides a compelling route. But if you are working for a well-funded company, there’s pretty much no option: Android is a requirement.

Hopefully Google gets their act together and can make a platform which provides a more pleasant experience for developers. Otherwise there will continue to be a love-hate relationship between developers and Android.

Unfortunately for most developers, your application will never get to the size where picking one database over the other will even matter. At Holler.com I went with MongoDB because a couple friends recommended it and it was relatively easy to code for. I also like their approach to structuring data as opposed to the standard MySQL way that I’ve been using for 10 years. Will it have problems at some point? I hope so! I also hope that we have a team in place who can react to and appropriately resolve the problems (also hopefully prevent problems before they occur).

If you decide to select a data store that is not yet proven, there’s a good chance you are going to face some serious hurdles as your system expands. The biggest problem that you’ll face is the lack of documentation surrounding the problem as not as many people have overcome the hurdles of scaling with some of the newer NoSQL solutions. Five years ago developers started going over how to effectively scale MySQL and now it has become common sense: how to shard, use master/slave setups, etc. There are even books on the topic.

The problem for many developers and pretty much all companies, is that there is typically a lack of resources to tackle a problem. When the developer ignores the warning signs that things will eventually fail because the business wants to keep adding features (as it sounds was the case with the anonymous MongoDB hater this weekend), it’s pretty much guaranteed that problems will ensue. The data gets corrupted, servers go down, all hell breaks loose It’s really the job of intelligent engineers to figure out how to solve these problems and more importantly how to avoid as many of them as possible.

The most intelligently designed systems fail at some point, the key however is figuring out how to avoid having failures bring entire systems down. Fortunately most people programming MongoDB are not developing commercial aircraft, and having a DB get corrupted is not really the end of the world (or somebody’s life). There’s a blog post by Netflix that has been re-shared numerous times over the years because of their strategy of killing systems at random and it illustrates a great engineering solution to less reliable systems:

We’ve sometimes referred to the Netflix software architecture in AWS as our Rambo Architecture. Each system has to be able to succeed, no matter what, even all on its own. We’re designing each distributed system to expect and tolerate failure from other systems on which it depends.

If our recommendations system is down, we degrade the quality of our responses to our customers, but we still respond. We’ll show popular titles instead of personalized picks. If our search system is intolerably slow, streaming should still work perfectly fine.

One of the first systems our engineers built in AWS is called the Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most – in the event of an unexpected outage.

Yes, systems break, but in theory, the whole system won’t go down. However their engineers have tested the systems and have figured out how to generate reliability on an unreliable platform. At the end of the day it’s not about the database you chose alone, but instead effectively building a reliable system based on the technologies you happened to choose to accomplish the job.

In my personal experience, MongoDB has been great and using a service like MongoHQ has meant that I can focus less on operations and spent my time building our app. While our system isn’t 100% fault tolerant since I’m the only person programming right now, offloading much of the operations to outside services has made my life a whole lot easier. When the time comes to solve the problems of scaling, I will be ready to tackle the problem along with any other engineers who are on our team at that time!

As for which database you select for your own startup, my own theory is that picking one with a sizable community is always the way to go. That way you have people available who have probably faced the same challenges you have whenever you face them. MongoDB happens to have a very active community which is why adoption continues to grow. MySQL and other SQL solutions also continue to have large communities as well.

No matter what you build though, you’re definitely going to run into problems just like those who have been complaining about MongoDB. With newer technologies you’ll probably face more problems but it doesn’t mean they’re bad solutions. It’s your job to work around them and help make your entire system more reliable!!

My current project, Holler.com, has been built entirely by me with the help of a front-end web developer (Johannes Ma) who cutup the creative director’s (Dann Petty) PSD files. The project has a back-end in PHP, a Mongo database currently hosted with MongoHQ, an iPhone app, Git for source control, Capistrano for automated deployment, Pubnub for real-time messaging, UrbanAirship for push notifications, and IndexTank for search indexing.

I decided to offload most of everything to third-parties because I don’t want to be responsible for managing multiple moving parts once the app is live. That’s a business decision, not a computer science decision. It will be interesting to see how that decision plays out. While I’ll go into more detail about Holler in a future post, I figured I’d walk any developer readers through a quick overview of how I set up my laptop.

• Install dropbox – Aside from local development projects that I simply sync through github, dropbox stores all of my files. I need to have this installed to get up and running. The only downside is that it can take upwards of 24 hours for my files to get downloaded when first installed. You could probably run a local backup if you wanted to accelerate this step, but then why would I have dropbox in the first place?
• Install Solarized theme – I like pretty colors. That’s why I use the Solarized theme in the Mac terminal and in textmate.
• Enable Super User – Apparently Apple turns off the ability to run the sudo/su command in the terminal by default. As such you have to manually turn it on. Here’s a relatively recent how to article in the Apple knowledge base. If you are running Lion, the command sequence is slightly different but you can just look it up in the help area after opening “System Preferences” and clicking on “Users & Groups”.
• Set up apache – While it sounds like Pow, the app originally linked to in the 37Signals post, is useful for ruby developers, I’m still using PHP (I know, old school!). Maybe one day I’ll make the jump, but in the meantime, I’m using good-ole apache for running my apps. This process entails editing your local hosts file, turning on virtual host support, uncommenting the php module and virtual host support in httpd.conf, setting AllowOverride to All (to support .htaccess files), and restarting apache. Pretty quick if you know your way around apache.
• Install and configure git
• Get Textmate – I use vi for all my terminal-based editing, however I prefer doing most of my web development in Textmate. After using XCode’s comprehensive IDE, I have to say that most text editors are feeling pretty pretty weak now.
• Install Photoshop and XCode – I use photoshop for all photo editing and XCode for all my iPhone development stuff.
• Install macports – I actually don’t use macports for much but it helps the mongodb install process a lot easier. I like having a local db set up when doing my development. If I was using MySQL I’d install that as well.
• Install mongodb – Now that macports is installed I install all the required packages before installing mongodb with sudo port install mongodb.
• Install pear – I have a few pear modules installed, including the mongodb driver for PHP so I install that. Also, remember that you need to add mongo to the php.ini file by adding the line extension=mongo.so.
• Install mbstring – I’m personally a big fan of the mbstring module for all my foreign character related stuff. While I’m sure there’s a more efficient way of handling unicode stuff, mbstring has worked brilliantly for all my past projects.

Once I’m done with those steps, I have pretty much got my entire development environment up and running! Now all that’s left is imagination and persistence to building the next great thing (as long as you want it to be powered by PHP ) Have any tips on setting things up or tool that make your life easier? Feel free to post those in the comments!