[LRUG] Dependency Injection and DHH

[Guy Boertje]

My take on the DHH keynote is that he is speaking up for the people who use
Rails incidentally.  For example, the IT manager needing a web app, might
have used PHP, now turns to Rails.  They would read some docs and get
cracking; they may not be aware of git or github, TDD, SOLID or what a
dependency is.  We, who use Rails, to build non-trivial apps, discuss these
issues, make decisions, change our minds and act accordingly. I'm reminded
of Dreyfus http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition.

My 2p
Guy


On Mon, Apr 28, 2014 at 10:39 AM, Najaf Ali <ali at happybearsoftware.com>wrote:

> +1x10^gazillion, The next time the topic of TDD comes up, I'm just going
> to copy-paste this email. It's all I have to say on the topic and I don't
> disagree with a single word :)
>
>
> On Mon, Apr 28, 2014 at 10:30 AM, Gabe da Silveira <gabe at websaviour.com>wrote:
>
>> On Sun, Apr 27, 2014 at 8:15 AM, Anthony Green <
>> anthony.charles.green at gmail.com> wrote:
>>
>>>
>>> These kind of missives have a tendency to devolve to flame bait. TDD
>>> goes through the same cyclical exchanges.
>>> And this continues despite the 'TDD - Thats not what we meant'
>>>  interventions.
>>> As I get older I have an increasing desire to move on and focus on
>>> exchanges that help me improve on the disciplines I've chosen to believe
>>> will help me produce better software.
>>>
>>
>> To be fair, flame bait is one of DHH's prime MOs. His goal isn't nuanced
>> discourse, as evidenced by his conflation of computer science with serious
>> software engineering in the keynote.  That said, I appreciate his challenge
>> of TDD and architecture astronautism simply as a counterpoint to prevailing
>> ideologies which, in the absence of push back, have a tendency to be cargo
>> culted mercilessly.
>>
>> On the one hand, I think DHH's critiques of techniques for separating
>> persistence and business model concerns are pretty weak since his entire
>> career is based on controlling his own domain and keeping it dead simple.
>>  It's easy for him to shoot down the need for any more complex architecture
>> because any small example for the sake of discussion is necessarily reduced
>> below the scope where such structure is necessary.  But on the other hand,
>> I couldn't agree more that TDD/BDD do not lead to better designs—they lead
>> to better tests, and good tests are just one metric of a good codebase.
>>  Ruby, of course, requires good tests to have any reliability over time
>> whatsoever, but we shouldn't forget that tests are still ancillary.  Being
>> testable is only a small fraction of what makes a given architecture good.
>>
>> -gabe
>>
>> _______________________________________________
>> 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/20140428/9da96f4f/attachment-0003.html>