Jeremy Keith

Jeremy Keith

Making websites. Writing books. Hosting a podcast. Speaking at events. Living in Brighton. Working at Clearleft. Playing music. Taking photos. Answering email.

Journal 2872 sparkline Links 9507 sparkline Articles 81 sparkline Notes 6398 sparkline

Saturday, May 14th, 2022

Checked in at Vine Street Tap. Daydrinking — with Jessica map

Checked in at Vine Street Tap. Daydrinking — with Jessica

map

Checked in at Loam. Coffee and a sandwich — with Jessica

Friday, May 13th, 2022

Thursday, May 12th, 2022

Cautionary Tales from Cryptoland

This quote from the brilliant Molly White is about web3/blockchain/cryptobollocks but it applies to evaluating technology in general (like, say, JavaScript frameworks):

I firmly believe that companies first need to identify and research the problem they are trying to solve, and then select the right technology to do it. Those technologies may not be the latest buzzword, and they may not cause venture capitalists to come crawling out of the woodwork, but choosing technologies with that approach tends to be a lot more successful in the long run — at least, assuming the primary goal is to actually solve a problem rather than attract VC money.

Wednesday, May 11th, 2022

map

Checked in at Jolly Brewer. Session 🎶☘️🎻 — with Jessica

The Demise of the Mildly Dynamic Website

It me:

Broadly, these are websites which are still web pages, not web applications; they’re pages of essentially static information, personal websites, blogs, and so on, but they are slightly dynamic. They might have a style selector at the top of each page, causing a cookie to be set, and the server to serve a different stylesheet on every subsequent page load.

This rings sadly true to me:

Suppose a company makes a webpage for looking up products by their model number. If this page were made in 2005, it would probably be a single PHP page. It doesn’t need a framework — it’s one SELECT query, that’s it. If this page were made in 2022, a conundrum will be faced: the company probably chose to use a statically generated website. The total number of products isn’t too large, so instead their developers stuff a gigantic JSON file of model numbers for every product made by the company on the website and add some client-side JavaScript to download and query it. This increases download sizes and makes things slower, but at least you didn’t have to spin up and maintain a new application server. This example is fictitious but I believe it to be representative.

Also, I never thought about “serverless” like this:

Recently we’ve seen the rise in popularity of AWS Lambda, a “functions as a service” provider. From my perspective this is literally a reinvention of CGI, except a) much more complicated for essentially the same functionality, b) with vendor lock-in, c) with a much more complex and bespoke deployment process which requires the use of special tools.

Reinventing W3C Governance

To be honest, I’m not all that convinced by Robin’s arguments here about overhauling the governance model at the World Wide Web Consortium (partly because the way he describes the current model sounds pretty okay to me). But I’m very interested in what he has to say in the broader philosophical sense about using values to solve problems:

A value is worth something if it’s there to help you when the rubber hits the road and starts hydroplaning. Sure, you’ll need a handful of high-level lofty values as reminders, if only because there’s always a vocal guy (it’s always a guy) who thinks it’s just outrageous to put people before profits. But mostly you want Values You Can Use.

That might be the best description I’ve come across yet for design principles: values you can use.

When we say that engineering is about trade-offs, we’re saying that engineers solve their hardest problems using values (which they call “heuristics” because everyone’s entitled to be fancy some). In implementing a system, you might need to decide between an option that provides people with the best experience, another that delivers the greatest value to the shareholders, and yet a third one that makes the control centre blinkenlights dance in the prettiest way.

Tuesday, May 10th, 2022

Agile design principles

I may have mentioned this before, but I’m a bit of a nerd for design principles. Have I shown you my equivalent of an interesting rock collection lately?

If you think about design principles for any period of time, it inevitably gets very meta very quickly. You start thinking about what makes for good design principles. In other words, you start wondering if there are design principles for design principles.

I’ve written before about how I think good design principles should encode some level of prioritisation. The classic example is the HTML design principle called the priority of consitituencies:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

It’s wonderfully practical!

I realised recently that there’s another set of design princples that put prioritisation front and centre—the Agile manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

And there’s this excellent explanation which could just as well apply to the priorty of constituencies:

That is, while there is value in the items on the right, we value the items on the left more.

Yes! That’s the spirit!

Ironically, the Agile manifesto also contains a section called principles behind the Agile manifesto which are …less good (at least they’re less good as design principles—they’re fine as hypotheses to be tested).

Agile is far from perfect. See, for example, Miriam Posner’s piece Agile and the Long Crisis of Software. But where Agile isn’t fulfilling its promise, I’d say it’s not because of its four design principles. If anything, I think the problems arise from organisations attempting to implement Agile without truly internalising the four principles.

Oh, and that’s another thing I like about the Agile manifesto as a set of design principles—the list of prioritised principles is mercifully short. Just four lines.

Sunday, May 8th, 2022

map

Checked in at Ovingdean Gap Cafe. Stopping for an ice lolly, a nice cup tea and a sit down — with Jessica

Saturday, May 7th, 2022

Friday, May 6th, 2022

Checked in at Baker Street Coffee. Flat whites — with Jessica map

Checked in at Baker Street Coffee. Flat whites — with Jessica