I’ve dabbled in JavaScript since college, made a few web pages here and there and while JS was always an enjoyable break from C or Java, I regarded it as a fairly limited language, imbued with the special purpose of serving up animations and pretty little things to make users go “ooh” and “aah”. It was the first language I taught anyone who wanted to learn how to code because it was simple enough to pick up and would quickly deliver tangible results to the developer. Smash it together with some HTML and CSS and you have a web page. Beginner programmers love that stuff.

Then something happened two years ago. At that time, I was in a researchy position working mostly on server-side code and app prototypes for Android. It wasn’t long before Node.js popped up on my radar. Backend JavaScript? Who would take that seriously? At best, it seemed like a new attempt to make server-side development easier at the cost of performance, scalability, etc. Maybe it’s just my ingrained developer skepticism, but there’s always been that alarm that goes off in my brain when I read about something being fast and easy and production-level.

Then came the research, the testimonials, the tutorials, the side-projects and 6 months later I realized I had been doing nothing but Node since I first read about it. It was just too easy, especially since I was in the business of prototyping new ideas every couple months. But Node wasn’t just for prototypes and pet projects. Even big boy companies like Netflix had parts of their stack running Node. Suddenly, the world was full of nails and I had found my hammer.

Fast forward another couple months and I’m at my current job as a backend developer for Digg. When I joined, back in April of 2015, the stack at Digg was primarily Python with the exception of two services written in, wait for it, Node. I was even more thrilled to be assigned the task of reworking one of the services which had been causing issues in our pipeline.

Our troublesome Node service had a fairly straightforward purpose. Digg uses Amazon S3 for storage which is peachy, except S3 has no support for batch GET operations. Rather than putting all the onus on our Python web server to request up to 100+ keys at a time from S3, the decision was made to take advantage of Node’s easy async code patterns and great concurrency handling. And so Octo, the S3 content fetching service, was born.

Node Octo performed well except for when it didn’t. Once a day it needed to handle a traffic spike where the requests per minute jump from 50 to 200+. Also keep in mind that for each request, Octo typically fetches somewhere between 10–100 keys from S3. That’s potentially 20,000 S3 GETs a minute. The logs showed that our service slowed down substantially during these spikes, but the trouble was it didn’t always recover. As such, we were stuck bouncing our EC2 instances every couple weeks after Octo would seize up and fall flat on its face.

The requests to the service also pass along a strict timeout value. After the clock hits X number of milliseconds since receiving the request, Octo is supposed to return to the client whatever it has successfully fetched from S3 and move on. However, even with a max timeout of 1200ms, in Octo’s worst moments we had request handling times spiking up to 10 seconds.

The code was heavily asynchronous and we were caching S3 key values aggressively. Octo was also running across 2 medium EC2 instances which we bumped up to 4.

I reworked the code three times, digging deeper than ever into Node optimizations, gotchas, and tricks for squeezing every last bit of performance out of it. I reviewed benchmarks for popular Node webserver frameworks, like Express or Hapi, vs. Node’s built-in HTTP module. I removed any third party modules that, while nice to have, slowed down code execution. The result was three, one-off iterations all suffering from the same issue. No matter how hard I tried, I couldn’t get Octo to timeout properly and I couldn’t reduce the slow down during request spikes.

A theory eventually emerged and it had to do with the way Node’s event loop works. If you don’t know about the event loop, here’s some insight from Node Source:

Node’s “event loop” is central to being able to handle high throughput scenarios. It is a magical place filled with unicorns and rainbows, and is the reason Node can essentially be “single threaded” while still allowing an arbitrary number of operations to be handled in the background.

You can see when all the unicorns and rainbows went to hell and back again as we bounced the service.

With event loop blocking as the biggest culprit on my list, it was just a matter of figuring why it was getting so backed up in the first place.

Most developers have heard about Node’s non-blocking I/O model; it’s great because it means all requests are handled asynchronously without blocking execution, or incurring any overhead (like with threads and processes) and as the developer you can be blissfully unaware what’s happening in the backend. However, it’s always important to keep in mind that Node is single-threaded which means none of your code runs in parallel. I/O may not block the server but your code certainly does. If I call sleep for 5 seconds, my server will be unresponsive during that time.

Visualizing the Event Loop — StrongLoop

And the non-blocking code? As requests are processed and events are triggered, messages are queued along with their respective callback functions. To explain further, here’s an excerpt from a particularly insightful blog post from Carbon Five:

In a loop, the queue is polled for the next message (each poll
referred to as a “tick”) and when a message is encountered, the
callback for that message is executed. The calling of this callback
function serves as the initial frame in the call stack, and due to
JavaScript being single-threaded, further message polling and
processing is halted pending the return of all calls on the stack.
Subsequent (synchronous) function calls add new call frames to the
stack…

Our Node service may have handled incoming requests like champ if all it needed to do was return immediately available data. But instead it was waiting on a ton of nested callbacks all dependent on responses from S3 (which can be god awful slow at times). Consequently, when any request timeouts happened, the event and its associated callback was put on an already overloaded message queue. While the timeout event might occur at 1 second, the callback wasn’t getting processed until all other messages currently on the queue, and their corresponding callback code, were finished executing (potentially seconds later). I can only imagine the state of our stack during the request spikes. In fact, I didn’t need to imagine it. A little bit of CPU profiling gave us a pretty vivid picture. Sorry for all the scrolling.

As a quick intro to flame graphs, the y axis represents the number of frames on the stack, where each function is the parent of the function above it. The x axis has to do with the sample population more so than the passage of time. It’s the width of the boxes which show the total time on-CPU; greater width may indicate slower functions or it may simply mean that the function is called more often. You can see in Octo’s flame graph the huge spikes in our stack depth. More detailed info on profiling and flame graphs can be found here.

In light of these realizations, it was time to entertain the idea that maybe Node.js wasn’t the perfect candidate for the job. My CTO and I sat down and had a chat about our options. We certainly didn’t want to continue bouncing Octo every other week and we were both very interested in a promising case study that had cropped up on the internet: Handling 1 Million Requests per Minute with Go

If the title wasn’t tantalizing enough, the topic was on creating a service for making PUT requests to S3 (wow, other people have these problems too?). It wasn’t the first time we had talked about using Golang somewhere in our stack and now we had a perfect test subject.

Two weeks later, after my initial crash course introduction to Golang, we had a brand new Octo service up and running. I modeled it closely after the inspiring solution outlined in Malwarebyte’s Golang article; the service has a worker pool and a delegator which passes off incoming jobs to idle workers. Each worker runs on its own goroutine, and returns to the pool once the job is done. Simple and effective. The immediate results were pretty spectacular.

Our average response time from the service was almost cut in half, our timeouts (in the scenario that S3 was slow to respond) were happening on time, and our traffic spikes had minimal effects on the service.

Blue = Node.js Octo | Green = Golang Octo

With our Golang upgrade, we are easily able to handle 200 requests per minute and 1.5 million S3 item fetches per day. And those 4 load-balanced instances we were running Octo on initially? We’re now doing it with 2.

Since our transition to Golang we haven’t looked back. While the majority of our stack is (and probably will always be) in Python, we’ve begun the process of modularizing our code base and spinning up microservices to handle specific roles in our system. Alongside Octo, we now have 3 other Golang services in production which power our realtime message system and serve up important metadata for our content. We’re also very proud of the newest addition to our Golang codebase, DiggBot.

This is not to say that Golang is a silver bullet for all our problems. We’re careful to consider the needs of each of our services. As a company, we make the effort to stay on top of new and emerging technologies and to always ask ourselves, can we be doing this better? It’s a constantly evolving process and one that takes careful research and planning.

I’m proud to say that this story has a happy ending as our Octo service has been up and running for a couple months with great success (a few bug fixes aside). For now, Digg is going the way of the Gopher.

“_This article was originally published on Medium by Alexandra Grant

Suggest

☞ Google Go Programming for Beginners (Golang)

☞ Beginners : Google’s Go (golang) Programming Language

☞ Learn Google Go — Golang Programming for Beginners

☞ The Go Programming Language Guide: Code Like a Pro

Want to learn a different programming language? C# is a great place to start. Step through 24 practical and easy-to-understand C# training episodes, with our talented friend Bob Tabor, from Developer University, as he teaches you the fundamentals of C# programming. Tune in to learn the basics of the C# language, and learn to apply them in your programming endeavors, like video games, mobile environments, and client apps.

Learn C# by stepping through the basics with Bob: get the tools, see how to write code, debug features, explore customizations, and much more! Search for and focus on the information you need, in this C# for beginners course, which has topics separated out into individual videos. Get to know the grammar, create and use methods, manipulate strings, and see how to handle events. Plus, get a look at next steps as you learn to develop Windows and web applications.

1 | Course Introduction
Hear an introduction to the topic, learn expectations for the series, and hear tips on how to get the most out of it. Plus, find out where to download the software you need.

2 | Installing Visual Studio
Get the details on installing Visual Studio.

3 | Creating Your First C# Program
Learn how to create a simple application, and get an explanation of common solutions to different problems you might encounter as you begin writing and compiling code.

4 | Understanding Your First C# Program
To better understand the grammar of C# at a high level, return to the program we just built to break apart each of the key words and symbols.

5 | Working with Code Files, Projects, and Solutions
Learn how to open and close individual files in a project, the relationship between projects and solutions, and more.

6 | Understanding Data Types and Variables
Add C# syntax to your vocabulary by exploring fundamental building blocks: data types and variables. In addition, learn about basic topics, such as naming conventions and data type conversions.

7 | The if Decision Statement
Get an introduction to the if Decision statement, along with the conditional operator. Find out how to refactor code to make it more compact and less likely to produce errors.

8 | Operators, Expressions, and Statements
Learn how to create a properly formed C# statement made up of expressions that include operators and operands. Hear about compilation errors that occur when the syntax rules of C# are ignored.

9 | for Iteration Statement
Look at several different types of iteration statements, how to utilize “code snippets” to help remind you of the syntax for this complex statement, and debugging in action.

10 | Understanding Arrays
Learn about arrays, and see how to declare and utilize arrays. Watch demos on a couple of powerful built-in methods that give arrays added features.

11 | Defining and Calling Methods
Create a helper method, create and call methods to retrieve a value, create and use input parameters, learn about string formatting, and create overloaded methods.

12 | While Iteration Statement
Learn a new iteration statement that allows you to continue performing a block of code until a condition is no longer true.

13 | Working with Strings
Look at built-in String methods to manipulate the content inside of a literal string and at the StringBuilder class for concatenating many strings together in a memory- and resource-friendly manner.

14 | Working with Dates and Times
Find out how to work with Date and Time data, how to create new instances of DateTime, how to add time, and how to format the data for display. Take a look at the TimeSpan class.

15 | Understanding Classes
Learn how classes are defined and new instances are created, how to define Properties, and how to both set values and get values for a given instance of the class.

16 | More About Classes and Methods
Dig into more details about classes: create a new instance, add class references, pass the reference to a method. Plus, review overloaded methods, static versus instance methods, and constructors.

17 | Understanding Scope and Accessibility Modifiers
Explore variable scope and how accessibility modifiers are used by the .NET Framework Class Library to expose or hide implementation of their given services to consumers of that given class.

18 | Understanding Namespaces and Working with the .NET Class Library
Learn about namespaces and how to find the classes for your applications by searching Bing and MSDN.

19 | Creating and Adding References to Assemblies
Learn about .NET assemblies: code libraries and executables, debug and release versions of assemblies. Plus, see how to reference assemblies, utilize NuGet, and create references to custom libraries.

20 | Working with Collections
See an “old style” collection, along with several of the newer, strongly typed generic collections (List and Dictionary) utilizing the generics syntax.

21 | Working with LINQ
Explore Structured Query Language and the LINQ syntax. See a demo projecting data onto existing types and new anonymous types.

22 | Enumerations and the Switch Decision Statement
See a demo on the use of Enumerations, create a custom enumeration, and then use it in a simple application that demonstrates a third Decision statement, the switch.

23 | Gracefully Handling Exceptions
Learn how to use the try catch finally block to anticipate potential problems so as to shield the end user from those problems as much as possible. Explore best practices when checking for exceptions.

24 | Understanding Events and Event-Driven Programming
Learn how events are utilized in the .NET Framework Class Library. Begin with the Timer class, and graduate to building a basic “Hello world” application.

25 | Where to Go from Here
Hear approaches to solving common issues, where to go for help, how to search for answers, and become part of the .NET community. View a long-term path to learn more about developing applications.

Learn

Learn how to declare and utilize arrays.
Create and use methods.
Use iteration statements.
Manipulate strings.
Learn how to work with Date and Time data.
Define and create classes and use properties.
Apply more advanced class details.
Contrast variable scope and accessiblity modifiers.
Find and use namespaces.
Create and reference assemblies.
See how to use collections.
Learn when and how to use LINQ.
Use enumerations.
Prevent exceptions.
See a demo on how to handle events.
Explore next steps to learn more about developing Windows and web applications.
Understand course expectations, and obtain software.
Create an application.
Understand C# grammar.
Discover the relationship between projects and solutions.
Learn the fundamental building blocks of working with C#.
Use if Decision statements and the conditional operator.
Create a properly formed C# statement, and resolve compilation errors.
Understand iteration statements and when to use them.
See a demo on how to declare and utilize arrays.
Create and use methods.
Use iteration statements.
Manipulate strings.
Learn how to work with Date and Time data.
Define and create classes and use properties.
Use if Decision statements and the conditional operator.
See a demo on how to declare and utilize arrays.
Install Visual Studio.

If you found this post interesting, follow and support us.
Suggest for you:

☞C and C++ Programming : Step-by-Step Tutorial

☞Learn C programming: C language

☞Learn to Program with C++

☞Object Oriented Programming with C++

☞Advanced C++ Programming Training Course

I’ve always wanted to build a 3D game. I’ve just never had the time and energy to learn the intricacies of 3D programming. Then I discovered I didn’t need to…

While tinkering one day, I got to thinking that maybe I could simulate a 3D environment using CSS transformations. I stumbled across an old article about creating 3D worlds with HTML and CSS.

I wanted to simulate a Minecraft world (or a tiny part of it at least). Minecraft is a sandbox game, in which you can break and place blocks. I wanted the same kind of functionality, but with HTML, JavaScript, and CSS.

Come along as I describe what I learned, and how it can help you to be more creative with your CSS transformations!

Note: Most of the code for this tutorial can be found on Github. I’ve tested it in the latest version of Chrome. I can’t promise it will look exactly the same in other browsers, but the core concepts are universal.

This is just half of the adventure. If you’d like to know how to persist the designs to an actual server, check out the sister post, PHP Minecraft Mod. There we explore ways to interact with a Minecraft server, to manipulate it in real time and respond to user input.

The Things We’re Already Doing

I’ve written my fair share of CSS and I’ve come to understand it quite well, for the purpose of building websites. But that understanding is predicated on the assumption that I’m going to be working in a 2D space.

Let’s consider an example:

.tools {
      position: absolute;
      left: 35px;
      top: 25px;
      width: 200px;
      height: 400px;
      z-index: 3;
    }

    .canvas {
      position: absolute;
      left: 0;
      top: 0;
      width: 100%;
      height: 100%;
      z-index: 2;
    }

Here we have a canvas element, starting at the top left corner of the page, and stretching all the way to the bottom right. On top of that, we’re adding a tools element. It starts 25px from the left and 35px from the top of the page, and measures 200px wide by 400px high.

Depending on the order div.tools and div.canvas are added to the markup, it’s entirely possible that div.canvascould overlap div.tools. That is except for the z-index styles applied to each.

You’re probably used to thinking of elements, styled in this way, as 2D surfaces with the potential to overlap each other. But that overlapping is essentially a third dimension. left, top, and z-index may as well be renamed to x,y, and z. So long as we assume every element has a fixed depth of 1px, and z-index has an implicit px unit, we’re already thinking in 3D terms.

What some of us tend to struggle with are the concepts of rotation and translation in this third dimension…

The Theory of Transformations

CSS translations duplicate this familiar functionality, in an API that extends beyond the limitations top, left, and z-index place on us. It’s possible to replace some of our previous styles with translations:

.tools {
      position: absolute;
      background: green;
      /*
        left: 35px;
        top: 25px;
      */
      transform-origin: 0 0;
      transform: translate(35px, 25px);
      width: 200px;
      height: 400px;
      z-index: 3;
    }

Instead of defining left and top offsets (with an assumed origin of 0px from the left and 0px from the top), we can declare an explicit origin. We can perform all sorts of transformations on this element, for which use 0 0 as the centre. translate(35px, 25px) moves the element 35px to the right and 25px down. We can use negative values to move the element left and/or up.

With the ability to define an origin for our transformations, we can start to do other interesting things as well. For example, we can rotate and scale elements:

transform-origin: center;
    transform: scale(0.5) rotate(45deg);

Every element starts with a default transform-origin of 50% 50% 0, but a value of center sets x, y, and z to the equivalent of 50%. We can scale our element to a value between 0 and 1, and rotate it (clockwise) by degrees or radians. And we can convert between the two with:

• 45deg = (45 * Math.PI) / 180 ≅ 0.79rad
• 0.79rad = (0.79 * 180) / Math.PI ≅ 45deg

To rotate an element anti-clockwise, we just need to use a negative deg or rad value.

What’s even more interesting, about these transformations, is that we can use 3D versions of them.

Evergreen browsers have pretty good support for these styles, though they may require vendor prefixes. CodePen has a neat “autoprefix” option, but you can add libraries like PostCSS to your local code to achieve the same thing.

The First Block

Let’s begin to create our 3D world. We’ll start by making a space in which to place our blocks. Create a new file, called index.html:

<!doctype html>
    <html>
      <head>
        <style>
          html, body {
            padding: 0;
            margin: 0;
            width: 100%;
            height: 100%;
          }

          .scene {
            position: absolute;
            left: 50%;
            top: 50%;
            margin: -192px 0 0 -192px;
            width: 384px;
            height: 384px;
            background: rgba(100, 100, 255, 0.2);
            transform: rotateX(60deg) rotateZ(60deg);
            transform-style: preserve-3d;
            transform-origin: 50% 50% 50%;
          }
        </style>
      </head>
      <body>
        <div class="scene"></div>
        <script src="https://code.jquery.com/jquery-3.1.0.slim.min.js"></script>
        <script src="http://ricostacruz.com/jquery.transit/jquery.transit.min.js"></script>
        <script>
          // TODO
        </script>
      </body>
    </html>

Here we stretch the body to the full width and height, resetting padding to 0px. Then we create a smallishdiv.scene, which we’ll use to hold various blocks. We use 50% left and top, as well as a negative left and topmargin (equal to half the width and height) to horizontally and vertically centre it. Then we tilt it slightly (using 3D rotation) so that we have a perspective view of where the blocks will be.

Notice how we define transform-style:preserve-3d. This is so that child elements can also be manipulated in a 3D space.

Now, let’s start to add a block shape to the scene. We’ll need to create a new JavaScript file, called block.js:

"use strict"

    class Block {
      constructor(x, y, z) {
        this.x = x;
        this.y = y;
        this.z = z;

        this.build();
      }

      build() {
        // TODO: build the block
      }

      createFace(type, x, y, z, rx, ry, rz) {
        // TODO: return a block face
      }

      createTexture(type) {
        // TODO: get the texture
      }
    }

Each block needs to be a 6-sided, 3D shape. We can break the different parts of construction into methods to (1) build the whole block, (2) build each surface, and (3) get the texture of each surface.

Each of these behaviours (or methods) are contained within an ES6 class. It’s a neat way to group data structures and the methods that operate on them together. You may be familiar with the traditional form:

function Block(x, y, z) {
      this.x = x;
      this.y = y;
      this.z = z;

      this.build();
    }

    var proto = Block.prototype;

    proto.build = function() {
      // TODO: build the block
    };

    proto.createFace = function(type, x, y, z, rx, ry, rz) {
      // TODO: return a block face
    }

    proto.createTexture = function(type) {
      // TODO: get the texture
    }

This may look a little different, but it’s much the same. In addition to shorter syntax, ES6 classes also provide shortcuts for extending prototypes and calling overridden methods. But I digress…

Let’s work from the bottom up:

createFace(type, x, y, z, rx, ry, rz) {
      return $(`<div class="side side-${type}" ></div>`)
        .css({
          transform: `
            translateX(${x}px)
            translateY(${y}px)
            translateZ(${z}px)
            rotateX(${rx}deg)
            rotateY(${ry}deg)
            rotateZ(${rz}deg)
          `,
          background: this.createTexture(type)
        });
    }

    createTexture(type) {
      return `rgba(100, 100, 255, 0.2)`;
    }

Each surface (or face) consists of a rotated and translated div. We can’t make elements thicker than 1px, but we can simulate depth by covering up all the holes and using multiple elements parallel to each other. We can give the block the illusion of depth, even though it is hollow.

To that end, the createFace method takes a set of coordinates: x, y, and z for the position of the face. We also provide rotations for each axis, so that we can call createFace with any configuration and it will translate and rotate the face just how we want it to.

Let’s build the basic shape:

build() {
      const size = 64;
      const x = this.x * size;
      const y = this.y * size;
      const z = this.z * size;

      const block = this.block = $(`<div class="block" ></div>`)
        .css({
          transform: `
            translateX(${x}px)
            translateY(${y}px)
            translateZ(${z}px)
          `
        });

      $(`<div class="x-axis" ></div>`)
        .appendTo(block)
        .css({
          transform: `
            rotateX(90deg)
            rotateY(0deg)
            rotateZ(0deg)
          `
        });

      $(`<div class="y-axis" ></div>`)
        .appendTo(block)
        .css({
          transform: `
            rotateX(0deg)
            rotateY(90deg)
            rotateZ(0deg)
          `
        });

      $(`<div class="z-axis" ></div>`)
        .appendTo(block);
    }

We’re used to thinking in terms of single pixel positions, but a game like Minecraft works at a larger scale. Every block is bigger, and the coordinate system deals with the position of the block, not individual pixels that make it up. I want to convey the same sort of idea here…

When someone creates a new block, at 1 × 2 × 3, I want that to mean 0px × 64px × 128px. So we multiply each coordinate by the default size (in this case 64px, because that’s the size of the textures in the texture pack we’ll be using).

Then we create a container div (which we call div.block). Inside it we place another 3 divs. These will show us the axis of our block – they’re like guides in a 3D rendering program. We should also add some new CSS for our block:

.block {
      position: absolute;
      left: 0;
      top: 0;
      width: 64px;
      height: 64px;
      transform-style: preserve-3d;
      transform-origin: 50% 50% 50%;
    }

    .x-axis,
    .y-axis,
    .z-axis {
      position: absolute;
      left: 0;
      top: 0;
      width: 66px;
      height: 66px;
      transform-origin: 50% 50% 50%;
    }

    .x-axis {
      border: solid 2px rgba(255, 0, 0, 0.3);
    }

    .y-axis {
      border: solid 2px rgba(0, 255, 0, 0.3);
    }

    .z-axis {
      border: solid 2px rgba(0, 0, 255, 0.3);
    }

This styling is similar to what we’ve seen before. We need to remember to set transform-style:preserve-3d on the.block, so that the axis are rendered in their own 3D space. We give each a different colour, and make them slightly bigger than the block they’re contained in. This is so that they’ll be visible even when the block has sides.

Let’s create a new block, and add it to the div.scene:

let first = new Block(1, 1, 1);

    $(".scene").append(first.block);

Now, let’s add those faces:

this
      .createFace("top", 0, 0, size / 2, 0, 0, 0)
      .appendTo(block);

    this
      .createFace("side-1", 0, size / 2, 0, 270, 0, 0)
      .appendTo(block);

    this
      .createFace("side-2", size / 2, 0, 0, 0, 90, 0)
      .appendTo(block);

    this
      .createFace("side-3", 0, size / -2, 0, -270, 0, 0)
      .appendTo(block);

    this
      .createFace("side-4", size / -2, 0, 0, 0, -90, 0)
      .appendTo(block);

    this
      .createFace("bottom", 0, 0, size / -2, 0, 180, 0)
      .appendTo(block);

I found this code to be a bit of trial and error (owing to my limited experience with 3D perspective). Each element starts off in exactly the same position as the div.z-axis element. That is, in the vertical centre of the div.block and facing the top.

So, for the “top” element, I had to translate it “up” by half the size of the block, but I didn’t have to rotate it in any way. For the “bottom” element, I had to rotate it 180 degrees (along the x or y axis), and move it down by half the size of the block.

Using similar thinking, I rotated and translated each of the remaining sides. I also had to add corresponding CSS for them:

.side {
      position: absolute;
      left: 0;
      top: 0;
      width: 64px;
      height: 64px;
      backface-visibility: hidden;
      outline: 1px solid rgba(0, 0, 0, 0.3);
    }

Adding backface-visibility:hidden prevents the “bottom” side of the elements from being rendered. Usually they would just appear the same (only mirrored) no matter how they were rotated. With hidden back faces, only the “top” side is rendered. Take care when turning this on: your surfaces need to be rotated the right way around or sides of the block will just disappear. That’s the reason for the 90/270/-90/-270 rotations I’ve given the sides.

Let’s make this block look a bit more realistic. We need to create a new file, called block.dirt.js, and override thecreateTexture method:

"use strict"

    const DIRT_TEXTURES = {
      "top": [
        "textures/dirt-top-1.png",
        "textures/dirt-top-2.png",
        "textures/dirt-top-3.png"
      ],
      "side": [
        "textures/dirt-side-1.png",
        "textures/dirt-side-2.png",
        "textures/dirt-side-3.png",
        "textures/dirt-side-4.png",
        "textures/dirt-side-5.png"
      ]
    };

    class Dirt extends Block {
      createTexture(type) {
        if (type === "top" || type === "bottom") {
          const texture = DIRT_TEXTURES.top.random();

          return `url(https://medium.com/$%7Btexture%7D)`;
        }

        const texture = DIRT_TEXTURES.side.random();

        return `url(https://medium.com/$%7Btexture%7D)`;
      }
    }

    Block.Dirt = Dirt;

We’re going to use a popular texture pack, called Sphax PureBDCraft. It’s free to download and use (provided you’re not try to sell it on), and it comes in a variety of sizes. I’m using the x64 version.

We begin by defining a look-up table for the textures of the sides and top of the block. The texture pack doesn’t specify which textures should be used for the bottom, so we’ll just reuse the top textures.

If the side needing a texture is “top” or “bottom”, then we fetch a random texture from the “top” list. The random method doesn’t exist, until we define it:

Array.prototype.random = function() {
      return this[Math.floor(Math.random() * this.length)];
    };

Similarly, if we need a texture for a side, we fetch a random one. These textures are seamless, so the randomisation works in our favour.

Making a Scene

How do we make this interactive? Well, a good place to start is with a scene. We’ve already been placing blocks in the scene, so now we just have to enable dynamic placement!

To begin with, we can render a flat surface of blocks:

const $scene = $(".scene");

    for (var x = 0; x < 6; x++) {
      for (var y = 0; y < 6; y++) {
        let next = new Block.Dirt(x, y, 0);
        next.block.appendTo($scene);
      }
    }

Great, that gives us a flat surface to start adding blocks to. Now, let’s highlight surfaces as we hover over them with our cursor:

.block:hover .side {
      outline: 1px solid rgba(0, 255, 0, 0.5);
    }

Something strange is going on, though:

This is because the surfaces are clipping through each other randomly. There’s no nice way to fix this problem, but we can prevent it from happening by scaling the blocks slightly:

const block = this.block = $(`<div class="block" ></div>`)
      .css({
        transform: `
          translateX(${x}px)
          translateY(${y}px)
          translateZ(${z}px)
          scale(0.99)
        `
      });

While this does make things look better, it will affect performance the more blocks there are in the scene. Tread lightly when scaling many elements at a time…

Let’s tag each surface with the block and type that belong to it:

createFace(type, x, y, z, rx, ry, rz) {
      return $(`<div class="side side-${type}" ></div>`)
        .css({
          transform: `
            translateX(${x}px)
            translateY(${y}px)
            translateZ(${z}px)
            rotateX(${rx}deg)
            rotateY(${ry}deg)
            rotateZ(${rz}deg)
          `,
          background: this.createTexture(type)
        })
        .data("block", this)
        .data("type", type);
    }

Then, as we click on a surface, we can derive a new set of coordinates and create a new block:

function createCoordinatesFrom(side, x, y, z) {
      if (side == "top") {
        z += 1;
      }

      if (side == "side-1") {
        y += 1;
      }

      if (side == "side-2") {
        x += 1;
      }

      if (side == "side-3") {
        y -= 1;
      }

      if (side == "side-4") {
        x -= 1;
      }

      if (side == "bottom") {
        z -= 1;
      }

      return [x, y, z];
    }

    const $body = $("body");

    $body.on("click", ".side", function(e) {
      const $this = $(this);
      const previous = $this.data("block");

      const coordinates = createCoordinatesFrom(
        $this.data("type"),
        previous.x,
        previous.y,
        previous.z
      );

      const next = new Block.Dirt(...coordinates);

      next.block.appendTo($scene);
    });

createCoordinatesFrom has a simple but important task. Given the type of side, and the coordinates for the block to which it belongs, createCoordinatesFrom should return a new set of coordinates. These are where the new block will be placed.

Then we’ve attached an event listener. It will be triggered for each div.side that gets clicked. As this happens, we get the block to which the side belongs, and derive a new set of coordinates for the next block. Once we have those, we create the block and append it to the scene.

Seeing Ghosts

It would be helpful to see an outline of the block that we’re about to place, before we place it. This is sometimes referred to as “showing a ghost” of the thing we’re about to do.

The code to enable this is quite similar to that which we’ve already seen:

let ghost = null;

    function removeGhost() {
      if (ghost) {
        ghost.block.remove();
        ghost = null;
      }
    }

    function createGhostAt(x, y, z) {
      const next = new Block.Dirt(x, y, z);

      next.block
        .addClass("ghost")
        .appendTo($scene);

      ghost = next;
    }

    $body.on("mouseenter", ".side", function(e) {
      removeGhost();

      const $this = jQuery(this);
      const previous = $this.data("block");

      const coordinates = createCoordinatesFrom(
        $this.data("type"),
        previous.x,
        previous.y,
        previous.z
      );

      createGhostAt(...coordinates);
    });

    $body.on("mouseleave", ".side", function(e) {
      removeGhost();
    });

The main difference is that we maintain a single instance of the ghost block. As each new one is created, the old one is removed. This could benefit from a few additional styles:

.ghost {
      pointer-events: none;
    }

    .ghost .side {
      opacity: 0.6;
      pointer-events: none;
      -webkit-filter: brightness(1.5);
    }

Left active, the pointer events associated with the elements of the ghost would counteract the mouseenter andmouseleave events of the side underneath. Since we don’t need to interact with the ghost elements, we can disable these pointer events.

Changing Perspective

The more interactivity we add, the harder it is to see what’s going on. It seems like a good time to do something about that. It’d be awesome if we could zoom and rotate the viewport, to be able to see what’s going on a little better…

Let’s start with zoom. Many interfaces (and games) allow viewport zooming by scrolling the mouse wheel. Different browsers handle mouse wheel events in different ways, so it make sense to use an abstraction library.

Once that’s installed, we can hook into the events:

let sceneTransformScale = 1;

    $body.on("mousewheel", function(event) {
      if (event.originalEvent.deltaY > 0) {
        sceneTransformScale -= 0.05;
      } else {
        sceneTransformScale += 0.05;
      }

      $scene.css({
        "transform": `
          scaleX(${sceneTransformScale})
          scaleY(${sceneTransformScale})
          scaleZ(${sceneTransformScale})
        `
      });
    });

Now we can control the scale of the entire scene, just by scrolling the mouse wheel. Unfortunately, the moment we do, the rotations are overridden. We need to take the rotation into account, as we allow dragging the viewport with the mouse to adjust it:

let sceneTransformX = 60;
    let sceneTransformY = 0;
    let sceneTransformZ = 60;
    let sceneTransformScale = 1;

    const changeViewport = function() {
      $scene.css({
        "transform": `
          rotateX(${sceneTransformX}deg)
          rotateY(${sceneTransformY}deg)
          rotateZ(${sceneTransformZ}deg)
          scaleX(${sceneTransformScale})
          scaleY(${sceneTransformScale})
          scaleZ(${sceneTransformScale})
        `
      });
    };

This function won’t only account for the scale factor of the scene, but also the x, y, and z rotations factors. We also need to change our zooming event listener:

$body.on("mousewheel", function(event) {
      if (event.originalEvent.deltaY > 0) {
        sceneTransformScale -= 0.05;
      } else {
        sceneTransformScale += 0.05;
      }

      changeViewport();
    });

Now, we can start to rotate the scene. We need:

1. An event listener for when the drag action starts
2. An event listener for when the mouse moves (while dragging)
3. An event listener for when the drag action stops

Something like these should do the trick:

Number.prototype.toInt = String.prototype.toInt = function() {
      return parseInt(this, 10);
    };

    let lastMouseX = null;
    let lastMouseY = null;

    $body.on("mousedown", function(e) {
      lastMouseX = e.clientX / 10;
      lastMouseY = e.clientY / 10;
    });

    $body.on("mousemove", function(e) {
      if (!lastMouseX) {
        return;
      }

      let nextMouseX = e.clientX / 10;
      let nextMouseY = e.clientY / 10;

      if (nextMouseX !== lastMouseX) {
        deltaX = nextMouseX.toInt() - lastMouseX.toInt();
        degrees = sceneTransformZ - deltaX;

        if (degrees > 360) {
            degrees -= 360;
        }

        if (degrees < 0) {
            degrees += 360;
        }

        sceneTransformZ = degrees;
        lastMouseX = nextMouseX;

        changeViewport();
      }

      if (nextMouseY !== lastMouseY) {
        deltaY = nextMouseY.toInt() - lastMouseY.toInt();
        degrees = sceneTransformX - deltaY;

        if (degrees > 360) {
            degrees -= 360;
        }

        if (degrees < 0) {
            degrees += 360;
        }

        sceneTransformX = degrees;
        lastMouseY = nextMouseY;

        changeViewport();
      }
    });

    $body.on("mouseup", function(e) {
      lastMouseX = null;
      lastMouseY = null;
    });

On mousedown we capture the initial mouse x and y coordinates. As the mouse moves (if the button is still being pressed) we adjust the sceneTransformZ and sceneTransformX by a scaled amount. There’s no harm in letting the values go over 360 degrees or below 0 degrees, but these would look terrible if we wanted to render them onscreen.

Computation inside a mousemove event listener can be computationally expensive due to how much this even listener may be triggered. There are potentially millions of pixels on the screen, and this listener could be triggered as the mouse moves to each one. That is why we exit early if the mouse button isn’t being held down.

When the mouse button is released, we unset the lastMouseX and lastMouseY, so that the mousemove listener stops computing things. We could just clear lastMouseX, but clearing both feels cleaner to me.

Unfortunately, the mousedown event can interfere with the click event on block sides. We can get around this by preventing event bubbling:

$scene.on("mousedown", function(e) {
      e.stopPropagation();
    });

Give it a whirl…

Removing Blocks

Let’s round out the experiment by adding the ability to remove blocks. We need to do a couple of subtle but important things:

1. Change hover border colour from green to red
2. Disable the block ghosts

It’ll be easier to do these with CSS, as long as we have a body class to indicate whether we’re in addition (normal) mode or subtraction mode:

$body.on("keydown", function(e) {
      if (e.altKey || e.controlKey || e.metaKey) {
        $body.addClass("subtraction");
      }
    });

    $body.on("keyup", function(e) {
      $body.removeClass("subtraction");
    });

When a modifier key is pressed (alt, control, or command), this code will make sure body has a subtractionclass. This makes it easier to target various elements using this class:

.subtraction .block:hover .side {
      outline: 1px solid rgba(255, 0, 0, 0.5);
    }

    .subtraction .ghost {
      display: none;
    }

We’re checking for a number of modifier keys, since different operating systems intercept different modifiers. For example, altKey and metaKey work on macOS, whereas controlKey works on Ubuntu.

If we click on a block, when we’re in subtraction mode, we should remove it:

$body.on("click", ".side", function(e) {
      const $this = $(this);
      const previous = $this.data("block");

      if ($body.hasClass("subtraction")) {
        previous.block.remove();
        previous = null;
      } else {
        const coordinates = createCoordinatesFrom(
          $this.data("type"),
          previous.x,
          previous.y,
          previous.z
        );

        const next = new Block.Dirt(...coordinates);
        next.block.appendTo($scene);
      }
    });

This is the same .side click event listener we had before, but instead of just adding new blocks when a side is clicked, we first check if we’re in subtraction mode. If we are, the block we just clicked is removed from the scene.

There’s a long way to go before we support as many blocks and interactions as Minecraft, but this is a good start. What’s more, we managed to achieve this without needing to study advanced 3D techniques. It’s an unconventional (and creative) use of CSS transformations!

If you’re keen to do more with this code, head over to the other half of this adventure. You don’t have to be a PHP expert to interact with Minecraft servers. And just imagine the awesome things you can do with that knowledge…

Suggest

☞ Unity 5 Host Your Game Server Online like a PRO

☞ Mastering 3D Animation in Unity

☞ JavaScript Bootcamp — 2016

☞ Upgrade your JavaScript to ES6

☞ JavaScript Tutorials: Understanding the Weird Parts

Authentication is one of the vital parts of any web application. There are innumerable libraries and frameworks that provide various options to perform authentication one way or another. These libraries take away much of the groundwork required to setup an authentication system, providing “magic” with what’s happening behind the scenes. For Rails, we have a number of authentication systems, the prominent one being Devise.

Devise is an authentication engine that runs as part of our application and does all the heavy lifting when it comes to authentication. However, often times we don’t need many of the parts it provides. For example, Devise doesn’t work very well with API-based systems, which is why we have the devise_token_auth gem. devise_token_auth is a library that does what Devise does, but with tokens instead of sessions.

Today we’re going to explore building our own custom JWT-based authentication system from scratch. Let’s get started.

Why JWT

JWT (JSON Web Token, pronounced “jot”) is a self-contained authentication standard designed for securely exchanging data between systems. Since it’s self-contained, it doesn’t need any backing storage to work. Also, the JWT approach is very reliable and flexible, allowing it to be used with any client. It doesn’t have any overhead to get started and almost all languages have libraries that make working with JWTs a breeze.

We already have an excellent tutorial about JWT and how to use it with Rails. If you’re new to JWT I’d suggest you to read it first to get an idea of what we’re going to create.

Model

We’ll begin by building a model for our app. The application will authenticae users, so let’s create a User model.

rails g model user

This command will create a migration file under db/migrate called XXX_create_users, where XXX is the current date. Add the following code to this file, which will add the columns we need:

create_table :users do |t|
      t.string :email,              null: false
      t.string :password_digest,    null: false
      t.string   :confirmation_token
      t.datetime :confirmed_at
      t.datetime :confirmation_sent_at

      t.timestamps
    end

Run rake db:migrate to run the migration.

We’re adding email and password_digest columns here, which are the basic columns required to register or authenticate a user. Of course, you can add more columns that makes sense, if you like. The confirmation_token,confirmed_at, and confirmation_sent_at columns are required for user confirmation. You can skip this if you don’t wish to confirm the emails.

Validations

Let’s add our validations to models/user.rb:

validates_presence_of :email
    validates_uniqueness_of :email, case_sensitive: false
    validates_format_of :email, with: /@/

We’re validating the uniqueness of email without case sensitivity and doing a simple format check of the email ensuring there is a @ in the email string. This might not be a solid validation, but there is no standard one and that’s why we verify the email upon registration.

Callbacks

We are going to make use of Rails’s has_secure_password for handling the password hashing.

To start, add the gem bcrypt (it’s probably there, but commented out) to your Gemfile and run bundle install. Once the gem is installed, add the following line inside the User class in the file models/user.rb:

class User < ApplicationRecord
   has_secure_password
   ...

Let’s also add callbacks that we want to perform before user creation. First, we’d want to lowercase the email and strip any spaces. Second, we’d have to generate a confirmation token that will be sent in the email to the user.

Add these before callbacks to the models/user.rb file:

before_save :downcase_email
    before_create :generate_confirmation_instructions

We downcase the email before saving it to the DB. The confirmation instructions should be generated only during the creation of the user record. Let’s add the methods:

def downcase_email
      self.email = self.email.delete(' ').downcase
    end

    def generate_confirmation_instructions
      self.confirmation_token = SecureRandom.hex(10)
      self.confirmation_sent_at = Time.now.utc
    end

If you plan to skip the confirmation, you can omit the above method and the corresponding callback.

Registration

Create

We now have the model setup, so let’s add an endpoint for user creation. Create our users controller:

rails g controller users

Add the below line to config/routes.rb:

def create
      user = User.new(user_params)

      if user.save
        render json: {status: 'User created successfully'}, status: :created
      else
        render json: { errors: user.errors.full_messages }, status: :bad_request
      end
    end

    private

    def user_params
      params.require(:user).permit(:email, :password, :password_confirmation)
    end

We now have generated our UsersController. Head over to the controller (app/controllers/users_controller.rb) and add the following lines:

def create
  user = User.new(user_params)

  if user.save
    render json: {status: 'User created successfully'}, status: :created
  else
    render json: { errors: user.errors.full_messages }, status: :bad_request
  end
end

private

def user_params
  params.require(:user).permit(:email, :password, :password_confirmation)
end

We now have an API endpoint to create a user! You can try it by starting the server and sending a POST request with the user details as JSON in the body. Here’s an example of what you could post to http://localhost:3000/users:

{
      user: {
        email: 'test@example.com',
        password: 'anewpassword',
        password_confirmation: 'anewpassword'
      }
    }

You should receive the User created successfully message as the response. Subsequent requests with the same data should respond with error messages. That’s our validations in play. For those who are skipping the confirmation part, you can skip the following and head to the Login section.

Confirmation

One thing that is pending is the user confirmation. We are going to send an email confirmation to the user before creation and create an endpoint that validates the token to confirm the user.

To start, we have to send an email to the user when the record is successfully created. We wouldn’t be going through how to send emails since there are already good tutorials that cover how to do it. We should add the line to send email right after user.save in users_controller.

...
    if user.save
      #Invoke send email method here
    ...

Just make sure that you include the user.confirmation_token in your email. Ideally, the URL should lead to an endpoint that fetches the token and posts it to our API. Let’s create that post API endpoint.

Adda route to our config/routes.rb file for the confirm endpoint:

resources :users, only: :create do
      collection do
        post 'confirm'
      end
    end

Now, create the confirm action in UsersController:

def confirm
      token = params[:token].to_s

      user = User.find_by(confirmation_token: token)

      if user.present? && user.confirmation_token_valid?
        user.mark_as_confirmed!
        render json: {status: 'User confirmed successfully'}, status: :ok
      else
        render json: {status: 'Invalid token'}, status: :not_found
      end
    end

Let’s see what we’re doing here. First, we are fetching the token from params, calling to_s to handle the case where the token is not sent in the request. Next, fetch the corresponding user based on the confirmation token.

If the user is present and the confirmation isn’t expired, call the model method mark_as_confirmed! and respond with a success message. We have to add the confirmation_token_valid? and mark_as_confirmed! methods to ourUser model:

def confirmation_token_valid?
      (self.confirmation_sent_at + 30.days) > Time.now.utc
    end

    def mark_as_confirmed!
      self.confirmation_token = nil
      self.confirmed_at = Time.now.utc
      save
    end

The confirmation_token_valid? method checks if the confirmation was sent in the last 30 days and, thus, is not expired. You can change it to any value you wish.

mark_as_confirmed! saves the confirmed time and nullifies the confirmation token so that the same confirmation email can’t be used to confirm the user again.

We now have the endpoint to confirm a user. You can test it by sending a post request to the endpointusers/confirm?token=<CONFIRMATION_TOKEN> and check the confirmed_at and confirmation_token value for the user. You should get User confirmed successfully. Subsequent requests with the same token should return Invalid token.

We now have a working registration as part of our app. Let’s create the final piece: the login endpoint.

Login

For login, we are going to create an endpoint to log the user in by sending the credentials of the user and responding with a JWT token. We also will add a helper method that can be used to secure endpoints that we want to be exposed only to authenticated users.

Controller

Let’s add the login route to our config/routes.rb file under users resource:

resources :users, only: :create do
        collection do
          post 'confirm'
          post 'login'
        end
    end

We have created a users/login route now. The controllers require some modification to pull in the json_web_tokencode and create the corresponding action in the UsersController.

In controllers/application_controller.rb, add the below line right after the class definition:

require 'json_web_token'

In controllers/users_controller.rb add the following snippet:

def login
      user = User.find_by(email: params[:email].to_s.downcase)

      if user && user.authenticate(params[:password])
          auth_token = JsonWebToken.encode({user_id: user.id})
          render json: {auth_token: auth_token}, status: :ok
      else
        render json: {error: 'Invalid username / password'}, status: :unauthorized
      end
    end

Let’s go over this method step by step. First, we’re fetching the user from the email and, if present, call theauthenticate method passing the password that is supplied. The authenticate method is provided by thehas_secure_password helper.

Once we verify the email and password, encode the user’s id into a JWT token via our encode method fromJsonWebToken lib which we have yet to create. Then, return the token.

For those who are confirming emails, we have to disallow users who aren’t confirmed. Modify the controller action to include one more conditional:

...
    if user && user.authenticate(params[:password])
      if user.confirmed_at?
        auth_token = JsonWebToken.encode({user_id: user.id})
        render json: {auth_token: auth_token}, status: :ok
      else
        render json: {error: 'Email not verified' }, status: :unauthorized
      end
    else
    ...

Checking if the confirmed_at field is not empty does the job, meaning user has been confirmed before allowing them to login.

JWT Library

Now, let’s add the JWT library. Begin by adding the following gem to your Gemfile and do bundle install:

gem 'jwt'

Once done, create a file called json_web_token.rb under lib/ and add these lines:

require 'jwt'

    class JsonWebToken
      # Encodes and signs JWT Payload with expiration
      def self.encode(payload)
        payload.reverse_merge!(meta)
        JWT.encode(payload, Rails.application.secrets.secret_key_base)
      end

      # Decodes the JWT with the signed secret
      def self.decode(token)
        JWT.decode(token, Rails.application.secrets.secret_key_base)
      end

      # Validates the payload hash for expiration and meta claims
      def self.valid_payload(payload)
        if expired(payload) || payload['iss'] != meta[:iss] || payload['aud'] != meta[:aud]
          return false
        else
          return true
        end
      end

      # Default options to be encoded in the token
      def self.meta
        {
          exp: 7.days.from_now.to_i,
          iss: 'issuer_name',
          aud: 'client',
        }
      end

      # Validates if the token is expired by exp parameter
      def self.expired(payload)
        Time.at(payload['exp']) < Time.now
      end
    end

Let’s go through the code. First, in the encode method, merge the payload which is the user id with meta information such as expiry, issuer, and audience. You can learn about these “meta” claims from the JWT tutorial linked at the beginning of this post. Once merged, encode the payload using the JWT.encode method along with the secret key from our server. It is important that this key is kept secure since this is the master key for all the tokens our app issues.

Then, the decode method, which uses the decode method from the jwt gem to (you guessed it) decode the payload using the secret key. We have a couple of other helper methods, one is valid_payload which validates if the payload has been tampered with, and the expired method which validates whether the token has expired. The default expiry is set in the meta method which is 7 days, but you are free to change it as per your requirement.

Now we have a functioning login endpoint that we can use to login the user. Try calling the endpoint users/loginwith the below formatted data in the request body:

{
      "email": "test@example.com",
      "password": "anewpassword"
    }

You should see a response similar to this,

{
      "auth_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxLCJleHAiOjE0NzUzMTM5OTQsImlzcyI6Imlzc3Vlcl9uYW1lIiwiYXVkIjoiY2xpZW50In0.5P3qJKelCdbTixnLyIrsLKSVnRLCv2lvHFpXqVKdPOs"
    }

There it is. Our authentication token for the user. We can now use this token to validate each request for the user.

Authentication Helper

Alright, we are going to create a helper method that gets the token from the header, validates the payload, and fetches the corresponding user from the DB. Open up /app/controllers/application_controller.rb and add the following:

protected
# Validates the token and user and sets the @current_user scope
def authenticate_request!
  if !payload || !JsonWebToken.valid_payload(payload.first)
    return invalid_authentication
  end

  load_current_user!
  invalid_authentication unless @current_user
end

# Returns 401 response. To handle malformed / invalid requests.
def invalid_authentication
  render json: {error: 'Invalid Request'}, status: :unauthorized
end

private
# Deconstructs the Authorization header and decodes the JWT token.
def payload
  auth_header = request.headers['Authorization']
  token = auth_header.split(' ').last
  JsonWebToken.decode(token)
rescue
  nil
end

# Sets the @current_user with the user_id from payload
def load_current_user!
  @current_user = User.find_by(id: payload[0]['user_id'])
end

Here, authenticate_request! is the helper method that we are going to use to authenticate controller actions. It fetches the payload from the Authorization header of the request, then validates the payload using thevalid_payload method, which we’ve seen before. Once confirmed valid, it fetches the user using the user_id in the payload, loading the user record into the scope.

We can now add the authenticate_request method as a before_filter to any controller action that we want to be authenticated for the user.

Conclusion

With that we have come to the conclusion of this tutorial. We covered the meaty aspects of user authentication — registration, confirmation, and login — all through an API using JWT. You can take this forward as is or make any sort of modifications to parts of it, maybe adding separate components like password reset, email update, locking accounts, and much more.

The example app is hosted on github. Feel free to fork and mess with it.

I thank you for reading this tutorial and I hope it serves your purposes. Happy learning.

Suggest

☞ Learn Rails: Build a Network Chatroom

☞ Make Medium (medium.com) Clone in Ruby on Rails

☞ Learn Rails: Quickly Code, Style and Launch 4 Web Apps

☞ Rails 5: Learning Web Development the Ruby Way

☞ Professional Rails Code Along

Web Development has evolved tremendously in the last 20 years. A modern development environment would be unrecognizable to to someone developing Coldfusion in the late ’90s for example. The greater focus on best practices and developer productivity have certainly made software more maintainable, but this comes at the cost of added complexity. To navigate this complexity, a modern development environment is required; this article will outline some of my personal favorite tools.

Tmux

Tmux is a terminal multiplexer (think screen), which means you can have several terminals in the same shell session. It allows you to split panes and move them around and reconnect to a tmux session from a different machine. This particularly shines when it is deployed on a server, as you can start a long-running task, disconnect, and your tmux session will keep running.

The real strength in Tmux for development lies in knowing in which window each of your different tools is running because with some quick window changing shortcuts, you can move so quickly that flow becomes instinctual. To aid this, tmuxinator sets up profiles (protip: bind these to Tmux shortcuts to facilitate easy opening of different types of projects like Rails, Sinatra, etc), which complements Tmux nicely.

Additionally, Tmux is extendable through its plugin ecosystem. Take a look, but I would recommend the Tmux Plugin Manager, tmux-battery, and tmux sensible.

If you are looking for a simple start with Tmux, check out this article.

Fish

Bash is fine and all, but it hasn’t aged very well and better terminal alternatives are available. ZSH is an excellent choice, but I personally lack the motivation to invest time in learning how to configure yet another piece of software. To this end, I would recommend Fish. It has excellent command completion, is fully scriptable, and looks much nicer than Bash. Best of all, it just works out of the box (although there are a couple of minor idiosyncrasies you’ll run into. Also, your Bash aliases won’t work, but translating is straightforward and these are comparatively low setup costs). I particularly enjoy interfacing with Git this way, but I recently discovered the excellent Gitsome, which offers excellent Github integration and unparalleled autocomplete, so I am currently vacillating between the two.

Vim

Vim is the cornerstone of my environment. Heavily customized to speed development, it bears more of a resemblance to a fully fledged (albeit lightweight!) IDE. Let’s walk through some generally useful plugins, and then get to some Ruby-specific ones. You can download my vim dotfiles here.

Navigating a project can be cumbersome. Fortunately, Vim’s rich ecosystem really comes into its own here. For browsing a project, I recommend the excellent Nerdtree. This will give you a browsable tree structure, affording you a neat high-level overview of the current directory and its children. Pressing m while in this view will allow you the ability to delete, create, and rename nodes without ever leaving vim. Sublime stalwarts will enjoy ctrlp; an excellent fuzzy matcher which particularly shines when you have similarly named files, like in a Rails project for example. Finally, I frequently want to access files I have used recently; MRU does exactly this.

While those are some of my favorites, here are some other vim plugins that deserve special mention:

• Fugitive: Git integration directly in Vim
• Supertab: Code completion
• Airline: Pleasant looking status bar
• TComment: Quick comment/uncomment functionality
• Surround: Wrap the usual vim boundary selections in parenthesis or quotes
• Autoclose: Automatically close brackets or quotes
• Gundo: Interface to Vim’s well hidden tree structure storing document changes, which frequently proves much more useful than the linear ‘undo’ functionality

Ruby Specific Plugins

First up, you need to ensure your version of Vim is compiled with Ruby:

vim --version | grep ruby

The above command should include a +ruby. If it doesn’t, you need to either recompile Vim with ruby support (relatively trivial) or install a version of Vim with Ruby support, like MacVim. While a lot of the plugins will work without it, you’ll miss out on useful features like autocompletion.

vim-ruby is the first port of call. It adds syntax highlighting, IntelliSense-like autocompletion, and even compiler plugins. This should get you a lot of basic IDE functionality out of the box. It even has erb syntax highlighting!

Tim Pope is the man who has given us several excellent Ruby (and other) plugins. You could do worse than to check out his projects and integrate them into your workflow. If you’re going to get one plugin to aid your Rails development, it should be vim-rails. This plugin brings all the command line functionality directly into Vim, which is tremendously useful when you marry it up with Vim shortcuts. Let’s delve into some useful commands here:

gf – This is a context aware switch that will jump you right into a related file. You can leverage the appropriately named :A (alternate) and :R (related) to go from model to schema, template to helper, and controller to functional test.

Interface with rails on the command line with :Rails (also rake can be accessed via :Rake, if you’re pre-Rails 5.)

You can extract partials by visually selecting an area and leveraging :Rextract <filename>. This seems such a minor feature but is incredibly useful when refactoring a clumsy view.

There are a ton of other useful shortcuts and your time will be well invested in learning them.

vim-dispatch is another Tim Pope creation. This allows you to leverage Tmux to bring asynchronous functionality to Vim. Useful to kick off unit tests without blocking input or opening another pane.

vim-rspec is a lightweight RSpec runner for Vim. I enjoy the mappings if I’m not using Guard.

For further reading on this subject, check out this article which is much more in depth.

Honorable mentions:

• vim-endwise: automatically appends an end when you input def <function_name>. Think snipmate but without having to invoke the shortcut.
• vimbundler: wraps bundler, which makes interfacing with it slightly nicer.
• vim-haml: Cutting edge Vim runtime files for Haml, Sass, and SCSS — unnecessary but nice.

This isn’t really a Vim plugin but I’ll include it here anyway: gem-browse is a Ruby Gem that opens a library’s source file in your editor, which saves time when you need to wade through the source of some obscure library to see why your code isn’t executing as expected.

Docker

Docker is comparatively new technology compared with the others, but no less important. It facilitates easy and platform agnostic deployment by running a ‘container’ within a single Linux instance, avoiding the overhead of starting and maintaining traditional Virtual Machines. Additionally, the isolation afforded by this approach affords an extra layer of protection.

Docker used to be a bit difficult to get started with, necessitating the excellent How to Use Docker on OS X: The Missing Guide, but things are better now. Head over to docker.com to get started.

Guard

I am a huge fan of Guard. While in large projects with huge batteries of tests, it doesn’t shine so much, any rapidly evolving project without this constraint benefits hugely from the instant feedback it provides to developers. By keeping the Spring preloader going, it can dramatically reduce time taken for tests to run, and I would wholeheartedly recommend pairing it with minitest-reporters for more informative test output.

Pry

Pry is a fantastic addition to your gemset. A powerful alternative to irb, it allows command shell integration (git, vim, etc), syntax highlighting and powerful history viewing and replay functionality. Used in tandem with the pry-doc gem, it includes some neat features like show-doc to bring up documentation and show-source to view source of Ruby builtins. It can work well as a debugger and as someone who favors REPL driven development, I find it a breath of fresh air to use compared with the default irb.

Pgcli

With the advent of ORMs, SQL is something I interface with less regularly, which means autocomplete is a real time saver when I can’t remember exactly how to do something. Pgcli (and its cousin Mycli if you’re stuck with mysql) offer this exact functionality and with syntax highlighting to boot. Highly recommended.

Mutt

If you can suffer through what is arguably the most painful configuration process in modern software, Mutt is an excellent choice for command line email access. It uses Vim bindings and I definitely appreciate not having to leave my shell to handle email.

Irssi

I find IRC an invaluable resource, but definitely something that works better in the shell. irssi is my client of choice (be sure to check out the extensions). I also hear good things about weechat.

Summary

We’ve covered a lot of ground here and, as always, there’s a ton more below the surface. Vim is where I spend most of my time, so I’ve spent proportionally much more time customizing it. Researching Tmux and your shell properly is definitely time well-spent. Naturally, this is all personal preference so you’re unlikely to develop using my exact setup, but you should hopefully have a better idea of what is out there and perhaps even integrate something new from here into your workflow.

Suggest

☞ The Complete Ruby on Rails Developer Course

☞ Rails 5: Learning Web Development the Ruby Way

☞ Learn Ruby on Rails from Scratch

☞ Ruby Scripting for Software Testers

☞ Python, Ruby, Shell — Scripting for Beginner

The WordPress Customizer has been actively developed since its inception. The APIs are continually evolving, including the JavaScript API. However, it is one of the least documented APIs in the WordPress Codex. Hence there are only a few extensive records that show how to leverage the JavaScript API practically.

Leveraging the JavaScript API in the WordPress Customizer can actually enable us to serve a more compelling real-time experience while customizing the theme beyond casting the change from the Control to the Preview window.

You may be familiar with how the Customizer JavaScript API is being used to cast a change to the Preview window in real time. To do so, we set the Setting transport mode to postMessage and add the corresponding JavaScript code, as follows.

wp.customize( ‘blogname’, function( value ) {
value.bind( function( to ) {
$( ‘.site-title a’ ).text( to );
} );
} );

However, we can also stretch the API further to, for example, hide, show, or move a Section, Panel, a Control, change the value of a Setting based on another Setting value, and interconnect the Preview and the Control interactions. And these are what we are going to look into in this tutorial.

The Settings and Controls

To begin with, we’ll examine the “Settings” and “Controls” in the Customizer that we have added for the purpose of this tutorial. We will also look into the code that puts them in their place.

In this tutorial, we will be focusing on the website “Site Title”. And as you can see above, we have two Controls: the native WordPress “Site Title” input field and our custom checkbox to enable or disable the “Site Title”. These two Controls reside in the “Site Identity” section. And on the right side of the image is the Preview, where you can see the “Site Title” being rendered.

Furthermore, as you can see below, we also have two Controls that reside in the Colors section to change the “Site Title” color and its hover state color.

The Underlying Code

Our theme herein is based on Underscores, which has all the Customizer-related code placed in the /inc/customizer.php file.

function tuts_customize_register( $wp_customize ) {

$wp_customize->get_setting( ‘blogname’ )->transport = ‘postMessage’;

$wp_customize->get_setting( ‘blogdescription’ )->transport = ‘postMessage’;
$wp_customize->get_control( ‘blogdescription’ )->priority = ‘12’;

$wp_customize->get_setting( ‘header_textcolor’ )->default = ‘#f44336’;
$wp_customize->get_setting( ‘header_textcolor’ )->transport = ‘postMessage’;

// Checkbox to Display Blogname
$wp_customize->add_setting( ‘display_blogname’, array(
‘transport’ => ‘postMessage’,
) );

$wp_customize->add_control( ‘display_blogname’, array(
‘label’ => __( ‘Display Site Title’, ‘tuts’ ),
‘section’ => ‘title_tagline’,
‘type’ => ‘checkbox’,
‘priority’ => 11,
) );

// Add main text color setting and control.
$wp_customize->add_setting( ‘header_textcolor_hover’, array(
‘default’ => ‘#C62828’,
‘sanitize_callback’ => ‘sanitize_hex_color’,
‘transport’ => ‘postMessage’,
) );

$wp_customize->add_control( new WP_Customize_Color_Control( $wp_customize, ‘header_textcolor_hover’, array(
‘label’ => __( ‘Header Text Color: Hover’, ‘tuts’ ),
‘section’ => ‘colors’,
‘priority’ => ‘11’
) ) );
}
add_action( ‘customize_register’, ‘tuts_customize_register’ );

And as you can see above, we have made a few modifications to the code, adhering to our need in this tutorial.

• We lower the WordPress built-in Setting, blogdescription, to 12 so that the checkbox Setting, display_blogname, appears below the "Site Title" input field.
• We create a new Control named display_blogname. We set the priority to 11 which, in our case, resides between the "Site Title" and the "Tagline" input field.
• Set the header_text default color to #f44336 and the transport type to postMessage.
• We also create a new Setting, header_text_color. Similarly, we also set the priority to 11 so that it appears just below the header_textcolor Setting.

All these Settings are set with postMessage instead of with refresh. The postMessage option allows the value to be transported asynchronously and displayed in the Preview window in real time. However, we will also have to write our own JavaScript to handle the change.

Loading JavaScript

We need to create two JavaScript files: one file, customizer-preview.js, to deal with the Preview and the other file, customizer-control.js, to handle the Controls inside the Customizer panel.

js
├── customizer-preview.js // 1. File to handle the Preview
├── customizer-control.js // 2. File to handle the Controls
├── navigation.js
└── skip-link-focus-fix.js

Within customizer-preview.js is the following code.

( function( $ ) {
// Codes here.
} )( jQuery );

It is currently an empty enclosed JavaScript function. We will discuss more specifically how we preview changes in the Preview window in the next tutorial of this series.

In the other file, customizer-control.js, we add the following code:

(function( $ ) {
wp.customize.bind( ‘ready’, function() {
var customize = this;
// Codes here
} );
})( jQuery );

As you can see above, we will wrap the code in this file upon the Customizer ready event. This will ensure everything within the Customizer is fully ready, including the Settings, Panels, and Controls, before we begin executing any customized functions.

Finally, once we have added the code, we will load these two JavaScript files in two different locations.

// 1. customizer-preview.js
function tuts_customize_preview_js() {
wp_enqueue_script( ‘tuts_customizer_preview’, get_template_directory_uri() . ‘/js/customizer-preview.js’, array( ‘customize-preview’ ), null, true );
}
add_action( ‘customize_preview_init’, ‘tuts_customize_preview_js’ );

// 2. customizer-control.js
function tuts_customize_control_js() {
wp_enqueue_script( ‘tuts_customizer_control’, get_template_directory_uri() . ‘/js/customizer-control.js’, array( ‘customize-controls’, ‘jquery’ ), null, true );
}
add_action( ‘customize_controls_enqueue_scripts’, ‘tuts_customize_control_js’ );

The customizer-preview.js file will be loaded within the Customizer Preview window through the customize_preview_init Action hook. The customizer-control.js file will be loaded in the Customizer back-end, where the Setting and Control elements are accessible through the customize_controls_enqueue_scripts Action hook.

Written by Louie R.

If you found this post interesting, follow and support us.
Suggest for you:

☞Wordpress Backup & Restore

☞Wordpress Basic to Advanced Tutorials

☞How to Create a WordPress Menu Driven Site & blog

☞WordPress Marketing: Profits With Powerful WordPress Plugins

☞How To Start A Profitable Wordpress Blog Step By Step 2016

Fix markdown issue on the section for installing pipYou may have heard of Python before, especially if you have been coding for a while.

If not, Python is a high level, general purpose programming language. What this means is that you can use it to code up anything from a simple game to a website supporting millions of users per month.

In fact, several high profile sites with millions of visitors per month rely on Python for some of their services. Examples include YouTube and Dropbox

That being said, why should you use Python in the first place? Why not one of the many other popular languages out in the wild like Ruby or PHP? Well, with Python you get the following awesome benefits:

1. Easily readable syntax.
2. Awesome community around the language.
3. Easy to learn.
4. Python is useful for a myriad of tasks from basic shell sripting to advanced web development.

When Not to Use Python

While you can easily write a Desktop app with Python using tools like wxPython, you generally would do better to use the specialized tools offered by the platform you are targeting for example .NET on Windows.

You should also not use Python when your particular use case has very specialized requirements which are better met by other languages. An example is when you are building an embedded system, a domain in which languages like C, C++ and Java dominate.

Python 2 vs Python 3

Python 2.7.x and 3.x are both being used extensively in the wild. Python 3 introduced changes into the language which required applications written in Python 2 to be rewritten in order to work with the Python 3.x branch. However, most libraries you will require to use have now been ported to Python 3.

This tutorial will use Python 3 which is at version 3.5.1 at the time of writing. The principles remain the same though and only minor syntax modifications will be required to get the code running under Python 2.7.x.

Some Python Code Samples

Hello World

As I said before, one of Python’s main benefits is its’ very easily readable syntax. How easy? Check out Python’s version of the ubiquitous Hello World.

# This line of code will print "Hello, World!" to your terminal
    print("Hello, World!")

This code prints out Hello, World! to the console. You can easily try out this code by visiting this site, pasting the code samples in the editor on the right side of the page, and clicking the run button above the page to see the output.

Conditional Logic

Conditional logic is just as easy. Here is some code to check if a user’s age is above 18, and if it is, to print Access allowed or Access not allowed otherwise.

# read in age
    age = int(input("What's your age?"))

    if age >= 18:
        print("Access allowed")
    elif age < 18 and age > 0:
        print("Access not allowed")
    else:
        print("Invalid age")

The input() function is used to read in keyboard input. You will therefore need to type something in the terminal prompt after running the script for rest of the script to execute. Note that the input() function is wrapped in theint() function.

This is because input() reads in values as strings and yet we need age to be an integer. We therefore have to cast the keyboard input into a string or else we will get an error for example when checking if the string is greater than 18.

Finally, note the else statement which executes for any other input which doesn’t fit the criteria being checked for in the if statements.

Abstract Data Types

Python also has some excellent built in abstract data types for holding collections of items. An example is a list which can be used to hold variables of any type. The following code shows how to create a list and iterate through it to print each item to the terminal.

# create a list called my_list
    my_list = [1, 2, 3, "python", 67,  [4, 5]]

    # go through my_list and print every item
    for item in my_list:
        print item

The code above creates a list with numbers, a string and a list (yes, lists can contain other lists!). To iterate through lists, a for-in loop comes in handy. Remember, lists are zero-indexed so we can also access list items using indexes. For example, to output the string python, you can write:

# create a list called my_list
    my_list = [1, 2, 3, "python", 67,  [4, 5]]

    print(my_list[3])

Dictionaries

Another excellent data type Python offers out of the box is dictionaries. Dictionaries store key-value pairs, kind of like JSON objects. Creating a dictionary is quite simple as well.

# create a dictionary
    person = {
                "name": "Amos",
                "age": 23,
                "hobbies": ["Travelling", "Swimming", "Coding", "Music"]
            }

    # iterate through the dict and print the keys
    for key in person:
        print(key)

    # iterate through the dict's keys and print their values
    for key in person:
        print(person[key])

Now that you know a little bit of Python, let’s talk about Django.

Django

Django is a Python web framework. It is free and open source and has been around since 2005. It is very mature and comes with excellent documentation and awesome features included by default. Some excellent tools it provides are:

1. Excellent lightweight server for development and testing.
2. Good templating language.
3. Security features like CSRF included right out of the box.

There are a myriad of other useful things included in Django but you shall probably discover them as you go along. We are going to be using Django to build our website in this tutorial.

Setting Up

In this tutorial, I will show you how to get a Django website up and running. Before we get there though, first grab a copy of the latest Python from the Python website.

Note that if you are on OSX and you have Homebrew installed you can do

brew install python3

After that go straight to the Getting started with Django section

After installing the correct version for your OS, you will need to make sure it is set up correctly. Open a terminal and type:

python3

You should see something resembling the following:

Python 3.5.1 (v3.5.1:37a07cee5969, Dec  5 2015, 21:12:44) 
    [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>>

This is the interactive Python shell. Hit CTRL + D to exit it for now

Next, we need to install pip. Pip is a python package manager that will enable us to get libraries we require in our app easily such as Django.

sudo easy_install pip

Setting Up the Environment

To avoid polluting our global scope with unecessary packages, we are going to use a virtual environment to store our packages. One excellent virtual environment manager available for free is virtualenv. You can get it by doing a pip install.

pip install virtualenv

Once that is done, create a folder called projects anywhere you like then cd into it.

mkdir projects

cd projects

Once inside the projects folder, create another folder called hello. This folder will hold our app.

mkdir hello

At this point, we need to create the environment to hold our requirements. We will do this inside the hello folder.

virtualenv -p /usr/local/bin/python3 env

The -p switch tells virtualenv the path to the python version you want to use. Feel free to switch out the path after it with your own Python installation path. The name env is the environment name. You can also change it to something else which fits the name of your project.

Once that is done, you should have a folder called env inside your hello folder. Your structure should now look something like this.

projects
    ├─hello
    │   ├── env

You are now ready to activate the environment and start coding!

source env/bin/activate

You will see a prompt with the environment name. That means the environment is active.

(env)

Installing Django

This is a simple pip install. The latest Django version at the time of writing is Django 1.9.6

pip install django

Creating an App

Now that Django is installed, we can use its start script to create a skeleton project. This is as simple as using its admin script in the following way.

django-admin startproject helloapp

Running this command creates a skeleton django app with the following structure:

helloapp
    ├─helloapp
    │   ├── __init__.py
    │   ├── settings.py
    │   ├── urls.py
    │   └── wsgi.py
    └── manage.py

When you look into the helloapp folder that was created, you will find a file called manage.py and another folder called helloapp. This is your main project folder and contains the project’s settings in a file called settings.py and the routes in your project in the file called urls.py. Feel free to open up the settings.py file to familiarize yourself with its contents.

Ready to move on? Excellent.

Changing App Settings

Let’s change a few settings. Open up the settings.py file in your favorite editor. Find a section called Installed Apps which looks something like this.

# helloapp/settings.py
    INSTALLED_APPS = [
        'django.contrib.admin',
        'django.contrib.auth',
        'django.contrib.contenttypes',
        'django.contrib.sessions',
        'django.contrib.messages',
        'django.contrib.staticfiles',
    ]

Django operates on the concept of apps. An app is a self contained unit of code which can be executed on its own. An app can do many things such as serve a webpage on the browser or handle user authentication or anything else you can think of. Django comes with some default apps preinstalled such as the authentication and session manager apps. Any apps we will create or third-party apps we will need will be added at the bottom of the Installed Apps list after the default apps installed.

Before we create a custom app, let’s change the application timezone. Django uses the tz database timezones, a list of which can be found here.

The timezone setting looks like this.

# helloapp/settings.py
    TIME_ZONE = 'UTC'

Change it to something resembling this as appropriate for your timezone.

# helloapp/settings.py
    TIME_ZONE = 'America/Los_Angeles'

Creating your own app

It is important to note that Django apps follow the Model, View, Template paradigm. In a nutshell, the app gets data from a model, the view does something to the data and then renders a template containing the processed information. As such, Django templates correspond to views in traditional MVC and Django views can be likened to the controllers found in traditional MVC.

That being said, let’s create an app. cd into the first helloapp folder and type;

python manage.py startapp howdy

Running this command will create an app called howdy. Your file structure should now look something like this.

helloapp
    ├── helloapp
    │        ├── __init__.py
    │        ├── settings.py
    │        ├── urls.py
    │        └── wsgi.py
    ├── howdy
    │        ├── __init__.py
    │        ├── admin.py
    │        ├── apps.py
    │        ├── migrations
    │        ├── models.py
    │        ├── tests.py
    │        └── views.py
    └── manage.py

To get Django to recognize our brand new app, we need to add the app name to the Installed Apps list in oursettings.py file.

# helloapp/settings.py
    INSTALLED_APPS = [
        'django.contrib.admin',
        'django.contrib.auth',
        'django.contrib.contenttypes',
        'django.contrib.sessions',
        'django.contrib.messages',
        'django.contrib.staticfiles',
        'howdy'
    ]

Once that is done, let’s run our server and see what will be output. We mentioned that Django comes with a built in lightweight web server which, while useful during development, should never be used in production. Run the server as follows:

python manage.py runserver

Your output should resemble the following:

Performing system checks...

    System check identified no issues (0 silenced).

    You have unapplied migrations; your app may not work properly until they are applied.
    Run 'python manage.py migrate' to apply them.

    June 04, 2016 - 07:42:08
    Django version 1.9.6, using settings 'helloapp.settings'
    Starting development server at http://127.0.0.1:8000/
    Quit the server with CONTROL-C.

If you look carefully, you will see a warning that you have unapplied migrations. Ignore that for now. Go to your browser and access http://127.0.0.1:8000/. If all is running smoothly, you should see the Django welcome page.

We are going to replace this page with our own template. But first, let’s talk migrations.

Migrations

Migrations make it easy for you to change your database schema (model) without having to lose any data. Any time you create a new database model, running migrations will update your database tables to use the new schema without you having to lose any data or go through the tedious process of dropping and recreating the database yourself.

Django comes with some migrations already created for its default apps. If your server is still running, stop it by hitting CTRL + C. Apply the migrations by typing:

python manage.py migrate

If successful, you will see an output resembling this one.

Operations to perform:
      Apply all migrations: sessions, auth, contenttypes, admin
    Running migrations:
      Rendering model states... DONE
      Applying contenttypes.0001_initial... OK
      Applying auth.0001_initial... OK
      Applying admin.0001_initial... OK
      Applying admin.0002_logentry_remove_auto_add... OK
      Applying contenttypes.0002_remove_content_type_name... OK
      Applying auth.0002_alter_permission_name_max_length... OK
      Applying auth.0003_alter_user_email_max_length... OK
      Applying auth.0004_alter_user_username_opts... OK
      Applying auth.0005_alter_user_last_login_null... OK
      Applying auth.0006_require_contenttypes_0002... OK
      Applying auth.0007_alter_validators_add_error_messages... OK
      Applying sessions.0001_initial... OK

Running the server now will not show any warnings.

Urls & Templates

When we ran the server, the default Django page was shown. We need Django to access our howdy app when someone goes to the home page URL which is /. For that, we need to define a URL which will tell Django where to look for the homepage template.

Open up the urls.py file inside the inner helloapp folder. It should look like this.

# helloapp/urls.py
     """helloapp URL Configuration

    The `urlpatterns` list routes URLs to views. For more information please see:

    https://docs.djangoproject.com/en/1.9/topics/http/urls/

    Examples:
    Function views
        1\. Add an import:  from my_app import views
        2\. Add a URL to urlpatterns:  url(https://medium.com/r'^r'^$', views.home, name='home'#39;,%20views.home,%20name='home')
    Class-based views
        1\. Add an import:  from other_app.views import Home
        2\. Add a URL to urlpatterns:  url(https://medium.com/r'^r'^$', Home.as_view(#39;,%20Home.as_view(), name='home')
    Including another URLconf
        1\. Import the include() function: from django.conf.urls import url, include
        2\. Add a URL to urlpatterns:  url(https://medium.com/r'^blog/',%20include('blog.urls'))
    """
    from django.conf.urls import url
    from django.contrib import admin

    urlpatterns = [
        url(https://medium.com/r'^admin/',%20admin.site.urls),
    ]

As you can see, there is an existing URL pattern for the Django admin site which comes by default with Django. Let’s add our own url to point to our howdy app. Edit the file to look like this.

# helloapp/urls.py
    from django.conf.urls import url, include
    from django.contrib import admin

    urlpatterns = [
        url(https://medium.com/r'^admin/',%20admin.site.urls),
        url(https://medium.com/r'^',%20include('howdy.urls')),
    ]

Note that we have added an import for include from django.conf.urls and added a url pattern for an empty route. When someone accesses the homepage, (in our case http://localhost:8000), Django will look for more url definitions in the howdy app. Since there are none, running the app will produce a huge stack trace due to anImportError.

.
    .
    ImportError: No module named 'howdy.urls'

Let’s fix that. Go to the howdy app folder and create a file called urls.py. The howdy app folder should now look like this.

├── howdy
    │   ├── __init__.py
    │   ├── admin.py
    │   ├── apps.py
    │   ├── migrations
    │   │   ├── __init__.py
    │   ├── models.py
    │   ├── tests.py
    │   ├── urls.py
    │   └── views.py

Inside the new urls.py file, write this.

# howdy/urls.py
    from django.conf.urls import url
    from howdy import views

    urlpatterns = [
        url(https://medium.com/r'^r'^$', views.HomePageView.as_view(#39;,%20views.HomePageView.as_view()),
    ]

This code imports the views from our howdy app and expects a view called HomePageView to be defined. Since we don’t have one, open the views.py file in the howdy app and write this code.

# howdy/views.py
    from django.shortcuts import render
    from django.views.generic import TemplateView

    # Create your views here.
    class HomePageView(TemplateView):
        def get(self, request, **kwargs):
            return render(request, 'index.html', context=None)

This file defines a view called HomePageView. Django views take in a request and return a response. In our case, the method get expects a HTTP GET request to the url defined in our urls.py file. On a side note, we could rename our method to post to handle HTTP POST requests.

Once a HTTP GET request has been received, the method renders a template called index.html which is just a normal HTML file which could have special Django template tags written alongside normal HTML tags. If you run the server now, you will see the following error page:

This is because we do not have any templates at all! Django looks for templates in a templates folder inside your app so go ahead and create one in your howdy app folder.

mkdir templates

Go into the templates folder you just created and create a file called index.html

(env) hello/helloapp/howdy/templates
     > touch index.html

Inside the index.html file, paste this code.

<!-- howdy/templates/index.html -->
    <!DOCTYPE html>
    <html>
        <head>
            <meta charset="utf-8">
            <title>Howdy!</title>
        </head>
        <body>
            <h1>Howdy! I am Learning Django!</h1>
        </body>
    </html>

Now run your server.

python manage.py runserver

You should see your template rendered.

Linking pages

Let’s add another page. In your howdy/templates folder, add a file called about.html. Inside it, write this HTML code:

<!-- howdy/templates/about.html -->
<!DOCTYPE html>
<html>
   <head>
       <meta charset="utf-8">
       <title>Howdy!</title>
   </head>
   <body>
       <h1>Welcome to the about page</h1>
   <p>
   Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc quis neque ex. Donec feugiat egestas dictum. In eget erat sit amet elit pellentesque convallis nec vitae turpis. Vivamus et molestie nisl. Aenean non suscipit velit. Nunc eleifend convallis consectetur. Phasellus ornare dolor eu mi vestibulum, ornare tempus lacus imperdiet. Interdum et malesuada fames ac ante ipsum primis in faucibus. Pellentesque ut sem ligula. Mauris volutpat vestibulum dui in cursus. Donec aliquam orci pellentesque, interdum neque sit amet, vulputate purus. Quisque volutpat cursus nisl, in volutpat velit lacinia id. Maecenas id felis diam. 
   </p>
   <a href="/">Go back home</a>
   </body>
</html>

Once done, edit the original index.html page to look like this.

<!-- howdy/templates/index.html -->
    <!DOCTYPE html>
    <html>
        <head>
            <meta charset="utf-8">
            <title>Howdy!</title>
        </head>
        <body>
            <h1>Howdy! I am Learning Django!</h1>
         <a href="/about/">About Me</a>
        </body>
    </html>

Clicking on the About me link won’t work quite yet because our app doesn’t have a /about/ url defined. Let’s edit the urls.py file in our howdy app to add it.

# howdy/urls.py
    from django.conf.urls import url
    from howdy import views

    urlpatterns = [
        url(https://medium.com/r'^r'^$', views.HomePageView.as_view(#39;,%20views.HomePageView.as_view()),
        url(https://medium.com/r'^about/r'^about/$', views.AboutPageView.as_view(#39;,%20views.AboutPageView.as_view()), # Add this /about/ route
    ]

Once we have added the route, we need to add a view to render the about.html template when we access the/about/ url. Let’s edit the views.py file in the howdy app.

# howdy/views.py
    from django.shortcuts import render
    from django.views.generic import TemplateView

    class HomePageView(TemplateView):
        def get(self, request, **kwargs):
            return render(request, 'index.html', context=None)

    # Add this view
    class AboutPageView(TemplateView):
        template_name = "about.html"

Notice that in the second view, I did not define a get method. This is just another way of using the TemplateViewclass. If you set the template_name attribute, a get request to that view will automatically use the defined template. Try changing the HomePageView to use the format used in AboutPageView.

Running the server now and accessing the home page should display our original template with the newly added link to the about page.

Clicking on the About me link should direct you to the About page.

On the About me page, clicking on the Go back home link should redirect you back to our original index page. Try editing both these templates to add more information about you.

Conclusion

That was just a brief look at how to get a Django website up and running. You can read more about Django on theofficial Django docs. The full code for this tutorial can also be found on Github.

Suggest

☞ Learning Python for Data Analysis and Visualization

☞ Learn Python for Beginners!

☞ Data Science: Deep Learning in Python

☞ Python, Ruby, Shell — Scripting for Beginner

☞ Python For Android Hacking Crash Course: Trojan Perspective

To understand how Node.js works, first you need to understand a few key features of JavaScript that make it well suited for server-side development. JavaScript is a simple language, but it is also extremely flexible. This flexibility is the reason why it has stood the test of time. First-class functions and closures make it an ideal language for web applications.

JavaScript has a bad reputation for being unreliable. However, this notion couldn’t be further from the truth. Actually, JavaScript’s bad reputation comes from the DOM’s unreliability. The DOM (docment object model) is the API (application programming interface) that browser vendors provide to interact with the browser using JavaScript. The DOM has idiosyncrasies between browser vendors. However, JavaScript the language is well-defined and can be used reliably across browsers and Node.js. In this tutorial, we discuss a few fundamentals of JavaScript followed by how Node.js used JavaScript to provide a highly performant platform for web applications. Other people complain about how JavaScript handles programming errors (it tries to make invalid code work). However, in such cases, the developers are really to blame, as they need to be careful when working with a highly dynamic language.

[mks_progressbar name=”” level=”” value=”15″ height=”20″ color=”#ef4f37″ style=”squared”]

Variables

Variables are defined in JavaScript using the var keyword. For example, the following code segment creates a variable foo and logs it to the console. As you saw in the previous article, you would run this code from your console (terminal on Mac OS X and cmd on Windows) using node variable.js
variable.js

var foo = 123;
console.log(foo); // 123

The JavaScript runtime (the browser or Node.js) has the opportunity to define a few global variablesthat we can use in our code. One of them is the console object, which we have been using up to this point. The console object contains a member function (log), which takes any number of arguments and prints them to the console. We will discuss more global objects as they are used. As you will see, JavaScript contains most things you expect a good programming language to have.

Numbers

All numbers in JavaScript have the same floating point number type. Arithmetic operations (+,-,*,/,%) work on numbers as you would expect, as shown in

numbers.js

var foo = 3;
var bar = 5;
console.log(foo + 1);   // 4
console.log(foo / bar); // 0.6
console.log(foo * bar); // 15
console.log(foo - bar); // -2;
console.log(foo % 2);   // remainder: 1

Boolean

Two literals are defined for boolean values: true and false. You can assign these to variables and apply boolean operations to them as you would expect.

boolean.js

var foo = true;
console.log(foo); // true

// Boolean operations (&&, ||, !) work as expected:
console.log(true && true);   // true
console.log(true && false);  // false
console.log(true || false);  // true
console.log(false || false); // false
console.log(!true);          // false
console.log(!false);         // true
[mks_progressbar name="" level="" value="40" height="20" color="#ef4f37" style="squared"]

Arrays

You can create arrays quite easily in JavaScript using []. Arrays have many useful functions, a few of which are shown

arrays.js

var foo = [];

foo.push(1);         // add at the end
console.log(foo);    // prints [1]

foo.unshift(2);      // add to the top
console.log(foo);    // prints [2,1]

// Arrays are zero index based:
console.log(foo[0]); // prints 2

Object Literals

By explaining these few fundamental types, we have introduced you to object literals. The most common way of creating an object in JavaScript is using the object notation, {}. Objects can be extended arbitrarily at runtime. An example is shown in

objectLiterals1.js

var foo = {};
console.log(foo); // {}
foo.bar = 123;    // extend foo
console.log(foo); // { bar: 123 }

Instead of extending it at runtime, you can define which properties go on an object upfront by using the object literal notation shown

objectLiterals2.js

var foo = {
    bar: 123
};
console.log(foo); // { bar: 123 }

You can additionally nest object literals inside object literals, as shown in

objectLiterals3.js

var foo = {
    bar: 123,
    bas: {
        bas1: 'some string',
        bas2: 345
    }
};
console.log(foo);

And, of course, you can have arrays inside object literals as well, as shown in

objectLiterals4.js

var foo = {
    bar: 123,
    bas: [1, 2, 3]
};
console.log(foo);

And, you can also have these arrays themselves contain object literals,

objectLiterals5.js

var foo = {
    bar: 123,
    bas: [{
        qux: 1
    },
    {
        qux: 2
    },
    {
        qux: 3
    }]
};
console.log(foo.bar);        // 123
console.log(foo.bas[0].qux); // 1
console.log(foo.bas[2].qux); // 2

Object literals are extremely handy as function arguments and return values.

[mks_progressbar name=”” level=”” value=”55″ height=”20″ color=”#ef4f37″ style=”squared”]

Functions

Functions are really powerful in JavaScript. Most of the power of JavaScript comes from the way it handles the function type. We will examine functions in JavaScript in progressively more involved examples that follow.

Functions 101

A normal function structure in JavaScript is defined in

functionBody.js

function functionName() {
    // function body
    // optional return;
}

All functions return a value in JavaScript. In the absence of an explicit return statement, a function returns undefined. When you execute the code in , you get undefined on the console.

functionReturn.js

function foo() { return 123; }
console.log(foo()); // 123

function bar() { }
console.log(bar()); // undefined

We will discuss undefined functions more in this article when we look at default values.

Immediately Executing Function

You can execute a function immediatelyafter you define it. Simply wrap the function in parentheses () and invoke it, as shown in

ief1.js

(function foo() {
    console.log('foo was executed!');
})();

The reason for having an immediately executing function is to create a new variable scope. An if,else, or while does not create a new variable scope in JavaScript. This fact is demonstrated in

ief2.js

var foo = 123;
if (true) {
    var foo = 456;
}
console.log(foo); // 456;

The only recommended way of creating a new variable scope in JavaScript is using a function. So, in order to create a new variable scope, we can use an immediately executing function, as shown i

. ief3.js

var foo = 123;
if (true) {
    (function () { // create a new scope
        var foo = 456;
    })();
}
console.log(foo); // 123;

Notice that we choose to avoid needlessly naming the function. This is called an anonymous function, which we will explain next.

Anonymous Function

A function without a name is called an anonymous function. In JavaScript, you can assign a function to a variable. If you are going to use a function as a variable, you don’t need to name the function. demonstrates two ways of defining a function inline. Both of these methods are equivalent.

anon.js

var foo1 = function namedFunction() { // no use of name, just wasted characters
    console.log('foo1');
}
foo1(); // foo1

var foo2 = function () {              // no function name given i.e. anonymous function
    console.log('foo2');
}
foo2(); // foo2

A programming language is said to have first-class functions if a function can be treated the same way as any other variable in the language. JavaScript has first-class functions.

Higher-Order Functions

Since JavaScript allows us to assign functions to variables, we can pass functions to other functions. Functions that take functions as arguments are called higher-order functions. A very common example of a higher-order function is setTimeout. This is shown in

higherOrder1.js

setTimeout(function () {
    console.log('2000 milliseconds have passed since this demo started');
}, 2000);

If you run this application in Node.js, you will see the console.log message after two seconds and then the application will exit. Note that we provided an anonymous function as the first argument tosetTimeout. This makes setTimeout a higher-order function.

It is worth mentioning that there is nothing stopping us from creating a function and passing that in. An example is shown in

higherOrder2.js

function foo() {
    console.log('2000 milliseconds have passed since this demo started');
}
setTimeout(foo, 2000);

Now that we have a firm understanding of object literals and functions, we can examine the concept of closures.

Closures

Whenever we have a function defined inside another function, the inner function has access to the variables declared in the outer function. Closures are best explained with examples.

you can see that the inner function has access to a variable (variableInOuterFunction) from the outer scope. The variables in the outer function have been closed by (or bound in) the inner function. Hence the term closure. The concept in itself is simple enough and fairly intuitive.

closure1.js

function outerFunction(arg) {
    var variableInOuterFunction = arg;

    function bar() {
        console.log(variableInOuterFunction); // Access a variable from the outer scope
    }

    // Call the local function to demonstrate that it has access to arg
    bar();
}

outerFunction('hello closure!');              // logs hello closure!

Now the awesome part: The inner function can access the variables from the outer scope even after the outer function has returned. This is because the variables are still bound in the inner function and not dependent on the outer function. shows an example.

closure2.js

function outerFunction(arg) {
    var variableInOuterFunction = arg;
    return function () {
        console.log(variableInOuterFunction);
    }
}

var innerFunction = outerFunction('hello closure!');

// Note the outerFunction has returned
innerFunction(); // logs hello closure!

Now that we have an understanding of first-class functions and closures, we can look at what makes JavaScript a great language for server-side programming.

Understanding Node.js Performance

Node.js is focused on creating highly performant applications. In the following section, we introduce the I/O scaling problem. Then we show how it has been solved traditionally, followed by how Node.js solves it.

The I/O Scaling Problem

Node.js is focused on being the best way to write highly performant web applications. To understand how it achieves this, we need to know about the I/O scaling problem. Let us look at a rough estimate of the speed at which we can access data from various sources in terms of CPU cycles

Comparing common I/O sources

You can clearly see that Disk and Network access is in a completely different category from accessing data that is available in RAM and CPU cache.

Most web applications depend on reading data from disk or from another network source (for example, a database query). When an HTTP request is received and we need to load data from a database, typically this request will be spent waiting for a disk read or a network access call to complete.

These open connections and pending requests consume server resources (memory and CPU). In order to handle a large number of requests from different clients using the same web server, we have the I/O scaling problem.

Traditional Web Servers Using a Process Per Request

Traditional servers used to spin up a new process to handle every single web request. Spinning a new process for each request is an expensive operation, both in terms of CPU and memory. This is the way technologies like PHP used to work when they were first created.

In order to successfully reply to an HTTP request “A,” we need some data from a database. This read can potentially take a long time. For this entire read duration, we will have a process taking up CPU and memory while idling and waiting for the database response. Also, processes are slow to start and have a significant overhead in terms of RAM space. This does not scale for very long and that is the reason why modern web applications use a thread pool.

Traditional Web Servers Using a Thread Pool

Modern servers use a thread from a thread pool to serve each request. Since we already have a few Operating System (OS) threads created (hence a thread pool), we do not pay the penalty of starting and stopping OS processes (which are expensive to create and take up much more memory than a thread). When a request comes in, we assign a thread to process this request. This thread is reserved for the request in the entire duration that the request is being handled, as demonstrated in

Traditional web server using a thread pool

Because we save the overhead of creating a new process every time and the threads are lighter than processes, this method is much better than the original server design. Most web servers used this method a few years back and many continue to use today. However, this method is not without drawbacks. Again there is wasting of RAM between threads. Also the OS needs to context switch between threads (even when they are idle), and this results in wasted CPU resources.

The Nginx Way

We have seen that creating separate processes and separate threads to handle requests results in wasted OS resources. The way Node.js works is that there is a single thread handling requests. The idea that a single threaded server can perform better than a thread pool server is not new to Node.js. Nginx is built on this principle.

Nginx is a single-threaded web server and can handle a tremendous amount of concurrent requests. A simple benchmark comparing Nginx to Apache, both serving a single static file from the file system, is shown in

[

Nginx vs. Apache requests/second vs. concurrent open connections

As you can see, when the number of concurrent connections goes up, Nginx can handle a lot more requests per second than Apache. What is more interesting is the memory consumption, as shown [

Nginx vs. Apache memory usage vs. concurrent connections

With more concurrent connections, Apache needs to manage more threads and therefore consumes much more memory, whereas Nginx stays at a steady level.

Node.js Performance Secret

There is a single execution thread in JavaScript. This is the way web browsers have traditionally worked. If you have a long-running operation (such as waiting for a timer to complete or a database query to return), you must continue operation using a callback. provides a simple demo that uses the JavaScript runtime setTimeout function to simulate a long-running operation. You can run this code using Node.js.

simulateUserClick.js

function longRunningOperation(callback) {
    // simulate a 3 second operation
    setTimeout(callback, 3000);
}

function userClicked() {
    console.log('starting a long operation');
    longRunningOperation(function () {
        console.log('ending a long operation');
    });
}
// simulate a user action
userClicked();

This simulation is possible in JavaScript because we have first-class functions and passing functions — a callback is a well-supported pattern in the language. Things become interesting when you combine first-class functions with the concept of closures. Let us image that we are handling a web request and we have a long-running operation such as a database query that we need to do. A simulated version is shown

simulateWebRequest.js

function longRunningOperation(callback) {
    // simulate a 3 second operation
    setTimeout(callback, 3000);
}

function webRequest(request) {
    console.log('starting a long operation for request:', request.id);
    longRunningOperation(function () {
        console.log('ending a long operation for request:', request.id);
    });
}
// simulate a web request
webRequest({ id: 1 });
// simulate a second web request
webRequest({ id: 2 });

, because of closures, we have access to the correct user request after the long-running operation completes. We just handled two requests on a single thread without breaking a sweat. Now you should understand the following statement: “Node.js is highly performant, and it uses JavaScript because JavaScript supports first-class functions and closures.”

The immediate question that should come to mind when someone tells you that you only have a single thread to handle requests is, “But my computer has a quad core CPU. Using only a single thread will surely waste resources.” And the answer is that yes it will. However, there is a well-supported way around it that we will examine in when discussing deployment and scalability. Just a quick tip about what you will see there: It is actually really simple to use all the CPU cores with a separate JavaScript process for each CPU core using Node.js.

It is also important to note that there are threads managed by Node.js at the C level (such as for certain file system operations), but all the JavaScript executes in a single thread. This gives you the performance advantage of the JavaScript almost completely owning at least one thread.

More Node.js Internals

It is not terribly important to understand the internals of how Node.js works, but a bit more discussion make you more aware of the terminology when you discuss Node.js with your peers. At the heart of Node.js is an event loop.

Event loops enable any GUI application to work on any operating system. The OS calls a function within your application when something happens (for example, the user clicks a button), and then your application executes the logic contained inside this function to completion. Afterward, your application is ready to respond to new events that might have already arrived (and are there on the queue) or that might arrive later (based on user interaction).

Thread Starvation

Generally during the duration of a function called from an event in a GUI application, no other events can be processed. Consequently, if you do a long-running task within something like a click handler, the GUI will become unresponsive. This is something every computer user I have met has experienced at one point or another. This lack of availability of CPU resources is called starvation.

Node.js is built on the same event loop principle as you find in GUI programs. Therefore, it too can suffer from starvation. To understand it better, let’s go through a few code examples shows a small snippet of code that measures the time passed using console.time andconsole.timeEnd functions.

timeit.js

console.time('timer');
setTimeout(function(){
   console.timeEnd('timer');
},1000)

If you run this code, you should see a number quite close to what you would expect — in other words, 1000ms. This callback for the timeout is called from the Node.js event loop.

Now let’s write some code that takes a long time to execute, for instance, a nonoptimized method of calculating the nth Fibonacci number as shown in

largeOperation.js

console.time('timeit');
function fibonacci(n) {
    if (n < 2)
        return 1;
    elses
        return fibonacci(n - 2) + fibonacci(n - 1);
}
fibonacci(44);             // modify this number based on your system performance
console.timeEnd('timeit'); // On my system it takes about 9000ms (i.e. 9 seconds)

Now we have an event that can be raised from the Node.js event loop (setTimeout) and a function that can keep the JavaScript thread busy (fibonacci). We can now demonstrate starvation in Node.js. Let’s set up a time-out to execute. But before this time-out completes, we execute a function that takes a lot of CPU time and therefore holds up the CPU and the JavaScript thread. As this function is holding on to the JavaScript thread, the event loop cannot call anything else and therefore the time-out is delayed, as demonstrated in

starveit.js

// utility funcion
function fibonacci(n) {
    if (n < 2)
        return 1;
    else
        return fibonacci(n - 2) + fibonacci(n - 1);
}

// setup the timer
console.time('timer');
setTimeout(function () {
    console.timeEnd('timer'); // Prints much more than 1000ms
}, 1000)

// Start the long running operation
fibonacci(44);

One lesson here is that Node.js is not the best option if you have a high CPU task that you need to do on a client request in a multiclient server environment. However, if this is the case, you will be very hard-pressed to find a scalable software solution in any platform. Most high CPU tasks should take place offline and are generally offloaded to a database server using things such as materialized views, map reduce, and so on. Most web applications access the results of these computations over the network, and this is where Node.js shines — evented network I/O.

Now that you understand what an event loop means and the implications of the fact that JavaScript portion of Node.js is single-threaded, let’s take another look at why Node.js is great for I/O applications.

Data-Intensive Applications

Node.js is great for data-intensive applications. As we have seen, using a single thread means that Node.js has an extremely low-memory footprint when used as a web server and can potentially serve a lot more requests. Consider the simple scenario of a data intensive application that serves a dataset from a database to clients via HTTP. We know that gathering the data needed to respond to the client query takes a long time compared to executing code and/or reading data from RAM. shows how a traditional web server with a thread pool would look while it is responding to just two requests.

[

How a traditional server handles two requests

The same server in Node.js is shown in All the work is going to be inside a single thread, which results in lesser memory consumption and, due to the lack of thread context switching, lesser CPU load. Implementation-wise, the handleClientRequest is a simple function that calls out to the database (using a callback). When that callback returns, it completes the request using the request object it captured with a JavaScript closure. This is shown in the pseudocode

.How a Node.js server handles two requests

. handleClientRequest.js

function handleClientRequest(request) {
    makeDbCall(request.someInfo, function (result) {
        // The request corresponds to the correct db result because of closure
        request.complete(result);
    });
}

Note that the HTTP request to the database is also managed by the event loop. The advantage of having async IO and why JavaScript + Node.js is a great fit for data-intensive applications should now be clear.

The V8 JavaScript Engine

It is worth mentioning that all the JavaScript inside Node.js is executed by the V8 JavaScript engine. V8 came into being with the Google Chrome project. V8 is the part of Chrome that runs the JavaScript when you visit a web page.

Anybody who has done any web development knows how amazing Google Chrome has been for the web. The browser usage statistics reflect that quite clearly. According to w3schools.org(www.w3schools.com/browsers/browsers_stats.asp), nearly 56% of Internet users who visit their web site are now using Google Chrome. There are lots of reasons for this, but V8 and its speed is a very important factor. Besides speed, another reason for using V8 is that the Google engineers made it easy to integrate into other projects, and that it is platform independent.

More JavaScript

Now that we understand the motivation for using Node.js, let’s delve further into JavaScript so that we can write maintainable applications. In addition to the fact that you need to be good at JavaScript if you want to become a Node.js developer, another reason to be good at JavaScript is to take advantage of the thriving ecosystem around Node.js and JavaScript in general. The language with the greatest number of projects on GitHub is JavaScript. Node.js is the most popular server-side technology on GitHub, as shown and the third most popular repository overall.

[

Most popular repositories on GitHub

Everything Is a Reference

JavaScript was designed to be simple and work with limited computer resources. Whenever we assign one variable to another, JavaScript copies a reference to the variable. To understand what this means, have a look at

reference1.js

var foo = { bas: 123 };
var bar = foo;
bar.bas = 456;
console.log(foo.bas); // 456

Passing objects around in function calls is extremely lightweight no matter what the size of the object, since we only copy the reference to the object and not every single property of the object. To make true copies of data (that break the reference link), you can just create a new object literal as shown

reference2.js

var foo = { bas: 123 };
var bar = { bas: foo.bas }; // copy

bar.bas = 456;              // change copy
console.log(foo.bas);       // 123, original is unchanged

We can use quite a few third-party libraries to copy properties for arbitrary JavaScript objects. (It is a simple function we can write ourselves if we wanted.)

Default Values

The default value of any variable in JavaScript is undefined. You can see it being logged out where you create a variable but do not assign anything to it.

default1.js

var foo;
console.log(foo); // undefined

Similarly, a nonexistent property on a variable returns undefined

default2.js

var foo = { bar: 123 };
console.log(foo.bar); // 123
console.log(foo.bas); // undefined

Exact Equality

One thing to be careful about in JavaScript is the difference between == and === As JavaScript tries to be resilient against programming errors, == tries to do type coercion between two variables. For example, it converts a string to a number so that you can compare it with a number, as shown in

**.**equal1.js

console.log(5 == '5');  // true
console.log(5 === '5'); // false

However, the choices it makes are not always ideal. For example, in the first statement is false because ’’ and ‘0’ are both strings and are clearly not equal. However, in the second case, both ‘0’ and the empty string (’’) are falsy (in other words, they behave like false) and are therefore equal with respect to ==. Both statements are false when you use ===.

equal2.js

console.log('' == '0');  // false
console.log('' == 0);    // true

console.log('' === '0'); // false
console.log('' === 0);   // false

The tip here is to not compare different types to each another. Comparing different types of variables (such as a string with a number) is something you would not be able to do in a statically typed language anyway (a statically typed language is one where you must specify the type of a variable). If you keep this in mind, you can safely use ==. However, it is recommended that you always use === whenever possible.

Similar to == vs. ===, there are the inequality operators != and !==, which work in the same way. In other words, != does type coercion, whereas !== is strict.

null

null is a special JavaScript object used to denote an empty object. This is different from undefined, which is used by JavaScript for nonexistent and noninitialized values. You should not set anything toundefined because, by convention, undefined is the default value you should leave to the runtime. A good time to use null is when you want to explicitly say that something is not there, such as as a function argument. You will see its usage in the section on error handling in this tutorial.

Truthy and Falsy

One important concept in JavaScript is truthy values and falsy values. Truthy values are those that behave like true in boolean operations and falsy values are those that behave like false in boolean operations. It is generally easier to use if / else / ! for null / undefined instead of doing an explicit check. An example of the falsy nature of these values is shown in

truthyandfalsy.js

console.log(null == undefined);  // true
console.log(null === undefined); // false

// Are these all falsy?
if (!false) {
    console.log('falsy');
}
if (!null) {
    console.log('falsy');
}
if (!undefined) {
    console.log('falsy');
}

Other important falsy values are 0 and the empty string (”). All object literals and arrays are truthy in JavaScript.

Revealing Module Pattern

Functions that return objects are a great way to create similar objects. An object here means data and functionality bundled into a nice package, which is the most basic form of Object Oriented Programming (OOP) that one can do. At the heart of the revealing module pattern is JavaScript’s support for closures and ability to return arbitrary (function + data) object literals. is a simple example that shows how to create an object using this pattern.

revealingModules.js

function printableMessage() {
    var message = 'hello';
    function setMessage(newMessage) {
        if (!newMessage) throw new Error('cannot set empty message');
        message = newMessage;
    }
    function getMessage() {
        return message;
    }

    function printMessage() {
        console.log(message);
    }

    return {
        setMessage: setMessage,
        getMessage: getMessage,
        printMessage: printMessage
    };
}

// Pattern in use
var awesome1 = printableMessage();
awesome1.printMessage(); // hello

var awesome2 = printableMessage();
awesome2.setMessage('hi');
awesome2.printMessage(); // hi

// Since we get a new object everytime we call the module function
// awesome1 is unaffected by awesome2
awesome1.printMessage(); // hello

The great thing about this example is that it is a simple pattern to understand because it only utilizes closures, first-class functions, and object literals — concepts that are already familiar to you and that we covered extensively in the beginning of this tutorial.

Understanding this

The JavaScript keyword this has a very special place in the language. It is something that is passed to the function depending upon how you call it (somewhat like a function argument). The simplest way to think of it is that it refers to the calling context. The calling context is the prefix used to call a function. demonstrates its basic usage.

this1.js

var foo = {
    bar: 123,
    bas: function () {
        console.log('inside this.bar is:', this.bar);
    }
}

console.log('foo.bar is: ', foo.bar); // foo.bar is: 123
foo.bas();                            // inside this.bar is: 123

Inside the function bas, this refers to foo since bas was called on foo and is therefore the calling context. So, what is the calling context if I call a function without any prefix? The default calling context is the Node.js global variable, as shown in

this2.js

function foo() {
    console.log('is this called from globals? : ', this === global); // true
}
foo();

Note that if we were running it in the browser, the global variable would be window instead of global.

Of course, since JavaScript has great support for first-class functions, we can attach a function to any object and change the calling context, as shown in

this3.js

var foo = {
    bar: 123
};

function bas() {
    if (this === global)
        console.log('called from global');
    if (this === foo)
        console.log('called from foo');
}

// global context
bas();     // called from global

// from foo
foo.bas = bas;
foo.bas(); // called from foo

There is one last thing you need to know about this in JavaScript. If you call a function with the newJavaScript operator, it creates a new JavaScript object and this within the function refers to this newly created object. Again,provides another simple example.

this4.js

function foo() {
    this.foo = 123;
    console.log('Is this global?: ', this == global);
}

// without the new operator
foo(); // Is this global?: true
console.log(global.foo); // 123

// with the new operator
var newFoo = new foo();  // Is this global?: false
console.log(newFoo.foo); // 123

You can see that we modified this.foo inside the function and newFoo.foo was set to that value.

Understanding Prototype

It is a common misunderstanding that JavaScript isn’t object-oriented. It is indeed true that until recently JavaScript has not had the class keyword. But functions in JavaScript are more powerful than they are in many other languages and can be used to mimic traditional object oriented principles. The secret sauce is the new keyword (which you have already seen) and a property called theprototype. Every object in JavaScript has an internal link to another object called the prototype. Before we look at creating traditional classes in JavaScript, let’s have a deeper look at prototype.

When you read a property on an object (for example, foo.bar reads the property bar from foo), JavaScript checks that this property exists on foo. If not, JavaScript checks if the property exists onfoo.proto and so on till proto itself is not present. If a value is found at any level, it is returned. Otherwise, JavaScript returns undefined

prototype1.js

var foo = {};
foo.__proto__.bar= 123;
console.log(foo.bar); // 123

Although this works, the __ prefix in JavaScript is conventionally used for properties that should not be used by user code (in other words, private/internal implementation details). Therefore, you should not use proto directly. The good news is that when you create an object using the new operator on a function, the proto is set to the function’s .prototype member, whichcan be verified with a simple bit of code, as shown in

prototype2.js

// Lets create a test function and set a member on its prototype
function foo() { };
foo.prototype.bar = 123;

// Lets create a object using `new`
// foo.prototype will be copied to bas.__proto__
var bas = new foo();

// Verify the prototype has been copied
console.log(bas.__proto__ === foo.prototype); // true
console.log(bas.bar);                         // 123

The reason why this is great is because prototypes are shared between all the objects (let’s call theseinstances) created from the same function. This fact is shown

prototype3.js

// Lets create a test function and set a member on its prototype
function foo() { };
foo.prototype.bar = 123;

// Lets create two instances
var bas = new foo();
var qux = new foo();

// Show original value
console.log(bas.bar); // 123
console.log(qux.bar); // 123

// Modify prototype
foo.prototype.bar = 456;

// All instances changed
console.log(bas.bar); // 456
console.log(qux.bar); // 456

Imagine you need 1,000 instances created. All the functionality you put on prototype is shared. And therefore lesson one: saves memory.

Prototype is great for reading data off an object. However, if you set a property on the object, you break the link with the prototype because (as explained earlier) the prototype is only accessed if the property does not exist on the object. This disconnection from a prototype property caused by setting a property on an object is shown in

prototype4.js

// Lets create a test function and set a member on its prototype
function foo() { };
foo.prototype.bar = 123;

// Lets create two instances
var bas = new foo();
var qux = new foo();

// Overwrite the prototype value for bas
bas.bar = 456;
console.log(bas.bar); // 456 i.e. prototype not accessed

// Other objects remain unaffected
console.log(qux.bar); // 123

You can see that when we modified bas.bar, bas.proto.bar was no longer accessed. Hence, lesson two: .prototype is not good for properties you plan on writing to.

The question becomes what we should use for properties we need to write to. Recall from our discussion on this that this refers to the object that is created when the function is called with thenew operator. So this is a perfect candidate for read/write properties and you should use it for all properties. But functions are generally not altered after creation. So functions are great candidates to go on .prototype. This way, functionality (functions/methods) is shared between all instances, and properties belong on individual objects. Now we can understand a pattern to write a class in JavaScript, which is shown in

class.js

// Class definition
function someClass() {
    // Properties go here
    this.someProperty = 'some initial value';
}
// Member functions go here:
someClass.prototype.someMemberFunction = function () {
    /* Do something using this */
    this.someProperty = 'modified value';
}

// Creation
var instance = new someClass();

// Usage
console.log(instance.someProperty); // some initial value
instance.someMemberFunction();
console.log(instance.someProperty); // modified value

Within the member function, we can get access to the current instance using this even though the same function body is shared between all instances. The reason should be obvious from our earlier discussion on this and the calling context. It is because we call a function on some instance, in other words, instance.someMemberFunction(). That is why inside the function this will refer to theinstance used.

The main difference here vs. the revealing module pattern is that functions are shared between all the instances and don’t take up memory for each new instance. This is because functions are only on.prototype and not on this. Most classes inside core Node.js are written using this pattern.

Error Handling

Error handling is an important part of any application. Errors can happen because of your code or even in code not in your controls, for example, database failure.

JavaScript has a great exception handling mechanism that you might already be familiar with from other programming languages. To throw an exception, you simply use the throw JavaScript keyword. To catch an exception, you can use the catch keyword. For code you want to run regardless of whether an exception was caught or not, you can use the finally keyword. . is a simple example that demonstrates this.

. error1.js

try {
    console.log('About to throw an error');
    throw new Error('Error thrown');
}
catch (e) {
    console.log('I will only execute if an error is thrown');
    console.log('Error caught: ', e.message);
}
finally {
    console.log('I will execute irrespective of an error thrown');
}

The catch section executes only if an error is thrown. The finally section executes despite any errors thrown within the try section. This method of exception handling is great for synchronous JavaScript. However, it will not work under an async workflow. demonstrates this shortcoming.

error2.js

try {
    setTimeout(function () {
        console.log('About to throw an error');
        throw new Error('Error thrown');
    }, 1000);
}
catch (e) {
    console.log('I will never execute!');
}

console.log('I am outside the try block');

The reason why it does not work is because at the point in time when the callback for setTimeoutexecutes, we would already be outside the try/catch block. The setTimeout is going to call the function provided at a later point, and you can see that happen in this code sample since “I am outside the try block” is executed. The default behavior for uncaught exceptions in Node.js is to exit the process, and this is why our application crashes.

The correct way of doing this is to handle the error insidethe callback, as shown shown in

error3.js

setTimeout(function () {
    try {
        console.log('About to throw an error');
        throw new Error('Error thrown');
    }
    catch (e) {
        console.log('Error caught!');
    }
}, 1000);

This method works fine from inside an async function. But now we have an issue of finding a way to tell the code outside about the error. Let’s look at a concrete example. Consider a simplegetConnection function that takes a callbackwe need to call after a successful connection, as shown in

error4.js

function getConnection(callback) {
    var connection;
    try {
        // Lets assume that the connection failed
        throw new Error('connection failed');

        // Notify callback that connection succeeded?
    }
    catch (error) {
        // Notify callback about error?
    }
}
[mks_progressbar name="" level="" value="95" height="20" color="#ef4f37" style="squared"]

We need to notify the callback about success and failure. This is why Node.js has a convention of calling callbacks with the first argument of error if there is an error. If there is no error, we call back with the error set to null. As a result, a getConnection function designed for the Node.js ecosystem would be something like what is shown in

error5.js

function getConnection(callback) {
    var connection;
    try {
        // Lets assume that the connection failed
        throw new Error('connection failed');

        // Notify callback that connection succeeded?
        callback(null, connection);
    }
    catch (error) {
        // Notify callback about error?
        callback(error, null);
    }
}

// Usage
getConnection(function (error, connection) {
    if (error) {
        console.log('Error:', error.message);
    }
    else {
        console.log('Connection succeeded:', connection);
    }
});

Having the error as the first argument ensures consistency in error checking. This is the convention followed by all Node.js functions that have an error condition. A good example of this is the file system API, which we cover in future . Also note that developers tend to use the falsy nature of null to check for errors.

Summary

In this article we discussed important JavaScript concepts necessary to to be successful with Node.js. You should now have a deep understanding of what makes JavaScript and Node.js great for creating data-intensive applications and why it performs better than the technologies that preceded it. In the next tutorial, we will discuss more Node.js specific patterns and practices for creating maintainable applications.

Works Cited

Ryan Dahl (2009) Node.js from JSConf.

“Nginx vs. Apache,” http://blog.webfaction.com/2008/12/a-little-holiday-present-10000-reqssec-with-nginx-2/

“Browser Statistics,” http://www.w3schools.com/browsers/browsers_stats.asp

“GitHub Repository Search by Stars,” https://github.com/search?o=desc&q=stars%3A%3E1&s=stars&type=Repositories

Suggest

☞ All about NodeJS

☞ Learn Nodejs by Building 12 Projects

☞ JavaScript Tutorials: Understanding the Weird Parts

☞ Learn How To Deploy Node.Js App on Google Compute Engine

☞ Become a Modern Web Developer

Scope, or the set of rules that determine where your variables live, is one of the most basic concepts of any programming language. It’s so fundamental, in fact, that it’s easy to forget how subtle the rules can be!

Understanding exactly how the JavaScript engine “thinks” about scope will keep you from writing the common bugs that hoisting can cause, prepare you to wrap your head around closures, and get you that much closer to never writing bugs ever again.

… Well, it’ll help you understand hoisting and closures, anyway.

In this article, we’ll take a look at:

• the basics of scopes in JavaScript
• how the interpreter decides what variables belong to what scope
• how hoisting really works
• how the ES6 keywords let and const change the game

Let’s dive in.

Lexical Scope

If you’ve written even a line of JavaScript before, you’ll know that where you define your variables determines where you can use them. The fact that a variable’s visibility depends on the structure of your source code is called lexical scope.

There are three ways to create scope in JavaScript:

1. Create a function. Variables declared inside functions are visible only inside that function, including in nested functions.
2. Declare variables with let or const inside a code block. Such declarations are only visible inside the block.
3. Create a catch block. Believe it or not, this actually does create a new scope!

“use strict”;
var mr_global = “Mr Global”;

function foo () {
var mrs_local = “Mrs Local”;
console.log(“I can see “ + mr_global + “ and “ + mrs_local + “.”);
function bar () {
console.log(“I can also see “ + mr_global + “ and “ + mrs_local + “.”);
}
}
foo(); // Works as expected

try {
console.log(“But /I/ can’t see “ + mrs_local + “.”);
} catch (err) {
console.log(“You just got a “ + err + “.”);
}
{
let foo = “foo”;
const bar = “bar”;
console.log(“I can use “ + foo + bar + “ in its block…”);
}
try {
console.log(“But not outside of it.”);
} catch (err) {
console.log(“You just got another “ + err + “.”);
}
// Throws ReferenceError!
console.log(“Note that “ + err + “ doesn’t exist outside of ‘catch’!”)

The snippet above demonstrates all three scope mechanisms. You can run it in Node or Firefox, but Chrome doesn’t play nice with let, yet.

We’ll talk about each of these in exquisite detail. Let’s start with a detailed look at how JavaScript figures out what variables belong to what scope.

The Compilation Process: A Bird’s Eye View

When you run a piece of JavaScript, two things happen to make it work.

1. First, your source gets compiled.
2. Then, the compiled code gets executed.

During the compilation step, the JavaScript engine:

1. takes note of all of your variable names
2. registers them in the appropriate scope
3. reserves space for their values

It’s only during execution that the JavaScript engine actually sets the value of variable references equal to their assignment values. Until then, they’re undefined.

Step 1: Compilation

// I can use first_name anywhere in this program
var first_name = “Peleke”;

function popup (first_name) {
// I can only use last_name inside of this function
var last_name = “Sengstacke”;
alert(first_name + ‘ ‘ + last_name);
}

popup(first_name);

Let’s step through what the compiler does.

First, it reads the line var first_name = “Peleke”. Next, it determines what scope to save the variable to. Because we’re at the top level of the script, it realizes we’re in the global scope. Then, it saves the variable first_name to the global scope and initializes its value to undefined.

Second, the compiler reads the line with function popup (first_name). Because the function keyword is the first thing on the line, it creates a new scope for the function, registers the function’s definition to the global scope, and peeks inside to find variable declarations.

Sure enough, the compiler finds one. Since we have var last_name = “Sengstacke” in the first line of our function, the compiler saves the variable last_name to the scope of popup — not to the global scope — and sets its value to undefined.

Since there are no more variable declarations inside the function, the compiler steps back into the global scope. And since there are no more variable declarations there, this phase is done.

Note that we haven’t actually run anything yet. The compiler’s job at this point is just to make sure it knows everyone’s name; it doesn’t care what they do.

At this point, our program knows that:

1. There’s a variable called first_name in the global scope.
2. There’s a function called popup in the global scope.
3. There’s a variable called last_name in the scope of popup.
4. The values of both first_name and last_name are undefined.

It doesn’t care that we’ve assigned those variables values elsewhere in our code. The engine takes care of that in execution.

Step 2: Execution

During the next step, the engine reads our code again, but this time, executes it.

First, it reads the line, var first_name = “Peleke”. To do this, the engine looks up the variable called first_name. Since the compiler has already registered a variable by that name, the engine finds it, and sets its value to “Peleke”.

Next, it reads the line, function popup (first_name). Since we’re not executing the function here, the engine isn’t interested and skips on over it.

Finally, it reads the line popup(first_name). Since we are executing a function here, the engine:

1. looks up the value of popup
2. looks up the value of first_name
3. executes popup as a function, passing the value of first_name as a parameter

When it executes popup, it goes through this same process, but this time inside the function popup. It:

1. looks up the variable named last_name
2. sets last_name’s value equal to “Sengstacke”
3. looks up alert, executing it as a function with “Peleke Sengstacke” as its parameter

Turns out there’s a lot more going on under the hood than we might have thought!

Now that you understand how JavaScript reads and runs the code you write, we’re ready to tackle something a little closer to home: how hoisting works.

Hoisting Under the Microscope

Let’s start with some code.

bar();

function bar () {
if (!foo) {
alert(foo + “? This is strange…”);
}
var foo = “bar”;
}

broken(); // TypeError!
var broken = function () {
alert(“This alert won’t show up!”);
}

If you run this code, you’ll notice three things:

1. You can refer to foo before you assign to it, but its value is undefined.
2. You can call broken before you define it, but you’ll get a TypeError.
3. You can call bar before you define it, and it works as desired.

Hoisting refers to the fact that JavaScript makes all of our declared variable names availableeverywhere in their scopes — including before we assign to them.

The three cases in the snippet are the three you’ll need to be aware of in your own code, so we’ll step through each of them one by one.

Hoisting Variable Declarations

Remember, when the JavaScript compiler reads a line like var foo = “bar”, it:

1. registers the name foo to the nearest scope
2. sets the value of foo to undefined

The reason we can use foo before we assign to it is because, when the engine looks up the variable with that name, it does exist. This is why it doesn’t throw a ReferenceError.

Instead, it gets the value undefined, and tries to use that to do whatever you asked of it. Usually, that’s a bug.

Keeping that in mind, we might imagine that what JavaScript sees in our function bar is more like this:

function bar () {
var foo; // undefined
if (!foo) {
// !undefined is true, so alert
alert(foo + “? This is strange…”);
}
foo = “bar”;
}

This is the First Rule of Hoisting, if you will: Variables are available throughout their scope, but have the value undefined until your code assigns to them.

A common JavaScript idiom is to write all of your var declarations at the top of their scope, instead of where you first use them. To paraphrase Doug Crockford, this helps your code read more like it runs.

When you think about it, that makes sense. It’s pretty clear why bar behaves the way that it does when we write our code the way JavaScript reads it, isn’t it? So why not just write like that all the time?

Hoisting Function Expressions

The fact that we got a TypeError when we tried to execute broken before we defined it is just a special case of the First Rule of Hoisting.

We defined a variable, called broken, which the compiler registers in the global scope and sets equal to undefined. When we try to run it, the engine looks up the value of broken, finds that it’s undefined, and tries to execute undefined as a function.

Obviously, undefined isn’t a function — that’s why we get a TypeError!

Hoisting Function Declarations

Finally, recall that we were able to call bar before we defined it. This is due to the Second Rule of Hoisting: When the JavaScript compiler finds a function declaration, it makes both its name and definition available at the top of its scope. Rewriting our code yet again:

function bar () {
if (!foo) {
alert(foo + “? This is strange…”);
}
var foo = “bar”;
}

var broken; // undefined

bar(); // bar is already defined, executes fine

broken(); // Can’t execute undefined!

broken = function () {
alert(“This alert won’t show up!”);
}

Again, it makes much more sense when you write as JavaScript reads, don’t you think?

To review:

1. The names of both variable declarations and function expressions are available throughout their scope, but their values are undefined until assignment.
2. The names and definitions of function declarations are available throughout their scope, even beforetheir definitions.

Now let’s take a look at two new tools that work a bit differently: let and const.

let, const, & the Temporal Dead Zone

Unlike var declarations, variables declared with let and const don’t get hoisted by the compiler.

At least, not exactly.

Remember how we were able to call broken, but got a TypeError because we tried to execute undefined? If we’d defined broken with let, we’d have gotten a ReferenceError, instead:

“use strict”;
// You have to “use strict” to try this in Node
broken(); // ReferenceError!
let broken = function () {
alert(“This alert won’t show up!”);
}

When the JavaScript compiler registers variables to their scopes in its first pass, it treats letand const differently than it does var.

When it finds a var declaration, we register the name of the variable to its scope and immediately initialize its value to undefined.

With let, however, the compiler does register the variable to its scope, but does not initialize its value to undefined. Instead, it leaves the variable uninitialized, until the engine executes your assignment statement. Accessing the value of an uninitialized variable throws a ReferenceError, which explains why the snippet above throws when we run it.

The space between the beginning of top of the scope of a let declaration and the assignment statement is called the Temporal Dead Zone. The name comes from the fact that, even though the engineknows about a variable called foo at the top of the scope of bar, the variable is “dead”, because it doesn’t have a value.

… Also because it’ll kill your program if you try to use it early.

The const keyword works the same way as let, with two key differences:

1. You must assign a value when you declare with const.
2. You cannot reassign values to a variable declared with const.

This guarantees that const will always have the value that you initially assigned to it.

// This is legal
const React = require(‘react’);

// This is totally not legal
const crypto;
crypto = require(‘crypto’);

Block Scope

let and const are different from var in one other way: the size of their scopes.

When you declare a variable with var, it’s visible as high up on the scope chain as possible — typically, at the top of the nearest function declaration, or in the global scope, if you declare it in the top level.

When you declare a variable with let or const, however, it’s visible as locally as possible — only within the nearest block.

A block is a section of code set off by curly braces, as you see with if/else blocks, for loops, and in explicitly “blocked” chunks of code, like in this snippet.

“use strict”;

{
let foo = “foo”;
if (foo) {
const bar = “bar”;
var foobar = foo + bar;

console.log(“I can see “ + bar + “ in this bloc.”);
}

try {
console.log(“I can see “ + foo + “ in this block, but not “ + bar + “.”);
} catch (err) {
console.log(“You got a “ + err + “.”);
}
}

try {
console.log( foo + bar ); // Throws because of ‘foo’, but both are undefined
} catch (err) {
console.log( “You just got a “ + err + “.”);
}

console.log( foobar ); // Works fine

If you declare a variable with const or let inside a block, it’s only visible inside the block, and only after you’ve assigned it.

A variable declared with var, however, is visible as far away as possible — in this case, in the global scope.

If you’re interested in the nitty-gritty details of let and const, check out what Dr Rauschmayer has to say about them in Exploring ES6: Variables and Scoping, and take a look at the MDN documentation on them.

Lexical this & Arrow Functions

On the surface, this doesn’t seem to have a whole lot to do with scope. And, in fact, JavaScript does notresolve the meaning of this according to the rules of scope we’ve talked about here.

At least, not usually. JavaScript, notoriously, does not resolve the meaning of the this keyword based on where you used it:

var foo = {
name: ‘Foo’,
languages: [‘Spanish’, ‘French’, ‘Italian’],
speak : function speak () {
this.languages.forEach(function(language) {
console.log(this.name + “ speaks “ + language + “.”);
})
}
};

foo.speak();

Most of us would expect this to mean foo inside the forEach loop, because that’s what it meant right outside it. In other words, we’d expect JavaScript to resolve the meaning of this lexically.

But it doesn’t.

Instead, it creates a new this inside every function you define, and decides what it means based on howyou call the function — not where you defined it.

That first point is similar to the case of redefining any variable in a child scope:

function foo () {
var bar = “bar”;
function baz () {
// Reusing variable names like this is called “shadowing”
var bar = “BAR”;
console.log(bar); // BAR
}
baz();
}

foo(); // BAR

Replace bar with this, and the whole thing should clear up instantly!

Traditionally, getting this to work as we expect plain old lexically-scoped variables to work requires one of two workarounds:

var foo = {
name: ‘Foo’,
languages: [‘Spanish’, ‘French’, ‘Italian’],
speak_self : function speak_s () {
var self = this;
self.languages.forEach(function(language) {
console.log(self.name + “ speaks “ + language + “.”);
})
},
speak_bound : function speak_b () {
this.languages.forEach(function(language) {
console.log(this.name + “ speaks “ + language + “.”);
}.bind(foo)); // More commonly:.bind(this);
}
};

In speak_self, we save the meaning of this to the variable self, and use that variable to get the reference we want. In speak_bound, we use bind to permanently point this to a given object.

ES2015 brings us a new alternative: arrow functions.

Unlike “normal” functions, arrow functions do not shadow their parent scope’s this value by setting their own. Rather, they resolve its meaning lexically.

In other words, if you use this in an arrow function, JavaScript looks up its value as it would any other variable.

First, it checks the local scope for a this value. Since arrow functions don’t set one, it won’t find one. Next, it checks the parent scope for a this value. If it finds one, it’ll use that, instead.

This lets us rewrite the code above like this:

var foo = {
name: ‘Foo’,
languages: [‘Spanish’, ‘French’, ‘Italian’],
speak : function speak () {
this.languages.forEach((language) => {
console.log(this.name + “ speaks “ + language + “.”);
})
}
};

If you want more details on arrow functions, take a look at Envato Tuts+ Instructor Dan Wellman’s excellent course on JavaScript ES6 Fundamentals, as well as the MDN documentation on arrow functions.

Conclusion

We’ve covered a lot of ground so far! In this article, you’ve learned that:

• Variables are registered to their scopes during compilation, and associated with their assignment values during execution.
• Referring to variables declared with let or const before assignment throws a ReferenceError, and that such variables are scoped to the nearest block.
• Arrow functions allow us to achieve lexical binding of this, and bypass traditional dynamic binding.

You’ve also seen the two rules of hoisting:

• The First Rule of Hoisting: That function expressions and var declarations are available throughout the scopes where they’re defined, but have the value undefined until your assignment statements execute.
• The Second Rule of Hoisting: That the names of function declarations and their bodies are available throughout the scopes where they’re defined.
  Written by Peleke Sengstacke

Did you find this article helpful? Don’t forget to drop your feedback in the comments section below. Suggest for you:

☞JavaScript the Basics — JavaScript for Beginners

☞JavaScript for Absolute Beginners

☞JavaScript: JavaScript Awesomeness

☞JavaScript For Beginners — Learn JavaScript From Scratch

☞Javascript Intermediate level 1 — Mastering the DOM

Front end development is a crucial part of web app development. We tend to keep our point of any particular website emphasizing design and structure. That is what makes front end more significant in web development. Java script is pretty much good in front end development when dynamic web pages take place. So, here is one more adaptable way for that has arrived! React.js comes into picture to help with the easier front-end development.

So, let’s get started and figure out what it is.

What is React.JS?

React.JS is an Open-source JavaScript library maintained by world’s top most community such as Facebook, Instagram and community of individual developers. Its aims to develop reusable UI components and can be represented as view ‘V’ in MVC model in web development. It focuses on efficiency and flexibility to create user interfaces. Now, design can be uncomplicated as React.JS allows creating simple view for each state and rendering when needed.

React Component:

React.JS is independent in nature as it becomes easy to maintain and reuse the component. Encapsulated components manage their own states and glued all of them to build Interactive UIs. The strongest point of React.JS is that it does not perform only on client side, but it can be rendered on server side too. Basically React Component is what you can say a class, a function which performs custom operation. Work of React.JS is not only about templates in UI, but it has sound mechanism to pass the data through application.

Virtual DOM and React.js:

One of the profound concept of React.js is Virtual DOM. Virtual DOM is refer to abstract version of DOM. It reduce the overhead of DOM manipulation by re-rendering (changing) what should be changed rather than reflecting directly in DOM. As it helped a lot to least DOM tree and renders accordingly when changed.

React Elements and Instances:

According to a community, a React Element is “An element is a plain object describing component instance or DOM node and its desired properties.” React Element is just representation of what you want to show on the screen. It is not an actual instance. It contains the information of component and its properties inside it. Each component instance has to maintain reference to its DOM nodes. React elements are lighter and no need to parse!

Main Aspect:

One noticeable characteristic of React.JS is its data flow. React.JS has one way data model data flow model unlike other framework having two-way data flow such as Angular js. The flow has been defined from parent to child. And, it really helps to make data flow smoother and easier. Developing a website efficiently with this one way data binding is agreeable way one can think.

Conclusion:
React.JS development facilitates front end development with the inclusion of exciting features. Hence, more flexible and efficient aspect has appeared in web application development. So, figure out what React.JS and its features will help you through development to meet your expectations! Good Luck!

Source: brainvire

For information you can read :

React.js Quickly: Developing Scalable Web User Interfaces