EPSON chooses Rails for developer site

Jason Wong of ionami has announced that they’ve just launched epsondevelopers.com for EPSON on a Rails platform:

ionami has been working with EPSON for over 3 years. While we created the original EPSON Developers site in Java, they were surprisingly open to a switch. We sold them on maintainability, speed, and the lower overall cost. We took the opportunity to do a redesign, and move the original, public site to Rails for ease of management.

That’s great news! Landing EPSON with Rails development is definitely a great step in that elusive “corporate” direction. At the same time, ionami has announced they’re going to do all future developments using Ruby on Rails. They’re officially a “Rails Shop” now.

Podcasting all over the Rails

Scott Barron has taken Ruby on Rails on the air. Listen to the Ruby on Rails Podcast:

On the show we will delve deep into the warped psyches of the members of the Rails core team. We’ll talk about news related to Rails and the web devlopment communities in general. We’ll talk about tips and tricks you can use to to write better Rails applications, and become a better person.

Rails 0.13.1: Faster for all, eager limits, more Ajax

We’ve returned the default MySQL/Ruby bindings to their former glory, made sure development mode on big applications didn’t get penalized on resetting the object space, and cut WEBricks lust to have a new database connection per request. All changes that actually allows Rails 0.13.1 to live up to the promise of better performance for everyone.

Additionally, we’ve made it possible to use :limit and :offset together with eager loading of has_one and belongs_to associations (has_many and has_and_belongs_to_many will still not work due to the nature of how SQL joins work).

And of course there’s a big bag of delicious script.aculo.us additions and fixes. Be sure to checkout the changelogs for the full scoop as usual:

Compiling the MySQL C-bindings under Tiger

OS X 10.4 Tiger ships with GCC 4.0, which not all software is ready to accept a compilation by. The MySQL C-bindings is such a piece of software, so before doing “sudo gem install mysql” be sure that you do a “sudo gcc_select 3.3” (you can switch back afterwards, if you fancy).

Mike Rundle redesigns the header

Mike Rundle didn’t like the header of this site and with the alternative he came up with, we don’t blame him. The new look is decidedly nicer than boring black-on-yellow. So it’s accepted and integrated. Much nicer. Thanks, Mike!

Odeo launched to the public

Odeo is a portal for finding, syncing, and creating podcasts. It’s might neat and of course it’s mighty Rails. Congratulations to the team for finally making the jump into the public limelight.

Having a portal like this is exactly the final nudge that we needed to get Scott Barron to kick off his forth coming podcasting show about Rails.

Get your Rails swag and wear here!

Bill Katz has setup a Cafepress shop for Rails swag and wear that features our wavy railroad tracks on the back and a discrete Ruby on Rails wording on the front. There’s currently no markup over the standard Cafepress prices, so you can get your Rails thong or baby bip at a pretty descent cost.

This is all just in time for OSCON, so all you Railers can show up representin’ tha posse, yo!

Are you running the final version of Ruby 1.8.2?

A fair number of people have been having problems with Rails 0.13 because it relies on behavior present in the final version of Ruby 1.8.2. That’s the one released on December 25th, 2004. You can check if you have the proper version by doing ruby -v, which should return “ruby 1.8.2 (2004-12-25)”.

If it doesn’t, you need to upgrade. Releases from before December 25th are beta releases that are not ensure to be compatible with Rails. In particular, there’s the session exception like:

NoMethodError: undefined method `new_session' for #CGI::Session:0x259f6c0

…or Proc errors like this:

/gems/actionpack-1.9.0/lib/action_controller/
code_generation.rb:68:in `dup': allocator undefined for Proc (NoMethodError)

Both tell, tell signs that your Ruby beta has exceeded its expiration date.

What's with this DoubleRenderError?

Another haunting feature of 0.13 is the DoubleRenderError. Jamis explains it purpose:

In order to understand why the DoubleRenderError was necessary, you need to understand something about the render and redirect_to methods that may surprise you. Many programmers expect a call to render or redirect_to to immediately cease execution of their action and return the result back to the browser. This is not the case in Rails. Unless you explicitly return after rendering or redirecting, your action will continue on its merry way as if nothing had happened.

Go read the full thing and you’ll go “ahhhh, thank heavens for DoubleRenderError!”.

Feeling the slowdown blues after going 0.13?

It’s somewhat ironic that we heralded Rails 0.13 as being a great move forward for the performance of Rails and then half the threads on the mailing list is about “Rails is sLOOOW!”. We’ve found the problems, though.

The first was with the MySQL/Ruby bindings, which called GC.start whenever MySQL#free was called. And we just put in MySQL#free in 0.13 to improve things after each select of rows. This caused the garbage collector to run every time you selected something. Doh!

The C-bindings didn’t have this problem, so it wasn’t discovered by the core team right away, and that was posed as the solution on the mailing list. Unfortunately, it’s not necessarily trivial to compile native bindings on all platforms (notably Windows), so having fast Ruby bindings was indeed important. They’re fast again, but if you upgraded to the C-bindings you can be happy that you’re even faster.

The second problem was that we plugged a big memory leak in development mode, but doing so caused a total of 8 runs through the so-called ObjectSpace after each action (basically iterating over all objects in the interpreter 8 times, eeks!). On big applications this could take a while. On Basecamp it took 2 seconds. After the fix went in where we just traverse the ObjectSpace once, it’s down to a comfortable 0.2 seconds (which is about 0.17 faster than it even was before the memory leak fix!).

Thus, Rails 0.13.1 is near forth coming. As in this weekend. If you cannot wait, and we certainly won’t blame you, there are new beta gems that consist purely of bug fixes. Upgrade with gem install rails --source http://gems.rubyonrails.org --include-dependencies.