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.

Service is back up. The server claims that it was running fine the whole time so this was probably a network issue at the data center and not anything that I messed up (unless you want to count not having some kind of fail over to a different data center set up, but I don't have the budget or an honest business case to justify the budget for that).

It reminds me of when my family got our first dial up Internet account and the ISP wanted to just email us the settings we would need to set up the computer to be able to do things like dial in and receive the email. (We were able to get them to realize that this obviously wouldn't work and got them to print the info out on paper.)

I am somewhat concerned that an email to support from an alternative server that's unaffected has not received an automated response.

The server with the shop's web site/email is down. Can't log in with ssh. There's another server under the same domain and the same service account that's still up and running just fine, but attempting to log into the service provider does the "we've emailed you a code that you need to enter before you can log in" thing, which obviously doesn't work if the whole reason I'm trying to log in in the first place is to figure out what's wrong with the mail server.

There was a big cat under my porch when I got home from work today. I only know this because it got spooked when I started climbing the steps and ran off to a neighbor's yard.

Today's shop web site update has a brief note calling attention to the fact that the latest addition is the first coffee where we've had a tariff line on the invoice. Coffee prices are also still higher than they were last year which explains why I need to charge what I'm charging for that coffee. The coffee growers and companies in the supply chain at origin aren't going to eat the tariff. They can sell it just as well to Europe or China. Import is so low margin they can't afford to eat it

I will reward myself with cake.

Spent some time working out new database queries to reduce the total number of separate queries needed (fetch all possible values needed after the first selection with the same query that populates the options instead of separate requests for only the data needed after the first selection is made). Most of the time it doesn't matter but this change can make the interface a lot more responsive if the database is accessed over a slow network connection.

Production test batches of new coffee were good. Unfortunately I'm going to have to put a retail price of $25 per pound on this one. If it weren't for tariffs I'd be able to charge $23. And if coffee prices were in line with where they were last year it would be more like $17. I'd like to be able to charge less, but can't afford to.

In better news, my sister gave me cake. It was good.

Hopefully this time I won't have to search SEC records for a CEO's home address and send a nasty letter to get them to fix their mistake (yes, I've had to do this and it worked)

I see medical billing in the USA is still as corrupt as the last time I interacted with that. (sending a bill for an amount that whoever chose that price has earned a place in hell for instead of the still egregious but smaller amount that my insurance company says I actually owe)

The receipt says almost everything was on sale, but today's grocery run was too expensive.

My production database has been growing at a very stable rate of about 1GB per year (over the past 20 years). I have some thoughts about ways to shrink that, but will want to do some testing before rolling any such changes out. Realistically the database is already doing some compression so it's unclear if there are gains that are worth it.

Given that I'm just noticing that it's after 2:30AM and I'm hungry, I should be sure to test tonight's code extra carefully (after I get some food and sleep) as I'm not at all confident that it does what I think it does.

It sounds wet outside.

Have you tested your backups lately?

Someone bought the Fyre Festival brand for about $245K. Pretty sure they overpaid by about half a million.

Today's coding was just finding and fixing bugs as well as identifying some features that don't exist but need to.

This morning's coding session was heavy on bit level operations. The hardware documentation is suggestive (without going so far as actually having coding advice) of just using a lookup table for the command strings, but creating these directly by ORing together the right binary literals saves about 60 bytes in executable size and reads a little more clearly to me. (Clearly the engineer who designed the comms protocol thought about this approach and it just wasn''t put in the documentation)