A Tuesday morning

The internet seems to be full of bad news at the moment, so I’m ignoring it and focussing on some nice little code projects that are calming and friendly and only slightly maniacally frustrating.

SVG Translate tickets are petering out; version 0.10.3 is just out with some login fixes and language updates.

This morning I’m working on adding a ‘messages exist’ notification icon to the PageTriage toolbar.

And I think I’ve cracked the search-debouncing for my Embed Wikimedia plugin, so might be able to move on with the metadata- and appearance-improving stuff that I’ve been trying to do for weeks.

Sorting duplicates in Piwigo

Piwigo has a duplicates-search feature, which allows you to search for duplicate photos by original filename, MD5 checksum, creation date & time, and/or image width & height. It’s slightly annoying though, because although it presents you with the duplicates, it doesn’t sort them so that potential duplicates are displayed next to each other. I’ve attempted to fix this.

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