Note, this post is only concerned with macOS/Linux and its various flavors, as that’s what I largely use on a day-to-day basis. I’m sure Windows has its own stuff (like systeminfo), but that’s for a different post. Also, I’m only concerned with tools that you access from the command line, as GUIs will most likely have their own menu or button to tell you about your computer, but that can’t be included in a script with other stuff.
My personal favorite command line tool to get information about my Mac (or Linux VM) is neofetch. It’s a rad bash script that creates a cool, screenshot-able display of useful information alongside either a picture of your OS’s logo, or a custom image. Since it runs on bash, it runs on virtually any bash-compatible shell system, which is a lot of potential operating systems.
Before I found neofetch, I used to use archey (which is a maintained fork of the original found here). It’s written in Python, which is another dependency that may not exist on the system you’re checking.
All this being said, not every system has (or can be installed with) the cool tools described above, so I decided a more progressive enhancement flow of attempts worked best.
function about() {
# OS info
if hash neofetch 2>/dev/null; then
neofetch
else
if hash archey 2>/dev/null; then
archey -c "$1"
else
if [ -f /etc/os-release ]; then
cat /etc/os-release
else
if [ -f /proc/version ]; then
cat /proc/version
else
uname -a
fi
fi
fi
fi
...
}
Essentially, start with the best option, and if it does not exist, try the next best option. If uname doesn’t exist then you’re probably not running macOS/Linux, and something is very wrong.
While this if-else chain is useful, it’s not very noteworthy for a post. Thus, over time I’ve slowly expanded this script to contain other things I care to know about a computer I’m using.
# colors
_RED="$(tty -s && tput setaf 1)"
_YELLOW="$(tty -s && tput setaf 3)"
_WHITE="$(tty -s && tput setaf 7)"
_GRAY="$(tty -s && tput setaf 8)"
_BOLD="$(tty -s && tput bold)"
_RESET="$(tty -s && tput sgr0)"
...other functions...
function about() {
# OS info
...
echo "${_BOLD}${_WHITE}--------------------------------${_RESET}"
echo "${_BOLD}${_WHITE}| programming langs |${_RESET}"
echo "${_BOLD}${_WHITE}--------------------------------${_RESET}"
...
echo "${_BOLD}${_WHITE}--------------------------------${_RESET}"
echo "${_BOLD}${_WHITE}| package managers |${_RESET}"
echo "${_BOLD}${_WHITE}--------------------------------${_RESET}"
...
echo "${_BOLD}${_WHITE}--------------------------------${_RESET}"
echo "${_BOLD}${_WHITE}| web servers |${_RESET}"
echo "${_BOLD}${_WHITE}--------------------------------${_RESET}"
...
echo "${_BOLD}${_WHITE}--------------------------------${_RESET}"
echo "${_BOLD}${_WHITE}| webdev tools |${_RESET}"
echo "${_BOLD}${_WHITE}--------------------------------${_RESET}"
...
echo "${_BOLD}${_WHITE}--------------------------------${_RESET}"
echo "${_BOLD}${_WHITE}| database systems |${_RESET}"
echo "${_BOLD}${_WHITE}--------------------------------${_RESET}"
...
}
An example of a programming language would be ruby:
function about() {
...
if hash ruby 2>/dev/null; then
echo "${_BOLD}${_YELLOW}ruby${_RESET}: ${_BOLD}${_WHITE}$(ruby -v | cut -d' ' -f2)${_RESET} $(which ruby)" | _anon
if hash rbenv 2>/dev/null; then
echo "${_BOLD}${_YELLOW}- rbenv${_RESET} ${_BOLD}${_WHITE}$(rbenv -v | cut -d' ' -f2)${_RESET}; using: $(rbenv global)" | _anon
else
echo "${_BOLD}${_GRAY}- rbenv not installed${_RESET}"
fi
else
echo "${_BOLD}${_GRAY}- ruby not installed${_RESET}"
fi
...
}
I check if it exists on the system, and if it does I print out the version (deftly cut up to get the most basic display of it possible, as every program does it differently and in different precision). Everything has proper spacing so that when a bunch of them are printed out they line up nicely.
Here’s an excerpt from the programming languages section to get the gist of all this:
python3: 3.11.7 /usr/local/bin/python3
- pyenv 2.3.35; using: system
ruby: 3.2.2 $HOME/.rbenv/shims/ruby
- rbenv 1.2.0; using: 3.2.2
rust: 1.75.0 /usr/local/bin/rustc
tsc: 5.3.3 /usr/local/bin/tsc
You may have noticed some of the version printing lines ending in _anon. That’s piping the output to a special sub-function I wrote to anonymize any line that may have my home directory explicitly displayed. If I want to share this kind of thing publicly, it’s nice to be able to keep it a little private.
To be honest, I don’t use this script very much, especially on a computer I use every day. I just kind of know what’s on it after a while, so I don’t need the reminder. I can forget, though, so it’s there to save me if I need it. Also, I can just copy this script to a server I’m accessing and run it to get a quick survey of its wares. As with most scripts like this, the most fun is in writing it, not using it.
The full thing is on Github if you wish to use it (or expand it! (or mangle it!)).
]]>Much like other advent calendars, Advent of Code is a daily puzzle challenge that happens each day in December until (and including) the 25th, Christmas itself. Each year has a story of sorts, usually involving helping elves solve problems so that Christmas goes off without a hitch.
Each day is a two-part word problem: you solve the first part and unlock the second part. Part one is often easier and has some connection with part two. Days get harder as the challenge progresses. Regardless of the complexity, each part is solved with a single integer value. Solve each day in a year and you get 50 stars.
A puzzle consists of a word problem, some sample data, and then a question to answer using the actual input data they give you (tied to your login, so it’s unique). The common approach is to parse some textual input data, create some kind of data structure out of it, build an engine of sorts to process that data structure, and spit out an answer. Just following the directions, paying close to attention to what it says (and doesn’t say), and methodically working through all that will usually result in a correct solution. The reality, of course, is wildly variable day-to-day, though. One day you might be sending Santa Claus up and down an elevator, and the next you might be evaluating growing fish populations.
Since it is a challenge, there is a leaderboard so you can see who solved each day’s puzzle first and in what time. However, all of the released challenges are available at any time, regardless of the year in which they first became available, so you can do them at your leisure for completion’s sake.
This is my third year actively competing in the challenge. Since I started in 2021, I’ve gone back to previous years and done a few of their challenges, but the meat of my output is in 2021, 2022, and 2023 (thus far).
I really enjoy AoC (as I will now refer to it), but it definitely challenges me! Despite using computers, and programming for them in some way, over the last 25+ years, AoC is often best solved with a strong background in algorithms and classic computer science chops. Except for a single class in high school in C, and a few quarters of college in Java, my programming knowledge is largely self-taught and centered around web development technologies like HTML, CSS, Javascript, SQL, and the like. My frontend has always been better than my backend, shall we say.
My approach to most challenges is straightforward and naive. What that means is that I don’t really analyze what the problem is asking for in a meta sense (e.g. a grid of numbers is given, and I’m asked to navigate through it, but what popular algorithm is this really modeling?) until after I just start parsing data left-to-right, top-to-down, and realizing that I’m hopelessly muddled in an endless string manipulation exercise with no idea how to get it to output an answer. Another very real result of this approach is an unoptimized algorithm. When you run it, it may get a solution, but only after it runs until the heat death of the universe, which means your algorithm is probably not correct enough.
Beyond the difficulty of any individual day’s puzzle, there are two things that always happen each year to me, compacting the overall frustration. The first thing is that I invariably end up not finishing a challenge on the day it’s released. This will usually occur around the second week of the month. That then makes me not finish the next day, too. And the next. The missed days pile up, and it becomes like a Steam backlog I know I’ll never get to. It hurts my confidence in even attempting later days, and it’s all just bleh. The second thing is related: mental fatigue. Even if I know what I need to do to solve a puzzle, sometimes it’s just tedious to accomplish. I work slowly on these things, and knowing I work slowly on them makes me not want to even try sometimes.
By the end of this year’s challenge (only a few days to go), I’m about mentally taxed to the extreme, and I just let the day’s releases go by like dust in the wind. I read them, but I rarely even attempt them. Sigh. Time to clean up my code, and maybe work on previous year’s puzzles, I guess.
One thing I’m doing differently this year is using a template for each day. Thanks to my friend Matt, I now have a script that generates the subdirectory and files for each day’s challenge so I just have to fill them in. It’s not necessary, but it makes the whole workflow run more smoothly.
As one may find about events, there’s a lot of things going on around the event that can be interesting, too. This year, I’m trying to use the subreddit that is chock full o’ people chatting about the event, giving hints, making memes, and just venting. I’ve found some helpful stuff there, and while it can still feel like “cheating” I’m trying not to care.
Also, I’ve decided to make a web app chronicling my journey. It’s built in Ruby on Rails (I’m doing all the problems this year in Ruby), and it’s a chance to rekindle my interest in both. I messed around with Ruby on Rails in the past, but never really finished a project worth putting up for posterity. I may go back and add my past year’s output at some point, but for now it’s just 2023.
My friend Matt and I are doing a few episodes of our podcast Hacking the Grepson on this year’s Advent of Code. There should be some interesting commentary on each day’s challenges for anyone interested.
While there are some other programming advent calendars out there, AoC is truly unique. The quality of the challenges, the website, the commentary on Reddit…it’s a very cool and important entity. Even if you don’t know how to program, you could ostensibly solve stuff on paper or in, like, Excel, so that’s pretty neat.
As this year’s challenge draws to a close, I’ve gotten more stars than any other year, and that’s progress!
]]>And folks…I just had to try it out.
Ruby is a dynamic programming language, often used with something called Rails to make dynamic websites. My attempts at making a Rails site never quite came to fruition, but I’ve made many scripts to do various things, like producing random text or making a whole game.
That being said, Ruby code largely runs on the command line and doesn’t have a strong GUI game. That is, until you bring Web Assembly (WASM) into the mix.
To be honest, I don’t think I understand it well enough to explain in any detail, other than to say it’s a way to write things in non-web languages (e.g. C/C++, Go, Ruby) so that they can be run on the web (via Javascript, for example). It’s a whole thing, and my little experiment here is just barely touching the edge of what it can do.
Here’s a decent introduction, here’s a related technology called Emscripten, here’s a synth someone built with WASM, and here’s a use case from ebay to wet your whistle for now.
One way to use WASM is to translate Ruby code into something a web browser can understand on the client-side. In the past, you could have some frontend Javascript call a backend Ruby script and then return its output to the frontend to display on a website. With WASM, you can do all of this on the frontend.
Remember this tag?
<script type="text/javascript">
console.log('hello world')
</script>
Standard use case, right? You can also do this:
<script type="text/ruby">
puts "hello world from ruby"
</script>
Of course, if you do just that, it won’t do anything. Add the following library to your <head> tag: <script src="https://cdn.jsdelivr.net/npm/ruby-3_2-wasm-wasi@1.0.1/dist/browser.script.iife.js"></script>, then refresh the page. You should see something like the following:
ruby 3.2.0 (2022-12-25 revision a528908271) [wasm32-wasi] browser.script.iife.js:2871
hello world from ruby browser.script.iife.js:2871
If you require the js module, then you can target web elements just like in Javascript:
<body>
<label for="button">Click this button, then check dev console!</label>
<button id="button">Boop</button>
</body>
<script type="text/ruby">
require "js"
document = JS.global[:document]
button = document.getElementById('button')
button.addEventListener "click" do |e|
puts "you hit the boop!"
end
</script>
My examples don’t truly show the real power of WASM, because you could have easily written the Ruby in actual Javascript, but for something more complex (and pre-written), this could be very helpful.
Also, there’s one fundamental issue when writing client-side Ruby I should note: Ruby is couched in the terminal’s event loop, but to do anything interactive on a web page, like an input parser, you have to re-think how you’re checking for that input (gets vs <input>) and displaying output (puts vs outputElement.value), which definitely takes some re-writing of your original Ruby script. I suppose this is unavoidable as the two paradigms are fundamentally different.
Regardless, I thought this was a cool thing to discover, and I plan to rewrite some of my old scripts for showcasing on a website soon!
]]>git repo, and shared on Github, so I figured I could use Github Actions to do this.
Thanks to some digital friends along the way, I was able to create one!
Github Actions are YAML config files you write to trigger some kind of event to take place when a Github-related action occurs (e.g. push, pull request, etc.). You can even write Github Actions that others can use, and I used one of them to make the Mastodon part much easier to write.
I’ll go into detail on some specifics, but first here’s the full thing:
name: Blog2Masto
on:
push:
paths:
- 'blog/_posts/*.md'
jobs:
post:
if: contains(github.event.head_commit.message, 'new blog post:')
runs-on: ubuntu-latest
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0
- name: Get Commit SHA
id: get_commit_sha
if: ${{ !env.ACT }}
run: |
echo "Running on Github"
echo "sha=${{ github.sha }}" >> $GITHUB_ENV
- name: Identify Added Blog Post
id: identify_added_blog_post
run: |
if [ -z ${{ env.sha }} ]; then
echo "using secret local SHA for 'act' testing"
sha=${{ secrets.TEST_SHA }}
else
sha=${{ env.sha }}
fi
if [ -n "$post_file" ]; then
new_post_file=$(echo "$post_file" | head -n 1)
# Extract information from file's front matter using awk and grep
title=$(awk '/^title:/ {$1=""; sub(/^[ \t]+/, ""); print}' "$new_post_file" | tr -d '"')
date=$(echo "$new_post_file" | grep -oP '\d{4}-\d{2}-\d{2}' | sed 's/-/\//g')
tags=$(awk '/^tags:/ {for (i=2; i<=NF; i++) print "#" $i}' "$new_post_file" | tr -d '[,]' | tr '\n' ' ')
# Construct the URL based on Jekyll site's URL structure
base_url="${{ secrets.BLOG_URL }}"
url=$(echo "$title" | tr '[:upper:]' '[:lower:]' | tr -d '[:punct:]' | sed -E 's/[[:space:]]+/-/g' | sed -E 's/^-//;s/-$//')
post_url="$base_url/$date/$url"
# Add pertinent Github environment variables
echo "post_title=$title" >> $GITHUB_ENV
echo "post_url=$post_url" >> $GITHUB_ENV
echo "post_tags=$tags" >> $GITHUB_ENV
fi
- name: Post to Mastodon
id: post_to_mastodon
if: ${{ env.post_title != '' && env.post_url != '' }}
uses: cbrgm/mastodon-github-action@v1.0.3
with:
message: |
New blog: "${{ env.post_title }}"
${{ env.post_url }}
${{ env.post_tags }} #blog
visibility: "public"
env:
MASTODON_URL: ${{ secrets.MASTODON_URL }}
MASTODON_ACCESS_TOKEN: ${{ secrets.MASTODON_ACCESS_TOKEN }}
I would say that this Github Action I have written is a Github Action I have written, except for the fact that a lot of it was written by ChatGPT3.
My initial stab at writing a Github Action was a lot less complicated than the final one, didn’t use Github’s repo checkout action, and didn’t have a long shell script to create variables. The resulting Mastodon post was just a link to my blog, and a simple “New blog post” title. I figured I could do better than this, but it would take some real effort.
Poring through the docs yielded some half-hearted and nonfunctional results (creating actions are not as simple as I would hope), so I did something I’ve done very little of thus far: I asked ChatGPT.
And it went well!
It’s no hot take at this point to say that ChatGPT is kind of revolutionary, if for nothing else than to be able to ask questions in conversational language and get actual working results! I did have to iterate a few times on certain lines that needed some tweaking or threw an error, but it was actually fun, way more fun than my Googling attempts.
The main issue with writing and testing a Github Action is the…Github Action part. My action is predicated on a git push with a certain commit message, so every time I needed to make a change I had to do a whole thing:
git push to trigger the actionThat workflow is not very efficient, eh?
Thankfully, I found act. This awesome tool allows you to edit your action to your heart’s content, and run it from your local computer, instead of Github’s server. Make change, save file, run command, see results. Just like regular web development!
Downsides to using act vs Github itself were mainly centered around creating some secrets or server variables that don’t automatically exist locally, so it was sort of like writing configuration for unit tests.
It’s not exaggeration to claim that without the previous online help, I would have probably just given up and went back to manually posting on Mastodon like a pleb. But that’s no fun!
Thus, my .github/workflows/post-to-mastodon.yml action was truly born, and now we will break it down.
name: Blog2Masto
on:
push:
paths:
- 'blog/_posts/*.md'
Github Actions are referred to as workflows that are triggered by some kind of event that occurs on a repository. My event is simple: when I do a git push, check if there is a file within the commit that matches a path. That path is where my blog posts live. If so, run a job.
jobs:
post:
if: contains(github.event.head_commit.message, 'new blog post:')
runs-on: ubuntu-latest
Github Actions consist of jobs that consist of steps. I only have one job I need to accomplish: post to my Mastodon instance. I only want the job to run if a git push is adding a new blog post, so I figured the easiest way was to just put that in the commit message and check for it. There may be a way to do this by checking for “only when a Markdown post is added”, but this works for my purpose.
Also, the runs-on value is there because a small VM gets spun up to run your action, which is kind of cool.
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0
- name: Get Commit SHA
id: get_commit_sha
if: ${{ !env.ACT }}
run: |
echo "Running on Github"
echo "sha=${{ github.sha }}" >> $GITHUB_ENV
- name: Identify Added Blog Post
...
- name: Post to Mastodon
...
My one job has four steps:
act on local (i.e. on Github), use the latest SHA run: |
if [ -z ${{ env.sha }} ]; then
echo "using secret local SHA for 'act' testing"
sha=${{ secrets.TEST_SHA }}
else
sha=${{ env.sha }}
fi
The above part is in step 3 and sets a environment variable for our SHA (the long alphanumeric string that identifies your commit) if it hasn’t been set in step 2. This secrets.TEST_SHA is a hand-picked identifier from the git repo’s history that I know has the correct commit message and file added, and is used for local testing. The action uses the SHA later to extract information about the blog post to use in my Mastodon post.
The rest of the identify_added_blog_post step consists mainly of grabbing info from the Markdown file using *nix tools like awk and grep and sed, and was helpfully provided by ChatGPT3. The variables I need are added to the $GITHUB_ENV variable to be used in the second step.
- name: Post to Mastodon
id: post_to_mastodon
if: ${{ env.post_title != '' && env.post_url != '' }}
uses: cbrgm/mastodon-github-action@v1.0.3
with:
message: |
New blog: "${{ env.post_title }}"
${{ env.post_url }}
${{ env.post_tags }} #blog
visibility: "public"
env:
MASTODON_URL: ${{ secrets.MASTODON_URL }}
MASTODON_ACCESS_TOKEN: ${{ secrets.MASTODON_ACCESS_TOKEN }}
Thanks to this Github Action, I could bring those juicy variables to my final step and plug them into the with: message: value. Finally, a worthy payload is sent off to my Mastodon instance, and the people rejoiced.
For how little I actually write blog posts, the time spent on getting a Github Action to work was most likely overkill. However, as a programmer, just trying to see if it can be done is a valid reason for anything.
Now that this blog post is done, committing its finality and pushing it to Github will hopefully, and accurately, create a Mastodon post linking to it. The meta of all this is truly overwhelming.
POSTSCRIPT: Guess what? Running this on Github did not quite work, so more fiddling was necessary: Apparently, the Github checkout action needed some additional configuration (the code above has been updated) to actually see the commit that is crucial for getting the filename for anything else to work. This wasn’t necessary for act to work, so it was confusing for sure. But now it works! Yaaaaaaaay!
In its place, a different idea has sprung anew: a roguelike deckbuilding idea.
The podcast I do with my friend Matt recently explored Slay the Spire, a roguelike deckbuilder available for most gaming platforms that exist. It came out several years ago, but I finally got sucked into it via Apple Arcade. Since then, I’ve put 40-50 hours into dozens and dozens and dozens of runs (still no wins yet -_-).
In the episode, we discuss how we think StS is made, from a gamedev viewpoint. I’m not one of the developers, and neither is Matt, but we both have made simple games before, so we have an educated guess on how StS might be constructed from component parts.
That being said, I’ve never made a game like it. That doesn’t mean I’m not now inspired to do so, though :-D
My preferred game engines tend to be retro consoles, mainly because they have all the parts you need to make simple games with proper gameplay, sprite graphics, and synth sounds. I’ve made a few finished games in PICO-8 and Lowres NX thus far (and at least poked at LÖVE), but there’s one I learned about a year ago or so that I have not actually attempted to use yet: TIC-80.
Much like the other retro consoles, TIC-80 features a command-line interface that can load and run applications, kind of like an old Commodore 64 or something. They are viewed through a low resolution display, and there are apps you can use to construct graphics, sound, and game logic for them. My main reason for using it is just to try something new, but there some significant points in TIC-80’s favor: slightly larger resolution than PICO-8, support for more than just the Lua scripting language, support for more button inputs, and completely open-source (PICO-8 is still very cheap to purchase).
My first goal is to make a working TIC-80 cartridge, i.e. will load, print some text to the screen, and react to button presses. Next, I will create a player sprite, an enemy sprite, and display them. Then I will create an attack card, and display that to the screen, as well. Then I will create some kind of state logic for the enemy so it knows what to do on its turn. If I get that far, I think that’s some significant progress!
My end goal is to get the bare-bones, turn-based event loop of “there is a player, an enemy, some cards, and the ability for the player to use them against the enemy” working, followed by a win state if you beat the enemy, and a fail state if the enemy beats you. Beyond that, it’s a matter of making more enemies, more cards, and some kind of chain of battles that lead somewhere.
If I’m still interested in the game after all of that, then it would behoove me to make better graphics for everything, a title screen, and some sound effects and background music. There’s no way it’ll be anywhere near as cool as Slay the Spire, but RogueyooDeck could still be a cool thing to add to my portfolio.
Learning a new system and all of its quirks is always fun, so even if this doesn’t go anywhere, I can still say I learned TIC-80. Who knows, maybe this will blossom into something bigger and I’ll try Godot someday!
]]>My daughter started ice skating at the beginning of 2023. She was a bit shaky at first, like we all were, but she has progressed impressively and quickly. She’s taken many public and private lessons, practiced for many hours, and is even on a synchronized skating team!
All this is to say that ice skating was not really in my mind grapes pre-2023, but is now in full force. As someone who dabbles in game development from time to time, the idea to make an ice skating game was not that farfetched.
There are a lot of ways to make a game these days. My preference is to use a retro console app like PICO-8 or TIC-80, mainly because they have all the tools in them to make the code, graphics, and sound. The integrated package makes all the parts talk to each other easily, and is just the right level of quality for my “programmer art” mindset.
Unfortunately, there is no iOS version of either, so if I want to work on the game I have to be at a computer. I’m not always at a computer, and it’s super useful to use my iPhone to do game development as well, if possible.
Thus, I went back to LowRes NX, a retro console app I used for a bit earlier in the year. It works on macOS, iOS, and Windows. I can edit the code, graphics, and sound on my phone, but also on my Mac, with the helpful niceties that a desk (large monitor, full keyboard/mouse) and VS Code provides (syntax highlighting, code folding, and auto-indentation via this plugin, etc.).
One unfortunate result of using LowRes NX is that it uses the BASIC programming language (but without line numbers, thankfully). Obviously, one can make a game with it, but BASIC was originally created in the 60s and does not do OOP, nor does it feature the modern creature features programmers have come to know and love since then (like, I dunno, functions that return a value). It’s best to set your expectations to “someone making a game in 1980 for the Atari” or something.
Regardless, for the kind of simple stuff I’m making, BASIC is fine, even if it means I have to kind of de-program my brain from what I normally work in to make headway. The low-resolution graphics and audio are fine, too, as I love chiptune and retro games.
The initial seed of an idea was to create an ice rink with some walls, and a skater that you control. Move the skater around the rink and then…uh, I’ll figure that out later. This involved making a bunch of sprites for the four cardinal directions, as well as alternate versions for when you’re moving. I also had to add a simple acceleration/deceleration model so it actually looks like the avatar is skating and not simply moving.
The most significant thing I have figured out so far is creating a little Tony Hawk-esque “hold button to crouch and then release to jump” move.
GLOBAL B_PRESSED
B_PRESSED=0
IF BUTTON TAP(0,1) THEN
B_PRESSED=1
END IF
IF BUTTON(0,1) AND B_PRESSED=1 THEN
'CHANGE SPRITE, ETC.
ELSE
IF B_PRESSED=1 THEN
B_PRESSED=0
CALL JUMP
END IF
END IF
The way I handle jumping is hacky (it uses WAIT) and needs to be updated to an upward velocity thing, but I’ll get to that next.
I want this game to involve doing tricks to get a high score, so I’m going to continue with the THPS idea, and figure out how best to map all the moves I want to be able to perform onto two buttons and a D-pad. I think trying to figure out the notion of “combos” is going to be rough.
Since I’m a musician, I gotta think of a cool soundtrack and some sound effects, too, but that’s the real fun part.
Stay slick!
]]>THAT ENDS NOW!
Ahem.
Since I’ve been a on self-hosted kick, slowly replacing external services with internal services that I set up and administer, I decided I would finally get some kind of analytics going on my web places.
There are many options for this kind of thing nowadays, but I remembered an old friend from my past work experiences, and figured I could look them up again to see how they’re doing.
Enter AWStats.
AWStats, which stands for Advanced Web StatisticS, is pretty simple: you give it a configuration file that points to a server log file, it parses a HUMONGOUS Perl script (this software was first released over 20 years ago, but hasn’t changed much in its basic structure), and spits out a web page (using <frameset>!) that gives you a bunch of stats about your website and its visitors. It’s not exactly pretty, and it isn’t what you’d expect in a modern web application, but it works, more or less.
Of course, as a web developer, it’s near-impossible for me to not want to tweak it. Just a little bit.
After looking at the AWStats interface for about 5 seconds, I realized I wanted two (2) things:
<select> to choose from my multiple domains, as an easy switch, instead of having multiple bookmarks or manually changing the part after config= in the URLNow, most web applications these days have templates you can customize, as they’ve been built with this kind of hackery in mind. AWStats, though? NOPE.
First things first, how is the web page that the GINORMOUS Perl script spits out structured? It still uses that darling of the early 2000s, <frameset>. There’s one of them, with two <frame> elements inside (I’m using pseudocode below, so it’s not 100% accurate, but you get the idea):
<html lang="en">
<head>
...
</head>
<frameset cols="240, *">
<frame name="left" src="nav">
<frame name="right" src="stats">
</frameset>
</html>
It’s easy to see that this is how the rendered website looks, but how is the HTML created? Buried inside somewhere, an intrepid coder finds the following:
...
print "<frameset cols=\"$FRAMEWIDTH,*\">\n";
print "<frame name=\"mainleft\" src=\""
. XMLEncode("$AWScript${NewLinkParams}framename=mainleft")
. "\" frameborder=\"0\" />\n";
print "<frame name=\"mainright\" src=\""
. XMLEncode("$AWScript${NewLinkParams}framename=mainright")
. "\" scrolling=\"yes\" frameborder=\"0\" />\n";
print "<noframes><body>";
...
print "</body></noframes>\n";
print "</frameset>\n";
print "</frameset>\n";
...
It took me some time on MDN to remember how to use HTML frames again, as I hadn’t used them in decades, but I finally came up with this little hack:
...
# mikehack start
print "<frameset rows=\"50,*\">\n";
print "<frame name=\"domainselector\" src=\""
. XMLEncode("./domainselector.html?framename=maintop")
. "\" frameborder=\"0\" />\n";
# mikehack end
print "<frameset cols=\"$FRAMEWIDTH,*\">\n";
print "<frame name=\"mainleft\" src=\""
. XMLEncode("$AWScript${NewLinkParams}framename=mainleft")
. "\" frameborder=\"0\" />\n";
print "<frame name=\"mainright\" src=\""
. XMLEncode("$AWScript${NewLinkParams}framename=mainright")
. "\" scrolling=\"yes\" frameborder=\"0\" />\n";
print "<noframes><body>";
...
print "</body></noframes>\n";
print "</frameset>\n";
print "</frameset>\n";
...
This essentially puts the whole page into another <frameset> so I can insert a new <frame> that pulls in another HTML file with a domain selector chunk:
<form id="domain-selector">
<select id="domain">
<option value="">- Choose Domain -</option>
<option value="michaelchadwick.info">michaelchadwick.info</option>
<!-- add other <option>s here for more domains -->
</select>
<button type="button" onclick="changeDomain()">Change Domain</button>
</form>
<script type="text/javascript">
function changeDomain(e) {
const dropdown = document.querySelector('#domain-selector select')
const domain = dropdown.value
if (domain != '') {
// top.location to reload whole frameset
// self.location and document.location did not work
top.location.href = `/cgi-bin/awstats.pl?config=${domain}`
}
}
window.onload = function loadDomainSelector() {
const searchParams = new URLSearchParams(new URL(top.location.href).search)
const dropdown = document.getElementById('domain')
const domain = searchParams.get('config')
dropdown.value = domain
}
</script>
This bit of HTML and JS makes a <select> with all my domains, and when the button is clicked the site reloads with the new config value, giving me sweet, luscious statistics.
Inserting a favicon into AWStats was a lot easier, but still necesitated trawling through the code until I found where the </head> tag was inserted. I put a simple <link rel="icon" href="/path/to/favicon.ico"> right before it, and now I have a custom image on the pinned tab for AWStats for easy scanning amongst other pinned tabs that are not AWStats.
The takeaway from all this is thus: AWStats is ancient by Internet standards, and not at all how I, or probably most people, would write an app like this anymore. That being said, it’s kind of impressive how much this software has not changed, and yet is still useful. Clean, beautiful code is certainly an aim when developing, but in the end, the end user either concludes it works or not, so even something like a 20K line script can still do the trick.
]]>Media embeds work pretty seamlessly in a Mastodon post, but I’ve never tried to embed a Mastodon post somewhere else.
Let’s try it!
So, I made a track recently by doing a Live Loops session in Garageband iOS on my phone. I was inspired by the Neon Metropolis sound pack, which is full of fun chiptune beats, rhythms, arps, and leads. While on a recent vacation, I loaded up the sound pack, started a session, and then just went to town for a few minutes, starting and stopping loops, and doing DJ-style effects here and there.
Once I was happy with what I’d done, I imported the Garageband iOS file into Logic Pro X onto a Mac to clean up my mistakes and do some more customization. Then I exported it to an MP3, put it up on my VPS, and made a post on Mastodon about it. Hopefully, you should see that below.
If you don’t see the Mastodon post above, with a further-embedded media player, then just go to the post directly: direct link to Mastodon post
If that link doesn’t work, then try this link: direct link to Magnificent Megalopolis.
If that link doesn’t work, then just, uh, imagine a cool song in your head and call it a day.
]]>Moving all of that cruft from one system to another is non-trivial, and I left a lot of old stuff in a format that couldn’t be used…until now.
Note: the post header image was created using NightCafe, but the words are my own (I swear!).
Thankfully, both LiveJournal and Wordpress possess ways to export content, and so I did. Unfortunately, Wordpress exports not only the final version of a post, but also “autosave” and “revision” versions, so I had to spend some time wading through them all to get the canonical version of each post. There were 4000+ files, so it took a bit.
Jekyll uses a simple filename-based post format tucked into a _posts directory, so a blog post written in today would be something like _posts/2023-08-04-blogging-all-the-blogs.md (.html is also OK). My exported blog posts did not have that filename format, so through the combination of a couple shell scripts and Name Mangler I was able to grab a date meta line from the file itself and rename each file accordingly. I also needed to add a specific tag to some posts so I could hide them publicly (not everything I wrote in the past is germane to this blog, but I still want to be able to read them!).
Besides re-learning how to do string manipulation in bash and how to actually use sed (I’ve basically almost never used it before), the main hiccup was just dealing with a large number of files (which I segmented into folders based on the first letter in the file) and trial-and-error with the logic in my shell scripts.
However, one Jekyll-related thing that came up (that I’ve solved in the past but forgot how to do until now) was this warning when serving up my site:
Conflict: The following destination is shared by multiple files
The written file may end up with unexpected contents.
/path/to/jekyll/_site/blog/tags/[tag-name]/index.html
- blog/tags/[tag-name]/index.html
- blog/tags/[tag-name]/index.html
Most of the fixes I found on the web did not address it for me (e.g. duplicate page.html and page.md), but once I searched for the offending tag name it was obvious: tag name vs. tag-name was resulting in the same page, which is not ideal.
The fix? Make sure you only use one format or the other. I just renamed any tags that had spaces to use hyphens instead and voilà.
Now I have a way to read everything I’ve ever blogged in the past 20 years in one place, and I control all of the content and how it’s displayed. This is the dream for all of us who, while still living in a corporate-controlled web where all your content gets locked up in a few companies’ coffers, don’t, like, actually want that to be true.
I’m sure many don’t care about that, and will continue to post their stuff on the Facebooks, Instagrams, Twitters/Xs, Threads, and their ilk, and so be it. Maybe I’m too precious with my words and their archival, but I figure I can have it this way and still link to my blog on those spaces if I want, so it’s a win-win.
]]>Second of all, I have a big enough ego to attempt my own Heardle, but using only my music. And so, I did.
Using the same codebase as my Bogdle game, which is also itself a play on the popular Wordle game, I was able to get a PoC of Nebyoodle done fairly quickly.
As with all new web applications, there’s usually at least one or two challenges that are new to me.
The logical data source for all my music is NebyooMusic, a Drupal-based web app that has all the music I’ve ever done, organized, and filled with metadata.
I enabled the core module JSON:API, and some of its submodules, and began configuring it to work with views of tracks. Then I could query an API endpoint and get a, for example, random track.
For a random-track-guessing web game, that’s pretty useful!
This is something I’ve dealt with plenty of times before, so I’m not neophyte to making audio occur on a website, but the Web Audio API is still something that is non-trivial to deal with beyond the following:
The main issue was handling skips vs incorrect guesses vs correct guesses and how they affect the UI and the overall game status. When it’s just text or images, it’s one thing, but when it’s audio, it’s a bit different.
I learn and organize as I go, which means a lot of backtracking on code and redoing things I’ve already done to make them more sense. I also jump between projects a fair amount, usually due to being stuck or burnt out, and any progress I make in one project often influences others. I should really use a framework or something (or make my own…?), but instead I stubbornly keep making my own each time, and consistency across projects takes a hit.
That being said, the meat of this project was done in Bogdle, so it didn’t take nearly as long to get done. Now I have a fun way to go through my catalog, which is nearly 600(!) tracks large. No one else would have the domain knowledge to play this game, and yet it was still fun to build, which is my bar of success.
]]>