susam.net VS blog.johnnyreilly.com

I have a similar setup for my personal and project websites. Some similarities and differences:

* I use Linode VMs ($5/month).

* I too use Debian GNU/Linux.

* The initial configuration of the VM is coded as a shell script: https://github.com/susam/dotfiles/blob/main/linode.sh

* Project-specific or service-specific configuration is coded as individual Makefiles. This takes care of creatng An example: https://github.com/susam/susam.net/blob/main/Makefile

* The software is written in Common Lisp. In case of a personal website or blog, a static website is generated by a Common Lisp program. In case of an online service or web application, the service is written as a Common Lisp program that uses Hunchentoot to process HTTP requests and return HTTP responses.

* I use Nginx too. Nginx serves the static files as well as functions as a reverse proxy when there are backend services involved. Indeed TLS termination is an important benefit it offers. Other benefits include rate limiting requests, configuring an allowlist for HTTP headers to protect the backend service, etc.

I began developing personal websites in 2001. It was a time when people like me would develop personal websites just because we could. It didn't matter whether we had something useful to say or if anyone visited the website. All that mattered was that it was fun! I still maintain my website in the same spirit.

I do share the technical posts from my websites on HN and Reddit hoping to get some feedback but that's not the primary motive. Also, there were no HN and Reddit in 2001. Back then I used to write for myself and I still do so now. My personal website is a way for me to keep an archive of some fun things I know so that my future self can look back at them when needed or desired. Only a few days ago, I added a jokes page[1] to my website just because I thought it would be nice to keep my favourite jokes somewhere easily accessible.

As years go by, I've found that the friction of editing and publishing new posts or pages to my website has only become less. First came, virtual private servers that swayed me away from shared web hosting solutions. Then came Git which made it incredibly efficient and convenient to keep a change history of my website and sync it to any system. I write my pages in plan HTML using Emacs. Then git add; git commit; make pub [2] and the updated website is published within seconds. A Common Lisp program reads all my HTML pages, adds a common theme and template to them and writes them out to a directory Nginx can read from. It is as low friction as it can get that suits my taste and preferences while maintaining complete flexibility on the website.

It has been 13 years since I wrote my first "Hello!" and while HTML and web development and publishing has evolved a lot since then, I am still having fun!

[1] https://susam.net/maze/jokes.html

[2] https://github.com/susam/susam.net/blob/main/Makefile#L144

form.service (the systemd unit file)

Source code [0] is available on GitHub; looks like they wrote their own simple site generator.

I've been thinking about something similar (maybe even simpler) for my blog too.

[0]: https://github.com/susam/susam.net

All of these affordances are available to me with TypeScript, and I want to keep them. Let's begin migrating. Incidentally, the code for this migration lies in this PR.

I'm going to write about this in the context of my blog. My blog is open source and you can find the code here. I'm going to present a simplified solution in this post, but you can find the full solution on GitHub.

These scripts are implemented as a simple ts-node console app. For historical reasons it's called trim-xml (it originally just truncated the sitemap.xml file). It's not a particularly good name but I'm not going to change it now. As the blog is open source, you can see the [code of trim-xml here](https://github.com/johnnyreilly/blog.johnnyreilly.com/tree/main/trim-xml].

I'm somewhat on the fence as to whether it's useful to have a breadcrumb for each tag. In fact, originally I didn't have it when I first added support. But I've added it in as it's not a lot of work and it's not a lot of code. I'm not sure if it's useful or not. I've added it now; I'm going to leave it in in place for a bit and see how it goes.

You will also need to disable the url-loader in your Docusaurus build which transforms images into base64 strings, as this will conflict with the plugin. There isn't a first class way to do this in Docusaurus at present. However by setting the environment variable WEBPACK_URL_LOADER_LIMIT to 0 you can disable it. You can see an implementation example in this pull request. It amounts to adding the cross-env package and then adding the following to your package.json:

//@ts-check const visit = require('unist-util-visit'); /** * Create a remark plugin that will replace image URLs with Cloudinary URLs * @param {*} options cloudName your Cloudinary’s cloud name eg demo, baseUrl the base URL of your website eg https://blog.johnnyreilly.com - should not include a trailing slash, will likely be the same as the config.url in your docusaurus.config.js * @returns remark plugin that will replace image URLs with Cloudinary URLs */ function imageCloudinaryRemarkPluginFactory( /** @type {{ cloudName: string; baseUrl: string }} */ options ) { const { cloudName, baseUrl } = options; const srcRegex = / src={(.*)}/; /** @type {import('unified').Plugin<[], import('hast').Root>} */ return function imageCloudinaryRemarkPlugin() { return (tree) => { visit(tree, ['element', 'jsx'], (node) => { if (node.type === 'element' && node['tagName'] === 'img') { // handles nodes like this: // { // type: 'element', // tagName: 'img', // properties: { // src: 'https://some.website.com/cat.gif', // alt: null // }, // ... // } const url = node['properties'].src; node[ 'properties' ].src = `https://res.cloudinary.com/${cloudName}/image/fetch/${url}`; } else if (node.type === 'jsx' && node['value']?.includes('')) { // handles nodes like this: // { // type: 'jsx', // value: '' // } const match = node['value'].match(srcRegex); if (match) { const urlOrRequire = match[1]; node['value'] = node['value'].replace( srcRegex, ` src={${`\`https://res.cloudinary.com/${cloudName}/image/fetch/${baseUrl}\$\{${urlOrRequire}\}\``}}` ); } } }); }; }; } module.exports = imageCloudinaryRemarkPluginFactory;

yeah I'm hoping that my redirect story is now quite good - see dynamic redirect code here:

https://github.com/johnnyreilly/blog.johnnyreilly.com/blob/m...

as to the duplicate content, Docusaurus generates /tags/ and /pages/ content by default that I strip from from my sitemap manually.

I started using fontaine on my blog. If you haven't tried it out, you can find it here. It helps reduce Cumulative Layout Shift. The flash of unstyled content jank that you can see when you first land on a site, before fonts have loaded. I can't see why that would be an issue. It should improve my blogs Core Web Vitals and help stuff rank better, not worse. I think this is a red herring.

client side redirects boom * https://github.com/johnnyreilly/blog.johnnyreilly.com/commit/e641431314c4b6a19d375f1c7bc14f5bd6456ec9 november feedback loop

param location string param branch string param staticWebAppName string param tags object @secure() param repositoryToken string param rootCustomDomainName string param blogCustomDomainName string param appInsightsId string param appInsightsInstrumentationKey string param appInsightsConnectionString string var tagsWithHiddenLinks = union({ 'hidden-link: /app-insights-resource-id': appInsightsId 'hidden-link: /app-insights-instrumentation-key': appInsightsInstrumentationKey 'hidden-link: /app-insights-conn-string': appInsightsConnectionString }, tags) resource staticWebApp 'Microsoft.Web/staticSites@2022-03-01' = { name: staticWebAppName location: location tags: tagsWithHiddenLinks sku: { name: 'Free' tier: 'Free' } properties: { repositoryUrl: 'https://github.com/johnnyreilly/blog.johnnyreilly.com' repositoryToken: repositoryToken branch: branch provider: 'GitHub' stagingEnvironmentPolicy: 'Enabled' allowConfigFileUpdates: true buildProperties:{ skipGithubActionWorkflowGeneration: true } } } resource staticWebAppAppSettings 'Microsoft.Web/staticSites/config@2022-03-01' = { name: 'appsettings' kind: 'string' parent: staticWebApp properties: { APPINSIGHTS_INSTRUMENTATIONKEY: appInsightsInstrumentationKey APPLICATIONINSIGHTS_CONNECTION_STRING: appInsightsConnectionString } } resource staticWebAppFunctionAppSettings 'Microsoft.Web/staticSites/config@2022-03-01' = { name: 'functionappsettings' kind: 'string' parent: staticWebApp properties: { APPINSIGHTS_INSTRUMENTATIONKEY: appInsightsInstrumentationKey APPLICATIONINSIGHTS_CONNECTION_STRING: appInsightsConnectionString } } resource rootCustomDomain 'Microsoft.Web/staticSites/customDomains@2022-03-01' = { parent: staticWebApp name: rootCustomDomainName properties: {} } resource blogCustomDomain 'Microsoft.Web/staticSites/customDomains@2022-03-01' = { parent: staticWebApp name: blogCustomDomainName properties: {} } output staticWebAppDefaultHostName string = staticWebApp.properties.defaultHostname output staticWebAppId string = staticWebApp.id output staticWebAppName string = staticWebApp.name