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.
