The Difference Between a Professional and an Amateur Programmer

Mike Cohn:

The professional programmer brings his or her full brain, experience and creativity to the job. When asked to develop a feature, the professional thinks about it: Are there gaps in what was asked for? Are there alternative and better solutions? Will it lead to later problems? And then the professional has conversations with the product owner based on the answers to these questions to determine exactly what the feature will look like when implemented.

In contrast, the amateur says, “OK, I’ll give you exactly what you asked for.” That’s easier. The amateur programmer doesn’t have to think about the work beyond the specification. Just code what was asked for.


The Difference Between a Professional and an Amateur Programmer →

On a related note, this brilliant image:

Elsewhere , , Leave a comment

Beat Saber

Beat Saber is a VR rhythm game, where your goal is to slash the beats which perfectly fit into precisely handcrafted music.


Beat Saber →

Elsewhere , , Leave a comment

Get HTTPS working on localhost, with green padlock

In On “Secure Contexts” in Firefox, HTTPS for local development, and a potential nice gesture by Chrome I said:

One of the things that’s still not really frictionless for your local development domains is the use of certificates.

To circumvent the use of self-signed certificates I explained in said article how I have a dedicated domain with all subdomains pointing to That way I can use proper certificates for my local dev needs.

In How to get HTTPS working on your local development environment in 5 minutes another technique – one which works with all domains, even localhost itself – is unearthed: create a root certificate yourself, and trust it on your system. Any certificate linked to that root CA will then also be trusted, thus any host using it will have valid certificate no matter how it’s being accessed (curl, browser, etc.)

I like this “hack” because you only have to trust the generated root CA once (and not each certificate separately). I guess if you combine it with you can also get it to work on your smartphone talking to local dev stuff (or is there any way to have manual DNS entries on your iOS device?).

How to get HTTPS working on your local development environment →

Elsewhere , , Leave a comment

Continuous Improvement as seen through the lens of Systems Thinking

Recording of a 1994 talk by Dr. Russel Ackoff on Continuous Improvement as seen through the lens of Systems Thinking.

This talk really was way ahead of its time. It’s talking about Continuous Improvement long before I even heard this term in the business of web development; it’s expressed in a very clear and calm language; it has a typical TED-talk style written all over it; it’s packed with one-liners; …–
Yes, I am impressed.

The system is not the sum of the behavior of its parts, it’s the product of their interactions.

There’s also a lengthier talk by Dr. Ackoff on the subject of Systems Thinking available on YouTube.

(via @mvuijlst)

Elsewhere , , , Leave a comment

Working LEGO Combination Safe

I always wondered how these things worked. Nice!

(via @inferis)

Elsewhere , , Leave a comment

CSS Paint API (Houdini’s Paint Worklet) available in Chrome 65!

Oh yeah, the CSS Paint API will be enabled by default in Chrome 65:

CSS Paint API allows you to programmatically generate an image whenever a CSS property expects an image. Properties like background-image or border-image are usually used with url() to load an image file or with CSS built-in functions like linear-gradient(). Instead of using those, you can now use paint(myPainter) to reference a paint worklet.

Inside a paint worklet a CanvasRenderingContext2D has been made available for you to use. Use it like you would draw on a regular <canvas> element. Next to the CanvasRenderingContext2D you can also access the geometry of the element (e.g. get width and height), and can access other CSS properties (including CSS Variables).

There’s a nice demo included which showcases the rendering of a checkerboard pattern, which can be customised via two CSS Variables:

Here’s code for the painter demoed in the video above:

// checkerboard.js
class CheckerboardPainter {
  // inputProperties returns a list of CSS properties that this paint function gets access to
  static get inputProperties() { return ['--checkerboard-spacing', '--checkerboard-size']; }

  paint(ctx, geom, properties) {
    // Paint worklet uses CSS Typed OM to model the input values.
    // As of now, they are mostly wrappers around strings,
    // but will be augmented to hold more accessible data over time.
    const size = parseInt(properties.get('--checkerboard-size').toString());
    const spacing = parseInt(properties.get('--checkerboard-spacing').toString());
    const colors = ['red', 'green', 'blue'];
    for(let y = 0; y < geom.height/size; y++) {
      for(let x = 0; x < geom.width/size; x++) {
        ctx.fillStyle = colors[(x + y) % colors.length];
        ctx.rect(x*(size + spacing), y*(size + spacing), size, size);

registerPaint('checkerboard', CheckerboardPainter);

New possibilities in Chrome 65: CSS Paint API →

💁‍♂️ Want to know more about Houdini? Check out Sam Richard’s talk “Magic Tricks with CSS Houdini” (video)

Elsewhere , , , Leave a comment

Fixing iTunes Connect “ERROR ITMS-90717” with ImageMagick

When recently publishing an app to the App Store (or at least trying to get it published back then), I couldn’t upload the app via the Application Loader. I got back ERROR ITMS-90717

“Invalid App Store Icon. The App Store Icon in the asset catalog in ‘’ can’t be transparent nor contain an alpha channel.”

You can also get a likewise warning later on in iTunes Connect, when uploading the “App Previews and Screenshots”

To easily fix this, you can use ImageMagick’s convert command to remove the alpha:

convert input.png -alpha off output.png

To convert all .png files in a folder, combine the command above with find:

find . -name "*.png" -exec convert "{}" -alpha off "{}" \;

Now replace the assets in your Xcode project file, build your app again, and re-send it to Apple 🙂

Elsewhere , , , Leave a comment – Free Video Series to learning CSS Grid

Great new video series by Wes Bos, this time on learning CSS Grid.

CSS Grid may seem a bit daunting with new syntax and layout ideas, but it’s fairly simple and can be broken down into a handful of powerful concepts that when used together will blow your mind and change the way you create layouts for the web forever.

Ready?! Let’s Learn CSS Grid Together!

Thanks to a sponsorship by Mozilla Firefox the series – all 25 videos – is entirely free.

CSS Grid — Learn all about CSS Grid with Wes Bos in this free video series! →

Elsewhere , , , Leave a comment

On “Secure Contexts” in Firefox, HTTPS for local development, and a potential nice gesture by Chrome

👋 This post also got published on Medium. If you like it, please give it some love a clap over there.

Earlier today, in a post entitled Secure Contexts Everywhere, it was announced on the Mozilla Security Blog that Firefox from now on will only expose new features such as new CSS properties to secure contexts:

Effective immediately, all new features that are web-exposed are to be restricted to secure contexts. Web-exposed means that the feature is observable from a web page or server, whether through JavaScript, CSS, HTTP, media formats, etc. A feature can be anything from an extension of an existing IDL-defined object, a new CSS property, a new HTTP response header, to bigger features such as WebVR. In contrast, a new CSS color keyword would likely not be restricted to secure contexts.

Whilst I somewhat applaud this move, especially in the age of data theft and digital espionage, it’s – pardon my French – quite a ballsy thing to do. CSS Properties, really?

You might not be entirely aware of it, but features like Geolocation, the Payment Request API, Web Bluetooth, Service Workers, etc. are already locked down to secure contexts only.

But what is this secure context they speak of exactly? Is it HTTPS? Or is it more than that?

Let’s take a look at the MDN Web Docs on Secure Contexts:

A context will be considered secure when it’s delivered securely (or locally), and when it cannot be used to provide access to secure APIs to a context that is not secure. In practice, this means that for a page to have a secure context, it and all the pages along its parent and opener chain must have been delivered securely.

Roughly translated: http://localhost/ is considered to be a secure context, so that one will have the latest and greatest. However, the docs aren’t that clear on whether the definition of “local” involves actual DNS resolving or not:

Locally delivered files such as http://localhost and file:// paths are considered to have been delivered securely.

What about development domains – think project.local or project.test – pointing to Right now we’re left in the blue here …

Do note however that Mozilla “will provide developer tools to ease the transition to secure contexts and enable testing without an HTTPS server”, but the related bug is still unassigned.


It’s best to have your local web development stack mimic the production environment as closely as possible. Over the years we’ve seen the rise of tools like Vagrant and Docker to easily allow us to do so: you can run the same OS and version with the exact same Apache version with the exact same PHP version with the exact same MySQL version with … oh you get the point.

One of the things that’s still not really frictionless right now for your local development domains is the use of certificates.

Yes, you could use self-signed certificates for this, but that’s:

  • Not always possible: The Fetch API for example doesn’t allow the ignoring of self signed certificates.
  • Asking for potential security problems the moment you go into production: I once read a post about some production code that still had the --insecure flag enabled on the curl requests 🤦‍♂️. It was put there in the first place because of to the self-signed certificates used during development.

Another approach – and one that I am taking – is to use an actual domain for your dev needs. Each project I build is reachable via a subdomain on that dedicated domain, all pointing to thanks to a an entry in my hosts file. Since it’s an actual domain I am using, I can use an actual and correctly signed certificate along with that when it comes to HTTPS.

At the cost of only a domain name (you can get your certificates for free via Let’s Encrypt, which now support wildcards too) that’s quite a nice solution I think.


Back in December 2017 version 63 of Google Chrome was released. One of the changes included is that Chrome now requires https for .dev and .foo domains. This was ill-received by quite a lot of developers as most of them – including me before – use(d) the .dev TLD for local development purposes.

And yes, the pain is real … just do a quick search on Twitter on chrome https dev and you’ll see that lots of developer have wasted – and still are wasting – many hours on this breaking change.

Yes, there’s a (lengthy) workaround available to get the green lock in Chrome, but I wouldn’t recommend it really. It would require you to repeat a likewise procedure in all browsers you have running/are testing in, and this per .dev domain you have. Above that it won’t fix any out-of-browser contexts.

Could Google have prevented this .dev debacle? Of course. But I don’t see a reversal of this change coming any time soon though …

Can Google still do something about it? Well … I have an idea about this:

Just imagine if Google were to point all .dev domains to, that’d truly be paving the cowpaths! Add free SSL certificates for all .dev domains along with that and we’d jump quite far. With announcements like Secure Contexts Everywhere (referenced at the very top of this page) this idea seems like a real winner:

  1. (Chrome) Us developers can keep using the .dev TLD for projects in development.
  2. Us developers no longer need to use self-signed certificates anymore for projects in development. We could use certificates directly signed by Google’s CA (or by Let’s Encrypt in case Google doesn’t feel like providing certificates)
  3. (Firefox) Domains with the .dev TLD (and with an SSL Certificate) can be considered as a Secure Context, just like any other domain reachable via HTTPS.

One can dream, right?


Original Content , , , , 1 Comment

Can (a ==1 && a== 2 && a==3) ever evaluate to true?

Is it ever possible that (a ==1 && a== 2 && a==3) could evaluate to true, in JavaScript?

This is interview question asked by a major tech company. My answer was that it’s impossible. They said nothing is impossible. It happened 2 weeks back, but I’m still trying to find the answer. I know we never write such code in our day to day job, but I’m curious.

Betteridge’s Law of Headlines demands the answer to this question to be no, but given the fact that it’s question about JavaScript the answer – of course – is yes.

Here’s a hint: note the == that’s used, allowing for coercion to happen 😉

StackOverflow: Can (a ==1 && a== 2 && a==3) ever evaluate to true? →

Elsewhere , , 1 Comment