Thursday 06th March, 2014
Week 268 - Interesting links
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
I’ve been playing about with Ruby enumerators recently. This article was one of the most useful in explaining how they work. — JM
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
An excellent post by Paul about the difficulty of adding value through validation of user input. — CR
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.
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.