I am soooo freaking rusty. Maybe if I was using Python, it wouldn't be so obvious. But flipping between regex and general flow, albeit without a good iterative process because I'm using a low/no code platform instead of Python [which includes restrictions around RegEx so my speedy match required some unintuitive reworking], requires more attention than I expected. I did find my flow a few times which was nice....management doesn't generally lend itself to finding that sweet spot.
My Day 2 solution...I think I could have done a better job by using a multi-row formula tool to look back and forward and apply it across the diffs, but this worked. Unfortunately....my approach meant that when I tried to build off of it for the second part, I was somewhat locked into a pattern that required some cut and paste. Pretty much the definition of tech debt and bad architecture.
Laughing is appropriate here... I had the basic pattern for how to exclude a value at a time from my ragged array in mind, but with the initial process I was using, it didn't lend itself to something dynamic. Instead, I just targeted each value with a separate process [yeah, it won't scale at all] and then eliminated the duplicates. Not as bad as it looks because it's mostly cut and paste. It reminded me of the ragged array Secret Santa Python I use once a year for family that excludes closest family and the last year or two of recipients. That's basically 24 lines of code...a double loop in Python would have been infinitely easier. But defeated the purpose. I did generate some product ideas while I was playing around with the layout, so probably worth the weird approach.
And Day 3, both part 1 and part 2. Part 1 was using some regex to extract a pattern and then parse it to multiply numbers. Part 2 was a little bit trickier because the pattern had to grab mixed start and end sections that determined whether to evaluate the numbers or not. That's the part where the Perl regex tripped me up. A bit of trial and error got it going eventually and then it was the same pattern/parsing as part 1, with the exception that I had to drop in a start and stop word at both ends of the document as my regex wasn't smart enough to deal with a start with no end.
No comments:
Post a Comment