Can't say I'm a fan of single-method classes. They always make me ask "why isn't this just a method?"
Objectify: A Better Way to Build Rails Applications
51–60 of 72 posts
Re: Objectify: A Better Way to Build Rails Applications
#52Someone has to say it: Damn, this looks fucking ridiculous! First we have the false modularity. You see a bunch of separate stuff (classes, methods, whatever) and think "Wow, nice, now we can reuse this all over the place!" The truth is that these policies/services/renderers are going to be complected; you're going to create them in triplets as you implement your application. Moving things around doesn't make them mo…
When you start a comment off with a sentence like that, you lose all credibility.
Re: Objectify: A Better Way to Build Rails Applications
#53Re: Objectify: A Better Way to Build Rails Applications
#54FWIW there's already a library called Objectify that's a Java-based ORM (lite) for AppEngine: http://code.google.com/p/objectify-appengine/ If you want your project to be found easily (on search engines) I always suggest: 1. Prefer a made up word to a non-English word (or a word in any live language for that matter); and 2. Don't choose a name that something else in the same or similar space shares. They've been arou…
Re: Objectify: A Better Way to Build Rails Applications
#55I personally think that writing reusable libraries using Decorator/Presenter patterns or Modules with ActiveSupport::Concern is simple approach.
Avdi's slides: https://speakerdeck.com/u/avdi/p/making-little-classes-out-o...
I highly recommend Objects on Rails book: http://objectsonrails.com/
Re: Objectify: A Better Way to Build Rails Applications
#56I have a prejudicial assumption that if you don't know the problem Objectify solves, you haven't worked with a Rails app which has A) a large code base B) a large, active user base and C) a bunch of different features. The vast majority of people who scale Rails sites (as far as I can tell) do so by breaking their apps into services. ActiveRecord god-objects do not make that step in an app's life cycle easy, and sepa…
I worked in Rails for the last 6 years professionally, and for the last 4 years on a single application. There are lots of ways to tackle this problem, but it really depends what precisely you have inside those models and there are certainly no universal silver bullets. Lots of people who complain about this underuse Rails features, external plugins etc. I think two good ways to deal with the problem are: - Splitting…
"If you look at Rails itself (it's great Ruby code, I highly recommend really reading it)"
I've worked with a member of Rails core, and frequent committers. I've spoken at 10 Ruby conferences at least, maybe 20. I'm familiar with the Rails code base. I once rewrote a few small pieces of ActiveRecord from memory for a stupid project because my wifi was dead.
I agree about it being worth reading, I just want to slow you down there for a second. Otherwise we're going to end up pulling things out and measuring them. I took the time to check your links, although I'd seen most of them already. I'm familiar with concerns and although I think your links are germane I'd have to disagree with this part:
"Deciding what things would fit well into external modules and what modules to create is a new skill to be learned"
As I think I've learned the skill.
What I'm saying basically is that I think you missed the mark in terms of guessing my background but I believe it was an honest mistake.
Egos aside, I agree that modularity matters. And I must admit I had a painful reminder about that skill recently when I built something around ActiveRecord and then refactored ARec out of the picture for performance reasons (the gains were staggering). It would have been less painful with better modularity, but I don't think the pain relief from using concerns would have been particularly great in this instance. Non-zero, but insignificant.
I don't care that much about OOP theory, but the pragmatic issues Objectify addresses seem to come up for people all the time. A year ago Steve Klabnik and a few other people were talking about this and I noticed it then how it was echoing James Golick's (the OP) posts about limiting ActiveRecord's role from a few years before that.
There basically seem to me to be three trends in discussion of scaling Rails: 1) "Rails can't scale" FUD, 2) DHH saying "just add hardware and/or caching", and 3) this idea of decoupling persistence from modeling, basically, reining in ActiveRecord, which I've heard from people like James Golick, Steve Klabnik, Gary Bernhardt, and I think Xavier Shay. Paul Dix wrote a great book about making Rails apps service-oriented, the Thoughtbot guys touch on it in their antipatterns book as well, and it's not exactly a coincidence that for many Rails apps the only gem more crucial than ActiveRecord is Delayed Job or Resque.
Re: Objectify: A Better Way to Build Rails Applications
#57FWIW there's already a library called Objectify that's a Java-based ORM (lite) for AppEngine: http://code.google.com/p/objectify-appengine/ If you want your project to be found easily (on search engines) I always suggest: 1. Prefer a made up word to a non-English word (or a word in any live language for that matter); and 2. Don't choose a name that something else in the same or similar space shares. They've been arou…
Furthermore, it's the top Google hit for 'objectify'.
Likewise I disagree with the idea that these two projects share the same space. A Java ORM and a Rails metaframework for avoiding ORM are not things which have a lot in common. I think the last time I observed a Rails hacker saying anything about AppEngine was 2007 or something.
Re: Objectify: A Better Way to Build Rails Applications
#58Earlier quoted context omitted.
> You have to think a bit more about what OO really is about. If you want to have a respectful debate, I'm completely game. If you'd prefer to continue with your incredibly condescending tone, then I'll bow out here.
Well, maybe I got carried away a bit with the tone in general in the last paragraphs of both comments, but I think I substantiated the particular sentence you cited quite a bit. On the other hand, I also took half an hour to clearly explain to you why this is somewhat misguided and tried hard to be polite, while someone below just said "this is fucking ridiculous". It's hard, at least for me, to give constructive cri…
I apply it mostly when I'm writing something and am getting the feeling that it might not come across so well.
http://www.rightattitudes.com/2008/02/20/sandwich-feedback-t... (from a quick Google)
Re: Objectify: A Better Way to Build Rails Applications
#59Earlier quoted context omitted.
Furthermore, it's the top Google hit for 'objectify'.
Do you really think the OP had SEO as a priority? Likewise I disagree with the idea that these two projects share the same space. A Java ORM and a Rails metaframework for avoiding ORM are not things which have a lot in common. I think the last time I observed a Rails hacker saying anything about AppEngine was 2007 or something.
As the lead developer of the Objectify project, and someone who makes a living through consulting related to Objectify, I am highly annoyed. I'm also talking to a trademark attorney to find out my options.
Re: Objectify: A Better Way to Build Rails Applications
#60Earlier quoted context omitted.
I don't necessarily think so. He draws you in with said outrageous remark and proceeds to raise some good points.
It doesn't really invite discussion. If you were the original author of the blog post would you engage with the author of the comment?