[LRUG] Objects and on Hexagonal Rails

Tue Jul 23 15:23:39 PDT 2013

To address the question of hiring I say hire software engineers rather than
Rails devs.

We've had a pretty positive experience with with on-boarding so far, but be
aware you'll need to hire people with good heads for OO.

Just as there's programming with functions and functional programming,
there's programming with objects (most Rails apps) and object orientated
programming.

If your team know the distinctions I'm talking about then they'll be fine.

Also if you start with coupling your app to Rails you ain't never getting
it back. Start decoupled and if it causes a problem with your new hires
they can paste the code into a massive controller method (or maybe on the
user model) and everyone will be right back in their comfort zones :)

Stephen Best
Ruby / Javascript developer, Ember.js evangelist.

+44 7745 790523
linkd.in/stephenbest
github.com/bestie
@thebestie

On 23 July 2013 23:12, Stephen Best <bestie at gmail.com> wrote:

> I've been working on a green field SOA project with the team at Cambridge
> Healthcare recently and we've very much embraced the whole 'Hexagonal
> Architecture' paradigm, following the EBI / EBC (entity, boundary,
> interactor / controller) pattern mentioned by Uncle Bob is his
> "Architecture the Lost Years" talk.
>
> http://www.youtube.com/watch?v=WpkDN78P884
>
> We started off with a hexagonal-ish Rails app, used devise and the service
> layer pattern and soon moved away from Rails and ported our app to Grape.
> The porting process was not a big problem.
>
> The awesome stuff is:
>
> * Adding / changing features is very easy.
> * All our objects are very simple.
> * Tests are lightening fast. Unit test run measured in ms. Full
> integration suite run through Faraday / Rack test takes <5s, including
> startup times.
>
> The caveats are:
>
> * It takes a little longer to get going.
> * Those tough decisions about how to do things are frequent at the start,
> make sure have at least two experienced/obsessed engineers to pair on /
> argue about them.
>
> Gerhard Lazu and myself are planning to present some of our ideas and code
> samples as soon as our apps have proven themselves in production.
>
> Stephen Best
> Ruby / Javascript developer, Ember.js evangelist.
>
> +44 7745 790523
> linkd.in/stephenbest
> github.com/bestie
> @thebestie
>
>
> On 23 July 2013 21:25, Aanand Prasad <aanand.prasad at gmail.com> wrote:
>
>> This comes to mind as a practical application of some of the techniques
>> we usually discuss at a higher level, though perhaps it's not all that
>> radical:
>>
>>
>> http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/
>>
>> On the refactoring theme, there's also the Bowkett book, Unfuck a
>> Monorail. Has anyone read that?
>>
>>
>> On Tue, Jul 23, 2013 at 8:53 PM, Murray Steele <murray.steele at gmail.com>wrote:
>>
>>>
>>> On 23 July 2013 15:58, Roland Swingler <roland.swingler at gmail.com>wrote:
>>>
>>>> * What sort of developers will you be hiring? Junior & mid-level
>>>> developers have a lot of resources in terms of books, community, other code
>>>> examples, etc. to learn how to follow rails conventions really well. Going
>>>> for the Objects on rails approach forces you into making many more, harder,
>>>> decisions - what is the scope for these decisions to be made poorly?
>>>> Appealing to authority, I seem to remember in the Domain Driven Design
>>>> book, Eric Evans advising that you shouldn't try and apply DDD if the
>>>> modelling skill in your team isn't high.
>>>>
>>>
>>> I think this is key.  If you build a standard rails app you are in very
>>> real terms "on rails"; there's a single approach you can take to build the
>>> app and you don't really have to think much as there's so much What Has
>>> Gone Before wisdom out there.  If you take the OO / Hexagonal approach
>>> pretty much everything you do is going to require A Decision About
>>> Something New.  Like Roland, I don't think that's a bad thing, but I do
>>> worry that it means it's easier to make poor decisions.
>>>
>>> There's lots of people saying "Hey, you should totes do stuff this new
>>> way. Maintainability FTW!" but not a lot of "and here is how. WOO!".  Maybe
>>> someone can prove me wrong though; do you know of any good, real-world,
>>> examples to look at?
>>>
>>> [aside: Objects on rails is good but, as someone already said, it
>>> describes a toy app and it's hard to extrapolate upwards to the complexity
>>> we'd really face.  The songkick tech blog series[0] about their approach to
>>> splitting an app into services is also good.  I want more.]
>>>
>>> It occurs to me that I have a bunch of tools to hand for refactoring
>>> single objects (extract method, identify and extract collaborators, etc).
>>>  Handily these tools can be applied to the problem in my brain before I
>>> even start writing the code, so I can knock up something reasonable at
>>> first pass without the refactoring step.
>>>
>>> What I don't really feel like I have a similar set of tools for doing
>>> this across a whole app.  Unless, maybe I do?  Is it just the same thing,
>>> applied macroscopically?  Does it even make sense to think in terms of
>>> red-green-refactor across a whole app architecture?
>>>
>>> Ideally I want someone who has done both:
>>>
>>> a) starting a new app and doing it using pure OO / Hexagonal approaches
>>>
>>> and
>>>
>>> b) refactoring a standard rails monolith down into a more service-y
>>> many-apps architecture
>>>
>>> to come an tell me (us) what it's like and which is easier.  Also
>>> explain what pitfalls there are (for example I imagine one obvious one is
>>> chopping it into the wrong services too early), and what patterns there are
>>> for spotting obvious things.
>>>
>>> Anyone?
>>>
>>> Muz
>>>
>>> [0] http://devblog.songkick.com/2012/07/27/service-oriented-songkick/ -
>>> I think that's the first of 3 articles; I'm sure a Songkicker will let us
>>> know if I'm wrong ;)
>>>
>>
>>
>> _______________________________________________
>> 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/79998e3a/attachment-0003.html>