[LRUG] Objects and on Hexagonal Rails

[Gerhard Lazu]

Some sound principles which never failed me:

1. Choose a solution from your own experience, appropriate for the team
that you're leading

Teams vary wildly, what works for team A will not work for team B. If
unsure, favour the known, tried and tested over the more academic solutions.

2. Write apps with change in mind

POODR explains this very well, I couldn't put it any better
http://www.poodr.info/

Whether it's a conventional Rails or pure JS app, strive for simple & clean
code.

3. Simple and straightforward always wins

If Rails is the simple and straightforward solution for you, go with it. As
Roland mentioned, Rails works very well for conventional CRUD. Even bigger
apps, with enough Rails experience, can be pulled off, just think alphagov.

4. Innovate as/when you can afford it

You should try new things for fun, not when you have a deadline or when
important things depend on it. Experiments can go either way, plan for
failure. Sometimes, the old and boring way is the best way
http://zef.me/4235/pick-your-battles

5. Defer decisions

This requires more experience, but the point is to defer everything that
you can. Rails is a decision, so is a real database Keynote: Architecture
the Lost Years by Robert
Martin<http://www.youtube.com/watch?v=WpkDN78P884#t=49m48s>

As Stephen mentioned, we've been running EBI in production for a few months
now, we're holding out for the degradation part. Every approach starts to
degrade sooner or later, without that experience under our belt the
talk that we're thinking of giving would be incomplete.

My reasons for going pure Ruby are based on all the negative experiences
that I've had with monorails stuck at specific versions (mostly Rails
2.x) and bloated with hundreds of gems. I've always associated them with
having an anaconda as a pet.

Over time, all successful apps grow to become standalone DSLs. As long as
you don't weld them to a framework, you will be much better off in the long
run. Yes, it does require experience to realize when you're coupling, but
experience is just learning from past mistakes. Trying to prevent mistakes
acts like airbrakes to learning and growing.

As for the conclusion, Apple (unreleased) Think Different ad - Narrated by
Steve Jobs (1997) <http://www.youtube.com/watch?v=Rzu6zeLSWq8>

------------------------------
Twitter <http://twitter.com/#!/gerhardlazu> Github<https://github.com/gerhard>
 Blog <http://gerhardlazu.com/>


On Tue, Jul 23, 2013 at 2:26 PM, Tom Cartwright
<tecartwright at gmail.com<javascript:_e({}, 'cvml',
'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 <javascript:_e({}, 'cvml', 'Chat at lists.lrug.org');>
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>


-- 

------------------------------
Twitter <http://twitter.com/#!/gerhardlazu> Github<https://github.com/gerhard>
 Blog <http://gerhardlazu.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20130725/b4c0cfba/attachment.html>