22 Aug 2018 • 16 minute read Most of the English-speaking world has Amazon and eBay. In New Zealand we have TradeMe - an online auction & classified advert website where Kiwis go to buy & sell general items, cars, and property. If the numbers are to be believed, then pretty much every Kiwi has a TradeMe account. I don’t think it’s an understatement to say that TradeMe is an itegral part of modern New Zealand culture.
Back in 2016, TradeMe announced that it was working on a new “smartphone-optimised” responsive website that will eventually also replace the desktop website. Then halfway through 2018, they announced that the new responsive website was being rolled out to real users.
Being the ever-curious developer, I wanted to give the new TradeMe website a try. After a couple of weeks using the new website on my phone (a Nokia 7 Plus), I became frustrated with how much time I spent staring at a loading spinner, and how sluggish the UI interactions were. So I went back to the old website.
This bothered me, because I know that the other TradeMe experiences are fast. Why should this new website be so slow? I wanted to dig deeper, so I’ve taken the opportunity to conduct a detailed performance review.
(Read more) 14 Jun 2018 • 26 minute read This post is a transposition of my Fluent talk Becoming a team lead: a survival guide. It’s been edited to better fit a blog post format. If you prefer to see the original format, you can watch the video (30 minutes + Q&A) or view the slides with speaker notes.
A survival guide is a strange thing to call this post, since survival guides are usually very serious books that prepare you for extreme situations. Building shelter in the wilderness, foraging for food, avoiding being eaten by bears - that sort of thing. I’m never sure when is the right time to read a survival guide, since being lost in the wilderness or being hunted by bears is not something you really plan for. If you read the survival guide too early, you forget most of it. If you read it too late, it’s no use.
Anyway, the reason this is a survival guide is because after spending my entire career as a software engineer, I was thrown into a team lead role without much warning. I had no idea what I was doing and had very little support. This is the survival guide I wish I had. It documents my experiences as an inexperienced team lead –as an engineer transitioning to a team lead– and my learnings & mistakes along the way. Hopefully this can act as a survival guide for you, too.
This is a fairly long guide, so I’ve split it into sections. Feel free to skip sections that aren’t relevant to you.
(Read more) 5 Aug 2017 • 6 minute read TL;DR
- Second is a framework for building React applications where the data is fetched on the server and most of the components do not change after the first render.
- Components can declare their data dependencies using a container similar to Facebook’s Relay.
- By default components are only rendered on the server; client-side rendering is opt-in by using the component dehydrator.
- Second works with any React-like library including Preact.
Why build this framework?
While using React to build the BBC News front page and several other mostly-static pages, a common theme emerged: only a small number of components on these pages require client-side JavaScript to function. Rendering every component in the browser does not provide an optimal experience — especially for users on low-powered devices or low-speed connections. Instead, selectively bundling components for the browser reduces bundle sizes and minimizes CPU overhead without sacrificing React’s event system and stateful components.
Second is not a large or complex framework. It is the result of combining several simple and well-tested techniques—
- Server-side rendering
- Container components for declarative data requirements
- Selective client-side rendering
—and combining them into a single package that can be easily reused across multiple applications.
(Read more) 4 Apr 2017 • 7 minute read Web performance is something I care deeply about both as a developer whose work affects millions of people around the world, and as a user who often accesses the web on slow & unreliable connections. I have regularly and loudly complained that the BBC News website is unnecessarily slow, so when I was given the opportunity to help rebuild one of the most visited pages of BBC News—the front page—I jumped at the chance.
That was April 2016. Now, a whole year later, we’re ready to begin a phased rollout of the new front page. Starting with a small percentage of users in the UK, we will gradually move everybody to the new front page over the course of several weeks. (Update: as of June 2017, the new front page is rolled out to all users).
Quick facts about the new front page
- It is lighter and faster than the old one:
- First meaningful paint happens up to 50% sooner on mobile devices.
- Page enhancements like lazy-loaded images load 150% faster on mobile, and 70% faster on desktop.
- The total bytes downloaded is 50% less on mobile and 75% less on desktop.
- CPU busy time has been reduced by 30% on mobile and by 50% on desktop.
- Performance monitoring has been automated with SpeedCurve from the beginning of the project.
(Read more) 16 Feb 2017 • 2 minute read I started 2016 feeling quite overwhelmed by the sheer number of new technologies that were being introduced. This year I feel like many of those technologies have matured, so I have collated a list of the ones that I think deserve your attention. My focus for the last couple of years has been on performance, so I’ve made an effort to ensure that all of the technologies mentioned are either “performance-friendly” or are directly related to performance.
(Read more) 13 Feb 2017 • 5 minute read This post is about the Web Application Framework in use by some teams at the BBC. It is not strictly a framework in that it specifies the contracts between components, rather than providing concrete implementations of the components. For this reason, I prefer to think of it as the Web Application Specification.
At the beginning of 2015, a group of developers and technical architects from around the BBC got together with the goal of designing a system for sharing web page components between teams. This came from an acceptance that most of the BBC’s public-facing web products have a similar look & feel, and a desire to improve efficiency through sharing rather than building similar things over and over again.
(Read more) 26 Dec 2016 • 8 minute read The BBC is a pretty large organisation. Today it employs around 20,000 people (actually around 35,000 when you include part-time and fixed-term contract employees) across a huge number of divisions. The BBC Careers website typically has over 100 vacancies posted on any given day. Before I joined the BBC, I found the sheer scale of it a bit intimidating. Usually I can get an idea of what it’s like to work for a company by reading their job advertisements and their engineering blogs, but with the BBC I was almost completely clueless. In this post I hope to shed some light on what it’s like to work as a developer or tester for BBC News.
Just a small disclaimer first: from an engineering perspective, the BBC is not like most other companies — it’s more like dozens of smaller companies, each with their own engineering department, working towards a common goal. News, Sport, Programmes, iPlayer, Radio… As digital products, these are all built mostly independently of each other. I work for BBC News, so a lot of what I’ve written may not apply outside of BBC News.
(Read more) 22 Jul 2016 • 16 minute read TL;DR: Over the last 4 years, the BBC News core experience has been transformed from a speedy 21KB page into a slow & bloated 685KB monster. This was in part due to a lack of performance monitoring and 4 years of feature creep, but also due to a lack of performance-oriented culture throughout the business.
I created a lightweight prototype of the BBC News core experience which demonstrates that focusing on the content first and foremost can result in an extremely fast page. I want the BBC and other websites to rethink what the core experience means, and experiment with giving users the power to define their own experience.
In the beginning of 2012 the BBC Responsive News team wrote about how they provide a “core experience” for users by default, and then progressively enhance the page if the browser cuts the mustard. At the time, this was cutting edge. They were able to build pages that worked on practically any browser without compromising the experience for users on modern browsers. To quote directly from the Responsive News blog:
(Read more) 20 May 2016 • 5 minute read Back in December 2015 I spoke at LDNWebPerf alongside Peter Chamberlin about how web performance is not a technical problem (slides with speaker notes). One of the things I talked about was how we used multivariate testing (MVT) at BBC News to prioritise performance optimisations. The gist of it was that our stakeholders had already bought into the idea that performance has a strong correlation to business metrics, and they wanted to dedicate some development time to improving performance. The catch was that they didn’t want to spent too much time on it.
Our predicament, then, was that we needed to know which optimisations had the biggest impact on performance without actually spending the time to make the optimisations. For example, we had a hunch that inlining the critical rendering path CSS would improve our start render time, but with over 1MB of CSS and a complicated application architecture, implementing this was much easier said than done.
This is where the idea to A/B test performance came from: we could easily make the performance optimisations by hand on a single page, and then benchmark each of the optimisations to find out which had the biggest impact.
(Read more) 28 Mar 2016 • 1 minute read The recent kerfuffle around the NPM #unpublishgate and the Greenkeeper bot impersonation has got me thinking about the open source community and its culture.
Sometimes the open source community feels like a wonderful, cooperative, welcoming place. There have been times when maintaining an open source project has given me an enormous sense of satisfaction and well-being. On the best days, complete strangers offer valuable feedback and even actively contribute to my projects.
(Read more) 23 Aug 2015 • 2 minute read Over the last 5 years I’ve managed to collect quite a few mechanical keyboards, to the point where I think I qualify as an (accidental) enthusiast.
Das Keyboard (3) Model S Ultimate
This was my first mechanical keyboard. The soft Cherry MX Brown switches make it my favourites for long periods of typing. Even so, I rarely use it any more. At the time of writing, this model is still available on the Das Keyboard website.
CODE Keyboard
I was really excited when Jeff Atwood announced the CODE keyboard. I already knew that I wanted my next keyboard to be compact and have backlit keys, so the CODE seemed to come at just the right time. Not long after buying the CODE, I purchased some Keycool rainbow keycaps so brighten things up.
The CODE has Cherry MX Clear switches, which makes for a much firmer keyboard than the Das. I find the clears preferable for short bursts of typing, but over long periods they tire my hands out.
(Read more) 27 Jul 2015 • 3 minute read This post contains a collection of resources for learning about functional programming. These resources cover a range of levels from beginner-friendly introductions right through to more advanced concepts. (Read more)
8 Jul 2015 • 3 minute read
Some notes on terminology
In case you’re not familiar with some of the terminology used below, here is a small glossary.
Object
An object in Git is either a blob (file), tree (directory), commit, or tag. All objects in Git have a hash (like 99b69df491c0bcf5262a967313fad8be0098352e) and are connected in a way that allows them to be modelled as a directed acyclic graph.
Reference
A reference in Git is a bit like a pointer, or a symlink. References are not objects themselves, and they always point to either an object or another reference. Branches, tags, and HEAD are examples of references.
You can learn about all of this and much more in my Hacker’s Guide to Git.
(Read more) 26 Apr 2015 • 1 minute read I’ve had trouble installing the readline package on a few separate OSX installations, so I figured it was worth writing the solution down.
When running cabal install for a package which depends on readline (or simply when running cabal install readline), Cabal exits with errors along the lines of
Configuring readline-1.0.3.0...
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for GNUreadline.framework... checking for readline... no
checking for tputs in -lncurses... yes
checking for readline in -lreadline... yes
checking for rl_readline_version... yes
checking for rl_begin_undo_group... no
configure: error: readline not found, so this package cannot be built
The problem is that Cabal is not aware of the location of the readline lib. My workaround is to specify the location of the lib whenever running these commands:
$ cabal install readline --extra-include-dirs=/usr/local/Cellar/readline/6.3.8/include/ \
--extra-lib-dirs=/usr/local/Cellar/readline/6.3.8/lib/ \
--configure-option=--with-readline-includes=/usr/local/Cellar/readline/6.3.8/include/readline \
--configure-option=--with-readline-libraries=/usr/local/Cellar/readline/6.3.8/lib/
Your paths may differ slightly if you have a different version of readline installed. You can check this with
$ ls /usr/local/Cellar/readline
6.3.8
I’ve long been considering switching to a different keyboard layout. I tend to type with mostly my forefinger and middle finger, only using my ring and pinky fingers occasionally to stretch out to the modifier keys. Despite this, I still manage to type at around 120WPM on a staggered QWERTY keyboard.
Thinking back, I probably started teaching myself to type at a reasonable speed around age 10. I’m now in my mid-twenties. My typing technique (or lack thereof) never really bothered me, but 15 years of typing with poor technique has started to take its toll. Recently I’ve started experiencing hand fatigue, and I’m beginning to see early signs of RSI. So I figure now is the perfect time to make some changes to the way I type.
(Read more) 