Cool things at the Melbourne Maker Faire

I’m at the Melbourne Maker Faire and a few cool things have caught my eye:

1. the FreeRTOS for Arduino — and  @fei_li_pu has persuaded me to take another look at Eclipse as an AVR development environment
2. Cool wooden journal covers from the Beehive
3. the MHV Arduino board
4. Up! 3D Printer — shame about the price and lack of Linux support though
5. @legopoerty
6. the Range of stuff from Freetronics. I hope they support the Raspberry Pi when it comes out

There was also lots of other cool things, steam punks, crafters, Smart Energy Group and so on. If you missed it hard luck.

2011 in review

The WordPress.com stats helper monkeys prepared a 2011 annual report for this blog.

Here’s an excerpt:

The concert hall at the Syndey Opera House holds 2,700 people. This blog was viewed about 29,000 times in 2011. If it were a concert at Sydney Opera House, it would take about 11 sold-out performances for that many people to see it.

Click here to see the complete report.

Top Tip: Running Perl Regex Coach on OS/X

If you’ve used the excellent Regex Coach for Perl programmers on Windows but have been dissapointed that the current version does not run on Mac OS/X, fear not. You can build Wine and then it runs well.

1. Install HomeBrew
2. Run the command brew install --use-gcc wine
3. Download the Regex Coach installer
4. Run the command wine regex-coach.exe to install
5. To run Regex Coach run the command wine .wine/drive_c/Program\ Files/The\ Regex\ Coach/The\ Regex\ Coach.exe

Setting up test printing on a Mac using CUPS-PDF

In my new job at PaperCut Software I do a lot more testing of print jobs and I’ve found the following useful for saving trees. Note that this actually creates a PDF printer device on the Mac, this is different the PDF option displayed on the standard OS/X print dialogue.

1. Download and install the Mac CUPS-PDF package
2. Create a new printer, as a generic colour postscript device
3. You can now create print jobs from the command line as any user with the following su - testuser -c 'lpr -P cups_pdf /etc/group'
4. You can check the output in /Users/Shared/CUPS-PDF

Application or IT Environments Management

Note from Alec: I’ve copied this article here in case the original version disappears.

Author: Valentine

Application or IT Environments Management service will fall under Application Management as defined in ITIL2 (operational guidance) because it contributes to improving the overall quality of IT Software development and support through the lifecycle. Application Environments Management set encompasses a set of best practices proposed to provide an effective, end to end management service for test software platforms or development environments. The software test bed or development environment could consist of a client server application, Relational Database Management System (RDBMS), middleware, interfaces, daemons, customised processes (written in any software programming language), FTP utilities etc.

Functional test phases such as Unit, Integration, Acceptance, all manner of performance or non functional testing and development phases all require Application Environments.

The primary clients of an Application Environments Management service are Software Project and Test teams.

The service will cater for the following;

• Manage the creation, build, upgrade and support for all test and development Application Environments.
• Clearly defining auditable processes of allocating application environments, multiple bookings or shared usage, code upgrades, service level agreement, support, decommissioning and re-allocation.
• Manage data refreshes, collating test data and assist in the anonimising of production or other sensitive data if necessary.
• Supply, provision and manage all Application Environment Requirements from the Project and Test teams all through the software development cycle of a project.
• Assist the Project in establishing their application environment requirements, provide expert knowledge on the APPLICATION environment’s set up, connectivity and serve as a guide to the projects in using the application environment in the most efficient manner.
• Review and contribute to the Project Initiation Document (PID) ensuring that the IT Environments Management function and its deliverables are clearly defined and captured.
• Create and maintain project plans to assist in managing all activities required to successfully carry out major code upgrades to all application environments.
• Provide reports on usage/utilisation, availability, forward planning and schedules.

Application Environments Management is clearly a new and emerging area which has arisen due to the following reasons:

• The increased Application Environment requirements for many companies who have several software projects running at any one time.
• The increased levels of interfacing and connectivity between several systems in most organisations also known as spaghetti. For example in some companies more than thirty systems are interfaced or connected with each other exchanging files and data flows etc and has meant that any changes to one system most times could require a change to many others and then require large numbers of test and development application environments.
• Increased awareness and more commitment to carrying out rigorous software testing especially with more companies opting to use the Prince 2 methodology and ITIL Framework

A typical Application Environments Management tool should be able to provide the following services: environments bookings and allocation, manage multiple bookings and re-curring bookings. Provide reporting on usage, availability, interconnectivity or interfacing environments, utilisation and conflict reporting etc. It must also serve as a repository of all information on an Application Environment to include Host Server names, Hardware Type, Operating System, IP Address and Interfaces if any.

The ideal background for an Application Environments Management personnel could be Software Development, Application or Technical Support, Infrastructure Project Management, Configuration and Release Management etc but must be

exposed to at least the ITIL Framework, Client – Server development, System Architecture/Design, Networks, TCP/IP and Messaging systems etc.

Terminologies defined & explained:

Application Environment – A single test bed or development platform instance of a software application or system that can also be used for all manner of functional and non functional testing or could be the production instance (production environment). It could also be large, medium or small which normally refers to the size of data the RDBMS will be holding depending on the type of testing it is required for.

Integrated Application environments (also known as stripes): More than one application environment connected to each other also communicating with each other and exchanging files and data flows. Connections could be via Microsoft ODBC, via FTP, TCP/IP, daemons, middleware, defined interfaces and database links etc.

Anonimising of data

Anonimising of data refers to the manipulation or transformation of production data held in the RDBMS such as Oracle, SQL Server, Sybase, Microsoft Access, DB2 etc to be used in a test or development Application Environment ensuring that for example real names, addresses, date of birth, bank account details and other sensitive information or data is transformed to dummy data.

The data is transformed whilst still maintaining its defining characteristics in a Relational Database Management System table such as character length (Char 25 or Varchar 50) etc to ensure its usage in testing or development is not compromised and that the integrity is maintained. For example a valid name such as John Smith defined as Char 10 will now be updated in the table to become possibly a unique character string XXXXXXYYYY (comprising of ten characters including the space between John and Smith).

Pipe cleaning

Pipe cleaning caters for the all the activities required to be carried out before a test or development environment is handed over to the Test or Project team and includes disk clear down, archiving and purging logs, importing test data, killing off rogue processes, resetting passwords, changing environment settings, end to end connectivity or integration tests to make sure everything is working okay.

Depending on the complexity of the system a checklist of activities may be required and ticked off capturing all the checks and tests that have been completed on an environment or an integrated suite of environments prior to its hand over to a Project or Test team.

Smoke Test

A smoke test describes an initial end to end test of all the integrated or even stand alone environments very possibly using dummy data and carried out by the support teams who have created or built the environment or by the test team when the environment is handed over.

Article Source: http://www.articlesbase.com/information-technology-articles/application-or-it-environments-management-2884860.html

About the Author

• Freelance IT Environments Manager & Technical Project Manager

• Previously Global FX technology manager at Citibank International

• Worked in several sectors to include energy, utilities, Investment banking, railway transport, software development, healthcare, manufacturing, research, insurance and the gaming sectors.

Have a *nix sh script put itself into the background

In the Unix Bourne style shell languages (e.g. sh, bash, ksh etc) you can put a long running command (or another script) into the background so that control returns to the user. The original idea is that you can perform other work whilst the background process continues. This is achieved by adding a &, for example $ myVeryLongRunningCommand and options >/tmp/myOutput &.

It would be nice to be able to have scripts place themselves in the background, when appropriate, without the user having to worry about and I assumed there would be a “shell’ish” way to do that — however I couldn’t find anything so I knocked something up in a hurry. I put it here for future generations and in the hope that improvements will be suggested.

#! /bin/sh

if [[ "$_myBackGround" != "_backGroundFlag" ]]; then
 nohup /bin/sh -c "_myBackGround=_backGroundFlag; export _myBackGround;$0 $*" > /tmp/$0.$$.stdout 2> /tmp/$0.$$.stderr &
 echo $0 passed to background with arguments "$*". NB stderr is /tmp/$0.$$.stderr and stdout is /tmp/$0.$$.stdout
 exit
fi

#  Your script goes here e.g.

echo hello: My arguments are $0 $*

echo Hello -- this is an error >&2

Setting up a Perl development environment

Here are my suggestions on how to set up your Perl development environment:

(NB If you are a Perl novice then start here)

1. Install a copy of Perl
   1. Windows: Strawberry Perl
   2. UNIX developer with a Windows desktop? Use Cygwin
   3. Linux: Your distro should have Perl. See here for some suggestions on installing CPAN modules
   4. UNIX: I built my own and manually installed the modules. Easier than it sounds.
   5. OS/X: Comes with Perl
2. Download a copy of the Perl Documentation and create a convenient shortcut
3. Configure your favourite editor for Perl. There are some guidelines on Perl.net
4. A decent version control tool (I use Git)
5. Install PerlCritic, Perltidy, Devel::REPL, Module::Starter::PBP, GetOpt::Long and RegEx Coach
6. Depending on the work you do consider the following modules as part of your ‘base’ kit:
   1. DBI::SQLite for DB test mocking (NB Depending on your testing needs you will also need other Test modules)
   2. Moose for OO programming
   3. See the list at Perl.Net
7. Run “perl -MModule::Starter::PBP=setup” and accept the defaults
8. Modify the templates used by your editor and Module::Starter so that .pl have the following additional code:
   

   	# Main program Entry point
   	sub main {
   
   	use Getopt::Long qw(GetOptionsFromArray);
   	# TODO Add options variables here
   	# GetOptionsFromArray(\@_,
   	#TODO Add option processing here
   	#);
   
   	#TODO Add application code here
   	}
   
   	return main(@ARGV)  unless caller();
   	1; # So we can treat this as a module for test purposes
   
   

Use:

• Have the local Perl docs open in your browser — there is a build in search engine
• Test perl assumptions about how Perl will behave by using Regex Coach and re.pl (re.pl runs from a terminal)
• Write your script (and modules) as a set of subroutines that you can test using  Test::More and it’s siblings. You can test script subroutines by writing test scripts in the normal fashion and then running prove with the command line options “-I ./lib -I .“
• Get good with your editor
• Use the branching feature of your version control tool to manage features (you are using Git right?)
• Don’t be afraid to refactor and fix stuff as you discover issues with previously written code

Caveats: This is based on my personal experience and preferences. Use it as a starting point only. I currently use Perl on Cygwin, Solaris and Linux with the Vim or vi editor. I tend to hack data munching scripts and I don’t use OO programming. YMMV.

My presentation on software process improvement

I recently gave a new presentation on Improving Software Processes at OSDC 2010 in Melbourne, AU

My 43 Folder Tickler File

Tickler File – 43FoldersWiki

In the parlance of Getting Things Done, a Tickler File consists of a series of 43 file folders: 12 monthly and 31 daily folders. Items are filed in a folder corresponding to when the item will need to be handled, thus reminding or “tickling” the user about it. These items might be action reminders, bills, receipts, reports, letters, or any number of other things.

I’ve been wanting a 43-folder tickler file for some time, however hunting in the stationary stores was proving fruitless until I discovered that you can buy dividers printed with 1-31 and Jan-Dec. With a cheap A4 binder, some clear plastic pockets and a pad of PostIt notes I have what feels like a very practical tickler file.

Setup: (assume today is the 5/Oct and we will not be using the tickler for today’s items)

1. Throw away the cover index sheets on both sets of dividers
2. Take the month dividers and place Jan-Sept behind Oct-Dec (so they are in the sequence O-N-D-J-F-M-A-M-J-J-A-S)
3. Place the month dividers in the folder
4. Take the 1-31 dividers and remove 1-4.
5. Place 5-31 in the binder, in front of October
6. Place 1-4  between October and November. The dividers are now in the sequence 5-31-O-1-4-N-J-F-M-A-M-J-J-A-S
7. Add the empty pockets

Daily use (using 6/Oct as an example):

1. Open to today by placing  finger on number 6 and opening. Now divider with 6 is on right hand side and back of the divider for 5 is on left. This is today’s space. Process an items that need to go into the action list, calendar etc.
2. Now process in-boxes etc. Suppose we locate an item that requires action on 10/Oct: Write a PostIt note (add today’s date) and stick onto back of divider for 9/Oct so that when we open the 10th it will be seen. Is there a piece of paper instead? Use a clear pocket to place it in the correct location.
3. Place ATM slips, Credit card slips etc into the pocket for the following Sunday weekly review
4. Flip back to the 5th (so the 5th appears on the right, back of the 4th on the left). Process any items.
5. Remove divider for 4th and place behind divider for 3rd. Place pocket in back of binder.

Weekly review:

1. Process as daily and additional review processing (for transaction slips, incubation decisions, project review etc)
2. Add pocket and possibly a marker to date for next review ready to receive transaction slips and other material for weekly review

I assume processing for end of month is obvious?

This format is actually quite compact and can even be put in the suitcase when travelling

Powered by ScribeFire.

Using the Khan Academy effectively

The Khan Academy is a great resource for learning maths and science. There are a few tricks when you start using the site and here are the things I’ve discovered over the last couple of weeks using the site with my daughter.

OSDC AU 2010: Get your papers in!

Updated 12/Oct/2010 — This proposal has been accepted so I hope to see you at OSDC 2010

 

The request for papers is up at The Open Source Developers Conference AU so get your ideas in. Here is my proposal for this year

Handy Hack: Pass podcasts from Liferea to Rhythmbox

I’ve started using a plain RSS reader (Liferea) to subscribe to podcasts. It’s nice to have my feeds in one interface. I’ve written s small script to hand the RSS enclosures to Rhythmbox (just supply the name of the script when prompted by Liferea)

#!/bin/sh

for i in "$@" ; do
	if test -f $i ; then
		/usr/bin/rhythmbox-client  --play-uri=file://$(cd $(dirname $i) ;  ls -1 $(pwd)/$(basename $i))
	else
		/usr/bin/rhythmbox-client  --play-uri=$i
	fi
done

Suggestions for improvement welcome

Good habits are worth cultivating

Twitter / Amanda Palmer: “Habit is the death of vis …

“Habit is the death of vision.” – Earon Davis

A short sound “bite” that is actually less useful than it looks. It should say something a little less pithy like “Poor habits can be the death of many valuable resources like time, energy and growth. Uncritical, habitual, thinking is the death of vision”. However the value of cultivating good habits has been know for millennia

“We are what we repeatedly do. Excellence then, is not an act, but a habit.” – Aristotle

So the trick is adopt good habits and unlearn the bad ones.

How to uncover bad habits:

1. Try and be conscious of what you do at all time
2. Ask the people around you (family, close colleagues, friends)
3. Keep a time log
4. Film yourself using your PC with a webcam
5. Review your day and consider what could have been better (the rule of threes — note three things that were good and three things that need to be improved)

What are some examples of bad habits:

1. Procrastination
2. Snacking on junk food
3. Worrying about other peoples opinions and using what you guessed they thought to be beat yourself up
4. Thinking that your state of mind is dependent on others peoples’ actions instead of it being your responsibility
5. Being critical of other people and concerned with what they do when it has no direct affect on you
6. Dwelling on missed opportunities and thinking “if only….”
7. Picking your nose, not covering your mouth when you cough etc.
8. Worrying about things without being able to use the thoughts to improve the outcome

Here some some suggestions for good habits:

1. Review your habits and look for improvements
2. Get enough sleep
3. Get up early enough to make full use of the day
4. Know what you need to do and get it done (people write books on that, I used their ideas and wrote a post)
5. Love and like as many people as you can
6. Shower daily, clean your teeth and wear clean clothes
7. Set yourself goals to learn or experience new things
8. Help others as much as you can
9. Ask for help if you need it
10. Smile and be courteous – remember most things that people do which annoy you are mistakes or bad habits, not deliberate attempts to upset you, you are not that important.
11. Plan and think things through, then don’t dwell on them in a negative spiral of worry
12. Look after yourself

How to unlearn bad habits:

I struggle with this, as do most people, and I’m not a psychologist so the advice is a bit mundane

1. Elastic band on the wrist – ping yourself when you catch yourself doing it
2. Ask friends to remind if they see you doing something
3. Substitute. e.g. carry fruit and veg to eat instead of buying chocolate
4. Try and make the habit redundant. e.g. Plan projects so that you feel in control and can stop worrying about them
5. Remove triggers. If certain places or activities trigger a bad habit then try and avoid them
6. Give yourself some credit and don’t do it all at once
7. Try and look at the root cause when you catch yourself. e.g. are you procrastinating because you think you won’t succeed? Are you not planning because your system is too complicated to use?

Finally
Use tools and techniques that support your good habits e.g. mind mapping tools to help you brainstorm improvements. Make sure they work for you.

Powered by ScribeFire.

Starting study for RHCE

I’ve mentioned a couple of time that I planned to study for my RedHat Certified Engineer qualification. As I’ve now cleared the decks a bit I been able to start the process. So far I have:

• Bought the book
  RHCE Red Hat Certified Engineer Linux Study Guide (Exam RH302) : McGraw-Hill Professional Online Book Store
• Set up a CentOS (a RedHat Enterprise Linux compatible distro) instance on my laptop using VirtualBox

More Notes to follow

Using Git DVC in conjuntion with a legacy SCM tool

Often developers get a limited choice on the Version Control (VC) or Software Configuration management tool they have to use when working on a project. However even when the Git (the Distributed Version Control tool) does not interface with the project tool there is value in using Git for a personal workflow. This can work as follows.

1. Fetch a copy of the working code needed to make your change
2. Initialise a new Git repo in your working copy and add the code
3. Now checkout a new git branch for your work
4. hack hack hack test test….
5. Commit
6. Switch to master branch
7. Fetch from the project tool again.
8. Add changes and commit
9. Review differences, rebase or merge as required.
10. Verify project tool still at same state from step 7
11. Upload/ check in changes to project tool. You can use the output from git log as the basis of your commit message for the legacy tool

Rinse and repeat

GSD and Pomodoro technique hacked on Paper

Updated June 2011.

For some time I’ve using a paper journal to follow the GSD workflow. I’ve actually been using a thick, 300 page, Miquelrius journal, but I’m finding it too bulky and the extra pages means it lasts long enough for the binding to start to fail so I’ll be going back to Moleskine style when the current book is finished. I’ve also tried Piccadilly notebooks which seem very similar to Moleskine and a lot cheaper, however both of mine have split down the spine. Recently I’ve also upgraded my workflow to include:

• Pomodoro technique to help me focus during the day in getting my longer actions completed
• Inbox Zero so I spend less time on email

Which have both improved things for me, but I need to improve my weekly review and project planning so I’ve been looking at moving up the GTD food chain to something a little more complete. After noodling with some UML diagrams I figure it’s pretty simple to fix, so this is my new (evolved) plan going forward (none of these ideas are very original).

1. Keep doing the GSD daily routine. (Turn to a new page, move the bookmark ribbon, date it, write down a list and work the list). Add the number of estimated Pomodoros to tasks to stop you overcommitting yourself
2. In the same space keep using pages for notes, GTD inbox, Pomodoros and project planning as needed
3. From the back of the book (turn to landscape so I have longer lines) write down actions. This is the GSD master list, but with more structure. A pink tab marks the page with the oldest active action. My column headings were inspired by mGTD. (NA/Competed, Description, Context/Agenda/Waiting, Project, Estimated Pomodoros). My coding for the NA/Completed field is as follows:
   1. Blank — task has incomplete dependencies
   2. Box — task is next action
   3. Tick — complete
4. Each time a project plan is created (as part of a Pomordoro usually) mark the project plan with a green tag. When the project is no longer active remove the tag
5. If a page has notes that might be needed in future fold down a corner so it’s quicker to skim to ‘important’ notes.
6. During the weekly review re-visit the previous weeks pages for incomplete actions, etc. Tick pages in top left when reviewed. Visit project tags to review each project
7. Use dated pages for X-ref links

Note that my approach to Pomodoro is deliberately simplistic so I keep limited notes on each one. As long as I know what my next Pomodoro is, have enough information to keep my day useful and can stay focused that’s good enough.

I’ve been using  a mind map to refine my ideas

Getting Pomodoros Done Mind Map

Oh Dear, not a great welcome back

Customer service in Australia « Alec the Geek

Australian customer service is generally pretty poor.

After writing a piece a few years showing some great examples of AU customer service I had a great example tonight of how NOT to treat customers on the Melbourne Skybus. It was the first time I had used the service and after the showing tonight I hope the last.

I had purchased my return ticket a couple of weeks ago (being concerned about the time it would take to queue up yesterday morning on my way to Sydney). The net result was that on my outward journey the ticket print had become worn (but was still legible) and this meant the driver had to punch the ticket manually and then return it. No problem so far. However tonight when I returned the driver refused to accept the ticket as it had two hole punches in it and so had supposedly been already used. My attempt to explain that this was not the case as I had only travelled up the day previously was greeted with disbelief and he started hectoring me in a loud voice. I asked him to stop shouting which only made matters worse. He eventually referred me to the ticket booth for assistance who were no help at all.

I’m guessing the first bus driver had decided that the slightly worn appearance of my ticket (it had been nestled in my wallet for two weeks) meant he was justified in clipping it for both inward and outward journeys without the courtesy of mentioning it to me!

I was forced to buy another ticket (A$16 for a 20min bus ride), was left feeling upset and embarrassed (as of course a large number of people had been able to enjoy the spectacle of me being harangued in the front of the bus).

I hope visitors to Melbourne don’t often get treated to such service

Build Audit and Processes: A line of sight from DEV to PROD

I’m presenting at the Devops Down Under conference in May 2010

…a conference about advancing our processes & methodologies, building better tools, and improving communication between developers and sysadmins.

Here is the abstract for my presentation in case it tempts anyone to attend…

Both agile and waterfall approaches to software delivery are a way to translate business needs into production features. Being able to trace that path is often crucial to affective delivery (and sometimes passing critical compliance regulations). Frequently the activity of software building breaks these important traceability links because of poor process and technology.

This presentation briefly examines these problems and looks at various approaches to overcoming them. An emphasis is placed on using processes and version control tool to provide a) Useful information and b) Audit trails of individual builds. A simple, illustrative, example using the Git DVCS is demonstrated.

Say hello if you are coming along.

Handy Hack: Calculating Git SHA1 on files without Git installed

If you are not a Git geek this will be of limited interest and I suggest you go and surf whatever inappropriate material uses up your bandwidth.

Updated after tips from Randal Schwartz and Charles Bailey

Still here? OK. As you will know every file stored in a Git repo is identified by a SHA1 hexadecimal string (as explained in the Pro Git book, it’s the hash of the concatenation of the  file contents and a Git specific header). You can calculate the Git SHA1 of any file with the command

git hash-object $file

assuming you have Git installed

If you do not have access to Git, but do have access to a UNIX style shell or Perl you have a couple of options (the Pro Git book also shows a Ruby solution and Stackoverflow has examples in Python and #F))

On Cygwin or Linux

(printf  "blob %s\00" $(wc -c < $file);cat $file)|sha1sum -b | cut -d " " -f 1

On Solaris

(printf  "blob %s\00" $(wc -c < $file);cat $file)|digest -a sha1 | cut -d " " -f 1

In Perl

# See also Git::PurePerl at http://search.cpan.org/dist/Git-PurePerl/

use strict;
use warnings;
use Digest::SHA1;

my @input = <>;

my $content = join("", @input);

my $git_blob = 'blob' . ' ' . length($content) . "\0" . $content;

my $sha1 = Digest::SHA1->new();

$sha1->add($git_blob);

print $sha1->hexdigest();

Using TaskCoach for GTD lists

I posted recently about using the TaskCoach list manager to support the Pomodoro Technique for actually doing work. Of course Pomodoro does not address the issue of task identification and organisation — so I promised a post on using TaskCoach and Getting Things Done (GTD) as  GTD and Pomodoro complement each other nicely.

Setup:

1. Install TaskCoach
2. Create Taskcoach categories that reflect the various GTD categories, i.e
   • Next Action ( I call it “.Next Action” so it sorts to the top of the list)
   • Deferred
   • Someday/Maybe
   • Waiting
3. Under Next Action create sub categories to represent your contexts. e.g.
   • “.Next Action/Errand”
   • “.Next Action/Web”
   • “.Next Action/Laptop”
   • “.Next Action/Telephone” etc…
4. Create a sub category called “.Next Action/_Agenda” (use underscore so that it sorts at the end of the next action list, alternatively make Agenda a top level category). Under that create categories for the people in your life e.g.
   • “.Next Action/_Agenda/Wife”
   • “.Next Action/_Agenda/Boss”
   • “.Next Action/_Agenda/SalesGuyOnCurrenProject” etc
5. Optionally make “.Next Action” mutually exclusive on sub categories (suggested by the mailing list)
6. Create the same people centric categories under Waiting
7. In preferences select the following
   • “Use Tabbed Interface..” off (you need to see context and task list at once)
   • “Allow for tasking notes” on (optional but useful)
8. Edit the “.Next Action” category and make it a different colour (NB Not red as that will hide overdue tasks)
9. Optionally make
10. Optionally add additional columns to the task view (suggested by the TaskCoach mailing list). It can be useful to add a column for category so that tasks can be sorted by category or context.

Using it:

1. Create top level tasks for your current projects. Create actions as subtasks under projects (You can drag and drop tasks between or into projects)
2. Add new actions to the list in the normal fashion, so the task list becomes an inbox as well
3. Add due and start dates as required
   • Deferred  actions
   • Delegated actions
   • Tasks with a real due date
4. Review tasks in the task list (daily) by
   • Selecting “Tree of tasks/List of tasks” as you progress to see context (or not)
   • Assigning the correct Next Action context to tasks during review. NB Only one NA category should be used
   • Moving new actions to the correct projects
   • Removing Next Action category from completed tasks
   • Using the other categories as appropriate
5. Now click on the “.Next Action” category and only next actions are displayed. Selecting a specific sub category (and de-selecting the higher “.Next Action”) will further filter by context