cjwainwright.co.uk

Hair

Sat, 19 Dec 2020 00:00:00 GMT

When God closes a door

Sun, 09 Aug 2020 00:00:00 GMT

Friendship

Sat, 11 Jul 2020 00:00:00 GMT

Pooh and Friends

Fri, 05 Oct 2018 00:00:00 GMT

What would Winnie the Pooh and Friends look like if they were real animals. Well, this is not fully realistic but you get the idea, Pooh is pretty intense!

Pine Cone

Sat, 29 Sep 2018 00:00:00 GMT

A sketch of a pine cone, done as an exercise in patience.

Bee

Sun, 20 May 2018 00:00:00 GMT

Trying out a mechanical pencil for drawing, it's good for details. Here's a drawing I did of a bee, from a photo I took of a bee!

Star Wars

Sat, 30 Dec 2017 00:00:00 GMT

Trying to get back into some drawing after a little while, here's some sketches of Star Wars characters!

Luke and Leia

Rey

Kylo Ren

Rose and Finn

Caching single page applications

Thu, 08 Sep 2016 00:00:00 GMT

One of the key features of single page applications (SPAs) is that they serve the exact same html page to the browser irrespective of the URL you visit. This html defines the framework of the app, I'll refer to it as the app html. In the following example we analyse how caching of the app html would behave in a typical SPA, and then we look at what we can do to improve it.

Imagine that this week's fad is a website which allows you to watch videos of certain pets. Let us also assume that this website has been written as a SPA.

An email shows up in my inbox:

Of course I follow the link, and my cache being empty for this site I download the app html and all the resources linked from it.

Let's ignore the extra resources the app html requires as these can be versioned and cached outright at a fixed URL, they're not really an issue for subsequent visits. Our simplified situation looks like this.

Now if I revisit that same URL, my browser can serve the app html directly from the cache, with possibly just a revalidaton request and 304 not modified response from the server, assuming the appropriate caching headers were set. However...

Later in the day I see a tweet:

I follow the clickbait. Now I've never been to this URL before, so there will be nothing in the cache and my browser will call off to the server and once again download the app html.

In fact every time I visit some url in the SPA that I've not been to before, assuming I've not navigated from within the control of the SPA itself, the browser re-downloads the app html and caches it separately. Can't we save those extra bytes and milliseconds by not downloading it again?

Not the solution you're looking for

We could go back to doing our SPA URLs the oldschool way, so rather than having clean URLs to identify the state/position in the application, like

http://example.com/cats/tiddles

we could use URL fragments like

http://example.com/#!/cats/tiddles

This way there's only one URL as far as the server is concerned as the fragment is not sent to the server. As such we only download the app html on the first visit to our app, subsequent visits to any state in our app, for example to check out Rover, will be 304 not modified responses.

"But I can't give up my clean URLs" I hear you cry. So how can we get the same caching behaviour, but still keep our clean URLs?

Use a service worker

A service worker allows us to have full programmatic control over the network requests and responses as well as caching. So, using a service worker we can ensure that each of our requests to different urls serves the same app html from the cache, even if we've never been to that specific URL before.

So, in our app html we register the service worker.

navigator.serviceWorker.register('/sw.js');

Before you go any further make sure you use the correct caching headers for the service worker itself - it will always be requested, so we want a 304 not modified response whenever it hasn't changed.

Now, inside the service worker we need to take control of our cache. On install let's cache our app html.

self.addEventListener('install', event => {
    var installed = caches.open('cache-v1').then(cache => cache.addAll(['/']));
    event.waitUntil(installed);
});

Whenever a network request is made it is handled by the service worker, and so we can check to see if it is for a URL that requires the app html as a response. I've hidden the logic of this URL check away inside a function isPageRequest, as this logic is specific to your application's URL routing structure. If it is a request for the app html, let's mock up a request that will match the app html that is stored in the cache. Using this request we retrieve the response from the cache and send it back to the browser, no need to even go to the network.

self.addEventListener('fetch', event => {
    var request = event.request;
    if(isPageRequest(request)) {
        request = new Request('/');
    }

    var response = caches.match(request).then(resp => resp || fetch(request));
    event.respondWith(response);
});

Now, every page request, whether it's for /cats/tiddles, /dogs/rover, or whatever, they all get redirected to a request for /. As such they can all share the same cache response, even if you've never been to that specific URL before.

Adult, Single

Sat, 13 Feb 2016 00:00:00 GMT

Dinnertime

Sun, 25 Oct 2015 00:00:00 GMT

Famous Faces - Part III

Thu, 27 Aug 2015 00:00:00 GMT

This is the third part in my on-going attempts at capturing a likeness. Parts one and two were in pencil, this time I decided to digitally paint them. I thought I'd try make them a little harder, too. I think these people are either a little less distinctive or a little less well known. Also, no clues at all this time!

So, can you tell who the following three famous faces are?

Mosquito

Sun, 09 Aug 2015 00:00:00 GMT

Tweet Tweet

Wed, 29 Jul 2015 00:00:00 GMT

How to remember the flexbox alignment properties

Tue, 16 Jun 2015 00:00:00 GMT

If you've used flexbox, the powerful layout mechanism in CSS, you may have found yourself occasionally mixed up trying to remember the correct property names, I know I have. In particular, the properties pertaining to alignment and distribution – justify-content, align-items and align-content – always caused me some trouble. I'll explain why I found them confusing, and hopefully this will help you to remember them correctly too.

The garden path

Let's first look at a couple of dictionary definitions you are probably familiar with:

justify:: Adjust (a line of type or piece of text) so that the print fills a space evenly or forms a straight edge at the margin
align:: Place or arrange (things) in a straight line

It's natural to try and apply these definitions to understand the meaning of the flexbox properties. But this will lead you up the garden path – it looks good to start with but then suddenly stops making sense. Let's have a look at the three properties I mentioned above to see how this happens.

`justify-content`

Here's what the specification has to say about this property:

The justify-content property aligns flex items along the main axis of the current line of the flex container. … Typically it helps distribute extra free space leftover when either all the flex items on a line are inflexible, or are flexible but have reached their maximum size.

This seems to fit with the dictionary definition of justify, i.e. adjusting the distribution of items along the main axis. So, feeling comfortable in our interpretation we move on to the next property.

`align-items`

Again, from the specification for this property we have:

Flex items can be aligned in the cross axis of the current line of the flex container. … align-items sets the default alignment for all of the flex container’s items

This also fits with the dictionary definition of align, i.e. moving the items in the cross axis to achieve a desired line up along the main axis. It's all beginning to make sense, no? But you shouldn't get too comfortable with this. The first sign that something is amiss with our interpretation is that this property uses “items”, but the previous one used “content”, we'll get back to that in a minute.

`align-content`

We now meet our third property, about which the specification tells us:

The align-content property aligns a flex container’s lines within the flex container when there is extra space in the cross-axis, similar to how justify-content aligns individual items within the main-axis.

Oh! What? This fits a lot better with the dictionary definition of justify does it not? And indeed, this property can take all the same values (plus stretch) that justify-content could take. So, what's going on? Why is this property not called justify?

Justification

The flexbox alignment properties are part of a bigger picture, which has its own specification, the CSS box alignment specification. This specification takes the CSS alignment behaviour of flexbox and generalizes it to be utilised across various other layout models.

If you read through this specification you'll find the following comment.

Note: This specification uses the terms “justify” and “align” to distinguish between alignment in the inline and stacking dimensions, respectively. The choice is somewhat arbitrary, but having the two terms allows for a consistent naming scheme that works across all of CSS’s layout models.

So justify and align actually have nothing to do with their dictionary definitions, they are not distinguishing the type of alignment, they are merely for distinguishing directions of alignment. Bringing this back to flexbox layouts, “justify” means you're moving things in the main axis direction whereas “align” means you're moving things in the cross axis direction.

So what is it that distinguishes the different layout behaviours? Well, it's actually the “content” vs “items” difference we noticed earlier.

*-content properties are for arranging the content with respect to their container. You can think of content as all the items treated as a whole. Thus, aligning content consists of things such as choosing the space around and between items in order to achieve a specific alignment with respect to their container. That's pretty much what we originally thought justify meant.

*-items properties can be thought of as defining how items should line up with each other. That's what we originally thought align meant. The specification doesn't word it quite like this, but I think this interpretation works quite well. I should note that this property sets the default alignment for each item, you can actually specify a specific alignment on the item itself using the corresponding *-self property.

So it all makes sense in the end, I hope! To help you out here's an alignment properties cheat sheet:

Term	Meaning
justify-*	move along the main axis
align-*	move along the cross axis
*-content	adjust all items together to arrange with respect to their container
*-items	default alignment for items relative to each other
*-self	specific alignment for an item relative to others

Source maps for private code

Sun, 24 May 2015 00:00:00 GMT

If you're doing front end web development these days, chances are the source code you write is being transformed in your build process before it reaches the browser. It might be minification, transpilation or possibly compilation from a completely different language.

At some point, inevitably, you're going to want to debug the generated code that the browser is running, and it might be so terribly obfuscated from the code you wrote that it's impossible to work out exactly what is going on.

The solution is to use source maps. They essentially provide an inverse lookup from positions in your generated code back to your original source code. Source maps can be created during your build, and most build processes have some form of source map support these days.

In order to use a source map, your browser dev tools need first to be able to find it. If your generated code is JavaScript, one way to let the dev tools know where to look is to add a comment to the end of the generated code which defines the sourceMappingURL - the location of the source map.

//# sourceMappingURL=mylib.js.map

If this URL is not absolute, then it is assumed relative to the location of the generated code.

Now when you open your browser dev tools to debug the generated code, the tools can download the source map and use it to map back to your original source code.

There are a couple of ways the source map can link back to the original sources. One possibility is to have your source code available at some URL and have the source map point at that via it's sourcesRoot property. However the option I'd recommend is creating your source maps with the original source code embedded inside them using the sourcesContent property. For one it means you don't have to host your source code. But further, if you change your source code without rebuilding, your source map is still going to work as it contains a snapshot of the source code from the time of the build.

So you now have working source maps allowing you to debug your generated code. But, if you've distributed your source maps along with your generated code, so can everyone else! You may not want this, after all not all code is open source. So how do you debug your generated code without distributing the source maps?

One way to solve this is to host your source maps on a private website. This may be on localhost, or possibly shared on your private network. Let's say you set up a private site http://sourcemaps/, then the source mapping URL in your generated code can be set up to point at this site.

//# sourceMappingURL=http://sourcemaps/mylib.js.map

This way anyone who opens up the browser dev tools without having access to your (or their own equivalent) sourcemaps site will not be able to load the source maps (it'll 404 in the dev tools) and so your original source code is safe from prying eyes. You, however, will be able to debug your generated code with the aid of the correct source maps.

If writing a private URL into your generated code feels like a hack to you, then I agree. I would much rather the browser dev tools implemented a feature allowing you to choose root locations to use when resolving non-absolute source mapping URLs. A lot like how when debugging dlls in Visual Studio you can choose a symbols server to point at to look for the relevant pdb files. Imagine something like this: