Jamie Flournoy's Software Development Blog
Painless! I’m actually starting to expect it to work without hitches now.
There are a couple of config file changes that need babysitting but none of them was difficult; I really do wish it would automatically do a three way merge between its old package version, the new version, and my version, and just assume “yes” if they merge cleanly.
Instructions are trivial: see Hardy Upgrades: Network Upgrade for Ubuntu Servers (Recommended).
This also works fine on Xen.
I haven’t read enough Heinlein to be sure that I like the guy, but he gets major brownie points for TANSTAAFL. jwz gets brownie points for several reasons, not the least of which is for having written, Linux is only free if your time has no value.
I try to avoid the mistake of saying that an inanimate object or non-corporeal hunk of information “needs” something, but I fail sometimes. For example, I said “I just think that ActiveRecord needs to support the low-level and middle-level abstractions better.” This is silly; of course, code doesn’t need anything per se.
You may think I’m being pedantic by saying this, but people commonly mix up whose needs are really being described. What I should have said was, “I would be happy with ActiveRecord if it supported…”, clearly indicating that the need was mine. I have a problem, and this code doesn’t solve it fully. And I understand that I, and maybe some like-minded individuals, bear the burden of actually trying to solve this problem. If I sit and wait and it gets fixed, that’s great, but it’s not fair for me to demand that the universe solve all my problems for me just because it has solved a few of them already without me doing any work.
Continue reading “On Anthropomorphizing Code”
When I am ruler of the universe, this will be my first edict:
Any clickwrap license which:
(a) is longer than 1000 words, OR
(b) is longer than ten (10) times the height of the text box it is enclosed in, OR
(c) is displayed in a text box that uses less than 5% of the total display area and cannot be resized by the user for easier reading, OR
(d) cannot be selected for copying and pasting into another document, OR
(e) cannot be read before purchase,
IS AUTOMATICALLY NULL AND VOID.
Inspiration abounds, but today it’s the Firefox 3 clickwrap license window’s that fails (c) and probably also (a) and (b) which reminded me of this common UI issue.
I subscribe to dozens of tech blogs (including but not limited to Ruby and Rails), and although I’ve seen quite a lot of commentary about TDD and BDD, I’m not sold on either of them yet. TDD is interesting, but BDD seems like a waste of time. But I am completely sold on automated testing in general. I write lots and lots of tests and make sure using rcov that my tests cover all of the code.
Getting 100% coverage isn’t easy. In general it means you definitely can’t just write a single test case per method and declare victory when it passes. When the number of possible combinations of inputs (method arguments and/or mock objects) and expected outputs (return values, exceptions, and side effects) becomes large, then the potential for copy-and-paste errors in your test code becomes large, and legibility becomes an issue. This is the point at which I find the recent fascination with writing tests in a near-natural-language DSL to be a distraction. It’s orthogonal to the problem I’m dealing with, which is how to comprehensively test the code. In other words, the problem is not making a small number of tests more readable, but concisely expressing a large number of input/output combinations and a large number of different tests, and making it all readable.
I assume that there are others working on this problem too, so I’ll describe some of the things I’ve come up with, and hopefully if you have any good ideas you’ll post them in the comments section.
Continue reading “Techniques for Exhaustively Testing a Rails App”
I’ve been moving a bunch of utility code out of a medium sized project (>10KLOC) to make it easier to test. I started by trying to make a set of plugins, but inter-plugin dependency management is basically nonexistent, and now that Rails supports explicit Gem dependencies, I decided to make them gems.
I’m happy I chose to make them gems, but I miss some of the stuff you get in a Rails project. In particular I wanted ‘rake:stats’, so I can update my estimation spreadsheet which is now almost 9 months old. I need the stats for each gem in addition to the main Rails project, in order to compare this to prior figures from the Rails project before I split it up.
So, here is the Rakefile snippet that I added, which adds the rake:stats task into a regular gem. If you don’t have the Rails gem installed, it will fail gracefully, without breaking your whole gem. So you need not make your teeny little gem depend on all of Rails being installed on every machine where your gem needs to go. Just install Rails whereever you want to run stats, which is probably already the case on your development machine.
Continue reading “Rakefile snippet to run Rails’ rake:stats in a plain old gem”