Long Refactoring: Extract Method

This refactoring is my bread and butter. Functions tend to grow. Eventually, you need to split them. Find a section of the method that has its own self-containerd reason- for existence, and make that its own function.

I have in the back of my head that I want to extract a class that abstracts the boards from this code. I’ve been resisting the urge thus far, as keeping the board as a 2D array of cells is really conducive to sharing with other implementations of this code. However, the following refactoring should work to support either direction: pull out the code that constructs a board from the string. This has the added benefit of making it possible to write a unit test that calls tree_to_solution_string without having to parse all of the strings.

Continue reading

Long Refactoring: Extract Helpers

As the refactoring process continues, we will continue to decompose the large central class and functions. Right now, the SudokuSolver class is performing two functions. It is holding and managing the list of the puzzles, and it is solving them.

The heart of this code is the function tree_to_solution_string. Right now, I can’t call that by itself, as the SudokuSolver creates a bunch of helper objects before running through the whole set of tests. how can we tease this apart?

Continue reading

Long Refactoring: First New Unit Test

The heart of the code is the call to solve a single puzzle; the function tree_to_solution_string. We want to write a test that runs just this function. Getting there is not so easy.

This method is buried deep within the class SudokuSolver. But creating one of these essentially runs the entire code. In fact, we can redo our original test to run the code as a python call as opposed to a subprocess call. Lets’ start with that.

Continue reading

Long Refactoring: Call a Unit Test

Our test takes 5 seconds to run. That is not horrible, but it does not bode well for when we write more tests. We don’t want to explode that number, and we want to be able to write more focused test. I’m going to do some project setup that will enable us to do more development, including fine grained unit tests.

I’m going to start by using tox.

Continue reading

Talking to FreeIPA with python-requests

The code that Rich M gave me a while back has bit rotted. At some point, I need to get an updated version, but until then, I can continue to talk to the FreeIPA server using Python and the Requests library. In the future, I can get a session cookie, but for now, python3-request-gssapi will work to authenticate me, provided I have a valid TGT.

I pulled the requests-gssapi library from Koji, as it does not currently ship in any of the RHEL8 repos. Here is the one I installed.

https://koji.fedoraproject.org/koji/buildinfo?buildID=1371255

Note that this quick-and-dirty code runs on the IPA server itself. A better approach would be to read the Server name out of /etc/ipa/default.conf.

#!/bin/python3
import requests
from requests_gssapi import HTTPSPNEGOAuth
import socket
hostname = socket.gethostname()
url = "https://%s/ipa/json" % hostname
referer =  "https://%s/ipa" % hostname
body = {"method":"user_find","params":[[""],{}],"id":0}
 
r = requests.post(url,
                  json = body,
                  auth=HTTPSPNEGOAuth(),
                  headers = {
                    'Content-Type': 'application/json',
                    'Accept': 'applicaton/json',
                    'referer': referer})
print(r.status_code)
if r.status_code  == 200:
    print(r.text)