Costco sells an apple juice that is perfect for making cider. We used 6 gallons of this and a bit over two pounds of strabwerries with Nottingham yeast.
Brew date: 2019-05-20
The last brew made a very light beer, suitable for 소맥 but not very satisfying. The main problem seems to have been that I used the top plate in the grain pipe during the mash, and that ended up compressing the grains too much. As a result, the water would not flow through it very well. The resulting beer is something like 3% ABV.
Today's brew is a Lakefront ESB from Northern Brewer. We'll try the robobrew again and see how it goes this time.
I'm slowly converting my brewing to metric units, but the kit was in English units, appropriate for an ESB.
I found some formulas to determine mashing water. I wanted to collect 5.5 gallons of wort for my fermenter, and various parts of the internet suggested 5 liters would be lost to the boil and trub.
Here's a table with all the values.
| Measurement | Value |
|---|---|
| Grains Lbs | 10.5 |
| Grains Kgs | 4.7619048 |
| Target Volume L | 25 |
| Boil and Trub Loss L | 5 |
| Mash Volume | 16.357143 |
| Sparge Volume | 17.452381 |
The first thing was to crush the grain. It occured to me that I could crush the grain directly into the grain pipe. So I set it up this way:
Figure 1: Crushing the Grain
It worked very well. I think next time I will use more water in the mash; it took a while to mix everything together. But I didn't have to get a bucket dirty, and since the base of the grain crusher covered the pipe completely I didn't have to worry about dust getting everywhere.
Here's the result after adding the carrying handle:
Figure 2: Grain is crushed
Another experiment today was brewing inside. Here are two pictures of the setup, one with the pipe resting on top, and one with the pipe inserted.
Figure 3: Setup 1
After inserting the pipe and stirring the grains, I could use the recirculating pump to keep the liquid moving.
Figure 4: Setup 2
The next experiment was to use the counterflow chiller instead of the provided immersion chiller. I used a pump to make sure the liquid could get into the fermenter.
Figure 5: The Chill
This brew went much better than the last one. I added some DME, maybe about a cup, to top off the gravity points, and was able to hit my target O.G.
The one mistake I made was it didn't occur to me to check the wort temperature before I added the yeast. It was still about 100 F! It doesn't seem to have hurt the yeast, fermentation started quickly. I guess I can pretend it's a Belgian ESB if there are esters as a result. :)
Tired of typing in that long directory name?
Sometimes when I am developing something I will end up
working in two separate directories that are not that
related. For example, I may be writing slides in my
~/class/cs421/periods/course-introduction/slides/
directory, and when they are done I want to put the
PDF in ~/web/cs421/slides/.
You can save a lot of typing by creating some variables for it. So instead of
% cd ~/class/cs421/periods/course-introduction/slides/
% make slides.pdf
% cp slides.pdf ~/web/cs421/slides/introduction.pdf
you could have something like…
% slides=~/class/cs421/periods/course-introduction/slides/
% web=~/web/cs421/slides/
% cd $slides
% make slides.pdf
% cp slides.pdf $web/introduction.pdf
If you are going to use them a lot, you can put them in your startup file.
Another similiar trick is to use tab completion. I'm using zsh, which
will run sub-shells if you hit tab. Suppose you are in that $slides
directory as before, and you want to access the directory
~/class/cs421/periods/recursion/slides. Yeah, you could use ../..
but that can get tedious. But you could also type
cd $(pwd)
and hit <TAB> instead of <ENTER>. This will run the pwd command
and paste it into your command line, leaving you with
cd ~/class/cs421/periods/course-introduction/slides/
You can then just edit the line to get what you want.
zsh extension to cd.
If you give cd two targets in zsh, it will treat that as a search
and replace command for your current directory name. So
cd course-introduction recursion
will do the same directory switch as above.
I have long been a fan of task management systems. When I was a student, I used Day Timer products a lot, and as the web came of age I tried many services: Remember the Milk, Nozbe, IQTell (may it rest in peace), and so on. As convenient as they were (usually) I found they all suffered from a combination of problems. Most were not flexible enough to keep the data I wanted. Most made entering tasks slower than it should be (something that someone proficient in an editor would notice). Some sites closed down; IQTell, in particular, closed after I had spent a month getting everything tweaked the way I wanted it.
I finally fell back on the one system I knew I could always rely on, would never close, and would be organized exactly the way I wanted: Org Mode. I have been using Org Mode for my task management system for a bit over a year now, so I'm documenting here how I have it set up. I will assume you are familiar with Org Mode already. If not, take a peek at Org Mode - Organize Your Life in Plain Text.
This will be a series of posts. For today I will go over the file structure I use: if you are already familiar with org-mode you will be able to replicate much of what I do.
One of the first decisions you will need to make when you set up your org files
is whether to have a bunch of files, one for each context, or One File to Rule them All.
Having tried both, I found I preferred to have separate files. I have a "main" file called
gtd.org, which I will talk about later, and one file for every context. For example,
there is cs225.org and cs421.org for two of the classes I teach. There is ielite.org
for a research group I am a part of. I have a subdirectory students/ where every student
working on a project with me has their own file.
My main reasons for splitting the files by context are to prevent needing a top level header for everything (or else mixing unrelated projects and tasks together), and to keep the file sizes managable.
My file headers contain the TODO tags, a directive to have log drawers, and an agenda
format string. The last item is the file tag. Here is the header for CS 225.
#+SEQ_TODO: TODO(t) NEXT(n) STARTED(s) WAITING(w) DELEGATED(e) APPT(a) MAYBE(m) | DONE(d) CANCELLED(c) DEFERRED(f)
#+STARTUP: logdrawer
#+COLUMNS: %40ITEM(Task) %17Effort(Estimated Effort){:} %CLOCKSUM
#+FILETAGS: CS225
Each file has a subset of these top level headers:
## Meetings
I want to be able to keep track of meetings I go to, and especially
meetings I am in charge of. For this, every agenda file has a top
level header * Meetings
Each meeting has this structure:
** <2018-09-11 Tue 10:00-11:00> Admin Meeting
*** Tasks
*** Agenda
*** Notes
The headline is level 2, contains a date stamp in the header itself. This causes it to appear in the agenda, and the agenda view automatically knows to remove the date when it displays the meeting.
If I am in charge of the meeting I will fill out the agenda, and have a task to email the agenda the day before. Tasks that arise during the meeting as a result of decisions get filed under the respective file-level task or project headings. The tasks here are only tasks directly related to running the meeting itself.
The reason I do this is because of a super convenient function
org-clone-subtree-with-time-shift with default keybinding C-c C-x c. Set
up the first meeting with the proper date stamps for the meeting and any tasks
that will recur (like sending the agenda) and then duplicate it, shifting the
dates into the future as you do so.
An appointment is very much like a meeting, except that I don't expect to need to take notes or organize it. I use this for office hours.
This heading is for all tasks that do not belong to a project. I use
the SCHEDULED property to set a start date, and a DEADLINE for real
deadlines. One thing I do differently than classic GTD is put a start
date on all tasks (unless they are in someday/waiting). I learned this
from the Manage Your Workday Now book written by Michael Linenburger
I also like to have an effort property.
A project is just a list of tasks, but I insist that there be one task
marked NEXT instead of TODO. There can be a header in the project
for reference information if need be.
I'll talk more about task and project processing in a future article.
I do not like the way Org archives things in a separate file, so I am trying to keep a headline for archived tasks and archived projects. This may end up getting to bloated, but I haven't used this very long yet. Time will tell.
There will be followup articles about other aspects of this. Currently I plan to write about the actual task workflow and the emacs lisp code I use with it.