Hi,<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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. </div>
<div><br></div><div>I should know, I came to Rails from .Net and I remember when <a href="http://ASP.NET">ASP.NET</a> 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).</div>
<div><br></div><div>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.<br><br>Regards,</div>
<div><br></div><div>Artan<br><br><div class="gmail_quote">On 19 June 2012 14:33, David Burrows <span dir="ltr"><<a href="mailto:david@designsuperbuild.com" target="_blank">david@designsuperbuild.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Hi Paul,</div><div><br></div><div>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. </div>

<div><br></div><div>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. </div>

<div><br></div><div>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.</div>

<div><br></div><div>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"</div>

<div><br></div><div>Anyway, it's been bouncing round my head for a few days, LRUG can feel free to tell me why it'd never work ;)</div><div><br></div><div>Cheers,</div><div>David</div><span class="HOEnZb"><font color="#888888"><div>
<br></div></font></span><div><span class="HOEnZb"><font color="#888888"><div>-- </div>
<div>David Burrows</div><div>079 1234 2125</div><div>@dburrows</div><div><br></div><div><a href="http://www.designsuperbuild.com/" target="_blank">http://www.designsuperbuild.com/</a> | @dsgnsprbld</div></font></span><div>
<div class="h5"><br>
<br><br><div class="gmail_quote">On Tue, Jun 19, 2012 at 11:35 AM, Steve Tooke <span dir="ltr"><<a href="mailto:steve.tooke@gmail.com" target="_blank">steve.tooke@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi Paul,<br>
<div><br>
On Tue, Jun 19, 2012 at 10:08 AM, Paul Mucur <<a href="mailto:mudge@mudge.name" target="_blank">mudge@mudge.name</a>> wrote:<br>
</div><div>> maybe we do need<br>
> to prove that code after redesign/refactor is *measurably* better than<br>
> the old. I fear that simply stating "it's more maintainable" without<br>
> demonstrating the fact is too vague and can be dismissed, as DHH puts<br>
> it, as "fortune telling".<br>
<br>
</div>I'm not sure we can find a metric, as 'maintainability' is function of<br>
the cost to modify the existing behaviour of the application, and I<br>
think that is an estimate based on the state of the code now.<br>
<br>
I wonder if its worth looking at this another way. I recently read a<br>
post [1] by J.B. Rainsberger which explains how TDD works using the<br>
theory of constraints, in particular queuing theory. He takes this<br>
idea:<br>
<br>
"Given a process B, which follows a process A, sometimes in performing<br>
B we need to perform some of A again. We can remove the need to rework<br>
by taking some portion of process B and performing it before process<br>
A."<br>
<br>
In the post he uses this idea to pull Analyis, Testing, Coding and<br>
Design in to a tight feedback loop, and he describes this as Behaviour<br>
Driven Development.<br>
<br>
The important thing is where design sits in this loop - after<br>
coding... or before you start adding the next feature. This is because<br>
"we can remove the need to rework by taking some portion of process B<br>
and performing it before process A." So by cleaning up our design,<br>
after we code it - and before we start adding more features, we should<br>
make adding new features easier.<br>
<br>
Unfortunately because this is software we don't have much in the way<br>
of studies to back up this claim, but we do have our own experiences.<br>
How much quicker does it feel to add behaviour to a system which is<br>
loosely coupled - where there are clear seams to add new behaviour?<br>
<div><br>
> Don't misunderstand me: I believe that separating your application's<br>
> core logic from your particular framework is a Good Thing but I feel<br>
> like we need more worked examples exploring the realities of creating<br>
> applications in this style such as James Hunt's recent "Building a<br>
> Rails app without Rails" [4].<br>
<br>
</div>I totally agree - I'm looking forward to see how James' and Roland's<br>
approach works!<br>
<div><br>
> I grow increasingly convinced that these principles are not something<br>
> that Rails or even Objectify can help us with as the key is to change<br>
> how we should build and design our applications *regardless of<br>
> framework*. This is particularly evident to me having co-authored<br>
> Proffer [5] which was an attempt to mitigate a bad practice with<br>
> tools. Perhaps the best thing we can do as a community is not to<br>
> constrain with software but to focus on *education* and examples?<br>
<br>
</div>Yes! Build your application in a way that lets you really focus on<br>
delivering the behaviour you need. Use the frameworks to support you,<br>
to make things easier in the areas that they are good at - but don't<br>
put them at the heart of your application.<br>
<br>
[1] <a href="http://www.jbrains.ca/permalink/how-test-driven-development-works-and-more" target="_blank">http://www.jbrains.ca/permalink/how-test-driven-development-works-and-more</a><br>
<span><font color="#888888"><br>
--<br>
/tooky<br>
</font></span><div><div>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</div></div></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div>