Ruby on Rails and J2EE technical comparison

Home

News: Ruby on Rails and J2EE technical comparison

  1. Aaron Rustad published a technical, hype-free comparison of Rails and the typical J2EE webapp stack, looking at how the frameworks compare, including MVC and persistence.
    While Ruby on Rails is a very new and exciting framework that has generated considerable interest in the Web development community, the core architecture follows the basic patterns found in J2EE. It's the philosophical approach to development of Web applications that sets the two frameworks apart. Rails prefers explicit code instead of configuration files, and the dynamic nature of the Ruby language generates much of the plumbing code at runtime. Most of the Rails framework has been created as a single project and application development benefits from a set of homogeneous components. In contrast, the typical J2EE stack tends to be built from best-of-breed components that are usually developed independently of one another, and XML is often used for configuration and gluing the components together.

    Threaded Messages (169)

  2. Oh Great....[ Go to top ]

    More Rails vs J2EE crap.

    I have not see a post from Vic in a while, or the rest of the "Java is Dead" crowd. I guess it is fun to heard from them every once in a while....... NOT.
  3. Oh Great....[ Go to top ]

    More Rails vs J2EE crap. I have not see a post from Vic in a while, or the rest of the "Java is Dead" crowd.

    Like this one:
    http://forums.java.net/jive/thread.jspa?forumID=25&threadID=315&messageID=9214
    that resulted in patches that make it easy to deploy JDK in 1.5.0.x? You are wellcome ;-)
    http://weblogs.java.net/blog/stanleyh/archive/2005/04/deployment_good_1.html

    I deployed quite a few huge sites for someone that is "anti-java".
    ex:http://www.theserverside.com/articles/article.tss?l=RiA

    Java != Sun.
    IBM SWT + Apache (iBatis, Harmony, Jakarta) + Groovy/Grails + WebStart I think is good combo, we'll see which one wins out. My guess is that IBM + Apache keep their dominant market share. SWT works out better on Mac then JDIC for example. You have seen that they are puting Rino in Mustang. So now how to deploy J2SE? Look at Flash 8 deployment for example:
    http://www.macromedia.com/software/flashplayer/public_beta
    (yes you can do apps in it http://www.macromedia.com/software/flash/productinfo/features/static_tour/data )


    .V
  4. Oh Great....[ Go to top ]

    Hi Vic! I knew this thread would turn to flames, so I thought I would spray some lighter fluid on it ;) Good to hear from you.
  5. Oh Great....[ Go to top ]

    Java != Sun.IBM SWT + Apache (iBatis, Harmony, Jakarta) + Groovy/Grails + WebStart I think is good combo, we'll see which one wins out. My guess is that IBM + Apache keep their dominant market share. SWT works out better on Mac then JDIC for example. .V

    And we all know that *everyone* is writing their apps in Groovy and iBatis ;)
    Groovy code always looks very professional - escpecially since all the Strings are named GString.

    You make it sound like IBM and Apache are a single organisation. Using your logic SCO and Apache would have a dominant marketshare.

    Your anti-Sun rants are really amusing some days. What happened to Mac servers running PPC? Apple is abandoning POWER for x86.
  6. Oh Great....[ Go to top ]

    More Rails vs J2EE crap. I have not see a post from Vic in a while, or the rest of the "Java is Dead" crowd.

    Like this one:
    http://forums.java.net/jive/thread.jspa?forumID=25&threadID=315&messageID=9214
    that resulted in patches that make it easy to deploy JDK in 1.5.0.x? You are wellcome ;-)
    http://weblogs.java.net/blog/stanleyh/archive/2005/04/deployment_good_1.html

    I deployed quite a few huge sites for someone that is "anti-java".
    ex:http://www.theserverside.com/articles/article.tss?l=RiA

    Java != Sun.
    IBM SWT + Apache (iBatis, Harmony, Jakarta) + Groovy/Grails + WebStart I think is good combo, we'll see which one wins out. My guess is that IBM + Apache keep their dominant market share. SWT works out better on Mac then JDIC for example. You have seen that they are puting Rino in Mustang. So now how to deploy J2SE? Look at Flash 8 deployment for example:
    http://www.macromedia.com/software/flashplayer/public_beta
    (yes you can do apps in it http://www.macromedia.com/software/flash/productinfo/features/static_tour/data )
    if JRE gets heavy, will users deploy it?

    .V
  7. Oh Great....[ Go to top ]

    More Rails vs J2EE crap. I have not see a post from Vic in a while, or the rest of the "Java is Dead" crowd.
    Like this one:http://forums.java.net/jive/thread.jspa?forumID=25&threadID=315&messageID=9214that resulted in patches that make it easy to deploy JDK in 1.5.0.x? You are wellcome ;-) http://weblogs.java.net/blog/stanleyh/archive/2005/04/deployment_good_1.htmlI deployed quite a few huge sites for someone that is "anti-java".ex:http://www.theserverside.com/articles/article.tss?l=RiAJava != Sun.IBM SWT + Apache (iBatis, Harmony, Jakarta) + Groovy/Grails + WebStart I think is good combo, we'll see which one wins out. My guess is that IBM + Apache keep their dominant market share. SWT works out better on Mac then JDIC for example. You have seen that they are puting Rino in Mustang. So now how to deploy J2SE? Look at Flash 8 deployment for example:http://www.macromedia.com/software/flashplayer/public_beta(yes you can do apps in it http://www.macromedia.com/software/flash/productinfo/features/static_tour/data )if JRE gets heavy, will users deploy it?.V

    I actually think that will never happen. The industry and its users went through a paradigm shift in application development around the time of the dot com boom. We went from simple and easy to use web pages to complex user interfaces on the web that attempted to mimic the desktop environment.

    Some developers continue to believe that rich desktop UI's is the route to go, but now we are in the age of the web page. Your grandmother can use sites like amazon or ebay because the web has a very simple set of rules that guides users through using the app-- click and back button. Only the most complex applications would ever have the requirements for a desktop UI, and that is only with hopes that introducing rich functionality won't alienate or confuse users.

    Keep it simple. The page model and your back button wins.
  8. Oh Great....[ Go to top ]

    We went from simple and easy to use web pages to complex user interfaces on the web that attempted to mimic the desktop environment.
    The key word being attempted.
  9. Oh Great....[ Go to top ]

    SWT works out better on Mac then JDIC for example

    Perhaps, but not as good Swing in general on that platform.
  10. Oh Great....[ Go to top ]

    SWT works out better on Mac then JDIC for example
    Perhaps, but not as good Swing in general on that platform.

    To get an good idea of which is better on any platform, try a program writen in SWT and one in Swing.
    Ex: BlogBridge vs RSSOwl
    One is clearly better techincaly IMO, don't you think?

    As far as IBM+Apache comment... I suspect IBM is behind Harmony effort. Sun is about to make a huge mistake of making Mustang+Rino much larger JRE to download than 1.5. AFAIK IBM do not have another Java 1.5 for PPC effort. Eclipse is an interesting choice of name. And IBM has more market share in J2EE than Sun AFAIK.

    Code generators write more code that has to be maintained. And w/ Groovy we write less code, that is why it's an improvment, one should realy try to write something in it (and see why the big guys use similar, Google uses Python, and Groovy is Java based) I use jEdit for Groovy... and read the JavaDoc to know all possible way to solve a problem.


    .V
  11. Oh Great....[ Go to top ]

    To get an good idea of which is better on any platform, try a program writen in SWT and one in Swing.Ex: BlogBridge vs RSSOwlOne is clearly better techincaly IMO, don't you think?

    Both look like good apps. As for technical superiority, that has to be the Swing one (BlogBridge) - it is easier to install (a single click on a web page) and it looks better. It has a more consistent XP style that the mixture of native components and SWT widgets used in RSS Owl.
  12. Someone once said[ Go to top ]

    "I love the smell of napalm in the morning"

    let the flame war begin

    peter
  13. Who wouldn't want Rails-like macro capabilities in J2EE or Java for that matter? The trade off is that you are dealing with a new language (for most) and there's not as strong of a knowledge base and choice as there is with J2EE.

    Where J2EE will gain ground in 'rails' functionality is with EJB 3/Hibernate annotations and MVC Component frameworks. The idea that you can drop visual components onto the page that can interact with the complete request lifecycle in order to provide the same create/read/update/delete operations that Rails short circuits for you.

    Really, you could end up with pages like:

    <ejb:table
      query="from Employee e where e.dept = #{param.id}"
      editable="#{user.roles['admin']}"
      styleClass="tableStyle"
    />
  14. Who wouldn't want Rails-like macro capabilities in J2EE or Java for that matter? The trade off is that you are dealing with a new language (for most) and there's not as strong of a knowledge base and choice as there is with J2EE.Where J2EE will gain ground in 'rails' functionality is with EJB 3/Hibernate annotations and MVC Component frameworks. The idea that you can drop visual components onto the page that can interact with the complete request lifecycle in order to provide the same create/read/update/delete operations that Rails short circuits for you.Really, you could end up with pages like:<ejb:table&nbsp;&nbsp;query="from Employee e where e.dept = #{param.id}"&nbsp;&nbsp;editable="#{user.roles['admin']}"&nbsp;&nbsp;styleClass="tableStyle"/>

    Thats just great. I always like to use my database table design as a foundation on how my webpages are laid out. If thats the future you can keep it.
  15. Thats just great. I always like to use my database table design as a foundation on how my webpages are laid out. If thats the future you can keep it.

    You are missing the point... it's a matter of being able to scale complexity based on your needs. Which rails does a great job of.
  16. Thats just great. I always like to use my database table design as a foundation on how my webpages are laid out. If thats the future you can keep it.
    You are missing the point... it's a matter of being able to scale complexity based on your needs. Which rails does a great job of.

    Complexity comes in many forms, and one of them is oversimplification. Many langauges try to make it as easy as possible to implement bad ideas. People who want to easily implement bad ideas in Java can use Groovy. Maybe you should build a "Groovy on Rails".
  17. Great Quote[ Go to top ]

    Complexity comes in many forms, and one of them is oversimplification.
    I don't know if you came up with this quote, or if you are paraphrasing, but I think it's brilliant.

    I put it right up there with Einstein's, "Everything should be made as simple as possible, but no simpler.". Of course, that is a paraphrase of his actual words:
    The supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.
    That is not to suggest that Einstein didn't understand the effectiveness of a soundbite:
    The eternal mystery of the world is its comprehensibility.
    The hardest thing to understand in the world is the income tax.
  18. Thats just great. I always like to use my database table design as a foundation on how my webpages are laid out. If thats the future you can keep it.
    You are missing the point... it's a matter of being able to scale complexity based on your needs. Which rails does a great job of.

    Exactly! The whole point of rails is to take away most of the complexity that its usually found in the plumbing code, web frameworks, OR mappers, configuration managers, transactionality, etc. and let you develop the business logic that the application demands. Although rails is far less advanced than most state of the art Java frameworks, it implements some good design patterns in a clear and practical way, making developing easier.

    I haven't develop any real application in rails but I believe that if you need to enhance a rails application and evolve it to enterprise level, then you can be in trouble if the framework can't include advanced features just as easy as you create the standard CRUD application, but then again I have no experience in this. I don't usually use every feature of the tool but I like to know they are there for me.

    How about some new Java framework that uses some of the best tools we have ( Hibernate, Spring, Struts, etc.) but implements actions and controllers in a dynamic language like Groovy or Jython? Just a thought.

    Regards
  19. Without meaning to offend you, I think as long as something like Struts is being considered as some of 'the best tools we have', we're really prisoned into our very own soul.

    It rather seems like we can't even realize anymore how slow and ceremonius we are with everyday java development, even with the latest lightweight toolset available (which are lightyears-away from our old kit).
  20. Manolo
    How about some new Java framework that uses some of the best tools we have ( Hibernate, Spring, Struts, etc.) but implements actions and controllers in a dynamic language like Groovy or Jython? Just a thought.
    You don't need a new framework for this. We've had code in the Spring sandbox for about 9 months that does just that. I think there's merit in the idea. It allows polling of script files, so changes are near immediately picked up, and threadsafe. (Of course you can't change the interface incompatibly.) Script objects are exactly the same as any other named object: hidden behind a Spring bean definition. An IoC container is perfect for this. Spring's IoC capabilities are powerful enough to allow it to provide a component model that can span any language that works on the JVM. So you could use Groovy instead of Java without changing any other object. You can dependency inject script objects into other objects and you can dependency inject your scripts. You can also use Spring AOP to advise objects written in whatever scripting language, expose them for management using Spring JMX and do all the other cool stuff you would expect.

    However, there is a reason that this code hasn't made it into the Spring core, or into a separate supported release: the Spring community hasn't shown a great deal of interest in it. Which is interesting, and shows that there's a difference between what people think is cool, and what people actually want to use in real-world development. I think one of the showstoppers is the relative lack of IDE support for Groovy and other scripting languages. (Although that may well change, or be changing already.) Java may be more verbose for many things, but what percentage of our Java code do we actually type in any more?

    Anyway, if people want these features, we can deliver them: please speak up here or in the Spring forums!

    Rod Johnson
    Spring from the Source
  21. Rod & co. are doing the right thing by exploring simplification and dynamic languages, just as the Ruby on Rails guys are doing the right thing by enhancing their enterprise capabilities. They're intended to solve fundamentally different problems, though. RoR has a very narrow sweet spot, but it's an important one. If you've got flexibility to use a dynamic langauge, and you control your schema, RoR can be very productive...much more so than Java. But it doesn't do full-blown ORM, or two phased commit, and it doesn't have rich transaction/security/remoting customization.

    I do believe that RoR does have some critical steps forward in simplification, like the Ruby langauge, hook points and metaprogramming, conventions and defaults, the active record design pattern with inheritance and dynamic discovery of database fields. It's a productive environment for babysitting your own relational database with a web-based UI.

    Rod, do you think that the lack of interest may have something to do with Groovy, and not dynamic languages in general?
  22. Bruce
    Rod, do you think that the lack of interest may have something to do with Groovy, and not dynamic languages in general?
    Not sure. I haven't looked into JRuby, but I made an effort to design the dynamic language support so that it could support multiple languages. So hopefully it would be possible to support it. Maybe that would bring the hordes, given the attention Ruby's getting these days :-)

    Certainly one reason we couldn't release the scripting support was that we couldn't work with a final release of Groovy, and can't release core Spring features that work only with alpha or beta software.

    Rgds
    Rod
  23. Rod &amp; co. are doing the right thing by exploring simplification and dynamic languages, just as the Ruby on Rails guys are doing the right thing by enhancing their enterprise capabilities. They're intended to solve fundamentally different problems, though. RoR has a very narrow sweet spot, but it's an important one. If you've got flexibility to use a dynamic langauge, and you control your schema, RoR can be very productive...much more so than Java. But it doesn't do full-blown ORM, or two phased commit, and it doesn't have rich transaction/security/remoting customization.I do believe that RoR does have some critical steps forward in simplification, like the Ruby langauge, hook points and metaprogramming, conventions and defaults, the active record design pattern with inheritance and dynamic discovery of database fields. It's a productive environment for babysitting your own relational database with a web-based UI.Rod, do you think that the lack of interest may have something to do with Groovy, and not dynamic languages in general?

    I'm going to chime in. I think it is scripting languages in general. IMO, Ruby is just another in a long line of scripting languages that was going to display C, C++, and Java. It was going to be bash/csh, then tcl/tk, then perl, then php, then python, then groovy, and now ruby.

    What displaced C? C++. What displaced C++? Java. What will displace Java? Most likely another statically typed language. I've yet to see one compelling argument that was convincing that would make me want to try Ruby or any of the scripting languages. Prototype quickly? Well, I can prototype fairly quickly now, but when the prototype turns into a production system, it doesn't need to be re-written. I've seen that time and time again. We still have projects that are replacing MS Access/VB "throwaways". I worked on a project that had a core module that took two years to replace that was a proof of concept.

    Why not prototype something that has the legs to scale up? I was asked recently to rewrite a pretty basic search function for an existing legacy web app. The thing was a search parameter screen and a search results screen. Two pages. I did it using Struts, Spring, and Hibernate. It took me 8 days while working on my real assignment and mentoring a junior developer. Did I mention that most of that time was figuring out this heinous uber-view that was used join 12 tables and figuing out where dropdown list values were coming from?

    None of the silver bullet scripting languages would have significantly contributed to speeding this up. But now, I have a search, standalone, that is structured like some of our larger applications. If you can figure out the search, you understand its big brothers since it uses the same techniques and basic interfaces.

    With the scripting languages, you it is suggested that we hodgepodge different projects and the scripting flavor of the month because it can read DB tables without a mapping file? Exactly how much time is spent doing this?

    If you say that RoR has a narrow sweet spot, I say that is too much time to figure that out. Why not, instead, use a solution that scales up and down?
  24. I was asked recently to rewrite a pretty basic search function for an existing legacy web app. The thing was a search parameter screen and a search results screen. Two pages. I did it using Struts, Spring, and Hibernate. It took me 8 days while working on my real assignment and mentoring a junior developer. Did I mention that most of that time was figuring out this heinous uber-view that was used join 12 tables and figuing out where dropdown list values were coming from?

    I want to make one thing clear, the framework for this search, was one that I created for a previous assignment and it scaled down nicely. It took me a two days to pare it down, ie, throw away unnecessary stuff, rename classes to better represent the application, web pages, etc. 6 days were spent studying the database. And now, I'm handing off to another guy and he's expanding the functionality.

    Another prototype because a production.
  25. Why not, instead, use a solution that scales up and down?

    Apparently scaling up is way too old school and boring nowadays.

    Having your application permabonded to your database schema is whats hip with the kids these days. I guess its kind of like getting a piercing or something.
  26. Why not, instead, use a solution that scales up and down?
    Apparently scaling up is way too old school and boring nowadays.Having your application permabonded to your database schema is whats hip with the kids these days. I guess its kind of like getting a piercing or something.
    Luckily, I (as have many others) have realized that I already have enought holes in my head.
  27. Why not, instead, use a solution that scales up and down?

    Apparently scaling up is way too old school and boring nowadays.Having your application permabonded to your database schema is whats hip with the kids these days. I guess its kind of like getting a piercing or something.

    Luckily, I (as have many others) have realized that I already have enought holes in my head.

    There are other body parts that can be pierced ..

    Peace.
  28. Why not, instead, use a solution that scales up and down?
    Apparently scaling up is way too old school and boring nowadays.Having your application permabonded to your database schema is whats hip with the kids these days. I guess its kind of like getting a piercing or something.
    Luckily, I (as have many others) have realized that I already have enought holes in my head.
    There are other body parts that can be pierced ..Peace.
    True. But I have had "no more kids surgery" and I have no idea why anyone would want to pierce that area. And "purple nurples" are no fun so, again, piercing that area is not fun. So I think I'll settle for my current total body hole count. :)
  29. True. But I have had "no more kids surgery" and I have no idea why anyone would want to pierce that area. And "purple nurples" are no fun so, again, piercing that area is not fun. So I think I'll settle for my current total body hole count. :)

    This has to be one of the most off-topic posts in the history of TSS :)
  30. True. But I have had "no more kids surgery" and I have no idea why anyone would want to pierce that area. And "purple nurples" are no fun so, again, piercing that area is not fun. So I think I'll settle for my current total body hole count. :)
    This has to be one of the most off-topic posts in the history of TSS :)
    Well, if that is what it takes to get noticed.

    Oddly, though, it might be the most useful post in TSS history. :) I could post stuff like Vic and "he who must not be named" if you would like. :) ;)
  31. Well, if that is what it takes to get noticed. Oddly, though, it might be the most useful post in TSS history. :)

    Absolutely!
  32. Anyway, if people want these features, we can deliver them: please speak up here or in the Spring forums!

    Rod Johnson

    +1

    I'm definitely interested in seeing this.

    Carl-Eric
  33. Me, too, Me, too!

    Some personal opinions on the hype around ruby on rails which i'm trying out in my spare time and pretty much like:

    1. It's good for java to learn from dynamic languages. After learning ruby it's indeed painful to come back to java in some spaces: overly long getters and setters, private static final bla-bla, regex and so on. Ruby-code is often much more compact and readable along the way.

    2. RoR gives you a great headstart when you're beginning a small to mid-size project in a small team. Imagine a little clash between a couple of "hobby-programmers" (let's say VB or VBA but without java or ruby experience). One group of them gets a good book about a java web-framework of choice the other the agile web development with rails. Both get the hardware to work with and a fast internet connection. Then let both groups head the challenge of writing a little private movie database where they and their friends might review the last dvd-rips and read reviews of eachother because imdb is so unpersonal. Both groups will realize that they need to model reviewers (users), movies, comments and their relations. Who will get the job done first. I would place my bet on the RoR group. So what's got this to do with enterprise programming?
    - kids, hobby-programmers, non-programmers could well be the next 4.5 Million Java-Programmers (or python, ruby, whatever ones). Some of them might well be the next Fowlers, Becks, Gammas, Boochs etc.
    - simplification is a good thing, the base for something complex is often something simple (learning from nature anyone)
    - RAD impresses decision makers and makes them decide one way or the other

    3. David Heinemeier Hansson does a great job in evengalizing RoR. This guy seems to be a one man guerilla marketing machine of highest ability. He's fighting for "his" framework like none of the java guys. He's passionate and people listen to passion.

    4. Design counts. This applies to webdesign as well as to the beauty of code. Now compare some snippets of ruby to java. And more obvious: compare the logos and the whole page layout of http://www.rubyonrails.com and http://docs.codehaus.org/display/GROOVY/Grails. The royal nerdness of some java guys who don't care how awful the space they blog to looks, who can't enjoy the style of apple devices and like to search for jars longer than necessary don't look appealing at all to rest of mankind.

    5. And coming back to spring configuration. I love spring. But parts of the spring framework don't look sexy at all. Rod, it's great what you did for enterprise java. But for your own sake at interface21, learn from documentation and evangelization at RoR community. I'm pretty sure that most people just didn't know about integration of and improvements through dynamic languages, because they had no fun way (videos, whatever) to learn about it.

    Best regards
    Jan Prill
  34. learn from documentation and evangelization at RoR community.

    The trouble is that much of it seems to be evangalization about poor practices (database-driven design, script code embedded in web pages) that many of us have known about and rejected years ago. It is painful to see some of these ideas resurrected as if they are new and useful.

    It is certainly good for Java to learn from dynamic languages. Recent JSRs show this is happening. What is not good is when certain aspects of the way J2EE does things (such as XML configuration files) seem to be rejected as unncessary, and the lessons of years of enterprise development are forgotten, especially when the ways things are done can easily scale down as well as up. Who cares about what looks 'sexy'! It is about what works.

    And about speed - if you really want speed of development, why not use something like Java Studio Creator? With the visual design, robust J2EE applications can be put together in minutes. I don't use it myself, but if speed of development is an issue, it will do the job.
  35. The trouble is that much of it seems to be evangalization about poor practices (database-driven design, script code embedded in web pages) that many of us have known about and rejected years ago.

    Steve, I partly disagree. Yes, the view part in many examples of RoR documentation looks like a big step back. But you <strong>may</strong> achieve a good design on the view part - it's possible. RoR and Ruby are a lot about DRY and give you layouts, partials and components at hand. As long as you are able to overwrite everything (please have a look at: http://wiki.rubyonrails.com/rails/show/HowToUseLegacySchemas for example) I can't find anything bad about using database schemas as a headstart in RAD.
    Who cares about what looks 'sexy'!

    As I said: Mankind!!! You could answer that "sexy" is only what is working, but anyway, things that are working great but miss in marketing and design won't live as long as they could and should be.
    It is about what works. And about speed - if you really want speed of development, why not use something like Java Studio Creator? With the visual design, robust J2EE applications can be put together in minutes. I don't use it myself, but if speed of development is an issue, it will do the job.

    I did try both, RoR as well as the Studio Creator approach. I'll go for RoR in some projects and my own Java, Eclipse, Ant, Spring, Hibernate Development environment for others. I don't know what formed your opinion that RoR isn't flexible at all. In my opinion RoR is more flexible than the IDE-for-simplification approach. The Java environment could learn a hell lot of rails.

    Jan Prill
  36. ... more flexible than the IDE-for-simplification approach.

    That is a good name of the 2 aproaches:

    Dynamics Langs(less code, less IDE) vs IDE-for-simplification(generate code)


    .V
  37. ... more flexible than the IDE-for-simplification approach.
    That is a good name of the 2 aproaches:Dynamics Langs(less code, less IDE) vs IDE-for-simplification(generate code).V

    There are not two approaches at all. Some dynamic languages (such as Smalltalk) have the best IDEs. Having a dynamic language does not remove the usefulness of a good IDE with all the associated tools (refactoring etc.).
  38. The trouble is that much of it seems to be evangalization about poor practices (database-driven design, script code embedded in web pages) that many of us have known about and rejected years ago.
    Steve, I partly disagree. Yes, the view part in many examples of RoR documentation looks like a big step back. But you <strong>may</strong> achieve a good design on the view part - it's possible.

    I keep hearing such comments about RoR - 'yes there are design faults, but if you work at it, you can get around them'. I would rather use a better-designed system from the start.
    RoR and Ruby are a lot about DRY and give you layouts, partials and components at hand. As long as you are able to overwrite everything (please have a look at: http://wiki.rubyonrails.com/rails/show/HowToUseLegacySchemas for example)

    I am familiar with it. A lot of criticism about Java is to do with excessive code (getters and setters for example). This is usually irrelevant as much of this code is generated and managed by an IDE.
    I can't find anything bad about using database schemas as a headstart in RAD.

    There is much that is potentially bad about it.

    Firstly, much modern development is about objects and their relationships, not about database tables. For some applications the database is simply a persistence method. Having possibly vendor-specific database features (such as allowed column names and relationships) impose on your software design is poor.

    There is a fundamental difference between using schemas as a headstart and having objects generated from schemas from then on.

    Thirdly, if you work from databases you tend to neglect useful features of OOP such as polymorphism and interitance.
    Who cares about what looks 'sexy'!
    As I said: Mankind!!! You could answer that "sexy" is only what is working, but anyway, things that are working great but miss in marketing and design won't live as long as they could and should be.
    No - things that work great tend to keep on going! What is sexy about SQL, or COBOL for example?
    It is about what works. And about speed - if you really want speed of development, why not use something like Java Studio Creator? With the visual design, robust J2EE applications can be put together in minutes. I don't use it myself, but if speed of development is an issue, it will do the job.
    I did try both, RoR as well as the Studio Creator approach. I'll go for RoR in some projects and my own Java, Eclipse, Ant, Spring, Hibernate Development environment for others. I don't know what formed your opinion that RoR isn't flexible at all. In my opinion RoR is more flexible than the IDE-for-simplification approach.

    I never said that RoR wasn't flexible (I haven't even used the word). What I have said is that it is flawed. It is designed for a 'get things going quickly' approach - it allows phenomenally fast generation of the skeleton of applications. However, it is then very vunerable to changes in requirements and design. Where is the mapping layer that isolates my code from schema changes? How do I know what tables my code uses?

    If I were designing something like RoR, I would have taken a far more modern approach. Allow the developer to specify the data model as Ruby classes and have something that can generate a schema and mapping layer, the latter perhaps stored in some external file (XML or, if you really have to - YAML) so users can change the schema without messing up the application. I would have implemented a web framework rather like Wicket or JSF where you have flexibility about rendering and the controls on a form are first-class components that can be extended and not simply helper methods on a monolithic class.
    The Java environment could learn a hell lot of rails.Jan Prill

    I seriously disagree. I think there has to be a lot of education the other way.
  39. development is about objects and their relationships, not about database tables. For some applications the database is simply a persistence method.

    There you go again. All other platforms are wrong becuase they are SQL centric. The should all be using EJB.... but it's not necesary on those platforms, a big plus for them.
    For some applications, even in J2EE, you use stored procedures.


    .V
  40. development is about objects and their relationships, not about database tables. For some applications the database is simply a persistence method.
    There you go again. All other platforms are wrong becuase they are SQL centric. The should all be using EJB.... but it's not necesary on those platforms, a big plus for them.For some applications, even in J2EE, you use stored procedures..V

    Whaaaaat?

    objects != EJB.
    "For some applications" != "All other platforms are wrong ..."
    "not about database tables" != "For some applications, even in J2EE, you use stored procedures"
  41. development is about objects and their relationships, not about database tables. For some applications the database is simply a persistence method.
    There you go again. All other platforms are wrong becuase they are SQL centric. The should all be using EJB.... but it's not necesary on those platforms, a big plus for them.For some applications, even in J2EE, you use stored procedures..V

    First, who mentioned EJBs? Second, no matter how much SQL needs to be generated, no matter how many triggers or stored procs are used, the application SHOULD NOT be coupled to the database schema.
  42. .... the application SHOULD NOT be coupled to the database schema.

    I think opposite. I hope you don't mind if I keep my opinion for me. And good luck to you too.

    .V
  43. .... the application SHOULD NOT be coupled to the database schema.
    I think opposite. I hope you don't mind if I keep my opinion for me. And good luck to you too..V

    Nothing wrong with having different opinions, but let me make sure that I understand yours.

    You believe that the application should be tied to the database schema. For example, a web page should directly reference the data tier. That having business logic that uses things like TABLE.COLUMN_1 embedded in it is not only acceptable, but desirable?

    That is your belief?
  44. ... logic that uses things like TABLE.COLUMN_1 embedded in it is not only acceptable, but desirable?That is your belief?

    YES!

    .V
  45. ... logic that uses things like TABLE.COLUMN_1 embedded in it is not only acceptable, but desirable?That is your belief?
    YES!.V

    Yike! Well, good luck to you too, but I hope I never have to work on your code. :-)
  46. .... the application SHOULD NOT be coupled to the database schema.
    I think opposite. I hope you don't mind if I keep my opinion for me. And good luck to you too..V

    Java seems to be a strange language to use in this case. The language that has changed so much of IT because of its portability and vendor independence. To be tied down simply as an addition to a particular type of storage, and (bearing in mind the much-discussed vendor dependencies of this kind of thing) even to a particular product - it seems very wrong to me. There are plenty of product-specific alternatives - languages which are possibly more business-oriented - so why Java?
  47. development is about objects and their relationships, not about database tables. For some applications the database is simply a persistence method.
    There you go again. All other platforms are wrong becuase they are SQL centric.

    What I said was carefully qualified. I actually said 'much' development is about objects, not all. I said for 'some' applications the database is simply a persistence method, not all. Of course, Java and ORM has to work with other applications and other uses of the database.

    In fact, this is where Ruby on Rails lets you down, not Java ORM. All the Java ORMs I know about have a mapping that gives code significant independence from from the schema and other uses of the database. RoR has (to simplify things) the approach: "The schema is MINE! Touch it and I could crash!."

    If you believe that the database is important and should be accessible to multiple applications and users, then you should be backing the J2EE approach, not RoR.
  48. If you believe that the database is important and should be accessible to multiple applications and users, then you should be backing the J2EE approach, not RoR.

    I wonder where this black and white comes from? If you believe in that than come to this site and fight with us, if you are a non believer then just shut your mouth and head over to the dark side... Once again: It's about learning from each other, and wouldn't you agree in that java at least should give the choice to do simple things in a simple manner. It's great that java is about choice and it's great that java has the facilities to build the most complex systems. But it needs to learn from others how to achieve simplicity where appropriate and document in a stylish way. This whole blueprints, petstore stuff to bring newbies on track just sucks big time.

    Jan
  49. Once again: It's about learning from each other, and wouldn't you agree in that java at least should give the choice to do simple things in a simple manner.

    But it does! A good Java IDE, combined with good tools (like the JDO workbench I use for my ORM development) can make development simple and even fun. Refactoring tools and powerful debugging systems make life far easier, and make the developer far more productive.
    But it needs to learn from others how to achieve simplicity where appropriate and document in a stylish way.

    I open my Java IDE, define a class, type in a few variables. All the bean properties are generated automatically. I open my JDO workbench, tell it where the classes are. It generates the JDO project automatically. Click on another icon and it generates the schema (or offers to migrate an existing schema to match my object relationships). All the information is there - the SQL for the schema, and UML diagrams of my classes. I change the classes, and these will change to match.

    Now that is simplicity, and definitely stylish! (unlike messing about with command-line scripts)
    This whole blueprints, petstore stuff to bring newbies on track just sucks big time.

    I'm afraid that learning examples of how to do things the right way can suck and be boring. Using the knowledge and experience of developers who have had years of experience can suck and be boring. However, a professional developer needs this knowledge and experience. I would not want a self-taught newbie anywhere near companies I support - I have seen the results and they are not pretty.

    I have seen this attitude before, decades ago, when Smalltalk first became popular. It is a dynamic language, and a lot of fun. However, as it got used for serious business projects it acquired a culture of blueprints, patterns, tests and refactoring. This supposed 'baggage' is pretty important for serious projects.

    If Ruby and Rails is to teach other approaches anything, it first needs to show that it has anything new to offer. So far I have seen nothing but the (probably) unintentional re-invention of wheels. I mentioned Smalltalk: there are good Smalltalk ORM and web frameworks that are very much like RoR, but without many of the mistakes.
  50. I open my Java IDE, define a class, type in a few variables. All the bean properties are generated automatically. I open my JDO workbench, tell it where the classes are. It generates the JDO project automatically. Click on another icon and it generates the schema (or offers to migrate an existing schema to match my object relationships). All the information is there - the SQL for the schema, and UML diagrams of my classes. I change the classes, and these will change to match.Now that is simplicity, and definitely stylish! (unlike messing about with command-line scripts)

    Steve, obviously you are passionate about java. I've made my first steps as a programmer with java (right when it came out) because I wanted to program applets - the first way to get kind of multimedia to the web. Never learned or even mastered C or C++ really and am not interested in it, because I've learned that the simplification of the managed environment makes a big deal and am interested in as less hair loss as possible. I've found a way myself to be productive in java too; my development environment may not be as sophisticated as yours but I've got a change-test-cycle that I'm satisfied with for the most part. For me getting this development env took quite some time and was hard work. I've seen enough java-developer, who have long compiling runs, building archives, deploying them, even restarting the container every time. This needs documentation for the newbies and for the poor guys who are waiting for their container to start again! Compared to the development cycle of dynamic languages at least these developers look like relicts from stone age.

    Jan
  51. ...... For me getting this development env took quite some time and was hard work. I've seen enough java-developer, who have long compiling runs, building archives, deploying them, even restarting the container every time. This needs documentation for the newbies and for the poor guys who are waiting for their container to start again! Compared to the development cycle of dynamic languages at least these developers look like relicts from stone age.Jan

    Oh! But this is not a limitation of Java. Java is dynamic/flexible enough to let you code 'realtime' and let your servlet container automatically pick up those changes to configuration files, code and web content.

    It is just that nobody really bothered to implement the servlet container like this. Different mindset I guess. Which is a shame, but a more dynamic container with better IDE plugins could really kick ass in the Java world.

     S.
  52. Steve, obviously you are passionate about java.

    Not really. I have used far better languages. What I am passionate about is good software engineering, and this is what I so dislike about RoR.
    This needs documentation for the newbies and for the poor guys who are waiting for their container to start again! Compared to the development cycle of dynamic languages at least these developers look like relicts from stone age.Jan

    Use a better IDE; a combination like Eclipse and MyEclipse allows incremental development and deployment without restarting J2EE containers, and often without even restarting the application.

    Yet again, this seems to be a justification for using RoR based on not fully understating how Java can work; because you have seen many Java developers possibly doing things the wrong way, you seem to be assuming that this is typical and Java can't be a fast and simple way to develop. It can.
  53. Yet again, this seems to be a justification for using RoR based on not fully understating how Java can work; because you have seen many Java developers possibly doing things the wrong way, you seem to be assuming that this is typical and Java can't be a fast and simple way to develop. It can.

    First of all I don't need a justification for testing or using any new technique I find interesting. I know that java can be a productive environment, I in strong believe that for many (too many) java developers it is not. In my opinion this is the reason why many JEE projects fail. I'm not fully understanding how RoR can work, do you?

    Jan
  54. First of all I don't need a justification for testing or using any new technique I find interesting.

    You obviously don't need a justification for using it yourself. If you are putting it forward for others to use in a public forum, I would suggest that it is expected that you should justify such a point of view.
    I know that java can be a productive environment, I in strong believe that for many (too many) java developers it is not. In my opinion this is the reason why many JEE projects fail.

    This is irrelevant to whether or not RoR should be used. At least a significant number of JEE projects use modern techniques for software development, with good debugging tools and refactoring.
    I'm not fully understanding how RoR can work, do you?Jan

    This does not help to deal with what seem to me (and others) to be obvious significant flaws in RoR. I have clearly described what I believe such flaws to be. So far no-one has managed to convince me that these things are not flaws.

    Again, this reminds me of when I used to use Smalltalk. Speed was a real problem. Smalltalk supporters continually attempted to hand-wave away this matter: "Speed is not important", "You can always code the fast bits in C", "Smalltalk will get faster in the future". In the end (and for other reasons), I had enough and switched to Java.

    Similarly, for me, the way Rails now works is a problem, and all I seem to get is similar hand-waving: "Rails will get better", "You can write your own extensions", "This doesn't matter", "you don't know enough about it".
  55. You obviously don't need a justification for using it yourself. If you are putting it forward for others to use in a public forum, I would suggest that it is expected that you should justify such a point of view.

    I've never said: Hey all, drop java - use rails. I'll definitly __not__ do this myself, but just evaluate and probably use rails for projects where I find it appropriate. And as a sidenote: I would be pretty happy if anyone (rife, trails, whatever) delivers a java framework with an entry barrier as low as RoRs.

    But since it is fun to provoke a little: Hey all: If you are interested in dynamic languages and are open minded enough to take a look at another approach: Give RoR a try! But be aware: Maybe you'll find that for some (private, smaller) projects you don't need the whole sophistication of JEE...

    Jan
  56. Hey all: If you are interested in dynamic languages and are open minded enough to take a look at another approach: Give RoR a try! But be aware: Maybe you'll find that for some (private, smaller) projects you don't need the whole sophistication of JEE...Jan

    Yet again, there is this 'evangelising': Stop being a 'closed' minded Java developer! RoR is not so much about dynamic languages - it is about dynamically generating data-linked web applications. It does so using a language (Ruby) that is hardly the most elegant (and until RoR was mentioned, did not have that much use), and it uses an ORM that isn't really an ORM (no Mapping!). In my opinion, developers who really want to see dynamic languages should look at more mature ones such as LISP or Smalltalk to see how things can really be done elegantly. [Take a look at Squeak Smalltalk (Squeak.org), and see a mature dynamic language in an interactive GUI environment with class browsing, debugging and refactoring. It makes most Ruby development look primitive.]

    And I still don't understand this 'whole sophistication' business - there is nothing sophisticated about a few JSP pages linked to a database using JSTL tags, yet it is still JEE. For smaller projects, even PHP is better that RoR, as at least changes to the databases don't change parts of your code.

    The longer this thread has gone on, the more I feel (rightly or wrongly) that many RoR advocates are the closed minded ones, as they really don't have much idea about modern Java use, and how fast and agile development can be, and have little sense of the real history of ORM and how it best works, or of dynamic languages.
  57. Yet again, there is this 'evangelising'

    It was marked as fun and provocative. Just a guess: You take yourself quite seriously, don't you? If I won't put something on me than it is to be closed minded. Nuff said!
  58. Yet again, there is this 'evangelising'
    It was marked as fun and provocative. Just a guess: You take yourself quite seriously, don't you? If I won't put something on me than it is to be closed minded. Nuff said!

    Many posts back you seemed to be pretty serious - talking about projects that had failed, and what Java had to learn about design. Certainly, the RoR folk seem to be saying it is a serious tool for writing "real world applications".

    Even if RoR was simply being pitched as a fun tool for novices to set up hobby websites, I would still be uncomfortable about it as such novices often end up in businesses thinking they know what they are doing. (I call it the "Boss's Son" syndrome). People like me have to clear up the costly mess that usually results. Also, I am a terribly, terribly serious person...
  59. You obviously don't need a justification for using it yourself. If you are putting it forward for others to use in a public forum, I would suggest that it is expected that you should justify such a point of view.
    I've never said: Hey all, drop java - use rails. I'll definitly __not__ do this myself, but just evaluate and probably use rails for projects where I find it appropriate. And as a sidenote: I would be pretty happy if anyone (rife, trails, whatever) delivers a java framework with an entry barrier as low as RoRs. But since it is fun to provoke a little: Hey all: If you are interested in dynamic languages and are open minded enough to take a look at another approach: Give RoR a try! But be aware: Maybe you'll find that for some (private, smaller) projects you don't need the whole sophistication of JEE...Jan


    And again, I say I'd rather use something that scales down to simple projects than use whatever scripting language is popular this quarter. Struts, Spring, and Hibernate allows you to handle simple applications and use the same techniques, architecture, and intefaces for larger projects.

    That low barrier of entry of which you speak already exists.
  60. I open my Java IDE, define a class, type in a few variables. All the bean properties are generated automatically. I open my JDO workbench, tell it where the classes are. It generates the JDO project automatically. Click on another icon and it generates the schema (or offers to migrate an existing schema to match my object relationships). All the information is there - the SQL for the schema, and UML diagrams of my classes. I change the classes, and these will change to match.Now that is simplicity, and definitely stylish! (unlike messing about with command-line scripts)
    Steve, obviously you are passionate about java. I've made my first steps as a programmer with java (right when it came out) because I wanted to program applets - the first way to get kind of multimedia to the web. Never learned or even mastered C or C++ really and am not interested in it, because I've learned that the simplification of the managed environment makes a big deal and am interested in as less hair loss as possible. I've found a way myself to be productive in java too; my development environment may not be as sophisticated as yours but I've got a change-test-cycle that I'm satisfied with for the most part. For me getting this development env took quite some time and was hard work. I've seen enough java-developer, who have long compiling runs, building archives, deploying them, even restarting the container every time. This needs documentation for the newbies and for the poor guys who are waiting for their container to start again! Compared to the development cycle of dynamic languages at least these developers look like relicts from stone age.Jan

    Well, I guess we'll see. I think that Ruby will go the way of Python and Perl. Niche languages used by few and will be replaced by another dynamic language.

    I also predict that today's Ruby projects will be replaced by tomorrows statically type language.

    It is ironic that you think that the development cycle makes one a relict as opposed to using discredited techniques from years ago.
  61. Another day, another dynamic language.[ Go to top ]

    Well, I guess we'll see. I think that Ruby will go the way of Python and Perl.
    And Easytrieve and Quik Job and .... :)
  62. If you believe that the database is important and should be accessible to multiple applications and users, then you should be backing the J2EE approach, not RoR.

    Database is very important component in the systems, stuff like J2EE and RoR are just some of many ways to access. If system is well designed (driven by RDBMS) then stuff like J2EE approach or RoR do not mater (it is easy to replace "legacy" data access method with new hype).
  63. If system is well designed (driven by RDBMS)
    A RDBMS driven system doesn't constitute a well designed system. It more than likely means the opposite. Not always.
    [Cue Cameron's presentation]
  64. If system is well designed (driven by RDBMS)
    A RDBMS driven system doesn't constitute a well designed system. It more than likely means the opposite. Not always.[Cue Cameron's presentation]
    Is it about cache driven systems ?
    :)
  65. If system is well designed (driven by RDBMS)
    A RDBMS driven system doesn't constitute a well designed system. It more than likely means the opposite. Not always.[Cue Cameron's presentation]
    Is it about cache driven systems ? :)
    You might say that. I wouldn't. But, yes, it is about cache. But also about using the right technique.
  66. If system is well designed (driven by RDBMS)
    A RDBMS driven system doesn't constitute a well designed system. It more than likely means the opposite. Not always.[Cue Cameron's presentation]
    Is it about cache driven systems ? :)
    You might say that. I wouldn't. But, yes, it is about cache. But also about using the right technique.

    It is also about keeping logic away from the database where possible - in terms of J2EE this could mean page navigation based on customer decisions. I would be interested to see how this could be done efficiently using a database!
  67. If system is well designed (driven by RDBMS)
    A RDBMS driven system doesn't constitute a well designed system. It more than likely means the opposite. Not always.[Cue Cameron's presentation]
    Is it about cache driven systems ? :)
    You might say that. I wouldn't. But, yes, it is about cache. But also about using the right technique.
    It is also about keeping logic away from the database where possible - in terms of J2EE this could mean page navigation based on customer decisions. I would be interested to see how this could be done efficiently using a database!
    You do not need database for page navigation, use Ruby or J2EE to generate text and images or parse HTML form input.
  68. You do not need database for page navigation, use Ruby or J2EE to generate text and images or parse HTML form input.

    But a few posts back you said that Ruby and J2EE did not matter.
  69. You do not need database for page navigation, use Ruby or J2EE to generate text and images or parse HTML form input.
    But a few posts back you said that Ruby and J2EE did not matter.
     Ruby, J2EE or .NET can be used to access database, RDBMS supports many platforms at the same time and it does not mater J2EE or Ruby is better to parse URL.
  70. If system is well designed (driven by RDBMS)
    A RDBMS driven system doesn't constitute a well designed system. It more than likely means the opposite. Not always.[Cue Cameron's presentation]
    Is it about cache driven systems ? :)
    You might say that. I wouldn't. But, yes, it is about cache. But also about using the right technique.
    Yes, cache is the right technique, RBDMS manages it without problems.
    BTW I like "Effective Enterprise Java" by Ted Neward http://www.theserverside.com/symposium/presentations.html, he talks about this stuff too.
  71. If system is well designed (driven by RDBMS)
    A RDBMS driven system doesn't constitute a well designed system. It more than likely means the opposite. Not always.[Cue Cameron's presentation]
    Is it about cache driven systems ? :)
    You might say that. I wouldn't. But, yes, it is about cache. But also about using the right technique.
    Yes, cache is the right technique, RBDMS manages it without problems.BTW I like "Effective Enterprise Java" by Ted Neward http://www.theserverside.com/symposium/presentations.html, he talks about this stuff too.
    Sadly, he presently problems but not solutions.

    The DB caching is not without its problems. From its standpoint it does it without problems.

    The big issue is that people equate data with database (more specifically a Relational DB). Both data and the rules about the data are equally important. Without the data, the rules would be pretty much useless. Without the rules, one wouldn't know what to do with the data or probably wouldn't even recognize it as data.
  72. Sadly, he presently problems but not solutions.
    He talks about solutions like stored procedures, pregenerated content. RDBMS related solutions are very simple and mature, it integrates well with any client application or technology.
  73. RDBMS related solutions are very simple and mature, it integrates well with any client application or technology.

    If only this were true. Of course, it isn't. If RDBMS solutions were simple, then DBA jobs would not be necessary, and so well paid and so important. If they integrate well with any client application and technology there would not be so much work put into integration helper systems like ODBC and JDBC. There would not be so many methods in ODBC and JDBC implementations which allow the developer to determine what each RDBMS is capable of.

    RDMBSes are important. They are a vital part of almost every business. However, one thing they are definitely not is simple!
  74. Yes, cache is the right technique, RBDMS manages it without problems.

    Unfortunately, this is simply not correct.

    For example, in an application that we worked with at one of the largest auto insurers in the USA, the database read/write for a particular [large] bit of user data cost over 200/800ms respectively, and was required by almost all pages. The end result of caching it in its application (i.e. object) form in the Java tier was a drop in load on the database of 80%, which made all the other database-related activity more responsive and gave them head-room for scale. At the same time, it dropped the read/write times to 1ms (read) and 25ms (write) for the same data (and most of the 25ms was XML serialization), so the user experience improved dramatically, shaving an entire second off of each request. The "cost" in terms of middle tier CPU cycles to manage this data? Negative 40%. In other words, by caching the data in the middle tier, the server CPU load in the middle tier dropped by 40%.

    In other words, I am offering proof that your statement is not correct by showing that the end user benefited, the middle tier servers benefited and the database server benefited from caching in the middle tier.

    At the same time, I'm a pragmatist. Caching does not replace a database; rather, it helps make database applications more scalable and more performant by avoiding unnecessary database bottlenecks. I do not think that cache is a solution to every problem; however, used correctly it can dramatically improve scalable performance, and in the case of Coherence, it can eliminate single points of failure and contribute significantly to the HA aspect of an enterprise system.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  75. At the same time, it dropped the read/write times to 1ms (read) and 25ms (write) for the same data (and most of the 25ms was XML serialization), so the user experience improved dramatically, shaving an entire second off of each request. The "cost" in terms of middle tier CPU cycles to manage this data? Negative 40%. In other words, by caching the data in the middle tier, the server CPU load in the middle tier dropped by 40%.In other words, I am offering proof that your statement is not correct by showing that the end user benefited, the middle tier servers benefited and the database server benefited from caching in the middle tier.
    I am not cache expert, but RDBMS vendors recommend to use it for e-commerce
    http://publib.boulder.ibm.com/infocenter/db2help/index.jsp?topic=/com.ibm.db2.ii.doc/ad/ciiperft.htm
    . Probably I was confused by oracle and IBM marketing BS if your cache outperforms it and can save a second per request.
  76. I am not cache expert, but RDBMS vendors recommend to use it for e-commercehttp://publib.boulder.ibm.com/infocenter/db2help/index.jsp?topic=/com.ibm.db2.ii.doc/ad/ciiperft.htm. Probably I was confused by oracle and IBM marketing BS if your cache outperforms it and can save a second per request.

    You were discussing relational databases in general. Now you are talking about the specifics of DB2. Just because DB2 (and other products) include cacheing does not mean that this is a general or standard facility. Recently you have been arguing about the portability of RBDMS application because of SQL standards.

    I fail to see the advantage of using highly database-vendor-specific techniques in this situation when there are very effective and portable Java solutions that work with J2EE.
  77. You were discussing relational databases in general. Now you are talking about the specifics of DB2. Just because DB2 (and other products) include cacheing does not mean that this is a general or standard facility. Recently you have been arguing about the portability of RBDMS application because of SQL standards.I fail to see the advantage of using highly database-vendor-specific techniques in this situation when there are very effective and portable Java solutions that work with J2EE.
    It as portable as any jdo-vendor-specific technique.
  78. You were discussing relational databases in general. Now you are talking about the specifics of DB2. Just because DB2 (and other products) include cacheing does not mean that this is a general or standard facility. Recently you have been arguing about the portability of RBDMS application because of SQL standards.I fail to see the advantage of using highly database-vendor-specific techniques in this situation when there are very effective and portable Java solutions that work with J2EE.
    It as portable as any jdo-vendor-specific technique.

    True, but how is that relevant? I try to avoid such techniques as I support portability. The JDO 2.0 specification makes what used to be optional vendor-specific techniques standard and available on all implementations. I still don't understand why you, given your past emphasis on portability, are encouraging the use of vendor-specific features when there are portable alternatives. Perhaps you have figures that show a dramatic performance benefit of this approach?
  79. I see no portability problems in materialized views , This cache is transparent for application (RDBMS manges it).
    I do not claim "dramatic performance benefit", I trust Cameron, he is cache expert and I hope he tested materialized view performance before to reply.
  80. I see no portability problems in materialized views , This cache is transparent for application (RDBMS manges it). I do not claim "dramatic performance benefit", I trust Cameron, he is cache expert and I hope he tested materialized view performance before to reply.

    Of course their is a portability problem. I don't believe all DBs support materialized views. I pretty sure Oracle 8i doesn't, for example.

    Non-trivial SQL isn't portable.
  81. I see no portability problems in materialized views , This cache is transparent for application (RDBMS manges it). I do not claim "dramatic performance benefit", I trust Cameron, he is cache expert and I hope he tested materialized view performance before to reply.

    My earlier point is that JDBC can itself be a costly interface to squeeze object data "through", and can itself be more expensive than the cost of managing distributed data in the application tier.

    Again, every application is different, and blind use of any technology is a guaranteed way to end up with needlessly complex and/or non-functioning applications ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  82. I see no portability problems in materialized views , This cache is transparent for application (RDBMS manges it). I do not claim "dramatic performance benefit", I trust Cameron, he is cache expert and I hope he tested materialized view performance before to reply.

    I think the key here is that each application is different. Just because something works for a small medium e-commerce site, doesn't mean it is appropriate for other applications. if there was one take home, I've learned the hard way it's best not to take something for granted. The times that I have and thought, "that should be a problem," it ended up being a problem. So there's no substitute for understanding the business needs and the technology. Without understanding both, it's much harder to build a good application that meets the needs.

    I see no problem with using ROR, if someone is aware of the limitations and knows what it takes to support 10 or 100x the load. A small company can't afford to build sophisticated applications using coherence and they shouldn't. But the developers should at minimum be aware of the difference and have a rough idea of how to migrate or change in the event the need appears.

    peter
  83. I see no portability problems in materialized views , This cache is transparent for application (RDBMS manges it).

    Materialized views are certainly not very portable. Major database vendors only declare that their implementations are 'similar to' those of others. Their use is not transparent to applications - just look at the different query hints you have to use on different versions of SQL server, for example.
    I do not claim "dramatic performance benefit", I trust Cameron, he is cache expert and I hope he tested materialized view performance before to reply.

    If you don't claim a dramatic performance benefit for this technique, then what is the point, and why suggest its use above Java/J2EE solutions which can be used on a far wider range of database and storage techniques? Perhaps it may be easier to administer, possibly being an integrated part of a DB product - but I can see no other justification.
  84. If you don't claim a dramatic performance benefit for this technique, then what is the point, and why suggest its use above Java/J2EE solutions which can be used on a far wider range of database and storage techniques? Perhaps it may be easier to administer, possibly being an integrated part of a DB product - but I can see no other justification.
    I just claim RDBMS manages cache without problems, if it is not as performat as you want then try some workaround like "Java/J2EE solution".
  85. I just claim RDBMS manages cache without problems, if it is not as performat as you want then try some workaround like "Java/J2EE solution".

    This is a bad approach. A developer should always use the most portable and standard solution where possible, and should have to justify using vendor-specific and non-portable alternatives, not the other way around. I can see little point in using database-specific "workarounds" when there are J2EE alternatives. But that is just my opinion...
  86. Yes, our opinions are very different. I think The Bad approach is to use "get/put" in code (any optimization must be "transparent" and without side effects), if cache is "transparent" then there is no problems to replace it (materialized views are transparent).
    Modern databases support query cache, it doe's not make sence to duplicate it and it doe's not have any client side cache limitations with triggers and stored procedures.
    I think server side cache is more portable than JAVA workarounds, it works for all clients including Ruby.

    It makes sence to use hashtables for data cache in some trivial cases, but it is more exception than rule (it is more performant to pregenerate and to cache content in web app).
  87. Yes, our opinions are very different. I think The Bad approach is to use "get/put" in code (any optimization must be "transparent" and without side effects),

    There are transparent cacheing solutions for Java/J2EE, so this is not an argument for or against using a cache as part of the database.
    materialized views are transparent.Modern databases support query cache, it doe's not make sence to duplicate it and it doe's not have any client side cache limitations with triggers and stored procedures.

    The problem is that materialized views aren't always transparent. As I pointed out earlier, for some databases (versions of SQL Server, for example) you need to include specialised code and there are restrictions on what you can do, so the use of this technique breaks your requirement for transparency. By your own criteria, a Java solution is therefore preferable.
    I think server side cache is more portable than JAVA workarounds, it works for all clients including Ruby.

    I don't approve of the phrase 'workarounds' - it makes the Java[sic] solution seem somehow second rate. It isn't. The point about use with other clients is a reasonable one, but, I would suggest, not that important. Java is the de-facto standard language for development in this situation. I would expect that the use of RoR with large high-volume clustered databases is rather rare.
  88. Do you recommend to ignore this tunning option just becouse some SQL Server version doe's not support it ?
  89. Do you recommend to ignore this tunning option just becouse some SQL Server version doe's not support it ?

    If you have a large investment in existing vendor-specific SQL-based applications on a particular database, I can see how this can be very useful. However, as it is not supported to the same extent on different databases, and when it is supported it is often not transparent and it can impose restrictions on what you can do, I personally would rather investigate a more modern approach which is to use a J2EE/Java based system that can be less restrictive and more transparent. The only reasons I can see for not using this approach is if there are other applications in other languages which need to use caching, or if there is some sort of objection to the use of Java or J2EE.
  90. All options are usefull to solve performance problems. I prefer to test "transparent" ways first, if it doe's not help then I try hacks. Both "get/put" and "query rewrite hints" are hacks, but "distributed cache" can be the last attempt only to optimize application, it has side effects and it duplicates database functionality ( if stale data is tolerated then I see more option to optimize without distributed "get/put" )
  91. All options are usefull to solve performance problems. I prefer to test "transparent" ways first, if it doe's not help then I try hacks. Both "get/put" and "query rewrite hints" are hacks, but "distributed cache" can be the last attempt only to optimize application, it has side effects and it duplicates database functionality ( if stale data is tolerated then I see more option to optimize without distributed "get/put" )

    I don't understand what you mean by "get/put". Cacheing in Java can be entirely transparent as you can proxy bean setters and getters (or add cacheing as aspects) so that there need be nothing in general code that is to do with cacheing - no need for hints or "get/put" (whatever that means) - just general bean use.

    I would suggest that you are misunderstanding transparency. On some databases query hints aren't optional, and something to be tried later - they are required for the type of cacheing we are talking about, so you can't try transparent ways first, as on these products there are no transparent ways!

    We seem to be going around in circles. You have presented no evidence that vendor-specific database cacheing is any faster, or more portable, or more transparent, than a Java-based cache. I may be wrong, but I can only conclude that your objection is a political dislike of Java/J2EE rather than based on technical arguments.
  92. I don't understand what you mean by "get/put".
    Based on his previous statements, I think he is talking about Hashmaps. As in “Coherence: The world’s most expensive HashMap” :)

    He seems to be in the camp that believes that the Database is the most important piece of the application (and actually is superior). And if the Database can do it (caching, enforce business rules, make things faster) then that is where it all should be done. Nothing but experience will change their mind, and sometimes not even that. Part of the problem is that this came equates data to database. The data is very important, as is the rules about the data. The database itself isn't anymore important than any of the technology involved. The level of importance depends on what is trying to be accomplished.
  93. Ok, I see it is the end of discussion. I do not have any personal arguments to insult you and Steve and I do not understand how database cache makes me a bad man from the wrong camp.
  94. Based on his previous statements, I think he is talking about Hashmaps.

    I suspected this, but did not want to assume it as it is a highly simplistic way of thinking about Java cacheing.
    Ok, I see it is the end of discussion. I do not have any personal arguments to insult you and Steve and I do not understand how database cache makes me a bad man from the wrong camp.

    I'm sure no insults were intended, and certainly no implication that anyone was 'bad'. I was simply having a problem seeing what your argument was.

    If you said 'I prefer to use vendor-specific cacheing for a database because that is what I know', or 'I want to use this sort of cacheing because I have mixed language access to the database' I could respect that point of view. I could even respect an honest 'I hate Java/J2EE' :)

    However, you were putting forward arguments for this sort of cacheing that, I believe, are easily refuted. You were saying that managed views (and similar techniques) were transparent to applications and portable, when even the most minimal research shows that this is not the case; at least not for all major databases.

    I just find it hard to accept an approach that says "use the most expensive vendor-specific technique first, and if that fails, then use a portable Java solution that is just as fast if not faster, and can be guaranteed transparent (no get/put required)."

    Seems the wrong way around to me. Don't feel pressured to reply - I have enjoyed this discussion as I have learned a lot - that DB2 link you provided was interesting.
  95. Ok, I see it is the end of discussion. I do not have any personal arguments to insult you and Steve and I do not understand how database cache makes me a bad man from the wrong camp.
    I apologize if you feel insulted. It was definitely not my intention. I don't think I said anything about you personally other than to put you in a certain grouping.

    While I believe (based on experience and knowledge) that you are wrong, I don't believe you are bad because of it. I was trying to point out to Steve that no matter how reasonable he feels his arguments are (or how reasonable they are), it won't make any difference. You believe what you do, for what ever reason. And that is all I was pointing out. That, and that your position is not uncommon (hence the word camp - meaning group of those who have the same ideals).
  96. My experience and knowledge hepls me to tune database without workarounds. I know how to use "vendor specific" features like indexes and mviews and I have no problems with hashmaps too, doe's it makes me wrong ?
  97. My experience and knowledge hepls me to tune database without workarounds. I know how to use "vendor specific" features like indexes and mviews and I have no problems with hashmaps too, doe's it makes me wrong ?

    It does if you are giving reasons for using these features that are technically incorrect.
  98. Overly general I think[ Go to top ]

    Yes, our opinions are very different. I think The Bad approach is to use "get/put" in code (any optimization must be "transparent" and without side effects), if cache is "transparent" then there is no problems to replace it (materialized views are transparent).

    Modern databases support query cache, it doe's not make sence to duplicate it and it doe's not have any client side cache limitations with triggers and stored procedures. I think server side cache is more portable than JAVA workarounds, it works for all clients including Ruby.

    It makes sence to use hashtables for data cache in some trivial cases, but it is more exception than rule (it is more performant to pregenerate and to cache content in web app).

    I can understand the fear of duplicating database functionality and incurring the cost of maintaining that yourself, but I think it's not always appropriate or even desirable for many real-time cases.

    Triggers and stored procs are great and should be used, but let not confuse a technique with potential problems it may solve. Say I have a real-time system that generates on the order of 1-10K rows of data per second from one or more systems. How in the world are you going to handle that with just a database? Especially if those 10K rows need to be analyzed and the delta's sent out to hundreds of UI clients. Materialized views provide an efficient way of indexing the values of a view and storing the index. This speeds up the search time, but it also incurrs a cost if I make a view with 2 dozen sum and average columns.

    the end result is that now my inserts take 500ms instead of 50-100ms for simple to moderate insert/update. Even if I use batch insert/update, the cost is still going to be significant.

    peter
  99. Overly general I think[ Go to top ]

    This problem was solved many years ago, just try to search google with "data,warehouse,transaction,processing" keywords. Distributed java hashmap must be top rated if solves this problem in the best way.
  100. Overly general I think[ Go to top ]

    This problem was solved many years ago, just try to search google with "data,warehouse,transaction,processing" keywords. Distributed java hashmap must be top rated if solves this problem in the best way.

    The problem was not solved years ago in a way that is transparent and highly portable - we have clearly established that. It has been solved in specific ways for specific products. One of the great benefits of Java is that it has been a driving force for portability - between vendors and between platforms. It is solving problems generally that other techniques have solved in specialised ways.

    The term 'Java hashmap' is just a joke. Distributed Java caches are far more sophisticated than that, yet entirely transparent (no get/put in your code). And yes, they are top rated.

    So, please, (one last time then I will give up!) what is the objection?
  101. Overly general I think[ Go to top ]

    As it was said "blind use of any technology is a guaranteed way to end up with needlessly complex and/or non-functioning applications", so I prefer to tune database before to blindly buy a "transparent and highly portable" hack. I see nothing wrong in hacks if there are no alternatyves, but I do not produce integration problems for myself just because JAVA cache is popular in TSS threads. Probably it is not a problem for trivial homepages distributed database integrates well with any programming language and do not have problems with data changes external to one of applications in system. Doe's it means I hate or love j2ee or database ? Do you have more arguments about my emotions to prove me wrong ?
  102. Overly general I think[ Go to top ]

    As it was said "blind use of any technology is a guaranteed way to end up with needlessly complex and/or non-functioning applications", so I prefer to tune database before to blindly buy a "transparent and highly portable" hack. I see nothing wrong in hacks if there are no alternatyves, but I do not produce integration problems for myself just because JAVA cache is popular in TSS threads. Probably it is not a problem for trivial homepages distributed database integrates well with any programming language and do not have problems with data changes external to one of applications in system.

    This is a good argument.
    Doe's it means I hate or love j2ee or database ? Do you have more arguments about my emotions to prove me wrong ?

    No - I think it is clear that you prefer to tune things specifically close to the database. That is fine, obviously. My only objection was to your incorrect assertions that this was portable and transparent. Also, the declaration that well-established and robust Java solutions are in some way a 'hack' seems pretty odd to me, as I'm sure you know things like Coherence are used for far, far more that 'trivial homepages'. However, I guess that if your focus is the database, everything else seems like an optional hack.
  103. Overly general I think[ Go to top ]

    No, I just prefer to tune things close to the database before to modify program, install additional software or write hints for optimizer. I use workarounds myself if "transparent" tunning doe's not help, I see nothing wrong in client side caches if it is the last step in tunning procedure (I stop this procedure after I make system as performant as it must be). Indexes, mviews, clusters, partitions are trasparent from my point of view, it doe's not change any application functionality in system. Client side cache can produce new problems, it adds more risk and maintainence effort, it can be a problem for integration too. Probably it is not as bad as sounds in my posts, web applications use "private" database for many reasons and I think content cache is not the last option for this use case too.
  104. Overly general I think[ Go to top ]

    No, I just prefer to tune things close to the database before to modify program, install additional software or write hints for optimizer. I use workarounds myself if "transparent" tunning doe's not help, I see nothing wrong in client side caches if it is the last step in tunning procedure (I stop this procedure after I make system as performant as it must be). Indexes, mviews, clusters, partitions are trasparent from my point of view, it doe's not change any application functionality in system. Client side cache can produce new problems, it adds more risk and maintainence effort, it can be a problem for integration too. Probably it is not as bad as sounds in my posts, web applications use "private" database for many reasons and I think content cache is not the last option for this use case too.

    I guess there is an increasing divide between developers like you and me. For me, the logic and functionality is in the Java code. The database is an important store for the information (and the relational features are certainly useful). I can do things in my Java code, and the interface to the database is handled automatically and transparently. The reason I like this way of working is because I have seen applications that are highly dependent on a specific database, and have to be kept on expensive hardware and software. I prefer to have code free of such limitations, and able to move between operating systems, between databases and even between different scales of system (from mainframes to mobile devices). In my view (and I am sure you will disagree!) this is the future. So far, I have seen no performance problems with this approach, only benefits. I have developed and tested applications on PostgreSQL and MySQL and deployed on Oracle with few problems.

    This is why I object to the Rails approach so much - it tends to encourage dependence on specific databases.
  105. Overly general I think[ Go to top ]

    No, I just prefer to tune things close to the database before to modify program, install additional software or write hints for optimizer. I use workarounds myself if "transparent" tunning doe's not help, I see nothing wrong in client side caches if it is the last step in tunning procedure (I stop this procedure after I make system as performant as it must be). Indexes, mviews, clusters, partitions are trasparent from my point of view, it doe's not change any application functionality in system. Client side cache can produce new problems, it adds more risk and maintainence effort, it can be a problem for integration too. Probably it is not as bad as sounds in my posts, web applications use "private" database for many reasons and I think content cache is not the last option for this use case too.
    I guess there is an increasing divide between developers like you and me. For me, the logic and functionality is in the Java code. The database is an important store for the information (and the relational features are certainly useful). I can do things in my Java code, and the interface to the database is handled automatically and transparently. The reason I like this way of working is because I have seen applications that are highly dependent on a specific database, and have to be kept on expensive hardware and software. I prefer to have code free of such limitations, and able to move between operating systems, between databases and even between different scales of system (from mainframes to mobile devices). In my view (and I am sure you will disagree!) this is the future. So far, I have seen no performance problems with this approach, only benefits. I have developed and tested applications on PostgreSQL and MySQL and deployed on Oracle with few problems.This is why I object to the Rails approach so much - it tends to encourage dependence on specific databases.

    +1

    It's interesting. The only people who really seem to object to this are the DBAs. Usually, developers have to know the problem domain, networking, various APIs, the language in question, user interfaces AND the DBAs. While I'm no DBA, I think that having to work across the entire system gives a better perspective than just dealing with the database. In my experience, DBAs want as much put into the database as possible because...well...that's what DBAs do.

    I worked on a project where we had to port an application to JSPs because the DB and stored procedures were used to generate HTML. "It can do this." was probably the statement the DBA used and the company paid for it. Twice apparently. Once for it to be written and a second for me and a couple of other guys to undo it.

    I doubt of anyone ever said "Gee, this app has a clean break between data storage, logic, and functionality. Let's move it all to the database."
  106. Overly general I think[ Go to top ]

    The only people who really seem to object to this are the DBAs.

    No, I don't think that is completely correct. I think it is a function of the application domain just as much as it is the background of the developer / DBA / etc.

    For example, in data warehousing, a lot of the things that work really well for OLTP just absolutely suck for warehousing and datamining. Specialized knowledge, tuning, and specialized tools can make the difference between a fully optimized query taking over a month and the same taking about two hours (a story I was told from Walmart, which purportedly has the world's largest non-governmental database).

    I like to think that I'm pragmatic. I'll take whatever benefits I can get, from the very edge (Akamai) to the very core (Oracle or DB2 materialized views) and everything in between (Apache, J2EE, message queue servers, etc.)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  107. Overly general I think[ Go to top ]

    The only people who really seem to object to this are the DBAs.
    No, I don't think that is completely correct. I think it is a function of the application domain just as much as it is the background of the developer / DBA / etc.For example, in data warehousing, a lot of the things that work really well for OLTP just absolutely suck for warehousing and datamining. Specialized knowledge, tuning, and specialized tools can make the difference between a fully optimized query taking over a month and the same taking about two hours (a story I was told from Walmart, which purportedly has the world's largest non-governmental database).I like to think that I'm pragmatic. I'll take whatever benefits I can get, from the very edge (Akamai) to the very core (Oracle or DB2 materialized views) and everything in between (Apache, J2EE, message queue servers, etc.)Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java

    Good example, but I don't think it addressed my point. I've used materialized views, triggers, SPs, and close to the metal queries. I've yet to meet a developer, as you've just demostrated, that had objections to using a particular DB technique for a particular task.

    However, in my experience, DBAs consistently attempt to tie *everything* to the database, no matter how inappropriate as my example about the stored procedures generating HTML demostrates.

    I work with a person who is currently doing a very quick, very simple task with fairly trivial selects and updates. However, the DBAs insist that these extremely trivial selects and updates use stored procedures. Hey, they are the customer, but I think its unnecessary.
  108. Overly general I think[ Go to top ]

    One thing I'd like to point is that "excuse" of putting everything on the database for the sake of app "integration". It works somewhat well for a few apps which depend on the same database, and usually it is the easier way to go, but the moment different technologies joint in the integration effort (mainframe, handhelds, apps based on a different database vendor, etc.) it may not work that well anymore.
    Other point is that this kind of database integration can backlash the moment you have to make changes in one app and that change affect database model, and thus may reflect on other integrated apps, sometimes needlessly. Doing app integration out of the database helps shielding apps from some (not all) changes between them.

    Regards,
    Henrique Steckelberg
  109. Nobody needs any "excuse" to create index or mview, it is just a "transparent" optimization and nodody knows how to help integrate things before you have something to integrate, so I think system architecture just needs not to break "integration".
  110. Overly general I think[ Go to top ]

    Nobody needs any "excuse" to create index or mview, it is just a "transparent" optimization and nodody knows how to help integrate things before you have something to integrate, so I think system architecture just needs not to break "integration".

    Why do you keep saying this? If views and indexes that work with caches (and particularly distributed caches) are not the same as normal views and indexes - if they restrict the kind of queries that can be used and if they require hints (as is the case with some RBDMSes), then they are clearly not a transparent optimisation, and to use that word is inappropriate, quoted or not.
  111. Overly general I think[ Go to top ]

    If indexes or mviews require hints on some database then it is not a transparent optimization (it is a workaround too). Transparent optimizations are portable, workarounds are not and it must be explained in product documentation. Solution is very simple, just try to understand your requerements and use the best tool (it will be easy to migrate to better product with transparent optimization and you do not need to migrate to broken product anyway).
  112. caching[ Go to top ]

    I am not cache expert, but RDBMS vendors recommend to use it for e-commerce

    I also recommend the use of RDBMS for ecommerce applications. I don't generally recommend them for chaching, however.

    Consider going from a Java object through a relational database driver over the network to a relational database in order to cache data, and then going from the Java application again through a relational database driver over the network to a relational database in order to retrieve that cached data, then bringing that data back over the network through the driver and constructing a graph of Java objects from that data .. it seems apparent why a database would make a poor cache for the most common use cases.

    BTW - the link you posted did not work for me. Was it about "cache tables" perhaps?

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  113. caching[ Go to top ]

    Consider going from a Java object through a relational database driver over the network to a relational database in order to cache data, and then going from the Java application again through a relational database driver over the network to a relational database in order to retrieve that cached data, then bringing that data back over the network through the driver and constructing a graph of Java objects from that data ..
    Your cache is distributed is not it ?
  114. If you believe that the database is important and should be accessible to multiple applications and users, then you should be backing the J2EE approach, not RoR.
    Database is very important component in the systems

    Absolutely. At least most systems.
    If system is well designed (driven by RDBMS) then stuff like J2EE approach or RoR do not mater (it is easy to replace "legacy" data access method with new hype).

    A lot of high-performance J2EE involves trying to avoid hits to the database, which would seriously impact performance. So much for 'do not matter'!
  115. Just to set some things clear: I didn't say that RoR can't learn from Java. It's obvious that RoR has already learned a lot from java web-frameworks. Since people like Brian McCallister and Erik Hatcher are influencing both worlds it's even more obvious that this will continue. The take on that it would (should) be a one way road of learning is arrogant.

    Rails is not even 1.0 and it's very agile. So in my opinion it's not such a big problem that there are design flaws. I haven't seen a project that is flawless.

    I for myself am grateful that other dynamic approaches evolve, because I'm sure that java has to and will learn from these approaches.

    Jan
  116. The take on that it would (should) be a one way road of learning is arrogant.Rails is not even 1.0 and it's very agile.

    Agile is not enough, if based on a poor foundation.
    So in my opinion it's not such a big problem that there are design flaws. I haven't seen a project that is flawless.

    The real problem with RoR is that things that many of us with years (or even decades) of experience have identified as problems or disadvantages are being actively promoted as benefits in RoR. This is not just flawed, it is gleefully taking great leaps backwards from modern design and claiming this as the way forwards.
  117. The take on that it would (should) be a one way road of learning is arrogant.Rails is not even 1.0 and it's very agile.
    Agile is not enough, if based on a poor foundation.
    I think he forgot the "F" at the beginning of the word. :)

     
     
    So in my opinion it's not such a big problem that there are design flaws. I haven't seen a project that is flawless.
    The real problem with RoR is that things that many of us with years (or even decades) of experience have identified as problems or disadvantages are being actively promoted as benefits in RoR. This is not just flawed, it is gleefully taking great leaps backwards from modern design and claiming this as the way forwards.
    [Cue the Huey lewis song "Back in Time"]
  118. Bob Marley: Time Will Tell,

    one thing is for sure: Suns Marketing Dep would bend over backwards to get a media coverage about their simplification approaches similiar to the one that RoR gets because of evangelization of a bunch of geeks and some little apps like tada-list. In my personal opinion RoR achieved another one: They lowered the entry barrier for newbies in web-app development a great deal, a nut that the java crowd tries to crack for quite some time. And finally another one that is quite important for webapplication-developer-newbies: Hosting Services are jumping on the bandwagon, something where java/tomcat also shines not as much as it should be. Hats off for this success!

    Jan
  119. I think there has to be a lot of education the other way.
    I agree.

    Java (J2EE for Vic) is being accused of not looking over the wall at other tools and not learning from them. I would accuse RoR of not looking at the past, not looking to the future and just plain not looking up.

    I think, though, that we can learn a many things from RoR. Sadly, many are "how not to's". Not all.
  120. I found it almost impossible to teach Java to kids. You need a lot of fustration tolerance to get your "hello world" thing going. No problem for an experienced guy without Java-knowledge, but painful for someone who does not spend his living on such stuff. Ruby, Perl, Python etc. are more accessible. Even though I use (and like) Perl a lot for "small stuff", I chose Ruby. It was possible and easy to teach to kids, but it has a pretty clean syntax and a lot of horse power in terms of object orientation and advance concepts under the hood.

    Don't get me wrong, I think that Java does have a great future. Being more low-level and being installed on many cell phones, the micro edition will go on for a long time. And having all this really big and well established enterprise-stuff, J2EE will go on for quite a time for the real big stuff.

    But you have to choose the adequate tool for each purpose. It can be Ruby, Perl, Java, Visual Basic, C#, C++, PHP, Lisp, Fortran, Cobol or whatever.
  121. Thats just great. I always like to use my database table design as a foundation on how my webpages are laid out. If thats the future you can keep it.
    You are missing the point... it's a matter of being able to scale complexity based on your needs. Which rails does a great job of.

    I don't think he is missing the point. You can make a perfectly scalable system, one that scales lower and higher without having your webpages aware of your database.

    We did that years ago. It was a bad idea.
  122. Moving away from XML configuration file may be a good thing. In a full-fledged real world application, the XML files can be pretty big with half the logic in them (Not the business logic, but the plumbing logic). Also, over the time, the tags in these XML files grow to meet the new demands, so it is like learning a new language. Lack of compile time checking makes debugging harder.

    I can't really say whether Ruby is better than J2EE, but Ruby is certainly headed in the right direction. (IMHO, of course!)

    The author has done a great job in comparing the key differences.

    Peace,
    Raghavendra.
  123. I was at a conference recently with many people praising Ruby on Rails.

    Talking to people more, it seemed that the takeaway was:

    If you're building a low complexity CRUD-type web app, Rails can be 10x more productive.

    However, if you're building a complex web app that also has other interfaces or advanced features, then a Java framework is more likely to fit your needs.
  124. Moving away from XML configuration file may be a good thing. In a full-fledged real world application, the XML files can be pretty big with half the logic in them (Not the business logic, but the plumbing logic). Also, over the time, the tags in these XML files grow to meet the new demands, so it is like learning a new language. Lack of compile time checking makes debugging harder.I can't really say whether Ruby is better than J2EE, but Ruby is certainly headed in the right direction. (IMHO, of course!)The author has done a great job in comparing the key differences.Peace,Raghavendra.

    The XML provides one nice thing: fine grained control. We can control URLs, column names, table names. They aren't changed often, but for minor tweaks due to migration or what have you, it is a very nice low cost thing to have. Especially if you use something like XDoclet to pregenerate a default.
  125. i think managed urls are one of the best features and should almost always be dictated by the framrework. take a look at zope and RoR to see ohow powerful it can be to use the url correctly.
  126. Moving away from XML configuration file may be a good thing. In a full-fledged real world application, the XML files can be pretty big with half the logic in them (Not the business logic, but the plumbing logic).

    Just yesterday I went to an IBM technical presentation on Rational App Developer 6. The presenter built a whole (albeit very basic) app from scratch with EJBs in the backend (connecting to DB2) and a JSF frontend. Not once did he have to go into an XML file.

    So my point is, with a good enough IDE it doesn't matter if there are complex XML files that store configuration if the IDE can provide an easy way to setup the config without seeing the XML.

    Of course it's still there if you want to go into it and edit it by hand, and editing it by hand doesn't break the easy interface RAD provides.
  127. it happens alot[ Go to top ]

    Who wouldn't want Rails-like macro capabilities in J2EE or Java for that matter? The trade off is that you are dealing with a new language (for most) and there's not as strong of a knowledge base and choice as there is with J2EE.Where J2EE will gain ground in 'rails' functionality is with EJB 3/Hibernate annotations and MVC Component frameworks. The idea that you can drop visual components onto the page that can interact with the complete request lifecycle in order to provide the same create/read/update/delete operations that Rails short circuits for you.Really, you could end up with pages like:<ejb:table&amp;nbsp;&amp;nbsp;query="from Employee e where e.dept = #{param.id}"&amp;nbsp;&amp;nbsp;editable="#{user.roles['admin']}"&amp;nbsp;&amp;nbsp;styleClass="tableStyle"/>

    Thats just great. I always like to use my database table design as a foundation on how my webpages are laid out. If thats the future you can keep it.

    Having seen that happen a few times over the last 2 years, it happens very often. The main downside of that approach from my experience is the database tables and models degenerate into gibberish very quickly. After 2-3 years, the tables end up having lots of un-used columns and requires a complete rewrite.

    if someone is ok with that approach, and prefer to have short lived applications, then it's all good. On the otherhand, if your application has to last 15-30 years, then it's not ok.

    peter
  128. Re: it happens alot[ Go to top ]

    Any java application you've seen recently lasting for 15 years? *wink*
  129. I know a few[ Go to top ]

    Any java application you've seen recently lasting for 15 years? *wink*

    I don't know of any that are 15 years old today, but the last time I went on interviews, several people stated the application has to last at minimum 10 years, preferrably 15 before it needs to be replaced.

    for a java server side app to be 15 *wink* years old, someone would have had to build everything himself. now, that would be painful to do back in 1994-95. that would predate jhtml and jsps :)

    peter
  130. I know a few[ Go to top ]

    that would be painful to do back in 1994-95. that would predate jhtml and jsps :)peter
    TSS is a clear example that one can roll out an interactive website without jsps.
  131. didn't TSS start in 99?[ Go to top ]

    that would be painful to do back in 1994-95. that would predate jhtml and jsps :)peter

    TSS is a clear example that one can roll out an interactive website without jsps.

    considering TSS was rolled out in 99, there weren't many choices. If I remember correctly, JSP spec 0.9 was out in 99 and jsp 1.0 spec was in 2000. Before that, it was JHTML. Thank god we don't have to go back to pre 1999 web development.

    peter
  132. didn't TSS start in 99?[ Go to top ]

    TSS is a clear example that one can roll out an interactive website withoutj sps.
    considering TSS was rolled out in 99, there weren't many choices. If I remember correctly, JSP spec 0.9 was out in 99 and jsp 1.0 spec was in 2000. Before that, it was JHTML. Thank god we don't have to go back to pre 1999 web development.peter
    No, I meant the current incarnation built on Tapestry.
  133. JUnit in action.[ Go to top ]

    TSS is a clear example that one can roll out an interactive website without jsps.

    Since TSS switched into its new skin over a year ago, my request crashes anytime I try to delete a bookmarked thread. So I tried it again today:

    Unable to invoke method formSubmit on portal.components.MyBookmarks$Enhance_439@dc19b9[MyThreads/bookmarkedThreads]: java.rmi.RemoteException: EJB Exception: ; nested exception is: kodo.util.FatalDataStoreException: weblogic.transaction.RollbackException: Unexpected exception in beforeCompletion: sync=kodo.runtime.PersistenceManagerImpl@1e5f102 Optimistic locking errors were detected when flushing to the data store. This indicates that some objects were concurrently modified in another transaction. Failed objects: [com.tmc.jdo.dto.UserMetaDataImpl@4c7f28] [java.util.ArrayList] - with nested exception: [kodo.util.OptimisticVerificationException: Optimistic locking errors were detected when flushing to the data store. This indicates that some objects were concurrently modified in another transaction. Failed objects: [com.tmc.jdo.dto.UserMetaDataImpl@4c7f28] [java.util.ArrayList]]
  134. Seriously[ Go to top ]

    Rails is far superior and only l33t 4aX0r5 masters can harness it's true powers.
    JEE is old school, and only old school Pascal drones work with this dying framework.

    Just kidding of course. I do like technology comparisons, and I think this article did a pretty good job (could have been more detailed).
  135. Dice.com job search comparison - number of hits when searching by keyword

    Ruby - 40
    Java - 11,000+

    Hmmm, I better learn this Ruby stuff before I find myself out of work.
  136. Dice count[ Go to top ]

    Did you check 'Cobol'? ;-)
  137. Honestly, who cares about this crap? So long as Ruby is like the crazy aunt in the basement, it has no value to me at all. Ruby could be the greatest language on the planet but it doesn't have a big name behind it so it will never get anywhere beyond a niche following in the states. There are many many languages out there that have a lot to offer but very few people actually code in them. One could argue that Smalltalk is still better than either Ruby or Java but you don't see companies hiring smalltalkers do you? Love it or hate it, Java is the big boy of the web app server world right now. If Ruby ever takes over I'll be more than happy to hop on the bandwagon but for now this endless "ruby is so great" and "ruby on rails ownz0rs u!" crap is pretty pointless. If you're gonna do it, at least be fair and include all the other promising languages out there that can be used to build server side applications.
  138. Ruby is a good language[ Go to top ]

    I remember when starting to work with Java that I was happily finding a lot of stuff fixed that annoyed me in C++.
    But now I am making the same experience with Ruby.

    What is the problem with Smalltalk and Lisp and to some extent even with Java: I want to write x = a*b+c*d and get the result I expect. Too bad, Smalltalk is really great, but here it is annoying and this makes it hard to access for many people. I understand x = (a*b) + (c*d) should work in Smalltalk, (setq x (+ (* a b) (* c d))) in lisp. Java has the problem, that this only works for the builtin primitives. Often it is necessary to do arithmetic with stuff like complex numbers, BigDecimal etc, where you start writing ugly stuff like x = (a.multiply(b)).add(c.multiply(d)) which is creating a lot of noise, errors etc. and is not very accessable either. C#, Ruby, Perl, and C++ can do this one. It could be fixed in Java. But I don't think it could or should be fixed in Smalltalk or Lisp.

    What I see is that Ruby allows a higher level of abstraction and thus allows to factor out stuff where you have to copy-paste or use code-generation-tools in Java. I think that is the cleaner way to do such stuff. In Java you spend too much time with noise-code that has to be there, but that does not particularly contribute to the business logic or that duplicates something that has already been implemented in a slightly different flavor elsewhere in the code.
  139. Big Name Behind It[ Go to top ]

    Hmmm, let me see, I guess that's why Perl never got used, because it just had that guy Larry Wall's name behind it.
  140. Web components for Ruby?[ Go to top ]

    Does Ruby on Rails have something analogous to web components (like Tapestry or JSF)?
  141. Web components for Ruby?[ Go to top ]

    Does Ruby on Rails have something analogous to web components (like Tapestry or JSF)?

    I think they consider a database table to be a web component ;)
  142. Web components for Ruby?[ Go to top ]

    Does Ruby on Rails have something analogous to web components (like Tapestry or JSF)?
    I think they consider a database table to be a web component ;)

    An amusing and wise observation :)

    Ruby on Rails has some of the worst design features I have seen in many years. As Java is moving towards the use of very powerful and productive systems that allow the business logic and persistence to be increasingly independent of the database (JDO 2.0, EJB 3.0), Ruby On Rails takes a dramatic step backwards and generates code at runtime based not just for a particular database, but on a specific schema. This may seem neat and cool, but in practice, for any serious project where the schema will evolve and be used by other applications, it is a serious problem. It is almost as if Ruby on Rails was specifically designed to be fragile.
  143. Web components for Ruby?[ Go to top ]

    no they don't, it creates interface from the database schema if you are "scaffold"'ing you application,but after that you have to use rhtml which is similar to jsp (actually more like velocity probably).

    i don't think RoR and j2ee compete at all for many of the reasons outlined in this thread already. but it *is* worth looking at because there are some good/great ideas in there. they use "convention over complexity" to avoid spending a lot of time plumbing an app together.

    i think there is room in j2ee for a framework and the groovy guys have been working on "grails" to that end. seeing as there are a lot of small and low-volume applications in production, it may be an option to get work done quickly...

    lets not be code-snobs, take a look, you might learn something ;)
  144. Web components for Ruby?[ Go to top ]

    lets not be code-snobs, take a look, you might learn something ;)

    I was partly joking by my comment. If you interested here is how I really feel.

    I have looked at RoR, and I think that RoR has it's place. What I don't see is why it would be compaired to J2EE. I don't really see any overlap between the two, I don't think they are aimed at the same developer, or solving the same problem.

    I do agree that current J2EE spec and mostly the current EJB spec is more complicated then it needs to be. Yes sometimes when I'm building a J2EE application I feel like I'm jumping through a few extra hoops, and that spending a more time plumbing then I should need to. In a small application developed against a schema that doesn't have a lot of tables, the extra work is probably worth it. I think that EJB3, or Spring, help to remove a lot of the unnecessary complexity. In EJB3 a “configuration by exception” approach is taken whenever possible. I do like a certian amount of expected structure in my code. In larger applications I find it useful to be able to model my code (UML). In working with teams of specialized developers I think that being able to provide clear seporation between Data Logic, Business Logic, and Data Logic is important.

    “configuration by exception” is also one of the core concepts behind RoR, but it is taken to a much greater extreme. For smaller applications where there is only one or two developers, a fairly static table structure, and no need for clear seporation of logic layers, then I can see where RoR would be an asset. If I find myself in that position I will probably give it a try ;)

    I don't think J2EE with the EJB3 spec, or Spring, has much to learn from RoR. ****NOTICE: I'M NOT DEFENDING THE CURRENT J2EE SPEC**** If you are building a small application, and you want it out the door AFAP, then just use RoR. Or I'm sure some Groovy/RoR type thing will come out at some point.

    Also I'm not sold on the RoR "scale up" concept. In my expirence turning a simplistic application into an enterprise application, is much harder then just putting the effort in up front and have an enterprise applicaiton the whole time. IMO EJB3 or Spring are not that hard.
  145. Web components for Ruby?[ Go to top ]

    "doesn't have a lot of tables, the extra work is probably worth it. "


    Sorry I meant.


    "doesn't have a lot of tables, the extra work is probably NOT worth it. "
  146. Web components for Ruby?[ Go to top ]

    If you are building a small application, and you want it out the door AFAP, then just use RoR. Or I'm sure some Groovy/RoR type thing will come out at some point.

    See.... for a complex application .. it's harder to use a complex platform, ie, it's easier to use a simple platform for a larger application. Else you are knee deep in aligators.

    That is why KISS for complex applications.

    .V
  147. Web components for Ruby?[ Go to top ]

    Hey Vic,

    Lets say that there was a Groovy on Rails that was identical to RoR, as far as features and ease of development. Would you perfer to use the Java version or would you perfer the Ruby version?

    This is not a loaded question. I'm interested in knowing weather the platform makes any difference, or is it the only development methodology that matters? If it is the platform what are the features of Ruby or Java factored into your decision?

    I have not worked with Ruby enough to answer this question for myself ..not yet anyway.

    Thanks,

    ~Matt
  148. Web components for Ruby?[ Go to top ]

    That is why KISS for complex applications..V

    This is something that is increasingly puzzling me. Is there any real evidence that 'complex application' developers have been significantly misled into doing things in ways that are too complicated? Or, perhaps the truth is that they have largely been using appropriate tools and frameworks to give robust and scalable systems? On the contrary, my personal experience and belief is that the opposite is true - that there are frequent problems caused by developers choosing technologies that make initial development fast, but end up being a maintenance, scalability and support nightmare. All it takes is a small proportion of such 'KISS' projects to need significant change or re-writing to allow scaling for the supposed savings of development time to be lost.
  149. Web components for Ruby?[ Go to top ]

    Matt, I did not spend any time on Ruby vs Groovy. Groovy has Gails..... but I use it for back end, ex Spidering... I don't do HTML apps any more, only RiA.

    This is something that is increasingly puzzling me. Is there any real evidence that 'complex application' developers have been significantly misled into doing things in ways that are too complicated? Or, perhaps the truth is that they have largely been using appropriate tools and frameworks to give robust and scalable systems? On the contrary, my personal experience and belief is that the opposite is true - that there are frequent problems caused by developers choosing technologies that make initial development fast, but end up being a maintenance, scalability and support nightmare. All it takes is a small proportion of such 'KISS' projects to need significant change or re-writing to allow scaling for the supposed savings of development time to be lost.

    Steve, for the 1st 7 years of my development, I was proud that I could develop complex apps. Then I got ashmed of it.
    This might inspire you, from my company's internal wiki/cut-paste, maybe one of touches you, they all say same thing

    .V :

    Controlling complexity is the essence of computer programming.
    -Brian Kernighan

    The difference between a good and a poor architect is that the poor architect succumbs to every temptation and the good one resists it.
    -Ludwig Wittgenstein

    Simplicity does not precede complexity, but follows it.
    -Alan J. Perlis

    Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
    -Antoine de Saint-Exupéry

    The differences are not minor – they are rather like the differences between Salieri and Mozart. Study after study shows that the very best designers produce structures that are faster, smaller, simpler, clearer, and produced with less effort.
    - F. P. Brooks

    Fools ignore complexity, experts avoid it; geniuses remove it.
    -Alan Perlis

    Complexity is a sign of technical immaturity. Simplicity of use is the real sign of a well design product whether it is an ATM or a Patriot missile
    - Daniel T. Ling

    The ability to simplify means to eliminate the unnecessary so that the necessary may speak.
    - Hans Hofmann

    ...Simplifications have had a much greater long-range scientific impact than individual feats of ingenuity. The opportunity for simplification is very encouraging, because in all examples that come to mind the simple and elegant systems tend to be easier and faster to design and get right, more efficient in execution, and much more reliable than the more contrived contraptions that have to be debugged into some degree of acceptability....Simplicity and elegance are unpopular because they require hard work and discipline to achieve and education to be appreciated.
    -Edsger W. Dijkstra

    Simplicity is the soul of efficiency.
    - Austin Freeman

    One of the great skills in using any language is knowing what not to use, what not to say. … There's that simplicity thing again.
    —Ron Jeffries

    A designer can mull over complicated designs for months. Then suddenly the simple, elegant, beautiful solution occurs to him. When it happens to you, it feels as if God is talking! And maybe He is.
    —Leo Frankowski

    Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.
    - Revised Report on the Algorithmic Language Scheme

    Increasingly, people seem to misinterpret complexity as sophistication, which is baffling—the incomprehensible should cause suspicion rather than admiration. Possibly this trend results from a mistaken belief that using a somewhat mysterious device confers an aura of power on the user.
    —Niklaus Wirth

    A charlatan makes obscure what is clear; a thinker makes clear what is obscure.
    —Hugh Kingsmill

    Newton was a genius, but not because of the superior computational power of his brain. Newton's genius was, on the contrary, his ability to simplify, idealize, and streamline the world so that it became, in some measure, tractable to the brains of perfectly ordinary men.
    —Gerald M. Weinberg

    Comprehensiveness is the enemy of comprehensibility
    -M. Fowler

    Elegance is not optional.
    - Richard A. O'Keefe

    The best programmers write only easy programs.
    - Michael A. Jackson

    It is vain to do with more what can be done with less
    - William of Ockham

    Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defense against complexity.
    - David Gelernter

    Restraint shows the master’s hand
    - Johann Wolfgang von Goethe

    Any fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction.
    -E.F. Schumacker

    Simplicity is the ultimate sophistication.
    - Leonardo DaVinci?

    The sculptor produces the beautiful statue by chipping away such parts of the marble block as are not needed - it is a process of elimination.
    - Elbert Hubbard

    Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.
    - Charles Mingus


    The Principle of Least Surprise

       1. http://www.ilstu.edu/~asharm4/quotations.htm
       2. http://www.vanderburg.org/Misc/Quotes/soft-quotes.html
  150. Web components for Ruby?[ Go to top ]

    I like the qotes, but I'm worried that RoR might have violated an important one.

    "Things should be as simple as possible, but no simpler!"

    - Albert Einstein
  151. Web components for Ruby?[ Go to top ]

    See.... for a complex application .. it's harder to use a complex platform,
    See what? Harder than what? It really depends on ones view of complexity. I would say VB is simple compared to Java. But it (VB) is much more difficult to use in a "complex" application (ie multiple projects - exe + dlls).
     ie, it's easier to use a simple platform for a larger application.
    Well, is the larger application complex? Or is it just larger?
    Else you are knee deep in aligators.
    I wouldn't want to be knee deep in piranhas either.

    That is why KISS for complex applications..V
    Assuming that your "proof" is true.

    Tinker toys and Erector Sets are simple and I can easily build small buildings, vehicles out of them. But should I build large buildings out of them? Something I want to live in? Bad example you say? Ok. Using nails and 2x4s (and some other materials) I can build houses. Nails are quicker than screws. And 2x4s are lighter and cheaper than 2x6s. Excellent - KISS. Now let a hurricane hit that house. Hmmm. Seems like now only the 4th S from KISS applies.
  152. Web components for Ruby?[ Go to top ]

    Analog boy,

    I meant to also include in my last post that I agree with what you said in your post. I just wanted to explain myself a little better. I have been making snoby and childish comments in this thread because I'm getting tired of people continualy compairing RoR and J2EE, not because I have anything against RoR.

    ~Matt
  153. Web components for Ruby?[ Go to top ]

    sorry, wasn't actually having a pop at you at all!

    there are a lot of developers in corporate environments that learned java at university and don't spend time looking over the fence at how other communities achieve similar goals. There is a lot to be gained from spending time looking at how other people work and there is a lot of innovation happening outside of the java commnuity. Even if threads like this fail to convert people, hopefully it will get them to at least take a look and see what they can bring back to our community.

    i don't think there is much wrong with java development right now. what we do need is more tool support to cut down the time doing the repetitive, boring and error-prone work. but there is also plenty happening in that space and we are lucky to have freely available tools like eclipse to help. a few better plugins and we'd be in great shape ;)
  154. Web components for Ruby?[ Go to top ]

    This kind of thread should not be seen as pure diatribe, but as a way for us to learn how people are dealing with everyday problems using different technologies. Instead of just saying "is it BS!", we should focus on learning what works and what doesn't in other technologies in order to apply it to Java and end up improving it and make it more useful for everyone. IMO, every technology has something to add, even if it is about how and when NOT to do something.

    Regards,
    Henrique Steckelberg
  155. Despite that I myself an old-time devoted Struts user, I have to say that Struts is not the only and not the best Java web framework. Comparing stuff that is claimed to be the best thing since sliced bread with an oldtimer says something about quality and of the new kid on the block and about its [lack of] new ideas.

    The author drew action hierarchy. He obviously have not heard about Struts DispatchAction. If he wanted more, he could create stateful dialogs, components and wizards as well, and all this in crusty old Struts.

    "While Ruby on Rails is a very new and exciting framework that has generated considerable interest in the Web development community, the core architecture follows the basic patterns found in J2EE." Then what is the point to switch? If I wanted something new and exciting I would rater try Wicket or Tapestry.

    --
    Dialogs for Struts:
    http://struts.sourceforge.net/strutsdialogs
  156. Catalyst[ Go to top ]

    A word for Perl world:
    have a look to Catalyst.
    Inspired from RoR and being much more powerfull than any MVC framework I have seen so far ...

    Rgds,
    José.
  157. Trails[ Go to top ]

    Here is my obligatory Trails pitch. If anyone actually bothers to read this thread this far, you might want to check out Trails. Trails is not a port of Rails, but it is an attempt to make Java web app development more productive by borrowing as many useful ideas from Rails (and other sources) as we can.

    http://trails.dev.java.net

    --Chris
  158. I just can't understand why people are excitied about Ruby on Rails as a technology. I hadn't looked at it before, but from reading the article it looks like they took Struts/Hibernate as a base, removed all the configuration flexibility and hardcoded the domain objects to look exactly like the database schema.

    That last part just puzzles me beyond belief. Have they never seen what a real production database schema looks like? Something that has more than 3 tables in it. Thats going to be the domain model I'm going to be stuck working with?

    This is what all the buzz is about?
  159. I hadn't looked at it before, but from reading the article it looks like they took Struts/Hibernate as a base, removed all the configuration flexibility and hardcoded the domain objects to look exactly like the database schema.


    I think that most middle ground of good practices is Apache's version of Sun PetStore:
    http://ibatis.apache.org/petstore.html

    (assuming you ignore PHP like Tiki-Wiki or Drupal or Plone... or RiA ;-) )
    .V

    ps: good to be back :-)
  160. I just can't understand why people are excitied about Ruby on Rails as a technology. I hadn't looked at it before, but from reading the article it looks like they took Struts/Hibernate as a base, removed all the configuration flexibility and hardcoded the domain objects to look exactly like the database schema.

    No, it is even worse. The domain objects are dynamically generated at run time from the schema, not hard-coded.
    That last part just puzzles me beyond belief.

    Me too.
    Have they never seen what a real production database schema looks like? Something that has more than 3 tables in it. Thats going to be the domain model I'm going to be stuck working with?

    As I mentioned above, you aren't stuck with a domain model. You can't even define the domain model. To quote from the Rails documentation: "Data definitions are specified only in the database". So, you deploy your application, and someone changes the schema and your domain model changes!
      
    This is what all the buzz is about?

    I'm afraid so.
  161. Oh, come on![ Go to top ]

    No, it is even worse. The domain objects are dynamically generated at run time from the schema, not hard-coded.

    Yes, its right.
    As I mentioned above, you aren't stuck with a domain model. You can't even define the domain model. To quote from the Rails documentation: "Data definitions are specified only in the database".

    You CAN define your domain model (omg...) DATA DEFINITIONS are specified only in database. You are free to create your classes based on your rules.
    So, you deploy your application, and someone changes the schema and your domain model changes!


    Yes, thats the idea, man!! The big idea behind Rails is "DRY, Don't Repeat Yourself". Why should you change 15 places just do add a "information in a screen"? I mean, why should one add a database field, change one or two hibernate xml files, change the VO, change the DAO's, change the JSP/Velocity, change the FormBean, change the....... Does this makes sense to you? We are all programmers! We do automate things, don't we? At least, we should...

    Rails *automates* this kind of REPETITIVE task by using the ActiveRecord GoF pattern AND the Ruby reflection engine. So, whats the problem? We kept the encapsulation and all other 'best practices'. So, if you need to change the accessor/mutator method for a property, you can do it. Instead of just doing repetitive tasks, focus on your business (btw, isn't it what all java frameworks promises). With the time you got having all this automated, you can make better tests, better documentation, better UI!

    btw, have you seen the Rails helper methods for the UI? Check it out: http://script.aculo.us/demos/ ;-)
  162. Oh, come on![ Go to top ]

    So, you deploy your application, and someone changes the schema and your domain model changes!
    Yes, thats the idea, man!!

    Let's think of a fun example of how this can be disastrous.

    You set up a RoR app to present a list of information. It is a long list, but as the schema is small it does not matter. Some else modifies the schema and to add a lot more data to the tables. They add a big text field and put in lots and lots of characters for each record. This extra field will automatically become part of your Ruby classes and will get loaded in as well. Your application turns from light and fast to a very slow memory hog. You see, the mapping files in systems like JDO and Hibernate are there for a very good reason - they are not a result of some crazy obsession with XML.
    The big idea behind Rails is "DRY, Don't Repeat Yourself". Why should you change 15 places just do add a "information in a screen"? I mean, why should one add a database field, change one or two hibernate xml files, change the VO, change the DAO's, change the JSP/Velocity, change the FormBean, change the....... Does this makes sense to you?

    Of course it does. I don't have to change all this with my Java development. Perhaps you have heard of 'refactoring'? I change my bean property and my IDEs refactoring tool locates all references to that bean, and can update all those references for me automatically (even in configuration files). Then, my JDO workbench can automatically update the schema for me. That is DRY - remember, I changed things in just one place.
    We are all programmers! We do automate things, don't we? At least, we should...Rails *automates* this kind of REPETITIVE task by using the ActiveRecord GoF pattern AND the Ruby reflection engine. So, whats the problem?

    The problem is you are wrong. Rails does not automate all this. It automates the first pass through all this, and then it is up to you. Suppose you have generated some web pages with scaffolding, then you amend them manually (as you will have to do to have anything presentable). You then end up with the tedious task of having to change all those pages if you change the schema, and change the data classes.

    With a Java system there are mappings that protect your code from such changes.

    You see, it is Java (with a good refactoring IDE) that is DRY, not RoR.
    We kept the encapsulation and all other 'best practices'. So, if you need to change the accessor/mutator method for a property, you can do it. Instead of just doing repetitive tasks, focus on your business (btw, isn't it what all java frameworks promises).

    Yes, and it is what a lot of them (especially when combined with good IDEs) actually deliver.
    btw, have you seen the Rails helper methods for the UI? Check it out: target="_blank">http://script.aculo.us/demos/ ;-)

    Pretty basic. Have you seen the Oracle ADF JSF components?
    http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/doc/tagdoc/core/imageIndex.html

    Rather more impressive, perhaps?
  163. Java CRUD Framework[ Go to top ]

    Jdon Framework is a rapid development framework too, include create/read/update/delete CRUD operations, and it is a Ioc/AOP Framework, all components are configurable.

    Jdon Framework project and Jpetstore implementions click here:
    http://jdon.sourceforge.net/
  164. Some Comments[ Go to top ]

    I'm pragmatic enough to use Rails for smaller projects where I would otherwise have used PHP. For more complex things I always run into problems.

    Some Rails observations:

    Ruby is a mess. Not as bad as Perl/CPAN though. I'm talking about inconsistencies between modules both in Ruby and on the Ruby module archives. Of course it happens because people have different coding styles and nobody tries to mandate a style or patterns to be used. It usually takes some effort to connect things together or to resolve namespace issues. (Happens less though, but mixins can be evil)

    Rails is just for web apps. Most of my apps have components behind the web app. Think about workflows, timers, queues, etc. All the good stuff that is specified in J2EE. With Java you run this in a nice container like Spring, Geronimo, or JBoss. In the Ruby world, if such a service is available, you start a script on the command line or do things from cron. For me that is a huge step backward. I love to point a JMX tool to my app server and let it put throughput of a queue in a graph.

    Rails is extremely simplistic. This is of course also its greatest strength. If you just look at the web part then you can compare that mostly to raw servlets. There is no workflow framework, no good validation (see below), no automatic conversion of input data to objects like Spring does, etc. For me that is always pretty dissapointing because I feel like I'm 10 years back in time. When I work in Rails I always have this 'lets put a nice framework on top of this to make things easier' feelingThat was common to do in the early 90s when we all did that in our Perl/PHP/Java frameworks. Those more functional frameworkshave been here for a while now though, the Rails people have just never properly looked at them. Rails is now version 0.13 though, so maybe there is a lot of good stuff to come. Ruby is an excellent dynamic language to make Stuff from Spring even more easy to use for example.

    Rails validation sucks. There is an infrastructure for validation but it is closely tied to the domain objects. This is probably because the Rails people assume that you will never use a non-domain object in a form. So, it is not possible to define a PORO (Plain Old Ruby Object) to be used for forms and define validation on that. There is simply nothing in Rails that compares to Spring's Command and Validation patterns. And those are pretty basic.

    Scaffolding; overrated. Nobody uses it in a production app because it never does what you really want to do. I use it a lot in quick hacks and admin forms, but that is about it.

    AJAX: Cool stuff. Really. I wish Java frameworks would spend more time on this too. The Wicket people are doing good stuff in that area.

    Development Time: For large projects with skilled programmers I don't think there is much difference between doing stuff in Rails or a proper combination of Java technologies. I really don't care that I have to spend a couple of hours on defining my domain model as it is a tiny part of the totl time spend on the whole project. The one thing that I do like is that you can edit/reload in Rails without too many complete server restarts. Java is also getting better at this (with Wicket I can edit both code and html live without having edit/build/deploy cycles) but Rails is sure the winner there.

     S.
  165. Some Comments[ Go to top ]

    good points..

    there is also a serious lack of i18n support which would rule it out for many people. you'll notice that rails apps like backpack require that the user specifies their locale which would be tedious to management by hand.
  166. It puzzles me that the Ruby controller is shown as advanced because it is able to automatically map URLs to classes without additional configuration. This is what servlets have done since its beginning, and thus the Servlet servlet has been an MVC controller since the start. Then, I wonder why this simple mechanism has been overriden by so many bizarre ways during all these years. Maybe it is just a long trip to go back to the place we started from. (Granted, servlets can't map to methods or make variables appear automatically, but it would not be much difficult to do so - maybe even a good idea, if the proper security mechanisms are put in place too).

    The phrase "ActionControllers are also a logical place to group all processing of specific domain logic" does not sound much trendy today, but I guess it can be taken as "ActionControllers are also a logical place to invoke the specific domain logic in the Model classes".

    As for the redirection between actions, Ruby follows the old approach of embedding the control in the code, instead of an additional definition level of result codes like Struts. Again, not much trendy or complex, but easy and effective.

    As for the persistence mechanism, ActiveRecord seems a much easy and intuitive approach than Hibernate.

    In summary, from my point of view:
    - from the MVC point of view, Ruby seems to me as MVC as plain servlets, plus much useful additions. It is not that servlets are not MVC, but from my point of view this puts in question the added value of so many model 2 frameworks agains plain servlets + templates or plain JSPs + backing beans.
    I do not know RHTML, but it sounds as something as bad or good as model 1 JSPs.
    (At any rate, I think that probably the best way of developing Java web apps is using JSF)

    - From the persistence point of view, Ruby seems to defeat Java by all means, with the possible exception of performance (about which I do not know). In particular, the metaprogramming features seem just such a nice feature, moreover if you compare it to the equivalente Java mechanism of bytecode rewriting.

    All in all, Ruby seems much interesting. I keep hearding about it.
  167. From the persistence point of view, Ruby seems to defeat Java by all means, with the possible exception of performance (about which I do not know).

    On the contrary, having the data model defined dynamically by the database is an old-fashioned and fragile system, and something that can lead to serious maintenance and migration problems.
  168. From the persistence point of view, Ruby seems to defeat Java by all means, with the possible exception of performance (about which I do not know).
    On the contrary, having the data model defined dynamically by the database is an old-fashioned and fragile system, and something that can lead to serious maintenance and migration problems.
    This argument about dynamic things can be applied to all of Ruby, which has no static typing or anything. I think the standard answer to that from Ruby adepts is that good tests solve it, among many other things (e.g. see http://www.martinfowler.com/bliki/DynamicTyping.html). And, if you do not like to directly access the ActiveRecord directly but want another static, protective layer, you can always write it on top.
  169. From the persistence point of view, Ruby seems to defeat Java by all means, with the possible exception of performance (about which I do not know).
    On the contrary, having the data model defined dynamically by the database is an old-fashioned and fragile system, and something that can lead to serious maintenance and migration problems.
    This argument about dynamic things can be applied to all of Ruby, which has no static typing or anything. I think the standard answer to that from Ruby adepts is that good tests solve it, among many other things (e.g. see http://www.martinfowler.com/bliki/DynamicTyping.html). And, if you do not like to directly access the ActiveRecord directly but want another static, protective layer, you can always write it on top.

    Tests don't help, as this fragility is not just an issue during development, it is a problem after deployment. Suppose your client decides that the database that your Rails app uses is so useful that it can be used by other applications. Of course, a couple of fields need to be added, but that should be OK.... What are you going to do - provide the entire development test suite to the client?

    I am very familiar with the static/dynamic typing argument, having used languages with both over 30 years. My experience is that you can't beat static typing for real robustness. Tests may do most of the job, but there may always be some area of code they don't reach.

    As for the 'you can always write something better' - well, yes, that is true, but it is hardly a supportive argument for Rails. Rails may be fun and cool and trendily dynamic and fashionably avoids XML, but I'm afraid that to me it seems to be seriously flawed. (And as for Ruby the language... I had better not start!)
  170. After spending the better part of the morning reading this thread, the main question the comes to mind is: even if I’m developing an application in RoR sweet-spot, is it all that significantly superior compared to using J2EE plus a real good IDE and a pre-packaged, tested and integrated stack of components like JSF, Spring, EJB3, JDO, Hibernated, (not really attempting an exact list here) etc… That is, well mature components which have been well tested and integrated.

    Both attempt to achieve the "Do Only Once" paradigm (a noble and worthy objective), and both achieve this goal to various degrees.

    It seems to me, if I want guaranteed quality, production proven worthiness, a guaranteed ability to handle and solve arbitrary problems (i.e. transactions, legacy interfacing, whatever, etc...), and reasonable mulit-vendor commercial support, "modern" J2EE is a wise choice and prudent choice.


    Steve Punte
    JXReports