Abandoned code projects

One of the sad things about open source software is the process of working on some code, feeling like it’s going somewhere good and is useful to people, but then at some point having to abandon it. Normally just because life moves on and the higher-priority code always has to be the stuff that earns an income, or just that there are only so many slots for projects in my brain.

I feel this way about Tabulate, the WordPress plugin I was working on until a year ago, and about a few Dokuwiki plugins that I used to maintain. All were good fun to work on, and served reasonably useful places in some people’s websites. But I don’t have time, especially as it takes even more time & concentration to switch between completely separate codebases and communities — the latter especially. So these projects just languish, usually until some wonderful person comes along on Github and asks to take over as maintainer.

I am going to try to keep up with Tabulate, however. It doesn’t need that much work, and the WordPress ecosystem is a world that I actually find quite rewarding to inhabit (I know lots of people wouldn’t agree with that, and certainly there’s a commercial side to it that I find a bit tiring).

Not this morning, though, but maybe later this week… :-)

I’m redundant

This week is the first time for seven years that I’ve not had a job to go to (and not been on holiday). So of course I’m sitting at a computer working on some code, drinking a coffee. The location (Parlapa) is better than the office, and more importantly my mind is not full of thoughts of work-code; it’s time to focus on projects that make me feel good.

Sailing in Spain, 1975
Sailing in Spain, 1975

Which is a tricky proposition, of course, because there are so many that I’d like to put time into, and it’s hard to prioritise. This morning I’ve been attempting to figure out why a cronjob I’ve got running on Tool Labs isn’t sending me emails. Yesterday I was scanning a small stack of photos that my dad took in Spain in 1975. Next I shall continue with a little website I’ve been working on to make it easier to search and browse books on Wikisource (almost all of the data for which is coming from Wikidata). But then there’s this little tool that I wrote a while ago for producing HTML and LaTeX albums from Flickr groups; it needs expanding and improving. Not to mention my desire to explore AtoM some more, especially in relation to how we might be able to use it while working on the Maps for Lost Towns Geogeeks project.

See? Too many things. That’s why jobs are good: one need just turn up every morning and have a ready-made list of what’s-to-be-done.

Stop inventing new ways of doing things

Every so often I write this same thing. It’s Monday (any Monday) and so it’s time to write it again.

The solution to very few problems is to write more code. Usually, it is better to write things in English, explaining whatever the thing is.

This is mainly because it takes a good long while to write code, and continues to take time for as long as the codebase exists. This time is better spent actually doing something — code is pretty much always ‘meta’ work, work that supports other work.

And don’t go saying that all work is like that, because it’s just not. (Hurrumph.) Working on preserving, describing, and storing all the books of the realm is work that has value in itself; writing the software for doing that is meta-work. I’d rather work on the former.

Today, it seems to me that the incremental construction approach is best. Don’t tear everything down and start again! That’s slow, and will never result in an improvement overall — some parts will be better, but others worse. Instead, find the bit that is most rubbish, and fix that. Then repeat. The growth will be messy and disorganised, but will have a quality that otherwise would never be achieved. Both a particular quality and a vibe of quality I mean.

Stop inventing new ways of doing things

Every so often I write this same thing. It’s Monday (any Monday) and so it’s time to write it again.

The solution to very few problems is to write more code. Usually, it is better to write things in English, explaining whatever the thing is.

This is mainly because it takes a good long while to write code, and continues to take time for as long as the codebase exists. This time is better spent actually doing something — code is pretty much always ‘meta’ work, or work that supports other work.

And don’t go saying that all work is like that, because it’s just not. (Hurrumph.) Working on preserving, describing, and storing all the books of the realm is work that has value in itself; writing the software for doing that is meta-work. I’d rather work on the former.

Coffee

Roll in to work, settle in for half an hour or so, and then head to the tearoom to make a cup of coffee. A good way to get one’s head in for a nice morning building databases. But that’s further down the list of Best Ways to Drink Coffee…

  1. A nice cosy cafe, without overly-loud music, tables a good height and not rocking, and nothing at all to do for a good few hours. Espresso.
  2. The office coffee machine, or ‘coffee printer’ — as it really does behave more like a noisy dot-matrix printer.
  3. Mocca-pot, or (secondly) frech press, at home with just-ground beans and a clean kitchen in which to make it. The choice of cup is far more satisfying here.
  4. A ”coffee bag” can be surprisingly good if all else fails.

Note that the muck they call instant coffee does not appear in this list.

Preventing duplicate rows in a tabular HTML form

I am working on a bespoke issue-tracking system at the moment (not for code issue-tracking, in case anyone thinks we’re cloning Redmine; although there certainly are overlaps…) in which each issue has a list of personnel, each of whom have a role on the issue.

The task at hand is to prevent people selecting the same combination of role and person more than once. Of course, the application and database will reject such an occurence; this is to fix the UI so that users can’t easily submit the duplicates. For the purposes of this explanation, we’re working only in HTML and Javascript (jQuery).

The UI looks something like the screenshot to the right (there is also a means of adding new rows to the table—that doesn’t change how this validation works, but it is why we’re using .live() below):

The Problem

In an HTML table full of form elements,
where new rows can be added (dynamically),
we want to prevent duplicate rows being selected.

The Plan

After changing a value in any row,
get a list of the values in that row
and then go through all of the rows
and see if those values are there.
If we find more than one instance of them,
tell the user
and return the changed value to what it was before.

The Solution

The final code is below (it was built using jQuery 1.6.1 and jQuery UI 1.8.5), and a demonstration is available elsewhere.

West 86th – Paperwork Explosion

“Machines should work, people should think.” The message repeats itself several times; it’s the core of the film’s techno-utopian vision. We can imagine IBM executives and lawyers and public relations agents sitting across a table from Jim Henson telling him to make sure he includes these lines in his film. What if, following William Empson’s advice to readers of poetry, we shifted the emphasis just a little bit? From “machines should work, people should think” to “machines should work, people should think”? Is it possible that the film might be trying to warn us against its own techno-utopianism? Read this way, the film is less an imaginary resolution to the problem of information overload in the modern era than an imaginative critique of this imaginary resolution. Machines should work, but they frequently don’t; people should think, but they seldom do.

Ben Kafka

via West 86th – Paperwork Explosion.

Finding all date ranges (which may be open-ended) that overlap with a given range

Given a database table listing events and their date ranges: events { id, start_date, end_date, }, where either or both of the dates can be null, how is one to find all of the events that fall within (even partially) a given date range? (This is pretty much what Kieran Benton asked on Stack Overflow, with the addition of the nullability.)

There are twelve possibilities for ranges with respect to the given range A-B:


Note that the gradients indicate null start or end dates. PNG
SVG

The red ranges are the ones that should be included in the result; the orange ones should be omitted. It’s easier to query for the smaller set, which satisfy the following conditions:







































































> A < A > B < B NULL
Start Date x


End Date
x


Start Date



x
End Date
x


Start Date

x

End Date

x

Start Date

x

End Date



x

Which corresponds to the following SQL:

SELECT * FROM events
WHERE NOT (
  (start_date IS NOT NULL AND start_date < :A AND end_date IS NOT NULL AND end_date < :A)
  OR (start_date IS NOT NULL AND start_date > :B AND end_date IS NOT NULL AND end_date > :B)
  OR (start_date IS NULL AND end_date IS NOT NULL AND end_date < :A)
  OR (start_date IS NOT NULL AND start_date > :B and end_date IS NULL)
)