Autoficiency

My Ideal GTD App

admin — Thu, 26 Jan 2012 12:55:07 +0000

I have been a long time user of Things by Cultured Code, but they have been very slow implementing a couple of features that would really enhance the way I use GTD, namely time based reminders, location based reminders, and cloud-based syncing.

So I went out looking. Producteev looked pretty good, but it is woefully underpolished. Firetask also looked promising, as did Wunderlist, but both left something to be desired. Toodledo had nearly everything except a native app. Omnifocus looks like it has all the features, but is so complicated and ugly that I don’t like it.

So I’ve come up with my list of needs, wants, and wishes for a GTD app. I don’t think it’s comprehensive, but it doesn’t seem like too much to ask–and yet there is nothing in a reasonable price range to do what I want.

So here’s my list. Take it for what it is. And if you know of something that implements all the musts, most of the wants and some of the needs… let me know.

Needs

Native Mac App (as a first class part of the solution)
iPhone App with Sync
Global Hotkey for capture that goes by default to the “Inbox”
Recurring Tasks
Easy Deferring of Tasks
A good “Focus”/”Today”/”Now” view that makes solid sense

Wants

Solid Cloud Sync
Easy Delegation of Tasks (drag, e-mail/web app notification)
Contexts / Workspaces
Projects / tags
Basic integration / support for Pomodoros
Full screen mode in Lion that takes advantage of the screen real estate to show task details, sub tasks, etc for the *current* task.
Push notifications / App badges for tasks remaining

Wishes

Defer to Location (best – switch contexts based on location automatically, some tasks context free)
Defer to Time: maybe not as important if location based worked, but being able to defer something until 9:00 pm gets it off my focus list until after my kids are in bed.
Defer until Focus section is ‘empty’: Implemented as “dependent” tasks or “next” tasks or “next tasks” for within a project. Hard to get this right.
Full on support for Pomodoro

Start a pomodoro for a given task, tag, or context
If started for a task, automatically mark the # of pomodoros taken
If started for a tag or context, still record the pomo and the tasks checked off during it
If the “interrupt” key is pressed, prompt for recording a new task in the inbox
If not resumed, mark the pomo as failed

Review Support

Reports of Pomodoros for the day/week/month
Reports of tasks completed for the day/week/context
Graph of “productivity” based on pomos completed per day

Calendar View, integrated with iCal calendars

Now, I know my list looks long to those in the GTD world, but if you look at the features, they seem simple to implement. Very simple. Omnifocus is the closest to this, but has no Pomodoro support and bad “Today” support. Producteev is actually really close, but lacks enough polish. Things is still the best task manager I’ve found for managing tasks AND getting out of the way. Has someone made this task manager I seek? If not, I assume I’m naive for thinking it is simple to do. I’m considering whipping together a webapp prototype that does what I want.

What’s your ideal GTD app? What features would you say are imperative?

Don’t Use DateTime in Rails 3

admin — Tue, 29 Nov 2011 17:44:51 +0000

Rails 3 has good TimeZone support built in, but you have to use the right Date and Time classes to get full support.

If you have this set in your application.rb

1	config.active_record.default_timezone = :local

, then you really need to use Time so that it properly identifies itself as being in the local timezone and not in UTC when passing to the database insert.

1
2
3
4
5
6
7
8

ree-1.8.7-2011.03 :001 > DateTime.parse('2011-11-27 12:00:00 +0000')
=> Sun, 27 Nov 2011 12:00:00 +0000
ree-1.8.7-2011.03 :002 > DateTime.parse('2011-11-27 12:00:00')
=> Sun, 27 Nov 2011 12:00:00 +0000
ree-1.8.7-2011.03 :003 > Time.parse('2011-11-27 12:00:00 +0000')
=> Sun Nov 27 06:00:00 -0600 2011
ree-1.8.7-2011.03 :004 > Time.parse('2011-11-27 12:00:00')
=> Sun Nov 27 12:00:00 -0600 2011

So basically, Time.parse always returns the value in the local timezone, DateTime.parse always returns the value in UTC. To get complete compatibility, always use Time.parse. Trust me, I learned the hard way :)

Code Kata #1 – Supermarket Pricing

admin — Fri, 14 Oct 2011 20:39:40 +0000

Taken from Code Kata’s by Dave Thomas

The basic premise of this Kata is asking how you would model super market pricing. What is the price of an item? What is the cost? How do you handle price-per-pound? Buy 2 get one free? What’s the value of stock? It’s interesting, and I thought I’d take the time to blog through my thought process.

I’d like to iterate over the design and see where it takes me. First task is to represent a product.

1
2
3
4
5
6
7
8
9
10
11

class Product
attr_accessor :name
attr_accessor :price
attr_accessor :quantity

def initialize(name, quantity, price)
@name = name
@quantity = quantity
@price = price
end
end

Basic enough… But the :price element can’t simply be a float… no it’s it’s own object… let’s look at that closer

1
2
3
4
5
6
7
8
9
10
11

class Price
attr_accessor :amount
attr_accessor :unit # nil, :pound, :oz, :box, etc
attr_accessor :multiple # defaults to 1, enables '3 {units} per {amount}'
attr_accessor :num_free # defaults to 0, enables 'buy {special} get 10 free!'
attr_accessor :special # defaults to nil, enables 'buy 3 get {num_free}'

def initialize(params={})
params.each {|p,v| send("#{p}=", v)}
end
end

At first, this looks overly complicated, but it allows us to store the exact input and calculate off of that. We never want to store $0.3333333 / orange when the user enters 3 for $1–that would make our rounding happens at the EARLIEST possible moment, rather than the latest. We also want to enable flexible definitions of what costs the amount specified, thus you could say 0.99/pound, etc. There should be some units that are known, and others that are simply treated the same a nil (or /each). I’m not thrilled with the num_free or special yet… maybe those will factor themselves differently as we go forward.

So what can we represent here… let’s set up some examples:

1
2
3
4

apple = Product.new "apples", 200, Price.new(:amount => 1.99, :unit => :pound)
soup = Product.new "soup", 100, Price.new(:amount => 1.00, :multiple => 3)
oreos = Product.new "oreos", 50, Price.new(:special => 4, :num_free => 1, :amount => 2.98)
bread = Product.new "bread", 25, Price.new(:amount => 1.69)

There’s a couple things about these that I want to refactor as I’m going… I want the price to be a bit more readable… like:

1
2
3
4

apple = Product.new 200, "apple", :at => 1.99, :per => :pound
soup = Product.new 100, "chicken noodle soup", :at => 1.00, :for => 3
oreos = Product.new 50, "oreos", :at => 2.98, :buy => 4, :get => 1
bread = Product.new 25, "bread", :at => 1.69, :per => :loaf

That’s what I’d like. It reads straight across. You can represent most things here… so we’ll refactor “Price” and “Product” to look like that:

1
2
3
4
5
6
7
8
9
10
11

class Product
attr_accessor :name
attr_accessor :price
attr_accessor :quantity

def initialize(quantity, name, price)
@name = name
@quantity = quantity
@price = price.is_a?(Hash) ? Price.new(price) : price
end
end

1
2
3
4
5
6
7
8
9
10
11

class Price
attr_accessor :at
attr_accessor :per # nil, :pound, :oz, :box, etc
attr_accessor :for # defaults to 1, enables '{for} {per} per {at}'
attr_accessor :get # defaults to 0, enables 'buy {buy} get {get} free!'
attr_accessor :buy # defaults to nil, enables 'buy {buy} get {get}'

def initialize(params={})
params.each {|p,v| send("#{p}=", v)}
end
end

There! Much better! Now how about being able to call “cost” for a specific quantity of something. Should it be on the “product” or the “price”? They are closely related, but the product is what needs the call, most likely delegating some of the calculation to the price. Let’s set up “Price.of(n)” and “Product.buy!(n)” Product.buy!(n) will actually decrease the quantity we have in stock.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class Price
# ...
def of(quantity, unit=:each)
quantity = convert(quantity, unit)
(quantity / for) * @at
end
end

class Product
def buy!(n)
@quantity -= n
price.of(n)
end
end

This continues to be tougher and tougher, but I’m getting the idea. This would be great for a TDD driven exercise. I’d like to do the timed Kata like Corey Heines does — to music even :)

Enough for this Kata. Time to move on to Kata #2.

Scary Complicated or Richly Awesome?

admin — Tue, 27 Sep 2011 14:44:16 +0000

When you look at a new piece of data, most of our initial reaction is in relation to the complexity of that data. Usually this scares me, but after you get to know the data, the more the merrier! What was scary becomes rich and awesome.

How do we move from scary complicated to richly awesome? Comprehension, comprehension, comprehension. And what is the best way to grok something like that? Dive deep into the guts of the code or the task and find out why the data is there and what it does. Why was it modeled that way? In what way could it have been modeled different? Do I have the power to change it? Is it a good thing to change it? Do I understand the system fully enough to see the richness of the data and of the model itself?

In the spirit of “Practice, Practice, Practice” — pick an open source project, look at the model, figure out what all of it does and how you would do it differently, more simply, more robustly, with better error handling, with fewer models. Grok and regrok. Get used to the FEELING of comprehension.

Feedback Loops and Estimation -or- What Rubik’s Cubes Taught Me About Making Software

admin — Mon, 04 Apr 2011 17:35:49 +0000

Estimation is hard. It may not be listed as one of the top two problems in computer science, but it’s at least a close third. Over the years I’ve gotten to try all sorts of methodologies for estimating. Waterfall, Agile, Points, Stories, Requirements, Features, Epics, Pomodoros, Billable hours… you can go on forever with the Jargon of Management, trying to get information from a developer about how much longer The Client has to wait until The Feature is finished.

Rubik’s Cubes

About 4 years ago I started a job where a coworker was an avid Rubik’s cube solver. I learned the steps and began competing with him to see who could solve a cube the fastest. Eventually, my top time ended up around a minute and thirty seconds. There are guys who can do it much faster–but I’m interested in consistency and improved speed. Sometimes I can solve very quickly because some steps can be skipped (i.e. they are done for you) or because I’m using a very good cube, but in general, I can solve a cube in 1:30 – 3:00.

But I don’t do it blindfolded.

Blindfolded

The world record for the fastest solve is just under 10 seconds, but the world record for the fastest blindfold solve (i.e. from the time you pick it up, look it over, and then blindfold yourself to begin solving) is over a minute and a half–10 times as long. The reason is simple–feedback. Immediate and quick feedback allow you to take shortcuts and spend less time worrying about the next 200 moves and just worry about the next step or two.

So why do we still tend toward “blindfolded” approaches in software?

Waterfall vs. a Feedback loop

Call it Agile, call it scrum, call it feedback–it doesn’t matter. What makes a team think they’re going to deliver better because they took the time to figure out all the steps, when you don’t know exactly how one step will affect the next? It’s foolish when you consider it, but still, so many teams do it. Even the supposed “agile” teams end up blindfolding releases and then trying to ‘feedback’ the sprints. That’s not to say there should be no planning, but getting customer and developer feedback is crucial to accurate and fast solutions to problems.

What should we be doing instead? In Rubik’s Cube solutions, you typically identify the next ‘step’ and iterate over it, examining the result and deciding the following step at that point. You might be able to ‘blindfold’ for each step, but you’d still need to look at the end to figure out where to go next. I think a similar paradigm works in software building. Identify the key feature, and let the developer work on it, deploy it, and get feedback. Iterate on it again if it’s not quite right. If it is, then move along to the next step or feature.

Analogy Breakdown

Where does this analogy break down? Architectural changes. You can’t make sweeping changes underneath the system without a good deal of planning and “blindfolding” where you step through, unsure of the effect on the system because you can’t actually evaluate it. There are times this must occur–but as developers, we probably tend toward a desire to rearchitect more often than we should. Always consider what the right solution is and evaluate the cost of technical debt vs. the potential cost of an underlying change that could have pervasive and unknown effects. Sometimes it is necessary, but generally it’s not. YAGNI is your friend.

Takeaway

The tighter the feedback loop, the more accurate and more quickly you’re able to deliver a solution, whether in Rubik’s world or in the Software space. Focus on tight loops with customer feedback and developer feedback and watch your estimation troubles diminish.

Migrating Serialized Columns in Rails

admin — Thu, 03 Mar 2011 21:09:21 +0000

I recently switched a serialized column in Rails from one type (Hash) to another (OpenStruct) and ran into a little problem when I tried to migrate, namely, that loading the model threw a SerializationTypeMismatch error. Hmm… how am I going to get at the base YAML and translate all of these without being brittle?

The answer is to copy the column, nullify it, and the load the raw YAML manually:

1
2
3
4
5
6
7
8

add_column :my_table, :serialized_column_raw, :text
MyTable.update_all("serialized_column_raw = serialized_column")
MyTable.update_all("serialized_column = NULL")
MyTable.all.each do |mt|
mt.serialized_column = OpenStruct.new(YAML::load(mt[:serialized_column_raw]))
mt.save!
end
remove_column :my_table, :serialized_column_raw

How to Stay At Inbox Zero

admin — Tue, 04 Jan 2011 21:57:56 +0000

I saw a link recently on how to get to the ever elusive “Inbox Zero” and it seemed kinda lame–label everything “oldinbox” and archive everything in Gmail. Maybe that’s the only way to do it when you have 10K+ e-mails in your inbox, but it seems like the best way is to never get there to begin with.

Personally, I haven’t had more than 50 e-mail in my inbox at any given time in over 2 years. I ruthlessly archive and delete items and as soon as I’ve processed something into an action for “Things” I get it out of my inbox. For e-mails I just need to look at, reference or respond to, I use the stars feature, but I have only 8 starred items right now. I think at some point I had nearly 20… that’s about the max.

There are 3 very simple things you can do to stay at Inbox Zero:

Use “Multiple Inboxes” – to keep things in front of you, use multiple inboxes (it’s a Gmail Labs feature) and make your own version of the priority inbox.
Use a catch-all and your own domain – I have a catch-all address getting checked by Gmail. I give out e-mail addresses to businesses like “amazon@my.domain.com” that way and have all of the mail that comes in on that domain marked with the label “bulk” — and I have a “bulk” inbox using “Multiple Inboxes”
Add “Send and Archive” in labs – Now, everytime you respond to somebody, send and archive, don’t just send. You’re done. Never worry about it again.

Okay, now you know how to keep a simple and clean inbox. Go forth and do likewise.

The Importance Of Speed in Automation

admin — Fri, 03 Dec 2010 15:35:46 +0000

We are impatient people. This is something that we must work to fix in order to grow as individuals, but it is something that serves the automator well–or can be our downfall.

Joel Splosky wrote on the “Joel Test” that having anything less than the best tools money can buy is rediculous for a development team. The reasoning is this: If you’re paying developers what they are worth, then they are expensive, and wasting their time while they’re reading the Onion waiting for a build will kill your productivity–and your bottom line.

The same goes now for Test Driven Development. Having a great test suite is nearly essential, and anything more than a trivial application will have difficult and long running tests, but these tests must be managed well and there must be a way for a developer to quickly run through a cross section of the test suite as a sanity check before checking in. If your tests take 1 minute to run, then the developer is 6 times less likely to run them than if they take 10 seconds to run. If your tests take 30 minutes to run, then the developer is 60 times less likely to run them than if they take 30 seconds. Every additional test is great for coverage, but if it adds time, there is a point of diminishing returns.

Tagged tests are a must, and a solid set of fast tests that touch much of the code base is essential. It must also be easy to run individual tests–anything that hampers this reduces the liklihood of continued test driven development. Testing becomes a chore again and running the tests becomes an excuse for swordfighting in the hall.

So take the time to improve the speed of anything you wait on as developers–and reap the benefits tenfold.

Stop Googling // RailsTips by John Nunemaker

admin — Thu, 14 Oct 2010 15:33:12 +0000

Yesterday, one of my inter-web buddies IM’d me and asked if I had used Typhoeus before. I said yes, so he asked me if it was possible to follow redirects using it. He said he google’d it and nothing turned up.

I sharply responded, “LOOK AT THE CODE!”. We had some banter back and forth and a few minutes later he was automatically following redirects. It seems these days that developers often think if something does not turn up in a google search, it does not exist.

via Stop Googling // RailsTips by John Nunemaker.

Things and Pomodoro

admin — Tue, 31 Aug 2010 14:11:29 +0000

For the last two years, I’ve been a loose GTD-er, using Cultured Code’s “Things” to dump my brain and keep track of tasks to do. I never got into the “project” side of GTD–planning out every project and asking why… I’m sure it has value, but that was never the problem I was trying to solve with GTD.

I just wanted to keep up with all the stuff everyone wanted me to do and I was tired of having things so easily slip through the cracks.

Well, 2+ years later and I’ve gotten very used to capturing, scheduling, prioritizing and crossing off items from my master list that isn’t in my brain. Things has been great for this, if only for the “Today” feature. For those of you looking for a great GTD app, I’d still recommend Things even though it doesn’t have OTA sync yet and there are many performance issues. It’s a simple app that does a simple thing.

Now, though, I’ve discovered that I have a problem getting motivated to do items on my list. Motivation is always difficult, but I tend to be paralyzed when I’m not sure how I will complete something. It makes me fail to even get started. Enter the Pomodoro Technique. I read this over the weekend and it made a huge difference on the first day. If you struggle with motivation and procrastination, this is the technique for you.

I’ve got 2 years worth of data in “Things” and my Pomodoro Technique is pretty new, so my first big question was how to use them TOGETHER. While this is neither pure GTD nor pure Pomodoro, I think I already have a great way to use Things better than I ever have and to stay motivated. If you’d like to try it, read on.

If you haven’t already, go get familiar with GTD and Pomodoro. You can read the full PDF about Pomodoro for free.

Once you’re familiar, go download Focus Booster (or one of many other pomodoro timer apps out there). Then fire up “Things” and set up the following tags:

Now, set up a recurring task daily to “Prep for day” with a “1p” tag – 1 pomodoro. You can use this first pomodoro to parse through everything in your inboxes and Today list in Things. Estimate using the number keys… and if you end up estimating 8 or more, break it up. Use the c or ‘combine’ tag for tasks that are smaller than one pomodoro and could be combined together.

Now, prioritize the tasks in order, and start working on your first pomodoro by winding up Focus Booster and plowing through. When you’re done with the pomodoro, put an X in the notes section of the task you worked on. Check it off if you’ve finished it.

At the end of the day, go review your tasks in the log book and ask how you can do better.

100% software Pomodoro + GTD — I guarantee you can get lots done!