DEV Community: Zak Laughton

Zak's Top 5 Habits for Success

Zak Laughton — Sat, 30 Jul 2022 19:28:20 +0000

I recently wrote a letter to my brothers, who were graduating high school, outlining the 5 habits I've found to be the most important for succeeding in careers, relationships, and life. It ended up taking a while to write, and I thought others might find it useful, so I've decided to share with a more public audience. Enjoy!

Hey [brother],

Congrats on graduating! Along with some cash from [wife] and me, I wanted to share a few things I've learned that have helped me in my career. Since graduating high school, I've found there are a few simple skills and mindsets that will put you miles ahead of others without too much effort. These are all things I wish I would have known when graduating high school.

But you're graduating and probably getting lots of random advice from family members about how to live your life and what to do. So why listen to me?

I've done extremely well over the past decade. Since starting in the software industry, I’ve consistently received the highest performance reviews on my teams at work, which has led to a significant promotion or pay increase every year. I am being paid significantly more today than I was 7 years ago, and it’s helped us pay off $100,000 in debt and live a happy, comfortable lifestyle.

I’m not saying any of this to brag, but to emphasize that I’ve found successful, reliable methods that continue to advance my career year after year. The principles I’m describing in this letter have helped me succeed in every situation as I rose up through 4 different roles on 5 different teams at 2 different companies. I genuinely think the advice in this letter will help you become a more successful person in your career and in your personal life. This is the first time I’ve shared these collective tips, so I hope you find them useful!

1. Seek first to understand, then to be understood

If you only take one thing from this letter, make it this one: Seek first to understand, then to be understood.

In your life, you will come across many people and situations you disagree with. Your boss will make seemingly dumb decisions, your significant other will get upset about things that seem unimportant to you, you'll meet people with completely different political and religious views that sound absurd to you, and you'll have to follow processes at work that look like they were created by a complete idiot. It's natural to immediately write off contradicting opinions to your own as "wrong" or "dumb". Do not do this. Ever. Instead, get curious.

Everyone has their own opinions and motivations, and for the most part, nobody is actively trying to make bad decisions. That dumb decision your boss made might have been the best thing they could do, given requirements you didn't know about from their boss. That thing your significant other is upset about might be related to a deeper concern about your relationship. That person who has crazy political views might have had years of indoctrination, or they might have some information or perspective you don't have. That dumb process at work might have come from years of reworking former “smarter” processes that have failed in the past. In any case, you are going to have a hard time making any of these situations better without first understanding the reasoning behind them.

When you come across a situation that makes you unhappy or someone you disagree with, get curious and ask questions. What led to things being this way? Why do people think this is a good idea? Do you understand why they think that or how they got to their conclusions? Ask specific questions and get specific answers. As long as you're coming from a place of genuine curiosity (not criticism), people will generally be more than willing to explain the context that you don’t have. And always keep in mind that no matter how confident you are about something, you could be wrong. The only way you're going to find out if you're wrong (or have the best information about why you're right) is to find out more from the people who disagree with you.

When you take time to listen to what other people have to say before inserting your own opinions, you also build trust and understanding. Active listening is a huge influencer, and people will be much more willing to listen to what you have to say if you've listened to them first. And by listening first, you'll also have better context and information to make sound decisions going forward.

2. Assume positive intent

This goes hand-in-hand with seeking first to understand. As you are seeking to understand others, it's important to not assume malice, and instead assume positive intent. One of the biggest blockers I've seen to progress and communication is when people assume the other person in a relationship (professional or otherwise) is intentionally screwing them over. When you don't get what you want, it can be easy to take it personally and assume the other person is targeting you or just being lazy. This is a toxic mindset that creates unnecessary stress and stops all useful conversations. Why even try to fix the situation or find out more when you “know” the other side is doing it on purpose or isn't willing to change?

Even if someone is trying to take advantage of you, the only productive way to continue a conversation is to assume they’re doing their best to work with you. This gives you a way to talk about why you're upset with their actions or ask them why things turned out differently than you expected. And if they continually act this way, it gives you a way to talk about it and plan for further contradictory behavior in the future.

Too many people assume bad intent and never follow up, which halts all progress and leaves them in a bitter state. I've seen days, weeks, and months wasted on projects all because people just didn't want to address a difference in expectations with someone. In most cases, it was just a lack of understanding that could have been cleared up with a simple question.

Assuming positive intent is great for your mental health, too. When I started practicing this several years ago, I realized how many small pointless grudges I was holding and how nice it was to let them go. For years I'd get upset when someone cut me off in traffic, or when a client wouldn't give me all the information I asked for, or when someone on my team at work didn't complete a task. All these unaddressed negative thoughts built up and added unneeded stress to my life with absolutely no benefits or promise of resolution. Assuming positive intent allows you to focus on the facts and not waste mental energy on negative thoughts that serve no purpose other than to make you madder. It forces you to actually think of solutions rather than pointing fingers and giving up.

On the opposite end of this, beware the chronic complainers. At most jobs, you will find negative people who make a habit of assuming bad intent. You'll often find them in groups, talking about how horrible everything is, how nothing will change, and how they're victims of their circumstances. In the short term, it's much easier to sit and complain like this. In the long term, these people find themselves stuck, unhappy, and unable to make any progress until they quit and find a new job where they find new things to complain about. Stay away from these types of people and mindsets if you want to grow and not be miserable. There are healthier ways to deal with stress.

3. Have a system for getting things done

You'd be amazed how many professionals far into their careers cannot reliably complete simple routine tasks. Too many people overcommit and don't keep track of their obligations, leaving their boss and coworkers constantly following up with them.

Know the minimum requirements of your job, and do them. If you have a weekly timesheet you need to submit, or a monthly report you have to do, make sure you have a system in place to remind you to get these done. These are probably some of the easiest and least important responsibilities you have, but not doing them will lose trust with your colleagues quickly. Being able to regularly complete simple routine tasks is an easy way to show you're reliable when compared to your coworkers who have to constantly be reminded by your manager every week.

Having a system to track everything you need to do also gives you a way to take your mind off unimportant tasks while focusing on the more important ones. Set up systems that make it easy to do the minimum requirements for the parts of your job you don't enjoy so you can use your energy to excel at the parts you actually do enjoy.

For effective tips in setting up a system for tracking tasks, I highly recommend reading "Getting Things Done" (or listening to the audiobook). This is the very first career advice book I read. It changed the way I thought about work, and I attribute a lot of my career growth to practices I learned from that book.

4. Have a budget

It's important to have a budget so you can know where your money is going and plan for unexpected expenses. This becomes especially important if you're paying off debt such as student and car loans. You should know how much money you have compared to how much debt you have, and you should make sure that your net worth continues to trend upward. This is very difficult to track without a budget.

A budget doesn't restrict the money you spend; it gives you a realistic picture of your spending. As your bank account grows, you need to know how much of that money you need to hold onto to pay for infrequent, expected expenses like replacing car tires or unexpected expenses like emergency medical procedures. Having a realistic view of your true expenses will give you a better idea of how much money you actually have and how much you can comfortably spend on more fun, frivolous things. Living within your means also makes it easier to focus on building your career, skills, and network without being hyperfocused on the size of your paycheck.

[Wife] and I have tracked every single expense we've made over the past 10 years. We've gone from more than $100,000 in debt to having a higher net worth than most people our age, and our budget has guided us in keeping in the right direction every step of the way.

There are a lot of budgeting programs out there, and you should pick one that you'll use and that works for you. I personally recommend a program called YNAB (short for "You Need A Budget"). They offer a free month and have a lot of great online training to help you manage your money.

5. Read

One of the more surprising tools I’ve used to improve myself and advance in my career is books. When I graduated high school, I had heard of popular self-help books and career advice books, but I didn't think they'd be useful. I figured they were just feel-good fluff motivational books without much to offer. It wasn't until I read "Getting Things Done" early in my career that I realized how helpful books can be in giving advice for navigating life, relationships, and communicating with others. Most of what's in this letter is a combination of what I've learned from these books and found to be the most useful. Today, I always have an e-book or audiobook that I'm reading or listening to, and often return to my favorites for more insight.

Here are the top books I’ve read so far that have had the biggest impact on me:

Getting Things Done – The first productivity book I read, which shapes a lot about how I live my life and succeed in my career today
The 7 Habits of Highly Effective People – Great advice on how to work effectively and handle relationships
How to Win Friends and Influence People in the Digital Age – A modernized version of the classic "How to Win Friends and Influence People", this book gives a lot of surprising insight into building relationships with others. This changed my way of thinking about the effort needed to get to know people, helping me realize that building relationships is mostly just being interested in other people.
Radical Candor – Great advice on how to talk to people and have difficult conversations
The Subtle Art of Not Giving a F*ck – This book gives a good perspective on how to live life a little more stress-free and focus on the things that matter.
Getting to Yes and Never Split the Difference – These are two great books about negotiation that give tips for handling tough conversations in all parts of your life (not just for negotiating purchases and business deals).
Atomic Habits – Nobody becomes a success overnight. Most successful people got to where they are by setting up systems and making small, incremental improvements every day over an extended period of time. Atomic Habits is a great guide to setting yourself up for success with focused habits.
Never Eat Alone – A helpful book about making connections with others and the powerful impact a good network can have on your career.

I hope some of this advice helps! You're at an exciting point at the start of your adult life where you can head in any direction. If you focus on getting a little better each day in your career and relationships, you can have a happy, successful life. Feel free to text me any time for life advice, career advice, or whatever. Congrats, again!

—Zak

Getting your first website on the internet is easier than you think!

Zak Laughton — Mon, 27 Apr 2020 14:23:30 +0000

Just before writing this article, I built a full website and published it online, and it only took 5 minutes!!! You can see the full site in all its glory here: https://zaklaughton.github.io/im-on-the-internet/.

Wow!

Okay, okay, so it's not the most impressive site (see all 3 lines of code in the repo here), but it was incredibly easy to put on the internet.

When I started learning web development, I thought getting my work online would be complicated. I pushed off figuring it out how to do it for way too long. It turns out, as long as you have an HTML file and a git repository, you can publish your site within minutes — you can even get a custom URL!

(This article assumes a basic understanding of git to push to a remote repository. If you're a new web developer unfamiliar with git, you'll need to learn it! Check out some of the training resources here).

GitHub pages

Static files with GitHub Pages

My amazing "I'm on the internet" site above was posted online using Github pages. Github pages is the simplest way to get your repository up on the internet. It's easy, free, and comes built-in with every repository on GitHub.

GitHub pages simply finds an index.html file in the root of your repository, and makes it available at a URL. As long as your repository has an index.html file you can open in a browser on your own computer, then this setup will work for you!

To enable:

Go to your repository on GitHub
Click "Settings"
Under GitHub Pages, select master branch as the source.

That's it! Github will provide you with a URL that you or anyone can use to access your site, and the site will automatically update whenever you update your repository. Pretty cool!

💡Step-by-step guide to getting started with GitHub pages

Framework sites with GitHub Pages

If you're using a framework such as React to build your site, you probably don't have an index.html just laying out there to be served up. These types of frameworks typically require you to build the site — this just means running a command to take all your files written for your framework and turn them into a simple "index.html" site that browsers will understand. Most often, these end up in some sort of "/build" folder.

For GitHub Pages to use this page, you'll need to build the site, put the built site on a new branch, and point Github Pages to the "build" branch. It's a few extra steps, but still should still be relatively quick to get your site online. There are also some great tools out there to automate this for you.

💡Step-by-step guide for publishing a subfolder to GitHub pages
💡If you're using React, check out react-gh-pages
💡An example of a branch built in one of my projects from React to serve a webpage: https://github.com/ZakLaughton/map-project/tree/gh-pages

Custom URL

So what if you don't like having "github.io" in the URL and want to serve your GitHub pages site at your own custom domain name? Turns out, that's pretty easy too! As general steps:

Buy a domain name from a domain name provider (typically costs around $12/year).
Update the domain name system (DNS) configuration with the provider to point to GitHub.
Update the repository settings on GitHub to point to your custom URL.

There are many domain name providers out there, and I recommend doing some research to figure out what works best for you. Personally, I like Google Domains for its low prices and intuitive interface.

Once you purchase the domain name, just update the DNS settings as described in the GitHub Pages documentation. Here are the settings for youneedtocalmdown.fyi, which direct both youneedtocalmdown.fyi and www.youneedtocalmdown.fyi to the same site:

DNS settings in Google domains. (Be sure to consult the GitHub docs for the most up-to-date address to use)

Corresponding GitHub Pages settings on the repository

💡How to setup Google Domain for GitHub pages

Using subdomains

$12/year for a domain name is pretty cheap, but this can get expensive as you start buying more. For many of your personal projects, you probably just want to host them on a subdomain on your site. You can do this by adding CNAME entries into your DNS settings.

Here's the DNS settings which direct to zaklaughton.dev, along with all the GitHub repositories with GitHub Pages settings configured for crossy.zaklaughton.dev, map.zaklaughton.dev, memory.zaklaughton.dev, minesweeper.zaklaughton.dev, and myreads.zaklaughton.dev:

What if my site needs a server?

In building web apps, you may get to a point where you do need a server to help serve the data on the page, such as with a back-end server or a site that is server-side rendered. While this isn't possible with GitHub pages, luckily there are sites that make it easy to host and run this server-side code, too! Both Netlify and Heroku are some of the more popular options.

The finer details are outside the scope of this article, but know that there are also server-side options are out there to automate the deployment process from a git repository.

Examples
🌐 flattenthecurve.zaklaughton.dev (repo) — Server-side rendered site (using Gatsby). Automatically builds and deploys the site when the GitHub master branch updates.
🌐 survivorstats.com (repo) — Front end is hosted on netlify. Back end (responsible for fetching database data) is hosted on Heroku. The back end is updated with simple commands from the Heroku CLI.

Summary

Putting your sites on the internet is a great way to share your work, and it's quick and easy to do! There's no need to wait to share your projects with the world.

Use GitHub Pages to make the sites in your GitHub repos public.
For a custom URL, Set up a custom domain with a service like Google domains
Use hosting services such as Netlify and Heroku if you require any server-side code.

Did you find this this article useful? Feel free to follow my profile below or follow me on Twitter for more developer tips and article announcements!

Git deep-dive: "git init"

Zak Laughton — Mon, 09 Mar 2020 04:50:31 +0000

This article kicks off a multi-part series taking a closer look at the common parts of git we often take for granted.

And what better way to start the series than with the command that starts all git repositories: git init.

What you might know

git init starts a new repository! You want source control in Git? Just run the command git init and BAM!– that directory is now a git repository.

Here's what it looks like in action:

Git commands such as git status won't work in a directory until we initialize the git repository

Once this is done, you can do all the cool things you do in git, such as add, commit, merge, and more!...But those commands are for another article. We're here to focus a little more on the usage of git init. Let's take a closer look...

What you might not know

💡 How the repository is initialized

What is git init actually doing when it initializes a repository? When you run the command, it creates a hidden directory called .git:

.git/ contains all the behind-the-scenes data that makes git source control tick. All the branch information, past changes, current status, and more is all held here. Here's what the contents of that directory look like:

We aren't going to go through what each directory and file does here. Most of it isn't human-readable, and is only intended to be interacted with using Git. Just know that this .git/ sub-directory structure (or most of it) is required for git to do its thing.

If you wanted, you could even manually create .git/ and all its contents, and git would still recognize it as a repository (Try it out if you have some free time! Which files are required? Which aren't?). This also means if you delete the .git directory on an existing repository, all your branches and git history will be deleted as well. This can actually be useful if you're very early in a project and decide you want to re-start a repository to initialize from your current working files. Just rm -rf .git and git init all over again.

💡 ALL repository data is stored in `.git/`

We often think about git storing historical data, while your working directory (everything outside .git/) has the current files. It's important to remember that Git, or more specifically: the .git directory, has all the data — including the most recent committed changes. In fact, you can even git clone directly from the .git directory, just like you would from a remote repository!

Now there are two of them!

💡 Create a "remote" repository with `--bare`

Did you know you can actually push to and pull from your local working repository? However, you might run into some issues. Watch what happens when we try to push the master branch to a local working repository where master is also checked out:

Git says "NO!"

This is why you'll typically push and pull from a remote repository instead of from someone else's working repository. Most often, this remote repository setup is handled through a git repo service such as Bitbucket or GitHub, but if you wanted to set up your own, you'd use the --bare flag:

Recognize those files and directories? That's everything we saw before in the hidden .git repository, except now they aren't covered by a hidden folder! Yes, they're...naked! 😮 So it shouldn't be surprising that this is known as a "bare repository". With a naked – um, I mean – bare repository, you're essentially telling git, "Nobody's working here. Just store the data, and let users push and pull from it."

Since nobody's working here, you don't really need anything outside the .git directory. And if you don't need anything outside the .git directory, why not just put all the .git contents at the top level?

💡 Shhhhhh

And finally...Is your git init making TOO MUCH NOISE???

Stop all that terrible noisy racket with the -q or --quiet flag:

Finally, some peace and quiet!

Wrap-up

I hope this has helped shine a light on how git init works and how a repository is born. For further reading, you may want to check out:

Stay tuned for the next article in the series where I cover the slightly-more-interesting command: git add.

Did you find this this article useful? Feel free to follow my profile below or follow me on Twitter for more developer tips and article announcements!

3 ways to time travel in Git to undo destructive mistakes

Zak Laughton — Thu, 27 Feb 2020 13:35:02 +0000

Raise your hand if you can relate:

// Detect dark theme var iframe = document.getElementById('tweet-1232412585397571584-502'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1232412585397571584&theme=dark" }

🙋🙋🙋🙋🙋

We've all been there! It's easy to do a well-meaning git rebase or git reset only to find everything broken afterwards. Then, since your changes rewrote history, the only way to go back is to delete everything and re-clone the repository to start over again. I used to do this all the time!

But what if I told you there was a better way? What if you could time travel back to a point before you did those destructive changes without deleting anything? It turns out, git has built-in tools for this such as reflog, ORIG_HEAD, and gitrevisions, and they're surprisingly easy to use!

In this article, I'll show you how to use these nifty shortcuts to undo some of those history-changing moves and get back to the proper timeline!

Setup

If you only want to read the examples, you can skip to the next section. But if you want to follow along with the examples on your own terminal, run each line below as a command in your terminal to set up the demo repository:

mkdir reflog-demo && cd reflog-demo && git init
echo "file 1 content" > file1.txt && git add . && git commit -m "add file1"
echo "file 2 content" > file2.txt && git add . && git commit -m "add file2"
git checkout -b my-new-branch
echo "new branch file content" > newBranchFile.txt && git add . && git commit -m "add newBranchFile"
git checkout master
echo "file 3 content" > file3.txt && git add . && git commit -m "add file3"
git checkout my-new-branch

Examples

Here's an overview of the starting git history (using the command git log --oneline --graph --all):

There is a master branch with 3 files, each added in a separate commit. There is also a separate my-new-branch branch. This branch also has the first two files, but then splits off from master and has its own third file.

And here are all the files in my-new-branch:

This is the desired state. When we mess it up in the examples below, our goal is to bring the repository back to this state.

1. Reset using a `reflog` reference

Let's say we're on my-new-branch and we rebase onto master:

But Agh! We realize this was a mistake! Maybe the code stopped working after the rebase. Maybe there were some weird merge conflicts during the rebase and everything got messy. Either way, we want things to be the way they were before, but here is what our new git log shows:

...and all our my-new-branch files are combined with the master files:

Apparently, our original commit (6cde040) is gone. How do we go back? We could delete everything and re-clone, but we probably don't have a remote copy of our most recent changes to clone. We could manually create a new branch off the old commit and re-add/delete the files that were there, but what a hassle!

Instead, try running git reflog to see some helpful points in history:

Git reflog shows everywhere our current working HEAD was at, including commits that were removed with destructive commands such as git reset and git rebase. Simply pick the commit before our destructive changes, do a hard reset to the gitrevision number (the one with the curly braces), and everything is reset to the way it was before the rebase!

git reset --hard HEAD@{3}

After running this command, our git log shows us we're back to our original state with the original commits and the original files:

Ahhhh, good ol' un-touched branches!

2. Reset to `ORIG_HEAD`

"But Zak," you might say, "that reflog output is kind of confusing, and it's hard to tell exactly which reflog line to go back to."

Agreed! Luckily, there's an EVEN EASIER way!

git reset --hard ORIG_HEAD

ORIG_HEAD automatically points to the state before the most recent destructive change, so we can easily undo our most recent rebase or reset with a single command! Running git reset --hard ORIG_HEAD here does the exact same thing as running git reset --hard HEAD@{3} in the example above without needing to hunt down a specific revision!

3. Reset to a relative time

🌟🌟🌟WARNING: THIS IS REALLY COOL

Resetting to ORIG_HEAD is great, but what if we've really gone down a rabbit hole of destructive changes. Let's take the rebase from the last example, and add a few more steps to it:

git rebase master
git reset --hard HEAD~2
git commit --amend -m 'shablagoo!'

Why did we do this? I don't know ¯\_(ツ)_/¯. Someone on Stack Overflow probably said it was a good idea, so we tried it on a whim and, well, things got weird:

The commits are all out of order, and we are missing files. How can we undo this??? We made several destructive changes, so ORIG_HEAD isn't going to work. We can check git reflog, but there's so many changes that happened that it might be hard to find the right one. All we want is for our branch to look like it did 5 minutes ago before the changes.

Try this:

git reset --hard HEAD@{5.minutes.ago}

...and afterwards, you'll see the branch in the exact state it was 5 minutes ago:

Ahhhh, good ol' un-touched branches!

Yes, you read that right: This command literally tells Git in plain English to return to some time in the past, and Git does it!

This is using a powerful concept in git called gitrevisions. Some other examples include: HEAD@{1.day.2.hours.ago}, HEAD@{yesterday}, HEAD@{2020-01-01 18:30:00}, HEAD@{12:43}. In other words: TIME TRAVEL IS POSSIBLE IN GIT!!!

Caveats

The techniques above are powerful, but there are a few limitations to keep in mind:

Only works for your local terminal – your reflog and gitrevisions are stored locally, but aren't shared when you push to a remote repository
Only works for committed files – if you've deleted uncommitted files, these aren't stored in Git anywhere. Good reason to commit early and often

Recap

So, to summarize, here are some ways to fix your repo after you reset or rebase your code into an unusable state:

Use git reflog to pick a point in history, then undo your recent changes git reset --hard HEAD@{<number>}
As a shortcut, use git reset --hard ORIG_HEAD to undo the most recent destructive operation
Reset to <refname>@<relative time> to time travel back to a happier state (e.g. git reset --hard HEAD@{10.minutes.ago})

I hope this helps someone out there! Let me know in the comments if you have any questions or any other go-to methods for undoing git mistakes!

_Did you find this this article useful? Feel free to follow my profile below or [follow me on Twitter](https://twitter.com/ZakLaughton) for more developer tips and article announcements!_

The only 4 Regex Notations You Need To Know (to start) ❤️

Zak Laughton — Wed, 19 Feb 2020 03:56:28 +0000

You know what's awesome?! Regex is! I use it almost every day to search through my codebase, and occasionally to parse text input in my code. (If you're unfamiliar: regex, short for regular expression, is a powerful technique for searching large amounts of text using a specialized string of characters.)

But I've heard something surprising lately from many developers: "I hate regex". What?? Why would anyone say something so horrible about something that's so fun? I have a theory...

I'm going to go out on a limb here and make a bold claim: nobody hates regex, they just hate implementing it into whatever programming language they use (hear me out on this). Even with a perfect grasp of how regex works, it can be difficult to figure out what the regex is actually doing when sending it through a coding interface.

As an example, here's a nice easy search for the word episode using regex
in a text editor where we can easily see the results:

"Ah, yes. This is everywhere my code has the word episode. Lovely!"

...but here's an example where we're searching for the same word in a myText variable using JavaScript regex functions:

"Did the query work? Why are there 3 different methods for searching regex? Am I using the right one? Why do they all return a different data type? Are they searching the right data?? Is this case sensitive??? WHY IS REGEX SO COMPLICATED?!!?!?!"

Clearly, regex isn't the problem here! The problem is figuring out how to use regex in these dang functions! Hating regex because of confusing code implementation is like hating cake batter for burning your cake. And do you know who hates cake batter? Nobody. Cake batter is delicious.

So in this article, I'm going to focus on just eating the cake batter. I'm going to show you the powers of regex by using it to search code in a text editor, without the pesky implementation of a programming language. I'll show you how it's an essential tool to search your files, and hopefully teach you some new delicious tricks along the way to help when you do need to use it in your code.

Most useful regex notations

There are entire textbooks written on how to write regex queries, but you only need a few basics to start seeing some big results. Below I've listed the 4 regex notations I use most often to quickly narrow down large sets of text to a single snippet.

The examples below will be using Visual Studio Code, but most other code text editors such as Sublime and Atom have similar regex search functionality. If you're following along, you can open up a text search in your editor using Ctrl + F (on mac: ⌘ + F), or search all your files using Ctrl + Shift + F (on mac: ⌘ + Shift + F). Be sure the regex option (the one that looks like .*) is enabled, and the rest are disabled:

1. Simple text search

At its base functionality, it's important to remember that regex will just search regular ol' text. If you're searching for text that just has letters, numbers and spaces, just type the text as your query.

If there are any special characters or punctuation, add a backslash \ before the character. This is because many special characters have meaning in regex queries that changes the search behavior. Adding a backslash "escapes" the character and tells regex to just search for the character itself. Example: to search for a period, type \., to search for an opening parenthesis, type \(.

Searching for atLatestEpisode\( matches all occurrences of atLatestEpisode( in the code.

2. Wildcard `.*`

.* is a wildcard that matches any number of characters. Use it to match strings where you're not certain of some of characters in the middle.

Searching at.*Episode\( matches both atEarliestEpisode( and atLatestEpisode(.

3. Capturing groups and backreferences `()`

Capturing groups are a way to "capture" parts of your query with parenthesis to use for special functionality. On their own, these parenthesis won't impact the search results. For example, in the query (shab)la(go)o, both shab and go are captured groups, but the query will still match all instances of shablagoo in the text.

So why would you want to do this? A few reasons, but one of the most useful reasons in a text editor is to reference the text as a variable. Each capturing group is numbered by the order it appears and is assigned a numbered variable you can use to insert the captured text somewhere else (this is also known as a backreference).

Where this gets really powerful in an editor is using these backreferences as search replacement variables. For example, if I search for (always)(blue), then set the replacement string to $2$1, then every occurrence of alwaysblue will be replaced with bluealways. This is because the first capturing group, always, is assigned to $1, and the second capturing group, blue, is assigned to $2.

This type of find and replace rearrangement is especially useful if you want to change the format of several records in a large dataset.

This gif shows a great way to capture and rearrange data. First, we select all names by changing the first and last name to wildcards. Next, we place the wildcards in capturing groups to be referenced in the replace field. Finally, we use the number of each capturing group to re-insert the first and last names into whatever new format we want!

Word boundary `\b`

The last one I'm going to cover here is the word boundary, which I use all the time when searching short words in code. Let's say you want to find any time the word user shows up in your files. You can do a regex search of all files for user, but this will also include partial matches such as username, enduser, and obtuseRicearoni. That's where the word boundary comes in.

\b represents a boundary between a word and a non-word character. Or more simply – the edge of a word. (Note: a "word" character here means a letter, a number, or an underscore. A "non-word" character is everything else). This means you can search for \buser\b and it will only return instances of user that are not a part of a longer word or variable name. Pretty cool!

Searching episode in this file returns waaaay too many results with longer names that include episode. You can narrow it down to search just for the word by searching for \bepisode\b.

Wrap-up

That's it! These tips above can help optimize your processes, make it easier to search through large files, and hopefully help boost confidence when implementing regex in your own code.

When you do implement regex in your programming language of choice, I strongly recommend trying it out in a text editor first to ensure you've got the proper regex before adding the programming complications. There are also super helpful sites such as https://regexr.com/ and https://regexr.com/ that provide great cheatsheets and playgrounds for testing your regex.

What did I miss? Any other regex notations you love that I left out? Or any questions about using regex? Feel free to let me know in the comments!

Did you find this this article useful? Feel free to subscribe to my articles below or follow me on Twitter for more developer tips and article announcements!

Every VS Code extension a JavaScript web developer should have in 2021 (with gifs!)

Zak Laughton — Sun, 09 Feb 2020 23:09:05 +0000

Visual Studio Code is a powerful editor out of the box, but there are many many VS Code extensions to make it even more powerful!

If you're new to VS Code or coding in general, I recommend reading through everything here to see if there are new ways you can optimize your workflow. If you're a VS Code veteran, see if there's anything here you don't have, and let me know in the comments if I missed anything!

VS Code is constantly updating, and I regularly review my extensions to figure out which ones are and are not adding value. I'll be keeping this list updated as I add and remove extensions.

Must-have extensions (alphabetical)

Better Comments

Better Comments shows your comments as different colors depending on how they're prefixed. Great to quickly visually scan and identify important pieces of your code. Keep in mind these colors only show if you have the extension, so this is best for personal use cases.
Bookmarks

Have you ever been working on a feature that involves 10 functions across several files, forcing you to hop around and re-find each function? Bookmarks helps you keep track of all the code that's important to you. Just add a bookmark to easily find your spot later!
Bracket Pair Colorizer

Trying to find missing parenthesis is my least favorite programming activity. Luckily, Bracket Pair Colorizer makes this a lot easier by color-coding all corresponding parenthesis and brackets. (NOTE: This one has some known performance issues, and theres a beta version of Bracket Pair Colorizer 2 out to fix this. Thanks for the tip, @garret_alex)
change-case

change-case gives an easy way to change a word or variable name to all sorts of cases including camelCase, snake_case, TitleCase, and more!
Code Spell Checker

Code Spell Checker finds typos and misspelled words, even if they're in the middle of a variable name. This is one I didn't truly realize the value of until I had it installed and started finding all my little typos. Turns out, having a spell checker in a code editor is just as useful as having one in a word processor!
ES7 React/Redux/GraphQL/React-Native snippets

ES7 Snippets has so many useful tools for autofilling in boilerplate text. Saves a ton of time whenever I'm writing imports or React components.
ESLint

ESLint is a great linter that will pick out syntax errors for you in your code to catch issues before you even run your code. Requires configuration of ESLint in your project.
GitLens

GitLens is a feature-packed extension that gives you all sorts of insight into your repository's commit history. Personally, I use it most often to see who wrote code inline, see previous versions of files, and compare HEAD to other commits/branches.
glean

If you're a React developer, you probably often find yourself breaking out large components into smaller ones in separate files as well as switching between class and functional components. glean automates all this for you and automatically inserts all the needed boilerplate.
Import Cost

Import Cost helps you to be cognizant of the size of your imports. It shows the size of each import inline, and shows in red and yellow warning colors if the import is larger than normal.
indent-rainbow

indent-rainbow makes it effortless to see indents at a glance. Plus, it's super pretty, right?
javascript console utils

Find yourself console.log()-ing a lot? javascript console utils automates this for you by inserting console.log() statements into your code, complete with the plaintext variable name and variable value. There's even a hotkey to remove all console.log() statements when you're done with them!
Prettier

This one's important. I'd even go as far as to say that nobody should code without Prettier. Prettier auto-formats your code with alt + shift + F, or you can have it auto-format on every save. This saves a TON of time over remembering every semicolon and indent.
Relative Path

Ever work in a large codebase trying to figure out how to reference another file? Exactly how many ../'s do you need to get back to the proper directory, then what's the path back down? Relative Path lets you search all files and auto-inserts the path relative to the file you're in. No tree counting needed!
Settings Sync
There's not a great way to demo this one, so here's my favorite gif of all time instead: So, about the extension: When you've got a sweet setup in your editor, Settings Sync gives a painless way to sync all your VS Code settings and extensions across your workstations by saving your configuration to a GitHub gist. They've even made several improvements over the past year to make syncing/authentication much easier.
Toggle Quotes

With Toggle Quotes, just use ⌘ + ' (or ctrl + ') to cycle your strings between using `, ', and "
Version Lens

It can be a hassle to keep track of all the latest versions of your npm packages. Version Lens shows you inline how your installed versions in package.json compare to the current versions.

Bonus

These items don't dramatically improve my day-to-day productivity, but golly, I sure do like them:

Dracula Offical – my preferred color theme
file-icons – gives unique file icons to quickly identify types in the file browser. I find it most useful for quickly distinguishing between .ts, .js, .test.ts, & .test.js.
Fira Code – a spiffy-looking font that includes some sweet ligatures! This means that inequality symbols such as <= and !== show up as a single character. It hasn't improved my coding, per se, but it has made me feel cooler. ℹ️ Other ligatured fonts recommended by readers: JetBrains Mono, Cascadia Code, Recursive Sans & Mono

NOTE: Ligatures can be a controversial topic among coders. My argument for using them is that I think they're sexy. I rest my case.

Vim – When I first started coding, I got really into becoming a Vim editor power user. The functionality of VS Code goes far beyond the utility I get from Vim, but sometimes I miss those old "Change 100 lines with 5 cryptic keystrokes" features. I mostly leave this disabled, but I fire it up every once in a while when I'm feeling spunky.

Extensions I no longer use

Sometimes I stop using an extension because the functionality is added to base VS Code, or maybe the extension isn't as useful as I once thought it was. Here are some extensions I used heavily once, but eventually uninstalled:

Indenticator – provided a great way to visually see your indents using highlighted vertical lines. This now comes standard in VS Code, though there are some differences. VS Code Native settings: editor.renderIndentGuides, editor.highlightActiveIndentGuide
Auto-close tag & Auto Rename Tag – automatically provided closing HTML tags whenever you typed an opening tag, and kept them updated to match each other. Most of this functionality is now included in VS Code, and these plugins were known to cause big performance issues (thanks for the tip, Matt Waler). Native VS Code settings: html.autoClosingTags, html.mirrorCursorOnMatchingTag.
Color Highlight – Highlights any CSS color values with the color they represent. VS Code now natively shows a colored box next to the value, which is good enough for me: editor.colorDecorators.

Anything else?

What did I miss? Is there any other extension that helps you be a productive coder? Please let me know in the comments!

Did you find this this article useful? Feel free to subscribe to my articles below or follow me on Twitter for more developer tips and article announcements!

The only 3 steps you need to mock an API call in Jest

Zak Laughton — Sun, 02 Feb 2020 05:51:51 +0000

I recently found myself working in a Javascript codebase where I needed to implement new Jest tests. I knew very little at the time about writing tests, so I looked to Jest docs and existing patterns in the codebase to figure out best practices and how to do it. It was fairly straightforward, and I even found myself enjoying testing. But I could not for the life of me reliably mock an API call.

The docs seemed clear, and the existing code appeared to have good patterns, but there were just so many ways to mock things. The existing tests used all sorts of mocking methods such as jest.genMockFromModule(), jest.spyOn(), and jest.mock(). Sometimes the mocks were inline, sometimes they were in variables, and sometimes they were imported and exported in magical ways from mysterious __mocks__ folders. I used these techniques interchangeably every time I got a burst of confidence in understanding, only to find myself stumbling over the different methods and their effects. I had no idea what I was doing.

The issue

The issue was that I was trying to learn how to run before I even knew how to walk. Jest has many powerful ways to mock functions and optimize those mocks, but they're all useless if you don't know how to make a simple mock in the first place. And while the Jest documentation provides a lot of great insight and techniques, I couldn't figure out where to start.

In this article, I hope to give you absolute basics to mock an API call so you can benefit from my 2020 hindsight (heh). If you're going crazy like I was because you can't figure out how to just make a simple damn mock, Start here…

(NOTE: The code below was written in Node.js, but the mocking concepts also apply to frontend Javascript and ES6 modules)

The unmocked code

We're going to be testing this getFirstAlbumTitle() function, which fetches an array of albums from an API and returns the title of the first album:



// index.js
const axios = require('axios');

async function getFirstAlbumTitle() {
  const response = await axios.get('https://jsonplaceholder.typicode.com/albums');
  return response.data[0].title;
}

module.exports = getFirstAlbumTitle;

...and here's our initial mock-less test for this function, which verifies the function actually returns the title of the first album in the list:



// index.test.js
const getFirstAlbumTitle = require('./index');

it('returns the title of the first album', async () => {
  const title = await getFirstAlbumTitle();  // Run the function
  expect(title).toEqual('quidem molestiae enim');  // Make an assertion on the result
});

The test above does its job, but the test actually makes a network request to an API when it runs. This opens the test up to all sorts of false negatives if the API isn't working exactly as expected (e.g. the list order changes, API is down, dev machine loses network connection, etc.). Not to mention, making these requests in a large number of tests can bring your test runs to a slow crawl.

But how can we change this? The API request is being made with axios as a part of getFirstAlbumTitle(). How in the world are we supposed to reach inside the function and change the behavior?

Mock it in 3 steps

Alright, here it is. This is the big secret that would have saved me mountains of time as I was wrestling with learning mocks. To mock an API call in a function, you just need to do these 3 steps:

1. Import the module you want to mock into your test file.
2. jest.mock() the module.
3. Use .mockResolvedValue(<mocked response>) to mock the response.

That's it!

Here's what our test looks like after doing this:



// index.test.js
const getFirstAlbumTitle = require('./index');
const axios = require('axios');

jest.mock('axios');

it('returns the title of the first album', async () => {
  axios.get.mockResolvedValue({
    data: [
      {
        userId: 1,
        id: 1,
        title: 'My First Album'
      },
      {
        userId: 1,
        id: 2,
        title: 'Album: The Sequel'
      }
    ]
  });

  const title = await getFirstAlbumTitle();
  expect(title).toEqual('My First Album');
});

What's going on here?

Let's break this down. The most important part to understand here is the import and jest.mock():



const axios = require('axios');

jest.mock('axios');

When you import a module into a test file, then call it in jest.mock(<module-name>), you have complete control over all functions from that module, even if they're called inside another imported function. Immediately after calling jest.mock('axios'), Jest replaces every function in the axios module with empty "mock" functions that essentially do nothing and return undefined:



const axios = require('axios');
jest.mock('axios')

// Does nothing, then returns undefined:
axios.get('https://www.google.com')

// Does nothing, then returns undefined:
axios.post('https://jsonplaceholder.typicode.com/albums', {
    id: 3,
    title: 'Album with a Vengeance'
})

So now that you've eliminated the default behavior, you can replace it with your own...



  axios.get.mockResolvedValue({
    data: [
      {
        userId: 1,
        id: 1,
        title: 'My First Album'
      },
      {
        userId: 1,
        id: 2,
        title: 'Album: The Sequel'
      }
    ]
  });

The mocked replacement functions that Jest inserted into axios happen to come with a whole bunch of cool superpower methods to control their behavior! The most important one here, for the purposes of a simple beginner mock, is .mockResolvedValue(). When you call this on a mocked method, anything you pass in will be the default return value when the mocked function is called for the remainder of the test. Simply put: you can make axios.get() return whatever you want! And it doesn't matter whether it's called directly in your test file or as a part of a function imported into your test – Jest will mock the function no matter where it's called!

Use this newfound power to give your functions exactly what they should expect from the API calls. Stop worrying about what the network requests return, and just focus on what YOUR code does once it gets the response!

If you want to play around with the examples, feel free to use this demo repository:

ZakLaughton / DEMO-simple-api-mocking-with-jest

A simple API mocking example with Jest.

Wrapping up

There you have it! This is the very basics of what you need to mock functions from another module: import the module, jest.mock() the module, then insert your own return values with .mockResolvedValue()!

I recommend starting here, using only these techniques as you start building out your first mocks for your network calls. Once you have a foundational understanding of what's going on here, you can slowly start adding the other robust mocking features included in Jest.

See also: Mocking Modules (Jest documentation).

EDIT: Also, be sure to clear your mocks between tests by running jest.resetAllMocks() after each test. This will help ensure your mocks won't interfere with future tests. (Thanks for pointing this out, @mjeffe!)

Where to go from here

Alright, you've learned the basics of mocking and successfully implemented the strategies above in several tests. You can import and mock resolved values for all your API calls like an old pro. What's next?

While the methods described above will cover most simple use cases, Jest has a lot of mocking functionality and methods to do some really powerful things. You can incrementally add some of the concepts below to super-charge your mocks:

Check out the other mock function methods listed in the Jest docs: Mock Functions. You can use methods such as mockReturnedValue() to mock synchronous returns and mockResolvedValueOnce() to only return a value the first time it's called.
Want to see how many times a mocked function is called, what it was called with, and what it returned? Check out the mock.calls and mock.results properties (also in the Mock Functions documentation)
Do you have your own custom functions that make network requests? You can mock your own modules too after they're imported into the test file: jest.mock('./path/to/js/module/file')! Careful here though that you're only mocking what's necessary. Your tests should make sure your functions do what's expected with a given mock input, and it can be easy to end up writing tests that instead just confirm you passed in mocked data.
Want a function to act as it was originally written, but still want to see how many times it was called? Check out jest.spyOn().
Find yourself mocking the same function over and over in multiple tests? Give it default mock responses in __mocks__ folders using Manual Mocks!

I hope this saves others some of the wasted time and frustration I went through! If anything doesn't make sense here, please leave a comment and I'd be happy to try to answer any questions. Also, let me know if there's anything else that helped you have an "Aha!" moment while learning to mock!

_Did you find this this article useful? Feel free to subscribe to my articles below or [follow me on Twitter](https://twitter.com/ZakLaughton) for more developer tips and article announcements!_

Get data from your URL into your React app with React Router

Zak Laughton — Fri, 27 Sep 2019 14:44:04 +0000

In trying to learn React Router URL parameters, I had a hard time finding clean, no-frills examples. Now that I have a better understanding, I'm putting a plain, dead-simple example here to help others.

The end product

I am going to show you how to create a site that takes 3 parameters from the URL, and passes them into a React component to display on the screen.

Prerequisites

Basic understanding of building with React
A react project with react-router-dom installed (Create React App is a great tool to spin up a React application)

The code

This is the full index.js file, and pretty much everything you need to set up the site (see the full repository here):



import React from 'react';
import ReactDOM from 'react-dom';
import { BrowserRouter, Route } from 'react-router-dom';
const AppRouter = () => (
  <BrowserRouter>
    <Route
      path='/:parameter1/:parameter2/:parameter3'
      render={props => <App {...props} />}
    />
  </BrowserRouter>
);
const App = props => {
  const { parameter1, parameter2, parameter3 } = props.match.params;
  return (
    <div>
      First: {parameter1} <br />
      Second: {parameter2} <br />
      Third: {parameter3} <br />
    </div>
  );
};
ReactDOM.render(<AppRouter />, document.getElementById('root'));

What's going on here?

We're basically wrapping the entire application in a <BrowserRouter> component, calling a <Route> component for a given URL, and passing the parameters from the URL into <App> as props. Lets dig into each piece…

`<BrowserRouter>`



const AppRouter = () => (
  <BrowserRouter>
    ...
  </BrowserRouter>
);

In order to use <Route>, it must have <BrowserRouter> (or one of the other router types) somewhere as a parent. React Router uses this higher order component to help do its routing magic in the background. There's no component configuration required here – all you need to do is be sure everything is wrapped in <BrowserRouter> open/close tags.

<BrowserRouter> documentation

`<Route>`



<Route
  path='/:parameter1/:parameter2/:parameter3'
  render={props => <App {...props} />}
/>

Here's where the meat of the work is being done. is a component that decides what component to show based on the URL.
path='/:parameter1/:parameter2/:parameter3' tells React Router to use this component whenever the URL has a path with 3 items separated by slashes after the base URL (for example, tvshows.com/series/season/episode). The parameters, such as :parameter1, are variables to assign that part of the URL to and pass into the rendered component.
render={props => }renders the component with the props passed in from the route, which will include the parameters set in the path in the line above

<Route> documentation

`<App>`



const App = props => {
  const { parameter1, parameter2, parameter3 } = props.match.params;
  return (
    <div>
      First: {parameter1} <br />
      Second: {parameter2} <br />
      Third: {parameter3} <br />
    </div>
  );
};

Since <Route> is rendering this <App> component, it's also passing in the props it needs. <Route> passes several props by default, but the one part of the props we're concerned about here is match.params. Whenever you use <Route> to render a component, you can always find the URL parameters in props.match.params.

The <App> component uses object destructuring to assign local variables for all the parameters passed in props.match.params, then uses these variables to display the data from the URL. That's it!

Wrapping up

Once you get the hang of using URL parameters, you can do some pretty powerful things with rendering the application based on the exact URL the user is visiting. It's even a handy way to lift up state in certain cases where you have multiple lower-level components sharing the same state that's also reflected in the URL.

Questions? Comments? Concerns? Let me know! Comment below or tweet me @ZakLaughton.

_Did you find this this article useful? Feel free to subscribe to my articles below or [follow me on Twitter](https://twitter.com/ZakLaughton) for more developer tips and article announcements!_

DEV Community: Zak Laughton

Zak's Top 5 Habits for Success

1. Seek first to understand, then to be understood

2. Assume positive intent

3. Have a system for getting things done

4. Have a budget

5. Read

Getting your first website on the internet is easier than you think!

GitHub pages

Static files with GitHub Pages

Framework sites with GitHub Pages

Custom URL

Using subdomains

What if my site needs a server?

Summary

Git deep-dive: "git init"

What you might know

What you might not know

💡 How the repository is initialized

💡 ALL repository data is stored in .git/

💡 Create a "remote" repository with --bare

💡 Shhhhhh

Wrap-up

3 ways to time travel in Git to undo destructive mistakes

Setup

Examples

1. Reset using a reflog reference

2. Reset to ORIG_HEAD

3. Reset to a relative time

Caveats

Recap

The only 4 Regex Notations You Need To Know (to start) ❤️

Most useful regex notations

1. Simple text search

2. Wildcard .*

3. Capturing groups and backreferences ()

Word boundary \b

Wrap-up

Every VS Code extension a JavaScript web developer should have in 2021 (with gifs!)

Must-have extensions (alphabetical)

Better Comments

Bookmarks

Bracket Pair Colorizer

change-case

Code Spell Checker

ES7 React/Redux/GraphQL/React-Native snippets

ESLint

GitLens

glean

Import Cost

indent-rainbow

javascript console utils

Prettier

Relative Path

Settings Sync

Toggle Quotes

Version Lens

Bonus

Extensions I no longer use

Anything else?

The only 3 steps you need to mock an API call in Jest

The issue

The unmocked code

Mock it in 3 steps

What's going on here?

ZakLaughton / DEMO-simple-api-mocking-with-jest

A simple API mocking example with Jest.

Wrapping up

Where to go from here

Get data from your URL into your React app with React Router

The end product

Prerequisites

The code

What's going on here?

<BrowserRouter>

<Route>

<App>

Wrapping up

💡 ALL repository data is stored in `.git/`

💡 Create a "remote" repository with `--bare`

1. Reset using a `reflog` reference

2. Reset to `ORIG_HEAD`

2. Wildcard `.*`

3. Capturing groups and backreferences `()`

Word boundary `\b`

`<BrowserRouter>`

`<Route>`

`<App>`