mult.ifario.us

There is plenty of talk about service-orientation as a way to decompose software, but I've come to look at it differently. Service-orientation is equally important as a way to decompose work.

As an impermeable barrier between the inside (i.e., implementation) of a service and the outside, service-orientation helps to reduce complexity of a larger system composed of multiple services. (Pat Helland's paper on “Data on the Outside vs. Data on the Inside” makes the case in detail.) This is a good thing, but it's not a great thing. Don't get me wrong — architecture requires a certain sensibility and flair, and there are plenty of deep thoughts yet to be thought about software. Nonetheless, the majority of the complexity in software engineering lies in putting a system into production (and keeping it there), not in coming up with an elegant design.

Service orientation also decouples teams. For example, the team working on the customer information system and the team working on the inventory management system only need to adhere to each other's service interfaces in order to collaborate. There is a huge difference between an interface and an implementation as the vehicle for collaboration. Once one system is built around the knowledge of something inside (i.e., the implementation of) another system, those two systems are rigidly linked, and this constrains the actions of both teams. For two teams trying to evolve two systems, this isn't a significant burden, but for dozens of teams trying to evolve dozens of systems toward different goals, it is debilitating.

Some e-commerce leaders talk the talk and walk the walk, but it doesn't take “interplanetary scale” to realize the benefits. Companies that ship complex, customized software to multiple customers have to manage the collaboration between product development and multiple professional services teams, and if they've done it for any length of time, they've probably encountered the challenge of migrating customizations between versions or even just between patches. (I've even seen systems — from a safe distance — where the customizations cross multiple tiers.) Trading communities are another example where service-orientation (albeit seldom SOAP/WSDL-style or even XML-based) or the lack thereof drives complexity and cost.

At any rate, yet another discussion thread on “business/IT alignment” in my inbox is what got me on the train of thought that spawned this entry, but I think that most such discussions miss the point. I do see service-orientation as a way to help align business and IT by pairing the semantics of the business with the semantics of the services, but it's the business of IT where service orientation pays the strongest benefits.

I followed the instructions and got Songbird built and running on my Mac without too much trouble. (I made a couple of very minor tweaks, as I prefer fink to darwinports, but it is essential to get the glib2 (2.10.3) and orbit2 from darwinports and in that order, as the locations of libraries are hardwired into some of the dependencies.)

I remain pleased with my minimal headless music configuration, but if I wanted something more iTunes-like, Songbird looks like it's going to be a good candidate. (Maybe the Mozilla plumbing will give Eclipse RCP a run for its money in the cross-platform rich client space...?) For a pre-alpha, it's in good shape so far. It imported most of my MP3s but turned up its beak at my FLACs and Oggs even though it looks like the embedded VLC engine should support them. It will be interesting to see how plugins and some of the network and social aspects evolve; if nothing else, Javascript as an extension language is more likely to spawn a community than iTunes's COM SDK on Windows and AppleScript API on OS X.

It takes some big hairy coconuts to knock on someone's front door and announce that you'd like to eat their lunch, so I assume that Kristopher Tate is half man and half palm tree. (The usual approach is to sneak up on them, even just a little bit, but then you don't usually ape their name, either...) On the other hand, either you suck or you don't suck. Either your business is solid or it isn't. Either you have a complete product or you don't. Either your customers love you or they don't. Either you can move faster than your competitors or you can't. Refusal to compete is admission of weakness, so it's great to see Flickr step up to Zoomr's challenge.

On the flip side, I see my Flickr photos as just that — mine. So don't use feudalistic control of your API as pseudo-DRM to lock me into your service, unless you want to ensure that I'll take my business elsewhere on principle. Instead of creating competitors by forcing people to work around you, either go so fast that no one can keep up or ensure that your service is so open, so flexible, and so compelling that people extend it rather than imitate it with minor twists.

When I was a mathematician, my preferred tools were a hard-bound notebook, a rollerball pen, and a box of crayons. I drew tons of pictures to help myself make sense of my ideas, and when I needed one for a document, I'd spend some time and draw it up in Adobe Illustrator or write a program in a T_EX macro package to draw it. I've written other entries about why as-plain-as-possible text files are preferable to formatted documents in a system like Microsoft Word or Open Office, and the same applies to drawings, except that in this case, it involves not using a computer at all.

A piece of paper or pieces of paper, fed into a fax machine and then received via j2 (or eFax or another similar service) or scanned with a multifunction machine and converted to a convenient format (i.e., PDF), are more time-effective than a drawing tool like Visio or even OmniGraffle. It takes a few minutes to sketch out what's needed, drop it in a sheet feeder, and then collect the results for use as an email attachment or for cut-and-paste. (At least on the Mac, Preview supports cut-and-paste to other applications as native PDF.) For a related take, see Paper Prototyping Graphics, although the idea of using stickers seems like a step back toward unnecessary frills to me.

In the form of a “do the simplest thing” corollary: If you need to draw a picture, use a pen. If you need to draw a pretty picture, use an app.

I needed an algorithm to traverse a graph of relationships and test whether it was a connected tree or not, so I coded-up a quick (and relatively efficient) search. No matter how many times I code graph searches, I know myself well enough to expect a couple of mistakes, so I went to write some tests after I'd finished with the algorithm. The reason that I'd put off writing the tests was that the signature for my search was the following:

static FancyIface findRoot(Map<FancyIface,FancyIface[]> graph)

FancyIface is an interface with a bazillion methods and where the API doesn't expose any implementations. Rather than mocking instances of FancyIface for testing purposes, it makes sense to genericize the method:

static <T> T findRoot(Map<T,T[]> graph)

and then code the tests with something nice and simple, like integers:

public void testFindRoot() {
  Map<Integer,Integer[]> m = new HashMap<Integer,Integer[]>();
  m.put(1,new Integer[] {2,3});
  m.put(2,new Integer[] {4});
  // should return 1, as this is a tree rooted at 1.
  assertTrue(Foo.findRoot(m) == 1);
  m.put(3,new Integer[] {4});
  // should return null because this is no longer a tree.
  assertFalse(Foo.findRoot(m) == null);
}

And that's it.

The mouse has its place, but I've never been that fond of the degree to which use of the mouse is required in many GUIs. (I'll take the position that anything that can reasonably be done without the mouse should be.) QuickSilver was a giant leap forward in de-emphasizing the mouse, and Mail ActOn helped; but the browser was largely the domain of the mouse. Now the Conkeror extension for Firefox takes a step toward mouse-free browsing with an interface that seldom requires taking hands away from the keyboard. In addition to Emacs-ish key bindings (including for text areas) and conveniences (like c to copy the current URL to the clipboard), Conkeror numbers the links and form elements on a page for random access (as opposed to the sequential access provided by TAB'ing in a traditional browser interface), and so far it's an improvement. (This approach does run afoul of really fancy interfaces like GMail, but the mouse remains usable for those situations.)

Conkeror also has a nice feature called “webjumps” (derived from an Emacs feature of the same name) that reminds me a bit of YubNub. For example, to find out how far below hair care brands, the NPR Paul Brown, and famous football coaches I rank on Google, I type g followed by google Paul Brown. Or, to add the current URL to my del.icio.us bookmarks, I type g followed by adelicious .. This requires adding the line delicious_username=“prb” (in my case) to your ~/.conkerorrc file and ensuring that Conkeror knows the location of your rc file by telling it on the help page (M-x help-page). (The . in the del.icio.us webjump is just window dressing and could just as well be foo or whatever; the webjump doesn't take any arguments, but Conkeror doesn't interpret a URL as a webjump unless an argument is supplied...)

Bill Clementson has some additional tips here and here.

Fit is an acceptance testing framework that drives test plans off of tables in HTML documents, and FitNesse is a wiki for creating the test plans and viewing the reports. Individual tests are composed of tables, and each table corresponds to a test fixture implemented as a Java class.

As part of its nature as a wiki, FitNesse thinks of camel case “words” as potential pages, and this sometimes clashes with, e.g., the naming of test fixtures or arguments in a test table. FitNesse does this by appending a hyperlinked “?” to the end of the candidate page name, and when the HTML is exported to Fit for evaluation, the “?” goes with it. In other words, FooBar in the wiki text is exported as FooBar? to Fit. (The HTML tag for the hyperlink is stripped.) The way to get FitNesse to not look at a word as a potential wiki page is to escape it, e.g., !-FooBar-!. (And since there is no page that describes the markup that FitNesse uses, I figured this out by reading the source code. It could also be inferred from the wiki markup source of an example, but that's only marginally easier.)

I ran into this with a long, fully-qualified class name in a table that was passed to a custom fixture, but when the fixture tried to load the corresponding class, it wasn't able to find the class. I looked at the exception trace, I looked at the wiki page source, and I looked at my fixture source. Everything looked reasonable. The FitNesse folks suggest debugging by putting in some System.err.println(...) statements, but I went ahead and set FitNesse to configure the Fit runner for remote debugging. This is done by changing the COMMAND_PATTERN variable:

!define COMMAND_PATTERN {java -agentlib:jdwp=... -xp %p %m}

where the ... are the options that make sense for your config. (This is for JSE 5.) I stepped through the fixture and inspected the classloader instance (a URLClassLoader) that I was using, and it appeared to be configured with an appropriate URL to find the class in question. (This was particularly puzzling because the classloader was the one used to load a class in the same package as the class that I wanted to load, and as far as I can tell, the Fit runner does absolutely nothing fancy with class loading.)

As you might imagine from above, the answer is that FitNesse exports the HTML, not the wiki source, and so the “?” after the class name was flowing along as part of the input to the method, and it somehow escaped my notice. The solution was to properly validate input by using a regular expression and provide an informative error message if it failed, which I should have done in the first place, but I had to slap my forehead for taking so long to find that extra “?” lurking around.