I love Rails’ routing system. Quickly and easily connecting English-readable URLs to complicated web actions is one of the joys of working in one of the coolest web frameworks on the Internet. At Synthetic, we’re ramping up to get a new site out, and as part of the push for that I implemented some cool dynamic routing. I wanted to briefly summarize how and why I went with the routing choices I did, to illustrate using routes expressively and, hopefully, easily.

My first RubyMotion application is rapidly nearing completion. As it involves user preferences that have to be stored both locally and remotely, I was investigating the available Rails gems for user preferences and really didn’t like what was presently out there. I don’t really have time to maintain another gem, but maybe someone else has run into this problem and wants a quick and easy solution for creating user preferences. If so, then this code’s for you.

I’ve been spending a lot of time talking about RubyMotion recently, and I was intending to post the second in my Introduction to Programming series today to give the whole Motion thing a break. But I spent far too long on Tuesday getting an app correctly deploying through Testflight, and it was a really painful process. I took copious notes while making it happen, though, so in the interest of saving someone else’s time, here is my step-by-step guide to successfully getting an app from your RubyMotion simulator onto someone else’s device.

I’ve been using RubyMotion for four days now. I still like it a lot, and I think the coolest thing about it is the rapidly-evolving community around its use. Ian Phillips figured out how to link Interface Builder and RubyMotion; Alan deLevie wrote a neat connection to Parse.com. Personally, I’ve been spending the time writing lots of code. I’ve just deployed my first RubyMotion app into TestFlight and sent it to some testers. Soon hopefully I’ll have an actual RubyMotion app, which is pretty exciting! I’ve learned a lot in the last four days of use and wanted to post a few tips and tricks to hopefully make life easier for other RubyMotionists.

Generally speaking I try to stay away from inflammatory posts. But the release of RubyMotion has been a revelation to me. I’ve done iOS programming before, but I’ve always found it unpleasant next to programming in other languages. Don’t get me wrong, Objective-C is better than C or C++, but I don’t think that’s saying a whole lot.

I’ve spent the better part of yesterday and last night (since RubyMotion was released) giving it a try. After converting two existing projects from Objective-C into RubyMotion, and spending some time developing one of those further using RubyMotion alone, I’ve come to a number of conclusions about RubyMotion and Objective-C. Ultimately, RubyMotion is superior to Objective-C in almost every way, and Laurent Sansonetti must be some kind of mythical otherworldly genius to have developed something at once so usable and so powerful.

Why do I believe this? What makes RubyMotion so superior to straight-up Objective-C?

Dynamoid 0.4.0 is a pretty significant improvement over previous iterations of Dynamoid. While the project has obviously always been my hobby, 0.4.0 represents what I would consider one of the first iterations I would use in a real production application. Not because the previous version haven’t worked – they’ve all done exactly what they should do. But now it has the flexibility and options to really allow an application to thrive in Amazon’s DynamoDB.

What do I mean by that?

This is a copy of the handout I’ll be giving to students for my upcoming class at the Center on Halsted, creatively titled “Introduction to Programming.” It borrows structure rather liberally from Chris Pine’s Learn to Program, but the content is my own.

I didn’t make a post on the 18th because I’ve been in San Francisco at the Hipstamatic offices, which are totally awesome. The work I’ve been doing here has taken up all of my time, so I didn’t even get the chance to start writing a post until today. While I was here, I met Luke Beard, a super talented designer who’s been touching up a lot of our sites. For example, the excellent disposable.hipstamatic.com site is all his handiwork. I wanted to streamline his development process, so that he could deploy his work without feeling blocked by my (usually extremely full) schedule.

We’re going to use Middleman to achieve this, in addition to some other nice effects: automatic minification of JS and CSS and smushing of images. Middleman is essentially intended for developers, though; it requires commandline tools that can be fairly intimidating to those who’ve never really bothered popping open the console before. So here’s some small tweaks I made to our HTML projects to make the whole process easier on Luke and any future designers we hire.

In my previous entry on elasticsearch, I promised I would elaborate on testing elasticsearch (and tire) in Rails applications. There’s not really a whole lot of secret sauce to it, but I figured it’d make a good, quick post with some crunchy code for a late night. While writing, though, I realized I could also talk about a small problem I ran into while using tire – specifically relating to index regeneration. This isn’t a major flaw, but it did waste some of my time, so I figured documenting it (prior to fixing it) would be a sensible idea.

Hipstamatic’s Rails application is deployed to Amazon’s Elastic Cloud, and we make extensive use of Amazon’s Web Services in keeping it nimble and performant. Last month, I dedicated two weeks to increasing the responsiveness of the application while simultaneously improving its performance. As a result of the changes I implemented, our AWS costs for this month will be 60% lower than they were last month. This is a pretty dramatic drop, and I wanted to discuss the tools and techniques I used to make it happen.