The subtitle is "A Book about Art, Independence and Spirit". And that's what this book has meant to me. It's an injunction to free myself and be true to what I feel and have to say. I am excited by this feeling, as applied to the art that I enjoy to create: what I want to say and depict and experience in the making.

The book is a great example of what Ms. Ueland intends to teach. I am swept up in it, and there is no wonder it this book being highly recommended for what it teaches. The words are alive and true, as she describes. I get the feeling that she is a writer, that she does have an ear for what she desires and believes and has gathered inspiration and her own thought that will help us all get a little closer to it ourselves.

The book reverently talks about many of the quips of William Blake and how he lived his life devoted to art. This has increased my own fascination of him.

The outcome of the book, for me, is energy and desire to create. What a heavenly book in that regard. I am thankful to have this positive push in the direction of new and original creation.

Make something true to yourself, and it will be original and worthy.

If You Want to Write


I've long loved The Muppet's Treasure Island. I was happily surprised with the extra bits of adventure found in the actual classic story. When I got to the 25% complete mark in the book and they had already arrived at the island, I wondered what was left. Well, lots! 

I've read that Treasure Island is a book wherein Jim, the main character, encounters various characters and from his encounters must decide what he'll be like when he grows up.  Yes, I suppose. I didn't see his decision points, as it doesn't seem that he talks through them much. But there are very different characters with very different values. Some are misjudged at first and lead to betrayal, others to unexpected respect.

A great book of adventure.


A young boy encounters a treasure map and all the adventure attached to it

Treasure Island


This could have been a real dry book about personal finance. Instead, it's short and sweet with distilled wisdom.  It's a collection of stories that are allegories about principles of personal finance.

For instance, here are a few:

## The 7 Cures for a Lean Purse

### 1: Start they purse to fattening

Save at least 1/10th of your income as payment to yourself and your future estate. This part of what you earn belongs to you.

### 2: Control thy expenditures

Learn what is necessity. Don't waste away money that could better be used in your life.

### 3: Make thy gold multiply

Use your money to make more money. Do not risk your principal.

### 4: Guard thy treasure from loss

If a venture is too good to be true, it probably is. Follow the advice of people with knowledge in finance. Combine in ventures with people with track records of return.

### 5: Make thy dwelling a profitable investment

Your home is a worthwhile place for investment. You'll have something to enjoy and a return for your investment.

### 6: Insure a future income

Some day you will be old and unable to work. Prepare for this moment. Invest money that will grow over time until this far-future moment.

### 7: Increase thy ability to earn

Make investment in education. Keep skilling up. Open new doors of opportunity. Be industrious.

And, a bit of restatement:

## The 5 Rules of Gold

### 1: Gold cometh gladly

If you put away 1/10th of your income, you'll keep growing your gold. Create an estate for yourself and your family.

### 2: Gold laboreth diligently

If you're a profitable servant, you'll put your inheritance, your gold, to work. It will "create children".

### 3: Gold clingeth to the cautious

You'll not lose your investment if you follow the advise of wise financial men. Don't trust brick layers to anything but the brick business.

### 4: Gold slippeth away from the unfamiliar

If you don't have the skills or knowledge in a venture, you'll lose money in it. Become familiar or get help.

### 5: Gold flees impossible earnings

The stats are not good for your financial outlook if you follow get-rich-quick schemes. Don't follow your romantic desires in investments.



Allegories set in babylon about how to handle finances

The Richest Many in Babylon

Svelte Basics

Styling React Components

Electron Fundamentals Course

Here's a bash script for running a lot of separate git commits.



Don't you feel like a 10th level terminal mage whenever you get any sort of bash script to run?  Bash is nice because it'll usually just work in the terminal. You don't need another runtime to get it to work. But wow, is it not a skill that I use often, and it has sharp edges I get myself caught on every time.

In this example, I had a monorepo that relies on conventional commit using commitlint to generate change logs. Thus, changes for every package had to be committed separately. 

First, I made [changes over multiple files](/post/search-replace-multiple-files-macos) using a method similar to one I've written about before.

Then, I made and ran this script:

```bash
for FILE in $(git diff --name-only); do
  PACKAGE=`echo $FILE | sed "s|packages/$.*$/package.json|\1|"`
  git add $FILE
  git commit -m "build($PACKAGE): update to react@17" --message "BREAKING CHANGE: react@17 peerDependency upgrade"
done
```

So, what's here?

- The for loop should look pretty familiar. Be careful to include that semicolon. The body can be multi-line, no problem.
- The thing being looped over is a list of files that have changed. Using the `--name-only` flag, only the file names are listed, not the other instructional text from git.
- `PACKAGE` is being defined here as another variable. Don't try to put spaces around that assignment operator. 
- The backticks for the command in the variable declaration are one way of surrounding a command. The dollar parenthesis in the for loop is another.
- When you use a variable previously declared and want the value of it, you prepend the dollar sign, as in `$FILE`.
- In the `sed` command, I'm using `|` pipes instead of the traditional forward slash. `sed` doesn't care what you use for delimiters, and in this case pipes require fewer escapes on the forward slashes in the pattern.
- The parenthesis in the pattern have to be escaped. This is odd, since this is the standard syntax for capture groups. Later, `\1` represents the group.
- And did you know that a `git commit` can have 2 messages?  One for the subject line: `-m`, and one for the body: `--message`.

Amazing. See, 10th level terminal mage.

A bash script for running a lot of separate git commits.

Automate Separate Commits in Bash

Make buttons controllable via the keyboard within test using testing-library.



## Test is Different than Browser

In the browser, we can focus a button and press enter, and the `onClick` handler is triggered, and all is good.  

In the test environment, it's a different story.  Here, we'll look at tests written for a React UI using [@testing-library/react](https://testing-library.com/docs/react-testing-library/intro/).

## Testing-library Peculiarities

Testing-library is awesome. But it has some duplicate functionality for keyboard events that makes using it confusing. There are many threads describing what works for people, and the answers are all different.  Well, this is another one: here's what worked for me; maybe it'll help.

[`@testing-library/user-events`](https://github.com/testing-library/user-event) is preferred when possible because it more-closely models how the user interacts with your UI in the browser. In this case, however, its use is ill advised -- it doesn't work. To be clear: don't use `userEvent.type(el, '{enter}')`. Instead, use `fireEvent` from [`@testing-library/dom`](https://github.com/testing-library/dom-testing-library). Specifically, use `fireEvent.keyDown(el, { key: 'Enter', code: 'Enter' })`.

## Single Handler, Multiple Events

To get the "enter" keyboarding to work in the test environment, you'll need to add an `onKeyDown` listener in addition to your usual `onClick`. Then point both listeners to the same handler (assuming you want both actions to do the same thing.). Then inside the handler, detect whether it's a click or the kind of key you're expecting before you run the logic for the handler.

```js
function handleButtonEvent(evt) {
  if (
    evt.type === 'click' || 
    (evt.type === 'keydown' && evt.key === 'Enter')
  ) {
    // ...handle it the same way
  }
}

return <button onClick={handleButtonEvent} onKeyDown={handleButtonEvent}>Clicky</button>
```

## Testing Keyboard Handler in Test

Testing-library will allow you to query the elements in the DOM and interact with them. They [prefer](https://testing-library.com/docs/guide-which-query/) using `getByRole`.
You can learn what the [accessibility roles are](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques#Roles) and the usage of `getByRole` will return the options for you upon a test failure.  It's pretty great.

Let's also make sure to focus it first, *then* press enter. Only then will we actuate the button and call the handler.

For this button:

```javascript
function MyButton(props) {
  return <button onClick={props.onClick} onKeyDown={props.onClick}>Clicky</button>
}
```

The test might look like:

```javascript
import { fireEvent, screen } from '@testing-library/dom'

it('calls the handler', () => {
  const handler = jest.fn()

  render(<MyButton onClick={handler} />)
  const button = screen.getbyRole('button', { name: /Clicky/ })
  button.focus()
  fireEvent.keyDown(button, { key: 'Enter', code: 'Enter' })
  expect(handler).toHaveBeenCalled()
})
```

"calls the handler" isn't a very strong assertion, but you get the idea. Assertions on your logic or the DOM state will be better.

Well, that should do it. 

What are the other ways that you've found to actuate a button in test with the enter key?

Make buttons controllable via the keyboard within test.

Keyboard Control of Buttons in Testing Library

Ideas come and go. Act on them now or (quite possibly) never.



Advice to self:

Strike while the idea is hot. (That's a good Jim Rohn'ism I picked up.) When it comes to you in a flash, you might remark to yourself how great the idea is. But it will leave just as quickly if you do nothing about it.

Our emotions can be helpful to us. We can encourage positive emotion, which will encourage positive thoughts, which we can translate to positive action.

I love the empowering idea that we are agents in our own lives. We get to decide what we will do and be. We can do many things of our own free will.

Let reality be the dream killer. Better than wasting your time killing your own ideas. Act to bring them to fruition. Some won't work out, but some will. It takes so little to kill an idea. We can easily convince ourselves it's not worth it, doable, easy, or whatever. Be a builder, and believe in some ideas, and get them off the ground.

Worry less about the future and whether you're making the right decision. If you're going forward trying to make good decisions, that's exactly what will happen. Your good desires will lead to good actions and then good outcomes.

Ideas come and go. Act on them now or never.

Prefer Action

<div class="video-container">
<script async class="speakerdeck-embed" data-id="eb226aa6a2a449299036d225fc2d34ab" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>

This was an experience report given to a Pluralsight audience, meant to increase understanding and appreciation of the Design System we made for ourselves by sharing a history of where it all started and how we came to the place we have. A similar talk meant for an external audience could be interesting, but would likely differ in content for sake of interest.

An experience report to an internal audience on how we made the Pluralsight Design System

How We Make the Design System

<div class="video-container">
<script async class="speakerdeck-embed" data-id="2bcda367b51843789b8f0301128a246d" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>

A presentation for Global Accessibility Awareness Day, where we were to demonstrate how our design system for the web builds with accessibility as a goal and can help product teams support these needs from the outset.

Some tidbits on how we've approached building accessibility into the design system

Accessibility in the Pluralsight Design System

<div class="video-container">
<script async class="speakerdeck-embed" data-id="9a8ad50208b8462794055b48035405d2" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>

Since the inception of our design system, React has been a core technology. Being in a polyglot tech organization however, React wasn't always a given. We never thought that the design system would be able to serve all teams equally. But we wondered if we might do more to support the non-React teams and products. This is a recounting of that journey.

Our explorations in supporting tech beyond React in our design system.

Courses

Posts

Talks

Reading