#ifdef

A client’s project requires a Java solution to fit their deployment strategy. One specific component of the implementation is an XML-RPC server. Using Groovy would be useful because there is a lot of XML being slung around as parameters. I could go with the Groovy XMLRPCServer, but it does not support SSL.

No problem, I’ll find a Java solution and Groovify it. How about the Apache XML-RPC implementation?. Excellent. However, I need to know that it works in its most basic, i.e. Java form. I’d rather not sandbox up an entire XML-RPC solution just to see how this thing works. Though small, there ought to be a better way than throwaway, experimental code. A nice way to deal with this is to use the published Calculator example with easyb.

The calculator class was unchanged. Here’s the easyb story that combines the xmlrpc server and client sides.

import org.apache.xmlrpc.client.*;
import org.apache.xmlrpc.webserver.*;
import javax.servlet.http.*;

scenario "apache xmlrpc server should work", {

        given "an xmlrpc servlet",{
          def sum = 0
          servlet = new XmlRpcServlet()
        }

        and "a servlet webserver", {
          webServer = new ServletWebServer(servlet, 4000)
          webServer.start()
        }

        when "the calculator.add method is invoked by an xmlrpc client", {
          config = new XmlRpcClientConfigImpl()
          config.setServerURL(new URL("http://127.0.0.1:4000/"))

          client = new XmlRpcClient()
          client.setConfig(config)

          sum = client.execute("Calculator.add", [33, 9])
        }

        then “the sum should be correct”, {
          sum.shouldEqual 42
        }

        and “stop the webServer”, {
          webServer.shutdown()
        }
}

Also, very nice how easyb allows some relaxation of the strict Java syntax in the xmlrpc client section. That starts to suggest what a Groovy subclass might look like. Next, a git commit to capture this working example in a readable form for the lifetime of the project.

There’s been a long running conversation about the relationship between static typing and unit testing. As early as 2003, Bob Martin found that unit tests reduce dependence on type safety. Around the same time Bruce Eckel argued that compilation is simply one test for correctness; and that code needs to pass all the tests that define correctness of your program. More recently, Stuart Halloway claims ‘In 5 years, we’ll view compilation as the weakest form of unit testing‘. Are you spotting a trend here?

This all bubbled up again for me recently on an embedded project I’m working on to optimize security policy lookups on a multicore security platform. The task was to optimize performance of the vendor’s C reference implementation. Policy insertion used a simple, but unscalable single linked list having O(n) performance. Of course, the code comes without tests of any kind, so how does one know that the optimization changes don’t break basic functionality?

Obviously, the best thing to do in this situation is to write tests for existing behavior so that as the API is refactored and reimplemented, the tests find any new logic errors. I got payback even before the optimization work got started. The linked list insert (implemented thousands of times by thousands of developers) had a bug in it. Policies that were supposed to be stored in priority order after insert were off by one.

Definition: Reference System n. A software implementation provided by hardware vendors to demonstrate programming of a target device; not intended for deployment in end user products. (2) A software implementation provided by hardware vendors that is for the most part, directly inserted into the systems of end users.

This really isn’t a rant about reference code, it’s about defensive testing and the fact that writing tests are not just for dynamic languages. The Java community is mostly on board with this, but it seems to have gotten slower adoption by the C variant world. So c’mon embedded developers. Let’s stop pretending that the type safety testing by our compilers is good enough.

Here’s one option. I really like check as a unit test tool for C. It has a niced xUnit flavor and ought to be in everyone’s toolbox.

START_TEST(it_should_insert_in priority_order)
{
    Policy* policy5 = alloc_policy_with_priority(5);
    Policy* policy6 = alloc_policy_with_priority(6);
    insert_policy(policy5);
    insert_policy(policy6);
    fail_if(policy_find(policy5) == NULL);
    fail_if(policy_find(policy6) == NULL);
    fail_unless(policy_first() == policy5);
}
END_TEST

And if you happen to be implementing reference code, a set of tests for your API would be a welcome addition to your product; not a program to exercise the hardware, but tests that verify and document the behavior of your APIs. It will reduce the bulk of documentation that needs to be provided to end users and may allow you to remove those weasel words, “not intended for deployment”.

It turns out that some changes to the Linux kernel — Ubuntu 8.04 uses Linux 2.6.24 — have introduced some issues that make running Ubuntu in a VMWare virtual machine difficult. Ubuntu will install just fine, but you won’t have access to VMWare Tools, which provides some nice features like shared folders and clipboard syncing.

[From Ubuntu 8.04 Causes Problems With VMWare Tools, Open Source to the Rescue | Compiler from Wired.com]

It isn’t just VMWare. Mac Parallels has likewise bitten me and many others judging by the considerable forum angst. My peeps have been telling me to cutover to Fusion. I’d say if VMWare fixes their tools issues before Parallels, I’ll consider it.

Here’s a weird thing that happened while working with VMWare Server. While trying to get one of my virtual machines bridged to our corporate LAN, I kept getting an error that no dns servers were configured.

The fix was to force the VMnet0 controller choice rather than allow it to bridge to an automatically chosen adapter. By doing that, the virtual machine was able to get an IP on the LAN.

This was for a Windows XP host machine and the configuration is performed by the Virtual Network Editor located on the host at VMWare Server > Manage Virtual Networks.

40. (with egg) Visual Studio, Ruby on Rails, and Old Dudes Who Know Smalltalk

I really love Old Dudes Who Know Smalltalk! I was nurtured, sculpted, and brainwashed by Old Dudes Who Know Smalltalk from my very first day as a professional programmer, and they universally “get it”. Young whipper-snappers out there, take note: if you ever here (sic) some Old Dude say the words “in Smalltalk you could blah blah blah” or “In VisualWorks you could yada yada”, spend as much time with this person as possible. You will learn more from them about software development than the Young Dude who only wears black and thinks that the bash shell is “too bloated”.

Oh… I am so feeling the love. One old dude benefit is in recognizing useful language features. I immediately fell in love with Groovy after seeing it’s Closures implementation. (By coincidence, I’m listening to Jason explain Closures on a WebDevRadio interview. He wants to whip out his Mac and show you, but… it’s radio). Likewise, being interested in tools to better exploit processor concurrency, I’ve been studying Erlang and have to say that I’m really disappointed with the bulky syntax. It just isn’t very readable, IMO. I much prefer the clean syntax of Scala.

Update: Merlyn has similar issues with Erlang readability, though attributes it to style rather than language syntax. I have to admit, the solution gives me hope.

One day there will be statements about the Old Dudes Who Know Ruby. I don’t really expect to be around for that one, but trust me; it will happen.

Over at InfoQ, Geoffrey Wiseman comments on Why Agile Adoptions Fail. It could have mockingly been titled “Agile Fails When Individuals Aren’t Sufficiently Impressed by the Process”. Ironically, many of the reasons he summarizes from Jean Tabaka’s original list blame the individuals involved.

Exactly why should people care about any grand poobah of process? A friend surprised me the other day by saying he wanted to be a development manager. I asked why. He said that as a programmer there is no shortage of people that want tell him how to do his job. But for managers, no one tells them how to do their job. They are only responsible for results.

There you have it. No one wants to be arbitrarily told how they should work. Offering solutions to their day to day headaches will get you respect, however.

Jared Richardson does a great talk on Gradual Agile from his NFJS rotation which he shared with Agile RTP recently. Stealth Agile would be an appropriate title as well. The case study he presents is a great example of introducing agility in a way that wins friends and influences people. One of the golden nuggets in there:

Your agile toolbox has everything in it needed to solve real business problems.

For a long time in our startup, I was slightly embarrassed by never having a “good” answer to the question, “What agile methodology are you using?” The implication was that if it wasn’t Scrum, XP, or some other labeled process, then it must not be agile, i.e. worth consideration.

The thing is though, we intrinsically knew that the Agile Manifesto was the right attitude to adopt for our team. People solutions were favored over process, primarily. We didn’t try to get Ruby/Rails running on a network processor doing gigabit encryption (although once we considered a JVM) to prove agility. We simply applied agile solutions whenever there was a business issue to be solved. Every practice we adopted as a team; unit testing, continuous integration, retrospectives, etc., was a response to a business problem, scaling issue or point of pain in the daily grind.

There were many times that we interacted with customers and certification bodies interested in our “process”. Most of the time, the questions they had were oriented towards waterfall type work flows and artifacts. We’ve never had any trouble mapping our agility to the “best practices” that were expected by these groups.

Rather than boiling the ocean and rewriting from scratch to have a process described in a book, we refactored. Not adopting agility wholesale, but gradually; recognizing that we had problems that could be fixed with agile solutions.

So, how do you eat a hippo? One bite at a time. You can go agile that way, too.

Extraordinary C++ - The Astoria Seminar

Must do this at least once before I die. I’m still digesting Dave Abraham’s MPL presentation from the fall!