On The Day's Events
Posted by kev Thu, 31 Aug 2006 01:25:00 GMT
So, I seem to have inadvertently caused a significant amount of controversy with this morning’s article on what I don’t think you should be doing in Rails. Some rather harsh words have been exchanged. It’s time for us all to take a breath, count to ten, and remember we’re all just coders working together to make Rails (and Ruby) better.
Matz is nice, so we should be nice.
With that as a preface I’d like to explain some of the things I said which caused a stir. Hopefully this will clarify and you can stop thinking of me as some pre-pubescent FUDdy jerk if indeed that’s where you stand.
I thought I was giving you a list of things that you should avoid in modern versions of Rails. I didn’t get anything back differently from my reviewers. You should know that for bigger articles like this I always have a group of people take a look see first and give me feedback. These are people that I respect and may be better at writing and programming than I am (and often are). I wait to get OKs from that group before I post.
I think this group of lines may have been my downfall.
See? A halt! Sufficiently frightened? You should be. Now, stop using these things. It’s for your own good.
I rather regret this. In my head it was tongue-in-cheek. My reviewers didn’t even mention it though I imagine they knew I was joking since they know me personally. Others apparently didn’t. What I meant to say was that I hope the list would coerce you into improving your code. That message got lost somewhere along the line and I feel like we’ve played a rather large game of telephone. I’m sorry for that.
Pagination seems to be the issue we pulled apart today so let’s talk about that for a few minutes. I said some things about pagination that, after returning to them, seem a bit cryptic. Sorry about that. Let me clarify: the built in pagination helpers are a hackish pain. They’re hard to work with and have some efficiency issues. As a result, working with very large data sets can cause it problems. Don’t be afraid, just be aware. With large data sets you’ll want to roll your own. The Paginator object itself isn’t so bad (though we really should clean it up) and I prefer to use custom pagination with it over the helpers.
That being said, we’ve talked about pulling out the Rails pagination helpers into a plugin for a while. I imagine they were brought up when I passed the article around was for that reason. It isn’t deprecated yet, but it probably will be.
Now, if you have other concerns please bring them up here.
Update: A friend has noted that one of the problems may be that some look at me as a voice of the core. Let me be clear: I’m not in core. I don’t speak for core. I speak for myself based on my knowledge and opinions. When I say, “we’ve talked about it” I mean “I’ve talked with developers working with the core in and outside the core team and the consensus seems to be that pagination will come out”. BUT, I’m still not David and not the core.
1…2…3… :P
What’s so painful about doing? If by rolling your own you mean the example in Rails’ docs of explicitly creating a paginator object and so on—no thanks, that’s more verbose.One place where pagination does totally leave you on your own and reveals its incompleteness is trying to paginate associations.
Joe:
I think he’s referring to the implementation, not the interface.
Wow, you’ve really kicked up a storm here, eh? It’s amazing how just a few points cause such a stir ;)
“What I meant to say was that I hope the list would coerce you into improving your code.”
And that’s exactly what it will do. As with all problems, there’s a whole host of solutions. Some may work better than others, some may be more fragile, some may be more stable and it’s our job as developers to question what we do and find better ways to achieve it, not just do “what the book says”.
I’ve never run into problems with pagination, but that’s not to say it’s not there and I wouldn’t argue anyway, using my experience. I’ll keep using the pagination helpers. But I know, every time I do, I will think of this. Which is a good thing :)
Although I may not agree with every point, It’s certainly an interesting read and certainly makes some good points which I will learn from.
Well said Kevin.
I’m glad this conversation is coming up; it is good to talk about. Kevin, besides pagination, people were getting rilled up about RoRs somewhat slim documentation, pace of refinements, changes, etc. Let me throw out a warning about this debate:
lets be careful for what we wish for.
I’ll use java as an example:
1) Java is terribly bloated. Things are depreciated but never removed. The api is a disaster (anyone remember CORBA and why is it still in the jdk?). I’m so glad that the rails core team plans to eventually pull out depreciated code. Yes!! Down with bloat!
2) Who has tried to learn java recently? There is no one place to go for tips, hints, coding styles. There are dozens of starter books, most of which put an emphases on ease of use over being truly OO, efficient, or maintainable. There were some great ideas in the comments about how to standardize RoR information, but lets not get riled up because there isn’t one unified coding methodology for rails.
3) Many of us left the java world precisely because their was minimal innovation after a 1.0 release of a framework. Multiple java frameworks pop up every year but then slowly fade away for lack of a forward vision. It is so frustrating to see! Let the RoR framework evolve so we don’t have stale technology in 18 months.
Oh woops! I used up my $0.02 cents awhile ago. :D
Adam
Pagination killed my father.
He was 3 days until retirement.
This time… it’s personal
I posted this on Alex’s blog, but this would obviously be a good place for it as well. I’m just gonna c/p it :)
I thought his article was interesting. Interesting in the kind of way that left me scratching my head.
Kevin apparently intended to inform people of problems they’ll run into while using Rails. Instead, it’s simply a list of common-sense programming principles mixed with shortcomings in Rails itself.
“Don’t use instance variables you didn’t create.” “Don’t get ahead of yourself.” “Scaffolding isn’t for production.”
Is there a single real programmer who doesn’t respond to those comments with “duh?”
The remaining items on the list are warnings…but it looks to me like they’re really just bug reports.
Components are crappy. Fix them, don’t avoid them. Engines could break. Stop being stupid – provide a plugin architecture that allows for views as well. Pagination is crappy. Fix it.
The Rails-specific warnings shouldn’t be warnings at all, but rather calls to action. It’s not like components, engines, and pagination are incredibly complex mechanisms that should be avoided because nobody will ever figure them out.
I posted some musings and analysis of tone at Bob Silva’s blog. Your article was a good one, but I think it was the delivery that was more controversial than the content itself.
FWIW it was an excellent post, which helped give a shape to the one real problem brought about by the sheer speed of development of Rails – exhilaration fatigue.
I think your friend’s assessment about ‘voice of the core’ is apt, but you wouldn’t be the only person who is viewed in that state of confusion. There are a lot of people making names for themselves dispensing their knowledge of Ruby or Rails, and the collective tone is one of friendly authority, perhaps acquired by imitation of the core team. The canonical example is the phrase: “you are writing your tests, aren’t you?”
The problem is one of trust. An average blog reader does not know who speaks from a position of influence and who does not. It’ll settle down over time, as many of the minor rockstar coders step back from the mic, and as those who stay develop their reputations.
In the meantime it is hard to know who is really worth watching. Perhaps a “Railsington Post” approach, where certain people blogged from under a collective reputation, would help a little with clarity of message.
That said, long may you be at the mic.
Sometimes I think everybody needs to relax. I thought it was a great article and appreciated it. Keep it coming.
i thought it was a great article. i’m surprised it kicked up a storm ! to me it was obviously toungue in cheek. perhaps you should consider moving to england
(hmm perhaps i should have put that last comment in a tag)
Uh, wasn’t it clear to everyone that you were just tossing out a mix of observations in a fun, entertaining, “here are some things that get under my skin” kind of way?
Guess not.
Anyway, I enjoyed it.
Michael Houghton wrote:
The problem is one of trust. An average blog reader does not know who speaks from a position of influence and who does not. It’ll settle down over time, as many of the minor rockstar coders step back from the mic, and as those who stay develop their reputations.This is how things work in the enterprise world, but not on the web. On the web, you are judged by the merit of your material, not by the enterpise or the cult group you belong to.
The personality obsession that is being displayed in the cultish corners of blogosphere is a sad fact. Better to focus on the quality of the published material than fall for the gossip, don’t you think?
For example, I like Paul Graham, and I read everything he publishes, but I find a lot of his ideas to be ridiculously flaky. The guy just wasn’t lucky when god was administering intellectual rigor.
But just because he is a prominent author doesn’t mean we should be taking his every essay as gospel.
Thanks for the clarifacation on pagination comment. What you’re talking about is paginate helper method and NOT the Paginator object. However, I’m still stratching my head over “They’re hard to work with and have some efficiency issues.” I think I understand the first part. What I’m unclear on is what are the inefficiency that cause paginate method to not scale that using the Paginator object will correct? The paginate helper doesn’t do a lot more than what I would do by writing it myself.
The only thing I can think that would not scale is how you have call the database twice. First count all possible rows for some query, then query limiting that result set to a few. If that’s not it then what specifically is the problem?
Thanks for the post Kevin. I didn’t find the original post too “high horse” as some did. I’m sorry you had to expierence the sting of a blacklash on good intentions. But, I think your expierence will benefit the Rails community as an example. If there is anything the Rails community can learn from this is that making judgements about people’s practices, even in jest, tend to force the conversation to be about the judgements and not the factual information you were trying to convey. Don’t let it bother you, and keep the information flowing man.
It would be really great if Kevin could post some code to illustrate the pagination issues and perhaps possible solutions.
Hey Kevin, I wasn’t particularly put off by your post, and I think the idea of a “don’t do this” list is a good one. When the wiki gets back in shape, there’s a fine place already made at http://wiki.rubyonrails.com/rails/pages/Deprecated+Patterns .It wouldn’t necessarily be the best place for talking about paginators, but it would be nice to have the page up to date. I wrote up several of the items you mentioned but I can’t get my lovely words to take. Maybe it’s auto-detecting my complete lack of writing ability.
Hey, I didn’t have a single problem with what you wrote initially, and I appreciated that somebody was writing about all the troubled parts of Rails in one spot. Thank you for that.
Kevin Clark: You’re right! I don’t like it and I should do something about the state of poor documentation, but what? Who do I talk too? You’re not core (sorry I thought you were, I take back my harsh tone towards you) and of the core group, who’s responsible for documentation? I will contact that person and sign up for Docs duty!
Authenticity.
Who’s in the core and who should we listen to for which aspects of Rails?
Wog, No one is in charge of documentation. I’ve been trying to push people to improve it for the last few months and made some significant improvements myself (some of which were backported to the 1.1.6 release).
I wrote an article on how you can help improve the documentation a while ago. You can find it here:
http://glu.ttono.us/articles/2006/05/10/documenting-rails
Wow, I read your list before it all kicked off and thought it was a sensible and well-informed post, written with an obviously sometimes-tounge-in-cheek tone. I never thought it’d cause such a stir. Just goes to show.
fwiw, I think you did a good job of pointing out some of the more obvious don’t-do-that-anymore things and helping to start conversations about how to make Rails better.
If you’re looking for an alternative to the Rails’ pagination helpers, check out my paginating_find plugin. It enhances the standard ActiveRecord::Base#find and is super easy to use for UI paging and also for transparently paging large enumerations for operations like exporting model instances to a file.
http://cardboardrocket.com/2006/09/01/replacing-the-rails-paginator/
Look, here’s my situation. I’m an amateur coder. I’ve written a few Rails applications that are very useful to the people in my small office. It’s helped us out a lot. Most recently, I wrote a small application for my wife’s work as well. They love it. I love it. I’m stretching out, learning and doing new things with each new project. I’m writing better code each time.
I came across your original post on Digg. I read it, and I thought it was very valuable. It contained a lot of information I wasn’t aware of. I bookmarked it. I plan to refer to it when I write my next app.
Now, did the tone of your article scare me off of Rails forever? No, it didn’t, because as it so happens I’m an adult, not a kindergartner with an ouchie. I don’t expect the Rails community to hold my hand and talk to me in soothing tones.
Prose is my business - my real work - and for what it’s worth, yours seemed fun and memorable. It seemed honest. I enjoyed it.
Your critic, who fears that you will single-handedly destroy all the things “he” is working for, likened your style to that of a “shooting-from-hip cowboy.” Now, class, can you think of anyone else in the Rails world whose style would fit that description? (Hint: His initials are “DHH,” and you’ve probably enjoyed his snappy zingers.)
My vote? Please, Rails community, resist all attempts to impose a uniform writing style on your advocates. You’ll end up sounding boring. That’ll kill your momentum for sure.
I for one am glad you wrote the article! It inspired to clean up some of my code and even though I’m a big fan of components (and rather dislike the alternative of using a before_filter and partials), I’ll still be moving away from them which will ease the headaches of upgrading. So thanks again!
WHAT INEFFICIENCY ISSUES?!
Don’t talk down to us. No, I don’t have time to read every Rails-related blog whilst grepping freenode#rubyonrails for anything interesting. No, that doesn’t make me a moron.
Are you talking about the fact that pagination_link_each instantiates a Page object for every little number link (“1 2 … 4 5 6 … 9 10”), and that instantiation in Ruby is kinda slow? If so, just say it, damn it!
If it’s something else, tell us! I’m not incapable of opening up the Rails source, but mysterious commentaries like this seem purposed only to separate the Knows from the Know Nots and piss me off.
Err… sorry for the tone in my last comment, but I’m, like, the eighteenth person to ask that question… so I’m not that sorry. :P
In other news, I did appreciate the intent of the article. The one about AJAX is a peeve of mine, too.
(While I’m here…) I’m another of the opinion that components and engines are not bad, just broken. For a whole class of problems that need DRYing, partials suck. (What, put model calls in the view?) For anything that might ever be updated, generators suck. (Notice how, pre-1.0, the core worked really hard to streamline as much of the generated rails skeleton as possible.) Heck, your blog engine uses components for its sidebar.
As someone who’s been reading about Rails for a while but is only jsut turning his attention to trying it out I thought the original article was a brilliant resource and I think I interpreted it in the tone that I was supposed to.
The documentation I’ll b eusing will inevitably be different ages and therefore a single palce to find the most commonly used programming styles that have been depricated shoul be very useful.
Thanks!
“Now, did the tone of your article scare me off of Rails forever? No, it didn’t, because as it so happens I’m an adult, not a kindergartner with an ouchie. I don’t expect the Rails community to hold my hand and talk to me in soothing tones.”
According to your own admonition, you’re an amateur coder. Meaning, you’re not in a position to decide whether to ditch your byzantine, 2 million dollar investment in some mainstream technological infrastructure in order to embrace the new kid on the block (i.e. Rails). I’m talking about these scenarios, and believe me, people in these positions are very easily scared.
If you, as an amateur coder, make a blunder while messing with Rails, your head is not going to roll.
Alex said: According to your own admonition, you’re an amateur coder. Meaning, you’re not in a position to decide whether to ditch your byzantine, 2 million dollar investment in some mainstream technological infrastructure in order to embrace the new kid on the block (i.e. Rails).
Fear and PR don’t change that fact.
Hey Kevin,
I thought you were pretty spot-on with the original article. I came back today so I could forward the URL to some folks. Thanks for writing these up.
Pagination, as a concept is often just annoying. I find that I take it out of production apps more than I add it in.
IMHO, those of us that have a number of production sites realize that a lot of the cool Rails bits really just get in the way.
What bothers me is that this advice is coming from a third party. Why isn’t the Rails core doing a better job at conveying this information? I think the documentation void left by core is not helping.
It’s the countless books, articles and blogs that are perpetuating the misinformation. Everyone is hyping Rails with outdated information, but it’s this hype that is putting Rails on the map. So it’s good and bad at the same time.
Still, any article intended to set the record straight about new ways of doing Rails needs to strike a balance in regards to tone and empathy with the old and the new. Hopefully, also, it should be done with the blessings of the core group.