Zoe Aubert

2023 What happened with me?

Zoe Aubert | GeekyAubergine — Sat, 13 Jan 2024 00:00:00 +0000

This year has been a year of inward reflection and discovery. Content warning for discussions about mental health.

Laser Hair Removal & Transition

The big event this year saw me start laser hair removal. I've never really spoken about it before on the internet, but I'm trans. I've been out for five-ish years and have been presenting full-time for nearly as long.

I'm the kind of person who doesn't like to do things unless I am 100% certain. I will build a list of pros and cons and research things to a silly level to try and be as certain as possible. This is particularly true of "irreversible" things. I'm not sure why this is; I suspect some part of this is because I struggle to make even trivial decisions, and some part thanks to working with computers; nothing I do there is truly permanent and could be changed with enough effort.

As a result, I put off making actual progress with my transition beyond socially transitioning and changing my name. I would like to apportion some of this delay to the pandemic, which took away all of my momentum. I would also like to apportion some of the blame to apathy generated by the NHS's ridiculous waiting times. It's hard to be motivated when you know how long that list is.

Shaving

I am naturally quite a hairy person. I have thick, black hair all over my body. This is incompatible with how I want to look, so I had to remove it. This led to me shaving every patch of visible skin on my body. Thanks to the speed and darkness of my hair growth, I had to do this almost daily. This led to me needing to spend nearly an hour shaving my face, arms, and legs daily. If I did not do this, I felt I could not leave the house.

This daily shaving and inability to leave the house led to many problems. It's a massive time sink; I'd hate to think how many hours I lost standing in front of that mirror. This time cost had several effects, including causing fights with people over bathroom access and internal debates of "should I forego shaving my arms/legs and hate it or should I just be late to X?" if I was running slightly late.

I also found that if I left less than 20 hours between shaves, it hurt more, and I got a worse result. This often left me caught between a rock and a hard place, especially with more fluid plans. If there was any risk that I'd have to go outside the next day, I'd have to make sure today's session was timed not to hurt tomorrow. This often led me to not take part in things I wanted to because I didn't know I was going that day and hadn't timed the previous day to make it work. This made meeting people and making impromptu plans almost impossible.

All this shaving also had a surprisingly high cost. I estimate I was spending around £70 a month on shaving products alone. I know there are cheaper products available, but I used what worked for me. The make-up also costs a lot and still does, though hopefully that will stop soon.

The feeling that I had to do all this just to leave the house often caused me to procrastinate doing it and grow to hate doing it. This hate towards doing it got increasingly worse as the years went on. I found it increasingly "unfair" that I had to do all this just to feel able to go to the shop, whereas most other people could just get out of bed, slap on some clothes and go.

Laser

I'm not sure what finally tipped the scales, but I booked myself in for a laser hair removal appointment earlier this year. It was very nerve-wracking. I knew it was going to hurt, and I knew it was going to be expensive.

My consultation went surprisingly well. I had initially asked for a consult for my face, chest, arms and legs. After the initial test patches looked good, we got around to discussing what I wanted. The technician quickly worked out I was trying to optimise their pricing matrix and that I likely wanted everything, and made some suggestions. I am grateful to them as their matrix is vague, and between us, we managed to work out how to get everything I wanted as efficiently as possible.

Since then, I've had five sessions as of writing and couldn't be happier with my results. The first session wasn't fun, and I looked bad for days afterwards. I was expecting the red and dryness of the skin, but I was not expecting the hair to become and stay dark for a few days before it started falling out. The second session was the worst so far. It completely drained me of all my adrenaline and left me exhausted for a good day or so. Since then, it's been no worse, though I still wouldn't call it fun.

I am currently at the point where I still have to shave my face every day, but it's much faster, and the shadow is much easier to cover, to the point where I have to relearn my colour correction techniques after every session as they're too strong. The rest of my body is a sort of weekly affair, which is amazing.

If the progress continues as it is, then I estimate by summer, I should be at the point where it's just maintenance shaving, and I can leave the house without having to shave and put on make-up. A time I am very much looking forward to.

Feelings

Starting laser has left me feeling a number of different things, some good and some bad.

One thing I've always found hard to reconcile is the differences between me and some of my trans friends. For many of them, transition is their primary focus, and I get it, whereas I treat it more as "I need to get on and do it", almost as if it's some kind of boring admin task. I kind of wish I was more driven/focused about it, but I'm not.

This difference has led to me avoiding talking about things because I find it hard to explain why I took so long to start. As I mentioned previously, the fear of making the wrong decision is strong, but every time I have spoken about it, it led to awkward conversations about "what if I'm wrong?". Conversations that have in the past made me push back and delay further.

While this "what if I'm wrong?" question still lingers, I think my outlook has changed. So what if I'm ultimately wrong? These feelings aren't new and aren't going away. If doing X makes me happier, I should do it and just deal with the consequences later. I've dealt with the consequences of delaying it for a long enough time, any consequences that come will at least come from me doing the right thing for me.

This change in outlook has been good. It's left me more open to talking about things, which has been good. Previously, if people asked me things like "How did you cut your arm?" when I've nicked myself shaving or something, I would make up lies to get the question over quickly, but now I tend to tell people the truth, often leading to interesting and meaningful conversations.

Because I've started to make actual progress, it's brought up a lot of internal anger over not starting sooner. Silly feelings, I know, but they're there. However, this has made me push to progress more, so it's a double-edged sword. I hope to continue to use this as a force for good in the coming year and do everything I've been delaying.

Health

This year has been very neutral in terms of my health. I've not made much progress on getting healthier, but I also have not been less healthy. From Q3 onwards, I started doing weekly meal preps, which has helped a lot in saving me time and money and helped me make healthier choices. It turns out it's a lot easier to make sensible decisions once rather than six times a week when you are tired after work. There's still a long way to go in terms of both improving the quality and reducing the quantity of the meals, but I'm glad the habit has stuck as well as it has.

House

After buying my house last year, I started the year with having to get the roof fixed. I knew it was coming from the survey, but it was still a pain and expensive. But very glad to know it's done and dealt with. Since then, it's been a slow grind to get unpacked and more settled. There's still a lot to do to make this feel more like a home, but I'm getting there. It turns out that just keeping a house running is a lot more time-consuming than I imagined.

Programming

This year's been a weird one for me and programming. I came to the realisation that a lot of my self-worth is tied to my performance, specifically with programming, which leads to me being in a bit of a spiral of getting stuck and starting yet another project. This really came to the forefront when, in a discussion about unfinished projects, I calculated I have in the order of 70 unfinished projects.

Since coming to that realisation, I've stopped starting any new projects, and it's been a good change for me and has led to me having much more time for things I enjoy more. I discuss this more in the Advent of Code post.

Hackathons

Having never attended a hackathon before, I attended two this year.

The first was run by Hack Pompey and saw me teaming up with a number of my colleagues to make a game about a Norwegian shark barbarian. I wrote about in more detail here.

The second was a more private event that was run by a friend. The theme for this one was "Silly Interfaces". I did this one solo and created a mazed-based interface that you navigate by balancing your phone. I wrote about it here.

Advent of Code

This year, I tried Advent of Code for the first time. It started off well but ended up being really unhealthy for me, so I stopped.

Warhammer

Earlier this year, I finally settled on a colour scheme and lore for my Space Marines army. I then got the Leviathan box set and set about building it. I discuss more of this in my First games of Warhammer 40k post, but my goal last year was to paint and play a 1k points army. While I missed that goal, I'm still happy with my achievements. Hopefully, this year, now that I'm not spending ages faffing with finding a colour scheme, I might be able to paint a bit faster.

Lego

Over the summer, I started to make my way through my build queue. It was a lot of fun to get back into the hobby. I initially planned to display most of the models in my living room, but I vastly underestimated the size of some of the models. Fortunately, I have a room in my house that, while not suitable for a bedroom or office (it has no windows and was previously used as a walk-in wardrobe), makes a great Lego/Hobby room. After careful planning, I got a series of IKEA PAX wardrobe shells and shelves and made my own display cabinet. Why not IKEA Billy shelves? A few of the models I intend to buy are too deep for them (looking at you Rivendell).

Another bonus is that while this room is quite small, I have to walk past it to get to my office from the rest of the house, so I see them much more frequently than I would if it were in the living room.

Gaming

I resurrected my gaming pc this year. It had been out of commission since I moved house last year, mostly because the power supply had started making some concerning noises, and I didn't want to mess with it. I did put in a very good service for eight years, of which four of those saw it almost never being switched off.

Since rebuilding it and sorting out some new peripherals, it's been nice to be able to game with my friends again. I've particularly had a lot of fun playing Lethal Company. I'm not a fan of horror in general; things tend to replay in my head for weeks, and as my friends will attest, I'm very easy to make the jump. But this game is different, and I'm glad I took the risk; it has its scary moments, but really, it's a comedy.

Photography

The year started out strong with me going to see short-eared owls twice. I got very wet and very cold getting these photos, but they are fantastic. I'd never seen a shorted-eared owl before and only heard about them by luck.

After that though, I didn't really get much of a chance to visit my regular spots or events. I missed both the Jersey and Bournemouth air displays, and the few other times I did get out with a camera, I saw little of interest.

I did take some photos on my summer trip back to Jersey, but I still haven't processed or uploaded those photos yet 🙈.

Travel

London

After buying my French horn in late 2022, I came across some teething issues. While the manufacturer was very good and offered to collect and deliver the instrument while it was fixed for free, I took it as a good opportunity to do a day trip to London.

This was my first solo trip to London, and while it was a little daunting, I had a lot of fun. When I dropped my instrument off, they weren't sure how long it was going to take, so I thought it a good idea to stick near the tube. As a result, I ended up going to many of the large stations and having a great time. It's no secret that I love trains, and I am a fan of architecture, so this was a match made in heaven. I managed to get to St Pancras, Paddington and King's Cross before having to return, of which St Pancras is definitely my favourite.

After collecting my instrument, I then went and did some shopping. I started at the Warhammer shop (surprising, I know) but decided not to go in as it's huge, and there was no one else in there bar the staff. I then did the classic Primark, Hamleys and the Lego store. I managed to be relatively well-behaved and only bought some small things, including a lovely London bus.

Overall, I consider it a successful trip. I've always wanted to go to London on my own schedule, and I'm glad that this provided the opportunity, as I don't think I'd've done it otherwise.

Jersey

I went to Jersey twice this year, in both the summer and for Christmas. There's not a lot to say about the Christmas trip, but the summer one was interesting.

I haven't been to Jersey in the summer for a number of years. My family all work in education, so they have the summer off. This, combined with my brother and his girlfriend being away, led to a window where I could go over, and it be quieter than normal. I was very fortunate; the weather was practically perfect every day, if anything too good for someone who struggles with heat. I wouldn't say it was a relaxing holiday, but I did a lot of things.

The highlight of the trip (bar a silly number of bbq's) was the Battle of Flowers night parade. I haven't been to the Battle for a long time. The last time I went was probably about 15 years ago, and my parents even longer ago, so this was a treat for all of us.

As a quick tldr; The Battle of Flowers is an annual event held in Jersey where teams from various places on the island create a float using real and/or paper flowers. The floats are then brought to the main avenue in the early hours of the morning and featured in a parade. Then, the next night is the night parade, where the float gets illuminated and displayed again. A lot of fun comes from the fact the floats come from a wide range of skill levels and, more importantly, budgets. They can range from a small cart with wooden structures and paper flowers pulled by a freshly washed tractor to a custom-built 40-foot frame with an untold number of dyed real flowers.

The Battle is important to me and my Mum. When she was young, she helped with her local team for multiple years and has many stories about being up at silly hours to pick flowers, roping in family members to make paper flowers and sitting in still-wet glue on the float for the parade. When I was younger, a farm near me used to host a few teams, and I eventually joined one of the teams. I have fond memories of crawling around under and in their float, helping with the wiring work, getting covered in dirt, running home for a shower and then being tasked with folding a silly number of flowers.

I remember the Battle being good, but I heard rumours over the years of it slowly becoming worse, and that, combined with the knowledge that my memories are probably a little rosy, I was a little concerned it'd let us down. I was wrong. It was great. The atmosphere was great, the floats looked good, and overall, it was a very good time.

Extreme Robots

A friend and I went to see Extreme Robots in Guildford. We were both fans of Robot Wars, so we thought this would appeal to both of us. We paid extra for VIP tickets so we could go backstage and see the robots and competitors which was great. I knew the robots weren't small but they were surprisingly big. Overall I had a good time, though the whole event was a little on the expensive side and I'd be hesitant to do it again.

Reading

I read (listened to) 6 books this year, all Warhammer-related. After starting with a highly recommended Slaves to Darkness book, I then started the monumental task of reading the Horus Heresy series of books. So far, I've been surprised about how good they are and just how much I didn't know. I hope this trend continues.

Trains/Model Railways

Had two good train moments this year. I went to Southampton Model Railway Exhibition which was good. I also got to see the Flying Scotsman which was an absolute treat.

Theatre/Musicals

For the first time in far too long I finally went to the theatre and saw two shows; Little Shop of Horrors and Rocky Horror. These are great and I'd like to see some more next year.

Social Media

This has been a good year for me and social media. I've always been a bit weird about sharing too much about myself with people. I got better at it in person, but I always resisted doing it publicly. After seeing how other people post about their hobbies and such, I decided to give it a shot, and it's been very rewarding.

It's been freeing to be able to share my things with other people who find it interesting and have some great interactions around them. It's also been great to have a better record of my activities for my timeline.

Micro.blog

As a result of me joining Mastodon and enjoying it much more, I decided to leave Micro.blog. It's just not the service for me. My biggest gripes are mostly around discoverability.

I had a very hard time discovering people posting about things I was interested in, the inability to search by tags/categories makes it hard to find things. Sure, there's a search function that will search the body of the post, but if I'm posting something like "painted my terminators", unless I search by "terminators", it won't find the tags of "Warhammer" or "Space Marines" which is really how I or someone else is likely to be searching. As a result, I ended up playing buzzword bingo to find people with interests similar to mine or relying on the Discover feed.

Mastodon

After tentatively joining Mastodon last year, it turned out to be one of my better decisions. I suspect my enjoyment comes from a few areas, though mostly the improved discoverability (being able to follow a tag is great) and the availability of some top-notch apps.

As a result, I ended up posting more this year than I had on any previous social media platforms combined. It's now the only social media I engage with (except for their respective messaging services), and it's been great.

I was worried I'd grow overly conscious of engagement, but I don't think that's happened. I'm posting for myself and to show others the fun things I've been up to. I suspect the lack of an algorithm to beat helps with that.

2024

Much like last year, I'm not making any traditional resolutions. But I do have some things I'd like to aim for:

Spend more time on things that actually bring me joy
Paint and play a 2k point game with my Confessors Space Marine army
Improve my health

My first games of Warhammer 40k

Zoe Aubert | GeekyAubergine — Wed, 20 Dec 2023 20:40:00 +0000

Last year, I set myself the goal of playing at least one 1k-point game of 40k. This seemed like a reasonable goal at the time, but I didn't really start it till pretty late in the year.

It became a sprint towards the finish line, with me finishing the last of the painting the day before my first game. But the pressure was good, as it forced me to accept "good enough," rather than spending hours chasing perfection.

While I ultimately missed my goal of 1k points, with me painting only about 500 points. I did end up playing two games, so overall, that's 1k 🤣.

Apologies for the lack of proper photos and battle reports. As I'll cover, it was a little overwhelming, and I forgot to take photos most of the time. Also, I know I've made mistakes, so the battle reports wouldn't be particularly "accurate".

The Confessors

I intend to cover this in more detail on a dedicated army page. Here's some lore/background on my army in the meantime.

I like dudes in armour and big guns. When I was collecting Age of Sigmar, I collected Slaves to Darkness. So, Space Marines were the obvious choice.

I like purple and wanted to use it as a colour in one of my armies. But for a long time, I wrestled with the fact that the Emperor's Children pre-heresy wore purple and I didn't want to be caught up in that. So I dabbled with the Imperial Fists for a while before giving up because painting yellow is painful.

After lamenting my choices with my friend, he convinced me to try doubling down on the "totally not Emperor's Children" angle. So I did. This then spawned "The Confessors". A Chapter who hunts the enemies of The Emperor and makes them "confess" their crimes and then pay for their sins.

The Confessors are led by Chapter Master Edward (another of my friend's brilliant suggestions), with each Captain taking a Ed name. For example, the name of my Terminator Captain featured here is Edwin. Their lore is still mostly under construction, but it's filled with many tongue-in-cheek references, such as they practice excellent (not perfect) warfare and focus on looking their best (again, not perfect).

Game 1

My first game was an "introduction to 40k" session at my local Warhammer shop. This wasn't a real battle in any real sense of the word. This was more of a "check I know the basic mechanics" sort of session. I was playing against a similarly sized force of Nerons.

As this was my first game and I knew Necron weapons could be pretty scary, I didn't want to get wiped, so I played it pretty cagey. This was my first mistake of many.

The Necron player got the first turn, but all they could really do was move up towards me (to the positions in the photo above). If I had asked more about their units before deploying, I would've found out that they had shorter-range weapon options and couldn't do much to me anyway.

It was then my turn. This revealed my second and third blunders. My Infernus Marines (left) did 0 damage to the Skorpekh Destroyers (left) as I grossly misunderstood how tough they were. Then my Terminators (right) did some damage to the Necron Warriors (upper middle), but due to hiding in a building, I prevented some of my models having a line of sight and being able to shoot.

I knew at this point I'd made some serious errors. I assumed my Infernus Marines would do more damage and that the Necrons would've been scarier. What I should've done is move both my units towards the centre of the board and lay down some heavy fire on the Necron Warriors while I had the chance. What was going to happen next was obvious.

The Necron player advanced their Warriors to the centre and then charged the Skorpekhs into my Infernus Marines. To say the Skorpekhs wiped my Marines would be an understatement. They were overkilled by a hilarious margin. After that, I was ready for my Terminators to also take a beating, but it turns out their armour is much better than I thought, and they just shrugged off the 20-odd shots, taking only a single wound.

It was then my turn to exact my revenge. On the advice of my opponent to trust in my Terminator's melee strength, I shot at the Warriors, taking a few out and then charged the Skorpekhs. To say I was impressed would be an understatement. The high strength and armour penetration of the Power Fists is awesome. They took out 2 of the Skorpekh and left another low for my Captain to finish off with his sword.

This very quickly turned from what I thought was an easy loss into a clear win. The Necrons continued to fail to shoot me off the table while I simply shot and then followed up with melee attacks that saw them die. The Necron Overlord (robot with the tall spear) did manage to kill off one of my Terminators with his Tachyon Arrow, which, while very deadly, only has one attack so could only kill one model.

While I know the opponent made some intentional "blunders" to ensure I didn't automatically lose the game, I was thoroughly impressed by how powerful my Terminators were and had a great time.

It was overwhelming though. While I thought I knew the game well enough to play, actually doing it and being required to remember everything the instant I needed it proved much more difficult than I expected. However, some of it was already becoming easier by the end of this first game.

Game 2

My next game was against my friend who got me into 40k and made many of the lore suggestions for the Confessors. He was playing his Genestealer Cult.

I thought I knew this army and how it operated from our numerous hours discussing our units and all the cool things they can do. As we both only really have the Combat Patrol's to play with, so we did that.

You'll also see that we each have our Red Gobbo's in our armies. They don't belong in our armies, but there's an option to play a game with them to get some free festive dice, and as we both had one, there were no real advantages to either player.

This was both my and my friend's first non-store-led games, so it was very slow and full of mistakes and uncertainties about the rules. These games are supposed to last about an hour. This turned into a three-hour slogfest.

We both seemed rather afraid of what could happen, so we both decided to make use of our deep-strike rules (start with some models off the board and have them appear later) and have some of the models start in reserve. I then got the first turn and teleported my Terminators on top of the centre objective. (Hidden behind my Captain). The sellotape was acting as my marker, but I forgot to remove it before I took the picture.

I knew that with most of the Neophyte Hybrids being in reserve, I needed to protect my home objectives, so I chose not to move the Infernus Marines or the Gobbo (he's off to the right corner of the board). This left me only shooting at the Goliath Rockgrinder with my Terminators. I vastly underestimated the Rockgrinder's toughness, and all of my shots did a single wound.

Things only got worse from here. My opponent moved his Rockgrinder up to near Terminators and disembarked his Aberrants (or as he affectionally calls them, "muscle beach") right in my face.

The Rockgrinder then shot, and it slapped hard. Thankfully, my Terminators have a 4+ (on a D6 roll equal or better than a 4) invulnerable save, or they've been toast. I rolled pretty well and only lost a single Terminator, but damn. Muscle Beach then charged, laid down the pain and took out another Terminator.

Thanks to being able to respond in my opponent's fight phase and then again in my turn, I managed to take out a few of the beachgoers before taking any more losses. Unfortunately, I made another mistake when removing my dead models, leaving the sergeant with a sword rather than keeping another power fist. I should've kept the power fist instead, as it has much higher strength, and it would've been much more effective against these enemies. Though, as I didn't kill the unit, it meant that the Rockgrinder could not shoot at my Terminators, which probably saved their lives (this is how we interpreted the rules; I think we're wrong, but oh well).

I did move my Infernus Marines around the corner to the left, trying to keep away from the Rockgrinder as it was obviously going to make the charge against them, but it didn't work.

As predicted, he moved his Rockgrinder up to my Infernus Marines on my opponent's turn. He also deployed his Neophytes on his home objective and dropped his Acolyte Hybrids as close as possible to my Terminators.

The Acolytes and Rockgrinder then charged respectively. The Acolytes did nothing to my Terminators, but the Rockgrinder decimated my Infernus Marines.

Enter the Red Gobbo.

On my next turn, as a somewhat last-ditch effort, I got my Gobbo involved and tagged him into combat with the Rock grinder. Astonishingly, he managed to do a wound to it. However, his primary goal was to pin the Rockgrinder down.

I then finished off the final Aberrant and moved my Terminators towards his home objectives. From here, it was a bit of a grind with us each taking out models, though he has the annoying ability to bring back a fair few models from the dead. This led to my Terminators being surrounded again. He also tagged his Gobbo into the fray.

Eventually, the Rockgrinder got through the Infernus Marines, Librarian and Gobbo and caught up with my Terminators.

My opponent then played a genius move of retreating his Neophytes so that the Rockgrinder could fire on my Terminators. This then left Captain Edwin all by himself to face the enemy.

I'm sure you can imagine what happened next. Despite his heroic last stand, he eventually was overwhelmed.

Thoughts

This was great. I had a feeling I'd enjoy this, and I did. I made a lot of mistakes that I hope I've learned from and won't make again. None of the mistakes feel bad, which is good, I feel I can correct them with more experience rather than it being insurmountable.

There's a lot of information to process, and reading/flipping through the books is far too clunky. I/we used a fair bit of time just finding useful information. So I need to make myself some cheat/crib sheets to take along, which should help with that too.

Advent of Code is not healthy for me

Zoe Aubert | GeekyAubergine — Wed, 13 Dec 2023 19:30:00 +0000

This year is the first time I've participated in Advent of Code, and it's caused me some problems and highlighted some issues I need to address.

Content warning for discussions of my mental health.

My Problem

I was planning to explore some of this in my EndOfYearPost™️, but now's as good a time as any.

This year has been a fun delve into my mental health. Not with a professional, but with myself, so take everything with a handful of salt.

A core part of my mentality is based on my performance. I must at all times be performing my best while performing increasingly impressive "feats" (take that to mean what you will). While this problem isn't isolated to just programming, that's part of a wider discussion.

If I'm not performing my best, then I feel terrible. That can mean many things. Maybe I'm stuck on a problem that "should" be solvable. Maybe I can't do the "right" thing because of time constraints. Sometimes, it's not even my "fault". The library I'm trying to use doesn't work as well as expected or similar, and it leads to endless unsolvable problems, (this has been particularly relevant to me professionally in recent times as I've been working with mobile device cameras). Any one of these things can ruin an otherwise great day/week.

To satisfy this need to perform at the highest levels, I keep starting more and more complex projects. Aiming higher and higher. I've tried many things, from building a stock-trading bot to making a search engine and an MMO. Only for every one of the projects to be abandoned. And with each abandonment comes failure, with each being more painful than the last. Ask my friends; we did a tally a while back and came to something like 80 unfinished/abandoned projects 🫠. And, of course, the only logical way to redeem myself for a failed project is to start and complete an even more complex one.

After the discussion where my friends and I tallied up my unfinished projects, I swore a vow not to start a new project until I completed one. I did not want the number of projects to increase any further and add to my perceived failures. I was doing well, even completing some of them, including shipping my hackathon project, finishing the redesign of this website, and painting some Warhammer models.

Programming Challenges

For many years, I have found a great source of pride (and big-headedness) in being able to solve "hard" programming challenges. Initially, many of these came from the projects I was working on, such as various graphics-related problems from making games or inverse kinematics from my foray into building a robotics simulator.

As the years went on, I ran out of fun project ideas and turned to other programming challenges such as LeetCode, CodeCademy and Project Euler.

I never found the first two particularly inspiring, mostly just things I'd had to solve myself previously, and if it's not new, I'm not interested. Project Euler, though, captured me.

While I'm not good enough at maths to understand some of the problems, it didn't stop me from trying. I've spent what I can only refer to as a silly number of hours trying some of these. Thankfully, because these are "maths hard" rather than "computer science" hard, I didn't take my inability to solve some of them too much to heart.

As another by-product of them being mostly "maths based", I wasn't able to get many of my friends to participate, so there was no-one I could really compete with.

This should have been a warning of what would come if I tried Advent of Code.

Advent of Code

The competitiveness

On rolls the first of December, and I'm feeling good. After having a go at it, I mentioned it to some of my friends, who also decided to give it a go. Great, now I am not only competing against the internet, I'm competing against people I know, and I have to prove that I'm better than them.

Here in lies the first problem. My primary motivation for Advent of Code was not "Can I complete these?", but "Can I complete them faster and better?" than others. Maybe I knew this from the start, but I might've (and likely did) repress that as I knew it was bad.

This got out of hand. Not only was I waking up early to be first, but I was spending every break I got working on the problems. Getting the answer was no longer enough. With other people posting their code and benchmarks, I had something even better to strive for. Solving it was no longer enough. I had to have the most optimal solution. My code had to be faster and better written.

Oftentimes, these optimisations took much longer than just solving the problem. Those are hours I'll never get back, chasing performance metrics that ultimately don't matter and no one was actually competing with.

The Blogging

At the start of the first day, I hadn't even thought about posting anything to do with Advent of Code, but then, Robb showed me Lewis' post, and it got me considering it.

I love talking about and teaching programming, so this seemed an obvious choice. So, after some faffing with getting the style right, I posted my first post.

With that simple post, I signed myself into an unwritten contract that would not only solve all the problems but also write about them. So when day 10 came, and I didn't finish the problems, it was not only a personal failure, but it also felt like a very public failure. I know it's not, and I wasn't the only person who didn't finish that day, but because I'd made an effort to write about all the other days, it felt worse than if I hadn't.

Another unfavourable aspect of blogging was it was a very public statement of "here's what I can do, beat it if you dare", which is less than healthy.

The Camels Back

I'm not exactly sure where it fell apart and became an obvious problem. Day ten was an obvious marker, and missing day 12 was probably the final straw, but I think the problem appeared earlier when I almost made myself late for things because I was busy either solving the problem or writing about my solution.

The first few days were great, but as time went on, the problems required more and more time, which I ultimately didn't have, and I was starting to sacrifice important things. Also, the pace required to keep up is relentless.

As the days progressed, fewer people were posting, and my friends' enthusiasm also seemed to die. And I sadly think that's what ultimately did it. I'd already "lost" to the internet as there we still lots of people completing the challenges I could not. And I'd already "won" within the circle of people I know.

What Now?

Today was the day of reckoning. I don't know if it's because I got an unusually good night's sleep, or what, but I saw clearly what was happening. Advent of Code, and the self-imposed competitiveness around it, was fuelling one of my toxic traits and causing me problems, and it had to stop.

I'm pleased I've got this far, I didn't know how far I'd get, and I didn't reasonably expect to be able to do all of the challenges. But I've survived the first few big challenges that saw lots of people leaving and I should be proud of that.

I might revisit these in the future. If I do, I think I'll do so privately without posting about it. But for now, I'm done. I should spend my time on less toxic things and enjoy the holidays.

PS

This is not a reflection of Advent of Code or anyone else who enjoys it. If you can enjoy it in a healthy way, then you should continue too 🙂.

Advent of Code 2023 - Day 11

Zoe Aubert | GeekyAubergine — Mon, 11 Dec 2023 23:00:00 +0000

Advent of Code is a yearly programming challenge. See my day 01 post to see how the project is set up.

To view my solutions in full, check them out on GitHub. See my previous posts for other solutions.

Part 1

Today saw us finding the distances between galaxies with some interesting twists. Read the problem statement, as it explains it pretty well. I went down many mistaken paths today trying to predict what would come, and it didn't work out 🤣.

Mistake 1

I started with a recurring feature of these challenges, and created aInput struct.

struct Input {
    chars: Vec<char>,
    width: usize,
    height: usize,
}

impl Input {
    fn new(input: &str) -> Self {
        let lines = input.lines().map(|l| l.trim()).collect::<Vec<_>>();
        let width = lines[0].len();

        // Expand "empty" rows to two "empty" rows
        let rows = lines
            .iter()
            .flat_map(|row| {
                if row.chars().all(|c| c == '.') {
                    vec![row, row]
                } else {
                    vec![row]
                }
            })
            .collect::<Vec<_>>();

        let height = rows.len();

        let mut cols = vec![];

        for x in 0..width {
            let mut col = vec![];
            for y in 0..height {
                col.push(rows[y].chars().nth(x).unwrap());
            }
            cols.push(col);
        }

        let cols = cols
            .iter()
            .flat_map(|col| {
                if col.iter().all(|&c| c == '.') {
                    vec![col.clone(), col.clone()]
                } else {
                    vec![col.clone()]
                }
            })
            .collect::<Vec<_>>();

        let width = cols.len();

        let mut chars = vec![];

        for y in 0..height {
            for x in 0..width {
                chars.push(cols[x][y]);
            }
        }

        Self {
            chars,
            width,
            height,
        }
    }

    fn to_string(&self) -> String {
        let mut s = String::new();
        for y in 0..self.height {
            for x in 0..self.width {
                s.push(self.chars[y * self.width + x]);
            }
            s.push('\n');
        }
        s
    }

    fn get(&self, x: usize, y: usize) -> Option<char> {
        if x >= self.width || y >= self.height {
            None
        } else {
            Some(self.chars[y * self.width + x])
        }
    }
}

In my infinite wisdom, I chose to deal with the "empty row/column counting as two rows/columns" by actually expanding the input and adding additional characters to it. In hindsight, it was absolute madness, but in my barely awake state this morning, seemed like a genius move. Everything else in it is pretty normal.

Mistake 2

struct Galaxy {
    id: u16,
    x: f32,
    y: f32,
}

impl Galaxy {
    fn new(id: u16, x: f32, y: f32) -> Self {
        Self { id, x, y }
    }

    fn distance(&self, other: &Self) -> f32 {
        let mut distance = 0.0;

        let mut x = self.x;
        let mut y = self.y;

        while x != other.x || y != other.y {
            let dx = other.x - x;
            let dy = other.y - y;

            if dx.abs() >= dy.abs() {
                x += dx.signum();
            } else {
                y += dy.signum();
            }

            distance += 1.0;
        }

        distance
    }
}

Next, I built myself a Galaxy struct. Here lies my second of many follies. When working out the distance between two galaxies, I first turned to what I thought was the genius move of using a rasterisation style approach to working out what "grid" slots the shortest distance span across, and using that to work out the "grid distance".

This initially worked for the first few tests, giving me a false sense of hope. But, later on (after building the rest of the program), I would discover it was wrong for more test cases. After abandoning that approach, I turned to what seemed like a safer bet. Work out the delta between the two points, and then walk in that direction one cell at a time in the direction of the greatest delta. And sure enough, it worked, but boi, was it slow. I couldn't see any optimisation for it, so I gave it no more thought at this point.

Mistake 3

I chanced a glance into the future as to what part 2 might contain, and suspected some more difficult pathfinding would come, something like "shortest path between all points", or "shortest spanning tree between all points". With that in mind, I decided it would probably be useful to cache the distance between any two given galaxies.

fn galaxy_distance_hash_id(galaxy_a: u16, galaxy_b: u16) -> u32 {
    let min = galaxy_a.min(galaxy_b);
    let max = galaxy_a.max(galaxy_b);

    (min as u32) << 16 | (max as u32)
}

struct GalaxyMap {
    galaxies: HashMap<u16, Galaxy>,
    galaxy_distances: HashMap<u32, u32>,
}

impl GalaxyMap {
    fn new() -> Self {
        Self {
            galaxies: HashMap::new(),
            galaxy_distances: HashMap::new(),
        }
    }

    fn from_input(input: &Input) -> Self {
        let mut map = Self::new();

        let mut id = 1;

        for y in 0..input.height {
            for x in 0..input.width {
                if input.get(x, y) == Some('#') {
                    map.add(Galaxy::new(id, x as f32, y as f32));
                    id += 1;
                }
            }
        }

        map
    }

    fn add(&mut self, galaxy: Galaxy) {
        self.galaxies.insert(galaxy.id, galaxy);
    }

    fn distance(&mut self, a: u16, b: u16) -> u32 {
        let key = galaxy_distance_hash_id(a, b);
        if let Some(distance) = self.galaxy_distances.get(&key) {
            *distance
        } else {
            let distance = self.galaxies[&a].distance(&self.galaxies[&b]) as u32;
            self.galaxy_distances.insert(key, distance);
            distance
        }
    }

    fn galaxy_ids(&self) -> Vec<u16> {
        self.galaxies.keys().copied().collect::<Vec<_>>()
    }
}

From there, it was easy to process the necessary data.

pub fn process(input: &str) -> Result<u32> {
    let input = Input::new(input);

    let mut map = GalaxyMap::from_input(&input);

    let galaxy_ids = map.galaxy_ids();

    let mut total_distance = 0;

    for a in 0..galaxy_ids.len() {
        for b in a + 1..galaxy_ids.len() {
            let distance = map.distance(galaxy_ids[a], galaxy_ids[b]);
            total_distance += distance;
        }
    }

    Ok(total_distance)
}

Cool. I was feeling good, I felt like I knew what twist was coming and was ready for it.

I then saw part 2. Each empty row/column isn't one additional empty row/column but is actually 1 million more rows/columns. This was not a twist I foresaw, and I knew immediately that my code would not support it.

Optimisation (aka fixing past mistakes)

I decided part 2 was impossible without fixing my previous mistakes, so I did this first, which is different to my usual approach.

Fix 1

Growing the input to be several million rows and columns is not feasible. So that had to change.

struct Input {
    chars: Vec<char>,
    width: usize,
    height: usize,
    empty_rows: Vec<usize>,
    empty_cols: Vec<usize>,
}

impl Input {
    fn new(input: &str) -> Self {
        let lines = input.lines().map(|l| l.trim()).collect::<Vec<_>>();

        let width = lines[0].len();
        let height = lines.len();

        let chars = lines.iter().flat_map(|l| l.chars()).collect::<Vec<_>>();

        let empty_rows = (0..height)
            .filter(|y| {
                for x in 0..width {
                    if chars[*y * width + x] == '#' {
                        return false;
                    }
                }
                true
            })
            .collect::<Vec<_>>();

        let empty_cols = (0..width)
            .filter(|x| {
                for y in 0..height {
                    if chars[y * width + *x] == '#' {
                        return false;
                    }
                }
                true
            })
            .collect::<Vec<_>>();

        Self {
            chars,
            width,
            height,
            empty_rows,
            empty_cols,
        }
    }

    fn to_string(&self) -> String {
        let mut s = String::new();
        for y in 0..self.height {
            for x in 0..self.width {
                s.push(self.chars[y * self.width + x]);
            }
            s.push('\n');
        }
        s
    }

    fn get(&self, x: usize, y: usize) -> Option<char> {
        if x >= self.width || y >= self.height {
            None
        } else {
            Some(self.chars[y * self.width + x])
        }
    }

    fn is_row_empty(&self, y: usize) -> bool {
        self.empty_rows.contains(&y)
    }

    fn is_col_empty(&self, x: usize) -> bool {
        self.empty_cols.contains(&x)
    }
}

Long gone is transforming the input. The only semi-clever thing going on here is pre-computing all the empty rows/columns before I need them. This is still quite messy, or at least I think it is. There are probably a few things you could do to fix it. The empty checks feel particularly scuffed.

Fix 2

This was more a stroke of luck than a stroke of genius. In trying to optimise the distance calculation I tried a great many things, including the Pythagorean theorem. While this turned out to be useless, I did notice that the x and y delta just happened to be the same as the distance. This greatly simplifies the calculation.

impl Galaxy {
    #[tracing::instrument]
    fn new(id: u16, x: f32, y: f32) -> Self {
        Self { id, x, y }
    }

    #[tracing::instrument]
    fn distance(&self, other: &Self) -> f32 {
        let dx = other.x - self.x;
        let dy = other.y - self.y;

        dx.abs() + dy.abs()
    }
}

I feel like with the number of grid-based games I've created over the years I'd have known this. Useful to know now though.

Fix 3

The GalaxyMap was the next thing on the chopping block. As we're not doing anything clever with the input to create the additional empty rows/columns, we need to do it here. Rather than just looking at galaxies, we need to go row by row and add a running offset for each empty row. Similar for columns.

The second thing is removing the cache. We're only checking each pairing once, so we're never going to look it up.

struct GalaxyMap {
    galaxies: HashMap<u16, Galaxy>,
}

impl GalaxyMap {
    fn new() -> Self {
        Self {
            galaxies: HashMap::new(),
        }
    }

    fn from_input(input: &Input) -> Self {
        let mut map = Self::new();

        let mut id = 1;

        let mut y_offset = 0;

        for y in 0..input.height {
            if input.is_row_empty(y) {
                y_offset += 1;
            }
            let mut x_offset = 0;
            for x in 0..input.width {
                if input.is_col_empty(x) {
                    x_offset += 1;
                }
                if input.get(x, y) == Some('#') {
                    map.add(Galaxy::new(
                        id,
                        (x + x_offset) as f32,
                        (y + y_offset) as f32,
                    ));
                    id += 1;
                }
            }
        }

        map
    }

    fn add(&mut self, galaxy: Galaxy) {
        self.galaxies.insert(galaxy.id, galaxy);
    }

    fn distance(&self, a: u16, b: u16) -> u32 {
        self.galaxies[&a].distance(&self.galaxies[&b]) as u32
    }

    fn galaxy_ids(&self) -> Vec<u16> {
        self.galaxies.keys().copied().collect::<Vec<_>>()
    }
}

With those optimisations, I got the speed boost I needed. It went from 44ms to 730µs. I'd usually chalk that up to a genius performance increase, but I think it just highlights how bad my first attempt was 🤣.

Part 2

After the optimisation, part 2 was easy and only required 2 changes. Changing all the values from u32 -> u64 and f32 -> f64 (possibly not needed), and changing the offsets to 999,999.

impl GalaxyMap {
    fn from_input(input: &Input) -> Self {
        let mut map = Self::new();

        let mut id = 1;

        let mut y_offset = 0;

        for y in 0..input.height {
            if input.is_row_empty(y) {
                y_offset += 999_999;
            }
            let mut x_offset = 0;
            for x in 0..input.width {
                if input.is_col_empty(x) {
                    x_offset += 999_999;
                }
                if input.get(x, y) == Some('#') {
                    map.add(Galaxy::new(
                        id,
                        (x + x_offset) as f64,
                        (y + y_offset) as f64,
                    ));
                    id += 1;
                }
            }
        }

        map
    }
    }

Thoughts

Today wasn't actually that difficult, I just made it harder than it needed to be by making a litany of errors.

I've also written this in a different style than usual. Rather than presenting the correct solution and why it worked, I thought it would be more entertaining to explore the issues of my own creation and how I fixed them. Hopefully, you enjoyed it.

Results

day_11        fastest       │ slowest       │ median        │ mean
├─ part1      43 ms         │ 49.85 ms      │ 44.31 ms      │ 44.43 ms
├─ part1_opt  621.2 µs      │ 1.266 ms      │ 721 µs        │ 731.8 µs
╰─ part2      612.7 µs      │ 1.052 ms      │ 718.6 µs      │ 733.2 µs

Advent of Code 2023 - Day 09

Zoe Aubert | GeekyAubergine — Sat, 09 Dec 2023 11:00:00 +0000

Advent of Code is a yearly programming challenge. See my day 01 post to see how the project is set up.

To view my solutions in full, check them out on GitHub. See my previous posts for other solutions.

Initial solutions

Part 1

Today saw us extrapolating numbers using a specific technique. I don't think I can explain the problem any better than it already is.

The first step was taking a first series of numbers 0 3 6 9 12 15 and producing the differences between each of them so that you get a result like this:

0   3   6   9  12  15
  3   3   3   3   3

fn calculate_differences(values: &[i32]) -> Vec<i32> {
    let mut differences = Vec::new();
    for i in 0..values.len() - 1 {
        differences.push(values[i + 1] - values[i]);
    }
    differences
}

The only slightly complex part was repeating this step until you reached a row of all 0 and then working up the right edge to get the extrapolations.

fn extrapolate_value(input: &[i32]) -> Result<i32> {
    let mut values = vec![input.to_vec()];

    loop {
        let bottom = values
            .last()
            .ok_or_else(|| Error::CouldNotGetBottomRowOfValues)?;

        if bottom.iter().all(|n| *n == 0) {
            break;
        }

        values.push(calculate_differences(bottom));
    }

    for row_index in (0..values.len() - 1).rev() {
        let row_last_value = values[row_index]
            .last()
            .ok_or_else(|| Error::CouldNotGetLastValueOfRow(row_index))?;

        let row_below_last_value = values[row_index + 1]
            .last()
            .ok_or_else(|| Error::CouldNotGetLastValueOfRow(row_index + 1))?;

        let next_value = row_last_value + row_below_last_value;

        values[row_index].push(next_value);
    }

    Ok(values[0][values[0].len() - 1])
}

pub fn process(input: &str) -> Result<i32> {
    let input = input
        .lines()
        .map(|line| {
            line.split_whitespace()
                .map(|n| {
                    n.parse::<i32>()
                        .map_err(Error::CouldNotParseNumber)
                })  
                .collect::<Result<Vec<_>>>()
        })
        .collect::<Result<Vec<_>>>()?;

    let extrapolations = input
        .iter()
        .map(|row| extrapolate_value(row))
        .collect::<Result<Vec<_>>>()?;

    let sum = extrapolations.iter().sum();

    Ok(sum)
}

Part 2

I half expected part 2 to be another maths thing like yesterday, but no, this was a nice simple twist. Rather than extrapolating forwards, we need to extrapolate backwards. The only change needed was to extrapolate_value which operated on the first rather than last elements in the arrays and inserted the value at the start rather than the end.

fn extrapolate_value(input: &[i32]) -> Result<i32> {
    let mut values = vec![input.to_vec()];

    loop {
        let bottom = values
            .last()
            .ok_or_else(|| Error::CouldNotGetBottomRowOfValues)?;

        if bottom.iter().all(|n| *n == 0) {
            break;
        }

        values.push(calculate_differences(bottom));
    }

    for row_index in (0..values.len() - 1).rev() {
        let row_last_value = values[row_index]
            .first()
            .ok_or_else(|| Error::CouldNotGetFirstValueOfRow(row_index))?;

        let row_below_last_value = values[row_index + 1]
            .first()
            .ok_or_else(|| Error::CouldNotGetFirstValueOfRow(row_index + 1))?;

        let next_value = row_last_value - row_below_last_value;

        values[row_index].insert(0, next_value);
    }

    Ok(values[0][0])
}

Optimisation

There might be some neat maths trick I don't know about, but I can't see any algorithmic thing I can do to optimise this in any meaningful way.

Thoughts

Today was a nice easy puzzle compared to some of the other days this week. It's nice to have an easy solution to an easy problem. Though it makes me worry about tomorrow 🤣

Results

day_09    fastest       │ slowest       │ median        │ mean
├─ part1  311.9 µs      │ 405.2 µs      │ 313.6 µs      │ 316.4 µs
╰─ part2  319.9 µs      │ 338.9 µs      │ 321 µs        │ 322.8 µs

Advent of Code 2023 - Day 08

Zoe Aubert | GeekyAubergine — Fri, 08 Dec 2023 23:20:00 +0000

Advent of Code is a yearly programming challenge. See my day 01 post to see how the project is set up.

To view my solutions in full, check them out on GitHub. See my previous posts for other solutions.

Initial solutions

Part 1

Today saw us taking a series of Nodes with left and right children, and based on a series of instructions, take either the left or right children until we reach a goal node. The nodes were formatted like this:

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

Using this it was relatively easy to parse the Nodes and build up a map of Nodes.

struct Node {
    id: u32,
    left: u32,
    right: u32,
}

impl Node {
    fn new(id: u32, left: u32, right: u32) -> Self {
        Self { id, left, right }
    }

    fn from_str(input: &str) -> Result<Self> {
        let id = input
            .get(0..=2)
            .ok_or_else(|| Error::CouldNotFindIdForInstruction(input.to_string()))?;

        let left = input
            .get(7..=9)
            .ok_or_else(|| Error::CouldNotFindLeftInstruction(input.to_string()))?;

        let right = input
            .get(12..=14)
            .ok_or_else(|| Error::CouldNotFindRightInstruction(input.to_string()))?;

        Ok(Self::new(
            letters_to_id(id)?,
            letters_to_id(left)?,
            letters_to_id(right)?,
        ))
    }
}

struct Map {
    nodes: HashMap<u32, Node>,
}

impl Map {
    fn new(nodes: Vec<Node>) -> Self {
        let mut map = Self {
            nodes: HashMap::new(),
        };

        for node in nodes {
            map.nodes.insert(node.id, node);
        }

        map
    }

    fn from_str(input: &str) -> Result<Self> {
        let mut nodes = Vec::new();

        for line in input.lines() {
            nodes.push(Node::from_str(line)?);
        }

        Ok(Self::new(nodes))
    }
    
    fn get_node(&self, id: u32) -> Result<&Node> {
        self.nodes
            .get(&id)
            .ok_or_else(|| Error::CouldNotInspectionForId(id_to_letters(id)))
    }
}

I've opted to use a HashMap as it's the quickest way to look up Nodes. You will notice that I've used HashMap<u32, Node> rather than HashMap<String, Node>. I don't know if this is still true but a fixed-size key is supposed to be a lot better than a String. As a result, I did some trickery.

const ZZZ_ID: u32 = 0x005A5A5A;

fn letters_to_id(letters: &str) -> Result<u32> {
    if letters.len() != 3 {
        return Err(Error::InvalidNumberOfLettersForId(letters.to_string()));
    }

    let mut id: u32 = 0;

    for (i, letter) in letters.chars().rev().enumerate() {
        id |= (letter as u32) << (i * 8);
    }

    Ok(id)
}

fn id_to_letters(id: u32) -> String {
    let mut letters = String::new();

    let letter_1 = ((id & 0x00FF0000) >> 16) as u8 as char;
    let letter_2 = ((id & 0x0000FF00) >> 8) as u8 as char;
    let letter_3 = (id & 0x000000FF) as u8 as char;

    letters.push(letter_1);
    letters.push(letter_2);
    letters.push(letter_3);

    letters
}

These functions convert the Node to and from a u32. Because I know that the Node IDs are always three-letter ASCII characters, and I know that an ASCII character takes up 1 byte, I can store all three in a u32 without much difficulty. For example, the Node ID ABC will be encoded as 0x00414243 in Hexadecimal.

From here it's a simple task to follow the instructions and traverse the Node Map until we find the Node we want. The instructions are given as a list of L and R (for each child Node). If you reach the end of the instructions and have not reached your goal Node, you repeat the instructions as required.

pub fn process(input: &str) -> Result<u32> {
    let mut lines = input.lines().map(|l| l.trim());

    let instructions = lines.next().ok_or_else(|| Error::NoInstructionsFound)?;

    lines.next();

    let remaining = lines.collect::<Vec<_>>().join("\n");

    let map = Map::from_str(&remaining)?;

    let mut steps = 0;
    let mut current_node = map.get_node(letters_to_id("AAA")?)?;

    loop {
        for direction in instructions.chars() {
            if current_node.id == ZZZ_ID {
                return Ok(steps);
            }

            match direction {
                'L' => current_node = map.get_node(current_node.left)?,
                'R' => current_node = map.get_node(current_node.right)?,
                _ => return Err(Error::UnexpectedInstruction(direction.to_string())),
            }

            steps += 1;
        }
    }
}

Part 2

Part 2 saw the fun introduction of instead of starting at the Node with the ID AAA, we're required to start at any Node ending with A and finish at any Node finishing with Z. For all the start Nodes, we must work out what is the minimum number of steps required before all "walks" (the word I'm going to use to represent the journey from a start to end Node when following the instructions) are on a Node ending with Z.

Oh, boi. This really complicates things. Working out when two "walks" both hit an end Node at the same time is kinda hard. I think the problem describes it pretty well.

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)

Here, there are two starting nodes, `11A` and `22A` (because they both end with `A`). As you follow each left/right instruction, use that instruction to _simultaneously_ navigate away from both nodes you're currently on. Repeat this process until _all_ of the nodes you're currently on end with `Z`. (If only some of the nodes you're on end with `Z`, they act like any other node and you continue as normal.) In this example, you would proceed as follows:

- Step 0: You are at `11A` and `22A`.
- Step 1: You choose all of the _left_ paths, leading you to `11B` and `22B`.
- Step 2: You choose all of the _right_ paths, leading you to `_11Z_` and `22C`.
- Step 3: You choose all of the _left_ paths, leading you to `11B` and `_22Z_`.
- Step 4: You choose all of the _right_ paths, leading you to `_11Z_` and `22B`.
- Step 5: You choose all of the _left_ paths, leading you to `11B` and `22C`.
- Step 6: You choose all of the _right_ paths, leading you to `_11Z_` and `_22Z_`.

So, in this example, you end up entirely on nodes that end in `Z` after `_6_` steps.

It was at this point I suspected that cycles would be important. I was ultimately right, but not before I went down a weird path.

I noticed in this example that the path the first walk takes loops every 2 steps. But this felt like a trap. What if there was a walk that didn't directly repeat, but instead oscillated between two valid end Nodes? Thinking that this was likely to be a gotcha, I set about solving it with this problem in mind.

I've recently been watching a bunch of videos on ray marching and thought I could borrow the approach. Essentially, it works out the longest "safe" distance a ray can progress before it might encounter an object. Using similar logic. I built a function that took a Node, the current input, and returned how many steps it had before it reached the next end Node. If I did this for all active walks, I would be able to skip forward to the next ending spot before progressing.

I thought this approach was clever. I thought I'd got one up on the inevitable gotcha. But I was wrong. After letting it run for a long time and not getting a result of use, I investigated more. I logged the length of each walk to work out their cycle lengths and noticed that even when crossing their looping point, the lengths did not change. This disproved my theory and meant I needed to rethink my approach.

Introducing the least/lowest common multiple. I've seen a fair bit of discussion talking about how people don't understand why it works. I'm going to give it my best shot of explaining it.

Why LCM works

Given two numbers, the LCM will tell you the first common multiple of two (or more) numbers. A "common multiple" is a number in which two other numbers can be multiplied by both arrive at. Let's take 2 and 3 and have a look at their multiples.

2: 02, 04, 06, 08, 10, 12, 14, 16, 18, 20
3: 03, 06, 09, 12, 15, 18, 21, 24, 27, 30

When we look at this list of multiples, we can see that 06 is the first number that appears in both lists. It is common to both lists of multiples. And because it is first, it is the least common multiple.

We can apply this to our problem using the lengths of our cycles. If we consider the first walk, it hits an "end" Node every n steps equal to the cycle length. Which in this case is 2. If we listed the step/iteration count at the end of each of these cycles, it would look like 02, 04, 06, ..., which is the same as our list of multiples from before. The same will be true with the other cycle with a length of 3.

So, if each of these "multiples" is equivalent to a cycle, we need to know when both cycles have ended at the same time. Or, another way of putting, that they have a step in common.

In this case, it's trivial, but in the actual input, the cycle lengths are:

If we take just the first two numbers. When would they both have a step in common? If you were to list every single multiple of 17,621 and 13, 939 below 1 million, you wouldn't find a common/shared multiple until 933,913. And as you can imagine, this is much easier to compute than actually checking all the numbers before that.

This also gets out of hand pretty quickly. If you take the first three walks, the LCM is 43,893,911. Adding that one number has made the search space increase by 47x. All of them together lead to a 14-digit number, which is crazy high and would take forever to check by hand. But this technique is much faster.

Implementing LCM

As part of my misstep earlier, I built a lot of helper functions and structures.

struct Input {
    input: String,
    cursor: usize,
}

impl Input {
    fn new(input: &str) -> Self {
        Self {
            input: input.to_string(),
            cursor: 0,
        }
    }

    fn skip(&mut self, n: usize) {
        self.cursor += n;
        self.cursor %= self.input.len();
    }

    fn peek(&self) -> Option<char> {
        self.input.chars().nth(self.cursor)
    }

    fn next(&mut self) -> Option<char> {
        let next = self.peek();
        self.cursor += 1;
        self.cursor %= self.input.len();
        next
    }
}

fn get_next_node(map: &Map, node: u32, mut input: Input) -> Result<(u32, Input)> {
    let node = map.get_node(node)?;

    match input.next() {
        Some('L') => Ok((map.get_node(node.left)?.id, input)),
        Some('R') => Ok((map.get_node(node.right)?.id, input)),
        Some(c) => Err(Error::UnexpectedInstruction(c.to_string())),
        None => Err(Error::UnexpectedEndOfInstructions),
    }
}

fn steps_to_next_ending_in_z(map: &Map, node: u32, mut input: Input) -> Result<u64> {
    let mut steps = 0;
    let mut current_node = node;

    loop {
        if id_ends_with_z(current_node) {
            return Ok(steps);
        }

        let (next_node, next_input) = get_next_node(map, current_node, input)?;

        steps += 1;

        current_node = next_node;
        input = next_input;
    }
}

fn lcm(numbers: &[u64]) -> u64 {
    let mut result = numbers[0];

    for &number in numbers.iter().skip(1) {
        result = result * number / result.gcd(number);
    }

    result
}

The Input struct is definitely over-engineered. But it did make the "repeat the instructions if not at the end until you are" part much easier to work with.

With those it was pretty easy to calculate the cycle length (distance to first "end" Node) and then get the LCM of them

pub fn process(input: &str) -> Result<u64> {
    let mut lines = input.lines().map(|l| l.trim());

    let instructions = lines.next().ok_or_else(|| Error::NoInstructionsFound)?;

    let input = Input::new(instructions);

    lines.next();

    let remaining = lines.collect::<Vec<_>>().join("\n");

    let map = Map::from_str(&remaining)?;

    let current_nodes = map
        .get_starting_nodes()
        .iter()
        .map(|n| n.id)
        .collect::<Vec<_>>();

    let distances_to_next_z = current_nodes
        .par_iter()
        .map(|n| steps_to_next_ending_in_z(&map, *n, input.clone()))
        .collect::<Result<Vec<_>>>()?;

    let lcm: u64 = lcm(&distances_to_next_z);

    Ok(lcm)
}

Optimisation

I don't think there's anything you could optimise out here. Maybe there is though and it'd be fun to be corrected.

Thoughts

I was not a fan of today. Not because it wasn't a good puzzle but because it required knowing and understanding how to apply a maths concept, rather than a computer science concept. I don't mind it when Project Euler does it, because that's a maths sort of problem set, but I disliked it here. I like using programming challenges to teach and many people are (rightly) put off by the heavy maths stuff so I have to point them to other places. I hoped this would be more maths-light.

Results

day_08    fastest       │ slowest       │ median        │ mean
├─ part1  351.7 µs      │ 1.896 ms      │ 381.9 µs      │ 441.9 µs
╰─ part2  1.096 ms      │ 8.691 ms      │ 1.169 ms      │ 1.355 ms

Advent of Code 2023 - Day 07

Zoe Aubert | GeekyAubergine — Thu, 07 Dec 2023 14:40:00 +0000

Advent of Code is a yearly programming challenge. See my day 01 post to see how the project is set up.

To view my solutions in full, check them out on GitHub. See my previous posts for other solutions.

Initial solutions

Part 1

Today saw us implementing "Camel Cards" or TotallyNotPoker™️. Though to be fair, it is a much simpler version of the game, though I see how it'd be easy to play while riding a camel 🤣.

Rather than me explaining all the rules, I suggest you read the problem. This is possibly the easiest to understand so far.

As soon as I saw the problem, I knew how I wanted to build it, and it's taking advantage of some of the really nice things from Rust.

#[derive(Debug, Clone, Copy, PartialEq, Eq, Ord, PartialOrd, Hash)]
enum Card {
    Two,
    Three,
    Four,
    Five,
    Six,
    Seven,
    Eight,
    Nine,
    Ten,
    Jack,
    Queen,
    King,
    Ace,
}

impl Card {
    fn from_str(input: char) -> Result<Self> {
        match input {
            'A' => Ok(Self::Ace),
            'K' => Ok(Self::King),
            'Q' => Ok(Self::Queen),
            'J' => Ok(Self::Jack),
            'T' => Ok(Self::Ten),
            '9' => Ok(Self::Nine),
            '8' => Ok(Self::Eight),
            '7' => Ok(Self::Seven),
            '6' => Ok(Self::Six),
            '5' => Ok(Self::Five),
            '4' => Ok(Self::Four),
            '3' => Ok(Self::Three),
            '2' => Ok(Self::Two),
            _ => Err(Error::CouldNotParseCard(input.to_string())),
        }
    }
}

We're into the fun stuff already. Card "derives" Ord. Ord is a way of representing the relative ordering of two values, essentially >, <, =. Using this very simple derive, Cards can now be easily compared without having to hold an internal value to compare against. The order is given ascending in the order it's defined.

#[derive(Debug, Clone, Copy, PartialEq, Eq, Ord, PartialOrd, Hash)]
enum HandType {
    HighCard,
    OnePair,
    TwoPair,
    ThreeOfAKind,
    FullHouse,
    FourOfAKind,
    FiveOfAKind,
}

impl HandType {
    fn from_cards(cards: &[Card]) -> Result<Self> {
        if cards.len() != 5 {
            return Err(Error::UnexpectedNumberOfCards);
        }

		// Sort asc
        let mut cards = cards.to_vec();
        cards.sort();

		// Cards 0-4 must all be the same
        if cards[0] == cards[4] {
            return Ok(HandType::FiveOfAKind);
        }

		// Cards 0-3 or 1-4 must all be the same
        if cards[0] == cards[3] || cards[1] == cards[4] {
            return Ok(HandType::FourOfAKind);
        }

        // Three of a kind and a pair
        if (cards[0] == cards[2] && cards[3] == cards[4])
            || (cards[0] == cards[1] && cards[2] == cards[4])
        {
            return Ok(HandType::FullHouse);
        }

        // Groups of threes
        if cards[0] == cards[2] || cards[1] == cards[3] || cards[2] == cards[4] {
            return Ok(HandType::ThreeOfAKind);
        }

        if (cards[0] == cards[1] && cards[2] == cards[3])
            || (cards[0] == cards[1] && cards[3] == cards[4])
            || (cards[1] == cards[2] && cards[3] == cards[4])
        {
            return Ok(HandType::TwoPair);
        }

        if cards[0] == cards[1]
            || cards[1] == cards[2]
            || cards[2] == cards[3]
            || cards[3] == cards[4]
        {
            return Ok(HandType::OnePair);
        }

        Ok(HandType::HighCard)
    }
}

Next was determining the Hand "type". Similar to last time, we get the comparison for free. The complexity is introduced here in determining what hand we actually have.

Thanks to Card being Ord we can call sort on a vector of them and get the cards sorted. Sorting them is important as it allows us to make quick comparisons to determine the hand. For example, if card[0] and card[4] are the same, then every value between them must also be the same. Therefore, we know that all five cards must be the same, giving us five of a kind.

We can then expand this logic to cover each case. It gets more complex, but hopefully, it's followable. Most of it is taking a "window" of x number of cards and seeing if any of them meet the equality requirement. The only weird one is full-house, which has to check for three of a kind and a pair in two different ways.

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
struct Hand {
    cards: [Card; 5],
    hand_type: HandType,
}

impl Hand {
    fn new(cards: [Card; 5]) -> Result<Self> {
        let hand_type = HandType::from_cards(&cards)?;
        
        Ok(Self { cards, hand_type })
    }

    fn from_str(input: &str) -> Result<Self> {
        let mut cards = [Card::Two; 5];
        for (i, card) in input.chars().enumerate() {
            cards[i] = Card::from_str(card)?;
        }
        Self::new(cards)
    }
}

We can then make a Hand containing the Cards and their corresponding HandType. We're going to want to compare Hands, but you might've noticed we've not derived Ord. That's because we need to do something a bit more clever here so we're going to implement it ourselves.

impl Ord for Hand {
    fn cmp(&self, other: &Self) -> std::cmp::Ordering {
	    // Compare the HandType
        match self.hand_type.cmp(&other.hand_type) {
	        // If the two hands have the same HandType
            std::cmp::Ordering::Equal => {
	            // zip takes two arrays and allows you to iterate through them at the same time without having to do index stuff
                for (self_card, other_card) in self.cards.iter().zip(other.cards.iter()) {
	                // Compare the face value of the Card
                    match self_card.cmp(other_card) {
	                    // If equal, keep going
                        std::cmp::Ordering::Equal => continue,
                        // If they're different, return the result of the face value comparison
                        other => return other,
                    }
                }
                // Default to equal
                std::cmp::Ordering::Equal
            }
            // If HandType is not equal, return the HandType comparison
            other => other,
        }
    }
}

// We need PartialOrd to satisfy other constraints, but it can just use `Ord`
impl PartialOrd for Hand {
    fn partial_cmp(&self, other: &Self) -> Option<std::cmp::Ordering> {
        Some(self.cmp(other))
    }
}

I've added a bunch of comments here to hopefully explain what this is doing. It might be a bit much if you've not seen Rust before. Essentially, we check if the two Hands have different HandTypes. If they're different, return the ordering for that. If they're the same, we then compare each Card in the hands until it breaks the tie.

With that, we can now sort out hands.

fn order_hands(hands: &[Hand]) -> Vec<Hand> {
    let mut hands = hands.to_vec();
    hands.sort();
    hands
}

Next, we need to store the HandAndBet and be able to compare them, too.

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
struct HandAndBet {
    hand: Hand,
    bet: u32,
}

impl HandAndBet {
    fn from_str(input: &str) -> Result<Self> {
        let mut split = input.split_whitespace();

        let hand = split
            .next()
            .ok_or_else(|| Error::CouldNotParseHandAndBet(input.to_string()))?;

        let hand = Hand::from_str(hand)?;

        let bet = split
            .next()
            .ok_or_else(|| Error::CouldNotParseHandAndBet(input.to_string()))?
            .parse::<u32>()
            .map_err(Error::CouldNotParseNumber)?;

        Ok(Self { hand, bet })
    }
}

impl Ord for HandAndBet {
    fn cmp(&self, other: &Self) -> std::cmp::Ordering {
	    // We don't care about the value of bet so just pass through the comparison of hand
        self.hand.cmp(&other.hand)
    }
}

impl PartialOrd for HandAndBet {
    fn partial_cmp(&self, other: &Self) -> Option<std::cmp::Ordering> {
        Some(self.cmp(other))
    }
}


fn sort_hands_and_bets(hands_and_bets: &[HandAndBet]) -> Vec<HandAndBet> {
    let mut hands_and_bets = hands_and_bets.to_vec();
    hands_and_bets.sort();
    hands_and_bets
}

And with that, we can now sort HandAndBet. All that's left is then to take these sorted HandAndBets, and multiply their bet by their rank and return the sum.

pub fn process(input: &str) -> miette::Result<u32> {
    let bets_and_hands = input
        .lines()
        .map(|line| HandAndBet::from_str(line.trim()))
        .collect::<Result<Vec<HandAndBet>>>()?;

    let ordered_hands_and_bets = sort_hands_and_bets(&bets_and_hands);

    let total_winnings = ordered_hands_and_bets
        .iter()
        .enumerate()
        .map(|(i, hand_and_bet)| hand_and_bet.bet * (i + 1) as u32)
        .sum::<u32>();

    Ok(total_winnings)
}

Part 2

Part 2 was an obvious twist and made J represent a Joker rather than a Jack. Thankfully, because I over-engineered it the first time, it's not that hard to update it to work.

First, we need to change J to be worth less than two.

enum Card {
    Jack,
    Two,
    Three,
    Four,
    Five,
    Six,
    Seven,
    Eight,
    Nine,
    Ten,
    Queen,
    King,
    Ace,
}

The only other change is to HandType, we need to make this account for Jokers. This is much more complex than before.

impl HandType {
    fn from_cards(cards: &[Card]) -> Result<Self> {
        if cards.len() != 5 {
            return Err(Error::UnexpectedNumberOfCards);
        }

		// Sorted ascending
        let mut cards = cards.to_vec();
        cards.sort();

        // Joker is always at start of hand

        if cards[0] == cards[4] {
            return Ok(HandType::FiveOfAKind);
        }

        let number_of_jokers = cards.iter().filter(|card| **card == Card::Jack).count();

        match number_of_jokers {
	        // I don't believe this is necessary as the previous check should've got it, but I have it here for completeness
            5 => Ok(HandType::FiveOfAKind),
            
            // If you have 4 Jokers, change all to be the only other card and get five of a kind
            4 => Ok(HandType::FiveOfAKind),
            
            3 => {
	            // If the two other cards match, you can make all the Jokers that card
                if cards[3] == cards[4] {
                    return Ok(HandType::FiveOfAKind);
                }

				// Change all the Jokers to one of the cards and get four of a kind
                Ok(HandType::FourOfAKind)
            }
            
            2 => {
	            // If the last 3 cards are all the same, you can make all the Jokers match
                if cards[2] == cards[4] {
                    return Ok(HandType::FiveOfAKind);
                }
                
				// If you have a pair, you can make four of a kind
                if (cards[2] == cards[3]) || (cards[3] == cards[4]) {
                    return Ok(HandType::FourOfAKind);
                }

				// If you have nothing, you can always match the two jokers to one of the cards for three of a kind
                Ok(HandType::ThreeOfAKind)
            }
            
            1 => {
	            // If all other cards match, you can make the Joker match to make five of a kind
                if cards[1] == cards[4] {
                    return Ok(HandType::FiveOfAKind);
                }

				// If you have three of a kind, you can use the joker to make four of a kind
                if cards[1] == cards[3] || cards[2] == cards[4] {
                    return Ok(HandType::FourOfAKind);
                }

				// If you have two pairs, you can make the joker one of them and make a full house
                if cards[1] == cards[2] && cards[3] == cards[4] {
                    return Ok(HandType::FullHouse);
                }

				// If you hav a pair, you can make three of a kind
                if cards[1] == cards[2] || cards[2] == cards[3] || cards[3] == cards[4] {
                    return Ok(HandType::ThreeOfAKind);
                }

                Ok(HandType::OnePair)
            }

			// Same as in part 1
            0 => {
                if cards[0] == cards[3] || cards[1] == cards[4] {
                    return Ok(HandType::FourOfAKind);
                }

                if (cards[0] == cards[2] && cards[3] == cards[4])
                    || (cards[0] == cards[1] && cards[2] == cards[4])
                {
                    return Ok(HandType::FullHouse);
                }

                if cards[0] == cards[2] || cards[1] == cards[3] || cards[2] == cards[4] {
                    return Ok(HandType::ThreeOfAKind);
                }

                if (cards[0] == cards[1] && cards[2] == cards[3])
                    || (cards[0] == cards[1] && cards[3] == cards[4])
                    || (cards[1] == cards[2] && cards[3] == cards[4])
                {
                    return Ok(HandType::TwoPair);
                }

                if cards[0] == cards[1]
                    || cards[1] == cards[2]
                    || cards[2] == cards[3]
                    || cards[3] == cards[4]
                {
                    return Ok(HandType::OnePair);
                }

                Ok(HandType::HighCard)
            }
            _ => Err(Error::UnexpectedNumberOfCards),
        }
    }
}

This is kinda similar to the previous implementation, but the Card lookup has to first consider how many Jokers there are so it can use them. Again, thanks to it being sorted we can make a lot of assumptions that simplify things immensely.

No other changes were necessary to make this work. Over-engineering wins again.

Optimisation

There are no obvious optimisations that I think would save any significant time. No matter what you do you still need to rank every hand which requires sorting. And I'm not doing anything too crazy with the cards -> hand-type mapping.

I did try multi-threading for part 1, but unsurprisingly it made things slower.

Thoughts

This was cool and didn't have any major complications. I've always meant to build a poker game thing, so this was a good practice and proof of concept.

Results

day_07        fastest       │ slowest       │ median        │ mean
├─ part1      154.9 µs      │ 251.2 µs      │ 169.4 µs      │ 172.7 µs 
├─ part1_opt  134.7 µs      │ 578.2 µs      │ 211.4 µs      │ 236.7 µs
╰─ part2      173.6 µs      │ 207.4 µs      │ 174.7 µs      │ 178.3 µs

Advent of Code 2023 - Day 06

Zoe Aubert | GeekyAubergine — Wed, 06 Dec 2023 11:00:00 +0000

Advent of Code is a yearly programming challenge. See my day 01 post to see how the project is set up.

To view my solutions in full, check them out on GitHub. See my previous posts for other solutions.

Initial solutions

Part 1

Today was much nicer than yesterday's. We were tasked with working out the optimal strategy for boat racing. A race lasts an amount of milliseconds (very short races) and has a record distance. For your boat to move, you must charge it. For every millisecond you charge it the boat goes 1 mm/s faster (it never slows down). Then, for any given race, you need to work out how many milliseconds to charge for in order to beat the record before the race ends.

The input was a series of time and distance pairs, each representing a race.

Time:      7  15   30
Distance:  9  40  200

Parsing this was pretty simple.

struct Race {
    time: u64,
    distance: u64,
}

fn numbers_from_line(input: &str) -> Result<Vec<u64>> {
    let colon_split: Vec<&str> = input.split(": ").collect();

    colon_split[1]
        .split(' ')
        .filter(|s| !s.is_empty())
        .map(|s| s.parse::<u64>().map_err(Error::CouldNotParseNumber))
        .collect()
}

fn input_to_races(input: &str) -> Result<Vec<Race>> {
    let mut races = vec![];

    let lines: Vec<&str> = input.split('\n').map(|l| l.trim()).collect();

    let times = numbers_from_line(lines[0])?;
    let distances = numbers_from_line(lines[1])?;

    for (i, time) in times.iter().enumerate() {
        match distances.get(i) {
            Some(distance) => races.push(Race {
                time: *time,
                distance: *distance,
            }),
            None => return Err(Error::MissingDistance(i)),
        }
    }

    Ok(races)
}

The puzzle is to determine how many ways you can beat each race and then multiply them together.

fn calculate_max_distance_for_time(press_down_time: u64, max_time: u64) -> u64 {
    let time_remaining = max_time - press_down_time;
    time_remaining * press_down_time
}

fn number_of_ways_to_beat_race(race: &Race) -> u64 {
    (0..race.time)
        .map(|t| calculate_max_distance_for_time(t, race.time))
        .filter(|t| t > &race.distance)
        .count() as u64
}

pub fn process(input: &str) -> miette::Result<u64> {
    let races = input_to_races(input)?;

    Ok(races.iter().map(number_of_ways_to_beat_race).product())
}

And that's it. Compared to previous challenges, this is nice, small and very clean.

Part 2

Based on yesterday I had a funny feeling that they'd make the numbers very big. And they did. Rather than the input being multiple races, it's a single race and you need to ignore the spaces. The new race is:

Time:      71530
Distance:  940200

This number's still pretty small, let's see if it works without optimising.

pub fn process(input: &str) -> miette::Result<u64> {
    let races = input_to_races(input)?;

    Ok(races.iter().map(number_of_ways_to_beat_race).product())
}

It worked, and it didn't take the lifetime of the universe. Nice. But I know we can do better.

Optimisation

There's one obvious optimisation here, and I think they're even trying to hint at it in the statement.

Since the current record for this race is 9 millimetres, there are actually _4_ different ways you could win: you could hold the button for 2, 3, 4, or 5 milliseconds at the start of the race.

In the second race, you could hold the button for at least 4 milliseconds and at most 11 milliseconds and beat the record, a total of _8_ different ways to win.

For each race, the only number that matters is the first and last charging time that'd beat the record. You know everything outside that range will lose, and anything inside that range will win.

You could search from each end to find the values, but I think bisectional search lends itself much better to this problem, especially knowing how large the input is. Thanks to the way I've built it, it only requires changing number_of_ways_to_beat_race.

fn find_first_winning_number(race: &Race) -> u64 {
    let mut low = 0;
    let mut high = race.time;

    loop {
        let index = (low + high) / 2;
        let left = index - 1;

        let distance = calculate_max_distance_for_time(index, race.time);
        let left_distance = calculate_max_distance_for_time(left, race.time);

        if distance > race.distance && left_distance <= race.distance {
            return index;
        }

        if distance <= race.distance {
            low = index;
        } else {
            high = index;
        }
    }
}

fn find_last_winning_number(race: &Race) -> u64 {
    let mut low = 0;
    let mut high = race.time;

    loop {
        let index = (low + high) / 2;
        let right = index + 1;

        let distance = calculate_max_distance_for_time(index, race.time);
        let right_distance = calculate_max_distance_for_time(right, race.time);

        if distance > race.distance && right_distance <= race.distance {
            return index;
        }

        if distance > race.distance {
            low = index;
        } else {
            high = index;
        }
    }
}

fn number_of_ways_to_beat_race(race: &Race) -> u64 {
    find_last_winning_number(race) - find_first_winning_number(race)
}

Yes, I'm doing two separate searches for each edge of the winners. You could probably do it in one. I tried it, but it was far too messy, and I don't think it would be that much faster.

I applied this to both parts and got a ~1.4x improvement on part 1 and a ~124,324x improvement on part 2. That bisectional search is really doing work on that second part.

For those who are curious or, like me, found the part 2 improvement suspicious, the tests are running with 41ns precision, and part 2 had 100 samples with 1600 iterations. The full benchmarking output is available on GitHub.

Thoughts

I'm very pleased with how quickly I saw the optimisation and how well it performed. Makes learning and practising the implementation almost worth it 🤣

Results

day_06        fastest       │ slowest       │ median        │ mean
├─ part1      790.7 ns      │ 5.04 µs       │ 791.7 ns      │ 852.1 ns
├─ part1_opt  541.3 ns      │ 1.786 µs      │ 551.7 ns      │ 584.3 ns
├─ part2      48.88 ms      │ 75.92 ms      │ 50.14 ms      │ 50.93 ms
╰─ part2_opt  387.7 ns      │ 424.1 ns      │ 403.3 ns      │ 403.6 ns

Advent of Code 2023 - Day 05

Zoe Aubert | GeekyAubergine — Tue, 05 Dec 2023 14:45:00 +0000

Advent of Code is a yearly programming challenge. See my day 01 post to see how the project is set up.

To view my solutions in full, check them out on GitHub. See my previous posts for other solutions.

Initial solutions

Part 1

I don't really know how to explain today's challenge. I would highly recommend reading the problem yourself. It saw us taking seeds and working out where to plant them. Seeds were given as an array.

seeds: 79 14 55 13

From there, you were given a series of maps to process the seeds.

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

These are essentially transformers that act on the seeds' value. After applying a bunch of these you then took the minimum remaining value.

As this was going to require some funky parsing I built a custom input and cursor, much easier than traversing lines in an iterator.

struct Input {
    lines: Vec<String>,
    cursor: usize,
}

impl Input {
    fn from_str(input: &str) -> Result<Input> {
        let lines = input
            .lines()
            .map(|s| s.trim().to_string())
            .collect::<Vec<_>>();

        Ok(Input { lines, cursor: 0 })
    }

    fn peak(&self) -> Option<&String> {
        self.lines.get(self.cursor)
    }

    fn next(&mut self) -> Result<&String> {
        let next = self
            .lines
            .get(self.cursor)
            .ok_or_else(|| Error::CannotFindNextLine(self.cursor));
        self.cursor += 1;
        next
    }

    fn to_string(&self) -> String {
        self.lines.join("\n")
    }
}

From there, it was a simple case of parsing the data.

type ParserOutput<T> = (T, Input);

struct Seeds {
    seeds: Vec<u32>,
}

impl Seeds {
    fn from_input(mut input: Input) -> Result<ParserOutput<Seeds>> {
        let first_line = input.next().map_err(|_| Error::CannotFindSeedsHeader)?;

        if !first_line.starts_with("seeds:") {
            return Err(Error::CannotFindSeedsHeader);
        }

        let seeds = first_line
            .split(':')
            .last()
            .ok_or_else(|| Error::CannotFindSeedsHeader)?
            .split(' ')
            .filter(|s| !s.is_empty())
            .map(|s| s.trim().parse::<u32>().map_err(Error::CouldNotParseNumber))
            .collect::<Result<Vec<_>>>()?;

        Ok((Seeds { seeds }, input))
    }
}

struct Map {
    mapped_values: HashMap<u32, u32>,
}

impl Map {
    fn from_input(mut input: Input) -> Result<ParserOutput<Map>> {
        let mut mapped_values = HashMap::new();

        if !input.next()?.ends_with("map:") {
            return Err(Error::CannotFindMapHeader);
        }

        while let Some(line) = input.peak() {
            if line.is_empty() {
                break;
            }

            let line = input.next()?;

            let numbers = line
                .split(' ')
                .filter(|s| !s.is_empty())
                .map(|s| s.trim().parse::<u32>().map_err(Error::CouldNotParseNumber))
                .collect::<Result<Vec<_>>>()?;

            if numbers.len() != 3 {
                return Err(Error::UnexpectedNumberOfValuesForMap(line.to_string()));
            }

            let destination_start = numbers[0];
            let source_start = numbers[1];
            let range = numbers[2];

            for i in 0..range {
                let source = source_start + i;
                let destination = destination_start + i;

                mapped_values.insert(source, destination);
            }
        }

        Ok((Map { mapped_values }, input))
    }

    fn get_mapped_value(&self, value: u32) -> u32 {
        *self.mapped_values.get(&value).unwrap_or(&value)
    }
}

There is a mistake here in Map, if you've already spotted it, nice, you probably suffered in a similar way, if not, stay tuned.

struct Data {
    seeds: Seeds,
    seed_to_soil_map: Map,
    soil_to_fertilizer_map: Map,
    fertilizer_to_water_map: Map,
    water_to_light_map: Map,
    light_to_temperature_map: Map,
    temparure_to_humity_map: Map,
    humidity_to_location_map: Map,
}

impl Data {
    fn from_input(input: Input) -> Result<Data> {
        let (seeds, mut input) = Seeds::from_input(input)?;
        
        input.next()?;

        let (seed_to_soil_map, mut input) = Map::from_input(input)?;

        input.next()?;

        let (soil_to_fertilizer_map, mut input) = Map::from_input(input)?;

        input.next()?;

        let (fertilizer_to_water_map, mut input) = Map::from_input(input)?;

        input.next()?;

        let (water_to_light_map, mut input) = Map::from_input(input)?;

        input.next()?;

        let (light_to_temperature_map, mut input) = Map::from_input(input)?;

        input.next()?;

        let (temparure_to_humity_map, mut input) = Map::from_input(input)?;

        input.next()?;

        let (humidity_to_location_map, _) = Map::from_input(input)?;

        Ok(Data {
            seeds,
            seed_to_soil_map,
            soil_to_fertilizer_map,
            fertilizer_to_water_map,
            water_to_light_map,
            light_to_temperature_map,
            temparure_to_humity_map,
            humidity_to_location_map,
        })
    }

    fn seeds(&self) -> &Seeds {
        &self.seeds
    }

    fn map_seed(&self, seed: u32) -> u32 {
        let soil = self.seed_to_soil_map.get_mapped_value(seed);
        let fertilizer = self.soil_to_fertilizer_map.get_mapped_value(soil);
        let water = self.fertilizer_to_water_map.get_mapped_value(fertilizer);
        let light = self.water_to_light_map.get_mapped_value(water);
        let temperature = self.light_to_temperature_map.get_mapped_value(light);
        let humidity = self.temparure_to_humity_map.get_mapped_value(temperature);
        let location = self.humidity_to_location_map.get_mapped_value(humidity);

        location
    }
}

pub fn process(input: &str) -> miette::Result<u32> {
    let input = Input::from_str(input)?;

    let data = Data::from_input(input)?;

    let min_location = data
        .seeds()
        .seeds
        .iter()
        .map(|seed| data.map_seed(*seed))
        .min()
        .ok_or(Error::NoMinValue)?;

    Ok(min_location)
}

I'm processing all the Maps and then passing in a single seed at a time, passing it through each Map and then getting its new value.

So, at this point, I was feeling good. I very quickly arrived at the point of having the example input processed and correct. So I swapped it to use the actual input, and, well, nothing happened. My computer sat there and processed. I added some logging and saw that it had only processed one line of the first Map after a minute.

It was at this point I looked properly at the actual input and noticed the size of the numbers. This is where my folly was. The first mapping range is:

2328388605 1716277852 240111965

Yes, that's right, it has 240,111,965 numbers. And that's just the first of many. Looking back through the code I noticed my mistake. In Map, I was building a HashMap of value -> mapped value. This is not good on something this size. Thankfully, because I'd over-engineered it, the only thing that needed changing was Map.

struct MapRange {
    destination_start: u64,
    source_start: u64,
    range: u64,
}

impl MapRange {
    fn new(destination_start: u64, source_start: u64, range: u64) -> Result<MapRange> {
        Ok(MapRange {
            destination_start,
            source_start,
            range,
        })
    }

    fn contains_value(&self, value: u64) -> bool {
        value >= self.source_start && value < self.source_start + self.range
    }

    fn map_value(&self, value: u64) -> u64 {
        if !self.contains_value(value) {
            return value;
        }

        let offset = value - self.source_start;
        let destination = self.destination_start + offset;

        destination
    }
}

struct Map {
    mapped_ranges: Vec<MapRange>,
}

impl Map {
    fn from_input(mut input: Input) -> Result<ParserOutput<Map>> {
        let mut mapped_ranges = Vec::new();

        if !input.next()?.ends_with("map:") {
            return Err(Error::CannotFindMapHeader);
        }

        while let Some(line) = input.peak() {
            if line.is_empty() {
                break;
            }

            let line = input.next()?;

            let numbers = line
                .split(' ')
                .filter(|s| !s.is_empty())
                .map(|s| s.trim().parse::<u64>().map_err(Error::CouldNotParseNumber))
                .collect::<Result<Vec<_>>>()?;

            if numbers.len() != 3 {
                return Err(Error::UnexpectedNumberOfValuesForMap(line.to_string()));
            }

            let destination_start = numbers[0];
            let source_start = numbers[1];
            let range = numbers[2];

            let map_range = MapRange::new(destination_start, source_start, range)?;

            mapped_ranges.push(map_range);            
        }

        Ok((Map { mapped_ranges }, input))
    }

    fn get_mapped_value(&self, value: u64) -> u64 {
        self.mapped_ranges
            .iter()
            .find(|map_range| map_range.contains_value(value))
            .map(|map_range| map_range.map_value(value))
            .unwrap_or(value)
    }
}

Rather than precomputing all the mappings (silly in hindsight), I now keep track of the ranges, and when asked for a value, I check if it's in the range, map it as necessary, or return the original value.

This small change fixed everything. The process now not only ran, but it was fast. For a change, my over-engineering saved me. Lets hope part 2 doesn't ruin all that.

Part 2

It ruined all that.

Part two changed the game. Instead of the seeds input being a list of seeds, it's now a list of pairs describing the starting seed number and then x number of following seeds.

seeds: 2906961955 52237479 1600322402 372221628

So, this went from 4 seeds to 424,459,107. And that's not the whole input. Oh boi.

I thought about it initially but decided I couldn't eyeball and optimise without a full rewrite, so I did the only logical thing. I brute forced it.

Introducing Rayon, my beloved. tldr; it lets you parallelise iterators with almost zero changes.

pub fn process(input: &str) -> miette::Result<u64> {
    let input = Input::from_str(input)?;

    let data = Data::from_input(input)?;

    let min_location = data
        .seeds()
        .seeds
        .par_iter()
        .map(|seed| data.map_seed(*seed))
        .min()
        .ok_or(Error::NoMinValue)?;

    Ok(min_location)
}

The only change here is iter -> par_iter, (Yes, this is one of the many reasons I love Rust and this library). I then changed the Seeds component to handle the pairings.

impl Seeds {
    #[tracing::instrument]
    fn from_input(mut input: Input) -> Result<ParserOutput<Seeds>> {
        let first_line = input.next().map_err(|_| Error::CannotFindSeedsHeader)?;

        if !first_line.starts_with("seeds:") {
            return Err(Error::CannotFindSeedsHeader);
        }

        let seed_pairs = first_line
            .split(':')
            .last()
            .ok_or_else(|| Error::CannotFindSeedsHeader)?
            .split(' ')
            .filter(|s| !s.is_empty())
            .map(|s| s.trim().parse::<u64>().map_err(Error::CouldNotParseNumber))
            .collect::<Result<Vec<_>>>()?;

        let mut seeds = Vec::new();

        for seed_pair in seed_pairs.chunks(2) {
            let seed = seed_pair[0];
            let count = seed_pair[1];

            for i in 0..count {
                seeds.push(seed + i);
            }
        }

        Ok((Seeds { seeds }, input))
    }
}

And with that, we were off. It took my Apple M2 Max 7 minutes to compute, and used just shy of 16GB of RAM. Damn.

This is clearly not the right solution, but it worked so I won't lament it. Part of my taking part in this is to accept "good enough" solutions. At least before I optimise them

Optimisation

I don't see any need to optimise part 1, or anywhere where I could make significant inroads.

Part 2 needs revisiting. I've tried a few things but not finished them. If I do I will update this post. Things I've considered trying:

Working from the bottom up. We know the minimum locations, what if we worked backwards from that to get an input seed range?
Operate only on ranges. Change the seeds to ranges and apply the mappings that way.

Thoughts

This was good. Evil but good. Everyone I know was caught off guard by the sudden explosion in size either causing insane run-times and or out-of-memory errors everywhere. If this is a sign of things to come and it's only day five, I'm a little worried 🤣.

Results

day_05    fastest       │ slowest       │ median        │ mean
├─ part1  57.2 µs       │ 370.5 µs      │ 62.06 µs      │ 79.74 µs
╰─ part2 7 minutes

Advent of Code 2023 - Day 04

Zoe Aubert | GeekyAubergine — Mon, 04 Dec 2023 15:30:00 +0000

Advent of Code is a yearly programming challenge. See my day 01 post to see how the project is set up.

To view my solutions in full, check them out on GitHub. See my previous posts for other solutions.

Initial solutions

Part 1

Today saw us parsing scratchcards.

Card 1: 41 48 83 86 17 | 83 86  6 31 17  9 48 53

Each card has a number, a set of winning numbers on the left of the | and the player's numbers on the right. In this case, this is card 1, the winning numbers are 41 48 83 86 17 and the player's numbers are 83 86 6 31 1 7 9. If the player has revealed a winning number, the card is worth 1 point, if the player reveals any more winning numbers it doubles for each additional winner.

I started with a function to parse each line and extract the numbers from it. This is built around splitting and parsing. The code is pretty self-explanatory. The ok_or is for error handling to change Option (null) to an error.

pub fn score_line(line: &str) -> Result<u32> {
    let numbers = line
        .split(':')
        .last()
        .ok_or(Error::CannotFindNumbers { line: 0 })?;

    let mut numbers = numbers.split('|');

    let winning_numbers = numbers
        .next()
        .ok_or(Error::CannotFindWinningNumbers { line: 0 })?
        .split(' ')
        .filter(|n| !n.is_empty())
        .map(|n| {
            n.parse::<u32>()
                .map_err(|_| Error::CouldNotParseNumber(n.to_string()))
        })
        .collect::<Result<Vec<_>>>()?;

    let scratch_numbers = numbers
        .last()
        .ok_or(Error::CannotFindScratchedNumbers { line: 0 })?
        .split(' ')
        .filter(|n| !n.is_empty())
        .map(|n| {
            n.parse::<u32>()
                .map_err(|_| Error::CouldNotParseNumber(n.to_string()))
        })
        .collect::<Result<Vec<_>>>()?;
}

From here, it's pretty easy to add the scoring part:

pub fn score_line(line: &str) -> Result<u32> {
    let numbers = line
        .split(':')
        .last()
        .ok_or(Error::CannotFindNumbers { line: 0 })?;

    let mut numbers = numbers.split('|');

    let winning_numbers = numbers
        .next()
        .ok_or(Error::CannotFindWinningNumbers { line: 0 })?
        .split(' ')
        .filter(|n| !n.is_empty())
        .map(|n| {
            n.parse::<u32>()
                .map_err(|_| Error::CouldNotParseNumber(n.to_string()))
        })
        .collect::<Result<Vec<_>>>()?;

    let scratch_numbers = numbers
        .last()
        .ok_or(Error::CannotFindScratchedNumbers { line: 0 })?
        .split(' ')
        .filter(|n| !n.is_empty())
        .map(|n| {
            n.parse::<u32>()
                .map_err(|_| Error::CouldNotParseNumber(n.to_string()))
        })
        .collect::<Result<Vec<_>>>()?;

    let winning_scratched = winning_numbers
        .iter()
        .filter(|n| scratch_numbers.contains(n))
        .count();

    if winning_scratched == 0 {
        return Ok(0);
    }

    Ok(1 << (winning_scratched - 1))
}

The "worth one point and then doubling" lent itself nicely to bit shifting. This feels much neater than other solutions and doesn't require an additional loop. From there it was pretty easy to turn this into a full solution.

pub fn process(input: &str) -> miette::Result<u32> {
    let out = input
        .lines()
        .map(|line| score_line(line.trim()))
        .collect::<Result<Vec<_>>>()
        .map(|v| v.iter().sum())?;

    Ok(out)
}

Part 2

The second part was much more interesting, rather than a card scoring points. For each winning number, it gave you a copy of the next n number of winning cards to scratch off. For example, card 1 has four winning numbers, so you get a copy of cards 2, 3, 4, and 5. This process then repeats for all of the player's cards. If you have multiple copies of a card, you play them all. For example, after winning a copy of card 2, you would play it twice, win twice, and get two additional copies of cards 3 and 4.

To keep track of the number of copies of each card the player has, the best solution is a HashMap, as it allows quick indexing and modification by an index (card number).

struct Cards {
    copies: HashMap<u32, u32>,
}

impl Cards {
    fn new() -> Self {
        Self {
            copies: HashMap::new(),
        }
    }

    fn add_card(&mut self, card: u32) {
        *self.copies.entry(card).or_insert(0) += 1;
    }

    fn add_card_copies(&mut self, card: u32, copies: u32) {
        *self.copies.entry(card).or_insert(0) += copies;
    }

    fn get_count(&self, card: u32) -> u32 {
        *self.copies.get(&card).unwrap_or(&0)
    }
}

From there the code looks pretty similar bar the new way of scoring

pub fn score_line(line: &str, mut cards: Cards) -> Result<Cards> {
    let mut card_and_numbers = line.split(':');

    let card_number = card_and_numbers
        .next()
        .ok_or_else(|| Error::CannotFindCardNumber(line.to_owned()))?
        .split(' ')
        .last()
        .ok_or_else(|| Error::CannotFindCardNumber(line.to_owned()))?
        .parse::<u32>()
        .map_err(|_| Error::CouldNotParseCardNumber(line.to_owned()))?;

	// Add self for the original copy of card
    cards.add_card(card_number);

    let numbers = card_and_numbers
        .last()
        .ok_or(Error::CannotFindNumbers { line: 0 })?;

    let mut numbers = numbers.split('|');

    let winning_numbers = numbers
        .next()
        .ok_or(Error::CannotFindWinningNumbers { line: 0 })?
        .split(' ')
        .filter(|n| !n.is_empty())
        .map(|n| {
            n.parse::<u32>()
                .map_err(|_| Error::CouldNotParseNumber(n.to_string()))
        })
        .collect::<Result<Vec<_>>>()?;

    let scratch_numbers = numbers
        .last()
        .ok_or(Error::CannotFindScratchedNumbers { line: 0 })?
        .split(' ')
        .filter(|n| !n.is_empty())
        .map(|n| {
            n.parse::<u32>()
                .map_err(|_| Error::CouldNotParseNumber(n.to_string()))
        })
        .collect::<Result<Vec<_>>>()?;

    let winning_scratched = winning_numbers
        .iter()
        .filter(|n| scratch_numbers.contains(n))
        .count();

    let copies = cards.get_count(card_number);

    for i in 1..=winning_scratched {
        cards.add_card_copies(card_number + i as u32, copies);
    }

    Ok(cards)
}

Note that because this is going to be used in a fold(reduce) function, this function takes mutable ownership of Cards and returns the mutated copy rather than mutating by reference. There are ways to do it by reference, but this is much cleaner.

pub fn process(input: &str) -> miette::Result<u32> {
    let mut lines = input.lines();

    let cards = lines.try_fold(Cards::new(), |cards, line| score_line(line.trim(), cards))?;

    let card_count = input
        .lines()
        .enumerate()
        .map(|(i, _line)| cards.get_count(i as u32 + 1))
        .sum::<u32>();

    Ok(card_count)
}

I'm happy with this implementation as it feels clean and clear.

Optimisation

After playing around with it for a bit, I only found one optimisation of use. Rather than using my previous technique for parsing numbers, I built a new function to do it:

fn parse_numbers(input: &str) -> Result<Vec<u32>> {
    let input = input.trim();

    let mut in_number = false;
    let mut numbers = vec![];
    let mut number_start = 0;

    for (i, c) in input.chars().enumerate() {
        if c.is_ascii_digit() {
            if !in_number {
                in_number = true;
                number_start = i;
            }
        } else if in_number {
            numbers.push(
                input[number_start..i]
                    .parse()
                    .map_err(|_| Error::CouldNotParseNumber(input.to_string()))?,
            );
            in_number = false;
        }
    }

    if in_number {
        numbers.push(
            input[number_start..]
                .parse()
                .map_err(|_| Error::CouldNotParseNumber(input.to_string()))?,
        );
    }

    Ok(numbers)
}

fn score_line(line: &str) -> Result<u32> {
    let numbers = line
        .split(':')
        .last()
        .ok_or(Error::CannotFindNumbers { line: 0 })?;

    let mut numbers = numbers.split('|');

    let winning_numbers = numbers
        .next()
        .ok_or(Error::CannotFindWinningNumbers { line: 0 })?;

    let winning_numbers = parse_numbers(winning_numbers)?;

    let scratch_numbers = numbers
        .last()
        .ok_or(Error::CannotFindScratchedNumbers { line: 0 })?;

    let scratch_numbers = parse_numbers(scratch_numbers)?;

    let winning_scratched = winning_numbers
        .iter()
        .filter(|n| scratch_numbers.contains(n))
        .count();

    if winning_scratched == 0 {
        return Ok(0);
    }

    Ok(1 << (winning_scratched - 1))
}

Doing this yielded a ~1.4x improvement for both part 1 and part 2.

I did try a few other things, including making winning_numbers a HashSet rather than an array, but the upfront cost seemed to contract any gains, which is expected on a data set of this size.

Results

day_04        fastest       │ slowest       │ median        │ mean
├─ part1      157.9 µs      │ 213.4 µs      │ 164.9 µs      │ 167.3 µs
├─ part1_opt  114.4 µs      │ 152.3 µs      │ 114.7 µs      │ 116.7 µs
├─ part2      189.4 µs      │ 227.6 µs      │ 192.8 µs      │ 193.5 µs
╰─ part2_opt  136.8 µs      │ 164.2 µs      │ 140.5 µs      │ 141.8 µs

Advent of Code 2023 - Day 03

Zoe Aubert | GeekyAubergine — Sun, 03 Dec 2023 14:55:00 +0000

Advent of Code is a yearly programming challenge. See my day 01 post to see how the project is set up.

To view my solutions in full, check them out on GitHub. See my previous posts for other solutions.

Updated 07:40 2023-12-04 with part 1 optimisation

Initial solutions

Part 1

Today saw us finding numbers adjacent to symbols and adding them up. Sounds pretty simple on paper, but this caused me some headaches.

My first headache came from trying to be clever too soon, and instead of doing "numbers adjacent to symbols", I did "symbols adjacent to numbers". This led to the rather funny issue where if two symbols touched the same number (for example, .#545%. ) it would get counted twice. It's not that big of an issue, and it was caught by the sample data.

Then, the real fun began. I was stuck for a while with a solution that was wrong. Clearly, there was some bug not caught by the sample data but present in the larger data. I tried eyeballing it for a while, but it was too large to spot. So I ended up building a frankly ridiculous test.

fn it_should_extract_part_numbers_adjacent_to_symbol() -> miette::Result<()> {
        let input = include_str!("../input1.txt");

        let part_numbers = input
            .lines()
            .enumerate()
            .flat_map(|(i, line)| extract_part_numbers_from_line(line.trim(), i as u32))
            .collect::<Vec<_>>();

        let symbols = input
            .lines()
            .enumerate()
            .flat_map(|(i, line)| extract_symbols_from_line(line.trim(), i as u32))
            .collect::<Vec<_>>();

        let parts_next_to_symbols = part_numbers_adaject_to_a_symbol(&part_numbers, &symbols);

        let expect_part_numbers = vec![
            155, 944, 622, 31, 264, 532, 254, 528, //line 1
            111, 495, 558, //line 2
            791, 62, 618, 818, 642, 789, //line 3
            58, 405, 542, 587, 198, 846, 647, // line 4
            964, 474, 302, 786, 43, 505, 436, 51, //line 5
            832, 951, 984, 111, 198, 322, 186, 262, //line 6
            490, 690, 346, 702, 566, 192, 190, 87, //line 7
            816, 588, 152, 535, 425, 53, //line 8
            36, 290, 831, 374, 579, 536, 733, 169, 146, 179, 658, 260, // line 9
            795, 776, 790, 871, 281, // line 10
            78, 716, 400, 319, 167, 399, 599, // line 11
            719, 376, 800, 211, 478, 326, 93, 889, 684, 285, // line 12
            852, 462, 374, 603, 369, // line 13
            960, 966, 321, 925, 926, 947, // line 14
            479, 909, 339, 17, 284, 657, 587, // line 15,
            772, 345, 93, 465, 419, 676, 521, 399, 662, // line 16
            17, 2, 531, 79, 589, 198, 734, 534, 614, // line 17
            301, 321, 895, 344, 694, 717, 511, // line 18
            707, 370, 428, 509, 889, 353, // line 19
            973, 877, 855, 955, 670, 682, 150, 958, 197, 555, // line 20
            504, 352, 468, 688, 10, 306, // line 21
            987, 5, 811, 705, 462, 374, 42, // line 22
            402, 804, 295, 406, 150, 22, 429, 268, 324, // line 23
            270, 982, 644, 87, 505, //  line 24
            98, 370, 19, 867, 396, 272, 760, // line 25
            593, 793, 503, 34, 406, 456, 303, 142, 432, // line 26
            707, 563, 837, 230, 169, 138, 420, // line 27
            689, 503, 449, 39, 77, 404, // line 28
            137, 624, 883, 891, 310, 404, // line 29
            287, 961, 488, 544, 130, 531, 72, 424, 766, // line 30
            476, 722, 780, 613, 533, 96, 553, 91, 835, 690, // line 31
            350, 950, 359, 141, 326, 658, 832, // line 32
            772, 127, 335, 539, 101, 959, 221, 512, // line 33
            798, 138, 207, 999, 574, 484, 364, // line 34
            919, 202, 971, 488, 349, 404, 448, // line 35
            246, 211, 426, 206, 557, 27, 659, 588, 367, 961, 583, 280, // line 36
            724, 324, 788, 685, 788, 532, 85, 139, 75, 196, // line 37
            521, 391, 987, 810, 214, // line 38
            679, 776, 447, 457, 25, 467, 173, 241, // line 39
            43, 898, 412, 742, 540, 825, 259, 997, 514, // line 40
            775, 52, 809, 871, 384, 295, 470, 114, // line 41
            147, 69, 914, 144, 875, 278, 441, 859, 346, 281, 40, // line 42
            89, 578, 519, 676, 473, 361, // line 43
            78, 42, 750, 465, 218, 833, 137, 538, 962, 421, 502, 42, // line 44
            457, 825, 26, 238, 205, 539, 109, 348, 837, 842, // line 45
            175, 925, 399, 560, 636, // line 46
            693, 447, 137, 679, 479, 619, 283, 458, 544, 802, 848, // line 47
            39, 141, // line 48
            471, 502, 663, 986, 633, 530, 598, 220, 542, 568, 219, 532, 15,  // line 49
            840, // line 50
            351, 993, 573, 865, 848, 239, 134, 64, 231, // line 51
            809, 925, 43, 277, 571, // line 52
            698, 355, 55, 847, 409, 78, 363, // line 53
            261, 591, 695, 678, 714, 364, 804, 156, 605, // line 54
            192, 957, 963, 447, 344, // line 55
            524, 568, 691, 169, 218, 10, 10, 399, 46, 488, 491, 16, // line 56
            824, 772, 265, 964, // line 57
            345, 161, 671, 414, 726, 564, // line 58
            155, 483, 546, 968, 591, // line 59
            806, 120, 813, 481, 593, 667, 815, 682, 579, 298, 668, 188, // line 60
            718, 469, 251, 52, 919, 846, 887, 637, // line 61
            81, 51, 236, 167, 338, 963, 258, 980, 816, // line 62
            150, 316, 389, 590, 291, 143, 284, // line 63
            390, 559, 116, 926, 779, // line 64
            500, 821, 594, 220, 830, 89, 915, 363, // line 65
            623, 337, 40, 827, 828, 294, 392, // line 66
            993, 565, 638, 307, 95, 535, 105, 632, 938, 116, 939, // line 67
            444, 378, 283, 971, 689, 937, 736,
            991, // line 68

                 // 608, 362, 642, 262, 617, // line 140
        ];

        assert_eq!(expect_part_numbers, parts_next_to_symbols);
        Ok(())
    }

Is this insane? Yes. But I was convinced I'd got the core logic right, and there was something funky in the input I wasn't expecting. So, I went line by line of the input and compared it after each save.

Eventually, on line 67 of the input I found my bug and was able to build a test case around it.

    fn it_should_parse_lines_66_to_68() -> miette::Result<()> {
        let input = "
        ...*...623....337.......................40..........827..............*................828....$294....392....*....*.....%..............*.....
        .993............*....565........................638...............307.............95.......#..............535.105.........632..938.166..$939
        .....$..444@...378...*.......4...283...971@.......*...................689..937...*.......736......@...................991..@....*...........";

        let part_numbers = input
            .lines()
            .enumerate()
            .flat_map(|(i, line)| extract_part_numbers_from_line(line.trim(), i as u32))
            .collect::<Vec<_>>();

        let expected_part_numbers: Vec<u32> = vec![
            623, 337, 40, 827, 828, 294, 392, // line 66
            993, 565, 638, 307, 95, 535, 105, 632, 938, 166, 939, // line 67
            444, 378, 4, 283, 971, 689, 937, 736, 991, // line 68
        ];

        assert_eq!(expected_part_numbers, part_numbers.iter().map(|p| p.number).collect::<Vec<_>>());

        let symbols = input
            .lines()
            .enumerate()
            .flat_map(|(i, line)| extract_symbols_from_line(line.trim(), i as u32))
            .collect::<Vec<_>>();

        let parts_next_to_symbols = part_numbers_adaject_to_a_symbol(&part_numbers, &symbols);

        // There's some numbers missing from 66 and 68, that's because this is a slice so the row above doesn't trigger them
        let expect_part_numbers = vec![
            337, 294, // line 66
            993, 565, 638, 307, 95, 535, 105, 632, 938, 166, 939, // line 67
            444, 378, 971, 736 // line 68
        ];

        assert_eq!(expect_part_numbers, parts_next_to_symbols);
        Ok(())
    }

It was a flaw in my number parsing. Line 67 is the first time a number appears at the end of the line without a non-digit following it. And my parser didn't account for that. It was annoying, but at least I was justified by the insanity that is that test.

Now that it's working, I can talk about my solution. Again, I went for reliability over performance (mostly so I can feel good about my later optimisations 😉). First were some simple structs and constructors:

struct PartNumber {
    x: u32,
    y: u32,
    width: u32,
    number: u32,
}

impl PartNumber {
    fn new(x: u32, y: u32, width: u32, number: u32) -> Self {
        Self {
            x,
            y,
            width,
            number,
        }
    }
}

struct Symbol {
    x: u32,
    y: u32,
    symbol: char,
}

impl Symbol {
    fn new(x: u32, y: u32, symbol: char) -> Self {
        Self { x, y, symbol }
    }

    fn postition_equals(&self, x: u32, y: u32) -> bool {
        self.x == x && self.y == y
    }
}

Then it was a simple case of parsing each line and extracting the part numbers and symbols.

fn extract_part_numbers_from_line(line: &str, line_index: u32) -> Vec<PartNumber> {
    let mut part_numbers = Vec::new();

    let mut in_digits = false;
    let mut number_start = 0;

    for (i, c) in line.char_indices() {
        if c.is_ascii_digit() {
            if !in_digits {
                in_digits = true;
                number_start = i;
            }
        } else if in_digits {
            in_digits = false;
            let number = line.get(number_start..i).unwrap().parse::<u32>().unwrap();
            part_numbers.push(PartNumber::new(
                number_start as u32,
                line_index,
                i as u32 - number_start as u32,
                number,
            ));
        }
    }

	// This is where my bug was, I didn't have this block so a trailing number would be lost
    if in_digits {
        let number = line.get(number_start..).unwrap().parse::<u32>().unwrap();
        part_numbers.push(PartNumber::new(
            number_start as u32,
            line_index,
            line.len() as u32 - number_start as u32,
            number,
        ));
    }

    part_numbers
}

#[tracing::instrument]
fn extract_symbols_from_line(line: &str, line_index: u32) -> Vec<Symbol> {
    let mut symbols = Vec::new();

    for (i, c) in line.char_indices() {
        if !c.is_ascii_digit() && c != '.' {
            symbols.push(Symbol::new(i as u32, line_index, c));
        }
    }

    symbols
}

Ok, cool, this works, now for the complex bit. Finding parts with an adjacent symbol.

impl PartNumber {
    fn has_adjacent_symbol(&self, symbol: &[Symbol]) -> bool {
        let start_x = if self.x == 0 { 0 } else { self.x - 1 }; // Rust doesn't have ternary operators, you do this instead
        let end_x = self.x + self.width + 1;
        let start_y = if self.y == 0 { 0 } else { self.y - 1 };
        let end_y = self.y + 1;

        for x in start_x..end_x {
            for y in start_y..=end_y {
                if symbol.iter().any(|s| s.postition_equals(x, y)) {
                    return true;
                }
            }
        }

        false
    }
}

Slightly cursed, but it works. I loop in a box around the part number and return true as soon as we see a symbol. Using this function, it's easy to find part numbers with an adjacent symbol, and then do the summation.

fn part_numbers_adaject_to_a_symbol(part_numbers: &[PartNumber], symbols: &[Symbol]) -> Vec<u32> {
    part_numbers
        .iter()
        .filter(|part_number| part_number.has_adjacent_symbol(symbols))
        .map(|part_number| part_number.number)
        .collect::<Vec<_>>()
}

pub fn process(input: &str) -> miette::Result<u32> {
    let part_numbers = input
        .lines()
        .enumerate()
        .flat_map(|(i, line)| extract_part_numbers_from_line(line.trim(), i as u32))
        .collect::<Vec<_>>();

    let symbols = input
        .lines()
        .enumerate()
        .flat_map(|(i, line)| extract_symbols_from_line(line.trim(), i as u32))
        .collect::<Vec<_>>();

    let parts_next_to_symbols = part_numbers_adaject_to_a_symbol(&part_numbers, &symbols);

    let sum = parts_next_to_symbols.iter().sum::<u32>();

    Ok(sum)
}

Part 2

Part two, funnily enough, saw us finding pairs of numbers surrounding the * symbol, which is very close to what I was originally doing. The changes to make this work were fairly minimal. First was making parts searchable and symbols able to search for them.

impl PartNumber {
    fn contains_point(&self, x: i32, y: i32) -> bool {
        let start_x = self.x;
        let end_x = self.x + self.width;

        x >= start_x && x < end_x && y == self.y
    }
}

impl Symbol {
    fn adjacent_part_numbers(&self, part_numbers: &[PartNumber]) -> Vec<i32> {
        part_numbers
            .iter()
            .filter(|part_number| {
                part_number.contains_point(self.x - 1, self.y) // left
                    || part_number.contains_point(self.x + 1, self.y) // right
                    || part_number.contains_point(self.x, self.y - 1) // top
                    || part_number.contains_point(self.x, self.y + 1) // bottom
                    || part_number.contains_point(self.x - 1, self.y - 1) // top left
                    || part_number.contains_point(self.x + 1, self.y - 1) // top right
                    || part_number.contains_point(self.x - 1, self.y + 1) // bottom left
                    || part_number.contains_point(self.x + 1, self.y + 1) // bottom right
            })
            .map(|part_number| part_number.number)
            .collect::<Vec<_>>()
    }
}

There was a small change to symbol parsing, mostly to skip anything that isn't *.

fn extract_symbols_from_line(line: &str, line_index: i32) -> Vec<Symbol> {
    let mut symbols = Vec::new();

    for (i, c) in line.char_indices() {
        if c == '*' {
            symbols.push(Symbol::new(i as i32, line_index, c));
        }
    }

    symbols
}

It was then again a case of just throwing these functions together to get them to work. This is kinda iterator-heavy, but hopefully, it's fine to follow.

fn symbols_with_2_adjacent_part_numbers(
    symbols: &[Symbol],
    part_numbers: &[PartNumber],
) -> Vec<i32> {
    symbols
        .iter()
        .map(|symbol| symbol.adjacent_part_numbers(part_numbers))
        .filter(|adjacent_part_numbers| adjacent_part_numbers.len() == 2)
        .map(|adjacent_part_numbers| adjacent_part_numbers.iter().product())
        .collect::<Vec<_>>()
}

#[tracing::instrument]
pub fn process(input: &str) -> miette::Result<i32> {
    let part_numbers = input
        .lines()
        .enumerate()
        .flat_map(|(i, line)| extract_part_numbers_from_line(line.trim(), i as i32))
        .collect::<Vec<_>>();

    let symbols = input
        .lines()
        .enumerate()
        .flat_map(|(i, line)| extract_symbols_from_line(line.trim(), i as i32))
        .collect::<Vec<_>>();

    let gear_ratios = symbols_with_2_adjacent_part_numbers(&symbols, &part_numbers);

    let sum = gear_ratios.iter().sum::<i32>();

    Ok(sum)
}

This felt much easier than part 1, but I think that's because I didn't spend an hour doing manual data entry to find my bug.

Optimisation

Part1

After a break, I decided to give optimisation another go.

Part2

I have chosen not to optimise part 2 as I don't see a nice way to do it. I have some guesses, but they all look quite ugly.

struct Data {
    symbol_map: Vec<bool>,
    width: usize,
}

impl Data {
    #[tracing::instrument]
    fn new(input: &String) -> Self {
        let is_symbol = input
            .lines()
            .flat_map(|line| line.chars())
            .map(|c| is_symbol(Some(c)))
            .collect::<Vec<_>>();
        let width = input.lines().next().unwrap().len();

        Self { width, symbol_map }
    }

    #[tracing::instrument]
    fn is_symbol(&self, x: i32, y: i32) -> bool {
        if x < 0 || y < 0 {
            return false;
        }

        match self.symbol_map.get(y as usize * self.width + x as usize) {
            Some(v) => *v,
            None => false,
        }
    }
}

This time, rather than accessing the strings as needed, I precompute whether or not a character is a symbol for the entire input. This may seem expensive, and I tried some other methods, but this came out the fastest. Doing this allows for fast lookups when processing the numbers.

A small but non-insignificant change was the way I was calculating if a character is a symbol.

fn is_symbol(char: Option<char>) -> bool {
    match char {
        Some(c) => {
            matches!(c, '-' | '%' | '+' | '=' | '*' | '/' | '$' | '#' | '&' | '@')
        }
        None => false,
    }
}

Rather than checking for any symbol, it only checks the ones present in the input. And thank you to clippy for suggesting the matches!, it's very cool (it expands to a match statement returning true for the items listed and false for everything else).

Processing each line has become more complex. While the basic outline and operations remain unchanged, there's some extra fun.

fn parse_line(line: &str, y: i32, data: &Data) -> Vec<u32> {
    let mut in_number = false;
    let mut number_start = 0;
    let mut adjacent_symbol = false;

    let mut numbers = vec![];

    for (i, c) in line.chars().enumerate() {
        let i_as_i32 = i as i32;
        if c.is_ascii_digit() {
            if !in_number {
                in_number = true;
                number_start = i;

                // Previous
                if data.is_symbol(i_as_i32 - 1, y)
                    || data.is_symbol(i_as_i32 - 1, y - 1)
                    || data.is_symbol(i_as_i32 - 1, y + 1)
                {
                    adjacent_symbol = true;
                }
            }

            // Above below
            if (data.is_symbol(i_as_i32, y - 1)) || (data.is_symbol(i_as_i32, y + 1)) {
                adjacent_symbol = true;
            }
        } else if in_number {
            // Check self, above and below
            if data.is_symbol(i_as_i32, y)
                || data.is_symbol(i_as_i32, y - 1)
                || data.is_symbol(i_as_i32, y + 1)
            {
                adjacent_symbol = true;
            }

            if adjacent_symbol {
                numbers.push(line[number_start..i].parse().unwrap());
            }

            in_number = false;
            adjacent_symbol = false;
        }
    }

    if in_number
        && (adjacent_symbol
            || data.is_symbol(line.len() as i32 - 1, y - 1)
            || data.is_symbol(line.len() as i32 - 1, y + 1))
    {
        numbers.push(line[number_start..].parse().unwrap());
    }

    numbers
}

After finding the first digit like we did before, we then immediately look left and diagonally left to see if we can find a symbol.

if data.is_symbol(i_as_i32 - 1, y)
	|| data.is_symbol(i_as_i32 - 1, y - 1)
	|| data.is_symbol(i_as_i32 - 1, y + 1)
{
	adjacent_symbol = true;
}

Then, for every digit following we do similar, and check above and below the current character.

if (data.is_symbol(i_as_i32, y - 1)) || (data.is_symbol(i_as_i32, y + 1)) {
	adjacent_symbol = true;
}

Then, once we've reached the end of the number, we have to check right, and diagonally right. But, we only know if we've reached the end of the number if we've seen a non-number character, so what we really need to do is check the current character, and above and below that, which has the same effect as checking right and diagonally because we're already one character to the right.

if data.is_symbol(i_as_i32, y)
	|| data.is_symbol(i_as_i32, y - 1)
	|| data.is_symbol(i_as_i32, y + 1)
{
	adjacent_symbol = true;
}

The only thing to do then is not to fall prey to my earlier bug and also check if we've reached the end of the line but are still in a number. Again, here, we have to check above and below on the final character for a symbol.

if in_number
	&& (adjacent_symbol
		|| data.is_symbol(line.len() as i32 - 1, y - 1)
		|| data.is_symbol(line.len() as i32 - 1, y + 1))
{
	numbers.push(line[number_start..].parse().unwrap());
}

Combing it all together is then a simple case of:

pub fn process(input: &str) -> miette::Result<u32> {
    let input = input
        .lines()
        .map(|line| line.trim())
        .collect::<Vec<_>>()
        .join("\n");

    let data = Data::new(&input);

    let sum = input
        .lines()
        .enumerate()
        .flat_map(|(y, line)| parse_line(line, y as i32, &data))
        .sum::<u32>();

    Ok(sum)
}

Using these techniques has yielded a rather silly performance increase of 59x, taking us from the ~7ms area to ~120µs.

Overall, I think this is a fairly intuitive optimisation. But I am very pleased with the results. I'm also glad I did it the more over-engineered way first as I would likely have had an even worse time debugging this approach to find my bug.

Additional Notes

This has been a lesson in not trusting their example input to cover all possible gotchas, I know there was one present in day-01 but I managed to avoid it, and in my hubris assumed it couldn't happen to me 🤣

Results

day_03        fastest       │ slowest       │ median        │ mean
├─ part1      7.107 ms      │ 15.85 ms      │ 7.342 ms      │ 7.564 ms
├─ part1_opt  123.7 µs      │ 150.4 µs      │ 124.1 µs      │ 126.7 µs 
╰─ part2      6.111 ms      │ 6.834 ms      │ 6.355 ms      │ 6.358 ms

Advent of Code 2023 - Day 02

Zoe Aubert | GeekyAubergine — Sat, 02 Dec 2023 18:00:00 +0000

Advent of Code is a yearly programming challenge. See my previous post to see how the project is set up.

To view my solutions in full, check them out on GitHub. See my previous posts for other solutions.

Initial solutions

Part 1

Today saw us calculating if it was possible to draw a "hand" of cubes out of a bag containing a set number of cubes. We were told that the bag contains 12 red cubes, 13 green cubes, and 14 blue cubes, so drawing 10 red cubes would be valid, but 20 would not.

My initial approach is possibly a little over-engineered, but here we are. I built structs (objects) to store the data I needed.

struct Bag {
    red: u8,
    green: u8,
    blue: u8,
}

struct Hand {
    red: u8,
    green: u8,
    blue: u8,
}

struct Game {
    id: u32,
    hands: Vec<Hand>, // Vec = array
}

I decided it would be best to work from backwards and parse the smallest bits of data before tackling the larger stuff, so I set up a test and built a parser for each hand. The input into this parser is 1 red, 2 green, 3 blue.

impl Hand {
    fn from_str(input: &str) -> Result<Self> {
        let mut hand = Self {
            red: 0,
            green: 0,
            blue: 0,
        };

        for card in input.split(',') {
            let parts = card.trim().split(' ').collect::<Vec<_>>();

            let count = parts
                .first()
                .ok_or_else(|| Error::CouldNotParseColorCount(card.to_string()))?;
            let color = parts
                .last()
                .ok_or_else(|| Error::CouldNotParseColorCount(card.to_string()))?;

            let count = count
                .parse::<u8>()
                .map_err(|_| Error::CouldNotParseCount(count.to_string()))?;

            match *color {
                "red" => hand.red = count,
                "green" => hand.green = count,
                "blue" => hand.blue = count,
                _ => return Err(Error::UnknownColor(color.to_string())),
            }
        }

        Ok(hand)
    }

    fn is_possible(&self, bag: &Bag) -> bool {
        self.red <= bag.red && self.green <= bag.green && self.blue <= bag.blue
    }
}

I also added a function to check if the hand was valid for any given bag. There's a fair bit of error handling here, but it's not too messy. It splits the string on ,, finds the number part, parses it, parses the colour component, and throws suitable errors.

For non-Rust people, impl allows you to add functions to a struct. If you're familiar with object-oriented programming, then these are similar to class methods. In Rust, we define the data structures separately from the implementation. This might seem weird, but it does have more advantages down the line.

After getting that down, it was then just a process of adding parsers that relied upon previously built parsers.

impl Game {
    fn from_str(input: &str) -> Result<Self> {
        let id_and_hands = input.split(':').collect::<Vec<_>>();

        let id = id_and_hands
            .first()
            .ok_or_else(|| Error::CouldNotParseGameId(input.to_string()))?
            .trim()
            .split(' ')
            .nth(1)
            .ok_or_else(|| Error::CouldNotParseGameId(input.to_string()))?
            .parse::<u32>()
            .map_err(|_| Error::CouldNotParseGameId(input.to_string()))?;

        let hands = id_and_hands
            .last()
            .ok_or_else(|| Error::CouldNotParseGameHands(input.to_string()))?;

        let hands = hands
            .split(';')
            .map(Hand::from_str)
            .collect::<Result<Vec<_>>>()?;

        Ok(Self { id, hands })
    }

    fn is_possible(&self, bag: &Bag) -> bool {
        self.hands.iter().all(|hand| hand.is_possible(bag))
    }
}

pub fn process(input: &str) -> miette::Result<u32> { // Main function
    let bag = Bag {
        red: 12,
        green: 13,
        blue: 14,
    };

    let games = input
        .lines()
        .map(Game::from_str)
        .collect::<Result<Vec<_>>>()?;

    let possible_games = games
        .iter()
        .filter(|game| game.is_possible(&bag))
        .map(|game| game.id)
        .sum();

    Ok(possible_games)
}

I am leaning quite heavily into iterators here, but hopefully, if you're familiar with using them in other languages or lambda-like functions, these won't seem too weird. ok_or_else transforms an Option (a different way of handling null) into an error if it's None/null.

Overall, this wasn't too complex, and I feel the code is pretty clean.

Part 2

Part 2 was possibly easier than Part 1. It was very simple to change the logic from "is hand possible" to "work out the max hand". The only real change was to Game.

impl Game {
    fn min_possible_bag(&self) -> Bag {
        let mut bag = Bag {
            red: 0,
            green: 0,
            blue: 0,
        };

        for hand in &self.hands {
            bag.red = bag.red.max(hand.red);
            bag.green = bag.green.max(hand.green);
            bag.blue = bag.blue.max(hand.blue);
        }

        bag
    }

    #[tracing::instrument]
    fn power_set(&self) -> u32 {
        let bag = self.min_possible_bag();

        bag.red as u32 * bag.green as u32 * bag.blue as u32
    }
}

With this, it was easy to change the process function to respect it.

pub fn process(input: &str) -> miette::Result<u32> {
    let games = input
        .lines()
        .map(Game::from_str)
        .collect::<Result<Vec<_>>>()?;

    let power_sets = games
        .iter()
        .map(|game| game.power_set())
        .collect::<Vec<_>>();

    Ok(power_sets.iter().sum())
}

Optimisation

I had a lot of fun with this.

Part 1

Optimisation Pass 1

While building the initial solution, I spotted a number of areas that could be improved. Mostly parsing more data than necessary. My initial solution parsed everything, and only once it's built a complete picture did it determine the number of possible games. But we know if a game is impossible much more quickly than that. If, at any point, while parsing a hand colour value, we spot a value that is higher than the possible number, we know that nothing else in that game matters as we've broken a rule, so we can exit at that point and declare the game impossible. The first step was parsing the hands:

fn parse_hand_color(input: &str, bag: &Bag) -> Result<bool> {
    let count_chars = input
        .chars()
        .take_while(|c| c.is_ascii_digit())
        .collect::<String>();

    let color_start = count_chars.len() + 1;

    let count = count_chars
        .parse::<u8>()
        .map_err(|_| Error::CouldNotParseCount(input.to_string()))?;

    if count > bag.red || count > bag.green || count > bag.blue {
        return Ok(false);
    }

    let color = input
        .get(color_start..color_start + 1)
        .ok_or_else(|| Error::CouldNotParseColorCount(input.to_string()))?;

    match color {
        "r" => {
            if count > bag.red {
                return Ok(false);
            }
        }
        "g" => {
            if count > bag.green {
                return Ok(false);
            }
        }
        "b" => {
            if count > bag.blue {
                return Ok(false);
            }
        }
        _ => return Err(Error::UnknownColor(color.to_string())),
    }

    Ok(true)
}

fn parse_hand(input: &str, bag: &Bag) -> Result<bool> {
    for card in input.split(',') {
        if !parse_hand_color(card.trim(), bag)? {
            return Ok(false);
        }
    }

    Ok(true)
}

The actual parsing here looks similar to the first parser. Notable differences include not splitting the string but instead using what we know about the structure of the input to be able to jump ahead (this will be important later). And, rather than relying on iterators, moving back to traditional loops and exiting as early as possible.

We also don't return a Hand struct anymore, but instead, just return if the hand is possible or not. One additional trick I pulled was rather than checking the whole colour name, I only check the first letter as we know there are no collisions between the colour's first characters.

The Game and input processing have changed in a similar way.

enum GameResult {
    Possible { game_id: u32 },
    Impossible,
}

fn parse_game(input: &str, bag: &Bag) -> Result<GameResult> {
    let id_chars: String = input
        .chars()
        .skip(5)
        .take_while(|c| c.is_ascii_digit())
        .collect();

    let hands_start = 5 + id_chars.len() + 2;

    let game_id = id_chars
        .parse::<u32>()
        .map_err(|_| Error::CouldNotParseGameId(id_chars))?;

    let hands_text = input[hands_start..].trim();

    for hand in hands_text.split(';') {
        if !parse_hand(hand, bag)? {
            return Ok(GameResult::Impossible);
        }
    }

    Ok(GameResult::Possible { game_id })
}

pub fn process(input: &str) -> miette::Result<u32> {
    let bag = Bag {
        red: 12,
        green: 13,
        blue: 14,
    };

    let mut possible_game_ids = vec![];

    for line in input.lines() {
        let game_result = parse_game(line.trim(), &bag)?;
        match game_result {
            GameResult::Possible { game_id } => {
                possible_game_ids.push(game_id);
            }
            GameResult::Impossible => {}
        }
    }

    Ok(possible_game_ids.iter().sum())
}

I also introduced GameResult to pass the minimum amount of data required back to the caller to be able to determine if the game was possible and what ID it had. I dislike tuples so chose not to use them.

These optimisations resulted in a ~2.6x performance increase, but we can go further.

Optimisation Pass 2

Building on what I touched on before, there's a lot of performance to be gained by our knowledge of the structure of the input.

Game 2: 1 blue, 2 green; 3 green, 4 blue, 1 red; 1 green, 1 blue

We know that the first 5 characters are skippable. We know that after the end of the game ID, there are two characters of dead space, and then we start parsing hands. We then know that after the number of cubes for each colour, there's a space, a colour and then a , or a ;. Turns out we don't care about whether it's a , or a ; as there are no repeated values per hand. So all we actually need to check is each number colour pairing, and we can forget the concept of hands. Additionally, building on the previous, we only need to check the first letter of colour and we automatically know the length of the string and can skip to the next hand without having to parse more data.

Before I show you the code, this is not what I'd call best practices, while there's nothing unsafe, there is potential for index out-of-bounds errors to occur.

enum HandResult {
    Possible { length: usize },
    Impossible,
}

fn parse_hand_color(input: &str, bag: &Bag) -> Result<HandResult> {
    let mut count_chars: String = String::new();

    for c in input[0..5].chars() {
        if c.is_ascii_digit() {
            count_chars.push(c);
        } else {
            break;
        }
    }
    let color_start = count_chars.len() + 1;

    let count = count_chars
        .parse::<u8>()
        .map_err(|_| Error::CouldNotParseCount(input.to_string()))?;

    let color = input
        .get(color_start..color_start + 1)
        .ok_or_else(|| Error::CouldNotParseColorCount(input.to_string()))?;

    match color {
        "r" => {
            if count > bag.red {
                return Ok(HandResult::Impossible);
            } else {
                return Ok(HandResult::Possible {
                    length: color_start + 3,
                });
            }
        }
        "g" => {
            if count > bag.green {
                return Ok(HandResult::Impossible);
            } else {
                return Ok(HandResult::Possible {
                    length: color_start + 5,
                });
            }
        }
        "b" => {
            if count > bag.blue {
                return Ok(HandResult::Impossible);
            } else {
                return Ok(HandResult::Possible {
                    length: color_start + 4,
                });
            }
        }
        _ => return Err(Error::UnknownColor(color.to_string())),
    }
}

Firstly we've gone from using an iterator to a string building for-loop to get the number of cubes in a hand. Previously we were checking for digits on all characters, but we don't need to as we know as soon as we've seen a non-digit character we can stop checking. From there the code is fairly similar to the previous implementation, but this time if it is a possible hand we also return the length of consumed input to allow us to skip to the next hand.

fn parse_game(input: &str, bag: &Bag) -> Result<GameResult> {
    let mut id_chars: String = String::new();

    for c in input[5..10].chars() {
        if c.is_ascii_digit() {
            id_chars.push(c);
        } else {
            break;
        }
    }

    let hands_start = 5 + id_chars.len() + 2;

    let game_id = id_chars
        .parse::<u32>()
        .map_err(|_| Error::CouldNotParseGameId(id_chars))?;

    let mut index = hands_start;

    while index < input.len() {
        let hand = &input[index..];

        let hand_result = parse_hand_color(hand, bag)?;

        match hand_result {
            HandResult::Possible { length } => {
                index += length + 2;
            }
            HandResult::Impossible { .. } => {
                return Ok(GameResult::Impossible);
            }
        }
    }

    Ok(GameResult::Possible { game_id })
}

Using a similar technique to get the game ID, we then use the new hand parser to skip through the list of hands using its returned length. The process function remains unchanged.

This final approach has a ~4.2x performance gain over the initial solution and a ~1.6x over the previously optimised solution. Is the new unreadability worth it? Probably not, but it sure is fun.

Part 2

While there we some changes required to optimise part 2, it's similar to part 1. The parse_hand_color function now returns a hand and colour rather than a validity check.

enum Hand {
    Red { consumed: u8, count: u8 },
    Green { consumed: u8, count: u8 },
    Blue { consumed: u8, count: u8 },
}

fn parse_hand_color(input: &str) -> Result<Hand> {
    let mut count_chars: String = String::new();

    for c in input[0..5].chars() {
        if c.is_ascii_digit() {
            count_chars.push(c);
        } else {
            break;
        }
    }
    let color_start = count_chars.len() + 1;

    let count = count_chars
        .parse::<u8>()
        .map_err(|_| Error::CouldNotParseCount(input.to_string()))?;

    let color = input
        .get(color_start..color_start + 1)
        .ok_or_else(|| Error::CouldNotParseColorCount(input.to_string()))?;

    match color {
        "r" => Ok(Hand::Red {
            consumed: color_start as u8 + 3,
            count,
        }),
        "g" => Ok(Hand::Green {
            consumed: color_start as u8 + 5,
            count,
        }),
        "b" => Ok(Hand::Blue {
            consumed: color_start as u8 + 4,
            count,
        }),
        _ => return Err(Error::UnknownColor(color.to_string())),
    }
}

Simialrly, parse_game saw some changes but still very similar to the part 1 optimistion.

fn parse_game(input: &str) -> Result<u32> {
    let input = input.trim();
        
    let mut hands_start = 0;

    for c in input[0..10].chars() {
        if c.eq(&':') {
            break;
        } else {
            hands_start += 1;
        }
    }

    hands_start += 1;

    let mut index = hands_start;

    let mut max_red: u32 = 0;
    let mut max_green: u32 = 0;
    let mut max_blue: u32 = 0;

    while index < input.len() {
        let hand = &input[index..];

        let hand_result = parse_hand_color(hand.trim())?;

        match hand_result {
            Hand::Red { consumed, count } => {
                max_red = max_red.max(count as u32);
                index += consumed as usize;
            }
            Hand::Green { consumed, count } => {
                max_green = max_green.max(count as u32);
                index += consumed as usize;
            }
            Hand::Blue { consumed, count } => {
                max_blue = max_blue.max(count as u32);
                index += consumed as usize;
            }
        }

        index += 2;
    }

    Ok(max_red * max_green * max_blue)
}

pub fn process(input: &str) -> miette::Result<u32> {
    let power_sets = input.lines().map(parse_game).collect::<Result<Vec<_>>>()?;

    Ok(power_sets.iter().sum())
}

This approach yielded a ~2.8x performance increase.

Additional Notes

I did try going further with the optimisation for part 1, but no changes I made improved upon my second attempt. This included some rather unpleasant un-check array reading and unsafe code, but it was still ultimately slower, which surprised me. And again, multi-threading did not help here as the input data was tiny.

Results

day_02         fastest       │ slowest       │ median        │ mean
├─ part1       77.79 µs      │ 197 µs        │ 159.3 µs      │ 142.4 µs
├─ part1_opt   53.41 µs      │ 82.79 µs      │ 60.08 µs      │ 61.02 µs
├─ part1_opt2  36.66 µs      │ 43.2 µs       │ 37.08 µs      │ 37.45 µs
├─ part2       104.3 µs      │ 144.4 µs      │ 112.8 µs      │ 116.2 µs 
╰─ part2_opt   49.2 µs       │ 58.99 µs      │ 49.49 µs      │ 49.96 µs

Advent of Code 2023 - Day 01

Zoe Aubert | GeekyAubergine — Fri, 01 Dec 2023 13:00:00 +0000

Advent of Code is a yearly programming challenge. I've followed other people doing it before and thought I'd take a crack at it this year. Let's see how far I get. It goes without saying that this post will contain spoilers.

To view my solutions in full, check them out on GitHub. See my previous posts for other solutions.

Setup and structure

Unsurprisingly I'm going to use Rust for this. I had an idea about how I wanted to structure the project but then Chris Biscardi posted a great video outlining their project structure. I've ~~borrowed~~ yoinked their approach and made some small modifications. It's a little confusing at first but if you've used Rust before it's probably fine. The video explains it well.

You'll notice I have part1.rs and part1_opt.rs. I thought it would be to separately store my first pass approach, and a more optimised approach and compare the two. It helps that I have a benchmarking tool that allows me to directly compare my solutions. The benchmarks are stored here.

Initial solutions

Part 1

This was a nice easy start. Given a set of strings, extract the first and last digit from each string, and join them to make a 2 digit number, then sum all the digits. For example, m9qvkqlgfhtwo3seven4seven becomes 94.

To get the digits I first extracted the digits from the string:

fn extract_digits(input: &str) -> Vec<u64> {
    input
        .chars()
        .filter_map(|c| c.to_digit(10))
        .map(|d| d as u64)
        .collect()
}

This is pleasantly easy in Rust. I then took the digits, got the first and last, and build a new string to then parse:

fn number_for_line(line: &str) -> Result<u64> {
    let digits = extract_digits(line);
    let first = digits.first().ok_or_else(|| Error::NoFirstDigitInLine)?;
    let last = digits.last().ok_or_else(|| Error::NoLastDigitInLine)?;
    let string = format!("{}{}", first, last);
    Ok(string.parse::<u64>()?)
}

(If you're new to Rust you can ignore the ok_or_else part, it's just error handling and does not change the way it works).

From there it again, very simple to sum up the value from each line:

pub fn process(input: &str) -> miette::Result<u64> {
    Ok(input
        .lines()
        .map(number_for_line)
        .collect::<Result<Vec<u64>>>()
        .map(|v| v.iter().sum())?)
}

Part 2

Now we get the fun twist. Rather than just parsing digits, we also need to parse the numbers as words. For example eight33 becomes 83.

I took a potentially cursed approach to this but I didn't think RegEx was the right tool for the job, so instead I did this:

fn parse_digit(input: &str) -> Result<u64> {
    let first_char = input
        .chars()
        .next()
        .ok_or_else(|| Error::NoFirstDigitInLine)?;

    if let Some(digit) = first_char.to_digit(10) {
        return Ok(digit as u64);
    }

    if input.starts_with("zero") {
        return Ok(0);
    }

    if input.starts_with("one") {
        return Ok(1);
    }

    if input.starts_with("two") {
        return Ok(2);
    }

    if input.starts_with("three") {
        return Ok(3);
    }

    if input.starts_with("four") {
        return Ok(4);
    }

    if input.starts_with("five") {
        return Ok(5);
    }

    if input.starts_with("six") {
        return Ok(6);
    }

    if input.starts_with("seven") {
        return Ok(7);
    }

    if input.starts_with("eight") {
        return Ok(8);
    }

    if input.starts_with("nine") {
        return Ok(9);
    }

    Err(Error::ParseBasicIntError())
}

Cursed, I know, but it worked and that's kind of what I'm striving for. Wanting to do everything perfectly all the time is a massive problem when it comes to me actually finishing projects. I then use this new parser in a new extract_digits function:

fn extract_digits(input: &str) -> Result<Vec<u64>> {
    let mut digits = Vec::new();
    for i in 0..input.len() {
        match parse_digit(&input[i..]) {
            Ok(d) => digits.push(d),
            Err(_) => continue,
        }
    }

    Ok(digits)
}

From there everything is the same as part 1.

Optimisation

Now on to the fun stuff, let's make this go further.

Part 1

The first step was no to try and parse the whole string for all digits, this is wasteful. Instead I built two new functions that move inwards from either end of the string and return as soon as they've found a digit.

fn extract_first_digit(input: &str) -> Result<u8> {
    for c in input.chars() {
        if let Some(digit) = c.to_digit(10) {
            return Ok(digit as u8);
        }
    }

    Err(Error::NoFirstDigitInLine)
}

fn extract_last_digit(input: &str) -> Result<u8> {
    for c in input.chars().rev() {
        if let Some(digit) = c.to_digit(10) {
            return Ok(digit as u8);
        }
    }

    Err(Error::NoLastDigitInLine)
}

The next tiny improvement was to also not build a new string to parse, but instead, use "maths" . This now leaves the number_for_line function as:

fn number_for_line(line: &str) -> Result<u32> {
    let first = extract_first_digit(line)?;
    let last = extract_last_digit(line)?;
    Ok((first * 10 + last) as u32)
}

With everything else remaining the same I got a ~2.4 time performance increase. For the full results scroll to the bottom of this post.

Part 2

After applying the same optimisations as I did in part 1 I got stuck. There was little I could see to make it better. I did try some replacement things, but there are some well thought out gotchas that tripped me up. For example eightwothree, depending on the order of your replacements, two will get replaced first leaving eigh2three, of which 2 is now the first digit, which is wrong.

Interestingly this resulted in a ~3x performance gain vs part 1. I suspect this is because the parsing is more expensive so doing less of it is just better (who'd've guessed 🤣).

Additional Notes

I also tried multithreading, and as I suspected, on a problem this small the overhead is too high to make it worth it, single-threaded is the way to go.

I never properly explored the RegEx solution, maybe it was better, but I would be surprised as I suspect you'd have to do the starts_with or === either way. However it wouldn't likely suffer from my issue where the string might be smaller than 5 characters and needs to be padded to prevent an index out-of-bounds error.

Results

day_01        fastest       │ slowest       │ median        │ mean
├─ part1      104.9 µs      │ 126.7 µs      │ 106.2 µs      │ 108.8 µs
├─ part1_opt  43.83 µs      │ 60.29 µs      │ 44.08 µs      │ 45.45 µs
├─ part2      214.2 µs      │ 246.9 µs      │ 217.1 µs      │ 220 µs
╰─ part2_opt  71.24 µs      │ 97.7 µs       │ 71.83 µs      │ 74.24 µs

Hackathon - AccelOS

Zoe Aubert | GeekyAubergine — Sun, 19 Nov 2023 23:30:00 +0000

Yesterday, I attended a hackathon with the theme "Silly Interfaces".

TLDR: I created a game where you had to balance a blob through a maze, changing its colour to match the colour of the option you want to select from an Operating System (OS) menu. The game is played on the browser, but the balance controls are controlled by tilting your phone using a companion app (not included).

You can play the game and read the code. To make it playable without a mobile device, I have changed the balance input to a keyboard input using WASD. To change the blob's colour, go over one of the coloured circles (you can go over multiple to combine colours to make the other colours). To select an option, you must go over the coloured square of the option you want, and your blob must be that colour.

Why's it called AccelOO? Because Accelerometer OS. And yes, I realise now, after calling it that, that actually I'm using the gyroscope, not the accelerometer, but here we are 🤷‍♀️.

The Idea

After a short discussion with others about what constituted "silly", I was left with an initial choice. Did I want to go with "silly" as in annoying or "silly" as in comical? I was heading down the comical route until I overheard another conversation about using facial expressions to control an OS. They quickly dismissed the idea, but I liked it, though I didn't want to do anything with machine learning. So, I was left with the challenge of coming up with a silly way to control an OS.

A long time ago, I spent a silly number of hours playing Mercury Meltdown on the PSP. In it, you have to move blobs of mercury around a tiltable map and change the colour of the blobs to match the goal colours. I loved this game and how complex the controls were (I've often thought about remaking it). I decided this was probably a good input system. You move and change the colour of a blob around to make it the colour of the option you want to select. I was initially going to include some of the more complex mechanics of Mercury Meltdown, such as splitting and merging blobs, but that proved too complex.

To top this off, rather than just your keyboard, imagine if you had to balance the map using your phone. Not only was this annoying because it's very hard to hold it perfectly level, but because the game is on one screen and your phone is in your hand. There's a weird disconnect and mental lag compared to it all being on your phone, which adds to the fun.

The Build

I turned to familiar tools for this. Similar to my previous hackathon, I decided to use TypeScript (TS) with the canvas and Vite. Borrowing some code and styles from that project, I was quickly up and running.

The first step was to get the core game functionality going. I decided on a much less complex system for rendering than previously, which helped a lot, though it has some rough edges. I wouldn't do this in a team, but it was just fine for solo. After getting the map and blobs rendering, it was time to work on the physics. This was pretty straightforward, to the point that there are bugs; for example, the blob does a simple collision check on the top, bottom, left and right of it before moving and stops moving in that direction. You can slightly clip inside if you approach a wall at an angle. It's annoying but not problematic enough to spend too much time on it.

From there, setting up the blob colour mechanics and goal detection wasn't too much hassle. I initially made the colour system very flexible, but after some complications, I decided to make it a small enum of just the colours you see. Adding more is very manual, so I didn't go any further.

Flushed with confidence, I decided to build the map. This took a surprisingly long time. In my infinite wisdom, I built the map manually in code rather than parsing a map file. It might've been quicker in retrospect to build the parser, but by the time I came to that conclusion, it was too late.

This then leads me to what is a significant part of the project. The phone balancing system.

Mobile Shenanigans

I remember learning some time ago that the browser had access to the gyroscope, and I was right, except I very much wasn't.

The problems first started when for some reason, no mobile device could access the site. It ran fine on people's laptops, but no mobile device could resolve the host. I wrote this off to some oddity with the network at the venue or something else. I was thankfully able to connect to it from my phone if I was on a mobile hotspot though, so I used that.

Thinking that was the end of my problems, I charged on and added the code to access the gyroscope. Enter roadblock 2. Chrome does not actually support the gyroscope, and neither does Safari (or mobile). I then checked the caniuse for it and, with relief, noticed that Android browsers seemed to support it. So, I borrowed an Android device. Unsurprisingly, despite it being up to date, it didn't work either.

Now entering a mild panic, I turned to the only tool I knew might work, ReactNative. I quickly built what is probably my most janky project to date. The code for it is not Github as it is not worthy of it, and I don't want people thinking it's good. But you can enjoy it here.

import React, {useEffect} from 'react';
import {
  Button,
  SafeAreaView,
  StatusBar,
  Text,
  useColorScheme,
} from 'react-native';

import {
  gyroscope,
  setUpdateIntervalForType,
  SensorTypes,
} from 'react-native-sensors';
import {Colors} from 'react-native/Libraries/NewAppScreen';

let gyro = {x: 0, y: 0, z: 0};

function App(): JSX.Element {
  const isDarkMode = useColorScheme() === 'dark';

  useEffect(() => {
    const ws = new WebSocket('ws://172.20.10.3:3000');
    console.log('connecting');
    ws.onopen = () => {
      console.log('connected');

      setInterval(() => {
        ws.send(
          JSON.stringify({
            type: 'gyro',
            ...gyro,
          }),
        );
        // console.log('sent');
      }, 100);
    };
  }, []);

  const backgroundStyle = {
    backgroundColor: isDarkMode ? Colors.darker : Colors.lighter,
  };

  setUpdateIntervalForType(SensorTypes.gyroscope, 20); // defaults to 100ms

  gyroscope.subscribe(({x, y, z}) => {
    gyro = {
      x: x + gyro.x,
      y: y + gyro.y,
      z: z + gyro.z,
    };
  });

  return (
    <SafeAreaView style={backgroundStyle}>
      <StatusBar
        barStyle={isDarkMode ? 'light-content' : 'dark-content'}
        backgroundColor={backgroundStyle.backgroundColor}
      />
      <Text>Gyroscope:</Text>
      <Button
        onPress={() => {
          gyro = {x: 0, y: 0, z: 0};
        }}
        title="Reset"
      />
    </SafeAreaView>
  );
}

export default App;

This took a while to get working, but thank your deity of choice, it did.

One problem I almost encountered was Apple's developer licensing. If I hadn't had access to the Android device, I wouldn't have been able to test it on any device, as I was not paying for the license to build it on my phone.

Thankfully, this worked as intended, and after some playing around, I integrated it with the website. One fun thing I didn't notice in the documentation is that this library only sends delta updates, so you have to track the communicative value to get the actual tilt of the device.

The OS Part

At this point, I was running out of steam. I opted for a very quick and dirty implementation of the "OS". It's a series of states with a list of options. The game part dispatches a "player triggered goal with colour X" event, and the OS part determines if it's a valid option and transitions to the next suitable state. It's very basic, but is enough to demonstrate the silly part which is the control scheme.

Conclusion

This was a lot of fun. I don't consider myself much of a "creative ideas" person and usually rely on others in the team to come up with ideas and implement them. But as I was solo this time, so I couldn't do that, and I was very pleased with what I came up with, even if part of the idea was "borrowed".

There wouldn't be much I'd do differently other than not do something that interacts with the core components of a mobile device unless the whole project is on mobile. And if it is, it would be the first thing I'd check to see if it worked. While the project is doable with keyboard input, it lacks a lot of charm that the balancing aspect introduces. Without it, I'd've felt bad about presenting it. So, leaving it so late to test it was silly.

Overall, I consider this a successful project.

Leveraging Your Type System

Zoe Aubert | GeekyAubergine — Fri, 23 Jun 2023 18:00:00 +0000

Early last year, I decided to give Rust a go, and as many people can attest, I won't shut up about it. Fear not; this is not a post about Rust. One of the many features Rust provides is an excellent type system which results in a high level of safety. Since then, I have tried to replicate the level of safety in other languages.

Making Invalid States Unrepresentable

During my experiments with Rust, I came across NoBoilerplate's excellent Rust videos. In many of the videos, they discuss the concept of "Making Invalid States Unrepresentable". This concept is relatively widespread, and after playing around with it, I think I finally have my own interpretation of it:

If you represent all possible states, which includes all error states, you make it impossible to enter an unexpected [invalid] state

I've also taken "state" to mean the state of anything from your entire application to a single object/class/struct.

The power of this approach is that if you use it correctly. You can get the compiler/static analyser (compiler from here on) to do a lot of work for you and prevent you from making mistakes.

I'll be using TypeScript, but this should apply to almost any language. View example code.

Invoice Example

type BadInvoice = {
    uuid: string;
    amount: number;
    state: 'pending' | 'paid' | 'cancelled'
    createdAt: string;
    paidAt: string | null;
    paymentMethod: string | null;
    cancelledAt: string | null;
    cancelledReason: string | null;
}

const validState: BadInvoice = {
    uuid: '123',
    amount: 100,
    state: 'paid',
    createdAt: '2020-01-01',
    paidAt: '2020-01-03',
    paymentMethod: null,
    cancelledAt: null,
    cancelledReason: null,
}

const invalidState: BadInvoice = {
    uuid: '123',
    amount: 100,
    state: 'pending',
    createdAt: '2020-01-01',
    paidAt: '2020-01-03',
    paymentMethod: null,
    cancelledAt: null,
    cancelledReason: null,
}

In this example, we're considering an Invoice to be our state. I've included both a valid and invalid state, and the difference is subtle. How would you protect against this happening? If adding a payInvoice function, I probably would've written something like this:

function payBadInvoice(invoice: BadInvoice, payment_method: string): BadInvoice {
    if (invoice.state !== 'pending') {
        throw new Error('Invoice is not pending');
    }

    if (invoice.cancelledAt !== null || invoice.cancelledReason !== null) {
        throw new Error('Invoice is canceled');
    }

    if (invoice.paidAt !== null || invoice.paymentMethod !== null) {
        throw new Error('Invoice is already paid');
    }

    const newInvoice: BadInvoice = {
        ...invoice,
        state: 'paid',
        paymentMethod: payment_method,
    }

    return newInvoice;
}

There are several things wrong with this approach:

We've checked that we are in a pending state
We can't trust the data actually matches the expected state for a pending invoice, so we have to check that it's not mistakenly a paid or cancelled
We return a new updated invoice with no more guarantees than the invoice that we were given

Issues 2 & 3 are particularly problematic as it is prone to errors. For example, if you check paidAt but forget to check paymentMethod, you might end up in a position where you incorrectly overwrite the paymentMethod when you should've defended against it.

So how can we improve upon this? We need to represent each state an Invoice can be in and what data each state needs to be valid.

type GoodInvoicePending = {
  uuid: string;
  amount: number;
  state: "pending";
  createdAt: string;
};

type GoodInvoicePaid = {
  uuid: string;
  amount: number;
  state: "paid";
  createdAt: string;
  paidAt: string;
  paymentMethod: string;
};

type GoodInvoiceCancelled = {
  uuid: string;
  amount: number;
  state: "cancelled";
  createdAt: string;
  cancelledAt: string;
  cancelledReason: string;
};

We now have a representation/type for each valid state of an Invoice. We have made it impossible for a pending invoice to have cancelledAt set on it, or to have a paid invoice with a no paymentMethod. So how can we use this to our advantage?

function payGoodInvoiceGeneric(
  invoice: GoodInvoice,
  paymentMethod: string
): GoodInvoice {
  if (invoice.state !== "pending") {
    throw new Error("Invoice is not pending");
  }

  const newInvoice: GoodInvoice = {
    ...invoice,
    state: "paid",
    paymentMethod,
    paidAt: new Date().toISOString(),
  };

  return newInvoice;
}

Gone are all the checks for cancelledAt and the like, as the compiler guarantees that it cannot exist on an invoice in the pending state. It is impossible to make a mistake assuming you've defined your states correctly. But we can go further.

function payGoodInvoice(
  invoice: GoodInvoicePending,
  paymentMethod: string
): GoodInvoicePaid {
  const newInvoice: GoodInvoicePaid = {
    ...invoice,
    state: "paid",
    paymentMethod,
    paidAt: new Date().toISOString(),
  };

  return newInvoice;
}

And just like that, we've made it impossible to pass a non-pending invoice to this function, you've transferred responsibility to ensure that an invoice is pending to the caller, and we've removed an exception/error (more on this later).

If we compare this to our original function, we've come a long way. We have added a lot of certainty to what we know about the data being given to and returned from our function and prevented mistakes. Not only does this prevent bugs, but it removes a log of cognitive load from you. You don't have to remember to check all the possible errors with the state, as it simply cannot be.

Error handling

We can only discuss representing all states if we include discussing error states. Traditionally we handle errors/exceptions (error from here on) with a try/catch statement. There are several issues with this approach:

How do you know what functions might throw an error?
How do you remember to try/catch these error-able functions?
How do we recover from these errors?
In some languages, the error in catch (e) is untyped or typed as any

The first problem is often dealt with using some kind of comment, such as @throws. This is a reasonable first attempt, but it only helps if you notice or remember it.

The second problem is rarely dealt with unless it is a core part of the language, such as Java's throws X syntax. Several languages return tuples with (err, value) in an attempt to remind you to check if there's an error before accessing the value. Java's (and others) approach is the only way to get the compiler to force you to handle the error.

The third problem is more complicated to address and will depend on your situation. But if you don't want to throw the error up the stack, you must find a way to return a "good" and "bad" value.

The fourth problem is egregious. Being untyped and relying on you to dance e instanceof Error is beyond problematic. If this is built into your language (looking at you, JavaScript and TypeScript), there's little you can do to resolve this other than do the dance.

This is a collection of rather sorry issues. Errors occur. It's the nature of life. A file might be corrupt, an API request might fail, or any number of other things might happen. So how do we address this?

export type Ok<T> = {
  ok: true;
  value: T;
};

export type Err<E> = {
  ok: false;
  error: E;
};

export type Result<T, E> = Ok<T> | Err<E>;

Introducting Result. Don't worry if you're not familiar with generics, you don't need to understand them for this. Result is a type that represents the return value of a function. It either worked and is Ok or errored and is an Err.

Why is this powerful? Let's look at an example.

enum FileReadingError {
  FILE_NOT_FOUND,
  FILE_NOT_READABLE,
  // ...
}

function readFile(path: string): Result<string, FileReadingError> {
  // ...
  
  return {
    ok: true,
    value: "file content",
  };
}

Looking at the readFile function, we immediately know 3 things, it can error, what it will return if it works, and what the error will be if it fails. This also resolves all of the issues highlighted previously. Let's say we wanted to print the contents of the file.

function printFile(path: string) {
  const result = readFile(path);

  if (!result.ok) {
    switch (result.error) {
      case FileReadingError.FILE_NOT_FOUND:
        console.log("File not found");
        return;
      case FileReadingError.FILE_NOT_READABLE:
        console.log("File not readable");
        return;
      default:
        return;
    }
  }

  console.log(result.value);
}

This function reads the file, and checks to see if the result is Ok. If it wasn't, it knows what the error type is and can respond correctly, or if it was, it can continue and print the contents.

Why is this powerful? Because the compiler, as before, can step in and ensure you handle the Result and let you know the error type. If you forget to check result.ok, you cannot access its value, and you'll get a compiler error like this:

Property 'value' does not exist on type 'Result<string, FileReadingError>'.
  Property 'value' does not exist on type 'Err<FileReadingError>'.

You'll get a similar error if you try to access the error without checking it's errored. It is now impossible to get this wrong and forget a try/catch somewhere, and having the error type is immensely useful. Not only does it save you from the instanceof dance, you know at compile time what errors you might get and can handle all of them appropriately.

Api with Result

The only complication with this is when it comes to integrating this approach with non-result-friendly code. But we can get around that.

type ApiErrorWithStatus = {
  type: "api_error_with_status";
  status: number;
};

type UnknownApiError = {
  type: "unknown_api_error";
  message: string;
};

type ApiError = ApiErrorWithStatus | UnknownApiError;

async function api<D>(url: string): Promise<Result<D, ApiError>> {
  try {
    const response = await fetch(url);

    if (!response.ok) {
      return {
        ok: false,
        error: {
          type: "api_error_with_status",
          status: response.status,
        },
      };
    }

    const data = await response.json();

    return {
      ok: true,
      value: data,
    };
  } catch (error) {
    return {
      ok: false,
      error: {
        type: "unknown_api_error",
        message: error.message,
      },
    };
  }
}

type Trade = {
  instrument: string;
};

type Instrument = {
  name: string;
  price: number;
};

type TradeWithPrice = Trade & {
  price: number;
};

type FetchTradeInstrumentNotFoundError = {
  type: "fetch_trade_instrument_not_found_error";
  instrument: string;
};

type FetchTradeError = ApiError | FetchTradeInstrumentNotFoundError;

async function fetchTradesWithPrices(): Promise<
  Result<TradeWithPrice[], FetchTradeError>
> {
  const trades = await api<Trade[]>("/api/trades");

  if (!trades.ok) {
    return trades;
  }

  const instrumentNames = trades.value.map((trade) => trade.instrument);

  const prices = await api<Instrument[]>(
    `/api/prices?instruments=${instrumentNames.join(",")}`
  );

  if (!prices.ok) {
    return prices;
  }

  const tradesWithPrices: TradeWithPrice[] = [];

  for (const trade of trades.value) {
    const instrument = prices.value.find(
      (instrument) => instrument.name === trade.instrument
    );

    if (!instrument) {
      return Err({
        type: "fetch_trade_instrument_not_found_error",
        instrument: trade.instrument,
      });
    }

    tradesWithPrices.push({
      ...trade,
      price: instrument.price,
    });
  }

  return {
    ok: true,
    value: tradesWithPrices,
  };
}

This is a fairly complex example, but hopefully, it demonstrates what is possible. We have wrapped fetch in an api function that turns it into a promised Result. We then use it in fetchTradesAndPrices to call the API and either return trades prices or return errors early. Again with complete type safety and assurance that we've remembered to handle any and all errors. We've also combined the API errors with our own errors so that any call of fetchTradesAndPrices will have to consider missing price data and potential API errors. You could also transform all the errors into a generic API_REQUEST_FAILED if that's all you need to display to users.

Null

Most languages now have the functionality to either enable strict-null-checking or have an Option type. I recommend using the language's built-in variants as they might have some advantages with compiler optimisation. If not, you can create an Option type similar to Result that forces you to check for null.

export type Some<T> = {
  some: true;
  value: T;
};

export type None = {
  some: false;
};

export type Option<T> = Some<T> | None;

export function Some<T>(value: T): Some<T> {
  return {
    some: true,
    value,
  };
}

export const None: None = {
  some: false,
};

This is similar to Result in the way you have to check that x.some is true before you can access the inner value, preventing you from accessing a null value. This eliminates the entire category of NullPointerExcetion errors.

Integrating with a database

One question you might have hanging around from our Invoice example is how to make it work with a database, as you almost certainly don't want to store each state on a separate table. So how do we keep the data consistent when building the states?

type InvoicePending = {
  uuid: string;
  amount: number;
  state: "pending";
  createdAt: string;
};

type InvoicePaid = {
  uuid: string;
  amount: number;
  state: "paid";
  createdAt: string;
  paidAt: string;
  paymentMethod: string;
};

type InvoiceCancelled = {
  uuid: string;
  amount: number;
  state: "cancelled";
  createdAt: string;
  cancelledAt: string;
  cancelledReason: string;
};

type Invoice = InvoicePending | InvoicePaid | InvoiceCancelled;

type DBInvoice = {
  uuid: string;
  amount: number;
  state: "pending" | "paid" | "cancelled";
  createdAt: string;
  paidAt: string | null;
  paymentMethod: string | null;
  cancelledAt: string | null;
  cancelledReason: string | null;
};

enum DBInvoiceParsingError {
  UNKNOWN_STATE = "UNKNOWN_STATE",
  PENDING_INVOICE_HAS_PAID_AT = "PENDING_INVOICE_HAS_PAID_AT",
  PENDING_INVOICE_HAS_PAYMENT_METHOD = "PENDING_INVOICE_HAS_PAYMENT_METHOD",
  PENDING_INVOICE_HAS_CANCELLED_AT = "PENDING_INVOICE_HAS_CANCELLED_AT",
  PENDING_INVOICE_HAS_CANCELLED_REASON = "PENDING_INVOICE_HAS_CANCELLED_REASON",
  PAID_INVOICE_MISSING_PAID_AT = "PAID_INVOICE_MISSING_PAID_AT",
  PAID_INVOICE_MISSING_PAYMENT_METHOD = "PAID_INVOICE_MISSING_PAYMENT_METHOD",
  PAID_INVOICE_HAS_CANCELLED_AT = "PAID_INVOICE_HAS_CANCELLED_AT",
  PAID_INVOICE_HAS_CANCELLED_REASON = "PAID_INVOICE_HAS_CANCELLED_REASON",
  CANCELLED_INVOICE_MISSING_CANCELLED_AT = "CANCELLED_INVOICE_MISSING_CANCELLED_AT",
  CANCELLED_INVOICE_MISSING_CANCELLED_REASON = "CANCELLED_INVOICE_MISSING_CANCELLED_REASON",
  CANCELLED_INVOICE_HAS_PAID_AT = "CANCELLED_INVOICE_HAS_PAID_AT",
  CANCELLED_INVOICE_HAS_PAYMENT_METHOD = "CANCELLED_INVOICE_HAS_PAYMENT_METHOD",
}

function dbInvoiceToInvoice(
  dbInvoice: DBInvoice
): Result<Invoice, DBInvoiceParsingError> {
  switch (dbInvoice.state) {
    case "pending": {
      if (dbInvoice.paidAt !== null) {
        return {
          ok: false,
          error: DBInvoiceParsingError.PENDING_INVOICE_HAS_PAID_AT,
        };
      }
      if (dbInvoice.paymentMethod !== null) {
        return {
          ok: false,
          error: DBInvoiceParsingError.PENDING_INVOICE_HAS_PAYMENT_METHOD,
        };
      }
      if (dbInvoice.cancelledAt !== null) {
        return {
          ok: false,
          error: DBInvoiceParsingError.PENDING_INVOICE_HAS_CANCELLED_AT,
        };
      }
      if (dbInvoice.cancelledReason !== null) {
        return {
          ok: false,
          error: DBInvoiceParsingError.PENDING_INVOICE_HAS_CANCELLED_REASON,
        };
      }

      return {
        ok: true,
        value: {
          uuid: dbInvoice.uuid,
          amount: dbInvoice.amount,
          state: "pending",
          createdAt: dbInvoice.createdAt,
        },
      };
    }
    case "paid": {
      if (dbInvoice.paidAt === null) {
        return {
          ok: false,
          error: DBInvoiceParsingError.PAID_INVOICE_MISSING_PAID_AT,
        };
      }
      if (dbInvoice.paymentMethod === null) {
        return {
          ok: false,
          error: DBInvoiceParsingError.PAID_INVOICE_MISSING_PAYMENT_METHOD,
        };
      }
      if (dbInvoice.cancelledAt !== null) {
        return {
          ok: false,
          error: DBInvoiceParsingError.PAID_INVOICE_HAS_CANCELLED_AT,
        };
      }
      if (dbInvoice.cancelledReason !== null) {
        return {
          ok: false,
          error: DBInvoiceParsingError.PAID_INVOICE_HAS_CANCELLED_REASON,
        };
      }

      return {
        ok: true,
        value: {
          uuid: dbInvoice.uuid,
          amount: dbInvoice.amount,
          state: "paid",
          createdAt: dbInvoice.createdAt,
          paidAt: dbInvoice.paidAt,
          paymentMethod: dbInvoice.paymentMethod,
        },
      };
    }
    case "cancelled": {
      if (dbInvoice.cancelledAt === null) {
        return {
          ok: false,
          error: DBInvoiceParsingError.CANCELLED_INVOICE_MISSING_CANCELLED_AT,
        };
      }
      if (dbInvoice.cancelledReason === null) {
        return {
          ok: false,
          error:
            DBInvoiceParsingError.CANCELLED_INVOICE_MISSING_CANCELLED_REASON,
        };
      }
      if (dbInvoice.paidAt !== null) {
        return {
          ok: false,
          error: DBInvoiceParsingError.CANCELLED_INVOICE_HAS_PAID_AT,
        };
      }
      if (dbInvoice.paymentMethod !== null) {
        return {
          ok: false,
          error: DBInvoiceParsingError.CANCELLED_INVOICE_HAS_PAYMENT_METHOD,
        };
      }
      return {
        ok: true,
        value: {
          uuid: dbInvoice.uuid,
          amount: dbInvoice.amount,
          state: "cancelled",
          createdAt: dbInvoice.createdAt,
          cancelledAt: dbInvoice.cancelledAt,
          cancelledReason: dbInvoice.cancelledReason,
        },
      };
    }
    default:
      return {
        ok: false,
        error: DBInvoiceParsingError.UNKNOWN_STATE,
      };
  }
}

Ok, this looks like a lot, and you might be thinking, "ah ha, see, you have having to check for possible invalid states!". Yes, we have to check for invalid states when importing non-validated states into our validated states code, but this is the only time we'll need to do it. If we're going to do these checks, then I believe this is the best place for it, as this will likely be in or adjacent to your database/repository code, so you will be thinking about all the possible states and data you need to be aware of. There's also a less verbose way to write this. I'll leave that as an exercise to the reader.

This function provides a single point for a non-validated state to become valid with helpful error handling. You might be thinking, "but what if it's in an in-between state, it should coerce it to a valid state". I know this is tempting, but you must avoid this thinking. If the "in-between" state was valid, you would have represented it in your initial definition. It should not be possible for the data in the database to not represent one of these valid states. If it does not, you should treat the data as corrupted and go down that recovery route.

There are many better options available to you than compromising the safety of your states. One such choice could be to present the user with a "Something went wrong" view and have the system raise an urgent ticket to manually review the account and correct the error. As cumbersome and slow as this might seem, and as tempting to say, "but it can self recover from this error", remember, your code could not have inserted this invalid state into the database. Therefore it should not have come out invalid. If it is invalid, it is either corrupted or something has tampered with the data. In either case, the computer can not be expected to make the correct rectification by itself and might, in turn, make the problem worse and harder to track and fix when you inevitably have to intervene.

If you are unable to load a valid state from a data, you should treat it as though the integrity of the data has been lost and should not try to automatically recover from it

Combining Valid States

While this invoice example is fine in isolation, combining it with other valid states becomes even more powerful.

type AccountSignup = {
  uuid: string;
  state: "signup";
  email: string;
};

type AccountTrial = {
  uuid: string;
  state: "trial";
  email: string;
  password: string;
  trialStartAt: string;
  trialEndsAt: string;
};

type AccountActive = {
  uuid: string;
  state: "active";
  email: string;
  password: string;
  paymentMethod: string;
  currentInvoice: InvoicePending | InvoicePaid;
};

type AccountCancelled = {
  uuid: string;
  state: "cancelled";
  email: string;
  password: string;
  currentInvoice: InvoiceCancelled;
  cancelledAt: string;
  cancelledReason: string;
};

type Account = AccountSignup | AccountTrial | AccountActive | AccountCancelled;

With this, you have defined some core business logic, embedded it as valid states, and the compiler will now hold you to these guarantees.

To become a trial account after signup, it must:
1. Have set a password
2. Have a trial start and end date
To become active, the account must:
1. Have a payment method set
2. A pending or paid invoice
3. Not be on trial
To cancel an account, you must:
1. Delete the payment method
2. Have a cancellation date and reason

You no longer have to consider, "oh, did I remember to force an invoice cancelled when cancelling the account?" or "when I cancelled the invoice, did I remember to create a new pending one to replace it and save it?". These concerns are now the concern of the compiler, and the compiler won't forget.

The compiler is smarter than you or me. The more information you give it, the fewer bugs you'll have and the less you have to think about

Another example

Before we move on to other concepts, it might be worth doing something non-finance-related to show you how it can be useful in different contexts.

const REPORT_TYPE = {
  STRUCTUAL: "STRUCTUAL",
  GROUND: "GROUND",
  RIVER: "RIVER",
} as const;
type REPORT_TYPE = (typeof REPORT_TYPE)[keyof typeof REPORT_TYPE];

type PersonSurveyor = {
  type: "surveyor";
  uuid: string;
  name: string;
};

type PersonReviewer = {
  type: "reviewer";
  uuid: string;
  name: string;
};

type PersonManager = {
  type: "manager";
  uuid: string;
  name: string;
};

type Person = PersonSurveyor | PersonReviewer | PersonManager;

type UnassignedUnconfirmedReport = {
  type: "unassigned_unconfirmed";
  reportType: REPORT_TYPE;
  uuid: string;
};

type AssignedUnconfirmedReport = {
  type: "assigned_unconfirmed";
  reportType: REPORT_TYPE;
  uuid: string;
  assignedTo: PersonSurveyor;
  assignedAt: string;
  assignedBy: PersonManager;
};

type AssignedConfirmedReport = {
  type: "assigned_confirmed";
  reportType: REPORT_TYPE;
  uuid: string;
  assignedTo: PersonSurveyor;
  assignedAt: string;
  assignedBy: PersonManager;
  date: string;
  confirmedAt: string;
  confirmedBy: PersonManager;
};

type InProgressReport = {
  type: "in_progress";
  reportType: REPORT_TYPE;
  uuid: string;
  assignedTo: PersonSurveyor;
  assignedAt: string;
  assignedBy: PersonManager;
  date: string;
  confirmedAt: string;
  confirmedBy: PersonManager;
  startedAt: string;
};

type AwaitingReviewReport = {
  type: "awaiting_review";
  reportType: REPORT_TYPE;
  uuid: string;
  assignedTo: PersonSurveyor;
  assignedAt: string;
  assignedBy: PersonManager;
  date: string;
  confirmedAt: string;
  confirmedBy: PersonManager;
  startedAt: string;
  endedAt: string;
};

type InReviewReport = {
  type: "in_review";
  reportType: REPORT_TYPE;
  uuid: string;
  assignedTo: PersonSurveyor;
  assignedAt: string;
  assignedBy: PersonManager;
  date: string;
  confirmedAt: string;
  confirmedBy: PersonManager;
  startedAt: string;
  endedAt: string;
  reviewStartedAt: string;
  reviewer: PersonReviewer;
};

type CompletedReport = {
  type: "completed";
  reportType: REPORT_TYPE;
  uuid: string;
  assignedTo: PersonSurveyor;
  assignedAt: string;
  assignedBy: PersonManager;
  date: string;
  confirmedAt: string;
  confirmedBy: PersonManager;
  startedAt: string;
  endedAt: string;
  reviewStartedAt: string;
  reviewer: PersonReviewer;
  reviewEndedAt: string;
  completedAt: string;
};

type Report =
  | UnassignedUnconfirmedReport
  | AssignedUnconfirmedReport
  | AssignedConfirmedReport
  | InProgressReport
  | AwaitingReviewReport
  | InReviewReport
  | CompletedReport;

Though this example is a little more complex, again, we've encoded a significant amount of business logic into our valid states, ensuring that we follow our own rules.

A report starts out unassigned and unconfirmed
A report must next be assigned to someone
The report time must be confirmed before it can be started, and it must be confirmed by a manager
A report must be finished and awaiting review before it can be reviewed
A reviewer is the only person who can review a report
A reviewer must complete a review before a report can be marked complete

These are some core business rules that previously might've been either a single large progressToNextState function that did a ludicrous amount of state validation and checking before progressing or a series of smaller functions littered all over the place. This trap is just waiting for you to forget to implement some business rule either when you first implement it or much later when changing something.

If you later decide that the surveyor can confirm the date themselves, you only need to change it in the state definition, and the compiler will tell you what else you need to change to reflect this change.

One limitation is that we cannot protect against moving between the states out of order. The easiest way around this is to have an internal rule (or better yet, a linter if possible and/or protected creators) preventing you from manually transitioning from one state to another, instead requiring you to use a series for functions that go from one state to the other.

function assignReport(
  report: UnassignedUnconfirmedReport,
  assignedTo: PersonSurveyor,
  assignedAt: string,
  assignedBy: PersonManager
): AssignedUnconfirmedReport {
  return {
    ...report,
    type: "assigned_unconfirmed",
    assignedTo,
    assignedAt,
    assignedBy,
  };
}

This not only has the advantage of forcing states to progress in a specific order but also means that in this single function, we could produce any necessary events we want to dispatch and not have to remember to do it anytime we modify a report.

Exhaust

You may have noticed that I have a default case that returns an error in several of my switch statements. This is fine, but we can do better.

export function exhaust(
  _value: never,
  message = "Failed exhaustive check"
): never {
  throw new Error(message);
}

If we use this as the default case for our switch statements, the compiler will not let us forget the variant and will force us to handle it. Yes, this function technically throws an error, and I've previously discussed why this is bad. This is an exception to that rule. While, in theory, it could throw the error, our type system prevents it, and if that code were to be reached, it would hint at a very unlikely compiler bug.

type ReportA = {
  type: "A";
  a: string;
};

type ReportB = {
  type: "B";
  b: string;
};

type ReportC = {
  type: "C";
  c: string;
};

type Report = ReportA | ReportB | ReportC;

function processReport(report: Report) {
  switch (report.type) {
    case "A":
      console.log(report.a);
      break;
    case "B":
      console.log(report.b);
      break;
    default:
      exhaust(report);
  }
}

This example creates a compiler error of:

Argument of type 'ReportC' is not assignable to parameter of type 'never'

It won't be happy until we write a case for ReportC. This might seem trivial in this case but consider larger applications. Take the example from before with the reports. There are likely multiple places where you'll be doing different things depending on the state/type of the report. If you add a new state/type to your report, you might forget somewhere it's used and end up with an invalid state in that code. Instead, using exhaust will raise an error everywhere you use the state/type and prevent you from forgetting to handle this new case. This could be anything from rendering styling to saving to the database.

Conclusion

Hopefully, you can now see how you can use your type system to your advantage. Why tolerate bugs caused by forgetfulness when you can have the compiler prevent them from ever getting past your editor?

In some languages, you might have to use a static analyser as part of your continuous integration rather than just the compiler, but that should not be a reason to not use this technique.

This approach is a bit verbose compared to what you might currently be writing, but I'd argue that the upfront cost is worth the lifetime of bug prevention you will gain. I recommend you play around with this technique and try converting some of your existing code. You might be surprised how many bugs it'll catch and tell you about.

Hack Pompey 2023 - Blahbarian

Zoe Aubert | GeekyAubergine — Sat, 25 Mar 2023 22:30:00 +0000

I attended my first hackathon hosted by Hack Pompey, and it went well.

tldr: We made a Vampire Survivors style game based around Blahai the Blahbarian

You can play it here. Warning that the noises are pretty loud.

The code is available on Github.

The Team

Char - Blahbarian and weapon pixel art
Charlie - Programming
Emily - Programming
Finn - Enemy pixel art
Luke - Programming
Robb (Remote) - Sound
Me - Programming

The Plan

Calling it a plan might be a bit of a stretch. My colleagues and I decided to team up when we decided to all go to the hackathon. We didn't know what we wanted to do and were hoping to find some inspiration when we got there. In the office, we have a Blahaj, and it's been the centre of a few shenanigans. In a moment of inspiration, I came up with the idea of:

Blahaj tower defence. The shark shoots boxes at furniture to flat-pack it.

This got everyone's attention. We quickly transitioned away from Blahaj and decided to move to Blahai, the legally distinct shark. We discussed the game style, and after floating over a few, including a platformer, we decided to go with a Legend of Zelda style dungeon/room-based game.

To play into the joke some more, we decided to make the Blahai Norwegian and make him a barbarian who destroys furniture. Emily then suggested "Blahbarian", and we immediately knew this was what we must do.

The Day

A rough outline of the day was:

10:15 - 13:00 - Programming
13:00 - 13:45 - Lunch
13:45 - 16:00 - Programming
16:00 - 17:00 - Presentations

We were likely to get a little under 5 hours of programming in. This was much shorter than I anticipated and was barely enough to finish.

As is standard, we were delayed at the start with internet issues, which caused us to lose about 15 mins at the start trying to get the repo cloned.

Once we got that going, we got Vite installed for easy Typescript compiling and some other nice tooling. This then allowed me to quickly get a framework set up and rendering to the canvas for the others to work with. As I was building the framework, Charlie suggested we move to an even simpler game design of something more similar to Vampire Survivor (linked above). We all agreed this would be much simpler, and it turned out to be an excellent suggestion.

By lunchtime, we had the world, player and entities rendering, and the player could move around. The sprite sheet rendering was the first two frames of the walking animation.

After lunch, it was a bit of a sprint as we knew just how much we had left to do. We finalised how the sprite sheets worked to allow for animations and got them working directionally. Added spawning for enemies and basic "go to player" "AI". Added sounds. Added powerups. And finally, just before the presentation, we added attacking and attack animations.

The presentation went well, it didn't immediately fail, and we got through it in one piece. We came 3rd place in the community vote.

Overall it was a great experience. It wasn't stressful per se, but very draining. I look forward to doing it again and maybe participating in a game jam in the future.

Engine design

Having dabbled in game building before, I had a plan of how it would work, which saved us a bunch of time. The core of the engine is simple.

The rendering would be handled by canvas. As the game was taking place on a flat plane, it made sense to centre the camera on the player and render everything relative to that. For the floor, this required rendering a simple grid of tiles relative to the player and ensuring the grid was one tile wider than the viewport.

All entities were given a movement enum of 'IDLE', 'DOWN', 'UP', 'LEFT', and 'RIGHT' to allow us to render appropriately rotated sprites and then rendered on the canvas relative to the player. Animations were handled by looping through an array of sprite keys that referenced the sprite sheets and rendering the sprite. The animations were then tied to the movement enum to allow it to swap out the correct sprites depending on movement.

Damage dealing and collisions were handled by checking collisions on axis-aligned bounding boxes.

What I'd do differently

Overall there's not a lot I'd do differently. The only part of the code I'm unhappy with is the animation system, as it's hard to trigger an animation and have it complete without a silly hack. For example, the sword swing takes longer than the player is pressing the key down for, so the boolean controlling its rendering is on a timeout rather than waiting for the last frame. It also doesn't always start from frame 0. I'm unsure how I'd address this without building a much more complex system than the time would've allowed.

Saving my Chaos Knight

Zoe Aubert | GeekyAubergine — Sun, 29 Jan 2023 22:04:00 +0000

Packing for my recent house move was a stressful process. Not only was it time-consuming, but some models required extra attention. I've always been worried about the structural integrity of the lances on the Chaos Knights (slightly different set to mine, but you'll hopefully get my points). This concern was justified.

My friend recently asked if I was still playing Age of Sigmar, which led me to pull my Slaves to Darkness collection back out. I then discovered that one of the lances on a knight had broken off.

I initially considered trying to glue the lance back on, but the contact point was, at best, 2mm in diameter. If it did stick, it'd just snap again immediately. So I did the only logical thing and reached for my pin vice.

I planned to use a brass rod to pin the parts in place. Having only ever used this technique to pin models to bases/cork before, this was a scary prospect. Especially considering the margin for error of misaligning the drill bit and coming out the side of the model was high.

I tackled the scary part first and drilled directly into the hand and handle assembly. For reference, the drill bit I used was 0.7mm in diameter.

This went better than I expected, I half expected to destroy the whole hand and handle, but it survived. Unfortunately, it did make a bit of a mess of the hand, and when half a finger gave way, it made the entrance to the hole much larger than expected.

Drilling the lance went much more smoothly.

Next came the pinning. I use 0.7mm outer diameter brass tubing. It might not be the best, but it's what I had. I initially forgot how soft the rod was and immediately bent it while pushing it into the hole. This took several attempts to get right with many bent and snapped pieces of brass.

Once I got a rod in safely, I noticed that it wobbled significantly due to the issue noted earlier, where the entrance to the hole had given way. This was problematic and could not be saved with glue. In a moment of inspired brilliance, I decided to try pushing an offcut of a rod into the hole. This resolved this issue, though there were a few tense moments where the plastic felt like it would give way completely. Sorry about the quality. It looked fine when I took it. I missed the focus, but you can see the smaller bit at sicking out.

Once I'd got that in place and got it settled, applying some glue on the hand and pushing the lance down onto the rod was simple. It did require holding in place a bit while it dried, as the rod wasn't perfectly aligned for both halves.

All things considered, I'm pleased with how this turned out. It's a little wonky, but you'd have to be looking for it. And when surrounded by other Knights, it fits in well. It does make me worry about the safety of this and the other models. Though I will be getting more regardless because this is a fantastic model.

2022 A Year In Review

Zoe Aubert | GeekyAubergine — Sun, 08 Jan 2023 16:10:00 +0000

2022 has been a year of significant change for me. I've wanted to write this since the summer when I thought of this title. I was considering borrowing the style from Robb Knight's and Sophie's posts, but much like my journalling, I find lists restrictive (more on this later in the journaling section), so I chose to do it this way instead.

Buying my house

At the start of 2022, I was renting a little one-bed flat. I intended to buy something at some point, but it wasn't really on my mind. Much to my surprise, towards the end of January, my landlord contacted me asking if I wanted to buy the flat. After initially going for it, I ended up pulling out due to a myriad of issues; this then started the search for somewhere else. I initially began looking for somewhere to rent, assuming I would receive my notice shortly. After lamenting my annoyance at having to rent again with my boss, he suggested that I look to buy and just sofa surf between places if I need to. Despite my initial reservations, this made sense.

The search increased from there, and I started reviewing property listings hourly and phoning them immediately for viewings. Despite this, I could not view all the properties I wanted to, such was the market's craziness at the time. All in all, I viewed in the order of 30 properties and offered on 3 before finally having an offer accepted.

Thankfully, as I'd been in the process of purchasing the flat, I had most of my anti-money-laundering and other checks in place, so I was able to complete in a speedy 84 days. The process of completing was surprising. After weeks of back and forth with lots of people, to then be given the keys and be left alone was a stark difference. Going from a tiny flat to being entirely responsible for a house was, and still is, a little overwhelming at first, but it's slowly sinking in. Overall it was an exciting and stressful experience, but I'm happy with how it worked out.

Warhammer

In 2021 I started to pick up Warhammer again, slowly working my way through one of the starter sets I'd picked up many years ago (Tempest of Souls, for those curious). As I was expanding my Nighthaunt collection, I grew a bit tired of painting ghosts despite my love of the lore and gave Slaves to Darkness. A little later in the year, I ended up going to a party and found out a friend had some Space Marines and Necrons he'd got in a starter pack. This spawned a discussion that led me to look into 40k and eventually give it a try. I was torn between trying Space Marines and Tyranids, but I ended up picking the Space Marines as I didn't fancy doing another "horde" army.

Picking Space Marines only increased my analysis paralysis. I couldn't decide what Chapter to pick. I love the Imperial Fists' lore and style, but their rules and painting that much yellow dissuaded me. I eventually decided to go for a custom chapter and settled on a lovely purple scheme after trying lots of different colours.

To learn more about 40k, I started reading (listening) to some books, and it was all going well until one of the last Ciaphas Cain books and The Devastation of Baal. These books (particularly the latter) focus on the Tyranids, and to say it captured my attention would be putting it lightly. So I ended up also picking up a Tyranids starting set and am currently stuck picking a colour scheme.

On top of all this, I also decided to participate in a Painting Competition. So far hasn't gone very well, but as it's for a friend, I intend to finish this project before starting any new ones (we'll see how long that lasts).

Obsidian and Journaling

This year I stumbled upon Obsidian, and I cannot stress how useful this tool has been. The ability to write something down and file it away and not have to keep all the details in my working memory has been a vast improvement.

Now, whenever I'm researching/learning something, I will open a note about it, jot things down, and link it. I can't say how useful this is bar basic re-enforcement but even that's a major plus. I really wish I'd had something like this at university.

I've not followed this religiously, and there are many things I should've taken notes on, so my graph could be more impressive, but what I have so far makes me happy. I am aware this might fall into the "feeling productive without really being productive" category.

I also have a note called "inbox". This is where I stick any and all links to anything I find interesting for me to review later. I used to try and remember things, and writing them down and not worrying about forgetting them is easily the biggest win for me so far.

Journaling

Something else that Obsidian has given me is a journaling solution that works for me. I've tried it numerous times but never stuck with it for more than a short period. I think what clicked for me was:

It's digital and private (no questionable cloud storage)
I can link to notes
I can link to people

Once I realised I could have notes for people and link to them in my daily notes, I was hooked. This was further enhanced when I started linking them to each other, interests, places of work, and social groups.

I often struggle to remember people and things about them. Now, if I know I'm going to a social event, I can find the note for that social event and quickly review people's interests. It's prevented a few "oh, I'd forgotten that" moments and allowed for more flowing conversation.

For an example of why I think this is powerful, see this graph where I've unhidden the "people" (pink) and "journal" (yellow) notes. The purple ones are social events/groups. It shows how deeply connected both my journal, and people's notes are to everything I do.

Later in the year, I noticed I was journaling less and less again and wasn't sure why. I have a template I use for my notes, and the way I'd designed it was groups of lists such as "what went well", "what was bad", and "reflections". This led to very restricted and "stiff" journaling where I'd just list things and not actually talk about them. As a result, I never really got my thoughts or emotions down on paper and removing them from my mind. Once I realised this, I completely redesigned my template to be much less restrictive.

# {{title}}

## Season Theme:

## Your day:

## What are you grateful for?

Since changing this my journaling has improved vastly, I write more, I remember more, and I feel better for it.

I also stumbled across CGP Grey's Theme Video again and decided to add that to my template, which has been a fun experiment. I'm not sure how much it helps me, but it reminds me of what I'm trying to achieve.

Health

This has been an unpredictable year for my health. At the start of the year, I made some rules for myself, which could be grouped into a broader category of "not consuming so much crap".

This was a good start, and to keep me on track, I downloaded an app to monitor the number of days since I last broke a rule. I do well when I gamify aspects of my life, and losing the big streaks helped a lot.

I followed my rules for a while until the house purchase stress caused me to fall off the rails a bit. An added benefit I didn't expect was the money I would save, despite the ridiculously high cost of soft drinks at bars.

Not long after the clocks changed, I decided, on a whim, to try running. I've never been an active person, and I've always particularly hated running, so this was a strange whim. And, I must admit, to my great surprise, I enjoyed it. Since then, I've run on and off 3 times a week and even invested in some running shoes (go to a good shop, it's helpful). I can say, without a doubt, that running and weight loss made me feel better than I have in a long time. I wasn't setting any records, but I felt good and was improving.

In the end, before the house stress entered my life, I lost about 9kg and was very close to being the lightest I've been in my adult life. While I still have a lot to go to reach my goal weight, this a milestone I very much look forward to coming close to and breaking again this year. Unfortunately, with the house stress, I gained back almost everything I'd lost, but I know I can lose it and look forward to getting back on it.

I also caught covid at the start of the year, funnily enough, 2 weeks after my booster. Overall, not good, wouldn't recommend it. Final review: 0/10, would not cough again.

Music

After a significant break of no music due to covid, 2022 was really the first full year of music, and it was a wild ride.

One of the groups I'm in performed The Grand Duke as a show for 4 days with 5 performances. It went surprisingly well considering the time since the last performance of that magnitude. But, it did result in half the group getting covid.

During the summer, I was asked to play at a mass. Having never been to a Catholic ceremony before, it was very educational, if not hard, to play while choking on incense. Interestingly was also my first official paid gig (unless you count food and drinks as "proper" payment), which now makes me a "professional".

After the summer break, another group I'm in had no French horns. I've always fancied one, so I decided to use the gap and fill it, so I got one. This has been a humbling experience. Having to start from almost 0 again was challenging. To add to this challenge I only gave myself 6 weeks to learn it before my first performance with it, and for added fun, I had to swap between French horn and Trumpet for it. Overall I'm pleased with how far I've gone with it and look forward to seeing how comfortable I am with it in a year's time.

Programming

At the start of the year, I decided to give Rust a go, a decision that has impacted me deeply.

Rust promised something I strive for, fewer bugs and more safety. This might be a slight bending of the truth, but that is how I saw the promises Rust made. These aspects are essential to me as I regularly get frustrated with the frequency of bugs and the lack of proper tools to prevent them. In many other languages, I emulate this by using highly modularised code, written as functionally as possible, immutable data structures and lot and lots of tests with good coverage. But it feels lacking compared to the tools Rust provides.

After messing around with it and getting bullied by the borrow checker, I started working on some more "serious" and larger projects. It was also around this time that I stumbled across NoBoilerplate's fantastic Rust videos that introduced me to the power of Rust's type system and "correctness". This, combined with Result and Option types demonstrated how a compiler can do a lot of the work for you if you give it a lot of information.

As you might've guessed, I fell in love with this and talked about it a lot, much to my friends and colleagues' annoyance. Unfortunately, I can't move all my projects to Rust, so I had to make do. We have moved a few of them that I work on to Typescript, which has allowed me to implement both Result with a custom error definition and Typestate for internal APIs. Unfortunately, we can't use Option as you'd have to do something special with JSON.seralize to make it work. Applying these techniques has:

Improved my confidence in the projects
Highlighted a significant number of bugs
Allowed us to focus on correctness vs bug fixing
Reduced the time spent writing tests for errors that the compiler now enforces behaviours for

I might be falling into the trap of feeling productive again. But this type of safety and correctness makes me feel much better about the quality of the code I produce. And while I don't use it professionally, Rust has provided me with knowledge and tools I could use regardless.

Privacy Concerns

During this year, I also became much more privacy-conscious. I made efforts on all my projects to protect users where possible. For me, the big change was dropping Google Analytics and Google Fonts. I was recommended (and would recommend) Fathom Analytics as a replacement for analytics, and I found Bunny Fonts to be a suitable replacement for fonts. Both are easy to use and do what I wanted them to do.

Social Media

As outlined in my leaving Twitter post I'm not, or at least wasn't, one for social media or posting in general. I rarely posted more than a few times a year and often less. More often than not, I was retweeting funny things or getting angry with the state of the world.

Micro.blog

With people leaving for greener pastures, I took it as an opportunity to re-evaluate my position within the social media world. I was first told about Micro.blog by Robb Knight, we discussed it a few times before I gave it a go, and I'm glad I did. The community is friendlier, and the lack of likes and a retweeting equivalent lends itself to much more "intentionality" rather than chasing interaction.

As Robb put it:

Micro.blog ... has no likes, no follower counts, no retweets, and no ~~post dunking~~ quote tweets. If I post something, I don't know who saw it or who enjoyed it but it doesn't matter; I'm posting it because I want to ... but none of it is being posted to try and "go viral" or get likes.

It was weird at first, posting and not getting instant likes, but posting just for yourself is fun. One of the many things that put me off posting on other platforms was it'd be shoved in people's faces, so I felt the need to perform. Here, I post what I like and only know if someone enjoyed or even saw it if they take the time to reply.

Instagram

Similar to Twitter I hadn't posted on Instagram in a long time, primarily due to the "x has posted for the first time in y" notification people get. Not only does this highlight that you've not posted a lot, but it also leads people to mindlessly like your posts as a performance, which is worse than no interaction. Again Micro.blog + my website filled the gap for me with minimal effort.

Mastodon

I originally intended to avoid Mastodon, but after freeing myself of the Twitter curse, I decided not to engage with a similar platform. I still think this way, but after (again) Robb spoke about omg.lol I thought I'd give it a look. I mainly got it for the Linktree-like pages geekyaubergine.omg.lol, but it also comes with a Mastodon instance, so I thought I'd at least set it up.

At first, I was trying to figure out what to do with it. I'd got my replacements for the two platforms I used to post on, which left Mastodon feeling redundant. I started following people who'd moved to it previously and noticed similar behaviours that I wanted to avoid. Andrew Canion's comment about treating Mastodon as ephemeral stuck with me. That, combined with status.lol got me thinking and deciding to use it similarly. Though I'm already uncomfortable with the "engagement" statistics and notifications I've received.

So what now?

This is what I found myself asking towards the end of the year. What I settled on was:

zoeaubert.me for long posts
geekyaubergine.com for almost a ledger of my life
Mastodon for "shorts"

I like this system for now, but I still have some concerns about Mastodon, but I'll try it for now.

One thing I learnt in moving away from other platforms is that getting your data is a pain (Micro.blog makes it very easy. So I'm wary of posting anything I care about to a platform where reclaiming it would be hard.

2023

Sort of following the "themes" methodology, I'm refusing to commit to any resolutions passed very vague ideas, phrased as "I would like to". I've gone with "would like to" rather than "will" as life is hard, things change, and your definition of success might (and likely will) have to change to reflect those new circumstances. That said my goals are:

I would like to improve my health
I would like to paint and play a 1k point game with one of my 40k armies
I would like to ship at least one of my unfinished projects

Leaving the Twitter nest

Zoe Aubert | GeekyAubergine — Tue, 15 Nov 2022 19:10:00 +0000

Twitter had never really captured my interest. I used to be, and still mostly am, a private person who rarely shares what they're up to with the broader world. This led to me tweeting very little and primarily using it to doomscroll and retweet anything that caused a reaction in me.

With that said, there were some good moments, either inspired tweets I've retweeted or when I really gave it a go and tried to make it work. This will be a guided tour of everything that made me laugh or reminded me of something good when going through my Twitter archive, so enjoy.

Going forward, I doubt I'll use Twitter for anything other than complaining to companies. I've moved to geekyaubergine.com, which is powered by Micro.blog (a community/platform I'd highly recommend looking into).

My Tweets

Top Tweet

2020-02-11

Shocking Straight Brexit Banana. As soon as I saw this, I knew I had to reference the straight banana rumours surrounding Brexit.

The Rest

These first few tweets are cringe, enjoy

2012-04-16

I need to get a good photo for my avatar.

The first tweet, how boring

2012-10-13

I do love it when my program's finally start to look promising. #Python

2012-11-05

So, it would appear last night that I impulse bought PrisonArchitect. One of my best buys this year, fantastic game. Especially for an alpha

Ok, maybe not cringe, but it is still a very good game

2012-11-20

I need to get a 5 x 5 x 5 Rubik's cube.

I have one now and love it; sue me.

2012-11-26

Senior Maths Challenge today, could be a laugh.

God, was I cool, maths challanges, so funny hahhahahhaa

2013-01-21

I've missed #objective-c nice to finally get back to it.

The worst opinion I've ever had

2013-06-13

I swear my bank account cries every time there's a steam sale.

Universal truths. Still the most I've spent in a steam sale

2013-07-24

Just seen a duck sneeze. Not sure what is was expecting, but not that.

I wish I remembered what it sounded like

2013-08-02

Listening to Les Mis and programming, I call that a win.

It's a vibe

2013-08-03

The 'calm' before the storm.

I miss Disney. Looking out over Crescent Lake heading from EPCOT to the Yacht and Beach Club/Swan and Dolphin.

2013-08-03

Burger phone

If I'm not mistaken, this is just outside the bathrooms in Adventureland

2013-10-03

Glad to say that my UCAS application is done!

I remember that, screw that form

2013-11-16

The build is starting to come together (the parts at least)

2013-11-17

Java + MySQL is a buddle of fun...

Turns out I've never been able to spell

2013-12-27

I love it when you find a bug, add code to print info, and the bug is magically fixed. Gotta love #debugging

🤮

2014-02-25

Nothing quiet like revision and classical music

How did I ever pass English?

2014-11-21

A design that I've been playing around with for @UP_Racing.@richboakes

Glad to see my design skills have improved a little since then

2016-06-23

And now we wait #iVoted

It was not worth the wait

2016-09-02

Doing a hard reboot on a train because it's stuck, that's a new one on me

This was interesting

2017-02-20

Oxygen Not Included by @klei is amazing, can't wait to see the finished product.

I had some good opinions, and this was one of them. I still love this game

2017-02-24

That time Dorris took out a tree

2017-02-28

Semi-successful pancakes on the worst hob I've ever used

2017-02-25

Uber got very drunk and thought a 10-minute drive would take 5 hours

2017-03-16

I got selected for the Monzo shares scheme, so I became a proper adult and bought a whole 10 shares

2017-03-19

Saw the new Beauty and The Beast movie

2017-04-29

Did some walking, got a badge

2017-06-20

Sky developer using prod keys

2017-08-16

Got up far too early to see a very big ~boat~ship

2017-08-26

Went to Victorious festival as a non-festival person, was alright

2017-10-19

Cold and beautiful morning on the last working day of the year.

2018-04-12

Funny train name

2018-04-18

Traditional first BBQ of the year post

2019-04-22

Traditional first BBQ of the year post (yes, it was a year between good posts)

2019-05-29

IEEE 754 Go brrr

2019-10-25

2020-12-25

Covid meant I couldn't go home for Christmas, so I did my first-ever roast. Very successful, all things considered, and I only set the fire alarm off once.

That time when I tried to make a Minecraft Mod

I owe a lot to this mod (maybe not my windmill design skills). I learned many programming skills on a fun project I was motivated about. It's a shame it never went further than prototypes, though it was highly ambitious.

Re-tweets

Funny [this fact is disputed] Things/Memes

Just Jersey Things

trains - Featuring the official checkmark because verified means nothing, gg Elon

Royale Blame Game

Haha, science jokes

The internet is wrong, again - Chorus is the correct choice

Skig

Creating a Micro.blog Theme + Tailwind

Zoe Aubert | GeekyAubergine — Fri, 27 May 2022 21:19:00 +0000

After having messed around with Micro.blog for a while, I decided I wanted to have a go at building my own them. At first, the challenge seemed relatively easy as there were many other themes already out there, but I was soon to be proven wrong. Hopefully, I can steer you in the right direction to save you some time.

I further complicated things by wishing to style everything using Tailwind, this is optional, of course, but it did complicate things further.

Many thanks to Robb Knight, who's worked with me to understand some of this weirdness.

You might also find reading Colin Devroe's post about creating a Micro.blog theme useful.

1. Prepping your environment

Micro.blog is powered by Hugo, you will need to install that.

Once you've installed Hugo, create a new site and open that directory.

2. Getting the right version of Hugo

The first challenge was getting something running. There are some differences between Hugo and Micro.blog, and overcoming them proved annoying. The first thing to ensure is you have Hugo version 0.91.0 installed, anything newer, and you'll get issues with almost all templates relying on some RSS data that no longer exists.

Once you have the executable from the website, drag it into your site's main folder, this will allow you to run ./hugo for all other commands, and you'll have the correct version.

3. Getting your data

Go to your Micro.blog, go to 'design', and click on the 3 dots next to your domain name.

Once you get here, click "Export" and download your "Theme and Markdown" as a ".zip".

Once this has been downloaded, copy the content and data folder into your Hugo site.

If you have posts with photos, you will have to replace the URLs as they don't work correctly and won't have been downloaded. You can go through each post and add your domain to the front of each URL. For example, mine went from

uploads/2022/11510a1600.png

https://geekyaubergine.com/uploads/2022/11510a1600.png

If you want to cheat as I did, perform global replace on the content folder focus-within:

find: 'src="u'
replace: 'src="https://geekyaubergine.com/u'

4. Getting configured

From the data you downloaded before, you will need to take your config.json file and convert it to TOML. Once you've done this, copy it into your config.toml file.

5. Prepping your theme

I would recommend downloading the blank theme. This will give you all the required files, but you won't see anything. To fix that also download the default.

Thankfully Hugo is nice and allows you to merge themes, so import the blank theme into a 'blank' folder and the default into a 'default' folder. You can then add the following to your config.toml file (near the top as you'll want this again in a minute).

theme=['default', 'blank']

6. Validate your environment

At this point, you should be able to run and see your content with the default theme.

./hugo server

Congrats, now we can customise it.

7. Build your theme

Create a new theme using the following command.

hugo new theme <theme_name>

Inside your config.toml you can now add:

theme=['theme_name', 'blank']

You can now do what you want. I recommend copying files from either default or blank into your theme and then updating them as you see fit.

An example of what your theme might look like can be found on my repo.

8. Deploying your theme

Now you have your theme and you're happy with it, let's deploy it. Firstly you need to push your changes to a public git repo. Then go to your Micro.blog and go to Design. Here you will find the Edit Custom Themes button, click this and click Create New Theme. It should look something like this:

Insert whatever name for the theme you like. One quirk of Micro.blog is that if you push changes to your theme's repo, it will not automatically update on Micro.blog. To remedy this, I strongly recommend you put some sort of version or timestamp at the end of your theme name to allow you to create new ones after each update. Then insert the https link to your repo, the ssh link will not work. It should look something like this:

Click Add Theme, check your new theme is listed there correctly and go back to Design. In the Custom theme drop-down, you should now see your newly created theme, select it and then click Update Blog Settings , this will deploy your changes, though it may take a minute to process.

At this point, you might see an error appear on the Design page. If you do see if the error makes sense, it might be something requiring a file you've not committed (that's what happened to me), or you've got something in a {{ if hugo.IsProduction }} block that's causing an error you didn't see on your test site. Fix them and create a new theme as described above. If successful, the error might stay around for a while but eventually disappear.

Tailwind

Hugo doesn't support Tailwind out of the box, so we need to do our own thing.

I have an assets/css/styles.css file where I put all my styles.

You will need to have node installed and running. You're also going to want to install the same packages as I have. After that, copy and modify the postcss.config.js and tailwind.config.js.

You're going to have to have Tailwind watching to rebuild your css for Hugo as it can't do it, so run:

npx tailwindcss -i .https://cdn.geekyaubergine.com/css/styles.css -o .https://cdn.geekyaubergine.com/css/tw.css --watch --minify

In your templates/layouts/partials you're going to need something like this:

{{ $css := resources.Get "css/tw.css" | minify }}
<link rel="preload stylesheet" as="style" href="{{ $css.Permalink }}" />

{{ if not hugo.IsProduction }}
{{ $styles := resources.Get "css/styles.css" }}
{{ $styles = $styles | resources.ExecuteAsTemplate (printf "css/styles.dev.%v.css" now.UnixMilli) . }}
<link href="{{ $styles.RelPermalink }}" rel="stylesheet" />
{{ end }}

This tells Hugo to watch the file generated by Tailwind and ignores your non-compiled files in production mode. Congrats, that should be it.

Don't forget to have the tw.css file committed to your repo, otherwise, it won't work with Micro.blog. Yes, I also dislike having a generated file committed.

An example of what configuration might look like can be found on my repo.

Transferring a Spotify Playlist

Zoe Aubert | GeekyAubergine — Sat, 02 Nov 2019 00:00:00 +0000

Transferring playlists on Spotify can be a rather tedious process, there are many different approaches talked about online but I think I may have found the easiest way yet.

Log into your new account using the Spotify app on your PC
Log into your old account using the Spotify web client
On your new account create a new playlist for each playlist you want to transfer
On the web, click on a playlist you want to transfer and copy-paste the URL into the search bar of your app
Once the playlist has loaded click on a song, select all the other songs in the playlist and then drag and drop the songs onto the new playlist
Repeat until all your playlists are transferred

Hopefully, this will make the process much less frustrating for you the next time you need to do this.

Optimising Nested Database Operations

Zoe Aubert | GeekyAubergine — Sat, 23 Feb 2019 00:00:00 +0000

Nested loops - love them or hate them - are often a necessary evil within many programming problems; whether it’s to traverse n-dimensional matrices or iterating over the children of objects, they provide the cleanest solutions. We’ll discuss the latter example and how it is sometimes possible to unravel some of the loops to reduce the complexity of the problem many times over.

Imagine you've been given a task; given an array of many objects of class Alpha, list all children Delta, along with related data from Bravo and Charlie which also are children of Alpha. While this sounds like a relatively simple task at first glance, you then remember that Delta does not directly belong to Alpha, but instead to Charlie, which in turn belong to Bravo, and Bravo’s belong to Alpha. The problem has now become much harder requiring traversal through three layers of children to access Delta.

An important thing to consider is whether or not the Alpha objects already have these children loaded into memory, or they need to retrieve from the database, this will greatly affect the required approach. Both the database and preloaded approaches can be found below.

We’ll use javascript in these examples but the techniques discussed will be applicable to any language - I first implemented this solution in PHP. Additionally, we’ll assume that alphas is an array of Alpha that has been given as an argument to this function, and we’ll assume all operations are synchronous.

One final thing to consider before we access solutions; it may be entirely unnecessary for you to implement any of these solutions if there is not already, or soon going to be, a significant performance problem within your program as you’ll likely introduce further complexities while also reducing readability which is something we should all strive to avoid.

Premature optimization is the root of all evil

Donald Knuth

Using databases

As we will be loading data from the database, it is worth considering the expensive nature database queries in terms of execution time and reducing the load on the database.

Let’s start with a simplistic solution that, while not ideal, is readable and completes the task.

const output = [];

for (const alpha in alphas) {
  const bravos = database.findAllBravosByAlphaId(alpha.id);
  for (const bravo in bravos) {
    const charlies = database.findAllCharliesByBravoId(bravo.id);
    for (const charlie in charlies) {
      const deltas = database.findAllDeltasByCharlieId(charlie.id);
      for (const delta in deltas) {
        output.push({
          w: alpha.w,
          x: bravo.x,
          y: charlie.y,
          z: delta.z,
        });
      }
    }
  }
}

return output;

There are many issues with this solution, not only is the quadruple nested loop is rather unforgiving when it comes to complexity growth - O(n^4), but this also results in a significant number of database queries. For example, if we assume that for every Alpha there are 10 Bravos, for every Bravo 20 Charlies, and for every Charlie, there are 5 Deltas; then the number of database queries are 1000n, where n is the number of Alphas. This is clearly rather problematic, thankfully though we can slowly begin to unravel the inner loops, lets first do this by pulling out the database queries which are the most expensive part.

const output = [];

for (const alpha in alphas) {
  const bravos = database.findAllBravosByAlphaId(alpha.id);
  const bravoIds = bravos.map((b) => b.id);

  const charlies = database.findAllCharliesByBravoIds(bravoIds);
  const charlieIds = charlies.map((c) => c.id);

  const deltas = database.findAllDeltasByCharlieIds(charlieIds);

  for (const bravo in bravos) {
    for (const charlie in charlies) {
      for (const delta in deltas) {
        output.push({
          w: alpha.w,
          x: bravo.x,
          y: charlie.y,
          z: delta.z,
        });
      }
    }
  }
}

return output;

While this solution leaves a lot to be desired it is a vast improvement over the previous one. The crux of the solution lies on lines 5, 7, 8 and 10. On line 5 we retrieve produce a simple array that contains all the Bravos we will need, which we can then use on 7 to find all Charlies which belong to any of these Bravos. A similar approach is repeated on lines 8 and 10 to retrieve all Deltas. We’ve now reduced our required number of database queries to 3n; this is a significant improvement already and should improve the performance of this program many times over, but there is still the annoying presence of the quadruple nested loop, these too can be extracted.

const output = []

for (const alpha in alphas) {
  const bravos = database.findAllBravosByAlphaId(alpha.id)
  const bravoIds = bravos.map(b => b.id)
  const bravoIdMap = bravos.reduce((acc, b) => { ...acc, [b.id]: b }, {})

  const charlies = database.findAllCharliesByBravoIds(bravoIds)
  const charlieIds = charlies.map(c => c.id)
  const charlieIdMap = charlies.reduce((acc, c) => { ...acc, [c.id]: c }, {})

  const deltas = database.findAllDeltasByCharlieIds(charlieIds)

  for (const delta in deltas) {
    const charlie = charlies.find(c => c.id === delta.charlieId)
    const bravo = bravos.find(b => b.id === charlie.bravoId)
    output.push({
      w: alpha.w,
      x: bravo.x,
      y: charlie.y,
      z: delta.z,
    })
  }
}

return output

This solution looks to be a large improvement as we have now removed two of the nested loops; although upon closer inspection we can see this isn’t true as it relies upon an array .find on lines 15 and 16, which sadly re-introduces a loop. We’ve now reduced the complexity from O(n^4) to O(n^3) which is a good start, though it can be improved yet further by doing more pre-computation.

const output = []

for (const alpha in alphas) {
  const bravos = database.findAllBravosByAlphaId(alpha.id)
  const bravoIds = bravos.map(b => b.id)
  const bravoIdMap = bravos.reduce((acc, b) => { ...acc, [b.id]: b }, {})

  const charlies = database.findAllCharliesByBravoIds(bravoIds)
  const charlieIds = charlies.map(c => c.id)
  const charlieIdMap = charlies.reduce((acc, c) => { ...acc, [c.id]: c }, {})

  const deltas = database.findAllDeltasByCharlieIds(charlieIds)

  for (const delta in deltas) {
    const charlie = charlieIdMap[delta.charlieId]
    const bravo = bravoIdMap[charlie.bravoId]
    output.push({
      w: alpha.w,
      x: bravo.x,
      y: charlie.y,
      z: delta.z,
    })
  }
}

return output

The pre-computation here is on lines 6 and 10. By precomputing an object with key-value pair mappings - similar to a hashmap - and using them in the inner loop the complexity has been reduced yet again to O(n^2) as a object/hashmap get operation is traditionally an O(n) operation. There is one final step we could take to improve performance, though it is at the cost of both memory usage - though should still be lower than that of the preloaded approach - and a significant reduction in the readability of the solution.


const output = []

const alphaIds = alphas.map(a => a.id)
const alphaIdMap = alphas.reduce((acc, a) => { ...acc, [a.id]: a}, {})

const bravos = database.findAllBravosByAlphaIds(alphas)
const bravoIds = bravos.map(b => b.id)
const bravoIdMap = bravos.reduce((acc, b) => { ...acc, [b.id]: b }, {})

const charlies = database.findAllCharliesByBravoIds(bravoIds)
const charlieIds = charlies.map(c => c.id)
const charlieIdMap = charlies.reduce((acc, c) => { ...acc, [c.id]: c }, {})

const deltas = database.findAllDeltasByCharlieIds(charlieIds)

for (const delta in deltas) {
  const charlie = charlieIdMap[delta.charlieId]
  const bravo = bravoIdMap[charlie.bravoId]
  const alpha = alphaIdMap[bravo.alphaId]
  output.push({
    w: alpha.w,
    x: bravo.x,
    y: charlie.y,
    z: delta.z,
  })
}

return output

Similar to before, this solution produces another pre-computed map, though this time of Alphas which allows for the removal of the outer loop. In doing so we have reduced the complexity of this problem to O(n). This demonstrates that under the right situation it is entirely possible to remove many - if not all - nested loops from a program while also reducing the number of database queries required. It is worth noting though that when implementing these techniques, pre-existing infrastructure may result in the inability to remove all loops, such as in a case where it is not possible to retrieve all Bravos for all Alphas as the current queries rely upon being given a single Alpha, and implementing such an approach may lead to many other headaches and potential inefficiencies.

Using preloaded data

Similarly to before, a naive approach to this problem might look something like this:

const output = [];

for (const alpha in alphas) {
  for (const bravo in alpha.bravos) {
    for (const charlie in bravo.charlies) {
      for (const delta in charlie.deltas) {
        output.push({
          w: alpha.w,
          x: bravo.x,
          y: charlie.y,
          z: delta.z,
        });
      }
    }
  }
}

return output;

Following a similar technique to which we used for the database approach, we can extract the outer loops to use maps again.

const output = []

const alphaIdMap = alphas.reduce((acc, a) => { ...acc, [a.id]: a}, {})

const bravos = alphas.reduce((acc, a) => acc.concat(a), [])
const bravoIdMap = bravos.reduce((acc, b) => { ...acc, [b.id]: b }, {})

const charlies = bravos.reduce((acc, b) => acc.concat(b), [])
const charlieIdMap = charlies.reduce((acc, c) => { ...acc, [c.id]: c }, {})

const deltas = charlies.reduce((acc, c) => acc.concat(c), [])

for (const delta in deltas) {
  const charlie = charlieIdMap[delta.charlieId]
  const bravo = bravoIdMap[charlie.bravoId]
  const alpha = alphaIdMap[bravo.alphaId]
  output.push({
    w: alpha.w,
    x: bravo.x,
    y: charlie.y,
    z: delta.z,
  })
}

While this solution again achieves O(n) complexity, it is very important to note that this approach will significantly increase the memory footprint of the program, as we are effectively doubling the memory required to store all entities other than Deltas. Similarly to before if this memory increase turns out to be a limiting factor it is reasonable to re-introduce loops to meet the requirements, though if you’re doing this re-implement from the outside in as this will have a much greater impact.

An Adventure Into Diffing Algorithms

Zoe Aubert | GeekyAubergine — Tue, 01 Nov 2016 00:00:00 +0000

A while ago at work, we decided that our current diffing algorithm was not meeting our requirements. At the time we were using FineDiff, while this library is good at dealing with common situations, it was unable to handle some of our more complicated inputs. The main complications we faced were our use of ; to separate items and the addition and removal of line breaks without the meaning of the content changing.

Input A:
Alpha

Input B:
Alpha; Beta

Original output:
~~Alpha~~Alpha; Beta

Desired output:
Alpha; Beta

In this case, the element Beta has been added to the input string, when doing this our software added the ; separator between the elements. This results in the original Alpha being compared to Alpha; which results in the diffing algorithm determining that they are different words and mark them as a complete replacement.

Input A:
Alpha; Beta

Input B:
Alpha; Beta

Original output:
Alpha; ~~Beta~~ Beta

Desired output:
Alpha; Beta

In this case, the addition of the line break between Alpha and Beta causes it to identify it as a new word and complicates the output (it should be noted that some algorithms can be configured to ignore newlines).

The results from the longest common subsequence implementation provided marginal improvements, with our usage of ; as a separator character. To further improve this I arrived at a solution of each input being tokenised using whitespace as separators, I then take these tokens and process a copy of them removed the ; and \n characters, for example:

Input:
Alpha; Bravo, Charlie; Delta

Raw Tokens:
Alpha; Bravo, Charlie; Delta

Clean Tokens:
Alpha Bravo, Charlie Delta

Upon doing this to each set of inputs the algorithm could be performed against the clean tokens, and the resulting diff would produce the results we wanted. It was then just a case of keeping a reference to the raw token and replacing the cleaned token with it when reconstructing the output string. The output from the algorithm performed significantly better than we had expected.

It became quickly apparent that while the new algorithm performed well, it was prone to producing verbose outputs (this was true of the previous implementation as well).

Input A: a c d f g i k

Input B: a b d e g h i j

Output: a b c d e f g h i j k

As you can see this output is incredibly verbose and complicated and proved unusable for many users. We decided that if there were a significant amount of difference between the input and outputs, then it would be displayed as a before and after text, in the last example this would produce:

~~a c d f g i k~~ a b d e g h i j

This additional was as difficult to implement reliably as the general diffing algorithm as it relied upon determining if the percentage diff was above a given threshold per line, and then amending the output as required. Firstly the output of the diffing algorithm is rendered into HTML tags and then split by \n, each line then have line.replace(/<\w>.*?<\/\w>/sg, '') applied to it to remove all text between tags, this allowed us to determine how many characters difference there was between the lines. If the calculated percentage was over the threshold two new string would be created, the first using line.replace(/(<i>.*?<\/i>)|(<(s|\/s)>)/gs, '') to remove all italics tags and any text between strikethroughs, and the second with the inverse operation line.replace(/(<s>.*?<\/s>)|(<(i|\/i)>)/gs, ''. This new output or the original line is then appended to the final output of the algorithm.

Glory Unto Four

Zoe Aubert | GeekyAubergine — Sun, 25 Jan 2015 00:00:00 +0000

Disclaimer/Errata

This post was retrieved from the archives of an old website. I wrote this just after Christmas during my first year of University, as such it wasn't it's best. I've left it as true to the origial as possible, though I have cleared up some aggregious errors.

Unlike the original, I have also included the (terrible) source code (see bottom). No I don't know why I chose Java. Hopefully you'll find it a least a bit amusing.

I have created something both glorious and terrible, and I have called it Four.

What is Four? That's a good question. Four came about as a result of me showing a friend Brainfuck. This spawned an idea, what if we could make something more difficult, more convoluted, thus Four was born. At the time we happened to have also been discussing 4chan (I won't link you, don't worry), and the idea was put forward to create a language only using the letter 'b', to pay homage to /b on 4chan (if you don't already know what that is, ask a friend, I would advise against looking it up personally). It's probably occurred to you that using a single character would be essentially impossible, so the choice was made to use '/' instead of space as a separator, why, because it was kinder than using 'd' and tied in very nicely with the theme we were going for.

Four is a rather interesting language, made difficult not only by it's reduced command set, but also the difficulties that occur when trying to read lots of b's and accurately count them (I know, I've been there). When designing Four I settled upon 15 commands (slightly more then Brainfuck's 8), as I felt this was the best combination of utility and 'simplicity'. It also behaves in a similar way to Brainfuck in the sense that it has a 'infinite' set of values in a single dimensional array. The instructions are as follows (the row number corresponds to the number of b's:

Adds one to the current index
Subtracts one to the current index
Moves the current index right one position
Moves the current index left one position
Stores the current value at the current position in memory
Sets the current value at the current position to the value stored in memory
Adds the values stored in memory to the current value at the current position
Sets the value in memory to the current index
Adds one to the current value stored in memory
Subtracts one from the current value stored in memory
Inverts the current value in the current index
Multiples the current value in the current position by 2
Divides the current value in the current position by 2
Starts a new loop
End of loop segment

Syntax:
All commands must be separated by a '/'. That's it. So adding one and moving right one would be 'b/bbb/'.

Notes:

And values stored in a negative index are not printed
At the end of the program all values are printed out
To print the values as numbers the first command should be 'b/'. To print the values as ASCII the first command should be 'bb/'

Here's 'Hello, World!' in Four

bb/
#Set -1 13
bbbb/
b/b/b/b/b/b/b/b/b/b/b/b/b/
#Grab 13
bbbbb/
#Set 65 across array
bbbbbbbbbbbbbb/
bbb/
b/b/b/b/b/b/b/b/
bbbbbbbbbbbb/
bbbbbbbbbbbb/
bbbbbbbbbbbb/
b/
bbbbbbbbbbbbbbb/
#Set -2 32
bbbb/bbbb/bbbb/bbbb/bbbb/bbbb/bbbb/bbbb/bbbb/bbbb/bbbb/bbbb/bbbb/bbbb/
b/b/b/b/b/b/b/b/
bbbbbbbbbbbb/
bbbbbbbbbbbb/
bbbbb/
#Move 0
bbb/bbb/
#Set 0 H
b/b/b/b/b/b/b/
#Set 1 e
bbb/
bbbbbbb/
b/b/b/b/
#Set 2 l
bbb/
bbbbbbb/
b/b/b/b/b/b/b/b/b/b/b/
#Set 3 l
bbb/
bbbbbbb/
b/b/b/b/b/b/b/b/b/b/b/
#Set 4 o
bbb/
bbbbbbb/
b/b/b/b/b/b/b/b/b/b/b/b/b/b/
#Set 5 ,
bbb/
bbbbbbbbbbbbb/
bbbbbbbbbbbbb/
bbbbbbb/
bb/bb/bb/bb/
#Set 6(space)
bbb/
bbbbbbbbbbbbb/
#Set 7 W
bbb/
bbbbbbb/
bb/bb/bb/bb/bb/bb/bb/bb/bb/bb/
#Set 8 o
bbb/
bbbbbbb/
b/b/b/b/b/b/b/b/b/b/b/b/b/b/
#Set 9 r
bbb/
bbbbbbb/
b/b/b/b/b/b/b/b/b/b/b/b/b/b/b/b/b/
#Set 10 l
bbb/
bbbbbbb/
b/b/b/b/b/b/b/b/b/b/b/
#Set 11 d
bbb/
bbbbbbb/
b/b/b
#Set 12 !
bbb/
bbbbbbbbbbbbb/
b/

This outputs 'Hello, World!'.

For all those interested here's the minimised version:

bb/bbbb/b/b/b/b/b/b/b/b/b/b/b/b/b/bbbbb/bbbbbbbbbbbbbb/bbb/b/b/b/b/b/b/b/b/bbbbbbbbbbbb/bbbbbbbbbbbb/bbbbbbbbbbbb/b/bbbbbbbbbbbbbbb/bbbb/bbbb/bbbb/bbbb/bbbb/bbbb/bbbb/bbbb/bbbb/bbbb/bbbb/bbbb/bbbb/bbbb/b/b/b/b/b/b/b/b/bbbbbbbbbbbb/bbbbbbbbbbbb/bbbbb/bbb/bbb/b/b/b/b/b/b/b/bbb/bbbbbbb/b/b/b/b/bbb/bbbbbbb/b/b/b/b/b/b/b/b/b/b/b/bbb/bbbbbbb/b/b/b/b/b/b/b/b/b/b/b/bbb/bbbbbbb/b/b/b/b/b/b/b/b/b/b/b/b/b/b/bbb/bbbbbbbbbbbbb/bbbbbbbbbbbbb/bbbbbbb/bb/bb/bb/bb/bbb/bbbbbbbbbbbbb/bbb/bbbbbbb/bb/bb/bb/bb/bb/bb/bb/bb/bb/bb/bbb/bbbbbbb/b/b/b/b/b/b/b/b/b/b/b/b/b/b/bbb/bbbbbbb/b/b/b/b/b/b/b/b/b/b/b/b/b/b/b/b/b/bbb/bbbbbbb/b/b/b/b/b/b/b/b/b/b/b/bbb/bbbbbbb/b/b/b/bbb/bbbbbbbbbbbbb/b/

Currently the compiler for this project is unavailable and will be until I see a demand to make it shippable product.

Overall this has been a very interesting project, regardless of how impracticable it is, it certainly turns a few faces.

The Code

package com.four.lang;

import java.util.ArrayList;
import java.util.HashMap;

import com.geekyaubergine.geekyutil.io.FileUtils;
import com.geekyaubergine.geekyutil.math.MathUtil;

public class B_B {

    public static final int MAX_INDEX = 100;
    public static int type = 0;
    public static int position = 0;
    public static int acc = 0;
    public static String separator = "/";

    static HashMap<Integer, Integer> map = new HashMap<Integer, Integer>();

    public static int parse(String[] data, int index) {
        String command = data[index];
        if (command.equals("bbbbbbbbbbbbbb")) { //14
            int counter = acc;
            int end = index;
            for (int i = index + 1; i < data.length; i++) {
                if (data[i].equals("bbbbbbbbbbbbbbb")) { //15
                    end = i;
                }
            }
            for (int n = 0; n < counter; n++) {
                for (int j = index + 1; j < end; j++) {
                    j = parse(data, j);
                }
            }
            return end;
        }
        else if (command.equals("b")) {
            if (!map.containsKey(position)) {
                map.put(position, 1);
            } else {
                map.put(position, map.get(position) + 1);
            }
        }
        else if (command.equals("bb")) {
            if (!map.containsKey(position)) {
                map.put(position, -1);
            } else {
                map.put(position, map.get(position) - 1);
            }
        }
        else if (command.equals("bbb")) {
            position++;
        }
        else if (command.equals("bbbb")) {
            position--;
        }
        else if (command.equals("bbbbb")) { //5
            acc = map.get(position);
        }
        else if (command.equals("bbbbbb")) { //6
            map.put(position, acc);
        }
        else if (command.equals("bbbbbbb")) { //7
            if (!map.containsKey(position)) {
                map.put(position, acc);
            } else {
                map.put(position, acc + map.get(position));
            }
        }
        else if (command.equals("bbbbbbbb")) { //8
            acc = position;
        }
        else if (command.equals("bbbbbbbbb")) { //9
            acc++;
        }
        else if (command.equals("bbbbbbbbbb")) { //10
            acc--;
        }
        else if (command.equals("bbbbbbbbbbb")) { //11
            map.put(position, -map.get(position));
        }
        else if (command.equals("bbbbbbbbbbbb")) { //12
            map.put(position, map.get(position) * 2);
        }
        else if (command.equals("bbbbbbbbbbbbb")) { //13
            map.put(position, map.get(position) / 2);
        }

        return index;
    }

    public static void parseFile(ArrayList<String> lines) {
        if (lines == null) {
            return;
        }
        map = new HashMap<Integer, Integer>();
        map.put(position, 0);

        String dataRaw = "";
        for (String line : lines) {
            if (!line.startsWith("#")) {
                if (!line.endsWith(separator)) {
                    line += separator;
                }
                dataRaw += line;
            }
        }
        FileUtils.deleteFile("min.txt");
        FileUtils.addToFile("min.txt", dataRaw);
        String[] data = dataRaw.split(separator);

        /* Data type */
        String dataTypeDec = data[0];
        if (dataTypeDec.equals("b")) {
            type = 1;
        }
        else if (dataTypeDec.equals("bb")) {
            type = 2;
        }

        for (int i = 1; i < data.length; i++) {
            //System.out.println(i);
            i = parse(data, i);
            position = (int) MathUtil.clampFloat(position, -MAX_INDEX, MAX_INDEX);
        }
    }


    public static void print() {
        FileUtils.deleteFile("output.txt");
        String out1 = "";
        String out2 = "";
        for (int i = 0; i < MAX_INDEX; i++) {
            if (map.containsKey(i)) {
                int n = map.get(i);
                char c = (char) (n);
                out1 += n + " ";
                out2 += c;
            }
        }
        String out = "";
        if (type == 1) {
            out = out1;
        }
        else if (type == 2) {
            out = out2;
        }
        FileUtils.deleteFile("out.txt");
        FileUtils.addToFile("out.txt", out);
        System.out.println("Out:");
        System.out.println(out);
    }

    public static void runFile(String file) {
        parseFile(FileUtils.getFileStrings(file, false));
        print();
    }

    public static void main(String[] args) {
        //File file = new File("res/test.txt");
        runFile("script.txt");
    }

}