Yesterday, the team over at Grouper released the first part of a blog series they call Rails, the Missing Parts. In part one, they talk about using Interactors in your Rails application to detangle your ActiveRecord objects and business rules from your controllers. They have the benefit of encapsulating your business rules and model interactions in one, more easily testable place. And, they have the side benefit of allowing you compose new service objects with others to make more intricate interactions. I think it’s interesting to mention that David Heinemeier Hansson jumped into the Hacker News discussion to point out that this is a good practice, only when it needs to be done. It’s overkill to do it always, but if you’ve got a sign up form or something that manages multiple models, then maybe it makes sense.

Speaking of Interactors or Service classes, there is a talk from Stephan Hagemann at MountainWest RubyConf 2013 that is a great overview on component-based architectures in Ruby and Rails. He shows with simple examples how you can extract self-contained business logic into modules, gems, engines, etc. He doesn’t actually use these as external gems. His central point seems to be that it’s easier to think about modules — even if you don’t fully extract them — when they have their own namespace. I tend to agree with him: clear naming tends to make it easier to see the edges of a class’s responsibility. As he demonstrates, the fact that a Rails app originally defines no namespaces sort of encourages a hodge podge mentality where responsibilities are mixed and it’s not clear what’s in charge of what exactly. Stephan shows how to create the gem structure without the need to run gem build or actually publish the gem itself. Instead it all stays within the Rails app despite. So he gets the benefits of a distinct interface and he can add the gem to the Gemfile using a local path. Ditto for mountable Rails engines.

Last week, Jordan Maguire put together an article on his experiences using RubyMotion where he reflected on The Frontier Group’s 3000 or so collective hours of using it. It’s one part in what may become a series on how to work with RubyMotion from the perspective of a Ruby on Rails developer. In this article, he touches on quite a lot, but I appreciated the “don’t think of controllers in Rails when you’re working with controllers in Cocoa Touch,” “state and persistence are drastically different in a client application,” and most amusingly, the observation that “Obj-C looks like the syntax was derived at random from a bag of broken glass, barbed wire, and salt.”. Even though you’re working in Ruby at the end of the day you’re building Objective-C applications. As such, you should know Objective-C at least enough to be able to convert Objective-C code to RubyMotion.

Last week Adam Sanderson wrote up a blog post about how adapters are used for the MultiJSON gem, ActiveRecord and even the DateTime and Time classes.

Quite a few people will find inspiration looking at ActiveRecord’s AbstractAdapter. It contains the basic database functionality while the MysqlAdapter for instance inherits from it and includes more stuff specific to MySQL databases, and the chain goes on all the way down to PostgreSQL.

These patterns are very handy when building an adapter for external APIs for instance. Not to mention give you the ability to make a testing adapter that makes no network calls. Sounds like a fun read.

The last example in the post is the way Rails (through ActiveSupport) basically patches DateTime to play nice with the Time class by adding a consistent #to_i method to it. As with any foray into Rails source code, you’re likely to pick up some nifty trick or discover some impressive hacks along the way.

Last month, Omniref released a major update to their Ruby source code indexing system, adding cross library reference inference and inline documentation from included modules, among other things. Omniref is a bit like a Ruby documentation and source code search engine that spans across Rubygems. It was created by Tim Robertson and Montana Low and you can think of it a bit like the Google of Ruby code, but more focused and intelligent on the search results. Because the context is strictly Ruby and Rubygems, they can cross link, show related libraries, dependent libraries, syntax highlighting, documentation, and more. It’s pretty amazing that they can inline function documentation between Rubygems (for example how ActiveModel provides to_key for ActiveRecord objects), showing the original function and documentation.