Why code is hard to test

Junior Developer: I can’t write a test for this code, it’s too hard to test

Senior Developer: Who wrote the code?

JD: I did

SD: You’re saying the code you wrote is hard to test. If you wrote the code, who made the code hard to test?

JD: I guess I did

SD: Right, so can you restructure the code to make it easier to test?

JD: Yes, looking at it again, I could break it down into smaller methods that would be easier to test individually

SD: Great! In future, how can we write the code so make it easier to test?

JD: Well if I think about how I’m going to test the code as I write it, then I can definitely write it in a way that would make it easier to test

SD: Great! And if you write your tests before you write your code, that would help even further with that approach, right?

JD: Yes, I guess it would.

TDD is not rocket science.

Installing Solaris 2.6 under QEMU

I’ve been looking at picking up a used Sun Sparcstation from eBay. It occurred to me that I’ve never installed an early version of Solaris before, so wondered if I could give it a try under QEMU since it’s emulates different hardware, including Sparc.

There’s an awesome step by step guide on Adafruit that takes you precisely each step to get Solairs installed un QEMU. You can follow the steps in their article here, so I won’t repeat all the steps here.

The key steps before you get to the install are creating a disk image:

qemu-img create -f qcow2 sparc.qcow2 9663676416

and then booting with the Solaris iso image as the cdrom and the disk image attached:

qemu-system-sparc -M SS-5 -m 128 -drive file=sparc.qcow2,bus=0,unit=0,media=disk -drive file=solaris_2.6_598_sparc.iso,bus=0,unit=2,media=cdrom,readonly=on

After this point it’s following through the steps in the install.

Here’s qemu booting up for the first time:

Here’s the Solaris installer starting up:

After the install had completed, here’s the rather impressive for it’s time CDE desktop:

Updating my AWS Lambda Sudoku Solver to generate new puzzles (part 1)

Having spent some time in the past building an implementation of Donald Knuth’s Algorithm X in Java to solve Sudoku Puzzles, I recently wondered what it would take to modify it to generate new puzzles.

If you missed my previous posts on this investigation, see:

It turns out having a working solver is part of the way there to implementing a puzzle generator, because you need to be able to check if a puzzle has a single solution, since valid puzzles only have 1 solution.

When I last wrapped my Solver as an AWS Lambda, I had taken the naive approach to call System.exit() in my Solver code if I detected there was more than 1 solution as a quick way to exit and not get stuck in a loop iterating over finding possible thousands of solutions for a grid that’s not a valid puzzle.

I went back and took another look at this and reworked it so I could pass an upper limit for number of puzzles, and changed the return type to return a List of solutions, and a flag indicating if there was a single solution or not. Latest commits on my repo have these changes, and I’m now ready to move on to building the puzzle generator. More updates coming soon.

Creating a new AWS Lambda using the AWS CLI

It’s pretty easy to set up and configure a new AWS Lambda with the AWS Console, but if you’re iterating on some changes and need to redeploy a few times, the AWS CLI makes it pretty easy.

To create a new Lambda, assuming you have a .zip packaged up and ready to go:

aws lambda create-function --function-name example-lambda --zip-file fileb://example-lambda.zip --handler index.handler --runtime nodejs8.10 --role arn:aws:iam::role-id-here:role/lambda-role