Mike Rowehl: This is Mobility

The wraps are off the latest project I’ve been working on: Chomp, a social iPhone application recommendation service. I actually started consulting with them to fill in some time, but liked the app and the people so much that I couldn’t resist jumping in full time. Now that the app is out and I can talk a bit more publicly it’s time to start building up a team. Obviously, about the app itself, the reception has been great and folks seem to love it:

• Geek.com - the one I’m most proud of
• Techcrunch - obTechCrunchShoutout
• ABC News - on the TV!! Not really, they’re talking about us, but the guy is just randomly poking around on an iPhone. Poor TV, you just don’t get it do you?

The goals of the business don’t stop at an iPhone app, we have plans to move into other areas over time. But the iPhone app market is the biggest juiciest lowestest hanging piece of fruit in the mobile arena right now. It would be crazy not to take a bite. Ben can answer a lot more of those style questions than I can however. I’m just here to keep the lights on and the servers running.

We have a jobs page up, but there isn’t too much color to them yet. In particular, I need some folks to join me on backend engineering and operations tasks, so I figured I would shout out here. Right now the team is only 5 people, so it’s a chance to get in at the very start for the right folks. We haven’t yet figured out exactly how the jobs break down, but at a startup job titles don’t really mean that much anyway. Here’s a rundown of the kinds of things I’ve been doing for the last two months, to give you a feel for what we have going on:

• Picked up and finished off a spin of the server side software. Standard LAMP stack with the PHP side built on top of CodeIgniter. There was some general cleanup work like reformatting the server responses to be more consistent across all the API calls, some new features like adding in bookmarking and avatar uploads, and generally operationalizing the code with stats logging, database migrations, processes for background tasks and cleanup.
• Prepping the production deployment systems. Which in this case meant getting Puppet up and going, setting up the modules for the bits of software we were planning to use, bits of custom config for things like the database systems (we’ve tried to set them up to be sharding-friendly right off the bat), and generally setting up the parts of the system we didn’t need till we went live (like load balancing and spreading out the front end web systems, and syslog-ng to pull together all the logs to a central system)
• Setting up system and application monitoring and metrics, so that we have alerts that fire if something seems to be going wrong and pretty graphs to show us where that wrong thing might be.
• Doing a few spins of designing a custom crawler that pulls info out of iTunes so that we can make it available in our app. With the number of apps, the number of regions, the number of languages, and the general lack of any kind of off-the-shelf solution for this, it’s been a pretty complex problem to work out. Our data is pretty timely right now, but this is one area in particular where there’s a lot of room for improvement.
• Adding in some very simple strategies for caching and load shedding if we ever hit the kind of load where we were in danger of degrading performance. Fortunately we’ve yet to have to pull any of the escape valve levers (fingers crossed), but with the system growing as quickly as it’s been growing I’m sure that’s only a matter of time.

Generally, it feels great to be back at the controls of a set of servers experiencing the kind of explosive growth we saw during the early days at AdMob. But there’s definitely more to do than I can handle all by myself. And I know there are plenty of folks out there who are better at the bits and pieces of this than I am, so I would love to be able to peel some of this stuff off to the right people and start scaling the human side before scaling the machine side gets out of control. Plus, when the weather gets nicer, I spend way too much time at the track to be the only person available to respond to ops issues :-)

So if you’re interested, particularly you folks who I’ve worked on projects with before, ping me. mike at chompapps dot com. Yes, this means I’m going to start reading my email again now.

I’ve been working on a project using CodeIgniter recently, and have been trying to clean some stuff up so that long running background scripts use the same code as the live system. Sane, every framework has some way of wiring it up so you can run command line tasks using the same framework as you’re running for web requests, and CodeIgniter is no exception. For some reason stuff that used to run find as bare mysql scripts kept running out of memory when I ran it within CI. Turns out the DB wrapper actually stores all the queries it runs in a big array. Not an issue when processing web requests I’m sure, but definitely an issue when you’re running big background tasks. If you want to keep your scripts from running out of memory it’s easy enough to do:

$this->db->save_queries = false;

After upgrading to Snow Leopard we’ve had only one real issue so far, Zend Server Community Edition didn’t want to start up. Well, technically, parts of it. The apache instance was running, by mysql and the admin interface were dead. I found this post about watchdog errors, but even after putting in the fix for lighthttpd I still wasn’t getting the services starting up. Same deal for Tony. Poking around in the startup files it looked like mysql data was owned by user 103, and the mysql scripts were trying to start as user ‘zend’, however I have no zend user on my system. I wasn’t able to find anything about it, but I figured hell, let me give it a try and create a user Zend. This is the command to run from the terminal (funky huh?):

sudo dscl . -create /Users/zend UniqueID 103

Which creates a zend user.. somewhere.. I’m not familiar with that bit of OS X magic yet. It’s not in /etc/passwd, but if you ‘ls -l /usr/local/zend/mysql’ you should see the data directory owned by zend again. Now just restart and you should be peachy:

sudo /usr/local/zend/bin/zendctl.sh restart

Works for Tony and I at least, so we figured we would share. голова болит секс голова болит секс

There seems to be a lot of “take it for granted” style discussion around the possibility of Android fragmentation. Without strong top down control of the platform, folks seem to think that we’re going to end up with hundreds of versions of Android, all slightly different. This was the nightmare that mobile Java became. There were large engineering teams dedicated to and specialized in taking your write-once-run-anywhere app and actually getting it to work on the volume of handsets you wanted to hit.

It’s true that technically anyone who wants to build a slightly different version of Android can, so in that sense there CAN be fragmentation. However, the ecosystem has also fundamentally changed. Before we had the carriers tightly controlling the channel, dictating what was in and out in terms of hardware, enforcing strict standards on the software they pushed to users, and doing everything they could to keep anyone else from pushing software to users. In that world the burden of dealing with fragmentation was with the developers, and the benefit went to the carriers. The carriers controlled the channel, so fragmentation continued.

The one lesson that everyone in mobile seems to have learned over the last year was that the carriers were really bad at determining the right hardware and managing that application and content catalog. It’s why everyone is jumping on the App Store Bandwagon. One of the side-effects of that is that it breaks the strongly controlled content and application channel. If ATT decides that their Android version is going to do Bluetooth slightly different, sure, go ahead. But how can they strongarm Android developers who produce Bluetooth apps into making an ATT specific version? The control isn’t really there any more. Developers might do it, but only if ATT is offering up enough incremental sales revenue to make the port worthwhile. Right now developers frequently do it cause they’re contractually obligated to if they want ATT to promote their app.

Anyone who’s worked in open source knows that forks are technically possible, but practically uncommon. When the “market” is completely open folks tend to follow a path that serves them best. And it’s a reinforcing path. Even when someone with vested interest tries to keep a fork distinct, normally the burden ends up being more on the controller than anyone else. Forks tend to get folded back or die off pretty quickly. I think the same thing should happen with Android. Sure, people might try at the start to get a leg up by including proprietary features and customizations. But in the long run if Android as a whole works, the only person they’re hurting with a fork is themselves (to the tune of a decreased application catalog). And although it’s possible for them to create a custom application catalog with some differentiation in the short term and attempt to keep that differentiation going, there’s no difference between that and the strongly controlled channel that we currently see failing today. The cost of trying to do so will outweigh the benefit of joining the mainline. толстые проститутки

I’m planning to go on an extended motorcycle trip in May. Whenever I leave to go somewhere for more than a few hours and my friends know about it I tend to get a lot of calls. They get very concerned and call to make sure I’m not lying on the side of the road somewhere bleeding. Can’t blame them, the precedent has been set. And hey, it feels good to know that next time I actually am lying on the side of the road bleeding there should be someone looking for me pretty quick even if I don’t have a sweeper following me. However, it also means that there are a bunch of worried people out there if I don’t answer my phone for some reason, for which I feel guilty. “I should be able to solve this with technology!” says Mike the geek.

Immediate thought, Google Latitude. I can keep recording info about where I am in the background with both the Android and Symbian phones I have. That way folks can see where I’m going as I’m going, and if I don’t answer the phone they at least know I’m moving. Which should mean I’m okay, unless I’m wedged under a truck getting dragged down the road. I haven’t figured out a technical solution to detecting that, so I’m leaving that corner case off the table for now.

However, the only way I can see to get info out of Latitude is through the iGoogle widget. Not a bad way for it to work, but I want to just post my location to my blog. Seriously, I don’t give a crap about privacy. I wanna publish where I am for everyone. And I’m not going to get my mom and my sisters to sign up for Google accounts, just not gonna happen. Is there a way to do a background update of location info and publish it your own website for example? Or a system where I can suck it back out easily and map the results?

Another option is to geotag photos and publish them on Flickr. That works, but requires that I’m taking photos in order to update folks about where I am. Perhaps a cool addition, but doesn’t get to the root problem I’m trying to solve, which effectively comes down to passively instrumenting myself using my cell phone and publishing that info as realtime as possible online publicly. I’m sure I could knock together an Android app to do it pretty quickly, but I have to assume there’s something out there already.

There’s a package now for installing X11 on the G1, which builds on the Debian for G1 package. I haven’t fooled around with the stuff yet, but what am I interested in running with access to the full set of Debian software? Well that should be obvious. Metaspoit of course. Cellular interface + Wifi interface + handheld device + automated security scanning = fun!

I saw some random references to something called Sexy View, malware aimed at Nokia devices. I was just going to ignore it, but then I realized it appears to be a signed application. Delicious. If nothing else that should allow the response folks to track down where it came from I would assume. The reports out there are vague so far at best, but I’m hoping at some point something will shed some light on how this came about. I’m assuming something happened like some company got careless (or went out of business and just ignored) their signing key for applications, and some malicious party got hold of it. Very curious about this I am.

After poking around for a while trying to add a second Google Apps for domains account to my G1, I finally just reset it and registered with my mike@theotherdomain.com address to activate the phone. Very cool that works directly, I have my email and calendar directly integrated into the phone. However, I would really like to have both my personal @gmail.com account and my @theotherdomain.com account both fully supported on the phone.

I can technically add my personal email as an external email account, and share my calendar so that I can add the ical feed to the Calendar app. Too hackish though, with lots of rough edges. Especially around calendaring. Is there an option floating around somewhere that I just haven’t found yet to add a second Google account to the phone setup?

The fact the Palm has taken a radical turn, redesigned their mobile platform around access to the web and development around web technologies, and is releasing a new device based on it in the first half of this year are all really non-news items for me. What’s going to be the deciding point is what happens when us developers get to see the Mojo SDK that goes along with the WebOS platform.

The message so far coming out of Palm is on target in that regard. They need to return to the kind of innovation and energy that went along with the initial Palm Pilot devices. The big deal there was that they had a relatively simple platform that encouraged developers to experiment, and at the time they were the only real game in town for someone who wanted to pick up a device off the shelf and be able to program for it. Basing the design of the OS around web interfaces and attempting to allow developers to use the same technologies for native apps as they’ve been using on the web, I like that actually. Just a few days ago I was fooling around with hooking into native services on Android from within a browser interface, and it provides a really powerful system for getting stuff together quickly with quite a bit of flexibility.

So overall, I got to say, my curiosity is somewhat piqued. I don’t think we have enough info at all yet to make any decisions. But for the first time in oh-so-long, I’m happy about what I’m hearing.

One of the points I was harping on at and around the Symbian Partner conf were my perceived issued with the Symbian Signed effort. As a developer I get no benefit out of the initiative, but I’ve commonly felt some pained incurred by it. David Wood also just posted about the basic principles of software signing, so apparently it’s on his mind too.

I’ve already put down a bunch of my gripes about the current system. But if we want to break it down to basics, there are a few questions that I think we need to answer about a signing process. I was going to try to lay then down in some form of coherent order, but I have a rapidly evolving situation that needs some tending to. So here they are in jumbled rough form:

• Signing is trusting. In the SSL world that’s trusting that the server at the end of the connection is owned by the people who are supposed to own it. Who are we trusting in signing a Symbian app?
• There’s trusting that the app provider isn’t going to do anything nefarious.
• There’s trusting that the OS will only allow the app to do things it was signed to do (nice bit of work there, I like this part of the signing process actually)
• There’s trusting that is something goes wrong with the app you can get help.. which is unaddressed.
• Part of what the carriers/operators really want is a reduction in support calls/cost. This doesn’t help that. Actually, there’s a mistaken perception on the part of users that their carrier/operator is the person to call when an app goes wrong. I don’t call Comcast when a virus screws up my PC
• Why are these things really important in the mobile world when they’re left to sort themselves out (internet style) in the PC realm? Is it constrained devices and bandwidth really? Or is carrier/operator cost the principal driver?
• If it’s really constrained devices and bandwidth, why can’t I - the user - manage rights outside of the signing infrastructure? Why doesn’t signing set default rights and let me choose what I want to grant or remove manually after the install?
• Signing shouldn’t be the only mechanism of trust extension. Look at the Maemo installer for an example of well done application installation process. Installing a package brings in a feed of updates, repository for apt installs actually, that brings in updates. Build the trust mechanism into that, I should be able to trust the people I want to trust. It’s great that the operating system can enforce some set of restrictions for a set of applications signed by an “official source”. But if I want to trust Google directly, let me trust Google.

Damnit, gotta run. Give David some feedback if you can, I think he’s headed in a good direction with this conversation.