Project Background
The first reason for building this site was practical: I needed an entry that could carry more context than a PDF resume. A PDF is useful for job delivery, but it has limited space. It is hard to explain the design path, debugging process, and review conclusions behind a project.
A GitHub repository can show code, but without context it is still difficult for a reader to understand what problem the project solves, what responsibility I had, and how issues were located. So I built a personal portfolio site that combines an online resume, project portfolio, and technical blog.
Core Problem
The core problem was not “how to make a website.” The real problem was how to make the content maintainable and credible. The site needed to be easy to update, easy to deploy, and clear enough that each project could be understood without reading all source files first.
Another constraint was scope control. A first version could easily become too large if it included login, database storage, comments, complex animation, and administration pages. For a portfolio site, those features would distract from the real goal: making engineering experience readable.
My Approach
I chose GitHub Pages, Astro, GitHub Actions, and Markdown. GitHub Pages provides stable static hosting. Astro fits content-oriented pages and Markdown-based blogs. GitHub Actions can build and publish the static output automatically. Markdown keeps writing and maintenance lightweight.
The site structure was split into reusable components and pages: a base layout for metadata and navigation, a header, a footer, a project card component, normal pages for resume/projects/about, and a content collection for blog posts. This kept the project small while leaving room for later content growth.
Debugging and Verification
The setup exposed several useful engineering issues. One issue came from template download failure during the initial Astro setup. The request was routed to a local proxy address, so the key was not simply “download failed” but where the request was being sent.
Another issue came from Astro 6 content-collection changes. The old content configuration path was no longer accepted, so the fix was to use src/content.config.ts with a glob() loader. Deployment also required GitHub Pages to use the GitHub Actions source. These were not page-design problems; they were environment and platform configuration problems.
Final Result
The site now contains a homepage, resume page, project page, blog list, blog detail pages, about page, and 404 page. It can be built locally and deployed as a static site through GitHub Pages.
More importantly, the site gives each project a stable place to record problem background, role boundary, technical challenge, solution, result, and later review. The output is not only a visual page, but also a maintainable engineering record.
Review Takeaways
For this site, the most important decision was to keep the first version static and content-first. A portfolio does not need a heavy back end before the content is clear. The better order is to make the content structure solid, verify local builds, then automate deployment.
This site also made my project writing more disciplined. Instead of only listing tools, I now write what problem I solved, what action I took, and what result can be checked. That writing pattern is more useful for both resume delivery and future technical review.