Nitch is now at version 2.0.1 uploaded to SourceForge, and the latest major change was to add support for high level goals. I think I need to add some screenshots to the overview page here on 40hz to make things a bit clearer, but in brief, it is now possible to define roles (there is a FlashPoint-like way to switch to different views in Nitch via a folder tab), and add projects as goals for each role.

Planning goals for roles is usually an activity done at the beginning of the week, with daily adjustments if necessary. Nitch will prioritize actions higher when the associated project is a goal, and it will use a visual highlight for those actions.

I’ve been using Nitch now for about half a year, and it seems to really hit the sweet spot in terms of managing projects and actions, marking actions as complete, and getting feedback about achievements and priorities. All of that was tremendously helped by the NewtonOS - again, I have to say! It’s such a joy to program for it…

It seems that I’m joining the ranks of the many who want to combine GTD and the 7 Habits approach by Stephen Covey. When I first approached GTD, one of my concerns was which next action to pick, see for example my use of priorities in Flashpoint. This was however not the most critical point at that point, it was rather how to slice projects into small, actionable items to actually get something done.

Now that I’m getting better at creating next actions and projects (Nitch is working really well!), making the right choice among the actions comes back as an issue. For a while, I have been using ToDo items in DateMan as “themes of the day,” but this overlaps with my use of ToDo items for the hard landscape for that day.

Which brings me to the 7 habits. After re-reading Covey’s book, the approach to first define your roles, and then your weekly goals with daily adjustments makes an awful lot of sense. I’m still thinking whether goals can be expressed straight in terms of a set of GTD projects, but overall, integrating this approach into Nitch should be easily doable.

I’ve been working on and off with Ruby in the past, and really like the language. There are some quirks and inconsistencies, but overall, it’s still the best of the lot. I’m working with Mac OS X, Windows and Linux, and Ruby bridges the platforms quite nicely, including the user interface layer. Only threads and IO are a bit tricky.

The project I recently spent most time on is a framework for communicating with the Newton via the regular Dock protocol (it works over serial, Bluetooth or TCP/IP connections). It is in spirit a replacement of the Desktop Connection Library, written in Ruby. I’m using the 40Hz repository on SourceForge to host the Subversion repository in case you want to check it out. It’s nowhere usable yet though :) But I can connect cleanly to the Newton, and the next step is to fill in the missing commands to do something useful.

The purpose of such a framework is to help with the basic use cases of installing packages and dumping data from the Newton, but in a wider context, it would be nice to use it as the basis for synchronization or backup/restore.

I noticed that writing on the Newton is easier with my rotring Quatto-Pen Data than with the regular stylus, but somehow, the rotring pen has a slight annoying rattle. On the other hand, we have tons of Pilot Super Grip mechanical pencils at work, which feel quite comfortable overall. Well, it seems that with a little bit of drilling and sawing and some super glue, it’s very easy to fit the “data” tips of the rotring (or other styluses) into the Pilot pen. And voila, the “Pilot Super Grip Data” is born :)

The reason I got stuck on this was that the Pile of Notes approach works very nicely, it just requires that you write down your thoughts the moment they come up.

Here is one more round of updates to my “getting things done” quest: After rationalizing a bit more what is actually important in GTD for me, I came up with Nitch, a little tool which lets you use the Newton’s Notepad as a project repository where next actions are simply handled as checklist items. Check one item, and Nitch will show it as a next action, mark it as done in Nitch, and it will be removed from the project checklist.

I find it quite remarkable how in the end, any of my approaches to GTD is leading back to a very strict interpretation of David Allan’s book and articles. As soon as I deviate too much, things stop working for me. It is one of these situations where things seem obvious when reading them, but you have to come to the same conclusion by actively practicing the methods. As an example, Flashpoint did in the end not work well for me because it took too much time to create new projects. But having a complete list of projects is extremely important, otherwise you will always end up having open loops.

I’ll be changing my job soon (funnily enough, most of the things I do now will stay with me), and I need to plan quite a few things like scope, cooperation with others, team setup and so on. Early stages like this are quite interesting from the way they are organized: They look much fuzzier than day-to-day work, and there is a component which does not fit in very well with an approach like GTD, at least from my perspective. That component is brainstorming and information gathering.

I have used mind maps in earlier projects, and they did help, but also had a tended to have a more temporary character. The challenge with information gathering is that the brain does not like to be controlled in that area, and good ideas or important thoughts just pop up at any time - regardless whether they are connected to a current project or not. This is a constant process, and ideally dealt with at all times.

Recently I came across one method which was puzzling first, but does seem to make quite a lot of sense now to me: The Pile Of Index Cards. You really have to adopt the mindset fully, read the whole Wiki, look at the Flickr pages and let it sink in for a while - but then I got it:

• Categorizing thoughts is difficult, so why not skip that step and just write down whatever comes up, and concentrate just on the thought, not the potential context
• The context can vary, and it is established during the Task Force phase where all thoughts are gathered and evaluated
• Thoughts come up all the time, and an index card seems just like the right size to gather one idea
• Instead of trying to form and document a clear picture and set of thoughts, the focus is on non-discriminating information gathering. Maintaining a clear picture (revisiting, updating, categorizing, tagging, sorting) at all times is very difficult and time consuming.

The original POIC method uses index cards, but I think the Newton is actually equally usable, and maybe even better: You can carry all your thoughts with you at all the time, the POIC Dock is a bit to bulky for that. One drawback is however that you cannot spread out all the notes, look at them from a bird’s eye perspective, and cluster them. The Newton allows searching, and it would be possible to handle the Task Force phase by putting Notes which are connected into different folders, but it maybe still a bit cumbersome. There is nothing preventing us from printing all the Notes though, and handle this part not on the Newton but using plain old paper.

I will give this method a try, in the end it is pretty interesting to say “good bye order, welcome chaos” :)

My previous efforts of using GCC to compile C and C++ applications for the Newton are now documented a bit better here. I uploaded the tools I put together so far to SourceForge. They include some Lua scripts to turn ELF executables into NCT modules, and a template makefile with the proper compiler and linker flags. The tools should be cross platform, but a cross compiler for the ARM target is still required.

Using the tools should allow compilation of C programs and linking them with the Newton libraries. Using any of the C++ classes in the Newton libraries is however quite tricky, I don’t think it will work out of the box. The reason are the different calling conventions, name mangling schemes and constructor/destructor calls.

I wrote earlier a bit about Scrum and how it looks similar to GTD. The practical reason for looking at Scrum was that I’m working on a small project which uses Scrum principles (not the full blown version). As it seems, most of the tools available to support scrumming are a bit too heavy for my needs, so I took the opportunity to write my own small app - and learn Ruby on Rails in the process :)

The result is now on SourceForge: A small RoR app called BagLock. Not perfect, but maybe somebody finds it useful.

I finally found some time to document my various GTD setups. It is quite interesting how much time it takes to realize what is actually behind GTD, and what the real issues in doing one’s work are! Another interesting dimension is the connection between GTD and the Scrum management method (it’s not only usable for software development). To me, projects look awfully like user stories, and sprint backlog items like next actions, just on a slightly bigger scale. And the principle to frequently identify those things which would bring you closer to the “done” state, and start working on them instead of trying to come up with a project and requirements plan at the very beginning looks very much like the GTD process to me.

After fixing the MySQL issues on 40hz.org (seems that some of the tables got corrupted), here is a status update for Blunt 2…

Overall, I’ve made some good progress on Blunt 2 over the summer. Right now, Blunt 2 is almost usable for connections initiated from the Newton side. I rolled in some stability improvements, changes to the service discovery, better preferences and more diagnostics code. There are still some stability issues which I suspect are coming from the interrupt handling routines, and some issues regarding automatic startup and shutdown of Blunt 2. Also, accepting connections is not implemented at all on the NewtonScript level. Still, I’ve been able to transfer data using IC/VC and Neo, which is right now the most important use case for me.

One interesting side project was to improve logging facilities, and I’ve settled now for a very simple but effective mechanism: I added a logger class which writes data straight onto the serial port at 9600 bps, which means a simple “cat /dev/…” command is enough to get the log outout. No more messing with Hammer :)

The current snapshop is as usual on SourceForge in the Blunt 2 release area.

PS: There were also some minor changes to IC/VC regarding export of names with multiple addresses which was problematic before with Mac OS X Address book.