Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×

Ruby on Rails for DB2 Developers 128

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.'"
This discussion has been archived. No new comments can be posted.

Ruby on Rails for DB2 Developers

Comments Filter:
  • by StaticFish ( 839708 ) on Sunday June 25, 2006 @07:45AM (#15600045) Homepage
    In the UK we've only just got trains to go on rails.
  • by bogaboga ( 793279 ) on Sunday June 25, 2006 @07:59AM (#15600073)
    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/ [railslivecd.org] have started some work in this direction.

    • It's simple. It hasn't been out as long.

      There ARE Ruby IDEs out there, btw, you just have to search a lot harder to find them and they aren't nearly as complete as what you are used to, because of their young age.
    • You should try Ruby Gems [rubygems.org] to solve your packaging woes. As for an IDE, there are plenty available: http://freeride.rubyforge.org/wiki/wiki.pl [rubyforge.org] and http://www.mondrian-ide.com/ [mondrian-ide.com] though I can't say much about them...
      • But I wonder about the quality of this packaging. 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. It seems there are several installation methods available (like copying the source files to your vendor directory), but so far no luck for me...'Feed constant not initialized' is my best result so far... :-(
        • 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

          • I followed the tutorial links to the textdrive forum, where nrbrookes recommended this strategy:

            This is what I did to get feed tools working...

            a) unpacked feedtools and the uuid gems
            b) edited the feed_tools.rb changing require_gem( 'uuidtools' ) to plain ol' require( 'uuidtools')
            c) copied the feed_tools.rb, feed_tools folder and uuidtools.rb into my vendor directory (don't put the whole of the unpacked gem, the stuff you are interested in is in lib)

            and then it works.

            but no luck so far...I'll go

      • He's talking about a Smalltalk-like development environment. Freeride and Mondrian don't even come close. Of course that begs the question of whether it would have been a good idea to have Ruby be image-based. Smalltalk is defined by its powerful development environments and it certainly wouldn't hurt Ruby to have one too.
    • by flipper65 ( 794710 ) on Sunday June 25, 2006 @08:37AM (#15600156) Homepage
      Actually, if you are looking for a rails IDE I strongly suggest that you check out http://radrails.org/ [radrails.org] available both as stand alone and as an eclipse plugin.
    • by 12ahead ( 586157 ) on Sunday June 25, 2006 @08:40AM (#15600168)
      Not sure what system you are on, but for osx there is Locomotive [raaum.org]. 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 [radrails.org]. 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.
      • 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.

        There is very strong evidence based on decades of research (such as with Smalltalk in the 70s) that says that the best way to learn and use OOP languages is with a good GUI. There is nothing to match browsing classes and dynamically inspecting o
        • I am very skeptical whenever I hear 'you don't need a GUI'. This seems to me to be an argument along the lines of 'if we don't implement it, you don't need it'.

          Actually, it's "You don't need it until we actually implement it". That's pretty typical of the linux-type crowd though that have always screamed that Vi and Emacs are the epitomy of advanced development environments.

        • There is very strong evidence based on decades of research (such as with Smalltalk in the 70s) that says that the best way to learn and use OOP languages is with a good GUI. There is nothing to match browsing classes and dynamically inspecting objects during the execution of a program.

          Just a short anecdote from my college days. I took a grad-level course in object oriented programming languages that covered both C++ and Smalltalk where all of the machine projects included a GUI and were implemented in b

          • I never really had a problem understanding what OOP was all about. I think too many texts focus on breaking problems down into too many objects/classes instead of teaching people the reasons for using them, mainly code re-use. I find that if you're good at decomposing problems and structuring programs intelligently, then you should be good at the implementation no matter what paradigm is used.

            I think there is nothing to compare with the experience of being able to dynamically debug and inspect a running OOP
    • 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

    • by MarkWatson ( 189759 ) on Sunday June 25, 2006 @10:29AM (#15600443) Homepage
      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.
    • Try using eclipse with the plugin ... http://sourceforge.net/projects/rubyeclipse [sourceforge.net] @least eclispe does more than thing rather than dozen crappy ides someone has cobbled together
    • You should take a look at Starter Toolkit for DB2 on Rails [ibm.com]. It is a complete package of everything that you will need including a copy of DB2 Express - C that is absolutely free to distribute as part of your finished application and it does not limit the size of your data like the other database servers do. It is a complete one-click installer for everything. The integrated installer is for Windows at this point but the one for Linux is in the works. Bookmark http://db2onrails.com/ [db2onrails.com] if you are interested in
    • 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.

      Oh come on. Settting up a Rails environment isn't that hard. And that is all you need to start developing "serious" (web) apps in Ruby. Get a Mac and run Textmate and you are set. I tr

      • Oh come on. Settting up a Rails environment isn't that hard. And that is all you need to start developing "serious" (web) apps in Ruby. Get a Mac and run Textmate and you are set.

        Oh come on, Edlin is all you need to start developing serious web apps in Ruby. Get a DOS machine and you are set. For the sarcasm-impaired the parent is typical of the "We haven't implemented it, so you don't need it" crowd.
        • Oh come on, Edlin is all you need to start developing serious web apps in Ruby. Get a DOS machine and you are set. For the sarcasm-impaired the parent is typical of the "We haven't implemented it, so you don't need it" crowd.

          More like the "Quit your whining and start coding if you are really that interested in it" crowd. He's complaining about not having a "single installer." And he goes on to wish Ruby was more like MS Access, of all things. MS Access!? What kind of point of comparison is that?

          -matthew

    • If you have Mac OS, you should try TextMate (http://macromates.com/ [macromates.com]).

      Ruby is preinstalled with Mac OS, you write your script in TextMate, press Apple+R and the results pop up in a seperate window. Very nice and fast.
      There are also 'Bundles' for Ruby and Rails, which let you develope stuff very quickly. Code completion, easy switching between model, controller and template etc.
    • IDE? You mean like vim and an xterm?

      Honestly, I've never liked IDEs, or any tool so specific to a given language / environment, that the experience won't generalize to my next project. I'd rather climb a steeper learning curve and learn a piece of software that I can be reasonably sure I will still be using for whatever language and system I'm working in in 2030.
      • IDE? You mean like vim and an xterm?

        Honestly, I've never liked IDEs, or any tool so specific to a given language / environment, that the experience won't generalize to my next project. I'd rather climb a steeper learning curve and learn a piece of software that I can be reasonably sure I will still be using for whatever language and system I'm working in in 2030.


        No, we mean modern development environments that aren't stuck in some 1980s barley-above-console world. And "honestly", your personal preferences
        • A keyboard gives you ten simultaneous points of input.

          If you have even a small amount of experience, it's faster than using a mouse. Sit an experienced vim / emacs hacker next to someone using Visual Studio, Code Warrior, Smalltalk whatever, Ecclipse, etc. and I'll give you ten to one odds I can predict who is going to be working more efficiently and spending lest time copying pasting and navingating four tier deep menus.
          • If you have even a small amount of experience, it's faster than using a mouse. Sit an experienced vim / emacs hacker next to someone using Visual Studio, Code Warrior, Smalltalk whatever, Ecclipse, etc. and I'll give you ten to one odds I can predict who is going to be working more efficiently and spending lest time copying pasting and navingating four tier deep menus.

            Yeah, the guy with the Vi plugin for Eclipse or VS;) But seriously, if you're using Vim or Emacs for a language like Java then, no, you're n
    • 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.
  • by Aladrin ( 926209 ) on Sunday June 25, 2006 @08:00AM (#15600075)
    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-
    • by Anonymous Coward on Sunday June 25, 2006 @08:15AM (#15600112)
      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.
      • 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..

      • 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 [ibm.com] when I was working on setting that up.

        I just wish more companies would follow there lead and provide something of value.
      • 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 [xml.com] 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.
    • 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.
    • 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).
  • Really good news. (Score:5, Interesting)

    by marcello_dl ( 667940 ) on Sunday June 25, 2006 @08:17AM (#15600115) Homepage Journal
    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.
    • by Decaff ( 42676 ) on Sunday June 25, 2006 @10:14AM (#15600407)
      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.
      • I should have been more explicit. You made some points about ruby that can be crucial indeed. But those emerge after you tried the technology and see it unfit for your needs. Many other people just swallow up the opinion by java lovers (trolls?) that I was referring to and don't bother to give it a try. You probably meant enterprise ready as "advanced feature-rich", I meant "useful in business". I also never implied that limitations of rails would go away on their own, ideally a frameworks limitation shoul
        • You probably meant enterprise ready as "advanced feature-rich", I meant "useful in business".

          Not really - for me, features like support for internationalisation are not just useful, but crucial for any large-scale (enterprise) applications. This is, of course, different from smaller-scale applications, for which RoR may well be suitable.
      • the ability to handle international characters is another.

        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?

        • Re:Really good news. (Score:3, Informative)

          by jizmonkey ( 594430 )
          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.

        • 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?

          Yes, I am.

          I would have thought that UTF-8, at least, would have been a given for such a project.

          Indeed.

          Is the support only partial, or is it limited, or... something?

          No, it is absent. There is work going on to help fix this.
      • the ability to handle international characters is another.

        I do not know the full extent of internation character lack of support, but that seems quite ironic since Ruby is from Japan

        • yes, it is!
        • > that seems quite ironic since Ruby is from Japan

          The story goes that the Japanese were upset about the whole Unicode thing. They had their own charsets that had all the Japanese characters necessary... so why bother with all these other languages?

          There was also the "Han Unification" (as part of the Unicode "transition") where all CJK characters that were the same were mapped to the same code points. Again, this upset the Japanese for some reason; I'm not sure about the details. Apparently some langua
          • Thanks!

            Can you point to a good site explaining how to setup en_US.UTF-8? Preferably for FreeBSD if possible. I have a lot of music folders and files that are named "????" now!!!

            • just export LC_ALL="en_US.UTF-8" and LANG="en_US.UTF-8" and everything should work. This might be a Linux-ism though; you have to make sure that your system as the en_US.UTF-8 locale around somewhere. (Debian uses locale.gen; but I don't know about *BSD.)
    • >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".

      Others of those Java people gave Rails a try, and quite a few of them have just showed off their successes in Chicago.

      For all the talk, pro or con, there's the pesky matter of *results*.

      Too many applications are built using very cumbersome frameworks, especially web presentation stuff, da
  • Ruby on Rails for DB2 Developers
    Does that mean Ruby is derailed for Oracle, mysql and postgres developers ?
    • > Does that mean Ruby is derailed for Oracle, mysql and postgres developers ?

      What would give you that idea? The DB2 adapter is part of Rails, and can be used outside the web-stack if you like. Your question is akin to asking if Java using Oracle is no longer relevant since someone has come out with a type 4 JDBC driver for Sybase.

      If you were trying to be funny here, then I apologize for not getting it.
  • 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?
    • AFAIK it's not just Django, there's stuff like TurboGears out there as well that does the same sort of thing. I believe Django was developed for a publishing environment and still has newspaper-y assumptions built in, whereas Rails was designed to be more general-purpose, but I haven't encountered Django recently so this could all be old news...
      • I know there are more, but Django's what I'm familiar with :). I don't know about the assumptions, I haven't noticed any, but then again, I have nothing to compare it to...
      • Re:RoR vs Django? (Score:2, Informative)

        by jcroft ( 23893 )
        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:RoR vs Django? (Score:3, Interesting)

      by amaupin ( 721551 )
      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? (Score:3, Interesting)

        by teg ( 97890 )

        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 doc

        • Re:RoR vs Django? (Score:3, Interesting)

          by masklinn ( 823351 )

          after reading the docs etc. it looks like yet another "Ruby on rails is popular, let's make something!" which is nowhere near finished

          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.

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

        • Nevermind the fact that there have been production sites built on Django FAR longer than there have been production sites built on Rails, I guess. *rolls eyes*

          Rails was open-sourced first, but Django has been in existence and working well longer.
    • Re:RoR vs Django? (Score:5, Informative)

      by masklinn ( 823351 ) <.slashdot.org. .at. .masklinn.net.> on Sunday June 25, 2006 @10:15AM (#15600411)

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

      • Ah, that was very informative. Based on what you said, there's not THAT much more that RoR does that one has to learn a new language + framework to use over Django.

        And I agree, the admin interface is a lifesaver :)
        • Based on what you said, there's not THAT much more that RoR does that one has to learn a new language + framework to use over Django.

          While it's true, I consider that broadening your horizons and knowing more if only for the sake of widening your field of vision is always a good thing.

          Plus neither are Rails nor Django static, they're both under heavy development (likewise for Turbogears, but I don't know that one at all).

  • migrations (Score:1, Redundant)

    by Zugot ( 17501 ) *
    too bad it doesn't support migrations. better luck next time ibm.
  • Ror programmers, could you step out your websites ? What are the main advantages and disadvantages of Ror ? Thank you
    • by 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-co
  • by Mofaluna ( 949237 ) on Sunday June 25, 2006 @12:08PM (#15600796)
    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.
  • 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?

    • 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 th
  • Unicode? (Score:3, Interesting)

    by jopet ( 538074 ) on Sunday June 25, 2006 @03:14PM (#15601530) Journal
    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.
    • Re:Unicode? (Score:2, Interesting)

      by RegularFry ( 137639 )
      Which? DB2 or Rails? I'm assuming that DB2's got multilingual wrapped up pretty well. As far as Rails goes, there are a couple of handshakes to perform (set headers, set $KCODE, prod the DB in the right way if necessary), but once they're done, everything's just a bunch of bytes. Ruby's Unicode support isn't great (there's an active discussion about the best way to fix it up on ruby-lang right now), but 95 times out of 100 it doesn't cause a problem.

      By the way, one of the sticking points about the Unico
      • Re:Unicode? (Score:3, Interesting)

        by jopet ( 538074 )
        Since this was essentially about Rails getting DB2 support I implicitly addressed Rails/Ruby - sorry for

        In the meantime I did some research myself and found the sobering fact that Ruby/Rails essentially does NOT support Unicode in any usable way.

        A string of Unicode characters is NOT just a bunch of bytes: take the simple operation of finding the length of a word or reversing it: both string functions return nonsense in Ruby, if there is any character encoded in more than one byte in the string.
        That Ruby doe
        • In the meantime I did some research myself and found the sobering fact that Ruby/Rails essentially does NOT support Unicode in any usable way.

          That depends on what you mean by 'usable'...

          A string of Unicode characters is NOT just a bunch of bytes: take the simple operation of finding the length of a word or reversing it: both string functions return nonsense in Ruby, if there is any character encoded in more than one byte in the string.

          My point was that for the vast majority of cases, you don't need to care
      • everything's just a bunch of bytes.

        Or, to put it another way, no, it still doesn't.


        the opinion that "the best and most common way to use characters of other languages is UTF-8" is not universally held. It might be the most common, but many learned and respected individuals think it's not the best.


        Indeed. For example, I prefer UTF-16 for most purposes, and I see that the MS and Java worlds agree with me; UTF-8 is primarily for Ugly Old Unix compatibility.

        Unfortunately, Ruby's issue is not so much wi
        • Unfortunately, Ruby's issue is not so much with UTF-8 as an encoding as with a perception that Unicode as a character set is insufficiently Japanese.

          To a certain extent, I'm sure that's true. However, there's also the opinion I've heard voiced that restricting Ruby's String class to a single representation internally completely ignores the fact that there are other encodings out there. Java is *not* thought to have got string encoding right by several Ruyists, but I don't know how much of that impression
  • by mangu ( 126918 ) on Sunday June 25, 2006 @06:44PM (#15602289)
    In all these articles about Ruby and RoR people always mention how great Ruby is and how great RoR is. After trying both, I must assume that I must be pretty stupid, because I fail to notice all that greatness. Let's see some case studies:


    1) I work for an aerospace company, and I recently needed some way to get NORAD TLEs [norad.mil] from Celestrak [celestrak.com]. Never mind what TLEs are, I went to CPAN [slashdot.org] 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 [celestrak.com] 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 [egroupware.org] 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?

    • 1) CPAN has the advantage of being stupidly huge, and is one of the best things about Perl, or indeed any language. I don't know of a library set like it. Ruby's libs aren't as comprehensive, but there is a lot of useful stuff out there.

      2) There are two separate issues here. Character set conversion is happily handled by the Iconv library, which is part of Ruby's stdlib. Without being intimately familiar with eGroupWare, I'm not entirely sure what functionality it provides. On the other hand, I can s

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Working...