I previously wrote about setting up Tensorflow for object detection on macOS. After getting everything set up on the Mac I very quickly decided that it would be worth it to get Tensorflow running on something other than my main development computer. Running Tensorflow to train computer visions models on my Mac consumed all available computing resources. Nothing else could be done while the training was in progress. And, it was not taking advantage of the GPU. Using a dedicated Ubuntu machine with a GeForce GTX 1060 graphics card would be a much better option.
It took a lot of work to get a GPU enable version of Tensorflow installed and running properly. Then, after it was working for a few months, a kernel update caused it to suddenly stop working. I didn’t immediately know that the problems were caused by a kernel update, I though some other updated dependency was the culprit, so I didn’t just roll the kernel back and call it a day. Again I had to spend a good amount of time piecing together different references in order to get everything working properly. I documented everything in one place to make the process easier in the future.
The real moral of the story is probably that it is worth it to use cloud-based compute resources for these sort of tasks. That is especially true if the task allows for TPUs to be used. Regardless, if you have an unused gaming or mining machine sitting around and want to get Tensorflow running on it, this is how I did it.
Tensorflow is an amazing tool, but it can be intimidating to get it up and running. I wanted to help someone get started with Tensorflow on a Mac, and if I had written all of this down then I could have just given them a link. This post isn’t a captivating read, it’s basically a list of commands, but it allows me to easily share my setup instructions. I’ll try to give a short explanation of what needs to happen and then a block with required commands. If you are in a hurry, don’t care to know what is happening, or have an odd blind trust in me, then you can skip the explanation and type in the commands at the end of each section. Conversely, if you follow along in the explanation section, then you don’t need to re-type the commands that appear at the end of each section.
There are many different applications for Tensorflow. We are currently using Tensorflow for object detection, so these instructions install everything which is required for that task. Other task could require additional prerequisites. If you are still here, then you probably need to get Tensorflow Object Detection API set up. In that case, open up a terminal window and read on.
On our first climbing trip, in the still very frigid month of March, a group of six of us went to Muir Valley. For our second trip, in the surprisingly sweltering month of May, four of us made the journey to the Red River Gorge. For our last trip of the year, our group had dwindled to three. The rest of the group was, respectively, busy taking care of a new human, finishing a doctorate, and settling in to a new job. Which, from a climbing perspective, was a shame. The weather for this trip was just about perfect. It was cool with low humidity, and the remnants of Hurricane Willa passed to the north of Kentucky, yielding only mild showers on our travel day.
The only downside to beautiful weather is that everyone likes to get outside and enjoy it. I would guess that the number of climbers out on any given day is somehow proportional to the quality of the weather. Fortunately, there is so much accessible climbing in the Red River Gorge that, with a little planning, it is not hard to find a wall to climb. And, great weather opens up routes which are less desirable under cold or raining conditions. Our unofficial guide, Doug, picked some crags in the Pendergrass-Murray Recreational Preserve (PMRP) which seemed likely to give us good climbing opportunities.
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.