[LRUG] Objects and on Hexagonal Rails

[Roland Swingler]

> On the refactoring theme, there's also the Bowkett book, Unfuck a
Monorail. Has anyone read that?

Yes, and in my view it is terrible. If you want to spend $40 on what is
basically "How Giles uses grep", a poor summary of various Destroy all
Software screencasts combined with a lot of cut-and-paste rantings from his
blog, go for it...

R


On Tue, Jul 23, 2013 at 9:25 PM, 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/20130724/30491d70/attachment.html>