Sam's notebook

Shed doors April 17th, 2017, 5PM

Woodworking

My new house didn’t have a shed, but just a carport with no fourth wall (it was brilliant in every other respect, really—even insulated in the ceiling). So, as part of the WMF’s “Spark Project” (that aims to encourage employees to do more than just be wiki geeks), I decided to turn the carport into a shed by adding a set of wooden ledge-and-brace doors. There was a deadline of April 18 (i.e. tomorrow).

This post documents the process up to the point of being ready to hang the doors. Unfortunately, the hinges aren’t back from the galvanizer’s yet (or haven’t even been welded? Zoran the welder wasn’t communicating with me over the Easter break) so the project is incomplete; I’ll post more when the doors are up.

All of these photos and a few more are in a Flickr album.

Design

How wide is not wide enough, or what is the absolute minimum garage door size that will still fit a (small) car? I settled on 2.2 m, and subsequent testing has confirmed that this is fine for most cars—not that cars will be allowed in this shed, mind.

Some changes were made as construction progressed: the double studs either side of the door were turned 90° in order that the hinge bolts be able to add some extra joining strength between them; the sizing of all timber was adjusted to match what was available. Mostly things turned out as planned though.

Timber

Fremantle Timber Traders

I wasn’t sure what to build the doors with, but heading to Freo Timber Traders (above) and finding a couple of packs of nice old Wandoo settled it.

Selecting the boards

The 60×19 for the cladding came from a house in Wembley; the 110×28 for the ledges and braces came from an old shoe factory in Maylands. The ex-factory floor was covered in machine oil, and full of holes from where the machines had been bolted down. None were in any awkward spots though, and as I was planning on oiling the finished product I wasn’t too worried about the oil.

Doors

The first thing to do was to prepare the timber for the ledges and braces by removing the tongues and grooves with a draw-knife and plane (shown below). I wasn’t too worried about making these edges pristine or accurate; these are shed doors not furniture and I rather like the rough, used, look. It was also stinking hot while I was hacking away at these, and there’s something viscerally satisfying about draw-knives, sweat, and following the grain of the timber (and what shitty grain some of it was! But some, smooth as silk).

Using a draw-knife to remove the groove

The main joinery of the doors is the mortise-and-tenon joints at each end of the four 45° braces. These are what take the main load of the cladding hanging on the outside. (It’s worth noting here how common it is for this style of door to have their braces put on the wrong way around — the idea is that the brace is in compression and for it to go up from where the hinge attaches; if it’s running from the hinge point downwards then it’s pretty much doing nothing, and the door will sag.)

Cutting the tenon cheeks:

Cutting a tennon

Some tenons, with the ledges behind:

Ledges and braces, cut to size

The mortises were easier than the tenons in some way, although they took longer. Mortises, cut by hand as I was doing, are basically an exercise in holding a chisel vertical and square, thumping it with a fair bit of strength, and moving it 2 mm before repeating.

One end of each mortise is cut at 45° where the brace comes in; the other is square and is where the main force of the door is held.

Finished mortice, with 45° at one end
Laying out number two door
Laying out number two door

Once the ledges and braces were done, the cladding was screwed on from the back with 40 mm stainless steel decking screws.

Screwing the cladding on

The boards were spaced with 2 mm gaps to account for timber movement, to prevent the doors from warping. The ends were docked square and to size once all the boards were on.

Spacer between the boards

The finished doors:

Both doors finished

Walls

The two side walls are 2.1 m high and about 400 mm wide. They’re painted treated-pine stud frames clad with more 19×60 Wandoo flooring.

They’re fixed to the slab below:

Bottom plate bolted to slab

And screwed to the beam above:

Top stud fixings

(The threaded rod in the background of the above is a tie to hold the top beam in its place when the force of the open doors is tending to pull it outwards.)

The cladding was put on with the same spacing as the doors:

Cladding the side panels

And when completed, had the place looking a fair bit closer to enclosed:

Cladding the side panels

Incomplete

Unfortunately, this is where it stops for now, because I’m having some hinges fabricated and they’re not yet done. As soon as they are, and the thirty bolts are doing their thing, I’ll post some photos of the finished project.

(By the way, I am surprisingly grateful to the Spark Project initiative for making me get off my bum and actually get to work on these doors.)

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

Should Tabulate support ENUM columns? April 13th, 2017, 10AM

Programming

I’m trying to figure out if it’s worthwhile adding better support for enumerated fields in Tabulate. MySQL’s ENUM type is useful when one has an immutable list of options such as days of the week, seasons of the year, planets in the solar system, or suits in a deck of cards. It can also be good for making ternary options more distinct and communicable than a nullable boolean field.

But really, I’ve never used them! I mean, I have in one place (which is why this is coming up for me at all, because I’m trying to do some work with an ancient database that I’ve pulled into WordPress + Tabulate) but I’ve never used them in any situation that I couldn’t have more easily solved by adding a cross-reference to another table.

Reference tables are far easier to work with, and allow other metadata to be attached to the referenced values (such as colour, in the card-suit example).

However, ENUMs are already supported by Tabulate for the display of data, so I guess I should just do the little extra bit of work required to add support to the table-structure editing as well. Even if no one uses it.

(On a related note, I don’t think SET fields are going to get the same treatment!)

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

Returning (again) to WordPress March 20th, 2017, 10AM

Open content

Every few years I try to move my blog away from WordPress. I tried again earlier this year, but here I am back in WordPress before even a month has gone by! Basically, nothing is as conducive to writing for the web.

I love MediaWiki (which is what I shifted to this time; last time around it was Dokuwiki and for a brief period last year it was a wrapper for Pandoc that I’m calling markdownsite; there have been other systems too) but wikis really are general-purpose co-writing platforms, best for multiple users working on text that needs to be revised forever. Not random mutterings of that no one will ever read, let alone particularly need to edit on an on-going basis.

So WordPress it is, and it’s leading me to consider the various ‘streams’ of words that I use daily: email, photography, journal, calendar, and blog (I’ll not get into the horrendous topic of chat platforms). In the context of those streams, WordPress excels. So I’ll try it again, I think.

[One comment] [Keywords: , ] [Permanent link]

Editing MediaWiki pages in an external editor February 21st, 2017, 2PM

Programming

I’ve been working on a MediaWiki gadget lately, for editing Wikisource authors’ metadata without leaving the author page. It’s fun working with and learning more about OOjs-UI, but it’s also a pain because gadget code is kept in Javascript pages in the MediaWiki namespace, and so every single time you want to change something it’s a matter of saving the whole page, then clicking ‘edit’ again, and scrolling back down to find the spot you were at. The other end of things—the re-loading of whatever test page is running the gadget—is annoying and slow enough, without having to do much the same thing at the source end too.

So I’ve added a feature to the ExternalArticles extension that allows a whole directory full of text files to be imported at once (namespaces are handled as subdirectories). More importantly, it also ‘watches’ the directories and every time a file is updated (i.e. with Ctrl-S in a text editor or IDE) it is re-imported. So this means I can have MediaWiki:Gadget-Author.js and MediaWiki:Gadget-Author.css open in PhpStorm, and just edit from there. I even have these files open inside a MediaWiki project and so autocompletion and documentation look-up works as usual for all the library code. It’s even quite a speedy set-up, luckily: I haven’t yet noticed having to wait at any time between saving some code, alt-tabbing to the browser, and hitting F5.

I dare say my bodged-together script has many flaws, but it’s working for me for now!

[One comment] [Keywords: , , , ] [Permanent link]

New feature for ia-upload February 6th, 2017, 4PM

Open content Programming

I have been working on an addition to the IA Upload tool these last few days, and it’s ready for testing. Hopefully we’ll merge it tomorrow or the next day.

This is the first time I’ve done much work with the internal structure of DjVu files, and really it’s all been pretty straight-forward. A couple of odd bits about matching element and page names up between things, but once that was sorted it all seems to be working as it should.

It’s a shame that the Internet Archive has discontinued their production of DjVu files, but I guess they’ve got their reasons, and it’s not like anyone’s ever heard of DjVu anyway. I don’t suppose anyone other than Wikisource was using those files. Thankfully they’re still producing the DjVu XML that we need to make our own DjVus, and it sounds like they’re going to continue doing so (because they use the XML to produce the text versions of items).

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