how did i build maprys.net 4.0? | maprys.net

maprys.net

how did i build maprys.net 4.0?

(last modified 18 May 2023)

It’s been a crazy enough year of ups and downs that I figured a “new me” in some form or fashion was in order. So why not the website!

Stayed the same

Shiny new things

Layout from JekyllBear

I appreciate the presentation of bearblog.dev. It functions as a basic blog site to bang out your thoughts; no need to care about styling or looks. JekyllBear implements those same qualities in the form of a Jekyll theme. I used its minimal features and aesthetic to give the site appeal despite my awful writing. Bear’s simplicity coupled with the minimal web philosophies of perfectmotherfuckingwebsite.com were my strongest inspiration for building Maprys into the lean presentation you see. I find beauty in its plainness; just HTML and stylesheets with zero JavaScript. Pow pow!

Fontastic

Verdana is used for all standard text with DejaVu Sans as a backup. Overpass is used for headings. Source Code Pro is used for code spans and code blocks.

Colors by Dracula himself

I love the Dracula theme. I use it in as many places as possible: Vim, Sublime Text, Kitty, and Suckless Simple Terminal to name a few. I can’t get enough of its purple, pink, and green! I drew heavily from the Dracula GitHub Pages Jekyll theme to color the site.

Let’s get sassy

I decided that two thousand twenty-two was the year that I would finally increase my knowledge of web style to a level greater than zero. I know what CSS is, and understand its concepts, but had never really dug in. I got tired of typing curly braces. Enter Sass (Syntactically Awesome Style Sheets)! It gives you some nice features like using indentation instead of curly braces, or providing nesting, variables, and modularity over basic CSS. Jekyll supports Sass out of the box, so that was pretty easy. I feel like the whole “cascading” part of style sheets is a little too Big Brain™ for me at times, but I stumble through. I’d be willing to bet my style sheets aren’t as optimized as they could be, but they get the job done. Regardless, it’s still fun to learn new things.

HIGHLIGHT ALL THE CODE

I’d been wanting to implement syntax highlighting for such a long time and never gotten around to it. The once or twice in the past that I’d tried, I did something incorrectly and it didn’t work. I’m now here to say that I finally understand how to do highlighting for code blocks!

When writing out your code blocks, append the language type to the opening tick marks (like we do on GitHub).

```ruby
def foo
  puts "fancy method"
end
```

If all goes well, you get the following:

def foo
  puts "fancy method"
end

Jekyll takes care of parsing the code, then wrapping all the necessary tokens with <span> blocks having various class attributes. The part that I’d always missed is that you also need styling to color all those given spans. Jekyll includes rouge which does the parsing part, but I still needed the styling from somewhere. I discovered that Pygments – a similar highlighting parser, written in Python – has a Dracula stylesheet. It took me a few tries, but I finally figured out how to get it.

from pygments.formatters import HtmlFormatter

# generate the CSS
style = HtmlFormatter(style='dracula').get_style_defs('.highlight')

# write it out to a file
with open('pygments-dracula.css', 'w') as f:
    f.write(style)

This output file is being used verbatim to syntax highlight the code you see above. This is a lie. I’ve since converted it to sass. It could probably be optimized better, but it works for now.

Script. Workflow. Action!

For the initial deployments of this rewrite, I’d continued to use the GitHub’s pre-configured environment using the github-pages rubygem. It worked perfectly fine if I’m honest, but the version of Jekyll used by GitHub Pages has been out of date for a while. It’s at least one major version behind the current. There’s a few niceties that come with Jekyll 4, so I figured why not.

I switched to GitHub Actions deployments. That means I’ve put together my own actions to build and deploy. It gives you a lot more control in customization, including unsupported plugins, or even gating the deploy based on other actions. The only true benefit for me is that it’s cool.

UPDATE: Literally after writing this post and attempting to deploy with GitHub Actions, it all came crashing down in a glorious explosion. In other words, the deployment silently failed and nothing happened. I guess that’s what I get for playing with a feature that’s still in beta. I’ve reverted back to just using the github-pages gem because that’s easy. I’m letting GitHub do the page generation and deployment with their automatic actions. I wasn’t using any particular features of Jekyll 4 anyways. Hope this works!

UPDATE 2: I’ve migrated the website to SourceHut Pages. SourceHut is a much leaner code forge ecosystem compared to GitHub. It touts operating with zero JavaScript, among other things. I have quickly grown to love its snappy nature and emphasis on composability and simplicity rather than offering giant feature sets. Check it out if you’re looking for a more grassroots-feel code forge in which to hang out.

I’m proud of how it’s turned out. It looks pretty. It loads blazingly fast. It looks good on mobile. Success.