Sho Fukamachi Online

So Rails 2.3.5 is out and while I don’t really know what’s new, I can tell you what isn’t – not running on the current stable version of the ruby programming language as reported by Ruby-Lang.

If you would like to start testing Rails on 1.9, you’ll need to apply the patches listed at this Lighthouse ticket, which fix the two most serious problems. A kind user down the bottom of that ticket has pulled the patches into monkeypatches suitable for just slipping into your config/initializers folder – I can confirm that they work for me.

I cannot fathom Rails Core’s bizarre refusal to pull these patches into 2.3.5. Yet another release goes out that is completely non-functional on the newest, fastest and best version of the language, forcing users to seek out and apply non-official monkeypatches – or just forsake 1.9 altogether, as the vast majority seem to be doing. In what way is this in the best interest of the framework or the community? What is holding them back? The patches might not be 100% perfect but they’re a lot better than what we have now, which is that out of the box Rails is broken on 1.9.1.

UPDATE: Happily, the 1.9.1-patched Rails does seem to be working on 1.9.2 as well. I’ve installed ruby 1.9.2dev (2009-09-07 trunk 24787) and my favourite “fussy site” is working there, too. That’s great news, because 1.9.2 is going to be the “serious” version of Ruby 1.9 and has further big performance increases.

So I’ve been ranting recently about Rails’ lack of Ruby 1.9 support. And rightfully so! It’s inexcusable for the #1 Ruby framework to not support the fastest, most efficient version of Ruby, especially not after it’s been available for almost 2 years.

But for some people, it is kind-of possible to use Rails on 1.9 today. Rails’ 2.3-stable (“stable” in quotes) branch has fixed a few of the worst problems in 2.3.4, such as the string comparison bug which made authentication systems unworkable. The showstoppers for me, like the utf8 in templates issue, remain. I wouldn’t rely on it in production – not for a site which your job depends on, anyway – but as long as you don’t use certain features of rails (like i18n), and don’t need to deal with utf8 much if at all, you may be able to use it.

You should want to switch to 1.9.1 as soon as possible. I see between 20% and 50% higher performance than 1.8.7, with memory usage significantly lower and even better, less prone to leakage. In one of my projects there is a daemon which does nothing except wait for items to hit a queue and then launches a script to deal with them. In 1.8.7, it would gain a meg or so every few hours and I’d be nervous about leaving it running unmonitored. In 1.9.1 it sits rock solid on 6.5M for weeks on end. I am totally sold on 1.9.1.

Anyway, here’s the instructions to get Rails up to the latest possible usable state. Open a terminal at the root of your Rails app:

# head into /vendor
$ cd vendor
 
# clear out any other rails
$ rm -rf rails/
 
# clone rails into here
$ git clone git://github.com/rails/rails.git rails
Initialized empty Git repository in /Users/sho/projects/myproject.com/vendor/rails/.git/
remote: Counting objects: 123204, done.
remote: Compressing objects: 100% (27700/27700), done.
remote: Total 123204 (delta 95101), reused 121853 (delta 94037)
Receiving objects: 100% (123204/123204), 21.72 MiB | 380 KiB/s, done.
Resolving deltas: 100% (95101/95101), done.
 
# enter that directory
$ cd rails/
 
# checkout 2.3 stable, ignore the errors
$ git checkout -b  2-3-stable remotes/origin/2-3-stable
warning: unable to unlink arel: Operation not permitted
warning: unable to unlink rack-mount: Operation not permitted
Branch 2-3-stable set up to track remote branch 2-3-stable from origin.
Switched to a new branch '2-3-stable'
 
# go back to the root dir 
$ cd ../..
 
# run rails as 1.9.1. get ready to find out which gems you forgot!
$ ruby1.9 script/server
 
# hello, console
$ script/console --irb=irb1.9
Loading development environment (Rails 2.3.4)
>> RUBY_VERSION
=> "1.9.1"

And there you go. It’s working, kind of. Try it out.

I would probably recommend using thin as the web server, but if you need a working mongrel in 1.9, my gem is still available:

sudo gem1.9 install sho-mongrel

That will probably die when github pulls gems for real but who knows, maybe the official mongrel will have been fixed by then (HA!).

Meanwhile, I’m going to step up my harassment of the Rails Core team to get this crap fixed; it is a fucking JOKE that it still doesn’t work 100%.

update: moved the gem to gemcutter.

Ruby on Rails development seems to be stalled, with no substantial release since March and many show-stopper bugs in the current version, 2.3.4, such as the claimed Ruby 1.9 support which does not work, meaning that the official Rails gem doesn’t run on the only version of Ruby that doesn’t leak memory like a firehose leaks water. Freezing to edge is broken and has been broken for months. Needless to say, that’s because master is now Rails 3.0pre which is in a totally unrunnable state.

The seems oddly low-volume, considering 2.3.5 is over a month late and 2.3.4 has so many problems. Working patches to fix critical errors languish unmerged for months, constantly needing to be regenerated to keep up – not that there’s anything official to keep up with, since there’s no real 2.3.5 target and master is fixated on the faraway 3.0. The Lighthouse tracking system is itself a hopeless, unnavigable mess.

So what’s going on with Rails? With the historical core developers absent or tied up with reinvent-the-world expeditions like the 3.0 rewrite, the projects appears directionless and adrift. Meanwhile the shine fades and word leaks out that all is not well in Railsville.

What happened? Two causes.

Firstly, the shoot-for-the moon total rewrite for Rails 3, leaving Rails 2 languishing for the better part of a year now and Rails 3 in a totally unrunnable state.

Secondly – well, this is just my opinion. But one of the reasons Rails was great at first because it was written by people who actually wanted to use it to make actual proper web apps. And then it became famous, and then it attracted another type of developer – people who just wanted their membership in Rails Core on their resumé – but they weren’t going to actually use it for real-world projects. So instead of getting fixes to seven-month-old show-stopper bugs, we get Engines and RESTful Resource Mapping and Application Templates, none of which are much used or useful in the real world.

Rails is looking sicker by the month. And since Core has bet the company on Rails 3.0, it better blow the world away and fix everything, or I have a feeling a lot of Rails devs are going to start looking for the next big thing. Or actually, the next small thing. I would trade off 90% of Rails’ useless bloat and feature creep for a minimalist framework that actually works, has developers who care, has a readable codebase and a clear direction. Basically, what Rails used to be before DHH got tired of saying “NO!” and it turned into a stumbling monster.

Sinatra? It’s possible but it’s a little too unstructured; great for a tiny API but I’d be worried about trying to use it for a large project. Django is by all appearances in even worse shape than Rails. Ramaze? Looks very interesting.

Update to turn down the tone a bit and correct some links. I will follow up with some constructive posts later; it is actually possible to run Rails on 1.9, just takes some work.

Processing AdminController#do_import (for 124.170.0.0 at 2009-09-14 11:33:51) [POST]
  Parameters: {"commit"=>"submit", "authenticity_token"=>"qUBkNAAEB7EM4SGQRnlM+uaKlqmVM09+8l4sCFhPvBw=", "import_order"=>{"number"=>"5000"}}
Redirected to http://adomain.com:3000/admin/import
Completed in 6026460ms | 302 Found [http://adomain.com/admin/do_import]

Er, obviously this is not Rails’ fault. It’s an import script processing large numbers of records, and it blocks while it’s doing so. I really should farm it out to a worker daemon, but it’s just a one-off thing as I set up a new site, so I can’t be bothered going to all the trouble for something that will only be used once.

But I am quite proud of that number – almost 2 hours for a single request. Lucky Mongrel doesn’t time out requests, unlike, say, Passenger.

UPDATE: another one

Completed in 7922222ms | 302 Found [http://adomain.com/admin/do_import]

Remember Zed Shaw’s “Rails is a Ghetto”? All about how the Rails community is being taken over by boring, pretentious, corporate wanna-be suits with their prattle about “professionalism”, pretentious posturing, MBA peacocking and assorted other behaviours unwanted in the dynamic and creative Ruby community.

Well, these MSCE-having douchebags are out in full force today. You see, there was this little Ruby conference in San Fran, and a presenter there had the temerity to include – wait for it – references to porn in his talk. Plus some pictures of scantily clad girls.

OH NOES

Now, I thought the talk was fine, and very well made. The content may have been slightly risqué, in a US context anyway, but no big deal. Actually I appreciate the creativity – there’s nothing more boring than yet another “professional” presentation. I use Ruby because I hate acting “professional”.

But oh boy, the reaction.

Some commentors were frankly laughable – one woman in particular went so far to claim the presentation made her fear for her safety, as if the entire body of men in the audience were in danger of rising as one and assaulting her in some kind of insane porn-fueled gang rape:

To most of these men around me, I am, at best, an oddity, and at worst, a sexual target. I feel a little less safe.

I suggest this poor woman seek therapy for these delusions.

Other reactions include pathetic “I am being victimised” attention-seeking, lame attempts at demonstrating how much “I truly care about women” etc, hilarious “I am leaving the Ruby community and re-installing Visual Studio” threats (please do!), and every combination thereof. I cannot help but think that if Matt’s presentation has the effect of getting rid of these disingenuous wowsers then he should henceforth be invited, nay required, to present at every Rails conference.

Comments from the SlideShare page from sad Java programmers:

I’ve talked with two large IT shops who’ve said that there is no way they’ll ever let Ruby in their companies because of this horse shit.

Lol, good. The less “large IT shops” pissing in the Ruby pond the better. And if their management is so stupid as to choose technology because of “some presentation given by some guy at some conference” then no doubt they’ll be out of business soon anyway.

I think Matt just blew the image of the Ruby community by doing something like this.

WTF? Who even thinks like this? Whatever, I am glad they do:

I’ll avoid joining the Ruby/Rails community at all. So will many other engineers, given the remarkable and continual display of unprofessionalism from you, the community, and even its leaders

Uh, OK. Door’s that way. By the way, you’re not a real engineer, did you know?

Is this the ruby community , sexist and racist? I am going back to .net and FU all!

Lol, enjoy! Wait, racist?

And so on and so on. Pretty funny. Thanks for the GC patch, Matt, it’s proving very effective.

About the only person whose reaction to this I truly admire is . And he is the father of Rails, so if he doesn’t mind it, then all these “this is inappropriate for a professional conference blah blah” business-card-offering synergystic-opportunity-seeking suit-wearing jerks can go jump off a cliff, IMO.

This is what I hate about Rails:

1. New feature added to Rails 2.3.0RC1 allowing simple localisation by template naming convention – ie, if locale is set to :ja and an index.ja.html.erb file is present, that gets rendered in preference to any other index files. Cool!
2. New feature doesn’t work properly and exhibits an insidious bug where it manages to set a wrong Content-type in the HTTP headers, causing all sorts of nasty, hard-to-troubleshoot problems
3. Problem is reported
4. Rails Core replies “wontfix”

The “fix” Josh suggests, needless to say, doesn’t fix anything.

That is utter bullshit. A major new feature of Rails 2.3.0, as reported in Ruby Inside and the Riding Rails blog itself, doesn’t work. Has no-one else tried it? Has anyone used this at all? Are me and the other commenters on this ticket the only 3 people in the world who ever tried to use this feature?

There is no fucking excuse in the world for Rails to silently be sending a wrong Content-Type, no matter what.

I’d been blissfully ignorant of Gregg “I don’t have enough G’s in my name” Pollack’s latest yawn-cast until the inimitable Wincent Colaiuta brought it to my attention. I’ve been unimpressed in the past by Mr Pollack’s shaky grasp of what he’s talking about, not to mention his nasty money-grubbing antics surrounding RubyConf 2008. However, I am but a (highly immature) man, and so similarly tantalised by the promise of a “rant”, I grabbed episode 5 and gave it a look.

My first thought is that Mr Pollack doesn’t really know what the phrase “scaling rails” means – no surprises there, since he didn’t know what “scaling ruby” meant either – ie. nothing, since you can’t “scale” a god damn language. He seems to be confusing it with performance and responsiveness – desirable attributes for sure, but not what I understand “scaling” to mean. The first few episodes do not even mention scaling, focussing on client-side perception of page load speed. Indeed, his first mention of “scaling” in the “Scaling Rails” series is this:

Before you attempt to Scale your Rails application, you need to know where and how to scale it.

Surely an insight for the ages there. I would write that down right now, if I could figure out what the hell it is supposed to mean. Apparently in Gregg’s world, “scaling” is something you do on a lark, just for fun, maybe on a rainy day or if you’re just plain bored. Hm, I don’t have anything much to do today – I think I might scale my websites! Before I attempt that though, I’d better learn up on where and how to scale them. Take it away Gregg!

Unfortunately, Gregg isn’t interested in, or aware of, any “how” that isn’t “caching” and any “where” which isn’t “uh, in the bits which will be cached”. Every single episode of the series so far focuses on caching strategies. Again, HTML caching is a useful and important tool to improve performance and efficiency but that’s merely one variable in the scaling equation. It’s a “vertical” optimisation, not a horizontal strategy, which is what my conception of the art of scaling is all about.

However, even Pollack’s advice on HTML caching leaves a lot to be desired. As Wincent points out:

Next up, he shows how you can include dynamic content on a statically cached paged. This is where he goes off the rails. His recommendation is that you use an AJAX callback to pull down the dynamic data. So let me get this straight: you’re caching the page to avoid hitting the Rails stack, but then you do a request that does exactly that (hits the Rails stack) to fill in the dynamic content…

It’s important to note that there’s nothing wrong with this technique per se. If a page is very expensive to generate, but just needs one little piece of dynamic content, this kind of thing can be very useful.

However, I think Pollack is barking up the wrong tree with the use he’s considering – a dynamic log in/log out link. His suggestion as written is to use AJAX to write in the login status, on every page in the site regardless of whether it’s cached or not. In fact, as written, if the page doesn’t get cached, the login status will be written twice! Not to mention that he’s forcing users to pull down the entire Prototype JS library just to implement this one little thing.

I suspect Mr Pollack is really just speaking about his own experiences here. His sites tend to be very content-heavy, very static, and it’s fairly obvious by looking at, say, EnvyCasts, that his experiences there have informed the strategies he passes on in the screencast. However, I would submit that his site is actually a fairly niche example. It’s a highly cacheable, rarely-changing site which indeed only really requires a single little bit of dynamic content – the login.

Which brings me to my main dispute with Pollack’s screencast. No, login status is not overrated. It’s highly useful to be able to check at a glance if you’re logged in to a site – especially with many sites’ less than perfect autologin functionality. It’s equally useful to be able to log out with a single click, especially if you have multiple accounts on a site. Forcing your users to click through a “my account” page – which may or may not even take you to your account, if you’re not logged in, that is if you have an account at all – is just lazy.

Especially since, as Wincent points out, it’s trivial to simply implement the login status client-side, using cookies and a bit of javascript:

I for one really appreciate the visual feedback that shows me whether I’m logged in or not; and given that implementing it is basically zero-cost using the method I’ve just described, I don’t see any reason why not to.

Indeed not.

The rest of the screencast is more of what we’ve come to expect from Mr Pollack & co. – a superficial treatment of things you probably already knew, or could easily find out. If you’re such a beginner that you don’t know anything about page caching, I recommend heading over to railscasts, starting from the beginning, and then just watching them all.

This video might be of some interest as a kind of summary, if you can sit through it – not only do you get to stare at Mr Pollack’s annoying face the whole time, the sound is totally out of sync, making it even more annoying. Pollack has an irritating habit of favouring the camera with a “knowing look” whenever he imagines he is making a particularly profound revelation, which is sure to have you searching frantically for the “press here to electrocute presenter” button:

One way we can do it, is by adding an … AJAX callback (long, tension-filled pause)

At least, though, Mr. Pollack has finally settled on the right price for his screencasts.

PS. As an aside, I thought the name of the company sponsoring Pollack’s latest effort, New Relic, was kind of ironic. A third party website trying to charge money for app monitoring? That does seem like a relic of a bygone age. And the service does seem to be new, hence a New Relic. I wonder if that was intentional. The name certainly makes no fucking sense at all elsewise. UPDATE: Their service actually does look pretty good. Good luck to them. Still a ridiculous name but hell, what isn’t.