As part of our ongoing efforts to improve the pub, we needed more space to store our beer.

A small space

For years, we’ve struggled with an undersized cold store for our beer. When I say undersized, what I mean is that we are constantly brewing “just in time” to ensure there’s enough space for the newly brewed beer. The beer store can hold a maximum of about two brews of beer.

Because the beer store is so small, whenever a new batch of beer is ready, we have to unload everything to get the new stuff in. This is basic stock rotation. However, when you’re dealing with 9, 18 and 36 gallon barrels, this can be a lot of hard, heavy lifting.

In addition to all this work rotating stock, the lack of space means we are limited to what we can brew. It makes it difficult for us to make a strong dark winter special, ideally brewed months in advance, because of the precious space it occupies. It also means that our brew schedule is strictly dictated by demand from the pub. Planning around this and taking holiday is hard.

Towards a solution

For the last year or so, we’ve been thinking seriously about what could be done. My father’s workshop, located next to the brewery, seemed to be the ideal space. It receives a lot less direct sun than the current beer store, and has the potential to be much better insulated. It just needed decluttering. Years of accumulated odds and sods from the pub and brewery needed organising, giving away, selling, throwing away, repurposing. Over the course of several weeks in autumn 2021 we did this, and at the same time we planning how to use the space.

Between the brewery team, we came up with a plan to split the space into thirds, allowing the leftmost third as space for the cold store.

Peter Fisher from ACM Ltd, based in Norwich, came to visit us and from our conversations sketched a design.

We sat on this, happy with the design. The quote seemed reasonable, but was on the high end of what we were able to afford. We were trying to figure out how to make it work.

A timely email

Then in September, through Bungay Events and Business Association, I received an email advising me that East Suffolk Council had launched a new grant for businesses affected by Covid-19 restrictions. This “Plan for the Future” grant scheme seemed to be a really good match for our beer store project:

Businesses which are looking to bring forward investment projects that will have a significant impact on their business will be able to apply for grants of between £5,000 and £25,000 to help support their projects.

I sent an email to East Suffolk council and within hours Margaret Oakley at the New Anglia Growth Hub had responded with some registration forms, helpfully partially completed based on the information they already held about us. The forms themselves do ask for quite a bit of detail, but Margaret responded very quickly to all my queries.

By the following day the registration forms had been completed I was assigned a growth advisor, Robert Turnbull, also at the New Anglia Growth Hub. Robert called me that day, and we had a long chat about the project. Robert listened carefully and was able offer excellent advice on how to complete the application form. Again, the form required some technical detail, and in every case Robert was able to provide a clear and concise answer on how to complete it.

Over the course the next few weeks, working through the details of the application form - figures from my accountant, how much state aid we’d already received, turnover, balance sheet, etc - I finally managed to complete the final bits and submit our application on October 1st. A couple of weeks later, on the 15th of October, our application was approved!

A small rethink

Once the grant application was approved, we knew we’d be okay to schedule the work. With that in mind, we had another look at our plans.

A local refrigeration engineer, and a regular at the pub, Bo came to look at the space. Bo is an expert in this field and has been working with refrigerated spaces for years. He advised us to try to envisage exactly how we would use the cold room. This exercise proved invaluable.

Along with my father, Digby and Luke, we started pacing the space out, laying it out with masking tape on the floor, shifting versions of where the barrels would go.

One of the biggest problems with the existing beer store is that once it starts to get full, there’s really no room to move around. When we started looking at the space with these barrels in place, we realised that having 3 sliding doors would not only overcomplicated things, it resulted in multiple “channels” that did not make the best use of the space.

After thinking things through, we asked Peter to come back and consider a plan using the rear half of the workshop instead of just the leftmost third. This would mean we could get away with only one large sliding door instead of three smaller ones, and would give us a lot more usable space. In retrospect, I believe this was the correct choice - it’s a much better design overall.

A job well done

In the second week of December, ACM send their team to install the cold room. They work very quickly and professionally, completely nearly all of the work in 2 days. A week later, Beeline Refrigeration come and install the cooler and LED illumination. The only thing left to install is the door, a 1500mm wide custom built sliding door made from foam covered with sheet steel and PVC. ACM return a few days later and install it.

Overall, I’m very happy with the result. The workmanship is of the highest quality and the additional breathing room it gives us means that there is much less work moving barrels as part of the stock rotation. Now, with the larger beer store, we can potentially look at slightly increasing production - perhaps producing a kegged product to sit alongside the craft kegged beers that we have been buy in as part of our ever-changing craft beer selection at the pub. This will not only make us more competitive, but will create a product that’s brewed onsite instead of couriered to the pub.

Thanks to East Suffolk for the Plan to the Future Grant, and the New Anglia Growth Hub for being so helpful during the application process. Thanks to ACM and Beeline for their patience and professionalism throughout the build process.

In April 2021, at great expense, we bought an Airack glass dryer for the pub. This was after months or years of mysteriously occasionally flat-looking pints of lager. The topic comes up frequently on the Pub Owner’s Network, and one of the common responses suggests buying an Airack. They’re expensive - around £500.

After a series of experiments which involved pouring lager into a series of wet, dry, and nearly dry glasses. We tried varying the temperature of the glass. What we found was that unless the glass is completely dry, the nucleation site at the bottom can sometimes (but not always) fail to produce bubbles. The effect is most pronounced in tall, narrow “continental” style glasses, which presumably dry slower due to reduced air flow. We tried briefly using a battery-powered fan to dry the glasses with limited success.

Enter the Airack

Enter the Airack by Clenaware Systems, a box with a fan and a bunch of holes. You put the glasses on top, twist a timer knob, and ambient temperature air is blown into the glasses. After about 5 minutes, they’re completely dry.

The short story is that it works. We haven’t had any problems with lager since. The downside is that it’s a relatively expensive machine: we paid £509.99 including VAT and delivery from Barcare Supreme Limited. It comes with a 1 year warranty on parts and labour, although I’m led to believe that Airack will increase their warranty to 2 years if you leave a Google review.

In 2015, JavaScript introduced async keyword which allows functions to await on promises, causing execution of the current context to pause until the promise resolves or rejects. The older way of handling promises them using then and catch introduced an additional level of nesting.

It’s reasonable to expect that Express handles traditional errors and rejected promises (and thrown errors within an async function) the same way. Unfortunately, Express v4 has a gotcha where rejected promises in an async function require additional treatment.

Synchronous errors

In the following typical Express request handler, the doSomething function throws an error.

app.get("/sync-example", (req, res) => {
  doSomething();
  res.status(200).send("OK");
});

What happens when a client makes a request to this endpoint?

curl -v localhost:3000/sync-example
*   Trying ::1:3000...
* Connected to localhost (::1) port 3000 (#0)
> GET /sync-example HTTP/1.1
...
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 500 Internal Server Error
...
<
... Stack trace rendered as HTML ...
* Connection #0 to host localhost left intact

The following happens:

1. The server responds with a 500 error.
2. The client receives a stack trace rendered as HTML.
3. The server continues serving request.

Note that setting NODE_ENV to production causes Express to return less verbose error messages.

Asynchronous Errors

What happens when we try the same thing with an asynchronous request handler?

Express request handlers are just functions, so of course it is possible to use an async function as a request handler:

app.get("/async-example", async (req, res) => {
  await asyncDoSomething();
  res.status(200).send("OK");
});

When I tested, using Node v17.3.0 and Express 4.17.1, Node crashed with the following error:

/Users/jp/example/index-2.js:22
  throw new Error("Something went wrong.");
        ^

Error: Something went wrong.
    at asyncDoSomething (/Users/jp/example/index-2.js:22:9)
    at /Users/jp/example/index-2.js:26:9
    at Layer.handle [as handle_request] (/Users/jp/example/node_modules/express/lib/router/layer.js:95:5)
    at next (/Users/jp/example/node_modules/express/lib/router/route.js:137:13)
    at Route.dispatch (/Users/jp/example/node_modules/express/lib/router/route.js:112:3)
    at Layer.handle [as handle_request] (/Users/jp/example/node_modules/express/lib/router/layer.js:95:5)
    at /Users/jp/example/node_modules/express/lib/router/index.js:281:22
    at Function.process_params (/Users/jp/example/node_modules/express/lib/router/index.js:335:12)
    at next (/Users/jp/example/node_modules/express/lib/router/index.js:275:10)
    at expressInit (/Users/jp/example/node_modules/express/lib/middleware/init.js:40:5)

Node.js v17.3.0

And the client received an empty response.

Async Handler to the rescue

The Express error handling documentation takes pains to describe how rejected promises must be handled by calling next(err). Of course, this is quite verbose and also requires the programmer to catch every single rejected promise error (in contrast to how synchronous errors are handled).

The documentation states that Express version 5 will fix this. Express v5 has been in development since July 2014, and does not have an expected release date.

Fortunately, an npm package exists that fixes all this: express-async-handler.

In order to use it, you need to wrap all your async requests in a function call:

app.get(
  "/async-example",
  asyncHandler(async (req, res) => {
    await asyncDoSomething();
    res.status(200).send("OK");
  })
);

This is quite straightforward, but it adds unnecessary boilerplate and is quite prone to forgetting to wrap everything.

I would much prefer this behaviour to built into Express, and I have expressed this sentiment on GitHub. Such small, fundamental, libraries should really be part of core framework in order to minimise risk of left-pad type incidents.

For context, express-async-handler is 8 lines of code and Express has 12.5 million weekly downloads.

Testing with Express version 5.0

In order to test the updated behaviour in Express 5.0, I updated my package.json:

  "dependencies": {
    "express": "git+https://github.com/expressjs/express.git#7bca2737d207189e6df65d1fee6fc735d370114e"
  },

And re-ran my test with the original unwrapped code.

app.get("/async-example", asyncHandler(async (req, res) => {
  await asyncDoSomething();
  res.status(200).send("OK");
}));

$ curl -v localhost:3000/async-example

With Express v5.0 the behaviour is the same as synchronous errors in v4.x, that is:

• The client receives a 500 response and an HTML-formatted stack trace.
• The node process does not exit, instead an error and stack trace are shown.

https://github.com/bootstrap-vue/bootstrap-vue is a component library for Vue.js that wraps and extends Bootstrap components for use in Vue.js-based web applications. It has components for buttons, tables, modals, tabs and loads more. The documentation is very good, and despite using it extensively I have encountered very few problems. It’s a library that I often use in my projects, and use throughout my ePOS software Little Till.

For a while, the maintenance status of Bootstrap-Vue has been in question. Regular contributions stopped in early 2021, with the the original author, Pooya Parsa’s last contribution in May 2019. Latterly Jacob Müller made a lot of contributions, but has not been a regular presence since early 2021.

Boostrap-Vue has roughly 200,000 weekly downloads via npm.

Support for newer technologies

The biggest question are around support for newer Vue and Bootstrap libraries. Bootstrap-Vue requires Vue 2 and wraps Bootstrap v4, but newer versions of Vue and Bootstrap are now available.

Vue 3 has been available for some time, but the Vue team are a bit unclear about its status. As of January 1 2022, the documentation says this:

All of our official libraries and tools now support Vue 3, but some of them are still in beta or release candidate status.

Bootstrap v5 was marked as stable on May 5 2021.

Getting by in the dark

Throughout 2021 there was a lack of clarity regarding the future of Bootstrap-Vue. There are issues about this on GitHub (5507 5196) without any satisfactory resolution. The most active maintainer, Hiws, has been praised for providing helpful answers on GitHub and actively helping out on on the Bootstrap-Vue Discord. However, Hiws has stated clearly that he’s not interested in managing pull-requests or other code-based maintenance.

In response to discussions around Vue 3 and Bootsrap v5 support, Jacob Müller said in April 2021:

BootstrapVue is still maintained and will have Vue 3 and Bootstrap 5 support in the future. There will not be ETAs in the near future but it will definitely happen.

Sadly, that development work was never done and Hiws has had to repeatedly explain to people that the repository is unmaintained. In November, on Discord, Hiws said:

i tried pushing the maintainers back in april/may to put out a “The project is no longer actively maintained”, so people wouldn’t be waiting around for new updates and Vue 3 support when it was likely never coming any time soon. But i kept getting told “We will start again soon”, but soon never happened.

Without input from either Pooya Parsa or Jacob Müller very little has happened and the conversations did not lead far. Even with a potential budget of roughly $20,000 raised using OpenCollective, there was nobody to take the lead on the project.

Bring on the forks

As often happens when a beloved open source project is clearly abandoned, forks spring up.

Here’s a list of the forks that I am aware of.

Illya Klymov’s fork targeting Vue 3’s Migration Build, with Bootstrap v4, created in November 2021 - discussed here: https://github.com/xanf/bootstrap-vue/tree/vue3-compat-build

Carlos Bonadeo’s fork targeting Vue 3, Boostrap v5 and Typescript: https://github.com/cdmoro/bootstrap-vue-3

Carlos’s fork appears to be a complete rewrite that attempts to match the Bootstrap-Vue API. It’s documentation states NOT PRODUCTION READY and critically it appears to be missing a table component.

Also of note is a recently released library targeting Bootstrap v5 and Vue 3, but which does not appear to attempt any API compatibility with the original Bootstrap-Vue project: https://coreui.io/bootstrap-vue/.

In my view, given that there is no attempt to maintain API compatibility with Bootstrap-Vue, it is confusing that CoreUI have decided use this name, even if it’s the most obvious choice for a project combining Bootstrap and Vue.

A new era dawns

Things took a more positive turn on 14 December 2021 when Pooya resurfaced with this comment:

Thanks for starting to work on vue3 support @xanf @cdmoro 💚 If you would like to dedicate more time, I can invite you to org, and also we have funds available in open-collective.

Subsequently Carlos Bonadeo (cdmoro) and Illya Klymov (xanf) were made maintainers of the Bootstrap-Vue repository. Since then Illya has got on with some basic tidy up and merging of simple pull requests.

The latest update is contained in this pinned issue: https://github.com/bootstrap-vue/bootstrap-vue/issues/6872

TL; DR

New maintainers are here

Pull requests will be reviewed within several days

There will be a new release of bootstrap-vue coming with fixes included

Primary goal of the team is to rewrite bootstrap-vue to support Vue 3 and Bootstrap v5. We will do this in a separate repository. We will announce the detailed roadmap for a rewrite as soon as we have it

I occasionally do iOS application development, and in some cases want to test the application on my phone.

I have an iPhone XS and a 2015 Macbook Pro.

I am afflicted by the issue described here: https://www.ifixit.com/Answers/View/473839/iOS+devices+connecting+and+disconnecting+rapidly.

That is, when I connect my iPhone to my laptop via USB the computer shows the iPhone connecting and disconnecting rapidly. This makes it impossible to use as a test device.

I have tried, without success:

• Using different cables, including genuine Apple ones.
• Using both USB ports on the laptop.

What works reliably is using a powered USB hub. But carrying one of those around is inconvenient, and I don’t have one with me now.

The solutions listed in the thread include:

• Trying a different cable.
• Force quitting the usbd process.
• Performing an SMC reset.
• Charging phone to 100%.

I recall that force quitting usbd has worked for me in the past, but does not seem to work now. Force quitting usbd via activity monitor causes my phone to disappear from the Device Setup screen, and replugging causes the repeated disconnected behaviour to resume.

A solution

I ran the following in the terminal:

sudo killall -STOP -c usbd

And noticed that although the Device Setup screen didn’t list my phone, the Next button was still enabled. Clicking Next allowed me to build and run my app on my phone.

Running this command from the command line should do the same thing as force quit in activity monitor. More testing is required to see whether using force quit in activity monitor allows this behaviour.

When pasting screenshots from Mac OS, they are shown at 2x resolution in Joplin (and in rendered GitHub pages) since that’s how Mac OS captures them on a retina screen.

If you take a screenshot on Mac OS and open Preview, then create a new document with the contents of the clipboard, the resulting .png file will be twice the width and twice the height of the original screenshot.

Critically though, when pasting into Preview, Mac OS recognises that the Image DPI is 144 pixels/inch (instead of the regular 72 pixels/inch).

Here’s a 70 x 70 screenshot I took:

Pasting into Preview the Info panel shows a 140 x 140 pixel image, but recognizes the image DPI.

Opening the image after it has been pasted into Joplin (by right clicking on the image and selecting Reveal file in Finder) shows that the image DPI information has been lost.

TL ; DR

It seems like Electron, on which Joplin is based, does not preserve image EXIF data when reading from the Clipboard.

There is some ongoing work to improve Electron’s clipboard API which may address this issue: https://github.com/electron/governance/pull/454

The above pull request references the following issue, created in April 2020 by fabiospampinato (author of Notable) that requests better support for reading images from the clipboard. https://github.com/electron/electron/issues/23156

Potential Solutions

Some thoughts on how to address this issue.

Find a screenshot app that rescales screenshots

It’s likely that an app exists on Mac OS that will take and rescale screenshots automatically.

See whether Joplin can identify high-DPI screenshots

Perhaps Joplin could intercept the paste command and rescale the image before saving its copy?

See whether EXIF data would allow the Joplin renderer to add width and height attributes

Perhaps there is something in the EXIF data of the png file that would allow Jopiln’s img renderer to identify that width and height attributes should be added at half the images natural resolution?

To figure out

Is there anything in the EXIF (or other) data from a screenshot that tells you it has been taken at double-DPI?

Summary: YES, a DPI of 144 is stored in the image’s EXIF data.

After taking a screenshot, saving as a PNG, it simply shows up as having double sized dimensions in the Mac OS file info screen.

Using the file utility doesn’t show the DPI:

file screenshot-1.png
screenshot-1.png: PNG image data, 232 x 250, 8-bit/color RGBA, non-interlaced

But in the general tab of Preview, you can see the DPI is 144:

ImageMagick’s identify tool shows that the DPI is stored in the image’s EXIF data:

identify -format '%[EXIF:*]' screenshot-1.png
exif:ExifOffset=90
exif:Orientation=1
exif:PixelXDimension=232
exif:PixelYDimension=250
exif:ResolutionUnit=2
exif:UserComment=65, 83, 67, 73, 73, 0, 0, 0, 83, 99, 114, 101, 101, 110, 115, 104, 111, 116
exif:XResolution=144/1
exif:YResolution=144/1

But importantly, after pasting into Joplin, the EXIF data is lost:

identify -format '%[EXIF:*]' c41d8c9e49774020a93ac6956112b0b6.png

So even if the web browser could identify the DPI (can it?), it won’t be able to since it’s not preserved.

What does the Mac OS clipboard API look like? When the clipboard stores a screenshot, does it show pixel density?

Research

How can I stop my retina display from taking 2x sized screenshots? https://apple.stackexchange.com/questions/105185/how-can-i-stop-my-retina-display-from-taking-2x-sized-screenshots

EXIF https://en.wikipedia.org/wiki/Exif

How do I take a MacOS Retina screenshot and get the image at its actual size? https://o7planning.org/12711/how-do-i-take-a-macos-retina-screenshot-and-get-the-image-at-its-actual-size

• A tutorial showing how to use Automator to save resized versions of screenshots.

Searching for EXIF on Joplin’s Subreddit, no results: https://www.reddit.com/r/joplinapp/search/?q=exif&restrict_sr=1&sr_nsfw=

Searching for EXIT on Joplin’s support forum: https://discourse.joplinapp.org/search?q=exif

This application, Maccy, remembers clipboard history on Mac OS. Perhaps we can look at the source code to see what the Mac OS clipboard API looks like? https://github.com/p0deje/Maccy

Similar Joplin GitHub issues

Images sometimes improperly rotated #3383 https://github.com/laurent22/joplin/issues/3383

• This issue also related to EXIF data.

Keep original image rather than compressing, please #1232 https://github.com/laurent22/joplin/issues/1232

• This issue also has a discussion of EXIF data.
• It points to the following part of the code which may be relevant: ./ReactNativeClient/lib/shim-init-node.js:141-148:

Examining Joplin source code

Building the Mac OS Desktop client by following https://github.com/laurent22/joplin/blob/dev/BUILD.md.

After taking a little while on yarn install and finishing first time with errors and second time with warnings, loading the desktop app works:

Electron’s NativeImage Class

Some of the code to handle image resizing is here:

packages/lib/shim-init-node.js line 162

let image = nativeImage.createFromPath(filePath);

It uses Electronic’s NativeImage class: https://www.electronjs.org/docs/latest/api/native-image/#imageisempty

Clipboard data is retrieved using Electron’s clipboard.readImage: https://www.electronjs.org/docs/latest/api/clipboard/#clipboardreadimagetype

Electron Issues

OPEN: Clipboard: improved support for reading images #23156 https://github.com/electron/electron/issues/23156

• The issue author is writing a note taking app.
• The issue is around preserving original clipboard data.

I discovered that Joplin includes a plugin for publishing to GitHub pages. I wanted to check it out to see how well it works.

Installation

Open Preferences and search for Pages Publisher. Install the Pages Publisher plugin:

After restarting Joplin, a new Pages Publisher option is availble in the preferences.

It requires a GitHub access token with the public_repo scope.

In https://github.com/settings/tokens/new I created a new token with just that permission.

I added the GitHub token in the Joplin preferences.

In the Tools menu, there is an option to Open Pages Publisher:

When you open it, a new panel appears:

Usage

The user guide is here: https://github.com/ylc395/joplin-plugin-pages-publisher/wiki/User-Guide

I already have a blog on GitHub pages, under “blog”: https://euoia.github.io/blog/making-bread/

This is covered the FAQ, no special action is required.

When I go to add Articles, it shows “No Data”:

Perhaps it’s because I didn’t configure my GitHub settings yet?

Indeed, after configuring my GitHub settings and Quitting and reopening the plugin, my notes are showing up. I was able to add this note:

Then click Generate to publish the site:

My site is now available at https://euoia.github.io:

But where is my article?

It shows in the Archives: https://euoia.github.io/archives

Is it supposed to show on the main page?

This is something I may wish to address later.

Updating Articles

I noticed that when I changed my note, the published version didn’t change.

Indeed, if you reload the Articles tab, it shows you that the note has changed and you have to manually Sync the updated content.

I wonder if that’s something that can be done automatically?

Creating a custom theme

I wanted to be able to tweak a few things in my theme. I also wanted to see what the process looks like, because it’s quite likely I will want to change a few things later on and it would be nice to know what’s involved.

The documentation is really clear and works well: https://github.com/ylc395/joplin-plugin-pages-publisher/wiki/How-to-create-a-custom-theme

So I created a custom theme, which I’ve pushed to GitHub here: https://github.com/euoia/joplin-pages-pickle-theme

At the moment, it just changes the appearance of the article timestamps, which I thought were a bit too in-your-face. Here’s my updated version:

This is my standard bread recipe, which as of December 2021 is pretty much the only bread recipe I use. It’s fairly tolerant to variations in the weights and timings, and is the basis for my cheese bread recipe.

The recipe starts by making a poolish, which is a kind of batter, and leaving it for at least 12 hours before mixing it with a denser mixture for the final loaf.

This recipe makes two loaves of roughly 875 grams wet mixture each.

Making the Poolish

A poolish should be made at least 12 hours before starting the loaf proper. Typically I do this the in the evening, then make the bread the following morning.

Combine loosely in a large bowl:

• 500 grams Strong White Bread Flour
• 500 grams 30 °C Water
• ¼ teaspoon Allison’s dried instant easy bake yeast

Cover with clingfilm or a damp tea towel and leave at room temperature for 12 to 20 hours.

Making the loaf

After resting the poolish for at least 12 hours it should be sticky and bubbly.

You will need:

• 500 grams Strong White Bread Flour
• 21 grams kosher salt
• ¾ tsp Allison’s dried instant easy bake yeast
• 250 grams 40 °C water
• All of the poolish

1. In a large bowl combine the dry ingredients: flour, salt, yeast.
2. Add the water to the poolish to loosen it from the sides of the bowl and scrape it into the other bowl.
3. Keeping a bowl of water nearby to wet your hands, mix the ingredients with your hands by folding and pinching alternately for about 3 minutes, until the ingredients are integrated and there is not much dry flour. The dough will be very shaggy.
4. Wait 30 minutes then stretch and fold.
5. Wait another 30 minutes then stretch and fold.
6. Wait another 30 minutes then stretch and fold.
7. Leave the dough covered with a damp tea towel for a further hour.
8. Put dough on floured surface and cut in half. Shape each half into boules and place one boule seam side down into a floured banneton or floured towel lined bowl. Wrap the other half of the dough in clingfilm and keep in a bowl in the fridge for a day or two. When you’re ready, you can remove it before transferring to a banneton and proceeding with the next step.
9. Set oven to 220 °C Fan (240 °C conventional oven). Place a cast-iron dutch oven in the oven with its lid on.
10. Wait an hour for the dutch oven to heat up and for the dough to rise.
11. Tear a piece of greaseproof paper large enough to accommodate the dough, with extra at the sides for lifting.
12. After an hour, flip the banneton upside down onto greaseproof paper. Carefully remove the banneton, trying not to tear the dough too much. Lift the dough by picking up the edges of the greeseproof and transfer into the dutch oven.
13. Bake for 30 to 35 minutes with the lid on, then 15 to 20 minutes with the lid off.

Cheese Bread

To make a cheesy variant of this recipe, chop 250 grams of emmental (the older and smellier the better) into 1.5 centimetre cubed pieces and fold into the centre of the dough as you make a boule. It will seem like a lot of cheese, but I have found it works really well.

I use Neovim on OS X as my code editor.

I am quite happy to use it in the terminal, but I find it helpful to have a separate application that I can run in full screen and can switch to independently of iTerm2.

I tried some of the standalone Neovim applications, but was generally unhappy with them for one reason or another. So I decided to make a standalone version that runs inside iTerm2.

Running Neovim this way is great because it leverages the power and stability of iTerm2. iTerm2 has great support for customization of appearance and keyboard rebinding.

Here’s how to build a standalone version of Neovim that’s based on iTerm2.

I am not a developer of Mac applications, so the following is based on a bit of trial and error and fiddling around with XCode. This is the method I’ve used to build a standalone version of Neovim several times across several versions of Neovim and XCode.

These steps have been tested with XCode 11.2.

1. Clone iTerm2 master from GitHub https://github.com/gnachman/iTerm2

2. Open XCode and choose “Open another project…”. Select the directory where you cloned iTerm2.

3. Change Bundle ID to (something like) co.uk.cloudship.neovim

4. Under Signing & Capabilities change to “Sign to run locally”

5. In the right-hand pane change Name to Neovim

A window will appear helping you rename all instances of iTerm2 to Neovim.

6. Update the icons.

Find Supporting Files > Images > Media.xcassets (you can use the filter at the bottom of the file list window)

Grab the Neovim icon from here: https://raw.githubusercontent.com/neovim/neovim.github.io/master/logos/neovim-mark.png

I used Iconfly to generate AppIcon.appiconset (select generate without scaling).

Drag the AppIcon.appiconset folder to Xterm.

Remove the old icon set and rename the new one to the old name.

7. I tried building at this point but it failed due to a reference somewhere to iTerm2.pch.

In XCode, select the project and go to Build Settings.

Under targets select NeovimSharedArc.

In the filter, enter GCC_PREFIX.

Under the setting Prefix Header, update the value to sources/Neovim.pch.

8. Replace all references to iTerm2SharedARC-Swift.h with NeovimSharedARC-Swift.h

9. Build the application by hitting ⌘-R.

10. Copy Neovim to applications.

Under Products right click on Neovim.app and select “Show in Finder”.

Move Neovim.app to applications.

10. All done!

You should be able to run Neovim.app now.

What I did after this was create a separate profile for Neovim in iTerm2 that runs the following at startup: nvim && exit. This option is under Profiles > General as “send text at start”) in the iTerm2 (and now Neovim) preferences.