Project Overview

This project was the direct result of my desire to create a space where I could showcase my projects, technical experience, and ongoing learning. I’ve always enjoyed finding other portfolio sites that had more personality than just a normal blog. After finding a few designs I thought were really creative, I decided, maybe I should give it shot and try to create my own. Now, echoing the wise words of Jeremy Clarkson I can say, “I did a thing”. This site is now live.

Goals

• Create a platform where I can post technical projects I am working on or have completed
• Create unique pages that blend my background in meteorology with my passion for technology
• Don’t make ‘just another blog’

Architecture

I spent a few days bouncing ideas off ChatGPT and looking at examples of what went into creating a portfolio website before I started writing a single line of code. After a good bit of research, I decided on utilizing the Astro framework since I only needed the site for static pages. Astro’s content collections were also exactly what I was looking for with the projects and technical writings I want to post.

The website itself is hosted through Cloudflare. I leverage their ‘Workers & Pages’ features which let me link the site’s GitHub repository. Whenever I want to push changes or post something new, all I need to do is push the updates to the repository. Cloudflare sees the new commit, then rebuilds and deploys the updated site. This architecture made the most sense for me because there are only a few workings parts implemented to help keep the site easy and cheap to maintain.

Implementation

1. Project Structure and Initial Setup

I decided on creating an Astro site since the only thing I would be doing was creating static project pages. To start, I installed node.js and Git. I then created a new Astro project in Visual Studio Code with command npm create astro@latest [filepath], selecting the blog template to use as the base.

Since I was working on this project across a few different devices, I initialized Git for version control and connected this project to a new GitHub repository.

After getting the development workflow working, I ran the first test with npm install then npm run dev. I wanted to see how Astro’s blog template was formatted and start planning on the changes I wanted to make for later. After verifying the local server was working, it was time to start building and making the site my own.

2. Design System and Styling

I spent a few hours looking up other Astro site templates online to get a few ideas for how I wanted mine to look and also to see what was possible. I knew I wanted the theme to blend my meteorology background and IT experience together so visitors could be given a better representation of who I am.

The theme I settled on uses dark mode style interfaces with muted blue colors for accent. I wanted the site to feel like you were both in a server room or on the outskirts of an incoming storm. To help keep the site pages consistent and make formatting easier, I reused many elements including the colorway, fonts, and spacing across all pages.

While I was looking up other Astro templates, I saw some that had visual features that made the site feel alive and active. Now that I saw this was possible, I knew I wanted to add something like this to my site. This led me to add many of the visual elements seen on the Homepage and Project pages. I intentionally kept these effects CSS and SVG based as to not require a large JavaScript application to run them.

3. Component-Based Homepage

The main index.astro homepage was the part of this project I spent the most time on. It was the most visually complex part of the site. The index.astro itself doesn’t have too much code in it. All it does is call each Astro component I created for each section of the home page. The homepage is made up of four components. The Hero section, the Featured Projects section, the Skills section, and a Contact section.

The Hero component was the hardest part visually of this project. The thunderstorm is layered with CSS, SVG lightning, a radar sweep, my headshot, and a whole lot of formatting tweaks. Since this was going to be the first thing someone sees when landing on the website, I wanted it to show something unique that also showed creativity.

The Featured Projects component was setup to show more of my IT experience. This section leverages Astro’s content collections, specifically the getCollection() function, to pull the 3 most recent projects that have “Featured” enabled in their metadata. By utilizing my “Projects” content collection this way, I do not need to manually update the component whenever I post a new project I want featured. Visually I added two network racks with topology lines between them and little “packets”, going across to represent traffic.

The Skills component is meant to pay homage to the work done with Linux terminal. It is displayed as two Linux terminals, the right one being a play on apt list --installed and the left being a play on cron jobs. As I continue more projects, the idea is to have this updated with new skills and highlighting the ones I’m actively working on.

The Contact component was kept simple, just a normal call to action with a button that takes you to the contact page.

4. Content-Driven Project System

This was one of the more technical pieces of the website. The projects writeups themselves are .md files stored as content entries in the \content\projects folder. When getCollection("projects") is called, it goes through each project file and pulls information from it’s metadata. This is used to generate the project cards you see on the Project page and the Featured Projects section on the homepage.

The other piece of the Projects page is the use of dynamic routes with an [id].astro template file used for the projects. This was done so that I wouldn’t have to create a new static page whenever I posted a new project. During the build process, getStaticPaths() retrieves everything within the ‘projects’ content collection and creates a page for each project.

5. Supporting Pages

The Experience, About, and Contact pages all share the same general design with each having something unique about them. The goal was to have these pages follow a similar set of features like formatting, font size, and color way while not being completely identical.

The Header is used across all pages of the site to handle navigation. The Footer is also shared across all pages and is used as an easy way to get to my GitHub and LinkedIn pages.

6. Testing, Iteration, Polishing

Development of the site was iterative. Each component was created then tested on the local server. After a new component or page was implemented, I would go through and verify everything was working. This included verifying the site would build without any errors, formatting stayed consistent, and making sure the the change fit with the rest of the site’s theme while still serving a function. Once I was satisfied with changes in place, I would move onto the next section.

This process worked really well for me. Instead of implementing everything at once, I found it much better to work on a small piece, get it working, then move onto the next one. This also made troubleshooting much easier since if something went wrong, I would quickly know what piece to start looking at.

ChatGPT was used throughout the project as a development and troubleshooting tool. This included utilizing it to help generate code, explore implementation approaches, and troubleshoot issues that arose. While working on this project, I’ve learned just how powerful AI can be as a development tool. However, I believe if it is going to be used, you need to understand the changes it is making and how those changes fit with the rest of the project. The iterative process I adopted for the project was great for this. When I utilized AI to help make changes or write code, I would rigorously test the change to see how it would effect other parts of the site. After evaluation, I would decide if the changed belonged in the project or if more changes would be required.

Towards the end of the initial development, before I wanted to push the site live, I did a walkthrough to see what needed polish and cleaned up. This included going through every page to fix formatting, make any last minute changes to text and buttons, and make sure everything was working as intended. During this process, I wanted to make sure the site looked good on mobile devices, smaller screen tablets, and on normal PCs as well.

7. GitHub and Cloudflare Deployment

Once I was happy with the general feel and design of the test site, I pushed all the changes to the GitHub repository and started working on getting the site setup with Cloudflare. I linked my GitHub repository for the site to Cloudflare using Cloudflare Pages. This let me configure the build process within Cloudflare to trigger whenever new changes were pushed to the main branch. Once Cloudflare saw there was a new change to the repo, it would build site from the changes then serve the static site.

Before going fully live on the paulbeaver.com domain, I tested the site using a Cloudflare-provided pages.dev address. This let me do a last Q/A check before putting the site live on the custom domain. After verifying the site was able to build without issues and I liked the way everything look, I fully pushed the site live.

After the site was live, I spent a little bit of time working on the DNS rules and redirects. I was able to setup the www. subdomain and correct redirects so users would still get to the site depending on the link they used.

Problems & Troubleshooting

Throughout this project, I ran into several issues that required troubleshooting. I wanted to highlight a few of the major ones below.

Problem #1: Formatting Challenges

Symptoms

Changing some of the text from the Astro blog template exposed formatting flaws. Text did not look like it fit within certain viewports.

Cause

Formatting rules for each page caused issues where you were only able to put in a certain amount of text before it would expand too far or creep into other areas.

Solution

Updated the code and general format scheme for certain features on pages. This included making changes such as;

• Gave more screen space for text blocks
• Shrunk and enlarged text in certain areas to allow for a better fit in the viewport
• Removed certain text blocks entirely

Problem #2: Deleting Template Files Caused Errors

Symptoms

Deleting certain template placeholder images caused site to break when being built.

Cause

Certain files were still importing and making calls for the deleted images.

Solution

Cleaned up code of several components to no longer require the images.

What I Learned

There were quite a few things I learned after having worked on this project. This site was the first time I have ever setup a portfolio site so working in HTML, using CSS for formatting, and getting the page live were all new to me. Here are some of the more important lessons I took away from this project.

Lesson #1: HTML is a Sandbox

I’ve only ever worked with HTML briefly to help make lockdowns for EMMs. Now having used it to build a website, I realize there is such a high ceiling for what can be done with HTML. The code is also relatively easy to pick up and read through. I learned more about semantic HTML elements and incorporated them into many pages. CSS is also a whole other beast in itself. I learned about all the things you could do with CSS and how important it is to get it right. I was able to get familiar with positioning, clamp(), and controlling images while working with the CSS for the pages.

Lesson #2: Astro is a Very Powerful Framework

When I was first started looking into the best ways for a beginner to make a website, I saw that Astro was one of the better frameworks to use starting out. This was definitely one of the smarter choices I made for this project. Astro’s content collections, how it utilizes components, and how it builds static sites was very easy to pick up early. I was up and running with the developer build after a few google searches. There were a few hiccups when trying to figure out what to change in the content.config.ts file but once I found the answers it got a lot easier.

Lesson #3: Figure Out The Design Early

One of the things I thought I did well during this project but know I could improve upon in the future is getting the website design, styling, and formats done early. I had a good idea of the general design and theme when I started which made it easy to make other styling choices later. However, while I was checking the Experience, About, and Contact pages I made later into the build of the project, I realized each page’s styling was different. This led me to create a global.css file that I could reference when making each page to keep things consistent without having to manually make the changes across different pages.

Future Improvements

• Add a ‘Writings’ section for knowledge base articles and smaller tasks other than projects
• Improve animations
• Update experience and skills as I get more experience