Archive for October, 2009

Units 0.03 is out

October 31, 2009

Units 0.03 is on PyPI. It includes a bug fix (A litre is a cubic decimetre, not a cubic centimetre!). It also has patches for PyPy that let you run a Python interpreter with built-in support for quantity literals. With these patches you can type 239 cm * cm * cm + 0.502 L and it will do what you expect.

Improve your Java: Restrict public methods to interface implementations

October 29, 2009

Good programming is all about restriction and constraint. Most possible programs do nothing interesting. Type systems, unit tests, code reviews and all that jazz are just ways of throwing out uninteresting programs.

Here is a chart view.

There are many more broken programs that good ones.

Notice the thickness of the blue slice.

This realization is what makes me feel comfortable proposing that we, as programmers, should mostly be thinking about new ways we can restrict ourselves.

Here is one way you can restrict your Java (or other classical Object-Oriented) programs to make them better.

Aran’s Public Interface Implementation Rule: All public methods on a class should be implementations of some explicit interface.

See, Java is tricky, because interfaces are interfaces, but so are classes. When you expose public methods on a class that are not part of an interface, a user of the method must specify the class name on the left hand side:

YourClassThatsAlsoAnInterface p = new YourClassThatsAlsoAnInterface();

That means their code is now glued to your implementation. They might not like that.

It would be better if you let them code to an interface and substitute implementations as desired. Thus, don’t bother putting public methods on a class that aren’t implementations of an interface.

YourInterface p = new yourClassThatsJustAClass();
YourInterface p2 = new theirReimplementationOfYourClassThatsJustAClass();

Incidentally, this rule totally enables Joshua Bloch’s Effective Java, Item 34: Refer to objects by their interfaces.

As Zak points out, the tradeoff is that you may hurt some compiler optimizations. If you have benchmarks to prove that following this rule causes unacceptable performance degradation, you have my permission to ignore it. Thanks for asking.

Leave your thoughts in the comments.

A Hack for “Unknown or expired link”

October 28, 2009

You’re using a web site, you fill in a big long form, and, upon submitting, you get “Unknown or expired link.” Why does this happen? The short[1] explanation is that the web site gave you a hidden code to submit with your form, and while you were typing, your code expired. If you hit “Refresh” to get a new code, your browser will probably throw away the contents of your form. You’re lucky you can hit “Back” from the “Unknown or expired link” page.

What to do?

Choice number 1: Copy out your form contents, refresh the page, and paste the contents back in. Slow, boring and painful.

Choice number 2: Get a new code and edit your current page to use it. Fast and fun!

How to get a new code: Open a new browser window, go to the page with the form, use “View source”, find the form you were filling in, find the hidden field in the form with a weird value, and copy the strange value.

How to edit your current page to use it: Go to the window where you’ve filled in your form, pop open your DOM editor, find the weird hidden field, and replace its value with your new code. Now when you submit your form, it will be using a fresh code!

OK, so maybe it isn’t easy, but at least it’s fast.

[1]: The long explanation is that the web site is probably using a continuation-passing style for managing client-side state and it garbage-collected your form submission continuation. I didn’t think you wanted to know.