We used this to automate UI tests on an iOS app a couple of years ago (before they added the UI automation stuff). Seemed to work pretty well, though it was a fair bit of work to get it set up.
I've been using it since the first alpha release back in December or whenever it was released and I can say that alpha absolutely fixes the one character at a time undo (and has since the first release).
Seems to have a minor glitch with unicode characters? When you do Colors.remove() everything goes away, but the entries with unicode all come back? Somewhat strange...
Interesting tech, but db access from the client scares me to no end, call me a curmudgeon I guess.
Performance on that url also seems to be super slow right now with a lot of people hitting it. Curious to see how Meteor handles loads, it's really exciting stuff.
I just did this about a month ago, and it couldn't be easier to get from London to Bletchley Park, it's literally right up the road from the Milton Keynes train station, maybe a two minute walk.
Getting to Down House (Darwin's House) from London, on the other hand, while totally worthwhile... what a hassle!
I just visited Bletchley Park last week. It was great to see, especially the Colossus MK2 reconstruction and the working rebuild of Turing's Bombe. The only thing that made me sad was the lack of discussion of the way the government treated Turing; it was glossed over on a sign next to the Turing statue, but other than that, not a word was said.
This is being rectified. There is a new Turing exhibit being planned and the official apology from Gordon Brown has been delivered to Bletchley Park and the people running Bletchley Park fully understand what's needed. I have been working with them on wording for the part talking about the apology.
I've written a library for internal use (that I'm waiting for work to agree to open source) that basically lets you bundle a group of asynchronous calls into a single callback. I prefer this method because it doesn't try and hide the asynchronous nature of the code, it just frees you up from having to nest your callbacks N deep when you require the output from all N asynchronous operations to continue. Wondering what others think about this? Do folks prefer the methods in this article that let you hide the asynchronous nature of some code?
It's been done. One of the best libraries for managing asynchronous code in JS without hiding it away is http://github.com/caolan/async
I agree wholeheartedly, by the way. There's way too much scope for leaky abstractions when you try to hide away the true nature of asynchronous code.
Same reason, I think, why most people are lukewarm about using continuations in web development, like e.g. Seaside does: in principle, very neat, very clean, but it hides away a fundamental aspect of how the web works, which can lead to all sorts of unforeseen behavior re. caching, debugging et cetera.
"There's way too much scope for leaky abstractions when you try to hide away the true nature of asynchronous code."
Done properly, that's not terribly true. Done properly, correct code transformers can actually bring you a lot of power, such as handling exceptions correctly across asynchronous boundaries or enabling much more powerful control flows, such as being able to freely pass in callbacks that themselves may have asynchronous functionality, layered arbitrarily deeply. The only thing that can "leak" is exactly where the asynchronous breaks occur, but it's not that hard to see that.
It's quite debatable that "the true nature" of asynchronous code is in the manually-scheduled hacked up code that you write by hand in Node.js or similar tools. Other environments that don't require that make a good case for saying that the "true nature" of asynchronous code looks like the synchronous code, only with capable scheduling, and the real "leaky abstraction" is the way your terrible, terrible language runtime scheduler is poking out and requiring you to manually transform your relatively simple code into a spaghetti mess to satisfy it. There's your leaky abstraction, and what leaks out is daggers slicing your code to ribbons.
Yeah, I assumed there had to be libraries to do this already, but didn't come across anything that did what I wanted. I'll check out async though, thanks for the heads up.
There are many many attempts at solving this problem, both libraries and preprocessors. None seem to satisfy a large audience, most people seem to deal with the callback nesting and hope to avoid cases where it gets super ugly.
I have a lot bookmarked on github, these are mostly libraries.
Some branches of CoffeeScript are also trying to ease the pain. Defer keyword didn't make it into CoffeeScript main. My impression is CoffeeScript makes callback hell less ugly anyway, so there is less need for adding a complex language feature that generates unreadable JavaScript.
While I appreciate why people would want to abstract around them for some use cases, I gotta point out that nested serial callbacks aren't just a nuisance. 95%ish of the serial cbs I've written in Node have benefited from their nested lexical scoping: A cb in a serial chain tends to rely on results from earlier in the chain, and it's nice to be able to refer to variables in the outer scopes without having to pass hella arguments between callbacks.
Related from a technology standpoint: CASH Music (http://cashmusic.org/) is a non profit dedicated to providing technology to enable a more direct musician to patron relationship. Lots of artists are going this route, which is really much more in line with how artists typically made a living up until the 20th century (i.e. patronage).
I love these 826 stores. I've got a set of time-travel travel posters from Echo Park and some cans of immortality and omnipotence from the Brooklyn Superhero Supply Company as well :).
Actually, I think best practice is to not put the version number in the URI at all. Instead versioning should be handled via content negotiation. That is to say, a client specifies the type of resource they want back via the Accepts: header, and that resource is versioned. So A request would look something like:
GET /client
Accepts: application/vnd.clientlist.v1+json
And they would get back the version 1 client list response. If they want v2, etc, they can specify a different content type (clientlist.v2+json, etc). Also note, that putting verbs in your URIs is counterintuitive. The verb for a REST operation is the HTTP method (GET, POST, PUT, DELETE). The URI should simply represent the resource being retrieved. An argument can be made that the client list is the resource, but in reality listing things from a REST API is a first class concept and shouldn't need separate URIs. It's simply a request for a specific resource type without qualifying it by asking for a single instance of that resource. So, GET /client would return all clients (can add query parameters for pagination, etc), GET /client/834 would return a single client resource.
Can I have a few more upvotes please? This is the only way to do it. There's currently two root posts above this one advocating the incorrect way, with versions in the URL.
By doing it this way, you don't break links when you want to bump versions. Or if you have a single resource with an incompatibility, you can just upgrade the version of it, and leave all the others the same, without having to change anything, or your clients having to change theirs, either.
Answer needs more love. The capabilities of the client are part of content negotiation. The version that the client supports is thus also part of content negotiation, just like content format, language, character set, compression method, etc. are
Please do not place the version number in the URL, it is a horrible practice
Unless I'm mistaken, this basically tells me that I should put the same code for v1+json and v2+json in the same controller method, rather than actually dispatching to separate controllers. I'm not sure how it's done in Rails, but /v1/ and /v2/ are dispatched separately since they are different namespaces.
Also, how do you separate users accessing your API if not with X-* HTTP headers with an API key? (I'm referencing that link you posted). Would you not consider Gowalla (and hundreds of others who use X-* API key headers) as being RESTful?
In rails3 we could use constraints to limit requests to header x to be routed to controller x and vice versa for controller y. I dont tested it yet to be sure but I think its totally possible.
