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. > > > JulesWhile 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
David Heinemeier Hansson
2006-Jan-16 00:47 UTC
[Rails] DHH''s dislike of high level components
> 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.