Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Programming IT Technology

Rails 2.1 Is Now Available 71

slick50 writes "Rails 2.1 is now available for general consumption with all the features and fixes we've been putting in over the last six months since 2.0. We've had 1,400 contributors creating patches and vetting them. This has resulted in 1,600+ patches. And lots of that has made it into this release. The new major features are: time zones (by Geoff Buesing), dirty tracking, Gem dependencies, named scope (by Nick Kallen), UTC-based migrations, and better caching. As always, you can install with: gem install rails Or you can use the Git tag for 2.1.0."
This discussion has been archived. No new comments can be posted.

Rails 2.1 Is Now Available

Comments Filter:
  • damnit (Score:1, Funny)

    i just started not caring about rails 2.0!
  • When I first looked at Rails years ago, it (and Ruby) had far less than adequate support for i18n. Has this changed at all? I'm sure there are some Rails devs here with experience in that.

    • by Vectronic ( 1221470 ) on Sunday June 01, 2008 @08:01PM (#23621451)
      No experience, and this may not be what you are talking about, but...

      Time Zones in Rails 2.1
      http://railscasts.com/episodes/106 [railscasts.com]

      By 'i18n' you might be refering to Localization (languages, etc) though.

      If you are bored, start at the beginning...

      http://railscasts.com/episodes/1 [railscasts.com]
      and keep stepping through to Episode 111. (some are older, some are new to 2.1)

      Movies are all in MOV format, optionally in M4V.
    • Re: (Score:2, Informative)

      by slick50 ( 136573 )
      One project you can check out for this is GlobaLite [google.com]

      GlobaLite is meant to be a breed of the best i18n /l10n plugins available for Rails.

    • by patio11 ( 857072 ) on Sunday June 01, 2008 @08:58PM (#23621801)
      ... but I burned about 16 hours of company time last week trying to do the following:

      1) Have a .rb script written in UTF-8, with Japanese in it.
      2) Read in a files written in a mix of UTF-8 and SJIS (a legacy Japanese encoding which is quite common here)
      3) Do some really freaking simple text munging.
      4) Write out to a new file in SJIS, for exporting to another system

      Sixteen. Freaking. Hours.

      Among the numerous issues I learned the hard way (previously all of my Rails experience had been in the mystical wonderland of ASCII and all of my i18n experience had been in Java, so I had never seen problems like this before):

      1) Running regexps on strings. I naiively assumed that you could actually, you know, do it. As it turns out, you have to first convert the encoding of the regexp and the encoding of the string such that they match, otherwise you get program killing errors. This was sort of a newbie mistake -- I figured that Ruby, with its "keep it easy" credo, would do things fairly transparently like Java does. Instead, I have to manually identify all entrance points of text into the system, and do the encoding to UTF-8 internally there, then do the encoding to the target encoding at all the output points. As you can imagine, this isn't the world's most maintainable solution, since all it takes is one other member of my team to refactor a file and forget to include the magic encoding comment at the top (thus letting encoding fall to the system default) and then we've got little SJIS gremlins running around internally wreaking havoc with our data.

      2) Try opening a file for writing as SJIS in a script written in UTF-8

      output_file = File.open("sample.txt", "w:SJIS") #this is Ruby 1.9
      output_file.puts Date.today.year # 2009

      You'll get an error saying that you can't transcode between ASCII-8BIT (what the 2009 starts as, after it gets munged into a string) and SJIS, which you've declared as the file encoding. Never mind that a) the transcoding is bitwise identical in this case and b) yes, you freaking machine, I damn well CAN transcode between those two because if I can't then Japan is "#$"#ed.

      3) Documentation. One of my favorite hobbyhorses with Rails, and I love that framework, is that documentation is sparse, outdated, and disorganized. Ruby 1.9 deals with the issue of sparse, outdated, and disorganized documentation by dispensing with it entirely, for minor features like Unicode support, which was theoretically the major advance. (Its possible I merely missed the documentation because my Japanese Google-fu is insufficient, but I really feel for those saps out there who need to support languages which aren't Japanese.)

      About the only helpful things I found were blog posts and mailing list archives which detailed the somewhat idiosyncratic relationship between

      a) the magic comment
      b) the -K and -E command line parameters
      c) the system default encoding

      in determining what encoding strings actually end up as. I have still not been able to re-find where I learned about the File.open(filename, "w:SJIS") syntax. There does not appear to be any comprehensive official list of changes. Rather, the best I was able to do was a blog post featuring (I kid you not) the results of one guy grep'ping changelogs looking for things that looked related to 1.9 and collecting them in one place.

      Oh boy, was Friday frustrating. And I get to do it again today. Fun stuff.
      • Re: (Score:3, Interesting)

        by setagllib ( 753300 )
        I really don't know how Ruby gets away with having such bad encoding support. Java and Python both solved that problem long ago, and Python 3 gets even more Java-like by having the standard string type be unicode. Heck, even C++ frameworks solved it. Meanwhile Ruby makes encodings just as hard as in C, if not harder.
        • by JanneM ( 7445 ) on Sunday June 01, 2008 @09:20PM (#23621943) Homepage
          Java and Python only solved that problem in the sense that "we support only Unicode". Which kind of sucks for Japanese, since Unicode is actually somewhat broken for the language (not all needed characters are actually defined). And even if you use Unicode, dealing with Japanese does mean dealing with and generating both ISO-2022 and Shift-JS documents on a regular basis.
          • Alright, let me rephrase: the problem has been solved as best as possible given that Unicode is what we've got and it's not going away. Ruby hasn't even gotten that far yet, which is one of my main reasons for preferring Python and Java for serious projects.
            • by JanneM ( 7445 ) on Sunday June 01, 2008 @09:54PM (#23622155) Homepage
              Ruby 1.9 supports unicode just fine. In addition, it supports the needed Japanese encodings, which Java and Python does not do well.
              • Re: (Score:2, Informative)

                by Anonymous Coward
                "Ruby 1.9 supports unicode just fine"

                Just having unicode strings is not enough to "support unicode". Can I sort a list of strings written in french with the built-in unicode libs in Ruby 1.9 ? no, they won't be sorted correctly. Can I do it with Java out of the box ? yes.


                The built in arrays sort in Java can take a collator and know how to sort an array of string in languages other than ASCII english.

                Ruby 1.9 support for unicode is minimal. It just
                • " Just having unicode strings is not enough to "support unicode". Can I sort a list of strings written in french with the built-in unicode libs in Ruby 1.9 ? no, they won't be sorted correctly. Can I do it with Java out of the box ? yes.

                  That is a hopeless endeavor. It will screw up at least in Danish, where e.g. aa might be sorted first or last, depending on (meaning of) the word. I think we have even seen some court battles over whether Aabenraa (a town) gets to be to be first or late in the telephone book.

                  Better to sort in a predictabe, semi-correct way

                  And I am not defending ruby here, as I have not attempted to do i18n in ruby yet.

                  • Re: (Score:1, Interesting)

                    by Anonymous Coward
                    You don't seem to understand how Unicode Collation algorithms work.

                    They are not perfect, but they are FAR better than.. putting every non ASCII character last in a sort, so anything with an accent will be put in the end. That's the way Python and Ruby does it unless you reimplement yourself an ad-hoc, ill-specified, bug-ridden subset of unicode collation algorithms without knowing it.

                    Unicode collation standards do take into account the specifics of a language as m
                • Ruby 1.9 support for unicode is minimal. It just allow you to use unicode but it has absolutely nothing to let you to actually use foreign languages with sorting, capitalization and so on.

                  The things you list are important for internationalization, to which Unicode support (as is support for local encodings where Unicode is not necessarily dominant) is also important, but beyond that they have nothing to do with Unicode support.
              • Having just added support for Japanese to a Java based system I'm working on, how does Java "not do [it] well"? For me it "just worked", once we made our translation house use the same Japanese Unicode font as us.

                • by JanneM ( 7445 )
                  Japanese mostly do not use Unicode at all. To support Japanese users you need to be able to handle Shift-JS and ISO-2022-JP as well, both reading and writing.
                  • Does any programming language do that out of the box? Many people have said it's an issue but no one has said that any language has solved it.
        • PHP also can support other character sets with more or less ease.

          All the reencoding libraries are easy to use and you wont get the weird errors that the GP got.
          • You obviously don't know what we are talking about.

            PHP has just wrappers for basic libc functions for locale support and wrappers for basic iconv functions.

            Strings are not object in PHP, strings are just a sequence of bytes. PHP strings store no info about the charset.

            Sure, you can reencode strings, but that's reinventing the wheel. Things are getting better with PHP6, though.
            • Yeah PHP 6 will be good.

              Storing no metadata about the strings is far better than what the GP was talking about with his Ruby pains. ;)
        • This is exactly why I use Turbogears [turbogears.org] and not Rails ;)
      • Re: (Score:2, Interesting)

        by JanneM ( 7445 )
        That's a bit weird. AFAIK, Ruby 1.9 takes the encoding you use system-wide as the default - if the "2009" above is interpreted as 8-bit ascii, it means that's the encoding for the environment you start ruby in.

      • by tacocat ( 527354 )

        yeah, I have problems with the documenation too. What little documentation they have only works from a connected PC. My notebook it's very portable in this regard. Most places I go I cannot work on any Ruby/Rails code because I can't access the website

    • Gettext is supported, and theirs a Rails plugin that replaces any methods that replace user-visible strings with gettext dictionaries.

      I havn't used it, but from what I've heard it works much like you'd expect gettext to.
  • You can see howto use some of the new features at http://railscasts.com/ [railscasts.com]

    Gem dependencies are awesome. RubyGems has been growing into a sweet package manager / deployment option and being able to easily handle gem dependencies is long overdue.

    Psyched for Rails 2.1 :)
    • by tacocat ( 527354 )

      This is the fundamental disconnect with Rails. RailsCasts is not documentation. It's a marketing tutorial showing how great it can be if you ignore everything important or secure.

      • Wow, what a useful comment.


        No one said that screencasts are documentation. Also, how exactly is railscasts a 'marketing tutorial?' And how does railscasts ignore everything important or secure? Ryan Bates has released a number of railscasts that address security issues with Rails.

        Railscasts is a free screencast site by Ryan Bates, recent recipient of the Ruby Hero Awards. I think you have Railscasts confused with something else.

        Screencasts are merely a learning tool just like books, podcasts, tutor
  • Wt (Score:5, Informative)

    by paugq ( 443696 ) <[gro.reuaple] [ta] [seliuqgp]> on Sunday June 01, 2008 @08:55PM (#23621789) Homepage

    I used to use Rails until I discovered Wt [webtoolkit.eu]: C++, Qt-like API, you develop webapps with widgets (as if they were a desktop application, no more "templates" or "pages") and you don't need to write a single line of HTML, CSS or Javascript. You can deploy it as a FastCGI module for Apache, Lighttp, etc, or as a standalone application with its own webserver. It supports very heavy loads, more than Rails or Django will ever be able to deal with. And you can link to a myriad of existing C and C++ libraries.

    Do you want to authenticate your users using Active Directory? Use Samba and link to libwinbind if on Unix, or link to the Windows API if on Windows (yes, it's cross-platform!). No more worries about language bindings.

    • Re: (Score:1, Interesting)

      by Anonymous Coward
      Very interesting--thanks for the link! My twenty-second look over their "Hello, World!" example shows that the output source is terrible (like so many generated-source frameworks). This is a big downside for me, since I like my XHTML-valid output.

      Definitely bookmarked, though.
    • Re:Wt (Score:4, Interesting)

      by bertilow ( 218923 ) on Sunday June 01, 2008 @10:11PM (#23622293) Homepage
      Brilliant! The WT page states that WT "Generates standards compliant HTML or XHTML code". But the page itself is not valid, and the gorram "Hello world"-example is also not valid, and - as it seems - the same goes for all other WT examples on that site! No, I don't think I will use WT.
    • Which might be great if you never have a graphic designer working on the design, while you work on the actual functionality of the system. If you don't code the HTML by hand, you won't be able to get it to look like the designer wants it. And it won't be the designer's fault. In ASP.Net you can write an entire web app without writing a single line of HTML. You can almost write an app (for various definitions of app) without writing a single line of code. That doesn't mean it's a good idea.
    • Re: (Score:1, Insightful)

      by Anonymous Coward
      On the other hand... I'm not sure I want to be using an unsafe language like C/C++ to be building an Internet-facing application.

      If it's a major bit of kit, like the Apache HTTP server, then sure, I can trust that the developers have got it mostly right, or that at least if there's a flaw, it'll be widely reported.

      But if it's a private app, like most Web applications tend to be, I'd really rather write it in a language that protects against some of the simpler security flaws, like buffer overflows.
      • PHB: "butbutbut...we used safe tool X, that was supposed to protect us from butter overflows!"
        Skillz: "So they nailed you with SQL injection. There is no substitute for knowing WTF."

        I'm not claiming that C/C++ are a great choice for web programming, merely bristling at the rejection as "unsafe".
        • So they nailed you with SQL injection.

          Which can be protected against by either not using a SQL database at all -- depending on the app, a Document database [wikipedia.org] might be better. (I'm not sure yet what kind of app SQL would be more suited for.)

          Or, more relevantly, by never inserting data into your SQL string in the first place. Use placeholder arguments instead, and prepare statements when you can.

          And getting back on-topic, you could also use a framework which discourages using SQL at all, let alone SQL injection. Rails is a good start, there.

          There is no substitute for knowing WTF.


        • The golden rule:

          Don't trust any data input. Escape out user input, use prepare / execute....
    • by pmontra ( 738736 )

      How this http://www.webtoolkit.eu/wt/hello.C [webtoolkit.eu] is better than the equivalent Rail application? No thanks, I have better things to do than wrestle with this sort of things

      b->clicked.connect(SLOT(this, HelloApplication::greet));
      nameEdit_->enterPressed.connect(SLOT(this, HelloApplication::greet)); }

      I just can't think how unmaintenable that can become for a real world application.

      I've been working a little with Python lately, to experiment with Google App Engine. I found it very verbose (that is: I have to explicitly write many things that Rails gives me for free) but it's still much better than what I saw here.

      Anyway, I'm sure th

  • by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Monday June 02, 2008 @04:25AM (#23624341)
    CakePHP [cakephp.org] Framework (supports PHP5 & PHP4), Version 1.2 Stable due any time soon.
    Symfony [symfony-project.org]. PHP 5 Meta Framework using Propel and other layer components. The accompaning book (free PDF, buyable dead-tree) is a very good documentation.
    Prado [pradosoft.com]. Event-Oriented PHP 5 Framework. Very interesting.
    Code Igniter [codeigniter.com]. Lightweight PHP Framework for smaller stuff. Neat website.

    Django [djangoproject.com]. Python Framework.
    TurboGears [turbogears.org]. Python Meta Framework using some 3rd Party stuff like Templating layers and such.
    Zope [zope.org] Web Application Server. To date unmatched. What Rails wants to be when it grows up.
    • by Corrado ( 64013 )
      I have recently thought a bit about what language I would use to code a brand new site from scratch. My first thought was RoR, but I'm not so sure that its the best choice.

      Perl is probably my "base" language but it just seems so old-school for CGI programming. It could definitely do the job but it would end up fairly messy and very hard to read/maintain.

      PHP is on the list as well, but everybody always points and laughs when someone uses it for web programming. It was designed specifically for this and AF
      • You really should give Rails a try - yes, Ruby takes a while to get your head around, although that's less of a problem if you learn Ruby, and *then* Rails. Trying to do both at once is like learning C at the same time as OS development.

        Once you've got the hang of Ruby things make much more sense.

        Just to quickly run through your requirements:

        User authentication: Have a look at the Restful Authentication plugin for something that'll just work. Or write your own auth system - it's really not that hard, and it
      • by miletus ( 552448 )
        Why don't you look at Catalyst? It's a Perl-based framework loosely based on Rails, only with a lot more choice (e.g. CPAN). Or look at CGI::Application for a simple, object-oriented framework that doesn't get in the way.
    • by arevos ( 659374 )
      You missed out Merb and all the other Ruby frameworks, which are arguably the closest alternatives to Rails.

      Zope Web Application Server. To date unmatched. What Rails wants to be when it grows up.
      A little less bias would help, too. I mean, "unmatched"? Unmatched in what areas?
      • Re: (Score:3, Funny)

        by mcvos ( 645701 )

        A little less bias would help, too. I mean, "unmatched"? Unmatched in what areas?
        Unmatched as in: thus far regular expressions failed to find Zope?
    • Curious that you'd feel the need to post this, but even stranger that you'd only include PHP and Python alternates.

      Language evangelism?
  • by tacocat ( 527354 ) <tallison1.twmi@rr@com> on Monday June 02, 2008 @07:23AM (#23625149)

    Rails and Ruby are nice languages, but they really need to start focusing on their documentation.

    The documentation on something as core as DBI returns, "Nothing known about DBI". The website for ruby DBI states that it is a ruby implimenation of Perl DBI. Except that the languages are different and therefore the syntax is different. You spend hours trying to figure out how to use the module.

    Rails is much worse. If any documentation exists as all, it's usually behind the web site peepcode for $9 a tutorial. These tutorials are not documentation but serve as a How To for Dummies, leaving you without sufficient knowledge on the scalability, security, or in many cases, any real clue of how to use the code provided.

    I have brought this up to the Rails community in my area and was told that if I really wanted to learn what was going on that I needed to read the source code. This was not a single person spouting off an answer but the general concensus of the community.

    To find out what public methods are available and how to use them, and even what they do, by trolling through thousands of lines of source code is a sick joke. There is no rational business model that is going to accept this methedology of development and survive in the world for long. It is the availability of fundamental documenation that has made so many languages long standing corner stones of application development.

    I'm no great fan of Java, but they have documentation on everything. I continue to use Perl every day because if I don't already know it, I can find the documentation in a few seconds.

    And to state that all the documentation is available on some website, which they tend to do, is a little short sighted. I haven't yet managed to get my notebook working in all locations of the planet with internet access that's suitable to store all my documentation. Buses, planes, airports, malls, and many other locations simply don't offer unlimited free internet service. But Perl and Java have local documentation so you don't require internet connectivity to do your job.

    Until Ruby & Rails gets their documentation together, they are going to be a minority second class citizen in the world of application development. No company can rationally invest in something that has nothing behind it.

    • Most agree that the "official" documentation for Rails leaves a lot to be desired.

      You seem to have completely ignored the various Rails books though. This is the best way to learn. For example, Agile Web Development with Rails (2nd Edition) or The Rails Way. O'Reilly has been pumping out some Rails books lately too.

    • I have brought this up to the Rails community in my area and was told that if I really wanted to learn what was going on that I needed to read the source code. This was not a single person spouting off an answer but the general concensus of the community.
      Real docs would be better, of course, but did you try it? It's not like when you're tracing Java code in an IDE and accidentally wander into the internals. The code behind Rails is not hard to read, even for a novice -- I'd say it's on par with a W3C spec
      • by tacocat ( 527354 )

        Yeah, I tried it. And you know what? It's a horrible way to learn what something does. I have to guess what the action/result is from the code. And if I'm new to Ruby/Rails, which I am, I am often left wondering what the heck is going on.

        What you overlook is that sometimes the code I'm looking at was written by people much smarter about Ruby than myself so I am looking at code that is far advanced beyond my knowledge. You can't expect someone to know all of it right away.

    • Re: (Score:1, Informative)

      by Anonymous Coward


      or if you like to kill trees, you can buy the following (or buy their PDFs)



      Also, it's trivial to build local documentation for your installation.

      It seems like there is plenty of documentation available and that the APIs are well and publicly documented outside the source code.

      It seems to me that you're simply more accustomed to per
    • Rails and Ruby are nice languages

      No, they aren't. Ignoring the subjective part, Ruby is a language, Rails is a web application framework written in Ruby, not a language.

      but they really need to start focusing on their documentation.

      Well, probably. This seems a pervasive problem, IME, with F/OSS languages and frameworks (but not F/OSS database servers -- SQLite, MySQL, and PostgreSQL all have pretty good documentation.) That said, Ruby and Rails don't seem particularly worse than the norm here (with the excep

    • Insightful? Why would you have to troll thru thousands of lines of source code just to find a public method? Ever tried google? There's great Ruby/Rails API documentation out there ...

      If you google something like 'Ruby String' you get the normal documentation, often on ruby-doc.org ( http://www.ruby-doc.org/core/classes/String.html [ruby-doc.org] )

      If you google something like 'Rails Activerecord' you get the normal documentation, often on api.rubyonrails.com ( http://api.rubyonrails.com/classes/ActiveRecord/Base.html [rubyonrails.com] )

"Atomic batteries to power, turbines to speed." -- Robin, The Boy Wonder