oscartheduckin’ around

November 8, 2009

test driven development

Filed under: Uncategorized — Tags: , , — oscartheduck @ 9:16 pm

So, it’s been a while since I’ve done this.

 

Test driven development.

 

I’m taking the time out on tabbr to refactor completely with test driven development from the bottom down. Why? Because I’m so fucking sick of small errors appearing because I was reworking code slightly and didn’t notice a typo, or a cmd-X and cmd-V took a wrong character with it because of a bad selection or something similar.

 

The latest misfire: I just discovered that a dump of an object to yaml is coming back with dumping the false object instead. When did this error happen? It’s such a simple thing, what the fuck is going wrong? All I can imagine is that an array that’s being initialised in the object creation isn’t being created properly, because I’ve been working on methods that alter data structures. And that’s simple to find and fix, but I should have something automatic that’s telling me about it. Maybe I can write a pre-commit hook in git that runs all the tests, as soon as I’ve written them up.

 

I’ve been writing code too long to keep ignoring what is, really, the basis of the current vogue trends for behaviour driven development and the like. Test driven development is the real basis that makes agile programming completely doable, and I’m not doing myself justice by ignoring it.

 

I did have some shell scripts I was keeping up to date that did similar things, but dumped the output of a bunch of config files to stdout instead of just being automated testing suites that’re built in. Serious duplication of effort somewhere there.

 

Blah. I should learn from the crowds more.

Advertisements

October 12, 2008

decisions, decisions, decisions

Filed under: freebsd, ruby — Tags: , , , — oscartheduck @ 8:04 pm

I’ve been thinking about writing a new ports installation tool which solves a few problems I’ve always thought would be neat to solve. Thus:

1. decision 1 — write a new ports tool or extend an existing one?

This is really hard. I’d write a new ports tool in ruby or shell. Guess what the two existing main ports tools are written in? That’s right, ruby and shell! So I just sit here thinking about the wisdom of potentially rewriting a lot of functionality. Especially with portupgrade being written by a hacker who’s ten times the programmer I am, and portmaster being, well, fucking fantastic.

Here’s some of my aims:

1. The ability to instruct a remote machine to build every port needed
for a local upgrade of ports as a packaged to be pkg_added.
2. The ability to cross compile everything. This means that a local
arm board can upgrade its onboard dns server by having a remote
xeon based computer build the port.
3. The ability to run the command without super user privileges. I
want to have a directory I have write access to that my ports
can build to and be able to do an upgrade of those ports
automatically.
4. The ability to synchronise ports across machines. This should be
architecture independent, and should take into account that
ports can with this tool be installed into home.

Which leads to decision 2:

2. How do I technologically best accomplish this?

Which is the same as decision one, really.

There are so many decisions. How do you search for a port when someone wants to install it? The other two tools I usually use for this stuff answer this question by saying “we don’t”.

So, accepting my premise that I’m not as good as these other folks at solving this issue, I won’t either.

A second: how do you determine if a port is to be upgraded? Well, there are two options I see:
1. roll my own method of doing so
2. use someone else’s method of doing so

I prefer the idea of number 2. Software is something that should be built modularly, so that each piece can be upgraded independently. And if I just use someone else’s tool, then I inherit their improvements.

portupgrade looks like the tool I shoould be thinking about, but I don’t want to follow their design decisions. I instinctively think portmaster has the right idea with not using an external database; maintaining pkgdb is annoying, irritating, and a whole host of other words which mean the same damn thing. There are a host of poorly documented prompts when repairing the database; stale dependency, eh? Great! What does it MEAN? I’ve always _assumed_ it was a reference to the idea that a dependency listed in the database is no longer needed, or somesuch thing; googling around can tell you, I’m sure, but the man page for pkgdb doesn’t, and if it ain’t in the man page then it’s undocumented. And that means that yes, I do consider man man to be inadequate because it tells you there a re other sections of the manual but doesn’t tell you _what_they_are_. I know what they are, they’re historically significant and everyone should know them, but man man should list them too.

I’m getting dangerously close to ranting, when I’m actually trying to document something. The aim here is to give people who’ve never written this sort of tool an idea of how the thought process goes. It’s all decisions, and no decision is correct.

Blog at WordPress.com.