Journal

I'd been out of a job for a while and a opportunity came up with a company in an industry that I'd not worked in before. After the first interview they asked me to write something - anything - that was unique to me. So I wrote Ferocious Beasts Top Trumps.

Honestly, the hardest part of the task was coming up with something I'd not done before but that I could accomplish in a relatively short time frame. Card-based sites are generally pretty useful to show off responsive layout knowledge, and that lead me straight on to Top Trumps - a game that I played as a kid a long long, long long time ago.

Essentially the app is clawed together from a couple of sources, and then written around a fairly dumb computer opponent. The project structure/CSS layout was ripped from my Walking Journal, the images from various sources on the internet for which I should probably go back and try figure out the attributions. The computer opponent is basically just choosing stats at random. But it seems clever. Like a seven-year old boy, perhaps.

From Stephanie Eckles' CSS newsletter:

CSS Nesting will be in all evergreen browsers as of Firefox 117, landing August 29... the nesting syntax has been relaxed and will eventually not require nested selectors to begin with a symbol, meaning "&" is not necessary before an element selector.

So I decided to side-step the multi-page process on the journal for a moment and take a look at Vue and Svelte. Vue is slighter younger than React with Svelte - the baby - arriving in 2016. I'd wanted to work with them for a while but never really had a good plan or project in which to use them. But as a way to introduce myself to their component systems, and understand their basic feature-set, incorporating them into the journal was ideal.

The groundwork for introducing them was simple. Similarly to the vanilla JS and Preact component systems they would take advantage of the global CSS so it's really just a matter of changing the syntax of either the Preact or vanilla systems to their syntax.

Vue was done in three hours; Svelte a little longer - simply because I spent more time reading its documentation.

A couple of interesting things that cropped up while I was testing the output:

1. In Vue you can have nested template elements which are very useful when using iteration to create a series of components with the proper semantic markup. Vue attaches directives to a containing element:

   <section v-for="item in items" :key="item.id">
   

   Usually, you want that element as part of the component. And you don't really want to create another containing component because that adds causes unnecessary markup. So by using a nested template which doesn't add any new markup:

   <template v-for="item in items" :key="item.id">
   

   you can move that section container within the component markup and have the components render properly. If you're a React developer it's the equivalent of a fragment.

2. One CSS issue that cropped up was some suspicious missing spacing on rendered tags which had to be corrected with an additional 0.25rem on each tag's right margin. I've not narrowed down why but I think it has something to do with point 1). The problem happens with the Svelte system too so I figure if I can fix it for one I can easily fix it for the other.^[1]

3. Fortunately I didn't have to do any CSS module wrangling or make any changes to Vue/Svelte configuration to make them work. You just import them directly within the script tags.

4. I do like Svelte but their method for props-sharing is a little counter-intuitive and there isn't a lot of documentation on why they've chosen this route (I'm not sure "you'll get used to it" counts). In short the component that has props being passed to it has to export those props from it (export let prop;).

5. markdown-it, which I use to parse the markdown into HTML so I can parse that and get some nice JSON, has different output for an ordered list (ol) and an unordered list (ul). I would have expected them to be the same but MDIT pads the list items with paragraph elements. And that meant a little fiddling with my parse-markdown tool so it didn't pick up those nested paragraphs and render them.

6. Added a markdown-it plugin for footnotes which, after a little work on my parse-markdown tool seems to be working well.

I'm going to add to my knowledge of both libraries soon with rewrites of my Walking Journal as a baseline. And then maybe I'll take a look at some web component libraries like Stencil. It's turning into quite a fun project.

1. Turns out that the issue was extra whitespace in the vanilla tag template which could be resolved by adding .trim() to the rendered string. ↩︎

Over the last few weeks I decided to revisit the code and markup for this site to try to address an issue that a lot of developers are having this year - whether the last decade of prioritising front-end development tooling and developer experience (DX) has had an inverse effect on user experience (UX), and whether we now just pay lip-serice to accessibility and performance.

In my personal projects I'm generally very frugal when it comes to introducing new libraries into a tech stack. In order to do this I do a lot of experimentation. For example, this site in particular has undergone various iterations over the last few of years with markdown as the only consistent component.

Initial stage

React, Redux, and an Express server hooked up to Google Drive. The journal markdown was stored on GD which allowed me to access and update it easily from any device.

Second stage

Preact, Signals, Express, Google Drive. This was really a test of Preact's capabilities, to work out how Signals worked, and to see whether they were a decent alternative to other popular state management libraries. Preact's added value was a significantly reduced bundle size.

Current stage

Here I wanted to strip back all the technology to the bare minimum and achieve a good balance between DX and UX. I wanted to use the capabilities of component-based design but with a renewed focus on performance and accessibility. In short I wanted a way to design the front end with today's component-centric technology but then be able to export that into plain HTML/CSS to keep performance costs low, and retain good UX and performance.

To keep things minimal:

• I created a JS script to convert the journal markdown to JSON.
• I wrote a component library using template strings. The parsed JSON is imported and passed into the Journal component, and the layers of components built from each entry in the data.
• I used CSS modules that I could extract out into a minified core CSS file.
• No client-side JS.
• Images are now hosted locally, and they are converted to webp format.
• A Rollup configuration builds and gzips the developed code and CSS, and a separate JS script minifies the HTML, and merges all the relevant files into one folder ready for deployment.

Total minified HTML/CSS size: 33K.

The next stage will be to use the component library and some templates to create separate entry pages.

Just finished watching The Dish - the fictional account of the Parkes Observatory and the team that worked there during the Apollo mission. But because it was "based on" the actual events the film-makers used fictional characters.

But I managed to unearth this brilliant photo of the actual operations team.

Back row left to right: Alfred Stella, George Kropp, William Reytar (back). Seated: Robert Taylor.

This is the view from the other side of Sandwich Bay where it hugs the Cliffsend coast to the south of Ramsgate Harbour. This looks back toward the Bay, and is the outer reach of the low tide. Here the North Sea drains away to leave vast stretches of sand for the thousands of sea birds that make their home here.

Took a walk with my Dad along the coast at Sandwich Bay. The tide was rolling out as we arrived, and slowly merged with the horizon as we walked along towards Shellness Point where the seals basked in the low Autumn sun."

Today I implemented basic responsive images for this site in order to improve the performance, and it took less than an hour thanks - mainly - to Flickr.

When you upload a new image to Flickr the service will automatically create and host new sizes of that image. Those copies can be requested through a simple http request (no need to use the API if you don't need to) according to a simple formula: filename[_sizeId].jpg.

For reference here's a list of the sizes along with their sizeIds based on an original image size of 2592x1456. Those marked with an asterisk are those sizes used for the devices that might visit this site.

"When I descend beneath the surface I am in a world with different rules, different truths. Things look different, light acts differently, gravity pulls differently. One can fly, or at least float over the landscape, or seascape. When I descend into this wonderland, I want to make images, not to explain or clarify that world, but to deepen the mystery." - Wayne Levin

This is the pond I was lazing by when I heard the sad news that Sam Shepard had died.

This site is an on-going React/Redux project to build and maintain an online static-site generated journal that looks good on both mobile and desktop. Initially this was going to be a one-shot experiment, but as I lean into different tech each month this has become a useful battle-tested area for me to test each tech out.

In the first release, for example, I decided to not implement Redux so I could concentrate on the React component workflow instead. I added Redux in the second release. And, while I'm a fan of CSS modules, it makes sense to start testing CSS-in-JS here too to see what all the fuss is about.

Process breakdown

All the text on this site was generated from a markdown file (currently only 4k in size) hosted on my Google Drive account.

I use Express to grab that file every 30 minutes, wrangle the data into an array of entries, and store it. There is a single API route /entries that React uses to get the data.

Once the site is loaded I use redux-thunk to grab the data from the server and store it in a Redux state for React to use. React-router 4 provides a stable routing interface.

This system means I can update the markdown file whenever I want from either my desktop or phone without the hassle of accessing a site admin panel to add a post knowing that within 30 minutes those words will be available on the site.

A walk from Embankment, up The Mall to Buckingham Palace, along Green Park, up to Hyde Park, through the park along the lake with the talkative geese, across to Kensington Palace Gardens, and finally out on to the road and on to Earl's Court.

It comes as a surprise to many people, even to those who have lived in the area, that the water that plays along the coast around Broadstairs, Ramsgate, Sandwich, and even Deal, is not the English Channel, but the North Sea.

If you were to imagine a line that crossed the sea in an ENE direction from Leathercoate Point, where the war memorial commemorating the Dover Patrol stands North of St. Margaret's Bay, to Walde Lighthouse just North of Calais, that line demarks where the Sea becomes the Channel.

This is one of the many images rendered by my spotmaps application.

From the original site:

Spotmaps, based on Brendan Dawes' Cinema Redux, is an on-going project to map the colour narratives of different films.

Films are processed through a Python/OpenCV pipeline: each frame's colour is sampled, and a spot of average colour is produced from the combination of one second's frames.

Spots are laid out 60 per line to represent one minute of film time. The length of the image represents the number of minutes in the film.

A 24-colour Adobe swatch file in ASE format and a hex RGB colour file are available to download for each spotmap.

More images can be found here on Flickr.

There are also a couple of online articles about the spotmaps website on FastCoDesign, and Gizmodo.

Nan is on the right.

Organised the first Kent miner's strike.