It took me a long time to author this – and to update this blog in general, in fact. RubyMotion has turned out to be fun and profitable, but also exhausting; I’m engaged in another RubyMotion project that has taken up most of the free time I used to dedicate to this blog.

Still, I committed to making an entire series, starting with Introduction to Programming I, and this is the next in that line. I hope someone finds it useful! I actually made edits to the last post to remove references to sandRBox – I’m using repl.it now, since that runs on the individual’s browser.

My RubyMotion app is almost complete. I spent a lot of time today getting ShareKit to work correctly in it; while Motion Cocoapods generally work pretty well out of the box, ShareKit was obstinate and unpleasant and it took me most of the day to get it working correctly. So, to save someone else some time, I documented the steps I took to get it working.

Just a small caveat first, though; this is not simple and elegant like the rest of the code here. (Generally.) I could’ve done this in a better way – by extracting the changes out into a new Cocoapod spec repository – and maybe in the future when I have some time I will. But until then, I hope this somewhat ugly hack helps out someone else!

Following parts one and two of my series on Rails concerns, I’m going to finish up with an extremely useful controller concern: automatically adding metatags to (and correctly displaying individualized titles on) your pages. Metatags, of course, are SEO-boosters that you should really be using if you aren’t already. In addition to improving your search engine ranking, they allow your pages to appear idiomatically in Facebook’s Open Graph. Of course, everyone wants metatags on each and every page on your site, but unfortunately it can be sort of a headache getting them there. Using the meta-tags gem and some good old-fashioned hard work, though, we can implement a very simple method to get metatags into every page of our application with minimal hassle.

For the second part of my series on Rails concerns (following part one earlier this week), I’ll be dissecting a tagging system and how to make it concerned. Of course, you have great gems like acts-as-taggable-on, but if you want significant customized functionality in either your Tag class or the taggables, you’re going to have to roll your own solution. That’s what I’m doing for GirlsGuideTo, and this is how I implemented it.

Rails concerns are a fancy way of saying Ruby modules. 37signals uses concerns a lot in the new Basecamp, and it’s easy to see why: separation and recatoring allow you to reuse code more sensibly and test it in only one place. But concerns aren’t only for code refuse – by allowing you to unclutter models, they make it more obvious where code in your application lives. Even though, for example, orders are the only model in your system being shipped, having a concern called Shipping makes it completely obvious that that’s where all the functionality for shipping lies… whereas a newcomer to your application would have to search through the order model to find it.

I’ve been using concerns extensively in GirlsGuideTo’s upcoming application, and I figured it’d be an interesting read if I shared the ones I’ve made so far. They’re not too complicated (this first one I’m posting mostly just to illustrate the concept), but but don’t let that fool you. They can be super complicated and really involved – but more than that, concerns just make your code better, so you should definitely be using them!

This post has been superseded by Dynamic Error Pages, Corrected. Check that out first.

One of the coolest features of Rails 3.2 is tagged logging. Using the UUID tagged logger, you can give each individual request a UUID reference number in order to track individual errors, find them, and smoosh them. It’s generally pretty awesome.

But it’d be even awesomer if actual errors in your application referenced this UUID, wouldn’t it? Maybe even emailed it to you in exception_notification? Presented it to your users so they could say directly, “I encountered error 123xyz,” rather than force you to look through a huge amount of backlog to find their specific exception?

Happily, you can do just this!

I’ve been looking about two weeks now for a really fantastic designer for GirlsGuideTo – a designer that’s as fabulous as the site itself. Somewhat surprisingly, given how many people are unemployed or underemployed, my search has been really difficult. And not because of a dearth of responses: in fact, quite the opposite. I estimate I’ve received more than a hundred resumes in response to Craigslist postings, LinkedIn listings, and advertising in Dribbbble. And most surprising to me is the fact that the vast majority of these responses just aren’t very good.

I’m sure that many of these resumes and coverletters come from experienced, seasoned professionals with a genuine and burning desire to be paid – a desire that is equally matched by my hunger to pay them for the amazing work they can do. But frankly, you wouldn’t know it from reading their letters. 99.9% of them are just… bad. So, I’ve taken the time to distill the mountain of resumes in my inbox into three succinct lessons. If you’re going to apply for a job, please take them to heart before writing your potential employer. Not only will you increase the chances you’ll actually be hired, but they will definitely thank you for breaking the tide of mediocrity that is surely washing over them. If you’re the one to stand out, believe me… you’ll get noticed.

Designing a new site from scratch can be difficult – not technically, but from a usability perspective. What color will your users like best? How big should your buttons be? Where should advertising be placed? Of course, there are amazing usability books out there, but there are some questions you can only answer through experience. Of course, designing for usability should be one of our top priorities – and here are three cute little libraries that will help you make your sites awesome, beautiful, and most importantly, usable for your users.

There’s been some discussion recently about the relative merits of Heroku. I’ve managed applications both inside Heroku and outside it, and personally speaking, I just can’t decide whether or not I like the web’s premier platform-as-a-service or not. Every now and again I’ll gnash my teeth in frustration over it, and then other times I’ll sigh dreamily and think of all the wonderful things Heroku has done for me – and indeed, for the world. So I jotted down a quick list of pros and cons that I think everyone considering Heroku should know; then, at least, you can make an informed decision as to whether or not it’s right for you.

I try to keep to a schedule of a post every three days, and I’ve definitely not been keeping on top of that – I haven’t posted for almost a week and a half now. I apologize for the lack of content; in my defense, I’ve been deep in negotiations that have resulted in some exciting personal changes. Changes that should hopefully make this modest blog even more interesting!