[LRUG] Evaluating Hexagonal/SOLID Principles in Rails

Tue Jun 19 09:04:34 PDT 2012

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20120619/9a98ccbb/attachment.html>