
**Dataview** is easily one of the most powerful plugins for [[Obsidian]].

One of my favorite ways to use **Dataview** is to get all of the files that are linked to the current file.

This lets the user embed linked mentions _in_ the document instead of having to use the "Linked Mentions" section of the Obsidian UI.

using the `dataview` tag:

```javascript
dv.list(
dv.pages(`[[${this.currentFilePath}]]`)
	.map(page => [page.file.link]))
```

The Result:
![[Pasted image 20220725165120.png|Screenshot of Obsidian using dataviewjs to get all file links]]


This is helpful if you don't need to see where the file is mentioned and instead just want to see an overview of all the files that link to it.

Get all links to the current file with Obsidian and Dataview


This is a collection built up over time of queries I use and find helpful.

# Document Arrays

Find any documents where key `smartEvents` exist and has an array length that's greater than 0:

```
{smartEvents: { $exists: true, $not: { $size: 0 } } }
```

Find any subdocuments of `governs` and an array key for `groups` where `groups` contains an `ObjectID` of `622b8fe0968213000946ee1e`

```
{"governs.groups":{ $in: [ObjectId('622b8fe0968213000946ee1e')]}}
```

### $elemMatch
`$elemMatch` is a useful operator for when you want to search an array of subdocuments where a field contains a value. In this example, `responses` is an array with a document that has a field of `content`:

```
{responses: {$elemMatch: {"content": {$regex:"Maybe tolerances could"}}}}
```

Also note `$regex` in the query above. This operator lets you search for a regular expression (or a plain string) within a value. This is useful when you don't want to search the whole value of a property in a document.

MongoDB Useful Queries


I often find myself needing to find a conversation that happened on a specific date in Slack but can't remember keywords from the conversation or who all was in the conversation.

**Here are two quick ways to find a conversation in Slack based on a known date or date range.** 

## Jump to date via UI

I can usually remember _around_ the time something happened (or use GitHub merge information) and I'll want to find a conversation that happened in Slack around it.

There's an easy way to **Jump to date** within a channel or direct message:

- Open the channel or direct message where you want to jump to date
- Find _any_ date in the channel or direct message
- Click it
- Select **Jump to a specific date**
- This will give you a date picker
- Select the date (or around the date) you want

![Jump to a specific date in Slack](/img/Pasted%20image%2020220725171217.png)


## Search all messages in all channels or direct messages by range

If you can't quite remember which channel or specific day a conversation happened but remember it happened within a range, you can use Slack's **Search feature**.

Let's say you remember you had a conversation in the first week of July of 2022.

- select the search bar in the top of the Slack UI
- type `after:2022-07-01 before:2022-07-05` and hit enter

This will return all results _after_ July 1st and _before_ July 5th.

Two quick ways to find a conversation in Slack based on a known date or date range.

Find messages in Slack based on a date or date range


Over the weekend I figured out how to integrate my Obsidian vault with Dropbox and publish my Dropbox files. 

Any Obsidian document with `type: Post` and `status: Published` in the Markdown's YAML Frontmatter will be published to my website's posts. 

# Why this workflow?
I wanted to achieve a few things with this workflow:
- Ease of writing (write in Obsidian)
- Keep all my thoughts in one place
- Ease of publishing 
- Use a file system (Dropbox) that has an API so I can publish as a part of my build

I've been using Obsidian for the past year and have lots of thoughts captured in it. I have been publishing posts from Dropbox but from a different folder that I had to edit in VS Code instead of Obsidian. 

This left my fledgling notes disconnected from the articles I would post. 

# What's next?
I'd also like to create some new collection types to publish other than posts. 

I'd like to start publishing my favorite hikes, climbs, gear and apps. I'd also like to start publishing my fledgling notes and snippets. 

I've got over 2,000 files at the time of writing in my Obsidian vault and a lot of them could benefit other people in some way. 

**This post was written and published from my iPhone using Obsidian and redeploying Vercel!**

### what's missing?
- I'm not pulling images from my Obsidian vault yet
- Remark doesn't parse Obsidian image links
- Mentioned links that aren't public will 404 (instead of just removing the link)

How I use Obsidian, Dropbox and Vercel to write and publish my website

Publishing my website from Obsidian files


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 `DyanmicKey`. 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 `conole.log` the `myDynamicObject` object, I would see:

```js
{
	"unicorns are": "awesome sauce",
	DyanmicKey: "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


Most of what I want people to know can be found in my personal [[Principles]]

# When you can find me at work...

_Times are in Pacific Time_

-   Ideal day **starts at 9AM and ends at 5PM on a weekday** so I can have some intentional quality time with my family before (6AM-9AM) and after (5PM-8:30PM) work.
-   I carve out 30 minutes at the beginning and end of each day to make sure I set myself up for success. Usually that means I'm offline during those periods creating/refining my daily plan or documenting the day.

# If you need something from me...

-   **Slack is the _best_ way** to successfully get a response from me. I try to be prompt in responding to people in Slack as long as it's during my normal day.
-   **Email is the worst** **way** to get in touch with me.

# The best way to give me feedback...

-   **as soon as you see a red flag, let me know.** I don't want any potential frustrations to fester and boil up into something worse later.
-   **I prefer getting/giving feedback face-to-face** (in a Zoom meeting) but if it's "minor" feedback I'm happy to discuss it over Slack.
-   **sharing examples of how/what I could do better/different** goes a long way in helping me be successful in being a better team mate.

# Things I need...

-   **clearly defined vision.** If you want to unleash me on a project, give me the vision.
-   **autonomy to make decisions.**
-   **my work purpose aligns with my life purpose.**

# I love...

-   **my family.** They will always be a driving force behind how I make decisions about my career, never the other way around.
-   **interacting and collaborating with others.**

# I find energy in...

-   **building things for people who build things.**
-   **teaching others skills** that will enable them to be more effective.
-   **finding and reducing toil** helping define and optimize work streams & processes.
-   **automating the drudgery!**
-   **trying out new things.**

# I struggle with...

-   **selling products that I don't believe in.** I feel uncomfortable pitching a product the team is building that's not ready or something that feels gimmicky rather than purposeful.
-   **unnecessary chaos.** I embrace intentional chaos that helps to build resiliency. I do not like chaos that's created "organically" because there was no effort in creating order.
-   **silos.** It's important for me that people are able to work with the least amount of friction.

# What I expect of my teammates...

-   **Be human.** We're in this experience together and I know my expectations are just that: expectations. I'm human. You're human. Let's be humans, acknowledge we're humans and act accordingly.
-   **Be honest.** I want to know the reality of a situation, not what someone thinks I might want to hear to not be upset.
-   **Be kind.** This is caring about people enough to have hard conversations (rather than skirting around them) but tempering those conversations with love and grace.
-   **See the best in me.** It's easy for me to feel an overwhelming fear that I'm not good enough for the work I'm doing, but I'm a hard worker who will strive to give it my all.

# What my team mates can expect from me...

-   All of the points listed in the **What I expect of my team mates...** section.
-   I will always **investigate before I initiate** on projects, tasks or conversations. I want to make sure I understand something before starting work on it so that I can make awesome things.

# Why does he...

-   **Why does he use a ✅(or a 👍) on so many of my Slack messages?** I like to make sure I mark things I've seen and know I've either done some action on _or_ marked as seen so that the sender knows that I've seen it. I find a lot of times that I ask "has `<INSERT NAME>` seen/read this yet?" I imagine if I think that, others probably think the same for me, so I want to give clarity that I've seen something or it's been resolved/completed if it's a task

A guide to what it's like working with me. Things I need, things I love, where I find energy, what I struggle with.

User Guide


I'm slowly refining my principles (I'm not really sure if they're principles or philosophies). This is what I have so far.

## Spend career capital on others.

As I build career capital and influence within the organizations I belong to, I want to use that capital and influence by spending it on those who have been denied it unjustly so that they can excel. The only way the work I do and the actions I take matter is if I do it with the intent of helping to raise others up.

## Live life as a vector: forward with velocity

In everything, find the next right thing and try it. Keep moving forward. Maintain velocity. It may not be the _right_ thing, but it's at least a thing to try. If you try it and it's wrong, it's still _right_ because you know you need to pivot. The important thing is that you're constantly finding what's next and _doing it_.

## If it's safe to try, let it fly.

When things are safe to try, try them. I won't let excuses or objections or blocking "what if"s be the things that hold me back.

## Be clear, not clever.

“Clever code” and “clever language” often creates confusion. Choosing to be clear emphasizes that the value is in the message, not in the implementation.

## Enough is best.

More isn’t better. Less isn’t better. Enough is best. There’s power in saying exactly what needs to be said or doing exactly what needs to be done. It doesn’t mean that I should “settle” for what’s in front of me. It does mean that I should know exactly what needs to be done and to do it the best that I can. If I could have added more, make that the next objective and stay on task. It means only removing that which can be removed without sacrificing exactly what’s meant to be said.

## Hope is not a strategy. Be prepared.

Every day comes with new circumstances and new challenges. Hoping for every day to go well is not a strategy. The strategy is to always be aware of the challenges I've faced in the past and the challenges I'm likely to experience in the future and prepare for how to handle them. _**Plan for Chaos, Strive for Order.**_

## Context, context, context.

Context gives our experiences and ideas purpose. Always provide context when presenting ideas or feelings or experiences, without it, they're just data points.

## do. document. distribute. automate.

Strive to do work that can only be done once. It’s deep work.

If it can be done, but must be done more than once, start with documenting the process. Understanding something well enough to document it creates a stronger context.

If it’s a process that can be documented but can’t yet be automated, distribute: teach others how to do it, leveraging the documentation. Sharing the toil makes room for the task to be automated so that the toil can be eliminated altogether.

Finally, automate the task, and start over at "do that which can only be done once". Automating allows all who toiled to then focus on deep work.

## It’s a good day for a good day.

It’s easy to allow negative outcomes or undesired circumstances to passively guide me into feeling that it was a bad day. Choosing that today is a good day for a good day and focusing on the wins of the day and the positive outcomes allows me to own the day, to be an active accelerant in my own success.

## See the best in people, even when they can't.

On hard days, it can be difficult to see the best in people. On their easy days it can be hard for them to see the best in themselves. Choosing to see the best in people gives me an opportunity to expand my perspective and help others realize their potential, even when they can't realize it themselves.

## Daily a Learner, Daily a Teacher.

Every day learn something new. Every day share something new with someone else. Knowledge and understanding spread like wildfire when there is a constant desire to create a cycle of learning and sharing.

## Not doing something is worse than doing it poorly
^a35dc5

This is especially true where it comes to writing things down. There needs to be a counter-balance principle that is "reflect on how a thing was done".

Principles


[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 Roundup


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


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


At Webflow we've started practicing SRE escape rooms: an SRE escape room designer creates some form of chaos in our acceptance environment and a group of SREs get to figure out how to get acceptance back into a healthy state.

It's been a great way for us to reinforce what we know and learn to keep our systems healthy.

If I ever get around to finishing this, this article will address:

- A more in depth explanation of what an SRE escape room is (similar to what some teams call "game day")
- A few examples of what we've done
- What the science says about spaced repetition for learning


SRE Escape Rooms and Reinforced Learning


I often find myself wanting to use changes that I've made for an NPM dependency in a personal fork. 

NPM (and yarn) have a useful convention for pointing to a git repository instead in a project's `package.json` `dependencies` by pointing to the fork and optionally using a specific branch instead of giving it a version number.

Here's how to set that up in a `package.json` for SSH and HTTPS. This example uses the `isomorphic-fetch` package.


Convention for a basic configuration for a package using git:

```
git+{protocol}://{user}@{hostname}:{project owner}/{project}.git#{branch name}
```

- protocol can be `ssh` or `https`.
- user and hostname for logging in via `git`. Usually the user is `git`, especially for github.com and gitlab.com
- project owner is either an organization or user
- project is the repo
- branch name (optional) is the branch you want to work off of

## Install NPM dependency from GitHub via SSH

Following the example, a basic version composition for SSH looks like this:

```
git+ssh://git@github.com:matthew-andrews/isomorphic-fetch.git
```

By branch:

```
git+ssh://git@github.com:matthew-andrews/isomorphic-fetch.git#some-branch
```

## Install NPM dependency from GitHub via HTTPS

Following the example, a basic version composition for HTTPS looks like this:

```
git+https://git@github.com:matthew-andrews/isomorphic-fetch.git
```

By branch:

```
git+https://git@github.com:matthew-andrews/isomorphic-fetch.git#some-branch
```

## Example in the package.json

This is what the JSON would look like for `dependencies` in `package.json`:

```json
{
    "dependencies": {
        "isomorphic-fetch": "git@github.com:matthew-andrews/isomorphic-fetch.git"
    }
}
```


How to set up an NPM dependency from a GitHub URL in a package.json for SSH and HTTPS.

Install NPM Dependency From GitHub URL


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


Curious George is one of our favorite bedtime routine reading characters. If you're unfamiliar with Curious George, he's a monkey that lives with a man with the yellow hat and is a representation of a toddler: affectionate, kind and...curious!

In all of the situations, George is constantly in discovery mode, which often results in a "big mess". The adults would scold him for making a mess, followed by them praising him if there was a positive side effect of the mess. These big messes never end in physical harm or safety issues, rather, they're an inconvenience to the adults (something almost always needs to be cleaned up).

My takeaways from this as a parent:

- In my experience as an adult, I constantly find myself wanting to maintain order, often at the expense of my daughter learning through experiences that would often end in a "big mess". I'm trying to be more aware of this and be okay with messiness, especially if it's an opportunity for her to grow.
- As an adult, I can also provide "bumpers" as often as possible for my daughter to experiment safely and when things feel like they're about to get messy, let it play out and not be upset about the mess.
- Curiosity is an important ingredient of play and growth. I believe this about myself as an adult and believe it to be true for children. My responsibility as a parent is to nurture and provide space for my daughter to be curious.

My takeaways from this as a parent for other parents:

- Wouldn't it be neat if there was a way to create "inserts" for existing curious george books to help parents/adults think about how they can think through the experience to encourage the exploratory nature of kids?
- Wouldn't it also be neat if there was supplementary incident analysis inserts to go along with Curous George books? "what actions/assumptions/expectations led to the incident?", "how did george feel when he got in trouble?", "why did the adults scold george?", "what could they have done differently to nurture his exploratory nature?"

My takeaways from this as a working professional in software (especially in developer experience):

- Are there ways for me to help my organization grow through allowing individuals/teams to be curious without them feeling the fear of making a "big mess"?
- Are there bumpers I can provide to make it easier for others to experiment safely, so that they can grow, the organization can grow and the things they do to keep a mess from getting big?

When discussing with my wife about how the adults scolded George when he messed up, she asked "does it bother you that Curious George (the show) is that way?" My response was: "I actually think this is exactly how it should be because it models reality for both the exploratory nature of kids and how adults generally to try to maintain order. I just wish there was a better resource to help adults learn from Curious George too."

I'm using this as an opportunity to grow myself into being better at supporting my daughter (and myself) to experiment and grow through curiosity without being afraid of the mess!

This post is brought to you from the takeaways of a Slack conversation with my good friend Dave Cadwallader.


Lessons for Adults from Curious George


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 surging 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 for 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 for 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 for 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




## Goal

After learning about three concepts: **union types**, **type refinement** and **disjoint unions**, you'll be able to use type refinement to create functions that are flexible and powerful while also keeping your code safe from footguns[^footguns].

We're going to start with a basic vanilla JavaScript example in order to understand how Flow can help us write code that can allows us to maintain the flexibility of JavaScript while still giving us safety with types.

In this example, we're going to write a simple function called `say` that:

- takes a string that is one of 4 types of animal: `"Dog"`, `"Cat"`, `"Cow"` and `"Horse"`
- executes a `console.log` with the noise that animal makes
- have a default for "I'm not a farm animal!" if someone passes a value we didn't prepare for

```js
const say = animal => {
    switch (animal) {
    case "Dog":
        console.log("woof!");
        break;
    case "Cat":
        console.log("meow.");
        break;
    case "Cow":
        console.log("moooooooo");
        break;
    case "Horse":
        console.log("nay-hay-hay-hay-hay!!!");
        break;
    default:
        console.log("I'm not a farm animal!");
    }
};

say("Dog"); // prints "woof!"
say("Cat"); // prints "meow."
say("Cow"); // prints "moooooooo"
say("Horse"); // prints "nay-hay-hay-hay-hay!!!"
say("Human"); // prints "I'm not a farm animal!"
```

As you can see, all of our animals are saying what we want them to.

Does the `switch(animal)` pattern above look familiar? You probably have some code that you've written recently that does a check for the value of a variable and do something unique based on it. This is the un-typed version of **type refinement**.

**Type refinement** is the ability to determine what to do based on the value a statement receives. If the value of `animal` is `"Dog"`, `console.log("woof!")`.

As you can see above, our "farm" only has 4 types of animals and we have a catch-all for if someone passes an animal that we don't have in our farm. We only want to do something if we receive one of those 4 types, and we want to let the caller know that we don't support other types of values to be passed to our `say` function.

Type refinement is possible because of the second concept we're going to explore: **union types**.

## Union Types

Before we implement Flow in our project, let's talk about **union types**.

Remember how we wanted to only take one of 4 types of animals and nothing more? That's achieved through **union types**.

We'll define a type for `Animal` that is a union type of "Dog", "Cat", "Cow" and "Horse":

```js
type Animal = "Dog" | "Cat" | "Cow" | "Horse";
```

As you can see, a union type is a single type that can be of any type joined by the pipe (`|`) character. It's also not restricted to strings, as we'll see in the last section.

Now any statement that takes an argument that is of type `Animal` can *only* be called with one of those 4 values. Flow will error (as we'll see in the next section) if the caller passes a value to the function that doesn't match one of those types.

## Implementing Flow

Equipped with our knew found knowledge of union types and our `Animal` type, we need to implement Flow in our file.

In order to do this we need to:

1. Add the `// @flow` pragma so Flow knows to check the file
2. Create a union type for `Animal`
3. Type `say` to take `animal` as type `Animal`

```js
// @flow
type Animal = "Dog" | "Cat" | "Cow" | "Horse";

const say = (animal: Animal) => {
    switch (animal) {
    case "Dog":
        console.log("woof!");
        break;
    case "Cat":
        console.log("meow.");
        break;
    case "Cow":
        console.log("moooooooo");
        break;
    case "Horse":
        console.log("nay-hay-hay-hay-hay!!!");
        break;
    default:
        console.log("I'm not a farm animal!");
    }
};

say("Dog"); // Works! => prints "woof!"
say("Cat"); // Works! => prints "meow."
say("Cow"); // Works! => prints "moooooooo"
say("Horse"); // Works! => prints "nay-hay-hay-hay-hay!!!"
say("Human"); // Error!
```

Now if we run `npx flow`, we get an error about the call of `say("Human")`:

```
Error ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ index.js:27:5

Cannot call say with "Human" bound to animal because string [1] is incompatible with enum [2].

    [2]  4│ const say = (animal: Animal) => {
        :
        24│ say("Cat");
        25│ say("Cow");
        26│ say("Horse");
    [1] 27│ say("Human");
        28│



Found 1 error
```

Now we've made it impossible to pass a value that's not in our union type! This also let's us clean up our code by allowing us to remove the following from our switch statement:

```js
    default:
          console.log("I'm not a farm animal!");
```

This `say` function is coming a long pretty smoothly and we're making progress on making it only do what we want it to, but the current implementation leaves room for mistakes.

After a year of not touching this code, someone comes along and accidentally changes the switch statement so that `"Dog"` says `"meow."` and `"Cat"` says `"woof!"`, that's no good and what's worse: our type system isn't helping us catch that a Dog should *only* woof and a Cat should *only* meow:

```js
// @flow
type Animal = "Dog" | "Cat" | "Cow" | "Horse";

const say = (animal: Animal) => {
    switch (animal) {
    case "Dog":
        console.log("meow.");
        break;
    case "Cat":
        console.log("woof!");
        break;
    case "Cow":
        console.log("moooooooo");
        break;
    case "Horse":
        console.log("nay-hay-hay-hay-hay!!!");
        break;
    }
};

say("Dog"); // Works! (but it's wrong) => prints "meow."
say("Cat"); // Works! => (but it's wrong) prints "woof!"
say("Cow"); // Works! => prints "moooooooo"
say("Horse"); // Works! => prints "nay-hay-hay-hay-hay!!!"
say("Human"); // Error!
```

Let's take a trip back a year and revisit our initial writing of this function. Instead of taking a string, let's make Animal a union of objects with a `type` and a unique function per type based on the noise the animal makes:

```js
// @flow

type SayFn = () => void

type Animal =
    | {| type: "Dog", bark: SayFn |}
    | {| type: "Cat", purr: SayFn |}
    | {| type: "Cow", moo: SayFn |}
    | {| type: "Horse", neigh: SayFn |};
```

It's important to notice that every animal has a unique function name, because we're going to call it based on the type so that the **type refinement** can catch the future mixup.

Let's rewrite the `say` function to look like this:

```js
const say = (animal: Animal) => {
    switch (animal.type) {
    case "Dog":
        animal.bark();
        break;
    case "Cat":
        animal.purr();
        break;
    case "Cow":
        animal.moo();
        break;
    case "Horse":
        animal.neigh();
        break;
    }
};
```

We made a few changes:

- we switch on `animal.type` instead of `animal` (previously a string)
- we call a unique function for each type instead of a `console.log`

This brings us to our final concept: **disjoint unions**.

`Animal` now has a `type` key that has a *unique* value (Flow docs call this a "tagged property") as it's type so that it can be easily distinguished by the type checker. It is a **disjoint union** because it has a tagged property of `type` and Flow knows that if the tagged property matches the value, it should use the object defined in the union.

Now let's fast-forward to the point that the developer mixed up the code for `"Dog"` and `"Cat"`, the change would be the following:

```js
const say = (animal: Animal) => {
    switch (animal.type) {
    case "Dog":
        animal.purr();
        break;
    case "Cat":
        animal.bark();
        break;
    case "Cow":
        animal.moo();
        break;
    case "Horse":
        animal.neigh();
        break;
    }
};

say({ type: "Dog", bark: () => console.log("woof!") });
say({ type: "Cat", purr: () => console.log("meow.") });
say({ type: "Cow", moo: () => console.log("MOOOO") });
say({ type: "Horse", neigh: () => console.log("NAY-HAY-HAY-HAY-HAY!!!") });
say({ type: "Human", neigh: () => console.log("I don't belong here.") });
```

When we run `yarn flow` we get the following error:

```
Error ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ index.js:12:14

Cannot call animal.purr because property purr is missing in object type [1].

    [1]  9│ const say = (animal: Animal) => {
        10│   switch (animal.type) {
        11│     case "Dog":
        12│       animal.purr();
        13│       break;
        14│     case "Cat":
        15│       animal.bark();


Error ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ index.js:15:14

Cannot call animal.bark because property bark is missing in object type [1].

    [1]  9│ const say = (animal: Animal) => {
        10│   switch (animal.type) {
        11│     case "Dog":
        12│       animal.purr();
        13│       break;
        14│     case "Cat":
        15│       animal.bark();
        16│       break;
        17│     case "Cow":
        18│       animal.moo();



Found 2 errors
```

And Flow has kept us from making a party foul and making our animals say the wrong thing!

Even if the developer came along and changed the say calls to this so that it'd "work":

```js
say({ type: "Dog", purr: () => console.log("woof!") });
say({ type: "Cat", bark: () => console.log("meow.") });
```

Running `yarn flow` would give us an error like this:

```
Error ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ index.js:29:5

Cannot call say with object literal bound to animal because:
    • property bark is missing in object type [1] but exists in object literal [2].
    • property purr is missing in object literal [2] but exists in object type [1].

    [1]  5│   | {| type: "Cat", purr: () => void |}
        :
        26│ };
        27│
        28│ say({ type: "Dog", purr: () => console.log("woof!") });
    [2] 29│ say({ type: "Cat", bark: () => console.log("meow.") });
        30│ say({ type: "Cow", moo: () => console.log("MOOOO") });
        31│ say({ type: "Horse", neigh: () => console.log("NAY-HAY-HAY-HAY-HAY!!!") });
```

Letting us know that an object with the type `"Cat"` should have a `purr` property and that `bark` isn't a part of the `"Cat"` type definition.

## Acknowledgements

Thanks to [Lily Scott (Suchipi)](https://github.com/suchipi) for helping me understand these concepts better and teaching me a lot of new things about Flow!

## Pior Art

- ["Making Impossible States Impossible" by Richard Feldman - YouTube](https://www.youtube.com/watch?v=IcgmSRJHu_8)
- [Designing with types: Making illegal states unrepresentable | F# for fun and profit](https://fsharpforfunandprofit.com/posts/designing-with-types-making-illegal-states-unrepresentable/)

[^footgun]: Functionality added to a product or tool that results in the person shooting themselves in the foot with it. [Wiktionary entry](https://en.wiktionary.org/wiki/footgun)


Learn how to use disjoint unions in Flow for more powerful type refinement.

Using Flow's type refinement for powerful, flexible, safer code


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 through File Associations




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.
gg

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.

Book Review - Making Work Visible



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,
> 
> I love building software you know, 
> 
> and I'm happy to say, that there's no better way, 
> 
> 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 (at 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-hard-drive-in-finder-sidebar-macos|Show Your Mac's 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




This year, I'm picking 3 Words to act as targets for 2016.

_My 3 Words_, originated in 2006 by Chris Brogan, is an alternative paradigm to creating New Year's resolutions. In his 2013 post, Chris explains how _My 3 Words_ fits into your life planning:

- The big story.
- Vision.
- Goals.
- Plans and Milestones.
- The daily calendar.

~ [My 3 words for 2013 — chrisbrogan.com](https://chrisbrogan.com/my-3-words-for-2013/)

Essentially, rather than creating reactive, rigid (and often myopic) resolutions, pick 3 words that help move your life story forward.

The concept of _My 3 Words_ resonates deeply with me for a few reasons:

- **Proactive.** Often New Year's resolutions are picked due to a _current_ dissatisfaction (often to do with health or fitness and because someone ate too much stuffing and pie). My 3 Words takes the _big picture_ into consideration.
- **Flexibility.** New Year's resolutions are often too rigid (not to be confused with _rigour_), which is the main cause of most broken resolutions.
- **Encompassing.** New Year's resolutions often only focus on specific areas. _My 3 Words_ creates space for application in any and all areas of life.
- **Forgiving.** Missing a day in a resolution, breaks that resolution. _My 3 Words_, because of its flexibility and ability to apply in any area of life, only requires awareness of the day's activities through the lens of the 3 words.

What I appreciate most about the practice of picking 3 Words is that it makes them easy to remember, easy to gut check and easy to reason about...**and easy is the major catalyst for follow-through**.

## My 3 Words for 2016

So, 2016, here are my 3 words:

- Discovery
- Systematic
- Rigour

Below I've outlined what they mean, why they're important to me, and specific action items.

### Discovery

_the act of finding or learning something for the first time._

We live in an incredible age: Accessibility to _everything_ has never been so abundant. I feel a great deal of excitement in discovering new things, people, places, ideas and processes. Even more exciting is discovering new aspects in what I already know!

- seeking out new adventures
- knowing God more
- knowing myself more
- knowing Jackie more
- learning new processes, systems and skills
- finding new places

### Systematic

_done or acting according to a fixed plan or system; methodical._

I've found that the tasks and areas of life I'm most successful in are the ones where I understand, fully, what they mean, how they relate to me and how to act. Creating processes for repeatable tasks and then either (1) documenting them or (2) automating them will allow me to be prepared to pivot in the case that I need to. **In structure, there is freedom.**

- discovering personal processes that make me effective
- everything has a place and in its place
- documentation
- automation of those things that can be automated

### Rigour

_the quality of being extremely thorough, exhaustive, or accurate._

In software, I've noticed the difference between a moderate engineer and an excellent engineer is that an excellent engineer reviews their own code. They may take a little longer to turn out a feature or a bugfix (this often isn't true, but I'm giving the moderate engineer the benefit of the doubt), but those features and bugfixes are rarely, if ever, revisited. They're accurate because they were exhaustively considered.

Moderate engineers can get the job done, but often do so by sacrificing being thorough, which leads to someone else fixing the same problem down the line, with little knowledge of how it was fixed originally.

In all areas of life, I want to be an "excellent engineer".

- triple checking
- understanding things more deeply and fully
- opt for prudence & excellence over momentum
- consider all tangents, contingencies and angles

## A Final Thought: Know Your Destination

I'm excited to see how this thought experiment guides the next year, but I believe it will only have value because I've spent some time ["beginning with the end in mind"](https://chaseadams.io/2013/10/my-eulogy/), a habit outlined by Steven Covey. _If you're considering the **My 3 Words** exercise, I recommend first starting with knowing (and documenting) the end you have in mind._

Your "end" may change a little along the way, but having a point of reference is an important component of being able to pick the right words to be most effective in your journey.

_Did you pick 3 Words this year? If so, I'd love to know what they are!_


My 3 Words for 2016: Discovery, Rigour, Systematic

My 3 Words - 2016




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.

Files 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.

Celebrate Your Employees


As much as I enjoyed working on and using my standing desk, it wasn't built for full-day usage (it wasn't as stable as I need for programming 6+ hours a day). I told Jackie I wanted to look at desks since I'll be working from home for Walmart Labs full time, so we started the quest for the right desk.

We both have high standards for how a desk should look and we both really like the rustic industrial style, so we set out to find something inexpensive (less than $500) and stylish. Just like with the quest for the right standing desk...nothing.

So, in our typical semi-bespoke style, we put together a plan to build a desk on our own!

Here's how we built this beautiful sitting desk and the best part about it? It only took us about **20 minutes to assemble**.

![Full Front View of Desk](/img/minimal-task-desk/full-front-desk.jpg)

## Parts

- [28" Raw Steel .375 Diameter 3 Rod Hairpin Leg ($20/leg)](https://www.hairpinlegs.com/products/3-rod-hairpin-leg?variant=1125171392)
- [74" x 1-1/2" KARLBY Countertop, Walnut ($189.00)](https://www.ikea.com/us/en/catalog/products/10301149/#/30301148)
- [Everbilt #10 x 1" Flat Head Phillips Wood Screws](https://www.homedepot.com/p/Everbilt-10-x-1-in-Zinc-Plated-Flat-Head-Phillips-Drive-Wood-Screw-100-Piece-801882/204275500)
- [3M Knob Adjust Keyboard Tray, Standard Platform, Gel Wrist Rest, Precise Mouse Pad, 17 in Track, Black](https://www.amazon.com/gp/product/B001B0DCOO/ref=as_li_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=B001B0DCOO&linkCode=as2&tag=thechasceperb-20&linkId=XYJLDXHUAVDOJ24F)

## Building the Desk

**Note**: Make sure to _not accidentally drill through the table top!_

**Flip the table!** Put the table top upside down on a soft surface (carpet) and make sure you leave plenty of space around the table top so you can move around it easily.

**Pre-drill the holes.** One thing my dad taught me a long time ago was pre-drill holes. It'll keep wood from splintering or splitting and make it a lot easier to drill the screws in. I measured so that the leg measured 1-1/4" from the edges and held the leg while Jackie marked where the holes needed to be pre-drilled. We pre-drilled three holes for all four legs.

**Attach the legs with fasteners.** Align the legs over the holes and drill the screws into the pre-drilled holes.

**Pre-drill holes for the 3M Keyboard Tray Mount.** Place the tray 1-1/4" away from the front edge of the desk. I measured from both side edges to make sure the mount is exactly the same distance from each edge. Mark the holes on the mounting with a marker, remove the tray and pre-drill the holes.

**Attach the 3M Keyboard Tray Mount.** Place the tray back over the pre-drilled holes and attach the mount to the desk.

**Assemble the Tray.** Follow the instructions to assemble the tray to the mount.

**Attach the Powerstrip.** My good friend Brandon Murry asked on my last project how I was planning on hiding all the power cords, so I tried to be more concious of it this time. I mounted the powerstrip to the bottom of the desk and used a combination of [mug hooks](https://www.amazon.com/ARROW-160376-Hooks-Rubbed-Bronze/dp/B00VEDF6I8/ref=sr_1_3?ie=UTF8&qid=1436750212&sr=8-3&keywords=mug+hooks) and [3m cord clip cable organizers](ttp://www.amazon.com/gp/product/B00M9FN2KY/ref=as_li_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=B00M9FN2KY&linkCode=as2&tag=thechasceperb-20&linkId=UIFHXUV6OHQCWYXW) which made the cables "virtually" invisible without you crawl under the desk. Even if you crawl under the desk, they look a lot better than they did with the standing desk.

The most "involved" part of building this desk is assembling the tray for the keyboard, but we were still able to put it all together in under 30 minutes.

## Finished Task Desk

### Full View of Desk

![Full View of Desk](/img/minimal-task-desk/full-desk.jpg)

### Full View of Hairpin Leg

![Full View of Hairpin Leg](/img/minimal-task-desk/legs.jpg)

### Attached Hairpin Leg to Desk Top

![Attached hairpin leg to desk top](/img/minimal-task-desk/attached-leg.jpg)

### Attached Tray

![Attached tray to desk top](/img/minimal-task-desk/attached-tray.jpg)

### Attached Powerstrip

![Attached power strip to desk top](/img/minimal-task-desk/power-strip.jpg)

_Have you built a desk like this? If so, be sure to share photos!_


A minimalist task desk for under $300 and built in under 30 minutes.

Rustic Industrial Minimalist Task Desk


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

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




You know that annoying pop, pop, pop noise your sound adjustment makes when you adjust the sound on your Mac? There's a really easy way to adjust your audio without the computer making it.

Just use **Shift + Audio Key**. The Shift Key temporarily disables the pop.

**Update for Mac OSX Yosemite**

In OSX Yosemite, they've reversed the functionality so that adjusting the volume of your computer with the volue buttons is silent and to hear the click you have to use the Shift key.

If you liked the feedback click without the Shift key, you can revert the settings to pre Yosemite settings by opening _System Preferences_, clicking on _Sound_ in the second row, and selecting _"Play feedback when volume is changed"_.


Silently Adjust The Volume On Your Mac




[_The Sketchnote Handbook_](https://www.amazon.com/gp/product/0321857895) by [Mike Rohde](https://rohdesign.com/) was one of the most important (and impactful) books I read this year. It's a book about learning to consume spoken word (visual language and caching ideas) and how to convert the information into memorable, impressive, visual "sketchnotes".

Created by the guy who illustrated one of my all-time favorite books, [_ReWork_](https://www.amazon.com/Rework-Jason-Fried/dp/0307463745), [_The Sketchnote Handbook_](https://www.amazon.com/gp/product/0321857895) is an illustrated guide about how to take notes visually.

It's the ultimate guide for information Hackers who want to retain and revisit information that's important and relevant to you.

Here's a short Youtube video [Mike made explaining Sketchnotes](https://www.youtube.com/watch?v=6SKQsULasTg):

## The Unboxing Was Awesome

It's very rare that I get a book in the mail and spend the first 10 minutes admiring the cover, thumbing through pages, while enjoying both the feel of the paper _and_ the beautifully crafted pages.

The first thing I realized (and I expected) was that this book was not like any other book on using visual language to convey ideas. It was chock full of low-level explanations on layout styles, font styles, processing information and other super useful concepts, but Mike took it up a notch by **practicing the very concepts he was encouraging the reader to learn**.

Every page was visually stunning.

## So Much Illustration

There wasn't a single page that was printed text (the SKU on the back cover is the only place I could find that didn't use Mike's handrolled fonts). Every page was intentional in layout and design and Mike left me spending minutes on each page turn just soaking up the content of the pages.

When I put the book down after my first read, I walked away **retaining concepts such as types of sketchnotes, active listening, hierarchy and personalization**.

The amount of topics Mike covers in [_The Sketchnote Handbook_](https://www.amazon.com/gp/product/0321857895) is uncanny. Just to list a few:

- The 5 Basic Elements of Drawing
- How to Listen
- Drawing People, Faces & Type
- Structure/Anatomy and Patterns of a Note
- Penmanship
- Key Hacks for Awesome Sketchnotes (The Process)

I have spent a few days over the course of the last few months after reading [_The Sketchnote Handbook_](https://www.amazon.com/gp/product/0321857895) revisiting the content, and I have to say, it's become my go to guide for any time I want to leverage the power of visual note taking.

![Sketchnote Handbook Simple Drawings Example](https://www.realchaseadams.com/imgs/2014/10/sketchnotehandbook-simple-drawings.jpg)

Throughout the book, Mike did an amazing job of always making sure the reader has examples to use as a springboard for trying their hand at the exercise or topic at hand.

My only feedback is that I would've liked to have seen the entire alphabet for Drawing Type Exercises. He gives the first three letters of the alphabet (a, b, c) in lowercase and uppercase format, but the complexity of creating a triple-line letter for the letter "R" or "Q" would have been a lot easier with an illustration to follow.

One of the really cool things that happened for me after reading [_The Sketchnote Handbook_](https://www.amazon.com/gp/product/0321857895) and applying the concepts to my notetaking was that people were interested in seeing my notes afterwards. I'd taken this new found skill and turned it into a way to help others where the way I would've taken notes (or not taken notes at all) before barely even helped me.

I also wanted to revisit my notes, thumbing through the pages of my notebook to look at the work I'd done and remember the experience from whatever I had taken notes from.

I could see Sketchnoting (and using this book) being taught to students at a young age, to encourage them to take notes visually (the way that we process information) as an alternative to the traditional way students are taught to take notes. I'm a huge proponent for giving students a resource for them to enjoy learning, retain concepts and ideas more and feel like they can take notes visually without the possibility of "getting in trouble" (if you were a doodler in school, you've experienced this unfortunate consequence of doodling).

## The Takeaway

This book absolutely deserves to grace your shelf.

I believe we all have the capacity to draw (Mike can prove that through his book and a few minutes of your time) and if you are in a position where you grow through learning information, then you need the concepts in this book to catapult your ability to retain and your desire to revisit that information.

## Who It's For

Anyone who takes notes, wants to take notes or does anything involving learning or growth.

This includes students, anyone who goes to meetings, church goers, conference goers or people who watch [TED Talks](/2014/02/whats-your-lollipop-moment/)...pretty much anyone who is growing, or trying to grow, through taking in information from an external source.

## How to Buy It

You should buy the [paperback copy of _The Sketchnote Handbook_](https://www.amazon.com/gp/product/0321857895), rather than the [kindle version](https://www.amazon.com/Sketchnote-Handbook-Illustrated-Visual-Taking-ebook/dp/B00E981K1W/ref=tmm_kin_title_0?_encoding=UTF8&sr=&qid=), for a few reasons:

- The artwork is stunning and deserves to be appreciated
- There's space to practice your exercises
- A lot of time and effort went into the layout and organization of the physical copy of [_The Sketchnote Handbook_](https://www.amazon.com/gp/product/0321857895)
- You can share the physical copy with peers much more easily

If you decide to buy the kindle version, at least consider also buying the paperback version, even if only to become a strong edition to your coffee table collection.

Mike has some really phenomenal sketchnote examples on his [flickr](https://www.flickr.com/photos/rohdesign/) and [instagram](https://instagram.com/rohdesign) accounts and he's one of the most [responsive/engaging authors I've encountered on twitter](https://twitter.com/rohdesign). You can find [blog posts and more sketchnotes at rohdesign.com](https://rohdesign.com/).

All outbound product links are to [Amazon.com](https://www.amazon.com). There are no affiliate links on this page.


The Sketchnote Handbook is one of the few books I believe everyone should own and revisit often. It's the definitive guide on how to take notes visually, think laterally and pick the right takeaways from a message, talk or meeting.

Book Review - Sketchnote Handbook




**Update:** I've decided to switch to a [minimalist rustic industrial sitting task desk](/2015/07/minimalist-task-desk), be sure to check it out (it's less expensive, more sturdy and took only 30 minutes to put together).

![Full Front View of Desk](/img/minimal-task-desk/full-front-desk.jpg)

This weekend I decided to build a standing desk. It was a lot of work, but with a little time, a little intuition, a few trips to Home Depot and a couple of setbacks, I am now writing this post from my rustic industrial standing desk!

Hopefully this detailed summary and retrospective will be enough inspiration and documentation for you to go and build your own.

![Rustic standing desk](/img/rustic-standing-desk/final-desk.jpg)

## A Good Desk Is Hard To Find

If you've ever done research online to find a desk, you've probably been exactly where my wife, Jackie, and I have been: lost.

There are a lot of desks out there, but finding one both parties can agree on is hard, and finding one that's in a store for you to look at makes it nearly impossible. Throw into the mix that I have started standing to do work, which means I'd like a standing desk, and you have yourself a Herculean task.

After hours (spanned over the course of 2 weeks) of doing research and finding no good solutions for under $1500, on a whim, Jackie and I decided Saturday morning to just build our own standing desk.

What follows is the process of going from a mere idea to a tangible desk, a retrospective of what I learned (and some gotchas) and some thoughts on what I would have done differently.

## The Idea

This project started as all good weekend warrior projects start: **A trip through Google Image Results and Pinterest.**

Jackie has been into the rustic industrial look lately, and as I'm a huge fan of wood and metal, rustic industrial was the easy decision.

The desk we found that we liked best as a starting reference was the [Postobello Industrial Metal And Rustic Wood Desk](https://www.custommade.com/postobello-industrial-metal-and-rustic-wood-desk/by/mortise-and-tenon-custom-furniture/): a _sitting_ desk ($945). What stood out was the minimalist look (no drawers or frills), the dark metal on the bottom and the rustic wood. The major modification we had to the idea itself was to use pipes.

I looked around the internet for a little bit longer and stumbled [onto a DIY tutorial on rustic pipe workbench](https://diyready.com/rustic-furniture-tutorial-workbench-plans-diy-pipe-leg-table/). This was exactly what I needed to get an idea of where to start.

## The Sketch

The first thing I did was figure out what the height needed to be so the desk would be at a 90 degree angle to my elbows while standing. For me, it was around 44".

After sketching it out, I figured out that I'd need certain pieces, and I was adding up the lengths of all the pipes to make sure I had the _exact_ right lengths.

**I'd suggest not doing it this way.** Once you've figured out the types of pieces you need, just go down to the building supply (Home Depot in my case), and start piecing stuff together to make sure that, with an extra 3.5" (taking into account the height of your runner boards and top boards), the pipes will give you a good 90 degree angle at your elbow.

I ended up having to redo my math while I was in Home Depot anyways, so it would've saved me a lot of time to just go down there and physically put together a single leg for testing.

## The Pre-Build

I made a material list in Excel based on the sketch and a cursory look at [homedepot.com](https://www.homedepot.com). This helped me come up with a good estimate for about how much it would cost. The Raw Materials list below is the _final_ material list, and this list came in about $50 under my original estimate, mostly because I ended up getting black iron pipe where I'd originally estimated galvanized steel pipe.

### Raw Materials

| Count | Material | Length |
|:---------:|---------|---------:|
| 3   | 2 x 6 #2 & Better Douglas Fir Lumber (cut to 66")                        | 8'    |
| 1   | 2 x 4 Premium Kiln-Dried Whitewood Stud (cut to 3 30" pieces)                      | 96"   |
| 1   | #8 x 2-1/2 in. Phillips Bugle-Head Coarse Thread Sharp Point Drywall Screws | 1 lb. Pack |
| 1   | MinWax 8 oz. Oil-Based Espresso Wood Finish Interior Stain    | -     |
| 1   | Varathane 1-qt. Matte Soft Touch Polyurethane                 | -     |
| 2   | PRO GRADE PRECISION 2-1/2 in. x 4 in. x 1 in. 120 Grit Fine Block Sanding Sponge | -   |
| 8   | 1 / 2" Black Iron Floor Flange                                  | —     |
| 8   | 3 / 4" Black Malleable Iron Threaded Tee                        | —     |
| 8   | 3 / 4" x 1 / 2" Black Malleable Iron FPT x FPT Reducing Coupling  | —     |
| 8   | 1 / 2" Close Black Steel Nipple                                 | —     |
| 4   | 3 / 4" Black Steel Nipple                                       |  2"   |
| 4   | 3 / 4" Black Steel Nipple                                       |  6"   |
| 4   | 3 / 4" Black Steel Nipple                                       |  12"  |
| 4   | 3 / 4" Black Steel Nipple                                       |  24"  |

I suggest going to your [local building material supplier (yes, I'm promoting my family's building supply company)](https://www.coferadams.com) if they carry all of this stuff, but I ended up at Home Depot because it was the closest supplier I could find.

## The Build

I decided to start with the processes that could be done synchronously with the lumber to make sure I minimized the build time, so the first step was to **sand the 6 pieces of lumber to a really smooth finish.**

### Sanding the Lumber

Sanding is an important part of the process for a few reasons. It will create a smooth surface, but more importantly, it opens the pores of the lumber and removes a surface glaze left by the mill's saw blades. A good sanding session made the lumber more receptive to the stain and left a richer finish.

### Staining the Lumber

![Rustic standing desk](/img/rustic-standing-desk/planks-1.jpg")

After sanding, I wiped the boards with a cloth just to make sure all the sawdust particles were removed and laid my first coat of stain. I started with my 30" pieces, since they were going to be under the desk and less visible, just to make sure I liked the color.

I let the stain rest for about 15 minutes and then wiped it off with two dry clothes, making sure to remove any residual stain that hadn't soaked. If I'd let it sit without wiping, it would've left dark droplets and pools of stain, which can make the wood look super janky.

I was really impressed with the color, so I followed the same process for the 2 x 6 boards, making sure to stain the top, the ends and the sides. I followed the same time (15 minutes) before wiping. These boards came out looking even better than the 2 x 4 pieces had.

**Note:** I only stained the exposed parts of the wood, so the center piece didn't get stain on the sides and the bottom runners didn't get stain on the side that was drilled down to the 2 x 6 pieces.

### Assembling the Legs

While I let the stain soak and dry, I started on the pipe assembly. On my first trip (there were _so many_ trips to Home Depot over the weekend), I picked up Galvanized pipes, primer and black Rustoleum paint for metal.

**DO NOT DO THIS.** There are a few good reasons I should've just gotten black pipes since I wanted them to be black in the end anyways:

- The process of preparing galvanized pipes for painting is a nightmare (based on what I've read online). Essentially the process of galvanizing adds a coat of zinc, which paint will just roll right off of.
- The whole point of galvanized metal is to help it standup to the elements. My officespace at home has never, and hopefully will never, have the problem of needing to stand up to elements.
- **Black pipe is cheaper anyways.** I ended up saving around $50-$60 exchanging my galvanized pipe for black pipe, so it was worth it in price alone.

#### Cleaning

![Rustic standing desk](/img/rustic-standing-desk/legs-1.jpg)

Once I'd gotten my black pipes, it was time to clean them. Getting stickers off of metal is kind of tricky. We had a hard time getting the tape that was wrapped around the pipe off, so I put my pipes in the back of the car (in Vegas it was kind of hot, so in the car it was really hot) for about an hour. When I pulled them out and peeled the tape, it came right off. Lesson learned: **Just heat tape and stickers for easier removal.**

I used [Goo Gone](https://www.homedepot.com/p/Goo-Gone-24-oz-Pro-Power-Spray-Gel-5011484/202329108) to remove any of the residual sticker, which made short work of cleaning the 12 pipes that had something on them.

#### Assembly

![Rustic standing desk legs](/img/rustic-standing-desk/legs-2.jpg)

After drying my pipes, it was time for assembly of the legs. I couldn't find any 3 / 4" floor flanges in black at my local Home Depot, so I modified my configuration a little bit and bought 1 / 2" (I would've gone with 1" if they'd had those) floor flanges, a 1 / 2" close to connect to the flange and a reducing coupling to connect the 3 / 4" pipe to the 1 / 2" close.

That seemed like it would've cost more than a 3 / 4" floor flange itself, but the price pretty much evened out, and it gave it a unique look instead of just going straight from the pipe to the floor flange.

Next, I assembled the feet and the "heads" of the legs with the metal Tees. I tightened everything down with a monkey wrench because I wanted to make sure if there was going to be any instability or rocking, it didn't happen because I didn't do my due diligence to tighten everything down.

I then connected the horizontal bar between the feet, but didn't tighten it down all the way. I added the 24" vertical bars and attached the heads via the Tees to the 24" bars and my legs were one step away from being complete.

**This is where I hit my first assembly snag.**

I wanted everything to be connected tightly, but because of the way the threads work, I couldn't tighten the top horizontal bar all the way. If I tightened it all the way on one side of the Tee, it would, by nature of physics, loosen it from the other side.

So I tightened it down as best as I could by hand to one Tee, placed the pipe's end in the receiving end of the other Tee where I knew it would thread right away, and _loosened_ the pipe from the Tee I'd tightened it into. The end result was a _mostly_ tightened horizontal bar, which was the best I could've asked for under the circumstances.

### Re-Staining

![Standing desk planks](/img/rustic-standing-desk/planks-3.jpg)

Once my legs were complete, it was time for another coat of stain. I followed the same process of staining I followed for the first run. I didn't stain the sides of the middle board that sat on the top of the desk because I knew I was going to use wood filler.

After two coats of stain, it was time to add the varnish. I varnished all sides of each piece 2 times, with a 3-4 hour dry time between each run.

Once my second coat of varnish had dried, it was time to assemble the desk.

### Assembling the Entire Desk

I started by pre-drilling holes into the 2 x 4 runners on top of the 2 x 6 pieces. Pre-drilling holes helps to minimize the possibility of the wood splitting when screwing the pieces together.

I used a drill bit that was a little wider than the thread of my screws. The outside 2 x 4 runners were 2-3 / 4" away from the short edge of the desk and 1" away from the frontand back of the desk. The center 2 x 4 runner was fastened with it's center at 33" (the center of the desk on the long edge).

I used drywall screws instead of wood screws because they're less likely to split your lumber, they don't need to standup to the elements and they're black (which blends really well with the espresso stain).8

Once the desktop was fastened together, I added the legs. Jackie helped hold the legs while I made marks for where to pre-drill the hole. I did this by drilling into the board just enough to make a mark. In hindsight, I probably would've used a sharpie to make these marks, because the drill didn't go straight down (it bumped against the legs of the table), which caused a screw or two to fasten a little off kilter.

After making marks, I pre-drilled the holes without the legs on the table, to ensure straight holes for the screws. We put the legs back on the table and fastened them with the 2-1 / 2" drywall screws. We flipped the desk over to stand on its legs after we'd completed fastening the legs to the desktop, and it was looking good. There was a little rock if you tried to jostle it on the long edge, but not anymore than I'd expected.

Now that the table was assembled, it was time for the wood filler and one more coat of varnish.

### One step too far

I'm just going to say it right now: **Don't use wood filler for filling gaps between boards if you're not a professional.**

Personally, I feel like I messed up my desk adding the wood filler, mostly because I wasn't good at it at first. It was really messy and, I'm of the belief, that it's a skill you have to practice before you use it in the real world.

I added a coat of varnish after the wood filler (that's 3 coats total for the desk), which helped a little to make the wood filler look better, but didn't help totally.

**Note:** I went back and sanded down the final coat of varnish and wood filler, and revarnished it, which looked much better. Here's the final wood filled result:

## Final Thoughts on the Build and the Buy

The total cost of parts was around $250, which was a huge savings. Generally, in these kinds of projects I like to take into account my "labor" but since it was a project for fun, I didn't really consider it worthwhile to keep up with my time.

As of this writing (2014 / 10 / 08), the desk is "stable" but a little rocky. depending on how my usage goes this week, I might add a stabilizing pipe to the back long edge to make it really stable.

The next step is to build a laptop stand. When working at a standing desk, it's good to have a separate keyboard at your elbow level and your laptop/monitor at or around eye-level. Personally, I think this part is crucial to the long-term health of your neck.

## My Retrospective

I've added bits and pieces of my retrospective through my build walkthrough, but I wanted to add some thoughts about what I felt went well, what I felt I could've gone better and what I wish I'd known before hand.

### What Went Well

- Sanding, staining & varnishing were the easiest/most successful tasks of the whole project.
- Once I figured out how to get the legs totally assembled, they turned out as good as I'd hoped for.

### What I Felt Could've Gone Better

- In hindsight, I didn't think about cable management, but I think over the next weekend I'm going to give it some thought and find a solution. [Thanks to @o2dazone (brandon murry) for the protip.](https://twitter.com/o2dazone/status/519858277048676353)
- I would've liked to have thought about having a pipe to stabilize the long edge that ran along the back. Based on my current configuration, I could probably still hack it to get it the way I want it.
- Wood filling. Wood filling. Wood filling. That's how badly that went. I should've practiced on something (the bottom) just to make sure I knew what I was doing.

### What I Wish I'd Known

- Don't get galvanized pipes to paint, if they're going to be black eventually anyways.
- Adding a second set of horizontal pipes, on the short edge, to a set of legs is significantly more complex/difficult than just having one horizontal pipe on the legs.

I'll continue to add my retrospective thoughts if anymore come to me, so be sure to check back every now and again for updates.

I hope this helps inspire you to build your own standing desk and gives you the beginning resoures you need to go your own way!

One final photo:

![Rustic standing desk](/img/rustic-standing-desk/final-desk.jpg)

If you feel like I missed anything in the build process or have questions unanswered, feel free to add a comment below!



Notes on the process I used to build an rustic industrial standing desk

I help startups navigate the complexity of building human-centric software.

What I'm Writing