
Since becoming a software engineer I've enjoyed optimizing different aspects of my development environment. I think the reason why I enjoy it is that each person has their preferences (or lack thereof), which allows for a bit of creativity in areas that can be typically mundane. In my opinion, one of the most used, yet often overlooked, aspects of a development environment is the font used in editors and terminals. I've tried several different fonts over the years but always found myself liking bits and pieces of individual fonts. That's why I decided to create [Monocode](https://github.com/aaronmbos/monocode).

![Monocode specimen](https://res.cloudinary.com/aaron-bos/image/upload/v1684413540/monocode-specimen_xicez5.png)

## How I created Monocode

I want to start by saying that I didn't create Monocode from scratch. That would be a bit out of my wheelhouse and probably a lot more work than I would've liked. Instead, I created a heavily customized version of a font called [Iosevka](https://typeof.net/Iosevka/). Iosevka is an open-source font that is designed with flexibility in mind. By default, it is narrower than most fonts but can be easily customized to normal width. The [maintainer](https://github.com/be5invis) has created an amazing [site](https://typeof.net/Iosevka/customizer) that allows you to customize specific characters of the font based on a set of predefined alternative glyphs.

The customization relies on a TOML configuration file containing the build plans for customization and a build script written in Node.js. Creating a custom version of the font can be done in a few simple steps that are all well documented on [GitHub](https://github.com/be5invis/Iosevka/blob/main/doc/custom-build.md#configuring-custom-build).

1. Clone the Iosevka repository
1. Modify the TOML configuration file with character customizations
1. Install the build dependencies
1. Run the build script

I've spent the last ten months adjusting characters and font metrics to fit my style. At this point, the font has been pretty stable, which is why I feel that this is the right time to share it on this blog. At the time of writing the latest release of Monocode is version 4.0.3, which is based on Iosevka version 22.1.2.

## Features of Monocode

When it comes to fonts that are used in programming environments, there are a few characteristics that are common among them.

1. Fixed width or monospaced
1. Distinct characters
1. Readable in smaller sizes

Since Monocode is based on a well-established font like Iosevka, it already has all of these characteristics. However, I've made a few adjustments to the font that I think makes it unique.

1. Larger x-height: I prefer a slightly larger x-height resulting in taller lowercase characters. I think this helps the readability of smaller sizes. Another example of a font that utilizes a larger x-height is JetBrains Mono.
1. Distinct characters: Certain character combinations can be easily confused like capital "O" and zero, capital "I" and lowercase "l", capital "B" and 8, etc. I've made adjustments to these characters to ensure they are easily distinguishable.
1. Italics: While the regular style is used most commonly in programming environments, I find it useful to set certain text to italic. For example, I use italics for code comments to differentiate them from the code itself. With Monocode in particular, I've made the italic style a bit more curly than just a slanted version of the regular style. Letters like "a", "i", "l", and "f" have slightly different variations for the italic style, which makes the font a bit more unique.

One font feature that many developers look for is ligatures. While Iosevka does support ligatures, I've decided to disable them in Monocode. I've found that ligatures can be distracting and I prefer to have the characters separated. However, if you do like ligatures, you can easily enable them in the customization configuration file.

## Updating and releasing Monocode

One of the aspects of Monocode that I'm most proud of is the build and release pipeline. At the time of writing, I've set up a few GitHub actions that automate the process of building new versions and creating releases. The effort that I've put into this automation allows me to easily update the font and test variations without needing to worry about all of the work that goes into manually building the font locally and creating new releases manually.

When it comes to automation, there is currently an action that runs every day to get the latest version of Iosevka. In the Monocode repo, I keep track of the Iosevka version that Monocode is using and compare it to the latest version when the action runs. If the latest version of Iosevka is different from the version that Monocode is using, the action will create a new branch and create a pull request with the updated version. This allows me to easily review the changes and merge them into the main branch. Once the changes are merged, another action will run to build the font and create a new release. The new Monocode version will be based on the new version of Iosevka. So for example, if Iosevka is updated from version 22.1.2 to 22.1.3, Monocode will be updated from version 4.0.3 to 4.0.4.

There are also a handful of images on the GitHub repo README demonstrating the font and some of its features. I've created an action that will automatically generate these images using a command line tool called ImageMagick. This allows the images to be quickly updated when the font changes.

Putting so much thought and effort into a font for programming isn't for everyone or most people for that matter. It is a quirky interest of mine that I enjoy and I hope that others will find it useful as well. If you're interested in trying out Monocode, you can download it from the releases pages on GitHub [here](https://github.com/aaronmbos/monocode/releases).


Over the past ten months I've been working on a custom font for me to use in programming environments. The font is called Monocode and in this post I'm going to talk about how I created it, why I created it, and what makes it unique. Let's dive in!

Monocode: A font for code


Since becoming a software engineer I've enjoyed the feeling of putting my headphones on, turning on some music, and getting into a flow state. In doing so I've listened to several different genres of music ranging from classical to electronic to lo-fi hip-hop. I still enjoy the variability of listening to different genres of music, but recently I've started to listen to binaural beats while working and have found them to be quite beneficial.

## What are Binaural Beats?

I initially heard about binaural beats on the Flow State [podcast](https://open.spotify.com/show/4IssY4XjHXdpTNOzpaeyxh?si=4e2165da83b2491c) a couple years ago and was intrigued by the idea of using sound to alter your brainwaves. I thought they were kind of interesting but didn't think much of them until I heard Andrew Huberman mention them in an interview with Lex Fridman. At that point I did a bit more research and decided to give them a try more consistently.

Simply speaking a **binaural beat is an illusion created by the brain when you listen to two tones with slightly different frequencies at the same time.** I'll be the first to admit that there are a lot of claims out there around binaural beats that are not backed by science. However, there is some research that suggests that binaural beats can help with focus and attention. I'm not going to dive into the research in this post, but I think this [video](https://www.youtube.com/watch?v=iboQ7mmGGGU) by Andrew Huberman does a good job of explaining the science behind binaural beats at a high level.

In the video Andrew mentions research indicating that listen to binaural beats that target 40 Hz can help with getting into a state of focus or concentration. He also mentions the use of white, pink, and brown noise to complement binaural beats during periods of concentration.

## How do I listen to Binaural Beats?

I've been listening to binaural beats pretty consistently for a couple months and have found them to be helpful. I found an [album](https://open.spotify.com/album/1QsPrWeubge8WfX20IFDql?si=QhWO4ObMTJ6mN9mpBRJP4g) on Spotify that contains a track at the 40 Hz frequency that I'll use to get into a state of focus. At that point I'll typically listen to the rest of the album which contains tracks at different frequencies. Once I'm in a state of focus I find that I can listen to other types of music without losing the focus that I gained from starting with binarual beats.

Overall I think this is a very personal process and what works for me might not work for everyone. As I mentioned earlier, there isn't a lot of hard evidence on the effects of binaural beats so you're mileage may vary. With that being said I think its worth giving binaural beats a shot if you're someone who is looking to take your ability to concentrate and focus to the next level.

## Resources

- [Do Binaural Beats Increase Focus & Attention? | Dr. Andrew Huberman](https://www.youtube.com/watch?v=iboQ7mmGGGU)
- [Binaural Beats - Peak Awareness (Spotify)](https://open.spotify.com/album/1QsPrWeubge8WfX20IFDql?si=QhWO4ObMTJ6mN9mpBRJP4g)


Over the years I've found it helpful to listen to music while doing work that requires some amount of focus or concentration. Recently I've started to listen to binaural beats during these periods of work and have found them to be very helpful. In this post, I'm going to share some of the benefits I've found from listening to binaural beats and also how I listen to them. Let's dive in!

Using Binaural Beats to Improve Focus


Artificial intelligence has been around for a long time both in theory and in practicality. Alan Turing developed the Turing Test as early as 1950 and since then there have been gradual advancements in the space of artificial intelligence and machine learning. As AI technology has evolved we've found ways to integrate it into our lives through games like chess, search engines, recommendation systems, autonomous vehicles, and much more. So if all of this technology has been in place for so long what makes the recent advancements in **generative AI** and around OpenAI's ChatGPT different? Is there any substance behind all of the hype that it has received or is the hype not real? Honestly, I don't have answers to these questions, but I do have some thoughts that I'd like to get out of my head.

The recent advancements in generative AI, that is artificial intelligence capable of creating content, feel different to me. For the first time that I can remember we can ask machines to create content like code, stories, images, videos, music, etc. from nothing. At least it seems like it is creating it from nothing. It's my understanding that the underlying language models have been trained on so much data from the web that they're able to translate just about any request into a response that feels unique.

In the past year, we've seen the introduction of ChatGPT and GitHub Copilot, which both seem to be revolutionary tools in their own right. OpenAI's ChatGPT is built with massive language models that can provide "human-like" responses to text prompts. The free version of ChatGPT is using GPT-3.5 which is impressive but is limited in the number of tokens it can store which limits its effectiveness. The latest release of ChatGPT with GPT-4 appears to improve upon the shortcomings of its predecessor, which makes it potentially more useful. I haven't had a chance to experiment with ChatGPT using GPT-4 yet since it is behind their subscription, but from a software engineer's perspective I think this [video](https://www.youtube.com/watch?v=N4sDzidCudQ) by Nick Chapsas does a great job of demonstrating its power.

With each release and advancement in this space, the question that keeps coming up for knowledge workers (like software engineers) is _"Should we be worried about our jobs?"_. I think that everyone has their own opinion on this, but my take is that the time will eventually come when software engineers, at least as we view them today, will no longer be needed. However, I don't think that time will come for a long time. I think in the meantime, knowledge workers will find it beneficial to begin adopting AI-powered tools and use them to increase their productivity. By doing so we make ourselves more valuable to the companies that we work for, but also potentially continue to push the needle on the level of abstractions that we operate at. Currently, most software engineers spend a lot of time writing and reading code that gets packaged and deployed for use by other developers, servers, or end users. What if the tools provide an opportunity to begin composing systems and applications at a layer higher than the code? I'm not sure if this is possible, but I think it's where things could be headed.

I think it's important to mention that all of the great advancement doesn't come without risk. The rapid development of some of these tools can result in bugs, vulnerabilities, and unforeseen exploits. We've seen API keys and credentials get leaked in GitHub Copilot. ChatGPT can hallucinate and provide completely incorrect answers to questions while appearing very confident in those answers. Users have also learned to use "prompt injection" attacks that result in the user's prompt being modified before being sent to the backend servers for the models to process.

I'll be honest, I've taken my time on joining the hype train that is gaining steam around AI-based tools, but there comes a time when the hype doesn't feel like hype anymore. For me, this is that time. I'm not planning to go off and build a startup around this technology, but I think it carries enough weight to at least begin familiarizing myself with the tools available and using them where I can.

## Resources

[https://simonwillison.net/2023/Apr/14/worst-that-can-happen/](https://simonwillison.net/2023/Apr/14/worst-that-can-happen/)

[https://changelog.com/podcast/534](https://changelog.com/podcast/534)

[https://podcasts.apple.com/us/podcast/ai-tools-today/id1602572955?i=1000608610109](https://podcasts.apple.com/us/podcast/ai-tools-today/id1602572955?i=1000608610109)


As developers, we are constantly exposed to new tools and technologies, but the most recent wave of AI advancements feels different. In this post, I'm going to share my thoughts on whether or not the hype around generative AI is real.

Is it Time to Lean into AI?


I began using CockroachDB several months ago for the blog post reaction implementation (don't forget to like this post 😏). During the initial implementation, I was hoping to use [Postgres.js](https://github.com/porsager/postgres) to connect to my CockroachDB serverless cluster. I, unfortunately, ran into a couple of stumbling blocks and opted to use the [node-postgres](https://github.com/brianc/node-postgres) npm package, which is actually recommended in the CockroachDB documentation.

Using node-postgres was fine, but I was still interested in Postgres.js for the following reasons.

- Easy-to-use API that allows for flexible and safe SQL query/command definitions
- Supports TypeScript out of the box
- ESM support (pg only supports CommonJS)
- Postgres.js markets itself as the fastest Postgres library for Node

I'll start off by saying that Postgres.js has great documentation and I think I could have gotten beyond my initial hurdles had I persisted, but I decided to take a path of "least resistance" and use node-postgres instead. I was recently wishing for ESM and TypeScript support from my database methods, which prompted me to revisit Postgres.js. To get started we'll be working in a file called `db.js` that imports the `postgres` module.

```js
// db.js

import postgres from "postgres";

// connection details to come
```

At the heart of the database connection is the `postgres([url], [options])` method, which provides parameters to define the information required to connect to a database. In my case, I'll be using a connection string URL, but the option is available to provide individual connection values as part of the object passed to the `postgres` method. The options provided will override any values that are in the connection string URL.

```js
// db.js

import postgres from "postgres";

// Always get sensitive information from the environment variables or secrets
const connectionString =
  "postgresql://user:password@db_server_url?sslmode=verify-full";

const sql = postgres(connectionString);

export default sql;
```

So far this is standard code for connecting to databases, the aspect that I stumbled on initially was the `sslmode=verify-full` option that requires a Certificate Authority signed SSL certificate to connect. This SSL mode isn't "required", but it is [strongly recommended](https://www.cockroachlabs.com/docs/v22.2/connection-parameters#secure-connections-with-urls) for production clusters. I needed a way to provide the certificate to CockroachDB through the driver provided by Postgres.js, but wasn't sure how.

I initially was expecting there to be some extra work to pass the certificate to the database driver, but recently found out that the Postgres.js driver will automatically use the certificate that exists on the server. This means that in order to use the `sslmode=verify-full` option for local development, I need to have the certificate installed on my development machine. Luckily CockroachDB provides a simple way to request, download, and save the certificate in the correct location.

### Login to your cluster and select the database you want to connect to.

![cockroachdb-databases](https://res.cloudinary.com/aaron-bos/image/upload/v1680309310/cockroachdb-databases_bqy7jf.png)

### Click on the connect button

![cockroachdb-connect-button](https://res.cloudinary.com/aaron-bos/image/upload/v1680309310/cockroachdb-connect-button_jqgbhk.png)

### Copy, paste, and run the command provided in the modal

![cockroachdb-cert-download](https://res.cloudinary.com/aaron-bos/image/upload/v1680309310/cockroachdb-cert-download_igzmhf.png)

I think one point that is worth calling out before wrapping up is that `sslmode=verify-full` isn't the only option for connecting to CockroachDB, but it is the only recommended secure option. The documentation does indicate that `sslmode=disabled` can be used for development purposes. The reason SSL is so important for database connections is that without it, connections are vulnerable to "Man in the middle" (MITM) attacks.

Overall I'm really happy that I transitioned to using Postgres.js for the reasons I listed earlier in the post. Ultimately the transition from pg to Postgres.js was painless and I'm a little bummed that I didn't persevere through the hurdles that I encountered months ago. I did learn a bit about SSL along the way so it's been a worthwhile endeavor.


I've been using CockroachDB on this blog for some time and I've recently transitioned to using the Postgres.js library for interacting with the database. In this post, I'm going to share how to connect to CockroachDB from a Node app using Postgres.js.

Connecting to CockroachDB with Postgres.js


## JavaScript Modularity

For the longest time, JavaScript was purely a language of the web. In the days of jQuery (and before), it was common to include all of the JavaScript that a website needed in a single file. This meant that we would define objects like variables and functions in the global scope, which had the benefit of being able to access everything necessary in that file. While using the default global scope for everything is convenient, it can be error-prone and difficult to maintain. When code begins to grow in size and complexity, developers often reach for modularity. For the longest time, JavaScript in the browser didn't have a great solution for modularity. You could separate code in different script files, but there was no guarantee that objects wouldn't be mutated in the global scope.

As the web development domain continued to evolve to more Node-based tooling, the need for modularity became more apparent. In 2018 ECMAScript Modules were made officially available in all major browsers. This meant that JavaScript code could be defined, exported, and imported in modules that run directly in the browser. Over time Node.js began to support ES Modules, while also supporting an existing module solution called CommonJS. ES Modules and CommonJS share a common goal of modularity in JavaScript, but unfortunately, they don't play too nicely when being used in the same project. I recently was working on a project that used ES Modules in the browser. I wanted to use Jest to write some tests for these modules and I ended up having to use an experimental Node.js flag to run the tests with ES Modules. My goal for this post is to simply understand more about each of the module systems, which I believe will help me in the future when working in frontend or Node-based codebases.

## CommonJS

According to the Node.js documentation, CommonJS is the original packaging solution for JavaScript. CommonJS isn't available to use in browsers so it is used in purely Node-based server-side applications. If you're wondering why CommonJS modules can be used within popular libraries like React, it's because that code is often transpiled and bundled before sending to the browser. If you're not too familiar with CommonJS, but have imported modules in JavaScript using the `require()` method then you've used CommonJS. The method of referencing other modules with `require` is the main difference between CommonJS and ES Modules.

Node.js will default to CommonJS unless otherwise specified by file type or an indication in the `package.json`, but it is best to be explicit when defining module type since Node.js supports CommonJS and ES Modules. There are a few ways to specify that modules are using CommonJS in a Node application.

- Use the file extension `.cjs`
- Set the `"type"` field to `"commonjs"` in the `package.json`
- Including `--input-type=commonjs` when invoking Node from the command-line

Another aspect of CommonJS that differs from ES Modules is the method of exporting members. Node wraps the module in a function wrapper which can be used to access some global-like objects. For example, the module wrapper provides a `module` object that the module author can use to export members from a module by setting the `exports` property. The module wrapping occurs before any module code is executed.

```javascript
(function (exports, require, module, __filename, __dirname) {
  // Module code actually lives in here
});
```

Let's put these CommonJS pieces together with an example. We'll define a module called `ai.js` which exports a function called `processPrompt`. The `ai` module is then required and referenced in another module called `prompt.js`.

```javascript
// ai.js

const processPrompt = (prompt) => {
  switch (prompt) {
    case "Are you human?":
      return "No, I'm your friendly neighborhood AI.";
    case "Will you take my software engineering job?":
      return "Yes, but not today.";
    default:
      return "I'm sorry, you've reached your request limit.";
  }
};

module.exports = {
  processPrompt,
};
```

```javascript
// prompt.js

const { processPrompt } = require("./ai");

console.log(processPrompt("Are you human?"));
console.log(processPrompt("Will you take my software engineering job?"));
console.log(processPrompt("Why does time only flow in one direction?"));
```

By running `node prompt.js` we'll see this output.

```shell
$ node prompt.js
No, I'm your friendly neighborhood AI.
Yes, but not today.
I'm sorry, you've reached your request limit.
```

CommonJS seems to be the de-facto method of modularizing JavaScipt that is meant to run on the server. In my opinion, things got a little more complicated when Node decided to support ES Modules.

## ES Modules

Modularity isn't anything new to the Node.js ecosystem, but it is something relatively new to the JavaScript that we run in browsers. It wasn't until mid-2018 that all major browsers shipped with the ability to natively import and export from modules in JavaScript, which was accomplished through ES Modules. The implementation details behind CommonJS and ES Modules are presumably quite different, but they both have the same goal of providing modules in JavaScript. Two keywords make ES Modules visibly different from CommonJS. They are `import` and `export`, pretty simple in my opinion.

To use ES Modules natively in the browser we can simply add `type="module"` to the `<script>` tag that is referencing the module.

```html
<script src="main.js" type="module">
```

Since the introduction of ES Modules to the web, Node.js has also adopted support for them. In Node.js we have a few options to tell the JavaScript engine ES Modules should be used for files. The options are quite similar to those used for CommonJS, but slightly different to indicate ES Modules.

- Use the file extension `.mjs`
- Set the `"type"` field to `"module"` in the `package.json`
- Including `--input-type=module` when invoking Node from the command-line

Files with the extension of `.mjs` can also be used when referencing modules in code targeting the browser.

As I mentioned the `import` and `export` keywords are the main user-facing differentiation between ES Modules and CommonJS. The `import` keyword is used to import objects or functions from another module or file. The `export` keyword is used to expose module members (objects and functions) that can then be imported by other modules.

> The import and export keywords are to ES Modules what the require function and module.exports object is to CommonJS respectively.

That declaration may be slightly reductive, but that's how I view them. Obviously, the way that the modules are parsed and evaluated by the respective JavaScript engines is bound to be quite different. Luckily as developers, we don't have to worry about their low-level implementation _too often_.

If we were to translate our previous code sample to ES Modules, there are only a few lines that need to change. In `prompt.js` we need to change the `require` method to the `import` keyword.

```javascript
// prompt.js
import { processPrompt } from "./ai";
// rest of code
```

Similarly in the `ai.js` we need to change `module.exports` to `export`.

```javascript
// ai.js
// rest of code
export { processPrompt };
```

In this post, we looked at CommonJS and ES Modules through the lens of the need for modularity and the environments they are used in. There is a ton of great documentation available to learn more about both of these module systems. So if you're interested in learning more I suggest using this post as a foundation to go deeper in those areas.


I was recently working on a project involving quite a bit of JavaScript. I always knew about ES Modules and CommonJS, but I never knew much about their differences. This post is a result of my exploration of CommonJS and ES Modules to learn more about their history and use cases.

Hey! 👋

My name is Aaron Bos and this is my blog.

Recent Posts