Category Archives: Viget

Beginner’s Guide to Variable Fonts: Part 1

Imagine a future where you could throw caution to the wind and use as many different font weights on a web page as your heart desired. One where you could easily create clever but simple animations using a single font file. Now, imagine you could do these things while reducing page load time. Well folks, we have arrived. The future is now. 

Variable fonts allow us as designers and front-end developers to create highly responsive and engaging interfaces that also cut down on load time. The best part? They’re super easy to use. Essentially, variable fonts are one font file that behaves like multiple font files.

read more

Gitting Your First Dev Job

A year and a half ago I decided I was ready for a career shift. I had heard great things about Turing School and decided to try out one of their Try Coding weekends. I attended classes all day Saturday and Sunday learning the basics of my shell, Ruby and JavaScript. I was hooked. I attended the Back End Engineering program from January – August 2018. We primarily focused on Ruby on Rails, with a sprinkling of JavaScript and other technologies.

I graduated from boot camp in August 2018, and began working at Viget the following month. I was nervous, expecting my Rails knowledge to be far inferior to other developers that have been working in the framework for years. Of course, there was still plenty of Rails to master, but I was surprised by all the other stuff there was to learn. In school, everything else felt like an overwhelming distraction from what I thought I was supposed to be focused on — Rails.

I was so focused on learning the details of this magical framework, that I’d ignore tons of other things. I’d often need to run sudo in front of commands when others didn’t need to. I’d get confused managing different versions of Ruby, and just change the .ruby-version and update everything to make my life easier. My philosophy was, why spend time resolving these types of issues when I could be doing the REAL work of writing code? TL;DR: This is not a great philosophy.

These types of tasks are a major part of a developer’s job. I had told myself I’d learn these other details after I fully understood Rails, which feels comical in retrospect. You’re never going to know everything there is to know about a particular framework. These “extra” tasks would have been extremely valuable to prioritize while at school.

Of the many coding-adjacent tasks to learn, my biggest regret is not spending more time learning Git before starting here. So without further ado, here are a few of my favorite Git commands.

Git

At school, I learned just enough to git by (sorry…). I could push and pull from a repo on GitHub, and check out a branch and merge that into master. Projects were typically small enough that you could coordinate with your partner on not touching the same parts of the codebase. Merge conflicts were rarely a big issue, with a few memorable exceptions.

Here’s a few of the things I’d glazed over and have come to strongly value.

Spike branch

This seems minor in retrospect, but it was really valuable in speeding up my workflow initially. A spike branch is a branch you create that you’re planning to experiment on and ultimately delete. When starting a potentially gnarly rebase on my-cool-feature branch or perhaps wanting to go back a few commits and try a different implementation, I could branch off of that branch to a duplicate lets-try-this spike branch. That way, if I were to mess anything up, I could go back to the original my-cool-feature branch. It let me take greater risks when learning, because I knew even if I royally botched the code or the Git history, I could delete the spike branch and start again. Now that I know the tools better (especially git reflog…see below), I use this less often, but it is still a great tool to have in the toolbox.

# from my-cool-feature-branch, let's make a spike branch
$ git checkout -b lets-try-this
# experiment with with some code and commit it
$ git add .
$ git commit -m "trying this out"
# whoops that really didn't work! revert!!
$ git checkout my-cool-feature-branch
# whew back to square one. let's delete that spike branch for the sake of git hygiene
$ git branch lets-try-this -D

Rebase

At Turing, we learned rebasing for one project, and it was a terrifying beast that I vowed to never touch again with a 10 foot pole. One reason some use rebase instead of merge commits is that it can make the Git history cleaner to read. That was not a very convincing argument when it was just me and a partner working together on a project that was completed in a week or less. Handling merge conflicts at every single commit seemed tedious (especially as this was before I knew to squash commits). Once I realized that rebasing was the Viget standard, I followed this tutorial to better wrap my head around it, but the majority of my learning just came through practice. It wasn’t until I was working on projects of a larger scale that I saw the value in rebasing. Now having a team of several developers, who may have been maintaining a codebase for months or years, it became clear that an easy-to-read Git log was a necessity.

# from my-cool-feature-branch, let's rebase off of master to pull in the latest changes
$ git pull --rebase origin master
# You'll see something like this in your terminal
remote: Enumerating objects: 60, done.
remote: Counting objects: 100% (60/60), done.
remote: Compressing objects: 100% (21/21), done.
remote: Total 46 (delta 26), reused 36 (delta 19), pack-reused 0
Unpacking objects: 100% (46/46), done.
From github.com:vigetlabs/cool_project
 * branch            master     -> FETCH_HEAD
   27b325e..3814381  master     -> origin/master
First, rewinding head to replay your work on top of it...
Applying: Adding absinthe_ecto and absinthe_phoenix
Applying: Wires up the user model
Applying: Adding tests associated with users
# If there are any conflicts associated with a particular commit, it will alert you and you will fix directly in your editor, then add and continue
$ git add .
$ git rebase --continue
# No exciting message to let you know when the rebase is complete, it simply applies the last commit and calls it a day.
Applying: User can login

read more

Sparking Connections and Growth from a GOOD Initiative

There is a really lovely thing that happens everyday around noon at Viget’s HQ office: you can find at least two, three, or 15 people enjoying lunch together. We have amazing custom self-built tables that invite all sorts of camaraderie and conversations. Everything from the latest reality TV dramas, big sports news, and politics gets discussed at our version of the “water cooler.” During these short lunch breaks, we sometimes wander off into bigger topics like identity, women in tech, and stereotypes, and it often feels like we are just getting started. Typically those conversations continue on Slack or, if we’re lucky, a Labshare or an Ignite Talk, but sometimes they don’t.

read more

How to use local unpublished Node packages as project dependencies

There are times when you want to install a local package as a project dependency. You might be writing a package for general distribution; or maybe you are contributing to an open source package, or a private personal package, or something internal to your team. You are working on local changes and you need to test them out before you commit, let alone before you open a pull request or deploy an update. What is the best way to add the local copy of the package to a local project for real work testing?

(No time to be reading things? Scroll to the end for the tldr.)

You can push your updates to a remote, and add that version as a dependency. For example with a Github repo you can do npm install or yarn add a <remote url>[#<ref>] (for Github repos there is the shorthand <user or org>/<repo>[#<ref>]). But that requires an internet connection, and the time to push updates, and you will have to reinstall the package in the project with every change.

There are npm add relative/path and yarn add file:relative/path, which copy the package directory over to the project’s node_modules. The npm command does not install dependencies. Neither responds to updates you make to the package. Plus using a relative path can get unwieldy with ../s.

There are npm link and yarn link. Both add a dependency as local symlink. (npm link docs, yarn link docs.) But this solution has technical complications, and the npm and the yarn implimentations give people trouble (as of this writing there are about 40 open npm link issues and over 150 open yarn link issues). If you have tried to use symlinked dependencies while developing a package you’ve probably run into into a stumbling block, whether simply an unexpected unlink behavior, trouble with peer dependencies, or something bigger.

So what to do? The answer for me is @whitecolor‘s yalc.

yalc maintains its own local “store”, at ~/.yalc. Publish a package with yalc, and a full copy of the package is copied to the store. Install a package from the yalc store, and the project will install that copy much like it would install a package from an external registry. Update a package published to the yalc store, and the update is now available in the dependent projects; you can even publish and automatically update dependent projects with a single command. To keep things from colliding, yalc signs each published version with a hash. And yalc can store as many versions of a package (that’s the package.json version) as you want.

yalc makes it easy to develop and test packages locally, in an intuitive way. It meets the common need you might expect (npm|yarn) link to meet. yalc has a number of other useful features too — head over to its README to learn all about workspace-friendly adding, advanced Git use, and more.

Here’s how to use yalc to manage local packages:

Install yalc

Install yalc

$ npm install -g yalc # or `yarn global add yalc`

(Note: here $ is used to represent the command prompt)

Publish a package to your local yalc store

In the package you’re developing

# in the in-development package's directory
$ yalc publish

Add the package as a dependency from the yalc store

In the dependent project

# in the dependent project's directory
$ yalc add <dependency name>

If you look in your dependent project’s package.json you will see that the dependency has been added, with a file:.yalc/ path, e.g.

"dependencies": {
  "my-package": "file:.yalc/my-package"
}

yalc also addes the yalc.lock file, which lists the project dependencies added with yalc. After yalc adding my-package, yalc.lock in the dependent project’s root directory will look something like

{
  "version": "v1",
  "packages": {
    "my-package": {
      "signature": "...", // a hash identifying the version of the dependency in yalc's store
      "file": true // type of yalc connection
    }
  }
}

yalc does not install dependency packages, so if the package under development has its own package.json dependencies they will need to be installed in the test project as a second step:

# in the dependent project's directory
$ npm install # or yarn

As of this writing, there is a bug where yalc dependencies are not given the correct permissions:

# in the dependent package's directory
$ <some command that relies on my-project>

path/to/test-project/node_modules/.bin/my-package
/bin/sh: path/to/test-project/node_modules/.bin/my-package: Permission denied
error Command failed with exit code 126.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

read more

How to use local Node packages as project dependencies

There are times when you want to install a local package as a project dependency. You might be writing a package for general distribution; or maybe you are contributing to an open source package, or a private personal package, or something internal to your team. You are working on local changes and you need to test them out before you commit, let alone before you open a pull request or deploy an update. What is the best way to add the local copy of the package to a local project for real work testing?

(No time to be reading things? Scroll to the end for the tldr.)

You can push your updates to a remote, and add that version as a dependency. For example with a Github repo you can do npm install or yarn add a <remote url>[#<ref>] (for Github repos there is the shorthand <user or org>/<repo>[#<ref>]). But that requires an internet connection, and the time to push updates, and you will have to reinstall the package in the project with every change.

There are npm add relative/path and yarn add file:relative/path, which copy the package directory over to the project’s node_modules. The npm command does not install dependencies. Neither responds to updates you make to the package. Plus using a relative path can get unwieldy with ../s.

There are npm link and yarn link. Both add a dependency as local symlink. (npm link docs, yarn link docs.) But this solution has technical complications, and the npm and the yarn implimentations give people trouble (as of this writing there are about 40 open npm link issues and over 150 open yarn link issues). If you have tried to use symlinked dependencies while developing a package you’ve probably run into into a stumbling block, whether simply an unexpected unlink behavior, trouble with peer dependencies, or something bigger.

So what to do? The answer for me is @whitecolor‘s yalc.

yalc maintains its own local “store”, at ~/.yalc. Publish a package with yalc, and a full copy of the package is copied to the store. Install a package from the yalc store, and the project will install that copy much like it would install a package from an external registry. Update a package published to the yalc store, and the update is now available in the dependent projects; you can even publish and automatically update dependent projects with a single command. To keep things from colliding, yalc signs each published version with a hash. And yalc can store as many versions of a package (that’s the package.json version) as you want.

yalc makes it easy to develop and test packages locally, in an intuitive way. It meets the common need you might expect (npm|yarn) link to meet. yalc has a number of other useful features too — head over to its README to learn all about workspace-friendly adding, advanced Git use, and more.

Here’s how to use yalc to manage local packages:

Install yalc

Install yalc

$ npm install -g yalc # or `yarn global add yalc`

(Note: here $ is used to represent the command prompt)

Publish a package to your local yalc store

In the package you’re developing

# in the in-development package's directory
$ yalc publish

Add the package as a dependency from the yalc store

In the dependent project

# in the dependent project's directory
$ yalc add <dependency name>

If you look in your dependent project’s package.json you will see that the dependency has been added, with a file:.yalc/ path, e.g.

"dependencies": {
  "my-package": "file:.yalc/my-package"
}

yalc also addes the yalc.lock file, which lists the project dependencies added with yalc. After yalc adding my-package, yalc.lock in the dependent project’s root directory will look something like

{
  "version": "v1",
  "packages": {
    "my-package": {
      "signature": "...", // a hash identifying the version of the dependency in yalc's store
      "file": true // type of yalc connection
    }
  }
}

yalc does not install dependency packages, so if the package under development has its own package.json dependencies they will need to be installed in the test project as a second step:

# in the dependent project's directory
$ npm install # or yarn

As of this writing, there is a bug where yalc dependencies are not given the correct permissions:

# in the dependent package's directory
$ <some command that relies on my-project>

path/to/test-project/node_modules/.bin/my-package
/bin/sh: path/to/test-project/node_modules/.bin/my-package: Permission denied
error Command failed with exit code 126.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

read more