colin_jack

I think it’d be better to judge it once those users have had a little time to try it. I signed up but couldn’t find anyone to follow, found the lack discoverability baffling, and ultimately bounced off.

>I found this disappointing because it means that for there to be a critical mass of content in a particular community so that it gains in popularity, then that particular community in that particular instance has to become popular on its own, instead of all instances contributing to one big community

Totally agree. The whole server focus is not user friendly or intuitive.

As an example I finally found someone to follow and decided to look at the people rhey were following, but it would only show me people from that server.

The complete lack of discoverability is jarring. Really not sure Mastodon is ready for mass market.

I dunno, on performance they could just have limited number of registrations to what they can handle. Better that than having potential users getting a bad impression because everything is too slow.

> The slowness and bugs might be due to the sudden influx of people from Twitter

Yeah definitely, feels like they should have seen this coming though. They have an opportunity that won’t come around again, and poor performance and confusing UX seem like pretty serious problems.

> As designed the UX is bad and cannot be fixed because of these issues.

For fun I just tried signing up and the process itself is confusing, sluggish, buggy, and ultimately didn’t work. It feels like it’ll need to improve very quiclkly if it’s going to capture any significant amount of Twitter users.

Yeah I had the exact same issue with syncing externally purchased music whilst using apple music, I honestly could not believe apple has delivered software that behaves in such a user hostile manner. It hurts their reputation and convinced me to give up on some music.

OK get you, I personally don't mind that sort of thing if I am explicitly asked but I see what you are saying.

I am not sure it's the same, as far as I was aware Google photos never deletes the local copy.

I unsubscribed from apple music when I found out about this and discovered iTunes would not allow me to sync music I bought from bandcamp onto my iDevices whilst using the iCloud support.

Does seem to be working times for apple, product wise they are making of decisions.

Same for me, it looks good but £270 is too much for me to justify.

To me big problem with Vainglory is not that the matches are long, its that your locked into the matches.

Quite often within minutes of starting match you find out your team-mates have no interest in playing strategically or are actively trolling you. At that point you can be pretty sure the match won't be fun and you'll lose.

However the game expects you to keep playing for the next 20-30 minutes till your team inevitably loses. I know eventually you can trigger a surrender vote but it didn't seem like they were ever successful.

Beats me, it was the first time I'd seen it and I found it pretty surprising.

I don't really think that's always true, if the cookie merely has a session ID then the session itself can be stored server-side (not necessarily in memory of course) and in fact could be a resource in its own right.

Also deciding to put the session ID in a cookie not the URL is purely a pragmatic approach (e.g for security reasons).

I guess the obvious argument would be that its worth subsidizing public transport as it has additional benefits, in terms of the environment and being open to the entire population not just those who are able and can afford to drive.

Ta will definitely give it a look, one nice thing about Serial is it put me onto This American Life which I'm enjoying (in parts, some of it puts my teeth on edge).

The depressing bit about the system is even when it's clear there's been a potential miscarriage of justice, and some poor sod has spent years behind bars on very shaky grounds, the system still tries its best to keep them there without retrial.

I'm not an expert on the UK legal system but one thing I enjoyed about the Serial podcast was getting an insight into just how crazy the US system can be.

Anyway 10 days is obviously nothing, especially when he's cost a man 25 years, but at least it's an attempt to hold someone responsible for a despicable act.

I've put some thoughts below with references to cookbook recipes, I'm not saying they are in sweet point for a lovely resource oriented design but they are things you can handle.

1. Recipe 2.4 is one option. Alternative might be granular resources, if the characteristics of your use case means they can be done efficiently. For example we might include the URL to author details inside the article. That means another request, but if those author details are made immutable (as in change to author details means new URL), then they can be given a long cache period. Also HTTP/2 will mean more granular resources have different performance characteristics.

2. Recipe 11.10 could work so the URL would be the comments collection as a whole, I'd use PATCH (or POST if PATCH isn't an option) to then send the updates you need. So a PATCH to /<posturl>/comments with the result body including information that causes those comments to be deleted.

3. Same idea as 2, I'd use PATCH to the collection or a custom resource.

The page linked to in the second point mentions "Restful Web Services Cookbook", it's a while since I've read it but my memory is as the the author says it covers solutions for each of the three issues you are raising.

1. I think though you'd really want to have some measurements regarding the performance impact of things like over fetching.

Also remember that having a resource oriented design and working well with HTTP gives you out of the box advantages in terms of caching and validation, and in HTTP/2 you get extra efficiency advantages (e.g. lots of more granular resources can be retrieved over a single connection).

2. There are patterns for that though, often best approach is to represent that transaction as a resource. Restful Web Services Cookbook covers approaches for these sorts of bulk operations.

3. Not sure that's an argument against going resource oriented, if you don't find the debate interesting just ignore it.

Indeed, not only can it more entertaining but a more people focused approach is known to be more effective as the Guardian themselves recently pointed out [1].

[1] http://www.theguardian.com/commentisfree/2015/sep/04/the-gua...

Not sure I agree, I found it very readable.

Some of these comments seem to be proof that not everyone commenting on here reads the articles before giving their views.

Much appreciated ta, will give it a look.

Its not about getting errors before they happen:

http://jlongster.com/Stop-Trying-to-Catch-Me

Would you have a link to an example of a streaming API done elegantly with async?

I'm interested to see what it looks like.

> On two occasions, I observed pups falling out of the female while being pelted on deck. The two pups I observed were alive and were thrown over the side. I seen these pups crawl up on the ice after we threw them over aboard.

Grim.

Utter nonsense, he replied to a comment about expressiveness with [1], its only natural that I assumed he was saying that lack of static typing lead to lack of expressiveness.

[1] ES6 isn't statically typed. It might be better for you , it is not for me.

OK but he quoted the expressiveness in his reply which I thought meant that was the point he was addressing.

> Modern JS (ES6+) isn't worse than Java or C# in terms of expressiveness. > ES6 isn't statically typed. It might be better for you , it is not for me.

So you are saying that because it isn't statically typed it's inherently worse in terms of expressiveness?

There's a valid argument that static typing has big advantages (navigation, refactoring) but it worries me when people write off dynamic code entirely.

Is that really a general problem in the Go community?

I ask because I've seen people explaining the tradeoffs Go makes pretty clearly online without any rudeness or condescending attitude.