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.

It's summer time and I'm feeling inspired to spin my "now" page back up!

Software

I've been in software for 3 years now! Still enjoying my time at AptAmigo.

So far, I've commited to learning a new programming language every year. This year, I've been having fun getting familiar with Java. The type system paired with VS Code intellisense is lovely.

Now having had a few years of experience working professionally, I've really taken a liking to sharpening my thinking by writing short tech articles. It's a great space to share what I'm working on and find clear ways of explaining it. My favorite part is when someone comes across a problem I've faced already. I can reach back to my own post to help them through the solution!

You can keep up with my tech articles through the tech tag on my blog. You can also find me on LinkedIn.

Music

I'm bouncing between playing guitar, piano, and writing my own music. To paraphrase W.A. Mathieu, it's fun to have many pots boiling!

After decades of communal music making and monophonic sound on the saxophone, I'm thrilled to be exploring independent and polyphonic instruments.

To make things even more interesting, I'm putting most of my focus on learning jazz on piano and guitar. A friend of mine told me that it's actually the way to go — to learn the vocabulary harmonically as opposed to in a scalar way.

For music writing, it's been fun to keep it loose! I take what ever I'm listening to at the moment, deconstruct it, and turn it into something new. It's a wildly fun outlet!

You can browse my mini albums here. You can keep up with my guitar and piano playing through the music tag on my blog. I'm also sharing recordings on Instagram.

Art

A couple of years ago I dedicated myself to learning how to draw and create digital paintings! I used to make my own comics growing up, but I always assumed my sister had all the talent. After switching from music to code, I realized I could learn anything. So I may as well learn a skill I've only ever dreamed of having! 🙂

I'm spending time balancing the fundamentals with just fooling around. This year has been all about figure drawing, direct painting, and making silly little digital sketches. The best part is that I have an excuse to revisit cartoons, comics, manga, and video games as sources of inspiration!

You can see what I've made so far through the Art tag on my blog. I'm also sharing drawings on Instagram.

Dallas

Living in Dallas with Miranda and our dog Lucy! We moved from Austin a couple of years ago so Miranda could attend Parker University for their Doctor of Chiropractic program. Only a year left as of this writing, then we'll see where we end up next!

So far it's been my favorite metro area in Texas to live in. Downtown is just a quick drive from where we are. But, in the other direction, artsy Denton is not far either.

All good things!

👋

Listen on Youtube

🚞 An oldie but a goodie

My original album cover for Noodle Bird was pretty crunchy. 😅 So I whipped up a new rendition!

From Austin Kleon:

The way I show up for myself, the way I discover who I really am, is to make an appointment every day to show up to the page. If I show up to the page, I show up to myself.

Two years of blogging! A small part of many years of creating and making, and it's certainly worth marking the occasion.

Last year I shared my Lessons From a Year of Blogging. I'd largely echo those points this year. I still enjoy the clarity of thought that comes from writing and making, the ability to carry a long term conversation while leaving a trail, and having a stage to perform on.

One other thing I've come to appreciate with blogging as a medium is this:

It's Malleable

I took a moment to look back at what I've made this year. For context: This started largely as a text blog, mostly developer logs. Out of the soil, buds of more literary posts on what I was reading began to sprout. Soon after that, I started sharing art and music.

I've since traded words for color and sound! Lately I only write for my tech posts. And the switch is intentional — I want to get more miles out of music and drawing, and there are only so many hours in the day.

When I started, a was wringing my hands trying to decide what one thing I would blog about. What a relief that it doesn't have to be one niche!

What I admire in the blogs I read is the spectrum of humanity that shines through. There's no predefined formula, and no algorithm to juice if you don't want to. So I end up seeing people as polyhedrons through the diversity they share and make.

On top of that, tomorrow I could decide that I'm all in on fly fishing. There's no barrier to me making this blog all about that for a couple of years. And I would revel in being able to look back fondly on the different phases and eras.

Starting out, I was worried about the idea that, if no one read what I wrote, I'd be doing all this for nothing. Turns out the rewards that come from a creative act alone absolutely eclipse any hit to the ego I would take if a post gets overlooked!

Elizabeth Gilbert in Big Magic:

You might end up dancing with royalty. Or you might just end up having to dance alone in the corner of the castle with your big, ungainly red foam claws waving in the empty air. that's fine, too. Sometimes it's like that. What you absolutely must not do is turn around and walk out. Otherwise, you will miss the party, and that would be a pity, because - please believe me - we did not come all this great distance, and make all this great effort, only to miss the party at the last moment.

And, of course, even if my inbox doesn't get flooded with mail on the eureka moment someone had reading a tech blog post, writing publicly is still a phenomenal tool for clarifying thinking in that craft.

I'm thinking much about the question offered through James Hollis' work: "What is seeking expression through me?" The wonderful thing about a personal blog is an opportunity to flexibly celebrate that expression.

The generous part of that showing up is that, by doing so, we then bring our fullest selves to the people we serve.

So start with where ever you are! Bring all parts of yourself along for the ride. You may find, as I have, it's an excellent way to explore the answers to that question.

Spring Boot is a well embraced and powerful framework for developing web applications. Getting a backend API setup is fairly quick and allows for a great deal of durability up front. A fine balance between moving quickly on an app while giving you the guard rails to maintain organization, scalability, and durability.

Here's the quick-start guide to getting an API setup:

Layers

If you're used to the MVC pattern in software development, you'll find a similar intent of organization around Spring Boot Architecture. However, the categories we group our logic in will be slightly different.

In Spring Boot, these categories are referred to as layers of the application. They have their own directories and are bundled in their own package within the application.

Here's a simple directory structure within the src folder of our app:

project/src/main/java/com/projectname
|-- controller
|    |-- ArtistController.java
|-- model
|    |-- Artist.java
|-- repositories
|    |-- ArtistRepository.java
+-- service
     |-- ArtistService.java

Note that tests will live in their own directory outside of the src folder.

Above, all layers are represented:

• The Controller layer is responsible for connecting our data from the service layer with a means of rendering or presentation.
• The Model layer handles communication between our application and external database.
• The Repositories layer is responsible for querying logic to our database. If the model layer is establishing communication with the database, then the repositories layer is handling what type of requests we're making available to our application.
• The Service layer handles all the business logic for our application. This layer relies on the repositories layer to provide the data so that it then can be transformed in whatever way we need it to be before delivery.

In Action

Ok! So say that I have my base app setup for a Spotify Popularity Monitor API. From here, I want to setup a feature for each layer that supports CRUD operations for an Artist.

I'll start with the model:

Model

package com.chrispadilla.spotifyperformancemonitor.model;

import jakarta.persistence.Column;
import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Id;

@Entity
public class Artist {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private long id;

    @Column
    private String name;

    @Column
    private String[] genres;

    @Column
    private String spotifyId;

    @Column
    private String spotifyUrl;

    // Getters/Setters here
    
}

For brevity, I'm leaving out the Getters and Setters. What I'm showing is the schema for an Artist as I want it setup in my relational DB.

By adding @Entity, I'm denoting this as a persistence layer class for the JPA.

Next, I'll add the repository:

Repository

package com.chrispadilla.spotifyperformancemonitor.repositories;

import org.springframework.data.repository.CrudRepository;
import org.springframework.stereotype.Repository;

import com.chrispadilla.spotifyperformancemonitor.model.Artist;

@Repository
public interface ArtistRepository extends CrudRepository<Artist, Long>{
    Artist findByName(String name);

    Artist findBySpotifyId(String spotifyId);
}

Fairly simple! Spring Repositories already come with several CRUD methods. I enable them by extending from CrudRepository. By default, I'll be able to call findById, but if I want to query by another field, I specify it on the interface with a method. I've done this with findByName and findBySpotifyId above. Spring will automatically make the connection that if I'm passing in a variable spotifyId, that this is what I'm querying by on the model. No extra logic required!

Service

The service layer will largely depend on what I'm trying to do with the data. It goes beyond the scope of today's blog, so here's the bare bones setup for a service class:

package com.chrispadilla.spotifyperformancemonitor.service;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import com.chrispadilla.spotifyperformancemonitor.model.Artist;



@Service
public class ArtistService implements IArtistService {
    @Autowired
    private ArtistRepository artistRepository;
        

    public void collectArtist(String spotifyId) {
        // Do your stuff
    }

}

It's good practice to create an interface outlining the methods you'll implement, so here I'm extending from an IArtistService instance above.

Again, an annotation of @Service marks this as a bean that can be injected throughout my other layers.

Controller

It all comes together in the controller! Here I'll setup a controller to GET and POST artists:

package com.chrispadilla.spotifyperformancemonitor.controller;

import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.server.ResponseStatusException;

import com.chrispadilla.spotifyperformancemonitor.model.Artist;
import com.chrispadilla.spotifyperformancemonitor.repositories.ArtistRepository;
import com.chrispadilla.spotifyperformancemonitor.service.ArtistService;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.HttpStatus;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseStatus;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestBody;


@RestController
@RequestMapping("/api/artist")
public class ArtistController {
    @Autowired
    private ArtistRepository artistRepository;
    @Autowired
    private ArtistService artistService;

    @GetMapping
    @ResponseStatus(HttpStatus.OK)
    public Iterable<Artist> getArtists() {
        return artistRepository.findAll();
    }

    @GetMapping("/{id}")
    public Artist getArtist(@PathVariable Long id) {
        Artist artist = artistRepository.findById(id)
            .orElseThrow(() -> new ResponseStatusException(HttpStatus.NOT_FOUND, "No matching ID"));
        return artist;
    }

    @PostMapping
    @ResponseStatus(HttpStatus.CREATED)
    public Artist postArtist(@RequestBody Artist artist) {
        return artistRepository.save(artist);
    }
}

Several nice annotations are made available here! RequestMapping, GetMapping, and PostMapping allow us to define the path for our controller. PathVariable gives access to the id that's listed as part of my path in my get request.

Here, you'll see I'm using Autowired to tell Spring to inject an instance of my repository and service layer classes created above. I can then use them freely within my controller.

It can be tempting to write the business logic directly in the controller. To maintain flexibility, though, it's best to leave minimal db logic in the controller and wrap up data transformation within a method on your service layer classes. This allows for a more highly decoupled system. Were I to add a Presentation layer, it would be far simpler to access the service layer object, as opposed to refactoring a bloated controller method.

That's It!

With just a few files written, we have a strong basis for a flexible and easily extendable API! All with type checking along the way and a largely decoupled system! 👏

Listen on Youtube

Summer is coming! Only felt appropriate to play some Pokemon island music 🏝

In our neighborhood, we had a duck couple move into the community pool. Now their ducklings have hatched and they're one big, happy duck family!

Of the core pillars of Object Oriented Programming, Polymorphism affords a great deal of flexibility. While inheritance allows for encapsulated and abstracted data to be shared, polymorphism allows for the redefining of both the data and the attached methods based on context.

Java supports polymorphic behavior through two means: Method Overloading and Method Overriding.

Demonstration

Say that I have an ArchiveItem class that stores the basic details of a name and id. Here I'll demonstrate both overloading and overriding:

package polymorphism;

public class ArchiveItem {
    private String id;
    private String name;
    
    // Overloaded constructor with all instance variables supplied
    public ArchiveItem(String id, String name) {
        this.id = id;
        this.name = name;
    }

    // alternative constructor with only the name provided
    public ArchiveItem(String name) {
        this.name = name;
        this.id = IDPackage.generate();
    }

    // Override the base equals() method
    @Override
    public boolean equals(Object compared) {
        if (compared == this) return true;
        if (!(compared instanceof ArchiveItem)) return false;

        ArchiveItem comparedItem = (ArchiveItem) compared;

        return this.id.equals(comparedItem.id);
    }

    // Override the base toString() method
    @Override
    public String toString() {
        return String.format("%s: %s", this.id, this.name);
    }
}

Taking a look at my constructors, I'm overloading the ArchiveItem method by declaring the same method, but with a different number of arguments both times. When instantiated, Java will know which of the two methods to run based on what arguments are provided. Another way of putting it: One of the two methods will be called depending on their signature.

Looking further down, I've written an equals and a toString method. All Objects in Java come with these methods. Every class inherits from the base Java Object class, and on that class are implementations for equals and toString. In fact, toString is what's called anytime you print an object to the console.

Without any adjustments, passing an object to System.out.println() would return something like this:

ArchiveItem guitar = new ArchiveItem("Guitar");
System.out.print(guitar);
// "polymorphism.ArchiveItem@28d93b30"

The base print method will print the classname to the left of the @ symbol and the location in memory to the right. Typically, we want something more descriptive representing our class instance.

In the example above, I'm pringint instead the provided id and name of the ArchiveItem

By adding the @Override annotation, I'm declaring that I'm intending to implement my own logic for the already inherited toString method. The @Override annotation is actually not necessary, but recommended. This will flag to the compiler to check that you're in fact overriding an existing method. Great for catching typos!

Putting It All Together

ArchiveItem piano = new ArchiveItem("Piano");
System.out.print(piano);
// "Piano, 93nkf903f"

Here it is in action! The ArchiveItem is instantiated with only one argument, so it calls the matching method. One line down, I'm calling my implementation of toString by passing my piano object into the print method.

Here is the same class but with a different constructor signature:

ArchiveItem piano = new ArchiveItem("custom-id", "Piano");
System.out.print(piano);
// "Piano, custom-id"

Listen on Youtube

A sweet dance from one of my Mom's old piano books 🦌