[LRUG] Objects and on Hexagonal Rails

[Matthew Ford]

So we've been experimenting with this pattern and had some good success
with internal projects and are slowly introducing it in newer client
projects. I wouldn't go down this route if you're going to have developers
who are new to Rails on your project as it's yet another thing to learn,
but for seasoned developers it shouldn't be much of an issue. It's
certainly better than having a million and one callbacks in a single class.

Regards,
--
Matthew Ford

Director of Bit Zesty

T: +44 (0)2071250160

This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify Bit Zesty
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system. Bit Zesty does not accept liability
for any errors or omissions in the contents of this message, which arise as
a result of e-mail transmission. Opinions expressed in this email are those
of Matthew Ford, and do not necessarily reflect those of Bit Zesty.

Bit Zesty Ltd, a company incorporated in England with registered company
number 06883289.


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/581d9127/attachment.html>