Ignite Baltimore Call for Participants

Hey everyone, we're organizing Ignite Baltimore, and we're looking for interesting topics.  Check out the site for more details, or visit these other city Ignite pages for inspiration:

• Phoenix
• New York
• Seattle
  

If you're a Twitter person, follow @ignitebaltimore. 

Humane Sproutcore Server Development Environment

Recently I've started to build a new, rich user interface for OtherInbox using SproutCore, which has been very enjoyable.  One thing that was not enjoyable was properly configuring my development environment.  

In production, you'll usually deploy your SproutCore app as a static file, so all you have to do is arrange for your users to hit that URL (which out of the box is configured as /static, but could be anything).

In development mode, though, you want to be regenerating your client on the fly by serving it dynamically from sc-server.  To use your app, you talk to http://localhost:4020, and if you want your client to communicate with a backend server, you configure the "proxy" setting in sc-config.  Thus when the Sproutcore server gets a request for "/gadgets", it proxies that request to your local development server.

For some kinds of apps, this works well.  For OtherInbox though, everything the Sproutcore app does requires you to be signed-in and have an active session with the Rails application server.  This caused all kinds of cookie problems, probably because of same origin policy (e.g. my Rails app running at otherinbox.dev was issuing cookies that were somehow getting mangled by the proxying process).

Here's what I solved the problem.  Check out my local Apache setup for details about the whole stack:

 <VirtualHost *:80>

 ProxyPass /app http://localhost:4020/other_inbox/
 ProxyPassReverse /app http://localhost:4020/other_inbox

 ProxyPass /static http://localhost:4020/static/
 ProxyPassReverse /static http://localhost:4020/static

 ProxyPass / http://localhost:3000/
 ProxyPassReverse / http://localhost:3000

 ProxyPreserveHost on
</VirtualHost>

See how that works?  When I load http://otherinbox.dev/app in the browser, Apache proxies that request to sc-server, which dynamically generates my Sproutcore client app.  

When components of that app make requests for other parts of Sproutcore, using the /static URL, Apache also proxies those back to sc-server.  

When the app makes requests for anything else, those requests get proxied by Apache to the Mongrel I have running the Rails code.  Because my Sproutcore app is making REST calls to the backend, this ensures that anything the Sproutcore app asks for from my server gets proxied properly, in this case to localhost:3000.

As soon as I did this, all of the cookie issues were done.  You'll also have to add some application-specific code about how you want to force logins if the user is not already signed-in. In our code, I just check for a logged-in cookie, and if it's not there, we open up the URL for a signin window.

Cool Medialets Micro-App

My good friend Paul Barry and I have been helping our friends at Medialets out with a neat little Rails micro-app that culls iPhone App Store data from Apple's endless array of plists, and makes a chart, a dynamically-generated Gruff graph, and a bunch of RSS feeds.  

My favorite thing about this app is the New Apps RSS feed which lets me keep up with the newest time-wasters/productivity enhancers for the iPhone.  Let me take this opportunity to say that the world does not need any more iPhone tip calculators or fortune-telling games.

I wrote a bit more about the latest features over at the Medialets blog. 

My iPhone app screens

I got stuck for 90 minutes at the dentist office, so I decided to organize all my iPhone apps. First screen (left) is essentials, stuff I use every day. Second screen (right) is references and tools.

Third screen is "communications and entertainment". Fourth screen is the graveyard, for things I don't use regularly or can't get rid of.

I can think of worse ways to kill 90 minutes.

Contributing to Rails is easier than you think

At OtherInbox we love open source and are looking for ways to share some of our labors with the community. Today I came across a great opportunity to contribute something to Ruby-on-Rails core development. I'm posting it here so everyone can see how easy it is to contribute.

I was building a JSON API to enable some new awesome features we're working on. Following the JSON request specification, I had the client setting its MIME type to "application/jsonrequest". But this was not causing Rails to recognize the request as JSON and thus the request body was not properly parsed. After doing some digging, I realized that Rails only looks for MIME type "application/json".

Fortunately, MIME type processing is implemented really humanely in Rails, so I whipped up a little patch that adds "application/jsonrequest" as a synonym for the JSON MIME type. First I wrote a test to prove that this was a problem. Once I had a failing test, I added the MIME type, and got my test passing. I followed the git patch instructions on lighthouse, then jumped into IRC #rails-contrib to garner support for it.

I happened to see that Rick Olson, the author of the existing JSON parsing code, was in the chat, so I pinged him with the lighthouse ticket. He tested it and applied it, and now our one line of code is a part of Rails!

Hopefully this will save some future JSON implementer a bit of pain.

Cross-posted from the OtherInbox blog

Speaking at Lone Star Ruby Conference

I will be speaking at the Lone Star Ruby Conference in September about how we use Ruby to deploy, monitor, and manage a cluster of servers running in the Amazon Web Services virtual cloud.   Below is a summary of what I'll be talking about.

In OtherInbox, almost every system administration task imaginable is carried out using Ruby, meaning we as developers can enjoy all of Ruby's expressive benefits and spend less time scripting the shell, writing cron tasks, or using other languages. Because we make fewer context switches from thinking in Ruby to thinking in other languages, we also reap a big productivity benefit.

Using Ruby throughout our cloud also means that porting the application to run in different production environments is a trivial task, because Ruby is the glue connecting the Ruby components together, thus all we require is a Ruby interpreter to deploy.

Two key Ruby technologies have matured in the previous 18 months which make it ideal for almost every layer of managing a cluster of servers:

• god.rb allows fine-grained process monitoring and daemon control (a la monit)
• rufus-scheduler enables Ruby-based scheduling (replacing cron, and providing a great facility for running daemons that must be executed on a recurring basis)

When combined with these Ruby workhorses, developers today can spend much more of their time writing Ruby code, and less time struggling with the vagaries of their production environment:

• Ruby standard library utilities (File, FileUtils, etc.)
• Rake
• Capistrano (for any kind of remote application, not just Rails)

The talk will also include a discussion of using several different AWS gems to make cloud computing simple, by illustrating the use of Amazon's S3 and SQS services to distribute asychnronous work and handle communication between servers.

(cross-posted from the OtherInbox blog)

random_data v1.3.1 released

random_data v1.3.1 is out.  Courtesy of stalwart contributor Hugh Sasse, this release includes more firstnames, and two new methods: Random.firstname_male and Random.firstname_female. 

Install it via:

sudo gem install random_data

or get it manually.