Google "Hello, World" App Up in Less Than an Hour
The News
I saw the news today about Google parting the clouds and letting us take a look at the big server in the sky today. I signed up for one of the 10,000 developer accounts, was told I was added to the waitlist, and then got an email saying I was accepted.
The Investigation
And here are some things I’ve gathered:
- They have their own version of SQL called GQL
- Python is the only language they support right now, which is mentioned a few places in the docs (they also throw Django links around a lot)
- You need to have Python 2.5 installed, and then you can use one of their SDK installers to set their environment up on your machine.
- There are two py scripts they provide: “dev_appserver.py” for you to run a development server, and “appcfg.py” for automatically deploying your app (I still love you, Capistrano).
- They have a library for signing in Google users (it has a dummy development version to test on– this one worked for me in development, but didn’t seem to work in production)
- The apps are hosted on their domain appspot.com (I’m not sure about DNS servers yet)
The Result
I tried to remember what I knew about Python and took their “Hello, World” tutorial (with a few modifications to make it a simple movie database), and within less than an hour had this guy running:
Here’s a screenshot of the admin interface you’re given (similar to Analytics):
They make it pretty much dead-easy to deploy. Makes you wonder what’s going to happen down the road. Hopefully Ruby support, and then someone will proably write the necessary adapters for GQL? How much are they eventually going to charge for this thing?
MacBook Recommendation: Stop Cracking!
I’ve been happy as a MacBook customer so far, with the unfortunate exception that I have been affected by the “chipped casing design flaw“ twice. Now that my year-warranty has expired, I found a pretty convenient way to protect the casing and keyboard when it is shut: this Marware package comes with a restickable wrist pad and a soft cloth for protecting your keyboard.
20 bucks, but it’s definitely better than the hundred-some-odd I’d pay the third time that the casing would chip. You can buy it for your White Macbook or your Black MacBook
.
Ronin: A Simple Rails Process Logger

(from Apple Dictionary)
Back in the fall at rmbr we were running into some requests that ate up a bunch of our memory. Since we often call a few dozen xml requests at a time, we weren’t exactly sure at first which requests were the cause of the growth.
Since I didn’t have a lot of experience with the already-existing Ruby performance tools out there, I cooked up a really basic plugin that monitors the growth of your Rails handler (server-agnostic, although I’ve only used it with Mongrel). We found the greedy requests and traced the leak to some SQL that was being loaded in one of our views (naughty!) within a few minutes of putting the plugin up on our server.
I finally got around to putting this plugin in my repository, so here is how you can try it out:
script/plugin install http://solid1pxred.com/svn/code/rails/plugins/ronin
Try it locally by running your server likes this:
RONIN=on script/server
And then just tail the log to watch your requests:
tail -f log/ronin.log
The plugin outputs the stats like so:
{ :growth => 0.22, :request_time => 0.187, :start_rss => 23416, :end_rss => 30076, :delta_rss => 6660, :uri => '/zombies/4.xml' }
As you can see it is pretty simple to load the log into irb, eval it, and sort it or do whatever you want with it. I’ve noticed a discrepancy with the request time against the Rails logger, so this is by no means scientific (yet… ?), but it gave me a really good approximation to detect those requests that make your server processes grow.
NOTE: this currently is built for POSIX systems
Altering Request Headers in Rails Integration Tests
def regular_user
open_session do |user|
def user.login(login, pass)
post '/sessions', :login => login, :password => pass
assert_equal 'You Are Logged In On a Browser!!', assigns[:page_title]
end
end
end
All of a sudden you decide to turn this into an iPhone-friendly login page, so you have to check for the HTTP_USER_AGENT header in the request. All you need to do is pass an extra hash of request headers (without the "HTTP_" prefix) into the request method (get, post, put, or delete):
def regular_user
open_session do |user|
def user.login(login, pass)
post '/sessions', { :login => login, :password => pass } , { :user_agent => 'something iPhone something' }
assert_equal 'You Are Logged In On an iPhone!!', assigns[:page_title]
end
end
end
This is a little obvious if you actually check the api for integration testing. But I didn't do that at first :)
Privatize your methods dude! 4
I guess I just feel inclined to post this because I haven't done any Ruby metaprogramming posts before. But let's say that you want to include MyModule in your class, but you want all its instance methods to be private.
PrivateMyModule = MyModule.dup
PrivateMyModule.module_eval "private #{PrivateMyModule.public_instance_methods.map {|m| ":"+m.to_s}.join(',') }"
You can test by grabbing all the private instance methods now from that module:
PrivateMyModule.private_instance_methods
