DEV Community: Erin Bush

Nevertheless, Erin Coded

Erin Bush — Wed, 06 Mar 2019 05:29:32 +0000

Shine theory continues to permeate my life and, reflecting back on that this International Women's Day, has made me eternally grateful for all of the folks in my life who push me to be a better person and who I can support in return.

From the Shine Theory website:

Shine Theory is an investment, over the long term, in helping someone be their best self—and relying on their help in return.

As of today, I am one sprint in to my first project as a technical lead. When doing our retrospective earlier, we anonymously write down 3 positive things and 3 things we can improve from the past 2 weeks. Three separate people wrote that something to the effect of "Erin is doing a great job as tech lead!"

Imposter syndrome is no joke and is something I grapple with all👏the👏damn👏time. I wanted to take a picture of those notes and stick them up on my monitor. Everyone needs reminders that. So here it is:

You are doing a good job and that you are killing it by just being yourself.

I continued to code in 2019 because...

I like creating silly little applications that don't really do anything and learning one new thing every day.

I am proud of...

Working in my spare time to draft conference talks. They might not be accepted anywhere but it's been great practice brainstorming creative ways of explaining concepts to a general audience.

Driving the accessibility initiative at work. We still have a long way to go but at least now accessibility is more front of mind for people than before.

I hope to see my developer community...

Be more like the community here on dev.to. I've been truly impressed with the culture fostered on this platform and am never afraid to publish content for fear of rude comments.

TIL about automatically bumping NPM versions

Erin Bush — Fri, 01 Mar 2019 19:08:14 +0000

Do you need to update a bunch of packages? Do they all have a similar scope* or name?

npm-check-updates checks the packages listed in your package.json file, and prints out a list of the packages that can be updated to the latest version.

To install:

npm install -g npm-check-updates

Then, run it in your project folder:

ncu

You’ll get some output that looks a little something like this:

If you want it to automatically bump the versions in your package.json file you can pass in the update parameter:

ncu -u

You can also run it with a regex string if you are just curious about a certain scope or package:

ncu '/^@npm.*$/' -u

Remember to run npm install afterwards to actually install the packages since npm-check-updates will just update your package.json file.

Presto-chango you've just saved yourself some seriously tedious file changes!

*PS: scopes in npm are useful if you need to group packages by your organization. In the following example “npm” is the scope.

@npm/package-name

This post was originally published on my blog

Being intentional with commits

Erin Bush — Sat, 23 Feb 2019 22:45:13 +0000

The other day I was poking around in a github repository and came across this commit message:

Not that I needed to know that much about what this person was committing at the time, but I couldn’t help but think how unhelpful this commit message would be if someone needed to understand the project.

I have also been guilty of creating less-than-descriptive commit messages - I'm sure we've all been there. If you want to see some truly hilarious commit messages you can check out whatthecommit.com.

At my work we started using Commitizen which is based on Conventional Commits specification. It took a minute to get used to but after a few days, I could see how much value it was adding to the code base.

Breaking down commit size

Because it breaks commits down into categories, it forces you to only add relevant files to one category.

Buh-bye editing 30 files and committing them all in one go. I mean, you still could do that but you will feel a slight pang of guilt every time you add a feature change in with your test changes.

After using the tool for a few days, I started thinking about good stopping points in my work where I could commit - with the intention that I could make my messages make the most sense. For example, when working on a feature that also included some refactor work, I would try to just do the refactor first, commit that, and then start working on the new functionality. Looking back at the commit messages when browsing files and seeing the type of change that was made, helps so much for granularity and for knowing what to expect from a certain commit.

More descriptive messages

While other people on the internet might have already been splitting their commit messages into subjects and bodies, I was not. I’ve now realized, the longer description in the body is so helpful for describing the nuances of the changes you have made. Even if its just for you to go over before you make your pull request, it will help you understand why you did what you in a way more thorough way - provided you actually add a thorough description.

At my work, we’ve gone a step further to create a custom command line tool that makes your pull requests for you on Github with the pull request description being a list of your git commits. At first, I was worried this wasn’t enough. How could 100 character commit messages tell you everything you need to know about the code changes? But then, I had a lightbulb moment: the commits already ARE supposed to tell you everything about the code changes. I just wasn’t making my commits well enough. Once I started breaking things down by commit category and providing better commit messages (mainly through the longer descriptions), my pull requests were back up to the level they used to be before when I would write the description myself and have subpar commit messages.

I encourage everyone to set up Commitizen and try it out for a few days. I think it will make future you way happier when you are looking back at your code and thinking, “What the heck was I thinking?”

NPM Linking and Unlinking

Erin Bush — Wed, 06 Feb 2019 22:05:39 +0000

At work, we have our own npm packages that we manage and maintain. As part of the dev process its crucial to test out the package in the context of a larger project to ensure it functions as expected and meets all our criteria. A handy trick that I've been using is linking local npm packages using npm link.

However, as a result of having multiple tasks on the go on any given day, I kept getting myself into weird situations with permission issues where I would have the package not available anymore, which TBH was v annoying. The result of constant branch switching and not cleaning up my local environment before doing so.

Here are the exact steps for both linking and unlinking so you can avoid the #struggle I went through.

Lets say we have an npm package that we are working on locally, lets call it cowabunga. Our project structure looks something like this:

And it’s package.json file looks something like this:

You’ll notice that this package has its own node_modules folder - this is where I kept getting tripped up. I would switch branches in the repo where my package lives and the node_modules folder would disappear as a result of building other components that don't live in both branches. When I would go to unlink, npm was throwing permissions errors that went something like this:



npm ERR! enoent ENOENT: no such file or directory, access ‘my_project/node_modules/cowabunga/node_modules/some-package’

In order to avoid this, you have to follow the linking/unlinking order otherwise npm will try to unlink folders that no longer exist. Seems pretty basic but it was surprisingly tedious to figure out.

Linking:

First, in the cowabunga folder (where package.json is):



npm link

Then in the project you want to include cowabunga in:



npm link cowabunga

Unlinking:

Before switching branches and/or removing any node modules from the package itself (in my project, this includes running learn clean which removed the node_modules folders)

First, in the project:



npm unlink --no-save cowabunga

Second, in the package:



npm unlink

Note: order is important!

Where I kept running into issues is switching branches and then the symlink couldn’t find the package anymore so you were stuck in this weird state where you couldn’t link anything or unlink anything because the folders don’t exist. When this happens, check out your original branch and start from the beginning with linking the package and the project.

🤙

Bonus:
You can also run



npm install -g i .

in your package folder to install it globally and avoid some of the linking mess 🎉

Advice for first-time conference applicant

Erin Bush — Thu, 17 Jan 2019 02:42:37 +0000

I've got a few different ideas rolling around in my noggin that could potentially be turned into conference talks. Anyone have any advice on writing/giving talks on technical subjects?

Nevertheless, Erin Coded

Erin Bush — Sun, 06 Jan 2019 22:17:30 +0000

I began/continue to code because...

I fell into coding after my first year at UBC. We were required to take a programming class as a part of the Engineering program. While staying up late, hunched over an assignment I had procrastinated on, I realized that I had been going for 5 hours straight with no bathroom breaks - an obvious sign that I was in a flow state?

My relationship with programming has seen a lot of ups and downs. The downs having me question if I really wanted to be a programmer or if there was more out there for me. Retrospection has made me realize that while essentially programming is the same everywhere, community is the thing that keeps me going.

I'm currently hacking on...

Building out my GraphQL knowledge by implementing subscriptions for real time notifications and status updates. I'm also working on implementing automated accessibility checks into my team's workflow and coming up with a technical plan of attack for our accessibility debt.

My advice for allies to support women and non-binary folks who code is....

Community is what has saved me from quitting programming several times. Find people you connect with and like working with and ask to be on their team or projects. Reach out to people online and see if anyone wants to meet up for coffee to talk about shared experiences as a woman or non-binary person who codes.