bct

This is what I actually believe.

Your expectations are odd. Large, loosely-knit communities don't (and can't) decide things in the way that you're suggesting.

Regardless of what "should" happen, we're just going to continue muddling around. It's worked out OK so far.

Linux users are not a monolithic group that all simultaneously want mainstream success and exclusivity. There's plenty of room for both approaches.

Most of that difference in life expectancy is due to lowered infant mortality, they weren't copyrighting anything anyhow.

Hmmm, interesting. Here's a concrete example:

I've got an 'Organization' model and a 'Person' model. I want to use them interchangeably in some templates, so I need to be able to get their names in a consistent way.

An Organization just has a 'name', but a Person has a 'first_name' and a 'last_name'. I've been using a 'displayName' method to encapsulate the difference; would it make more sense to do something like:

    var Person = Backbone.Model.extend({
      initialize: function() {
        var name = this.get('first_name') + ' ' + this.get('last_name');
        this.set({ name: name }, { silent: true });
      }
    });

I'll try to think of examples and come back to it tomorrow.

For now: One thing that I'm still not clear on is when to wrap .get/.set.

Should I always write my own getters/setters and only use .get/.set internally? Right now I'm only wrapping them when the attributes need special processing, which leads to an inconsistent-feeling API.

"Lack of guidance" is the way I'd describe it. The documentation is great, but it didn't help to steer me away from making architectural decisions that don't work well with Backbone when I was doing my first experiments.

Those are some pretty wild assumptions you've got there.

Men's issues are feminist issues, and are best advanced by working with and as feminists.

> It implies that just by being a men one is in a more powerful and advantageous position.

All other things being equal, yes, a man is in a more powerful and advantageous position.

Obviously there are lots of individual women who are more powerful than individual men, and there are classes of women who are more powerful than other classes of men, but in general there are many advantages that men have that women do not. These advantages are a direct result of broad societal structures and cultural norms.

Yes, there are advantages that, in general, women have and men do not, but when you look at them they are almost always the result of sexist, patriarchal norms - e.g. the ideas that men are strong so they should never show weakness, strength is best displayed through through dominance, women are fragile and need men to take care of them, women are naturally better with children, etc. These problems are all tied up with each other.

> down-vote the heretic

> "forbidden thought"

> I don't care about "thought crimes".

Bad news: you're not the brave thinker that you seem to think you are (in fact your "forbidden thought" is probably more common than the alternative that we're presenting!).

People aren't disagreeing with you because they think it's morally wrong to think the way you do, they disagree because they think you're wrong.

Please note my parenthetical.

keymone said: "overdramafication because of overbitchiness? boring.."

Quoted for posterity.

The difference is the societal context. Women are judged by and valued for their appearance (to the exclusion of other attributes) to an extent that men are not.

"Do women also find the fact that only women actors are used in cleaning commercials "fucking gross"?"

It's not gross in the same way, but yeah, that is a great example of sexism!

"They're paid for it, there is nothing illegal about it"

Ah, Hacker News, where all ethical questions boil down to "were they paid?" and "is it illegal?".

> (E.g. I can't see a client going "oh!, there's a new business function I haven't seen yet, let me invoke that!".)

Of course not, nobody thinks that. That notion does not exist.

> With the rels/links, you're just moving the coupling away explicit URLs to the names/identities of rels/links in the response.

I suppose, but that's a much looser coupling than the alternative (i.e. writing in the documentation "the comments URL is http://example.com/comments - you can't rearrange your URL structure, you can't start using a different domain (e.g. a CDN) for comments, existing clients can't use other sites that implement the same API, etc).

HATEOAS is about building general protocols rather than site-specific APIs. That it makes it easier to change your own URLs is just a bonus.

The trick is to build ugly systems that are able to grow into beautiful ones.

I don't understand the distinction you're making between "trivially" and "non-trivially". Looking at pretty much any commercial CMS you can see that publishing documents can involve all kinds of business logic.

Of course we have to be pragmatic about these things - if you have a business that will live or die based on the success or failure of its API then you have to make your decision based on that - but there are times that it makes sense to push the boundaries of what developers are comfortable with, yes? Otherwise how do we expect things to progress?

You examine the situation and determine what makes the most sense. Do you want the client to repeat the request if it's not sure whether it succeeded or not? If so, use PUT; otherwise use POST.

This isn't complicated stuff.

I don't think there's anything particularly unRESTful about using non-URL ids in that case. The critical thing is that the client isn't using out-of-band knowledge (i.e. what the developer read in the API documentation and hardcoded into the client) to construct the query.

What's often left out is the reason that that's a useful rule to have: if PUTs are always idempotent, then you can always safely repeat a PUT if you're not sure whether it succeeded or not. This makes it easier to build robust systems.

> commonly held up as exemplary REST

Not by people who know what they're talking about.

> This makes so much more sense because then you can use ?command= and have any command you want and not have people confused about what it means.

That's textbook RPC. It's a pattern that works well for many things, but it's definitely not REST.

No. It is incorrect to use tables used for layout, and this widespread practice has made it impossible for user agents to treat tables specially.

A div exists to have no meaning. Using it for layout doesn't hurt anything except page size (unless there was a more specific element that you could have used accurately instead).

I don't understand how we're in the year 2012 and people are still repeating these "rules" without any understanding of why they might matter.

I had the same problem, for some reason

    get '/:short_code' do
    end

got inserted at the end of the textarea.

> Then I will. It's a conspiracy theory, worthy of all the mocking typically associated with such a thing.

When we're talking about a company what's the difference between a "conspiracy" and a "plan" or "strategy"? (Serious question.)

Maybe we don't need stuff like Avatar.

Hacker News was originally called Startup News; that would still be a more accurate title.