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
I was wondering if anyone has used both RoR and Django. Having only used the latter myself, I am a bit curious on how they compare. Can anyone fill me in on that?
Send email from the afterlife! Write your e-will at Dead Man's Switch.
IBM has been jumping on multiple bandwagons for a while now, I think I've already seen at least a pair of Rails tutorials and at least one or two Django tutorials on DeveloperWorks.
They're usually fairly bad too..
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
IBM doesn't want to point their customers and potential customers to web sites that describe how to use MySQL, then have to tack on a "... and then here's how you can use OUR product with it."
They want to keep the user firmly in their court for the entire exercise, so this approach makes sense from their perspective.
Plus, it's easier to follow one tutorial than to have to skip around multiple ones.
Why are you letting these clowns ruin our country?
Ror programmers, could you step out your websites ? What are the main advantages and disadvantages of Ror ? Thank you
The big difference is that Rails is an actual tool, with a of buzz around it, while AJAX is wankery for marketroïds and is only buzz.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
> I work in banking and my experience has seen DB2 used to support very heavy applications (e.g. internet banking with 1+ million customers).
> Is rails being used in enterprise for heavy web apps (not my field)?
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.
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.
Nah, AJAX is a general description of the technique of using "asynchronous javascript and xml" (although it may be synchronous, doesn't have to use javascript, which should properly be called ecmascript, you shouldn't capitalize the 'a' in an acronym, and xml is optional as well, so maybe "discreet content updating" would be a better term but isn't very catchy) and is being widely used so it is in fact an identifible thing and by the amount of attention/adoption "hot."
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.
> 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.
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
This is irrelevant. Of course the heavy lifting is backend - but that is where websphere/weblogic/j2ee come in - they are systems designed for this kind of heavy lifting. Where such high-performance and cacheing goes on (and this may not be simple), you can't just attempt to connect a PHP or RoR application to the same tables and expect everything to work right.
Fortunately for me, most of my massive databases get php front-ends these days. And hopefully RoR soon.
Then they probably aren't the kind of substantial applications being discussed. Large high-transaction-rate systems tend to use considerable amounts of in-memory storage and avoid falling through to the database where possible, as the database can be the slowest part of the system. The 'let the database store everything' approach of PHP and RoR doesn't scale to the highest levels of performance.
Personally, I think IBM should be commended. Their developerworks articles are usually of good quality, easy to find, well thought out, timely, and free. When I'm searching for some tech topic (specifically implementation instructions/tutorials) with Google if anything from IBM shows up, that's the first place I'll go. Just the other day I used their ssh keychain piece when I was working on setting that up.
I just wish more companies would follow there lead and provide something of value.
You don't make the poor richer by making the rich poorer. - Winston Churchill
> 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.
I need to code a simple app to interface with a forex trading system. Their API has been designed for JAVA/.NET and I am unfamiliar with both. I figure this would be a good excuse to learn RoR, but I am not sure how flexibile it is.
As far as function goes, this is all math based. No fancy-pants GUI elements required.
Am I better off designing a full-fledged JAVA app, or can RoR do this sort of thing and save me time?
barack to the future?
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?
>>Fortunately for me, most of my massive databases get php front-ends these days. And hopefully RoR soon.
> Then they probably aren't the kind of substantial applications being discussed. Large high-transaction-rate systems
> tend to use considerable amounts of in-memory storage and avoid falling through to the database where possible, as the database
> can be the slowest part of the system. The 'let the database store everything' approach of PHP and RoR doesn't scale to the highest levels of performance.
Keep in mind that "substantial applications" take a variety of forms. Some have high transaction rates with relatively simple queries and many concurrent users. Perhaps J2EE is well-suited here, though I suspect that the complexity it incurs isn't worth the benefit, and there are a variety of ways to cache database data, including within the database of course. And of course, most people don't need "the highest theoretical levels of performance" - they need reasonable performance.
Other substantial applications have low to no transaction rates with extremely complex queries and fewer users. In this latter situation j2ee is no better suited than RoR, actually worse in a variety of ways such as complexity & cost. Enterprise reporting and information dashboards & consoles are perfect examples in which applications may have just a few hundred simultaneous users running thousands of extremely complex queries.
Back to RoR & DB2 - i'm currently working on a multi-terabyte DB2 database application that supports hundreds of large customers running extremely complex queries around the clock. It worked fine in php, there's no reason to believe that it won't work even better in RoR. Saying that this isn't an enterprise app, isn't a substantial app, or doesn't apply to anyone else is highly misleading.
At least one. It's recomended for begginers on RoR's website. It comes out of the box... just unzip it and there you go.
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.
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.
The readers of the article are likely to be developers in DB2 shops who haven't touched RoR yet. They may not have bothered downloading the software stack, installing and configuring when they saw 'MySQL', but now there is DB2 support, they would likely appreciate the complete getting started guide. Besides, they'd rather have the version written by someone who works for one of their major suppliers rather than a pimply sophomore in his blog (to borrow a phrase from a sibling poster).
> Unfortanly many parts of DB2 is buggy, slow and bloated.
Not the core database. Like anything else, the fringe functionality that fewer people use or that is newer has tends to have more problems. Stuff like table inheritance, xml, replication, cube views, etc, client tools, etc. But the engine works very well. That ultimately is what I focus 99% of my time on.
And back to how it was clunky a few years ago: anyone on the 7.* versions really needs to upgrade. v8 is a very good product, and now v9 is going to be out in a couple of months.
Note also that in my experience most problems in which people "had to switch to oracle" started out because they had an oracle staff that did everything the "oracle way" - using oracle-style partitioning, etc. Then discovered that db2 didn't work as well as oracle in doing things the oracle way. Then they switched. However, it was a foregone conclusion that they would switch. With v9 coming out and oracle-style partitioning built-in perhaps those that insist in developing for oracle will find it much easier to get their code to work with db2.
Why in the world is this moderated as trolling? Taking the parent post's advice, here's a bit more on the author.
*LOL* I've seen some poor ImageMagick tutorials also. I think DeveloperWorks is trying to be a newer, poorer version of O'Reilly.
Back to RoR & DB2 - i'm currently working on a multi-terabyte DB2 database application that supports hundreds of large customers running extremely complex queries around the clock. It worked fine in php, there's no reason to believe that it won't work even better in RoR. Saying that this isn't an enterprise app, isn't a substantial app, or doesn't apply to anyone else is highly misleading.
No, it is misleading to generalise. You have something that supports hundreds of users and runs complex queries. Some of us write applications that support tens of thousands of users (with hundreds of concurrent sessions) but with relatively simple queries. With your use the database can pick up the load, and PHP and RoR are entirely suitable. With my use, I am intending to migrate to a clustered system with considerable in-memory cacheing and J2EE is far better.
I would agree that the term 'enterprise' is confusing, but to take one specific case and assume that this indicates that PHP and RoR are general purpose enterprise tools is definitely mistaken. After all, J2EE can work very efficiently over a far wider range of types of enterprise app.
I think before calling authors names like "sophomore pimply FOSS-monkey intern" you ought to at least do a search on the author's name. http://www.xml.com/pub/au/Dumbill_Edd Edd Dumbill is a very respected guy in his field and has some very serious Ruby on Rails projects behind his belt. He is neither "sophomore" nor "pimply" and has quite a bit of integrity.
Do you bank, buy insurance, shop at Home Depot, go to hospital, have your packages delivered by UPS, fly major airline, make telephone calls, get IRS audit notices, go to hospital, buy groceries, pay for electricity fill up at the gas station ...? Let me give you a hint ... you are not most likely using DB2. So, other then to be the backbone of commerce it is not used much :-)
It is a bummer. Where do you turn? MySQL - popular but buggy. Firefox [ed: I assume you mean Firebird] - less buggy but not so popular. Oracle - an extremely popular dinosaur that doesn't even bundle a GUI.
I assume you already know the answer you're looking for here is SQL Server, right?
I don't write databases for banks or anything, but coming from MySQL I've been very impressed with Yukon. Since SQL Server Express finalized, I've moved over to it -- it's a much better environment to work in if you use C# and/or Visual Studio at all. I imagine Microsoft's new strategy of C# Express, SQL Server Express, plus the $300 Windows 2003 Web Edition are going to create a lot of ASP.NET converts out there.