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.

Bar Camp, Code Camp

I met some of the Bar Camp guys:

http://barcamp.org/

at ETech last week:

http://conferences.oreillynet.com/etech/

and mentioned Code Camp to them:

http://blogs.msdn.com/trobbins/archive/2004/12/12/280181.aspx

These two non-conferences seem to have a lot in common, though one is vaguely MS-centric (it was briefly known as MSDN Code Camp) with the other isn’t. Brian Button is putting together a Code Camp here in St. Louis soon, it will be interesting to see how it works out.

http://www.agileprogrammer.com/oneagilecoder/archive/2006/01/22/11023.aspx

SQL Server Log Shipping Fragility

In a customer production system, we use MS SQL Server 2000 “log shipping” extensively to offload reporting DB load to secondary servers… a common use of the technology. This generally works very well, most of the time.
We’ve noticed, though, that it can be somewhat fragile, in that it is easy to inadventantly run a SQL operation (such as a large index update, schema change, etc.) that results in many, many pages shipped, and hence in large log backup files, and large “standby” files – all of which are processed surprisingly slowly by SQL Server. The result of this (the fragility) is that the log ship destination servers can then take many, many hours to return to an operatonal state.
It turns out that one cause of this is that log backup (and hence log shipping) apparently happens at the “page” level: if one bit on a page changes, all 8K of the page is shipped.

A second cause is that if a log backup happens during the middle of a large operation, it will ship the partially complete operation; the destination servers will then generate huge “standby” files (we’ve seen them over a gigabyte) in the restore process.
One path forward is to to move up to SQL Server 2005, which has numerous log shipping improvements. Imagine my dismay to find this today:

http://sqljunkies.com/WebLog/acalvett/archive/2006/03/12/18993.aspx

in which Andrew Calvett found that the log ship monitoring functionality is much worse in SQL Server 2005 than in SQL Server 2000.

As usual there is likely a third party tool to make this better. But since log shipping is such a powerful and flexible tool for scaling up SQL Server based applications, it is disappointing to see the monitoring get worse rather than better. Perhaps in SQL Server “2010”…