+++*

Symbolic Forest

A homage to loading screens.

Blog : Post Category : Meta : Page 1

We can rebuild it! We have the technology! (part three)

Introducing Pug

If you want to start reading this series of articles from the start, the first part is here. In the previous part we discussed how I adapted Wintersmith to my purposes, adding extra page generators for different types of archive page, and refactoring them to make sure that I wasn’t repeating the same logic in multiple places, which is always a good process to follow on any sort of coding project. This post is about the templating language that Wintersmith uses, Pug. When I say “that Wintersmith uses”, incidentally, you should always add a “by default” rider, because as we saw previously adding support for something else generally wouldn’t be too hard to do.

In this case, though, I decided to stick with Pug because rather than being a general-purpose templating or macro language, it’s specifically tailored towards outputting HTML. If you’ve ever tried playing around with HTML itself, you’re probably aware that the structure of an HTML document (or the Document Object Model, as it’s known) has to form a tree of elements, but also that the developer is responsible for making sure that it actually is a valid tree by ending elements in the right order. In other words, when you write code that looks like this:

<section><article><h2>Post title</h2><p>Some <em>content</em> here.</p></article></section>

it’s the developer who is responsible for making sure that those </p>, </article> and </section> tags come in the right order; that the code ends its elements in reverse order to how they started. Because HTML doesn’t pay any attention to (most) white space, they have to be supplied. Pug, on the other hand, enforces correct indentation to represent the tree structure of the document, meaning that you can’t accidentally create a document that doesn’t have a valid structure. It might be the wrong structure, if you mess up your indentation, but that’s a separate issue. In Pug, the above line of HTML would look like this:

section
  article
    h2 Post title
    p Some
      em content
      | here.

You specify the content of an element by putting it on the same line or indenting the following line; elements are automatically closed when you reach a line with the same or less indentation. Note that Pug also assumes that the first word on each line will be an opening tag, and how we can suppress this assumption with the | symbol. You can supply attributes in brackets, so an <a href="target"> ... </a> element becomes a(href="target") ..., and Pug also has CSS-selector-style shortcuts for the class and id attributes, because they’re so commonly used. The HTML code

<section class="mainContent"><article id="post-94">...</article></section>

becomes this in Pug:

section.mainContent
  article#post-94 ...

So far so good; and I immediately cracked on with looking at the pages of the old Wordpress blog and converting the HTML of a typical page into Pug. Moreover, Pug also supports inheritance and mixins (a bit like functions), so I could repeat the exercise of refactoring common code into a single location. The vast majority of the template code for each type of page sits in a single layout.pug file, which is inherited by the templates for specific types of page. It defines a mixin called post() which takes the data structure of a single post as its argument and formats it. The template for single posts is reduced to just this:

extends layout
block append vars
  - subHeader = '';
block append title
  | #{ ' : ' + page.title }
block content
  +post(page)

The block keyword is used to either append to or overwrite specific regions of the primary layout.pug template. The content part of the home page template is just as straightforward:

extends layout
block content
  each article in articles
    +post(article)

I’ve omitted the biggest part of the home page template, which inserts the “Newer posts” and “Older posts” links at the bottom of the page; you can see though that for the content block, the only difference is that we iterate over a range of articles—chosen by the page generator function—and call the mixin for each one.

The great thing about Pug, though, is that it lets you drop out into JavaScript at any point to run bits of code, and when doing that, you don’t just have access to the data for the page it’s working on, you can see the full data model of the entire site. So this makes it easy to do things such as output the sidebar menus (I say sidebar; they’re at the bottom if you’re on mobile) with content that includes things like the number of posts in each month and each category. In the case of the tag cloud, it effectively has to put together a histogram of all of the tags on every post, which we can only do if we have sight of the entire model. It’s also really useful to be able to do little bits of data manipulation on the content before we output it, even if it’s effectively little cosmetic things. The mixin for each post contains the following Javascript, to process the post’s categories:

- if (!Array.isArray(thePost.metadata.categories)) thePost.metadata.categories = [ thePost.metadata.categories ]
- thePost.metadata.categories = Array.from(new Set(thePost.metadata.categories))

The - at the start of each line tells Pug that this is JavaScript code to be run, rather than template content; all this code does is tidy up the post’s category data a little, firstly by making sure the categories are an array, and secondly by removing any duplicates.

You can, however, get a bit carried away with the JavaScript you include in the template. My first complete design for the blog, it turned out, took something like 90 minutes to 2 hours to build the site on my puny laptop; not really helpful if you just want to knock off a quick blog post and upload it. That’s because all of the code I had written to generate the tag cloud, the monthly menus and the category menus, was in the template, so it was being re-computed over again for each page. If you assume that the time taken to generate all those menus is roughly proportional to the number of posts on the blog, O(n) in computer science terms (I haven’t really looked into it—it can’t be any better but it may indeed be worse) then the time taken to generate the whole blog becomes O(n2), which translates as “this doesn’t really scale very well”. The garden blog with its sixtyish posts so far was no problem; for this blog (over 750 posts and counting) it wasn’t really workable.

What’s the solution to this? Back to the Wintersmith code. All those menus are (at least with the present design) always going to contain the same data at any given time, so we only ever need to generate them once. So, I created another Wintersmith plugin, cacher.coffee. The JavaScript code I’d put into my layout templates was converted into CoffeeScript code, called from the plugin registration function. It doesn’t generate HTML itself; instead, it generates data structures containing all of the information in the menus. If you were to write it out as JSON it would look something like this:

"monthData": [
  { "url": "2020/10/", "name": "October 2020", "count": 4 },
  { "url": "2020/09/", "name": "September 2020", "count": 9 },
  ...
],
"categoryData": [
  { "name": "Artistic", "longer": "Posts categorised in Artistic", "count": 105 },
  ...
],
"tagData": [
  { "name": "archaeology", "count": 18, "fontSize": "0.83333" },
  { "name": "art", "count": 23, "fontSize": "0.97222" },
  ...
]

And so on; you get the idea. The template then just contains some very simple code that loops through these data structures and turns them into HTML in the appropriate way for each site. Doing this cut the build time down from up to two hours to around five minutes. It’s still not as quick to write a post here as it is with something like Wordpress, but five minutes is a liveable amount of overhead as far as I am concerned.

The Plain People Of The Internet: So, you’re saying you got it all wrong the first time? Wouldn’t it all have been fine from the start if you’d done it that way to begin with?

Well, yes and no. It would have been cleaner code from the start, that’s for certain; the faster code also has a much better logical structure, as it keeps the code that generates the semantic content at arm’s length from the code that handles the visual appearance, using the data structure above as a contract between the two. Loose coupling between components is, from an architectural point of view, nearly always preferable than tight coupling. On the other hand, one of the basic principles of agile development (in all its many and glorious forms) is: don’t write more code than you need. For a small side project like this blog, the best course of action is nearly always to write the simplest thing that will work, be aware than you’re now owing some technical debt, and come back to improve it later. The difficult thing in the commercial world is nearly always making sure that that last part actually happens, but for a site like this all you need is self-discipline and time.

That just about covers, I think, how I learned enough Pug to put together the templates for this site. We still haven’t covered, though, the layout itself, and all the important ancillary stuff you should never gloss over such as the build-deploy process and how it’s actually hosted. We’ll make a start on that in the next post in this series.

We can rebuild it! We have the technology! (part two)

In which we delve into Wintersmith and some CoffeeScript

Previously, I discussed some various possible ways to structure the coding of a website, and why I decided to rebuild this site around the static site generator Wintersmith. Today, it’s time to dive a little deeper into what that actually entailed. Don’t worry if you’re not a technical reader; I’ll try to keep it all fairly straightforward.

To produce this website using Wintersmith, there were essential four particular technologies I knew I’d need to know. Firstly, the basics: HTML and CSS, as if I was writing every single one of the four-thousand-odd HTML files that currently make up this website from scratch. We’ll probably come onto that in a later post. Second-and-thirdly, by default Wintersmith uses Markdown to turn content into HTML, and Pug as the basis for its page templates. Markdown I was fairly familiar with as it’s so widely used; Pug was something new to me. And finally, as I said before, Wintersmith itself is written using CoffeeScript. I was vaguely aware that, out of the box, Wintersmith’s blog template wouldn’t fully replicate all of Wordpress’s features and I’d probably need to extend it. That would involve writing code, and when you’re extending an existing system, it’s always a good idea to try to match that system’s coding style and idioms. However, I’d come across CoffeeScript briefly a few years ago, and if you’ve used JavaScript, CoffeeScript is fairly straightforward to comprehend.

The Plain People Of The Internet: Hang on a minute there, now! You told us up there at the top, you were going to keep all this nice and straightforward for us non-technical Plain People. This isn’t sounding very non-technical to us now.

Ah, but I promised I would try. And look, so far, all I’ve done is listed stuff and told you why I needed to use it.

The Plain People Of The Internet: You’re not going to be enticing people to this Wintersmith malarkey, though, are you? Us Plain People don’t want something that means we need to learn three different languages! We want something nice and simple with a box on-screen we can write words in!

Now, now. I was like you once. I didn’t spring into life fully-formed with a knowledge of JavaScript and an instinctive awareness of how to exit Vim. I, too, thought that life would be much easier with a box I could just enter text into and that would be that. The problem is, I’m a perfectionist and I like the site to look just right, and for that you need to have some knowledge of HTML, CSS and all that side of things anyway. If you want your site to do anything even slightly out-of-the-ordinary, you end up having to learn JavaScript. And once you know all this, and you’re happy you at least know some of it, then why not go the whole hog and start knocking together something with three different programming languages you only learned last week? You’ll never know unless you try.

The Plain People Of The Internet: Right. You’re not convincing me, though.

Well, just stick with it and we’ll see how it goes.

In any case, I had at least come across CoffeeScript before at work, even if I didn’t use it for very much. It went through a phase a few years ago, I think, of almost being the next big language in the front-end space; but unlike TypeScript, it didn’t quite make it, possibly because (also unlike TypeScript) it is just that bit too different to JavaScript and didn’t have quite so much energy behind it. However, it is essentially just a layer on top of JavaScript, and everything in CoffeeScript has a direct JavaScript equivalent, so even if the syntax seems a bit strange at points it’s never going to be conceptually too far away from the way that JavaScript handles something. The official website goes as far as to say:

Underneath that awkward Java-esque patina, JavaScript has always had a gorgeous heart. CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way.

Now if you ask me, that’s going a little bit far; but then, I don’t mind the “Java-esque patina” because the C-derived languages like C# and Java are the ones I’m happiest using anyway. CoffeeScript brings Python-style whitespace-significance to JavaScript: in other words, whereas in JavaScript the empty space and indentation in your code is just there to make it look pretty, in CoffeeScript it’s a significant part of the syntax. My own feeling on this, which might be controversial, is that the syntax of CoffeeScript is harder to read than the equivalent JavaScript. However, despite what some people will tell you, there’s no such thing as an objective viewpoint when it comes to language syntax; and as I said above, as Wintersmith is written in CoffeeScript, the best language to use to change and extend its behaviour is also CoffeeScript.

Wintersmith, indeed, is designed for its behaviour to be changeable and extendable. By default it only has a fairly small set of capabilities. It takes a “content tree”, a particular set of files and folders, and a set of templates. Markdown files in the content tree are converted to HTML, merged with a template, and written to an output file. JSON files are treated in almost the same way, almost as content files without any actual content aside from a block of metadata. Other filetypes, such as images, are copied through to the output unchanged. So, to take this article you’re reading as an example: it started out as a file called articles/we-can-rebuild-it-we-have-the-technology-part-two/index.md. That file starts with this metadata block, which as is normal for Markdown metadata, is in YAML:

---
title: We can rebuild it! We have the technology! (part two)
template: article.pug
date: 2020-09-28 20:09:00
...
---

I’ve configured Wintersmith to use a default output filename based on the date and title in the metadata of each article. This file, therefore, will be merged with the article.pug template and output as 2020/09/28/we-can-rebuild-it-we-have-the-technology-part-two/index.html, so its URI will nicely match the equivalent in Wordpress. So there you go, we have a page for each blog post, almost right out of the box.

That’s fine for individual article pages, but what about the home page of the blog? Well, Wintersmith is designed to use plugins for various things, including page generation; and if you create a new Wintersmith site using its blog template, you will get a file called paginator.coffee added to your site’s plugins folder, plus a reference in the site configuration file config.json to make sure it gets loaded.

"plugins": [
    "./plugins/paginator.coffee"
]

The code in paginator.coffee defines a class called PaginatorPage, which describes a page consisting of a group of articles. It then calls a Wintersmith API function called registerGenerator, to register a generator function. The generator function looks over every article in the content/articles folder, slices them up into blocks of your favoured articles-per-page value, and creates a PaginatorPage object for each block of articles. These are then output as index.html, page/2/index.html, page/3/index.html and so on. There, essentially, is the basis of a blog.

If you’ve used something like Wordpress, or if you’re a regular reader of this site, you’ll know most blogs have a bit more to them than that. They have features to categorise and file articles, such as categories and tags, and they also have date-based archives so it’s easy to, say, go and read everything posted in May 2008 or any other arbitrary month of your choice. Well, I thought, that’s straightforward. All we have to do there is to reuse the paginator.coffee plugin, and go in and fiddle with the code. So, I copied the logic from paginator.coffee and produced categoriser.coffee, archiver.coffee and tagulator.coffee to handle the different types of archive page. Pure copy-and-paste code would result in a lot of duplication, so to prevent that, I also created an additional “plugin” called common.coffee. Any code that is repeated across more than one of the page-generator plugins was pulled out into a function in common.coffee, so that then it can be called from anywhere in the generator code that needs it. Moreover, this blog and the garden blog are structured as separate Wintersmith sites, so I pulled out all of the CoffeeScript code (including the supplied but now much-altered paginator.coffee) into a separate shared directory tree, equally distant from either blog. The plugins section of the configuration file now looked like this:

"plugins": [
    "../shared/wintersmith/plugins/common.coffee",
    "../shared/wintersmith/plugins/paginator.coffee",
    "../shared/wintersmith/plugins/categoriser.coffee",
    "../shared/wintersmith/plugins/tagulator.coffee",
    "../shared/wintersmith/plugins/archiver.coffee"
]

The original paginator page generation function has now turned into the below: note how the only logic here is that which slices up the list of articles into pages, because everything else has been moved out into other functions. The getArticles function weeds out any maybe-articles that don’t meet the criteria for being an article properly, such as not having a template defined.

env.registerGenerator 'paginator', (contents, callback) ->
  articles = env.helpers.getArticles contents
  numPages = Math.ceil articles.length / options.perPage
  pages = []
  for i in [0...numPages]
    pageArticles = articles.slice i * options.perPage, (i + 1) * options.perPage
    pages.push new PaginatorPage i + 1, numPages, pageArticles
  env.helpers.pageLinker pages
  rv = env.helpers.addPagesToOutput pages, 'default'
  callback null, rv

This is the simplest of all the page-generators: the others have slightly more complex requirements, such as creating a fake “Uncategorised posts” category, or labelling the archive page for January 1970 as “Undated posts”.

There we go: my Wintersmith installations are now reproducing pretty much all of the different types of archive that Wordpress was handling dynamically for me before. The next time I come back to this topic, we’ll move onto the template side of things, including some nasty performance issues I found and then sorted out along the way.

The next part of this post, in which we discuss website templating using Pug, is here

We can rebuild it! We have the technology! (part one)

Or, how many different ways can you host a website?

I said the other day I’d write something about how I rebuilt the site, what choices I made and what coding was involved. I’ve a feeling this might end up stretched into a couple of posts or so, concentrating on different areas. We’ll start, though, by talking about the tech I used to redevelop the site with, and, indeed, how websites tend to be structured in general.

Back in the early days of the web, 25 or 30 years ago now, to create a website you wrote all your code into files and pushed it up to a web server. When a user went to the site, the server would send them exactly the files you’d written, and their browser would display them. The server didn’t do very much at all, and nor did the browser, but sites like this were a pain to maintain. If you look at this website, aside from the text in the middle you’re actually reading, there’s an awful lot of stuff which is the same on every page. We’ve got the header at the top and the sidebar down below (or over on the right, if you’re reading this on a desktop PC). Moreover, look at how we show the number of posts I’ve written each month, or the number in each category. One new post means every single page has to be updated with the new count. Websites from the early days of the web didn’t have that sort of feature, because they would have been ridiculous to maintain.

The previous version of this site used Wordpress, technology from the next generation onward. With Wordpress, the site’s files contain a whole load of code that’s actually run by the web server itself: most of it written by the Wordpress developers, some of it written by the site developer. The code contains templates that control how each kind of page on the site should look; the content itself sits in a database. Whenever someone loads a page from the website, the web server runs the code for that template; the code finds the right content in the database, merges the content into the template, and sends it back to the user. This is the way that most Content Management Systems (CMSes) work, and is really good if you want your site to include features that are dynamically-generated and potentially different on every request, like a “search this site” function. However, it means your webserver is doing much more work than if it’s just serving up static and unchanging files. Your database is doing a lot of work, too, potentially. Databases are seen as a bit of an arcane art by a lot of software developers; they tend to be a bit of a specialism in their own right, because they can be quite unintuitive to get the best performance from. The more sophisticated your database server is, the harder it is to tune it to get the best performance from it, because how the database is searching for your data tends to be unintuitive and opaque. This is a topic that deserves an essay in its own right; all you really need to know right now is that database code can have very different performance characteristics when run against different sizes of dataset, not just because the data is bigger, but because the database itself will decide to crack the problem in an entirely different way. Real-world corporate database tuning is a full-time job; at the other end of the scale, you are liable to find that as your Wordpress blog gets bigger as you add more posts to it, you suddenly pass a point where pages from your website become horribly slow to load, and unless you know how to tune the database manually yourself you’re not going to be able to do much about it.

I said that’s how most CMSes work, but it doesn’t have to be that way. If you’ve tried blogging yourself you might have heard of the Movable Type blogging platform. This can generate each page on request like Wordpress does, but in its original incarnation it didn’t support that. The software ran on the webserver like Wordpress does, but it wasn’t needed when a user viewed the website. Instead, whenever the blogger added a new post to the site, or edited an existing post, the Movable Type software would run and generate all of the possible pages that were available so they could be served as static pages. This takes a few minutes to do each time, but that’s a one-off cost that isn’t particularly important, whereas serving pages to users becomes very fast. Where this architecture falls down is if that costly regeneration process can be triggered by some sort of end-user action. If your site allows comments, and you put something comment-dependent into the on-every-page parts of your template - the number of comments received next to links to recent posts, for example - then only small changes in the behaviour of your end-users hugely increase the load on your site. I understand Movable Type does now support dynamically-generated pages as well, but I haven’t played with it for many years so can’t tell you how the two different architectures are integrated together.

Nowadays most heavily-used sites, including blogs, have moved towards what I supposed you could call a third generation of architectural style, which offloads the majority of the computing and rendering work onto the user’s browser. The code is largely written using JavaScript frameworks such as Facebook’s React, and on the server side you have a number of simple “microservices” each carefully tuned to do a specific task, often a particular database query. Your web browser will effectively download the template and run the template on your computer (or phone), calling back to the microservices to load each chunk of information. If I wrote this site using that sort of architecture, for example, you’d probably have separate microservice calls to load the list of posts to show, the post content (maybe one call, maybe one per post), the list of category links, the list of month links, the list of popular tags and the list of links to other sites. The template files themselves have gone full-circle: they’re statically-hosted files and the webserver sends them back just as they are. This is a really good system for busy, high-traffic sites. It will be how your bank’s website works, for example, or Facebook, Twitter and so on, because it’s much more straightforward to efficiently scale a site designed this way to process high levels of traffic. Industrial-strength hosting systems, like Amazon Web Services or Microsoft Azure, have moved in ways to make this architecture very efficiently hostable, too. On the downside, your device has to download a relatively large framework library, and run its code itself. It also then has to make a number of round-trips to the back-end microservices, which can take some time on a high-latency connection. This is why sometimes a website will start loading, but then you’ll just have the website’s own spinning wait icon in the middle of the screen.

Do I need something quite so heavily-engineered for this site? Probably not. It’s not as if this site is intended to be some kind of engineering portfolio; it’s also unlikely ever to get a huge amount of traffic. With any software project, one of the most important things to do to ensure success is to make sure you don’t get distracted from what your requirements actually are. The requirements for this site are, in no real order, to be cheap to run, easy to update, and fun for me to work on; which also implies I need to be able to just sit back and write, rather than spend long periods of time working on site administration or fighting with the sort of in-browser editor used by most CMS systems. Additionally, because this site does occasionally still get traffic to some of the posts I wrote years ago, if possible I want to make sure posts retain the same URLs as they did with Wordpress.

With all that in mind, I’ve gone for a “static site generator”. This architecture works in pretty much the same way as the older versions of Movable Type I described earlier, except that none of the code runs on the server. Instead, all the code is stored on my computer (well, I store it in source control, which is maybe a topic we’ll come back to at another time) and I run it on my computer, whenever I want to make a change to the site. That generates a folder full of files, and those files then all get uploaded to the server, just as if it was still 1995, except nowadays I can write myself a tool to automate it. This gives me a site that is hopefully blink-and-you’ll-miss-it fast for you to load (partly because I didn’t incorporate much code that runs on your machine), that I have full control over, and that can be hosted very cheaply.

There are a few static site generators you can choose from if you decide to go down this architectural path, assuming you don’t want to completely roll your own. The market leader is probably Gatsby, although it has recently had some well-publicised problems in its attempt to repeat Wordpress’s success in pivoting from being a code firm to a hosting firm. Other popular examples are Jekyll and Eleventy. I decided to go with a slightly less-fashionable but very flexible option, Wintersmith. It’s not as widely-used as the others, but it is very small and slim and easily extensible, which for me means that it’s more fun to play with and adapt, to tweak to get exactly the results I want rather than being forced into a path by what the software can do. As I said above, if you want your project to be successful, don’t be distracted away from what your requirements originally were.

The downside to Wintersmith, for me, is that it’s written in CoffeeScript, a language I don’t know particularly well. However, CoffeeScript code is arguably just a different syntax for writing JavaScript,* which I do know, so I realised at the start that if I did want to write new code, I could just do it in JavaScript anyway. If I familiarised myself with CoffeeScript along the way, so much the better. We’ll get into how I did that; how I built this site and wrote my own plugins for Wintersmith to do it, in the next part of this post.

The next part of this post, in which we discuss how to get Wintersmith to reproduce some of the features of Wordpress, is here

* This sort of distinction—is this a different language or is this just a dialect—is the sort of thing which causes controversies in software development almost as much as it does in the natural languages. However, CoffeeScript’s official website tries to avoid controversy by taking a clear line on this: “The golden rule of CoffeeScript is: ’it’s just JavaScript’”.

Relaunch!

It's a new day, and so on

Well, hello there! Time to start all this up again.

This blog has been dormant, for, what, the best part of a decade I think. I started a second blog all about gardening in the hope it would get me to write more in general, but this site stayed quiet. I started a Tumblr, and even managed to post things semi-occasionally, but that faded away much as the whole Tumblr community has faded too. I thought, though, midway through a rather unusual year, that it might be time to get this site going again.

My biggest motive this time, really, is that I don’t like the way the internet has been going over the past ten years ago. The old, open Web has been closing down, drifting instead toward megacorporation-owned walled gardens where you are trapped inside a corporate app that discourages you from leaving. When those walled gardens start to shrivel up and wither, what happens? Look at Facebook; look at Twitter; look at Tumblr and its steady decline. The days of the independent blogger are gone; most people now who do want to do some form of blogging will go to Wordpress.com, or Medium, or to a site like Dev.to if they’re technically minded. So me, being contrarian, decided to become an independent blogger once again.

A few things have changed. I’ve redone the design to hopefully look reasonable on a phone, because that’s what most people use for their casual reading nowadays. I’ve taken away comments, for a few reasons: it saves me the effort of worrying when people leave controversial ones, and it saves me the sadness when they inevitably don’t leave any at all. On the technical side, I’ve ported everything over to a static site generator, so everything loads in a flash. At some point I’ll write…

The Plain People Of The Internet: My lords! Will they eversomuch be bothered about all that technical gubbins? Or is it all so much tumty-tumty verbiage, like?

Me: I wondered if you lads were still around, you know. I’m sure some people might be interested.

The Plain People Of The Internet: Lads? Lads? Now there’s not very inclusive of you, is it.

Me: Fair point, Plain People.

As I was saying, I’m sure some people out there will be interested in long technical posts about how the site is now built and structured, and although most of my technically-minded blog posts end up on my employer’s website nowadays, it may well be that some technical topics are more suited to this place. In general I suspect there will end up being more of the longer, more considered essay-type posts on here, and fewer of the one-liner posts about how I don’t have anything to say. And, as you’ve already seen, I’m sure that if my meanderings start to become too diffuse and unfocused, they will be interrupted by the Plain People Of The Internet, who at some point in the distant past escaped from a Flann O’Brien newspaper column and now seem to live somewhere in the collective hive-mind of the global internetwork.

The Plain People Of The Internet: Now there’s a word you don’t hear very often. Fair rolls off the tongue.

A whole load of the aforementioned one-liner posts have already been culled from the archives. This isn’t exactly the British Library or some great tome of record, so I’ve removed things from back in the mists of time where I was only posting to meet some arbitrary and self-imposed target of posting on a certain schedule. I’ve also gone through and cleared out a whole heap of dead links, and spotted a host of spelling mistakes that have been sitting there out in the open for everyone to see for years. There are probably many more dead links I missed checking, and many more spelling mistakes I’m still to notice, but I’m reasonably happy with the state of things as they stand. As well as deleting a pile of stuff that was here previously, I’ve also added stuff that I’d previously posted to Tumblr, such as my thoughts on what Amsterdam is like, or the experience of watching my father die. Hopefully, some people other than me will think these things were worth saving.

I’m aware that previously I’ve posted things that say: “Well, hello there! Time to start all this up again,” and then have stuttered slowly to a stop within a few days or weeks. Let’s see how it goes this time.

The Plain People Of The Internet: By sure, we will.

The Writer's Voice

In which FP reads, and learns more about writing as a result

Writing this post from the other week, with its long rant about the poor quality of the worldbuilding in BBC3’s Being Human, has made me think more in general about the quality of writing, and the quality of my own writing. After all, am I in a position to excoriate other people’s ability to write and worldbuild, when I don’t exactly have much to demonstrate on my own behalf there?

It set my brain off on a tangent, though. Not so much about worldbuilding, but about the authorial voice. Because that’s something I used to worry about, years back: I would never be any good at writing because I didn’t have my own voice. If you read any of my prose, there would be nothing at all distinctive about it. Whether that was true back then, back when I used to worry about such things, I don’t know, and I have no real desire to go back and read anything that old. It probably isn’t true any more, though. Certainly, one of the things K likes about my blog posts is that, she says, in my writing I sound just as I do when I speak.

I’ve been a reader since I was small: I’ve been able to read since before memory, since before virtually all of my memories, so I have no conception of what it feels like to see words and not understand them. Ever since I started reading for myself, though, I’ve been a silent reader, a very quick reader, and I also tend to be a very poor reader. Because I’m a quick reader I skim too much. I miss things. I miss things out, have to go back, don’t notice Important Plot Points and don’t take in any of the craft involved in the work. However, I think I’ve found a solution to this. I’ve started reading things aloud, and it has turned around the way I look at writing.

What started all this was: I’d just started reading a book I’ve had sitting around unread for a couple of years almost, Wolf Hall by Hilary Mantel.* Only on the second or third chapter, we had to take a plane journey, and K didn’t have anything interesting herself to read. “Read to me?” she asked. So, since, I’ve been reading a passage of Wolf Hall to her in bed every evening. It’s been a couple of months now; reading aloud is much slower than reading silently, and we’re not awake enough for a chapter** every single night. In doing it, I’ve learned a lot about syntax, prosody, and prosody’s representation. Hilary Mantel has been one of my favourite novelists for many years now,*** and Wolf Hall, award-winning and all, is very readable, but it’s not always the easiest novel to read aloud. Its long sentences are just slightly too long for comfort in the voice: lists of things, and there are many lists of things, always have one term too many to easily read aloud. Her authorial voice is very readable, very concise and very accessible, but her sentences are sometimes a little too long to know automatically where the stresses are intended to fall. Which isn’t to deny that it is, absolutely, an excellent novel; it just isn’t perfect for me to read aloud, at least not without a rehearsal.

Wolf Hall‘s sequel will be coming out before too long, and no doubt will be something I will read to K at some point. In the meantime, we are assembling a list of books to be read: The Third Policeman after last week’s opera;**** some Peter Ackroyd, such as Dan Leno And The Limehouse Golem; maybe Lanark, although that will be a mammoth adventure. In the meantime, I am taking a lot from reading aloud. It makes me confident that I do have a voice when I write, a voice I can manipulate if I want to. It makes me confident, too, that I have a readable voice, a voice that might be publishable. Most importantly, it has helped an awful lot to reconnect the craft of writing with the act of reading. The two, obviously, are very closely linked; but I think I’d forgotten just how closely linked they are. I think I’d forgotten to write for the reader.

* I can tell you where I started reading it, too: waiting for a train in Frankfurt an der Oder.

** Strictly speaking, it would be very hard to read a chapter every night, because Wolf Hall has very uneven chapter lengths. Some are getting on for a hundred pages of the book; others are no more than two or three.

*** At root, her earlier historical novel about the lives of Robespierre, Danton and Desmoulins is one of the things to blame for the time I got myself on the telly the other year.

**** Tricky, with all its footnotes.

The Extension

In which an annex is announced

As you can see, as I’ve mentioned more than a few times already, this site has been fairly quiet for the past few months, since we’ve moved house. We’ve come up with a cunning solution, though. Start another blog!

It’s not really a separate blog; it’s more of an annex to this one. A separate side-project, with rather more of a focus than this rambling monstrosity,* with a specific topic, rather than whatever I can conjure up to make 500 words of. The idea being, a narrower topic will make ideas come more easily. It is: The Symbolic Forest Gardenblog.

Gardening posts on this site — all none of them — will now appear over on the gardening blog. Gardening-related photos will pop up over there too. Anything I write that isn’t about gardening, that will still be over here. Keeping it in this domain might end up a bit confusing, because forest gardening is a recognised genre that is almost entirely unlike our garden so far. Hopefully readers will pick up that it’s the Symbolic Forest Gardenblog, not the Symbolic Forest Gardenblog.

* and it’s not going to have footnotes, either.

Suddenly, half a year

Or, time to exercise

Well, hello again. Apparently, it’s summer.

Regularly, I do get urges to come back to the Admin Interface and write a bit more prose-doodling for this website. There are so many other things to do that keep me occupied, though. Now it’s summertime, the garden at Symbolic Towers is lush and green, and instead of getting on with things indoors you can regularly find me outside, hiding behind the Bee House,* pottering around the garden, deadheading the marigolds and worrying about the effect of leafhoppers on the potato harvest. As the gardens at Symbolic Towers are barely the size of a damselfly’s bandana, though, I am usually easy to spot.

Checking back, I’ve just realised that the entries on the main page still include things I wrote over a year ago now – for example, you can still see the ice monster we defeated when we moved house, down below this one. It’s not very good performance, for a blog that was originally started with the aim of posting every weekday. There are, however, more things in my head that I do plan to write about, some time over the next few months. Maybe I’ll actually manage them at some point. If nothing else, I should start posting pictures of the verdant garden, before it stops being verdant and crumbles back into autumn mulch. The pea plants are already starting to look a bit mildewed.

Lots has been in the news in the past few months about exams: about exam boards getting the questions wrong, about teenagers staring down baffled at unanswerable questions, and then about kids and parents complaining that they don’t want to be marked down for the question-setters’ mistakes. I have to say, my first thought was: surely, this is a learning experience? One of the first tips I was taught at school was: exam questions, numerically-based ones, are usually carefully worked out so that you’ll get nice neat answers at the end. The real world, of course, doesn’t work like that. When you’ve left school, you’ll find out that real world questions don’t have nice neat answers, and that often people will ask you things that are unanswerable, or insoluble with the information you have. Discovering that fact in the middle of an exam is probably a very good place to learn it. Possibly, this is why I should never become a teacher.

For now, that will do for a blog post. I will come back and try to write more in a few days; get my writing muscles unstiffened and flexible again. Because, as anybody who’s ever tried it knows, the more you write the more you want to write.

* Not one of those big boxes you use to house domesticated, sociable bees in the hope you can steal their honey, but a boarding-house for antisocial solitary bees. None have, as yet, taken up residence, but neverless I always check.

With Difficulty

In which we muse on how hard it is to write something with all the distractions the modern world has to offer

There’s one big problem with computers and pervasive connectivity. The problem is: it’s all at your fingertips. Which means, when you sit down to do some work, it’s all too easy to realise that there are other things you’d rather be doing; and there are a lot that can be done there and then.

In a lot of cases that’s straightforward to solve: disconnect yourself. It’s a bit trickier, though, when it comes to writing blog posts. Particularly, the sort of blog posts that need fact-checking, more information, and so on. Once you have to start doing that, you start getting sidetracked down a line of “research” which is very interesting and distracting, but doesn’t really help you with getting your blog post written. The inspiration fades away amid a mass of non-information.

What I’m going to have to do, I think, in order to get this process going properly again, is to make more notes. Get a notebook, and find a place far away from the internet. Hide my phone. Lie back in bed, maybe, and write my posts with pen and paper first. And after that, put all the links in and do the fact-checking, after the text is already down. It all goes back to something I wrote a long time back, wondering if having a Blog Editor would improve the quality of this blog. An independent Blog Editor is highly unlikely to appear, so I have to fulfil both roles myself; but if I do try to explicitly divide writing time and editing time, then maybe much more will get done.

Strange Loop

In which things get into a circular reference

Things go around in circles. This site has been quiet for a while in the past, more than once, and it will probably happen again in the future at some point. I can’t tell when, but it will probably happen.

Still, a new year is as good a time for a new start as any, even though I try not to believe in arbitrary starting-points. It’s hard to avoid it at this time of year, though: forced to stay away from work, expected to visit the family, exchange gifts, rest for a week and recover ready for the new year’s start. I’ve been staying in and reading one of the books I received for Christmas: Gödel, Escher, Bach: an Eternal Golden Braid, by Douglas Hofstadter. It’s a long book, a complex book, and I haven’t finished it yet: but its essence is in loops, looping, and self-referentiality. How self-referentiality is necessary, as a minimum, before self-awareness can occur. It seems like an ideal thing to talk about on a blog which has always been highly aware that it’s a blog, but I’m not sure if I’ve taken in enough of the book to write about it yet. “It’s got a lot of equations in it,” said The Mother, giving it to me. It does have, true; it also has some truly awful puns, intertwined and nested ideas, and dialogues between fictional and/or appropriated characters who butt into the discussion on a regular basis.

Funnily enough, a letter came the other day from regular reader E. Shrdlu of Clacton-on-Sea…

The Plain People Of The Internet: Hurrah! We were wondering when that chap would pop up again. We were worried he’d got stuck putting shapes into boxes, or analysing what kind of linoleum he has in his kitchen.

Hush, you. As I was saying, a letter came, from semi-regular reader E. Shrdlu of Clacton-on-Sea:

“Gödel, Escher, Bach” is quite a work to try to emulate, isn’t it? Maybe you should try something simpler. Never mind the parallels between human consciousness, a baroque composer and a 20th-century artist: have you thought about the links between something simpler, like TV ghost stories and the British railway preservation movement? Or maybe: the parallels between the work of Robert Graves and books like “Holy Blood, Holy Grail”. Something nice and straightforward like that.

It’s an interesting idea there. Maybe I should indeed be starting off along those lines. Over the next few weeks and months, I’ll be writing a critique of a piece of writing I read for the first time a few days ago. It starts like this:

Things go around in circles. This site has been quiet for a while in the past, more than once, and it will probably happen again in the future at some point. I can’t tell when, but it will probably happen.

Still, a new year is as good a time for a new start as any, even though I try not to believe in arbitrary starting-points…

Somehow, I think I might be onto something.

Recent Search Requests

In which we know what you’re looking for

From the past month or so:

1/64 scale castle. 1/64 scale is also known as “S Gauge” in the model train world. I have some photos of an S gauge model train on here; no castles, though.
addicted to prostitutes grimsby. I’ve seen what Grimsby prostitutes are like generally, and, well, grim is the word.
describe a seaside town in winter. “Grey” would be a good start, usually.
did horne and corden write there new sketch show?. If they didn’t, they should consider asking for a discount next time.
evening post crash bedminster. The junction of Winterstoke Road and Bedminster Down Road is still covered in flowers and mementos, after a woman died when a car crashed into a stone wall there late one night recently. I should pop down and take photos of it all before it rots away.
finding a deat bat meaning and symbolism. Well, I know what to do when you find a dead bat on your doorstep, if you’re British at least. Its meaning: erm, the cat managed to kill a bat, I think. As for symbolism, I’m at a bit of a loss.
mark bradshaw replacement bedminster surely has to be a bit of wishful thinking, because it’s a couple of years until Bradshaw (one of Bedminster’s city councillors) is up for re-election. He’s recently been tipped as an ideal Bristol Labour leader, although his pet projects have a reputation for releasing misleading press releases.
men diamler did a very good performance and DJ set at The Cube on New Years Eve, despite being (by his own admission) the most alcohol-infused act of the evening, as I mentioned at the time. Still, as I said: rather good.
naked forestmen. That’s enough Recent Search Requests, I think.