kmt's comments

I think it's much healthier to work in maintenance mode. Your mind is singly pointed almost meditatively. My personal favorite is troubleshooting. I'm always happy when someone comes to me with an urgent problem. It's such a joy to jump on it and help! Compared to that the process of new design and development is painful.

I think I might be that bg guy. :) Will be delighted to catch up; email me if interested (I'm around).

How good is the pay? Can you give some examples?

Don't forget that this guy (still) works alone. He only needs a small niche, he doesn't need to beat Google at all. His users don't even have to be loyal; they could just be (temporarily) frustrated.

Agree that hypocrisy is a strong word for something that's just a how-to.

Anyway, my point was that his recommendations are not worth much.

And what about the hypocrisy of "don't have kids" combined with his "support my growing family" footer?

Incidentally, for those interested in photography I wouldn't take this guy's photo advise either. The guy lacks depth in understanding and sometimes makes statements that are just ridiculous.

Exactly. I'm surprised to see many people here saying that the responder was unhelpful or rude. I think that the answer was not only fascinating but also responsible, pedagogical and, in a way, even compassionate.

Not all of them need labels. For example: Google Acquires the Internal Revenue Service.

This is all recreational. But it sometimes also gives you perspective. Makes you think in a different way. That can't be bad.

Besides, those who are really bothered by the jokes and are that dependent on HN that they cannot live without it for a day seem to have a different problem.

It likely has a dependency on HN: looking up users, karma, etc., which is just simpler to do on the same machine.

I'm quoting the last paragraph which is a summary:

"The best you can hope for in this life is that your delusions are benign and your compulsions have utility."

In my mind, the whole post is very much worth reading. "This life" is basically here and now since times and societies change.

Reminds me of how back in the day I chose to do software although I had other talents and passions as well. It was not an easy choice but here I am now.

And all of the above presumably helped him to co-found a successful (in a make-something-people-want sense) startup. Not too bad after all, eh?

What if you have to serve both interactive users and automatic clients? Would you use the url structure for both or would you have a separate api structure?

I agree with that. But here you aren't talking about HTTP you are talking about RPC. You could have gone with RPC directly from the very beginning. Typically, you put that on top of HTTP to avoid firewalls, etc.

I said simple as possible, but the real world is always complex and one day you may have to use something other than JSON-RPC in which case someone will have to create an adapter or an abstraction. Thankfully this is easy to do in software even if it sometimes looks nightmarish.

I think you might be wrong about the 'underlying protocol'. HTTP is an application layer protocol. If something feels dirty it is to put another protocol on top of it especially if it doesn't add value.

With REST, you are not adding more special meaning than the HTTP methods. Using those methods according to the spec is all there is to it. If that's enough to do your business, why add more to it? Things should be simple as much as possible.

Is the well known and used cookie based authentication in conflict with REST? In my mind it's not, it's orthogonal to it.

If not logged in, redirect to a login page (resource) which upon success redirects back, e.g. GET login?next=desired_resource.

If logged in but not authorized to perform the action on the resource return 401.

That's it basically, isn't it? Also not trolling, challenge me if I'm missing something please.

You could always install a recent version of Emacs yourself even if you're not an admin, can't you? Also, don't forget the options for remote editing.

My take on "sessions are irrelevant" is that you don't start and close a session. You start by creating a resource: itenerary, document, submission or whatever you call it. You do that by POST-ing to the list of such resources and you edit it (PUT) until you're done. You could always come back to it (GET) and edit some more (PUT). Or you could delete it (DELETE).

Of course, there can be authentication and authorization but, really, there's no need for a session since you have to do those two on each http request anyway.

I've used FastMail for about 8 years now. It's an extremely solid service. They just do one thing and that's email. No spam issues.

I think you got two good answers. They aren't even conflicting, just presenting the two sides of the coin.

And how about node.js on rails? Anyone working on it? Maybe with MongoDB backend? It looks like a convenient fit to me.