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.

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.

Composer repository URLs can’t use UNC paths?

It would seem that when using Composer on Windows, one cannot use UNC paths as repository URLs. That is to say, the following doesn’t work:

{
  "repositories": [
    {
      "type": "vcs",
      "url": "//SERVER/Share/project.git"
    },
  ]
}

Instead, the share must be mapped and the mapped drive letter used:

      "url": "G:/project.git"

This does, of course, have the stupid side effect of forcing everyone who uses the composer.json in question to map the share to the same drive letter! However, this is hardly the most significant of the miseries that one must live through when developing software on Windows…

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.

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

Switching an SVN directory to and from an ‘externals’ definition

There seems to be quite a few posts out there about how to replace Subversion externals definitions with local directories, but not so much for going the other way. I’m not sure why; it seems to me more likely that one would start off with some small module as part of a bigger repository, and then at a later date want to move it out to live on its own. I don’t really know what I’m on about, though.

The point being, that I’m working with a branch of a project that is having a few of its directories — its current, local, ‘normal’ directories — replaced by externals definitions. That’s all fine and good, but I keep having to switch to trunk and back again, and there’s the crux: the directories that are getting turned into externals do not like being switched.

Running the usual svn sw http://svn.example.com/repo/branches/v2 from the top level of a trunk checkout gives the following error:

Fetching external item into 'lib/foo':
svn: warning: W155037: Previous operation has not finished; run 'cleanup' if it was interrupted

Running svn cleanup complains with:

svn: E155010: The node '/path-to-repo/lib/foo/file.txt' is not installable

And not even status has anything useful to say (throwing instead the same error as above).

A solution (and yes, this post is probably a bit long-winded for such a short snippet of advice; I can only say that I felt like writing this down this morning because four weeks ago I figured it out but forgot and I suspect that four weeks hence I’ll have forgotten again, and this morning is one of those moments of verbosity; blame Travels with Charley, which I was reading over breakfast this morning), and it’s probably not the ‘proper’ solution because I’m no Subversion hacker and do rather treat it as magic, but the solution that I use is (and I’d better put it on it’s own line, because no one’s likely to have read to the end of this paragraph)…

Delete the offending directory (as in, rm -r lib/foo or what have you), and update again.

That’s all.