I tend to write two kinds of note: long and short. Long notes I store in Notion - and they are essentially personal documentation. I'm talking recipes, packing lists, code snippets or movie recommendations - things that need to be stored in different formats, with rich text, images, and more.

But the vast majority of notes are short - and for these, Notion is too slow. The best app I've found for short notes is WhatsApp.

Short form note app must-haves:

• Extremely fast for me to write something.
• Secure.
• Available on all my devices and synchronised.
• Easy to use.

Nice to haves:

• Searchable
• Ephemeral
• Notes can be easily shared
• Free

WhatsApp checks all of these!

To use WhatsApp for note taking, you need to be able to send yourself messages, which is a weirdly un-straightforward process.

How to send yourself messages on WhatsApp

You have two options, either send yourself a direct message, or create a group. I prefer the group option, but I'll show you both.

To send yourself a direct message, you need to open this URL on any device that can install WhatsApp:

https://wa.me//+3801111111111

You'll need to replace the end part with your own number, including the country code.

This will prompt you to open a chat with yourself - why you can't select your own contact from the UI, I have no idea. ¯\_(ツ)_/¯

The second option is to create a WhatsApp group, add a bemused friend or loved-one, then instantly remove them. You now have a private group. I prefer this method for two reasons: 1) You can name the group "notes' or something similar, and set an appropriately note-like icon. 2) When using a direct message to yourself, if you write a note on one device, your other devices get a notification - which can get annoying. This doesn't happen with groups.

Once the group is created, you can create a shortcut to it on your home screen, and even turn on disappearing messages. This means that any sensitive notes are automatically cleared up, and it discourages you from storing anything important in there - as you know it'll be removed in 7 days.

TL;DR: Spin up a local container running Ghost, crawl the frontend to generate a static site, and upload to a free static host.

While there's quite a few options for statically hosting written content for free, most of these involve using markdown as your writing interface. While this is fine, I'd prefer the block-based rich editor offered by Ghost.

Ghost Pro's pricing is quite reasonable and a good option if you want to take advantage of all that Ghost has to offer. But if you just want a personal site without members, I've found the best option is to run Ghost locally, and upload the rendered pages to a free static web hosting service. This tutorial will show you how.

Limitations

[Skip this part if you don't care about the limitations and just want to get to the tutorial].

It's important to understand a little about how Ghost works. The backend keeps state in a SQL database, and is accessed by a JSON API. Assets, such as images, themes or logs are kept in 'storage', which can be on the filesystem of the server, in an S3-like object storage service, or in a container volume/mount. The other part of Ghost is the frontend, which out of the box is a theming system that uses handlebars.

Generating static HTML files from your locally running Ghost instance works for quite a few use cases, but clearly not for anything dynamic. For instance readers won't be able to sign up to your newsletter, as there won't be any server to handle the request. The following features won't work:

• Newsletters;
• Memberships;
• Post embargos;
• Easy collaboration with others;
• Anything else that requires clients to make a request other than for HTML/CSS.

Tutorial

How to run Ghost locally

I run my Ghost instance using Docker, which means it's easy to update and is isolated from my OS.

If you haven't got it already, you'll need to install Docker.

To pull down the latest Ghost image, run docker pull ghost

You'll now need to set up a folder where you can keep your Ghost content, this is things like images, themes, and your SQLite database. For instance: /Users/steve/stuff/ghost-content

Now, to run the Ghost container, execute the following, but substitute my-blog with whatever you want to call your container (doesn't really matter what), and /Users/steve/stuff/ghost-content with the location of your content folder that you created in the previous step.

docker run -d --name my-blog -e url=https://sgbarker.com/blog -p 3002:2368 -v '/Users/steve/stuff/ghost-content':/var/lib/ghost/content ghost

You should find that Ghost has populated your content folder with stuff:

Now, if you head to https://sgbarker.com/blog, you should see that your publication is running! (You may need to wait ~1 minute if the container is still spinning up).

If you head to https://sgbarker.com/blog/ghost, this will display the admin page where you can set up your publication.

Generating the static site

Now that you have Ghost running on your machine, you'll need to crawl the site to fetch the HTML files. For this I'd recommend Mr Mo's Ghost Static Site Generator, (GSSG) which usefully does this job for us. Thanks Mr Mo.

Follow the instructions on the GSSG readme to install it.

Next, you'll need to create a folder that you want to store your static site in. Let's call it /Users/steve/stuff/ghost-static for now.

From your ghost-static folder, run the following command. You'll need to change the --dest to path of the folder you just created, and the --url from yourdomain.com to the actual domain you intend on hosting the site at:

gssg --domain https://sgbarker.com/blog --dest '/Users/steve/stuff/ghost-static' --url https://yourdomain.com

You should now see GSSG fetching a load of files and putting them in your static directory.

Uploading to the internet

You'll need some kind of static hosting service. I think Cloudflare Pages offers the best performance, ease of use and price, so I'll be using that. It's free for unlimited requests, bandwidth and sites, up to 500 builds per month ATTOW. You could also use something like GitHub Pages or Netlify.

Create a GitHub repo for your static site, then upload the contents of your static folder - by now this should contain an index.html, some xml files, and possibly a number of folders, depending on how much content you have.

​Sign in to Cloudflare Pages

Go to the Cloudflare Pages site, and sign in with your Cloudflare account. If you do not have an account yet, you can sign up as you go.

​Connect to GitHub

Signing in with GitHub allows Cloudflare Pages to deploy your projects, update your GitHub PRs with preview deployments, and more. After you sign in, select Create a project in the Pages dashboard.

You'll then need to point Cloudflare Pages to the GitHub repo containing your static site, after which you can configure some settings such as which directory it should point at. If you've followed this tutorial closely, your static site should be stored in the root of the repo.

Once the first deployment has finished, you can also set up your own domain name.

That's it! You now have your writing hosted on one of the world's fastest content delivery networks, that can handle a virtually "unlimited" amount of traffic, for free.

Going further and optimising

Backups

If you ever want to spin up your local Ghost container, it's as simple as executing the docker run command from the start. However if you lose your content folder, then you'll lose all your posts and your ability to run your publication locally, so I strongly recommend you back it up.

Turning off dynamic features

As dynamic features of Ghost won't work for your users, I recommend turning as many of them off as possible. From the Ghost settings, you can head to memberships to turn off subscription access.

You can also pick a theme that optimises for content delivery, rather than for more dynamic features of Ghost.

Deleting posts

One small 'gotcha' is that if a post is deleted or renamed, the original will stay in your static folder. To get around this, ensure you periodically purge your static folder before regenerating it.

Database

The database used by the official Docker image is SQLite, which is fine for our use case. The database will live in your content-folder/data, so you can easily make changes to the data or back it up.

I hope you find this useful. Note, while I've been using it for a few months, I wouldn't rely on this workflow for anything critical.

I spent some time in North Korea (DPRK), via a specialist travel agency. I didn't get as many good photos as I would have liked, but below are some of the better ones.

The only difficult thing about making delicious fudge is how long and at what temperature to cook it for.

Ingredients

Makes: ~900g of fudge

• 550g demerara sugar
• 100g butter
• 170g golden syrup
• 1.5-2 tps sea salt flakes
• 30g maple syrup
• 350ml double cream
• 1 tsp vanilla extract

Optional:

• Sugar thermometer

Method

Weigh out your ingredients, then get a medium-large pan - ideally with a thick base.

Melt the butter gently, then dissolve in the sugar.

Once the sugar is more-or-less mixed in with the butter, add in the double cream and syrup(s).

Ensure the pan is on a medium heat and stir everything together.

After a few minutes, it should be a smooth liquid that's vaguely fudge-coloured:

Now comes the less-fun part, you basically want to keep it cooking for a while, stiring now and then, mainly to make sure it doesn't stick.

There is lots written online about the 'perfect' temperature to cook your fudge at - I've found it doesn't make much difference, as long as you don't let it get too hot. I use a sugar thermometer and if I see it getting much more than 117℃, I turn the heat off for a minute.

As the fudge is cooking it's fine for it to look light and bubbly like this.

It's quite tricky to know exactly how long to cook for, so it takes a bit of trial and error. Roughly speaking after about 35 minutes, I'm starting to test the fudge for it's consistency.

How to know when the fudge is ready

I use the 'soft ball' method. Again, it's something you'll get better at after a few attempts - but essentially you put a bit of the liquid fudge in cold water to see if it takes on the consistency you're aiming for.

Fill a bowl with cold water. Drop a teaspoon of fudge in - then pick it up. Can you form it into a ball that stays together? Does it have the consistency of fudge? If so, it's probably ready. You don't want it to go hard - that means it's been cooked too long. If the fudge stays very liquid and doesn't form a ball easily, then it needs more cooking.

Once the fudge is cooked, turn off the heat and mix in the salt and vanilla. I personally like to use plenty of salt, but err on the side of caution. You can always sprinkle more salt on after it's cooked. Stir the hot fudge for a few minutes.

When the fudge is cooked, salted and stirred, get a container. I use a small baking tray lined with parchment paper. Put in. Leave for 1.5 hours, then cut up and put in the fridge.

Originally posted on Gousto Engineering & Data

Most Gousto customers choose to get their recipe boxes on a subscription basis: every week they choose their recipes from our menu, and we pick, pack and deliver them to their door. To give customers as much flexibility as possible, we let customers edit their box right up until it’s sent to one of our factories for picking.

This process works really well most of the time. But what happens when a customer’s payment fails?

It’s natural that a proportion of payments will fail — customers’ cards have changed, or there aren’t enough funds in the account. At Gousto we had a natural failed payment rate of around 2% for existing customers.

Until recently we only had two ways of handling a failed payment. First, we could send out the box anyway and put a debit on the customer’s account. Alternatively, we could just cancel the customer’s order.

Neither of these is a good solution. We never want to have to cancel a customer’s box, nor do we want to put a customer into ‘debt’. The majority of failed payments are because a customer has forgotten to update their card details and are still expecting to receive their order. I’m sure you can imagine how frustrating it might be to lose your food delivery for the week just because your debit card expired.

How did we reduce failed payments?

We decided to request a ‘dry run’ payment 24 hours before the actual payment is due — this is known as a pre-authorisation. Pre-auths allow merchants like Gousto to ‘reserve’ some amount of money against a customer’s payment method, without actually charging them. When we attempt to reserve these funds, we’ll receive a success or failure response from the customer’s bank. If unsuccessful, we can ask the customer to update their payment details.

As you can see, pre-auths allow us to catch a failed payment. We then email customers and give them 24 hours to update their card details in time for the final payment. This alone reduced our failed payment rate by 92%!

Many customers will receive a notification from their bank when the pre-auth is requested, which serves as an extra reminder of their upcoming box, with time for them to update their recipes before it’s dispatched. If the customer no longer wishes to receive their order, they also have the opportunity to cancel it through the app before it’s already paid for and dispatched. This reduces wasteful unintentional orders.

How do pre-auths actually work?

When a merchant pre-authorises funds on an account, it doesn’t have access to those funds yet; they’re ring-fenced for that merchant to use at some future point in time and the customer can’t use those funds for anything else.

If the merchant doesn’t end up charging the customer, the funds are released back to the customer by their bank after a period of time, typically five days. We built our system so that if a customer cancels a box that has been pre-authorised but not yet paid for, we would immediately void the pre-authorisation. This ensures we aren’t holding onto customers’ funds for any longer than is necessary.

How did we engineer this? Enter: Data bulkheading.

As I mentioned above, once a Gousto order is ‘cut-off’, it is no longer editable by the customer and is sent to one of our factories to be packed. This happens in batches of orders at a time, so it’s extremely important that this process is fault tolerant and speedy. To this end, many Gousto applications use a bulkhead architecture, and our shiny new pre-auth system is no exception.

The pre-auth process comprises a series of serverless functions, but we don’t want these functions to have to rely on a centralised data store to do their job. Instead, they have their own data store, which keeps a copy of all upcoming orders with payments due in the near future. Not only does this save additional functions from putting more load on a single database, but should there be a fault in another part of the system, the payments data store will be unaffected. Fun fact: the bulkhead pattern is named after the isolated sections of a ship’s hull. If the hull is pierced, only the damaged section fills with water, preventing the rest from flooding.

The pre-auth system is an ideal use case for serverless functions. Demand for these services is very spiky — when a batch of orders is ‘cut off’ for example, we need a large amount of concurrency to quickly process them all. The rest of the time, we don’t see much activity, so it doesn’t make sense to pay for running servers.

For our payment functions to maintain a storage bulkhead, they need to be kept up to date with the state of orders. We utilise AWS SNS and SQS for this or — in other words — pub’ sub’. When any application within Gousto makes a change to an order, we publish to a topic. One of our payment functions is subscribed to this topic, and if the change affects the price or payment of the order, this update is added to its queue. The change is then persisted to the payments data store, ready to be processed.

After testing pre-auths on a small group of customers for a few weeks, we saw very positive results, both financially and from the feedback we received from customers! We have now rolled this out to everyone who uses Gousto.

Back in the day I used WordPress quite a bit. It had many appealing qualities - it was easy to host, very extendable and had a huge community of users. So huge that even in 2020, WordPress runs over 33% of all websites. I used WordPress for all kinds of projects that needed a CMS: brochure sites, online stores, landing pages.

But even though WordPress was ostensibly a blogging platform, by 2013 it no longer excelled as one. The WordPress team had continued to add features, and with the extensibility of plugins and themes, WordPress became a much more general-purpose API for managing content on the web.

I don't think there's anything intrinsically wrong with this, but it left an opportunity for a CMS narrowly focussed on the writing experience. And there was demand for such a CMS. Ghost ran a successful Kickstarter campaign, and has been growing in popularity ever since.Ghost has a clean writing interface that uses blocks to arrange content, (similar to Notion's, though admittedly not with as many block types), and makes for a very intuitive all-round UI. I've made Ghost sites for non-techie people and they've been able to get going straight away. That's not to say Ghost is lacking features, rather they're focussed on allowing you to write, grow your audience, and more recently, monetise that audience. There are SEO tools, email newsletters and paid memberships built in, for instance.So it's safe to say I'm a fan of Ghost. I don't dislike WordPress, but for writing projects, Ghost is my no1. choice. It can be self-hosted, or you can use Ghost's official managed hosting.

My take on the simple Moscow Mule cocktail. I use a quince infused vodka which gives a unique twist.

I picked up the quince vodka from Szambelan, a vodka producer in Krakow - but you can infuse your own or buy some online too.

If you're adding extra fresh ginger, which I recommend, slice into long match sticks and just throw in!

• 50ml quince vodka
• 200ml ginger beer
• Juice from ~half of a lime
• Plenty of ice
• Sprig of mint (optional)
• Fresh ginger root (optional)

As I talked about in my Helios 44M-4 post, I bought a 1980s Zenit camera and lens kit, mainly to fit the lens to my Fuji X camera.

But I also put a film in the Zenit to have a play around with it... I'm experienced with film at all, but here are some the images it produced.

Apparently you can fit pretty much any old film lens to a Fuji X-series camera, given the right adapter. This is an inexpensive way to try out retro glass on a modern mirrorless body - so thought I'd give it a go with a Helios 44M-4.

You can pick up one of these lenses quite cheaply by itself, but I found buying it as part of a kit is only marginally more expensive. For £37 on eBay I got a Zenit 12XP + lens, still in it's original packaging!

Zenit began as a Soviet camera manufactuer in the 1950s, and mass-produced a huge number 35mm SLRs. The 12XP was one of the most popular, and you'll often find it with a Helios 44M-'x' lens.

Attaching The Lens To Fuji X

To use a retro lens with a Fuji X camera you'll need an adapter - for the Helios 58mm it's the M42 mount. You can get similar adapters for Sony, Nikon etc. too.

Once the lens is attached to my beloved X-T20, the whole thing its quite big - the adapter alone adds a few centimetres of depth.

I also found that the orientation of the adapter meant that the focus and aperture markings were facing at a slight angle - you should be able to see what I mean from the picture below.

Trying It In The Wild

Armed with the Helios-on-Fuji I set out to take some pictures around London.

After just a few shots I was impressed with the quality. I'd heard that these lenses could produce some great images, and I you can see the results for yourself.

There's a film-like quality to the picture above - it's got an imperfect character that you won't find with modern lenses.

I noticed that reds really tend to stand out with this lens.

There are quite a few variations of the Helios 44 - the 44M-1, 44M-2 etc. I have the 44M-4 which was made in the 1980s and apparently has some of the best image quality of the range.

The Helios does pretty well in low-light too. I took this one at about f4 and increased the exposure only a little in Lightroom.

Especially when the lens is open between f2 - f4, there is a fair amount of distortion at the edge of the image. You can see this alot on the bike wheels on the left.

Helios lenses from this era are also famed for their bokeh - the quality of their blur. In the background of these shots you can see a distinctive hazy swirl pattern.

For a point of comparison, below is a similar shot with my Fujinon 35mm 1.4. Part of the difference is down to my ability to focus manually. That's the other thing you'll have to get used to with a lens like this: there's no chip inside for autofocus or image stabilisation.

Again, in this picture of a boat you can see that the centre of the image is really sharp, but the trees and towpath look pretty smudgy. But for how cheap this lens is it handles really well and is fun to shoot with too.

I also took some shots with the Zenit body and a film, I've uploaded those here if you're interested.