DEV Community: Austin Crim

JavaScript Dev Does Rust: Statements, expressions, and return values

Austin Crim — Wed, 07 Jul 2021 03:03:28 +0000

In Rust, a statement is a piece of code that does not return a value and always ends with a semicolon

let x = 12;

println!("x is {}", x);

An expression is code that evaluates to something. Most Rust code contains expressions.

let y = 2 + 2;  // 2 + 2 is an expression within a statement

do_something()  // do_something() is an expression the returns a value

This distinction is important, especially when reading functions. It might not be obvious what this function is returning at first glance. A function's return value can be the last expression evaluated by body of the function.

fn sum_and_double(x: i32, y: i32) -> i32 {
    let summed = x + y;
    summed * 2  // since this is the last expression, it is implicitly returned
}

summed * 2 is the last expression so it evaluates and returns that value from the function. This would break if we added a semicolon because that would turn the line into a statement.

This code would result in a compiler error for mismatched types because we are not returning an i32, we are returning nothing!

fn sum_and_double(x: i32, y: i32) -> i32 {
    let summed = x + y;
    summed * 2;  // Compiler error! This is now a statement and nothing gets returned from the function!
}

You can explicitly use the return keyword in functions, which is required for returning early, but the implicit return is a de facto standard and you will see it everywhere.

Pay attention to the semicolons!

Introducing Perusing the Platform: Discover the Native Capabilities of the Web

Austin Crim — Thu, 17 Jun 2021 13:42:26 +0000

I'm super excited to announce my latest project, Perusing the Platform! Join me through a series of demos and articles that will introduce the native JavaScript APIs that are built right into the browser.

The web as a platform is extremely powerful, not just because of its unparalleled reach, but also due to the decades of work that the language designers and browser vendors have put in to make it a robust runtime for our applications. You can do so much with just JavaScript and a web browser and that's why I'm creating a resource to help developers discover and understand just how far they can go with vanilla JS.

I just published the first article on PtP all about the Web Notifications API. I would love for you to check it out and feel free to provide me with any feedback!

COBOL'in 🏀: What a 60-year-old language taught me about JavaScript

Austin Crim — Wed, 02 Jun 2021 14:47:24 +0000

Hey, I'm Austin, and I started my career a few years ago as a 20-year-old COBOL developer.

I can already hear the questions:

Why would you subject yourself to that? Why not something relevant? What the heck is COBOL?

COmmon Business Oriented Language is a programming language that showed up in the late 1950s. It saw widespread adoption throughout many large companies and was usually employed for large-scale batch processing. Although it's over 60 years old, it is surprisingly common today. More recently, it got some time in the news when the governor of New Jersey made a public plea for COBOL developers to rescue the state unemployment system.

My COBOL story starts with my father who, after I finished high school, advised me to look into learning COBOL. He was a mainframe developer at a large university for almost the entirety of his career and with many of his contemporaries retiring, he knew that the amount of COBOL code still running would need maintainers with a specific set of skills (insert Liam Neeson gif). Unfortunately, I had to admit he was right. I landed a job as a mainframe engineer after just 18 months in school and started my career path in 2018 using technology from the 1950s.

I only spent a couple of years in that role before I transitioned to a team using a more modern stack and even though I now use things like React and Node every day, I have carried over some of the lessons I learned on the green screens.

Let's take a look at 3 ways that writing COBOL has made me a better web developer.

Requiring Readability 📚

COBOL was designed to be readable by default. Its syntax is intentionally English-like in nature, with statements ending in periods and grouped by 'paragraphs'. Here's an example:

MOVE 5 TO NUM.
ADD 10 TO NUM.
PERFORM UNTIL NUM LESS THAN 10
  DISPLAY NUM
  SUBTRACT 1 FROM NUM
END PERFORM.

While admittedly verbose, it's also free of arcane symbols or abbreviations. Its verbosity is a side effect of its explicitness. Now, I'm not going to say that programming languages need to be designed this way in order to be readable, in fact, even COBOL can't enforce readable code, it can only encourage it. But this general notion of readability as a first-class idea leads me to my first point: prioritizing readability pays off.

We do a lot in the developer world in the name of readability. Everything from syntax highlighting and code formatters to abstractions like classes and functions improves our ability to quickly scan and reason about our code. So much time is spent in this realm because we have realized that readability leads to maintainability. Code that's hard to read is hard to understand, if it's hard to understand, it's hard to fix bugs and add features.

Here are some quick hitters on how to improve the readability of your code:

In general, avoid abbreviations when naming things. They oftn mk ur cod hrdr to read :).
Make purity and immutability the default. Functions that reach outside their scope and variables that unexpectedly change are common sources of confusion in codebases. Do your best to avoid these techniques when practical.
Keep functions small, without being dogmatic. It stands to reason that less code is easier to read than more code. Extracting another function costs very little, but can make a big difference in the long run. See more in the next section 👀.

One caveat that should go without saying, there are scenarios where you have to choose something like performance over readability, but when I write code I first ask myself "Is this readable?" before I try to optimize for anything else.

Function Focused 🧐

COBOL has no scope. If you declare a variable, it is for all intents and purposes, global, even if COBOL'ers wouldn't use that word. COBOL also doesn't have functions. It is procedural, not functional or object-oriented (sorta).

A COBOL program is essentially a long list of instructions that get processed in a sequence. The way we organize these instructions in COBOL is with paragraphs. A paragraph is a named grouping of instructions, like this:

COMPUTE-TOTAL.
    MULTIPLY TAX-RATE BY SUBTOTAL GIVING TAX.
    ADD SUBTOTAL TO TAX GIVING TOTAL.
    SUBTRACT DISCOUNT FROM TOTAL.

With our paragraph defined, we can then execute it whenever we want with the PERFORM keyword.

PERFORM COMPUTE-TOTAL.

Since COBOL has no scope and no functions, it quickly becomes apparent that the frequent use of paragraphs is imperative to maintaining a halfway-decent codebase. Many teams even develop style guides with rules like:

All code must be in a paragraph
Paragraphs must be named clearly
Paragraphs should have one primary responsibility

If these ideas around paragraphs sound familiar it's because many JavaScript developers talk similarly about functions.

Functional programming in JavaScript has become somewhat in vogue as of late and for good reason! If you're like me, you might have thought you hated programming when you were in Java class and got yet another NullPointerException trying to write a tip calculator. But pure functions offer a much clearer mental model: dump values in, get values out, consistently.

Small, pure functions are the easiest to test, read, and maintain, so why not try to build your whole codebase out of such functions? Even COBOL, without the first-class notion of a function, understood code that can be grouped and reused is paramount to building applications for the long haul.

Talking Testing 🧪

Up to this point, my comments on COBOL have been mostly positive, but that's about to change. The biggest hurdle in my time as a mainframe dev was testing my code. By their very nature, most COBOL codebases are supporting old, long-running processes and applications. They are often products of many different developers making changes over decades and, due to the lack of tooling, the resulting code is not easy to test. Impact analysis and unit testing were by far the most time-consuming tasks in any feature request or bugfix. There is rarely a path forward on how to execute your program under certain conditions or identifying what parts of the codebase your change might negatively affect.

Again, I mainly attribute this to the lack of sophisticated tooling and it brings me to my final point, automated testing in JavaScript is a gift.

To the chagrin of some, the JavaScript ecosystem has an embarrassment of riches when it comes to choice. There is an NPM package for checking if a number is even, for goodness sakes. Search NPM for "testing" and you get back 14,534 results. The point is you can write tests in just about any way imaginable; the barrier to entry has never been lower. Having an automated test suite in place skyrockets developers' confidence, encourages frequent refactors, and can singlehandedly change the future of a given application.

There are umpteen resources out there telling you why testing is important, so I will stop preaching here, but I will offer up a couple thoughts on getting started.

Focus on the highest value, lowest friction tests first. End-to-end web tests using something like Cypress is a great way to ensure the main functionality of your app is working before you get to production.
Run tests automatically and frequently. Whether in continuous integration or a git hook, make sure your feedback loop is short and you get informed of test failures at the right times.
Kent C. Dodds puts it best: "The more your tests resemble the way your software is used, the more confidence they can give you."

Closing Comments 🚪

When COBOL was released in the 1950s, programmers wanted to write resilient applications that solved problems and while our tools have changed dramatically, I would argue our goals mostly remain the same. Frameworks and languages come and go at a breakneck speed, but if we can glean principles from those who came before us, our knowledge will stand the erosion of time, not unlike a lot of COBOL code still running today.

Thanks for your time.

AWS CDK with Go: Hello World

Austin Crim — Tue, 11 May 2021 22:02:28 +0000

Background

I recently started exploring the AWS CDK using Go. The Go CDK library is currently in Developer Preview, meaning the APIs are subject to change and it should not be used in production. However, it should be used to experiment and provide feedback to AWS!

I wanted to spin up a simple Lambda fronted by API Gateway to create an HTTP API, a very common use case. I have pasted the full source of both the CDK and the Lambda handler below.

// lib/cdk.go
package main

import (
    "os"

    "github.com/aws/aws-cdk-go/awscdk"
    "github.com/aws/aws-cdk-go/awscdk/awsapigatewayv2"
    "github.com/aws/aws-cdk-go/awscdk/awsapigatewayv2integrations"
    "github.com/aws/aws-cdk-go/awscdk/awslambda"
    "github.com/aws/constructs-go/constructs/v3"
    "github.com/aws/jsii-runtime-go"
)

type GoCdkStackProps struct {
    awscdk.StackProps
}

func NewGoCdkStack(scope constructs.Construct, id string, props *GoCdkStackProps) awscdk.Stack {
    var sprops awscdk.StackProps
    if props != nil {
        sprops = props.StackProps
    }
    stack := awscdk.NewStack(scope, &id, &sprops)

    // The code that defines your stack goes here

    function := awslambda.NewFunction(stack, jsii.String("gofunction"), &awslambda.FunctionProps{
        FunctionName: jsii.String("hellogo"),
        Code:         awslambda.AssetCode_FromAsset(jsii.String("../handler"), nil),
        Handler:      jsii.String("handler"),
        Runtime:      awslambda.Runtime_GO_1_X(),
    })

    integration := awsapigatewayv2integrations.NewLambdaProxyIntegration(&awsapigatewayv2integrations.LambdaProxyIntegrationProps{
        Handler:              function,
        PayloadFormatVersion: awsapigatewayv2.PayloadFormatVersion_VERSION_1_0(),
    })

    api := awsapigatewayv2.NewHttpApi(stack, jsii.String("goapi"), &awsapigatewayv2.HttpApiProps{
        ApiName: jsii.String("hellogoapi"),
    })

    api.AddRoutes(&awsapigatewayv2.AddRoutesOptions{
        Path:        jsii.String("/"),
        Integration: integration,
    })

    return stack
}

func main() {
    app := awscdk.NewApp(nil)

    NewGoCdkStack(app, "GoCdkStack", &GoCdkStackProps{
        awscdk.StackProps{
            StackName: jsii.String("GoCDKStack"),
            Env:       env(),
        },
    })

    app.Synth(nil)
}

// env determines the AWS environment (account+region) in which our stack is to
// be deployed. For more information see: https://docs.aws.amazon.com/cdk/latest/guide/environments.html
func env() *awscdk.Environment {
    return &awscdk.Environment{
        Account: jsii.String(os.Getenv("CDK_DEFAULT_ACCOUNT")),
        Region:  jsii.String(os.Getenv("CDK_DEFAULT_REGION")),
    }
}

// handler/main.go
package main

import (
    "context"
    "fmt"

    "github.com/aws/aws-lambda-go/events"
    "github.com/aws/aws-lambda-go/lambda"
)

func HandleRequest(ctx context.Context, request events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
    name := request.QueryStringParameters["name"]
    if name == "" {
        name = "Friend"
    }
    return events.APIGatewayProxyResponse{Body: fmt.Sprintf("Hello, %s!", name), StatusCode: 200}, nil
}

func main() {
    lambda.Start(HandleRequest)
}

Allow me to highlight a few concepts that tripped me up.

Finding the Go CDK packages

Since the CDK bindings for Go are currently in developer preview, the documentation is not quite as fleshed out as the other supported languages. This made getting started a little hairy. In the end I found most of what I needed here, after selecting the v2 release candidate from the menu in the top right.

One major benefit of CDK 2.0 is having all the various packages under a single namespace. This makes it trivial to grab more dependencies as you go, simply changing the last node of your import statements.

jsii.String()?

Most examples of Go CDK that I found on AWS' docs included calls to jsii.String() or similar. This call has to wrap any literal data types that you wish to pass, such as string or integer primitives. All construct options structs take pointers, even for things like strings or integers. This is because Go does not natively support optional struct fields. jsii.String() will automatically provide a pointer to your string literal value, this allows for a nil pointer to be used for optional fields that you choose not to provide.

Specifying a Lambda Handler

awslambda.NewFunction(stack, jsii.String("gofunction"), &awslambda.FunctionProps{
    ...
    Handler:      jsii.String("handler"),
    ...
    })

This option took me the longest to figure out and partially inspired me to write this post. When specifying the Handler option of a new Lambda function, you specify the name of the executable file generated by go build. So in my scenario, I have a folder named handler that contains a main.go file. When built, this creates a handler executable. This is what needs to go in the Handler struct field.

Another important note, when building your executable, you have to run GOOS=linux go build or the Windows equivalent. This tells the Go cli to build an executable for the Linux OS which is where your Lambda will actually run. If you don't do this, you will get a runtime error when executing your lambda.

That wraps it up for this post, let me know if you run into any other common issues I could add!

How I Added Themes to My Website Using Tailwind

Austin Crim — Thu, 08 Apr 2021 19:17:27 +0000

Background

I recently added theming to my website and I wanted to quickly jot down my implementation. I ran into a little friction along the way, but I am really happy with how the result looks and feels. I'm excited about adding even more themes!

A lot of this is based on Tailwind Labs' own theming video and I highly encourage you to start there if you are interested in adding themes with Tailwind. All code examples will assume that your project is already integrated with TailwindCSS.

Note ⚠️: Most of this article applies to any site, regardless if you use TailwindCSS. If you're not using Tailwind, feel free to read on, you might learn something!

Overview

The modern mechanism for theming on the web today is through CSS Custom Properties (aka CSS Variables). They are incredibly flexible and make theming much simpler than it used to be. A basic workflow for adding theme support to a website looks something like this:

define color palettes in CSS variables
use CSS variables wherever a theme-specific value is needed
add/remove theme class names in the DOM based on some action (button click, dropdown select, etc.)
optionally persist a user's preference

In Tailwind, an extra step is required somewhere in that list: generating new class names with your tailwind.config.js. Therein lies the rub that makes theming with Tailwind different. I found this process to offer some friction, but being a major TW lover, I persevered in the name of not writing custom CSS classes by hand.

Defining Your Palette in CSS Variables

This step honestly contained the bulk of the time spent in my case. I was trying to craft each theme from scratch, so coming up with all of the color values took a decent amount of trial and error.

Using the full TailwindCSS color palette as a reference, I copied and pasted RGB values into my CSS variables to preview them on my site. Not the best workflow, but I stuck with it and got a good result. I wanted to stay within Tailwind colors, but unfortunately, I don't know of a way to reference Tailwind colors in a plain CSS file. This resulted in my copy/paste workflow which, in my opinion, was the most painful part of the whole theming process.

After finishing a theme, my CSS would look something like this:

.theme-dark {
    --color-base: 17, 24, 39;                /* gray-900 */
    --color-text-base: 243, 244, 246;        /* gray-100 */
    --color-off-base: 31, 41, 55;            /* gray-800 */
    --color-text-muted: 229, 231, 235;       /* gray-200 */
    --color-muted-offset: 209, 213, 219;     /* gray-300 */
    --color-primary: 147, 197, 253;          /* blue-300 */
    --color-secondary: 96, 165, 250;         /* blue-400 */
}

As you can see, I attempted to name my variables generically enough to be reusable while maintaining clarity. I have a few base colors for backgrounds and text, as well as offsets, a primary, and a secondary. You can include as many different variables as your theme requires, but I tried to keep it reasonably simple.

Generating and Using New Theme Classes

Once you have your themes outlined in CSS variables, you've done the hard bit. Now we are almost to the fun part! To use these dynamic theme colors in Tailwind, you have to generate utility classes using the config file. If you have never tweaked a tailwind.config.js file, this step might take some getting used to, but it is fairly straightforward once you have had some practice.

Here's a snippet from my config file:

(For an explanation on the withOpacity function, please refer to the Tailwind Labs video linked above.)

function withOpacity(variableName) {
    return ({ opacityValue }) => {
        if (opacityValue) {
            return `rgba(var(${variableName}), ${opacityValue})`;
        }
        return `rgb(var(${variableName}))`;
    };
}

module.exports = {

   ..., 

   theme: {
        // we want to extend the current colors instead of replacing them
        extend: {
        // this will generate utilities like `bg-base` and `bg-primary`
            backgroundColor: {
                base: withOpacity('--color-base'),
                'off-base': withOpacity('--color-off-base'),
                primary: withOpacity('--color-primary'),
                secondary: withOpacity('--color-secondary'),
                muted: withOpacity('--color-text-muted'),
            },
        // these classes end up like `text-base` and `text-primary`
            textColor: {
                base: withOpacity('--color-text-base'),
                muted: withOpacity('--color-text-muted'),
                'muted-offset': withOpacity('--color-muted-offset'),
                primary: withOpacity('--color-primary'),
                secondary: withOpacity('--color-secondary'),
            },
      }
}

Since our utility classes reference CSS variables, their values will respond when we toggle our theme classes. In my example, I only generated utilities for backgroundColor and textColor specifically. You can generate classes for any applicable properties or generate classes for all color properties using the theme.extend.colors key in the config.

Now using these classes is as simple as this:

<span class='theme-dark bg-base text-primary'>
  Hello Tailwind Themes!
</span>

It's also important to apply a theme class by default to ensure correct styling on the initial page load. You can also define your base theme on the CSS :root selector and those values will take effect by default, without adding any extra classes.

Switching Themes on the Fly

Now that we have our classes generated and applied, we can start switching themes! This process just consists of toggling different class names on the document. On my website, I show a list of the different available themes and, when one is clicked, I run something like this:

 document.documentElement.classList.replace(currentTheme, newTheme);

Here, I am replacing the current theme class with whatever the user has selected. I'm doing it on the documentElement but you can apply this to wherever you want your top-level theme class to live.

Note ⚠️: My website uses React, so I track the currentTheme in a piece of state. However, this can be done in several ways in vanilla JavaScript, like a global variable or a data-theme attribute. The important part is that you swap out the current theme for the user's selection.

Hanging on to a User's Choice

If you've made it this far, congrats! You now have fully functioning themes on your site. But you might notice if you select a theme and refresh the page, you've lost your choice! This is where data persistence comes into play. Don't worry, it can be really simple! Here's a look at how my site does it:

function pickTheme(newTheme) {
    if (newTheme === current) return;
    document.documentElement.classList.replace(current, newTheme);
    localStorage.setItem('crimTheme', newTheme);
    setCurrent(newTheme);
}

This pickTheme function is called when a theme choice is selected.

Let's break it down:

return early if they selected the theme that's currently applied to prevent unnecessary work
replace the current theme class with the new one
save the user's choice in browser local storage
update my current theme state (React style)

This is a great start! Now when a user selects a new theme, we get it applied to the DOM and then save it to the browser's local storage.

There is one more step we have to do before the whole experience works smoothly. Currently, even though our theme choice is in local storage, if we refresh the page we don't see any difference. On page load, we need to check local storage and get the theme applied right away, before the user sees the default theme. Here's what I did:

// theme.js
if (localStorage.crimTheme) {
    document.documentElement.classList.add(localStorage.crimTheme);
} else {
    document.documentElement.classList.add('theme-light');
    localStorage.setItem('crimTheme', 'theme-light');
}

Not too bad! We first check local storage for our theme and apply it if it exists. If not, we set them up with the default theme. I load this theme.js file directly in my index.html to ensure it runs early enough to prevent flashes.

Conclusion 🎉

Big kudos to you if you made it this far. We have accomplished a lot!

Let's review:

We set up our themes with CSS variables
We generated custom Tailwind classes to apply our CSS variable values
We allowed users to swap themes by updating our theme class in the DOM
Finally, we boosted the user experience by saving and retrieving a user's theme preference in local storage

Theming adds a lot of personality to sites and I hope to see more of it in the future. Reach out and show me your themed sites!

Svelte Pomodoro Timer

Austin Crim — Mon, 06 Jul 2020 23:37:20 +0000

I have been wanting to beef up my Svelte skills and what better way than a quick project! I just finished up a simple Pomodoro Timer.

Check out the app here and the source here.

Let me know what you think!

Quick CSS Transition Explainer

Austin Crim — Tue, 30 Jun 2020 19:34:59 +0000

CSS transitions are easy to use and really add that final touch of polish to a UI. I love transitions and they make a site look more professional when used correctly. They were a little confusing at first for me, so I decided to whip up a quick CodePen showing how transitions are written.

Transitions are used to smoothly transition from one style to another. Here's an example using a button with hover and active states.

Thanks for reading!

Recreating the macOS Mail UI

Austin Crim — Tue, 23 Jun 2020 21:54:55 +0000

After seeing the design of the newly announced macOS, Big Sur, I decided to try to remake the user interface of the macOS Mail app. I used TailwindCSS and Heroicons by Steve Schoeger to help me along.

Check it out here (not mobile friendly) and look at the source here.

Let me know what you think!

Rebuilding My Personal Site with Next.js and TailwindCSS

Austin Crim — Tue, 26 May 2020 19:00:51 +0000

Background

After publishing the first iteration of my personal website around a year ago, I grew tired of the design and wanted to explore the new technologies I had been learning. My old site was written in plain HTML and CSS using the Bootstrap 4 framework. This was a great exercise at the time and it taught me some important lessons about CSS and design in general, but it was time for change.

Here is what my old site looked like: Old Website.
And this is the new and improved version: New Website.

The New Stack

My new portfolio site is built using Next.js and TailwindCSS. I love both of these technologies and their developer experience is top notch. I definitely recommend checking out these frameworks if you're interested in React or CSS.

Using Next.js

Currently, my portfolio site is a single page, statically generated by Next. It reads in data at build time to create the HTML, allowing the server to respond with static HTML for fast rendering. Here's how easy it is to get data at build time:

// index.js
export async function getStaticProps() {
    const { skills } = JSON.parse(
        fs.readFileSync(path.join(process.cwd(), 'data/skills.json'))
    );
    const { projects } = JSON.parse(
        fs.readFileSync(path.join(process.cwd(), 'data/projects.json'))
    );
    return {
        props: {
            skills,
            projects,
        },
    };
}

I can then access this data in my homepage like this:

// index.js
const Index = ({ skills, projects }) => (
    {
        skills.map((skill, index) => (
            <SkillCard
                title={skill.title}
                image={skill.imagePath}
                alt={skill.alt}
                key={index}
            />
        ))
    }
)

In my case, I'm reading files to get my data, but you could do any kind of data fetching here: API calls, database queries, you name it. You can read more about SSG (static site generation) here.

Using Tailwind

I have been an huge fan of Tailwind ever since I discovered it. I find the utility-first workflow helps me move faster as a developer and the built-in classes allow me to produce more consistent, intentional designs. I was wary of Tailwind when I first read about it and it does come with trade-offs, but I was hooked after the first time I actually used it to build something. I would encourage anyone interested in Tailwind to give it a try before forming strong opinions.

Future Plans

While I am happy with how my new design turned out, I have some future additions I wish to make. I want to further my knowledge of Next.js by adding a blog, complete with a built-in Markdown editor for posts. I also need to transition the new website to my preferred domain: austincrim.me. The last thing on my backlog is a fan-favorite: dark mode.

The source for my portfolio site can be found here.

Thanks for reading and feel free to offer feedback or comments!

Cooking in quarantine? Check out this Twilio recipe finder!

Austin Crim — Wed, 08 Apr 2020 18:49:58 +0000

What I built

With a growing populace "sheltering in place" and restaurants closing their doors temporarily, the need for home cooking is on the rise and if you're anything like me, you are lacking inspiration. That is why I decided to help myself out with a recipe finder! Simply send a text to +1 (202) 952-8194 with a comma separated list of ingredients and receive delicious recipes. If only Twilio could cook the meals too...

You can also send a number as the last parameter to specify how many recipes to bring back (e.g. Carrots, potatoes, 7). Keep in mind, each recipe will be a separate text message and contain an image.

How I built it

I wrote the project in NodeJS and it is currently hosted on Heroku. I utilized Twilio's programmable SMS API as well as the Spoonacular recipe API.

Here's the source code.
FYI, I'm currently working through an issue where Twilio is slow to post my message to my app. This causes intermittent delays in the recipe response. Thanks for understanding!

Let me know what you think in the comments!