DEV Community: Mehdi Zed

How to make a wormhole like Stargate SG-1 in JavaScript?

Mehdi Zed — Tue, 21 Sep 2021 18:46:02 +0000

Today we’re going to talk about the effect that impressed the most people in my latest project. A central effect that moved the game’s plot forward. An effect that I forced in front of everyone’s eyes several times because I was so proud of it: the wormhole of Across The Multiverse!

In the previous episode

This article is the direct continuation of last Monday’s article where I explained how I created the whole universe. Yes, yes. A free 3D game in JavaScript in your browser.

A game that just won a prestigious fucking internet award.

Ha I’m proud of my baby.
You don’t know my game yet ?
Here's a 3 minutes trailer to get started.

Anyway, where were we? Oh yes!

How to build a wormhole?

We are at the point in the project where I generate infinite star fields with excellent performance. At this moment, the beautiful game you see in the YouTube video, it looks like this.

Clearly at that point, the possibilities are endless. I have 10,000 ideas per second. So obviously I’m thinking of adding nebulae, galaxies, red giants and everything else that makes up the universe.

And we’ll get to that in the next article.

But I have one particular idea that comes to mind. If I can generate one universe, it means that I can generate several! There is a lot of theory around the multiverse.

Some theories claim that a black hole is in fact a wormhole that leads into another universe.

I am obsessed with this idea!

I have absolutely no idea how to do that. But I know it’s possible to create a wormhole in JavaScript. So I’m going to get started on that right away.

Step 1: I need a visual reference.

As I said in the previous article, I always used a reference image or video. A real representation of what I wanted to recreate. Something to look at to get as close as possible to a “realistic” rendering.

Very quickly, I decide to do the tunnel effect of the stargate SG-1 series again!

It looks pretty complicated, though! Almost too complicated for the knowledge I have at this time. And what do you do when the problem is too complicated?

Reducing complexity

Building a wormhole? Too complicated. I don’t even know where to start. OK, so let’s narrow it down.

Moving the camera in a tube? That means almost nothing to me at this point. You have to build a tube first!

Building an infinite curved tube? Still too complicated, let’s reduce it.

Build a simple tube?

Ha !

That sounds doable to me!

It’s time to get started.

How to build a simple tube?

I immediately think that making a simple tube, in a big library like Three.js., it already exists.

And I am right.

A ready-made geometry object exists and is ready to use. Even better, the code already exists. This means that the first step is what?

A big copy and paste of the code from the doc as we like.

class CustomSinCurve extends THREE.Curve {
    constructor( scale = 1 ) {
        super()
        this.scale = scale
    }

    getPoint( t, optionalTarget = new THREE.Vector3() ) {
        const tx = t * 3 - 1.5
        const ty = Math.sin( 2 * Math.PI * t )
        const tz = 0
        return optionalTarget.set( tx, ty, tz ).multiplyScalar( this.scale )
    }
}

const path = new CustomSinCurve( 10 )
const geometry = new THREE.TubeGeometry( path, 20, 2, 8, false )
const material = new THREE.MeshBasicMaterial( { color: 0x00ff00 } )
const mesh = new THREE.Mesh( geometry, material )
scene.add( mesh )

Now, if we want to continue our wormhole, we have to understand what we just copied and pasted. First, we see a CustomSinCurve class that extends another THREE.curve class.

I understand very quickly that this is the Three.js way to create 3D curves!

It’s very good that I have that in mind at this point in the development of the game. I’m going to use curves a lot in the future. I’m happy and I don’t know yet how important it will be.

In this Custom class, there is a simple constructor and a getPoint function.

I will understand later in detail what this last function corresponds to. I deduce for the moment that it is linked to the curvature of the tube! Indeed, the complicated mathematical model on the three axes (x, y, z) is what allows this shape of the tube.

The rest is just basic Three.js.

I still pay attention to these two lines.

const path = new CustomSinCurve( 10 )
const geometry = new THREE.TubeGeometry( path, 20, 2, 8, false )

Here, I can see that the tube is waiting for a curve to be displayed on the screen. So what? So, it means that we can give our tube the shape we want!

I have my next goal!

How to build an infinite curved tube?

I then cast an eye back to my reference model, the wormhole in Stargate.

It’s a permanent near-curve that goes a bit in every direction. However, it doesn’t do any tight turn madness. Looks like several tortured ellipses.

I decide to keep looking at the doc in search of a geometry that fits what I want.

And bingo.

The TorusKnotGeometry is a perfect candidate for my wormhole shape.

All we have to do is instantiate a TorusKnot, take its shape and add it to our previously made tube!

Easy.

Let’s write this down.

const wormhole = {}
wormhole.shape = new THREE.Curves.TorusKnot(500)
const wormholeMaterial = new THREE.MeshBasicMaterial({
      map: null,
      wireframe: true
})
const wormholeGeometry = new THREE.TubeGeometry(wormhole.shape, 800, 5, 12, true)
const wormholeTubeMesh = new THREE.Mesh( wormholeGeometry, wormholeMaterial )
scene.add(wormholeTubeMesh)

I am very happy with the curve of this tube. You will notice that I managed the infinite side of the tube in the simplest way in the world.

By closing the tube!

const wormholeGeometry = new THREE.TubeGeometry(wormhole.shape, 800, 5, 12, true)

Indeed, the last parameter of TubeGeometry is set to true, which instructs the script behind to join the two ends of the tube.

That’s a quick win!

As a developer, we’re not here to do complicated things, we’re here to respond to needs.

You don’t need to write three kilometers of hieroglyphics to get what you want!

It perfectly meets my needs without taking the headache.

Exactly what we want.

Now, how do we move in there?

How to move the camera in a tube?

The idea is to move the camera forward, inside the tube, with each image. Really, put the user’s eyes inside the tube! Thinking about it, I say to myself that it is enough to update the position of the camera at each image.

Just do it according to the curves of the tube.

And then I remembered the getPoint() function which I didn’t really understand at first.

This function returns the coordinates of the curve according to a given value.

Wait… But isn’t that EXACTLY what we want?

It seems to me that it is.

This said, we will have the right position in time for the camera, but we will not have the right angle. So we will have to force the camera to look forward, permanently. The lookAt function of the camera object will do this for us.

OK, let’s write this down.

let wormhole = {
    CameraPositionIndex: 0,
    speed: 1500
}

function updatePositionInWormhole () {
    wormhole.CameraPositionIndex++

    if (wormhole.CameraPositionIndex > wormhole.speed) {
        wormhole.CameraPositionIndex = 0
    }

    const wormholeCameraPosition = wormhole.shape.getPoint(wormhole.CameraPositionIndex / wormhole.speed)

    camera.position.x = wormholeCameraPosition.x
    camera.position.y = wormholeCameraPosition.y
    camera.position.z = wormholeCameraPosition.z

    camera.lookAt(wormhole.shape.getPoint((wormhole.CameraPositionIndex + 1) / wormhole.speed))

    renderer.render(scene, camera)
}

function animate() {
    updatePositionInWormhole()
    requestAnimationFrame(animate)
}

And it works!

We have a beautiful trip in roller coaster mode in a tube.

The hardest part is behind us, now it’s just dressing up.

And the little trick to make something pretty is to put several materials with different textures. Then you play with GSAP for the opacity and the order of appearance of the materials. You can get sublime things by playing with all this.

this.wormholeTubeMesh = SceneUtils.createMultiMaterialObject(this.wormholeGeometry, [
      this.wireframedStarsSpeederMaterial,
      this.auraSpeederMaterial,
      this.nebulaSpeederMaterial,
      this.starsSpeederMaterial,
      this.clusterSpeederMaterial
])

 async animate () {
    this.wormholeTimeline = gsap.timeline()

    // initial massive boost at wormhole enter
    this.wormholeTimeline
      .to(this.starsSpeederMaterial, { duration: 7, opacity: 1 }, 0)
      .to(this.wireframedStarsSpeederMaterial, { duration: 7, ease: 'expo.out', opacity: 1 }, 0)
      .to(this.auraSpeederMaterial, { duration: 7, ease: 'expo.out', opacity: 1 }, 0)
      .to(window.wormhole, { duration: 7, ease: 'expo.out', speed: 2500 }, 0)

    // adding speed and noises
    this.wormholeTimeline
      .to(this.clusterSpeederMaterial, { duration: 6, opacity: 1 }, 7)
      .to(this.auraSpeederMaterial, { duration: 2, opacity: 0 }, 7)
      .to(window.wormhole, { duration: 6, speed: 2000 }, 7)

    // adding speed and nebula distorded
    this.wormholeTimeline
      .to(this.nebulaSpeederMaterial, { duration: 6, opacity: 1 }, 13)
      .to(this.clusterSpeederMaterial, { duration: 6, opacity: 0 }, 13)
      .to(this.auraSpeederMaterial, { duration: 6, opacity: 0.7 }, 13)
      .to(window.wormhole, { duration: 6, speed: 1800 }, 13)

    if (!window.isMobileOrTabletFlag) {
      window.controls.velocity.x = 0
      window.controls.velocity.z = 0
    }

    return this.wormholeTimeline.then(() => true)
  }

As said in the previous article, for the sake of length and simplification, sometimes I don’t explain everything. And especially, I don’t show everything. This is the case for this part where it’s just a presentation and not pure logic.

You have the full source code if you want to see everything.

And more precisely the wormhole class is here.

Epilogue

And here we have a perfect wormhole. Very good performance and very pretty! We are ready to go from universe to universe with this. In the next article, we will see how to create nebulae and more particularly supernova remnants!

I built the entire universe in JavaScript

Mehdi Zed — Mon, 13 Sep 2021 12:31:20 +0000

It’s not a clickbait title. I really did it. And it’s not just a web experience. No. It’s a real game, freely explorable, in 3D, right in your browser ! Don’t you believe me ?

TLDR

Ho, i know your time is precious. Here’s the condensed version.

I built a free 3D browser game, freely explorable, across infinite universes procedurally generated in JavaScript. The goal? Go from universe to universe and discover the origin of everything.

It’s a four chapter story with an epic reveal at the end.

Before going further in reading this article, stop everything, put yourself in full screen, take some popcorn and play ACROSS THE MULTIVERSE !

No time to play?

You prefer to enjoy it on a PC and not on a mobile phone ?

Or do you just want to see more before playing it?

I got you.

I made a launch trailer on YouTube! It’s only 3 minutes long. It shows a lot of things.

But beware, it’s extremely spectacular!

I put a lot of my time, my soul and my skills in the creation of this free game for the internet.

If you have five seconds to share it, that would be wonderful.

// Detect dark theme var iframe = document.getElementById('tweet-1437333985223450635-37'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1437333985223450635&theme=dark" }

Meanwhile, it’s time to talk about the flashing elephant in the middle of the room.

How the fuck i did that?

Talk is cheap. Show me the code

I know that many of you prefer to dive right into the code. Even before reading my beautiful explanations. And I totally understand this.

For the most impatient, here is the full source code of the game.

jesuisundev / acrossthemultiverse

An in-browser, freely explorable, 3D game across infinite universes procedurally generated. Go from universe to universe and discover the origin of everything. A four chapter story with an epic revelation at the end.

Across The Multiverse

An in-browser, freely explorable, 3D game across infinite universes procedurally generated Go from universe to universe and discover the origin of everything A four chapter story with an epic revelation at the end.

https://across-multiverse.com/

A blog post explaining how everything works is available here !

License

Source Code

Under BSD 3-Clause License.

Music

All musics are owned by artists (see list below) and are used here under Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0) license

You can't use the musics for commercial use and/or without mentioning the following artists

Transcendent - Joel Nielsen
I Walk With Ghosts - Scott Buckley
Discovery - Scott Buckley
Celestial - Scott Buckley
Omega - Scott Buckley
Into the Night - Melodysheep

Footage

Under Attribution 4.0 International (CC BY 4.0)

You can use footage of the game for any use but you must mention this project with the following link : https://across-multiverse.com/

…

View on GitHub

It is of course open source under MIT license (for the code).

I still recommend following the story of the project’s gradual creation via this article. It will give more context. And most importantly make a lot more sense.

How to build the universe?

Before I even start, you should know that I use the Three.js JavaScript library. This library allows you to use the WebGL api via JavaScript to do 3D rendering in the browser.

It It is possible that you don’t understand the sentence before and/or that you don’t know Three.js.
Fortunately I thought of everyone.

I made an article dedicated to Three.js and 3D rendering in JavaScript.

This article will allow you to immediately understand the basis of the project in only 5 minutes.

Anyway, back to the point.

How to build the universe?

Clearly the problem is too big.

I couldn’t tackle this problem head on. And that’s not how you do it when you’re a developer. There is only one reflex to have when faced with a huge and complex problem.

Reducing complexity

Building the universe? Too complicated. I don’t even know where to start. Okay, then let’s narrow it down.

Building the Milky Way? Still too complicated, let’s reduce it.

Building our solar system? No. It’s too complicated. Let’s reduce it.

Building an empty space filled with stars?

Ha! That sounds doable! A simple starfield in the darkness of space.

Thinking about it a little bit, I think this problem is really simple. That means I’ve reduced the complexity enough.

It’s time to get started.

How to build a simple starfield?

From then on, I always used a reference image. A photo or a real representation of what I wanted to recreate. An image to look at to get as close as possible to a realistic rendering.

For the starfield, I had decided to take a picture from the Hubble satellite.

I figure I just need to display random white dots in a black space.

It is very easy.

Let’s start by creating an empty, black space and put a camera in it.

const scene = new THREE.Scene()
const renderer = new THREE.WebGLRenderer({ powerPreference: "high-performance", antialias: false, stencil: false, depth: false })
renderer.setSize(window.innerWidth, window.innerHeight)
renderer.setClearColor(0xffffff, 0)
renderer.domElement.id = 'starfield'
document.body.appendChild(renderer.domElement)
const camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000)
camera.position.set(0, 10, 0)
camera.lookAt(0, 0, 0)
function animate(time) {
    renderer.render(scene, camera)
    requestAnimationFrame(animate)
}
animate()

OKAY. Great stuff. All this to display a black screen?!

Yes. Let’s be patient. We have to start somewhere.

Now, harder.

Let’s display white dots randomly in this black space. Can you do it? I didn’t know how. So I look at to the documentation.

And i fount it !

There is a class dedicated to this : Points.

Perfect, let’s follow the doc and write this down.

function getStarsGeometry() {
    const geometry = new THREE.BufferGeometry()
    geometry.setAttribute('position', new THREE.Float32BufferAttribute(getStarsRandomVertices(), 3))
    return geometry
}
function getStarsRandomVertices(verticesNumber = 10000) {
    const vertices = []
    for (let i = 0; i < verticesNumber; i++) {
        const x = 2000 * Math.random() - 1000;
        const y = 2000 * Math.random() - 1000;
        const z = 2000 * Math.random() - 1000;
        vertices.push(x, y, z);
    }
    return vertices
}
function getStarsMaterial() {
    const starSprite = new THREE.TextureLoader().load('../images/star.png');
    const starMaterial = new THREE.PointsMaterial({ size: 5, sizeAttenuation: true, map: starSprite, alphaTest: 0.5, transparent: true });
    return starMaterial
}
function getStars() {
    const stars = new THREE.Points(getStarsGeometry(), getStarsMaterial())
    return stars
}
scene.add(getStars())

In this piece of code, what will really do the magic is the getStarsRandomVertices function.

Our starfield (here represented by new THREE.Points) needs two things.

1 : The coordinates of each point to be displayed
2 : The material of each of the points. That is to say what we will display (to simplify) for each of the points.

The coordinates are managed by getStarsRandomVertices.

Our camera is placed at coordinates 0,0,0. We want stars all around us. So our points should be placed between the coordinates -1000 and 1000. All around us.

To do this, we will do a simple calculation.

2000 * Math.random() – 1000

This very simple piece of math gives us a random value (math.random is not really random but let’s admit it) between -1000 and 1000. We put this calculation in each axis (x, y, z) and that’s it!

The material is managed by getStarsMaterial

Not much to say here. We’ll just use an image of a white circle as a texture and apply it. For the moment we don’t need much.

We put the two together in the getStars function and we have solved our problem.

Well, for the moment it just gives an image with static white dots in 2D.

It’s kind of lame. We can do better.

It’s time to iterate on this result.

Improvement via iteration

Let’s just start by bringing things to life.

The idea right now is to just move the camera in relation to the movement of the mouse. When I did that, I just wanted to make sure I was aware that I was doing 3D now.

Let’s write this down.

document.body.addEventListener('pointermove', onPointerMove);
function onPointerMove(event) {
    if (event.isPrimary === false) return
    mouseX = event.clientX - windowHalfX
    mouseY = event.clientY - windowHalfY
}
function animate(time) {
    renderer.render(scene, camera)
    camera.position.x += (mouseX - camera.position.x) * 0.05
    camera.position.y += (-mouseY - camera.position.y) * 0.05
    requestAnimationFrame(animate)
}

OK it’s cool, it moves, it’s 3D, we are happy.

Now let’s make it even more interactive. What I’d like to do is walk around in there. Freely. Like in an FPS game, with the mouse and the keyboard.

At that point, I had two choices:

Either I rewrote a whole FPS navigation system myself.
Either I took a FPS control class already made by Three.js.

I obviously chose to use the code already done.

It is tested and used by many people. I advise you to do the same thing when this situation happens to you. Unless you are in a learning process, there is no point in reinventing the wheel.

However, the features offered by the module were not enough for me.

I wanted more.

I wanted a velocity system. Give the players that feeling of acceleration and deceleration. So I had to use the existing module and extend those possibilities in my own class.

OK, let’s write this down.

import { PointerLockControls } from './PointerLockControls.js'
import * as THREE from 'three'

export default class Controls {
  constructor (camera, parameters) {
    this.parameters = parameters
    this.camera = camera
    this.pointerLockControls = new PointerLockControls(this.camera, document.body)

    this.velocity = new THREE.Vector3()
    this.direction = new THREE.Vector3()

    this.moveForward = false
    this.moveBackward = false
    this.moveLeft = false
    this.moveRight = false
  }

  onKeyDown (event) {
    if (this.pointerLockControls.isLocked) {
      switch (event.code) {
        case 'ArrowUp':
        case 'KeyW':
        case 'KeyZ':
          this.moveForward = true
          break
        case 'ArrowLeft':
        case 'KeyA':
        case 'KeyQ':
          this.moveLeft = true
          break
        case 'ArrowDown':
        case 'KeyS':
          this.moveBackward = true
          break
        case 'ArrowRight':
        case 'KeyD':
          this.moveRight = true
          break
      }
    }
  }

  onKeyUp (event) {
    if (this.pointerLockControls.isLocked) {
      switch (event.code) {
        case 'ArrowUp':
        case 'KeyW':
        case 'KeyZ':
          this.moveForward = false
          break
        case 'ArrowLeft':
        case 'KeyA':
        case 'KeyQ':
          this.moveLeft = false
          break
        case 'ArrowDown':
        case 'KeyS':
          this.moveBackward = false
          break
        case 'ArrowRight':
        case 'KeyD':
          this.moveRight = false
          break
      }
    }
  }


  handleMovements (timePerf, prevTimePerf) {
    const delta = timePerf - prevTimePerf

    this.direction.z = Number(this.moveForward) - Number(this.moveBackward)
    this.direction.x = Number(this.moveRight) - Number(this.moveLeft)

    if (this.moveForward || this.moveBackward) {
      this.velocity.z -= this.direction.z * this.parameters.controls.velocity * delta
    }

    if (this.moveLeft || this.moveRight) {
      this.velocity.x -= this.direction.x * this.parameters.controls.velocity * delta
    }

    this.pointerLockControls.moveRight(-this.velocity.x * delta)
    this.pointerLockControls.moveForward(-this.velocity.z * delta)
  }
}

And just like that, we built a starfield that can be explored like in a FPS.

Here you go, I’ll put a codesandbox, you can play live in it.

You just have to click in the stars to switch to FPS mode.

Not bad, right?

It’s not bad.

But it’s time to get down to business.

How to simulate infinity?

So far we have just placed dots around the player. But all he has to do is move a little bit and he sees the trickery. It’s a bit lame again.

So how do we get this scaled?

How do you do it in a way that makes sense?

And above all, how do you do it without blowing up the memory and/or without going below 60FPS.

Now the real project begins.

The grid

** At that point, I stopped touching my keyboard.**

To code a solution for this kind of problem, you can’t “feel your way to it”. No. You have to solve the problem conceptually -on paper- before doing anything.

Otherwise you are wasting your time.

And I hate wasting my time.

It’s time to make drawings.

One of the first ideas that came to mind was the concept of a grid to represent space.

Concretely, the space would be an infinite grid. The player would go from square to square to see what it contains. And in each square you put what you want.

Stars, nebulae, galaxies, suns, black holes, whatever you want!

To better understand what I’m talking about, I’ll draw you a little picture.

Solve the problem

Let’s start by representing our existing code. Right now, we have our player in the original 0,0,0 square, surrounded by stars. If he moves away a little he is in complete darkness.

Conceptually, it looks like this.

The little dude represents our player.
The blue stars represent the points already randomly placed around him.
The numbers in red are the coordinates of each square in space.

So far, nothing complex.

And that’s the goal! I want to keep it simple at all costs. It’s complex to keep it simple. Let’s try to keep it simple in the algorithm for updating the grid.

We need two main functions.

The initialization function.

This function will create the material in the original square and in all the squares around the player.

The advantage of the initialization phase is that you can afford expensive actions. As long as the player is not in a gameplay phase, you are quite free.

Conceptually, it looks like this.

The green stars represent the points dynamically created by the initialization function

The update function.

This function will update the grid only when the player crosses the border between two squares.

With this function we want two things:

Delete the content of the squares which are too far from the player
Create the content of the squares where the player is most likely to go
Conceptually, it would look like this.
The blue stars represent the points already placed
The green stars represent the points we create dynamically
The red stars represent the points that are deleted

And just like that, we managed the infinity simulation.

The player can go anywhere he wants. In the direction and the way he wants. He will not see the trickery. Wherever he goes, there will be wonderful things to look at.

I like this solution because it has several advantages.

It is relatively efficient

The fact that the contents of the squares are created on the fly and, above all, that they are deleted at the same time, relieves the memory a lot. In addition, only the minimum number of squares necessary is created each time.

We don’t have to manage the player’s direction

No matter which direction the player is going, the algorithm will be the same. Indeed, we don’t need to know what are the squares in front of the player. We just want to know which squares around the player are empty ! So he can go in the direction he wants, our algorithm will do exactly the same thing.

It’s easy to manage

No need for a data structure straight from hell like a graph or a tree like an octree. No, no. Fuck that, leave me alone. One array, two hashmaps and that’s enough. No headaches. Keep it simple.

Well, let’s write this down.

Coding the solution

We are going to create this famous class which will manage the grid. For the sake of length and simplification, I don’t explain everything. And above all, I don’t show everything.

You have the full source code if you want to see everything.

We’re just looking at the important parts today.

import MultiverseFactory from '../procedural/MultiverseFactory'

export default class Grid {
  constructor (camera, parameters, scene, library) {
    this.camera = camera
    this.parameters = parameters
    this.scene = scene
    this.library = library
    this.activeClusters = new Map()
    this.queueClusters = new Map()

    this.multiverseFactory = new MultiverseFactory(this.scene, this.library, this.parameters)
  }

  getCurrentClusterPosition () {
    const currentCameraPosition = this.getCurrentCameraPosition()
    const xCoordinate = Math.trunc(currentCameraPosition.x / this.parameters.grid.clusterSize)
    const yCoordinate = Math.trunc(currentCameraPosition.y / this.parameters.grid.clusterSize)
    const zCoordinate = Math.trunc(currentCameraPosition.z / this.parameters.grid.clusterSize)
    const currentClusterPosition = `${xCoordinate},${yCoordinate},${zCoordinate}`

    return currentClusterPosition
  }

  getCurrentCameraPosition () {
    this.camera.updateMatrixWorld()

    return this.camera.position
  }

  getClustersStatus (currentCluster) {
    const clustersNeighbour = this.getNeighbourClusters(currentCluster)
    const clustersToPopulate = this._getEmptyClustersToPopulate(clustersNeighbour)
    const clustersToDispose = this._getPopulatedClustersToDispose(clustersNeighbour, currentCluster)

    return {
      clustersNeighbour,
      clustersToPopulate,
      clustersToDispose
    }
  }

  getNeighbourClusters (currentCluster) {
    const neighbourClusters = [currentCluster]
    const currentClusterArray = currentCluster.split(',')
    const x = currentClusterArray[0]
    const y = currentClusterArray[1]
    const z = currentClusterArray[2]

    // forward
    neighbourClusters.push(`${x},${y},${Number(z) - 1}`)

    // backward
    neighbourClusters.push(`${x},${y},${Number(z) + 1}`)

    // right
    neighbourClusters.push(`${Number(x) + 1},${y},${z}`)

    // left
    neighbourClusters.push(`${Number(x) - 1},${y},${z}`)

    // forward right
    neighbourClusters.push(`${Number(x) + 1},${y},${Number(z) - 1}`)

    // forward left
    neighbourClusters.push(`${Number(x) - 1},${y},${Number(z) - 1}`)

    // backward right
    neighbourClusters.push(`${Number(x) + 1},${y},${Number(z) + 1}`)

    // backward left
    neighbourClusters.push(`${Number(x) - 1},${y},${Number(z) + 1}`)

    return neighbourClusters
  }

  disposeClusters (clustersToDispose) {
    for (const clusterToDispose of clustersToDispose) {
      let matter = this.activeClusters.get(clusterToDispose)

      matter.dispose()
      matter = null

      this.activeClusters.delete(clusterToDispose)
    }
  }

  addMattersToClustersQueue (matters, type = 'starfield', subtype = null) {
    for (const clusterToPopulate of Object.keys(matters)) {
      this.queueClusters.set(clusterToPopulate, {
        type: type,
        subtype: subtype,
        data: matters[clusterToPopulate]
      })
    }
  }

  populateNewUniverse () {
    const clusterStatus = this.getClustersStatus('0,0,0')

    this.buildMatters(clusterStatus.clustersToPopulate)
  }


  renderMatters (position, cluster) {
    const matter = this.multiverseFactory.createMatter(cluster.type)

    matter.generate(cluster.data, position, cluster.subtype)
    matter.show()

    this.queueClusters.delete(position)
    this.activeClusters.set(position, matter)
  }

  _getEmptyClustersToPopulate (neighbourClusters) {
    const emptyClustersToPopulate = []

    for (const neighbourCluster of neighbourClusters) {
      if (!this.activeClusters.has(neighbourCluster)) {
        emptyClustersToPopulate.push(neighbourCluster)
      }
    }

    return emptyClustersToPopulate
  }

  _getPopulatedClustersToDispose (neighbourClusters, currentCluster) {
    const populatedClustersToDispose = []

    for (const activeClusterKey of this.activeClusters.keys()) {
      if (currentCluster !== activeClusterKey && !neighbourClusters.includes(activeClusterKey)) {
        populatedClustersToDispose.push(activeClusterKey)
      }
    }

    return populatedClustersToDispose
  }
}

And it works!

The contents of the boxes are added on the fly as the player approaches. The illusion is almost perfect. I say almost because unfortunately we have a big problem.

I know it doesn’t show much in the video.

The performances when updating the grid are disastrous.

It freezes the image, it’s just disgusting and unplayable as is.

It is therefore time to diagnose and optimize.

Diagnose & Optimize

When a performance problem occurs in an application, the first reflex is to diagnose before doing anything.

Diagnose

In the case of a web application like ours, we will do this with the chrome dev tools. F12, tab “Performance” then CTRL+E to record what happens. Then we use the application normally before stopping the recording and analyzing the results.

By doing this, I quickly understood what was going on.

We have big FPS drops because we try to do too many things at the same time.

We do too many things for JavaScript. JavaScript being single-threaded, it is not forgiving. Too much is required, in too little time, for a single thread.

Remember the simple calculation I told you about at the beginning?

2000 * Math.random() – 1000

We do this 300,000 times for each stars. In one frame.

Multiply by 3 for each axis (x, y x) of the coordinates.

Again multiplied by 3 for the three new squares that are created each time the player moves from square to square.

And right now, we’re just doing simple math for starfield. When we’ll create nebulae or galaxies later, the math will be much more intensive.

It’s expensive. Very expensive. So expensive that we exceed the limit of 16ms allowed per frame for a fluid image. We go up to 33ms. It blocks the event loop, it freezes the image and it becomes unplayable.

If we leave it like that, our player will also leave the game in 33ms.

Optimize

To avoid this, I have two solutions.

First, we will free ourselves from the single thread limit of JavaScript.

We will do it using the Web Workers of the browser. I’m not going to do a lecture on this, it’s very well known, and the MDN page is extremely well done to understand them.

Concretely, we will send to Web Workers all the heavy calculations of the game.

These calculations will then be done in the background, by the browser. The goal is not to disturb our main thread. It must be in charge of only one thing: displaying things in a fluid way to the players.

Once the heavy calculations are done, the Web Workers return the results in events. Our main thread just has to display them !

// in worker.js

self.onmessage = messageEvent => {
  const heavyMath = _getHeavyMath()

  self.postMessage(heavyMath)
}

function _getHeavyMath () {
  const positions = []
  const colors = []

  // heavy math to process positions and colors of particles

  return {
    positions: new Float32Array(positions),
    colors: new Float32Array(colors)
  }
}


// in main.js

worker.onmessage = messageEvent => this.showData(messageEvent.data)

And just like that, we divide the load by ten!

But that’s not enough. In order to have excellent performances, we will relieve the event loop a little more.

Secondly, we are going to spread out the display phases of the squares in time.

As it is, the heavy calculations are well done in the web workers. But it is very possible that the display of the three squares are requested at exactly the same time. We want to avoid this to have a perfectly smooth image.

To do this, we will use a little trick.

We will allow only one display of star fields at the same time via a boolean. Then we will spread out in time the display phases of each square via a setTimeout. This means that the display of each square will not be instantaneous. It will be spaced out by 50ms. One by one.

50ms is huge in terms of relief for the event loop.

And it is imperceptible to the player.

Exactly what we need.

isRenderingClusterInProgress = true

const clusterTorender = grid.queueClusters.keys().next().value

setTimeout(() => {
  grid.renderMatters(clusterTorender, 
  grid.queueClusters.get(clusterTorender))
  isRenderingClusterInProgress = false
}, parameters.global.clusterRenderTimeOut)

Et voilà !

Infinite starfields in your browser.

Isn’t life beautiful?

And the rest?

If you have played the game and/or seen the trailer, you can see that 90% of the content is missing in this article.

Nebulae, suns, black holes, red giants, fucking wormholes between universes, four different universes and the incredible finale!

Yes, it is. But this project is huge. Too huge to be written about in one article.

A lot of articles (at least four) on the subject is coming. We’ll take a look at each of the topics to talk about them.

How to build Nebulae in JavaScript ?
How to build Red Giant in JavaScript ?
How to build Black Hole in JavaScript ?
How to build Worm Hole in Javascript ?

So stay tuned folks !

I’m just getting started.

Epilogue

It was the biggest personal project I’ve ever done. It was incredible to do. There were ups, downs, distress and wonder. I’ll let you enjoy the game. I’m not sure I’ll be doing a project this big again anytime soon.

Please share it with others. It would mean a lot to me.

I’m going to get some sleep now.

Javascript: what I didn't understand

Mehdi Zed — Sat, 17 Apr 2021 15:55:00 +0000

Javascript is one of the most accessible languages. But between those who use it and those who master it, there is a clear difference. Javascript is full of nuances, fuzzy behaviors and hidden concepts. It'll drive you crazy if you don't know them.

The Javascript trap

A long time ago, in a galaxy far, far away, I arrived in a new team. Behind me, a strong PHP specialization. This day was important. I gave up my PHP religion to join a team of Javascript religion.

At this point, I am convinced of two things. Javascript is easy and I already mastered it perfectly. No need to really understand how the bowels of the language work to use it. It's going to be fine.

But soon I began to see some disturbing things on the horizon. I came across code, concepts and terms that were completely opaque. I didn't get worried right away. It was quite far from my area of intervention.

I should have worried right away.

A few weeks later, my first big mission in the team fell on my desk.

The entire rewriting of a hinge service for the product.

Without going into details, we can compare this service to a kind of CDN. The client sends a ZIP file, my service has to manage a lot of things. On-the-fly file extraction with recursion (zip in zip), upload, caching, static file service, versioning, metadata. All this while keeping 100% of calls under 200ms.

Doing this kind of thing correctly requires an internal understanding of how Javascript works. I didn't know that yet. I was about to suffer in front of mistakes and incomprehensible behaviors.

The Javascript trap had just closed on me.

On the surface, Javascript is very accessible and you quickly do wonders with it. A superficial knowledge of internal mechanics is often sufficient. Hence the number of people who use it without really knowing what they are doing.

But when you end up tackling more complex things, you're quickly lost, and your impostor syndrome begins to stare you intensely.

Unknown variables

Before I tell you about what drove me crazy when I started this service, let's go back a few years. Like many people, I learned Javascript on the job. I had to do it so I started doing it.

As required by the time, I write jQuery. I thought i was a god at it. I managed to do everything that was asked of me. In spite of what I was thinking, from time to time I got some big slaps in the face.

Simple things don't work. It bugs for no reason. And strangely enough, the fact that I'm banging my keyboard hard doesn't solve the problem.

My problems came from the first thing I didn't understand with Javascript: the internal workings of variables and types.

To understand what i'm talking about, let's look at some code.

*What will this code display and why?*

const originalEzio = {
  "name": "ezio Auditore da Firenze",
  "weapon": "Hidden Blade",
  "metadata": {
    "version": "Original",
    "type": "Assassin"
  }
};

originalEzio.name[0] = 'E';

function getHeroCopy(originalHero) {
  let copyHero = {
    name: originalHero.name,
    weapon: originalHero.weapon,
    metadata: originalHero.metadata
  };

  copyHero.metadata.version = 'Copy';

  return copyHero;
}

const copyOfEzio = getHeroCopy(originalEzio);

console.log('Original : ', originalEzio);
console.log('Copy : ', copyOfEzio);

Yes, I know, it's look like a stupid Javascript trivia question. But please, play the game, take the time to predict what it will display.

Let's check your prediction by pressing play on the Repl just below.

If you can't explain this result, you're missing something in the foundations of language. A short explanation in a few words.

Variables are divided into two main categories: primitives and complexes.

Primitives (string, number, boolean, …) point to unique values.

They are immutable. Hence the fact that the string does not change (line 10). By the way, if you add "use strict" at the beginning of the file, it throws immediately. In strict world, Javascript does not allow this devilry.

Complexes (object, …) point to value references.

They are mutable. Line 16, I refer to the metadata object of the original hero and assign it to the metadata object of the copy. By changing the copy, I therefore change the reference of the original.

When I started, I didn't have these notions. And believe me, it's no fun not having them. A lot of people don't have them.

The goal today is not to give you a lesson. The goal is to point out the pitfalls I've encountered. To make sure that you avoid them.

I have a recommendation for you at the end of the article to understand and overcome all these pitfalls.

But before that, let's continue to point out the places where I wallowed.

What the fuck is this

For the rewriting of the service, I was helped by many internal and external library. Some more recent than others. Some better done than others. They used all the object dimension of Javascript.

Or more precisely, prototype oriented programming, an incomplete form of object programming.

Even today, despite the syntactic sugar of the classes, it is still prototypes. Javascript is not really an object-language. See you on twitter for some fight those who disagree.

// what you use
class Assassin {
  constructor(name) {
    this.name = name;
  }

  getCreed() {
    return "Nothing is true, everything is permitted.";
  }
}

//---------------

// what JS really does behind
function Assassin(name){
  this.name = name;
}

Assassin.prototype.getCreed = function() {
  return "Nothing is true, everything is permitted.";
}

In short, I got to know the contexts in Javascript. With these schizophrenic perimeter rules. I immediately started using my head to smash my keyboard.

Again, a annoying trivia question.

***What will this code display and why?***


const altair = {
  name: "Altaïr Ibn-La'Ahad",
  templarsKilled: ['Tamir', 'Talal', 'Sibrand'],
  showTemplarsKilled: function() {
    console.log(`List of templar killed (${this.templarsKilled.length}) by ${this.name}`)

    this.templarsKilled.forEach(function(templarKilled) {
      console.log(`${this.name} killed ${templarKilled}`)
    });
  }
};

altair.showTemplarsKilled();

You can check your prediction with the Repl just below.

Why doesn't the second log (line 8) work? Why does the first log (line 5) work? Why using an arrow function (line 7) solves the problem?

If you are not able to answer these questions, it is because the famous (this) Javascript context is blurred for you. And that's understandable. In Javascript, the context doesn't behave at all like in other languages.

We're dealing with a monster.

In theory, "this" represents the context of the function. An object associated with the invocation of the function. Except that it is not so simple. In truth, it will be determined according to how it is called.

Let's look at some examples.

Call in a function, the context will be the global object. If you don't know it, you tragically change the global object. This is evil.

this.creed = "Nothing is true, everything is permitted.";

function showCreed() {
    console.log(this.creed)
}

showCreed();

Except in strict mode. In strict mode it is undefined. You don't know it, this time everything goes wrong.

"use strict"

this.creed = "Nothing is true, everything is permitted.";

function showCreed() {
    console.log(this)
}

showCreed(); // undefined

Call in method of a function, the context will be the object in question, as we want. This is why the "showTemplarsKilled" function above works. But not the next nested function. The next one has its own context.

showTemplarsKilled: function() {
    // this -> objet context
    console.log(`List of templar killed (${this.templarsKilled.length}) by ${this.name}`)

    this.templarsKilled.forEach(function(templarKilled) {
      // this -> function context
      console.log(`${this.name} killed ${templarKilled}`)
    });
}

I don't know if you've ever seen code create variables like "self" or "_this" that passed the current context? That's exactly why. A relatively disgusting hack to keep the current context.

showTemplarsKilled: function() {
    const self = this;
    console.log(`List of templar killed (${self.templarsKilled.length}) by ${self.name}`)

    self.templarsKilled.forEach(function(templarKilled) {
      console.log(`${self.name} killed ${templarKilled}`)
    });
  }

Today, the most elegant way is to use an arrow function. In addition to making our code more readable and shorter, it passes the current context to the called function. Neat.

showTemplarsKilled: function() {
    console.log(`List of templar killed (${this.templarsKilled.length}) by ${this.name}`)

    this.templarsKilled.forEach(templarKilled => console.log(`${this.name} killed ${templarKilled}`));
  }

I'm telling you I don't want to lecture, but I'm throwing myself into explanations anyway. Please stop me when I start going off all over the place like that.

Anyway, while I was doing this famous service, I was far from suspecting all this. And all these rules of context depending on where and how you call out made me freak out.

It made the speed and quality of what I was producing … let's say questionable. The first few weeks on it were laborious. And even if that wasn't true, I had the impression that my team was beginning to doubt what I could bring to the table.

With a lot of (too much) time and pain, I gradually managed, module by module, to produce something. However, this was just the beginning of my discoveries. I was not at the end of my pains.

Deployment

I'll pass the various adventures on the road, let's go straight to the deployment. At that point I am convinced that my stuff is working. I have 3 million tests. It's been running on dev for a week. I would have gladly bet an arm and two legs.

Monday morning, I finally deploy the service, it works perfectly.

But as the day went by, the more users were gradually using the new version, the more I saw the response time increase worryingly. In the middle of the afternoon, the first email from a customer arrives in my inbox.

This is clearly related to my service.

But even when i was looking precisely at the slow code, I didn't understand. The response times kept getting longer and longer. I was more and more in the fog.

It wasn't a big mistake It was a collection of subtle little errors that slowed down my application. Let's take a closer look at one of them. I promise, last interview question, then I'll leave you alone.

What's wrong with the following code?

function _load (assetFile, assetRoute) {
  return this.cdn.getFileInfo(assetFile)

  .then(assetInfo => this.setAssetInCache(JSON.Stringify(assetFile), assetInfo))

  .then(() => this.getAssetFromCache(assetRoute))

  .then(data => {
    if (data) {
      return Promise.resolve(data)
    } else {
      return Promise.reject("Can't get asset from cache.")
    }
  })

  .catch(error => Promise.reject(error))
}

The problem is line 5 with the use of JSON.stringify. This is a blocking operation. In a non-blocking asynchronous world, you have to be very careful with this kind of thing.

JSON.stringify blocks the thread it is in. Since Javascript is single thread, this is problematic. So yes, the promise gives a delay to the blocking. But when the stringify executes, nothing executes until it's finished.

Thus blocking all the rest of the application.

Most of the time, stringify is not a problem. What needs to be stringified is so small that the function is done almost instantaneously. Except that here, thousands of files -more or less large- are processed simultaneously.

Millisecond by millisecond, the response time went up to 1 second per call!

The more users used the application, the more it was an ordeal for everyone.

That's the day I really started to get interested in the event loop.

How it works, what is at stake, the different phases. From timers to close callback to I/O polling. It was going to be very useful on NodeJS. But also on javascript in a general way in the browser.

So, it is important to know that even if the global functioning of the event loop in the browser and in NodeJS is the same, there are differences when zooming. I say this because you will always have a self-proclaimed "expert" to correct you -in an unbearable way- as if it was important.

Anyway, with a little time and crying a little blood, I ended up correcting all the incriminated places. The response time went under 200 ms. And I thought I was done learning the hard way.

Breaking point

A few weeks later, I attended a meeting with my colleagues. It was an important meeting where I was going to discuss technical issues. A new service was planned.

This meeting was going to be the breaking point that would really push me to act.

I hardly mentioned the meeting. Despite my learning about the service, it wasn't enough to keep up. Concepts and technical terms were flying around.

Following the discussion was becoming more and more complicated. Participating in it without saying anything stupid, even more so. It was about closures, generators, the risk of memory leaks and using proxies for advanced monitoring.

None of this was clear in my head. It was time to act to get out of this fog.

Raising your game

When I returned to my post after the meeting, I took my courage in both hands. I asked one of my colleagues for clarification on the content of the meeting. The discussion quickly turned around a book he had read.

My recommendation of the day : Secrets of the Javascript Ninja.

This book is the starting point of all my confidence with Javascript.

By explaining me deeply the internal workings, the behaviors on the surface have become clear. My code became fast and robust. The interview trap questions were easy.

It starts very softly with what happens in the browser with Javascript. Then, he quickly gets to the heart of the matter with the functions. Understanding -really- how they work changes everything.

Then the incredible part about the closures and the functioning of the lexical fields which was a revelation for me.

Then, generators, promises and prototypes. Finally, it ends with a deep dive into the holy event loop that I FINALLY understood. I came out of this book with a clear vision. Ready to fight.

So let's be clear. I have always been very honest with my recommendations. This book is not an easy read.

It's not for you if you're just starting Javascript. There are complex moments where I had to think more, read, reread and look at the diagrams to really get it. But that's what this book is all about.

This book is for those who have been using Javascript for some time and want to raise their game. It is for those who want to dominate this language. It is for those who want to create an expertise.

If it were that simple, everyone would be an expert. This book pushes you into the fog to get you out of it. There is no evolution without friction.

Epilogue

Like many people, I fell into the Javascript trap thinking it was an "easy" language. All my mistakes and painful moments could have been avoided by taking seriously the language learning process beforehand. It's up to you to see if you want to take the risk.

8 developer habits that help you progress

Mehdi Zed — Sat, 10 Apr 2021 02:07:29 +0000

Over time, I came to understand that one of the most important thing as a developer are habits. All the little decisions, the ways of doing things, the way you look at things. It may not seem like much from a day to day point of view. This is the secret for greatness.

Going into the unknown

Let's be honest, I haven't always done this. I was not that kind of person. I would take the task made for me. With my go-to language, on the part of the app that I know perfectly. I knew exactly what i needed to do before I even looked at it. Choosing the easy way, when it becomes a habit, is very dangerous.

One day, I decided I was going to do the opposite. As soon as the opportunity arises to do something totally unknown, I'll jump on it. And the first time I finally did it, it was a disaster !

The time estimate ? I blew it up. It was a task estimated for one day or two. Took the whole week ! My company at that time was not happy. Me neither. But something more important happened. Something that seemed impossible and out of reach for me became commonplace. And this alone changed everything.

If you take the habit of getting into uncomfortable situations all the time, nothing will be uncomfortable anymore. If you get out of your comfort zone, you'll stretch it out. And doing it frequently will gradually make you feel better all the time. You really win when the uncomfortable becomes your new norm. It's a lot easier than it sounds.

What I suggest you do right now is look at the to-do tasks at your job. Take the one with a title you don't even understand. And throw yourself in there in angel jump mode. For damage control, let's discuss how to handle the unknown.

Take time for understanding

For a long time, upon receiving a new task, i would start to write code immediately. The goal was to go fast. What could be faster than coding the solution right away ?

And I totally understand if you do that too. We're pushed by tight deadlines and we're judged on our speed. But it's the worst possible habit. It's really gonna hit you in the face sooner or later. To avoid that, you need a plan.

The habit I'm advising you to follow is very simple. Don't do any lines of code until you have a complete solution of the problem. It doesn't mean you have to go into detail and write a novel.

It just means that, at least you know where you're going. Understanding, defining and solving the problem up front. Just invest time beforehand! The code part will only be the application of a problem that has already been fixed.

What you can do right now to start this habit is making diagrams for everything. Before coding, use a paper and pencil. Or even better : whiteboard. Just draw your solution and make it work on paper. That all you need to do and it's terribly efficient!

Always keep it simple

I'm still amaze when i run into hyper-complex code for basic needs. We developers love making everything complex when we code. We have to abstract, decouple and above all show that we know how to do complex things. It's a shitty habit.

What I'm advising you here is a change of mindset. You have to get into the habit of asking yourself how to do the simplest things all the time. Cut out the complexity, make classes with less responsibility, more functions, shorter that do one thing. Do everything you can to make it simple and readable. Your whole team should instantly understand what's going on in your code!

You can apply this very simply today by making a conscious effort to simplify everything you code. The main advantage of doing this is maintainability. It will save you and your entire team a lot of time.

Be careful with deadlines

I've dedicated an entire article to this subject because it's such a source of anxiety in our profession. Your time estimate is a joke. A good estimate is almost impossible to come out with.

Problem is : you have to make estimates. A lot of them, all the time. Like most developers, you tend to underestimate those timelines. It puts you in a world of trouble. And you regularly find yourself having to justify your estimate.

To overcome that, I've established two habits. The first habit is that I always ask for more information. More details, more precision, more context, more history, for whom ? why? is it possible to simplify ? is it possible to deliver using steps (alpha, beta and so on)? Yeah, I'm a big pain in the ass. But any information is critical and could save my life.

The second habit is that I never give a fixed estimate. Always a range, a min/max. If I think it's going to take two days, I say it's going to take between two to four days. And if I have no choice but to give fixed number, then I say four days. Fuck it if it's too long, that's my estimate.

Step-by-step learning

When I was first introduced to Git, I was told that it was the basis for any respectable developer. Not knowing absolutely everything about Git was a disgrace as a developer. It put a lot of pressure on me. So I read the whole doc and tried to swallow it all in a few hours. Of course, the next day, I was staring the console like an idiot after git status.

I see a lot of people trying to do the same thing. Learn as much as possible as quickly as possible. You have to understand that your brain doesn't give a fuck if you want to go fast. It'll come out as fast as it went in. People don't want to believe it, but it's true. You turn into a goldfish when you get too much information too fast. You can run as much as you want, you'll forget all about it.

So how do you learn a lot of things then? Just study by reasonable lengths, give your brain time to print out the information, and come back to it the next day. To do that, you can apply today a habit I picked up years ago that has done wonders.

Every time I hear a term or concept I don't understand, I write it down in a google doc. When I have some time, I open this google doc, I take the first term/concept and I learn about it. And that's it, I stop there, we'll see another day for the rest. You don't realize how good it is in the long run. And it's in the long run that you have to invest your time. Development is a marathon, not a sprint.

Another habit I've picked up is doing the same thing, but with bits of code and commands. I have long snippets on GitLab filled with complicated commands and other boring syntax to remember. I use these snippets every day and it frees my head for something else while remaining efficient.

Taking a step back

At the beginning of my career, very frequently, I insulted my computer out loud while working. Yeah, so without context, it's weird. Like all developers, I had bugs in my applications. Being stuck for a long period of time, my frustration was so high that I ended up losing it.

Tenacity, perseverance and resilience in the face of a problem are essential for all developers. I'm sure you've already lost your temper in front of your PC. We all have.

The secret is to step back and keep a logical and methodical approach. Most of the time, when you go crazy over something, you're so into it that you can't see anything. When you get angry, you lose the focus that allows you to think normally. You need to approach things coldly and methodically. You can practice a very simple first habit to start with.

Next time you feel this, instead of imploding, get up and do something completely different. Every time I do that, I'm gonna get coffee and/or see a colleague. When I get back to my seat : my brain is reset. I've taken a step back from what's going on and it's immediately clearer.

Then my second habit is to reduce the parameters and context of the problem to an extreme level. In a methodical way, I remove the complexity of my problem to arrive in a simple context that works. Finally, I put back parameters one by one until it crashes. When it crashes, I find the culprit, I fix the bug and I don't insult anyone.

Creating concentration tunnels

I often hear that to be an effective developer you have to be able to focus NON-STOP on a topic for several hours. I'll tell you right now: it's impossible. If you can hold 25 minutes on a single topic without flinching, it's already incredible. I think it's more efficient to create concentration tunnels (20 to 30 minutes) and to take breaks between each tunnel.

I've developed several habits over time to do that. The first habit I've established is the Pomodoro Technique. Concretely I set a timer of 25 minutes and I work without pause and without interruption during this time. At the end of the timer, I take a 5 minute break, no matter where I am. You become absolutely imperturbable during the tunnels and it changes everything.

Another super simple habit that you can put into practice right away: the next time you want to concentrate, turn your phone over or put it somewhere you can't see it. You don't realize how much the notifications on your phone are messing with your brain. Seriously, just try it for one day and see. It's unbelievable.

Control your ego

I mean, I'm bound to end this article on the ego. The unbelievable developer ego is very real. If I dedicated an entire article on it, it's because there is something to discuss.

The main problem for a developer with an overflowing ego is that he has no room for improvement. If you can't control your ego, you feel you have nothing left to learn. If you don't learn, you don't progress. If you don't progress, you regress. And believe me, you don't want to regress as a developer.

Besides, beyond your regression, if you're really full of ego, you're an asshole. You piss people off and nobody wants to work with you. That's not good for your career either. The good news is that you can easily control that oversized ego.

The very easy to practice habit is very much in line with what I advise you in the first point. Get out of your comfort zone and fail. Nothing better than a good old fail to put your ideas back in place and start afresh on your personal progress.

Epilogue

It's a lot to take in all at once, but believe me, it's worth it. I read a book that gave some tips on how to absorb good habits. The secret is to take it slowly in stages by applying part of the habit a little bit every day. It's called Atomic Habit, it helped me a lot, I highly recommend it! I promise it will pay off in the long run.

Understand Big O notation in 7 minutes

Mehdi Zed — Sat, 03 Apr 2021 01:20:26 +0000

The Big O notation is a notion often completely ignored by developers. It is however a fundamental notion, more than useful and simple to understand. Contrary to popular belief, you don't need to be a math nerd to master it. I bet you that in 7 minutes, you'll understand everything.

What is the Big O notation ?

The Big O notation (or algorithm complexity) is a standard way to measure the performance of an algorithm. It is a mathematical way of judging the effectiveness of your code. I said the word mathematics and scared everyone away. Again, you don't need to have a passion for math to understand and use this notation.

This notation will allow you to measure the growth rate of your algorithm in relation to the input data. It will describe the worst possible case for the performance of your code. Today, we are not going to talk about space complexity, but only about time complexity.

And it's not about putting a timer before and after a function to see how long it takes.

The problem is that the timer technique is anything but reliable and accurate. With a simple timer the performance of your algo will change greatly depending on many factors.

Your machine and processors
The language you use
The load on your machine when you run your test

The Big O notation solves all these problems and allows us to have a reliable measure of the efficiency of all the code you produce. The Big O is a little name for "order of magnitude".

And that's really the important thing to understand. You don't directly measure the speed of an algorithm in seconds. You measure the growth rate of an algorithm by the number of operations it takes to complete. You should Big O notation when performance among developers.

Not convinced ? OK, let's put ourselves in a real life situation!

It could happen to you

Imagine, you're hard at work, and one day you're asked to make a function that will return the sum of all the numbers from 1 to the number passed as a parameter. More clearly, something that would have this behavior.

n = 3

output = getSum(n)

print(output)
# will print : 6  because 1 + 2 + 3 = 6

Immediately, the first thing that comes to your mind is to make a simple loop that will cumulate the numbers one by one. I'll give you examples in Python, but we don't care about the language. It applies to any language.

def getSum(n):
    sum = 0

    for number in range(1, n + 1):
        sum += number

    return sum

And it works. You start your function with input 3: instantly you have the right result. Great! You're pushing to prod and you're getting a coffee in a nonchalant way.

A few days later, someone contact you directly and tell you that the system has become super slow. It's because of your function. The process time of your function goes up to more than 15 seconds! It frequently blocks the whole system for several seconds.

Panic! You look at the logs and you realize that the input has become huge numbers. Sometimes, the input of your function goes up to 1 billion. Another developer had to intervene. Your function is replaced and everything goes back to normal. You look at the new code and you see that.

def getSum(n):
    return n * (n + 1) / 2

This function solves the problem instantly, even when the input is 1000 billion. You ask the developer who did that on Slack and his answer gets you even more lost.

"Hi! Your solution had a linear O(n) trend except that the input was huge. I found a constant solution O(1). No matter how high the input is, it will be fast now."

You look at your screen and you have a single question that obsesses you.

How does it work?

As I told you, the key is to evaluate how many operations the machine will need to do to solve your problem. With your solution, there are a lot of operations.

def getSum(n):
    sum = 0  <-- assignment

    for number in range(1, n + 1): <-- addition + range
        sum += number <-- n additions + n assignments

    return sum

We're not going to do the exact calculation of the number of operations because we don't care about the exact number. We want the trend of the number of necessary operations according to the input parameters. What should shock now is the loop at line 4 and 5.

The operations to solve your problem will be multiplied by the size of your input. Your order of magnitude is directly related to the number n at the input of your function. Your function therefore has a linear trend of O(n).

The input is 1 billion ? It will be 1,000,000,000 * operations to do for the machine.

This is not the case for the other function.

def getSum(n):
    return n * (n + 1) / 2 <-- three operations

With this solution, the operations to solve your problem will not increase along with your input. Your order of magnitude will always be three operations, regardless of the input. Your function therefore has a constant trend of O(3), which is simplified to O(1). If you draw a picture, it looks like this.

You beginning to understand why it's important to have this notion in mind. There are obviously other scenarios for this notation. Let's take a quick look.

Big O notation by example

Constant complexity O(1)

The constant complexity O(1) does not change regardless of the input. The same number of operations is required everytime.

def exempleO1(n):
    print(n + n)

Logarithmic complexity O(log(n))

The log complexity O(log(n)) is more tricky to understand if you don't have the notion of logarithm in math. In a greatly simplified way, a logarithmic tendency is the opposite of an exponential tendency. Where an exponential trend will multiply over time, and the performance of your algo with it, the logarithmic trend will divide.

def exempleOlogn(n):
    i = 1

    while(i < n):
        i = i * 2
        print(i)

The binary search algorithm works with this trend.

Linear complexity O(n)

The linear complexity O(n) evolves in direct relation with the size of the input. The number of operations grows with the number of input. The simplest example is a simple loop.

def exempleOn(n):
    for number in range(n):
            print(number + 1)

Linearithmic complexity O(n log(n))

Linear complexity O(n log(n)) uses the same "divide and conquer" approach as logarithmic complexity except that it does so on each element of input n.

def exempleOlogn(n):
    i = 1
    for number in range(n):
        while(i < n):
            i = i * 2
            print(i)

The merge sort algorithm works with this trend.

Quadratic complexity O(n²)

The quadratic complexity O(n²) will evolve to the square of the input. The number of operations will grow to the square of the input. Two nested loops is the perfect example for this trend.

def exempleOn2(n):
    for number in range(n):
        for number in range(n):
            print(number + 1)

The best-known sorting algorithms (quick sort, bubble sort, insertion sort) have this tendency.

There are plenty of others that I'm not telling you about. If you want to see them all, the wiki page is interesting.

Also, look at this short YouTube video which is EXCELLENT to understand the rules of simplifying the writing of the notation. For example why is O(3) simplified into O(1)? Why do two loops that are not nested stay in a complexity O(n) ? Like any subject in your profession, there is an ocean of knowledge.

Finally, we will discuss why all this is important.

Why is this important?

I see developers working with small volumes coming in, convinced that all this will be of no use to them. Or even developers with 300 years of experience who don't need all this stuff.

The Big O notation quickly answers a question that every developer should ask himself during his work. How much does my solution scale? And it doesn't matter if your volumes are huge or not. It's important that you understand the limits of your solutions in order to estimate the limits of your system.

Then, by understanding this notion, you will have a standard language to discuss with other developers. This is important for comparing solutions, making trade-offs and simply exchanging technical information.

If you don't understand what we're talking about, you have a handicap. Personally, this even happened to me in interviews at the beginning of my career. I had no idea what he was talking about and I was in panic mode.

Having this basic understanding changed the way I approached problems. And as a developer, it's important to make optimized code.

Last but not least, these notions will allow you to quickly spot what is wrong with a slow system. A lot of time is spent reading and repairing other developers' code. All of this will allow you to find and optimize bits of slow code faster.

Epilogue

I hope this introduction to Big O notation made you want to know more. It's important to know this concept in order to better optimized your code. And generally speaking, it will be more and more useful to you as your career evolves.

Understand Blockchain in 5 minutes

Mehdi Zed — Sat, 27 Mar 2021 15:35:14 +0000

The Blockchain could have a monster impact on a huge number of industrial sectors within the next 5 to 10 years. We hear a lot about it everywhere, but what is the Blockchain? And more importantly, technically, how does it work?

Once upon a time

It's September 2008 and a global financial crisis is hitting the world. And this one is no joke. It's brutal, everyone is getting a huge slap in the face. This crisis will show, once again, that the current financial system is a joke. It's fragile, full of systemic problems, and it scares everybody. Now, if you can't trust the banks for your money, then who ?

On October 31, 2008, the famous Bitcoin whitepaper landed on the Internet. This whitepaper explains the concept and operation of a new currency exchange system. Reliable and, above all, without intermediaries.

We don't know who is behind this paper. We don't know if it is a man, a woman or a group of people. All we know is a mysterious pseudonym: Satoshi Nakamoto. And the crazy things about it is that, even today, we're still not sure who or what's behind this pseudonym.

On January 3, Satoshi Nakamoto launched the money platform by generating a first block in the blockchain. Bitcoin was born. But what exactly are we talking about?

What is the Blockchain?

The Blockchain is a digital data storage and exchange technology that is decentralized and tamper-proof. Imagine a huge accounting register where each transaction is scrupulously recorded one after the other. Everyone can see the new transaction added at the end of the register and no one can change it. Thus forming an "eternal" history of forgery-proof exchange.

The name "Blockchain" is not a lie. That's exactly what it is. A chain of public blocks that contains information about transactions between users. Each time new transactions are made, a block is created and placed in the chain. Via the peer-to-peer protocol, this block chain is securely updated to all machines connected to the Internet and using the system. The system ensures that the order and content of the blocks received by everyone is the same.

Under these conditions, this chain of blocks of information becomes a reliable source of truth between users. The state of the chain and its history is trustworthy. And this source of truth, with a decentralized architecture, makes exchanges possible without intermediaries. Intermediaries such as banks, for example.

But why this system can be trusted so much? To answer this question, you have to understand how it works.

How does it work?

Let's zoom in on that block chain a little bit. You have to understand what each block is made of to better understand the rest. First, each block contains the hash of the previous block, to make the link with the previous block. Then, of course, the data of the transactions you want to store. Then an identifier to know who made the block and a timestamp to know when it was made. There is also what is called a "proof of work", whose usefulness will be explained later. Finally, we end up with the hash of the current block, to make the link with the next block. It's clearer with a small schema.

I made an effort on the schema this time. Don't get used to it. And yes, it looks a lot like a linked list. Linking the blocks together via the previous hash and the current hash is similar to how linked lists are linked via pointers. But I have to point out that it's not exactly the same, otherwise all the purists will jump at me, fighting knives between their teeth.

Now, let's talk about the famous "proof of work". The proof of work is simply a long and complex calculation to do. Without going into details, it is a cryptographic puzzle that requires a lot of trial and error to arrive at a value.

And the important thing to understand is that without this proof of work, a block cannot be validated and inserted into the chain. Without proof of work, the Blockchain cannot function. But who is going to use their time and processor to make this proof of work? And for what purpose? That's where the famous Blockchain miners come in!

Some actors in the Blockchain are only there for the proof of work. They're called "the miners". Each time a new block is created, before being integrated into the chain, it is broadcasted to the whole Blockchain network for validation. All the miners in the network jump on the complex cryptographic problem necessary to validate this block. They use their computing capacities to ensure the Blockchain to work.

And the trick is that the first one to find a valid solution, spreads the solution over the network, and gets rewarded with Bitcoin. Bitcoin is a lot of money and miners are handsomely rewarded for their proof of work. That's why the Chinese have crazy secret data centers just to mine Bitcoin. That's why in 2017 graphics cards suddenly became super expensive, they were used by miners as proof of work.

Once the block is validated by the network, the miner who managed to make it first gets his reward. The block is then added to the chain and everyone receives it. The new state of the chain then becomes official. Until the next request for a new block.

Blockchain: the crazy expansion

From the beginning I've been talking about Bitcoin and transactions in general because it's a lot of money. The numbers of the transactions that are made every day will make you dizzy, it's crazy. But that's not the only use of the Blockchain.

There's a lot more and they're already there. The blockchain is just a secure way for exchange between two parties. Afterwards, what we exchange, and between whom the exchange is made, is completely free.

According to some experts, the year 2019 has been a major one for the Blockchain with a lot of new concrete cases of use by big names. A study on the Blockchain, also done in 2019, reports that the majority of companies place this technology in the top 5 of their priorities. So you're not done hearing about it yet. Especially as a developer. It will probably even be the standard for most exchanges in the future.

Épilogue

We've already been talking for five minutes, so I won't take up any more of your time. I hope I've made you want to know more about this technology that I think is crazy! If you did, I'd recommend this super interesting video that goes into some juicy technical details.

Understand Typescript in 5 minutes

Mehdi Zed — Fri, 19 Mar 2021 17:30:16 +0000

Typescript exploded in popularity in 2019 and continues its crazy run in 2020. The first language to hit the top 10 in less than 5 years. Unbelievable.

Once upon a time

This is 2010. Anders Hejlsberg, the responsible for the .NET framework, starts to have a lot of problems with Javascript. He works for Microsoft. And at Microsoft, everyone agrees on one thing. Javascript is not made for large-scale projects.

But Javascript is still used in large-scale projects at Microsoft. Why ? For a very simple reason: browsers only accept Javascript! Everyone is stuck with it. This problem in mind, Microsoft started to work on Typescript.

In October 2012, the version 0.8 of Typescript will go public for the first time. Many developers will then immediately change their religion.

And even if the first Typescript worshippers are intense, the first years of Typescript will be discreet. In 2017, the adoption of Typescript go crazy. And the years after, well, you've probably already heard about it.

What's Typescript?

Typescript is an open source programming language made by Microsoft. To be more precise, it is a superset of Javascript. Any existing Javascript program is already a valid Typescript program. In other words, if you're a Javascript developer, you have no entry barrier.

Typescript is a multi-paradigm language. You can do functional and object-oriented programming just like that. And I'm talking about real object-oriented, not object-oriented via prototype like in Javascript. The combination of OOP and the fact that Typescript is a highly typed language is the big thing here.

Typescript exploded in popularity because of developers coming from languages like Java and C++. These developers hate Javascript because of its interpreted nature, which is far too permissive. Typescript allows them to produce Javascript, therefore to work in the browser, while keeping a strongly typed and object oriented environment. Many of them see Typescript like a Javascript killer.

It is obviously not the case since Typescript will generate Javascript permanently. Typescript just transcompiles code into Javascript. And I say transcompile, not compile, because it's different. Okay, let's see how this works.

How does it work?

Typescript is very simple. Well, it's simple for us, the users. Microsoft must have pulled their hair out doing this.

First you're going to develop in .ts files. Typescript looks like Javascript, you're not going to be lost. However, you'll be in an object and strongly typed environment.

Typescript comes with a compiler (TSC). This compiler is really what makes Typescript a fancy thing. During development, this compiler will constantly transcompile your Typescript application into a Javascript application. OK, drawing !

Here's the important thing to understand : the Typescript part of the development is a typed, "secure" environment, made to catch bugs. After transcompilation, we're in Javascript. The interpretation at runtime part and therefore more exposed to bugs.

But as we went through Typescript before, our application is "reinforced". That's also what made Typescript so successful. A more secure way to handle huge codebase in Javascript. Enough theory, let's get our hands on it.

Show me the code

I'm assuming you're on a holy Linux distribution and the examples here are all runing on Node 13. Let's start by installing it. We're going to use npm to install it generally, then check that the installation was done correctly.

npm install -g typescript
tsc --version

Let's start with a daily thing in your everyday Javascript journey. A simple async/await. We'll call an async function via an await and simulate a 1 sec latency with a setTimeout and a promise. Right now, we stay in Javascript format and it looks like this.

async.ts

async function displayUser(idUser) {
  try {
    const user = await _getUserData(idUser)

    console.log(user)
  } catch (error) {
    console.log(error)
  }
}

async function _getUserData(id) {
  const user = await new Promise(resolve => setTimeout(() => resolve({ id,  name: 'superToto' }), 1000))

  return user
}

displayUser(1)

I told you before that any Javascript code is a valid Typescript code. So we should be able to transcompile that code, right? Let's run the compiler in the same folder.

tsc

Which will generate an async.js file that looks like this.

function displayUser(idUser) {
    return __awaiter(this, void 0, void 0, function () {
        var user, error_1;
        return __generator(this, function (_a) {
            switch (_a.label) {
                case 0:
                    _a.trys.push([0, 2, , 3]);
                    return [4 /*yield*/, _getUserData(idUser)];
                case 1:
                    user = _a.sent();
                    console.log(user);
                    return [3 /*break*/, 3\];
                case 2:
                    error_1 = _a.sent();
                    console.log(error_1);
                    return [3 /*break*/, 3];
                case 3: return [2 /*return*/];
            }
        });
    });
}
function _getUserData(id) {
    return __awaiter(this, void 0, void 0, function () {
        var user;
        return __generator(this, function (_a) {
            switch (_a.label) {
                case 0: return [4 /*yield*/, new Promise(function (resolve) { return setTimeout(function () { return resolve({ id: id, name: 'superToto' }); }, 1000); })];
                case 1:
                    user = _a.sent();
                    return [2 /*return*/, user];
            }
        });
    });
}

What the hell is this ? Where does all this infernal code come from ? Nobody wants to work with something like this. And nobody should !

But actually, we just haven't configured our compiler. By default, it will assume that you want ES3 compatible Javascript. A very old specification. A time when async/await didn't exist. He's trying to replicate async/await like it's 1999 !

To avoid this torture, let's configure the compiler. To do that, as always, we need the documentation. We need to create a tsconfig.json file at the root. That'll be our config.

{
  "compilerOptions": {
    "target": "esnext",
    "watch": true
  }
}

Target: this is the Javascript compilation target. You have to put the ECMAScript specification you want. Let's just put the last specification using "esnext".

Watch: this means that the compiler will transcompile your code if your file changes. Similar to a nodemon with NodeJS. By restarting TSC, the generated code is identical and the compiler is waiting for any changes.

All right, now let's look at a more advanced example. We're going to do what Javascript can't do. Using real interface (no duck typing), strong typing and all this in an object environment.

class Hero {
  constructor(public name: String) {}

  age: Number;
  powers: Array<string>;
}

interface Anonym {
  name: string;
  age: number;
  powers: Array<string>;
}

function displayHeroInfo(anonym: Anonym) {
  const heroInfo = {
    name: anonym.name,
    age: anonym.age,
    powers: anonym.powers
  }

  console.log(heroInfo);
}

const superToto = new Hero("SuperToto");

superToto.age = 25
superToto.powers = ['telekinesis', 'laser']

displayHeroInfo(superToto);

I'm creating a Hero class with a constructor. Using the public in the constructor arguments allows me to automatically create a name property. Then, still in the Hero class, I declare age (typed number) and powers (typed string array).

After that, I create an interface that establishes a contract name, age, powers. Then, a function that takes my interface as an argument. Finally, a piece of code that will call my class to display the JSON.

And it works! Try to pass a string for age, to not put a name at the instantiation of the class or to remove a property in the class. Typescript will scream and won't let you transcompile to Javascript.

Epilogue

We've been talking for more than five minutes. I'm done here. You'll find more sample codes over here. I find this technology really perfect for large-scale projects. A layer of protection like this in development is reassuring. I hope I've made you want to try it out for yourself!

Understand VueJS in 5 minutes

Mehdi Zed — Fri, 12 Mar 2021 21:01:19 +0000

I've been playing with VueJS recently. I'm impressed. It's simple, powerful, super fun and incredibly popular. Even a moron like me can do interesting things with it rapidly. It just goes to show that anybody can do great things with it. Do you have five minutes in front of you ?

Once upon a time

2012 in the New York area. At that time Evan You is living his best life learning Javascript. He's doing side projects left and right for laughs. One of them explodes in popularity on Hackernews ! Evan didn't know, but he just got Google's attention.

Very quickly hired at Google, his role is to create "experimental projects" for innovative ideas. He uses a lot of vanilla Javascript. He tries AngularJS and other frameworks, but he rages instantly on it. He doesn't find the freedom he needs. So he had an idea : extract the best part of these frameworks and make his own light and malleable framework for his own personal need.

In July 2013, the first commit of VueJS was made. For the record, VueJS was to be called Seed.JS. But it was taken on NPM! Since its framework is centered around the view part, Evan wanted something that looked like "View" in English. He went to google translate and translated "View" into several languages. He came across the French translation "Vue" and found it cool. A few minutes later, VueJS was published.

In 2014, the first version of VueJS arrived on the Internet. The project doesn't explode right away. But like the creator of Laravel, more and more people are talking about it. Today, VueJS is in the big league.

What is VueJS ?

VueJS is a Javascript frontend framework to create user interfaces. You're going to say "one more?" and the answer is yes. Except it's a little different.

First, it's interesting to understand that VueJS was designed to be incrementally integrated. That means if you have an existing frontend application, you don't have to redo everything. You can make a new part in VueJS and quickly integrate it with the rest.

VueJS is also the most is easy to pick up of all the frontend framework. That's what attracted me as a backend developer in the first place. Very quickly, I did some frontend stuff that worked ! I was shocked! Within a few hours of reading the doc and testing stuff, I had understood all the basics. I was already shipping frontend.

VueJS also takes good ideas from its competitors. It allows data binding. The data and the DOM are coupled and reactive to changes. We also find the concept of virtual dom with VueJS. The DOM is not directly changed, it goes through the virtual DOM.

We also find the organization by component. This feature allows you to divide your application into several sub-components that each manage their own life and are reusable. Let's imagine you want to make a list of images: you can make a component that manages an image and a component that manages a list of image components.

That's all well and good, but how does it work?

How does it work?

For once I cheat a bit and show some code in advance to better understand what's coming next. Hello World!

<!DOCTYPE html>
<html>
  <head>
    <script src="https://cdn.jsdelivr.net/npm/vue"></script>
  </head>
  <body>
    <div id="app">{{ message }}</div>
    <script>
      const data = { message: "Hello World !" };
      new Vue({
        el: "#app",
        data: data
      });
    </script>
  </body>
</html>

VueJS focuses on the view part of your application. To do so, the framework is partly inspired by the MVVM architecture pattern. VueJS will link your DOM, the view part, with your view instance, the Model-View part. These two parts are linked by the data-binding system.

Finally, the data in your view instance is the Model part. It will provide your application with data. The Hello World code schematized looks like this.

A VueJS application is composed of one or more components. When the instance of the global application is launched, there is first a root instance. This is root instance is composed of a tree of components which have their own root instance.

But what happens to the life cycle of your instance when you create the component with new Vue()? I wanted to make my usual silly schema but it turns out that the official VueJS doc is just EXCELLENT*. It's rare to have a good documentation. So I'm just going to pump their schema.

I'll let you admire it and figure out what's going on. The only thing that might be unclear is the difference between "created" and "mounted".

Created means that the element is only available in the View-Model part.
Mounted in VueJS means that the DOM element has been rendered in your page and you can manipulate it.

OK great, now let's get our hands dirty.

Show me the code

I'm gonna show you a piece of code I made for a personal need. A simple responsive gallery with only three components. We start with the root app.

app.vue

<template>
  <div id="app">
    <action v-bind:message="messageAction"></action>
    <grid v-bind:photos="photos"></grid>
  </div>
</template>

<script>
  import action from './components/action.vue'
  import grid from './components/grid.vue'

  export default {
    name: 'App',
    components: { action, grid },
    data: function () {
      return {
        photos: [
          {
            id: 0,
            url: "https://i.imgur.com/p3IKY9G.jpg"
          }
        ],
        messageAction: "It's working !"
      }
    }
  }
</script>

<style>
  {
    box-sizing: border-box;
  }

  body {
    margin: 0;
    font-family: Arial;
  }
</style>

On the template side I start by declaring my root app in a div. Inside there are two other components (action and grid). Note how I pass the data that comes from the instance seen in the components with the v-bind directives.

On the script side, I import the components to use them in the app we export. We declare the data, the pictures and a message, which is reactive to changes.

On the style side I integrate very simple CSS that is global to the whole project.

Next up, the action component.

action.vue

<template>
  <div class="callToAction">
    <h1>{{ message }}</h1>
  </div>
</template>

<script>
  export default {
    name: 'callToAction',
    props: {
      message: String
    }
  }
</script>

<style scoped>
  .callToAction {
    position: absolute;
    height: 100%;
    width: 100%;
    padding: 0;
    margin: 0;
    display: -webkit-box;
    display: -moz-box;
    display: -ms-flexbox;
    display: -webkit-flex;
    display: flex;
    align-items: center;
    justify-content: center;
  }

  h1 {
    color: red;
    background:black;
    padding: 10px;
  }
</style>

The action component is simply a text that we put in the middle of the page and that will be a call to action for the user. I use the "message" syntax to display the message that comes from the app.

Note also that the style part is "scoped". This means that the CSS in question has effect only in this component. This is very useful to separate the style scope of each component.

grid.vue

<template>
  <div class="grid">
    <div v-bind:key="grid.id" v-for="grid in grids" class="column">
      <photo
        v-for="photo in grid" 
        v-bind:photo="photo" 
        v-bind:key="photo.id"
      ></photo>
    </div>
  </div>
</template>

<script>
import photo from './photo.vue'

export default {
  name: 'grid',
  components: { photo },
  props: ['photos'],
  computed: {
    grids: function () {
      const grids = []
      const deepClonePhotos = JSON.parse(JSON.stringify(this.photos))
      const gridsToMake = Math.ceil(deepClonePhotos.length / 2) - 1

      for (let index = 0; index <= gridsToMake; index++) {
        const currentGrid = []

        for(let i = 0; i < 2; i++) {
          if(deepClonePhotos.length) {
            currentGrid.push(deepClonePhotos.shift())
          }
        }

        grids.push(currentGrid)
      }

      return grids
    }
  }
}
</script>

<style scoped>
  .grid {
    display: -ms-flexbox; /* IE10 */
    display: flex;
    -ms-flex-wrap: wrap; /* IE10 */
    flex-wrap: wrap;
    padding: 0;
  }

  /* Create four equal columns that sits next to each other */
  .column {
    -ms-flex: 25%; /* IE10 */
    flex: 25%;
    max-width: 25%;
    padding: 0;
  }

  /* Responsive layout - makes a two column-layout instead of four columns */
  @media screen and (max-width: 800px) {
    .column {
      -ms-flex: 50%;
      flex: 50%;
      max-width: 50%;
    }
  }

  /* Responsive layout - makes the two columns stack on top of each other instead of next to each other */
  @media screen and (max-width: 600px) {
    .column {
      -ms-flex: 100%;
      flex: 100%;
      max-width: 100%;
    }
  }
</style>

The grid component is the one that will make the logic to display image grids in relation to the data it receives from the app. In the template part I create a column every two images. In these columns I display my two images. I do this using another photo component. You will notice the use of the v-for directive to browse my lists.

In the script part, I use props to get the data passed by the v-bind in the app. Then I use the computed function to create a new grids variable with the data of the pictures.

photo.vue

<template>
  <img :src="photo.url" alt ="" />
</template>

<script>
  export default {
    name: 'photo',
    props: ['photo']
  }
</script>

<style scoped>
  .column img {
    vertical-align: middle;
    width: 100%;
  }
</style>

The photo component just allows me to isolate the display of the photo in a corner. It's quite simple, but it allows me to change a lot of things on this side in the future without having to touch the logic above! As usual, I put a little codesandbox, you can play with it and see it all in action.

Epilogue

We've been talking VueJS for more than five minutes now. You have to understand that after reading the doc quickly I created this first application in a few hours. The handling of this framework is crazy and so pleasant. Frankly I advise you to test it, it's enjoyable!

How to screw up your IT project

Mehdi Zed — Fri, 05 Mar 2021 23:38:08 +0000

I've seen a lot of computer projects catch fire and fall into chaos before my eyes. Today, I'm going to give you the perfect recipe to screw up your IT project. Everything burns.

Schizophrenic scope

At the beginning of an IT project, you have a plan. You and your colleagues had some big coffee and went to a room to make drawings and put it all on paper. Well, this reflection has to be shit. It's super important, because it's the basis.

To make sure your IT project fails, your starting scope has to be blurry and incomplete. Get out of this meeting with a stupid post-it, throw it at the first developer you see and tell him that it's due for tomorrow. This is by far the best start. You haven't even started yet but you're already punching your project in the ribs. It's not enough.

Your scope and the features need to keep moving. It'll be easy to do if the basics of your project are not clear. And there are no rules here. Go crazy ! Change everything. Add features, change them at the last moment, go back and contradict yourself in the same sentence. To make sure your IT project fails, your scope must evolve as much as possible. The scope has to be completely schizophrenic from start to finish. It's important that every changes make no fucking sense. You need chaos. This will also keep the stress level very high.

Anxiety as a service

Again, this is really a metric that you have to monitor and maintain throughout the project. To make sure that your IT project fails, you need to generate and maintain maximum pressure. Constantly changing the scope is a good start. When your development team proudly finishes a feature, just delete it from the specification.

If you're a manager, you need to communicate all your stress to the whole team. If you're a developer do the same with other developers. You really need everyone in panic mode.

In order to maintain an unhealthy level of anxiety, there's something you can do right away. To make sure your IT project fails, you need to set a crazy deadline. That's kryptonite for everyone. Here's a tip : don't let the development team do the technical time estimate. That's central, too. Have someone who doesn't know anything about the technology used. Better, who knows nothing about the technical side in general. The time estimate must be a huge joke. Everyone must agree that the situation is untenable. Everybody, except the person who decides.

As a developer, when faced with a situation like this, you'll immediately produce absolute garbage code to go faster. Normal, classic, we like it and above all it's essential for any project that sinks into chaos. As the base of the project is shaky and the scope is unstable, very quickly, the first technical problems will occur. At this point, there is a absolute golden rule to keep in mind.

Always blame others

It's not your fault! Never. It's other people's fault. To make sure your IT project fails, no one has to take responsibility. You have to be always defensive and hostile to any remark. Because if you accept criticism, rightly or not, you will focus on how to fix the problem. This could lead to progress ! To make sure that your IT project fails, everyone has to point fingers at each other. No one works on the problem anymore since everyone is too busy blaming everyone else. The chaos is total and your project is doomed.

A long time ago in a galaxy far, far away, I worked on a microservice that I had to ship in an internally managed cloud. I'll pass on the details of why, but my thing wasn't working. More accurately, it wasn't working in that internal system. It was weird. Innocently, I just asked a single dude, using private email, if there were other cases with the same problems or if I was an isolated case.

A week later, no answer. By that time I had solved my problem on my own. It was indeed my implementation which was absolute garbage. Classic.

But without knowing it, I had started a war between three different teams. My service behavior was déjà vu. They all started pointing fingers at each other using e-mails. This went so far that the direction has to intervene. A week's work lost. No progress and a bad atmosphere. And that was possible because everyone was working on their own stuff.

Working in silo

It's super common in big company. There's a lot of teams doing a lot of things all over the place. You're on one of those teams. It's very important that you refuse to share your work and that you close communication. To make sure that your IT project fails, everyone has to work in their own corner. It's best when everyone is working on the same thing without knowing it. It's beautiful when you realize it months later. You realize it months later because you don't communicate.

To make sure that your IT project fails, communication must be non-existent. If there's one piece of advice you need to remember, it's this one : no communication, zero. Maybe answer an email once or twice a week. Just send that you're "too busy to talk", works every time. And if you run into people in real life, look at the ground or kind of turn around and run. Avoid interaction as much as possible.

It is also important not to say anything about potential problems you spot. Zero transparency. When you see a huge problem, keep it to yourself. Zen, let it go. To make sure your IT project fails, forget about risk management. Everything's fine. Remember, it's not your fault. Don't start mapping out risky areas. You could change course and solve a lot of problems with this method alone. This is easy to avoid when you don't have any process.

No process, no standards.

Work processes, methodologies and best practices : forget about it. It's for the weak who don't know how to work independently. To be sure that your IT project fails, you should not apply any process or standards. The problem is that it allows everyone to work the same way. It saves time and you're injecting stability into your project. That's not what you want !

Also, force all your developers not to document what they do. Each piece of code must remain a mystery to those who will pass over it afterwards. And this lack of process should also be felt in the way you communicate.

To be sure that your IT project fails, important changes must be made by email or orally. If you manage to drown a change of specs in the middle of an endless chain of e-mails you get bonus points. You don't want a structured source of truth like Jira, Trello and others. You don't ! Because then you can't just go, "No, but if you remember, we said so at this meeting." And this card is important, because it's going to help you explain that it's never your fault.

Also, quality shouldn't be one of your goals. I'm not worried, you'll be fine if you don't have standards. Your only goal should be to deliver something on time. It doesn't matter how bad your project is. And what matter even less is the state of your team.

Despise the human

To make sure your IT project fails, you have to recruit the wrong people. You have to take people who don't get along with each other or with the company in general. One bad recruitment can jeopardize your entire project. It's much more efficient than you think. Insist that that HR send you toxic people, this will really have major impact on the project.

Once you get people who hate each other to work together, all you have to do is make the most of them. To make sure your IT project fails, you have to despise everyone. There are a couple of techniques to be effective in this.

You can force everyone to work a minimum of 80 hours a week. When people no longer have a personal life, it is with undisguised pleasure that they will shit inside your project.

A little "You take your afternoon off ?" when someone leaves at 7pm is exactly what we want. It doesn't cost you anything to say it, but for the person receiving the remark it's incredibly unpleasant. You can also ask a junior to do a senior job and pay him like shit. In short, frequently despise everyone a little bit and people will go crazy.

The Holy Grail for your project is someone doing a burnout. Priceless ! If on top of that it's a dude who made himself indispensable JACKPOT! You'll have a lot of indispensable people because you have no standards and no documentation. Your project will then end its race in hell while this person leaves with critical knowledge to finish it.

Epilogue

Now, if you apply everything I've just said, you can be sure that your IT project will be a disaster. A lot of projects do this and that's why IT project fails so much in tech. Sure, there's a lot of other things you can do to screw it up. You have the comments below to share tour thoughts.

Understand GraphQL in 5 minutes

Mehdi Zed — Fri, 26 Feb 2021 14:33:06 +0000

When GraphQL arrived on the Internet, it spread like an epidemic. GraphQL has completely changed the way things are done and continues its progression everywhere. If you have five minutes in front of you, I'll explain everything you need to know.

Once upon a time

By 2012, the adoption of mobile phones reached monstrous figures worldwide. It's such an invasion that companies that didn't adapt their products were at risk. At that point, Facebook was at risk.

Facebook was primarily a web company. As a result, they made their IOS app like a website, using web-view. Very quickly, they realize that web-view was shit (at that time). So they decided to redo it entirely in native, for a better customer experience. Immediately they hit another wall .

The existing architecture didn't work. Mainly because the endpoints of their existing REST api don't allow flexibility on the data. Multiple round trips to different endpoints were required for nested data, causing slowness and inconsistencies. Part of the payload was not required for most queries, causing unnecessary data transfers. And most importantly, it was tedious for Facebook to handle so many HTTP calls.

In this infernal context, in February 2012, Lee Byron, Dan Schafer and Nick Schrock reserved some workstations in a corner of Facebook.

Very quickly a first prototype of GraphQL, then called SuperGraph, was produced by our three devs. In August 2012, GraphQL was shipped in production with the new native Facebook app. In 2015, the first public version arrives on the internet. GraphQL is still present today when you scroll your Facebook wall. But how did they solve a problem that affected not only Facebook, but the whole industry?

What is GraphQL ?

GraphQL is a data query language for APIs. QL, as in SQL, stands for Query Language. GraphQL allows to manipulate data in a simple, flexible and very precise way. GraphQL is not a programming language nor a framework. GraphQL is a specification to implement your API. Concretely it looks like this.

Request

{
    pokemons {
        name,
        abilities {
          name,
          damage,
          accuracy,
          mana,
          type
        }
    }
}

Response

{
    "data": {
        "pokemons": \[
            {
                "name": "pikachu",
                "abilities": \[
                    {
                        "name": "Thunder punch",
                        "damage": 75,
                        "accuracy": 70,
                        "mana": 15,
                        "type": "physical"
                    },
                    {
                        "name": "Thunderbolt",
                        "damage": 90,
                        "accuracy": 80,
                        "mana": 15,
                        "type": "electric"
                    }
                \]
            },
            {
                "name": "mewtwo",
                "abilities": \[
                     {
                        "name": "Earthquake",
                        "damage": 130,
                        "accuracy": 100,
                        "mana": 20,
                        "type": "ground"
                    },
                    {
                        "name": "Brutal swing",
                        "damage": 180,
                        "accuracy": 90,
                        "mana": 25,
                        "type": "physical"
                    }
                \]
            }
        \]
    }
}

That's how you ask for and receive data using GraphQL. Okay, at the moment, it's not clear. First of all, where does this thing fit into your architecture?

The dude smiling it's you. And to make the payload I showed you earlier with the Pokemons and their skills, you're in trouble. You're struggling because the REST API you're using is not made for your needs. You end up making one call per Pokemon, then one call per skill for each Pokemon.

Each time the logic in your application makes a request to the database and sends you a payload. And so, despite your apparent smile, you feel like shooting yourself. That's where GraphQL comes in.

With GraphQL, no more problems. You make a single POST and you ask exactly what you want via a GraphQL request. Then, the server manages everything and you get your full payload.

With REST, you get objects defined by endpoints. With GraphQL, you don't adapt to a object defined by the backend, you dynamically define the object you're going to receive on the client side. And that changes everything.

OK, that's all very well, but how does it work in concrete terms? How does GraphQL access your database and make queries? To really understand GraphQL, you have to get your hands on it.

Show me the code

I'm going to make you a Javascript implementation (NodeJS).Be aware that all the following is applicable in any language. The GraphQL logic remains the same everywhere since it is above all a specification.

To start working on GraphQL go to the official site and their implementation list in all languages of the world. To make it simple with NodeJS we need the express-graphql and graphql modules. Let's start by mounting the base server.

index.js

const path = require("path");
const express = require("express");
const graphqlHTTP = require("express-graphql");
const graphql = require("graphql");

const { query } = require(path.resolve("schema/query"));
const graphQLSchema = new graphql.GraphQLSchema({ query });

const app = express();

app.use(
  "/graphql",
  graphqlHTTP({
    schema: graphQLSchema,
    graphiql: true
  })
);

app.listen(8080);

First of all, we call our dependencies. Then line 6 we look for our root query which we pass to the main schema on line 7. We launch our express server, we expose the /graphql route via an express middleware and finally we listen on port 8080. Let's see what happens inside the schema now.

schema/query.js

const path = require("path");
const { GraphQLObjectType, GraphQLList } = require("graphql");
const { pokemonsType } = require(path.resolve("schema/types"));

const RootQuery = new GraphQLObjectType({
  name: "RootQueryType",
  type: "Query",
  fields: {
    pokemons: {
      type: new GraphQLList(pokemonsType),
      resolve() {
        const data = require(path.resolve("data/pokemons.json"));

        return data;
      }
    }
  }
});

exports.query = RootQuery;

The schema is central in GraphQL. It will dictate the communication between your client and your server. I*t specifies the queries your clients can make, the types of data that can be retrieved and the relationships between these types.* Everything is defined in this schema. Starting with the root query.

The root query allows GraphQL to know what type of data can be retrieved. And here, in my root query, I specify that I have a field pokemon line 9 which is a list of type pokemon line 10.

Then we have a resolver on line 11. It's the resolvers that do the job of fetching your data from your database. A resolver is assigned to each of your fields. And the resolver for my pokemon field is a pokemon object list. My resolver here returns the data via a JSON file that corresponds to an array of pokemons.

I return a JSON for the data for simplicity and brevity. But in real life this is where you are supposed to call your database, make queries, and return the data. Now let's see what the types look like.

schema/types.js

const path = require("path");
const graphql = require("graphql");
const { GraphQLObjectType, GraphQLString, GraphQLList } = graphql;

const abilitiesType = new GraphQLObjectType({
  name: "ability",
  fields: {
    name: {
      type: GraphQLString,
      resolve: parent => parent.name
    },
    damage: {
      type: GraphQLString,
      resolve: parent => parent.damage
    },
    accuracy: {
      type: GraphQLString,
      resolve: parent => parent.accuracy
    },
    mana: {
      type: GraphQLString,
      resolve: parent => parent.mana
    },
    type: {
      type: GraphQLString,
      resolve: parent => parent.type
    }
  }
});

const pokemonsType = new GraphQLObjectType({
  name: "pokemons",
  fields: {
    name: {
      type: GraphQLString,
      resolve: parent => parent.name
    },
    abilities: {
      type: new GraphQLList(abilitiesType),
      resolve(parent) {
        const abilities = require(path.resolve("data/abilities.json"));

        return abilities.filter(ability =>
          ability.linkedTo.includes(parent.name)
        );
      }
    }
  }
});

exports.pokemonsType = pokemonsType;

The principle remains the same. We create GraphQL object types that represent our data structure. We specify fields and for each field, we assign a resolver that will look for the right data. It's interesting to see here that I use the context of the parent to filter which abilities to return for each pokémon line 44.

If you want to see a working version of this implementation, I made a little public sandbox where you can play with it. You can see all the files, including the JSON files, and change whatever you want!

Instead of JSON data you could implement the same thing by doing fech on PokéAPI. That would allow you to practice GraphQL as well.

Epilogue

That's it, I can't go any further in the presentation. I'm already over the five minutes of time you gave me. There's a lot more to be said about this technology. The mutations, the cache, the variables and the contexts. I'll stick to the basics. If you want to know more and have some time to spare, I recommend this very complete article!

20 essential web tools for developers

Mehdi Zed — Fri, 19 Feb 2021 16:02:51 +0000

Having the right tools as a developer will save you a lot of time on everything. Whether it’s producing code, checking data or validating commands and configurations, it quickly becomes indispensable. Here is my favorite folder, it took me several years to build this list!

1 – DevHints.io

Impossible for me to remember the syntax and snippets of the tools and languages I use. Besides, it’s useless since that’s not the important thing. The important thing is to remember the concepts, not the details.

For details, cheatsheets are there for that, and DevHints is the gold mine.

You can think of any language tools or frameworks used by developers, you will find the cheatsheet on this site. In a few clicks you have access to everything and it’s easily printable. A must to help the memory!

2 – Learn X in Y minutes

Learn X in Y minutes is the kind of crazy site you have to see to believe.

Every possible language, explained in one page, in almost every language, through concrete examples of code. From more than standard languages like C++ to infernal languages like LOLCODE you will find everything.

It differs greatly from the first one because here each language is explained as a course. It’s not about refreshing your memory (cheatsheet) but about learning the basics of a new language quickly.

3 – Regex101

Regex stopped being a problem when I discovered Regex101.

Before the discovery of this tool, creating or modifying a complex Regex was tedious. I first had to remember every syntax and detail and then I had to test my solution for a long time to make it work the way I wanted.

Today, I go on this tool, it is done step by step with explanations. All the tests are done instantaneously with each modification. To decode one of them, I copy/paste and I have the whole explanation. The tool accompanies me and it saves me an absurd amount of time. A MUST HAVE!

4 – JSON Editor Online

When I work with JSON, I frequently end up drawing JsonEditorOnline.

First, i use it to clearly visualize my data via nodes. But above all it allows me to make differences between several JSON. If like me you work a lot with APIs, you often find yourself having to compare data.

I used to do this by looking at JSONs one after the other. It wasn’t fast and it could create errors. Since I’ve been using this tool, there’s no more chance of making mistakes and I save a lot of time!

5 – CodeSandbox

My favorite online code editor that I use all the time is Codesandbox.

A free, instant and collaborative sandbox code editor for all your needs! It’s really fast and you can host whatever you want as a small static app.

I prefer it to CodePen because I can host images without paying and I have more choice of technologies and templates. Perfect for prototyping my ideas quickly!

6 – Cloudflare Speed Test

With the pandemic, my internet connection has become even more important than before. If there is a network outage or drop, I want to know immediately.

Fortunately, Cloudflare has made a page analyzing your connection in great detail.

With one click, it tells you everything about your current connection status. Handy to know what happens when your call lag or when nothing works anymore!

7 – Excalidraw

Before coding a complicated problem, I need to make a schematic. Believe me, nothing will save you more time than schematizing your ideas before coding.

Most of the time, it’s paper/pencil. Otherwise, it’s Excalidraw.

Excalidraw is a whiteboard that allows you to easily draw your plan as if it were handmade! A blank page, enough to make diagrams and save them. Simple, fast, clean, free, incredible. A must.

8 – BundlePhobia

When I find an NPM package that could help me, it goes right through BundlePhobia.

This small web application allows me, in one click, to know the price in size and time of the package. It also allows me to see how many dependencies are linked.

It allows me to decide if it’s worth introducing this new dependencies in my project. Sometimes it allows me to choose between two packages that do the same thing. And no matter what happens in the end, my application wins!

9 – Semver Check

I frequently use Semver check to check the NPM versions of my projects.

It allows me to be sure that some version constraints will behave as I want. It’s more of a tool to check that I’m not going to do something stupid. But it’s very useful to quickly validate a version.

I sometimes found myself with unwanted package versions before using it. It’s not possible to make mistakes with this anymore. Very practical!

10 – CodeElf

If you are a dev it means that you spend half of your time choosing variable and function names. This tool will help you.

Codelf is designed to save you time thinking about naming!

It instantly searches Github, GitLab and Bitbucket to see if your naming idea is popular! There’s a greater chance your idea will be good if it’s already been used by thousands of developers before you.

11 – Htaccess Tester

I have already broken entire sites by changing htaccess with far too much confidence.

By using htaccess tester it won’t happen anymore!

This little tool allows you to know exactly how your htaccess behaves before pushing it. No more need to worry when pushing, you are already sure that your site will not implode and that the redirections will be correct. Just one use is addictive!

12 – ExplainShell

Retaining all the small options of all shell commands is almost impossible.

Explain shell allows to copy/paste any command is to have a complete explanation!

It’s a kind of man command but faster to read, more detailed and well presented in the browser. Everything is explained, option by option, in a nice interface. Very handy to quickly go through all types of command.

13 – Squoosh

Most huge images – in terms of weight – can be reduced by 60% without losing quality.

That’s exactly what Squoosh does in just one drop!

Indispensable if you want to optimize your site and the bandwidth of your visitors. And generally speaking huge images are useless. Very handy to get rid of them quickly.

14 – Photopea

This one is completely crazy!

Photopea is just free Photoshop in the browser.

I frequently find myself retouching images for various reasons. No need to have the cheap free editing tools anymore. I just open a page and get it done.

It’s very handy to do a quick trick from anywhere without installing all the junk. It’s amazing that it works so well and it’s free!

15 – DevDocs

It would be cool to have access to all the docs of all the frameworks/languages in one well-organized place.

Well that’s exactly what DevDocs is all about.

Very handy to not spend your life on all the sites of the world and have 30 tabs open. The truth is that I use it mostly for a limited number of docs, but it’s still convenient to stay in one place.

16 – Carbon

If you’re wondering how some developers are able to generate beautiful images of their code, look no further!

Carbon is quite simply the most widely used code presentation generator.

It’s handy! The equivalent in VSCode extension also exists.

17 – Hoppscotch

Almost everyone knows Postman or Insomnia to test these APIs.

Hoppscotch is exactly the same, but directly in the browser!

It’s very complete, there are all the options you can imagine and it can always help to quickly test an api. Postman also allows you to test via the web, but you need a code and even a browser extension for some calls.

Hoppscotch you have access to everything you need with just one click.

18 – Crontab Guru

Setting up a cron can be extremely catastrophic if there is the slightest error.

Crontab guru allows you to validate exactly how your future cron will behave before programming it.

In the same vein as htaccess tester, no more sweating before adding or updating rules with a strong impact. You know exactly how it will behave before you push anything. Very handy to go fast and have peace of mind!

19 – DevTools

DevTools is a suite of tools to save a little time in the small tasks of dev of every day.

Encoding/decoding text, text comparison, text generation, UUID generation and many other mini tools in one place. Instead of juggling commands and scripts from everywhere, you have everything in one place. Copy and paste you have your result and you save time!

20 – Repl.it

Online code editors such as Codesandbox or Codepen are limited to the frontend.

ReplIt is more than 50 languages that can be used in the browser for free.

The perfect place to prototype bits of code backends quickly. I use it very frequently to validate a function, a piece of algo or simply to check the compatibility between two versions of NodeJS or Python. With a free account you can even share your algos !

Bonus – Pomofocus

A little bonus tool!

Pomofocus is the best web management tool for the pomodoro technique I’ve ever seen.

The pomodoro is a very well known technique that I frequently tell you about on this blog. It allows you to increase your productivity tenfold in an impressive way! And pomofocus is perfect to test it.

Epilogue

I’ll do the same kind of post in the future with desktop software and another one with Visual Studio Code extensions. Today’s list comes from a thread I created on Twitter. If you want to get the news before everyone else, don’t hesitate to join me on Twitter !

Understand 3D in Javascript (ThreeJS) in 5 minutes

Mehdi Zed — Fri, 12 Feb 2021 15:47:08 +0000

With a little knowledge in Javascript, you can do incredible things in 3D with ThreeJS. It's much simpler than it looks and it's so much fun. The only problem is the first learning barrier. Today, I'm taking that barrier down for you in 5 minutes. After that, all you'll have to do is have fun.

What is ThreeJS?

ThreeJS is a library in Javascript, created by Mr.doob, that allows you to manipulate 3D objects directly in the browser. What you have to understand is that ThreeJS, via Javascript, allows you to use WebGL in an HTML5 canvas.

WebGL is a Javascript API that allows you to create 2D and 3D graphic rendering.

A canvas is an HTML component that is part of the HTML5 specification and allows to display graphic rendering.

ThreeJS, via Javascript, allows you to drive WebGL, and thus 3D. And the crazy part is that there is no additional installation and/or plugin needed ! Import the the library and voila, the 3D world is opening.

So in summary, we have a Javascript library(ThreeJS) that manipulates a Javascript API to do graphical rendering (WebGL) in an HTML5 component. Easy!

Now you're going to tell me, why are we using ThreeJS? If it's actually WebGL, why not write WebGL directly ? The answer is pretty simple.

ThreeJS simplifies and shortens to the extreme the code needed to do whatever you want. ThreeJS does all the complex part for you. You just have to do simple Javascript on your side.

So if you have simple Javascript knowledge, ThreeJS gives you the power to do incredible things in 3D.

But concretely, how does it work?

How does it work?

To understand how ThreeJS works at a high level you need to put yourself in the shoes of a film director. Yes, poof, I've just decided, you're a movie director now.

And to shoot your movie in Javascript, you're going to need to create and manipulate several key elements.

The scene

You can see the scene like the 3D world you're going to work in. You're going to arrange objects in this scene. You're going to create as many objects as you want in your scene via the meshes.

The meshes

Meshes are simply the objects that will be present in your scene. You will need to put light on these objects to see them. To see them, you will have to film them. To film them, you need a camera.

The camera

As in real life, the camera will show a point of view of your scene. We're going to talk about field of view (fov), to be precise. By moving the camera, you're going to move objects in or out of this field of view. It's what you see in this field of view of this camera that will be sent to the rendering engine.

Rendering engine

The rendering engine takes the scene and the camera as parameters. With that, it displays everything in the HTML5 canvas I was telling you about at the beginning. The rendering engine will produce an image each time your screen is refreshed. In general, 60 frames per second. That's what gives life to your animation!

I guess it can still be pretty abstract at the moment. I have to draw you a picture to make it more concrete. Ok, I'll use my drawing skills then.

Can you tell i'm a backend developer ?

Anyway, it should be much clearer now between the explanations and the drawing. I know you want to see code now.

Show the code

As the Hello World app we'll make it as simple as possible. We're going to code the schema I made for you just before.

A basic scene with a cube in the middle. Except that instead of the cube, we're going to put a cylinder, just because I feel like it. We're going to make it spin on itself and we're going to put it in the camera's field of view.

I'm going to comment strongly on each line so that you understand everything that's going on. I will also frequently talk about the official documentation, so don't hesitate to read it as you go along.

We start by declaring our scene, without that, nothing is visible! Then the rendering engine for our scene. Without this, no image will be created and displayed to the user. Then we want a camera to film the scene. Here we will use a perspective camera. The options allow us to configure the field of view.

const scene = new THREE.Scene()
const renderer = new THREE.WebGLRenderer()
const camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000)

We already have everything we need to show things now. Let's create the cylinder via a mesh! To create a mesh we need two things.

The geometric shape that the object will have. Here we want a cylinder so CylinderGeometry is perfect for our needs.

The material of this object. The material is the digital version of real world materials. The materials control the color of the object and the degree of reflection of the surface. Here we put a basic material of red color.

With these two parts we can create our object, add it to the scene and place the camera over it.

const geometry = new THREE.CylinderGeometry(5, 5, 20, 32)
const material = new THREE.MeshBasicMaterial({ color: 0xff0000, wireframe: true })
const cylinder = new THREE.Mesh(geometry, material)

scene.add(cylinder)
camera.position.z = 20

Then, we're going to put the rendering engine in full screen and add it in the HTML page via the HTML5 canvas!

renderer.setSize(window.innerWidth, window.innerHeight)
document.body.appendChild(renderer.domElement)

Finally, we're going to animate things up. We are going to create an animation function that will be called in an infinite loop. Each time we go through this function we're going to:

make the cylinder rotate on itself
ask the rendering engine to create and display an image
recall this same animation function

function animate() {
    cylinder.rotation.x += 0.01
    cylinder.rotation.y += 0.01

    renderer.render(scene, camera)

    requestAnimationFrame(animate)
}

animate()

And that's it ! Done ! I put everything in a codepen and let you play with it now.

I tried to make this article a highway for understanding Javascript 3D. I sincerely think that after this first barrier of understanding, you can quickly do incredible things! Go use you new power now.

A few weeks ago, I hadn't touched 3D in any way, shape or form. Starting from the basic example I just presented to you, in a few days, I created a 3D web experience that takes you through the universe in your browser.

I'm really super proud of it and I invite you to take a look at it. There's a story, music and it's amazing. A real show! If you're even more curious, you have all the source code on my GitHub.

Epilogue

If I can do this kind of thing in a week, that's proof that anyone can do it. Anything you can imagine as animation is within your reach with your knowledge of Javascript. And now that you have the ThreeJS base, it's up to you to see if the adventure tempts you.