It’s The Little Things That Get You

I spent some time today dealing with a layer of data that was added to an ESRI REST service. The service layers are zero base indexed which means you can reference them based on their position relative to each other. The first layer is identified at position zero while the second is 1, the third is 2 and so on.

The new layer was just before the fourth existing layer. This means the new layer became the fourth, the fourth became the fifth and the fifth became the sixth. Are you following along?


Anyway, I was working on a web app that consumes this service and it references the service layers based on those index positions. I added some new markup and some code for the added layer and changed the existing code to reference their two new position numbers. At first everything seemed to be working fine. Then a coworker noticed that the new layer’s data was showing on screen by default (you’re supposed to check a box first). It took me a while before I finally realized that it was being controlled by a different checkbox that controls the layer right after it in the service.

To make an already long and confusing story shorter, there was a second reference to the service indexes in my code. When I had designed the app a few years ago I, for some reason, found it expedient to make two, hard coded references to the index. Instead of taking the time to create a variable, I had repeated a hard coded number that could be changed by an outside source.

My poor design choice can back to bite me. Not only did I repeat code, I made it confusing to update. It’s embarrassing to admit that I wrote code that even I couldn’t figure out later. But it goes to show that taking the time to design things correctly from the start will pay off in the future. It’s the little things that get you; that second hard coded index number that’s nearly impossible to notice.

Taking Time To Tinker

In his famous lectures on creativity, John Cleese says that if you play around with a problem and put off calling it done for a while, you’ll often come up with a better solution than if you simply took the first solution that came to you.

Tinkering with an idea or a map or a code base is a great way to not only develop it but to develop it into something better than it had been before. It’s taking something that could be called complete but then further playing with it and manipulating it until it becomes something else.

This is an approach I take with application and code I’ve written. Even after I’ve finished a project, I’ll let it sit for a while and then come back to it. When I do, I try to reimagine its uses or how it can be written. I went through this process today with a code module I had written over a year ago. With fresh eyes I was able to play around with the code. I asked myself why something was written a certain way. I tried things like stripping out important lines of code just to see if it would improve performance in other areas. I also had fun seeing just how massively I could make the code fail.

The result of my playing around with my code wasn’t as dramatic as an entirely new application. But I was able to reduce its size and rewrite parts of it more elegantly. Well worth the time it took to tinker.

Objective Reasoning – The Basic Javascript Object

What is an Object?

In Javascript an object is simply a container or store of properties that are related to what the object is modeling. These properties can be primitive data types, other objects or functions. Here’s an example of an empty object with no properties:

const furBearingTrout = {};

I’ve used object literal notation which is doing just what it sounds like – literally writing out the notation of an object. We do this using curly braces {}.

How to create properties

When we want to set a property on our object we can do it one of two ways:
1. Use bracket notation where we state the object name along with a property name in brackets and then assign a value using the equal sign:

furBearingTrout[“name”] = ‘Alpino-Pelted’;
furBearingTrout[“url”] = '';

2. Use dot notation where we state the object name followed by a dot followed by the property name we want to use and then assign a value using the equal sign: = ‘Alpino-Pelted’;
furBearingTrout.url= '';

I could have created our object with properties already assigned. Note that properties are written as name:value pairs separated by commas.

const furBearingTrout = { 
  name: ‘Alpino-Pelted’, 
  url: ''

How to access properties

Once we have properties we can access them using the same two methods we used to set them just without the equal signs that assign values.

console.log(; //outputs ‘Alpino-Pelted’
console.log(furBearingTrout[‘url’]); //outputs ''

We can also create objects using the constructor method (new Object) or the Object.create() method but for this article we’ll stick to the literal notation for its simplicity and visual aid.

Functions in objects are methods

When the property is a function we call it a method. Methods do something with the data stored in the object. Imagine we had the following properties:

const furBearingTrout = {
  name: ‘Alpino-Pelted’,
  url: '',
  view: function () {
    console.log(`View the ${} trout at ${this.url`;)

You call a method by accessing the property name it’s associated with followed by parentheses.

furBearingTrout.view(); //ouputs ‘View the Alpino-Pelted trout at

Why do I use ‘this’ ?

The ‘this’ keyword simply references the very object it’s inside of. So is the same as saying Outside of the object we would refer to but inside the object we refer to

There’s a lot more to objects than what I’ve written here. But if you understand these basics you’ll already be able to model some fairly complex real world data and be able to manipulate it.