2024 was a tumultuous year. Shortly after my last post (still technically 2023) I was part of my second RIF-style layoff, and hit the job market once again. I found my way into a contract job working primarily making a new project scaffolder and CI/CD pipeline via AWS CDK, but the lack of provided insurance, low likelihood for conversion to FTE, and the lower pay range for that company soon had me scouring the market for better options. I started digging around and made the fool's choice to jump into an AI-based startup.

Now I'm not going to name and shame, but that place did not understand the concept of a proper work/life balance. I could tell fairly early on that they were more used to burning out their internal devops people rather than allow them time to prepare useful solutions (also why I think the person before me doing the same work also left? mock shocked face goes here).

I managed to last there for 4-5 months; the same day that I got the notice that my current company was going to hire me, my manager was not asking me, but telling me about the upcoming weekend's worth of work that they were handing me that day (a Tuesday, so not a lot of notice) in order to help replace a core system library within their monorepo. Imagine jacking up the Great Pyramids at Giza, only to replace the bottom layer, and hope that when you drop it back down, it doesn't generate any problems. Fortunately, after informing said manager about the nascent change in employment, I suddenly didn't need to do the weekend work, and they offboarded me the day after, which IMO was fairly abrupt, but I wasn't too sad about having the extra days to … not deal with their shit. :D

I've been with $CUR_JOB since October, working on an internal portal for tracking the software created by the company. It's all based in Backstage, which is something I grew familiar with at Startup #2. The team is solid, if not a little on the less-experienced side, but that gives me the ability to serve as a mentor in places (and further extol the virtues encoded in The Pragmatic Programmer, which anyone in my past work history would tell you I quote just a little too much).

I've enjoyed the new styles, so that is sticking around. Page loads are super snappy, it is (or at least seems to be?) easy to follow, and it doesn't involve React. :D

I've added a Uses page to allow keeping an up-to-date list of the things that I make use of on a daily basis. I try to keep this up to date, and it has a timestamp of the last update (so technically I have updated since two years back, just not longform…). I'm hoping that as I surface more of the things that I use frequently, it prompts me to use this space more frequently, too.

The social page also has had updates, as I've moved my Fediverse home over to the awesome omg.lol community. It's a group of people who seem to enjoy the simpler times of the Internet, including IRC, a web directory / link board, and simple approaches to personal content (eg: images). I still enjoy doing self-hosted things, but I may look into ways to more tightly weave those systems and this space together. If nothing else, it's leading me to think about how I use my own internet space, and spurring me on to do more investment in my own domains (like this one!).

Most recently, I've been migrating all of my code that I care about (sadly far less than the total repo count) away from github/gitlab, and into codeberg. I don't need my data feeding AI systems or providing extra traffic to platforms with questionable moral steering (the GitLab exec professing his support of DOGE at the bottom of this article was a pretty quick call for me to exit).

I'm currently getting ready to do an internal networking upgrade to boost to 2.5gbps traffic throughout (including at the uplink). Once that's complete, I'll be re-re-re-revamping my homelab (which I'm going to try to do as a public exercise). Hoping that means more content here. :D

Since the last post in 2021 (which I'm super proud of, it was the best-performing post I've had), I've helped raise a kid to 2 years old (he was 1 month old when that last post landed), changed jobs (went through a layoff, and found new employment elsewhere); my primary social media platform was purchased by a person with more money and ego than sense, and has turned it into a cesspool of fascist propaganda and hate speech; and the world has continued dealing with the continuing COVID pandemic.

Oh, right.

Well, the very obvious one is there's a new style and theme attached. Gone is the smooth lines and colorful graphics, and now we have a simple text-forward site. This is by choice. I've stumbled down a rabbit hole of blog posts containing concerns that "web pages are too large", and some satirical and expletive-laden examples to the contrary.

The overall sense that I got from the above is that, the less amount of unnecessary data being requested by your users, the better. So, the simplification of this site tracks with that goal. We have a simple font selection set (which will render mostly the same); the colors are inspired by the Catppuccin color theme (which I'm using all over my tools, it's seriously great), and I've tried to limit image usage to only the necessary places.

Being a parent sucks a lot of the free time away from tinkering, so likely not a ton. That said, I've admired what Ben Werdmuller does, and I've been a fan of the Indieweb movement in general, so I'll likely do some work to enable more of this site to use Indieweb-related functionality. I think I've taken a bit of a step back with this recent change, and so I'll do some cleanup in the near term to get be back to some level of microformats usage (right now, I'm just wanting to get the style change out the door, and I'll iterate on that in later days).

And hey, Advent of Code comes back here in December, so I'll maybe have some things to write there. Gonna have a think on which language to use…

Coming from a scripting language like Ruby, basic string input and output is fairly straightforward:

puts "How old are you?"
age = gets.strip
puts "You've said #{age} years, which is #{(age.to_i*365.25).to_i} days."

In Rust, this becomes significantly more involved:

#![feature(old_io)]
use std::old_io::stdin;
use std::str::FromStr;

fn main() {
    println!("How old are you?");
    let mut input = match stdin().read_line() {
        Ok(v) => v,
        Err(_) => panic!("Couldn't get STDIN!")
    };
    input = input.trim()
    let age_days:usize = match FromStr::from_str(input.trim()) {
        Ok(v) => (v * 365.25) as usize,
        Err(_) => panic!("Couldn't convert to usize!")
    };

    println!("You've said {} years, which is {} days", input.trim(), age_days)
}

In Rust, the placement of the variable in stack or heap memory is important to the Rust compiler's understanding of

• how long the variable lives (it's "lifetime"), and
• who owns the memory that the variable uses (the "ownership").

There are plenty of posts available which will explain these terms to enough detail; for practical purposes, we have to manage two separate types of strings. Each type gets used in subtly different ways, but will cause you some problems when building out programs.

The more commonly used string type is &str, also known as the "string slice". This string is allocated to the stack, and is accessed through a reference to the stored string, much like a C-like character array.

The second string type, String, is used when you want to maintain ownership over the string value. String s are allocated on the heap, and are "growable" - that is, they can be added to as mutable variables.

Be careful to understand what type of string you'll be dealing with; functions generally operate on the more general &str type, so you may need to convert back and forth between the two types with String::as_slice or "".to_string().

One of the larges differences between the two languages is the presence/absence of a Garbage Collector. In Ruby (and other GC'd languages), the GC is used to clean up expired references from the runtime, to periodically free unused memory from the application being run.

In Rust, there is no GC. Instead, the compiler has a notion of "ownership," as we discussed earlier. Check out the following snippet:

let x = Box::new(5);
{
    let y = x;
}

println!("x == {}", x);

In line 1, we create a new heap-allocated variable, and store 5 into it. Because it's on the heap, the value of x is really a pointer to the memory location of the "Box" - the owned variable. Now, in line 3, we create the variable y, and store x's value into it; this is considered by the Rust compiler to be a "move" - both pointers point to the data, but rust treats y as the new owner of the Box, as x has transferred ownership. Because of this, line 6 fails to compile correctly, as the value owner has been moved:

src/main.rs:7:25: 7:26 error: use of moved value: `x`
src/main.rs:7     println!("x == {}", x);
                                      ^
note: in expansion of format_args!
<std macros>:2:43: 2:76 note: expansion site
<std macros>:1:1: 2:78 note: in expansion of println!
src/main.rs:7:5: 7:28 note: expansion site
src/main.rs:4:13: 4:14 note: `x` moved here because it has type `Box<i32>`, which is moved by default
src/main.rs:4         let y = x;
                          ^
src/main.rs:4:14: 4:14 help: use `ref` to override
error: aborting due to previous error

Because of this, you need to keep track of what values you're using where, who's got the ownership of the value, and how long the value is alive.

This will be something that comes with more use and more exposure, but right now, outside of the Rust standard documentation, there isn't much for explanations on how/where to do things is, in comparison to the Ruby ecosystem on the Internet. As I get more into it, I'm hoping to have more posts like this, where I can go into greater detail on how to do things in a rust-like way.

Moving into Systems programming is weird for me; I know there's some things that I'm missing, and I have a lot more power to play around with the system at a lower level, but I struggle with finding projects to work on. Either I choose something substantially big, or it ends up being examples on /r/dailyprogrammer. I'd like to put together something in the middle soon.

One of the more controversial decisions I've made for myself in the past few years was to take myself off of the Facebook platform. While this makes it far harder for friends and family to scout me out on the Internet as a whole, I had reservations about using their platform, and ultimately deactivated my account in early 2011. The reason for this mostly stems out of two main points:

• The first takes us way back to April of 2010. Back then, Facebook

introduced a change to their platform; as a result, all users' permissions defaulted to be public by default. This caused a fair amount of backlash at the time, and ultimately caused the FTC to sanction Facebook as a result of this and earlier privacy concerns.

• The second is due to their need to create a wide break between content on the inside of

their platform and the rest of the Internet (the "walled garden", as is often used). As a result of this separation, users who either are not on Facebook at all, or may be logged out for the time being, lose the ability to access media and content stored there.

The Internet was founded with the principle of enabling people to share ideas - the existence of some of the largest Internet companies today started out by enabling people to find and share information. By limiting access to resources, data and content to only a select subset of individuals, you restrict the ability for people to grow from those ideas. I'm not saying that there can't be some access limits (although, if you want to keep something private, maybe putting it on a global network isn't the best idea - better argument for a different day, though); content creators want to retain use and control of their content. However, at the scale in which Facebook exists, the limitations of access to those resources is stifling to those who could use it.

Facebook, as well as Twitter, Instagram, Google, etc. all share something in common: they have one point of access. When that access is cut off or limited (think of Github outages, which have been dubbed "developer holidays" based on their impact to the tech community), it can be disruptive to a large amount of people. In addition, by selecting one route to access for these services, the companies that run them can start to dictate consumption:

• Twitter heavily limits access for third-party phone apps into the platform
• Snapchat doesn't provide a Windows Phone app, but requested Microsoft pull third-party apps providing that functionality from their app store
• the implementation, backlash and subsequent removal of YouTube's "Real Name" policy.

This centralization shows that, as we allow sole consumption from these groups, we risk reducing access to them; as a way of providing robustness to the Internet, there should be more than these single players in their respective spaces, so that we can operate in the event something goes down.

This spring, Twitter made the (unfortunate) decision to update some of their UI - most notably, they removed usernames from replies in messages. People didn't enjoy this (as noted above). Whenever there's a big event like this (Reddit has had them a number of time in their past, too), a subset of users start to look for competing products. Around this time, people discovered the Mastodon project, which provides a Twitter-like interaction style, but with a couple of major shake-ups:

• You had 500 characters (If you've tried it after years on Twitter - it's SO MUCH SPACE).
• There's a "Content Warning" function, which hides things that may be offensive or may cause discomfort.

The major difference (for the sake of our discussion) was that, instead of being one service, it is a network of separate running copies of the server software, run independently (called mastodon "instances"). This brings in some tradeoffs: for example, since you can organize communities on separate instances, those communities can start to build on specific topics. However, this doesn't mean you're limited to just the people on your instance. Through a process called "Federation", users on one instance can follow users from another; the server then keeps that user and their instance up to date for the users that follow them on their home instance.

NB: The author of the above article tried out Mastodon around this time too - you should see her take on it.

A big driver for me after being introduced to Mastodon is the power to do things your way. I run my own personal instance (at https://social.ballpointcarrot.net); this gives me the ability to personalize and customize my instance to how I need it to operate. However, due to the communication protocol (GNU Social) underlying it, all instances have the capability to communicate with each other.

Note from the future: as of the time of this blog migration (2026-01-23), the above instance is no longer running. I've moved most of my personal stuff onto the omg.lol platform.

I would love to take this concept of widespread, federated or decentralized services, which define a common protocol for communication, and see them grow on the Internet. Moreover, since these give you the ability to host them for personal or individual use, I would love to see the rise of the "DIY Web" - media, content and resources shared the way you want them to be. I see great benefits to having these platforms: Technology literacy, Robustness of content, Better software as a result of the needs around these platforms, all while retaining the social aspect of interacting and showing our voices.

Email is exactly this. Not everyone has (or even wants, in cases) a Gmail account. There is no absolute requirement that your email go to Yahoo/Hotmail/Gmail/etc. - Running an email server is something you can do for your self, your household, your extended family. The requirements are straightforward:

• Set up the software to receive the email.
• Set up the accounts to have the mail delivered to.
• Tell everyone how to get their email (configure the clients).

The problem here is, those steps are hard. Most people aren't taught how installing packages on their desktop goes - getting them to install and configure a mail server would be insane.

With the current technology teaching path, that is.

Think about a curriculum that uses setting up a project like this as its goal. In it, this gives you the ability to talk about many concepts about computing that would largely go untouched. Networking (how do things go in and out to the Internet), configuration of software (not just installing it), understanding how the messages are created and handed off from place to place - there's a lot of detailed information that can be learned, just by trying to solve this as an exercise. Once these people who have gone though this new training, they're going to be better set for dealing with technology out in their daily lives (and hopefully with less of the "oh I'm not good with computers" hand-waving affectation).

At the same time, this is a place where those in the technology space can help. Part of the difficulty in this process is that the resources that are being dealt with are built in a way that "technology people" know how to control. If we can take some time and energy to make explaining the concepts here easier, and to simplify the process of building out these types of applications, then we can make it easier to extend these types of federated networks out to the world writ large. This is a perfect place for something like Docker - a premade container of a suite of coordinated services will help to allow easy installation and execution of systems that would otherwise take hours to properly set up and activate - hours that some at the target end don't have to spend in the review of those setup instructions. Once these improvements are in place, we can then turn to making the communications protocols that these systems will use more stable, more robust, and provide new features and extensions to them.

I'm excited to see where federated applications like this can take us. The more these can be used, the better off we are in terms of open platform access, robustness (as the data propagates out to other nodes), and the benefits brought in from the learning landscape, as well as benefits to the software itself.

The first problem is summarized as follows: you're an Elf travelling back in time to fix anomalies in history, in order to "save Christmas". However, in order to get the time travel device working correctly, it first needs calibrated.

Given a series of "frequency changes", like +1 -2 +3 -1, the following changes would occur:

• Current frequency 0, change of +1; resulting frequency 1.
• Current frequency 1, change of -2; resulting frequency -1.
• Current frequency -1, change of +3; resulting frequency 2.
• Current frequency 2, change of +1; resulting frequency 3.

This provies a resulting frequency of 3.

With those rules in place, the Advent of Code site has you log in (thanks, Login with Github) and get a link for sample input. The input file was larger than I expected, but the rules simple enough to come up with this small Clojure snippet:

(defn calibrate [input-file]
  (let [raw-input (slurp input-file)
        freqs (map #(Integer. %) (clojure.string/split-lines raw-input))]
    (reduce + freqs)))

The above reads the file into a string (using slurp), then converts each individual number (separated with a newline character) into a Java Integer. Finally, everything is summed up via reduce to get the full set of adjustments for a final frequency.

Within your input, you now need to keep track of the active value, and look for the first time you encounter the same value twice. Additionally, this means that your list can loop; for example, take the input +3, +3, +4, -2, -4. As you run through this the first time, you generate intermediate values of 3, 6, 10, 8 4, and there are no matches within that set. So, you take the last offset of 4, and start the original list over again, returning 7, 10, .... When you've reached 10 again, you have found your "twice match", and return that value. Now, using the same test input, we get to find the first value we hit twice.

Clojure gets to harness the power of lazy infinite sequences here. Using the clojure cycle function, the list of frequencies gets to be repeated indefinitely. Obviously, we can't eager load a list of infinite values - there's not enough memory space to do that; what we can do, however, is let that list populate as needed, only providing the next number until we need it.

I built a function that generates a list of the intermediate points, and loops to find a solution:

(defn frequency-adjustments [freqs]
  (reductions + (cycle freqs)))

(defn calibrate [freqs]
  (loop [n 2]
    (let [steps (take n (frequency-adjustments freqs))
          step-counts (frequencies (rest steps))
          repeats (filter (fn [[k v]] (if (= v 2) k)) step-counts)]
      (if-not (empty? repeats)
        (first (keys repeats))
        (recur (inc n))))))

I was happy with how things looked. I went to a REPL and tested the logic with some of the samples, which seemed to get the answer I was looking for. frequency-adjustments was nice, actually, because you could see effectively a new list of how each step processes, which was great for visual analysis. I then fired it off with the test data.

And waited. Quite a while in fact.

Turns out that, when you have a high enough input, trying to build the list over and over again is somewhat taxing on the system doing that calculation. Obviously, this wasn't the solution I was looking for. At this point, I did a little bit of cheating (hey, it's the Internet, and I'm not proud) and checked the reddit post where people were posting solutions, and came across a separate Clojure solution by zqvt (slightly modified to fit my input parameters below):

(defn calibrate2 [freqs]
  (loop [xs (cycle freqs) seen #{} total 0]
    (if (contains? seen total)
      total
      (recur (rest xs) (conj seen total) (+ total (first xs))))));

This generates a set of values we've come across, as well as keeps a running total of where we're at while we're generating. The key here that I didn't even think about (let alone thought possible) was the use of rest to generate further sequences while not including the items processed. That was clever, and this solution very quickly provided a response.

Lessons learned:

1. My initial thought was to build a set of values that I'd seen going through the list calculated with

reductions, but I really wanted to try something that I could do without maintaining state outside of the loop. That led me down the path of regenerating the list each time, which made it impossible to run effectively. I probably should've gone with that easier thought process, as it would've worked faster (and I would've spent less time on the solution).

1. Good to be posting stuff again, and practice always helps.
2. Honesty - it hurt to come clean about looking for solutions, but sometimes you have to suck it up. Also, I felt really dumb after seeing the painful performance of my implementation vs. the one that I found. But I wanted to highlight a successful implementation, both to show that there are good ways to do it, and to give myself something to look forward to improving upon. I'm hoping to not need the crutch next time.

Being able to send and receive messages is key. Ten minutes after receiving my laptop today, I had a meeting that I had to run to, and to send an email containing some details to one of the attendees. I run my email from the office Exchange server to my desktop (and now the laptop) using fetchmail and procmail. While these may seem esoteric, and not terribly user-friendly, it gives me a strength that no other email client has - I can run scripts around my email. Procmail handles the filtering of the incoming fetchmail setup, and separates the email into the various folders for easy filtering rules (based on sender, topic in subject, etc.). Emails sent specifically to me in the To: header get a bit more prevalence, and emails with calendar invites as attachments get the attachment parsed and sent to a calendar. Since everything was using a standard Maildir format for storage on the laptop, migrating the email was as easy as running rsync between the two systems.

This covers only the receipt of email, not sending. Since December (referencing an earlier post), I've been using Emacs to do more and more things - this has grown to include IRC chat (via the ERC plugin) and email (using a pair of utilities called mu and mu4e). While normally I'd entertain jokes here (like "emacs is a good OS, it just needs a decent text editor."), I have to say that it's handy to have a single place to go for all the work you need to do. mu is external to Emacs, and is a search engine over your Maildir folders; you can use it on the command line to pick out emails that pertain to certain topics, and filter them by specific recipients and whether they're new/flagged/unread/etc. Mu4e wraps that logic in an easy to use mail client from within Emacs, and it's been much nicer than sifting through Outlook.

So I've got some software… now I have to customize what I run it in. Rather than stay with Unity (the default Ubuntu installed WM, which I frankly feel is counter-intuitive), I choose to go to a lesser known window manager called "Awesome." Appropriately named, as I haven't left it since I found it. By using a tiling window manager, I don't have to worry about resizing things to fit. Additionally, the entire interface is programmable via Lua, so defining custom shortcut keys and startup programs is fairly simple:

-- ...
-- Hotkeys for handling window resizing and management:
clientkeys = awful.util.table.join(
awful.key({ modkey,           }, "f",      function (c) c.fullscreen = not c.fullscreen  end),
awful.key({ modkey,           }, "q",      function (c) c:kill()                         end),
awful.key({ modkey, "Control" }, "space",  awful.client.floating.toggle                     ),
awful.key({ modkey, "Control" }, "Return", function (c) c:swap(awful.client.getmaster()) end),
awful.key({ modkey,           }, "o",      awful.client.movetoscreen                        ),
awful.key({ modkey, "Shift"   }, "r",      function (c) c:redraw()                       end),
awful.key({ modkey,           }, "t",      function (c) c.ontop = not c.ontop            end),
awful.key({ modkey,           }, "n",
    function (c)
        -- The client currently has the input focus, so it cannot be
        -- minimized, since minimized clients can't have the focus.
        c.minimized = true
    end),
awful.key({ modkey,           }, "m",
    function (c)
        c.maximized_horizontal = not c.maximized_horizontal
        c.maximized_vertical   = not c.maximized_vertical
    end)
)
-- Autostarts
awful.util.spawn_with_shell("/usr/bin/startup-script.sh")
awful.util.spawn_with_shell("~/bin/runme")

Awesome's libraries have amusing names: "awful", "naughty", and "vicious", to name a few. Currently, I have this attached to the GNOME session layer, so I get the benefit of GNOME's background and icon management, but the window management of awesome.

A programmer can't do much unless he has languages to write in. For me, that means having to add some additional packages:

• rbenv - this manages various installations of Ruby and the ecosystem around it. Similar to RVM, this uses shim binaries to point to rotating Ruby versions, so that I can use one version with one app, and use a legacy version to work on an older one.
• nvm - Same idea as rbenv, but for node.js. These libraries give me the flexibility of using different runtimes for different applications, and makes it easier to install the languages than with the system-provided binaries (which can either be out of date or harder to manage).
• I've already mentioned it, but Emacs is in here, too. Being able to easily see language and typographical issues with flycheck, syntax highlighting for languages available via el-get, and being able to launch a simple shell within the editor to run a test is a blessing to getting things done.

This was just for the first day, too. Things like browser plugins (which we use a myriad of for work) will likely come soon enough, and there will be tweaks to all of the stuff listed as what I need in the environment changes. Let me know if you have any questions on any of this, and I'll do what I can to answer them.

Now that we have the ordinal solved, we can go about formatting the actual output. In order to do so, we need to compare the values of the dates to find the differences between them (less than a month, less than a year, more than a year, etc.). In order to solve this, I arranged the date properties into a tuple - a structure with multiple data points within it.

let (start_yr, start_mo, start_dy) = start_values[0], start_values[1], start_values[2];

Tuples in Rust can be used in many ways; often, they're used to provide multiple values as a return of a function, or to store data that is paired or grouped together (like (x,y) coordinates).

My limited example above is referred to as a destructuring of a tuple - it allows creation of multiple variables from the tuple they were defined from. In other words, I can now use start_yr and start_mo in my code in other spots.

This example doesn't show much of the power of what is being done, but watch what happens when you pair it with the match statement from above:

match (end_yr-start_yr, (end_mo as isize)-(start_mo as isize), (end_dy as isize)-(start_dy as isize)) {
    (0, 0, 0) => format!("{} {}",
                         MONTHS[start_mo-1],
                         print_ordinal(start_dy)),
    (0, 0, _) => format!("{} {} - {}",
                         MONTHS[start_mo-1],
                         print_ordinal(start_dy),
                         print_ordinal(end_dy)),
    (0, _, _) => format!("{} {} - {} {}",
                         MONTHS[start_mo-1],
                         print_ordinal(start_dy),
                         MONTHS[end_mo-1],
                         print_ordinal(end_dy)

Here, we generate a tuple that acts as the difference between the year, month, and day values. Given the assumption that our ranges move forward in time, we present three cases:

• The start and end days are the same. In this case, just print the month and day (you don't need to print the end day, as it's the same).
• The difference of the start and end month and year are both zero. In this case, we're within the same month, so we don't need to print it twice. Instead, we print the range between the start and end day.
• The year is the same, but we have two different months. In this case, print both months and days.

Notice that we don't care about what values we have in the month and day. In a situation where we need that calculation, we can assign variables to it, as well:

(1, month, day) => {
    let use_yr = match (0.cmp(&month) , 0.cmp(&day)) {
        (Ordering::Greater, _) => false,
        (Ordering::Equal, Ordering::Greater) => false,
        (_,_) => true
    };
    if use_yr {
        format!("{} {}, {} - {} {}, {}",
                MONTHS[start_mo-1],
                print_ordinal(start_dy),
                start_yr,
                MONTHS[end_mo-1],
                print_ordinal(end_dy),
                end_yr)
    } else {
        format!("{} {} - {} {}",
                MONTHS[start_mo-1],
                print_ordinal(start_dy),
                MONTHS[end_mo-1],
                print_ordinal(end_dy))
    }
}

Here, we need to know the difference between month and day, as the year changed. However, if the month difference is less than zero (eg: from 2015-12-01 to 2016-03-01), then the year is assumed to be changing, and not printed. By extension, we will do the same with the date (eg: 2015-12-31 -> 2016-12-25).

We capture those differences from the matcher in the month and day variables, and then use those to make further determinations in the matcher's block. First, we figure out if we are using the year, based on the conditions above. Then, we choose a format for the date based on if we're using the year.

Rust includes a strong preprocessor, which will examine and selectively compile parts of your code. Based on this, you can keep your unit tests contained within your source file, and they will only be compiled when you run in a test configuration (usually using 'cargo test').

You can find the crate for my solution on my github repository. Note that there are different branches - I'll hopefully add more solutions to new branches for each problem that's solved.

I realize I don't post much on here, so I want to set a goal for myself for new blog posts. So, starting today, until the end of June, I'll strive to make a post every 2 days. You should expect to see something Friday. This will allow me to get some of my mind dumped out to the Internet, and expose my thinking to approaches for software. It will also give me time to put down things I've learned while working at AWS - expect a lot of the posts to be covering issues with CloudFormation, Elastic Beanstalk, Auto Scaling and more. Plus, I'll probably have some talk on new JS frameworks, Docker, Ruby gotchas, and anything else I can think of.

I still should be pretty reachable via the site - the sidebar for posts has my G+, Twitter and email nearby to click on. I've also added Disqus comments below, so let me know what you think of the new layout, and my future content.

As I mentioned, the base of the new platform is Harp. The base theme is a port of Casper, which is the default theme for the Ghost blogging platform. In addition, I've added a more flexible syntax highlighting library called Prism to help with code snippets (which I'll be able to use more frequently, I'm hoping!).

christopher.blog_upgrade = true;

Overall, the site is still set to run on GitHub Pages; I appreciate that they allow hosting like that, and moreover, allow the Hostname redirection that they do.

Migration of the actual data from the old platform to the new one worked pretty well. As they say, the best knowledge transfer medium is plain text. No reading from databases, no conversions; just a little bit of modification of the markdown files in one platform to the other.

That will remain to be seen. I had a goal of writing every two days; we saw how well that went. But, I've been working on teaching myself new things in the intervening time, and I think it may prove to be good not just for me, but for people reading, to start putting my thoughts to paper, so to speak.

I'm cautiously optimistic that I can do a better job of updating things. We'll see if I can make a pattern out of it.

The long-and-short of the second day's problem is thus:

You are given a list of box IDs, which are series of letters. In order to verify the contents of the boxes in total, you count the number of IDs with "exactly two of any letter", and separately count "exactly three of any letter" to make a checksum of the values. Using the example from the problem statement:

For example, if you see the following box IDs:

1. abcdef contains no letters that appear exactly two or three times.
2. bababc contains two a and three b, so it counts for both.
3. abbcde contains two b, but no letter appears exactly three times.
4. abcccd contains three c, but no letter appears exactly two times.
5. aabcdd contains two a and two d, but it only counts once.
6. abcdee contains two e.
7. ababab contains three a and three b, but it only counts once.

As a result, we have four IDs which contain exactly two repeated letters (2, 3, 5, and 6), and three IDs which contain three repeats (2, 4, 7). If you multiply these values together 4 x 3 = 12, so 12 is your checksum value. You are now asked to calculate the checksum value of the test input.

Not to be bitten by the trouble yesterday, I wanted to set up a full project (with the ability to test). This took a fair bit longer than I had intended, because I rabbit-holed into "how do I get this to provide test results automatically?" (where I spent about 20m), and "Why the hell isn't this test executing correctly?" (which took substantially longer).

Once I finally had my environment up and running correctly, I went about putting some test cases down:

(ns aoc.aoc2-test
  (:require [aoc.aoc2 :as sut]
            [clojure.test :refer [deftest testing is]]))

(deftest aoc2-part1
  (testing "the example statement"
    (let [input ["abcdef" "bababc"
                 "abbcde" "abcccd"
                 "aabcdd" "abcdee"
                 "ababab"]]
      (is (= 12 (sut/checksum input)))))
  (testing "a simple second example"
    (let [input ["abab" "abaa" "aab"
                 "aac" "aaa" "abc"]]
      (is (= 6 (sut/checksum input))))))

This uses the example scenario given in the problem, as well as a small example I cooked up myself. Armed with tests that executed on file save, I was ready to build out the solution.

Once again, this problem lends well to the frequencies function provided by Clojure - it will automatically group the values within the string by how frequent they show up. Since we only care about twos and threes, however, we need to search those results for those values. The reduce function (of "map/reduce" fame) is where we want to be - it gives us an easy way to take a list of things and make a scalar value out of it. In our case, we want to reduce each map to its existence of twos and threes; ideally, {:a 3 :b 1 :c 2} would result in {:threes 1 :twos 1}.

Building out a complicated reduce function generally is painful; because the inner function to a reduce is exactly that (a function), I defined it outside the logic. Because clojure values are generally immutable, I needed an easy way to maintain the state during the loop - transient helped out here, because I treat the map as temporarily mutable, but only within the bounds of the function and the lifetime of the transient binding.

Here's what I ended up with for the part 1 solution:

(ns aoc.aoc2)

(defn reduce-twos-threes
  "check the given frequency map n for twos or threes matches, and update
   the memo map to indicate if the string has a match. Used for a reducer."
  [memo n]
  (let [t-memo (transient memo)]
    (if (some (fn [[k v]] (= v 2)) n) (assoc! t-memo :twos (inc (:twos t-memo))))
    (if (some (fn [[k v]] (= v 3)) n) (assoc! t-memo :threes (inc (:threes t-memo))))
    (persistent! t-memo)))

(defn checksum [input]
  (let [sum-maps (map frequencies input)
        twos-threes (reduce reduce-twos-threes {:twos 0 :threes 0} sum-maps)]
    (* (:twos twos-threes) (:threes twos-threes))))

This makes the checksum function read really straightforward: find the frequencies of each input value, find the numbers of twos and threes (stored in a map), then finally multiply the twos and threes values together.

Distilling the problem statement again:

Given your list of IDs, the particular IDs you're searching for differ by just one character; for example, "text" and "tent" fit this requirement, because you only need to replace the "x" and "n" characters. The example given in the problem is this:

• `abcde`
• `fghij`
• `klmno`
• `pqrst`
• `fguij`
• `axcye`
• `wvxyz`

where `fghij` and `fguij` are "adjacent" boxes. Any problem where you're comparing closeness of matching strings screams Levenshtein Distance. The Levenshtein distance of two strings is a measure of the minimum number of changes required to turn one string into another - this is generally counting insertion, deletion, and substitution, but our needs solely require substitution (better known as Hamming Distance - two separate mathematicians studying the same area of string differences. This is done by comparing values in each string, and adding 1 to each difference you encounter - a pretty simple comparison function.

(defn hamming
  "Compute the Hamming Distance between two equal length
   strings."
  [str1 str2]
  (if-not (= (count str1) (count str2))
    (throw (IllegalArgumentException. "Strings must be equal size.")))
  (loop [s1 str1
         s2 str2
         score 0]
    (if (empty? s1)
      score
      (recur (rest s1) (rest s2)
             (+ score (if (= (first s1) (first s2)) 0 1))))))

This uses Clojure's tail-recursive optimizing functions loop and recur to compare the strings one-by-one, and calculate their Hamming distance (we've got a check in there to make sure they're the same length, and throw an error if not).

Once that was complete, I built out a way to sift through the list of boxes to find just the ones with a Hamming distance of 1. This returns a two-item sequence, one for each swap of matching (there's probably an optimization there to not go through the entire list):

(defn find-christmas-boxes [input]
  (keep identity (map (fn [base-str]
                        (let [target-box (filter #(= 1 (hamming % base-str)) input)]
                          (if-not (empty? target-box)
                            [base-str (first target-box)]))) input)))

There's a couple of cool things to point out here. First, the base map function will return a lot of nil (Clojure's null value). In order to get rid of those, we use the identity function (which basically says "return true if truthy"; it's effectively a cleaner (not (nil? thing))). Another thing to point out for non-Clojurists is that shorthand function declaration used in the filter call:

;; These two are equivalent:
#{+ % 3}

(fn [arg] (+ arg 3))

Finally, the AoC puzzle asks for the common characters between the two strings. This is close to the Hamming Distance function above, but we just need to drop a character if it doesn't match. This got reduced to the following:

(defn remove-uncommon-letter [s1 s2]
  (apply str (keep-indexed #(if (= (get s2 %1) %2) %2) s1)))

;; To execute everything:
;; (apply remove-uncommon-letter (first find-christmas-boxes input))
;; where input is the raw input string from the project.

apply is the cool bit here - using apply allows you to use vector (read: array) entries as arguments to a function:

(let [numbers-to-add [1 2 3 4 5 6]]
 (apply + numbers-to-add)) => 21

And hey - no borrowing from anyone else today, and right before day 3 releases. I'm saving that for tomorrow, though. :D The Github Gist for today's problems is right here.

I've had forays into learning Emacs before, but I've always shied away, after playing with some basic tooling, and forgetting how to close it more often than I care to admit. This time was different, though; I had more years of experience under my belt, and it was more about getting myself into an uncomfortable place before I gain more knowledge.

My first thought was to find some type of starting guide. While the Emacs tutorial helped in terms of understanding navigation and simple editing, it didn't really show me the true power of the environment that I had gained. A cursory google search brought me to the Emacs Starter Kit. This toolkit provides some default setting to get you started with the environment; I used the documentation around it to gain knowledge of things like Melpa and Marmalade, which act as Emacs Package Managers of sorts.

Following my initial setup with the starter kit, I started delving into the emacs wiki. This became a much more handy resource to me, as it provided me with multiple provided solutions to given issues that I've encountered while converting my vim-based mind to a constantly-insert-enabled editor. When I'd run into an issue where I found something I'd like to do similar to vim, I'd head to the wiki to find what analogs are available. Once I'd find a package which did what I looked for, I'd test it out with an M-x pacakge-install, and incorporate it into my init.el when I felt I had it down.

These are the things that I've discovered in the two months since I switched:

• Split pane support. I actually like the way that Emacs splits its windows better than vim. A C-x 2 or C-x 3 is an easy way to remember it; coupled with the 'workgroups2' package, configurations can be stored across sessions, too.
• Lisp. This has been a slow one for me, but I'm becoming more interested in learning Lisp and Lisp-like languages, like Clojure. I have a lot of work to do here, and that will be something to work on in the future.
• Tramp. Being able to edit files across an SSH tunnel is a fantastic feature.
• Buffers without files. Since the editor is meant to live on indefinitely, it's nice to spin up a new buffer and set the mode(s) I want, and let it reside in memory for a while before saving it. If I need to, a save is close enough away, but it works wonders for when I need to take some quick notes.
• ERC. I no longer need a separate IRC cilent; Emacs handles it for me. This is fantastic for me at work, where we frequently use chat to talk around.

Things I wish I had from Vim:

• Sentence-like movement. I've sort of rebuilt this on my own with a combination of line-jumps (M-x goto-line) and ace-jump-mode, but being able to translate "^3wci(" into what it can do in Vim is a skill I have yet to master.
• Mixing modes in HTML. This was noticeably less of a problem in Vim, but I don't know if it was due to the editor or my lack of noticing that showed just how difficult it is to switch contexts from HTML/CSS/JS all in the same file. I've tried doing the nXML hack and multiple modes, but those have worked to no avail.
• Closing the editor. True, I can leave Emacs. But, I miss popping up a new window for one file, and then leaving right after a quick edit.
• Workspace management. Because of the way I separated files into tabs in Vim, I knew each tab matched a different section of what I was working on (or another project entirely). I lack this with the way that buffers are managed by default in Emacs. I'm still looking for better ways of handling this management, though - workgroups2 has been a nice start.

Things I know I still have yet to learn:

• More Lisp. I've gotten a good start, but that's a deep rabbit hole.
• Shell, email within Emacs. I used to use a lot of separate tools - now that Emacs contains most of them, I'd like to get better at handling those tasks within Emacs.
• Org-mode. I've seen my coworker pull off some crazy things with scheduling and notes within Org-mode, and I'd love to get to the point where I can do them, too.
• Macros and scripting. My next Pragmatic tenet is Write Code That Writes Code; I think getting your editor set to facilitate your programming counts. :)

We'll see what the next few months hold.

Let's say you're an avid photographer - you'll have a lot of photos collected. In order to make sense of your collection, you're going to want to organize those photos. If they were physical photos, you'd want to collect them by the event that you took them at:

• Tim's birthday party
• Joe's wedding
• Vacation photos from Las Vegas
• random photos of food
• far too many cat pictures
• etc.

Additionally, let's say these photos happened over the course of a few years.

Borrowing from the physical realm, we can place these photos into different folders, or directories, in order to keep them organized. Let's lay them out like so:

• 2018
  • Joe's Wedding
  • I <3 Food
  • My Cat
• 2019
  • Tim's Bday Bash
  • Vegas trip
  • My Cat
  • I <3 Food

You'll notice there are duplicate names here - that's okay, because they're nested within two different folders.

Now, all of these folder names are legit as they stand, but they'll be a little harder to deal with when on the command line with some of the special characters and spaces. It's a standard convention to replace spaces and special characters in names to make it easy to deal with, while retaining most of the meaning that was present in the original names; most of the replacements are things like dashes or underscores. This would be my likely replacement:

• 2018
  • joe-wedding
  • i-heart-food
  • my-cat
• 2019
  • tim-bday-bash
  • vegas-trip
  • my-cat
  • i-heart-food

Syntactically very similar, and much easier to deal with while typing.

So rather than pulling up a file manager window, let's make this structure out of commands at a terminal.

the mkdir command is used to make a directory. The basic invocation is very straightforward:

$ mkdir <folder-name>

This command will create a new directory with the given name based on the directory you're currently in (referred to as your 'Current Working Directory' or 'Present Working Directory'). Sometimes the terminal you're using will tell you where you are as part of the prompt; even if not, you can find out by running the command pwd to give you that directory.

$ pwd
/home/ballpointcarrot

So let's make our photo collection structure:

$ mkdir 2018

Wait… Nothing came back. Did it do anything?

ls is a versatile command - it gives you a listing of your PWD. This becomes handy when you're looking around you filesystem, and generally know where something is located. If we do an ls where we are now, you'll see something like:

$ ls
2018/   Desktop/        Downloads/      Notes/          Videos/
Books/  Documents/      Music/          Photos/

Oops… that 2018 isn't in the right spot. Let's move it with mv:

$ mv 2018 Photos

Again, we get no output signifying anything. However, on the next ls:

$ ls
Books/          Documents/      Music/  Photos/
Desktop/        Downloads/      Notes/  Videos/

Now we can see that the 2018 folder is no longer here. We want to make sure that it's in the Photos directory though, so we'll check there, too:

> Note: this shows that the ls command can be used on folders - meaning you don't have to be in the folder to use ls. That gets handy when you're searching a lot of subfolders.

$ ls Photos
10262018_0001.JPG  10262018_0035.JPG  10262018_0069.JPG  10262018_0103.JPG  10262018_0137.JPG  10262018_0171.JPG  10262018_0205.JPG  10262018_0239.JPG  10262018_0273.JPG  10262018_0307.JPG
10262018_0002.JPG  10262018_0036.JPG  10262018_0070.JPG  10262018_0104.JPG  10262018_0138.JPG  10262018_0172.JPG  10262018_0206.JPG  10262018_0240.JPG  10262018_0274.JPG  10262018_0308.JPG
10262018_0003.JPG  10262018_0037.JPG  10262018_0071.JPG  10262018_0105.JPG  10262018_0139.JPG  10262018_0173.JPG  10262018_0207.JPG  10262018_0241.JPG  10262018_0275.JPG  10262018_0309.JPG
10262018_0004.JPG  10262018_0038.JPG  10262018_0072.JPG  10262018_0106.JPG  10262018_0140.JPG  10262018_0174.JPG  10262018_0208.JPG  10262018_0242.JPG  10262018_0276.JPG  10262018_0310.JPG
...

Whoa! Where's the 2018 folder? These are all just JPG files (the photos that I've been dumping without organizing into the Photos folder). Fortunately, I can filter out the type of object returned from ls:

$ ls -d */
2018//

There's our folder. Now let's explain that command: the -d within the command tells ls that we just want directories, and not files. However, ls isn't smart enough on its own to just grab the directories on its own; we have to explicitly say grab "all directories", which is where */ comes in - it signifies "anything in the current directory" with the asterisk (also called a star or wildcard), and the forward slash is for anything designated a folder.

Let's get to work on the rest of those folders. First, let's put ourselves in the right place.

The cd command changes our current working directory. By changing directories, it gives us the ability to change context with what we're doing on the filesystem. In our case, we'll change to the Photos directory, because we're working in the context of organizing our Photos. Makes sense.

$ cd Photos

Again, the command has now output, but we can do a pwd and see that we've changed places:

$ pwd
/home/ballpointcarrot/Photos

Now let's finish up our 2018 folders. Me, being lazy, want to do everything in one shot - fortunately, mkdir lets us do just that:

$ mkdir 2018/joe-wedding 2018/i-heart-food 2018/my-cat

This creates three folders, all nested neatly under the 2018 folder. "Great!", we say, and we go to do 2019:

$ mkdir 2019/tim-bday-bash 2019/vegas-trip 2019/my-cat 2019/i-heart-food
mkdir: cannot create directory ‘2019/tim-bday-bash’: No such file or directory
mkdir: cannot create directory ‘2019/vegas-trip’: No such file or directory
mkdir: cannot create directory ‘2019/my-cat’: No such file or directory
mkdir: cannot create directory ‘2019/i-heart-food’: No such file or directory

Uh oh… because we never created the parent 2019 folder, it's not allowing us to build the rest of the directories. We can outwit it though; mkdir has a parameter option -p, which gives us the ability to make parent directories within the same call:

$ mkdir -p 2019/tim-bday-bash 2019/vegas-trip 2019/my-cat 2019/i-heart-food

All good. Just to double-check:

$ ls 2019
tim-bday-bash/  vegas-trip/     my-cat/         i-heart-food/

So now we've got our directory structure in the Photos directory, with a boatload of random JPG files. How are we going to get them organized? It looks like a lot of them are around the same dates (look at all the 10262018_xxxx files we have up there). Let's take a look at one or two of them to get a sample, to make sure it's the right event.

Note: This step will be different depending on the platform you're on, so I'll give both.

# OSX example
$ open 10262018_0001.JPG

# Linux example
$ xdg-open 10262018_0001.JPG

Both of these commands do the same thing - they ask the current environment to figure out who the best person to open a JPG file is, and then executes that program. Ideally, you'll see a window with your picture loaded.

I started with a vanilla cargo project, and added the following into the cargo.toml:

[[bin]]
name = "bootstrap"
path = "src/main.rs"

[dependencies]
lambda_runtime = "^0.4"
tokio = "^1"
serde = { version = "^1", features = ["derive"] }
serde_json = "^1"

The [[bin]] section allows us to specify the binary filename for what's built (and saves us renaming the file after compilation). The dependencies are all references and dependencies of the AWS Rust runtime crates - that's where the code for the function we'll be using is pulled from.

we just have one file in the source directory, at src/main.rs:

use lambda_runtime::{handler_fn, Context, Error};
use serde_json::{json, Value};

#[tokio::main]
async fn main() -> Result<(), Error> {
    let funct = handler_fn(func);
    lambda_runtime::run(funct).await?;
    Ok(())
}

async fn func(event: Value, _: Context) -> Result<Value, Error> {
    let first_name = event["firstName"].as_str().unwrap_or("world");
    Ok(json!({"message": format!("Hello, {}!", first_name)}))
}

For those less savvy with Rust code, this defines the 'bootstrap' runtime under main(), and calls the async function func() to act as the lambda function body. Our function responds with a message of "Hello, World!" in a JSON response by default, or can respond with a specific greeting when passed a "firstName" JSON value as part of its input.

Now, you could build this locally, but because of the way that the lambda function is called, local runs will panic:

± cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.39s
     Running `target/debug/bootstrap`
thread 'main' panicked at 'Missing AWS_LAMBDA_RUNTIME_API env var: NotPresent', /home/ckruse/.asdf/installs/rust/stable/registry/src/github.com-1ecc6299db9ec823/lambda_runtime-0.4.1/src/lib.rs:57:58

The immediate goal here is to run it in lambda, and not locally, so we'll save testing it out on our own for a later time.

I hope you can use this to make a running start building out lambda function code on the new Graviton2-based Lambda runners. Let me know if this helped you out!

After we saved the cloth from the previous problem, it's now up to the Elves to figure out how to cut it optimally. The problem statement makes the first assertion that the fabric is a square of 1000x1000 square inches. This proved useful to my method of solving the problem, as you'll see below.

Each elf makes a claim on the fabric to designate a rectangle they want to cut. The claims have the following format:

#12 @ 3,4: 5x6

Which is to be interpreted as "Claim number 12, with the top corner location of (x,y) = (3,4), has a width of 5 and a height of 6."

To make sense of this, I used a regular expression to isolate the various numerical terms (while regex is a superpower, it is also a bit of a rabbit-hole, and I won't cover its general concepts here). Unfortunately, while Java 7+ has support for a regex feature called named capture groups, Clojure does not have that support out of the box. However, the regex with the named groups still functions, but I can only get positional arguments. I built out a function that took an input claim, and built out a rather interesting set of responses:

(defrecord Claim [claim-number squares])

(defn convert-to-grid
  "Converts a claim into a sequence of 'taken' squares."
  [claim grid-width]
  ;; Named groups would be great here, but Clojure doesn't support this natively.
  (let [matcher #"#(?<claim>\d+)\s@\s(?<x>\d+),(?<y>\d+):\s(?<width>\d+)x(?<height>\d+)$"
        matches (re-find matcher claim)
        [_ claim horiz vert width height] matches
        x (Integer. horiz)
        y (Integer. vert)
        w (Integer. width)
        h (Integer. height)
        rows (take h (iterate inc y))]
    (->> (map #(range (+ x (* grid-width %)) (+ (+ x w) (* grid-width %))) rows)
         (flatten)
         (set)
         (Claim. (Integer. claim) ))))

Let's walk through this example a little.

The first thing we see is the definition of a clojure record (similar to a struct). Because Clojure lives on the JVM, this builds out effectively a Java class and allows you to instantiate objects of that type. The problem above could have been solved with a simple map, but I wanted to give readers of the codebase an easier way to have a mental model of the transformed claim. Additionally, this helps us keep track of the claim number, which is not important in Part 1, but makes a re-appearance in Part 2.

Because we know the width of the field we'll be working with in units, I made a choice to build out the "rectangle" that a claim represented by identifying the cells that the rectangle makes up. For example, in a 5x5 grid, with a claim of #1 @ 2,0: 3x3:


This leaves us with a set of squares: #{2 3 4 7 8 9 12 13 14}. The practical upshot here is now we can use set logic (difference, intersection, union) to manipulate the rectangles and calculate our details for overlaps. And that's just what I did:

(defn get-overlap
  "returns the amount of overlap based on calculated inputs.
   Answer provided in square units matching the units entered
   (for the case of the problem, square inches)."
  [claims]
  ;; Perform intersection to find any matches, then union to combine; repeat through the list.
  (loop [mapped-area (map #(convert-to-grid % 1000) claims)
         shared-fabric #{}
         intersections #{}]
    (if (empty? mapped-area)
      intersections
      (let [intersect (set/intersection shared-fabric (:squares (first mapped-area)))
            union (set/union shared-fabric (:squares (first mapped-area)))]
        (recur (rest mapped-area) union (set/union intersections intersect))))))

Again we see our friends loop and recur from Day 2. This section highlights one of my favorite things about Clojure - maniuplating data in bulk. We pass into this a vector of claim strings, that are parsed in the function above it. In just one map call, however, we were able to convert each of those strings into a grid area 1000x1000 wide. Once we have objects we can compute easily against, we go about calculating. :)

The set/intersection notation is new to these examples, because clojure.set is outside of Clojure's "Core" namespace - up until now we've been using functions packaged in clojure.core, which is loaded by default for a Clojure runtime. Since clojure.set isn't, we have to import it into the namespace (and in our case, provide it a nice short name to use when calling):

(ns aoc.aoc3
  (:require [clojure.set :as set]))

This allows us to call functions in clojure.set by using set/fn-name. For each iteration of the loop, we do three things:

1. We check against the "shared fabric". This is done by doing a set intersection between the current rectangle (defined by (first mapped-area)) and all of the rectangles that came before it.
2. We define the "shared fabric" by adding the current rectangle to the rectangles that have already been added by a set union.
3. When we cut back into the next iteration, we take the union of all found intersections in previous iterations, and the intersections we've found in this run. This piece is what gives us our total overlap at the end, as we're constantly accumulating more overlap; because it's a set, however, we're not recounting the same values, we're just including them as "overlapped" already.

Once this was done, I was able to solve Part 1 quickly.

Now that we've found the overlapping area, our challenge is to find the rectangle which does not have any overlapping area within the list of claims. This is where keeping that claim number comes in handy.

I wanted to come up with a clever way of using the set notation used above to make a lightning-quick function for processing the list of rectangles to find one with no overlap, but nothing came to mind. (If anyone finds one, let me know and I'll owe you a coffee.) Instead, I used a little more of a brute force method: compare each grid to the list of grids, and cut out when you find no set intersections. This was a little more computationally intensive (O(n^2)), but given the count limit in the sample input, it wasn't too bad to sit for a few seconds while the laptop pounded it out.

I had one hiccup as I was putting this together - how do I managed the list of claims so that I don't run an intersection with myself? That would cause even the "no overlap" rectangle to match (as it's matching itself). What I ended up doing was breaking out the function that handled the overlapping calculation to have a check at the top that said "if you're the same rectangle by claim number, then return nil" - this allows you to pass the full list and not worry about matching yourself.

(defn overlapping-claim [c1 c2]
  (cond
    (= (:claim-number c1) (:claim-number c2)) nil
    (not-empty (set/intersection (:squares c1) (:squares c2))) c2))

(defn find-no-overlap
  "given a set of input claims, find the claim that has no overlap
  with any other claims."
  [claims]
  (let [grid-claims (map #(convert-to-grid % 1000) claims)]
    (loop [idx 0 ignores #{}]
      (if-not (contains? (:claim-id (nth grid-claims idx)) ignores)
        (if-let [overlap (some #(overlapping-claim (nth grid-claims idx) %) grid-claims)]
          (recur (inc idx) (conj ignores (:claim-number overlap)))
          (:claim-number (nth grid-claims idx)))
        (recur (inc idx) ignores)))))

Cool Clojure-y things to point out here:

1. cond. Think of cond as a bit of a if/else on steroids. It allows you to pass a pair of items: test expression, and success expression. If the test expression passes (ie, returns true), then the success expression is evaluated and returned (immediately - it does not fall through to other condition pairs). This means I don't have to nest if calls, which makes it easier to read (IMO).

2. if-let. This is basically a conditional binding (think variable) assignment: if the binding value is not nil, then assign the value that binding for the scope of the if-let. It saves you from the all-too-common pattern of:

   my_var = doThingPossibly()
   if my_var
   # do other things
   end
   

   or

   if (doExpensiveThing()):
       repeatItForVariable = doExpensiveThing()
       # do other things
   

And again, my code is available in a Github Gist. Until tomorrow!

Nixos provides an ISO from their website, as is often the case with linux distros. The only qualm that I had in this stage is that, because I wanted to do a UEFI installation via USB, I had to jump through a few extra hoops in order to get things working correctly. This is less of a problem with Nixos specifically, and more endemic to the linux community as a whole - we need to make UEFI boot media easier to create. I miss the days of dd if=<iso> of=<flash-drive>. :)

I was pleasantly surprised to see that you could boot into a graphical environment using the boot media. This is something that some major distributions still seem to miss, and I was impressed to see a relatively young distro include a UI, even if it didn't handle the installation that way. At the very least, it gives you a sense of "try before you buy."

The initial read-through of the Nixos Manual were useful, but sparse in places where more information (particularly for a new user) would have been helpful. As you can see, the first 9 steps are pretty straightforward - hard disk setup, loading options for runtime, etc.

Then there's step 10.

"Edit this file" has a lot of openness to it. They do give you some resources around here (links to detailed configuration docs, a very barebones initial config, and links to "real-world installations" to compare to), but as your first foray into the format of the configuration.nix file, I would have loved a "guided tour" here, giving insight into why the file structure is how it is, common configuration options for particular installation types, and a more "this is a normal base installation" config instead of the bare config provided in the manual.

In my mind, this is where the magic of Nixos happens - the documentation should highlight the magic, calling out its importance and showcasing how the features work. Imagine my surprise (and delight!) when I found I could enable xorg with a single line:

services.xserver.displayManager.sddm.enable = true;

Having fast, impacting implementations of large swaths of software fed through because a single option was enabled? Again, that's magic, and that's what needs advertised here.

Other first-order-of-business options for me at installation are things like:

• Adjusting the keyboard layout (Dvorak)
• Setting timezone and verifying current time (with optional NTP)
• laptop configuration (thinkpad module, touchpad config)

These were all fairly easy to find though the nixos wiki - when you've had other users run into the same configurations, it's always nice to have them easy to find.

The rest of the installation was a breeze - you run nixos-install, set your root password at the end, and then reboot into your new OS.

Now I had a base working system, and it only took me a few generations of building and rebooting. After about generation 6-7 or so, I had things down to where I liked them for a start. From here, it was time to dig into what I could do with it.

In the last iteration of the blog engine, I was still using a static site generator (zola) to upload the contents of the site to Netlify. This worked, but as mentioned in the previous post, I've been enjoying the community over at omg.lol. One of the things that has resonated with me is the sense of simplicity: a lot of what is made in that community is small, single-focused and simple sites that serve mainly to be enjoyable.

I realized that reaching to simpler processes would make the time spent with my own space on the web would make working in it something to look forward to, instead of something that I need to prove myself with. I've been missing the joy in software and computing, and I needed to shove off a lot of added baggage to get to a point where I can find some fun again. This led to finding more ways to simplify, and keep what I'm doing close to the standard workflow that I've already built out for myself. There's no sense in me trying to learn a new suite of tooling for this. It's just for me, so I might as well let it live where I do. The end goals here:

• If you enjoy doing it, you'll do it more often.
• Don't feel pressure around adding things, nobody's judging you.
• Open up and be more authentic.

When I'm on a computer, I more or less live within an Emacs session. I've seen other blogs that are made solely from Org mode documents, so I decided to make this site in the same method.

David Duncan: I blame you for being the starting point of all this. :P

This site/blog/space to throw my inanities is now fully built from Org mode. While designed as a way to handle tree-style note taking, it is a full markup language like Markdown in terms of flexibility. On top of that (and relevant for this space), it can also be used as an environment for literate programming, which is useful given both my profession and occasional interest in hosting advent of code¹ solutions here.

I did a fair amount of diving into research on how best to establish my use of Org mode as a full blogging platform, so I want to throw out links to the blogs that gave me inspiration for building mine out in the way I did:

• https://systemcrafters.net/publishing-websites-with-org-mode/building-the-site
• https://www.ereslibre.es/blog/2019/09/building-a-personal-website-with-org-mode.html
• https://pavpanchekha.com/blog/org-mode-publish.html
• https://zwpdbh.github.io/emacs/org-to-blog-using-org-publish.html
• https://llazarek.github.io/blog/2018/11/org-export-processing.html
• https://commonplace.doubleloop.net/setting-up-a-literate-publish-el-with-org-babel?stack=my-publish-el-configuration&stack=how-i-publish-my-wiki-with-org-publish#org94967b6

Taking that literate programming mentality into account, I spun up an org file explicitly designed to describe how I wanted to build out the blog. Starting in January, I went through a number of iterations in how I wanted to approach building the site:

• Org -> Hugo -> some host/cdn/etc.
• Org -> markdown -> weblog.lol
• finally: Org -> Html -> CDN

While attempting building these out, I used the org file to not only describe the tasks that I still had to accomplish, but also embedded the code that was used to generate the site itself. Having both together allowed me to plan ahead for things that aren't complete yet and discuss approaches before trying them out.

You can find the full contents of the file here², but both as a way to see if I can do it usefully, and as a way to give you a taste without leaving, here's an excerpt:

** DONE Make the HTML not ugly
I want my templated theme back. :'(

There's arguments on whether to use overrides for parts of the html template
baked into org-publish, or to just override the entire template.

First off, let's load our CSS:
#+begin_src elisp :tangle bpc-blog.el
(defun bpc/stylesheet-link (path)
  (format "<link rel=\"stylesheet\" type=\"text/css\" defer href=\"%s\" />" path))

(defun bpc/highlightjs-head ()
  (with-temp-buffer
    (insert-file-contents "templates/head.html")
    (buffer-string)))

(setq-local bpc/html-head-extra
            (string-join 
                    (cons (bpc/highlightjs-head)
                          (mapcar #'bpc/stylesheet-link
                            '(
                              "/assets/styles/styles.css"
                              "/assets/styles/catppuccin-frappe-pre.css"))
                          )
                    "\n")
            )
#+end_src

Applying a ~#+TITLE: <page title>~ to the pages grants each a nice H1 heading.
I've added that to the relevant pages.

Syntax highlighting there is a little odd, but I don't blame the highlighting tool.

Because the previous iteration of the blog used Markdown as a format for the contents of the blog, moving to org wasn't terrible. Each file required tweaks, but they weren't major.

Frontmatter had to be handled in a different way - instead of using a block at the top of the page, Org mode uses metadata values like this:

#+title: Page Title Goes Here
#+date: <2026-03-17 Tue>

The other major thing was syntax changes around links. Fortunately, my years in vim prior to Emacs taught me how to do quick macros. Switching from

[link title](https://example.com)

to

[[https://example.com][link title]]

wasn't too bad.

The positive benefit to only posting a couple of times every few years: I didn't have many posts to fix. :)

I have some things left to do to polish all the features that I want to get done:

• RSS Feed(s)
• Tags pages
• Better metadata rendering on posts
• Supporting images better

I'll get to them, and because I'm making it myself, and I'm not putting too much stress on myself to complete it, it'll get there when it's needed.