Ruby on Rails for DB2 Developers

An anonymous reader writes "Ruby on Rails seems to be the new hotness in the world of web development, right up there with Ajax. IBM DeveloperWorks has a helpful howto on how to bring the worlds of Ruby on Rails and your DB2 framework together. From the article: 'Because Rails emerged from the open source world, until recently you had to use MySQL or PostgreSQL to work with it. Now that IBM has released a DB2 adapter for Rails, it's possible to write efficient Web applications on top of your existing DB2 database investment.'"

Comments

Ruby on rails?

[StaticFish]

In the UK we've only just got trains to go on rails.

Ruby could be packaged better

[bogaboga]

I have read about the beauty of Ruby and how it's better than Python or Perl. I'd not like to start flames but I wonder why Ruby does not have an IDE like that of SmallTalk. Yes, SmallTalk is old time stuff, but this absence does not help Ruby's popularity.

Many times, I have tried learning it on my own and have been frustrated by missing or conflicting versions of components. I'm waiting for some folks to develop a one install package that will take care of all packages needed to develop serious apps on Ruby. An IDE like Access on the JET database engine would be very welcome.

There is some effort to this end. These folks http://www.railslivecd.org/ have started some work in this direction.

Re:Ruby could be packaged better

[ricardo_nz]

You should try Ruby Gems to solve your packaging woes. As for an IDE, there are plenty available: http://freeride.rubyforge.org/wiki/wiki.pl and http://www.mondrian-ide.com/ though I can't say much about them...

Re:Ruby could be packaged better

[flipper65]

Actually, if you are looking for a rails IDE I strongly suggest that you check out http://radrails.org/ available both as stand alone and as an eclipse plugin.

Re:Ruby could be packaged better

[12ahead]

Not sure what system you are on, but for osx there is Locomotive. You will get a magnitude of libraries (I guess the DB2 stuff won't be in there just yet) plus a nice gui to start/stop webservers for your Rails projects. Not sure if you were after Rails or plain Ruby, but anyway.

On the IDE front you could check out RadRails. Again, this focuses on Rails instead of "just" Ruby.
 
However, I do believe that Ruby is one of those languages that you can learn by just using it from command line. You do not need an IDE or huge framework to do fun stuff. You can at least get a feel for how Ruby does stuff to put you off it or to keep investigating.

Re:Ruby could be packaged better

[MarkWatson]

Actually, I find the Eclipse RDT and RadRails plugins to be very good (I work in this environment 8 to 15 hours a week).

I had another more radical thought yesterday: just for fun, I installed the latest stable build of Squeak Smalltalk - years ago, I had done some natural language processing work with Squeak and I wanted to look at a newer version. Any, the idea: Smalltalk and Ruby are similar enough, that for non-GUI applications it would not be so hard to write a translater from Smalltalk to Ruby for deploying small utility applications.

The performance of Ruby is not so great (I just had to switch part of my current project from Ruby to Common Lisp for performance), but it would be neat to be able to use a Smalltalk enviroment, and "compile to Ruby". Anyway, this is an idea that probably lacks merrit because professional versions of Smalltalk like VisualWorks have very good deployment tools (small size, low memory requirements) and even with the free Squeak system, with some effort you can build smaller "headless" applications.

Back to Ruby: I find Ruby installation to be easy, and the rubygems system is great. The Ruby community is friendly and helpfull.

DB2... The only change?

[Aladrin]

I can understand wanting to get news of the DB2 adapter out to the public... But to attach a tutorial to it that is basically just another RoR tutorial seems pointless. The only differences in this article from every other RoR article were in the paragraph that describes how to install the DB2 adapter for RoR.

-yawn-

Re:DB2... The only change?

[Anonymous Coward]

But to attach a tutorial to it that is basically just another RoR tutorial seems pointless.

It's called "jumping onto the bandwagon"; you may have heard of it. It's what all of IBM's "cutting-edge" developerworks-articles (written by some sophomore pimply FOSS-monkey intern) are about.

Really good news.

[marcello_dl]

Getting the likes of IBM to recognize the usefulness of the Rails framework is a little more than just another DBMS supported: rails used to be bashed, especially by java people, for not being "enterprise ready". They criticised the limitations of the active record ORM (but it's open source, you can either extend it or make your custom sql calls), or the relative immaturity of ruby and libraries.

Now such claims will sound less credible so more dubious people might give it a try.

Re:Really good news.

[Decaff]

Getting the likes of IBM to recognize the usefulness of the Rails framework is a little more than just another DBMS supported: rails used to be bashed, especially by java people, for not being "enterprise ready". They criticised the limitations of the active record ORM (but it's open source, you can either extend it or make your custom sql calls), or the relative immaturity of ruby and libraries.

Now such claims will sound less credible so more dubious people might give it a try.

IBM has been hosting articles about RoR for some time - this is not a major change in attitude - it is indeed simply getting just annother DBMS supported. Rails is bashed for not being enterprise ready for more than just the range of databases supported. This additional support does nothing to change the limitations of the Active Record approach (and the ability to extend the system does not make it enterprise ready).

There are many aspects of Ruby and Rails that remain a significant barrier to much enterprise use - performance, for one thing (Ruby VMs that might address this problem seem stuck in permanent beta), the ability to handle international characters is another.

To assume that these issues are somehow fixed simply because IBM has provided DB2 support is nothing more than wishful thinking.

Re:RoR vs Django?

[amaupin]

Haven't tried Django, but while Ruby on Rails is making progress, it's still no match for the power and flexibility of Zope.

Re:RoR vs Django?

[masklinn]

I've tried a bit of both, and from what I've seen:

• Rails does more user-related stuff automagically, but doesn't build your administrative interfaces (you have to do that yourself). Django's admin interfaces are dead-easy to build and gorgeous to boot (as far as admin interfaces can be I mean).
• Rails does a lot of things by itself, but you have to follow the Rails Path/Rails Way/whatever. It's name means it all, if you veer too far from how DHH intended Rails to work it breaks (in the sense of "it makes your life a living hell), while Django is much more flexible. If you don't like the way Rails work you're screwed while with Django you can recover. The plus side is that Rails does a lot of things for you if you follow The Rails Way.
• I quite like the ActiveRecord ORM pattern. On the other hand i'll repeat the last point: if you want to switch to another ORM pattern or ORM period, you're going to have a hard time. Django makes it much easier to switch to a non-default ORM engine (the impressive SQL Alchemy for example)
• Rails' quite static (directories) structure make it... well.. structured. You don't want to bend the directory structure too much (see point 2), but it's usually well thought of and gives a very clean feeling. Django "feels" much less structured out of the box.
• Testing is strongly emphasized in Rails, and it goes a long way towards helping you write as many Unit (for models) and Functional (for controllers) tests as you can write. And every time you generate models or controllers Rails will create test stubs that you just have to fill.
• ERb. Basically, you write your templates (views) in Ruby. This means that Ruby's templates are much more powerful than Django's (out of the box) templates, and you don't have to learn another language and switch between Ruby and your-template-language. On the other hand, Django's templating language makes it much simpler to use by designers (ERb is much more fit to coders, and the Django team considered that coders didn't know jack about web pages and weren't supposed to go near the stuff). The downside of ERb is -- of course -- that since it's much more powerful (you have the full power or Ruby available) you can turn your templates into a PHP-like crapfest with whole bunches of application/model logic in them.

I haven't build any big application with either yet, I don't have any real preference yet (I know more about Rails than Django though), but how I see it ATM is that way: if I need an extremely extensive admin interface, I'll just go with Django, the admin scaffolds just save too much time. If I don't need that extensive admin interfaces I'll go for the most well-known language in the team (if I have Pythonistas I'll pick Django, if I have rubyists I'll go with RoR).

Re:DB2... The only change?

[Decaff]

Massive databases often support multiple presentation layers - ecommerce, internal administration, parter access, internal reporting, etc, etc. Even if you're doing one in Java/websphere there's no reason another couldn't be in RoR.

There is good reason why you may not want it to be. The Java/J2EE/Websphere approach often uses clustering and cacheing to give high performance and scalability. You would not want to let a small RoR application (or any other type of application) loose on such such a system.

I find it hard to believe that

[Mofaluna]

Now that IBM has released a DB2 adapter for Rails, it's possible to write efficient Web applications on top of your existing DB2 database investment.

While much can be said in favor of RoR, especially the fact that the approach is the best thing since sliced bread for a certain 'niche' market, non-enterprise applications, the above quote is wrong. There is a huge difference between efficiently writing web applications, that which Ror is good at, and writing efficient web applications, that which RoR traded of in favor of efficiently writing web applications.

Re:I imagine...

[kpharmer]

> I imagine that all three people who use DB2 are quite pleased with this development :)
> What kind of market share does it have?

Depends on how you count it. I think by revenue IBM databases account for about 1/3 of the market. This primarily consists of db2 but also includes numbers from informix and ims.

> Seriously, I haven't seen any person or development shop in my area using DB2. I've never heard of it being used at all.

It's used heaviest on the mainframes, but also works very well on windows & unix/linux. After having spent decades developing databases using db2, oracle, informix, sybase, sql server, postgresql, mysql, access, clipper, ims-db, vsam, etc - I've grown to like db2 quite a bit (and Informix the most). DB2 is far faster than mysql or postgresql, and about 1/2 the cost of oracle.

The primary reason it doesn't have a larger marketshare is that IBM isn't very good at marketing, and until about four years ago its unix/windows version was a little clunky.

DB2 works fine for small projects where it is very cost effective, but you typically see it the most on very large projects. It especially shines when your data volumes keep growing - then it gives a ton of different scalability options - all the way up to very robust beowulf-like clustering capabilities in which you can spread your database across hundreds of separate servers. For large projects like this its only real competition is Informix or Teradata.

Re:RoR Question from JAVA newbie...

[mr_rattles]

The API is designed for Java/.Net and you think it's a good excuse to learn Ruby? Wouldn't it be a better excuse to learn Java or .Net? Also, you said it yourself that it's a simple app so I don't think you need to bend over backwards "designing" a "full-fledged" Java app either. Just write the simple app using whichever API makes most sense for whatever you're interfacing with. On one side you say you have a Java/.Net API but what do you need to interface that with, another Java/.Net app? If that's the case your decision should be obvious.