Joe @ viable.dev

It's a pretty exciting milestone today – this very website, viable.dev, is now officially deployed and live! The journey to get here was a fantastic, hands-on learning experience, involving Google Cloud Storage (GCS), GitHub Actions for CI/CD, wrangling DNS with GoDaddy, and setting up a Google Cloud Load Balancer for robust HTTPS.

Phase 1: The Initial Plan - GCS & GitHub Actions

The first step was straightforward: create a GCS bucket to host the static HTML, CSS, and JavaScript files and configure it for public access. To automate updates, I set up a GitHub Actions workflow. This was my first dive into Workload Identity Federation (WIF) with Google Cloud, a more secure alternative to service account keys. It involved enabling a few APIs (IAM Credentials, specifically), creating a dedicated Service Account, and configuring a Workload Identity Pool to trust GitHub Actions. This allowed my GitHub repository to impersonate the Service Account securely for deployments. An early snag was an organization policy (iam.disableServiceAccountCreation), which thankfully WIF helped navigate by allowing the use of an existing, approved service account.

Phase 2: Bucket Names, Restructuring, and DNS Ponderings

I initially named my GCS bucket viable.dev. However, I quickly learned about the nuances of pointing apex domains directly to GCS via CNAME records, especially with GoDaddy, and the implications this has for HTTPS. To align with best practices and simplify things, I decided to "rename" the bucket by creating a new one – www.viable.dev – and configured it for website hosting. All files were copied over, and the GitHub Actions workflow was updated to point to this new www bucket. During this phase, I also caught a security oversight: my initial GitHub Action was uploading the entire repository, including .git and .github folders, into the public GCS bucket! A quick fix to the workflow path and a cleanup in GCS resolved that.

Phase 3: Leveling Up with a Load Balancer for HTTPS

Serving content over HTTP just wasn't an option; that padlock was essential. This meant the simple GCS static hosting setup needed an upgrade. Enter the Google Cloud HTTP(S) Load Balancer. This involved reserving a static IP, creating a Google-managed SSL certificate for both www.viable.dev and viable.dev, and configuring the Load Balancer itself. The backend was set up to point to our www.viable.dev GCS bucket, with Cloud CDN enabled for better performance. The frontend was configured with the static IP and SSL certificate, along with a redirect from HTTP to HTTPS. This also meant another round of DNS updates at GoDaddy: changing the CNAME for www.viable.dev to an A record pointing to the Load Balancer's IP, and creating a similar A record for the apex domain viable.dev after removing any old records or forwarding rules. A bit of DNS troubleshooting was needed here to clean up multiple, conflicting A records for the apex domain.

Phase 4: The Final Bosses - XML Gremlins & Typos

With DNS propagating and the Load Balancer in place, the SSL certificate eventually provisioned successfully. However, the site then decided to greet me with an XML list of bucket contents instead of the glorious index.html. It turned out that even with a Load Balancer, the GCS bucket's "Website configuration" (specifically, the main page suffix) is crucial. After a bit of a hunt in the GCP console UI, I set index.html as the main page suffix. Victory? Not quite. Next up was a NoSuchKey XML error. This usually means the system is looking for a specific file (like index.html) and can't find it. After meticulously checking paths and configurations, a classic culprit was found: a typo involving an errant slash (/) in a path reference. Fixing that tiny detail was the final key!

Outcome: Success!

And with that, viable.dev (and www.viable.dev) went live, serving content securely over HTTPS, with updates automatically deployed from GitHub. It was a multi-layered process with plenty of troubleshooting moments that served as great learning opportunities. It's incredibly satisfying to see it all come together!

Continued to iterate on the portfolio today, focusing on adding more personality and refining some of the visual effects. The main goal was to incorporate a circular profile picture into the "About Me" section, making it appear with a subtle fade-in animation as the section scrolls into view.

To achieve this, I added an `` tag just above the "About Me" title, styling it with Tailwind CSS for the circular shape, size, and initial `opacity-0`. The fade-in effect is triggered using an `IntersectionObserver` in JavaScript. When the image (or its container) becomes about 10% visible in the viewport, a CSS class `.is-visible` is added, which transitions the opacity to 1. This provides a nice, smooth introduction to the visual element without it being jarring.

While working on this, I noticed the SVG background animation we integrated yesterday wasn't showing through the content sections as intended. It appeared to be hidden behind opaque section backgrounds. After a bit of troubleshooting, the fix involved a couple of key adjustments:

• Ensuring the main content wrapper (`
  `) had a `background-color: transparent;` in the CSS.
• Modifying the Tailwind background classes for each content `
  ` (e.g., from `bg-white` to `bg-white/85` or `dark:bg-slate-800` to `dark:bg-slate-800/85`). This added a slight transparency to the sections, allowing the subtle SVG animation to peek through.
• I also slightly increased the fill opacity of the SVG path itself in the CSS (via the `--svg-fill-opacity` variable) to make sure it was present enough against these new semi-transparent backgrounds.

With these tweaks, the profile picture now fades in nicely, and the SVG background is once again visible, adding that dynamic layer I was hoping for. It's a good reminder that sometimes a small CSS tweak can make all the difference in how visual layers interact!

Integrated the proof-of-concept SVG scroll-depth animation as a dynamic background. The SVG is a large letter "J" that pans and zooms to different parts based on which section of the page is being viewed. This involved adding the SVG markup to `index.html`, linking Anime.js, and adapting the JavaScript to trigger viewBox changes based on section `offsetTop` values. Also styled the SVG path to change color subtly with the light/dark mode theme, aiming for a 10% offset from the main `body` background and making section backgrounds semi-transparent.

Challenge: Defining meaningful `viewBox` coordinates for each section. Ensuring the animation is smooth and the SVG is subtly visible through semi-transparent section backgrounds without impacting text readability.

Next Steps: Fine-tune `viewBox` targets, animation easing, and opacity levels for section backgrounds and the SVG path itself.

Updated website content based on the latest version of my resume. Re-evaluated the information architecture and navigation to simplify and improve clarity, moving to About, Experience, Skills, Project Log, Contact.

This marks the official start of this personal portfolio website project! The primary goal is to create a "living document". The PRD emphasizes a simple, accessible, single-page design. The "Project Log" itself is a key feature.