Ruby On Rails on Google AppEngine

A few nights ago, I went to a talk about using Ruby on Rails (RoR) on Google’s AppEngine.  Python was the first language supported by AppEngine.  Java is the second.  Using RoR on AppEngine requires compiling Ruby to Java bytecode using the JRuby compiler and runtime enviroment.  RoR applications on AppEngine gain the security benefits of running in a JVM, but this also imposes restrictions on what sort of packages the application can use.

App Engine
App Engine

Moving an existing RoR application to AppEngine requires remapping ActiveRecord data from a SQL database to Google’s DataMapper machinery.  This store is basically a hash-map that may be distributed over multiple machines — transparently.  Joins are not possible with this representation.  The speaker made the claim that for data that suits this type of store, queries require time proportional only to the result set size.

To get your code and data up to the server you need to compile it (using JRuby) and upload it (as JAR files).  Managing your static file content and Ruby gems sounded tricky because there isn’t a proper file manager or shell interface.  And it isn’t possible to use gems that have binary components (like RMagick – the Ruby binding for the ImageMagick package).

Performance tuning seemed difficult.  Threading is not supported to interleave transactions.  Rather, new machine instances are spawned based on load; a new instance takes about 30 seconds to get up and running.

It’s an intriguing offer: use Google’s machinery to host applications in the cloud that scale transparently and are free for about up to 500M pages per month.  For me, it seems there are too many layers between the application and the hardware, since you never really get a host: at any given time your application may be running on any number of hosts — anywhere.  It will be interesting to watch this type of cloud computing fight it out in the marketplace with cheap managed virtual hosts and other approaches.

1-Wire Signalling

1-Wire is a signalling protocol developed by Dallas Semi that has been around for over 10 years.  It’s actually a two-wire physical connection, but one of the wires is GND.  1-wire masters can power small devices and communicate with them over these two wires.

1-wire USB bus master
1-wire USB bus master

I learned a little bit about 1-wire signalling recently.  It uses an open-drain pull-down driver with a pull-up termination resistor.  To signal a “1”, a device pulls the bus down for a very short duration – from 1 to 15 uS.  To signal a “0”, a device pulls the bus down for 60uS.  A very long pulse – 480uS – resets everyone on the bus.

Nowadays, bus masters implement software control of network parameters.  Such things as slew rate and timing are adjusted dynamically by adaptive algorithms in the bus master.  I was aware of adaptation in very high-speed signalling systems for memory, ethernet and IO, but had not really encountered it’s use in a lower-rate system.  Here, adaptation helps with reliability and distance rather than speed.

Cycle Lust

(This post is a little off-topic for me here, but I’m still finding my voice and experimenting with this forum.)

I discovered Moto Marin off of 101 while out on a ride last week. This business used to be located off on a side street, but they recently moved to a vacated auto dealership fronting 101 to gain more visibility.  They’ve also begun representing Motoguzzi in the Bay Area (after a previous distributor went under).  I was intrigued by the Motoguzzi Stelvio I saw there.

I ride a BMW R1200GS that looks just like the picture below. I was taken aback by how similar the Stelvio is to the BMW both in styling and stature.  I got a chance to sit on the Stelvio and rev the engine.  The Stelvio has a more growly rumble compared to the BMW, and it felt great, even just sitting there.  It sure is sexy, but I’d expect that from the Italians.  But for now, I think I’ll stick with the fine German engineering of my GS.

BMW R1200GS 2008
BMW R1200GS 2008
Motoguzzi Stelvio 2008
Motoguzzi Stelvio 2008

SheevaPlug PlugComputer

The SheevaPlug is a tiny Linux server from Marvell based on an ARM processor.  It comes with 512MB RAM and 512MB of SSD.  A development kit currently costs $99.  It’s about the size of a slightly-oversized wall adaptor.


It comes with an Ethernet port, and two USB ports.  One of the USB ports is intended to be used during development and for debugging, the other is for regular applications.

I was surprised to find a rather full-fledged Debian-based Linux distribution (Gentoo) on the device.  It has a  package manager (“apt”) already installed, so it is simple to install other standard applications.  I ventured off into some uncharted territory when I decided to explore using the SheevaPlug to monitor some devices that communicate via a serial interface through USB, however.

Device Drivers …

I learned something about device drivers in this experiment.  While USB is a standard interface, to expose your USB device to the OS, you need a piece of software (a driver) that understands the particular chip in the USB device.  In my case, it had a Silicon Labs UART.  On Mac OSX, Silicon Labs provides a driver that exposes a serial interface as /dev/cu.SLAB_USBtoUART when the USB device is plugged in.  On my Intel-based machine, the default OS understands this device and it appears as /dev/ttyUSB0.  I was concerned that on the ARM-based SheevaPlug, there may not be the necessary piece of software.

After a number of false starts, I found out that the original OS distribution did not understand this particular UART.  However, the Silicon Labs UART is standard enough that there is support in later revs of the kernel.  Updating the kernel and re-flashing the device was required, and then my ARM-based SheevaPlug was talking to my USB devices over /dev/ttyUSB0.

For more information about this device look here: