2017. július 6., csütörtök

Understanding JWT

Using JWT-s is a widely accepted way of authentication.
The reason why JWT-s are used is to prove that the sent data was actually created by an authentic source.
This means the client will get this token which is signed somehow with a secret (stay tuned) and with that the server can trust that client that it is already authenticated without having to handle sessions in memory.
It's very important to mention that the purpose is not to hide data! Let me show you this through an example.

Autopsy of a token

I would like to give a try for another approach by explaining how JWT-s work and it is by using an existing example and analysing it.
Let's have a token:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleGFtcGxlLmNvbSIsInN1YiI6ImFkbWluIiwiZ3JwIjpbImFkbWluIiwidXNlcnMiXSwiYWRtaW4iOnRydWUsImF1ZCI6ImV4YW1wbGUiLCJleHAiOjE1MTQ3NjQ4MDAsImlhdCI6MTQ5OTI2NDQ4NX0.w1Ls_fdotl3SdqFp2GcadSzc8a5Po77qeIUgknZ0X78
Separate them by the character "." and we have three parts. 
The first one is the "Header". It is encoded via Base64, which you can decode via your browser for example.
Try it in your console: atob("eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9")
This is going to return {"alg":"HS256","typ":"JWT"} , which stands for
  • typ: the type of the token which is JWT
  • alg: the hash algorithm which is going to produce a signature for the header and the payload
The key part here is that this is not even signed, you can read it anytime! You just need to decode the Base64 string via e.g. your browser or however you would like to.
The middle part is the Payload. Similarly you can decode it by calling
atob("eyJpc3MiOiJleGFtcGxlLmNvbSIsInN1YiI6ImFkbWluIiwiZ3JwIjpbImFkbWluIiwidXNlcnMiXSwiYWRtaW4iOnRydWUsImF1ZCI6ImV4YW1wbGUiLCJleHAiOjE1MTQ3NjQ4MDAsImlhdCI6MTQ5OTI2NDQ4NX0")
which stands for:
{"iss":"example.com","sub":"admin","grp":["admin","users"],"admin":true,"aud":"example","exp":1514764800,"iat":1499264485}
BOOM! Nothing fancy, just decoding some Base64 string, that's it!
These keys are mainly standing for who you are and when this token will be expired, but you can check out more here: https://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#rfc.section.4.1.6
The last part is the signature itself. NOW comes the interesting part.
The plan is the following how we can create a signature:
  • First you need a secret which is a string. In our case it is "That's a secret."
  • Then you'll need to Base64 encode your Header and Payload (remember, these are JSON strings!) - let's call them B64Header and B64Payload from now on.
  • After that you can sign these by passing two arguments for the chosen hashing algorithm (HS256 in this case)
    • The first argument is a string which looks like this: B64Header + "." + B64Payload
    • The second argument is the secret.
  • And the hashing algorithm returns then the signiture, which is going to be the last part of the token. Easy!
To make sure you understood everything visit https://jwt.io/ and try the token I provided in this article and make sure it's signed correctly (so it is a valid signature!)
Cheers!

2017. június 12., hétfő

Writing your own container in Go

This artice is about creating a tool which is like Docker, but much more simplified.

First of all, why do we need containers?

I like to think about containers as separate little planets who live in a universe. There is a planet for database management, other one is for an operating system, etc.. They don't care about each other, however you can create communication between them via e.g. radio waves. This could be  the interface between them.
In my world, what is good about these planets is that you can copy the exact same environment which it had, but who is going to live on these planets is up to that specific instance. (E.g. you can achieve that with quantum entanglements - this is getting a bit too fantasy-like haha.)
Let's get back to our containers. With these you can assure that if it works on your computer, it is going to work on any of them in the world - in theory. Saying that you can easily automate your processes for deployment, make development easier and more productive.
So - long story short - containers are really important for modern development environments.

Ok. How can I create one?

It's not that complex! Really!
First of all, I would like to shout out to Liz Rice, whose talk I saw at Craft Conference in Budapest few months ago. (similar video - twitter)
First, you have to understand two core features: control groups (cgroups) and namespaces.
So what are namespaces?
Well, in it's fundamental, namespace is what a user can see of it's environment: process id-s, file system, users, networking, hostname, etc.. And it's all yours, noone else's!
Ok now, let's see what cgroups are!
If we are sticking to the analogy before, cgroups are what you can use, like CPU, memory, disk I/O, etc.. So basically speaking about resources.
And now let's jump into coding!

As you can see it's not that big of a source code. Only 56 lines!
The basic idea is that we are going to run a system call inside a system call.  At the main function it is going to jump into the run function since first we passed the "run" parameter. (go run main.go run)
Basically what os.exec does is wrapping external commands so they can run in their own namespace. Uhm, excuse me? I have heard about this word before.
Well, no surprise, with this line of code we are going to achieve our own namespace, and we are going to have our own process id-s. Great!
You can see here that we are passing the new argument "child" which means it is going to call the child function.
The next interesting part is the 33rd line where we are passing a bunch of flags for the newly started process, these are:

  • CLONE_NEWUTS is for namespace
  • CLONE_NEWPID is for new process id-s
  • CLONE_NEWNS - this means unshare the mount namespace, so that the calling process has a private copy of its namespace which is not shared with any other process.
Neat! So now we now how we want to run our child process which has it's own namespace and cgroup, but it's still not working in it's own "world". We have to give it a filesystem which behaves like an ubuntu filesystem would work.
So that's where one another trick comes in: we have to have a linux root filesystem which will be the playground of our container. You can learn about the restrictions for the root filesystem here: http://www.tldp.org/LDP/sag/html/root-fs.html .
With this in our toolbelt we can change the root of our child execution to that particular root filesystem directory (46th line), and with the 48th line we are mounting /proc because it's a special kind of directory, and THAT'S IT, if you run go main.go run /bin/bash you will have your own little planet which is completely separate (well, now you know, it's not that separate, but it's acting like it is ;) ).
Enjoy and feel free to play around if you like these kinds of little aspects of modern software development / containerization!

2017. április 11., kedd

Favorite logical puzzles

This topic is a bit related to my JavaScript interview questions post, because I think it is a very good test to see how a candidate relates to a so called 'difficult' problem. If she just freezes, it is a bad sign, but if she starts to cover the options, that's a very good sign.
Here are few of my favorite puzzles:

2017. február 7., kedd

React Redux notes

I've started to work on a project where the frontend is using React with Redux and I thought it would make sense to collect all the confusing parts of this ecosystem which made me think about something twice or more. More or less this article's content is available at the official Redux page. Enjoy!

First of all here are the presentational vs container components in comparison:



Presentational Components
Container Components
Purpose
How things look (markup, styles)
How things work (data fetching, state updates)
Aware of Redux
No
Yes
To read data
Read data from props
Subscribe to Redux state
To change data
Invoke callbacks from props
Dispatch Redux actions
Are written
By hand
Usually generated by React Redux

This is not rocket science, but still, it is a really good separation between components. In one sentence: containers are Redux aware while components are not, they are just getting everything via props (both parts of the state and callback functions which will call some dispatches on the Redux store).

Redux

Here is a silly picture of Redux, but actually it represents well how the state changes are managed.

An action creator is basically a helper for actions where you can pass an argument and it will return an action, nothing fancy.
When are action creators used? Here is a great article: https://daveceddia.com/redux-action-creators/. To sum it up, whenever you need to pass some dynamic values like username or e-mail.
combineReducers:
when there are lots of reducers (a function which handles a call of an action and creates the new state regarding to that action) it is tideous to write a rootReducer like this:
function rootReducer(state = {}, action) {
return {
reducer1: reducer1(state.treeNode1, action),
reducer2: reducer2(state.treeNode2, action),

}};

Very important! Each of these reducers are managing its own part of the global state. The state parameter is different for every reducer, and corresponds to the part of the state it manages.
Actually combineReducers is simplifying this with the following syntax:
import { combineReducers } from ‘redux’;
const app = combineReducers({
reducer1,
reducer2,

});
export default app;
All combineReducers() does is generate a function that calls your reducers with the slices of state selected according to their keys, and combining their results into a single object again.
Store
  • Holds application state;
  • Allows access to state via getState();
  • Allows state to be updated via dispatch(action);
  • Registers listeners via subscribe(listener);
  • Handles unregistering of listeners via the function returned by subscribe(listener).
data flow (how redux handles actions)
  • You call store.dispatch(action).
  • The Redux store calls the reducer function you gave it.
  • The root reducer may combine the output of multiple reducers into a single state tree.
  • The Redux store saves the complete state tree returned by the root reducer.
    - Every listener registered with store.subscribe(listener) will now be invoked; listeners may call store.getState() to get the current state.

React-Redux

  • connect function:
    Basically what you could do is to subscribe to state changes at container components. But this is tideous and react-redux’s connect function does performance improvements where it is calling shouldCompentUpdate in an optimal way.
    • mapStateToProps
      With this function you are able to get a subtree of the Redux store as a prop for a component.
    • mapDispatchToProps
      This function enables you to bind functions which dispatches actions on certain events which were fired by the component.
  • Provider
    It’s a component.
    All container components need access to the Redux store so they can subscribe to it. One option would be to pass it as a prop to every container component. However it gets tedious, as you have to wire store even through presentational components just because they happen to render a container deep in the component tree.
    Provider makes the store available to all container components in the application without passing it explicitly
  • What's the difference between React's state vs props?
    state is a private model while props are sort of public
    “A component may choose to pass its state down as props to its child components.”
    So basically you can’t reach state from the outside, but you can tell parts of the state via props to a component “below” in the component tree)
A very good summary picture (from: https://raw.githubusercontent.com/uanders/react-redux-cheatsheet/master/1440/react-redux-workflow-graphical-cheat-sheet_v110.png)
React Redux cheat sheet

React component lifecycle diagram

A very simple (dumb) implementation of Redux

Sometimes I get really confused how the Redux environment is getting around. These times I get back to this very simplificated implementation of Redux (which is actually a pretty goo starting point).

Async Redux

Well, that's a bit more complicated of a topic. There are a few options if you would like to go with HTTP calls e.g.
E.g. there are great libraries like redux-thunk, redux-promise, redux-saga and many-many more.
Let's talk about redux-thunk first.
The action creator can return a function instead of an action object.
When an action creator returns a function, that function will get executed by the Redux Thunk middleware. This function doesn't need to be pure; it is thus allowed to have side effects, including executing asynchronous API calls. The function can also dispatch actions—like those synchronous actions we defined earlier.
Why do we need redux-thunk? (LINK) We could easily do the following (calling dispatch in the callback) this.props.dispatch({ type: 'SHOW_NOTIFICATION', text: 'You logged in.' }) setTimeout(() => { this.props.dispatch({ type: 'HIDE_NOTIFICATION' }) }, 5000) OR with action creators // actions.js export function showNotification(text) { return { type: 'SHOW_NOTIFICATION', text } } export function hideNotification() { return { type: 'HIDE_NOTIFICATION' } } // component.js import { showNotification, hideNotification } from '../actions' this.props.dispatch(showNotification('You just logged in.')) setTimeout(() => { this.props.dispatch(hideNotification()) }, 5000) OR with the connect() function: this.props.showNotification('You just logged in.') setTimeout(() => { this.props.hideNotification() }, 5000) The problem with this approach is you ca have race conditions, meaning in the above example if two components are waiting for the noticfication request to end, one will dispatch HIDE_NOTIFICATION which is going to hide the second notification erroneously. What we could do is to extract the action creator like the following: // actions.js function showNotification(id, text) { return { type: 'SHOW_NOTIFICATION', id, text } } function hideNotification(id) { return { type: 'HIDE_NOTIFICATION', id } } let nextNotificationId = 0 export function showNotificationWithTimeout(dispatch, text) { // Assigning IDs to notifications lets reducer ignore HIDE_NOTIFICATION // for the notification that is not currently visible. // Alternatively, we could store the interval ID and call // clearInterval(), but we’d still want to do it in a single place. const id = nextNotificationId++ dispatch(showNotification(id, text)) setTimeout(() => { dispatch(hideNotification(id)) }, 5000) } Now separate components will work with the async call: // component.js showNotificationWithTimeout(this.props.dispatch, 'You just logged in.') // otherComponent.js showNotificationWithTimeout(this.props.dispatch, 'You just logged out.') showNotificationWithTimeout need dispatch as an argument, because that function is not part of the component, but it still needs to make changes on the store. (BAD APPROACH: If we had a singleton store exported from some module, then the function does not need the dispatch as an argument. But this si not a good approach since it forces the store to be singleton. (which makes testing harder, becuase mocking is difficult, because it is referencing the same store object)) Now comes the thunk middleware in play. showNotificationWithTimeout is not returning an action, so it’s not an action creator, but it’s sort of because of that purpose. This was the motivation for finding a way to “legitimize” this pattern of providing dispatch to a helper function, and help Redux “see” such asynchronous action creators as a special case of normal action creators rather than totally different functions. With this approach we can declare showNotificationWithTimeout function as regular Redux action creator! // actions.js function showNotification(id, text) { return { type: 'SHOW_NOTIFICATION', id, text } } function hideNotification(id) { return { type: 'HIDE_NOTIFICATION', id } } let nextNotificationId = 0 export function showNotificationWithTimeout(text) { return function (dispatch) { const id = nextNotificationId++ dispatch(showNotification(id, text)) setTimeout(() => { dispatch(hideNotification(id)) }, 5000) } } Important note: showNotificationWithTimeout doesn’t accept dispatch now as an argument, instead returns a function that accepts dispatch as the first argument. Neat! In the component it will look like this: // component.js showNotificationWithTimeout('You just logged in.')(this.props.dispatch) But that looks weird! Instead what we can do is this: // component.js this.props.dispatch(showNotificationWithTimeout('You just logged in.')) Also worth mentioning that the second argument of the thunk (the returned function) is the getState method, which gets us access to the store. Also worth mentioning that not only redux-thunk is there to do async dispatches, but redux-saga (with generators and promises, like async-await) or redux loop.

Summary of async redux flow

Without middleware, Redux store only supports synchronous data flow. This is what you get by default with createStore(). You may enhance createStore() with applyMiddleware(). It is not required, but it lets you express asynchronous actions in a convenient way. Asynchronous middleware like redux-thunk or redux-promise wraps the store's dispatch() method and allows you to dispatch something other than actions, for example, functions or Promises. Any middleware you use can then interpret anything you dispatch, and in turn, can pass actions to the next middleware in the chain. For example, a Promise middleware can intercept Promises and dispatch a pair of begin/end actions asynchronously in response to each Promise. When the last middleware in the chain dispatches an action, it has to be a plain object. This is when the synchronous Redux data flow takes place.

2016. december 23., péntek

A bit of lambda calculus

Lately I have been messing around with functional programming. I find it extremely pure and scalable.
But I wanted to get back to the core of it and suddenly I found myself in the deep forests of lambda calculus. This article is going to cover what I learned the past few weeks. Let's jump in!


Lamba syntax only has
  • variables: x
  • lambda abstractions: λx.x
  • applications: (t s)
And that's it. Boom.
You have everything at this point. You have a Turing-complete language.
And that's (the simplicity) one of the most remarkable about this system.
Unlike other languages it has one primitive element which is the function. No Integers, Numbers, Strings, Characters, Booleans, etc.. Only functions.
But with this simple concept you are able to create any real-world general-purpose programs. (That's Turing-completeness in a nutshell in a very informal way.)
At this point you are going to ask: how can I implement primitive types such as booleans or numbers with functions? - And that's a very good question.

Church encoding

Don't be afraid of this term, it won't hurt.
Church encoding only means to be able to represent data and operators in the lambda calculus.
From another perspective: the guy (Alonzo Church, who had a major impact on modern logic and computation technology) who invented the lambda calculus was not a lunatic when he decided to create the core rules of the language but instead he wanted to create a general language for an investigation where he wanted to determine the foundations of mathematics. So he knew this language should support e.g. addition on two numbers. And - come closer, let me whisper something - it can.
To understand this we have to go a bit abstract.

You are thinking right now: "how could we possibly get the primitive 1 out of only function expressions?". The answer is: we won't.
We are going to go abstract. We are going to call a certain expression 1.
 And with this abstraction we can create a rule set where e.g. addition is going to make sense, so e.g. + 1 = 2. Elementary school flashback, isn't it?
But first, let's look at the most basic primitive element of any programming language: The Booleans. (As I wrote it down it feels like an 80's TV show.)
Think about booleans as a choice.
Let's create a higher-order function where if something is true it is going to return the "first" argument of the function and it returns the second if it's false.
true := (λx.(λy x))
false := (λx.(λy y))
It makes more sense if we define the basic logical operators as well:
and := (λp.(λq. p q) p)
or := (λp.(λq. p p) q)
Let's try a simple operation: (and true false):
(λp.(λq. p q) p) (λx.(λy x)) (λx.(λy y)) := true false true := (λx.(λy x)) false true := false := (λx.(λy y))
BOOM. true AND false = false. Magic.
What is really important here is the result is a function expression as well.

OK. Now we can do some simple logic operations. How about numbers? Addition? Multiplication? ..?
We can do that too! But remember, we only have functions as building blocks, and with these we are going to mimic numbers with functions (or function compositions).
Let's pretend that character "1" is not a number but just a character. Which is the case by the way in lambda calculus since we don't have any other primitive data types than functions.
With this let's define numbers as functions.
The key concept will be the following: if a function is going to compose that function n-times we are going to look at that function as a representation of the number n.
E.g.: f(f(f(x))) /or λf. λx.  f f f x / means it's the number 3. And λf. λx. x means it's the number 0.
0 := (λf. λx. x)
1 := (λf. λx. f x)
2 := (λf. λx. f f x)
3 := (λf. λx. f f f x)
...
n := (λf. λx. f n x)

With this abstraction now we can think about numbers as function expressions.
As we discussed in the previous example at the logical operations let's create  a simple operation on numbers: increment. This is the good ol' fashioned i++; statement. Let's call it succ (as successor).
succ := (λn. λf. λx. f (n f x))
Let's succ 0 for the sake of simplicity:
succ 0 := (λn. λf. λx. f (n f x))(λf. λx. x)
Basically what this means is call f on a function w-hich already called n-times f. f n+1. Easy.
succ 0 := (λn. λf. λx. f (n f x)) (λf. λx. x) = (λf. λx. f ( (λf_. λx_. x_) f x ) ) (λf. λx. f ( (λf_. f_) x ) ) = (λf. λx. f x)
And the result is 1! That's it!
You can imagine now and belive me there is a way to "simulate" all the mathematical operations such as addition, multiplication, exponentiation, etc.. If you're interested, you can find out more here.

This "thinking about natural numbers as they were functions" concept is called Church numerals. I skipped this term on purpose: I didn't want to scare you with formal mathematical words. But that's it, now you know what Church encoding and Church numerals are. Congratulations!

Fun fact the system above only works on natural numbers since if we would go under 0 it would just give us 0. But obviously we can create a system where minus numbers are also included in this game, but I'm not going to cover that topic in this very article. :)

Here is a very good lambda calculator if you would like to play around with lambda expressions: http://www.cburch.com/lambda/

In summary: I find it extremely interesting and fascinating that we can think about data, operations and almost anything else as composition and representation of functions. Nothing else is needed, just plain, simple functions.

Happy Functional Holidays!

2016. szeptember 28., szerda

Game of life with every pixel on a canvas!

Hello everyone!

Long time haven't posted, so here is a new dirty marble of mine: game of life using every pixel on a canvas!
My first thought was: "this is brilliant!", but eventually it turned out it is eating a lot of memory. - But still, it was worth the 2 hours I spent with!

You can learn more about the "game of life" here: https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life .


2016. július 6., szerda

Demistfying co

I always wondered why generator functions are included in the JS language, and still don't see why they are very powerful. However one of the key reasons I still think they are a needed step for the evolution of the language is the use-case of this very article.
I am not going to talk about generator functions or Promises or the Fetch API in this article, but you can read for more information in the links I attached.
The following code snippet is basically what co package does where you can easily do asynchronous calls in a synchronous way. (the key difference here is co can deal with not only Promises, but here we just wanted to work with them, not like e.g. thunks, which co can handle).
Enough with the chit-chat, let's see some code!
The first thing what you should feel here is it has a synchronous feeling when it does something asynchronous. Witchcraft!
Let's see what is happening here (click on "Next" and "Prev" to follow the steps of the control flow)



See the Pen Demistifying co by Adam Nagy (@nagyadam2092) on CodePen.
I think this whole topic is more about to move on to the next generation asynchron call methodology, which is called async-await and thus it is a needed step to be able to build that kind of behaviour.
BTW it's fun to have a look at what an ES6 transpiler is doing with this code-snippet, go on and try it here: https://babeljs.io/repl/
In summary I think we achieved a good (not great) way of handling asynchronous calls with a "synchron-like" feeling.