This isn’t the first nest to be built there. Years ago, I saw a different family of wasps build their nest a few rafters over. That nest lasted a season, bore a few wasps and was swiftly abandoned.

I’m done washing now, and we head over to the couch. Hanging just outside the back window is a planter that is tipped on its side. Devoid of plant life, it has become the home of many a generation of Spotted Pardalote. Each generation tirelessly excavating a burrow to call home for the season. Adorning the insides with fine grass and feathers to make a home. Eggs are laid, fledglings emerge, and so the nest is abandoned. Until next year, when another spot is excavated and turned in to a safe space to protect new life.

The cycle of build, inhabit, departure, decay continues.

We humans build houses, mega structures, cities to achieve similar goals. Provide shelter and safety — a place for life to take place, but also to manufacture for profit and advance humanity.

We’ve built entire cities whose soul purpose was to provide shelter or manufacture cars — and when those things are no longer needed or financially feasible, we depart and let entropy take over.

We build homes in the suburbs and raise families, sometimes for several generations, but ultimately, those homes are abandoned and passed on to other people. In this case though, the structure itself is still used and cared for.

When a structure ultimately serves its purpose, however, we, much like the animal kingdom defaults to departure rather than demolition. I have no answer as to why, but departure feels more like a release. It feels more respectful to the places that sheltered us and helped us live our lives. It feels like we’re leaving behind a reminder, to ourselves and future generations or archeologists, that life happened here. That we briefly defied entropy, ordered something chaotic and did something beautiful with the result. And to let order naturally return to chaos is to let something in the universe slowly exhale. Unlike the abrupt and violent severance of demolition.

The same can be said for life itself. When our time comes, and our bodies are abandoned, we usually see the same processes take place. A natural decay, a return to the earth to feed other life and continue the cycle of impermanence. Even the seeming annihilation of cremation is just accelerated decay.

I watch my son at his pile of blocks now, placing wooden shapes down around his other toys. He’s building something too, in his way — temporary worlds, brief architectures of imagination that will be abandoned the moment something else catches his eye. No ceremony, no destruction, just departure.

Perhaps this is what we’re all doing. The wasp in the eaves, the pardalotes returning to burrow anew each season, the families who locked their doors one last time — we build, we inhabit, we leave. And in leaving rather than destroying, we acknowledge something true: that the structure was never really ours to unmake. We borrowed materials, borrowed time, created temporary pockets of order. But the materials themselves want to return, and maybe our departure is simply honouring and enabling that want.

The old pardalote nest from last season is still visible in the planter if you look closely — a small cave of earth and dried grass, already beginning to collapse in to the soil around it. The wasp nest from years ago has gone papery and gray, dissolving slowly into the eaves. These aren’t monuments to failure or loss. They’re evidence. Life happened here. Order briefly prevailed. And now the universe gets to slowly breathe it all back in.

I wonder if this is the real legacy we leave behind — not the structures themselves, but the pattern. The knowledge that it’s okay to build something beautiful, live fully and completely within it, and then simply walk away.

• ARC Raiders
• Split Fiction
• Blue Prince
• Hollow Knight: Silksong
• Death Stranding 2

Music

• Sleep Token — Even in Arcadia
• Starship Syncopation — Cory Wong
• Heavy Metal — Cameron Winter
• DON'T TAP THE GLASS — Tyler, The Creator
• GNX — Kendrick Lamar
• USB — Fred Again..

Live Sets

• Fred Again.. | Boiler Room
• Caribou, Floating Points & Fred Again.. | Drumless Mix
• King Gizzard & The Lizard Wizard — Live in Athens (all of the nights are amazing)
• Underworld | Boiler Room: London

Books

• Kafka On The Shore — Haruki Murakami
• The Wind-Up Bird Chronicle — Haruki Murakami
• Hard-Boiled Wonderland and the End of the World — Haruki Murakami
• The Peripheral — William Gibson

TV Shows / Movies

• The Naked Gun
• Alien: Romulus
• Omar and Cedric: If This Ever Gets Weird

• It's been a while! The last few months have brought many a change. I won't go in to details but it has been a busy few months. Despite everything, the world keeps on spinning and so another week passes! Let's get in to what happened;
• Last week of parental leave before getting back on the wheel! I am quite excited to get back and catch up with work peeps again!
• Big week for the dogs. Barkly has a lump on his spleen that needs to come off as it's teetering on too-big-to-leave. He also has some liver enzyme issues that I tried to get some insight in to a while ago, to no avail. On the plus side, I might be able to get some answers while the spleen-related surgery is happening so I can better treat the little boy.
• On Sunday, both Barkly and Crumpet got in to the nappy bin, tore apart some nappies and ate some of the absorbent material. So that was a fun trip to the vet to get them to bring the nappy parts up! What made it even better was that the folks were understaffed (boo) and I had to manage the spewing dogs, trying to catch whatever they were bringing up. Thankfully, it was all pretty quick and I was out of there with some lighter, and happier dogs.
• I had Sebastian's first birthday at the zoo! Can't believe the little man is already 1! The day itself was a little rainy, so we didn't get to wander too much, but the little guy had his first babychino and a play around on the playground / swings <3
• I've been trying to collect some of the poems that have been on my mind lately at /poems.
• I've been playing some paper Magic online with Spelltable and it has been surprisingly effective! Even when a card looks illegible on the video I am seeing, the software is still able to parse it just fine. I reckon there must be some shenanigans happening that has the card recognition happening locally on the other machine before the video is compressed and sent to me when I click a region of the table on my screen. If not, then suuuuper impressed at how it's able to recognise cards that look blurry on my end.
• I've been playing ARC Raiders a bit this week and I've really enjoyed my time with it. I'd never played extraction shooters, but I totally get the hype about the genre now. For those unfamiliar, an extraction shooter has you load in to a map with other humans and computer players. The humans can choose to be friendly and team up to take on the computer players, or be hostile and take more rewards for themselves. You load in to each map with a selection of things that you've collected in previous matches, and if you don't make it out safely, you lose everything. As a chronic hoarder of in-game items (you know, in case I need to use that potion later), it took a bit to get over using all the things I have collected and risking my good things™ but after losing stuff once or twice, the fear of loss has subsided, and the game is just a joy now.
• I've been continuing my journey through the works of Haruki Murakami, now about 1/3 of the way through The Wind-Up Bird Chronicle. So far a slow start, but there has been plenty of time to build such a rich and interesting set of characters and world. I'm digging it.

• Sebastian is really close to crawling. He can plank forever, and gets straight on to his knees when I put him down.
• I've been working from a co-working space in Weston Creek for the last few months. Several times a week, the bus's MyWay+ reader is borked, which means a free fare in to work — and usually a free fare home too! I do feel for the folks who have to maintain the system, and I just hope this wasn't a case of ship the thing before it's ready because we have to hit some unrealistic deadline (though I bet that was it).
• I have given up on Skull and Bones — I think I did 3 different mission types in the 10 hours I played. It feels very odd that you can dress up your pirate, you can walk them around in a town, explore islands with them — but that's it? Would have been cool to have some level of combat. Maybe some cool caves to explore on an island, or some stakes when boarding an enemy ship. Oh well — it was very pretty, and if its live-service-ness sustains it, then maybe I'll check back in in a year or two and see what kind of pirate-shenanigans I can get up to.
• Most of my game time is now back on Diablo IV. It was free on PSN this month, so I'm back in with a new Season 9 character. It's kinda nice playing it on a machine that can consistently push 60 FPS (the Mac does most of the time, but also gets kinda warm). I am also keen to see how the couch co-op goes!
• I went to the NMA this weekend for a free community day at the discovery centre. Sebastian loved it! There were so many new things to touch and see, new faces to smile at too! I think he got a bit frustrated (or overwhelmed) after a while though as there was so much to look at, and so many new noises that we bailed after about 45 mins. The centre itself looks pretty neat! I just wish it had more natural light — even I was feeling the effects of the artificial lights after our time there!

• 3rd and final short week in a row this week 😅 who knows how I am going to go with working 5 day weeks after all this! I had been working half-ish days on Sundays over those 3 weeks to do some maintenance things at work, so kinda balances out, I guess.
• I have been using the watch and iOS 26 betas over the last week or so. I knew going in they would be super rough (and they are). I am super interested to see how they polish this release, which parts they dial back, which parts they pull. Life is also too short to not play with the cool things (even if they are half baked), the battery drain and sluggish performance will be long forgotten by the time GM 1 comes around. The glass material is really nice, but I am way more drawn to it than the content it is over. Maybe that will fade when it is no longer new and interesting, but right now, I am spending way too much time slowly moving content below the buttons to see the effects of the material.
• I started Crumpet on seisure medication a couple of weeks back because her seisures were becoming more and more frequent (one every 5 weeks or so). It has been a while now, and she has been faring pretty well. She hasn’t had any of the side effects of the medication which is heartening and her liver function seems to have remained the same.
• Sebastian has started saying “mama” and “baba” which melts my heart every damn time. I am not sure how much intention there is behind it at 8 months, but if I go to him / pay attention to him whenever he says it, maybe that’ll build a link?

• The last 3 weekends have been long weekends for me. Reconciliation Day, The King's Birthday (still weird to write) and some time in lieu (still hard to write). Who knows how I will cope going back to 5 day weeks 😂. Granted, I was working each of the Sundays so it kinda worked out well.
• Winter is well and truly here. We've had to put on the big heater because the small space heater was struggling to keep the room within 5 degrees of its setting. Cranking it to 22, but shivering in 17 degrees is no way to live! Though, nor is paying stupidly high gas bills.
• Our new house has been insulated ready to be plastered. I took a walk through and even with a bunch of holes still, it feels incredibly cosy and sound proof. Double glazed windows that actually seal do wonders. Who knew. Let's see how it goes in the Canberra winter!
• WWDC was on earlier this week. I always look forward to this time of year. The excitement of new Apple things is still strong in this one, but, for some reason this year's WWDC felt just a little off. I am not sure if it was the underlying environment that Apple is operating in. Or if a new UI being the headline thing isn't as exciting. Nevertheless, I was mad enough to install beta 1 on my phone and reealllly like the Liquid Glass UI (even if it is buggy AF at the moment). I am excited to see what they do with it.
• Sebastian got his first tooth this week — on the lower left. We'll see how he goes chomping food now (we might need to be more vigilant if he can break off chunks of things 😆). Also, must be weird to have a bottom tooth but no top teeth to stop you from biting your gums.

• No public holidays or long weekends this week ;)
• My dishwasher kicked the bucket over the previous weekend. This meany washing dishes by hand and trying everything under the sun to bring “Dishy” (as it’s known) back to life. The error code I got from the machine was super unhelpful — it could have been one of; the hose is too high, too low, or has a kink in it. After several attempts at trying to get the hose at the right level and several runs that sounded promising, Dishy was still in the dishwasher afterlife. At this point, I was so close to calling a plumber — but maybe just a few more tries. Yesterday morning I sent some vinegar and bicarbonate down the drain and wiggled the drain pipe furiously and much to my surprise, I heard the drain-gurgle or life! Dishy lives! And now think of all the things I can get it to wash!
• Finished Split Fiction last night. What a joyfully imaginative game that was. The platforming was challenging but doable, the boss fights were more a test of memory than skill, and the story was not there to be taken seriously. Each vignette of the main game was really well thought out — none of them felt like the same thing just re-skinned as sci-fi or fantasy. Even the side quests were super fun and playful. But the ending sequence was the icing on top. Both a technical work of art and a delightful time. 100% would recommend especially if playing local co-op.
• Speaking of finishing things, I finished reading Hardboiled Wonderland and the End Of The World this week. Only my 2nd book by Haruki Murakami, but two things stand out. His prose is so easy to read, and (maybe this ship has sailed) he needs an editor that knows how to write female characters. In general, it was a really fun read. Many authors have written dream sequences that are hammed up to feel like a dream, but the End Of The World sections of the book put them all to shame. It’s such a natural an effortless dream-like world. That said, once I kinda knew where things were going, this was the section I skimmed through to get back to the action and exposition in Hardboiled Wonderland. All in all the story was a fun exploration of the conscious and subconscious mind, asking some interesting questions and not leaving everything tied off neatly. I might have to revisit this one again in a few years.

class MyThing
  def call
    data = list.reduce({}) { |data, option|
      data.merge(option.id.to_s => option.value)
    }
  end
end

def measure
  start = Time.now
  x = GC.stat :total_allocated_objects
  yield
  end_time = Time.now
  [GC.stat(:total_allocated_objects) - x, end_time - start]
end

class MyTest
  def call
    big_list = 20_000.times.map do
      OpenStruct.new(id: Random.rand(10_000), value: "Option #{Random.rand(10_000)}")
    end

    measure {
      data = big_list.reduce({}) { |data, option|
        data.merge(option.id => option.value)
      }
    }
  end
end
# => [60,004, 1.134663]

class MyTest
  def call
    big_list = 20_000.times.map do
      OpenStruct.new(id: Random.rand(10_000), value: "Option #{Random.rand(10_000)}")
    end

    measure {
      data = big_list.each_with_object({}) { |option, data|
        data[option.id] = option.value
      }
    }
  end
end

# => [3, 0.029746]

Projects

• Since March, we've been renovating our new house. In the early days this took the form of me going in and removing many of the fixtures that we didn't want anymore (carpets, wardrobes, cabinets). But then quickly grew in scope as we discovered things like lead paint in the walls and no insulation in anything! So as most projects go, we estimated a few months™ to get it all done, but we are just now getting the framing for the new bits in (and it looks amazing).

  

  

• I also built a small (now retired) Rails project to watch any RSS feed and publish new entries to anywhere else around the web (like Mastodon, Bluesky, as a webhook, or as a HTTP call). I mainly wanted to see what Rails was like in 2024 — I'll save you the project, it's still hard to break free of the Rails Way, but things like Stimulus and Turbo are nice additions.
• To help my partner stay on top of her ever-growing sewing pattern collection, I built her PatternMate. It really only does the things she wants and works how she does with pattern organisation, but we figured there's likely at least one other person out there that works the same, so it might be of benefit to release it — and we avoid the 90 day ticking clock of internal TestFlight releases!
• Lastly, over the last few weeks, I have been rebuilding the backend of my blog (the one you're reading now) with the plans of making it available to the public as grouse.site! Thankfully, Hanami 2 has made this super easy. I can just pull out the core slice and build an admin UI and any public facing template bits around it! The main thrust around keeping the site compatible with the micropub spec, is that I really like writing in markdown for a number of reasons. I have a local backup, and I can use whichever native writing tool that I feel like. But I still wanted a stellar admin UI to be able to make smaller edits, or write shorter-form posts. Anyway, there will be a more detailed post on this in the future, so stay tuned!

Media

• Dune: Part Two — Who doesn't love a good space opera?
• The Boy and the Heron — The latest (and last?) from Hayao Miyazaki. This has all the trappings of a Ghibli film — ✅ World war, ✅ quaint rural setting, ✅ sick / dead mother, ✅✅✅ a heartwarming story that is beautifully animated and told.
• The Iron Claw — technically a 2023 release, but we only got around to watching it a few months ago, and it needs to be called out. You'll laugh, you'll cry, it'll change your life.

Work

Family

Late in October, we welcomed Sebastian in to our lives, and he has been a napping, smiling, farting pile of joy since then! The ~3am wake-ups are all worth it when you get to see this mug staring back at you.

I had initially planned to take leave from his due date (of 21 November) until Jan 6 '25, but due to complications and his early arrival, I have been off since October 29, which has been amazing. After 4 weeks, I was struggling to see how I would have gone back to work and been available to support Abby as we work things out (without dying of lack of sleep). So I'm glad that I did get ~2 months of leave to be able to really help set a foundation for our routines in his first few months. Also, it's been a joy watching him grow every day!

Misc

Today's puzzle was about deciphering reports, to determine if each level in the report is deemed safe.

A safe "level" is on that each number in the row increases or decreases only, and only by a maximum of 3.

Link to puzzle

Part 1

In the first part, we needed to work out how many levels were safe.

E.g. given:

7 6 4 2 1
1 2 7 8 9
9 7 6 2 1
1 3 2 4 5
8 6 4 4 1
1 3 6 7 9

Only the first and last reports are safe as they're the only ones that follow the 2 rules.

A simple enough solution for this one:

def part1(input)
    input.map do |line|
      dir = nil
      vals = line.split(" ").each_cons(2).map do |first, second|
        next_dir = if Integer(first) > Integer(second)
          :increase
        elsif Integer(first) < Integer(second)
          :decrease
        else
          :no_change
        end
        dir = next_dir if dir.nil?
        (Integer(first) - Integer(second)).abs > 3 || dir != next_dir
      end

      vals.all?(false) ? 1 : 0
    end.sum
  end

First, mapping over each line, checking items in pairs of 2 and checking if we're constantly increasing or decreasing, or if we're stepping in increments greater than 3.

⭐️ Success! Albeit a little verbose!

Part 2

The second part was tricky!

My solution to the first part wasn't really flexible enough to accommodate the second part, so a rewrite was required.

In part 2, we learned that some levels can be made safe, by removing an entry in the level. I totally misread this, and thought that only otherwise unsafe entries could be removed. So made a number of wrong entries before realising that any entry could be removed to make the level safe.

So here's my brute-force attempt after banging my head against it for a bit:

def part2(input)
  input.count { |levels|
    levels = levels.split(" ")
    safe?(levels) || safe_by_removing_level?(levels)
  }
end

def safe?(report_result)
  res = report_result.each_cons(2).map do |first, second|
    if Integer(first) < Integer(second) && Integer(second) - Integer(first) <= 3
      :increase
    elsif Integer(first) > Integer(second) && Integer(first) - Integer(second) <= 3
      :decrease
    else
      :bad_step
    end
  end

  res.all? { |x| x == :increase } || res.all? { |x| x == :decrease }
end

def safe_by_removing_level?(report)
  0.upto(report.size).find do |i|
    sub = report.dup
    sub.delete_at(i)
    safe?(sub)
  end
end

This time, we still check that every level is safe, but if it's not, we then remove one entry from the level at a time to see if it would be safe.

⭐️ Success!

Performance

Even though this was brute-forced, it still performed OK. Though each level only had ~6 entries to loop through, so not a huge set of data to work with.

day 02
├─ part 1 — 0.002105s
╰─ part 2 — 0.008360s

Day two: https://github.com/dNitza/advent-of-code/tree/main/2024/02

3 4
4 3
2 5
1 3
3 9
3 3

list = {left: [], right: []}
    input
      .map { |line| line.split(" ") }
      .each_with_object(list) { |item, memo|
        memo[:left] << Integer(item[0])
        memo[:right] << Integer(item[1])
      }
    sorted_left = list[:left].sort
    sorted_right = list[:right].sort

    sorted_left.each_with_index.map do |left, idx|
      [left, sorted_right[idx]].sort.reverse.inject(:-)
    end.inject(:+)
lang-ruby

list = {left: [], right: []}
    input
      .map { |line| line.split(" ") }
      .each_with_object(list) { |item, memo|
        memo[:left] << Integer(item[0])
        memo[:right] << Integer(item[1])
      }

right_frequency = list[:right].tally

list[:left].map do |left|
      (right_frequency[left] || 0) * left
    end.inject(:+)
lang-ruby

day 01
├─ part 1 — 0.000542s
╰─ part 2 — 0.000324s

Check if an index is still being created.

The following should return something if an index is still being created on another process.

SELECT 
  a.datname, 
  l.relation::regclass, 
  l.transactionid, 
  l.mode, 
  l.GRANTED, 
  a.usename, 
  a.query, 
  a.query_start, 
  age(now(), a.query_start) AS "age", 
  a.pid 
FROM pg_stat_activity a 
JOIN pg_locks l 
ON l.pid = a.pid
WHERE mode = 'ShareUpdateExclusiveLock' 
ORDER BY a.query_start

If the result is empty (and the index still isn't there), then it's likely that the index creation failed.

Check for invalid indexes in pg_index

SELECT * 
FROM pg_class, pg_index 
WHERE pg_index.indisvalid = false 
  AND pg_index.indexrelid = pg_class.oid;

This might return something like:

| oid | relname | relnamespace | .... | 
|-----|---------|--------------|------| 
| 123 | my_index| 1234 | .... |

In this case, you can tell postgres to reindex this index to make it valid:

REINDEX INDEX CONCURRENTLY my_index;

Docs: https://www.postgresql.org/docs/current/sql-reindex.html

Some solid takes on the common use-cases for AI "stuff". It's refreshing to see some well thought out use cases for generative AI that don't result in lifting the output and passing it off as ones own.

More of an AI mentor or colleague than an assistant.

Take aways —

1. Wouldn't it be awesome if AI could use its context to ask leading questions to help us think more deeply about something?
2. If AI does generate something (especially text) that is useful or good, cite it as such.
3. Ask AI to be the critic of your writing that humans can sometimes shy away from — but then challenge what it suggests.

Critical thinking can be a practice that is easily lost without regular use. Offloading it to AI would be a terrible way to give up the opportunity to grow and reflect.

Best : Boiled Frogs

First : Accidents

Favourite : Happiness by the Kilowatt — inspired by the Euphio Question by Kurt Vonnegut, this song is an absolute journey. Best experienced live, but a live recording is also solid.

Instead of Safari

I have been trying Arc out. I love the sense of style it has. You can paint the darn thing any colour you want and it's just so much fun! Which is an odd thing to praise a browser for, but so much of our software has lost its whimsy in an effort to appeal to as many people as possible. There are some other neat things, too. Like, you can split view multiple tabs directly in the browser. I've found this useful for reading the orange website, and opening comments on posts next to the post itself. The last thing that I will call out, is the tab system. I didn't think I'd dig tabs in the sidebar, but now I don't really notice them. Arc's command palette is so good that I rarely every look to the left to pick a tab, not when I can hit a shortcut and quickly type a few letters. Oh, and you can set tabs to close after a given period of time. I've set my "close tab" timeout to its max, as I generally do close tabs I am no longer actually using and keep things open that I actually go back to.

Instead of LaunchBar

I've been trying out Raycast. I had minimally extended LaunchBar with my own extensions over the last, checks notes, 9 years! Mainly for things like opening certain apps, and creating shortcuts to search carious websites. In all cases, LaunchBar was a wrapper around an AppleScript, so thankfully, these were a cinch to port over to Raycast. So far the other things that Raycast has going for it over LaunchBar are a bunch more builtin extensions (for things like searching screenshots, and window management), as well as being able to do some handy things with numbers and conversions. Also, just before I switch to Raycast, LaunchBar was doing some weird things with its index. It would constantly want to open up a file instead of Apple Music, or take me in to an iCloud directory for an app instead of opening the app itself. I ended up disabling files and folders from the index to rectify this, but that was an annoying bandaid to have to place.

Web frameworks

Ok, this one's a bit of a gimme because I use Rails almost every day at work, but it has been a long time since I have started a new Rails project with all the modern trimmings. I think the last time I did that, was Rails 5? I have to say, Rails has come a long way since then. I still don't love the MVC pattern or ActiveRecord, and Stimulus is still a bit too magical (especially as compared to ViewLoader, Defo or Alpine / HTMX), but my little side project did come together very quickly. Though, now I want to port it to Hanami 2 😉.

Instead of iTerm2

I've been trying Alacritty out. And, well it works really nicely, it doesn't have a million and one options, but so far that's working out well for me! I really only used the theming / font settings anyway, so we'll see how continued use goes and if anything comes up as a deal breaker of a feature.

We usually expect some flake in our suite, as it's gigantic, and it's not impossible to write a test that doesn't completely isolate its state. Usually how this presents, though, is one spec failing sporadically so it's easy to know which file is the culprit and thus easy to fix the problem.

The last few days were different, though. Instead of the same spec failing, we saw multiple different and unrelated specs failing. Well, unrelated in that they were all in different parts of our application, but they all failed in the same way! Some string value we expected to be there, was nil!

But why? What was causing this behaviour in our specs? We also observed that sometimes, we just got lucky, and our suite passed without issue. So it was looking more definite that the order of our specs had a big part to play in the flake.

Enter rspec --bisect.

RSpec can be run with an additional flag, which, (when given a failing group of specs), will work out the smallest sets of specs needed to reproduce the failure. This can then be run locally, and with some educated guessing or trial and error, be used to narrow down what state may be leaking between specs.

If you notice flake in your CI/CD pipeline, you should be able to take the exact specs that were run and retry those with --bisect.

For example, if something like this is run on CI: bin/rspec foo_spec.rb bar_spec.rb baz_spec.rb

It can be updated to the following to run in bisect mode. bin/rspec --bisect foo_spec.rb bar_spec.rb baz_spec.rb

If successful, something like the following should be printed: bar_spec.rb[1:2] foo_spec.rb[1:1]

If the specs above are run in the order printed, a failure should consistently present itself. The numbers in the square brackets are the index or path of the specs that are run in each file — so [1:2] would be the second spec in the first group.

In our case, the tests that were failing were all Rails controller specs. We also rely on some I18n magic to persist a user's preferred language between requests (once set). A new controller spec had been introduced that must have been the first to exercise this logic - or at least exercise the logic without cleaning up its state. And so, where we were expecting some strings to exist in one language, they were coming back as nil, because they were not present for the language being leaked between specs. 🙌🏽

(Ignore the unreads — I will reply to them at some point!)

• Obsidian is a staple, notes used to be my go to, but I've found so much more utility with Obsidian.
• A couple of shortcuts for posting to this blog
• And of course Ivory and NetNewsWire!

The action looked something like this:

class MyAction < Action
    before_action :some_validation

    def handle(req, res)
        event_id = req.params[:event_id]
        ticket_id = req.params[:ticket_id]

        # do things with params here
    end

    private

    def some_validation(req, res)
        body = req.body.read
        request_url = "..."
        # compare the SHA of body + some other things against a header in the request
    end
end

Generally, the approach I would take for testing an action like this is to create a new instance of the action, and then call it with some params.

let(:subject) { MyAction.new }

it "works" do
    subject.call({event_id: "123", ticket_id: "246"})
end

However, that doesn't exactly work when trying to read the body off the request.

When calling req.body.read, we get no method read error for nil.

To get that to work, we need to call the action with an object that loosely resembles the env object of a Rack request, specifically an object with a rack.input key. This is what Rack uses to build the request body.

For example:

params = StringIO.new(JSON.generate({event_id: "123", ticket_id: "246"}))

subject.call({"rack.input" => params})

Success! req.body.read is now accessible in our action under test!

1. Sans Soleil by Alexisonfire — 25 Scrobbles
2. Sweet Dreams of Otherness by Alexisonfire — 18 Scrobbles
3. Following Eyes by Soccer Mommy — 18 Scrobbles
4. Bones by Soccer Mommy — 16 Scrobbles
5. Blue Spade by Alexisonfire — 15 Scrobbles
6. Stillness (Way Beyond) — 14 Scrobbles
7. Boiled Frogs by Alexisonfire — 12 Scrobbles
8. Conditional Love by Alexisonfire — 12 Scrobbles
9. Dark Night of the Soul — 12 Scrobbles
10. Happiness by the Kilowatt — 12 Scrobbles

    

1. TUNIC (Original Game Soundtrack) by Lifeformed — 144 Scrobbles
2. RARITIES by Lorn — 143 Scrobbles
3. Otherness by Alexisonfire — 123 Scrobbles
4. Sometimes, Forever by Soccer Mommy — 119 Scrobbles
5. Nothing Else by Lorn — 78 Scrobbles
6. Crisis by Alexisonfore — 66 Scrobbles
7. Diplomatic Immunity by Client Liaison — 64 Scrobbles
8. Carnavas by Silversun Pickups — 56 Scrobbles
9. One Step More You Die by Mono — 55 Scrobbles
10. Ask The Dust by Lorn — 53 Scrobbles

    

1. Lorn
2. Alexisonfore
3. Silversun Pickups
4. Lifeformed
5. Soccer Mommy
6. The Mars Volta
7. King Gizzard & The Lizard Wizard — this one should have been higher, but so many albums weren't in my library.
8. City and Colour
9. GUNSHIP
10. Wilco

    

11. Alternative
12. Rock
13. Indie Rock
14. Post Hardcore
15. Indie

    

In this puzzle, we're using our trusty Oasis And Sand Instability Sensor — OASIS — to analyse our surroundings.

The OASIS produces a history for each value, and we need to extrapolate the next value from the current set of values.

Part 1

Our input looks like this:

0 3 6 9 12 15
1 3 6 10 15 21
10 13 16 21 30 45

Each row represents the history of a value, with the earliest entry on the left.

The way we extrapolate a value is by finding the difference between the first and second values, the second and third, and so on. This will produce another set of values — this set will be 1 shorter than the initial set. We then repeat the process on the new set until all values are zero.

This is how the above process can be visualised.

0 3 6 9 12 15
  3 3 3 3 3
    0 0 0 0

Once we're at this stage, we can (starting from the array of all 0s), add the last element of the last array to the last element of the previous array until we're back at the top — the result will be the extrapolated item.

So in the above example, 0 + 3 = 3, 3 + 15 = 18, 18 is our extrapolated value.

def part1(input)  
  extrapolated_values = input.map do |line|  
    nums = [line.split(" ").map(&:to_i)]  

    while !nums.last.all?(&:zero?) do  
      nums << next_in_series(nums)  
    end  

    nums.reverse.inject(0) do |sum, numbers|  
      sum + numbers.last  
    end  
  end  
  extrapolated_values.sum  
end

def next_in_series(numbers)  
  numbers.last.map.with_index(1) do |n, i|  
    next if i+1 > numbers.last.count  

    numbers.last[i] - n  
  end.compact  
end

Here's all my code for the above algorithm.

The first piece maps over our input, creates the first set of numbers [[0, 3, 6, 9, 12, 15]], then, while the last set of numbers isn't all 0, calculates the next set.

Then, starting from the array of 0s, it adds the last number of each array to the next until we loop through each item and come up with our next number in the set!

⭐️ Success!

Part 2

Part 2 asked us to extrapolate in the other direction — what's the number that comes before 0 in this case?

Once we get that number for each row, we can again sum everything up.

This was almost identical to part 1, except the starting set of numbers is reversed:

nums = [line.split(" ").map(&:to_i).reverse]

⭐️ Success!

Code: https://github.com/dNitza/advent-of-code/tree/main/2023/09

Performance

Pretty snappy today — I was looking to see if there were any extrapolation algorithms that could reduce the time here, but my searching didn't produce much.

day 09
├─ part 1 — 0.003131s
╰─ part 2 — 0.00299s

Today's puzzle had us navigating a sandstorm. Our map, a set of directions, through what looked like a graph.

Starting at AAA, we want to get to ZZZ following the R, then L item each iteration — starting from R again if we've landed on a node that is not ZZZ.

RL

AAA = (BBB, CCC)
BBB = (DDD, EEE)
CCC = (ZZZ, GGG)
DDD = (DDD, DDD)
EEE = (EEE, EEE)
GGG = (GGG, GGG)
ZZZ = (ZZZ, ZZZ)

Part 1

Given the above input, if we start at AAA, then follow the right-most node, we land on CCC. From CCC , we need to follow the left-most node, which happens to be ZZZ. So we're able to complete this in 2 steps.

Our puzzle's test input does have needing to restart the loop of directions, as the first pass only gets us to BBB, but a 2nd pass gets us to ZZZ.

LLR  

AAA = (BBB, BBB)  
BBB = (AAA, ZZZ)  
ZZZ = (ZZZ, ZZZ)

This puzzle has graphs written all over it. I didn't build a full graph class, but a tiny implementation using a Hash:

def build_graph(nodes)  
  nodes.each do |text_node|  
    node, left, right = text_node.scan(/(\w{3})/).flatten  

    insert_node(node)  
    add_edge(node, left)  
    add_edge(node, right)  
  end  
end  

def insert_node(node)  
  @nodes[node] = []  
end  

def add_edge(node1, node2)  
  @nodes[node1] << node2  
end  

def neighbors(node)  
  @nodes[node]  
end

Then, we can prepare our graph from the puzzle input like so:

@nodes = {}  

directions = input[0]  

text_nodes = input.slice(2..-1)  

build_graph(text_nodes)

This results in something like from our test input:

{
  "AAA"=>["BBB", "BBB"], 
  "BBB"=>["AAA", "ZZZ"], 
  "ZZZ"=>["ZZZ", "ZZZ"]
}

With the 0th element being the left, and the 1st being the right.

Next, we want to loop over our directions until we land on ZZZ.

current_node = "AAA"  
hops = 0

while current_node != "ZZZ" do  
  directions.chars.each do |direction|  
    current_node = direction == "L" ? neighbors(current_node)[0] : neighbors(current_node)[1]  
    hops += 1  
  end  
end

hops

To do this, we take each character, and find the next node based on if the character is an L or an R. We then repeat infinitely or until we land on ZZZ, incrementing the number of hops with each loop.

This gets us our first star!

⭐️ Success!

Part 2

Again, we take a closer look at our input.

This time, we find out that its meant for ghosts! And since ghosts don't follow any rules of physics, they're able to traverse multiple paths at once. What we want to know now is, starting from all nodes ending in A , and travelling to the next node simultaneously, how many moves would need to be made before our ecoplasmic friends landed on all nodes ending in Z.

This one seemed too easy, like there would be a gotcha waiting for us the moment we tried to run it.

I adjusted my solution slightly to start with current_nodes (all nodes ending in A) and map over them all, progressing the list of current nodes, then checking if all nodes ended in Z.

Tests passed, first try — woo!

But the puzzle calculation was running for a while, and it kept running. I stopped it, added some logging to print the number of moves, and started again. For 10 mins, it was running, and got to a count of ~450,000,000. At this point I stopped and decided to rethink my solution.

In theory, once a ghost starts at say 11A, and ends on 22Z, the length of that path is known. When we start our loop again, we start at the start of our direction list, even if we ended on 22Z part way through our direction list.

So, given our test input:

LR  

11A = (11B, XXX)  
11B = (XXX, 11Z)  
11Z = (11B, XXX)  
22A = (22B, XXX)  
22B = (22C, 22C)  
22C = (22Z, 22Z)  
22Z = (22B, 22B)  
XXX = (XXX, XXX)

11A -> L -> 11B -> R -> 11Z (2)22A -> L -> 22B -> R -> 22C -> L -> 22Z (3)

We find that following directions from 11A gets us to a node ending with Z in 2 steps, and starting at 22A gets us to a node ending with Z in 3 steps.

If we were to look at multiples for these numbers, we would find they intersect at 6:

2: 2, 4, 6, 8, ...
3: 3, 6, 9, 12, ...

This should mean that we would need to make 6 steps through our graph with each ghost to have them land on 11Z and 22Z at the same time. Let's try it!

11AL -> 11BR -> 11Z 11AL -> 11BR -> 11Z11AL -> 11BR -> 11Z (6)

22AL -> 22BR -> 22CL -> 22Z 22AL -> 22BR -> 22CL -> 22Z (6)

Maybe better visualised with an image:

So now, instead of praying that we land on nodes ending with Z all at once, we can instead perform 6 calculations through from A to Z (6 because in my starting input, there are 6 nodes that end with A), and then find the lowest common multiple amongst them all.

The setup is the same as part 1, so this is all that needs to change:

total_hops = start_nodes.map do |node|  
  hops = 0  

  while !node.end_with?("Z") do  
    directions.chars.each do |direction|  
      node = direction == "L" ? neighbors(node)[0] : neighbors(node)[1]  
      hops += 1  
    end  
  end  
  hops  
end  

total_hops.inject do |sum, number|  
  sum * number / sum.gcd(number)  
end

1. loop through each of the starting nodes, counting the hops until we land on a node ending with Z
2. find the lowest comment multiple, by using the greatest common divisor

⭐️ Success!

Code: https://github.com/dNitza/advent-of-code/tree/main/2023/08

Performance

In doing some googling to see if I could speed up the lowest common multiple bit, I found that Ruby has a built in lowest common multiple method, which yielded almost identical performance.

day 08
├─ part 1 — 0.002344s
├─ part 2 — 0.012820s
╰─ part 2 (ruby lcm) — 0.012787s

Camel cards are like poker. But simpler, so you can play it while on a camel.

The hand-rules are similar to Poker, but with a few changes — which is ace, because I have no idea what the poker rules are anymore.

Five of a kind, where all five cards have the same label: AAAAA

Four of a kind, where four cards have the same label and one card has a different label: AA8AA

Full house, where three cards have the same label, and the remaining two cards share a different label: 23332

Three of a kind, where three cards have the same label, and the remaining two cards are each different from any other card in the hand: TTT98

Two pair, where two cards share one label, two other cards share a second label, and the remaining card has a third label: 23432

One pair, where two cards share one label, and the other three cards have a different label from the pair and each other: A23A4

High card, where all cards' labels are distinct: 23456

The hands are also ranked by suit, in descending order where an ace is high.

Part 1

In part 1, we have the following input:

32T3K 765
T55J5 684
KK677 28
KTJJT 220
QQQJA 483

Where the right hand column is the bid amount for the hand.

Our job is to sort each hand, and then multiply each hand's bid with its rank.

So if we take the order above as an example — we'd have 765 * 1 + 684 * 2 + ...

I started off this puzzle by assigning a suit / card number a letter (easier to sort alphabetically than numerically in this case):

ORDER = {"A" => "a", "K" => "b", "Q" => "c", "J" => "d", "T" => "e", "9" => "f", "8" => "g", "7" => "h", "6" => "i", "5" => "j", "4" => "k", "3" => "l", "2" => "m"}.freeze

Then turned the input in to an array of arrays that looked like [[hand, bid], ...] , sorted the list and then went to work adding up each bid:

rounds = input.map { |l| l.split(" ") }  
sorted_rounds = rounds  
                  .sort {|a,b| [hand_type(a[0]), hand_value(b[0])] <=> [hand_type(b[0]), hand_value(a[0])] }  
sorted_rounds  
  .map  
  .with_index(1) {|r, idx| r[1].to_i * idx }  
  .sum

To find the type of hand I was looking at, I used the below 2 methods.

First, I turned the hand in to a hash with the number of cards of each type. So for an input of K3558 I would have {K => 1, 3 => 1, 5 => 2, 8 => 1}. Then, I take the values and sort them — in to something like [2,1,1,1].

This is then passed in to the score_hand method which returns a rank based on the hand.

def hand_type(hand)  
  cards = hand.gsub(/(.)\0*/).to_a  
  sorted_cards = cards.tally.values.sort {|a,b| b <=> a}  
  score_hand(sorted_cards)  
end

def score_hand(cards)  
  return 6 if cards == [5]  
  return 5 if cards == [4,1]  
  return 4 if cards == [3,2]  
  return 3 if cards == [3,1,1]  
  return 2 if cards == [2,2,1]  
  return 1 if cards == [2,1,1,1]  
  return 0 if cards == [1,1,1,1,1]  
end

Lastly, we need to sort cards that have the same type based on the order of the cards in hand.

For this, sorting alphabetically was was simpler than zipping each array and comparing card values.

For this, I took a look at the ORDER constant and turned a hand like K3558 to bljjg, so when compared with another hand that has the same type, say K3448 (bliig), the first hand wins.

def hand_value(hand)  
  hand.gsub(/(.)\0*/).map{ |v| ORDER[v] }.join("")  
end

Part 2

In part 2, Jacks are out, Jokers are in.

Jokers are the lowest scoring card, but they can be used as a wildcard to improve a hand to one of a better quality. So for example, the hand 33JJ8 goes from being two of a kind [33, JJ] to four of a kind [3333]!

Because Jokers are now worthless, I have a new order for them:

IMPROVED_ORDER = {"A" => "a", "K" => "b", "Q" => "c", "T" => "d", "9" => "e", "8" => "f", "7" => "g", "6" => "h", "5" => "i", "4" => "j", "3" => "k", "2" => "l", "J" => "m"}.freeze

The code for part 2 and part 1 is pretty much the same, except I try and improve each hand when sorting:

rounds = input  
           .map { |l| l.split(" ") }  
sorted_rounds = rounds  
                  .sort {|a,b| [improve_hand(a[0]), improved_hand_value(b[0])] <=> [improve_hand(b[0]), improved_hand_value(a[0])] }  
sorted_rounds  
  .map  
  .with_index(1) {|r, idx| r[1].to_i * idx }  
  .sum

I try and improve each hand with the method below. I do the same tallying of each hand.

So 33JJ8 becomes {3 => 2, J => 2, 8 => 1}.

But then I take any J cards and add them to whichever card type has the most already.

So now, the tally looks like {3 => 4, 8 => 1} — which makes this a 4 of a kind.

Thankfully Jokers only improve hand quality, not overall score, so we didn't need to consider hands like KQKQJ and QKQKJ and apply the Joker to the King in order to get a better overall score.

def improve_hand(hand)  
  cards = hand.gsub(/(.)\0*/).to_a  
  return hand_type(hand) unless cards.any? { |c| c == "J" }  
  return hand_type(hand) if cards.all? { |c| c == "J" }  

  card_types = cards.tally  
  improve_by = card_types["J"]  
  type_to_improve = type_to_improve(card_types)  
  card_types[type_to_improve] += improve_by if improve_by && type_to_improve  
  card_types.delete("J")  
  sorted_cards = card_types.values.sort {|a,b| b <=> a}  

  score_hand(sorted_cards)  
end  

def type_to_improve(cards)  
  return nil if cards.empty?  
  no_jack = cards.reject{|k,v| k == "J" }  
  return nil if no_jack.empty?  
  no_jack.max_by{|_,v| v}[0]  
end

⭐️ Success!

Day 7: https://github.com/dNitza/advent-of-code/blob/main/2023/07/lib/puzzle.rb

Performance

day 07
├─ part 1 — 0.073877s
╰─ part 2 — 0.101986s

Today's puzzle has us racing boats. But not any boats, toy boats that are wound up with the hold of a button. The longer the button is held, the higher their speed. So holding the button for 3ms, sends the boat off at 3mm/s, 4ms sends the boat off at 4mm/s and so on.

Part 1

There are 3 races to be sailed, for each race we have a maximum number of milliseconds for the race. The race starts when the button to wind up the boat is pressed down, and the time it's held for counts towards the total time.

Our goal is to work out how many ways we can win each race, and multiply the results.

Time: 7 15 30
Distance: 9 40 200

For instance, the first race can be won by folding the button down for 2ms, giving the boat a speed of 2mm/s, which means it will travel for 10mm over 5s. 3ms, gives a speed of 3mm/s over 4s, resulting in a distance of 12mm and so on, for a total of 4 possible winning scenarios.

races = input.map { |l| l.scan(/\d+/).map(&:to_i) }  
races = races[0].zip(races[1])  

wins = {}  
races.each_with_object(wins) do |race, memo|  
  (0...(race[0]).round).each do |time_held|  
    wins[race[1]] ||= 0  
    memo[race[1]] +=1 if time_held * (race[0] - time_held) > race[1]  
  end  
end

This is my code for part 1.

We first build up an array of [[time, distance], ...] then for each race, we check the time we hold the button for incrementally to see if the speed of the boat (the time we've held the button for) is greater than the target distance when speed is multiplied by the time remaining in the race. Then, multiply the scores.

⭐️ Success!

Part 2

As usual with part 2, it's caused by us not reading the input properly the first time! In part 2, we realise that the race times we saw are actually poorly kerned, and it is actually a single race!

So now our time and distance look like this:

Time: 71530
Distance: 940200

In this part, we just need to work out how many times we can win the race.

race = input.map { |l| l.scan(/\d+/).inject(:+) }.map(&:to_i)  

(0...(race[0])).map do |time_held|  
  if time_held * (race[0] - time_held) > race[1]  
    1  
  else  
    0  
  end  
end.inject(:+)

Here's a super simple pass at it, using exactly the same logic as before. I did try and speed it up by only checking half the total time, because it looked like once you reached a maximum at the half-way mark, the rest of the numbers would mirror the first half of the range, but I was off by 1 in a couple of cases, and wanted to move on to day 7, so left it for now.

⭐️ Success!

Performance

day 06
├─ part 1 — 0.000040s
╰─ part 2 — 2.095320s

Part 2, not super fast, but no time to make any improvements!

A classic entry for AoC, in which there is a brute-force option that will melt any CPU.

Today's puzzle was fun! But also frustrating.

The setup is you need to work out the best place to plant some seeds.

Part 1

In part 1, we have a map that looks like:

seeds: 79 14 55 13

seed-to-soil map:
50 98 2
52 50 48

soil-to-fertilizer map:
0 15 37
37 52 2
39 0 15

fertilizer-to-water map:
49 53 8
0 11 42
42 0 7
57 7 4

water-to-light map:
88 18 7
18 25 70

light-to-temperature map:
45 77 23
81 45 19
68 64 13

temperature-to-humidity map:
0 69 1
1 0 69

humidity-to-location map:
60 56 37
56 93 4

Where each seed maps to some soil, soil to fertilizer, fertilizer to water and so on, until you reach a location.

The location with the lowest number is the closest, and we're tasked with finding the lowest location! The mapping is super convoluted, and probably best read in full here: https://adventofcode.com/2023/day/5#part1

This was the body of my code for the first part:

seeds = input  
          .first  
          .gsub("seeds: ", "")  
          .split(" ")  
          .map(&:to_i)  

seeds_to_soil = get_map(input: input, name: "seed-to-soil map:")  
soil_to_fert = get_map(input: input, name: "soil-to-fertilizer map:")  
fert_to_water = get_map(input: input, name: "fertilizer-to-water map:")  
water_to_light = get_map(input: input, name: "water-to-light map:")  
light_to_temp = get_map(input: input, name: "light-to-temperature map:")  
temp_to_humidity = get_map(input: input, name: "temperature-to-humidity map:")  
humidity_to_location = get_map(input: input, name: "humidity-to-location map:")  

closest_seed = seeds.map do |seed|  
  sts = resolve_map(val: seed, target: seeds_to_soil)  
  stf = resolve_map(val: sts, target: soil_to_fert)  
  ftw = resolve_map(val: stf, target: fert_to_water)  
  wtl = resolve_map(val: ftw, target: water_to_light)  
  wtl = resolve_map(val: wtl, target: light_to_temp)  
  ltt = resolve_map(val: wtl, target: temp_to_humidity)  
  resolve_map(val: ltt, target: humidity_to_location)  
end.min  

closest_seed

First build a list of seed numbers, then build the map for each section, and finally resolve each map.

def get_map(input: ,name:)  
  seeds_to_soil_index = input.find_index(name)  

  maps = input[seeds_to_soil_index+1..-1].take_while {|v| v != ""}  

  maps.map do |map|  
    map.split(" ").map(&:to_i)  
  end.map do |map|  
    [[map[0], map[0]+map[2]], [map[1], map[1]+map[2]]]  
  end  
end

get_map constructs the source and destination maps for each section

def resolve_map(val:, target:)  
  match = target.detect { |t|  
    val >= t[1].first && val <= t[1].last  
  }

  match.nil? ? val : match[0].first + (val - match[1].first)  
end

resolve_map takes a value and a target map and works out if the value matches a location in that target map by working out the offset of the found item, and adding it to the location of the destination location. If no match is found, the value is passed through.

My first attempt of resolve_map used ranges, and found the index of the passed in val in the range of the destination map. For the test input, that was fine! But for the actual input, where the numbers are in the billions, it was not.

Anyway, this part worked nicely!

⭐️ Success!

Part 2

In part 2, instead of looking for the locations of a handful of seeds, we need to look for the location of hundreds of millions of seeds!

Safe to say that this solution didn't scale, and after leaving it run for 30 mins, it had barely progressed.

I have another idea, to reverse the lookup. That is, start with the lowest locations and see when we match a seed — then that'll be the result.

But that's enough computering for today, and this'll be a problem for future Dan.

🙅🏽‍♀️ No good!

Performance

Super snappy for part 1, stay tuned for part 2

Rehearsal ------------------------------------------
part 1
  0.000526 0.000009 0.000535 ( 0.000533)
--------------------------------- total: 0.000535sec

             user system total real
part 1
  0.000253 0.000002 0.000255 ( 0.000255)

Inspired by some folks at work, I decided to try and do this as functionally as possible.

Apparently there are some similarities with past puzzles, but I, for the life of me, cannot remember any of the puzzles of years past 😆.

Part 1

Today's puzzle revolved around scratch-and-win cards.

A card looks like this:

Card 1: 41 48 83 86 17 | 83 86 6 31 17 9 48 53
Card 2: 13 32 20 16 61 | 61 30 68 82 17 32 24 19
Card 3: 1 21 53 59 44 | 69 82 63 72 16 21 14 1
Card 4: 41 92 73 84 69 | 59 84 76 51 58 5 54 83
Card 5: 87 83 26 28 32 | 88 30 70 12 93 22 82 36
Card 6: 31 18 13 56 72 | 74 77 10 23 35 67 36 11

On the left of the pipe are your numbers, on the right, are numbers that have been chosen as winners. Your first winning number was worth 1 point, and each subsequent win would double your score.

So 4 wins would be (1 * 2 * 2 * 2) = 8

In part 1, we need to calculate the score of our card.

input  
  .map { |l|  
    l.gsub(/Card \d+[:]\s/, "")  
      .split("|")  
      .map{|v| v.split(" ")}  
  }  
  .map { |c|  
    c[0] & c[1]  
  }  
  .map { |c|  
    next 0 if c.count <= 0  
    1 * 2**(c.count-1)  
  }  
  .inject(:+)

That was my code for part 1.

First throw away the Card N: bits, then split my numbers from the winning numbers, and finally split both sides in to their own array.

Next, map over each pair and count the matches (n), then for each card, get the score 1 * 2^(n-1) and finally sum everything up!

⭐️ Success!

Part 2

Enter, recursion~

In this part, instead of winning points for a card, we win more cards!, which in turn win MORE cards — and so on until we're out of cards.

The ask this time? How many cards did we win in total.

First up a couple of functions to make this a bit nicer:

def play(cards, index)  
  @tally += 1

  cards  
    .slice(index + 1, wins(cards[index]))  
    .each_with_index do |_, idx|  
      play(cards, index + 1 + idx)  
    end  
end  

def wins(card)  
  (card[0] & card[1]).count  
end

play loops over all the cards we've won and plays each one, which then loops over all the cards they win and plays each one, which then loops ...

wins was just a convenience function for calculating wins.

Now we can do our tallying:

@tally = 0  
cards = input  
          .map { |l|  
            l.gsub(/Card \d+[:]\s/, "")  
             .split("|")  
             .map{|v| v.split(" ")}  
          }  

cards.each_with_index do |_, index|  
  play(cards, index)  
end  

@tally

First throw away all of the Cards: info and pre-process our cards in to the same shape as before, then, play each round.

After many SystemStackError: stack level too deep errors, I got there (always remember to increment your indices folks).

⭐️ Success!

Performance

This one was a good candidate for some perf gains.

Rehearsal ------------------------------------------
part 1
  0.001061 0.000019 0.001080 ( 0.001079)
part 2
 13.300407 0.015743 13.316150 ( 13.330276)
-------------------------------- total: 13.317230sec

             user system total real
part 1
  0.000637 0.000006 0.000643 ( 0.000644)
part 2
 13.554139 0.020912 13.575051 ( 13.608991)

The code above for part 2 was suuuuper slow. Clocking in at ~13s.

Rehearsal ------------------------------------------
part 1
  0.001129 0.000038 0.001167 ( 0.001173)
part 2
  2.834447 0.007401 2.841848 ( 2.845803)
--------------------------------- total: 2.843015sec

             user system total real
part 1
  0.000636 0.000003 0.000639 ( 0.000637)
part 2 
  2.838135 0.007346 2.845481 ( 2.849414)

After adding a super simple cache to wins, it shaved ~10s off the total time:

def wins(card_id, card)  
  @win_cache[card_id] ||= (card[0] & card[1]).count
end

Happy with that!

Day 4: https://github.com/dNitza/advent-of-code/tree/main/2023/04

Today's puzzle revolved around an ascii schematic and we were tasked with parsing it and finding adjacent elements in the map.

These ones always trip me up for some reason — and I think it's because I don't normally work with data structures where some elements are related, by space, to others.

Part 1

Here's our schematic:

467..114..
...*......
..35..633.
......#...
617*......
.....+.58.
..592.....
......755.
...$.*....
.664.598..

In this part, we need to find out how many numbers are directly adjacent to (horizontally, vertically and diagonally) to a symbol (. does not count). Those numbers then need to be summed up.

For this, I first built up a list of all the symbol positions on each line:

symbol_positions = {}  
input.each_with_index{ |l ,idx|  
  symbol_positions[idx] = []  
  l.enum_for(:scan, /[^a-zA-Z\d[.]:]/).each {  
    symbol_positions[idx] << Regexp.last_match.begin(0)  
  }  
}

This resulted in something like {0 => [], 1=> [3], ..., 8 => [3,5], ... }

Next, I needed the positions of each of the numbers:

number_positions = input  
                     .flat_map  
                     .each_with_index { |l, idx| l.enum_for(:scan, /\d+/).map { [idx, [Regexp.last_match.offset(0), Regexp.last_match.to_s.to_i]] } }

This resulted in an array like: [[0, [[0, 2], 467], [5,7], 114]], [1,[...]]] ([[line, [match_range, match]]])

Then, it was just a matter of working through that list of numbers to see if any had an adjacent symbol. Where an adjacent symbol is one that appears in the previous line, the same line, or the next line within the match_range of the number (increased by 1 each side to account for diagonals).

number_positions.map do |pos|  
  line = pos[0]  
  match_range = pos[1][0]  
  match = pos[1][1]  

  same_line = symbol_positions[line].any? { |pos| adjacent(match_range, pos) }  
  above = line < (input.count - 1) && symbol_positions[line + 1].any? { |pos| adjacent(match_range, pos) }  
  below = line > 0 && symbol_positions[line - 1].any? { |pos| adjacent(match_range, pos) }  

  match if same_line || above || below  
end.compact.inject(:+)

def adjacent(range, item)  
  (range[0] - 1...range[1] + 1).include? item  
end

I initially had the range defined as (min..max) and my tests passed, but he answer I submitted was not correct!

Cleaned that up and ⭐️ success!

Part 2

Part 2 drove me nuts!

The idea was simple. Given the same schematic, now only find "gears". Where a "gear" is a * symbol that has exactly 2 adjacent numbers. Multiply the two numbers for each gear, and sum the total.

I started this one off in a similar way, list all the potential gear positions and list all of the number positions.

Then, look over each potential position, and check if there is a number above, next to, or below it. What tripped my up though was my wahackadoo data structure above. I was trying to make today's effort a little simpler than yesterday's, but that meant it was trickier to debug and reason about as I was jumping between cooking dinner and this at the same time.

In the end, I got my tests passing — but oh no! my solution was too high?!

I had a look through the input data and found a "gear" that looked like:

.....755.. 
....*.....
.664.598..

Which was obviously incorrect as the * was adjacent to 3 numbers, when it's only allowed to be adjacent to exactly 2.

I started puts-ing out what my code thought was a gear and it returned [755, 664] and [755, 598] as 2 seperate gears!!

It turned out the bug was in how I was determining what numbers were around a *, and I was just taking the first — so when I checked to see if a gear had more than 3 numbers, I was missing the 3rd!

This is how that code ended up in the end:

gears = potential_gear_positions.flat_map do |line, positions|  
  positions.map do |gear|  

    lines = [  
      line < (input.count - 1) && number_positions[line + 1],  
      line > 0 && number_positions[line - 1],  
      number_positions[line]  
    ].compact  

    nums = lines  
             .flat_map { |l| l.select { |ll| adjacent(ll[0], gear) }.map(&:last) }  
             .flatten  
             .compact  

    next 0 if nums.count != 2  

    nums.inject(:*)  
  end  
end  

gears.inject(:+)

⭐️ Success! 🫠

The code: https://github.com/dNitza/advent-of-code/tree/main/2023/03

Performance:

Rehearsal ------------------------------------------
part 1 0.004141 0.000094 0.004235 ( 0.004255)
part 2 0.002621 0.000048 0.002669 ( 0.002673)
--------------------------------- total: 0.006904sec

             user system total real
part 1 0.003456 0.000042 0.003498 ( 0.003516)
part 2 0.002341 0.000022 0.002363 ( 0.002366)

The first iteration of this, was based on HTTP BasicAuth. To get this to work, I built a small module that uses Rack::Auth::Basic — https://github.com/rack/rack/blob/main/lib/rack/auth/basic.rb.

It looked like:

class AuthenticatedAdminAction  
  def self.call(action:)  

    action = ->(env) { Admin::Container["actions.#{action}"].(env) }  

    basic_auth_username = Hanami.app.settings.basic_auth_username
    basic_auth_password = Hanami.app.settings.basic_auth_password  

    if basic_auth_username && basic_auth_password
      Rack::Auth::Basic.new(action) do |username, password|  
        username == basic_auth_username &&  
          password == basic_auth_password  
      end  
    else      
        Rack::Auth::Basic.new(action_proc) { |_username, _password| true }  
    end  
  end

Then, on each path that I wanted to authenticate, I would adjust the to: argument call this method:

Auth = AuthenticatedAdminAction

get "/", to: Auth.call(action: "index")

Which looks nice, and works well! However, something changed in the way Safari on iOS and macOS handles auto-filling usernames and passwords for HTTP Basic Auth that meant it would log me out every few minutes and I would need to re-open 1Password to log back in!

I thought this may have been a beta-season thing (after seeing a few other cases of it online), so I stuck it out for a while. But after many months of being on a stable version of Sonoma, the problem persisted!

So, onwards with a more stable and scalable form of authentication. It didn't need to be fancy, it just needed to let me create a session with as little hassle as possible. For this reason, I didn't opt for something like OmniAuth or even Warden and instead built a simple token-based auth system that emails me a login link.

The above code changes slightly, to now call some custom middleware with the user in the session, but is now a zillion times more reliable as Safari doesn't seem to forget who I am every 2 seconds 🙃.

The middleware now looks something like:

module Middleware  
  class Authenticate  
    def initialize(app, auth_proc)  
      @app = app  
      @auth_proc = auth_proc  
    end  

    def call(env)  
      session = env["rack.session"]  
      return [403, {"Content-Type" => "text/html"}, ["Unauthorized | <a href=\"/admin/login\">Login</>"]] unless @auth_proc.call(session[:user_id])  

      @app.call(env)  
    end  
  endend

Next steps

The next thing I want to look at is wrapping a block of routes in an authentication block, e.g:

AuthenticatedThing.call do
  get "/pages", to: "pages.index"
  get "/pages/new", to: "pages.new"
  get "/pages/:slug/edit", to: "pages.edit"
end

mainly to make it easier to see which routes are authenticated and avoid accidentally missing some routes.

(at least until the rest of the end-of-year things start getting in the way — which normally happens at around day 6)

Started reading this one thinking we'd be getting in to probabilities — thankfully that's not the case, yet.

Part 1

For today's puzzle, we're given the following input:

Game 1: 3 blue, 4 red; 1 red, 2 green, 6 blue; 2 green  
Game 2: 1 blue, 2 green; 3 green, 4 blue, 1 red; 1 green, 1 blue  
Game 3: 8 green, 6 blue, 20 red; 5 blue, 4 red, 13 green; 5 green, 1 red  
Game 4: 1 green, 3 red, 6 blue; 3 green, 6 red; 3 green, 15 blue, 14 red  
Game 5: 6 red, 1 blue, 3 green; 2 blue, 1 red, 2 green

Each line, represents a game, and each segment (separated by a ;) represents a round in that game. Where, in each round, a set of cubes are pulled from a bag.

We're tasked with finding out, which games can be played with only the following cubes: 12 red cubes, 13 green cubes, and 14 blue cubes, then, sum the game number to find our answer.

For this one, I first wanted to add some structure to each game. Parsing each one in to a hash would then mean when I want to do some poking at each game, I could reason about each bit.

So for that, there's this method:

def build_games(input)  
  input.map do |line|  
    id = line.scan(/(\d+)[:]/).flatten.first.to_i  
    game = line.gsub("Game #{id}: ", "").split(";")  
    rounds = game.map do |reveal|  
      red = reveal.scan(/(\d+) red/).flatten.first&.to_i || 0  
      green = reveal.scan(/(\d+) green/).flatten.first&.to_i || 0  
      blue = reveal.scan(/(\d+) blue/).flatten.first&.to_i || 0  

      {  
        red: red,  
        green: green,  
        blue: blue  
      }  
    end  

    {  
      id: id,  
      rounds: rounds  
    }  
  end  
end

Which returns an array of games in the following shape:

game = {  
  id: 0,  
  rounds: [  
    red: 0,  
    green: 0,  
    blue: 0,  
  ]  
}

So then, it was just a matter of rejecting the games that exceeded our cube limit, and summing the IDs:

result = games.reject do |game|  
  game[:rounds].any? { |round|  
    round[:red] > 12 ||  
      round[:green] > 13 ||  
      round[:blue] > 14  
  }  
end  

result.map{|r| r[:id]}.inject(:+)

⭐️ Success!

Part 2

Thankfully, today's part 2 was free of gotchas!

In part 2, we need to work out what is the minimum number of balls we would need to be able to play each game. Then, multiply the number of balls for each colour, to get the power of the game. Sum all the powers, and that's our answer!

So for each game, we can work out the minimum number of required cubes with something like:

min_red = game[:rounds]  
            .map{|r| r[:red].zero? ? nil : r[:red] }  
            .compact  
            .max

for each cube colour (making sure to remove 0s so we don't multiply by 0).

N.B — this could have been solved by also making the number of cubes optional in our game hash.

Then it's just a matter of multiplying the cube counts, summing everything up and we're done for day 2!

⭐️ Success!

Day 2: https://github.com/dNitza/advent-of-code/tree/main/2023/02

Usually, I try and do it in a programming language I am not super familiar with, but this year I'm going to stick to Ruby (mainly because I am out of ideas for languages to try 😆).

Part 1

The first part was nice and simple. The challenge was to extract the first and last digits from each line, concatenate them in to a new number, and then sum the total.

E.g. given:

1abc2
pqr3stu8vwx
a1b2c3d4e5f
treb7uchet

The first line would be 12, the second 38 and so on, with the solution being 12 + 38 + ...

My solution was as follows

input.map{ |line|   
  matches = line.scan(/\d/)   
  Integer("#{matches[0]}#{matches[-1]}")   
}.inject(:+)

⭐️ Success!

Part 2

The second part was sneaky! Building on from the previous part, we're now tasked with including numbers that have been spelled out.

So for example, given:

two1nine  
4nineeightseven2

The first line would be 29 and the second would be 42.

Which seemed simple at first:

NUMBERS = {one: 1, two: 2, three: 3, four: 4, five: 5, six: 6, seven: 7, eight: 8, nine: 9}.freeze

num_pattern = NUMBERS.keys.join("|")  

input.map {|line|  
  matches = line.scan(/#{num_pattern}|\d/)  
  first = NUMBERS[matches[0].to_sym] || matches[0]  
  last = NUMBERS[matches[-1].to_sym] || matches[-1]  

  Integer("#{first}#{last}")  
}.inject(:+)

1. Search for either a digit, or the number-in-letters
2. Grab the first and last match (and if either is a number-in-letters, replace it with the digit)
3. Create a new integer and we're done!

I submitted my answer, and booo , too high!

My tests passed, what was I missing?

I threw in a bunch of puts in the above code and saw a line like the following:

pxxtd793frjfckbhstcdhsrx58mksktwoneqx

Which my code was resolving to 72, but should have been 71!

The issue was with the last section ktwoneqx, the regular expression I was using was was not looking ahead! So a quick change to use a positive lookahead and I was done!

The new pattern becomes: /(?=(#{num_pattern}|\d))/

⭐️ Success!

Day one: https://github.com/dNitza/advent-of-code/tree/main/2023/01

There's a pretty big gap between 2012 & 2017 — I am pretty sure I have photos of these, just Apple Photos was doing a bad job of surfacing them.

2011

2012

2017

2018

2019

2020

2022

2023

My previous attempts included: - WordPress; which was okay. Though it required typing in a handful of apps that could post to WordPress' XML-RPC endpoint, and, at the time, none of those apps had a writing experience that I liked. Unfortunately, I moved away from WordPress (for other reasons) by the time iA Writer and Ulysses came along. - Jekyll; which was probably the closest I got. This involved editing posts in a Dropbox folder that was kept in sync with my web server. Since Jekyll is a static site generator, all of the site's HTML needs to be regenerated every time a change occurs in order for that change to be made available to the public. This goes for new pages as well as changes to existing pages. So in practice, this means whenever a file is changed in Dropbox, something would need to tell Jekyll to regenerate the site. And this is where this attempt came unstuck. I wasn't able to get the regeneration process to work reliably, which meant that changes would sometimes never get picked up, requiring me to jump in to the server and manually build the site. - Ghost; this one never really took off with regard to publishing from an iPad. And it also suffered from something that was annoying me about Jekyll. It was somewhat inflexible out of the box, and to make it more flexible required putting in some work to update some of the template code. Which is fine, until the vendors of the base software publish a major update and then all of the edits required to make the site work, no longer work — meaning more work to get things back to normal.

Blogging ecosystem aside, there was also a lull in the capability of the software in the iPad ecosystem (both apps and iPadOS). This, however, has become less of an issue now that Obsidian exists for writing, and Shortcuts exists to patch many of the gaps in iPadOS. Which leads to where I am today.

This blog adheres to the Micropub spec, which means that most of the techniques below can be used with any blog that also follows the spec.

For text posts, everything is written in Obsidian. I then have a shortcut that accepts the post's body as markdown. This means I can share a document with the shortcut, fill in a title as well as any other metadata (like tags, location, publish time) and then send the request on its way to result in a brand new post on this site.

Things get a bit more involved for media posts. Right now, photos need to be uploaded to a special "media" endpoint before they can be used in a post. This endpoint accepts a file, and returns the URL of the uploaded piece of media (photo or video). So for this, I have a shortcut that accepts one or more photos (just photos for now), sends them to the media endpoint, and copies the URLs of all the uploaded photos to the clipboard. Pasting these in to Obsidian renders them, so I can see which photo is which and place them accordingly in the post.

Right now, I don't publish many videos (though I wanted to during a recent trip). So some upcoming changes to the media shortcut will allow the upload of videos (which the server supports). But I also want to be able to take a live photo with a loop effect, and upload that as a looping GIF / mp4.

I also have similar posts for specific post types (e.g. bookmarks, photo posts and the like).

So with a handful of shortcuts, publishing to this blog has finally become as simple as writing in a text editor that I really like, and then pressing a button or two. And since it's all done over HTTP, it's hopefully less likely to break with changes to iOS or iPadOS.

Over the last few weeks I have been putting together a small app to help Abby organise her collection of clothing patterns. The current method of organisation is AirTable, which, is incredibly powerful, but because if its flexibility, falls short in a couple of key places. The working name is "PatternMate" — largely because of TextMate and MailMate 😅.

So, together we sketched out a quick handful of screens and flows that would make organising patterns simpler and bypass some over the overhead of using a tool like AirTable. Some of which, I have included below:

One of the key use-cases for this app is to be able to quickly see if any patterns have a tag that fits with a fabric that is about to be purchased. So for example, some patterns are designed for fabrics that have some amount of stretch, while others can not tolerate any stretch. So, being able to tag and filter patterns, then quickly see how much fabric is required is a flow that I am paying particular attention to.

I've started a brand new app that targets iOS17 because I really like how SwiftData looks. After many years of trying to decipher CoreData (and often reaching for libraries that just wrap it instead), SwiftData looks like a really nice approach to persistence with SwiftUI. And so far? It has been really nice! There are a couple of bugs that I have run in to, but the API and developer experience are top notch so far.

The bugs I am running in to so far: - A crash when trying to load a Model's attribute that has ben annotated with @Attribute(.externalStorage). This is meant to store the contents of the field on disk, next to the DB, which is useful for things like storing image data. So for the moment, I am loading an image from a hardcoded URL in place of an image loaded from disk. - The app hanging and a memory leak whenever I try and load a query that has a variable in it (the example below works when I replace tag.name with a hardcoded string)

let predicate = #Predicate<Pattern> { $0.tags.contains { t in
  t.name == tag.name
} }

_patterns = Query(filter: predicate, sort: \.name)

But previews have largely meant that I can still work, just running the app in a simulator or on device and trying to visit these screens is a no-go for now. Here's hoping that Xcode 15 beta 6 addresses some of these.

One of the other things I have been looking at is Apple's "vision" APIs. In particular VNRecognizeTextRequest, which lets you pull out bits of text from a photo, then run some custom filtering to pick things that might be interesting to you. So in this case, I am checking the text of a scanned packet to try and grab the designer's name and pattern number to pre-fill them and streamline the pattern adding process. That scan will then be used as the pattern's image, so a step most people will hopefully find useful.

WIP early screens:

How do I work out what methods are available on a class?

The methods method lets you see which methods an class defines. This is useful when working with an un-documented or otherwise unknown class, but have an idea of what you might want to achieve. The return value of this call is an array of symbols that represent method names.

Foo.methods #=> [:bar, :baz, ...]

If you run this yourself on a class, you'll see a huge list of method names, including things like :new, :==, :inspect. This is is because method also returns a list of methods that the ancestors of your object respond to. If you want to clean up this you can:

Pass the false argument in to methods:

Foo.methods(false) => [:bar, :baz]

Or selectively remove the methods of known ancestors from the resulting output:

Foo.methods - Object.methods => [:bar, :baz]

There is also the instance_methods method that does the same thing, but only returns instance methods.

The following calls are almost the same:

Foo.new.methods #=> includes methods that belong to ancestors

Foo.instance_methods(false)

Ok cool, now we have an idea of the methods, but what about actually calling them?

The parameters method lets you take a peak at the arguments required to call a method. This is not always bulletproof, as some methods take a variable number of args (e.g. def foo(*args))

Anyway, once we have a method to inspect, we can use parameters like so:

class Foo
    def bar(one:, two:)
    end

    def baz(one, two = nil, three: nil)
    end
end

Foo.instance_method(:bar).parameters #=> [[:keyreq, :one], [:keyreq, :two]]

Foo.instance_method(:baz) #=> [[:req, :one], [:opt, :two], [:key, :three]]

You can even see if a method has a default provided (:key, :opt), or is required (:req, :keyreq) along with its name.

Workout where a method is defined.

Sometimes, you're calling a method and the behaviour being presented is not at all what you expect, or even worse, your myriad of puts and raise calls you've put in place to debug the behaviour are not being called!

Here's an example:

# source/foo.rb

class Foo
    def bar(arg)
        raise "here".inspect
        # do the method here
    end
end

Foo.new.bar(arg) #=> Nothing is raised 😱

Inspecting the bar method with source_location should help work out what is going on here:

Foo.instance_method(:bar).source_location #=> ['some_monkey_patch.rb']

In our case here, we can see that something else is being called instead of our method in our class! While this exact example is not super common, I have been bitten by this a couple of times by some gems implementing a to_h, to_json, to_s etc. method on basic Ruby classes that then cause unexpected behaviour.

Another variation of this is when you have a super-class that is calling super in its initialiser (or some other place) but you don't know where that goes.

class Foo < Bar
    def call
        puts method(:call).super_method.source_location #=> ['/gems/path/bar.rb#42']
        # super
    end
end

You can then use something like cat in the terminal to inspect the file and get a sense of what Bar's super method will call.

Or better than cat, you can use bundle open to dig around a gem with your editor of choice (discussed in the next section).

Inspecting a Gem

Sometimes, the code you're having trouble with is in a gem! There are a couple of ways to go about inspecting this code. If the code is hosted on Github, then that's a fairly simple way of spelunking through code, with the benefit of having commit messages right there that could explain the behaviour you're seeing (just make sure you're looking at the right version).

But, you can also use bundle open gemname to have bundler open the correct version of the gem in your EDITOR of choice. From here, you can throw in debugging statements, make changes, and even fix a bug or two if you find any :)

If you're spelunking has lead you to drop puts statements through many files, you can clean the gem up quickly with gem pristine gemname (or gem pristine --all if your debugging journey spanned multiple gems!).

How did we get here?

We've discussed working out where a method call will take us, but what about how we got to a particular method.

For this, we can use caller. caller will print out a massive stack trace showing you how we got here, but the first line is the one that really matters:

class Foo
    def bar
        caller
    end
end

irb(main):072:0> Foo.new.bar #=> ["(irb):72:in `<top (required)>'","/Users/danielnitsikopoulos/.asdf/installs/ruby/3.2.0/lib/ruby/3.2.0/irb/workspace.rb:119:in `eval'", ...]

in this case, I'm running the code in irb, so (irb):72 is where this is being called from.

Formatting

The last thing I want to touch on, is how to do some basic formatting to make inspecting output a little easier.

Add some markers to split puts calls, especially when calling something in a loop:

def foo
    puts "Doing something:"
    do_something
    puts "*" * 88 # print out 88 stars
end

2.times { foo } #=>

Doing something:
****************************************************************************************
Doing something:
****************************************************************************************

When looking through a collection of data to understand something about it, also print out things like IDs so that you can pick out the one you want:

some_collection.map {|c| [c.id, c.name] } #=>
[
  [123, "foo"],
  [234, "bar"],
  [345, "baz"],
  ...
]

Conclusion

Ruby's built in meta programming tools are super powerful, and while there are definitely a bunch more techniques for debugging, these are the ones I always turn to first and usually are all I need to work out what is happening. I will (one day) get RubyMine's built in debugger working and report back if it blows any of this out of the water :D

Writing documentation

Almost any piece of documentation I write for work starts its life in Obsidian. I have a vault just for work docs that doesn't get synchronised and lives on my work computer, but means I can write outlines and drafts out and publish a doc when it's ready. Not to mention having a local backup in case Confluence decides to crash and lose my work — though, to be fair, this is happening a lot less lately.

Daily notes and to-do lists

This is where Obsidian really shines in my opinion. I used to use Taskpaper for plain text daily to-do lists. And by daily to-do lists, I mean a single long list that I would keep adding things to / checking things off from. While this was kind of neat in the sense that I have a historic list of all things I've don, the method for organising those to-do items was a bit unwieldy. Each day I would need to tag an item with @today if I wanted it to be visible in the "today" view. Booo 👎🏼.

Obsidian has a built in concept of a "Daily Note". Right from the command palette, you can "open today's daily note" and if there isn't one, Obsidian will offer to make one for you. Of course, where this note is saved and its filename is customisable. But the cool thing is, you can also install a plugin to create a daily note from a template!

My daily note template is as follows: - A created at timestamp - A tag of "Daily Notes" - A section for a to-do list - A section for notes, tagged with #daily_note (more on why in a bit).

created: <% tp.file.creation_date() %>
---
tags:: [[+Daily Notes]]

---

##### ✅ To do
- [] 

---
# 📝 Notes
- <% tp.file.cursor() %>

#daily_note

So now, whenever a daily note is created, it's labeled with the day's date and the cursor is placed in the notes section, ready to go.

There is one more plugin I use though, to make this setup really work for me. And that is a plugin to roll-over any to-dos from the previous daily note to today. This way I still have the history of what was done when, but not all the clutter or manual work of tagging when a task should appear.

So when I first log in for the day, I'll usually open the day's daily note and clean up whatever to-do items are rolling over, add any new for the day and then be good to go!

Plugins to make this happen: - Templater- Rollover Daily Todos- Calendar is also nice. It adds a calendar to the sidebar so you can jump to any daily note, without having to search.

Reviewing daily notes

I mentioned that I have a #daily_note tag in the notes section itself. The reason for this is that every 6 months or so at work, performance review season rolls around. And, in what I am calling a weird coincidence, every 6 months or so I wish I had taken notes about what I had done for the previous 6 months. This is where the daily note tag comes in. My mate Mike put me on to another plugin called Dataview which basically lets you query your Obsidian vault. He also shared with me this script (below) that will search for notes in a folder with a given tag, and then pull the notes in to a view broken down by month and year.

So now, whenever I am taking notes in meetings, or when I am puzzling something out, I throw a #daily_note on the end of important lines and violà, a prompt and a fighting chance of remembering what I did in the last 6 months.

// get daily notes pages
let pages = dv.pages('"Daily Notes" and #daily_note').sort(p => p.file.cday)

// group pages by year
let years = pages.groupBy(p => p.file.cday.toFormat("yyyy"))

// for each year...
years.forEach(year => {
    // add a header
    dv.header(3, year.key)

    // group by month
    let months = year.rows.groupBy(y => y.file.cday.toFormat("MMMM"))

    // for each month...
    months.forEach(month => {
        // add a table with the month name as header
        // and each item for that month in the body
        let file = month.rows.file
        dv.table(
            [month.key], 
            file.
                lists
                .where(item => !item.task)
                .map(item => ["- " + item.text]))
    })
})

Writing these posts

I also use Obsidian for writing my weekly posts and posts like this one! While I wish it had better Micropub support, I make do with a Ruby script that pulls in Jekyll-like markdown files and converts them to the JSON that Micropub expects.

Ruby Koans

https://www.rubykoans.com

This is my go to recommendation for learning the Ruby language from scratch. You'll complete a number of exercises in the form of tests. Your goal is to get each test to pass by writing Ruby code. As with most $language Koans library, it starts off very easy and then ramps up in complexity.

The Odin Project

https://www.theodinproject.com

Specifically the Ruby portion of the "Full Stack Ruby on Rails" course. This course covers off almost all of the basics that you would need to be productive with Ruby in a project that isn't super complex.

Ruby Weekly

https://rubyweekly.com

One of the joys of the Ruby world is that someone is coming out with a Cool New Thing™ almost all the time. This can be hard to keep track of, and I have found Ruby Weekly a great resource to keep on top of all of the happenings in the world of Ruby. There are similar newsletters from the same publisher for other languages, too.

Ruby Tapas

https://www.rubytapas.com

These timeless videos from Avdi Grimm illustrate the why behind a lot design patterns we employ every day, using real examples to help solidify the benefit of following these patterns.

Blogs

• Piotr Solnica
• Sandi Metz's blog
• Schneems
• Tenderlove making
• Thoughtbot's blog
• Tim Riley

Podcasts

• The Bike Shed — Out of thoughtbot, general developer experience, challenges and joys, usually covering Ruby and Javascript.
• The Ruby on Rails Podcast — A weekly chat about Ruby on Rails, OSS and programming in general. Though not always about Rails specifically.

Talks

Boundaries

Garry Bernhardt — Watch

Thinking about the boundaries of and within systems can be tricky for new programmers. This talk does an excellent job of introducing the topic and providing concrete examples to take with you throughout your career.

Y Not- Adventures in Functional Programming

Jim Weirich — Watch

A detailed introduction to functional programming with Ruby, via first principles of lambda calculus.

Refactoring Ruby with Monads

Tom Stuart — Watch

Dealing with unwieldy code using monads to help simplify presence or absence of data in our apps.

All the Little Things

Sandi Metz — Watch

Another journey through a hairy refactoring, this talk takes an ugly section of conditional code and converts it into a few simple objects. It bridges the gap between OO theory and practice and teaches straightforward strategies that all can use to improve their code. Also, checkout Sandi's book at Practical Object-Oriented Design, An Agile Primer Using Ruby.

Getting setup

After you've setup an account on fly.io and have installed the command line app, you can then follow the docs for setting up a Ruby app.

While running through the fly launch setup, you should get the option to setup a Postgres database. If you do, the URL will be available as an environment variable in DATABASE_URL.

Once fly launch has completed, you should have a new fly.toml file in the root of your project.

Before deploying your application, you'll need to make a couple of changes specific to Hanami 2.0. The fly.toml below is where I landed in terms config for a small, simple app. The biggest changes from the generated file are as follows:

• on deploy, defines a release command to run database migrations (at the time of writing, migrations are not in Hanami 2.0 by default)
• defines the web process as  bundle exec puma -C config/puma.rb
• sets the Hanami environment
• configures the processes to run (as ["web"]) and the internal port to listen on

Deployment

Once you've filled out your fly.toml, you can run fly deploy to send your first build to fly.io.

If you're familiar with Heroku, there's a similar build and deploy log on fly.io. Though I have found it to be not as detailed as Heroku, it has been enough to surface any config errors and correct them, so keep an eye on it as it'll surface any obvious issues.

Once your deploy is working, you likely wont need to change anything for a little while, so, if you're hosting your code on Github, you can setup an action to build and deploy on a successful build.

An example GitHub action to build and deploy a Hanami 2.0 to fly.io

To achieve this, I am using chezmoi and GitHub to keep an up to date snapshot of my dotfiles. My previous tool of choice for managing dotfiles was rcm, but chezmoi offers things like password manager integration, scripts, and templates to customise dotfiles based on the machine I am setting up, making it just that little bit more useful.

The initial setup of chezmoi is super straightforward:

chezmoi init
chezmoi add ~/.my-first-file

chezmoi cd
# follow your usual git workflow to add a remote and push

Then, to pull down and apply your dotfiles on another machine, run:

chezmoi init --apply $github_username

From here, the workflow of adding and updating files is essentially: - Edit the source file on your machine - Then, chezmoi add ~/.file to commit and push to GitHub

The chezmoi FAQ lists a couple of other ways you can keep a file in sync, including chezmoi edit and chezmoi merge, but I have found add to be the simplest.

Chezmoi also makes it simple to run scripts when you run chezmoi apply.

You can decide whether a script is run_once_ when you first run chezmoi apply, or run_onchange_, which will run every time, provided the file has changed.

The scripts I have at the time of writing are:

• run_once_00_install-xcode-devtools — Does what it says on the tin, installs Xcode's devtools
• run_once_01_install_homebrew — Installs Homebrew if it's not already installed
• run_onchange_after_brew-bundle — To run brew bundle whenever the Brewfile changes
• run_onchange_after_configure-macos — To configure a bunch of macOS and LaunchBar defaults.

Having a look through the chezmoi docs, you'll see there's a bunch more you can configure to meet your specific requirements, but hopefully this has provided a brief insight in to what is possible, and how easy it is to get started with a simple setup.

Once the initial setup is done, the day-to-day to maintain your dot files will look like this:

SSH keys

My SSH keys are the one thing that are not managed by chezmoi. For that I make use of 1Password. All my keys are stored in its vault and are then made available to the ssh-agent via 1Password's ssh agent integration. This makes it super easy to generate a bunch of keys for different services rather than using a single key for everything.

What my chezmoi setup achieves

macOS Setup

As a long-time computer user, my ideal macOS configuration is comprised of years of small tweaks here and there. Once set, those tweaks are normally forgotten until such time as I get a new machine, or use someone else's computer 😅.

Some of the highlights include: - Installing Xcode's command line tools - Installing Homebrew as well as all of my Homebrew packages - Finder config: - Disable transparency - Disable window animation - Show hidden files by default - Set window title to full POSIX file path of current folder - When performing a search, search the current folder by default - Disable the warning when changing a file extension - Show the ~/Library folder - Mail.app: - Copy an email address as hello@example.com instead of Hello <hello@example.com> - Shell - Set Fish as the default shell

Config

Fish:

• Set git aliases
• Set default prompt as starship

• Set a bunch of other aliases (including 2 to fix some of macOS's flakier processes)

• Install default gems

• Setup IRB

General

• Set a global tool-version file for Mise
• Remap a couple of keys with Karabiner:
  • Caps Lock to delete
  • Switch option and command on my non-Apple keyboard

My chosen theme was the Metal Gear series, so naturally, the drive was named Solid Snake, and my MacBook was Roy Campbell. Fast forward a couple years and now the lineup looks like:

• MacBook Pro — Zero
  
• AirPods — Sigint
• iPad — Shalashaska
• iPhone — Fortune
• Watch — Volgin
• HomePod mini — Quiet
• TV — Otacon
• Wifi — Outer Haven
• And then I have a room light and a lamp named Olga and Sunny respectively :)
• ... as well as a previous iPhone and AirPods pairing of Ground Control and Major Tom (which were the only ones to break the theme).

The only annoying thing is that Air Drop shows the device name as a destination (which makes sense), but doesn't show who owns the device. A solution to this would be to leave everything as "Daniel's Whatever " — but where is the fun in that.

*computer nerds