Week 268 - Interesting links

Using Feature Flags to Ship Changes with Confidence

Feature flags allow you to conditionally switch chunks of functionality on or off. They’re commonly set on a per-environment or per-user basis. This tactic means a developer can commit work to master but hide the new functionality until it’s “ready”. This article gives some practical suggestions for how to implement feature flags in a Rails app. — JM

Ruby 2.0 Works Hard So You Can Be Lazy

I’ve been playing about with Ruby enumerators recently. This article was one of the most useful in explaining how they work. — JM

Oppia: a tool for interactive learning

This open source project from Google looks really interesting. There appears to be a lot of crossover with the work we were doing at FutureLearn. — CR

Using CCMenu with Travis CI

I’ve used CCMenu on Mac OSX for many years to keep an eye on continuous integration builds - it’s a status bar app displaying a green or red symbol depending on the status of the build(s). Although it’s somewhat old news, this article is a good write up of how to use CCMenu with Travis CI for both public and private repositories. — JM

First encrypted and signed indieweb comment using PGP (thanks to Keybase.io)

This is a really interesting experiment of using encryption to send private messages on the IndieWeb. It reminds me of what Trsst is trying to do. — CR

1 error(s) prevented this form from being saved

An excellent post by Paul about the difficulty of adding value through validation of user input. — CR

New Project: Air Hockey Robot

I’m a big fan of Air Hockey and so this robot which was built using parts from a RepRap 3D printer caught my eye. — JM

Continuum

A great post that argues against the idea of trying to make sites look and act the same across multiple browsers. These two paragraphs stick out for me. — CR

If your client or boss expects that a website will look and behave the same in every browser on every device, then where did they get those expectations from? And rather than spending your time trying to meet those impossible expectations, I think your time would be better spent explaining why those expectations don’t match the reality of the web.

And

I think part of the problem may be with the language we use. We talk about “the browser” when we should be talking about the browsers. I’m guilty of this. I’ll use phrases like “designing in the browser” or talk about “what we can do in the browser”, when really I should be talking about designing in the browsers and what we can do in the browsers.