Matt Rugamas (@mattrugamas)

Still on Jekyll, Probably Forever

2026-04-02T00:00:00+00:00

I’ve rebuilt this site a few times now. Not a full rebuild, more like the kind of thing where you touch one CSS file and end up rewriting three others. Each time I do it, I think about whether I should just… do it properly. Migrate to something modern. Maybe Next.js. Maybe Astro. Maybe whatever the new thing is by the time you’re reading this.

Each time, I end up back at the same place: a text editor, a folder of Markdown files, and a git push that deploys to GitHub Pages in about ninety seconds. No build server. No monthly bill. No framework to upgrade around. Just HTML and CSS, served from an edge node somewhere, loading fast on whatever connection you’re on.

I want to think out loud about why. It’s not because I haven’t looked at the alternatives.

What This Site Actually Is

A personal site is a weird thing to optimize. It’s not a product. It’s not a dashboard. Nobody is going to bounce if your page load is 300ms instead of 100ms. The requirements are relaxed: a place for text, the occasional photo, links I want to share, maybe some thoughts about things I’ve been working on or listening to. That’s it.

When I think about what this site needs, the list is short: serve HTML fast, don’t cost money, don’t break and let me write posts in a format I’ll still be able to read in ten years. Markdown in a git repo checks all of those. It’s also portable; if GitHub Pages disappears or changes its pricing, I can point the same files at Netlify, Cloudflare Pages, or an S3 bucket in about twenty minutes.

That’s a different kind of reliability than “the framework is well-maintained.” It’s the reliability of boring, stable technology that doesn’t have anywhere to go.

The Case Against Tech Like React (for this)

I want to be careful here. I’ve worked with React heavily before, debugging it, reading through it, explaining it, it’s great. But when I think about what I’d be adding to this site by reaching for it, I mostly come up with a list of new problems:

A JavaScript bundle to ship to every visitor. A Node runtime to keep alive somewhere (or a build step to manage). Framework versions to update. Dependencies that drift. A dev server that occasionally needs restarting. A bunch of tooling between me and the thing I actually want to do, which is write something and publish it.

For a site with no interactivity, no real-time data, no user accounts, no dynamic server-side logic, that tradeoff is hard to justify. The thing you’re optimizing for with a React app is developer ergonomics and component reuse. I have three pages. I don’t need component reuse. I need to write a post and not think about it until next time.

Jekyll’s output is just files. Which is, at the end of the day, what a website is.

The Nostalgia Is Real, But It’s Not The Point

Another point in the back of my mind is that there’s something that genuinely appeals to me about the personal site as a format. Not in a precious, “the web was better in 2012” way. More that I still believe in the idea of having a place online that is yours, that doesn’t route through an algorithm, that doesn’t disappear when a platform gets acquired, that you don’t have to fight to get your own posts back out of.

I spent years being reasonably active on social media. I’m mostly not anymore. Part of that is the obvious stuff, the toxicity, the engagement optimization, the way that every platform eventually becomes a worse version of itself. But part of it is simpler: I’d rather have a URL I control than a post that lives inside someone else’s product.

There’s a reason the people I find most interesting online tend to have personal sites. The act of maintaining one, even a simple one, is a small signal that someone thinks their thoughts are worth putting somewhere permanent.

What I Actually Use It For

Honestly? Not enough. The archive on this site is thin. But I’ve found that having it here, in a format I control, in a setup I understand end-to-end, makes it easier to write when I do want to. There’s no friction between having a thought and publishing it. I open a file, write some Markdown, push to a branch, and it’s live. The whole process from draft to published is maybe five minutes if I don’t overthink the title.

That frictionlessness is something I’ve come to value. It’s why I’m not migrating to something with more features, more flexibility, more configuration surface area. Features are friction when you don’t need them. I’ve got the features I need, and they’re working fine.

So we’re still on Jekyll in 2026. Probably forever, or at least until GitHub Pages does something unforgivable, which seems unlikely. And if they do, the files are right here.

The Redesign

2026-03-31T00:00:00+00:00

I’ve been sitting on a version of this site that I built sometime around 2018 or 2019, back when I was learning more front-end seriously and wanted a place to practice. It worked, mostly. The bones were fine. But it had the kind of accumulated debt that happens when you build something to learn and then never really go back to treat it like a real project.

A few weeks ago I decided to try and change that.

What It Was

The old site was functional but a little rough around the edges. The CSS was desktop-first, which meant I was patching mobile as an afterthought. There were no design tokens, just magic numbers scattered across files, colors hardcoded inline and three different breakpoint values that didn’t agree with each other. The navigation would overflow on small screens with no fallback. The resume page was outdated by about five years. And there was no light mode, which felt increasingly like a gap.

The content wasn’t much better. My bio was vague. The homepage intro led with a job title. The music and resume sections lived awkwardly together on the About page, which made neither feel intentional.

None of this was broken, exactly. But it wasn’t a site I’d hand to someone who asked to see something about me.

What Changed

I approached this in a few passes.

The first was architectural. I converted the whole stylesheet to mobile-first; base styles for small screens, min-width breakpoints layering in the desktop layout. I introduced a proper design token system using CSS custom properties: a spacing scale, a type scale, a named color palette. Every color reference in the codebase now points to a variable instead of a hardcoded value. That groundwork made the light/dark mode toggle possible, and honestly easier than I expected. It’s just a data-theme attribute on the root element, with a small script in <head> that reads localStorage before the first paint so there’s no flash.

The second pass was structural. I rebuilt the About page around CSS Grid instead of the flexbox column-reverse trick I was using before. I extracted music into its own page. I rebuilt the resume as an actual web CV with semantic HTML: proper headings, <article> elements per role, a <dl> for skills. The navigation got a hamburger menu for mobile and a somewhat cleaner active-state treatment.

The third pass was content. I rewrote the homepage intro and the About bio to say something more specific and honest about the kind of work I do. The framing I landed on, working at the intersection of customers, code and product, is more accurate than any job title I’ve held and it holds up across the kinds of roles I’m looking at next.

What’s Still The Same

The tech stack is unchanged. Still Jekyll, still GitHub Pages, still a git push to deploy. I wrote a whole other post about why I’m keeping that setup, but the short version is: it’s the right tool for what this site actually is. I didn’t need to migrate to something more complex to make it better. I just wanted to clean up the CSS and fix the copy.

The dark theme is still the default. The color palette is the same, a dark charcoal background with warm cream text and teal accents. What’s new is a light mode that maps those same values to their warm-background counterparts, keeping the same character just with the values flipped.

On Making Personal Sites

There’s something satisfying about treating a personal site like a real project rather than a test environment you keep meaning to clean up. The design constraints are low-stakes in a useful way, nobody’s filing a bug report if something looks slightly off, but that also means there’s no excuse not to just fix the thing that’s been bothering you.

This site is a work in progress in the most literal sense. The blog is thin. There’s probably still some CSS somewhere that’s doing too much work. But it’s a better version than what was here before, and that feels like the right direction.

Blog Update

2019-02-13T00:00:00+00:00

There is still a lot of cool Jekyll stuff I’ve yet to write about and I will, but January/February lines up with the end of the Winter semester here at good ol’ Mt. SAC and with my journey in applying for new positions related to my field. The good news is that my job search might be over, as I’m going over some preliminary details with a new employer for a Technical Support position supporting a fairly popular software product that is currently on the market and receiving lucrative investments. It’s a great opportunity that I’m crossing my fingers for, but the Jekyll writing has been on the backburner for now.

On top of that Jekyll is based on Ruby, which is awesome, but with recent developments in Gatsby and React a lot of my free time has gone towards learning vanilla javascript to get ready for the sleu of React/Gatsby books I’ve been able to acquire. It’s a very interesting area of development and would be more valuable as a front-end guy than taking time out to learn Ruby to get more familiar with Jekyll. The stuff I’ve been seeing made with Gatsby and React has still not stopped surprising me, so the amount of Jekyll content going forward might be limited to the setup of this site itself.

Anywho, that’s what’s been going on around here. I’ve been updating the bundle and making small cosmetic SCSS changes here and there, but as I build more a projects page will eventually have to go up soon. If you’re still reading I appreciate your time.

Playing With Jekyll Pt. II (Pages Whitelist)

2018-12-25T00:00:00+00:00

In my previous post I wrote about Jekyll and it’s integration with Github Pages, and I mentioned how Github Pages whitelists Jekyll dependencies in your build, essentially building our Jekyll site with the --safe mode flag. As I thought about how we might go around this, switching over to Netlify was a thought that came up that could get comments and syntax highlights going. I also realized I could just build the site locally and push my static pages over to the Github repo for my site, but seemed hacky.

A couple revealing blog posts later, enter Travis CI. With Travis CI, not only can we test our Jekyll builds but we can use any dependencies or versions of Jekyll that we like! I have my Travis CI set up so that it looks for changes on my release branch, builds and tests my site from that branch, and if it passes, pushes my resulting static pages to the master branch where it is hosted on Github Pages. Then, I just created a develop branch for development. When I have something working, I push to release for testing and if it passes, on to master!

The set up really couldn’t have been easier. I set up a Travis CI account by signing in with my Github credentials, and simply flipped a switch—like Drake—on my page repo to get it going. I added a .travis.yml file to the root to set up Travis’ build configs. Before getting that started, I also had to create a personal token and set that up in Travis’ settings.

language: ruby
        cache: bundler
        branches:
        only:
        - release
        script:
        - JEKYLL_ENV=production bundle exec jekyll build --destination site
        deploy:
        provider: pages
        local-dir: ./site
        target-branch: master
        email: deploy@travis-ci.org
        name: Deployment Bot
        skip-cleanup: true
        github-token: $GITHUB_TOKEN
        keep-history: true
        on:
        branch: release
        

With this workflow, we build on a local branch of our Git repository. We can then merge these changes into a remote release branch. Travis keeps track of our release branch, builds on change, and if it passes the tests we’ve set up in .travis.yml, travis pushes the release branch to the master branch of the GitHub repository. GitHub will then serve this master branch as the site when users visit your .io site.

This is perfect for using plugins that aren’t on the GitHub Pages Dependecy whitelist. It’s also an ideal solutions for unit tests and the like. Travis CI has many diverse functions that will keep me busy for much time to come.

Playing With Jekyll

2018-12-24T00:00:00+00:00

Jekyll feels like a great place to start, again. Ruby and RubyGems is familiar, I’ve gotten the hang of switching between Ruby environments with rbenv, and I like the idea of packaging Jekyll themes in a RubyGem. With Jekyll we can also style with SCSS, write posts in markdown (kramdown), and do kinda-dynamic stuff using HTML with Liquid—sweet.

Jekyll’s site tutorial has many useful components built in that we’re going to keep. The blog component is very simple, and since we’re going to be writing, that stays over. There’s no staff and separate blog page on this site, So we’re going to remove the ‘authors’ collection and the whole ‘collection’ functionality until it is needed. The blog component can be easily migrated to the home page by getting familiar with Liquid’s Syntax. Liquid makes our posts available as static html pages that we can cycle through a format with HTML.

<ul id="blog-list">
        {% for post in site.posts %}
        <li>
        <h2><a href="{{ post.url }}">{{ post.title }}</a></h2>
        <p class="date">{{ post.date | date: "%m/%d/%Y" }}</p>
        {{ post.excerpt }}
        <p class="read-more"><a href="{{ post.url }}">Read More</a></p>
        </li>
        {% endfor %}
        </ul>
        

I’m also going to set up a base layout that all other layouts are derived from in our _layouts folder. Our index layout inherits from this, as well as our post layout. I set up a favicon package to support a wide-range of devices and put the package in it’s own file in the _include folder. With includes, we can use Liquid to link to them from our layouts. In this case all my includes are for all the pages, and will be placed in the base layout that all are derived from.

<head>
        <meta charset="utf-8" />
        <meta http-equiv="X-UA-Compatible" content="IE=edge" />
        <meta name="viewport" content="width=device-width, initial-scale=1" />
        <link rel="stylesheet" href="/assets/css/styles.css" />
        {% include faviconpackage.html %}
        {% feed_meta %}
        {% seo %}
        </head>
        <body>
        {% include navigation.html %}
        {{ content }}
        <footer>
        <p>Made with ❤️.</p>
        </footer>
        </body>
        

The navigation set up is also in an include. I used Necolas’ reset and started with plain HTML/CSS. I built up my own SCSS in main.scss and imported main.scss and reset.scss into styles.scss, which is where the base layout links to the stylsheet.

nav {
        box-shadow: 0 1px 0 $basecomp;
        ul {
        display: flex;
        flex-flow: row nowrap;
        justify-content: flex-start;
        margin: 0 auto;
        li {
        a {
        position: relative;
        display: block;
        padding: 15px 5px;
        margin: 0 5px auto;
        text-transform: uppercase;
        text-decoration: none;
        font-weight: 900;
        &:hover {
        background-color: transparent;
        }
        &.current {
        color: $highlight;
        box-shadow: 0px 1px 0px $highlight;
        }
        &.not-current {
        color: $inactive;
        &:hover {
        color: $basecomp;
        &:after {
        width: 100%;
        }
        }
        &:after {
        position: absolute;
        bottom: -1px;
        left: 0;
        right: 0;
        margin: auto;
        width: 0%;
        content: '.';
        color: transparent;
        background: $highlight;
        height: 1px;
        }
        }
        }
        }
        }
        }
        

I’m using a navigation bar style that I forked from user shahjehan over on CodePen. I took the animation he was using in one of the nav styles and modified it to match the barebones minimal style I wanted to approach for the site. I also needed something simple that I could style and scale gracefully to smaller viewports. Much of this project turned out to be learning CSS, SCSS and how they work. Jekyll made the site building process much simpler such that I only really needed to focus on that.

Finder Window showing Directory Layout

We’re hosting on Github Pages because a) it’s free, and b) works well with Jekyll. Pros and cons of course, one being that Github Pages has a whitelist on dependencies/plugins such that we are forced to use Jekyll 3.7.4 along with other not quite up-to-date wares (With Jekyll we need to use the bundle exec command as a prefix before any jekyll commands if we’re running a newer Jekyll than the one GitHub currently has whitelisted). A pro on the other hand is that we don’t build! We push our commits over to our remote repo on GitHub and they build our site and serve, meaning we can add _site directory to our .gitignore. We can start this process by using GitHub’s web interface to create a new repo titled <username>.github.io and pushing our updates to the master branch of this new repo.

That’s basically it. There’s a lot of little details that I think I’ll make another post about if necessary, but this is the gist of the current setup. Until next time…

Getting Ready For The Web

2018-12-14T00:00:00+00:00

My experience with web tools fell exponentially after high school, when computer science courses intrigued me with ‘actual’ programming languages like C++ and Java, with a little Python mixed in with discrete math curriculum.

So coming into 2018 my conceptions of web tooling, and programming languages (think what we’re doing with modern JS, Node, React, Bundlers, etc), needed refreshing. All of these relatively new technologies I had previously heard a thing or two about on dev twitter, but I never really looked into any of them or how they worked. I knew I wanted to use a static page generator but I knew I’d have to come to grips with more fundamental tooling first:

Terminal with configurations

Terminal.app is Apple’s terminal emulator for MacOS and is enough for what I needed: Getting Started. I’ve heard great things about other emulators like iTerm2 and Hyper, but I feel having a solid foundation on a default terminal emu is beneficial.

Next up was the bourne again shell, or BASH (As opposed to, say, ZSH, Oh-My-ZSH, etc). Because of licensing issues, MacOS ships with a slightly outdated version of Bash. I used Homebrew to install a more current version of Bash, and then dove into Bash specifics, commands, and configuration files. Pat’s write up on this helped me out a lot so instead of reinventing that wheel, I’ll just link to his excellent write up. He also has some posts on Jekyll and virtualenv that helped me set up this site and get a Flask project started.

I learn Bash, package managers, running scripts and programs via Bash, and soon we’re installing Jekyll through RubyGems and starting a new Jekyll project on the Desktop using jekyll new. Sweet. (I also installed rbenv to instal the latest Ruby build, installed the latest bundler, etc) This first couple of days was spent wrapping my head around fundamental tooling: Terminal emus, shell environments, package managers, dependencies, Git, text editors (I settled on Textmate 2 for now..) Jekyll installation, setup, and Jekyll’s awesome tutorial project. That’s really enough resources to get in the door. We’re interested now. Wouldn’t it be cool to build a static page site and maybe get it hosted somewhere? I hear Github Pages is doing some hosting…

Test Run

2018-12-06T00:00:00+00:00

I’ve finally started to get projects up and running thanks to GitHub and frameworks that make deploying a site or web app easy.

My goal is to keep projects consistent and keep a log of them here. I have a couple posts in the works as to how I got this site up and running in totality. There’s a lot of helpful guides out there but it took me a while to sort through dated, half-relevant material. I believe these guides will be more straightforward. That’s the goal at least ;)

Thanks for sticking around and checking out this site. I know it’s a little skeletal right now, but just give your boy a moment to work.

Matt