I’ve spent the evening emailing back and forth with Chris from Sonos’ tech support about a strange issue I’ve experienced where the Sonos app can’t connect to the playbar (on both OS X and iOS). It turns out the problem is that my DLink wifi access point doesn’t handle multicast traffic properly – Chris knew that almost immediately but took me through each step carefully checking every assumption and taking the time to ask about settings in the terms DLink uses instead of generic ones.

My wife and I gave each other a Sonos playbar for Christmas to improve the clarity of our TV. The initial setup was excellent – clearly stepping through each required step and very cleverly detecting the type of TV remote I have and automatically reacting to it’s volume controls so I can carry on using the TV remote as usual. The only problem is that my Panasonic TV doesn’t provide a way to disable the internal speakers.

Rich Bowen – We’ve Always Done It That Way: Principle 13 in the Toyota Way says that one should make decisions slowly, by consensus, thoroughly considering all options, and then implement those decisions rapidly. We believe a similar thing at the ASF. So to people who have only been around for a short time, it looks like we never change anything. But the truth is that we change things slowly, because what we’re doing works, and we need to be sure that change is warranted, and is a good idea.

Jeffrey Ventrella in The Case for Slow Programming: Venture-backed software development here in the San Francisco Bay area is on a fever-pitch fast-track. Money dynamics puts unnatural demands on a process that would be best left to the natural circadian rhythms of design evolution. Fast is not always better. In fact, slower sometimes actually means faster – when all is said and done. Jeffrey’s right in suggesting that we sometimes need to go slower to go faster, unfortunately he makes the mistake of believing that committing and releasing in very short cycles is the cause of these problems:

Lawrence Kesteloot has an excellent post Java for Everything. About a year ago, though, I started to form a strange idea: That Java is the right language for all jobs. (I pause here while you vomit in your mouth.) This rests on the argument that what you perceive to be true does not match reality, and that’s never a popular approach, but let me explain anyway. There are two key realisations that are vital to understanding why this argument has merit and the first one is right there in the introduction: what you perceive to be true does not match reality.

Before writing any even half serious bash script, stop and read: Use the Unofficial Bash Mode How “Exit Traps” Can Make Your Bash Scripts Way More Robust And Reliable Any other particularly good articles on writing reliable bash scripts that should be added to this list?

When generating a JavaScript file dynamically it’s not uncommon to have to embed an arbitrary string into the resulting code so it can be operated on. For example: function createCode(inputValue) { return "function getValue() { return '" + inputValue + "'; }" } This simplistic version works great for simple strings: createCode("Hello world!"); // Gives: function getValue() { return 'Hello world!'; } But breaks as soon as inputValue contains a special character, e.

In Software is sometimes done Rian van der Merwe makes the argument that we need more software that is “done”: I do wonder what would happen if we felt the weight of responsibility a little more when we’re designing software. What if we go into a project as if the design we come up with might not only be done at some point, but might be around for 100 years or more?

When you have automated testing setup with a big display board to provide clear feedback, it’s tempting to try and use it for things it wasn’t intended for. One example of that is as a kind of reminder system – you identify a problem somewhere that can’t be addressed immediately but needs to be handled at some point in the future. It’s tempting to add a test that begins failing after a certain date (or the inverse, whitelisting errors until a certain date).

Every web based product is adding “responsive design” to their feature lists. Unfortunately in many cases that responsive design is actually making their product much harder to use on a variety of screen sizes instead of easier. The problem is that common CSS libraries and grid systems, including the extremely popular bootstrap, imply that a design can be made responsive using fixed cut-off points and the design just automatically adjusts. In reality making a design responsive requires tailoring the cut off points so that the design adjusts at the points where it stops working well.

Ever since the public beta of OS X I’ve been meaning to get around to learning Objective-C but for one reason or another never found a real reason to. I’ve picked up bits and pieces of it and even written a couple of working utilities but those were pretty much entirely copy/paste from various sources. Essentially they were small enough and short-lived enough that I only needed the barest grasp of Objective-C syntax and no understanding of the core philosophies and idioms that really make a language what it is.

Apple have released Swift, their new programming language – designed to be familiar to Objective-C programmers and work well with the existing Cocoa frameworks. It’s far too soon to make substantial judgements about the language – that can only come after actually using it in real projects for some time. However, there’s nothing that stands out as incredibly broken, so with Apple’s backing it’s extremely unlikely that it won’t become a very commonly used language.