mjswensen.com

Rejoicing in His coming

Sun, 28 Dec 2025 18:15:00 +0000

Intro

Good morning!

I could not for the life of me figure out how to start my talk. I rewrote this opening paragraph at least a few times and never could get anything that felt quite right. I kept trying to come up with a catchy hook because I wanted to do a good job and be impressive. Also, this message of God’s love that I want to share with you is so important.

I couldn’t figure it out, so instead, I’m going to use someone else’s words to help me paint a picture of what it means to “rejoice.” The word “rejoice” is a word we hear often, especially at this time of year, but maybe don’t fully know what it means or looks like since we don’t use it in everyday speech. This is from a song called “My Everything” by Adam Young:

When my hope is lost And my strength is gone I run to you and you alone When I can’t get up and I can’t go on I run to you and you alone

‘Cause you’re my light in the dark And I sing with all of my heart

Hallelujah My almighty God divine Hallelujah I am yours and you are mine This is all I know how to say Hallelujah Hallelujah You’re my everything

So we don’t rejoice because life is easy, or because answers come quickly. We rejoice because Jesus Christ came, and we rejoice because He will come again.

Why we rejoice

Jesus Christ did not come because humanity had proven itself worthy of rescue. He came because heaven does not abandon its children.

This is where I want to slow down because I feel that it is critically important to understand.

Christ did not come for humanity in the abstract. He came for people. For individuals with histories, contradictions, hopes, and fears. He came for you. Personally. With full awareness of who you are, with full awareness of what you carry, and full awareness of what you fear might disqualify you from His love. Because you matter.

A personal experience

I want to share something from my own life that I am still trying to figure out.

There are days when I feel spiritually stretched thin. I’m trying to be present as a husband and father, faithful in my discipleship and ministering responsibilities, and yet I often feel as though I am carrying more than I am managing well. I find myself wondering if I am truly magnifying my calling. I make myself feel guilty for my minuscule ministering efforts.

I believe in Christ. I trust His gospel. But sometimes I still wonder whether I am living it well. I suspect I’m not alone.

And in moments like that, I personally don’t feel motivated by reminders that I should just try harder. What I need is the assurance that Christ did not come because I was sufficient. He came because I wasn’t.

The angel’s declaration to the shepherds we remembered this week for Christmas was not conditional:

“I bring you good tidings of great joy, which shall be to all people.”

“All people” includes those who are striving but tired. Faithful but unsure. Devoted but, like me, still learning how to trust grace as much as effort.

That is why we rejoice in His coming.

How we rejoice

So then, how do we rejoice in His coming?

The answer, mercifully, is simple.

We rejoice by living close to Him.

Not perfectly, or performatively, but intentionally.

We rejoice in His coming when we pray—not only because we are disciplined, but also because we are dependent.
We rejoice when we open the scriptures—to hear His voice and feel close to Him.
We rejoice when we partake of the sacrament—not only as a grounding regular routine, but as a warm, welcoming reunion with the Divine.

A Jewish example

Recently, my sweetheart Christine has been teaching our family about different faith traditions, on what we have been calling our “holy envy tour.” Last week during Hanukkah we spent time learning about Judaism. Her insight that struck me most was the incredible depth of faith required by the Jewish people to continue waiting for the Messiah—century after century—without losing hope.

A Latter-day Saint perspective

As Latter-day Saints, we stand in a sacred place, where we no longer wait in uncertainty, because we know who the Messiah is. We know what He has done. We have the great blessing of scriptural evidence of His power, and of His mercy. And we we have some idea about what to look forward to when He comes again.

My favorite part of all of the scriptures is when the people of the Book of Mormon rejoice in His visitation of the Americas. He asks them to come forward—one by one—to see Him and feel Him individually. This is from 3 Nephi chapter 11:

13 And it came to pass that the Lord spake unto them saying:

14 Arise and come forth unto me, that ye may thrust your hands into my side, and also that ye may feel the prints of the nails in my hands and in my feet, that ye may know that I am the God of Israel, and the God of the whole earth, and have been slain for the sins of the world.

15 And it came to pass that the multitude went forth, and thrust their hands into his side, and did feel the prints of the nails in his hands and in his feet; and this they did do, going forth one by one until they had all gone forth, and did see with their eyes and did feel with their hands, and did know of a surety and did bear record, that it was he, of whom it was written by the prophets, that should come.

16 And when they had all gone forth and had witnessed for themselves, they did cry out with one accord, saying:

17 Hosanna! Blessed be the name of the Most High God! And they did fall down at the feet of Jesus, and did worship him.

For some, rejoicing might be outwardly loud and exuberant. After all, we believe that we cheered and jumped for joy at the presentation of the Plan of Salvation before coming to Earth. For me personally, it’s usually in the quiet moments that I feel like my heart is rejoicing the loudest.

A personal experience

Some months ago, on a particularly difficult day during a particularly difficult trial, I was driving in the car by myself. I remember praying to Heavenly Father, wondering when He was going to lift this trial from my family. I asked, “where are You?” I think I even said it out loud. I had some music on, not spiritual music, just a regular song. Right then the song had this beautiful melody that captured my full attention. It felt like a bolt of lightning went through my heart when I felt the Spirit say, “I’m right here, in this melody. I’m in the trees and the air, I’m all around you. I’m here with you.” My heart rejoiced at the absolute miracle that a loving Creator of the Universe was aware of little me and took the time to speak to my heart.

Conclusion

Brothers and sisters, I testify that Jesus Christ came because the Father knows us each individually. I testify that His love is not theoretical and His grace is not distant. He came because you matter—and He continues to come now, quietly and faithfully into our hearts, until the day He comes again in person.

Hallelujah.

In the name of Jesus Christ, amen.

Clean + Format: a UX pattern for high-quality user input fields

Wed, 07 Aug 2024 03:42:50 +0000

Forms are at the core of how users get data into web applications. And there are so, so many ways to get the UX of text input fields wrong. At Rivet, we’ve spent some time crafting what we believe is a nice balance between user-friendly, forgiving input fields and real-time validation and formatting.

The secret is simple on the surface but represents a novel insight: typically, the value of a text input is tied to a single piece of state, and all operations like formatting and validation are run against that state. Depending on the implementation, this can lead to user frustration as forms are validated prematurely or input formatted while the user is still trying to type. The answer to an improved experience lies in a two-step approach that separates the cleaning and the formatting of typed input, allowing users to type freely while ensuring data integrity and (later) prettified display of the inputted data.

This approach works for any type of field expecting a particular type of input data, for example:

Currency input fields
Integer-only fields
Number fields with rounding to some maximum number of fractional digits
Fields with a maximum or minimum allowed value
Text fields where a particular case is enforced (uppercase-only, lowercase-only)
Phone number or email fields
etc.

Let’s dive into how it works.

Secret sauce

The core tenets of the approach are as follows:

In real time as the user types input, clean and convert the input into the desired computer-friendly value type on a best-effort basis. It’s important that this cleaning algorithm be deterministic and idempotent.
1. Emit this cleaned up value from the component immediately for use in the application.
2. In the case of two-way binding, this cleaned value might be immediately sent back into the component from the outer application—pass it through the clean() function again, and if the resulting value is the same as the result of clean() on the user’s current raw input, do nothing (so as not to interrupt the user’s work in progress).
Once the user leaves the field (on the blur event), pass the cleaned value to a format() function that produces a human-friendly stringified version of the cleaned value.
1. Overwrite the user’s raw input with this formatted value.

That’s a lot to grok—let’s break it down step by step as the user flows through a typical input experience.

Example: currency field

Suppose we want to implement a user-friendly currency field for inputting USD values. Yes, a simple <input type="number"> might suffice in some situations, but it leaves a lot to be desired in terms of user experience, particularly with the visual formatting of user input. So we use an <input type="text"> as the core of our custom component and plug in our approach as follows:

The user types in their currency value, but makes an error or two on the way, typing 12,34.567a.
We don’t get in the user’s way and try to format or validate their input. Instead, we make a best guess effort at what they were intending. This is our clean() function:
1. We’ll use an algorithm that filters out non-digit characters except ., leaving us with 1234.567.
2. We’ll parse this new string as a number and use a rounding function to coerce our number into a maximum of two fractional digits, leaving us with 1234.57.
3. This is our best guess at the user’s intention. We’ll emit this cleaned numeric value to the application.
The application may send this value back to us, or it may send us a different value. This is how we’ll react to values coming in programmatically:
1. We’ll run the value coming in through our clean() function, and we’ll also run the user’s current raw input through the clean() function. If the two results are an exact match, we’ll assume the application is just sending us back the value we just emitted, and do nothing. This is because if we format it and update the <input>, the user’s work will be interrupted and their cursor position will change. If it’s different, however, we can assume that the application state has changed in some way—perhaps we loaded some data from the server and need to update the state of this field—so we’ll go ahead and run this value through our format() function (more on this below) and overwrite the user’s text in the <input>.
Once the user leaves the input field (on the blur event), we’ll take our most recent result of clean() and pass it through format(), and update the value of the <input>. This is what the format() function will do:
1. Our cleaned, computer-friendly value is 1234.57. We want to turn this into something more human-friendly with some typical currency formatting. We can use the Intl API or any number formatting library to stringify this value into $1,234.57.
2. We write the formatted value to the <input> for display.

Here’s what it looks like in action. Note the clean()ed value echoed back to the UI under the field for demonstration purposes.

Precise semantics of `clean()` + `format()`

So how do you determine how to implement your clean() and format() functions, and which bits of processing should belong in each one?

Function	`clean()`	`format()`
Purpose	Takes raw user input and converts it into a computer-friendly value for use by the application.	Takes the cleaned value from `clean()` and formats it into a human-friendly string.
Implementation responsibility	Likely to be bespoke but could be delegated to a library depending on the needs of the input.	Unless very specific formatting is needed, likely to be delegated to a formatting library or language/platform API.
Idempotent?	Yes	No
Deterministic?	Yes	Yes

Conclusion

Creating user-friendly input fields is a delicate balancing act. By separating the cleaned computer-friendly value from the user’s raw input state, we ensure that they can type freely without interruptions, while also maintaining data integrity and sending the correct data type to the outer application for immediate use. After the user is done working we can present neatly formatted results. This approach can be applied to various types of input fields; wherever some additional structure is needed on top of the raw input text.

The single most important factor that differentiates front-end frameworks

Sun, 11 Jun 2023 05:14:49 +0000

There are tons of blog posts on the internet about how frameworks differ and which one to pick for your next web project. Usually they cover a few aspects of the framework like syntax, development setup, and community size.

This isn’t one of those posts.

Instead, we’ll go directly to the crux of the main problem front-end frameworks set out to solve: change detection, meaning detecting changes to application state so that the UI can be updated accordingly. Change detection is the fundamental feature of front-end frameworks, and the framework authors’ solution to this one problem determines everything else about it: developer experience, user experience, API surface area, community satisfaction and involvement, etc., etc.

And it turns out that examining various frameworks from this perspective will give you all of the information you need to determine the best choice for you and for your users. So let’s dive deep into how each framework tackles change detection.

Major frameworks compared

We’ll look at each of the major players and how they have tackled change detection, but the same critical eye can apply to any front-end JavaScript framework you may come across.

React

“I’ll manage state so that I know when it changes.” —React

True to its de-facto tagline, change detection in React is “just JavaScript.” Developers simply update state by calling directly into the React runtime through its API; since React is notified to make the state change, it also knows that it needs to re-render the component.

Over the years, the default style for writing components has changed (from class components and pure components to function components to hooks) but the core principle has remained the same. Here’s an example component that implements a button counter, written in the hooks style:

export default function App() {
  const [count, setCount] = useState(0);
  return (
    <div>
      <button onClick={() => setCount(count - 1)}>decrement</button>
      <span>{count}</span>
      <button onClick={() => setCount(count + 1)}>increment</button>
      <button onClick={() => setTimeout(() => setCount(count + 1), 1000)}>increment later</button>
    </div>
  );
}

The key piece here is the setCount function returned to us by React’s useState hook. When this function is called, React can use its internal virtual DOM diffing algorithm to determine which pieces of the page to re-render. Note that this means the React runtime has to be included in the application bundle downloaded by the user.

Conclusion

React's change detection paradigm is straightforward: the application state is maintained inside the framework (with APIs exposed to the developer for updating it) so that React knows when to re-render.

Angular

“I’ll make the developer do all the work.” —Angular

When you scaffold a new Angular application, it appears that change detection happens automagically:

@Component({
  selector: 'counter',
  template: `
    <div>
      <button (click)="count = count - 1">decrement</button>
      <span>{{ count }}</span>
      <button (click)="count = count + 1">increment</button>
      <button (click)="incrementLater()">increment later</button>
    </div>
  `
})
export class Counter {
  count = 0;

  incrementLater() {
    setTimeout(() => {
      this.count++;
    }, 1000);
  }
}

What’s really happening, is that Angular uses NgZone to observe user actions, and is checking your entire component tree on every event.

For applications of any reasonable size, this causes performance issues, since checking the entire tree quickly becomes too costly. So Angular provides an escape hatch from this behavior by allowing the developer to choose a different change detection strategy: OnPush. OnPush means that the onus is on the developer to inform Angular when state changes so that Angular can re-render the component. Aside from the default naive strategy, OnPush is the only other change detection strategy Angular offers. With OnPush enabled, we must manually tell Angular’s change detector to check the new state if it ever gets updated asynchronously:

@Component({
  selector: 'counter',
  template: `
    <div>
      <button (click)="count = count - 1">decrement</button>
      <span>{{ count }}</span>
      <button (click)="count = count + 1">increment</button>
      <button (click)="incrementLater()">increment later</button>
    </div>
  `,
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class Counter {
  constructor(private readonly cdr: ChangeDetectorRef) {}

  count = 0;

  incrementLater() {
    setTimeout(() => {
      this.count++;
      this.cdr.markForCheck();
    }, 1000);
  }
}

For applications of any reasonable complexity, this approach quickly becomes untenable.

Alternative solutions are introduced to wrangle this problem. The primary one that the Angular docs suggest is to use RxJS observables in conjunction with the AsyncPipe:

enum Action {
  INCREMENT,
  DECREMENT,
  INCREMENT_LATER
}

@Component({
  selector: 'counter',
  template: `
    <div>
      <button (click)="update.next(Action.DECREMENT)">decrement</button>
      <span>{{ count | async }}</span>
      <button (click)="update.next(Action.INCREMENT)">increment</button>
      <button (click)="update.next(Action.INCREMENT_LATER)">increment later</button>
    </div>
  `,
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class Counter {
  readonly update = new Subject<Action>();

  readonly count = this.update.pipe(
    switchScan((prev, action) => {
      switch (action) {
        case Action.INCREMENT:
          return of(prev + 1);
        case Action.DECREMENT:
          return of(prev - 1);
        case Action.INCREMENT_LATER:
          return of(prev + 1).pipe(delay(1000));
      }
    }, 0),
    startWith(0)
  );

  readonly Action = Action;
}

Under the hood, AsyncPipe takes care of subscribing to the observable, informing the change detector when the observable emits a new value, and unsubscribing when the component is destroyed. Observables are a powerful way to model state changes over time, but they come with some serious drawbacks:

They are difficult to debug.
They have a very steep learning curve.
They are great for modeling streams of values (think: mouse movements), but they are overkill for the more common use cases (simple state changes like the on/off state of a checkbox).

To overcome the shortcomings of the default change detection paradigm, the Angular team is working on a new approach called Signals. Conceptually, signals are similar to Svelte stores (which we’ll get to later), and fundamentally, they solve the change detection problem the same way as React; the framework is taking control over the application’s state so that changes can be easily monitored and re-renders can be as efficient as possible.

From the Angular docs:

Angular Signals is a system that granularly tracks how and where your state is used throughout an application, allowing the framework to optimize rendering updates.

This is a large paradigm shift, making Angular applications more similar to the other frameworks.

Conclusion

Angular's change detection is a disaster. The developer gets two suboptimal choices: (1) the slow and naive default implementation, or the complexity of managing change detection manually. Signals will make it much better, though nearly a decade too late.

Vue

“I’ll track changes to state and react accordingly.” —Vue

Vue’s approach to change detection is subtly different than both React and Angular. Rather than calling a framework function to change state (React) or changing state and then informing the framework that it has been changed (Angular), you work with state objects that have been specially instrumented by the framework to intercept and detect changes.

Confusingly, Vue has two different APIs that wrap the same underlying change detection engine differently. Under the “Options API,” you define an object that contains your state, and Vue assigns a proxied version of that object as a member of this for use in the component’s functions:

<template>
  <div>
    <button @click="decrement">decrement</button>
    <span>{{ count }}</span>
    <button @click="increment">increment</button>
    <button @click="incrementLater">increment later</button>
  </div>
</template>

<script>
  export default {
    data() {
      return {
        count: 0
      };
    },
    methods: {
      decrement() {
        this.count--;
      },
      increment() {
        this.count++;
      },
      incrementLater() {
        setTimeout(() => {
          this.count++;
        }, 1000);
      }
    }
  };
</script>

Alternatively, the “Composition API” is somewhat similar to React’s hooks: a framework function is called to retrieve a state object that Vue can monitor for changes:

<script setup>
  import { ref } from 'vue';

  const count = ref(0);

  function increment() {
    count.value++;
  }

  function decrement() {
    count.value--;
  }

  function incrementLater() {
    setTimeout(() => {
      count.value++;
    }, 1000);
  }
</script>

<template>
  <div>
    <button @click="decrement">decrement</button>
    <span>{{ count }}</span>
    <button @click="increment">increment</button>
    <button @click="incrementLater">increment later</button>
  </div>
</template>

Conceptually, the object returned from ref() has a getter and a setter for value, which allows Vue to track changes to it.

Conclusion

Vue utilizes JavaScript language features to allow developers to work with stateful variables without thinking about change detection.

Svelte

“I’ll figure it out for you at compile time.” —Svelte

On the surface, Svelte’s version of our counter component looks pretty similar to the other frameworks:

<script>
  let count = 0;
  function decrement() {
    count--;
  }
  function increment() {
    count++;
  }
  function incrementLater() {
    setTimeout(() => {
      count++;
    }, 1000);
  }
</script>

<div>
  <button on:click="{decrement}">decrement</button>
  <span>{count}</span>
  <button on:click="{increment}">increment</button>
  <button on:click="{incrementLater}">increment later</button>
</div>

But Svelte’s approach to change detection is completely novel in comparison. At compile time, Svelte analyzes an AST (Abstract Syntax Tree) of the component’s code and injects some code into the compiled output that surgically updates the DOM when necessary. For example, here is what the compiled decrement() function looks like:

function decrement() {
  $$invalidate(0, count--, count);
}

Where $$invalidate is a call to Svelte’s internals to instruct the compiled component to update the DOM.

This compile-time approach means that Svelte applications don’t need to bundle a large runtime along with the application itself.

Conclusion

Svelte strikes a rare win-win balance: developers don't have to think about change detection at all, and can interact with stateful variables intuitively; yet the end user's experience is improved through better performance because a bare-minimum application (with change detection baked in) is shipped to the browser.

So, what?

The nuances of how various frameworks choose to tame this beast is not limited to how things work at the component level; it ripples out to everything else about the framework. To name just a few examples: the concepts used to create custom React hooks composed of the basic hooks provided by React out of the box are not relevant to generalizing component behavior in Vue; the challenge of working with observables for state management in Angular has led folks to try and find ways to convert component input props to observables; the framework’s API, dictated by its change detection management paradigm, affects how well it integrates with productivity and quality tools like typechecking, testing, and linting. And so on, and so forth.

And those are just examples from the developer’s point of view. Each approach has implications on the performance of the application for the end user. React, Vue, and Angular each ship a runtime to the user’s browser that needs to be parsed and executed. Svelte’s choice to be a compile-time framework obviates this need in most cases, so the user gets a faster loading experience. Each framework has subtleties that make it more susceptible to particular classes of bugs (often around state management or change detection) that the end user will experience.

Find a change detection paradigm that fits the needs of your application, and everything else will fall into place. Pick one that doesn’t work, and you’ll be fighting against it for the life of the project.

How to set up a WireGuard VPN for personal use

Sun, 19 Mar 2023 00:04:28 +0000

VPNs are a great way to level up your privacy online. Here’s how to set one up from scratch.

Step 1: spin up and connect to your cloud server

Using your cloud provider of choice, provision a new server instance. Since the VPN will be for personal use only, inexpensive instances will work fine. Select any operating system that WireGuard supports; we’ll assume Ubuntu for this tutorial.

Connect to your server via SSH as the root user.

Root user

Heads up, all commands outlined in this tutorial assume the root user, so you won't see any commands prefixed with sudo.

Step 2: install WireGuard

If you picked Ubuntu for your server’s OS, you can install WireGuard with one command:

apt install wireguard

Working directory

For the remaining steps, change your working directory to /etc/wireguard.

Step 3: generate a key pair for your VPN server

First, generate a private key:

wg genkey > private.key

Then, use the private key to derive a public key:

wg pubkey < private.key > public.key

These are the keys your VPN server will use when encrypting traffic with your client VPN peers.

Step 4: create your server configuration file

With WireGuard installed and keys generated, we’re ready to create our VPN configuration.

First, find the name of the public network interface:

ip route list default

The output might look something like this: default via ... dev eth0 proto static—the eth0 part is what we’re after.

Create a file called wg0.conf with the following contents, being sure to include the private key where required, and replacing eth0 with the name of the network interface:

[Interface]
SaveConfig = true
PostUp = ufw route allow in on wg0 out on eth0
PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PreDown = ufw route delete allow in on wg0 out on eth0
PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 51820
PrivateKey = <the contents of private.key>

Step 5: configure IP forwarding

Add the following line at the bottom of /etc/sysctl.conf:

net.ipv4.ip_forward=1

Then run sysctl -p to load the new configuration.

Step 6: allow UDP traffic

Update the operating system firewall to allow traffic on the port specified in the WireGuard configuration:

ufw allow 51820/udp

Restart UFW to pick up the new configuration:

ufw disable
ufw enable

Step 7: configure the WireGuard server to start on boot

systemctl enable wg-quick@wg0.service

Step 8: generate keys for clients

Now we’ll generate keys for the devices that will be connecting to the server. Follow this process for as many clients as you need:

Output the private key with wg genkey
Output the corresponding public key with echo -n '<the private key>' | wg pubkey
Mark the public key as allowed with wg set wg0 peer <the public key> allowed-ips 10.8.0.2; for each client increment the last digit of the IP address

Verify that the public keys have been added as peers by running the wg command with no arguments. If you’ve configured three clients, the output should look something like this:

interface: wg0
  public key: <the server's public key>
  private key: (hidden)
  listening port: 51820

peer: <first client's public key>
  allowed ips: 10.8.0.2/32

peer: <second client's public key>
  allowed ips: 10.8.0.3/32

peer: <third client's public key>
  allowed ips: 10.8.0.4/32

Step 9: configure clients

Finally, configure your client devices to connect to your WireGuard VPN server. This process will be a little different depending on whether you are using the iOS app, Android app, or another Linux installation of WireGuard. Generally, though, your client configuration should look something like this:

[Interface]
PrivateKey = <the client private key>
Address = <the client IP address>/24
DNS = <the DNS resolvers you wish to use (optional)>

[Peer]
PublicKey = <the server public key>
Endpoint = <the server IP address>:51820
AllowedIPs = 0.0.0.0/0

The 0.0.0.0/0 configuration value indicates that all internet traffic should be tunnelled through the VPN connection.

Happy tunneling!

Cascade layers, `subgrid`, and container queries: What's new in CSS

Sat, 07 May 2022 01:25:47 +0000

As CSS inches closer to its 30th birthday, it continues to evolve and improve more rapidly than ever. Let’s take a cursory look at some of its newest features being shipped in the near future: cascade layers, subgrids, and container queries.

Cascade layers in CSS

First, here’s a quick background on what exactly we mean by “cascade.”

Styles can come from a few different sources, such as the browser’s defaults or the stylesheets we author as web developers. Some of these sources take precedence over others. Traditionally, we think of the cascade as follows:

User-agent stylesheet (browser defaults)
User settings
Author stylesheets

Styles in the website author’s stylesheets take precedence over the browser defaults. (This is not to be confused with selector specificity, which is resolved within each layer of the cascade.)

What the new cascade layers feature allows us to do as CSS authors is add and control additional layers of the cascade. So, rather than all of a website’s styles being lumped into a single cascade layer, authors can now create multiple cascade layers and control their order of precedence:

User-agent stylesheet (browser defaults)
User settings
Author layer “C”
Author layer “B”
Author layer “A”
Etc.

Before we dive into the syntax of defining cascade layers, let’s look at some use cases and problems you might solve with additional control over the cascade.

Why use cascade layers in CSS?

Cascade layers allow us to circumvent some of the thorniest parts of working in CSS code. In some cases, we will be able to avoid the use of !important because basic, overridable styles can simply be placed in a lower-precedence cascade layer.

For example, you might consider placing typical “reset” styles in their own cascade layer, and styles from a third-party CSS library in another. You could also put utility classes — such as those used by “atomic CSS” approaches like Tailwind CSS — into their own cascade layer to take precedence over common styles without the need for !important.

Another use case could be dividing up an existing design system into different layers to allow for easy theming and customization. It will be interesting to see how modern JavaScript frameworks, which typically ship with workarounds like CSS modules or style encapsulation via emulated shadow DOM, adopt cascade layers to improve their developer and user experiences — although these features might be affected more directly by the @scope proposal, which is different but related.

Syntax

We define cascade layers and the styles that belong in them with the @layer statement. Although not required, you can declare multiple layers upfront (without any styles) to determine their order of precedence, like so:

@layer reset, base, utilities;

This will create three layers called reset, base, and utilities. Styles defined in utilities will take precedence over base styles, which will take precedence over styles in reset.

To add styles to a layer, we define them in a block, like this:

@layer utilities {
  p {
    color: blue;
  }
}

@layer base {
  p {
    color: red;
  }
}

Note that because we declared the layers previously and also defined their order (the initial line: @layer reset, base, utilities;), any paragraphs on our page will be blue, even though the styles for the base layer are defined later. Had we omitted that line, the base layer would take precedence because it does appear later in our stylesheet, and the paragraphs would therefore be red.

It’s also possible to create anonymous layers:

@layer {
  p {
    color: green;
  }
}

Or load external stylesheets into a particular layer:

@import url('utilities.css') layer(utilities);

We can also nest layers within other layers:

@layer outer {
  @layer innerOne {
    /* ... */
  }
}

/* Dot syntax works, too. */
@layer outer.innerTwo {
  /* ... */
}

There are several options and plenty of flexibility!

When can I use cascade layers in CSS?

Pretty soon! At the time of writing, cascade layers have already shipped to most evergreen browsers, with broader support on the way. See resources like caniuse.com for updated browser support information.

One last `!important` note

With the addition of multiple cascade layers, a deeper understanding of how !important works is much more, well, important. For a clear and well-written explanation (including visuals) on the nuances of how !important fits into the cascade and its effect on cascade layers, be sure to check out this article.

Introducing CSS’s `subgrid`

This new feature is much simpler — at least conceptually — than cascade layers, but is certainly still exciting and much anticipated by CSS authors. Currently, grid row and column configurations only extend to the immediate children of a grid container.

Those children can also be grid containers themselves, but to achieve a consistent alignment with the parent grid, they need to carefully configure their columns or rows to match precisely those of the parent. Sometimes that’s difficult or impossible, depending on the grid settings.

With the addition of the subgrid value for grid-template-rows and grid-template-columns, grid children can now inherit the grid row and column settings from the parent and properly position their children seamlessly and effortlessly, without the need to define or keep in sync with their own row and column settings. Nice!

For a more detailed explanation of subgrid, see “Subgrid” on the MDN docs.

When can I use `subgrid`?

At the time of writing, only Firefox implements the new subgrid value, but the other evergreen browsers won’t be far behind.

Mastering container queries in CSS

When browsers shipped support for media queries, the web took a giant step forward in the realm of responsive design. Media queries solved a myriad of problems, but they also exposed a new problem with complicated responsive layouts: context-aware responsiveness.

For example, you might have a component that exists within the main part of your web page and needs to change its layout based on the width of that main section. However, the width of the main section is itself dependent on the width of the browser viewport and is controlled by its own responsive layout settings.

With today’s media queries, the only way to change the layout of your inner component is to do so based on changes to the browser viewport’s width, which means you need to keep its media queries carefully in sync with those of the main section so that your component always looks correct at every viewport size. And, if you ever change your main layout, you’ll need to update your component, too.

Container queries solve this problem by allowing CSS authors to respond to the dimensions of arbitrary elements, not solely those of the viewport. This will decouple components styles from their parent containers, making responsive components vastly easier to maintain — and reduce visual layout bugs!

When can I use container queries?

Unfortunately, the specification is still under active development, and no browsers have yet implemented container queries, as the final syntax is still being refined. However, it’s one of the most widely requested features, so we should see regular progress and big updates on container queries in the near future.

Conclusion

CSS is rapidly evolving to provide better primitives for us web developers and our users. Keep an eye on these top features for your next project!

Extending object-like types with interfaces in TypeScript

Sun, 03 Apr 2022 00:09:22 +0000

Interfaces are one of TypeScript’s core features, allowing developers to flexibly and expressively enforce constraints on their code to reduce bugs and improve code readability. Let’s dive into exploring interfaces’ characteristics and how we might better leverage them in our programs.

What are interfaces?

First, a little background. Interfaces are a way for developers to name a type for later reference in their programs. For example, a public library’s management software might have a Book interface for data representing books in the library’s collection:

interface Book {
  title: string;
  author: string;
  isbn: string;
}

With it, we can ensure that book data in the program contains the essential information of title, author, and ISBN. If it doesn’t, the TypeScript compiler will throw an error:

const tale: Book = {
  title: 'A Tale of Two Cities',
  author: 'Charles Dickens',
  // Error: Property 'isbn' is missing in type '{ title: string; author: string; }' but required in type 'Book'.
};

Interfaces vs. types

If you’ve written TypeScript code before, you might be familiar with type aliases, another common way to name a type, and you might be asking, “Why use interfaces over types or vice versa?”

The primary difference is that interfaces can be reopened for adding additional properties (via declaration merging) in different parts of your program, while type aliases cannot. Let’s look at how to take advantage of declaration merging, as well as some cases of when you might want to.

Expanding interfaces in TypeScript

Option 1: Declaration merging

As noted above, interfaces can be reopened to add new properties and expand the definition of the type. Here is a nonsensical example to illustrate this capability:

interface Stock {
  value: number;
}

interface Stock {
  tickerSymbol: string;
}

Of course, it’s not likely that the same interface would be reopened nearby like this. It would be clearer to simply define it in a single statement:

interface Stock {
  value: number;
  tickerSymbol: string;
}

So, when would you want to expand an interface in different parts of your program? Let’s take a look at a real-world use case.

Declaration merging to wrangle disparate user preferences

Suppose you are writing a React application, and you need some pages that will allow the user to configure information such as their profile, notification preferences, and accessibility settings.

For clarity and user experience, you’ve split up these three concerns into three separate pages where the source code will be in three files: Profile.tsx, Notifications.tsx, and Accessibility.tsx.

From an application architecture perspective, it would be nice if all of the user’s preferences were contained in a single object that adheres to an interface we’ll call Preferences. This way, you can easily load and save the preferences object with your backend API with just one or two endpoints rather than several.

The next question is: “Where should the Preferences interface be defined?” You could put the interface in its own file, preferences.ts, and import it into the three pages — or, you could take advantage of declaration merging and have each page define only the properties of Preferences that it cares about, like so:

// Profile.tsx

interface Preferences {
  avatarUrl: string;
  username: string;
}

const Profile = (props) => {
  // ... UI for managing the user's profile ...
}

// Notifications.tsx

interface Preferences {
  smsEnabled: boolean;
  emailEnabled: boolean;
}

const Notification = (props) => {
  // ... UI for managing the user's notification preferences ...
}

// Accessibility.tsx

interface Preferences {
  highContrastMode: boolean;
}

const Accessibility = (props) => {
  // ... UI for managing the user's accessibility settings ...
}

In the end, the Preferences interface will resolve to fully contain all the properties, as desired:

interface Preferences {
  avatarUrl: string;
  username: string;
  smsEnabled: boolean;
  emailEnabled: boolean;
  highContrastMode: boolean;
}

And the UI code is now co-located with only the properties of Preferences it is responsible for managing, making the program easier to understand and maintain. Nice!

Option 2: Extending interfaces in TypeScript

Another way to expand interfaces in TypeScript is to mix one or more of them into a new interface.

interface Pet {
  name: string;
  age: number;
}

interface Dog extends Pet {
  breed: string;
}

interface Fish extends Pet {
  finColor: string;
}

const betta: Fish = {
  name: 'Sophie',
  age: 2,
  finColor: 'black',
};

This probably looks familiar to object-oriented programmers. However, interfaces offer a key feature that is not typically found in traditional object-oriented programming: multiple inheritance.

Multiple inheritance allows us to combine behaviors and properties of multiple interfaces into a single interface. Let’s look at a use case for when you might want to do this.

Extending interfaces to form a type-safe global state store

Suppose that you’re building an application that enables users to keep track of their to-do lists and their daily schedules in one place. You’ll have some different UI components for tracking each of those tasks:

// todo-list.ts

interface ToDoListItem {
  title: string;
  completedDate: Date | null;
}

interface ToDoList {
  todos: ToDoListItem[];
}

// ... application code for managing to-do lists ...

// calendar.ts

interface CalendarEvent {
  title: string;
  start: Date;
  end: Date;
}

interface Calendar {
  events: CalendarEvent[];
}

// ... application code for managing the calendar ...

Now that you’ve created the basic interfaces for keeping track of your two pieces of state, you would like a single interface that represents the state of the entire application. We can use the extends keyword to create such an interface. We’ll also add a modified field so that we know when our state was last updated:

interface AppState extends ToDoList, Calendar {
  modified: Date;
}

Now you can use the AppState interface to ensure that the application is properly handling the state.

function persist(state: AppState) {
  // ... save the state to a storage layer ...
}

persist({
  todos: [
    { title: 'Text Marcy', completedDate: new Date('2022-02-05') },
    { title: 'Buy groceries', completedDate: null },
  ],
  events: [
    {
      title: 'Study',
      start: new Date('2022-02-11 08:00:00'),
      end: new Date('2022-02-11 10:00:00'),
    },
  ],
  modified: new Date('2022-02-06'),
});

Extending types

While re-opening interfaces is not possible with type aliases, this approach of extending types is, but with some subtle differences in syntax. Here’s the equivalent example adapted to use type instead of interface:

type ToDoListItem = {
  title: string;
  completedDate: Date | null;
}
type ToDoList = {
  todos: ToDoListItem[];
}
type CalendarEvent = {
  title: string;
  start: Date;
  end: Date;
}
type Calendar = {
  events: CalendarEvent[];
}
type AppState = ToDoList & Calendar & {
  modified: Date;
}
function persist(state: AppState) {
  // ... save the state to a storage layer ...
}
persist({
  todos: [
    { title: 'Text Marcy', completedDate: new Date('2022-02-05') },
    { title: 'Buy groceries', completedDate: null },
  ],
  events: [
    {
      title: 'Study',
      start: new Date('2022-02-11 08:00:00'),
      end: new Date('2022-02-11 10:00:00'),
    },
  ],
  modified: new Date('2022-02-06'),
});

Conclusion

There are a few different ways to extend object-like types with interfaces in TypeScript, and, in some cases, you may be able to use type aliases. In those cases, even the official docs say they are mostly interchangeable, at which point it’s down to style, preference, organization, habit, etc. But if you’d like to declare different properties on the same type in different parts of your program, use interfaces.

How to develop over HTTPS on localhost

Fri, 11 Mar 2022 15:16:41 +0000

There are a number of reasons you may wish to use HTTPS as part of your web application development workflow:

Your app will likely be deployed to users via HTTPS; the closer your development environment is to production, the less likely you are to run into bugs.
Browsers behave differently in secure contexts, and you want to avoid production-only surprises.
You might be integrating with third-party services or APIs that require the use of HTTPS.

Keep reading to find out how to set up SSL for local development.

Step 1: Generate a self-signed SSL certificate

Unless you are developing on a remote development environment with a static IP address, you won’t have a unique domain name that points to your development environment (and even if you are, you may not want or need one). Without a unique domain name, our only option for and SSL certificate is a self-signed one for local use only. Use this command to generate one:

tl;dr

Use the command below to generate your self-signed certificate and private key.

openssl req -x509 -out localhost.crt -keyout localhost.key -newkey rsa:2048 -nodes -subj '/CN=localhost' -extensions EXT -config <(printf "[req]\ndistinguished_name = dn\n[dn]\nCN=localhost\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")

Let’s pick that command apart. Feel free to skip to step 2 if you don’t care about the details.

openssl req - We’re using the openssl program to generate our certificate. openssl has many sub-commands; the one we are using is req, which is for generating certificates and certificate requests.
-x509 - Output a self-signed certificate (rather than a certificate signing request that you might send off to a certificate authority—often called a “CA” for short—to be verified and signed for production use).
-out localhost.crt - Write the certificate to a file called localhost.crt.
-keyout localhost.key - Write the private key to a file called localhost.key.
-newkey rsa:2048 - Generate and use a new private key (as opposed to an existing key, which you’d specify with the -key option) of 2048 bits using the RSA algorithm.
-nodes - Do not encrypt the private key.
-subj '/CN=localhost' - Sets the subject of the certificate request. For production certs, this would include information about the company or business seeking the certificate (such as location, department, email address, etc.), but since this is a development-only certificate, the only necessary information is the “common name” (“CN” for short), localhost.
-extensions EXT - Specifies that the extensions section of our config is delineated with a header titled EXT. That config is defined in the next part of the command.
-config <(printf "...") - The -config option takes a file name containing configuration options, but rather than use a separate file we use input redirection (the < character) and a subshell (the command embedded between parentheses, which returns the string config) to pass the config contents directly, for convenience.

The contents of the configuration are shown more readably below:

[req]
distinguished_name = dn
[dn]
CN=localhost
[EXT]
subjectAltName=DNS:localhost
keyUsage=digitalSignature
extendedKeyUsage=serverAuth

[req] - Options for the req subcommand are below this heading.
distinguished_name = dn - Indicates that the distinguished name fields will be found in a section of the config titled dn.
[dn] - The heading for the fields as indicated above.
CN=localhost - The common name (“CN”) for the certificate; in this case: localhost.
[EXT] - The heading for the extensions, as indicated by the -extensions parameter above.
subjectAltName=DNS:localhost - Indicates that the certificate should match the localhost domain name.
keyUsage=digitalSignature - Indicates that the key may be used for signing the certificate.
extendedKeyUsage=serverAuth - Indicate that in addition to signing the certificate, the private key will also be used to identify the server for SSL/TLS.

Step 2: Install and trust the certificate

Now your local operating system needs to know that the certificate is trustworthy. (Otherwise you’ll see a warning when you access https://localhost that the certificate is not trusted. This warning can be bypassed but trusting the certificate at the OS level gives a smoother development experience.)

For macOS, this can be achieved by following these steps:

Open the Keychain Access app.
Drag and drop your localhost.crt file onto the app.
Right click on the new certificate entry and choose “Get Info”.
Expand the “Trust” section of the Get Info dialog.
For “Secure Sockets Layer (SSL)”, choose “Always Trust”.
Close the dialog and input your password (or TouchID) to save the changes.

There should be a similar process for trusting the certificate in Windows and Linux.

If you’re working on a team, write some documentation for your teammates on how to do this (or point them to this article) so that new engineers can get up and running quickly.

Step 3: Configure your development server to use the certificate and private key

Lastly, your development server applications need to be updated to use the certificate and private key. This will be different for each language and framework. Here are some examples:

For Netlify, the netlify dev server can be configured to use your SSL certificate in development by adding the following to your netlify.toml file:

[dev.https]
  certFile = "localhost.crt"
  keyFile = "localhost.key"

For Node.js servers, pass the key and cert options to https.createServer.

Once configured, you should be able to access your development server via HTTPS on localhost!

Additional reading

Mastering mapped types in TypeScript

Fri, 18 Feb 2022 20:17:28 +0000

Mapped types are a handy TypeScript feature that allow authors to keep their types DRY (“Don’t Repeat Yourself”). However, because they tow the line between programming and metaprogramming, they can be difficult to understand at first.

In this post, we’ll cover some foundational concepts that enable mapped types, then walk through an advanced, real-world example.

Why use mapped types in TypeScript?

Using mapped types in a program is especially useful when there is a need for a type to be derived from (and remain in sync with) another type.

// Configuration values for the current user
type AppConfig = {
  username: string;
  layout: string;
};

// Whether or not the user has permission to change configuration values
type AppPermissions = {
  changeUsername: boolean;
  changeLayout: boolean;
};

This example is problematic because there is an implicit relationship between AppConfig and AppPermissions. Whenever a new configuration value is added to AppConfig, there must also be a corresponding boolean value in AppPermissions.

It is better to have the type system manage this relationship than to rely on the discipline of future program editors to make the appropriate updates to both types simultaneously.

We’ll delve into the specifics of the mapped types syntax later on, but here is a preview of the same example using mapped types instead of explicit types:

// Configuration values for the current user
type AppConfig = {
  username: string;
  layout: string;
};

// Whether or not the user has permission to change configuration values
type AppPermissions = {
  [Property in keyof AppConfig as `change${Capitalize<Property>}`]: boolean
};

Foundational concepts of mapped types

Mapped types build upon each of these concepts and TypeScript features.

What is a mapped type?

In a computer science context, the term “map” means to transform one thing into another, or, more commonly, refers to turning similar items into a different list of transformed items. Likely the most familiar application of this idea is Array.prototype.map(), which is used in everyday TypeScript and JavaScript programming:

[1, 2, 3].map(value => value.toString()); // Yields ["1", "2", "3"]

Here we’ve mapped each number in the array to its string representation. So a mapped type in TypeScript means we’re taking one type and transforming it into another type by applying a transformation to each of its properties.

Indexed access types in TypeScript

TypeScript authors can access the type of a property by looking it up by name:

type AppConfig = {
  username: string;
  layout: string;
};

type Username = AppConfig["username"];

In this case, the resolved type of Username is string. For more information on indexed access types, see the official docs.

Index signatures

Index signatures are handy for cases when the actual names of the type’s properties are not known, but the type of data they will reference is known.

type User = {
  name: string;
  preferences: {
    [key: string]: string;
  }
};

const currentUser: User = {
  name: 'Foo Bar',
  preferences: {
    lang: 'en',
  },
};
const currentLang = currentUser.preferences.lang;

In this example, the TypeScript compiler reports that the type of currentLang is string rather than any. This functionality, in conjunction with the keyof operator detailed below, is one of the core components that make mapped types possible. For more information on index signatures, see the official documentation on object types.

Using union types in TypeScript

A union type is a combination of two or more types. It signals to the TypeScript compiler that the type of the underlying value could be any one of the types included in the union. This is a valid TypeScript program:

type StringOrNumberUnion = string | number;

let value: StringOrNumberUnion = 'hello, world!';
value = 100;

Here is a more complicated example that shows some of the advanced protection the compiler can offer with union types:

type Animal = {
  name: string;
  species: string;
};

type Person = {
  name: string;
  age: number;
};

type AnimalOrPerson = Animal | Person;

const value: AnimalOrPerson = loadFromSomewhereElse();

console.log(value.name); // No problem, both Animal and Person have the name property.
console.log(value.age); // Compilation error; value might not have the age property if it is an Animal.

if ('age' in value) {
  console.log(value.age); // No problem, TS knows that value has the age property, and therefore it must be a Person if we're inside this if block.
}

See the docs on everyday types for more information on union types.

Using the `keyof` type operator

The keyof type operator returns a union of the keys of the type passed to it. For example:

type AppConfig = {
  username: string;
  layout: string;
};

type AppConfigKey = keyof AppConfig;

The AppConfigKey type resolves to "username" | "layout". Note that this also works in tandem with index signatures:

type User = {
  name: string;
  preferences: {
    [key: string]: string;
  }
};

type UserPreferenceKey = keyof User["preferences"];

The UserPreferenceKey type resolves to string | number (number because accessing JavaScript object properties by number is valid syntax). Read about the keyof type operator here.

Mapped types: a real-world example

Now that we’ve covered the foundations upon which TypeScript’s mapped types feature is built, let’s walk through a detailed real-world example. Suppose our program keeps track of electronic devices and their manufacturers and prices. We might have a type like this to represent each device:

type Device = {
  manufacturer: string;
  price: number;
};

Now, we’d like to ensure that we have a way to display those devices to the user in a human-readable format, so we’ll add a new type for an object that can format each property of a Device with an appropriate formatting function:

type DeviceFormatter = {
  [Key in keyof Device as `format${Capitalize<Key>}`]: (value: Device[Key]) => string;
};

Let’s pull this code block apart, piece by piece.

Key in keyof Device uses the keyof type operator to generate a union of all keys in Device. Putting it inside of an index signature essentially iterates through all properties of Device and maps them to properties of DeviceFormatter.

format${Capitalize<Key>} is the transformation part of the mapping and uses key remapping and template literal types to change the property name from x to formatX.

(value: Device[Key]) => string; is where we utilize the indexed access type Device[Key] to indicate that the format function’s value parameter is of the type of the property we are formatting. So, formatManufacturer takes a string (the manufacturer) while formatPrice takes a number (the price).

Here’s what the DeviceFormatter type looks like:

type DeviceFormatter = {
  formatManufacturer: (value: string) => string;
  formatPrice: (value: number) => string;
};

Now, let’s suppose we add a third property, releaseYear, to our Device type:

type Device = {
  manufacturer: string;
  price: number;
  releaseYear: number;
}

Thanks to the power of mapped types, the DeviceFormatter type is automatically expanded to look like this without any additional work on our part:

type DeviceFormatter = {
  formatManufacturer: (value: string) => string;
  formatPrice: (value: number) => string;
  formatReleaseYear: (value: number) => string;
};

Any implementations of DeviceFormatter must add the new function or compilation will fail. Voilà!

Bonus: a reusable formatter type with generics

Suppose now that our program not only needs to keep track of electronic devices but also accessories for those devices:

type Accessory = {
  color: string;
  size: number;
};

Again, we want a type for an object that can provide string formatting functions for all the properties of Accessory. We could implement an AccessoryFormatter type, similar to how we implemented DeviceFormatter, but we end up with mostly duplicate code:

type AccessoryFormatter = {
  [Key in keyof Accessory as `format${Capitalize<Key>}`]: (value: Accessory[Key]) => string;
};

The only difference is that we’ve replaced references to the Device type with Accessory. Instead, we can create a generic type that takes Device or Accessory as a type argument and produces the desired mapped type. Traditionally, T is used to represent the type argument.

type Formatter<T> = {
  [Key in keyof T as `format${Capitalize<Key & string>}`]: (value: T[Key]) => string;
}

Note that we have to make one slight change to our property name transformation. Because T could be any type, we don’t know for sure that Key is a string (for example, arrays have number properties), so we take the intersection of the property name and string to satisfy the constraint imposed by Capitalize.

See the TypeScript documentation on generics for more detail on how they work. Now we can replace our bespoke implementations of DeviceFormatter and AccessoryFormatter to use the generic type instead:

type DeviceFormatter = Formatter<Device>;
type AccessoryFormatter = Formatter<Accessory>;

Here is the full final code:

type Device = {
  manufacturer: string;
  price: number;
  releaseYear: number;
};

type Accessory = {
  color: string;
  size: number;
};

type Formatter<T> = {
  [Key in keyof T as `format${Capitalize<Key & string>}`]: (value: T[Key]) => string;
};

type DeviceFormatter = Formatter<Device>;
type AccessoryFormatter = Formatter<Accessory>;

const deviceFormatter: DeviceFormatter = {
  formatManufacturer: (manufacturer) => manufacturer,
  formatPrice: (price) => `$${price.toFixed(2)}`,
  formatReleaseYear: (year) => year.toString(),
};

const accessoryFormatter: AccessoryFormatter = {
  formatColor: (color) => color,
  formatSize: (size) => `${size} inches`,
};

Try this code in the TypeScript playground on typescriptlang.org.

Conclusion

Mapped types provide a powerful way to keep related types in sync automatically. They can also help prevent bugs by keeping types DRY and obviating the need to repetitively type (or copy and paste) similar property names.

Happy typing!

How to set up a simple web server development container for VS Code

Wed, 26 Jan 2022 16:18:46 +0000

Sometimes it’s nice to have a lightweight development container that automatically serves the contents of a directory, for rapid prototyping or building static web pages—without having to setup a tool chain on your local environment or install web server software (and its dependencies) on your local machine.

If you’re using VS Code’s extension for developing inside containers, below is a recipe for a comfortable development setup containing these three main attributes:

Lightweight; small image footprint and minimal container boot up time
Automatic; once the container starts, the files are being served on a local port without the need to run another command
Complete; has all the dependencies required by VS Code for the full development lifecycle

To achieve this, we’ll use the Alpine Linux operating system with Nginx as our development web server.

Step 1: define development container in a Dockerfile

We’ll include the dependencies required by VS Code’s remote containers extension as well as the specific tools we need for development.

.devcontainer/Dockerfile:

# We'll base our dev container image on Alpine Linux.
FROM alpine:3.15

# Then we'll add the dependencies we need:
# - musl, libgcc, and libstdc++ are required by VS Code's server
# - git and gnupg are useful for remote development so that we
#   can commit and sign commits from within the container
# - and of course nginx itself
RUN apk add \
  musl \
  libgcc \
  libstdc++ \
  git \
  gnupg \
  nginx

# Finally, we'll remove nginx's default content and replace it
# with a symlink to our source code.

RUN rm -rf /usr/share/nginx/html
RUN ln -s /workspaces/my-app /usr/share/nginx/html

Heads up

You'll want to replace /workspaces/my-app with whatever directory VS Code mounts your source code to inside the container.

Step 2: configure VS Code to utilize our image

With our image definition done, we’ll add some configuration to instruct VS Code to run it.

.devcontainer/devcontainer.json:

{
  "name": "my-app",
  // Tell VS Code to build our dev container from our Dockerfile.
  "build": {
    "dockerfile": "./Dockerfile"
  },
  // Automatically expose port 8080 (mapped to container's port 80, nginx's default) for development
  "appPort": "8080:80",
  // Make sure our nginx container's default command runs, which starts up the web server in the background.
  "overrideCommand": false
}

Step 3: profit

With those files in place, VS Code has everything it needs to spin up the development container with the source code mounted inside. Once it’s running, you can load up your project’s files in the browser (or even try VS Code’s built-in development browser) on port 8080 for easy side-by-side development:

Happy prototyping!

Using tsm as a shebang interpreter in TypeScript

Mon, 24 Jan 2022 14:52:48 +0000

Using tsm as a shebang interpreter in TypeScript

TypeScript has taken the web development world by storm, becoming increasingly popular for enterprise projects and solo developers alike.

Executing TypeScript code typically involves transpiling it down to vanilla JavaScript for use in common environments like Node.js or the browser. This approach still represents the vast majority of how TypeScript programs are run, but a few projects have emerged that allow developers to run their TypeScript code directly.

tsm is a brand new player in this category and represents a step forward in the broader TypeScript/JavaScript ecosystem.

What is tsm?

tsm is a TypeScript module loader for Node.js, created by Luke Edwards. It expands Node.js to provide native TypeScript support without the need to transpile it to JavaScript first.

Rather, tsm uses esbuild under the hood to quickly transpile TypeScript sources into JavaScript on the fly before passing it to the Node.js runtime. This approach essentially abstracts away the typical transpilation step, making it transparent to the user.

Should you use tsm?

The primary and most obvious advantage to using tsm is that developers don’t need to worry about TypeScript transpilation. This means that development feedback loops are shorter, build tooling is simpler, and deployment is more straightforward. This is particularly convenient for small projects like one-off scripts.

Because tsm runs on top of Node.js, developers familiar with Node will find using tsm natural and easy to incorporate TypeScript into their projects with a simple step.

For example, esbuild has built-in source map support, which means that TypeScript programs that run under tsm can be debugged with the standard V8 debugging protocol (included with Node.js) and popular debugging tools like VS Code.

Additionally, the vast ecosystem of npm packages and Node built-in APIs are available to TypeScript running with tsm.

The disadvantages to tsm

One relatively small trade-off of using tsm is that it must be installed, in addition to Node.js itself, on the system that needs to run the TypeScript code.

This can be an inconvenience if distributing scripts meant to be run directly from the shell (like when using tsm as the interpreter for a script via shebang interpreter directive), but not a problem for fully packaged Node.js modules.

Other than that, there aren’t too many downsides to giving tsm a try, assuming there’s an appetite for new and emerging (and therefore, potentially changing) tech.

Unlike other elements of a project’s technology stack (such as databases, programming languages, frameworks, etc.), the nice thing about JavaScript build tools is that they can be swapped out later with minimal impact on the application’s source code itself.

Using tsm

There are a few different ways to hook tsm into a Node.js project.

1. As a replacement for the `node` executable

Assuming you have tsm installed globally (via npm --global install tsm or yarn global add tsm), you can run TypeScript files using the tsm executable, like so:

tsm index.ts

For local installations, the tsm executable can be found at ./node_modules/.bin/tsm.

Note that any command-line flags will be passed through to node, which is convenient for experimental features, debugging configuration, and the like.

2. With a shebang interpreter directive

Because tsm includes an executable, it can be used in a shebang directive like any other script interpreter. Shebang directives are formatted as such: !#<path/to/interpreter> [arguments].

They appear at the first line of the file and tell the operating system which program to use to parse and execute the rest of the file.

For example:

#!/usr/local/bin/tsm

function print(message: string): void {
  console.log(message);
}

print('hello from TypeScript!');

3. Using the `--require` or `--loader` hooks

If you still need to use node directly rather than the tsm executable, you can use the --require or --loader hooks to instruct node to use tsm to load TypeScript files. tsm needs to be installed as a local dependency (rather than globally) for this to work.

node --require tsm index.ts

node --loader tsm index.ts

Deno: An alternative to tsm

tsm isn’t the only way to achieve transpilation-less executable TypeScript. Ryan Dahl, the creator of Node.js, has released a project called Deno that ships with TypeScript support out of the box.

Like Node.js, Deno is built on top of the V8 JavaScript engine and seeks to overcome some of Node.js’s design flaws.

Like Node.js and tsm, Deno can be used directly as an executable:

deno index.ts

It can also be used in a shebang directive:

!#/usr/local/bin/deno

...

However, code written for Node.js in TypeScript may not be portable to Deno, as Deno provides its own standard library as a replacement for the Node.js APIs. It also has its own paradigm for distributing modules rather than utilizing npm. Check out Deno’s standard library and API docs for more details.

Conclusion

tsm is a great way to integrate TypeScript into a Node.js project quickly and seamlessly. Because it’s built upon Node.js, tsm users can leverage the vast ecosystem of packages in npm and the powerful Node.js APIs, all from within TypeScript without needing to set up a complicated build process.

Check out tsm’s GitHub repo and its dependents list to see what people are using it for. Some notable examples include:

create-figma-plugin: a comprehensive toolkit for developing plugins and widgets for Figma and FigJam. It is written in TypeScript and uses tsm for its development process
tinyhttp: a modern web framework written in TypeScript. It uses tsm in its documentation examples as a simple way to get users up and running quickly
nanostores: a tiny state manager for JavaScript projects. tsm is used in the development cycle for this module

In short, use tsm when you want to leverage Node.js’ vast ecosystem from within TypeScript or integrate TypeScript into an existing Node codebase. If you don’t have many npm-only dependencies and want to enjoy the benefits of Deno’s security model, consider using Deno for your next server-side TypeScript project.

Happy coding!

Using SVG vs. Canvas: A short guide

Mon, 31 May 2021 12:21:29 +0000

So, you need to add some charts to your app or site? By now you’ve figured out that there are many different ways to accomplish this, most of which utilize one of two primary technologies: SVG and the Canvas API.

In order to decide which will best fit your needs, we need to look at SVG’s and Canvas’ relative strengths and weaknesses and how those play into the different chart-drawing solutions available.

Canvas and SVG are both technologies that allow web developers to draw images onto the screen, but they have very different APIs and approaches to doing so.

What is SVG?

SVG stands for “scalable vector graphics” and represents a body of standards for declaratively defining the properties of an image (things like the shapes themselves, fill color, stroke color, and the like).

<svg width="100" height="100" xmlns="http://www.w3.org/2000/svg">
  <circle cx="50" cy="50" r="45" fill="#FFA69E" />
</svg>

SVG images are created either inline with HTML code by adding an <svg> tag, or can be defined in separate files (with the .svg extension) and referenced in the HTML.

What is Canvas?

Canvas is a lower-level browser standard API that allows developers to imperatively “draw” directly onto the image by issuing a series of commands:

const canvas = document.querySelector('canvas');
const ctx = canvas.getContext('2d');
ctx.fillStyle = '#FFA69E';
ctx.arc(50, 50, 45, 0, 2 * Math.PI);
ctx.fill();

Canvas images are created by adding a <canvas> element to the HTML and then manipulating that element via the JavaScript DOM API as shown above.

SVG vs. Canvas: API differences

Because Canvas is a lower level API than SVG, it offers more flexibility than SVG in exchange for greater complexity. The limit of what can be drawn on a Canvas is only limited by how much code a developer is willing to write. Any SVG image can be drawn with the Canvas API with enough effort.

Conversely, because SVG is a higher level API compared to Canvas, it can create complex images without requiring developers to write complicated code.

In this example, we apply lighting and blur effects to a couple of polygons in just 15 lines of SVG code. The corresponding Canvas code would be much more complex to produce the same image:

<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">
  <defs>
    <filter id="point-light">
      <feSpecularLighting result="light" specularConstant="1" specularExponent="150" lighting-color="#DDFFF7">
        <fePointLight x="100" y="100" z="200"/>
      </feSpecularLighting>
      <feComposite in="SourceGraphic" in2="light" operator="lighter" />
    </filter>
    <filter id="blur">
      <feGaussianBlur in="SourceGraphic" stdDeviation="3" />
    </filter>
  </defs>
  <polygon points="190,10 10,55 10,190" fill="#AA4465" filter="url(#point-light)"/>
  <polygon points="10,10 190,100 100,190 100,10" fill="#FFA69E" filter="url(#blur)" />
</svg>

However, because Canvas offers more flexibility, not every image that can be drawn on a Canvas can be precisely expressed with SVG syntax (short of using tiny SVG <rect> elements as “pixels”).

This image would be somewhat more difficult to produce using SVG:

const canvas = document.querySelector('canvas');
const ctx = canvas.getContext('2d');
function mix(channel1, channel2, proportion, variability) {
  const scaledVariability = variability * 0xFF;
  return channel1 * (1 - proportion) +
    channel2 * proportion -
    scaledVariability / 2 +
    scaledVariability * Math.random();
}
const color1 = {
  r: 0xAA,
  g: 0x44,
  b: 0x65,
};
const color2 = {
  r: 0x86,
  g: 0x16,
  b: 0x57,
};
const variability = 0.2;
for (x = 0; x < Canvas.width; x++) {
  for (y = 0; y < Canvas.height; y++) {
    const proportion = x / (Canvas.width - 1) +
      y / (Canvas.height - 1) / 2;
    const color = {
      r: mix(color1.r, color2.r, proportion, variability),
      g: mix(color1.g, color2.g, proportion, variability),
      b: mix(color1.b, color2.b, proportion, variability),
      a: (0.9 + Math.random() / 10).toFixed(2),
    };
    ctx.fillStyle = `rgba(${color.r}, ${color.g}, ${color.b}, ${color.a})`;
    ctx.fillRect(x, y, 1, 1);
  }
}

Important implications to consider when using SVG vs. Canvas

The fundamental differences in API between SVG and Canvas outlined above have downstream effects that you should consider, such as the following.

SVG elements can exist in the DOM alongside the HTML markup

This means that SVG DOM elements can be manipulated in ways that are familiar to web developers, including being integrated into popular frameworks like React or Vue.

One downside of this is that complex SVG charts containing tens of thousands of nodes, for example, could prove to be too resource-intensive for browsers to render efficiently, leading to sluggish or janky web pages. This is because Canvas operations are committed directly to the screen, so the number of drawing operations is less impactful to performance in that there is no overhead of keeping track of these operations in the DOM.

As with HTML, SVG is declarative

This means that the browser takes care of translating the desired image into the low-level imperative code for drawing pixels onto the screen — the developer doesn’t have to worry about that. Complex images can be succinctly represented in SVG syntax.

SVG images can be responsive, and Canvas images are not

SVGs can grow and shrink in response to parent container sizes or screen size changes, whereas Canvas elements need custom JavaScript to achieve this behavior.

SVG vs. Canvas: Which is better for you?

With the differences between SVG and Canvas in mind, we can evaluate the needs of our chart project and determine which technology might better serve us. It’s worth asking the following:

Will the charts have many elements or be highly detailed? Canvas may perform better for showing this data without bogging down the browser with many DOM nodes. But if the charts are relatively simple, the SVG syntax may be a simpler and quicker solution to getting a nice-looking chart out the door quickly.
Do your charts need to have several animations or be responsive in width? While it’s certainly possible to render animations using Canvas or to make Canvas elements respond to width changes, it may be more straightforward to achieve these effects using SVG and CSS.
Do the charts need to be interactive? Because SVG elements are in the DOM, responding to user actions like clicks on particular elements of a chart is as simple as responding to events on any other DOM element. Canvas interactivity is possible but will require some additional code.

Charting libraries

Because rendering data visualizations is such a common use case for websites and applications, there are a plethora of libraries that make drawing charts with Canvas or SVG easy. A quick DuckDuckGo search of “JavaScript chart libraries” will bring up dozens of pages outlining many of the different options available.

Some popular options offer great-looking charts out of the box, such as Chart.js or Chartist. Others are more complex but allow for more customization, like Vega-Lite. Many libraries are built upon the de-facto library for data visualization on the web, D3.js, which offers complete flexibility and control at the expense of a steep learning curve.

Rendering charts on the backend

Creating charts with SVG and Canvas isn’t limited to browser contexts; they can be rendered in server applications as well.

For SVG, a tool like Puppeteer can be used to render SVG images in a headless Chrome browser and generate screenshots as desired. For Canvas, there is a fantastic library called Canvas that provides a near-complete implementation of the standard Canvas API for Node.js.

An example of a backend Canvas rendering

This JavaScript snippet encodes a secret message. To see what it is, save this code in a file called index.js:

const { join } = require('path'),
  { createWriteStream } = require('fs'),
  { createCanvas } = require('canvas');

const canvas = createCanvas(200, 100);
const ctx = canvas.getContext('2d');

ctx.strokeStyle = '#861657';
ctx.lineWidth = 5;
ctx.lineCap = 'round';
ctx.beginPath();
ctx.moveTo(40, 25);
ctx.lineTo(40, 75);
ctx.moveTo(40, 50);
ctx.lineTo(100, 50);
ctx.moveTo(100, 25);
ctx.lineTo(100, 75);
ctx.moveTo(160, 25);
ctx.lineTo(160, 75);
ctx.stroke();

const path = join(__dirname, 'message.png');
const out = createWriteStream(path);
const stream = Canvas.createPNGStream();
stream.pipe(out);
out.on('finish', () => console.log(`Image file created at ${path}.`));

Then save a file called package.json right next to index.js with the following content:

{
  "private": true,
  "dependencies": {
    "canvas": "^2.7.0"
  }
}

From the same directory where you saved index.js and package.json, run the following command (Node.js must installed available on your PATH):

npm install
node index.js

If everything went according to plan, your headlessly generated PNG image with secret message will be saved to message.png. 👋

Conclusion

SVG and Canvas are both powerful and mature technologies, each with a strong ecosystem of libraries and documentation to help bring your charts to life. And some libraries even support rendering to both SVG or Canvas!

Don’t be afraid to invest some time in evaluating alternatives to find the right solution for your specific project’s needs. Here are some quick rules of thumb when it comes to deciding on SVG or Canvas.

Do your charts need to be responsive or interactive? SVG may offer these features more simply than Canvas.
Will your charts be highly detailed or complex? Canvas may offer better performance and greater control than SVG.

Good luck!

What's new in TypeScript 4.2?

Fri, 07 May 2021 12:09:43 +0000

Version 4.2 of TypeScript was released on 23 February, 2021, and with it a number of nice features, bug fixes, and performance improvements. Here are the most important ones you should be aware of.

TypeScript 4.2’s top enhancements

More flexible rest elements in tuple types

Previous to 4.2, rest elements could only appear at the end of the tuple type. If we were modeling the state of a two-player game, for example, we might use this tuple type to hold our two Players and a list of the Moves they’ve played:

let gameState: [Player, Player, ...Move[]];

With 4.2, the Moves don’t have to be at the end of the type; they could be in the middle or even at the beginning. If desired, we can now expand our type as follows, to include which player’s turn it is. For additional clarity, we’ll take advantage of TypeScript’s support for labeled tuple elements (which is not new in 4.2):

let gameState: [player1: Player, player2: Player, ...moves: Move[], currentTurn: number];

Increased visibility into which files are included in your compiled program

TypeScript’s compiler (tsc) now includes a new flag, --explainFiles, that outputs a list of files included in the compilation as well as basic reasoning behind why they’re there, in a simple text format. This can be very helpful when developing or fine-tuning compiler configuration in tsconfig.json.

This feature is a nice first step toward debugging build time issues, and I expect to grow more robust and powerful in future releases (for example, a JSON output format for ingestion into other tools for more advanced analysis).

Given a default TypeScript config and an index.ts file with a simple console.log('hello, world!');, here is some example output from the --explainFiles flag:

node_modules/typescript/lib/lib.d.ts
  Default library
node_modules/typescript/lib/lib.es5.d.ts
  Library referenced via 'es5' from file 'node_modules/typescript/lib/lib.d.ts'
node_modules/typescript/lib/lib.dom.d.ts
  Library referenced via 'dom' from file 'node_modules/typescript/lib/lib.d.ts'
node_modules/typescript/lib/lib.webworker.importscripts.d.ts
  Library referenced via 'webworker.importscripts' from file 'node_modules/typescript/lib/lib.d.ts'
node_modules/typescript/lib/lib.scripthost.d.ts
  Library referenced via 'scripthost' from file 'node_modules/typescript/lib/lib.d.ts'
index.ts
  Root file specified for compilation

Try it yourself using this example repository (complete with devcontainer.json) on GitHub.

Better support for unused destructured variables

When destructuring tuples or arrays, there are times when the elements you are interested in don’t appear at the beginning of the list. In these cases, “throwaway” variable names such as _ or a, b, c, etc., are used for the elements of no interest.

With the noUnusedLocals compiler option on, however, these unused local variables would cause TypeScript to throw an error until version 4.2.

Now, simply prepend the unused variable names with _ and TypeScript will happily ignore these variables and will not throw an error if they are unused. As an example, this new feature would be particularly useful when extracting bits of data from the rows of a CSV spreadsheet:

function* getCsvRows(): Generator<string[], void, void> { /* ... */ }

for (const row of getCsvRows()) {
  // Destructure row, utilizing only the 1st, 4th, and 6th columns.
  const [id, _1, _2, name, _3, country] = row;
  // ... do something with id, name, and country
}

Prefixing unused variable names with _ is a common convention in situations like these; this is an example of tool authors building thoughtfully around and supporting the existing behavior of their users.

Smarter type system and performance improvements

As with any TypeScript release, there were also a number of smaller enhancements that are not groundbreaking on their own but they make TypeScript incrementally better and more comfortable to use. To name just a few:

A helpful error when trying to use the in operator on a primitive type. This is normally a runtime error (in JavaScript) but is now caught at compile time in TypeScript
An internal limit on tuple size in conjunction with the spread syntax, to improve compilation performance
Better parsing and interpretation of vanilla JavaScript files
A new flag called --noPropertyAccessFromIndexSignature that can help reduce errors from object property name misspellings under certain situations

More details and resources

A full list of all the enhancements can be seen on the TypeScript project’s releases page on GitHub, as well as the release announcement on the TypeScript blog. Those are the top highlights of the TypeScript 4.2 release. To dive deeper in to the changes or learn more about TypeScript generally, check out the following resources:

The case for using frameworks

Fri, 30 Apr 2021 11:58:08 +0000

Complaints against the complexity of modern web development tooling setups have been ever increasing in recent years as the web platform continues to evolve and innovate. A recent iteration of this movement toward simplicity is called the “stackless” (or “framework-less”) approach, coined by Daniel Keyhoe of yax.com.

The core tenets of the stackless approach are:

Lean into natively supported features and standards of the web platform
Avoid build tooling and frameworks by using CDN-served npm packages instead
Use web components

The core sentiment of utilizing standards is an admirable one, and indeed it may suffice for very small projects or prototypes, but here are some reasons why this approach is infeasible in practice for professional web development or projects of material size.

Frameworks will never go away

Frameworks play a critical role in the frontend ecosystem. As the web platform advances, so do the frameworks that build on top of it. They serve as a critical space to innovate and inform the future direction of the web standards.

Frameworks are built to overcome the deficiencies of the standard features until new standard features are introduced to fill the gaps. They can move faster than standards do, and can experiment with features to fine-tune and validate them before they get proposed and adopted by the platform. An example of this was the revolutionary jQuery function (commonly called $) in the 2000s and 2010s that directly informed what we know today as document.querySelectorAll.

Stackless has too many limitations

To Keyhoe’s credit, the limitations of the stackless approach are clearly acknowledged in the introductory tutorials. Unfortunately, they are prohibitively severe for many types of modern web development projects.

Data persistence is ignored

Perhaps the largest omission in the stackless approach is that it doesn’t account for data persistence. The approach talks about abandoning Rails for standards-based JavaScript, HTML, and CSS, but Rails solves a different problem than the frontend browser technologies.

What about an API to hide sensitive or proprietary business logic from the frontend? What about centralized state persistence? What about user authentication? There are so many common problems and paradigms that the stackless approach simply doesn’t account for.

Using “functions” (meaning serverless or Lambda functions) is mentioned in passing, but if you are using serverless functions backed by a database or other storage, all of a sudden you have a “stack” again.

CSS is too low-level to author maintainability without a framework

CSS is powerful and chock full of features, but in favor of flexibility, it lacks adequate constraints to guide engineers toward solutions that are maintainable or easy for team members to contribute to.

Even with powerful tools like CSS preprocessors, the topic of keeping CSS under control and well-documented is a common point of discussion for software teams. Even the stackless approach recommends using a CSS framework in the fine print. This is akin to titling an article “How to tour America on foot,” and then in the body paragraph write, “Until we figure out a way to walk faster, just use a car.”

State management is unaccounted for

Web components are ill-equipped to manage the complex state required to build an advanced frontend application. The stackless approach can work for simple informational sites, but for applications with complex user interfaces, the state management becomes unwieldy without the help of a framework or state management library.

This is the second time the answer to “how to build an app without a framework” is “actually, just use a framework.” There are very few classes of applications that are both useful and don’t require the management of complex state.

Complexity is not addressed

The core problem with the stackless approach is that it tries to abandon complexity without a proposal on where that complexity should go. Complexity, in general, cannot be eliminated — it can only be pushed around to different parts of the system. Here are a few examples:

Hypermedia APIs vs bespoke RESTful APIs

Hypermedia APIs return the relevant data for the resource, along with links to related API resources that the client must subsequently request. The complexity of assembling the full picture is pushed to the client.

A bespoke API, on the other hand, may handle the complexity of gathering all of the relevant data before returning it to the client in a single, neat package. The complexity of assembling the requisite data can be moved around but not eliminated.

`create-react-app` and `react-scripts`

The Facebook team behind React has tried to abstract away the complexity of maintaining webpack and other configuration to bootstrap a React application as quickly as possible. This allows engineers to create fully functional React application without having to worry about installing and configuring all the tooling; they only have to install the react-scripts package.

The build tool complexity didn’t go away, its burden just moved into the application’s dependencies rather than on the shoulders of the engineer building the application.

Redeeming qualities of the stackless way

Though using the stackless approach may not be feasible for projects larger than hobbies or prototypes, there are some excellent points in its philosophy that can benefit software projects regardless of which approach they use.

“Users are the users.” The focus on users’ needs, where the definition of users is literally the end users of the software, is a critical point that developers should stay as close to as possible. It is only by keeping the users in mind that applications can be designed empathetically and with critical attributes such as performance and progressive enhancement at the forefront.
“Stick to standards.” One of the best features of the web is that it moves forward on open standards and an unfailing spirit of backward compatibility. Framework authors and framework users alike should embrace and utilize standard features as much as possible (without being afraid to use non-standard technology such as frameworks when it enables them to build better software more quickly).
“Embrace simplicity where possible.” The idea of using the best and simplest tool for the job is pervasive in the stackless approach, and indeed, is part of the core DNA of the web. It’s easy for engineers to fall into the trap of “over-engineering” solutions to problems that end up just creating more problems themselves; it takes discipline and the wisdom of experience to avoid this trap.

Use stackless where it makes sense

Like any other tool, the stackless approach can be useful philosophy when approaching a problem. If you need to build a simple app where the features of the raw web platform will suffice, go for it.

Using the least powerful technology capable of accomplishing the task or solving the problem is an excellent way to build solutions.

But when working on a team, or on a project with even moderate complexity, leveraging modern frameworks will likely yield dividends throughout the life of the project.

How polymorphic JavaScript functions affect performance

Tue, 30 Mar 2021 13:32:23 +0000

As with any conversation about performance, we need to gain some shared context around the type of JavaScript code we want to optimize and the context in which it will run. So, let’s start with some definitions:

Performance. First of all, when we use the word performance in the context of a computer program, we are referring to how quickly or efficiently that program can execute.

Polymorphic functions. A polymorphic function is a function that changes its behavior based on the types of arguments that are passed to it.

The key word here is types, as opposed to values. (A function that didn’t change its output based on different values for arguments would not be a very useful function at all.)

JavaScript engine. In order to think about performance productively, we also need to know where our JavaScript is going to be executed. For our example code, we’ll use the V8 engine given its popularity.

V8 is the engine that powers the Chrome browser, Node.js, the Edge browser, and more. Note that there are also other JavaScript engines with their own performance characteristics, such as SpiderMonkey (used by Firefox), JavaScriptCore (used by Safari), and others.

Creating a polymorphic function in JavaScript

Suppose we are building a JavaScript library that enables other engineers to easily store messages to an in-memory database with our simple API. In order to make our library as easy and comfortable to use as possible, we provide a single polymorphic function that is very flexible with the arguments that it receives.

Option 1: Use completely separate arguments

The first signature of our function will take the required data as three separate arguments, and can be called like this:

saveMessage(author, contents, timestamp);

Option 2: Use message contents with `options` object

This signature will allow consumers to separate the required data (message contents) from the optional data (the author and the timestamp) into two separate arguments. We’ll accept the arguments in any order, for convenience.

saveMessage(contents, options);
saveMessage(options, contents);

Option 3: Use an `options` object

We’ll also allow users of our API to call the function passing in a single argument of an object containing all of the data we need:

saveMessage(options);

Option 4: Use only the message contents

Finally, we’ll allow users of our API to provide only the message contents, and we’ll provide default values for the rest of the data:

saveMessage(contents);

Implementing a polymorphic function

OK, with our API defined, we can build the implementation of our polymorphic function.

// We'll utilize an array for a simple in-memory database.
const database = [];

function saveMessage(...args) {
  // Once we get our input into a unified format, we'll use this function to
  // store it on our database and calculate an identifier that represents the
  // data.
  function save(record) {
    database.push(record);
    let result = '';
    for (let i = 0; i < 5_000; i += 1) {
      result += record.author + record.contents;
    }
    return result.length;
  }
  // If the developer has passed us all the data individually, we'll package
  // it up into an object and store it in the database.
  if (args.length === 3) {
    const [author, contents, timestamp] = args;
    return save({author, contents, timestamp});
  }
  // Or, if the developer has provided a message string and an options object,
  // we'll figure out which order they came in and then save appropriately.
  if (args.length === 2) {
    if (typeof args[0] === 'string') {
      const [contents, options] = args;
      const record = {author: options.author, contents, timestamp: options.timestamp};
      return save(record);
    } else {
      const [options, contents] = args;
      const record = {author: options.author, contents, timestamp: options.timestamp};
      return save(record);
    }
  }
  // Otherwise, we've either gotten a string message or a complete set of
  // options.
  if (args.length === 1) {
    const [arg] = args;
    if (typeof arg === 'string') {
      // If the single argument is the string message, save it to the database
      // with some default values for author and timestamp.
      const record = {
        author: 'Anonymous',
        contents: arg,
        timestamp: new Date(),
      };
      return save(record);
    } else {
      // Otherwise, just save the options object in the database as-is.
      return save(arg);
    }
  }
}

OK, now we’ll write some code that stores a lot of messages using our function — taking advantage of its polymorphic API — and measure its performance.

const { performance } = require('perf_hooks');

const start = performance.now();
for (let i = 0; i < 5_000; i++) {
  saveMessage(
    'Batman',
    'Why do we fall? So we can learn to pick ourselves back up.',
    new Date(),
  );
  saveMessage(
    'Life doesn\'t give us purpose. We give life purpose.',
    {
      author: 'The Flash',
      timestamp: new Date(),
    },
  );
  saveMessage(
    'No matter how bad things get, something good is out there, over the horizon.',
    {},
  );
  saveMessage(
    {
      author: 'Uncle Ben',
      timestamp: new Date(),
    },
    'With great power comes great responsibility.',
  );
  saveMessage({
    author: 'Ms. Marvel',
    contents: 'When you decide not to be afraid, you can find friends in super unexpected places.',
    timestamp: new Date(),
  });
  saveMessage(
    'Better late than never, but never late is better.'
  );
}
console.log(`Inserted ${database.length} records into the database.`);
console.log(`Duration: ${(performance.now() - start).toFixed(2)} milliseconds`);

Now let’s implement our function again but with a simpler, monomorphic API.

Creating a monomorphic function in JavaScript

In exchange for a more restrictive API, we can trim down the complexity of our function and make it monomorphic, meaning that the arguments of the function are always of the same type and in the same order.

Although it won’t be as flexible, we can keep some of the ergonomics of the previous implementation by utilizing default arguments. Our new function will look like this:

// We'll again utilize an array for a simple in-memory database.
const database = [];

// Rather than a generic list of arguments, we'll take the message contents and
// optionally the author and timestamp.
function saveMessage(contents, author = 'Anonymous', timestamp = new Date()) {
  // First we'll save our record into our database array.
  database.push({author, contents, timestamp});
  // As before, we'll calculate and return an identifier that represents the
  // data, but we'll inline the contents of the function since there's no need
  // to re-use it.
  let result = '';
  for (let i = 0; i < 5_000; i += 1) {
    result += author + contents;
  }
  return result.length;
}

We’ll update the performance measuring code from our previous example to use our new unified API.

const { performance } = require('perf_hooks');

const start = performance.now();
for (let i = 0; i < 5_000; i++) {
  saveMessage(
    'Why do we fall? So we can learn to pick ourselves back up.',
    'Batman',
    new Date(),
  );
  saveMessage(
    'Life doesn\'t give us purpose. We give life purpose.',
    'The Flash',
    new Date(),
  );
  saveMessage(
    'No matter how bad things get, something good is out there, over the horizon.',
  );
  saveMessage(
    'With great power comes great responsibility.',
    'Uncle Ben',
    new Date(),
  );
  saveMessage(
    'When you decide not to be afraid, you can find friends in super unexpected places.',
    'Ms. Marvel',
    new Date(),
  );
  saveMessage(
    'Better late than never, but never late is better.'
  );
}
console.log(`Inserted ${database.length} records into the database.`);
console.log(`Duration: ${(performance.now() - start).toFixed(2)} milliseconds`);

Results

OK, now let’s run our programs and compare the results.

$ node polymorphic.js
Inserted 30000 records into the database.
Duration: 6565.41 milliseconds

$ node monomorphic.js
Inserted 30000 records into the database.
Duration: 2955.01 milliseconds

The monomorphic version of our function is about twice as fast as the polymorphic version, as there is less code to execute in the monomorphic version. But because the types and shapes of the arguments in the polymorphic version vary widely, V8 has a more difficult time making optimizations to our code.

In simple terms, when V8 can identify (a) that we call a function frequently, and (b) that the function gets called with the same types of arguments, V8 can create “shortcuts” for things like object property lookups, arithmetic, string operations, and more.

For a deeper look at how these “shortcuts” work I would recommend this article: What’s up with monomorphism? by Vyacheslav Egorov.

Pros and cons of polymorphic vs monomorphic functions

Before you go off optimizing all of your code to be monomorphic, there are a few important points to consider first:

Polymorphic function calls are not likely to be your performance bottleneck. There are many other types of operations that contribute much more commonly to performance problems, like latent network calls, moving large amounts of data around in memory, disk i/o, complex database queries, to name just a few.

You will only run into performance issues with polymorphic functions if those functions are very, very “hot” (frequently run). Only highly specialized applications, similar to our contrived examples above, will benefit from optimization at this level. If you have a polymorphic function that runs only a few times, there will be no benefit from rewriting it to be monomorphic.

You will have more luck updating your code to be efficient rather than trying to optimize for the JavaScript engine. In most cases, applying good software design principles and paying attention to the complexity of your code will take you further than focusing on the underlying runtime. Also, V8 and other engines are constantly getting faster, so some performance optimizations that work today may become irrelevant in a future version of the engine.

Conclusion

Polymorphic APIs can be convenient to use due to their flexibility. In certain situations, they can be more expensive to execute, as JavaScript engines cannot optimize them as aggressively as simpler, monomorphic functions.

In many cases, however, the difference will be insignificant. API patterns should be based on other factors like legibility, consistency, and maintainability because performance issues are more likely to crop up in other areas anyway. Happy coding!

Creating compound components in React and Angular

Mon, 15 Mar 2021 13:23:09 +0000

Creating compound components in React and Angular

There’s no question that components are a powerful abstraction for authoring frontend user interfaces (and, it turns out, text-based UIs, application routers, and many other types of interfaces).

But there are many different approaches to authoring components. In this post, we’ll talk about the compound component pattern and when it may be an appropriate choice for component authors.

What are compound components?

Compound components are groups of individual components that come together to create a cohesive and complex behavior. They work together, sharing state behind the scenes, to offer an intuitive and expressive syntax for the programmer who is using the components. One of the most familiar examples of compound components comes from vanilla HTML:

<select>
  <option value="apples">Apples</option>
  <option value="oranges">Oranges</option>
  <option value="pears">Pears</option>
</select>

In this example, the <select> and <option> elements come together to form a complex input control that is familiar for many users. The <select> maintains its own internal state for which <option> is currently selected by the user and provides advanced behaviors like keyboard input to change the selected <option>.

How to implement compound components

First, make sure a compound component is the appropriate API design. Like any programming paradigm, compound components come with their fair share of tradeoffs. Generally, any pattern where there is implicit shared state — or behavior that is “magical” or not easily discoverable — can cause headaches down the road if not designed with utmost care.

Some questions to ask yourself before designing a compound component are:

Does the programmer using the component really need to compose two (or more) components together to achieve the desired result? Or can the same result be achieved with a simpler single-component design and appropriate inputs or props?
Will the interactions and roles between the components be clear and intuitive to programmers using them?

Carefully consider various APIs for your new component and consult with colleagues on which API they would prefer to consume.

Here are some examples of common UI paradigms that lend well to the compound component pattern:

An advanced table component that allows users of the component to provide not only the tabular data but also custom sorting or filtering behavior
A searchable dropdown component where users of the component will be providing the options

Compound component architecture in React

To implement our example compound components in React, we will be leveraging a number of React APIs, so a foundational knowledge of each will be helpful:

Hooks and functional components
Context API for sharing state between components

Building a compound component

We will build a rough draft of a compound component that allows the user to select multiple options from a list, using a text field to filter the list if desired.

Implementing sub-components and an `App` component

To create our compound component, we will implement two sub-components:

EnhancedMultiSelect: this will be the outer wrapping component and will have the following roles:
- Encapsulate the state of the child options
- Render the text field for filtering options
EnhancedMultiSelectOption: this component will express the individual selectable options and will have the following roles:
- Read from and write to the selection state based on user interaction
- Read the filter value and exclude itself from rendering if appropriate

Finally, we will also implement an App component that uses our compound component, to develop and test its API.

`EnhancedMultiSelect`

First, we’ll create a context that will be used to share state between the parent and child components.

export const EnhancedMultiSelectContext = createContext();

Next, we’ll implement the signature for our component, which will take three props:

children: the children in the render tree, which will include the selectable options and any other markup required by the UI. We don’t care how deeply nested the options appear or if there are other components in the tree, allowing flexibility in usage for the engineer who is using our component
value: a Set of strings representing the selected options
onChange: a function that we will call with a new Set whenever the selection changes

export default function EnhancedMultiSelect({ children, value, onChange }) {}

Now we’ll implement the body of our component. First, we’ll use a useState hook to keep track of the query the user has typed into the filter text input.

const [filter, setFilter] = useState('');

We’ll next return the components that React will render for us. We’ll first set up a provider for the context we set up earlier and use it to provide a few values that will be used by the options later on:

An isSelected function that takes a string key and returns whether or not the given key appears in the selection
A setSelected function that takes a key and adds or removes the key from the selection as indicated
The current value of the filter text input

We’ll also render our filter text input and the components children inside the context provider. Here is the full source code for EnhancedMultiSelect:

import { createContext, useState } from 'react';

export const EnhancedMultiSelectContext = createContext();

export default function EnhancedMultiSelect({ children, value, onChange }) {
  const [filter, setFilter] = useState('');
  return (
    <EnhancedMultiSelectContext.Provider
      value={{
        isSelected: key => value.has(key),
        setSelected: (key, selected) => {
          const newValue = new Set([...value]);
          if (selected) {
            newValue.add(key);
          } else {
            newValue.delete(key);
          }
          onChange(newValue);
        },
        filter,
      }}
    >
      <input
        type="text"
        placeholder="Filter options..."
        value={filter}
        onChange={evt => setFilter(evt.target.value)}
      />
      {children}
    </EnhancedMultiSelectContext.Provider>
  );
}

`EnhancedMultiSelectOption`

Now we’ll implement the other half of our compound component, which will take two props:

children: for displaying whatever the user of our component would like to render inside the selectable option
value: a string for representing this option; if this option is selected, this value will be included in the Set exposed by the parent EnhancedMultiSelect component

export default function EnhancedMultiSelectOption({ children, value }) {}

The first thing we’ll do in the body of our component is consume the context provided by the parent EnhancedMultiSelect component, using destructuring assignment to pull the context apart for easier usage.

const { isSelected, setSelected, filter } = useContext(
  EnhancedMultiSelectContext,
);

Now that we have the user’s filter query from the context, if it doesn’t match the option’s value, we’ll return null to render nothing:

if (!value.includes(filter)) {
  return null;
}

Finally, we’ll render the checkbox and plug its checked state into our compound component’s selection state, as well as any children the consumer of our component would like to render. Here is the full source code for EnhancedMultiSelectOption:

import { useContext } from 'react';
import { EnhancedMultiSelectContext } from './EnhancedMultiSelect';

export default function EnhancedMultiSelectOption({ children, value }) {
  const { isSelected, setSelected, filter } = useContext(
    EnhancedMultiSelectContext,
  );
  if (!value.includes(filter)) {
    return null;
  }
  return (
    <label style={{ display: 'block' }}>
      <input
        type="checkbox"
        checked={isSelected(value)}
        onChange={evt => setSelected(value, evt.target.checked)}
      />
      {children}
    </label>
  );
}

`App`

To see how it all works together, we’ll consume our compound component and render it in an entry point App component:

import { useState } from 'react';
import EnhancedMultiSelect from './EnhancedMultiSelect';
import EnhancedMultiSelectOption from './EnhancedMultiSelectOption';

export default function App() {
  const [selection, setSelection] = useState(new Set());
  return (
    <section>
      <EnhancedMultiSelect value={selection} onChange={v => setSelection(v)}>
        <EnhancedMultiSelectOption value="apples">
          Apples
        </EnhancedMultiSelectOption>
        <EnhancedMultiSelectOption value="oranges">
          Oranges
        </EnhancedMultiSelectOption>
        <EnhancedMultiSelectOption value="peaches">
          Peaches
        </EnhancedMultiSelectOption>
        <EnhancedMultiSelectOption value="grapes">
          Grapes
        </EnhancedMultiSelectOption>
        <EnhancedMultiSelectOption value="plums">
          Plums
        </EnhancedMultiSelectOption>
      </EnhancedMultiSelect>
      <pre>
        <code>{JSON.stringify([...selection], null, 2)}</code>
      </pre>
    </section>
  );
}

Compound component architecture in Angular

Let’s build the same simple compound component using the Angular framework.

`enhanced-multi-select.component.ts`

For the outer component, we’ll set up a simple template that contains a text input with a two-way binding to the filter property. Like in the React example, we’ll create an input for the selection state and an output when when the selection state changes. Here’s the full source code:

import { Component, Input, Output, EventEmitter } from '@angular/core';

@Component({
  selector: 'app-enhanced-multi-select',
  template: `
    <input type="text" [(ngModel)]="filter" />
    <ng-content></ng-content>
  `,
})
export class EnhancedMultiSelectComponent {
  @Input()
  value!: Set<string>;

  @Output()
  valueChange = new EventEmitter<Set<string>>();

  filter = '';
}

`enhanced-multi-select-option.component.ts`

For the option items, we’ll render a label that wraps the checkbox and the content of the component, just like in the React example. We’ll utilize Angular’s dependency injection system to get a reference to the parent EnhancedMultiSelectComponent instance passed via the constructor.

With that reference, we can evaluate and manipulate the state directly and check to see if the option should be visible according to the value of the user-provided filter string. Here is the source code:

import { Component, Input } from '@angular/core';
import { EnhancedMultiSelectComponent } from './enhanced-multi-select.component';

@Component({
  selector: 'app-enhanced-multi-select-option',
  template: `
    <label *ngIf="visible()" style="display: block">
      <input
        type="checkbox"
        [ngModel]="selected()"
        (ngModelChange)="setSelected($event)"
      />
      <ng-content></ng-content>
    </label>
  `,
})
export class EnhancedMultiSelectOptionComponent {
  constructor(private readonly select: EnhancedMultiSelectComponent) {}

  visible() {
    return this.value.includes(this.select.filter);
  }

  selected() {
    return this.select.value.has(this.value);
  }

  setSelected(selected: boolean) {
    if (selected) {
      this.select.value.add(this.value);
    } else {
      this.select.value.delete(this.value);
    }
  }

  @Input()
  value!: string;
}

`app.component.ts`

Finally, we’ll utilize our compound component and display the formatted JSON selection data for demonstration purposes:

import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  template: `
    <app-enhanced-multi-select [(value)]="selection">
      <app-enhanced-multi-select-option value="apples">
        Apples
      </app-enhanced-multi-select-option>
      <app-enhanced-multi-select-option value="oranges">
        Oranges
      </app-enhanced-multi-select-option>
      <app-enhanced-multi-select-option value="peaches">
        Peaches
      </app-enhanced-multi-select-option>
      <app-enhanced-multi-select-option value="grapes">
        Grapes
      </app-enhanced-multi-select-option>
      <app-enhanced-multi-select-option value="plums">
        Plums
      </app-enhanced-multi-select-option>
    </app-enhanced-multi-select>
    <pre><code>{{ selectionArray() | json }}</code></pre>
  `,
})
export class AppComponent {
  selection = new Set<string>();

  selectionArray() {
    return [...this.selection];
  }
}

Conclusion

In this post we’ve implemented a filterable multi-select compound component in React, using the Context API, and in Angular, using dependency injection.

Compound components are one option for creating a simple API to compose behavior that is too complex for a single component. There are plenty of alternative patterns, such as “render props” in React, and each pattern’s trade-offs should be carefully considered for a particular use case.

The full source code for running the above examples in a development environment can be found on GitHub.

Should you drop support for IE 11?

Tue, 02 Mar 2021 16:02:44 +0000

Celebration. Joy. Relief.

These are some of the words used to describe a web developer’s reaction to Microsoft’s announcement that some of their own apps and services will end support for Internet Explorer 11 in August 2021. While IE 11 is not officially sunsetted (it follows the same support cycle as the platforms with which it is included), it has taken a back seat to its replacement, Microsoft Edge, and is definitively on its way out.

And though precise measurement of browser usage is difficult, IE 11 likely represents approximately just 1% of the internet’s browsing traffic at the time of writing.

So, should your app or service continue to invest time in IE 11 support? The answer is every software engineer’s favorite: it depends.

Each app, business, and project will have a different answer and timeline for dropping legacy browser support. Below are some different aspects of this question as you consider dropping IE 11 for your app or web site.

Should you drop IE 11 support?

Who are your customers?

Identifying who your users are and how they interact with your web property is paramount to making decisions regarding browser support. Are your users primarily from large corporations whose IT departments have strict policies in place that limit choice for web browsing software, or are your customers from small businesses where the latest tools and technologies are the norm?

How many of your current users interact with your app using IE 11? What job(s) does your software get done for your users? Answering these fundamental questions will lay the groundwork for a productive internal discussion on whether or not to drop IE 11 support.

How much do your customers pay for your app or site?

Do you build a B2B SaaS offering with large but infrequent contracts, or are you building a hobby app in your free time outside of a regular job?

Is the technology itself the core value proposition of your app or does it simply enable your underlying business model?

In each of these cases, a shift in legacy technology support will have dramatic differences in how the project or business will be impacted. You need to involve all key stakeholders of the app and carefully weigh the benefits of developer experience against any potential reductions in revenue or other business implications.

Does your company have a service level agreement in place that outlines which technologies you are obligated to support?

Some large contracts include stipulations about legacy support timelines and service level agreements for bug fixes, among other things. If applicable, be sure to check with your company’s legal department to be sure that dropping IE 11 support would not constitute a breach of any contract.

Do the benefits outweigh the costs for dropping IE 11 support?

Ultimately, all of the above exploratory questions lead to a final cost-benefit analysis on dropping vs. maintaining IE 11 support for your site or app. Answers to the above questions will help you rank, compare, and add to the following lists of example costs and benefits:

Costs of dropping IE 11 support

Some users may no longer be able to use your site or app. This could decrease revenue or increase support ticket volume, etc

Benefits of dropping IE 11 support

Your site may be able to take better advantage of modern APIs or browser features
You may be able to simplify your testing and quality assurance processes
Your development cycle may be faster due to decreased compatibility requirements
You may be able to reduce the amount of code that is downloaded for your site/app if polyfills for older browsers can be removed
If you were already shipping different bundles for different levels of browser support, your deployed assets may be able to be simplified or consolidated

How to pragmatically drop support for IE 11

OK, so you’ve carefully considered all the possibilities and potential implications of dropping IE 11 support and have decided that the benefits outweigh the costs. What’s next?

There are a few different approaches that can help minimize any friction users might encounter.

At my company, Rivet, we supported IE 11 for the first year or so of the company’s life, and later decided to limit browser support to the latest two versions of the evergreen browsers (such as Chrome, Safari, Firefox, and Edge).

Rather than pull the plug completely, we carefully crafted a fallback experience for users who try to access our application with a legacy browser. To do this, we ship a separate bundle — a mini-app — that supports all browsers and shows an instructional message to the user prompting them to download a modern browser if they wish to access our application.

This added a little bit of complexity to our build and deploy processes, but has proven worth it; to simply show a blank page with a console full of errors would leave the user stranded and without a clear path on how to get unstuck.

Our CTO even visited the office of one of our largest customers. Upon arrival, he witnessed one of our users open up our app in IE 11, see the message, and then promptly switch over to Chrome to continue using the app. It was certainly a relatively smooth experience compared to the alternative, which perhaps would have been an awkward moment of confusion followed by “Yeah… you’ll want to try that again in Chrome or Firefox.”

If an automatic in-app message is not an option, there are other ways to ensure your users are as taken care of as possible:

An email marketing campaign informing and preparing users of the change
Custom error pages that direct to a help center or provide a way to get in contact with you when something goes wrong
A message that is pushed to users proactively using a chat widget like Intercom or similar

Alternative option: progressive enhancement

Legacy browser support also doesn’t have to be an all-or-nothing endeavor. The spirit of backward compatibility and progressive enhancement runs deep into the web’s DNA.

Responsive web design is the practice of offering a different design for your site or app depending on the size or type of device your user is using to interact with it. This idea is extended beyond aesthetic considerations to include behaviors and functionality.

The idea of offering a different experience based on the capabilities of the user’s browser is as old as the web itself. You might, therefore, consider offering basic functionality to IE 11 users along with a prompt to upgrade to a modern, standards-based browser for more advanced features.

Conclusion

Ultimately, software is for humans, by humans, and is a way that we communicate with each other and make each other’s lives better.

There is a delicate balance between pursuing a comfortable developer experience — therefore shortening the release cycle and allowing for more or higher quality software to be shipped more quickly — and enabling as many types of users as possible to gain value from an app.

Dropping support for legacy browsers like IE 11 should be considered carefully and approached pragmatically and empathetically.

How to Make an .ico File Using the macOS Terminal

Thu, 11 Feb 2021 13:03:36 +0000

Suppose you have an icon or logo at multiple resolutions and would like to combine them into a single favicon.ico file for your website. These are the commands you need to get up and running from the comfort of your own terminal.

Step 1: install ImageMagick

Check out the ImageMagick downloads page for instructions on how to get it running on your machine. Personally, I like to use containerization to keep my Mac free from extraneous software that I rarely use, so I’ll install ImageMagick in a Docker container instead (make sure you have Docker installed):

docker run -it --rm -v /absolute/path/to/icons/directory:/workdir -w /workdir ubuntu

This command will drop you into a bash session on the container. From there, it’s easy to get ImageMagick installed:

apt update
apt upgrade
apt install -y imagemagick

Tip!

ImageMagick has a dependency on tzdata, so you will be prompted to configure your time zone upon installation. Since this is an ephemeral installation, you can just type 1 for each prompt to get through the installation process quickly.

Step 2: create the file

ImageMagick gives us a handy convert command that makes the process super easy:

convert input-file-16x16.png input-file-24x24.png input-file-32x32.png input-file-64x64.png favicon.ico

This will create the desired favicon.ico file.

Step 3: verify the .ico file

ImageMagick also provides a nice utility called identify for inspecting our file to ensure it is formatted as we expect.

identify favicon.ico

The output should look something like this:

favicon.ico[0] ICO 16x16 16x16+0+0 8-bit sRGB 0.000u 0:00.000
favicon.ico[1] ICO 24x24 24x24+0+0 8-bit sRGB 0.000u 0:00.000
favicon.ico[2] ICO 32x32 32x32+0+0 8-bit sRGB 0.000u 0:00.000
favicon.ico[3] ICO 64x64 64x64+0+0 8-bit sRGB 24838B 0.000u 0:00.000

You Might Not Need Sass: Modern CSS Techniques

Tue, 15 Sep 2020 12:46:12 +0000

Sass and other CSS preprocessors have some great features and have been widely used for years. CSS is rapidly evolving, though, and some of the features that were previously only possible through preprocessors are now achievable in plain CSS. While updating the styles for mjswensen.com, I found plain CSS to be powerful enough on its own and completely migrated away from Sass. Depending on the size and needs of your project (and target browser support), you may be able to simplify your CSS tool chain as well by using these techniques.

The Sass features we will be re-creating in vanilla CSS in this article:

Parameterized Mixins
Color Manipulation
Variables

Parameterized Mixins

In Sass, you can define a collection of reusable styles, and then include the styles in multiple places throughout your stylesheet.

@mixin alert ($color: yellow) {
  color: $color;
  border: 1px solid currentColor;
  padding: 1em;
}

.error {
  @include alert(red);
}

.success {
  @include alert(green);
}

<div role="alert" class="success">Submitted successfully.</div>

We can achieve this same functionality in vanilla CSS using custom properties and some changes to our markup:

.alert {
  color: var(--color, yellow);
  border: 1px solid currentColor;
  padding: 1em;
}

.error {
  --color: red;
}

.success {
  --color: green;
}

<div role="alert" class="alert success">Submitted successfully.</div>

Tradeoffs

Though we can achieve something similar to Sass’s @mixin/@include with vanilla CSS, there are some tradeoffs to this approach:

There is less clarity around how to use the alert class since it’s --color “parameter” is implicit; you have to reference the HTML to see how it is being used and what the value of --color might be, whereas with Sass the parameters are explicit.
Sass can catch incorrect usages of mixins at compile time and surface errors to the developer, whereas the CSS approach will silently fail if used incorrectly.
Since the CSS approach involves both the stylesheet and the markup, there is more room for mistakes in refactoring a “mixin,” especially in large projects.

Color Manipulation

Sass has long provided a powerful library for manipulating colors. Similar functionality has been proposed for CSS in the CSS Color Module Level 4 specification but is not available for widespread use at the time of writing. However, using the widely available CSS calc() function, we can achieve some simple color manipulations without any tooling on top of our CSS.

In Sass, we can use the rgba() and desaturate() functions to get semi-transparent and desaturated versions of a given color, respectively:

$main-color: hsl(14, 75%, 58%);
$semi-transparent-main: rgba($main-color, 0.1);
$desaturated-main: desaturate($main-color, 20%);

We can achieve the same effect in CSS by splitting the color components into their own custom properties and operating on them individually:

:root {
  --main-color-h: 14;
  --main-color-s: 75%;
  --main-color-l: 58%;
  --semi-transparent-main: hsla(
    var(--main-color-h),
    var(--main-color-s),
    var(--main-color-l),
    0.1
  );
  --desaturated-main: hsl(
    var(--main-color-h),
    calc(var(--main-color-s) - 20%),
    var(--main-color-l)
  );
}

Tradeoffs

The Sass syntax for color manipulation is more compact, easier to use, and easier to read. There are also limitations to the CSS-only approach, at least until the color() function becomes a W3C recommendation and gains browser adoption.

Variables

One of the most then-groundbreaking features of CSS preprocessors was the ability to define and reuse values via variables. As seen in the examples above, we can now do the same thing in vanilla CSS using custom properties. But there are some nuances in the difference between Sass variables and custom properties that are worth mentioning.

Since Sass is a compiled language (compiles down to CSS), variable values are evaluated at compile time rather than at runtime. This comes with a couple of tradeoffs to consider:

Sass variables’ values can’t change in response to browser context changes (like media queries), while custom properties can.
Sass can warn you if you try to use a variable that hasn’t been initiated (if the name is misspelled, for example), while CSS will fall silently when using an undefined variable.
Both Sass variables and custom properties are “global,” but “global” has different meanings. For Sass, “global” means in scope for the current compilation target and any dependency stylesheets (and their dependencies). In CSS, “global” means really global: the values are visible to all stylesheets, markup, and scripts loaded on the page.

Conclusion

Modern vanilla CSS can cover some of the preprocessors’ flagship features, but at a cost of readability and maintainability. The overhead of a CSS build process may be worth it for larger projects or teams. For smaller or solo projects, though, CSS is powerful enough to stand on its own.

The Book of Mormon: An Ancient Guide to Modern Times

Wed, 08 Jul 2020 12:24:00 +0000

As millions of members of the Church of Jesus Christ around the world study the Book of Mormon together this year, I have been impressed by how similar the challenges, attitudes, and behaviors are between the ancient people in the record and people today.

This week we study an exchange between Alma, a reformed trouble maker who has become the leader over the ancient Church in that area, and Korihor, a self-proclaimed “Anti-Christ.” Alma and Korihor pre-date the life of Jesus Christ, so their discussion revolves around whether or not a Christ would come. Note Korihor’s key arguments as he contends with Alma:

Sound familiar? These similar to ideas that are very widespread in the modern world; thoughts shared by non-believers and even believers from time to time. Take a look at Alma’s rebuttals:

Korihor tells Alma he will change is mind if Alma can provide proof of God’s power. To see how the story ends, read verses 43-60 of chapter 30 of the book of Alma in the Book of Mormon.

There are lots of interesting things to learn from this account, but if anything, we learn that we’ve been here before—humans in ancient times are similar to us now, therefore we can learn from their experience to better ourselves and our world.

The Book of Mormon can be studied online for free at ChurchOfJesusChrist.org.

Building Stripe.com's Tabbed Preview Widget From Scratch in 30 Minutes

Thu, 09 Apr 2020 12:39:00 +0000

In this video I try to build a fully functional tabbed preview widget in HTML and CSS from scratch in 30 minutes—without looking at the original code. After the time’s up, I peek under the hood to see the approach of the original author and compare and contrast it to my approach.

The build process

Setting up a development environment

For this short project I used a very simple setup: an index.html file served by browser-sync for automatic reloads on save. It can be run without previous download or install via npx, which is included by default in node/npm installations.

npx browser-sync --server --files index.html

Configuring the widget’s container

Since this widget doesn’t appear to respond to the window size, I used the macOS screenshot tool (command-shift-4) to measure the dimensions and simply hard-code them into the CSS.

Managing the active tab state

The original Stripe implementation uses JavaScript to maintain the state of the currently active tab, which is a perfectly reasonable approach. I thought it might be fun to see if we could do it without JavaScript. I landed on using radio-type HTML inputs and some CSS selector tricks to achieve the same effect. In a professional setting, I would have likely used JavaScript—one could argue that this is an inappropriate use of radio inputs since this is an informational widget and not part of a form with user-provided data.

The book I referenced in the video is called Resilient Web Design by Jeremy Keith and is freely available to read online.

Sliding the content left and right based on the active tab

I wrapped the code snippets in a container and positioned it absolutely, altering the left property based on the active tab. We discuss a better approach to this later on when we inspect Stripe’s solution.

To give the widget a 3D appearance, I rotated the widget around the X and Y axes, but it didn’t quite have the right effect. I should have used the rotate3d() function instead.

Adding a shine effect

For the shine effect, I added an ::after pseudo-element, positioned absolutely to stretch the width and height of the container, and added a background gradient. To keep the text beneath it selectable (and tabs clickable), pointer-events: none was required so that mouse events would fall through it.

My final code

Here is what I ended up with at the end of the session.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Code Preview Widget</title>
  <style>
    .container {
      --width: 490px;
      --bg: #31335B;
      --radius: 8px;
      --border-active: #596481;
      width: var(--width);
      height: 380px;
      background-color: var(--bg);
      border-radius: var(--radius);
      color: white;
      display: grid;
      grid-template-columns: repeat(5, 1fr);
      grid-template-rows: auto 1fr;
      transform: rotateX(-10deg) rotateY(10deg);
      position: relative;
    }

    .container::after {
      content: '';
      position: absolute;
      top: 0;
      right: 0;
      bottom: 0;
      left: 0;
      background-image: linear-gradient(to bottom right, hsla(0, 0%, 100%, 0.15), transparent);
      pointer-events: none;
    }

    .content {
      grid-column-start: 1;
      grid-column-end: 6;
      position: relative;
    }

    .slide-wrapper {
      display: flex;
      overflow-x: hidden;
      position: absolute;
      transition: left 400ms ease-in-out;
    }

    #js:checked ~ .content .slide-wrapper {
      left: 0;
    }

    #rb:checked ~ .content .slide-wrapper {
      left: calc(var(--width) * -1);
    }

    #py:checked ~ .content .slide-wrapper {
      left: calc(var(--width) * -2);
    }

    #go:checked ~ .content .slide-wrapper {
      left: calc(var(--width) * -3);
    }

    #other:checked ~ .content .slide-wrapper {
      left: calc(var(--width) * -4);
    }

    .content pre {
      width: var(--width);
      overflow: hidden;
    }

    input[type="radio"] {
      display: none;
    }

    #js:checked ~ label[for="js"],
    #rb:checked ~ label[for="rb"],
    #py:checked ~ label[for="py"],
    #go:checked ~ label[for="go"],
    #other:checked ~ label[for="other"] {
      background-color: var(--bg);
      border-left: 1px solid var(--border-active);
      border-right: 1px solid var(--border-active);
      border-bottom: 1px solid var(--bg);
    }

    label {
      background-color: #2D2F4A;
      border-top-left-radius: var(--radius);
      border-top-right-radius: var(--radius);
      text-align: center;
      padding: 0.25em;
      border-bottom: 1px solid var(--border-active);
    }
  </style>
</head>
<body>
  <div class="container">
    <input type="radio" name="tab" id="js" checked>
    <input type="radio" name="tab" id="rb">
    <input type="radio" name="tab" id="py">
    <input type="radio" name="tab" id="go">
    <input type="radio" name="tab" id="other">
    <label for="js">
      Node.js
    </label>
    <label for="rb">
      Ruby
    </label>
    <label for="py">
      Python
    </label>
    <label for="go">
      Go
    </label>
    <label for="other">
      ...
    </label>
    <section class="content">
      <div class="slide-wrapper">
        <pre><code>// Set your secret key
  const stripe = require('stripe')('sk_test_BQokikJOvBiI2HlWgH4olfQ2');
  
  // Get the payment token ID submitted by the form:
  const token = request.body.stripeToken;
  
  (async () => {
    const charge = await stripe.charges.create({
      amount: 999,
      currency: 'usd',
      description: 'Example charge',
      source: token,
    });
  })();</code></pre>
        <pre><code># Set your secret key
  Stripe.api_key = 'sk_test_BQokikJOvBiI2HlWgH4olfQ2'
  
  # Get the payment token ID submitted by the form:
  token = params[:stripeToken]
  
  charge = Stripe::Charge.create({
    amount: 999,
    currency: 'usd',
    description: 'Example charge',
    source: token,
  })</code></pre>
        <pre><code> Set your secret key
  stripe.api_key = 'sk_test_BQokikJOvBiI2HlWgH4olfQ2'
  
  # Get the payment token ID submitted by the form:
  token = request.form['stripeToken']
  
  charge = stripe.Charge.create(
    amount=999,
    currency='usd',
    description='Example charge',
    source=token,
  )</code></pre>
        <pre><code>// Set your secret key
  stripe.Key = 'sk_test_BQokikJOvBiI2HlWgH4olfQ2'
  
  // Get the payment token ID submitted by the form:
  token := r.FormValue('stripeToken')
  
  params := &stripe.ChargeParams{
    Amount: 999,
    Currency: 'usd',
    Description: 'Example charge',
  }
  params.SetSource(token)
  ch, _ := charge.New(params)</code></pre>
        <pre><code>TODO</code></pre>
      </div>
    </section>
  </div>
</body>
</html>

Inspecting the original Stripe code

Differences with my approach

Aside from the fact that the Stripe code was much more polished (with additional borders, typography, syntax highlighting, etc.), there were a number things about the original code that were much improved to my version. Here are a couple:

Rather than transitioning the left property to slide the code back and forth, the original author used translateX(), which is more performant.
The original author used the <figure> element to wrap this widget, which is much more semantically correct than the div I used.

Nice touches

Stripe is known for adding a level of polish and detail that most engineering teams can only dream of. Here are just a couple that I noticed:

Using ::before and ::after pseudo-elements with transparent-to-opaque background gradients, the text had an appearance of sliding “under” the edges of the widget as it moved back and forth.
A tasteful box-shadow was added to augment the 3D effect of the widget.

Conclusion

Any questions or suggestions about my tooling, approach, development style? What would you have done differently? I’d love to hear from you. Find me on Twitter or leave a comment on the video.

Tools

Here are the tools I used in this video:

Text editor: Visual Studio Code with theme Right in the Teals by themer, and Fira Code font
Browser: Brave
Development server: Browsersync launched under npx
Application launcher: Alfred
Color picker: Sip

Playing the Numbers: A Millennial Engineer's Probabilistic Approach to Believing in God

Wed, 18 Dec 2019 12:48:00 +0000

Update 12/18/2019

Thanks to an astute Reddit commenter, today I learned about Pascal's Wager, which is strikingly similar to the idea I tried to synthesize below. For a more in-depth read on this topic, check out the Wikipedia article on Pascal's Wager.

A core premise (perhaps the core premise) of religiosity is faith, which I define as “believing in things one cannot see or otherwise definitively prove.” Though faith is an essential component to any religious conversation, I’d like to set it aside for just a moment and focus instead on a pragmatic and logical way of thinking about religion.

The topic in question: “Does God exist?”—a question that has sparked divisive debate for millennia. Believers will present mountains of “evidence” while non-believers will correctly point out that such “evidence” cannot amount to “proof.”

Rather than pick my side and try to convince others of its relative merit, I take a different approach. Let’s look at the problem rationally, from a distance, by comparing the expected utility and implications of each option.

For the purposes of illustration, let’s simplify the spectrum of possibilities down into two distinct categories: either there is a God, or there is not. The primary end goal of most religions is to influence people to live according to a moral code, usually set forth by deity. So again, let’s boil the infinitely broad spectrum of lifestyle choices into two simple categories: to obey God’s moral code or to not obey God’s moral code.

For a visual aid, we plot our two dimensions onto an empty probability square.

	God	No God
Obey
Not Obey

Since the goal of most rational people is to maximize one’s own happiness, we’ll use a rough relative measure of happiness level for the values in our square.

The doctrines of most religions include some flavor of an afterlife, so we’ll also add a third dimension to our square: this life vs. the afterlife.

	God	No God
Obey	this life happiness / afterlife happiness	this life happiness / afterlife happiness
Not Obey	this life happiness / afterlife happiness	this life happiness / afterlife happiness

We’re ready to start filling out our diagram, starting with the left column. We might describe these cells as “the happiness level in both this life and the afterlife of people who obey God and who do not obey God, given God exists.”

“Happiness in this life” is difficult to measure. Though some research suggests that religiosity is directly correlated with increased happiness, health, and wealth, in my observation faithful people do not have a corner market on happiness or prosperity, and they certainly aren’t immune to the challenges of being human. Conversely, despite what many non-religious people believe, living free from the rigors of a religious lifestyle isn’t necessarily a path to greater happiness in the long run. To keep our estimates conservative, we’ll assume that the happiness level of both religious and non-religious people is approximately the same. We’ll mark this level as “average.”

	God	No God
Obey	Average / ?	? / ?
Not Obey	Average / ?	? / ?

The afterlife dimension of these cells is more straightforward. Most religions concur that obedience to God in this life warrants some sort of reward in the afterlife; and disobedience results in some form of diminished happiness, at least temporarily.

	God	No God
Obey	Average / High	? / ?
Not Obey	Average / Low	? / ?

On to the right column. We will reuse our previously calculated “Average” happiness level for both obedient and non-obedient people for this life into this column. Since there is no God and presumably therefore no afterlife in these scenarios, we’ll put “N/A” for the afterlife values.

	God	No God
Obey	Average / High	Average / N/A
Not Obey	Average / Low	Average / N/A

With our square filled in, we can now finish our analysis. Since the existence of God can neither be proven nor disproven (much to the chagrin of both believers and non-believers), we’ll naively assign an equal probability of 50% to both options. And in lieu of a more precise measure for happiness, we’ll make a simple assignment of 1, 2, and 3 to our rough levels.

	God (0.5)	No God (0.5)
Obey	Average (2) / High (3)	Average (2) / N/A
Not Obey	Average (2) / Low (1)	Average (2) / N/A

Now we can calculate the expected value for happiness for the two lifestyle choices:

Obey: 0.5 × (2 + 3) + 0.5 × 2 = 3.5
Not obey: 0.5 × (2 + 1) + 0.5 × 2 = 2.5

Our simple analysis suggests that obedient people will have a larger expected happiness, and therefore the rational choice to maximize well-being is to live in accordance to God’s moral code.

Of course, life is infinitely more complex and our illustration may only serve as little more than a thought experiment, but a valid point still remains: banking life decisions on whether or not to live by a moral code solely on the existence or absence of God is an enormous bet and strictly a one-way ratchet in the sense that the upside is negligible with the potential for substantial downside.

As for me, I like my choices to be the opposite: negligible downside with the potential for infinite reward.

From Electron to Progressive Web App

Sun, 24 Mar 2019 02:29:00 +0000

In this post I’d like to review my reasoning behind sunsetting an Electron-based application in favor of a Progressive Web App (PWA).

tl;dr

Choose your platform wisely—you are at the mercy of its maintainers
URLs are amazing
You really can't beat the distribution model of the Web

themer

First a little context. My application, themer, started off as a command-line tool built on Node.js. It uses a set of colors as input and produces matching themes for various text editors, terminal emulators, and other tools. However, actually choosing the colors for your personalized theme was tedious and cumbersome. A friend suggested to me that I build a GUI to help ease this process and provide a tighter feedback loop when creating a personalized theme. Given that Electron bundles a Node.js runtime, and that I could therefore easily wrap my CLI in a “native” GUI for all platforms, an Electron app seemed like a perfect fit. themer’s GUI was born:

The bug

After spending a good amount of time building the GUI and wiring it up to my CLI running in Electron’s Node process, I was able to bundle up the application installers and make them available for download on the GitHub releases page. It wasn’t until after the application was downloaded about 10k times that I discovered a really nasty bug that caused Electron-based applications to crash when using the macOS native color picker:

It took nearly eight months to fix that issue, during which the utility of themer’s GUI was drastically reduced.

The takeaway

When building for a particular platform or framework, you are at the mercy of its maintainers (of course, if the project is open-source, you can attempt to fix problems yourself, but this isn’t always tenable). Even though Electron is popular, a bug like this wouldn’t have lasted a week in a mainstream Web browser (or likely occurred at all).

Shared/persisted state

One requirement for themer’s GUI was that users should be able to save (and ideally share) their themes. Short of some sort of cloud-based service that integrated with the GUI, the best solution was to simply allow themer’s GUI to read and write JSON from the filesystem. One neat thing about Electron is that you can register a custom icon with the operating system for files that match your custom extension:

I went the whole nine yards and implemented Open, Save, Save As..., friendly prompts to prevent accidental discarding of unsaved changes, etc…. basically everything you’d expect from a traditional desktop program. This worked well enough for persisting theme data, but didn’t allow for easily sharing themes with others.

On the Web, there’s a better way to share application state: the URL. themer’s new PWA stores all of the theme-relevant state in the URL’s query string, so sharing your theme is as easy as sending a link (like this one), and saving is as easy as bookmarking (or just using your browser’s history).

The takeaway

The URL is one of the Web’s most wonderful and distinguishing features. This simple and powerful state/location sharing mechanism is one of my favorite parts about the Web, and is glaringly missing from other platforms.

Distribution model

There is a great open-source package available called electron-builder that adds support for pushing updates that your app can automatically download in the background. In all, it was relatively easy to configure and get working, but there was always a voice in the back of my mind that said: “I hope the updater code in this version works; if it doesn’t, no one will be able to install updates beyond this point.”

While it’s still possible to shoot yourself in the foot with a PWA’s ServiceWorker, more of the cacheing and network code lives in the browser itself, leaving less room for error in user-land.

The takeaway

The distribution model for the Web is unparalleled. If you ship a version of your application that is broken, all you have to do is fix it and re-deploy. The platform itself takes care of the rest.

Conclusion

There are, of course, applications that require the use of Electron (like VS Code for filesystem access, etc.), in which case the choice to build a purely Web-based application is not so simple as it was for my small pet project.

Electron is a wonderful piece of software, and building an Electron app was an enjoyable experience filled with learning. After having spent some time with it, though, I am more committed than ever to building for my platform of choice: the Web. I can’t wait to see what the future holds for PWAs and Web technologies in general.

Check out themer’s new PWA and let me know what you think.

Zen and the Art of Software Engineering

Sat, 25 Mar 2017 00:58:00 +0000

As part of my on-boarding as software engineer at Nuvi, I had the opportunity to read the classic book Zen and the Art of Motorcycle Maintenance: An Inquiry into Values by Robert M. Pirsig. While the book delves deeply into abstract philosophical concepts, there were a number of concrete principles that I felt had direct application to writing high-quality software.

The efficacy of a machine

Pirsig points out that a machine (or system or tool) really has no inherent efficacy; but rather its efficacy is measured by how satisfied we are with it. I thought this was a compelling point of view because it provides us with a useful measuring stick for our software. For example, I could build a beautiful UI that I believe to be streamlined and intuitive, but if our users have different needs, the tool is not effective for them.

This also applies to developers as they build the software. The book discusses how the true artisan is actively involved in their work, being one with the material (the tools, technologies, and code), and has peace of mind when producing good work. If there isn’t peace of mind, it could be a sign of subpar work or an ineffective environment.

Being stuck isn’t a bad thing

An eye-opening point brought up in the book is the idea that being mentally stuck is not a bad thing. It’s so common in day-to-day software work to run into roadblocks, and they are justifiably seen as annoyances that keep engineers from their goal to deliver software. However, these roadblocks provide opportunities for creativity—to think “laterally” as Pirsig calls it—to find new solutions and to innovate.

Gumption is psychic gasoline

Though nearly 40 years later the word “gumption”—defined as shrewd or spirited initiative and resourcefulness—seems somewhat outdated, it accurately describes the creative fuel we need to produce quality work. We should work to ensure that our proverbial tanks of gumption don’t deplete. Pirsig dedicates a significant amount of time in the book to discuss the sources and drains of gumption. These are the ones that stuck out to me:

Don’t try to regain gumption by working furiously to make up lost time. It doesn’t work for motorcycles or for software.
Sometimes making your own motorcycle parts will build gumption. In the software world, I think of this as finding and building the right abstractions in code.
Ego is a gumption trap. So is anxiety about failure.
Bad tools are also a gumption trap.

Conclusion

Creating quality work is an all-encompassing act, requiring conscious effort that is more often focused inwardly rather than on the work itself. To adapt Pirsig’s own words: “The real [software] you’re working on is the [software] of yourself.”

GitHub Pages vs. GitLab Pages

Fri, 01 Jul 2016 03:59:00 +0000

I’ve been a longtime fan of GitHub Pages. It is a wonderful option for hosting many types of sites. However, recent movements toward a more secure web and GitHub’s lack of support for HTTPS on GitHub Pages with a custom domain prompted me to start looking at other options, including GitLab Pages.

GitLab Pages has a lot of great features, many of which are similar to those of GitHub Pages (there’s no question that they are shooting for feature parity with the large incumbent). But there was one problem that was an absolute show-stopper for me: painfully slow build queues. For that reason primarily, I moved back over to GitHub Pages.

These are the primary differences I found between the two services:

	GitHub Pages	GitLab Pages
Static site generator support	Jekyll only, no plugins	Completely customizable build, therefore any SSG is supported (including plugins)
Build configuration	Optional; Jekyll sites will be built automatically, and non-Jekyll sites are published directly. Tests can be set up easily through travis-ci.org	Required; without a valid build definition GitLab Pages won’t know how to deploy your site. Setting up the build definition in `.gitlab-ci.yml` is easy and is very similar to setting up `.travis.yml` for GitHub Pages project
Build queue time	Almost always instantaneous, both on the GitHub Pages side and the Travis CI side	Excruciatingly slow; of the several builds I triggered on my site, the average wait time was a couple of hours
Support for HTTPS	Partial	Yes
CDN support	Out-of-the-box	Not provided by GitLab Pages but can be configured with free tiers of popular CDN providers

GitLab Pages has a lot of great features. And the GitLab.com service is generally fantastic, especially given that it’s free. One of my favorite parts is that they offer free build instances (they call them “runners”) as part of the GitLab.com offering (and the CI is built right into the core product—another plus). The only issue is that since the runners are free, they are overworked and the build queues can be hours long (at the time of writing, at least). While it’s still a wonderful service, the delayed builds means a feedback loop that is too slow for feature development and a production deploy time that is too unpredictable.

That slowness and the need to configure CDN myself outweighed my desire to enable TLS on my site for now. And given GitHub’s track record, I also have a sneaking suspicion that TLS support on GitHub Pages is just around the corner. In which case I’ll be extra glad I stayed.

Keeping Our Testimonies Up-to-date

Sun, 15 May 2016 15:25:00 +0000

I had the opportunity to give a talk on this topic to a congregation of the Church of Jesus Christ in South Jordan, UT. The following is the transcript. The original topic title was “Finding Peace Through Jesus Christ by Strengthening Your Testimony Throughout Your Entire Life”.

Good morning brothers and sisters, I’m Brother Swensen. Today I will be talking about testimony. But I won’t be talking about it in the way we normally do. Often we think of a testimony as a belief or assurance of a particular point of doctrine or principle. And usually we think of these testimonies as knowledge gained by some specific experience in our lives, that can then be added to our collection of experience to be recalled later when we need it. Today, however, I am trying to shift my own thinking of what a testimony is—and I invite you to do the same—by thinking about testimony in the context of the passage of time; so rather than thinking of our testimonies as pieces of knowledge gained at a particular point in time, instead thinking of them as a living foundation that changes and adapts over time.

Testimonies Need Updating

As my sweet wife pointed out to me while I was studying to prepare this talk, an absolutely essential facet to our Heavenly Father’s Plan of Salvation is that we learn and grow constantly over time, “line upon line, precept upon precept” (2 Nephi 28:30). As part of that growing process, we acquire additional responsibility throughout our lives, in both spiritual and temporal matters. Typically, also the challenges and trials that we face increase in difficulty as we age and mature. Because of this, our testimonies need to be growing at a proportional pace. The testimony that we had at age 5, or 16, or 27 will not be sufficient alone to sustain us at age 43 or 72 or 96.

I am a software engineer by trade, and as such, I spend most of my day on the computer. What many people don’t realize, is that a software program is never really “finished.” (Which is good, because it means job security for me!) There are always features to be added or fine tuned, enhancements than can be made, or problems that need to be fixed. Indeed, I spend most of my professional time publishing updated versions of my company’s software for the people who use it. Naturally, I am the designated technology fixer-upper for our family. And with this background, obviously when one of our computers or phones are not behaving properly, the first thing that I check is whether or not there are updates available for the software on the problematic device. More often than not, the problems that Christine and I run into with our technology are fixed when I make sure that everything is up-to-date.

Our testimonies are the same way. We need to make sure that our testimonies are constantly updated for our spirits to be in tip-top shape. When we are sharing spiritual experiences, if we are needing to always refer back to long-past missionary service or an experience we had many years ago, it’s time for a testimony makeover! While those experiences are still special and important, we should be able to say “last week…” or “yesterday…” or “this morning I had a testimony-building experience.” Alma taught us this in the Book of Mormon when he asked this probing question: “And now behold, I say unto you, my brethren, if ye have experienced a change of heart, and if ye have felt to sing the song of redeeming love, I would ask, can ye feel so now?” (Alma 5:26).

Testimonies Need To Be As Dynamic As Our Modern-day Lives

Not only do our testimonies need to be current, they need to be broad and dynamic. The Greek philosopher Heraclitus once said that the only thing that is constant in life is change. Our circumstances are indeed constantly changing, as are our thoughts, needs, worries, strengths, weaknesses, doubts, struggles, and questions. Our testimonies need to adapt to our changing needs. For example, when I am teaching the missionary preparation class, I need to be able to bear sincere testimony of the material being taught, which is different every week. (I am still learning how to do that and have a long way to go.) The same can be said of missionaries, Sunday School instructors, parents, grandparents, visiting teachers, home teachers, and so forth.

Our testimonies need to be living, dynamic, and ever evolving. This is the reason that we invariably hold testimony meetings every single month, instead of proclaiming our convictions just once when we gain our initial testimony.

Brothers and sisters, gaining and maintaining a dynamic, current, multi-dimensional testimony is what will allow us to have peace in our lives. It is by believing in the Savior and living His Gospel that we find this type of testimony and accompanying peace. As the beloved hymn states: “Where can I turn for peace? Where is my solace when other sources cease to make me whole? .. He, only One. … In my Gethsemane, Savior and Friend. Gentle the peace he finds for my beseeching. Constant he is and kind. Love without end.” (“Where Can I Turn for Peace?”, Hymns, 129).

Finding Peace and Testimony by Believing in and Living the Gospel of Jesus Christ

In the very first chapter of Teachings of the Presidents of the Church: Howard W. Hunter, President Hunter teaches: “In this age, as in every age before us and in every age that will follow, the greatest need in all the world is an active and sincere faith in the basic teachings of Jesus of Nazareth, the living Son of the living God. Because many reject those teachings, that is all the more reason why sincere believers in the gospel of Jesus Christ should proclaim its truth and show by example the power and peace of a righteous, gentle life. …”

Fortunately, God has outlined the pattern for our lives in the scriptures in various formats. Of course, the example of the Savior Himself is the foremost point of reference for how we must try to live our lives. He has laid the path for us, setting the example in every detail for how we can return to live with Him again in the Celestial Kingdom.

When we are living a particular principle of the Gospel, Moroni teaches us that we can ask Heavenly Father to bless us with a testimony of that principle: “And when ye shall receive these things, I would exhort you that ye would ask God, the Eternal Father, in the name of Christ, if these things are not true; and if ye shall ask with a sincere heart, with real intent, having faith in Christ, he will manifest the truth of it unto you, by the power of the Holy Ghost. And by the power of the Holy Ghost ye may know the truth of all things. And whatsoever thing is good is just and true; wherefore, nothing that is good denieth the Christ, but acknowledgeth that he is.” (Moroni 10:4-6)

Even if we have doubts or questions, the core truths of the Gospel can be an anchor to us. In the talk “Returning to Faith” by Sister Rosemary M. Wixom in the April sessions of General Conference last year, Sister Wixom quotes a young woman who was struggling to maintain her testimony when she received an inspired calling to play the piano for the primary. She said: “Playing the Primary songs, she often thought to herself, ‘Here are truths I love. I can still bear testimony. I will just say those things that I know and trust. It may not be a perfect offering of knowledge, but it will be my offering. What I focus on expands inside of me. It is beautiful to get back to the essence of the gospel and feel clarity.’” The young woman was actively working on updating her testimony by focusing first on the core doctrines that are taught in Primary.

Conclusion

Brothers and sisters, I know that the Savior and the Gospel can give us a peace that no worldly pursuit can ever offer us. I know this because I have put it to the test, usually by my own mistakes or misguided actions. There is no other way to enjoy the sweet peace of striving to live a righteous life. I know that the most powerful testimonies are the ones that aren’t stagnant or outdated, but rather that grow with us as we move forward through life. I encourage you to consider the changes you may need to make in your life to more fully enjoy the sweet peace and blessings that the Savior is so willing to give to us. I know that He loves us and that He is there, closer to us than we usually realize. I close with some of his tender words from the New Testament: “Peace I leave with you, my peace I give unto you: not as the world giveth, give I unto you. Let not your heart be troubled, neither let it be afraid.” (John 14:27). May we find peace through Him by strengthening our testimonies throughout our entire lives. In the name of Jesus Christ, amen.

How to Learn From Mistakes

Sat, 26 Dec 2015 23:29:00 +0000

Mistakes are an inevitable and essential part of the human experience. Though everybody makes mistakes of some form or another, not everyone leverages the great potential for learning and growth that mistakes offer. Here are some ideas for taking advantage of our mistakes rather than simply letting them weigh us down.

Allow yourself to feel the pain

Mistakes hurt. There’s no sugar-coating it: when we screw up, we cause pain for ourselves and those around us. Realizing that we’ve hurt a loved one can be a source of some of the deepest emotional pain we experience.

We are pre-programmed with a natural aversion to pain, which helps us survive and avoid dangerous situations. We can use this aversion to our advantage when we make mistakes. Rather than avoid the pain we are experiencing after making a mistake—as many often do—we should instead embrace the pain and let it run its full course to help us fully learn our lesson.

Pain avoidance	Pain acceptance
"Medicating" with alcohol or addictive substance/behavior	Meditating on the events leading up to the mistake
Mentally denying that a mistake was made	Pondering the implications and consequences of the mistake

It may seem counterintuitive at first, but actively accepting the pain allows us to feel the depth of it and let our natural aversion to pain do its job when we later remember what we’ve experienced. If we avoid it altogether, we don’t allow ourselves that learning opportunity.

Set goals for yourself

Setting goals is a proven practice for personal growth. Setting goals in relation to and in reaction to a mistake helps restore lost self-confidence and brings hope for the future. Set goals that will help you avoid making the same mistake again. Also set other worthwhile goals that may be unrelated but that will lead to a balanced life. Here are some examples:

Arise earlier each morning to allow for exercise or mediation
Spend a little time each day on behalf of others
Study from good books for 30 minutes each day

Write a letter to your children (or your future self)

Record your mistake and your experience with the pain it brought in a letter or journal format. It may sound strange, but there is something fulfilling about providing hard-earned wisdom to others in writing, even if your letter is never read. If it is actually read someday, you are altruistically giving the reader knowledge that they didn’t have to learn the hard way. If not, the act of writing down your experience is still therapeutic.

Do your best to rectify the problems you’ve caused

Very few mistakes are completely unrecoverable. Use your creativity to come up with ways to minimize the damage. Also, if you hurt others, seek forgiveness from those people. Though your healing shouldn’t be contingent on receiving the forgiveness of others—you can’t control what they choose to do or say, after all—some of life’s most beautiful experiences involve sincere apologies we offer to those we care about.

Involve God

We are children of a loving Heavenly Father who weeps when we are in pain and who rejoices when we learn from our mistakes. We can turn to Him with our concerns, and He can help us with strength to undertake any of the processes outlined in this article. If your mistake was moral in nature, ask Him for forgiveness and tell Him of your resolve to improve; He will answer that prayer and help you feel of His unconditional love for you.

To learn more about forgiveness through Jesus Christ, visit comeuntochrist.org.

Forgive yourself

Understand that making mistakes is part of the human experience. Even still, forgiving oneself is not as easy as it sounds. Here are some ideas for starting on that challenging process:

Talk with a trusted friend or family member who is capable of encouraging you and building you up.
Make a list of accomplishments or positive points about yourself.
Think on a time when you were able to forgive someone else, and apply those feelings toward yourself.

You can also cultivate a love of self by doing the following:

Show self-respect by living healthily (food, sleep, exercise, etc.).

Let it go!

Finally, after you have extracted all of the learning and growth potential out of a mistake, let it go and move on. Keep only enough of it in your memory to not make the same mistake twice. Carrying it any further is a waste of energy!

Conclusion

As outlined in one of my new favorite books, The Pursuit of Perfect: How to Stop Chasing Perfection and Start Living a Richer, Happier Life by Tal Ben-Shahar, failure is a required and essential element of growth. But our mistakes will only be useful to us if we learn to let them propel us to greater heights!

Static Sites Are Awesome

Sat, 19 Sep 2015 21:41:00 +0000

When creating landing pages, content sites, or blogs, content management systems shouldn’t be the first tool web developers reach for. Because of the many benefits that come with the simplicity of static sites, they are not only a viable alternative, they are a more practical alternative. And with the popularity of static site generators rapidly on the rise, creating and maintaining static websites is easier than ever.

Why static sites?

For certain types of content, static websites excel over content management systems in lots of areas, including performance, decreased server maintenance, site maintainability, and capacity for version-controlled content.

Performance

In today’s world where site performance is of utmost importance, the most compelling reason to move toward static websites is the performance benefit. Content management systems make use of a database, and reading from the database to serve page content incurs a performance cost. Static sites make no use of a database—all the content is baked right into the final HTML code. The performance win comes from the fact that modern webservers (like Apache or nginx) are heavily optimized to serve such static files extremely quickly.

In a nutshell, with a CMS, the burden of constructing a web page is placed on the server, at the time the page is requested. With a static site, that burden is moved to when the site is assembled before it is deployed. Many programmers will agree that, from a user experience perspective, it is better to have as much processing occur as possible at compile time rather than at run time. This is the approach that static site generators take.

Server maintenance

Another big advantage for static sites is the reduced amount of required server maintenance. With a typical CMS like Wordpress or Drupal, sysadmins will need to install and configure a scripting language runtime (like PHP), a webserver (like Apache), and a database server (like MySQL). Security patches and periodic software updates will also need to be run for each of these. With static sites, only a webserver to serve the static files is required. (It is also arguable that security of the server is improved with this simpler setup.)

Maintainability

Some scoff at the idea of building a static website because it sounds to the unfamiliar ear like writing static webpages individually by hand, which of course is a cumbersome task that content management systems were designed to overcome. However, the “static” part is simply the compile target. Static site generators allow web developers to build sites with familiar programming constructs, like DRY, logic and flow control, templating, etc.

Version control

Without the dependency on a database system, it is also much easier to keep the site’s content under revision control, depending on how the developer has chosen to deploy and publish to the site. This also means that content is more easily synced with code between different environments (i.e., development and production).

Concerns with static sites

The obvious concern with static sites is that they cannot serve dynamic content. However, there are ways to add common dynamic elements to the site without the need of a full-blown CMS. For example, the popular service Disqus provides a fully featured commenting system for a page, simply by adding a small JavaScript snippet. There are also services like Firebase that allow client-side applications to communicate directly with a database.

There are, of course, many cases where a static site is inappropriate. Any service where users log in to access their content is a common example. In these cases, one might consider using a static site for blogs or landing pages and minimize the the scope of the backend code to the core of the application itself.

Deploying and publishing content to static sites

Static sites can be deployed in a variety of ways. One of the simplest ways is to take the compiled output of the static site generator and drop it into an Amazon S3 bucket. As S3 (and similar services) are preconfigured to serve static files, there is no server setup required. Take one more step to put that bucket behind a service like Amazon CloudFront, and the site’s files are now served over CDN, with minimal effort!

Another noteworthy mechanism that works great for open-source sites is GitHub Pages, a free service offered by GitHub. GitHub Pages integrates automatically with one of the most popular static site generators, Jekyll, and so deploying and pushing updates to a site is as simple as git push. GitHub Pages are also served via CDN.

There are also great workflows that allow non-technical people to publish to a static site. For example, Contentful is a content management service that has fast, read-only APIs for retrieving content. Non-tech writers can log into Contentful to create the content, and the static site generator could be configured to receive updates from the API, compile the site, and deploy the changes automatically. A similar workflow based on syncing a Dropbox folder of markdown files with a static site generator could also work well. With the flexibility of static sites, teams can find a publishing paradigm that works well for them.

Conclusion

Static websites are a practical tool in a web developer’s tool belt. The simplicity of a static website can be a welcome replacement for complex content management systems.

Blissful Static Site Development with Jekyll, BrowserSync, and tmux

Sat, 20 Jun 2015 05:44:34 +0000

I was recently listening to the Shop Talk Show podcast where Chris Coyier shared a submission from a listener that outlined the development and deployment setup for her personal website. It involved using Dropbox to sync blog posts to a static site generator on her server and sounded pretty slick. I thought I would add to the conversation by sharing my setup for developing this site. These are the technologies that are used in concert:

GitHub Pages
Jekyll
BrowserSync
tmux
iTerm2

Overview

Here is a visual overview of the development setup, created with Lucidchart.

Further explanation of each component is below.

GitHub Pages

GitHub Pages is just about the easiest way to deploy a basic website these days. If you have a GitHub account (free), the process is simple:

Create a repository with a special name: <your username>.github.io (for example, mine is mjswensen.github.io for this website).
Add your website files (index.html, etc.) to the repository.
Commit and push. Within a few minutes (usually just seconds), your site will be live at http://<your username>.github.io/.

If you want a custom domain instead of the default, it’s easy to set that up, too.

The best part? It’s fast. GitHub distributes the content on GitHub Pages via CDN out of the box, so visitors to your website download your content quickly no matter where they are. One of my recent posts happened to be trending on Hacker News one morning and that page had about 7,500 views over the course of a few hours; the site was still responsive as ever during that time, despite the drastically increased load.

And it’s free. You really can’t beat that.

Jekyll

Jekyll is a static site generator, which—as the name suggests—makes creating static HTML sites a breeze. Jekyll is one of the most popular static site generators. This is due in part to the fact that it integrates with GitHub Pages. If you build your site with Jekyll, GitHub will detect that your site is a Jekyll site and will compile it for you when you push (as outlined above). So for development, one can install Jekyll and build the site locally, push and have GitHub build the live site, and not have to worry about keeping the compiled site files in source control or uploading them via FTP.

There are a lot of advantages to moving away from content management systems and toward static sites where possible. Increased site performance is the primary one (content management systems usually involve reading from a database, whereas static sites are simply files that can be quickly served from webservers like nginx that have been heavily optimized for that task). It’s also nice to keep content under version control rather than trying to sync databases across different environments.

(Sidenote: Among Jekyll’s many features, one of the most convenient is its native support for Sass. Sass makes writing CSS painless and fun, and the fact that Jekyll will compile the Sass sources automatically is a big plus.)

BrowserSync

While Jekyll by default has a built-in server enabled for testing as you develop, BrowserSync has some incredible features for developing for the modern web:

Live reloading when sources change
Synced page viewing and scrolling across multiple devices or browsers simultaneously
Great debugging features
Automatically go to local site in new Chrome tab on launch

So, while Jekyll watches my source files for changes and generates the site automatically, BrowserSync watches Jekyll’s output directory and pushes changes to the browser automatically. It makes for a great development workflow!

tmux

While starting Jekyll and BrowserSync is pretty simple via the command line, it is the same two commands and requires two terminal windows each time I want to write a new blog post or develop the site. This is where tmux comes in. tmux is a terminal multiplexer, which means that it allows for text-based windows and split panes within a single terminal window, among many other fantastic features.

The best part about tmux is that it is easily scriptable. So for developing this site, I’ve written a Bash script that sets up my tmux session, configures the windows and panes as I like them, and starts Jekyll and BrowserSync in separate panes. The script is pretty simple:

#!/bin/bash

SESSION="mjswensen"
PROJECT_PATH="/Users/mjswensen/Projects/other/mjswensen.github.io"
OUTPUT_PATH="$PROJECT_PATH/_site"

tmux new-session -d -s $SESSION -n "site" -c $PROJECT_PATH

tmux split-window -h -t $SESSION:0 -c $PROJECT_PATH
tmux split-window -v -t $SESSION:0.1 -c $OUTPUT_PATH

tmux send-keys -t $SESSION:0.0 "git status" enter
tmux send-keys -t $SESSION:0.1 "jekyll build --watch" enter
tmux send-keys -t $SESSION:0.2 "browser-sync start --server --files \"*.css, *.html\"" enter

tmux select-pane -t $SESSION:0.0

tmux -CC attach-session -t $SESSION

iTerm2

Finally, I use iTerm2 in place of the standard Terminal.app for Mac. iTerm2 has some amazing features and is a popular choice for terminal emulation among Mac users. The reason I like iTerm2 so much is for its deep tmux integrations. While tmux brings some great features to the terminal, certain common tasks—like switching between windows or copying text, or scrolling—involve cumbersome keyboard commands and workarounds. iTerm2, when attached to a tmux session with the special -CC command-line flag (as seen in the script above), converts tmux windows and panes to native iTerm2 tabs and panes. It sounds simple, but it really makes all the difference. It really is a great solution for tmux fans.

In the end, this is what the iTerm2 window looks like:

Thanks for reading!

Key Takeaways to Common CSS Questions

Fri, 12 Jun 2015 14:42:13 +0000

One of my goals for Q2 2015 was to answer ten CSS-related questions on Stack Overflow. Below is an outline of some of the key concepts I came across while doing so.

Preprocessor Compilation

This question regarded the relative “efficiency” of two comparable snippets of Sass code. What the original poster did not realize is that the differences were purely preferential, and that the two examples in fact compiled down to the exact same CSS code.

Key takeaway: Understanding how preprocessors behave is important for producing quality code. The best way to know what the compiled output of a preprocessor is to go back to the basics of CSS selectors, specifically compounding simple selectors (and sequences of simple selectors) together with combinators. Understanding combinators is the key to effectively using the popular preprocessors’ nesting and & syntax.

Parent Selector

In this question, the original poster was on a wild goose chase that most CSS developers have found themselves on at one point or another: trying to select a parent element based on whether or not it contains a given descendant. For example, all sections that contain an element with the metadata class, but not those that do not (proposed syntax: section < .metadata).

Key takeaway: Unfortunately, the parent selector does not yet exist, but may someday in a future CSS specification. There may be, however, alternate solutions to solving that problem, such as the use of psuedo-classes like :empty or :not().

The Box Model

In this question, the original poster was tripped up on how an element’s padding affects its position and size—a very common issue.

Key takeaway: A lack of understanding for the CSS box model is a common source of error for layout and alignment concerns. Also, the use of the box-sizing property can greatly simplify the reasoning behind an element’s computed size.

The `display` And `visibility` Properties

In this question, the original poster discovered that changing an element’s display property from none to block re-triggered any animations for that element. The solution was to toggle between the hidden and visible values of the visibility property instead.

Key takeaway: Animations do not play nicely with display: none; in general. The use of visibility: hidden; can sometimes help with this, but special care must be taken as there are differences in behavior and styling between these two property-value pairs. (e.g., visibility: hidden; maintains an element’s space in the flow of the web page while display: none; removes it from the flow. For this reason, in certain circumstances there will be performance gains from favoring visibility.)

SVG

SVG is an extremely powerful and open graphics format. It is closely related to HTML in that both are XML (SVG images are therefore quite compatible with web pages) and CSS in that SVG elements can be styled with CSS, just like HTML elements. The original poster of this question was simply not familiar with some of the SVG features used in the code. In this case, adding a class to the SVG element (and therefore being able to make specificity work to our advantage) was enough to accomplish the task.

Key takeaway: While there are plenty of graphical tools and libraries for manipulating SVG images, being comfortable in the source code of an SVG can be valuable. Some of the best references for SVG are found on the Mozilla Developer Network site. Sara Soueidan also has a lot of great content and research around SVG.

Practical Use Cases For The :empty Pseudo-class

Tue, 12 May 2015 04:17:54 +0000

At first, the :empty pseudo-class may not seem to be the most useful of the advanced selectors. However, there are situations in which :empty is the perfect tool for the job. Here are a couple of examples:

Tag/label manager UI

Say you were developing an application that allowed users to manage tags or labels (think Trello). It would be nice to allow users to add titles to their labels, but the labels should also be visually sufficient if no titles are added, like so:

You’ll notice that the tags without text are wider than they would be if they were simply an empty <span> with padding and a background color. The essentials of the code to achieve this is:

.label:empty {
  width: 1rem;
}

Simple, yet adds a bit of robustness to the design. I made the labels contenteditable and put it up on CodePen so that it can be played with:

Analytics dashboard UI

Another example use case would be a data collection user interface that hasn’t received any data yet. Suppose an application was tracking the conversion rate of an e-commerce site by geographical region, like so:

In the previous example, the elements for the USA and Canada metrics have text (“1.64%” and “0.53%”, respectively), while that of Mexico is empty. This is the relevant code:

.conversion-rate:empty::before {
  content: "No data";
  opacity: 0.25;
}

Here is a link to the live example. It’s a nice little trick that provides a better experience than simply leaving the space blank in the absence of data.

Conclusion

As web professionals, we take pride in making sure our designs look great no matter the circumstances—think responsive design, for example—and the :empty pseudo-class is another tool in our tool box to achieve that.

What other great use cases for :empty have you come up with?

The Power of Education: Truly Thinking

Mon, 27 Apr 2015 20:42:18 +0000

I very recently graduated from Brigham Young University with a master’s degree in Information Systems Management. In one of my final class sessions, a professor showed us this video and asked us to reflect on what our education means to us. As the video points out, we have the power to truly think, to choose what has meaning and what doesn’t in the mundane moments of everyday life. The video is made from a speech given ten years ago, but the message is a timeless gem.

How Personal Revelation Helps Us Prepare For Eternal Life

Fri, 10 Apr 2015 13:30:19 +0000

I had the opportunity to give a talk on this topic to a congregation of the Church of Jesus Christ in Provo, UT. The following is the transcript.

Good morning! My name is Matt Swensen. Today I will be talking about how personal revelation helps us prepare for eternal life. (Personal revelation is a process by which God communicates with us directly, leading and guiding our lives.)

I will start by sharing with you a weakness that I am working through. I tend to rely upon my own capacities more than I rely on the Lord, especially when it comes to solving problems or dealing with trials. What I have learned while preparing for this talk is that while our efforts to move forward and learn from our own experiences are an important part of our purpose—I’m not saying that we shouldn’t try to solve our own problems—learning how to rely on the Lord and follow personal revelation is even more important.

This is what then-Elder Packer (now President Packer) said about it in an October 1994 General Conference address:

Physically you can see with eyes and hear with ears and touch and feel and learn. Through your intellect, you learn most of what you know about the world in which we live…

But if you learn by reason only, you will never understand the Spirit and how it works—regardless of how much you learn about other things…

Your spirit learns in a different way than does your intellect.

And Elder Scott, in the April 2012 General Conference, said:

Our Heavenly Father did not put us on earth to fail but to succeed gloriously… Sometimes we unwisely try to face life by depending on our own experience and capacity. It is much wiser for us to seek through prayer and divine inspiration to know what to do.

Brothers and sisters, I know that we will be better off if we rely more on the Lord than on our own intellect. We can do this by seeking personal revelation from the Lord.

Personal revelation helps us prepare for eternal life because we learn how to follow the will of God, and therefore become one with Him. The Savior outlined this type of unity in His great Intercessory Prayer in the 17th chapter of John. Keep in mind that when He refers to “these” or “they,” He is referring to us—recipients of personal revelation. He said:

Neither pray I for these alone, but for them also which shall believe on me through their word;

That they all may be one; as thou, Father, art in me, and I in thee, that they also may be one in us: that the world may believe that thou hast sent me.

And the glory which thou gavest me I have given them; that they may be one, even as we are one:

I in them, and thou in me, that they may be made perfect in one; and that the world may know that thou hast sent me, and hast loved them, as thou hast loved me.

Put another way, eternal life is being one with God. Personal revelation helps us achieve that.

When we communicate with others, we get to know them better. The same is true with our communication with God. Personal revelation helps us know His will, His wisdom, and His personality. The concept of knowing God is an important part of our faith, as outlined in verse three of the same chapter of John:

And this is life eternal, that they might know thee the only true God, and Jesus Christ, whom thou hast sent.

In other words, personal revelation helps us prepare for eternal life because it helps us know God.

I have divided the rest of my talk into three short topics: (1) how to receive personal revelation, (2) the blessings of receiving personal revelation, and (3) the importance of recording personal revelation when we receive it.

How to Receive Personal Revelation

In the aforementioned talk, Elder Packer outlines the process by which we can elicit personal revelation. He breaks it down clearly into two basic steps.

Prayer

The first is prayer. We must use our agency (freedom of choice) to pray and ask. Elder Packer points out in his talk that the invitation to “ask and ye shall receive” (John 16:24) is one of the most common commandments in the scriptures. We need to humbly go before the Father in prayer and lay out our questions, asking for His divine help.

Study

After we pray, we must study the issue. The Lord expects us to put forth effort before He will give us the answer. Sometimes He answers by directing our study to find what we need. Usually, this means turning to the scriptures or to the words of the modern-day prophets.

Receiving the Revelation

The Lord will then communicate with us, according to His will and timeline. Elder Packer points out that when we feel the answers come, it is primarily a spiritual feeling. Occasionally the spiritual light is accompanied by physical sensations and emotional feelings (like warmth and peace).

A Personal Experience

One of the most distinct personal revelations I have received in my life was when I knew I was to marry Christine. We had been dating and communicating long-distance for a few months, and I had come to know that she embodied everything that was important to me in an eternal companion. I knelt in prayer, asking Heavenly Father if it was in line with His will that we be married. My mind and spirit filled with light and some specific words from my patriarchal blessing came to my mind—as if I had been looking at them on the page—affirming to me that I should move forward.

The Blessings of Receiving Personal Revelation

In addition to the blessing of preparing for eternal life, there are many other blessings that come with personal revelation.

Increased Confidence in God’s Love For Us and in His Caring For Us

For example, when Heavenly Father hears and answers our prayers, we gain an increase in our confidence that God loves us and is actively watching over us. We feel His love and we feel closer to Him. Our testimony that he is indeed our Father is strengthened. In the 14th chapter of 3rd Nephi, the Savior echoed to the Nephites the words he once gave to his disciples in His Sermon on the Mount:

Ask, and it shall be given unto you; seek, and ye shall find; knock, and it shall be opened unto you.

For every one that asketh, receiveth; and he that seeketh, findeth; and to him that knocketh, it shall be opened.

Or what man is there of you, who, if his son ask bread, will give him a stone?

Or if he ask a fish, will he give him a serpent?

If ye then, being evil, know how to give good gifts unto your children, how much more shall your Father who is in heaven give good things to them that ask him?

Strength to Move Forward

When we act upon the revelation we receive, we have more strength to move forward even when the way is difficult. This is because we know that we are in line with God’s will and we trust in His power to do all things. We are not aimlessly wandering, hoping that we made the right choice or are following the right path; we are progressing with confidence toward achieving eternal goals and becoming more like our Heavenly Father.

The Importance of Recording Personal Revelation When We Receive It

This strength and confidence relates directly to my last topic: the importance of recording personal revelation when we receive it. Christine and I have experienced this first-hand. As many of you have discovered or will discover, growing your family with children is a singular blessing that brings its own unique challenges. During those challenges, Christine and I have often looked back to the specific experiences when we received direction from the Lord regarding our family. Being able to read our own words about those sacred experiences has given us great strength.

I invite all of us to make a habit of always writing down our spiritual impressions. We will be so glad we did.

Not only will our journals give us strength in the days ahead, but they can benefit our future generations. When I gave a talk in this ward last year I shared a journal entry from one of my ancestors and how it strengthened my testimony. I have had several more of similar experiences since because of the diligence of my ancestors in writing in their journals.

Conclusion

Brothers and sisters, I know that Heavenly Father is there. I think that He is closer to us than we realize. He wants to communicate with us and has given us the pattern by which we can ask Him for help. I know that He loves us. In the name of Jesus Christ, amen.

Why Code Snobs Are Invaluable

Fri, 30 Jan 2015 20:50:44 +0000

Some argue that “code snobs” waste time on trivia. While I am sure this can be the case, I submit that their ideas and comments offer more benefit than cost in the long run.

I recently pushed a change at work that involved refactoring a few of our JavaScript classes and adding a couple of new ones. Nothing too out of the ordinary. Our development workflow requires a different engineer to code review any commits before they go on to the master branch (and eventually out to production). I felt good about the solution that I had come up with for the particular task I was working on.

The engineer that I had requested for the code review—who had recently reworked our Selenium testing framework and is an active proponent of code quality for our team—left a comment on our pull request system for a particular area of the code I was submitting. He suggested a slight change, merely that some of the classes I had implemented were not using the singleton pattern, while some of their analogous counterparts were, and that I should adjust them to better mirror that structure.

I was halfway through replying to the comment with reasons to just move forward and approve my pull request anyway when I realized that he was right. The classes really would be more semantic if they were singletons. I decided to take the additional 15 minutes to make the change.

I realize that whether or not my two small JavaScript classes were implemented as singletons probably has no real bearing on the reliability and performance of our large codebase. But small decisions like that add up, especially when they are made every day. Imagine how different your codebase would be if every programmer on your team pushed out the best quality code they could, every single commit, with unfaltering snobbery! Over the course of even a year, the difference would be significant.

Perhaps a “code snob” is simply the term lazy programmers use to describe their more disciplined peers. If that’s the case, I want to be one.

How Well Do You Know Your Programming Language?

Sat, 16 Aug 2014 05:48:17 +0000

I was listening to a podcast about Scala by Scott Hanselman and Dianne Marsh where programming languages were briefly compared to foreign languages. The idea stuck in my mind for the rest of the drive to work. I came up with the following scale that can be used to help self-assess one’s proficiency with a programming language.

Level	Programming Language	Foreign Language
1 (inexperienced)	You don't recognize the syntax, either because the language utilizes an unfamiliar paradigm or is from a different family of languages than what you are used to. The file extension might provide a hint—depending on how good your memory is.	You might be able to guess which continent this language is used in, but you wouldn't feel comfortable taking a stab at identifying the language with anyone listening.
2	You know what language it is, but the syntax feels quite uncomfortable (or even unintelligible).	You are able to identify the language based on the look of the alphabet, but phonetics, grammar, and general structure are still very foreign.
3	You understand the context in which the language resides and are able to hack together basic functionality by copying and pasting snippets from Stack Overflow.	You have memorized a few basic phrases for ordering food and asking where the bathroom is.
4	You can make things work, but the level of code quality is such that it pains others (and future you) to read. You don't yet enjoy writing code in the new language.	Though still fragmented, you have a basic knowledge of the structure of the language and can form a basic sentence on the fly, albeit grammatically unsound.
5	You write code at an acceptable level. It's no longer completely written in the paradigms of languages you are more comfortable with. You are starting to feel comfortable in the new language.	Though you are still simply speaking your native language using foreign words some of the time, you are able to carry on a conversation.
6	You are adopting more and more of the idioms of the new language. You are embracing the best practices and avoiding the pitfalls and code smells of the new ecosystem that is becoming more familiar to you by the day. You creatively solve problems in the way that only the new language would.	You are starting to think and dream in your new language. You wish there were ways to express certain ideas in your native language that are only achievable in the foreign language.
7 (proficient)	Writing code the idiomatic way for the new language is natural and comfortable. Reading quality work by others is easy and pleasant. The new language has become your go-to for thinking through problems. You even contribute to the community and help spread enthusiasm for the language.	Your command of the new language is such that you understand the subtle nuances of poetry. You are even capable of writing poetry yourself, and occasionally come up with something brilliant, indistinguishable from that of a native speaker of the language.

Where you do fall on the scale for the languages you work in every day?

Configurations for a Friendlier tmux Status Bar

Sat, 09 Aug 2014 23:22:00 +0000

At work, the engineering team uses tmux to manage the several instances of the services we run to develop the Lucid suite locally. It is a phenomenal terminal management system and the best part is that it is highly configurable. If you enjoy working in the command-line and haven’t checked it out yet, you need to!

This is what the default status bar looks like with a few windows open:

I added a few config options to my ~/.tmux.conf file to make the status bar easier to read:

set-window-option -g status-left " #S "
set-window-option -g status-left-fg black
set-window-option -g status-left-bg white

set-window-option -g status-right " %H:%M %d-%b-%y "
set-window-option -g status-right-fg black
set-window-option -g status-right-bg white

set-window-option -g window-status-format " #I: #W "

set-window-option -g window-status-current-format " #I: #W "
set-window-option -g window-status-current-fg green
set-window-option -g window-status-current-bg black

This is what the status bar looks like now:

(Terminal theme is the beautiful Tomorrow Theme by Chris Kempson.)

Update 5/16/2015

I still love and use tmux every day. I have recently moved from the default Terminal.app to the fantastic iTerm2.app, in part because it has wonderful tmux integrations. In a nutshell, it is possible to attach to a tmux session with a special command-line flag that uses native iTerm panes/tabs/windows in place of the tmux panes and windows. This allows for easier scrolling, better copy/pasting, and better mouse integrations (i.e., switching between panes). It has loads of other features as well. I can't recommend it enough.

Update 8/26/2017

It's been just over three years since I wrote this post, and I still use tmux every day. My custom tmux status bar theme has largely remained the same as outlined above, too. For the rest of my development environment, I recently built a tool called themer that greatly simplifies keeping a consistent theme between editors, terminals, other apps, and even desktop wallpaper. Check out themer here.

Options For Git Status in Shell Prompt

Fri, 08 Aug 2014 04:01:00 +0000

When it comes to customizing your Bash prompt to give you more information about the status of a Git repository, there are a lot of options out there. This post covers using the built-in options that ship with Git, as opposed to a third-party alternatives like this or this.

Once Git is installed, all you need to do is:

Load the git-prompt.sh file (comes with Git) in your ~/.bashrc or ~/.profile file
Add $(__git_ps1) somewhere in your bash prompt variable (look for PS1 in that same files)

The current branch name will always be displayed. However, there are a few other options you can use to add more than just the current branch name to your prompt. The available configurations are not easily Google-able, so I sifted through the source and listed them here. The available options are:

Option	Value	Description
`GIT_PS1_SHOWDIRTYSTATE`	any nonempty value	shows `*` or a `+` for unstaged and staged changes, respectively
`GIT_PS1_SHOWSTASHSTATE`	any nonempty value	shows `$` if there are any stashes
`GIT_PS1_SHOWUNTRACKEDFILES`	any nonempty value	shows `%` if there are any untracked files
`GIT_PS1_SHOWUPSTREAM`	`auto`	shows `<`, `>`, `<>`, or `=` when your branch is behind, ahead, diverged from, or in sync with the upstream branch, respectively
	(alternatively to `auto`, a space-delimited list of the following options)
	`verbose`	show number of commits ahead/behind (+/-) upstream
	`name`	if verbose, then also show the upstream abbrev name
	`legacy`	don't use the '--count' option available in recent versions of git-rev-list
	`git`	always compare HEAD to @{upstream}
	`svn`	always compare HEAD to your SVN upstream
`GIT_PS1_DESCRIBE_STYLE`	(determines the style of the current commit when in a detached HEAD state, when set to one of the following values)
	`contains`	relative to newer annotated tag (e.g., `v1.6.3.2~35`)
	`branch`	relative to newer tag or branch (e.g., `master~4`)
	`describe`	relative to older annotated tag (e.g., `v1.6.3.1-13-gdd42c2f`)
	`default`	exactly matching tag

Here’s how you might put it all together in your ~/.bashrc or ~/.profile file:

# First, load up the git-prompt.sh file that ships with Git. You
# might consider copying it to your home folder first. On my Mac
# OS X (Mavericks) setup, the file resides in
# /Applications/Xcode.app/Contents/Developer/usr/share/git-core/.
test -f ~/git-prompt.sh && . ~/git-prompt.sh

# Then, set the options as desired. Remember that the current
# branch name is displayed no matter what.
export GIT_PS1_SHOWSTASHSTATE=true
export GIT_PS1_SHOWDIRTYSTATE=true
export GIT_PS1_SHOWUNTRACKEDFILES=true
export GIT_PS1_SHOWUPSTREAM="auto"

# Finally, add $(__git_ps1) to the prompt variable. That's it!
PS1="\u@\h \w\$(__git_ps1) \$ "

Here is how the prompt might look:

How the Gospel of Christ Relates to Those Who Passed On Without It

Sun, 08 Jun 2014 17:50:00 +0000

I had the opportunity to give a talk on this topic to a congregation of the Church of Jesus Christ in Orem, UT. The following is the transcript.

Brothers and sisters, can you think of a time when you were in a sticky situation? A situation where you needed to be in two places at once, or where you just couldn’t get somewhere fast enough? Or you just couldn’t do something by yourself? Were you able to call a close friend or family member to help? Do you remember the relief you felt as they came to the rescue? Do you remember how nice it was to have the weight lift off your shoulders as everything worked itself out? Do you remember how good it felt to have that friend or family member cheerfully respond to your plea for help, even though you knew it wasn’t convenient for them?

I have the opportunity to speak today about one of the great messages of hope and rescue that the gospel brings. It’s an aspect of the gospel that no other church has. It also sometimes gets overlooked in our church and is one that I personally take for granted. The topic is family history and performing ordinances vicariously for those that have already passed on. It fits perfectly with what Courtney and Cedar just spoke about: families and love.

For those of you who are visiting with us today or who are unfamiliar with family history, it is the process of gathering information about our ancestors and finding out who they are so that we can vicariously perform sacred ordinances in temples as proxies for them. These ordinances allow them to enjoy the blessings of the gospel in the afterlife even though they didn’t have an opportunity to receive them when they were alive.

The Prophet Joseph Smith said:

…suppose the case of two men, brothers, equally intelligent, learned, virtuous and lovely, walking in uprightness and in all good conscience, so far as they have been able to discern duty from the muddy stream of tradition, or from the blotted page of the book of nature.

One [of them] dies and is buried, having never heard the Gospel of reconciliation; to the other the message of salvation is sent, he hears and embraces it, and is made the heir of eternal life. Shall the one become the partaker of glory and the other be consigned to hopeless perdition? Is there no chance for his escape?

Outlined here is one of the great questions of life: is there no hope for those who pass away without having had a chance to embrace the gospel of Jesus Christ? Joseph explains that there is a way for this first brother, and that it is through the ordinances performed by proxy in the temple. Though God is a just God in that each and every person must adhere to His commandments to receive the saving ordinances, He is also merciful, loving, and kind, not condemning those who never had an opportunity to do so before their sojourn on earth was through.

Of this, Joseph aptly said, “This doctrine appears glorious, inasmuch as it exhibits the greatness of divine compassion and benevolence in the extent of the plan of human salvation…This glorious truth is well calculated to enlarge the understanding, and to sustain the soul under troubles, difficulties and distresses.”

Brothers and sisters, I know that Heavenly Father loves us. Not only because of this beautiful doctrine, but because He has revealed it to us so that we may have peace and hope concerning our brothers and sisters who leave this life without a knowledge of Him.

One of the most amazing parts of this doctrine is that we have the power to help our ancestors in this way. By performing this work in the temple we are becoming “saviors on Mount Zion.” Note that the s in saviors is lowercase, for there is only one Savior; however, we are indeed performing a necessary work for our ancestors that they can no longer perform for themselves.

As Voltaire (and later a wise comic book character) once said, “With great power comes great responsibility.” It is up to us to perform this ever-important work. Joseph warned: “Those Saints who neglect it in behalf of their deceased relatives, do it at the peril of their own salvation.” This helps us realize that performing vicariously these saving ordinances is not just for our ancestors’ benefit, but also for our own.

Elder David A. Bednar, in an October 2011 General Conference address, promised the following:

As you respond in faith to this invitation, your hearts shall turn to the fathers. The promises made to Abraham, Isaac, and Jacob will be implanted in your hearts. Your patriarchal blessing, with its declaration of lineage, will link you to these fathers and be more meaningful to you. Your love and gratitude for your ancestors will increase. Your testimony of and conversion to the Savior will become deep and abiding. And I promise you will be protected against the intensifying influence of the adversary. As you participate in and love this holy work, you will be safeguarded…throughout your lives.

The benefits of family history work are not only spiritual. The following is an excerpt from an article in the New York Times by Bruce Feiler entitled “The Family Stories that Bind Us,” published March 15th, 2013:

…my dad called me to his bedside. There was a palpable sense of fear I couldn’t remember hearing before.

“Our family’s falling apart,” he said.

“No it’s not,” I said instinctively. “It’s stronger than ever.”

But lying in bed afterward, I began to wonder: Was he right? What is the secret sauce that holds a family together? What are the ingredients that make some families effective, resilient, happy?

Myth-shattering research has reshaped our understanding of dinnertime, discipline and difficult conversations. … [In this research] a surprising theme [has] emerged. The single most important thing you can do for your family may be the simplest of all: develop a strong family narrative.

I first heard this idea from Marshall Duke, a colorful psychologist at Emory University. In the mid-1990s, Dr. Duke was asked to help explore myth and ritual in American families.

“There was a lot of research at the time into the dissipation of the family,” he told me at his home in suburban Atlanta. “But we were more interested in what families could do to counteract those forces.”

Around that time, Dr. Duke’s wife, Sara, a psychologist who works with children with learning disabilities, noticed something about her students.

“The ones who know a lot about their families tend to do better when they face challenges,” she said.

Her husband was intrigued, and along with a colleague, Robyn Fivush, set out to test her hypothesis. They developed a measure called the “Do You Know?” scale that asked children to answer 20 questions.

Examples included: Do you know where your grandparents grew up? Do you know where your mom and dad went to high school? Do you know where your parents met? Do you know an illness or something really terrible that happened in your family? Do you know the story of your birth?

Dr. Duke and Dr. Fivush asked those questions of four dozen families in the summer of 2001, and taped several of their dinner table conversations. They then compared the children’s results to a battery of psychological tests the children had taken, and reached an overwhelming conclusion. The more children knew about their family’s history, the stronger their sense of control over their lives, the higher their self-esteem and the more successfully they believed their families functioned. The “Do You Know?” scale turned out to be the best single predictor of children’s emotional health and happiness.

…Dr. Duke said that children who have the most self-confidence have what he and Dr. Fivush call a strong “intergenerational self.” They know they belong to something bigger than themselves.

…The bottom line: if you want a happier family, create, refine and retell the story of your family’s positive moments and your ability to bounce back from the difficult ones. That act alone may increase the odds that your family will thrive for many generations to come.

I believe that there is eternal truth at the heart of these doctors’ research that can be summarized by Malachi chapter four, verse six, which says: “And he shall turn the heart of the fathers to the children, and the heart of the children to their fathers, lest I come and smite the earth with a curse.”

Perhaps the greatest blessing, though, is the joy we feel when we participate in the Lord’s work. President Joseph F. Smith once said, “Through our efforts in their behalf their chains of bondage will fall from them, and the darkness surrounding them will clear away, that light may shine upon them and they shall hear in the spirit world of the work that has been done for them by their children here, and will rejoice with you in their performance of these duties.”

We taste of the joy that President Joseph F. Smith is talking about when we do missionary work. In fact, family history work can be considered missionary work for the dead. Both involve bringing the gospel to those who did not have it before. Both involve some sort of sacrifice on our part. Both involve faith.

This month’s special message from President Monson (the current prophet and president of the Church) is entitled “Hastening the Work.” When I think of hastening work, I think about working extra hard at the end of the day to make sure that everything is done; I think about expending extra effort in the ninth inning of a close baseball game between rival teams; I think about scrambling to finish an exam before the exam center closes. The Lord has said through His prophets that He is hastening His work in these times. This is not limited to full-time missionary service. President Monson reminds us that “The Lord has never…indicated that His work is confined to mortality. Rather, His work embraces eternity.” Temple ordinances for the dead, therefore, are a vital part of this work.

If you’ve never done family history work before, that’s OK. Neither have I. Now is a great time to start. President Monson said:

We are going to make mistakes, but none of us can become an expert in family history work without first being a novice. Therefore, we must plunge into this work, and we must prepare for some uphill climbing. This is not an easy task, but the Lord has placed it upon you, and He has placed it upon me.

As you pursue family history work, you are going to find yourself running into roadblocks, and you are going to say to yourself, “There is nothing else I can do.” When you come to that point, get down on your knees and ask the Lord to open the way, and He will open the way for you. I testify that this is true.

The Lord has already provided us with many valuable resources to aid in His work. The Church’s familysearch.org website is a wonderful place to start. Within minutes after logging in, I was reading stories written by my ancestors, seeing their pictures, and realizing that they are real people who had lives and experiences just like we do. This morning I happened upon an experience written by my great-grandfather, George Samuel Romney, that recounted one of his brother’s journeys through the Mexican wilderness. This brother, Miles Archibald Romney, befriended a dog who would not stop following him. As he camped for the night and slept, he awoke to the growling of the dog and discovered that there was a thief approaching him with “a huge dagger with which he expected to strike the deadly blow.” Miles quickly readied his rifle and warned the intruder that he would defend himself if necessary. Frightened, the thief fled. The story concludes:

Miles, when he was left alone with the dog he gave him a fond caress while tears of gratitude glistened in his eyes there in the moonlight. The attempt of the bandit had been frustrated and a life had been saved by the growl of a dog. … [Upon resuming his journey in the morning] he cast a backward glance [and] to his astonishment the dog could not be seen. For several miles he followed back the trail but his faithful friend could not be found. As mysteriously as the animal had come into the life of the traveler did it pass out again. Surely, thought my brother as he pushed on toward home there is an unseen power protecting the lives of men from dangers of which they are unaware…

My faith was strengthened by reading this story. And thanks to modern technology, with a few clicks of the mouse I was able to see that all the temple work for Miles had been completed a few years ago.

Our ancestors need our help. President Monson said, “We, as spirit children of our Heavenly Father, were sent to earth at this time that we might participate in hastening this great work… Our job is to search out our dead and then go to the temple and perform the sacred ordinances that will bring those beyond the veil the same opportunities we have.”

If you’d like to learn more about family history, I encourage you to attend the Family History Sunday School class that starts next week.

Brothers and sisters, though I am very new to family history work, I can already testify of the additional blessings we will receive and will allow our ancestors to receive if we participate. I know that the plan of salvation is a selfless plan of love. I know that Jesus Christ is our Savior. In his name, the name of Jesus Christ, amen.

What Really Matters

Thu, 24 Apr 2014 14:29:00 +0000

When life’s challenges affront us, the superfluity of daily life suddenly loses its meaning.

My wife and I are the parents of one child, a nearly two-year-old boy. He is our first child, and I am therefore a little clueless when it comes to parenting (my wife is much further along than me in that regard). This week he managed to come down with what was later found to be a gastrointestinal bug of some sort, with an ear infection and cold on top of that. When he woke up with a 105° fever, we rushed him to the pediatrician’s office. He was dehydrated, and was admitted to the hospital that night. Since this was our first bout with any health-related issues for our son, one can hopefully understand that we felt anxious and worried. Fortunately, after taking in some fluids intravenously he began to recover without a problem. The point of the story is not the ending—which, thankfully, was a happy one—but what happened during the difficult experience.

When life gets challenging, I’m convinced that we need at least three things to get us through:

Family/close friends
A close-knit community
Hope that things will turn out

Family/Close Friends

We were overwhelmed by the amount of love and support we felt when our family and friends caught wind that we were in the hospital with our son. Upon arriving home, we found that a group of our close friends had cleaned and organized our entire apartment! My sister showed up unannounced a few hours later with dinner. Some other friends, knowing that we would be surely taken care of, decided to leave a half-dozen of my favorite Krispy Kreme donuts with a note to let us know they were thinking about us. You can imagine how we felt!

A Close-knit Community

The Church of Jesus Christ serves my family well in this regard. Leaders of our local congregation organized volunteers to bring us dinner for three nights following our return home from the hospital. When we attended our church meetings that Sunday, our friends at church showed genuine concern for our well-being and were relieved to hear that everything was OK. Since it is a global church, we know that no matter where we may relocate to in the future there will be a warm community there to welcome us.

Hope

This is perhaps the most important factor to our ability to handle life’s curve balls. For me, hope comes from my belief that I will be able to be with my family in the afterlife. I knew that no matter what happened to my precious baby son, he is my son both in life and after death. This is possible through Jesus Christ, and brings me great peace each day. The following Easter-themed video shows why we can have hope in Jesus Christ:

I encourage any seeker of peace and comfort to be sure that these three anchors are intact before pursuing any other endeavor.

Lucidpress: Publishing for Web and Print

Mon, 30 Dec 2013 21:21:00 +0000

Lucidpress is a new cloud-based-yet-desktop-caliber publishing application. If you’re a designer or involved with a small- or medium-sized business, you should probably check it out—it’s free during beta. There’s also an interactive demo.

Here’s a short introduction:

Check out what others are saying about Lucidpress:

TechCrunch — Lucidpress Launches Web-Based Design And Publishing App For Print And Online
The Next Web — Lucid Software brings the power of desktop publishing to the Web with Lucidpress, now in beta
PC World — Lucidpress: drop-and-drag publishing app simplifies document design
AppStorm Web — Lucidpress Brings Advanced Page Layout Tools to the Browser
VentureBeat — Underdog Lucid takes on Adobe, Microsoft with free design app
About.com — Lucidpress Slick Web-based Design App for Novice Users
PC World — Lucidpress review: Free beta makes typesetting simple, accessible, and fun
The Red Ferret — Lucidpress – superb new free collaborative web based layout and design application does it all
AddictiveTips — Lucidpress Is A Collaborative Web-Based Alternative To Adobe InDesign
FreeTech4Teachers.com — Collaboratively Create Multimedia Documents With Lucidpress
MarketingTechBlog.com — Lucidpress: Collaborative Online Print & Digital Publishing
EducatorsTechnology.com — Lucidpress: A Good Real-time Collaborative Tool for Teachers and Students
CreativePro.com — Design for Print and Digital Publishing With Lucidpress
PubExec.com — Drag-and-Drop Software Makes Publishing Accessible
MakeUseOf.com — Lucidpress: The Free Online InDesign Alternative For Your Creative Needs

Well, what are you waiting for? Go check it out!

Basic Beliefs of the Church of Jesus Christ

Sun, 03 Nov 2013 15:13:00 +0000

According to one of the Church’s official websites:

The Church of Jesus Christ of Latter-day Saints is the official name of the religion commonly called the Mormon Church. We believe first and foremost that Jesus Christ is the Savior of the world and the Son of God.

The story behind the Church is remarkably simple and powerful. Be sure to check out a brief history of the Church and a succinct description of the Church’s core doctrines. Good stuff.

CSS-only Text Gradients

Tue, 08 Oct 2013 01:52:00 +0000

The things you can do with CSS these days are amazing. I was inspired by the beautiful Jekyll logo and set out to see if I could do something similar using only CSS.

This is the look I was going for:

I was excited to find on my first Google attempt a succinct post by the awesome Chris Coyier and I had achieved the desired effect in minutes. I thought it would be nice for a new project I’m working on called Scribbli.

Here is the complete Sass code:

$yellow: hsl(52, 80%, 53%)
h1
  color: $yellow// Fallback
  background: -webkit-linear-gradient(lighten($yellow, 20%), $yellow)
  -webkit-background-clip: text
  -webkit-text-fill-color: transparent
  text-shadow: 0 1px 1px hsla(0, 0%, 0%, 0.15)

And this is the end result for Webkit browsers (Chrome, Safari, Opera):

Breakdown

I thought we could take a closer look at what is going on here. First, let’s take a look at the fallback for non-Webkit browsers:

$yellow: hsl(52, 80%, 53%)
h1
  color: $yellow// Fallback

This gives us a simple text color with no effect. Not as cool as the detail we get with the gradient and the shadow, but good enough for a fallback.

The trick is in this next part. We set a background gradient on the entire h1 element, but we restrict the visibility of the gradient to the form of the text! We also need to make the text transparent so that the gradient isn’t hidden by the flat yellow fallback we set earlier.

$yellow: hsl(52, 80%, 53%)
h1
  color: $yellow// Fallback
  background: -webkit-linear-gradient(lighten($yellow, 20%), $yellow)
  -webkit-background-clip: text
  -webkit-text-fill-color: transparent

Note that we can use some nifty Sass functions to calculate the color stops for the gradient with minimal effort. Also note that for the background gradient, we are only using the -webkit- prefix and omitting the prefixes for the other browsers. This is because the text-fill-color is only currently supported in Webkit and we don’t want the background gradient there if the rest of it doesn’t work.

Cool. We’re almost there. Last thing to do is to add a little shadow to give the text some depth. Adding a text shadow to transparent text is different than the usual text shadow effect, because you can see the entire shadow under the text. For example: this is what the shadow looks like if we remove the background clipping mask:

Anyway, putting it all together again:

$yellow: hsl(52, 80%, 53%)
h1
  color: $yellow// Fallback
  background: -webkit-linear-gradient(lighten($yellow, 20%), $yellow)
  -webkit-background-clip: text
  -webkit-text-fill-color: transparent
  text-shadow: 0 1px 1px hsla(0, 0%, 0%, 0.15)

Even though the shadow drastically affects the apparent colors of the text since it is fully visible, it actually gives a nice embossed effect with the slight vertical offset. Once again, here is a screenshot of the final result; fully selectable, SEO-friendly text!

Additional Resources

Here is related and more in-depth article from Chris Coyier.

The Psychology Behind Open Source

Thu, 03 Oct 2013 15:30:00 +0000

This video is seriously cool. I’ve always wondered what motivates people (including myself) to contribute to the open source community. Dan Pink hits the nail on the head and the RSA animation drives the point home.

Git

Mon, 26 Aug 2013 14:10:00 +0000

What better topic for my first post than my favorite piece of software? This post is intended for the budding programmer who is ready to take their productivity to the next level. Git is one of the best ways to do just that.

Git has many features and a comprehensive review of any one of them is far beyond the scope of this post. Instead, we will cover the basic idea behind Git and why you should use it if you don’t already.

What is Git?

Git is a distributed source code version control system. It keeps track of the revision (change) history for your code, recording snapshots of your codebase’s history while you work. It is also a powerful tool for collaborating with other developers on a project. If you’ve never used Git before, you might think that you don’t need it—we’ll get to that in the next section.

Why use Git?

These are my top reasons to use Git:

Increased productivity
Better collaboration
Automatic redundancy

1. Increased Productivity

Have you ever been writing a program and realized that you broke something that worked previously, but have no idea how many changes you have made since it stopped working? You then begin a frantic series of undos in hopes to get your program back to a working state. (And if you’re lucky enough to find one, you have to redevelop the progress you just undid.)

There’s a better way.

With Git, you periodically commit your program as you develop. That way, when you’ve made some progress, you can commit your code and then move forward knowing that if something goes wrong you can always safely revert to a previous state. You can even delete files and Git will re-add them if you tell it to.

2. Better Collaboration

Git is the go-to standard for collaborative coding. Often there will be a designated server to host a Git repository that developers of a team will pull from and push to. Git makes it easy to develop different features simultaneously and even merge conflicts where necessary. One of the most popular hosted Git solutions is GitHub, which has a special focus on highly collaborative, open-source software.

3. Automatic Redundancy

One significant advantage of Git is that if your team’s central Git server were to go down, each computer that cloned the repository has a full backup of the code including all of its history. Team members could then push and pull code from each other until the issue with the server could be resolved. This is not possible with some other version control systems.

Conclusion

Git is a powerful tool to add to your toolkit. Learning it is an investment that is sure to pay off.

Additional Resources

There is a great (free!) book about Git called Pro Git which gives a thorough explanation of Git usage for all experience levels. It’s available in various formats and languages. I would recommend going there next!

mjswensen.com

Rejoicing in His coming

Intro

Why we rejoice

A personal experience

How we rejoice

A Jewish example

A Latter-day Saint perspective

A personal experience

Conclusion

Clean + Format: a UX pattern for high-quality user input fields

Secret sauce

Example: currency field

Precise semantics of clean() + format()

Conclusion

The single most important factor that differentiates front-end frameworks

Major frameworks compared

React

Angular

Vue

Svelte

So, what?

How to set up a WireGuard VPN for personal use

Step 1: spin up and connect to your cloud server

Step 2: install WireGuard

Step 3: generate a key pair for your VPN server

Step 4: create your server configuration file

Step 5: configure IP forwarding

Step 6: allow UDP traffic

Step 7: configure the WireGuard server to start on boot

Step 8: generate keys for clients

Step 9: configure clients

Cascade layers, subgrid, and container queries: What's new in CSS

Cascade layers in CSS

Why use cascade layers in CSS?

Syntax

When can I use cascade layers in CSS?

One last !important note

Introducing CSS’s subgrid

When can I use subgrid?

Mastering container queries in CSS

When can I use container queries?

Conclusion

Extending object-like types with interfaces in TypeScript

What are interfaces?

Interfaces vs. types

Expanding interfaces in TypeScript

Option 1: Declaration merging

Declaration merging to wrangle disparate user preferences

Option 2: Extending interfaces in TypeScript

Extending interfaces to form a type-safe global state store

Extending types

Conclusion

How to develop over HTTPS on localhost

Step 1: Generate a self-signed SSL certificate

Step 2: Install and trust the certificate

Step 3: Configure your development server to use the certificate and private key

Additional reading

Mastering mapped types in TypeScript

Why use mapped types in TypeScript?

Foundational concepts of mapped types

What is a mapped type?

Indexed access types in TypeScript

Index signatures

Using union types in TypeScript

Using the keyof type operator

Mapped types: a real-world example

Bonus: a reusable formatter type with generics

Conclusion

How to set up a simple web server development container for VS Code

Step 1: define development container in a Dockerfile

Step 2: configure VS Code to utilize our image

Step 3: profit

Using tsm as a shebang interpreter in TypeScript

Using tsm as a shebang interpreter in TypeScript

What is tsm?

Should you use tsm?

The disadvantages to tsm

Using tsm

1. As a replacement for the node executable

Precise semantics of `clean()` + `format()`

Cascade layers, `subgrid`, and container queries: What's new in CSS

One last `!important` note

Introducing CSS’s `subgrid`

When can I use `subgrid`?

Using the `keyof` type operator

1. As a replacement for the `node` executable

3. Using the `--require` or `--loader` hooks

`create-react-app` and `react-scripts`

Option 2: Use message contents with `options` object

Option 3: Use an `options` object

Implementing sub-components and an `App` component

`EnhancedMultiSelect`

`EnhancedMultiSelectOption`

`App`

`enhanced-multi-select.component.ts`

`enhanced-multi-select-option.component.ts`

`app.component.ts`