Jan 21, 2012 - Why Apple iBooks for textbooks is a bad idea


Apple recently announced an initiative and authoring tools to get school textbooks into their new iBook platform. This is a really bad thing for a couple of reasons.

First of all, this is an enforced vendor lock in. In other words, Apple iPad will be supported, and nothing else. This is not unexpected by Apple, but it begs the question about Apple's real motives.

Second, if you are thinking about authoring a textbook for this platform, read the fine text of the agreement. You are agreeing to give Apple exclusive rights to your book. Yes, exclusive means exactly what it sounds like - You are explicitly denied from publishing your work in any other way or medium!
If Apple really cared about education, they would be embracing open standards with an equal footing for anyone, and respecting author's rights. They could do this in a way that still makes them money, but instead have chosen to make sure that they are the only player. I'm really disappointed in how the media is touting how "great" this is without considering the downside.

Yep, Apple is proving themselves to be the new Microsoft, time and time again. I will continue to support open platforms and open standards, and encourage everyone reading this to do likewise. Say no to vendor lock in and exclusive publishing agreements!

Dec 11, 2011 - Firedust - Book 1 of The Adventures of Josh Bronsky


With Christmas just a couple of weeks away, this is a good time to plug my sister's book "Firedust" - Book 1 of The Adventures Of Josh Bronsky by Katherine Emmons.

If you have 8-12 year old children on your Christmas shopping list, you should really check it out! It's a great adventure story, with more books coming in the Josh Bronsky series...


Josh Bronsky is whisked off to the world of Lumira in a dune buggy stolen right out of the school parking lot.

His accomplice is the stubborn Isabel, better known as the Sock Princess. This whole fiasco is her fault.

A strange man warns Josh about an upcoming battle, and tells him about the firedust, ...

You can preview the first chapter of the book, and get more information, at www.firedust.org. Check out the links below to purchase the book directly from Amazon, or to get the ebook on Nook and Kindle.

Buy the book:

Buy ebook for Nook:

Buy ebook for Kindle:

Dec 8, 2011 - Fostering a 'just fix it' software development culture


During my career in software development I've encountered many different corporate cultures. A common one is what I like to call a "culture of blame". In blame cultures, everything revolves around finding someone else to blame. When a project is late, product managers blame developers. When there are bugs, developers blame QA. When tests fail, QA blames development. When there are production problems, operations blames developers. When QA can't get test environments to work, QA blames operations. When software is pushed before it's ready, developers blame product managers. It's all about plausible deniability and a "circle of blame".

Where I work now has a very different culture. I call it the "just fix it" culture. If you break the build, "just fix it". If tests fail, "just fix it". If there's a production issue, "just fix it". You see where this is going... Instead of finding someone to blame, or finding ways to defer the problem, "just fix it", and move on. There's no need for retrospectives (where everyone sits in a meeting room deciding who to blame), nor really any need to discuss it beyond what is required to fix it and get back on track.

Whether it's a "culture of blame", or one of "fix it", the reality is that the same person has to fix it. By skipping all the crap in the middle, we go from problem to solution without delay and diversion. Instead of pretending that we can be perfect, the trick is to accept that things break. It's not that we want things to break, it's about accepting reality. The poor person didn't mean to break it - he or she is mortified about it, in fact. By accepting a "just fix it" culture, we just ask that they fix it, and move on. In a "culture of blame" we end up discouraging this person from being productive because blame is intimidating, and it scares people into being afraid to commit. When people are afraid to commit, they stop being productive.

In the end, software development is all about productivity. You want developers to be productive. You want QA to be productive. You want operations to be (you guessed it) productive. How do we make everyone productive? It's not by pointing fingers, and it's not by assigning blame. We all know when we screw up, and we don't like doing so. Deep down inside, we all fundamentally want to succeed. This is pretty obvious, right? Nobody likes failure. So why do so many companies build a culture around failure instead of success? It's a good question, right?

So what's the secret?

Well, from the above, it's pretty obvious - stop playing the blame game. If Fred checks in code that breaks the build, Fred should know about it as soon as everyone else does. If he doesn't have visibility into this, then you need to improve your build system and notifications. It's perfectly OK to tell Fred "hey, did you see that the build failed?". Fred didn't plan on breaking it, and he wants to fix it. Notify, but don't blame. Fred will fix it. If Fred's not around, then someone else has to fix it. This is the exact same situation that you could be in with a "culture of blame" anyway, and the end result is the same, that somebody will need to fix it. Again, instead of worrying about who to blame, let's "just fix it", and move on.

An agile release process is key as well. If you only release a few times a year (or less), then blame is more likely, because the release process is expensive and infrequent. We release every week. If your code isn't ready, then your code doesn't go out this week. It's that simple, and the worst case is your code ships the following week instead. Very rarely we have skipped a release because the release branch has had issues, but again we don't blame anyone - we "just fix it" and release a different day, instead. Having the ability to do rolling upgrades without bringing down the site is key.

Simple, right?

It is simple, but there's complexity in the details, and it requires discipline and support from management - and an acceptance that things do go wrong. And yes, it requires that your corporate culture change. Are you mature enough to handle it? That's all up to you!

Dec 5, 2011 - NMEA-0183 and RS-422 vs RS-232


Following is an article I wrote 3 or 4 years ago regarding integrating marine navigation electronics via NMEA-0183. Recently a friend and fellow sailor had run across this same situation, so here you go Ron!

Questions seem to come up on occasion about wiring for NMEA, and use of RS-232. Hopefully this article will help understand the issue and be of use for other folks setting up an NMEA network on their own boats.

This discussion is explicitly about NMEA-0183 - not NMEA-0180, NMEA-0182, NMEA-2000, SeaTalk, etc. I've tried to write this technically correct, but hopefully more or less understandable without getting too loose on the details. If I've been overly sloppy, please don't hesitate to call me on them.

Strictly speaking, the NMEA-0183 specification calls for an RS-422 differential transmission system.

What's thedifference between single-ended and differential transmission?

"single-ended" means that the signal is transmitted over a single wire. The receiving end has to determine the voltage of this signal, and to do so it needs a reference. In a single-ended system, a "signal ground" is used as a reference. The receiving end essentially measures the voltage on the wire relative to this signal ground.

RS-232 is single-ended. A transmit wire has voltage relative to the signal ground. Note that in the case of a bi-directional configuration (where a particular device is both sending and receiving), the signal ground can be shared between the two.

The problem with single-ended transmission is that it can be prone to noise. For example, if the cable crosses over other cables, voltage can be inducted from the other cables and the receiving end may not be able to distinguish the right signal relative to signal ground. The same thing can happen if the signal ground is not stable.

Also, the RS-232 specification states that it is point-to-point, so technically speaking you can only have a single talker and a single listener. In other words, you cannot connect more than two devices together.

A "differential" transmission system works by transmitting over two wires. When one wire sends a voltage, the other wire sends the opposite voltage. The receiving end detects a transmission by comparing the voltage differential between these two transmit wires, instead of using a signal ground.

A differential setup is much less prone to inductive noise because an inducted voltage tends to affect both transmit wires in the same way. The receiving end doesn't care because it's only comparing the difference between the two wires - in other words, the inductive noise will increase (or decrease) the voltage in both wires, but the delta between the two will remain nearly constant.

Note that a proper differential transmission needs no signal ground, and a bi-directional setup (where a device is both transmitting and receiving) is supposed to require 4 wires, as there is no common reference ground. Also note that many "NMEA-0183" devices are loose on this. For example, both fixed-mount Garmin GPS units I have onboard only provide a single transmit and receive wire; power ground must be used for reference.

RS-422 uses differential transmission. Unlike RS-232, the specification allows for multiple listeners - but you can still only have a single talker. So, you can connect more than two devices together, but only one can be a transmitter, the rest must all be receivers.

So why can I plug my NMEA-0183 GPS into my computer's RS-232 and get data? You can argue it's either good engineering or just plain blind luck. RS-232 receivers detect the correct voltage, even though we've technically muddled things by using the power ground from the RS-422 transmitter as a signal ground on the RS-232 receiver. Using the power ground wire as a signal ground works because the RS-422 driver in the GPS bases it's transmit voltages from this ground. In other words, the combination of the right transmit leg of RS-422 and power ground is effectively the same thing as the combination of transmit on RS-232 and signal ground.

The unfortunate thing about loose adherence to RS-422 and not providing proper differential wiringis a much lower noise threshold. Where a single-ended system will start to become unreliable after maybe a couple dozen feet if you are lucky, a differential system can be reliable for several thousand feet. In an electrically noisy environment like a boat this can make a big difference.

After writing this article, I received some feedback from Actisense, a manufacturer of marine electronics. Below are the comments from Actisense - republished here without their permission but these were originally public, so I'm sure they won't mind. They've got some nice products in any event - worth checking out.

"So why can I plug my NMEA-0183 GPS into my computer's RS-232 and get data? You can argue it's either good engineering or just plain blind luck."
Most modern RS232 chips don't actually need the -ve swing to read a signal despite the requirement in the spec. This is why, more often than not, connecting RS-422 to RS-232 will work. I argue good engineering!

With the addition of isolated outputs to some products there is another good engineering solution. The differential (RS-422) system means that at one moment A is positive relative to B and then B is positive relative to A.

The key here is the word relative.

If B is tied to ground and cannot go positive then A is forced to go negative to B instead.

The A line is now swinging from + to - volts around B.

This can ONLY work if the outputs are isolated (floating).

Tying an un-isolated B to Ground will cause something to burn out.

The B line will be driven and a large current will sink straight to ground.

"Strictly speaking, the NMEA-0183 specification calls for an RS-422 differential transmission system."
NMEA 0183 version 2.0 onwards unequivocally specifies meeting the differential RS-422 specification. Previous to version 2.0 ground was used as a reference. The earlier version is why new products can claim NMEA 0183 status without meeting the RS-422 differential requirement without breaking any rules, somewhat cheeky perhaps but certainly allowed.

Hopefully this information helps other people who need to integrate NMEA-0183 systems together.

May 30, 2011 - Catalina 27 Daysail


Our boat is still in Mexico, but that doesn't stop me from being able to sail. This weekend I went for a quick daysail with close friends who recently bought a great Catalina 27. It was lots of fun sailing for the first time in three months. Thanks Jim+Wendy for a great day!

Cruising in the delta

Wing on Wing

Catalina 27 Interior