Category: Technology

Michael Feathers at XPSTL

This evening at XPSTL, Michael Feathers (blog) (book) was in from out of town (and from around the world) and gave a talk on API design. He’s been thinking a lot about API design recently, driven by issues that come up with working with legacy code, which talks to lots of APIs, to cajole it in to a more testable state. I think there is a lot to say (maybe a book’s worth?), and a lot of what has been said elsewhere turns out to yield APIs that are unduly difficult to build testable code with.

What we end up doing here, and a thing that Michael says is not at all unusual, is to “wrap” most APIs with some application code, to enable:

  • a simplified way to call the external component / API, more suited to our needs
  • easy testing, as we can design our wrapper to make it trivial to substitute a test/mock implementation
  • a buffer from future changes in the external component / API
  • easier migration to alternate implementation of the same underlying services

Our wrappers tend to be “flatter” and simpler than the underlying APIs we wrap. For example, most of our use of Hibernate is behind a class we call DataSession, which represents the connection/session, transactions (it encodes our policies on how to use transactions) and many named methods for query operations (thus we avoid scattering HQL or SQL around the project).

Also, we had a big crowd at XPSTL – the room was packed.

Sutter Concurrency Talk – We Need Better Languages

I’ve seen lots of links to Herb Sutter‘s talk at PARC on concurrency. This is a great talk – I found it a little tough to make it through his paper on the topic, while the talk is a joy to experience, information-dense yet approachable. Some thoughts and notes:

  • There weren’t very many people in the audience – I’d have loved to fill one of those empty chairs.
  • He mentioned OO being invented decades ago… passed on the opportunity to mention that much of it happened right there at PARC.
  • I looked at Erlang some months ago after Joel Reymont described his experienced with it.  Erlang is worth looking at again, in depth.
  • For those of us who make a living by staying on the front slope of the adoption curve, the time is now (or past…) to build systems that run as a large number of separate threads of execution, to learn to build and use abstractions over concurrency, to run operations on a clusters of multi-CPU, multi-core PCs, etc.
  • We need to use languages that let us build new abstractions and new kinds of abstraction.  With such a language, if I wanted something like Herb’s “once {}” construct on slide 17, I could add it.

Weiqi pointed out Herb’s double-checked-locking comments.  I did in fact know that DCL was broken and is now fixed… but have generally sworn off its use anyway.  Life is too short to worry about whether we’re sure the right JVM will be used for each block of code we write.

One nit I have to pick is that the PARC site offers only an “mms://” streaming link for the video… I worked for me this time, but in general I’ve had far better results with plain old HTTP downloads and local playback, particularly if I’m not able to watch all in one sititng.

The J2EE / Rails / TurboGears / etc. Video

Lots of people are linking to this excellent video (presentation and screencast) by Sean Kelly at JPL (380 megabyte, 30+ minutes, worth it):

http://oodt.jpl.nasa.gov/better-web-app.mov

Watch it all the way through. Wow.

It’s a little over-the-top in its J2EE example; but the disparity is still stark… and near to my heart as we have a time tracking web application in development.

But I think he stopped short of a fundamental point: that the benefits of dynamic languages, XML-free convention over configuration, fast turnaround, etc. are not specific to GUIs or web applications; he experienced them there and showed them there, but as far as I can tell the same issues and benefits apply equally to the non-GUI tiers of a system.

Incompressible Java, PI day

Weiqi Gao reminded me that today is “PI Day”; that along wouldn’t warrant a post here, but the Java snippet for estimating the value of PI rather inefficiently, did:

[weiqi@gao] $ cat PI.java
public class PI {
public static void main(String[] args) {
double sum = 0.0d;
for (int i = 1; i < 64000; i++) {
sum += 6.0/(i*i);
}
System.out.println(Math.sqrt(sum));
}
}
[weiqi@gao] $ javac PI.java
[weiqi@gao] $ java PI
3.1415525815597167

The inefficiency of the PI estimate didn't bother me - rather it was the inefficiency of the text of the program. This is a a good example of the "incompressibility" of Java; there are a lot of words and symbols in there. Contrast that with a bit of Ruby:

ruby -e "print (1..64000).inject(0.0) { | sum, i | sum + 6.0 / (i*i) } ** 0.5"

3.141577732895

The difference in the answer is from the different underying floating point data types. The textual difference is easy to talk your way around for a small program like this. But we've found that as our applications grow, the amount of Java code grows at a frightening rate compared to the functionality therein. We work around that with great tools (Eclipse, IDEA), and accept it as a trade off to the strong library support and abundance of developers. But the language itself...

Slider Control for Touch-Screen Applications

An improved version of this post is cross-posted on the Oasis Digital blog.

At Oasis Digital we are working on an application that will run on a touch-screen computer, and which will be used to (among other things) control an audio amplification system. There are some design considerations for touch-screen applications which are rather stark once you use the touch-screen for a few minutes:

  • A finger is rather less precise than a mouse pointer – hitting small targets is hard
  • Drag/drop operations (or grab-adjust operations) sometimes don’t start quite where you aimed
  • Your finger blocks the point on the screen where you are pressing
  • The concept of keyboard “focus” is moot on applications with no keyboard

To accomodate the first two of these, I’ve built a prototype/example of a slider control to use for audio adjustment in such an application. It has these key features:

  1. It does not matter if you click on the “handle” or on the rest of the bar – because with touch screen you won’t be able to reliably do one vs. the other.
  2. The adjustment is not immediate; there is a limit of the speed of the adjustment to produce smoother audio control. The slider handle will move down very quickly, but will move up slowly. This avoids the possibility of an accidental touch pushing the audio amplification in to feedback.

The prototype/example looks like the screenshot here:

Touchscreen Slider

… but ignore the static image, it doesn’t tell the story. To see it in action, take a look at the screencast (currently in a WMV file, easily viewable only on Windows) or download the example program and play with it. The source is also on github.

This example runs on Delphi 2007 (rather old… but I had it handy on the PC at hand), an enhanced version of it in us used in a production application for a touch-screen audio control system. My secondary goal was to use it as a target to create an AJAX control with the same behavior. Anyone want to write that?

.NET Traction at Microsoft?

According to this article from Richard Grimes, it appears that .NET has not gained as much traction inside Microsoft as anticipated:
http://www.grimes.demon.co.uk/dotnet/vistaAndDotnet.htm

“My conclusion is that Microsoft has lost its confidence in .NET. They implement very little of their own code using .NET. The framework is provided as part of the operating system, but this is so that code written by third party developers can run on Vista without the large download of the framework. Supplying the .NET runtime for third party developers in this way is similar to Microsoft supplying msvbvm60.dll as part of XP.”

I think his conclusion is a bit overreaching, but this isn’t a big deal to me either way, and I’m neither a raving Microsoft fan nor a rabid Microsoft detractor.

However, this is good news in at least one important way:

To the extent Windows itself is not built on .NET, that in a sense leaves more room for other, non-.NET runtime environments to flourish as first class citizens, leaving more room for Java (we ship a commercial Java application, so that’s good…) and also for other currently and upcoming dynamic language runtime environments.