I recently ran into an issue with RubyMotion where I couldn’t build to a development device without explicitly setting the provisioning profile in the Rakefile. Not only is this annoying, but it’s a big problem for team development because you’ll always want to check your Rakefile into source control and each team member would have a different Rakefile.

So I started hunting for a solution.

Official Documentation is Misleading

The RubyMotion official project configuration documentation states that it look for and use the first provisioning profile it finds on your computer. This is false though, at least when you have multiple profiles, because even if each of your profiles contains the device UID you’re building to, this still won’t work.

Existing Solutions Insufficient

The existing solutions are simply to explicitly refer to your provisioning profile in your Rakefile. That’s OK for solo development (but still annoying), however it’s not a good solution for team development.

See this stackoverflow Discussion

My Solution

After a little light reading I discovered that the RubyMotion build will check for a default profile named “iOS Team Provisioning Profile”.

So we simply need to create a new provisioning profile via the iOS provisioning portal named “iOS Team Provisioning Profile” and containing the device(s) we want to be able to run development builds on.

I’ve been building an iOS app with RubyMotion for a while now, and the verdict is…

I’m in love with RubyMotion.

Here’s why:

• Ruby syntax runs circles around Objective-C syntax. If you’ve used Ruby and Objective-C for anything significant, and you’re not a masochist, then you know what I’m talking about.
• It already has some amazing libraries like Teacup, BubbleWrap, and Formotion.
• Building and deploying is a cinch with Rake. There’s even a testflight gem.
• Bundler and CocoaPods for dependency management.
• The REPL. I actually haven’t found this that big of a deal, but it can come in handy now and then.
• I can continue using a text editor (vim or Sublime Text) instead of that hog called Xcode.
• Really small archives.
• The only (minor) downside so far has been occasionally translating example Objective-C code to RubyMotion code from Apple’s docs and Stack Overflow.

I had the opportunity to work with a bunch of TDD vim hackers during the last 4-5 months over at Nulogy, and after some initial resistance I decided to jump in and learn vim. My motivation is to really see if it lives up to the hype, and more importantly because it’ll make me look like a genius to the layman watching my screen (I.e. Gary Bernhardt).

I’ve tackled vim a few times over the years, but never fully committed to it. Since I believe you need to fully commit to something to do it well (including learning anything), I decided to pick up my touch typing first to really see the benefits of VIM.

Last week I achieved my typing goal of 75 words per minute, inspiration courtesy of Steve Yegge. I’ve since upped my goal to 90 wpm, but I think I’m at least quick enough now to really immerse myself into learning vim.

I’m starting with Peepcode’s Smash Into Vim, this Yehuda post, and of course the built in vim tutor.

Rock on!

Yesterday I ran through the “Rails Best Practices” course over at Code School.

I really like this interactive format. You watch a video / screencast covering a topic or set of topics, then you’re required to code up some excersizes to review the content of the video’s material before you can move on to the next topic.

Overall the format worked really well. The gamification (points etc.) didn’t make a difference for me, but it might be a motivator for some people. I do think they’re on to something here, and from the looks of it (also from the workd marketplace in their tagline) they’ll be refining this as a platform for use with other third party content.

The online editor was actually really well done. It’s not vim or emacs obviously, but it’s not super cludgy like you’d expect, so it works well enough for the small amount of material you’re covering.

I think there’s an opportunity to add in some social features so students can help each other if they get some harder topics going.

As for the content of the “Rails Best Practices” course itself, you can get the same content from here; http://rails-bestpractices.com/, however the code school environment was enjoyable enough.

A problem I often run into whenver I build an ordering system is how best to store addresses for customers and orders in an ordering system (like an ecommerce store).

Given the following conditions for an order placement application:

• Customer’s can register and supply seperate billing and shipping addresses.
• Orders need to store customer data as a snapshot of when the order was placed in case the customer data is changed or removed in the future (orders should maintain historical integrity).

We have several different ways of accomplishing this with a relational database (document and KV stores are a different story).

1. Store all address information within the customer and order tables themselves. This is perhaps the easiest solution even though it’s not the most normalized. So you’d have fields like billing_city and shipping_city inside both the customers and the orders tables. The downside is that you’ve created duplicates of the same fields, which uses up a little more storage space (usually not an issue) and requires more work to maintain if you ever needed to change their schema (again, pretty rare occurence for address fields that are well known entities). The upside is it’s very simple to work with from a code perspective.

2. Store addresses in their own table and associate them to orders and customers using via polymorphic composite keys. In order for this to work you’ll need a composite key of 3 fields; address_type, addressable_type, addressable_id. So the shipping address for a customer would be something like: “Shipping”, “Customer”, 1232. and the billing address for an order could be: “Billing”, “Order”, 2873. etc. The downside is it’s a rather fancy assoication and will add complexity to your ORM code as you override some methods (since no ORM I know of is built to handle this oddball relationship out of the box). The upside is it’s very normalized and you can add new address types on the fly and new classes that can have addresses on the fly.

3. Store addresses in their own table, but simplify the association by using many-to-one foreign keys. For this to work we just have keys in the address table for each assoication. So in this case we have “billing_customer_id”, “shipping_customer_id”, “billing_order_id”, “shipping_order_id”. The downside is it’s not very normalized / DRY and you won’t be able to add new address types or addressable classes on the fly like you could using the plymorphic associations. The upside is very simple (almost all convention based) ORM code since you’re dealing with belongs_to type relationships.

4. Use an Address class to define your address fields, but serialize it to text fields wherever it’s used. So you’re ditching the relational style just for the addresses. For this to work you’d have two text fields in your orders table and your customers table; “billing_address” and “shipping_address”. Then you just serialize your address objects to these fields (yaml, xml, json, or whatever). The upside is the same simplicity as solution #1, but without all of the redundancy in your schema. The downside is the potential complexity of code needed to edit and manage the address information and get proper validations to work.

My preferred solution is #4. I think it’s worth the added complexity at the view level when using Rails 3 since it’s not too much extra work (although it could be a little cleaner).