From Securing your HTTP API with JavaScript Object Signing and Encryption:-


Basically, the token (JWT) is the simplest structure that you will deal with while implementing JOSE in our architecture; it is a string representation of some data base64 encoded (other types of encoding might be applied, but this is not madatory): the JWT differs from raw base64-encoded data since it also includes informations about the encoding itself, in the token’s header; by concatenating the base64-encoded version of the token header and payload (the actual data) you obtain what the specification calls signature input, which will then be used to create the signature (JWS).


After the JWT comes the JWS, which is a signed representation of the JWT; it differs from the token just because of the signature; on an higher step of the ladder comes the JWE instead, which lets you encrypt the data in order to achieve an higher security level: the examples in the ietf draft show you how to create JWEs with a pair of private / public keys.

ISO 8601

From biztalk360:-

Out of the 2 important tricks we applied, one of the trick is agreeing on the standard date and time format string between the client and REST API. It’s a simple no brainer decision to use the ISO-8601 format, it’s pretty much THE internet standard when it comes to handling date and time in web focused applications.

Self-tuning Systems

From Where are the self-tuning systems?

In 2015, self-tuning systems mostly don’t exist. Every single piece of software still relies on magic numbers found empirically or pulled out of thin air, by developers or by users, possibly manually adjusted later in order to get closer to an acceptable security/ reliability/ performance balance.

ES6 Generators

From Hanging Up On Callbacks (video here).

What does the following code output?

function* powGenerator() {
  var result = Math.pow(yield "a", yield "b");
  return result;

var g = powGenerator();

Hover below for the answer!