DEV Community: John Woodruff

PCIe Passthrough with Cloud-Init in Proxmox VE

John Woodruff — Sun, 30 Jul 2023 05:07:16 +0000

As I wrote about in my last post I have been diving into the world of homelabs and the fun and sometimes frustrating world of hosting your own services on your own hardware in your basement. I have been using Proxmox VE as my hypervisor of choice and have been loving it. That being said there are often times where I need to cobble together information from various sources to figure something out, whether it be the Proxmox forums, blog posts, or YouTube videos by a variety of homelabbers.

I recently purchased a used Nvidia Quadro P2000 GPU on Ebay for my server to utilize for Plex hardware transcoding as my server's CPU doesn't have an iGPU so watching stuff on Plex always ended up being endless buffering. I finally got it this last week and popped it in my server and began the long arduous task of figuring out how to utilize PCIe Passthrough in Proxmox to be able to utilize that GPU in my Plex virtual machine. Thankfully, there are some excellent tutorials out there on the subject, including this one by Craft Computing which got me 90% of the way there.

The Problem

I will fully admit that this is a problem of my own making. I very recently followed this tutorial by TechnoTim on using cloud-init in Proxmox to create virtual machines using Ubuntu's cloud images. Super awesome, I love the idea, and so naturally I had to set up Plex using a new cloud-init template. It was all going swimmingly until I tried to add my GPU to the VM in Proxmox, and suddenly when I tried to boot the VM it would just hang forever.

Most other smart people probably would've just said "no worries, I'll just use Plex in a VM that doesn't use cloud-init and call it a day" but instead I decided I would rather spend hours diving down rabbit holes to figure it out. Thankfully, in combination with multiple forum threads, blog posts, random videos, and super friendly community members in the TechnoTim Discord, I was able to get it working.

The Solution

The above tutorial is fantastic for setting up an awesome, clean, usable cloud-init template. I'm going to outline the changes I made that differ from that setup so that anyone else having this issue can clearly see the changes I made and hopefully get it working for themselves. The super short answer is that I needed it to be a UEFI boot setup with a few related changes to allow GPU passthrough, but here are the specific details.

The first issue is that when I was setting up the cloud-init drive rather than using ide2 I needed to use scsi1. I got that information from this Proxmox Forum thread comment So I ran the following (replacing {VMID} with my actual VMID):

$ qm set {VMID} --scsi1 local-lvm:cloudinit

Once I finished the commands in the above tutorial, I made some further changes to the VM before making it a template. The first is that I changed the BIOS to OVMF (UEFI). In order to support this, I needed to add an EFI Disk. I added that from the hardware menu, selected my storage target, and then SUPER IMPORTANTLY you need to UNCHECK the "Pre-Enroll keys" checkbox. This is a confusing name but basically this disables Secure Boot. If you have this enabled, then your Nvidia drivers won't work. I spent a substantial amount of time trying to figure out why my Nvidia driver wasn't working, and it wasn't until a super friendly person in TechnoTim's Discord server pointed me to that setting that I got this all working.

Another change I needed to make in order to be able to correctly pass through the GPU is in the hardware menu in Proxmox, "Machine" was set to the default of i440fx, and it needed to be set to q35. That would allow me to select the "PCI-Express" checkbox when adding a GPU via the Add PCI Device menu. I then had my virtual hardware set up so I could create a template from this VM.

Finally, once I had booted a fresh VM from the above template, I had some annoyance getting the Nvidia drivers installed. In the end, as I mentioned above, it was simply because I didn't have my Secure Boot disabled, but I was able to find an easier way to install Nvidia drivers than downloading the .run file and installing it manually. You can merely search apt for nvidia drivers by running apt search nvidia-driver which should list a large number of driver versions. You install the version your card requires, which you can find out by going to Nvidia's website and look up your card to see the version of the driver it needs to use. In my case it was version 535, so I very easily installed the drivers by using the following command:

$ sudo apt install nvidia-driver-535 nvidia-dkms-535

At this point everything worked beautifully! I was able to pass through my GPU, got it hooked up to Plex, and tested it to see the minimal CPU usage and hardware GPU transcoding in action!

Conclusion

Sometimes virtualization can be intimidating, frustrating, and difficult to figure out. On the other hand, it's very rewarding when you're able to get something working that has been troublesome for you. In this case I am super excited to be able to better utilize my Plex installation to watch my content, and while it was tough to get it working just right, I now understand a lot more around virtualization, cloud-init, and UEFI. That's the whole point of my homelab. Besides the fun I have messing around with stuff, I have already learned a ton about technology that has helped me both personally and in my career.

My Homelab

John Woodruff — Sun, 22 Jan 2023 04:30:02 +0000

I have a variety of hobbies, but the most obvious one is playing around with fun technologies. This applies not only to software, which I obviously write for a living and for enjoyment, but also to hardware. Ever since I took apart my parents' VHS player to see how it worked (RIP that VHS player 🪦) I have loved tinkering with hardware, and have since then built multiple PCs, wired my home for ethernet, installed security cameras, and more. The hardware projects I've most recently spent my time doing has been assembling my homelab in my basement, and that's what this post is about.

What is a homelab?

Before we dive into my specific homelab, we should cover what a homelab is for those who have never heard the term. It's a very broad inclusive term that refers to some sort of setup in your house that you can use to tinker, mess around with software or hardware, and generally experiment in the safe confines of your own home and network. This homelab can be as tiny as a single Raspberry Pi or old laptop, to something as big as a Home Data Center. The foundational concept is the same, however, it's some place at home to be able to mess around with tools and technologies for the purposes of learning and fun. The great thing is that you don't have to have a lot of money to build a lot of infrastructure, you can easily use an old machine you have lying around.

What can I do with a homelab?

You can do a lot with a homelab. Anything you want that your hardware can handle, which is actually probably more than you think. Raspberry Pi's are surprisingly capable little devices, and even really old hardware can run a lot of open source software on Linux. There are so many common homelab projects and ideas you can find on the internet. A few include:

Setting up Pi-hole for network-wide adblocking
Running a Plex media server to host your own media
Set up a Raspberry Pi with RetroPie for retro gaming
Home automation with Home Assistant or Homebridge
Custom code you write yourself to do whatever you'd like!

There are so many other things you can do, that list barely scratches the surface of the possibilities. Just find something that sounds cool and get started. There are likely even tutorials that walk you through it!

My homelab hardware

This is my current homelab. I've been working on my homelab for a while, and this is by no means what I started out with. If you're interested in having a homelab, make sure you try your best to not constantly compare yours to others, because it's a slippery slope of feeling like you "need" more. (trust me, browsing r/homelab often leaves me wanting to buy way more hardware, so I'm constantly needing to resist that urge) So with that out of the way, here's the hardware I have in my homelab server rack from top to bottom:

StarTech 25U Open Frame Rack
1U Brush Panel (makes things look nice with cables coming from the back)
Ubiquiti Dream Machine Pro
Ubiquiti Network Video Recorder
24 Port Patch Panel
Ubiquiti Switch 24 Port with Power over Ethernet
24 Port Patch Panel
Raspberry Pi 1U Rackmount with a Pi 3B+ and a Pi 4B+
A few blanking panels & shelf holding my cable modem
Dell PowerEdge R720 2U Rackmount server
Synology DS920+ NAS
StarTech Rackmount Power Strip
Tripp Lite 300W 1U UPS
Tripp Lite 900W 2U UPS

Let's go through the above.

Ubiquiti Networking

All of the Ubiquiti gear is the backbone of my home network. The UDM Pro is my router that provides firewall, VLANs, and more. I love this device and it was actually the first thing that started getting me interested in homelabbing. My Switch then connects all the rest of my hardwired devices such as the server, NAS, and my wireless access points and security cameras. That's why I have a PoE (power over ethernet) switch, because that's required for powering my APs and cameras. My Ubiquiti security cameras throughout my house record to the UNVR so I have all my recordings and data locally in my basement rather than in the cloud.

Computing Hardware

First I have my two Raspberry Pi devices. They're not currently plugged in since I moved their workloads onto my server recently, but once I have another need for them I'll plug them back in. I don't use their power cords because they each have a PoE "hat" which is a little add-on board that makes the Pi able to be powered over ethernet. Previously one was running Pi-hole, and the other was running Hoobs, a HomeBridge platform.

I also have my Synology NAS (network attached storage) which has two 4 TB hard drives in it currently. (I'll be adding to it when I am getting close to the storage limit) This NAS hosts my media for my Plex server as well as a lot of backups of PCs and my server virtual machines.

Finally I've got my Dell R720 server. I love this server, I bought it used on Ebay, and have loved using it ever since. It has 192 GB of RAM and a Xeon E5-2630 v2 CPU, and it's running Proxmox for virtualizing. It's got more than enough power to host the many services I've put on it so far, and there's plenty of room for more. I also have eight used 2 TB hard drives I bought on Ebay in this server which are used as the server local storage.

These devices are definitely more than enough compute power for what I use currently. Eventually as I add more services I may outgrow my current hardware, and then I may acquire a little more hardware. The nice thing is the used market for these devices is thriving and can be a very affordable way to acquire this hardware.

Services

I run a variety of services in my homelab, almost all of it on my Dell server. Some I run as dedicated VMs, and others I run as docker containers in a Docker VM. There are so many ways to host these services, so I enjoy messing around with many of those methods. Here's a list in no particular order of the services I'm running in my homelab and a short description of what it's for.

Pi-hole: Whole home adblocking
Hoobs: HomeBridge which allows me to use non-HomeKit devices with Apple's HomeKit
GitHub Actions Self-Hosted Runner: I use this to build and deploy my custom homelab code with GitHub Actions
Uptime Kuma: A status page to monitor my homelab services
Heimdall: A homelab dashboard linking to all my services
Plex: A self hosted media server
Portainer: A nice UI to monitor and manage my docker containers
Traefik: Local reverse proxy which allows me to have SSL certificates for my self-hosted services
Pterodactyl: A game server panel which allows me to spin up game servers for any game like Minecraft or Valheim
Grafana: A tool to build dashboards with metrics and for searching logs across all my services
Custom Code: I have a bunch of custom code I've written in the form of Slack bots, scripts, and other things that do whatever I want.

The fun thing about homelabs is you can run whatever you want to experiment with. While I currently run most of my stuff as Docker containers on a single Docker VM, I am planning to spin up a Kubernetes cluster and migrate my services to that so I can distribute the load across multiple nodes as opposed to throwing everything on one big Docker VM. That's just one item on my list, there are so many cool open source projects and technologies to mess around with, and it's as simple as just spinning up a VM or container for it and playing around. That's where the true fun of a homelab lies.

Conclusion

This is the state of my homelab at the beginning of 2023. Honestly I'm super excited to see where it'll be in a year or two. Maybe there's enough changes that I end up making this a yearly blog post to go over where my homelab is currently. I highly recommend that everyone who likes technology and messing around with software or hardware should start their own homelab. As I stated before, you can absolutely do a ton without spending a lot of money. Just use an old laptop or Raspberry Pi that's gathering dust. Use resources like Reddit or YouTube channels like TechnoTim or Jeff Geerling to get ideas, follow tutorials, or just enjoy their content. Or you can just mess around yourself and make a bunch of mistakes. It's a safe place to do that. And most of all just have a great time.

Angular CDK - Creating a Custom Dialog

John Woodruff — Sun, 28 Nov 2021 23:58:04 +0000

This is the first in a series of posts about using the Angular CDK library to build your own custom components.

If you're building applications using Angular, you probably know about the amazing Angular Material library. It's a component library that implements the Material Design spec. For many teams and applications, particularly those without design resources, it's a fantastic tool for building applications with a high quality design system. I have used it many times with great success.

There have been times, however, where I wanted the amazing developer experience of Angular Material, but I couldn't use the Material design that it implements because the company has an existing design system. It's precisely for these situations that the Angular team created Angular CDK, or the "Component Dev Kit". According to their website, the CDK is "a set of behavior primitives for building UI components". The CDK is fantastic because it abstracts away a lot of the really complex behavior implementation in building UI components.

Because of all these benefits, I try to always utilize the CDK for as much as possible when writing Angular applications. For this series of posts I hope to dig in to as many pieces of the CDK as possible to help you build your own high quality design system. In this post I'm going to specifically talk about building an alternative to MatDialog, as that is a very commonly used service for creating modals.

Dialog Service

In Angular Material, the MatDialog service allows you to pass a component to the service which it will then open in a floating dialog that's globally centered both horizontally and vertically. Obviously this dialog implements the Material Design spec including animations when opening and closing. Because of this, we want to implement our own design, but the ergonomics of the MatDialog service are great. So our implementation, while not exactly the same, will be similar and provide some of the same features.

The design of the API is fairly simple, but extendable when needed. We'll have have an open method that takes in an Angular component to be opened in the dialog. We can also pass data to the component that can be used if needed. This method will return a reference to the dialog that we can use to close it programatically or subscribe to when it's closed. This API design is simple and easy to extend as needed, but gets us a highly functional dialog service.

Here is a demo of the finished product with all the features mentioned above. We'll be going through step by step but you're welcome to simply reference the code here if preferred.

Prerequisites

First off we need to make sure we've got Angular CDK in our app. You have two ways you can do this. The first and least manual is to install it alongside Angular Material, via their provided Angular CLI schematic. Note that this will also install and configure Angular Material, a theme, and set up the styles. This is good in some ways because it includes the Angular CDK styles as part of the Angular Material theme. You can do that by using the following command:

$ ng add @angular/material

If you know for a fact that you're never going to want to use anything from Angular Material, and only want the CDK, then you can install it by itself from npm. Note that you must install the same version number that matches your Angular version, like so:

$ npm install --save @angular/cdk@12.2.13

This will not configure any styles, so you'll need to reference them properly as the docs outline for each piece you use. This is the method I'll be using in these tutorials because I know I won't want Angular Material as that is the whole point of this series. So now, no matter the path you chose, you have the Angular CDK installed and ready to go!

CDK Overlay

First let me explain how the CDK overlay concept works. There are three pieces to this that work together. There's the component we want to render, there's a Portal which is a CDK package for rendering dynamic content such as a component, and then there's an Overlay which is a CDK package for opening floating panels on the screen. Basically what we do is attach a component to a ComponentPortal, then attach that portal to an OverlayRef which we'll open.

There are a number of ways you can use the Angular CDK's overlay. You can use it programmatically or even as directives on markup. In our situation we want to use it programmatically so we can invoke it from anywhere via a service in our logic. So let's start out by creating a simple Angular service and stubbing out the basic API along with a couple of comments on what needs to be done.

import { ComponentType } from '@angular/cdk/overlay';
import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root'
})
export class DialogService {
  constructor() {}

  open<T>(component: ComponentType<T>) {
    // 1. Create the overlay
    // 2. Attach component portal to the overlay
  }
}

This is the very beginning of our service. We know that we want an open method, and we know it needs to take some component to open. You'll notice we're using the type of ComponentType from the Angular CDK overlay package. This is a type that allows us to receive any Angular component, and that's what is passed to the CDK when instantiating the component. Of course we also have our generic <T> which will be the type of the component we pass through.

Create Overlay

As we mentioned above we need to first create an overlay. To create an overlay we most importantly need a PositionStrategy. This defines where on the screen we want to open this overlay. There are a couple options, but in this post we'll be using the GlobalPositionStrategy. This means we won't be attaching it to a specific element. We also can provide a few more optional configuration options, which we'll do. Here's how we create that overlay, injecting the Overlay class in the constructor:

import { Overlay, ComponentType } from '@angular/cdk/overlay';
//...
export class DialogService {
  constructor(private overlay: Overlay) {}

  open<T>(component: ComponentType<T>) {
    // Globally centered position strategy
    const positionStrategy = this.overlay
      .position()
      .global()
      .centerHorizontally()
      .centerVertically();

    // Create the overlay with customizable options
    const overlayRef = this.overlay.create({
      positionStrategy,
      hasBackdrop: true,
      backdropClass: 'overlay-backdrop',
      panelClass: 'overlay-panel'
    });

    // Attach component portal to the overlay
  }
}

We did a couple of things. First, we defined our position strategy. We declared that we want a global strategy, and we want to position the overlay in the center of the screen both horizontally and vertically. You can also position your overlay (similar to absolute positioning) by giving it a top, left, right, or bottom value. This might be useful if you wanted to open a sidepanel or a bottom sheet. Since we're just making a standard modal, we're centering it on the screen.

We're also defining some information about the panel and backdrop. First we're defining that we want a backdrop for this modal, as well as providing the backdrop class for that. That's where we can define how we want to style the backdrop, which I'll be styling with a darkly translucent backdrop. We're also providing a panel class, which will be applied to the parent "panel" that we'll be rendering our component in. I just did some basic styling to make the background white and have a little padding. You can see my styles I provided in src/styles.scss.

Create Component Portal

Next we need to create our ComponentPortal that we'll then attach to the overlay. It's quite straightforward, and we do it like so:

import { Overlay, ComponentType } from '@angular/cdk/overlay';
import { ComponentPortal } from '@angular/cdk/portal';
//...
export class DialogService {
  constructor(private overlay: Overlay) {}

  open<T>(component: ComponentType<T>) {
    // Globally centered position strategy
    // ...

    // Create the overlay with customizable options
    const overlayRef = this.overlay.create({
      // ...
    });

    // Attach component portal to the overlay
    const portal = new ComponentPortal(component);
    overlayRef.attach(portal);
  }
}

At this point we can successfully open this dialog if we actually call this method and pass a component to it. While we could just leave our service like this, it definitely doesn't meet the common usecases that we could do with MatDialog. We want to be able return a dialog reference so we can programmatically close the overlay or subscribe to when the overlay gets closed. So let's add that to our implementation.

Dialog Reference

Let's create a simple DialogRef class. It should take in an OverlayRef which we can use to close the overlay, and it should have an rxjs Subject so we can subscribe to when the overlay is closed. So let's implement this simple class:

import { OverlayRef } from '@angular/cdk/overlay';
import { Subject, Observable } from 'rxjs';

/**
 * A reference to the dialog itself.
 * Can be injected into the component added to the overlay and then used to close itself.
 */
export class DialogRef {
  private afterClosedSubject = new Subject<any>();

  constructor(private overlayRef: OverlayRef) {}

  /**
   * Closes the overlay. You can optionally provide a result.
   */
  public close(result?: any) {
    this.overlayRef.dispose();
    this.afterClosedSubject.next(result);
    this.afterClosedSubject.complete();
  }

  /**
   * An Observable that notifies when the overlay has closed
   */
  public afterClosed(): Observable<any> {
    return this.afterClosedSubject.asObservable();
  }
}

Now we need to add this in to our open method so we can create this reference and return it from the method on creation. So let's put that in here:

import { Overlay, ComponentType } from '@angular/cdk/overlay';
import { ComponentPortal } from '@angular/cdk/portal';
import { DialogRef } from './dialog-ref';
//...
export class DialogService {
  constructor(private overlay: Overlay) {}

  open<T>(component: ComponentType<T>): DialogRef {
    // Globally centered position strategy
    // ...

    // Create the overlay with customizable options
    const overlayRef = this.overlay.create({
      // ...
    });

    // Create dialogRef to return
    const dialogRef = new DialogRef(overlayRef);

    // Attach component portal to the overlay
    // ...

    return dialogRef;
  }
}

This is super helpful for the consumer of this API so they can access the dialog. But what about the component we're opening? We want to be able to allow the component in the overlay to close itself. So how can we pass that dialogRef through? Well, for that we'll need to create an Injector which we pass to the component portal. This will allow us to then inject the dialogRef in our component. It's pretty easy to do this, you can do it like so:

import { Injectable, Injector } from '@angular/core';
import { Overlay, ComponentType } from '@angular/cdk/overlay';
import { ComponentPortal } from '@angular/cdk/portal';
import { DialogRef } from './dialog-ref';
//...
export class DialogService {
  constructor(private overlay: Overlay, private injector: Injector) {}

  open<T>(component: ComponentType<T>): DialogRef {
    // Globally centered position strategy
    // ...

    // Create the overlay with customizable options
    const overlayRef = this.overlay.create({
      // ...
    });

    // Create dialogRef to return
    const dialogRef = new DialogRef(overlayRef);

    // Create injector to be able to reference the DialogRef from within the component
    const injector = Injector.create({
      parent: this.injector,
      providers: [{ provide: DialogRef, useValue: dialogRef }]
    });

    // Attach component portal to the overlay
    const portal = new ComponentPortal(component, null, injector);
    overlayRef.attach(portal);

    return dialogRef;
  }
}

Now that we've provided an injector to the component portal, we'll be able to inject the dialogRef in our component very simply like so:

@Component({
  // ...
})
export class LoginComponent {
  constructor(private dialogRef: DialogRef) {}

  close() {
    this.dialogRef.close();
  }
}

Our implementation is much more thorough now that we have a way for the dialog to be programmatically closed from within the component or outside of it. The last major gap in functionality is being able to optionally pass some arbitrary data to the component that is being opened so it can utilize that data as needed.

Dialog Data

In order to pass data to the component, we'll be using the same method as our dialogRef. In this case, however, we'll need to define our own injection token for the dependency injection system. Let's start by doing that in a new file, dialog-tokens.ts. It's going to be a very simple file.

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

export const DIALOG_DATA = new InjectionToken<any>('DIALOG_DATA');

Now that we've created a very basic injection token, we can add this to our injector. We also need to update our open method to accept optional data to be passed to the component. As part of that, we'll define a DialogConfig interface that has optional data. The reason we're making this a config object like this is so it's easy to extend later if you wanted to, for example, allow customizing the options for the overlay.

import { Injectable, Injector } from '@angular/core';
import { Overlay, ComponentType } from '@angular/cdk/overlay';
import { ComponentPortal } from '@angular/cdk/portal';
import { DialogRef } from './dialog-ref';

export interface DialogConfig {
  data?: any;
}

//...
export class DialogService {
  constructor(private overlay: Overlay, private injector: Injector) {}

  open<T>(component: ComponentType<T>, config?: DialogConfig): DialogRef {
    // Globally centered position strategy
    // ...

    // Create the overlay with customizable options
    // ...

    // Create dialogRef to return
    // ...

    // Create injector to be able to reference the DialogRef from within the component
    const injector = Injector.create({
      parent: this.injector,
      providers: [
        { provide: DialogRef, useValue: dialogRef },
        { provide: DIALOG_DATA, useValue: config?.data }
      ]
    });

    // Attach component portal to the overlay
    // ...

    return dialogRef;
  }
}

Conclusion

Now that we've built this highly reusable service, we're able to open any component we want in a nicely centered modal! We can optionally provide data to it, and we can reference that dialog externally to close it if we wanted, or subscribe to it closing and react to that as needed. We could take this further, for example, by defining our own transitions and animations for the modal entering and exiting. Or we could easily pass in a config option to change the position strategy so it opens as a sidepanel instead of a centered modal. There are many ways you could tweak this to get exactly what you want, and it's fully within your control rather than being locked into the Material design dialog design and interactions.

In my next post I'm going to go over the FlexibleConnectedPositionStrategy that you can use to build things such as tooltips, popovers, dropdowns, and more. I'll be working hard on that one and hope to have it out soon. Hopefully this helps you get started digging into all the powerful options you have through the Angular CDK, and especially their Overlay package.

My Completely Biased Reasons for Choosing Angular

John Woodruff — Fri, 11 Jun 2021 20:14:48 +0000

I wanted the title to be painfully obvious. Just in case that didn't make it obvious enough, let me be even more clear. This is my completely biased opinion. You possibly vehemently disagree with me on this, and that's okay. This is not a post to try to claim Angular is better than React or Vue or Svelt or whatever other framework you're in love with. It's literally a post talking about why I, John Woodruff, choose to use Angular in personal projects small and large. Honestly, I'm not even trying to convince you to use Angular. In fact, my honest advice for picking a framework for a project is to pick the one you know the best, so you can be as productive as possible. So let's get all that out of the way up front, and dive into my heavily biased reasons for choosing Angular for personal projects. Keep in mind, when I make a statement it's an entirely opinion-based statement, so take it with a grain of salt.

Opinionated Framework

Let's talk about one of the hottest topics up front. Angular is an opinionated framework. If you're not sure what that means, basically it's that the Angular framework defines how you should build applications, and they provide all of the essential tools you need to be able to build your applications. They provide solutions for routing, data fetching, internal data flow, and more, all bundled in the framework itself. Contrast this with something less opinionated like React which specifically does not define how you should build applications, it's simply a library to build components. You can then pick and choose any number of libraries for all the pieces you need to build your application, specifically the same things I mentioned above.

So why is that a hot topic? Well, opinionated or less-opinionated frameworks or libraries elicit all sorts of responses from the developers who use them. Many developers are very against opinionated frameworks, where many other developers love opinionated frameworks. So naturally many of the arguments both in favor of and against Angular are based on the fact that it's a highly opinionated framework. They have rigid structure for how Angular apps should be built, and many tools included out of the box.

Well here we come to my first of several biased opinions. I love Angular because it's an opinionated framework. I love that I don't have to pick and choose from a million libraries to put together a complex app. 95% of what I need is already included in the Angular framework. I also don't need to decide "how" I want to build my applications, because Angular has a detailed style guide for building applications, and I'm able to focus entirely on the actual implementation of my application.

This is also why I love Angular for large complex apps within work environments. When working on teams there is often friction due to different teams or team members doing things differently. With Angular you eliminate a lot of that, because there are defined ways of doing things, and so it's far easier to scale across an organization. Having worked on large complex applications in work environments using both Angular and React, it's been infinitely easier to work within Angular applications due to the lack of a lot of the friction we had with the large React applications. It came down to Angular being opinionated, so there was far less mental overhead.

Angular CLI

Ah the Angular CLI. This goes right along with the previous point of Angular being opinionated. The Angular CLI is the best way to build Angular applications due to it tightly following the Angular style guide. It generates a fully scaffolded Angular project for you, and has numerous generator commands for adding new components, services, modules, etc., has automated testing all set up for you out of the box, and more.

It also completely controls your build process, which means they fully manage the building and optimizing of your application. So all of your production builds make use of optimizations such as ahead-of-time compilation, source code minification, tree shaking, style auto-prefixing, and more. This is all stuff that you would have to figure out and do yourself using a build tool and numerous libraries and plugins. Instead of wasting time on all that, I can enjoy knowing that the Angular CLI is generating the best possible production build for me and I can focus on building awesome features.

Version Updates

One of the best features of Angular CLI, if not the best feature, is the ng update command. Ever since Angular 6 was released, the Angular CLI has included this command. It takes basically all the work out of doing version upgrades, and the Angular team did an absolutely phenomenal job of making this command work exceptionally well. They even have a super helpful Update Guide which gives detailed instructions, but almost all of them say that the changes should be automated by the ng update command. Normally when you have a major version update, you would have to manually go through your app updating dependencies, delving into changelogs, changing code in your app in numerous places to get rid of deprecated or removed features, and then painstakingly testing to make sure you haven't broken anything. This command, however, automates essentially all of that, including running code migrations that automatically migrate you to the latest recommended syntax. There have only been a handful of times where the changes required manual intervention in the code, and usually they were exceptionally quick to resolve. All the rest is fully automated by Angular CLI.

Ever since this command was released, I have spent approximately 5-10 minutes updating to the latest each time a new major version is released. Contrast this with major version upgrades that can sometimes take hours or even days to update your large complex applications to the latest versions. It even allows library authors to define their own schematics to automatically update their libraries, and that's awesome for users of the framework to not have to worry about manually keeping those up to date when they can just automate it. This has saved me countless hours every single time a major version is released, and I am completely spoiled when using other frameworks that don't provide this incredible functionality. (that's actually another upside to opinionated frameworks, it allows features like this that are otherwise unrealistic with unopinionated frameworks) The Angular team absolutely knocked it out of the park with this feature.

Angular CDK

Alongside Angular Material is a super awesome little package called Angular CDK. CDK stands for Component Dev Kit, and it is an incredibly handy package for helping you develop some of the more complex components an application requires. They're marketed as "behavior primitives" that you can use to build your own branded components.

Building buttons and input fields and such are fairly straightforward for people building component libraries, but there are other components that are much more complex such as modals, accordions, data tables, drag and drop, trees, and more. Rather than building all this yourself or relying on libraries that style these components how they want, Angular CDK gives you ways to very easily build your own complex behavioral components that you can style easily to fit your company or project's branding. Not only that, but these components are often much more accessible than components you would build yourself. As has been the theme with this post, Angular CDK helps you save a ton of time by having these abstractions built out for you so you can worry about the look, feel, and implementation of your components rather than the more complex details such as positioning, scroll behaviors, etc. It has saved me an enormous amount of time and complexity when building my components. If you're building with Angular, even if you don't use Angular Material, you should absolutely use Angular CDK.

Dependency Injection

This is a hot topic for some reason, but Dependency Injection is another huge reason why I love to use Angular. It allows me to not have to worry about defining my own patterns for singleton vs factories. Instead, Angular's Dependency Injection tooling makes it exceptionally easy for me to provide the dependencies I need, anywhere I need them, and to do it in an easy manner. Rather than have to instantiate a service in a component, I can simply inject my service and Angular's Dependency Injection will ensure I am given the correctly instantiated service, like so:

// Some service I've defined
@Injectable()
export class MyService { /* ... */ }

// Some component in my app
@Component({ /* ... */ })
export class MyComponent {
  constructor(private service: MyService) {}
}

The other huge benefit to Dependency Injection is for better testability. Automated tests are something that I consider absolutely vital to the success or failure of a product and the team that builds it. Dependency Injection in Angular makes it incredibly easy to test, mock out, and handle dependencies external to the unit of code I'm testing at the moment. Consider the above component. To mock a method I simply need to inject the correct dependency and then utilize Jasmine's spies to mock out the method.

describe('MyComponent', () => {
  let service: MyService;

  beforeEach(async () => {
    // Initialize Angular TestBed
    await TestBed.configureTestingModule({
      declarations: [MyComponent]
    }).compileComponents();

    // Inject MyService for mocking
    service = TestBed.inject(MyService);
    // Mock out `sayHello` method
    spyOn(service, 'sayHello').and.returnValue('Hello World!');
  });
});

It makes working in large complex codebases much more trivial, and makes testing vastly more simple. Are there downsides to Dependency Injection? Absolutely. No matter what pattern you choose, there are always going to be tradeoffs. It comes down to what tradeoffs you're willing to make in exchange for the benefits you consider most valuable. For me, Angular's Dependency Injection is one of the main reasons I choose it over other frameworks.

Conclusion

In case you've forgotten by this point, I'll reiterate one more time that this post is incredibly biased and entirely opinion-based. I absolutely love to use Angular, it's my framework of choice for side projects, and I believe it's an excellent choice for many of you as well. That being said, I absolutely would argue that it's not a good choice for many others. When it comes down to it, you need to weigh the pros and cons of each framework, decide what tradeoffs you're willing to make, and choose based on what you decide. For many of you that's going to be React, or Vue, or Svelt, or Stencil, or Ember, or heck maybe even Backbone. And that's absolutely okay.

I wanted to write this article to provide perspective to why I personally choose Angular over another framework. Not to provide more fodder for the "framework wars" or to bash on another person's choice. I will always say that the best framework choice for a project is the one you or your team is the most familiar with that will help you be the most productive and provide the fewest tradeoffs for what you want. In fact I love to read other peoples' completely biased articles on why they choose their framework (or library or text editor or whatever) and I enjoy celebrating their success and happiness over what they've chosen, while I enjoy what I've chosen. If there's anyone else out there like me who chooses Angular for their side projects, I'd love to chat in the comments about what your reasons are! And if you want to bash Angular or another framework for it not being as good as Framework X or Y, I humbly request you save those comments for the posts that encourage it. ❤🌈

Combatting Burnout During COVID

John Woodruff — Sun, 04 Oct 2020 20:44:13 +0000

I'll be completely honest, I'm feeling tired just thinking about writing this post. But that's not surprising, given the topic I'm writing about. Burnout. I've written about burnout before, whether it be comments on posts, or the chapter I wrote for Your First Year in Code. I'm writing about it again because I'm currently feeling quite burned out. This, however, is a different kind of burnout than I've felt before. I've been burned out by too much coding, too little vacation, and other typical burnout reasons. This time there's no work-related reason for my burnout. This time, it's 2020 that is taking its toll on me, as I'm sure it's doing the same to many of you.

COVID-19 has been bigger, longer, and crazier than I think most of us ever thought it would be. In the early days of COVID many thought it was a quick solution. Stay home for a few weeks, maybe a month or two, and it would fizzle out. Well, as history has shown us, it hasn't fizzled, it has exploded. Most tech companies have said they'll be full remote until January at least, at which point they'll "reevaluate", which likely means set another arbitrary date because there won't yet be a vaccine widely available. Many of us have been stuck inside without much social interaction since March. Even for the staunchest of introverts, that can be exceptionally taxing on one's mental health. I'm an extrovert and I feel exhausted not being able to fully charge that social battery.

In short, I'm burned out. Not just from work, but from 2020. I also recognize that I have it better than many people. I've got a fantastic home office setup which I feel productive in, and I've got a wonderful supportive wife and son, and work for a company that was very well prepared for remote work. Many people are in a far worse situation than me, so I recognize that my burnout may be nothing compared to what others are feeling. Nevertheless it's very real for me and I wanted to write about what I'm doing to attempt to combat it.

Hobbies

I'm of the opinion that it's important to have hobbies outside of work. That being said I completely understand that many people enjoy programming as a hobby. (I'm definitely one of those people, and I've got a side project graveyard to prove it) I have, in recent years, tried to find hobbies that aren't programming that I could indulge in. That has been super helpful during times of burnout, because when I get burned out it affects my hobby coding in addition to my professional coding.

For myself personally I've had a variety of hobbies over the years. In addition to some of the typical ones (such as video games) I've enjoyed other hobbies that were less technical and more physical. One of my favorites is woodworking. My wife and I have built a variety of pieces I am proud of. My favorite was a dining table.

We had many family dinners around that table, and I felt very accomplished and greatly enjoyed working hard on this beautiful piece. It contributed greatly to me feeling fulfilled and definitely helped to hold off periods of burnout. There is something about working with physical objects and tools that breaks up the constant mental stress of working on a screen and with software. Perhaps something like that that would work for you to help fight off burnout.

Exercise

This is one of the most commonly recommended things to help with burnout. (among many other ailments) I'm sure you, like me, are tired of hearing that exercise is good. It's one of those things where we all know it's something we're supposed to do, but despite that I personally tend to brush it off as something other people need to do. It is, however, a very important part of keeping your mind and body healthy, something that directly affects your burnout.

I've lately been in a better habit of exercise. Part of it is that I got a new puppy about 2 months ago! She's adorable, but she requires a lot of exercise to keep her healthy and happy, which means a lot of exercise for me. I take her on multiple walks every day to help her expend some energy, and she usually loves to run during the long stretches of grass, which I run with her.

Another easy way to start getting into exercising is through VR if you're able to own something like an Oculus Quest. While most games you don't move around much, there are plenty of games that can actually get your heart rate going decently well such as Beat Saber. On the Oculus Quest specifically there is a game called Supernatural that is a fitness game. You pay for a membership and you get new workouts daily that tailor themselves to your fitness level. I tried it on a friend's headset before I got the Quest and it was a great workout. So there are plenty of ways to get exercise without needing to go to a gym or have lots of equipment at home.

Video Games

I really enjoy video games as I'm sure many of you reading this article do as well. On the one hand playing video games keeps you staring at screens, so for some people it might not help with burnout. Also playing video games for huge periods of time can lend itself to not feeling great mentally. However I really enjoy playing video games for reasonable periods of time, especially with friends and family.

Due to COVID most of us can't do close contact with friends and loved ones at the moment. I'm particularly close with my siblings, and pre-COVID we would get together regularly to hang out and enjoy each others' company. Since we can't do that right now, we decided to do a once-a-week video game night where we all play a video game together over voice chat. Our favorite to do is Age of Empires II, since that was one we played together frequently while growing up. It's really fun because we get to chat while playing, and we usually do a Zoom call afterwards to chat and reminisce.

I also enjoy streaming on Twitch while I play video games. I'm by no means a streamer like many of you might be. I mostly stream just because it's fun when the occasional person hops on the stream and interacts with me. I only stream twice a week, usually to play Sea of Thieves on Tuesdays, and Rocket League on Fridays, with a variety of friends. Those are really fun to do. We play a couple hours and just have a fun time together, whether anybody watches or not. I definitely don't stream to do anything other than just have a good time.

Keep in Touch with Friends & Family

It's hard being apart from those you care about. That really starts to wear on you. So while we can't do much right now in terms of being together with groups of loved ones, we can find alternative ways to be together and enjoy each others' company. My family, for example, does a scheduled Zoom call once a week to stay updated with each others' lives. We share memories, talk about our week, and just have a nice time together.

Another thing my family has started doing is sending weekly emails to each other on Sunday with photos and details of our lives and goings on during the week. It's been incredibly fun reading through what people are doing despite being restricted in what they normally do, and it's always enjoyable seeing photos of nieces and nephews and pets. In fact I've started saving those emails, and I'd love one day to compile a book of them for our family to look back on this crazy time and remember.

If you live near family you can also do socially distanced visits. My parents live about 10 minutes from me so we like to go over every now and again and hang out in their backyard. We let our puppy run around and play, my son jumps on their trampoline, and my wife and I sit and chat with my parents, about 10 feet apart, on their back patio. While we can't give hugs or be physically closer than across the patio, it's really nice being able to be in somewhat close proximity with loved ones. I recognize that many people don't have the same luxury as I do of living close to family, but for those that do this can be incredibly helpful in trying to push away the burnout of being alone and separated from people, and we can still do it safely.

Those are just a few of the things I've been doing to try to fend off the burnout that's been persistent during all the shutdown and restrictions of COVID. As with everything else in life this is by no means a one size fit all kind of thing. Obviously what works for me isn't necessarily going to work for you. I do hope, however, that by detailing some of the things that work for me, you'll at least find some ideas that work for you too. COVID has been rough for all of us in a million different ways, but frankly it's good to talk about when we're not feeling great. I'd love to hear what all of you are doing to combat the burnout many of us are feeling during COVID, maybe some of your ideas could work for me too.

Far More Epic Development Environment using WSL 2

John Woodruff — Sun, 16 Aug 2020 23:41:53 +0000

By far my most read blog post was my first, Epic Development Environment using Windows Subsystem for Linux, and to this day it gets many views here on DEV, as well as on Medium where I originally published it, as people search for WSL to find out if it'll work for them. Well, since I published it at the end of 2017, a lot has changed, and I'm not referring to the pandemic in which we all find ourselves. I'm talking about WSL 2.

This year Microsoft released Windows Subsystem for Linux 2 alongside the Windows 10 version 2004 update. There are a number of differences between version 1 and 2. You can read more about the exact differences but the key takeaways are that WSL 2 offers 100% system call compatibility, much faster performance, and less memory usage. Note that you only get the fast performance if you store the files you work with in the Linux filesystem. If for some reason you need to store your files in the Windows filesystem, you'll get better performance using WSL 1.

Since I've upgraded my setup to use WSL 2, my quality of life has been upgraded in a major way. There have also been other advancements in a variety of other areas that make my new setup so much better than what I wrote about in my previous article. I'm super excited to go over them with you all.

Prerequisites

To use WSL 2 you must be running Windows 10 version 2004 or greater. WSL 2 is not available in builds before version 2004. In my previous article you needed Windows 10 Pro so Docker could use Hyper-V virtualization. Thankfully that's no longer required!

Install WSL 2

Let's get WSL 2 installed. The first thing you need to do is enable the Windows Subsystem for Linux feature in Windows. You can do this simply by running the following command in PowerShell as an Administrator:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

This will enable the WSL feature. At this point you'll want to follow the Update to WSL 2 instructions to update the WSL 1 installation to WSL 2. In short you need to run the following command, then restart your computer to complete installation:

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Once your computer has been restarted, make sure you run the following command as Administrator in PowerShell to ensure WSL 2 is always the default WSL version.

wsl --set-default-version 2

NOTE: You might get a message saying something like "WSL 2 requires an update to its kernel component". Make sure you follow the link provided and do what's needed.

At this point you can go to the Microsoft Store app and search for your favorite Linux distribution! Please note that this article assumes you are using Ubuntu. You can use any distro, however, you will simply need to find the correct commands to install things. Once you've installed your distro, go ahead and open it to perform the initial installation. It will ask you for a user and password for the Ubuntu userspace. When it's done, you're ready to get to installing!

Git

As before, many of the installations further on in this article require git. To install, simply run sudo apt update && sudo apt install git. You should also generate an SSH key. This is very simply accomplished by running: ssh-keygen -t rsa -b 4096 -C "your_email@example.com".

ZSH (Optional)

I'm simply going to copy paste this section from my previous article as nothing has changed at all here, and I'm still digging my ZSH setup.

This next step is completely optional. I love bash, and I love zsh, so either one works fine. If you prefer bash, skip this section.

It’s fairly straightforward to install zsh. After making sure you’ve run sudo apt update then install it with sudo apt install zsh. You can test to make sure it’s working by running zsh which should bring you into a zsh terminal!

I also love oh-my-zsh, which provides lots of beautiful themes and excellent plugins. I used the curl command under the Basic Installation instructions, and I was good to go! You can then select the theme you want by editing your ~/.zshrc file and adding the theme name to the ZSH_THEME environment variable. Previously I was using the Pure theme for ZSH, but I've since moved over to the venerable Powerlevel10k theme. It's super customizable, easy to setup, and has excellent speed.

Featured image from the Powerlevel10k repository

Windows Terminal

This is one area where I've absolutely changed my mind from 2017. Back then I used the Hyper terminal by Zeit. (The company has since rebranded to Vercel) While I still use that on my Mac, on Windows I now use the phenomenal Windows Terminal. It's fast, modern, and beautifully designed. It also works seamlessly with WSL, PowerShell, CMD, and more! It's got multiple tab support, Unicode support, custom themes, and a bunch of other great features. I highly recommend it for anyone doing any kind of development on Windows, whether it's WSL or not. You can simply find it on the Microsoft Store and install it from there for free.

When you launch Windows Terminal after having installed and run Ubuntu for the first time, it should pick up the distro automatically and add it to your terminal settings so it's an option to use. I like to make it my default when I open Windows Terminal, as well as a couple other changes to the configuration. Here's my specific Windows Terminal config for my Ubuntu distro:

{
    "guid": "{GUID_HERE}",
    "hidden": false,
    "name": "Ubuntu",
    "source": "Windows.Terminal.Wsl",
    "startingDirectory":"//wsl$/Ubuntu/home/{UBUNTU_USERNAME}",
    "fontFace": "Fira Code",
    "useAcrylic": true,
    "acrylicOpacity": 0.8
}

I set a few things here. First of all, I set my startingDirectory to be my Ubuntu home directory. Simply replace {UBUNTU_USERNAME} with your actual ubuntu username. I also love the Fira Code font, so I've got that installed on my machine and I have my terminal using it. Lastly, I'm a huge fan of the Windows acrylic look, so I have my terminal using that effect. You're welcome to set that to false if you don't like it.

Screenshot from the Windows Terminal store page

Visual Studio Code

What has not changed is that Visual Studio Code is possibly my favorite piece of software ever. As mentioned in my previous article, I’ve used IDEs, Sublime Text, Atom, Notepad++, I’ve tried almost all of the most used ones. VS Code is by far my favorite editor. It’s beautiful, incredibly lightweight, super fast, has tons of amazing extensions, built in debugger support, and is as close to full IDE functionality as any text editor I’ve ever used. I installed this as quickly as I could and brought down all my settings using the Settings Sync extension.

NOTE: As of a couple days ago I probably won't be using the Settings Sync extension anymore as VS Code now has built in settings sync support. My initial tests have been very positive.

There's one more extension you must get if you're doing WSL 2 development. This is different from my last article as this extension did not exist at the time. That's the Remote - WSL extension. This little extension makes many of the little gotchas I previously experienced go away. I used to have to install a tool called wsl-git that would proxy Windows git requests to WSL. This was so I could get the git features in VS Code to work. With this WSL extension you no longer need any of that. When you run code . from a folder inside of your WSL terminal, it will open that folder in VS Code and automatically use all the features and binaries from your WSL 2 installation instead of from Windows. You can install VS Code extensions that use the Linux binaries. It's a totally seamless experience that makes you forget you're not using Linux.

My Visual Studio Code setup with the Remote - WSL extension

Node.js/NPM

This section remains the same as my previous article. Once again copying it over for posterity.

Personally I decided to take the approach of doing as much as absolutely possible inside of the WSL environment. Also, I am obsessed with NVM for managing my Node installs, which doesn’t work on Windows. So, instead of downloading the installer for Node.js for Windows, I installed nvm through Ubuntu’s repositories! You can follow the directions on NVM’s Installation Instructions. I used curl to download the install script, which I installed by running sudo apt install curl.

If you did everything right, you should have nvm installed correctly. I then installed the Long Term Support version of node by running nvm install --lts and then nvm use --lts to set it as the version I’m currently using. I also set it to my default node version by running nvm alias default {VERSION} where VERSION is the version number you just installed.

A global npm install of the Angular CLI & Typescript npm packages

Yarn

As an aside to installing Node, I thought I’d bring up that I also installed Yarn, because I love Yarn. You can install it through Windows, but again, I’m trying to do everything I need through WSL, so I followed the Linux Installation Instructions. Specifically the Ubuntu/Debian instructions, of course. This went without a hitch, and I had yarn working!

A yarn install working beautifully

Docker

This is one of the best parts of WSL 2 that has changed since last time. Docker for Windows has been updated to support using WSL 2 as the backend for Docker. This was one of the pain points in the setup in WSL 1, and I had to alias the Windows executables to bash commands. There were occasional gotchas that generally were annoying. This is fantastic news, as those gotchas are all gone, and it's a totally seamless experience!

To get Docker up and running, simply download Docker Desktop. During the installation it should prompt you whether or not you'd like to use the WSL 2 integration, so make sure you enable that. The Docker Desktop WSL 2 Backend documentation gives detailed instructions on how to make sure things work properly in case you're having troubles getting this working.

At this point you should be able to use Docker and Docker Compose beautifully inside of both your Windows PowerShell environment as well as inside of your default WSL distro! (you can enable it inside of other WSL distros besides your default one in the WSL Integration settings in Docker Desktop)

Docker for Windows pulling and running the mysql container

Last Words

I'm hugely impressed with everything the WSL team has accomplished. WSL 2 is a massive improvement over WSL 1 and alongside other tools from Microsoft that integrate seamlessly with WSL 2, it's a phenomenal development environment that has very few if any compromises for the web development work I do. I have a work-issued Macbook Pro that I use through the work day, but I now immediately switch to my Windows machine when the work day is over and all the rest of what I do is done there with great enjoyment.

Four years ago I had totally written off Windows for development. For me it was either Mac or dual boot a Linux distribution. I would occasionally come back and try Windows for coding, and would almost immediately give up. WSL 1 changed that for my personal side projects. To be honest, however, WSL 2 has me fully believing I could use Windows exclusively for everything I do and be super happy doing it. That's an awesome feeling for someone who has always loved Windows as a consumer operating system, and I'm so excited to see what other amazing dev tools come to Windows because of the amazing tool of WSL 2.

My Home Office & Workstation

John Woodruff — Thu, 24 Oct 2019 23:53:01 +0000

This year I got a new job at a place called GoReact that allows me to work remote if I wish. I currently am enjoying working remote 3 times a week, and going in to the office on the other 2 days. As such, I needed a comfortable, ergonomic, productive workspace for myself at home. I have the fortune of living in an apartment that has an extra bedroom we don't use, so I use that as my home office. It's taken me close to a year to acquire all the pieces I wanted in a dream office, but I finally have a space put together that helps me feel inspired and productive while working. So, without further ado, here it is:

Here's another view of it from straight on.

I'm very proud of this workspace. Sure, it could use some help in the cable management department, among other places, but I love it. A lot of this I owned before setting up this home office, and some of it I bought when getting my space set up.

Here is a list of the things you'll see that make up my workspace:

Autonomous SmartDesk Business Edition with Cable Tray (to help with cord management)
Autonomous ErgoChair 2
Anti-Fatigue Mat
15" MacBook Pro (work issued)
Samsung CHG90 Series Curved 49" monitor
Logitech BRIO Ultra HD Webcam
CODE Mechanical Keyboard with Cherry MX Clear switches
Apple Magic Mouse 2
Apple Magic Trackpad 2
Bose QuietComfort 25 Noise Cancelling Headphones
Anker Soundcore Bluetooth Speaker
Anker Wireless Charger
Pictostone Notebook - Stone Paper Notebook
ORICO USB 3.0 Hub
Brainwavz Hengja - Desk Headphone Hanger Mount
Various dongles because USB-C 😅

Miscellaneous non-work related items:

Dwight Schrute Bobblehead
Dundie Award
Korbanth Graflex 2.5 Lightsaber (empty hilt kit, self-assembled)
DJI Ronin S
Breath of the Wild Divine Beasts desk light from VividDelights

Well, that's it. That's my workspace. It's got two windows so I get plenty of natural light. (they were closed so the photos wouldn't be backlit like crazy) It has a door I can close and lock so I don't need to worry about my sweet 5 year old walking in while I'm in an important meeting. It works perfectly for me.

I'm quite satisfied with the current state of my office. I am, however, saving up for a custom build gaming PC. My MacBook Pro is work-issued, can't play most of my video games, and definitely can't do VR. (I have an Oculus Rift S) So it may be close to a year before I can get that, but that's next on my list of what to add once I've saved up a bit more.

Let me know what you think! I'd also love to see some other workstations from the rest of y'all!

Stop Fighting About JavaScript Frameworks

John Woodruff — Wed, 21 Nov 2018 06:17:46 +0000

The State of JS survey is live, and with it comes the usual tweets about this or that framework "dominating" others, one or another "has been destroyed", it goes on and on. Even the survey itself says:

The front-end remains the key battleground for JavaScript. But now that the dust has cleared, it's starting to look like only two combatants are left standing...

It's disappointing to say the least that the JavaScript community that I love so much has turned into one giant argument about who's better, cooler, in other words, the "winner".

React vs Angular vs Vue vs...

This is the tale as old as time. I can't tell you how many articles I've seen and read about why React is better, Angular is better, Vue is better, Vanilla JS is better, etc. There is the full spectrum of these posts. From being very fair and open minded by addressing the best and worst of each framework and inviting the user to decide what works for them, to being downright biased and essentially saying Framework X sucks and Framework Y is the best, with little offered for reasoning.

All this serves to do is foster a culture of superiority and gatekeeping. You're not a real developer because you use the inferior framework. Unless you're using the hottest framework, you're not worth hiring at my hip and happening startup.

It Hurts Everyone

Saying and promoting ideas like this is damaging to the community as a whole. Take the State of JS survey for example: The number of respondents was approximately 20,000 developers. That's very small representation compared to the industry. Stack Overflow's survey had over 100,000 respondents.

There is also something to be said about the fact that the makers of the survey are React library authors with heavy React developer followings. So naturally simply due to the audience they cater to, there will be a hefty amount of React developers responding to and sharing the survey amongst themselves.

The problem with this is that this survey is being presented as a definitive view of JavaScript in 2018. With such a limited and focused sample size, the results are likely skewed towards certain groups. This is problematic for developers who take those results and show them to their boss saying "look at these results, Angular is dead, we need to migrate all of our code to React or Vue". I've literally had discussions with people to that effect. It's not based on what the best option is, but rather the most popular according to one small survey or blog claiming to be the definitive view of the JavaScript world.

This is harmful to everyone, because companies and developers will spend a lot of time doing what someone views as the most popular thing to do rather than the option that might be best for the company. For example, rewriting an app from Angular.js to React despite the fact that an Angular.js to Angular transition may be faster and easier due to the concepts and fundamentals being similar. I've also heard of a developer being hired at a startup and telling them that Angular is the best framework and they need to rewrite their entire React app in Angular, costing months in time and money.

Stop the Hot Takes

I'm personally over all the pundits proclaiming why one framework is better than another, or declaring a winner of the "framework war". It is, in my opinion, a form of gatekeeping that we as a community don't need. Why does there have to be a war? I would argue that there's not, or at least shouldn't be, a war. Especially in 2018, when React, Angular, Vue, Aurelia, etc. are all excellent modern frameworks with amazing reasons to use each.

Use what makes you happy. If it's React, Angular, Vue, something completely different, if it is enjoyable and helps you to be more productive, then it's a good thing. Let's please stop using these surveys and articles to try to convince everyone else that your choice is right and theirs is wrong. Let's love each other and love our own choice.

Disclosure: I am a happy user of both Angular and React. This article is not intended to be a low-key "Why Didn't Angular Get First Place". Hopefully that's not how it sounds. I simply want to help end the "war".

Changelog: New StackBlitz Liquid Tag

John Woodruff — Mon, 19 Nov 2018 17:44:59 +0000

A new challenger approaches!

Joining the likes of the various other embedded code environments such as CodeSandbox, Codepen, and Glitch, there is a shiny new StackBlitz Liquid Tag! StackBlitz, the online IDE for web applications powered by Visual Studio Code, has become the go-to online editor solution for many developers, many of whom even use StackBlitz to power their documentation examples. (such as the Angular team)

To use the liquid tag, simply add your project ID to the liquid tag. This may be the auto-generated ID when you created the project, or whatever you renamed your project to. Like so:

{% stackblitz ball-demo %}

There you have it! Enjoy the awesomeness that StackBlitz can bring to your blog posts! 🎉

Component Libraries with Stencil.js - Decorators

John Woodruff — Sun, 18 Nov 2018 23:40:19 +0000

This is the fifth in a series of posts about creating a web component library using Stencil.js - Check out the first post

At this point we've built a fairly basic component that looks great and functions correctly. We're now going to move on to a new component that has more complex functionality and interaction. Tabs are one of the basic components every library needs. Each tab is effectively a button, but those buttons work together and maintain a shared state with regards to which tab is currently active. This is a perfect candidate for our next component, as it can use all the rest of the decorators Stencil provides.

Building Blocks

Let's first create an incredibly simple component with no styling or functionality. Start by creating a new folder, tabs, which contains three files: tabs.tsx, tab.tsx, and tabs.scss for our styles. Let's start with the building block tab component.

This will be a little different. It will be a component, but will not have a render function. It will instead keep track of a couple of props for us. Add the following to your tab.tsx file:

@Component({
  tag: 'mtn-tab',
  shadow: true
})
export class Tab {
  @Prop() label: string;

  @Prop() active: boolean;

  @Prop({ reflectToAttr: true }) disabled: boolean;
}

We've got props for the label, which the tab will display, a flag that shows whether or not it's active, and of course a disabled property. If we wanted to keep more metadata associated with each individual tab, this is where we'd add it.

Now let's dig into our main tabs component in tabs.tsx. We first need to render the basic structure of the component. Let's start with the following:

export class Tabs {
  render() {
    const classMap = this.getCssClassMap();

    return (
      <div class={classMap}>
        <button role="tab">
          Tab 1
        </button>
        <button role="tab">
          Tab 2
        </button>
        <button role="tab">
          Tab 3
        </button>
      </div>
    );
  }

  private getCssClassMap(): CssClassMap {
    return {
      'tabs-list': true
    };
  }
}

Let's also get some very basic styling in place to our host component and .tabs-list class. In our tabs.scss file we'll put in a few blocks:

@import '../../styles/variables.scss';

:host {
  display: block;
  box-sizing: border-box;
}

.tabs-list {
  border-bottom: 1px solid #dddddd;
  padding: 0 5px;
}

This obviously looks really ugly and not at all like tabs, but it's a start, and we simply need to style them to be a little nicer. Let's add a few simple styles to make them look beautiful.

Let's give each button a .tab-button class and an .active class to the first one. Now for the class definition:

.tab-button {
  border: 0;
  font-size: 14px;
  font-family: $font-family;
  padding: 8px;
  outline: none;
  cursor: pointer;

  &:hover:not(:disabled):not(.active) {
    border-bottom: 3px solid $light-dark;
  }

  &:disabled {
    opacity: 0.4;
  }

  &.active {
    border-bottom: 3px solid $blue-steel;
    font-weight: 600;
  }
}

We're doing a couple things here that you can work out, but basically we're removing the styling that buttons have, tweaking the font, and then adding a nice border at the bottom of the tab when it's active. We're also doing a fun little hover border with a light gray color when hovering over a tab that's neither disabled nor currently active. We're of course also defining what a disabled tab looks like.

Now our tabs look like actual tabs, but they're also hardcoded. We want to be able to specify how many tabs we want, as well as customize their labels. Here's where we get into the other decorators.

State and Element Decorators

First let's define the tabs and dynamically create them. These tabs define how we render our component, so we're going to define them along with the @State() decorator:

export class Tabs {
  @State()
  tabs: HTMLMtnTabElement[] = [];

  //...
}

The @State() decorator is used to manage data that is internal to the component. Any changes to this property will cause the component to re-render, as the state has changed.

You'll also notice I'm using the HTMLMtnTabElement[] type for the tabs. This is an interface that is created automatically by Stencil in your components.d.ts file. It gives you some nice intellisense for your component, with the standard HTML element properties and methods, as well as those you define on your component.

With our tabs, we want to use the following syntax to define them:

<mtn-tabs>
  <mtn-tab active label="Tab 1"></mtn-tab>
  <mtn-tab label="Tab 2"></mtn-tab>
  <mtn-tab label="Tab 3" disabled></mtn-tab>
  <mtn-tab label="Tab 4"></mtn-tab>
</mtn-tabs>

Let's use the componentWillLoad() lifecycle hook to grab the tabs we've specified and render them. We're also going to have to use the @Element() decorator so we can reference it in our method.

The @Element() method is pretty simple. It returns an instance of the host HTMLElement of your component. We want to query elements within our own component, so we're going to use that in our componentWillLoad() method like so:

export class Tabs {
  // Our host element
  @Element()
  el: HTMLElement;

  @State()
  tabs: HTMLMtnTabElement[] = [];

  componentWillLoad() {
    // Grab tabs from this component
    this.tabs = Array.from(this.el.querySelectorAll('mtn-tab'));
    if (this.tabs.length === 0) {
      throw new Error('[mtn-tabs] Must have at least one tab');
    }
  }
  //...
}

This snippet grabs all mtn-tab elements and sticks them in our tabs property. Let's then adjust our render() function to use the dynamically grabbed tabs.

export class Tabs {
  // ...

  render() {
    const classMap = this.getCssClassMap();

    return (
      <div class={classMap}>
        {this.tabs.map((tab: HTMLMtnTabElement, index: number) => {
          const tabClassMap: CssClassMap = {
            'tab-button': true,
            active: tab.active
          };

          return (
            <button
              role="tab"
              disabled={tab.disabled}
              class={tabClassMap}
              onClick={() => this.openTab(index)}>
              {tab.label}
            </button>
          );
        })}
      </div>
    );
  }
}

If you've ever used React, you'll recognize what we're doing here. Remember that TSX is TypeScript, not actual HTML, so we can do things such as transform arrays into other rendered elements. We're doing this in our function here. We're taking this.tabs and using the map() function to transform those tabs into elements we want to render on screen. In this case we're rendering our buttons with the .tab-button class, and we're conditionally applying the .active class to the tab which is marked as active. We make sure to assign the disabled attribute conditionally to those tabs that we've marked as disabled. We also specified a click handler, onClick, that we'll implement now.

Method Decorator

We want to implement our click handler on a tab so we can correctly change tabs when clicked on. For this we're going to use the @Method() decorator. This decorator exposes class methods on the public API for the component. In other words, you can call those methods simply by querying for the element and calling its method, like so:

const tabs = document.querySelector('mtn-tabs');
tabs.openTab(2);

In order to keep methods internal to the component we want to simply omit the @Method() decorator. By my judgement, methods should be kept internal unless there is a valid reason for them to be exposed. In the case of this openTab() function, there is definitly a good reason to expose it, so let's implement it now. According to the docs, public methods must be async so we're making sure to mark it as such.

export class Tabs {
  // ...

  @Method()
  async openTab(index: number) {
    if (index >= this.tabs.length) {
      throw new Error(
        `[mtn-tabs] Index ${index} is out of bounds of tabs length`
      );
    }
    if (!this.tabs[index].disabled) {
      this.tabs = this.tabs.map((tab, i) => {
        tab.active = i === index;
        return tab;
      });
    }
  }

  // ...
}

We first make sure that the index requested exists. We can't select a tab that doesn't exist. We then check that the tab that has been clicked is not disabled. We don't want a disabled tab to have any functionality. Otherwise we change the active flag on each tab, depending on whether the index of the tab matches the index we passed into the method. If it matches, we set active to true, otherwise we set it to false.

If you save and check, your tabs now change when you click on them! They're starting to work just how we want them to. There are a few more things, however, that we want to do before we finish up this component.

Event Decorator

We exposed the openTab() method on the public API of our component. This is obviously useful to be able to programatically change tabs. What about being able to determine when tabs have changed and react to that change? We would use custom Events with the @Event() decorator.

With our components, we can define an EventEmitter to emit Custom DOM events. This is really easy with Stencil. Let's define ours now and emit the changed tab in our openTab() method:

export class Tabs {
  // ...

  @Event({ eventName: 'change' })
  onChange: EventEmitter;

  @Method()
  openTab(index: number) {
    if (index >= this.tabs.length) {
      throw new Error(
        `[mtn-tabs] Index ${index} is out of bounds of tabs length`
      );
    }
    if (!this.tabs[index].disabled) {
      this.tabs = this.tabs.map((tab, i) => {
        tab.active = i === index;
        return tab;
      });
      this.onChange.emit({ tabId: index });
    }
  }

  // ...
}

We created our onChange which is an EventEmitter that we imported from Stencil. We also changed its name using the eventName config property in the decorator. You can change this if you want or keep it the same, it's up to your preference. The only suggestion is that you keep your naming consistent.

We then call the emit() function on the EventEmitter and emit an object with a tabId of the changed tab. We can now listen to this event outside of this component and react to it, like follows:

const tabs = document.querySelector('mtn-tabs');
tabs.addEventListener('change', event => {
  // You'll find your emitted object under event.detail
  console.log(`CHANGED TABS TO INDEX ${event.detail.tabId}`);
});

Now you can do things such as swapping out views when the currently active tab changes! Events are super handy when it comes to any good component library. We could add all sorts of events to our components. In the case of our tabs, however, we'll leave it with this one event.

Listen Decorator

The @Listen() decorator is closely related to the @Event() decorator. Basically it's a shorthand way of listening and reacting to a DOM Event. You could either listen to your own component event you've defined, or you could listen to a standard event, such as the scroll event. It works like this:

export class MyComponent {
  @Listen('body:scroll')
  handleScroll(ev) {
    console.log('The body was scrolled', ev);
  }
}

We're not using this decorator in our tabs component, but it's very simple to use. Other use cases might be a keyup listener which you could use to, for example, implement the Konami Code on your component to unlock a fun easter egg.

Watch Decorator

There is one more main decorator in Stencil's toolkit, and that's the @Watch() decorator. It is used to watch a specific property on the component class, and decorates a method which is called upon that property being changed. It calls the method with the oldValue and newValue, so you can react with either value in mind. We're not going to use it in our tabs component, but we could if we wanted. Instead of emitting the new index in the openTab() function, we could instead listen to the tabs property and emit the newly active tab from there, perhaps like this:

export class Tabs {
  // ...

  @Watch('tabs')
  tabsChangeHandler(newValue: HTMLMtnTabElement[]) {
    const newIndex = newValue.findIndex(tab => tab.active);
    this.onChange.emit({ tabId: newIndex });
  }

  // ...
}

In that function we don't care about the old value, we just want to return the new tab. This works identically to how we were doing it previously, it still emits the new tab when the tabs change. We're not using this method in our component, however, because we have to search for the index of the new tab each time the tabs are updated, whereas we know for certain which tab is the new one in our openTab() method, so we'll stick with that. This is how you use the @Watch() decorator though, and it's useful for other situations and components, so it's worth keeping around in your toolbox.

Next Steps

Congratulations! Your tabs component should be fully working now! We have a public API to change tabs, an event we can listen and react to, and internal state that helps us re-render appropriately when needed. The decorators we've gone over in this and previous posts form the foundation of building web components with Stencil. We've covered a ton of ground in this series, but there's still more to be had! One of the most important aspects of developing software has been missing thus far, and that's testing your code. We'll be going over that in the next post, coming soon!

Simply want to see the end result repo? Check it out here

Component Libraries with Stencil.js - Going Deeper

John Woodruff — Wed, 26 Sep 2018 16:17:05 +0000

This is the fourth in a series of posts about creating a web component library using Stencil.js - Check out the first post

In the last post we created a very simple button component. We're now going to extend that with more options and functionality to be more fully featured. I personally want to have a couple of color options for this button, a couple of button shapes, and a few sizes.

Component Props

To start into this, we'll need a few props to allow the user to specify what they want. Let's call our props color, shape, and size. We also can have multiple button types such as submit and reset, just like a regular HTML button, so we'll add that as a prop too.

@Prop()
type: 'button' | 'reset' | 'submit' = 'button';

@Prop()
color: 'primary' | 'accent' | 'light' = 'primary';

@Prop()
shape: 'square' | 'round' = 'square';

@Prop()
size: 'small' | 'default' | 'large' = 'default';

If you've barely/not used TypeScript before, you'll notice that instead of defining my types for these props to be of type string, which technically they are, I'm going a step further and defining that each prop can be one of several specific strings. This allows for much more effective IntelliSense when you're using this component. I'm defining up front a few specific sizes, colors, shapes, and types that I'm going to be implementing. On top of that, I've initialized those props to my preferred defaults, so that if you simply call my button component with no defined props, it'll look like a default button.

Class Map

Next I'm going to be using those props to build a map of CSS classes to apply to my component. I typically like to define an interface called CssClassMap for this purpose. Let's create that file at src/utils/interfaces.ts, as it's something I'll be reusing for all my components, and use the following content for the file:

export type CssClassMap = { [className: string]: boolean };

As you can see, I'm defining this class map type as a map of a key, the class name, and the value being a boolean. Effectively I'm going to be specifying whether I want classes to be applied or not. Now that we have this interface, let's write a method that builds this class map on render.

export class Button {
  // ...

  render() {
    const classMap = this.getCssClassMap();

    return (
      <button type={this.type} class={classMap} disabled={this.disabled}>
        <slot />
      </button>
    );
  }

  private getCssClassMap(): CssClassMap {
    return {
      [this.color]: true,
      [this.shape]: true,
      [this.size]: true
    };
  }
}

As you can see, I'm calling our function from the render method to get the class map, a fairly simple one in this case, and am applying that to the button. You may also have noticed that I also passed the type prop to the button as well. Now that we have the correct classes being applied, let's actually implement those classes. First we need the correct colors, so let's add a few more SCSS variables to our src/styles/variables.scss file.

//...

// Brand Colors
$blue-steel: #4571c4;
$blue-steel-dark: #315db0;
$coral: #c75943;
$coral-dark: #a83a24;
$light: #f0f1f2;
$light-dark: #e2e3e4;

Now that we have the variables available, let's implement the classes themselves. We don't need to implement the default classes as they are the default that we've already implemented.

button {
  //...

  // Color variations
  &.accent {
    background-color: $coral;

    &:hover {
      background-color: $coral-dark;
    }
    &:active {
      background-color: darken($coral-dark, 10%);
    }
  }
  &.light {
    background-color: $light;
    color: rgba(0, 0, 0, 0.7);

    &:hover {
      background-color: $light-dark;
    }
    &:active {
      background-color: darken($light-dark, 10%);
    }
  }

  // Shape variations
  &.round {
    border-radius: 50px;
  }

  // Size variations
  &.small {
    padding: 2px 8px;
    font-size: 12px;
  }
  &.large {
    padding: 8px 20px;
    font-size: 16px;
  }
}

For the color changing classes, we need to re-implement our hover and active states. We do not need to re-implement our disabled state since our existing one simply applies a lower opacity, looking great in any color. Making the button round is trivial, and then we finally tweak the padding and font-size of our button to look good as a large or small button.

Now that we've implemented these classes, we have some pretty incredible looking button web components!

Next Steps

We now have an awesome button component we can use anywhere! This is a simple first component, so we're not dealing with many of the other decorators such as @Watch(), @Method(), or @State(). We'll get into those with a new component that is more complex in our next post. See you in the next one!

Simply want to see the end result repo? Check it out here

Component Libraries with Stencil.js - Your First Component

John Woodruff — Mon, 17 Sep 2018 15:57:09 +0000

This is the third in a series of posts about creating a web component library using Stencil.js - Check out the first post

We've done a lot of setup so far, now let's create our first component. This is the foundation of any component library: the button component. Let's rename the my-component folder to button, and all the files inside replacing my-component to button. We're now ready to build our button.

Component Decorator

The first thing we're going to do is change the contents of button.tsx. We're going to change the tag in the @Component decorator to our actual tag name, and the styleUrl to point to our newly renamed SCSS file, in my case the following:

@Component({
  tag: 'mtn-button',
  styleUrl: 'button.scss',
  shadow: true
})

Note the shadow property. This is declaring that we will be using the Shadow DOM for this component. This has many benefits including an isolated DOM and scoped CSS, among others. We'll definitely want to be taking advantage of this, as it's one of the key parts of web components.

Render Method/JSX

Next we're going to change the class to render a plain button with a single prop.

export class Button {
  render() {
    return (
      <button>
        <slot />
      </button>
    );
  }
}

Looking at the render method, you'll notice we're not writing HTML. We're using a JavaScript syntax extension called JSX or JavaScript XML. Note with Stencil we're actually using TSX, a file with the ability to write JSX using TypeScript. Let's change the markup to render a standard HTML button. We're also placing a slot inside the button. This is a part of the suite of browser web component APIs; it allows us to fill that slot with markup defined by the consumer of the component. In our case, consuming this component would look like this:

<mtn-button>Click Me!</mtn-button>

The text "Click Me!" is projected down to the slot within the component. The markup in the component will be the following:

<button>
  <slot>Click Me!</slot>
</button>

This button component is currently incredibly simple. With more complex components we will obviously have more markup, and will occasionally use multiple named slots to project multiple bits of markup down to the component. For now, we'll stick with that for our button.

Component Props

You'll have noticed by now if you're familiar at all with React that these components look and function very similarly to React components. Along those lines, we're now going to define a prop. An important piece of functionality for a button is to disable that button. Let's use the @Prop() decorator to define a disabled property. We're also going to pass that disabled property down to our actual button. We'll update our class like so:

export class Button {
  @Prop({ reflectToAttr: true })
  disabled: boolean;

  render() {
    return (
      <button disabled={this.disabled}>
        <slot />
      </button>
    );
  }
}

We've defined a property on the class called disabled, and added a @Prop() decorator to it. We've also passed in an object with a reflectToAttr key we've defined to be true. According to the Stencil Prop Docs, using that makes sure our disabled prop stays in sync with an HTML attribute. In this case we definitely want that because we're using a disabled attribute.

We are also adding disabled={this.disabled} to our button in the component. This will conditionally apply the disabled attribute depending on whether or not the disabled prop is defined.

Styling Our Button

Currently this is an ugly HTML button. We're obviously going to change that. I encourage you to come up with your own style guide and design for your components, but you're of course welcome to copy what I'm doing. First off I'm going to create a file at src/styles/variables.scss for my color variables. If I have to change colors, I want it to apply to all the colors rather than change them one by one, so I'm using SASS variables to do that. I'm going to start with my font, a couple basic colors, and my primary color shades which is all I'm focusing on right now.

// Font Family
$font-family: 'Open Sans', 'Helvetica Neue', Arial, Helvetica, sans-serif;

// Basic Colors
$white: #ffffff;
$black: #000000;

// Brand Colors
$blue-steel: #4571c4;
$blue-steel-dark: #315db0;

Now that I've got my font and colors established, I'm going to give my button some classy styling.

@import '../../styles/variables.scss';

:host {
  box-sizing: border-box;
}

:host([disabled]) {
  pointer-events: none;
}

button {
  font-family: $font-family;
  cursor: pointer;
  border: none;
  background-color: $blue-steel;
  color: $white;
  line-height: 20px;
  font-size: 14px;
  padding: 4px 12px;
  border-radius: 3px;

  &:hover {
    background-color: $blue-steel-dark;
  }
  &:active {
    background-color: darken($blue-steel-dark, 5%);
  }
  &:disabled {
    opacity: 0.4;
  }
}

First I'm importing my variables for use. I'm then using the :host selector, which allows us to select the shadow host of the Shadow DOM, for a couple different things. First of all I'm setting box-sizing: border-box to the host element. I personally prefer using the border-box sizing to not take into account borders for the height and width. It makes more sense to me personally. Next I'm using the host selector to only select the host when it has a disabled attribute applied to it. In that case I'm applying pointer-events: none to the element. This makes it so setting a click handler on the element will not fire when the button is disabled.

Next I'm styling my button itself. You'll notice and possibly worry about me globally styling the button element. This is not a problem because we're using the Shadow DOM, and this is one of its best benefits. All of your styling is scoped to the component's Shadow DOM, no styles from outside can penetrate it, and no styles from inside can mess up anything outside of it. It's pretty awesome.

The rest of the styles are pretty straightforward. I have the button styles, the background color darkens on hover, and darkens even more on click. When it's disabled, I apply opacity: 0.4 to make it look disabled.

If you haven't already, make sure you run npm start to start up your dev server and it'll automatically open in your browser. Go ahead and add your button to your index.html page so you can test your component. I added the following markup:

<mtn-button>Button</mtn-button>
<mtn-button disabled>Button</mtn-button>

When your page refreshes automatically you should see your beautiful new button component in both its disabled and non-disabled states!

Next Steps

There you have it! A classy button component that looks great and has basic functionality. There's obviously a lot more to a button (and most components) that will implement, but we'll do that in our next post. See you there!

Simply want to see the end result repo? Check it out here