[LRUG] Evaluating Hexagonal/SOLID Principles in Rails

[Paul Mucur]

Just to pull in something from Twitter, James Martin (@jmrtn) pointed
me at Gary Bernhardt's "Sucks/Rocks" Rails application as an exemplar:
https://github.com/garybernhardt/sucks-rocks

It's also worth noting that the creation of the above application is
detailed in the following Destroy All Software screencasts:

1. https://www.destroyallsoftware.com/screencasts/catalog/sucks-rocks-1-the-rails-app
2. https://www.destroyallsoftware.com/screencasts/catalog/sucks-rocks-2-computing-scores
3. https://www.destroyallsoftware.com/screencasts/catalog/sucks-rocks-3-the-search-engine
4. https://www.destroyallsoftware.com/screencasts/catalog/sucks-rocks-4-caching
5. https://www.destroyallsoftware.com/screencasts/catalog/sucks-rocks-5-a-bug-and-a-model
6. https://www.destroyallsoftware.com/screencasts/catalog/sucks-rocks-6-a-controller
7. https://www.destroyallsoftware.com/screencasts/catalog/sucks-rocks-7-more-cucumber
8. https://www.destroyallsoftware.com/screencasts/catalog/sucks-rocks-8-the-whole-design

On Tue, Jun 19, 2012 at 5:04 PM, Artan Sinani <artisinani at gmail.com> wrote:
> Hi,
>
> I have followed with lots of interest the debate of Rails and its object
> orientation (or lack of). In fact I couldn't wait to hear what DHH had to
> say about it. And he didn't disappoint.
>
> For me Rails is the best effort of making web development as object oriented
> as possible, don't forget that it was the framework that had separation of
> concerns built in from day one. There was (and still is) a lot of code out
> there, written in all sorts of languages, which had the database
> interaction, logic and views in the same file.
>
> I also liked the OoR book, especially how the writer took us in all this
> long journey, to build something that you can build with a scaffold
> generator in Rails. And that is one of the points of RoR (or any framework
> for that matter): making the trivial decisions for you. I think he confirmed
> RoR once more.
>
> I have noticed that many people don't take DHH's words about the beauty of
> code seriously; they think the beauty of code written in ruby is a side
> effect, but not central to us using it. I think they're forget why they
> chose Rails and Ruby in the first place. Writing beautiful code is one of
> the main reasons we use Ruby, right? And having a class per controller
> action is no way beautiful.
>
> I should know, I came to Rails from .Net and I remember when ASP.NET MVC was
> trying to copy Rails, but was doing it so wrong... Strangely, I can see some
> .Net (Java) patterns being introduced to Rails (services, repositories).
>
> Please understand, I'm not against Rails improvements. I also think that
> Rails faces one of its biggest challenges: where and how does it fit in the
> rich client-side applications era.
>
> Regards,
>
> Artan
>
>
> On 19 June 2012 14:33, David Burrows <david at designsuperbuild.com> wrote:
>>
>> Hi Paul,
>>
>> I listened to the DHH Rogues podcast lately and had exactly the same
>> response, especially having recently gone through the Objects on Rails book.
>> Some of the implementation in the OoR book had such a high overhead it was
>> hard to believe that they the time was ever going to be paid back. "Better"
>> is highly subjective but did get me thinking whether we could create tests
>> for different rails app architectures.
>>
>> The idea would be to use the different approaches that are being put
>> forward to build a slightly-more-than-trivial base app (hopefully not
>> another bloody blog engine) then add a series of features to it that
>> traditionally cause problems in implementation - things like authentication,
>> authorisation, social network integration, persistence backend change etc.
>>
>> After each feature is added you'd generate some metrics (how many lines of
>> code are written/re-written to implement each feature, etc.) then move on to
>> the next one. As long as you implement a decent amount of features it should
>> become apparent which approaches are keeping complexity down.
>>
>> Having mulled it over in my head there's obviously a few issues with the
>> idea, the main one being that everyone would argue about the
>> implementations. I imagine you could solve that by taking pull requests to
>> the individual approaches repos - you'd hopefully arrive at an
>> implementation everyone would be happy with, rather like the re-writes of
>> benchmarks that always occur whenever a blog post says "X language is 10
>> times slower that Y"
>>
>> Anyway, it's been bouncing round my head for a few days, LRUG can feel
>> free to tell me why it'd never work ;)
>>
>> Cheers,
>> David
>>
>> --
>> David Burrows
>> 079 1234 2125
>> @dburrows
>>
>> http://www.designsuperbuild.com/ | @dsgnsprbld
>>
>>
>>
>> On Tue, Jun 19, 2012 at 11:35 AM, Steve Tooke <steve.tooke at gmail.com>
>> wrote:
>>>
>>> Hi Paul,
>>>
>>> On Tue, Jun 19, 2012 at 10:08 AM, Paul Mucur <mudge at mudge.name> wrote:
>>> > maybe we do need
>>> > to prove that code after redesign/refactor is *measurably* better than
>>> > the old. I fear that simply stating "it's more maintainable" without
>>> > demonstrating the fact is too vague and can be dismissed, as DHH puts
>>> > it, as "fortune telling".
>>>
>>> I'm not sure we can find a metric, as 'maintainability' is function of
>>> the cost to modify the existing behaviour of the application, and I
>>> think that is an estimate based on the state of the code now.
>>>
>>> I wonder if its worth looking at this another way. I recently read a
>>> post [1] by J.B. Rainsberger which explains how TDD works using the
>>> theory of constraints, in particular queuing theory. He takes this
>>> idea:
>>>
>>> "Given a process B, which follows a process A, sometimes in performing
>>> B we need to perform some of A again. We can remove the need to rework
>>> by taking some portion of process B and performing it before process
>>> A."
>>>
>>> In the post he uses this idea to pull Analyis, Testing, Coding and
>>> Design in to a tight feedback loop, and he describes this as Behaviour
>>> Driven Development.
>>>
>>> The important thing is where design sits in this loop - after
>>> coding... or before you start adding the next feature. This is because
>>> "we can remove the need to rework by taking some portion of process B
>>> and performing it before process A." So by cleaning up our design,
>>> after we code it - and before we start adding more features, we should
>>> make adding new features easier.
>>>
>>> Unfortunately because this is software we don't have much in the way
>>> of studies to back up this claim, but we do have our own experiences.
>>> How much quicker does it feel to add behaviour to a system which is
>>> loosely coupled - where there are clear seams to add new behaviour?
>>>
>>> > Don't misunderstand me: I believe that separating your application's
>>> > core logic from your particular framework is a Good Thing but I feel
>>> > like we need more worked examples exploring the realities of creating
>>> > applications in this style such as James Hunt's recent "Building a
>>> > Rails app without Rails" [4].
>>>
>>> I totally agree - I'm looking forward to see how James' and Roland's
>>> approach works!
>>>
>>> > I grow increasingly convinced that these principles are not something
>>> > that Rails or even Objectify can help us with as the key is to change
>>> > how we should build and design our applications *regardless of
>>> > framework*. This is particularly evident to me having co-authored
>>> > Proffer [5] which was an attempt to mitigate a bad practice with
>>> > tools. Perhaps the best thing we can do as a community is not to
>>> > constrain with software but to focus on *education* and examples?
>>>
>>> Yes! Build your application in a way that lets you really focus on
>>> delivering the behaviour you need. Use the frameworks to support you,
>>> to make things easier in the areas that they are good at - but don't
>>> put them at the heart of your application.
>>>
>>> [1]
>>> http://www.jbrains.ca/permalink/how-test-driven-development-works-and-more
>>>
>>> --
>>> /tooky
>>> _______________________________________________
>>> Chat mailing list
>>> Chat at lists.lrug.org
>>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>>
>>
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>