tag:blogger.com,1999:blog-22587889.post1618544901993367932..comments2024-02-11T13:21:47.930+05:30Comments on Ruminations of a Programmer: Party time Over for Rails .. It's time to Deliver !Anonymoushttp://www.blogger.com/profile/01613713587074301135noreply@blogger.comBlogger21125tag:blogger.com,1999:blog-22587889.post-89090103961244966292007-10-22T19:21:00.000+05:302007-10-22T19:21:00.000+05:30for jeremy: I really don't understand why you thin...<I>for jeremy:</I> <I>I really don't understand why you think it's harder to scale up a development team in a dynamic language.</I><BR/><BR/>Lack of static type safety in API design - I may be biased, but still feel that it is extremely difficult to scale up in a development team without the safety net. You have the unit tests, but, I don't think unit tests are an alternative to type safety. I usually do not put forward a straw man argument, but here, I have to, since at least in my part of the world we do not often get the ideal team composition of quality members who can live up to the dynamics of a dynamically typed language in a big project.<BR/><BR/><I>You also continue to claim that ActiveRecord is not capable of handling more than a "handful" of entities.</I><BR/><BR/>ActiveRecord mixes up the two concerns - the domain and the persistence. This is difficult to scale in a domain rich application, since ur domain model is now tightly coupled with the persistence model.<BR/><BR/>Cheers.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-68042590756150565672007-10-21T08:27:00.000+05:302007-10-21T08:27:00.000+05:30I really don't understand why you think it's harde...I really don't understand why you think it's harder to scale up a development team in a dynamic language. Do you have any evidence, or even any anecdotal experience, to back this up? I understand that concern that explicit typing provides a certain amount of documentation-in-code, but that has its own costs, and doesn't always tell the whole story, and I just don't think it's as significant as you seem to. <BR/><BR/>I'm someone who worked with statically-typed languages for over 10 years and switched to a Rails project consisting of tens of thousands of lines of code (plus tests), and I didn't have much trouble getting up to speed on the code.<BR/><BR/>You also continue to claim that ActiveRecord is not capable of handling more than a "handful" of entities. What constitutes a handful? What is it about ActiveRecord, or Rails in general, that is limiting in this regard?<BR/><BR/>Rails wasn't designed to be the be-all-end-all framework for every business environment. It doesn't fit in a lot of enterprise applications for a variety of reasons -- other languages and frameworks don't fit either, for the same and different reasons. It also doesn't fit in many non-enterprise projects. This doesn't mean ANYTHING.<BR/><BR/>That said, Rails IS being used (successfully) in the enterprise, apparently increasingly so, and likely for the forseeable future. However, as others have already pointed out here, most software projects are NOT enterprise projects. Lots of people don't WANT to work on enterprise projects (it's hard to think of a good reason to want to), and it just so happens that a large cross-section of those people like a lot of Rails is selling. Concepts like convention over configuration, do the simplest thing that could possibly work, AJAX, REST, and the pure (admittedly subjective) elegance of the Ruby language are all very good reasons to like Rails.<BR/><BR/>It's funny that people who use and support Rails are labeled "fanboys", when something close to 99% of Rails developers have more experience with other platforms than you do with Rails, and probably more experience with said other platforms.Jeremy Weiskottenhttps://www.blogger.com/profile/01868696039970401724noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-73078755415519702282007-09-29T09:31:00.000+05:302007-09-29T09:31:00.000+05:30"The completely dynamic nature of the language ten...<I>"The completely dynamic nature of the language tends to compound the complexity of the application, and turns it into the worse nightmare in any development team of decent size and attrition rate."</I><BR/><BR/>+1. It is very difficult to scale up a development team programming in dynamic language. I have mentioned this earlier also and has been dismissed as the strawman argument by Ruby fanboys.<BR/><BR/>However, in this post, my main argument is NOT Ruby. It is Rails and the main issue which I have is that the Rails community always dismiss enterprise apps as something not worth their consideration in their forte. But they do not admit that the basic design of Rails along with Active Record model and a coupled domain-persistence paradigm never enable them to go beyond a handful of entities. Some of them point to JRuby as the solution, which unfortunately is nothing for than a jar in a Java app server, given the pathetic state of Rails deployment.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-39217494019940360502007-09-29T02:14:00.000+05:302007-09-29T02:14:00.000+05:30@Debasish,Funny I ran into this one right after re...@Debasish,<BR/><BR/>Funny I ran into this one right after reading Weiqi Gao's post discussing <A HREF="http://www.weiqigao.com/blog/2007/09/26/unit_tests_are_not_enough.html" REL="nofollow">the lack of static typing in ruby</A> - and an earlier piece, <A HREF="http://www.weiqigao.com/blog/2007/09/20/the_end_of_the_ruby_hype_re_top_10_reasons_java_sucks.html" REL="nofollow">The End of The Ruby Hype</A>. I for one agree with the points made by both of you. RoR's difficulty to scale manifests on more than one level. The completely dynamic nature of the language tends to compound the complexity of the application, and turns it into the worse nightmare in any development team of decent size and attrition rate.Jing Xuehttps://www.blogger.com/profile/01002689771296002774noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-20397204763090830152007-09-27T21:17:00.000+05:302007-09-27T21:17:00.000+05:30The least thing you want with your rich business d...The least thing you want with your rich business domain model is to tie it to a particular persistence mechanism, is shooting yourself in the foot. You are building a model hoping to reuse it across many applications and then, tying it to a particular database structure... a big no-no in my book. (of course, my book could be different than yours) :-)Anonymoushttps://www.blogger.com/profile/17525961934302794120noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-80408768790996823642007-09-26T22:12:00.000+05:302007-09-26T22:12:00.000+05:30"The whole JRuby movement is making it easier to i...<I>"The whole JRuby movement is making it easier to integrate Rails into the enterprise."</I><BR/><BR/>I agree and I have mentioned in my blog also. JRuby is the best bet with Rails for the enterprise. However, the unfortunate part is, in absence of a scalable deployment process, a performant virtual machine, JRuby still is just another jar sucked up in the JVM.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-2914641164284713632007-09-26T19:34:00.000+05:302007-09-26T19:34:00.000+05:30"why do all the Rails evangelists still shirk away..."why do all the Rails evangelists still shirk away from big enterprise applications branding them as *monstrous* ?"<BR/><BR/>Another generalization that just isn't true.<BR/><BR/>Sure, many Rails evangelists shirk away from enterprise apps, but how many do so because they don't want to deal with the overhead of enterprise clients, or prefer to work on shorter-term projects, or any number of other perfectly valid reasons other than "Rails can't do it"?<BR/><BR/>There are Rails evangelists who would be perfectly happy to use Rails in an enterprise project. ThoughtWorks is leading the pack -- Mingle is geared towards the enterprise. The whole JRuby movement is making it easier to integrate Rails into the enterprise. There *are* enterprise projects going on with Rails.<BR/><BR/>There are reasons not to go into the enterprise. One is legacy databases, which I admit Rails/ActiveRecord isn't set up to handle, because a legacy database probably wasn't built around the conventions that ActiveRecord largely depends on. It's possible to solve these problems with Rails -- you don't *have* to use ActiveRecord, after all -- but it's usually just not worth it. USE THE RIGHT TOOL FOR THE JOB.Jeremy Weiskottenhttps://www.blogger.com/profile/01868696039970401724noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-56769024521463573042007-09-26T15:55:00.000+05:302007-09-26T15:55:00.000+05:30Nice blog.....thanks for the info....... Web 2.0 a...Nice blog.....thanks for the info....... Web 2.0 approach to enterprise application development is the first factor that makes our applications bring about a SEA-change.<BR/>Regards,<BR/>Rosy.<BR/>------------------<BR/>http://www.axaya.netAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-85593661476510783592007-09-26T10:56:00.000+05:302007-09-26T10:56:00.000+05:30@jeremy:"The persistence and business aspects may ...<I>@jeremy:</I><BR/><I>"The persistence and business aspects may be tightly-coupled, but the persistence part is mostly transparent."</I><BR/><BR/>With ActiveRecord in Rails, you are coupling a relational persistence model with an OO domain model. That way your domain model is a mere replication of the way things persist in the database. This approach is easy to implement with small models, but simply goes out of bounds with large and complex ones, where domain entities interact with each other through rich behavior, which are best modeled using OO abstractions.<BR/><BR/>And, if the Rails model of working with domain scales well, why do all the Rails evangelists still shirk away from big enterprise applications branding them as *monstrous* ? My main point of the post was that how long will Rails stay away from complex domain modeling ? Is it because they know that the technology they evangelize so much is not able to handle the monster ?Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-61720858785918412282007-09-26T06:13:00.000+05:302007-09-26T06:13:00.000+05:30"But if you can get out of the mindset that enterp..."But if you can get out of the mindset that enterprise apps must be huge and complex, then you may find that you can satisfy your business requirements with a fraction of the effort and cost using Rails."<BR/><BR/>Absurd.<BR/><BR/>"In practice, dynamic typing doesn't bite you as often as you might think. To put it in a pure Java analogy, consider how often (read: rarely) you put the wrong kind of object into a Java 1.4 collection and got a ClassCastException when getting it out. It's just not that big of a deal (but we ended up with generics anyway)."<BR/><BR/>Java is only statically typed to a degree; ClassCastExceptions and NullPointerExceptions are a problem, because now you have a language without strong runtime safely guarantees, but one that nevertheless has the drawbacks of static typing (more complex semantics, verbose without inference, ...)<BR/><BR/>I think modern static type systems (ML, Haskell, ...) are competitive with dynamic typing when it comes to conciseness and expressiveness, though.Slava Pestovhttps://www.blogger.com/profile/02768382790667979877noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-46293556420496834702007-09-26T06:10:00.000+05:302007-09-26T06:10:00.000+05:30This comment has been removed by the author.Slava Pestovhttps://www.blogger.com/profile/02768382790667979877noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-69593103482739979722007-09-26T01:02:00.000+05:302007-09-26T01:02:00.000+05:30Yes, it's possible. Why not? The persistence and b...Yes, it's possible. Why not? The persistence and business aspects may be tightly-coupled, but the persistence part is mostly transparent. Besides, what would be the benefit of decoupling them? In Java it's a common practice to be able to unit test business logic in isolation from CRUD, but that's not a concern with Ruby.<BR/><BR/>I believe that the complexity of a domain scales linearly in proportion to its size. What I mean is that a larger domain may be more complex in that it has more entities and more relationships, but it doesn't get exponentially or logarithmically more complicated with size. <BR/><BR/>The static vs dynamic typing argument is separate. Static typing has benefits, but so does dynamic/duck typing. In practice, dynamic typing doesn't bite you as often as you might think. To put it in a pure Java analogy, consider how often (read: rarely) you put the wrong kind of object into a Java 1.4 collection and got a ClassCastException when getting it out. It's just not that big of a deal (but we ended up with generics anyway).<BR/><BR/>The safety net is unit tests, not static type checking. You do write unit tests for Java apps, right? You would for Ruby apps too.Jeremy Weiskottenhttps://www.blogger.com/profile/01868696039970401724noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-31880817776165307612007-09-25T23:42:00.000+05:302007-09-25T23:42:00.000+05:30ActiveRecord is a DSL for relational models -- I w...<I>ActiveRecord is a DSL for relational models -- I would argue that an entity's relationships to other entities is part of the domain and business logic.</I><BR/><BR/>Do u seriously think that it is possible to maintain a Rails application consisting of a large number of entities sucked up with a tightly coupled relational ActiveRecord model and laced with APIs that offer no type checking ? I think this is where a separate domain model, decoupled from the persistence layer matters with the safety net of static type checking.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-79404569355576604842007-09-25T19:49:00.000+05:302007-09-25T19:49:00.000+05:30The quantity of entities in the model doesn't make...The quantity of entities in the model doesn't make it more complex. And there are only so many types of relationships (one-to-one, one-to-many, many-to-many), and just about any domain has examples of each. It might be harder to keep 600 entities straight in your head than 10, but I wouldn't argue that it's that much more complex.<BR/><BR/>As far as separation of concerns, if you have a framework that makes one of the concerns all but transparent, why does it need to be separated? ActiveRecord is a DSL for relational models -- I would argue that an entity's relationships to other entities is part of the domain and business logic.<BR/><BR/>The important thing is that this is in the model layer -- whether you separate persistence from business logic doesn't matter, it's still in the model (or should be). Separation of concerns is much more important when you're talking about business logic in views or controllers.Jeremy Weiskottenhttps://www.blogger.com/profile/01868696039970401724noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-58019957382863065132007-09-25T11:49:00.000+05:302007-09-25T11:49:00.000+05:30@radarlistender: There are plenty of examples. Typ...<I>@radarlistender:</I> There are plenty of examples. Typical ones come from the financial domain - any back office solution can be as large as having thousands of entities. See my last comment.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-48937073213559402562007-09-25T11:47:00.000+05:302007-09-25T11:47:00.000+05:30@jeremy: 1. A complex domain model is one which is...<I>@jeremy:</I> <BR/>1. A complex domain model is one which is big in terms of the number of entities as well as the relationships between them. Any typical enterprise application like back-office solutions for financial markets, investment bankings etc. qualify for being a complex enough domain model. I have been working on a back office trading and settlement solution, that has 600+ entities and a huge domain model.<BR/><BR/>2. Separation of concerns. The main advantage is that your data model and domain model can evolve independently with very loose coupling between them. The ActiveRecord model does not allow such separation.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-14572808767312782752007-09-25T09:17:00.000+05:302007-09-25T09:17:00.000+05:30Show me an "enterprise application" that requires ...Show me an "enterprise application" that requires a thousand models and I might start to believe some of the sputum that is spewed forth from these Rails haters.Radarhttps://www.blogger.com/profile/00543351735507911332noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-41593865161492000742007-09-25T01:40:00.000+05:302007-09-25T01:40:00.000+05:30"How long will Rails shrug away from the enterpris..."How long will Rails shrug away from the enterprise applications branding them as monstrous ?"<BR/><BR/>As long as it wants.<BR/><BR/>As much as some people are just now getting tired of what they call "Rails fanboy-ism", I'm getting tired of "enterprise" as being the be-all and end-all. There are only 500 firms in the Fortune 500, hiring a small percentage of the workforce. There are hundreds of thousands of small businesses in the US, millions more worldwide, that can't afford and probably don't need what typically gets labeled "enterprise".<BR/><BR/>If Rails never gets to the point of being considered "enterprise-worthy", so be it. All us non-enterprises will be happy for tools that meet <B>our</B> needs, rather than yours.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-40014182500956560952007-09-25T01:37:00.000+05:302007-09-25T01:37:00.000+05:30Two questions:1. How do you define "large complex ...Two questions:<BR/><BR/>1. How do you define "large complex domain model"? What makes a model "large" or "complex"?<BR/><BR/>2. Why is it important to separate the persistence layer from the domain model? What is the downside to combining them, and what is the benefit of separation?<BR/><BR/>I have my ideas about these, but I'm curious what your arguments are.Jeremy Weiskottenhttps://www.blogger.com/profile/01868696039970401724noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-25567706236848508072007-09-25T01:31:00.000+05:302007-09-25T01:31:00.000+05:30As long as you still believe that you need to buil...As long as you still believe that you need to build "large complex domain models" and "deliver big enterprise applications", then you aren't ready for Rails. <BR/><BR/>For some enterprise apps that have to build on legacy systems or legacy databases, those characteristics may be unavoidable. And those apps are probably not suited to Rails.<BR/><BR/>But if you can get out of the mindset that enterprise apps <B>must</B> be huge and complex, then you may find that you can satisfy your business requirements with a fraction of the effort and cost using Rails.ScooterPhttps://www.blogger.com/profile/15592694393416941037noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-69345215093980703222007-09-24T19:49:00.000+05:302007-09-24T19:49:00.000+05:30I just realized it: "easy to develop simple (CRUD)...I just realized it: "easy to develop simple (CRUD) applications", "ActiveRecord", "(almost) no domain model"... it reminds me of VisualBasic and Datagrids... is Rails trying to compete against Microsoft? :-DAnonymoushttps://www.blogger.com/profile/17525961934302794120noreply@blogger.com