The Minitest Cookbook

I’m not a professional developer (at least not as of 2017-01-26), but I’ve always been enamored with the idea of testing. The first time I jumped into testing, I went straight for the Rspec/Cucumber stack. Rspec seemed to be the thing that all the serious developers used, and Cucumber seemed like an interesting way to write tests. I tried both. Rspec is a fine system, but it can feel overwhelming at times. There are almost too many options. Cucumber can be a good way to go, if you need to develop tests with non-developers, but I haven’t had a need for it, and using Cucumber when it’s just you isn’t necessary.

I started writing a Rails app for the first time again recently. It’s called Stocker. I definitely wanted to write a test suite for this app, as I want it to be an example of my skills for job hunting purposes, and test should help keep it from developing bugs in the future. This time around though, I thought it would be best to avoid the same pitfalls from my first forays with testing. I like the Rspec syntax, but I thought I could get most of the benefits of Rspec from Minitest::Spec and I since I’m the stakeholder, I don’t need Cucumber. I wanted to get a good grasp of what Minitest can do, so I wanted a guide. I remembered Chris Kottom’s Minitest Cheatsheet from the end of 2016 and I looked it up again and was reminded that he wrote a book called The Minitest Cookbook.

Over the course of the book, he has you add some extra gems and extensions to Minitest to add some helpful features, but I think he does a great job of how functional and how flexible Minitest is. He shows you how to use the spec syntax, how to extend Minitest’s reporting capabilities, and how to set it up to enhance Rails testing. Sure, you aren’t using vanilla Minitest, but you don’t need any of them. I also really like that you can mix and match assert-style and spec-syntax styles any time you like.

require 'minitest/autorun'

describe "Foo" do
  let(:one) {1}

  it "is cool" do
    expect(one).must_equal 1
  end

  def test_something
    assert_equal one, 1
  end
end

Save as foo.rb and run with ruby -Iminitest foo.rb and both tests pass. That’s pretty cool. I really like the Minitest reporters gem. I output the spec reporter and the HTML reports on every run. Also, minitest-rails will enable the spec syntax with Rails and the minitest-rails-capybara gem will get Capybara working. Very cool. If you haven’t given Minitest a fair shot before, check out The Minitest Cookbook.



Sed and Awk Shebangs

#!/bin/bash

sed 's/some pattern/something else/g' $*

…is bad form, in my opinion.

#!/usr/bin/sed -f

s/some pattern/something else/g

…seems so much better.

#!/bin/bash

awk '/some pattern/ { print }' $*

…is bad form, in my opinion.

#!/bin/awk -f

/some pattern/ { print } 

…seems so much better.



Hunger and Guides

There’s a lot to be said for turning the tasks in your productivity system into guides. Instead of checking OmniFocus to see if you need to wash the dishes or do the laundry, you’re better served by taking notice of the dishes or clothes that are piling up and then acting on that guide. After considering the role of guides vs. tasks, I’ve found there’s been a great weight lifted off of me in regards to task management. I used to have silly tasks popping up in my OmniFocus Dashboard every day. Things like “wash dishes”, “do laundry”, “brush teeth” and “take out the trash”. I then made them Considered Tasks for a while, with names like “Consider taking out the trash”. This was just as bad. Some things are best left to guides. Go through your task manager and see what mundane tasks can be left to guides. In OmniFocus, you can assign these tasks to a “Retired Habits” context that’s placed “On Hold”. Try living without these tasks for a few weeks and see if you’re functioning just as well without seeing them pop up flagged and screaming for your attention. If the guides are working, delete the tasks. If they aren’t maybe you need to work on building the habit a little more.

The best way I’ve found to improve the effectiveness of guides is to make the guides more visibile. An inbox or laundry basket with a lid is harder to see than an inbox or laundry basket without a lid. Lidded baskets allow us to shove things in, close the lid and not see what’s really there. It’s why we buy cabinets for books, videos and games that we don’t want to see—because we know that deep down we don’t really need all these things. Also, make the baskets smaller. A small laundry basket with no lid on it is going to fill up much faster than a bigger one, and with no lid to keep keep the mountain of dirty clothes at bay, the erupting volcano of laundry will get your attention in a much less nagging way than a due or flagged task in a task manager.

So, let’s bring this idea of guides to health. Our ancestors didn’t worry about eating breakfast, lunch and dinner. They found food when they could and they ate when they wanted. It’s our manmade workday that’s forced us into meals. Meals are like tasks. They are scheduled events that we think we have to get done. We should be thinking about hunger and meals the same way we think about guides and tasks. If we relied on our hunger to be our guide, we’d eat when we are hungry—instead of when we think we should eat. This idea is central to the Primal Blueprint. So while you’re trying to use your guides for handling household chores, try listening to your body about when it’s time to eat.



Considered: AppleScript to Wrangle Considered Tasks in OmniFocus

I wrote another cool little tool using my AppleScript library. It’s called Considered. It also handles things having to do with colons and prefixes, but specifically the Consider: prefix. If you’re unfamiliar with considered tasks, read all about them here. Instead of trying to set task names to something like “Consider reviewing” with the ing, I opted for Kourosh Dini’s prefix-style considered tasks where you just add Consider: as a prefix. It’s simpler and easier to script. Here’s the code (using my OmniFocus library, of course.)

use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
use O : script "omnifocus"
use OmniFocus : application "OmniFocus"

on run
    tell O to toggleConsider(selectedItems())
end run

on handle_string(argv)
    if argv is "set" then
        tell O to setConsider(selectedItems())
    else if argv is "clear" then
        tell O to clearConsider(selectedItems())
    end if
end handle_string

It’s a pretty nifty script that will toggle consider prefixes on and off. It’s set up to accept an argument with LaunchBar (either “set” or “clear”) to flip the considered switch one way or the other no matter what the current state.



Fixxxer: AppleScript to Set and Clear Prefixes in OmniFocus

Another nifty script for OmniFocus. It’s called Fixxxer. It does two things. If you run it with no arguments, it will remove colonized prefixes from task names. If you pass it an argument, it will add that argument as a prefix to selected tasks. It’s LaunchBar-ready. If you want to turn off the confirmation dialog, set nagMePlease to false.

use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
use O : script "omnifocus"
use OmniFocus : application "OmniFocus"
-- If you want to play it safe, set nagMePlease to true
property nagMePlease : true

on run
    if nagMePlease then
        set question to display dialog "Do you want to remove all prefixes?"
        if button returned of question is "OK" then
            removePrefixes()
        end if
    else
        removePrefixes()
    end if
end run

on handle_string(argv)
    tell O to setPrefix(selectedItems(), argv)
end handle_string

on removePrefixes()
    tell O to clearPrefixAll(selectedItems())
    display notification ¬
        "All prefixes removed." with title "Fixxxer"
end removePrefixes