Dan's Bloviating

Starting to play with the UI

2024-12-11T00:00:00Z

In the first iteration of this reincarnation of my site, I started with a quick-n-dirty Bootstrap theme to get the ball rolling...seemed reasonable, right? A quick way to get started?

Yeah, well...it took roughly 2 hours before I began to realize that implementing anything in Bootstrap before I had at least a passing familiarity with CSS was a bad idea. When I found myself sprinkling the pages with <hr>s and  s just to mess with layout, that was a danger sign. Young(er) Dan may well have stubbornly forged ahead, but old(er) wise(r) Dan chose another path.

So, I pulled out all of the CSS and Bootstrap junk I'd dropped in place, and started instead hand-crafting the CSS one step at a time.

Preliminary cleanup

Eleventy blocks

One of the first things I realized, even before getting to the styling, is that I wanted to be able to override the page title format. I'm happy with the default of Dan Blumenfeld - {page title} in most cases, but, as an example, Dan Blumenfeld - Blog - {post title} might be better for blog posts. This was pleasantly easy to accomplish.

In my base page layout (base.njk), I defined the title as <title>{% block title %}Dan Blumenfeld - {{ title }}{% endblock %}</title>, so that whatever title was defined in the front matter of the page being displayed would be used.
I created a child layout (blog.njk), with the following content:
{% extends "layouts/base.njk" %} {% block title %}Dan Blumenfeld - Blog - {{ title }}{% endblock %}
I specified the child layout in the front matter of my post as so: layout: layouts/blog.njk

And just like magic, it worked. :-)

File format choices

I had started with a mix of Markdown and HTML, as I hadn't yet come across a reason to prefer one over the other. Until I realized that Markdown was going to be converted to HTML anyway, so I'd have more control over the eventual output if I just went to HTML in the first place.

This triggered a bit of angst because I'd already created quite a few Markdown files which needed to be converted; but, taking steps now to make things more consistent down the road seemed wise.

So, to sum up: the gerneral rule is that all layout files are Nunjucks(.njk) and all content files are HTML.

Semantic markup

Apparently, in this newfangled world of HTML5, there are more options than just the <p> tag for grouping content. Who knew?!?

So, I went through and made a feeble stab at applying the correct tags.

Styling

Resources used

My first question: variables, please?

After typing the same color and size variables more than twice, I had to ask: how can I define variables or otherwise keep my CSS as DRY as possible?

It turns out that I can use CSS Custom Properties. This is a means by which properties can be defined using two dashes (--), so that they operate in the same cascading manner as other CSS entities; or they can be defined using the @property at-rule. In both cases, they can then be referenced using an inline var(--custompropname); syntax in the following CSS.

Two-dash declaration

Has to be written inside a ruleset. For global access, adding them to the root selector is an easy approach, but they can be declared inside any ruleset.

            :root {
                --secondary-color: #c0ffee;
              }

@property at-rule definition

More expressive, in theory. I've not really used them yet.

            @property --secondary-color {
                syntax: "";
                inherits: false;
                initial-value: #c0ffee;
              }

Referencing the custom properties

            main {
                background-color: var(--secondary-color);
              }

Configuring my daily driver using Ansible

2024-12-06T00:00:00Z

Historically, I've practiced a form of infrastructure management I like to call "memory-based chaos". However, as I slide through middle age with increasing lack of cognitive grace, it becomes more apparent that I should let my tools work for me. Enter shell scripting and Ansible

The goal

In my ideal world, I'd like to use the following ever-so-elaborate process to set up my daily driver:

Install a clean copy of Ubuntu with minimal tools (including Git)
Pull my repo
Execute local-install.sh
Answer a couple of questions, then wait

Requirements

It should be idempotent. I don't want to cause problems by re-running the process.
It should be user friendly. The process should save my responses locally, and ask me if I wish to re-use them. (With obvious exceptions for sensitive data like passwords and access tokens, of course.)
It should be designed to run locally, but with an eye towards running it against other hosts too. This is more for my learning than any practical purpose, as I find it unlikely that I'll want to set up my workstation remotely.
Each component should be able to be run independently, with minimal upstream dependencies. This keeps things easier to use on an ad-hoc basis, as well as easier to debug.

The initial manifest

Ansible (Used to drive the rest of the system configuration)
Git configuration. Defines local git settings, generates SSH key, pushes said key to Github
System hardening, details TBD
Tor Browser
1Password
1Password CLI
Sublime Text
Sublime Merge
Docker and docker-compose
DevToys
Visual Studio Code
Terraform

How's it going so far?

Quite well, actually.

I've got a seemingly decent model for the individual playbooks and associated scripts, with at least a modicum of sanity checking and convenience features.

The Ansible, git config, Tor Browser, and VS Code scripts and playbooks are implemented and seem to work nicely.

Lessons Learned

- My UniFi network needed some help to unblock Tor traffic. Apparently. "dark web" is synonymous with "concern for privacy" in the eyes of Ubiquiti's UX designers.

Thriller!

2024-12-03T00:00:00Z

*Vectorportal, CC BY 3.0, via Wikimedia Commons*

This, my personal website, has been under the weather for quite some time. I had set it up using Namecheap-hosted Wordpress many years ago, then let it lie fallow ever since. At some point in the past year or so, the Wordpress instance stopped working, and I didn't even realize it until this month.

So, it's time to bring the site back to life. This time, I'm broadening my horizons by avoiding any dynamic server-based solutions, and am instead going with static content and old-school hand-crafted HTML/CSS/JS.

Because I'm not a *complete* masochist, I'm using Eleventy ~~and Bootstrap~~[Edited to add] A week later, I decided to skip Bootstrap and learn some CSS basics instead..

My front-end implementation and design skills are lacking, to say the least, but at least this will force me to learn something.