Ruby on Rails is stirring up the waters in the Java world. Matt Raible, the man behind AppFuse (kickstarting J2EE development), has been "thinking about Rails ever since I wrote a post about it".
The thoughts must have lead to some frustration with his current environment, though. Here's his description of why doing a CRUD on a single database table would flunk any productivity test:
...if I did it right now in AppFuse's current state, it'd be a disaster... To CRUD a database table using AppFuse you have to create 11 new files and modify 5 existing files. 16 files. What a beotch, huh? If I made a video of this - it'd be 20 minutes long!
While this might make AppFuse look silly, it's really more of a symptom of the patterns we have in J2EE and how we're supposed to architect our apps. 3 tiers, test-driven, loosely-coupled and internationalized.
Compare this to the Rails approach:
class Post < ActiveRecord::Base
# All attributes are given accessors
# through column introspection
end
class WeblogController < ActionController::Base
# The controller now has actions for all
# CRUD operations and uses introspection
# to select the input fields and columns
scaffold :post
end
I'd be depressed too if my environment forced me to go through a 20 minute setup phase (and that's for an expert, I'm sure creating and updating 16 files could easily take longer for people less skilled than Matt).
Naturally, this has spawned interest in remedying the situation for Java. Enter Trails by Chris Nelson:
The Trails framework is a domain driven development framework inspired by others that have gone before it such as Rails and Naked Objects. Its goal is to make developing database-driven web applications in Java radically easier, faster, and more fun. The basic approach is to eliminate as many of the steps as we can.
While I laud the aspirations for easing the pain that is J2EE, I'd advice treating the disease rather than the symptoms. Which is of course while I keep stressing the use of Ruby on Rails instead of just Rails. Rails cannot happen in a language like Java. Approximations will try, though.
But if you're stuck with J2EE as a fear-driven technology choice made by higher powers, I most certainly recommend checking out Trails. Chris is picking thebestinfrastructure J2EE has to offer and will attempt to make it fit like Rails. That's a great starting point and a good vision. Best of luck!
Challenge by Keat on October 29, 12:55
I have been thinking about Rails, too, ever since the first article.
And I like it, having tried my hands in it too.
However, changing jobs (none yet, in Asiapac) or convincing the company to junk J2EE (used to build the several-year-old company core product) just isn't feasible. Yet?
I understand the language plays a big part of why Rails is Rails.. still, efforts to port over the "Rails-way" to Java (or other languages) give people like me a sliver of a chance to live it in our working hours. End of the day, what really captures me is the "Way".
Wiki is the Way for a niche purpose. PHP/Perl/Java/Python Wikis? The more the merrier.
Oh, I totally agree. If you're stuck in J2EE (can't change jobs, can't convince higher powers) then Trails sounds like a fantastic project!
If you're not stuck, though. Either because you are working on a personal project, have the power to influence the technology used at your company, or see an opportunity to work with Rails at one of the trend-setting companies, I'd wonder hard why you wouldn't go with the real thing.
Seems like you'll have to use those Jedi mind tricks once again. Remember the "show, don't tell" philosophy, which applies to convincing your management perhaps even more than to convincing fellow programmers. If at all possible, try simply starting off in Rails, and show how this makes your life easier and more productive, and at the end of the day, results in a better product.
I agree with Marten,
Its not hard to convince anyone about superior technology if its a win win situation. The next time you have to make this boring admin interface for internal use, do with rails. Sit down, draft the entire thing up using scaffolding in a day. Than invite the people involved to talk about what you have and where you will be going. The question how the hell you got where you were at this point in the project will fall and you can share that you are "evaluating this technology the internet has been raving about" and how it amazes you.
The trick is to play the convinced instead of the convincer, if you tell them how well it worked they will agree and remember when the next projects are started up.
I know this is a bit off topic, but I figure it fits into the 'fear/dominant technology' theme kicking about here.
I have been hesitant to learn ruby or use rails.
I just can't seem to find any good web hosting for ruby projects. I'm not about to use the first host I can find. I've been burned before. I'd rather have one reccomended to me.
TextDrive is the place you want to be. I'm personally involved with the operation and making sure that Ruby on Rails runs perfectly. They have the latest version of Rails installed as gems and you can even run FCGI.
I've never used app fuse here, but we use spring/hibernate/xdoclet here at work, and I think it's the best solution to dealing with J2EE's design issues. Part of the problem is that J2EE is solving a much broader problem domain than building CRUD web applications so it's not exactly fair to judge it compared to a focused solution, and part of the problem is that J2EE sucks. I have the descision making power here to switch future projects to Ruby (or whatever) and it looks very interesting -- I've just starting looking into it and am certainly going to be messing around at home with it -- but there are currently too many unknowns.
I don't know if this is the right forum, but by main question is:
How does ruby scale? (i.e. what large sites have successfully used it?)
- Not supporting native OS threads seems like a major no-go to me.
- Non-generational mark-and-sweep GC strategy seems extremely lame.
Challenge by on November 01, 17:56
well, basecamp is the common example for rails.
There are lots of other ruby samples not built on it, so we can suppose it does scale, somewhat.
Ruby supplies to the non native os thread problem the way it is done in many other cases: using processes.
Given that on common unix implementations (i.e. linux) threads and processes are built upon the same syscall (clone() for linux, freebsd has something similar) this seems ok.
Anyway, to scale the core idea is to avoid sharing stuff, leaving the central coordination role to the DBMS. This way you can simply add another web frontend and another coordinated dbms to scale up your application.
Some stuff will be shared, anyway, I can think of the db connection pooling done from fastcgi. It is basically the same approach found in most enterprise solutions done in perl or python or php.
I never really found the need for something different, except in realtion to messaging.
I'd like to have something like JMS for ruby, to leverage al those great messaging engine out there. But I should dig a little into Rinda and Ring, to check if they can fit for some stuff (basically Rinda is similar to JavaSpaces, while Ring is similar to Jini)
About GC.. GC in ruby seems fast enough, but I'd like it to be a 3color generational with write barrier. It sounds much better, even if it may not have an dvantage ;)
Right, I'm only passing judgment on J2EE as a platform to create web-applications -- not it's ability to integrate with bank systems from the 70'ies. But it seems to me that plenty of companies are using J2EE for run-of-the-mill web stuff, which what I think is inefficient.
The problem is probably figuring out where that cut-off point is. When does heavy-handed frameworks like J2EE or .NET start to pull their own weight? I think that cut-off point is much higher than most people would expect.
And I think that people have this misconception that the dynamic languages are unsuitable for "mission critical" applications. Which I believe is a rather silly notion. As a recent example to the contrary, look at the Kapital system that Cincom Smalltalk has been touting as a big win for JP Morgan in advanced trading systems.
Please do let me know what those unknowns are and I'll try to make them 'knows ;) But you're certainly on the right direction. Ruby on Rails is so easy to get into that the only sane way to have a look is just by trying it out.
Rails uses a Share Nothing approach combined with either mod_ruby or Fast CGI, which means that threads and GC strategies doesn't really matter too much. Concurrency is something the database deals with and all the web processing is basically just serialized (through isolated parallel process, of course).
So Ruby on Rails basically scales as deep as your database is able to scale just by adding additional web/application servers.
Challenge by Will on November 01, 20:22
My main issue with ruby's threading approach is that I don't want to further complicated my code with interprocess communication in addition to dealing with multithreading issues. Shouldn't a smartly written threaded application get twice the speed if deployed on an SMP box? All of our production boxes now at at least 4 way, and its easier for me to bind the java vm across all the CPUs, and limit the multiple-process communication to JMS synchronization messages. (Everything else, as you say, is treated as a data issue and pushed to the DB.)
Is there any messaging solution like JMS for ruby? For things like batch-job queuing or the like? What does rails/ruby do for webservices or remoting?
Another issue I'm wondering about is database HA. Right now I favor using oracle in a veritas cluster, and database connections going through a veritas virtual ip. When the database goes down, the datasource drivers sitting ontop of the connection pooling is smart enough to catch SQL exceptions and attempt to reconnect to the new database. I haven't looked at the database pooling strategy of rails, but I would assume that you could build something similar on top without too much difficulty.
I don't really see any issue with "dynamic" languages, per se. There's certainly something to be said about the benefits of programming with a type system to prevent a certain class of bugs from presenting itself, but I think the bigger issure has to do with raw performance. Namely, I think a lack of JIT/HotSpot type technologies is an actual problem. But that's more towards intepreter maturity than a language construct issue.
Its probably time for me to start poking under the hood rather than asking high level questions, but I've got one more anyway. How does the Share Nothing approach deal with maintaining inmemory session data? (My impression is that mod_ruby has everything running inside of the apache process, and that fastcgi passes everything off onto a long running ruby process.) Does whatever load balancing trick available use session affinity so that each session gets routed back to the same 'app server' instance or is there some sort of serializing/marshalling to a common datastore technique deployed?
I'm a big fan of app-level caching, even with the distributed cache coherence issue involved. It's fairly straightforward to send a "object x has been modifed flush from cache" message to a cluster using JMS, but the share nothing technique eschews all of that and trusts the database. (Hibernate, as an aside, also recommends not doing app caching and letting the DB deal with that.) But high volume browse type sites really benefit from the using memory io vs network+disk io of a database. The traffic metric I'm trying to hit is 300 req/second, for data which is effectively static (i.e. changes once a day).
I don't think you'd get 300 req per second withouth large hardware and replication, but you may get it.
Anyway Rails is really non-optimized (david strictly followed the 'premature optimization is the roo of all evil' , it seems :)
Simple inteprocess comunication is really easy to do with RingServer and rinda, so you may do tour cache invalidation trick with 'em.
There are people (I'm thinking of noaa.gov) using ruby in large distributed environments, and they seem quite happy with it.
Anyway, on the side of EAI the java solution seems still better. I don't think Rinda can bridge MSMQ or Tibco the way jms does. But it's just yet another example of 'use the right tool for the job' :)
Have their been thoughts to find further performance optimizations in Rails to support higher transaction volumns? I'm looking at Rails as truly incredible for developer performance, but limited to low volumn applications. Its seems that performance degrades considerably even on simple queries. The webserver performance doesn't seem to be an issue.
