December was intense: working devops and learning Helm for kubernetes, then digging into CSS ligatures related to a bug fix. Not to mention that I started this blog, and needed t refresh my basic trigonometry knowledge!
Helm for kubernetesThe Helm logo, the steering wheel of a ship
We use kubernetes clusters to deploy and run services, but until now it was unknown for me, how exactly these services are set up. Imagine the kubernetes building blocks:
- Docker images (in which you put your actual code and app)
- a Kubernetes cluster, which has pods of containers of images, which create services together, this is where your app run
- kubectl, the CLI command tool that can manage a kubernetes cluster, at an atomic level
- and now Helm, which was the missing ingredient - at least for me
Helm aims to be the package manager for kubernetes clusters. These packages are called Charts, where you can define which docker images have to be used in your services later, exact version of images and configuration data.
The configuration also contains the keys for secrets where the data itself will be provided by the k8s cluster’s secret store. (Be sure to avoid storing these in code, as I’ve mentioned this a few times in my introductionary DevOps talk)
I’m pretty sure all these could be configured using
kubectl, but that would be lots of commands, probably redundant,
error-prone and time-consuming.
But with Helm Charts, you can define your service in a kube cluster pretty easy - after you get to know what goes where. We should not forget, these charts are versioned, so you can roll back if something went wrong.
Structure of Helm Charts
A Chart is a collection of files in a directory, the name of this directory is the name of the Chart. Here is a brief description of these
- Chart.yaml holds information about the current Chart, version, description etc
- requirements.yaml the dependencies of the Chart, it can depend on other Charts
- Templates/ in these templates, you can define your architecture: services, deployments, replica sets, ingresses, any kubernetes building block you need
- values.yaml the data in here will populate fields in the Templates. You can create several of these files, and pick the right one you need, or override any values in these from the CLI commands
So far I've met with simple charts, with a few Templates and Values. Having several value files - staging and production for example - was enough for our needs, and we could version and deploy our services using those. Here is the complete documentation on Chart contents.
Before using the helm CLI you have to connect to a kubernetes cluster. Helm will use the cluster information from your
~/.kube/config file. The basic commands are:
helm listlist all the releases
helm installinstall a Chart to the cluster
helm upgradeupgrade a release to a new Chart version
helm deletedelete a release
These are really the most essential commands, there are many other commands, you can check the out at the Helm Docs
While working on a feature, that relies heavily on the contenteditable property of the DOM, this happened:
Since I know the work of @aemkei, and the dark magic of zero-width Unicode characters, I prepared for the worst. Tried to hunt down any, accidentally created ghost character, but there were none. It was really two characters, handled as somewhat one, but the caret did not move while stepping over them. After a short googling the word “Ligature” burned in my brain!
In writing and typography, a ligature occurs where two or more graphemes or letters are joined as a single glyph
In our case - which is actually a very common one - the letters f and i melted together. The weird thing here is that the browser treats these as two separate characters, it does not move the caret visually, which is really confusing UX-wise - imagine use cases like precise-selecting text.
But it can be turned off, using the powers of CSS!
examples for font-variant-ligatures, font-variant-numeric and font-variant-alternates
The best place to learn about these is the W3 spec itself and it turned out, it's a long slippery way down the rabbit hole.
There's a lot of these settings and features, some really interesting:
- font-variant-ligatures there can be several ways of ligature occurence: the font designer can decide or there are historical typeface rules, or contextual, like joining letters in a script or handwriting font
- font-variant-numeric how numeric characters relate to each others, like aligning kerning so they form columns of prices, or displaying fractions
- font-variant-alternates the area where font designers can really play around, new design for the capital letter Q, or playing with terminating letters, or just highlighting characters
Important: these are based on OpenType features, so they only work with OpenType feature enabled web fonts. Try these features on Google Fonts: Google Font OpenType Feature Preview
What's more fun, is that ligatures power many of the emojis, combining them in a various way, for example, flags:
Flag emoji like 🇯🇵 are ligatures of special country code glyphs called “Regional Indicators”. There are 26 of them, one for each letter of the Latin alphabet, and two combine to make a flag. For instance, there is no Unicode number for the Japanese flag emoji 🇯🇵, it is made up of two indicators: REGIONAL INDICATOR SYMBOL LETTER J + REGIONAL INDICATOR SYMBOL LETTER P.
These are combined together using a Unicode "zero-width joiner" (
U+200D in HTML it's
‍). If there is a connected form for
two characters, putting this one in between them, causes them to appear as their connected variant. Lots of new emoji are created,
using such ZWJ's, here is the complete list of them on Unicode.org
Trigonometry & CSS variables
For this site, I wanted to play with a skewed header and footer background, but leaving these slanted layers there just being static elements looked boring. So why not add some animation?
To animate these leaning layers, I have to update the css
skew property, by a relatively small degree. If I look at this shape of
a skewed background rectangle, the upper / or lower part is a simple right-angled triangle.
The value I need, is the angle between it's adjacent and hypotenuse, that has the degree value to skew the background with.
Luckily, the right-angled triangle has some basic rules in trigonometry.
The Opposite and the Adjacent divided gives me the tangent of the skew angle. All I need is two values:
- the Adjacent is the width of the header, which is always the viewport width
- the Opposite will be the skewed height of the header
Refresh your knowledge on trigonometry, it can be really useful in usecases like mine!
requestAnimationFrame on scrolling I can calculate the height of the Opposite value until a maximum pixels, and during this calculation
I can set the skew angle, so as the visitor scrolls down, it starts to skew the header or the footer.
Setting a CSS property from JS can be painful for rendering performance. Instead, use CSS variables - or CSS Custom Properties - where the value of a CSS property is bound to a CSS variable, just update the value of the variable from JS, and let the browser sort out the rest.
Combining this technique with FLIP, enables you to create not just fancy decorative animations, but meaningful and contextual transitions for any UI.