Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Rails 2.1 Is Now Available

Posted by kdawson on Sun Jun 01, 2008 07:36 PM
from the blood-on-the-tracks dept.
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."
+ -
story

Related Stories

[+] Microsoft Linking Silverlight, Ruby on Rails 232 comments
CWmike writes "Friday Microsoft will demonstrate integration between its new Silverlight browser plug-in and Ruby on Rails. Microsoft's John Lam, a program manager in the dynamic language runtime team, said in a recent blog item: 'Running Rails shows that we are serious when we say that we are going to create a Ruby that runs real Ruby programs. And there isn't a more real Ruby program than Rails.' Also at the event, Microsoft officials will demonstrate IronRuby, a version of the Ruby programming language for Microsoft's .Net platform, running a Ruby on Rails application."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • 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)

      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
      output_file.close

      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)

        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.

                http://java.sun.com/docs/books/tutorial/i18n/text/locale.html

                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.

        • 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.
      • Re: (Score:2, Interesting)

        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.

    • 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 :)
  • Wt (Score:5, Informative)

    by paugq (443696) <pgquiles@[ ]auer.org ['elp' in gap]> 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: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.
      • 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.

          It's

        • The golden rule:

          Don't trust any data input. Escape out user input, use prepare / execute....
  • by Qbertino (265505) 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.
    • 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
      • Re: (Score:3, Funny)

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

        • Re: (Score:3, Informative)

          Yes, you do. At least, if you installed the usual way. Run "gem server" from the command line, and go to http://localhost:8808 in your preferred browser. The layout's different (slightly), but the info's there.