As a software engineer, my day-to-day responsibilities may vary quite a bit depending on several factors like time of the year, team structure, current role, etc. These responsibilities include writing code, reviewing PRs, mentoring others, attending meetings, code spelunking to answer questions from stakeholders, and many more. With all of these varying responsibilities, it can be easy to ask yourself "What did I even do today?" when the time comes to close the laptop for the night. This feeling has become more common as I've grown in experience and tenure throughout my career.

I've recently been reading "[The Software Engineering Guidebook](https://www.engguidebook.com/)" by [Gergely Orosz](https://www.linkedin.com/in/gergelyorosz/) who also publishes the popular Pragmatic Engineer [newsletter](https://newsletter.pragmaticengineer.com/). If this topic interests you, I'd highly recommend checking out the book and newsletter because Gergely shares a lot of great content that can benefit engineers at various points in their careers. 

In the book, Gergely discusses how keeping a work log can benefit software engineers, so I figured I'd try it out. As you can venture to guess from the title of this post, it has been beneficial for me so far. To avoid stealing Gergely's thunder I'll share what has worked for me and what I expect to get out of continuing to keep a daily work log going forward.

## Keep it simple

When trying to build a new habit, I've often found the biggest barrier to entry to be trying **too much too soon**. For this reason, I wanted to keep my work log as simple as possible. I started by using Apple's Notes app because I already used it for other work-related notes and didn't want to worry about adopting a new tool. 

From there I created a weekly template to use for each week. I keep all of my work notes in the same document and the template is at the top so I can copy and paste to get started at the beginning of each week. This is what my template looks like.

```
2024-MM-DD - 2024-MM-DD

Fri
Thurs
Wed
Tues
Mon
```

From there I fill in content each day throughout the week. This has worked well for me so far, but there's a good chance I adjust it going forward to continue to meet my needs. If you're also starting from scratch, I'd recommend **choosing a tool and process requiring the least friction to get started**.

## Be consistent

Once the tool and format were decided for my work log, the only thing left for me to do was to make sure I filled it out each day. Initially, it was a bit of a challenge, but after the first couple of weeks, it became part of my normal routine. For me, the routine is to log relevant work throughout the day when possible and also to review the log to fill in any missing details at the end of the day.

I've found that no day is the same in terms of how often I add details to my work log, but **being consistent about reviewing it at the end of the day is key** for me. Doing this provides an opportunity to update existing or add new details before logging off. This routine also gives me a sense of accomplishment at the end of the day because I can look back and see everything I did. There are some days when I'm reviewing the log with frustration because I didn't feel I accomplished much that day. After reviewing the log I often realized that I did accomplish a lot, it just didn't feel like it because I was context-shifting often or spread a little thin for the day.

In terms of the detail that I add to each of my logs. I try to **keep them simple and to the point**. My work logs are similar to what you'd see in bullet points in a presentation. The goal isn't for me to be able to look back and have a detailed log for each minute of the day, but for me to see the highlights and progress that I made on different responsibilities and tasks.

## Looking ahead

I've been consistent with my work log habit for several weeks now and I'm excited to carry the habit forward. I hope it continues to provide me with positive vibes and motivation at the end of the day. In Gergely's book he also mentions using the work log as a way to make work software engineers do that may not be visible to others visible. For example, I may be able to reference my work log in conversations with my manager to help them understand the progress and effort that I've put into work that may have not been initially obvious. I have not put this into practice, but I have a feeling it could definitely come in handy in the future. Overall maintaining a daily work log has been a positive experience for me and I'd definitely encourage others to give it a try!

Life as a software engineer can sometimes feel hectic, so it's important to have processes that keep us grounded and focused on the things that matter. Recently I've adopted a habit of keeping a work log to do just that. My goal for this post is to share the benefits I've noticed since keeping a daily work log and what I hope to gain from the habit in the long term.

Staying Productive with a Work Log

## Seeking with FFmpeg

The functionality for "trimming" or "cutting" video is included in a command flag `-ss` and it's referred to as "seeking". The seek option is a time duration value that tells FFmpeg where to seek directly in the input or output.

Here is an example of a command using the `-ss` option where FFmpeg will seek five seconds at the beginning of the input video before decoding it for the output. The output from this command will be missing the first five seconds of the original input.

```shell
ffmpeg -ss 5 -i input.mp4 out.mp4
```

It's important to note that the placement of `-ss` in the command will play a role in how FFmpeg seeks the video as well as how fast the command runs. When specified before the input file(s) or `-i` flag, FFmpeg will seek directly to the specified duration on the input before decoding.

The other alternative is to include the `-ss` flag after the input file(s), which results in FFmpeg decoding and discarding each frame of the video until it reaches the seek time duration. 

```shell
ffmpeg -i input.mp4 -ss 5 out.mp4
```

This can be useful or required if filters need to be applied to generate the desired output, but it's key to know this can be much slower than seeking the input file. For that reason, I'd default to seeking the command input unless seeking the output is required.

## Time Duration Syntax

When it comes to values that we can use for the `-ss` flag, FFmpeg expects a "time duration" value. Time duration values can come in two forms and both forms can specify negative values.

1. `[-][HH:]MM:SS[.m...]`
2. `[-]S+[.m...][s|ms|us]`

In the first syntax `HH:` represents the number of hours and is optional. `MM` and `SS` are required representing minutes and seconds respectively. Finally, `.m` represents an optional decimal value for seconds. Our previous command using this syntax would look like the command below.

```shell
ffmpeg -ss 00:05 -i input.mp4 out.mp4
```

We used the second syntax listed in our previous examples, but I do think it's worth noting that seconds are assumed unless specified with one of the valid suffixes.

- `s` seconds
- `ms` milliseconds
- `us` microseconds

All of the commands below are equivalent in the amount of video to seek in comparison to previous commands.


```shell
ffmpeg -ss 5000ms -i input.mp4 out.mp4
ffmpeg -ss 5000000us -i input.mp4 out.mp4
ffmpeg -ss 5s -i input.mp4 out.mp4
```

So far the commands we've listed will seek or trim video starting at the beginning of an input file. Next, we'll look at the command flags we can use to also trim video from the end of a file.

## Cutting Parts of Video

There may be situations when you want to remove video from the end of a file and to do that we'll want to look at the `-t` and `-to` command flags. While these two flags serve similar purposes, they are mutually exclusive and can't be used together in the same command. If both are included, `-t` will take priority. So what do these flags do exactly?

Both `-t` and `-to` accept time duration values, but how FFmpeg uses the time durations is the key differentiator between the two flags.

- `-t` expects its value to be a **duration** of the input or output
- `-to` expects its value to be a **position** in the input or output

Similarly to `-ss` these commands can be used to operate on the input or output (before or after the `-i input.file`). When `-t` and `-to` are used in a command without `-ss` their behavior is pretty straightforward. For example, this command will result in the output containing the first eight seconds of video.

```shell
ffmpeg -t 8 -i input.mp4 out.mp4
```

Things get a little more interesting when `-t` and `-to` are used in conjunction with the `-ss` flag. Using them together allows us to cut parts in the middle of an input file, but it's important to keep in mind **where** in the command we place certain flags. For example, if `-ss` is specified before the input then we need to place `-t` or `-to` in the right place, before or after the input, to achieve the desired results. Let's go through the following scenario.

- Original video is ten seconds
- Desired output is five seconds
  - Trim two seconds from the beginning
  - Trim three seconds from the end

```shell
********** # Original
  *****   # Trimmed
```

We could structure this command several ways varying the positions of the `-ss`, `-t`, and `-to` flags while achieving the same end result.

```shell
ffmpeg -ss 2 -i input.mp4 -t 5 out.mp4
ffmpeg -ss 2 -i input.mp4 -to 5 out.mp4
ffmpeg -ss 2 -t 5 -i input.mp4 out.mp4
ffmpeg -ss 2 -to 7 -i input.mp4 out.mp4
ffmpeg -i input.mp4 -ss 2 -t 5 out.mp4
ffmpeg -i input.mp4 -ss 2 -to 7 out.mp4
```

All of these commands are similar and result in the same output, but the ordering of the command flags is important. You'll notice that when `-ss` is specified before the input and `-t` or `-to` are specified on the output the value provided is the same. This is because the duration and position are applied to the input that has already been adjusted by seeking to the specified time duration. When both flags are applied to the same side of the command i.e. both on input or output, then the `-to` position is relative to the original input duration.

I think this post goes to show that while trimming video may be simple on the surface, can find ways to be complicated even for the simplest of problems. There are a lot of other considerations to take into account when trimming video like codec copying and timestamps. I hope this is a good introduction to the problem space and provides a solid platform for you to learn more!



If you're a developer and work with video, there's a chance that you may need to trim or cut parts of the video for your users. In this post, I'll be going through the commands needed to do this in FFmpeg along with some details to consider when trimming video. Let's dive in!

Trimming Video with FFmpeg

## Simple Find and Replace

If you've landed on this post looking for a quick solution, I won't make you scroll. Below is a command that you can use in Neovim (and Vim) to find a string "Waldo" and replace all occurrences with another string "Wizard Whitebeard".

> Where is Waldo? Have you seen Waldo?  
There you are Waldo.


```shell
:%s/Waldo/Wizard Whitebeard/g
```

I'll go into more detail on the command structure and flags below, but `:%s` invokes the substitution command. `Waldo` is the string that we are looking for and `Wizard Whitebeard` is the string to replace occurrences of `Waldo` with. 

The `/g` is required to replace instances of the string on the same line. Without `/g` the `Waldo` in "Have you seen Waldo?" would not be replaced because it is the second occurrence of the string on that line.

If you're interested in learning a little bit more about the `:substitution` command, grab a coffee and read on.

## Command Breakdown

As I mentioned, the feature of Neovim (and Vim) that we are concerned with here is **substitution**. Substitution refers to the ability to perform string replacements on a whole range of lines.

The command to invoke substitution is `:substitution` or `:s` as we saw in the previous example. Those with a keen memory may be wondering why we used `:%s` in the previous command. The reason for the `%` range prefix is used to indicate that the command should be applied to **all lines** instead of just the current line. This means that we can also use the `%` with `:substitution` as well. So `:%substitution` is the same as `:%s` and for the remainder of this post I'll use `:%s` to save some keystrokes 😎.

Now that we know what command we're concerned with we can focus on the actual syntactical structure. Generally the substitution command is constructed as follows.

```
:[range]s/<string-to-find>/<string-to-replace>/[flags]
```

If we were to compare this structure to our previous example then we can make the following mappings.

- range: `%`
- string-to-find: `Waldo`
- string-to-replace: `Wizard Whitebeard`
- flags: `g`

While the percent sign may be the most commonly used range for substitution, there are many other things that we can do with this range beyond considering all lines for the command. Ranges are quite robust, but beyond the scope of this particular post. If you are interested in learning more, head over to the docs [here](https://neovim.io/doc/user/usr_10.html#10.3).

The one feature of ranges that I'd like to call out is to be able to grab the range for the current selection in Visual mode. This feature is great for substituting text just inside of a selection rather than all of the lines or a hard-coded range.

To do this, simply enter Visual mode (press `v` while in Normal mode) and select the text you'd like to consider for substitution. Once you've selected the text, press `:` which should then display this in the command area.


```
:'<,'>
```

From there we can add our substitution command, which will just be applied to the text that we have selected from Visual mode.

```
:'<,'>s/Waldo/Wizard Whitebeard/g
```

I'm sure there are plenty of other patterns to apply with ranges and selections, so if you've got one reach out and let me know!

### Flags

The substitution command doesn't come with too many flags and we've already seen the global or `g` flag in our previous example. The other two flags that we have available are as follows.

- print or `p`: which results in the command printing out the last line it changes
- confirm or `c`: which prompts the user for each substitution before applying the change

When using the confirmation flag, you'll have a few options to choose from.

1. Make the change by pressing `y`.
2. Skip changing this occurrence by pressing `n`.
3. Make the change and all subsequent changes without further confirmation by pressing `a`.
4. Quit without making more changes by pressing `q`.
5. Make the current change, then quit by pressing `l`.

Let's a take look at our previous command, but include the confirmation flag.

```shell
:%s/Waldo/Wizard Whitebeard/gc
```

With each occurrence of the string we are presented with this prompt, allowing a decision to be made before the change takes place.

```
replace with Wizard Whitebeard (y/n/a/q/l/^E/^Y)?
```

This post only cracks the surface of what can be done with substitutions. If you're curious about learning more, I'd recommend checking out applying search patterns within the text to find or replace using the substitute command. As with most things in Vim, foundational knowledge can be composed and applied to perform powerful operations.


While Neovim may not be my daily editor, I still prefer it to modify files quickly. Often I find myself in Neovim when I need to make small changes to JSON or YAML files. A common action that I perform is a simple "find and replace" which is supported by most editors. As with most things, the method to do this in Vim is powerful, but not necessarily straightforward unless you know the right commands and flags. In this post, I'll go into some detail about substituting characters in Vim and Neovim.

Find and Replace in Neovim

I've navigated quite a bit of change over the last year and I think with that came a change in perspective. I'll be the first to admit that it can be easy to get "shiny object syndrome" and lose focus now and then. Recently for me, this has been thinking about ways to monetize or profit from my blog. Whether that be trying out automated ads with Google Adsense (terrible idea), tailoring content to potentially get sponsored posts in the future or other profit-focused ideas. While these ideas may sound intriguing, they don't necessarily align with the reasons why I started blogging in the first place.

The month of February was the first month in three years that I didn't share a single blog post. I have a couple drafted, but I lacked the motivation to finish them. As I was reflecting on why this might be, it occurred to me that I've gotten away from the entire reason I wanted to do this blog in the first place and that is to share what I'm learning about. 

If you've come to expect regular posts from me, I apologize for missing a post in February. I'm hoping to have a few posts out this month to get back into my groove. I've been learning quite a bit recently about Swift and iOS development which I think could be an interesting topic to discuss. I'm also hoping to dive a bit deeper into AI coding tools as well as some new features in C#. If you've made it this far thanks, and keep learning!

In the rush of everyday life, it's easy to lose sight of your "North Star". For me and this blog, my North Star is learning. If I'm not learning, then chances are I'm not feeling energized. It's time to get back to what I have enjoyed so much with this blog over the last three years. Sharing what I'm learning through interesting and valuable blog posts.

A Reminder of Why I Started This Blog

## Semantic Versioning Intro

Before getting too deep into npm package specifics, it's worth taking a look at semantic versioning in general. If you're not familiar with semantic versioning (sometimes referred to as "semver"), it is a simple set of rules and requirements that dictate how version numbers are assigned and incremented. 

Typically you'll see semantically versioned packages formatted as `X.Y.Z` or `Major.Minor.Patch` where each period-separated part of the version is a positive integer without leading zeroes. For example, the first production release of any package should be `1.0.0`. 

Occasionally you may see slight variations of this standard. For example, packages are versioned with a major version of zero like `0.2.1`. This indicates that a package is in initial development and that the entire API is subject to change. Another common variation of the standard is to append a modifier like `alpha`, `beta`, or build numbers to the end of a version. Both of these variations are compliant with the official semver standard.

For package creators, semantic versioning is most important when making changes to an existing package. The developer needs to decide what kind of version bump the change requires. Below is a list of scenarios to take into consideration when deciding how to change a package version.

- Bump patch version: Bug fixes not affecting the API
- Bump minor version: Backward compatible API additions/changes 
- Bump major version: Backward incompatible API changes

While the standard is relatively straightforward, I think going too deep into the specifics is out of scope for what I'm looking to cover in this post. If you're interested in learning more head over to the [semver spec](https://semver.org/) to get a more in-depth understanding of everything it entails.

## `package.json` Specifics

All packages that are published to the npm repository are required to contain a package.json file. The package.json file serves the following purposes.

- Lists the packages your project depends on
- Specifies versions of a package that your project can use using semantic versioning rules
- Makes your build reproducible, and therefore easier to share with other developers

There are many fields that *can* be included in the package.json file, but for this post, we are mostly concerned with the `"dependencies"` and `"devDependencies"` fields. The difference between the two is that `devDependencies` are packages that are only needed for local development or testing. Whereas the packages listed in the `dependencies` section are expected to be needed in production. To install a dev dependency the `--save-dev` flag should be used when running `npm install` for the package.

```
npm install <package_name> --save-dev
```

Both the `dependencies` and `devDependencies` sections include package names along with semantic version numbers. If you've seen package.json files before you may have noticed that the exact package version isn't always used when referencing packages. Within the semver spec we can specify package ranges for which the "best" package meeting the range's criteria will be selected for use.

```
{
  "dependencies": {
    "foo": "1.0.0 - 2.9999.9999",
    "bar": ">=1.0.2 <2.1.2",
    "baz": ">1.0.2 <=2.3.4"
}
```

## Getting into `node-semver`

Now I'll be going through the different options that we have available when specifying package versions in the package.json file. Again these rules are compliant with the semver spec, which is managed in the node-semver [package](https://github.com/npm/node-semver) globally installed with npm.

- `1.2.3` Specify the exact version of a package. If that package doesn't exist, an error will be thrown.
- `>1.2.3`, `>=1.2.3`, `<1.2.3`, `<=1.2.3` The comparison operators work exactly how you'd expect them to. The resolved package will be the next available version compared using the provided operator. The comparisons can also be combined to specify explicit ranges like `>=1.2.3 <=3.2.1`.
- `~1.2.3` The tilde range resolves a package that is "approximately equivalent to" the specified version. This range behaves slightly differently depending on whether or not a Minor or Patch version is included in the requested version. For example, `~1.2.3` will allow patch-level changes greater than `1.2.3`, but less than `1.3.0` whereas `~1` will allow minor or patch version upgrades up until `2.0.0`.
- `^1.2.3` Carat ranges allow patch and minor updates for versions 1.0.0 and above, patch updates for versions 0.X >=0.1.0, and no updates for versions 0.0.X. The updates allowed are based on the left-most zero in the specified version.
- `1.2.x` Allows for patch upgrades only
- `*` or `""` will match any version 😱
- `1.2.3-3.2.1` is the same as `>=1.2.3 <=3.2.1`
- `1.2.3-3.2.1 || 4.0.0-5.0.0` will pass as long as either of the ranges are met
- HTTP, Git URLs, and local paths can also be referenced, but are less commonly used.

For a more hands-on look at semver resolution specifics, check out the [semantic versioning calculator](https://semver.npmjs.com/) which provides a UI to play around with dependency versions and ranges. This is a quick intro into what can be a fairly complicated space. I hope it provides a foundation to learn more if you need to do so!

If you've been a developer for any amount of time you've undoubtedly reached for external dependencies to solve specific problems. Whether the problem is as small as padding the left side of a string or as large as a component library, external packages are inevitable. In this post, I'll be going into the nuances of how npm leverages semantic versioning and some information that will be useful as npm package consumers. Let's dive in!

Hey! 👋

My name is Aaron Bos and this is my blog.

Recent Posts