Hardware Reference
In-Depth Information
The fourth group of computers is a mixed bag: mobile
phones, music synthesizers, and motor controllers, to
name a few. Some of them will have fully developed
physical interfaces, some will have minimal physical inter-
faces but detailed software interfaces, and most will have
a little of both. Even though you don't normally think of
these devices as computers, they are. When you think of
them as programmable objects with interfaces that you
can manipulate, it's easier to figure out how they can all
communicate, regardless of their end function.
X
Good Habits
Networking objects is a bit like love. The fundamental problem in both is that when
you're sending a message, you never really know whether the receiver understands
what you're saying, and there are a thousand ways for your message to get lost or
garbled in transmission.
Never Assume
What you say is not always what the other person hears.
Sometimes it's a matter of misinterpretation, and other
times, you may not have been heard clearly. If you assume
that the message got through and continue on oblivi-
ously, you're in for a world of hurt. Likewise, you may be
inclined to first work out all the logic of your system—and
all the steps of your messages before you start to connect
things—then build it, and finally test it all at once. Avoid
that temptation.
You may know how you feel but your partner doesn't.
All he or she has to go on are the words you say and the
actions you take. Likewise, you may know exactly what
message your local computer is sending, how it's sending
it, and what all the bits mean, but the remote computer
has no idea what they mean unless you program it to
understand them. All it has to go on are the bits it receives.
If you want reliable, clear communications (in love or net-
working), there are a few simple things you have to do:
•
Listen more than you speak.
•
Never assume that what you said is what they heard.
•
Agree on how you're going to say things in advance.
•
Ask politely for clarification when messages aren't clear.
It's good to plan the whole system out in advance, but
build it and test it in baby steps. Most of the errors that
occur when building these projects happen in the com-
munication between objects. Always send a quick “Hello
World!” message from one object to the others, and make
sure that the message got there intact before you proceed
to the more complex details. Keep that “Hello World!”
example on hand for testing when communication fails.
Listen More Than You Speak
The best way to make a good first impression, and to main-
tain a good relationship, is to be a good listener. Listening
is more difficult than speaking. You can speak anytime you
want, but since you never know when the other person
is going to say something, you have to listen all the time.
In networking terms, this means you should write your
programs such that they're listening for new messages most
of the time, and sending messages only when necessary.
It's often easier to send out messages all the time rather
than figure out when it's appropriate, but it can lead to all
kinds of problems. It usually doesn't take a lot of work to
limit your sending, and the benefits far outweigh the costs.
Getting the message wrong isn't the only misstep you can
make. Most of the projects in this topic involve building the
physical, software, and electrical elements of the interface.
One of the most common mistakes people make when
developing hybrid projects like these is to assume that
the problems are all in one place. Quite often, I've sweated
over a bug in the software transmission of a message,
only to find out later that the receiving device wasn't even
connected, or wasn't ready to receive messages. Don't
