We think sand clocks have only been in use since the middle ages, and the reason they were invented is pretty interesting. (At least in Europe; I’ve looked into this before and couldn’t find any other sources, but I may just not have looked hard enough).

For reasonably accurate time keeping, people had been using water clocks since at least the 16th century BCE. Basically the same idea as a sand clock, but water, which was slightly easier to feed into a reservoir. We don’t think sand clocks really saw any use until the 13th or 14th century CE. Mostly, people needed to keep more accurate time on ships as oceanic voyages became more common, but the movement of the vessel messed up a water clock too badly to be useful, and pendulums had the same problem. So, enter a sand clock! Basically the same idea as a water clock, but way less prone to errors from the ship’s movement.

(edit: some spelling)

Fun fact: we’re pretty sure this is why hourglasses (or sand clocks in general) were invented! They flow at a pretty consistent rate even on board a ship, and were basically just a tweak on the design of a water clock.

That honestly sounds like the way to go, and I’ll probably look into it when I have more time. I’m more a software person than a sysadmin and I’m not wildly confident that I won’t accidentally close us down for a few days without a lot of prep. 😆

Inventory is through our POS/processor and production records are through Beer30 (though I have plans to write my own and open source it when I have time; we just opened and we’re all still running pretty hard doing new-open stuff). We’re also technically a nano-brewery, so anything we’re doing is a little bespoke (i.e., I think it’s a very situational setup) right now.

The biggest thing from a brewery-specific side that we’re doing is controlling the brewhouse. We’re running an all-electric system, and all the heating and cellar controls expose UIs over the LAN. In addition to being generally nifty, we’re using Unifi to separate brewery-specific stuff onto its own network and the built-in VPN hosting (I opted for the OpenVPN option) to expose that network security. This allows our brewer to do stuff like check the temperature from home or set the boil kettle to start running before he leaves the house. (The useful thing about the UDM (primary server) running Alpine is that I have a task that essentially functions as dynamic DNS and updates an A record with our domain provider so he can always log in at a known hostname).

It also integrates with cameras, phone, and menu boards, which are all useful for the FoH side of things.

All-in-all, we’re not doing that much with it yet, but it’s pretty nice to use so far, and being a software engineer, I’m excited for the possibilities of useful stuff I can host on it.

I’ve been using Ubiquiti/Unifi for my brewery setup (cameras, several private networks, phone tree stuff). It comes with some pretty solid management software accessible through the local network, but under the hood, everything’s just running Alpine. There’s a bit of a learning curve if you keep the management software installed (firmware updates wipe out the crontab, for example), but you can customize it pretty aggressively if you know your way around a terminal.

Looks like early last year. News to me, too

https://itsfoss.com/microsoft-npm-acquisition/

Pretty much every job. I think the paradigms in most modern languages are similar enough that the actual language doesn’t matter as much as how you think about structuring code.

Surprisingly, yes to both of these. I was just commenting on how long my Dyson vacuum has lasted a couple days ago.