DEV Community: 802.11 Savage

Removing Background Noise from Pre-recorded Audio

802.11 Savage — Sun, 23 May 2021 19:39:05 +0000

So you recorded your podcast and everything went great! You open up your recorded files and notice some pretty nasty background noise. You have a few options on removing this noise:

Use some noise gates to get rid of it => Wont be able to remove everything, especially noises mixed with the voice
Manually edit it out => still doesn't work with mixed audio
cry

There are tools that work while recording (such as krisp.ai) but not once you have a recording.

...unless you use some audio wizard!

1. Download Loopback

From Loopback's website:

With the power of Loopback, it's easy to pass audio from one application to another. Loopback can combine audio from both application sources and audio input devices, then make it available anywhere on your Mac.

So using this app we will be able to send audio from one application (whatever is playing your video) as an input to another application (krisp.ai to remove the background noise)

2. Download krisp.ai

This app will enable use to us AI to remove the background noise from your audio

3. Set up Virtual Capture Device

Once you have loopback installed we will need to set up a virtual device. This will make the Descript Audio virtual device available to other applications.

4. Set krisp.ai's Input to `Descript Audio`

Now set krisp.ai to use our virtual device as its input. This will enable krisp to remove the audio from the other app once we start recording.

Make sure the switch the Remove Noise option on.

5. Use QuickTime for Capture

Now that we have our audio routing set up all that's left to do is actually capture it!

Open QuickTime and start a new audio recording (File => New Audio Recording).' Then using the dropdown select krisp microphone as the capture device.

6. Start Capture

Now all you have to do it hit the Record button in QuickTime and start playing you audio in whatever application you are capturing. While this is happening you won't hear anything come out of your speakers because QuickTime is capturing it.

Wait until your video is done and stop recording. You know have you audio with all the background noise removed! 🎉

JavaScript Monorepo Tooling

802.11 Savage — Sun, 14 Feb 2021 04:16:57 +0000

JavaScript Monorepo Tooling

JavaScript monorepo tooling has come a long way. The landscape is vast and filled with varying tools that attempt to solve different parts of the tool chain. Many times while discussing what tools do what I see lots of confusion. This article attempts to summarize a some popular tools and their approach to solving monorepo problems.

The functionality of these tools can be organized into 3 capabilities.

Capabilities:

installer - tools that help with installing a monorepo's dependencies
task-runner - tools that help with running commands or scripts throughout the repo and possibly creating new packages within the repo
publisher - tools that help/enforce versioning for a monorepo

Some tools have multiple functions and can encompass multiple Capabilities.

Tool	installer	task-runner	publisher
lerna	✅	✅	✅
yarn v1	✅
npm v7	✅
pnpm	✅	✅	✅
rush	✅	✅	✅
nx		✅
ultra-runner		✅
turborepo		✅
changesets			✅
auto			✅

Monorepo tooling is a sea of innovation right now and some best in class have emerged that enable you to build a monorepo with wonderful DX. With faster builds becoming the focus of many of these tool I'm excited to see what I can do with all my new free time 😉

Common Monorepo Structure

Most of the tools in this article operate under the assumption that your project is structured like following:

package.json: devDependencies and scripts for the monorepo
packages/**/package.json: dependencies, unique devDependencies and scripts for the package

The packages package.jsons form a dependency graph that describes how everything depends on each other. All of these tools in some way utilize the dependency graph in some way.

Tools

This is not a comprehensive list and some tools maybe left out. If you see one i've missed tell me about it on twitter.

🐉 lerna

A tool for managing JavaScript projects with multiple packages.

Capabilities: installer task-runner publisher

From my experience lerna was the first JavaScript monorepo tool that came with all the tools needed to manage a monorepo. It paved the way for all of these other tools and is a piece of software that truly changed my life. If you want to you can just use lerna and it's commands in your projects.

`installer` => `lerna bootstrap` `lerna add`

The first command lerna comes with that most people probably attribute their lerna experience to is the bootstrap command. This is how it's described in the docs:

Link local packages together and install remaining package dependencies

Basically it's npm install but for monorepos. While not the fastest monorepo installer it gets the job done! It also set the stage for other tool to iterate and improve.

`task-runner` =>`lerna changed` `lerna run` `lerna exec` `lerna create`

All of these command in some way facilitate running the various scripts in your projects. lerna exposes some flags that help you run these scripts in a monorepo-aware way:

lerna run --stream: Run a script in each package in order of the dependency graph
lerna run --parallel: Run a script in all matches packages in parallel processes
lerna run --since: Run a script in all changed packages since a specific commit or tag

lerna can also quickly scaffold a new package using lerna create. Although this doesn't work off of templates, and created packages are don't conain many files.

`publisher` => `lerna version` `lerna publish`

In my opinion this is really where a lerna really shines. Publishing in a monorepo is hard! You have many packages and lots of dependencies between them, so it's pretty hard to know what package to version and when.

To solve this problem lerna can publish a project in two modes:

fixed (recommended) - All packages in the project have the same version
independent - All package in the project have independent version

In either mode lerna will figure out what packages have changed, even taking into dependencies between packages, then update the package.jsons as needed.

Tip: in fixed mode you can use the --force-publish flag to always publish each package on any change. This makes it simple to debug versions since they should all be the same!

The amount of time that these commands have saved me is immense! This is the publish workflow to beat for monorepo tooling.

🐈 yarn v1

Fast, reliable, and secure dependency management.

Capabilities: installer

yarn is an alternative to npm that came with the promise of faster install times. At the time of it's creation it really delivered! Installs were super fast, so fast even that npm improved the performance of their install too.

When yarn introduced the concept of workspaces they brought that same speed to monorepo install times. Compared to lerna bootstrap yarn is almost twice as fast for the projects I work on.

All of the monorepos I've set up both at my job and in open source utilize a combination of lerna and yarn and it's been amazing! They go together like chocolate and peanut butter.

`link:`

When declaring a dependency between packages in your monorepo use the link:../path-to-package syntax. This will create a symlink in you node_modules to the package in your repo so that any requires resolve to the current version of the code. These links will get resolved by lerna during a publish for seamless developer experience.

The one caveat to this is that none of the tooling warns you when you created and invalid dependency link:. If you mis-type a path, that path won't be resolved during a publish, it will make it's way into consuming projects and break their code!

To fix this my teammate Kendall Gassner forked eslint-plugin-package-json and added a rule to create an error when an invalid link: is found!

Check it out here.

🐻 npm v7

The CLI for the world's largest software registry.

Capabilities: installer

Very recently npm add support for workspaces. It works in the same manner as yarn workspaces and makes npm a monorepo aware installer!

🐨 pnpm

Fast, disk space efficient package manager

Capabilities: installer task-runner publisher-ish

pnpm stands for performant npm, it aims to be a fast installer for any JavaScript project. From my reading of the docs it focuses mainly on the installer and task-runner aspects of monorepo management.

`installer` => `pnpm install` `pnpm add` `pnpm update` and more!

These commands are the bread and butter of pnpm. They facilitate managing the decencies for you project and work well for monorepos.

This functionality is a direct competitor to yarn and npm, any of these can be a good fit for a project.

`task-runner` => `pnpm run`

Much like lerna's run command you can use pnpm run to run monorepo aware scripts in your project.

pnpm run --recursive: Run a script in each package in order of the dependency graph
pnpm run --parallel: Run a script in all matches packages in parallel processes

`publisher` => `pnpm publisher`

With this command you can edit a package version and then run pnpm publish --recursive to publish the current package and it's dependencies.

Other than that pnpm does not implement anything further to help you with publishing you monorepo. This is probably the place where pnpm lacks the most, but they know that and recommend other tools in this post.

🚴‍♂️ rush

Rush: a scalable monorepo manager for the web

Capabilities: installer task-runner publisher

Rush aims to be a full featured tool set for managing monorepos much like lerna, but takes a much different approach for each set of problems. A lot of it is very config driven and newly initiated project have a lot of files.

It supports plugins too!

`installer` => `rush add` `rush check` `rush install` `rush update`

Rush has it's own approach to monorepo structure. In a Rush project there is not root package.json and only each individual package has a package.json.

In one step, Rush installs all the dependencies for all your projects into a common folder. This is not just a package.json file at the root of your repo (which might set you up to accidentally require() a sibling's dependencies). Instead, Rush uses symlinks to reconstruct an accurate node_modules folder for each project, without any of the limitations or glitches that seem to plague other approaches.

They support all the popular JavaScript package managers (npm yarn pnpm), so you can choose whatever best fits your project.

`task-runner` => `rush build` `rush rebuild`

Rush improves running build in your repo through a few methods.

The first is by being smart about execution using the dependency graph.

Rush detects your dependency graph and builds your projects in the right order. If two packages don't directly depend on each other, Rush parallelizes their build as separate processes.

And the second is by only building the parts of the projects when you want to.

If you only plan to work with a few projects from your repo, rush rebuild --to <project> does a clean build of just your upstream dependencies. After you make changes, rush rebuild --from <project> does a clean build of only the affected downstream projects.

It even support incremental builds for even faster builds! Unfortunately this is where Rush's task running abilities end, it only does builds, so you'll have to figure out running other types of scripts on your own.

`publisher` => `rush change` `rush version` `rush publish`

Keeping with the trend, Rush also has it's own custom publishing process.

When a developer is submitting a PR to a Rush based monorepo they need to run rush change to tell Rush what the change is and how it should effect the package's version.

On a CI the build script will run rush change -v to verify that a PR has a change from rush change included. Once the PR is merged the CI run rush publish to apply the version changes. This command will create a changelog for each effected package in the dependency graph and publish it to npm.

A cool new feature they introduced recently is Version Policies. Version Policies are a lot like lerna's fixed and independent mode but more powerful. Instead of saying all packages should be fixed or independent you can group packages into a policy as you want. This means you could have multiple parts of your repo have different fixed versioning and independently version the rest.

🌊 nx

Nx is a suite of powerful, extensible dev tools to help you architect, test, and build at any scale — integrating seamlessly with modern technologies and libraries while providing a robust CLI, caching, dependency management, and more.

Capabilities: task-runner

This tool focuses mainly on being a smart task-runner. In the same vein as other tools in this list it will only run commands for code effected in your project's dependency graph. It can also use a distributed computation cache, which stores the results of commands in a cache to speed up execution.

Nx changes the monorepo structure by only having a root package.json. Instead of a package.json for each project in the monorepo all of that is configured through the workspace.json. This file describes all of the apps, libraries and tools in the monorepo and how they depend on each other. It also includes command and generator configuration.

Comparing it to lerna can be summarized as:

lerna => A tool for managing a monorepo of packages
nx => A tool for managing a monorepo of applications, tools and services for an

Plugins

Nx also has a plugin systems so you can easily add popular development tools in an easy way. These plugins range from test and linting tools to templates for new libraries, services and websites.

This project has the most full featured project templating/package creation of the tools in this list.

`task running` => `nx run` `nx run-many` `nx affected`

This tool comes with many of the same features as other task runner, supporting parallel, dependency graph sorted and git detected change builds.

🏃 ultra-runner

Zero-config ultra fast monorepo script runner and build tool

Capabilities: task-runner

This tool is super easy to use in any repo using the common monorepo structure. It parses scripts in your package.json to intelligently run theme and only re-executes commands if the files have changes using a local build cache.

While not as full features as other tools on this list it does one things and does it well. One of it's biggest features for me is the ease with which you can add it to an existing monorepo.

⏩ turborepo

Monorepos that make ship happen.

Capabilities: task-runner

This is the only tool on the list but it's the one I'm most excited about. From what I've read and seen, turborepo seems to be like all the intelligent builds of rush and nx without all of the config or monorepo structure changes.

turborepo use a local+remote caching system with your dependency graph to run your builds and scripts more efficiently. It also is going to shipt with a plugin system that will make it work with various tools. The plugin system seem super cool to me because it potentially opens up the tool for use outside of JavaScript. Imagine have super quick builds for everything.

🦋 changesets

A way to manage your versioning and changelogs with a focus on monorepos

Capabilities: publisher

changesets operate in a very similar way to how rush change works. They both produce a file that describes the change and how it should effect the version.

`publishing` => `changeset` `changeset version` `changeset publish`

Once a PR is merged with a changeset file the CI can apply the version bumps described in those files with changeset version. This command will create changelog file, apply version bump to the dependency graph, and delete the changeset files. The changeset publish command is then called to publish the changes made by the version command

🏎️ auto

Generate releases based on semantic version labels on pull requests.

Disclaimer: I'm the main author and maintainer of this project

Capabilities: publisher

auto's npm plugin has built-in support for publishing JavaScript monorepos that's built on top of lerna awesome publishing features. Where it differs is that it automates the semantic versioning of you project though GitHub labels. It handles creating changelogs, versioning your packages, creating Github releases, publishing canary/prerelease versions, and a host of other things through its plugin system.

All of this is available of one context aware command that you just run at the end of each build: auto shipit.

call from base branch -> latest version released
call from prerelease branch -> prerelease version released
call from PR in CI -> canary version released
call locally when not on base/prerelease branch -> canary version released

The awesome thing about auto is that you can bring its workflow to whatever platform you want! As of today auto has 11 different package manager plugins that enable you to publish anything from a rust create to a gradle project.

At the company where I work (Intuit) we have hundreds of projects on various platforms using auto and have made 16,000+ release and saved thousands of developer hours.

Best In Class

Compared to just a few years ago the open source options for monorepo tooling have exploded with a lot of quality options. If you chose any of the tools mentioned in this article you would be in good hands.

The following details my personal "best" of each category. I have not used a few of these tools at all and my opinions are in now way facts.

Installation

Best	Honorable Mention
`yarn v1`	`pnpm`

While I have put yarn as the best it's really because it's the only one I've used in the past few years. While researching this article I now have the itch to try out pnpm on a project since the transition seems easy.

Task Running

Best	Honorable Mention
`rush` or `nx`	`turborepo`

I haven't used either of these tools that I've deemed best, but given their features they have vastly improved build and task execution for monorepo projects. The one detractor for me is that both of those tools rely heavily on radically different monorepo configurations, and lots and lots of config.

This is what has me excited for turborepo. Since it can easily fit to the common monorepo model it will be a no brainer for any project.It doesn't seem to rely on a bunch of new configuration either which is a huge plus, the less config the better. If it's plugin system can be extended to other languages and platforms I predict this tool will become popular

Publishing

Best	Honorable Mention
`auto`	`rush`

On this category I am a little biased. I maintain auto but I truly believe that it's the best solution for publishing in any project. It's automated publishing system can be used with any package management system though it's plugin systems. It takes one of the most stress filled parts of managing a monorepo and makes it as easy as merging a pull request.

Rush's new Versioning Policy feature is pretty cool. It feels like the next generation of lerna's fixed and independent modes. I'm excited to test it out, and probably will write and auto plugin for it 🎉

❤️ Thanks for Reading

I hope you found some useful information in this article and learned something! Feel free to hit me up on twitter to discuss the latest and greatest in monorepo tooling and automated publishing!

My Terminal Setup

802.11 Savage — Fri, 29 May 2020 03:49:17 +0000

When I first started coding in college, one of the scariest pieces of technology to me was the terminal. Back then OSX shipped with bash and the default was just plain hard to look at, so I didn't.

Often tell junior developers to get as comfortable as possible with the terminal as soon as they can. I recount a tale from my college years where, just a few hours before a due date, I rm -rfed my project and had to redo it in a rush. This was solely because I was hesitant to use the terminal and didn't realize what I was doing. Being comfortable on the terminal is a critical skill as a dev, so being on your terminal should feel amazing.

Over the years I've played around with a bunch of different terminal setups and even written themes of my own. But I've really come to love my current setup. This post will detail how do make your's looks like this too!

Terminal App

The default terminal for OSX is okay but I always install iterm for all it's great features.

iTerm settings

Beautiful Font

The default rendering just kind of feels "off". To make it buttery smooth go to Preferences => Profiles => Text and check Enable subpixel anti-aliasing. This is a huge quality of life improvement.

The them I use recommends to install these fonts and I wholeheartedly agree.

Then go to Preferences => Profiles => Text and change the font to MesloLGS NF. I also up the default font size to 16 instead of 12. You will need to restart iTerm for it to save you font selection to the default profile.

Minimal Theme

Go to Preferences => Appearance => General and change Theme to Minimal. This is what makes the terminal's toolbar black and uniform with the rest of the app.

Unfocused Pane Dimming

Go to Preferences => Appearance => Dimming and make sure everything but Dim background windows is checked. This will make it so that when you split panes the unfocused pane isn't distracting.

Split Pane in Same Directory

Something that I hated about terminal splitting was that the new terminal starts out in the home directory.

Go to Preferences => Profiles => General => Working Directory
Select Advanced Configuration
Click Edit
Change Working Directory for New Split Panes to Reuse previous session's directory

Quiet New Terminal Prompts

When you make a new terminal it will spit out a bunch of text you don't care about. Run the following command to silence all of these! This even works on corporate computers!

touch ~/.hushlogin

Shell Configuration Manager

And then the next thing I install oh-my-zsh. From their website:

Oh My Zsh is a delightful, open source, community-driven framework for managing your Zsh configuration.

We will this utilize the theming and plugin support

sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

Theme

Theming your terminal usually involves a lot of setup and tweaking. Recently I found powerlevel10k and am absolutely in love.

Features:

Setup is a breeze
The font the have you install looks amazing on a terminal
Instantly responsive on a new tab (I type so fast now!)
Transient Prompt make having information on your terminal prompt useable

Install the theme on your machine:

git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/themes/powerlevel10k

Set the theme in ~/.zshrc:

ZSH_THEME="powerlevel10k/powerlevel10k"

Once you restart your terminal you will go through the setup to customize your terminal. If you like the way mine above is rendered, you can grab mine here.

p10k Customizations

In this section I explain the customization I did to my ~./.p10k.zsh. If you use mine you do not have to read any of this, as it has already been done for you

Left Prompt

On the left side I added a custom icon on the first line, and a prompt character on the second line. The rest of the values are the defaults.

typeset -g POWERLEVEL9K_LEFT_PROMPT_ELEMENTS=(
  # =========================[ Line #1 ]=========================
  my_icon
  dir                     # current directory
  vcs                     # git status
  # =========================[ Line #2 ]=========================
  newline                 # \n
  prompt_char           # prompt symbol
)

# Display a custom Icon the changes depending on the time
# Use the Font Book on your mac to figure out the character
# To change the color change `-f 070` to a different 256 color
function prompt_my_icon() {
  local -i currentTime=${(%):-%D{%H%M}}

  if (( currentTime > 1619 || currentTime < 421 )); then
    # Weed
    p10k segment -f 070 -i 'ﲤ'
  else
    # Duck
    p10k segment -f 227 -i ''
  fi
}

Right Prompt

Here I un-commented any node version detection and added three items to the second line of the prompt.
These three segments are only show on previous commands.

status - Whether the last command failed or passed
time - The time the last command was run
dir - The directory the command was run from

This is super useful when your are looking back on commands you've run. You know the context in which they were ran and that information isn't cluttered with all the other stuff in your prompt.

typeset -g POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS=(
  # =========================[ Line #1 ]=========================
  # ALL THE DEFAULTS DONT DELETE THEM. REMOVED FOR CLARITY
  nodenv                  # node.js version from nodenv (https://github.com/nodenv/nodenv)
  node_version          # node.js version
  battery               # internal battery
  # =========================[ Line #2 ]=========================
  newline                 # \n
  status
  time
  dir
)

# Turn of p10k's transient prompt so we can control it
typeset -g POWERLEVEL9K_TRANSIENT_PROMPT=off

# Hide the second line on the right side
function p10k-on-pre-prompt() {
  p10k display '1|*/left_frame'=show '2/right/(time|dir|status)'=hide
}

# Show the second line on the right side after command is run
function p10k-on-post-prompt() {
  p10k display '1|*/left_frame'=hide '2/right/(time|dir|status)'=show
}

ZSH Plugins

ZSH Plugins offer a lot and most of the are geared towards a specific dev stack. Finding the right plugin means an awesome tab completion experience. Install whatever you need, I don't use plugins for this though.

The two plugin I do use are

zsh-syntax-highlighting - Fish shell like syntax highlighting for Zsh. This is what makes my aliases/commands green above. If it's green then it's installed!
zsh-autosuggestions - Fish-like autosuggestions for zsh. Will show a preview of the last matching command while typing. Press right to use

Aliases

I started out not using aliases all that much, but as you get more comfortable with the terminal they become really useful. Create these as you see fit, that's the easiest way to remember them.

The following ones are simple and can fit most workflows:

# Alias the vs-code "code" command to something shorter
# You can use it to open anything in vscode "c ." will open the current directory
alias c="code"

# Open your .zshrc in VS Code
alias zshrc="c ~/.zshrc"

# Restart the terminal and ZSH
alias restart="exec zsh"

Git

I started as a Git GUI person (I still love and use gitup daily) but as I've grown as a developer I moved more and more into my terminal.

# Open the current repository in Gitup
alias g="gitup"
# Create a new Branch
alias gb="git checkout -b"
# Show the current status of the repo
alias gs="git status --short"
# Stage some files
alias ga="git add -v"
# Stage all files
alias gaa="ga -A"
# Make a commit
alias gc="git commit -m"
# Add all changes, amend the last commit, and force push
alias gaf="gaa && git amend && gp -f"

gitPush()
{
    # If in a git repo - call git mv. otherwise- call mv
    if [[ $(git config "branch.$(git rev-parse --abbrev-ref HEAD).merge") == '' ]];
    then
        git push -u --porcelain "$@"
    else
        git push --porcelain "$@"
    fi
}
# Push to origin and set the upstream if necessary
alias gp=gitPush

# Delete merged branches
alias gcb="git checkout master && git pull && git branch --merged master | egrep -v 'next|master' | xargs -I % sh -c 'git branch -d %; git config --get branch.%.merge && git push origin -d %'"

The gp alias requires you to set a value in your git configuration

[push]
  default = current

The gaf alias requires you to set a value in your git configuration. This will also make the git amend command available. This command will amend the last commit with any staged changes.

[alias]
  amend = commit --no-edit --no-verify --amend

And while you're there you might as well use all my color settings too. Git output should be pretty too!

[color]
  ui = true
  branch = auto
[color "diff-highlight"]
  oldNormal = red bold
  oldHighlight = red bold 52
  newNormal = green bold
  newHighlight = green bold 22
[color "diff"]
  commit = yellow bold
  old = red bold
  new = green bold
  whitespace = red reverse
[color "status"]
  branch = magenta normal bold
  remoteBranch = magenta normal bold
  changed = yellow normal bold
  untracked = red normal bold
  updated = green normal bold
[color "branch"]
  current = magenta normal ul bold
  remote = yellow normal bold

Terminal Keyboard Shortcuts

Being skilled with keyboard shortcuts can make you look like a superhero in a text editor. The default iTerm keyboard shortcuts are nothing like vs-codes so I was always inserting weird character in the terminal instead of quickly navigating text.

To fix this you can set up custom keyboard shortcuts in iTerm. Go to Preferences => Keys. For each of the following click the + button and make the Action set to Send Hex Code.

Shortcut	Result	Hex Code
`cmd + right`	Cursor to end of line	`0x05`
`cmd + left`	Cursor to start of line	`0x01`
`cmd + backspace`	Delete line	`0x15`
`alt + right`	Cursor skip one word right	`0x1b 0x66`
`alt + left`	Cursor skip one word left	`0x1b 0x62`
`alt + backspace`	Delete one word	`0x1b 0x08`

Better Default Tools

A lot of the tools you use are probably super old! That's great cause they work no problem, but they might not be as pretty as we want them! All of the following are tools I use to replace default tooling that is preinstalled on most computers.

`cat` => `bat`

A cat(1) clone with wings.. So much nicer!

brew install bat

Make sure to alias cat in your ~/.zshrc.

alias cat="bat"

`ls` => `exa`

A modern version of ‘ls’.. Pretty colors!

brew install exa

Make sure to alias cat in your ~/.zshrc.

alias ls="exa"
# Show lots of info, even with icons!
alias lss="exa -alh --icons --git-ignore"

`git diff` => `diff-so-fancy`

Strives to make your diffs human readable instead of machine readable..

brew install diff-so-fancy

Tell git to use diff-so-fancy for all diffs:

git config --global core.pager "diff-so-fancy | less -FR --tabs=4

History search

bash and zsh ship with a nice search history (press ctrl + r). But it's old and ugly. For a better experience I install fzf.

brew install fzf

# To install useful key bindings and fuzzy completion:
$(brew --prefix)/opt/fzf/install

`cd` => `z` (zoxide)

Easily jump to directories. Just supply a part of the path and it will change the directory to the last matching path. I still use cd but I use z to jump between projects.

brew tap ajeetdsouza/zoxide
brew install zoxide

And add some config in your ~/.zshrc.

eval "$(zoxide init zsh)"

zoxide ships with a zi alias. This allows you to fuzzy search though all possible directory matches.

npm: More Secure Canary Publishing

802.11 Savage — Sun, 15 Dec 2019 00:16:24 +0000

Publishing canary versions comes with some security risks. If your project is private you have nothing to worry about, but if your project is open source there are some security holes.

A canary version is a test version put out for a change other user's can utilize for testing.

Attack Vectors

Depending on the build platform you might be able to pass secrets to PR builds for forked repos. While this makes the developer experience of your project nice, in auto's case publishing canary versions, it exposes your keys.

An attacker could:

print secrets
send secrets to some server
modify auto to publish to the latest tag instead of canary

No amount of code can fix these problems. If your release keys are in everyone's CI builds an attacker can do any number of things to modify what you intend for auto to do (or any other release method run in the CI).

Solution

The solution for this is actually quite simple:

Create a test scope that you publish canaries under (ex: @auto-canary or @auto-test)
Create a user that only has access to that scope
Set the default NPM_TOKEN to a token that can publish to that scope (this is used for any pull request)
Set up a secure token that is only accessible on the main fork (still named NPM_TOKEN)

Step 3 might not be possible on your build platform.

The following are the ways the auto team knows how to do it. If you do not see the method for you build platform, please tell us about it!

CircleCI Context - Contexts provide a mechanism for securing and sharing environment variables across projects. The environment variables are defined as name/value pairs and are injected at runtime.

Usage

To use this work flow in auto, supply the following configuration to the npm plugin.

{
  "plugins": [
    [
      "npm",
      {
        "canaryScope": "@auto-canary"
      }
    ]
  ]
}

Now when people make pull requests to your repos:

your CI can run auto shipit
the canary versions will get published under your canaryScope

This feature was added in auto@v8.1.0

Announcing “auto” 8.0.0

802.11 Savage — Thu, 12 Dec 2019 08:06:18 +0000

We are excited to announce the release of auto 8.0.0! This release brings a new command next, a new use for shipit, more powerful label configuration, and more.

If you are unfamiliar, auto is a CLI tool which helps you version your code and automate any part of your release pipeline. auto's main use is for automating your versioning with semantic versioning and GitHub pull request labels. It handles determining the next version, creating changelogs, publishing to package managers, publishing GitHub Releases, and so much more through plugins.

The following is a high level view of the workflow that auto shipit enables:

If you aren't already using auto you can either install it through npm:

npm install auto

Or if you are publishing to something other than npm:

# On OSX
brew tap intuit/auto https://github.com/intuit/auto
brew install auto

# Or other OSs
# Download a platform specific version of auto
curl -vkL -o - https://github.com/intuit/auto/releases/download/v8.0.0/auto-linux.gz | gunzip > ~/auto
# Make auto executable
chmod a+x ~/auto

`next` Command

This new command will make a preview release of your code. This entails:

Creating a prerelease on package management platform (supported by npm and git-tag plugins)
Creating a tag and "Pre Release" on GitHub releases page

The only prerelease branch auto comes configured with is next. You can configure as many branches as you want with the prereleaseBranches .autorc option. If your package manager plugin supports release tags, such as the npm plugin, auto will publish the prerelease branch to a tag of the same name. Calling auto next from a one of these branches will publish a prerelease, otherwise it will publish to your default prerelease branch/tag.

Example Usage

Given the following configuration:

{
  "prereleaseBranches": ["beta"]
}

Run auto next from beta branch => Publish prerelease to beta tag.
Run auto next from feature branch => Publish prerelease to beta tag.

Prerelease Branches with `shipit`

The shipit command will now also publish a prerelease when ran from a prerelease branch. You can use this in a few different ways:

Two release branches: master and next
Without next Branch (--only-graduate-with-release-label)
Multiple next Branches (ex: alpha, beta, rc)
Feature Pre-releases

Label Configuration

Label configuration just got a whole lot simpler 🎉.

Labels can now only be supplied as an array of label objects.

{
  "labels": [
    { "releaseType": "major", "name": "Version: Major" },
    { "releaseType": "minor", "name": "Version: Minor" },
    { "releaseType": "patch", "name": "Version: Patch" }
  ]
}

Instead of using skipReleaseLabels just set the label's type to skip

   {
     "labels": [{ "releaseType": "skip", "name": "NO!" }]
   }

Overwrite default labels using overwrite

   {
     "labels": [
       { "releaseType": "major", "name": "Version: Major", "overwrite": true }
     ]
   }

Add none releaseType. This will act as a skip-release unless paired with a SEMVER label

   {
     "labels": [{ "releaseType": "none", "name": "documentation" }]
   }

Changed title to changelogTitle.

   {
     "labels": [{ "changelogTitle": "New Docs Yo!", "name": "documentation" }]
   }

Upload Assets - Globs

You might want to upload multiple files or you might not know the file-name (ex: a vscode extension w/ a version number in the name), but you know the pattern of the filenames that you want to upload. So now you can use globs!

{
  "plugins": [["upload-assets", ["./path/**/to/*.file"]]]
}

💥 Other Notable Breaking Changes

Deprecate `--very-verbose, -w` Flag

Using -w for very verbose logs was a very odd choice on my part (two vs next to each other look like a w 😓). Instead you can now just add another -v and get the very verbose logs!

# old
auto shipit -w

# new
auto shipit -vv
# or
auto shipit --verbose --verbose

We hope you enjoy the new ways you can release your code!

– Andrew Lisowski and the auto Team

View the full release notes.

DEV Community: 802.11 Savage

Removing Background Noise from Pre-recorded Audio

1. Download Loopback

2. Download krisp.ai

3. Set up Virtual Capture Device

4. Set krisp.ai's Input to Descript Audio

5. Use QuickTime for Capture

6. Start Capture

JavaScript Monorepo Tooling

JavaScript Monorepo Tooling

Common Monorepo Structure

Tools

🐉 lerna

installer => lerna bootstrap lerna add

task-runner =>lerna changed lerna run lerna exec lerna create

publisher => lerna version lerna publish

🐈 yarn v1

link:

🐻 npm v7

🐨 pnpm

installer => pnpm install pnpm add pnpm update and more!

task-runner => pnpm run

publisher => pnpm publisher

🚴‍♂️ rush

installer => rush add rush check rush install rush update

task-runner => rush build rush rebuild

publisher => rush change rush version rush publish

🌊 nx

Plugins

task running => nx run nx run-many nx affected

🏃 ultra-runner

⏩ turborepo

🦋 changesets

publishing => changeset changeset version changeset publish

🏎️ auto

Best In Class

Installation

Task Running

Publishing

❤️ Thanks for Reading

My Terminal Setup

Terminal App

iTerm settings

Beautiful Font

Minimal Theme

Unfocused Pane Dimming

Split Pane in Same Directory

Quiet New Terminal Prompts

Shell Configuration Manager

Theme

p10k Customizations

Left Prompt

Right Prompt

ZSH Plugins

Aliases

Git

Terminal Keyboard Shortcuts

Better Default Tools

cat => bat

ls => exa

git diff => diff-so-fancy

History search

cd => z (zoxide)

npm: More Secure Canary Publishing

Attack Vectors

Solution

Usage

Announcing “auto” 8.0.0

next Command

Example Usage

Prerelease Branches with shipit

Label Configuration

Upload Assets - Globs

💥 Other Notable Breaking Changes

Deprecate --very-verbose, -w Flag

4. Set krisp.ai's Input to `Descript Audio`

`installer` => `lerna bootstrap` `lerna add`

`task-runner` =>`lerna changed` `lerna run` `lerna exec` `lerna create`

`publisher` => `lerna version` `lerna publish`

`link:`

`installer` => `pnpm install` `pnpm add` `pnpm update` and more!

`task-runner` => `pnpm run`

`publisher` => `pnpm publisher`

`installer` => `rush add` `rush check` `rush install` `rush update`

`task-runner` => `rush build` `rush rebuild`

`publisher` => `rush change` `rush version` `rush publish`

`task running` => `nx run` `nx run-many` `nx affected`

`publishing` => `changeset` `changeset version` `changeset publish`

`cat` => `bat`

`ls` => `exa`

`git diff` => `diff-so-fancy`

`cd` => `z` (zoxide)

`next` Command

Prerelease Branches with `shipit`

Deprecate `--very-verbose, -w` Flag