## 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!

npm and Semantic Versioning

## 2023 Goal Reflection

Let's start by reflecting on the goals that I set out to accomplish with this blog both in content and general site functionality. If you're curious, [here's](https://aaronbos.dev/posts/2022-year-in-review) my review/preview post from last year. In that post, I noted a couple of goals related to blogging.

- **Achieved**: Post twice a month (24 times throughout the year)
- **Achieved**: Incorporate book reviews into posts

Both of these goals felt natural to work towards and I think overall they helped me maintain traction and find a balance between purely technological content and more general posts. While two posts a month was reasonable, I'll be touching on what I'm planning on for cadence in 2024 👀.

The next set of goals that I set was based on this site's functionality. I set a goal to be completed throughout each quarter of the year.

- Framework upgrades | Q1 | [PR](https://github.com/aaronmbos/personal-site/pull/24)
- Migrate posts from markdown files to database | Q2 | PR's [1](https://github.com/aaronmbos/personal-site/pull/28), [2](https://github.com/aaronmbos/personal-site/pull/29), [3](https://github.com/aaronmbos/personal-site/pull/33)
- Improve search experience | Q3 | [PR](https://github.com/aaronmbos/personal-site/pull/47)
- Add pagination to posts page | Q4 | [PR](https://github.com/aaronmbos/personal-site/pull/51)

You may be wondering why I feel the need to create a plan for making improvements to the site itself. The main reason for this is so that I can avoid the trap of tinkering with the site instead of writing posts and creating content. As a developer, I enjoy writing code and making improvements, but free time is finite and I need to stay focused on the goal of writing blog posts.

Overall I feel good about the content I published last year. There was a mix of technical and non-technical content, which was good for me to practice different styles of writing. I'd like to continue this going forward, but maybe lean back into the technical end of the spectrum more frequently.

## Looking Ahead to 2024

For the past three years (woah I can't believe I've been writing posts for this long already 😲) I've stuck with a cadence of two or three posts per month. Two has always felt right, but there have still been times when I've felt a little rushed to complete more in-depth posts in time. I feel best about posts that have true substance to them and require a bit of digging to complete. For this reason, I'm going to create two goals that I hope will strike a balance between in-depth posts and continuing to share my learnings frequently.

- Post **one post per month** throughout the year
- Create a new section of the site for **book notes**

My goal with writing one post per month will be to set aside around a continuous week to prepare for and write a post in hopes of being able to focus on a single concept at some depth. The reason I'd like to add a new section for book notes specifically is so that I have a place to share notes on books that I'm reading, but is separate from general posts. Book notes will be much rougher and most likely un-edited whereas posts should be more structured and cohesive. 

### Site Roadmap

Here are my site roadmap improvements planned for the upcoming year, broken out by quarter. As a reminder, these are posted and kept up to date in the GitHub repo [here](https://github.com/aaronmbos/personal-site#feature-roadmap).

- **Q1**: Dependency upgrades, code cleanup, rework, and refactoring
- **Q2**: Create the new "book note" section
- **Q3**: Automatically generate OG images for posts
- **Q4**: Content management features (ie markdown editing shortcuts)

That's a wrap for my look back and look ahead for the blog in 2023-24. I can honestly say that I'm as optimistic as ever that 2024 will be a great year for me and I wish you all the same! Let's get out there and crush it!


This time of year (holidays and New Year's) means something different for everyone, but for me, they are always a time to reflect on what has been and look ahead at what could be. As I've done in previous years I'm going to review the previous year in terms of this blog and my career as well as look ahead to the next year in the context of what to expect. Let's dive in!

Reviewing 2023 and Previewing 2024

## History

HTTP Live Streaming or HLS as I'll refer to it for the rest of this post was first released by Apple in 2009. In its simplest form, it can be described as an HTTP-based adaptive bitrate (ABR) streaming protocol that relies on text-based playlist files referencing the actual media content. Adaptive bitrate streaming refers to a video playback experience that "adapts" to the user's network and environment constraints to provide the best possible viewing experience. Since HLS is both HTTP and text-based, simple web servers and CDNs can be leveraged heavily to distribute content.

The HLS specification is defined in IETF RFC 8216, which can be found [here](https://datatracker.ietf.org/doc/html/rfc8216). The most up-to-date draft specification was published in November 2023 and can be found [here](https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis).

## HLS Components

### Capture device

This is the first step of the pipeline that involves capturing audio and visual data. If the content has already been recorded, this step may involve simply using existing media files.

### Server

The server is the next step in the pipeline which involves encoding the content from the previous step and segmenting it into short files. Common codecs for video are HEVC or AVC and AC-3 or AAC for audio. The output from this step is formatted as fragmented mp4 or MPEG-2 transport streams.

### Distribution

Once the media has been encoded and formatted for delivery the distribution step of the pipeline comes into play. The distributor may be a web server, caching system (like a CDN), or a combination of the two. Since HLS is built on a text-based HTTP protocol there’s typically little setup required for this component.

### Client
The client software is the last step of the pipeline and is responsible for requesting the media, downloading the response, and displaying it to the user. This step is slightly simplified here as there will most likely be some form of decoding required to play the media back.

**Note:** The key to this architecture is that the server encodes multiple renditions of the same video that can be played back effectively at varying bandwidths. For example, the server may generate a 720p and 1080p rendition of the same video so that the client can dynamically use the rendition that best fits their environmental constraints. The files encoded by the server are short enough that the client doesn't have to spend long amounts of time downloading and decoding the content.

## HLS Playlist Format

As I mentioned previously, HLS is a text-based protocol and more specifically the text that is transferred from server to client is in the form of "playlists". A playlist is a simple text file with a file suffix of `.m3u8` (ie "playlist.m3u8"). The playlist contains references to the media files for playback. The media file references may be in the form of absolute or relative (to the location of the playlist) paths.

As with any file format playlist files need to follow a standardized structure. An HLS playlist is nothing more than a text file containing a set of standardized tags that each provide information about the playlist or the media files contained in the playlist. Tags are prefixed with a `#` and media file references are not. Many possible tags can be used in playlists, but here are a few to just get a general understanding. 

- **EXTM3U:** Indicates that the playlist is an extended M3U file. This type of file is distinguished from a basic `M3U` file by changing the tag on the first line to `EXTM3U`. All HLS playlists must start with this tag.
- **EXT-X-VERSION:** Indicates the compatibility version of the playlist file. The playlist media and its server must comply with all provisions of the most recent version of the IETF Internet Draft of the HLS specification that defines that protocol version.
- **EXTINF:** A record marker that describes the media file identified by the URL that follows it. Each media file URL must be preceded by an `EXTINF` tag. This tag contains a duration attribute that’s an integer or floating-point number in decimal positional notation that specifies the duration of the media segment in seconds. This value must be less than or equal to the target duration.
- For a full list check out the [RFC](https://datatracker.ietf.org/doc/html/rfc8216). 

There are two main types of playlists used in HLS.

- Variant: A playlist file that references actual media files
- Multivariant: A playlist that references other playlists (typically the same content in a different rendition).

A layer below variant and multivariant playlists are VOD and Event playlist types, which are defined in the EXT-X-PLAYLIST-TYPE tag. VOD playlists typically contain pre-recorded content while Event playlists can refer to a live recording. The playlist type defined will change the way that servers can modify the playlist. For example, Event playlists can be appended to while VOD playlists are expected to be static.

### Example Playlists

Below are a couple of example playlists, which show how the tags and media file references are formatted.

#### Variant Playlist
```
#EXTM3U
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-TARGETDURATION:10
#EXT-X-VERSION:4
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
fileSequenceA.ts
#EXTINF:10.0,
fileSequenceB.ts
#EXTINF:10.0,
fileSequenceC.ts
#EXTINF:9.0,
fileSequenceD.ts
#EXT-X-ENDLIST
```
    
#### Multivariant Playlist
```
#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=150000,RESOLUTION=416x234,CODECS="avc1.42e00a,mp4a.40.2"
http://example.com/low/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=240000,RESOLUTION=416x234,CODECS="avc1.42e00a,mp4a.40.2"
http://example.com/lo_mid/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=440000,RESOLUTION=416x234,CODECS="avc1.42e00a,mp4a.40.2"
http://example.com/hi_mid/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=640000,RESOLUTION=640x360,CODECS="avc1.42e00a,mp4a.40.2"
http://example.com/high/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=64000,CODECS="mp4a.40.5"
http://example.com/audio/index.m3u8
```

HTTP Live Streaming is a relatively simple protocol that is used behind the scenes to power some of the most popular streaming experiences that we all use. Next time you watch a video maybe check out the network tab to see if you see any of these protocols in action!

Video has become an integral part of our digital lives. We rely on video streaming services like YouTube, Netflix, and Hulu to consume all kinds of content from sports to Movies and TV. If you've ever wondered what kind of technology might be powering these streaming services, you've landed in the right place. In this post, I'm going to share some info about HTTP Live Streaming and how it is used to provide smooth video playback experiences.

Hey! 👋

My name is Aaron Bos and this is my blog.

Recent Posts