Many moons ago I would write web applications using technologies like PHP or Python to directly serve web content – often using templating engines to more easily handle data display. These apps would thus ship server-side rendered plain HTML, along with a mix of browser-native forms and AJAX (sometimes with JQuery) for some interactivity and more seamless data submission. I’d use additional lightly-sprinkled JavaScript for other UI niceties.

For the past ten years or so, this all changed and my web apps – including those developed as part of my work and nearly all of my side projects – switched to using front-end frameworks, like React or Vue, to create single page apps (SPAs) that instead solely consume JSON APIs. The ease of adding front-end dependencies using npm or yarn, advancements in modular and “importable” JavaScript, and browser-native capabilities like the Fetch API’s json() function encouraged this further, and the ecosystem continued to grow ever larger. Front-end code would run entirely independently from the back-end, the two communicating (often) only via JSON, and with both “ends” developing their own disparate sets of logic to the extent where progressive web application front-ends could leverage service workers and run entirely offline.

HMRC’s Making Tax Digital

Making Tax Digital (MTD) is part of the UK Government’s plan for modernising the tax system for both businesses and individuals.

For years, HMRC (the Government’s tax department) has had an online tax system that is infamously complicated and slow to use and update such that even accomplishing simple tasks can be long and painful processes. Part of this is due to the laughably complicated UK tax system itself (rather than the fault of the technology), but some of it can certainly be attributed to the antiquated tooling.

I recently signed the web0 manifesto, which embodies many of the values I consider to be important when it comes to technology - and the web in particular.

web0 is the decentralised web… web0 is web3 without all the corporate right-libertarian Silicon Valley bullshit.

– The web0 manifesto website

Essentially web0 is around empowering a decentralised web that:

• Is available and truly accessible to everyone;
• Minimises the barriers to entry for all;
• Enables people to own and control their own data (sovereignty);
• Enables people to move, remove, or modify their own data;
• Avoids the naturally-occurring centralisation when utilising big-tech services;
• … And therefore puts the web back in the control of individuals rather than a small number of huge companies.

In practice this could mean owning your own domain name and taking part by hosting a website or through getting involved in other communities, such as in the tildeverse. The key thing is that participants own and can control their own data and that things are accomplished without needing to rely on big-tech.

I’ve recently been reminiscing about the “old” days of the web. They felt much more like expressions of personality and creativity.

These days, most people have social media accounts on mainstream services that act as their sole representation of themselves online. Whilst the content can be different, everyone’s own pages end up looking the same, with avatar images, feeds, and other components having layouts and “look and feel"s controlled by the service - the creativity is lost and things become bland.

Another podcast I frequently listen to likely needs no introduction of its own. The This Week in Tech (or just “TWiT”) network’s flagship podcast - also called TWiT - must be one of the longest-running tech podcasts.

The podcast series started back in 2005. It runs weekly, with episodes recorded live each Sunday evening and made available via podcast clients shortly afterwards.

It is hosted by Leo Laporte, who is joined by interesting and varied panelists from across the tech sector. Episodes feature light-hearted discussion of recent news and insights from the technology world.

For many developers, the notion of adding accessibility features - such as image alt text attributes to web page images and integrations with host usability enhancements, such as screen-zoom and text-to-speech - might feel like a chore. Especially for those still in the startup or “do things that don’t scale” phase.

It should no longer be about “adding” accessibility features any more than one these days “adds” a mobile-friendly version of their site (long-surpassed by responsive design and mobile-first pricinples) or even “adds” a button to perform a specific task. Accessibility features are a core part of any product, and should factor into the software development process right through from requirement engineering through to planning, design, implementation, and testing.

Recently I’ve noticed that some of the RSS feeds I subscribe to have become more and more restrictive. A post might contain just a title, or perhaps a short snippet or introductory paragraph, with the expectation that I then proceed to follow the link to visit the website itself in order to view the post in full.

I suppose in many ways that this is similar to distributing podcasts via RSS: the feed contains the podcast title, description, and other metadata, and then a link to download the podcast episode file itself. But this is because podcasts are in audio or video format and cannot be reasonably embedded directly into an XML file.

Like many people, I own and manage multiple email accounts - for example, some are for work, for home, or for specific projects. I used to be a strong user of solely web-based email clients (such as Gmail or Fastmail’s web apps) for each of my accounts. However the number of tabs I needed to keep open for all of this grew to the point where things became unmanageable - both in terms of needing to check multiple tabs several times per day and also frustrations when the browser would restart, or if I’d lose my tab setup for some other reason.

Simple and RESTful HTTP APIs

The HTTP standard is an expressive system for network-based computer-computer interaction. It’s a relatively old standard - it started life as HTTP/1.0 in 1996 and the HTTP/1.1 standard was formally specified in 1999. HTTP/2 (2015) introduced efficiencies around how the data is transmitted between computers, and the still in-draft HTTP/3 builds further on these concepts.

I won’t go into the nuts and bolts of it, but - essentially - for most applications and APIs, the developer-facing concepts haven’t really changed since HTTP/1.1. By this version, we had all the useful methods required to build powerful and flexible APIs.

I recently finished reading The Hunt for Red October by Tom Clancy.

This genre of novel (sort of military thriller fiction) is not usual for me and this is the first Clancy book I have read. That being said, the book has been on my “to-read” list for a fair amount of time and so I am glad I got round to reading it.

By now I’m sure everyone has heard the horror stories about people (seemingly-) randomly losing access to their Google accounts. Often the account closures are reported to have been accompanied with vague automated notifications from Google complaining that the account-holder violated their terms in some way, but without any specific details or an offer of appeal or process to resolve the “issues” and reinstate the accounts.

As such, these events usually mark the end of the road for the victims’ presence and data on Google platforms - including Gmail, Drive, Photos, YouTube - without having any option to extract the data out first. This could be years’ worth of documents, family photos, emails, Google Play purchases, and much more (ever used “Sign in with Google” on another service, for example?).

A few months ago I stumbled across this article: Beyond Cyberpunk: Towards a Solarpunk Future. It was posted on the excellent blog Tales from the Dork Web, by Steve Lord, which I can certainly recommend subscribing to.

I had never heard of the term “Solarpunk” before, but I read up more about it and the more I researched the more intrigued I became. Essentially it is defined as - more or less - the opposite to the Cyberpunk subculture, and I think we’re at a bit of a fork in the road from which either future could become a reality.

This month marks a year from when I decided to (mostly - see below) stop answering my phone. This was not because I wanted to be antisocial (quite the opposite), but because it’s become the wrong form of communication for me.

Why did I stop?

Like many people, I am inundated with sales-y and spammy phonecalls. I have had the same mobile phone number since 2001 (that’s 20 years this year), which I am sort of proud of and would prefer to keep. However, careless (or malicious) entities over the years (and more than likely mistakes also made by my younger self) have meant that my number and name are now in the databases of many different types of agents - from insurance/legal company sales teams through to dodgy Bitcoin spam companies.

Many people would consider RSS - Really Simple Syndication - to be a relic of the past. However I think it has been making a comeback.

RSS is a mechanism by which people can automatically receive updates from individual websites, similar to how you might follow another user on a social networking service. Software known as RSS readers can be used to subscribe to RSS feeds in order to receive these updates. As new content (e.g. a blog post) is published to an RSS-enabled website, its feed is updated and your RSS reader will show the new post the next time it refreshes. Many RSS readers have an interface similar to an email client, with read/unread states, folders, favourites, and more.

If you need a database for your next project, why not first consider if SQLite might be a good option? And I don’t mean just for getting an MVP off the ground or for small personal systems; I mean for “real” production workloads.

Many people will be quick to jump on this with chimes of “it’s not designed for production”, but I think it depends on what is actually meant by “production”? Sure, it’s not the right choice for every scenario - it wouldn’t work well in distributed workloads or for services expected to receive a very high volume of traffic - but it has been used successfully in many real-world cases.

If you’ve visited my geminispace (gemini://wilw.capsule.town) you’ll have noticed that I’ve recently been on a mission to decentralise the every-day tools and services I use, and will understand the reasons why. This post will likely become part of a series of posts in which I talk about taking control and responsibility for my own data.

One of the changes I’ve made more recently is to move many of my own personal projects (including the source for this site) over to a self-hosted Gitea service. I chose Gitea personally, but there are many other self-hosted solutions available (see this post for examples and comparisons).

Building apps on serverless architecture has been a game-changer for me and for developers everywhere, enabling small dev teams to cheaply build and scale services from MVP through to enterprise deployment.

Taking advantage of serverless solutions - such as AWS’ Lambda, Google’s Cloud Functions, and Cloudflare’s Workers - means less resource is spent on traditional dev-ops and deployment and, especially when combined with tools like Serverless framework and its rich ecosystem of plugins, you can use the time instead to better develop your products. Let the provider worry about deploying your code, keeping your services highly available, and scaling them to meet the needs of huge audiences.