Slashdot Mirror
Rails 2.1 Is Now Available
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."
i just started not caring about rails 2.0!
Do you even lift?
These aren't the 'roids you're looking for.
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.
You can see howto use some of the new features at http://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
I used to use Rails until I discovered Wt: 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.
... but I burned about 16 hours of company time last week trying to do the following:
.rb script written in UTF-8, with Japanese in it.
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.
Help poke pirates in the eyepatch, arr.
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".
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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.
Don't thank God, thank a doctor!
CakePHP Framework (supports PHP5 & PHP4), Version 1.2 Stable due any time soon.
Symfony. PHP 5 Meta Framework using Propel and other layer components. The accompaning book (free PDF, buyable dead-tree) is a very good documentation.
Prado. Event-Oriented PHP 5 Framework. Very interesting.
Code Igniter. Lightweight PHP Framework for smaller stuff. Neat website.
Django. Python Framework.
TurboGears. Python Meta Framework using some 3rd Party stuff like Templating layers and such.
Zope Web Application Server. To date unmatched. What Rails wants to be when it grows up.
We suffer more in our imagination than in reality. - Seneca
The golden rule:
Don't trust any data input. Escape out user input, use prepare / execute....
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.
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.
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...