This is part two of my multi-part series on my checkers web app. Part one is an introduction which explains what I was trying to do. Hopefully it's coherent, I wrote it last September and since I have quarantine head these days, I haven't gone back and revisited it.

API

My plan was to build a single page app for practice with the React JavaScript library. This type of app exists only in the browser, so it needed a server to connect to to get the data. The backend server waits for requests from the app to provide the state of the board, the players, and any other state that might be required.

APIs

An Application Programming Interface (API) is just an interface between different pieces of software, for the use of other software. So you wouldn't say a web page is an API, because it's not really written for other software to interact with. But a library that you import in a programming language provides an API to use it, and a web API also provides an interface to another system. For instance JavaScript provdes a JSON library with an interface including JSON.parse(...) and JSON.stringify(...). On the other hand, the National Weather Service provides a web API for retrieving weather data. You can see an example of using the NWS API here. (Note that that github link is to an old project that is unmaintained).

Django REST Framework

The checkers API is built using a Django web server with Django REST Framework (DRF) layered on top. DRF is a framework for building RESTful APIs on top of a standard Django web app. REST (REpresentational State Transfer) is an approach to writing APIs that focuses on transferring text in a predefined way, often over HTTP using the standard methods.

Ok, so that was a lot of jargon. Bottom line, much of the time when you write a REST API, you'll be interested in transferring objects of some sort. Typically, you'll use a GET request to get an object, a POST request to store updates an object, and a PUT request to create a new object. Often, these will all be to the same endpoint (or URL). You might use an endpoint called /thunderstorm/ to see if there were a thunderstorm in your area. Making a GET request might give you a response like this (in JSON):

{
  "zip": "06268",
  "thuderstorm": true,
}

Now if your API allowed you to create thunderstorms (what kind of API are you writing?) you might be able to use a PUT request to create the storm and a POST request to change the storms location.

Ok, this example is kind of getting away from me. I'll just mention three specific things that I like about DRF and link into the checkers code.

viewsets

The python Django web framework has a concept of 'views' which are functions that handle requests to endpoints in a web app. Imagine you want people to be able to contact you to request a thunderstorm on their enemies. For a contact form, reachable at /app/contact_form.html, you might write a 'contact' view that handled both GET to render the form, and POST to handle the form submission. Somewhere in the code to handle POST you'd find something that sent your storm request to the app owner.

Viewsets are a DRF construct that provides a lot of the boilerplate views you would use to manipulate objects in a REST API. For instance, say you had a User you wanted to interact with. You might want to be able to CREATE, READ, and UPDATE a user. In DRF, your UserViewset could give you most of that out of the box, in the way a ModelView might give you similar things in vanilla Django.

Here is the UserViewset for checkers. It allows you to get a listing of all users (/users/), see the details of a user (/users/3/), and the endpoint (/users/) also allows you to create a user using a POST request or update a user using a PUT request. There is also a special endpoint at /users/me/ that provides the user info on the logged in user.

serializers

Serializers are another DRF feature analogous to Django templates. If you've ever used a templating system (jinja, handlebars, or many, many others) for generating your webpage, you can think of something like that. Serializers are designed for outputting the kind of representations that APIs use, such as JSON or XML, instead of HTML like a web template might create.

I'll link to the checkers user serializer. It's a super simple mostly generic serializer, but it provides enough to allow get and post requests. There's no validation done here, besides what is provided by the framework.

the http interface

Django Rest Framework provides a web frontend to talk to the API. If I had a live checkers instance, I'd point to that, but at the time of this writing, it doesn't exist. Here's a taste, though:

This is incredibly helpful as it allows you to browse and test the API as you would click around on a normal website. It allows you to see exactly what data your serialziers are providing, as well as access the various endpoints and submit and retrieve data.

Checkers Endpoints

So with the libraries out of the way, lets look at the various checkers end points. There aren't many, since the viewsets cover most of the useful views. users allows you to get and set user information. game provides information about the game, and provides additional endpoints for move and jump to make moves. board still exists but is vestigial, because I now get the board information through the game endpoint.

Coming Up

Hopefully this provides enough background to talk about some interesting react things next time. Next time I'll talk about React and JavaScript. My plan is to break it up and talk about a few interesting things at a time.

Until next time, fair winds!

cover: Photo by Artem Labunsky on Unsplash

I'm a day late with this post (assuming it goes out today!) because I went sailing on Thursday instead of writing a blog.

I think I can live with myself.

Repairs

I mentioned that I chewed up the daggerboard last time. In the interim I sanded it down and coated the bare wood with a new epoxy covering. I think I'm going to wait on varnish in case it happens again. For the most part the daggerboard spends it's time underwater and in the shade of the boat, so I'm not super worried about sun damage to the epoxy due to lack of varnish.

I did notice that the shape of the daggerboard hole might contribute to future damage. This winter I might see about making some modifications to soften the angle of the trailing edge of the hole.

New spot

For this trip, I went to the Falls Lake Beaver Dam boat launch. It's nice because there are no gas powered engines allowed in that area. South of the ramp there's a fence under an overpass which separates the lake. I didn't go too far in the other direction but presumably that whole side of the lake is open only to non-gas powered boats.

The wind was about 4-7 knots according to Windy, the wind app I downloaded. Except for launching and docking, didn't touch an oar all afternoon. There were some moments of calm, but for the most part I had a great time cruising about.

Am I... getting better?!

What I've learned about lake sailing is that the wind tends to change direction an awful lot. The shape of the shore is a big factor. When I move around a bend and a new expanse of lake opens up, I can expect wind blowing off that open area. Close in along the tree lined banks I find the wind running parallel to the shore, where as slightly farther out, the wind seems to blow in a more consistent direction. And for the best fun, in between all of these regions, the wind swirls and changes, gusts and dies off completely. This means more attention to the helm and the sail trim to get good performance and a great time!

I've also noticed that as I've sailed Bella Claire more I've started to get a feel for the tiller. I can tell without looking when I've got her rudder centered by the pressure on the tiller. I'm still not entirely comfortable with the push/pull tiller, but I'm definitely getting better at handling it. My sail trim is improving with my confidence, and understanding the wind patterns on the lake a bit better has improved that, as well. I'm much less surprised now when I go from a beam reach (that is, the wind coming from the side, perpendicular to the boat) to suddenly in irons (the boat heading directly into the wind, a point by which no sailboat can progress). Initially I was confused, thinking I had just misread the wind to start, but now I've begun to notice the conditions under which the wind changes so abruptly and adjust to the changes more readily.

I'm also happy to report that I had no issues with seasickness or heat. It was certainly lot (NC in July, after all) and humid, but I started and remained well hydrated. It helps to have a partner who is a hydration expert. All in all I had a great day and I'm looking forward to my next adventure!

Until next time, fair winds!

Introducing Bella Claire. She's amazing.

I took her out on Monday, after not getting to go all weekend. I went by myself since I didn't have an easy way to get a babysitter thanks to COVID-19.

I got a couple of complements on shore before I put her in the water. I texted Jill that I was going to throw up before I got in, not from motion sickness (yay drugs) but from nerves...

Fortunately the ramp wasn't busy.

It was a bit of a pain to ship the rudder and step the mast while under way, but not too bad considering I did it having no idea what I was doing. I did have to step the mast twice because I didnt run the halyard (sail hoisting rope) through the mast head before i stepped the mast the first time.

Need to tighten that sail to lose the giant wrinkle. Also, there was almost no wind. Great for learning! Less so for sailing...

Such a good time!

Made it back to the dock. Does anyone remember where we parked?

Except for not getting to take Jill, I couldn't have asked for a better end to construction, nor a better start to my new hobby.

... and that's it. I'm sure the future holds plenty more sailing and probably some sailing pics to go with it.

Many thanks to everyone who helped to make this project possible! Jill, of course, for love, support, and permission. Dane for lying to me and telling me I wasn't crazy to start this in the first place, and for toil and trouble. Jason and Lucien for getting Bella Claire out of the dining room. Chris, for cutting a hole in the hull. Iron Jim, for hard labor. And the kids, who helped and didn't complain too much when daddy went to work on his boat! And everyone else who made this possible! You're so amazing! When we can get together again, come get boat rides!

Going to try to get back into some technical posts as well. As for other physical maker projects, I have some in the works. Next up may be the table top version of Bella Claire.

Anyway look for more updates every Thursday! That's my new posting schedule, help me stick with it.

Until next time, fair winds and following seas!

This is part one in my series about writing a checkers webapp

Why Checkers?

Actually, it's about reactJS.

I started this project because I wanted to brush up on my react and redux, and learn redux-saga. Checkers was kind of incidental. However, when I make decisions in a hurry, it has a way of coming back to bite me. So I spent a lot longer on the actual checkers part than I expected.

The code is available on github, but it's still changing so check back. Its here.

so... Checkers.

Yeah, so checkers is an interesting game. I chose it because I felt like I didn't need to explain the rules, but I'll try and give a very abbreviated version here.

• players move stones (checkers) on a chess board using only the dark squares
• checkers move one hop diagonally (always on the dark squares) towards the opponents side of the board
• checkers capture an opposing stone by jumping over it to the dark square on the other side, if it's clear
• checkers must jump if possible
• a checker that is jumping must continue jumping until there are no more jumps available
• when a checker reaches the final row on the board, it is promoted to a king
• a king moves just like a regular checker but can move backward in addition to forward
• The game ends when one side has no checkers left

The game itself is reasonably straightforward. I wanted to make something simple that would let me play with various libraries. Because I wasn't thinking too hard about the actual design of the system, I ran into some interesting issues. If you're thinking about trying this at home, I a) heartily recommend it, and b) suggest trying Reversi instead. Without giving it almost any thought at all, I think the rules are simpler with less exceptions.

The Checkers Part

If you're following along at home, you can check out the code here

There's basically three interesting endpoints here. move lets you move a piece, jump lets you start a series of jumps, and game gets you information about the game. There's other stuff, but I want to look at these three.

game is interesting because of the way I stored the board layout. Rather than write a JSON blob into the db, I figured I'd just stick everthing in a string and put it in a 32 char field. The starting layout looks like this:

bbbbbbbbbbbb        wwwwwwwwwwww

There's only 32 because I've cut out the other 32 squares that a checker can't land on. This works.

The good part about this is that when you write to the DB it's straightforward and when you send across the network it's relatively small. What I should have done is written a conversion and handled everything using x,y coordinates. Instead, I just used the string representation and built an adjacency matrix to manage movement. It's pretty messy. I think I might have been sick at the time, high on cold medicine. Let me tell you, editing a string like that by hand is a pain in the tuchas. Also, you can't just set the values in the django admin because it trims trailing spaces (and empty squares are spaces in that string). Ask me how long it took me to figure out why my board kept getting corrupted.

I may rewrite it to use cartesian coordinates so that moves can be (+1, +1) or (-1, +1) which is super simple. That'll make all the logic so much easier. If I do that I'll post about it so you can see the change.

Now let's talk about move and jump. One of my goals was not to reimplement all of the move logic on the react side (see my mess above) and just let the backend handle all the move logic. So maybe you're wondering why we need separate move and jump endpoints? Why not just move and if you're trying to jump, it handles it appropriately? That's an excellent question and fixing that may involve a small rewrite. Right now, the frontend just checks if your move is more than 1 (diagonal) square away and picks an endpoint based on that.

Whew. Moving on.

Interesting Problems

So I mentioned that I was trying to keep the actual checkers on the backend, rather than having rule implementations in the client javascript as well as the server python code. This is fine for moving a checker. You send a start and an end position and you get back either 200 ok or 400 bad request. All the checkers logic is neatly contained in the backend.

Now consider what happens when you jump. You send a start and an end, and the backend can validate that jump. So far so good. Unfortunately for me, a checker can have a whole chain of jumps in one turn. Now we either have to calculate a whole series of jumps on the frontend and send them to the backend, or we have to send one jump at a time and hope the backend can preserve our move sequence and know when our turn is complete.

My implementation loosely follows this pattern. You selects a jump and sends it to the jump endpoint. The jump endpoint checks if the jump is ok, then checks to see if more jumps are possible from that piece. Remember from the rules that you have to make jumps if they are available. The response to a move includes the turn number, from which both sides (frontend/backend) calculate whose turn it is (black moves first on turn 0 so even numbers are black's turn). A player who submits a jump can continue submitting jumps until the turn ends.

Here's another interesting question to consider. When a checker is making a series of jumps and it lands on the back row, it becomes a king. Now, technically its turn is over, but if you're not careful becoming a king can suddenly open up new jumps to continue the process.

System Design

Really I can talk about whatever I want here because this is my space, but since this post is meant to lead into a series I'll say a little about the design of the app as a whole. The server is built on django-rest-framework, which powers the API. In addition the server provides a single page javascript frontend which communicates with the API and provides the user interface.

The javascript frontend is built using react/redux and all the communication is done with redux-saga and axios. Thanks to a bug, you can just move all the pieces because the backend doesn't check to see if you're moving your own pieces (I'm leaving this alone for now).

To support multiple players, I need to fix the above bug and build a mechanisim to notify you when it's your turn. Currently the system has a big button labeled 'refresh' which requests the state of the board. My plan is to replace that with a websockets/django channels based notification system that can run all the time.

I have some thoughts for a post on redux-saga and another on django channels/websockets. Once the system is somewhat more robust and has an actual login, I'll post a link to create an account and play here.

This morning Z made apple muffins (with a little help).

We start our makers young.

Somehow the pan of 12 only made ten muffins...

Ah, there they are.

It was a productive day in the boatworks this Sunday, although there are not a lot of pictures.

I worked on the thwarts (seats) and mast thwart. I'm just getting the final coats of epoxy on them. I'm waiting on the rear seat until I can flip the boat back over and test the fit again.

I got the tape off and did some more cleanup sanding and touched up the epoxy on the hull a bit.

And I had some helpers this week! They helped me glue together the foam insulation for extra flotation. It's amazing how much more stressful (but rewarding) it is having them in there.

A plywood boat sealed in epoxy is a good thing. A child sealed in epoxy, while probably quieter, is not a good thing.

The floatation is foam blocks that will be shaped and glued under the seats. The wooden boat should already float pretty well, but hopefully this will make the boat unsinkable, a trait I will likely need...

Next time, hopefully, I will flip the boat right side up!

So... this happened:

Don't worry, it was intentional.

This is the hole for the daggerboard. Once I flip the boat over I'll post a pic with the boat on the sawhorses and the daggerboard down, and everybody will understand what the hell is going on...

We cut it with a router and flush trim bit. It worked fantastic. I did gouge the inside of the daggerboard trunk with the drill bit slightly. Here's the initial hole.

Then we cut it out with the router. Here's Chris cutting up my boat.

If it sinks I'm using this picture as blackmail.

We started with chopping the hole, then did some sanding while the morning warmed up. Don't want condensation in the paint. After the routing and sanding the boat needed a good cleaning. The router makes a ton of sawdust. Then one more round of wet sanding, some more blue tape, and we rolled on coat number four of paint! It sure is easier with a second set of hands. Thanks Chris!

That may be the final coat of polyurethane. I'll have to look close and see how it came out. Then lots more sanding and varnish on the wood!