DEV Community: Gunnari Auvinen

Print emojis to the terminal in C

Gunnari Auvinen — Mon, 29 Jun 2026 12:54:00 +0000

Recently I've started to work on building my own shell in C, which is one of the projects for the CSI class I'm taking. The first thing I had to decide is what would be the appearance of my shell. You may be asking yourself, "What would I want as part of my shell's appearance?" The answer should be obvious! Emojis are clearly the only correct answer 🚀

For now, I'm going to call my shell unishell. I bet you've guessed which emoji will be part of prompt. If you guessed 🦄, you'd be correct! After I made this choice I realized that I wasn't entirely sure how I'd print out the emoji, as those clearly weren't covered in K&R.

Looking online I was able to find the Unicode sequence for the unicorn, which is U+1F984. I knew that I'd need an escape sequence to print it in C, but I wasn't sure exactly what it was. After a bit of searching I found out that there are two escape sequences, which are \u and \U.

The \u is used for unicode characters that can be encoded in four hex characters. On the other hand, \U is used for unicode characters that are five or more hex characters long. Initially I didn't realize there was a \U escape sequence, so I tried using u1F984, which didn't turn out exactly as planned 😅 The code for the first attempt is below.

// unishell.c
#include <stdio.h>

int main() {
    printf("\u1f984");
    return 0;
}

When I ran the emoji1 executable file, I got this output 😬

At first I was scratching my head for a moment, but then I realized it made sense. The unicorn emoji is five hex characters long and the translation on the screen is the first four characters translated to one character, with the leftover 4 getting printed as a 4. It turns out that U+1F98 is the Greek capital letter Eta.

Following that incorrect solution, I tried to change the \u1F984 to a \U1F984, but CLion showed that was an error. Unfortunately it didn't say what the error was 🤦🏼‍♂️ It turns out that you must pad the front of the Unicode characters with 0s until there are eight characters plus the escape sequence, which is \U0001F984. With this update, I got the output below 🎉

Here's the final code for reference.

#include <stdio.h>

int main() {
    printf("\U0001f984");
    return 0;
}

With this solved, I can get onto the rest of the unishell implementation!

Call vs. Apply in JavaScript

Gunnari Auvinen — Mon, 22 Jun 2026 12:39:00 +0000

Both call and apply allow you to invoke a specific function and pass in a context, that will be this within the function, as well as arguments. How you pass in the arguments for each method is different though and can certainly lead to frustration as you work to debug your code. Having spent some time debugging my own code due to this confusion, I figured it was worthwhile to write a blog post about it for reference, even if I'm the only one that refers to it in the future!

Call

As stated previously call allows you to invoke a function, pass in your desired context as the first argument, as well as your input arguments. In the case of the call method, you pass in the arguments individually and separated by commas.

One instance where it can be beneficial to use call is when creating subclasses within JavaScript. Specifically if your subclass shares traits with your superclass, you can use call on the superclass to set the properties on the subclass. Here's a quick example.

var Business = function(name, location) {
  this.name = name;
  this.location = location;
};

var Restaurant = function(name, location, type) {
  Business.call(this, name, location);
  this.category = 'Restaurant';
  this.type = type;
};

Restaurant.prototype = Object.create(Business.prototype);
Restaurant.prototype.constructor = Restaurant;

var SupplyStore = function(name, location, type) {
  Business.call(this, name, location);
  this.category = 'Supply Store'
  this.type = type;
};

SupplyStore.prototype = Object.create(Business.prototype);
SupplyStore.prototype.constructor = SupplyStore;

var pizza = new Restaurant('House of Slices', 'Your Neighborhood', 'Pizza');
var officeSupplies = new SupplyStore('All Your Office Supply Needs', 'Next town over', 'Office Supply Store');

Another quick example of using call is when you can use it to convert the arguments array of a function input from an array-like object to an array.

var addNumbers = function() {
  var inputs = Array.prototype.slice.call(arguments, 0);
  return inputs.reduce(function(previous, current) {
    return previous + current;
  }, 0);
};

var total = addNumbers(1, 2, 3, 4);
console.log(total); // 10

Apply

Now that I've discussed call, you might wonder how apply is any different, as they ostensibly do the same thing. apply still takes a context as its first argument, but instead of taking individual arguments after that, apply takes an array or array-like object instead.

In this somewhat contrived example, if you wanted to print out the character code for each letter in an array of unknown length, you could use apply to invoke that function.

var testStringChars = 'hello there!'.split('');
var printCharacters = function() {
  for (var i = 0; i < arguments.length; i++) {
    console.log('character code for "' + arguments[i] + '" is ' + String.prototype.charCodeAt.call(arguments[i]));
  }
};

printCharacters.apply(this, testStringChars);

Takeaway

The main takeaway here is that both call and apply both allow you to invoke functions and supply the context that it should be invoked with. The fundamental difference between the two is how the input arguments are passed in when invoked. call takes its input arguments as individual inputs, while apply takes an array or array-like object. If you have a good example for apply please let me know!

How to undo a git rebase? Hint: git reflog and git reset

Gunnari Auvinen — Mon, 15 Jun 2026 12:17:00 +0000

The other day at work a group of us were asked if any of us were Git masters, at which point my ears perked up and I asked him to explain what exactly he needed help with at that moment. He then told me that a teammate had lost roughly a half-days worth of work after a bad git rebase and he wanted to know if it was possible to recover their lost work. Now while I'm not a Git master, I vaguely remembered something from a lecture and told him that I would look into it and get back to him in a few minutes.

After a couple of minutes of searching I managed to find the information that I was searching for to "save the day." What I had discovered was that Git keeps track of the tips of branches and when they're changed and this information can be accessed via the git reflog command. In this case the git reflog command allowed us to find the reference to the commit that had been made prior to the bad git rebase. The reflog had the various messages associated with the branch tip changes and in our case we looked for the last commit message that had been entered prior to the rebase, which had a reference similar to HEAD@{7}. Having this reference allowed us to use the git reset --hard HEAD@{7} command to go back to that specific commit. With a little bit of searching we fortunately saved hours worth of work!

As this concept can be a little bit nebulous in just text I've provided an example below to help flush things out.

Example of How to Undo a git rebase

For this example I made a little git repository that uses master and the amazing-feature branch for us. Here is a printout of a git log --oneline command before the git rebase is done, while in the amazing-feature branch.

98008d5 Add the divide function to amazing-feature.
93c18de Add multiply function to amazing-feature.
abdc941 Add amazing-feature.
18244f8 Add the add function to first-feature.
3a01fc1 Add the amazing first-feature.

Next I did:

➜  git-reflog-git-rebase-example git:(amazing-feature) git rebase master

First, rewinding head to replay your work on top of it...

Applying: Add amazing-feature.
Applying: Add multiply function to amazing-feature.
Applying: Add the divide function to amazing-feature.
➜  git-reflog-git-rebase-example git:(amazing-feature)

This added the other commits from master that this branch didn't have. Following that I did a git log --oneline.

b13c3f1 Add the divide function to amazing-feature.
4fdbc95 Add multiply function to amazing-feature.
085c6a5 Add amazing-feature.
2c0a30c Add the square function to best-feature file.
18244f8 Add the add function to first-feature.
3a01fc1 Add the amazing first-feature.

Oh no, we don't actually want that information from master merged into the amazing-feature branch! We need to figure out a way to undo that rebase. Fortunately we can look up the HEAD reference that we want to go to by using the git reflog command.

b13c3f1 HEAD@{0}: rebase finished: returning to refs/heads/amazing-feature
b13c3f1 HEAD@{1}: rebase: Add the divide function to amazing-feature.
4fdbc95 HEAD@{2}: rebase: Add multiply function to amazing-feature.
085c6a5 HEAD@{3}: rebase: Add amazing-feature.
2c0a30c HEAD@{4}: rebase: checkout master
98008d5 HEAD@{5}: commit: Add the divide function to amazing-feature.
93c18de HEAD@{6}: checkout: moving from master to amazing-feature
2c0a30c HEAD@{7}: commit: Add the square function to best-feature file.
18244f8 HEAD@{8}: checkout: moving from amazing-feature to master
93c18de HEAD@{9}: commit: Add multiply function to amazing-feature.
abdc941 HEAD@{10}: commit: Add amazing-feature.
18244f8 HEAD@{11}: checkout: moving from master to amazing-feature
18244f8 HEAD@{12}: commit: Add the add function to first-feature.
3a01fc1 HEAD@{13}: commit (initial): Add the amazing first-feature.

Looking at the reflog printout, I know that to undo the git rebase that I need to go to the reference HEAD@{5} when I do a git reset, as that reference is the last time the HEAD pointed to the proper place.

➜  git-reflog-git-rebase-example git:(amazing-feature) git reset --hard HEAD@{5}
HEAD is now at 98008d5 Add the divide function to amazing-feature.
➜  git-reflog-git-rebase-example git:(amazing-feature)

One last git log --oneline to make sure that the rebase has been undone.

98008d5 Add the divide function to amazing-feature.
93c18de Add multiply function to amazing-feature.
abdc941 Add amazing-feature.
18244f8 Add the add function to first-feature.
3a01fc1 Add the amazing first-feature.

Phew it has been fixed! Here's what git reflog shows after the git reset command from immediately prior.

98008d5 HEAD@{0}: reset: moving to HEAD@{5}
b13c3f1 HEAD@{1}: rebase finished: returning to refs/heads/amazing-feature
b13c3f1 HEAD@{2}: rebase: Add the divide function to amazing-feature.
4fdbc95 HEAD@{3}: rebase: Add multiply function to amazing-feature.
085c6a5 HEAD@{4}: rebase: Add amazing-feature.
2c0a30c HEAD@{5}: rebase: checkout master
98008d5 HEAD@{6}: commit: Add the divide function to amazing-feature.
93c18de HEAD@{7}: checkout: moving from master to amazing-feature
2c0a30c HEAD@{8}: commit: Add the square function to best-feature file.
18244f8 HEAD@{9}: checkout: moving from amazing-feature to master
93c18de HEAD@{10}: commit: Add multiply function to amazing-feature.
abdc941 HEAD@{11}: commit: Add amazing-feature.
18244f8 HEAD@{12}: checkout: moving from master to amazing-feature
18244f8 HEAD@{13}: commit: Add the add function to first-feature.
3a01fc1 HEAD@{14}: commit (initial): Add the amazing first-feature.

As you can see, the reflog shows the HEAD pointer moves back to the reference that was at HEAD@{5} and is now at HEAD@{6} in the last reflog printout.

Always Push to Your Remote Prior to a git rebase

While I was able to find a solution to the student's problem and we were able to save a half-days worth of work, there is an additional takeaway from this experience. My recommendation is that prior to performing a git rebase always push your work up to a remote if you haven't already. This way even if your git local git history gets messed up, you can always just clone down the remote again.

It really is great to know that you can go back in time and fix those seemingly unfixable mistakes with a few key strokes!

Building Days Since Last

Gunnari Auvinen — Wed, 10 Jun 2026 23:45:10 +0000

I've been watching the NBA Finals with one eye on the series and the other on an idea that's been kicking around in my mind. Somewhere out there a Knicks fan is explaining to a group chat exactly how many days it has been since their last title. What if there were a site that just showed that number for every team across a variety of sports? A giant scoreboard counter for every championship drought, ticking up in real time. That idea turned into Days Since Last, and this post covers the decisions that went into building it.

The best API is no API

My first instinct was probably the same one you have right now, which was to go find a sports API and start comparing free tiers. Then I did the math on what the site actually needs. At the absolute minimum, a drought counter needs exactly one fact per team, the date of their last title-clinching game. That dataset changes once per year per league, and it changes on a night that everyone knows about well in advance.

Given that, there's no API. Instead, each league is a JSON file in the repo, and every date was pulled from box scores. The whole "backend" is a curated dataset, a static site generator, and a GitHub Action. There are no monthly costs and no rate limits, which is perfect for a little side project. When a champion is crowned in any of the leagues, updating the site is a simple one-line JSON edit. I cannot overstate how nice it is to maintain a "live" site that has no moving parts 🚀

Astro, because the counter is the only JavaScript

The site is almost entirely static content with exactly one interactive element, which is the ticking counter. That made the framework decision easy. Astro ships zero JavaScript by default, and the counter is a few KB of vanilla JS that computes the elapsed time from the clinching date on every tick. The number is always correct no matter when the site was last built. It's expected that most people will open these links from group chats on their phones, and that cold mobile load is exactly where shipping a tiny script instead of a framework runtime pays off.

The jumbotron

For the design I wanted an arena scoreboard, not an analytics dashboard. The counters use DSEG, a gorgeous open-source seven-segment font, with a dim ghost layer of 8s behind the digits so it reads like an LED panel with all of the segments faintly visible. Each team's page glows in its real colors. My favorite design problem in the whole project was light mode. A dozen teams have accent colors that simply vanish on a white page, like the Nets' white and the Lakers' gold. Each of those teams carries an alternate accent from its official palette that swaps in with the theme.

What is sports fandom without a little bit or a whole lot of pain and disappointment? With this in mind, I thought that it would be fun to include some tidbits of events that have happened since a team last won a championship. This helps to really drive home how long some teams' droughts are at this point. Fortunately both the Red Sox and Cubs have won championships recently, otherwise the counter might not function properly 😬

Below each team's counter are the facts that I think will make people want to send the link to their friends, families, and coworkers. For example, let's take a look at the Sacramento Kings. The Kings last won a title before the Moon landing, the iPhone, and ChatGPT. Fourteen presidencies have started since then. When they last won, Michael Jordan wouldn't be born for another twelve years. None of that is hardcoded. It all falls out of one date and a small list of reference events.

Share cards with a freshness problem

Every team gets an Open Graph image rendered at build time with Satori in the same jumbotron style, so pasting a link into a chat unfurls into that team's number. Most people who see a shared link never click it, which means the unfurl is the site for them. Baking a day count into pixels also means the image goes stale at midnight. The fix is delightfully dumb. A GitHub Actions cron hits a deploy hook every night and rebuilds the whole site. The counters tick live in the browser, and the images never drift more than a day.

Trust, but verify every single date

The thing that makes or breaks a site like this is whether the numbers are right, and championship history is full of traps. Does Oklahoma City carry Seattle's 1979 title? Officially yes. Do the Vikings count their 1969 NFL Championship? They don't, because the Super Bowl decided that season, which is why Vikings fans are still waiting. Did today's Hornets exist before 2002? Officially yes, since the NBA retconned their history back to 1988 in a deal made in 2014.

I leaned on Claude Code agents for this in two passes. One set of agents built each league's dataset from box scores, and a second set was told to assume the first set made mistakes and to go find them. Across 193 teams and eight leagues, the adversarial pass found exactly one factual error. In the MLS, FC Dallas had been credited with a Supporters' Shield that D.C. United actually won. One error, in a footnote, across every clinching date in American sports history. I'll take it!

One JSON file per league

The site launched as an NBA-only board, but the architecture never assumed that. Leagues load from a glob over the data directory, so adding the NFL meant adding a file. The nav link, the league board, the team pages, and the share cards all appear on the next build. There are eight leagues on the board now, from the NFL down to the brand-new PWHL, whose Montréal Victoire lifted the Walter Cup just three weeks ago. The all-sports view surfaces the heavyweight, the Arizona Cardinals, whose last championship came in 1947. That counter has five digits 😬

As I write this, the Knicks and the Spurs are playing in the Finals, and the Hurricanes and the Golden Knights are tied in the Stanley Cup Final. Two of the longest waits on the site might reset to zero within the week. That's the thing I love most about this project. It's a static site with a built-in season finale.

Check it out at dayssincelast.app, and the code is on GitHub. If your team's counter hurts to look at, I'm sorry. The clock doesn't lie 😅

What is Semantic Versioning?

Gunnari Auvinen — Mon, 08 Jun 2026 12:43:00 +0000

Versioning and Software Development

As you've probably seen while writing your own software, your code can change a little bit from version to version, or it can change quite a bit, or it can be completely overhauled. As you write code and go from version to version, are you using a versioning system to keep track of the types of changes from build to build? If so are you following a defined system? To my understanding there is currently no universally adopted specification for software versioning, but one specification that many people use is called Semantic Versioning specification or SemVer.

What Is Semantic Versioning?

Alright now that you know about the SemVer specification, what exactly is it and how is it defined? SemVer uses the following three categories: major, minor, and patch. These map to the x.y.z numbering system, eg 1.2.3 would be major version 1, minor version 2, and patch version 3.

Ok... what exactly do major, minor, and patch mean with respect to software versions? The following information has been taken directly from the SemVer website:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

There are a couple of main takeaways from this information. The first being that you should always review what changed in a piece of software when they update the major version number. Specifically due to the fact that certain aspects of the API may or may not have changed. The documentation should be examined to ensure that either the changes allow continued functionality of your own project or that your project will need to be refactored due to the changes. On the other hand upgrading a dependency when the minor or patch version is updated, is less concerning, as all of these changes are expected to backwards compatible. Armed with this information you now know when it is possible to upgrade a dependency without fear of likely breaking anything and when you will need to review the new software to see if you will need to change any of your own code.

Why Is This Important?

Well all of that is great information, but why should you care? As you develop software you want to avoid something coined "dependency hell". Specifically you don't want to be put into a position where changes in your dependencies will break your entire system or leave it in a state where you cannot easily make changes. The Semantic Versioning specification assists you in avoiding that unenviable position. This is made possible by the ability to determine whether or not when a dependency is updated whether or not it is backwards compatible. If the update is either minor or a patch in nature, you will be confident in updating that dependency, as by the SemVer definitions the public API of that dependency will still function the same as it was previously defined. While on the other hand if changes in a dependency result in incompatibility you can require that your software uses a specific version of the software, such that you ensure continued functionality.

When you work on your next project work on implementing the SemVer specification as your versioning system. There's additional thoughts and points behind SemVer on the specifications website. This will make all of our lives as developers that much easier and fruitful!

What Do the ~, ^, and * Mean in package.json?

Gunnari Auvinen — Sun, 07 Jun 2026 15:04:00 +0000

~, ^, and * in package.json... wat?

The first time you open up a package.json file you're greeted by a lot of information about that project. That one file can include a lot of information about the project: the author's name and email, the project title, where the project is hosted, where to submit bugs, startup scripts, and more. The parts that I'm going to discuss in this post are found within the dependencies and devDependencies sections.

Frequently you will see module version numbers prefixed with a ~ or ^ and sometimes you'll even see just a *. What exactly do these characters correlate with respect to version numbers? When you run npm install, the ~, ^, and * tell npm what versions of the dependencies to install for the project. So how do those characters relate to version numbers at all?

The numbers listed there certainly make sense, but what do the other characters mean? After all you know what version of software you wanted when you required the module, why would you want or need anything else? Well these characters help provide flexibility on what versions of dependencies are installed when the npm install command is run. Let's take a look at what each one does and why that functionality is useful.

Semantic Versioning Breakout

Real quick before we dive into the what the characters do, let me first give a brief overview of the software versioning system that npm modules use. They follow the Semantic Versioning, or SemVer, specification. These map to a x.y.z numbering system, eg 1.2.3 would be major version 1, minor version 2, and patch version 3.

What exactly do major, minor, and patch mean with respect to software versions? The following information has been taken directly from the SemVer website:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

For an expanded look at semantic versioning, I wrote a previous post about the subject that can be found here. Alright let's jump back into the the examination of the ~, ^, and * characters!

~, ^, and *? Oh I see what they do now...

Let's start by looking at the ~. The ~ character fixes both the major and minor version numbers, while matching any patch number. e.g. if the version dependency was defined as ~2.3.1, npm would match all versions greater than or equal to 2.3.1 and less than 2.4.0 for that dependency.

Next up is the ^, which locks down the major version number, but leaves the minor and patch versions to be more flexible. When installing a dependency that is listed with the version of ^2.2.3, npm will match any version that is greater than or equal to 2.2.3 and also less than 3.0.0.

Finally there is the *, which while available, isn't used as often. The primary reason for its less frequent use is the fact that it acts as a stand in for either the major, minor, or patch number and catches any version number for the place that it represents. For example a dependency with a version of * would equate to any version that was greater than or equal to 0.0.0, while 1.* would allow versions greater than or equal to 1.0.0 and less than 2.0.0.

Importance of Dependency Versions

Gaining a greater understanding how the versioning system works in the package.json file will hopefully help you to avoid dependency hell down the line. Take a little bit of time now to familiarize yourself with the system that the package.json file uses, so you can avoid headaches later. Also take some time to review the SemVer specification, so you can properly version your own software in the future!