nickknw

Oh that's clever! What a cool way to do your personal site. Definitely makes it stand out

> healthy primary income provided by the synergy between them and their community

Definitely interested in this.

Haven't tried Reflux but I would recommend trying Redux before it. It is heavily inspired by Elm and has been very pleasant to work with. Reflux also bypasses the 'unidirectional data flow' part of Flux, which gives you added convenience for some things at the cost of more complexity.

Well that's a bit disappointing, although probably pretty important to their business model.

Will make the news of a jailbreak for PS4 that much more exciting at least :)

Oh I see - you just needed to be a licensed developer to get their version of it before, is that it?

> You still can't do anything with it if you aren't a licensed developer.

Not sure I follow - what is stopping non-licensed developers from developing and testing games on their own PS4s now that this has happened?

Well this is pretty exciting. This opens up the door for PS4 games to be written in any language that uses LLVM as a backend, right? So in the future, PS4 games could be written in D, Rust, Ada, ActionScript...

Especially with the indie focus Sony has had, this could make it much much easier for people used to creating games with ActionScript to get their game on a console.

Is there something I'm missing? This seems too good.

Glad to see another language that has chosen to avoid NullPointerExceptions. Some of you might take issue with the way it is implemented (special syntax vs general type), but IMO it is still much better than having NPEs.

Here is a practical everyday example where languages that can represent emptiness in the type system come in handy.

He ends up using pointers and mentions: "Using pointers also means that clients of the library will need to perform their own nil checks where appropriate to prevent panics."

Looking forward to using Rust :)

Ahh, now that makes sense, thanks! The HTML5Rocks article cleared up my concerns.

For anyone reading this later, it was the section starting with this paragraph:

Inline Code Considered Harmful

It should be clear that CSP is based on whitelisting origins, as that’s an unambiguous way of instructing the browser to treat specific sets of resources as acceptable and to reject the rest. Origin-based whitelisting doesn’t, however, solve the biggest threat posed by XSS attacks: inline script injection. If an attacker can inject a script tag that directly contains some malicious payload (<script>sendMyDataToEvilDotCom();</script>), the browser has no mechanism by which to distinguish it from a legitimate inline script tag. CSP solves this problem by banning inline script entirely: it’s the only way to be sure.

> How would you like to be largely invulnerable to XSS? No matter if someone managed to trick your server into writing <script>alert(1);</script>, have the browser straight up refuse it?

I don't quite get how this header makes you invulnerable to XSS, would someone mind explaining?

It seems like it only prevents XSS attacks from loading remote javascript files. What's to stop the attacker from just injecting the entire script inline? If you can get a small piece of javascript to execute you should be able to get a larger piece to execute just fine.

I can see how it makes XSS more inconvenient, but I don't understand how it makes you largely invulnerable to it.

This exchange has really helped me understand more about Docker and why and when to use it. Thanks!

I for one thought this was a fantastic article, and quite well-written.