soconnor/personal-website
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

refactor: fix linting and typechecking errors

Browse Source
This commit is contained in:
Sean O'Connor
2025-12-11 19:41:36 -05:00
parent 962f2ad7ee
commit 4f9602a242
35 changed files with 768 additions and 720 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/content/blog/accessibility.mdx
+8 -2
View File
@@ -5,9 +5,10 @@ import Link from "next/link";
export const metadata = {
title: "Accessibility Features",
publishedAt: "2024-11-01",
summary: "A deep dive into the process of building an inclusive web experience, from semantic HTML to custom accessible components.",
summary:
"A deep dive into the process of building an inclusive web experience, from semantic HTML to custom accessible components.",
tags: ["Accessibility", "WCAG", "Inclusive Design", "Web Standards"],
image: "/images/accessibility.png"
image: "/images/accessibility.png",
};
# Building an Inclusive Web Experience
@@ -21,22 +22,27 @@ For me, the motivation was twofold. Professionally, I wanted to demonstrate that
## The Implementation Process
### Starting with the Basics
The journey began with the fundamentals: **Semantic HTML**. I ensured that the site uses a logical heading hierarchy (`h1` through `h6`) so that screen reader users can easily navigate the document structure. I also made sure to use appropriate semantic elements like `<article>`, `<nav>`, and `<main>` instead of just wrapping everything in `div`s.
### Visual Accessibility
Color and contrast were next on my list. I carefully selected a color palette that meets **WCAG AA standards** for contrast, ensuring that text is readable for users with visual impairments. I also implemented a system-aware dark mode, which isn't just a cool feature—it's essential for users with light sensitivity.
I also built a strict **Image Alt System**. Every image on the site is required to have descriptive alt text. This ensures that users who rely on screen readers don't miss out on the context that images provide.
### Interactive Elements
One of the biggest challenges was ensuring **Keyboard Navigation**. I tested every interactive element—buttons, links, form inputs—to make sure they could be reached and operated using only a keyboard. This involved managing focus states and ensuring that the tab order was logical.
## Overcoming Technical Challenges
### The Hydration Problem
Working with Next.js presented a unique challenge: **Hydration**. The split between server-side rendering (SSR) and client-side interactivity can sometimes cause issues with accessibility tools if the HTML structure changes during hydration. To solve this, I created client-side wrapper components for complex interactive features. This allowed me to keep the performance benefits of SSR while ensuring a stable, accessible experience on the client.
### Video Accessibility
I didn't want to just embed a standard video player. I built a custom **AccessibleVideo** component that includes closed captions with a toggle, a full transcript, and keyboard-accessible controls. This ensures that my video content is accessible to users who are deaf or hard of hearing, as well as those who prefer reading over watching.
## Ongoing Commitment
src/content/blog/design-system.mdx
+26 -20
View File
@@ -1,9 +1,10 @@
export const metadata = {
title: "Designing My System: Soft, Translucent, and Alive",
publishedAt: "2025-12-10",
summary: "A deep dive into the design philosophy behind my personal website's new theme, moving from rigid boxes to organic, living layers.",
summary:
"A deep dive into the design philosophy behind my personal website's new theme, moving from rigid boxes to organic, living layers.",
tags: ["Design", "UI/UX", "TailwindCSS", "Frontend"],
image: "/images/design-system.png"
image: "/images/design-system.png",
};
## The Philosophy: Soft, Translucent, and Alive
@@ -22,9 +23,9 @@ The heartbeat of this theme is the background. Instead of a flat color or a stat
```tsx
// src/app/layout.tsx
<div className="fixed inset-0 -z-10 overflow-hidden pointer-events-none flex items-center justify-center">
<div className="pointer-events-none fixed inset-0 -z-10 flex items-center justify-center overflow-hidden">
<div className="absolute inset-0 bg-[linear-gradient(to_right,#80808012_1px,transparent_1px)...] bg-[size:24px_24px]"></div>
<div className="w-[800px] h-[800px] bg-neutral-400/40 dark:bg-neutral-500/30 rounded-full blur-3xl animate-blob"></div>
<div className="animate-blob h-[800px] w-[800px] rounded-full bg-neutral-400/40 blur-3xl dark:bg-neutral-500/30"></div>
</div>
```
@@ -36,10 +37,10 @@ One of the biggest structural changes was detaching the navigation and sidebar f
In a traditional layout, the sidebar is stuck to the left, and the navbar is stuck to the top. In this system, they are **floating cards**.
- **Navbar**: Fixed `top-4`, `left-4`, `right-4`.
- **Sidebar**: Fixed `top-24`, `left-4`, `bottom-4`.
- **Navbar**: Fixed `top-4`, `left-4`, `right-4`.
- **Sidebar**: Fixed `top-24`, `left-4`, `bottom-4`.
This creates a sense of layering. The UI elements aren't *part* of the window; they are tools floating *above* the content.
This creates a sense of layering. The UI elements aren't _part_ of the window; they are tools floating _above_ the content.
## Design Tokens
@@ -47,9 +48,9 @@ This creates a sense of layering. The UI elements aren't *part* of the window; t
I chose a base radius of `1rem` (16px) because it strikes the perfect balance between friendly and professional.
- **Cards**: `rounded-3xl` (24px). Large containers need softer corners to feel less imposing.
- **Buttons**: `rounded-xl` (12px). Tactile and clickable.
- **Icons**: `rounded-full`.
- **Cards**: `rounded-3xl` (24px). Large containers need softer corners to feel less imposing.
- **Buttons**: `rounded-xl` (12px). Tactile and clickable.
- **Icons**: `rounded-full`.
This softness extends to interaction states. When you hover over a card, the `overflow-hidden` property ensures that any inner content (like images or background fills) respects these curves perfectly.
@@ -57,9 +58,9 @@ This softness extends to interaction states. When you hover over a card, the `ov
Instead of heavy drop shadows to show depth, I rely on **Glassmorphism**.
- **Surface**: `bg-background/80` with `backdrop-blur-md`. This allows the "Living Blob" to bleed through, tinting the UI with the background color.
- **Border**: `border-border/60`. A subtle, semi-transparent border defines the edges.
- **Shadow**: `shadow-sm`. A very light lift, just enough to separate the layer.
- **Surface**: `bg-background/80` with `backdrop-blur-md`. This allows the "Living Blob" to bleed through, tinting the UI with the background color.
- **Border**: `border-border/60`. A subtle, semi-transparent border defines the edges.
- **Shadow**: `shadow-sm`. A very light lift, just enough to separate the layer.
### 3. Color Palette
@@ -75,21 +76,21 @@ For typography, I wanted to blend the readability of a digital product with the
### The Serif: Playfair Display
<p className="text-4xl font-heading mb-6">Playfair Display</p>
<p className="mb-6 font-heading text-4xl">Playfair Display</p>
I chose **Playfair Display** for all headings (`h1`–`h6`). It's a transitional serif typeface with high contrast strokes and delicate hairlines.
* **Why Serif?** Serifs feel "human", "established", and "emotional". They break the sterile "tech" vibe common in developer portfolios.
* **Why Playfair?** Its high contrast makes it perfect for large display sizes. It commands attention and adds a layer of sophistication that a sans-serif simply cannot achieve.
- **Why Serif?** Serifs feel "human", "established", and "emotional". They break the sterile "tech" vibe common in developer portfolios.
- **Why Playfair?** Its high contrast makes it perfect for large display sizes. It commands attention and adds a layer of sophistication that a sans-serif simply cannot achieve.
### The Sans: Inter
<p className="text-4xl font-sans mb-6">Inter</p>
<p className="mb-6 font-sans text-4xl">Inter</p>
I chose **Inter** for the body text. It is the gold standard for screen readability.
* **Why Sans?** Sans-serif fonts are "rational", "clean", and "invisible". They reduce cognitive load, making long-form reading (like this blog post) effortless.
* **Why Inter?** It was designed specifically for computer screens, with a tall x-height that remains legible even at small sizes.
- **Why Sans?** Sans-serif fonts are "rational", "clean", and "invisible". They reduce cognitive load, making long-form reading (like this blog post) effortless.
- **Why Inter?** It was designed specifically for computer screens, with a tall x-height that remains legible even at small sizes.
### Implementation
@@ -109,7 +110,12 @@ theme: {
```css
/* src/styles/globals.css */
h1, h2, h3, h4, h5, h6 {
h1,
h2,
h3,
h4,
h5,
h6 {
@apply font-heading; /* Playfair Display */
}
src/content/blog/eceg431.mdx
+5 -4
View File
@@ -1,9 +1,10 @@
export const metadata = {
title: "ECEG 431 E-Portfolio",
publishedAt: "2025-12-01",
summary: "E-Portfolio and reflection for the Nand2Tetris course, covering the journey from NAND gates to a high-level compiler.",
summary:
"E-Portfolio and reflection for the Nand2Tetris course, covering the journey from NAND gates to a high-level compiler.",
tags: ["Simulation", "Compilers", "Python", "Assembly", "VM", "OS"],
image: "/images/nand2tetris.png"
image: "/images/nand2tetris.png",
};
## Assignment Prompt
@@ -71,7 +72,7 @@ The "oh crap" moment. A dark figure from the past comes to haunt you; a love is
For the course, this could be lots of things. Work piling up? Concepts getting hard? Confusion setting in? Difficulty asking for help? Reliance on LLMs piling on? Not coming to class? Or maybe something entirely external to the course. What was it for you? There seems to be a common theme that happens to all of us in this course---we set out strong, start doing well with big dreams, but we typically all go through something and our original plans for the course start to crumble. What were those moments for you?
**[Project 5: The CPU](https://github.com/soconnor0919/eceg431/blob/main/05/CPU.hdl)**. This is where the "just wrapping logic gates" theory fell apart. It wasn't just logic anymore; it was *timing*. It was *control*. Decoding instructions was fine, but managing the control flow was a nightmare.
**[Project 5: The CPU](https://github.com/soconnor0919/eceg431/blob/main/05/CPU.hdl)**. This is where the "just wrapping logic gates" theory fell apart. It wasn't just logic anymore; it was _timing_. It was _control_. Decoding instructions was fine, but managing the control flow was a nightmare.
```hdl
// projects/05/CPU.hdl
@@ -83,7 +84,7 @@ Not(in=aInstr, out=cInstr); // cInstr = 1 when instruction[15] = 1
Mux16(a=instruction, b=aluOut, sel=cInstr, out=aRegIn);
```
As I wrote in my reflection: *"The problem was taking the instruction and turning it into something the ALU could handle... I just repeatedly hit my head against a wall."* (Project 5 Reflection). The fix wasn't more code. I had to stop coding and start drawing. I couldn't "hack" my way through a hardware definition. I had to understand the signals.
As I wrote in my reflection: _"The problem was taking the instruction and turning it into something the ALU could handle... I just repeatedly hit my head against a wall."_ (Project 5 Reflection). The fix wasn't more code. I had to stop coding and start drawing. I couldn't "hack" my way through a hardware definition. I had to understand the signals.
> There are three steps to solving a problem. Write down what you know, Think really hard, Write down the answer. You're at step 2.
src/content/blog/latex-intro.mdx
+4 -3
View File
@@ -6,9 +6,10 @@ import Link from "next/link";
export const metadata = {
title: "Getting Started with LaTeX",
publishedAt: "2024-10-15",
summary: "A guide to my 5-minute introduction to LaTeX, explaining why it's the gold standard for academic writing and how to get started.",
summary:
"A guide to my 5-minute introduction to LaTeX, explaining why it's the gold standard for academic writing and how to get started.",
tags: ["LaTeX", "Tutorial", "Accessibility", "Education", "Overleaf"],
image: "/latex-thumbnail.jpg"
image: "/latex-thumbnail.jpg",
};
export const transcript = `
@@ -30,7 +31,7 @@ export const transcript = `
In the world of engineering and science, clear communication is just as important as the technical work itself. I created this tutorial because I noticed many students struggling to format their mathematical equations and technical reports using standard word processors. **LaTeX** is the solution to that problem.
It's the gold standard for academic and technical document preparation, especially in mathematics, computer science, and physics. Once you get past the initial learning curve, it allows you to focus entirely on the *content* of your work, trusting the system to handle the *presentation* professionally.
It's the gold standard for academic and technical document preparation, especially in mathematics, computer science, and physics. Once you get past the initial learning curve, it allows you to focus entirely on the _content_ of your work, trusting the system to handle the _presentation_ professionally.
## The Tutorial