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

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

[masklinn]

Mostly because Smalltalk came from PARC and was built to work in an environment (BTW there is no Smalltalk "IDE", they're environment and you work in an image within the environment, it's a much more impressive concept than the simple concept of IDE which is merely a beefed up text editor)

Ruby was built as a programming language and as a language only, it wasn't built with the idea of environments in mind and the editors/ides therefore have to be bolted on. Plus Ruby only recently started to get widespread adoption in occident (and fyi Python doesn't have many good IDEs and it's been popular for a much longer time in occident than Ruby).

About the packages issue, I can't help but tell you to learn how gems work, as it automagically handles dependencies and package versioning...

Re:Ruby could be packaged better

[masklinn]

As an example: I'm trying to get FeedTools going for a week now. There's a gem installation available, but it seems even the developers don't trust it and recommend a manual installation.

Uh? I find pretty much the opposite statement on the front page of the FeedTools project:

However, the preferred method of obtaining FeedTools is with RubyGems because of FeedTools' dependancies on other gems.

Works like a charm too:

$> gem install FeedTools -d -y
Attempting local installation of 'FeedTools'
Local gem file not found: FeedTools*.gem
Attempting remote installation of 'FeedTools'
Successfully installed feedtools-0.2.24
Successfully installed uuidtools-1.0.0
Installing RDoc documentation for feedtools-0.2.24...
Installing RDoc documentation for uuidtools-1.0.0...
$> irb --simple-prompt
>> require 'feed_tools'
=> false
>> slashdot_feed = FeedTools::Feed.open('http://www.slashdot.org/inde x.rss')
=> #
>> slashdot_feed.title
=> "Slashdot"
>> slashdot_feed.description
=> "News for nerds, stuff that matters"
>> slashdot_feed.link
=> "http://slashdot.org/"
>> slashdot_feed.items.length
=> 10

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: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.

Re:RoR programmer ? What are your websites..

[Anonymous Coward]

Advantages:

- Ruby
- Speed / Efficiency (about 1:3 - 1:5 ratio over other environs)
- Routing (Pretty URLs)
- Test-Driven Development

Disadvantages:

- Internationalization
- Integration with Compound Primary Keys (legacy databases)

RoR is best used as a front-end for a new (or significantly refactored) application. The approach of "convention over configuration" that RoR uses is magnificent, but if your existing application you want to port doesn't do things the "RoR way" (example, ActiveRecord expects a single-column integer primary key 'id'), then it's more difficult to port. (A counter-argument could be stated that multi-column or intelligent keys have no place in a DB -- my stance.)

If you can, for the most part, follow the RoR conventions in your application the speed of development is consideribly faster. Performance is pretty good when you understand how it works (there are separate environments -- development vs production) which significantly effect performance. It supports sophisticated caching as well.

Finally, the things I listed in the disadvantages column are partially-solved by "plugins" which are easily downloadable and available to any app that needs it. The community is very active and new OSS plugins / generators are making their way onto the scene every day.

Re:RoR vs Django?

[jcroft]

Django did start out in publishing (I should know, I'm the senior designer for the publishing company that created it). But, since then, it's been developed greatly to work well in other application-type environments. While Django still excels at content-heavy sites, and you can see the roots are in publishing, I would contend it's every bit as capable for more transaction-based web apps as Rails is.

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:Really good news.

[jizmonkey]

Wait. I don't develop Ruby. But you're not honestly telling me that it doesn't at least have support for UTF-8, are you? I would have thought that UTF-8, at least, would have been a given for such a project. Is the support only partial, or is it limited, or... something?

The (Japanese) creator of Ruby thinks that Unicode sucks, and therefore Ruby has only half-baked support for Unicode. There are patches to make Rails work with Unicode but they're a little flaky.

Re:I imagine...

[Anonymous Coward]

Unfortanly many parts of DB2 is buggy, slow and bloated. That means that you need several years of DB2 experience to work around all the issues. Our national bank had tons of issues with DB2 crashing under load (Websphere AS too), which could only be resolved by using JBoss and Oracle instead. I'm not fond of either Oracle or DB2, so I couldn't really care which they use. Horrible when even the experts IBM send in to assist can't fix the issue and claim it's an OS issue, even when the same problem arise on both Linux and Windows.