Blog
The list of ideas and features you and your team could come up with is likely enough to last a lifetime. There's both an art and science to choosing what to work on next as well as what you will not take on.
Let's take a look at some of the motivations behind prioritization, a couple of specific techniques, and finally some of the wrinkles that make this messy in the real-world.
While refactoring some of the data manipulation behind www.cambridgebumps.com I came across an ovbious place to apply some memoization. This is where we cache a, usually expensive, function call so that subsequent calls simply return the cached value. It's a performance optimization.
While React and d3 are designed with different goals in mind they do share a common theme. This is that data should define what you see.
The following musings are supported by a simple mortgage calculator example you might want to play around with first.
That they have different goals can be seen in their approaches to changing the DOM. I prefer to think of the algorithms behind these two pieces of technology as implementation details for the most part. At the end of the day what you get out of them is satisfactory performance for a particular use-case. For React is it effectively letting you re-render your interactive UI on any data change using a shadow DOM. For d3, it doesn't feel quite as declarative, but it will mutate the DOM directly to enable you to update and animate thousands of elements as part of your data visualization.
It's easy to think of applications which would benefit from both approaches. For example, an analytics dashboard could use React for the UI and d3 to render the charts.
However it turns out to be not straight forward to integrate the two technologies.
Mike Bostock outlines a standard for putting together d3 plugins here. My first serious attempt is d3-bumps-chart - a way of visualizing bumps race results. You can see it used at www.cambridgebumps.com.
The original implementation imported the whole of d3.
import * as d3 from 'd3';
I decided to try being more specific and only import the individual d3 packages I was using, e.g.
import {select} from 'd3-selection'; import {scaleLinear} from 'd3-scale'; import {line} from 'd3-shape'; import {max, range} from 'd3-array';
Rollup is a Javascript module bundler. Think Webpack or Browserify. My take is that it has fewer features but brings tree-shaking to the table. Rollup will eliminate unused library code and the theory is that this will always generate smaller modules than the equivalent Webpack or Browserify equivalent. Nice!
However, when I moved to importing specific objects from individual d3 modules I started seeing the following error message.
selection.transition is not a function
Some digging around turned up the root cause. Rollup's heuristics for detecting code to include do not in general pickup code which relies on side effects. The way the transition function in d3-transition works relies on such side-effecting code. The solution is simply to explicitly import the module itself, i.e.
import 'd3-transition';
I put this up in the hope it might save someone else some time when putting together a d3 plugin.
I launched cambridgebumps.com this week during the annual Cambridge Town Bumps event (see the Cambridgeshire Rowing Association for details). However this post is about the website and not the rowing.
Google Analytics summary
With 110 crews taking part we know that there are at worst around 1000 people interested in looking at results. I'll take 800 users and 1,500 sessions and deem the launch successful.
Average session duration appears good at over five minutes and the bounce rate is satisfactory.
Who makes up the audience?
Demographics
A good spread of ages here. Only 41% of sessions were from women but I can't draw any firm conclusions because I don't know the underlying split of women/men in the population who care about bumps results.
This is the first website I've developed with mobile as the primary target platform.
Mobile vs Desktop
Pretty much as expected. The majority of visits come from mobile devices. Despite targeting mobile I must say the experience is still superior on desktop; with several features only available there.
My hunch is that mobile suits looking up live/recent results. Whereas desktop suits looking back at past results and a more exploratory usage pattern. It would be good to test this hypothesis.
Traffic sources
This is the first time I've set up Google Adwords for a personal project. Making up almost a fifth of traffic this was an attempt to reach people outside my immediate social media reach. It is clearly not cost effective (as I have no intention to monetise this website).
Organic search was poor but expected. There was no time to develop a good search ranking. Next year will be a better test once the website has had time to find its way into organic search results.
What one area would I look to improve?
Definitely live results. There is a demand for it. My workaround was to wait for the official results to be put online and then update my website. This already means there is a delay of several hours.
The process of actually updating my website was also difficult. It is easy on a laptop where I can put up the results and my website side-by-side. On my phone I have to switch between screens and it is very error prone.
All in all a satisfying project to work on. Bring on the new rowing season!
The second problem in our series of algorithm katas is Kingdom And Trees from Top Coder.
Essentially we have an array of positive integers which we want to transform into an array of strictly increasing positive integers. The only operation at our disposal is to change the value of an element by an amount in the range [-X, X].
Every few months I revisit the git client landscape. I know enough about the git command-line to be dangerous but sometimes I just want to forget the syntax and click on some buttons.
