Forem: Taylor D Jones

Tackling the Cloud ☁️ Building a Containerized Sports API with AWS ECS and API Gateway

Taylor D Jones — Sun, 02 Feb 2025 20:17:09 +0000

This was one of the most challenging projects I've ever worked on. When I started to build the containerized API management system for sports data, I thought, "How hard could it be?" Spoiler alert: It was like trying to win the Super Bowl without knowing the playbook. But guess what? After fumbling through tasks, battling circuit breakers, and chasing down rogue environment variables, I emerged victorious. Here’s the play-by-play of my adventure with Amazon ECS (Fargate), API Gateway, and a sprinkle of Docker magic.

🏈 Kickoff: The Game Plan

The goal was simple: create a REST API that pulls real-time sports data, containerize it with Docker, deploy it on AWS ECS with Fargate, and expose it through API Gateway. Sounds easy, right? Like a rookie quarterback, I had no idea the defense (aka AWS errors) I was about to face.

⚙️ The Tech Stack Draft

AWS Services: ECS (Fargate), API Gateway, CloudWatch

Programming Language: Python 3.x with Flask

Containerization: Docker

External Data: SerpAPI for sports data

🚀 First Quarter: Building the API

Writing the Flask API was the easy part. I whipped up an endpoint /sports to fetch NFL schedules from SerpAPI. It worked perfectly on my local machine. I felt like an MVP.

@app.route('/sports', methods=['GET'])
def get_nfl_schedule():
    # Fetches the NFL schedule from SerpAPI
    try:
        params = {
            "engine": "google",
            "q": "nfl schedule",
            "api_key": SERP_API_KEY
        }
        response = requests.get(SERP_API_URL, params=params)
        data = response.json()
        return jsonify(data), 200
    except Exception as e:
        return jsonify({"error": str(e)}),

.... but then came the deployment.

💥 Second Quarter: The Fargate Fumble

Deploying to ECS was like facing the 1985 Chicago Bears defense. My containers wouldn't start, tasks kept stopping, and AWS threw errors like confetti:

Exit Code 137: "Out of memory? But I gave you 2GB, why are you still hungry?"

Circuit Breaker Thresholds: ECS decided, "You’re done here, buddy," and kept rolling back my services.

Image Pull Errors: "CannotPullContainerError: manifest does not contain descriptor matching platform 'linux/amd64'."

🏃‍♂️ Halftime Adjustments: Learning from the Fumbles

Memory Issues? Increased the task memory to 4GB. Boom. No more out-of-memory errors.

Circuit Breaker Drama? Disabled it temporarily to figure out the root issues.

Docker Image Errors? Rebuilt the Docker image with the --platform linux/amd64 flag. ECS finally stopped being picky.

🏆 Third Quarter: API Gateway Gets in the Game

Setting up API Gateway was smoother than a perfect touchdown pass:

Created a new REST API
Linked it to the Application Load Balancer (ALB) from ECS
Deployed to the prod stage

BUT... hitting the endpoint returned:

{
  "games": [],
  "message": "No NFL schedule available."
}

Cue dramatic music.

😤 Fourth Quarter: The Debugging Blitz

Turns out, the API key I set as an environment variable was misnamed. I had SPORTS_API_KEY in ECS but SERP_API_KEY in my code. Rookie mistake. I updated the task definition, redeployed the service, and...

TOUCHDOWN! 🏈

{
  "message": "NFL schedule fetched successfully.",
  "games": [
    {
      "away_team": "Kansas City Chiefs",
      "home_team": "Philadelphia Eagles",
      "venue": "Caesars Superdome",
      "date": "Sun, Feb 9, 6:30 PM",
      "time": "6:30 PM ET"
    }
  ]
}

📚 Overtime: Lessons Learned

Memory Matters: Don’t underestimate resource allocation.
Naming Conventions Save Lives: Consistency with environment variables is key.
Logs Are Your Best Friend: CloudWatch helped me track down every sneaky error.
Docker Platforms: Specify the platform when building for ECS to avoid compatibility headaches.

💡 Final Thoughts: From Rookie to Pro

What started as a simple API project turned into a cloud computing masterclass. I battled ECS tasks, tamed API Gateway, and came out with a fully containerized, scalable sports API. So, if you’re diving into AWS, just remember:

It’s okay to fumble, as long as you recover the ball. 🙌

Ready to deploy your own sports API? Check out the project on GitHub!

DevOps Challenge: Day 2 – Building an Automated NBA Score Alert System with AWS

Taylor D Jones — Tue, 07 Jan 2025 19:21:28 +0000

Welcome to Day 2 of my DevOps Challenge! Today, I focused on implementing an automated NBA score alert system using AWS services like SNS, Lambda, and EventBridge. This project is a great hands-on way to explore cloud automation, event-driven workflows, and security best practices in AWS.

🏀 The Goal: Real-Time NBA Alerts

The goal is simple: fetch live NBA game scores from an external API and send real-time notifications via SMS or email to subscribed users. To achieve this, I leveraged:
• Amazon SNS for sending notifications
• AWS Lambda for processing game data
• Amazon EventBridge for scheduling updates
• IAM Security following least privilege principles

🛠️ What I Did Today

1️⃣ Setting Up Amazon SNS for Notifications

I started by creating an SNS topic to handle message distribution. Subscribers (either via email or SMS) will receive updates as new scores come in. One key step was confirming email subscriptions to ensure proper delivery.

2️⃣ Deploying the Lambda Function

Next, I created an AWS Lambda function in Python, which fetches live NBA scores from SportsData.io and formats them for delivery. The Lambda function also uses environment variables to securely store the API key and SNS topic ARN.

3️⃣ Automating with Amazon EventBridge

To keep notifications timely, I scheduled the function using EventBridge Rules. I set up a cron job that triggers the Lambda function at specific intervals, ensuring fans receive the latest game updates without manual intervention.

4️⃣ Implementing IAM Security Best Practices

Security is crucial in any cloud deployment. I followed least privilege access by creating IAM roles that grant only the necessary permissions for Lambda, SNS, and EventBridge. This reduces the risk of unauthorized access or misconfiguration.

🚀 Lessons Learned
• Event-driven automation is powerful – With just a few AWS services, I automated a notification system that runs on its own.
• IAM security should never be an afterthought – Applying least privilege policies ensures services have just the right level of access.
• Lambda functions are great for lightweight tasks – Fetching, processing, and sending notifications with Lambda made the system both scalable and cost-efficient.

Have you built a similar notification system? What use case would you automate with AWS? Let’s discuss! 👇

Day 1 of My 30-Day DevOps Challenge: Building a Cloud-Powered Weather Dashboard ☁️🌍

Taylor D Jones — Mon, 06 Jan 2025 18:40:45 +0000

Kicking Off the DevOps Journey 🚀

I’m officially diving into a 30-Day DevOps Challenge, and I couldn’t be more excited! The goal? Build hands-on cloud skills while tackling real-world projects. And what better way to start than by creating something practical—a serverless weather dashboard that fetches live weather data and stores it in AWS S3?

The idea sounded simple at first:
👉 Fetch weather data from an API
👉 Store it somewhere
👉 Retrieve and display it later

But as I quickly learned, cloud projects always involve more than you expect—and that’s part of the fun. 😆

Step 1: Fetching Weather Data Like a Pro

Since I wanted to pull real-time weather updates, I decided to use the OpenWeather API. It’s a free (and super easy-to-use) service that provides weather details like temperature, humidity, and conditions for any city.

I grabbed my API key, made a request, and boom—instant weather data! 🌤️

At this point, I was feeling good. Step 1? Done. ✅

Step 2: Where Do I Store This Data? 🤔

Here’s where AWS comes in. Instead of saving data to a local file, I wanted to store it in Amazon S3 (Simple Storage Service)—a scalable, cloud-based storage solution. This meant I could keep weather records over time and access them from anywhere.

But… AWS always has a way of humbling you.

🙃 Reality Check #1: Just uploading data to S3 wasn’t enough—I had to make sure my bucket was configured correctly to allow access.
🙃 Reality Check #2: AWS has strict security settings (which is good, but also frustrating when you just want something to work).

After some troubleshooting (and a few Google searches), I got my S3 bucket set up and successfully stored my first weather data file. Step 2? Done. ✅

Step 3: The Unexpected Challenge—S3 Permissions 🔐

This is where I hit my first real DevOps problem. Even though my data was in S3, I kept getting 403 Forbidden errors when trying to access it. Turns out, S3 buckets are private by default, and I needed to update my bucket policy to allow public read access.

I went into the AWS console, tweaked my settings, and… still got the same error. 😅

Cue troubleshooting mode:
✔️ Checked bucket policies
✔️ Disabled “Block Public Access” (the sneaky culprit)
✔️ Updated my object permissions

After a lot of trial and error, I finally got my data to be publicly accessible. Lesson learned: Security is a key part of cloud computing, and AWS doesn’t mess around.

What I Learned on Day 1

🎯 Cloud services are powerful, but security is always a factor
🎯 Permissions & access control take time to get right
🎯 DevOps is all about learning through problem-solving

By the end of Day 1, I had a working cloud setup—weather data being pulled from an API and stored in AWS S3.

This was just the beginning, but I already feel like I’m leveling up. 💪

See you on Day 2! 🚀

How I Turned My Resume Website into a Cloud-Powered Project

Taylor D Jones — Mon, 06 Jan 2025 15:29:20 +0000

When I first started this project, my resume was just a simple HTML and CSS page sitting in an S3 bucket. But what’s a website without some dynamic elements? I wanted to track how many people visit my site—not just for fun, but as a way to explore AWS serverless technologies. This led me to build a serverless visitor counter using JavaScript, DynamoDB, API Gateway, and AWS Lambda.

Here’s a breakdown of how I did it and what I learned along the way.

Step 1: Adding JavaScript for the Visitor Counter 🖥️

Since my website is static, I needed JavaScript to fetch and display the visitor count. The idea was simple:

When someone loads the page, JavaScript requests an API.
The API retrieves the current visitor count from a database.
The page updates to show the new count.

Step 2: Storing Visitor Count in DynamoDB 📊

I needed a database to store the number of visitors, and Amazon DynamoDB was the perfect choice. It’s serverless, scalable, and free for small projects.

Setting Up DynamoDB

I created a DynamoDB table with:
• Partition Key: id (set to a fixed value like "visitorCounter")
• Attribute: count (integer storing the visitor count)

Step 3: Building an API with API Gateway & AWS Lambda ⚡

Instead of letting my JavaScript communicate directly with DynamoDB (which would be a security risk), I built an API using:
•AWS API Gateway (to handle HTTP requests)
•AWS Lambda (Python) (to interact with DynamoDB)

Writing the Lambda Function

I wrote a Python function that:

Retrieves the current visitor count from DynamoDB
Increments the count
Updates the database with the new value
Returns the updated count as a JSON response

Step 4: Connecting API Gateway to Lambda 🌐

Next, I needed to create an API Gateway to expose this Lambda function as a REST API.

API Gateway Setup

Create a new API Gateway (REST API).
Create a GET endpoint (e.g., /visitor-count).
Connect it to the Lambda function.
Enable CORS so my JavaScript can make requests from the browser.

Step 5: Automating Deployments with AWS SAM ⚙️

Instead of manually setting up DynamoDB, API Gateway, and Lambda every time, I used AWS Serverless Application Model (SAM) to define everything as code.

Step 6: Automating CI/CD with GitHub Actions 🚀

To make my project automatically update whenever I push changes, I set up GitHub Actions:

CI/CD for Backend

When I push changes to my Lambda function or API, GitHub Actions runs my Python tests.
If the tests pass, the SAM application automatically deploys to AWS.

CI/CD for Frontend

When I update index.html, styles.css, or script.js, GitHub Actions uploads the new files to my S3 bucket.
It then invalidates the CloudFront cache, so visitors see the latest version instantly.

Final Thoughts: What I Learned 🎓

This project provided great hands-on experience in serverless development. Some key takeaways:

✅ JavaScript is powerful—even on a static site, you can create dynamic elements with APIs.
✅ DynamoDB is an easy-to-use NoSQL database, perfect for lightweight projects.
✅ AWS Lambda + API Gateway makes it simple to build serverless APIs.
✅ Infrastructure as Code (AWS SAM) is a game-changer—no more manual setup!
✅ CI/CD with GitHub Actions ensures my site stays up-to-date automatically.

Cloud-Ready Resume: HTML to AWS ☁️

Taylor D Jones — Thu, 19 Dec 2024 18:38:44 +0000

If you’ve ever even thought about dabbling in the world of cloud, you’ve probably heard of the Cloud Resume Challenge. It’s like this rite of passage for anyone wanting to level up their cloud skills—and honestly, I couldn’t resist giving it a try. Spoiler alert: it was as challenging as it was rewarding!

At this point in my cloud career I have two AWS certifications under my belt BUT getting your hands dirty is much different than answering exam questions correctly.

Here's what I did on day one of building my resume on the cloud:

Step 1: Crafting the Resume in HTML

The first task was straightforward: ditch the Word docs and PDFs and embrace HTML. I broke my resume into clean, semantic HTML sections—header, main content, and footer. Each section represented an essential part of my professional journey, from my work experience to my education and skills.

What stood out? Writing a resume in HTML reminded me of how structure matters. I had to think about not just what I wanted to say but how to present it logically for both users and browsers. Simplicity, meet power.

Step 2: Adding Style with CSS
Next up was CSS—basically the magic that turns plain functionality into something beautiful. I had so much fun with this part! I kept the design simple but polished, focusing on clean typography, a pop of color for the headings, and nice, even spacing to keep everything looking organized.

I’ve always loved designing, so it was exciting to play around with styles and see how small changes could completely transform the page. Even a little CSS goes a long way to take raw HTML from “meh” to something that feels professional and put together.

Step 3: Deploying a Static Website with S3
Here’s where things started to get real. I uploaded my HTML and CSS files to an Amazon S3 bucket and set it up as a static website. Sure, I could’ve gone the easy route with GitHub Pages or Netlify, but the whole point was to dive into AWS and really learn how it all works.

Seeing my work go live was such a cool moment—knowing it’s running on the same infrastructure that powers massive companies. Plus, I got to dig into how AWS S3 operates behind the scenes, which was both challenging and super rewarding.

Step 4: Securing with HTTPS via CloudFront
Security is non-negotiable, so I set up Amazon CloudFront to serve my static site over HTTPS. It was my first time working with a CDN (Content Delivery Network) to distribute content securely and quickly.

There was a learning curve here, especially configuring the SSL certificate and linking everything correctly. But seeing that padlock icon in the browser? Totally worth it.

Step 5: Custom Domain with DNSTo give my resume a professional edge, I registered a custom domain and pointed it to my CloudFront distribution using Route 53. Setting up DNS records was a bit like solving a puzzle, but the satisfaction of accessing my resume at _techwithtay.click _made it all worthwhile.

Why This Matters?
This project wasn’t just about writing a resume—it was about showcasing technical skills in a practical way. It tested my understanding of front-end development, cloud deployment, and web security. Plus, it felt amazing to see a tangible result after a full day of learning.

If you’re thinking of taking on a similar challenge, go for it! You’ll come away with more than a resume—you’ll have a project that proves your ability to learn, build, and execute.

Have you ever built your resume in the cloud? Let’s talk tech! 🌐

AWS Lex: Building a Language Translation Bot

Taylor D Jones — Thu, 14 Nov 2024 22:20:25 +0000

Overview of the Project ☁️
If you've ever needed a quick translation while chatting with someone, then a language translation chatbot might be just the thing! In this project, I decided to build a bot with Amazon Lex that can translate phrases on the fly. It’s a relatively simple concept—type in a word or sentence, select the language you want it translated to, and voilà! The bot responds with the translated phrase. While working on it, I encountered a few challenges (spoiler alert: slots and intents can be tricky!), but the learning experience was well worth it.

Steps to Building the Translation Bot 👩🏽‍💻
Here's a breakdown of the steps, along with a few notes on what I struggled with:

Creating an Empty Chatbot
I started with a clean slate in Amazon Lex by creating a new bot. The setup felt straightforward, though I knew this was just the beginning!

Specifying Intents and Slots
This was where things got interesting. The intent is basically the action the bot should take (in this case, translating text). Slots are like the pieces of information needed to complete that action—like the phrase to translate and the target language. Getting the slot configurations to work just right was more challenging than I expected. I had to be precise with formatting; if anything was off, Lex wouldn’t understand what I wanted, and I'd get error messages or unexpected behaviors.

Tip: Make sure the slot types and the order align with what Lex expects. Sometimes, I’d double-check, only to realize one small formatting error was causing issues.

Specify Fulfillment
This step defines what happens once the user has provided all the necessary information. In this case, the bot needed to call AWS Lambda to handle the translation request by interfacing with Amazon Translate.

Create an IAM Role
To allow the bot to securely interact with Lambda and Translate, I created an IAM role. This part was more technical, but it’s a vital step to keep everything secure.

Create a Lambda Function
Now came the actual coding part! I wrote a Lambda function that takes the user’s phrase and the desired language and sends a request to Amazon Translate. Lambda returns the translated result, which the bot then outputs.

Test the Lambda Function
I wanted to make sure the function worked correctly on its own before testing it with Lex. Running a few test cases, I realized I needed to debug and fine-tune the code to ensure the translations were accurate.

Testing the Chatbot
Finally, I integrated everything in the Lex console and tested the bot. This was the most exciting part because it meant seeing the bot in action! Testing revealed a few things I needed to fix, but seeing it work was rewarding.

AWS Services Used 🛠
Here’s a quick rundown of the AWS services I used:

Amazon Lex: The platform for building and configuring the chatbot and defining the conversation flow.
AWS Lambda: Handles the translation request by communicating with Amazon Translate.
AWS IAM: Manages permissions for secure service interaction.
Amazon Translate: Performs the actual translation of phrases.

Reflections on the Process
I didn’t expect formatting slots with intents to be as challenging as it was, but I learned a lot about the precision Lex requires. It's these little details that ultimately make the bot work smoothly. Overall, building this bot helped me understand more about how different AWS services can work together to create functional, interactive applications. If you’re considering a project like this, don’t be discouraged if you hit a few bumps—each step is a learning experience.

Final Thoughts
Building a language translation bot with Amazon Lex was both rewarding and educational. It’s an amazing introduction to natural language processing, serverless functions, and the AWS ecosystem. If you're curious about cloud-based chatbots, give it a try—you might surprise yourself with what you can build!

Baddie's Hackathon

Taylor D Jones — Sun, 25 Feb 2024 01:54:16 +0000

I'm thrilled to dive into my 3rd hackathon adventure, and this time it's all about those Baddie Buildathon vibes! But hey, this isn't your average hackathon – we're on a mission to tackle some serious global issues faced by women, from gender-based violence to fair pay and healthcare access. And guess what? We're pulling out all the stops, delving into the realms of AI, Blockchain, and 5G networks to cook up some seriously innovative solutions.

Teaming up with a crew of awesome women from Texas, Cali, and India, I'm taking on the roles of UX/UI magician and frontend wiz for the next couple of weeks. This week's been all about jazzing up our project with color schemes and whipping up wireframes. And tomorrow, it's full speed ahead with mockups, aiming to have our prototype ready to roll by Tuesday.

I can't wait to see where this wild ride takes us. Let's hack for a change! ✨👩🏽‍💻

Ruby Array Methods

Taylor D Jones — Thu, 22 Feb 2024 00:40:05 +0000

Let's talk about Ruby's array methods... but first, what is an array?

Arrays are dynamic collections of elements, capable of storing any data type and adjusting in size as needed. With built-in methods for sorting, iteration, and transformation, arrays in Ruby offer flexibility and efficiency for managing collections of data.

Here are some methods demonstrating some of Ruby array's versatility:

.sample
This method returns a random element (or elements) from the array. Here are some examples:

If we want multiple elements:

.sort
This method returns a new array with the elements of the original array but it sorts the elements of the array in ascending order. Let's see this method in action:

.count
Ruby's .count returns the number of elements in the array that meet certain conditions. It also returns the number of elements in a list, when given no arguments. If given an argument, returns the number of times that argument occurs in the array. In these instances, this method returns an Integer

.push
This method adds one or more elements to the end of any Array and returns a modified array. For example:

.at
This method takes in an Integer argument and returns the element in the specified index of an Array.

.join
You can think of this method as the inverse of String's .split method. It combines the elements of the array into a single string, separated by a specified delimiter. Here are some examples of using these different delimiters:

Of course, there are other array methods such as .sum, .min & .max, and .include. I hope these have been helpful for your Ruby learning journey.

Until next time, Happy Coding!

Ruby String Methods

Taylor D Jones — Wed, 14 Feb 2024 20:18:58 +0000

Today I was working mainly with Ruby strings. It still surprises me how many of these methods cross over into Javascript, although they have different names. Let's explore some of the essentials Ruby string methods and what they do:

.reverse
This method returns a new string with the characters in reverse order. For example:

.upcase
returns a new string with all characters converted to uppercase. Example:

.downcase
returns a new string with all characters converted to lowercase. Example:

.swapcase
returns a new string with uppercase characters converted to lowercase and vice versa. Example:

.capitalize
This method returns a new string with the first character converted to uppercase and the rest to lowercase. Example:

.strip
returns a new string with leading and trailing whitespace removed. For example:

.gsub
returns used for global substitution, replacing all occurrences of a pattern in a string with another string. For example:

Until next time, happy coding!

Ruby Revelations: A beginner's journey

Taylor D Jones — Tue, 13 Feb 2024 23:17:03 +0000

I've been learning Ruby fundamentals for about a week or so. While I was nervous about taking on a new programming language, I found this one to be easier and more readable than Javascript.

In other words, I'm enjoying learning this language!

Today my learning was all about strings in Ruby, it was quite an enlightening day for several reasons. One, the methods used are similar to Javascript, so I don't feel like I'm learning something entirely new. And two, seeing the differences between the two languages.

So here's some things I learned:

Strings are objects. This means they come with a plethora of built-in methods and functionalities that can be very useful. From simple manipulations to complex transformations, Ruby offers a lot of tools to work with.
String interpolation It's a feature that allows me to embed Ruby code within a string, making it convenient to insert variables and expressions directly into the text. This not only streamlines my code but also makes it more readable and expressive.

For example, using the '#{}' syntax seamlessly integrates variables into my strings. This adds flexibility to the code but also opens up possibilities for creating dynamic, data-driven applications.

3.String manipulation Whether it's through concatenation, slicing, or using various built-in methods like 'upcase', 'downcase', or 'reverse', there are many ways to manipulate a string. Each of these methods serves a unique purpose, allowing me to tailor my string manipulations to suit my specific needs.

As I continue to explore Ruby, I'm excited to see how I can leverage these new skills to build even more robust and dynamic applications in the future.

Until next time, happy coding!