Hung Truong: The Blog!

Mapskrieg iPhone/iPad App Launch!

It's been about 4 years since I announced the launch of Mapskrieg, my Google Maps and craigslist mashup web app. Since then, I've gone to school (again), worked for Microsoft and quit, and made a few apps. Today, I'm happy to announce the launch of my newest app, Mapskrieg for iOS!

I've been working on this app for a few weeks, and I think it's ready for public consumption. It's basically Mapskrieg, but developed natively for the iPhone and iPad. In the past, I've taken a sort of iterative approach of releasing fairly minimal apps and improving on them. For example, I released Threadless as an iPhone only app and later added the iPad support. I wanted to release Mapskrieg on both platforms so the launch would have a little more bang. Plus I think the iPad app is the better of the two, and I really wanted that one to stand out for the release. I've been getting much more comfortable with mobile development, and I'm very happy with the rate at which I was able to conceive and release this app.

That's not to say I didn't struggle or learn anything new with it. While a lot of the concepts are borrowed from my Threadless iPad app, I had to do a lot of stuff I hadn't done before. For example, since Mapskrieg is going to rely on iAds to make money, I decided that both the iPad and iPhone versions would support iAd. Apple, in their infinite wisdom, made the split view controller a very useful and now, standard, design paradigm. Unfortunately, they don't provide any support for using it with iAd at all. What the fucking fuck, Apple!? So I had to basically recreate the Split View (well, the landscape mode at least) in order to support iAds. It'll be well worth it if I can rake in some iAd dough, though!

This post also comes almost 1 year after I quit my job at Microsoft. That milestone probably deserves its own post, but I'll just say that I have not yet regretted my decision in the very least so far. This is as fun as it gets, folks!

Google, Bing, and SERP Copying: Additional Evidence?

In the beginning of February this year there was some mild uproar about Google setting up an elaborate sting operation against Bing to prove that Bing was copying search results pages directly from Google using the Bing Toolbar. I personally thought it was a bit childish of Google to do this. All's fair in gathering user-generated data, right?

Fast forward to a few weeks ago. I put some code on Mapskrieg that would auto-detect a mobile device using the useragent string and show a mobile friendly site. I thought this was clever, but apparently Google thought it was cloaking. Oops! My bad. I took a hit on my Google search rankings. Once I fixed the issue my hits from Google have been coming back up slowly.

I looked at Google Analytics to see how the organic search referrals had changed, and I noticed something interesting. Not only had the referrals from Google gone down, the ones from Yahoo and Bing did as well. Perhaps Yahoo and Bing noticed the “cloaking” behavior, too (Yahoo is just using Bing results in their SERPs now). If so, then Bing was a bit slower than Google. See the charts below:

I started getting punished by Google around the 15th of March. Bing seems to have taken a few days to lower my rankings (and thus the # of clicks). My website's recovery from punishment shows a similar upward trend, even though the site was no longer “cloaking” for about a week before that recovery. This suggests (at least, to me) that Bing really is copying Google's search results pages. Otherwise they have a very similar method of cloaking detection, a similar policy for punishment, and a similar timeline for reducing the punishment for cloaking… At this point I feel that there are too many coincidences for this to be mere chance.

I was previously on Bing's side because I figured that the Google data was just one data point out of many that they use. This example makes it seem like Google's data is THE data point, or at least a major, major part of their “algorithm.”

Having stated all of this, my experience is only a sample size of 1, but I'm sure other webmasters have similar data sitting around. I'd be interested in seeing if there's more evidence for Google's stance. If I were Google, I'd be analyzing data from Google Analytics on other websites to see if they agree (I have a feeling they're allowed to use this data anonymously).

Full Disclosure (because why not?): I used to work for Microsoft AdCenter, but I haven't been involved with their operations for over a year now. I have a can of Bing soda water on my shelf but I mostly use Google (unless I want to use Bing ironically).

Edit: I've gotten some really great comments from Hacker News. I thought I'd paraphrase a few and write my comments on them. If you want to see the actual comments, go directly to my submission.

Comment: How could Bing get SERP info from just the toolbar?

My response: 1) My site drops from many SERP listings, Bing Toolbar stops getting click info for my site so the listings drop from Bing as well.

Comment: It might not be cloaking punishment. It could just be an outside factor, like people generally searching for the site's keywords less or a competitor coming in and being better.

My response: The traffic to Mapskrieg is pretty darn regular and this was a significant drop for both search engines. Through trial and error the only thing that changed my rankings back was fixing the user agent thing.

Comment: Google suggested that the changes to SERPs took months to propagate and this data only took about a day.

My response: Okay, that's a good point!

The response from Hacker News has been great and really made me think more about the issue. I'm not sure if Bing really is copying from Google, but I thought this was a worthwhile data point to look at. Maybe someone else has some data they'd like to share as well.

♥s Threadless for iPad Release!

About a week ago I thought about working some more on ♥s Threadless, my fan made iPhone app. I originally designed it for the small iOS devices like the iPhone and iPod touch, and figured I would do the proper iPad version later. I got the itch, so I got to work figuring out what an app on the bigger screen would look like.

I knew that I wanted a grid-y layout as opposed to the list-y one of the iPhone/iPod, which was partly the reason why I hadn't done the iPad version yet. Lists on iOS are easy because they're given to you for free. Grids are a whole other beast. Luckily, I ran into a framework (AQGridView) on GitHub that does grid layouts in a tableview-y sort of paradigm. The framework was still a little beta (or alpha) as I had to go in and change a few things that were crashing, but it did succeed in making my job a lot easier overall. I'd like to try contributing to that code to improve it, but I guess that's another post altogether.

After getting the grid stuff working, I decided to use a modal pop up view to display the images and sharing options all in one view. Since the iPad has much more screen real estate, it's easy to design things without running into space issues. You don't, however, want to just stick a billion buttons in because you can. I think this design does a good job of showing enough stuff to the user, but not too much stuff too soon.

I still have some bugs to fix, mainly with memory management due to the grid view stuff. If you have any suggestions, feel free to comment on this blog!

Hopefully the iPad app continues the mission of the iPhone app, which is to provide a really easy and fun way to browse and share awesome Threadless designs! I may have been an early iPad doubter, but I really believe that it's a great device for consuming content. Even on my iPad 1, the designs and colors just pop on the app. At least I think so. But you don't have to take my word for it!

Get the app if you don't have it already!

Note to Myself about UISplitViewController and Auto-Rotation

In order to prevent my future self from wasting like, 2 hours fucking around with UISplitViewController getting it to auto-rotate its subviews, here's a little post!

Most of the time, UISplitViewController doesn't want to rotate because you didn't set it as the root subview of the Window. This is pretty well documented on StackOverflow, etc. I thought this was why my splitviewblahblahblah wasn't rotating. It turns out that, according to Apple's documentation,

A split view controller relies on its two view controllers to determine whether interface orientation changes should be made. If one or both of the view controllers do not support the new orientation, no change is made. This is true even in portrait mode, where the first view controller is not displayed. Therefore, you must override the shouldAutorotateToInterfaceOrientation: method for both view controllers and return YES for all supported orientations.

The key here is that the view controller wasn't autorotating because the subviews did not answer “YES!!!” (exclamation points added by me) to shouldAutoRotateToInterfaceOrientation. I was fucking around with the Split View Controller in Interface Builder (and later programmatically) to no avail. Adding the stupid autorotate thing to yes in the subviews made it work (shouldn't it default to YES!?!??!).

Okay, lesson learned. Just don't forget this next time, Hung!

Porting Mapskrieg to App Engine

Lately I've been playing around a lot with Google App Engine. I think it's finally at a point where it makes sense to develop for it, and it can be fun and profitable to do so. For example, I wrote Instascriber on App Engine, and so far it has cost me a few pennies in CPU cycles (and like $2 for a domain name or something).

Playing around with memcaching and stuff with Instascriber has led me to become a little obsessed with efficiency (not that I wasn't already). I took a look at Mapskrieg and found that it was performing pretty slowly. My Google Webmaster Tools thing was saying it took on average 6-8 seconds to load! I wanted to decrease that number, and I figured I could make it work on App Engine, so I started working on it last week.

I modified the parser I use to grab craigslist listings to also send them to Mapskrieg. Then I basically rewrote all of the logic that existed in PHP and ported it over to App Engine. This took a little while but it wasn't too difficult since Mapskrieg is a pretty simple web app. I hardly changed any code in the Maps API implementation, though I'm thinking of moving to v3 (which is apparently supposed to be faster).

I just switched out the hosting from my MediaTemple PHP based host to the Google App Engine based one. So far the results look good. I think Mapskrieg is faster in terms of response time and the caching is definitely smarter than it was before (a memcache that only gets cleared when the content in it changes versus a time based cache expiration).

I'm going to watch closely to make sure nothing got borked in the transition, but so far so good. If I can keep Mapskrieg on App Engine, I might downgrade the MediaTemple server to save some money and maybe eventually move other services to App Engine as well.

One funny thing I noticed was the pricing plan for App Engine. I'm currently pruning listings from the database when they get too old or move past the limit of listings per listing type (because I'll never show them). This is actually older behavior from when I had listing info in MySQL. Back then, the size of the database would affect the performance of selecting rows. Google's datastore apparently does not get slower with respect to size. This is actually pretty awesome.

The weird thing is that adding and removing datastore objects costs quite a lot in CPU time. Additional CPU time past 6.5 hours is $.10 an hour. Storage, on the other hand, is .$01 per 2 gigabytes per day. From my usage, I am predicting that the CPU cycles that I would use to trim the datastore listings would actually cost more than just leaving them in the datastore and paying for storage. Is that insane or what? I still have to test some things out, but it kind of surprises me that storage would be that much cheaper than the CPU cycles to remove something.