I’ve always liked Michael Feather’s concept of stunted frameworks. I write a lot of code that could be re-used, but it is tailored to specific projects. Adding hooks, and configuration to make the stuff more generally useful and releasable as open-source just feels like too much hassle. I wouldn’t mind, so much but I don’t want to add bulk and complications to the code I’m working on. In any case, the chances of it matching everyone else’s edge cases are slim.

Look what happened to David Megginson when he wrote SAX2:

people were screaming for all kinds of esoteric stuff that about 12 people in the world care about (i.e. entity boundaries) ….. SAX ended up with all kinds of new, optional interfaces in the distribution anyway, so it’s quite nightmarish for a new user trying to figure out what matters and what doesn’t.

It recently occurred to me that Github is an excellent mechanism for distributing stunted frameworks. To that end I’ve just added (a tiny) one for writing stubs in Java, by providing partial implementations to an interface. I first wrote about it in 2005 and have since then used it on many Java projects in lieu of more sophisticated mocking libraries.

For more information go to the project at http://github.com/paulanthonywilson/dummy-proxy/tree/master

All the cool kids these days like to have the current Git branch as their command-line prompt. Call me old fashioned, but I like to know my current directory as well. As showing the full path can get ridiculous, I just want the directory name.

This is what I ended up with in my .profile:

export PS1=\
'$(echo $PWD| sed s/.*\\\///) \
$(git branch &>/dev/null; if [ $? -eq 0 ];\
 then echo "(\[\033[00m\]$(git branch | grep ^*|sed s/\*\ //)) ";\
 fi)\$\[\033[00m\] '

(The Git part was copied from the Internet somewhere – I forget where.).

This is what it looks like:

I’ve enjoyed using and writing about Dr Nic’s Rbiphonetest. It’s been cool being able to at least do the testing point of iPhone development in Ruby, which is far more succinct, DRY, and expressive than Objective-C. It’s also handy to be able to take advantage of Ruby’s mature testing frameworks.

I’ve even been able to test the iPhone’s UI widget interactions, which Rbiphonetest is not supposed to do: it needed a hack, but it was a clever hack – and that’s the problem. Rbiphontest is a clever experiment, but it seems to have run its course. Anywhere off the standard path (UI, Catagories, creating one model in another) is strewn with traps and difficulties. Even Dr Nic seems to be discouraging its use.

So expect more blog entries about Rbiphonetest. What I will be writing are some tutorials on doing iPhone TDD using the Google toolbox for Mac. I’ve got something like autotest running with it already. Stay tuned.