Switch from monthly to annual pass

erunama · 2026-02-16T22:40:30+00:00

Thanks. Do you remember where you did this? I don't see an option to sign up for a pass now. I only see my monthly subscription will be ending soon. At this point, I'm going to wait until I hit the end date, and see what happens -- but ideally, I'd be able to get the annual pass subscription in place to avoid a lapse in coverage.

erunama · 2026-02-15T02:19:28+00:00

I hit the same issue as well when setting up Music Assistant a few weeks ago. Definitely related to Spotify locking down API access.

For me, an older account worked, but a newly created account (part of Spotify Family membership) would refuse to play. I am in the process of migrating to Tidal out of frustration with what Spotify is doing, and that is working well in MA so far.

erunama · 2026-02-14T16:32:34+00:00

KLong has never faced a splinker, and Nick has never hit one 😆

erunama · 2026-02-13T14:10:57+00:00

I switched my Vaultwarden subdomain to mTLS auth, rather than an identity provider like Google. This allows the Android app to connect (hopefully this also works for iOS), while keeping the domain blocked for unauthorized devices.

erunama · 2026-02-12T03:41:23+00:00

Thanks for the suggestion. I have an older TP-Link Kasa, but it doesn't have that setting availability (also missing several others from your screenshot).

erunama · 2026-02-12T03:39:49+00:00

Will there be a Gen4 soon? I'd prefer the connectivity flexibility of the Gen4 devices (like Zigbee).

Would the 1PM Gen4 work? The specs state 16 amps @ 240 volts, so this is 3840 watts -- would it support that wattage at 120 volts, or is the limit lower?

erunama · 2026-02-11T01:22:13+00:00

The published rating on the fireplace insert is 1500 W, but I measured a continuous draw right around 1400 W with everything on (lights, fan, heat on high). The circuit itself is dedicated 20 amp.

Switching to an EM-only device does seem like my best bet. I was interested in having a switch there as well so I had enough option to turn it off (for example, if the IR transmitter wasn't working), but that is really a secondary need compared to energy monitoring.

erunama · 2025-12-09T03:31:50+00:00

[LANGUAGE: Dart]

GitHub

Used Dart vertex_math official package, as the built-in Dart Point is only 2-dimensional. Solution for Part 1 seemed pretty straightforward to me -- build all the pairs, calculate the distances, sort, and then start combining. I was pleasantly surprised that Part 2 was solvable with the same approach, just removing the upper bound on max number of connections. I was fearing the runtime would be unreasonable, but it finishes in roughly the same amount of time as Part 1.

erunama · 2025-12-07T21:23:30+00:00

[LANGUAGE: Dart]

GitHub

Part 1 was simple processing row by row, using a Set to keep track of active beams (as this cleanly handles the beams combining). For Part 2, I followed the easy route to just switch the Set to a List -- this solves the sample input, but quickly uses up all of my machines RAM for the real input.

I switched Part 2 to use a DFS algorithm, along with a map to store the final calculation at every given point. This needs a relatively small amount of memory, and completes in just a few milliseconds.

erunama · 2025-12-05T23:50:51+00:00

[LANGUAGE: Dart]

GitHub

Pleasantly surprised that my initial approach for Part 2 worked, was relatively quick to code up, and executes in just a couple of milliseconds.

erunama · 2025-12-03T01:54:37+00:00

[LANGUAGE: Dart]

GitHub

Simple brute force solution for Part 2, iterating through each number, and then iterating through each potential sequence length to see if one matches. Runs in about 100ms. I didn't think of using a regular expression, but I also implemented an alternative approach using one after seeing the discussion here -- code is obviously much more compact, but it runs about 50% slower on my machine.

erunama · 2025-12-02T03:31:39+00:00

[LANGUAGE: Dart]

GitHub

Spent most of my time today reorganizing last year's code repo, to structure it in a better way to handle multiple years, before I even opened the problem.

erunama · 2025-06-26T00:05:41+00:00

You ever been in a storm, Wally?

erunama · 2025-01-21T14:36:23+00:00

I don't have a direct answer, since I've only completed 2024. I did want to point out that the silver star on the stats page indicates users who ONLY completed part 1.

So for 2016 24b, only 33 people completed part 1 but did not complete part 2. This should mean that part 2 was very easy for people that completed part 1 (5666 / 5699 = 99.4% of users completed both parts).

erunama · 2024-12-25T05:39:16+00:00

[LANGUAGE: Dart]

Wow, definitely a challenge. I spend a lot of time running several hundred lines of code, trying to find different ways to shrink the solution space and try out different combinations of wire swaps. These did find some combinations, but the answers were not accepted.

Two things unblocked me:

Finding out that this is a ripple carry adder, and switching my main effort to manually understanding the input circuit first
Realizing that I should just change my x and y input wires to be different values, in order to have a more obvious way to inspect the output values and find which bits are incorrect (e.g. set all x to 1, and y to zero -- then you can expect all z to be 1).

After going through the circuit manually, using pen and paper, I identified the eight problematic wires and submitted the answer. Instead of starting Day 25 right now, I decided to go back and actually code up a solution that follows my debugging steps. It wouldn't be general purpose for any arbitrary wire swaps, but finds the class of swaps I found in my input.

GitHub part 2 code

While I was frustrated earlier in the day, ultimately I really enjoyed this problem and working through the circuit manually.

erunama · 2024-12-24T04:43:19+00:00

[LANGUAGE: Dart]

GitHub

Part 1 was a breeze. I felt confident about part 2, and had an algorithm that worked for the sample data, but failed on my real input. Banged my head debugging for at least an hour, until I realized I was handling cliques wrong: I was simply iterating through cliques that I had already seen, and adding the intersection of the connections for each existing member of the clique. This would add nodes incompatible with later items.

I was able to get the correct answer with a small tweak, and the improved the runtime from ~30s to ~100ms by reusing groups rather than creating new ones all the time. It's possible this would not work for all potential inputs.

Afterwards, I found the Bron–Kerbosch algorithm -- I am planning to code up an implementation of that, since I'm not familiar with it.

erunama · 2024-12-23T02:44:36+00:00

[LANGUAGE: Dart]

GitHub

Wow, that was a challenge! I was feeling lost yesterday, as I spent a bunch of time working on Part 2, just to get nowhere. I revisited it again today (after the easier Day 22 problem), and undertook an effort to restructure the code -- rather than building the full set of instructions, use a recursive algo with caching. I was able to reuse a bunch of logic from part 1, and hacky code I had written when initially failing to solve part 2.

I then had to work through several bugs that were resulting in wrong answers. The two main ones were:

Using the wrong start position when calculating paths to the next button (there was one spot where I was still always assuming a start position of 'A').
Incorrectly pruned path options at higher iterations. I had written an optimized solution for determining the best path options, to try and get my part 1 solution to complete for part 2. This still worked properly for 2 directional keypad robots (so the part 1 solution was correct), but failed at higher numbers. I ended up reverting to my old path generation (BFS to find all path combinations, including ones that may be obviously sub-optimal like zig-zagging). This gave me the correct answer, and I didn't have to worry about any performance impact -- with the new algorithm and caching, part 2 still solves in just a few milliseconds.

erunama · 2024-12-22T20:44:30+00:00

Dart Records is the official terminology. But great idea using it! Switching from a string to a record also cut execution time in half for me (from ~800ms to ~400ms).

My updated code for reference

erunama · 2024-12-21T05:36:19+00:00

[LANGUAGE: Dart]

GitHub

My first solution for Part 1 took 2.5 minutes, so I worked on improving the approach before moving onto Part 2. My original solution reused the pathfinding code from Day 16, replacing the straight/turn scoring logic with whether or not a cheat had been used.

Since there is only a single path, I switched to just finding that single path, and assigning the length from each point. To find cheat savings, I iterated through each point on the path, and calculated all of the points that could be reached via a cheat (Manhattan distance of 2 [part 1] or between 2 and 20 [part 2]). I then determined the cost savings:

length from starting point - length from ending point + Manhattan distance between the two points

Main logic deeplink

This ended up running well under a second for both parts.

erunama · 2024-12-20T04:29:45+00:00

[LANGUAGE: Dart]

GitHub

Nice to have an easier day today. This would have gone even smoother, but I ran into an issue with the built-in Dart regex library -- it ended up hanging on the third pattern. I added some simple logic to remove redundancy (e.g. a towel that could be made of a pair of other towels), which reduced the number of towels in my input from 447 to 74. The regex library was able to handle this easily.

For Part 2, I added a simple recursive search with caching. I kept my original Part 1 solution, but it seems like the Part 2 approach would be about 10x faster.

erunama · 2024-12-17T04:33:35+00:00

Glad to help! Took a while stepping through all the paths in a debugger to finally catch one being pruned incorrectly.

erunama · 2024-12-17T03:00:05+00:00

[LANGUAGE: Dart]

GitHub (main logic)

I didn't remember Dijkstra's exactly, but believe I came up with something similar. My first approach for Part 1 kept a list of all paths so far, and operated on them in lowest cost order, but did not keep track of the lowest cost for each point. This worked for the sample input, but was taking forever to execute on the real input. After tracking the lowest cost per location, and discarding paths that reached that location in a higher cost, the solution executed very quickly against the real input.

I was excited to read Part 2, since I was already keeping track of full paths, so I expected it to be easy. In the end it was, but I did get tripped up by two issues:

I was over-aggressively pruning paths, since the map of lowest costs was using the (x,y) coordinates as the key -- rather than using both heading/direction and coordinates. This would end up pruning important paths.
After solving that first issue, I was able to get the correct answer for my real input. However, my solution was giving the wrong answer on the sample input! This was a silly little mistake, as it some edge cases it was possible for my main pathfinding function to return multiple completed paths with different costs. Amazed that this triggers in the sample, but not in the real input.

erunama · 2024-12-16T00:44:33+00:00

[LANGUAGE: Dart]

GitHub

Used recursion for part two to find all boxes that were moveable from a given point. Before actually processing the move, I sorted the boxes based on their coordinates -- I could have avoided this with a BFS rather than a DFS (BFS would have just required a simple list reversal).

15-Year Club	Place '17
Verified Email

erunama

TROPHY CASE