Gordon’s Place

I implemented a very small change to simplepassword.com last week, which has opened the way up for some nice usability enhancements. The change itself was very simple – you can now pass the name of a domain as part of the URL to simplepassword.com. So you can do something like this – Generate a password for bbc.co.uk. Doing so will populate the domain field for you and move focus on to the password field. Handy enough, but only if you’re developing your own site.

It becomes more generally useful when you hook it together with some Javascript. I knocked up a little bookmarklet which will take the location of the page you are currently on, parse out the domain name and then call simplepassword.com passing this domain name. So you can have a one-click “generate me a password for this site” button in your browser toolbar. Full details, with installation instructions, here.

Time for a story. Some time ago I was listening to the stack overflow podcast. There was a theme which had been running for a few episodes which was how to track all your different passwords, and how to make them easily accessible whenever you needed them. Most of the suggested solutions involved either password management software or an encrypted file together with options for either syncing it between computers or remotely accessing it.

I was kind of interested in this discussion since I’d pretty much been there. I’d had an encrypted DB containing all my passwords on my PC, it synced to my phone. Which was grand until I changed my PC for a Mac and bought an iPhone. Then I was faced with having to buy some new software to do the same thing and re-keying all of my passwords. Needless to say I hadn’t bothered and I was starting to slip into some pretty bad password habits. You know, lots of sites, only a few different passwords.

So at that point some bloke joined the discussion to suggest a site called http://passwordmaker.org/. He explained that the idea was to build a hash out of a site URL and your secret master password and to use this hash value as a password for the site. The hashing function would ensure that each site had a distinct password and also that it could be easily re-calculated whenever you needed it. All you had to do was remember your master password.

Now I’m sure this says something about what a geek I am, but I thought this was a fantastic idea. Simple, elegant, clever and a lot more secure than the way I was currently managing it. I went straight to their website to try it out, which was a bit of a shock. Try it yourself, here’s the on-line version of the software. There are fourteen fields on that form that you have to fill out to generate a password. Fourteen! I’m not even sure I understand what some of them are for. Great idea, but I’m really not convinced about the implementation.

So I did what any self respecting programmer would do. I wrote my own version of it. I scratched my own itch. The first implementation was, of course, a command line ruby script. It took 2 parameters – URL and master password – generated a password and popped it on the clipboard. It was opinionated software, it didn’t ask you to choose which hashing algorithm or character set to use, it just went on and did it’s thing and gave you back a password.

And that’s how things stayed for the best part of a year, I’ve used this script to generate / re-generate all my passwords and although it’s worked very well, it is only available when I’m working on my own laptop. Over the last couple of months I’ve been getting to grips with Rails, so it was a fairly logical and simple extension to create an on-line version of the script, and thus simplepassword.com was born. It’s still opinionated software, even the name of the site reflects that. I hope you enjoy it, but if you need something more complex then there are other options available.

To paraphrase the opening sentence of The Nerd Handbook, every geek has to have a project or two on the go to keep them out of mischief. Well, my latest side project has just gone live. It’s called simplepassword.com and it’s supposed to help you out with the password fatigue that we all get these days from having logins to dozens / hundreds of different websites. And it’s supposed to be very simple. The idea is that you pick a single “master” password and then use that password together with the URL for the website you want to login to, to generate a password.

I’m using a hash to generate passwords from the combination of your master password and the URL of the website you want to login to. This means that I can accurately re-generate a password for a given site from the same master password and also that the passwords generated for each URL will all be different from each other. That last bit is pretty important. Using simplepassword.com to generate your passwords will give you strong distinct passwords for each website you use.

The site is up and running right now, so please check it out and leave your feedback. There should be a feedback tab on each page, feel free to make use of it.

My first attempt http://gordonrobertson.muxtape.com/.

This is better. As soon as I’ve allowed myself to post something trivial, then there are a whole lot of things that I’d like to say spring to mind. Here’s one.

I’ve been working on a couple of projects recently in which I’ve made use of an xUnit style framework for unit tests. Both of the projects have mainly been backend BL code, which is the stuff I usually want to write loads of tests for, but I’ve approached the test code in two different manners.

In the first I looked at each test having to be entirely self contained. I wrote Setup routines to load a bunch of fixtures from external XML files into a variety of tables before running the test. Then the tests would run, then the teardown code would tidy out all of the tables involved in the test. This worked pretty well, I could run the test with nothing but an empty DB and the test routines, but it wasn’t the quickest. Every time the tests were run, I had table loading and tidying up to be done. It never got to the stage that it was taking too long, but I could imagine a big application with a high level of test coverage wouldn’t be able to say the same thing.

So, with the second project I tried a different approach. Instead of loading up the tables with the correct data in advance, I decided to have the setup code attempt to find appropriate test in the existing tables. If it couldn’t find the test data that it needed, then it would fail the test with a “Could not find appropriate test data”. If it could find data that met all the requirements of the test, then it would use that data as the basis of all of the subsequent tests. I wouldn’t need all the overhead of loading the fixtures, but I would have to make sure there was decent test data in place.

So, what I wanted to do was to share the wisdom I’ve gained from trying it both ways. The reason that I tried the second approach at all, was that sometimes having pre-defined test fixtures and load and tidy up routines seemed a little overkill when all I was working on was a simple update routine. I was spending more time setting up the tests than writing the code. I would concede that for this simple scenario, finding your data on the fly in the existing dev database is probably fine. But anything more complex that that quickly becomes a problem. As my latest piece of code grew in complexity, I ended up spending more and more time nursing the tests through running properly by inserting records here / deleting records there. I grew to hate the “Could not find appropriate test data” messages. And I would often have bugs in the test code. Probably more often than in the code I was trying to test. Plus this lack of a solid “known state” before running the test suite would often mean that the tests were non-repeatable, they’d run once and then the second time would fail ‘cause one of the other developers had changed the data.
So, the conclusion I’ve reached is that independent test fixtures, plus setup / teardown routines to load and clear those tables, should always be part of the test routines. I keep the fixtures as XML files and check them in with the test code. That scheme did seem a little heavy handed for simple routines, but it certainly scaled up well when the complexity increased. I’m pretty sure that if I care to check it out, this little gem will already be common knowledge in the automated testing community, but since I went to all the bother of trying the experiment, I figured I at least deserved to be able to post about it.
There you go. Two posts in a week.

Quiet here, init? I’ve been somewhat remiss at updating recently. So much so that mates have started pointing out how deserted this place is starting to look. It’s really not meant to be. I do enjoy writing and posting, but the longer I’ve left it without writing anything, the more I’ve felt that I really need to post something heavy, significant and thought provoking to make up for it. And all my interesting projects, like the Progress feed parser and the Progress xUnit framework are half finished. IOW, I don’t have anything which is both significant and ready to post. So, I’m giving up on that and sticking up a largely content free post, as I’m sure you’ve noticed by now, just to get going again. More soon, hopefully.

... experimenting with twitter.

I’ve been meaning to mess around with yahoo pipes for a while, so I’ve just built a simple “lifestream” to pull together all of the various feeds I’m currently generating. Have to admit, I’m pretty impressed. I was able to grab a series of feeds, use a different regexp on each of them to adjust the titles before merging and sorting the results into a single amalgamated feed. Took less than half an hour and most of that was spent tracking down feed URLs. You can see / subscribe to the results here, but fair warning – there may be WAY too much trivial information in this, even if you know me well.

The feed contains – my blog entries, my flickr photos, flickr comment conversations, my twitter stream, my starred items from google reader, my recent reading list and a list of golf courses I’ve played. It may change in the future to include even more trivial information, such as my bookmarks and my listening habits.

I’ve been meaning to have a mess around with Lightbox for a while now, so I’ve knocked up a little slide show from my flickr “moon” collection. Click on the image at the top of this post to see it in action. Tested in Firefox and IE7.

Great idea, would be really, really useful if it contained some Progress code. Then I could ego search .