What is the Temporal Dead Zone in JavaScript?

You may have heard this term get thrown around in JavaScript dev circles. No, it is not something the crew of the USS Enterprise encountered in Star Trek, although that would be really cool to watch!

No, the Temporal Dead Zone with regards to JavaScript is a special edge case which came from the introduction of a couple of new features in ES6.

To give a bit of background, consider this code:

function doSomething() {
  console.log(something);
  var something = 'test';
}

doSomething();

The output of the code above will be ‘undefined’. If you have been using JavaScript for a little while then that makes sense in a weird sort of way. Or, to put it another way, the output of ‘undefined’ would be expected. This has to do with the fact that in JavaScript, variables declared with the ‘var’ keyword are hoisted to the top of the execution context.

Hoisting? Execution context? What? So this speaks to those who may be new to JavaScript. JavaScript is admittedly a weird language, but I will explain these terms in detail.

So what is Hoisting? This refers to the concept in JavaScript that variables are moved to the top of the function they are in regardless of where they appear in the function. From the example above, I declared and initialized ‘something’ after I used it. The JavaScript compiler looks through all of that code above (I know, a whopping 5 lines) for variables and then “moves” them to the top, meaning that in the mind of the JavaScript compiler it looks like this:

function doSomething() {
  var something = undefined; <- Hoisted variable
  console.log(something);
  var something = 'test';
}

doSomething();

If the variable just shows up out of nowhere like my first example and it doesn't have a value assigned to it, it just assigns the undefined data type to it. That is why the output of the code is 'undefined'.

Enter ES6/ECMAScript 2015

In ES6, the 'let' and 'const' keywords were introduced to the language. Variables declared with the 'let' keyword are not scoped to the function they are in. They are scoped to the block that they are declared.

For those of you coming from another language, that makes sense right? Most programming languages are block-scoped. However, prior to the introduction of 'let', variables in JavaScript were function-scoped. This meant that any variables declared outside of a function are global to the entire application and variables declared within a function are local to that function.

Now with the new version of JavaScript, 'let' makes a variable behave just like they do in most common languages. There is a key difference though. They are not hoisted. With that in mind, let's revisit my trivial example from above using 'let' instead of var.

function doSomething() {
  console.log(something);
  let something = 'test';
}

doSomething();

The output of the code above is a ReferenceError. So this is normal right? This doesn't sound like something Lieutenant Commander Data would have to figure out. So what is the Temporal Dead Zone?

Well let's answer that with a final example:

function doSomething() {
  return something;
}
let something;
doSomething();

Guess what? The output is 'undefined'! This answers our question to what the Temporal Dead Zone is. The Temporal Dead Zone is a period of time between when a variable enters scope and when it is declared whereby it can't be accessed.

I know this was a lengthy answer, but it was necessary to explain because I felt it would actually allow you, as the reader, to understand it in a more thorough way.

It's also important to note that the 'const' keyword is subject to this as well.

Just Start Now

Just start now.

This is the best advice I give to not only get into Programming, Mobile Apps but just about anything you can think of.

You’ve all heard the idiom “Give me 6 hours to chop down a tree and I’ll spend the first four sharpening my axe.”

Wrong.

Our world is shaped by the people who just found a tree to chop down and got to work. You don’t have to spend years in School learning to create a piece of Software. Start creating one right now. If you want to lose weight and exercise, don’t go to the store and buy a book or hire a personal trainer. Instead, set a goal to walk just 10 minutes per day. Just start now.

HTTPotion not making get request

I was writing a small app in Elixir today that required making an HTTP request to a 3rd party API. To do this, I used the HTTPotion library. I thought I had everything set up properly but I would get an error. It turns out you have to call HTTPotion.start. If you’re using Mix for your project, you can just edit your mix.exs file to start HTTPotion automatically.


def application do
# Specify extra applications you'll use from Erlang/Elixir
[extra_applications: [:logger, :httpotion]] #added httpotion atom
end

Good process is not a silver bullet

I recently read an article that I felt was very well written and much better than the usual Software Development articles that I come across on sites like Medium. The title is “How Terrible Code Gets Written By Sane People”.

I definitely recommend you read it but there was a section of it in particular that really hit home for me. The section was titled “Assuming that good process fixes bad people”. This is something I have dealt with a lot throughout my career as the larger companies I have worked at devote a lot of resources to coming with what they feel are the best processes and/or maintaining existing ones.

In these cases, Management definitely treats their processes like some sort of silver bullet. As if, this one perfect process is somehow going to make every project go more smoothly. I get a kick out of companies that pour time and money into converting to Agile Methodologies and concoct this Byzantine-like labyrinth of a process that has you feeling like a cog more than a contributing member of the team. If such people had taken the time to read the Agile Manifesto, they would see that one of the tenets are “People over Process”!!!

Something else that the author of this article touched on was the importance of hiring smart and talented people and how this is far better than simply improving your processes. I agree with the author in that over-reliance on a process can actually cause talented people to leave the company because their creativity is crushed. I feel that this stems from a fundamental flaw in the way that Business views Software Development. They seem to rely on process and policies because they seem to have this vision of a Universal Programmer. By this I mean that when they need to hire a Programmer, they simply plug a new one into the vacancy, hand them a training manual, and they’re able to be up and running. From there they simply take Business requirements and turn them into code like some sort of translator from Business-Speak to Machine Code.

I can’t imagine a more toxic scenario! Writing Software of any notable complexity is an exercise in collaboration. It means you have to talk to people and work together to solve problems. There aren’t a bunch of universal design patterns that will eliminate all confusion and will be universally understood by any Developer that jumps into a project. As useful as I think Test Driven Development can be, it’s not going to replace helping someone to debug a problem nor will a suite of tests ever be perfectly written to avoid the need for simply sitting down and chatting with someone about the code design of a project.

Both Business and Developers are trying to find more and more ways to put sugar on a bitter pill. The bitter pill in this case being that Software Development is hard. Developing Software is damned hard, it’s complex and it’s only going to continue to be this way.

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

Linus Torvalds →

Good enough

Invariably, good enough is better than perfect. Indeed, good enough is often better than ideal.

Why?

Because the good enough solution gets you to ship NOW. The ideal solution keeps you in a holding pattern until YOUR criteria are met, not your Customers.

Good enough leads to results that you can act on and learn from. These results provide actual data that you can use to inform your decisions and THEN allow you to work on what your ideal outcome is.

I’m reminded of a talk that a Game Developer gave. He mentioned that he read the source code of the game Doom and saw that they used a very simple algorithm for loading map data. He raged that they should have used proper Software Development principles and advanced Data Structures to load and save the data. He set about to show them how right he was by implementing his own vision of what the code should look like. He found that his code was not only slower, but harder to understand and didn’t work very well. He also understood another concept very clearly…

The author of the code he raged against drove to work in a Ferrari, was worth millions of dollars and released many successful games while he was just someone on a mailing list complaining about his “simplistic” code…

He never forgot the lesson that often, good enough IS ideal.

Everything old is new again

I was perusing courses on Tutsplus, Pluralsight and a couple of other sites as well as my daily dose of Programmer-centric newsletters and something caught my eye. I noticed that Functional Programming was a sort of common background noise throughout.

I vaguely remember mention of it back in my days in College and University but nothing substantial. The one thing that I remembered is that it’s a very old concept, dating back to the 60s and 70s.

Now, this probably doesn’t strike you as interesting and it doesn’t really to me either. However, it’s been a theme that I’ve noticed with other concepts as well in Software Development. A while back (60s and 70s), Functional Programming sucked and Procedural Programming was the best. Then after a while, Procedural Programming was garbage and Object-Oriented Programming was the way to go. Now we seem to be going back to Functional and maybe Procedural.

I watched a talk on Microservices and I found this to be a part of this resurgent theme as well. Essentially, Unix is a bunch of little programs or, in some ways, a bunch of little Microservices. But as companies grew and computing became more complex, big Monolithic systems were THE WAY TO DO THINGS.

You see this concept of cyclical ideas and concepts in the JavaScript world too.

For what my opinion is worth, I recommend just focusing on the fundamentals. I try to learn how things work (Browsers, languages, data structures) at a fundamental level and fill in the gaps as needed. This idea recycling has me feeling exhausted.

Error: cannot stat filename too long – How to Fix Git Issue

This is an issue I ran into on my Windows machine. Some of the files in my node_modules had filenames that were nauseatingly long. This causes an issue
with git where you get the error: “Error: cannot stat filename too long” or something to that effect.

Here’s how I fixed it. Run the following in your terminal:

git config –system core.longpaths true

I then made sure that the node_modules directory was not in the Git repo:

git rm -r –cached node_modules

I then added the node_modules to my .gitignore file.

Hope this helps!

Why Does Programming Suck?

This post from John Somnez caught my eye:

Why does Programming suck?

In his post, he addresses an email from one of his followers asking “why does Programming suck?” I was taken back by this question. It’s something I’ve asked myself a lot over the years, but due to my insecurities I felt that maybe I just wasn’t good enough to do the job. Over time I’ve seen this question pop up again and again. There was even a talk that I watched delivered by Thomas Figg describing the horrors that he has experienced in the Industry. In a way, I felt vindicated. I felt that the responsibility had been lifted from me. The responsibility of trying to become better as a Developer and a Communicator. “Of course it’s not me, the Industry just sucks.”

One of the things that both Figg and myself agree on is the sad state of some of the tools that we use. I can’t tell you how many times I’ve spent hours trying to get Tool A to work on Machine B in a process that usually involves me putting in more detective work than those who worked on the JFK Assassination! It is at this point that I will rant about the explosion of different JavaScript Frameworks that have been introduced in the past couple of years. All of them touting “features” like, “it’s like Backbone but more lightweight and uses template engine X instead of template engine Y.” I contest that Front-End Development is already a miserable and often times soul-crushing experience due to the lack of standardization across the major Browsers. Do we really need to be changing and introducing tools in an avalanche of new things we have to learn?

This ties into a point John Somnez makes about why programming sucks. The constant pace of change in our Industry. He argues that professions like Electrical Engineering don’t change very much over time. A circuit is a circuit. In some ways I agree with this, but my gut feels differently. In some ways, this is true. However, in the beginning of Electrical Engineering, there were many new ideas being introduced. For example, Alternating Currents (AC) was first utilized in the 1850s which was incompatible with the infrastructure that Edison had setup based on Direct Currents (DC). It was adopted after much resistance (pardon the pun). Today, Electricians are the practical application of Electrical Theory and have reliable and standardized tools to allow them to perform their work.

My personal feelings on the matter is that programming sucks because of a lack of standardization. In the early days of my career doing Web Programming, MVC was not a widely adopted way of structuring code. In fact, every project I took on seemed to be a snowflake. Each one was coded in an entirely different way. Although WordPress, Drupal and Joomla were starting to come into their own at the time, custom web applications simply followed the Architecture of least resistance. Want an SQL query displayed directly to the user? Sure! Go for it! The aforementioned CMS’ as well as CodeIgniter and Zend Framework did much to remedy this and today I would be hard pressed to find a PHP project that was built without the use of a CMS or Framework. It seems like we have come to some sort of standardization when it comes to MVC. However, we still have a long way to go in my opinion.

The next domain we need to standardize is that of the Front-end. This is something I feel we as Developers need to do more to solve. Take jQuery for example. Yes, it has weaknesses and drawbacks. But think of the benefits it offers. I can select an element and change its color if I wanted to in one line of code! I did Front-end development for a time before jQuery existed. If you haven’t done that then compare it to writing Assembly code in some regards. The DOM combined with Browser compatibility issues ensured that the most trivial tasks would take about a full day of work with enough defensive programming checks and if/else statements to make you feel like someone suffering from Clinical Paranoia. jQuery comes and takes a lot of that away. Were Developers happy!?! No! We needed it to be more lightweight which led to the birth of Zepto and other variations because Developers can be an arrogant bunch. We see something and think it can and should be done better.

Developers need to be comfortable with the idea of Tradeoffs and we need to be better at communicating to our Stakeholders and our Clients. We also need to promote the idea of “the right tool for the right job.” To further riff on this idea, I recently worked on a Ruby on Rails project. The site was basically a CMS and even included a Blog, User Management, etc. However, it was coded entirely from scratch and making any changes to it is perilous because there is no testing and the original developers are long gone. My contention was that Ruby on Rails wasn’t even needed for this. Yes, you are probably screaming a list of Ruby CMS’ into the screen right now. However, I would argue that this was a perfect job for WordPress! WordPress had a lot of the desired features right out of the box and millions of plugins available. But, because the original Developers were Rails Developers, they wrote it from scratch. If all you have is a hammer, then everything is a nail as they say.

To conclude, my answer to the question of why Programming sucks is that it is because of us. Because of Developers. Our natural inclination towards trying to improve tools by writing new ones makes it much harder to standardize our tools. We can’t blame our Clients or Stakeholders for our misery because they trust us to weigh the pros and cons of our tools and proposed solutions. They don’t understand our problems and they certainly can’t adapt their goals and expectations unless we explain it to them in a clear way.

The Myth of the Interchangeable Programmer: Can’t We Just Offshore Him?

This is an older article I bumbled across on the InterWebs but one that I feel still rings true unfortunately.

The Myth of the Interchangeable Programmer: Can’t We Just Offshore Him?

While I do encourage you to read the article, I will summarize and weigh in. The fact is that Software Development is really really hard and a lot of times it’s really shitty. What do I mean by that? Several things which I will cover briefly.

First, the methodologies available to building Software products are still new. While methodologies like Agile are helpful, they are by no means a silver bullet. The advent of Test Driven Development (TDD) and Acceptance Testing is making a difference in the quality of code being produced, however, there are still a large number of Developers and Companies who have not adopted these concepts. Along similar lines, much of the legacy code still out in the wild was not developed using TDD, so trying to implement it into these projects is incredibly difficult. Although Ruby on Rails has lead the charge of using TDD in the web development space, much of the way development works on the web doesn’t make doing TDD easy. For example, it’s difficult to test things like Async calls, etc.

Second, many of the tools Developers use are simply broken. I just spent the better part of 5 hours of my own time in last night trying to get a unit testing library working with my Android Project. It required reading a nauseating number of posts all of which contained several uses of the word “hack” in their instructions. I couldn’t imagine going into surgery and listening to the Doctors talk about how they had to hack together a device to perform Laparoscopic Surgery on me and feeling very confident. How about a Carpenter that has a broken level or a Drill that overheats and has a short in it?

Last, our methods of managing Software Projects can sometimes be compared to an ADHD seven-year-old’s Birthday Party. Chaotic doesn’t even begin to express some of the projects I’ve been involved with. In these projects, several priorities were changed back and forth, and were often dropped entirely due to poor communication, etc. As a side note, the word “priority” was never meant to be pluralized and only recently in history have people started using it in the plural form.

To summarize and paraphrase the article (again, I really encourage you to read it), Developers are treated as little more than manual laborers. That is, management is under the assumption that to increase productivity in a project you can just add more Developers to decrease the amount of time it takes to complete said project. One way which was, and still is in some cases, to outsource the work to places like India and China where you can get people to work for you for very little money.