http://www.techi.com/2011/02/why-the-facebook-like-button-change-is-a-bait-and-switch/
Excuse the opinionated title of that link. The information is worth knowing.
Monday, February 28, 2011
Wednesday, February 23, 2011
Go: Race conditions
Race conditions should be impossible in Go. Am I wrong?
Here is a verbose article on the subject. I'm not sure I get the point of the author, but the comments are interesting.
Here is a verbose article on the subject. I'm not sure I get the point of the author, but the comments are interesting.
Tuesday, February 15, 2011
Ruby: Following HTTP redirects
I'll update this with my Ruby code later. For now, read this:
How to control your HTTP transactions in Go
You might want to read his previous post also, on using Go for an HTTP throttler to simulate a low-bandwidth connection.
How to control your HTTP transactions in Go
You might want to read his previous post also, on using Go for an HTTP throttler to simulate a low-bandwidth connection.
Monday, January 24, 2011
Friday, January 21, 2011
HTTP: safety and idempotency
This blogpost has lots of useful links and a good example.
A big part of RESTfulness is mapping CRUD (Create/Read/Update/Destroy) to GET/POST/PUT/DELETE without violating idempotency (repeatability) or safety (no side-effects).
As pointed out here, using GET unsafely does not break anything, but I think the author misses the point. GET safety is a convention, which makes it easier for the rest of us to understand Web APIs. It's similar to conventions about identifying side-effects in software. The trouble is that most software engineers do not recognize the cognitive penalty of side-effects, so they do not see any reason to illuminate them.
Also, note the difference between idempotency and referential transparency. Technically, we should say referentially transparent, rather than idempotent, since the result of a GET (or PUT or DELETE) cannot be applied to itself. To me, that's a less important distinction than the tenor of the rule. And here is a lucid defense of using idempotent in the context of the web.
See also this StackOverflow discussion, especially the link to Roy Fielding's comment on REST and Cookies.
A big part of RESTfulness is mapping CRUD (Create/Read/Update/Destroy) to GET/POST/PUT/DELETE without violating idempotency (repeatability) or safety (no side-effects).
As pointed out here, using GET unsafely does not break anything, but I think the author misses the point. GET safety is a convention, which makes it easier for the rest of us to understand Web APIs. It's similar to conventions about identifying side-effects in software. The trouble is that most software engineers do not recognize the cognitive penalty of side-effects, so they do not see any reason to illuminate them.
Also, note the difference between idempotency and referential transparency. Technically, we should say referentially transparent, rather than idempotent, since the result of a GET (or PUT or DELETE) cannot be applied to itself. To me, that's a less important distinction than the tenor of the rule. And here is a lucid defense of using idempotent in the context of the web.
See also this StackOverflow discussion, especially the link to Roy Fielding's comment on REST and Cookies.
Thursday, January 6, 2011
jQuery: WTF?
Unbelievable.
I definitely prefer Prototype. Still, jQuery is much better than ASP. (Fortunately, the folks at MS recognized this, and VS MVC has supported jQuery since 2008.)
I definitely prefer Prototype. Still, jQuery is much better than ASP. (Fortunately, the folks at MS recognized this, and VS MVC has supported jQuery since 2008.)
RoR: Nested routes
I learned something interesting enough that I want to keep a link to it. Unfortunately, I posted the answer a year after the question, so nobody will ever see it. Awwww.
Subscribe to:
Posts (Atom)