almost

Please don't go the Daily Mail for anything more than an idea of what small minded scared bigots we English sometimes can be.

I'm not a lawyer so I couldn't say. But apparently that's how it works when it comes to fonts.

I meant it when I thanked you for the comment. It was a fascinating insight into how these tests actually come about. Thanks for writing it!

But that's the thing, they don't identify bad teachers. And they do penalize good teachers. Being taught to pass these tests is not the same as being educated. All the tests do is identify teachers who don't put the majority of their teaching effort into getting children to pass the tests, to the detriment of everything that matters.

Please don't be so defeatist. The US education system is horribly broken. Maybe the chances of it ever being fixed are low but I hope people continue to try.

Thanks for your fascinating comment.

Unfortunately, all the excuses in the world don't change the fact that these tests hurt education and hurt children. The production of these things is a shameful act.

I thought the tests we had in the UK were bad, and they are, but the US obviously has a far greater problem. I hope this changes, because you are hurting your children and damaging your future.

You can trace the outlines and produce an exact or almost exact copy, and that's what Ariel actually is.

Imagine if you could scale up and down the amount of computing capacity you were paying for on a second by second (or even ms by ms) basis! That would be pretty cool :)

Pretty cool, but I'd love it if it would show all the projects I've contributed to along with how much I've contributed.

The list of projects on my account isn't a good way to see what I've done, loads of it is stuff I've just forked and not done much with (or maybe fixed one tiny thing), then there's the odd thing I've commit more to, but you can't tell that.

It would be even nicer to have a way to highlight bits I'm especially proud of :)

What's especially nice is Websockets have their own url type (ws://) you can just include a link to the Websocket's endpoint for the resource for the API client to follow. Reductions in the amount of custom stuff that has to be done is always good :)

I think little upgrades happen all the time. And sometimes you need a way to handle those.

It depends what you want to share though. Are you sharing the location of a resource or are you sharing a specific version of that resource?

If I'm viewing some resource in some client that supports version X and I send it to you and you view it in a client that supports version Y (maybe this happens automatically, maybe new versions are in the process of being rolled out, maybe your on the mobile client that hasn't been updated yet) isn't it better that my client gets a representation of it that it can understand?

(I don't think there's one answer for everything, I think both can make sense in different situations. But I think versioning via Headers can be very powerful and can interact well with of RESTful types of things you might want to do, it would certainly make no sense in an RPC style API)

Some answers, may be wrong but this is how it makes sense to me:

1. Possibly both (the one in the URL being the version of the URL-space and the one in the Header being the more fine grained Representation Version).

2. It depends. For simplicity it often makes sense to put it in the URL. For more generality headers can be better.

3. No

4. They don't have to. They usually do though and it makes most sense when they do.

5. Fully formed URLs are simpler, so go with those if you can. But sometimes you'll need more.

6. URLs are a subset of URIs. All URLs are URIs. URLs give the location of the resource whereas URIs just have to identify it (but could also give the location of course.

7. It depends. I lean towards different but I'm no authority.

8. Using the Accept-Language header. But I'm guessing this is not always the best way to do things.

You are a little. In a properly RESTful API you simply don't construct URLs most of the time. Instead you follow links. If you change the URL structure you break the links. If that's what you want then a version number in the URL makes sense, but in a properly RESTful API that's probably not what you want.

I think for a lot of people the reason they don't see the benefit of things from REST is they try to use them in isolation. You say "this is useless for my RPC style API!" and you are right.

Full content. I have a layer over Backbone.JS on the client side that provides an identity map for models (all of which are identified by uri). When a representation is recieved it grabs the relevant model and updates it which makes any views listening on that model also update themselves in the normal backbone way. I think it's kind of neat :)

Apples vs. Oranges: discuss!

(I'm quite happy with my RESTful API that allows subscription to resources via Websockets. This works very nicely when your resource representations include their own href)

But how do you deal with the partial upgrade scenario? I might want to use a few of the new features in my client code but not have the time to upgrade (and test!) everything just yet.

Of course version numbers in URLs can have their place too. But I think they should only really be used in situations where you have upgraded so much that the original URL space just makes no sense. And if you can avoid huge breaking upgrades like that through good initial design then all the better :)

There's nothing wrong with doing that. A resource can have multiple URLs and multiple representations. That's fine, in the right circumstances.

I think different approaches are suitable for different situations. Quite often I think different translations of the same thing should be treated as different (but related) resources.

With a RESTful API you don't tend to need IDs most of the time, you just use URLs. So having all the versioning info in the URL is not so great, you change the version and suddenly all the URLs aren't valid anymore.

But more important that is upgrading a version on an API may not be an all or nothing thing. You might want to start using the new features of the API on one resource type but you aren't ready to upgrade your usage on everything else. If the version is in the API you'll have to take apart and put back together urls to get the right ones, this is logic you don't want to have to encode into your client. If on the other hand you use Accept headers to do versioning you can have as fine grained control as you need.

Regarding the custom HTTP verbs it may seem like you need those at first but in practice you really don't and there is almost always a good clean way of doing things that doesn't break anything (or so I've found). I find that the solution is usually to introduce another resource or two, the transactions example from the article is a perfect example of this.

I know it sometimes seems like this is all abstract stuff that has no impact on the real world but it does make sense eventually! It's really lovely to use a properly RESTful API :)

It does matter. The more you build on predictable standards in one place the simpler things get in others.

On the subject of the Turing test Turing's actual originally paper is well worth a read: http://cogprints.org/499/1/turing.html

It's extremely readable and you may be surprised at how often people entirely miss the point when discussing it.

I'm currently going in sort of the other direction. I'm usinge evil-mode which is VIM implemented in Emacs. Emacs does have many of the powerful features of VIM but what it lacks are composable commands. So what in Emacs would take NxM separate commands can be supported in VIM/Evil-mode with N edit commands and M movement commands (not to mention the modifiers like (i)nside or (a)around). I find myself intuitively using combos ive never used before, it just makes sense that they would work whereas I would have had to learn them individually in Emacs. What Emacs has that VIM lacks is it's amazing customisability, I love switching to scratch and changing how my editor works on the fly, I also totally rely on Org-mode along with my customisations of it (I even use it to generate my website!). I'm sure it's not for everyone and I wouldn't recommend it to someone without Emacs, or at least VIM, experience but for me Evil-mode really feels like the best of both worlds.

(commenting from my phone so please excuse weird autocorrect thingies)

I wish I'd seen you comment before I bought it. I couldn't get it to work with any of my windows. It even has problems with it's own tutorial Window!

I'm actually considering trying to get my money back, it's that bad.

It's not quite the same thing but Moom is pretty good. It doesn't try to automatically manage windows but it does let you position (inc full size) windows very quickly with the keybaord.

The system they have now is the #! hack, the crawlers know how to request static versions of the pages. There isn't a similar mechanism for pushState based designs, you just serve up the content pre-rendered for the initial page. So that's probably what they will do to stay indexable. It will also make the first page load snappier (probably)

I think Crowdflower (http://crowdflower.com/ ) would be useful in this situation. I've used them before because I'm UK based and MTurk wouldn't let me create HITS (not sure if that's still true?) but they also add some stuff to MTurk like a HIT designer (a form designer) and, more interestingly here, an interface to have people complete your HITS outside of MTurk.

Awesome stuff: http://julialang.org/manual/metaprogramming/

Looks cool. How about letting us enter a user and show all the repositories they have committed to along with how much they've committed.

It would be good to be clearer about licenses. It just says "Single Site" right now but it would be good to have a page that clarifies exactly what you mean just in case my idea of what that means differs from yours.

Will exclusive and multi-site license options follow?

Also, on your /sell page there's a heading that says sellers earn between 55 and 75% but in the text of that block it says the non-exclusive share is 35%.

Anyway, as I said below this is awesome and I wish you the best of luck.

If it becomes a problem for you and you think there are people who would steal them without that but pay you with then go for it. But it will make it harder to evaluate themes for people who do actually want to buy them.

This is an awesome idea by the way. I love the choice on Theme Forest but I the flexibility of Bootstrap is brilliant too. I'm also using Bootstrap whenever I prototype anything and being able to just buy and use a theme later on would be incredibly useful (obviously it's not quite that simple, but it could be close). I will almost certainly be buying lots of themes from you assuming you get designs (which I'm sure you will!).

I'm surprised ThemeForest don't have a Bootstrap section yet actually...