Showing all entries for: April 2017

My résumé is online. Full up-to-date and current. Finally. And although I’m not looking for a new job (I love working at Fingerprint!), I’ve been meaning to update my résumé and get it online for quite a while now.

My portfolio is online. A visual timeline of my work over the years — complete with screenshots!

Arrow Functions in JavaScript

The ECMAScript 2015 (ES6) standard introduced “arrow functions” to JavaScript, which on the surface looks like syntactic sugar over JavaScript functions, but have some subtle—but useful—differences.

First and foremost, you can use arrow functions anywhere you would use an anonymous function. For instance, in a timeout:

setTimeout(function() {
  console.log('Timeout reached')
}, 500)

In ES2015, the above can be written as:

setTimeout(() => {
    console.log('Timeout reached')
}, 500)

NOTE: In the above examples, we have no parameters (), but if we had only one parameter, we could leave off the parenthesis and that would still be valid. With arrow functions, zero or more than one parameter requires parenthesis.

Inherited Context

So we reduced the first example by five characters, and while that’s a welcome enough change when you’re working in JavaScript all day, that’s not the only benefit you gain from using arrow functions. Before I get into what those are, what do you think the following example prints out?

function myFunc() {
  setTimeout(function() {
    console.log('My name is: ' + this.name)
  }, 500)
}

myFunc.call({ name: 'Jonathan' })

// My name is undefined

“My name is: undefined” is probably not what the code had intended to output, but that’s what happened. To get the function that is passed to setTimeout() to inherit its parent’s context (e.g. this), you need to bind that function to the context:

function myFunc() {
  setTimeout((function() {
    console.log('My name is: ' + this.name)
  }).bind(this), 500)
}

myFunc.call({ name: 'Jonathan' })

// My name is Jonathan

The difference may be hard to spot, but it’s there. This time we pass a bound function to setTimeout() instead, which entails wrapping the function in parenthesis and calling bind(this). With arrow functions, none of that is necessary because they automatically inherit the surrounding context (this of its parent scope):

function myFunc() {
  setTimeout(() => {
    console.log('My name is: ' + this.name)
  }, 500)
}

myFunc.call({ name: 'Jonathan' })

// My name is Jonathan

Not only is that less typing than the bound function example, it’s also more intuitive, which ultimately translates into less bugs. In fact, with arrow functions, you should rarely (if ever) need to use bind(this) ever again. As another example, a common scenario is to pass a bound function as a listener:

myObj.on('click', this.handleClick.bind(this))

You can use an arrow function instead to make the code more natural:

myObj.on('click', event => this.handleClick(event))

In the above example, we are actually passing the listener as an arrow function and all it is doing is forwarding the parameter (event) to the real handler function (this.handleClick()). In this case, arrow functions do not decrease the lines of code, however, by being explicit about the arguments we pass to the function, the code is more “honest” and thus more clear.

Implicit Return

Another subtle difference in behavior is that arrow functions can have an implicit return when written as an expression (no curly braces, which would be a block):

myArray.map(x => x * 2)

Is the same as…

myArray.map(function(x) {
  return x * 2;
})

This particular feature is “syntactic sugar” that makes your code more compact by allowing the omission of the return statement, a bit like CoffeeScript and Ruby, but not exactly because this only works in cases where the only thing in the function body is the return statement. Personally, I think that was a good decision because allowing implicit returns with other logic would just make code more unreadable in my opinion.

And that’s about it! While not much, it turns out arrow functions provide a little more than just simple syntactic sugar. The subtle changes in behavior are welcome additions to JavaScript, and contribute to a more pleasant coding experience overall.

Digging Through the Archives

This website started life as a Tumblr blog (jonbeebe.tumblr.com) way back in 2010 before I finally registered a domain name for it (jonbeebe.net). Since then, my life has changed immensely, and so has this website. I’ve reset it and reboot it more times than I can count. Recently, I started posting entries to this site once again. This time, however, I decided to take a different approach.

Rather than blowing everything away and starting new, I thought I would attempt to scour the internet for all traces of past incarnations of this website and restore the archives. Thanks to the Wayback Machine, I was able to restore most of all my previous entries. I also discovered that I had written a lot more over the years than I realized.

Unfortunately, there were several entries that are lost forever due to not being able to find any cached copies anywhere, but I was able to get most of them because there were more snapshots during the times I was more active on this website.

Overall it was a very nostalgic experience for me, and sometimes a little sad, particularly remembering the great experiences we’ve had with Carlos Icaza (my mentor who had passed away last year). For each entry, I could remember the snapshot in time when that entry was written. It really highlighted just how much my life has improved since 2010, and how exciting it has been over these years.

During the process, I tried to fix any links that were broken (or redirect to a cached version if it was available) and add notes wherever necessary. It was a lot of work, but I’m glad I was able to preserve most of the website’s past.

Here’s to no more huge gaps in the archives!

xcfg

Today I published a new package on npm: xcfg.

It’s a cross-platform config file management package that’s fairly simple, but pretty useful for those who write Node.js applications such as command-line utilities or desktop software in the form of Electron apps.

Since all the details of the project are on the package page, this entry will just cover the technology I used to create it.

JavaScript (ES2015)

First and foremost, this is a JavaScript package for the Node.js ecosystem, written using the ECMAScript 2015 standard. I had explored Python 3 recently, but ultimately decided to move forward with the Node.js ecosystem. I was momentarily torn between the two, because I think Python 3 is a fantastic language. However, I’m vastly more comfortable in JavaScript, and I’m a big fan of Node’s package manager (npm). Conversely, I really don’t like Python’s distribution story. In fact, I think it’s a nightmare compared to the npm experience.

Case in point: I started writing xcfg yesterday evening and finished up the remaining tests and documentation this evening before finally pushing the project onto GitHub and running npm publish. It’s a small package, so that’s obviously why I was able to finish it in such a short amount of time, but the process of setting up a package.json and publishing to the npm registry was an absolute breeze. Publishing added only a very minimal amount of time and effort on top of coding, writing documentation, and adding unit tests.

Documentation and Testing

As far as documentation goes, I put some basic usage info in the project’s README and used ESDoc for the API docs. ESDoc looks great by default and has a familiar set of tags so it wasn’t difficult to use, despite never having used it previously. The only problem is, out of the box, it doesn’t work for Node.js projects but that was easily fixable with the esdoc-node development package.

For the unit tests, I used a combination of Mocha and Chai and at version 1.0.1, there are 10 unit tests (all passing, of course). I thought Mocha was pretty good but I may explore other assert libraries for my next project because Chai has a strange API and was a little annoying to validate with my chosen style guide, which brings me to my chosen…

JavaScript Style Guide

I personally believe it’s important for a project to follow a style guide. Not only does it make it easier for multiple people to work together on a single codebase, the consistency that a style guide enforces really helps improve programming discipline and ultimately results in less bugs in the final product. Given JavaScript’s dynamic nature, following (and linting with) a style guide is a great—if not essential—way to prevent a whole class of (stupid) bugs.

I recently discovered the JavaScript Standard Style and chose to follow it for xcfg. The project has it as a development dependency and can be linted with a simple npm command: npm run lint. I found that I agreed with all of its rules, even the more controversial decision to disallow extraneous (in other words, most) semicolons.

And that concludes my technical overview of xcfg 1.0.1. If you find any value in this package, please take a moment to star the GitHub repo.