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."
damnit (Score:1, Funny)
Internationalization (Score:2)
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.
Re:Internationalization (Score:5, Informative)
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)
I love Ruby and Rails, don't get me wrong... (Score:5, Informative)
1) Have a
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)
Re:I love Ruby and Rails, don't get me wrong... (Score:5, Informative)
Re: (Score:2)
Re:I love Ruby and Rails, don't get me wrong... (Score:4, Informative)
Re: (Score:2, Informative)
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
Re: (Score:2)
" 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)
http://www.unicode.org/unicode/reports/tr10/
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
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Perhaps the most commonly given example (not the most problematic, but involving a common character) is "hone" (bone), which has been conflated with the Chinese character of the same meaning. Problem is, kanji and hanzi have drifted apart in this case (and in plenty others), so the correct way to write it actually differs between the languages, and thus two gly
Re: (Score:2)
All the reencoding libraries are easy to use and you wont get the weird errors that the GP got.
Re: (Score:2)
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.
Re: (Score:2)
Storing no metadata about the strings is far better than what the GP was talking about with his Ruby pains.
Re: (Score:2)
Re: (Score:2, Interesting)
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
I havn't used it, but from what I've heard it works much like you'd expect gettext to.
Screencasts of New Features (Score:2, Informative)
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
Re: (Score:2)
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.
Re: (Score:1)
What?
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)
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)
Definitely bookmarked, though.
Re:Wt (Score:4, Interesting)
Re: (Score:2)
Re: (Score:1, Insightful)
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.
So, after the break-in, during the post-mortem... (Score:5, Insightful)
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".
Re: (Score:2)
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
Re:So, after the break-in, during the post-mortem. (Score:2)
Don't trust any data input. Escape out user input, use prepare / execute....
Re: (Score:1)
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
Once again - The Alternatives: (Score:5, Informative)
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.
Re: (Score:2)
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:2)
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
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Funny)
Re: (Score:2)
Language evangelism?
Documentation Sucks (Score:4, Insightful)
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:2)
Yes, there are some docs available and you do have to pay what adds up to a pretty price to see it. But even after you buy all the books and tutorials you don't have much value for the money you put out.
The ratio of knowledge gained to dollars spent is on par or below Microsoft's business model.
Rails, and Ruby, does not have a sustainable future under this model. There are too many alternative languages that have everything already out there.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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:2)
You missed the whole point entirely. I don't have access to the Rails API docs when I am not sitting in a coffee shop or my house. I can't get to the internet while on a plane, train, automobile, or other transportation. Similarly, I don't have internet access everywhere I might be.
So the Rails API docs, as a website, sucks.
Re: (Score:3, Informative)
Re: (Score:1, Informative)
http://api.rubyonrails.org/
or if you like to kill trees, you can buy the following (or buy their PDFs)
http://pragprog.com/titles/ruby/programming-ruby
http://pragprog.com/titles/rails3/agile-web-development-with-rails-third-edition
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
Re: (Score:2)
No, they aren't. Ignoring the subjective part, Ruby is a language, Rails is a web application framework written in Ruby, not a language.
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
Re: (Score:1)
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] )
Re: (Score:2)
I've been trying to connect to a SOAP 1.1 implementation using Java, and the current Java API (SOAP 1.2) doesn't support rpc/encoded required to pass data to my SOAP 1.1 back-end.