Ever since classes went fully online in the spring semester, I've had a horrible time concentrating during lectures. There's the usual self-caused distractions—the phone, the browser, literally any other room of the house besides the one with the lecture playing—but even when I'm there, trying to focus like a Good Boy, it's really hard to lock in and take something from the class. Since the classes are three hours long, only twice a week, it's a real grind trying to force focus. Don't look to me for advice on how to do it.
Except today—I tried something accidentally. In the finance class we were doing some calculations on bond values, and I went to Excel like I normally would for calculations. And we occasionally needed to shift the term length on the bonds, and calculate the annual value like we would on a timeline, and Excel was just feeling a little too stiff—changing the number of rows or columns or whatever on the fly, manually. And I was focusing that great anyway, so I popped open Eclipse and started trying to create the calculations in Python instead.
I never really got the thing to do much yet (finance_sandbox.py) but there was a different kind of focus that set it once I started doing it. Setting up classes and thinking about what attributes of the bonds I had to capture from the lecture, trying to quickly think of abstractions so that I could calculate problems with different features from the lecture—having to create and re-create the most basic aspects of the things we were learning about turned out to be very helpful.
I'll tell you one of my personal hells:
"Ce qui vaut la peine d'être fait vaut la peine d'être bien fait". ("What is worth doing is worth doing well".) You've heard that one before. That's just a gateway drug, though. Doing something well leads to wanting to understand the patterns and causes and then, once you can start to get a grip on the classes and methods of that something it's only natural to want to start building a machine of some sort to do that something for you.
(I'm saying "you" but I know I'm thinking "me". Bear with me on this one. I need to talk about this like it's your problem. It's easier to deal with, etc.)
My big Home Project now is building some steps from the back door of the garage down to the back yard—the Backyard Steps Project. In isolation: it's not that difficult of a problem.
My wife would also like the backyard to be leveled—the Backyard Leveling Project. In its current state (which I was tempted to call its "natural state", although this would be a casual lie because it was certainly modified during the installation of these suburbs in the ~1960s, and perhaps even before that, I don't know) there is a downslope from north-to-south and from west-to-east. As the proud owner of a shovel (a collection of shovels, really, don't judge), the solution to the leveling problem is simple: take a shovelful of dirt from the high side and put it on the low side. Repeat until there is no high side or low side.
Simple specification, simple implementation. I'd crawl on my knees and beg for a spec to be this easy to implement at work. However, there is some coupling between the Backyard Steps Project and the Backyard Leveling Project that is giving me a headache.
How many steps does one need? Assuming you care about your user (you should—I do), the steps should be an equal height—an obvious assumption, sure, but we're just building out the model here. Now you have h_step, and n_steps * h_step will be the total elevation change (h_total) from the landing at the top (z_top) to the landing at the bottom (z_bottom); or, in reverse, the total elevation change will give you n_steps, just divide h_total by h_step. z_top is fixed—the garage slab is not going anywhere. But z_bottom is z_backyard, and the value of z_backyard to use is its future value, after leveling. h_step—we'll limit the values for this one between 6 and 7.5 inches.
And, to some extent, since setting z_bottom affects the rise-over-run of the whole set of steps, z_bottom also affects d_step, the depth (or amount of run) of each step—and we'll also assume d_step to be equal for all steps. But this can be somewhat mitigated by changing the length of the top and bottom landing. (w_step, the width of the path, was fixed at 60 inches through what we might call stakeholder feedback.)
A diagram would be helpful, no?
I've also gathered measurements (good ol' stick, string, and bubble level) for the project. The measurements break down into two groups: (1) the ground leading from the garage door to the edge of the deck (a single arc); and (2) the back yard measured in 2-ft increments 32 feet south of each deck pier (so, basically, six arcs of data). Call it data_1 and data_2 for reference.
data_1 is easy because it is just measured from the deck (the top edge of the deck planks) down to the ground with a (large) ruler. It assumes that the deck level is fixed because otherwise why bother. It also assumes that the east-west slope here is zero, which is not accurate, but not far off—since this bit is not part of the yard leveling scheme, it doesn't need to be accurate, I'm not accounting for the volume of dirt to move.
data_2 was massively annoying to capture. I attached the string a clamp on the wood supports one inch above each of the concrete piers to provide a reference height for each series of measurements. But each pier has a different absolute height—so, essentially, there is a z_string for each series of measurements that defines the height of the fixed string above the ground to give the raw measurements.
This all needs to be adjusted so that the height measurements are taken from the same level—deck level.
There is one more transformation that I did, that might be overkill—but what the hell. As mentioned at the start: if it's worth doing, it's worth overdoing. The distance measured south of the deck is really the distance along the ground, not the distance measured along the north-south axis—so a little trigonometry needs to be done to pull out the y-axis (north-south axis) component.
Then add in the distance between the piers for x-axis (east-west axis):
Then, at this point, I've got the transformed (x,y,z) field data for leveling the backyard.
It's the most wonderful time of the year.
This is my third batch of eggnog, and the motivation is still the same as the first time: make an alcohol drink with raw eggs and then age it for 30 days? Gotta try that.
It seemed a little crazy. That's exactly the sort of thing that people who would drink alcoholic milk would say to do. That's what Michael Ruhlman said to do. So did J. Kenji López-Alt. So I tried it, waited 30 days or so, and it worked. And I tried it again, waited 30 days or so and it worked—but we didn't drink it all and I ended up aging a jar and a half for about 13 months and it still worked.
I used the original recipe without modifications, except for not using the full measure of sugar (I started with 2 cups of sugar, then scooped some out until I felt less disgusted about how much sugar there was):
There's not much to it:
Bonus: Here's a bunch of links to other people who tried it:
When I saw the phrase "30-day eggnog" show up in my RSS feed, I knew right away that I had to try it. It was too weird of a concept to let it pass by. Michael Ruhlman: "Plan ahead: 30-day eggnog".
I've never made eggnog before. Growing up, we just bought it at the store. I knew eggnog proper had some alcohol in it, but I assumed it was mostly eggs and milk with just a little bit of alcohol. Wrong. Flip that equation around.
So, while the eggnog is aging in the refrigerator—either mellowing into a more complex flavor or preparing to kill me—here's how I set it up. The recipe is 75% of the one on Michael Ruhlman's site because I only wanted to buy a 750 mL bottle of bourbon.