This was going to be another post in the ‘ancient mead’ series where we create modern interpretations of historical mead recipes. However, I found this excerpt to be interesting enough that I didn’t want to wait until I had come up with the interpreted recipe. I may pull out the main miodomel recipe and give my interpretation of it at some point in the future, but for now, here is an excerpt from the 1845 book “The Beekeeper’s Manual”1.
An immense quantity of honey is consumed in miodomel, which is as common as beer in this country. The numerous Roman and Greek monasteries have always their cellars well stocked with this favourite beverage. The monks, friars, priests, and nuns, of all orders and denominations, are exceedingly fond of it, and they know best how to make it. And, as there is a very numerous body of these fanatics or idlers, they help greatly to the universal consumption of the products of the earth, especially of honey; the only good they ever do render to the communities which feed them.
Let’s intelligently connect many pieces of legacy infrastructure to the internet, and do it in such a way that insights can be gleaned from the all data it generates. The premise sounds simple enough, but in practice such a project requires deep knowledge of a wide range of technologies. However, by breaking the problem down into discrete, logical pieces, we can prove that a working solution is possible in a relatively short period of time. We did this exact thing for a recent project, and this is the overall approach we took.
In this series we create modern interpretations of ancient meads. This time we will look at a circa 1660 metheglin recipe from Belgium. The original recipe says that hops can be used to help preserve the mead, and we will be making that miodomel (mead with hops) version. We are going to use Saaz hops, which we hope will help bridge the mildness of the mead with the spiciness of the clove and ginger. Our one gallon interpretation uses SafAle BE-256 yeast, paying homage to the original recipe’s Belgian roots. The original and modern interpretations are below, if you are up to it.
From the fourth quarter of 2017 through the first half of 2018 I was almost exclusively creating Ruby on Rails applications. After the excitement of mastering a new toolset wore off, I started to feel that I was working on a dated platform. There’s nothing inherently bad about Ruby on Rails, it is a time-tested and validated approach for creating reliable monolithic web applications. But, having just previously worked at a shop where we figured out how to build actual microservices, building monolithic applications simply felt dated.
I certainly wasn’t going to use microservices out of the gate for my side projects, but I at least wanted to abstract the presentation layer from the data access layer. So, I needed a set of tools which made creating SPAs (single page applications) and APIs as easily as it was to create views and models with Rails. Where I landed isn’t quite as easy, but it is fairly enjoyable, and I really don’t even know what I’m doing yet. The stack I landed on was Elm for the front end and, for now, FeathersJS for the backend.
I have often heard people say, “the data speaks for itself.” This sentiment is not only naive, it is also very dangerous — especially in a world of big data and machine learning. All data is seen through a lens, and the conclusions drawn from the data will change with the perspective of the interpreter.
We know that if we give an article to one of our right-leaning friends they could give us a much different interpretation than if we gave the same article to one of our left-leaning friends. The lens that they use to make meaning of the article determines the conclusions they will draw from it. This is no different when raw data is algorithmically interpreted.
Modern web applications are commonly split up into two major parts. The first part, called the front-end, is the part that most people interact with. The second part, called the back-end, is hidden from users and manages all of the information which is needed by the application. Splitting applications like this separates the rendering of the information from the generation of the data, which brings certain efficiencies.
Last summer we drove from Akron to Fort Collins, Colorado. Although it was a great experience, we wanted to drive a little less this summer. So we came up with a new adventure idea. We wanted to find a place which was off the grid, but had front-country amenities, like running water, toilets, and great food. And, it had to be within about eight hours of Akron. It seemed like an impossible ask, and I was fairly sure that we would have to compromise on at least one aspect. Then I found Charit Creek Lodge in Tennessee. Amazingly, it has all the desired amenities and is just seven hours and fifty minutes away. As an added bonus, it costs about the same as a stay at a major hotel chain.
Rather than driving straight to Charit Creek, we decided to break our trip up. We were going to do a mix of backpacking at Zaleski, car camping at Cumberland Lake, and lodge camping at Charit Creek.
The last time we headed to the Red River Gorge our intent was just to climb some real, outdoor sport routes. As a part of that goal we wanted to explore the Muir Valley. Now, having a modicum of experience, we had loftier objectives. We wanted to top out on something which was higher than we could get in a rock gym. This time our goal was to send Eureka.