Slashdot Mirror
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.'"
In the UK we've only just got trains to go on rails.
- There's no place like 127.0.0.1
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.
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-
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
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.
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.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
Haven't tried Django, but while Ruby on Rails is making progress, it's still no match for the power and flexibility of Zope.
Haven't tried Django, but while Ruby on Rails is making progress, it's still no match for the power and flexibility of Zope.
I've been programming python for many years now - I've not used Django, but after reading the docs etc. it looks like yet another "Ruby on rails is popular, let's make something!" which is nowhere near finished. One nice thing about Ruby on Rails is focus - the entire ruby community seems to be on the bandwagon, driving it forward and integrating nicely with it. This means that docs, libraries etc are there for you.
Zope is way too complex... when you know easily how to get most of what you want to do in python scripts from straight database tables, you'll hit your head against the wall for ages converting this from python code to Zope and its evil ZoDB[1]
[1] The one good reason for using ZopeDB is that Python's database libraries need a large overhaul. Consistency is badly needed (making things like quoting etc. driver dependent... which sick mind thought that was a good idea?), and why are there so many drivers? There shouldn't be a need for much more than one for each database - and e.g. in the case of PostgreSQL, that should be the bundled one. pyPgSQL, PyGreSQL, Psycopg, PoPy, Proboscis.... and I'm sure I forgot some. The perl DBI interface was more pleasant to use almost 10 years ago than the python DB interface is today. JDBC also got it right. A de-facto standard python ORM would be nice too.
I've tried a bit of both, and from what I've seen:
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).
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
It's not, both are extremely different from one another (and even more since the Django guys went the magic_removal route). And while Django is not finished (nor is rails) it's very much production ready.
I hear you, that's probably the biggest issue with the Python community, this "No tool does exactly what I want, so I'll just build a new one, no point in extending an existing one" attitude.
Brings some interresting stuff to the table though (have you tried SQL Alchemy in your Quest For An ORM?)
Another Python issue is that the community can hardly bring itself to standardize things, and even then people usually try to build even more tools (sometimes better though, see py.test versus STL's unittest, or effbot's ElementTree which will finally be part of the STL with Python 2.5 versus the whole xml package crapfest)
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
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.
As an example of the hype machine in action, I recently interviewed for a web developer position. When the subject of my AJAX experience came up, I said that I had extensive experience. He then asked about my Ruby experience, which I said was limited. He then laughed -- LAUGHED -- and said "What are you talking about? AJAX is a *part* of Ruby!" Clearly I had no experience in either technology and was lying "because otherwise I would know this", and the interview went downhill from there.
Life would be easier if I had the source code.
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.
----------
Jeff Croft
http://jeffcroft.com
> 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.
It depends:
- I'd bet that 9 out of 10 websphere/weblogic implementations don't use clustering
- many massive databases have relatively modest websites, ie the heavy-lifting is all backend not presentation
- many massive databases have small related "helper" applications that also need presentation layers
- even clustering & caching applications should be able to handle changes to reference data through simple cache-refresh methods.
Fortunately for me, most of my massive databases get php front-ends these days. And hopefully RoR soon.
I would say this is a bit of the Python philosophy showing up in Django: Explicit is always better than implicit. Obviously Rails doesn't share this philosophy, and that's fine. But Django definitely intends to be very Pythonic, and model definitions are no exception.
----------
Jeff Croft
http://jeffcroft.com
> 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.
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.
Erik http://yakko.cs.wmich.edu/~rattles
Does it already properly support Unicode? Not everyone uses just English texts and the best and most common way to use characters of other languages is UTF-8.
1) I work for an aerospace company, and I recently needed some way to get NORAD TLEs from Celestrak. Never mind what TLEs are, I went to CPAN and found what I needed in a few minutes. How does Ruby compare to Perl in available libraries and utilities? If I have to get the TLE specifications and code my own functions in Ruby, sorry, but I'd rather cope with Perl's shortcomings.
2) Occasionally I have to do some web applications to access corporate databases in Oracle, Ingres, and Postgres. The data contains international characters, which may be in UTF or ISO-8859, I need support for both and an easy way to shift between them, often in the same application. For this kind of work I use PHP together with the eGroupWare suite. I have no need for very complicated code here, these are mostly simple web forms and tables, which PHP+eGroupWare handle quite well. Using the built-in etemplates utility I can code applications very quickly.
3) For really complex work I use C, or C++ with Qt if there is need for a GUI. I often create prototypes for my C code, using either Perl, Python, or Matlab to develop some of the algorithms. After I have the algorithm, I reimplement it in C using the many libraries available, such as GSL, Lapack, or FFTW, for instance.
With all that, I have yet to find a reasonable niche where Ruby would fit, with or without Rails. I can see how someone who wants to learn only one language would think Ruby is the best, but I cannot imagine being more productive in Ruby than in the languages I use for each of the jobs I described.
And the attitude one finds in Slashdot "hey stupid, Ruby is 'teh' language, you must be a troll" doesn't help either. For any other language I can find websites that give detailed descriptions of its good and bad points, but I have seen very little on comparing Ruby with other languages. From the little I have seen, it gives the impression of being somewhat remotely related to Lisp, like Python. How about creating a site that shows some examples comparing code written in Ruby with the same program in Python, Perl, C, PHP, Java, etc?
I would actually consider this a good thing. This guy let on that he didn't know what the hell he was talking about right up front at the interview, on top of demonstrating a lack of professionalism - a great time to walk, assuming you weren't hurting for the money. I wish every company were so forthcoming about their flaws.
It sounds like you were saved from having to work with morons there SilentBob.
I view a job interview as a chance not just for them to find out about me, but a chance to find out whether they are a group of people worth working for.
Please don't send a Word document when a text file will do the job.