The Quest for 'Done'
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.
Pile of Notes
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” :)
Newton and GCC
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.
Distractions, distractions...
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.
GTD again... and a bit of Scrum
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.
Blunt 2 Status
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.
A little hammered
The Newton, that is :) I haven’t gotten the complete Newton debug protocol put together yet, but I have at least a way to connect and get some logging done. Since I haven’t used Hammer to actually debug much (Blunt for example is very asynchronous which is not easy to debug anyway), this is enough to get rid of Hammer for regular development work. The problem with Hammer is that it loads the CPU 100% when connected, and it has a tendency to hang and hog the serial port. And it runs in Classic only.
There is still lots missing from the actual debug protocol, right now especially initiating and terminating debug sessions is not done properly since it involves not actual commands, but rather setting memory values remotely on the Newton. Reverse engineering those parts is however lower priority now because I really want to get Blunt 2 done!
At least I tried
So, it is possible to get CFront to work. I downloaded the 3.0.3 release, massaged the source a bit and compiled it on MacOS X. The output looks very close to what the Norcroft compiler generates, but it’s not close enough. And the reason is simple: The Norcroft compiler in the Newton C++ Tools is based on the 2.1 CFront release. Too bad, there is no source available for that. I guess this does not qualify as fun for many people, but maybe I get a degree in software archeology at some point… we’re talking about code which is 15-20 years old. No further comments about the quality of the CFront sources, they compiled after all, but looking at them is as much fun as poking a fork into your eye.
As a bit of background information, the main issue with C++ on the Newton is the incompatible vtable format: The Norcroft compiler does not handle multiple inheritance well as far as I can see, so it uses a quite simple vtable format, and all later compilers changed that somehow (either by using thunks or stubs, or by adding offset fields). Unfortunately, the vtable format has a direct influence on the generated code, calling virtual functions looks quite different from compiler to compiler. In addition to that, the vtables in the Newton ROM are actual jumps, whereas other compilers just use function addresses.
What will work though is to use C++ without virtual functions, and to stick with C.
C++ ruins it all
Development tools for the Newton are becoming more and more an issue - especially the C++ part of that problem. The NewtonScript side looks actually quite ok now with DyneTK, but we are still stuck with the ancient Norcroft C++ compiler for classic Mac OS (the 68k variant). Not that it won’t work, but it makes moving to an Intel based Mac quite hard. Add to that the problem that serial ports don’t seem to work here under BasiliskII and Mac OS X, it seems that you need a PowerPC or even 68k based Mac for any Newton C++ development.
I dug a bit deeper recently, but just to confirm that no version of GCC will ever be usable for C++ programming for the Newton. C will work, but the C++ code generated by GCC and the code in the Newton ROM won’t play nicely due to vtable issues (among other things).
Well, one last straw still exists, although it is actually slightly insane to even consider this option: The Norcroft compiler is based on CFront, so theoretically, you could compile CFront and use it to convert C++ code into C code, which could then be compiled by e.g. GCC for the Newton. The old CFront sources are available, but a quick attempt at compiling them resulted in a bunch of errors… maybe it needs a bit more than just a quick attempt.
iPhone
There has been lots of discussion about the iPhone in many places, among them of course NewtonTalk, and Leander Kahney dropped me and others a quick emailasking about my option on it, especially how it relates to the Newton… well, I said it before and I’ll say it again :) - the Newton is hard to replace since it is so reliable and versatile. There’s no way I would trust a device without a user replaceable battery with my data, or use a device which needs to be recharged frequently without any usable emergency power source like AA batteries. A PDA simply has to work, otherwise you’d worry more about the thing doing its job than actually being productive with it. After thinking a lot about what I need for both organizing both my personal and work life, I concluded that it’s either the Newton … or paper :)