Magic3W

This makes extracting a BIC (or SWIFT) number from an IBAN a breeze, and it can be done right in the browser. The package supports IBAN numbers from Germany, Austria, Luxembourg, Belgium and the Netherlands.

In case you wonder which ingresses and which routes your k8s cluster is providing, just run:

kubectl describe ingress

Webpack often has powerful, but also non-standard, loaders. So you can load CSS, SASS or HTML right into your applicationpackage. But when you load your package into another, these depending packages cannot work with your non-standard imports.

The alternative is to import an exported module. To do so, you can use webpack (any version after 5.28 should work) and add an export as es6 module.

Here's an example of how your webpack.config.json would look:

const path = require('path'); module.exports = [ { entry: {...}, target: "web", output: {...}, module: {...} }, { experiments: { outputModule: true, }, externals: { 'libraries-you-use' : 'commonjs2 library-name' }, entry: {...}, target: "es6", output: { filename: '[name].node.js', chunkFilename: '[name].node.bundle.js', path: path.resolve(__dirname, 'dist'), libraryTarget: 'module' }, module: {...} }, ]

I often extract some of the repeating settings as variables, so it gets easier to build a configuration that makes sense.

Sometimes we don’t realize that we introduced a bug during development, or that a change had a side effect that we didn’t expect.

Most of the time, git blame will tell us who is responsible for a certain line of code being added, or a certain change being made. But what if the issue was caused by a side effect? So the issue doesn't happen where the change was made.

Imagine having an issue because you have a script that in line 50 expects to manipulate a number variable by multiplying it by another number. 20 commits ago, you added a line 30 that overwrites the variable and sets it's value to a string.

Your code will fail in line 50, because you can't multiply a string by a number (at least not without causing weird stuff happening). But the issue we introduced was in line 30, so git blame won't be able to tell you what caused the issue.

This is where git bisect comes into play. This tool performs a binary search for the commit that broke your repository. This is how you best use it:

Write a script outside your repository that triggers the error. This can be a simple bash script, a program, or even a manual process if you can't or don't want to automate it.

Run git bisect and pass the hash of the good commit and the hash of a known bad commit.

Git will automatically checkout a commit.

Now execute your test.

Depending on the result execute git bisect good or git bisect bad.

If git has found the bad commit it will print it's hash and commit message. Otherwise it will jump to step three and repeat.

The binary search approach isn't specially novell or hard to do manually, but it's really good at helping you find a bad commit without the need of sifting through the git logs.

Did you know you can use scrollbar-width in CSS to just indicate how you would like the browser to render your scrollbar?

The property has three different values you can set: auto, thin and none.

The first, auto is the standard setting and allows your browser to select the width it prefers for the scrollbar. The other two are the most interesting ones, for obvious reasons. thin allows you to add scrollbars to smaller elements without taking up too much space.

Specially on windows systems, thick scrollbars are an issue when you have a small container the user can scroll in. They look unwieldy and out of place.

Another very interesting one is none. Up until now, if you wanted a box that would scroll on it's own, or use the mouse-wheel to do so, you would have to disable scrolling completely and reimplement it in Javascript.

Implementing scroll in JS would usually make it really inconsistent. Many browsers have smooth scrolling now, and mobile browsers have scroll-inertia, which allows you to flick the content.

Now you don't have to do so any more. Just set the scrollbar-width to none and scrolling will work. It just won't show the scrollbar.

I’ve seen many people use a jQuery or Javascript library that provides the ability for your application to smoothly scroll to a position on the window so the user has a sense of orientation.

Often in tutorial scripts or autoscroll, you want the user to understand that they are not on a new page. But that the viewport has been moved.

This benefits the usability (as long as you're not trying to scroll long distances) and it now can be implemented in vanilla Javascript.

Instead of using your window.scroll function like this:

window.scroll(0, 0);

You can pass an object like this:

window.scroll({ top: 0, left: 0, behavior: 'smooth' })

We have been maintaining an identity provider service for quite some time now. It’s been a massive undertaking, but I also learned an incredible lot from the experience.

With the next version of phpauth I want to start to properly implement authorization and authentication in a way that is interoperable with the rest of the world. This is where OIDC comes into play.

Up until now, we used a proprietary mechanism to generate tokens for the users, and signatures for the clients. Unlike oAuth2, we would have the client generate a signature with it’s app id and secret, and exchange that signature for a token.

The identity provider would then generate a token that the client can redirect the user to authenticate.

While our system was rudimentary in a lot of ways, and probably undercooked, it provided many of the creature comforts that we expect from OIDC and gave me a great foundation for understanding what makes the work behind OIDC, oAuth2 and JWT so amazing.

I found that many of the problems I was trying to solve were already solved elegantly (or not so elegantly at some points), and that adhering to a standard would not just make life easier for me - since somebody already wrote the manual to my software for free - it would also make the software more useful and interoperable with others.

SASS is a really powerful tool when you write styles for your web application. We use it to maintain a small SASS framework that our applications can extend. This way, we can share fixes to our components across our applications without the need to repair a broken margin or a bad overflow in every application's CSS.

This also makes it super convenient to maintain a consistent behavior in every app. Instead of having custom error messages in every one of them, you have a shared class that all can use, extend and rely upon. And if you update the underlying framework, the behavior stays consistent.

But there was one thing I found to be notoriously hard to do in SASS. And that's configuring the components.

If your application just wants to adjust the blue color palet to match a client's corporate image, you would have to either edit the library, or do some sort of black magic.

But lately I found out that this is a non-issue if you use !default. This keyword is appended to a variable definition and implies that the variable is only overridden if it wasn't set to begin with.

So, now my library code can be something like this:

$blue : #00F !default; $button-radius: .3rem !default;

Now, if a project needs a bit of configuration on top of our base styles, they can use something like this:

$blue: #F00; $button-radius: 0; @import "./library/main.scss";

or

@use "./library/main.scss" with ( $blue : #F00, //Actually red $button-radius: 0 )

To override our default settings.