Week 3 - Temperature Conversions

Thanks for subscribing, and welcome to the third issue of the revamped All Tests Pass, a weekly programming debugging puzzle newsletter. I’m your puzzlemaster, Brandon Morrison, and I’m really happy that you’ve decided to play along.

Last week's puzzle: Weight Conversions

Last week we started a multi-week puzzle focusing on a convert function, which converts different units of weight. In our test cases for Week 2, we chose to convert between grams, kilograms, ounces, and pounds.

Thinking through the problem, there's a few different ways you could choose to solve this.

1. Keep a table of conversions between each possible unit of measure. This is likely the most naive approach from a code-scaling perspective, but has the benefit of being the most explicit about how conversions are handled, and in theory more performant that other options since the conversion only needs to happen once. With only 16 possible combinations (or 12 if you filter out matching pairs) it's a feasible implementation.
2. Always convert to a predetermined unit, then convert from that to the expected destination unit. This approach reduces the number of conversions you need to keep in your code at the cost of each conversion taking two calculations to make instead of one. In our case for four different weight units, we reduce our conversions from 12 to 8, four for converting to a predetermined unit, and four to convert back to all the supported units. If we added two more options, we would go from 30 to 12. This is the approach I take in the author implementation.

Implementations

• Author Implementation: https://github.com/fillerwriter/alltestspass-week2/blob/author-solution/week2-measurements.js

This week's puzzle: Temperature Conversions

This week, we're building on our last set of unit tests to add a new set of conversions to the mix: temperature. In addition to the weight conversions, we'll also start supporting conversions between Fahrenheit, Celsius, and Kelvin.

For our base puzzle, I've kept the author's solution from Week 2 as the base of Week 3, but feel free to either start with your own solution from last week, or to start from scratch. All you'll need to do is swap out the implementation of the convert function.

Programming Note

A programming note for this week: I've made some adjustments to our template for puzzles going forward. I've improved the support for GitHub Codespaces, such that setting up a running environment there should be a 1-click operation.

I've also temporarily deprecated support for 1-click support for CodeSandbox.io. Under the hood, I've found it difficult to tune the underlying infrastructure config to work with both CodeSpaces and CodeSandbox. I would like to reimplement this so that it works on both and maybe other platforms, but for now I've dropped support.

And, as always, you can run the code locally on your machine. I've updated the README to include common instructions. Any feedback on ways to make it easier to participate is welcome either via email or pull request on any of the puzzles.

What's a Kelvin?

If you're not familiar with Kelvin as a unit of measure, it's often used in scientific circles for variety of applications outside of standard "How hot/cold is this object?" types of questions. First proposed by the British physicist Lord Kelvin in 1848, Kelvin's share the same magnitude as Celsius degrees (i.e., when something gets 1 degree hotter in Celsius, it also goes up 1 Kelvin), but begins at absolute zero instead of the freezing point of water. The Wikipedia page goes into a lot more detail and is worth a read if you're interested in more.

The rules

1. Every Wednesday I'll send out a link to a short coding challenge. Sometimes your challenge will be to debug a pre-built function. Other times you'll need to flesh out a function or a method with a predefined specification. Sometimes we might just laugh at WTF JS moments. Regardless of the specifics, the puzzles should take roughly 30 minutes or less to solve.
2. If you decide to play along, take the code from that week's newsletter, and fork it. Your code can live anywhere you feel comfortable. Feel free to use CodeSandbox, GitHub, JSBins, or some other external delivery system. Make your modifications, and respond back to brandon at brandonmorrison dot com . Responses should arrive no later than the following Monday at midnight Eastern. Please don't reply back with your code as an email attachment — I will not read it, no matter how nice the code is inside. 
3. When I send out a new puzzle (on Wednesdays!), I'll post a solution to the previous week's puzzle. I'll also give shoutouts to those who responded with a correct answer. Privacy is important to me, so I'll only name you in the way that you identify yourself via your public GitHub/JSBin/CodeSandbox account, unless specifically asked to do otherwise. I won't share your email address.
4. AI/Code Generation: While you're free to use any development tools to create your response, including generative AI coding tools, please consider not using them to solve the puzzles for you. The whole point of these puzzles is to enjoy solving the problem, not to get the answer with as little effort as possible.