In the 7th grade I convinced my Grandma to buy me a student copy of Visual Studio. I used to lug the accompanying Visual Basic book around at school. After getting kicked out of gym class I would sit in the office for that period and read it every day.

Image for post
Image for post
6th grade with loads of flannel and my Jansport backpack

I don’t remember actually doing much programming in those days, but I had a passion for learning more about tech and became obsessed with hacker culture. …


Image for post
Image for post
Taking some time to reflect in London, England

Thanksgiving 2017 I was hanging out with family near Las Vegas and generally having a great time, but I couldn’t stop thinking that maybe I should go back to school.

I was never actually good at school. I have a degree in Community, Environment and Planning from the University of Washington, which outside of my passion for sustainability, I was drawn to because the classes don’t use traditional grades and the students get to help set the curriculum. …


AnxietyTech is a new conference I’m organizing to discuss cutting edge technology and mental health. Everyone working in tech needs to attend! This is absolutely the time to have these discussions and build the community that’s going to end up making such a big difference for so many people’s lives.

The first tech conference I attended was JSConf/NodeConf 2011 in Portland, Oregon. It introduced me to a whole community of talented and interesting people. I remember seeing Dan Shaw on the light rail leaving the airport, being awestruck meeting Thomas Fuchs (of Zepto.js fame) at the arcade after-party, meeting Paolo Fragomeni and Charlie Robbins from the NodeJitsu team and later substack and so many others. I was inspired watching Chris Williams at NodeConf publicly challenge Ryan Dahl about giving node.js …


A few years ago I gave a talk at MountainWest JS called Error Handling in node.js. In that talk I extolled the virtues of creating custom error objects by extending the built-in Error type. Most of the content was inspired by Guillermo’s seminal A String is Not an Error. Let’s revisit that advice in the world of ES6 classes.

Why Do We Care About Error Objects?

Error objects are the only way to get stack traces in JavaScript. If you callback with or throw or reject a promise with a string instead of an Error, you won’t be able to trace where the error came from.

Here’s a simple…


Image for post
Image for post

Back in April I shifted into a platform/architect role in my job at PayPal. I was tasked with looking at stability, performance and quality. One of the first things I did was graph our JavaScript bundle sizes over time.

After a couple of weeks I noticed at several points we had pretty big spikes in our build size which added up to nearly 1mb. Looking into it I discovered that we were duplicating things all over the place.

NPM makes it very easy to install many versions of modules. That is fine in server code, but when bundling for the web this is a big problem. Webpack provides some basic tools for inspecting built files, but making sense of that data requires a few extra shell…


Image for post
Image for post

Inspired by the Zeit team’s post on the subject, my team at PayPal recently migrated our main server-side codebase to use Async/Await. I’m excited to share with you some of things we learned along the way.

Let’s start with some terminology:

  • Async function
  • Await keyword

People usually say async/await which is lovely and nice really, but you should know that they aren’t the same thing. There are async functions and there is the await keyword. They are certainly tied together in some ways, but async functions in particular can be used without await. How is that?

Async Functions Return a Promise

When you create a function with the async keyword that function will always return a Promise. When you return inside your async function it wraps your value in a Promise. …


This is the follow up to a post I wrote recently called From Require.js to Webpack — Part 1 (the why) which was published in my personal blog.

In that post I talked about 3 the main reasons my team decided to move from require.js to webpack:

  1. Common JS support
  2. NPM support
  3. a healthy loader/plugin ecosystem.

Despite the clear benefits in developer experience (DX) the setup was fairly difficult and I’d like to cover some of the challenges we faced to make the transition a bit easier.

From paths to alias to NPM

The first thing you do when you’re converting from require.js to webpack is you take your whole require.js configuration file and convert it to a webpack.config.js


As a lead UI engineer on the consumer web team at PayPal I’ve often seen patterns of mistakes that repeated themselves over and over again. In order to put an end to the most egregious errors we started using JSHint early on in the project. Despite its usefulness in catching major syntax errors, it did not know anything about our code, our patterns or our projects. In trying to improve code quality across the whole consumer web team we needed to find a linting tool that let us teach it how we wanted to code.

Enter ESLint

ESLint was started in 2013 by Nicholas Zakas with the goal of building a customizable linting tool for JavaScript. With that goal in mind Nicholas decided to make each rule standalone and provided a mechanism to easily add additional rules to the system. …

About

Jamund Ferguson

UI Engineering Leader

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store