Lots of articles out there that have almost the right solution here but nearly all of them miss one critical component, so for my future sanity, here’s what works for me:

sudo mount.cifs //timecapsule.local/Data/ /mnt/directory/ -o “pass=password,sec=ntlm”

If you don’t have zeroconf working in your Linux install you’ll have to use the time capsule’s IP instead of it’s .local name.  The “Data” part is the name of the disk you want to mount as shown in Airport Utility (make sure you escape any spaces with backslash.

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. By the end of it all I had a solid understanding of what the problem was and a simple way to describe it to DLink’s support to see if it could be fixed. A little creativity on my end has even given me a good work around.

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. So the playbar and the TV were both outputting sound which sounds pretty awful.  There’s two ways to solve this:

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. As Lawrence notes:

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.g.

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? Would we make it fit into the web environment better, give it a timeless aesthetic, and spend more time considering the consequences of our design decisions?

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). Now the build is green and there’s no risk of you forgetting to address the problem because it will fail again in the future. Perfect right?

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. This is probably best exemplified by the approach to memory management those utilities took: it won’t run for long, so just let it leak.