I revisited a passage from Sir Terry Pratchett's "A Slip of the Keyboard." The essay "Magic Kingdoms" illustrates the English dedication to maintaining a garden in any environment. Pratchett uses this as an exemplification for how the garden is a portal to another world, and a widespread fascination with planting a garden is why fantasy is part of the fabric of the culture.

I remember a back garden I used to see from the train. It was a very small garden for a very small house, and it was sandwiched between the thundering railway line, a billboard, and a near-derelict factory.

I don't know what a Frenchman or an Italian would have made of it. A terrace, probably, with a few potted plants and some trellis to conceal the worst of postindustrial squalor. But this was an Englishman's garden, so he'd set out to grow, if not Jerusalem, then at least Jerusalem artichokes. There was a rockery, made of carefully placed concrete lumps (the concrete lump rockery is a great British contribution to horticulture, and I hope one is preserved in some outdoor museum somewhere) There was a pond; the fish probably had to get out to turn around. There were roses. There was a tiny greenhouse made of old window frames nailed together (another great British invention). Never was an area so thoroughly gardened, in fact, as that patch of cat infested soil.

No attempt had been made to screen off the dark satanic mills, unless the runner beans counted. To the gardener, in the garden, they did not exist. They were in another world.

For me there's another comfort in the scene. Even if we're not nurturing plants, we all have the means to cultivate our own creative gardens. A sketchbook, journal, blog, a song. And it doesn't matter how humble! A jar of soil and basil goes a long way for bringing life to a space. So it is with strumming strings and moving the pencil.

A very warm color palette for crazy hot summer days.

Continuous Integration/Continuous Deployment has many benefits in a team's development process! Much of the manual work of pushing changes to production are automated, different processes can be created between staging and production environments, and setting up a CI/CD flow can be a way of practicing Infrastructure As Code. The benefits to having the deployment process documented are all the same as using git in your application code: it's clearly documented, changes can be reverted, and there's a single source of truth for the process.

Here I'll be continuing on from deploying a Docker Image to AWS! This time, looking at integrating the process into a CI/CD process. Namely: CircleCI!

Setup

To configure CircleCI, we'll add this file as .circleci/config.yml from the root of our application:

version: 2.1
orbs:
  aws-cli: circleci/aws-cli@4.0
  aws-ecr: circleci/aws-ecr@9.1.0
  aws-ecs: circleci/aws-ecs@4.0.0

Here I'm loading in all the necessary orbs that will support our deployment. Orbs can be thought of as a group of pre-defined jobs that support integrations. Let's continue setting things up and seeing these orbs in action:

Checkout Repo

Much of the heavy lifting here will be done by the orbs we're pulling in. The only custom job we'll need to employ is one for checking out our repo on github:

jobs:
  checkout-repo:
    docker:
      - image: cimg/node:20.14
    steps:
      - checkout

Stepping Through the Workflow

Below the jobs block, it's now time for us to setup our workflow! This is the access point where CircleCI will call our commands and run our jobs.

I'm going to start by naming the workflow build-app. Under jobs, I'll start with the checkout-repo flow we just created:

workflows:
  build-app:
    jobs:
      - checkout-repo:
          name: checkout-repo
          filters:
            branches:
              only:
                - main

Here, I'm also targeting which branch triggers a build. Anytime a PR is merged into main, the process will fire off.

Next, let's build our docker image. We're going to be configuring the aws-ecr/build_and_push_image job:

  - aws-ecr/build_and_push_image:
      requires:
        - checkout-repo
      account_id: ${ID}
      auth:
        - aws-cli/setup:
            role_arn: ${ROLE}
            role_session_name: CircleCISession
      dockerfile: Dockerfile
      repo: ${REPO}
      tag: ${CIRCLE_SHA1}
      extra_build_args: >-
        --build-arg API_KEY=${API_KEY}

Most of these will be self explanatory if you've deployed to ECR before. One thing worth noting specific to CircleCI is the requires block. Here, we're adding checkout-repo as a dependency. I want the job to run sequentially, so here I'm telling CircleCI to wait for the previous step to complete before starting this one.

Also note that I'm passing in CIRCLE_SHA1 to the tag. I'm tagging images here with the unique hashed identifier. This way, all of my images are uniquely identified in ECR. The CIRCLE_SHA1 variable comes for free in any workflow.

Finally, we'll deploy to our ECS service by updating the service:

  - aws-ecs/deploy_service_update:
      requires:
        - aws-ecr/build_and_push_image
      cluster: ${CLUSTER}
      family: ${FAMILY}
      service_name: ${SERVICE}
      container_image_name_updates: container=${CONTAINER}, tag=${CIRCLE_SHA1}
      force_new_deployment: true
      auth:
        - aws-cli/setup:
            role_arn: ${ROLE}
            role_session_name: CircleCISession

Again, much should be familiar from the CLI approach. What's worth highlighting is the container_image_name_updates property. Since I'm defining the hashed id as the tag name in the previous job, I'm going to update my container image through the arguments container=${CONTAINER}, tag=${CIRCLE_SHA1}

The force_new_deployment argument is required for new changes to be pushed if the task is already running on ECS. (Which it likely is since this is continuous deployment!)

Full Config

That's it! That's enough to get the app spun up and running. Here's the full config for context:

version: 2.1
orbs:
  aws-cli: circleci/aws-cli@4.0
  aws-ecr: circleci/aws-ecr@9.1.0
  aws-ecs: circleci/aws-ecs@4.0.0

jobs:
  checkout-repo:
    docker:
      - image: cimg/node:20.14
    steps:
      - checkout

workflows:
  build-app:
    jobs:
      - checkout-repo:
          name: checkout-repo
          filters:
            branches:
              only:
                - main
      - aws-ecr/build_and_push_image:
          requires:
            - checkout-repo
          account_id: ${ID}
          auth:
            - aws-cli/setup:
                role_arn: ${ROLE}
                role_session_name: CircleCISession
          dockerfile: Dockerfile
          repo: ${REPO}
          tag: ${CIRCLE_SHA1}
          extra_build_args: >-
            --build-arg API_KEY=${API_KEY}
      - aws-ecs/deploy_service_update:
          requires:
            - aws-ecr/build_and_push_image
          cluster: ${CLUSTER}
          family: ${FAMILY}
          service_name: ${SERVICE}
          container_image_name_updates: container=${CONTAINER}, tag=${CIRCLE_SHA1}
          force_new_deployment: true
          auth:
            - aws-cli/setup:
                role_arn: ${ROLE}
                role_session_name: CircleCISession

Austin Kleon lately has written a few pieces on how "you don't need a vision." He makes the case that visions are for things that already exist in the world, where art is the process of creating what doesn't already exist. In response to "Vision is everything:"

...this all sounds very inspiring — it really does pump you up! — but for much of my life, it would have been almost useless advice, because I didn’t really see any of my career coming. There was no clear path back then to where I am now.

It's this way on a project level just as much as it is on a life-sized scale. Many projects don't start with a crystal clear vision of what's going to make it on the page.

Sometimes the wind is in your sails, a vision for the project is so clear that it practically writes itself. Those can be so thrilling!

The only way we get those, in my experience, is with many projects that start in dark caves.

The lights are out and there's little sound.

Perhaps there's a north star, or a breeze indicating a path to follow. So much of the start can be groping in the dark, feeling the walls and floor gently, finding an indication of the way forward.

Dead ends are reached. Steps retraced. Sometimes early, sometimes late.

Sourced Via Kleon on No such thing as waste, Lynda Berry writes about this searching when drawing with four year olds:

I often find drawings begun and then abandoned… Something is not quite right and they need to start over. Then comes the issue of wasting paper. And of finishing what they started. But what if we were…talking about a kid learning to play the trumpet, trying to play a certain note by repeating it… Getting the hang of it, making it natural. Would we say they are easing notes? It took 12 index cards to come to this image.

Projects start here, but I'm finding that even seasons follow this pattern. For me, fall and spring are highly generative times of year, while winter and summer I find myself slowing down. It's applied across the board to software, music, art, and writing.

The challenge is to look at that cavern not as a discouraging block. But as a part of the process.

The predominant culture values linearity, but nature works in seasons and cycles. Overlooking that can make the cave feel never-ending.

Derek Sivers writes about how the two ideas are in contrast in "Explorers Are Bad Leaders:"

Explorers poke through the unknown, experimenting, trying many little dead-ends.

Explorers meander, constantly changing directions based on hunch, mood, and curiosity.

Explorers are hard to follow. It’s better to let them wander alone, then hear their tales...

Leaders are easy to follow. Leaders say, “Here’s where we’re going. Here’s why this will improve your life. Here’s how we’re going to get there. Let’s go.”

...Leaders go in a straight line. Leaders simplify.

Explorers are bad leaders.

Keeping a creative practice is contingent on the extent to which you are comfortable with submerging yourself in the dark time and time again.

Giving up on the search means being closed off to finding the way forward. Returning to the dark, though, means there's a chance of a new path being discovered.

That honestly is what ends up being the fun part of the process. It's an act of discovery when a piece starts to come alive, or when a practice continues to mature and grow after years.

It repeats time and time again. Since, as Gene Wolfe told Neil Gaiman "You never learn how to write a novel, you only learn to write the novel you’re on.”

I love what this means for a creative life. As Kleon put it at the start of this piece, In Free Play, Stephen Nachmanovitch speaks to practice as a means of uncovering oneself over time:

The Western idea of practice is to acquire a skill. It is very much related to our work ethic, which enjoins us to endure struggle or boredom now in return for future rewards. The Eastern idea of practice, on the other hand, is to create the person, or rather to actualize or reveal the complete person who is already there. This is not practice for something, but complete practice, which suffices unto itself. In Zen training they speak of sweeping the floor, or eating, as practice. Walking is practice.

With this piece done, I'll be stepping back into the cavern. Listening for the next indication forward.

Listen on Youtube

Getting back in the saddle on guitar! Been doing studies out of the Berklee Method to become one with the fretboard 🧘

🦊 🌠

Watched Neon Genesis Evangelion the other night. Still thinking about the colors and moods.

This month marks five years since I decided to crack my knuckles and learn JavaScript! I started mostly out of curiosity, partly as a pastime to balance my music teaching job, and eventually to explore a brand new career path.

Now firmly settled into the field, I'm surprised with how much I've learned about myself. Particularly, how I never expected to be doing this kind of work growing up, how it's been even more fulfilling than teaching music, and how well the field supports a life of exploration.

Life Can Only Be Understood Backwards

I'm grateful to have grown up alongside the web. Heck, I was born just a few years before Windows 95!

Now in retrospect, it almost seems inevitable I'd end up in software. But at the time, when I was younger, it was just a fun hobby with infinite ways to play around.

I find myself stunned by how well the timing of my life worked out to bring me here. Firstly, by how open and experimental building online was back in the 90's and 2000's.

Jim Nielsen illustrates this in "Making a Website is for Everyone":

I made my first website as a young teenager because the barrier was so low (and I dropped out of my very first computer science course after the very first class because the barrier seemed so high)... I absolutely love the idea of actively preserving a low barrier to entry for future generations of people.

The web’s low barrier to entry led me to a career that has been a boon for my life. I hope it can do the same for others.

It didn't even take JavaScript to get a website going then! It was accessible and free. Something very down to earth while also being exciting and full of places to explore!

I also lucked out with a tinge of right-place-right-time with my career. I was early on enough in my life a few years ago to take a risk on switching fields. That intersected with a general need in the market for more programmers, regardless of educational background. (I know the past couple of years are an exception to that, but I hold optimism that the pendulum will swing the other way with time.)

My parents didn't know that HTML and CSS would lead to a career. (Somehow music was more promising to all of us??) If anything, sometimes I was told I was spending too much time in front of these dang computers! But, here we are.

To paraphrase Austin Kleon in Steal Like An Artist: Never throw any part of yourself away. I was tempted as a musician to be only a musician, but I kept up with tinkering on computers. I didn't realize that putting together websites for music projects would eventually lead me here.

I suppose it's true! As Kierkegaard puts it, "Life can only be understood backwards, but it must be lived forwards."

Giving Through Creation

Artist Carolyn Yoo and I are both 32. My favorite line from her 23 lessons upon turning 32 is this one:

Give however you enjoy giving, whether that’s through food, money, knowledge, or presence. All forms of giving have immense value depending on the recipient.

I have the good fortune of knowing many people for whom Service means a direct, one on one connection. Teaching, chiropractic, volunteering.

I've felt at odds for a while. The type of service I give isn't that obvious on the surface. This was especially poignant when I left teaching. How could anything beat shaping the next generation?

However, Carolyn's perspective here mirrors what I've come to find in software. There are some people who's greatest gifts are in engaging with the process of creation and sharing what they make. And hey, wouldn't you know it, that's me!

There are many ways to create things that serve people. What I've found, though, is that software is one of the most well supported, widely appreciated, and broadly impactful mediums to create through. Likely, if this is your chosen field, your gift is in making.

Lead With Curiosity

Software has been one of the most natural things in the world. I'm surprised by how never-ending my curiosity is in the field. With programming, I wake up lead by the call to explore something new. And there's no end to where that road will go.

If there's anything to share at this milestone, I'd share advice that I recently passed on to a friend entering the field. Let curiosity lead the way.

Put yourself in a position where you have a chance to explore broadly and/or deeply. Continually find new things to learn. Once you've learned and made enough, you'll get paid to do it all over again in a new way, all the while helping people solve real problems.

Maybe for you that's in another field! But I'll say that Software is a discipline where the work supports exploration profoundly well.

Here's to many more rotations in the cycle of learning, creating, and serving!

🌄

There are great benefits to be had when bundling an application in a Docker Image. Namely, maintaining control over the environment, including runtime versions, package managers, and environment variables. From a development standpoint, developing with docker can ensure all those same benefits on your local machine, instilling confidence that there won't be any unforeseen errors due to a difference in build environment.

So! Today I'll dive into how you can take your docker image and throw it up on AWS for deployment.

Services

We'll be looking at using two services: Elastic Container Services (ECR) and Elastic Container Registry (ECR)

ECS is the platform which will actually enable us to setup the hosting environment for our application. When configured with AWS Fargate, much of the nitty gritty of instantiating separate services is taken care of.

ECR is the AWS proprietary image repository for hosting your docker image on build. ECS will reference our specified repo to find the image to build our app from. ECR stores images based on versions, or tags as they're called. You can set a tag by version number or any other unique identifier, and then rollback if you ever need to.

Setting Up the AWS Services

To setup ECR and ECS, I'll recommend logging into to the AWS console and setting up your repo in ECR and creating a Service and Task in ECS. The sensible defaults should be ok with getting you started. Official AWS tutorials may be helpful to reference as you do so.

To keep this post brief, I'll be focusing on the CLI deployment.

Deploying to ECR

Assuming we have a working Dockerfile and application, here's how we can get started.

We'll start with building the image locally. This can later be automated in a CI/CD process. For now, though, we'll do it through the command line:

$ docker build --no-cache -f myapp.Dockerfile -t <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/<ECR_REPO_NAME>:<TAG> .

Be sure to run this from your project directory, or change the . to refer to the root of your project.

Biggest thing to note here is that we're tagging our image with the -t flag. The tag we are giving it should match with all of the AWS specific variables provided above.

Once that's done, we'll log in and retrieve AWS permissions to push our image in the following step:

$ aws ecr get-login-password --region <region> | docker login --username AWS --password-stdin <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com

Be sure that you have in your env variables the appropriate AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. Those will override any variables set in your aws command line profiles.

From there, we're set to push the image!

$ docker push <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/<ECR_REPO_NAME>:<TAG>

Running Your ECS Task

You can run your task from the AWS portal, though while we're here, we may as well fire it up from the command line!

$ aws ecs run-task \
  --cluster <CLUSTER_NAME> \
  --launch-type FARGATE \
  --task-definition <TASK_DEF> \
  --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}"

Swapping all of your appropriate variables here will enable you to spin up the application, now deploying to a subnet of your choice and soon running on AWS!

Collectathon Island's magical power-orbs have been scattered all over the place! We need a lovable 3D anthropomorphic mascot to use their signature jumping and running abilities to return them all.

Inspired by Richard Jacques, David Wise, and countless summers playing platformers.

Purchase on 🤘 Bandcamp and Listen on 🙉 Spotify or any of your favorite streaming services!

Listen on Youtube

From FFX! Wildly beautiful. For 9 year old Chris, this was the midi arrangement that played on his Neopets page! 😂

Been thinking about Chrono Trigger lately! "Ma'am, you're mistaken, I'm not a pet, I'm a Knight and master swordsman."

Listen on Youtube

Lingering musical thoughts after the Maggie Rogers & Leon Bridges duet in Dallas

Music making really pivoted for me once I started asking what success in that realm meant for me. There are plenty of prescribed defenitions. The surprise came when I reached the end of a success script empty handed.

So, here are a few different voices in support of taking the time to answer that question.

From Derek Sivers:

Never forget that you can make your role anything you want it to be.

Anything you hate to do, someone else loves. So find those people and let them do it.

For me, I loved sitting alone and programming, writing, planning, and inventing. Thinking of ideas and making them happen. This makes me happy, not business deals or management. So I found someone who liked doing business deals and put him in charge of all that.

If you do this, you’ll encounter a lot of pushback and misunderstanding, but who cares? You can’t just live someone else’s expectation of a traditional business. You have to just do whatever you love the most, or you’ll lose interest in the whole thing.

From Mike Lowenstern:

While I was still doing the freelance/orchestra life, I never felt completely fulfilled. I was working, but I was working with a lot of people who would read magazines during concerts (no, I’m not kidding. They had them on their music stands) and complain during breaks. Many were very, very unhappy. And there I was, feeling their negativity pretty acutely, and thinking to myself, there are hundreds of musicians who would kill to do this job you’re endlessly complaining about. It was around this time that I decided to switch tracks, and to make an attempt to be successful outside of music, and to pour my energy into the business sector to see how far that would take me. It was a good decision for me, and ironically, it gave me the freedom to become much more successful INSIDE the music world.

... If you want to feel fulfilled as a musician, you need to ask yourself a few questions:

What fulfills you as a musician?... [And] What fulfills you as a person? Is it playing music you love? Teaching someone else to play and love music? Is it the freedom to do what you want (e.g. without needing to worry about money)? Again, each of these requires a different path.

From Dana Fonteneau:

Success is a process, not a destination; a becoming, not a formula...

If we don't stop to question the paradigms, we're blindly following someone else's map without knowing where we are or where we're going.