Ethan Hawksley's Blog

JSON-LD Explained for Personal Websites

Sun, 21 Jun 2026 00:00:00 GMT

JSON-LD, also known as JSON Linked Data, is a format for adding structured data to webpages. It can aid web crawlers in understanding the semantic structure of your site, qualifying you for richer link previews, and even potentially improving your search ranking.

It's been 4 months since my first post where I described building this site, and Wakatime estimates I've spent ~100 hours coding now, not including time spent researching and testing. Since then, this site has been receiving plenty of polish, including the addition of JSON-LD on each page.

JSON-LD Fundamentals

To add JSON-LD to a page, add the following somewhere in your <head> section:

<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@graph": [
      {
        "@type": "WebSite",
        "@id": "https://hawksley.dev/#website",
        "url": "https://hawksley.dev/",
        "name": "Ethan Hawksley"
      },
      // Insert more nodes here.
    ]
  }
</script>

Let’s break down what each part does.

<script type="application/ld+json">

This declares a new script with MIME type application/ld+json. Since it has this type specified, the browser's JS engine won't run it. Specialised crawlers like Googlebot look out for these elements and parse the contents.

{
  "@context": "https://schema.org"
}

Here, a JSON object is initialised and the property @context is set to https://schema.org. In JSON-LD, the structure of data is determined by assigning the appropriate context. Web crawlers are standardised on Schema.org, which defines all the valid key-value pairs for the JSON.

Now that we've defined the schema our JSON-LD is following, we can describe our webpage!

{
  "@graph": [
    {
      "@type": "WebSite",
      "@id": "https://hawksley.dev/#website",
      "url": "https://hawksley.dev/",
      "name": "Ethan Hawksley"
    }
    // Insert more nodes here.
  ]
}

A JSON-LD document can be thought of as a labelled, directed graph, stored under @graph. The graph contains multiple nodes, connected to each other with directed arcs.

Nodes have:

@type - Describes what the node is, e.g. WebSite or SoftwareApplication
@id - A unique identifier for the node, typically a URL with a unique hash value at the end
Properties - Key/Value pairs that describe the attributes of the node

In the example above, the type is WebSite, the ID is https://hawksley.dev/#website, and it has two properties, url and name.

Web crawlers can merge the properties of a node across multiple pages, as long as they share an ID. However, scrapers that only read one page - such as LLMs - will not merge the properties. When JSON-LD is reused across pages, striking this balance is important to keep in mind. It is best practice for the ID to be a URL followed by a hash, such as #website, that uniquely identifies the node.

Although the Schema.org context defines many types of nodes, this guide will only be covering nodes that have noticeable SEO impact. If you're interested in more, look up the semantic web - it's a fun rabbit hole.

Let's move on to which nodes each page on our site should include. For each type, I've included the JSON-LD from this site, so you can copy-paste and edit it to fit your own.

WebSite

You've seen an extract of WebSite earlier! Now here's the full version:

{
  "@type": "WebSite",
  "@id": "https://hawksley.dev/#website",
  "url": "https://hawksley.dev/",
  "name": "Ethan Hawksley",
  "alternateName": ["hawksley.dev", "Hawksley"],
  "description": "The personal site and technical blog of Ethan Hawksley, a UK-based CS student with a focus on systems programming, low-level computing, and cybersecurity.",
  "inLanguage": "en-GB",
  "publisher": {
    "@id": "https://hawksley.dev/#person"
  },
  "image": {
    "@type": "ImageObject",
    "@id": "https://hawksley.dev/#website-image",
    "url": "https://hawksley.dev/logo-square.png",
    "caption": "Ethan Hawksley Logo"
  }
}

WebSite explains the metadata about the site. It gives crawlers hints on how to display your site.

Here, you can see that Google has interpreted the name field as representative of the domain and is labelling the result appropriately.

Although WebSite applies to every page, you don't need to include the full version of it on every page. The root page of the domain should be fully detailed, but it is perfectly acceptable for other pages to have a slimmed-down version:

{
  "@type": "WebSite",
  "@id": "https://hawksley.dev/#website",
  "url": "https://hawksley.dev/",
  "name": "Ethan Hawksley"
}

This gives sufficient context to single-page crawlers so they correctly name the site, but they don't need the full details.

WebPage

WebPage describes the current page, but it's important to distinguish it from other types like BlogPosting (covered later). WebPage represents the physical page itself, the HTML. It contains the content of the page.

{
  "@type": "WebPage",
  "@id": "https://hawksley.dev/blog/hack-club-campfire/#webpage",
  "url": "https://hawksley.dev/blog/hack-club-campfire/",
  "isPartOf": {
    "@id": "https://hawksley.dev/#website"
  },
  "name": "Winning the Hack Club Campfire Hackathon",
  "inLanguage": "en-GB",
  "breadcrumb": {
    "@id": "https://hawksley.dev/blog/hack-club-campfire/#breadcrumb"
  }
}

There are more specific subtypes of WebPage. In this post, I'll cover ProfilePage and CollectionPage. You can find less common ones at the bottom of Schema.org's definition for WebPage.

Person

Another node that every page on a personal website should have is Person. It describes who you are, which Google uses as part of their content quality metric. Increasingly, LLM crawlers are also using it to decide who to cite in their answers.

Unlike WebSite, it is important enough context that you should include it on all of your site's pages.

Warning - Quite Long!

{
  "@type": "Person",
  "@id": "https://hawksley.dev/#person",
  "url": "https://hawksley.dev/",
  "name": "Ethan Hawksley",
  "alternateName": "ethanhawksley",
  "givenName": "Ethan",
  "familyName": "Hawksley",
  "description": "Long Description",
  "disambiguatingDescription": "Shorter Description",
  "jobTitle": "Computer Science Student",
  "knowsLanguage": "en-GB",
  "knowsAbout": [
    // Keywords
  ],
  "nationality": {
    "@type": "Country",
    "name": "United Kingdom"
  },
  "homeLocation": {
    "@type": "Place",
    "address": {
      "@type": "PostalAddress",
      "addressCountry": "GB"
    }
  },
  "affiliation": {
    "@type": "HighSchool",
    "url": "https://www.alcestergs.co.uk",
    "name": "Alcester Grammar School",
    "sameAs": [
      "https://www.wikidata.org/wiki/Q4713005",
      "https://en.wikipedia.org/wiki/Alcester_Grammar_School"
    ]
  },
  "alumniOf": [
    {
      "@type": "HighSchool",
      "url": "https://www.brookeweston.org",
      "name": "Brooke Weston Academy",
      "sameAs": [
        "https://www.wikidata.org/wiki/Q4974495",
        "https://en.wikipedia.org/wiki/Brooke_Weston_Academy"
      ]
    }
  ],
  "image": {
    "@type": "ImageObject",
    "@id": "https://hawksley.dev/#person-image",
    "url": "https://hawksley.dev/ethan-hawksley.png",
    "caption": "Ethan Hawksley",
    "width": 1536,
    "height": 1536
  },
  "sameAs": [
    "https://github.com/ethan-hawksley",
    "https://www.linkedin.com/in/ethanhawksley",
    "https://lobste.rs/~ethanhawksley",
    "https://news.ycombinator.com/user?id=ethanhawksley"
    // etc. etc.
  ]
}

Phew! There's plenty of properties for Person. I find that it helps to be more descriptive, rather than less, when it comes to filling it out. Let’s look at the most important properties:

url - Points to your root page, anchoring the node.
name, givenName, familyName - Clearly describes your name.
image - Preferably a photo of you, or a logo you are affiliated with. Connects you to a canonical image of you.
sameAs - Immensely useful for disambiguation, especially if you have a common name. It cleanly informs crawlers what your other profiles are, letting them build a knowledge graph representation of you across multiple pages. At the time of writing, /g/11m62cgdtf is my Google knowledge graph ID.

The other properties of Person are useful for adding more detail, but aren't strictly necessary. You can trim them if you wish with only minor impact.

ProfilePage

A ProfilePage, as you may expect, describes a page on the site about a person. For instance, I use this node on my home page, as that's where I talk about myself. On your site, putting it on an about page could be more appropriate.

{
  "@type": "ProfilePage",
  "@id": "https://hawksley.dev/#webpage",
  "url": "https://hawksley.dev/",
  "isPartOf": {
    "@id": "https://hawksley.dev/#website"
  },
  "name": "About Ethan Hawksley",
  "inLanguage": "en-GB",
  "dateCreated": "2024-09-10T00:00:00.000Z",
  "dateModified": "2026-05-17T00:00:00.000Z",
  "mainEntity": {
    "@id": "https://hawksley.dev/#person"
  }
}

It's important to use isPartOf to link it to your broader WebSite node, to create a relationship between the two nodes. The same applies for mainEntity, it lets crawlers know who the page is about. Including dateCreated and dateModified is a good freshness signal for crawlers, but if your site doesn't have them readily available, don't worry too much about it.

SoftwareApplication

If you are showcasing any software on your page, it's a good idea to include a SoftwareApplication node to describe the metadata about it.

{
  "@type": "SoftwareApplication",
  "@id": "https://hawksley.dev/#project-yt-play",
  "url": "https://crates.io/crates/yt-play",
  "name": "yt-play",
  "description": "A CLI utility written in Rust that synchronises YouTube playlists to local directories.",
  "applicationCategory": "MultimediaApplication",
  "operatingSystem": "All",
  "creator": {
    "@id": "https://hawksley.dev/#person"
  },
  "sameAs": ["https://github.com/ethan-hawksley/yt-play"],
  "offers": {
    "@type": "Offer",
    "price": 0,
    "priceCurrency": "GBP"
  }
}

If you want to be more specific than SoftwareApplication, other valid types for this node are MobileApplication, WebApplication, and VideoGame.

The url property should be a link to where the project is deployed, e.g. crates.io. sameAs is for any other pages associated with the project, like its source code repository.

There are lots of valid values for applicationCategory, you can find a list on Google's definition for SoftwareApplication.

Even if your project is FOSS, include offers but make sure to set the price to 0.

BreadcrumbList

BreadcrumbList is widely useful and should be included on all pages aside from the root page. It is used to describe the categorisation of a page, which isn't necessarily the actual path to the page.

{
  "@type": "BreadcrumbList",
  "@id": "https://hawksley.dev/blog/hack-club-shipwrecked/#breadcrumb",
  "itemListElement": [
    {
      "@type": "ListItem",
      "item": "https://hawksley.dev/",
      "position": 1,
      "name": "Home"
    },
    {
      "@type": "ListItem",
      "item": "https://hawksley.dev/blog/",
      "position": 2,
      "name": "Blog"
    },
    {
      "@type": "ListItem",
      "item": "https://hawksley.dev/blog/hack-club-shipwrecked/",
      "position": 3,
      "name": "The Shipwrecked Hackathon by Hack Club"
    }
  ]
}

BreadcrumbList describes the path of a page. By including one, you can control how search engines represent the path of a specific page.

Here, the search result for my blog post contains the path https://hawksley.dev › Blog. If your site already uses short paths, this node is a minor gain and can be omitted. However, if your paths are longer, BreadcrumbList is useful for shortening them.

CollectionPage

The CollectionPage node is a subtype of WebPage, usable for pages that primarily contain lists. For example, my /elsewhere/ page lists all my other profiles, and /blog/ lists all my blog posts.

{
  "@type": "CollectionPage",
  "@id": "https://hawksley.dev/elsewhere/#webpage",
  "url": "https://hawksley.dev/elsewhere/",
  "isPartOf": {
    "@id": "https://hawksley.dev/#website"
  },
  "name": "Elsewhere",
  "description": "Online profiles of Ethan Hawksley, a UK-based CS student. Links to his development, social media, technical writing, and security accounts.",
  "inLanguage": "en-GB",
  "about": {
    "@id": "https://hawksley.dev/#person"
  },
  "breadcrumb": {
    "@id": "https://hawksley.dev/elsewhere/#breadcrumb"
  }
}

You've met most of these properties already, so they are largely self-explanatory. Make sure you link breadcrumb to the correct BreadcrumbList! It needs to be the one on the current page for it to make any sense.

Blog

You should add the Blog node to your blog's index or home page. It acts as a stepping stone between your WebSite and the individual blog posts you publish.

{
  "@type": "Blog",
  "@id": "https://hawksley.dev/blog/#blog",
  "isPartOf": {
    "@id": "https://hawksley.dev/#website"
  },
  "mainEntityOfPage": {
    "@id": "https://hawksley.dev/blog/#webpage"
  },
  "name": "Ethan Hawksley's Blog",
  "description": "Technical blog of Ethan Hawksley, a UK-based CS student. Articles on systems programming, low-level computing, cybersecurity, and computer science.",
  "inLanguage": "en-GB",
  "dateModified": "2026-05-17T00:00:00.000Z",
  "publisher": {
    "@id": "https://hawksley.dev/#person"
  },
  "license": "https://creativecommons.org/licenses/by/4.0/"
}

dateModified is a good freshness signal, but if you don't have it handy, don't worry. Including license lets crawlers know under what circumstances they can use your prose.

If you've done prior research into JSON-LD, you may be surprised that the publisher property is set to be a Person, not an Organization. Although it used to require one, Google's documentation has since been relaxed and Person is entirely valid too, and arguably more accurate for a personal website.

BlogPosting

The last node we'll be covering is BlogPosting. It should be included on all published blog posts, providing added information to crawlers so they can more accurately represent them, including both more accurate placement and richer details in search results.

{
  "@type": "BlogPosting",
  "@id": "https://hawksley.dev/blog/need-for-post-quantum-cryptography/#blogposting",
  "url": "https://hawksley.dev/blog/need-for-post-quantum-cryptography/",
  "mainEntityOfPage": {
    "@id": "https://hawksley.dev/blog/need-for-post-quantum-cryptography/#webpage"
  },
  "isPartOf": {
    "@id": "https://hawksley.dev/blog/#blog"
  },
  "headline": "The Need for Post-Quantum Cryptography",
  "description": "Quantum computers are closer to breaking RSA and ECC than we thought. Learn what post-quantum cryptography is and how to start migrating.",
  "articleSection": "cybersecurity",
  "keywords": "cybersecurity, quantum",
  "inLanguage": "en-GB",
  "datePublished": "2026-04-13T00:00:00.000Z",
  "dateModified": "2026-04-17T00:00:00.000Z",
  "author": {
    "@id": "https://hawksley.dev/#person"
  },
  "publisher": {
    "@id": "https://hawksley.dev/#person"
  },
  "image": {
    "@type": "ImageObject",
    "@id": "https://hawksley.dev/blog/need-for-post-quantum-cryptography/#blogposting-image",
    "url": "https://hawksley.dev/og/blog/need-for-post-quantum-cryptography.jpg",
    "width": 1200,
    "height": 630
  },
  "license": "https://creativecommons.org/licenses/by/4.0/"
}

Since this is a personal site, it is alright for author and publisher to both point towards the same Person node. The image property should mirror the OG image that the post already uses for link previews.

Conclusion

Congrats, that's all the JSON-LD a personal site needs! I've structured this post to make it as easy as possible for you to copy-paste and implement into your own personal site. Even if you run a static site without a build step, you can still benefit from adding at a minimum WebSite, ProfilePage, and Person to the root page of your site.

If you have any questions, you can get in touch via email, and I'll do my best to help.

Mitigating Ongoing Registry Supply Chain Attacks

Sun, 17 May 2026 00:00:00 GMT

Supply chain attacks are a growing threat to software registries.

One of the first major typosquatting attacks on npm took place in 2017 when the user "hacktask" published a series of packages with similar names to popular libraries (e.g., crossenv vs cross-env), misleading people into installing them.

Then the first time an official package was compromised was in 2018, when the account of an eslint-scope maintainer was hijacked and used to publish malicious packages. These packages would exfiltrate the contents of developers' .npmrc files, often including their keys used for publishing new npm packages. This marked a turning point when attackers began harvesting credentials at scale, to fuel further attacks.

The recent attack - named Mini Shai-Hulud as a homage to the Dune sandworms - is a symptom of how broken the security of these registries is. It scans your system for API keys, creates public GitHub repositories containing said API keys, and abuses credentials to upload itself to other libraries, spreading its influence.

Software developers are large targets for malicious actors due to their unique position as both users and distributors. They can easily be compromised by a single library and spread the infection rapidly to all downstream users. Paired with keys to expensive cloud billing accounts and browser token-stealers, it's no wonder developers face these attacks so often.

Not all registries are at equal risk, npm is the worst offender by far. A recent report shows it contained 90% of all detected malware across a collection of registries. PyPI and crates.io both contain some malware, but their scale is dwarfed.

Mitigations

Despite the dangers associated with supply chain attacks, they can be mitigated. The easiest method is by setting a minimum-age on new packages. Most malicious packages from hijacked libraries last no longer than a few hours, so by setting an age-requirement of a week, the vast majority of threats can be foiled.

For npm, set the contents of ~/.npmrc to:

min-release-age=7

For pnpm, run the command:

pnpm config set minimumReleaseAge 10080 --global

For Bun, set the contents of ~/.bunfig.toml to:

[install]
minimumReleaseAge = 604800

For Yarn, run the command:

yarn config set --home npmMinimalAgeGate 10080

For uv, set the contents of ~/.config/uv/uv.toml to:

exclude-newer = "7 days"

For pip, set the contents of ~/.config/pip/pip.conf to:

[install]
uploaded-prior-to = P7D

Cargo has a minimum age feature as an RFC, but as of the time of writing it is not implemented in the client yet. Go has no such plans, nor do Maven or Gradle.

This mitigation is not without drawbacks. It's worth considering that delaying such installations by a week also delays any critical security patches, unless otherwise overridden. It's worth weighing up whether it is worth the trade-off.

Other Considerations

Aside from a minimum-age, there are a few other key changes worth implementing.

Firstly, ensure you have 2FA set up for all accounts that support it. It greatly limits the potential blast radius if you become compromised. I personally recommend Ente Auth - it's free, cross-platform, and supports optional E2EE cloud backups.

Secondly, if you are not using pinned versions or lock-files, you should be. They ensure that installed software versions will only change when explicitly updated. This gives you greater control over how and when you want to update, limiting your exposure to supply chain attacks.

Lastly, if your language supports post-install scripts, it's worth disabling them unless necessary. Especially in the JS ecosystem, post-install scripts are often abused to execute payloads immediately before you have time to react. In most circumstances, the feature is just an unnecessary attack surface.

Even with these mitigations, no project is immune. However, with enough common sense and precautions, you should be able to keep reasonably safe.

The Need for Post-Quantum Cryptography

Mon, 13 Apr 2026 00:00:00 GMT

The threat quantum computers pose to encryption is growing faster than many expected. Historically, the internet has relied on algorithms like RSA encryption and Elliptic Curve Cryptography (ECC) to exchange encryption keys and verify identities across the web. These algorithms are in danger of being entirely broken by the new capabilities of quantum computers, leaving our communications insecure. Modern breakthroughs in research are bringing us closer to this becoming a reality than we expected.

Quantum computers can be thought of as computers with fundamentally unique capabilities. Instead of using bits as memory, they use qubits. Quantum computers can run specialised "quantum algorithms" which, in some circumstances, are much faster than conventional algorithms[^1]. RSA and ECC seemed secure when we designed them, but as we research more about quantum computers, we realise that they are not secure at all. To resolve this, we have now designed post-quantum algorithms capable of securing data even after quantum computers are accessible. NIST finalised its post-quantum standards in 2024, introducing new post-quantum algorithms such as ML-KEM to replace the old vulnerable ones.

Shor's algorithm - the algorithm responsible for factorising the integers used in RSA encryption - has been improved and requires far fewer qubits than before. Google has also made quantum algorithms used for breaking ECC significantly more efficient. Major tech companies like Google, Microsoft, and IBM are competing to build bigger and faster quantum computers, bringing us closer to these quantum algorithms becoming possible. With these developments, the advent of quantum computing is closer than we had once expected. In response, Google has announced a 2029 timeline for using post-quantum cryptography, and Cloudflare has followed suit with their global network. It won't be long until other major providers follow.

In the course of researching this, I discovered that America's Cybersecurity and Infrastructure Security Agency surprisingly still doesn't support post-quantum cryptography. If you want to check some websites yourself, Cloudflare offers a free tool where you can enter any URL and check.

The Risks

Adversaries aren't waiting, even though experts in the field predict that quantum computers capable of breaking RSA are likely to be built in 10-15 years. They are already harvesting huge quantities of our encrypted communications - known as Harvest Now, Decrypt Later (HNDL) attacks - knowing they will be able to decrypt them later.

Adversaries aren't selective, they are collecting all the data they can get their hands on. Once quantum computers arrive, they'll decide what's worth decrypting. The question is simply whether your data will still matter in ten years.

On a personal level, private messages, account records, medical records, and biometrics are in danger of being exposed. Some sensitive data, like passport pages and credit card details, will likely have expired by then, so there isn't much risk for those.

For companies, trade secrets, source code, internal logs, and customer data pose great risk. Exposure of client information could lead to legal fines, and trade secrets risk losing your competitive advantage.

With governments, however, the stakes are highest. Foreign intelligence, real identities of agents in the field, military plans, and diplomatic communications are severe threats to national security.

No matter the scale you operate at, the transition needs to happen before quantum hardware catches up. That window is narrowing.

[^1]: If you're interested in more details about how quantum computing works on a fundamental level, I highly recommend the quantum.country essay, which goes into far greater depth.

Winning the Hack Club Campfire Hackathon

Tue, 03 Mar 2026 00:00:00 GMT

As leader of ComSoc at my school, I guide the Year 12 and 13 students and keep on the lookout for any new opportunities we can take part in.

A few months ago, we practised for the British Informatics Olympiad, a challenging set of three questions that required us to design accurate algorithms to solve. Over a short period, I had helped transform a group of enthusiastic Year 12 students into confident programmers capable of breaking down and solving complex problems.

Whilst looking for new events, I found Campfire, a team-based hackathon by Hack Club, where over the span of 12 hours, you design, create, and present a game, and the best teams receive prizes! Having previously competed in Daydream - a very similar game jam - I knew that this would be a lot of fun. After getting the members of ComSoc to split into teams and sign up, we were off to the races.

Preparing for Campfire

Nowadays, there's plenty of choice for how to produce and release a game. The event was restricted to only game engines that could be exported to run on the web. After some thought, I chose to use Godot as its beginner-friendly nature makes it the perfect candidate for teaching.

The members of my society needed some teaching, so after struggling through the pain that is Git credentials on Windows, I had them all set up and installed with the necessary software. After I ran a session on creating a simple platformer to bring them up to speed, I knew they were ready.

The Big Day

On the car journey over, I learned that the surprise theme was "Beneath the Surface", which started to give me plenty of ideas.

Once we all arrived at the location, I met up with my teammates. It took a little brainstorming, but we came up with the idea for our game. Inspired by the incremental games you often see in ads or see others playing, our game was to be based around a cat that goes fishing deeper and deeper into the ocean. Any caught fish could be sold to buy upgrades, allowing for even deeper levels to be reached. We named it "Cat-Fishing Frenzy".

Developing the Game

We began the event by first creating the assets we would need. I used Aseprite to design the pixel art for many of the fish that would swim in the sea.

Next, we laid the foundations. The main scene was created and populated with the cat, rod, and boat. After adding the fishhook, Ryley discovered a neat way to create the fishing line by just moving a point on a Godot Line2D.

func _process(_delta: float) -> void:
	set_point_position(1, to_local(node.global_position))

Ryley and I worked on fish spawning, whilst Sam implemented a currency and shop system. With each of us working on largely different areas of the codebase, Git merge conflicts were easy to solve and very infrequent.

After not too long, we had created the skeleton of a fully functional game! With plenty of time to spare, we introduced a couple of smaller mechanics, and the game received many balancing tweaks. After some polishing, the time was up, just in time for the pizza that the organisers ordered.

We presented the game to the other competitors, and then came a voting round. After a suspenseful wait, the results were in, with our game taking first place!

Retrospective

This hackathon was plenty of fun to attend, and winning it was the icing on top. Lots of nice prizes were dished out, but I really enjoyed getting to know the people I was working with better. Programming under strict time constraints was excellent practice for my efficiency and teamwork skills, and I look forward to further opportunities in the future.

If you're curious, you can play Cat-Fishing Frenzy here on itch.io. You'll need the arrow keys to move the hook, so no mobile compatibility at the time of writing.

The Shipwrecked Hackathon by Hack Club

Wed, 11 Feb 2026 00:00:00 GMT

Last April, I was minding my own business when I received a curious email in my inbox.

Hack Club is renting an island.

We are hosting a hackathon.

Anyone who ships 4 projects gets to come. Flight stipends available!

Dates are August 8th - 11th. Boston, USA.

I'd signed up for Hack Club mailing lists in the past since they run a variety of coding activities. However, this email particularly stood out to me. I've always wanted to visit America, and it seemed like they would be offering me a free flight!

Following the link led me to a sign-up page where I entered my details to register my interest. I spread the word about this event to the other coders I knew, and soon it reached the 5,000-signup threshold to be given the green light.

Hack Club is a non-profit organisation that has received some generous donations in the past, but they still can't afford to give away such a great trip for free. To earn my place at the event, I needed to pass The Bay.

The Bay

The Bay was an online platform designed by Hack Club specifically for this event. You tracked your time spent coding projects with their WakaTime server Hackatime and submitted any completed projects for review by the Shipwrecked moderators.

Approved projects granted you a number of "shells" relative to how many hours were spent creating the project. These shells could be spent on many different items from their shop, from Flipper Zeros to 3D printers. However, the grand prize was a ticket for the Shipwrecked hackathon in Boston. This cost the small sum of 60 hours total. Travel stipends were also available, at a conversion rate of 1 hour coding → $10 grant towards a flight.

After checking Skyscanner to see return flights would charge an entire £400 (~$550), I checked the clauses for Shipwrecked and saw that if I programmed for 100 hours total, they would fully cover my flight regardless of how expensive.

Now I had the 100-hour goal in mind, it was time to start programming.

Some Notable Projects

Gravify

I had found an interesting library called html-to-image that could convert DOM elements into images I could manipulate with JavaScript. While that library was sitting in the back of my mind, I stumbled across the Matter.js physics simulation library. The library supported custom PNGs as input to the physics simulation, so I decided to combine these two libraries and recreate something very similar to Google Gravity.

Going through the MDN Web Docs to learn how to build a browser extension was far smoother than I had expected. I was comfortable writing JavaScript, and not much boilerplate was required to hook into the Browser APIs. After not too long, Gravify was created.

Turing Machine Simulator

After visits to Bletchley Park and diving into more theoretical computer science, I knew I wanted to build a Turing machine.

Turing machines are a model for computing first devised by Alan Turing in 1936. They consist of an infinite roll of tape marked out into squares, a "head" that points to a single square at a time, and a set of states and instructions. Each cycle, the Turing machine reads the value of the tape underneath itself, compares it to the corresponding instruction, writes a new symbol onto the tape, and finally either moves left or right along the tape.

Despite their limited nature, they can provably carry out any calculation and are often used for proving new theorems in computer science. I did some research and couldn't find a simulator online that I was content with using, so I built my own.

I was still studying a React course at the time, so I wasn't fully confident building UI with JSX components. This led to a lot of repetitive code.

const rightOption = document.createElement('option');
rightOption.value = 'Right';
rightOption.textContent = 'Right';
// ...

Looking back at it, it is quite brittle and challenging to debug, but I can thank my understanding of JavaScript fundamentals for framework-less code like this.

Reaching America

As soon as I got the official go-ahead from the organisers, I booked a flight ready to set off for Boston.

Coming alongside me were two friends who also qualified for the event. They had put in the hours to earn tickets, and we all came over together.

The flight took a long eight hours, but after not too long we finally reached America.

Once we arrived at the airport, we set off to EDIC Pier where we laid our picnic blankets and bought some local food. I got to know the other contestants who were there. Many were American, but surprising numbers were from all across the globe, with one even as far as Vietnam!

It didn't take long until we began to set off towards Cathleen Stone Island. The ride was short but a great opportunity to chat with the other people there and take some photos. By the time we finally reached the island, we had already decided on the structure of our teams.

Everyone scrambled to claim their beds, but as one of my projects had gone viral, I was given first pick and stayed in the executive suite with the other viral programmers. It was here that I met Daniel, another participant who managed to go viral, and formed a team with him and Oliver.

By the end of the day, we were all invited down to the pavilion to learn about the first project we would be assigned. This hackathon had three projects that we would make in total, each themed around a certain idea. The first project was to design a method of communication that wouldn't involve letters or numbers.

SymbolNotes

In my team, we decided to create an online peer-to-peer messaging app. Since I had prior experience with the PeerJS library, I suggested that we use that.

As per hackathon tradition, the code we made was hacky, and the graphics were rough, but we managed to create a working solution. We released the source code for SymbolNotes onto GitHub so others could examine and learn from it. We made it together over the course of a morning and submitted it onto The Bay.

Exploring The Island

With our project complete, we spent the rest of the day exploring the island as a team. The executive suite and pavilion were both very close to the docks, but there was the entire rest of the island still to investigate.

Alongside us were some Americans who knew the area much better than we did and told plenty of stories about what it was like living in America. As somebody who'd only set foot outside Europe once before, it was very refreshing to hear such different perspectives.

Before long, however, it was back to the next challenge.

Connect Infinity

Our next challenge was to design a creative game that could be played online. We decided to put a spin on the classic game Connect 4 and make it real-time. To prevent it from ending extremely quickly, the game only ends once the entire board is full. Every 4-in-a-row gives a point, most points win.

Now the team had got used to PeerJS, we decided to use it once again here as it seemed perfectly suited for the task. As a challenge, we designed the code so that lobbies of unlimited size were supported, instead of just groups of two.

This took more time than the previous project due to its larger scope, but we worked as a team much more efficiently. After a few tireless hours, Connect Infinity was created just in time to present.

We took laptops down to the pavilion and set them up running the game by the shore. The other participants all tried out the game, and it was surprisingly well received! We managed to win a limited-edition Shipwrecked shirt, which I still have and wear to this day.

Perlin Colours

Our final task was to create a project that heavily featured a variety of colours. One of our team had the idea to create a Perlin noise generator that could create plenty of colourful gradients. We decided to name it Perlin Colours.

After some research on the formulas involved and a fair bit of trial and error, we ended up with a functioning noise generator implemented with HTML Canvas. I had dabbled with Canvas before, but this was the first time I had implemented a proper renderer using it.

We ended up sleeping on the problem, but once we woke up, we were fully refreshed and fixed the final bugs with the implementation. It was very satisfying to have a proper end product.

The project was presented, and it went down a treat! The prizes were limited-edition laptop stickers that I have proudly stuck onto my laptop ever since.

Returning Home

Alas, all good things must come to an end. It was the final day, so I gathered all my belongings and packed them away into a suitcase. My team attended the closing ceremony and said our goodbyes to the people there. There were so many nice people I met, and I'll cherish the memories made forever.

I caught an Uber alongside some others also needing a flight back and returned to the airport. It was there our team finally disbanded. One amusing thing at the airport was the Hack Club official plushies were just over the weight limit and were tripping all the security alarms. I got through just fine, but it caused a right mess!

It was then I also got to see my very first American passport. Having only seen European ones, it was a right culture shock with pages full of landmarks and a giant eagle on the photo page.

The actual flight was thankfully uneventful. I watched the in-flight entertainment and ate the food, but slowly drifted off to sleep until we landed.

Reflections

Participating in Shipwrecked is an experience I'll remember forever, and I thank Hack Club and the organisers for helping set up such a wonderful event. I have still maintained contact with several of the other people there and arrange to meet up with them at future hackathons.

It was also very enjoyable working in teams. Having spent so much of my time programming solo, it was nice bouncing ideas back and forth to come to informed conclusions.

I've done many other things with Hack Club since, but they are perhaps a story for another blog post...

One thing you can take for granted is that I'll absolutely be doing more hackathons in the future!

Building An Astro Blog

Wed, 04 Feb 2026 00:00:00 GMT

I've owned the domain name hawksley.dev for a while now, but I've never done much with it aside from sending email. Over the weekend, I thought I might as well make good use of it and decided to create a blog.

In the beginning, this site had a humble home page with some links to GitHub projects. A blog requires much more infrastructure for me to use it effectively. For one, it'd be great if I could just write my posts in Markdown and have them formatted by my project automatically. Having a look at the options available, the first that stood out was GitHub's Jekyll. It looked nice and had great integration with GitHub Pages, which I'm hosting with at the time of writing. However, it just felt too rigid. I needed something modern that I felt I could get my hands dirty with.

Enter Astro.

Why Astro

In the grand scheme of things, the Astro framework is pretty new at just 5 years old. That hasn't prevented it from gaining popularity rapidly. It holds performance as a key design principle, anything that can be static will render statically. By default, it ships absolutely no JS to the browser, which felt perfect for my use case. I have no need for advertising or heavy tracking scripts weighing down my site. All I need is a place to write.

Learning how to work with Astro was completely painless. I created a new GitHub repository and followed along with their very high-quality documentation to create a blog of my own. At the very end of it, I’d created a nice neat blog that loaded instantly and was easy to write for.

I wasn't satisfied by using the tutorial's blog for my site, though, as it felt too cookie-cutter, and so I started again, now with confidence in the framework.

The Design Decisions

There were some definite design decisions I knew I wanted from the get-go. First-class light mode and dark mode support were a must. Plenty of blogs offered just one or the other, and after a bit of digging, it didn't seem technically hard to implement at all.

Another key principle was mobile-first design. Many of my previous projects started with the key assumption that the reader will be on a laptop or desktop, but that often isn't the case. Mobile devices account for approximately two-thirds of global internet traffic, with the remaining third coming from desktops. I wanted this site to stand the test of time until I inevitably rebuild it again, so it's only natural I designed it with mobile devices in mind.

My final decision I knew I wanted was to have excellent performance scores, one of the very reasons that I chose Astro for the job. Components are almost a certainty in modern web design to ensure consistency across pages, but I needed to write components used at compile time, rather than at run time.

Actually Programming the Site

After creating an experimental fork of my main repository and wiping the directory, I initialised a new blank Astro project with pnpm create astro@latest and scaffolded the directory structure I'd need.

public // Assets such as robots.txt and favicons.
src
  assets // Any assets displayed in the actual site.
  components // Reusable components representing sections of UI.
  content // Markdown files representing the blog.
  layouts // The base layout each page uses.
  pages // The actual pages rendered, combining all parts together.

Development went very smoothly over two days and 15 full hours, with only some minor hiccups along the way.

Google's PageSpeed Insights flagged my planned accent colour International Orange #FF4F00 as having insufficient contrast in light mode, so I had to split into separate accents for light and dark mode. By using global CSS variables that change depending on the theme, I implemented this change painlessly.

I also encountered some CLS issues surrounding my choice of font. I personally love the look of the Inter font and included it in my project[^1]. However, although 300 KiB may not sound like a lot, on a slow connection it’s a noticeable delay. After some research I discovered the fontTools library and managed to shrink the Inter font to 70 KiB by subsetting the font to only the character sets I need.

The Conclusion

Astro has been a pleasure to work with, and I can easily see myself using it in future projects now I've adjusted to it.

A perfect score has got to be one of the most satisfying feelings after doing a site redesign.

[^1]: I'm now using IBM Plex Sans and IBM Plex Mono, but they are subsetted to 62KiB and 9KiB respectively, so the advice still holds.