Category Archives: Development

Origami: JS Logo

A few years ago I wanted to try to design an origami version of the JS logo. This is the widely-used community logo for the JavaScript programming language. (There’s no “official” logo for the language, but that’s a whole other story that’s not relevant for this post.)

Original community JS logo

I did this not because it was particularly wanted by anyone, but simply as an interesting challenge—possibly one not attempted before. As documented elsewhere, I wasn’t experienced at designing origami models at that point. I broke it down into chunks, trying separate “J” and “S” designs. To keep things simple, I started with pixel-like shapes for the letters (90° angles only), then chucked in some 45° angles if I could get away with it.

After a fair bit of trying different techniques and refining folds, I ended up with the most efficient models I could think of. (“Efficient” in this case means using the smallest possible starting size of paper. Every bit of paper tucked away out of sight is effectively wasted; efficiency is minimising how much paper is wasted.)

But trying to combine the models together into a single “JS” design was beyond me. The differences in fold placements combined with the off-centre placement of the letters was too much. I knew I had to be missing some fundamental design technique that would unlock what I wanted to do. In the end I put it aside for a while… which became several years.

Continue reading

Mashed browsers and the IE-lephant — A Web Directions adventure

A few weeks ago I gave a talk at Web Directions Summit 2019 in Sydney. The talk was about the ECMA-402 Internationalisation APIs built in to browsers, because I don’t think enough people know about them. A fully written version of the talk is available on this site in the unsurprisingly-named Talks section: Intl we meet again.

There was a helluva lot of stress and preparation involved in trying to make a rather dry topic sound interesting for 20 minutes. In the end, the results were worth it, but I was reminded why it had been several years since I’d previously given a conference talk. It will likely be several years before I do another one entirely from scratch.

I got some good feedback about the talk, but there were two parts I was particularly pleased with. Even if the presentation had tanked, I’d still have been satisfied with the completion of two slides. Mainly because they gave me the excuse to muck around in design tools and pretend I’m a real designer.

These items were the mashed-up browser logos, and the “IE-lephant in the room”. I had enough people talk to me about the images after the talk that I’ve decided to pop them online for all to see. Both images are linked from this post in SVG form, under a Creative Commons Attribution 4.0 International license. That means you’re free to copy them, modify them, do whatever… but with an attribution credit too.

Some-in-one browser logo

Mashed up and combined logos of Chrome, Edge, Firefox, and Safari.

The idea of smooshing many web browser vendor logos into a single image was one I had years ago. This talk was finally the excuse I’d been looking for to actually do something about it. I’m perhaps far more pleased with the result than I should be.

I’ll refrain from calling it an all-in-one logo, as there are many more browsers available than just Chrome, Edge, Firefox and Safari. Important note: This isn’t intended to favour any one browser over the others. My intent was for this image to equally (but light-heartedly) offend the designers of each of the featured logos. 😉

It would also be hypocritical of me to request attribution without also giving some in return. So for completeness, here are the links to the original vector images that went into this (before a lot of cleaning, nudging, and mangling of the files in Illustrator):

Of course, as soon as I’d finished the mashup image and put it my presentation, 2 of the 4 logos became outdated. Firefox has just got an updated and simplified logo, while Edge’s logo has had a complete revamp for its move to a Chromium base. Oh well, I guess I’ll have to make a Version 2 at some point.

IE-lephant

Internet Explorer logo merged onto the body of an elephant.

In contrast to the well-planned logo mashup, this image was pretty much a spur-of-the-moment joke. Its only purpose was to be a punchline — “I’ve only talked about support for modern browsers; but what about the elephant in the room?”

I’m not really sure it has any reusable purpose beyond that joke, but I’m still rather pleased with the result, so I’m sharing it anyway.

The two source images that went into this are:

Enjoy!

Reduce your spread

A quick prelude: I wrote the first draft of this post a couple of months ago, but it still needed editing and polishing. Then Rich Snapp published The reduce ({…spread}) anti-pattern and made all the main points I was going to make.

Feeling rather deflated, I initially abandoned the draft. However, to force myself to complete things, I’m publishing it anyway. Although our primary argument is the same, we approach the topic from slightly different angles. I recommend reading Rich’s post too as it’s well-written, and he explains some things better than I do. But mine has a bonus grumpy rant at the end. Contrast and compare.


Object spread — a primer

The object spread syntax has become one of the more readily-adopted[citation needed] pieces of the ever-evolving ECMAScript specification. Over the past few years I’ve worked on several application codebases that have made use of it, and seen many more open source libraries using it.

First I should define what I mean by the object spread syntax. It’s best to explicitly set the terms of reference here, because different people might have different interpretations of it. Other people might have used the syntax but not known what it was called.

Object spread, at its simplest, is used for copying the keys and values of one object into a new object. It’s important to note that it does a shallow copy rather than a deep copy, but in many cases that’s all that’s required anyway. (For more details on shallow vs deep copies, see this Stack Overflow post.)

let sourceObject = { element: 'input', type: 'radio' };

let sourceCloned = { ...sourceObject };
// A new copy of the original: { element: 'input', type: 'radio' }

let extendedObject = { ...sourceObject, name: 'newthing', type: 'checkbox' };
// A modified copy: { element: 'input', name: 'newthing', type: 'checkbox' }

The problem

Object spread syntax is not a problem in and of itself. Quickly and easily copying an object’s data to another object is a very common use case. Indeed, the plethora of solutions that were created in the years beforehand show how much it was needed. Long gone are the days where some projects would include the entirety of jQuery just so they could use $.extend().

The problem arises when it becomes the only way to assign properties to an object in a codebase. Over the past few years I’ve noticed a trend of using object spread wherever possible, even if it isn’t the best tool for the job.

In the worst cases, it has caused exponential performance bottlenecks. Helping someone fix a slow-running script is what prompted me to write this post. Object spread syntax should be used with caution.
Continue reading

SydCSS Wheel of Talks

Last December the SydCSS meetup had its first game show-themed “Wheel of Talks” evening. Three presenters each had to deliver a talk of 5-10 minutes on a topic related to CSS. The catch was that they didn’t know what their topics were until the start of the evening, at which point they had 20-ish minutes to prepare. The talks were randomly selected from the eponymous on-screen Wheel of Talks, built in CSS and JS.

This is the story of how the event was planned, and how I built the wheel.

I can’t hide from my mind

The best ideas arrive when you’re meant to be thinking about something else. The late, great Terry Pratchett imagined them as “inspiration particles” that, like muons and neutrinos, sleet through space until they strike the brain of an unsuspecting creature. I just call them brain farts.

This particular idea struck one morning as I was getting ready for work. I imagined a 3D, poker machine-esque, CSS-powered spinning wheel. Specifically, I imagined two of them — one to randomly choose a presenter, one to randomly choose their topic. I knew SydCSS was looking for new ideas to mix up their evenings, and this would be the perfect fit. I called it “presentation roulette”.

I whipped up a basic prototype on the train ride in to work that morning to make sure the concept worked. I showed it to David (one of the SydCSS organisers) and explained the idea. The next day I got a message from Fiona (the other organiser) saying that she loved the plan. A day later she said that someone else was already on board to do one of the impromptu talks, and that I should do one too.

And thus, a monster was born.

Continue reading

My future in tech

The future’s not set. There is no fate but what we make for ourselves.

— Yes, I just opened a blog post with a quote from Terminator 2. I can’t quite believe it either.

I’ve been doing a lot of reflecting over the last few years about what I want to do for a living. Perhaps a bit too much. I’ve had all of these thoughts rattling around my head over the years, and I’ve babbled parts of them at various friends. Someone suggested that if I finally wrote everything down, it might help clarify what I want.

Frankly, I’m still none the wiser, but at least I now have something to link to if when I start to rant about it to someone else.

Written pieces such as this post are generally read in a linear fashion, with a narrative structure. But I can’t get this story to work like that — all the pieces are intertwined in a sort of feedback loop. Instead I’ll present separate threads of the tale, then try to weave them together.

Continue reading

New project: A Visual Studio Code extension for time zone data files

(A boring title, I know, but it’s stuffed full of juicy SEO keywords. Mmmmm.)

As mentioned in my previous project-related post

From now on, I’m going to attempt to write a proper explanation here for each side project I complete. Even if no-one else reads it, at least I’ve created some historical documentation for my future self.

As many people know by now, I’m a time zone nerd. I’ve given talks at conferences and meetups about problems and solutions when dealing with time zones. I sit on the time zone database mailing list and read about last-minute changes to a country’s time zone with a mixture of fascination, horror, and (mostly) amusement.

The IANA time zone database (also known as the “Olson database”) source files are incredibly rich with information. About two thirds of the lines in each file are comments about the data and its history. The project is part database, part history lesson, part social commentary.

A couple of years ago I wrote a Sublime Text package that added syntax highlighting specifically for the formatting of the time zone database files (available via Package Control). While it’s great to read the comments surrounding the data, sometimes you want the comments to be styled like comments and fade away a little, to let the lines of data stand out.
It seems to have been well-received, and Matt Johnson of Microsoft (a frequent contributor to the mailing list) suggested an improvement to the text formatting.

A few months ago, Matt contacted me asking if I was interested in porting the package over to an extension for Visual Studio Code (hereafter referred to as “VS Code”, because I’m lazy and it’s easier to type). I regularly use VS Code for coding, so I figured it was a good way for me to explore the extension ecosystem. I’ll describe how I converted it, and some of the mistakes and improvements I made along the way, in case it’s helpful for someone else.

If you want to cut to the chase and use the finished extension, it’s available as zoneinfo in the VS Code marketplace.

Continue reading

New projects: Emoji Censor and Numberwang

I’ve generally been rather lax when it comes to writing about side projects I’ve done. I’ll finish the project, mention it on Twitter a couple of times, then… well, that’s about it. Not a particularly effective way to do promotion of ideas.

Time to do something it. From now on, I’m going to attempt to write a proper explanation here for each side project I complete. Even if no-one else reads it, at least I’ve created some historical documentation for my future self.

Take me down to Distraction City, where the… oooh shiny!

I have a history of talking with people at tech user groups and meetups and coming up with ridiculous ideas for side projects. Mostly the ideas go no further than that because, well, they’re ridiculous (and taking a joke too far often ruins the humour). Sometimes, though, the idea is just too tempting to leave alone.

The first of these ideas came from a SydCSS meetup:

For the rest of the evening, a friend and I would whisper “that’s Numberwang!” whenever a bunch of numbers appeared on a presentation slide. Yes, we’re far too easily amused.

Wait, what the hell is Numberwang?

Numberwang started as a series of sketches on the TV show That Mitchell and Webb Look. The basic premise is a number-focused game show that makes no sense to viewers, but everyone on the show knows exactly what’s happening. I highly recommend watching the full collection of sketches.

The next morning on the train I whipped up a super-quick prototype of a browser extension that would randomly exclaim “That’s Numberwang!” when you typed a number on a web page. I let it linger for a few months, then another conversation spurred me to write it properly. Here’s a video of it in action:

Continue reading

Redirecting GitHub Pages after renaming a repository

One of the golden rules I try to follow in web development is “don’t break URLs”. That is, even if pages get moved around, or a site is completely revamped, the old URLs should still redirect somewhere. It’s a terrible experience to bookmark a page or follow a link from another site, only to find that the page has completely vanished. Let’s try not to make the problem of link rot even worse.

The best way to redirect old pages is to get the web server to send a 301 Moved Permanently HTTP header. This has the benefit that search engines will see the 301 header and automatically update their caches to reference the new URL. Where this can fall down is when using static site hosting such as GitHub Pages or Surge.sh. By design, you’re not allowed to send any web server directives such as custom HTTP headers, so the 301 redirect option is out.

So what do you do when you want to move some URLs around when using GitHub Pages? Here are the options I found.

Continue reading

Software development amnesia

There needs to be a name for the software development version of the Gell-Mann Amnesia effect. The full version is worth reading, but I’ll just repeat the critical parts here (emphasis mine):

You open the newspaper to an article on some subject you know well. […] You read the article and see the journalist has absolutely no understanding of either the facts or the issues. Often, the article is so wrong it actually presents the story backward–reversing cause and effect. […] In any case, you read with exasperation or amusement the multiple errors in a story–and then turn the page to national or international affairs, and read with renewed interest as if the rest of the newspaper was somehow more accurate about far-off Palestine than it was about the story you just read. You turn the page, and forget what you know.

I’d like to propose a corollary to the Gell-Mann Amnesia effect, targeted specifically at software developers:

As an experienced software developer, you know how much work goes into delivering a new feature for a reasonably-sized product. The myriad priorities that are juggled to determine the ever-shifting sands of the roadmap. You’ve been frustrated at the angry customers demanding that their personal top priority be attended to first, under the highly-mistaken assumption that their use case is everyone’s use case.

You know the weeks or months of discussion and planning that happens before any code is written. The sheer number of people who will be involved in trying to get it right. The UX research, the design iterations, the architectural concerns. You know the amount of testing that needs to happen for edge cases on different platforms, or with different configuration setups. You know the rigour with which someone in the QA team will pick up on potential problems. Depending on the size of the company, there might even be an internal roll-out first, to pick up any stray bugs. Then, and only then, can it finally go through to a public release.

You breathe a sigh of relief that the feature you’ve worked so hard for is out the door. Switching to some other piece of software you use frequently, you see an update notification. The release notes mention some small, trivial new feature that has no value for you. You exclaim, “Ugh, how can they possibly be focusing on such unimportant details when they still haven’t fixed the thing that annoys me the most?” — as if somehow this other company’s planning and implementation process is any different from yours.

You switch away from your product, and forget what you know.

Should I continue canianimate.com?

Or, shouldicontinuecanianimate.

This is an open question to the front-end development community. I have a website and want to make it better. But I need to know if it’s actually valuable before putting in more work.

Back to…

A couple of years ago, as part of a building some animation prototypes, I ended up creating a small library that collates which CSS properties can be animated, and how they animate. At the suggestion of Sean Curtis, I turned that data into a site called canianimate.com. It’s inspired by caniuse.com but only for CSS animations and transitions.

I launched a basic version of the site and had grander plans for it. Ultimately I wanted to add a bunch of interactive graphs that showed better details of how different types of properties were interpolated and transitioned.

But a little while after that, I attended a conference where the theme of several talks was performant animations. All the advice was to animate only the opacity and transform properties, which matched the trend of advice coming from the wider dev community — especially those working for browser vendors.

While it was definitely good advice (and still is today), it effectively took the wind out of my sails. What was the point of putting more effort into explaining the minutiae of all the different properties’ animation rules, when the general advice is to only use two of them?

…the Future

Continue reading