×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Rails 2.1 Is Now Available

kdawson posted more than 5 years ago | from the blood-on-the-tracks dept.

Programming 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

71 comments

pf? (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#23621271)

first piss

Internationalization (1)

PhrostyMcByte (589271) | more than 5 years ago | (#23621377)

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 (4, Informative)

Vectronic (1221470) | more than 5 years ago | (#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:Internationalization (2, Informative)

slick50 (136573) | more than 5 years ago | (#23621653)

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.

I love Ruby and Rails, don't get me wrong... (5, Informative)

patio11 (857072) | more than 5 years ago | (#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:I love Ruby and Rails, don't get me wrong... (2, Interesting)

setagllib (753300) | more than 5 years ago | (#23621845)

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.

Re:I love Ruby and Rails, don't get me wrong... (5, Informative)

JanneM (7445) | more than 5 years ago | (#23621943)

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.

Re:I love Ruby and Rails, don't get me wrong... (1)

setagllib (753300) | more than 5 years ago | (#23622079)

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.

Re:I love Ruby and Rails, don't get me wrong... (4, Informative)

JanneM (7445) | more than 5 years ago | (#23622155)

Ruby 1.9 supports unicode just fine. In addition, it supports the needed Japanese encodings, which Java and Python does not do well.

Re:I love Ruby and Rails, don't get me wrong... (2, Informative)

Anonymous Coward | more than 5 years ago | (#23623749)

"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 allow you to use unicode but it has absolutely nothing to let you to actually use foreign languages with sorting, capitalization and so on.

Re:I love Ruby and Rails, don't get me wrong... (1)

EsbenMoseHansen (731150) | more than 5 years ago | (#23624001)

" 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:I love Ruby and Rails, don't get me wrong... (1, Interesting)

Anonymous Coward | more than 5 years ago | (#23624419)

You don't seem to understand how Unicode Collation algorithms work.
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 much as possible. Go see section 1.3 on the link and the level of complexity unicode can deal with, like the stupid french accents rules that state that the last accent in a word is the one which determinate order.

Java implements collation classes, you tell the locale/language to the sorting algorithm and it will get its collation comparator.

Ruby and Python only implements the bare minimum to support unicode, unfortunately.

Re:I love Ruby and Rails, don't get me wrong... (1)

DragonWriter (970822) | more than 5 years ago | (#23640975)

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.

Re:I love Ruby and Rails, don't get me wrong... (1)

LizardKing (5245) | more than 5 years ago | (#23625401)

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:I love Ruby and Rails, don't get me wrong... (1)

JanneM (7445) | more than 5 years ago | (#23625841)

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.

Re:I love Ruby and Rails, don't get me wrong... (1)

AmaDaden (794446) | more than 5 years ago | (#23626257)

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.

Re:I love Ruby and Rails, don't get me wrong... (0)

Anonymous Coward | more than 5 years ago | (#23628583)

I don't get the problem. In Python you'd read data as raw bytes (a str() object Python 2.x, a bytes() object in Python 3.x), then you'd decode() that data to a Unicode object using the appropriate encoding (Python's standard encodings include multiple variants of JIS/SJIS), work on that data as a Unicode string, then once you're done processing it encode() it back to the relevant encoding before outputting the data. Where's the problem? If Unicode doesn't support all JIS/SJIS characters then there's a problem that needs to be solved in Unicode itself, holding off on a Unicode-based solution to the general encoding problem because of a issue with current Unicode support of one language is silly. OK, if your application is targeted specifically for the Japanese market then that's a problem, but in that case don't convert to Unicode, instead deal with it the raw byte string from start to finish.

Re:I love Ruby and Rails, don't get me wrong... (1)

Dahan (130247) | more than 5 years ago | (#23624531)

since Unicode is actually somewhat broken for the language (not all needed characters are actually defined).
Do you have any more details on that? My understanding was that all characters in traditional/legacy Japanese encodings are included in Unicode (with some exceptions, as mentioned in the standard [unicode.org] (PDF warning). Do you have an example of a character encoded in, e.g., ISO-2022-JP, that's not in Unicode?

Re:I love Ruby and Rails, don't get me wrong... (1)

JanneM (7445) | more than 5 years ago | (#23625985)

A decent, if somewhat rambling description of the whole problem is available here [hwacha.net]. Skip the history and go the "Han unification section" if you want.

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 glyphs are called for. It is much the same as the Swedish "ö" and the Danish "ø" have the same sound and the same origin, but are now considered separate glyphs. More serious is that various kanji forms used in given names are absent or changed; this tends to not go down well with people bearing such names.

Re:I love Ruby and Rails, don't get me wrong... (1)

Dahan (130247) | more than 5 years ago | (#23632267)

Ah, I've heard the arguments against Han unification, and don't particularly agree with them... although perhaps I'm described by the, "... the person is thinking of Chinese usage, which is usually much looser than Japanese" in the page you posted (I'm Chinese, but I know a little Japanese).

In the case of hone, my opinion is that if you use a Japanese font, it'll display the Japanese way (little square in the lower-right of the bigger one); if you use a Chinese font, it'll display the Chinese way (little square in the lower-left). An analog with the Roman character set is the "a" that looks like an ellipse with a vertical bar on the right vs. the "a" where the bar curves up over the top of the ellipse. Or the two main styles of writing "g"--they aren't assigned separate Unicode code points.

More serious is that various kanji forms used in given names are absent or changed; this tends to not go down well with people bearing such names.

However, I'm more intrigued by the part about kanji used in given names, which brings me back to my question about if there's a character in the JIS character set that's not in Unicode... page 418 in the section of the Unicode spec I linked to describes Unicode's Han unification rules, and the first rule is the "Source Separation Rule. If two ideographs are distinct in a primary source standard, then they are not unified." JIS X 0208-1990 and JIS X 0212-1990 are both listed as primary sources. They give an example of the ken in kendou (as in the martial art/sport), meaning "sword". There are 6 variants of that kanji in JIS, and they were not unified in Unicode--the 6 variants are in Unicode too. So it was my understanding that due to Unicode's Source Separation rule, if a Japanese person had an unusual kanji variant in his name that was separately encoded in JIS, it was also available in Unicode. Is that not the case?

The "Personal Names" section of the article you linked mentions, "by 1983 [the kanji that could appear in names] was a subset of the JIS X 0208 character set." and goes on to discuss debate about expanding the list. But what I got out of it is that some people who used exotic kanji had problem with not finding their character in the original Japanese encoding standard; while it may still be a problem in Unicode today, it's not a problem Unicode introduced and using, e.g., ISO 2022 JP doesn't solve the problem.

And I think this paragraph agrees with me... it says the subvariants are not in JIS either:

For an example of missing variants, the name 'watanabe' has often been used. There are three main variants of the second character in this name; one new and two older ones (U+908A and U+9089). The original JIS standard included both older ones. However, the older ones each have several subvariants used by various families, which were not in JIS and are therefore, as far as I know, still not in Unicode. These variants (and many other name variants) can be represented by many products sold in Japan designed specially for representing variant kanji, but there is no standard encoding for such products.

Re:I love Ruby and Rails, don't get me wrong... (1)

cheater512 (783349) | more than 5 years ago | (#23624105)

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:I love Ruby and Rails, don't get me wrong... (1)

chrysalis (50680) | more than 5 years ago | (#23635437)

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.

Re:I love Ruby and Rails, don't get me wrong... (1)

cheater512 (783349) | more than 5 years ago | (#23635455)

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

Re:I love Ruby and Rails, don't get me wrong... (2, Interesting)

JanneM (7445) | more than 5 years ago | (#23621915)

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.

Re:I love Ruby and Rails, don't get me wrong... (1)

tacocat (527354) | more than 5 years ago | (#23625165)

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:I love Ruby and Rails, don't get me wrong... (0)

Anonymous Coward | more than 5 years ago | (#23625273)

Have you tried this ?
# Start gem_server
> gem server
# Open web browser
firefox http://localhost:8808/ [localhost]

Re:I love Ruby and Rails, don't get me wrong... (1)

tacocat (527354) | more than 5 years ago | (#23634323)

Yes, but plugins don't come from the gemserver and not all gems, like much of the core API have good documentation to begin with.

Re:Internationalization (1)

Jellybob (597204) | more than 5 years ago | (#23624975)

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.

Re:Internationalization (0)

Anonymous Coward | more than 5 years ago | (#23626189)

Fuck unicode, who wants to write like a paki or a jew?

Screencasts of New Features (2, Informative)

remitaylor (884490) | more than 5 years ago | (#23621519)

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

Re:Screencasts of New Features (1)

tacocat (527354) | more than 5 years ago | (#23625175)

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:Screencasts of New Features (1)

remitaylor (884490) | more than 5 years ago | (#23635539)

Wow, what a useful comment.

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, tutorials, etc. There are some people out there who might want to watch howto use some of the latest Rails 2.1 features. Others will simply read the docs. So what?

got goat? (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#23621549)

poop in your mouth

Rails is obsolete, Django is the next new thing (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#23621711)

Rails is SOOO last fad. The new thing is Django for all you who like to look at new things.

Wt (5, Informative)

paugq (443696) | more than 5 years ago | (#23621789)

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 (0)

Anonymous Coward | more than 5 years ago | (#23622013)

Whoa, a framework like that is tempting enough to learn C++ for.

Re:Wt (1, Interesting)

Anonymous Coward | more than 5 years ago | (#23622103)

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 (3, Interesting)

bertilow (218923) | more than 5 years ago | (#23622293)

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.

Re:Wt (1)

CastrTroy (595695) | more than 5 years ago | (#23622447)

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:Wt (1, Insightful)

Anonymous Coward | more than 5 years ago | (#23622523)

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.

So, after the break-in, during the post-mortem... (4, Insightful)

smitty_one_each (243267) | more than 5 years ago | (#23622709)

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

Re:So, after the break-in, during the post-mortem. (1)

SanityInAnarchy (655584) | more than 5 years ago | (#23623543)

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 not a substitute, it's a supplement. Yes, you have to know more than just "OMG RAILZ IS TEH AWESUM" -- but it is nice when you no longer even have to think about buffer overflows or SQL injection.

Re:So, after the break-in, during the post-mortem. (1)

AliasTheRoot (171859) | more than 5 years ago | (#23624629)

The golden rule:

Don't trust any data input. Escape out user input, use prepare / execute....

Re:Wt (0)

Anonymous Coward | more than 5 years ago | (#23623703)

Yes , it is possible to have mixed feelings about C++ :)

      Sometimes ago there was WebObject in ObjectiveC, but now it's all in java ... (there is still gnuStepWeb : http://wiki.gnustep.org/index.php/Creating_A_Simple_GSWeb_Application )

Re:Wt (1)

pmontra (738736) | more than 5 years ago | (#23624637)

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 that some people with a different background than mine (which however includes C and Java) might find easier to code with Wt than learning Rails or Python.

Once again - The Alternatives: (4, Informative)

Qbertino (265505) | more than 5 years ago | (#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.

Re:Once again - The Alternatives: (1)

Corrado (64013) | more than 5 years ago | (#23624633)

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 AFAIK works pretty well, as long as your careful about construction. But that pretty much goes for any language...

I just don't care for Python much. I don't know why really, I think it just reminds me too much of COBOL or something. :/

I think I would like to love RoR but I cant seem to gather the momentum to really drink the cool-aid. I love the way it works and the cool features it brings to the web programming table, I really do. However, I can't seem to wrap my head around Ruby. Even doing simple stuff sends me running to find a tutorial or example code. I admit I'm not a hard core programmer (anymore) and that I haven't immersed myself knee deep in code in years, but I find it hard to even think about some things in Ruby and keep them straight in my head. It's kind of like C pointers. :)

Speaking of C/C++, I don't think I would ever write a web interface in either one. Enough said about that.

Java is probably the only other choice on my plate and while it should be a great one I cant shake the feeling that its still a tool looking for a problem to solve. There are probably hundreds of Java frameworks out there to choose from, and that's probably its downfall. I feel like I have to include a whole mess of extra things and carry around a dump truck load of libraries & packages just to do something simple. I'm not saying that Java is slow (I've spent many years fighting that notion) but that its deployment heavy. That said, it does have some massively good things in its corner: language maturity, great tools, and coherent documentation. RoR is still trying to nail these things down.

Anyway, what I want out of a web programming framework is pretty simple. I want to:
  - be able to implement a user authentication & authorization system in a simple and effective manor.
  - connect to databases in a generic way so that I'm free to switch platforms in the future.
  - make using CSS free and easy.

That's pretty much it and it seems simple enough. I guess any language above could handle the task but I haven't found any thing that really jumped out at me. I'm thinking about giving RoR another try now that they seem to be maturing or maybe one of the PHP frameworks Qbertino suggested.

</soapbox>

Re:Once again - The Alternatives: (1)

Jellybob (597204) | more than 5 years ago | (#23625005)

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's a good introduction task.

Database system independance: Available out of the box - you can even develop against one type of DB, and then deploy your app to another, so long as you don't drop down to vendor specific SQL queries.

CSS: This isn't so much a Rails feature. It has a few helper methods to load stylesheets and apply relevant classes to pages, but no built in styles. Have a look at Blueprint CSS if you want somewhere to start from.

Re:Once again - The Alternatives: (1)

miletus (552448) | more than 5 years ago | (#23645749)

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.

Re:Once again - The Alternatives: (1)

arevos (659374) | more than 5 years ago | (#23625369)

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:Once again - The Alternatives: (2, Funny)

mcvos (645701) | more than 5 years ago | (#23625443)

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?

Re:Once again - The Alternatives: (1)

bill_mcgonigle (4333) | more than 5 years ago | (#23628915)

Curious that you'd feel the need to post this, but even stranger that you'd only include PHP and Python alternates.

Language evangelism?

Re:Once again - The Alternatives: (0)

Anonymous Coward | more than 5 years ago | (#23630887)

I used to be a Python programmer. I even tried to build a serious site on Zope. It has some really cool ideas, but if you think this is what Rails "wants to be when it grows up", you must have a strange idea of what grown-up means.

For a while, it wasn't even possible to figure out which Zope to download. Zope 2 was mostly stable, but unsupported, because they decided they needed to rewrite [joelonsoftware.com] a bunch of things and call it Zope 3. Then somebody saw that having "stable, ancient, unsupported" and "unstable, new, unfinished" were not really good options, so they started The Five Project to combine them. Unfortunately when your problem is "too many distributions", adding another distribution is not always the answer.

Zope was killed by the same thing that Netscape was: they said "everybody in the world, stop what you're doing so we can rewrite it". It's so sad to see this Pattern repeated so many times.

Say what you will about Rails (and I've got pages and pages of rants about stupid things they've done), Zope is not the ne plus ultra web framework.

Rails is what Zope wants to be when it grows up: useful, and used.

I'm seeing massive performance problems. (0)

Anonymous Coward | more than 5 years ago | (#23625073)

I just upgraded two of my sites to using 2.1, and I'm seeing massive performance losses. Rails is the only thing that's changed on both of these servers, so I'm pretty sure it's to blame. I've since rolled one of the servers back, and it's performing fine again. So please beware with this new release, there may be some serious performance-related bugs with it. I'll keep you guys updated with my investigation.

Documentation Sucks (3, Insightful)

tacocat (527354) | more than 5 years ago | (#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:Documentation Sucks (0)

Anonymous Coward | more than 5 years ago | (#23625745)

Rails documentation is not a sick joke, it's a commercial endeavour :/ (see books, paying how-tos, screencasts, ...) The documentation exists but you must pay for it.

Re:Documentation Sucks (1)

tacocat (527354) | more than 5 years ago | (#23634315)

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:Documentation Sucks (1)

carlivar (119811) | more than 5 years ago | (#23626695)

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.

Re:Documentation Sucks (1)

Doctor Faustus (127273) | more than 5 years ago | (#23628161)

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

Re:Documentation Sucks (1)

tacocat (527354) | more than 5 years ago | (#23634289)

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:Documentation Sucks (0)

Anonymous Coward | more than 5 years ago | (#23629355)

It's not quite as bad as you make it out to be. It sounds like you are looking for the Rails API docs [rubyonrails.org]. These docs are also typically distributed with Rails AFAIK.

Additionally, there are several good books like the "Pickaxe" book (Which is an excellent starting point IMO) but they tend to be slightly outdated as Rails continues to evolve.

Re:Documentation Sucks (1)

tacocat (527354) | more than 5 years ago | (#23634303)

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:Documentation Sucks (2, Informative)

RegularFry (137639) | more than 5 years ago | (#23637705)

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.

Re:Documentation Sucks (1, Informative)

Anonymous Coward | more than 5 years ago | (#23631351)

http://www.ruby-doc.org/

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 perl, and secondly that you're a fucking idiotic twat.

Re:Documentation Sucks (1)

DragonWriter (970822) | more than 5 years ago | (#23632721)

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 exception of the Ruby core (vs. standard library) documentation at ruby-doc.org, which is rather messed up.)

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.


The main documentation for Rails is the rdoc, which is part of the distribution and also available over the web for free.

Aside from that, the best source is probably the book Agile Web Development with Rails, the most recent version of which is currently available as a Beta pdf.

The documentation on something as core as DBI returns, "Nothing known about DBI".


What documentation on DBI "returns" that? (DBI is not part of Ruby's core, or its standard library, or Rails [though rails can use it], so I'm not sure how any problem with DBI's documentation is relevant to criticism of Rails' or Ruby's documentation.)

Re:Documentation Sucks (1)

remitaylor (884490) | more than 5 years ago | (#23635585)

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

You can browse API sites or you can just look at the same HTML documentation that's generated on your local PC when you install Ruby/Rails or any RubyGems. You don't need internet connectivity.

I don't know why people think that screencasts like those on Peepcode have *anything* to do with documentation because they don't. You can watch screencasts for learning C#/Java/etc too. It's not something that's unique to Ruby or Rails, it just so happens that there are some very nice Ruby/Rails screencasts (notable via Peepcode and Railscasts). Java has books - so does Ruby. Hibernate has books - so does Rails. They all have local and online documentation.

That said, I read the source code for Ruby apps to find the answers to my questions quite often. Ruby is very expressive so much of the code reads like documentation ... if I want to see what is done with a variable I pass in, NO language's documentation could help that ... you'll ALWAYS need to read the source code.

I'm baffled by why people think of Ruby/Rails screencasts negatively ... I've never heard people bash Lynda.com before ... what's wrong with people wanting to supplement the learning tools out there? Seriously. There's a lot of Ruby/Rails documentation ... I've been using Ruby for 3+ years and Rails for 2+ and I can't remember ever having trouble finding documentation (and I came to Ruby/Rails from .NET & Java).

I'm sorry if you're using some old legacy Ruby library and the developers didn't provide any documentation but you can't generalize that to the whole of the Ruby and/or Rails communities. It's simply wrong. There's lots of great documentation out there.

Not enterprisey enough (0)

Anonymous Coward | more than 5 years ago | (#23626645)

I could never use Rails, and the reason is that it is not enterprisey enough. I do not mean that I should be making lots of fancy boxes with Visio and do some really weird stuff. What I mean is that I have to resort to (semi-)abandoned 3rd party libraries to get ahold of the de facto integration way - SOAP. Rails developers made a stellar mistake by dropping those features from the core, instantly decreasing the adoption rate of Rails in corporations near to zero. In the long run it is just now more work and much more (perceived) risks.

On the other hand, EJB 3.x made creating web services in java quite as much easy (compared to what Rails USED TO have), so I guess many people will migrate there fast if they have not already...

Re:Not enterprisey enough (1)

metamatic (202216) | more than 5 years ago | (#23628291)

It's a pity SOAP 1.2 isn't back-compatible with SOAP 1.1. Kinda spoils the easy integration story.

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.

Re:Not enterprisey enough (0)

Anonymous Coward | more than 5 years ago | (#23628447)

I am using vendor *cough* enhanced *cough* ide, tools, and such.. It's a complete ecosystem, and you're in synch.

Even without that you'd have better chances that with Rails.
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...