Do not meddle in the affairs of Wizards#

Sat, 07 Aug 2010 17:50:20 +0000

From github

A less resource-heavy way to do realistic regression tests (and eventually load tests) than controlling an actual web browser a la watir.

• Interact with your web site using Firefox.
• Capture the requests sent with Tamper Data, and export as XML
• Replay them from the command line
  • with realistic timing
  • with SSL support
  • with a 'rewrite' step that lets you programmatically change the request data before sending it (e.g. to switch hostnames from production to test, or vice versa)
  • using the single-threaded low-overhead goodness of EventMachine

For an event this autumn that I'm probably not allowed to tell you about, $WORK needs a web site that deals with 50x as many transactions as the current box. Current plan is to move it into the cloud and add memcached for everything that might conceivably benefit, but step one in performance tuning is, of course, to get a baseline.

And it's an excuse to learn EventMachine

RESTless spirits#

Mon, 23 Aug 2010 21:04:19 +0000

From stackoverflow.com

I have read up many articles on Rest, and coded up several rails apps that makes use of Restful resources. However, I never really felt like I fully understood what it is, and what is the difference between Restful and not-restful. I also have a hard time explaining to people why/when they should use it.

If there is someone who have found a very clear explanation for REST and circumstances on when/why/where to use it, (and when not to) it would benefit the world if you could put it up, thanks! =)

Content-Type: text/x-flamebait

I've been asking the same question lately, and my supposition is that half the problem with explaining why full-on REST is a good thing when defining an interface for machine-consumed data is that much of the time it isn't. OK, you'd need a really good reason to ignore the commonsense bits (URLs define resources, HTTP verbs define actions, etc etc) - I'm in no way suggesting we go back to the abomination that was SOAP. But doing HATEOAS in a way that is both Fielding-approved (no non-standard media types) and machine-friendly seems to offer diminishing returns: it's all very well using a standard media type to describe the valid transitions (if such a media type exists) but where the application is at all complicated your consumer's agent still needs to know which are the right transitions to make to achieve the desired goal (a ticket purchase, or whatever), and it can't do that unless your consumer (a human) tells it. And if he's required to build into his program the out-of-band knowledge that the path with linkrels createorder => addline => addpaymentinfo => confirm is the correct one, and reset_order is not the right path, then I don't see that it's so much more grievous a sin to make him teach his XML parser what to do with application/x.vnd.yourname.order.

I mean, obviously yes it's less work all round if there's a suitable standard format with libraries and whatnot that can be reused, but in the (probably more common) case that there isn't, your options according to Fielding-REST are (a) create a standard, or (b) to augment the client by downloading code to it. If you're merely looking to get the job done and not to change the world, option (c) "just make something up" probably looks quite tempting and I for one wouldn't blame you for taking it.