This Site

I'd always been unsatisfied with my old sites. They did the job of linking to a few of my projects, they provided some contact information for me, but were nothing you could spend a lot of time looking at, nor something that looked professional, nor something that let me just... type.

I tried a bunch of band-aid solutions in the years after creating that one - briefly looking into using WordPress, using Jekyll with GitHub Pages to create a "blog," even looking into using Squarespace at my darkest moments.

But I finally bit the bullet about a month ago. I sat down, began to do some research, and began to build myself a new site.

The Goals

I laid out a few of my concerns with my old sites above, but I'll list them here alongside my goals for this site in full:

1. Look professional and modern across all devices
2. Provide links to my other digital footprints (email, github, linkedin, etc.)
3. Allow for a short bio
4. Showcase all of the projects I'd ever hope to document.
5. Allow me to discuss each project in length, without having to recompile anything or push to a repository.

With these goals in mind, I started on the first four goals by simply mocking up my website in hand-written HTML/CSS in VSCode. 

To do this, I started with just one external library - Water.css (kognise.dev). I wanted something lightweight that I could easily manipulate and understand, without having to wrap my brain around something heavy and cumbersome like Bootstrap. This, plus a font from Google Fonts, led to the core of the visual style of the site. 

I wanted a pinned sidebar, for easy navigation and reference purposes on project sites, so I added that in.

The main challenge laid around how to actually layout everything across multiple devices. To do this, I used something I hadn't played with before: CSS Grids. They turned out to be really intuitive, but they really only helped me lay out the site. I needed to go through and make it responsive.

I ended up finding MediaQueries worked best for this. I'd define the layout for the smallest possible size - mobile, then add a breakpoint at tablet size, and another at desktop size. Therefore, all bases would be covered. Turn on the grid at the desktop size, and tada! The entire site now cleanly snaps to whatever form it is on.

This helped me get a handle on what I wanted to showcase, and how I wanted to showcase it. As you can see, I didn't deviate too far from this initial concept, just focusing on cleaning up clutter and visually organizing similar elements. This all happened during the implementation phase.

Now to accomplish the last goal.

PHP is ugly

I wrote the entire thing by hand in PHP, talking to a MySQL server.

At it's core, this site is a traditional CRUD application - we Create new projects, Read existing ones, Update ones I'd like to alter, and Delete ones I don't want to share anymore. In the end, the CUD part of CRUD ended up being locked behind an authentication/admin page that I will not share the details of here, but overall, it's a pretty standard setup for PHP.

I looked through most online guides to find the "best" or "proper" way to do a setup like this. Nothing I saw satisfied me - the most simple ones involved writing PHP and HTML in a completely intertwined fashion, making it impossible to read or maintain. The more complicated ones involved miles of boilerplate code that I wasn't interested in replicating for my project. In the end, the only external code libraries I ended up using were this router bramus/router: A lightweight and simple object oriented PHP Router (github.com) for organizing endpoints and TinyMCE for the project editor.

I ended up creating a system of "Widget" classes, each of which took in the mysql connection object as well as whatever relevant parameters they needed to display content. They'd then use the "template" class to render out their HTML, which would then be returned to the user.

It's not the cleanest setup, but it works well for me, and is relatively expandable.

Over about two weeks, I wrote the vast majority of the functionality of the site. The biggest implementation challenge lied in the administration tools - as it turns out, creating tools to upload and administrate a site is much more involved than just displaying content.

Just as an example, here's the admin page for this post:

Most of the stuff is pretty standard, with the exception of the tags/assets system. These are two (technically three) other tables in the database which manage the many-to-many relationship that tags have, as well as the one-to-many relationship that any project has with its assets. These links open up modal dialogues which allow me to create, link/unlink tags, and upload and insert assets into any given point in the editor.

Writing is Hard

While developing a website takes a lot of time, the part of the development process that actually took me the longest was the documentation of my previous projects. The shortest projects sit at about a ~500 word description, while the longest (currently) have over three thousand words. That's not even counting the wide variety of pictures, assets, and other embedded media that I've organized and dug through in order to help document my past projects.

It was a very, very tedious process going through and writing about everything. But it was also very cathartic and nostalgic.

I've been working on various programming projects since 2015 - and rarely stopped for any length of time. Digging through my oldest stuff was a little treacherous - the march of time doesn't take kindly to abandoned code. But it let me experience a lot of the highs and lows that come from looking back at your own history.

I've now spent about half a month just writing and documenting old projects, up until this one right here. It's provided me a looking glass through which to view myself over the past half-century, and it's been a very uplifting reminder of what I've done and where I've come from.

Keep an eye on this site to see where I go.