In our previous post we talked about Nathan, the sole designer in our trio of iPhone monkeys. We figured that we may as well complete the picture, and release part two of this three part trilogy, this time looking at Philip Simpson.
Philip and I both work at Groundhog Software during the day, a company that develops custom applications and web sites for many different clients (be sure to check them out, they’re one of the few companies I’ve ever come across that really value quality and innovation rather than just talking about them). They are also highly supportive of our iPhone efforts, and trust us to maintain a separation between our work and personal developments, a trust I think we’ve always done the right thing by. That’s where I first came across Philip, when he started there as a Software Developer about 2 years ago. It quickly became obvious that Philip was smart, and highly motivated and also that he did a lot of development in his spare time (at the time mainly for charity). In his day job Philip mainly works with Java and large J2EE applications for our clients.
It came as no surprise then that when Ruby on Rails started gaining traction Philip fell in love with it. It was the anti-java in a lot of ways, fast, flexible, highly extendable and very light weight. While Java servers generally need at least 512MB of RAM to run, Rails runs quite happily on a tenth of that. Meaning that you could set up a ten server Rails cluster in the same space you could put one Java server. Rails is also a lot cheaper to host than Java. It was a fairly logical step then that it was the language of choice for the back end of Pocket Weather, and even more logical that Philip should be the man to do it.
The back end of Pocket Weather is what I call the ‘invisible’ side. Most of you probably don’t even know it’s there or what it does. Coded exclusively by Philip the back end polls the various FTP and HTTP sites from the BOM at various intervals during the day, and parses out all the data that Pocket Weather needs. This is no small feat, and is why we refer to Philip as our ‘Ruby Magician’ because all I see of it is a nice clean API that the iPhone App talks to. When you open Pocket Weather it contacts our server, and asks it for the weather for all the locations you have set up. This data is all sent back in one tiny chunk. This is good from a speed and data point of view on your iPhone, and also very good for the BOM, because it’s only our server talking to it, not tens of thousands of individual iPhones.
The running joke in the early days of Pocket Weather development between myself and Philip was always ‘Yes, but can it scale?’. You see Rails has an (undeserved) reputation for not being able to scale when it comes to handling large amounts of traffic. We were able to test that first hand when, in the early days of Pocket Weather, 800 new people a day were downloading our application. There were some nervous times when Philip had to keep a daily eye on things as our shared hosting groaned under the strain. Philip was always on the case though, and has been tweaking the code and architecture since day one. This has meant that Pocket Weather has experienced no downtime due to our code, though we have had some minor outages thanks to the double-edged sword that is shared hosting.
Philip is also a great friend and a very handy developer to have in our trio. I find that working solo it’s hard to get motivated and produce quality work, but when you have someone else you can draw immense motivation from each other, and you end up with a much better end product. Just like all of us, Philip is in the development for the fun, not the money, so much so that I often have to force him to accept payments and end up arguing with him because I think he needs a higher share of the profits, while he’s always pushing for a smaller one. I can think of many employers who would kill to have that problem 🙂
So what is Philip currently working on at the moment? Well he’s bringing the extended forecasts we promised for version 1.4 (so you can stop emailing us residents of Cape Byron, Wollongong, etc), as well as moving all of our code to a private server, so that we will never have to suffer the indignity of the downtime and problems you get on a shared host. He’s also working on two other projects that are very close to being released, but that we are maintaining Apple(TM) levels of secrecy about.