I spent a few hours recently refactoring the TickTickDone javascript to reduce code duplication. In the process, I generalised out a common pattern - a link that, when clicked disappears and is replaced with a form. If the form is cancelled or submitted, the form disappears and the link returns. An example can be found in the “Add a new milestone” button on the goal page of TickTickDone. I’ve packaged up the HTML template and the javascript, and linked them below. To use it, create your HTML page with a section following the format in collapse-form.html. Include collapse-form.js, and call the following in your javascript init:

init_collapse_forms($(document));

Collapsible forms version 1:

collapse-form.html

collapse-form.js

First off, read this: http://xkcd.com/413/.

Once you’ve got the robot going:

1. Write a low-level controller with a python interface
2. Display the currently running code on a web site
3. Allow anyone to upload a patch through the web site
4. Any patch that passes some basic tests (ie. the code still executes) is applied to the code
5. Every hour, the new code is automatically uploaded to the bot

I’m sure I’ve heard that you can edit running lisp code, so that might be an option as well (although I can actually code in python, which is an advantage ). I reckon you could have a lot of fun playing with evolutionary algorithms, trying to make some sense out of the webcam input and so on. Anyone feel like building one?

This post is a summary of this essay by Clay Shirky. It details social / technical issues that you need to accept or design for when building social software for long-lived groups. The full article is interesting and well worth the read, but the following serves as a useful summary of the take-away ideas.

Things to accept:

1. You cannot completely separate technical and social issues.
2. A pattern will arise in which there is some group of users that cares more than average about the integrity and success of the group as a whole. And that becomes your core group, Art Kleiner’s phrase for “the group within the group that matters most.” Now, the software does not always allow the core group to express itself, which is why I say you have to accept this. Because if the software doesn’t allow the core group to express itself, it will invent new ways of doing so.
3. The core group has rights that trump individual rights in some situations. So the core group needs ways to defend itself so that it can stay on its sophisticated goals and away from its basic instincts.

Things to design for:

1. Handles (an identity) the user can invest in.
2. You have to design a way for there to be members in good standing. The minimal way is, posts appear with identity. You can do more sophisticated things like having formal karma or “member since.”
3. You need barriers to participation. It has to be hard to do at least some things on the system for some users, or the core group will not have the tools that they need to defend themselves. Now, this pulls against the cardinal virtue of ease of use. But ease of use is wrong. The user of social software is the group, not the individual.
4. You have to find a way to spare the group from scale. You can’t try to make the system large by taking individual conversations and blowing them up like a balloon; human interaction, many to many interaction, doesn’t blow up like a balloon. It either dissipates, or turns into broadcast, or collapses. So plan for dealing with scale in advance, because it’s going to happen anyway.

Here’s an idea I had on while on the bus going past a graffiti-covered warehouse:

1. Start by owning some wall-space in the city.
2. Divide the wall into generous portions.
3. Post a notice on the wall stating that anyone is permitted to paint a wall-space, as long as the previous piece has been up for at least a month.
4. Enjoy the random, free creativity.

Inspiration from postering etiquette, greater union civic commissioned graffiti, graffiti culture in general.

At the end of last year, one of my friends started a webcomic and published it using Google Pages. It was an adequate, but rather inefficient way to work, so we wrote ComicHub, a webcomic hosting site with a clean interface, with grand plans of finding a way to make money from it. It didn’t take us long to realise that that wasn’t going to work, but we put some Project Wonderful ads up anyway (they’ve made $5 in the last six months ). All that said, the site is still up and running, and free for anyone who wants clutter-free hosting for their comic / photoblog / random scribblings. Enjoy!

ComicHub: It’s better than Google Pages

What would it be like to write a small, but useful web app within a timespan of one week?

Way back when I thought of the name “NiftyKit”, I envisioned niftykit.com as an index page for many small web apps we developed. We didn’t really get around to developing that (unless you count ComicHub), and since then have worked on a number of larger projects, the latest being TickTickDone.

The idea reoccured to me the other day, and today I found Clay Shirky’s essay on Sitated Software, which fits the idea beautifully. The concept really appeals to me, I think because the potential for awesomeness is higher than generalised apps because it can be so much more specific and relevant. A great example is leech, a distributed app-sharing tool we built to work around tiny disk quotas at uni, which was lots of fun to develop and use.

I think trying to do it would produce some interesting results (adding a whole new meaning to rapid app development to start with ). I can see myself starting to think of ways to speed things up already (eg. setting up a really solid base project to work from each week). It’s certainly a way to use constraints to force innovation.

At the moment I can’t see any way to make a significant sum of money off of it, unless we started generalising the apps after the first version was built, but that would quite possibly defeat the purpose. If we made enough of them they might work as donationware, but maybe it’d be simpler just to do it as a hobby and call it good karma. I’ll see if I can come up with some ideas and try it out.

In response to this post, I’ve written an equivalent script in python (because I’m too lazy to get the CPAN lib):

#!/usr/bin/python

from twyt.twitter import Twitter
import sys

username = ''
password = ''

def tweet(message):
    twitter = Twitter()
    twitter.setauth(username, password)
    twitter.status_update(message)

if __name__ == '__main__':
    message = ' '.join(sys.argv[1:])
    tweet(message)

It depends on python-twyt. Enjoy!

I had a request for a script to delete all the tweets in an account, so here it is:

twitter-obliterate-0.1

May be harmful to your tweets, use at your own risk! I’m not sure how fast it is, since I’ve only tested it on an account with about 10 tweets. It has to send a separate HTTP request for each tweet, and it does so serially. Hopefully it’ll be adequate for all but the most massive accounts.

The tarball includes a version of the python-twyt library, modified to add support for the archive command. Patch on the way to the maintainer shortly…

Update: I’ve done a few tests and it appears the code has some bugs, but due to lack of demand I haven’t investigated any further. Let me know if you’re interested in a fix!

Whenever I’ve tried to start a blog in the past, I’ve always had trouble, maybe becuase I also had trouble writing in english back in school. So, starting sometime soon (hopefully within the next few weeks), I’m going to do a 30 day trial, writing a post every day. Hopefully by the end of it I’ll be in the habit, and I’ll have plenty of content to bulk out the site. I’ll start collecting topics to write about now, so I don’t run out of ideas.

Here’s a start:

• http://www.tune-out.com
• Response to http://www.acidlabs.org/2008/05/02/cognitive-heatsinks/ and Clay’s ideas in general
• jQuery
• The NiftyKit story so far
• Responses to Steve Pavlina articles
• 30 day trials in general and my latest one in particular
• Intention-manifestation
• Write up private journal entries into public posts
• … more to come