I have been using Piwigo for a couple of years (photos.samwilson.id.au), and have been really happy with it. The ability to work with large numbers of photos (uploading lots, and bulk-editing) is what made it a pleasure to use to start with; these are usually the initial tasks one does with this photo-gallery software, and they’re usually where systems are not at their best. Now I’ve got a few thousand photos in it, I’ve gotten the hang of a reasonable workflow, and Piwigo has mostly receeded to the background and just carries on working without issue. I’ve added my albums’ URLs to all sorts of places, including in printed archival descriptions, and feel pretty committed to sticking with Piwigo.

So it was nice to recieve a newsletter from the Piwigo development team, talking about their recent shift of the codebase to GitHub, a new Java desktop synchronisation client, and other things. If one doesn’t actively haunt the forums, it’s hard to remember that Piwigo is still a going concern — but I’m very glad that it is!

Open source software is great, I love using it and contributing to it. But sometimes it goes away. :( Of course, that happens to proprietary apps too, but with FOSS failures I feel sad, because it feels like I’ve personally failed the project (I should’ve been more involved). It’s one of the reasons it’s good to pay for free software. I’m glad Piwigo makes money from their piwigo.com service (well, I assume that’s what keeps the lights on).

Anyway, all I wanted to say was: thanks for Piwigo.

[No comments] [Keywords: , , , , , ] [Permanent link]

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.

[No comments] [Keywords: , , , , , ] [Permanent link]

I’ve been working on a system for integrating custom queries and outputs into Tabulate. So far, it’s only been possible to use MySQL views to combine data from different tables, and the output has been just the same as for base tables. I keep wanting to be able to apply custom formatting to columns or to whole tables — the data is fine, it can almost always be derived with a single SQL statement.

Currently, I’m working on a system of ‘reports’, where one can define a template (using Twig) and a set of SQL queries whose data will be given to the template. Pretty simple, really. I thought about (actually, still wonder if it’s not a better way) making it possible to define custom formats/templates for individual columns and column types, but everything that that approach can do can be done with these ‘reports’, plus a whole lot more.

So, a report (a record in the $prefix_tabulate_reports table) has a title, description, and a Twig template. Then it has a set of SQL queries (in the $prefix_tabulate_report_queries table), each of which has a name (which is what the query is passed into the template as).

It’s hard to know if this is enough. It might even be too much — Tabulate is not meant to be anything more than a CRUD tool, and customisation above and beyond what it does can easily be handled with custom plugins. It does seem that it’s worth making Tabulate able to do some basic display-customisation though, so that site authors can more easily work with data without having to write any custom code.

Because that’s really the goal of Tabulate: it should provide simple ways to work with tabualar data within WordPress in much the same way that spreadsheet programes do on the desktop (well, that’s perhaps a bit of an overstatement, considering the crazy things that people do with spreadsheets). It should easily insert a list of statistics into a post; or add an always-up-to-date chart to a page; or invite submissions of data points from registered users; and generally make it easier (than spreadsheets do) to enforce referential integrity, proper data types, and other essential constraints.

[No comments] [Keywords: , , , , , ] [Permanent link]

I’ve just realeased version 1.0.0 of Tabulate, a WordPress plugin for working with data in a site’s MySQL database. I’ve been using it for a few months in production, and the shift from 0.* to 1.0 was fairly arbitrary — it just seemed stable enough now. The new feature that got included in this release is the ability to export to OpenStreetMap XML (not a great leap ahead of the KML export that was already done).

Any problems with Tabulate can be lodged on the issue tracker at Github, or on the normal WordPress support forum.

Here’s a suburb’s worth of power pole locations, exported from Tabulate and opened in JOSM:

Poles in Hamilton Hill


[No comments] [Keywords: , , , , , , , ] [Permanent link]

Just a note for my future reference: importing an Excel CSV into MySQL. The WKT column has been constructed by hand to be POINT(lng lat) and the CSV contains headers.

LOAD DATA INFILE '/full_path/to/file-on-server.csv'
INTO TABLE the_table
SET geographic_location = GeomFromText(@geographic_location)

[No comments] [Keywords: , , , , , , , , ] [Permanent link]

I’ve updated the Wikisource validated works’ category browser tool to include other languages. So far it’s just Italian, and to some perhaps-incorrect extent French (there’s only four? that’s not right).

I just need more Wikisources to tell me the names of their validated works and root categories, and it’ll just be a matter of adding these to the config to get them running.

The category list is updated weekly.

[No comments] [Keywords: , , , , , , , , ] [Permanent link]

A new Wikisource survey is being conducted!

During the survey, you will be asked questions regarding your personal involvement with the Wikisource project, your preferences regarding governance and technology, and your opinion on how a Wikisource Conference should be shaped. With the support of Wikimedia Österreich and Wikimedia Italia, a Project and Event Grant proposal is to be presented for such a conference. We would like to involve Wikisourcers in a joint venture both to spread knowledge about the project and to strengthen community bonds. This,

Read more: Wikisource needs your input « Wikimedia blog

[No comments] [Keywords: , , , ] [Permanent link]

My main woodworking toolbox has two runners inside, near the top edge, on which to slide a drawer. I put them in when I built the thing (I made them too long, or the lid props too long, or something too long, and had to chop a bit out of them so the lid would close; see at right. That’s irrelevant to the task at hand though.)

But I have no drawer — so, I’m making one. I’ve got a few odd bits of pine sitting around, mostly destined to be paint stirrers; I’ll bodge them together in a squarish shape, and my chisels and small things will have somewhere to be put.

The piece of 19×42 was a bit fat, or at least I thought it might look a bit odd next to the skinny walls made from the other pieces, so I ripped it in half.

Docked to length (with a few millimeters to spare for cutting off later), I then cleaned up the sawn surfaces (a bit; I’m not fussy, and sometimes like to see some saw marks). I usually work with Tas. Oak, and am always surprised at the soft squishiness of pine, and the speed with which it can be worked (or butchered, as one might say in this case).

The drawer bottom pieces were actually already within a gnat’s crotchet of where they needed to be, so I just planned their ends to get them squared up and the right length. The sides I then marked to length off the bottoms, because I really don’t care how big this thing is (it just has to fit itself).

I really should get around to making myself a bench hook or two; they’re far better than hanging things off the end of the bench. But I’m lazy; whenever I’ve got energy for woodwork, I want to get on with the thing at hand, and not get caught up in jigs and set-up and prep. A ridiculous, inaccurate attitude, I’m sure. It’s not like I get shit done anyway.

The time had come for beer, so that was procured (from a shockingly plastic homebrew bottle), and the glue-up commenced. It didn’t go right, at first, but I went and found a proper glass for it (and found my battery drill with a 1 mm bit), and after that the nails went straight and true and didn’t blow out the sides.

Probably, one should try to avoid blogging about gluing things together while actually doing it. But then, the computer was right there in the cupboard playing odd things from Radio Paradise, so it seemed easy enough. Got a bit of glue on the camera grip though.

The two short sides were next, being cut to length each to their own. They fitted with no dramas. By this time it was dark, and I was wondering what it would cost to get something more than a single fluro tube lighting my shed. Or even a new extension cord so I could run the computer, amp, and a desk lamp on my bench (radio takes precedence at the moment).

So, all done.

The album for all these photos is at photos.samwilson.id.au/index/category/222.

[No comments] [Keywords: , , , , , , , ] [Permanent link]