bradrobertson

"Catching on" doesn't mean "is the right way to do things". Code reuse is in fact a prime example of a misuse of inheritance

Like others have mentioned here, simply pointing out examples where microservices have failed doesn't imply that microservices can't succeed. I've attempted to bake bread twice and they both failed. I didn't conclude that baking bread can't be done, but that my skills to do it were insufficient.

There are lots of examples of successful companies using microservices, but I believe the real problem is in defining what constitutes a microservice. Most people call things "microservices" that are nothing of the sort. I can unequivocally say if you built a "service" that depends on other things being 100% available (like another "service") than you haven't built a microservice (ie: those things you built shouldn't be called services).

By that token, autonomy is a pretty important factor. The Udi Dahan teachings (https://particular.net/adsd) (currently available for free) promote this style of architecture. A concrete example of a toolkit for building true microservices can be found in Message DB (https://github.com/message-db/message-db) and/or Eventide (http://docs.eventide-project.org/)

I wouldn't suggest, however, that anyone can just watch the course, pick up these tools and succeed. Like baking a good loaf of bread, it takes a lot of skill, work and experience. Whether or not you succeed at building microservices is ultimately up to you and your team.

Looks promising! Are there any docs coming on a production ready setup? Reading below it looks like you're working on high availability, but even in the single machine scenario, do you have recommendations for persistence, fault tolerance etc?

I'm not sure I'd agree that "All Threads" not being a channel warrants the exact opposite navigational behaviour as a channel. An obvious user experience is one that I don't have to think about. If you've already been trained by Slack to expect different behaviour on different screens then of course you'll think they did it right, but I don't care to have to be trained on how to use software.

As for hard dates I don't know of any, but the article suggests "2 years" and I've seen StackOverflow posts from 2014 asking about threading so I'm sure it was at least on Slack's radar for that long.

The point of all of this however is that a) 2 years is far too long for an MVP rollout (if that's what this is) and that b) they simply added some lipstick onto existing substandard features.

Our personal preferences re: UX etc aren't even really all that relevant as we'll obviously never agree on that, but we can certainly agree that spending 2 years delivering a limited-use MVP for a giant company like Slack with almost unlimited manpower is pretty miserable.

I was going to say the same thing. I wouldn't even think about touching this gem. Multiple methods close to 200 lines long, all in a single file with no test suite. I shudder to think what the cyclomatic complexity of the 'api_comparison' method is. Have fun contributing to this project.

We use roughly this one in our office: http://nvie.com/posts/a-successful-git-branching-model/

Good call I'll update the post to mention resolving commits. This was not intended to enlighten those who already know how rebase works.

outraged? I think it's amazing. This is the kind of creativity we need from professors, especially in subjects such as programming where things can get quite bland. I wish I had these kinds of tests in school, I probably would have paid more attention.