Docs Decomposer Week 7

This weekend I solved a problem I’ve been bothered by for weeks: Given a list of pages with a dynamic priority or risk button on each row, the sortable tables didn’t reflect changes in priority or risk until I reloaded the page. It felt good to see that one go down, and it felt good to drop a bunch of lines of code in the process.

So, I think we’re done here. Or at least, we’re in a place where I can do everything with this tool I wanted to do, plus a few things I hadn’t thought of at the time.

I didn’t keep very close track of my time. If I had to guess, I think I spent somewhere around 40-50 hours, or an average of an hour a day from my first commit on February 13. The vast majority of that time was here and there on weekends, but I put in a few lunches, too. It occupied a funny space: I didn’t want to devote work work to it in case I got stuck and couldn’t see it through. So it felt better to file it under “hobby that may prove useful.”

Other stuff I finished up this weekend:

  • Some rake automation, which makes setting everything up pretty quick.
  • A HTML reimport button, to refresh the contents of a page if the underlying content in the git repo hasn’t been recently refreshed.
  • User pages, so it’s possible to look up a user and all their commented or flagged pages.
  • Sortable tables that work.
  • Unicorn/nginx, which was ops’ recommended approach to get this thing onto an internal box.

Stuff I’d like to do next:

  • Connecting Devise, which I’m using for authentication, with LDAP.
  • An “export new metadata” gadget, to make it easier for writers to quickly generate new YAML frontmatter that includes their tags and risk assessment, for copy and paste into documentation.
  • Revising the importers to understand our pre-release content repository and internal preview servers.
  • Write some tests. I’ve never really done much with testing, and I’d like to learn how. That’d make my friend in ops, who’s been helping me get this ready to deploy somewhere, a little happier with the whole affair.

Docs Decomposer #4

Tags ended up going in pretty easily with acts-as-taggable-on. It allows for mutltiple kinds of tags, which means with judicious use of forms you can pretty much create any kind of taxonomy you want. I’m just using keywords for now, in a classic free-tagging setup. With judicious use of forms to control input, I’ll be able to add risk and priority tags.

Docs Decomposer

Which means, I guess, that the thing is pretty much “done” in terms of the basic features I’d like it to have:

  1. Individual user accounts.
  2. The ability to quickly reduce a given page to just the steps and CLI instructions.
  3. The ability to flag a page with a click.
  4. The ability to comment on a page.
  5. The ability to tag a page.

Over lunch, I broke my “don’t do this in the office” rule briefly to add some markup to our Jekyll templates to make it easier to grab the rendered content for import. The importer became a little simpler as a result, and the pages lose a little bit of extra nav cruft from our templates.

So, as it stands, I could pretty much run an inventory session for the team from this thing running on my laptop. The one thing that’s still vexing me about it is the notion of unique and trackable page elements (ordered lists and code blocks, mostly).

In my Padrino prototype, each page showed the rendered content, plus a tab that showed only ordered lists and pre-blocks. Each <ol> and <pre> was checksummed, and the “elements” tab showed which other pages in the docs corpus had the exact same content.

What I really, really want is something like this:

  • You look at the page and see a <pre> block that concerns you, either because it looks very perishable or could be harmful if the information has aged out.
  • You hover over the element to expose a flag or comment button, plus a little stats box that tells you where else that element appears.
  • Once you flag that element, it’s flagged everywhere it appears in the corpus, receiving a special visual treatment.

How’s that work?

Everything is parsed by Nokogiri, so I can just write a little checksumming service in my Elements controller that will be seeing the same HTML whether it’s getting it during the content import phase, or the presentation/review phase. So:

  1. User loads a page.
  2. JavaScript finds each element of interest on the page (each <pre> and <ol>) and sends it over to the checksumming service.
  3. The checksumming service returns a unique i.d. for the element.
  4. The element gets wrapped in a div with that i.d. (in case it already has an i.d.)
  5. The comment/flag widget for that element is just AJAX calls to the controller against the i.d. of the wrapper, which gets a class to reflect its flagged status.
  6. Each flagged element gets either a modal/lightbox or a page with the comment history.

Now that I write it all out, though, it seems pretty doable. I should probably write more stuff out.

Flaws in the plan? Mostly that it’s going to add some load time as each page is pulled in, dissected, and checksummed. Fortunately, there are advanced GIF technologies to make that seem almost pleasant:


It’s something I could do at import time, too, I guess. There’s nothing sacred about the underlying markup.

Oh, the other problem is “what about when that element changes, even if it’s for the better?” At that point, the checksum changes and the flag/comment history disappears because it becomes a “new” element. There goes the inventory. Which means the inventory might become something less about the literal content and more about what/where it is, e.g. “ordered list on page #{foo} under the heading #{bar}.” So when a flag gets thrown on an element, the existence and “coordinates” of the thing are logged somewhere, along with a snapshot of what it looked like at the time. That’s probably going to be enough to find it again.


So we could go either way here. I think writing the checksumming service and coding up the process sounds interesting and fun. I think deciding that flagging elements and leaving comments on them as a one-time process with no expectation of permanence might be okay. I think automating a log based on “there’s a fishy set of instructions on the page called #{foo} under the heading #{bar}” sounds like a useful middle ground. I’ve also already figured out the xpath needed to do just that: “Show me a thing plus the most recent heading that occurred before it,” which has proven great for explaining what some of the lists and pre blocks are trying to tell you at a glance.

Well … something to think about.

Docs Decomposer Weekend 3


I added a Comment model to the project this weekend, then wired it up to a modal form. Useful things I learned to use this weekend:

  • simple_form, which makes it a little easier to write forms in Rails, and which understands Bootstrap.
  • markdownizer, which can take a text column and render it to Markdown on creation, which will help make the comments a little more expressive.

And since I’m using twitter-bootstrap-rails, I got some handy freebies for styling the flash with Bootstrap text styles.

A few things I didn’t get to:

  • Making it possible for users to delete their own comments.
  • Making it possible for users to edit their own comments.
    In other words, the comments feature sort of sucks, but at least you can suffer in Markdown.

  • Connecting the act of flagging to invoking the comments form.

And to replace the spreadsheet we came up with to review the upstream platform docs last week, I probably need to add a tags field of some kind. I think that’s a solved problem.

One more weekend?

Docs Decomposer

Menubar and Docs Decomposer and CSS Bootstrap

Docs Decomposer Weekend 2

Last week I left off with a gnawing sense of unhappiness because the flagging buttons weren’t dynamic: When Rails dropped Prototype.js, it dropped pretty much all the stuff I knew about AJAX and Rails. I could have left well enough alone, but it bothered me; and we’re doing this in the name of (re)learning.

I had fun working on it. Last weekend’s time involved a lot of re-orientation on the basics. This week felt pretty fluid as stuff I’d forgotten came back, and as I got used to a few of the tweaks I added to Emacs last week (including flymake and Projectile).

In the process of rewriting the flagging code into something a little easier to work with, I learned about acts_as_votable, and that encouraged me to just toss the flagging code I’d written altogether. Yay, cargo culting. That didn’t make the dynamic flagging button situation any better, but it did make a few other features fall down much more quickly.

So this weekend I added:

  • Flag status indicators to the page lists. You can tell if you’re the one who flagged the page, and if someone else also flagged it along with
  • A toggle to hide all the unflagged pages
  • A little list of who flagged a page on the page itself, along with next/previous buttons for each page, to make it easier to run through review without going back and forth to the master page list:

Next up, I guess, is commenting. I was hoping to get to it this weekend, but once I had acts_as_votable in place, it was a lot easier to run through a bunch of flag-related things and implement them, and I was ready for some easy stuff once I’d finally managed to make the flagging buttons dynamic.

Once I’ve got commenting in place, it’ll be time to go back through and do a lot of housekeeping. I’ve got view code that probably ought to go into partials, controllers that could probably stand to have some logic moved out into the models, and a lot of code that … well … it’s optimistic is what it is!

After that?

The thing I keep thinking about and sketching out is how being able to flag a given element on a page might work. One of the reasons I decided to just import HTML straight into the app was that it gave me access to the markup. For instance, once you find and checksum an ordered list, it’s pretty easy to wrap it in a div and give it an i.d. At that point, it can be targeted for flagging widgets and such.

Dunno. Bedtime.

Weekend Science Project (Rails After Time Away)

We need to do a documentation inventory at work. We’ve added a lot to the docs over the past year, and we’ve got a few things lurking around in there that need to be flagged for QA or revalidation. The stock answer is “put all the pages in a spreadsheet and start clicking/scrolling and annotating the list,” but I’ve been pining to fiddle around with a tool for a little while, and spreadsheets suck, so I decided to see how quickly I could put something together to make the job a little easier for the team (and reviewers down the road).

I started out with a Padrino app, which was a great way to do a proof of concept on what I was after:

  • Find all the Markdown files in the docs repo.
  • Use the filenames to compose the live URLs of each document.
  • Pull the HTML in from the server and store it for fast retrieval/decomposition
  • Identify all the elements of interest on each page and store them with a checksum.

For that last, “elements of interest” became “ordered lists and things inside pre tags.” They represent the step-by-step instructions in the docs; either in “do this, then this, then this” form, or in “start typing this stuff on the command line” form. They’re the things people gravitate to and start following, and we know that the average technical user is prone to looking for just those things and not looking at the surrounding text.

Putting a checksum on each of them will provide a way to do reports that show when an element appears on multiple pages, and across multiple versions of the docs. You kind of expect things like ordered lists to change a little over time. If one has persisted over four or five releases without changing, you might want to look at it and make sure it hasn’t been overlooked.

So after four or so hours of work, my Padrino app could do all that stuff, wrapped up in Bootstrap. I could fire up the app, get a list of all the documentation pages by product version, and use some widgets to do a few useful things:

  • See all the elements of interest in their own tab.
  • Preview a docs page, then click a button to show only the headings, pre blocks, and ordered lists.

That seemed pretty useful just as a way to help someone rip through a collection of pages and look for just the things most likely to cause a user pain, then maybe enter them in a log.

Once I was home for the weekend, though, I realized that I wasn’t as familiar with Padrino as I once had been with Rails, so I decided to do a quick port. Since I’d used ActiveRecord for the original app, and since I was happy with my db schema, it was pretty simple to set up the models, re-run the migrations, and reuse the importer scripts to repopulate my development db with content.

I spent a few hours on Saturday and a big chunk of Sunday trying to see how far I could get before, well, having enough time to blog about it before ending the long weekend and going to bed. I didn’t want to put any more time in on it at work, because if I ran into a dead end and couldn’t make what I wanted, I didn’t want to feel obligated to try using it.

I had to relearn a few things about Rails that have changed since I last used it much (during v2 times), and I had to learn some new things about jQuery that I’ve never dealt with before. Still, I’m pretty happy with where it’s at now:

First, I implemented flags. For now, all you can do is flag a page if you see something you think might be a problem that needs further review. I’ve got a few ideas about how to flag individual elements. One way is super simple, but doesn’t allow you to flag them in the context of the text. The other is tougher and I’m still working on relearning Rails’ AJAXy stuff to figure out a way to flag an element in place, store it, then have it highlighted as flagged next time you visit that page.

Next, I added a working user authentication model with Devise, so flags can belong to individual people. For now, it just means that if two people look at the same page, they don’t have to agree on its flaggability. Down the road, it’ll mean there’s a way to share the tool with all our technical reviewers so that they can flag things and we can capture all the flag data from them. I’d like to add a way to enter a comment, too, but one thing at a time.

Finally, I got thiiiiis close to making the flag button truly dynamic. All the AJAX stuff I knew from when I built my last Rails app has changed, and I couldn’t figure it all out in time, so for now I just force a page refresh when the user clicks the flag button to get it to change its state from “flag this” to “unflag this.”

There are a few more things I’d like to get to:

  • Report pages, naturally: Every flagged page, how many flags it has. That won’t take much.
  • Flaggable elements (ol, pre): I can already do this the easy way, but I’d love to do it the hard way.
  • Comments to go with flags, with design to accommodate a running list of flag comments down the side of a page preview.
  • Dynamic page import. Right now, we get the map of all the files then suck in their HTML and store it. The advantage is that it’s pretty fast. The disadvantage is that the content will drift from reality over the course of a release cycle. Way better to either suck it in each time the page is viewed or offer a “re-import the HTML” button people can hit.
  • Links straight to the files in the Github repo, so people can quickly fix things from the app if they spot something.

It’s in a place where I knock most of that stuff off with another leisure-time sprint, then see about hosting it somewhere relatively secure where I can put it in front of a few people for real feedback.

It also reminds me of all the stuff I wish I knew more about, like testing. I guess if I can get it into a useable state for other people, I can use it as a sandbox for learning about that stuff.

Anyhow, here it is. Hope you had a good Presidents Day weekend. Good night.

On the Quicksilver (and the curious marketing conceit “RV resort”)

IMG 4917

We took our new Quicksilver trailer out on its inaugural camping trip this weekend. A few notes on the whole thing:

We’ve got a Livin’ Lite Quicksilver 8.0. It’s a tent trailer, not a pop-top, so when it folds out it’s sort of like having an old-school canvas tent with a bimini frame sitting up off the ground on a big aluminum box.

Not being a pop-top, and being made of aluminum, it only weighs about 850 pounds, which is well under our Toyota Matrix’s 1,500-pound towing capacity. Driving it out to Mt. Hood this weekend was pretty easy. It was very quiet, and the main thing I noticed about it was how it affected braking: I definitely needed to give myself more time to slow down.

Setting it up is very easy: It has a vinyl cover you unsnap and roll up, a set of four aluminum struts that hold up the bed ends when it’s unfolded, and a bunch of snaps, velcro and bungie loops to hold the tent top in place. Ideally, you’ll want to deploy it with two people, but I’ve managed to put it up and take it down on my own. With two people, it takes well under 10 minutes to get from “completely closed up” to “fully deployed.”

Setup on the inside, once the tent is up, is pretty easy, too. The galley top (with a sink and a cabinet) can be lifted into place by one person. It has a folding table and removable seat cushions that stand up in a minute or two. There are also little light/fan combination units that clip onto the bars next to each bed end and plug in to 12-volt power sockets.

IMG 4909

As RVs go, it’s a pretty simple affair.

Each end of the tent has a double mattress. It’s also possible to collapse the dining table and lay it between the two dinette seats, then put their cushions down to sleep two more people. The mattresses on the beds are a little thin, so next time I think we’ll bring along our Therm-a-Rest pads.

It has an electrical system with three standard household outlets and a 12v adapter. You can run it off its own 12v deep-cycle battery, or you can connect it to shore power. It also has a small sink with a faucet that can either work with city water connected from the outside, or pump water from a plastic, 7-gallon tank in the galley base. It was pretty nice being able to wake up and start the water for the French press with an electric kettle. There’s no built-in stove, but there’s enough counter space to use the two-burner camp stove our dealer threw in. Alternately, there’s a small aluminum table you can mount outside the trailer to use for cooking.

It’s got pretty decent storage. The galley offers three small cabinets with plenty of space to stow cables, hoses, the camp stove, and first aid kit. There’s another cabinet by the door that can hold a few things you might want to grab out even before the trailer is fully deployed. The dinette seats also offer storage compartments. For travel, you can slide a few things under the dining table when it’s folded and placed over the edges of the dinette seats. We were able to fit everything for our trip into the trailer itself (including cooler and folding chairs), and didn’t have anything in the car with us.

We had good weather for our trip. It got down to the low 40s overnight, and we used a small ceramic space heater running off the electrical system to keep the trailer warm. I slept in an unzipped sleeping bag and stayed pretty comfortable.

IMG 4913

I can’t name many downsides. Sleeping with a heater in such cool weather did cause some condensation. We toweled a lot of it off before we packed the tent back down, and since it was sunny and in the high 50s this afternoon when we got home, we just set it back up again to air out and dry out a little more.

The city water pressure from our hookup was a little high and caused a small leak around one of the pipes. We spotted that happening pretty quickly. One of the nice things about the all-aluminum body is that it wasn’t a huge deal to towel up the water without fear of rot setting in.

All in all, though, it’s mainly a big tent on wheels, with plenty of space to sit around if the weather turns (or if you just feel like hanging out in there). It definitely changes your outlook about the weather when you know you’re sleeping four feet off the ground under a waterproof vinyl top. Because it’s a little more weatherproof than a tent, and because it’s easy to heat if need be, it extends our camping season quite a bit. Because it’s a little more comfortable to sleep in than a tent, it also extends our range. We’ll probably do a few more trips to some of the regional parks like Oxbow and Stub Stewart, just to make sure we’ve got the hang of driving a trailer around the metro area, but we’ve already got a spot reserved at Crater Lake this summer, and I’d like to figure out a longer trip somewhere further out before next year.

Where We Stayed

When we bought the trailer, the dealer included a year’s membership in an RV park network. We can stay in any of the parks in the Pacific NW for free for up to 30 nights this year.

We stayed at Mt. Hood Village. Since our trailer is just 16′ when fully deployed, we opted to stay in what you might call the “rustic” section of the facilities: Dirt sites with water and electricity (but no sewer or cable t.v.)

That was probably for the best: We had the entire area to ourselves. The premium area was packed pretty tightly with really big RVs. Yeah, they had a shorter walk to the (indoor) swimming pool and hot tub, but they also had to deal with all the hooting and yammering of people out under their awnings, drunk on Coors Light and the novelty of just-a-hoodie weather in January.

The vibe was pretty friendly. Our family did get the side-eye from a dude with a pony tail and the most gigantic owl tattoo I have ever seen: It spanned his chest and its eyes encompassed his pecs. He seemed a little miffed we were in the hot tub (which was huge … it could have easily seated 10 people), maybe because he was hoping to maul his girlfriend in there. Al & Ben left to go swimming, and he did get a little nasty with the towel-off once he and his girlfriend decided to climb out. Another couple in the corner looked to be completely fucked up on something that made them squint into the far distance and occasionally slur giggling observations. Oh, and Ben & I shared a sauna with a guy who’d bark “shut-it-shut-it-shut-it-the-heat-the-heat-the-heat” when people came in or out. He was also super worked up about a missing flashlight, and he snarled recriminations at one of his children through the steamed glass.

Still, people did smile and say “hi,” so friendly enough; but I think we’d have been okay just sitting by the fire, too. I also think that perhaps “RV resort” is one of the more interesting bits of branding nomenclature I’ve encountered in a while if that place is an average specimen. Your average state park is doing what it can to make the sites feel a little isolated from each other, and what you lose in the way of a hot tub, gift shop and swimming pool you make up for in relative quiet, hiking trails, twilight ranger shows at a rustic amphitheater, and fewer opportunities to see some dude with a ginormous owl tattoo toweling his lady off all nasty.

The membership is free for a year, though, so really we can live in both worlds if we choose.

IMG 4915


This video is 14 minutes of camper setup competency that I find a little hypnotic. It helps that the Livin’ Lite company is located in Northern Indiana, and so I’m hearing the voice of my people (more or less: I’m about two years more “from Oregon” than I am “from Indiana,” at this point).

Which reminds me of another thing that I enjoyed this weekend:

I worked at an RV plant the summer after I graduated from high school. I was really, really bad at it, but I learned a lot: I installed air conditioners, manufactured step-well covers, routed and secured fiberglass sheets to partition walls, undercoated vans, and did a bit of finishing work here and there.

Sitting at the table enjoying my coffee this morning, knowing the trailer was made in the same town where I helped put together RVs, it was pretty easy to see bits and pieces that looked like things I’d made or assembled that summer. You might see some of that stuff and not think twice about it, assuming a machine did it, but I spotted a few things: A small nick on the crimp on an otherwise perfect aluminum cover; and the thumbnail impression of a screw that had gone in a little off, then got pulled back out a bit and tightened back down a tiny fraction of an inch the other direction. For a second, I could smell routed fiberglass and rolls of carpet in a hot warehouse.

A Few More Org Findings

So, I learned something this week. Rather, I did something that was useful to me, which is stop short of trying to get GNUS working again. Instead, I focused on seeing if I could get comfortable enough with MobileOrg to use it (mostly I did) and I kept on working on making some of the things I like about OmniFocus work in org-mode. I think that slightly more constructive behavior — pulling away from a fit of emacsimalism before going completely toxic on it — made it easier to keep on going with org-mode.

So, here’s some of the stuff I learned this week. It’s mostly about how to use MobileOrg a little better, and how to control how much of your org-mode data you have to see at a time.

Better MobileOrg

I’m learning to trust MobileOrg, but it takes a little effort to make it work smoothly, especially if you’re coming from something like OmniFocus or Things.

Save all your open org mode files from the agenda with C-x C-s

Things has the very best sync I’ve seen in a todo app: It seems to “just happen.” Others require some sort of action on the part of the user, so if you’re the type to spend some time at your desk squaring away your actions for the day, then head into back-to-back meetings, it’s a pain if you don’t remember to sync before heading out.

Org-mode can, depending on your setup, complicate matters even more. If you live in multiple files and org-mobile-push without saving them, you get an imperfect sync. The best answer (without rigging up some kind of auto-sync), is to use the standard Emacs save command (C-x C-s) from an agenda buffer: It saves all your open org-mode files. Then you know it’s safe to push to MobileOrg.

Cheat a little with emacsclient until you can remember to save-and-sync

Emacsclient is able to run elisp from the command line, so if you can ssh into a machine with your org files and emacs on it, you can do an org-mobile-push from the command line without opening Emacs:

~$ emacsclient –eval ‘(org-mobile-push)’~

Set up refiling to more easily move things out of your inbox

Refiling allows you to move a thing from one org file to another. With MobileOrg, where the default capture method dumps you into an inbox file, it’s helpful to set up your refiling targets. With this example:

   (("~/Dropbox/org/" :level . 1)
    ("~/Dropbox/org/" :level . 1))))

C-c C-w would present you with the level 1 headings from your and files as targets for refiling, meaning a given org headline will be moved to the last line under the heading you select.

Leveraging the Agenda and Sub-Tree Narrowing for Focus

I really like the way OmniFocus handles its Perspectives and Focus features. It’s easy to quickly narrow down your view to things you need to work on or think about right now. I’ve learned two ways to attain similar constrained views in org-mode.

Narrow focus with the agenda

In a tool like OmniFocus or Things, you might have a few different views into your task lists to better organize what you’re working on and when you’re working on it, but the mouse-driven interface of those tools generally means your experience is one of moving between areas of the UI, or doing one-click state changes.

Custom Agenda Commands to Narrow to Contexts

With org-mode, you can use custom agenda views to pull off something like perspectives or context views, you’ll just be doing it with the keyboard.

When I use OmniFocus, my tendency is to make a lot of people contexts and a few mode contexts, but not a lot of place contexts. With org-mode, I use tags as contexts, and tag items with people. Then I made a few custom agenda commands that make it easy to drill down to specific people (either at my desk, or when I’m using MobileOrg):

    (setq org-agenda-custom-commands
          '(("p" . "People")
            ("pn" "Nick F." tags-todo "nickf")
            ("pm" "Michelle F." tags-todo "michellef")
            ("pl" "Lauren" tags-todo "lauren")
            ("pL" "Larissa" tags-todo "larissa")
            ("pp" "Pete" tags-todo "pete")
            ("pj" "Jean" tags-todo "jean")
            ("pi" "Isaac" tags-todo "isaac")

            ("g" .  "Groups")
            ("gt" "Tech Pubs Team" tags-todo "team")
            ("gl" "Tech Pubs Leads" tags-todo "leads")
            ("gs" "Engineering Staff" tags-todo "staff")

            ("o" tags-todo "office")


These views make it possible to generate an agenda (C-c a) then tap the p, g or o keys to get pre-built tag searches by people on my team, teams I work on, or items I’ve tagged as “office” (which is my way of saying “things where I need to get up and walk over to someone’s desk to talk face-to-face.”) Those same custom commands appear as agenda views in MobileOrg, so I can walk into a 1:1 and easily see everything tagged with the person I’m speaking to.

Restrict the Agenda to a Single File

You can also restrict the files the agenda uses to generate itself by invoking the agenda (C-c a) then tapping the < key before tapping a to generate the agenda. That will limit the agenda to the file you invoked it from. If you keep your todos in “work” and “personal” files, that means you can effectively filter out one or the other with a single extra keystroke.

Restrict the Agenda to a Single Subtree

You can also restrict the agenda by tapping the < key a second time. That will restrict it to the current subtree. That’s helpful if you keep lists of single-action tasks, or want to focus on the todos for a single project.

Narrowing focus with org-narrow-to-subtree and widen

The agenda has a bunch of single-key commands to cycle todo status, etc. By enabling org speed commands, you can get the same commands in an org-file. s is useful for narrowing to the current headline (great for focusing on a single project or area of concern). Map w to widen to quickly expand the file again:

(setq  org-speed-commands-user (quote (("w" . widen))))

Use TODO label faces

You can customize the way todo faces look by keyword. STUCK, WAITING and DELEGATED each get a special face so that when I’m scanning a file, they stand out a little (white on red, orange and gray, respectively).

If you use the OmniFocus defer date, use a “scheduled” date in org-mode

Like OmniFocus, org-mode has both a start date and a deadline date. Keep the agenda clear by planning start dates for things with “scheduled.”

You can make custom links in org mode really easily

Here’s one for linking to JIRA tickets:

Then use a “jira:” URL scheme in a standard org-mode link, jira:doc-988

Opening that link with C-c C-o will open your default browser and execute the search (which will take you to the ticket).

org-mode Face Lift

Menubar and usr local bin emacs q Dropbox org omnifocus org usr local bin emacs zsh 159×34 and Init File GNU Emacs Manual and Preview of org mode Face Lift

I realized a couple of days ago that part of the reason OmniFocus and Things feel better compared to org-mode is that they’ve got a much more pleasant visual design: There’s way more room, screen elements are better differentiated, and they present with a variable-width font. So I did some poking around in Cocoa Emacs to see if I could clean up org-mode a little. There’s no particular master plan here, just some things that made org-mode look nicer.

If you’re looking for the quickest wins, the first three (picking a better theme, hiding leading stars, and using org-bullets) make a big difference right away and work in both Cocoa and console Emacs. They don’t involve any fiddling with faces. The fourth (opening up the line height) works on Cocoa Emacs and definitely helps a busy file feel a little more scannable; and it’s also fiddle-free.

A Nicer Theme

The flat-ui theme gives Emacs a more muted palette that’s similar to the one OmniFocus uses. Stick it in your .emacs.d/themes and invoke it with:

(load-file "~/.emacs.d/themes/flatui-theme.el")
(load-theme 'flatui t)

Hide Leading Stars to Declutter

You can turn off the display of all the asterisks in a heading but the last one:

(setq org-hide-leading-stars t)

Use org-bullets

org-bullets gives you the ability to change the way the asterisks used in org-mode present on the screen. The defaults aren’t great. I ended up using normal bullets for level 1 and 2 headings (which are equivalent to folders and projects in my own org hierarchy) and open circles for lower levels (which are usually todos for me).

Downplay “DONE” and Similar States

I set the face for org-done to bright black and the weight to thin to help push completed items to the background. I often squirrel notes away under information gathering todos, so I don’t like to completely archive a todo until the project is complete. By muting the display of done items, they’re still there and searchable, but they don’t compete with active TODO items when I’m scanning my list.

Open Up Line Height

It helps to open things up between lines a little:

(setq line-spacing '0.25)

Differentiate With Size and Weight

You don’t need to go bananas. I gave the highest heading levels a small bump in size (:height 1.2 for level 1 headings, :height 1.1 for level 2) and helped them stand out by setting their weight to semi-bold. I sized metadata faces down to :height 0.8 (org-tag, org-date, org-special-keyword) and also made the tags face less dark, which reduces the sense of clutter and makes tags more scannable.

In the process of changing these faces, I learned a new trick I can’t believe I’d missed in the past: Place the cursor over a given element in an org file and use the command customize-face, and Emacs will present the face of the current text you’re on as the default argument. That makes it easy to visually identify what you want to change and quickly jump to its customization page.

Use Variable Width for Headings

… and maybe the body.

I explicitly set the typeface for headings to Helvetica Neue, and I’ve been using this hook for org-mode:

(add-hook 'org-mode-hook (lambda () (variable-pitch-mode t)))

It sets the body type for any org-mode buffer to variable width. The drawback of variable width type is that it breaks some indentation (since Emacs still thinks in terms of fixed-width characters). The advantage is that it’s a little more pleasant to read. I haven’t made up my mind about it yet.

If you do end up using a variable-width font for everything, don’t forget to explicitly set the face for org-table to a fixed-width choice.

All that gets you to here:

Menubar and omnifocus org and usr local bin emacsclient t Dropbox org omnifocus org emacs zsh 159×34 and Emacs Set Line Spacing and org mode Face Lift

Review It in a Terminal Window

Because it ought to be able to work there, too.

Menubar and usr local bin emacsclient t Dropbox org omnifocus org emacs zsh 159×34 and Preview of org mode Face Lift and org mode Face Lift

In a Gist

If you’d like these to play with, I put them in a gist for easy cut-n-paste inside a custom-set-faces block in your own init.el:

Have Some mutt Macros

I ran through Steve Losh’s the Homely Mutt, which I am willing to stand behind as the best guide to setting up mutt on a single-user system, if you’re okay with running server-style stuff on a laptop or desktop machine. Personally, I’m not (for fiddly, neurotic aesthetic reasons). You can run mutt just fine via standard IMAP if you’re okay with giving up really good search via notmuch, but the package Losh puts together (mutt, offlineimap to Maildir, notmuch for search, postfix as a relay) gives you the very best mutt experience and gives you a local backup of all your mail you can access with anything else that groks Maildir. So if you’re in an erratic orbit around Emacs with stuff like GNUS, well, a little investment in offlineimap reaps years of futzing with email clients.

Anyhow, I do have a Linux box running under a desk at home along with mosh, which makes my logins to it from work feel pretty persistent. So given a thing I think of as a “shell box,” I’m fine running offlineimap on a cron job and postfix in dumb satellite mode if it gives me the single best email client on the planet to optimize for keyboard-centric use and versatile view filtering.

Keyboard-centric view versatility is theme number one for these macros. Theme number two is separation of mail personae, which I’ve handled with the creation of mail-account-specific profile files and macros that allow me to switch between work and personal accounts quickly, and without wondering if my signature and other profile-related stuff have been set correctly when I compose a message. So anyhow, here they are:

… and here’s my whole muttrc (Gmail IMAP variant) or offlineimap/Maildir variant. I think the scores and colors (which interact with the scoring I’ve set up) are the most useful things in there.

Breakfast at Oliver’s


I appear to have eaten at Oliver’s Cafe about 90 times since March, 2012 (can’t account for a few cash transactions). I ran the Quicken report that told me that through a quick script to count how many of those visits were on a Sunday (“Dad and Ben breakfast day”): Harder to know that because the date of the transaction going through varies from the date the transaction happened, but it must be about 70.

Ben’s got a usual: 2 scrambled eggs, a sausage patty, a cinnamon roll and a cup of decaf. He settled on that after a streak where he was all about the bacon pancakes, which are incredible but also torpor inducing. Lately I’m all over the place. The coffee is a constant, but it’s hard to choose between all the scrambles and omelettes, plus the occasional bacon pancakes or plain old hotcakes.

When we first moved here, the space Oliver’s is in was occupied by Le Sorelle Café. You could get coffee and pastry and panini there. We’d stop in on Sundays after going to the farmers market. Le Sorelle didn’t last. Coffee in Lents, in general, does not last unless it’s being served out of an espresso hut. That’s a shame, because until the neighborhood is ultimately overrun by people like me, it’d be nice to have a slow but steady coffee place to go work at now and then. We had that in the form of Lents Commons, but it fell apart pretty quickly because it was never meant to be a coffee place: The owners wanted it to be a performance space.

Oliver’s has been at it for a couple of years now, and I hope they’ve cracked the code for remaining viable in Lents: They’re only open until 2 each day. They’re not even attempting dinner service.

Anyhow, this isn’t its Yelp page, where it is mostly appropriately revered by the neighborhood.

Ben and I have been walking down there most Sunday mornings for a while. It’s about 10 minutes from our house, so we’ll go all but the worst days, unless we’re feeling lazy and don’t want to get out of our pajamas.

Some days, we don’t say much. Other days, Ben wants to talk about World of Warcraft or something he saw on YouTube. This last Sunday, he was curious about elections and what it would be like if we had more than two major parties. “Winner takes all” was pretty easy to explain. Proportional representation was helped along by our recent Munchkin Cthulhu binge, because forming a coalition government in parliament is exactly like agreeing to gang up on a level 16 eldritch horror in exchange for a cut of the treasure.

When we get there, we’ve got a few preferred booths over on the east side of the restaurant, where it’s more isolated. Our waitress this past week is new — or new to Sundays — and she’s only seen us four or five times. She was visibly disoriented when we had to sit over on the west side in straight-backed chairs like a pair of chumps, though.

So, most of the wait-folks there know us pretty well by now. Ben still delivers his order each week like it’s going to be news to the waitresses. I’ve made more of an effort to mix it up ever since I caught a waitress starting to write my order down before I spoke it. The next week I deliberately broke my rut and there was an expression of polite surprise that I wasn’t having the omelette.

After I left the newspaper — my first job after college — I ended up in a burger joint for a while. On the days I had the lunch shift, there was a group of three mailmen who’d come in every day. They ordered the same thing every time, and one of them brought exact change every time. The first time I served him his burger I forgot to apply some discount the owner had made up for mailmen and there was a diplomatic incident. I never got the comfort of that routine because the three of them were pretty sour-faced guys. I just saw them sitting there eating their burgers in silence, maybe tipping a curt nod at the counter person on the way out, back to their routes.

I’ve certainly had routines since. Al & I were regulars at the Barracks Road Mister Donut in Charlottesville, VA on Sundays: chocolate angels to go with the Sunday Times for a long while. The fall and winter she was pregnant with Ben it was me going over to Jae’s Low Beer Price on Belmont for ice cream sandwiches, Diet 7-Up and the big box of Dots (which were fresh maybe one time out of ten, which always provoked pleased exclamations).

But I’ve got a weird thing about my routines being picked up on, too. It can feel strange and intimate, and I think about those mailmen and how little I knew about whatever they did besides eat burgers at the College Mall Road G.D. Ritzy’s in Bloomington, IN and (I hope) deliver mail, and how flattened out they seemed to me.

Sounds a little neurotic when I see it there in black and white, but there it is. Most major demons and powerful wizards are similarly particular about people knowing their true names, let alone their preferred breakfasts.

But with the exception of adjusting my ordering habits now and then to appropriately reset expectations with the wait staff at Oliver’s, I don’t mind being a regular there so much because the other half of things I think about in the process of regularing there is my childhood:

Several moves around town before I was five, a big move from Texas to Pennsylvania before kindergarten, cross-town moves and a few elementary schools, a move to Chicago, then back to Pennsylvania (way down the road from where we’d been before), then Indiana in the middle of eighth grade.

I recently did the math, and realized that this time in Oregon — since July 6, 2001 — is the longest I’ve lived in any state my entire life by a couple of years. We’ve been in this house just a few weeks over 5.5 years, and that’s the longest I’ve ever lived in a single house.

I’m not going to say moving around a lot was bad for me. I got a lot from it, especially because it was all so varied: suburban Chicago, dairy country in Pennsylvania, small-town Indiana, Texas, suburban Pittsburg. Lots of experiences — jumping up from dinner to help our host birth a calf out back in the barn! — and lots of people of all kinds.

But it was also kind of lonely. The Pennsylvania farm kids hated the accent I picked up in Chicago. The small-town Indiana kids didn’t really care about hunting much, and my hunter’s ed certification badge wasn’t really a mark of achievement to them. The Chicago kids — I guess they all went on to become John Hughes characters, but I don’t know because I only knew them for this little slice of their grade school lives. I had friends but they didn’t last, and I didn’t ever learn to expect them to.

So when Ben was getting ready to start kindergarten, we decided to make up our minds about where we’d be living, and we picked our house partly because we could see the elementary school he’d be going to from the front porch. I was pretty set on the idea that we’d be looking from that porch to that school every morning until middle school. That on Ben’s first day at middle school, he’ll be in a new place with friends from that school. And that when he starts high school, there’ll be familiar faces in the halls that first day — faces he’s known for almost as long as he can usefully remember anything.

Ben went on this Lady Gaga kick a couple of years ago. He loved her makeup and costumes, and “Born This Way” just sort of resonated with him. He got marked as a weirdo for it, and there was some trouble at school briefly. A group of mean girls started a playground “Ben’s a fag” campaign and he got pushed around. We briefly freaked out — I took six months of that kind of abuse from a bunch of farm kids in Pennsylvania in eighth grade — just five or six punches on the arm or in the gut every morning before gym for six months straight — and it sucked. We’d managed to “win” the elementary school lottery, though, so we could have picked another school to transfer him to the next year. But the thing we learned from the teacher when we talked to her about it was that Ben’s friends had all stuck up for him, and even if there was some stuff going on from a few shitty little kids, after the first shoving incident his friends had all just surrounded him and kept him safe. I thought about it some and realized transferring him to another school would just mean starting over, and maybe not making those friends he’d need before a mean girl clique over there decided he was a weirdo, too.

All of which is to say, that’s part of what we bought — that sense that the best school is the one his friends are at. I have to randomize my breakfast orders to keep from — whatever would happen if I let myself be known that way — but Ben gets to walk into a place where sometimes we hear the waitress behind the counter say “the guys are here,” and he can have his usual.

© Michael Hall, licensed under a Creative Commons Attribution-ShareAlike 3.0 United States license.