DEV Community: Martin Himmel

Transferable Skills When Changing Careers

Martin Himmel — Sun, 05 Sep 2021 16:29:36 +0000

One of the hard things about changing careers is the thought of starting over with no experience. That's not necessarily true, though. In 2015, I changed careers. Prior to that, I was a dental technician for 15 years (I made dentures, metal frameworks, and did some crown and bridge work). While preparing for that change, I did the expected thing and spent a lot of time honing my technical/programming skills. But I also spent a lot of time thinking about how that shift was going to work for my family and what that looked like for myself.

Some questions that came to mind were:

Since I'm starting over, what will that look like financially?
Will we have to move?
Am I just throwing away the last 15 years?

I got lucky in landing a 100% remote job with a starting pay of exactly what my ending dental tech. pay was. So, financially, it ended up being a lateral move, but with all the benefits of being remote and not having up uproot my family.

That last question, though, really got me thinking. What do I with this 15 year history I have? From a technical skills standpoint, it's all useless. But I realized not everything was being thrown away.

Let me give a brief explanation of the process in the dental lab. A dentist would send us a script with the instructions along with the impressions of the patient's mouth. We would go through the whole process of creating a denture (or partial, crown, etc.) based on those instructions. While working on the denture, it would typically go between the lab and the dentist's office 2 or 3 times (or more, if something was really problematic) before it was finished. If a problem or question came up, we would call up the dentist to clarify it. Occasionally, a dentist would request a chair side visit with the patient so we could see what was going on and discuss how to proceed.

Let's look at that same process with a twist. A client (dentist) would send us product requirements. As we were creating the product (dentures), there was constant communication with the client and changes to the product as needed to meet the requirements. Sometimes a phone call would suffice, sometimes a visual inspection was easier.

It's an oversimplification of the process, but hopefully it gets the idea across.

Framing my career like that made me realize that a lot of the non-technical skills do transfer. Not only that, but for 8 of those 15 years, I was a lab manager. The people skills, ability to juggle multiple projects, and team building skills learned during those years all directly transferred.

While starting a new career can be daunting, take a look at how previous experience can be applied. The technical aspects may not directly transfer, but there are plenty of other skills that can and do transfer.

Remote Advocacy

Martin Himmel — Thu, 23 May 2019 11:47:18 +0000

Anyone who knows me, knows I'm a strong proponent of remote work. For almost any "office job," there's no need to be physically present in an office. With the ubiquity of the internet and the tools we have today, people have the ability to work from anywhere. Note that I say "ability," not "option."

Now, that's not to say offices are necessarily bad. Some people prefer to work in an office. Nothing wrong with that. The problem is the requirement of being in an office.

Employment Pool

A non-remote company is limited to people in the local region (including long commuters) or those willing to move.

Imagine a company in a small town of 10,000 people. The odds of finding someone with the exact skill set needed is pretty small. Now, imagine that same company being open to remote employees. All of a sudden, the potential pool goes from about 7500 people (global adult population has averaged 73-75% for the last decade) to approximately 5.7 billion people.

Let's take it a step further. Those numbers consider all adults as potential workers. That doesn't work - not everyone does the same job. So, let's say 1% of the population does what's needed for a particular position. The non-remote company has a potential 7 people to choose from. The remote company has a potential 57 million people to choose from. If you factor in different skill levels (perhaps the company needs someone with 10 years of experience), the numbers drop even further.

I use a small town as an example, but it's by no means limited to that. I saw this when I lived in Albuquerque, which has a metro area population of just over 900,000 people. That's a significant number of adults (and jobs). It faced the same problem. After switching careers, the two companies I worked at were out of state. I eventually moved to Michigan, which is where the second company (where I currently work) is located.

Commuter Waste

Commuting is terrible on so many levels - waste of time, environmental impact, sheer cost (gas, vehicle wear and tear), etc. In my first career as a dental tech, I figured out I wasted about 4400 hours (just over 6 full months) of my life to commuting. Running those numbers was a bit jarring. That's over 2 full time work years. More importantly, it's time taken away from family, friends, events, developing new skills, hobbies, personal heatlh, etc.

Money Isn't Everything

Everyone wants more money, that's a given. Given the choice though, most people will choose personal freedom over money (granted, sometimes it takes money to achieve personal freedom, especially when debt is involved). This is purely anecdotal, but from what I've read and conversations I've had, there's a significant portion of the population that values non-monetary benefits over monetary rewards - flexible hours (9 to 5 is a terrible schedule - ask any night owl or anyone with kids in school), working remotely, more vacation time, etc.

I've turned down several job offers and potential interviews just because they weren't remote, including one that would have been a 50% increase in income but required moving and being in the office. That's a hard pass for me. Don't get me wrong, a 50% raise would be incredible (especially for achieving my other goals), but not at the cost of family, community, mental health, time, and freedom. Had it been remote, I would have seriously considered it.

Shift In Thinking

Remote work does require a bit of a shift in thinking. It eschews a lot of the traditional work place thoughts and practices, many of which are born out of the "we've always done it this way" mentality anyway (which is counter to innovation and progress). A few key points - less meetings (most are a waste of time anyway - lack of direction, people who don't need to be there, etc.), more written communication, and prefer results over hours put in.

Check out the Remote Only Manifesto for a practical look at that shift (and more ideas/tips).

Remote Work Tips

First off, remote work has nothing to do with a glamorous life. In fact, most of your productive work is going to happen during quiet times. Or maybe even in public places (coffee shops, co-working spaces, etc.) where you're free to tune everything out. If you do it right, you'll be more productive than with the constant interruption of an office (where you can't fully tune things out, just in case), as long as you're not constantly interrupted on whatever communication channels your company uses. Even then, if your company is doing it right, those shouldn't require immediate response anyway. The only real emergencies involve someone being physically hurt and needing to go to the hospital, and I've only seen that once in all my years of working. Anything else is urgent at best.

Get into a routine. Treat each day as if you're going to an office. It'll help you mentally prepare for the day. My routine is to get up and ready for the day (shower, brush my teeth, etc.), read for a few minutes, head to the coffee shop and work from there for 3 or 4 hours, head home and finish working from there. There is some variation to that as needed (trips to the store, kids' school events, etc.), but it always starts the same.

Don't forget to socialize! We are social creatures by nature. "Random" channels are great for teams, as are one-on-one DMs. Share those funny stories, memes, etc. Just don't expect an immediate response! Find your in-person community, too. For me, that's at my favorite coffee shop. I've developed good friendships with the baristas and other regulars there.

Moving a Sprite Sheet Character with JavaScript

Martin Himmel — Mon, 25 Feb 2019 01:49:41 +0000

The long overdue follow up is finally here! 😅

In part 1, we covered how to animate a sprite sheet character on a timer using requestAnimationFrame. Now, instead of looping through a timed animation cycle, we'll change it to animate and move based on user input.

Setup

We'll be using the code from part 1 as a baseline. To make this a little easier, let's alter some of the old code to give us a better starting point.

let img = new Image();
img.src = 'https://opengameart.org/sites/default/files/Green-Cap-Character-16x18.png';
img.onload = function() {
  window.requestAnimationFrame(gameLoop);
};

let canvas = document.querySelector('canvas');
let ctx = canvas.getContext('2d');

const SCALE = 2;
const WIDTH = 16;
const HEIGHT = 18;
const SCALED_WIDTH = SCALE * WIDTH;
const SCALED_HEIGHT = SCALE * HEIGHT;

function drawFrame(frameX, frameY, canvasX, canvasY) {
  ctx.drawImage(img,
                frameX * WIDTH, frameY * HEIGHT, WIDTH, HEIGHT,
                canvasX, canvasY, SCALED_WIDTH, SCALED_HEIGHT);
}

const CYCLE_LOOP = [0, 1, 0, 2];
let currentLoopIndex = 0;
let frameCount = 0;
let currentDirection = 0;

function gameLoop() {

  window.requestAnimationFrame(gameLoop);
}

The init function has been renamed to gameLoop.
The step function has been removed.
To keep the loop going, window.requestAnimationFrame(gameLoop); is called at the end of gameLoop.
In keeping with const conventions, all consts have been made fully upper case.

Getting User Input

Let's set up handling user input. We'll need a pair of event listeners to track when keys are pressed and released. We'll also need something to track those states. We could track specific buttons and only respond to those, or we can store all key presses in an object and later check what we need. Personally, I tend to use the latter.

let keyPresses = {};

window.addEventListener('keydown', keyDownListener, false);
function keyDownListener(event) {
  keyPresses[event.key] = true;
}

window.addEventListener('keyup', keyUpListener, false);
function keyUpListener(event) {
  keyPresses[event.key] = false;
}

function gameLoop() {
  // ...
}

Moving the Character

Now that we're capturing user input, let's add the character back in and handle movement.

To start with, we'll only use the first frame of the down facing character. We also need to track the x and y positions of the character. We should also add a MOVEMENT_SPEED constant so we can easily change it later. This translates to the number of pixels moved per animation frame.

const MOVEMENT_SPEED = 1;
let positionX = 0;
let positionY = 0;

function gameLoop() {
  ctx.clearRect(0, 0, canvas.width, canvas.height);

  if (keyPresses.w) {
    positionY -= MOVEMENT_SPEED;
  } else if (keyPresses.s) {
    positionY += MOVEMENT_SPEED;
  }
  if (keyPresses.a) {
    positionX -= MOVEMENT_SPEED;
  } else if (keyPresses.d) {
    positionX += MOVEMENT_SPEED;
  }

  drawFrame(0, 0, positionX, positionY);
  window.requestAnimationFrame(gameLoop);
}

We have a moving character!

Note: The arrow keys were originally used, but due to the page scrolling when pressing up and down, the WASD keys were used instead. Any key combination will work though.

Changing Directions

Currently, the character always faces down. Let's handle facing different directions. As in part 1, we'll use the currentDirection variable to store which direction the character is facing. To make it a little more intuitive, let's add a constant for each direction.

const FACING_DOWN = 0;
const FACING_UP = 1;
const FACING_LEFT = 2;
const FACING_RIGHT = 3;
let currentDirection = FACING_DOWN;

Now that that's set up, let's update the movement handling conditions and the drawFrame call to handle the set direction.

// Inside gameLoop
if (keyPresses.w) {
  positionY -= MOVEMENT_SPEED;
  currentDirection = FACING_UP;
} else if (keyPresses.s) {
  positionY += MOVEMENT_SPEED;
  currentDirection = FACING_DOWN;
}

if (keyPresses.a) {
  positionX -= MOVEMENT_SPEED;
  currentDirection = FACING_LEFT;
} else if (keyPresses.d) {
  positionX += MOVEMENT_SPEED;
  currentDirection = FACING_RIGHT;
}

drawFrame(0, currentDirection, positionX, positionY);

And now we multiple directions. Let's add the different frames now. We'll still stick with the 0, 1, 0, 2 frame pattern for our walk animation. For that, we can bring back the reference to CYCLE_LOOP[currentLoopIndex] in our drawFrame call.

drawFrame(CYCLE_LOOP[currentLoopIndex], currentDirection, positionX, positionY);

Then we can bring back the frame incrementor and limit. This looks a little different from part 1. We still need to handle movement, so instead of an early return, we'll increment the frame count, then every few frames reset the count and update the index. However, we only want the frame to increment if there's any movement.

const FRAME_LIMIT = 12;

function gameLoop() {
  ctx.clearRect(0, 0, canvas.width, canvas.height);

  let hasMoved = false;

  if (keyPresses.w) {
    positionY -= MOVEMENT_SPEED;
    currentDirection = FACING_UP;
    hasMoved = true;
  } else if (keyPresses.s) {
    positionY += MOVEMENT_SPEED;
    currentDirection = FACING_DOWN;
    hasMoved = true;
  }

  if (keyPresses.a) {
    positionX -= MOVEMENT_SPEED;
    currentDirection = FACING_LEFT;
    hasMoved = true;
  } else if (keyPresses.d) {
    positionX += MOVEMENT_SPEED;
    currentDirection = FACING_RIGHT;
    hasMoved = true;
  }

  if (hasMoved) {
    frameCount++;
    if (frameCount >= FRAME_LIMIT) {
      frameCount = 0;
      currentLoopIndex++;
      if (currentLoopIndex >= CYCLE_LOOP.length) {
        currentLoopIndex = 0;
      }
    }
  }

  drawFrame(CYCLE_LOOP[currentLoopIndex], currentDirection, positionX, positionY);
  window.requestAnimationFrame(gameLoop);
}

There we have it! The character moves around the canvas, changes directions, and cycles through all the animation frames.

A Little Cleanup

Before we continue, let's do a bit of refactoring to this:

const SCALE = 2;
const WIDTH = 16;
const HEIGHT = 18;
const SCALED_WIDTH = SCALE * WIDTH;
const SCALED_HEIGHT = SCALE * HEIGHT;
const CYCLE_LOOP = [0, 1, 0, 2];
const FACING_DOWN = 0;
const FACING_UP = 1;
const FACING_LEFT = 2;
const FACING_RIGHT = 3;
const FRAME_LIMIT = 12;
const MOVEMENT_SPEED = 1;

let canvas = document.querySelector('canvas');
let ctx = canvas.getContext('2d');
let keyPresses = {};
let currentDirection = FACING_DOWN;
let currentLoopIndex = 0;
let frameCount = 0;
let positionX = 0;
let positionY = 0;
let img = new Image();

window.addEventListener('keydown', keyDownListener);
function keyDownListener(event) {
    keyPresses[event.key] = true;
}

window.addEventListener('keyup', keyUpListener);
function keyUpListener(event) {
    keyPresses[event.key] = false;
}

function loadImage() {
  img.src = 'https://opengameart.org/sites/default/files/Green-Cap-Character-16x18.png';
  img.onload = function() {
    window.requestAnimationFrame(gameLoop);
  };
}

function drawFrame(frameX, frameY, canvasX, canvasY) {
  ctx.drawImage(img,
                frameX * WIDTH, frameY * HEIGHT, WIDTH, HEIGHT,
                canvasX, canvasY, SCALED_WIDTH, SCALED_HEIGHT);
}

loadImage();

function gameLoop() {
  ctx.clearRect(0, 0, canvas.width, canvas.height);

  let hasMoved = false;

  if (keyPresses.w) {
    moveCharacter(0, -MOVEMENT_SPEED, FACING_UP);
    hasMoved = true;
  } else if (keyPresses.s) {
    moveCharacter(0, MOVEMENT_SPEED, FACING_DOWN);
    hasMoved = true;
  }

  if (keyPresses.a) {
    moveCharacter(-MOVEMENT_SPEED, 0, FACING_LEFT);
    hasMoved = true;
  } else if (keyPresses.d) {
    moveCharacter(MOVEMENT_SPEED, 0, FACING_RIGHT);
    hasMoved = true;
  }

  if (hasMoved) {
    frameCount++;
    if (frameCount >= FRAME_LIMIT) {
      frameCount = 0;
      currentLoopIndex++;
      if (currentLoopIndex >= CYCLE_LOOP.length) {
        currentLoopIndex = 0;
      }
    }
  }

  drawFrame(CYCLE_LOOP[currentLoopIndex], currentDirection, positionX, positionY);
  window.requestAnimationFrame(gameLoop);
}

function moveCharacter(deltaX, deltaY, direction) {
  positionX += deltaX;
  positionY += deltaY;
  currentDirection = direction;
}

This looks a lot cleaner. The constants and variables are all in one place near the top (we could even move these to a set of objects instead of global scope, but for the sake of this tutorial, we'll keep it simple). The key press event listeners are the first in the set of functions. The image loader, which kicks off the whole game loop, is in its own function. And the movement handling has been moved to its own function.

Keeping In Bounds

Pulling the movement handling out to its own function actually has an additional purpose. Right now, the character can leave the canvas boundary. With the moveCharacter function, we can check for border collision in one place instead of four.

Our collision detection looks something like this:

Does the character's left edge touch or pass the left edge of the canvas?
Does the character's right edge touch or pass the right edge of the canvas?
Does the character's top edge touch or pass the top edge of the canvas?
Does the character's bottom edge touch or pass the bottom edge of the canvas?

If any of those are true, we need to stop the character from moving in the given direction. Since we're handling two directions at once, we can split the horizontal and vertical movement checks and restrictions. That way, if the character is at the middle of one edge, they can slide along that edge until they hit the corner.

Let's update our movement function to handle those conditions.

function moveCharacter(deltaX, deltaY, direction) {
  if (positionX + deltaX > 0 && positionX + SCALED_WIDTH + deltaX < canvas.width) {
    positionX += deltaX;
  }
  if (positionY + deltaY > 0 && positionY + SCALED_HEIGHT + deltaY < canvas.height) {
    positionY += deltaY;
  }
  currentDirection = direction;
}

One important thing to remember is that positionX and positionY refer to the top left corner of the character. Because of that, positionX + SCALED_WIDTH gives us the right edge of the character, and positionX + SCALED_HEIGHT gives us the bottom edge of the character.

With that in mind, this is how the checks translate to match the questions above:

positionX + deltaX > 0 checks for left edge collision.
positionX + SCALED_WIDTH + deltaX < canvas.width checks for right edge collision.
positionY + deltaY > 0 checks for top edge collision.
positionY + SCALED_HEIGHT + deltaY < canvas.height checks for bottom edge collision.

One Last Quirk

Now that our character stays within bounds, there's one more little quirk to handle. If the user stops pressing a key when the character is on the second or fourth frame of the animation cycle, it looks a little odd. The character stands still in mid stride. How about we reset the frame when the character doesn't move?

In the gameLoop function, right before the call to drawFrame, let's add a check:

if (!hasMoved) {
    currentLoopIndex = 0;
}

Great! Now the character will always be in a natural standing position when not moving.

Final Result

Here's the final bit of code:

const SCALE = 2;
const WIDTH = 16;
const HEIGHT = 18;
const SCALED_WIDTH = SCALE * WIDTH;
const SCALED_HEIGHT = SCALE * HEIGHT;
const CYCLE_LOOP = [0, 1, 0, 2];
const FACING_DOWN = 0;
const FACING_UP = 1;
const FACING_LEFT = 2;
const FACING_RIGHT = 3;
const FRAME_LIMIT = 12;
const MOVEMENT_SPEED = 1;

let canvas = document.querySelector('canvas');
let ctx = canvas.getContext('2d');
let keyPresses = {};
let currentDirection = FACING_DOWN;
let currentLoopIndex = 0;
let frameCount = 0;
let positionX = 0;
let positionY = 0;
let img = new Image();

window.addEventListener('keydown', keyDownListener);
function keyDownListener(event) {
    keyPresses[event.key] = true;
}

window.addEventListener('keyup', keyUpListener);
function keyUpListener(event) {
    keyPresses[event.key] = false;
}

function loadImage() {
  img.src = 'https://opengameart.org/sites/default/files/Green-Cap-Character-16x18.png';
  img.onload = function() {
    window.requestAnimationFrame(gameLoop);
  };
}

function drawFrame(frameX, frameY, canvasX, canvasY) {
  ctx.drawImage(img,
                frameX * WIDTH, frameY * HEIGHT, WIDTH, HEIGHT,
                canvasX, canvasY, SCALED_WIDTH, SCALED_HEIGHT);
}

loadImage();

function gameLoop() {
  ctx.clearRect(0, 0, canvas.width, canvas.height);

  let hasMoved = false;

  if (keyPresses.w) {
    moveCharacter(0, -MOVEMENT_SPEED, FACING_UP);
    hasMoved = true;
  } else if (keyPresses.s) {
    moveCharacter(0, MOVEMENT_SPEED, FACING_DOWN);
    hasMoved = true;
  }

  if (keyPresses.a) {
    moveCharacter(-MOVEMENT_SPEED, 0, FACING_LEFT);
    hasMoved = true;
  } else if (keyPresses.d) {
    moveCharacter(MOVEMENT_SPEED, 0, FACING_RIGHT);
    hasMoved = true;
  }

  if (hasMoved) {
    frameCount++;
    if (frameCount >= FRAME_LIMIT) {
      frameCount = 0;
      currentLoopIndex++;
      if (currentLoopIndex >= CYCLE_LOOP.length) {
        currentLoopIndex = 0;
      }
    }
  }

  if (!hasMoved) {
    currentLoopIndex = 0;
  }

  drawFrame(CYCLE_LOOP[currentLoopIndex], currentDirection, positionX, positionY);
  window.requestAnimationFrame(gameLoop);
}

function moveCharacter(deltaX, deltaY, direction) {
  if (positionX + deltaX > 0 && positionX + SCALED_WIDTH + deltaX < canvas.width) {
    positionX += deltaX;
  }
  if (positionY + deltaY > 0 && positionY + SCALED_HEIGHT + deltaY < canvas.height) {
    positionY += deltaY;
  }
  currentDirection = direction;
}

And this is the result:

Quick Tip to Stop Flexbox from Overflowing

Martin Himmel — Fri, 25 Jan 2019 00:48:33 +0000

I ran into an issue (yet again 😅) where my flex items weren't shrinking below a certain point in one browser but not another (e.g. it worked in Chrome but not Firefox). Turns out, it's a one-line fix: add min-width: 0; to the item.

.flex-container {
    display: flex;
}

.flex-item {
    flex: 1 1 0;
    min-width: 0;
}

Introspective Questions For Personal Development

Martin Himmel — Fri, 11 Jan 2019 16:16:06 +0000

As devs, we're constantly working on external projects. By the nature of our work, we're always learning, though it may often be accidental or out of necessity. Learning for a job may be a necessity, but it may not always be what we want to learn for our personal growth/development - the internal project of our selves. Working on the internal project of our selves will almost always lead to benefits for our external projects.

With that in mind, here are a few questions I've regularly come back to over the years.

What do I want to learn?

This isn't necessarily code related. It could be a language, a skill, something for a hobby, etc.

Why do I want to learn that?

A lot of people get tripped up on this. You don't actually need a "great" or world changing reason. Sometimes, it's just because you want to try something new. It's hard to say if you'll have a long term interest in something before actually doing it.

What's stopping me from learning that?

Identifying the blocks can help remove them.

Who can I learn from?

It's great to be able to bounce questions and ideas off of someone, if you can. If not, learn from whatever source you can - books, websites, podcasts, videos, etc. Whether you can find someone to learn from or not, online communities (like this one!) are a great additional resource.

Is there someone I can teach?

Teaching something, no matter how experienced you are in a given subject, is a great way to solidify what you learn.

Why am I doing what I'm currently doing?

If you really dive into this one, it can be challenging and scary, but eye opening.

That last question led me to a career change. I was a dental tech for 15 years before transitioning to full time development. For me, the answer to the question was that I was good at it, it was safe, and it was easy. And that wasn't good enough for me. I wanted a challenge and needed to learn something new. Where I was in the dental industry, there wasn't much else to learn (the process for making dentures hasn't changed much since the mid 1970s).

Really diving in to code (more than only as a hobby) put me on the path I am now, which has led to some great opportunities. The ability to work remotely. Meeting people I wouldn't have otherwise, especially with being able to work remotely - coffee shops are my jam. Teaching opportunities, which is something I love doing. The list could go on.

Hopefully some of those questions spark some ideas for your own development. If you have a habit of doing this, what are some of the questions your regularly ask?

JavaScript (ES5) - this

Martin Himmel — Tue, 27 Nov 2018 21:52:16 +0000

This was originally posted on my site at https://martyhimmel.me on January 16, 2017. Like a number of others on dev.to, I've decided to move my technical blog posts to this site.

The this keyword can be a bit tricky to understand in JavaScript. Before we get too deeply into it, I should mention strict mode, as the behavior of this is a little different depending on if it's used in strict mode or not.

At its core, strict mode is there to enforce better coding practices in JavaScript. There are a few things it changes about the way JavaScript code is interpreted by the browser. As the scope of strict mode could easily be it's own tutorial or article (and it has been on many sites!), I'm not going to go over all the details of it here. Instead, I'd encourage you to read Mozilla's developer docs regarding strict mode, especially before continuing this tutorial.

`this` in the Global Scope

this is a reference to an object. What object depends on the context of where this is called.

In the global scope, both in strict and non-strict modes, this is a reference to the window object. Anytime there's a reference to the global scope, it's actually talking about the window object. Consider this example:

var foo = 42;
console.log(foo); // 42
console.log(window.foo); // 42
console.log(this.foo); // 42

Any variable or function you define in the global scope actually attaches it to the window object. So, when you're working in the global scope, this then refers to window. If you want to see another example of this, open the console and type console.log(window);, then console.log(this); - you'll see the same output. And if you create any variables or functions and then run either of those statements, you'll see those variables/functions in the logged object.

`this` in an Object

This is the same for both strict and non-strict mode. As seen in the above section, the global scope is actually a top level object - the window object. That being said, any time this is called inside an object, it works exactly the same by referencing the object it's called on.

var person = {
  firstName: 'John',
  lastName: 'Smith',
  fullName: function() {
    return this.firstName + ' ' + this.lastName;
  }
};
console.log(person.fullName()); // John Smith

In the fullName function, this is a reference to the container object - person. this.firstName could be written as person.firstName. Why use this then? Imagine you have another variable with the same name (person) somewhere else in your script. What does person.firstName refer to then? Depending on the structure of the code, it may reference the wrong person object. That's where this becomes essential - it only references the object it's being called on.

`this` in Functions

In the above section, you already saw this inside of a function, but that function was wrapped in the person object. But what happens when you have a global function and use this? This is where strict mode actually matters. Let's look at the code first:

var fullName = 'Jane Doe';
function getName() {
    return this.fullName;
}

Let's cover non-strict mode first. In non-strict mode, this is a reference to the closest object in context. In the previous section, person was the closest object in the context of the function.

If you remember that the global scope is actually the window object, then this in a global function becomes easier to understand. In the fullName example, the function is in the global scope, which means it's part of the window object. In turn, the closest object to the function is the window object, so this refers to the window. And since fullName is the same as window.fullName (because it's in the global scope), this.fullName inside the global function references the global variable.

Now let's look at strict mode. In strict mode, this is a reference to whatever object it was bound to in the execution context. What this means is there's a significant difference between fullName and window.fullName. In the former, the execution context is the function, while in the latter, the execution context is window.

Due to strict mode looking at the execution context rather than object context, when calling getName(), the function throws an Uncaught TypeError. The reason being this is undefined in the execution context. You can see this if you add a console.log(this); statement inside the function.

On the other hand, if you call window.getName(), the function is bound to the window object at execution time. In that case, the function works properly and if you log this inside the function, it logs the window object.

Let's look further into how this works in functions.

With a constructor type of function, this works just like it does in objects. We'll use this function as our basis:

function Person(firstName, lastName) {
  this.firstName = firstName;
  this.lastName = lastName;
  this.getName = function() {
    return this.firstName + ' ' + this.lastName;
  };
}

Anytime you create a new object with the Person function, this is bound to that instance of the object. It works the same way in both strict and non-strict mode.

var person = new Person('John', 'Smith');
console.log(person.firstName); // John
console.log(person.lastName); // Smith
console.log(person.getName()); // John Smith

var anotherPerson = new Person('Jane', 'Doe');
console.log(anotherPerson.firstName); // Jane
console.log(anotherPerson.lastName); // Doe
console.log(anotherPerson.getName()); // Jane Doe

Since this is bound to the individual instance, person has its own this reference, while anotherPerson has its own reference.

`this` in Argument Functions

Things get a bit tricky when you pass a function as an argument to another function, such as in an event listener. Consider a button click listener:

// Using an anonymous function
document.getElementById('myButton').addEventListener('click', function() {
  console.log(this); // logs the button element (HTML)
});

// Using a declared function
document.getElementById('myButton').addEventListener('click', myClickListener);
function myClickListener() {
  console.log(this); // logs the button element (HTML)
}

It doesn't matter if you create an anonymous function inline or pass a declared function, nor does it matter if you use strict or non-strict mode, the results are the same. In the above button click listener example, this references the object that called the function - in this case, the button.

That doesn't seem too bad, right? Let's complicate it a bit. What happens if you're passing a function that already has its own this reference. For example, instead of logging this to the console when a button is pressed, we want to log the full name of person (from the previous example).

document.getElementById('myButton').addEventListener('click', function() {
  console.log(person.getName()); // John Smith
});

In that anonymous function version, it works the way we expect it to. That makes sense since we're calling the function on the object, not passing it as an argument. Let's use the method as an argument instead.

document.getElementById('myButton').addEventListener('click', person.getName);
// undefined undefined

In this case, even though getName is a method of the person object, we're not calling the function directly on the object, but passing it as an argument. Instead of this referencing the person object, it references the button element. The button has no firstName or lastName property attached to it, so it returns undefined.

There's a way around that, though. JavaScript has a built in bind function to handle it. In it's simplest form, the bind function binds this to whatever object you pass in.

document.getElementById('myButton').addEventListener('click', person.getName.bind(person));
// John Smith

What that says is to bind this to the person object when calling person.getName within the context of the button's event listener.

`this` in Closures

Closures have a unique behavior when it comes to this. Normally, an inner function has access to the outer function's variables. That's not the case with this. Each function has its own version of this. Consider this code:

var person = {
  scores: [1, 2, 3, 4],
  getScores: function() {
    console.log(this);
    this.scores.forEach(function(score) {
      console.log(this);
      // do something
    });
  }
};
person.getScores();

In the getScores method, this has predictable behavior - it references the person object (in both strict and non-strict modes). Things change once we step into the inner function inside the forEach loop.

The inner function doesn't have access to the object itself - only the wrapping/outer function's variables and anything in the global scope (the window object). Because of this behavior, you can think about the function as a stand-alone function (from the "this in Functions" section). In non-strict mode, this refers to the window object. In strict mode, this is undefined.

So how do we get around that? Create a variable in the outer function that's set to this so that variable is available to the inner function.

var person = {
  scores: [1, 2, 3, 4],
  getScores: function() {
    console.log(this);
    var that = this;
    this.scores.forEach(function(score) {
      console.log(that);
      // do something
    });
  }
};

Now, the that variable is assigned to the value of this in the outer function - in other words, the person object. Using that anywhere in the inner function gives us the same behavior as this in the outer function.

Using var that = this; or var self = this; is a common practice to handle this situation. While these are both common, it might be easier to understand if you use a more succinct variable name. In this example, var personObject = this; makes it clear what you're referring to.

JavaScript (ES5) Objects

Martin Himmel — Tue, 27 Nov 2018 18:44:53 +0000

This was originally posted on my site at https://martyhimmel.me on January 31, 2017. Like a number of others on dev.to, I've decided to move my technical blog posts to this site.

While discussing data types, we compared an object to a dictionary - a set of terms (properties or keys) and their definitions (values). Another way to think of an object is as a container for something. Here's an example:

var person = {
  firstName: 'John',
  lastName: 'Smith',
  age: 24,
  isMarried: true,
  children: ['Jack', 'Judy'],
  pet: {
    type: 'dog',
    name: 'Fido'
  }
};

In this example, the person object contains several different data types, including another object. Accessing each of those properties is done with dot notation.

console.log(person.firstName); // John
console.log(person.age); // 24
console.log(person.children[0]); // Jack
console.log(person.pet.name); // Fido

Objects can also contain functions. Here's an example, continuing with the person object:

var person = {
  firstName: 'John',
  lastName: 'Smith',
  ... // The other properties
  getFullName: function() {
    return person.firstName + ' ' + person.lastName;
  }
};
console.log(person.getFullName()); // John Smith

Just like the other properties of an object, you declare the property name and give it a value. In this case, the value is a function.

`this`

The getFullName function could be written in a slightly different way, using the this keyword.

var person = {
  ...
  getFullName: function() {
    return this.firstName + ' ' + this.lastName;
  }
}
console.log(person.getFullName()); // John Smith

The result is the same. this is a reference to the current object. I'll save the details of how this works for a separate tutorial, as it can be a bit confusing until you understand all the rules for it. For this tutorial, we'll keep it simple though, and this will always refer to the current/containing object.

Creating Objects with Constructor Functions

Up to this point, we've been manually creating every object. That's fine, but it makes for a lot of repetitious code. If we wanted 10 person objects, we'd have to create 10 separate objects.

var person1 = {
  firstName: 'John',
  lastName: 'Smith'
};
var person2 = {
  firstName: 'Jane',
  lastName: 'Doe'
};
// and so on

There's a principle in programming called "DRY" - Don't Repeat Yourself. If you can avoid duplicating code (sometimes, you can't or don't necessarily want to), it makes the code easier to maintain. So, how do we use that principle here?

You'll notice each of our person objects have the same properties - firstName and lastName. They could have all the properties from the first example, if we wanted, but we'll keep it simple here. In any case, the same code is repeated in creating every object.

This is where constructor functions come in handy. A constructor function is a function that produces objects. A common naming convention is to capitalize the first letter of a constructor function. This sets it apart from other functions. Otherwise, a constructor function is created in exactly the same way as any other function. Now, let's convert the above example.

function Person(firstName, lastName) {
  this.firstName = firstName;
  this.lastName = lastName;
}
var person1 = new Person('John', 'Smith');
var person2 = new Person('Jane', 'Doe');
// and so on
console.log(person1.firstName + ' ' + person1.lastName); // John Smith
console.log(person2.firstName + ' ' + person2.lastName); // Jane Doe

Using the Person constructor gets rid of the repititious code of assigning the first and last name to each object. Imagine if each person had 10 or 15 properties. That would be a lot of repeated code. Now imagine you had 500 people, then found a bug or needed to change some property or method of the object. You'd have to make 500 changes. Using a constructor function, you only have to change it in one place. This is why the DRY principle is important.

The Person constructor takes two arguments - firstName and lastName. The use of this inside the function is used to assign the values passed to the given property name. In other words, the firstName argument passed to the constructor is assigned to the firstName (this.firstName) property of the created object.

Calling new is what creates the actual object. If we look at the person1 object that was created, it looks like this:

console.log(person1); // {firstName: 'John', lastName: 'Doe'}

Object Prototypes

In this section, we'll continue using the above Person constructor as our base. It would be convenient to have a getFullName method - like in the first section. That's where prototypes come in.

JavaScript is a prototype based language. You can read about it in depth in Mozilla's developer docs.

Every object in JavaScript has a prototype. Logging an object to the console gives more info than just the object itself. So, a real view of console.log(person1); would give us this (using Chrome):

Person
  firstName: "John"
  lastName: "Smith"
  __proto__: Object
    constructor: Person(firstName, lastName)
      // a handful of other properties
      prototype: Object
        // more properties
    __proto__: Object
      // a bunch of properties inherited from the prototype chain

As you can see, there's a whole lot more going on than just the two properties we created in the constructor. That's all part of the prototype structure of JavaScript objects. The prototype allows objects to inherit properties from other objects. This also means we can retrofit objects with new methods by tapping into the prototype property of the constructor.

The format for adding methods via the prototype chain is:

[constructor name].prototype.[method name] = function() {
    // do something
};

Let's add the getFullName method.

Person.prototype.getFullName = function() {
  return this.firstName + ' ' + this.lastName;
};
console.log(person1.getFullName()); // John Smith

Now that the Person constructor has a getFullName method, that method is available to every instance - person1, person2, and any other objects that may have been created with the constructor. And because of the way prototypes work, even if a Person object was created before the prototype method was added to the constructor (as is the case in this example - write the constructor, create two objects, add the prototype method), that method is still available to all objects created with the given constructor.

JavaScript (ES5) Functions - Part 2

Martin Himmel — Tue, 27 Nov 2018 17:24:14 +0000

This was originally posted on my site at https://martyhimmel.me on January 10, 2017. Like a number of others on dev.to, I've decided to move my technical blog posts to this site.

Last time, we looked at the basics of functions and how to create them. In this tutorial, we'll focus more on using functions and look at recursion, closures, and functions as "first-class citizens" or "higher order functions" (both terms reference the same idea).

Recursion

A recursive function is a function that calls itself repeatedly until some condition is met. You can think of it like a self-looping function.

For the first example, we're going to use a factorial. If you're not familiar with factorials, it's a mathematical term that takes a number and muliplies every number (starting with 1) up to the given number. For example, factorial 5 (written as 5!) is the result of 1 * 2 * 3 * 4 * 5, so 5! = 120. Using that as our base, here's a function that handles it with a standard for loop.

function factorial(num) {
  if (num < 0) {
    return -1;
  }
  if (num === 0) {
    return 1;
  }
  var total = 1;
  for (var i = 1; i <= num; i++) {
    total *= i;
  }
  return total;
}
factorial(5); // 120

Now let's convert this to a recursive function.

function factorial(num) {
  if (num < 0) {
    return -1;
  }
  if (num === 0) {
    return 1;
  }
  return factorial(num - 1) * num;
}
factorial(5); // 120

As you can see, this simplifies the code. Recursive functions have their limits in JavaScript though. Every time you call a function, it gets added to the stack, which takes up memory. The bigger the stack, the more memory being used. If the stack gets too big, the app (or the browser) can hang and/or crash.

Let's look at the Fibonacci sequence as an example. If you're not familiar with it, the Fibonacci sequence is a series of numbers that adds the previous two values. Starting with one, the first few numbers are 1, 1, 2, 3, 5, 8, 13, 21, and so on. 1 + 1 = 2, 1 + 2 = 3, 2 + 3 = 5, and on it goes. The mathematical formula for that is Fn = Fn-1 + Fn-2 - the nature of this formula lends itself really well to a recursive function.

function fibonacci(num) {
  if (num < 2) {
    return num;
  }
  return fibonacci(num - 1) + fibonacci(num - 2);
}
fibonacci(8); // 21 - the eighth number in the series

Here's the tricky part - depending on your system, this can hang the browser at a relatively low number. On my laptop, there's a momentary pause at fibonacci(30) while it calculates, about a 2 second wait at fibonacci(40), and it hangs at around fibonacci(55). The reason is the way this recursive function is set up, it makes 2 more function calls for every one value, which calls the function two more times to calculate those values, and so on. Here's a graphical representation of that.

As you can see, it quickly (and exponentially) builds up the stack. As shown in the diagram, with just a base number of 5, there are 15 function calls. At base number 10, there are 177 function calls. You can see how this gets out of control really fast.

The way to get around that is through memoization - a process of storing known or previously calculated values and passing that information. This results in far fewer function calls, which means the stack isn't anywhere near as large, and the performance is greatly improved. Here's a memoized version of the fibonacci function.

function fibonacciMemoized(num, values) {
  // First call to this function, values will be undefined since the "values" argument isn't passed
  if (typeof values === 'undefined') {
    values = {};
  }

  if (num < 2) {
    return num;
  }

  // Calculate values if needed and stores them in the "values" object
  if (!values.hasOwnProperty(num - 1)) {
    values[num - 1] = fibonacciMemoized(num - 1, values);
  }
  if (!values.hasOwnProperty(num - 2)) {
    values[num - 2] = fibonacciMemoized(num - 2, values);
  }

  return values[num - 1] + values[num - 2];
}
fibonacciMemoized(8); // 21

In this case, any time a value is calculated, it gets stored in the values object, which is passed with each call. In the non-memoized version, the function calls are being made even if the same value was calculated in another branch. In the memoized version, once a value is calculated, it never has to be calculated again. The values object is checked for the number's value and, if it exists, it uses it instead of calling the function again. The branching looks more like this now:

In the non-memoized version, there was an exponential increase in the number of function calls as the base number grew larger. In the memoized version, as the base number grows larger, the number of function calls is only one more than the base number, resulting in a significantly smaller stack and an exponential increase in performance compared to the previous version. On my laptop, calling fibonacciMemoized(1000) returns instantaneous results, whereas the non-memoized version completely crashed around 55.

Closures

The simplest definition of a closure is a function within a function, but that definition doesn't capture the power of closures. In a closure, the inner function has access to the outer function's variables and parameters. Here's an example.

function displayWelcomeMessage(firstName, lastName) {
  function fullName() {
    return firstName + ' ' + lastName;
  }
  return 'Welcome back, ' + fullName() + '!';
}
console.log(displayWelcomeMessage('John', 'Smith')); // Welcome back, John Smith!

The inner function takes the parameters from the outer function and concatenates them, then passes it back to the outer function. The outer function then creates a welcome message with the results of the inner function, then returns the full welcome message.

One of the benefits of closures is that it creates a private scope. In the above example, if you try to call fullName() anywhere outside of the displayWelcomeMessage function, you'll be met with an Uncaught ReferenceError: fullName is not defined error. fullName() is only available inside displayWelcomeMessage.

Closures and Immediately-Invoked Function Expressions

One of the common ways of using closures is with an Immediately-Invoked Function Expression (IIFE). An IIFE is a function that runs as soon as it's created. Here's a comparison of a standard function and an IIFE.

// Standard function
function foo() {
  // do something
}
foo(); // Need to call the function to use it

// Immediately Invoked Function Expression
(function() {
    // do something right now
})(); // anonymous IIFE - the code inside is executed immediately (no need to call it later)

Often times, you will find entire scripts wrapped in an IIFE. Doing so prevents the global scope from being polluted with variables and functions. It essentially creates a privately scoped module. This is actually the basis for several design patterns in JavaScript as well, such as the module and revealing module patterns.

Higher Order Functions

JavaScript functions are referred to as "higher order" or "first class" functions (they're the same thing). What this means is that functions can be used in a similar way as objects - you can pass a function as an argument, return a function from another function, etc. Event listeners are dependent on accepting functions as arguments.

function buttonClickListener() {
  console.log('You clicked a button!');
}
document.getElementById('myButton').addEventListener('click', buttonClickListener);

This example attaches a click event to the button with an id attribute of "myButton" by passing the name of the function (buttonClickListener) as an argument. You may have noticed this is a bit different than calling the function. When you call a function, you include the parentheses (e.g. myFunction()). When you pass a function as an argument, you don't include the parentheses. If you do, it will execute the function immediately rather than pass it as an argument.

You can also use anonymous functions as arguments. This example has the same functionality of the previous, but is done with an anonymous function instead.

document.getElementById('myButton').addEventListener('click', function() {
  console.log('You clicked a button!');
});

JavaScript (ES5) Functions - Part 1

Martin Himmel — Tue, 27 Nov 2018 17:19:58 +0000

This was originally posted on my site at https://martyhimmel.me on January 2, 2017. Like a number of others on dev.to, I've decided to move my technical blog posts to this site.

A function is a contained block of code that performs a task. Generally, functions are created to be reusable pieces of code. Reusability means you don't have to write the same code over and over in every place you need it, which means you're writing less code and the program as a whole is much easier to maintain. With functions, you can create the function once and call it as many times as you need.

If you've been following this series, you've already seen a few examples of functions. console.log() - console is actually a global object in JavaScript, and .log() is a function (or a "method") of that object.

A quick side note about "function" versus "method." A method is a function inside of an object. That's it. If a function isn't attached to an object (e.g. in the global space), it's a function. If a function is attached to an object, it's a method.

Back to some functions/methods you've already seen. .pop(), .push(), .shift(), .unshift() are all array methods. All of the DOM selectors (e.g., .getElementById()) are methods of the document object.

Creating Functions

There are two ways to create functions in JavaScript - as a function expression and as a function declaration.

Function Expression

A function expression is similar to creating a variable. Use the var keyword, followed by the name of the variable, then set it equal to function() {};. Doing it this way creates an "anonymous" function. Optionally, you can give the function a name (this is different from the variable name) by adding a name between the function keyword and the parentheses (e.g. function myFunction() {}).

The code to be executed goes inside the curly braces. And because a "function expression" is set to a variable, it must be terminated with a semicolon. Here are examples both anonymous and named functions:

// anonymous function
var myFunction = function() {
  // do something
};

// named function
// var myReferenceVariable = function myFunction() {
  // do something
}

The named function expression can be useful for debugging. If a function is anonymous and an error occurs, the console will only say "anonymous function" as part of the stack trace. If a function is named and an error occurs, the name will be displayed in the stack trace.

Function Declaration

A function declaration starts with the function keyword, followed by the name of the function, then the opening and closing sets of parentheses and curly braces. Function declarations don't need a terminating semicolon - they're similar to loops and conditionals in that way. Here's an example:

function myOtherFunction() {
  // do something
}

What's the Difference?

There's one significant difference between the two ways of creating functions, and that's when you can call (use) the function. With a function expression, the function has to be created before the function is used in the file. With a function declaration, the function can be called anytime, before or after the function is created.

In this example, both functions are created before they're called and everything works as expected.

var myFunction = function() {
  console.log('inside myFunction');
};
myFunction(); // inside myFunction

function myOtherFunction() {
  console.log('inside myOtherFunction');
}
myOtherFunction(); // inside myOtherFunction

Now, let's look at what happens in each if you call the function before it's created.

myFunction(); // Uncaught TypeError: myFunction is not a function
var myFunction = function() {
  console.log('inside myFunction');
};

myOtherFunction(); // inside myOtherFunction
function myOtherFunction() {
  console.log('inside myOtherFunction');
}

In the expression example, calling myFunction() before it is created breaks the script. On the other hand, in the "declaration" example, myOtherFunction() works perfectly fine. The reason behind this is because of the way JavaScript handles variables and functions, but I'll save the details of that for another tutorial.

In the meantime, which one should you use? It's mostly a matter of preference. There are certain cases where you'll need an expression rather than a declaration, but most of the time, you're free to use either one. Just keep in mind an expression can't be called before it's created.

Function Parameters and Arguments

Let's get the terminology out of the way. With functions, a parameter is a local variable that acts as a placeholder for expected data. Parameters are used when creating functions. On the other hand, when callling a function, you're passing arguments to the function. An argument is the actual data being passed. Really, this is similar to the function/method naming. They're the same thing, but developers use the different names to distinguish when they're being used - parameters in the function definition and arguments when passing data to the function.

When a function is created, you can set a list of parameters - the data expected to be passed in to the function when it's called. A function can have as many parameters as you want, though, for readability and maintainability's sake, you should keep the list as small as possible.

Consider this example:

function add(num1, num2) {
  return num1 + num2;
}
var value = add(4, 9);
console.log(value); // 13

num1 and num2 are the parameters. Whatever num1 and num2 are, they will be added together, then the value will be returned.

The return statement in a function is the result of evaluating the function. In this case, the function evaluates to the total of two numbers. Not every function will have a return statement. Imagine you're displaying a string on a page as an HTML paragraph. The function may display the string and that's it - it does an action without needing to return anything.

Back to our example. In the var value = add(4, 9); line, 4 and 9 are the arguments (the actual data) being passed to the function. The function evaluates the code and assigns the returned value to the variable value. Afterwards, the value gets logged to the console.

Wrapping Up

Functions are incredibly powerful constructs in programming. Using the last example, we can see the reusability of functions.

console.log(add(13, 12)); // 25
console.log(add(100, 34)); // 134
console.log(add(0, 1)); // 1
console.log(add(5, 72)); // 77

Without the function, you'd have to manually add the numbers each time. For a simple addition problem, that's no big deal, and is less code to just add the numbers. But let's say you have type checking in place.

function add(num1, num2) {
  var result = parseInt(num1) + parseInt(num2);
  if (isNaN(result)) {
    return false;
  }
  return value;
}
console.log(add(3, 4)); // 7
console.log(add(5, '8')); // 13
console.log(add(12, 'a')); // false

Now our add function is more useful. First, it converts the passed arguments to numbers, then adds them. If either of the arguments can't be converted, then parseInt() returns NaN (not a number). Adding NaN to anything results in NaN, so our function returns false. Otherwise, it returns the value. Having to type all that every time you want to add two numbers is highly prone to errors, not to mention unnecessarily repetitive.

Hopefully this gives you a good grasp of using, creating, and the power of functions. In the next tutorial, we'll dive deeper into functions and really tap into their power and usefulness.

JavaScript (ES5) Arrays

Martin Himmel — Tue, 27 Nov 2018 16:51:37 +0000

This was originally posted on my site at https://martyhimmel.me on December 28, 2016. Like a number of others on dev.to, I've decided to move my technical blog posts to this site.

A Quick Recap

First, a quick recap on arrays. Here’s an example array: var animals = ['cat', 'dog', 'hawk', 'wolf', 'elephant'];

And this is how we access those elements:

animals[0] - cat
animals[1] - dog
animals[2] - hawk
animals[3] - wolf
animals[4] - elephant
animals[animals.length - 1] - elephant

There are a few noteworthy things about the way arrays are indexed and accessed in the above example.

Arrays are zero indexed. The animals array indexing looks like [0, 1, 2, 3, 4].
Getting an element from an array is done by calling the array name followed by square brackets with the index number inside the brackets.
arrayName[0] will always get the first element of an array
Calling .length (an array method) on an array will give the total number of elements in an array. This is not zero based, but an actual count. animals.length is 5.
Because of the difference in the length of an array and the zero based indexing, the last element of an array will always be arrayName.length - 1.
To get the last element of an array, arrayName[arrayName.length - 1] can be used.

Now that the basics are out of the way, let's look dive deeper into using, looping over (iterating), and manipulating arrays.

Iteration

Arrays become a lot more useful after you understand loops - they tend to go hand in hand when coding. Consider this example:

var names = ['John', 'Jane', 'Judy', 'Joe', 'Jack', 'Jessie', 'Julie'];
for (var i = 0; i < names.length; i++) {
  console.log(names[i]);
}
// John
// Jane
// Judy
// Joe
// Jack
// Jessie
// Julie

If you really wanted to, you could manually type out each of those (e.g. console.log(names[0]), console.log(names[1]), etc.), but, aside from being tedious work, imagine if you had 100 elements in the array. What about 1000? You get the idea. Not only that, doing it manually requires you to know the number of elements in the array. Most of the time, in real world applications, you won’t know how big the array is, and it may change over time.

Let’s take it one step further and throw conditionals into the mix.

var randomData = ['John', 1234, 'Jane', true];
for (var i = 0; i < randomData.length; i++) {
  if (typeof randomData[i] === 'string') {
    console.log(randomData[i]);
  }
}
// John
// Jane

Granted, this is a contrived example, but hopefully you can see how powerful arrays can be, especially when used with loops and conditionals.

Array Methods

Let’s look at a few built in array methods. Each of these methods will modify the array they’re called on and return a value.

`array.pop()`

pop removes the last element of an array and returns its value.

var numbers = [1, 2, 3, 5, 8, 13];
var lastNumber = numbers.pop();
console.log(lastNumber); // 13
console.log(numbers); // [1, 2, 3, 5, 8]

`array.push(element)`

push adds an element to the end of an array and returns the new length.

var numbers = [1, 2, 3, 5, 8, 13];
var newLength = numbers.push(21);
console.log(newLength); // 7
console.log(numbers); // [1, 2, 3, 5, 8, 13, 21]

`array.shift()`

shift removes the first element of an array and returns its value.

var numbers = [1, 2, 4, 8, 16];
var firstElement = numbers.shift();
console.log(firstElement); // 1
console.log(numbers); // [2, 4, 8, 16]

`array.unshift(element)`

unshift adds an element to the beginning of an array and returns the new length.

var numbers = [1, 2, 4, 8, 16];
var firstElement = numbers.unshift(0.5);
console.log(firstElement); // 6
console.log(numbers); // [0.5, 1, 2, 4, 8, 16]

Closing Thoughts

Those four array methods are some of the more commonly used built in array methods. Two more, map and reduce are also commonly used with functions. I’ll cover those in a future tutorial on functions. In the meantime, you can check out more array methods at Mozilla’s developer docs for arrays.

JavaScript (ES5) Conditionals

Martin Himmel — Tue, 27 Nov 2018 16:44:25 +0000

This was originally posted on my site at https://martyhimmel.me on December 27, 2016. Like a number of others on dev.to, I've decided to move my technical blog posts to this site.

Conditionals allow user interactions/choices and are used to control the flow of a program. Think of all the choices you make in a day and the results of those choices. That is basically how conditionals work in programs - when you do one action, the program flows one way; if you choose a different action, the program flows another way.

Here's a example of conditionals in life. When the alarm goes off, you can hit snooze or get up. That choice is a branching point - if you hit snooze, then you sleep more but don't have time for breakfast. If you get up, you have time to get ready and have breakfast. As you can see, that's a really simple example. A morning routine has many more choices between the alarm going off and eating breakfast. And each choice along the way could be considered a conditional - the choice and the result of that choice.

`if` Statements

An if statement is the most basic type of conditional. It reacts to a condition - if a condition is true, then whatever is inside the statement is run. If the condition is false, the statement is skipped. Here's the structure:

if (condition) {
  // do something
}

Here are some common uses of if statements:

Checking if a value is a certain type
Comparing a numerical value against an expected value
Matching a string variable against an explicitly expected string

var myString = 'This is a string';
if (typeof myString === 'string') {
  console.log(myString);
}
if (typeof myString === 'number') {
  console.log('Number: ' + myString);
}
// This is a string

var myNumber = 42;
if (myNumber > 0) {
  console.log('Greater than 0');
}
if (myNumber > 100) {
  console.log('Greater than 100');
}
if (myNumber === 42) {
  console.log('The answer to everything');
}
// Greater than 0
// The answer to everything

var color = 'blue';
if (color === 'blue') {
  console.log('The sky is blue');
}
if (color === 'green') {
  console.log('The grass is green');
}
// The sky is blue

As you can see in those examples, for the conditions that are true, the statement is executed, while the statements with false conditions are skipped.

`if, else` Statements

if, else statements can be thought of as a branching point. If the if condition is true, then the code in that block is executed and the else block is skipped. If the if condition is false, then that block is skipped and the else block is executed. Here's the structure:

if (condition) {
  // do something
} else {
  // default action
}

The else block acts as a default - the code executes any time the if condition is false. Here are a couple examples.

var choice = 'left';
if (choice === 'left') {
  console.log('You have chosen the left path.');
} else {
  console.log('You have chosen the right path.');
}
// You have chosen the left path.

var choice = 'right';
if (choice === 'left') {
  console.log('You have chosen the left path.');
} else {
  console.log('You have chosen the right path.');
}
// You have chosen the right path.

`if, else if, else` Statements

if, else if, else statements are the same as an if, else statement, but with more branches. You can have as many else if statements as you want. Here's the structure:

if (condition) {
  // do something
} else if (different condition) {
  // do something else
} else {
  // default action
}

The else statement still acts as a default, but with more conditions to check first. Let's expand on the above examples.

var choice = 'right';
if (choice === 'left') {
  console.log('You have chosen the left path.');
} else if (choice === 'right') {
  console.log('You have chosen the right path.');
} else {
  console.log('That is an invalid choice.');
}
// You have chosen the right path.

var choice = 42;
if (choice === 'left') {
  console.log('You have chosen the left path.');
} else if (choice === 'right') {
  console.log('You have chosen the right path.');
} else {
  console.log('That is an invalid choice.');
}
// That is an invalid choice.

Similar to a single if statement, you can leave off the else statement here. If all of the if and else if conditions are false, then nothing will happen and it skips the entire set.

var time = 1200;
var timeOfDay = 'It is noon.';
if (time < 1200) {
  timeOfDay = 'Sometime in the morning.';
} else if (time > 1200) {
  timeOfDay = 'Sometime in the afternoon or evening.';
}
console.log(timeOfDay);
// It is noon.

`switch` Statements

switch statements (also known as switch, case statements) are similar to if, else if, else statements. Here is the structure.

switch (expression) {
  case 'one':
    // 'one' matches the result of the expression, do this
    break;
  case 'two':
    // 'two' matches the result of the expression, do this
    break;
  default:
    // no matching cases, do this
    break;
}

An expression is checked at the switch line, similar to an if condition. Once the expression is evaluated, it goes through the list of case values until it finds a match, and then executes the code within the case statement. If no match is found, then the default statement is executed (similar to an else statement).

Like else if statements, you can have as many case blocks as you want. Similarly, the default block is optional (just like an else statement).

switch statements are commonly used to match user input to an expected set of values. Here's an example.

var color = 'blue';
switch (color) {
  case 'blue':
    console.log('You picked blue');
    break;
  case 'red':
    console.log('You picked red');
    break;
  case 'yellow':
    console.log('You picked yellow');
    break;
  default:
    console.log('Invalid color');
    break;
}
// You picked blue

The break; lines at the end of each case are important. If those aren't there, fall through can occur. What this means is that when a case's code is run and there is no break, the code falls through to the next case, and that block of code also executes. A good practice to avoid this is to write your case value, then immediately add the break before adding the code in between.

That being said, sometimes the fall through effect is what you want to happen. In the following example, we’re checking the months to get the season.

var month = 'April';
switch (month) {
  case 'December':
  case 'January':
  case 'February':
    console.log('Winter');
    break;
  case 'March':
  case 'April':
  case 'May':
    console.log('Spring');
    break;
  case 'June':
  case 'July':
  case 'August':
    console.log('Summer');
    break;
  case 'September':
  case 'October':
  case 'November':
    console.log('Fall');
    break;
  default:
    console.log('Not a valid month');
    break;
}
// Spring

JavaScript (ES5) Loops

Martin Himmel — Tue, 27 Nov 2018 14:32:19 +0000

This was originally posted on my site at https://martyhimmel.me on December 26, 2016. Like a number of others on dev.to, I've decided to move my technical blog posts to this site.

`for` Loops

for loops are probably the most common type of loop. Two common uses of the for loop are iterating over an array and doing something with each element, and iterating over an array to find a matching set of values. Here's the structure:

for (initial expression; condition; incrementing expression) {
  // do something on each pass
}

The "initial expression" is an expression that marks the starting point of the loop. The "condition" is the ending point of the loop. The loop continues as long as the condition is true. Once the condition is false, the loop terminates. The “incrementing expression" is how the initial expression is changed on each pass of the loop (note: it doesn’t actually have to increment - it could decrement, increase by 2, etc.).

Here are a few examples of for loops. The first loop is the most common for loop that starts at the zeroth element (beginning) of an array and counts up.

// This will be used in all the examples.
var numbersAsWords = ['one', 'two', 'three'];

for (var i = 0; i < numbersAsWords.length; i++) {
  console.log(numbersAsWords[i]);
}
// one
// two
// three

This loop starts at the last element of an array and counts down.

for (var i = numbersAsWords.length - 1; i >= 0; i--) {
  console.log(numbersAsWords[i]);
}
// three
// two
// one

When a for loop is run, any expression in the "condition" part is calculated on every pass. When looping through a large number of elements, that could lead to performance issues. Using the previous two examples, if the numbersAsWords array had 100,000 elements, the length of the array would be calculated 100,000 times (on every pass). A way around this is to create an additional variable in the "initial expression” part of the loop and store the array's length. Then the array length is only calculated once at the beginning of the loop, instead of every pass through the loop. Here's an example:

for (var i = 0, arrLength = numbersAsWords.length; i < arrLength; i++) {
  console.log(numbersAsWords[i]);
}
// one
// two
// three

`for…in` Loops

for…in loops are used to loop over the properties of an object. Here is the structure:

for (var prop in obj) {
  // do something
}

The looping statement can be read as "for each property in an object." When using a for…in loop, you can access each property and value without knowing the specific name of the property. Remember, objects are sets of key/value pairs ("property": "value”). You can get the property name directly with prop (using the structure example) and the value by using bracket notation - obj[prop]. Here's an example:

var myWidget = {
  company: 'ACME',
  unitsSold: 42000,
  isModular: true
};

for (var prop in myWidget) {
  // log each property of the object as "property: value"
  console.log(prop + ': ' + myWidget[prop]);
}
// company: ACME
// unitsSold: 42000
// isModular: true

`while` Loops

while loops continue to run until a condition is false. The structure is:

while (condition) {
  // do something
}

for loops are great for iterating over a collection (e.g. an array). while loops can be used in the same way, but are generally better for doing something until user input or some sort of external condition says to stop.

An example of waiting for user input is the "game loop." Every game is built around the game loop. One example is while the player is playing, keep running the game - this is the most basic game loop, which would terminate by pressing the "Quit" button. Another example is while the character's hit points are above zero, keep fighting. An example with Tetris is while the blocks are below the top line, send the next block to the field. This list could go on indefinitely.

Here’s an example of a for loop variant:

var i = 1;
while (i <= 3) {
  console.log('Line ' + i);
  i++;
}
// Line 1
// Line 2
// Line 3

And this is a game loop example:

var isPlaying = true;
while (isPlaying) {
  nextAction();
}

Warning: It's easy to create an infinite loop using while (and do…while) loops. Make sure you have something in place to terminate the loop (an incrementor if looping a number variable, user input option to stop, etc.).

`do…while` Loops

do…while loops will do something once, then continue to run until a condition is false. The structure is a little different than a while loop, as the code is contained in the do block with the while containing only the condition.

do {
  // do something
} while (condition)

A do…while loop is guaranteed to run at least once, becuase it runs the do code block before checking the condition. After the first run, it will keep looping over the do block as long as the condition is true.

Since the do block is run first without checking the condition, this can cause unexpected issues if you're not careful. Here are two examples of do…while loops. This one works properly:

var myArray = ['John', 'Jane'];
var i = 0;
do {
  console.log(myArray[i]);
  i++;
} while (i < myArray.length);
// John
// Jane

This one fails silently:

var myArray = [];
var i = 0;
do {
  console.log(myArray[i]);
  i++;
} while (i < myArray.length);
// undefined

The second example has some hidden dangers. At this point, it logs undefined to the console and nothing breaks. However, if you needed to manipulate the data in the array, it would break the script. Here's a modified version of the second example:

var myArray = [];
var i = 0;
do {
  console.log(myArray[i].toUpperCase());
  i++;
} while (i < myArray.length);
// Uncaught TypeError: Cannot read property 'toUpperCase' of undefined

Adding .toUpperCase() (a string method) when calling an undefined array element breaks the script. For this reason, it's usually best to not use do…while loops unless you have a good reason to. More often than not, you can accomplish the same thing with a while loop.