Sunday 31 July 2011

Mapping DNS domain to Google App Engine application

I have been working on a small application for promoting and selling books on popular science. I made a prototype and bought a domain name so I can setup all trackers and Amazon Affiliate accounts. I deployed the prototype as a Google App Engine application. Using GAE you can have a site up in 3 minutes.

When you deploy your GAE app, it will automatically get DNS mapped as yourappid.appspot.com. So in my case the app resides as http://popularsciencemedia.appspot.com in the Google cloud. From the Swedish DNS supplier Loopia I had bought the domain popularsciencemedia.com and now simply wanted to DNS remap popularsciencemedia.appspot.com to my own http://www.popularsciencemedia.com.

This is not as easy as you might think! The obvious solution would be to create a DNS CNAME entry with an alias to reroute traffic to www.popularsciencemedia.com to http://popularsciencemedia.appspot.com but but Google won't allow that. So I thought I'd write a few lines on how you do it to avoid you from the same misery. The purpose here is to map www.popularsciencemedia.com since Google App Engine only can be mapped to sub domains. www is good enough for me.

  • You need to sign up for Google Apps for you application. Go to https://www.google.com/a/cpanel/domain/new and enter your registrered domain name and fill in the forms. You will in this process create a system user for this Google App. In my case I created the user admin@popularsciencemedia.com. Google Apps let's you create emails, calenders and much more for your app.
  • This process will need you to verify that you own the domain. There are several ways to do this, I thought the easiest way was to add a Google verification code in the DNS registry as a TXT entry. The DNS record now looks like this. If you can't create TXT records with your DNS provider Google has other mechanisms for verifying that you own the domain.
$ORIGIN popularsciencemedia.com.
$TTL 300
@ SOA ns1.loopia.se. registry.loopia.se. (
    1312117911
    3H ; Refresh after three hours
    1H ; Retry after one hour
    1W ; Expire after one week
    1D ) ; Minimum one day TTL

@    IN 3600 NS ns1.loopia.se.
@    IN 3600 NS ns2.loopia.se.

@    IN 3600 A 194.9.94.85
@    IN 3600 A 194.9.94.86
@    IN 3600 TXT google-site-verification=Uy4magKHIasdeEOasdgs6b7qYt8tR8

*    IN 3600 CNAME ghs.google.com.

www    IN 3600 CNAME ghs.google.com.
  • Notice the additions. The TXT entry maps against the value you get from the Google App sign up. This makes it possible for Google Apps to verify that you own the domain you claim to own. Then, add also a CNAME mapping to ghs.google.com for the subdomain www since this is the sub domain we want to use.
  • Now to to your Google App account, go to something like https://www.google.com/a/cpanel/popularsciencemedia.com. Under Sites-> Services -> YourAppId (App Engine) there should be a possibility to add a new address under the domain you have registrered. 
  • I add www so my app is mapped as www.popularsciencemedia.com.
  • After a waiting a very short while all DNS changes seems to be working and I can surf to http://www.popularsciencemedia.com/

Friday 15 July 2011

Profiling an Android application tutorial

I'm spending some spare time on an Android Reversi game which could need some performance tuning. After figuring out how the tooling works for Android profiling it works like a charm.

There are two ways to profile an application, using the debugging server DDMS or manually decide which parts of the code base are interesting for inspection. DDMS could be useful if you are inspecting code you might not be able to recompile. DDMS can also be used to inspect memory usage and more.

The easiest approach however is to use the debug interface provided by the Android API in your sources to specify when to start generating profiling information and when to end.


public int[] alphabeta(Board b, int maxDepth, long maxTime) {
      
      Debug.startMethodTracing("othello_profiling");

      // Here goes code to profile
  
      Debug.stopMethodTracing();
      return result;
   }

Run your program and you'll see in the VM logs when the profiler kicks in. (As usual the performance of your app in the emulator will sink to the bottom when profiling is enabled)



Now you got your profiling info written to the SD card of your Android emulator device. If you run into permission issues when writing to the SD card, add something like this to your Android Manifest.

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />     

To fetch the file to your development computer use the adb tool that comes with the Android SDK. On my Windows machine I did something like this.


C:\Program Files (x86)\Android\android-sdk\platform-tools>adb pull /sdcard/othello_profiling.trace c:\temp\othello_profiling.trace
126 KB/s (2266911 bytes in 17.491s)


The tool traceview can interprete the file.

C:\Program Files (x86)\Android\android-sdk\tools>traceview.bat c:\Temp\othello_profiling.trace


Voila! You get a profiling view similar to what you get from common profilers like JProfiler, hprof etcetera. Here you can see each methods execution time and which parents and children methods it has connection to and much more.


Theres more you can do with the trace file. Traceview can also show you each threads exectution and calls in chronological order. You can simple zoom in on the interesting parts.



You may also want to try the tool dmtracdedump to create graphs over your call stack. See the Android documentation for more information.