DEV Community: Asa Smith

Cloud Resume Challenge Week 2

Asa Smith — Tue, 22 Apr 2025 15:22:00 +0000

Since my last update on the Cloud Resume Challenge, I've made several significant changes, resolved some unexpected problems, and refined my overall infrastructure strategy. Here's a detailed overview of my recent progress:

Diagnosing a Certificate Issue (Not Just a Validation Problem)

Initial Problem:
Initially, I suspected my AWS ACM certificate issue was related to DNS validation delays. However, after deeper investigation, I discovered the actual issue stemmed from changing a resource name in my CDK code.

What Actually Happened:

I updated the logical name of my ACM certificate resource within my CDK stack. Although this change seemed minor, it led to unforeseen conflicts with CloudFormation, resulting in confusing errors that were not immediately apparent.
The subtle nature of this issue complicated troubleshooting because CloudFormation events didn't clearly indicate the root cause. This scenario reinforced the importance of careful naming practices when working with infrastructure as code.

Resolving the Issue by Manual Deletion and Redeployment

After pinpointing the issue as a naming conflict, the fastest and most straightforward resolution was:

Manually deleting the entire CloudFormation stack to ensure all conflicting resources were fully removed.
Redeploying the stack using cdk deploy, which cleanly rebuilt my S3 bucket, CloudFront distribution, and ACM certificate without conflicts.

Why Good Naming Conventions Matter

This experience highlights the critical importance of consistent, clear, and stable naming conventions from the outset:

Changing resource names later in development can result in subtle but significant infrastructure conflicts.
Establishing good naming conventions early significantly simplifies troubleshooting and prevents hard-to-diagnose issues.

Completing DNS Validation and Attaching the Certificate

Since my domain (asasmith.dev) is managed externally with Hover, I chose manual DNS validation instead of using Route53:

After I redeployed my stack I used the following cli command to get a list of certificates:

  aws acm list certificates --region us-east-1

Then using the cert's arn and another cli command I was able to get the dns validation info:

  aws acm describe-certificate --region us-east-1 --certificate-arn <CERTIFICATE_ARN>

I added the required CNAME record in Hover’s DNS settings.
Verified DNS propagation, and my ACM certificate status quickly transitioned to ISSUED.

I have since successfully attached this validated ACM certificate to my CloudFront distribution.

Mapping a Subdomain to CloudFront

Additionally, I've configured Hover to map the subdomain resume.asasmith.dev directly to my CloudFront distribution, ensuring visitors can securely access my static resume site using HTTPS. I've confirmed that the subdomain is functioning exactly as expected.

Single-Stack Infrastructure Approach

Previously, I organized my CDK project into multiple stacks based on resource types, complicating dependency management and debugging. Now, I've transitioned to:

A single, unified stack containing all the necessary resources for my static website.
Simpler management, clearer resource dependencies, and easier troubleshooting.

Lessons Learned

Naming conventions: Good, stable, and descriptive naming upfront is essential for avoiding subtle infrastructure conflicts.
Manual resource cleanup: Sometimes deleting and redeploying resources completely is the most efficient path forward.
Infrastructure consolidation: Keeping related resources in a single stack simplifies operations and debugging.

Next Steps

With my static website fully operational, the next phase includes:

Defining and deploying a DynamoDB table to store visitor data.
Creating a Lambda function to interact with DynamoDB (I'm currently considering which programming language to use).
Setting up API Gateway to provide an endpoint to my Lambda function—this will be a learning experience as I haven't worked with API Gateway before.

Stay tuned for further updates as I continue building out and enhancing my Cloud Resume project!

Cloud Resume Challenge Week 1

Asa Smith — Tue, 22 Apr 2025 15:06:00 +0000

Recently I across the Cloud Resume Challenge, and it immediately caught my attention. I’ve been looking for opportunities to get more hands-on experience with AWS, but I haven’t had a structured way to approach it. This challenge seemed like the perfect opportunity—a real-world, end-to-end cloud project that touches multiple AWS services. So, I decided to jump in.

This post is a brain dump of why I’m doing this, what I hope to get out of it, and my progress so far.

Why I'm Doing the Cloud Resume Challenge

For majority of my career I've focused solely on front end development. I've done some backend work with node/express and one time I built a data collection tool in Go. But AWS has, for the most part, been a total black box to me. I know what an s3 bucket is and I have a grasp of iam roles. I can even dig through logs in cloudwatch to try to find errors but that's been the extent of my exposure. but I’ve never actually built something from the ground up using AWS infrastructure as code, IAM roles, API Gateway, Lambda, and DynamoDB.

So I'm doing this challenge for a few reasons:

To get hands-on AWS experience—I learn best by doing, and this is as close to a real-world project as it gets.
To force myself out of my comfort zone—I know enough AWS to be dangerous, but I'd like to actually understand it.
To document my progress and mistakes—I want to write about this experience as I go, partly to help others, partly to remind future me what I did when I inevitably forget.

Week 1: What I've Done So far

Even though this project is relatively simple I want to be mindful of creating an architecture that is representative of real world applications. So while it might be overkill for this I knew I wanted to create three repos for code organization.

cloud-resume-infra
cloud-resume-frontend
cloud-resume-backend

One of the requirements is to not use the AWS console to create any of the necessary resources. I have completed a Frontend Masters course that used AWS CDK (cloud deployment kit) with GO so I already had some exposure to the tool. I chose to use typescript for this project. AWS SAM (serverless application model) templates are another route you could go but since I've never used these before I decided to not use them here. Documentation for CDK can be found here along with a guide for install/setup here.
CDK, as I understand it so far, allows you to write code to define different aws resources. Initializing a project is simple. Just run the following commands in your terminal:

// create a new empty directory for the project
mkdir cloud-resume-infra && cd cloud-resume-infra 

// initialize new cdk app specifying typescript as the language
cdk init app --language typescript

A CDK app is composed of several differnt units. The smallest units are constructs. Constructs are pieced together to create Stacks. Stacks are pieced together to create Apps. The CDK cli tool takes your code an converts it into CloudFormation templates that are deployed from the command line.

The first thing I did was create my S3Stack. All I've done is create an s3 bucket to store my static website files.

import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";
import * as s3 from "aws-cdk-lib/aws-s3";

export class S3Stack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    new s3.Bucket(this, "CloudResumeInfraBucket", {
      bucketName: `cloud-resume-${this.account}-${this.region}`,
      blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
      removalPolicy: cdk.RemovalPolicy.DESTROY,
    });
  }
}

Then I've updated the bin/cloud-resume-infra.ts file to the following:

#!/usr/bin/env node
import 'source-map-support/register';
import * as cdk from 'aws-cdk-lib';
import { S3Stack } from "../lib";

const app = new cdk.App();
const product = 'cloud-resume';

new S3Stack(app, `${product}-s3-stack`); 

app.synth();

Once I've saved both files I need to run npm run build to build out the javascript files and then run cdk deploy to deploy my s3 bucket.

What's Steps

Now that I have the initial CDK setup and an S3 bucket, my next steps are:

Set up IAM roles and policies – I need to make sure my GitHub Actions workflow has the right permissions to deploy site updates.
Automate frontend deployments – I’ll configure GitHub Actions to upload new frontend files to S3 whenever I push to main.
Start planning the backend – I’ll be working on API Gateway, Lambda, and DynamoDB next.

For future posts, I’ll break things down further—IAM setup, GitHub Actions workflows, API design, and more. But for now, this is a solid start.

Here is my cloud-resume-infra repo for reference.

Technical Interview Questions I Wish I Could Do Over #1

Asa Smith — Tue, 22 Apr 2025 14:48:00 +0000

Technical interviews are the adult equivalent of those big test days we had in
grade school that would determine our academic future. They’re challenging to
prepare for because sometimes I know ahead of time what the topic will be
(system design lite) and other times it’s a surprise I learn once I’m in the
interview (build an infinite scroll in react), and there’s almost always
something I wish I could do over after I finish.

This series is intended to be part therapeutic, part knowledge share: a place to
break down questions I wish I could do over. Whether you're prepping for
interviews, brushing up on fundamentals, or just enjoy a bit of technical
storytelling, I hope these posts are useful and maybe even a little cathartic.
Who knows, maybe I'll write about technical interviews I do well in too.

What will be the output of the following code and why?

console.log('start');

setTimeout(function setTimeoutFunc() {
    console.log('timeout');
}, 0);

Promise.resolve().then(function firstPromiseFunc() {
    console.log('promise 1');
});

async function asyncFunc() {
    console.log('async start');
    await Promise.resolve();
    console.log('async end');
}

asyncFunc();

console.log('end');

After taking a minute to read through the code this was my response:

start, timeout, promise 1, async start, end, async end

The actual output is:

start, async start, end, promise 1, async end, timeout

I misunderstood two big parts of the execution model:

how setTimeout and setInterval are handled, even when passed 0 to their delay argument
the microtask queue

There are three key parts to the JavaScript execution model: the Call Stack,
the Microtask Queue, and the Task Queue.

| Call Stack | Microtask Queue | Task Queue |

When the program runs the first line it evaluates is:

console.log('start');

This operation is added to the Call Stack

|    Call Stack      | Microtask Queue | Task Queue |
|       ---          |     ---         |    ---     |
|console.log('start')|

Since this operation is synchronous it is executed immediately and removed from
the stack. So we see start logged and the Call Stack returns to its previous
state.

|    Call Stack      | Microtask Queue | Task Queue |
|       ---          |     ---         |    ---     |

Pretty simple so far.

The next line evaluated is the setTimeout. Here I assumed the setTimeout
would be added to the Call Stack, the timer started, and since it was 0, the
callback function would be executed immediately. But what really happens is the
callback function (setTimeoutFunc()) is added to the Task Queue and the
program moves to the next line to evaluate.

|    Call Stack   | Microtask Queue |     Task Queue  |
|       ---       |     ---         |        ---      |
|                 |                 | setTimeoutFunc()|

The next block of code that is evaluated is:

Promise.resolve().then(function firstPromiseFunc() {
    console.log('promise 1');
});

Since this is an asynchronous function it is added to the Microtask Queue

|    Call Stack   | Microtask Queue |     Task Queue  |
|       ---       |     ---         |        ---      |
|                 |firstPromisFunc()| setTimeoutFunc()|

And the program moves to the next lines:

async function asyncFunc() {
    console.log('async start');
    await Promise.resolve();
    console.log('async end');
}

asyncFunc();

The asyncFunc() is added to the call stack:

|    Call Stack   | Microtask Queue |     Task Queue  |
|       ---       |     ---         |        ---      |
|    asyncFunc()  |firstPromisFunc()| setTimeoutFunc()|

The first console.log statement is synchronous so it is executed logging
async start and then the program gets to the await keyword. await is
syntactic sugar for native Promises so the event loop treats this the same way
it did the previous Promise, the console.log('async end') is scheduled in
the Microtask Queue, and at that point, asyncFunc() is paused and removed from
the call stack. Its remaining execution (everything after the await) will resume
in the microtask phase of the event loop.

|    Call Stack   |     Microtask Queue    |     Task Queue  |
|       ---       |          ---           |        ---      |
|                 |firstPromisFunc()       | setTimeoutFunc()|
|                 |console.log('async end')|                 |                 |

The program then moves on to the last line:

console.log('end');

and since this is a synchronous operation it is added to the stack and executed
immediately.

The end of the program has been reached so the event loop moves to the
Microtask Queue. The Task Queue and the Microtask Queue both operate on a
First in, First out basis. For my example, firstPromiseFunc() was added to the
queue first so it is executed first and promise 1 is logged. Then
firstPromiseFunc() is removed from the queue. The event loop checks to see if
there are any tasks left in the Microtask Queue and since there is it is
executed next and we see async end logged.

Now that the Microtask Queue is empty the event loop moves to the Task Queue
and executes tasks on the same First in, First out basis. For this example we
now see timeout logged.

Key Takeaways

Timer functions, setTimeout and setInterval, never run immediately. Even if the delay argument is 0. The callbacks are added to the Task Queue.
All async code, anything wrapped in a Promise or that comes after await, is added to the Microtask Queue.
The tasks in the Microtask Queue will be executed before the event loop moves to the Task Queue.

This question reminded me how important it is to understand not just what
JavaScript does, but when it does it. Before this technical interview I would've
said I had a good mental model of how async code works but realizing how the
microtask and task queues work helped me connect a few lingering gaps. Now that
I’ve internalized the way the event loop processes Promises, async/await, and
setTimeout/setInterval, I’ll be more confident when questions like this come up.

Next up: a question I actually nailed and how I approached it.

Using Tailwind CSS v3 with Ember JS

Asa Smith — Tue, 11 Jan 2022 15:36:17 +0000

Tailwind CSS v3 has been released and there is a bunch of cool new features available (I'm mostly interested in the "just in time" engine being standard now). The standard setup for an ember project has changed a little and there doesn't seem to be a lot of good resources available for this setup.

Create a new ember project.

npx ember-cli new tailwindcss-demo --no-welcome
cd tailwindcss-demo

Install tailwind and related packages.

npm install tailwindcss autoprefixer --save-dev
# no need for purgecss anymore

Install postcss add on.

ember install ember-cli-postcss

Create tailwind config.

# I create a tailwind dir in styles and add the config file there
# this is a personal organizational choice, the config file could live anywhere
mkdir app/styles/tailwind

# create tailwind config file
# last arg is path to config file
# if no arg is provided it will be created at the root of your project
# this path will be needed when updating ember-cli-build.js
npx tailwind init app/styles/tailwind/config.js

There isn't a purge key in the config file anymore. Update the content key with paths to all template files. The config docs are here

// app/styles/tailwind/config.js

module.exports = {
  content: ['./app/**/*.hbs'],
  theme: {
    extend: {},
  },
  plugins: [],
}

Update app/styles/app.css

/* app/styles/app.css */

@tailwind base;
@tailwind components;
@tailwind utilities;

Update ember-build-cli.js

// ember-build-cli.js

'use strict';

const EmberApp = require('ember-cli/lib/broccoli/ember-app');
const autoprefixer = require('autoprefixer');
const tailwind = require('tailwindcss');

module.exports = function (defaults) {
  let app = new EmberApp(defaults, {
    postcssOptions: {
      compile: {
        // track changes in template, css, scss, and tailwind config files
        cacheInclude: [/.*\.(css|scss|hbs)$/, /.tailwind\/config\.js$/],
        plugins: [
          {
            module: autoprefixer,
            options: {},
          },
          {
            module: tailwind,
            options: {
              config: './app/styles/tailwind/config.js',
            },
          },
        ],
      },
    },
  });

  return app.toTree();
};

That's it. You should be up and running with Ember and Tailwind now!

Repo for this demo.

How to use ember-cli to generate components using pod structure

Asa Smith — Thu, 03 Dec 2020 23:59:11 +0000

The answer to the question above is ember generate component component-name --pods --no-path

Maybe I should back up a bit.

I've been working on an ember project full time for about a year now. I definitely prefer the pods style file layout to the classic style.

If you're unfamiliar, classic style file structure looks like this:

app/
|-- components/
    |-- tags.js
    |-- tags.hbs
|-- controllers/
    |-- post.js
|-- models/
    |-- post.js
|-- routes/
    |-- post.js
|-- templates/
    |-- post.js
|-- app.js
|-- index.html
|-- router.js

while pods looks like this:

app/
|-- components/
    |-- tags.js
    |-- tags.hbs
|-- post/
    |--controller.js
    |--route.js
    |--template.js
|-- app.js
|-- index.html
|-- router.js

The pod structure organizes the file system by feature instead of by entity type which I think is much easier to reason about and navigate.

You can use the ember-cli to scaffold out files for:

routes
controllers
templates
ember-data files

The command ember generate entity-type feature-name would scaffold out the correct file in the correct directory. If you want to use the pod structure you have to pass the --pods option to the ember generate command.

ember generate route feature-name would generate a new route.js file inside the feature-name directory. If the directory didn't exist it would be created. This command will also generate a test file at tests/unit/feature-name/route-test.js

You can also update the .ember-cli config file like so

// .ember-cli
{
    "usePods": true
}

If you try to pass the --pods arg with a "usePods": true config ember-cli will throw a warning that using both is deprecated. The rest of my examples will use the --pods flag.

The problem I had was trying to create a component but I didn't want the component.js file or its template.hbs file to be generated inside of a /components directory. Maybe this is a bad idea. If it is I'm sure the internet will tell me.

The --path option accepts a string as its argument. You can use it to pass a file path. The file path passed must be relative to the /app directory.

app/
|-- post/
    |-- controller.js
    |-- route.js
    |-- template.js
|-- app.js
|-- index.html
|-- router.js

If you want to create an author-info component inside our post directory the ember-cli command would be

ember g component author-info --pods --path="post"

app/
|-- post/
    |-- author-info/
        |-- component.js
        |-- template.hbs
    |-- controller.js
    |-- route.js
    |-- template.js
|-- app.js
|-- index.html
|-- router.js

But what if I want to create a component at the same level as /post?

ember generate component my-component --pods --path=""

Just pass an empty string as the argument. That creates the file structure below.

app/
|-- my-component/
    |-- component.js
    |-- template.js
|-- post/
    |-- author-info/
        |-- component.js
        |-- template.hbs
    |-- controller.js
    |-- route.js
    |-- template.js
|-- app.js
|-- index.html
|-- router.js

There's also an alias for --path="". It's --no-path

ember generate component my-component --pods --no-path