Neal Wilson ✅ @neal@social.typica.us

#introduction

I'm part owner and roaster at a little coffee company in Wisconsin. Author of Typica, a popular free program used to capture and work with coffee roasting production records that's used at roasting companies all over the world. Volunteer on the Roasters Guild education committee. Available for paid coffee consulting, training, open source software development. Living with a cat who broke into my house and decided to stay. Likes: cute, travel, food. Dislikes: blinking lights.

The light roast version is very much in line with how a lot of other roasters these days would approach this coffee and I think this coffee takes that sort of approach very well. The medium and dark roasts are more in line with what I was doing with the coffee this is temporarily replacing.

Removed the previous Guatemalan coffee from the web site, made roasting decisions on the next one which is a peaberry version from the same place, but I'm going to do production test roasts tomorrow and make final decisions the day after pretty early in the morning since I'll be baking again that day. If it works in a drip brew I'm thinking that we'll do a light, medium, and dark roast.

I was on baking duty today. I'm 4th in line for that job so it's not something that I need to do very often so it was a surprise when I went to what I thought was the recipe binder and discovered that it now only contained recipes for scones. I was eventually able to locate the recipes I wanted so I didn't have to make all scones.

I wasn't planning on working an open to close shift today but when orders come in I'm inclined to take the money.

Getting bigger bread instead of trying to use my sandwich materials on the previous bread was definitely the right decision.

Today was supposed to be a stay home and write software data, but one of my customers is having a coffee emergency so I'm roasting more coffee instead. Shouldn't take too long to slam out the order.

Sorting out one of those the old unsupported version of the library did it one way and the current version of the library doesn't have that anymore issues. First thing I found to try is almost but not quite viable (I can probably bludgeon it into working but for now I'll keep looking for a better option, there are at least a few things that I can try).

Just got back from a little awards ceremony for people with old buildings. It was interesting. My house was the 2nd oldest (1898) building honored tonight.

Also tested a small code change made last night intended to improve print quality which had significantly regressed compared to the last release version. Documentation suggested that the change I made was a Windows only thing but it fixed things on Linux too. Still need to test that on Mac.

Colombian coffee from the latest delivery is pretty much the same as the previous Colombian coffee to the point that I'm going to keep the same roasting plan and probably don't need to adjust any blend recipes. Of course, I'll verify that with drip brews on the first production batches before selling it. There's a new Guatemalan coffee as well, but I've still got some of the previous shipment to roast through before I move on to that one. Probably 1-2 weeks depending on what customers buy.

It makes me a little sad that part of why users might be impressed with the speed is because of how much the bar has been lowered with modern software.

New coffee arrived today so while I'm scheduled to work from home tomorrow I'll probably stop in at some point to continue product development work on that. Also spent some time continuing to port Typica's reports to the new code base. While I knew that the new code was more efficient, I was honestly surprised by just how fast the one I was working on today really is. I think users will be impressed if they edit report parameters.

Alternately, I could unconditionally use the more expensive but always correct code path and save myself a few bytes of memory at the expense of not enough cycles to matter.

Spent some time bug hunting. Identified which variable was causing an observed problem in one very specific situation, failed to find where that was getting set to the obviously wrong value (based on the code there should only be 2 possibilities here and it doesn't seem to be either of them), so I put in a thing to check for the wrongness and when that exists it tries to get at the correct value in a slightly more expensive way. I hate that "solution" and left myself a note to try harder later.

Downgraded some software because I hate the UI changes in the new version. Nice thing about locally installed open source software: I can always revert to an older thing I like if the devs go crazy. (But seriously, thanks for your earlier work in making the good thing I like.)

I can probably still get this going faster (what I'm seeing is consistent with the bottleneck being 1GbE, but I'm pretty sure the ports on the NAS are 2.5), but that would involve replacing hardware and honestly, I don't need it so I'll just keep that in mind for maybe later if I expect that to change.

Yeah, transfer speeds in/out of the NAS are a lot more stable now that it's on the wired part of the network even when the other things it's communicating with are on the wireless side. Moving this was a good decision.

Tonight I'm going to move the home NAS so it can be on a wired connection instead of a hanging off a janky Ethernet to WiFi thing.

More coffee is on the way.

Most of today's roasting schedule is full capacity batches (2 full batches for one of them). That makes it a little harder to get started as I prefer to ramp up with smaller batches, but a longer and hotter preheat also works.