Posted by Chris Ball
Mon, 06 Jul 2009 22:58:00 GMT
ExploreTree
Over the July 4th weekend, I found time to release the tree visualizer that Mad and I wrote for the Processing Time code jam a few months ago. Mad's worked on it some more since the code jam, adding a search function, options for specifying font size and the tree depth shown, and a link from each node to its Wikipedia page. The program's available as an applet now, at:
http://exploretree.org/
Feedback welcome, especially if it doesn't work for you and you're able to figure out why.
Bugs Everywhere
Bugs Everywhere, everyone's favourite distributed bugtracker, has been seeing a decent amount of work lately thanks to some strong efforts:
It's nice to keep momentum going on some small projects. Counter-intuitively, I think it's much easier not to get tired of programming when you're working on code for work and different code outside of work, than when you're just concentrating on the code for work.
Tags bugseverywhere, exploretree, processing, python | no comments
Posted by Chris Ball
Mon, 15 Sep 2008 05:36:00 GMT
I spent a few nights working on a web site recently — it's a public OpenSSH keyserver, in the style of the OpenPGP keyservers, and it's up now. I'd like to attempt to persuade you all to consider uploading your public SSH keys to http://sshkeys.net/, for a few reasons:
If you publish your public key, it's going to be easy for people setting up accounts for you in the future to find it, with a simple wget sshkeys.net/you@yourdomain.com.
If you manage machines, having your potential users upload keys to the site should save your time by making sure they get past problems like uploading the wrong file, since the site will tell them if they try to upload anything other than a public key.
There should be side benefits of having a large repository of SSH public keys: I think we would have detected the recent Debian/OpenSSL randomness bug sooner if we'd been on the lookout for unexpected duplicate keys, for example.
I used Django for the site and it was shockingly effortless, to the point where I didn't have to write any SQL or interact with the database manually. I wrote the following model, which says that there are Addresses, Keys, and combinations of Address and Key that have some extra fields like whether they've been verified against the supplied e-mail address or not:
class Address (models.Model):
address = models.CharField(max_length=255)
def __unicode__(self):
return self.address
class SSHKey (models.Model):
owners = models.ManyToManyField(Address, through='AddressKey')
keytext = models.CharField(max_length=1024)
def __unicode__(self):
return self.keytext
class AddressKey:
address = models.ForeignKey(Address)
sshkey = models.ForeignKey(SSHKey)
date_added = models.DateTimeField('date added')
verified = models.BooleanField(default=False)
token = models.CharField(max_length=40)
token_sent = models.DateTimeField()
After that, it all just worked. The gap between having it all working in the Admin interface (time taken: 3 hours) and having it all working with production views was much larger, though. The Admin interface is full of beautiful widgets that are not at all re-usable in your production site.
The full code's available over at github (under AGPLv3). I'd be very happy to get patches to make it smarter, and let me know if you find any bugs. Thanks!
Tags django, django, python, python | 23 comments
Posted by Chris Ball
Mon, 15 Sep 2008 05:36:00 GMT
I spent a few nights working on a web site recently — it's a public OpenSSH keyserver, in the style of the OpenPGP keyservers, and it's up now. I'd like to attempt to persuade you all to consider uploading your public SSH keys to http://sshkeys.net/, for a few reasons:
If you publish your public key, it's going to be easy for people setting up accounts for you in the future to find it, with a simple wget sshkeys.net/you@yourdomain.com.
If you manage machines, having your potential users upload keys to the site should save your time by making sure they get past problems like uploading the wrong file, since the site will tell them if they try to upload anything other than a public key.
There should be side benefits of having a large repository of SSH public keys: I think we would have detected the recent Debian/OpenSSL randomness bug sooner if we'd been on the lookout for unexpected duplicate keys, for example.
I used Django for the site and it was shockingly effortless, to the point where I didn't have to write any SQL or interact with the database manually. I wrote the following model, which says that there are Addresses, Keys, and combinations of Address and Key that have some extra fields like whether they've been verified against the supplied e-mail address or not:
class Address (models.Model):
address = models.CharField(max_length=255)
def __unicode__(self):
return self.address
class SSHKey (models.Model):
owners = models.ManyToManyField(Address, through='AddressKey')
keytext = models.CharField(max_length=1024)
def __unicode__(self):
return self.keytext
class AddressKey:
address = models.ForeignKey(Address)
sshkey = models.ForeignKey(SSHKey)
date_added = models.DateTimeField('date added')
verified = models.BooleanField(default=False)
token = models.CharField(max_length=40)
token_sent = models.DateTimeField()
After that, it all just worked. The gap between having it all working in the Admin interface (time taken: 3 hours) and having it all working with production views was much larger, though. The Admin interface is full of beautiful widgets that are not at all re-usable in your production site.
The full code's available over at github (under AGPLv3). I'd be very happy to get patches to make it smarter, and let me know if you find any bugs. Thanks!
Tags django, django, python, python | 23 comments
Posted by Chris Ball
Sat, 29 Mar 2008 00:54:00 GMT
Bugs Everywhere is a neat piece of software implementing distributed bugtracking: it combines a bugtracker and a distributed version control system. I've offered to be its new maintainer, taking over from its original author of Aaron Bentley and the folks at Panoramic Feedback. Bugs Everywhere posits that the use of a centralized bugtracker for software is no less inappropriate than the use of a centralized version control system1, and that real programmers work with bugs that exist in complex states of being fixed on some branches, as yet unmerged on others, and trying to keep a mental model of which is which is doomed to failure.
For example, at OLPC we believe in cheap and fast branching, and we have feature branches (e.g. "faster"), development branches ("joyride"), release branches ("update.1"), and production branches ("candidate", "release"). We have a bugtracker that allows us to describe bugs as being "open" or as being "resolved", which closes them. This is not cool.
In the Bugs Everywhere world, the same branch that contains your code also contains the bug state for that code. So, as I create my "faster" branch software, I can create/close bugs linked to those commits. When my tree is merged into the next branch up, we not only get the code merged, but the bug state merged as a side-effect. The bug state is not going to become inconsistent with the code.
How does it work? We insert a .be directory into your repo, and use a command-line interface ("be"), web interface (written in TurboGears) or GUI (written in wxWidgets) to let you perform the dual operation of changing the state of the text files that describe bugs, and committing that change to the underlying VCS. We support Arch, Bazaar, GIT, Mercurial and RCS. BE itself is written in Python. Of course, another benefit of this approach is that the same offline editing advantages that your dVCS gives you apply to your bugtracker.
You might argue that being distributed sounds good, but having a common place for developers and users to go to to query bug state is important too. Having a distributed bug tracker isn't incompatible with this — the central web interface to the bugtracker becomes just another client performing merges with the master location for the repository.
So, should you drop everything and switch to BE? Well, maybe. One way in which BE currently isn't suited to OLPC is that we like having a central bugtracker for many projects, even though each project has its own source repository, or even several. BE would be much more suitable if we were just developing a single software project, rather than the complex selection of projects and processes that we currently track. Maybe the way forward is to run a meta-tracker that keeps track of changes in any of the specified source repositories and collates them.
Another current limitation is the web interface support, which was written against an old version of TurboGears, and is still a proof of concept. Noah Kantrowitz is interested in working on a BE backend for Trac, which would offload the web interface awesomeness to Trac.
I'm writing this post to try and build up a community around BE: please check out our wiki and mailing list, and consider hacking on it. It's the future, honest.
1: Or at least, I do.
Tags bugseverywhere, olpc, python | 8 comments
