Rails - Jan 2006 - DHH''s dislike of high level components

On 1/5/06, David Heinemeier Hansson wrote:
>
> The lure of components is directly proportional with the pain of
development.
I''m not trying to be abrasive in any way but I''m curious if
this
attitude is related to the number of rails apps David maintains. No I
don''t know how many login systems David maintains. I can understand
avoiding components if a person only has one application to maintain.
Maybe a lot of us are still missing something?

Peter

Configuring an existing login system takes longer than creating a new 
one (since you''ll have to look everything up), and what if your
existing
login system turns out to be not configurable enough?

I think engines solve most of these problems:
http://rails-engines.org/

You can override everything in Ruby-code.

But I still think that things like calendar-components could be handy 
sometimes.


Jules

-- 
Posted via http://www.ruby-forum.com/.

Jules wrote:
> Configuring an existing login system takes longer than creating a new 
> one (since you''ll have to look everything up), and what if your
existing
> login system turns out to be not configurable enough?
> 
> I think engines solve most of these problems:
> http://rails-engines.org/
> 
> You can override everything in Ruby-code.
> 
> But I still think that things like calendar-components could be handy 
> sometimes.
> 
> 
> Jules
While I understand DHH''s position on this, I think there is a fair 
amount of ''pain of development'' involved in putting together a
good
login system.  The stakes are also pretty high if you screw it up.

There are only a few things that lend themselves well to 
''components/engines''.  I think a login system is one of them.

One of the things I really like about the ''engines'' is that it
is pretty
easy to customize/extend them once you have them running.  In my mind 
they are sort of like scaffolds on steroids.  As a developer, you would 
do well to review/replace them according to your needs, but they do give 
you the framework to get up and running quickly.

_Kevin

-- 
Posted via http://www.ruby-forum.com/.

While I think the statement is a platitude, I can give you a good  
indication of *my* problem with massively componentized architectures:

http://www.ibiblio.org/maven/

That''s a lot of components, and all of them are very different in  
their usability, documentation levels, and how they''re integrated.   
Throw in that some use 1.4 java, some use 1.5 (or is that 3 or 2 or 5  
I can never figure it out), and many of them require conflicting  
versions of various other jars.  A classic example is Log4J.  One  
project will use Log4J 1.2.8 another uses 1.2.13 and somehow also  
uses the latest feature, so you get screwed when they both try to  
load the classes and the class loader (that someone decided to  
rewrite 20 times for extra confusion) blows up in your face.  Even  
worse if you used older JBoss that used the same log4j classes, but  
just moved them to a different package so you got weird class loader  
conflicts (and rewrote the class loader 20 times for extra confusion).

That''s just my opinion as to why components haven''t work as
well as
advertised in practice.  I think the windows world has a much better  
component strategy simply because of the standards they enforce, but  
even there you have similar problems.

I would actually say, it''s not so much the components, but the way  
most componentized architectures don''t enforce an integration  
standard.  You can have tons of components as long as there''s a  
standard about how they''re documented, written, used, and  
distributed.  But none of that solves the problem of interlocking  
dependencies.  Nobody''s got a solution to that I believe.

Zed A. Shaw
http://www.zedshaw.com/


On Jan 15, 2006, at 12:32 PM, Peter Michaux wrote:
> On 1/5/06, David Heinemeier Hansson wrote:
>>
>> The lure of components is directly proportional with the pain of  
>> development.
>
> I''m not trying to be abrasive in any way but I''m curious
if this
> attitude is related to the number of rails apps David maintains. No I
> don''t know how many login systems David maintains. I can
understand
> avoiding components if a person only has one application to maintain.
> Maybe a lot of us are still missing something?
>
> Peter
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

Am 15.01.2006 um 20:23 schrieb Zed Shaw:
> I would actually say, it''s not so much the components, but the way
> most componentized architectures don''t enforce an integration  
> standard.  You can have tons of components as long as there''s a  
> standard about how they''re documented, written, used, and  
> distributed.  But none of that solves the problem of interlocking  
> dependencies.  Nobody''s got a solution to that I believe.
I can only agree here: The problem with component dependencies is one  
you cannot solve without having control over all components.

However, rewriting everything from scratch, having a component in  
source code and applying updates and security patches on top of your  
code (as is the case with the Generator approach) all have their own  
drawbacks.

IMO this is one of the principles of complex systems: Every  
sufficiently interestingly complex system bears the seed of havoc and  
problems.

Regards

Manuel Holtgrewe

> I''m not trying to be abrasive in any way but I''m curious
if this
> attitude is related to the number of rails apps David maintains. No I
> don''t know how many login systems David maintains. I can
understand
> avoiding components if a person only has one application to maintain.
> Maybe a lot of us are still missing something?
37signals has four applications in production and two in development.
They all have different login systems. Some more similar than others,
but all sufficiently different for components to work well (meaning
less effort and higher cohesion than starting from scratch every
time).

But that''s just us. If you find that you''re repeating exactly
the same
login system over and over again, you''d be a fool not to abstract. I
don''t have any problem with that. But this is about intra-company
sharing. Once you start thinking that your login system is a good
model for the world at large, that''s when the trouble begins.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework

Whether or not it''s possible (or desirable) to create a
''general'' set
of high-level components which will happily integrate in a way that
satifies an acceptable proportion of developers, I think at the very
least it''s always going to be useful to have tools which enable
developers to create subsystems which they, personally or within their
team, can reuse in later projects. In this case, the problem of
ensuring interoperability lies squarely at the foot of the
developer(s) themselves, which is almost certainly where it should be.

Even when made public, the responsibility for integrating those
solutions with their own application again lies with the application
developer. This is surely an inversion of responsibility compared to
heavily-component-based frameworks.

On 1/15/06, Zed Shaw <zedshaw@zedshaw.com> wrote:
> While I think the statement is a platitude, I can give you a good
> indication of *my* problem with massively componentized architectures:
>
> http://www.ibiblio.org/maven/
>
> That''s a lot of components, and all of them are very different in
> their usability, documentation levels, and how they''re integrated.
> Throw in that some use 1.4 java, some use 1.5 (or is that 3 or 2 or 5
> I can never figure it out), and many of them require conflicting
> versions of various other jars.  A classic example is Log4J.  One
> project will use Log4J 1.2.8 another uses 1.2.13 and somehow also
> uses the latest feature, so you get screwed when they both try to
> load the classes and the class loader (that someone decided to
> rewrite 20 times for extra confusion) blows up in your face.  Even
> worse if you used older JBoss that used the same log4j classes, but
> just moved them to a different package so you got weird class loader
> conflicts (and rewrote the class loader 20 times for extra confusion).
>
> That''s just my opinion as to why components haven''t work
as well as
> advertised in practice.  I think the windows world has a much better
> component strategy simply because of the standards they enforce, but
> even there you have similar problems.
>
> I would actually say, it''s not so much the components, but the way
> most componentized architectures don''t enforce an integration
> standard.  You can have tons of components as long as there''s a
> standard about how they''re documented, written, used, and
> distributed.  But none of that solves the problem of interlocking
> dependencies.  Nobody''s got a solution to that I believe.
>
> Zed A. Shaw
> http://www.zedshaw.com/
>
>
> On Jan 15, 2006, at 12:32 PM, Peter Michaux wrote:
>
> > On 1/5/06, David Heinemeier Hansson wrote:
> >>
> >> The lure of components is directly proportional with the pain of
> >> development.
> >
> > I''m not trying to be abrasive in any way but I''m
curious if this
> > attitude is related to the number of rails apps David maintains. No I
> > don''t know how many login systems David maintains. I can
understand
> > avoiding components if a person only has one application to maintain.
> > Maybe a lot of us are still missing something?
> >
> > Peter
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Zed Shaw wrote:
> I would actually say, it''s not so much the components, but the way
most
> componentized architectures don''t enforce an integration standard.
You
> can have tons of components as long as there''s a standard about
how
> they''re documented, written, used, and distributed.  
I went to the London Web Frameworks night, back in November, and was 
very impressed by the way that Catalyst (Perl) [1] provides a framework 
that allows different options for architectural components (renderers, 
authenticators, persistence etc.) to be plugged together.

I hope someone will do the same in Ruby.

regards

   Justin

[1] http://catalyst.perl.org/

On 1/18/06, Justin Forder <justin@justinforder.me.uk>
wrote:
> I went to the London Web Frameworks night, back in November, and was
> very impressed by the way that Catalyst (Perl) [1] provides a framework
> that allows different options for architectural components (renderers,
> authenticators, persistence etc.) to be plugged together.
Actually, my impression of Catalyst from that very same presentation
was "... where on earth do I start?!" It seemed like you could chop
and change so many parts of the framework that it was difficult to
know what was even a sensible combination without steeping yourself in
the deep, deep waters of CPAN. One of the advantages of Rails over
that approach, IMHO, is that it provides everything you need. If you
want a different ORM layer or renderer, such things are certainly
possible, but you don''t have to assemble it all like a kit if you
don''t want.

Using Catalyst struck me as being a microcosm parallel to building
your own Linux distro. Eeek! Perhaps a better analogy would be
building your own PC vs. buyng a Mac. I used to build my own PCs, but
now I wouldn''t have a clue which GFX card (read: view renderer) or ATA
standard (read: ORM layer) is any good anymore; my Powerbook just
*works*.

That said, i know nothing of the Perl library, and if you knew the
dark incantations necessary to summon your carefully-chosen demons
from the CPAN realm, then I can imagine there''s a certain pleasure in
that.

It also might be worth noting that the components we were talking
about in this particular thread where application-level, rather than
framework level...

- james

James Adam wrote:
> On 1/18/06, Justin Forder <justin@justinforder.me.uk> wrote:
>> I went to the London Web Frameworks night, back in November, and was
>> very impressed by the way that Catalyst (Perl) [1] provides a framework
>> that allows different options for architectural components (renderers,
>> authenticators, persistence etc.) to be plugged together.
> 
> Actually, my impression of Catalyst from that very same presentation
> was "... where on earth do I start?!" It seemed like you could
chop
> and change so many parts of the framework that it was difficult to
> know what was even a sensible combination without steeping yourself in
> the deep, deep waters of CPAN. One of the advantages of Rails over
> that approach, IMHO, is that it provides everything you need. If you
> want a different ORM layer or renderer, such things are certainly
> possible, but you don''t have to assemble it all like a kit if you
> don''t want.
> 
> Using Catalyst struck me as being a microcosm parallel to building
> your own Linux distro. Eeek! Perhaps a better analogy would be
> building your own PC vs. buyng a Mac. I used to build my own PCs, but
> now I wouldn''t have a clue which GFX card (read: view renderer) or
ATA
> standard (read: ORM layer) is any good anymore; my Powerbook just
> *works*.
I think it''s a bit more remarkable than that. The parts for a PC
conform
to interfaces which are understood across an industry, whereas my 
impression is that Catalyst allows integration of components that were 
defined in the absence of agreed interfaces.

So far as the choice is concerned, if all you have is Catalyst and CPAN, 
then you are right, but that combination provides an opportunity for 
other people to provide the ''distro''. I don''t know if
that''s happening
with Catalyst, but AppFuse is an example in the Java world. (And the 
need to choose is a big difference between the Java world and the .NET 
world.)
> That said, i know nothing of the Perl library, and if you knew the
> dark incantations necessary to summon your carefully-chosen demons
> from the CPAN realm, then I can imagine there''s a certain pleasure
in
> that.
I imagine so - I''m not a Perl hacker myself. I would like a web 
application framework with the expressiveness of Rails and a lot more 
pluggability of components. I am only using Rails for prototyping at the 
moment - most of what my customers need is a little way off the Rails 
''golden path''. I''m looking forward to when JRuby both
performs well and
has all the functionality required by Rails.
> It also might be worth noting that the components we were talking
> about in this particular thread where application-level, rather than
> framework level...
Well, there''s a lot of stuff that DHH considers to be application-level
that I am used to seeing architectural support for, so I don''t think 
that there is a hard distinction there. The application/architecture 
boundary is pretty context-dependent (where context includes people and 
organisation structure, as well as business requirements - it''s a 
well-known observation that architectures reflect the structure of the 
organisations that produced them).

Catalyst has pluggable support for authentication and authorisation, 
which is stuff that DHH regards as inappropriate for the core of Rails. 
I''d like Rails to take the same approach as Catalyst - define the 
plug-in points, and let other people provide the options to plug in.

Thanks for an interesting reply - I''ve had to think quite a lot while 
responding, and have thrown away as much text as I ended up with.

   Justin

P.S. Have you watched the Snakes and Rubies videos? It''s well worth it.