Slashdot Mirror
Ruby On Rails 1.2 Released
Scooter[AMMO] writes "David Heinemeier Hansson sent a post to the Rails 1.2. This new version adds a slew of buff and polish to the rest of the system, as well several new features like RESTful interfaces, response formats, improved multi-byte support, and more. If you haven't checked out the web application framework that aims to renew joy within its users, give it a look. You may be amazed at how easy it makes things without sacrificing power or functionality."
I code web apps in rails for work. I come home and play in Django. There is my renewed joy...
If you'd RTFA instead of rushing to get first post, you would have seen this:
It's too bad Rails 1.2 wasn't released with mongrel (a very nice app server designed to run Rails apps, among other things). Currently deploying a production-ready server capable of running Rails is a uncomfortably unrails-like experience. Mongrel makes things a bit nicer, but even with that running under virtual hosts and/or with SSL requires some seriously heavy lifting (think Mongrel running behind Apache acting as a reverse proxy).
Until we get a quick and easy way of deploying Rails apps -- especially at the shared hosting level for ISPs (along the lines of PHP hosting, which is now standard), Rails will continue to have a difficult time finding a niche. The only place where Rails really belongs right now, and the only place where I'm using it (and loving it) is the corporate intranet, where putting up dedicated mongrel servers for internal web-based apps is not an issue.
For all guys currently using engines, you might want a look at this:
a re-dead-long-live-engines/
http://rails-engines.org/news/2007/01/03/engines-
And after looking at some presentations on their site, I still don't.
All it seems to do is offer a way to do very similar and simplistic web apps without any real-world functionality. I also wonder about the performance and memory profile; seems that the way it handles databases is exactly what DBA's hate to see. Sure, I understand Rails offers you the ability to create websites at high speed, but none of the websites it can create is worthwhile.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
http://jesusphreak.infogami.com/blog/why_django
It's getting installed at a furious rate... we're doing around a gem a second now.
The Army reading list
I did read the article. The problem is, the Rails team has created a module that, by their own admission, will be obsolete within a year.
This alone is a bad engineering practice, but there's also the possibility that the two multibyte systems are incompatible. What if one uses UTF-8 and the other UCS-2? Or UTF-32? All of those are multi-byte. All of them are Unicode. None of them use the same encoding.
Since Rails is commonly used with a database backend, any incompatibilies will cause major upgrade headaches in the future.
This is the sort of thing that gives developers a bad name.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Now that we've just calmed down the Rails bunch they'll be all over us again with foam aroung their mouths. "RAILS! RUBY! RAAAAH!". ...
Here's a list of very good/better alternatives:
Zope - What Rails want's to be when it grows up. Ancient but still ahead of anything else with classic persistance. (www.zope.org)
django - Drinking buddies of the rails people. And they have unicode support. (www.djangoproject.com)
cakephp - YaWebframework. In PHP. Largest community out there. Impressive piece of code (www.cakephp.org). Some De-Normalisation and Relational Trails built in. Very neat.
symfony - PHP 5 Framework. Very good. (www.symfony-project.com)
The biggest suprise for me was reading right here that Rails, as of version 1.2, doesn't have unicode support - and apparently never had. Now that's showstopper imo.
We suffer more in our imagination than in reality. - Seneca
Thanks for the vote of confidence. You might be surprised to know that we thought about all this before we started working on AR:Multibyte.
AR:Multibyte is currently mostly used internally in Rails to make methods multibyte safe. It will be really easy to phase it out when internal support arrives.
Ruby is getting more multibyte support 'in a year', which means that it's at least going to take a few years for everyone to actually get the new version in their OS.
I'm especially surprised because the creator is Japanese and Ruby apparently has a big following there.
I would have thought that multi-byte languages would have been a big deal from the start.
> I would have thought that multi-byte languages
> would have been a big deal from the start.
Yup, they are. Ruby supports UTF-8, JIS, and various other multi-byte encodings. It just doesn't have support for all the Unicode encodings.
Keep in mind that other languages have to change as Unicode changes as well. For example, Java's char primitive is 16 bits, which for a while was enough to store all the Unicode characters. But with Unicode 3.1, supplementary characters can be 21 bits. That's why Java 1.5 introduced a bunch of new Character methods that accept an int, not a char.
The Army reading list
WHOOPS!
Attention deficit disorder is a complicated issue, spanning several major... HEY LET'S GO RIDE BIKES!
Django doesn't use SQLObject. You can, as a programmer, use it of course, since everything in Django is nicely decoupled, but Django uses it's own ORM. The main advantage of using this ORM is of course the production ready administration interface that you get for free, but if you don't need that, there is nothing stoping you from using SQLObject or even better, SQLAlchemy. In fact, there is even a branch in Django to have SQLAlchemy support in the framework.
Using a different ORM, template engine, etc in Django is just a import statement away.
The problem is, the Rails team has created a module that, by their own admission, will be obsolete within a year.
Let me guess - you're one of those that would have waited for jet powered air travel to be invented instead of taking the luxurious ocean liner?
Developers need to choose the tools they feel will best help them get the job done in the time allotted and in their estimation will also allow them an upgrade path at an acceptable level of pain as things (inevitably) change.
According to the release notes, Rails 1.2 works with Unicode.
Rails provides so much more than just MVC. It *is* built on solid OO design, and the ActiveRecord framework is pretty solid, and would take a lot of time to recreate by hand. Why reinvent the wheel? The point of rails is to free you from having to do that stuff all over again. "Don't Repeat Yourself" is the motto, and I find that to be the biggest reason to use rails. As I have grown in my own programming abilities, I've discovered the greatest frustration is when I repeat code (or worse, copy and paste).
With the rails framework, you also get(besides MVC and AR): Built in data validation, error reporting from the validation(model) immediately available to the view, session flash (temporary message carried through to next page view), the new RESTful approach (try it!), different responses based on request type, all sorts of view helpers, easy to integrate ajax.... man I just can't list it all.
One of the great things with Rails is that it is so easy to update. There's three easy steps: Step 1: gem update rails --include-dependencies Step 2: Press return Step 3: There's no step 3
If I remember correctly, there is a cultural issue here in that Unicode is apparently considered with some disdain in Japan and local multi-byte encodings are used, one of which Ruby supports. If you do some searches, you can probably find the full background story.
All of frameworks I've used allow you to drop down to straight SQL for database work, ignore their models and templating (or substitute others), and completely mess up the MVC pattern, if you want. Django goes the farthest towards restricting your options in the latter respect, but it's still possible.
I know you're somewhat kidding, but I just wanted to note that the reason for a framework is above all to have a starting point. Some frameworks do a much better job at that than others, but that's the purpose. If the only purpose was to restrict, they'd be more annoying than not, and people wouldn't use them by choice at all.
I [may] disapprove of what you say, but I will defend to the death your right to say it.
There was a good AC post about it in the "Ruby as a Lisp" posting a few days ago:
It basically has to do with the fact that Unicode uses Han Unification to cause Chinese and Japanese ideograms to share codepoints, and Japanese aren't down with that, so they use Shift-JIS. Check the postings that reply to it for a big digression on the issue ;)
Don't blame me, I voted for Baltar.
Damn autolinky didn't work!
Don't blame me, I voted for Baltar.
Thanks to the Rails developers!
Ruby on Rails is certainly a giant step forward in increasing programmer productivity. The new REST support is great, but I must say that the web based SOAP debugging interface made using SOAP with Rails painless.
A little off topic, but for my customer I integrate Rails with back end Common Lisp code - so far just using home grown REST support at both ends. Eventually, I would like to get the time to generate compiled Lisp libraries directly linked to Ruby when everything is runnng on a single server.
BTW, I created a simply Ruby and Ruby Rails news clipping web site, mostly for my own use, but it might be useful for you: http://rubyplanet.net/
That analogy falls flat on its face, because:
1. Ocean liner travel and jet travel came out over a century apart. I'll be dead in a century, but probably not in a year.
2. Jets are considerably faster than ocean liners, taking hours instead of days. As far as we know, Ruby's multi-byte support will be faster than ActiveSupport::Multibyte, but we have no idea on the order of magnitude that it's faster.
3. The world didn't know about jets when ocean liners were introduced. On the other hand, we know Ruby is gaining multi-byte support in the next major release.
4. There are other benefits for taking a luxurious ocean liner, particularly if it's a cruise ship. What's the advantage to using ActiveSupport::Multibyte? Release date. That's it.
Yes, and I'm free to point out in a public forum that the method presented will be obsolete within a year. The difference is that mine is (afaik) a fact, not an opinion.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Using UCS-2 would be a bug, since it can't encode all Unicode characters, and UTF-32 (more properly, UCS-4) would probably be unnecessarily wasteful. Furthermore, any code that supports Unicode is going to have to support UTF-8 at some point, not least because UTF-8 has become the way of encoding Unicode on Unix, as well as on the Internet.
http://outcampaign.org/
Well, I appreciate the multi-byte support. I think I might actually start using Rails, now.
http://outcampaign.org/
I actually mentioned UCS-2 because Microsoft has historically used it, although it has been superceded (and replaced in newer Windows versions) by UTF-16. Side note: Java also uses UTF-16 internally.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Actually, it's probably Good Engineering.
:)
Ruby (the language) doesn't support Unicode yet.
Rails needs it. So they write a module to support Unicode. Yes, in a year, that module will be obsolete. But then, presumably, the module will then become a pass-through to the native Ruby support.
No code will need to be changed.
That's encapsulation. That's Good Engineering[tm].
Or I could be confused and totally missing the point
Eloi, Eloi, lema sabachtani?
www.fogbound.net
> If it doesn't support UTF-EBCDIC and UTF-9, it's no good to me
Yeah, and what about UTF16LE? C'mon!!
The Army reading list
Changing it to be a passthrough only works if ActiveSupport::Multibyte and the Ruby implementation are identical. dwerg has implied that they are, but since he's not part of the Rails Core Team, I have to take what he said with a grain of salt.
Encapsulation is good, yes. However, all classes should be encapsulated, so that when their internals change, their external interfaces do not.
OK, the problem presented here is what happens with ActiveSupport::Multibyte when Ruby 2.0 comes out. Since you can't force everyone to upgrade Ruby when it comes out, you have to do one of the following:
1. Support two versions of ActiveSupport::Multibyte
2. Write additional code to determine if multi-byte support is present in Ruby
3. Not use Ruby's multi-byte support in ActiveSupport::Multibyte at all
That's why it's a Bad Engineering(tm) decision. Even if the final decision is #2, ActiveSupport::Multibyte then becomes an Unnecessary Layer of Abstraction(tm)/Indirection(tm) of Ruby's multi-byte support on systems that support it, serving no purpose than to slow nice, compiled language calls with calls to Ruby code.
Pandora, you can open that box if you want, but I'm not touching it.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
As someone who works at a software company in Japan, I've never seen any resistance to Unicode here or from any of our partners. In fact we use it all the time.
I have switched from Mongrel (behind Apache) to Litespeed. Mongrel was using too much memory and a mongrel process can only be used for one application. So if you want to set up a cluster of Mongrels for each application, it can quickly eat up a lot of memory. And if you are serious about deploying a Rails application, you should look at a VPS or a dedicated server to do it. For some good Rails hosting companies visit Railshostinginfo.com, which gives you the ability to compare Rails hosting companies.
What if one uses UTF-8 and the other UCS-2? Or UTF-32? All of those are multi-byte.
No, they're not. UCS-2 and UTF-32 are fixed width encodings, not multi-byte. And if UTF-8 is not eventually supported natively by Ruby, then the Rails implementation will still be needed. The rest of the internet is not going to drop UTF-8 just because Ruby does not support it.
UCS-2 was a bad example, as it has been phased out in favor of UTF-16.
The technical introduction to Unicode states "The Unicode Standard defines three encoding forms that allow the same data to be transmitted in a byte, word or double word oriented format (i.e. in 8, 16 or 32-bits per code unit)."
You'll notice that only the first is listed as byte? That's because a word as they have defined it is two bytes long. Two bytes is, of course, more than one byte, thus the term "multi-byte." The UTF-8, UTF-16, UTF-32 & BOM FAQ has a nice table with the minimum and maximum bytes/character that each encoding takes.
(For reference, the Unicode standard refers to the full size of a character as a "code unit" or "code value," rather than a byte.)
This slide, from a presentation given by the Ruby's author, Yukihiro "Matz" Matsumoto, indicates upcoming support for UTF-8.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Just come up with a PHP version of Rails and acceptance and support will improve. Done.
Table-ized A.I.