to learn ruby through https://rubykoans.com is fun!

having solved a problem in one language (Go) makes it easy to solve it in another (Ruby)

Ruby divisions are floor by default

Ruby has .map and .reduce operations 💖

file and string handling in Ruby is fun e.g. File.read("./input.txt").split("\n").map(&:to_i)

the problem was not the coding but not having read the specification thoroughly.

having the wrong test cases does not help you finding the problem

the python int operator

brought recursion back to memory

how to contribute to an adoc file ;-)

again having the wrong test cases does not help you finding the problem

being to lasy to find the number of elements of an array by code may couse some trouble if you just declare a value you think might fit

how to break out of nested loops

today was a tough for me. After four stars on the first days I thought it would stay that easy and I can improve and learn something about git, github and so on, for example as I learned yesterday how to bring my fork up to date, but the puzzle today told me some other story

today I learned, that with my Ardunio/M5Stack I will not be able to solve the puzzle, even if the puzzle itself was well understood.

today I also learned, that not giving up and trying something new kann help you, even if it was hard to start learning VBA. I guess I am completely old-fashioned :-)

today I also learned how good it feels, to be part of that party. Thank you all!

today I better understood the puzzle and the necessary algorithm for the calculation of the solution compared to yesterday, so I could concentrate on deepening my knowledge in VBA. For me it seems to be pretty good for using it for this kind of puzzles making fast progress or trying something out.

but until now I have not found a good way in structuring the VBA code, so if looking at Santa’s mission from a ISO26262 view, I would not have a good trust on my own coding in VBA :-)

creating software with extendable architecture for AoC pays off 😉

day05 instructions seemed so simple, that I started coding the elements for one OP code and started to copy and modify this in all other OP codes without proper testing. Most of the bugs while running the program where simple errors inherited by this coping.

Lesson learned: Never multiply a modul you have not tested in all use cases. At the end bugfixing took more time than having done it right from the start. (I went trough every single instruction by hand :-()

I am still working with Excel VBA. Today I learned some more stuff how to enable in VBA to start test runs and the final run within one file by defining different sub’s

I also started not to try to write the code in one piece (as on day05), but in small steps with always "automated" testcases, which helped me in the end by having a working SW. After each step I was able to run a test showing that the snipe of code works as intended

Excel VBA is also capable to do recursive functions, but unfortunately the programm starts to get very slow when having a lot of recursions (day06’s part 1 was running more than 3hours. Pro: Effort spent in testing at start provided a FPY).

Kotlin has wonderful operator for collections.

Today minBy saved me a lot of effort.

today VBA did a very good job, better than me. For testing purpose I started to read only the first ten frames into the program, unfortunately with those 10 frames also the test case of part1 was fullfilled, so I forgot to read the complete frames, which made me suffering in part2, with only 10% of the input was not readable. *Lessons Learned 1: Write down which restrictions you make in the start of programming, to check and change it to the right syntax values afterwards. (I hade the same before with the IntComputers, for testing I calculated not all variations, which also led to wrong outputs) *Lessons Learned 2: With word the number of elements can very easily counted. I copied the puzzle input to a word documnent, at "Überprüfen" you can find a icon for counting words and signs.