Welcome the Audio Fool

   I'd like to welcome a member of my team to the world of blogging.  His blog is called The Audio Fool.  He works on measuring the fidelity of audio devices for Windows.  If you have interest in audio and want to learn about it from a technical standpoint, I suggest you add his blog to your rss reader.  I look forward to reading it.

VOIP - Ready for Prime Time?

   About two months ago my wife and I decided to take the plunge and try out VOIP.  Economically it made a lot of sense.  The pricing at SunRocket is just so much better than the price of our local baby bell.  The question was, would the service be comparable?  The short answer is that while it is not as good as POTS, it is good enough for us.  It may not be for everyone yet though.

   There are three major worries about VOIP phones:

• It may not work with 911


• The voice quality may be low


• It isn't reliable.

Two of the three of these turned out to be non-issues and the third isn't as big a problem as it might have been.

   The 911 problem is largely solved for VOIP.  All of the major providers support Enhanced 911 service.  When you call 911, the call center is provided with information like your address.

   The voice quality is excellent on our line.  At times I think it sounds a bit different but only when I'm focusing on it and that could just be me hearing what I expect to hear.  It is certainly better than most cell connections.  I don't notice any breakup, distortion, or significant latency.

   The reliability isn't all there yet.  POTS never goes out.  Even when your power is down, POTS phones just work.  This isn't the case with VOIP.  If your power it out, it won't work.  If your network is down, it won't work.  When the VOIP company is having issues, it won't work.  When we first had the phone installed, we were experiencing random drops where we could hear what the other person was saying but they couldn't hear us.  After a call (on a cell phone) to Sunrocket, tech support fixed the issue by tweaking something in their device.  Since then, it has been working like a charm. 

   System setup is really easy.  Just plug the device, which Sunrocket calls their "Gizmo," into your network between your cable/dsl modem and your router.  The Gizmo has 2 phone jacks on it into which you plug regular phone line and regular phones.  At my house I have a star network for my phones so I just connected the device to my central phone hub and all the phones in the house worked.

   So, would I recommend it?  Yes.  There is a caveat that you'll have to be a little technically savvy to deal with the glitches that come with networking.  If you can figure out how to reset a cable modem/router every once in a while, you can handle this.  The economics of VOIP are just so much better than land lines.  In our area, a full package of phone plus features like caller ID, etc. costs $35 per month plus long distance and taxes.  Sunrocket is just over $17.  If you have a land line you don't use very much, you can get away with the $9.95/month package.  For $25/month, I can deal with a little inconvenience.

Prescriptive Advice For Successful Unit Testing

   At the beginning of the Vista (then Longhorn) project our team decided that we would implement unit tests.  This was the first attempt in our locale to try to use them.  We had some successes and some failures.  Out of that I have learned several things.  This is an attempt to codify what I have learned and to try to set out a prescription for what I feel it would take to leverage them fully.  What follows are my recommended practices for implementing unit tests:

1. Unit tests must be written by the developers of the code.  Having a separate test team implementing them doesn't work as well.  First, they take longer to write.  The person developing the code knows how it is supposed to operate and can write tests for it quickly.  Anyone else has to spend time learning how it is intended to be used from the minimal (at best) documentation or conversations with the developer.  Having the developer write the unit tests acts as a form of documentation for everyone to follow.  Second, the tests take a lot longer to come online.  They are available days, weeks, or even months after the code is checked into the product. 


2. Unit tests must be written and passing before the code is checked in.  Writing unit tests should be considered part of the development process.  Nothing is code complete unless there are passing unit tests for it.  Checking in code without passing unit tests should be treated like checking in a build break.  That is, it is unacceptable.


3. The unit tests must never be allowed to fail.  Just recently I saw a bug in our database about a unit test that was failing.  The bug was filed several months ago.  This just cannot be allowed to happen if you are going to get the full value out of the unit tests.  Unit tests should act as canaries.  They are the first things to fall over when something goes wrong.  If they ever break, they must be fixed immidiately.  


4. Before any checkin, existing unit tests must be run and made to pass 100%.  This is a corrolary to points 2 and 3 but I want to make it explicit.  Just as you would get a buddy build, a code review, and a smoke test before every checkin, you must also pass the unit tests.


5. Unit tests must be granular and comprehensive.  A test case which plays back some media is not really a unit test for a media pipeline and it certainly isn't sufficient.  At a minimum, each external interface should be tested for all expected values.  An even better system of unit tests would verify internal interfaces directly as well.  A rule of thumb is that unit tests should achieve at least 60% code coverage before the first checkin is made.


6. Standardize a mechanism for storing, building, and running unit tests.  Don't leave it up to each individual or small team.  There should be a standard harness for the tests to be written in.  There should be a convention followed by all for where to check them into the source tree.  Unit tests must be built regularly.  In my opinion, the unit tests should be written in the same harness used by the test team for their tests.  The unit tests should be checked into the build right alongside the code that they are testing and should be built with each build.  A build break in a unit test is just as bad as a build break in the shipping code.


7. The unit test framework must be lightweight.  If the framework is to be the same one the test team uses (highly recommended), it must be one that can be run easily.  If running unit tests requires anything more than copying some files and running an executable, it is too heavy.  Expecting developers to install a whole test framework to run their tests is a prescription for disaster.


8. Run unit tests as part of the daily testing process.  If the tests use the same harness, they can be leveraged as part of the daily tests.  The tests for external interfaces can be especially useful in assessing the quality of the product.

Have any other best practices for unit testing?  Let me know.

Introductory Lisp Books

  I've been doing a little reading about Lisp lately.  In particular, I've read two books on the subject.  ANSI Common Lisp by Paul Graham and Practical Common Lisp by Peter Siebel.  I haven't finished either book but I've read enough to give an assessment of the two.  If you are considering learning Lisp, read on for my recommendation.
   Let me start by saying that both books are good.  Both books assume that you already understand how to program.  Neither book is written for someone who is brand new to the art.  They both cover the subject of ANSI Common Lisp which is probably the predominant dialect of Lisp. 
   Practical Common Lisp starts off with a quick tutorial and moves on to a simple database implementation.  Only after these two examples does Mr. Siebel start describing the syntax and symantics of the language.  After some typical programming book subjects like functions, variable, control structures, and macros, the book goes back to examples.  The examples are easy to follow and give you a good sense of how Lisp is to be used.
   ANSI Common Lisp is written by Paul Graham who also writes on the subject of startups, geek culture, and programming langugaes over at his web site.  Mr. Graham takes a different tack.  After a quick introduction/tutorial, he describes the language via data structures--talking about lists and other data structures.
   My preference is for the ANSI Common Lisp book.  There are two primary reasons for this:  1)  it is more accessible to a C/C++ programmer and 2) it flows better. 
   ANSI Common Lisp approaches the subject from a perspective that is understandable to a C/C++ programmer.  Whereas Practical Common Lisp describes the Let/Setf operators by talking about "bindings", ANSI Common Lisp describes it in terms of variables and pointers.  The first requires becoming fully versed in a new way of thinking.  The latter comes naturally.  PCL also introduces forms and s-expressions but describes them in terms of other Lisp concepts.  This makes it hard to understand unless you already grok Lisp, which, if you are reading the book, probably isn't the case.  ACL avoids these concepts in the abstract and only introduces them with concrete examples.
   PCL also commits what I like to call the carnal sin of programming books.  It uses concepts in its examples before actually introducing them.  For example, in an example on page 94, it uses the first, second, and third functions.  Unfortunately, it doesn't actually explain what these are until page 143.  ACL, on the other hand, seems to build more logically upon the previous pieces it has introduced.
   It should be noted that PCL is available for free as a PDF if that is to your liking.  Personally, I prefer dead trees.