Aloha Google!

I always said, the only way you're going to get me off of this island is if I got a job with Google. Time for me to put my life and career where my mouth is, because...

New Job with Google!

I'm stoked to announce that starting June 1st 2010 I will start a new adventure as a Developer Advocate for Google in Mountain View, California.

It's a very bittersweet moment, as this means I will have to leave my island paradise home. Hawaii has welcomed me with open arms and has grown to be my true home with all my friends and family. I have loved every minute of living here, and I believe that I shall return one day.

However, the real hot spot for emerging web systems, technologies, and companies is the San Francisco Bay Area. Silicon Valley has the momentum, the people, and the energy that can really fuel my passion for building web systems. It's extremely hard to replicate that environment, especially on Hawaii.

I made a very tough and personal decision to explore Bay Area options, as I felt it was time to kick my career up a few notches. I wanted to aim high, and the highest I felt like I could go was working for Google.

Luckily, through Aloha on Rails and my general involvement in the web engineering community, I was able to reach out to current Google employees. I was also fortunate that a friend and ex-coworker recently started at Google. This really helped, as they were able to steer me towards the right position.

My New Title is Developer Advocate

We decided that Developer Advocate would be the best match with my skill set and experience. I didn't even know this position existed, but I'm very glad I was recommended for it. A Developer Advocate is a mix between Teacher and Developer. My main goal is to ensure that other developers are successful with Google products and APIs. This means there is a lot of teaching and instruction, which I am trilled to get into. I've always felt that I would someday focus more on teaching. Well, that someday is now!

The title Developer Advocate itself is very deliberate. I want to make clear this is not an evangelist role. This position's main responsibility is to advocate for the external developer to the product and engineering teams. That is, I am to listen intently to what developers are doing with the products and what they need from the products. I am to take their concerns back to the engineering team, and then ensure the developers that their voice is heard.

Meanwhile, I will be leading classes, teaching workshops, writing demos and tutorials, and generally reaching out to current and potential developers.

Focusing on HTML5 and Chrome

I'm tentatively slated to join the HTML5/Chrome/ChromeOS team. I will be learning an entirely new set of technologies for some very cool, emerging, and strategically important products.

As you can imagine, Google wants everyone to be successful with the Web. And the lingua franca of the Web is HTML, and soon HTML5. HTML5 enables very rich user experiences, and with rich user experiences comes more interesting products and services. And with more interesting products and services comes more changes for Google to sell ad space. So Google is definitely invested in promoting and developing a more rich, and open, World Wide Web. Here I am, thrown right into the middle, and it couldn't be more exciting!

The Interviews Were Lots of Fun

Some quick notes on the interview process, because I've been asked about this a few times.

I had two phone interviews and one on-site interview. Each phone interview was 45 minutes long, and each was conducted by a peer (and engineer and a developer advocate). The first phone call was solidly technical, with questions about SQL and algorithm analysis. There was a bit of coding on paper. The second phone interview was half technical, mostly dealing with scaling web sites, and half mock-teaching. For example, my interviewer asked me to "teach object oriented programming to newbie developers".

My on-site interview consisted of, if I recall, meeting five people each for 45 minutes. The format was the same for all: half technical and half instructional. Everyone I met there was very friendly and helpful.

I loved every second of it! I thought the interviews were more fun than work, and I could have riffed on the questions all day.

Oh, and I was treated to a delicious lunch. Google takes its food very seriously, I'm looking forward to my Google 15.

Start on June 1st, Two Months Vacation in Hawaii

I am taking a few months off to enjoy Hawaii as a tourist and not as a 8-5 work-a-holic. I'll use this time to visit the places I've never been and to bond with the islands. Plus, my parents are coming out at the end of May so I'll be able to hang with them right before I leave.

I'll actually be back on Oahu on September 11, 2010 for a Ruby on Rails class for the Pacific New Media program, part of the University of Hawaii Outreach College. Maybe now I can also teach an HTML5 class for them as well! :)

Where to Live in Bay Area?

Finally, a call for help. I'm a total Bay Area newbie. If anyone can recommend places to live that are family friendly, pedestrian friendly, near good schools and are close to the Googleplex in Mountain View, we'd really appreciate it! Any nudges in the right direction are most welcome.

Mahalo!

So. Stoked.

I cannot wait to start with Google. I believe in their mission, I think they are a great company, and I am most certainly going to have my mind blown. This is a huge step for me and my family, and we are ready for the adventure.

Aloha Google!

Ruby on Rails and App Engine Performance Sample

Statistics are always dangerous, and YMMV, but I wanted to post a set of performance tests I recently ran on a sample (and simple) Ruby on Rails application hosted on App Engine.

These numbers are after the application has warmed up, and I've tried to make this test show results under the best real life circumstances. Ruby on Rails applications do have a higher than normal start-up time on App Engine, an issue acknowledged and currently worked on. After they are warmed up, however, users shouldn't experience a difference.

The test was driven from the ab command, a simple benchmarking tool that comes with any Apache HTTPD software install. I ran the test from a Rackspace Cloud virtual machine.

The Rails code for this test can be found on Github.

Specifically, the controller and action being run in the test:

class ContactsController < ApplicationController

  def index
    @contacts = Contact.all
  end

end

Note: the database is empty for this test.

Network latency between Rackspace Cloud and Google App Engine:

sladd@slice84717:~$ ping ruby-on-rails-demo.appspot.com
PING appspot.l.google.com (74.125.65.141) 56(84) bytes of data.
64 bytes from gx-in-f141.1e100.net (74.125.65.141): icmp_seq=1 ttl=247 time=24.0 ms
64 bytes from gx-in-f141.1e100.net (74.125.65.141): icmp_seq=2 ttl=247 time=20.0 ms
64 bytes from gx-in-f141.1e100.net (74.125.65.141): icmp_seq=3 ttl=247 time=20.0 ms
64 bytes from gx-in-f141.1e100.net (74.125.65.141): icmp_seq=4 ttl=247 time=20.0 ms
64 bytes from gx-in-f141.1e100.net (74.125.65.141): icmp_seq=5 ttl=247 time=20.0 ms
64 bytes from gx-in-f141.1e100.net (74.125.65.141): icmp_seq=6 ttl=247 time=20.0 ms

Finally, after thousands of requests to warm up the application, below are the results. Specifically, I ran 1000 requests with 10 concurrent requests. You can see that the mean request time is 187ms. Remember, this is to connect over the internet, hit App Engine, hit Rails, hit a controller action, reach into the database, return an empty result set, and render a HTML page.

sladd@slice84717:~$ ab -c 10 -n 1000 http://ruby-on-rails-demo.appspot.com/contacts
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking ruby-on-rails-demo.appspot.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Google
Server Hostname:        ruby-on-rails-demo.appspot.com
Server Port:            80

Document Path:          /contacts
Document Length:        53 bytes

Concurrency Level:      10
Time taken for tests:   18.737 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      304056 bytes
HTML transferred:       53000 bytes
Requests per second:    53.37 [#/sec] (mean)
Time per request:       187.371 [ms] (mean)
Time per request:       18.737 [ms] (mean, across all concurrent requests)
Transfer rate:          15.85 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       20   23   1.6     24      24
Processing:    92  158  91.8    132     992
Waiting:       92  158  91.8    132     992
Total:        116  181  91.9    156    1016

Percentage of the requests served within a certain time (ms)
  50%    156
  66%    164
  75%    176
  80%    184
  90%    224
  95%    332
  98%    564
  99%    592
 100%   1016 (longest request)

If interested in learning more about App Engine, Programming Google App Engine: Build and Run Scalable Web Apps on Google's Infrastructure (Animal Guide) is the newest book that I can find.

Owly is the Cutest Comic Book Perfect for Kids

I have a three year old son, and like any father I think he's the bee's knees.  One of our traditions is to read three stories at bed time.  Naturally, as a big comic book and graphic novel fan myself, I am always on the lookout for graphic novels I can bring to story time.


I can say that without a doubt, I found the best comic book or graphic novel for kids of any age.  My son and I absolutely love the Owly graphic novel series of stories, and if you have a kid, know of any kid, or were ever a kid yourself, then you should fly to your nearest comic book shop and pick up a few of these books.

Owly is an adorable little Owl who lives in the forrest and loves working in his garden.  He lives up in his tree house with his best friend Wormy.  The stories center around simple morals with touching illustratives and characters.

Perhaps the best part of the Owly stories is the complete lack of words.  The entire story is told through illustrations and simple symbols like exclamation points or question marks.  This means that the stories can be enjoyed by any age!

I found that I love to narrate the illustrations, making up the dialog to match the pictures.  I can pace the story myself to match the mood of my son, or relate the plot to recent events in his life.

It's easy to over analyze these stories, as they are as rich as they are accessible.  At their core, the Owly series is about simple life lessons learned by adorable, friendly, and kind characters.

Follow Owly, Wormy, and all their friends as they learn to fly (not being embarrassed and perseverance), be brave (overcoming fears), or through a collection of short stories.

The Owly books are in the rare category of stories I don't mind reading over and over at story time.

Google App Engine is the Best Web Application Platform

It's a great time to be a web engineer. It's never been easier or quicker to go from idea to execution. Gone are the days when you had to provision hardware, configure operating systems, setup firewalls, or debug system components. Today it's as simple as pushing your latest code to source control or running a single command line script. I'm a software developer first, and a systems engineer second, so anything that can abstract the systems part is OK with me.

Shopping around for a cloud based web application platform can be a bit challenging, as the field itself is so new and it's sometimes difficult to compare offers as apples to apples. A vibrant and young ecosystem needs this sort of wild and varied experiments, and I hope to see more players enter the field of Web Application Platform as a Service.

I've searched for a long time, comparing offers and services, and it's my opinion that Google App Engine is the best web application platform on the market today. I make these claims as an experienced Web Application Engineer, having developed and deployment many different web applications over 14 years.

There are many solid choices for Web Application Platforms, and certainly shop around before you choose.  There are many factors to consider, and I'll list what I think are the most important aspects to consider below.

Abstraction

App Engine does a fantastic job of abstracting the system components, ensuring the developer is well shielded from the particulars of the platform.  Frankly, I don't care what particular version of memcached is running on the platform, as long as it conforms to the specification and the implementation is well documented.  App Engine encourages developers to not think about or be worried about platform implementation specifics.  Ideally, the Platform should be a utility.

Feature Complete

App Engine provides a wide array of services, supporting most use cases for web applications.  Included in App Engine are Request/Response handling, image manipulation, URL fetching, mail services, caching, cron jobs, task queues, blog storage, and a scalable data store.  It's clear that App Engine is more than a simple web server or CGI runner, but instead is a full featured web platform.

Language Agnostic

App Engine supports Python and the JVM.  Notice how I didn't say it supports Java (which it does), but instead supports the JVM and it implies.  App Engine will happily run JRuby, Scala, Clojure, or numerous other JVM based languages.  Yes, App Engine runs Rails.

Free for Most Applications

All of App Engine's services are free to use, and Google provides a generous quota for each component. It's quite possible that your application will never incur a charge.  App Engine's freemium model enables anyone to build, deploy, and host a full featured web application for free.  I'm unaware of another web application platform that offers all of its components for free.  This means there are no barriers to building a real world web application on App Engine, complete with cron jobs, queues, and email support.

Truly Scalable, Pay-as-you-go Data Store

This is quite possibly the biggest deciding factor for me when choosing a web application platform.  A lot of service providers have solved scaling your request/responses or offer a caching layer.  However, no other web application platform service that I am aware of offers a truly pay-as-you-go scalable data strore.  App Engine's Datastore means that I can write my application and know that response time for my requests scales with the size of the data query response size, and not the size of the data store.  This is very important when building web applications!  Scaling the data service is always a pain point for any successful web application, and using App Engine means I never have to worry about it at all.

Simple Deploys

Deploying my application onto App Engine couldn't be easier.  A simple command line script is all it takes to bundle up the application and post it up to the service.  Many other web application platforms have one button deploys, and I'm happy that deployment is a solved problem!

Things to Look Out For

Note that App Engine is currently in Preview mode, which means that Google hasn't finished adding all of the functionality they envision for a 1.0 release or that some APIs are still receiving feedback from the user community.  There are commercial applications running on App Engine, and Google appears to be investing heavily in App Engine.

It's also important to note that App Engine's Datastore requires you to relearn how to store and retrieve data for a scalable web application.  This is a Very Good Thing, as it forces the developer to acknowledge that data access patterns are different for scalable web apps.  However, it may take a bit to let go of the potential relational database baggage (which I think is a good thing, anyway :)

Summary

I could go on and on, but you should be the final judge.  I encourage you to download the App Engine SDK, sign up for an account, and give it a shot.  The App Engine documentation is quite good, too.

If you are a web application engineer, looking to for a free, easy to use, and simply to scale platform, I can highly recommend Google App Engine!

Migrate from Wordpress to Blogger

I've just finished moving my blog from Wordpress to Blogger.  The domain name has even changed to http://blog.sethladd.com to reflect my continued efforts to link my digital assets to my Name as Brand.

While Wordpress is an excellent blogging platform, their free offerings at Wordpress.com left me wanting more.  You are unable to run any Javascript widgets or code at wordpress.com.  This means you can't run Google Analytics or Google AdSense.  Wordpress.com also requires you to pay to configure a custom domain name for you blog.  Granted, it's only $10 a year, but if I can get everything I want or need for free, then I'll go that route.

The Blogger platform is a natural fit.  They offer free hosting, free domain name configuration, and let you control the HTML templates and insert Javascript.  They have lots of widgets ready to go, as well.  Blogger makes it easy to monetize your blog, too.  I was sold, it's off to Blogger!

Converting a Wordpress blog to a Blogger blog isn't actually that hard.  Wordpress lets you export, and Blogger lets you import.  The issue, however, is that the two platforms use different file formats.  As luck would have it, someone wrote a Google App Engine application to convert from Wordpress to Blogger.  I tried it, and it worked great for me!

The main issue, though, is that Wordpress and Blogger use different permalink (aka slug) schemes.  That is, the format for generating the permalink URI is different.  This makes a clean transition very difficult.

Being the good web citizen that I am, I wanted to try to keep all of my old links working.  I have some nice PageRank scores for a few of my posts, and I'd hate to simply destroy that content.  Therefore, I wanted to configure the appropriate HTTP Redirects to help users and search engines make the transition.

My first step was to configure Apache, my web server, to redirect users from the old blog to the new blog.  I changed the CNAME for my old blog domain name to point to an Apache I control (instead of wordpress.com).

The following is the Apache Virtual Host file used to redirect:



(btw, if you are reading this in a feed reader, I'm sorry you can't see the above embedded javascript snippet)

You can see that I am listening at the address which used to host my blog, and redirecting over to the new blog address. I make use of the awesome Apache mod_rewrite to handle the redirects. I also let user agents know if a resource is Gone, when I know there is no equivalent between Wordpress and Blogger.

You'll also notice the ErrorDocument line. This is the catch all handler, performing the bulk of the work. If the Virtual Host encounters a URI it doesn't know what to do with, it will ask the redirect-to-blogger.php script.



The above PHP code isn't the best in the world, but it attempts to convert Wordpress permalinks into Blogger permalinks. My tests show that for my modest collection of posts, it covers most of the cases.

I'm redirecting with an HTTP response of 301, which means the resource has permanently moved to a new location. This will hopefully tell user agents that they should no longer check the old link.

While Wordpress has more polish, the Blogger platform is very configurable and lends itself to easy monetization. I hope the work put into the redirects pays off, and search engines and people can continue to find both new and old posts.

See you on Blogger!

Calculating the nth Term of a Cartesian Product

I recently had to calculate the nth term for a Cartesian Product. I wanted to avoid generating the entire Cartesian Product in order to jump to the nth term. I wanted a way to derive the nth term.

For example, let's say I have two arrays:

a = [
  [1,2,3],
  [4,5]
]

The Cartesian Product of the above two arrays can be:

[[1, 4], [1, 5], [2, 4], [2, 5], [3, 4], [3, 5]]

Now, when I ask for the 3rd term of the above cartesian product, I want to receive [3,4]. Again, I want to do this without calculating the entire set.

My solution is below:

def combo(arrays, num)
  arrays.map do |a|
    v = a[num % a.length]
    num /= a.length
    v
  end
end

Example:

term = combo(a, 2)
puts term.inspect
# [2,4]

The next trick is to turn [2,4] back into 2.

Suggestions for how to improve this?