📸 Back in 2013 I’ve experimented with element() to recreate the <marquee> element. The alternate and slide variants still work fine, but looks like the left/right/down/up variants could need some polishing for them to work fine again.
I sometimes like to rewatch pieces from the Vox Earworm and Vox Borders video series. I especially liked this one on John Coltrane’s “Giant Steps” from the Vox Earworm series, for which they won the Emmy for “Outstanding New Approaches: Arts, Lifestyle and Culture”:
John Coltrane, one of jazz history’s most revered saxophonists, released “Giant Steps” in 1959. It’s known across the jazz world as one of the most challenging compositions to improvise over for two reasons – it’s fast and it’s in three keys. Braxton Cook and Adam Neely give me a crash course in music theory to help me understand this notoriously difficult song, and I’m bringing you along for the ride. Even if you don’t understand a lick of music theory, you’ll likely walk away with an appreciation for this musical puzzle.
When building an image, Docker steps through the instructions in your Dockerfile, executing each in the order specified. As each instruction is examined, Docker looks for an existing image in its cache that it can reuse, rather than creating a new (duplicate) image.
Therefore it is important that you carefully cater the order of your different Docker steps.
When using Google Cloud Build however, there – by default – is no cache to fall back to. As you’re paying for every second spent building it’d be handy to have some caching in place. Currently there are two options to do so:
Using the --cache-from argument in your build config
Using the Kaniko cache
⚠️ Note that the same rules as with the local cache layers apply for both scenarios: if you constantly change a layer in the earlier stages of your Docker build, it won’t be of much benefit.
The easiest way to increase the speed of your Docker image build is by specifying a cached image that can be used for subsequent builds. You can specify the cached image by adding the --cache-from argument in your build config file, which will instruct Docker to build using that image as a cache source.
To make this work you’ll first need to pull the previously built image from the registry, and then refer to it using the --cache-from argument:
Kaniko cache is a Cloud Build feature that caches container build artifacts by storing and indexing intermediate layers within a container image registry, such as Google’s own Container Registry, where it is available for use by subsequent builds.
To enable it, replace the cloud-builders/docker worker in your cloudbuild.yaml with the kaniko-project/executor.
When using Kaniko, images are automatically pushed to Container Registry as soon as they are built. You don’t need to specify your images in the images attribute, as you would when using cloud-builders/docker.
Here’s a comparison of a first and second run:
From +8 minutes down to 55 seconds by one simple change to our cloudbuild.yaml 🙂
Did this help you out? Like what you see? Thank me with a coffee.
I don't do this for profit but a small one-time donation would always put a smile on my face. Thanks!
We return to take a closer look at Progressive Web Apps (PWAs) and how they combine the reach of the web with the device integrations of installed software. In this ebook, Volume 2 in the series, you will learn:
The capabilities of Progressive Web Apps
Product strategies for deploying PWAs
Promotional patterns for driving installs of PWAs
UX best practices for designing installed experiences that work reliably offline
How to implement analytics to measure business impact.
When you run act it reads in your GitHub Actions from .github/workflows/ and determines the set of actions that need to be run. It uses the Docker API to either pull or build the necessary images, as defined in your workflow files and finally determines the execution path based on the dependencies that were defined. Once it has the execution path, it then uses the Docker API to run containers for each action based on the images prepared earlier. The environment variables and filesystem are all configured to match what GitHub provides.
Installation per brew (if you’re on Mac):
brew install nektos/tap/act
Once installed, run act and you’re good to go …
# List the actions
# Run the default (`push`) event:
# Run a specific event:
# Run a specific job:
act -j test
# Run in dry-run mode:
# Enable verbose-logging (can be used with any of the above commands)
Reminds me of Eric Meyer’s Flexible Captioned Slanted Images in which he combines Flexbox and CSS clip-path. In that implementation Eric did have to correct the margins to fix the gap between the items. With the grid implementation this looks like to be no problem.