
This is a brief guide to how I use Emoji and GIF and a few contextual notes about what Emoji I use, when I use them and what they mean to me.

## Principles

- Unambiguous - use emoji and GIFs that may often have multiple meanings
- Enhancement - only use Emoji as an enhancement to an existing message

## Norms

- **GIF** - generally choose Adventure Time / non-human cartoon gifs

## When I use Emoji

- reacting to a message in Slack or Discord
- enhancing an existing message for Twitter
- responding to a text where reactions are limited but words aren't necessary

## How I Use Emoji

My most used public messaging Emoji:

- 🚀 - when I'm excited about something that's happening (shipping software or forward movement in work/side projects)
- ✨ - when I'm in awe of something someone has done or grateful for something that's happened/happening
- 🌱 - when someone (including myself) has a moment of self reflection or personal growth

My most used private (Slack/Messages) Emoji:

- ✅ - I have done something about this
- 👀 - I am looking into this (also, acknowledgement that I've seen something)
- 🦺 - I believe this is safe to try

My most used Emoji for Pull Request (code) reviews:

- ℹ️ - I am giving you context for this change
- ❓ / ❔ - I am asking an exploratory question based on my experience 
- 📌 - I'm requesting this be changed
- ‼️ - I believe this could be problematic, can we discuss

Other Emoji I use:

- 🎉 - when I'm excited about something personal
- 💙 - when I've had a good moment with a peer
- 💜 - when someone has noticed a moment of personal growth for me

Emoji I try to avoid:

- most people faces and hand symbols
- 🔥 - ambiguous

Personal Emoji & GIF Usage Guide


I often find myself needing a dynamic value for a key in an object in JavaScript when both accessing and storing values on the object.

Let's start with how you'd do this without a dynamic key:
```ts
const args = {
	StaticKey: "some value"
}
```

If you know you want to use a dynamic key to store the value on, there are two ways to do that.

## The first way: on object creation

For the purpose of demonstration, I'll create a constant called `DynamicKey`. You can imagine that a function may take a string that it will use:

```ts
const someKey = "DynamicKey"
```

And on the object, rather than writing `DynamicKey` directly, I'll use the constant as the key:

```ts
const myDynamicObject = {
	[someKey]: "some value"
};
```

The important thing to note here is that the key is surrounded by square brackets (`[ ]`). Setting the key up this way tells JavaScript that what's inside needs to be interpolated as its value.

Here's what it would look like if you were to have the code above and `console.log` it:

```ts
const someKey = "DynamicKey"

const myDynamicObject = {
	[someKey]: "some value"
};

console.log(myDynamicObject); // {DynamicKey: "some value"}
```

## The second way: setting the key/value pair on an existing object

Let's stick with the example above that we have `myDynamicObject` and it has `DynamicKey` on it still. How would I interpolate a variable for the key in the existing object?

Assuming we want to put another value on an existing object with a dynamic key, we can do:

```ts
const secondKey = "unicorns are"

myDynamicObject[secondKey] = "awesome sauce"
```


Now if I were to `console.log` the `myDynamicObject` object, I would see:

```js
{
	"unicorns are": "awesome sauce",
	DynamicKey: "some value"
}
```

Now you have two tools to do dynamic variable interpolation for object keys.

Build something awesome!


Learn how to interpolate a JavaScript variable for an object key for dynamic keys in a JavaScript object.

Interpolate a JavaScript variable for an object key


[Josh Comeau](https://twitter.com/JoshWComeau) has a wonderful article about using CSS variables in style attributes in React props that has changed the way I write CSS in React ([link](https://www.joshwcomeau.com/css/styled-components/)).

Unfortunately, when using TypeScript, this method leads to a build error.

## The Error

```shell
TS2326: Types of property 'style' are incompatible.
Type '{ "--color": string; }' is not assignable to type 'CSSProperties'.
Object literal may only specify known properties, and '"--color"' does not exist in type 'CSSProperties'.
```

## How to Fix it

There are two ways to fix the build error:

- cast the style object to `React.CSSProperties`
- create an interface that extends `React.CSSProperties`

### Cast the style object to `React.CSSProperties`

The part to note here is that the `style` object is followed by `as React.CSSProperties`:

```tsx
 <StyledComponent style={{ "--color": colorValue } as React.CSSProperties}>
 {/* details... */}
 </StyledComponent>
```

The downside of casting is that it will allow any key arbitrarily. If you want to be explicit about what keys are available, try the next method, **Extending CSSProperties**.

### Create an interface that extends `React.CSSProperties`

Extending `CSSProperties` has the advantage of allowing you to say which keys are acceptable:

```ts
import React, { CSSProperties } from 'react';

export interface CSSPropertiesWithVars extends CSSProperties {
  '--color': string;
  // any other vars you may use
}
```


How to define CSS variables in style attributes in react and Typescript

Fix CSS variable keys in style attributes in React and Typescript


Lorem Ipsum is a fundamental tool for building things for the web, so here's a collection of Lorem Ipsum generators.

## Bob Ross Ipsum

[Ariel](https://twitter.com/ariel_n) stumbled over this after finding Khaled Ipsum and knew this was Lorem Ipsum was for me.

Sample: 

> Maybe we got a few little happy bushes here, just covered with snow. Take your time. Speed will come later. Nothing wrong with washing your brush.
>
> Only God can make a tree - but you can paint one. Be careful. You can always add more - but you can't take it away. I get carried away with this brush cleaning. We'll lay all these little funky little things in there. This piece of canvas is your world. Work that paint.

Go to [Bob Ross Ipsum](https://www.bobrosslipsum.com/).


## Khaled Ipsum

[Ariel](https://twitter.com/ariel_n) discovered this Lorem Ipsum during a tweaky build jam. Key to success.

Created by [Patrick Wong](https://twitter.com/patrickswong)

Sample: 

> You see that bamboo behind me though, you see that bamboo? Ain’t nothin’ like bamboo. Bless up. The key to more success is to have a lot of pillows. Watch your back, but more importantly when you get out the shower, dry your back, it’s a cold world out there. The key is to drink coconut, fresh coconut, trust me. Let’s see what Chef Dee got that they don’t want us to eat. It’s important to use cocoa butter. It’s the key to more success, why not live smooth? Why live rough?

Go to [Khaled Ipsum](http://khaledipsum.com/).

Lorem Ipsum Collection


I'm embarking on a new chapter of life: **joining Murmur, a platform that will change the future of work.**

On Tuesday, October 13th, I'll be joining the team (as employee #2) at Murmur to build collaborative software to help teams decide how they're going to work together. We're doing this by guiding them through the process of making working agreements where everyone gives consent.

[Aaron Dignan](https://aarondignan.com) (author of [Brave New Work](https://www.bravenewwork.com/) and Founder of [The Ready](https://theready.com/)) reached out to me to talk about self-management a few weeks ago and he introduced me to the vision for Murmur. When he asked me "what do you think?" the first thought in my mind was "my whole adult life has led me to this moment of saying 'this was what I was made to do.'".

Thankfully, Aaron thought so too, because he asked me if building the Murmur platform was something I wanted to be a part of! As an alternative, he gave me the opportunity to simply give advice about how I would build the software. If I did decide to join, the decisions would be the ones I'd want to make anyways.

I wasn't _looking_ for something new, in fact, I was preparing to dig into my path at Webflow deeper doing this same type of work, but within teams rather than as software. Because I wasn't looking, I had mixed emotions: I knew this was a rare opportunity that I would regret not taking but I had also started to settle in to making an impact at Webflow with people I enjoy working with on a product I think will also change the future of innovation.

After a week of grappling, I told Aaron that I'm all in.

I'm excited to be a part of the inception of Murmur and excited to see what's to come in building software to help teams decide how to work together in a way that puts humans at the center of the process.

## Summary

**Where are you headed?**

A startup called [Murmur](https://murmur.com).

**What will you be doing?**

Building a platform for teams to collaborate on how they decide to work together. I'll be involved in designing and building the software and helping to create a team.

**What's interesting about it?**

- This is a stepping stone to helping teams and companies move towards self-organizing. One of my greatest passions at work is helping teams do the meta work of deciding how they work together, work on process improvement and increase clarity.
- This platform _doesn't exist_ today. I'll be involved in helping get the software topology and software systems up and running and building out a team to help it start and help it scale.
- This will be the second self-organizing structured organization I've been a part of but the first one where there's someone who knows what works and what doesn't and how to figure out what works and what doesn't in a way that makes me confident we'll do it the most authentic way.

**What's scary about it?**

As always, I'll reach for an analogy involving canoes...

Every time I've changed jobs in the past, I've brought my canoe to an existing reservoir and helped clean it up or make it better, but the hole was dug and the water was there.

With Murmur, I'm coming into a plot of land, a map, a blueprint and some shovels and the reservoir has to be dug and filled. For me, that comes with a great amount of responsibility.



I'm embarking on a new chapter of life: joining Murmur, a platform that will change the future of work.

Joining Murmur


I thought `toggle-word-wrap` would enable wrapping a line when it was at the edge of a buffer, but it turns out what I wanted was `toggle-truncate-lines`.

If you want to enable word-wrapping in Emacs, use `M-x toggle truncate-lines`.

![Using toggle-truncate-lines to enable truncating lines](/img/emacs_toggle-truncate-lines.gif)


A quick tip on how to enable word wrap in Emacs.

How to REALLY enable word wrapping in Emacs


If you're using Prettier and want to have backticks be the character that wraps strings, you need to do the following:

Install the following ESLint npm packages:

- eslint-config-prettier
- eslint-plugin-prettier

Update your eslintrc.js with this rule:

```js
module.exports = {
  rules: {
    quotes: ["error", "backtick"],
  },
}
```


and your `.prettierrc.js` with this config:

```js
module.exports = {
  singleQuote: false,
}
```

Add this to `settings.json` in VS Code:

```json
{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },
}
```


Learn how to autofix backticks in JavasScript with ESLint and Prettier in VS Code.

Autofix Backticks with ESLint and Prettier in VS Code


**_The most important part of being a successful contributor on a distributed team is being equipped with the right tools and frameworks to help you transition into this new paradigm._**

## My Distributed Journey

Before working from home, I'd worked at a number of in-office jobs, the last of which was working on Software at Zappos. I had a 30 minute commute both ways to an open-office where I would sit down at my desk around 9AM, interact with peers almost all day, clock out around 5:30 or 6 and drive again for 30 minutes.

I started working from home in 2015 for Walmart Labs on a fully distributed team, building software for other teams to use. I transitioned into a job where I could wake up whenever I wanted (which didn't change), my commute was 15 seconds to a guest bedroom in our house, where no one else knew (nor did they care, it turned out) what my hours were, where no one knew if I decided to wear jammies and by the end of the day, I could be confident I didn't have to worry about sitting in traffic.

If you go into a change like this unprepared, it's easy to end up confused, feeling lost and even in a place where you think that this "remote thing" isn't for you. Despite that feeling, I challenge you to consider some tips and techniques I've found to help keep me grounded and help me do my best work and stay on task without also sacrificing my personal life.

**The tips that I've found to be most useful for my success and mental health are:**

- **Maintain your personal routines**
- **Connect virtually with co-workers as often as possible**
- **Start your week and your day with a concrete plan**
- **Create a dedicated workspace**
- **Stop Working When You Should Stop**

## Tip 1: Maintain Your Personal Routines

Most people think that their greatest temptation when working from home will be _not_ to work, however, I've found that my temptation is to _keep_ working all the time. The best way you can equip yourself for either temptation is to **create and maintain _personal_ routines and rituals that bookend when you want your day to start and end**.

Here's what my routine looks like:


- I wake up and make a coffee between 5:30-6AM.
- I write or pursue a hobby (reading or 3d printing) for an hour or two before my daughter wakes up.
- I make my daughter her breakfast.
- I walk the dogs.
- I take a shower and get dressed for work.
- I make another coffee, fill up my water bottle, give my family a kiss and head to my office.
- I take my mouse and keyboard out of their box, turn them on, turn on my monitor and...
- START WORK...and work until END WORK.
- I turn off my monitor, turn off my external mouse and keyboard and put them in a box. I always try to leave my desk "pristine".
- I go downstairs and have dinner with my family.
- I do bedtime routine with my daughter.
- I walk the dogs.

As you can see, my day is bookended with things I care about and _can't_ skip. Find the things that matter to you and bookend your day with those so that you know "it's time to start work" and "it's time to wrap up work".

**Note: You may think you don't already have rituals or routines, but things like "eating breakfast" and "showering" are good anchors for setting up rituals and routines to fill the time you may get back from no longer having a long commute. It's easy to think "I can sleep in now!" but the best thing you can do to be successful is to find ways to fill that newly acquired time. It may be spending time reading, exercising, finding a new hobby or if you have a family, spending time with them.**

## Tip 2: Connect Virtually with Co-Workers As Often As Possible

If you're a knowledge worker that's used to putting on a pair of headphones at the beginning of the day and hacking away on the computer by yourself, you may think work from home is going to give you that much more time to hack away at stuff. Now that you're work from home though, there are probably a lot of opportunities you once had in an office to collaborate or socialize that's now been stripped from you.

### Setup Pair Programming/Maker Sessions

Whatever you work on, you're probably not in a situation where you need to do it alone, so check in with a co-worker and ask them if you can schedule some time to pair on something. As a developer, I setup 4-5 sessions a week that last anywhere from 2-5 hours (it's important to be aware of when you or your pairing partner have hit a wall, this kind of work is mentally a lot more taxing than it is when you work alone). In most roles, there are opportunities to collaborate with a teammate or someone else in the organization on work that either of you are working on. This time doubles as an opportunity to interact with others outside of your neighbors/roommates/family.

### 10% Time

If your company gives you 10% time, this is a great time to try to connect with someone you may not normally cross paths with. It's also a great way to use that time to interact. 10% time is an opportunity for you to step outside of your daily role/routine/tasks and focus on things like writing, finding creative ways to use existing tools or building tools. You can also start a book club with some co-workers and use 10% time to have a weekly zoom where you talk about what you're reading. If you do this, a great way to keep it up is to make sure that you make it a ritual, by doing it the same time every week and putting it on people's calendars.

### Team Building

One of the things I've done that I've found to be a lot of fun, especially at companies where team building is encouraged, is to play boardgames online together over Zoom.

If you're not using it now, **talk to your company about investing in Zoom**.

## Tip 3: Start Your Week and Your Day with a Concrete Plan

When I worked in an office it was common for someone to catch me within the first 30 minutes of my day and ask me to help with something reactive. If you're in this boat, you'll find that Slack (or whatever tool your company uses for communication) is now the avenue people will use to "tap you on the shoulder". Working from home has a happy side effect of giving _you_ the ability to control your day.

The best way to control your day: plan at the end of the day every day.

At the end of the day every day, I write down what I _plan to do tomorrow_. I write it down with as much concrete detail as possible. If you work on a team that uses sprints or iterations or some version of long-term (weekly or bi-weekly planning), use your planned tasks to determine what you'll do tomorrow and do it in detail based on where you left off today. I usually write down one big task and 2-3 little tasks.

When you sit down at your desk (more on this coming up), _just do what you had planned_. Don't open Slack. Don't check your email. Don't open Twitter. **Open the tool you use for doing work and check off your tasks you had planned.**

Something really amazing happens when you plan your day and don't have an easy way for people to interrupt you: you find yourself done with everything you planned to do and sometimes more than you planned in half the time it would've taken you in the office.

## Tip 4: Create a Dedicated Workspace

Having a dedicated workspace has been critical in working from home. Every time my wife and I have moved, we've looked for a place that has a room that I can use as a dedicated office. As you start to work from home and find that you're using video conferencing more frequently or find that your roommates/family are now a part of your "daily office", you'll find that those little interruptions can add up in a big way.

If you have the luxury of an extra room that's not your bedroom or a main throughfair during the day, use that room as your workspace.

### Get a Good Desk

An adjustable desk and a comfy chair can go a long way.

I've had a few desks (I built my first two. It seemed cool at the time, but trust me, invest in a desk from people who specialize in this) but I've found the [Autonomous AI standing desk](https://www.autonomous.ai/standing-desks/smartdesk-2-home) or the [Husky adustable workbench](https://www.homedepot.com/p/Husky-52-in-Adjustable-Height-Workbench-Table-with-2-Drawers-in-White-HOLT5202BJ1/307723266?) to be two I enjoy using.

### Get a Good Chair

As for chairs, I have _only ever owned_ a [Herman Miller Sayl](https://www.hermanmiller.com/products/seating/office-chairs/sayl-chairs/). Don't be cheap on your chair. Your butt's in it most of the day and your back will thank you if you spend the time and money finding the right one for you.

### Anything is Better Than Your Bed

**Whatever you do, don't work from bed.**

If you have a family or roommates, you're probably going to be tempted to campout in your bedroom, but beware of this because of the challenge you'll face of feeling like life starts to blend together. If you absolutely have to use your bedroom, still get a desk and find a "shutdown ritual" that helps remind you that you are no longer at work, you are at life.

If you don't have the luxury of an extra room, try out getting a [screen for a desk](https://www.ikea.com/us/en/p/bekant-screen-for-desk-gray-70268811/), a [room divider](https://www.amazon.com/ACME-3-Panel-Wooden-Screen-Cherry/dp/B002WGJHB8/ref=sr_1_2?qid=1583705663&refinements=p_36%3A1253524011&s=home-garden&sr=1-2) or my favorite [an IKEA Kallax bookshelf that you can mount in the middle of a room](https://www.ikea.com/us/en/p/kallax-shelf-unit-white-30275861/).

## Tip 5: Stop Working When You Should Stop

As I mentioned in a previous tip: you're probably going to find that you actually get _a lot more done_ than you used to in an office. This probably means that you'll be done a lot earlier in your day than you used to. In the first weeks and months, be kind to yourself and "clock out" when you're done. I can't tell you how many days I have wasted by trying to squeeze out a little bit more in the name of "I'm supposed to be butt's in seat until 5PM" when my brain was mush and I'd already conquered the day early on.

This new way of working is _amazing_ and the dopamine hit you'll get from increased effectiveness is going to think you're actually being more efficient. Don't trick yourself into thinking that you are a robot and you have increased efficiency (humans are terrible at efficiency, our greatest strength is our ability to be effective).

## Work Well. Live Well. Don't Burn Out.

Long-term working from home (or remote...or distributed, whatever you call it) has been one of the greatest things to happen to me in terms of being an effective contributor, a balanced person and as someone who wants to enjoy the fruits of having family. I see my wife and daughter at the beginning of every day, at lunch and I have dinner and do bedtime routine with them every night. I am so grateful to have that time back to invest it in the people I care about.

If you're in a position where you're working from home, I'd encourage you, try out these tips, be "present" at work when you're at work, be present at home when you're not at work and experiment with different tips and techniques yourself to find the balance you want out of life.


Tips that I've found to help me be successful in my transition into remote work, working from home.

Tips For Being Successful at Working From Home Long-Term


I often find myself working in Docker containers interactively and when I do, the images I use don't usually have `dig` or `nslookup` installed. This is further complicated by the fact that those utilities aren't standalone packages, so I forget which collection of utilities they belong to. Here's how to install `dig` and `nslookup` with a few Linux flavored package managers.


## Install dig and nslookup on Ubuntu (Debian)

`dig` and `nslookup` are in `dnsutils` on Ubuntu (debian):

```shell
apt update && apt install dnsutils
```

## Install dig and nslookup on ArchLinux

`dig` and `nslookup` are in `bind-tools` on ArchLinux:

```shell
pacman -Syu && pacman -Sy dnsutils
```

## Install dig and nslookup on OpenSUSE

`dig` and `nslookup` are in `bind-tools` on OpenSUSE:

```shell
zypper update && zypper install dnsutils
```

## Install dig and nslookup on Alpine

`dig` and `nslookup` are in `bind-tools` on Alpine:

```shell
apk update && apk add bind-tools
```

## Verify Install

Now that they're installed you can run `dig -v` and `nslookup -v` to verify they're present.


Install dig and nslookup dependencies on Docker Containers


Today I started my journey into 3d printing! This post will be a rolling update (hopefully) of what I learn and what I'm making.

## Day 1 (2020-02-28 Fri)

- received a Monoprice Voxel
- setup Monoprice Voxel, connected it to the wifi
- connected to Monoprice Voxel through FlashPrintMP
- didn't realize I missed the instructions on loading the filament, almost ran a print without filament
- printed my first Benchy. Used auto-supports...turned out to be a lot of support (😅), but the print turned out really good for my first print!
- first print took somewhere around 2.5 hours, used around 3m of filament


My Journey in 3d Printing


In a Gartner article on [how peer feedback boosts employee performance](https://www.gartner.com/smarterwithgartner/peer-feedback-boosts-employee-performance/), Jessica Knight, research director at Gartner, said "High-quality peer input has become an essential part of effective performance feedback".

Every company I've worked for—Zappos, Walmart Labs and Webflow—in the past 8 years has incorporated peer feedback in the annual performance review (Webflow is the only one that doesn't tie compensation to this feedback).

For high performers and contributors who interact with others across an organization this can be a really great way to receive feedback, but the hidden superpower for people in these roles is that they have the ability to _give_ insightful feedback.

One of the most important changes I made to how I give feedback was **to start keeping notes for all of the peers I interact with through the year, then to reflect on and summarize those to write my peer feedback.**

## Step 1: Keep Notes Through the Year

Immediately after interacting with someone for the first time, I create a file in a folder in Dropbox called `people` with that person's name in it and use a text expander snippet to add a list item for that interaction. As an example, if I need help with a particular feature I don't know a lot about from a peer named "Jim Johns", I would created a file in Dropbox called `people/jim-johns.md` with the following:


```md
## Summary

## Notes

- **2020-02-21T13:04** I needed some help with the slider element feature and Jane said "Jim knows a lot about it". Jim was really helpful and the way he walked through the internals of the feature felt like we were exploring it together and he was letting me learn it and ask questions. I was really comfortable asking questions that felt silly because he often responded to my questions by first saying "great question!".
```

Some things to note about the above example:
- **I keep a timestamp (format: [year]-[month]-[day]T[hour]:[minute]).** I find the timestamp to be helpful because it helps me zoom out and if I have notes that are negative, I can look at my journal and see how _I_ was feeling that day. I find that including "I was having a hard day" also helps to show that sometimes "negative" feedback comes from where I was that day and give context that "maybe this was just me on that day" if I have any negative feedback.
- **I write about _what_ our interaction was about.** The what's important to me because it will help me recall the situation better when I'm summarizing and will likely help the person I'm giving feedback to recall specific situations.
- **I write how the interaction made me feel.** How I felt during/afterwards is important because it helps express what behaviors make me feel special. I generally only write about the behaviors that were positive (if I experienced behaviors that made me feel hurt or frustrated, I try to address that as soon as it happens. I've yet to have an interaction that ended negatively that repeated itself.)
- **I include the person who connected us**. I believe connectors are critical contributors at work. Whenever I include the connector, it makes it easier to search the whole directory for people's names if they request feedback. If I find Jane's name numerous times, I can add that to the summary that I keep for her.

## Step 2: Review and Summarize

Once I have 4-5 interactions, I'll try to summarize feedback into my `# Summary` section. I don't usually wait until peer feedback time to do this, but I usually do it when I can see that there are patterns of strengths, behaviors and qualities of a person that stand out. I also add a ⭐to a few of the interactions that I want to highlight to my feedback. I find specific examples as a good way to indicate I genuinely mean what I wrote in the summary.

## Step 3: Identify Opportunities for Growth

There are always opportunities for a person to grow. Sometimes they'll feel negative, but other times it'll be opportunities around skills/strengths an individual has that they want to refine/get better at. A really great way to share this feedback is to find any interactions where you caught a glimmer of something _stellar_ that you think that person has an opportunity to do more of that will also help them shine.

## Give Awesome Peer Feedback

For the past 4 years I have had to give anywhere between 12-15 peer reviews per cycle and this process of capturing over time and collating at review time has made giving feedback an enriching, stress-free experience!

This is also helpful for people who you haven't interacted with in a long time or don't interact with that frequently. This is a wonderful gift to those people because it shows you cared enough to be prepared and that you, someone they chose to request feedback from, took the time to reflect on your interactions with them.

I should also note that people have asked me for feedback outside of these cycles and when they do, it makes it a lot easier to give that feedback because I've already done the work to collect my thoughts!

[Thanks to David Hoang for inspiring me to write this post. His twitter post recommending managers keep a document on "what they've done" nudged me to write about the documents I keep to give awesome peer feedback.](https://twitter.com/davidhoang/status/1230886326561492994)


Many companies are incorporating peer feedback into performance reviews. Here's how I prepare to give awesome peer feedback.

How to Give Awesome Peer Feedback


Often times I find myself wanting to spin up an ephemeral Docker container. This is the structure of the command I'll use:

```shell
docker container run --rm --interactive --tty <IMAGE> <COMMAND>
```

An example if I want to spin up an [Alpine Linux](https://alpinelinux.org/) container:

```shell
docker container run --rm --interactive --tty alpine sh
```

Running this command will open a new shell inside of my existing terminal window with the ability to interact with the container.

This command can be run more tersely with the shorthand flags for `interactive` and `tty` as well:

```shell
docker container run --rm -it alpine sh
```

The composition of the command:

- `container run`: Runs a command in a new container
- `--rm`: Automatically removes the container when it exits (when I'm done, this is really nice so that Docker doesn't end up with a bunch of dangling Docker processes [you can experiment with removing this flag, running this command a few time and exiting and running `docker ps -a` to see what that means])
- `-interactive`: Keep STDIN open even if not attached
- `-tty`: Allocate a pseudo-TTY


Learn how to create an ad hoc interactive Docker container.

Create an ad hoc interactive Docker container


Sometimes when attempting to run a NodeJS server locally, you may see an error with:

```bash
Error: listen EADDRINUSE: address already i use 127.0.0.1:4567
```

To determine what's listening on this port (and potentially stop it), you can use a combination of the `lsof` and `ps` commands.

First, use `lsof -P -i :<PORT>`  replacing `<PORT>` with the port you want to check.

We use the `-P` with `lsof` since we likely don't need the mapping for the port to a name in the network files[^1].

Take the `PID` from `lsof` and run `ps <PID>` to find what's running on this port. If it's okay to kill it, run `kill <PID>` and try to re-run your command again.

[^1]: By using `lsof -P`, it ignores the host machines conversion of port numbers to port names for network files. For example, if we ran `lsof` without `-P`, the `NAME` column would contain services that run on those ports, such as port 4567 for `bcm-reporting` or 4568 for `tram`. If you're interested in seeing what service MacOS expects to be serving on a specific port, you can run the following command and replace `4567` with the port you're curious about: `cat /etc/services | grep " 4567/tcp"`.


Learn how to use the lsof and ps utilities to find running services when debugging EADDRINUSE in NodeJS logs.

Use lsof and ps to Find Running Services


Want to enable infinite scrollback in iTerm2? By default, iTerm2 has a scrollback buffer of 1000 lines. Since most of my day is doing builds and running watch tasks with lots of output, I want to have infinite scrollback.

1. In iTerm2, open **Settings**
2. Click on **Profiles**
3. Cick on **Terminal**
4. Under the **Scrollback Buffer** Heading, click the checkbox for **Unlimited scrollback**

![GIF of selecting unlimited scrollback](/img/iterm2-unlimited-scrollback.gif)


Learn how to setup iTerm2 to allow infinite (unlimited) scrollback

Setup iTerm2: Infinite Scrollback


I like to use [Emacs Bindings](https://caiorss.github.io/Emacs-Elisp-Programming/Keybindings.html) for navigating the terminal. The iTerm2 default for the Control key works just fine, but the Meta key puts junk in the terminal. To fix this, iTerm2 needs to know that "Left Option" needs to be treated as a Meta key.

1. Open **Settings**
2. Click on **Profile**
3. Click on **Keys**
4. In the bottom right corner, You'll see **Left Option**. Change that to **Esc+**


Learn how to setup a control key for more natural Emacs movements in iTerm2

Setup iTerm2: Better Movements with Emacs Bindings




It's been a while since I've posted a new thought/article here.

Some things that held me back:

- My process had too much friction
  - I was using `git`, a tool that's great for versioning but terrible for moving fast
  - using `git` meant I was limited to the devices I could publish on easily
- I waited for something to be perfect before publishing
- I was wanting to using Notion's API (it's been "coming soon" for almost a month now) to write and visualize my post statuses

What got me moving:

- I rethought my process
  - I decided to move everything to Dropbox
  - Moving to Dropbox means I can use a computer, phone or tablet to write
  - I don't have to think about committing changes, they're just there when I write them
- I just write stuff down
- I accepted that maybe every idea is better fledgling and shared instead of almost perfect and invisible

I plan on making a better signal for the status for an article/blog post (what do I even call these?) so that others know how well-thought out a piece of content is, but for now, the goal is just to write and let the world see it.


The reason I've decided to write content in Dropbox instead of keeping it in version control.

Back to Writing Content in Dropbox


If you want to replace a pattern multiple times with the JavaScript `replace` method, you have to use a regular expression with the global flag.

Replacing **the first found instance** is achieved with the following:

```js
"this is a string".replace(" ", "-");
```

Result:

```
"this-is a string"
```

When calling the `replace` method with a string as the first argument, it will only replace the first instance with the replace value (in this case `"-"`).

Replacing **all found instances** is achieved with a regular expression and global flag:

```js
"this is a string".replace(/ /g, "-");
```

Result:

```
"this-is-a-string"
```

When the `replace` method with a regular expression and the global flag, it will replace all instances with the replace value.


Replace Multiple Instances of Pattern in JavaScript


Friction is a force that affects our ability to do things. 

If you want to add good habits, reduce friction that makes those habits hard to do.

If you want to remove bad habits, create friction that makes those habits less easy to do. 

Do you spend to much money online? Delete your saved credit cards and keep your wallet or purse far out of reach. 

Do you spend to much time surfing social media? Delete your apps and only log on through an Incognito window for 10 minutes, then close the window.

Friction is a powerful force to helping us shape the way we live our lives. If it's used to intentionally design habits, it becomes a leverage point to become the person you want to be. 

Friction: A Secret Tool for Successful Habits




> "...so use good tools, the right tools, in a well-lit space." - Zen & The Art of Motorcycle Maintenance

I think the way the Technology Industry views tools for visualizing what they're producing is broken. Here's why:

In my experience it's not unique that in a company there's the power struggle of "visualizing work".

- **teams** want to visualize it in a way that helps them increase flow, reduce blockage and produces the most impact.
- **"Upper Management"** wants to know what's getting done.
- **Project Managers** want to know status updates on other team's boards that might affect them or their own team's progress.
- **Product Managers** want to know when they can let customers know about features that exist.

These conflicting priorities are often the reason there's a struggle over "which tool do we use?" and the reason a lot of engineers get frustrated (because let's face it, _often_ they're the ones who have the least amount of influence on org-wide tool decisions).

At first I thought this wasn't really a tooling problem, it was really more of an issue of people figuring out as an Individual Contributor: **How do I visualize work in a way that works best for me?**

As I thought about it more, though, I thought about tools like Trello that was really static, or GitHub projects that lets you filter but has really limited functionality or tools that have gantt charts or swimlanes...all of the tools I could think of had very static underlying data types. [^1]

I realized that it's really an issue of shared, common underlying data. We should be able to visualize (and tag it) data differently and all that really mattered for all of the stakeholders to be satisfied was that there be some minimal, common constraint fields (ie, maybe you only need two fields to be shared across each role: the task name and the "status").

Having only two common fields that are _required_ gives individuals, teams and organizations the ability to add data types that help them visualize work and be effective.

Other individuals, teams and organizations _can_ use the optional data types, but they don't have to (or even care that they exist).

By allowing each funnel of the org, all the way to the individual to add _and_ visualize data types that work for them, they can create a dashboard that helps them with their desired workflow/way to visualize data that doesn't also undermine other people's way to do the same.

**So what if the data about the was pivotable, so the state of the world could look like this:**

- The Company could have a simple list view of what's been completed this week across the whole company.
- The Engineering Org has a high-level "template" Kanban board to visualize the flow of work.
- My team can have a dashboard that has the same data, but we could pivot based on things like "tool" or "priority" or "impact".
- As an Individual Contributor, I can have a Kanban board that helped me visualize the same work in a way that helps me be effective in my day-to-day tasks.

I want to see a tool that throws static views out the window and thinks deeply about creating open, flexible ways for data to be viewed as individuals zoom in and out through their organizations.

[^1]: I think there are some companies (I'm looking at you [Airtable](https://airtable.com) and [Notion](https://www.notion.so) 😍) that are moving this vision in the direction I want to see it.


On Team Productivity, Tools & Flexible Data




When attempting to run a Docker container with `docker container run ...`, you may see this error:

```shell
Bind for 0.0.0.0:8000 failed: port is already allocated
```

Whenever you see this error, it means that the container is unable to bind the container's exposed port to the port on the host machine.

## Solution

This is an easy fix with two steps:

1. run `lsof -i :8000` (replace `8000` with the port that's allocated in your error).

   ```shell
   lsof -i :8000
   COMMAND    PID         USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
   com.docke 1596 chaseadamsio   20u  IPv4 0x677313baaeffcfd7      0t0  TCP *:irdmi (LISTEN)
   com.docke 1596 chaseadamsio   21u  IPv6 0x677313ba9b203357      0t0  TCP localhost:irdmi (LISTEN)
   ```

   If the output has `COMMAND` of `com.docker` (as above), proceed to step 2.

   ```shell
   lsof -i :8000
   COMMAND   PID         USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
   node    46205 chaseadamsio   19u  IPv4 0x677313ba9d523357      0t0  TCP localhost:irdmi (LISTEN)
   ```

   If the output has `COMMAND` that's anything else, make a note of the `PID` for the process serving on that port and proceed to step 3.

2. run `docker ps` to get a list of running containers.

   ```shell
    docker ps
    CONTAINER ID        IMAGE                  COMMAND                   CREATED             STATUS                            PORTS                    NAMES
    20c6837d446e        crccheck/hello-world   "/bin/sh -c 'trap \"e…"   4 seconds ago       Up 3 seconds (health: starting)   0.0.0.0:8000->8000/tcp   web-test
   ```

   Under `PORT` you'll see a mapping of the `HOST PORT` (0.0.0.0:8000) -> `CONTAINER PORT` (8000/tcp). The port from your failure will be on one of the containers. Make a note of the `CONTAINER ID` and run `docker stop <CONTAINER ID>`. If you no longer need the container, run `docker rm <CONTAINER ID>` to clean it up.

3. With the `PID` from step 1 in hand, run `ps <PID>` to make sure the process serving on that port is okay to kill.

   If it is, first, check any open Terminal windows to make sure the process isn't running as a part of some other script. If it is, `ctrl-c` to send a `SIGINT`. If it isn't running in a Terminal window and you're confident that it's okay to kill, run `kill <PID>`. If you're not sure what it is, restart your host machine and see if it restarts. If the process restarts on machine booting, consider running your container on a different port.

After you've gone through the steps above, when you attempt to run `docker container run...` you should make it a little further through starting up your container.


How to fix a failed Docker port allocation error.

Fix Docker Error: Failed Port Allocation


## Error

```shell
Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/entrypoint.sh\": permission denied": unknown
```

## Solution

If you're using GitHub Actions, you'll get this when you've forgotten to set the `entrypoint.sh` as an executable. You can fix this error by running `chmod +x </path/to/>entrypoint.sh` (replacing `</path/to>` with the directory path from the proectx root) and committing it.

## When Have I see this?

When I'm creating a GitHub Action and I forget to set the `entrypoint.sh` as an executable, I'll see this error when the Actions container runs.


Fix Docker Error: GitHub Actions Entrypoint Executable Error




A cheatsheet for the pattern to use to match certain [paths for a GitHub CODEOWNERS file](https://help.github.com/en/articles/about-code-owners).

The cheatsheet uses `<ROOT>/.buildkite` as an example. `<ROOT>` in the "I want to match" section is the `git` root of your project.

| I want to match...                             | Pattern              |
| :--------------------------------------------- | :------------------- |
| all files in `<ROOT>/.buildkite`               | `.buildkite/**`      |
| `.buildkite` directory anywhere in the project | `**/.buildkite`      |
| everything _but_ `<ROOT>/.buildkite`           | `!.buildkite`        |
| `.buildkite` anywhere in `test`                | `test/**/.buildkite` |


A cheatsheet for GitHub CODEOWNERS pattern for matching a directory and all of its contents

GitHub CODEOWNERS Directory Pattern Match Cheatsheet


## Error

```shell
standard_init_linux.go:207: exec user process caused "no such file or directory"
```

## Solution

Make sure all of the scripts that are being run in the container (this is especially true for `entrypoint.sh`) are using a process that exists.

If it is an `entrypoint.sh`, you probably need to make sure to do this:

```diff
- #!/bin/bash
+ #!/bin/sh
```

If you need `bash` features, use an Alpine distro with `bash` already installed or install it in the `Dockerfile`.

### When Do I See It Most?

When I'm using Docker and the `Dockerfile` is `alpine` linux, I sometimes forget that it doesn't have `bash` installed and accidentally add the sha-bang for `#!/bin/bash`. 99.9% of the time that's okay, so I change it to `#!/bin/sh`.

This is especially true when I'm making a GitHub Action.


Fix Docker Error: exec user process caused "no such file or directory"




In the past, when I needed to share a specific line in a Markdown file from GitHub, I'd usually share a link to the Markdown file or a link to the fragment for the header closest to what I wanted to share and say, "look for X".

In this short GitHub protip, I'll share the hack I discovered that allows you to share specific lines from a Markdown file.

I'm using Hashicorps HCL repo as an example, but the concepts work with any Markdown file on GitHub. We're going to be sharing specific lines about how to write comments in HCL.

## Sharing a line with GitHub UI

First, open a GitHub project and find the `README.md` [^1]. (If you don't have one handy, feel free to follow along [in the hashicorp/HCL repo](https://github.com/hashicorp/hcl)).

You can see that the `README.md` is rendered as Markdown instead of source. In the file viewer, find and click `README.md`. The view this takes us to is _also_ rendered as Markdown:

![GitHub rendered README.md](/img/gh-md-readme-view.png)

For our example, the part of the Markdown file that we want to share is "Single line comments start with # or //" and as you can see, there's not a way to do that from this view.

**To select a specific line, we're going to use the Blame view.** Click the **Blame** button in the top right corner of the content view:

![GitHub button for Blame for README.md](/img/gh-md-blame.png)

The new view that we see has the source of the Markdown file, along with the line numbers! Now we can look for "Single line comments start with # or //" and to the left, click the line number (54 as of writing).

You should notice that the URL Location has changed to include a fragment at the end of it:

```
https://github.com/hashicorp/hcl/blame/master/README.md#L54
```

When you share this link, it will take the recipient to this page, at this line number and add highlighting to the line you referenced.

## Sharing multiple lines with GitHub UI

If you wanted to share _all_ of the lines regarding comments instead of just the single line comment, you can do that too! Click the line number you want to start on (again, line 54) and shift+click the line you want to end on (in this case, line 58).

This adds a URL fragment that looks like this:

```
https://github.com/hashicorp/hcl/blame/master/README.md#L54-L58
```

Now when the recipient follows this link it will take them to the file, go to line 54 and highlight lines 54-58.

## Conclusion

This is currently the best way I know of to share specific lines in a Markdown file with GitHub. Hopefully they'll be listening and push out the change I've shared below so this post can become obselete!

## For GitHub, if you're listening...

You've already nailed this UI with GitHub Actions, so if you're looking for small easy wins, consider applying the switcher for rendered blob and source blob:

![GitHub rendered README.md](/img/gh-md-better-buttons.png)

[^1]: This works for all markdown files, but this is the one that is most prolific/consistent.


Learn the trick I use to share a Markdown file with GitHub

Share Specific Lines in a Markdown file with GitHub




I consider Monday the start of my week, so I like to make sure my Calendars are setup properly.

## Google Calendar

- Open you Google Calendar in your browser
- Click the **Gear** in the top bar
- Click settings
- Scroll to **"View options"**
- In **Start week on** dropdown menu, change "Sunday" to "Monday"

## Apple Calendar (Mac)

- Open the Calendar app on your Mac
- Click **Calendar** in the menu bar
- Click **Preferences**
- In **General**, find **Start week on:** and change it from "Sunday" to "Monday"


Learn how to setup Google Calendar so that the week starts on Monday

Start Week on Monday in Google Calendar and Apple Calendar



If you're a voracious reader, it's worth creating a framework for choosing a format for reading books. Here's the framework I use, feel free to copy/pasta and change as much as you'd like!

## Format Options

There are 3 formats:

- Paperback/Hardcover (physical/visual)
- eBook (digital/visual)
- Audio Book (digital/auditory)

I've found that it's best to pick each format based on three criteria:

- the genre of the book
- planned level of focus
- likelihood of taking notes/highlighting

## Paperback/Hardcover Books (Physical)

- **Genre:** technical (specifically w/ code samples/diagrams) in nature, "evergreen" personal growth, "essentials list" books
- **Planned Focus:** Deep
- **Likelihood of Taking Notes/Highlighting:** Strong
- **Pros:** easy highlighting, easy bookmarking, consistent formatting, easy sharing
- **Cons:** physical nature makes it harder to carry more than a few and requires physical storage space

## eBook

- **Genre:** personal growth, business, fiction
- **Planned Focus:** Deep to Shallow
- **Likelihood of Taking Notes/Highlighting:** Strong
- **Pros:** portable, scalable, highlighting saved online, instant gratification on purchase
- **Cons:** dependency on device battery life, limited consistent formatting, harder to search than paperback

**Note:** It's important to address why I don't like to read technical books as eBooks:

**code samples and diagrams are often crafted with the physical copy of a book in mind, not eBooks.** 

If you've ever read a technical book on an eBook, you've likely found that diagrams don't scale properly (often even bleeding off the page or being so incredibly small you need a reading loop to make sense of it) and that code samples don't fit on the page properly or worse extend off the page and can't be read.

## Audio Books

- **Genre:** fiction, non-fiction requiring no action
- **Planned Focus:** Shallow
- **Likelihood of Taking Notes/Highlighting:** Unlikely
- **Pros:** portable, scalable, passive, multi-taskable
- **Cons:** dependency on device battery life, highlighting non-existent or kludgy, hard to focus, impossible to "search" for keywords or quotes

Almost exclusively fiction. The only time I generally listen to audio books is when I'm doing something else that requires attention but isn't deep work. For example:

- driving long distances (anything more than 20 minutes)
- walking the dogs
- doing yard work
- grocery shopping

I can listen to a fiction and pay attention while also "fully" tending to the other task I'm doing without feeling the need to concentrate or worse, hearing something I want to highlight or write down because it resonated with me.

**I hope that this approach has at the very least given you a sense of how to pick formats of books yourself and at best given you a framework to figure your out your own approach. Happy reading!**


A Pragmatic Approach To Choosing A Format For Reading




Earlier I shared how I [use Netlify's Deploy Context to safely write drafts in GatsbyJS that never land in production](/2019/gatsby-drafts).

Now I want to share another use of Netlify's Deploy Context to only include Google Analytics on a GatsbyJS site when it's in production. Using this solution guarantees Google Analytics tracking won't ever be included in a non-production preview environment without tribal knowledeg workarounds or hacks.

**This solution requires that 1) you're building your site with GatsbyJS and 2) you're using Netlify for build/deploy/hosting.**

It's a simple two step process:

- Install the Google Analytics GatsbyJS plugin
- Add logic to `gatsby-config.js` to only include the plugin in production

## Add Google Analytics to GatsbyJS

With all things GatsbyJS, there's a [plugin for Google Analytics](https://www.gatsbyjs.org/packages/gatsby-plugin-google-analytics) and it's easy to setup.

From within your project, install `gatsby-plugin-google-analytics` (the code below is using `yarn`. You can install it with `npm install --save` as well):

```shell
$ yarn add gatsby-plugin-google-analytics
```

Now, if you open your `package.json`, you should see it in your list of `dependencies`.

## Configure GatsbyJS to use Netlify's Deploy Context

Since we want our analytics to be as accurate as possible, we're going to check that Netlify's deploy context is `production` so the Google Analytics plugin is only included in production. (By default, this plugin checks for `NODE_ENV === production`, so it won't include Analytics during `gatsby develop` but `gatsby build` sets `NODE_ENV` to `production`, so anything that's built and served will include it)

In the `gatsby-config.js`, create an object called `cfg` and set the file's `module.exports` to that object:

```js
const cfg = {
  plugins: []
  /* the rest of your config */
};

module.exports = cfg;
```

Now, between the `cfg` definition and `module.exports`, add a condition for when the `CONTEXT` is `production` that will creat a configuration for the Google Analytics plugin, followed by pushing the configuration to `cfg.plugins`.

```js
// cfg = {...}

if (process.env.CONTEXT === "production") {
  const googleAnalyticsCfg = {
    resolve: "gatsby-plugin-google-analytics",
    options: {
      trackingId: "UA-XXXXXXXXX-X" // <- your tracking ID
    }
  };
  cfg.plugins.push(googleAnalyticsCfg);
}

// modules.exports = cfg;
```

## Test Google Analytics

To test, we're going to...

- Install the ["Block Yourself from Analytics" extension for Chrome](https://chrome.google.com/webstore/detail/block-yourself-from-analy/fadgflmigmogfionelcpalhohefbnehm?hl=en)
- Create a pull request to the repo. Open the Netlify deploy preview and verify that the extension shows that there are no analytics coming through.
- Merge the PR and check that your production URL is still serving Google Analytics.

Now you know how to use Netlify's Deploy Context to bend GatsbyJS to your will (and keep your Google Analytics stats clean)!

## Footnotes

- You can use Netlify's deploy context to follow the same pattern for only including Google Analytics with Hugo and likely other platforms.
- This isn't exclusive to Netlify, you can use this pattern anywhere that has preview URLs (GitHub for example) and a way to determine the context of the environment.


Learn how to use Netlify's Deploy Context to only include Google Analytics in production in your GatsbyJS site.

Production Only Google Analytics in GatsbyJS with Netlify


Learn all the ways to disable ESLint rules with the comment syntax.

## Ignore ESLint rules for file

In general, using file level `eslint-disable` is an indicator that the code needs to be fixed rather than ignored, but there are definitely times when using `eslint-disable` at the file level is necessary.

### Ignore all rules for a file

Syntax: `/* eslint-disable */`

Example:

```js
/* eslint-disable */
var myObj = {};
```

### Ignore single rule for a file

Syntax: `/* eslint-disable <rule> */`

Example (using `no-unused-vars`):

```js
/* eslint-disable no-unused-vars */
var myObj = {};
```

### Ignore multiple ESLint rules for a file

Syntax: `/* eslint-disable <rule>, <rule>, <etc> */`

Example (using `no-unused-vars` and `no-shadow`):

```js
/* eslint-disable no-unused-vars, no-shadow */
var myObj = { old: "thing" };

function myFunc() {
  var myObj = { new: "thing" };
}
```

## Ignore ESLint rules in a block of code

Sometimes you may want to ignore a rule inside of a block of code and re-enable outside of it.

### Ignore all rules in a block of code

Syntax: `/* eslint-disable */ /* ...block of code... */ /* eslint-enable */`

Example:

```js
var myObj = { old: "thing" };

/* eslint-disable */
function myFunc() {
  var myObj = { new: "thing" };
}

function myFunc2() {
  var myObj = { new: "thing" };
}
/* eslint-enable */
```

### Ignore single rule in a block of code

Syntax: `/* eslint-disable <rule> */ /* ...block of code... */ /* eslint-enable <rule> */`

Example (using `no-shadow`):

```js
var myObj = { old: "thing" };

/* eslint-disable no-shadow */
function myFunc() {
  var myObj = { new: "thing" };
}

function myFunc2() {
  var myObj = { new: "thing" };
}
/* eslint-enable no-shadow */
```

### Ignore multiple rules in a block of code

Syntax: `/* eslint-disable <rule>, <rule>, <etc> */ /* ...block of code... */ /* eslint-enable <rule>, <rule>, <etc> */`

Example (using `no-shadow` and `no-unused-vars`):

```js
var myObj = { old: "thing" };

/* eslint-disable no-shadow, no-unused-vars */
function myFunc() {
  var myObj = { new: "thing" };
}

function myFunc2() {
  var myObj = { new: "thing" };
}
/* eslint-enable no-shadow, no-unused-vars */
```

## Ignore ESLint rules for current line

This is useful for ignoring rules for a single line. I find it useful because if code gets moved around, it guarantees that the `eslint-disable` comment is preserved with the code it's meant for.

### Ignore all rules for current line

Syntax: `// eslint-disable-line`

Example:

```js
var myObj = {}; // eslint-disable-line
```

### Ignore single rule for current line

Syntax: `// eslint-disable-line <rule>`

Example (using `no-var`):

```js
var myObj = {}; // eslint-disable-line no-var
```

### Ignore multiple rules for current line

Syntax: `// eslint-disable-line <rule>, <rule>, <etc>`

Example (using `no-var` and `no-unused-vars`):

```js
var myObj = {}; //eslint-disable-line no-var, no-unused-vars
```

## Ignore ESLint rules for next line

This is useful for when you have a declaration/definition that spans multiple lines. Some examples of this may be multi-line imports or destructuring, multi-line function definitions or multi-line object definitions.

### Ignore all rules for next line

Syntax: `// eslint-disable-next-line`

Example:

```js
// eslint-disable-next-line
module.exports = () => {
  /* lots of code here, all covered under the eslint-disable comment */
};
```

### Ignore single rule for next line

Syntax: `// eslint-disable-next-line <rule>`

Example (using `no-unused-vars`):

```js
// eslint-disable-next-line no-unused-vars
module.exports = () => {
  /* lots of code here, all covered under the eslint-disable comment */
};
```

### Ignore multiple rules for next line

Syntax: `// eslint-disable-next-line <rule>, <rule>, <etc>`

Example (using `no-var` and `no-unused-vars`):

```js
// eslint-disable-next-line no-var, no-unused-vars
module.exports = () => {
  var myObj = {};
  /* lots of code here, all covered under the eslint-disable comment */
};
```


Learn how to disable ESLint rules with the comment syntax

Disable ESLint Rules with Comment Syntax




Have you ever opened a file in VS Code that doesn't have a standard language extension or filename and noticed that the syntax highlighting and other language mode features is missing?

As a trivial example, you might have a `Brewfile` and want it to have syntax highlighting. Despite being Ruby, without a `.rb` extension syntax highlighting won't be applied because VS Code doesn't have a way to determine the `Brewfile` is Ruby. Another example is an AlfredApp Theme file, it has the naming convention of `*.alfredappearance` but is JSON, so syntax highligthing won't be applied to this file either.

VS Code makes it easy to associate a file with a language mode by adding `files.associations` to your `settings.json`. To demonstrate, here's what a configuration for the above examples would look like:

```json
{
  "files.associations": {
    "Brewfile": "ruby",
    "*.alfredappearance": "json"
  }
}
```

`files.associations` is an object where each key is a filename or a pattern (glob) of the filename with the value set to the language mode that it represents.

Now whenever you open a `Brewfile` or an Alfred theme that ends in `.alfredappearance`, the file will get the correct syntax highlighting and all the features that are available to the language mode!

In the examples I've given for `files.associations`, syntax highlighting was the only feature highlighted, but setting a file to a language mode gives it access to any functionality that's associated with that language.

![Gif of adding Syntax Highlighting to Files Without Extensions in VS Code](https://user-images.githubusercontent.com/1024544/52688212-4f697300-2f0a-11e9-8621-5763dd263082.gif)


Learn how to setup syntax highlighting and other language modes with file associations

Apply Language Modes to Files With Non-Standard Filenames in VS Code




There are a few solutions out there for keeping drafts in GatsbyJS, but none achieved what I wanted. The ones I've found required `graphql` to do the heavy lifting to filter out drafts which meant a lot of filtering out anything where drafts was false. **If you don't care about the justification, you can skip to [the code for how I write drafts in GatsbyJS](/gatsby-drafts/#how-i-write-drafts-in-gatsby).**

## Justification

These were the specifications that led me to the solution I use:

- Easy to infer which articles are in draft state.
- Single author not using Netlify CMS (works for multiple authors as well, but not required for me).
- The production build/runtime of my site should be totally unaware of drafts.

### Finding Drafts is Clear

I'm a huge advocate for reducing the friction of finding content that has a state of "Work in Progress". Having a separate directory explicitly for drafts helps me do that.

One of the downsides of using `drafts` in frontmatter is that you usually have to _search_ through the frontmatter with a tool that can tell if a file is a draft (grep, ripgrep, etc) _or_ keep the state in your brain (which is a bad use of a brain).

### Single Author Hosting Content on Dropbox

I'm the only author on my Gatsby sites and use Dropbox to host my content. I think this solution could easily work for multiple authors using git as the "backend" (the way you might use Netlify CMS), but I haven't tried that with this solution so mileage may vary.

I also use Dropbox to _host_ my content and builds are done as a result of changes to files. Having a separate drafts folder allows me to write content without triggering unnecessary Dropbox/Netlify hooks.

### Production Safety

I don't want to have a bunch of drafts filters in my GraphQL. I can't think of a compelling reason for GraphQL to filter drafts when I know that I don't want drafts in production). Having a separate drafts folder reduces a lot of the complexity (and potential bugs) that would come with using GraphQL to do the same filtering.

## How I Write Drafts in Gatsby

Now to the fun part: configuring Gatsby!

I have two content folders in my src directory:

- `content` - the content ready for production
- `drafts` - the content that I'm still working on

There are 3 "stages" of the content lifecycle:

| Stage                  | `content` present   | `drafts` present    |
| ---------------------- | ------------------- | ------------------- |
| Local Development      | ✅ (symlink)         | ✅ (symlink)         |
| Non-Production Netlify | ✅ (pulled at build) | ✅ (pulled at build) |
| Production Netlify     | ✅ (pulled at build) | ❌                   |

The goal is to have a `gatsby-source-filesystem` for `drafts` in any non-production stage and to not even worry about it in production.

### Setup for Gatsby Config

In my `gatsby-config.js` I have a Gatsby config object (rather than setting the object directly on `module.exports`):

```js
const cfg = {
  /* ...my default configuration */
};

module.exports = cfg;
```

Then do a conditional check for the environment where Gatsby is building the site (based on Netlify's deploy contexts):

```js
if (process.env.CONTEXT !== "production") {
  const draftsCfg = {
    resolve: `gatsby-source-filesystem`,
    options: {
      name: `drafts`,
      path: `${__dirname}/src/drafts`
    }
  };
  cfg.plugins.push(draftsCfg);
}
```

If `process.env.CONTEXT` isn't `production`, provide `drafts` as a filesystem source.

- `draftsCfg` is a `gatsby-source-filesystem` plugin configuration object, where the `sourceInstanceName` of the content is `drafts` and the path to the content is the `src/drafts` directory inside  of the project root.

Next we push the `draftsCfg` into the `plugins` object that Gatsby will use when it builds the site.

Now whenever Gatsby is run locally or in a non-production branch (because Netlify's preview branches are AWESOME!) and the build in the production environment is totally unaware of the fact that we have a `drafts` folder.

### Caveat

A lot of this looks like it's dependent on using Netlify, but every hosting provider worth its salt provides a way to set environment variables. Netlify does it out of the box, so it was super convenient to hook into that, but it's not a show stopper if you're using another hosting provider.

Big ❤️ to GatsbyJS and Netlify for making this process super easy!


Learn an alternative solution for writing drafts with GatsbyJS

Writing Drafts in GatsbyJS




I spend a lot of time in the Terminal typing bash commands, but it never fails that I want to re-run a command or **most** of a command and can't remember what it is (anyone else forget how to spell the word am...end when typing `git commit --amend -m "change my commit message"`?! (yeah, I always add an extra "m" the first time))

If you use the reverse search functionality, you've probably used your history to do this. The only way to determine if that command was maybe the right command is by running it and seeing it fail or succeed.

The best way to keep your bash `history` from potentially giving you bad info is to delete the command from your history after you've done it wrong. As an example, here are the last 4 items from my bash history:

```bash
$ history 4
 4449  ls
 4450  mkdire foo
 4451  mkdir foo
 4452  history 4
```

`history` gives you the entry number and the command that was run. Passing `history` a 4 means I only want the last 4 commands that were executed (it'll include itself in this list because it was executed).

I want to remove `mkdire foo` because `mkdire` should be `mkdir` and I don't want to ever accidentally re-run it with reverse search. You can pass `-d` and the entry number to delete the entry:

```bash
$ history -d 4450
```

Now if I run `history 4` again, I get the following results:

```bash
$ history 4
 4450  mkdir foo
 4451  history 3
 4452  history -d 4450
 4453  history 4
```

Now when I do a reverse search, I won't find that result again! 🎉


Delete Command from Bash History




I've been using VS Code for the past year in my development workflow and recently started recording more screencasts and demos.

I've also started experimenting with tweaking settings to find VS Code settings to make the videos and demos I create clear and easy to follow. **The goal is to reduce the visual clutter as much as possible so that the code I'm showing (or writing or demoing) can be shown without any distraction.**

Below are the settings I use when recording videos. I recommend them to anyone presenting code through video or live demos.

## Screenshots

Since this brief post is about the visual changes of VS Code, here are some screenshots showing the difference. In these screenshots I've used a simple Go file from my `dotfiles`.

### Before Changing Settings

![VS Code preview before adding settings for better screencasts and demos](/img/before-vs-code-sharing-settings.png)

### After Changing Settings (with Terminal)

![VS Code preview after adding settings (with terminal open) for better screencasts and demos](/img/after-vs-code-sharing-settings-with-terminal.png)

### After Changing Settings

![VS Code preview after adding settings (without terminal open) for better screencasts and demos](/img/after-vs-code-sharing-settings-without-terminal.png)

## VS Code Settings

### Non-JSON Settings

#### Disable the Sidebar

Unless you're exploring code for the sake of showing hierarchy, in my opinion, there's no good reason for having the Sidebar open, so I use **⌘ + B** to hide it.

### JSON Settings

To achieve the same effects, add the following key/value pairs to your `settings.json` file (You can access this file by opening the Command Palette (⌘+Shift+P) and typing **Preferences: Open Keyboard Shortcuts (JSON)**):

```json
{
  "workbench.activityBar.visible": false,
  "window.zoomLevel": 2,
  "workbench.statusBar.visible": false,
  "editor.lineNumbers": "off",
  "gitlens.currentLine.enabled": false,
  "scm.diffDecorations": "none",
  "editor.minimap.enabled": false
}
```

Below is a brief explanation for each setting and why I've chosen it.

### Disable Activity Bar

**setting:** `"workbench.activityBar.visible": false,`

This setting disables the **VS Code Activity Bar**. It's a very prominent visual feature of VS Code and can be very distracting.

#### Exceptions

- demoing a full workflow

### Zoom Level

**setting:** `"window.zoomLevel": 2,`

Increasing the size of your code is by far the number one request I hear _during_ presentations. A **Zoom Level** of 2 (based on a **Font Size** of 12) is a good setting to make sure that what you're presenting is visible for attendees/viewers. It's also not so big that it's unmanageable for navigating when you're presenting. One thing to remember is that code should probably adhere to not extending past the 80 character length per line.

### Disable Status Bar

**setting:** `"workbench.statusBar.visible": false,`

The VS Code Status Bar (the bar that extends across the bottom of the window. It contains information about git, where you are in the file, the type of file, etc) is useful for development, but can be very distracting because it's _constantly_ changing if you're typing or navigating. The information it contains is rarely useful for presentation for you or for your audience.

### Disable Diff Decorations

**setting:** `"scm.diffDecorations": "none",`

When working out of a project under version control, you'll see blue, green and a red arrow in the "gutter". This can be distracting when typing, so disabling it allows you to focus on the code, especially if you're writing code as you present.

### Disable Line Numbers

**setting:** `"editor.lineNumbers": "off",`

Line numbers are rarely useful during demos and any reference to a line number can be replaced by highlighting with a cursor as you present the information.

### Disable Minimap

**setting:** `"editor.minimap.enabled": false`

The minimap doesn't add any contextual value other than where you are in a large file, which is very rarely relevant (if you need to know where you are, consider re-enabling line numbers).

### Disable Current Line GitLens

**setting:** `"gitlens.currentLine.enabled": false,`

Knowing who changed what and when for the current line doesn't add a lot of value to a demo.

#### Exceptions

- When you want to show how to investigate changes for context

### Disable Indent Guides

**setting:** `"editor.renderIndentGuides": false`

## A Final Note on Settings

These are the settings I've found work for me, but "works for me" is purely anecdotal! I recommend trying out the configuration I suggested and changing your settings until you find what works for you. If you find something you think would be useful for me, please let me know on [twitter at @chaseadamsio](https://twitter.com/chaseadamsio).


Settings that I have found are best for optimizing VS Code for sharing code through screencasts and demos

VS Code Settings for Sharing Better Screencasts & Demos




I've been working with Flow a lot since joining Webflow and one of the things that I constantly miss is the `// $FlowFixMe` comments. I decided to highlight `// $FlowFixMe` comments in red so they stood out.

Emacs makes it trivial to add configuration to highlight specific lines based on certain criteria. In `init.el` or any file that you load configuration through, you can add the following:

```lisp
  (defface flow-fix-me-comment '((t (:foreground "#ff0000"))) "Red")

  (font-lock-add-keywords
   'js-mode '(("// $FlowFixMe" 0 'flow-fix-me-comment t)))
```

Breaking it down:

- `defface` allows us to declare a customizable `FACE` (you can think of `FACE` as a style). We're naming it `flow-fix-me-comment`
- `font-lock-add-keywords` allows us to highlight a mode based on a specific keyword.
- `'js-mode` is the mode we want to highlight on.
- `"// $FlowFixMe"` is the term we want to use as the criteria for highlighting.
- If the term matches the line, apply the `flow-fix-me-comment` `FACE`.

Make sure to `eval-buffer` on the snippet, reload your config or restart Emacs to see the changes take place.

The end result will look like this:

![Use Emacs to highlight $FlowFixMe in Javascript](/img/flowfixme.png)

If you're using Emacs to develop for JavaScript and using Flow in your projects, this is a great way to make sure you don't get burnt by any `$FlowFixMe` comments during development!


Learn how to setup conditional highlighting for Emacs by writing emacs-lisp to highlight $FlowFixMe

Emacs: Highlight $FlowFixMe comments in JavaScript




**Today I'm joining the Frontend Infrastructure team at [Webflow](https://webflow.com/about)!** I'll be contributing to the underlying frontend code/APIs that will make contributing to Webflow more seamless for the whole Frontend team.

Webflow is an incredible platform that empowers designers, creative professionals and entrepreneurs to create and publish for the web. It significantly reduces the barrier for creators who have a vision for a website to create a website without having to learn to code and still have the full power of building for the web. Unlike other sites/frameworks, rather than forcing creatores into using stock templates that have some customization—it provides a intuitive UI to let creators build and publish a site on par with some of the best sites in production (Webflow has put in a significant amount of work to make their users successful through the [Webflow University](https://university.webflow.com/)).

## What I'm Excited About

- Webflow's Core Behaviors
- Building Things For People Who Build Things
- Margin

### Webflow's Core Behaviors

Webflow has 7 Core Behaviors (They're different from values, because behaviors are _how we act_, not just what we believe).

The Core Behaviors are:

- Start with Customers
- Practice Extraordinary Kindness
- Be Radically Candid
- Move Intentionally Fast (changed 2020/03/12)
- Just Fix It (Find a need, Fill a need)
- Lead by **Serving** Others
- Dream Big

I've interacted with a number of Webflow-ers over the past few years (some I've worked with previously) and I can say without question that they practice these in their daily lives. It's exciting to join an organization where the Core Behaviors are congruent with what matters to me so that **I can _also_ practice these behaviors knowing that I'm fully supported to do so.**

### Building Things For People Who Build Things

I ❤️ building things for people who build things. I am excited to be in a position where I can create features, products and core functionality that will reduce friction and increase joy for the builders using the products Webflow builds.

### Margin

Over the past few years it's been difficult for me to find (maybe even create) margin. The roles I've held at Walmart required me to work a lot of hours that were often hard to create a schedule around (needing to join bridges at all hours of the night—for hours—for site issues). My role at Webflow will give me more consistent hours so that I can spend time with my family, working on other passions (writing about management/building teams/effectivenesss/workflows for example!) and leaving room for breathing.

I'm excited for this next chapter and look forward to the opportunity to serve a new type of customer in a new type of work!

## Frequent Questions with Answers

So far, these are the 5 things almost everyone has asked:

- I will **continue working from home** since **Webflow is a remote-first organization** (there is a super sweet HQ in San Francisco).
- I will be **writing Javascript (React)** full-time and contributing to some Go projects on the side.
- I will be **an individual contributor**, so the only person I'll be managing for now is myself!
- I **will not be on a pager duty rotation**. 🙌🙌🙌
- I will be **traveling a lot less**.


I'm joining Webflow to democratize creation of the web.

Joining Webflow


When working with computers—specifically while programming—you'll inevitably find yourself naming things ([one of the two hard things in computer science](https://twitter.com/codinghorror/status/506010907021828096?lang=en)).

A major factor of being successful in naming is knowing the type of case you want to use so that you can have a consistent convention per project/workspace. If you're writing software, you'll come across at least one of these in a languages specification for how it's written. Some languages (Go, particularly) rely heavily on you knowing the difference between two of them and using them correctly!

## What You'll Learn

- The most common case types:
    - [Camel case](#camelcase)
    - [Snake case](#snake_case)
    - [Kebab case](#kebab-case)
    - [Pascal case](#pascalcase)
    - [Upper case (with snake case)](#upper_case_snake_case)

## camelCase

`camelCase` must **(1)** start with a lowercase letter and **(2)** the first letter of every new subsequent word has its first letter capitalized and is compounded with the previous word.

An example of camel case of the variable `camel case var` is `camelCaseVar`.

## snake_case

`snake_case` is as simple as replacing all spaces with a "\_" and lowercasing all the words. It's possible to snake\_case and mix camelCase and PascalCase but imo, that ultimately defeats the purpose.

An example of snake case of the variable `snake case var` is `snake_case_var`.

## kebab-case

`kebab-case` is as simple as replacing all spaces with a "-" and lowercasing all the words. It's possible to kebab-case and mix camelCase and PascalCase but that ultimately defeats the purpose.

An example of kebab case of the variable `kebab case var` is `kebab-case-var`.

## PascalCase

`PascalCase` has every word starts with an uppercase letter (unlike camelCase in that the first word starts with a lowercase letter).

An example of pascal case of the variable `pascal case var` is `PascalCaseVar`.

**Note: It's common to see this confused for camel case, but it's a separate case type altogether.**

## UPPER_CASE_SNAKE_CASE

`UPPER_CASE_SNAKE_CASE` is replacing all the spaces with a "\_" and converting all the letters to capitals.

an example of upper case snake case of the variable `upper case snake case var` is `UPPER_CASE_SNAKE_CASE_VAR`.

## Which case type should I use?

Now that you know the various case types, let's tackle an example of my recommended best practice for filenames and when to use each case for Go, JavaScript, Python & Ruby.

### What convention should I use when naming files?

**Recommendation: always snake case**

When naming files, it's important to ask "what's the lowest common denominator?" If you're not opinionated, I've found I've had the most success with snake case because it's the least likely to create a problem across filesystems and keeps filenames readable for "my\_awesome\_file".

If you're a Mac user or work with Mac users, it's a good practice to always use lowercase. Mac's have an HFS+ filesystem and since HFS+ is not case sensitive, it can read "MyFile" or "myfile" as "myfile".

My predominant argument for this stems from a particularly insidious "bug" I saw when I was running a CI/CD (continuous integration/continuous delivery) cluster. A CI job failed with "file not found: mycomponent.js" during a build for a React project. The developer swore the file was in the project's source, and as I dug through it, I noticed they had an import for "mycomponenet.js" but the file was named "MyComponent.js" (for a React project, where PascalCase is the convention for naming component files). Due to the way HFS+ handles file casing, it happily accepted that "MyComponent.js" was "mycomponent.js" at the time the developer (using a Mac) was writing the code, but ath the time the Unix based CI server was building it, it would fail because it expected exact casing to find the file.

### Go Conventions

Go is the language where it's most critical to pay attention to case type conventions. The language decides whether a variable, field or method should be available to a package caller by if the name starts with a capital or lowercase letter.

- **Pascal case** is _required_ for exporting fields and methods in Go
- **Camel case** is _required_ for internal fields and methods in Go

```go
package casetypes

type ExportedStruct {
    unexportedField string
}
```

In the above example, `ExportedStruct` is available to package callers for `casetypes` and `unexportedField` is only available to methods on `ExportedStruct`.

### Javascript Conventions

- **Camel case** for variables and methods.
- **Pascal case** for types and classes in JavaScript.
- **Upper case snake case** for constants.

#### React Conventions

I write enough React and it's unique enough that it's worth calling out conventions here as a subsection:

- **Pascal case** is used for component names and file names in React.

### Ruby Conventions

- **Pascal case** is used for classes and modules in Ruby.
- **Snake case** for symbols, methods and variables.
- **Upper case snake case** for constants.

### Python Conventions

- **Snake case** for [method names and instance variables](https://www.python.org/dev/peps/pep-0008/#method-names-and-instance-variables) (PEP8).
- **Upper case snake case** for constants.

### Other Conventions

- kebab case in **Lisp**.
- kebab case in **HTTP URLs** (`most-common-programming-case-types/`).
- snake case in **JSON** property keys.

## Quick Comparison Table

| Case Type                   | Example            |
| --------------------------- | ------------------ |
| Original Variable as String | `some awesome var` |
| Camel Case                  | `someAwesomeVar`   |
| Snake Case                  | `some_awesome_var` |
| Kebab Case                  | `some-awesome-var` |
| Pascal Case                 | `SomeAwesomeVar`   |
| Upper Case Snake Case       | `SOME_AWESOME_VAR` |

Now that you've been introduced to the most common case types, you're prepared to hop into most of the popular languages and know what conventions to keep when you're writing your own code!


A list of common case types, along with some language specific protips

Most Common Programming Case Types




Taking full-length screenshots of a webpage is useful for client work, keeping historical references of a website or when you want to have a webpage round-up gallery to show sites that you've found around the web.

In the past, if you needed to do this, you likely did it incrementally and stitched it together or installed a separate extension in your browser (most had varying results).

Recently when I was doing some mobile web development and checking how my site looked for various devices with Chrome DevTools, I noticed that Chrome has a baked in way of taking a full length screenshot!

1. **Open DevTools.** In the application menu click **"View"**, then **"Develop"**, then **Developer Tools** (Alternatively you can save some clicks with cmd+option+i on a Mac). You should have a new pane that has tabs for "Elements", "Console", "Sources" and more and below that you will likely see the HTML of the page you're currently on.

![How to open Chrome DevTools](/img/chromescreencap_1.gif)

1. **Toggle Device Toolbar.** In the top left corner of the new pane, click the second icon from the left for **"Toggle Device Toolbar"**. A new toolbar should open at the top of the browser's window with options to change the page to be emulate displaying different devices.

![How to toggle device toolbar](/img/chromescreencap_2.gif)

1. **Take The Screenshot.** In the new device toolbar, click the **"More Options"** button (3 vertical dots) in the far right corner and click **"Capture Full Size screenshot"**.

![Now to take a full-screen screenshot of a website with Chrome DevTools](/img/chromescreencap_3.gif)

Now you can take full size screenshots with ease and natively in the browser!


Learn how to take full page screenshots of a webpage using Chrome DevTools

Full Page Webpage Screenshots with Chrome DevTools




Previously when generating new blog articles, adding dates to Markdown frontmatter was a manual step that required me to:

- Determine the date
- Convert what I read into the date format I use for frontmatter

As of [VS Code release 1.20](https://code.visualstudio.com/updates/v1_20#_more-snippet-variables), Snippets have access to the current date and time with one of the following variables:

- `CURRENT_YEAR`
- `CURRENT_YEAR_SHORT`
- `CURRENT_MONTH`
- `CURRENT_DATE`
- `CURRENT_HOUR`
- `CURRENT_MINUTE`
- `CURRENT_SECOND`

Now if I want a frontmatter "date" for Markdown for the current year, month and day (`YYYY-MM-DD`), I can add the following to my snippet:

```yaml
date: "\"$CURRENT_YEAR-$CURRENT_MONTH-$CURRENT_DATE\""
```

Using the published date of this post, the expanded snippet produces:

```yaml
date: "2018-07-24"
```

![Markdown snippet with current date and time automatically inserted](/img/vscode-current-date-time-in-snippets.gif)



Learn how to use current date and time in VS Code Snippets.

Using Current Date and Time In VS Code Snippets




While working on a frontmatter markdown snippet in VS Code I couldn't understand why tab completion wasn't working. It turns out that [some extensions (including Markdown) don't have snippet tab completion enabled by default](https://github.com/Microsoft/vscode/issues/1617) (you can however type `ctrl+Space` to show available snippets with what you've typed).

VS Code has a setting for `editor.tabCompletion` that has 3 options: `"on"`, `"off"` (default), `"onlySnippets"`. Let's go through how to enable snippet completion for all files first and how to enable it only for a specific file type.

## Enable snippet tab completion for all extensions

Open the **Command Pallete** (`⌘+shift+p` in MacOS, `ctrl+shift+p` in Windows)[^cmd-p], type **"Open Settings (JSON)"** and press return. This will open the file **settings.json**.

At the bottom of the file, add the following (don't forget to add a comma to the item before! Otherwise you'll get a syntax error):

```json
    "editor.tabCompletion": "onlySnippets"
```

Save your **User Setttings** configuration, open a Markdown file and type FM

![Markdown Snippet Tab Completion](/img/markdown-expand.gif)

[^cmd-p]: If you have your settings to default to **Open Settings (JSON)**, you can use `⌘+,` in MacOS, `ctrl+,` in Windows.


A quick guide to enabling tab completion for Markdown Snippets in VS Code.

Enable tab completion for Markdown Snippets in VS Code


One of my *favorite things* is to find an example of code that "Works on my machine" but fails in CI.

In this example, I was working on a project that's using React and importing a component from a file called `components/Form.js`. I needed to import the new component into `Post.js`. For my import, I added the following line to my imports:

```jsx
import Form from "./components/form";
```

Once I had an import, I used the component, checked it locally with `localhost` and verified everything looked good.

When everything was ready, I opened a PR, went to get some coffee, came back to merge amd saw a little. red. x.

Those little red X's can be surprising, especially when you didn't change much and the code you did change worked locally. I checked my Netlify build logs and found this:

```shell

error Generating JavaScript bundles failed
    Error: ./src/templates/post.js
    Module not found: Error: Can't resolve '../components/Layout' in '/opt/build/repo/src/templates'
    resolve '../components/Layout' in '/opt/build/repo/src/templates'
    using description file: /opt/build/repo/package.json (relative path: ./src/templates)
```

If you're not used to seeing this (I've seen this before a few times when I was working on CI at WalmartLabs, enough so that it inspired me to write about the various types of case in programming), it's easy for your very first shought to be 'That file is definitely there...something must be wrong with the build process or build server."

While working on some react components, I decided to downcase all the filenames.

When I did a `git status` I saw that everything was up to date even though I had clearly renamed the files.

This is a problem with HFS+ (the filesystem that most MacOS machines are formatted to by default).

The easiest way to always do this right in the future is to use `git mv <oldFilename> <newfilename>`.

## Takeaways

- Always assume the CI machine is right and something is wrong with your code (don't say "weird, it works on my machine")
- Opt for all lowercase file names, especially in places where there's no convention.
- Running your app in a container that emulates the environment where the build process happens.
- Run your code locally in a Docker container that matches your build environment.
- Always run CI before merging code into a project (through a Pull Request hook in your favorite git repository).
- For JS, you can't rely on automatically updating import statements.


Learn why and how to use git mv instead of mv on MacOS when changes case on filenames.

Why Git May Be Ignoring You When You Downcase Filenames


When I transitioned from writing Javascript into writing Golang, I quickly realized that there was a big difference in what it means for something to be truthy.

## Truthiness in JavaScript

If you're unfamiliar with the term truthy, it means that a non-boolean type value (for instance, string, number, null) can be evaluated to a boolean. A fairly common example of that in javascript is to evaluate a string's truthiness before doing something with it:

```js
let foo = "";

if (foo) { // "" evaluates to false, since it is empty
    console.log("the fu is strong with you");
}

foo = "foo";

if (foo) { // "foo" is true since it contains a string of length > 0
    console.log("how in the world can a string be true?!");
}
```

Another example is to check the value of an number:

```js
let isGreaterThanZero = 0;

if (isGreaterThanZero) { // 0 evaluates to false, because 0 is "empty"
    console.log("it's greater than zero.");
}

isGreaterThanZero = 1;
if (isGreaterThanZero) { // any number that's _not_ zero evalutes to true
    console.log("it's greater than zero.");
}
```

When you've written javascript for a long time, boolean evaluation not only feels normal, it becomes surprising when a string *doesn't* evaluate to a boolean.

## What is Truth in Golang

In Golang, there's only one type that has truthiness: booleans.

It makes sense right? That whole "if it quacks like a duck" analogy makes it a lot easier to know what your value is, but it also means that if you come from a language where you relied on boolean coercion, you need a major paradigm shift in how you check the truthiness of a non-boolean value.

## Strings

As far as I've seen, there are two idiomatic ways in golang to test if a string is true:

- test if a string has a length greather than 0
- test if a string is not equal to an empty string ("")

```go
package main

import "fmt"

func main() {
    s := "hello"
    if len(s) > 0 {
        fmt.Println("this string is not nil")
    }
        
    if s != "" {
        fmt.Println("this string is not empty")
    }
}
```

## Numbers

Alternatively, for numbers, check if the value is greater than 0:

```go
package main

import "fmt"

func main() {
    n := 1
    if n > 0 {
        fmt.Println("this number is greater than 0")
    }
}
```

## Wrapping Up

This was a big mental shift for me, since javascript took care of coercion for me, but once I was able to make the shift, I realized that relying on coercion made my code more likely to have bugs.

The big takeaway here is that **Golang does not have automatic type coercion for values that aren't of type `bool`** and those values have to be checked against an empty value for the type you're using.


Coming to Golang from a language like Javascript comes with a lot of baggage. In this article, I'll demystify truth in Golang.

Golang: What is Truth?




I discovered _[Making Work Visible](https://www.walmart.com/ip/Making-Work-Visible/56040750)_ when I needed it most and was most ready for it. It is a canonical book for anyone who wants to be effective at getting the right things done in the right amount of time.

## Why It Mattered To Me

I was two months into my journey as a manager for a small technical team whose primary responsibility was to manage an overwhelmingly active queue of support requests.

I was struggling with two major tensions:

1. "How do I know the work we're doing is the right work for the right time?"
1. "How do I ensure we're able to be effective?"

I wanted to increase our internal customers' velocity and happiness by decreasing the request resolution time without increasing risk (production systems) or hours at work.

I was uncertain (and lacked confidence) of how to best visualize the team's work to uncover our constraints (what [_Making Work Visible_](https://www.walmart.com/ip/Making-Work-Visible/56040750) calls **Time Thieves**).

_[Making Work Visible](https://www.walmart.com/ip/Making-Work-Visible/56040750)_ equipped me with tools to ask the right questions to find clarity about my tensions and overcome my lack of confidence. In the short amount of time between finishing the book and now, my team has made a number of small changes to help us expose the 5 time thieves. In the past two weeks, I've received feedback that these changes have made our internal customers feel better supported and engaged, given back our sibling teams time to spend on planned work without increasing headcount or the amount of hours my team is working (my next goal is to reduce the amount of hours we spend on this work).

## Key Takeaways

Setup a workflow system to do five things:

> The solution is to design and use a workflow system that does the following five things: Make work visible. Limit work-in-progress (WIP). Measure and manage the flow of work. Prioritize effectively (this one may be a challenge, but stay with me—I’ll show you how). Make adjustments based on learnings from feedback and metrics.

### Exposing The 5 Time Thieves

_[Making Work Visible](https://www.walmart.com/ip/Making-Work-Visible/56040750)_ has a number of exercises to try out with teams to expose the time thieves. The ones that resonated with me to start with were "Explore the Five Reasons Why We Take on More WIP" & "Demand Analysis".

### How Is Work Prioritized

There's the way you _want_ work to be prioritized and the way it _is_ prioritized. Creating a label for who asks for a task, tracking whether it's planned or unplanned, and how compelled we are to get it done will enable us to determine how the work is _truly_ prioritized. If we can be aware of how work is expected to be prioritized, we can have a deeper discussion with the person who asks for that work to help us increase visibility into the things they're going to ask for with more notice.

### Lean Coffee

"Lean Coffee"—a meeting format created by Jim Benson:

> Lean Coffee turns traditional, one-direction management meetings on its head by helping teams uncover the most important topics to the majority of people, by allowing everyone to hear and to be heard, and by providing real-time feedback.

I've always disliked agenda-less meetings, but the idea of a meeting that's purpose is to determine what the important topics are and talk about those topics? That's a meeting format I can get behind. I'm excited to try this style of meeting out with my team (as well as a few non-work meetings I'm a part of) to uncover what's really important and needs to be talked about and talking about those topics.

### Other Topics I Learned About:

- 5 Time Thieves
- Kanban
- Flow time
- Operations Reviews
- Queueing Theory

### Some Favorite Highlights

> We allow the chaos of modern work coupled with an often paralyzing number of options at our disposal to overload us, to distract us, to stealthily steal our time and focus and ultimately impede our effectiveness.

> All it takes is a shift from haphazardly saying yes to everything to deliberately saying yes to only the most important thing at that time. And to do it visually.

> Indeed, time is sacred. Treat it as such. Visualize your work. Limit the amount of work you take on. Pay attention to its flow. Build thoughtful work systems to reflect what really matters. To breathe. To think. To learn. To grow. To play. To love. To live. For it is in working well that we can live well.

### Added Bonuses

**Book recommendations abound.** There were at least 4 other books that Dominica mentioned that caught my attention and are now on my list of books to read.

**Quotes.** Every chapter starts with a quote and I found myself highlighting almost every one.

## Who Should Read It?

If someone has asked you "how are you doing?" and you responded with, "I'm (SO,TOO,VERY) busy!" or "I'm working way too much.", read this book.

If you are on a team where no one knows what anyone else is doing, read this book.

If you know you could be _completing_ (operative word) more work in less time but can't determine why you're unable to do it, read this book.

If you find yourself with a million things to do and you suffer from deciding where to start, read this book.

This book doesn't encourage overwork or hero mentality, rather it gives you the tools to ask, "how can I be more effective without spending an insane amount of hours working?"

**If you enjoyed this review, please consider buying _Making Work Visible_ from [Walmart](https://www.walmart.com/ip/Making-Work-Visible/56040750) (you'll be supporting me in an indirect way). If you support your local library, be sure to check for it in eBook or audiobook through [Libby by OverDrive](https://meet.libbyapp.com/). If you'd prefer to buy it on Amazon, you can buy it in [paperback](https://www.amazon.com/Making-Work-Visible-Exposing-Optimize/dp/1942788150/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=1517151393&sr=8-1), [kindle](https://www.amazon.com/Making-Work-Visible-Exposing-Optimize-ebook/dp/B076BYZ6VN/ref=sr_1_1?ie=UTF8&qid=1517151393&sr=8-1&keywords=making+work+visible) or [audiobook](https://www.amazon.com/Making-Work-Visible-Exposing-Optimize/dp/B07776XY3D/ref=tmm_aud_swatch_0?_encoding=UTF8&qid=1517151393&sr=8-1).**


Making Work Visible is a canonical book for anyone who wants to be effective at getting the right things done in the right amount of time.

Making Work Visible [Book Review]



I joined the show to talk about working on distributed systems with distributed teams, giving people opportunities to learn and grow, and interesting Go projects and news.

My Intro:

They call me chaseadamsio, <br />
I love building software you know, <br />
and I'm happy to say, that there's no better way, <br />
than to power said software with go.

<audio data-theme="night" data-src="https://changelog.com/gotime/54/embed" src="https://cdn.changelog.com/uploads/gotime/54/go-time-54.mp3" preload="none" class="changelog-episode" controls></audio>[Changelog.com - Go Time 54: Go at Walmart (and Scale) with Chase Adams](https://changelog.com/gotime/54)<script async src="//cdn.changelog.com/embed.js"></script>


I joined GoTime to talk about working on distributed systems with distributed teams, giving people opportunities to learn and grow, and interesting Go projects and news.

Guest on GoTime: Go at Walmart (and Scale)




**I have been using Emacs for a month (as of this post) and it would be a Hurculean task for any other editor to pull me away from it!**

At the beginning of December 2016, I joined a new team at WalmartLabs writing Go to optimize the request/response lifecycle. I was having a conversation with one of my new teammates ([Shane Hansen, who's an awesome go developer](https://www.whitane.com/)) about which editors we used.

**I used Vim. He used Emacs.**

I'd been using Vim for over 4 years religiously and that was the moment that I realized that he was the _first emacs user I've ever met_. It led me to ask, "why have I never given Emacs a try?"

That night I googled "Emacs" and started my journey down the rabbit hole and haven't come back out of it since...in fact, I've given up on considering other editors because **Emacs is the best editor for me.**

![A Screenshot of My Emacs Editor](/img/emacs.png)

Why I'm using Emacs

I've tried a number of editors (Coda, Sublime, Atom, VSCode and clearly Vim) but have never been able to leave vim because I always felt so darn productive using it.

Even though I knew I'd be sacrificing my initial productivity, there were a few major reasons I was willing to try out Emacs:

- Emacs has been around since the mid-1970s and **still** has a group of people who are contributing to it heavily...and it does stuff none of the other editors I've used can do.
- Learning lisp is different, but Emacs lisp makes the editor itself incredibly powerful and flexible.
- It's self-documenting. If you want to know what a particular keybinding does, you can type a help command that'll prompt you to type the keybinding and then it'll show you the docs for whatever method it's bound to. How neat is that?
- **Org-mode. Org-mode. Org-mode.** This is going to get its own blog post, but org mode the most amazing feature of any editor I've ever used. It's a way to write todo lists. It's a way to keep an agenda in your editor. To capture todos. To capture notes. To capture anything your heart desires...from anywhere in your editor, quickly. It's a way to practice literate programming (rather than write code and document with comments, you write the documentation in a `*.org` file and you can run the code _from_ the file or "tangle" it into its own file, such as a shell script...it's really just amazing). **Org-mode itself has been the most valuable reason for me to learn Emacs.**

and one minor reason...

- **It's not written in Javascript.** I debated whether I should bring this up, but I don't think Javascript is the right language for an editor. I get better IO response from keystrokes (no visual lag) on Emacs in a VM than I do in Atom or VSCode on my host machine. I'll always love Javascipt, I just don't love it as the core language of my editor.

## If You're Considering Giving Emacs a Shot...

Here's some advice I'd like to give you if you're willing to try out Emacs:

- **Go into it with an open mind.** Everything new is scary. It's easy to justify not putting time into it by saying "this is scary" or "this is stupid" or "I don't have time for this". I'm not saying you _should learn emacs_, but I am saying that if you're choosing to invest time in it, give it a fair shake.
- **Go through the Emacs tutorial.** Learning the keybindings and functionality of Emacs is one of the most critical steps to success.
- **Wait to install plugins.** I know the white background is probably jarring, especially if you're using a dark theme in your current editor. There's so much out of the box that it can do and if you've gone through the tutorial, chances are you're getting a good chunk of what your current editor gives you. If you need things to write go or javascript, you can install plugins, but it's good to get a feel for the editor before installing stuff you may not need.
- **If you're coming from vim & your keybindings are a deal breaker, install evil-mode.** I use vim keybindings everywhere, so I installed evil-mode and found that it provided 100% of what I used in vim, which is a pretty awesome testament to whoever wrote `evil-mode`. Most vim keybinding extensions for other editors are missing basic features that made it hard to use for me.
- **If you use evil-mode...eventually try using Emacs without it.** I disabled `evil-mode` because I wanted to give the keybindings in Emacs a fair shake too, and they're not so bad! I've been using Emacs without `evil-mode` productively for almost two weeks now.
- **Check out [Sacha Chua's: How to Learn Emacs](https://sachachua.com/blog/2013/05/how-to-learn-emacs-a-hand-drawn-one-pager-for-beginners/) visual tutorials.** Pretty much every sub-rabbit hole I've gone down in Emacs has either started or ended with something from Sacha's blog, it's a /gold mine/ of information for learning Emacs.
- **Read the docs for org-mode.** Seriously, I can't convey how awesome org-mode is in this single post, but I'm hoping to churn out a bunch of new content explaining in a systematic way how to use org-mode to be a more effective engineer. Check out the [org-mode docs here](https://orgmode.org/)
- **Check out my emacs dotfiles.** All of my dotfiles are now org files that are either tangled or executed from my [dotfiles](https://github.com/chaseadamsio/dotfiles) directory. You can checkout my [emacs config](https://github.com/chaseadamsio/dotfiles/blob/master/emacs.org) which is loaded from my [`init.el` that's tangled from my bootstrap.org](https://github.com/chaseadamsio/dotfiles/blob/master/bootstrap.org) ]] or read through my [osx-defaults which are executed from emacs to setup a new OSX environment](https://github.com/chaseadamsio/dotfiles/blob/master/osx-defaults.org). Did I mention how much I love `org-mode`?


Curious about Emacs? Read about my journey with it.

Getting Started With Emacs




**MacOS Version:** macOS Mojave

If you want to show your Mac's Hard Drive in Finder instead, check out ["Show your Mac's Hard Drive in Finder"](/2014/01/show-your-macs-hard-drive-in-finder-sidebar/).

I spend all of my time in my home folder, and while I don't use Finder very much anymore, I find it useful to have quick access to the home folder. In this quick MacOS Protip, I’ll guide you through showing the shortcut to your user's Home folder in OSX.

## Show User's Home Folder in Finder Sidebar

![Show User's Home Folder in Finder Sidebar](/img/finder-show-home.gif)

Start by clicking on the Finder icon in your dock, and a new Finder window should come into focus.

In your Finder you should see a sidebar with Favorites and a list of devices. If you don’t see the sidebar, click on “View” in the application menu at the top and then click “Show Sidebar”.

Under Favorites, click the checkbox next to the icon of the home with your username to the right of it. You should now see a link to your user's (in my case, "chaseadamsio") home directory in your Finder sidebar.

As you can see, you also have the ability to show shared items and other external devices. I hide almost all the Favorites (with exception of Applications, Documents &amp; Downloads), show all the devices and turn on all shared but Back to My Mac.


Learn how to show your User's Home Folder in the Finder Sidebar.

MacOS Protip: Show your User's Home Folder in Finder Sidebar




**MacOS Version:** macOS Mojave

If you want to show your Mac's Hard Drive in your Finder sidebar instead, check out ["Show your Mac's Hard Drive In Finder Sidebar"](/2014/01/show-your-macs-hard-drive-in-finder-sidebar).

Quick access to your Hard Drive is incredibly useful, especially when you need to browse above your home directory. In this quick MacOS Protip, I’ll guide you through showing the shortcut to your Hard Drive on your desktop.

## Show Macintosh HD on Desktop

![Show Macintosh HD on Desktop](/img/finder-show-mac-hd.gif)

Open Finder and click on “Finder” in the application menu at the top of the screen, then “Preferences” in the drop down menu. This will open the Finder Preferences pane.

If “General” isn’t the selected navigation icon (for instance, if you just finished the Finder Sidebar tutorial), select it.

Under “Show these items on desktop” click on “Hard disks”. Now if you look at your desktop, you’ll see the icon for your Macintosh HD.


Learn how to show your Mac's Hard Drive on it's Desktop.

MacOS Protip: Show your Mac’s Hard Drive On Your Desktop




I am _not a_ remote worker, **I am a part of a distributed team.**

The word “remote” is loaded with negative baggage: something or someone that’s far away, distant; isolated. Something or someone that’s out of touch with the reality of how things really are.

As a software engineer, when I think about the term “remote”, I think about accessing a machine that’s out of sight, but one in which I can control. It’s uni-directional, communication is often flaky at best and creates frustration in the ability to be effective.

The term “remote” focuses on _where the team member is_ . It doesn’t address _what_ needs to be done or _how_ to do it. The _where_ is **totally irrelevant to the work.**

The term “distributed,” however, naturally lends itself to thinking about **what needs to be done and how we go about doing it together.**

Communication on a distributed team isn’t uni-directional, it’s not even bi-directional, it’s **n-directional** , as each individual now decides how they collectively work towards a common purpose.

An organization shifting from having remote workers to **the** **distributed model helps teams transcend the “remote vs in-office” mentality**. In a remote model, it’s common for those who are in an office (which may very well be remote from the home office) to ask, “why does that person get to work from home (or co-working space) and I have to be in the office?” It’s also common that a remote worker feels they’re left out of the loop because communication is done in person.

Shifting from thinking about people as “remote” to teams being distributed teams allows us to streamline communication, create stronger connections, expand the candidates we hire so we find the best fit for our teams, not just “local” talent.

**The distributed team paradigm focuses on...**

- _how_ we work being the driving force to our success (not _where_ we work)
- goals being concrete and achievable
- communication being clear and focused
- individual self-management equally contributing to the team’s success

  **The distributed team paradigm is _not..._**

- an opportunity to shirk responsibility
- a way to get out of being a part of a group
- the chance to get out of meetings or being around people

  **The distributed model** allows us to do our best work when our bodies and minds are most optimal, rather than feeling the need to be “butts in seats from 9–5 to be noticed.” As our technologies become more distributed (as they already have), our _teams_ becoming distributed facilitates our abilities to think of how our software works (and can be better) and how our software works helps us shape the way our teams effectively move our products towards their ultimate purpose.

So this is a call to join us in our journey to eliminate the idea of remote workers and **embrace the idea of distributed teams** . Over the next few months we’ll be posting retrospectives of what we’ve done and how it worked for our teams. We invite you to join us in doing the same and using the tag #distributedteams and sharing what you’ve tried, what worked and what didn’t go so well.

We are not remote. We are not in-office. **We are Distributed.**


The term 'remote' focuses on where the team member is. It doesn’t address what needs to be done or how to do it. The where is totally irrelevant to the work. The term 'distributed', however, naturally lends itself to thinking about what needs to be done and how we go about doing it together. I am not a remote worker, I am a part of a distributed team.

Remote is Dead. Long Live Distributed.




**I want to be the best person I ever manage.**

This is a systematic approach at discovering and documenting who I am. Many of the high-level concepts in this document are heavily borrowed from Peter F. Drucker's _Managing Oneself_.

## Table of Contents

- [Introduction](#introduction)
- [Desired Outcomes](#desired-outcomes)
- [What Are My Strengths?](/strengths)
- [How Do I Perform?](/perform)
- [What Are My Values?](/values)
- [Final Thoughts](#final-thoughts)

## Introduction

I believe I can be systematically discoverable.

When I left Zappos.com 4 months ago to work with Walmart Labs, there were many aspects of my professional life that changed and these changes catalyzed a movement in me to systematically discover who I was.

- I transitioned from being "required" to be in an office to being fully distributed & outside of an office
- I transitioned from being on a team with a project manager and sprints to a team that was fully autonomous and self-driven, and for a lack of a better term, was continuously delivering
- I transitioned from a reactive sense of responsibility to a proactive thoughtfulness
- I transitioned from the customer being my customer to engineers who served the customer's needs as being my customer

As is true of any new venture, I felt ill-equipped to successfully make these transitions with the toolset I had. By some strange twist of Amazon recommendations, I stumbled onto _Managing Oneself_ by Peter F. Drucker. **This is [one of three books that I recommend to anyone wanting to chart a path for being an impactful and effective person](/essential-books).**

One of the excerpts that stood out most to me was:

> "Successful careers are not planned. They develop when people are prepared for opportunities because they know their strengths, their method of work, and their values."

The key to success isn't planning, it's knowing _yourself_.

This documentation is the outflow of me attempting to know myself, in a pragmatic, systematic way, based on insights from _Managing Oneself_.

## Desired Outcomes

There are a few desired outcomes I have for doing this, in descending order of importance:

- **Capturing & Understanding Myself.** Ultimately, this guide is for me. I want to have an understanding of myself so I can make better, more prudent decisions based on what I've discovered. Whether it's "should I take this professional opportunity" or "should I engage in this in my freetime", this document and systematic discovery should guide me. If no one else ever looked at it, it would still be worthwhile.

- **Sharing Myself with Peers & Future Peers.** I know that if I work with (or for) someone directly, I want them to be the kind of person who wants to know these topics about me. I want to provide as much information as I can about myself so that I'm (1) a respected and impactful peer, (2) effective in the work where I collaborate and (3) available to be used for the clearly defined strengths, in the method that I do it best, while fully aligned with my values.

- **Sharing The Framework with Others Like Myself.** When I realized this project was a priority, I had no idea where to start...even before I realized it was a priority, I put off making it a priority for that very reason. I want to provide not only what I find about _myself_ by using this framework, but the framework itself. It would be exciting for me to have peers who say, "I took a systematic approach at documenting myself too!" If this document can help one other person, that is a huge win for me.

## Framework

The framework is actually really simple, and as I said before, is heavily borrowed from _Managing Oneself_. As the book itself is really more of a long-form essay (you can find a free [pdf copy here](https://www.usb.ac.za/Common/Pdfs/usb-career-center/articles/HBR%20Managing%20Oneself.pdf)), this is an abstraction of what Drucker suggests any thought-worker should know about themselves and what process I went through to actually figure these things out.

### Strengths, Method of Performing & Values

The first task Drucker recommends is to answer the following questions:

- What are my Strengths?
- How Do I Perform?
- What Are My Values?

#### What Are My Strengths?

This one can be _really_ hard to figure out on your own, fortunately, there's a framework that exists to help you do that already!

I used [StrengthsFinder 2.0](https://strengths.gallup.com/110440/About-StrengthsFinder-20.aspx). If you buy the book, there's a code to take the StrengthsFinder assessment in the back and IMO, the introduction is worth the price of the book and the rest of the book makes a great reference after you've taken the assessment.

You can see the answer to ["What are My Strengths?" here.](/strengths)

#### How Do I Perform?

There are two questions here:

- Am I a Reader or Listener?
- How Do I Learn?

The first one is an easier question to answer: think about the times you've solved a problem or created a mental model of something. Did you do it by reading from texts and documentation or did you do it by having a conversation with yourself and others?

How Do I Learn was a little trickier, so I deferred to the experts and found a questionnaire on [vark-learn.com](https://vark-learn.com/the-vark-questionnaire/). It's a free test and the feedback is given to you on a scale for four categories (VARK):

- Visual
- Aural
- Reading/Writing
- Kinisthetic

Once you've taken the questionnaire and get your feedback, there's lots of great information on:

1. how to intake information
2. how to successfully take notes and
3. how to successfully perform in any test, assignment or examination.

I think 3 could also be general output, as I don't / haven't done any of those 3 tasks in a long time, but I believe how to best output would be great for preparing for meetings, deep-dives & presentations.

Taking this assessment was really helpful in giving me the information I need to know how I consume information to best perform at work and explained a lot about why I do my best work when I interact with people.

### What Are My Values?

This was probably the _trickiest_ one of all because there's no "discovery" framework that I could find that made it really easy to answer questions and get a response with answers about who you are, so I decided to do a self-inventory over time of what really mattered to me in the moment.

For 3 weeks every time I felt excited about something or really frustrated about something, I'd write it down. Whether that was at work or at home, I'd think about the "event" and write down some abstraction about what it exemplified.

As an example let's take "Do. Document. Distribute. Automate": Whenever I was able to automate a process that I used to do by hand, it'd put me on top of the world, so I wrote down "automate". Automation, however, was not the whole picture, it was the ability to start with something and work through the process of documenting it, having others help with it and eventually automating it so we could do _other things_ that were _more important_.

I did this for around 30 different phrases and then sat with those, removed many and prioritized the others as "inside out", meaning the values that impacted other values were at the top. "God foremost, Family first" is the lens through which everything els is filtered. After that "Glow In The Dark" because if I wasn't pursuing a life where I was glowing in the dark, the rest didn't matter.

## Final Thoughts

Using this framework to discover who I am has empowered me with one of the most important tools I could ever have: **To know myself.**

Knowing myself and having it documented allows me to revisit it so that I can grow in my strengths, challenge my values and use how I perform to be better in all areas of life. It allows me to give my current and future peers a look into who I am so they can decide if I'm a good fit for their team or organization and **give others a recipe for discovering who they are so they can _glow in the dark_.**


This is a systematic approach at applying 'Managing Oneself' to my life. Many of the high-level concepts in this document are heavily borrowed from Peter F. Drucker's Managing Oneself.

A Systematic Approach to Managing Oneself



![Essential books that changed how I live and work](/img/essential-books.jpg)

Every so often you come across a piece of writing that was such a critical component to changing the way you live your life or pursue work, that it's worth revisiting.

Not only are they worth revisiting, **they're worth evangelizing so that they help other people.**

For myself, I have 3 such books that I re-read multiple times a year and own in multiple formats for consumption:

- [The Seven Habits of Highly Effective People](#the-seven-habits-of-highly-effective-people)
- [Managing Oneself](#managing-oneself)
- [Essentialism: The Disciplined Pursuit of Less](#essentialism-the-disciplined-pursuit-of-less)

## The Seven Habits of Highly Effective People

**_by Stephen Covey_**

This book has been with me since I was a teen and I've read it at least once every year (often before a new year begins).

Stephen Covey was the master of being _effective_. The title of the book clears any ambiguity: it holds the seven habits that drive highly effective people.

Choosing to intentionally practice these principles has helped me to grow tremendously and every time I read it, I walk away from some new insight because of new experiences that I didn't have the year prior.

Link: [The 7 Habits of Highly Effective People on Amazon](https://amzn.com/1451639619)

## Managing Oneself

**_by Peter Drucker_**

Managing Oneself was one of the first books I read after taking a remote position at Walmart Labs.

I believe the key to being successful at being an impactful remote contributor is having the ability to manage oneself, and who better to guide me in that growth than the master himself?

The principles he lays out in this tiny, essay-esque book were critical for my success as a remote engineer and has continued to be a critical guide for my professional growth.

It was so critical to my success as a remote engineer, I started a [small systematic framework based on Managing Oneself](/systematic/intro).

The conversational flow of Drucker's writing and the short nature of the book itself make it easy to consume every other month in a single sitting.

Link: [Managing Oneself by Peter Drucker on Amazon](https://amzn.com/142212312X)

## Essentialism: The Disciplined Pursuit of Less

**_by Gregory McKeown_**

Essentialism came to me at a time when I craved direction in my career and was drowning in a million choices.

Essentialism is about _living life by *design* not by default._ It's about distinguishing the vital few from the trivial many. It is a systematic approach to determining _what is my highest point of contribution_ and _how do I execute on it?_

Essentialism helped me to decide to hone in on what was important and eliminate everything else. Every time I read it, it helps me realign and recalibrate, making me more focused on my essential intent.

Link: [Essentialism: The Disciplined Pursuit of Less (Amazon)](https://amzn.com/0804137382)

**These books have shaped the man I am today, both in my personal and professional life** and without them, I believe I'd be less intentional and less effective. They have become the canonical guides that help me navigate the waters of life and for that I am eternally grateful.


The canonical writings that I revisit multiple times a year because they have (and continue to) impacted my life deeply.

Essential Books That Changed How I Live & Work




When I started learning how to code in 2008, the landscape for a frontend developer was very different than it is today. In 2008, it was good to know HTML & CSS (that hasn't changed) and with a little bit of jQuery knowledge and the ability to use the WordPress API and an FTP uploader, you could get by building basic brochures sites for clients, but you couldn't _bend the web to your will_.

In the last 3-4 years, Frontend Engineering has changed from being more about simply the aesthetics and content and become a role that requires thinking about optimization, data structures and state. If your eyes just glazed over, that's okay, just read on.

I'm going to explain at a very high level the five technologies that are crucial to my day-to-day as a Frontend Engineer with the hopes that it:

- Gives you starting points for what technologies to learn if you want to pursue becoming a Frontend Engineer.
- helps **Junior Frontend Engineers** have a roadmap for what they should already know and what they need to learn.

The Five technologies (mostly languages, if you want to learn about [frontend engineering tools, check out this post](/2015/07/tools-of-the-trade)) every Frontend Engineer should know are:

- [HTML](#html)
- [CSS](#css)
- [Javascript (vanilla)](#javascript-vanilla)
  - [JSON](#json)
  - [NodeJS](#nodejs)
- [Git (Version Control)](#git-version-control)
- [Markdown](#markdown)
- [Wrap Up](#wrap-up)

The _really good news_ is that nothing has replaced `html`, `css` or `javascript` as browser languages since the [first browser wars](https://en.wikipedia.org/wiki/Browser_wars#First_browser_war) so being able to use them will be useful as long as web browsers continue to exist.

## HTML

`html` (HyperText Markup Language) is the language that defines the content of the web. A web browser will read an `html` file and render the content into the browser. If a webpage were a living being, `html` would essentially be the bones. It gives the webpage structure.

No matter what you're building for the web, if it's in the browser you'll be using HTML, either directly or through a component library or templating language.

## CSS

`css` (Cascading Style Sheets) is language that gives a website its look and feel. Where `html` was the bones, `css` is the skin. Without `css` a website would simply be text and images: a rendered bland blob of content.

The result would be that every paragraph tag would have a background of "electric blue" (using a hexidecimal color value), the font color would be white and the paragraph will have padding of 1em (which is basically the size of the font inside the paragraph):

CSS is really important for giving visual cues, adding general aesthetics and giving a website the unique qualities it needs to stand out.

## Javascript (vanilla)

**Javascript is my favorite language: It's the language of the functionality of the web.**

Whenever you submit a Facebook post, reshare a tweet on twitter, send an email in gmail, click a swatch color on Zappos.com that changes the images and buy box selection to match that color, **that's Javascript**.

Javascript has become a huge part of being a Frontend Engineer because it drives so much of what we actually do on the web that's interactive.

In the past, most websites would have full page reloads when you clicked a link, today a lot of websites are transitioning to Single Page Apps, which means every interaction on a website in the browser is fully powered by Javascript.

Within Javascript there are two subsets that I think are really important: `json` and `node`. These are _really_ useful and my guess is that if you do become a Frontend Engineer you're going to have a hard time getting away with _not_ using them.

### JSON

`json` is a subset of javascript, easily readable by humans, for defining objects with key value pairs. It's generally used for communication between a server and a web application.

Most APIs provided by companies (such as Twitter, Trello and GitHub) are in `json` format and many companies are using `json` APIs to serve their data to the Frontend, which means Frontend Engineers will be spending a lot of time using `json`. @WalmartLabs, for example, is building the entire eCommerce platform on a RESTful `json` API.

The really cool thing about `json` is that even though the language was created from how Javascript objects work, any other language can consume it, which makes it both easy to read and easy to use for _any developer_.

### NodeJS

Once you've learned the basics of Javascript in the browser, transitioning those skills (the core syntax and concepts) to the server has a huge amount of value. You can do that with NodeJS, a run-time environment for server-side and networking applications.

NodeJS is being used heavily in a lot of organizations (Netflix, Walmart, General Electric and [an ever growing list of others](https://github.com/joyent/node/wiki/projects,-applications,-and-companies-using-node)) for both serving content and internal tooling, which makes it a really valuable "language" to know. There are some conceptual differences in NodeJS from Javascript in the browser but learning `javascript` for both the browser and the server will make you a huge asset wherever you're working.

## Git (Version Control)

`git` isn't a language, it is a version control system, a technology that every developer should be using. `git` allows developers to keep a history of how their files changed, easily merge other developer's change, revert a project to a specific state in the history and define stable versions of a project.

Note: a lot of new developers use the term `git` interchangeably with github.com. GitHub.com is _one place_ where a developer can keep their projects that are version controlled with `git`, but it isn't explicitly related to `git`.

## Markdown

Markdown is the easiest technology to learn in this list, but it's one of the most prolific technologies on the internet. Markdown is a really simple syntax that allows anyone to write text that can be easily converted into `html`.

Markdown is the language of documentation, so if you're working on a project that will be used by someone else, most likely you'll be (should be) writing documentation and doing it in Markdown.

Every post I write is also written in Markdown, as an example My post on [Frontend Tools of the Trade](https://github.com/chaseadamsio/chaseadams.io.hugo/blob/master/content/post/2015/07/tools-of-the-trade.md) is converted into `html`, but [this is the raw markdown](https://raw.githubusercontent.com/chaseadamsio/chaseadams.io.hugo/master/content/post/2015/07/tools-of-the-trade.md) used to generate it.

An example of markdown would be:

Which would render to the following `html`:

The basics are outlined on the [Daring Fireball Markdown Basics](https://daringfireball.net/projects/markdown/basics) page.

## Wrap Up

These five languages are core to what I do on a daily basis and knowing these languages will make you both a powerful Frontend Engineer and a huge asset to any organization building for the web.

_Are you interested in learning the skills required to be a frontend engineer? Let me know in the comments below!_


Frontend Engineers should have five technologies under their belt

Five Technologies Every Frontend Engineer Should Know




Today is going to be a hard day for me.

I've said most of my goodbyes, I've emailed out my goodbye email, I've even had my goodbye lunch.

The closure won't change the fact that I'll always remember the good times I had at Zappos and the good friends I've made.

To all my friends who were once a part of my Zappos experience and have left: I'm so grateful for everything you did to help me grow, laugh and get through the struggles.

To all my friends who are still there: You're the secret sauce that makes Zappos great. It's not holacracy or "culture events" or free coffee.

To my lunch crew: I'm going to miss the chance to totally zone out from work to talk about something gross or watch videos and looking at pictures of all of you guys when you were kids.

To FEZ: Thanks for all the laughter, candy overloads and cards against humanity. I learned something awesome from everyone of you and I hope I've helped you learn something awesome too. Our code is our craft. Never forget. #fezForLife

To GSD: You guys have been one of the most awesome groups of people, both the alums and the people who are still with us and I am so proud of you guys for all the work you did to get Search and Product pages out the door despite the hurdles we had.

To GSD Contractors: You guys were as good as full-time hires as far as I'm concerned. You were awesome Zapponians.

To mdot: Rafael, you've got one of the best attitudes of anyone I know. Someone could ask you to clean a toilet and you'd figure out how to make it fun and do it with a grin the entire time. Thanks for always reminding me that work is fun when you're with people you enjoy being with. Dave...well...you know.

To Mark Walker: I'll never forget the first time we played ultimate frisbee, built FRACK for 6pm.com and somehow always ended up on the same teams. I'll miss our walks to the water cooler to watch drug deals go down at the pump and snack, arguing over code review practices and letting you win, running after work those few times we did it and your genuine acceptance of the fact that I believe something totally different from you and all of the really wonderful conversations that came from it. Regardless of how much you want people to think you hate people, it's very transparent that you're one of the most thoughtful, kind and helpful people that anyone can ever know. And, just for you...

I think Andy said it best..."I wish there was a way to know you're in the good ole days, before you've actually left them."


The Final Paragraph in My Zappos Chapter




A .gitignore file is an important part of any project that is being version controlled.

This post is intended to give you a general idea of the things that I add to my .gitignore. Want to just see [my standard node + mac .gitignore to copy](https://gist.github.com/chaseadamsio/88d5deae496317fb4546)? Check it out along with all my other [github gists for chaseadamsio](https://gist.github.com/chaseadamsio).

**Update:** While talking with Thai Wood about this problem today, we looked around and found a [generator that will create your .gitignore based on IDEs, Operating Systems and Programming Languages](https://gitignore.io/), which is awesome!

## .DS_Store

If you've ever worked on a project with someone who uses their finder to navigate their filesystem, odds are you've seen this ugly file rear it's head.

`.DS_Store` is a _hidden_ file that gets generated whenever someone opens a directory in the finder. It holds metadata about the folder, such as "where the icons should be positioned in the finder" when in the directory. This is useless to anyone other than you, so it's a good file to add to your `.gitignore`.

As a developer, if you navigate your filesystem with Finder, `.DS_Store` files will be generated and modified frequently, so ignoring these is incredibly important (I'd also suggest learning to use the Terminal...it's significantly more powerful and robust for developers).

## node_modules

If you use any language that keeps a project's dependencies inside of the project itself (such as `node_modules` for NodeJS), it's best to add the dependency directory to your .gitignore. You don't want to version control someone else's code in your code. If you're worried about keeping the same versions, you can always use [`npm shrinkwrap`](https://docs.npmjs.com/cli/shrinkwrap).

## Third-party Code

If you happen to use something like bower for things like font-awesome or jQuery or if you just copy/paste third party code into your project, it's best to not version control this stuff either. I've seen bootstrap in version control in a few projects and if you're building your production application with a sensible build tool (and using some kind of dependency manager), you shouldn't ever need to keep any of these external dependencies in version control.

I've been successfully (and happily) using node modules for all of my server and client-side dependencies, so ignoring the `node_modules` directory takes care of this for me as well.

## logs

Your logs are really only useful for _you_ and only useful for _a specific environment_ at _a specific time_, which basically means keeping them in version control is going to cause all kinds of weird merging issues and extra cruft in your project that's not useful.

## Build Directory

If I'm building frontend code using something like Webpack or Gulp, I'll always add `dist` which where I build my static assets, (some people use the `public` directory) to my .gitignore. My rule of thumb is "Is this directory a source of truth or a representation of a source of truth somewhere else in my project?"

For example, if I use sass, it doesn't make sense to version control the css files that are the result of precompiling from the sass files.

## Secret Files

You may have a file with API keys in it (for instance, AWS used to recommend keeping these files in your project and not in your home directory), you should **NEVER** version control anything that has keys or passwords because you're giving the entire world the ability to see those keys...you don't want pictures of sad kittens on your production eCommerce website, so keep these out of your project by adding them to your .gitignore.

Those are the specific files and general types of files I add to my .gitignore file. Ultimately, I think some good general rules of thumb for what to add to a .gitignore are:

- Is this a file (or directory) built from another file that I work on?
- Is this a file that's only relevant specifically to me?
- Is this a file that's possibly going to give away credentials?
- Is this file a result of a command I've run?

I'd say those 4 questions cover 99% of the use cases you'd ever need to consider.

_What things do you add to your .gitignore file that I've missed here?_


A .gitignore file is an important part of any project that is being version controlled. Adding things like node_modules to your git ignored files is essential.

Things Every NodeJS Developer Should Add to Their .gitignore




[As I'm leaving Zappos to go to Walmart Labs](/2015/07/walmart-labs), I've been reflecting on some of the great qualities I appreciated over the years. One of the qualities that comes to mind over and over is the value people put on celebrating employees for their time, effort and work.

In this post, I'm going to highlight 6 ways that have resonated with me most. The crazy thing is, they have nothing to do with compensation and everything to do with **letting people know they're valued**.

![Celebrate Your Employees(/img/celebrate-your-employees.jpg)

## Welcome Them During New Hire Graduation

When you join Zappos, _generally_ you go straight into New Hire Training: a month long endeavour to learn about the company history and get a better grasp on _our_ customer. On the last day of New Hire Training, we have a graduation where Zapponians pack the room, bring noise makers and hoot and holler for the new team members that will join their teams on the following Monday.

When I joined Zappos, I was on a team called "FEZ" (Frontend @ Zappos) and it's customary to give every new FEZZER a FEZ hat. I still have mine and plan on keeping it even though my time with Zappos is over.

I'm not advocating for a month long training course for all new employees, but having a big batch of employees start on the same day of the week/month and welcoming them with a big group of people is a really great first experience.

## Celebrate their anniversary

During New Hire Training, you get a temporary license plate to hang over your desk and Zappos honors your first year by replacing your temporary license plate with a real license plate with your name on it. Most teams will go to lunch to celebrate an anniversary and every anniversary generally comes with some sort of swag. Also...cake. Every anniversary comes with cake and a big shout across the floor: "Hey everybody, it's [fill in the blank]'s 5 year anniversary today!"

## Celebrate their hard work

This may seem like a no brainer, but it's really easy to glaze over celebrating hard work. In my opinion (and in my experience), this isn't done very well at a high level at Zappos, but leadership within my department has always done a great job of celebrating the work we've done.

It makes it a lot easier to get through the muck when you know that the people asking you to do it care.

**Note: Even if the work doesn't result in the high level desired outcome, it doesn't mean the people didn't do the best they could with the tools you gave them, so don't use "they didn't meet the results" as an excuse.**

## Co-worker Bonuses

...because your peers are the people who know who's working hard.

This one is probably my favorite: At Zappos everyone has a \$50 co-worker bonus to award to someone (per month) who's "Wowed" them. You may think to yourself, "that seems gameable!" but I think it's the most under-utilized tool we have. One of my favorite things to do is to give co-worker bonuses to somebody who's pushed hard to wow their team. When I receive them, it's one of the best ways for me to feel validated in the work that I've done.

## Ask them what problems they're facing...and do something about it

I'm getting on a high horse with this one: I've had some really amazing conversations with leadership for my teams and Tech and seen some great changes.

If a leader says, "what's holding you back?" or "what problems are you facing with xyz?" and an employee says, "abc is a problem." **do something about abc.**

## Sprint Awards

My team does two week sprints (which is a "regular, repeatable work cycle") and at the end of every sprint, someone's given the sprint award based on team nominations followed by a vote. We usually get a plush character (in the past we've had Luigi and Bowser, currently we have Stuart the Minion) and the winner gets to keep it on their desk for the sprint.

It might sound kind of silly (and it is because my team is awesome like that) but it's a great reminder that the team appreciates that individual. If you're on a team but you don't have a regular "cycle" for work, you could still have a 2 week celebration where a team member is awarded with a "we love you, you're awesome." award.

![The Stuart Sprint Award](img/stuart-award.jpg)

## A Final Thought on The Weight of Leadership

One major takeaway here is that if you're a leader, your "title" matters for how people are going to receive a lot of these examples. For instance, if you are a CEO and you email an employee to say, "hey, I really appreciate the work you've done" (and mean it), it's probably going to carry a lot more weight than if I (as a peer) did it.

**Even if you're organization is "flat", the more recognized you are as a leader in the organization, the more weight your actions carry.**

_What are some ways you appreciate about how your organization celebrates employees?_


Celebrating your employees can easily one of the best morale boosters for your organization. Here are 5 of the ways Zappos has done that for me.

6 Ways To Celebrate Your Employees The Zappos Way




It was 4:30 AM. I knew I had goals for the morning, but I thought to myself, "checking my work email won't hurt. Surely no one has emailed me between 9 PM last night and this morning." The next thing I knew it was 6:30 AM and I'd spent most of my morning reactively responding to work emails.

_Work_ emails.

That morning I knew it was time to declare a separation of work and life...but I had no idea where to even start.

Fortunately, my buddy Thai, a guy who I've looked to for honing my personal operational rigor, had been dealing with the same problem. That same morning we sat and had coffee on the bistro patio at Zappos and had a conversation about how to create that separation. These solutions are directly or indirectly inspired by my conversation with Thai ([He has an awesome blog about learning ruby](https://thaiwood.io/) and is working on a book about [system adminstration with ruby](https://thaiwood.io/books/ruby-for-system-administrators/)).

## Create A Work Uniform

The first key that almost seemed obvious to creating the separation between work and life was **"create a uniform"**. It didn't have to be a "true" uniform just a token that represented that I was "on", I was at work.

Thai worked as an EMT for a while, and one of the things he had to do was to wear a standard uniform. I could see there was a definite case for having some kind of consistent thing that when you put it on, you're at work and when you take it off, you're in your life.

The funny thing is that Zappos practically hires people because they hate uniforms or rules, which might point to why many of my peers either burn out or work so hard that they're just spinning their wheels.

For me, creating a uniform actually turned out to be pretty simple. I found a [silicone wristband](https://www.reminderband.com/) that I keep in the car and as soon as I get to my parking spot at work, I shoot Jackie a text to let her know I'm in the office and done my silicone wristband. I try to take it off as soon as I get back to my car and at the latest when I get to my driveway.

![usb wristbands](https://ecx.images-amazon.com/images/I/31SJyHRxumL.jpg) If you're in an industry where you use a USB, there are also some cool [USB wristbands](https://www.amazon.com/Wristband-Flash-Memory-Drive-White/dp/B00HSW85V4/ref=pd_sim_147_6?ie=UTF8&refRID=1D1M8X1193AR8Z33V0JH) that could double as a uniform aid and storage solution. I might try this out, because I'm all about minimalist solutions.

An interesting anecdote after practicing "wearing a uniform" for a few weeks: I forgot to take it off one day and I was "tempted" to check my email...and only then did I realize I still had it on! I immediately took it off and forgot to check my email.

## Create A Work Routine

![working from the patio](/img/patio.jpg)

When I get into the office, I have a routine that involves taking the stairs to the second floor to grab a cup of coffee and two bottles of perrier, heading out to the Zappos Cafe patio and writing documentation or working on an internal project and finally making my way up to the 5th floor. I used to do this before team standup (which was at 10 AM), but now that we have a virtual standup (which is going _really_ well), I just try to get to my desk around 10AM instead of just before.

I try really hard not to check my email before 10 AM, so that I can be proactive about the first hour of my day. I find that email is almost always a great way to derail you from the tasks _you've_ decided are important to satisfy someone else's tensions...which keeps you from getting the important stuff done.

At the end of the day, I make some notes about how I spent my day in and how I could have spent it better in [DayOne Journal for Mac](https://dayoneapp.com/). I then shut down all the applications on my work laptop and shut my computer off. I don't turn it on until the next morning when I start my routine over again.

## Timeblocks & Tasklists

I have a set amount of time that I'm willing to work, with buffers on both start and finish and a _reasonable_ list of things I know I need to get done that day. Blocking your time and having a hard limit to how long you'll stay at the office is probably the most important component of all. Being able to create limits is a difficult discipline, but it's one worth doing.

Do I stay late sometimes? Absolutely. A few weeks ago I had to stay well past my normal hard limit four nights a week, but I knew it was coming because of the gravity of the project I was working on. I let Jackie know at the beginning of the week that I was going to be late getting home every night and she was totally fine with it. I'd like to think that it's because I've been better about guarding my time lately.

One last thought on hard limits and breaking them: If you stick to your hard limits, when you do break them, make it count. Choose to stay late for _good_ reasons, otherwise people are going to (both inadvertenly and intentionally) take advantage of that.

## Liberate Your Life From Work

If you've been in the workforce for any period of time, I don't think I need to tell you how hard it can be to separate work and life. It's even harder when you work at a place like Zappos where it's almost expected that they co-exist (happy hours, unofficial events outside of work that may or may not impact how others view your performance, working on "passion" projects on nights and weekends).

If you haven't burnt out already but you're working non-stop, I imagine burn out is close. You don't have to work all the time to be a machine of productivity.

You might be thinking to yourself, "this guy is an idiot, he has no idea what he's talking about." I, myself, have been there. That's okay. I think there are seasons when we just go full-throttle and we can handle burning the candle at both ends (and those are the seasons we should be chasing the hustle). But I'd like to encourage you, that when you do hit your wall, that you come back and revisit these keys for work-life balance and try and implement at least one of them.

_So what about you? Do you have triggers for how to separate your work/life balance? Do you think work/life balance is bunk in the first place? I'd love to hear your thoughts!_


If you haven't burnt out already but you're working non-stop, I imagine burn out is close. These are the steps I took to get my life back.

Separation of Work & Life




As a Frontend Engineer, I feel tied to my work as my trade, as an artisan creating something both finely tuned in its functionality and beautiful in its aesthetics.

Every craftsman or tradesman has a collection of tools that help to make them better at executing their work. If you're beginning your journey as Frontend Engineer, these are the tools I believe you should add to your collection, both generally the types of tools you'll need and the specific tools I use.

Generally, every Frontend Engineer should know what each of these are and why they're important to use:

- Operating System
- Text Editor
- Browser[s]
- Command Line Interface
- Package Manager
- Programming Languages

## Operating System

Your operating system (referred to also as _environment_) is the most foundational tool you'll have. Everything you do stems from the operating system, navigating your file system, editing files, running servers and scripts, all of it happens in the operating system.

There are two types of operating systems you'll use as an engineer:

**Local Opreating System** This is your development environment. All of your development work happens here.

**Remote Operating System** This is any environment meant to be available to the outside world. At the very least it will be your "production environment" where your programs will be available to everyone. You could also have the following:

- **QA Environment** A place to check that your code works, but with mock data.
- **Staging Environment** A place to check that your code works with production data before it's live as production.

### Local Environment

Locally, I use [Mac OS X Yosemite (or the most recent stable OS X version)](https://www.apple.com/osx/), the obvious main reason being that I use a [MacBook Air](https://www.apple.com/macbook-air/).

Mac OS X at a low level emulates very closely the operating system I use in production, which is very advantageous, because the closer you can be between local and production, the less possible things that can go wrong.

This is becoming less and less of an issue with tooling, such as [Docker](https://www.docker.com/) giving developers the power to isolate their code to a container that will be _exactly_ like production, but I still think it's a good thing to keep your environments as close as possible in their low level systems.

### Remote Environment

When you start developing for the web, you'll need to push code to production environments. You'll also probably use `ssh` to access your production environment to make minor changes to your server. For example, I `ssh` into my production server to modify my `nginx` configurations for a/b tests and routing.

I use [Digital Ocean (referral)](https://www.digitalocean.com/?refcode=3b4e0dec66b7) to host my production server, and I use the Dokku droplet, which is an application that allows you to deploy your code using a push to `git` and a recipe of what to do once your code has been received to the `git remote`.

## Text Editor

Your text editor is where you'll spend all your time actually writing code.

I use [Sublime Text 3](https://www.sublimetext.com/3) in `vintage` mode (emulates `vim` keybindings). Sublime Text has a `package control` that allows you to install "plugins" that allow you to be more productive, and I absolutely recommend [installing `package control`](https://packagecontrol.io/installation).

My Favorite Packages:

- Advanced New Package
- BracketHighlighter
- EditorConfig
- Emmet
- Git Gutter
- Pretty JSON

Installing a package, once you've installed `package control`, type `cmd + shift + p` and type `install package`. Hit enter and type the package name you want to install and `Sublime Text` will install it for you. _Note:_ Sometimes you may need to restart `Sublime Text` for a package to work.

Getting started with `Sublime Text`? There's a great tutorial for [the perfect workflow in sublime text](https://code.tutsplus.com/articles/perfect-workflow-in-sublime-text-free-course--net-27293) on the tutsplus network.

If you're using a command line tool, you should setup the shortcut for opening [Sublime Text 3 from the Terminal](https://www.sublimetext.com/docs/2/osx_command_line.html).

## Browsers

Frontend Engineers spend a huge amount of time reconciling issues between browsers (mostly because of Internet Explorer), so it's good to have a suite of them installed.

If you're on a Mac, you should install [Google Chrome](https://www.google.com/chrome/)and [Mozilla Firefox](https://www.mozilla.org/en-US/firefox/new/). Safari comes preinstalled. If you're working for a company that requires Internet Explorer support, I'd suggest using a virtual machine and try out [Miccrosoft's virtual machine's for the version you need](https://dev.modern.ie/tools/vms/).

I spend my actual development time in Chrome because I am very familiar with, and find a lot of power, in their DevTools. For documentation on getting started with DevTools, checkout the [chrome developer guides for DevTools](https://developer.chrome.com/devtools) and for a more indepth look into how to use them, [check out codeschool.com's free discover devtools course](https://discover-devtools.codeschool.com/).

## Command Line Interface

A Command Line Interface can be really daunting to use, and it could be confusing as to why you should use one in the first place.

When you start working with local development, you'll find yourself running servers, creating directories and files, using `git` in your workflow, running scripts, lots of things that will make you productive, but can only really be done in a `Terminal`.

I use [iTerm2](https://www.iterm2.com/), but lots of people use `Terminal.app` which is a core application to Mac OS X.

## Package Manager

Installing new languages and new utilities can be a real pain if you have to do it different ways. Package managers allow you use a common language/syntax and convention for installing all of these.

Thankfully for Mac, there's a utility called [Homebrew](https://brew.sh/) that will allow you to install programs with the same syntax and keep those programs and utilities in a common location.

I also use [npm.js](https://www.npmjs.com/) which is a package manager built with [NodeJS](https://nodejs.org/) for all of my projects.

## Programming Languages

Programming languages are the heart and soul of your work. Without a programming language, your not programming. There are a few that are core to being a Frontend Engineer and a few that I use to make my workflow easier.

### Web Languages

**HTML.** HTML (**H**yper **T**ext **M**arkup **L**anguage) is the language of the web. It's the structure and content of how webpages are created.

**CSS.** CSS (**C**ascading **S**tyle **S**heets) is the language of defining how HTML looks and feels. Everything from font-type, colors, layout, borders and (sometimes) animation is defined using CSS.

**Javascript.** Javascript is the language of defining the functionality of a webpage (and SO much more!). Whenever you interact with a form or see content update on the page "magically", Javascript is the language behind the curtain. Javascript has also made its way into the server, so it can be used to write scripts to be run directly on your computer, run servers and even run databases.

If you're interested in learning the languages of the web, Mozilla Developer Network has great documentation for [HTML](https://developer.mozilla.org/en-US/docs/Web/HTML), [CSS](https://developer.mozilla.org/en-US/docs/Web/CSS) and [Javascript](https://developer.mozilla.org/en-US/docs/Web/javascript).

You can also start learning for free on sites such as [codecademy](https://codecademy.com/), or pay for subscriptions to places such as [codeschool](https://codeschool.com) or [treehouse](https://teamtreehouse.com/).

**Git.** [Git](https://git-scm.com/) is more of a system than a language, but it's one of the most important tools a developer working in a collaborative environment will use. Not to be confused with [github](https://github.com) (which is just _one of many_ places to store your git projects), `git` is a version control system that allows you to keep a history of all the changes you've made on a project over time and merge multiple user's code into a single "source of truth". When paired with a powerful system, such as Dokku, you can leverage a remote server as a way to both keep your version controlled projects and deploy those projects with a single `git push`.

### Other Languages

**GoLang.** I started tinkering with Go because it's fast. It's strongly typed, compiled and has lots of support for creating web servers and for cross-platform functionality. I've built a few small utilities for personal use, but I also really like [Hugo](https://gohugo.io/)(a static site generator) and the [MongoDB Driver for Go](https://labix.org/mgo).

**Markdown.** Markdown is a wonderful way to write in an easy to learn, easy to read, common plain text syntax that is converted into HTML in places like [github.com](https://www.github.com) and by static site generators (and some blog platforms). Most documentation (this blog post included!) is written in Markdown, which makes it a really useful language to learn and use. [GitHub has great documentation on learning the basics](https://help.github.com/articles/markdown-basics/).

**Bash.** Bash is the language of the terminal. A lot of utilities are written in bash, but I generally only use it for my [dotfiles](https://github.com/chaseadamsio/dotfiles), which includes aliases and mini-functions for executing certain things in the terminal.

## The Tools Of The Trade

As a Frontend Engineer, it's important to know why to use certain tools and which tools work best for you. There's no clear cut dogma saying "these are the tools everyone should use", but I believe the ones I've shared are the best tools for me to be most productive.

_Are you a Frontend Engineer? What tools do you find valuable (and why)?_


Every craftsman or tradesman has a collection of tools that help to make them better at executing their work. This is a list of my toolset.

Frontend Engineering Tools of The Trade




If you missed the first "Big News" post from earlier this week, I started [teaching Frontend Engineering for the Iron Yard part time](https://chaseadams.io/2015/06/frontend-engineering-instructor-at-the-iron-yard/). This confused some people, because they thought I was leaving Zappos but didn't understand why I was only leaving to do part-time work.

Starting July 29, I'll be joining [Walmart Labs](https://www.walmartlabs.com/) as a Senior Software Engineer on their Global Products team.

Some reasons I'm super stoked about this opportunity:

**I get to work remote.** Walmart Labs has offices in both Mountain View and San Bruno, California, but the team I'm joining is fully remote, which means I'll be working from home. We'll stay in Vegas for another seaason and in the meantime figure out where we want to go!

**I get to work on technologies I love.** Walmart Labs created my favorite Node Server framework (Hapi) and they're doing an entire rearchitecture of their website around [Hapi](https://www.hapijs.com), [React](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CB4QFjAA&url=http%3A%2F%2Ffacebook.github.io%2Freact%2F&ei=AfOTVff0Bo7GogTI54PYCw&usg=AFQjCNHdWiPEYmXAnso1kFmH1X65GT26Iw&sig2=GqP4LF_1iONti3kG77U-Qw) and [Flux](https://facebook.github.io/flux/) (if these words don't mean anything to you, think Candy, popcorn, cream soda. That's how much I enjoy working in these technologies).

**I get to work for a company who strives to innovate in technology.** Zappos is an interesting place and I believe they want to innovate in a lot of spaces, but technology is not one of them. Walmart Labs has been steadily building better customer experiences, solving interesting problems and contributing to the open-source community heavily. These three things interest me very much.

I'm going to miss my teams at Zappos, and I'll miss the relationships I had the chance to build, but a lot has changed since I started there. I did my part to try and fix the things that felt broken and I at least feel like I gave it my best effort.

More than anything, I'm just incredibly excited for the next season of life: teaching frontend engineering and building stuff that propels the web forward. I couldn't ask for more than that!


As of July 29, I'll be a Senior Software Engineer at Walmart Labs

Part 2: Joining Walmart Labs as Senior Software Engineer




If you have spent any length of time with me, you know that two of the most core principles I hold are **_to pursue growth and learning_** and **_to pursue thy craft_**.

Knowing that about me, it probably comes as no surprise that I've decided to start teaching my craft.

As of tomorrow (June 30, 2015), I start one of two new journeys: I officially join The Iron Yard as a [part-time frontend engineering instructor](https://theironyard.com/courses/part-time/front-end/)!

## Why Teaching?

I've spent so much time investing in personal growth, I felt it was time to invest in other people more _pragmatically_.

I have made a lot of mistakes and learned a lot through trial and error. I can share those learnings in a way that accelerates a student's growth without the headache.

I've always wanted to teach in some capacity, but I've never felt like the public education system was the place for me.

I never thought I'd find the opportunity to teach where the students are there because they want to be and they truly have a stake in their learning. I never thought I'd find a group of people dedicated to uprsuing a craft.

## Why The Iron Yard?

It's simple: they walk the walk. I first met a few of their founders last year and I've kept up with them and their work and it's undeniable that they are focused on creating growth through technology education.

Their mission statement resonates with me very deeply:

> **_"The Iron Yard exists to create exceptional growth and mentorship for people and their ideas through tech-focused education."_** .

When I guest lectured at the Atlanta campus, I _saw_ this mission statement being lived out through the staff.

It felt like the missions statement resonated with everyone I met there as well and that was when I realized that The Iron Yard was the organization they said they wanted to be.

## The Details

I'll be teaching a class twice a week in the evening, three hours per session, for ten weeks, giving new frontend engineers the tools and skillsets they'll need to dive into a full-time course.

Tucked away further into their [About The Iron Yard](https://theironyard.com/about/) page was this little gem:

> Our mission is to find people who want to pursue the craft and life-long adventure of technology, teach them the tools of the trade, and then release them into the world with the drive and capability to make a difference. We believe that passionate, talented people who love what they do will create great families, jobs, companies and solutions to the world’s problems.

I want to help others pursue their craft. I want to teach others the tools of the trade. I want to release a tenacious group of people into the world to create a better version than the one we have.

It's going to be a challenging season but I'm excited to take a group of self-motivated, problem solving learners and give them the best opportunities for growth I can.

I'm grateful The Iron Yard is taking a chance on me to help build engineers who **chase their craft**.


As of tomorrow (June 30, 2015), I officially join The Iron Yard as a part-time frontend engineering instructor.

Joining The Iron Yard as Part-Time Frontend Instructor




Whenever I start a new project, I try to make sure I decide on a good font stack for web safe fonts. I'll usually start at [CSS Font Stack](https://www.cssfontstack.com/).

I like to decide on my font stack based on availability to users and CSS Font Stack has good statistics on what fonts are available at what percentages to windows and mac users.

After I've picked my web safe fonts, I go to [Google Fonts](https://www.google.com/fonts). There's a huge selection of fonts and one of the best features is seeing the size of the assets requested and about how long it will take to request them.

If you can't find what you want there and you know your traffic is going to be low, [Webtype.com](https://www.webtype.com/) has free trials for fonts for 30 days, and a \$20/year plan for sites with less than 10k visits a month.

If you can get away with it, use web safe fonts. Not only will this ensure your users get consistent experiences, but it also minimizes the amount of requests your site is making for extra assets, which means lower pageload times.

Choosing the right fonts for a project for the web may seem easy, but it's always good to make sure you go through the right process of picking fonts that provide consistent experiences.


Whenever I start a new project, I try to make sure I decide on a good font stack for web safe fonts. This is my process.

Choosing Fonts For Web Projects




I've always found the caps lock key to be utterly useless.

Thankfully, the folks at Apple have given Mac users the option of remapping caps lock to a different modifier key.

Open System Preferences (click the Apple in the top left and "System Preferences"). In the second row of preferences click the "Keyboard" icon.

Once in the keyboard pane, click the "Modifier Keys..." button. A new dialogue box will pop up and the first select menu is for **Caps Lock**.

I find the option key to be the most unnatural modifier key of all of them, so I remap my Caps Lock to "Option". In Mac OSX Yosemite there's a "Select keyboard" select menu, so make sure you map it for all of the peripheral keyboards you have listed as well.

You can also just decide to map it to "No Action", but for me this felt wasteful when it could easily replace another key I had a hard time using.

Click "OK" and you're all set!


Learn why and how to remap the Caps Lock key to a more useful modifier key.

Remap Caps Lock to A Useful Modifier Key




When building software in JavaScript, I often need to inspect an array of objects or object of objects.

One of my favorite methods for achieving this is to use `console.table()`. Rather than having to toggle open nested objects that are of the same "type" (in this example we'll use some weird fishes), `console.table()` presents the data in a clean, tabular format. It's available in [NodeJS as of version 10.0.0](https://nodejs.org/api/console.html#console_console_table_tabulardata_properties) and in [almost every major browser](https://developer.mozilla.org/en-US/docs/Web/API/Console/table#Browser_compatibility).

In this tutorial, we'll learn how to use `console.table()` by creating an array of objects and calling `console.table` to inspect the data using NodeJS and Google Chrome.

## Using console.table()

`console.table(tabularData[, properties])` is a method that takes two parameters:

- `tabularData`: a collection of data with any type
- `properties`: an array of strings of the fields you want to use to display the table

## Setup code

First, let's create a file for this example code called `weirdfishes.js` and create an array of weird fishes called `weirdFishes`:

```javascript
let weirdFishes = [
  {
    common_name: "common fangtooth",
    scientific_name: "Anoplogaster cornuta",
    family: "Anoplogastridae",
    wikipedia_link: "https://en.wikipedia.org/wiki/Fangtooth"
  },
  {
    common_name: "vampire squid",
    scientific_name: "Vampyroteuthis infernalis",
    family: "Vampyroteuthidae",
    wikipedia_link: "https://en.wikipedia.org/wiki/Vampire_squid"
  },
  {
    common_name: "blobfish",
    scientific_name: "Psychrolutes marcidus",
    family: "Anoplogastridae",
    wikipedia_link: "https://en.wikipedia.org/wiki/Blobfish"
  },
  {
    common_name: "dumbo octopus",
    scientific_name: "Grimpoteuthis abyssicola",
    family: "Opisthoteuthidae",
    wikipedia_link: "https://en.wikipedia.org/wiki/Grimpoteuthis_abyssicola"
  }
];
```

## Simple call to console.table()

We're going add a call to `console.table()` with `weirdFishes` passed in as the first argument:

```javascript
console.table(weirdFishes);
```

If we call `console.table` with only the first argument, it will display all of the data inside of each object.

## Inspect array of objects in NodeJS

Open your favorite terminal emulator application (I used VS Code's Integrated Terminal for the screenshots) and run `node weirdfishes.js` within the parent directory of `weirdfishes.js`. **Note that this requires nodejs >= v10.0.0)**

When we run the command, the console will display a table like this:

![Output of running console.table on an array of objects in NodeJS](/img/nodejs-console-table.png)

## Inspect array of objects in the Browser (Chrome Example)

The easiest way to see this in action in Chrome is to add the object via the JavaScript console. To open the Javascript console, type `cmd + option + j` and a new pane should pop up at the bottom of the browser window.

Copy the JavaScript snippet from above and paste it into the JavaScript console, press enter and you'll see a table that looks similar to the screenshot below:

![Output of running console.table on an array of objects in Chrome](/img/chrome-console-table.png)

## Constructing the table based on keys

Let's revisit the second parameter mentioned earlier: `properties`—an array of strings representing the values you want to display. Continuing in the browser example in the JavaScript console, call `console.table` with a second argument of `["common_names"]`:

```js
console.table(weirdFishes, ["common_name"]);
```

Calling `console.table` with the second argumend constructs the new table with only the index and the values of the keys in the array:

![Output of running console.table on an array of objects in Chrome with only the common name key](/img/console-table-only-one-key.png)

## Using console.table on an object of objects

`console.table` also works for an object of objects (because an array is a type of object) and the index will be the key for the child objects. You can see an example of this by running `console.table(roleModelsObj)`.

```javascript
let weirdFishes2 = {
  "common fangtooth": {
    scientific_name: "Anoplogaster cornuta",
    family: "Anoplogastridae",
    wikipedia_link: "https://en.wikipedia.org/wiki/Fangtooth"
  },
  "vampire squid": {
    scientific_name: "Vampyroteuthis infernalis",
    family: "Vampyroteuthidae",
    wikipedia_link: "https://en.wikipedia.org/wiki/Vampire_squid"
  },
  blobfish: {
    scientific_name: "Psychrolutes marcidus",
    family: "Anoplogastridae",
    wikipedia_link: "https://en.wikipedia.org/wiki/Blobfish"
  },
  "dumbo octopus": {
    scientific_name: "Grimpoteuthis abyssicola",
    family: "Opisthoteuthidae",
    wikipedia_link: "https://en.wikipedia.org/wiki/Grimpoteuthis_abyssicola"
  }
};
console.table(weirdFishes2);
```

You can see that the table now has the key for each object as the index:

![Output of running console.table on an object of objects in Chrome](/img/console-table-object-of-objects.png)

Now you've got a great alternative to `console.log` for displaying objects in JavaScript in tabular form instead of nested data—an alternative that will save you time in inspection and debugging!


Learn how to inspect an array or object of objects with console.table in the browser.

Inspect a Collection of Objects in Javascript with console.table



This is a handy trick for pushing your code and deploying it with the same command.

In your git repo on your remote server there's a directory called *`hooks`*. Create a new file in hooks called *`post-receive`* and set it as an executable by running **`chmod +x post-receive`**.

Now open post-receive and insert the following code:

```shell
#!/bin/sh

LOGFILE=./post-receive.log

DEPLOYDIR=$DEPLOYDIR # The place to deploy to.

echo -e "[log] Received push request at $( date +%F)" >> $LOGFILE
echo "[log] - Old SHA: $oldrev New SHA: $newrev Branch Name: $refname" >> $LOGFILE
echo "[log] Starting Deploy..." >> $LOGFILE

echo "[log] - Starting code update"
GIT_WORK_TREE="$DEPLOYDIR" git checkout -f
echo "[log] - Finished code update"

echo "[log] - Starting npm install..."
cd "$DEPLOYDIR"; npm install; cd -
echo "[log] - Finished npm install."

echo "[log] - Starting gulp build..."
cd "$DEPLOYDIR"; gulp build; cd -
echo "[log] - Finished gulp build."

echo "[log] - Building Hugo blog..."
cd "$DEPLOYDIR" && hugo
echo "[log] - Finished building hugo blog"

echo "[log] Finished Deploy" >> $LOGFILE
```

A few things to note:


- **`$RCA_THEME_PATH`** is an environment variable set to the absolute path to where I want my repo to checkout the code.
- **The file has to be modified to be executable.** If you don't do this, you're going to be banging your head against your keyboard until you realize you need to.

Now, once you've added your updated code and committed it, when you run **`git push origin master`** (replace *origin* with your remote name), you'll see your code change on your remote server.

## Issues with this technique

For the most part, this technique is a pretty good solution for pushing code and deploying it at the same time. One major drawback is that you have to version control your distribution directory (the compiled code for your js, css and templates), which is not generally considered a good practice.


Learn how to deploy code to a server by using git with post-receive hooks.

Deploy Code with Git Push and a Post Receive Hook




**MacOS Version:** macOS Mojave

_Want to show your Mac's Hard Drive on your desktop instead? Check out my tutorial on how to [show your Mac's Hard Drive on your Desktop.](/2016/12/show-your-macs-hard-drive-on-your-desktop)_

Quick access to your Hard Drive is incredibly useful, especially when you need to browse above your home directory. In this quick MacOS Protip, I’ll guide you through showing the shortcut to your Hard Drive (and other shortcuts) in your Finder sidebar.

## Show Macintosh HD in Finder Sidebar

![Show Macintosh HD in Finder Sidebar](/img/finder-show-mac-hd.gif)

Start by clicking on the Finder icon in your dock, and a new Finder window should come into focus.

In your Finder you should see a sidebar with Favorites and a list of devices. If you don’t see the sidebar, click on **View** in the application menu at the top and then click **Show Sidebar**.

If you don’t see a **Devices** list in your Finder’s sidebar, click on **Finder** in the application menu at the top of the screen, and then **Preferences** in the drop down menu. This will open a new pane called Finder Preferences. Click the Sidebar icon in this pane and it switch to a list of all the possible items you can show in your sidebar.

Under Devices, click the checkbox next to Hard disks and you should now see **Macintosh HD** in your Finder sidebar.

As you can see, you also have the ability to show shared items and other external devices. I hide almost all the Favorites (with exception of Applications, Documents &amp; Downloads), show all the devices and turn on all shared but Back to My Mac.


Learn how to show your Mac's Hard Drive in the Finder Sidebar.

MacOS Protip: Show your Hard Drive in Finder Sidebar

Markdown. I use it daily in writing blog posts, README's or answering questions on [stackoverflow.com](https://www.stackoverflow.com). One undocumented capability of markdown is how to create an image inside an anchor.

This week, I was drafting a post where I wanted to use book covers and have them link to their Amazon product page. I haven't done it before, but I figured, "Hey, this should be simple, I'll check the docs!" 30 minutes after <em>scouring</em> the docs, I realized it wasn't there. So I decided to experiment.

I knew how to create anchors using both inline and reference styles:

```md

[1]: https://www.bower.io
[My Bower Link][1]


[My Bower Link](https://www.bower.io)
```

As well as how to create Images using both inline and reference styles:

```md

[2]: https://bower.io/img/bower-logo.png
![Bower.io: A Frontend Package Manager. logo][2]


![Bower.io: A Frontend Package Manager. logo](https://bower.io/img/bower-logo.png)
```

 So I decided to wrap a referenced image within an referenced anchor, making the image the link content:

```md

[1]: https://www.bower.io

[2]: https://bower.io/img/bower-logo.png


[![Bower.io: A Frontend Package Manager. logo][2]][1]
```

and voila, here's the output:

[<img src="https://bower.io/img/bower-logo.png" alt="Bower.io: A Frontend Package Manager. logo" width="200" />](https://www.bower.io)

If you hover over the Bower bird, you'll see that it is, indeed, a link.

Learn how to create an anchor link on an image in Markdown.

Set An Anchor Link On An Image In Markdown




Grunt has become the build tool/task manager standard for javascript developers and empowered us to take control of our workflows. Better workflows mean better productivity, and Grunt has some great plugins for maximizing that productivity.

I wanted to write a [Javascript cookie manager utility](https://github.com/chaseadamsio/cookiejar), knowing full well that I was reinventing the wheel, so that I could learn how to write better Javascript as well as play with grunt.

I found that when writing any kind of javascript utility or framework, there are a few tasks that I consider standard for my projects: Watching files for changes and running tasks, checking my javascript for code consistency, running functional tests, minifying javascript and a way for the system to alert me when something goes wrong.

_A quick note: All of these tasks leverage minimatch, a 'minimal matching' utility that I highly recommend reading up on if you haven't already:_ [minimatch on GitHub](https://github.com/isaacs/minimatch)

## Grunt Watch: So you can just work

[grunt-contrib-watch on GitHub](https://github.com/gruntjs/grunt-contrib-watch)

I rarely, if ever, create a Grunt file without including watch. Being able to run `grunt watch` and know that I don't need to run my tasks over and over again allows me to shave of huge amounts of time having to context switch between the terminal and my editor.

For my cookie manager utility, this is what my watch task looks like:

Watch is pretty straight forward:

- Give it parameters for files you want to watch.
- Tell it what tasks you want to run.

Your watch task can get pretty complex with options, but I keep mine basic by just enabling livereload (which will refresh my browser automatically).

## JSHint: For Writing Consistent Javascript

[grunt-contrib-jshint on GitHub](https://github.com/gruntjs/grunt-contrib-jshint)

JSHint allows you to write cleaner, more consistent javascript. You can define your project's code standards by creating a `.jshintrc`. As most everything javascript, it's an object with key/value pairs of what standards you want to follow.

Like watch, the jshint task can be pretty simple, just pass it a minimatch array of files you want it to check and you're on your way. One extra option that I didn't show in the example above is the `beforeconcat` and `afterconcat` options. This allows you to run jshint on your source files before and your concatenated files after.

## Mocha: Automated Unit Testing

[grunt-mocha on GitHub](https://github.com/kmiyashiro/grunt-mocha)

Unit testing (or any formal testing for that matter), seems to me to be the most under-utilized tool most front-end developers have. As developers, we could save a lot of time simply by leveraging unit tests to make sure we don't break or regress code we've already written. Thankfully, there are a lot of great testing frameworks out there, and Mocha is the one that I like to use, because it allows you to run client-side unit tests in a headless browser.

_If all of that sounded like white noise, I'd check out Smashing Magazine's [Introdution to Javascript Testing](https://coding.smashingmagazine.com/2012/06/27/introduction-to-javascript-unit-testing/)._

This task is simple (starting to see a pattern here?), you tell it where your test file[s] lives and tell it to use PhantomJS. Badabing, you are now unit testing your javascript!

([Installation instructions for PhantomJS](https://phantomjs.org/download.html))

## Notify:

[grunt-notify on GitHub](https://github.com/dylang/grunt-notify)

I like to tie all of these tasks together with the Notify task. Notify will use whatever system notification application you use (Growl, notify-send, Snarl or OSX Notification Center) to alert you when something is complete or fails.

If you're running jshint or mocha, this is a great tool because it allows you to write your javascript, save your file and continue on without having to confirm everything passed in your terminal.

When something fails, grunt-notify will alert you with a notification that looks like this:

![Growl example of grunt-notify](https://f.cloud.github.com/assets/51505/982676/43c372da-0814-11e3-89e5-0cb0f45f50e1.png)

## Uglify

[grunt-contrib-uglify on GitHub](https://github.com/gruntjs/grunt-contrib-uglify)

The last task I always have in any project I create is the Uglify task. This task allows you to minify and obfuscate your javascript, which basically just means less code to do the same stuff.

I also like to add a banner with the package name, the package version, where the package lives and a timestamp.

## Your Unique Workflow

Not all workflows are created equal, and it's likely that there are far superior workflows to this one out there. This is an example of me learning by doing and finding what works for me.

**What are you doing to be more productive in creating your development projects? Do you have anything you'd add to make this one better?**


Learn about 5 Grunt build tool plugins to optimize your workflow.

5 Grunt Plugins for a Better Workflow




Frontend package management has quickly become a lot more, well...manageable since the release of [Bower](https://www.bower.io) & [Grunt](https://www.gruntjs.com). Here's how I manage frontend dependencies in my projects.

Bower has made it incredibly easy to install frontend packages (such as jQuery, Underscore, Backbone, Angular, the list goes on) and manage updates without the hassle of manually copying and pasting files into your projects or adding git submodules.

To get started using bower and grunt, you'll need to have [Node](https://nodejs.org) and [npm](https://npmjs.org) already installed. Once you have them installed, from your command line, run **`npm install -g bower`**, and let npm take care of pulling it in and setting it up for you. The -g flag is making bower available globally, so you don't have to install it every time.

**For convenience, I've added a working gist that can be cloned to your local box and run: [Gist: Using Grunt and Bower for Frontend Package Management](https://gist.github.com/7369801.git).**

## Harness the Power of Bower

The first thing you'll want to do is run **`bower init`** which will generate your _`bower.json`_ file and add the name, version, authors, license and ignore properties. This is also where all of your package definitions will be so when you pull this project down on a different computer or work with someone else, they can install all of the packages with one command.

Now that Bower is installed and initialized, let's setup our project's bower configuration. I don't like the name _`bower_components`_ for the directory we're going to store it in, so create a file called _`.bowerrc`_ in the root of your project's path, and add the following options:

```json
{
  "directory": "src/_lib",
  "json": "bower.json"
}
```

We're overwriting the default directory of _`bower_components`_ and defining the name of the package manifest.

### Installing Our Packages

In the project example, we'd like to use a few frontend packages:

- font-awesome
- underscore
- jquery
- requirejs

If we want to find a package, for example font-awesome, but we don't know the name, we can run **`bower search font-awesome`**, which will return a list of results. Looks like the package we want is called 'font-awesome', so the next thing we can do is run **`bower install font-awesome --save`**. This command will pull down the font-awesome package into _`src/_lib`_ and make it ready for us to use. If you take a peek into your _`bower.json`_ file, you'll see that the command also added font-awesome to your json file, so that it is now available for anyone else who uses your project to pull all the dependencies in with **`bower install`**.

Run **`bower install underscore --save`**, for each dependency until you've installed them all.

## Workflow Using Grunt

I am a huge proponent of using [Grunt as a build tool](/2013/11/07/using-grunt-for-a-better-workflow/), especially for frontend, so it only makes sense that we'd use it here!

One of the "downsides" of package management with Bower is that it pulls in a lot of extra cruft, all the tests, configuration files, README.md files, anything that's in version control, and when we're developing, we don't need all of it, so we can use Grunt to build only the files we need into our target directory.

Once you've gone through the steps to add **uglify** &amp; **copy** grunt-contrib plugins, add options to your Gruntfile.js grunt config:

```js
var pkgjson = require('./package.json');

var config = {
  pkg: pkgjson,
  app: 'src',
  dist: 'dist'
}

module.exports = function (grunt) {

  // Configuration
  grunt.initConfig({
    config: config,
    pkg: config.pkg,
    bower: grunt.file.readJSON('./.bowerrc'),
    copy: {
      dist: {
       files: [{
         expand: true,
         cwd: '<%= config.app %>/_lib/font-awesome',
         src: 'css/font-awesome.min.css',
         dest: '<%= config.dist %>'
       },
       {
         expand: true,
         cwd: '<%= config.app %>/_lib/font-awesome',
         src: 'fonts/*',
         dest: '<%= config.dist %>'
       }]
      }
    },
    uglify: {
      options: {
        banner: '/*! <%= pkg.name %> lib - v<%= pkg.version %> -' +
          '<%= grunt.template.today("yyyy-mm-dd") %> */'
      },
      dist: {
        files: {
          '<%= config.dist %>/js/lib.min.js': [
            '<%= bower.directory %>/jquery/jquery.js',
            '<%= bower.directory %>/underscore/underscore.js',
            '<%= bower.directory %>/requirejs/require.js',
          ]
        }
      }
    }
  });

  grunt.loadNpmTasks('grunt-contrib-copy');
  grunt.loadNpmTasks('grunt-contrib-uglify');

  grunt.registerTask('default', [
    'copy',
    'uglify'
  ]);
};
```

This Gruntfile will only be running a few tasks, but they're really convenient from a frontend development workflow:

- Copy Font-Awesome's minified css file into a _/css_ directory in our target.
- Copy Font-Awesome's fonts into a _/fonts_ directory in our target.
- Create a minified _`lib.min.js`_ of all of the javascript dependencies we have with a banner and place it in a _/js_ directory in our target.

When you run **`grunt`**, your dependencies will be put where they need to go and minified, so when you build, you can rest easy you don't have to manually add packages, and as you upgrade your dependencies, grunt will still continue to upgrade your target version of them whenever you run it.

## Last Steps

In my _`.gitignore`_, I add the following directories: _`dist`_ &amp; _`src/_lib`_ (or whatever your bower directories name is). There's a lot of debate about whether or not to version control your dependencies, and I tend to fall on the side of not doing it. For me, I don't have a good reason to version control something that's already version controlled, so it keeps my projects a little lighter.

**If you decide to start using Grunt and Bower, let me know, and show me how you did it! Seeing something you think isn't so great in my workflow? I'd be interested to hear other's opinions on good practices.**


Learn how to use grunt and bower for a frontend workflow

How I Use Grunt And Bower for Frontend Packages




Grunt is a NodeJS task runner that allows you to automate all the things! I use it to speed up my development workflow and enhancing the performance of my projects.

## 2 Years: A Sour Memory

It's Thursday. I've just started a front-end project that needs to be done...tomorrow. I've started a new WordPress site for a client that we needed to churn out quickly, so I open up Coda, start to manually scaffold out a theme, manually create my php and html files, manually start to add CSS, then I flip over to my browser, hit the refresh button and watch the page reload.

Fast forward to the next day, and I'm cleaning up code, trying to make files smaller (and doing an awful job) and I finally wrap it up, and manually drag files into ftp in Coda, then manually sanity the site and call it a day.

### And then I found Grunt.

As I'm writing this post, I've got Chrome open in the background and SublimeText 3 open taking half of the screen. I save my file and watch chrome magically update to my most recent markdown file's changes.

**This is just one advantage of Grunt**.

Grunt has become one of those things in life where you didn't realize just how badly you needed it until you start using it and thinking, _"what have I been doing with my life?"_

By automating all the things I used to have to manually do, I make more time to do more things, and ultimately make more time to focus on the important things while Grunt takes care of the trivially mundane.

## Advantages to Using Grunt

- It has a huge library of plugins to automate almost anything you can think of, the community on a whole is using Grunt for all of their projects (jQuery, twitter, Modernizr) which leads to contributing, which leads to more plugins, which, as you guessed, leads to greater adoption.
- Easy to get up and running and lots of documentation.
- Options are passed in as Javascript objects, which is nice for front-end developers
- Robust enough that you can use it for any kind of tasks, but minimal enough that it's not bloated unless you need it to be.

## Getting Started

**I've added all of these code samples to a github gist, you can clone done the repo, and run the commands as you read rather than having to write out the examples yourself if it's more convenient.**

Project gist: [Grunt: Up &amp; Running](https://gist.github.com/chaseadamsio/7354446/)

Grunt has a few dependencies that you'll need to have installed:

- [NodeJS >=0.8.8](https://nodejs.org/)
- npm (comes with the Node package)

From anywhere within your terminal run:

```shell
npm install -g grunt-cli
```

This is going to install the module for the command line tool globally (-g) so you can run _`grunt`_ anywhere on your machine and it will know what you're referencing.

### package.json

Next, in your project's root, you'll need to create a _`package.json`_ (run **`npm init`** in your project) and a _`Gruntfile.js`_. The package.json file is a NodeJS file that tells Node about all the attributes of your project and the different Node modules your project will depend on.

Here's my sample _`package.json`_:

```json
{
  "name": "chaseadamsio",
  "version": "1.0.24",
  "description": "Yeoman / Grunt workflow for realchaseadams",
  "dependencies": {},
  "devDependencies": {
    "grunt": "~0.4.1",
    "grunt-contrib-jshint": "~0.5.2",
    "grunt-contrib-uglify": "~0.2.0",
    "grunt-contrib-watch": "~0.5.3"
 },
  "engines": {
    "node": ">=0.8.0"
  }
}
```

After you've created your _`package.json`_, you'll need to run **`npm install`**, which is going to install grunt, jshint and uglify (any dependencies you specify in your _`package.json`_).

### Gruntfile.js

The final piece of the Grunt puzzle is to create your _`Gruntfile.js`_.

In it we're going to have it run two tasks:

- **lint or javascript**
- **uglify it if there aren't any errors**

We'll create a default task and add the options to the **`initConfig`**:

```js
'use strict';
var packagejson = require('./package.json');

module.exports = function (grunt) {

  // Configuration
  grunt.initConfig({
    pkg: packagejson,
    watch: {
      scripts: {
        files: ['<%= pkg.name %>.js'],
        tasks: ['default']
      }
    },
    jshint: {
      build: [
        '<%= pkg.name %>.js'
      ]
    },
    uglify: {
      options: {
        banner: '/*! <%= pkg.name %> - v<%= pkg.version %> - ' +
        '<%= grunt.template.today("yyyy-mm-dd") %> */'
      },
      build: {
        src: '<%= pkg.name %>.js',
        dest: 'build/<%= pkg.name %>.min.js'
      }
    }
  });

  grunt.registerTask('default', [
    'jshint',
    'uglify'
  ]);

  grunt.loadNpmTasks('grunt-contrib-jshint');
  grunt.loadNpmTasks('grunt-contrib-uglify');
  grunt.loadNpmTasks('grunt-contrib-watch');
};
```

In our Gruntfile, we've very basically told it for jshint, we want to lint the javascript file _`script.js`_, the path being relative to the Gruntfile's location.

After that we want to use uglify to compress and minify our javascript file for performance, and add a banner with the project's name, the version and the date (useful for debugging).

At the very least for running **`grunt`** to work, you have to:

- **`registerTask`** of **default** and add the tasks you want to run
- **`loadNpmTasks`** of all the tasks that are in your configuration object.

The only thing we need to do for this to work is to add a _`script.js`_ to your project give it some javascript to execute. Here's a sample js file just for convenience:

```js
(function() {
  var foo = "hello ",
      bar = "world!";

  console.log(foo + bar);
})();
```

Now that we have everything setup, , and you can switch back to your terminal and run **`grunt`** from anywhere in your project (I always run it from the project root just to be safe), and grunt will run jshint and uglify on your script with the package name!

Having to run **`grunt`** every time you make a change can be a real hassle, so for convenience to almost every project I use, I add the **`grunt-contrib-watch`** task, so let's go ahead and add it as a task:

```shell
npm install grunt-contrib-watch --save-dev
```

When you do this as **`--save-dev`** it will add it to your developer dependencies in your _`package.json`_ file, which will help you out in the long run, especially if you want other people to use your project. If you don't pass in the flag to save as a dependency, when someone else pulls down your project and tries to work with it, they'll have to manually install **node modules** and most likely give up on your project.

Updated _`package.json`_ after saving dev dependency for watch:

```js
{
  "name": "chaseadamsio",
  "version": "1.0.24",
  "description": "Yeoman / Grunt workflow for realchaseadams",
  "dependencies": {},
  "devDependencies": {
    "grunt": "~0.4.1",
    "grunt-contrib-jshint": "~0.5.2",
    "grunt-contrib-uglify": "~0.2.0",
    "grunt-contrib-watch": "~0.5.3"
 },
  "engines": {
    "node": ">=0.8.0"
  }
}
```

### Updating Grunt

Now that we have the ability to watch files, we can add it to our _`Gruntfile.js`_:

```js
'use strict';
var packagejson = require('./package.json');

module.exports = function (grunt) {

  // Configuration
  grunt.initConfig({
    pkg: packagejson,
    watch: {
      scripts: {
        files: ['<%= pkg.name %>.js'],
        tasks: ['default']
      }
    },
    jshint: {
      build: [
        '<%= pkg.name %>.js'
      ]
    },
    uglify: {
      options: {
        banner: '/*! <%= pkg.name %> - v<%= pkg.version %> - ' +
        '<%= grunt.template.today("yyyy-mm-dd") %> */'
      },
      build: {
        src: '<%= pkg.name %>.js',
        dest: 'build/<%= pkg.name %>.min.js'
      }
    }
  });

  grunt.registerTask('default', [
    'jshint',
    'uglify'
  ]);

  grunt.loadNpmTasks('grunt-contrib-jshint');
  grunt.loadNpmTasks('grunt-contrib-uglify');
  grunt.loadNpmTasks('grunt-contrib-watch');
};
```

With an updated file, we can simply run **`grunt watch`** from our terminal, update our javascript file, and watch as it magically runs our tasks everytime we save!

**If you're using Grunt, let me know what you like/don't like about it, or some of the really useful plugins you've found! I'll be adding posts every month about the plugins that I find useful for my workflow.**


Learn how to use Grunt for a better workflow.

Using Grunt For A Better Workflow




If you're tired of sharing code snippets for other people to look at or collaborate on via [github.com](https://www.github.com), [gist.com](https://www.gist.github.com) or worse, dropbox or email, check out these three great code collaboration tools.

Collaborating on code is one of the most vital tools a developer can leverage.

We solve problems best by having a fresh set of eyes join in and talking through our solutions. Our code matures faster through having stronger developers give input. We learn more clearly by having tangible examples both in the code itself and in it's execution.

If you are like me, at one point in time the best option you thought you had was to email it. Eventually you probably learned about github.com and gist, where you could share code people could pull down locally. Unfortunately, all of these solutions are expensive to the person on the other side in both time and work.

Now frontend development is getting major contributions from both the community and companies like Google and Mozilla to help speed up our workflow. From the community, we have 3 great tools for sharing code snippets that show the code and it's execution:

- **Codepen.io** for mocking presentational ideas with HTML &amp; CSS
- **JSFiddle.net** for javascript interaction with the presentation layer
- **JSBin.com** for javascript interaction and the data/event layer

## codepen.io

[codepen.io (link)](https://www.codepen.io)

![Codepen.io](https://www.realchaseadams.com/imgs/2014/01/codepenio-1024x633.png) [Codepen Example](https://codepen.io/realchaseadams/pen/wLcse)

### What I use it for: Mocking Presentational Ideas with HTML and CSS

Codepen.io is yet another great idea from [Chris Coyier](https://chriscoyier.net/). Three of the main benefits of using it that really stand out to me are:

- It's easy to browse other people's pens for inspiration
- Forking other people's pens
- The options for HTML, CSS &amp; JS are incredibly robust

I generally use it when I've got **HTML** and/or **CSS** ideas I want to quickly share and I think someone else that I want to collaborate with will want to edit it in their own fork to share back with me.

The language options are awesome. For HTML, you get the option of using HTML, markdown, slim or jade and adding classes to the html or adding meta data to the head. For CSS, you get sass (both .sass and .scss), less and stylus. **These features alone, in my opinion, make this code collaboration tool king for presentational concepts.**

## jsfiddle.net

[jsfiddle.net (link)](https://www.jsfiddle.net)

![jsfiddle.net](https://www.realchaseadams.com/imgs/2014/01/jsfiddle-1024x633.png) [JSFiddle Example](https://jsfiddle.net/rfwEP/)

### What I use it for: Javascript Interaction with the Presentation Layer

At the office when we're talking about abstract concepts in javascript, fiddles get passed around a lot. We used JSFiddle for training our intern and it was a great way for him to do work and show us his progress.

You can save versions of your fiddle to share, which was great for us to give him a problem set and then have solutions in a different version for him to go to when he completed his solutions.

It also has a collaboration feature (which is in beta), so if you want to have multiple people in a fiddle working on it, it's the ideal feature!

## jsbin.com

[jsbin.com (link)](https://www.jsbin.com)

![jsbin.com](https://www.realchaseadams.com/imgs/2014/01/jsbin-1024x633.png) [JSBin Example](https://jsbin.com/UWuwiyi/1/edit)

![jsbin.com](https://www.realchaseadams.com/imgs/2014/01/jsbin2-1024x633.png) [JSBin Date Example](https://jsbin.com/UWuwiyi/2/edit)

### What I use it for: Javascript that focuses on data

Sometimes you need to be able to see what's under the hood when you're working with javascript. JSBin allows you to have a console (that's not your browser console), that can be run and viewed easily.

If you're working on any javascript that isn't modifying the interaction layer, you need to make sure that it's functioning as you expect and JSBin is a great tool for doing that.

**Do you know of any good sources for collaboration that other developers should know about? If so, share them!**


I help startups navigate the complexity of building human-centric software.

What I'm Writing