Living in a state of accord.

Mounting a Time Capsule Drive In Linux

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.

Critically, you need to insist on NTLM authentication using the sec=ntlm option.  You may additionally want to specify file_mode, dir_mode and other standard mount options.

If you are using disk or device password based security you only need to specify the password, the username is ignored. However, if you’re using account based security you’ll need to also supply a user= option to specify the correct username.

Sonos’ Support is Brilliant

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.

Normally support teams do just enough work to determine that it’s not their product at fault and then fob you off to the other company. I really appreciate the extra time Chris took to make sure I knew he was doing everything he could.

Even more impressive, all this happened on a Sunday night on the weekend between Christmas and New Year – getting responses almost immediately.

So if you’re considering a wireless speaker system – go buy a Sonos. The whole company is working hard to make it awesome for you and it shows.

Disabling Internal Speakers on a Panasonic TV

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:

  1. Configure the Sonos to respond to a different remote (or different buttons on your TV remote such as those for a DVD or video play you don’t use). Then simply turn the volume on the TV all the way down and don’t use the normal volume buttons anymore.
  2. Access the secretive hotel mode.

The secretive hotel mode is mentioned in a bunch of places on the internet but apparently Panasonic denies it exists (unless you’re a hotel I guess). To access it on my particular version I had to hold down the -/V button on the side of the TV and press “AV” on the remote three times.

A menu then pops up providing access to a few settings including a maximum volume. Enable hotel mode and set the maximum volume to zero and you’ve effectively disabled the internal speakers.

Now when you use the volume controls both the TV and Sonos will respond but the TV volume is limited to zero so the volume bar appears on screen but the TV speakers never activate.

This gives the ideal setup – a sound system that provide significantly improved sound from the TV without any extra remotes or other complications.

Decision By Consensus

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.

I’m a big fan of decision by consensus. It doesn’t mean everyone agrees (consensus does not require unanimity) but it does ensure that the bulk of the team are all on board and moving in the same direction.

It does take longer – much longer. And it requires investing a lot more into the decision making process, having debates, doing research and planning out how things will actually work. In the end though it’s worth it to avoid having the decision undermined by people resistant to the change or having decisions made too independently and then having people heading off in different directions.

Just don’t forget that one of the best ways to build consensus is by running a trial. It’s much easier to plan out a trial (including a rollback plan) and gain consensus for running it than for making the change permanently.

Another example of Less Haste, More Speed.

Less Haste, More Speed

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:

My programming style is defined by organic arcs of different sizes and timescales, Each arc starts with exploration, trial and error, hacks, and temporary variables. Basically, a good deal of scaffolding. A picture begins to take shape. Later on, I come back and dot my i’s and cross my t’s. The end of each arc is something like implementation-ready code. (“Cleaning my studio” is a necessary part of finishing the cycle). The development arc of my code contribution is synonymous with the emergence of a strategy, a design scheme, an architecture.

This kind of design and development arc is completely independent of how often the developer commits or how often a release is taken. As you speed up your commit and release cycle, you mostly shouldn’t change the design and development process of any given change you simply reduce the size of the change. By tackling much smaller problems at a time it’s much easier and quicker to go through the full arc of understanding, experimenting, scaffolding, building and tidying.

Part of making each small change is considering how it fits in with and modifies the overall system design. Bad development teams forget this and wind up with an awful mishmash of designs all cobbled together, but that’s a reflection of the team’s design ability, not of the process. Good teams gradually adjust the system design as they go, sometimes in subtle ways sometime with more radical changes. Doing so means the system design is optimal for each stage of its life.

Commenter mmlac nails it:

Maybe [the machine-gun committer] IS doing the same as you, just sharing the progress with the team, so people can spot obvious mistakes earlier and see the approaches and stop him in time if they have more experience with the way they are trying to go?

You are basically advocating waterfall. And the issues you face have nothing to do with the speed of coding and the number of commits.

That’s not to say that there isn’t value in the saying “Go slower to go faster” but the much better way to phrase it is “Less Haste, More Speed”. It’s not about going slow, it’s about not rushing and doing a good job. It means taking the time to break down large changes into smaller, simpler incremental changes so you don’t have to deliver them all in one go. It means considering what adjustments to the overall system design are required for each change to make it fit in well.

And it means committing and releasing more often. Regularly investing time to prove things are completely finished and sent off to users instead of building that time up as technical debt because you’re attempting to make too big a change at once.

You don’t go faster by simply trying to go faster – you go faster by identifying and eliminating bottlenecks which requires you to do things that individually appear to make you go slower but make the overall system go faster. Committing and releasing regularly (continuous integration and continuous deployment respectively) are solutions to the bottle neck of horrendous merge and release processes that result from not doing them regularly enough.