Live data from Hacker News

Objectify: A Better Way to Build Rails Applications

jamesgolick.com

51–60 of 72 posts

Re: Objectify: A Better Way to Build Rails Applications

#51

Can't say I'm a fan of single-method classes. They always make me ask "why isn't this just a method?"

The reason I don't like adding extra methods to classes is because by doing so you often end up adding an extra layer of dynamic dispatching. If I have that functionality in a static function when I read it I know that it can only do one thing but if I see a method call I have to always wonder if its going to be polymorphic.

Re: Objectify: A Better Way to Build Rails Applications

#52
post #22

Someone 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.

judofyr is about as credible about Ruby as they come.

Re: Objectify: A Better Way to Build Rails Applications

#53

Earlier quoted context omitted.

When you start a comment off with a sentence like that, you lose all credibility.

judofyr is about as credible about Ruby as they come.

If that's the case, why does he need to start a discussion with that kind of statement?

Re: Objectify: A Better Way to Build Rails Applications

#54
post #2

FWIW 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'.

Re: Objectify: A Better Way to Build Rails Applications

#55
Objectify is a nice framework, but after reading the examples in README made me feel like I am required to take extra iterations: create new responder files, write more codes for each Responder class, etc. This approach is little tedious.

I 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

#56
post #49

I 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…

hey man, re:

"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

#57
post #2

FWIW 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'.

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.

Re: Objectify: A Better Way to Build Rails Applications

#58
post #41

Earlier 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 find utilising the Feedback Sandwich Technique, with some authentic positive encouragement, usually works well.

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

#59

Earlier 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.

It will certainly cause confusion. This is just decidedly uncool.

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

#60

Earlier 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?

Good point. There are friendlier (better?) ways to discuss flaws.
Post reply on HN