bigonlogn

Also, you can achieve some pretty fast development velocity with .NET. C# is intuitive and the tools are great. I know everyone complains about Visual Studio, but even it's most vocal complainers will admit it sets the industry standard for debugging.

One sticking point is that the tools, while community and small projects, are all behind a license. But, they are free for small teams making under something like $1M/year in revenue.

This is not entirely true. Since we talking about implementing stateful sessions, you could receive a valid token (stolen, out otherwise) after the user has logged out.

You are correct that the lookup doesn't have to be via the database. You could implement a caching system where the cache is invalidated when the user logs out and requires reauthentication. This is the notion of the session. By definition they cannot be stateless.

Stateless authentication is inherently (slightly) less secure than sessions. I think of a blind librarian who gives out keys to the library. Whoever has a key has access. You can put limitations on the timeframe someone has access to the library, but that's it. If your key gets stolen, the blind librarian can't help you as there is no way for him to tell if it's really you.

You can also supply an options object (including headers) as the second argument[1].

[1]https://developer.mozilla.org/en-US/docs/Web/API/GlobalFetch...

JWT is just a token. It's not some panacea of client-side only authentication. There are a lot of people lamenting the difficulty in performing logout via JWT. I believe people are missing the point. The failing isn't with JWT, it's with the implementation of the session system.

Typically with sessions the client has a session key. The key gets sent to the server where it looks up the session (via. memory, cache, database, whatever). You can create a new session, validate an existing session, or end a session. All using that key. They only difference between JWT and cookies is JWTs aren't automatically sent with every request. You have to explicitly send them. I believe this is a good thing. It avoids some common attack vectors.

You can implement sign out everywhere by setting a reauth flag on the user in the database. You lose the "completely stateless" aspect that JWT claims to provide, but it's a small trade-off for tighter security.

Stores hold the state your Views use to render. This can include more than just the data backing the Views. It can include things like which item is selected in a list, if a link is active or not, and any error messages as well.

FYI, the "docker.io" repository in trusty points to an older version of docker (0.9.1). I believe the script at http://get.docker.io/ubuntu will install the latest version of docker.

Generators definitely have their place. They're good for prototyping, and creating internal tools. Tasks that are time sensitive and can really benefit from eliminating boilerplate code.

Larger LOB, or public facing apps require more thought and planning to ensure that they get the job done right.

yeoman seems to be involved very little, in this tutorial. It seems more like a bower/grunt tutorial. I was expecting to see yeoman used to generate models, views, and controllers. It's a shame because, I think this is where yeoman could really shine.

> You could make a better choice.

But you can call it whatever you want, so... who cares? The choice is yours... Being a pedant is hardly constructive.

You hold Ctrl (or Shift+Ctrl) while you tab to cycle all the way through all your tabs. The first time you press the combination, it switches to the last tab you were in. This is how it is in version 2, anyway.

This is the nature of using any third party software or API. If you're not going to write it yourself, then you have to be willing to play by someone else's rules. Words I learned to live by years ago.

Coincidentally, this is how I feel about AngularJS. By using it, you're developing apps the way Google wants you (or it's own developers) to. It could be good, it could be bad. it depends on the app, but you still have to do it their way.

You don't want to be locked into Google's walled garden, but, by using Angular, you're already inside...

His views aren't the issue, his outspokenness is. How could a woman ever feel comfortable interviewing with this guy, let alone, working for him. What if said woman was a great fit for the company and had a lot to contribute? His ability to hire and fire effectively is compromised. Not because of his views, but because he couldn't keep his mouth shut about them.

Sometimes knowing when to shut the hell up is a far greater asset than being outspoken and opinionated. Especially about things related to your job...

This looks like a known issue. It seems this doesn't work on windows at the moment... See https://github.com/kytrinyx/exercism/issues/20