And it’s definitely been a long time coming. In 2022 we had my daughter and I found a higher paying job that mentioned that I should study and get my Security Plus certification within a year’s time. So I figured, let me study up the 601 and try to figure out how to get this certification months in advance so I don’t have to cram before some mandatory deadline.
Well, I was not prepared for being a new parent and having to roll through the punches of changing diapers or losing sleep and navigating through the ups and downs of parenting. So when I took the test, I didn’t do too well. However, I have kept my skill sharp and I’ve worked and plenty of government related environments that require strict security controls, secure enterprise applications that need to be handled with care, and other material that pertain to the certification.
Every year I reflect on what the next best thing is or what the new fun thing might be in my career and the Security Plus can open up a lot of doors for me. So it’s always in the back of my mind but never a priority until recently.
About a month ago I was handed a layoff letter because the company I worked for decided to go heavy into AI and started consolidating and shrinking their employment staff. I’m under the impression that it was to possibly offset the cost of the AI that they’ve been implementing over the past 14 months. Knowing that I’m getting laid off should have felt like a slap in the face. Most people instantly start thinking about how long they will last without reaching into their savings or with their savings. I spoke to my wife at the beginning of the year to reflect on the financial principles I put into place two years prior and was impressed with how much we had saved for emergencies and “waves” as I like to call them. That conversation with my wife at the beginning of the year had us kickstart our new journey in upgrading our house so we put our house up for sale weeks before I got hit with the devastating news. I repeated to my wife “Financial freedom is our only hope”, and now I have to pivot and see how well I practive what I preach. The news of the layoff shocked me, but didnt effect the foundational boat my wife and I have created. This wave wont hurt as mcuh as the previous ones did. It allowed to “snap out of the shock” before the video call ended. I hit the ground running, texted my wife, and started updating my resume, Dice.com, Indeed.com, and LinkedIn job profiles and portals. I reached out to different recruiters from different agencies that I worked with and the one thing I learned pretty quickly that was clear was the IT industry is in shambles right now!
Finding some kind of senior level position at my rate shouldn’t be hard, but not having the Security+ was something in the back of my mind that I thought might hinder me from just getting past HR firewalls or ATS tracking systems that review my resume. After the two weeks that felt like two months, interviewing with a few places, and doing my best to stay positive, I got a job offer. The offer letter was presented with the contingency that I obtain an IAT Level II certificate (under directive 8570/8140 for personnel managing network environment security).
With the opportunity presenting itself, I knew that I had to prove to them that I can take the test and get the certification so that they can then start the process of the background check and tests and get all that done before the expected start date within 30 days. Which means I realistically have 2 weeks to study and take this test which allows the extra two weeks to have all the other onboarding processes take place.
I decided to take the test on March 14th and passed!
The test definitely kicked my ass! Most of it was the pressure involved with passing this and the whole “job/career in limbo” but I was able to get the exact results I needed. I was definitely more equipped with understanding than I was 2 years ago because I’ve been in the field for that long so I’m able to easily understand situations and scenarios but that didn’t make it any less harder of an exam.
The 601 which expired last year is much different from the 701 that I took. The 601 is very much focused on commands that you have to memorize and specific technologies that you may not use day-to-day but you have to know for the exam. The 701 focuses more on concepts like “John Doe is a security engineer at company XYZ he notices X what is the best way to resolve or mitigate X” or “Susan is a data processor at company company. JJJ what does company JJJ expect of Susan as a data processor?”
Now that I have the exam, here are the links and the resources I used to stay sharp and stay focused and now that you’ve read this you understand that I’m not coming from ground zero.
The Udemy courses by Jason Dion and the discount at diontraining.com along with the Cyberkraft PBQ’s (performance based questions) are what changed the game for me. Being able to take the practices tests in udemy helped me get into the metal “exam mode” mindset. Someone like me who has always gotten test anxiety when taking any of the certification exams I have taken, makes these test a vital part of my studies. The Cyberkraft team on youtube and the performance based questions THAT I ACTUALLY SAW ON THE EXAM helped me answer the 3 pbq’s that started my test off. Those two things were paramount to acheiving this goal. I pray that sharing this information with others helps whoever is reading this. Best of luck to you and “May the odds be ever in your favor”.
]]>If you’ve followed my journey from passion to paycheck, or from Linux enthusiast to Platform Engineer, you know I’m a fan of building things. But I have learned over the years, there’s a difference between building from scratch and doing the same task twice. If I have to click through the AWS console to spin up an EC2 instance more than once, I’ll drive to a data center and shoot up a few server racks myself.
This week, I decided to sit down and clean up my infrastructure workflow. I wanted to showcase my move away from the “manual” and move toward “automated excellence.” I built a pipeline that combines Terraform, GitHub Actions, and Discord to handle the heavy lifting while I focus on the bigger picture. Like Thanos, I’m trying to get to that point where I can finally rest and watch the sunrise on a grateful (and fully automated) universe. Let me break this down and, with the help of AI, write it out in a blog to share with other engineers.
For those who havent listed to Juicy by NOTORIOUS BIG, Terraform is a tool that lets you write code to define your hardware. Instead of pointing and clicking in an AWS dashboard, I write a few lines in a .tf file, and AWS makes it happen.
In this project, I targeted a simple Ubuntu 20.04 server. But I didn’t want to just “hardcode” the settings. I wanted a setup that felt professional—something that handles versioning and security right out of the box.
tfenvI’m a stickler for consistency in the dev space and I’ve seen too many projects break because one dev is on Terraform v1.5 and another is on v1.14. So I wrote a setup.sh script that leverages tfenv. It checks your system, installs the tool if it’s missing, and locks the project to a specific version.
This creates a .terraform-version file in the repo. Now anyone, and my GitHub runner. knows exactly which version of Terraform to use. No more “it works on my machine” excuses when sharing the repo link.
The real magic happens when you stop running commands from your laptop and let the cloud manage itself. I configured a GitHub Actions workflow to handle my CI/CD (Continuous Integration/Continuous Deployment).
The workflow does a few key things: Quality First: Before a single Before a single server is built, the pipeline runs TFLint. While the standard Terraform validator checks if your code is “legal,” TFLint checks if it is “good.” It acts like a senior engineer performing a code review on every commit, catching non-optimal configurations—like using an outdated instance type or missing recommended tags—that a basic syntax check would miss.
Security-on-Demand: It’s essential for catching those quirky provider-specific errors and ensuring a “clean-code” mindset is baked into the pipeline from the start.
While the pipeline focuses on linting by default, I’ve included a commented-out block for a Focused Trivy Scan.
Since this is a general-purpose template, not every project—like a local test lab or a simple static site—requires high-level security audits that might fail a build over a minor disk encryption warning. However, for anything destined for production, this is a “nice-to-have” that acts like a pre-flight security officer.
To enable it, you simply uncomment the following block in your workflow:
- name: Run Focused Trivy Scan
id: security_scan
uses: aquasecurity/trivy-action@0.28.0
with:
scan-type: 'config'
scan-ref: '.'
severity: 'CRITICAL,HIGH'
limit-to-misconfigurations: true
exit-code: '1'
Manual Control: I added a workflow_dispatch trigger. This gives me a “Run Workflow” button in GitHub where I can choose to plan, apply, or destroy my infrastructure manually. Sometimes you want that “big red button” feel. This helps keep costs low and prevents the apply to stick around overnight and have me write out a new blog about how I owe AWS my savings acount because I forgot to turn something off.
Environment Secrets: Using the GitHub CLI (gh), I automated the process of pushing my AWS keys and Terraform variables into GitHub “Environments.” This keeps sensitive data off my hard drive and safely tucked away in GitHub’s encrypted vault.
One thing that used to trip me up back in 2018 was the concept of “State.” Terraform needs to remember what it built. If you run it on a GitHub runner, that runner disappears as soon as the job is done. If you don’t save that memory (the state file) somewhere, Terraform will think it has to start from scratch every time.
I moved my state to an S3 Bucket. Now, the state is persistent and shared. Whether I’m running a command from my terminal or GitHub is running it from a data center in Virginia, we’re all looking at the same map.
I’m a fan of proper “alerts” I didn’t want to keep refreshing a browser tab to see if my deployment finished. I want to be notified with a problem when it happens and not have to deal with a “hey, you got a second” ping. Give me the hard details!
I set up a Discord Webhook that sends a formatted “Embed” message to my server. It uses color-coded bars—Green for success, Red for a failure. It tells me the branch, the author, and how long the job took. It’s a small touch, but it adds a level of calmness to the chaos of deployment. Discord was used because this is part of my own personal project. Don’t need pay for teams or slack when discord is my current computer chat app of choice.
I often think about my twin brother when I finish a project like this. He wasn’t into Linux or Automation, but he understood the hustle. He understood what it meant to take a raw idea and turn it into something tangible. Every time I hit “Apply” and see those green checkmarks, I kinda feel that connection.
The work is never done. The tech field is a moving target, and the only constant is change. But by automating these workflows, I’m carving out more time to reflect, more time to listen to music that keeps me grounded, and more time to get to whatever is next.
If you’re looking to grab the code and set up your own automated AWS environment, you can check out the repo here.
Keep getting to it.
Automation isn’t about being lazy; it’s about being efficient so you can focus on the things that actually require your humanity.
Terraform + GitHub Actions + S3 + Discord = A production-ready pipeline that fits in your pocket.
Stay calm, keep building, and let the code handle the noise.
]]>This is a quick guide on deploying a React app on GitLab Pages. The following files are required to have it working properly. An example of this app can be see here
A file named “.gitlab-ci.yml” should be added to the repository root directory. This is the bread and butter of the continuous integration/continuous devliery part of Gitlab Pages. The file should have the environment and scripts to build and deploy the React app for you. Once its been run, it should move the build folder contents into /public directory for page deployment. However, I have caught myself running into errors with trailing slashes and back slashes when copying directory content.
More specifically this line here
- cp -r $CI_PROJECT_DIR/build/* public
Previously I had this setup
- cp -r $CI_PROJECT_DIR/build public
which would copy the entire build dir into the public dir leaving me with this.
$CI_PROJECT_DIR/public/build
The builds would succeed but gitlab pages would show the new website as a white page. After realizing that I only needed the contents in the build dir I tried a few steps that copied all the content and the removed the build dir all together. That too fails. So to finally resolve this and have a working react app showing on Gitlab pages my .gitlab-ci.yml file looks like this.
image: node:20
cache:
paths:
- node_modules/
stages:
- build
- deploy
build:
stage: build
script:
- rm -rf node_modules package-lock.json
- npm install
- ls -la public/ # Debug: Verify public/ directory contents
- npm run build
- ls -la build/ # Debug: Verify build/ directory contents
#- mv build public
artifacts:
paths:
- public/
expire_in: 1 hour
only:
- main
pages:
stage: deploy
script:
# If creating a syymlink doesn’ŧ work for any reason replace the line ln -s $CI_PROJECT_DIR/portfolio/public public with cp -r $CI_PROJECT_DIR/portfolio/public .
- cp -r $CI_PROJECT_DIR/build/* public
- echo "Deploying to GitLab Pages" # move build contents to new /public directory
- export
artifacts:
paths:
- public # only allow paths in project root directory for some reason
environment:
name: production
url: https://dave.meralus.com
dependencies:
- build
only:
- main
The package.json file requires the following line to be added as well.
"homepage": "https://custom-url.com/"
Setting the homepage URL the react app is important because it sets the app’s routing and asset paths and makes sure they are configured relative to the project’s URL. Without this, the app may fail to load resources properly, leading to broken links, a non-functional site, or a blank white page.
Hopes this helps someone out there. More importantly I hope it helps myself when I look back and read this 6 months from now lol.
]]>Vagrant is a powerful tool for creating reproducible dev environments, and sharing your custom Vagrant boxes on Vagrant Cloud makes it easy for other people to use them. Many times there are popular boxes, like ubuntu or red hat boxes, that are hard to find or disappear. In this post I want to walk through creating a Vagrant box from a VirtualBox vm.
Start by creating a vm in VirtualBox:
Log into the VM and configure it to meet Vagrant’s requirements:
sudo passwd root
Set the password to vagrant.
sudo visudo -f /etc/sudoers.d/vagrant
Add the following line:
vagrant ALL=(ALL) NOPASSWD:ALL
Save and test with sudo pwd (it should not prompt for a password).
sudo apt-get update -y
sudo apt-get upgrade -y
sudo apt-get install -y openssh-server
sudo shutdown -r now
mkdir -p /home/vagrant/.ssh
chmod 0700 /home/vagrant/.ssh
wget --no-check-certificate https://raw.githubusercontent.com/hashicorp/vagrant/master/keys/vagrant.pub -O /home/vagrant/.ssh/authorized_keys
chmod 0600 /home/vagrant/.ssh/authorized_keys
chown -R vagrant:vagrant /home/vagrant/.ssh
sudo apt-get clean
sudo dd if=/dev/zero of=/EMPTY bs=1M || true
sudo rm -f /EMPTY
sudo shutdown -h now
On your host machine:
mkdir ~/vagrant-boxes && cd ~/vagrant-boxes
vagrant package --base vagrant-ubuntu --output ubuntu.box
To ensure the box works:
mkdir test-box && cd test-box
vagrant init
Vagrant.configure("2") do |config|
config.vm.box = "ubuntu"
config.vm.box_url = "file:///path/to/vagrant-boxes/ubuntu.box"
end
vagrant up
vagrant ssh
vagrant destroy -f
cd .. && rm -rf test-box
Install the Vagrant Cloud plugin:
vagrant plugin install vagrant-cloud
Log in to Vagrant Cloud from the CLI:
vagrant cloud auth login
Enter your username and password or an access token (generate one from your Vagrant Cloud account settings).
Create a version for your box:
vagrant cloud version create yourusername/ubuntu2004 1.0.0
Add a VirtualBox provider for the version:
vagrant cloud provider create yourusername/ubuntu2004 virtualbox 1.0.0
Upload the box file to Vagrant Cloud:
vagrant cloud provider upload yourusername/ubuntu2004 virtualbox 1.0.0 ~/vagrant-boxes/ubuntu.box
Release the version to make it available:
vagrant cloud version release yourusername/ubuntu2004 1.0.0
Your box is now live on Vagrant Cloud. Test and share the box now.
Test the box by initializing it from Vagrant Cloud:
Vagrant.configure("2") do |config|
config.vm.box = "yourusername/ubuntu2004"
config.vm.box_version = "1.0.0"
end
vagrant up
vagrant ssh
vagrant destroy -f
Creating and sharing a Vagrant box on Vagrant Cloud is straightforward once you understand the process. By following these steps, you can package a custom VM and make it available for others to use in their dev workflows. Whether you’re sharing a public box with the community or a private box with your team, Vagrant Cloud simplifies distribution.
For more advanced setups, consider using Packer to automate box creation. Happy Vagrant-ing!
His journey through music talk alot about unpacking issues through therapy and sadness and self-reflection. I tend to feel like anytime I hear an interview or read a tweet from him I get happy for him and his success and sad that my brother wont ever be able to discuss his music with me or get to that level of success because he is no longer here (RIP).
In his new album he has a song called Gettin Too it with DJ Lucas. This or Pent Up in a Penthouse are growing to be my favorite songs on the album but the verse from DJ Lucas and his lyrics, have blown me away! Going through DJ Lucas’s work and discovering him through Russ made me feel the same feeling my brother and I felt when listing to Lupe Fiasco’s The Cool album back in the day. The way that music is able to pull you back to the good ole days and keep you there for at least 2 minutes and 38 seconds astonishes me.
I’m writing this to be able to read this later in the future and remind myself a few things.
Russ built a career from scratch, just like I did with Linux, Automation, and Software Engineering.
If Russ can find ways to navigate through these lonely roads, then I can too
Like Thanos, I can finally rest, and watch the sunrise on a grateful universe
My work is not done, but the road I have carved for myself in the tech field and the places I have gone will continue to take me to places I have not yet. The only constant in life is change and im still getting to it. Hopefully Russ reads this one day and knows that someone in the tech world is listening to his music and is rooting for him.
]]>Infrastructure as Code (IaC) is a game-changer for automating server deployments. HashiCorp’s Packer application is one of the best tools to build infrastructure in the cloud. While working at one of the biggest sneaker retail giants in the world I worked on a project that involved cleaning up and updating a multi-chain packer build. In this blog post, I decied to recreate the multichain Packer build pipeline that creates two AWS AMIs and explain it. Since I cant give away trade secrets I can rebuild a new version of the pipeline and stretch my memory and skills to share I guess. The pipeline builds a base image with WordPress manually installed on Ubuntu 20.04 using Ansible, and an enhanced image that builds on the first by adding WordPress plugins and security packages. The glue that put it together at work was Jenkins, but because I no longer work there and dislike managing Jenkins jobs and Jenkins in general, I’ll test and automate the entire process with a GitHub Actions workflow that chains the builds and passes the base AMI ID to the enhanced build.
Packer allows you to create consistent, immutable machine images across platforms like AWS, Azure, and VirtualBox. For WordPress, this means you can pre-bake AMIs with all dependencies—web server, database, PHP, and WordPress itself allowing you to create a fast, scalable, and reliable deployment in your environments. By chaining builds, you can create a modular pipeline: a base image with the core setup and an enhanced image with customizations like plugins and security configurations. This allows developers to work on the base image and tweak it how they see fit, or tweak an enhanced image to ensure security and vulnerability tests are met. If you had AMI instances in different regions of the world this could allow you to add translation plugins or GDPR secuirty testing to an enhanced image and allow development in those European like areas. Packer essentially “PACKS” all the files, packages, filesystems, and everything into a reusable image to build cloud servers from.
The goal is to create two AMIs:
To follow along you can clone this repository
├── base-image
│ ├── ansible
│ │ ├── files
│ │ │ ├── nginx.conf.j2
│ │ │ ├── wordpress.sql
│ │ │ └── wp-config.php.j2
│ │ ├── playbook.yml
│ │ └── scripts
│ │ └── install_wordpress.sh
│ ├── packer-base.json
│ └── scripts
│ └── bootstrap.sh
├── enhanced-build
│ ├── ansible
│ │ ├── files
│ │ │ └── secure-wordpress.sh
│ │ ├── playbook.yml
│ │ └── scripts
│ │ └── install_wordpress.sh
│ ├── packer-enhanced.json
│ └── scripts
│ └── bootstrap.sh
├── gh-actions-packer-build.yml
└── README.md
The base image sets up a fully functional WordPress installation. Here’s a breakdown of the key components.
This template uses the amazon-ebs builder to create an AMI from an Ubuntu 20.04 base image. It runs a bootstrap script to install Ansible and then uses an Ansible provisioner to set up WordPress.
{
"variables": {
"aws_access_key": "",
"aws_secret_key": "",
"aws_region": "us-east-1",
"ami_name": "wordpress-base-",
"ssh_username": "ubuntu"
},
"builders": [
{
"type": "amazon-ebs",
"access_key": "",
"secret_key": "",
"region": "",
"instance_type": "t2.micro",
"source_ami_filter": {
"filters": {
"virtualization-type": "hvm",
"name": "ubuntu/images/*ubuntu-focal-20.04-amd64-server-*",
"root-device-type": "ebs"
},
"owners": ["099720109477"],
"most_recent": true
},
"ami_name": "",
"ssh_username": "",
"associate_public_ip_address": true,
"force_deregister": true,
"force_delete_snapshot": true
}
],
"provisioners": [
{
"type": "shell",
"script": "scripts/bootstrap.sh"
},
{
"type": "ansible",
"playbook_file": "ansible/playbook.yml",
"extra_arguments": ["--extra-vars", "db_name=wordpress db_user=wp_user db_password=securepassword"],
"ansible_env_vars": ["ANSIBLE_HOST_KEY_CHECKING=False"]
}
]
}
#### Ansible Playbook: base-image/ansible/playbook.yml
The Ansible playbook installs Nginx, MariaDB, PHP, and WordPress, configures the database, and sets up Nginx to serve the WordPress site. Key tasks include:
This makes sure Ansible is available on the base image:
#!/bin/bash
set -ex
sudo apt-get update
sudo apt-get install -y software-properties-common
sudo apt-add-repository --yes --update ppa:ansible/ansible
sudo apt-get update
sudo apt-get install -y ansible
To build the base image locally, run:
cd base-image
packer build packer-base.json
This creates an AMI named wordpress-base-
The enhanced image builds on the base AMI, adding WordPress plugins and security packages.
This template uses the base AMI ID as an input variable:
{
"variables": {
"aws_access_key": "",
"aws_secret_key": "",
"aws_region": "us-east-1",
"ami_name": "wordpress-enhanced-",
"ssh_username": "ubuntu",
"base_ami_id": ""
},
"builders": [
{
"type": "amazon-ebs",
"access_key": "",
"secret_key": "",
"region": "",
"instance_type": "t2.micro",
"source_ami": "",
"ami_name": "",
"ssh_username": "",
"associate_public_ip_address": true,
"force_deregister": true,
"force_delete_snapshot": true
}
],
"provisioners": [
{
"type": "ansible",
"playbook_file": "ansible/playbook-enhanced.yml",
"extra_arguments": ["--extra-vars", "wp_plugins='yoast-seo akismet'"],
"ansible_env_vars": ["ANSIBLE_HOST_KEY_CHECKING=False"]
}
]
}
This playbook installs security packages and WordPress plugins:
#!/bin/bash
set -ex
# Disable directory listing
sed -i 's/autoindex on/autoindex off/' /etc/nginx/sites-available/wordpress
# Restart Nginx
systemctl restart nginx
# Update WordPress core
wp core update --path=/var/www/html/wordpress --allow-root
To build the enhanced image locally, you’d need the base AMI ID:
cd enhanced-image
packer build -var "base_ami_id=ami-1234567890abcdef0" packer-enhanced.json
Manually passing the AMI ID is tedious. So we should automate it with GitHub Actions.
The GitHub Actions workflow (packer-build.yml) generates the build process, chaining the base and enhanced image builds and passing the base AMI ID automatically.
name: Build Packer AMIs
on:
push:
branches:
- main
pull_request:
branches:
- main
workflow_dispatch:
jobs:
build-base-image:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Set up Packer
uses: hashicorp/setup-packer@v3
with:
packer_version: 1.10.0 # Adjust to the desired version
- name: Build base image
id: build_base
env:
AWS_ACCESS_KEY_ID: $
AWS_SECRET_ACCESS_KEY: $
run: |
cd base-image
packer init packer-base.json
packer build -force packer-base.json > packer-base-output.log
# Extract AMI ID from Packer output
AMI_ID=$(grep -oP 'ami-[0-9a-f]{17}' packer-base-output.log | tail -1)
echo "BASE_AMI_ID=$AMI_ID" >> $GITHUB_ENV
continue-on-error: false
- name: Upload base image log
if: always()
uses: actions/upload-artifact@v4
with:
name: packer-base-log
path: base-image/packer-base-output.log
retention-days: 5
outputs:
base_ami_id: $
build-enhanced-image:
needs: build-base-image
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Set up Packer
uses: hashicorp/setup-packer@v3
with:
packer_version: 1.10.0
- name: Build enhanced image
env:
AWS_ACCESS_KEY_ID: $
AWS_SECRET_ACCESS_KEY: $
BASE_AMI_ID: $
run: |
cd enhanced-image
packer init packer-enhanced.json
packer build -var "base_ami_id=$BASE_AMI_ID" -force packer-enhanced.json > packer-enhanced-output.log
- name: Upload enhanced image log
if: always()
uses: actions/upload-artifact@v4
with:
name: packer-enhanced-log
path: enhanced-image/packer-enhanced-output.log
retention-days: 5
The workflow will build both AMIs and output their IDs in the logs. Check the artifacts for detailed logs if anything goes wrong. This Packer and GitHub Actions pipeline shows the power of Infrastructure as Code. Whether you’re running a single blog, an ecommerce site, or a fleet of WordPress sites, this approach ensures consistency, scalability, and repeatability.
Check out the full code in my github repo link here.
]]>The Flask app is built as an API interface to display NBA data fetched from the RapidAPI NBA API. The main page features a Matrix-themed design with Neo’s ASCII art and links to various API endpoints, such as /api/teams, /api/seasons, /api/leagues, /api/games, and /api/standings. The /api/test endpoint returns a static list of NBA teams with their IDs and names, while the other endpoints dynamically fetch data from the RapidAPI service. The project was a great way to combine my love for basketball, web development, and Python’s simplicity.
In this blog, I’ll share my experience and insights on these key aspects. My intent is to share these things for people who arent in the tech feild and have them digest the information easily so forgive me for not going to deep into the weeds of this project.
One of the first challenges I had was how to securely store my RapidAPI key and host information. Hardcoding API keys directly in the source code is a security risk, especially if the code is shared publicly on GitHub or any public version control system. I decided to use a .env file to store my API credentials and loaded them into the Flask app using the python-dotenv library. I typically stay away from adding complexity to code but a minimal amount of libraries is fine in this case.
I created a .env file in the project root to look like this:
RAPIDAPI_KEY=your_rapidapi_key_here
RAPIDAPI_HOST=api-nba-v1.p.rapidapi.com
In the Flask app.py, I imported load_dotenv from python-dotenv and os to access these variables:
from dotenv import load_dotenv
import os
load_dotenv()
headers = {
'X-RapidAPI-Key': os.getenv('RAPIDAPI_KEY'),
'X-RapidAPI-Host': os.getenv('RAPIDAPI_HOST')
}
This approach allows to me keep sensitive data outside of the app. The load_dotenv() function reads the .env file and makes the variables available via os.getenv(), allowing the app to access the API key and host securely.
Since the .env file contains sensitive information, it’s important to prevent it from being committed to version control. I added the following line to my .gitignore file:
.env
This ensures that git ignores the .env file, keeping my API key safe from accidental exposure on platforms like GitHub. Without this step, anyone with access to the repo could see the API key and leverage it to do hundreds of pulls leading to unauthorized access or exceeding API usage limits (and leaving me with a big bill to pay at the end of the month).
Using a .env file with .gitignore is a best practice for any project involving sensitive data. It’s a simple yet effective way to maintain security while keeping the codebase clean and shareable.
APIs are like gateways to a treasure trove of data, and the NBA API provided a wealth of information about teams, games, standings, and seasons. Trying to explain that to my wife makes it seem like im in the matrix to her but the ability to fetch real-time or historical NBA data with a simple HTTP request felt like unlocking a superpower.
The API endpoints I used included:
Each endpoint was accessed using Python’s http.client module, with the response parsed as JSON and returned via Flask’s jsonify function. For example, the /api/teams endpoint was implemented as follows:
@app.route("/api/teams", methods=["GET"])
def get_teams():
conn = http.client.HTTPSConnection(os.getenv('RAPIDAPI_HOST'))
conn.request("GET", "/teams", headers=headers)
res = conn.getresponse()
data = res.read()
conn.close()
return jsonify(json.loads(data.decode("utf-8")))
The thrill of seeing real NBA data flow into my app was addictive. I could fetch team rosters, check game schedules, or analyze standings with just a few lines of code. The API’s structured data made it easy to integrate into the Flask app, and the Matrix-themed front end added a fun, cinematic flair to the project because of my wifes thoughts on the matrix.
APIs make it possible to access vast amounts of data without needing to scrape websites manually or build complex data pipelines. The RapidAPI platform simplified the process further by providing an interface for the NBA API, complete with documentation and usage limits. The ability to query specific endpoints (e.g., games on a particular date) allow me to tweak the app to my interests, like focusing on head to head matchups between two teams.
For basketball fans, working with NBA data feels like stepping into the game itself. Whether it’s checking the latest standings or revisiting past seasons, APIs bring the data to life in a way that’s both fun and practical. This is the modern way the internet works and now I see why some people find this so fun.
Python’s simplicity and versatility were key to making this project quick and painless. From setting up the Flask web server to handling API requests python’s ecosystem made every step intuitive and efficient. This is probably why python is #1 on the TIOBE INDEX.
Flask is a lightweight and flexible web framework that allowed me to set up routes and serve content with minimal boilerplate. The main page, with its Neo ASCII art and links to API endpoints, was created using Flask’s render_template_string function:
@app.route('/')
def index():
return render_template_string(template, neo_art=neo_art)
This simplicity let me focus on the core functionality—fetching and displaying NBA data—without getting bogged down in complex configuration. The matrix like ASCII art and the overall homepage are just nice-to-have’s and not necessary for the actual endpoints.
Python’s built-in http.client module made it easy to send HTTP requests to the RapidAPI NBA API. Combined with the json module, parsing the API responses was straightforward:
import http.client
import json
conn = http.client.HTTPSConnection(os.getenv('RAPIDAPI_HOST'))
conn.request("GET", "/standings?league=standard&season=2024", headers=headers)
res = conn.getresponse()
data = res.read()
conn.close()
return jsonify(json.loads(data.decode("utf-8")))
This code snippet shows how Python handles HTTP requests and JSON parsing with minimal effort, making it ideal for rapid prototyping and development.
The python-dotenv library for managing .env files is a great example of Python’s functionality and flexibility. With just a few lines of code, I could securely load environment variables, keeping my API credentials safe from web crawlers and potential hackers. Python’s package manager, pip, also made it a little easier to manage dependencies and document them in requirements.txt:
Flask==3.0.3
python-dotenv==1.0.1
This file ensures that anyone else working on the project can install the exact dependencies with a single command: pip install -r requirements.txt.
Python’s readability and extensive libraries allows you to build the app quickly while maintaining clean, maintainable code. I learned that back in 2018 when first learning how all these apps connected to each other using a variable that didnt seem defined anywhere. With the experience I have gained over the years I find that to be common place now, but it blew my mind back in the day.
This project was a fun refresher course that combined by python skills with my passion for basketball.
As far as my next steps, I plan to enhance the app by:
There were a few peices of inspiration behind building the app but a big part of it was building out a project with a friend and to solve the issue I was having with finding head to head data. Currently to find out if the Miami Heat have beant the Minnesota Timberwolves over the last 5 games they have played you have to go to nba.com or espn.com and navigate through pages upon pages of data and information. It can get a little tricky. Finishing this app will allow us to pull that data with an api and get our answers immediately.
To check out the Matchups App we are building you can check here. However, if you want to grab just the backend portion and play around with API’s and Python you can check out my git repo here
]]>When working with automation tools like Ansible or managing storage systems, it’s common to test scenarios involving large files — whether you’re verifying delete operations, assessing disk space thresholds, or benchmarking storage performance. Instead of copying actual large datasets, you can simulate them by using the fallocate command in Linux.
In this blog post, we’ll walk through:
Here are a few practical scenarios:
Testing Ansible Delete Playbooks You might be automating the cleanup of files older than X days or larger than Y GB. To test your playbook safely, you’ll want to generate dummy files of significant size.
Storage Capacity Testing Simulate disk usage to ensure alerts, monitoring, or threshold actions behave correctly when space runs low.
File I/O Benchmarking Large files can help you test file system performance or backup tools under realistic conditions.
The fallocate command is the fastest way to create large files in Linux. It allocates space at the filesystem level without actually writing data, making it nearly instant.
fallocate -l <size> <filename>
fallocate -l 3G /tmp/testfile.bin
This creates a 3GB file at /tmp/testfile.bin in a fraction of a second. It appears fully allocated on disk but is not filled with data like zeroes or random bytes.
This helps trigger low-disk-space alerts or test how your application reacts when the disk is nearly full.
Note: Some filesystems (e.g., XFS, ext4, Btrfs) support fallocate, but others (like FAT32 or some network filesystems) might not.
## Use Case: Testing Ansible File Deletion Playbook
Suppose you’re writing an Ansible playbook to delete files larger than 3B in /var/log/test:
mkdir -p /var/log/test
fallocate -l 3G /var/log/test/testfile1.bin
fallocate -l 1G /var/log/test/testfile2.bin
- name: Find files greater than or equal to 3GB in /var/log/test
find:
paths: "/var/log/test"
recurse: yes
size: "2g"
file_type: file
register: event_large_files
- name: Display files that will be deleted (for logging visibility)
debug:
msg: ""
loop: ""
when: event_large_files.matched > 0
- name: Delete files greater than or equal to 2GB
file:
path: ""
state: absent
loop: ""
when: event_large_files.matched > 0
ansible-playbook cleanup_large_files.yml
You’ve now safely tested your logic against dummy data without risking production logs or valuable files being tested or removed accidentally.
Creating large files with fallocate is a fast, efficient, and safe way to simulate data for testing Ansible playbooks, storage thresholds, and system performance. Whether you’re a systems engineer, SRE, or DevOps practitioner, mastering this tool can help you create realistic test environments without waiting hours to copy or generate large datasets.
Storage space is running out on a linux server. The files taking up space are iologs and logs larger than 3GB. The team has developed an ansible playbook to remove logs larger than 3GB in specific dirs but the storage issues have been resolved on the servers that were reporting space issues. How can we reproduce large files on a development server to test the ansible playbooks and confirm it will pick up large files and remove them accordingly?
The fallocate command is a fast and efficient way to create large files for testing and development purposes on Linux systems. It allocates disk space to a file without actually writing data to it, making it ideal for simulating large files quickly. This is particularly useful for testing scripts or systems that handle file size thresholds, such as removing files larger than 3GB or validating storage limits.
To create a 3GB file using fallocate, you can run the following command:
fallocate -l 3G /tmp/dummy-file.bin
]]>Anyway, I went the admin/engineer route because I was looking for longevity and wanted to get my foot in the door so I took jobs that were weird or shady or sketchy and anytime something happened I kept telling myself “this is not my final destination” although it was some for some people. Now that I’ve been in the “hospital” for 10+ years I’m able to consider moving into a doctor like role or maintaining the engineer role I have….not sure if engineer and nurse would be the same in this comparison but the idea still sticks.
If you want to be a contrarian you could argue that the barrier of entry to being a doctor/surgeon vs being a programmer is vastly different but the idea remains the same. The hospital is the IT field and programming/cyber security/networking are no different than children’s care, or EMT, or burn victim units. They are all different areas that cns be studied to get in the field. Programming just happens to have a higher payout short term vs entry level jobs doing things like networking or cyber security.
When you think long term the journey in the middle can feel like a blur or bliss or both at the same time but many people try to learn to code short term and burnout. Learning to code is no different than playing basketball. Gotta create the projects, dribble the ball, learn the applications and how the game is played and stay consistent with it on and off the clock. Being an engineer allows me to work on more than just a niche part of an ecosystem it allows me to deal with firewalls, networking, cyber security, virtualization, and more so it’s worth it in the long term
While working at one of the many contracted positions I have held I heard someone mention in a standup meeting the idea that the job market is booming but its no different than studying the stocks and understanding annual trends in IT like Eternal September. The idea that the uptick in open jobs in the market or jobs going away due to AI in modern times is no different than the feelings that my co-worker had years before when he mentioned now is a good time to find a new job but jumping from job to job and not having a gameplan or having your gameplan focus only on finances will have you run through an Eternel September where every year or every time something big happens and the stress/workload gets to you your mind is off to the races and looking for something different. It’s reminiscent of the The quote “Wherever you go, there you are” which is a saying that emphasizes that you cannot escape yourself or your problems, as you carry your inner self and your baggage with you wherever you go.
With a plan, and a goal that focuses on longevity and the long term affects of career decisions, study choices, or job offers, the end-goal can be obtainable. With the right mindset the journey can be a fun ride as well. There is a lot to being a doctor, but there is much more on the road travelled then just the destination.
]]>