Scraping active Optimizely experiments

Need to see what’s running?

I think Optimizely might’ve done something to make this tricker as an optional project setting, but it’s handy to be able to debug what’s running and possible splits.

Object.keys(optimizely.allExperiments).map(function(item){
item = optimizely.allExperiments[item];

if (!item.enabled) return;
console.log([item.name,'\n',item.variation_ids.map(function(v){
    return "\t" + item.variation_weights[v]/1000 + "%: " + optimizely.allVariations[v].name;
  })].join(''))
})

Paste in console.

Fixing a Magic Button MBTX4 remote (which is really a Neatrol Systems 4Ch RFAND Tranceiver)

Our garage remote died recently. We subbed the battery, and nothing improved. Stood closer, nothing improved. Sporadic successes were very-much outweighed by failures.

The base station/”receiver” (it’s actually a tranceiver, I think? If you want to learn more about this than I did, KeyLoq would be a good starting point) in our little block of four has been known to have some problems, but the sporadic failures and our pretty comical attempts to hold the remote at different angles, out windows, bashed-sideways, bashed-frontways, etc., were yielding poorer and poorer results.

Anyway, an afternoon prodding the thing got us to “oh the button’s probably dead”. So much for those new batteries.

At least in our situation, a four-button remote is a pretty useless thing - there’s only one gate to control. Turns out the numbering on the front of these things doesn’t even line up with the PCB - we hit “2”, which always confused me no end, but this is really pressing button 1 on the circuit.

Button 1, in this case, was doing nothing at all.

Replacement time!

The PCB’s pretty generously spaced, probably because no-one wants a remote so tiny it gets lost. The surface mount buttons are pretty easy to work with. I ordered this pack of 20 buttons from an eBay seller (described as a “20pcs 6x3x4.3mm SMT SMD Momentary Micro Tact Tactile Push Button Switch” in the very likelihood the listing has vanished by the time you’re reading this… eBay, stop the bitrot!) for about $5 having measured up the button as being, well, vaguely that size. The buttons on my remote were black and these were white, but hey, it’s behind a piece of rubber anyway. If anyone needs 19 SMD buttons and is in Sydney, holler at me - they’re probably in a drawer somewhere.

I realised while I was popping off the old button and soldering on the new that I actually didn’t need to order any buttons at all, of course.

If you, like me, only use a single of your four remote buttons… just swap the bad one for a good one! My soldering is shocking but the original SMD work was pretty tidy and easy to get things on and off. The good news is it’s a spacious enough board you probably don’t need to worry too much about melting the wrong thing.

Anyway, yay, working remotes again!

Jekyll, .well-known and other dotfiles

Not that this blog is used for much, but I hit this while trying to add a file under .well-known and realising I couldn’t get the directory to show up.

As this is hosted on Github Pages (and I hadn’t published for ~2 years), I wondered if adding a static file wasn’t enough to trigger a publish. Turns out GH Pages is fine, the issue’s how Jekyll handles (or doesn’t) . prefixed files/dirs.

The solution is to add this to your config.yml:

_config.yml

include: [".well-known"]

Jekyll actually documents this pretty clearly (search “Include” on that page) but I found mention of it on a Keybase issue first.

Given their documentation is focused on .htaccess files (haven’t used those/Apache for a while!) I thought I’d document here to optimize more for the search terms I was using!

Jekyll

First update in quite a while… but worth noting this blog is now powered by Jekyll after a pretty bad run of security things with WordPress (my fault: not keeping it up to date, their fault: security holes every other day).

Good news is everything is static and Github Pages hosted now. Comments have gone to Disqus (for better or worse), and analytics stays on GA (I just upgraded their circa 2007 Urchin tracking JS). Love it when stuff starts to work.

In defense of Data URIs

A friend sent this Mobify article my way with a one-liner comment: “Sprites over Data URIs?”

True to Bettridge’s law of headlines, here’s my reaction.

No. :P

Their test image is a 17.6KB file. If you’re serving up any files that big you’ve already lost (see also, our jumbo sprites on mastheads). See also the recommendation at the end of the post to “use data URIs in exactly the right way” – which, I hope, is broadly how we’ve been using them.

This isn’t to completely disregard these results, but I would like to see it run with better test data (images in the 500 byte - 4KB range, say) to reflect actual best practice usage. Again, if you’re using images as large as they are, there are probably ample opportunities to make easier micro-optimisations, which is what this whole debate is about.

That said, there are plenty of other problems with this article.

The penalty of data URIs for older phones is severe - on Android 2.2 materialization of five 17.8kB images took almost 2 seconds in the data URI condition!

Note how Android 2.2 is a complete outlier in the original chart and subsequent observations – it’s not supported by us, and comprises >0.5% of m-site traffic (source: GA, last 30 days). It’s a red herring that would be better off excluded for honest charting – especially given the author’s own data reflects ours – see his own RUM chart distribution for evidence.

There’s also a methodology problem in that this is dealing with inlined src attributes on elements, which introduces additional DOM performance and possibly reflow considerations assuming these are visibly attached that you wouldn’t experience with background images in CSS. Completely agree that it’s harder to measure the nonexistent ‘load’ event of CSS background images, but that isn’t a defense for the disingenuous finding that this equally impacts all inlined images. (Though the high CPU assumption seems sound enough.)

Here are a couple of assumptions of my own:

1. CSS parsing is necessarily more efficient than popping elements onto an unstable DOM, unless you attach the CSS late in the load. Note how in the histogram charts image materialization starts dependably late (i.e. reliably >5ms in) – CSS parsing has happened long before this assuming it was in the head.

2. CSS uses ‘classes’, and is therefore more efficient than creating separate DOM elements with separate attributes that need to be individually unpacked. Therefore, measuring the materialization of five images is a poor test, unless four of those were deep cloned from an original element and browsers somehow cache the unpacked binary data (poking around source code and bug reports might help ascertain this). Suspect the test didn’t do this, and if not, strongly doubt that browsers would have stored a hash of the unpacked encoded data to quickly reference – memory is too tight on mobile to bother with this.

3. Because of 2, multiple instances of elements (commenting icons, media type indicators, etc.?) will not incur any measurable performance hit over loading just a single element, though obviously more elements on the DOM costs something.

4. Even disregarding 1-3, we are splitting hairs here. It’s a micro-optimisation whereby we’re hoping to move events in the 10-20ms range (if you accept that a 17KB image is even a reasonable test) to the 1-5ms range. That sounds big, but consider the number of elements we are doing this with, and consider user perception of this on pages that can already take over a second to load.

Data inlining, especially with preprocessors, is about maintainable code (because sprites are the Dementors of the front-end world), repeating/large-but-small-filesize backgrounds, and the ability to pick whatever format you like should you so choose (i.e. for some very small images, GIF outperforms PNG, and for some textures, JPG outperforms PNG, and with inlining you can CHOOSE to do this!)

If this is really keeping you up at night, look into using Appcache as well, because that’ll hopefully save on some network pain (assuming we’re worried about that given how bullish the original post is on pipelining). I apologise in advance for the caching complexity and curly support requests it creates!

Still firmly of the view that there’s a big place for data-inlining on the mobile web.