Sharing Software Should be Like Playing a DS Together

The good folk over at 37 Signals published some upgrade figures for a day in the life of the new Backpack and, as often happens, the comments were the most idea-sparking part.

One obviously happy user said you guys added a lot of features officially that we were sharing one backpack login to pull off.

This made me think about product features and how often the multi-user version of a product is delayed to get version 1 out the door. If you’re not building in a reason for users to buy multiple licenses from day one, you’re teaching them bad habits. In particular, unless you make it really painful for multiple users to share a copy of the application, the upgrade to a multi-user version isn’t going to offer enough incentive once the rot has set in. Continue reading

Reflections on Introspection

RB2008r1 has shipped and the main feature is their addition of what they are calling Introspection. Some people regard them as synonyms but it seems the feature should more properly have been called Reflection as it not only allows you to read information about objects but allows their property values to be set and methods to be invoked. I’ve written an article for the upcoming vol6.3 of RBDeveloper magazine and you can download my sample application to play with Introspection now. For a good example of using the method invoke features, see Paul Lefebvre’s new release RBUnit 3.0.

Culling Features to Ship – Rotating Shapes

When I review the list of bugs in my generic shape editing source, many of them are related to either the behaviour or the final rendering effects of being able to rotate shapes. Rotating shapes in an editing environment, especially those with text, involves a lot more work than people may at first consider:

  1. Rendering the rotated shape, which may require an additional level of masking on Windows and Linux.
  2. Drawing drag-shapes as rotated or at least rotated rectangles.
  3. Drawing the selection outline and handles at rotated positions.
  4. Changing the cursor type as you mouse-over rotated handles, once you have rotated past 90 degrees.
  5. Changing the behaviour of constrained resize handles, depending on the angle, as X movement may now for example imply changing the height of the shape rather than width.
  6. Changing the behaviour of constrained resize or drag, if modifier keys held down, similarly based on shape angle.
  7. The dilemma of whether to implement rotated inline editing or to jump to a straight edit box (which maps to the issue of using edit boxes for inline editing or rolling your own behaviours).
  8. Possibly changing or enhancing the behaviour of nudging shape positions with the arrow keys or menu option (I always like to include a menu equivalent). If a shape is rotated, do the arrow keys move it along the XY axes relative to the canvas on which it is drawn or relative to the shape itself or do you give the user the ability to choose as a preference or runtime toggle?

When I consider the domains in which the generic editor is going to be used for our initial products: report-writer layout, screen layout and possible diagram editor, rotation becomes a lot less desirable than the original arbitrary editor required. However, dropping rotation from the common editor does constrain all of those products for now.
Decision: retain rotation code where possible, to avoid too much culling, but remove the UI for the feature so any related bugs can be deferred until the next version.

Ruby vs Python

I’ve just blogged over on my Artima Blog about choice of languages for AppMakerX coming down to Ruby or Python to replace the proprietary OO language in the original AppMaker v2 (which in turn replaced a truly horrible resource-based template language in AppMaker v1).

Delving deeper into the design-oriented thinking than that post, and deeper into my own psyche, I admit to Ruby being a bright shiny new toy in my mind compared to Python with which I’m comfortable and productive. I can quickly get into a spiral of doubt over my rationalising such a decision, without even going into the possible marketing cachet of a Ruby-based solution.

People with whom I may want to partner for AppMakerX are putting bets in both camps, although I suspect IronRuby and RubyCocoa are well-behind the Python equivalents. It seems, if you’re happy using wxWidgets 2.8, that wxRuby is now up to scratch.

Readers outside the confines of my own mind and possibly occasional ranting to friends will note that I’ve gotten over the Paul Graham effect and whilst retain a fascination for and intent to study Lisp, won’t be using it as an implementation language in any of my products soon. At least, not anywhere that I’m expecting to have collaborators or users fiddle with.

In terms of trying to quantify the trade-offs, I think it comes down to a fairly simple list. I don’t know how the prejudices of above-mentioned potential users work out either way. One of the factors influencing me more towards Python in the past was using it at CSIRO, which is no longer of course anything to worry about. If I do consulting work back there in future it will not be at a coding level other than maybe some C++ maintenance.

Pragmatically, whilst I should be able to claim to know a lot about the Python libraries, that kind of detailed syntax escapes me much of the time and I have to look quickly at the available methods at least. I have a similar feeling about Python as I do about C++ that I’ve internalised so much of using the language, the only main barrier on a given project is looking up the particular libraries and GUI framework.

Technical reasons:

  • Python For – know it well, good performance
  • Python For – lots of great libraries
  • Python For – Komodo has a great debugger and IDE that is cross-platform
  • Python Against – considerable worry about whitespace sensitivity in templates
  • Ruby For – great example book in Code Generation in Action and suspect it embeds with less overhead than Python
  • Ruby Against – some learning curve for the language
  • Ruby Against – Komodo support for Ruby is much less mature than Python

Consulting reasons and future projects or playthings:

  • Python For – I know there’s a lot of Python-based software development around Perth but honestly don’t know if these are places that will ever hire someone to consult at other than lowly web-developer rates
  • Python For – Blender is scripted in Python
  • Python For – my XO Laptop I’m picking up in March is programmed in Squeak and Python
  • Ruby For – I have things I’d love to try to develop in Google Sketchup which is scripted in Ruby.
  • Ruby For – at some point I suspect a Rails job will crop up if I want one, or if I have Ruby expertise will be able to get online from job sites.

Gut Feel: Ruby is strategic and may well be fun but not in the next few months. Komodo and other tools I suspect come at Ruby primarily for web developers using Rails whereas they expect Python to be used by a wider audience.

Decision: For the initial release of AppMakerX I’m going to use command-line invocation of Python. Later will investigate embedding Ruby in REALbasic and C# applications.

XML Bigots and Ant-bites

There’s been an interesting thread over on the Artima Forums – How Will You Use XML in the Years to Come? I’m not writing this post on my Artima Blog because I wanted to bring XML issues to a different audience and there seems to be a fairly bigoted crowd over there, largely from the Java community. I can get into fights with enough people there on the comment threads.

The funny thing is, when I’ve become involved in similar threads in the past, it seems many of the people commenting are anti-XML because of experiences either dealing with relatively small configuration files or other domains where the benefits of schema checking aren’t perceived due to the small file size. It may be that Java developers are soured on XML by the Ant syntax but the whole configuration files in XML debate isn’t really about XML so much as it is about the issues of wholly-declarative make files. Martin Fowler has a nice bliki entry The thing with build scripts is that you need both declarative and procedural qualities. The heart of a build file is defining tasks and the dependencies between them. This is the declarative part, and is where tools like ant and make excel. The trouble is that as builds get more complex these structures aren’t enough. You begin to need conditional logic; in particular you need the ability to define your own abstractions.

One of the perennial issues that crops up with XML is the painful redundancy in having to enter those closing tags, raised by people with a Lisp background (simple parens instead of opening and closing tags) and indentation fans such as the YAML crowd. It was ironic to read a posting recently from someone encountering the main reason for the redundant closing tags – they catch your errors! But one thing which came in handy which I didn’t expect was that because of XML’s redundancy, the parser caught my mistakes in missing closing tags and pointed them out at the location that they occurred.

The posting is worth reading as it starts as someone speaking with no agenda and seeming surprised by the conclusion they come to – XML ain’t that bad.

Whatever is being used, I want my configuration and other exchange data to provide two characteristics:

  1. I can effectively subclass the existing code by being able to add my own annotations and nested clauses in the data, without worrying about breaking their parser or having to maintain their code.
  2. Bits of data should survive being copied and pasted from emails and web pages. This happens very often as we reuse advice from web pages or passed on by friends or mailing lists. Anything relying on whitespace for meaning is under threat (yes, I include Python, which I use happily in many circumstances but has a real problem here).

Given that XML satisfies these two conditions and has lots of free tools out there including stuff for command-line validation (given schemas), I don’t feel the desparate need to replace it. I’m not exactly a fan of the W3C XML Schema XML-based language for schema definitions but it serves a reasonable job much of the time and again, there’s a substantial body of tools that avoid having to write schemas by hand any more. People in the OGC (geo-spatial) community typically work in visual models and generate XML Schema.

Stirring the RB Pot

As part of a leadup to having some good discussions in REALWorld, March, I’ve put a page on the RBWiki to get some discussion going around what makes RB either infuriate or put-off professional users. The aim is to get a consistent picture together for the management at RS to focus on over the next few releases.