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.

WordPress (not Laravel) as an app framework

Is it a good idea to develop full-blown applications as plugins inside WordPress (or an other CMS)? I sometimes feel like it’s a silly thing to do. Especially if the application is not really doing anything to extend or complement the standard functions of the CMS, and is just existing as a stand-alone creature within it.

In WordPress, for instance, lots of things can be done by creating new post types: a plugin for tracking books and authors could have two new post types for those entities, and we would attach whatever metadata is required. Or alternately, a few new database tables could be created, and the book-managing plugin could do things directly with them and completely ignore the standard post functionality. The latter would mean other common features of filtering and things wouldn’t apply, but then that’s often just as it should be when we need full control over how an application behaves.

Basically, I sometimes only really use WordPress as a framework for:

  1. user authentication and authorisation;
  2. installation and upgrade;
  3. a theming/skinning system;
  4. internationalisation;
  5. familiar UI for users;
  6. the front-end/back-end dicotomy.

And that’s it. Everything else is within the plugin. See how it feels a bit silly?

However, it means that a plugin-application does have the things listed above (for no effort on my part), and it also gets what it perhaps the most important reason that I go this route: the WordPress community.

So I’ll carry on being silly.

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.

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.

Writing Plugins

I want to help to write plugins for things. Not these full-blow, stand-alone applications with requirements and scopes that change and change and are never finalised! Far nicer to work on a small part of a bigger application, with a particular goal in mind that can — with time and work — come closer and closer to being realised.

With other people, too. That’s the best part of it. There’s whole communities of users out there. Much nicer to work with.

Don’t Write Code (write descriptions of things)

I wish I didn’t know how to code.

For a programmer, the solution to every problem is to write more code.

But sometimes, all that is needed is to write proper words. To explain things and explore them through prose.

Not to remove oneself to the meta-realm of trying to understand the general structure of the problem and model it accordingly. (And then build something that resembles that model, and hope that the people using it see through the layers back to what the buggery’s trying to be done!)

Just write some nice, verbose, rambling blather about what it is and how it works and where we’re trying to go from here. Nothing too technical, and hopefully actually interesting to read. At least, linear, in that old-fashioned way of real writing. Interesting is probably too much to aim for… just words, then.

I was reading Phoebe Ayers recent post about the task of archiving the Wikimedia Foundation’s material. My first thought was “what sort of database/catalogue would be useful for this sort of thing?” Which is quite the wrong question, of course. There’s a whole world of wikis (both instances and engines) out there, perfect for this sort of variably-structured data. (If there’s one thing that constantly amazes me about Wikipedia it’s the fact that so much structure and repeated data is contained in what is basically an immense flat list of lone text files, and that it does rather work! The database geek in me shudders.)

I think a basic tennent for archiving physical and digital resources is that each object, and each grouping of objects, needs to have its own web page. In most cases, I use this both as a catalogue entry for the object or group, and as a printable coversheet to store along with the physical objects (or, in the case of digital-only objects, to be a physical placeholder or archive copy, if they warrant it).

The other thing I try to stick to is that a fonds and its catalogue (i.e. a pile of folders/boxes and the website that indexes them and adds whatever other digital material to the mix) should be able to be shifted off to someone else to maintain! That not everything should live in the same system, nor require particularly technical skills to maintain.

I know that there’s a dozen formalised ways of doing this stuff, and I wish I knew the details of them more thoroughly! For now, I’ll hope that a non-structured catalogue can work, and continue to write little printable English-language wiki pages to collate in amongst my folders of polypropylene document sleeves. And I’ll keep checking back to en.wikibooks.org/wiki/Subject:Library_and_Information_Science for instructions on how to do it better…

Contributing to Github-hosted projects

Some projects provide information about how people should fork and contribute to them. This is my general approach (included here, obviously, for my own edification):

  1. Fork a project: Github clickity-click
  2. Clone it locally:
    git clone git@github.com:username/project.git
  3. Add the upstream project:
    git remote add upstream git@github.com:upstream/project.git
  4. Do not commit to the master branch; it is to be kept up-to-date with upstream master:
    git pull upstream master
  5. Create branches that solve one feature or issue each, named whatever:
    git branch new-branch-name master
  6. Create a ‘personal master’ named with your username:
    git branch username master
  7. Do not merge master into feature branches, rather rebase these on top of master:
    git rebase new-branch-name
  8. Merge all personal feature branches into your personal master branch, so you’ve got a branch that represents all your development.

My main goal is to create discrete branches, based on the upstream master, for features that I want to push back upstream.

(No doubt I’m missing obvious things, and any git-geek will see instantly the gaps in my knowledge.)

Updates:

To combine the last three commits (and write a new commit message):*

git reset --soft HEAD~3
git commit

Sorry, Apple Inc., I’ve met something I like more than you

I first used a Mac in about 1993 — a Quadra I think it might’ve been, or a Performa. I’d come from DOS and Amiga and didn’t really know anything about anything — I didn’t even know there was anything to be known. I remember hearing someone talking about Windows, and assuming they just meant those rectangles one could drag about on the screen. A computer to me was a fun sort of thing which could usually be made to do (boring… but strangely compelling) things with textual input and output, thanks to variants of a ‘basic‘ language (AmigaBasic, QBasic, etc.). When I found AppleScript — and when I started using it for CGI programs (don’t ask!) — it seemed that all that one needed was an idea and some time, and the machines could be made to do anything!

Anyway, it was on System 7 that I spent most of my time (and its successors), thanks to my stepfather’s loyalty to Apples — and I loved it. I loved the whole Apple thing, really — this odd feeling that somehow, just by choosing this particular OS, one could be calmer, more focussed, write better (code or prose), and still spend one’s spare time rock climbing (as I did). That couldn’t be the case with those horrid business machines running Windows, that was for sure! I even got a reply from Douglas Adams himself once (a Mac person, as if you didn’t know), to my pedantic email with the subject “Macs are PCs too, you know” (he said, no, they’re not, that argument has been won, and Macs are something more than Personal Computers). I remember sitting in a bookshop reading the Apple Human Interface Guidelines, and thinking how much amazingly careful thought had gone in to everything — the distance between buttons in a dialog window, for example, or the algorithm for changing the length of the ‘thumb’ in a scroll bar as the content length changed.

Why on Earth was there such an element of personal identification with these computers?! I was an ‘Apple person’; otherwise known these days, more appropriately, as a fanboi! Which has lasted nearly twenty years… but I can’t keep it up. I’ve been through five or six Macs in that time — I’m typing this on my MacBook5,1 — but it’s time to move on. I’ve enjoyed them all, especially the feeling that they are reliable: physically solid and unlikely to break in my backpack. But I won’t be buying another. I’m losing faith.

No, I’ve lost my faith. I lost my faith as Apple wanted to control everything more and more — the whole ‘ecosystem’, as they say, of OS and programs and data and sources — and as my awareness of the value of open standards grew. Obviously, I’m not saying that one can’t work perfectly well with open standards on Mac OS, because I have been doing so for years and years. It’s just that the OS as a whole is not geared to helping people do that. I shudder to think of people who know no better and are tying up their entire digital archives in formats that offer no security for future access! (But don’t let me get sidetracked into that discussion…)

I’ll no longer align my computing life (which is a rather large part of my life, for better or worse) with a corporation who’s aims are less than honourable: so I’ve bought a Lenovo X220, and shall be running Ubuntu exclusively. (I would’ve done this years ago, except for the fact that my current hardware has been running well since 2008, and I hate the idea of discarding a useful machine. Also, I do most of my computing on Linux anyway; the local machine is just a gateway, really.)

Goodbye Mac OS! I’ve enjoyed the ride and learnt lots, but ultimately have been thwarted in learning on too many occasions. It’s time for a system that, should I come up against its limitations, can be changed to suit my needs.

So long and thanks for all the fish. ;-)

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.