Brit Gardner’s Site

all the code that’s fit to printf()

I love App Engine - I think it’s the best thing since sliced servers (bad joke)!  But one thing they got wrong is their “smart” quota management.  This has been something that has irked me ever since I heard a google rep talk about it at the Seattle App Engine Hack-a-Thon.

Here’s how it works according to the representative:  You have about 1 million free pageviews per month, but it’s not a simple you-have-exceeded-your-monthly-limit quota.  The app engine team has developed a way to evenly spread out your quota over the full month, so it is possible that you receive a generic “this account has exceeded its limit” page at the beginning middle or end of the cycle.  See anything wrong with that?

From what I’ve seen, most of the web properties that are looking for traffic do it in a very specific pattern that invovles two phases iterated many times.

Phase 1 - get a huge spike in traffic somehow.  Get on Digg’s homepage,  get a mention on Techcrunch, etc etc. You now have an unusually large number of visitors over a short period of time.

Phase 2 - a small percentage of those visitors will stick around and become loyal or engaged visitors.  This is the traffic you care about!

Here’s a snapshot of this site’s traffic after getting linked to by a popular internet pundit last month.  You can see the two phases very clearly.

One of the primary benefits of hosting in the cloud is that they are built to handle this type traffic profile - large random spikes!  Google’s App Engine is so promising as a platform because you can leverage their infrastructure to handle a lot of traffic.   But, very few sites have high, steady traffic - it’s mostly spikes like this.

But, with google’s “smart” quota - you have all the limitations of a single physical server!  When their quota system detects you’ve gone over your micro quota for the day, or the hour, or however they track it, then your site is officially taken down and a generic quota screen is shown.  Ouch!  Now that bump in steady traffic doesn’t quite stay as high as you’d like because many of those visitors that would stick around never get to see your content.

This very well may change when Google announces it’s pricing and other features, but for now this is a non-starter for sites that are looking to take advantage of google’s infrastructure to handle a lot of traffic.

I see a lot of coverage of the new browser out by Google - Chrome.  And rightly there should be - this is pretty exciting stuff!  Javascript running on it’s own thread per tab?  Sweet!

I’ve also seen a lot of “Should Mozilla be pissed?” or “How will this affect Microsoft?” etc.  But I haven’t seen a lot of coverage on who I think is affected most by this move: Adobe.  Why?  Because the whole concept behid Chrome is to spead up web applications, namely Google’s style of web applications which all happen to be using AJAX instead of Flash.

So, if Google has completely revamped it’s javascript engine in Chrome so that each tab operates javascript in it’s own thread, and you can run AJAX applications like google docs, gmail, etc. continuously without worrying about your browser bringing down your entire computer, we’re likely to see a renewed interest in AJAX as a platform.  Also, we’ll see a renewed effort from other browser vendors to make their javascript engines comparible.  This is all bad news for Adobe Flex/Flash.

How are you, as a web developer, going to build that next business app?  Using Adobe’s Flex/Flash platform that requires users have a plugin installed (although most do) but has all the limitations of Adobe’s Flash plugin running in the browser?  Why would you when for most business applications, AJAX can meet all your needs AND be optimized to run as well as desktop applications?

No matter what the outcome, it’ll definitely be fun to see how this plays out!

Oh, and I’m writing this blog post through Chrome - it’s so new and shiny, go get it now!

Update: Chrome doesn’t have to gain huge market share for this scenario to play out!

Chrome is open source and hence their Javascript Engine is open source! (http://chromium.org) So, Chrome doesn’t have to make a huge dent in market share to make a huge dent in how the other browsers support javascript and AJAX apps.

From limited testing over about 2-3 hours I could noticeably tell a difference in performance running Gmail, Google Docs, Google analytics, and google reader in separate tabs as opposed to doing this on firefox.

This tells me that their javascript engine technology is superior to others out there - and since it is open source, I can imagine a scenario where other browsers, especially mozilla, adopt this engine.

So, google chrome may never ever gain market share but I’m willing to bet their javascript technology will! This is what bodes poorly for Adobe in my opinion - a new browser market that isn’t dominated by Chrome per se, but is dominated by fast and multi-threaded javascript engines!

Recently, I’ve been working on a project that requires a lot of geocoding.  Google provides a free service that takes any string as an input and returns a bunch of JSON encoded data if that string matches a physical location.  Check it out here.

Unfortunately, Google’s geocoding service is limited to 15k requests per day per IP.  Sounds like a lot, but for certain applications this limit can be reached very quickly.

What’s a good solution in these cases?  Why, how about use my favorite up-and-coming database, CouchDB, to store a repository of geo-data mined from Google?  Why use CouchDB?  As previously mentioned, google natively return JSON data for geocoding requests.  Perfect.  CouchDB just happens to store documents natively in JSON!

The following is a rough and tumble library I put together called GeoCouch that you can use to easily handle geocoded data in CouchDB.  This lib has a narrow scope right now - the requirements are:

1. PHP 5+
2. CouchDB
3. A Google API Key (get one here)

Usage

Using the GeoCouch is dead simple.
Grab the file here.

All the tech blogs are aflame with news of Cuil’s launch (pronounced cool), so I thought I would give the new search engine a try.  Cuil’s brick wall immediately becomes apparent before I ever even hit the site.  Instinctively, I tabbed over to my google search bar embedded in FireFox and typed in ‘cuil.’

That’s right - I’m a url searcher (someone who knows the url for a given site but still types it into a google search bar), and by all accounts I’m not alone.  So, I’m an engaged user actively looking to try out a new search engine and I am typing that search engine’s name into google?  I don’t envy the position Cuil is in.

On a more optimistic note, I really like Cuil’s interface.  It’s refreshing and new, which seems to stimulate the brain, and their categorization of searches really helps.  I’ll definitely use it more if I think about it, but again I search instinctively and right now that means I use the google search box in firefox.

What do you get when you combine the powers of CakePHP 1.2.x and the Zend Framework?

No, not Captain Planet… something much more powerful - the ability to use the Google Data API PHP library! This is useful if you want to use Google Calendar or any of the other services supported by the data API.

Loading the Zend Framework isn’t as straightforward as App::Import(…), since Zend’s libraries assume that the Zend Framework folder is in your include path. To get around this simply:

1. Drop the Zend Framework Library folder into your vendors folder
2. Create a script in your Vendors folder called something like zend_include_path.php with the following statement:
   1.  
   2. ini_set(‘include_path’, ini_get(‘include_path’).dirname(__FILE__));
   3.  
3. In your action, just do the following, replacing Gdata.php with whatever library you wish to load (i.e. Loader.php):
   1. function myAction() {
   2.      App::import(‘Vendor’, ‘zend_include_path’);
   3.      App::import(‘Vendor’, ‘Zend_Gdata’, true, false, ‘Zend/Gdata.php’);
   4.  
   5.      …
   6. }
   7.  

Voila! You should now be able to instantiate your loaded Zend Library Class and work with it normally.

Adobe just dropped a bomb as far as I’m concerned.  They’ve announced a collaboration between Google and Yahoo to bring fully searchable SWFs.  Ted on Flex reveals the best part:

The cool part is that this also covers dynamic data loaded in from requests to a server, these are typically ignored in both AJAX and SWF applications.

This is going to open the door for a lot of the cool and useful things we’ve been wanting to do for clients at Figaro, but have had reservations about because of SEO implications, and  I’m sure many RIA houses out there feel the same.

Combine this news with a tool like swfaddress to provide deep linking into your applications and BAM! you have a killer combo.  Let’s just remember to keep our apps classy and tasteful, guys and gals.  This news isn’t cause to go hog wild with flash like the late 90s, early 2000s restaurant site debacle.

Hey neat, Shaun just told me that bravenewfiction.com is now one of Google App Engine Editor’s Picks!

Whew, well after a few nights of diving right into App Engine, I’m proud to announce a little demo I put together: brave new fiction.  The site is inspired by a contest copyblogger.com recently had where writers were forced to create a story in exactly 140 characters.  I loved the idea, and the results were amazing.

I decided to use that contest a basis for brave new fiction.  The constraints are a little different: 140 characters or less per line, 1 line a day is published.  This means your story is told in 140 characters a day - can you keep you audience interested?

The concept and implementation are a little rough around the edges, but like I said, this was just a technology demo for google app engine.  Overall, app engine was amazing to work with.  I had no prior experience with python or GAE (obviously) but the entire application took about 16 hours to create from start to finish.  All of that is attributed to both python and GAE, I can’t say enough about either.

Anyways, if you’re interested - bravenewfiction.com.  Check it out!

Like I said in this post, google app engine feels like this brand new, shiny toy that I just want to play with all day.  Over the past 4 or 5 days I’ve been spending a couple hours a night playing with it and here is my stream-of-consciousness Cliff’s Notes:

• App Engine is incredibly streamlined
• The development environment is well documented and easy to use
• Setting the dev environment up with Eclipse was a breeze thanks to this post
• I decided to hop right into django - i’ve been wanting to test it out
• Django is nice, but I still think CakePHP runs circles around it as far as frameworks go
• Python is amazing - it just feels light and agile and I just want to touch it

I’m working on a little Technology Demo for Figaro Interactive on the app engine.  After about 8 hours or so, I’d say it’s about 40% complete - not bad.  I attribute a lot of that to App Engine’s steamlined-liness (that’s a word I swear), also a lot of it to how much a pleasure python is to work with.  I’ll release more details about the technology demo when it’s closer to releasing.

Courtesy of xkcd.com:

Remember in college when you would skip class because that awesome new game just came out and your entire hall would all get it and play non-stop for 48 hours?  That is how I feel right now because the Google App Engine wait list is going to be opened! From ReadWriteWeb.