They recently decided to significantly redesign the Projects feature within Komodo, as part of version 6, and it serves as a great negative example of what happens when you don’t consult your users or put out prototypes but just inflict a design on people. For many users, including myself, the new approach loses functionality and makes the program significantly more painful to use, as you can see in the discussion forum.

I’ve heard a few tales now that reflect a certain degree of arrogance in the ActiveState team and I wonder if this is another example – the team or a key person wanted this new design and didn’t want to deal with asking the community so chose to implement it first, so there’d be no going back. I found this comment particularly interesting:

If you’ve followed bugzilla, you’re aware that there were plenty of bugs in the project system.
True, we could have fixed those bugs, and gone on with the status quo, but there were aspects in the existing project system that were standing in the way of where we wanted to take Komodo.

As you can see below, from the New Features web page, it’s basically a file tree, in their words It provides a customized view of your file system (local or remote) and allow easy file management operations such as file editing, copying, drag/drop file moving, creation or removal of files and folders, as well as recursive search capabilities.

Places will replace the existing Komodo project viewer (by the time Komodo 6 is final).

One of the things that really bugs me about this is that I am a cross-platform developer. When I shift platforms, I shift mental modes and use the explorer and file open dialogs of that platform, with their different idioms and keyboard shortcuts. I don’t want the Komodo developers spending their time writing a replacement file browser for me. I have written enough file handling to know there’s more work than many people anticipate dealing with different permissions, network drive issues and external file system events – it’s not a trivial workload to have added that we didn’t ask them to take on!

I am using xUnit.net with C++/CLI invoking native DLLs and so I need to have the working directory set to where these reside. The settings I use are (note the fixed directory for Command, obviously changing to that of your local install).

Shown in context in the dialog:

In case anyone’s curious about the appearance of the above dialog, it was captured on a Mac using Remote Desktop into my Windows 7 box so the rendering lacks a bit of Aero gloss.

We have a standard environment variable pointing to the location of thirdparty code which I wanted to use but the tool definition dialog refused to accept a path for the Command like $(thirdparty)\xUnit_net\blah.exe.

It also refuses to accept just an executable name, even when it’s on the PATH and can be run in a command window with just that executable name.

Bembeng’s post showed using the longer way to compose the Arguments of $(BinDir)$(TargetName)$(TargetExt) but I prefer simply $(TargetPath) which is easier to type and read.

If anyone’s curious, I eventually picked xUnit.net over NUnit and mbUnit/Gallio because it allows for similar parameterised testing but has a GUI test runner that copes with C++/CLI and I like their style and rationale.

This was indexed at Ohloh and shows why it is such a dumb idea to claim XML is a programming language. Ohloh now asserts with some appearance of authority that the source code has few comments and makes other discouraging claims. Mild slander on what is now the top hit for rbKarel in Google

I assume Ohloh’s report about the comments is because the XML serialisation of REALbasic source doesn’t contain any XML comments. The actual source code comments are invisible to Ohloh. It also has more detailed statistics on the number of lines of source code, which are completely bogus.

A much better approach would be to confess to ignorance, instead of saying:

• Mostly written in XML
• Very few source code comments

They should say unrecognised source format or, if they wanted to show off, source appears to be stored in XML, unknown programming language.

The other thing which annoys me about Ohloh’s judgement is that it doesn’t really cater for mature, stable software that is moved to an open-source repository. Such software appears to have little version history and may have few commits, making it look like a piece of alpha-level abandonware. They do have one redeeming feature in this regard, allowing you to enter an arbitrary start date for the project rather than solely being stuck with the automated analysis.

This all wouldn’t have irritated me so much but I was reminded of that page recently by a Google Alert for “Andy Dent”  and found that a search for rbKarel now hits them first, meaning this slightly slanderous page is what people will read and possibly not bother trying the actual program! After all, if the most popular page on the web about something implies it’s poorly maintained and lacking comments, why bother?

As a side-inspiration, Sarah Zettel’s excellent novel The Fool’s War includes pen-based UI in the spaceships where a special pen is used to access information and sign the log as an authentication device.

Tablets

I’ve owned a CrossPad for a few years and it’s effectively retired, largely because of the heft and age of software. The CrossPad was a combination digitizing tablet and pen so you recorded strokes in the pad as you drew with the pen, giving you an instant ink copy. The software included mediocre OCR and it used a serial connection.

A later incarnation seems to be the DigiMemo which adds USB and can function as a realtime graphics tablet. The DigiMemo .DHW format files can be converted to SVG using a third-party script, by Kevin Lindsey. Other OEM branded devices are the Adesso Cyberpad and AipTek MyNote.

There are a number of such tablet devices out there and a UK site devoted to their sale with some charmingly awkward user reviews is Digital notepad.

The .TOP file format is one of the dominant formats saved by these devices and Gadgetoid raved about the cross-platform third-party VectorPen software which converts .DHW, .DNT and .TOP files to PDF and SVG.

Pens

Pens with a small clipboard receiver are attractive because they allow the pen to be smaller than the paper-based ones below and have no inbuilt cost of special paper. The latter is a big selling point.

Peter Steieir dismisses the IRISNotes due to poor software, especially the difficulty of getting vectors back out because it writes to a proprietary .pegvf file. That’s the same format as the IOGear Mobile DigitalScribe which I’ve seen locally.

Getting more details on the DigitalScribe took a bit of digging but I eventually found their manuals and software on the support site. From these I was able to work out that the pen has no way to navigate back to previous pages. This may just be a limitation of this model or inbuilt in the OEM’s design but I think it’s a fairly fundamental weakness.

The Amazon reviews of the DigitalScribe include a useful tip that the Staedtler Multi-Action Pen refills fit. A common theme is that the receiver clip only manages a few sheets of paper so you can’t clip it to the top of the typical top-bound legal pad.

Pens with Paper

An alternative to the standalone pen is the Anoto technology which uses unique microdots on special paper. You can get a 500 euro demo kit directly from them but the Livescribe below is a cheaper way to experiment. They commonly partner with companies delivering forms-based applications such as simPRO. The big deal about the Anoto technology is being able to map all pen actions back to specific locations on the paper including having what amounts to buttons on paper – clickable areas to trigger pen actions.

Livescribe seems to be one of their dominant partners in the consumer space, with the Pulse pen supported in Australia by Smartpen. As well as being commonly retailed, rather than bundled with specialist software, the Pulse adds audio which is linked to your strokes on paper and replayable within the pen or desktop.

The Livescribe Platform allows for developing custom applications which recognise special areas on the paper, coupled with logic in the pen to provide the recognition. The release notes provide a nice summary of the steady development of the product over the last two years. The Pulse user manual is also online. This 2009 review includes an example of how well the strokes are captured and how the audio capture of the Pulse is linked to paper areas.

With a sufficiently high-resolution (600dpi+) color laserprinter, the Livescribe desktop software allows you to print your own paper or you can order pre-printed pads from OfficeWorks and other stationery suppliers.

I’ve also effectively retired from consulting, taking up a full-time job at Gemcom Software. I’m very limited about what I can talk about there, thankfully there’s an internal blog on which I can vent my need to think out loud. Based on the public job postings, I can say I’m working with WPF, C#, C++ and back in Python land (so much for all the time spent learning Ruby!).

My involvement in the REALbasic community is going to shrink considerably as I’m focussed on other languages and frameworks. I’ll still put some odd time into projects like rbKarel (although it’s mature and works) and further porting of OOFILE to RBRW but that’s about it. It will be interesting to see how hard it is to delve back into RB if I’m living in Visual Studio and C++ and C#.

In the Questions section at the end he talked about lock-in and mentioned the new generation databases such as SimpleDB as representing lock-in because they aren’t standardised.

I did some quick skimming and found an interesting debunking article on these key-value databases.

The enthusiastic response to these databases makes me wonder, apart from the obvious Google must be right attitude, if a sloppy view of the world as a soup of key-value pairs is actually an inherently comfortable way for many people to think about data? Is it appealing because this is a level of complexity we can think with more naturally?

The image below was created by sizing a preview to fit at a non-readable text level and then taking a snapshot. The original PDF is 72KB and allows you to cleanly zoom in to see the flow.

Clicking the image will let you see a larger version but still obfuscated.

Zoomed out to Obfuscate - Accounting Program UI flow

I also uploaded files to the expatpp project so I could include them in OOFILE using the svn:externals property.

Part of the attraction of this chore was so I can walk through the report-writer in a modern compiler, to help finish my port to REALbasic.

I have to bask in a bit of immodest glory here that the source needed so little tweaking, mainly a couple of issues that have been brought up to date in VS2008 with streams, and the report-writer still works flawlessly under Vista 64, including its simple MFC preview window.

I was very lucky in that no tabs were broken and found a great guide to fitting keys but thought a few points might help someone else squinting at the problem. This is definitely magnifying glass territory if you are trying to work out where the gaps live in some of the hooks.

Any directions below assume you have the same position relative to the laptop as in normal use.

When Apple’s guide says to get the scissor mechanism back in place first, it is vital – you can’t get the scissor to click with the key in place. So, if either of the two pieces is still on the key, pull it out gently at right angles from the key. The hooks that the scissor pieces go into are designed to snap over the pins on the scissors with a downward pressure on the key, so they pull out the opposite way.

Reassembling the scissor – you will notice ridges on one side. The smooth side of both pieces should be facing up.

I found it easiest wiggling the larger piece scissor over the lower pair of metal hooks (which point towards you) then getting the two long skinny arms to click into their holders, by very gently squeezing them inwards.

When the scissor is in place properly, it feels smooth when you run your fingers over it and is disconcertingly flat – it does not appear to stick up much, unlike the photos of the smaller key scissors. You should not be able to remove the scissor by gentle pressure – if you can that means you haven’t got it properly hooked into position.

The rest is simple, as the Apple document describes, put the stabiliser bar through its two holes and then gently press the key vertically into place – there are four points where the scissor will click into the bottom of the key. You don’t have to worry about getting these lined up – the geometry of the scissor does that for you surprisingly well.

Hope this helps or amuses someone. I was near to panicking and taking the laptop into a repair shop because I didn’t seem to get making progress and the first attempt just fell straight off the keyboard as the scissor wasn’t correctly in place.