Today we launch OtherInbox!

Josh and I are in San Francisco at Techcrunch50.  Sometime between 1 and 5 pm Pacific time we'll be launching OtherInbox!  You can see the demo live at otherinbox.com.

What a great year it's been!  Thanks for everyone's help and support.

My talk at Lone Star Ruby Conference

I had a great time at Lone Star Ruby Conference,

meeting fellow Rubyists and hanging out with the entire OtherInbox dev team.  I had the privilege of speaking about all the benefits we've gained from using as much Ruby as possible in running our service.  Confreaks will be posting the video soon, but here are my slides:

Ruby in the Cloud (PDF, 5.8 MB)

I really enjoyed sharing our experiences with the conference, but the highlight of the event for me was getting to hear the inventor of Ruby speak, and also getting to meet him.  You will not meet a more generous, noble, joyful person than Matz, and I can't think of anyone I don't know personally who has had more of an impact on my professional life than him.

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