Update, October 2013: I wrote a book, Game Development with Three.js, that goes into much more detail on the concepts discussed in this article and much more about how to build a fuller in-browser game. Check it out if you'd like to learn more!
Over the weekend I participated in AngelHack Silicon Valley 2012. I built Nemesis, a completely browser-based (HTML5 WebGL/Canvas) first person shooter game in under 24 hours with no prior WebGL experience. Head over to Github for the code or try it out!
Like most things in this world, the question of whether cloud hosting is for you is not black and white. Since you're reading this it's pretty likely that you've already read The Cloud Is Not for You and the counterpoint at Heroku Isn't for Idiots. Though both pieces are well-written and offer useful (if pointed) insight, what everyone actually wants to know is when to use each kind of hosting.
A lot of people think about programming as some huge, difficult discipline that you sit down and learn like you would learn History or Math. I think I'll learn how to code today, one might say, and I've really been looking forward to that quantum physics class.
Here's the thing: almost no one learns how to code in a classroom, by hearing about it or by reading about it. People learn how to code by doing it, like driving a car. But most people learn how to drive a car because it gets them from Point A to Point B, not because driving is fun. Lots of people drive for fun, but hundreds of millions of people slog through traffic on their way to work every day.
I have a problem with mobile-first design.
I spend a lot of time every day sitting in front of three 1920x1080 screens. That's 6,220,800 pixels to play with, and web developers are not using them well. Take Twitter.com, for example: the Tweet column is 496 pixels wide. That's 26% of the width of just one of my screens for all of the content on the site that I'm supposed to read and engage with. When I'm sitting 3 feet away, the text is small, and it's a small target for my mouse (I've sped up the cursor so I can efficiently pan across screens).
Two weeks ago at about 2am I had the brilliant idea that now would be a great time to upgrade this website to Drupal 7. Long story short, I messed up the upgrade, and the site was down for two weeks. Whoops. Everything should be back up now, though I'm working on a new theme.
I believe that the world of tech entrepreneurship is definitely in a bubble. But more than a startup bubble, we're in a coder talent bubble. Take a minute to read 2012 is for buying startups. Companies are getting bought not because they made anything of value or with a revenue model, they're getting bought more and more because the acquirers need more engineers. Have you looked at the list of sponsors for any hackathons lately? Huge companies (Google, Yahoo!, and Facebook come to mind) have sponsored several small hackathons reasonably close to the Philly area in just the past few months. They're not doing it mainly because it's a good thing to do, they're doing it because it's a recruitment tool and they desperately need to find engineers. (But keep doing it! Hackathons are awesome!) And then there's this phenomenon:
I have the unusual distinction of being a programmer in a business school that is currently experiencing something of a startup fever. Penn also happens to have a relatively small but enthusiastic CS community in which I consider myself active. One result of these circumstances is that I am frequently approached by students1 who have ideas for a business or have started a business that requires a website, but who have no idea where to start. I've been on the other side of that table too, hiring contractors for startups I've worked on. Here's the basic outline of how I answer this common question.
How you should accomplish getting a website built depends a lot on how fundamental the technology is to your business, how complex it is to build, how much money you have to spend, and what tradeoffs you're willing to make between quality and time.
Tonight my roommate, who is British, turned to me and said,
The way I learned to think about problems in the U.K. is different than how Americans think about problems. When confronted with a task, I think first about the obstacles and how to overcome them. Americans seem to first identify the ideal solution and then consider what revisions may need to be made to make that solution realistic.
First: stop thinking about this from a technical perspective. The problem and solution are not about how we build new protocols. That's just implementation, and as fun as it is to talk about that, nobody cares about your implementation. It only matters that it works and makes people's lives a little less painful.
