[LRUG] Objects and on Hexagonal Rails

[Matthew Rudy Jacobs]

I often get involved at the early stages of building a prototype, then an
MVP, and handing over to an internal team.

If I were planning to build and lead a team for a number of years my
approach would be different.

But if you plan to hand over a project you need to be able to explain
succinctly the design principles you've used.

For the last couple of years I've always said;
"I built this according to the patterns described in Ryan Bigg's Rails 3 in
Action"

That's worked very well. If its a newbie, or an experienced developer, we
can all read that one book and understand the approach.

I think that "Objects on Rails" describes some great patterns, but isn't
complete enough as an introduction to rails to give to a newbie.

I'm waiting for Steve Klabnik to finish his rewrite as "Rails 4 in Action",
but I'm reconsidering what approach I'd use for a new "rails project".

(I started building an Ember app (+ Rails API) this week, and that's pretty
fun)


On 23 July 2013 14:26, Tom Cartwright <tecartwright at gmail.com> wrote:

> Afternoon all,
>
> I am about to start a new rails project. I have read objects-on-rails and
> watched the Hexagonal rails talk and the techniques make a lot of sense.
> "Great!" thought I, I can build this new app with lots of those patterns
> (service layers, decorators, publish/subscribe (announcer/listener)
> pattern, logic living in a classes with a single responsibility etc).
> Everything will be easier to test and easier to change and develop. Winner.
> However, when I asked a colleague what they thought of these techniques,
> they had concerns about moving away from the rails conventions as it would
> take time to get developers up to speed with the techniques.
> One reason (and I can definitely see their point here) is that intentions
> can get obfuscated when using lots of loosely coupled objects and this can
> lead to confusion. Given lots of developers will be working on the app,
> onboard time is something I need to consider.
> One way to strike a balance would be to develop the app in the canonical
> fashion and then use these techniques as and when. E.g. Use the publish
> subscribe pattern when controllers/models start to get bloated. However, by
> that point it could be a bit too late and I might be reluctant to make
> changes that major. My integration tests would catch most stuff, but I will
> have to be confident that they will catch all the edge cases.
>
> So my question is: Should you strike a balance? If so, how do you strike a
> good balance? What has been your experience of introducing these techniques
> bit-by-bit?
> Thanks in advance for your brain thoughts.
>
> Tom
>
> --
> Tom Cartwright
> tecartwright at gmail.com Portfolio <http://www.tomcartwright.net> · GitHub<http://github.com/tomcartwrightuk>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20130723/04487733/attachment.html>