DEV Community: Mike Ekkel

What do you think it means to be a Senior Developer?

Mike Ekkel — Thu, 15 Apr 2021 13:19:21 +0000

Let's discuss what people's interpretation of a senior developer is.

Slice and splice: explained

Mike Ekkel — Sun, 31 Jan 2021 18:08:46 +0000

While .slice() and .splice() are incredibly useful, the similarity of their names can cause a lot of confusion for beginner and seasoned developers alike. This post will explain the difference and, hopefully, give you the confidence to use them in your code!

Slice

Slice is the easier of the two to explain, since it only does one thing, so I'll start there.

Array.slice(startIndex, endIndex) will return a copy of the array from startIndex up until (not including) the endIndex you've provided without changing the original array. If you don't provide an endIndex, it will go until the end of the array.

const week = [
  "Monday",
  "Tuesday",
  "Wednesday",
  "Thursday",
  "Friday",
  "Saturday",
  "Sunday",
];
const weekend = numbers.slice(5); // Will return ["Saturday", "Sunday"]
const weekdays = numbers.slice(0, 5); // Will return ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"]

Splice

There are three things you can do with splice:

Remove part of the array
Replace part of the array with a new value
Insert something new anywhere within the array

The syntax for splice is: Array.splice(startIndex, deleteCount, replacingItems). I'll show you what they mean based on the three things you can do with splice. The only required parameter is startIndex.

Splice has a major gotcha that you need to be aware of: splice changes the original array.

Removing part of the array

Let’s say you are running a race and there are 6 finishers. To figure out who to give a trophy, you want to eliminate everyone except the top three. Everyone outside of the top three will get a medal.

// Top three trophies
const finishers = [1, 2, 3, 4, 5, 6];
finishers.splice(3);
console.log(finishers); // [1, 2, 3]

// Medals outside of top three
const finishers = [1, 2, 3, 4, 5, 6];
finishers.splice(0, 4);
console.log(finishers); // [4, 5, 6]

The above example can be done in a single go because Array.splice() returns the deleted portion of the array. This is what that would look like:

const finishers = [1, 2, 3, 4, 5, 6];
const medals = finishers.splice(3);

console.log(finishers); // [1, 2, 3]
console.log(medals); // [4, 5, 6]

Replacing part of the array with a new value

Let’s say you want to fix the following array:

const months = ["January", "September", "March", "April"];

Obviously, "September" is wrong and you want to replace it with "February". Here’s what that would look like:

// Array.splice(startIndex, deleteCount, replacingItems)
const months = ["January", "September", "March", "April"];
months.splice(1, 1, "February");

console.log(months);
// ['January', 'February', 'March', 'April']

Inserting something new anywhere within the array

Using the same example as above, let’s say you forgot to add a month in your array:

const months = ["January", "March", "April"];

If you want to add ”February" to the array, you can use the exact same code as replacing part of the array but this time you set the deleteCount to 0:

// Array.splice(startIndex, deleteCount, replacingItems)
const months = ["January", "March", "April"];
months.splice(1, 0, "February");

console.log(months);
// ['January', 'February', 'March', 'April']

Wrapping things up

While slice and splice have incredibly similar names and return values, they are used entirely different and have different use cases. I hope this post has been helpful to you.

Hit me up if you find anything unclear or confusing. I’d be happy to explain it to you in more detail and will update this post accordingly!

What Javascript features are the most confusing to you?

Mike Ekkel — Sun, 17 Jan 2021 08:33:36 +0000

In an effort to help out aspiring developers, I’m interested in hearing about what you think the most confusing parts of Javascript are.

I’ll try my best to explain a concept and, hopefully, others will chime in 😊.

This is a safe space, which means all questions are good questions!

How to work on dependency code using NPM link

Mike Ekkel — Fri, 21 Aug 2020 15:01:14 +0000

You might, at some point, find yourself in a situation where you have to work in dependency code. There might be a bug in the dependency, functionality might be extended, or perhaps the code needs refactoring to be more performant.

You could use npm pack to create a dependency.tgz package file when you're ready to test your changes. You would have to link to that file inside your package.json like so:

"dependencies": {
    "component-library": "./path/to/dependency.tgz"
  },

The problem with this approach is that you would have to pack your files every single time you want to test your changes, and you have to remember to put your package.json back the way it was.

Introducing NPM link

I personally think npm link is a cool feature. It creates a symbolic link (symlink) between a package and where you want to use that package. In other words: it connects a package you have locally on your machine to the project you need it in.

Usage

Package linking is a two-step process:

Create a symlink¹, or symbolic link, in the global folder by running npm link.
Tell NPM in your application to use the global symlink using npm link DEPENDENCY_NAME.

cd ~/projects/dependency
npm link

cd ~/projects/application
npm link dependency

From here on out you can make changes in your dependency's code as you would normally do. Meanwhile, your application will run with the changes you've made without having to update the dependency. Pretty cool, right?!

When you decide your changes are good to go and you're ready to update the dependency, you may want to delete the symlink.

⚠️ Unlinking a dependency with NPM unlink ⚠️

While there is a command called unlink, it doesn't actually behave as you might expect. The npm unlink command is an alias for npm uninstall² and you want to be very careful when using it to delete the symlink.

If you want to properly remove the symlink without uninstalling the package, you'll have to run the command with the --no-save flag:

npm unlink --no-save dependency

This will uninstall the dependency without removing it from your package.json. All that's left to do now is to install the dependency as it's listed inside package.json:

npm install

Good to know

List all linked packages

If you want to find out what packaged you have linked, run this command:

npm list -g --depth=0 --link=true

Speed up unlinking

This might seem obvious for a CLI power-user, but you can unlink and install in one go by chaining commands! Here's how to do that:

npm unlink --no-save dependency && npm install

Final words

I use npm link all the time while working on dependencies for my team. We rely on a bunch of libraries that we've created ourselves and using npm link makes improving them a whole lot easier and faster.

It's been a while since I've written a post, but I hope you've enjoyed it and found it useful!

A symlink is a reference, or shortcut, to another file or directory on your system. ↩
NPM: npm - uninstall ↩

CSS Combinators: explained and visualized

Mike Ekkel — Sun, 07 Jun 2020 14:00:38 +0000

Selectors help us target a specific HTML element we want to apply styling to on our page. There are many selectors available to us, allowing for very precise control over styling. The combinator is a type of selector that combines different selectors and gives them a useful relationship to each other.

Sometimes we want to style based on the relationship between two elements. On my blog, for example, paragraphs have different styling when it immediately follows a heading. This is exactly what combinators allow us to do.

In this post, we're going to take a closer look at each of the four combinators: descendent, child, general sibling, and adjacent sibling. We'll look at example code as well as visualizations of how the combinators work.

Descendent combinator

The descendent combinator — represented by a ‎‏‏‎ ‎‎ (space) — will select all elements that are descendants of the first element. This is useful for when you want to change the styling of a component for a specific part of the page but not anywhere else on the page.

Example

An example of this would be div.content span will match all <span> elements inside the <div class='content'>. Let's say we have the following CSS:

span {
  background-color: red;
}

div.content span {
  background-color: green;
}

The <span> element has a red background in the above example. However, when a <span> element is inside of a <div class='content'> it will have a green background. To give you a better understanding of this, I've visualized it:

It doesn't matter if a <span> element is a direct descendant of <div.content> or not. As long as a parent, somewhere up the DOM tree, is <div.content> it will have a green background color. This is not the case for our next combinator, though.

Child combinator

The child combinator — represented by a > — will select all elements that are direct descendants, known as children, of the parent element. This is perfect for when you want to style, for example, a list within a list. Perhaps to-do items need to be bold and nested to-do items need to be a normal weight*.*

Example

Going back to our previous example, the descendant combinator, we can easily highlight the behavior by changing the combinator! So let's use the exact same code, but this time we're going to use the child combinator.

span {
  background-color: red;
}

div.content > span {
  background-color: green;
}

Just like before, the <span> element has a red background. When a <span> element is a child of a <div class='content'> it will have a green background. However, if the <span> element is nested deeper it will still be red. Let's visualize that:

As soon as the <span> element is separated from its parent by being nested a level deeper, it will not be selected by the child combinator.

General sibling combinator

The general sibling combinator — represented by a ~ — will select all siblings that follow the first element. The sibling element doesn't have to directly follow the first element but they need to share the same parent element.

An example of this could be styling the paragraphs differently after using the first <h2> element of an article. Usually, the content before that first <h2> element is an introduction and you may want to have that in italics.

Example

Let's apply different styling to the <p> elements after using the first <h2> element.

p {
  background-color: red;
}

h2 ~ p {
  background-color: green;
}

Any <p> element after <h2>, as a sibling, will have a green background. All other <p> elements will have a red background. Just like before, it's easier to see what's going on by visualizing it:

There's not much else to it. All <p> elements after the <h2> element, provided they share the same <article> element as a parent, will have a green background. If a <p> element is used before, or if it's nested, it will have a red background.

What if we just want to style the first <p> element that follows the <h2> element? Well, that's where our final combinator comes into play.

Adjacent sibling combinator

The adjacent sibling combinator — represented by a + — will only select the direct sibling of the first element. This means that, unlike the general sibling combinator, the sibling needs to immediately follow the first element and share the same parent element.

A use case for this is when you want to change the margin-top of the first <p> element following an <h2> element. On my blog, for example, the first paragraph following a heading has less margin at the top than the others. This allows the <h2> element to sit more closely to the content it's the heading of.

Example

Using the previous example of <p> elements following an <h2> element, let's apply a different style to the <p> that immediately follows an <h2>.

p {
  background-color: red;
}

h2 + p {
  background-color: green;
}

All <p> elements will be red, except for the ones that immediately follow an <h2>. Again, to visualize this:

As you can see, the final <p> element returns to the default red background.

The adjacent sibling combinator is probably my favorite of the four combinators outlined in this post. My blog converts my markdown written posts into HTML, which means all content elements are siblings of one another. The adjacent sibling combinator allows for fine control over styling in specific scenarios related to my content.

Combinators & CSS Specificity

Combinators have no impact on the specificity of your styling.

That's it... that's all there is to know about combinators in relation to CSS specificity. Not much of an exciting ending. I feel it's important to know that it doesn't, though. At first glance, using combinators appears to make your CSS more specific. While this is definitely true for you, the writer/reader of the code, this isn't true for calculating CSS specificity.

If you want to know more about CSS specificity and what does, or doesn't, have an impact, read this amazing post about CSS Specificity by Emma Bostian.

Final thoughts

Sometimes code snippets don't help me figure out what's going on. This is when I start visualizing the behavior of my code. Visualizing it helps me figure out how it works and hopefully it's been helpful to you too!

I hope you've enjoyed reading this post. Until next time 😊

Five Git commands I started using that might be helpful to you

Mike Ekkel — Sat, 30 May 2020 14:15:33 +0000

Git is a powerful tool I use every single day. Up until a few months ago I only used the bare minimum to get my job done. When I moved to a different company, with a much larger team, I quickly figured out there was so much of Git I didn’t know about and wasn’t using.

Nowadays I feel much more confident and I’ve learned a bunch of helpful new things! While I won’t go into the basics of Git, because there are many great resources out there to help you with that, I’d like to show you five commands that I think are very useful and may save you a few headaches. They certainly saved some for me.

Let’s dive in!

Amend: changing the commit after committing

You commit something and you immediately realize your commit message isn’t clear enough or doesn’t adhere to the commit message formatting rules of the project. Maybe you realized you needed to add one small change, like removing that silly little console.log(), or maybe you forgot to add a new file.

Does any of the above sound familiar? It definitely sounds familiar to me and has happened a few times! Luckily, there is a way for you to change, or rather update, your latest commit before you push it using --amend.

There are two parts to a commit that you may want to change, the first one is the commit message and the second one is a file. Let’s start with changing the commit message.

Changing the commit message

In it’s most basic form, the command to change your commit message looks like this:

git commit --amend

This will open your configured code editor for Git and allow you to change the commit message. You can, however, change the commit message without opening the editor:

git commit --amend -m "Your updated commit message"

Adding the -m flag, followed by the updated message in quotes, allows you to change the message without opening the editor.

Amending a change or file

Let’s say you notice a rogue console.log() after you’ve committed and you want to remove it. Edit the file and stage it like you normally would for a commit. Then run the following command:

git commit --amend --no-edit

This will amend the file to the commit. The —no-edit flag allows you to do this without changing the commit message.

⚠️ Caveat

Using —amend doesn’t change the commit. Instead, it replaces the commit with a brand new one. As such it is incredibly important you don’t amend public commits. Your local commits are perfectly fine.

Checkout: reverting a single file

Recently I did a pull request for a new feature I was working on. Part of my work was to remove some old styling in a legacy file. When I deleted the 8 lines of styling and hit save, I automatically ran prettier because that’s how I’ve set up my IDE.

The result was a little over a thousand changes making it impossible to figure out what it was that I actually changed myself. I completely missed this had happened and joyfully opened a pull request ready for review. Oops 😅.

I had to revert that file, make sure prettier wasn’t running, make my changes, save it, and commit it to the branch so it could be reviewed properly. Luckily git checkout comes to the rescue!

To revert a single file back to a previous commit, you run the following command:

git checkout <commit_hash> -- <path/to/file>

First find the commit that holds the changes you need to revert to, this is most likely 1 commit before the commit you need reverting, then figure out what the path to that file is (easiest way is to copy the relative path in your code editor).

Your file is now reverted to what it was on the commit you picked out. In my case: before I removed the styling and ran prettier. Phew, crisis solved 🥳.

Remote: add another remote repo

I’m going to outline this part with a hypothetical situation based on real events.

Imagine you are currently working on a new feature and you’ve got a co-worker, let’s call her Kate, who’s working on something that you need to integrate into your feature. You are both working in a fork of the central repository of your team and you need to pull in the latest changes Kate has made on her fork.

When you cloned your forked repository to your system, Git automatically created a remote connection named: origin. You may already know this, but did you know you can add Kate’s repository as a remote connection as well? This is great for when you want to pull in changes Kate made without her having to push to the central repository.

Let’s look at how to add Kate’s repository to your list of remote connections, we’ll go into fetching her changes in the next section. Here’s how to add her repository:

git remote add <name> <url>

The name can be anything you want. I usually stick to using my co-worker’s names or Github usernames. The url is the URL to her repository, for example: git@github.com:Kate/acme-fork.git. Putting that together:

git remote add kate git@github.com:Kate/acme-fork.git

If you run git remote, which will list all of the remote connections, you’ll see Kate’s remote repository.

Remote: fetching a branch from the remote branch

To fetch a specific branch from a specific remote, you run the following command:

git fetch <remote> <branch>

In the previous section we talked about adding Kate’s repository to your remote connections. Kate was working on something in a branch called new-feature. Using the above command, that would look like this:

git fetch kate new-feature

Running the command will fetch Kate’s branch and save them locally in kate/new-feature. What’s going on here is that remote branches you fetch are available using <remote-name>/<branch-name>.

To merge Kate’s changes into your branch, you have to git checkout your branch and then merge the branch you just fetched:

git merge kate/new-feature

Kate’s branch is now merged into your branch 👍.

Checkout: creating a branch based on another branch

I was recently working on rewriting a feature using a different library than the one in use on production. Aside from rewriting the code, new functionality needed to be added as well. I tackled this in two steps:

Rewrite the feature as it currently works in production and have my code reviewed to make sure I didn’t miss anything.
Add new functionality.

For step one I created a branch for the rewrite called feature-rewrite. Well it was a little more elaborate than that, but you get the point! You may be familiar with doing this from the CLI, but if not this is how you’d do that:

git checkout -b feature-rewrite

The -b flag tells Git to run git branch feature-rewrite if the branch doesn’t exist yet before checking out that branch, pretty neat 😄.

While I was waiting for the code to be reviewed, I continued with adding new functionality. This had to be done based on the rewrite I just did. In other words: I had to create a new branch based off of the feature-rewrite branch. Here’s how to do that:

git checkout -b new-functionality feature-rewrite

The checkout command takes a second parameter to let Git know what branch to base the new branch off of. To give you a clearer picture of this:

git checkout -b <new-branch> <existing-branch>

Final words

Over the past few months I have learned a lot of new things about Git and how you can use it to your advantage. The commands outlined in this post are by far the most useful and have been a real lifesaver for me.

Thank you for reading this post and I hope it’s been helpful!

This post was originally published on my own blog: https://www.mikedecodes.com/blog/five-git-commands-i-started-using-that-might-be-helpful-to-you

Seven lessons learned during my first year of being a developer

Mike Ekkel — Fri, 22 May 2020 17:38:58 +0000

This month marks my first anniversary of being a frontend developer after switching over from design. There are so many things I learned along the way. Things from a technical point of view, a professional point of view, and from a personal point of view. In this post I want to share seven things I learned during my first year of being a developer.

1. Google is your best friend

Okay, you got me. This one’s a bit of an easy hit. As cliché as it sounds, though, it’s true! You will be googling a lot and that’s okay. It will help you learn new things, it will help you find things you need faster and it will help you remember some things faster.

I’ll be honest, there are things you will be googling from now until the end of time. In my experience it’s the things you use once every couple of months that need googling the most. The worst part about it isn’t having to use Google, it’s the fact Google will show you that you’ve been there before and you just can’t seem to remember 😅.

2. Take notes

I don’t know about you, but I can’t remember every single thing that was discussed in a meeting, said to me at some point in time, or everything I’ve discovered about a topic I am researching. So I started taking notes. About everything.

There are many different ways of taking notes and not all of them will work for you. I’ve tried a lot of methods and I finally found one that works well for me. I’ve also tried many different note-taking apps and notebooks. Eventually finding the one that works for me.

A quick Google search will help you find all the different methods of taking notes. I use a combination of the outline method, sentence method, and mapping method. I picked out the parts that worked for me and combined them!

I use a Moleskine squared notebook for handwritten notes as it gives me a grid to work with if I ever need to structure stuff and I use Bear for my digital note-taking needs.

3. Ask for help

I’ve fallen into this trap a few too many times; not asking for help sooner. Sometimes you just can’t figure it out on your own. You’ll feel like you’ve read every single link on Google, tried every solution and it just won’t work. That’s where your fellow developers come in!

Don’t be afraid to ask for help, because there’s a good chance they have run into the same problem and will be able to help you. Even if they haven’t experienced the same problem, they will be your extra pair of eyes and you can pair program the solution or they can even be your rubber duck!

No, seriously, I have solved so many problems by simply explaining to someone what is going on and while I was doing so I realized what the problem was and how to solve it.

Asking for help isn’t the only way to help you solve your problems, tho.

4. Step away from the code

There’s something magical about spending hours and hours on something, coming back the next day, and all of a sudden it makes sense so now you spend two minutes solving it.

I’ve discovered I can sort of force this moment by taking regular breaks from coding. The problem with grinding away at your code is that you start to develop tunnel vision and you lose sight of the bigger picture. This makes problem-solving a little more difficult. To counter this I’ll get up and go for a short walk around the office every hour or so.

Not only is this great for your health, but you will come back to your code with a fresh pair of eyes and things will make a lot more sense! At least to me it does. This means my productivity has, despite taking more breaks, gone up.

5. You will learn from failing

Eventually, one way or another, you are going to fail. I know I did. Here’s the cool part, though. Moments of failure are moments of learning. Every time something doesn’t work out the way you thought it would, you know that’s not the way to do it. You go back into it, figure out why it went wrong and you’ll be better for it!

Think of it like learning to walk. When we learned to walk as a little kid, we would fall… a lot. We got back up, put our foot in front of the other, and fall again and again. Until we didn’t fall anymore and ran away with our toys because they are mine.

6. Learn to read other people’s code

I firmly believe that one of the most important skills you can have as a developer is the ability to learn other people’s code. Working in teams, working on a shared project, or even coming back to code you’ve written ages ago means you’ll be looking at code that is unfamiliar to you.

It will help you do code reviews faster, it will help you learn new ways of doing things, it will help you think about how this person is solving problems and, most importantly, it will solidify some of the knowledge that you might be struggling with.

Try and read other people’s code as soon as possible! I only started doing this recently, so I am still struggling at times, but it’s incredibly valuable already.

7. Celebrate your (tiny) wins

Most of the time our job is about solving problems. How can you get that element to be over there while this element stays here? How can I get this data to that place? Is there a way I can make this bit of code run faster? How can I solve this bug?

No matter how big or small the problem is, solving it feels like a win! Celebrate the wins by sharing them with your team, posting them on twitter, sharing them with your spouse, giving yourself time to do something else, relax, or whatever you can think of.

By celebrating the wins I’ve built confidence and kept myself motivated to tackle the next problem.

Final words

This was just a small selection of what I've learned during my first year as a frontend developer. I hope you've enjoyed reading this post and found some use in the things I've learned.

How do you keep track of your goals?

Mike Ekkel — Mon, 09 Mar 2020 15:20:13 +0000

When it comes to getting things done there are so many sources to look for inspiration on how to manage and keep track of that. For your own goals, however, I haven’t really found a great resource just yet.

This leads me to ask you all:
How do you keep track of your goals?

They could be personal or professional. So basically ranging from “I want to read more” to “I want to write more technical blog posts”. Share your thoughts, tools and approaches and let’s discuss them.

Which productive activities are typically seen as unproductive?

Mike Ekkel — Wed, 28 Aug 2019 11:44:21 +0000

Inspired by the following post:

Which unproductive activities are typically mistaken for productivity?

Ben Halpern ・ Aug 27 '19

#discuss #productivity

I sometimes find myself in a situation where I'm being called out for doing something that's 'unproductive' when in reality it's helping me be more productive. Be it reading about some sort of coding related problem I am facing or sorting out my backlog so I can get my priorities straight.

So, what productive activities are typically seen as unproductive?